# UML

Esta Wiki tem como objetivo apresentar conceitos da **UML** (***Unified Modeling Language***). Boa parte do conteúdo aqui descrito tem uma linguagem não tão formal e é focado em disseminar conhecimento para os colegas de classe da forma mais simples e objetiva que consigamos.

**Importante**

A wiki está sendo atualizada e não está em sua versão final, qualquer dúvida entrar em contato com os integrantes do grupo.


---

## Tópicos abordados

> [TOC]

# História

Provavelmente todas as **Wikis** aqui contém uma contextualização sobre a história da UML, então tentamos diferenciar um pouco usando uma linguagem mais descontraída e apresentando uma pequena história para entedermos melhor o que levou a criação desssa notação que padroniza o projeto de um *software* :ok_woman:

## Pequena contextualização

### Primórdios
A programação já é algo que data de bastante tempo, começou lá por volta de 1930, com os primeiros computadores elétricos [1], desde então diversas linguagens e metodologias de desenvolvimento foram introduzidas e adotadas no mercado. Dito isso, os anos foram passando e a Engenharia de Software (começou em 1968) foi evoluindo, uma parte importante disso foi a evolução da modelagem de sistemas, no começo não existia padrão para modelar um sistema, ou se existia era utilizado por poucos e não era amplamente divulgado. Por isso, um pessoal tentou introduzir padrões de modelagem, e pelas pesquisas que eu fiz, descobri alguns padrões de modelagem que foram famosos (fora a UML), sendo esses:

1. **Análise estruturada**, criada por Gane & Searson;
2. **Análise Essencial**, criada por Palmer & McMenamin e Ed. Yourdon;

Para falar a verdade, nós do grupo não temos nenhuam experiência ou conhecimento nas metodologias citadas acima, mas é interessante de se colocar, pois com isso notamos que houve uma evolução nas metodologias de modelagem até que se chegasse na **UML**, padrão que utilizamos a muitos anos e é o objeto de pesquisa desta **WIKI**.

### Programação moderna

Agora voltando um pouco no tempo, em 1958 foi introduzido pela primeira vez o termo ***software*** [2], e como anteriormente dito houve uma evolução constante desde então, em dado momento surgiu a grande e famigerada **Orientação a Objetos**, um paradigma de programação que de certa forma tenta abstrair conceitos do mundo reais dentro do seu código, e ela de certa forma virou um padrão e é amplamente utilizada até os dias de hoje. E com programas cada vez mais sofisticados foi cada vez mais difícil projetar e organizar a engenharia por trás de um projeto de *software*, nessa linha é que encontramos a *UML*, uma linguagem que padroniza o projeto de um *software*, de sua concepção conceitual até seu modelo de implementação.

## Surgimento da UML

Na seção anterior foram apontados dois padrões de modelagem que vieram antes da **UML**, o que aconteceu para o surgimento da mesma foi que 3 caras muito famosos na Engenharia de Sofware, sendo esses Grady Booch, James Rumbaugh, e Ivar Jacobson, estavam cansados da forma como a modelagem de software seguia padrões não muito definidos e dificultava a comunidade na adoção dos mesmos, então eles que são conhecidos pelo codinome **3 amigos** pegaram todo conhecimento e artefatos que eles tinham produzido no âmbito da modelagem de software e juntaram tudo em uma mesma metologia: a **UML - Unified Modeling Language**. Na teoria a UML era bem simples, eles queriam definir uma estrutura lógica e correta que padronizaria a modelagem de software orientado a objetos, botando um prego nessa questão que vinha causando problemas já a algum tempo.

## Finalizando o tópico

Bom, agora que já sabemos como surgiu a **UML**, antes de partir para a definição e prática apenas vamos ressaltar alguns objetivos da mesma (na nossa visão):

* Criar um padrão para análise e modelagem de qualquer sistema orientado a objetos
* Tornar a modelagem próxima tanto para humanos quanto para máquina (implementação não distoa do modelo)

# Uso comum

Já citamos acima que a UML pode ser usada em uma variedade de sistemas, basicamente você pode modelar qualquer sistema orientado a objetos com a mesma, porém apenas para exemplicar um pouco melhor, segue uma lista de sistemas comuns a UML, essa lista é uma reprodução encontrada na apostila UML da Etec Lauro Gomes [4, página 7]

* Sistemas de Informação: Armazenar, pesquisar, editar e mostrar informações para os
usuários. Manter grandes quantidades de dados com relacionamentos complexos, que
são guardados em bancos de dados relacionais ou orientados a objetos.

* Sistemas Técnicos: Manter e controlar equipamentos técnicos como de
telecomunicações, equipamentos militares ou processos industriais. Eles devem
possuir interfaces especiais do equipamento e menos programação de software de que
os sistemas de informação. Sistemas Técnicos são geralmente sistemas real-time.

* Sistemas Real-time Integrados: Executados em simples peças de hardware integrados
a telefones celulares, carros, alarmes etc. Estes sistemas implementam programação
de baixo nível e requerem suporte real-time.

* Sistemas Distribuídos: Distribuídos em máquinas onde os dados são transferidos
facilmente de uma máquina para outra. Eles requerem mecanismos de comunicação
sincronizados para garantir a integridade dos dados e geralmente são construídos em
mecanismos de objetos como CORBA, COM/DCOM ou Java Beans/RMI.

* Sistemas de Software: Definem uma infra-estrutura técnica que outros softwares
utilizam. Sistemas Operacionais, bancos de dados, e ações de usuários que executam
ações de baixo nível no hardware, ao mesmo tempo que disponibilizam interfaces
genéricas de uso de outros softwares.

* Sistemas de Negócios: descreve os objetivos, especificações (pessoas, computadores
etc.), as regras (leis, estratégias de negócios etc.), e o atual trabalho desempenhado
nos processos do negócio.

---

# Fases do desenvolvimento de um sistema em UML
A UML (Unified Modeling Language) é uma linguagem padrão para modelagem orientada a objetos. No entanto, essa linguagem de modelagem não é um método de desenvolvimento.

A UML tem como objetivo auxiliar a visualização do software como um todo e a comunicação de objetos em diagramas padroniados.

Para que um sistema de software seja desenvolvido, é necessário passar por cinco fases até o resultado final. Vejamos:


A execução das fases segue uma ordem definida e obrigatória, pois não há como realizar testes se as fases de Design e Implementação não foram finalizadas. Da mesma forma, não há como executar a etapa de Design e Implementação se as fases de Análise de Requisitos e Análise do Sistemas não foram concebidas.

## Análise e coleta de requisitos
Fase responsável pelo levantamento das intenções e necessidades dos usuários para o sistema que pretendemos criar.

É feita por meio de uma entrevista que usa as funções denominadas use cases (casos de uso). A partir disso, podemos identificar, definir e relacionar os atores externos do sistema. Dessa forma, é possível promovermos a interação entre os atores externos e modelarmos as funções necessárias, de acordo com os *use cases*.

Os atores externos e os *use cases* podem ser modelados com os relacionamentos que possuem comunicação associativa entre eles ou, ainda, podem ser separados em níveis de hierarquia. Cada *use case* modelado é descrito por meio de um texto, detalhando os requerimentos do ator externo que usará o sistema. Dessa forma, a partir do diagrama de use cases, é possível exibirmos o que os atores externos deverão esperar da aplicação. Nessa etapa, conhecemos apenas a funcionalidade do sistema, e não é necessário nos importarmos com a forma como ela será executada.

## Análise do sistema (Concepção das classes e objetos)
Fase que tem como foco nas definições das classes, dos objetos e dos mecanismos envolvidos para a solução da situação.

As classes são modeladas, são conectadas e relacionam-se com outras classes. Além disso, são referenciadas no **diagrama de classe** para desenvolver os *use cases* modelados anteriormente, elaborados por modelos dinâmicos de UML.

Na análise do sistema, apenas as classes que compõem o domínio principal da situação do software serão modeladas. Desse modo, as classes que tratam do acesso ao banco de dados, da interface, da comunicação, dos conflitos não farão parte do diagrama. Já sabemos, por meio da **Programação Orientada a Objetos (POO)**, que as classes podem ser abstratas, públicas ou privadas. As classes abstratas fazem parte dos processos de negócio e funcionalidades do sistema.

Já as classes públicas e privadas fazem parte da codificação da programação em qualquer linguagem. Nesse contexto, o grande conceito da POO é realizar a interação entre as classes abstratas e as classes de implementação.
## Design (Concepção visual do projeto)
Fase em que o produto da fase de análise do sistema é tecnicamente ampliado, de modo a ser solucionado.

Novas classes são acrescentadas para fornecer uma infraestrutura técnica, como a coordenação ao banco de dados, a interface do usuário e de periféricos, a conexão e o relacionamento com outros sistemas etc.

Na fase de análise (etapa anterior), a infraestrutura técnica das classes modeladas do domínio do problema passa a ser incorporada. Desse modo, é possível modificar tanto a própria infraestrutura quanto a função modelada. A fase do design projeta a fase seguinte, ou seja, a **programação do sistema** por meio do resultado do detalhamento das especificações.
## Implementação
Etapa em que as classes originárias do design são codificadas para uma linguagem orientada a objetos. Nesse caso, devemo-nos lembrar de não usar linguagens procedurais.

Tal conversão poderá ser um procedimento simples ou complexo. Isso vai variar de acordo com os recursos da linguagem empregada na programação, no instante em que a elaboração dos modelos de análise e design em UML forem codificados.

A etapa de programação é uma fase isolada e totalmente diferente. Nessa fase, os modelos desenvolvidos anteriormente(análise de requisitos, análise de sistema e design)serão codificados, não mais representando o perfil original do sistema.
## Testes
Fase de validação do sistema. Para isso, é comum executar testes seguindo três processos:

**a) Teste unitário:** de modo geral, o teste unitário é executado pelo desenvolvedor ou programador do sistema. O teste é aplicado tanto nas classes individuais quanto nos grupos de classes. Desse modo, podemos observar se as classes, os métodos e os atributos estão em conformidade com a documentação e a execução para os quais foram projetados.

**b) Teste de integração:** o teste de integração utiliza as classes e os componentes integrados. Dessa forma, o teste verifica se as classes estão cooperando umas com as outras, de acordo com a especificação presente nos modelos do projeto. Por exemplo, o teste verifica se um sistema está se comunicando com o outro conforme o esperado e se os resultados da execução são aqueles previstos.

**c) Teste para homologação**: o teste para homologação avalia a funcionalidade do sistema segundo o que foi especificado nos primeiros diagramas. Em outras palavras, o teste analisa se as soluções apresentadas atendem as necessidades levantadas no início do projeto.

---

# Principais diagramas

## Diagrama de casos de uso
Dentro da UML o diagrama de Casos de Uso ajuda no levantamento dos requisitos funcionais de um sistema, descrevendo um conjunto de funcionalidade e interações com elementos externos e internos do sistema.

### Elementos do diagrama de caso de uso
Os diagramas de Casos de Uso são compostos basicamente por 4 elementos:

Cenários: Um cenário pode ser compreendido como uma sequência de passos que decreve uma interação entre o usuário e o sistema.

Atores: Os usuários que interagem com o sistema. Pode ser uma pessoa, organização ou sistema externo.

Caso de Uso: Uma tarefa ou funcionalidade realizada pelo ator (usuário).

Relacionamento: auxiliam na descrição dos casos de uso, podendo ser: entre um ator e um caso de uso, entre atores e entre casos de uso.

### Símbolos e notação no diagrama de caso de uso

Atores: Stickman que representa um humano ou sistema computacional.

Figura 3 - Representação de um cliente
[Fonte: Medium](https://medium.com/operacionalti/uml-diagrama-de-casos-de-uso-29f4358ce4d5)

Caso de Uso: É representado por um elipse que representa uma funcionalidade do sistema. Existem duas possibilidades, um caso de uso pode ser concretro ou abstrato. Quando concreto, o caso de uso é iniciado diretamente por um ator. Quando abstrato, o caso de uso é uma extensão de um outro caso de uso. Além disso há casos de uso primários e secundários. O primeiro representa os objetivos dos atores, já o segundo são funcionalidades do sistema que precisam existir para que este funcione corretamente.

Figura 4 - Representação de um caso de uso
[Fonte: Macoratti.net](http://www.macoratti.net/11/10/uml_rev1.htm)

Relacionamentos: Os relacionamentos no diagramas podem variar entre os seguintes.

Relacionamento de Comunicação ou Associação: representa a interação entre um ator e um caso de uso. Essa interação é representada por uma linha sólida.

Figura 5 - Representação relacionamento
[Fonte: Medium](https://medium.com/operacionalti/uml-diagrama-de-casos-de-uso-29f4358ce4d5)

Relacionamento de Inclusão: é usado quando um comportamento se repete em mais de um caso de uso. Um exemplo como é um aplicativo de banco, onde um cliente que vai realizar um pagamento precisa se assim como um cliente que quer visualizar o seu saldo também precisa realizar o login.

Figura 6 - Representação include
[Fonte: Medium](https://medium.com/operacionalti/uml-diagrama-de-casos-de-uso-29f4358ce4d5)

Fazer o login é essencial tanto para pagar a fatura, quanto para visualizar o saldo.

Figura 7 - Representação extend
[Fonte: Medium](https://medium.com/operacionalti/uml-diagrama-de-casos-de-uso-29f4358ce4d5)

Relacionamento de Extensão: Esse tipo de relacionamento é utilizado quando queremos representar um fluxo alternativo. Um exemplo comum é o cadastro de um, onde podemos "cadastrar um administrador" ou "cadastrar um moderador".

Tanto "cadastrar administrador" quanto "cadastrar moderador" são extensões de "cadastrar usuário". Eles não são essenciais, só contém eventos adicionais sob certas condições.

Relacionamento de Herança: Esse é um relacionamento entre atores, usado quando queremos representar uma especialização/generalização.

Figura 8 - Representação herança
[Fonte: Medium](https://medium.com/operacionalti/uml-diagrama-de-casos-de-uso-29f4358ce4d5)

Os casos de uso de pessoa são também casos de uso de vendedor. Vendedor tem seus próprios casos de uso.

Em resumo:
Figura 9 - Resumo casos de uso
[Fonte: Medium](https://medium.com/operacionalti/uml-diagrama-de-casos-de-uso-29f4358ce4d5)

### Mais exemplos do diagrama de casos de uso

Figura 10 - Exemplo caso de uso
[Fonte: Lucidchart](https://www.lucidchart.com/pages/pt/diagrama-de-caso-de-uso-uml)

Figura 11 - Exemplo caso de uso
[Fonte: Lucidchart](https://www.lucidchart.com/pages/pt/diagrama-de-caso-de-uso-uml)
## Diagrama de classes

Dentro da UML, um dos tipos de diagramas mais populares é o diagrama de classes. Os diagramas de classes são um tipo de diagrama da estrutura do sistem, pois nele é descrito o que deve estar presente no sistema a ser construído.

Também podemos definir o diagrama de classes como uma representação não só das estruturas do sistemas, mas também como a as relações entre as classes do sistema. É uma modelagem muito útil para o desenvolvimento de sistemas, pois define todas as classes que o sistema precisa para que construído, servindo também como base para os diagramas de comunicação, sequência e estados.

### Conceitos

***Classes:*** Um rascunho para a criação de objeto e implementação do sistema. É constituída por um retângulo divido em 3 blocos. O primeiro bloco contém o nome da classe, o segundo seus atributos e o último contém suas operações.

Figura 12 - Representação de uma classe
[Fonte: Medium](https://medium.com/gdgcampinas/conceitos-básicos-de-orientação-a-objetos-b58809b2d809)

Detalhando os dois últimos blocos da classe:

**Atributos:** Cada atributo da classe é exibido em uma linha separada. Dentro do conceito de atributos também há o conceito de visibilidade, podemos entende-lo ele da seguinte forma.

**Pública:** representada pelo símbolo "+", onde outras classes podem ter acesso ao atributo;

**Privada:** representada pelo símbolo: "-", o atributo somente é acessado diretamente pela própria classe;

**Protegida:** representada pelo símbolo: "#".

**Operações:** Também conhecidos como métodos, métodos são exibidos em formato de lista, com cada operação representada em sua própria linha.

**Multiplicidade:** Consideramos a multiplicidade os limites inferior e superiorda quantidade de objetos que outro objeto está associado.

Figura 13 - Multiplicidade um para um
[Fonte: Space Programmer](http://spaceprogrammer.com/uml/compreendendo-multiplicidade-e-os-tipos-de-associacao/)

Uma pessoa pode possuir 0 ou no máximo 1 CPF, e um CPF pode ser tido por somente 1 pessoa. Chamamos esse relacionamento de um para um.

Figura 14 - Multiplicidade um para muitos
[Fonte: Space Programmer](http://spaceprogrammer.com/uml/compreendendo-multiplicidade-e-os-tipos-de-associacao/)

Nesse exemplo um cliente pode possuir zero ou muitas contas e a conta pode ser pertencer a uma única pessoa, fazendo com que o relacionamento seja de um para muitos.

Figura 15 - Multiplicidade muitos para muitos
[Fonte: Space Programmer](http://spaceprogrammer.com/uml/compreendendo-multiplicidade-e-os-tipos-de-associacao/)

Essa é a relação de muitos para muitos, temos que um profissional pode trabalhar em zero ou muitos projetos, e um projeto pode ter zero ou muitos profissionais.

De forma mais concisa temos:

Figura 16 - Resumo multiplicidade
[Fonte: PowerPoint Presentation](https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/uml-diagrama-classes-relacionamentos_v01.pdf)

## Interações ##

Consiste nas diversas ligações e relações que podem existir entre as classes e objetos. As interações mais comuns são:

**Hereditariedade:** Esse processo também é chamado generalização.
Figura 17 - Hereditariedade entre classes
[Fonte: Lucidchart](https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-classe-uml)

A simbologia é representada por um linha reta conectada a um triângilo, indicando assim a superclasse.

No exemplo acima, o objeto "Car" herda todos os atributos e operações da classe primária "Vehicle".

**Associação unidirecional:** Essa relação não é tão comum. Uma classe tem conhecimento de outra e tem interação com ela. Essa interação é representada por uma linha reta com uma seta aberta da classe que conhece para a classe conhecida, como indicado na imagem abaixo:

Figura 18 - Associação unidirecional entre classes
[Fonte: Lucidchart](https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-classe-uml)

**Associação bidirecional:** Nesse caso, as classes estão cientes uma da outra e de sua relação entre si. A representação dessa interação é uma linha reta entre as duas classes.

Figura 19 - Associação bidirecional entre classes
[Fonte: Lucidchart](https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-classe-uml)

Na imagem acima temos que, a classe "Car" e a classe "RoadTrip" estão inter-relacionadas.

**Agregação:** É um tipo especial de associação. Representa que as informações de um objeto precisam ser complementadas por um objeto de outra.

Figura 20 - Representação de agregação entre classes
[Fonte: PowerPoint Presentation](https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/uml-diagrama-classes-relacionamentos_v01.pdf)

**Composição:** Esta é uma variação do tipo agregação, representa um vínculo mais forte. De forma mais clara, os objetos-parte DEVEM pertencer ao objeto-todo.

Figura 21 - Representação de composição entre classes
[Fonte: PowerPoint Presentation](https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/uml-diagrama-classes-relacionamentos_v01.pdf)

**Classes Associativas:** Suponhamos que uma empresa queira contratar um funcionário. Existiriam duas classes, a classe "Empresa" e a classe "funcionário". Entre essas duas classes existiria um relacionamento chamado "Contratação". Não seria intuitivo armazenar algumas informações nas classes Empresa e Funcionário, por isso devemos criar uma classe associativa, sua função é armazenar informações sobre do relacionamento entre duas classes.

Figura 22 - Representação de uma classe associativa
[Fonte: Space Programmer](http://spaceprogrammer.com/uml/compreendendo-multiplicidade-e-os-tipos-de-associacao/)

As classes associativas no diagrama da UML são representadas igualmente as classes comuns, assim, podem se relacionar livremente com outras classes. O que as diferenciam é somente uma linha, que é tracejada, ligada ao relacionamento que a mesma representa.

Exemplos de Diagramas de Classe:

Figura 23 - Exemplo de um diagrama de classes
Fonte: Retirada de um slideshow sobre Diagrama de Classes da Universidade Federal de Minas Gerais. [7]

Figura 24 - Exemplo de um diagrama de classes
[Fonte: Generalization collection](https://generalizationcollection.blogspot.com/2019/07/the-best-quality-illustration-showing_75.html)

## Diagrama de objetos

O diagrama de objetos representa uma instância específica de um diagrama de classes em um determinado momento.

Este diagrama afeta os atributos de um conjunto de objetos, e como é o relacionamento entre eles.

Figura 24 - Diferença entre um diagrama de objetos e de classes
[Fonte: Medium](https://micreiros.com/diagrama-de-objetos/)

O diagrama de objetos possue suas semelhanças com o diagrama de classes. No exemplo, fica claro que o diagrama de objetos representa uma intência de um diagrama de classes.

Como podemos observar no exemplo acima, o diagrama de objetos mostra uma fotografia de um sistema OO em execução, mostrando os objetos, com os valores de seus atributos.

Outros exemplos do uso do diagrama de objetos são:

Figura 25 - Exemplo de um diagrama de objetos
Fonte: Retirada de um slideshow sobre diagrama de objetos da Universidade Federal do Maranhão [8]

## Diagrama de estado

O diagrama de estados tem o objetivo de modelar os estados que um objeto pode ter durante o seu ciclo de vida. Ou seja, durante o ciclo de vida de um objeto da classe **Pagamento** por exemplo, ele vai poder ter diversos estados, como:

* Inicial
* Pendente
* Pago
* Cancelado

Os objetos transitam entre os estados atráves de eventos, tais eventos são descrito no modelo atráves de setas que relacionam os estados, veja abaixo um exemplo de um diagrama de estados de um sistema de pagamentos


[Figura x - Diagrama de estados. Fonte: Pinterest](https://br.pinterest.com/pin/608408230881337702/)

Para entedermos a notação, observe o ponto preto, ele determina o estado inicial do sistema, as setas determinam as transições, cada figura amarela determina um estado e o ponto preto com um circulo exterior determina o estado final do sistema. É importante notar que as linhas e setas de transição contém um texto adjascente que determina o evento que vai emitir aquele novo estado.

### Diagrama com estados condicionais

Alguns objetos podem ter a possibilidade de emitir diversos estados baseado em um único evento, isto é, o evento carrega informações que serão tratadas pelo objeto e a depender do que o evento carrega um estado diferente vai ser emitido, isso tem que ser tratado no diagrama.

A notação de condicional no evento é tratada de algumas maneiras diferentes, ela pode ser um retângulo pintado de preto ou pode ser um losango que representa um **IF** em um fluxograma, veja abaixo um exemplo de diagrama de estados com fluxos condicionais


Figura x - Diagrama de estados com condicionais. Fonte: Retirada de apostila sobre UML da Universidade Federal de Uberlândia [5]

### Consistência do diagrama de estados

Ao modelar um diagrama de estados é importante salientar que ele deve ser consistente, isto é, os estados devem ter caminhos definidos até o estado final, o objeto não poderá ficar preso em algum estado intermediário e todos os estados do objeto devem estar mapeados. Temos algumas perguntas que podemos fazer para verficar a consistência do diagrama:

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 possíveis estados que o objeto pode assumir foram
definidos?
4. Cada estado reage adequadamente a todos os possíveis
eventos?

### Reflexões sobre o diagrama de estados

Quando eu comecei a estudar sobre diagrama de estados em análise 1, eu não fazia idéia da proposta real dele, porém hoje eu entendo o quão importante ele é, então decidi fazer essa seção para mostrar como ele pode ser útil nos sistemas de hoje.

Quem trabalha como desenvolvedor front-end já deve ter se deparado com frameworks SPA como React, Vue, Svelte, Ember, Angular e etc. Todos esses frameworks usam programação declarativa e componentização para criarem a DOM, e no final das contas todos os desenvolvedores escolhem alguma library que implementa algum Design Pattern para gerenciar os estados dos componentes, os mais famosos são o Observable, Flux e BloC. Agora, o que eles tem a ver com o diagrama de estados? Bom, os frameworks em ambos os patterns utilizam os eventos gerados pelos componentes para alterar o estado da aplicação, então se você usa o BloC do Flutter por exemplo, já deve ter tido que pensar nos estados possíveis para um Widget, além de ter de pensar quais as mudanças de estado o Widget ia ter baseado nos eventos recebidos. Por outro lado, se você é programador React já deve ter tido que pensar nas suas actions e em seus reducers para alterar o estado de seus componentes, e até deve ter feito diagramas dependendo da complexidade do componente, saiba que você estava fazendo um diagrama de estados, talvez não no padrão da UML, mas estava 😀.

Outro ponto interessante é que isso não se limita ao front-end, se você é um desenvolvedor que trabalha como SRE ou é mais ligado ao Devops, já deve ter dado um `kubectl get pods --all-namespaces` no terminal para verificar o **estado das pods** de um cluster kubernetes, acho que vou até parar de pensar em possíveis usos de um diagrama de estados pois deu pra ver que da pra usar em muuitos lugares.

## Diagrama de sequência

É um diagrama de interação que, dado um caso de uso do sistema, o diagrama de sequência mostrará a dinâmica de interação (troca de mensagens) entre os objetos de classes de um dado ponto do sistema que compõem a funcionalidade em um dado momento do tempo. Os objetos são descritos por caixas, por sua vez eles tem linhas verticais que saem abaixo dele que representam o tempo, ou seja, o tempo poderá ser visualizado de cima para baixo. Na horizontal serão representadas as interações entre os objetos, sendo essas interações descritas por linhas.


Diagrama de sequência e seus componentes. Fonte: [StarUML Docs](https://docs.staruml.io/working-with-uml-diagrams/sequence-diagram)

### Atores

São os mesmos do diagrama de casos de uso, geralmente eles representam a entidade que começa a interação no diagrama de sequência, assim como nos objetos a linha vertical representa a sua linha do tempo.

Atores em um diagrama de sequência. Fonte: [Givanaldo Rocha de Souza](https://docente.ifrn.edu.br/givanaldorocha/disciplinas/engenharia-de-software-licenciatura-em-informatica/diagrama-de-sequencia)

### Objetos

Os objetos representam instâncias de classes envolvidas na interação em questão, os mesmos podem ser criados ao decorrer do tempo ou começarem já criados e possuem uma linha do tempo, representada por uma linha tracejada, assim como os atores.

Objetos em um diagrama de sequência. Fonte: [Givanaldo Rocha de Souza](https://docente.ifrn.edu.br/givanaldorocha/disciplinas/engenharia-de-software-licenciatura-em-informatica/diagrama-de-sequencia)

### Linha de vida

A linha de vida, citada alguma vezes acima, é representada pela linha vertical tracejada e tem como objetivo demonstrar o tempo que o objeto existe dentro de um processo. Quando o objeto for excluído (não existir mais) na interação, um X na linha representará o seu fim.

### Foco de ativação

Quando um usuário estiver participando efetivamente do processo (enviando, recebendo ou aguardando mensagem) a linha de vida dele será representada de forma diferente, com um retângulo ou com uma linha mais grossa.


Focos de ativação. Fonte: [Givanaldo Rocha de Souza](https://docente.ifrn.edu.br/givanaldorocha/disciplinas/engenharia-de-software-licenciatura-em-informatica/diagrama-de-sequencia)

### Mensagens

As linhas horizontais que são trocadas entre as linhas de vida representam as mensagens trocadas entre os objetos em um dado momento de tempo, as mensagens são eventos como a chamada de um método presente no outro objeto e etc. A mensagem de ida costuma ser representada por uma linha cheia e a mensagem de retorno costuma ser representada por uma fina linha tracejada.

Mensagens. Fonte: [Givanaldo Rocha de Souza](https://docente.ifrn.edu.br/givanaldorocha/disciplinas/engenharia-de-software-licenciatura-em-informatica/diagrama-de-sequencia)

### Auto-chamada

O objeto pode chamar métodos contidos na própria classe dele, quando isso acontece existe uma notação específica para essa chamada dentro do diagrama, veja abaixo um exemplo:

Auto-chamada no diagrama de sequência. Fonte: [Givanaldo Rocha de Souza](https://docente.ifrn.edu.br/givanaldorocha/disciplinas/engenharia-de-software-licenciatura-em-informatica/diagrama-de-sequencia)

### Esteriótipos ECB

Na UML existe um pattern chamado ECB (Entity-Control-Boundary) que é utilizado no diagrama de Robustez que representa as classes de um sistema de acordo com suas responsabilidades e caso de uso.

Dentro do diagrama de sequência os objetos podem ser representado por um dos esteriótipos ECB, então não estranhe se você ver um diagrama de sequência com esses esteriótipos representando os objetos.

Esteriótipos ECB no diagrama de sequência. Fonte: [Givanaldo Rocha de Souza](https://docente.ifrn.edu.br/givanaldorocha/disciplinas/engenharia-de-software-licenciatura-em-informatica/diagrama-de-sequencia)

### Operadores de interação

O diagrama de sequência pode abrigar conceitos como condicionais e loops de repetição, a maioria dos exemplos básicos que você encontra na internet não utiliza esses conceitos, mas eles agregam muito valor ao diagrama.

Operator de interação: **ALT**. Fonte: [Aristófanes Corrêa Silva](http://www.deinf.ufma.br/~acmo/MOO_Seq.pdf)

Para entender melhor esses caras achamos um **blog post** muito interessante do **Creately** que mostra vários exemplos e ensina a utilizar os operadores de interação, para não copiar o pessoal do Creately aqui, recomendamos que vocês leiam esse post para entender melhor os conceitos do diagrama de sequência.

❤️ [Blog post recomendado](https://creately.com/blog/pt/diagrama/tutorial-do-diagrama-de-sequencia/) ❤️

A imagem utilizada acima foi tirada de uma apostila da UFMA que contém ilustrações muito interessantes que nunca tinha visto, é muito bacana se você quiser ver algumas ilustrações do diagrama em português.

❤️ [Apostila UFMA de UML [Capítulo - Diagrama de Sequência] - Pós Graduação em Engenharia de Eletricidade](http://www.deinf.ufma.br/~acmo/MOO_Seq.pdf) ❤️

## Diagrama de colaboração (ou comunicação)

Assim como no diagrama de sequência, o diagrama de colaboração também demonstra as interações entre os objetos do sistema, porém diferente do diagrama de sequência o diagrama de colaboração não contém o espaço de tempo, ou seja, ele independente do tempo, mostrando apenas as sequências de interações entre os objetos do sistema que são numeradas.

Você deve optar pelo diagrama de sequência quando o objetivo for visualizar a sequência em relação ao tempo e optar pelo diagrama de colaboração quando o objetivo for visualizar as interações dentro de um contexto específico.

### Conceitos

[Imagens retiradas de apostila da UFMA [9]](http://www.deinf.ufma.br/~geraldo/dob/10.Comunicacao.pdf)

---

Os principais elementos envolvidos em um diagrama de colaboração são os seguintes:

* Objeto: Instância da classe.


* Vínculo: Ligações entre os objetos.


* Mensagem: Mensagem a um método.


Os objetos podem ter restrições, que são criadas a partir das interações, sendo essas as seguintes:

* New: um objeto ou um vínculo é criado durante uma interação.
* Destroyed: um objeto ou um vínculo é destruído durante uma interação.
* Transient: um objeto ou um vínculo é criado, destruído e recriado em uma mesma interação.

Segue abaixo um exemplo completo de diagrama de comunicação/colaboração

Exemplo de diagrama de comunicação. Fonte: Fakhroutdinov, K. [10]

## Diagrama de atividade

Os diagramas de atividade, junto com os diagramas de caso de uso e de máquina de estados, são considerados diagramas de comportamento, porque descrevem o que é necessário acontecer no sistema sendo modelado.

Esses diagramas tem uma atuação fundamental em juntar áreas de negócio e de desenvolvimento de certa corporação ou organização, para entendimento de ambos sobre o mesmo processo e/ou comportamento. Na construção de Diagramas de Atividade, existem certos conjuntos de símbolos especiais que devem ser utilizados, como os de iniciar, encerrar, receber etapas no fluxo e afins. Nesse diagrama, é muito importante se comunicar com clareza, já que as "partes envolvidas" lidam com muitas questões, e precisam ter clareza nas informações recebidas.

Exemplo de diagrama de atividade para uma página de login. Fonte: Lucidchart. [11]

Diagramas de atividades são, normalmente, utilizados para modelar 3 coisas: processos, operações internas ou processos de negócios. Ele lembra um fluxograma, porém com um propósito que envolve capturar ações e seus resultados, quando falamos de mudanças do estado do objeto. Esta diagramação é representada por um gráfico de atividades que mostram um fluxo, que se apresenta em forma de setas direcionadas, mostrando a sequência entre os estados de atividade, que são as ações.

### Componentes básicos do diagrama de atividade

O diagrama de atividade contém alguns componentes básicos para sua representação, que são: **Nó inicial, final e de decisão, e ações.**

O **Nó inicial** é representado por uma esfera preta, e como o próprio nome indica, dá início ao diagrama;

O **Nó final** é representado por uma esfera preta delineada, e como o próprio nome indica, dá um encerramento ao diagrama;

O **Nó de decisão** é representado por uma losango, e indica uma bifurcação do fluxo do diagrama;

As **Ações** são representadas por retângulos, e representam, como o nome indica, as ações realizadas durante o fluxo do diagrama;

<!-- O **Fork** é representadas por uma seta que aponta para uma bifurcação, e representa uma atividade que é subdividida em duas tarefas.

O **Join** é representado ;

Fork: Significa que uma atividade
chegou neste ponto e foi
subdividida em mais de uma
atividade.
 Join: Significa que uma atividade
chegou num mesmo ponto e criouse uma nova atividade
-->
## Diagrama de componente
Os Diagramas de componentes têm o propósito de apresentar o sistema de software estruturalmente, mostrando suas interfaces, suas dependências e, como o nome indica, seus componentes. Eles demonstram também certa versatilidade, uma vez que permitem a sua utilização para a modelagem de sistemas em baixo e também alto níveis.

### Utilidade
Diagramas de componentes tem diversas utilidades e propósitos. Alguns deles envolvem a revelação de problemas de configuração, através de relacionamentos de dependências. Também é muito oportuno na definição de quais aspectos do software serão executáveis e/ou reutilizáveis.
Além disso, esses diagramas servem para dar uma noção mais precisa de um aplicativo de software antes de fazer as alterações ou aprimoramentos necessários na aplicação.

### Tipos de componentes
Os componentes presentes nesse tipo de diagramação, são peças básicas na implementação de um sistema. Na prática, consistem em conjuntos de artefatos físicos em formato digital, como arquivos de código ou até arquivos de documentos relativos ao negócio. Quando falamos dos tipos de componentes, podemos dividi-los em 3 distintos: os componentes de instalação, de trabalho e de execução.
Os componentes de instalação constroem a base dos sistemas executáveis, como as classes Java, por exemplo. Os componentes de trabalho são os que baseiam a criação dos componentes de instalação, então podemos ter exemplos como arquivos de código, documentos e arquivos de dados. Por último, os componentes de execução são criados a partir do resultado da execução de determinado sistema, como processos, threads e agentes de software.
Componentes de software são partes físicas de um sistema, ou seja, não são apenas abstrações na mente do analista, como temos nos conceitos de classes. Além disso, um componente implementa uma ou mais classes, que são representadas dentro dos símbolos dos componentes ou com relações explícitas de dependência de implementação.


Exemplo de Diagrama de componentes para um gerenciamento de bibliotecas. Fonte: Creately. [12]

### Símbolos
Assim como diversos outros diagramas da UML, o de componentes têm diferentes símbolos de representação dos mesmos componentes, e alguns deles são:

Exemplo de símbolo de componente. Fonte: Creately. [12]
Uma das maneiras de utilizar o símbolo de componentes é a representada acima, pelo retângulo com o ícone do componente no canto superior direito, e com o estereótipo do componente no centro.

Exemplo de representação de conector entre componentes. Fonte: Creately. [12]

Em diagramas de componentes, interfaces apresentam como os componentes são interligados. O conector acima representa a vinculação da interface necessária do componente, demonstrado com um semi-círculo e uma linha sólida (vinda do componente da esquerda), com a interface fornecida, demonstrada com um círculo cheio e uma linha sólida (vinda do componente da direita). Essa representação demonstra que um componente fornece um serviço que outro exige.

Exemplo de símbolo de porta. Fonte: Lucidchart. [13]

O símbolo de porta, representado acima, também pode aparecer em diagramas de componentes, e serve para especificar um dos pontos de interação separados, entre o componente e o ambiente em que está sendo demonstrado pelo diagrama.

Exemplo de símbolo de dependência. Fonte: Lucidchart. [13]

Assim como muitos outros diagramas da UML, o diagrama de componentes não é diferente em seu relacionamento de dependência, que é representado por uma seta com uma linha pontilhada. Esse relacionamento, dentro desse tipo de diagrama, representa que certa parte do sistema depende de outra, para operar da forma correta. Este símbolo vincula um componente ou um elemento a outro.
### Benefícios
Portanto, o diagrama de componentes tem uma clara diferença perante a diagramas mais conhecidos da UML, uma vez que busca representar todo o modelo físico do sistema. Além disso, ele se preocupa em dar atenção a todos os componentes do sistema físico, e qual será a relação entre eles. Essas características trazem uma grande importância a esse diagrama, uma vez que ajudarão as equipes de desenvolvimento a terem um maior entendimento do ambiente em que trabalharão, pois isso com certeza afetará o trabalho de cada um de determinada equipe. E esse diagrama traz um conhecimento de qualidade e importância e que faz muita diferença.

## Diagrama de implantação

### Utilidade
Apesar de alguns dos diagramas propostos pela UML tratarem mais da parte física dos sistemas analisados, o Diagrama de implantação é o mais físico deles. Ele ajuda a focar a questão da organização da arquitetura física do software a ser implantado e executado em termos de hardware. Ou seja, esse diagrama ajudará a equipe a ter um melhor mapeamento de suas máquinas, desde computadores pessoais a servidores, que suportam o sistema, além de também apresentar uma definição da conexão e interação dessas máquinas, através de protocolos de comunicação e transmissão de informações.
Os Diagramas de implantação auxiliam na modelagem da topologia de hardware de um sistema, mostrando o funcionamento da arquitetura de um sistema. Ele é um forte aliado para descrição de sistemas complexos e distribuídos, onde os hardwares envolvidos têm papel fundamental na execução da aplicação. Obviamente todo software depende de algum hardware para sua execução, mas em alguns casos o modelo físico requer uma atenção maior, por conta de sua complexidade, como em casos de utilização de um software na nuvem, onde existem diversas demandas como a determinação dos recursos necessários, número de servidores a serem comunicados e outras informações.

### Símbolos básicos

#### Nós
Exemplo de símbolo de nó. Fonte: Creately. [14]

Os nós são componentes fundamentais do Diagrama de Implantação. Ele permite a ilustração de um item de hardware, como um servidor em que um ou mais módulos do software são executados ou que armazene arquivos consultados pelos módulos do sistema, ou pode representar um ambiente de execução, ou seja, um ambiente que suporta o sistema de alguma forma. Eles também podem conter outros nós, e é comum que representem um item de hardware contendo outro nó representando um ambiente de execução, embora eles também possam ser representados separadamente, com os ambientes de execução contendo outros ambientes dentro de si.

#### Artefatos

Exemplo de símbolo de artefatos. Fonte: Creately. [14]

Os artefatos são elementos concretos, entidades físicas existentes no mundo real que são causados por um processo de desenvolvimento. Exemplos de artefatos são bibliotecas, arquivos, arquivos de configuração, arquivos executáveis. Estes artefatos devem estar implementados dentro de um nó.

#### Associação entre nós
Exemplo de símbolo de associação entre nós. Fonte: Devmedia. [15]

Para simbolizar a troca de informações entre os nós, existem as associações entre os nós, que são representadas por retas que conectam os nós. Essas associações podem conter estereótipos utilizados para determinar tipos de protocolos e comunicações utilizadas entre os nós, por exemplo.

### Exemplo
Utilizando alguns dos elementos básicos deste diagrama, que são os Nós, que representam os componentes, Associações entre Nós, que são as ligações entre os Nós do diagrama, e os Artefatos, que representam entidades físicas do mundo real, podemos demonstrá-los aplicados no exemplo a seguir:

Exemplo de símbolo de associação entre nós. Fonte: Devmedia. [15]

Neste diagrama, podemos ver que a comunicação entre o Nó Hardware do Autor, equipamento utilizado pelo autor para desenvolver o artigo, e o Nó Servidor de Aplicação I, equipamento instalado do lado do servidor onde a aplicação Sistema de Controle de Submissões está instalada, passa pelos Nós Servidor de Comunicação, equipamento que terá a função de garantir a alta performance e cuidará da transmissão e da recepção dos dados, e também passa pelo Servidor de Firewall, que é responsável pela proteção da arquitetura do sistema. Podemos também notar a presença do nó de Servidor de Banco de Dados, presente entre os Servidores de Aplicação I e II, tendo o relacionamento e passagem de informações com ambos.

### Benefícios
Portanto, podemos observar que o Diagrama de implantação traz uma oportunidade de modelagem e entendimento de aspectos não muito explorados pela maioria dos demais diagramas da UML, que são representados nas partes físicas da operação de determinado sistema. Essa nova abordagem é muito vantajosa por justamente oferecer uma visão operacional e específica de ferramentas que serão utilizadas no hardware, como serão passadas as informações necessárias para o melhor andamento do projeto, e que recursos serão necessários para a melhor execução possível do projeto. Essas características trazem muita vantagem para o time que se utilizar desse diagrama, especialmente os que encaram sistemas fisicamente complexos, para justamente ter um planejamento bem definido e estruturado, a fim de evitar complicações e inconsistências futuras.

---

# Links interessantes e referências

## Referências

[1] Pacievitch, Y., n.d. História da Programação - Informática. [online] InfoEscola. Available at: <https://www.infoescola.com/informatica/historia-da-programacao/> [Accessed 8 April 2021].

[2] Laia, W., 2013. A evolução do software. [online] TI Especialistas. Acessível em: <https://www.tiespecialistas.com.br/a-evolucao-do-software/> [Acessado em 8 de Abril de 2021].

[3] Apostila ETEC Lauro Gomes - [Linguagem de modelagem unificada em Português](http://www.etelg.com.br/paginaete/downloads/informatica/apostila_uml.pdf)

[4] OMG® Unified Modeling Language® Version 2.5.1 - [Complete Specification](http://www.etelg.com.br/paginaete/downloads/informatica/apostila_uml.pdf)

[5] D. Abdala, P., 2021. Diagrama de Estados. [ebook] pp.1-3. Available at: <http://www.facom.ufu.br/~abdala/DAS5312/Diagrama%20de%20Estados.pdf> [Accessed 17 April 2021].

[6] Figueiredo, E. Relacionamentos do Diagrama de Classes. Disponível em: <https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/uml-diagrama-classes-relacionamentos_v01.pdf> [Acessado 11 de abril 2021]

[7] Figueiredo, E. Diagrama de Classes. Disponível em: <https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/uml-diagrama-classes_v02.pdf> [Acessado 11 de abril 2021]

[8] Braz Jr., G. Curso de Especialização - DEINF - UFMA. Disponível em: <http://www.deinf.ufma.br/~geraldo/dob/8.Objetos.pdf> [Acessado em 10 de abril de 2021]

[9] Diagrama de comunicação., G. Curso de Especialização - DEINF - UFMA. Disponível em: <http://www.deinf.ufma.br/~geraldo/dob/10.Comunicacao.pdf> [Acessado em 21 de Abril de 2021].

[10] Fakhroutdinov, K., (2010) UML Communication Diagrams Overview. [ONLINE]. Disponível em: https://www.uml-diagrams.org/communication-diagrams.html [Acessado 22 de Abril de 2021].

[11] Lucidchart - [ O que é diagrama de atividades UML?](https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-atividades-uml)

[12] Creately - [ O Guia Fácil de Diagramas de Componentes](https://creately.com/blog/pt/diagrama/tutorial-de-diagrama-de-componentes-2/)

[13] Lucidchart - [ Diagrama de componentes UML: o que é, como fazer e exemplos](https://www.lucidchart.com/pages/pt/diagrama-de-componentes-uml)

[14] Creately - [ O Guia Fácil de Diagramas de Implantação UML](https://creately.com/blog/pt/diagrama/tutorial-do-diagrama-de-implantacao/)

[15] Devmedia - [ Artigo SQL Magazine 68 - Utilizando UML: Diagramas de Implantação, Comunicação e TempoArtigo SQL Magazine 68 - Utilizando UML: Diagramas de Implantação, Comunicação e Tempo
](https://www.devmedia.com.br/artigo-sql-magazine-68-utilizando-uml-diagramas-de-implantacao-comunicacao-e-tempoartigo-sql-magazine-68-utilizando-uml-diagramas-de-implantacao-comunicacao-e-tempo/16353)
## Links interessantes sobre o assunto

https://micreiros.com/diagrama-de-objetos/

https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-objetos-uml

http://spaceprogrammer.com/uml/compreendendo-multiplicidade-e-os-tipos-de-associacao/

https://www.lucidchart.com/pages/pt/diagrama-de-caso-de-uso-uml

https://www.ateomomento.com.br/uml-diagrama-de-atividades/

https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-atividades-uml

https://www.lucidchart.com/pages/pt/diagrama-de-caso-de-uso-uml

https://medium.com/operacionalti/uml-diagrama-de-casos-de-uso-29f4358ce4d5

https://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408

https://pt.wikipedia.org/wiki/Diagrama_de_classes

http://www.professorvida.com.br/if62c/material/relacionamentos.pdf

https://www.ibm.com/docs/pt-br/rsar/9.5?topic=designing-modeling

https://homepages.dcc.ufmg.br/~amendes/GlossarioUML/glossario/conteudo/atividades/diagrama_de_atividades.htm

http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ES_II_2013_1/UML_Aula3.pdf