Introdução

---

Visão Geral

A UML 2.0 organiza os diagramas em duas categorias principais:

Categoria	Propósito
Diagramas Estruturais	Capturam a organização física dos elementos — como os objetos se relacionam entre si
Diagramas Comportamentais	Focam em como os elementos interagem, mudam de estado e processam comportamentos ao longo do tempo

💡 Princípio Fundamental: Um modelo UML consiste em um ou mais diagramas. Cada diagrama representa uma determinada visão ou interesse no sistema sendo modelado. Elementos individuais frequentemente aparecem em múltiplos diagramas.

---

🔷 Diagramas Estruturais

Diagramas estruturais modelam a arquitetura estática do seu sistema — o “o quê” em vez do “como”.

1. Diagramas de Classes

Propósito: Classes de modelo, interfaces e suas relações estáticas.

Elementos Principais:

• Classes com atributos e operações

• Interfaces e relações de realização

• Associações, agregações, composições e generalizações

• Modificadores de visibilidade (+, -, #, ~)

• Especificações de multiplicidade (1, 0..*, 1..5)

Exemplo de Uso:Quando usar:

Estereótipos e Tipos de Classe

O diagrama utiliza estereótipos (indicados por texto dentro de colchetes angulares, como <<entidade>>) para categorizar o papel de cada classe:

• Classes de Fronteira (<<fronteira>>): Essas lidam com a interação entre o sistema e seus atores (usuários ou sistemas externos).

• Exemplos: ConsoleWindow e CaixaDeDiálogo.

• Classes de Controle (<<controle>>): Essas gerenciam a coordenação, transações e fluxo de lógica de negócios do aplicativo.

• Exemplos: ContextoDeDesenho e ControladorDeDados.

• Classes de Entidade (<<entidade>>): Essas representam os dados principais ou informações persistentes que o sistema rastreia.

• Exemplos: Quadro, Janela, Evento, Forma, Círculo, Retângulo, Polígono, e Ponto.

• Classe Abstrata: O Forma a classe representa um conceito abstrato. Serve como um modelo base para formas específicas e não pode ser instanciada diretamente por si só.

---

Anatomia de uma Classe

Uma caixa de classe UML padrão é dividida em compartimentos. Olhando para a Círculo classe como exemplo:

• Nome da Classe: Localizado no compartimento superior (Círculo).

• Atributos: Localizado no compartimento central, representando os campos de dados.

• -raio : float (O sinal de menos - indica um atributo privado).

• -centro : int sem sinal

• Operações (Métodos): Localizado no compartimento inferior, representando os comportamentos ou funções.

• +area(raio : float) : double (O sinal de mais + indica um método público).

• +circun(), +setCentro(), e +setRaio().

---

Relações e Links

As linhas e setas que conectam as classes definem como elas interagem e dependem umas das outras:

Generalização (Herança)

Representado por uma linha sólida com uma seta vazia apontando para a classe pai. Isso indica uma relação “é-um” onde uma classe filha herda atributos e comportamentos de uma classe pai.

• Janela herda de Quadro.

• JanelaConsole e CaixaDialogo herdam de Janela.

• Círculo, Retângulo, e Polígono herdam da classe abstrata Forma (por exemplo, um Círculo é uma Forma).

Agregação

Representado por uma linha sólida com um losango vazio na extremidade do contêiner. Isso indica uma relação “tem-um” solta ou de todo-parte, onde a criança pode existir independentemente do pai.

• Janela agrega Forma (multiplicidade 1 a *). Um Janela pode conter múltiplas (*) formas, mas se a janela for fechada, as formas ainda podem existir conceitualmente na memória ou em outro contexto.

Composição

Representado por uma linha sólida com um losango preenchido (preto) na extremidade do contêiner. Isso indica uma relação “tem-um” forte com uma vida útil coincidente — se o contêiner for destruído, as partes também serão destruídas.

• Círculo é composto por Ponto objetos (multiplicidade 1 para *). Um círculo não pode existir sem seu centro ou pontos na fronteira; destruir o círculo destrói essas referências específicas a pontos.

Dependência

Representado por um seta tracejada. Mostra que uma classe depende de outra, ou seja, uma alteração na classe-alvo pode afetar a classe de origem.

• Janela tem uma dependência sobre Evento (indicado pela seta tracejada apontando para Evento). A janela depende de gatilhos de evento para executar operações como handleEvent().

Associação

Representado por uma linha simples e contínua. Indica uma relação estrutural em que objetos de uma classe estão conectados a objetos de outra.

• Caixa de Diálogo está associado a ControladorDeDados, ou seja, eles se comunicam entre si para trocar informações ou coordenar comportamentos.

---

Elementos de Documentação

• Nota: O diagrama apresenta uma caixa de nota com canto dobrado conectado por uma linha tracejada à Janela classe. Fornece contexto legível por humanos: “A janela principal do aplicativo.”

• Projetando arquitetura de software orientada a objetos

• Documentando modelos de domínio

• Gerando esqueletos de código

---

2. Diagramas de Componentes

Propósito: Mostrar a organização e as dependências das unidades de implementação.

Elementos Principais:

• Componentes (estereotipados como «componente»)

• Interfaces fornecidas/necessárias (notação de bola e soquete)

• Conectores de montagem e relações de dependência

• Artifatos (saídas compiladas: JARs, DLLs, executáveis)

Uso Exemplo:Quando usar:

Componentes e Fronteiras Modulares

No centro do diagrama está o conceito de um componente, uma unidade autônoma e modular de um sistema que encapsula seus conteúdos e manifesta seu comportamento por meio de interfaces claras. A grande borda externa representa o Terminal componente, que atua como um subsistema ou contêiner. Dentro desse contêiner residem componentes internos menores e especializados — nomeadamente Inspeção de Segurança, Equipe, Defeito, e Mapa. Cada uma dessas unidades internas representa uma peça modular de software ou lógica de gerenciamento de dados trabalhando juntas para cumprir as responsabilidades do Terminal.

Interfaces como Contratos

Componentes não expõem diretamente sua lógica interna; ao invés disso, interagem por meio de interfaces bem definidas que atuam como contratos arquitetônicos.

• Interfaces Fornecidas: Representadas por um símbolo de “guloseima” ou círculo, essas indicam os serviços, dados ou operações que um componente implementa e oferece ao seu ambiente. Por exemplo, o componente Terminal externo expõe interfaces fornecidas externas como Estado, Detalhes, e Item de Inspeção, indicando o que os clientes externos podem solicitar dele.

• Interfaces Requeridas: Representadas por um símbolo de “soquete” ou semicírculo, essas especificam os serviços ou dados que um componente precisa de outra entidade para funcionar corretamente. No lado direito do diagrama, o componente Terminal expõe explicitamente interfaces requeridas para Conta e ID de Inspeção, mostrando suas dependências com subsistemas externos.

Portas e Fiação Interna

Para gerenciar o fluxo de dados e controle, preservando a encapsulação, o sistema utiliza portas e relações de delegação.

• Portas: Os pequenos quadrados localizados na borda dos componentes representam portas. Elas atuam como pontos de interação distintos pelos quais a estrutura interna do componente se conecta com o mundo exterior. As portas permitem que um componente isole sua fiação interna do ambiente externo, significando que componentes internos podem ser substituídos ou modificados sem alterar como o componente pai aparece para o exterior.

• Delegação e Montagem: Dentro do Terminal, linhas conectam essas interfaces para formar a montagem estrutural. Uma interface fornecida na porta externa delega solicitações recebidas diretamente para a interface fornecida de um componente interno (como visto com os caminhos de Estado e Detalhes que levam para Inspeção de Segurança). Por outro lado, os componentes internos conectam suas interfaces de soquete requeridas diretamente às interfaces de guloseima fornecidas de componentes vizinhos. Por exemplo, o componente Inspeção de Segurança depende da interface Inspetor fornecida por Equipe, a Detalhes do defeito interface fornecida por Defeito, e a Localização interface fornecida por Mapa, criando um ecossistema interno bem coordenado, mas fracamente acoplado.

• Planejamento da arquitetura modular do sistema

• Gerenciamento das dependências de compilação

• Documentação de bibliotecas de componentes reutilizáveis

---

3. Diagramas de Estrutura Composta(Adicionado na UML 2.0)

Elementos Principais:

• Partes (propriedades com relações parte-todo)

• Portas (pontos de interação com interfaces fornecidas/obrigatórias)

• Conectores (links em tempo de execução entre partes)

• Ocorrências de colaboração

Exemplo de Uso: Modelando um Carro:

Classificador Encapsulador (Classe)

O retângulo externo representa o classificador contido, neste caso, o Carro classe. Em um diagrama de estrutura composta, essa fronteira atua como um contêiner que encapsula a configuração em tempo de execução interna do sistema. Define o contexto em que instâncias individuais cooperam para alcançar um propósito comportamental mais amplo, escondendo a complexidade de como um “Carro” funciona internamente de entidades externas.

Partes (Estrutura Interna)

Os retângulos internos dentro da fronteira do Car representam Partes. Uma parte explica um papel desempenhado por um conjunto de instâncias durante a execução do classificador contido. Ao invés de mostrar uma relação estática em tempo de compilação (como um diagrama de classes padrão), essas partes indicam instâncias em tempo de execução preenchendo slots arquitetônicos específicos:

• -t : Transmissão: Uma instância desempenhando o papel do sistema de transmissão.

• -e : Motor: Uma instância desempenhando o papel da fonte de energia do motor.

• -s : Sistema de Direção: Uma instância desempenhando o papel do mecanismo de direção.

A notação de dois pontos indica que esses são papéis estruturais tipificados por suas respectivas classes, definindo exatamente quais componentes devem existir dentro de um Car operacional.

Portas e Fronteiras

Os pequenos quadrados embutidos na fronteira do classificador externo e nas fronteiras das partes internas representam Portas. As portas são pontos de interação distintos que desacoplam a estrutura interna de um classificador do seu ambiente externo.

• Portas externas na fronteira do Car—como : Roda, : Alavanca de Gasolina, e : Volante—exibem como o Car interage com o mundo exterior ou ambiente físico sem expor quaispartes internas estão lidando com essas interações.

• As portas nas partes internas (como as portas nos blocos de Transmissão ou Motor) regem como esses sub-sistemas se comunicam entre si ou com a fronteira pai.

Conectores e Fiação Interna

As linhas sólidas que conectam as portas representam Conectores. Os conectores definem os caminhos de comunicação entre partes ou entre uma parte e uma porta externa em tempo de execução.

• Conectores de Delegação: Conecta uma porta externa do container diretamente a uma porta interna de uma parte. Por exemplo, a porta externa : Roda porta rota diretamente para o Transmissão, e o externo : Volante rota diretamente para o Sistema de Direção. Isso garante que os estímulos externos sejam delegados de forma contínua para o ator interno correto.

• Conectores de Montagem: Liga partes internas para permitir colaboração. O conector entre o Transmissão e o Motor mostra que essas duas funções de tempo de execução distintas trocam diretamente sinais, dados ou força mecânica para que o carro funcione como um todo unificado.

Quando usar:

• Documentar padrões de design

• Modelar colaborações internas complexas

• Ponte entre o design de classes e a implementação de componentes

---

4. Diagramas de Implantação

Propósito: Mapear artefatos de software para ambientes de execução de hardware.

Elementos Principais:

• Nós (dispositivos, ambientes de execução)

• Artefatos (unidades implantáveis)

• Caminhos de comunicação entre nós

• Especificações de implantação (detalhes de configuração)

Uso Exemplo:Quando usar:

Nós e Infraestrutura Física

Diferentemente dos diagramas de design lógico que modelam o layout do código ou estruturas de classes, um diagrama de implantação foca na topografia de hardware. Os principais blocos de construção sãoNós, que são representados visualmente como cubos tridimensionais. Os nós ilustram recursos computacionais físicos ou ambientes de execução onde os elementos de software realmente funcionam:

• <<processador>> Nós: Cubos estereotipados com<<processador>> (comoServidor de Cache, Servidor Principal, e genéricosServidor blocos) representam nós com capacidade computacional, memória e poder de processamento capazes de executar binários de software.

• <<rede>> Nós: O cubo alongado rotulado comoRede Local representa um caminho de comunicação ou infraestrutura de roteamento, e não um computador individual. Indica a estrutura física que permite que processadores conectados troquem fluxos de pacotes de dados.

• Nós de Dispositivos: Nós não estereotipados comoInternet eBanco de Modems representam componentes de hardware de fronteira ou infraestrutura física externa necessária para rotear tráfego externo para o ambiente central do sistema.

Associações e Rotas de Comunicação

As linhas sólidas que conectam os cubos tridimensionais representamAssociações. Em um diagrama de implantação, essas associações mapeiam os caminhos de comunicação física, links de rede ou conexões de hardware entre nós.

• A linha entre Internet e Banco de Modemsilustra o ponto de entrada de dados públicos externos na pilha de hardware.

• A associação que se estende do Banco de Modems para baixo até o Servidor de Cachemapeia o roteamento físico do tráfego entrante até a camada de cache de borda.

• Associações que conectam os Servidores de Cache e o Servidor Primário cluster ao Rede Localestabelecem como os componentes internos se comunicam por meio de uma infraestrutura compartilhada de barramento local de alta velocidade ou comutador de rede.

Empilhamento Topológico e Redundância

A disposição dos nós no diagrama mostra explicitamente a topologia de implantação e as escolhas de design arquitetônico para alta disponibilidade e distribuição de carga.

• Camada de Cache de Borda: Posicionados diretamente abaixo do hardware do modem de entrada estão dois nós distintos e paralelos Servidor de Cachenós. Essa configuração demonstra visualmente uma camada de borda redundante projetada para distribuir a carga de tráfego entrante e armazenar em cache ativos antes que as requisições alcancem a infraestrutura profunda.

• Granja de Servidores Internos: Posicionado na parte inferior da pilha, conectado por meio do Rede Local, é um cluster de servidores principais. A diferenciação entre o Servidor Primário e o genérico adjacente Servidor os nós mapeiam visualmente uma arquitetura mestre-réplica ou primária-secundária, garantindo que a persistência de dados e as cargas de trabalho intensivas de computação sejam coordenadas com segurança no ambiente interno do centro de dados.

Propósito: Modelar a estrutura interna de classificadores e padrões complexos.

• Planejamento da infraestrutura do sistema

• Documentação de arquiteturas distribuídas

• Especificar estratégias de failover e redundância

---

5. Diagramas de Pacotes

Propósito: Organizar e gerenciar namespaces por meio de agrupamento lógico.

Elementos Principais:

• Pacotes (retângulos com abas)

• Relacionamentos de importação/acesso («importar», «acesso»)

• Relacionamentos de fusão («fundir»)

• Visibilidade (+ público, - privado)

Exemplo de Uso:

Limites de Subsistema e Pacote

O diagrama depende fortemente da notação de “pasta” para representar agrupamentos lógicos de elementos de design.

• Subsistema: A grande pasta externa estereotipada como <<subsystem>> Gestão de Pedidos representa uma unidade comportamental principal e encapsulada do sistema físico. Atua como um contêiner de alto nível que agrupa componentes e pacotes relacionados necessários para executar a gestão de pedidos.

• Pacote: As pastas menores dentro e fora do subsistema (tais como UI, Processamento de Pedidos, e GUIManager) são pacotes padrão. São usados para organizar elementos em grupos gerenciáveis, estabelecer namespaces e definir limites de visibilidade dentro da arquitetura.

Dependências e Camadas

Setas tracejadas indicam Dependências, estabelecendo que uma mudança em um pacote (o destino) pode afetar o funcionamento do pacote de origem (a fonte).

• Dependências Internas: Dentro do subsistema de Gestão de Pedidos, uma clara camada arquitetônica de cima para baixo é visível. O UI pacote depende do Processamento de Pedidos, que por sua vez depende do Calculadora de Preços e Armazenamento Externo. Isso representa um fluxo arquitetônico em que elementos de apresentação de nível superior dependem de camadas de lógica de negócios central e de acesso a dados.

• Dependência de Pacote Externo: Os pacotes também podem depender de elementos fora de seus limites imediatos de subsistema. Por exemplo, o UI pacote tem uma dependência com o externo GUIManager. Da mesma forma, o Armazenamento Aleatório e Armazenamento de Fluxo pacotes na parte inferior cruzam a fronteira do subsistema para depender de estruturas de dados externas, destacando como o subsistema se integra em um ecossistema de software maior.

Abstração e Herança (Generalização)

O diagrama utiliza estilos especializados e setas de relacionamento para demonstrar padrões de design abstratos aplicados à arquitetura modular.

• Pacotes Abstratos vs. Concretos: Pacotes que contêm elementos abstratos ou definem uma estrutura semelhante a uma interface são representados com nomes em itálico (como Armazenamento Externo e Gerenciamento de Armazenamento). Por outro lado, pacotes que contêm implementações de código operacional, como Repositório e Armazenamento de Arquivo, usam texto padrão para indicar que são pacotes concretos.

• Generalização: Representado por uma linha sólida com um triângulo aberto e oco apontando para o pacote pai. Isso indica uma relação de herança ou implementação. Dentro do subsistema, Armazenamento Aleatório e Armazenamento de Fluxo especializam ou implementam a interface abstrata Armazenamento Externo interface. Fora do subsistema, o Repositório e Armazenamento de Arquivo pacotes generalizam-se para o nível abstrato GerenciamentoDeArmazenamento pacote, mostrando como o comportamento polimórfico e a classificação estrutural podem ser modelados no nível do pacote.

  

• Quando usar:

• Gerenciamento de grandes bases de código

• Definição de limites de módulos

• Controle de dependências de compilação

---

6. Diagramas de Objetos

Propósito: Mostrar instantâneos de instâncias e seus links em um momento específico.

Elementos principais:

• Objetos (nomes sublinhados: meuCarro:Carro)

• Ligações entre instâncias de objetos

• Valores de atributos em tempo de execução

Exemplo de uso:

Objetos e instâncias concretas

Diferentemente dos diagramas de classe, que mostram configurações abstratas e de nível de projeto, um diagrama de objetos captura instâncias reais que vivem na memória. Os objetos são representados por retângulos, e seus nomes são sempre sublinhados para indicar instanciação.

• Objetos nomeados: Esses seguem a sintaxe nomeInstância : NomeClasse. Por exemplo, c : Empresa representa uma instância específica de empresa chamada “c”, e p : Pessoa representa uma instância específica de indivíduo chamada “p”.

• Objetos Anônimos: Quando o identificador específico da instância é omitido ou irrelevante para o cenário, apenas o nome da classe é fornecido, precedido por dois pontos (por exemplo, : Informações de Contato). Isso especifica que uma instância concreta de informações de contato existe e está associada à estrutura, mas não precisa de um nome de variável exclusivo neste contexto.

Estado e Valores de Atributos

O compartimento inferior de um retângulo de objeto contém seu estado específico, definido por valores explícitos atribuídos aos seus atributos naquele momento. Em vez de apenas listar tipos de dados, essas entradas usam o formato atributo = valor de atribuição para refletir a realidade:

• A instância do departamento d1 possui o valor do atributo nome = Vendas.

• Outra instância distinta de departamento d2 possui o valor nome = P&D.

• A instância da pessoa p possui um conjunto completo de dados de estado, mapeando um perfil específico: nome = Derek, IDFuncionário = D-12821, e cargo = Gerente.

Links e Relacionamentos

As linhas sólidas que conectam os objetos representam Links. Uma ligação é uma instância concreta de uma associação definida entre classes. Se um diagrama de classes afirma que Empresas têm Departamentos, o diagrama de objetos demonstra as conexões reais em tempo de execução entre eles.

• A instância da empresa c está ativamente ligada às instâncias de departamento d1 (Vendas) e d2 (Pesquisa e Desenvolvimento).

• O diagrama também demonstra a conexão hierárquica de instâncias, onde d1 : Departamento (Vendas) está ligada a uma instância de sub-departamento também tipificada como Departamento (nome = Vendas EUA).

• Finalmente, a instância de pessoa p (Derek) está ligada à instância do departamento de Vendas EUA, ao mesmo tempo em que mantém uma ligação com uma instância anônima : Informações de Contato contendo seu endereço físico.

Quando usar:

• Validando projetos de diagramas de classes

• Depurando relações complexas entre objetos

• Demonstrando estados de tempo de execução de exemplo

---

🔶 Diagramas Comportamentais

Diagramas comportamentais modelam aspectos dinâmicos — como o sistema se comporta ao longo do tempo.

7. Diagramas de Atividades

Propósito: Modelar fluxos de trabalho, processos de negócios e lógica algorítmica.

Elementos Principais:

• Ações (retângulos arredondados)

• Nós de controle: inicial, decisão, fusão, ramificação, junção, final

• Nós de objeto e pinças

• Partições (cursos de natação) para atribuição de responsabilidades

• Tratadores de exceções e regiões interrompíveis

Exemplo de Uso: Fluxo de trabalho de processamento de pedidos

Organização Estrutural (Cursos de Natação e Partições)

O diagrama é organizado verticalmente em grandes colunas conhecidas indistintamente comoCursos de natação ou Partições. Essas fronteiras categorizam as responsabilidades pelas ações contidas neles, mapeando etapas para papéis ou unidades de negócios específicos:

• Interface de Vendas ao Cliente: Possui o ciclo de vida voltado para o cliente, gerenciando a inicialização do cliente, roteamento alternativo e a apresentação final.

• Proprietário da Proposta: Gerencia o planejamento central, a análise operacional e a compilação das estruturas de dados formais da proposta.

• Proprietário do Orçamento: Foca exclusivamente na avaliação financeira e na preparação das métricas específicas do orçamento.

Fluxo de Controle e Estados de Ação

A execução procedural passo a passo é direcionada por nós de controle e caminhos direcionados.

• Nó Inicial: Representado pelo círculo preto sólido no topo, isso indica o ponto de início de todo o fluxo de trabalho da atividade.

• Ação: Os retângulos arredondados (por exemplo, Iniciar Contato, Buscar Alternativa, e Compilar Informações Adicionais) representam etapas ou tarefas únicas e não decomponíveis dentro da sequência de execução.

• Fluxo de Controle: As setas sólidas que conectam os elementos determinam a progressão sequencial do fluxo de trabalho, indicando exatamente qual ação deve ser concluída antes que a próxima comece.

• Nó Final de Atividade: O símbolo de alvo (um círculo sólido dentro de um anel oco) na parte inferior marca o ponto absoluto de término da execução de todo o processo.

Roteamento e Lógica com Guardas (Nós de Decisão)

Símbolos em forma de losango representamNós de Decisão, que modelam ramificações condicionais no fluxo de trabalho.

• Os caminhos de controle de entrada são divididos em múltiplos caminhos de saída mutuamente exclusivos com base em entradas específicas.

• As condições que determinam qual caminho seguir são cercadas por colchetes, conhecidas como condições de guarda (como[aceito], [rejeitado], e[juntar com outro fornecedor ou alterar requisitos]). O processo avalia essas condições em tempo de execução para direcionar a execução pelo caminho funcional apropriado.

Processamento Paralelo (Nós de Fork e Join)

As barras pretas sólidas no diagrama atuam como pontos de sincronização para gerenciar fluxos de execução concorrentes ou paralelos.

• Nó Fork (rotulado como Nó de Fluxo na seta do diagrama): Um único fluxo de controle de entrada entra na barra e se divide em múltas threads de execução independentes e concorrentes. Aqui, após criar um plano de projeto, o processo se divide para permitir que o Proprietário da Proposta execute análise e planejamento de entrega, enquanto o Proprietário da Cotação simultaneamente trata a preparação da cotação.

• Nó Join: Uma barra de sincronização que combina múltiplos caminhos concorrentes de volta em um único fluxo de controle. O processo não pode passar pelo Nó Join até quetodos os fluxos paralelos de entrada tenham alcançado com sucesso a barra, garantindo que a compilação da cotação e o rascunho da proposta estejam totalmente finalizados antes de prosseguir para compilar o pacote final.

Integração de Dados (Nós de Objeto)

Retângulos padrão indicamNós de Objeto, que introduzem fluxo de dados no diagrama de atividade orientado a controle.

• Nós de objeto representam instâncias de dados específicos ou artefatos físicos produzidos ou consumidos por ações, usando onomeDaInstância : NomeDaClasse convenção (por exemplo, umaProposta : Proposta e umPlano : Plano de Entrega do Projeto).

• Explicitamente marcado criar as setas mostram exatamente quando uma ação instancia ou atualiza uma estrutura de dados, demonstrando como os dados fluem de tarefa para tarefa junto com a execução operacional.

Quando usar:

• Documentação de processos de negócios

• Modelagem de realizações de casos de uso

• Especificação de algoritmos complexos

---

8. Diagramas de Máquina de Estados (Statecharts)

Propósito: Modelar o ciclo de vida e o comportamento dependente de estado de objetos.

Elementos principais:

• Estados (retângulos arredondados com atividades de entrada/saída/fazer)

• Transições (disparador[guarda]/efeito)

• Pseudostados: inicial, escolha, divisão, junção, histórico, terminar

• Estados compostos e regiões ortogonais

Exemplo de uso: configuração de telefonia

Estados e condições do sistema

O diagrama captura o comportamento de um sistema—especificamente uma configuração de telefonia—mapeando suas diversas situações ou condições discretas.

• Estados: Os retângulos arredondados representam estados (por exemplo, Inativo, Tom de Discagem, Discando, Conectando, e Conectado). Um estado representa um período no ciclo de vida de um objeto durante o qual ele satisfaz alguma condição, executa uma atividade ou aguarda um evento.

• Estado Pseudo Inicial: O círculo sólido preto na extremidade esquerda representa o ponto de partida da máquina de estados. É um estado pseudo e não um estado verdadeiro, servindo meramente como um ponteiro para o estado ativo padrão quando o objeto é instanciado (Inativo).

• Estado Final: O símbolo de alvo na extremidade direita representa a terminação da execução da máquina de estados, indicando que o objeto completou seu ciclo de vida.

Transições e Roteamento Impulsionado por Eventos

As linhas direcionadas que conectam os estados são Transições, que representam o movimento de um estado para outro como resposta a um gatilho específico.

• Transições Padrão: Acionadas por eventos específicos, como uma ação do usuário ou resposta do sistema, indicados ao longo das linhas. Por exemplo, mover-se de Inativo para Tom de Discagem ocorre quando o evento onHook é acionado, e mover-se de Tom de Discagem para Discando acontece quando um dígito(n) evento é recebido.

• Transições próprias: Uma seta de transição que sai de um estado e retorna diretamente para o mesmo estado (como visto no Discando estado com o dígito(n) gatilho). Isso indica que o evento é processado e atualiza o contexto de estado interno (por exemplo, gravar um dígito recém-discado) sem fazer com que o objeto saia ou mude seu estado operacional geral.

Caminhos Alternativos e Tratamento de Erros

Máquinas de estado se destacam ao mostrar a lógica de comportamento e o ramificação de erros com base em condições variáveis durante a execução.

• Caminho de Execução Bem-Sucedido: A pipeline horizontal central mapeia o caminho ótimo: Ocioso $rightarrow$ Tom de Discagem $rightarrow$ Discando $rightarrow$ Conectando $rightarrow$ Toque $rightarrow$ Conectado $rightarrow$ Desconectado.

• Estados de Tratamento de Exceções e Erros: O sistema leva em conta falhas ou atrasos ramificando-se para estados dedicados de tratamento. Se um número estiver ocupado durante a conexão, o sistema dispara o númeroOcupado transição para entrar no Sinal de Ocupado estado. Se um usuário pausar por muito tempo durante a discagem, um tempo limite evento transfere o sistema para um Aviso ou Tempo Limite estado. Se uma sequência incorreta for detectada, um número inválido gatilho redireciona o sistema para um Mensagem Gravada estado, garantindo que o sistema manipule com segurança todos os casos extremos do mundo real.

 

Quando usar:

• Modelagem de sistemas embarcados ou implementações de protocolos

• Especificação da gestão de estados da interface do usuário

• Documentação das regras do ciclo de vida do objeto

---

9. Diagramas de Interação

Quatro tipos de diagramas enfatizam aspectos diferentes da colaboração entre objetos:

a) Diagramas de Sequência(Mais Comum)

Propósito: Mostrar trocas de mensagens ordenadas no tempo entre linhas de vida.

Elementos Principais:

• Linhas de vida (linhas tracejadas verticais)

• Mensagens (setas sólidas/tracejadas com rótulos)

• Ocorrências de execução (barras de ativação)

• Fragmentos combinados: alt, opt, loop, par, break

Uso Exemplo:

Linhas de Vida e Contextos de Execução

O diagrama é lido da esquerda para a direita para estabelecer os participantes, e de cima para baixo para indicar a passagem do tempo.

• Linhas de Vida: As caixas no topo conectadas a linhas verticais tracejadas representam linhas de vida. Elas modelam participantes individuais na interação, seguindo o padrão nomeInstância : NomeClasse convenção (por exemplo, janela : UI, aCadeia : CadeiaHotéis, e aHotel : Hotel). A linha tracejada rastreia a existência desse participante ao longo da sequência.

• Barras de Ativação: Os retângulos verticais finos e coloridos apoiados sobre as linhas de vida indicam uma Ativação (ou ocorrência de execução). Essas barras mostram exatamente quando um objeto está ativamente executando uma operação ou aguardando a conclusão de uma chamada aninhada.

• Parado: O grande símbolo “X” na parte inferior do janela : UI a linha de vida indica destruição ou término, mostrando que o ciclo de vida deste participante específico terminou e seus recursos foram liberados.

Tipos de Mensagem e Comunicação

A comunicação entre participantes é modelada por meio de setas horizontais que representam mensagens, ordenadas sequencialmente usando um sistema de numeração hierárquico (por exemplo, 1, 1.1, 1.1.1).

• Mensagens Síncronas: Linhas contínuas com pontas de seta sólidas (como 1: fazerReserva e 1.1: fazerReserva) indicam chamadas síncronas. O remetente bloqueia a execução e aguarda que o objeto receptor conclua seu processamento.

• Mensagens Auto-Referenciais: Um loop de mensagem que começa e termina na mesma barra de ativação (como 1.1.1: disponível(idQuarto, data): éQuarto executado por aHotel) representa uma Mensagem Auto-Referencial. Isso indica uma execução de método interna em que um objeto chama uma de suas próprias operações.

• Mensagens de Criação: Uma linha tracejada com uma ponta de seta aberta apontando diretamente para uma caixa de objeto (como a mensagem 1.1.2: apontando para aReserva : Reserva) representa a criação de um objeto. Isso mostra que a aHotel instância instância dinamicamente o aReserva objeto exatamente nesse momento na sequência de tempo de execução.

Fragmentos Combinados e Fluxo de Controle

Grandes caixas retangulares que envolvem seções da sequência são Fragmentos Combinados, que usam operadores de interação para gerenciar lógica complexa, ramificação e iteração.

• Fragmento de Loop: A caixa externa rotulada como loop com a condição de guarda [cada dia] representa iteração. Todas as interações contidas nesta caixa serão repetidas continuamente para cada dia especificado no pedido de reserva.

• Fragmento Combinado Alternativo (Alt): Embutido dentro do loop está um alt fragmento (anotado como “Se” na seta do diagrama), que trata a ramificação condicional. Ele avalia a condição de guarda [isRoom = true]. Se a condição for atendida, a sequência executa o caminho específico dentro desse bloco — criando a instância aReservation e, em seguida, disparando a mensagem 2: para instanciar aNotice : Confirmação. Se a condição fosse falsa, um caminho alternativo (ou nenhuma ação) seria tomado.

  

b) Diagramas de Comunicação

Propósito: Enfatizam as relações entre objetos em vez do tempo de mensagens.

Elementos Principais:

• Objetos como nós

• Ligações com mensagens numeradas e direcionadas

• Foco em “quem fala com quem”

c) Diagramas de Visão Geral de Interação

Propósito: Fluxo de controle de alto nível usando notação de diagrama de atividade.

Elementos Principais:

• Ocorrências de interação como nós de atividade

• Decisão/junção para ramificação

• Divisão/junção para paralelismo

d) Diagramas de Temporização

Propósito: Modelar restrições de tempo precisas (sistemas em tempo real).

Elementos Principais:

• Linhas de tempo de estado para cada linha de vida

• Escalas de tempo e restrições

• Setas de mensagem com marcadores de duração

Quando usar interações:

• Especificando realizações de casos de uso

• Depuração de fluxos de mensagens complexos

• Documentação de padrões de uso da API

• Modelagem do tempo de protocolos em tempo real

---

10. Diagramas de Casos de Uso

Propósito: Capturar requisitos funcionais da perspectiva de um ator externo.

Elementos Principais:

• Casos de uso (ovals ou retângulos de classificador)

• Atores (figuras de palito ou classificadores)

• Associações (ator ↔ caso de uso)

• Relacionamentos: «incluir», «estender», generalização

• Caixa de limite do sistema

Exemplo de Uso: Sistema de Caixa Eletrônico

Quando usar:

• Elicitação de requisitos com partes interessadas

• Definição do escopo e limites do sistema

• Planejamento de cenários de teste

---

🎯 Escolhendo o Diagrama Correto: Guia de Decisão

Objetivo	Diagrama(s) Recomendado(s)
Design da estrutura de classe	Classe, Objeto, Pacote
Modelar interações em tempo de execução	Sequência, Comunicação
Documentar fluxos de trabalho do negócio	Atividade, Caso de Uso
Especificar o ciclo de vida do objeto	Máquina de Estados
Planejar implantação do sistema	Implantação, Componente
Modelar padrões internos complexos	Estrutura Composta
Capturar restrições em tempo real	Diagrama de Tempo
Definir requisitos	Caso de Uso, Atividade

---

🔑 Princípios Chave de Modelagem

1. Comece simples: Comece com o tipo de diagrama que melhor corresponde ao seu objetivo imediato.

2. Itere: Aperfeiçoe os modelos à medida que o entendimento aprofunda-se—nenhum diagrama é “definitivo” na primeira versão.

3. O público importa: Ajuste o nível de detalhe de acordo com o leitor (desenvolvedores versus interessados).

4. Combine perspectivas: Use múltiplos diagramas para contar uma história completa (por exemplo, Caso de Uso → Sequência → Classe).

5. Estenda com cuidado: Use estereótipos, valores com marcadores e perfis para necessidades específicas do domínio—mas documente as convenções.

6. Mantenha-o legível: Omita detalhes irrelevantes; use notas para contexto complementar.

📌 Lembre-se: “UML é uma linguagem, não um método.” Oferece notação—não processo. Escolha diagramas que esclareçam a comunicação, não aqueles que apenas preencham caixas.

Conclusão

This post is also available in Deutsch, English, Español, فارسی, Français, English, Bahasa Indonesia, 日本語 and Polski.