⚙️ Engenharia de Software

Cap 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>>), Extensão (<<extend>>), Associação e Generalização em cenários reais, garantindo que o diagrama reflita regras de negócio obrigatórias, opcionais e hierarquias de Atores/Casos de Uso.


🏢 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.

3. Associação

É a linha mais simples de todas: só indica quem participa de quê, sem implicar obrigatoriedade (como o <<include>>) ou opcionalidade (como o <<extend>>) entre Casos de Uso.

  • Exemplo: O Cliente se associa a Calcular Empréstimo Pessoal; o Submissor se associa a Realizar Submissão.

4. Generalização (Herança)

Ocorre quando um Ator ou Caso de Uso mais específico herda o comportamento de um mais genérico — evita redesenhar o diagrama inteiro para cada variação.

  • Exemplo (Atores): Pessoa Física e Pessoa Jurídica são especializações do Ator genérico Cliente.
  • Exemplo (Casos de Uso): Abrir Conta Especial e Abrir Conta Poupança são especializações de Abrir Conta Comum.

📊 Visualização de Fluxo Laboratorial


🔍 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.

Dica: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

Importante: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). 🧠🛡️
Copyright © 2026