UML - Guia Rápido

UML é uma linguagem padrão para especificar, visualizar, construir e documentar os artefatos de sistemas de software.

A UML foi criada pelo Object Management Group (OMG) e o rascunho da especificação UML 1.0 foi proposto ao OMG em janeiro de 1997.

OMG está continuamente fazendo esforços para criar um verdadeiro padrão da indústria.

UML significa Unified Modeling Language.
UML é diferente de outras linguagens de programação comuns, como C ++, Java, COBOL, etc.
UML é uma linguagem pictórica usada para fazer projetos de software.
UML pode ser descrita como uma linguagem de modelagem visual de propósito geral para visualizar, especificar, construir e documentar o sistema de software.
Embora a UML seja geralmente usada para modelar sistemas de software, ela não está limitada a esse limite. Também é usado para modelar sistemas que não sejam de software. Por exemplo, o fluxo do processo em uma unidade de manufatura, etc.

UML não é uma linguagem de programação, mas as ferramentas podem ser usadas para gerar código em várias linguagens usando diagramas UML. UML tem uma relação direta com a análise e design orientado a objetos. Após alguma padronização, UML se tornou um padrão OMG.

Objetivos da UML

Uma imagem vale mais que mil palavras , esse idioma se encaixa perfeitamente na descrição de UML. Os conceitos orientados a objetos foram introduzidos muito antes da UML. Naquela época, não havia metodologias padronizadas para organizar e consolidar o desenvolvimento orientado a objetos. Foi então que a UML entrou em cena.

Existem vários objetivos para desenvolver UML, mas o mais importante é definir alguma linguagem de modelagem de propósito geral, que todos os modeladores podem usar e também precisa ser simplificada para entender e usar.

Os diagramas UML não são feitos apenas para desenvolvedores, mas também para usuários de negócios, pessoas comuns e qualquer pessoa interessada em entender o sistema. O sistema pode ser um sistema de software ou não. Portanto, deve ficar claro que UML não é um método de desenvolvimento, mas sim acompanha processos para torná-lo um sistema de sucesso.

Em conclusão, o objetivo da UML pode ser definido como um mecanismo de modelagem simples para modelar todos os sistemas práticos possíveis no ambiente complexo de hoje.

Um modelo conceitual de UML

Para entender o modelo conceitual da UML, primeiro precisamos esclarecer o que é um modelo conceitual? e por que um modelo conceitual é necessário?

Um modelo conceitual pode ser definido como um modelo feito de conceitos e seus relacionamentos.
Um modelo conceitual é a primeira etapa antes de desenhar um diagrama UML. Ajuda a compreender as entidades do mundo real e como elas interagem umas com as outras.

Como a UML descreve os sistemas de tempo real, é muito importante fazer um modelo conceitual e prosseguir gradualmente. O modelo conceitual de UML pode ser dominado aprendendo os seguintes três elementos principais -

Blocos de construção UML
Regras para conectar os blocos de construção
Mecanismos comuns de UML

Conceitos Orientados a Objetos

A UML pode ser descrita como a sucessora da análise e design orientado a objetos (OO).

Um objeto contém dados e métodos que controlam os dados. Os dados representam o estado do objeto. Uma classe descreve um objeto e eles também formam uma hierarquia para modelar o sistema do mundo real. A hierarquia é representada como herança e as classes também podem ser associadas de diferentes maneiras de acordo com o requisito.

Os objetos são as entidades do mundo real que existem ao nosso redor e os conceitos básicos, como abstração, encapsulamento, herança e polimorfismo, todos podem ser representados usando UML.

A UML é poderosa o suficiente para representar todos os conceitos que existem na análise e design orientado a objetos. Os diagramas UML são representações apenas de conceitos orientados a objetos. Portanto, antes de aprender UML, torna-se importante entender o conceito OO em detalhes.

A seguir estão alguns conceitos fundamentais do mundo orientado a objetos -

Objects - Os objetos representam uma entidade e o bloco de construção básico.
Class - A classe é a planta de um objeto.
Abstraction - A abstração representa o comportamento de uma entidade do mundo real.
Encapsulation - Encapsulamento é o mecanismo de vincular os dados e ocultá-los do mundo exterior.
Inheritance - Herança é o mecanismo de fazer novas classes a partir das existentes.
Polymorphism - Define o mecanismo para existir em diferentes formas.

Análise e Design OO

OO pode ser definido como uma investigação e, para ser mais específico, é a investigação de objetos. Design significa colaboração de objetos identificados.

Portanto, é importante entender os conceitos de análise e design OO. O propósito mais importante da análise OO é identificar os objetos de um sistema a ser projetado. Essa análise também é feita para um sistema existente. Agora, uma análise eficiente só é possível quando somos capazes de começar a pensar de uma forma onde os objetos possam ser identificados. Depois de identificar os objetos, seus relacionamentos são identificados e, finalmente, o design é produzido.

O objetivo da análise e design OO pode ser descrito como -

Identificando os objetos de um sistema.
Identificando seus relacionamentos.
Fazendo um design, que pode ser convertido em executáveis usando linguagens OO.

Existem três etapas básicas onde os conceitos OO são aplicados e implementados. As etapas podem ser definidas como

OO Analysis → OO Design → OO implementation using OO languages

Os três pontos acima podem ser descritos em detalhes como -

Durante a análise OO, o propósito mais importante é identificar objetos e descrevê-los de maneira adequada. Se esses objetos forem identificados de forma eficiente, o próximo trabalho de design será fácil. Os objetos devem ser identificados com responsabilidades. Responsabilidades são as funções desempenhadas pelo objeto. Todo e qualquer objeto tem algum tipo de responsabilidades a serem desempenhadas. Quando essas responsabilidades são colaboradas, o propósito do sistema é cumprido.
A segunda fase é o design OO. Durante esta fase, a ênfase é colocada nos requisitos e no seu cumprimento. Nesta etapa, os objetos são colaborados de acordo com a associação pretendida. Depois que a associação for concluída, o design também estará concluído.
A terceira fase é a implementação OO. Nesta fase, o design é implementado usando linguagens OO como Java, C ++, etc.

Papel da UML no design OO

UML é uma linguagem de modelagem usada para modelar sistemas de software e não software. Embora a UML seja usada para sistemas que não sejam de software, a ênfase está na modelagem de aplicativos de software OO. A maioria dos diagramas UML discutidos até agora são usados para modelar diferentes aspectos, como estático, dinâmico, etc. Agora, qualquer que seja o aspecto, os artefatos nada mais são do que objetos.

Se olharmos para o diagrama de classe, diagrama de objeto, diagrama de colaboração, diagramas de interação, todos seriam basicamente projetados com base nos objetos.

Portanto, a relação entre o projeto OO e UML é muito importante para entender. O design OO é transformado em diagramas UML de acordo com o requisito. Antes de entender a UML em detalhes, o conceito OO deve ser aprendido adequadamente. Depois que a análise e o design OO estiverem concluídos, a próxima etapa é muito fácil. A entrada da análise e design OO é a entrada para os diagramas UML.

Blocos de construção UML
Regras para conectar os blocos de construção
Mecanismos comuns de UML

Este capítulo descreve todos os blocos de construção da UML. Os blocos de construção da UML podem ser definidos como -

Things
Relationships
Diagrams

Coisas

Thingssão os blocos de construção mais importantes da UML. As coisas podem ser -

Structural
Behavioral
Grouping
Annotational

Coisas Estruturais

Structural thingsdefinir a parte estática do modelo. Eles representam os elementos físicos e conceituais. A seguir estão as breves descrições das coisas estruturais.

Class − Classe representa um conjunto de objetos com responsabilidades semelhantes.

Interface − Interface define um conjunto de operações, que especificam a responsabilidade de uma classe.

Collaboration −Colaboração define uma interação entre elementos.

Use case −O caso de uso representa um conjunto de ações executadas por um sistema para um objetivo específico.

Component −O componente descreve a parte física de um sistema.

Node − Um nó pode ser definido como um elemento físico que existe em tempo de execução.

Coisas Comportamentais

A behavioral thingconsiste nas partes dinâmicas dos modelos UML. A seguir estão as coisas comportamentais -

Interaction − A interação é definida como um comportamento que consiste em um grupo de mensagens trocadas entre elementos para realizar uma tarefa específica.

State machine −A máquina de estado é útil quando o estado de um objeto em seu ciclo de vida é importante. Ele define a sequência de estados pelos quais um objeto passa em resposta a eventos. Os eventos são fatores externos responsáveis pela mudança de estado

Agrupando Coisas

Grouping thingspode ser definido como um mecanismo para agrupar elementos de um modelo UML. Existe apenas uma coisa de agrupamento disponível -

Package − Pacote é o único agrupamento disponível para reunir itens estruturais e comportamentais.

Coisas Anotacionais

Annotational things pode ser definido como um mecanismo para capturar comentários, descrições e comentários de elementos de modelo UML. Note- É a única coisa anotacional disponível. Uma nota é usada para renderizar comentários, restrições, etc. de um elemento UML.

Relação

Relationshipé outro bloco de construção mais importante da UML. Mostra como os elementos estão associados entre si e essa associação descreve a funcionalidade de um aplicativo.

Existem quatro tipos de relacionamento disponíveis.

Dependência

Dependência é uma relação entre duas coisas em que a mudança em um elemento também afeta o outro.

Associação

Associação é basicamente um conjunto de links que conecta os elementos de um modelo UML. Ele também descreve quantos objetos estão participando desse relacionamento.

Generalização

A generalização pode ser definida como uma relação que conecta um elemento especializado a um elemento generalizado. Basicamente, descreve a relação de herança no mundo dos objetos.

Realização

A realização pode ser definida como um relacionamento no qual dois elementos estão conectados. Um elemento descreve algumas responsabilidades, que não são implementadas, e o outro as implementa. Esse relacionamento existe no caso de interfaces.

Diagramas UML

Os diagramas UML são o resultado final de toda a discussão. Todos os elementos, relacionamentos são usados para fazer um diagrama UML completo e o diagrama representa um sistema.

O efeito visual do diagrama UML é a parte mais importante de todo o processo. Todos os outros elementos são usados para torná-lo completo.

A UML inclui os nove diagramas a seguir, cujos detalhes são descritos nos capítulos subsequentes.

Diagrama de classes
Diagrama de objeto
Diagrama de casos de uso
Diagrama de sequência
Diagrama de colaboração
Diagrama de atividades
Diagrama Statechart
Diagrama de implantação
Diagrama de componentes

Qualquer sistema do mundo real é usado por diferentes usuários. Os usuários podem ser desenvolvedores, testadores, executivos, analistas e muitos mais. Portanto, antes de projetar um sistema, a arquitetura é feita com diferentes perspectivas em mente. A parte mais importante é visualizar o sistema da perspectiva de diferentes visualizadores. Quanto melhor entendermos, melhor podemos construir o sistema.

A UML desempenha um papel importante na definição de diferentes perspectivas de um sistema. Essas perspectivas são -

Design
Implementation
Process
Deployment

O centro é o Use Casevista que conecta todos esses quatro. UMAUse Caserepresenta a funcionalidade do sistema. Portanto, outras perspectivas estão conectadas ao caso de uso.

Designde um sistema consiste em classes, interfaces e colaboração. UML fornece diagrama de classe, diagrama de objeto para dar suporte a isso.

Implementationdefine os componentes montados juntos para formar um sistema físico completo. O diagrama de componentes UML é usado para apoiar a perspectiva de implementação.

Processdefine o fluxo do sistema. Portanto, os mesmos elementos usados no Design também são usados para apoiar essa perspectiva.

Deploymentrepresenta os nós físicos do sistema que forma o hardware. O diagrama de implantação UML é usado para dar suporte a essa perspectiva.

É muito importante distinguir entre o modelo UML. Diferentes diagramas são usados para diferentes tipos de modelagem UML. Existem três tipos importantes de modelagem UML.

Modelagem Estrutural

A modelagem estrutural captura os recursos estáticos de um sistema. Eles consistem no seguinte -

Diagramas de classes
Diagramas de objetos
Diagramas de implantação
Diagramas de pacotes
Diagrama de estrutura composta
Diagrama de componentes

O modelo estrutural representa a estrutura para o sistema e esta estrutura é o local onde todos os outros componentes existem. Portanto, o diagrama de classe, o diagrama de componente e os diagramas de implantação fazem parte da modelagem estrutural. Todos eles representam os elementos e o mecanismo para montá-los.

O modelo estrutural nunca descreve o comportamento dinâmico do sistema. O diagrama de classes é o diagrama estrutural mais amplamente usado.

Modelagem Comportamental

O modelo comportamental descreve a interação no sistema. Ele representa a interação entre os diagramas estruturais. A modelagem comportamental mostra a natureza dinâmica do sistema. Eles consistem no seguinte -

Diagramas de atividades
Diagramas de interação
Diagramas de caso de uso

Todos os itens acima mostram a sequência dinâmica de fluxo em um sistema.

Modelagem Arquitetônica

O modelo arquitetônico representa a estrutura geral do sistema. Ele contém elementos estruturais e comportamentais do sistema. O modelo arquitetônico pode ser definido como o projeto de todo o sistema. O diagrama do pacote está incluído na modelagem arquitetônica.

UML é popular por suas notações diagramáticas. Todos nós sabemos que UML serve para visualizar, especificar, construir e documentar os componentes de sistemas de software e não software. Portanto, a visualização é a parte mais importante que precisa ser compreendida e lembrada.

As notações UML são os elementos mais importantes na modelagem. O uso eficiente e apropriado de notações é muito importante para fazer um modelo completo e significativo. O modelo é inútil, a menos que seu propósito seja representado corretamente.

Portanto, as notações de aprendizagem devem ser enfatizadas desde o início. Diferentes notações estão disponíveis para coisas e relacionamentos. Os diagramas UML são feitos usando as notações de coisas e relacionamentos. A extensibilidade é outro recurso importante que torna a UML mais poderosa e flexível.

O capítulo descreve as notações UML básicas em detalhes. Esta é apenas uma extensão da seção de blocos de construção da UML discutida no Capítulo Dois.

Coisas Estruturais

Notações gráficas usadas em coisas estruturais são mais amplamente usadas em UML. Estes são considerados os substantivos dos modelos UML. A seguir está a lista de itens estruturais.

Classes
Object
Interface
Collaboration
Caso de uso
Aulas ativas
Components
Nodes

Notação de classe

A classe UML é representada pela figura a seguir. O diagrama está dividido em quatro partes.

A seção superior é usada para nomear a classe.
O segundo é usado para mostrar os atributos da classe.
A terceira seção é usada para descrever as operações realizadas pela classe.
A quarta seção é opcional para mostrar quaisquer componentes adicionais.

As classes são usadas para representar objetos. Objetos podem ser qualquer coisa com propriedades e responsabilidade.

Notação de Objeto

O objeto é representado da mesma forma que a classe. A única diferença é o nome que está sublinhado conforme mostrado na figura a seguir.

Como o objeto é uma implementação real de uma classe, que é conhecida como a instância de uma classe. Portanto, ele tem o mesmo uso da classe.

Notação de interface

A interface é representada por um círculo, conforme mostrado na figura a seguir. Tem um nome que geralmente é escrito abaixo do círculo.

Interface é usada para descrever a funcionalidade sem implementação. A interface é como um modelo em que você define diferentes funções, não a implementação. Quando uma classe implementa a interface, ela também implementa a funcionalidade conforme o requisito.

Notação de colaboração

A colaboração é representada por um eclipse pontilhado, conforme mostrado na figura a seguir. Tem um nome escrito dentro do eclipse.

Colaboração representa responsabilidades. Geralmente, as responsabilidades estão em um grupo.

Use Case Notation

O caso de uso é representado como um eclipse com um nome dentro dele. Pode conter responsabilidades adicionais.

O caso de uso é usado para capturar funcionalidades de alto nível de um sistema.

Notação do ator

Um ator pode ser definido como alguma entidade interna ou externa que interage com o sistema.

Um ator é usado em um diagrama de caso de uso para descrever as entidades internas ou externas.

Notação de estado inicial

O estado inicial é definido para mostrar o início de um processo. Essa notação é usada em quase todos os diagramas.

O uso da notação de estado inicial é para mostrar o ponto de partida de um processo.

Notação de estado final

O estado final é usado para mostrar o fim de um processo. Essa notação também é usada em quase todos os diagramas para descrever o final.

O uso da notação de estado final é para mostrar o ponto de término de um processo.

Notação de classe ativa

A classe ativa é semelhante a uma classe com uma borda sólida. A classe ativa geralmente é usada para descrever o comportamento simultâneo de um sistema.

A classe ativa é usada para representar a simultaneidade em um sistema.

Notação de Componente

Um componente em UML é mostrado na figura a seguir com um nome dentro. Elementos adicionais podem ser adicionados sempre que necessário.

O componente é usado para representar qualquer parte de um sistema para o qual os diagramas UML são feitos.

Notação de Nó

Um nó em UML é representado por uma caixa quadrada, conforme mostrado na figura a seguir, com um nome. Um nó representa o componente físico do sistema.

O nó é usado para representar a parte física de um sistema, como servidor, rede, etc.

Coisas Comportamentais

As partes dinâmicas são um dos elementos mais importantes na UML. UML possui um conjunto de recursos poderosos para representar a parte dinâmica dos sistemas de software e não software. Esses recursos incluem interações e máquinas de estado .

As interações podem ser de dois tipos -

Sequencial (representado pelo diagrama de sequência)
Colaborativo (representado pelo diagrama de colaboração)

Notação de interação

A interação é basicamente uma troca de mensagens entre dois componentes UML. O diagrama a seguir representa diferentes notações usadas em uma interação.

A interação é usada para representar a comunicação entre os componentes de um sistema.

Notação de máquina de estado

Máquina de estado descreve os diferentes estados de um componente em seu ciclo de vida. As notações são descritas no diagrama a seguir.

Máquina de estado é usada para descrever diferentes estados de um componente do sistema. O estado pode ser ativo, inativo ou qualquer outro, dependendo da situação.

Agrupando Coisas

Organizar os modelos UML é um dos aspectos mais importantes do design. Em UML, há apenas um elemento disponível para agrupamento e esse é o pacote.

Notação de pacote

A notação de pacote é mostrada na figura a seguir e é usada para envolver os componentes de um sistema.

Coisas Anotacionais

Em qualquer diagrama, a explicação dos diferentes elementos e suas funcionalidades são muito importantes. Portanto, a UML tem notações de notas para dar suporte a esse requisito.

Notação de notas

Essa notação é mostrada na figura a seguir. Essas notações são usadas para fornecer as informações necessárias de um sistema.

Relacionamentos

Um modelo não está completo a menos que as relações entre os elementos sejam descritas corretamente. O relacionamento dá um significado adequado a um modelo UML. A seguir estão os diferentes tipos de relacionamentos disponíveis em UML.

Dependency
Association
Generalization
Extensibility

Notação de Dependência

Dependência é um aspecto importante nos elementos UML. Ele descreve os elementos dependentes e a direção da dependência.

A dependência é representada por uma seta pontilhada, conforme mostrado na figura a seguir. A ponta da seta representa o elemento independente e a outra extremidade representa o elemento dependente.

Dependência é usada para representar a dependência entre dois elementos de um sistema

Notação de Associação

Associação descreve como os elementos em um diagrama UML são associados. Em palavras simples, ele descreve quantos elementos estão participando de uma interação.

A associação é representada por uma linha pontilhada com (sem) setas em ambos os lados. As duas extremidades representam dois elementos associados, conforme mostrado na figura a seguir. A multiplicidade também é mencionada nas extremidades (1, *, etc.) para mostrar quantos objetos estão associados.

Associação é usada para representar o relacionamento entre dois elementos de um sistema.

Notação de generalização

A generalização descreve a relação de herança do mundo orientado a objetos. É um relacionamento entre pais e filhos.

A generalização é representada por uma seta com uma ponta de seta oca, conforme mostrado na figura a seguir. Uma extremidade representa o elemento pai e a outra extremidade representa o elemento filho.

A generalização é usada para descrever a relação pai-filho de dois elementos de um sistema.

Notação de extensibilidade

Todas as linguagens (programação ou modelagem) possuem algum mecanismo para estender seus recursos, como sintaxe, semântica, etc. UML também possui os seguintes mecanismos para fornecer recursos de extensibilidade.

Estereótipos (representa novos elementos)
Valores marcados (representam novos atributos)
Restrições (representa os limites)

As notações de extensibilidade são usadas para aumentar o poder da linguagem. São basicamente elementos adicionais usados para representar algum comportamento extra do sistema. Esses comportamentos extras não são cobertos pelas notações padrão disponíveis.

Nos capítulos anteriores, discutimos sobre os blocos de construção e outros elementos necessários da UML. Agora precisamos entender onde usar esses elementos.

Os elementos são como componentes que podem ser associados de diferentes maneiras para formar uma imagem UML completa, que é conhecida como diagrama. Assim, é muito importante entender os diferentes diagramas para implementar o conhecimento em sistemas da vida real.

Qualquer sistema complexo é melhor compreendido fazendo algum tipo de diagramas ou imagens. Esses diagramas têm um impacto melhor em nossa compreensão. Se olharmos ao redor, perceberemos que os diagramas não são um conceito novo, mas são amplamente usados de diferentes formas em diferentes setores.

Preparamos diagramas UML para entender o sistema de uma maneira melhor e simples. Um único diagrama não é suficiente para cobrir todos os aspectos do sistema. A UML define vários tipos de diagramas para cobrir a maioria dos aspectos de um sistema.

Você também pode criar seu próprio conjunto de diagramas para atender aos seus requisitos. Os diagramas geralmente são feitos de forma incremental e iterativa.

Existem duas grandes categorias de diagramas e eles são novamente divididos em subcategorias -

Diagramas Estruturais
Diagramas Comportamentais

Diagramas Estruturais

Os diagramas estruturais representam o aspecto estático do sistema. Esses aspectos estáticos representam as partes de um diagrama, que formam a estrutura principal e, portanto, são estáveis.

Essas partes estáticas são representadas por classes, interfaces, objetos, componentes e nós. Os quatro diagramas estruturais são -

Diagrama de classes
Diagrama de objeto
Diagrama de componentes
Diagrama de implantação

Diagrama de Classe

Os diagramas de classes são os diagramas mais comuns usados em UML. O diagrama de classes consiste em classes, interfaces, associações e colaboração. Os diagramas de classes representam basicamente a visão orientada a objetos de um sistema, que é estática por natureza.

A classe ativa é usada em um diagrama de classe para representar a simultaneidade do sistema.

O diagrama de classes representa a orientação a objetos de um sistema. Portanto, é geralmente usado para fins de desenvolvimento. Este é o diagrama mais amplamente usado no momento da construção do sistema.

Diagrama de Objeto

Os diagramas de objetos podem ser descritos como uma instância do diagrama de classes. Portanto, esses diagramas estão mais próximos de cenários da vida real onde implementamos um sistema.

Os diagramas de objetos são um conjunto de objetos e seu relacionamento é como os diagramas de classes. Eles também representam a visão estática do sistema.

O uso de diagramas de objetos é semelhante aos diagramas de classes, mas eles são usados para construir protótipos de um sistema de uma perspectiva prática.

Diagrama de Componentes

Os diagramas de componentes representam um conjunto de componentes e seus relacionamentos. Esses componentes consistem em classes, interfaces ou colaborações. Os diagramas de componentes representam a visão de implementação de um sistema.

Durante a fase de design, os artefatos de software (classes, interfaces etc.) de um sistema são organizados em grupos diferentes dependendo de seu relacionamento. Agora, esses grupos são conhecidos como componentes.

Finalmente, pode-se dizer que os diagramas de componentes são utilizados para visualizar a implementação.

Diagrama de implantação

Os diagramas de implantação são um conjunto de nós e seus relacionamentos. Esses nós são entidades físicas onde os componentes são implantados.

Os diagramas de implantação são usados para visualizar a visão de implantação de um sistema. Isso geralmente é usado pela equipe de implantação.

Note- Se as descrições e usos acima forem observados cuidadosamente, então é muito claro que todos os diagramas têm alguma relação uns com os outros. Os diagramas de componentes dependem das classes, interfaces, etc. que fazem parte do diagrama de classes / objetos. Novamente, o diagrama de implantação depende dos componentes, que são usados para fazer diagramas de componentes.

Diagramas Comportamentais

Qualquer sistema pode ter dois aspectos, estático e dinâmico. Portanto, um modelo é considerado completo quando ambos os aspectos estão totalmente cobertos.

Os diagramas comportamentais basicamente capturam o aspecto dinâmico de um sistema. O aspecto dinâmico pode ainda ser descrito como as partes mutáveis / móveis de um sistema.

UML tem os seguintes cinco tipos de diagramas comportamentais -

Diagrama de casos de uso
Diagrama de sequência
Diagrama de colaboração
Diagrama Statechart
Diagrama de atividades

Diagrama de casos de uso

Os diagramas de caso de uso são um conjunto de casos de uso, atores e seus relacionamentos. Eles representam a visão de caso de uso de um sistema.

Um caso de uso representa uma funcionalidade específica de um sistema. Portanto, o diagrama de caso de uso é usado para descrever os relacionamentos entre as funcionalidades e seus controladores internos / externos. Esses controladores são conhecidos comoactors.

Diagrama de sequência

Um diagrama de seqüência é um diagrama de interação. Pelo nome, fica claro que o diagrama lida com algumas sequências, que são a sequência de mensagens que fluem de um objeto para outro.

A interação entre os componentes de um sistema é muito importante do ponto de vista de implementação e execução. O diagrama de sequência é usado para visualizar a sequência de chamadas em um sistema para executar uma funcionalidade específica.

Diagrama de Colaboração

O diagrama de colaboração é outra forma de diagrama de interação. Representa a organização estrutural de um sistema e as mensagens enviadas / recebidas. A organização estrutural consiste em objetos e links.

O objetivo do diagrama de colaboração é semelhante ao diagrama de sequência. No entanto, o propósito específico do diagrama de colaboração é visualizar a organização dos objetos e sua interação.

Diagrama Statechart

Qualquer sistema em tempo real deve ser reagido por algum tipo de eventos internos / externos. Esses eventos são responsáveis pela mudança de estado do sistema.

O diagrama Statechart é usado para representar a mudança de estado orientada a eventos de um sistema. Basicamente, descreve a mudança de estado de uma classe, interface, etc.

O diagrama do gráfico de estado é usado para visualizar a reação de um sistema por fatores internos / externos.

Diagrama de atividades

O diagrama de atividades descreve o fluxo de controle em um sistema. Consiste em atividades e links. O fluxo pode ser sequencial, simultâneo ou ramificado.

As atividades nada mais são do que funções de um sistema. Números de diagramas de atividades são preparados para capturar todo o fluxo em um sistema.

Os diagramas de atividades são usados para visualizar o fluxo de controles em um sistema. Este está preparado para se ter uma ideia de como o sistema funcionará quando executado.

Note- A natureza dinâmica de um sistema é muito difícil de capturar. A UML forneceu recursos para capturar a dinâmica de um sistema de diferentes ângulos. Os diagramas de sequência e os diagramas de colaboração são isomórficos, portanto, podem ser convertidos um do outro sem perder nenhuma informação. Isso também é verdadeiro para Statechart e diagrama de atividades.

O diagrama de classes é um diagrama estático. Ele representa a visão estática de um aplicativo. O diagrama de classes não é usado apenas para visualizar, descrever e documentar diferentes aspectos de um sistema, mas também para construir o código executável do aplicativo de software.

O diagrama de classes descreve os atributos e operações de uma classe e também as restrições impostas ao sistema. Os diagramas de classes são amplamente usados na modelagem de sistemas orientados a objetos porque são os únicos diagramas UML, que podem ser mapeados diretamente com linguagens orientadas a objetos.

O diagrama de classes mostra uma coleção de classes, interfaces, associações, colaborações e restrições. Também é conhecido como diagrama estrutural.

Objetivo dos Diagramas de Classe

O objetivo do diagrama de classes é modelar a visão estática de um aplicativo. Os diagramas de classes são os únicos diagramas que podem ser mapeados diretamente com linguagens orientadas a objetos e, portanto, amplamente usados no momento da construção.

Os diagramas UML, como o diagrama de atividades e o diagrama de sequência, podem fornecer apenas o fluxo de sequência do aplicativo, mas o diagrama de classes é um pouco diferente. É o diagrama UML mais popular na comunidade de codificadores.

O objetivo do diagrama de classes pode ser resumido como -

Análise e desenho da visão estática de uma aplicação.
Descreva as responsabilidades de um sistema.
Base para diagramas de componentes e implantação.
Engenharia direta e reversa.

Como desenhar um diagrama de classes?

Os diagramas de classes são os diagramas UML mais populares usados para a construção de aplicativos de software. É muito importante aprender o procedimento de desenho do diagrama de classes.

Os diagramas de classes têm muitas propriedades a serem consideradas durante o desenho, mas aqui o diagrama será considerado de uma visão de nível superior.

O diagrama de classes é basicamente uma representação gráfica da visão estática do sistema e representa diferentes aspectos do aplicativo. Uma coleção de diagramas de classes representa todo o sistema.

Os seguintes pontos devem ser lembrados ao desenhar um diagrama de classe -

O nome do diagrama de classes deve ser significativo para descrever o aspecto do sistema.
Cada elemento e suas relações devem ser identificados com antecedência.
A responsabilidade (atributos e métodos) de cada classe deve ser claramente identificada
Para cada classe, um número mínimo de propriedades deve ser especificado, pois propriedades desnecessárias tornarão o diagrama complicado.
Use notas sempre que necessário para descrever algum aspecto do diagrama. No final do desenho, deve ser compreensível para o desenvolvedor / codificador.
Finalmente, antes de fazer a versão final, o diagrama deve ser desenhado em papel comum e retrabalhado tantas vezes quanto possível para corrigi-lo.

O diagrama a seguir é um exemplo de um sistema de pedidos de um aplicativo. Ele descreve um aspecto específico de todo o aplicativo.

Em primeiro lugar, o Pedido e o Cliente são identificados como os dois elementos do sistema. Eles têm um relacionamento de um para muitos porque um cliente pode ter vários pedidos.
A classe Order é uma classe abstrata e possui duas classes concretas (relacionamento de herança) SpecialOrder e NormalOrder.
As duas classes herdadas têm todas as propriedades da classe Order. Além disso, eles têm funções adicionais como dispatch () e receive ().

O seguinte diagrama de classes foi desenhado considerando todos os pontos mencionados acima.

Onde usar diagramas de classes?

O diagrama de classes é um diagrama estático e é usado para modelar a visão estática de um sistema. A visão estática descreve o vocabulário do sistema.

O diagrama de classes também é considerado a base para os diagramas de componentes e implantação. Os diagramas de classes não são usados apenas para visualizar a visão estática do sistema, mas também para construir o código executável para a engenharia direta e reversa de qualquer sistema.

Geralmente, os diagramas UML não são mapeados diretamente com nenhuma linguagem de programação orientada a objetos, mas o diagrama de classes é uma exceção.

O diagrama de classes mostra claramente o mapeamento com linguagens orientadas a objetos, como Java, C ++, etc. Com base na experiência prática, o diagrama de classes é geralmente usado para fins de construção.

Resumindo, pode-se dizer que os diagramas de classes são usados para -

Descrevendo a visão estática do sistema.
Mostrando a colaboração entre os elementos da visão estática.
Descrever as funcionalidades realizadas pelo sistema.
Construção de aplicações de software usando linguagens orientadas a objetos.

Os diagramas de objetos são derivados de diagramas de classes, portanto, os diagramas de objetos dependem dos diagramas de classes.

Os diagramas de objetos representam uma instância de um diagrama de classes. Os conceitos básicos são semelhantes para diagramas de classes e diagramas de objetos. Os diagramas de objetos também representam a visão estática de um sistema, mas essa visão estática é um instantâneo do sistema em um determinado momento.

Os diagramas de objetos são usados para renderizar um conjunto de objetos e seus relacionamentos como uma instância.

Objetivo dos Diagramas de Objeto

O propósito de um diagrama deve ser entendido claramente para implementá-lo na prática. Os objetivos dos diagramas de objetos são semelhantes aos diagramas de classes.

A diferença é que um diagrama de classes representa um modelo abstrato que consiste em classes e seus relacionamentos. No entanto, um diagrama de objeto representa uma instância em um determinado momento, que é de natureza concreta.

Isso significa que o diagrama de objeto está mais próximo do comportamento real do sistema. O objetivo é capturar a visão estática de um sistema em um determinado momento.

O objetivo do diagrama de objetos pode ser resumido como -

Engenharia direta e reversa.
Relações de objeto de um sistema
Visão estática de uma interação.
Compreenda o comportamento do objeto e sua relação de uma perspectiva prática

Como desenhar um diagrama de objeto?

Já discutimos que um diagrama de objetos é uma instância de um diagrama de classes. Isso implica que um diagrama de objeto consiste em instâncias de coisas usadas em um diagrama de classes.

Portanto, os dois diagramas são feitos dos mesmos elementos básicos, mas em formas diferentes. No diagrama de classe, os elementos estão em forma abstrata para representar o projeto e no diagrama de objetos os elementos estão em forma concreta para representar o objeto do mundo real.

Para capturar um sistema específico, o número de diagramas de classes é limitado. No entanto, se considerarmos os diagramas de objetos, podemos ter um número ilimitado de instâncias, que são únicas por natureza. Apenas aquelas instâncias são consideradas, que têm impacto no sistema.

A partir da discussão acima, está claro que um único diagrama de objeto não pode capturar todas as instâncias necessárias, ou melhor, não pode especificar todos os objetos de um sistema. Portanto, a solução é -

Primeiro, analise o sistema e decida quais instâncias têm dados e associações importantes.
Em segundo lugar, considere apenas as instâncias, que cobrirão a funcionalidade.
Terceiro, faça alguma otimização, pois o número de instâncias é ilimitado.

Antes de desenhar um diagrama de objeto, as seguintes coisas devem ser lembradas e entendidas claramente -

Os diagramas de objetos consistem em objetos.
O link no diagrama de objeto é usado para conectar objetos.
Objetos e links são os dois elementos usados para construir um diagrama de objetos.

Depois disso, as seguintes coisas devem ser decididas antes de iniciar a construção do diagrama -

O diagrama de objetos deve ter um nome significativo para indicar sua finalidade.
Os elementos mais importantes devem ser identificados.
A associação entre objetos deve ser esclarecida.
Os valores de diferentes elementos precisam ser capturados para serem incluídos no diagrama de objetos.
Adicione notas adequadas em pontos onde mais clareza é necessária.

O diagrama a seguir é um exemplo de um diagrama de objeto. Ele representa o sistema de gerenciamento de pedidos que discutimos no capítulo Diagrama de classes. O diagrama a seguir é uma instância do sistema em um momento específico da compra. Possui os seguintes objetos.

Customer
Order
SpecialOrder
NormalOrder

Agora, o objeto de cliente (C) está associado a três objetos de pedido (O1, O2 e O3). Esses objetos de pedido estão associados a objetos de pedidos especiais e de pedidos normais (S1, S2 e N1). O cliente tem os três pedidos a seguir com números diferentes (12, 32 e 40) para o tempo específico considerado.

O cliente pode aumentar o número de pedidos no futuro e, nesse cenário, o diagrama de objetos refletirá isso. Se objetos de ordem, ordem especial e ordem normal forem observados, você descobrirá que eles têm alguns valores.

Para pedidos, os valores são 12, 32 e 40, o que implica que os objetos têm esses valores para um determinado momento (aqui o momento específico em que a compra é feita é considerado o momento) em que a instância é capturada

O mesmo é verdadeiro para pedidos especiais e objetos de pedidos normais que têm um número de pedidos como 20, 30 e 60. Se um momento diferente de compra for considerado, esses valores serão alterados de acordo.

O seguinte diagrama de objetos foi desenhado considerando todos os pontos mencionados acima

Onde usar diagramas de objetos?

Os diagramas de objetos podem ser imaginados como o instantâneo de um sistema em execução em um determinado momento. Vamos considerar um exemplo de um trem em execução

Agora, se você tirar uma foto do trem em movimento, você encontrará uma imagem estática dele com o seguinte -

Um estado particular que está em execução.
Um determinado número de passageiros. que vai mudar se a foto for tirada em um momento diferente

Aqui, podemos imaginar que o snap do trem em execução é um objeto com os valores acima. E isso é verdade para qualquer sistema simples ou complexo da vida real.

Em suma, pode-se dizer que os diagramas de objetos são usados para -

Fazendo o protótipo de um sistema.
Engenharia reversa.
Modelagem de estruturas de dados complexas.
Compreender o sistema de uma perspectiva prática.

Os diagramas de componentes são diferentes em termos de natureza e comportamento. Os diagramas de componentes são usados para modelar os aspectos físicos de um sistema. Agora a questão é: quais são esses aspectos físicos? Os aspectos físicos são os elementos como executáveis, bibliotecas, arquivos, documentos, etc. que residem em um nó.

Os diagramas de componentes são usados para visualizar a organização e os relacionamentos entre os componentes de um sistema. Esses diagramas também são usados para fazer sistemas executáveis.

Objetivo dos Diagramas de Componentes

O diagrama de componentes é um tipo especial de diagrama em UML. O objetivo também é diferente de todos os outros diagramas discutidos até agora. Não descreve a funcionalidade do sistema, mas descreve os componentes usados para fazer essas funcionalidades.

Portanto, desse ponto de vista, os diagramas de componentes são usados para visualizar os componentes físicos de um sistema. Esses componentes são bibliotecas, pacotes, arquivos, etc.

Os diagramas de componentes também podem ser descritos como uma visão de implementação estática de um sistema. A implementação estática representa a organização dos componentes em um determinado momento.

Um único diagrama de componente não pode representar todo o sistema, mas uma coleção de diagramas é usada para representar o todo.

O objetivo do diagrama de componentes pode ser resumido como -

Visualize os componentes de um sistema.
Construa executáveis usando engenharia direta e reversa.
Descreva a organização e os relacionamentos dos componentes.

Como desenhar um diagrama de componentes?

Os diagramas de componentes são usados para descrever os artefatos físicos de um sistema. Este artefato inclui arquivos, executáveis, bibliotecas, etc.

O objetivo deste diagrama é diferente. Os diagramas de componentes são usados durante a fase de implementação de um aplicativo. No entanto, ele é preparado com bastante antecedência para visualizar os detalhes da implementação.

Inicialmente, o sistema é projetado usando diferentes diagramas UML e, em seguida, quando os artefatos estão prontos, os diagramas de componentes são usados para se ter uma ideia da implementação.

Este diagrama é muito importante, pois sem ele o aplicativo não pode ser implementado de forma eficiente. Um diagrama de componentes bem preparado também é importante para outros aspectos, como desempenho do aplicativo, manutenção, etc.

Antes de desenhar um diagrama de componentes, os seguintes artefatos devem ser identificados claramente -

Arquivos usados no sistema.
Bibliotecas e outros artefatos relevantes para o aplicativo.
Relacionamentos entre os artefatos.

Depois de identificar os artefatos, os pontos a seguir precisam ser mantidos em mente.

Use um nome significativo para identificar o componente para o qual o diagrama deve ser desenhado.
Prepare um layout mental antes de produzir as ferramentas de uso.
Use notas para esclarecer pontos importantes.

A seguir está um diagrama de componentes para o sistema de gerenciamento de pedidos. Aqui, os artefatos são arquivos. O diagrama mostra os arquivos no aplicativo e seus relacionamentos. Na verdade, o diagrama de componentes também contém dlls, bibliotecas, pastas, etc.

No diagrama a seguir, quatro arquivos são identificados e seus relacionamentos são produzidos. O diagrama de componentes não pode ser correspondido diretamente com outros diagramas UML discutidos até o momento, uma vez que foi desenhado para propósitos completamente diferentes.

O diagrama de componentes a seguir foi desenhado considerando todos os pontos mencionados acima.

Onde usar diagramas de componentes?

Já descrevemos que os diagramas de componentes são usados para visualizar a visão de implementação estática de um sistema. Os diagramas de componentes são tipos especiais de diagramas UML usados para diferentes propósitos.

Esses diagramas mostram os componentes físicos de um sistema. Para esclarecer, podemos dizer que os diagramas de componentes descrevem a organização dos componentes em um sistema.

A organização pode ser descrita posteriormente como a localização dos componentes em um sistema. Esses componentes são organizados de maneira especial para atender aos requisitos do sistema.

Como já discutimos, esses componentes são bibliotecas, arquivos, executáveis, etc. Antes de implementar o aplicativo, esses componentes devem ser organizados. Esta organização de componente também é projetada separadamente como parte da execução do projeto.

Os diagramas de componentes são muito importantes do ponto de vista da implementação. Assim, a equipe de implementação de um aplicativo deve ter um conhecimento adequado dos detalhes do componente

Os diagramas de componentes podem ser usados para -

Modele os componentes de um sistema.
Modelar o esquema do banco de dados.
Modele os executáveis de um aplicativo.
Modele o código-fonte do sistema.

Os diagramas de implantação são usados para visualizar a topologia dos componentes físicos de um sistema, onde os componentes de software são implantados.

Os diagramas de implantação são usados para descrever a visão de implantação estática de um sistema. Os diagramas de implantação consistem em nós e seus relacionamentos.

Objetivo dos diagramas de implantação

O próprio termo Implantação descreve o propósito do diagrama. Os diagramas de implantação são usados para descrever os componentes de hardware, onde os componentes de software são implantados. Os diagramas de componentes e os diagramas de implantação estão intimamente relacionados.

Os diagramas de componentes são usados para descrever os componentes e os diagramas de implantação mostram como eles são implantados no hardware.

A UML é projetada principalmente para focar nos artefatos de software de um sistema. No entanto, esses dois diagramas são diagramas especiais usados para enfocar os componentes de software e hardware.

A maioria dos diagramas UML é usada para lidar com componentes lógicos, mas os diagramas de implantação são feitos para enfocar a topologia de hardware de um sistema. Os diagramas de implantação são usados pelos engenheiros do sistema.

O objetivo dos diagramas de implantação pode ser descrito como -

Visualize a topologia de hardware de um sistema.
Descreva os componentes de hardware usados para implantar componentes de software.
Descreva os nós de processamento do tempo de execução.

Como desenhar um diagrama de implantação?

O diagrama de implantação representa a visão de implantação de um sistema. Está relacionado ao diagrama de componentes porque os componentes são implantados usando os diagramas de implantação. Um diagrama de implantação consiste em nós. Os nós nada mais são do que hardware físico usado para implantar o aplicativo.

Os diagramas de implantação são úteis para engenheiros de sistema. Um diagrama de implantação eficiente é muito importante, pois controla os seguintes parâmetros -

Performance
Scalability
Maintainability
Portability

Antes de desenhar um diagrama de implantação, os seguintes artefatos devem ser identificados -

Nodes
Relações entre nós

A seguir está um diagrama de implantação de amostra para fornecer uma ideia da visão de implantação do sistema de gerenciamento de pedidos. Aqui, mostramos nós como -

Monitor
Modem
Servidor de cache
Server

O aplicativo é considerado um aplicativo baseado na web, que é implementado em um ambiente em cluster usando o servidor 1, o servidor 2 e o servidor 3. O usuário se conecta ao aplicativo usando a Internet. O controle flui do servidor de armazenamento em cache para o ambiente em cluster.

O diagrama de implantação a seguir foi desenhado considerando todos os pontos mencionados acima.

Onde usar diagramas de implantação?

Os diagramas de implantação são usados principalmente por engenheiros de sistema. Esses diagramas são usados para descrever os componentes físicos (hardware), sua distribuição e associação.

Os diagramas de implantação podem ser visualizados como os componentes / nós de hardware nos quais residem os componentes de software.

Os aplicativos de software são desenvolvidos para modelar processos de negócios complexos. Aplicativos de software eficientes não são suficientes para atender aos requisitos de negócios. Os requisitos de negócios podem ser descritos como a necessidade de oferecer suporte ao número crescente de usuários, tempo de resposta rápido, etc.

Para atender a esses tipos de requisitos, os componentes de hardware devem ser projetados de forma eficiente e econômica.

Os aplicativos de software atuais são muito complexos por natureza. Os aplicativos de software podem ser autônomos, baseados na web, distribuídos, baseados em mainframe e muitos mais. Portanto, é muito importante projetar os componentes de hardware de forma eficiente.

Os diagramas de implantação podem ser usados -

Para modelar a topologia de hardware de um sistema.
Para modelar o sistema embarcado.
Para modelar os detalhes de hardware para um sistema cliente / servidor.
Para modelar os detalhes de hardware de um aplicativo distribuído.
Para engenharia direta e reversa.

Para modelar um sistema, o aspecto mais importante é capturar o comportamento dinâmico. Comportamento dinâmico significa o comportamento do sistema quando está rodando / operando.

Apenas o comportamento estático não é suficiente para modelar um sistema; o comportamento dinâmico é mais importante do que o comportamento estático. Em UML, existem cinco diagramas disponíveis para modelar a natureza dinâmica e o diagrama de caso de uso é um deles. Agora, como temos que discutir que o diagrama de caso de uso é dinâmico por natureza, deve haver alguns fatores internos ou externos para fazer a interação.

Esses agentes internos e externos são conhecidos como atores. Os diagramas de caso de uso consistem em atores, casos de uso e seus relacionamentos. O diagrama é usado para modelar o sistema / subsistema de um aplicativo. Um único diagrama de caso de uso captura uma funcionalidade específica de um sistema.

Portanto, para modelar todo o sistema, vários diagramas de casos de uso são usados.

Objetivo dos diagramas de caso de uso

O objetivo do diagrama de caso de uso é capturar o aspecto dinâmico de um sistema. No entanto, essa definição é muito genérica para descrever o propósito, visto que outros quatro diagramas (atividade, sequência, colaboração e gráfico de estado) também têm o mesmo propósito. Examinaremos algum propósito específico, que o distinguirá de outros quatro diagramas.

Os diagramas de caso de uso são usados para reunir os requisitos de um sistema, incluindo influências internas e externas. Esses requisitos são principalmente requisitos de design. Portanto, quando um sistema é analisado para reunir suas funcionalidades, os casos de uso são preparados e os atores são identificados.

Quando a tarefa inicial é concluída, os diagramas de caso de uso são modelados para apresentar a visão externa.

Em resumo, os objetivos dos diagramas de casos de uso podem ser considerados os seguintes -

Usado para reunir os requisitos de um sistema.
Usado para obter uma visão externa de um sistema.
Identifique os fatores externos e internos que influenciam o sistema.
Mostre a interação entre os requisitos são os atores.

Como desenhar um diagrama de caso de uso?

Os diagramas de caso de uso são considerados para análise de requisitos de alto nível de um sistema. Quando os requisitos de um sistema são analisados, as funcionalidades são capturadas nos casos de uso.

Podemos dizer que os casos de uso nada mais são do que as funcionalidades do sistema escritas de forma organizada. A segunda coisa que é relevante para os casos de uso são os atores. Os atores podem ser definidos como algo que interage com o sistema.

Os atores podem ser um usuário humano, alguns aplicativos internos ou podem ser alguns aplicativos externos. Quando planejamos desenhar um diagrama de caso de uso, devemos ter os seguintes itens identificados.

Funcionalidades a serem representadas como caso de uso
Actors
Relacionamentos entre os casos de uso e atores.

Os diagramas de caso de uso são desenhados para capturar os requisitos funcionais de um sistema. Depois de identificar os itens acima, temos que usar as seguintes diretrizes para desenhar um diagrama de caso de uso eficiente

O nome de um caso de uso é muito importante. O nome deve ser escolhido de forma a identificar as funcionalidades executadas.
Dê um nome adequado para atores.
Mostre relacionamentos e dependências claramente no diagrama.
Não tente incluir todos os tipos de relacionamentos, pois o objetivo principal do diagrama é identificar os requisitos.
Use notas sempre que necessário para esclarecer alguns pontos importantes.

A seguir está um diagrama de caso de uso de amostra que representa o sistema de gerenciamento de pedidos. Portanto, se olharmos para o diagrama, encontraremos três casos de uso(Order, SpecialOrder, and NormalOrder) e um ator que é o cliente.

Os casos de uso SpecialOrder e NormalOrder são estendidos do caso de uso Order . Conseqüentemente, eles têm relacionamento estendido. Outro ponto importante é identificar o limite do sistema, que é mostrado na imagem. O ator Cliente está fora do sistema, pois é um usuário externo do sistema.

Onde usar um diagrama de caso de uso?

Como já discutimos, existem cinco diagramas em UML para modelar a visão dinâmica de um sistema. Agora, todo e qualquer modelo tem um propósito específico para usar. Na verdade, esses objetivos específicos são ângulos diferentes de um sistema em execução.

Para entender a dinâmica de um sistema, precisamos usar diferentes tipos de diagramas. O diagrama de caso de uso é um deles e seu propósito específico é reunir os requisitos e atores do sistema.

Os diagramas de caso de uso especificam os eventos de um sistema e seus fluxos. Mas o diagrama de caso de uso nunca descreve como eles são implementados. O diagrama de caso de uso pode ser imaginado como uma caixa preta onde apenas a entrada, saída e a função da caixa preta são conhecidas.

Esses diagramas são usados em um nível muito alto de design. Este design de alto nível é refinado repetidamente para obter uma imagem completa e prática do sistema. Um caso de uso bem estruturado também descreve a pré-condição, a pós-condição e as exceções. Esses elementos extras são usados para fazer casos de teste durante a execução do teste.

Embora o caso de uso não seja um bom candidato para engenharia direta e reversa, ainda assim eles são usados de uma maneira ligeiramente diferente para fazer engenharia direta e reversa. O mesmo se aplica à engenharia reversa. O diagrama de caso de uso é usado de forma diferente para torná-lo adequado para engenharia reversa.

Na engenharia direta, os diagramas de caso de uso são usados para fazer casos de teste e, na engenharia reversa, os casos de uso são usados para preparar os detalhes dos requisitos do aplicativo existente.

Os diagramas de caso de uso podem ser usados para -

Análise de requisitos e design de alto nível.
Modele o contexto de um sistema.
Engenharia reversa.
Engenharia avançada.

A partir do termo Interação, fica claro que o diagrama é usado para descrever algum tipo de interação entre os diferentes elementos do modelo. Essa interação faz parte do comportamento dinâmico do sistema.

Este comportamento interativo é representado em UML por dois diagramas conhecidos como Sequence diagram e Collaboration diagram. O objetivo básico de ambos os diagramas é semelhante.

O diagrama de sequência enfatiza a sequência de tempo das mensagens e o diagrama de colaboração enfatiza a organização estrutural dos objetos que enviam e recebem mensagens.

Objetivo dos Diagramas de Interação

O objetivo dos diagramas de interação é visualizar o comportamento interativo do sistema. Visualizar a interação é uma tarefa difícil. Portanto, a solução é usar diferentes tipos de modelos para capturar os diferentes aspectos da interação.

Os diagramas de sequência e colaboração são usados para capturar a natureza dinâmica, mas de um ângulo diferente.

O objetivo do diagrama de interação é -

Para capturar o comportamento dinâmico de um sistema.
Para descrever o fluxo de mensagens no sistema.
Descrever a organização estrutural dos objetos.
Descrever a interação entre objetos.

Como desenhar um diagrama de interação?

Como já discutimos, o objetivo dos diagramas de interação é capturar o aspecto dinâmico de um sistema. Portanto, para capturar o aspecto dinâmico, precisamos entender o que é um aspecto dinâmico e como ele é visualizado. O aspecto dinâmico pode ser definido como o instantâneo do sistema em execução em um determinado momento

Temos dois tipos de diagramas de interação em UML. Um é o diagrama de sequência e o outro é o diagrama de colaboração. O diagrama de sequência captura a sequência de tempo do fluxo de mensagens de um objeto para outro e o diagrama de colaboração descreve a organização de objetos em um sistema que participa do fluxo de mensagens.

Os itens a seguir devem ser identificados claramente antes de desenhar o diagrama de interação

Objetos que participam da interação.
A mensagem flui entre os objetos.
A sequência em que as mensagens estão fluindo.
Organização de objetos.

A seguir estão dois diagramas de interação que modelam o sistema de gerenciamento de pedidos. O primeiro diagrama é um diagrama de sequência e o segundo é um diagrama de colaboração

O Diagrama de Seqüência

O diagrama de seqüência possui quatro objetos (Customer, Order, SpecialOrder e NormalOrder).

O diagrama a seguir mostra a seqüência de mensagens para o objeto SpecialOrder e a mesma pode ser utilizada no caso do objeto NormalOrder . É importante entender a sequência de tempo dos fluxos de mensagens. O fluxo de mensagens nada mais é do que uma chamada de método de um objeto.

A primeira chamada é sendOrder () que é um método do objeto Order . A próxima chamada é confirm () que é um método do objeto SpecialOrder e a última chamada é Dispatch () que é um método do objeto SpecialOrder . O diagrama a seguir descreve principalmente as chamadas de método de um objeto para outro, e este também é o cenário real quando o sistema está em execução.

O Diagrama de Colaboração

O segundo diagrama de interação é o diagrama de colaboração. Ele mostra a organização do objeto conforme visto no diagrama a seguir. No diagrama de colaboração, a sequência de chamada do método é indicada por alguma técnica de numeração. O número indica como os métodos são chamados um após o outro. Utilizamos o mesmo sistema de gerenciamento de pedidos para descrever o diagrama de colaboração.

As chamadas de método são semelhantes às de um diagrama de sequência. No entanto, a diferença sendo o diagrama de sequência não descreve a organização do objeto, enquanto o diagrama de colaboração mostra a organização do objeto.

Para escolher entre esses dois diagramas, a ênfase é colocada no tipo de requisito. Se a sequência de tempo for importante, o diagrama de sequência será usado. Se a organização for necessária, o diagrama de colaboração será usado.

Onde usar diagramas de interação?

Já discutimos que os diagramas de interação são usados para descrever a natureza dinâmica de um sistema. Agora, veremos os cenários práticos em que esses diagramas são usados. Para entender a aplicação prática, precisamos entender a natureza básica da sequência e do diagrama de colaboração.

O objetivo principal de ambos os diagramas são semelhantes, pois são usados para capturar o comportamento dinâmico de um sistema. No entanto, o propósito específico é mais importante para esclarecer e compreender.

Os diagramas de sequência são usados para capturar a ordem das mensagens que fluem de um objeto para outro. Os diagramas de colaboração são usados para descrever a organização estrutural dos objetos que participam da interação. Um único diagrama não é suficiente para descrever o aspecto dinâmico de um sistema inteiro, portanto, um conjunto de diagramas é usado para capturá-lo como um todo.

Os diagramas de interação são usados quando queremos entender o fluxo de mensagens e a organização estrutural. Fluxo de mensagens significa a sequência de fluxo de controle de um objeto para outro. Organização estrutural significa a organização visual dos elementos de um sistema.

Diagramas de interação podem ser usados -

Para modelar o fluxo de controle por sequência de tempo.
Modelar o fluxo de controle por organizações estruturais.
Para engenharia avançada.
Para engenharia reversa.

O nome do diagrama em si esclarece a finalidade do diagrama e outros detalhes. Ele descreve diferentes estados de um componente em um sistema. Os estados são específicos para um componente / objeto de um sistema.

Um diagrama Statechart descreve uma máquina de estado. Máquina de estado pode ser definida como uma máquina que define diferentes estados de um objeto e esses estados são controlados por eventos externos ou internos.

O diagrama de atividades explicado no próximo capítulo é um tipo especial de diagrama Statechart. Como o diagrama Statechart define os estados, ele é usado para modelar o tempo de vida de um objeto.

Objetivo dos Diagramas de Statechart

O diagrama Statechart é um dos cinco diagramas UML usados para modelar a natureza dinâmica de um sistema. Eles definem diferentes estados de um objeto durante seu tempo de vida e esses estados são alterados por eventos. Os diagramas de statechart são úteis para modelar os sistemas reativos. Os sistemas reativos podem ser definidos como um sistema que responde a eventos externos ou internos.

O diagrama Statechart descreve o fluxo de controle de um estado para outro. Os estados são definidos como uma condição na qual um objeto existe e muda quando algum evento é acionado. O propósito mais importante do diagrama Statechart é modelar o tempo de vida de um objeto desde a criação até o término.

Os diagramas Statechart também são usados para a engenharia direta e reversa de um sistema. No entanto, o objetivo principal é modelar o sistema reativo.

A seguir estão os principais objetivos do uso de diagramas Statechart -

Para modelar o aspecto dinâmico de um sistema.
Para modelar o tempo de vida de um sistema reativo.
Descrever os diferentes estados de um objeto durante sua vida útil.
Defina uma máquina de estado para modelar os estados de um objeto.

Como desenhar um diagrama de estatísticas?

O diagrama Statechart é usado para descrever os estados de diferentes objetos em seu ciclo de vida. A ênfase é colocada nas mudanças de estado em alguns eventos internos ou externos. Esses estados de objetos são importantes para analisá-los e implementá-los com precisão.

Os diagramas de statechart são muito importantes para descrever os estados. Os estados podem ser identificados como a condição dos objetos quando um determinado evento ocorre.

Antes de desenhar um diagrama Statechart, devemos esclarecer os seguintes pontos -

Identifique os objetos importantes a serem analisados.
Identifique os estados.
Identifique os eventos.

A seguir está um exemplo de um diagrama Statechart onde o estado do objeto Order é analisado

O primeiro estado é um estado ocioso de onde o processo começa. Os próximos estados são chegados para eventos como enviar solicitação, confirmar solicitação e despachar pedido. Esses eventos são responsáveis pelas mudanças de estado do objeto de pedido.

Durante o ciclo de vida de um objeto (aqui objeto de pedido), ele passa pelos seguintes estados e pode haver algumas saídas anormais. Esta saída anormal pode ocorrer devido a algum problema no sistema. Quando todo o ciclo de vida é concluído, ele é considerado uma transação completa, conforme mostrado na figura a seguir. O estado inicial e final de um objeto também é mostrado na figura a seguir.

Onde usar diagramas de statechart?

A partir da discussão acima, podemos definir as aplicações práticas de um diagrama Statechart. Os diagramas de statechart são usados para modelar o aspecto dinâmico de um sistema como outros quatro diagramas discutidos neste tutorial. No entanto, possui algumas características distintivas para modelar a natureza dinâmica.

O diagrama Statechart define os estados de um componente e essas mudanças de estado são dinâmicas por natureza. Seu objetivo específico é definir as mudanças de estado desencadeadas por eventos. Os eventos são fatores internos ou externos que influenciam o sistema.

Os diagramas de statechart são usados para modelar os estados e também os eventos que operam no sistema. Ao implementar um sistema, é muito importante esclarecer os diferentes estados de um objeto durante sua vida útil e diagramas de Statechart são usados para esse propósito. Quando esses estados e eventos são identificados, eles são usados para modelá-los e esses modelos são usados durante a implementação do sistema.

Se olharmos para a implementação prática do diagrama Statechart, ele será usado principalmente para analisar os estados do objeto influenciados por eventos. Esta análise é útil para entender o comportamento do sistema durante sua execução.

O uso principal pode ser descrito como -

Para modelar os estados de objeto de um sistema.
Para modelar o sistema reativo. O sistema reativo consiste em objetos reativos.
Identificar os eventos responsáveis pelas mudanças de estado.
Engenharia direta e reversa.

O diagrama de atividades é outro diagrama importante em UML para descrever os aspectos dinâmicos do sistema.

O diagrama de atividades é basicamente um fluxograma para representar o fluxo de uma atividade para outra. A atividade pode ser descrita como uma operação do sistema.

O fluxo de controle é puxado de uma operação para outra. Esse fluxo pode ser sequencial, ramificado ou simultâneo. Os diagramas de atividades lidam com todos os tipos de controle de fluxo usando diferentes elementos, como bifurcação, junção, etc.

Objetivo dos Diagramas de Atividades

Os objetivos básicos dos diagramas de atividades são semelhantes aos outros quatro diagramas. Ele captura o comportamento dinâmico do sistema. Outros quatro diagramas são usados para mostrar o fluxo de mensagens de um objeto para outro, mas o diagrama de atividades é usado para mostrar o fluxo de mensagens de uma atividade para outra.

A atividade é uma operação particular do sistema. Os diagramas de atividades não são usados apenas para visualizar a natureza dinâmica de um sistema, mas também para construir o sistema executável usando técnicas de engenharia reversa e direta. A única coisa que falta no diagrama de atividades é a parte da mensagem.

Ele não mostra nenhum fluxo de mensagens de uma atividade para outra. O diagrama de atividades às vezes é considerado um fluxograma. Embora os diagramas pareçam um fluxograma, eles não são. Mostra diferentes fluxos, como paralelo, ramificado, simultâneo e único.

O objetivo de um diagrama de atividades pode ser descrito como -

Desenhe o fluxo de atividades de um sistema.
Descreva a sequência de uma atividade para outra.
Descreva o fluxo paralelo, ramificado e simultâneo do sistema.

Como desenhar um diagrama de atividades?

Os diagramas de atividades são usados principalmente como um fluxograma que consiste nas atividades executadas pelo sistema. Os diagramas de atividades não são exatamente fluxogramas, pois têm alguns recursos adicionais. Esses recursos adicionais incluem ramificação, fluxo paralelo, raia, etc.

Antes de desenhar um diagrama de atividades, devemos ter um entendimento claro sobre os elementos usados no diagrama de atividades. O principal elemento de um diagrama de atividades é a própria atividade. Uma atividade é uma função desempenhada pelo sistema. Depois de identificar as atividades, precisamos entender como elas estão associadas a restrições e condições.

Antes de desenhar um diagrama de atividades, devemos identificar os seguintes elementos -

Activities
Association
Conditions
Constraints

Uma vez que os parâmetros mencionados acima são identificados, precisamos fazer um layout mental de todo o fluxo. Esse layout mental é então transformado em um diagrama de atividades.

A seguir está um exemplo de um diagrama de atividades para o sistema de gerenciamento de pedidos. No diagrama, são identificadas quatro atividades associadas a condições. Um ponto importante deve ser claramente entendido que um diagrama de atividades não pode corresponder exatamente ao código. O diagrama de atividades é feito para entender o fluxo de atividades e é usado principalmente pelos usuários de negócios

O diagrama a seguir é desenhado com as quatro atividades principais -

Enviar pedido pelo cliente
Recebimento do pedido
Confirme a ordem
Despachar o pedido

Após receber a solicitação de pedido, são realizadas verificações de condições para verificar se é um pedido normal ou especial. Após a identificação do tipo de pedido, é realizada a atividade de despacho que é marcada como o encerramento do processo.

Onde usar diagramas de atividades?

O uso básico do diagrama de atividades é semelhante a outros quatro diagramas UML. O uso específico é modelar o fluxo de controle de uma atividade para outra. Este fluxo de controle não inclui mensagens.

O diagrama de atividades é adequado para modelar o fluxo de atividades do sistema. Um aplicativo pode ter vários sistemas. O diagrama de atividades também captura esses sistemas e descreve o fluxo de um sistema para outro. Este uso específico não está disponível em outros diagramas. Esses sistemas podem ser banco de dados, filas externas ou qualquer outro sistema.

Veremos agora as aplicações práticas do diagrama de atividades. A partir da discussão acima, fica claro que um diagrama de atividades é desenhado a partir de um nível muito alto. Portanto, oferece uma visão de alto nível de um sistema. Essa visão de alto nível é principalmente para usuários de negócios ou qualquer outra pessoa que não seja uma pessoa técnica.

Este diagrama é usado para modelar as atividades que nada mais são do que requisitos de negócios. O diagrama tem mais impacto no entendimento do negócio do que nos detalhes de implementação.

O diagrama de atividades pode ser usado para -

Modelagem de fluxo de trabalho usando atividades.
Modelagem de requisitos de negócios.
Conhecimento de alto nível das funcionalidades do sistema.
Investigar os requisitos de negócios em um estágio posterior.