No diagrama de casos de uso da UML, as associações include (inclusão) e extend (extensão) servem para relacionar casos de uso, permitindo reaproveitar comportamentos e organizar o sistema. [1, 2]
Aqui está a função direta de cada uma:
<<include>> (Inclusão)
Serve para indicar que um caso de uso obrigatoriamente precisa do comportamento de outro para ser concluído. [3, 4]
- Função: Reaproveitar passos comuns entre diferentes fluxos.
- Sentido da seta: Do caso de uso principal ponta para o caso de uso incluído.
- Exemplo: "Sacar Dinheiro" e "Ver Saldo" obrigatoriamente incluem "Fazer Login". [5, 6]
<<extend>> (Extensão)
Serve para indicar que um caso de uso pode ou não ter seu comportamento ampliado por outro, dependendo de uma condição específica. [7]
- Função: Tratar fluxos opcionais, alternativos ou exceções sem poluir o fluxo principal.
- Sentido da seta: Do caso de uso opcional (extensão) ponta para o caso de uso principal.
- Exemplo: "Fazer Compras" pode ser estendido por "Aplicar Cupom de Desconto" (apenas se o cliente tiver um cupom).
Relembrando ...
No diagrama de casos de uso da UML, além das relações já mencionadas, existem três formas de associação que conectam atores entre si ou atores a casos de uso: [1, 2]
1. Associação Simples (Entre Ator e Caso de Uso)
É a conexão mais comum do diagrama. Ela indica que um ator interage com um caso de uso, participando da execução dele. [3, 4]
- Representação gráfica: Uma linha reta contínua (sem setas).
- Significado: Mostra apenas o canal de comunicação. Não indica quem inicia a ação, a menos que se use uma seta opcional na ponta para indicar o sentido da interação.
2. Generalização / Herança de Atores (Entre Atores)
Assim como nos casos de uso, um ator pode herdar o papel e as permissões de outro ator mais geral. [5]
- Representação gráfica: Uma linha reta contínua com uma seta em formato de triângulo vazado.
- Sentido da seta: Aponta do ator específico (filho) para o ator geral (pai).
- Exemplo: O ator "Gerente" é uma especialização do ator "Funcionário". O "Gerente" herda o acesso a todos os casos de uso do "Funcionário", além de ter os seus próprios. [6, 7]
3. Associação Direcionada / Unidirecional (Entre Ator e Caso de Uso)
É uma variação da associação simples usada para deixar explícito quem inicia a interação no sistema.
- Representação gráfica: Uma linha reta contínua com uma seta comum (
>). - Ator Primário: A seta sai do ator e aponta para o caso de uso (o ator inicia a ação).
- Ator Secundário: A seta sai do caso de uso e aponta para o ator (o sistema inicia a ação e o ator apenas recebe o resultado ou fornece dados de suporte, como um sistema de gateway de pagamento externo). [8, 9, 10]
A distinção entre atores primários e secundários baseia-se em quem inicia a ação e quem apenas apoia a execução do caso de uso. [1, 2]
Aqui está o critério exato de definição:
Ator Primário vs. Ator Secundário
- Ator Primário: É quem inicia a interação com o sistema para atingir um objetivo específico. O caso de uso existe para satisfazer uma necessidade dele.
- Exemplo: O Cliente que inicia o caso de uso "Comprar Produto". [3]
- Ator Secundário: É quem fornece um serviço ou suporte para que o caso de uso possa ser concluído. Ele é acionado pelo sistema e não inicia o processo. Geralmente são sistemas externos, bancos de dados ou APIs.
- Exemplo: O Gateway de Pagamento (sistema externo) que valida o crédito durante a compra. [4, 5, 6]
Um caso de uso pode ter mais de dois atores?
Sim, perfeitamente. Um único caso de uso pode estar associado a múltiplos atores simultaneamente. Não há limite técnico na UML.
Quando isso acontece, a estrutura geralmente segue este padrão:
- Um Ator Primário: Aquele que starta o processo.
- Múltiplos Atres Secundários: Diferentes sistemas ou pessoas que precisam interagir para o fluxo terminar.
Exemplo Prático com 3 Atores:
No caso de uso "Agendar Consulta Médica Online":
- Paciente (Ator Primário): Inicia o agendamento no aplicativo.
- Médico (Ator Secundário): Recebe a notificação e confirma a disponibilidade na agenda.
- Sistema de SMS/E-mail (Ator Secundário Externo): Envia o código de confirmação para o paciente.
Não confunda Caso de Uso com Atividade
Para não confundir o Diagrama de Casos de Uso com o de Atividades, você deve focar no "o quê" o sistema faz, e nunca no "como" ele faz. O diagrama de casos de uso é uma ferramenta de escopo e negócio, não de fluxo de processos. [1, 2]
Aqui estão as diretrizes práticas para estabelecer esse limite na sua modelagem:
1. Aplique o Teste do Valor de Negócio (Regra do "E Daí?")
Um caso de uso deve entregar um resultado de valor observável para o ator. Atividades isoladas não entregam valor sozinhas. [3]
- Errado (Nível de Atividade): "Digitar Usuário", "Validar Senha", "Clicar no Botão Entrar". (Se o usuário fizer apenas isso e o sistema cair, ele não atingiu nenhum objetivo de negócio).
- Certo (Caso de Uso): "Fazer Login" ou "Autenticar Usuário".
2. Evite o "Efeito Cascata" de Includes e Extends
Se o seu diagrama tem uma sequência longa de balões interligados por
<<include>> que parecem um passo a passo, você transformou o diagrama em um fluxograma.- Sinal de alerta: Se o Caso de Uso A inclui o B, que inclui o C, que inclui o D, você está modelando o algoritmo ou a cronologia do sistema.
- Como corrigir: Junte todos esses passos dentro da descrição textual (fluxo principal) de um único caso de uso macro.
3. A Regra do "Abaixe a Caneta" (Deixe o detalhe para o texto)
O balão no diagrama deve ser apenas um título visual. Toda a lógica de ifs, elses, loops e validações deve ficar guardada dentro da especificação textual do caso de uso (documento de texto que acompanha o diagrama), e não desenhada na tela. [4]
- Se você precisa explicar o que acontece se o usuário errar a senha, não crie um caso de uso "Exibir Mensagem de Erro". Trate isso como um Fluxo Alternativo no documento de texto do caso de uso "Fazer Login".
4. Diferença Visual e Conceitual de Foco
| Critério | Diagrama de Casos de Uso | Diagrama de Atividades |
|---|---|---|
| Foco principal | Metas e Objetivos do usuário. | Fluxo de controle e passos lógicos. |
| Tempo / Ordem | Não possui cronologia. A ordem dos balões não importa. | Altamente cronológico. Tem início, meio, decisões e fim. |
| Granularidade | Macro (Visão de alto nível do sistema). | Micro (Visão detalhada do processo). |
Para calibrar o limite do seu projeto atual, você poderia me dizer qual o nome de um caso de uso que você está em dúvida se está detalhado demais? Posso te ajudar a avaliar se ele deve virar um balão ou apenas uma linha de texto.
Comentários