Linguagem de modelagem unificada

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Linguagem de modelagem unificada
Introdução
Você já ouviu falar em UML? Sabe seu significado ou para que serve?
A UML (Unified Modeling Language) – Linguagem de Modelagem Unificada – é uma linguagem padrão para modelagem orientada a objetos. No entanto, essa linguagem de modelagem não é um método de desenvolvimento.
A UML tem como objetivo auxiliar a visualização do desenho e a comunicação entre objetos. Nesse sentido, a UML permite que desenvolvedores visualizem o produto criado em diagramas padronizados.
Histórico
A UML foi desenvolvida por James Rumbaugh, Ivar Jacobson e Grady Booch. Esses três autores já haviam desenvolvido a modelagem de sistemas grandes e complexos de modo separado e com características próprias: OMT, OOSE e BOOCH respectivamente. Vejamos, a seguir, como ocorreu a evolução da UML. 
Atualmente, a UML é aceita como a documentação oficial de um projeto. Ao longo deste curso, no entanto, vamos descobrir que a UML é muito mais do que a padronização de uma notação.
A UML representa o desenvolvimento de novos conceitos, como a programação orientada a objetos.
Desse modo, entender a UML não é apenas aprender a simbologia de seus gráficos e casos de uso.
Entender a UML é aprender a modelar sob a ótica da programação orientada a objetos em seu conceito mais puro.
Mais adiante, veremos como a UML traduz o conceito estático e dinâmico de um sistema a ser analisado. Para isso, já no início do desenvolvimento, a UML leva em consideração as futuras mudanças que podem ocorrer em relação à utilização de alguns fatores. Clique nas letras para conhecê-los.
U - Pacotes – componentes
M - Banco de dados
L - Especificações que o sistema a ser desenvolvido deve conter
Objetivos da UML
Você já conseguiu descobrir quais são os objetivos da UML? Clique nos números para conhecê-los.
Modelar sistemas por meio dos conceitos da programação orientada a objetos.
Estabelecer uma união para que os métodos conceituais sejam práticos e executáveis.
Desenvolver uma linguagem de modelagem que possa ser utilizada tanto pelo usuário quanto pelo equipamento.
O uso da UML, por sua vez, irá variar de acordo com os objetivos de cada sistema. Vamos entender melhor os diferentes usos da UML?
Usos da UML
A UML pode ser utilizada na elaboração de vários tipos de sistemas.
Por meio dos diagramas, a UML é capaz de abordar sistemas com quaisquer características. Além disso, é utilizada nas variadas etapas de construção de um sistema – desde o levantamento e a concepção detalhada da análise de requisitos, até a sua conclusão, com a etapa de testes e homologação.
O propósito da UML é relatar diversos tipos de sistemas relacionados a diagramas orientados a objetos. Desse modo, sua utilização mais frequente envolve a elaboração de modelos de sistemas de software.
No entanto, a UML também é empregada na representação de sistemas mecânicos, industriais ou de negócios, sem a necessidade de nenhum tipo de programação envolvida.
Usos da UML
Clique nas imagens a seguir para conhecer os diferentes tipos de sistemas que utilizam a UML e a função de cada um deles.
Sistemas de informação Usados para consultar, editar, alterar, arquivar e apresentar dados e informações. Além disso, têm a função de conservar quantidades elevadas de dado se informações armazenadas em bancos de dados relacionais ou orientados a objetos.
Sistemas de suporte técnico Usados para conservar e supervisionar equipamentos técnicos vitais, como equipamentos de telecomunicações. Normalmente, são sistemas real-time, com interfaces e programações próprias do equipamento.
Sistemas distribuídos Usados para compartilhar facilmente dados e informações entre um equipamento e outro. Por conta desse compartilhamento, necessitam de mecanismos de comunicação confeccionados em mecanismos de objetos de modo geral. Para isso, os mecanismos precisam estar sincronizados, assegurando a integridade dos dados.
Sistemas de software Usados para estabelecer uma estrutura técnica empregada por outros softwares, como sistemas operacionais e bancos dedados. Usados também em procedimentos de operações de empresas em conjunto com ações de usuários. Isso ocorre por meio de interfaces abrangentes ou procedimentos de baixo nível no hardware – linguagem de máquina.
Sistemas de negócios Usados para relatar os detalhamentos – usuários e equipamentos, por exemplo –,as regras – legislações, estratégias de negócio etc. – e o efetivo trabalho desenvolvido em cima dos processos do negócio.
As técnicas da UML não são utilizadas exclusivamente na informática. Tais técnicas servem para descrever quaisquer ações e processos que necessitem ser analisados, detalhados e documentados.
As técnicas da UML não são exclusivas para a informática, e servem para descrever quaisquer ações e processos que necessitem ser analisados, detalhados e documentados, como é o caso dos diversos sistemas apresentados. Dessa forma, os sistemas:
de informação são usados para consultar, editar, alterar, arquivar e apresentar dados e informações.
distribuídos são usados para compartilhar facilmente dados e informações de um equipamento a outro.
de negócios são usados para relatar os detalhamentos, legislações, estratégias de negócios etc.
de suporte técnicos são sistemas real-time, com interfaces e programações próprias do equipamento.
As técnicas da UML não são exclusivas para a informática. Essa linguagem não é considerada um método de desenvolvimento. Ela serve para descrever quaisquer ações e processos que necessitam ser analisados, detalhados e documentados. Além disso, pode ser utilizada para conhecer sistemas de informação, sistemas de suporte técnico, sistemas distribuídos, sistemas de software e sistemas de negócios.
Fases do Desenvolvimento de um Sistema em UML
Para que um sistema de software seja desenvolvido, é necessário passar por cinco fases até o resultado final. Vejamos:
A execução das fases segue uma ordem definida e obrigatória, pois não há como realizar testes se as fases de Design e Programação não foram finalizadas. Da mesma forma, não há como executar a etapa de Design e Programação se as fases de Análise de Requisitos e Análise do Sistemas não foram concebidas.
Essa é uma prática comum nas corporações. Dessa maneira, as falhas detectadas em uma fase podem ser corrigidas, alteradas e aprimoradas nas fases confeccionadas anteriormente.
O resultado final é um sistema de alto desempenho e qualidade. Desse modo, também é possível manter uma continuidade de desenvolvimento e melhorias do produto – próximas versões, documentação, alcance e maior complexidade.
Fases do Desenvolvimento de um Sistema em UML
A seguir, veremos cada uma das fases de desenvolvimento de um software, com detalhes, para entendermos como se dá um desenvolvimento em UML.
Antes disso, que tal termos uma visão geral de cada etapa? Essa visão geral irá nos ajudar a compreender melhor os detalhes de cada fase posteriormente.
Análise de requisitos
A análise de requisitos é o primeiro levantamento das intenções e necessidades dos usuários de um sistema. A partir dessa análise, serão elaboradas todas as demais necessidades do projeto, bem como os diagramas e os gráficos que permitirão uma análise detalhada do que cada processo ou ação vai executar.
Análise do sistema
A análise do sistema é o passo seguinte ao primeiro detalhamento de concepção do sistema. Devemos começar a pensar nas classes, nos objetos e nos mecanismos que irão solucionar um método ou uma ação. Os diagramas de use cases são ideais para esse detalhamento.
Design
Na fase de design, o projeto toma forma. Desse modo, são criadas as interligações com os vários sistemas.
Programação
Na fase da programação, o projeto é convertido para alguma linguagem de programação orientada a objetos (não devem ser utilizadas linguagens procedurais). É a fase de codificação das etapas anteriores (análise de requisitos, análise de sistema e design).
Testes
A fase de testes existe para que o resultado desejado, proveniente da relação
entre os requisitos analisados e a programação desenvolvida, seja alcançado. Para validar um sistema, é comum que sejam executados três processos de teste: teste unitário, teste de integração e teste de homologação (aprovação).
Fases do Desenvolvimento de um Sistema em UML
Preparado para conhecer os detalhes das fases de desenvolvimento de um software? Vamos lá!
No infográfico a seguir, clique em cada uma das fases para verificar o que é necessário para desenvolver um sistema em UML.
Fases do Desenvolvimento de um Sistema em UML
Estamos prestes a concluir o tópico. Antes disso, precisamos lembrar que é muito importante conhecer as cinco fases do desenvolvimento de um sistema UML:
Essas fases são atualizadas continuamente, para melhor refletirem o projeto final.
Na sequência, vamos pensar em um exemplo para o início do desenvolvimento de um sistema?
Exemplo
Imagine que você tenha sido convidado a participar do projeto de desenvolvimento da biblioteca virtual da escola onde estudava.
Como a escola não tem biblioteca virtual, você terá de partir do zero. Além disso, terá a responsabilidade de criar toda a documentação do projeto.
Qual deve ser o seu primeiro passo nesse caso?
O primeiro passo a ser dado envolve a análise de requisitos. É nesse momento que serão levantadas as intenções e necessidades dos usuários da biblioteca virtual.
Vamos ver como seria feito esse levantamento de requisitos?
Exemplo – Análise de Requisitos
O próximo passo é determinar o que vai fazer parte do sistema – precisamos pensar na concepção das classes e dos objetos que o constituirão.
Começamos identificando os principais elementos e entidades: atores, objetos e atributos.
Quem são os ATORES?
Eles seriam os primeiros a serem entrevistados para identificarmos os elementos que vão alimentar o sistema, certo?
Exemplo – Análise Macro da Análise de Requisitos
Uma vez consultados os atores, conseguimos identificar os objetos e atributos de nosso sistema.
A partir da definição dos atores, podemos traçar uma análise macro, definindo também os métodos (ações) envolvidos.
Atores: elementos que alimentam o sistema.
Objetos: elementos para o armazenamento de dados do sistema.
Atributos: informações relevantes que serão utilizadas pelo sistema.
Exemplo – Análise Macro da Análise de Requisitos
Uma vez finalizado o diagrama de casos de uso, passamos para o diagrama de sequência de cada uma das ações e, depois, para o diagrama de classes.
Com isso, temos uma visão geral de todos os requisitos.
Lembre-se: finalizada a etapa de análise de requisitos (objeto do nosso exemplo), as fases seguintes são:
Análise do Sistema
Design (Projeto)
Programação
Testes.
Agora que vimos um exemplo prático de como é feita a análise de requisitos, vamos encerrar o tópico para conhecermos as notações da UML.
As fases do desenvolvimento de sistemas, que devem ser atualizadas continuamente, para melhor refletirem o projeto final, são cinco, obedecendo a seguinte ordem:
Análise de requisitos
Análise do sistema
Design;
Programação
Homologação.
Desenvolvimento de UML
Para desenvolver uma UML, na elaboração de cada fase já conhecida (análise de requisitos, análise do sistema e design) devemos utilizar, além dos diagramas, modelos de elementos e mecanismos gerais, mais um componente, identificado como visões. O conjunto composto desses quatro itens determina os detalhes e as exemplificações para o desenvolvimento do sistema, envolvendo as suas funcionalidades estática e dinâmica.
Antes de aprofundarmos nosso conhecimento acerca de tais itens, vamos entender o que eles representam.
A visão é uma concepção baseada em uma série de diagramas que apresentam aspectos distintos do sistema a ser modelado. Dessa forma, cada visão declarada exibirá:
Pontos específicos do projeto, com ênfase em perspectivas e fases conceituais desiguais
Um plano total do sistema a ser elaborado.
As visões também podem proporcionar a conexão entre a linguagem de modelagem, e selecionar o método ou processo de desenvolvimento.
Os modelos de elementos são as definições empregadas nos diagramas que encenam declarações gerais da OO – Orientação a Objetos.
Por exemplo: classes, objetos, atributos, métodos, mensagens, módulos, comunicação entre as classes, além de algumas características como associações, dependências e heranças.
Os mecanismos gerais consistem em observações, notas, comentários complementares, informações ou significados específicos e necessários para explicar determinados comportamentos, bem como elementos que integram os variados modelos.
Além disso, os mecanismos gerais permitem meios de expansão para adaptação e detalhamento da UML ao método, ao processo, à organização, ao negócio ou a um usuário específico.
Os diagramas são indicadores visuais (figuras ou símbolos) empregados para ilustrar o conteúdo de uma visão. A UML fornece todas as visões possíveis do sistema por meio da quantidade, da variedade e da combinação entre os diagramas disponíveis.
Para desenvolver uma UML, a elaboração de cada fase já conhecida (análise de requisitos, análise do sistema e design) utiliza, além dos diagramas, modelos de elementos e mecanismos gerais, mais um componente, identificado como visões. O conjunto composto desses quatro itens determina os detalhes e as exemplificações para o desenvolvimento do sistema, envolvendo suas funcionalidades estática e dinâmica.
A visão é uma concepção baseada em uma série de diagramas, indicadores visuais, que apresentam aspectos distintos do sistema a ser modelado. Os modelos, por sua vez, são compostos de definições empregadas nos diagramas, que encenam declarações gerais da OO – Orientação a Objetos. Já os mecanismos gerais consistem em observações, notas, comentários complementares, informações ou significados específicos e necessários para explicar determinados comportamentos, bem como elementos que integram os variados modelos.
Aspectos do Sistema
Um sistema é formado por três aspectos. Clique nas imagens para conhecê-los.
Funcionais
Sistemas que envolvem a estrutura estática e suas interações dinâmicas.
Não funcionais
Sistemas classificados pelos requisitos de tempo, confiabilidade e desenvolvimento.
Organizacionais
Sistemas que tratam da organização do trabalho e do mapeamento dos módulos de código.
Aspectos do Sistema
A partir dos aspectos funcionais, não funcionais ou organizacionais, o sistema precisa ser reproduzido com base em visões. Desse modo, o sistema deve representar individualmente uma intenção e apresentar seus diferentes aspectos.
Um aspecto também pode estar inserido em mais de uma visão – isso não é errado nem é um problema.
Nesse contexto, cada visão é criada com vários diagramas, que contêm informações enfáticas sobre os aspectos particulares do sistema.
A intenção é sempre tentar detalhar o projeto da melhor maneira.
Representação das Visões
As visões compostas nos diagramas possuem as estruturas dos elementos do sistema. Para saber mais detalhes sobre a classificação de cada uma dessas visões, clique nos títulos a seguir.
Um projeto é descrito por meio de visões. Cada uma delas representa uma particularidade da especificação completa e mostra os diferentes aspectos do projeto. Cada visão é criada com vários diagramas, que contêm informações enfáticas sobre os aspectos particulares do projeto.
A partir dos aspectos funcionais, não funcionais ou organizacionais, o sistema precisa ser reproduzido com base em visões. Desse modo, o sistema deve representar individualmente uma intenção e apresentar seus diferentes aspectos. A intenção da UML é sempre tentar detalhar o projeto da melhor maneira. Cada visão é criada com vários diagramas, que contêm informações enfáticas sobre os aspectos particulares do sistema.
A visão de componentes especifica a execução dos módulos e seus complementos. Com isso, essa visão compreende os próprios componentes dos diagramas. Além disso, é executada apenas por desenvolvedores.
A visão lógica é elaborada por analistas
e desenvolvedores. Essa visão reproduz o modo de execução da usabilidade do sistema, observando e estudando o sistema internamente.
A visão de concorrência executa a segmentação do sistema em etapas, traçando sua implementação. Considerada uma característica não funcional do sistema, a visão de concorrência admite uma otimização da plataforma na qual o sistema será implantado.
A visão de organização apresenta a infraestrutura do sistema, dos equipamentos, dos servidores, das redes e dos periféricos, bem como as respectivas conexões entre eles.
Modelos de Elementos
Você sabe o que são Modelos de elementos?
Modelos de elementos são as definições utilizadas nos diagramas, determinadas de acordo com a sua representação, sem gerar dúvidas ou ambiguidades.
Cada elemento contém uma simbologia detalhada nos diagramas da própria UML.
Existem regras para determinar quais elementos podem ser apresentados nos tipos de diagramas, já que um elemento pode estar em vários tipos de diagrama.
Por exemplo, entre os modelos de elementos, consideramos os relacionamentos entre classes, objetos, estados, módulos (ou pacotes) e componentes utilizados na conexão com outros modelos de elementos.
Classes
Vamos começar com as classes?
Segundo o conceito de Programação Orientada a Objeto (POO), uma classe é a referência ou a representação de um objeto. Nesse sentido, a classe corresponde à classificação do objeto segundo critérios de atributos e métodos.
Podemos afirmar que a classe define o objeto, e que todos os objetos são instâncias de classes, e não o contrário.
Relação entre atributos e métodos com a classe.
Relação entre os valores dos atributos e dos métodos com o objeto.
Classes
As classes são utilizadas para categorizar os objetos encontrados em uma situação ou em um contexto verdadeiro.
Por exemplo, classes que identificam:
Qualquer tipo de sistema de informação, técnico ou de software – sistema operacional, arquivos de dados, códigos de programação, interface ou elementos de uma interface
Qualquer outra descrição de um objeto.
Classes
Reconhecer classes não é uma tarefa simples. No entanto, existem algumas dicas para ajudar nessa tarefa. Clique nas lâmpadas para acessá-las.
Há informações que necessitam ser arquivadas ou verificadas?
Em caso afirmativo, olhe para essa entidade com mais atenção. É possível que ela seja uma classe.
Existem sistemas externos ao sistema que será implementado?
Se existirem, tais sistemas deverão ser vistos como classes pelo sistema implementado. Além disso, eles deverão se relacionar com outros sistemas externos.
O sistema modelado precisa utilizar classes de bibliotecas, componentes ou modelos externos?
Para manipular esses elementos no sistema, são definidas as chamadas classes candidatas.
Qual a função dos atores dentro do sistema?
A função dos atores pode ser definida como classe – administrador, usuário, operador, cliente etc.
Classes
A representação gráfica das classes é feita por um retângulo subdividido em três partes. Clique nos números para conhecê-las.
Cliente
Nome: string
Idade: int
Sexo: bit
CPF: string
Comprar()
Trocar()
Devolver()
Pagar()
1
2
3
Nome
Contém o nome de identificação da classe.
Neste exemplo: Cliente.
Atributos
Correspondem à definição dos atributos da classe.
Neste exemplo: Nome, idade, sexo, CPF.
Métodos e operações
Correspondem aos métodos de tratamento de dados e de relacionamento entre as classes do sistema.
Neste exemplo: Comprar(), Trocar(), Devolver(), Pagar().
Observe que os Métodos ou operações são sucedidos por parênteses (). A função dos parênteses é indicar uma ação – execução.
No caso do tratamento de dados ou relacionamento entre as classes, a ação pode ou não ser parametrizada – complementada com parâmetros.
Objetos
Agora que já vimos as classes, vamos passar para os objetos?
O objeto é um elemento que existe em um contexto verdadeiro e está inserido em qualquer parte de todo tipo de sistema.
O objeto permite tratamentos variados, como análise de comportamento, criação, consulta, alteração ou exclusão. Dessa forma, o objeto permite tratamento em:
Dispositivo físico – hardware ou equipamento
Entidade – empresa
Projeto – negócio.
O objeto é apresentado como uma classe e identificado por um nome. Entretanto, o nome do objeto é destacado com uma linha sublinhada, para assim se diferenciar do nome da classe, que o antecede.
Estados
Os estados são os resultados das atividades, alcançados após o processamento de um objeto.
Dessa forma, um estado é obtido por meio dos valores dos atributos do objeto e das ligações com outros objetos.
Nesse contexto, um evento ocorre quando um objeto sofre alguma ação. Em outras palavras, realiza-se um evento quando algo acontece a um objeto, alterando seu estado.
Podemos antecipar todos os comportamentos de um objeto. Para isso, basta observarmos a modificação de estado entre os objetos de um sistema, conforme os eventos sofridos pelos mesmos objetos.
Estados
A representação de um estado está estruturada em três partes. Clique nas setas conhecê-las.
Nome do evento
Atributos
Atividades
Nome
O nome representa a identificação do estado.
Atributos
Os atributos apresentam a variável do estado em que os atributos do objeto, mencionados na representação da classe, podem ser relacionados e atualizados.
Atividades
A atividade relaciona as ações e os eventos. Entre os eventos, podemos destacar os seguintes padrões:
Entrar – quando as atividades do objeto entram naquele estado.
Sair – quando as atividades do objeto prosseguem para o estado seguinte.
Executar – enquanto as atividades do objeto permanecem no mesmo estado.
Módulos ou Pacotes
Você sabe o que são módulos ou pacotes no contexto do desenvolvimento de sistemas?
O diagrama de módulos ou pacotes descreve as partes do sistema em agrupamentos lógicos. Além disso, o diagrama exibe as dependências entre esses agrupamentos.
Os módulos podem depender de ou estar relacionados a outros módulos. Um módulo é estabelecido como um mecanismo de representação geral para estruturar elementos agrupados por meio de relacionamentos.
Todos os modelos de elementos relacionados ou mencionados por um módulo são denominados conteúdo do módulo.
O conteúdo do módulo não deve ser incluído em outros módulos. Nesse sentido, o conteúdo do módulo deve ser reutilizado em outros módulos por meio dos relacionamentos estabelecidos entre eles. Dessa maneira, evitamos a reescrita do código.
Além disso, quando módulos adquirem modelos de elementos de outros módulos, fazemos somente a referência ao módulo que contém o elemento.
Módulos ou Pacotes
Apesar de os módulos não possuírem significados estabelecidos para suas instâncias, as formas de comunicação permitidas entre eles são identificadas por:
Dependência
Refinamento
Generalização ou herança.
Um módulo é estruturado a partir de outros modelos de elementos, criando uma agregação de composição – processo semelhante a um tipo de relacionamento denominado agregação. Com isso, a eliminação de um módulo implica a eliminação de todo seu conteúdo.
Diagrama de Módulos
O objetivo do diagrama de módulos é organizar os modelos dos elementos.
Nesse sentido, um diagrama de módulos pode ser utilizado em qualquer fase do processo de modelagem de um sistema.
Vejamos como funciona o diagrama de módulos. Clique no diagrama para ampliá-lo.
Agora, vamos passar para os componentes!
Componentes
Componentes são códigos em linguagem de programação ou códigos em linguagem de máquina (objeto ou executável).
No contexto da UML, o componente é utilizado para:
Modelar o código-fonte.
Destacar a função de cada módulo, facilitando sua reutilização.
Por exemplo, em um sistema desenvolvido em C-Sharp, cada arquivo com extensão .cs é considerado um componente do sistema a ser exibido no diagrama de componentes que utiliza o arquivo.
Diagrama de Componentes
O diagrama de componentes determina como as classes deverão estar organizadas por meio dos componentes de
trabalho.
Desse modo, é possível apontar quais classes cada componente representa.
Relacionamentos
Os relacionamentos conectam classes ou objetos, estabelecendo relações lógicas entre as próprias entidades.
Associação A associação é o relacionamento entre as classes e os objetos dessas classes. A função da associação é detalhar uma quantidade de conexões definidas entre os dois objetos relacionados.
2. Generalização A generalização é um tipo de relacionamento entre um elemento globalizado com outro específico. O elemento específico abrange somente informações complementares, mais detalhadas além da instância, permitindo sua utilização onde o elemento globalizado também seja permitido.
3. Especialização A especialização ocorre quando uma classe criada é herdada da generalização e detalha o processo definido na classe pai. Dessa forma, essa classe especializa a classe pai para um tipo específico.
4. Dependência A dependência é a relação entre um elemento independente e um elemento dependente. Por conta desse relacionamento, qualquer modificação no elemento independente provoca alteração no elemento dependente.
5. Refinamento O refinamento é um relacionamento em níveis distintos de concepção. Tal relacionamento envolve duas definições de uma mesma entidade.
Associação
Você sabe como ocorre uma associação? Uma associação exibe a conexão de duas classes. Tanto as classes quanto as associações são fortes quando bem modeladas em sistemas complexos.
Será que existe apenas uma forma de associação? Observe o esquema.
Tipos de Associação
Para conhecer os tipos de associação, navegue pelas setas a seguir.
Associação normal
É a forma mais comum de associação. De modo geral, a associação declara um nome de identificação e, normalmente, uma ação. A ação pode ser declarada por um verbo ou um substantivo, quando um verbo não for recomendado.
A associação pode ser representada por uma linha contínua. Outra opção é usar uma seta ao final da associação, com referência ao único sentido considerado, ou então dar dois nomes à associação – nesse caso, um nome para cada direção da associação.
A multiplicidade entre os relacionamentos costuma ser representada por um intervalo. Esse intervalo indica a proporcionalidade de objetos relacionados na conexão. Vejamos, no exemplo a seguir, um relacionamento por associação normal entre as classes Cliente e Cadastro.
Associação recursiva
A Associação recursiva é um tipo de associação que permite a conexão de uma classe a ela mesma por uma ligação. Ainda que a associação indique a conexão entre os dois objetos, os objetos conectados pertencem à mesma classe.
Associação qualificada
As associações qualificadas são aplicadas às associações de um para vários (1..*) ou vários para vários (*).
O identificador da associação qualificada – denominado qualificador – determina como um objeto é identificado no final da associação n.
Vejamos um exemplo:
Associação ordenada
Uma associação ordenada ocorre quando as relações entre objetos possuem uma ordem específica. No entanto, as associações entre objetos podem indicar uma ordenação oculta em alguns casos.
Também é possível que exista uma ordem subentendida definida por meio de uma associação ordenada. Por exemplo, uma associação ordenada pode ser utilizada como a ordem de disposição das janelas de um sistema ao usuário.
A associação é indicada com a descrição "{ordenada}" próxima à linha de relacionamento da associação entre ambas as classes.
Associação ternária
A associação ternária ocorre quando uma classe pode ser ligada a outra associação que já possui duas classes a ela relacionadas. Desse modo, chamamos de associação ternária a associação de mais de duas classes.
A associação ternária ocorre na própria linha da associação, para adicionar informações extras na associação anterior. Se as operações ou os atributos são adicionados à associação, a associação deve ser mostrada como uma classe.
Nesse sentido, a associação ternária reúne três classes e é representada por meio de um losango. Vejamos:
Tipos de Associação – Agregação
Ainda temos a associação do tipo agregação, que é uma forma específica utilizada quando uma das classes associadas é considerada parte de outra classe ou então está inserida em outra classe.
A associação do tipo agregação é identificada quando alguns termos são aplicados. Por exemplo: “é parte de”, “contém” ou “consiste em”.
A agregação é especificada como:
Agregação compartilhada
Agregação composta ou de composição.
Tipos de Associação – Agregação Compartilhada
A agregação compartilhada ocorre quando uma das classes é parte de outra classe ou está inserida nela. Com isso, a classe pode repetir-se diversas vezes, em um mesmo instante. Vejamos um exemplo.
A agregação compartilhada é representada por um losango não preenchido, sempre ao lado do objeto-principal.
Tipos de Associação – Agregação Composta ou de Composição
A agregação composta ocorre quando uma classe está inserida em outra, compondo e integrando essa outra classe. Caso o objeto da classe principal seja eliminado, as classes que integram a classe principal por agregação de composição também serão eliminadas.
Isso ocorre porque a existência da classe inserida em outra classe só faz sentido se a classe principal existir. Vejamos.
No exemplo, repare que os componentes de uma página Web (Text, RadioButton e CheckBox) estão contidos na página Web. A existência desses componentes não faz sentido se a página Web não existir.
A agregação de composição é representada por um losango preenchido, sempre ao lado do objeto-principal. Neste caso, ao lado da página Web.
Exemplo
Vejamos um exemplo de agregação composta.
Neste exemplo, os componentes do formulário (Form1) CADASTRO (Label, Button e TextBox) estão contidos no formulário (Form1). A existência desses componentes não faz sentido se o formulário (Form1) não existir, certo?
Desse modo, trata-se de uma associação do tipo agregação de composição.
Já vimos todos os tipos de associação. Vamos continuar vendo outros tipos de relacionamento?
Generalização
A generalização é um tipo de relacionamento definido pelo elemento principal classe pai e pelo elemento detalhado classe filha ou herança.
Além de todas as características do elemento principal, o elemento detalhado contém outras especificações. Desse modo, é possível que um objeto mais detalhado seja aproveitado como uma instância do elemento principal.
A generalização é dividida em dois tipos diferentes, e a escolha do tipo a ser utilizado depende da situação. Clique nas caixas para conhecê-los.
Generalização Normal
Na generalização normal, a classe detalhada é conhecida como subclasse ou classe filha. A subclasse obtém todos os atributos, os métodos e as associações da classe principal, conhecida como superclasse ou classe pai.
Uma classe pode ser considerada uma subclasse ou uma superclasse. Isso pode ocorrer por meio das generalizações e conforme a hierarquia das classes.
A representação de uma generalização normal é visualizada pelo uso de uma linha que associa as duas classes relacionadas. A superclasse é indicada pela seta na linha que representa a generalização.
No exemplo a seguir, observe que a classe pai ou superclasse é representada pela classe Carro. Já a classe filha ou subclasse é representada pela classe Motor.
Carro Motor
Generalização Restrita
Uma generalização restrita detalha informações mais objetivas e concretas. Com isso, a generalização restrita aborda o processo e a forma como a generalização será aplicada e ampliada posteriormente.
A generalização restrita pode ser subdividida em generalização de 
Sobreposição: A generalização restrita de sobreposição ocorre quando as subclasses obtêm informações de uma superclasse por meio da sobreposição.
Disjuntiva: A generalização restrita disjuntiva é utilizada como default – padrão. Trata-se do inverso da generalização por sobreposição.
Completa: A generalização restrita completa considera que todas as subclasses estão
detalhadas – especificadas. Dessa forma, esse tipo de generalização não permite qualquer outra generalização naquele instante.
Incompleta: A generalização restrita incompleta é tratada como padrão da linguagem. Nesse sentido, esse tipo de generalização é o oposto da generalização completa. Conforme as novas necessidades, é possível desenvolver outra generalização.
Especialização
Ao contrário da generalização, a especialização cria uma classe herdada da generalização. Com isso, o processo definido na classe pai é refinado.
A especialização detalha a classe pai de acordo com as necessidades dos elementos da aplicação.
Dependência
Vamos conhecer mais um tipo de relacionamento?
A dependência é uma ligação estrutural entre dois tipos de elementos: um elemento independente e um elemento dependente.
A dependência gera uma cumplicidade entre os elementos envolvidos. Com isso, a classe que adquire um objeto de outra classe como parâmetro acessa o objeto principal dessa outra classe.
Nesse sentido, qualquer alteração no elemento independente afetará também o elemento dependente. Desse modo, podemos concluir que existe uma dependência entre as duas classes envolvidas, ainda que a dependência não seja evidente.
No exemplo a seguir, a classe Produto depende do Pedido para ser acessada. Desse modo, não é possível acessar o produto sem a abertura do pedido. Vejamos:
O relacionamento de dependência é representado por uma linha tracejada e uma seta ao final de um dos lados do relacionamento.
Refinamento
Chamamos de refinamento o relacionamento entre duas descrições de um mesmo elemento, porém em camadas divergentes de abstração. O refinamento, portanto, pode ser utilizado para modelar implementações diversas de uma mesma função.
Por exemplo, imagine um relatório com uma visão geral e uma visão detalhada. O relatório é a camada de abstração. Nesse caso, a visão geral não é tão complexa quanto a visão detalhada, pois trata-se da implementação do mesmo relatório.
Você sabia que o refinamento é muito utilizado em modelos de coordenação? Pois é!
E como representamos o refinamento?
A representação do refinamento é feita por meio de uma linha tracejada com um triângulo ao final de um dos lados do relacionamento.
Mecanismos Gerais
A UML busca determinados recursos em seus diagramas para lidar com as informações complementares. Tais recursos são denominados mecanismos. Temos dois tipos de mecanismos gerais.
Os ornamentos são acrescentados aos modelos de elementos em diagramas para agregar informações ao elemento. A utilização do ornamento tem o objetivo de apontar determinado aspecto de um elemento, como a multiplicidade de relacionamentos. A multiplicidade de relacionamentos é um número ou um intervalo que assinala uma quantidade possível de instâncias para um elemento associado na ligação do relacionamento.
Desse modo, para identificar um tipo, o nome do elemento é escrito em negrito.
Já para indicar uma instância, o nome do elemento é sublinhado.
A definição em uma linguagem de modelagem não pode ser aplicada genericamente, independentemente de sua extensão. Dessa forma, devemos utilizar o mecanismo notas quando a inclusão de informações em um modelo não puder ser indicada de outra maneira. Uma nota pode ser inserida em qualquer parte do diagrama e armazenar qualquer tipo de informação.
Um exemplo de nota seria:
A Associação recursiva é um tipo de associação que permite a conexão de uma classe a ela mesma, por meio de uma ligação. Ainda que a associação indique a conexão entre os dois objetos, os objetos conectados pertencem à mesma classe. Já a associação ternária ocorre quando uma classe pode ser ligada a outra associação que já possui duas classes relacionadas. Desse modo, chamamos de associação ternária a associação de mais de duas classes. A associação comum, por sua vez, pode ser representada por uma linha contínua. A generalização, por outro lado, é um tipo de relacionamento definido pelo elemento principal (classe pai) e pelo elemento detalhado (classe filha).
Ao contrário da generalização, a especialização cria uma classe herdada da generalização. Com isso, o processo definido na classe pai é refinado.
A classe cliente existe de maneira independente de pedido, porém a classe ItemPedido é dependente de pedido, o que pode ser entendido pela multiplicidade de relacionamentos, como a utilização de ornamentos, por exemplo, que tem o objetivo de apontar determinado aspecto de um elemento.
Diagramas
Você sabia que a literatura sobre UML considera diferentes quantidades de diagramas UML? Diagramas são formas de explicar, por representação visual, como se relacionam as classes, os objetos e as ações. A partir dos diagramas, podemos esclarecer o que acontece nas operações do mundo real com a programação do mundo abstrato.
Os diagramas estão classificados em diagramas estruturais e diagramas comportamentais.
Em algumas referências, você vai encontrar nove diagramas. Em outras, dez diagramas. Ainda há aquelas referências que consideram 13 diagramas.
Ao estudar os diagramas, percebemos que sua quantidade varia conforme a necessidade de detalhamento do projeto. Isso significa que o grau de especificação para representar a abordagem e a distribuição das informações influencia a quantidade de diagramas.
Diagramas
Você lembra quantos diagramas havia no esquema que acabamos de ver? Se não lembra, aqui vai a resposta: havia dez diagramas!
Agora, vamos apresentar uma abordagem mais completa. Para isso, iremos utilizar uma literatura mais detalhada, que faz referência a 13 tipos de diagrama. Nesse caso, o diagrama de interações está subdividido em outros diagramas.
Observe que os diagramas continuam divididos em dois grandes grupos: Estruturais e Comportamentais. Clique em cada um deles, a seguir, para ampliá-los.
Diagramas
É importante reforçar que todos os sistemas apresentam estrutura estática (estrutural) e comportamento dinâmico (comportamental).
A UML também aceita modelos:
Estáticos – estruturais
Dinâmicos – comportamentais
Funcionais – de interação.
Prepare-se para conhecer todos os tipos de diagrama. Vamos começar pelo grupo dos diagramas estruturais.
Diagramas Estruturais
Os diagramas estruturais representam estruturas estáticas ou modelos estáticos de um sistema.
Nesse sentido, tais diagramas são definidos como modelos para documentação dos aspectos estáticos de um ciclo de desenvolvimento de um software.
Podemos citar como exemplo a representação estrutural (o "esqueleto") com as classes, as interfaces, as colaborações e os componentes envolvidos. Essa representação disponibiliza aos desenvolvedores uma visualização mais ampla sobre o mapeamento geral do produto em desenvolvimento dentro do processo.
Desse modo, a representação estrutural colabora com a especificação, a construção e a própria documentação do sistema.
Diagrama de Classes
O Diagrama de Classes funciona por meio de simbologias. Nesse sentido, é a forma mais comum de representar uma estrutura e as relações entre as classes utilizadas como parâmetro para os objetos.
O Diagrama de Classes é uma modelagem que define todas as classes necessárias ao sistema. Com isso, esse diagrama serve de apoio para a elaboração de outros diagramas. Como já vimos, as classes podem relacionar-se com outras classes de diversas maneiras. 
Associação
As classes são conectadas entre si.
Dependência
Uma classe é dependente, e outra classe é independente.
Especialização
Uma classe é especialização de outra classe.
Generalização
Uma classe é mais genérica que outra classe.
Módulos ou Pacotes
Classes são agrupadas por características similares.
Diagrama de Classes
De modo geral, um sistema possui alguns Diagramas de Classes, já que nem todas as classes estão inseridas em um único diagrama.
Diagrama de Objetos
O Diagrama de Objetos é uma diversificação do Diagrama de Classes, já que aplica uma ideologia muito próxima entre os dois diagramas (classe versus objetos).
No entanto, os elementos representados
no diagrama são os objetos, justamente os que foram definidos como instâncias das classes. Desse modo, em determinado instante da execução, proporcionam uma visão dos valores atribuídos pelos objetos de um Diagrama de Classe.
Os Diagramas de Objetos também são empregados como parte de outros diagramas. Por exemplo, Diagrama de Colaboração ou de Comunicação. O Diagrama de Comunicação era conhecido como Diagrama de Colaboração. A partir da UML 2.0, seu nome foi alterado.
Dessa forma, a apresentação da colaboração ocorre de modo dinâmico entre os objetos do sistema.
Diagrama de Componentes
O Diagrama de Componentes mostra o sistema pelo lado funcional. Desse modo, esse diagrama está relacionado à linguagem de programação, exibindo as associações entre os componentes e a distribuição dos módulos durante o processamento.
O Diagrama de Componentes detalha os componentes de software e as dependências envolvidas, fundamentados na estrutura lógica do código desenvolvido.
Esses componentes se referem ao código-fonte, por exemplo. Nesse sentido, fazem referência à implementação, na arquitetura física das concepções e nas aplicabilidades definidas por meio das classes, dos objetos e de seus relacionamentos, classificados como arquitetura lógica.
A representação ou a simbologia empregada em um componente UML é indicada por meio de um retângulo, com a identificação do componente escrita na parte inferior ou interna de seu símbolo. Além disso, no lado esquerdo, são usados uma elipse e dois retângulos de menores dimensões.
Somente os componentes executáveis podem ter instâncias. No entanto, um diagrama de componente mostra apenas componentes como tipos. Componentes também revelam interfaces visíveis para outros componentes.
Nesse contexto, as dependências entre componentes podem apontar para a interface usada do componente.
Diagrama de Implantação, Execução ou Instalação
O Diagrama de Implantação exibe a arquitetura física do hardware e a arquitetura do software do sistema.
hardware
A arquitetura física é representada pelas características físicas do sistema, como: servidores, periféricos, estações e topologias.
software
Já a arquitetura do software do sistema é representada pelos sistemas operacionais e pelos aplicativos envolvidos, como: SQL, IIS e JBOSS.
Diagrama de Módulos ou Pacotes
O Diagrama de Módulos, ou Diagrama de Pacotes, descreve os pacotes ou as partes do sistema.
As partes do sistema são os subsistemas ou submódulos incorporados e distribuídos em agrupamentos lógicos.
O uso do Diagrama de Módulos é muito comum, uma vez que ele apresenta a arquitetura de um sistema por meio do agrupamento de suas classes. Nesse sentido, a finalidade do Diagrama de Módulos é simbolizar um grupo de classes.
A aplicação desse tipo de diagrama pode ser feita em qualquer etapa do processo de modelagem, a fim de sistematizar os modelos dos elementos.
Vejamos um exemplo de Diagrama de Módulos.
Diagrama de Estrutura Composta
O Diagrama de Estrutura Composta apresenta o detalhamento das partes internas de uma estrutura.
Esse detalhamento é realizado por meio da descrição dos relacionamentos entre os elementos e da colaboração interna das classes, interfaces, ou componentes e suas funcionalidades.
O Diagrama de Estrutura Composta é considerado um dos diagramas mais recentes até o momento. Esse diagrama só foi incorporado aos conceitos da UML a partir da UML versão 2.0 do Rational Unified Process (RUP). O Processo Unificado da Rational, ou Rational Unified Process (RUP), é um processo de engenharia de software criado para apoiar o desenvolvimento orientado a objetos, a partir de uma forma sistemática, para obter vantagens no uso da UML.
O RUP foi criado pela Rational Software Corporation e adquirido pela IBM em fevereiro de 2003.
O principal objetivo do RUP é atender as necessidades dos usuários por meio de uma produção de software de alta qualidade, que cumpra um cronograma e um orçamento previsíveis.
Diagramas Comportamentais
Os Diagramas Comportamentais representam estruturas dinâmicas ou modelos dinâmicos. Nesse sentido, são chamados de diagramas comportamentais porque seus modelos estão associados aos processos de operação e de execução do sistema.
Os Diagramas Comportamentais permitem a visualização, a especificação e a construção dos aspectos dinâmicos do sistema.
Por exemplo: o tráfego de mensagens, a circulação dos componentes em uma rede, bem como todos os elementos que permitem modificações e atualizações.
Diagramas Comportamentais - Diagrama de Caso de Uso
Vamos começar a abordar os Diagramas Comportamentais, a começar pelo Diagrama de Caso de Uso. Vamos lá?
Diagrama de Caso de uso
Antes de conhecermos cada um dos Diagramas Comportamentais, vamos pensar em um assunto:
Qual é o diagrama primordial da UML?
Vamos conhecer suas características e sua aplicabilidade?
O Diagrama de Caso de Uso (Use Case) apresenta o conjunto de comportamentos e funcionalidades de um sistema. Com isso, ele é considerado o diagrama primordial da UML, justamente por não exigir elevado grau de detalhamento.
Além de ser simples, o Diagrama de Caso de Uso é o mais comum entre os demais diagramas.
	
	Você se lembra do exemplo inicial, feito na etapa de análise de requisitos?
Naquele momento, recorremos ao Diagrama de Caso de Uso para fazer um levantamento dos itens de uma biblioteca.
A principal aplicabilidade do Diagrama de Caso de Uso está na etapa de especificação dos requisitos de um sistema. Tal etapa é encarregada de coletar dados e levantar uma análise detalhada das necessidades indispensáveis ao sistema.
Desse modo, os requisitos são relatados em termos dos próprios casos de uso (use cases) e dos atores externos, representando uma entidade externa ao sistema.
A comunicação com o sistema via use case representa uma sucessão de ações que podem ser executadas pelo sistema e receber dados concretos, de um formato pré-conhecido, na entrada de dados, por meio do próprio ator, por exemplo.
Os mesmos atores retornam ou não o valor da resposta da efetuação de um use case. Tal definição é realizada por meio do texto da documentação, em conjunto com o caso de uso – use case.
A importância da aplicação de use cases em colaborações é fundamental, já que eles apresentam um contexto que especifica as classes e os objetos, bem como os relacionamentos, a comunicação e a forma de interação entre classes e objetos na execução de uma atividade no sistema.
Por meio do relacionamento, da comunicação e da interação constante, o Diagrama de Use Cases tem participação durante todo o processo de modelagem. Além disso, esse diagrama serve como base para outros diagramas.
De modo resumido, podemos considerar três elementos importantes do Diagrama de Caso de Uso:
Diagrama de Caso de Uso
No momento em que um Use Case é elaborado, a responsabilidade, a obrigação e o comprometimento de cada etapa de execução precisam estar relacionados com as classes envolvidas na colaboração.
Dessa forma, devem ser detalhados os métodos e as operações, juntamente com a explicação de como irão interagir as classes.
 
Para exibir o caminho específico de cada ação, utilizamos um cenário. O cenário é um importante exemplo de uma instância de um use case ou de uma colaboração.
No âmbito de um Use Case, a interação está limitada entre o ator externo e o use case.
No âmbito de uma colaboração, todas as relações e os procedimentos da execução efetivados no sistema serão especificados e registrados.
Vejamos dois exemplos de Diagramas de Use Case.
Diagrama de Estados
O Diagrama de Estados tem a finalidade de complementar a descrição das classes.
A complementação é feita por meio da apresentação de todos os estados possíveis (identificados como aspectos dinâmicos), encontrados nos objetos de uma classe, bem como por meio da exibição dos eventos dos sistemas que ocasionam as alterações.
No entanto, nem todas as classes de um sistema terão o Diagrama de Estados modelado.
Somente terão os Diagramas de Estado modelados as
classes que apresentem uma quantidade estabelecida de estados conhecidos e o próprio comportamento das classes atingido e modificado pelos estados diversos, em função da execução de eventos no processo.
Diagrama de Estados
Primeiramente, o Diagrama de Estados se apodera do ciclo de vida dos objetos e de seus atributos naquele instante. Em seguida, exibe os possíveis estados contidos em um objeto e o modo como os eventos podem influenciar esses atributos nos instantes seguintes. Por exemplo: tráfego de mensagens, temporizadores de controle, erros em procedimentos (status, flags etc.) e condições lógicas resolvidas.
Vejamos a representação de um Diagrama de Estados com seus principais componentes.
Clique em cada componente para acessar sua descrição.
Ponto inicial: tudo começa pela definição do estado inicial ou ponto de partida, representado por um círculo totalmente preenchido.
Ponto final: os pontos iniciais são seguidos por diversos estados finais – pontos finais. Os pontos finais são representados por um círculo maior, não preenchido, contornando outro círculo menor totalmente preenchido.
Transição: as transições aplicadas sobre um evento são representadas por uma linha com uma seta em sua extremidade final. A representação indica a ligação e o sentido do fluxo entre os estados.
Estado: a representação de um estado é realizada por um retângulo com ângulos arredondados.
Quando a aplicação de um evento é detectada, inicia-se a execução da transição de um estado para outro. Dessa forma, caso uma transição incorpore um evento, como uma intervenção de um operador, essa transição será executada automaticamente. Caso contrário, a inexistência de um evento implicará a espera de uma ação interna do código do estado para ser executada.
Com isso, a transição será iniciada, e as atividades do estado subsequente estarão na sequência de execução do Diagrama de Estados, quando todas as ações forem executadas pelo próprio estado.
Diagrama de Atividades
O Diagrama de Atividades visa ao trabalho realizado na execução de um método ou uma operação, bem como ao trabalho realizado nas atividades, em uma instância de um objeto.
Os Diagramas de Atividades são considerados uma oscilação do Diagrama de Estado, mas com um objetivo diferente. Desse modo, os Diagramas de Atividades detêm as ações e seus resultados, por meio de um conjunto de ações ou atividades executadas, até atingir a conclusão total do processo.
No Diagrama de Atividades, os estados passam para uma próxima etapa no momento em que um procedimento é acionado. Ao contrário do Diagrama de Estados, o Diagrama de Atividade não exige qualquer especificação de evento.
O Diagrama de Atividades é outra forma de apresentar as interações, demonstrando onde ocorrem e o que acontece com essas interações quando as ações são executadas.
Obter as operações que serão processadas no momento em que uma ação é iniciada – processo mais usual em um Diagrama de Atividade.
Apresentar como é o funcionamento de um elemento de negócio, considerando os atores, o tráfego de trabalho, a organização, os objetos físicos e as regras de negócio.
Obter as operações internas de um objeto.
Exibir o processamento de ações e objetos de uma instância.
Apresentar o modo de processamento de um conjunto de ações associadas e a interação de tais ações com os objetos relacionados.
De modo geral, o Diagrama de Atividades é desenvolvido para simbolizar as atividades processadas por um método no sistema. Com isso, esse diagrama demonstra o tráfego sequencial de todas as atividades, ou seja, os processamentos dos estados, com as descrições de uma atividade executada por uma ação do sistema.
Por meio de um processamento paralelo, podemos especificar elementos lógicos de decisão e condição, bem como exibir tais elementos no diagrama. Além disso, podemos tratar as complementações de mensagens enviadas e recebidas como integrantes de ações executadas.
Vejamos um exemplo de Diagrama de Atividade – Controle de Acesso de Usuário:
Diagramas de Interação – Diagrama de Interatividade
O Diagrama de Interatividade é formado por pequenos diagramas de sequência. De forma complementar, esses pequenos diagramas utilizam os registros e elementos sintáticos do Diagrama de Atividades para apresentar o controle do fluxo de execução.
Você sabia que o Diagrama de Interatividade surgiu na UML a partir da versão 2.0?
Podemos afirmar que os Diagramas de Interatividade são uma derivação dos Diagramas de Atividades dentro do próprio sistema ou de um processo de negócio.
Desse modo, nos Diagramas de Interatividade, podemos encontrar as sequências que compõem um fluxo de atividades, bem como as referências sobre como realizam suas atividades e trabalham em uma sequência de eventos.
Clique na imagem a seguir para ver um diagrama de interatividade sobre o seguinte processo de negócio: Reserva de Passagem.
Diagramas de Interação – Diagrama de Sequência
O Diagrama de Sequência apresenta a contribuição dinâmica entre os objetos de um sistema – como uma troca de mensagens – na sequência de eventos executados dentro de um processo.
Desse modo, o diagrama possibilita melhor compreensão e acompanhamento das mensagens encaminhadas entre os objetos e da interação entre eles. Além disso, é possível apontar para algum acontecimento previsto em um instante do processamento do sistema.
O Diagrama de Sequência também permite observar a quantidade de objetos relacionados, por meio das linhas verticais, associados ao tempo e interpretados pela evolução desse tempo.
Diagramas de Interação – Diagrama de Sequência
Como pudemos observar, no Diagrama de Sequência desse sistema, cada objeto processado apresenta seu próprio caminho de desempenho, ou sua linha ou encadeamento de execução, conhecido como thread.
Para sistemas que utilizam linhas concorrentes de controle, mensagens ou objetos que não ocorrem simultaneamente (assíncronos) são mostrados como ativação.
Diagramas de Interação – Diagrama de Comunicação ou Colaboração
O Diagrama de Comunicação (ou de Colaboração, até a UML 1.5) apresenta a comunicação dinâmica entre os objetos por meio de um processo equivalente ao processo do Diagrama de Sequência.
Apesar das particularidades de cada um desses diagramas, podemos optar pela utilização do Diagrama de Comunicação ou do Diagrama de Sequência, devido a essa visão de equivalência.
Foco do diagrama associado ao tempo do processo: diagrama de sequencia
Foco do contexto do sistema em uma ordenação estrutural: diagrama de comunicação.
Diagramas de Interação – Diagrama de Tempo
Vamos conhecer o Diagrama de Tempo?
O Diagrama de Tempo surgiu a partir da UML versão 2.0, no grupo do Diagrama de Interação. Nele usa-se uma escala de tempo para realizar a modelagem de restrições temporais do sistema, além de acompanhar o comportamento dos objetos por meio da interação e da evolução de estados.
Nesse diagrama, as condições que mudam durante um intervalo são destacadas.
Diagramas de Interação – Diagrama de Tempo
Muitos afirmam que o Diagrama de Tempo é um modo alternativo e mais completo de exibir um Diagrama de Sequência, com as suas particularidades.
Em uma abordagem geral, o Diagrama de Tempo é a junção dos Diagramas de Sequência e de Estado. Com isso, o Diagrama de Tempo apresenta o estado dos objetos em relação ao tempo e as mensagens que alteram o estado de maneira mais unificada. Vejamos, a seguir, um exemplo de Diagrama de Tempo:
Conseguiu ter uma visão geral dos diagramas? É muito importante nos lembrarmos de algumas informações essenciais. Clique nos números para relembrar!
Os diagramas utilizados pela UML são compostos de 13 tipos.
Todos os sistemas possuem uma estrutura estática e um comportamento dinâmico.
A UML suporta modelos estáticos (estruturais), dinâmicos (comportamentais) e funcionais (interativos).
Devemos optar pelo Diagrama de Colaboração quando for necessária a representação da troca de mensagens entre os objetos e a visualização desses com seus relacionamentos.
O Diagrama de Sequência possibilita melhor compreensão e acompanhamento das mensagens encaminhadas entre os objetos e da interação entre eles, além de apontar acontecimentos previstos em um instante do processamento do sistema.
A principal aplicabilidade do Diagrama de Caso de Uso está na etapa de especificação dos requisitos de um sistema, encarregada de coletar dados e levantar uma análise detalhada das necessidades indispensáveis ao sistema.
O Diagrama de Estados representa os possíveis estados contidos em um objeto e o modo como podem influenciar esses atributos nos instantes seguintes.
O Diagrama de Caso de Uso (Use Case) apresenta um conjunto de comportamentos e funcionalidades de um sistema. Com isso, ele é considerado o diagrama primordial da UML, justamente por não exigir elevado grau de detalhamento.
Já o Diagrama de Estados exibe os possíveis estados contidos em um objeto e o modo como os eventos podem influenciar esses atributos nos instantes seguintes. Representa o ponto inicial, final, e de transição de uma classe.
No Diagrama de Atividades, os estados passam para uma próxima etapa no momento em que um procedimento é acionado. Ao contrário do Diagrama de Estados, o Diagrama de Atividades não exige qualquer especificação de evento.
Por fim, Diagrama de Sequência apresenta a contribuição dinâmica entre os objetos de um sistema – como uma troca de mensagens – na sequência de eventos executados dentro de um processo.