Modeling « Desenvolvedores.Net

Para um melhor entendimento deste Artigo veja o Índice (UML)

Ao desenvolvermos um sistema complexo temos a necessidade de enxergar o sistema, para nos auxiliar podemos dividir o sistema em diversos aspectos:

Funcional

Estruturas estáticas e as interações dinâmicas;

Não funcional

Tempo, confiabilidade, desenvolvimento;

Organizacional

Trabalho, mapeamento, código;

O sistema pode ser descrito em várias visões, cada uma mostrando particularidades do sistema, estas visões podem estar ligadas entre si pelos diagramas.

A figura no começo do artigo mostra as cinco visões da UML que iremos abordar.

Visão de Caso de Uso

Esta visão descreve a funcionalidade que o sistema irá fornecer. É destinada aos usuários, analistas, projetistas, desenvolvedores, e equipes de testes. É de grande importância porque o seu conteúdo irá acionar o desenvolvimento de outras visões. Tenha sempre em mente que esta visão deverá ser tecnologicamente neutra e focalizar o “que” e não o “como“.

Utiliza os digramas de:

Casos de uso

Visão Lógica

Esta visão irá descrever como será fornecida a funcionalidade, destinada principalmente aos projetistas e desenvolvedores.

Esta visão descreve a estrutura estática (classes, objetos e relacionamentos) e as dinâmicas que ocorrem na aplicação.

As tabelas, relacionamentos, classes , propriedades, métodos devem ser descritos nesta visão.

Utiliza os diagramas de:

Visão de Processo

Nesta visão descrevemos o sistema em processo, esta divisão permite o uso eficiente de recursos, a manipulação síncrona e assíncrona dos eventos. É destinada aos desenvolvedores.

Utiliza os diagramas de:

Visão de Implementação

A visão de implementação descreve os módulos e suas dependências. Estes módulos podem proporcionar a verificação cruzada para outros produtos garantindo que todos os requisitos estejam eventualmente atualizados. É destinada aos desenvolvedores.

Utiliza os diagramas de:

Componente

Visão de Implantação

Esta visão descreve a disponibilidade física do sistema e recursos que o sistema ira utilizar. Descreve toda a estrutura onde o sistema é instalado. É destinada aos desenvolvedores, equipe de suporte, de testes e equipe de instalação.

Utiliza os diagramas de:

É isso ai pessoal
Até o próximo
♦ Marcelo

: Language, Modeling, UML, Unified, visions, visões

About Marcelo

Nascido em Juruaia/MG em uma fazenda de criação de búfalos. Está perdido em São Paulo trabalhando com desenvolvimento de aplicações desde os 17 anos. Atualmente é arquiteto de software, é um cara meia boca que fica entre a equipe de desenvolvimento e o gerente de projetos, no meio da ponte. Para saber mais ... http://desenvolvedores.net/marcelo []'s

Outros Diagramas da UML

(1 votos, média: 5,00 de 5)

Loading ...

13 de julho de 2011

Para um melhor entendimento deste Artigo veja o Índice (UML)

Diagrama de Estrutura Composta

Este diagrama é utilizado para modelar Colaborações. Uma colaboração descreve uma visão de um conjunto de entidades cooperativas interpretadas por instâncias que cooperam entre si para executar uma operação específica. Este diagrama também pode ser utilizado para definir a estrutura interna de um classificador. Este é um dos novos diagramas propostos pela UML 2.0.

Diagrama de Comunicação

Este diagrama era conhecido como Diagrama de Colaboração até a versão 1.5 da UML,tendo o seu nome modificado para Diagrama de Comunicação a partir da versão 2.0 e está amplamente associado ao Diagrama de Seqüência, na verdade, um complementa o outro. As informações mostradas no Diagrama de Comunicação são, com freqüência, praticamente as mesmas apresentadas no Diagrama de Seqüência, porém com um enfoque diferente, visto que este diagrama não se preocupa com a linha de tempo do processo, concentrando-se em como os objetos são vinculados e quais mensagens trocam entre si durante o processo.

Diagrama de Interação Geral

Este diagrama é uma variação do Diagrama de Atividade que fornece uma visão geral dentro de um sistema ou processo de negócio. Esse diagrama passou a existir somente a partir da versão 2.0 da UML e costuma englobar diversos tipos de diagramas de interação para demonstrar um processo geral.

Diagrama de Tempo

Este diagrama descreve a mudança no estado ou condição de uma instância de uma classe ou seu papel durante um tempo. Tipicamente utilizado para demonstrar a mudança no estado de um objeto no tempo em resposta a eventos externos. Este é o terceiro diagrama criado a partir da nova versão da linguagem.

É isso ai pessoal
Até o próximo
♦ Marcelo

: Communication, Composite, Diagrama de Comunicação, Diagrama de Tempo, Diagrama Estrutura Composta, Interação Geral, Interaction Overview, Language, Modeling, Strucutre, Timing, UML, Unified

About Marcelo

Diagrama de Implantação (UML)

(1 votos, média: 1,00 de 5)

Loading ...

12 de julho de 2011

Para um melhor entendimento deste Artigo veja o Índice (UML)

O diagrama de implantação representa a configuração e a arquitetura do sistema em que estarão ligados os respectivos componentes.

Neste diagrama também podemos representar toda a estrutura de hardware e requisitos mínimos onde o sistema será executado

Características do Diagrama

Pode representar a estrutura da plataforma em que será utilizado;
Pode representar bancos de dados, Componentes de Terceiros;
Pode representar os servidores, a rede;
Pode representar a configuração dos equipamentos;

Este diagrama não é específico do desenvolvedor, mas em uma equipe onde existe o responsável pela implantação do sistema, este deve estar preocupado com o hardware e a configuração em que o sistema deverá ser executado e a compatibilidade entre os dois.

Os Diagramas de Implantação também podem ser usados para especificar os módulos do sistema que deverão ser instalados no cliente.

Como Fazer:

Identifique os dispositivos e o ambiente que a aplicação deverá ser executada;
Se for possível utilize alguma ferramenta para descobrir a configuração adequada de hardware;
Se a instalação ficar complexa crie mais de um diagrama, cada um focando em um determinado ponto da instalação;
Utilize as notas para explicar melhor cada passo do diagrama;

É isso ai pessoal
Até o próximo
♦ Marcelo

: Diagrama Implantação, Language, Modeling, UML, Unified

About Marcelo

Diagrama de Pacote (UML)

(1 votos, média: 5,00 de 5)

Loading ...

29 de junho de 2011

Para um melhor entendimento deste Artigo veja o Índice (UML)

Os diagramas de pacotes ou diagrama de módulos, organizam os modelos criados, todos os blocos , casos de uso, classes, componentes, etc. Estes diagramas podem ser organizados em pacotes. (namespace em .net ou package em java).

Deve-se fazer a organização dos pacotes observando a semelhança de cada diagrama e no que diz respeito à solução do problema que cada um está sendo empregado.

Neste diagrama podemos representar a dependência entre os módulos do sistemas, isso quer dizer que pacotes podem depender de outros pacotes.

Exemplo de uma diagrama de pacotes:

Como Fazer:

Identificar objetos semelhantes;
Nomear os pacotes (módulos);
Definir os nomes dos pacotes;

É isso ai pessoal
Até o próximo
♦ Marcelo

: Diagrama Pacote, Language, Modeling, Package Diagram, UML, Unified

About Marcelo

Diagrama de Atividade (UML)

(Sem votação.)

Loading ...

20 de junho de 2011

Para um melhor entendimento deste Artigo veja o Índice (UML)

No diagrama de atividades podemos representar as ações que são executadas. Podemos documentar os métodos que iremos escrever na instância de um objeto.

Os estados no diagrama de atividades mudam quando uma ação é executada, estes estados podem ser representados com swimlanes.

* Uma swimlane agrupa a atividade e as organizam de acordo com suas responsabilidades. São representadas por retângulos que englobam os objetos que estão ligados a atividade.

Abaixo uma imagem de exemplo da swimlane

Os diagramas de atividade representam o fluxo das informações dentro de um objeto do sistema, podemos representar as condições e as execuções paralelas.

O propósito do digrama de atividades e focar no fluxo do sistema e descrever o processamento interno e paralelo. Podemos comparar o diagrama de atividades ao antigo fluxograma.

Exemplo de um diagrama para “Fritar um Ovo”:

Definições:

Atividade

Representa a execução de alguma coisa, uma método, uma rotina, um trabalho, etc.

Separação

Representa as execuções paralelas, têm uma entrada e podem ter várias saídas.

Junção

Usamos a junção para unir as saídas de duas ou mais separações.

Desvio

É a representação de uma única entrada em várias saídas. É um tipo de comportamento condicional.

Intercalação

Ao contrário do desvio aqui temos várias entradas com uma única saída.

Início

Marca o início das atividades no diagrama.

Marca o fim das atividades no diagrama.

Como Fazer:

Identificar os cenários;
Modelar a parte básica;
Modelar as junções, decisões, separações. Se houver;
Se houver a necessidade, organizar com o uso de swimlanes;

É isso ai pessoal
Até o próximo
♦ Marcelo

: Diagrama de Atividade, Language, Modeling, UML, Unified

About Marcelo

Diagrama de Estado (UML)

(3 votos, média: 5,00 de 5)

Loading ...

7 de junho de 2011

Para um melhor entendimento deste Artigo veja o Índice (UML)

Podemos ver o diagrama de estados como um complemento para o diagrama de classes. Neste diagrama podemos mostrar qual o estado em que o nosso objeto esta naquele momento. O diagrama de estado deve ser construído para os objetos que tem seus estados definidos e onde o comportamento do objeto muda por causa de um determinado estado.

Podemos representar aqui o ciclo de vida dos objetos e como são afetados pelos eventos (erros, mensagens, condições).

Os diagramas de estado começam com um estado inicial (um circulo preto todo preenchido) e podem ter várias saídas (um circulo com um X) ou fins (Um circulo com outro circulo menor preenchido).

Vamos pensar em um objeto que faz pedidos de venda. Este objeto pode ter vários estados:

Em Análise de Crédito;
Crédito Aprovado;
Crédito não aprovado;
Aguardando Liberação;
Pedido Entregue;
Cancelado;

Neste caso teremos que representar também algumas condições e transições de um estado para outro. Vamos ver como fica nosso diagrama

Características Principais

Demonstrar os estados possíveis de um objeto;
Demonstrar a transição de um objeto para outro;
Ajudam a visualizar a complexidade do sistema de forma simples;

Como fazer

Defina o objeto que irá representar;
- Aqui podemos usar os diagramas de interação para nos ajudar
Defina os eventos e estados que o objeto vai ter;
Estabeleça o início e fim do seu objeto;
Estabeleça os estados de seu objeto, se possível na ordem em que acontecem;

É isso ai pessoal
Até o próximo
♦ Marcelo

: Diagrama Objetos, Language, Modeling, UML, Unified

About Marcelo

Diagrama de Sequencia (UML)

(Sem votação.)

Loading ...

6 de junho de 2011

Para um melhor entendimento deste Artigo veja o Índice (UML)

Os diagramas de sequencia dão ênfase à sequencia lógica em que as mensagens são trocadas.

Os diagramas de colaboração dão ênfase a ordenação estrutural em que os objetos se colaboram.

Para facilitar o entendimento iremos ver os dois em detalhe abaixo.

Diagrama de Sequencia

Usamos o diagrama de sequencia para modelar a interação entre os objetos e normalmente estão associados a apenas um caso de uso.

Este diagrama mostra a colaboração dinâmica de vários objetos, com isso podemos ver a execução de um ponto específico da aplicação.

O diagrama de sequencia possui dois eixos, horizontal que mostra os objetos envolvidos e o eixo vertical que mostra o tempo em que a ação acontece, este tempo é representado por uma linha tracejada a qual chamamos de linha de vida.

Para visualizar o tempo olhamos o diagrama de cima para baixo.

Os objetos são representados por ícones no topo do diagrama e as setas representam as direções das mensagens.

Os diagramas de sequencia podem representar objetos que são criados ou destruídos no decorrer da aplicação.

Podem representar acessos concorrentes (threads).

Vejamos um diagrama de Exemplo:

Este diagrama representa um processo simples de saque. Desde a inserção do cartão até o momento em que é gravado pelo banco.

Diagramas de Colaboração

Os diagramas de colaboração, diferente dos diagramas de sequencia que focam na ordem cronológica, focam no relacionamento dos objetos e em sua compreensão. São ligados por associações (veja: Tipos de Relacionamento) cada associação representa uma mensagem e são marcadas com números para vermos sua sequencia.

O diagrama de colaboração é semelhante ao de sequencia, ambos mostram a colaboração dinâmica entre os objetos. Não precisamos usar os dois diagramas, algumas dicas que poderão ajudar a identificar qual usar:

Se a necessidade for usar um diagrama para mostrar uma sequencia cronológica utilize o diagrama de sequencia;
Se a necessidade for mostrar o contexto prefira o diagrama de colaboração;
Prefira os diagramas de sequencia para cenários complexos;
Utilize o diagrama de colaboração para cenários mais simples.

Exemplo de um diagrama de Colaboração:

Vimos aqui que os diagramas de sequencia e colaboração formam o diagrama de interação, eles representam a dinâmica de um sistema.
Os objetos colaboram entre si a partir da interação existente entre os atores e o sistema. A partir de eventos gerados teremos as operações, podemos dizer que os eventos são estímulos gerados e as operações as respostas à estes estímulos.

Características dos diagramas de interação

Representam a dinâmica de um sistema;
Representam as colaborações e comportamentos entre os objetos;
Simplicidade, pois as mensagem podem ser “lidas” ao observar os diagramas;
Representam a “ordem” que as coisas acontecem;
Possui dois diagramas para representar as interações;
Podemos ver os passos gerados para cada cenário;
As operações de cada sistema e sua importância;

Como fazer

Defina o caso de uso que deseja representar;
Define quais serão os comportamentos que você irá representar;
Crie notas para deixar a descrição de seus diagramas mais informativas;
Defina seus relacionamentos;
Defina a ordem em que acontecem os eventos;

É isso ai pessoal
Até o próximo
♦ Marcelo

: Diagrama de Colaboração, Diagrama de Interação, Diagrama de Sequencia, Language, Modeling, UML, Unified

About Marcelo

Diagrama de Objeto (UML)

(1 votos, média: 5,00 de 5)

Loading ...

28 de maio de 2011

Para um melhor entendimento deste Artigo veja o Índice (UML)

O diagrama de objetos é uma variação do diagrama de classes. A diferença é que neste diagrama você pode colocar os nomes reais aos seus objetos. O diagrama de objetos não é tão importante quanto o de classes, mas ele vai ajudar a exemplificar um diagrama de classes muito complexo.

Por exemplo, uma pessoa física que se chama Marcelo, você pode definir um objeto “Marcelo” e representar ele aqui.

Tecnicamente podemos dizer que o diagrama de objetos representa uma instância da classe.

Os diagramas de objetos têm seu nome sublinhado e todos os seus relacionamentos são mostrados. Seus nomes vêm separados das classes que ele representa por “:” (dois pontos).

Ex: Marcelo:Pessoa

Os diagramas de objetos são importantes para visualizar, especificar e documentar os modelos estruturais, assim como aspectos dentro de um sistema.

Exemplo de um diagrama:

Como fazer:

Escolha o cenário que deseja representar (casos de uso);
Identifique as classes (diagrama de classes);
Defina os relacionamentos entre os objetos (tipos de relacionamento);
Defina os nomes e valores para os atributos de seu objeto;

É isso ai pessoal
Até o próximo
♦ Marcelo

: Diagrama Objetos, Language, Modeling, UML, Unified

About Marcelo

Diagrama de Caso de Uso (UML)

(Sem votação.)

Loading ...

12 de maio de 2011

Para um melhor entendimento deste Artigo veja o Índice (UML)

O Diagrama de Caso de Uso descreve a funcionalidade proposta para um novo sistema, que será projetado.
Segundo Ivar Jacobson, podemos dizer que um Caso de Uso é um “documento narrativo que descreve a sequência de eventos de um ator que usa um sistema para completar um processo”.

Caso de uso é representado por uma elipse, com o nome do caso de uso dentro ou abaixo.
Se há limites do sistema no diagrama, o caso de uso deve ficar dentro.

Os casos de Uso são tipicamente relacionados a “atores”. (Iremos ver a definição de “ator” abaixo.)

Imaginem o caso de uso como um palco de teatro, onde vocês têm o cenário e seus atores, cada um executando uma ação com o cenário a sua volta.
O palco (limite) seria a parte do sistema em que o cenário se encaixa.

Use os casos de uso para descrever o sistema e como ele executa a ação, utilize uma linguagem simples e objetiva.

Algumas regras para fazer um bom caso de uso:

Um caso de uso sempre se inicia por um “Ator”.
Um caso de uso deve oferecer possíveis situações do mundo real para testes do sistema.
Um caso de uso deve ser completo.
Um caso de uso deve ser uma descrição completa do sistema, o mesmo não estará completo até que o valor final seja produzido.

Para identificar os casos de uso devemos fazer algumas perguntas:

O ator precisa ler, modificar, alterar alguma informação no sistema?
O trabalho do ator pode ser facilitado, simplificado com o uso de mais funções no sistema?
O ator tem que receber ou enviar notificações ao sistema?
Quais as funções que o ator precisa do sistema?
O que o ator precisa fazer?
Quais os problemas com a implantação atual?

Ator

Especifica um papel executado que interage com o cenário (caso de uso).

Um ator deve ter associações exclusivamente para casos de uso.
A exceção é um ator que possa herdar o papel de outro.

Um ator é representado por um boneco (stick man).

Um ator pode ser um usuário, um humano, uma máquina,hardware, uma aplicação. Um ator deve representar uma interação com o sistema.

Para identificar um ator de um sistema podemos fazer as seguintes perguntas:

Quem está interessado na exigência?
O sistema usa um recurso externo?
Quem fornecer a informação irá usar e modificar, ou às removerá?
Uma pessoa representa um papel?
O sistema interage com um sistema legado?

Interação em caso de uso

O ator comunica-se com o sistema através do envio e recebimento de mensagens.

Um ator comunica-se com o caso de uso, esta comunicação e mostrada conectando-se o símbolo do ator ao símbolo do caso de uso por um caminho sólido.

Tipos de relacionamento

Uso <<use>>

Quando os casos de uso têm um comportamento comum eles podem ser modelados em um simples caso de uso que é utilizado por outro caso de uso. Ocorre quando há uma parcela de comportamento similar sugerindo um reutilização.

Inclusão <<include>>

No relacionamento de inclusão, o cenário mais comum é quando existem dois casos de uso que serão utilizados em um caso de uso base, para que outros casos de uso utilizem estes serviços.

Desta forma evita-se descrever a mesma seqüência em casos de uso que usam outros casos de uso.

Extensão <<extend>>

Extensões são usadas para mostrar um comportamento semelhante, mas com alguma particularidade. (Especialização e Generalização).

Como fazer um bom caso de uso

Eu tenho uma receita que costumo seguir para montar os meus casos de uso.
Vou passá-la a vocês, mas com o tempo vocês irão melhorar a receita ou adequar às suas necessidades.

Passo 1: Identificação dos atores

- Listar os atores;
- Nomear os atores, dê nomes reais “Sr. João” , “Impressora HH900″, “CGQ”;
- Descrever o papel de cada ator;

Passo 2: Identificação dos Cenários (Casos de Uso)

- Listar os casos de uso;
- Nomear os casos de uso (verbos);
- Descrever os casos de uso;

Passo 3: Definir as interações (Atores x Casos de Uso)

- Descrever as interações;
- Analisar os estereótipos dos relacionamentos
  <<include>>, <<use>>, <<extend>>)

Passo 4: Montar o diagrama

- Desenhe o diagrama;
- Descreva o diagrama;

Passo 5: Estabelecer as ligações

- Agrupe pelo tipo de cenário;

Conclusão

Eu considero os casos de uso o principal diagrama para um bom desenvolvimento e documentação de um sistema.

Devemos detalhar todos os casos de uso, sem economizar nas descrições, estas devem ser em uma linguagem simples e objetiva para que o cliente e o desenvolvedor possam falar o mesmo idioma, pois o seu cliente pode não entender os termos técnicos que você usa, assim como você pode não entender os termos que ele usa.

É isso ai pessoal
Até o próximo
♦ Marcelo

: Casos de Uso, extend, include, Language, Modeling, UML, Unified, use, Use Case

About Marcelo

Diagramas – Visão Geral (UML)

(Sem votação.)

Loading ...

1 de maio de 2011

Para um melhor entendimento deste Artigo veja o Índice (UML)

Os diagramas da UML são a representação gráfica de um sistema, seja em parte ou o todo.

A UML disponibiliza 13 diagramas para representar ou visualizar um modelo de sistema, estes diagramas são classificados como:

Estáticos

Representam a estrutura estável de um sistema. São os diagramas de Casos de Uso, Classe, Objeto, Pacotes.

Dinâmicos

Representam as partes de um sistema que podem sofrer alguma alteração. São os diagramas de Atividade, Colaboração, Seqüência, Estado, Casos de Uso (O diagrama de caso de uso pode ser estático ou dinâmico), Temporização.

Arquitetônicos

Representam as partes reais de um sistema. São os diagramas de Componentes e Implantação

Os 13 diagramas da uml são:

Casos de Uso, Classes, Objetos, Estrutura Composta, Seqüência, Comunicação , Máquina De Estados, Atividades, Interação Geral, Componentes, Pacotes, Implantação, Temporização

No decorrer do artigo iremos ver em detalhes estes diagramas.

Se você ainda não leu sobre os relacionamentos entre os objetos e a extensibilidade da UML, recomendo antes de continuar a ler sobre os diagramas.

1. Relacionamentos

2. Extensibilidade

É isso ai pessoal
Até o próximo
♦ Marcelo

: Geral

: Language, Modeling, UML, Unified

About Marcelo

Extensibilidade (UML)

(Sem votação.)

Loading ...

23 de abril de 2011

OCL (Object Constraint Language) (176)

Para um melhor entendimento deste Artigo veja o Índice (UML)

A UML é um padrão de modelagem de sistemas orientado a objetos. Apesar da padronização já definida, a UML oferece uma forma de expressar em nossos modelos regras e tipos definidos por nós.

À estas formas damos dois nomes, Estereótipos e Restrições (Constraint).

Estereótipos

Os estereótipos são usados para classificar os elementos que não foram padronizados pela UML e para representar problemas específicos. São representados entre os sinais de maior e menor duplos <<estereótipo>>.

Abaixo uma lista dos estereótipos mais comuns:

Para relacionamentos;
Para classes;
Para atributos e operações;
Para eventos e mensagens;
Para componentes;
Outros …

Os estereótipos podem ser traduzidos para o português, não existe uma restrição quanto ao idioma utilizado

Se a ferramenta CASE utilizar o estereótipo para gerar o código fonte é necessário especificar o idioma que iremos utilizar.

Abaixo alguns diagramas que usam estereótipos:

Casos de Uso:

Tipos definidos:

Tabela:

Restrições (Constraint)

As restrições são regras que podemos aplicar aos elementos, podemos usar para especificar uma regra de negócio, um tipo de relacionamento, como uma ação deve ser executada.

Uma restrição de regra seria por exemplo:

Um funcionário tem que ter salário.
Um carro tem que ter motorista para andar.

As restrições são escritas entre chaves {restrição}.

Alguns diagramas de exemplos:

OCL (Object Constraint Language)

Eu ia falar sobre OCL, mas encontrei na internet um artigo em PDF muito bom sobre OCL, e creio que ele explica muito bem o que é a OCL.

Segue o link para download

É isso ai pessoal
Até o próximo
♦ Marcelo

: Documentação, UML

: constraint, estereótipo, Extensibilidade, Language, Modeling, Object Constraint Language, OCL, restrições, UML, Unified

About Marcelo

Tipos de Relacionamento (UML)

(5 votos, média: 5,00 de 5)

Loading ...

14 de abril de 2011

Para um melhor entendimento deste Artigo veja o Índice (UML)

Neste artigo irei abordar os tipos de relacionamento que a UML tem.

Os relacionamentos ou associações definem as dependências e ligações entre as classes, objetos, pacotes, tabelas, entre outros que iremos ver no decorrer do artigo.

Vamos à eles:

Associação

É uma conexão entre as classes , tabelas e objetos. Um relacionamento.

Em UML uma associação representa um relacionamento que descreve as ligações entre os objetos ligados.

Uma associação deve ter sempre duas pontas, onde uma é o objeto de início e a outra o objeto final.

Uma associação pode representar a multiplicidade entre os objetos. Podemos ter as seguintes representações de multiplicidade:
0 (zero)
1 (um)
0…1 (zero ou um)
0…* (zero ou mais)
1…* (um para muitos)
* (muitos)

Por exemplo, podemos pegar uma Nota Fiscal e seus Itens.

Uma nota fiscal, vários itens.

As associações podem ser:

Normais:
- É o tipo mais comum, é representada por uma linha sólida entre as classes. Possui um nome em cada ponta que identifica o que cada uma representa, normalmente é um verbo. Mas fica a critério de cada um para facilitar o entendimento.
Recursiva:
- Indica que uma classe pode conectar-se a ela mesma. Por exemplo. Pegamos o objeto Pessoa. Ele é um objeto que pode ser um Pai, um Filho, um Fornecedor, um Cliente, um Usuário. Mas todos estes são “Pessoas”.

Um outro exemplo pode ser um plano de contas, onde podemos ter:

Fornecedor
    |----> Água;
    |----> Luz;
Receitas
    |----> Vendas
    |----> Serviços
Despesas
    |----> Financeiras
    |----> Funcionários

Neste caso podemos estar colocando todos dentro do mesmo objeto e definir o “pai” como o nível superior de cada conta.

Exclusiva:
- Em alguns momentos precisamos representar que um objeto pode participar apenas de um tipo em determinado momento.
- Uma associação exclusiva é representada por um linha tracejada entre as associações, entre elas existe a especificação {ou}.
- Abaixo um exemplo. A pessoa não pode ser Jurídica e Física ao mesmo tempo.
Qualificada:
- As associações qualificadas representam as ligações de 1…* (um para muitos) ou * (muitos).
  O “qualificador” identifica no final da associação qual o objeto está identificado.

Agregação

A agregação é um tipo de associação onde o todo está relacionado com suas partes. É representada com o símbolo de um diamante junto a classe agregadora.

Composição

A composição é muito semelhante a agregação, o objeto “Parte” pode pertencer somente ao objeto “Todo” e normalmente o objeto “Todo” vive e morre com suas “Partes”.

É representada pelo símbolo de um diamante preto na classe agregadora.

Generalização

Generalização é a capacidade de identificar as similaridades entre várias classes, com isso criamos um supertipo que encapsula todas as funcionalidades comuns as demais classes filhas.

Podemos usar a generalização para agrupar os nossos objetos em um tipo comum.

Especialização

A especialização cria uma classe herdada da generalização onde refina o processo definido na classe pai. Como o próprio nome diz, especializa a classe pai para um tipo específico.

Usando a mesma imagem acima da generalização, podemos identificar quem é a generalização “subindo” e quem é a especialização “descendo”.

Realização

A realização é um relacionamento entre os itens que implementa o comportamento especificado por outro.
Um exemplo disso seria as classes abstratas e as interfaces que definem que o objeto “filho” deverá realizar alguma método, propriedade no momento da herança.

Dependência

Este é simples é um item (objeto) que depende de outro.

Com isto finalizamos este tópico, mas ainda temos muita coisa para ver.
Eu recomendo a leitura de alguns artigos sobre Programação Orientada à Objetos para fixar a idéia e ver a aplicação do que foi aprendido.

É isso ai pessoal
Até o próximo
♦ Marcelo