🎭 CAPÍTULO 11: CASOS DE USO (PRÁTICA E RELAÇÕES)

Dominar os conceitos básicos é apenas o começo. Na engenharia profissional, precisamos modelar como as funcionalidades dependem umas das outras através de relacionamentos formais da UML. 🛡️🧩

🎯 Objetivo do Capítulo

Aplicar os relacionamentos de Inclusão (<<include>>) e Extensão (<<extend>>) em cenários reais, garantindo que o diagrama reflita regras de negócio obrigatórias e opcionais.

🏢 O Cenário Corporativo (TecProExpress Health)

A TecProExpress iniciou um projeto para uma rede de laboratórios. O sistema deve permitir que o Bioquímico valide exames, mas a lei exige que todo exame validado dispare automaticamente uma notificação para o Órgão Governamental.

Ao mesmo tempo, o paciente pode (ou não) solicitar o envio do laudo por e-mail após a visualização.

"Seu desafio é modelar essas dependências. O que é um passo obrigatório (Inclusão) e o que é uma ação opcional (Extensão)? Esse diagrama guiará a segurança e o fluxo de dados da aplicação."

🧠 Relacionamentos entre Casos de Uso

1. Inclusão (<<include>>)

Ocorre quando um Caso de Uso sempre precisa de outro para ser concluído. É uma dependência obrigatória.

• Exemplo: Para Efetuar Pagamento, o sistema deve obrigatoriamente Validar Saldo.

2. Extensão (<<extend>>)

Ocorre quando um Caso de Uso pode disparar outro em situações específicas. É opcional.

• Exemplo: Ao Realizar Pedido, o sistema pode (se o usuário quiser) Aplicar Cupom de Desconto.

📊 Visualização de Fluxo Laboratorial

graph LR
    subgraph "Fronteira TecPro Health"
        UC1(["Visualizar Exame"])
        UC4(["Validar Laudo"])
        UC5(["Gerar PDF do Prontuário"])
        UC7(["Disparar Webhook Governamental"])
        UC8(["Download Exame"])
    end

    RE["Recepcionista"] --- UC1
    BI["Bioquímico Sênior"] --- UC4
    UC4 -. "<< include >>" .-> UC7
    PA["Paciente"] --- UC8
    UC8 -. "<< extend >>" .-> UC5

🔍 Detalhamento: Segurança Visual

Note no diagrama acima como o Paciente nunca toca no endpoint de "Validar Laudo". Visualmente, o Arquiteto trancou a rota. Nenhum programador sênior esquecerá de colocar a trava de segurança no código Java após ver este fluxograma.

[!TIP] Dica Sênior: Se você tem uma ação que se repete em 10 Casos de Uso diferentes (ex: "Fazer Login"), use o <<include>> para não precisar redesenhar a lógica em todos. Isso é o equivalente ao reuso de código na modelagem. 🚀

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se você modelar um <<include>> para uma ação que na verdade é opcional, o que acontecerá com o sistema? (Resposta: O sistema ficará engessado. O usuário será obrigado a fazer algo que não queria, gerando uma péssima experiência de uso e um bug de regra de negócio). 🧠🛡️