modelagem de processos 4

Prévia do material em texto

31
MODELAGEM DE PROCESSOS
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
25
/0
8/
09
Unidade IV
5
10
15
6 RELACIONAMENTOS
É a maneira como as classes de objetos interagem entre si 
para formar o comportamento do sistema. Esse relacionamento 
é apresentado pelo diagrama de classes. Os dois principais tipos 
de relacionamento são associação e agregação.
6.1 Associação
• Compreende uma conexão bidirecional entre classes que 
indica a existência de um relacionamento entre os objetos 
dessas classes.
• Nos diagramas de classe, é representada por uma linha 
conectando as classes associadas.
• O fl uxo de dados pode ser unidirecional ou bidirecional 
por meio da conexão.
• Para esclarecer o signifi cado de uma associação, ela é 
nomeada. No diagrama de classes, o nome é apresentado 
ao longo da linha de associação. Usualmente, esse nome 
é um verbo ou uma frase verbalizada.
• Entre duas classes pode existir mais de uma associação.
6.2 Multiplicidade de associação
É o número de instâncias de uma classe relacionada com 
uma instância de outra classe. Para cada associação, há uma 
multiplicidade em cada direção.
32
Unidade IV
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
25
/0
8/
09
A expressão usada pela UML para os indicadores de 
multiplicidade é:
Muitos * 
Apenas um 
Zero ou muitos 1 
Um ou muitos 
Zero ou um 0..* 
Intervalo específi co 1 * 
Exemplo de nomeação de uma associação:
<<Controle>>
GerenteDeRegistro
<<Entidade>>
Curso
gerência
Exemplo de indicador de multiplicidade de uma associação:
<<Controle>>
GerenteDeRegistro
<<Entidade>>
Curso
1 1..*
Exemplos de como interpretar (ler) a associação representada 
em num diagrama de classes:
<<Controle>>
GerenteDeRegistro
<<Entidade>>
Curso
é
gerenciada1
Um objeto “Curso” é gerenciado por um único 
“GerenteDeRegistro”:
<<Controle>>
GerenteDeRegistro
<<Entidade>>
Curso
gerência 1..*
5
10
33
MODELAGEM DE PROCESSOS
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
25
/0
8/
09
Um “GerenteDeRegistro” gerencia um ou muitos “Cursos”.
6.3 Associação refl exiva
É quando os objetos da própria classe estão se relacionando.
<<Entidade>>
Curso
Pré-requisito
0..*
0..*
Um curso está associado a nenhum ou a muitos pré-
requisitos. Além disso, um curso é pré-requisito de nenhum ou 
muitos cursos.
6.4 Agregação
• É uma forma especializada de associação, na qual um 
todo é relacionado com suas partes. Também conhecida 
como relação de conteúdo.
• É representada como uma linha de associação com um 
diamante junto à classe agregadora.
• A multiplicidade é representada da mesma maneira que 
nas associações.
<<Fronteiriça>>
FormularioDeRegistro 1 1
<<Fronteiriça>>
FormularioDeRegistro
Um objeto da classe “FormularioDeRegistro” contém 
um único objeto “FormularioDeMatricula”. Um objeto 
“FormularioDeMatricula” está contido num único objeto 
“FormularioDeRegistro”.
5
10
15
34
Unidade IV
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
25
/0
8/
09
Agregação refl exiva: é quando objetos de uma classe é 
composto de objetos da própria classe.
6.4.1 Associação ou agregação
<<Fronteiriça>>
FormularioDeRegistro 1 1
<<Fronteiriça>>
FormularioDeRegistro
1
<<Controle>>
GerenteDeRegistro
6.4.2 Classe de uma associação de classe
Permite adicionar atributos, operações e outras características 
a uma dada associação.
Aluno Curso
Nota
3..10 1..*
A classe de uma associação de classe, normalmente, é gerada 
a partir de uma associação de muitos para muitos.
6.5 Relacionamento entre pacotes
• Pacotes são relacionados uns com os outros usando um 
relacionamento de dependência.
• Se uma classe de um pacote interage com uma classe de 
outro pacote, a relação de dependência é adicionada em 
nível de pacote.
5
10
35
MODELAGEM DE PROCESSOS
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
25
/0
8/
09
• Relacionamentos entre pacotes são obtidos a partir dos 
diagramas de classe e de cenário.
Aluno
RegrasDoNegocio
Elementos da Universidade
6.6 Diagrama de componentes
terraogcwmscgi
terraogcwmstheme
terraogcwmsclient
terraogcwmsserver
terramanager
terralib
xerces-c_2_7
terraogcwms
wmsplugin
terraogxml
terraogccommon terraogcutils
terraogcows
Figura 23 - Diagrama de componentes.
36
Unidade IV
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
25
/0
8/
09
6.7 Diagrama de implantação
ogwsserver
ogwswms
Servidor
Cliente 1 - WMS
Cliente 2 - WMS
Cliente 3 - WFS
HTTP
HTTP
HTTP
SGBD 1
SGBD 2
SGBD 3
Figura 24 - Diagrama de implantação.
7 MODELAGEM CONCEITUAL
O modelo conceitual deve descrever a informação 
que o sistema vai gerenciar. Trata-se de um artefato 
do domínio do problema e não do domínio da solução. 
Portanto, o modelo conceitual não deve ser confundido 
com a arquitetura do software (diagrama de classes de 
projeto), pois esta, embora inicialmente derivada do 
modelo conceitual, pertence ao domínio da solução e, 
então, serve a um objetivo diferente.
O modelo conceitual também não deve ser confundido 
com o modelo de dados, pois o modelo de dados enfatiza 
a representação e a organização dos dados armazenados, 
enquanto o modelo conceitual visa representar a compreensão 
da informação e não a sua representação física.
O modelo conceitual procura mostrar quais são os elementos 
de informação tratados pelo sistema, para que mais adiante se 
possa mostrar ainda como essa informação é transformada pelo 
sistema a partir das diferentes requisições do usuário (operações 
de sistema).
5
10
15
37
MODELAGEM DE PROCESSOS
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
25
/0
8/
09
O analista deve lembrar que a fase de análise considera 
apenas o mundo exterior ao sistema, e nunca seu interior. Por 
isso, não faz sentido falar em modelo de dados nessa fase porque 
os dados somente existirão no interior do sistema. Uma maneira 
interessante de compreender o modelo conceitual é imaginar 
que os elementos descritos nele correspondem a informações 
inicialmente existentes apenas na mente do usuário.
Figura 25 - O modelo conceitual é uma representação da visão que o usuário tem 
das informações gerenciadas pelo sistema.
O usuário, pelas operações e consultas de sistema, 
passa informações ao sistema e recupera informações do 
sistema. O sistema nem precisa ser considerado um sistema 
computacional nesse momento. Ou seja, essas informações 
existem independentes da existência de um computador para 
armazená-las.
O objetivo da análise é estudar o problema. Mas o sistema 
computacional seria uma solução para o problema, logo, objeto 
de estudo da fase de projeto. O sistema-solução poderia também 
não ser computacional. Seria possível analisar todo um sistema 
e propor uma solução manual para implementá-lo, na qual 
os dados são armazenados em fi chas de papel e as operações 
são efetuadas por funcionários da empresa com o uso de lápis, 
borracha e grampeador.
5
10
15
20
38
Unidade IV
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
25
/0
8/
09
Assim, o modelo conceitual deve ser independente da 
solução física que virá a ser adotada e deve conter apenas 
elementos referentes ao domínio do problema em questão, 
fi cando relegadosà fase de projeto os elementos da solução, 
isto é, todos os conceitos que se referem a computadores 
como: interfaces, formas de armazenamento (bancos de dados), 
segurança de acesso, comunicação etc.
7.1 Elementos básicos do modelo conceitual
Apesar de a análise trabalhar com diferentes casos de uso 
em cada um dos ciclos iterativos, o modelo conceitual é único 
para todo o sistema. Então, não existe “modelo conceitual do 
primeiro ciclo”, ou do segundo ciclo etc. Existe um único modelo 
conceitual para todo o sistema, o qual vai sendo completado à 
medida que se passa de um ciclo para outro.
O modelo conceitual representa somente o aspecto estático 
da informação. Dessa maneira, não podem existir no modelo 
conceitual referências a operações ou aspectos dinâmicos dos 
sistemas.
Quando se trabalha modelagem conceitual com diagramas 
de classes da UML, existem precisamente três elementos para 
representar informação:
• conceitos, que são representados por classes. Conceitos 
na modelagem conceitual são a representação da 
informação complexa, que não pode ser descrita 
meramente por tipos alfanuméricos. Exemplos de 
conceitos num sistema de videolocadora são: fi ta, 
cliente, empréstimo e reserva;
• atributos, que são informações alfanuméricas diretamente 
ligadas aos conceitos. Exemplos de atributos num sistema 
de videolocadora são: idade do cliente, data do pagamento, 
nome do fi lme e endereço do cliente;
5
10
15
20
25
30
39
MODELAGEM DE PROCESSOS
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
25
/0
8/
09
• associações, que muitas vezes são pouco compreendidas e 
consistem em um tipo de informação que liga diferentes 
conceitos entre si. Porém, a associação é mais do que 
uma mera ligação: ela própria é um tipo de informação 
conceitual importante. Exemplos de associações são: “é 
dono de”, entre uma pessoa e seu automóvel, “contraiu”, 
entre um cliente e um empréstimo, “emprega”, entre uma 
empresa e um grupo de funcionários.
Cliente
+ nome: String
+ endereço: String
+ telefone: Inteiro
+ debito: Moeda
Emprestimo
+ data: Data
+ valorTotal: Moeda
+ pago: Booleano
TipoDeFilme
+ tipo: String
+ prazo: Inteiro
+ preco: Moeda
ItemDeEmprestimo
+ prazo: Inteiro
+ valor: Moeda
Reserva
+ data: Data
Filme
+ titulo: String
Fita
+ danifi cada: Booleano = falso
+ codigo: String
Concluído
Em andamento
EstadoDeItemDeEmprestimo
tipo
titulo codigo
nome
cadastra
+cadastro1
1
1
11
1
1
1
*
*
*
*
*
*
*
*
1
1
1
1
1
1
1
0..1
Videolocadora
especifi ca
prioriza solicitou
contém
está em
apareceu emespecifi ca
aparece em
referenciou
*[ordered}
Figura 26 - Modelo conceitual para o primeiro ciclo de uma videolocadora. Fonte: 
Waslawick, 2004.Glossário
Glossário
SOAP – protocolo simples baseado em XML que permite que 
aplicações troquem informações sobre HTTP.
5
40
Unidade IV
Re
vi
sã
o:
 B
ea
tr
iz
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
25
/0
8/
09
Referências bibliográfi cas
ASSEMBLY LANGUAGE SOURCE CODES. Disponível em: <http://
www. emu8086.com/dr/asm2html/assembler_source_code/>. 
Acessado em 23 de maio 2009.
DAUN, Berthould. Modelagem de objetos de negócios com 
XML: abordagem com base em XML. Rio de Janeiro: Elsevier, 
2004.
FOWLER, Martin; SCOTT, Kendal. UML essencial: um breve guia 
para a linguagem padrão de modelagem de objetos. 2. ed. 
Porto Alegre: Bookman, 2000.
GORDON, Steven R.; GORDON, Judith R. Sistemas de 
informação: uma abordagem gerencial. Rio de Janeiro: LTC, 
2006.
QUEIROZ, Gilberto Ribeiro de. UML: visão geral. Instituto 
Nacional de Pesquisas Espaciais: s.l, 2008. Disponível em: 
<http://www.dpi.inpe.br/~gribeiro/apresentacoes/uml_ 2008_
02_29.pdf>. Acessado em 25 de maio 2009.
SOAP TUTORIAL. Disponível em: <http://www.w3schools.com/
soap/ default.asp>. Acessado em 23 de maio 2009.
WAZLAWICK, Raul Sidnei. Análise e projetos de sistemas de 
informação orientados a objetos. Rio de Janeiro: Elsevier, 2004.