Pular para conteúdo

🎓 Guia de Modelagem UML

"A modelagem não é apenas desenhar; é pensar visualmente para resolver a complexidade do software."

Bem-vindo à sua jornada na Linguagem de Modelagem Unificada. Este guia foi projetado para capacitar analistas e desenvolvedores a projetar sistemas robustos, escaláveis e bem documentados, cobrindo desde requisitos até a arquitetura física.

⚡ Atalhos Rápidos

  • Trilha de Aulas --- 16 lições modernas englobando análise, diagramas e integração. Iniciar Jornada

  • Slides Interativos --- Material visual otimizado com transições e suporte Reveal.js. Ver Slides

  • Quizzes e Prática --- Avalie seu progresso com 160 questões técnicas exclusivas. Testar Conhecimento

  • Laboratórios e Projetos --- Aplique conceitos de modelagem em cenários reais. Ver Projetos

  • Exercícios Progressivos --- Das questões conceituais ao desafio prático de modelagem. Praticar Agora

  • Setup e Ferramentas --- Configurações essenciais para StarUML, Visual Paradigm e mais. Configurar

🗺️ Mapa da Jornada (Módulos)

O curso está estruturado em 4 Módulos cruciais para a maestria em UML:

📦 Módulo 1: Fundamentos e Requisitos

Entendendo o problema para desenhar a solução. - Aulas 01 a 04: Introdução à Análise, Engenharia de Software, Intro UML e Diagrama de Casos de Uso.

📐 Módulo 2: Especificação e Estrutura

A anatomia estática do sistema. - Aulas 05 a 07: Especificação de Casos de Uso, e Diagrama de Classes (Partes 1 e 2).

🧠 Módulo 3: Modelagem Comportamental

Como os objetos colaboram e reagem ao longo do tempo. - Aulas 08 a 11: Diagrama de Sequência, Comunicação, Atividades e Estados.

💻 Módulo 4: Arquitetura e Integração Final

Da visão física ao projeto consolidado. - Aulas 12 a 16: Componentes, Implantação, Integração, Workshop e Projeto Final.

💡 Dicas de Sucesso

  1. Simplicidade é Chave: Não tente modelar cada detalhe. Foque no que agrega valor à comunicação.
  2. Consistência: Garanta que as classes no diagrama de sequência existam no diagrama de classes.
  3. Diagramas são Vivos: Use-os para discutir com o time, não apenas para documentar após o código.

Pronto para modelar? Ir para Aula 01

📘 Disciplina: Análise e Modelagem de Sistemas com UML

Carga sugerida: 80 horas Pré-requisitos: Lógica de Programação e Fundamentos de Engenharia de Software

🎯 Objetivo Geral

Capacitar o aluno a analisar requisitos e modelar sistemas de software utilizando a UML (Unified Modeling Language), aplicando boas práticas de engenharia de software e padrões de modelagem.

📚 Plano de Curso – 16 Aulas 🔹 Aula 1 – Introdução à Análise de Sistemas

Conceitos de sistema e sistema de informação

Papel do analista de sistemas

Ciclo de vida do software

Introdução à modelagem

🔹 Aula 2 – Fundamentos de Engenharia de Software

Processos de desenvolvimento (Cascata, Incremental, Ágil)

Levantamento de requisitos

Requisitos funcionais e não funcionais

Documento de requisitos

🔹 Aula 3 – Introdução à UML

Histórico da UML

Objetivos da modelagem

Estrutura da UML

Visões arquiteturais

🔹 Aula 4 – Diagrama de Casos de Uso

Atores

Casos de uso

Relacionamentos (include, extend, generalização)

Fronteira do sistema

Ferramentas de modelagem

Atividade prática: Modelar sistema simples (ex: biblioteca ou sistema acadêmico)

🔹 Aula 5 – Especificação de Casos de Uso

Fluxo principal

Fluxos alternativos

Regras de negócio

Escrita estruturada de requisitos

🔹 Aula 6 – Diagrama de Classes (Parte 1)

Classes e atributos

Métodos

Visibilidade

Relacionamentos

🔹 Aula 7 – Diagrama de Classes (Parte 2)

Associação

Agregação

Composição

Herança

Multiplicidade

Atividade prática: Modelagem estrutural completa

🔹 Aula 8 – Diagrama de Sequência

Objetos

Linha do tempo

Mensagens

Ativação

Criação e destruição de objetos

🔹 Aula 9 – Diagrama de Comunicação

Diferença entre sequência e comunicação

Interações entre objetos

Aplicações práticas

🔹 Aula 10 – Diagrama de Atividades

Fluxo de controle

Decisão

Paralelismo

Swimlanes

Atividade prática: Modelagem de processo de negócio

🔹 Aula 11 – Diagrama de Estados

Estados e transições

Eventos

Estados compostos

Aplicação em sistemas reativos

🔹 Aula 12 – Diagrama de Componentes

Arquitetura do sistema

Interfaces

Dependências

Organização em camadas

🔹 Aula 13 – Diagrama de Implantação

Nós

Artefatos

Distribuição física

Modelagem cliente-servidor

🔹 Aula 14 – Integração dos Diagramas

Rastreabilidade entre diagramas

Coerência e consistência

Boas práticas de modelagem

Revisão geral

🔹 Aula 15 – Projeto Prático (Workshop)

Definição do problema

Levantamento de requisitos

Construção completa da modelagem UML

Apresentação parcial

🔹 Aula 16 – Apresentação Final do Projeto

Entrega do projeto completo

Defesa técnica

Discussão crítica

Feedback final

🛠 Ferramentas Sugeridas

StarUML

Visual Paradigm

Lucidchart

Draw.io

📊 Metodologia

Aulas expositivas dialogadas

Estudos de caso reais

Modelagem incremental

Projeto prático em grupo

📌 Avaliação Sugerida

Exercícios práticos (20%)

Modelagens individuais (20%)

Projeto em grupo (40%)

Apresentação final (20%)

Aulas

Aulas do Curso

Bem-vindo à seção de aulas! Aqui você encontra todo o conteúdo do curso organizado por módulos.

📚 Módulos do Curso

Módulo 1 – Fundamentos e Requisitos

Módulo 2 – Especificação e Estrutura

Módulo 3 – Modelagem Comportamental

Módulo 4 – Arquitetura e Integração Final

Aula 01 - Introdução à Análise de Sistemas 🎯

Módulo

MÓDULO 1 – FUNDAMENTOS E REQUISITOS

1. O Universo da Análise de Sistemas 🌍

A análise de sistemas é o processo de coletar e interpretar fatos, diagnosticar problemas e utilizar essas informações para recomendar melhorias no sistema. É a base fundamental onde a Modelagem UML será aplicada.

🧠 Conceitos Estratégicos

Sistemas de Informação (SI)

Um SI não é apenas software. É um arranjo de pessoas, dados, processos e tecnologia que interagem para apoiar e melhorar as operações do dia a dia de um negócio.

O Analista como Arquiteto

O analista de sistemas atua como um tradutor, transformando necessidades de negócio em especificações técnicas precisas.

2. Abordagem Sistêmica e Pensamento Crítico 🔍

Para modelar bem, o analista deve enxergar o todo antes das partes.

mindmap
  root((Análise de Sistemas))
    Processos
      Entradas
      Transformação
      Saídas
    Dados
      Estrutura
      Persistência
      Fluxo
    Atores
      Usuários
      Sistemas Externos
      Administradores
    Feedback
      Monitoramento
      Correção

3. Estruturação de Workspace de Requisitos 💻

Um analista moderno utiliza o terminal para organizar a base de conhecimento do projeto.

mkdir projeto-uml-v1 && cd projeto-uml-v1mkdir -p docs/{ata-reuniao,diagramas,requisitos}echo "Status: Fase de Levantamento" > README.mdtree.
├── README.md
└── docs/
├── ata-reuniao/
├── diagramas/
└── requisitos/

4. Diferenciando Análise de Projeto 🎨

Característica Análise de Sistemas (O QUÊ) Projeto de Sistemas (COMO)
Foco Entendimento do problema Desenho da solução
Público Usuários e Stakeholders Desenvolvedores e Arquitetos
UML Casos de Uso, Atividades Classes, Sequência, Componentes
Objetivo Requisitos Funcionais Arquitetura Técnica

5. Mini-Projeto Prático 🚀

Cenário: Sistema de Gestão de uma Clínica Médica.

Desafio: 1. Identifique 2 processos críticos de negócio (ex: agendamento). 2. Liste 3 informações que não podem faltar no banco de dados. 3. Descreva uma regra de negócio (ex: "Só pode cancelar com 24h de antecedência").

Importante

Uma falha nesta etapa inicial pode comprometer todos os diagramas UML subsequentes. Analise antes de desenhar!

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Fundamentos de Engenharia de Software ➡️

Aula 02 - Engenharia de Software e Modelagem 🔧

Módulo

MÓDULO 1 – FUNDAMENTOS E REQUISITOS

1. Processos e Ciclos de Vida 🚀

A Engenharia de Software fornece a estrutura para que a análise e a modelagem UML ocorram de forma organizada. O ciclo de vida define quando cada diagrama deve ser construído.

🧠 Modelos de Desenvolvimento

Modelo Cascata (Tradicional)

Linear e sequencial. A modelagem UML deve ser completa antes da programação. Ideal para sistemas críticos com requisitos fixos.

Modelos Ágeis (Scrum/XP)

Iterativo e incremental. A modelagem UML é feita em "micro-doses" (Just-in-Time), focando na funcionalidade imediata.

2. A Abstração no Ciclo de Vida 📊

Diferentes fases do projeto exigem diferentes níveis de detalhamento na modelagem.

graph LR
    A[Requisitos] --> B[Análise]
    B --> C[Design]
    C --> D[Código]

    subgraph "Nível de Abstração"
        A -.- High((Alto))
        D -.- Low((Baixo))
    end

    style High fill:#f9f,stroke:#333
    style Low fill:#ccf,stroke:#333

3. Gestão de Requisitos com Markdown 💻

Documentar requisitos de forma clara é o primeiro passo para um diagrama de Casos de Uso impecável.

touch requisitos.mdecho "### RF01: Agendamento de Consulta" >> requisitos.mdecho "O sistema deve permitir que o paciente escolha médico e horário." >> requisitos.mdecho "### RNF01: Segurança" >> requisitos.mdecho "Os dados clínicos devem ser criptografados (LGPD)." >> requisitos.mdcat requisitos.md

4. Classificação Técnica de Requisitos 📑

Tipo Descrição Exemplo em UML
Funcional (RF) O que o sistema faz Caso de Uso / Sequência
Não-Funcional (RNF) Restrições e qualidades Notas no Diagrama
Regra de Negócio Lógicas e políticas Admonitions / Comentários

Dica de Analista

Nunca comece um diagrama UML sem ter uma lista de requisitos aprovada pelo stakeholder. O diagrama é o mapa dos requisitos.

5. Mini-Projeto Prático 🚀

Cenário: Dashboard de Investimentos.

Desafio: 1. Escreva 2 Requisitos Funcionais (RF). 2. Escreva 1 Requisito Não-Funcional de Performance (RNF). 3. Identifique um fluxo de exceção (ex: "Saldo insuficiente").

Atenção

Ignorar requisitos não-funcionais (como segurança ou latência) costuma quebrar a arquitetura física do sistema mais tarde.

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Introdução à Linguagem UML ➡️

Aula 03 - Introdução à Linguagem UML ⚙️

Módulo

MÓDULO 1 – FUNDAMENTOS E REQUISITOS

1. O Surgimento da Linguagem Padrão 📚

A UML (Unified Modeling Language) não é uma metodologia, mas sim uma linguagem visual para especificar, visualizar, construir e documentar artefatos de sistemas de software.

🧠 A "Guerra dos Métodos"

História e Evolução

Nos anos 90, existiam dezenas de linguagens de modelagem. A UML surgiu da unificação dos três métodos mais populares: Booch, OMT (Rumbaugh) e OOSE (Jacobson).

Por que padronizar?

Permitir que equipes diferentes, em lugares diferentes, entendam o projeto sem ambiguidades. É o "Plantão Técnico" do engenheiro de software.

2. A Estrutura dos 14 Diagramas 📊

A UML 2.5 é dividida em dois grandes grupos: Estruturais e Comportamentais.

graph TD
    A[UML 2.5] --> B[Estruturais]
    A --> C[Comportamentais]

    B --> B1[Classes]
    B --> B2[Objetos]
    B --> B3[Componentes]
    B --> B4[Implantação]

    C --> C1[Casos de Uso]
    C --> C2[Sequência]
    C --> C3[Atividades]
    C --> C4[Estados]

    style B fill:#e1f5fe,stroke:#01579b
    style C fill:#f3e5f5,stroke:#4a148c

3. Preparando o Ambiente UML 💻

Analistas utilizam ferramentas CASE (Computer-Aided Software Engineering) para desenhar e exportar modelos.

mkdir modelagem && cd modelagem# Simulando verificação de versão de plugin UMLuml-cli --versionUML-Generator v2.5.0# Criando estrutura de pacotes (Representação lógica)mkdir -p domain/services domain/entities infrastructure/dbtree.
└── domain/
├── services/
└── entities/

4. Visões do Modelo 4+1 (Kruchten) 🏗️

Visão Descrição Diagramas Chave
Lógica Funcionalidades para o usuário Classes, Estados
Processo Performance e paralelismo Atividades, Sequência
Desenvolvimento Organização do código Componentes, Pacotes
Física Topologia do Hardware Implantação
Cenários (+1) Requisitos base Casos de Uso

Dica de Ouro

Não use todos os diagramas em todos os projetos. Foque naqueles que resolvem as dúvidas da sua equipe.

5. Mini-Projeto Prático 🚀

Cenário: Sistema de Controle de Drones de Entrega.

Desafio: 1. Identifique qual visão seria mais crítica para este sistema (Física ou Processo?). 2. Liste 2 diagramas UML que ajudariam a explicar o funcionamento do drone. 3. Justifique o uso da UML em vez de apenas texto para descrever o sistema.

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Diagrama de Casos de Uso ➡️

Aula 04 - Diagrama de Casos de Uso 👥

Módulo

MÓDULO 1 – FUNDAMENTOS E REQUISITOS

1. O Contrato Funcional: Casos de Uso 📚

O diagrama de casos de uso é o coração da modelagem comportamental. Ele descreve o que o sistema faz do ponto de vista do usuário (Ator), sem se preocupar com o "como" interno.

🧠 Elementos Chave

Ator

Representa um papel desempenhado por um usuário humano ou um sistema externo que interage com o sistema.

Caso de Uso

Uma unidade funcional que representa uma tarefa completa realizada pelo sistema. Deve começar sempre com um verbo no infinitivo.

2. Modelagem Prática de Biblioteca 📊

Um diagrama de casos de uso define a fronteira do sistema e as interações principais.

graph LR
    subgraph "Fronteira: Sistema Biblioteca"
        UC1((Emprestar Livro))
        UC2((Consultar Acervo))
        UC3((Manter Usuário))
    end

    User((👤 Usuário))
    Admin((👨‍💼 Bibliotecário))

    User --> UC1
    User --> UC2
    Admin --> UC3
    Admin -- "Auxilia" --> UC1

    style User fill:#e1f5fe
    style Admin fill:#fff3e0

3. Relacionamentos: Include e Extend ⚙️

Entender a diferença entre dependência obrigatória e opcional é vital para o nível intermediário.

# Simulando validação de diagrama de casos de usouc-check --file biblioteca.uc> Verificando 'Emprestar Livro'...
> Localizado relacionamento 'include' -> 'Validar Login'
> Localizado relacionamento 'extend' -> 'Calcular Multa'
> Status: Sucesso!

Include vs Extend

  • Include: Obrigatório. (Ex: Para emprestar, sempre precisa validar o usuário).
  • Extend: Opcional/Condicional. (Ex: Calcular multa só acontece se houver atraso).

4. Generalização de Atores 🎭

Assim como no código OO, atores podem herdar permissões.

Ator Pai Ator Filho Benefício
Funcionário Gerente Gerente herda tudo que funcionário faz
Cliente Cliente VIP VIP possui extensões de desconto
Sistema Sistema de Pagamento Especialização de logs e APIs

5. Mini-Projeto Prático 🚀

Cenário: Sistema de Delivery de Comida.

Desafio: 1. Desenhe (mentalmente ou rascunho) 3 atores: Cliente, Entregador, Restaurante. 2. Identifique um caso de uso que use include. 3. Identifique um caso de uso que use extend.

Antipattern

Não tente modelar o fluxo do processo em Casos de Uso. Use-os para listar funcionalidades. Para fluxos, usaremos o Diagrama de Atividades.

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Especificação de Casos de Uso ➡️

Aula 05 - Especificação de Casos de Uso 📝

Módulo

MÓDULO 2 – ESPECIFICAÇÃO E ESTRUTURA

1. Documentação Detalhada 📚

Enquanto o diagrama de casos de uso mostra a visão geral, a especificação detalha o diálogo entre o ator e o sistema. É o documento que o desenvolvedor usará para codificar a lógica de negócio.

🧠 Componentes da Especificação

Fluxo Principal (Caminho Feliz)

Sequência de passos onde tudo ocorre conforme o esperado, sem erros ou desvios inesperados.

Fluxos Alternativos

Variações que ainda levam ao objetivo final, mas por caminhos diferentes (ex: pagar com cartão vs pagar com boleto).

Fluxos de Exceção

Tratamento de erros que impedem a conclusão da tarefa (ex: saldo insuficiente ou queda de conexão).

2. Dinâmica da Especificação 📊

A estrutura lógica de uma especificação segue uma ordem rigorosa de pré e pós condições.

graph TD
    A[Início] --> B{Pré-condições ok?}
    B -- Não --> C[Erro de Autenticação/Dados]
    B -- Sim --> D[Fluxo Principal]
    D --> E{Desvio?}
    E -- Alternativo --> F[Lógica Adicional]
    E -- Exceção --> G[Tratar Erro]
    F --> H[Pós-condições]
    G --> I[Log de Erro]
    H --> J[Fim - Sucesso]

3. Template de Especificação Pro 💻

Um analista sênior organiza as especificações de forma que sejam testáveis.

# Gerando template via CLI fictíciaspecification-tool create --id UC001 --title "Realizar_Venda"[SUCCESS] Template UC001 criado em docs/specs/cat docs/specs/UC001.md# UC001: Realizar Venda**Atores**: Vendedor (Primário), Gateway de Pagamento (Secundário)
**Resumo**: Registra a venda de produtos e valida o pagamento.

4. Estrutura de Fluxos e Regras 📑

Elemento Propósito Exemplo
Passo do Ator Ação externa "O Cliente insere o cartão"
Passo do Sistema Reação interna "O Sistema valida o PIN"
Regra de Negócio (RN) Condição lógica "Desconto de 10% para compras > R$ 500"

Dica de Redação

Use frases curtas e objetivas. Evite termos técnicos da implementação como "clicar no botão salvar" (use "solicitar gravação").

5. Mini-Projeto Prático 🚀

Cenário: Sistema de Check-in de Aeroporto (Totem).

Desafio: 1. Escreva o fluxo principal (4 passos) para "Realizar Check-in". 2. Crie um fluxo de exceção para "Documento Inválido". 3. Identifique uma pré-condição obrigatória.

Importante

Regras de Negócio (RN) devem ser citadas na especificação, mas detalhadas em um documento separado de regras, para facilitar a manutenção.

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Diagrama de Classes (Parte 1) ➡️

Aula 06 - Diagrama de Classes (Parte 1) 🏢

Módulo

MÓDULO 2 – ESPECIFICAÇÃO E ESTRUTURA

1. Fundamentos da Estrutura Estática 📚

O Diagrama de Classes é a espinha dorsal da UML. Ele descreve a estrutura do sistema mostrando suas classes, atributos, operações e os relacionamentos entre os objetos.

🧠 Anatomia de uma Classe

Os 3 Compartimentos

  1. Nome: Identificador da classe (ex: Paciente).
  2. Atributos: Variáveis de estado (ex: nome: String).
  3. Operações: Comportamentos ou métodos (ex: marcarConsulta()).

2. Visibilidades e Encapsulamento 📊

Na UML, utilizamos símbolos para representar o acesso aos membros da classe, refletindo os conceitos de Orientação a Objetos.

classDiagram
    class ContaBancaria {
        +numero: String
        #titular: String
        -saldo: Double
        +depositar(valor: Double)
        -atualizarLog()
    }

    note for ContaBancaria "+ Público\n- Privado\n# Protegido"

3. Prototipagem de Entidades via CLI 💻

Analistas podem validar a estrutura de dados criando classes rápidas para testar a lógica de atributos.

# Criando uma classe modelo rápida em Python para validar atributoscat <<EOF > entidade.pyclass Usuario:
def __init__(self, id, email):
self._id = id # Protegido
self.email = email # Público
self.__senha = None # Privado
EOFpython -c "from entidade import Usuario; print('Entidade validada!')"Entidade validada!

4. Identificando Classes no Domínio 📑

Candidato Por que é uma Classe? Exemplo de Atributos
Pessoas Papéis que interagem nome, cpf, dataNascimento
Coisas Objetos físicos ou lógicos numeroSerie, valor, status
Eventos Ocorrências no tempo dataHora, local, resultado

Dica de Modelagem

Não coloque "ID" ou "Código" em todas as classes no início. Foque nos atributos conceituais que definem o negócio primeiro.

5. Mini-Projeto Prático 🚀

Cenário: Sistema de Inventário de Loja de Games.

Desafio: 1. Desenhe a classe Produto com 3 atributos privados e 2 operações públicas. 2. Identifique os tipos de dados (String, Integer, etc) para cada atributo. 3. Use a notação UML correta (+, -, #).

Erro Comum

Evite classes "Deus" que fazem tudo. Quebre o sistema em classes menores e especializadas.

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Diagrama de Classes (Parte 2) ➡️

Aula 07 - Diagrama de Classes (Parte 2) 🔗

Módulo

MÓDULO 2 – ESPECIFICAÇÃO E ESTRUTURA

1. Relacionamentos Avançados 📚

Dificilmente uma classe vive sozinha. O poder da UML está em descrever como as classes se conectam para formar o sistema.

🧠 Tipos de Relacionamentos

Associação

Conexão estrutural básica. Pode ter nome e direção. (Ex: Professor ministra Disciplina).

Agregação (Todo/Parte Fraca)

O objeto parte pode existir sem o todo. (Ex: Time e Jogador. Se o time acabar, o jogador continua existindo).

Composição (Todo/Parte Forte)

O objeto parte morre com o todo. (Ex: Documento e Página. Se você rasgar o documento, a página não tem sentido sozinha).

2. Herança e Polimorfismo 📊

A generalização permite reaproveitar estrutura e comportamento, criando hierarquias ricas.

classDiagram
    class Veiculo {
        <<abstract>>
        +marca: String
        +acelerar()*
    }
    class Carro {
        +numeroPortas: Int
        +acelerar()
    }
    class Moto {
        +cilindrada: Int
        +acelerar()
    }
    Veiculo <|-- Carro
    Veiculo <|-- Moto

3. Validando Estruturas Complexas 💻

A multiplicidade define quantos objetos participam de um relacionamento.

# Analisando multiplicidade de um relacionamento 1..* (Um para Muitos)echo "Relacionamento: Pedido (1) <---* (Itens)"echo "Regra: Todo pedido deve ter ao menos 1 item."python -c "itens = []; print('Erro: Pedido vazio!') if not itens else print('Pedido OK')"Erro: Pedido vazio!

4. Multiplicidade e Navegabilidade 📑

Símbolo Significado Exemplo Prático
1 Exatamente um Um CPF pertence a 1 Pessoa
0..1 Zero ou um Uma Pessoa pode ter 0 ou 1 Carro
* Muitos (zero ou mais) Um Autor escreve * Livros
1..* Um ou muitos Uma NF possui 1..* Itens

Classes de Associação

Use quando o relacionamento em si possui atributos. Ex: Estudante e Disciplina se relacionam via Matrícula, que guarda a nota.

5. Mini-Projeto Prático 🚀

Cenário: Sistema de Gestão de Clínica Veterinária.

Desafio: 1. Identifique o relacionamento entre Dono e Pet (Agregação ou Composição?). 2. Desenhe uma classe de associação Consulta entre Veterinário e Pet. 3. Defina a multiplicidade entre Clínica e Sala.

Atenção

Cuidado com a Herança excessiva. Muitas vezes, uma Composição é mais flexível e evita o "Problema da Fragilidade da Classe Base".

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Diagrama de Sequência ➡️

Aula 08 - Diagrama de Sequência 🔄

Módulo

MÓDULO 3 – DIAGRAMAS COMPORTAMENTAIS UML

1. Fundamentos do Diagrama de Sequência 📚

Nesta aula, estudaremos o Diagrama de Sequência, que modela a interação entre objetos focando na ordem temporal das mensagens.

🧠 Conceitos Fundamentais

Ator/Objeto

Entidades que participam da interação, representadas por retângulos no topo do diagrama.

Linha de Vida (Lifeline)

Linha tracejada vertical que representa a existência do objeto ao longo do tempo.

Mensagem

Comunicação entre objetos, representada por setas horizontais com rótulos que indicam operação/método.

Ativação

Retângulo fino na linha de vida que indica quando o objeto está processando uma operação.

2. Anatomia do Diagrama de Sequência 📊

sequenceDiagram
    participant U as 👤 Usuário
    participant S as 📱 Sistema
    participant BD as 🗺 BD
    participant Email as 📧 ServicoEmail

    U->>+S: login(email, senha)
    S->>+BD: validarCredenciais(email, senha)
    BD-->>-S: credenciaisValidas: Boolean

    alt credenciais válidas
        S->>+BD: buscarDadosUsuario(email)
        BD-->>-S: dadosUsuario: Usuario
        S->>+Email: enviarNotificacaoLogin(usuario)
        Email-->>-S: emailEnviado: Boolean
        S-->>-U: loginSucesso(dadosUsuario)
    else credenciais inválidas
        S->>S: incrementarTentativasFalhas(email)
        S-->>-U: loginFalha("Credenciais inválidas")
    end

3. Tipos de Mensagens 📨

Mensagens Síncronas e Assíncronas

Mensagem Síncrona (-->)

Comportamento: Remetente aguarda resposta antes de continuar

**Uso**: Chamadas de método, consultas ao banco de dados

**Notação**: Seta sólida

**Exemplo**: `cliente.calcularDesconto(valor)`

Mensagem Assíncrona (->>)

Comportamento: Remetente não aguarda resposta

**Uso**: Notificações, logs, emails

**Notação**: Seta aberta

**Exemplo**: `sistema.enviarEmail(destinatario)`

Mensagem de Retorno (-->>)

Comportamento: Resposta a uma mensagem anterior

**Opcional**: Pode ser omitida se óbvia

**Notação**: Seta tracejada

4. Fragmentos de Combinação 💻

mkdir diagramas-sequenciacd diagramas-sequenciatouch processamento-pedido.mdecho "# Diagrama de Sequência - Processamento de Pedido" >> processamento-pedido.mdecho "" >> processamento-pedido.mdecho "## Fragmentos utilizados:" >> processamento-pedido.mdecho "- **alt**: Alternativas (if-else)" >> processamento-pedido.mdecho "- **opt**: Opcional (if)" >> processamento-pedido.mdecho "- **loop**: Repetição (while/for)" >> processamento-pedido.mdecho "- **par**: Paralelo (concorrência)" >> processamento-pedido.mdcat processamento-pedido.md

5. Fragmentos Avançados ⚙️

Alt (Alternative)

Estrutura Condicional

```mermaid sequenceDiagram participant C as Cliente participant S as Sistema

    C->>S: finalizarPedido()

    alt estoque suficiente
        S->>S: processarPagamento()
        S-->>C: pedidoConfirmado()
    else produto indisponível
        S-->>C: produtoIndisponivel()
    else pagamento negado
        S-->>C: pagamentoRejeitado()
    end
```

Loop (Repetição)

Estrutura de Repetição

```mermaid sequenceDiagram participant S as Sistema participant BD as BancoDados

    loop para cada item do pedido
        S->>BD: verificarEstoque(item)
        BD-->>S: quantidadeDisponivel
        S->>S: atualizarItemPedido(item)
    end
```

Par (Paralelo)

Processamento Paralelo

```mermaid sequenceDiagram participant S as Sistema participant Email as Email participant SMS as SMS participant Log as Log

    par notificar cliente
        S->>Email: enviarConfirmacao()
    and notificar por SMS
        S->>SMS: enviarSMS()
    and registrar auditoria
        S->>Log: registrarOperacao()
    end
```

6. Auto-Mensagens e Criar/Destruir 🎨

Auto-Mensagens

Mensagem para Si Mesmo

Representa operações internas de um objeto.

**Notação**: Seta que começa e termina na mesma linha de vida

**Uso**: Métodos privados, validações internas

Criar e Destruir Objetos

Criar Objeto

Notação: Mensagem apontando para o retângulo do objeto

**Rótulo**: `<<create>>` ou `new(parâmetros)`

Destruir Objeto

Notação: X no final da linha de vida

**Rótulo**: `<<destroy>>` ou `delete`

7. Boas Práticas 📐

Organização Visual

!!! tip "Diretrizes de Layout" 1. Objetos da esquerda para direita: Do ator para sistemas internos 2. Mensagens numeradas: Para processos complexos 3. Comentários: Explique lógicas não óbvias 4. Agrupamento: Use fragmentos para organizar fluxos

Granularidade Adequada

Nível de Detalhe

❌ Muito detalhado: objeto.setAtributo(valor), validarCPF()

✅ **Adequado**: `processarPagamento()`, `enviarConfirmacao()`

❌ **Muito genérico**: `processarPedido()` (sem mostrar interações internas)

8. Mini-Projeto Prático 🚀

Cenário: Sistema de Reserva de Quartos de Hotel

Desafio: 1. Identifique 3 participantes: Portador, Maquineta, Operadora. 2. Desenhe o fluxo de uma "Autorização de Compra". 3. Use um fragmento alt para tratar o cenário de "Saldo Insuficiente".

Dica de Sênior

Não modele cada linha de código. Foque nas mensagens importantes entre os componentes principais da arquitetura.

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Diagrama de Comunicação ➡️

Aula 09 - Diagrama de Comunicação 📢

Módulo

MÓDULO 3 – MODELAGEM COMPORTAMENTAL

1. Perspectiva Espacial: Comunicação 📚

Antigamente chamado de Diagrama de Colaboração, o Diagrama de Comunicação foca na organização estrutural dos objetos que trocam mensagens.

🧠 Diferenças Estratégicas

Foco na Estrutura

Enquanto a Sequência foca no tempo, a Comunicação foca nos links entre objetos. É excelente para visualizar o acoplamento do sistema.

Numeração de Mensagens

Como não há linha do tempo vertical, as mensagens são numeradas (1, 1.1, 2, etc.) para indicar a sequência da execução.

2. Visualizando a Colaboração 📊

O layout em grafo facilita ver quais objetos são "hubs" de comunicação no sistema.

graph LR
    User((👤 Atendente)) -- "1: criarPedido()" --> P[<u>:Pedido</u>]
    P -- "1.1: adicionarItem()" --> I[<u>:ItemPedido</u>]
    P -- "1.2: calcularTotal()" --> P
    P -- "2: validarEstoque()" --> E[<u>:Estoque</u>]

    style User fill:#e1f5fe
    style P fill:#fff3e0

3. Verificação de Vizinhança via CLI 💻

No desenvolvimento, o diagrama de comunicação nos ajuda a pensar em quais classes precisam de referências para outras.

# Analisando dependências de uma classe (Neighbors)depend-verify --class Pedido> Dependencies:
- ItemPedido (1..*)
- Estoque (1)
- Financeiro (1)
> Status: Acoplamento dentro do limite aceitável.

4. Quando usar Sequência vs Comunicação 📑

Característica Diagrama de Sequência Diagrama de Comunicação
Ponto Forte Ordem cronológica clara Caminhos físicos e links
Complexidade Melhor para muitos fragmentos(alt, loop) Melhor para poucas mensagens
Histórico Visão "Horizontal" Visão "Grafo"
Uso Ideal Lógica de algoritmos complexos Visualização de Arquitetura

5. Mini-Projeto Prático 🚀

Cenário: Sistema de Controle de Elevador.

Desafio: 1. Identifique os objetos: Botão, Controlador, Motor. 2. Desenhe as comunicações numeradas para "Chamar Elevador para o 5º andar". 3. Identifique qual objeto centraliza a lógica (o Hub).

Dica de Analista

Se o seu diagrama de comunicação parece uma "teia de aranha" confusa, seu sistema pode estar com alto acoplamento (muitas classes dependendo de muitas outras).

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Diagrama de Atividades ➡️

Aula 10 - Diagrama de Atividades 🏃‍♂️

Módulo

MÓDULO 3 – MODELAGEM COMPORTAMENTAL

1. Modelagem de Processos de Negócio 📚

O Diagrama de Atividades foca no fluxo de controle e de dados. É o melhor diagrama para descrever algoritmos complexos ou processos de negócio (workflow), sendo parente próximo do fluxograma tradicional.

🧠 Elementos de Controle

Nó de Decisão e União

Representado por um losango. Define caminhos alternativos baseados em condições (guards).

Fork e Join (Paralelismo)

Barras pretas grossas que indicam o início e o fim de atividades que ocorrem simultaneamente.

2. Orquestração do Fluxo 📊

Diferente do Sequência, o Atividades mostra "o que" acontece em ordem lógica de execução.

graph TD
    Start(( )) --> Pack[Empacotar Produto]
    Pack --> Fork{ }
    Fork --> Pay[Processar Pagamento]
    Fork --> Logis[Gerar Etiqueta]
    Pay --> Join{ }
    Logis --> Join
    Join --> Dispatch[Despachar Pedido]
    Dispatch --> End(( ))

    style Start fill:#000
    style End fill:#000,stroke:#fff,stroke-width:4px

3. Automação de Workflows via CLI 💻

Workflows modelados em Diagramas de Atividades podem ser convertidos em motores de regras ou scripts de automação.

# Simulando execução de um workflow de CI/CDworkflow-engine run --file deploy_atividades.yaml[STEP 1] Build: Success
[STEP 2] Parallel: [Unit Tests] [Linting]
[STEP 3] Deployment: Staging
[SUCCESS] Sistema online em produção.

4. Partições (Swimlanes) 🏊‍♂️

As raias ou "swimlanes" dividem as atividades por responsabilidade (quem faz o quê).

Raia Responsabilidade Atividades Comuns
Cliente Usuário externo Solicitar, Pagar, Receber
Vendas Departamento interno Validar Pedido, Faturar
Estoque Logística Separar, Embalar, Despachar

Dica de Fluxo

Use o Diagrama de Atividades para mapear processos manuais antes de tentar automatizá-los com software.

5. Mini-Projeto Prático 🚀

Cenário: Sistema de Cadastro de Novo Usuário com Confirmação de Email.

Desafio: 1. Desenhe o fluxo: Preencher Dados -> Enviar Email -> Aguardar Clique -> Ativar Conta. 2. Adicione uma decisão: "Email já existe?". 3. Adicione um fork para: Enviar Log de Auditoria e Enviar Boas-vindas ao mesmo tempo.

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Diagrama de Estados ➡️

Aula 11 - Diagrama de Estados 🔄

Módulo

MÓDULO 3 – DIAGRAMAS COMPORTAMENTAIS UML

1. Fundamentos do Diagrama de Estados 📚

Nesta aula, estudaremos o Diagrama de Estados (State Machine), que modela o comportamento dinâmico de objetos em resposta a eventos.

🧠 Conceitos Fundamentais

Estado

Condição ou situação na vida de um objeto durante a qual ele satisfaz alguma condição, executa atividade ou aguarda evento.

**Notação**: Retângulo com cantos arredondados

Transição

Mudança de estado causada por evento, podendo ter condição de guarda e ação associada.

**Notação**: Seta rotulada com `evento[guarda]/ação`

Evento

Ocorrência que pode disparar uma transição de estado.

**Tipos**: Chamada, sinal, mudança, tempo

2. Anatomia do Diagrama de Estados 📊

stateDiagram-v2
    [*] --> Criado : criar()
    Criado --> Ativo : ativar() [condiçõesOK]
    Criado --> Cancelado : cancelar()

    Ativo --> Suspenso : suspender()
    Ativo --> Bloqueado : bloquear() [violacao]
    Ativo --> Inativo : desativar()

    Suspenso --> Ativo : reativar()
    Suspenso --> Cancelado : cancelar()

    Bloqueado --> Ativo : desbloquear() [administrador]
    Bloqueado --> Cancelado : cancelar()

    Inativo --> Ativo : ativar()
    Inativo --> Cancelado : cancelar()

    Cancelado --> [*]

    state Ativo {
        [*] --> Normal
        Normal --> Premium : upgrade()
        Premium --> Normal : downgrade()
    }

3. Estados Especiais e Atividades 🔀

Estados Inicial e Final

Estado Inicial

Notação: Círculo preenchido [•]

**Comportamento**: Ponto de entrada da máquina de estados

**Regra**: Apenas uma transição de saída

Estado Final

Notação: Círculo com borda [◎]

**Comportamento**: Terminação da máquina de estados

**Característica**: Nenhuma transição de saída

Atividades em Estados

Entry, Do e Exit

Estado ___________ entry / açãoEntrada do / atividadeContínua exit / açãoSaída

**Entry**: Executada ao **entrar** no estado

**Do**: Executada **durante** a permanência no estado

**Exit**: Executada ao **sair** do estado

4. Transições Complexas 💻

mkdir estados-umlcd estados-umltouch pedido-estados.mdecho "# Estados do Pedido - E-commerce" >> pedido-estados.mdecho "" >> pedido-estados.mdecho "## Eventos possíveis:" >> pedido-estados.mdecho "- criarPedido()" >> pedido-estados.mdecho "- confirmarPagamento()" >> pedido-estados.mdecho "- cancelarPedido()" >> pedido-estados.mdecho "- enviarProduto()" >> pedido-estados.mdecho "- confirmarRecebimento()" >> pedido-estados.mdecho "" >> pedido-estados.mdecho "## Guardas (condições):" >> pedido-estados.mdecho "- [pagamentoAprovado]" >> pedido-estados.mdecho "- [estoqueDisponível]" >> pedido-estados.mdecho "- [dentroP prazo]" >> pedido-estados.md

5. Estados Compostos (Aninhados) 🎨

Hierarquia de Estados

Estado Composto

Definição: Estado que contém outros estados (sub-estados)

**Vantagem**: Reduz complexidade e permite reutilização

**Exemplo**:
```
Estado "Ativo"
├── Sub-estado "Funcionando"
└── Sub-estado "Manutenção"
```

Estados Paralelos (Concorrentes)

Regiões Paralelas

Uso: Quando objeto pode estar em múltiplos estados simultaneamente

**Notação**: Estados separados por linha tracejada

**Exemplo**: Telefone pode estar "Ligado" E "Conectado" ao mesmo tempo

6. Eventos e Triggers ⚙️

Tipos de Eventos

Evento de Chamada (Call Event)

Formato: nomeOperacao(parametros)

**Disparo**: Invocação de método ou operação

**Exemplo**: `sacar(valor)`, `login(usuario, senha)`

Evento de Sinal (Signal Event)

Formato: nomeDoSinal

**Disparo**: Recebimento de sinal assíncrono

**Exemplo**: `sistemaInicializado`, `falhaDetectada`

Evento de Tempo (Time Event)

Formatos: after(tempo), when(condição)

**Disparo**: Passagem de tempo ou condição temporal

**Exemplo**: `after(30 seg)`, `when(dataVencimento < hoje)`

Evento de Mudança (Change Event)

Formato: when(condição)

**Disparo**: Quando condição se torna verdadeira

**Exemplo**: `when(temperatura > 80)`, `when(saldo < 0)`

7. Aplicacões Práticas 🏢

Quando Usar Diagramas de Estados

!!! success "Ideal Para" - Objetos reativos: Respondem a eventos externos - Protocolos: Sequências de interação bem definidas - Interfaces de usuário: Botões, janelas, formulários - Dispositivos: Equipamentos com estados óbvios

**Exemplos**: Conta bancária, processamento de pedidos, elevador

!!! warning "Evitar Para" - Objetos passivos: Apenas armazenam dados - Operações simples: Cálculos diretos sem transições - Fluxos de controle: Use diagrama de atividades

**Exemplos**: Endereço, produto (sem ciclo de vida), relatórios

Integração com Outros Diagramas

!!! tip "Relação com Classes" - Estados correspondem a valores de atributos - Transições correspondem a métodos que alteram estado - Validação: Métodos devem respeitar transições válidas

5. Mini-Projeto Prático 🚀

Cenário: Ciclo de vida de um Ar-Condicionado Inteligente.

Desafio: 1. Identifique 3 estados básicos: Desligado, Resfriando, Ventilando. 2. Adicione um estado de "Manutenção" que só pode ser acessado via código técnico. 3. Defina o evento que faz o aparelho passar de "Resfriando" para "Ventilando" (ex: Temperatura Atingida).

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Diagrama de Componentes ➡️

Aula 12 - Diagrama de Componentes 🗜️

Módulo

MÓDULO 4 – DIAGRAMAS AVANÇADOS E ARQUITETURA

1. Visão Física do Software 📚

O Diagrama de Componentes descreve como o sistema é dividido em módulos físicos (arquivos, DLLs, pacotes, microserviços) e como eles se conectam através de interfaces.

🧠 Anatomia do Componente

Interfaces Fornecidas (Lollipop)

Serviços que o componente oferece ao mundo exterior. Representado por um círculo.

Interfaces Requeridas (Socket)

Serviços que o componente precisa para funcionar. Representado por um semicírculo.

2. Orquestração de Microserviços 📊

A modelagem de componentes é vital para entender o acoplamento entre serviços.

graph LR
    UI[Frontend Web] -- IAuth --> Auth[Serviço Autenticação]
    UI -- IOrder --> Order[Serviço Pedidos]
    Order -- IPayment --> Pay[Gateway Pagamento]
    Order -- IStock --> Stock[Serviço Estoque]

    style UI fill:#e1f5fe
    style Pay fill:#f1f8e9

3. Inspeção de Dependências via CLI 💻

Em projetos modernos, os componentes são gerenciados por gerenciadores de pacotes (npm, pip, maven).

# Analisando árvore de dependências do projetodependency-tree list --depth 1├─ api-gateway (v2.1)
│ ├─ auth-module
│ └─ order-module
└─ shared-utils (v1.0)
[SUCCESS] Nenhuma vulnerabilidade detectada.

4. Camadas e Responsabilidades 📑

Camada Componentes Comuns Regra de Ouro
Apresentação Controllers, Views Nunca acessa o Banco diretamente
Negócio Services, Entities Contém a lógica de domínio
Dados Repositories, DAOs Foca apenas em persistência
Integração API Clients, Adapters Isola sistemas externos

Dica de Arquitetura

Sempre prefira depender de interfaces (abstrações) do que de implementações concretas. Isso facilita os testes e a manutenção.

5. Mini-Projeto Prático 🚀

Cenário: Arquitetura de um Aplicativo de Delivery.

Desafio: 1. Identifique 3 componentes principais (API, App Cliente, App Entregador). 2. Defina uma interface de comunicação (ex: INotifyOrder). 3. Desenhe o relacionamento de dependência entre eles.

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Laboratório de Requisitos ➡️

Aula 13 - Diagrama de Implantação 🌐

Módulo

MÓDULO 4 – DIAGRAMAS AVANÇADOS E ARQUITETURA

1. Visão de Implantação 📚

O Diagrama de Implantação (Deployment Diagram) descreve a arquitetura física do sistema, mostrando como os artefatos de software são distribuídos nos nós de hardware.

🧠 Elementos Principais

Nó (Node)

Representa um recurso computacional físico ou virtual (Servidor, PC, Smartphone, Nuvem). Notação: Um cubo 🧊.

Artefato (Artifact)

O arquivo físico que resulta do desenvolvimento (JAR, DLL, EXE, Docker Image). Notação: Retângulo com o estereótipo <<artifact>>.

2. Modelagem de Arquitetura 📊

Diferente do diagrama de componentes (que é lógico), o de implantação é sobre infraestrutura.

graph TD
    subgraph "Servidor Cloud [AWS]"
        Docker[<<artifact>> backend.jar]
        DB[<<artifact>> postgres_db]
    end

    subgraph "Desktop Cliente"
        Browser[<<nó>> Web Browser]
    end

    Browser -- "HTTPS / TCP-IP" --> Docker
    Docker -- "JDBC" --> DB

3. Dispositivos e Execução 💻

A UML permite detalhar o ambiente de execução dentro de um nó.

# Verificando o ambiente de implantação (Nó)docker inspect uml-backend-container{
"Node": "Worker-01",
"Artifact": "api-v1.0.jar",
"Network": "Bridge-External"
}
[SUCCESS] Artefato implantado com sucesso no nó.

4. Distribuição Física 📑

Elemento Tipo Exemplo Real
Device Hardware Físico Servidor Dell, Roteador, Mobile
Execution Environment Software de Sistema JVM, Docker, Servidor Web (Nginx)
Communication Path Conexão HTTP, Bluetooth, Fibra Ótica

Dica de Arquiteto

Use este diagrama para planejar a escalabilidade e identificar gargalos de rede entre os computadores do sistema.

5. Mini-Projeto Prático 🚀

Cenário: Arquitetura Cliente-Servidor de um Sistema Bancário.

Desafio: 1. Identifique 3 nós: Smartphone, Servidor de API, Servidor de Banco de Dados. 2. Defina os protocolos de comunicação entre eles (ex: REST/JSON, SQL). 3. Especifique em qual nó ficaria o artefato auth-module.bin.

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Integração dos Diagramas ➡️

Aula 14 - Integração dos Diagramas 🔗

Módulo

MÓDULO 4 – DIAGRAMAS AVANÇADOS E ARQUITETURA

1. Rastreabilidade e Coerência 📚

A modelagem UML só é eficaz quando os diagramas são consistentes entre si. A Integração garante que um método no Diagrama de Sequência realmente exista no Diagrama de Classes.

🧠 Pilares da Integração

Rastreabilidade

Capacidade de seguir a evolução de um requisito desde o Caso de Uso até a Implantação.

Consistência Horizontal

Garantir que diagramas do mesmo nível (ex: Sequência e Comunicação) contem a mesma história.

2. A Teia da UML 📊

Os diagramas não são ilhas isoladas; eles se alimentam mutuamente.

graph TD
    UC[Caso de Uso] -- "Define Escopo" --> CD[Diagrama de Classes]
    CD -- "Define Estrutura" --> SD[Diagrama de Sequência]
    SD -- "Define Lógica" --> AD[Diagrama de Atividades]
    AD -- "Define Fluxo" --> COMP[Diagrama de Componentes]
    COMP -- "Define Pacotes" --> UC

3. Auditoria de Modelagem via CLI 💻

Analistas Sêniores usam scripts para verificar se os nomes das classes batem com a modelagem.

# Verificando integridade entre modelo e códigomodel-checker lint --src ./src --diagrams ./docs/uml[INFO] Verificando Classe: Usuario... OK
[WARNING] Método 'validarSenha' no Seq não encontrado em Classes.md
[ERROR] Objeto 'Carrinho' sem correspondência no UseCase.md
[FAIL] Modelagem inconsistente detectada.

4. Matriz de Rastreabilidade 📑

Requisito (RF) Caso de Uso Classe Principal Diagrama de Dinâmica
RF01: Login Manter Usuário Autenticador Seq_Login_01
RF02: Checkout Finalizar Venda Pedido Ativ_Checkout_Flow
RF03: Estoque Baixar Produto Estoque State_Item_Vendido

Dica de Auditoria

Antes de começar a programar, faça o "teste da caneta": tente seguir o fluxo de um requisito passando por todos os diagramas. Se a "caneta" travar, falta uma conexão.

5. Mini-Projeto Prático 🚀

Cenário: Revisão Geral do Sistema NexusCart.

Desafio: 1. Escolha uma funcionalidade: "Adicionar Produto ao Carrinho". 2. Verifique se o ator do Caso de Uso é o mesmo que inicia a Sequência. 3. Garanta que a Classe Carrinho tenha o método adicionarItem(). 4. Documente uma inconsistência encontrada e como corrigi-la.

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Workshop Prático ➡️

Aula 15 - Desenvolvimento do Projeto Final 🚀

Módulo

MÓDULO 5 – PROJETO FINAL E AVALIAÇÃO

1. Da Teoria à Prática 📚

Chegou o momento de consolidar todo o conhecimento em um projeto completo. O Projeto Final desafia você a aplicar a modelagem UML de ponta a ponta, desde a descoberta até o design arquitetural.

🧠 Checklist de Excelência

Modelagem Estrutural

Garantir que os Diagramas de Casos de Uso e Classes reflitam fielmente o escopo e as regras de negócio.

Modelagem Comportamental

Demonstrar a dinâmica do sistema através de Diagramas de Sequência e Atividades para as funcionalidades críticas.

2. Roadmap do Projeto 📊

Siga as etapas para garantir uma entrega de alta qualidade.

timeline
    title Etapas do Projeto Final
    Semana 1 : Definição de Escopo : Casos de Uso
    Semana 2 : Modelo Estático : Diagrama de Classes : Dicionário de Dados
    Semana 3 : Modelo Dinâmico : Sequência : Atividades
    Semana 4 : Refinamento : Documentação : Preparação da Apresentação

3. Gestão de Versões do Projeto via CLI 💻

Mantenha seu projeto organizado usando ferramentas de controle de versão.

# Finalizando documentação técnicagit add docs/projeto/git commit -m "feat: Adicionado diagrama de arquitetura final"git tag -a v1.0.0 -m "Versão Final do Projeto"[SUCCESS] Projeto marcado como concluído para avaliação.

4. Critérios de Avaliação Técnicos 📑

Critério Peso O que será avaliado?
Consistência 30% Os diagramas "conversam" entre si?
Notação UML 20% Uso correto de símbolos, flechas e visibilidade.
Complexidade 20% O sistema resolve um problema real?
Documentação 30% Clareza das especificações e mini-projetos.

Atenção

Não se esqueça das Regras de Negócio. Um diagrama bonito sem lógica de negócio correta é apenas um desenho.

5. Mini-Projeto Prático (Sprint Final) 🚀

Cenário: Revisão por Pares (Peer Review).

Desafio: 1. Troque seu Diagrama de Classes com um colega. 2. Identifique 2 possíveis "Bugs de Modelagem" (ex: herança mal aplicada, falta de multiplicidade). 3. Sugira uma melhoria arquitetural (ex: uso de uma interface).

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Próxima Aula: Apresentação e Avaliação ➡️

Aula 16 - Apresentação e Avaliação 🏆

Módulo

MÓDULO 5 – PROJETO FINAL E AVALIAÇÃO

1. O Momento da Entrega 📚

A Apresentação e Avaliação não é apenas o fim, mas a celebração do processo de modelagem. É aqui que você demonstra sua capacidade de traduzir problemas complexos em diagramas claros e acionáveis.

🧠 Checklist de Apresentação

Poder de Síntese

Conseguir explicar a arquitetura do sistema em menos de 5 minutos, focando nos pontos mais críticos.

Postura Profissional

Responder a questionamentos técnicos sobre escolhas de relacionamentos (ex: por que Agregação e não Composição?).

2. Processo de Feedback 360º 📊

A avaliação é uma oportunidade de aprendizado contínuo.

graph TD
    A[Apresentação] --> B[Arguição Técnica]
    B --> C[Feedback Pares]
    C --> D[Avaliação Mentor]
    D --> E([Certificação])

    style E fill:#f3e5f5,stroke:#9c27b0

3. Empacotamento Final via CLI 💻

Antes de exportar seu projeto, certifique-se de que tudo está em ordem.

# Gerando PDF final da documentação UMLdocumentation-gen build --output "Projeto_Final_Analista.pdf"[EXPORT] Convertendo docs/ para PDF...
[SUCCESS] Documentação gerada com sucesso.sha256sum Projeto_Final_Analista.pdf5f98... Final Hash for submission

4. O Caminho do Analista Sênior 📑

Nível Competência Atitude
Junior Faz o diagrama correto Segue regras
Pleno Resolve problemas de design Questiona requisitos
Sênior Desenha arquiteturas escaláveis Foca no valor de negócio
Lead Mentora outros analistas Define padrões

Parabéns!

Você concluiu a jornada de Modelagem UML. Agora você possui as ferramentas para projetar sistemas robustos e profissionais.

5. Mini-Projeto Prático (Auto-Avaliação) 🚀

Cenário: Reflexão sobre o aprendizado.

Desafio: 1. Qual foi o diagrama mais difícil de aprender e por quê? 2. Se você pudesse refazer a Aula 01, o que faria de diferente hoje? 3. Defina seu próximo objetivo de estudo (ex: Padrões de Projeto - GoF).

🎯 Materiais e Prática

  • Slides Interativos --- Acesse a apresentação visual da aula. Ver Slides

  • Testar Conhecimento --- Responda ao Quiz da aula para fixar os conceitos. Responder Quiz

  • Exercícios Progressivos --- Pratique com 5 exercícios de fixação e desafio. Praticar

  • Mini-Projeto --- Aplique a análise no seu projeto de referência. Ver Projeto

Concluir Curso: Voltar ao Início 🏠

Exercícios

Exercícios Práticos

Mantenha a prática constante para dominar a modelagem UML. Cada lista contém 5 exercícios (Básico, Intermediário e Desafio) com links para soluções detalhadas.

Módulo 1 – Fundamentos e Requisitos

Módulo 2 – Especificação e Estrutura

Módulo 3 – Modelagem Comportamental

Módulo 4 – Arquitetura e Integração Final

Exercícios: Aula 01 - Introdução à Análise e Projeto de Sistemas 📝

Resolver estes exercícios ajudará na fixação dos conceitos fundamentais de APS e Ciclo de Vida de Software.

1. O Papel do Analista (Básico 1)

Contexto: No desenvolvimento de software, o analista atua como o tradutor entre o mundo dos negócios e o mundo técnico.

Pergunta: Defina o conceito de Análise e Projeto de Sistemas e cite duas vantagens de se investir tempo nesta fase antes de iniciar a codificação.

2. Cascatas vs. Sprints (Básico 2)

Contexto: Existem diferentes formas de organizar o trabalho (Modelos de Processo).

Pergunta: Diferencie brevemente o modelo Cascata (Waterfall) do modelo Ágil. Qual deles você escolheria para um projeto de uma Startup? Justifique.

3. A Importância da Abstração (Intermediário 1)

Contexto: Modelar não é desenhar, é abstrair a realidade para representá-la em um sistema.

Pergunta: Como a falta de uma fase de análise pode impactar o custo de manutenção de um sistema após 1 ano de uso?

4. Fluxo de Trabalho (Intermediário 2)

Contexto: O processo de software envolve várias etapas ligadas entre si.

Pergunta: Crie um esboço em texto (ou Mermaid) que represente o fluxo de informação desde o Levantamento de Requisitos até a Entrega do Produto.

5. Desafio: O Abismo de Comunicação (Desafio)

Contexto: Um cliente pede um "sistema de busca de produtos", mas o que ele realmente precisa é de um "recomendador de ofertas".

Pergunta: Como o uso de ferramentas de modelagem (UML, Protótipos) pode ajudar o analista a evitar que o desenvolvedor construa algo que o cliente não quer? Proponha uma estratégia prática.

Ver Solução e Explicação Detalhada

Exercícios: Aula 02 - Fundamentos da UML 📝

Estes exercícios focam na estrutura da linguagem UML e seu papel na modelagem profissional.

1. A Linguagem Franca do Software (Básico 1)

Contexto: UML não é um processo, mas sim uma linguagem.

Pergunta: Explique por que a UML é considerada a "Linguagem Universal" do desenvolvimento de software e cite dois diagramas que pertencem à categoria de Estrutura.

2. Ser ou Fazer (Básico 2)

Contexto: A UML divide os diagramas em duas grandes famílias: Estruturais e Comportamentais.

Pergunta: Qual a principal diferença entre um diagrama de Estrutura e um de Comportamento? Dê um exemplo de cada.

3. A Visão do Arquiteto (Intermediário 1)

Contexto: O modelo 4+1 de Kruchten organiza o caos da modelagem.

Pergunta: De forma resumida, o que o "1" (Cenários) representa nesse modelo e por que ele é o elo de ligação entre as outras visões?

4. Sintaxe Visual (Intermediário 2)

Contexto: Cada símbolo na UML tem um significado específico (Actor, Use Case, Class).

Pergunta: Imagine uma relação entre "Professor" e "Disciplina". Como você representaria essa associação estática em um rascunho de diagrama?

5. Desafio: O Equilíbrio da Modelagem (Desafio)

Contexto: No passado, alguns times tentavam modelar 100% do sistema antes de codar. Hoje, o foco é o "Pragmatismo".

Pergunta: Em que situações você recomendaria o uso extensivo de UML e em quais situações você usaria apenas rascunhos rápidos (UML as Sketch)? Justifique sua decisão como futuro analista.

Ver Solução e Explicação Detalhada

Exercícios: Aula 03 - Processo Unificado e Ágil 📝

Aprofunde seus conhecimentos sobre como a modelagem se encaixa em diferentes fluxos de trabalho.

1. A Estrutura do RUP (Básico 1)

Contexto: O Processo Unificado (RUP) é dividido em quatro fases fundamentais.

Pergunta: Liste as 4 fases do RUP e identifique em qual delas a arquitetura do sistema é definida e os riscos técnicos são mitigados.

2. Modelagem Ágil (Básico 2)

Contexto: Metodologias ágeis (como Scrum) priorizam software em funcionamento sobre documentação abrangente.

Pergunta: Isso significa que não usamos UML em projetos Ágeis? Justifique sua resposta baseada no manifesto ágil.

3. O Conceito de Iteração (Intermediário 1)

Contexto: Tanto o RUP quanto as metodologias Ágeis usam o conceito de iterações.

Pergunta: Explique a vantagem de entregar partes do sistema a cada 2 ou 4 semanas em vez de entregar tudo apenas no final do projeto (modelo Cascata).

4. UML as Code vs UML as Sketch (Intermediário 2)

Contexto: Existem diferentes "níveis" de uso da UML.

Pergunta: Defina o que é "UML como Esboço (Sketch)" e como ela se aplica em reuniões de Sprint Planning.

5. Desafio: Adaptando o Processo (Desafio)

Contexto: Você foi contratado para um projeto de um Sistema de Controle de Tráfego Aéreo. O time quer usar Scrum puro, sem documentação formal.

Pergunta: Sendo um sistema crítico (onde vidas estão em jogo), você concorda com a ausência de diagramas formais de arquitetura? Como você equilibraria a agilidade com a necessidade de rigor técnico?

Ver Solução e Explicação Detalhada

Exercícios: Aula 04 - Engenharia de Requisitos 📝

Pratique a arte de descobrir e documentar o que o cliente realmente precisa.

1. O que o Sistema Deve Ser (Básico 1)

Contexto: Requisitos são a fundação de qualquer software de sucesso.

Pergunta: Diferencie Requisitos Funcionais de Requisitos Não-Funcionais. Dê um exemplo de cada para um aplicativo de banco.

2. Técnicas de Descoberta (Básico 2)

Contexto: O cliente nem sempre sabe explicar o que quer (Elicitação).

Pergunta: Cite três técnicas usadas pelo analista para coletar requisitos com os Stakeholders.

3. Rastreabilidade (Intermediário 1)

Contexto: No meio do projeto, o desenvolvedor decide adicionar uma funcionalidade que o cliente não pediu.

Pergunta: Como o conceito de Matriz de Rastreabilidade ajuda a evitar o desperdício de tempo com funcionalidades desnecessárias?

4. Documento de Visão (Intermediário 2)

Contexto: Antes de desenhar diagramas complexos, precisamos de uma visão clara do produto.

Pergunta: Qual o principal objetivo do Documento de Visão e quem é o público-alvo deste documento?

5. Desafio: Gerenciando Mudanças (Desafio)

Contexto: O projeto já está na metade e o cliente mudou uma regra de negócio crítica que afeta 50% dos diagramas já feitos.

Pergunta: Sendo um analista ágil, qual deve ser sua atitude diante dessa mudança? Como você avaliaria o impacto dessa alteração no projeto?

Ver Solução e Explicação Detalhada

Exercícios: Aula 05 - Especificação de Casos de Uso 📝

Descubra como documentar a interação entre o usuário e o sistema com precisão.

1. Atores de Sistema (Básico 1)

Contexto: Um ator representa um papel, não necessariamente uma pessoa física.

Pergunta: Um banco de dados externo ou um sistema de gateway de pagamento pode ser considerado um Ator em um Diagrama de Casos de Uso? Justifique.

2. O Caminho Feliz (Básico 2)

Contexto: Todo Caso de Uso possui fluxos de execução.

Pergunta: O que caracteriza o Cenário Principal (ou Fluxo Principal) de um Caso de Uso?

3. Gestão de Erros (Intermediário 1)

Contexto: O sistema deve saber o que fazer quando algo sai do planejado (Exceções).

Pergunta: No contexto de uma especificação de Caso de Uso, qual a diferença entre um Fluxo Alternativo e um Fluxo de Exceção?

4. Condicionantes (Intermediário 2)

Contexto: Casos de Uso não acontecem no vácuo; eles têm estados anteriores e posteriores.

Pergunta: Explique a importância de definir as Pós-condições em uma especificação de Caso de Uso. O que acontece se elas não forem atendidas?

5. Desafio: Include vs Extend (Desafio)

Contexto: Muitos analistas iniciantes confundem essas duas relações.

Pergunta: Uma funcionalidade de "Validar Token de Segurança" seria melhor representada como um <<include>> ou um <<extend>> em relação ao Caso de Uso "Realizar Transferência"? Justifique sua escolha técnica.

Ver Solução e Explicação Detalhada

Exercícios: Aula 06 - Diagramas de Classe I 📝

O Diagrama de Classes é a espinha dorsal da modelagem estática. Pratique os fundamentos aqui.

1. Anatomia da Classe (Básico 1)

Contexto: Uma classe é composta por três compartimentos principais na representação UML.

Pergunta: Quais são esses três compartimentos e qual a função de cada um deles na modelagem?

2. Segredos bem guardados (Básico 2)

Contexto: Visibilidade é fundamental para o encapsulamento em Orientação a Objetos.

Pergunta: O que significam os símbolos (+) e (-) antes de um atributo ou método? Por que não devemos deixar todos os atributos como públicos?

3. Comportamento vs Estado (Intermediário 1)

Contexto: Classes representam tipos de objetos.

Pergunta: Identifique, em uma classe Carro, dois itens que seriam Atributos e dois que seriam Métodos (Ações).

4. Conectando Objetos (Intermediário 2)

Contexto: Objetos raramente vivem sozinhos; eles se associam.

Pergunta: O que representa uma linha sólida entre duas classes em um diagrama UML? Dê um exemplo real de associação.

5. Desafio: Refatoração de Modelo (Desafio)

Contexto: Você tem uma classe Funcionario com atributos: nome, cpf, rua, numero, cep, cidade.

Pergunta: Como você aplicaria o conceito de Composição para melhorar esse design, separando os dados de endereço em uma classe própria? Desenhe a lógica (ou explique em texto).

Ver Solução e Explicação Detalhada

Exercícios: Aula 07 - Diagramas de Classe II 📝

Domine as relações avançadas e a hierarquia entre objetos.

1. Todo e Parte (Básico 1)

Contexto: Agregação e Composição são formas especiais de associação.

Pergunta: Qual a principal diferença "existencial" entre uma Agregação e uma Composição? (Dica: Pense no tempo de vida dos objetos).

2. Herança e Generalização (Básico 2)

Contexto: A relação de herança permite reutilizar atributos e métodos.

Pergunta: Explique o conceito de Generalização. Use o exemplo de "Veículo", "Carro" e "Moto" para sua explicação.

3. Quantos são? (Intermediário 1)

Contexto: A multiplicidade define quantos objetos participam de uma relação.

Pergunta: O que significam as notações 1..* e 0..1 em uma extremidade de associação?

4. Classes de Abstração (Intermediário 2)

Contexto: Nem toda classe serve para gerar objetos (instâncias).

Pergunta: O que é uma Classe Abstrata e qual a sua utilidade em um projeto de arquitetura de software?

5. Desafio: Modelagem de Domínio Acadêmico (Desafio)

Contexto: Em uma universidade, um Curso é composto por várias Disciplinas. Se o curso for extinto, as disciplinas deixam de existir naquele contexto de grade curricular.

Pergunta: Qual relação UML melhor representa esse cenário? Agregação, Composição ou Herança? Justifique sua resposta desenhando a lógica dessa relação.

Ver Solução e Explicação Detalhada

Exercícios: Aula 08 - Diagrama de Sequência 📝

Visualize a troca de mensagens entre objetos ao longo do tempo.

1. A Dimensão do Tempo (Básico 1)

Contexto: Ao contrário do Diagrama de Classes, o de Sequência é dinâmico.

Pergunta: O que a dimensão vertical e a dimensão horizontal representam em um Diagrama de Sequência?

2. Existência de Objetos (Básico 2)

Contexto: Cada objeto no diagrama tem uma representação visual de sua duração.

Pergunta: O que é uma Linha de Vida (Lifeline) e o que indica o pequeno retângulo vertical (barra de ativação) sobre ela?

3. Esperar ou não esperar? (Intermediário 1)

Contexto: Diferentes tipos de setas indicam diferentes tipos de comunicação.

Pergunta: Qual a diferença visual e conceitual entre uma Mensagem Síncrona e uma Mensagem Assíncrona?

4. Lógicas de Fluxo (Intermediário 2)

Contexto: Às vezes precisamos representar "se" ou "enquanto" no diagrama.

Pergunta: Para que servem os fragmentos combinados alt e loop em um Diagrama de Sequência?

5. Desafio: Modelando o Mundo Real (Desafio)

Contexto: Um usuário tenta sacar dinheiro em um caixa eletrônico. O sistema precisa validar a senha e verificar o saldo antes de entregar as notas.

Pergunta: Identifique os 3 participantes principais e liste a sequência de 5 mensagens necessárias para completar esse processo com segurança.

Ver Solução e Explicação Detalhada

Exercícios: Aula 09 - Diagrama de Comunicação 📝

Entenda como os objetos se organizam estruturalmente para realizar uma tarefa.

1. Irmãos de Sangue (Básico 1)

Contexto: O Diagrama de Comunicação é o "primo" do de Sequência, ambos são Diagramas de Interação.

Pergunta: Qual a principal diferença de foco entre o Diagrama de Sequência e o Diagrama de Comunicação?

2. A Ordem das Coisas (Básico 2)

Contexto: No Diagrama de Comunicação, os objetos não estão organizados de cima para baixo.

Pergunta: Como sabemos qual mensagem acontece primeiro no Diagrama de Comunicação?

3. Caminhos Lógicos (Intermediário 1)

Contexto: Para que duas instâncias troquem mensagens, elas precisam estar ligadas.

Pergunta: O que é um Link em um Diagrama de Comunicação e como ele se diferencia de uma Associação comum?

4. Espaço e Estrutura (Intermediário 2)

Contexto: Cada diagrama brilha em um cenário diferente.

Pergunta: Em que situação prática um analista preferiria usar um Diagrama de Comunicação em vez de um de Sequência?

5. Desafio: Tradução de Modelos (Desafio)

Contexto: Você recebeu um Diagrama de Sequência e precisa convertê-lo para Comunicação para uma reunião de arquitetura.

Pergunta: Qual o maior desafio técnico ao fazer essa conversão manualmente e como você representaria uma mensagem de "retorno" no diagrama de comunicação?

Ver Solução e Explicação Detalhada

Exercícios: Aula 10 - Diagrama de Atividades 📝

Modele o fluxo de trabalho e a lógica de processos de negócio.

1. Fluxogramas com Superpoderes (Básico 1)

Contexto: O Diagrama de Atividades é frequentemente comparado ao fluxograma tradicional.

Pergunta: Liste duas funcionalidades que o Diagrama de Atividades possui e que o fluxograma comum não consegue representar bem.

2. Decisões e Uniões (Básico 2)

Contexto: O fluxo de uma atividade pode seguir caminhos diferentes conforme o cenário.

Pergunta: Qual o símbolo usado para um Nó de Decisão (if) e qual sua contraparte (Merge)?

3. Paralelismo (Intermediário 1)

Contexto: Sistemas modernos executam várias tarefas ao mesmo tempo.

Pergunta: Explique a função das barras pretas (Fork e Join) na modelagem de processos paralelos.

4. Zonas de Responsabilidade (Intermediário 2)

Contexto: Processos de checkout envolvem Cliente, Logística e Financeiro.

Pergunta: O que são Swimlanes (Raias) e como elas ajudam na identificação de gargalos de um processo?

5. Desafio: Modelagem de Fluxo Complexo (Desafio)

Contexto: Um processo de "Publicação de Post" requer: escrita -> revisão -> aprovado? (sim: publicar e notificar | não: voltar para escrita).

Pergunta: Desenhe a lógica (em Mermaid ou lista de passos) desse processo, garantindo que a publicação e a notificação ocorram de forma paralela usando Fork/Join.

Ver Solução e Explicação Detalhada

Exercícios: Aula 11 - Diagrama de Estados 📝

Entenda as mudanças de comportamento de um objeto conforme o tempo passa.

1. O que é um Estado? (Básico 1)

Contexto: Nem tudo no sistema precisa de um diagrama de estados, apenas objetos com ciclos de vida complexos.

Pergunta: Defina o conceito de Estado para um objeto e dê um exemplo de três estados de um "Pedido de Venda".

2. Causas de Mudança (Básico 2)

Contexto: Objetos não mudam de estado sozinhos; algo deve acontecer.

Pergunta: Qual a diferença entre uma Transição e um Evento?

3. Condições de Guarda (Intermediário 1)

Contexto: Às vezes a transição só pode ocorrer se uma regra for atendida.

Pergunta: O que é uma Guard Condition e como ela é representada visualmente na UML?

4. Pseudo-estados (Intermediário 2)

Contexto: Existem símbolos que não são estados reais, mas ajudam na lógica.

Pergunta: Identifique o símbolo de Início, Fim e do Histórico no Diagrama de Estados. Para que serve o histórico?

5. Desafio: Modelando o Ciclo de Vida (Desafio)

Contexto: Um sensor de temperatura está em estado "Inativo". Ao ser ligado (liga()), ele entra em "Monitorando". Se a temperatura atingir 100ºC, ele passa para "Alerta". Se for desligado (desliga()), volta para "Inativo" a partir de qualquer estado.

Pergunta: Desenhe esse diagrama de estados simplificado, identificando onde as condições de guarda seriam necessárias.

Ver Solução e Explicação Detalhada

Exercícios: Aula 12 - Diagrama de Componentes 📝

Entenda como o software é organizado fisicamente e como seus módulos se conectam.

1. Unidades de Software (Básico 1)

Contexto: Ao contrário das classes, que são lógicas, os componentes são físicos.

Pergunta: O que pode ser considerado um Componente no mundo real do desenvolvimento? Dê dois exemplos práticos.

2. Plug and Play (Básico 2)

Contexto: Componentes usam interfaces para se comunicar sem conhecer a implementação interna um do outro.

Pergunta: Explique a diferença visual e funcional entre uma Interface Fornecida (lollipop) e uma Interface Requerida (socket) na UML.

3. Dependências Físicas (Intermediário 1)

Contexto: Componentes raramente funcionam isolados.

Pergunta: Se o Componente A depende de uma interface que o Componente B fornece, mas o Componente B é substituído por uma nova versão, o que deve acontecer com o Componente A?

4. Mapa da Arquitetura (Intermediário 2)

Contexto: O Diagrama de Componentes é vital para o time de DevOps e Infraestrutura.

Pergunta: Como este diagrama ajuda o analista a decidir quais partes do sistema podem se tornar Microserviços independentes?

5. Desafio: Modelagem de Integração (Desafio)

Contexto: Um sistema de e-commerce possui um componente de Checkout que precisa se comunicar com um Gateway de Pagamento de terceiros através de uma API REST.

Pergunta: Como você representaria essa dependência externa em um Diagrama de Componentes? Use o conceito de interfaces para garantir que o sistema possa trocar de Gateway (ex: PayPal para Stripe) no futuro.

Ver Solução e Explicação Detalhada

Exercícios: Aula 13 - Diagrama de Implantação 📝

Teste seus conhecimentos sobre a arquitetura física e a distribuição de artefatos de software em hardware.

1. A Natureza do Nó (Básico 1)

Contexto: Na UML, um nó é a unidade básica de hardware ou ambiente de execução.

Pergunta: Qual a diferença entre um Nó de Dispositivo (Device) e um Ambiente de Execução (Execution Environment)? Dê um exemplo de cada.

2. O Papel do Artefato (Básico 2)

Contexto: O diagrama de implantação mostra onde os arquivos resultantes do build são colocados.

Pergunta: O que é um Artefato na UML e como ele se relaciona com uma classe ou componente lógico?

3. Topologia de Rede (Intermediário 1)

Contexto: Sistemas modernos raramente rodam em uma única máquina.

Pergunta: Como representamos a conexão física entre dois servidores em um Diagrama de Implantação e quais informações devem constar nessa conexão (Caminho de Comunicação)?

4. Modelagem de Nuvem (Intermediário 2)

Contexto: Hoje em dia, muitos sistemas usam arquitetura em nuvem (AWS, Azure, Google Cloud).

Pergunta: Como você representaria um cluster de servidores (múltiplas instâncias do mesmo serviço) utilizando a notação de nós da UML?

5. Desafio: Segurança e Latência (Desafio)

Contexto: Um banco de dados sensível deve ficar em uma rede interna, enquanto o servidor web fica na rede pública.

Pergunta: Desenhe (em texto ou descreva os elementos) um Diagrama de Implantação que mostre um Firewall como um nó intermediário entre o Cliente (Browser) e o Servidor de Banco de Dados. Quais protocolos de comunicação seriam usados nas duas pontas?

Ver Solução e Explicação Detalhada

Exercícios: Aula 14 - Integração dos Diagramas 📝

Aperfeiçoe sua capacidade de manter a coerência e rastreabilidade entre os diferentes modelos da UML.

1. O Conceito de Rastreabilidade (Básico 1)

Contexto: Um projeto UML profissional exige que os requisitos possam ser seguidos do início ao fim.

Pergunta: O que é Rastreabilidade Vertical e como ela conecta um Caso de Uso ao Diagrama de Classes?

2. Detecção de Inconsistências (Básico 2)

Contexto: É comum encontrar nomes de métodos diferentes no Diagrama de Sequência e no Diagrama de Classes.

Pergunta: Por que essa inconsistência é perigosa para a equipe de desenvolvimento e qual a regra de ouro para nomear elementos em diagramas diferentes?

3. A Matriz de Rastreabilidade (Intermediário 1)

Contexto: Gerentes de projeto usam matrizes para garantir a cobertura dos requisitos.

Pergunta: Quais são as colunas fundamentais de uma Matriz de Rastreabilidade e como ela prova que um requisito funcional foi totalmente modelado?

4. Verificação Cruzada (Intermediário 2)

Contexto: Ao revisar um Diagrama de Atividades, você nota uma decisão que não está prevista no Diagrama de Estados do objeto principal.

Pergunta: Como você resolveria esse conflito e qual diagrama deve ser considerado a "fonte da verdade" para o comportamento do objeto?

5. Desafio: Auditoria de Modelo (Desafio)

Contexto: Você recebeu uma modelagem onde o ator "Cliente" apaga um registro no Caso de Uso, mas o Diagrama de Sequência mostra o ator "Administrador" executando essa tarefa.

Pergunta: Identifique o erro de integridade nessa situação e descreva os passos que você tomaria para auditar o restante da documentação em busca de falhas similares.

Ver Solução e Explicação Detalhada

Exercícios: Aula 15 - Desenvolvimento do Projeto Final 📝

Aplique todo o arsenal da UML para construir uma arquitetura de software sólida.

1. O Desafio Final (Básico 1)

Contexto: O projeto final é a síntese de todo o curso.

Pergunta: Qual a importância de se ter um Documento de Requisitos bem definido antes de começar a desenhar os diagramas de Classe e Sequência do Projeto Final?

2. Foco no Core (Básico 2)

Contexto: Projetos grandes demais tendem a falhar por falta de tempo.

Pergunta: Como você aplicaria o conceito de MVP (Mínimo Produto Viável) na escolha das funcionalidades que serão modeladas no seu projeto final?

3. Consistência entre Modelos (Intermediário 1)

Contexto: UML é um conjunto integrado de visões.

Pergunta: Como você garante que um método de classe disparado em um Diagrama de Sequência realmente exista no seu Diagrama de Classes?

4. Ferramentas de Autoria (Intermediário 2)

Contexto: Existem ferramentas CASE e ferramentas de "texto para diagrama" (como Mermaid).

Pergunta: Cite uma vantagem e uma desvantagem de usar Mermaid.js para documentar o seu projeto final em vez de uma ferramenta visual pesada como o IBM RSA ou Enterprise Architect.

5. Desafio: Planejamento de Roadmap (Desafio)

Contexto: Você tem 1 semana para entregar a modelagem completa de um "Sistema de Agendamento de Consultas".

Pergunta: Crie um cronograma lógico de quais diagramas você faria primeiro e por quê. O que acontece se você deixar o Diagrama de Classes por último?

Ver Solução e Explicação Detalhada

Exercícios: Aula 16 - Apresentação e Avaliação 📝

Prepare-se para defender sua arquitetura e aprender com o feedback.

1. Defesa de Projeto (Básico 1)

Contexto: Um analista deve saber explicar suas escolhas técnicas.

Pergunta: Por que a fase de apresentação é considerada tão importante quanto a fase de desenho dos diagramas na vida real de um escritório de projetos?

2. O Olhar do Outro (Básico 2)

Contexto: A avaliação por pares (Peer Review) é uma prática comum de qualidade.

Pergunta: Como o feedback de outros alunos pode ajudar a melhorar a qualidade técnica dos seus diagramas UML?

3. Auto-crítica (Intermediário 1)

Contexto: Nenhum modelo é perfeito de primeira.

Pergunta: Ao rever o seu projeto final, qual diagrama você considera o mais difícil de manter atualizado e por quê?

4. Do Modelo ao Código (Intermediário 2)

Contexto: UML serve para guiar a construção.

Pergunta: Se um desenvolvedor pegar sua documentação hoje, qual o item (diagrama ou descrição) que você acredita ser o mais crucial para que ele não cometa erros de implementação?

5. Desafio: Simulação de Consultoria (Desafio)

Contexto: Durante sua apresentação, um "cliente" questiona por que você usou Composição em vez de Agregação em uma relação crítica de banco de dados.

Pergunta: Como você justificaria essa escolha tecnicamente, focando na integridade dos dados e no ciclo de vida dos objetos?

Ver Solução e Explicação Detalhada

Projetos

Projeto Integrador: NexusCart 🛒

O Projeto Integrador deste curso consiste no desenvolvimento da modelagem completa de uma plataforma de E-commerce Omnichannel chamada NexusCart.

Você evoluirá este projeto aula a aula, aplicando cada novo diagrama e técnica aprendida.

🚀 Fases do Projeto

Módulo 1: Fundamentos e Requisitos

Módulo 2: Estrutura e Dados

Módulo 3: Dinâmica e Comportamento

Módulo 4: Arquitetura e Lab

Módulo 5: Finalização

Conselho de Ouro

Salve todos os arquivos de modelagem em uma pasta organizada. Ao final do curso, você terá um portfólio completo de análise e projeto de sistemas!

Etapa 01: Visão Geral do Sistema 🚀

Bem-vindo ao início do seu projeto prático! Nesta primeira fase, vamos definir o "Norte" do sistema NexusCart.

📋 Descrição do Desafio

O NexusCart será uma plataforma que permite a lojistas venderem produtos tanto online quanto em tablets dentro de lojas físicas (Omnichannel).

Nesta etapa, você deve: 1. Definir o Contexto: Descrever em um parágrafo o problema que o NexusCart resolve. 2. Identificar Stakeholders: Quem são as pessoas interessadas no sucesso deste sistema? (Ex: Lojista, Cliente final, Administrador do sistema). 3. Desenhar o Diagrama de Contexto: Use um diagrama Mermaid simples para mostrar o sistema no centro e as entidades externas ao redor dele.

🛠 Ferramentas Recomendadas:

  • Mermaid Live Editor
  • VS Code com plug-in Markdown All in One
  • Bloco de Notas (para rascunhos de requisitos)

Entrega Parcial

Guarde este documento. Ele será a base para a Etapa 02, onde profundaremos nos Requisitos.

Etapa 02: Levantamento de Requisitos 📋

Com a visão geral definida, é hora de descobrir as regras do jogo para o NexusCart.

📋 Descrição do Desafio

O sucesso de um software depende de quão bem entendemos as necessidades do cliente.

Nesta etapa, você deve listar: 1. 5 Requisitos Funcionais (RF): Ações que o sistema deve executar (ex: "O sistema deve permitir o cadastro de produtos"). 2. 3 Requisitos Não-Funcionais (RNF): Qualidades do sistema (ex: "O sistema deve processar o pagamento em menos de 5 segundos"). 3. Técnica de Elicitação: Decida qual técnica você usaria para coletar esses requisitos com o dono da loja (Entrevista? Questionário? Observação?).

💡 Dica de Ouro

Use a numeração padrão: RF001, RF002, RNF001, etc. Isso facilita a rastreabilidade no futuro!

Atenção

Cuidado para não confundir Requisito com Tecnologia. "Usar React" não é um requisito funcional, é uma restrição tecnológica!

Etapa 03: Escolha do Modelo de Processo ⚙️

Como vamos organizar o trabalho para construir o NexusCart?

📋 Descrição do Desafio

A escolha do modelo de ciclo de vida dita a velocidade e a flexibilidade da equipe.

Nesta etapa, você deve: 1. Escolher o Processo: Você usaria RUP (mais formal) ou Scrum/Ágil (mais rápido)? 2. Justificativa: Explique por que sua escolha é a melhor para uma startup que está criando um e-commerce do zero. 3. Diagrama de Fluxo: Crie um diagrama Mermaid mostrando as fases do seu projeto (ex: Inception -> Elaboration... ou Sprints 1, 2, 3).

🎨 Visualização Mermaid:

graph LR
    A[Planejamento] --> B[Modelagem]
    B --> C[Implementação]
    C --> D[Testes]
    D --> B

Próximos Passos

Agora que sabemos como vamos trabalhar, na Etapa 04 começaremos a desenhar os primeiros diagramas UML!

Etapa 04: Atores e Casos de Uso 👤

É hora de desenhar! Vamos mostrar quem interage com o NexusCart e o que eles podem fazer.

📋 Descrição do Desafio

O Diagrama de Casos de Uso é o contrato funcional do sistema.

Nesta etapa, você deve: 1. Identificar os Atores: Quem são as entidades externas? (Dica: Lembre-se do sistema de pagamento). 2. Mapear 5 Casos de Uso Críticos: Como "Realizar Login", "Adicionar ao Carrinho", "Finalizar Pagamento". 3. Desenhar o Diagrama: Utilize a sintaxe Mermaid para Casos de Uso.

🎨 Exemplo Mermaid:

useCaseDiagram
    actor Cliente
    actor Vendedor
    package NexusCart {
        usecase "Realizar Compra" as UC1
        usecase "Cadastrar Produto" as UC2
    }
    Cliente --> UC1
    Vendedor --> UC2

Dica de Especialista

Não tente modelar tudo agora. Foque nos processos que trazem valor imediato para o negócio (o "Caminho Feliz").

Etapa 05: Especificação de Casos de Uso 📝

Mergulhe nos detalhes de como o NexusCart deve se comportar.

📋 Descrição do Desafio

Um diagrama sem descrição é apenas um desenho. Vamos detalhar um processo crítico.

Nesta etapa, você deve: 1. Escolher um Caso de Uso: Recomendado: "Realizar Compra" ou "Cadastrar Produto". 2. Escrever o Fluxo Principal: O passo a passo do sucesso. 3. Definir 2 Fluxos de Exceção: O que acontece se o cartão for negado ou o estoque acabar? 4. Pré e Pós-condições: O que deve ser verdade antes e depois do processo.

💡 Exemplo de Estrutura:

  • Nome: UC01 - Realizar Compra
  • Ator: Cliente
  • Pré-condição: Cliente logado e com itens no carrinho.
  • Fluxo Principal:
    1. Cliente clica em Finalizar.
    2. Sistema solicita endereço...
  • Pós-condição: Pedido gerado e estoque reservado.

Importante

Esta especificação será a base para o seu Diagrama de Sequência na Etapa 08!

Etapa 06: Atributos e Visibilidade 📦

Vamos começar a desenhar a estrutura interna de dados do NexusCart.

📋 Descrição do Desafio

O Diagrama de Classes define os "objetos" que o sistema vai gerenciar.

Nesta etapa, você deve: 1. Criar 3 Classes Principais: Produto, Cliente e Pedido. 2. Definir Atributos: Pelo menos 3 para cada classe (ex: preco, estoque, nome). 3. Aplicar Visibilidade: Use - para atributos privados e + para métodos públicos (Getters/Setters). 4. Identificar Métodos: O que esses objetos "fazem"? (ex: atualizarPreco(), calcularTotal()).

🎨 Exemplo Mermaid:

classDiagram
    class Produto {
        -String nome
        -float preco
        +atualizarEstoque(qtd)
    }

Dica de Ouro

Mantenha os atributos sempre privados (-). Isso é uma boa prática de encapsulamento que você aprendeu na aula!

Etapa 07: Relações e Multiplicidade 🔗

As classes do NexusCart não vivem isoladas. Vamos conectá-las!

📋 Descrição do Desafio

A força da Orientação a Objetos está em como os objetos se relacionam.

Nesta etapa, você deve: 1. Adicionar a Classe: ItemPedido (para representar os itens dentro de um carrinho). 2. Modelar Relações: * Composição: Entre Pedido e ItemPedido (um item não existe sem o pedido). * Associação: Entre ItemPedido e Produto. * Agregação: Entre Cliente e Pedido. 3. Definir Multiplicidade: (ex: 1 Cliente pode ter 0..* Pedidos).

🎨 Exemplo Mermaid:

classDiagram
    Pedido "1" *-- "1..*" ItemPedido
    ItemPedido "*" --> "1" Produto

Checkpoint

Com o Diagrama de Classes pronto, você já tem a "planta baixa" dos dados do seu sistema. Nas próximas etapas, vamos focar na dinâmica!

Etapa 08: Fluxos de Mensagens 🕒

Vamos ver como as mensagens "viajam" no tempo dentro do NexusCart.

📋 Descrição do Desafio

O Diagrama de Sequência é o favorito dos desenvolvedores para entender a lógica do código.

Nesta etapa, você deve: 1. Modelar o Processo: "Realizar Pagamento". 2. Identificar Instâncias: Cliente, Checkout, GatewayPagamento. 3. Desenhar as Mensagens: Síncronas (com retorno) e Assíncronas. 4. Adicionar Lógica: Use um bloco alt para lidar com "Pagamento Aprovado" vs "Recusado".

🎨 Exemplo Mermaid:

sequenceDiagram
    Cliente->>Checkout: finalizarCompra()
    Checkout->>Gateway: processar(cartao)
    alt Sucesso
        Gateway-->>Checkout: ok
        Checkout-->>Cliente: confirmar
    else Falha
        Gateway-->>Checkout: erro
        Checkout-->>Cliente: avisar
    end

Atenção

Certifique-se de que os nomes das mensagens coincidem com os métodos que você criou no Diagrama de Classes da Etapa 06!

Etapa 09: Organização de Instâncias 🤖

Como os objetos do NexusCart estão "pendurados" uns nos outros para realizar uma tarefa?

📋 Descrição do Desafio

O Diagrama de Comunicação (antigo Colaboração) foca na estrutura da rede de objetos.

Nesta etapa, você deve: 1. Desenhar os Nós: (ex: Loja, Estoque, Transportadora). 2. Ligar os Objetos: Mostre quem tem o "contato" de quem. 3. Numerar as Mensagens: Liste a ordem da comunicação (ex: 1: solicitarEnvio, 1.1: baixarEstoque, 2: emitirNF).

🎨 Dica de Notação:

Lembre-se que no Diagrama de Comunicação não temos a linha do tempo vertical. A numeração (1, 1.1, 2) é obrigatória para entendermos a ordem dos fatos!

Vantagem

Este diagrama é excelente para identificar se uma classe está sobrecarregada (muitas setas saindo ou chegando), o que pode indicar a necessidade de refatoração.

Etapa 10: Processos de Negócio 🔀

Vamos mapear o fluxo de "logística reversa" ou "devolução" do NexusCart.

📋 Descrição do Desafio

O Diagrama de Atividades é ideal para processos que envolvem decisões e tarefas paralelas.

Nesta etapa, você deve: 1. Usar Swimlanes (Raias): Divida o diagrama em Cliente, Atendimento e Estoque. 2. Modelar o Fluxo: Início -> Solicitar Devolução -> Validar Item -> Reembolsar. 3. Adicionar Paralelismo: Use um Fork para disparar o "Aviso de Estorno" e o "Ajuste de Saldo" simultaneamente. 4. Pontos de Decisão: O item está quebrado? (Sim/Não).

🎨 Exemplo Mermaid:

graph TD
    A[Início] --> B{Decisão}
    B -- Sim --> C[Atividade 1]
    B -- Não --> D[Atividade 2]

Dica

Imagine que você está desenhando um mapa para uma pessoa que nunca viu o processo antes. Seja claro nas condições de saída de cada nó de decisão!

Etapa 11: Ciclo de Vida do Pedido 💓

Um pedido no NexusCart muda muito de estado. Vamos controlar isso!

📋 Descrição do Desafio

O Diagrama de Estados evita bugs onde um pedido é "entregue" antes de ser "pago".

Nesta etapa, você deve: 1. Identificar Estados: Aguardando Pagamento, Em Separação, Enviado, Entregue, Cancelado. 2. Criar Transições: Quais eventos causam a mudança? (ex: confirmarPagamento()). 3. Adicionar Guards: Um pedido só vai para Enviado se houver [Nota Fiscal Gerada].

🎨 Exemplo Mermaid:

stateDiagram-v2
    [*] --> Pendente
    Pendente --> Pago : pagar()
    Pago --> Enviado : despachar() [possuNF]
    Enviado --> [*]

Checkpoint de Módulo

Parabéns! Você concluiu a modelagem comportamental. No próximo módulo, vamos focar na Arquitetura e modularização física do sistema!

Etapa 12: Modularização Física 📦

Como o código do NexusCart será organizado em arquivos e módulos?

📋 Descrição do Desafio

O Diagrama de Componentes ajuda a visualizar a estrutura física e as dependências entre bibliotecas e APIs.

Nesta etapa, você deve: 1. Identificar 3 Componentes: (ex: MobileApp, BackendAPI, Database). 2. Definir Interfaces: Use o símbolo de "Pirulito" (Lollipop) para mostrar o que cada componente oferece. 3. Traçar Dependências: Use setas tracejadas para mostrar quem depende de qual interface.

🎨 Exemplo Mermaid:

graph LR
    A[App Mobile] -- IAuth --> B[Serviço Autenticação]
    A -- IOrder --> C[Serviço Pedidos]

Visão Técnica

Pense nos componentes como "caixas pretas" que podem ser desenvolvidas por equipes diferentes simultaneamente!

Etapa 13: Workshop: Design Sprint 🎨

Mão na massa! Vamos validar uma ideia de nova funcionalidade para o NexusCart.

📋 Descrição do Desafio

O laboratório serve para testar hipóteses antes de gastar dias em diagramas formais.

Nesta etapa, você deve: 1. Escolher um Problema: Ex: "Como reduzir o abandono de carrinho?". 2. Executar o Crazy 8s: Desenhe 8 rascunhos rápidos de soluções (pode descrever em texto cada rascunho). 3. Criar o Storyboard: Desenhe (ou descreva) uma sequência de 6 quadros mostrando o usuário resolvendo o problema usando sua solução.

💡 Dica de Lab

Não se preocupe com a beleza dos desenhos no storyboard. O importante é a clareza da solução proposta!

Aplicação UML

Qual diagrama UML você acha que melhor documentaria o Storyboard que você criou? (Justifique).

Etapa 14: Workshop: Comunicação Ágil 🗣️

Como explicar a arquitetura do NexusCart para o time sem ser chato?

📋 Descrição do Desafio

UML funciona melhor quando é usada para facilitar o diálogo.

Nesta etapa, você deve: 1. Criar 2 Histórias de Usuário (User Stories): No formato "Como [ator], eu quero [ação] para [valor]". 2. Definir o DoD (Definition of Done): O que garante que a Etapa 06 (Classes) e a Etapa 08 (Sequência) do seu projeto estão realmente "prontas"? 3. Documentar Critérios de Aceite: Para uma das histórias criadas, liste 3 regras que o desenvolvedor deve seguir.

💡 Exemplo de DoD:

  • Todos os nomes de métodos em PT-BR.
  • Sem cruzamento de linhas no diagrama.
  • Legenda incluída.

Reta Final

Você já tem quase todo o material! Na Etapa 15 vamos organizar tudo para a grande entrega final.

Etapa 15: Consolidação da Documentação 📂

Vamos dar o acabamento profissional ao projeto NexusCart.

📋 Descrição do Desafio

Um bom analista sabe organizar o conhecimento.

Nesta etapa, você deve revisar todas as etapas anteriores e garantir que: 1. Nomes Consistentes: Se na Etapa 02 o requisito é "Cancelar Pedido", na Etapa 04 deve haver um Caso de Uso com o mesmo nome. 2. Visual Profissional: Verifique se as cores e estilos do Mermaid estão legíveis. 3. Sumário Executivo: Escreva um pequeno texto resumindo o que você aprendeu com a modelagem deste sistema.

Checklist de Ouro

  • Requisitos RF/RNF
  • Casos de Uso
  • Diagrama de Classes
  • Diagrama de Sequência
  • Diagrama de Atividades/Estados
  • Componentes

Etapa 16: Entrega e Apresentação Final 🏆

Hora da verdade! Apresente o NexusCart para o mundo.

📋 Descrição do Desafio

A última etapa é a defesa técnica da sua arquitetura.

Nesta etapa, você deve preparar: 1. Apresentação (Slides ou Markdown): Mostre os 3 diagramas que você considera os mais importantes do projeto. 2. Destaque Técnico: Explique um ponto difícil que você resolveu usando modelagem (ex: "Usei o diagrama de estados para garantir que o estorno só ocorra após a devolução física"). 3. Auto-Avaliação: Qual parte da UML foi mais útil para você neste projeto?

🎉 Parabéns!

Você concluiu o curso de Modelagem UML. Agora você tem um caso de uso real e completo para o seu portfólio!

Certificação

Não esqueça de exportar sua documentação final para PDF ou gerar o link do seu repositório GitHub para a avaliação final.

Quizzes

Quizzes Interativos

Teste seus conhecimentos técnicos com nossos quizzes interativos de 10 questões cada.

Módulo 1 – Fundamentos e Requisitos

Módulo 2 – Especificação e Estrutura

Módulo 3 – Modelagem Comportamental

Módulo 4 – Arquitetura e Integração Final

Quiz 01: Introdução à Análise e Projeto de Sistemas ❓

Teste seus conhecimentos sobre os fundamentos do ciclo de vida de software.

1. Qual a principal diferença entre Análise de Sistemas e Projeto de Sistemas?
A Análise foca no "o que" o sistema deve fazer; o Projeto foca em "como" ele será construído.
O Projeto foca nos requisitos e a Análise foca no código final.
Não há diferença; são apenas nomes diferentes para a mesma fase.
A Análise lida com banco de dados e o Projeto lida com o cliente.
2. O que caracteriza um sistema Monolítico?
Divisão em vários serviços independentes que se comunicam via rede.
Uma única unidade de software onde todas as funcionalidades estão acopladas em um só bloco.
Um sistema que só pode ser executado em servidores locais (on-premise).
Um sistema que não permite o uso de diagramas UML.
3. Qual o papel do Analista de Sistemas na fase de concepção?
Escrever as primeiras linhas de código do backend.
Atuar como uma ponte entre as necessidades do cliente (negócio) e a equipe técnica.
Configurar os servidores de banco de dados.
Apenas marcar reuniões entre os diretores da empresa.

Quiz 02: Engenharia de Software ⚙️

Teste seus conhecimentos sobre modelos de processo e Engenharia de Requisitos.

1. Qual a principal característica do Modelo em Cascata (Waterfall)?
Foco em entregas rápidas e feedback constante do cliente.
Processo linear e sequencial, onde cada fase depende da conclusão da anterior.
Alta flexibilidade para mudanças de requisitos no meio do projeto.
Ausência total de documentação técnica.
2. O que são Requisitos Não-Funcionais (RNF)?
Descrevem qualidades do sistema, como Performance, Segurança e Usabilidade.
Descrevem as funcionalidades diretas que o usuário pode executar.
São requisitos opcionais que não precisam ser documentados.
Dizem respeito apenas às cores e fontes da interface.
3. No contexto de Métodos Ágeis, o que significa o termo "Sprint"?
Um documento longo contendo todos os requisitos do sistema.
Um ciclo de tempo curto e fixo (geralmente 1 a 4 semanas) focado em uma entrega.
Uma reunião diária de 15 minutos entre os desenvolvedores.
A fase final de testes antes do sistema entrar no ar.

Quiz 03: Introdução à UML 🗺️

Teste seus conhecimentos sobre os blocos básicos e tipos de diagramas da UML.

1. O que significa a sigla UML?
Unified Modeling Language (Linguagem de Modelagem Unificada).
Universal Method Logic (Lógica de Método Universal).
Unique Mark Language (Linguagem de Marcação Única).
Ultimate Modeling Library (Biblioteca de Modelagem Definitiva).
2. Quais são as duas grandes categorias de diagramas na UML 2.x?
Diagramas Lógicos e Diagramas Físicos.
Diagramas Estruturais e Diagramas Comportamentais.
Diagramas de Hardware e Diagramas de Software.
Diagramas de Caso de Uso e Diagramas de Código.
3. Qual a principal vantagem de usar a UML em um projeto de software?
Reduzir o tempo de desenvolvimento para zero.
Eliminar a necessidade de escrever código.
Padronizar a comunicação visual e facilitar o entendimento do sistema entre a equipe.
Garantir que o sistema só funcione em linguagem Java.

Quiz 04: Diagrama de Casos de Uso 👤

Teste seus conhecimentos sobre como modelar as intenções do usuário.

1. O que representa um "Ator" em um Diagrama de Caso de Uso?
Apenas o usuário humano que clica nos botões.
Qualquer entidade externa (humano, hardware ou sistema) que interage com o sistema modelado.
Uma parte do código que executa uma função específica.
Uma classe interna que armazena dados de login.
2. Para que serve o retângulo de "Fronteira do Sistema" (System Boundary)?
Para desenhar o layout visual da interface (UI).
Para delimitar o escopo do que está sendo desenvolvido internamente no sistema.
Para proteger o sistema contra ataques de hackers.
Para indicar o tamanho do servidor onde o código será instalado.
3. Qual a relação correta quando um Caso de Uso "A" SEMPRE executa um Caso de Uso "B"?
Relacionamento de Inclusão (<<include>>).
Relacionamento de Extensão (<<extend>>).
Relacionamento de Associação Bilateral.
Relacionamento de Herança de Dados.

Quiz 05: Especificação de Casos de Uso 📝

Teste seus conhecimentos sobre fluxos, pré-condições e pós-condições.

1. O que é o "Fluxo Principal" (ou Caminho Feliz)?
A sequência de passos quando o usuário comete um erro.
A sequência de passos ideal onde o objetivo do ator é atingido sem erros.
Uma descrição genérica que não precisa de detalhes.
A lista de servidores onde o sistema roda.
2. Por que as "Pré-condições" são importantes?
Para definir o que deve ser verdade antes que o caso de uso possa começar.
Para listar as bibliotecas de programação necessárias.
Elas servem apenas para enfeitar o documento de requisitos.
Para definir o que acontece após o término do sistema.
3. Qual a diferença entre Fluxo Alternativo e Fluxo de Exceção?
Não há diferença; ambos são nomes para a mesma coisa.
Alternativo é uma variação do sucesso; Exceção trata uma situação de erro ou falha.
Alternativo é obrigatório e Exceção é opcional.
Exceção é sempre mais simples que o fluxo alternativo.

Quiz 06: Diagrama de Classes (Parte 1) 📦

Teste seus conhecimentos sobre classes, atributos, métodos e visibilidade.

1. No Diagrama de Classes, o que representa o símbolo de menos (-) antes de um atributo?
Visibilidade Pública.
Visibilidade Privada.
Visibilidade Protegida.
Visibilidade de Pacote.
2. O que é uma "Classe" no contexto da UML?
Um molde ou abstração que define atributos e comportamentos comuns a um conjunto de objetos.
Uma representação de um único registro no banco de dados.
Uma função matemática que processa dados.
O nome do arquivo onde o código está salvo.
3. Qual a diferença entre Atributo e Método?
Atributo é opcional e Método é obrigatório.
Atributo representa o estado (dados); Método representa o comportamento (ações).
Atributo fica fora da classe e Método fica dentro.
Atributo não tem visibilidade e Método sempre é público.

Quiz 07: Diagrama de Classes (Parte 2) 🔗

Teste seus conhecimentos sobre associações, herança e composição.

1. O que caracteriza um relacionamento de Composição em relação à Agregação?
Na composição, os objetos podem existir de forma independente.
Na composição, a parte não faz sentido sem o todo (forte dependência de ciclo de vida).
A composição é apenas um nome antigo para a agregação.
A composição é representada por um diamante branco (vazado).
2. O que representa a Generalização/Especialização na UML?
O conceito de Herança, onde uma subclasse herda atributos e métodos de uma superclasse.
O ato de agrupar classes em pastas para organizar o projeto.
A criação de tabelas no banco de dados.
O envio de mensagens em tempo real entre dois objetos.
3. O que indica a "Multiplicidade" (ex: 1..*) em uma associação?
A quantidade de memória que a classe ocupa no servidor.
O número de instâncias de uma classe que podem estar relacionadas a uma única instância de outra classe.
Apenas se o sistema permite ou não o uso de listas (Arrays).
A versão do software que está sendo modelada.

Quiz 08: Diagrama de Sequência ⏱️

Teste seus conhecimentos sobre a ordem temporal das mensagens entre objetos.

1. O que representa o eixo vertical (linha tracejada) em um Diagrama de Sequência?
A quantidade de memória que o objeto consome.
A Linha de Vida do objeto, indicando sua existência ao longo do tempo.
O conjunto de mensagens enviadas para o banco de dados.
A hierarquia de cargos da empresa.
2. O que indica um retângulo estreito sobre a Linha de Vida?
O Foco de Controle (ou Ativação), indicando que o objeto está executando uma operação.
Que o objeto foi deletado da memória.
Uma mensagem de erro crítica.
O limite físico do servidor.
3. Qual a diferença entre uma seta sólida e uma seta pontilhada no envio de mensagens?
A sólida é para Java e a pontilhada é para Python.
A sólida representa uma chamada de método; a pontilhada representa o retorno do dado.
A sólida é para internet e a pontilhada é para rede local.
Ambas representam a mesma coisa, a escolha é puramente estética.

Quiz 09: Diagrama de Comunicação 💬

Teste seus conhecimentos sobre como os objetos se organizam para trocar mensagens.

1. Qual o foco principal do Diagrama de Comunicação em comparação ao de Sequência?
O foco total na ordem temporal das mensagens.
O foco na organização estrutural e nos enlaces entre os objetos que trocam mensagens.
Ele não mostra mensagens, apenas nomes de objetos.
Ele serve apenas para modelar o banco de dados.
2. Como a ordem das mensagens é indicada no Diagrama de Comunicação?
Através de numeração sequencial nas mensagens (ex: 1, 2, 3...).
Pela posição de cima para baixo no diagrama.
Pela espessura das linhas de conexão.
Não há indicação de ordem; as mensagens ocorrem todas ao mesmo tempo.
3. O que é um "Enlace" (Link) no Diagrama de Comunicação?
O conteúdo em texto de um e-mail enviado pelo sistema.
A conexão física ou lógica entre dois objetos, permitindo que troquem mensagens.
O cabo de rede que liga dois computadores.
Uma relação de herança entre duas classes.

Quiz 10: Diagrama de Atividades 🏃‍♂️

Teste seus conhecimentos sobre o fluxo de trabalho e processos de negócio.

1. O que representam as "Raias" (Swimlanes) em um Diagrama de Atividades?
As classes que possuem métodos privados.
A divisão de responsabilidades, indicando quem executa cada atividade no fluxo.
A velocidade de processamento dos dados.
As caixas de texto que aparecem na tela do usuário.
2. Qual a função do símbolo de "Losango" (Gateway) no diagrama?
Indicar uma Decisão ou Bifurcação (Merge/Decision) no fluxo.
Indicar o início obrigatório de todo o processo.
Indicar o fim do fluxo de trabalho.
Indicar que várias ações devem ocorrer em paralelo de forma obrigatória.
3. O que são os nós de "Fork" e "Join"?
São ferramentas para comer a comida servida na empresa.
Símbolos que indicam o início e o fim de atividades executadas de forma paralela ou concorrente.
São nomes de bibliotecas do sistema operacional Linux.
São apenas decorativos e podem ser ignorados em diagramas profissionais.

Quiz 11: Diagrama de Estados 🔄

Teste seus conhecimentos sobre o ciclo de vida de um objeto e suas transições.

1. O que representa um "Estado" no diagrama?
O local geográfico onde o servidor está instalado.
Uma condição ou situação durante a vida de um objeto na qual ele satisfaz alguma condição ou espera por algum evento.
O valor exato de cada variável no código fonte.
A lista de cores da interface do usuário.
2. O que é uma "Transição" entre estados?
A mudança de um estado para outro, disparada por um evento ou condição.
O estado final do objeto após o sistema desligar.
Um erro que trava o sistema permanentemente.
Um botão invisível na tela.
3. Para que servem as "Pseudostates" de Início e Fim?
Elas são opcionais e não trazem informação relevante.
Para indicar claramente onde a vida do objeto começa e onde ela se encerra.
Para indicar onde o usuário deve clicar para fechar o navegador.
Para desenhar o logo da empresa no diagrama.

Quiz 12: Diagrama de Componentes 🗜️

Teste seus conhecimentos sobre a estrutura física e modular do software.

1. O que é um "Componente" na UML?
Um grupo de desenvolvedores que trabalham juntos.
Uma unidade modular de um sistema que encapsula seu conteúdo e cuja manifestação é substituível.

Quiz 13: Diagrama de Implantação 🧊

Teste seus conhecimentos sobre a arquitetura física e a distribuição de artefatos.

1. Qual elemento da UML representa um recurso computacional como um servidor ou smartphone?
Componente
Nó (Node)
Ator
Classe
2. O que é um "Artefato" no contexto do Diagrama de Implantação?
Um arquivo físico resultante do processo de desenvolvimento (ex: .exe, .jar).
Um texto escrito no caderno de requisitos.
A marca do servidor que o cliente comprou.
A conexão de internet fibra ótica.
3. Para que serve o "Caminho de Comunicação" (Communication Path)?
Para mostrar os métodos que o desenvolvedor deve criar.
Para descrever como os nós se conectam fisicamente e quais protocolos utilizam (ex: HTTPS, TCP/IP).
Para definir o ciclo de vida de um botão.
Para escolher as cores da interface mobile.

Quiz 14: Integração dos Diagramas 🔗

Teste seus conhecimentos sobre a rastreabilidade e consistência entre os modelos UML.

1. O que é a Rastreabilidade na Modelagem UML?
A capacidade de saber quem apagou um arquivo no Git.
A capacidade de seguir a evolução de um requisito através de diferentes diagramas e níveis de detalhe.
A velocidade com que o sistema consegue gravar logs.
O rastro que o mouse deixa na tela ao desenhar.
2. O que caracteriza um modelo UML Inconsistente?
Quando um diagrama contradiz o outro (ex: método usado no Sequência não existe no de Classes).
Quando usamos cores diferentes para cada diagrama.
Quando o diagrama é feito usando texto em vez de software gráfico.
Quando o nome da classe é muito grande.
3. Qual a finalidade da Matriz de Rastreabilidade?
Mostrar as transições de estado de um objeto.
Mapear requisitos, casos de uso e classes, garantindo que o escopo foi totalmente coberto.
Definar as raias de responsabilidade de um processo.
Escolher qual banco de dados usar no sistema.

Quiz 15: Workshop de Projeto Final 🚀

Teste seus conhecimentos sobre a aplicação prática de diagramas em um projeto real.

1. Qual a finalidade do Workshop de Projeto Final?
Escrever um relatório de 200 páginas sobre a história da computação.
Integrar e aplicar as diferentes visões da UML (casos de uso, classes, estados, etc.) na modelagem de um sistema completo.
Aprender a instalar o VS Code pela primeira vez.
Ver apenas vídeos teóricos sobre o futuro da IA.
2. Por que é importante validar a consistência entre diferentes diagramas?
Para garantir que a visão dinâmica (sequência) não conflite com a visão estática (classes).
Para economizar tinta na hora de imprimir os diagramas.
Para deixar o GitHub do projeto mais colorido.
Apenas para ganhar nota máxima na avaliação, sem efeito prático.
3. Qual artefato é o mais crítico para o início do Workshop?
O código-fonte completo já escrito e testado.
A Lista de Requisitos e Regras de Negócio do sistema a ser modelado.
A nota fiscal de compra dos servidores.
O manual do usuário pronto para impressão.

Quiz 16: Avaliação Final 🏆

Chegamos ao fim! Teste seus conhecimentos gerais sobre a entrega de projetos de modelagem.

1. Qual o principal objetivo da Apresentação Final do projeto?
Mostrar fotos das férias da equipe.
Demonstrar a coerência técnica da solução e validar como os diagramas resolvem o problema proposto.
Ler em voz alta todas as definições da especificação UML.
Pedir desculpas pelos erros cometidos nas aulas anteriores.
2. O que é considerado uma "Solução Robusta" na avaliação final?
Uma modelagem que trata fluxos alternativos, exceções e possui baixo acoplamento.
Um diagrama que usa todas as cores possíveis e fontes gigantes.
Um projeto que foi feito em menos de 10 minutos.
Algo que só o desenvolvedor que criou consegue entender.
3. Qual a importância do feedback recebido na banca de avaliação?
Apenas para reduzir a nota do aluno sem motivo técnico.
Proporcionar uma visão externa crítica que ajude a melhorar o design e as competências do analista.
O analista nunca deve aceitar sugestões de mudança no seu projeto.
É apenas uma formalidade burocrática sem valor pedagógico.

Slides

Slides Interativos

Nesta seção você acessa os slides completos de cada uma das 16 aulas do Curso. As apresentações foram desenhadas com visual otimizado Reveal.js.

Para utilizar as transições (como as setas do teclado) em tela-cheia, pressione a tecla F.

Módulo 1 – Fundamentos e Requisitos

Módulo 2 – Especificação e Estrutura

Módulo 3 – Modelagem Comportamental

Módulo 4 – Arquitetura e Integração Final

Configuração

Configuração do Ambiente

Prepare sua máquina para modelar sistemas com as melhores ferramentas do mercado.

  • Windows --- Configuração para sistemas Microsoft. Ver Guia

  • Linux --- Configuração para distribuições Linux (Ubuntu/Debian). Ver Guia

  • macOS --- Configuração para computadores Apple. Ver Guia

📋 Próximos Passos

Após configurar seu ambiente, você estará pronto para iniciar a Aula 01 e começar sua jornada em modelagem UML.

Configuração: Windows 🪟

Siga os passos abaixo para preparar seu ambiente de modelagem UML no Windows.

1. Instalando o VS Code

O Visual Studio Code será nossa principal ferramenta para visualizar e criar diagramas via código. 1. Acesse code.visualstudio.com. 2. Baixe o instalador para Windows. 3. Execute o instalador e siga as instruções padrão.

2. Extensões Recomendadas

Abra o VS Code (Ctrl+Shift+X) e instale as seguintes extensões: * Mermaid Editor: Para renderizar diagramas definidos via texto. * Draw.io Integration: Para criar diagramas visuais diretamente no VS Code. * Markdown All in One: Melhora a experiência de escrita para os seus arquivos de aula.

3. PlantUML (Opcional - Avançado)

Para usar o PlantUML, você precisará do Java e do Graphviz: 1. Java: Instale o JRE/JDK aqui. 2. Graphviz: Baixe o instalador em graphviz.org. 3. Extensão: Instale "PlantUML" no VS Code.

4. Git (Versionamento)

Essencial para salvar seu progresso no GitHub. 1. Baixe em git-scm.com. 2. No terminal (cmd ou PowerShell), configure sua identidade: 

git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"

[!TIP] Use o tema Dark Modern no VS Code para uma melhor visualização dos diagramas com cores vibrantes.

Configuração: Linux 🐧

Siga os passos abaixo para configurar seu ambiente de modelagem UML em distribuições baseadas em Debian/Ubuntu.

1. Instalando o VS Code

Abra o terminal e execute: 

sudo apt update
sudo apt install software-properties-common apt-transport-https wget
wget -q https://packages.microsoft.com/keys/microsoft.asc -O- | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://packages.microsoft.com/repos/vscode stable main"
sudo apt install code

2. Extensões de Modelagem

No VS Code, instale: * Mermaid Editor * Draw.io Integration * PlantUML

3. Dependências do PlantUML

Para renderizar diagramas complexos, instale o Java e o Graphviz: 

sudo apt install default-jre graphviz

4. Git

Provavelmente já está instalado, mas para garantir: 

sudo apt install git
git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"

5. Dica de Performance 🚀

Se estiver usando o VS Code via Snap, ele pode ter problemas com algumas extensões de arquivos. Recomendamos a instalação via .deb oficial conforme o passo 1.

Configuração: macOS 🍎

Siga os passos abaixo para preparar seu Mac para modelar sistemas com UML.

1. Instalando o VS Code

  1. Acesse code.visualstudio.com.
  2. Baixe a versão para o chip Apple Silicon (M1/M2/M3) ou Intel, conforme seu caso.
  3. Arraste o Visual Studio Code para a pasta Applications.

2. Extensões Essenciais

No VS Code (Cmd+Shift+X), instale: * Mermaid Editor * Draw.io Integration * PlantUML

3. Brew e Dependências

Recomendamos o uso do Homebrew para instalar o Graphviz (necessário para o PlantUML): 1. Instale o Homebrew (se não tiver): /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" 2. Instale o Graphviz e o Java: 

brew install graphviz
brew install --cask oracle-jdk

4. Git

O macOS já vem com o Git, mas você pode atualizar via Brew: 

brew install git
git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"

[!IMPORTANT] Se o VS Code pedir permissão para acessar pastas de sistema ao abrir arquivos .drawio ou .mermaid, clique em Permitir.

Sobre

Sobre o Curso

🎓 Guia de Modelagem UML Profissional

Este curso foi projetado para capacitar estudantes e profissionais na arte da análise e projeto de sistemas, utilizando a Linguagem de Modelagem Unificada (UML) como base para a comunicação técnica eficiente.

🎯 Objetivos do Curso

  • Análise Holística --- Compreender o sistema como um todo, desde a viabilidade técnica até os requisitos detalhados.

  • Domínio da UML --- Dominar a leitura e criação dos principais diagramas que regem o desenvolvimento de software moderno.

  • Mentalidade Ágil --- Integrar as práticas de modelagem com o manifesto ágil e frameworks como Scrum e Kanban.

  • Prática de Mercado --- Simular cenários reais de levantamento de requisitos e documentação técnica em ambientes digitais.

📚 O Que Você Vai Aprender

Módulo 1 – Fundamentos de Sistemas

  • Introdução à Análise e Papel do Analista
  • Ciclo de Vida de Sistemas (Modelos)
  • Estudo de Viabilidade (Custo-Benefício)
  • Requisitos Funcionais e Não Funcionais

Módulo 2 – Levantamento e Modelagem

  • Técnicas de Coleta de Requisitos
  • Documentação e Especificação Técnica
  • Métodos Tradicionais vs Modernos
  • Introdução Prática à UML e OO

Módulo 3 – Métodos Ágeis

  • Valores e Princípios do Manifesto Ágil
  • Framework Scrum (Papéis e Eventos)
  • Gestão Visual com Kanban
  • WIP e Fluxo Contínuo

Módulo 4 – Laboratório e Projeto final

  • Design Sprint e Prototipação
  • Comunicação em Equipes de Alta Performance
  • Desenvolvimento Ágil de Backlog
  • Apresentação e Defesa de Solução

🛠️ Metodologia

Foco 100% didático e orientado a problemas reais. Cada aula combina teoria sólida com atividades que simulam o dia a dia de um analista de sistemas.

Pronto para modelar soluções incríveis? Começar Agora

Roadmap do Projeto: Guia de Modelagem UML 🚀

Este documento rastreia a evolução do curso.

✅ Fase 1: Planejamento (Concluído)

  • Definição Syllabus (16 Aulas)
  • Estrutura focada em Fundamentos e Modelagem
  • Configuração MkDocs Material Moderno

✅ Fase 2: Conteúdo Base (Concluído)

  • Criação das 16 Aulas (Markdown) com Mermaid
  • Criação dos 16 Quizzes Interativos
  • Criação dos 16 Conjuntos de Exercícios
  • Criação dos 16 Slides (RevealJS) com 20+ slides cada

✅ Fase 3: Projetos e UX (Concluído)

  • Definição dos 16 Projetos práticos aplicados
  • Layout de Cards na Home e subpáginas
  • Demonstrações com TermynalJS

🚀 Fase 4: Lançamento e Manutenção

  • Deploy GitHub Pages (GitHub Actions)
  • Inclusão de vídeos tutoriais de diagramação
  • Atualização para novas versões da UML

Status Atual: Finalizado / Manutenção Última Atualização: 20/02/2026

Materiais Complementares 📚

Bem-vindo à seção de materiais complementares do curso de Guia de Modelagem UML. Aqui você encontra recursos adicionais para apoiar seus estudos e aprofundar seu conhecimento técnico.

  • Slides --- Acompanhe o conteúdo teórico com slides dinâmicos e visuais.

  • Exercícios --- Pratique a modelagem de sistemas com exercícios progressivos.

  • Quizzes --- Valide seu aprendizado com testes rápidos por módulo.

  • Projetos --- Construa um portfólio sólido com 16 mini-projetos práticos.

  • Ambiente --- Guias de instalação de ferramentas (VS Code, Astah, Lucidchart).

Versão para Impressão

Esta página foi gerada automaticamente para impressão.