Diagramas Estruturais da UML: Diagrama de Implantação

O diagrama de implantação é o diagrama estrutural responsável por estabelecer a relação entre os recursos de infraestrutura e artefatos do sistema, em outras palavras, ele mapeia arquitetura do hardware às necessidades do software a ser implantado. Esse diagrama é basicamente implementado com “nós”, “associações entre nós”.

Os “nós” são formas ou containers de UML, usadas para representar um item de hardware, como um servidor físico, seja ele de armazenamento ou execução da aplicação ou de módulos isolados, ou ainda um “nó” pode significar o ambiente de execução do software ou parte dele. “Nós” também podem conter outros nós, de maneira que demostrem a real estrutura do sistema, por exemplo, um nó pode conter os arquivos necessários, encapsulados por um “nó” que representa o servidor de armazenamento, este por sua vez, também encapsulado por outro “nó” que representa o ambiente de execução e ainda se necessário, encapsulado em outro “nó’ com outros ambientes de execução.

As associações entre os “nós” representam as relações destes itens no mundo real, bem como a forma que interagem e trocam informações. São representados por retas complementadas por um rótulo que descreve da relação entre eles ou a maneira como integarem entre si, sendo esse rótulo um mecanismo da UML conhecido como esteriótipo.

“A UML tem muitos tipos diferentes de setas tracejadas que parecem idênticas. Felizmente, a UML permite que você marque um elemento de modelo para indicar exatamente que tipo de elemento ele é. UML chama esse rótulo de um estereótipo. Você mostra o estereótipo ao lado do elemento (precedendo o nome do elemento, se houver). UML tem vários estereótipos predefinidos ou você pode definir o seu próprio para indicar um tipo especial de elemento para seus próprios fins”. (Chonoles & Schardt, 2003)

O propósito deste modelo de diagrama é documentar os itens envolvidos a fim de tornar ágil o processo de implantação de software. A  Figura 1 apresenta um exemplo deste diagrama.

O diagrama de implantação é um forte aliado para descrição de sistemas complexos e distribuídos onde os hardwares envolvidos tem um papel crucial na execução da aplicação. Claro que todos os softwares são codependentes do hardware, porém em alguns casos o hardware se torna o recurso mais prioritário. Por exemplo, em um software na nuvem onde queremos fazer backups diários usando a infraestrutura da empresa Amazon, é extremamente importante que se determine e explicite todos os recursos a serem utilizados no diagrama, bem como o número de servidores a serem comunicados, interligados pelos estereótipos dos meios ou protocolos de comunicação, a segurança da aplicação, etc.

 

Pedro Oziel Escobar da Silva

Chonoles, M. J., & Schardt, J. A. (2003). UML 2 for Dummies. Hungry Minds.

Guedes, G. T. (2007). UML UMA ABORDAGEM PRÁTICA. Novatec.

Diagramas Estruturais da UML: Diagramas de Componentes

O Diagrama de Componentes apresenta uma visão estática de como o sistema será implementado e quais os componentes utilizados. Através deste diagrama, são identificados os arquivos que irão compor o software em termos de módulos, bibliotecas, formulários, etc., além de identificar os relacionamentos destes. Além de modelar os componentes, este diagrama destaca a função de cada componente, facilitando a sua reutilização em outros sistemas.

É utilizado para:

  • Modelar os dados do código fonte, do código executável do software.
  • Destacar a função de cada módulo para facilitar a sua reutilização.
  • Auxiliar no processo de engenharia reversa, por meio da organização dos módulos do sistema e seus relacionamentos.

Componente

Um componente é um nome genérico dado à menor parte a ser considerada na modelagem do sistema (uma classe, uma função, uma parte de um hardware, etc.). Os símbolos de componentes podem ser:

Um componente pode apresentar um estereótipo, i.e., uma definição do que este componente é. Os principais estereótipos são:

  • Arquivo: determina que o componente é um arquivo de dados do sistema. Por exemplo um arquivo texto manipulado por um programa.
  • Biblioteca: determina que o componente é uma biblioteca de código por exemplo um componente pode ser a biblioteca stdio.h da linguagem C.
  • Documento: determina que o componente é um documento de sistema (por exemplo arquivo de ajuda, documentação, etc.)
  • Executável: determina que o componente é um arquivo executável (por exemplo parte de aplicação, módulos compilador, etc.)
  • Tabela: determina que o componente é uma tabela de um banco de dados.

Interface fornecida

Designa uma interface que o próprio componente possui e oferece para outros componentes. Isto significa que o componente só pode ser acessado pela interface fornecida.

Esta interface possui a forma de um pirulito:

Interface requerida

Designa uma interface necessária para que o componente se comunique com outros componentes. Esta interface será conectada, então, em uma interface fornecida de outro sistema.

Classes e componentes internos

Um componente pode possuir classes e componentes internos.  Chamamos de visão caixa preta quando um ou mais componentes não apresentam seus elementos internos, enquanto caixa branca é o nome dado quando os componentes apresentam seus elementos internos.

Portas

Porta são elementos que permitem que elementos internos possam se comunicar com elementos externos do componente.

REVISTABW. UML: Diagrama de Componentes. Revista Brasileira de Web: Tecnologia. Disponível em http://www.revistabw.com.br/revistabw/uml-diagrama-de-componentes/. Criado em: 26/12/2013. Última atualização: 24/07/2015. Visitado em: 27/04/2017

 

Paulo Ricco Sirtoli

Diagramas Estruturais da UML: Diagrama de Objetos

O diagrama de objetos permite uma visão de um conjunto de instancias existentes em determinado momento de execução do programa, ou seja, o diagrama de objetos é uma “fotografia” das instancias das classes.

Afinal, diagrama de objetos é a mesma coisa que diagrama de classes?

Figura 1: Afinal, diagrama de objetos é a mesma coisa que diagrama de classes?

O diagrama de objetos não é uma representação do diagrama de classes mas sim uma variação dele.

O diagrama de objetos utiliza uma notação semelhante a usada nos diagramas de classes, entretanto, enquanto o diagrama de classes representa a estrutura de relações de classes que servem de modelo para objetos, os diagramas de objetos mostram instancias e links entre estas instancias.

Abaixo vemos um diagrama de classes simplificado para um sistema de locadora de veículos.

Figura 2: Diagrama de Classes

A seguir vemos um diagrama de objetos criado a partir do diagrama de classes acima. Este diagrama consiste em um cliente (clienteAtual) que em uma locadora (locadoraAtual) realizou dois alugueis (aluguel1, aluguel2) de dois carros (carro1, carro2).

Figura 3: Diagrama de Objetos

Dicas

  • Use o diagrama de objetos como meio para depurar uma funcionalidade do sistema;
  • Diagrama de objetos podem também ser usados para verificar se o sistema foi desenvolvido conforme os requisitos e muitas vezes analisar como a regra de negócio do sistema responde;
  • Mostre associações de qualquer tipo entre objetos somente com uma ligação (por exemplo, uma linha única juntando dois objetos, sem setas), e não como uma dependência ou qualquer outro tipo de associação. Um diagrama de objetos mostra somente associações e não os tipos de associações;
  • Evite representar todos os objetos do seu sistema em um diagrama de objetos pois um diagrama de objetos representa um estado do objeto. É melhor representar somente o estado dos objetos de um processo crítico ou importante da aplicação pois isto vai facilitar a leitura do diagrama.

Os diagramas de objetos não são tão importantes como os diagramas de classes, porem eles são complementares de modo a exemplificar diagramas complexos ajudando na compreensão do sistema.

Leitura complementar: http://www.developer.com/design/article.php/2223551/Object-Diagrams-in-UML.htm

Patrik Guerra

Diagramas Estruturais da UML: Diagrama de Classes

O diagrama de classes faz parte do conjunto de diagramas estruturais UML (Unified Modeling Language). Esse conjunto de diagramas foi concebido para facilitar no planejamento do desenvolvimento de softwares. O diagrama de classe em especifico busca demonstrar como as classes funcionarão em um projeto de desenvolvimento, que utiliza a orientação a objetos.

Um diagrama de classe é composto por entidades e seus relacionamentos. Suas entidades podem ser divididas entre classes e interfaces. As classes são representadas no formato de retângulos onde a primeira linha é o nome da classe, a segunda seus atributos e a última os seus métodos.  As classes também podem ser representadas concretamente ou de forma abstrata, bastando que para isso seu nome seja escrito em itálico (para classes abstratas). Para representar seus atributos e métodos como privados ou públicos pode ser adotado o sinal de “-” para privado e “+” para público.

Figura 1: Classes abstratas e concretas

Os diagramas de classe contam também com vários componentes, que permitem com que os softwares sejam representando de maneira muito clara na forma de diagramas, os mais utilizados são:

Navegabilidade e multiplicidade: As ligações entre as classes podem ser feitas tanto de forma simples, quanto de maneira mais restrita. Uma ligação simples é representada apenas por uma linha ligando as classes, ou seja, a navegabilidade entre as classes é nos dois sentidos. Como mostrado no “exemplo 1”, onde uma motocicleta pode ter rodas e as rodas podem ter uma motocicleta. Essa representação pode ser um pouco mais restrita, representando melhor a realidade como no (exemplo 2). Onde a navegabilidade é representada por uma seta, demonstrando que uma motocicleta possui as rodas e não o contrário, além da especificação da quantidade dessas rodas sendo demonstrada atravesses de números ao lado das classes (multiplicidade), significando que uma motocicleta pode ter 2 rodas e as rodas são contidas em uma motocicleta.

Figura 2: Ligações entre classes

Herança: representada pelo símbolo de uma seta fechada e com linha continua. O lado em que a seta aponta é a classe que está sendo herdada.

Figura 3: Herança

Implementação: Interfaces podem ser representadas por círculos ou também por retângulos com a identificação de interfaces. No caso da primeira opção basta ligar a classe a interface com uma linha continua que simboliza a implementação, já na segunda é utilizada uma seta fechada com linha tracejada.

Figura 4: Implementação de interfaces

Os diagramas de classe são totalmente voltados a orientação a objetos, possuem três tipos de perspectivas de representação, são elas:

-Conceitual: os diagramas são representados em um domínio mais abstrato, sua forma de demonstrar os acontecimentos é mais voltada para o cliente.

-Especificação: nessa perspectiva os diagramas são voltados a um modo de representação da arquitetura do sistema, demonstrando seus principais métodos, mas não como será feita sua implementação. Voltada para pessoas que não necessariamente precisam saber como o projeto vai ser desenvolvido, mas sim somente como será feita sua estrutura. (Gerentes de projeto).

-Implementação: maneira onde o diagrama demonstra os detalhes de como será a implementação, demonstrando a estrutura das classes e seus atributos. Perspectiva mais voltada aos desenvolvedores, que precisam saber os detalhes das classes.

Figura 5: Perspectivas dos diagramas

Graças a essas características os diagramas de classe são excelentes ferramentas para modelagem de sistemas, sejam eles complexos ou simples. Com o uso dos diagramas de classe os sistemas podem ser fielmente representados, de uma maneira que seja fácil de entender e ao mesmo tempo seja útil, facilitando o desenvolvimento do software.

Patrick Pronobi Rodrigues

Diagramas Comportamentais da UML: Diagrama de Estados

A UML(Unified Modeling Language) prevê um diagrama específico para modelar os diversos estados de um objeto durante o seu ciclo de vida. Tal diagrama é chamado de diagrama de estados.

Muito utilizado na área de eletrônica digital e em engenharia de software, um diagrama de estado é a representação de um estado ou situação em que um objeto se encontra no decorrer da execução dos processos de um sistema. É uma maneira eficiente e clara de descrever todos os possíveis estados de um sistema, assim como quais eventos levam transição de um estado para outro.

Os diagramas de estado representam uma alternativa para o diagrama de casos de uso. Geralmente, os diagramas de caso de uso são utilizados durante a etapa de análise do sistema, e os diagramas de estados, durante a etapa de projeto do sistema. O foco principal dos diagramas de estados reside na identificação dos valores que os atributos de uma classe podem assumir, assim como os eventos ou mensagens enviadas para o objeto que efetivamente implicará na atribuição dos valores.

Diagramas de estados podem ser concebidos englobando diversos objetos, porém, o ideal é modelar diagramas de estados individuais para cada objeto e utilizar outros diagramas para ilustrar como diferentes objetos interagem durante a execução do sistema.

Elementos de um Diagrama de Estados

Estado Inicial – Ponto de entrada da utilização do objeto, pode ser sua instanciação ou sua reinicialização do mesmo para um estado estável inicial.

Estado Final – Ponto de saída da utilização do objeto, pode ser sua destruição ou o ato de deixar de ser utilizado.

Estado – Possível estado que o objeto pode se encontrar em cada momento. É definido como sendo a identificação dos atributos que o compõe. Um estado pode demonstrar a espera pela ocorrência de um evento, a reação a um estímulo, a execução de alguma atividade ou a satisfação de alguma condição.

Evento – Também chamado de transição, representa uma ação externa sobre o objeto.

Verificação de um Diagrama de Estados

Após a criação de um diagrama de estados, precisamos verificar se o mesmo é consistente, como cada verificação é específica para cada diagrama, pois depende diretamente da mecânica da classe e do problema se se propõe a resolver, podemos verificar de uma forma sistemática cada diagrama de estados respondendo às seguintes perguntas:
1 – Todos os estados podem ser atingidos?
2 – A partir de qualquer estado, existe um caminho que leve para o estado final?
3 – Todos os estados possíveis que o objeto pode assumir foram definidos?
4 – Cada estado reage adequadamente a todos os possíveis eventos?

Exemplos de Diagramas de Estados

Um exemplo simples seria um semáforo onde cada estado corresponde a uma situação que ocorrerá. Quando verde, os carros podem prosseguir na via. Passado um tempo, é acionada a tarefa de mudar para amarelo. Então o semáforo passa de verde para amarelo. Aqui os carros ficam em estado de atenção e já aguardam a próxima transição.
O próximo passo é passar para vermelho. Nesse estado, os carros estão parados na via. De vermelho, o próximo estado somente será verde, assim, os carros podem voltar a trafegar na via.

Outro exemplo simples seria a troca de estações do ano. Onde cada estação possui seu tempo de duração, após esse tempo ter se esgotado, uma transição de estados ocorre e a estação passa ao seu próximo estado, com sua determinada duração.

 

Diagrama de Atividade

Oriundo do Diagrama de Máquina de Estados, este diagrama enfatiza a sequência e condições para descrever um processo computacional completo de uma atividade. Como já observado, é um dos mais detalhistas diagramas da UML, muito semelhante aos fluxogramas utilizados para lógica de programação. Está sempre associado a um Caso de Uso, descrevendo as atividades executadas pelo Ator e pelo Sistema. Composto por estados que representam as atividades e ações que representam as transições, já foi considerado uma parte especial do Diagrama de Gráficos de Estados, porém a partir da versão 2.0 da UML, tornou-se totalmente independente.

Este diagrama preocupa-se em descrever os passos a serem percorridos para a conclusão de um método ou algoritmo específico, ou seja, tem como objetivo principal a especificação do comportamento do software do ponto de vista funcional e das suas funcionalidades e não um processo completo como é o diagrama de sequência, e possui três estados obrigatórios:

  • Estado Inicial;
  • Estado de Ação;
  • Estado Final.

É também utilizado para modelar dois tipos específicos de fluxos, o Fluxo de Controle e o Fluxo de Objetos.

Figura 1 – Esquema exemplificando o Diagrama de Atividade

Principais Elementos de Utilização

Estados Iniciais e Finais: Todos os diagramas de atividades possuem pelo menos um estado inicial e pelo menos um estado final. O Estado inicial indica o início do processo enquanto o estado final indica o fim do processo:

Figura 2 – Exemplo de Estado inicial e final

Atividades: Representados por um retângulo com as bordas arredondadas, equivalem as atividades ou ações que devem ser feitas. Quando a referida ação é finalizada, transfere a execução para a próxima atividade:

Figura 3 – Exemplo de Atividade

Transições: Setas contínuas que representam o fluxo de trabalho de uma atividade para outra, ou seja, o “caminho” a ser seguido para a conclusão do processo:

Figura 4 – Exemplo de Transição entre Atividades

Ponto de Decisão / Desvio: Representa uma escolha entre dois ou mais fluxos em que um dos fluxos será escolhido em detrimento dos outros. É representado pela figura de um losango:

Figura 5 – Exemplo de nó de decisão

Condição de Guarda: Condiciona a ocorrência de uma transição para a execução de uma atividade, geralmente é utilizada após um ponto de decisão:

Figura 6 – Exemplo de Condição de Guarda

Barras de Sincronização – Bifurcação/ União: Representam a execução de atividades concorrentes e independentes. Na condição de Bifurcação ou Fork, as atividades associadas continuam seu processamento paralelo. Já na condição de União ou Join, as atividades concorrentes são novamente sincronizadas em um único processo:

Figura 7 – Exemplo de Fork e Join

Raias: Representam uma forma de organização lógica das atividades. Podem estar associadas a objetos, componentes ou atores do sistema:

Figura 8 – Exemplo da utilização de Raias

Eventos: Eventos são mudanças de estado instantâneas que propiciam o início de uma outra ação. Existem basicamente três representações para eventos: únicos, periódicos e deliberados:

Figura 9 – Exemplo de utilização de Eventos

Nós de Objetos: Representam a instância de uma classe, que pode estar disponível em um determinado momento da atividade. É útil para mostrar o fluxo de dados acontecendo em um processo, e foi inserido a partir da versão 2.0 da UML:

Figura 10 – Exemplo de utilização de objetos

Exemplo Ilustrativo de Utilização do Diagrama de Atividade

Basicamente, temos referências a dois módulos nas duas Raias (Cadastro de Cliente e E-mail Marketing), e trata-se de um fluxo do sistema, onde um cliente após ser cadastrado sofre uma avaliação, e dependendo do resultado da avaliação (feita através do software) o fluxo pode tomar caminhos diferentes. Se todo o fluxo se completar, antes de encerrar-se, o cliente vai para uma situação de “espera”, onde outro fluxo, por exemplo, tratará o envio de uma nova oferta ao cliente que passou em todas as etapas:

Figura 11 – Exemplo completo de Diagrama de Atividade

Podemos identificar que o uso do Diagrama de Atividade é uma excelente opção para a especificação funcional de um software, desde que sua utilização seja empregada ao fim a que se destina. Mapear processos de forma que o desenvolvedor possa visualizar a funcionalidade isolada propicia um nível de controle e de abstração perfeitos de cada ponto do sistema e o deixa bem próximo do negócio. Também, dentro de suas limitações, pode ser utilizado por pessoas menos técnicas e até mesmo usuários para o entendimento dos processos de funcionamento gerais.

 

Os Diagramas Comportamentais da UML


Diagramas comportamentais são aqueles onde existe alguma alteração de comportamento das classes. Os principais diagramas comportamentais da UML são: Diagrama de Caso de Uso, Diagrama de Seqüência e Diagrama de Atividade. Este artigo tem o objetivo de descrever as principais características destes diagramas.

A UML permite que os desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados propiciando uma notação gráfica facilmente entendível com a um explicação significativa. Continue lendo “Os Diagramas Comportamentais da UML”