Quais são os tipos de associações que representam a relação Todo parte entre objetos?

Artigos .NET UML Unified Modeling Language � Parte 01

Desenvolvimento

A UML tem v�rias divis�es, cada uma com uma apresenta��o distinta.

Suas divis�es s�o:

• Vis�es;
• Modelos de Elementos;
• Mecanismos Gerais;
• Diagramas.

Vamos falar de cada divis�o em particular, elas mostram os diferentes aspectos do sistema.

� descrita por um n�mero de diagramas que cont�m informa��es que d�o �nfase aos aspectos particulares do sistema.

Os diagramas podem fazer parte de mais de uma vis�o do sistema.

Os sistemas s�o compostos por diferentes n�veis de vis�es.

As vis�es do sistema s�o:

• Vis�o de Casos de Uso: Descreve as funcionalidades do sistema desempenhadas pelos atores externos. � a vis�o central, base para as outras vis�es do sistema. Diagramas de Casos de Uso e eventualmente Atividades.
• Vis�o de Componentes: Descreve a implementa��o dos m�dulos e suas depend�ncias. Consiste nos componentes dos diagramas.
• Vis�o L�gica: Descreve como as funcionalidades do sistema ser�o implementadas, especifica a estrutura est�tica e din�mica. Diagramas de Classe e Objetos e Diagramas de Estado, Seq��ncia, Colabora��o e Atividades.
• Vis�o de Organiza��o: Mostra a organiza��o f�sica do sistema, os computadores, perif�ricos etc e como eles se conectam entre si. Diagrama de Execu��o.
• Vis�o de Concorr�ncia: Trata da divis�o do sistema em processos e processadores. Diagramas de Estado, Seq��ncia, Colabora��o e Atividade.

Modelos de Elementos

S�o os conceitos utilizados nos diagramas, os elementos da UML s�o blocos de constru��o para os modelos dos diagramas s�o essenciais para o entendimento da UML, cada elemento tem um prop�sito, regras e nota��es diferentes. Alguns elementos podem ser usados em diferentes diagramas.

Elementos do Modelo:

• Caso de Uso: � a descri��o de um conjunto de seq��ncias de a��es realizadas pelo sistema, que proporciona resultados observ�veis de valor para um determinado ator. Um caso de uso � realizado por uma colabora��o. Graficamente � representado por uma elipse de linhas cont�nuas, incluindo somente seu nome.
• Ator: O Ator � algu�m ou algo externo ao sistema, mas que vai interagir com o sistema, � representado como um boneco.
• Classe: � a descri��o do conjunto de objetos que compartilham os mesmos atributos e relacionamentos (estado), opera��es e sem�ntica (comportamento), podem implementar uma ou mais interfaces e, graficamente, s�o representadas por ret�ngulos, com tr�s divis�es: 1�-Nome da Classe, 2�-Conjunto de Atributos e 3�Conjunto de M�todos.
• Objeto: � uma inst�ncia de uma classe, em tempo de execu��o. � graficamente representado por um ret�ngulo com o nome sublinhado, ou o nome seguido de dois-pontos, o nome da classe e do seu tipo.
• Interface: � um elemento que define uma cole��o de opera��es que especificam servi�os de uma classe ou componente. Ela representa todo o comportamento externamente vis�vel do elemento. Pode representar todo o comportamento, ou apenas parte dele. Ela define um conjunto de especifica��es de opera��es, mas nunca de um conjunto de implementa��es de opera��es. � representada graficamente por um c�rculo e o respectivo nome.Uma interface raramente aparece sozinha.
• Estado: Todos os objetos possuem um estado, que � o resultado das atividades executadas por ele. O estado representado por um ret�ngulo com os cantos arredondados e o nome do evento dentro do desenho.
• Componente: � a parte modular de um sistema, cujo comportamento � definido pelas suas interfaces. O trabalho interno dos componentes deve ser invis�vel, e o seu uso deve ser independente de plataforma. Geralmente c�digos-fonte, DLLs, Java Beans e outros artefatos s�o considerados componentes. Graficamente � representado por um ret�ngulo com duas abas na lateral esquerda.
• N�: � uma pe�a f�sica de equipamento, na qual o sistema ser� disponibilizado, por exemplo, uma esta��o de trabalho ou um servidor. Ele geralmente cont�m os componentes e outras artes execut�veis do c�digo, que podem ser ligados a processos em particular ou espa�os de execu��o, s�o usados nos diagramas de deployment, para modelar o deploy de um sistema, e para ilustrar a aloca��o f�sica dos artefatos implementados. Graficamente � representado como um cubo.
• Colabora��o: Define as itera��es e o comportamento cooperativo, resultado da soma das fun��es dos elementos, sendo assim, as colabora��es cont�m dimens�es estruturais e comportamentais. Graficamente s�o representadas como elipses tracejadas com o seu nome.
• Pacote: � um mecanismo de prop�sito geral para a organiza��o de elementos em grupo.

Modelos de Elementos

S�o os conceitos utilizados nos diagramas, os elementos da UML s�o blocos de constru��o para os modelos dos diagramas s�o essenciais para o entendimento da UML, cada elemento tem um prop�sito, regras e nota��es diferentes. Alguns elementos podem ser usados em diferentes diagramas.

Relacionamentos

S�o as liga��es entre os elementos dos modelos UML. Os elementos est�o ligados uns aos outros, especificando o que cada elemento significa ao outro e qual o grau de liga��o deles, ou seja, qual a rela��o l�gica existe entre os elementos. A estas liga��es damos o nome de Relacionamentos.

Tipos de Relacionamentos:

Associa��o

Representa uma liga��o entre dois elementos. Ainda podem expressar a cardinalidade (ou multiplicidade) e a navega��o (sentido) da associa��o.

<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

Na figura 1 temos uma associa��o simples entre duas entidades, cliente e conta corrente, onde uma possui a outra e vice e versa.

Associa��o Recursiva

Acontece quando um elemento se conecta a ele mesmo, e a associa��o tem alguma sem�ntica no modelo.

Na figura 2 mostramos como � poss�vel conectar uma entidade a ela mesma atrav�s de uma associa��o recursiva e que ainda representa semanticamente a conex�o entre dois objetos, mas os objetos conectados s�o da mesma entidade.

Associa��o Exclusiva

Quando algumas combina��es de associa��es n�o s�o compat�veis no dom�nio do problema. � uma restri��o entre duas ou mais associa��es.

Na figura 3 podemos notar que objetos de uma entidade podem participar de no m�ximo uma das associa��es em um dado momento. Uma associa��o exclusiva � representada por uma linha tracejada entre as associa��es que s�o partes da associa��o exclusiva, com a especifica��o {ou} sobre a linha tracejada.

Associa��o de Classe

Uma classe pode ser associada a uma associa��o. Serve para adicionar informa��es extras � associa��o existente.

Na figura 4 a associa��o da classe Fila com a associa��o das classes Cliente e Processo pode ser estendida com opera��es de adicionar processos na fila, para ler e remover da fila e de ler o seu tamanho. Se opera��es ou atributos s�o adicionados a associa��o, ela deve ser mostrada como uma classe.

Associa��o Tern�ria

Usada quando mais de duas classes podem se associar entre si. Ela � mostrada como um grande losango (diamante) e ainda suporta uma associa��o de classe ligada a ela, tra�ar-se-ia, ent�o, uma linha tracejada a partir do losango para a classe onde seria feita a associa��o tern�ria.

Na figura 5 a associa��o tern�ria especifica que um cliente poder� possuir 1 ou mais contratos e cada contrato ser� composto de 1 ou v�rias regras contratuais.

Agrega��o

Este � um caso particular de associa��o. Indica que um elemento � parte ou est� contida em outra classe. Representa uma rela��o do tipo parte/todo.

Na figura 6 um jogador pode ser membro de uma Equipe ou v�rias Equipes em determinado momento.

Agrega��o de Composi��o

� um relacionamento onde um elemento est� contido em outro, ou seja, a vida de um depende do outro, e os seus tempos de vida s�o os mesmos.

Na figura 7 o objeto da entidade que cont�m for destru�do, as entidades da agrega��o de composi��o ser�o destru�das juntamente j� que as mesmas fazem parte da outra, se tirar o cora��o a pessoa morre.

Generaliza��o ou Heran�a

A generaliza��o � um relacionamento entre um elemento mais geral e um mais espec�fico.

Na figura 8 a generaliza��o normal � representada por uma linha entre as duas entidades, conta corrente e poupan�a, que fazem o relacionamento, sendo que coloca-se um seta no lado da linha onde encontra-se a superclasse no caso a conta corrente indicando a generaliza��o.

Depend�ncia

A depend�ncia � uma conex�o sem�ntica entre dois elementos, um independente e outro dependente.

Na figura 9 existe uma rela��o de depend�ncia � simbolizada por uma linha tracejada com uma seta no final de um dos lados do relacionamento. E sobre essa linha o tipo de depend�ncia que existe entre as duas classes. A entidade Aplica��o <> da entidade Janela.

Refinamento

O relacionamento de refinamento ocorre entre dois elementos parecidos, em diferentes n�veis de abstra��o.

A figura 10 mostra como os refinamentos s�o simbolizados por uma linha tracejada com um tri�ngulo no final de um dos lados do relacionamento e s�o usados em modelos de coordena��o.

Mecanismos Gerais

Prov� coment�rios suplementares, informa��es ou sem�ntica sobre os elementos dos modelos.

A UML utiliza alguns mecanismos para tratar de informa��es adicionais, sendo um ponto de extens�o da linguagem.

Esses mecanismos s�o:

• Nota: � apenas um s�mbolo para representar restri��es e coment�rios anexados a um elemento. Geralmente usa-se a nota para aprimorar os diagramas. Graficamente � representada por um ret�ngulo com um dos cantos com uma dobra na p�gina.
• Ornamento: � algo como uma nota que adiciona texto ou algum elemento gr�fico ao modelo.

Diagramas

Os diagramas (gr�ficos que descrevem o conte�do em uma vis�o) s�o utilizados para modelar os projetos de sistemas, s�o divididos, basicamente, em:

• Diagramas Estruturais: diagrama de classes, diagrama de objetos, diagrama de componentes e diagrama de disponibiliza��o.
• Diagramas de Comportamento: diagrama de casos de uso, diagrama de seq��ncia, diagrama de atividades, diagrama de colabora��o e digrama de estados.
• Diagramas de Gerenciamento do Modelo: pacotes, subsistemas e modelos.

Tipos de Diagramas:

Diagrama de Casos de Uso

Serve para visualizar os relacionamentos entre os atores e os casos de uso do sistema (cen�rios), numa vis�o geral.

Na figura 11 temos dois atores representados por bonequinhos, o usu�rio e o administrador, um ator pode ser conectado a um ou mais casos de uso, neste caso o usu�rio est� conectado a tr�s casos de uso e o administrador a dois casos de uso. Os casos de uso s�o representados por elipses e elas tamb�m podem se conectar entre si utilizando extend e include, neste caso representados pelos casos de uso Busca CD e Busca Livro que fazem extend com Busca de produtos e o Caso de Uso Finalizar Compra faz um include com Baixa de estoque.

Diagrama de Atividades

Diagramas de atividade capturam a��es e seus resultados. Eles focam o trabalho executado na implementa��o de uma opera��o (m�todo), e suas atividades numa inst�ncia de um objeto. O diagrama de atividade � uma varia��o do diagrama de estado e possui um prop�sito um pouco diferente do diagrama de estado, que � o de capturar a��es (trabalho e atividades que ser�o executados) e seus resultados em termos das mudan�as de estados dos objetos.

A figura 12 mostra o fluxo de controle. As atividades s�o representadas como ret�ngulos com cantos arredondados (Login Usu�rio, Sele��o dos produtos ...). Tipicamente as atividades s�o estados de a��o � estados que transitam para outro estado, assim que a a��o tenha sido completada. Este diagrama pode ser usado em qualquer n�vel: fluxo dos casos de uso, fluxo no n�vel de programa��o fluxo das regras de neg�cio, etc.

Diagrama de Classes

Mostra a estrutura est�tica do modelo da aplica��o. Este diagrama exibe as classes do sistema e o grau do relacionamento entre elas.

Na figura 13 a classe Produto faz uma agrega��o de composi��o com a classe ItemPedido, ou seja um depende do outro para continuar existindo. As classes CD e Livro herdam (generaliza��o) da classe Produto. A classe ItemPedido faz uma agrega��o com a Classe Pedido um Pedido pode ter v�rios ItenPedido, e por fim a classe Venda faz uma associa��o a classe Pedido.

Diagrama de Objetos

O Diagrama de objetos � muito similar ao Diagrama de classes e utiliza quase a mesma nota��o.

Na figura 14 o diagrama mostra uma �fotografia� dos objetos existentes em um determinado momento na execu��o do sistema. Pedido1 faz agrega��o com item1 e item2, o pedido � parte ou est� contido nos itens 1 e 2. Os itens 1 e 2 fazem agrega��o de composi��o com CD e Prod1, ou seja um depende do outro.

Diagrama de Estados

O Diagrama de Estados serve para mostrar todos os estados poss�veis dos objetos de uma classe do modelo, e que eventos do sistema causam essas mudan�as de estado. N�o h� a necessidade de representar os estados dos objetos de todas as classes.

Na figura 15 o diagrama mostra o comportamento do objeto e suas a��es, bem como a seq��ncia de estados que o objeto assume ap�s est�mulos recebidos. O ret�ngulo com os cantos arredondados (novo, item adicionado e pedido fechado) s�o os estados do objeto, a seta que liga o estado origem ao estado destino (escolhe item e fechar) � o evento que provoca o novo estado.

Diagrama de Seq��ncia

Diagrama de Seq��ncia mostra a intera��o entre os objetos da aplica��o arranjados numa linha do tempo. S�o utilizados para descrever a seq��ncia de um fluxo ou caso de uso da aplica��o. S�o muito �teis para se levantar quais s�o os envolvidos no fluxo e definir a interface de alguns objetos.

Na figura 16 o diagrama descreve o que ocorre nos objetos participantes, ou seja, mostra as itera��es do objeto atrav�s dos m�todos buscaproduto, adicionarproduto, finalizarvenda e fecharpedido.

Diagrama de Colabora��o

O Diagrama de Colabora��o � semelhante ao Diagrama de Seq��ncia, mostrando a colabora��o din�mica entre os objetos, sem levar em conta a linha do tempo. Neste diagrama, al�m da troca de mensagens, pode-se perceber o relacionamento entre os objetos.

Na figura 17 o diagrama mostra a mensagem (adicionar produto) enviada de um objeto (Venda) para o outro (ItemPedido). A mensagem � representada por uma seta que mostra o nome, o par�metro e a sequ�ncia da mensagem.

Diagrama de Componentes

O Diagrama de Componentes mostra o lado funcional, expondo a rela��o entre seus componentes e suas depend�ncias.

Na figura 18 s�o relacionados os componentes de �software�, ou seja, o execut�vel e os softwares necess�rios, ou seja, mostra a depend�ncia funcional que as classes de um componente tem com as classes de outro.

Diagrama de Execu��o

Mostra o lado funcional, exibindo a arquitetura f�sica do hardware e do software do sistema.

Na figura 19 o diagrama mostra os componentes, estes significam objetos f�sicos que fazem parte do sistema, duas m�quinas (ClienteA e ClienteB), uma m�quina servidora (HP/UX), uma m�quina servidora de banco de dados (Oracle) e conex�es entre estes componentes que juntos comp�em toda a arquitetura f�sica do sistema.

Conclus�o

Embora a UML forne�a um conjunto consider�vel de diversos diagramas que ajudam a definir uma aplica��o, de modo algum � uma lista completa de diversos diagramas �teis que voc� poderia querer usar. Em muitos lugares, diferentes diagramas podem ser �teis, e voc� n�o deve hesitar em us�-los.

N�o se pode examinar um diagrama UML e dizer exatamente como seria o c�digo equivalente. Entretanto, voc� pode ter uma id�ia aproximada de como ficaria o c�digo. Na pr�tica isso � suficiente para ser �til.

A UML tamb�m � utilizada na atividade de an�lise de requisitos para descobrir o que usu�rios e clientes de um produto de software querem que o sistema fa�a, algumas t�cnicas de UML s�o �teis como: casos de uso, diagrama de classes, diagrama de atividades, dentre outros.

Confira outros conte�dos: