Cap 11: Casos de Uso (Prática e Relações)
🎯 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.
<<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
<<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). 🧠🛡️Cap 10: Diagrama de Casos de Uso (Conceitos)
O Diagrama de Casos de Uso é a "foto panorâmica" do sistema sob a perspectiva do usuário final. Ele é o ponto de partida essencial para definir o escopo funcional e os limites do software. 🛡️🧩
Cap 12: Diagrama de Classes (Conceitos)
Chegamos ao núcleo da Engenharia de Sistemas modernos. Se os "Casos de Uso" explicavam o que o usuário vê, o Diagrama de Classes explica como o software organiza a Memória RAM e o Banco de Dados. 🛡️🧩