📚 Pré-requisitos Teóricos: este projeto aplica conceitos ensinados em Guia Engenharia de Software e Modelagem UML (Capítulos 06, 10, 11, 13 e 14). Recomendado revisar antes de começar.

🏦 Especificação & Modelagem de Domínio Bancário com UML 2.5

v1.0 — Engenharia de Software, UML 2.5, Casos de Uso, Diagrama de Classes e Sequência

Trilha de Especialização Pedagógica — Projeto 1 de 4

• ➡️ v1 (este): Modelagem Bancária · UML 2.5 · Casos de Uso · Classes de Domínio · Sequência
• v2: Modelagem de Microsserviços e Event-Driven com Diagramas de Atividades
• v3: Domain-Driven Design (DDD): Bounded Contexts & Context Mapping
• v4: C4 Model: Diagramas de Contexto, Contêineres, Componentes e Código

🎓 Nível Profissional Simulado: Arquiteto de Software / Analista de Sistemas Pleno. Antes de escrever uma única linha de código em um sistema financeiro, arquitetos projetam o modelo na notação UML (Unified Modeling Language). Dominar Casos de Uso, Diagramas de Classes (composição, agregação, herança) e Diagramas de Sequência é essencial para construir sistemas de missão crítica.

🎯 Objetivo & Escopo do Projeto

Elaborar a Especificação de Arquitetura e Modelagem de Domínio Completa de um Sistema Bancário Digital (Core Banking) na notação UML 2.5, cobrindo o Diagrama de Casos de Uso, o Diagrama de Classes com relacionamentos de herança (ContaCorrente, ContaPoupanca) e o Diagrama de Sequência de uma transação Pix em tempo real.

🧑‍💼 Fase 1 — Levantamento de Requisitos

O Briefing do Cliente (Superintendente de Arquitetura Bancária)

“Estamos reformulando o motor de contas e transferências do banco digital. Precisamos de uma especificação técnica formal: mapear todos os atores (Cliente, Gerente, Sistema de Antifraude), detalhar os casos de uso de abertura de conta, depósito, saque e transferência Pix, modelar a hierarquia de classes com saldo, limite de cheque especial e taxas, e desenhar o fluxo sequencial exato de validação e liquidação de um Pix.”

Requisitos Funcionais (RF) e Não-Funcionais (RNF)

📋 Fase 2 — Backlog & User Stories

🌿 Fase 3 — Engenharia em Equipe (Git Flow & Setup)

# Branch da funcionalidade
git checkout -b feature/US01-uml-banking-domain

# Validar especificacao UML
cat index.md

🛠️ Fase 4 — Modelagem do Diagrama de Sequência Pix (UML)

sequenceDiagram
    autonumber
    actor Cliente as 👤 Cliente Pagador
    participant App as 📱 App Bancário
    participant Core as ⚙️ Core Banking API
    participant Fraude as 🛡️ Antifraude
    participant Bacen as 🏛️ Banco Central (SPI)

    Cliente->>App: Solicita Pix (Chave + Valor)
    App->>Core: POST /api/v1/pix/transferir
    Core->>Fraude: Analisar Risco da Transação
    Fraude-->>Core: Aprovado (Score de Risco Baixo)
    Core->>Core: Debitar Saldo em Conta
    Core->>Bacen: Enviar Ordem de Liquidação
    Bacen-->>Core: Confirmação de Liquidação SPI
    Core-->>App: Comprovante de Pagamento
    App-->>Cliente: Exibir Comprovante com Sucesso ✅

🚀 Como Executar no Laboratório

1. Abra o terminal na pasta deste projeto

No seu editor/IDE, abra a pasta deste projeto (File > Open Folder) ou navegue via terminal:

cd uml_01_especificacao_sistema_bancario

2. Execute a aplicação ou testes

# Executar comandos específicos da tecnologia:
python main.py # ou npm run dev / ./gradlew build

[!TIP] Dica para execução a partir da raiz do repositório: Se você abriu o repositório completo no VS Code, basta navegar até a pasta antes de executar: cd catalogo_projetos/uml_01_especificacao_sistema_bancario`

🧭 Decisões de Arquitetura (ADRs)

• ADR 001: Adoção de UML 2.5 com diagrama de sequência para garantia de consistência em operações Pix.

🧪 Testes de Validação & Consistência de Modelo

• Validação de Domínio: Todas as subclasses herdam métodos abstratos sacar(valor) e depositar(valor) respeitando o Princípio de Substituição de Liskov (LSP).

🏛️ Arquitetura Visual & Engenharia do Sistema

O diagrama abaixo sintetiza a organização dos artefatos, contratos e diretrizes arquiteturais na subpasta uml/:

flowchart TD
    subgraph Especificacao["Especificação & Contratos"]
        E1["Contratos Formais"] --> E2["Modelagem de Domínio"]
    end
    subgraph Implementacao["Implementação & Stacks"]
        I1["Arquiteturas & Código"] --> I2["Paridade Multilinguagem"]
    end
    subgraph Padroes["Governança & Padrões"]
        P1["Living Styleguides"] --> P2["Conformidade de Design"]
    end
    subgraph Homologacao["Qualidade & Homologação"]
        Q1["Matriz de Rastreabilidade"] --> Q2["Checkpoints CP-01..05 PASS"]
    end

    Especificacao --> Implementacao
    Implementacao --> Padroes
    Padroes --> Homologacao

    style Especificacao fill:#e3f2fd,stroke:#1976d2,stroke-width:1.5px
    style Implementacao fill:#fffde7,stroke:#fbc02d,stroke-width:1.5px
    style Padroes fill:#e8f5e9,stroke:#388e3c,stroke-width:1.5px
    style Homologacao fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px

🎯 Engenharia de Requisitos & Modelagem Formal

👤 User Stories (Histórias de Usuário)

⚙️ Requisitos Funcionais (RF)

🛡️ Requisitos Não-Funcionais (RNF)

🔗 Matriz de Rastreabilidade (RTM)

🏁 Checkpoints de Qualidade & Homologação