MODELAGEM DE PROCESSOS
Unidade IV 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
5
• 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.
10
15
• O fluxo de dados pode ser unidirecional ou bidirecional por meio da conexão. • Para esclarecer o significado 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.
31
Unidade IV A expressão usada pela UML para os indicadores de multiplicidade é:
5
Muitos Apenas um Zero ou muitos Um ou muitos Zero ou um Intervalo específico
* 1 0..* 1*
Exemplo de nomeação de uma associação: gerência
<>
<>
GerenteDeRegistro
10
Curso
Exemplo de indicador de multiplicidade de uma associação: <>
1
1..*
GerenteDeRegistro
<> Curso
Exemplos de como interpretar (ler) a associação representada em num diagrama de classes: <>
1
é gerenciada
GerenteDeRegistro
<> Curso
Um objeto “Curso” é gerenciado por um único “GerenteDeRegistro”: <> GerenteDeRegistro
32
gerência
1..*
<> Curso
MODELAGEM DE PROCESSOS Um “GerenteDeRegistro” gerencia um ou muitos “Cursos”. 6.3 Associação reflexiva
É quando os objetos da própria classe estão se relacionando. <> 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 5 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. 10
• É representada como uma linha de associação com um diamante junto à classe agregadora. • A multiplicidade é representada da mesma maneira que nas associações. <> FormularioDeRegistro
<> 1
1
FormularioDeRegistro
Um objeto da classe “FormularioDeRegistro” contém um único objeto “FormularioDeMatricula”. Um objeto 15 “FormularioDeMatricula” está contido num único objeto “FormularioDeRegistro”.
33
Unidade IV Agregação reflexiva: é quando objetos de uma classe é composto de objetos da própria classe. 6.4.1 Associação ou agregação <> FormularioDeRegistro
<> 1
1
FormularioDeRegistro 1
<> 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 3..10
1..*
Nota
5
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. 10
34
• 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.
MODELAGEM DE PROCESSOS • 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 terraogcwmstheme
terraogcwmscgi
terraogcwmsserver
wmsplugin
terraogcwmsclient
terraogcwms
terraogcows
terraogxml terramanager
terraogccommon
terraogcutils
xerces-c_2_7 terralib Figura 23 - Diagrama de componentes.
35
Unidade IV 6.7 Diagrama de implantação Cliente 1 - WMS
SGBD 1
Servidor HTTP
ogwsserver
Cliente 2 - WMS
SGBD 2 HTTP ogwswms
Cliente 3 - WFS
HTTP 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 5 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 10 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 15 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).
36
MODELAGEM DE PROCESSOS 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 5 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 10 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 15 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 fichas de papel e as operações 20 são efetuadas por funcionários da empresa com o uso de lápis, borracha e grampeador.
37
Unidade IV 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, ficando relegados à fase de projeto os elementos da solução, 5 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 10 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 15 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 20 representar informação:
25
30
38
• 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: fita, 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 filme e endereço do cliente;
MODELAGEM DE PROCESSOS
5
• 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. Emprestimo
Cliente 1
1 TipoDeFilme + tipo: String + prazo: Inteiro + preco: Moeda
+ + 1 + +cadastro +
cadastra
tipo
nome
Videolocadora titulo codigo 1 1
1
solicitou *[ordered}
*
ItemDeEmprestimo + prazo: Inteiro + valor: Moeda
Reserva referenciou
+ titulo: String
1 contém *
prioriza
especifica Filme
1
1
1
1 *
nome: String endereço: String telefone: Inteiro debito: Moeda
+ data: Data * + valorTotal: Moeda + pago: Booleano
1
*
1
+ data: Data
está em 1 EstadoDeItemDeEmprestimo
* especifica *
1 Fita
apareceu em *
Concluído
+ danificada: Booleano = falso aparece em Em andamento + codigo: String 0..1 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.
39
Unidade IV Referências bibliográficas ASSEMBLY LANGUAGE SOURCE CODES. Disponível em: . 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: . Acessado em 25 de maio 2009. SOAP TUTORIAL. Disponível em: . 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.
40
