Guia Extra: Engenharia de Software e Modelagem UML • Bloco 5: Do Modelo ao Código e à Evolução

🗺️ Mapa Conceitual do Projeto Integrador

flowchart TD
    subgraph STAGE1["Etapa 1: Visão, Processo e Requisitos"]
        E1A["Visão de Produto & Stakeholders"]
        E1B["Modelo de Processo (Scrum/XP/Kanban)"]
        E1C["Requisitos SMART (RF, RNF, RD) & Backlog INVEST"]
    end

    subgraph STAGE2["Etapa 2: Negócio e Comportamento"]
        E2A["Diagrama de Casos de Uso (Cockburn)"]
        E2B["Modelagem BPMN 2.0 (AS-IS e TO-BE)"]
        E2C["Diagrama de Atividades com Swimlanes"]
    end

    subgraph STAGE3["Etapa 3: Domínio e Estrutura Estática"]
        E3A["DDD Estratégico (Bounded Context) & CRC"]
        E3B["Diagrama de Classes (Composição & OCL)"]
        E3C["Diagrama de Pacotes & Métrica D de Martin"]
    end

    subgraph STAGE4["Etapa 4: Dinâmica, Nuvem e Decisões"]
        E4A["Diagrama de Sequência & Máquina de Estados"]
        E4B["Modelo C4 (Níveis 1 e 2) & Implantação"]
        E4C["ADRs (Nygard) & Cenários de Qualidade ATAM"]
    end

    STAGE1 --> STAGE2
    STAGE2 --> STAGE3
    STAGE3 --> STAGE4
    STAGE4 --> SAD["📘 Documento de Arquitetura de Software (SAD / arc42 Consolidado)"]

    style STAGE1 fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style STAGE2 fill:#ede7f6,stroke:#512da8,stroke-width:2px
    style STAGE3 fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style STAGE4 fill:#fce4ec,stroke:#c2185b,stroke-width:2px
    style SAD fill:#e8f5e9,stroke:#2e7d32,stroke-width:3px

🎯 1. O Desafio: A Síntese da Engenharia de Software

O objetivo culminante deste guia é a confecção autônoma de um Documento de Arquitetura de Software (SAD — Software Architecture Document) completo, aderente ao padrão internacional arc42 e apoiado pelo modelo conceitual das visões 4+1 de Philippe Kruchten.

O estudante ou equipe deve escolher um dos quatro domínios canônicos para modelar do zero (ou submeter um tema corporativo equivalente à validação do instrutor):

Domínio de Aplicação Desafio de Domínio Central Tensões Arquiteturais e Requisitos Críticos
1. Gestão Hospitalar Veterinária Prontuário eletrônico unificado, controle de posologia farmacêutica e internação de animais. Integridade transacional estrita; rastreabilidade de substâncias controladas; histórico temporal imutável.
2. Coleta Seletiva Municipal Logística reversa inteligente, agendamento de descarte de volumosos e otimização de rotas de caminhões. Alta disponibilidade móvel em campo; tolerância a conexões intermitentes; geolocalização em tempo real.
3. Sistema de Micromobilidade (Bicicletas) Estações inteligentes de travamento, cobrança por tempo de uso fracionado e manutenção preventiva de frota. Concorrência massiva na devolução/retirada; prevenção de fraudes de GPS; baixa latência de liberação física.
4. Gestão de Congressos Científicos Submissão double-blind, comitê avaliador distribuído, controle de conflitos de interesse e certificados digitais. Sigilo e integridade de dados; picos extremos de tráfego na data limite de submissão (deadline effect).

🧱 2. Roteiro Executivo em Quatro Etapas

A construção do artefato arquitetural ocorre de forma iterativa e incremental ao longo de quatro entregas sincronizadas:

Etapa 1: Visão do Produto, Processo e Engenharia de Requisitos

  • Justificativa do Modelo de Processo selecionado (Scrum, Kanban ou OpenUP) com base na incerteza e volatilidade do domínio.
  • Especificação de 12 requisitos numerados hierárquicos: Requisitos Funcionais (RF), Requisitos Não Funcionais (RNF conforme ISO/IEC 25010) e Regras de Negócio (RN).
  • Backlog do Produto contendo 10 User Stories estruturadas sob os princípios INVEST e acompanhadas de critérios de aceitação em sintaxe BDD (Dado-Quando-Então).
  • Matriz de Rastreabilidade Bidirecional em Markdown ligando necessidades a itens do backlog.

Etapa 2: Modelagem de Negócio e Comportamento Operacional

  • Diagrama de Casos de Uso com fronteira do sistema explícita e uso semanticamente correto de «include» e «extend».
  • 2 Especificações Textuais de Casos de Uso no padrão formal de Alistair Cockburn (nível do mar).
  • Diagrama BPMN 2.0 modelando o fluxo de negócio em piscinas (pools) e raias (lanes), comparando o fluxo manual (AS-IS) ao automatizado (TO-BE).
  • Diagrama de Atividades UML com nós de bifurcação (fork), junção (join) e objetos trafegando entre partições.

Etapa 3: Domínio de Negócio e Arquitetura Estrutural

  • Glossário de Linguagem Ubíqua e delimitação de Bounded Contexts no modelo de domínio estratégico DDD.
  • Cartões CRC (Class-Responsibility-Collaborator) para as três entidades mais complexas do núcleo de domínio.
  • Diagrama de Classes de Projeto contendo tipagem forte, visibilidade (+, -, #), multiplicidade nos dois lados das associações, herança ou padrão de papéis, composição forte e pelo menos duas restrições invariantes formais em OCL (Object Constraint Language).
  • Diagrama de Pacotes validando a ausência de ciclos acíclicos (ADP) e calculando a distância da Sequência Principal ($D = |A + I - 1|$).

Etapa 4: Dinâmica de Execução, Topologia Física e Governança

  • 2 Diagramas de Sequência completos utilizando fragmentos combinados (alt, opt, loop).
  • Máquina de Estados comportamental do ciclo de vida da entidade central do sistema, contendo ações entry/do/exit, guardas e pseudoestados.
  • Diagramas do Modelo C4: Nível 1 (Contexto do Sistema) e Nível 2 (Contêineres de Software).
  • Diagrama de Implantação especificando nós de nuvem, ambientes de execução e protocolos de conectividade.
  • 3 Registros de Decisão de Arquitetura (ADR) completos no padrão Michael Nygard.
  • Esquema DDL SQL gerado para o banco relacional, incluindo chaves primárias, estrangeiras e restrições de integridade em cascata.

📘 3. Estrutura Canônica do SAD (Template arc42)

O documento final consolidado deve organizar-se rigorosamente segundo as 12 seções canônicas do framework arc42:

docs/arc42-sad.md
├── 1. Introdução e Metas de Negócio
├── 2. Restrições Arquiteturais
├── 3. Contexto e Escopo (C4 Nível 1)
├── 4. Estratégia de Solução & Estilo Arquitetural
├── 5. Visão de Blocos de Construção (C4 Nível 2 e Diagrama de Classes)
├── 6. Visão de Tempo de Execução (Sequência e Atividades)
├── 7. Visão de Implantação (Topologia de Nuvem e Nós)
├── 8. Conceitos Transversais (Segurança, Transações, Observabilidade)
├── 9. Decisões Arquiteturais (Catálogo de ADRs)
├── 10. Requisitos de Qualidade (Cenários ATAM de Latência, Resiliência e Vazão)
├── 11. Riscos Técnicos e Plano de Mitigação de Débito
└── 12. Glossário da Linguagem Ubíqua

⚖️ 4. Rubrica de Avaliação da Engenharia de Software

A avaliação do projeto integrador reflete a maturidade profissional do aluno na resolução de problemas complexos de software:

Dimensão Avaliada Peso Indicadores de Excelência Técnica
Coerência Semântica Horizontal 30% Rastreabilidade total: As classes fornecem os métodos invocados nos diagramas de sequência; o esquema SQL reflete com exatidão as multiplicidades e composições; as transições da máquina de estados suportam os fluxos dos casos de uso.
Verificabilidade e Engenharia de Requisitos 20% Requisitos funcionais e não funcionais sem termos ambíguos; critérios de aceitação executáveis em Gherkin; cenários de qualidade mensuráveis via métricas objetivas (p99, MTBF, throughput).
Rigor Notacional e Sintático (OMG / BPMN) 20% Notação UML 2.5 e BPMN 2.0 executada com precisão (diferenciação nítida entre agregação e composição, visibilidade formal, semântica correta de gateways e eventos).
Profundidade das Decisões e ADRs 15% As decisões não são meras justificativas superficiais; explicitam forças conflitantes, alternativas tecnológicas descartadas e contrapartidas assumidas (trade-offs).
Maturidade Docs-as-Code e Versionamento 15% Todos os diagramas implementados em código textual (Mermaid/PlantUML), repositório limpo, commits semânticos (Conventional Commits) e histórico de baseline preservado no Git.