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 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.
