Diagramas de Casos de Uso: Um Guia Prático

Um diagrama de caso de uso é um diagrama comportamental UML que mostra como usuários externos ou sistemas interagem com um sistema. Ele foca em o que o sistema faz sob a perspectiva de um ator, e não em detalhes de implementação interna.

Diagramas de casos de uso são especialmente úteis durante a análise de requisitos, pois fornecem uma visão de alto nível da funcionalidade e do escopo do sistema.

1. O que um Diagrama de Casos de Uso Mostra

Um diagrama de caso de uso tipicamente contém:

• Fronteira do sistema — define o que está dentro do sistema que está sendo modelado.

• Ator — usuários externos, organizações, dispositivos ou sistemas que interagem com ele.

• Casos de uso — objetivos ou serviços que o sistema fornece.

• Associações — links de comunicação entre atores e casos de uso.

• Relacionamentos entre casos de uso — como <<incluir>> e <<estender>>.

• Generalização — herança entre atores ou casos de uso.

Um diagrama de caso de uso normalmente não mostra:

• Passos do algoritmo

• Tabelas de banco de dados

• Classes de programa

• Fluxos de trabalho internos

• Layouts detalhados da interface do usuário

• Sequências de mensagens ao longo do tempo

Esses detalhes são melhor representados com diagramas de atividade, classe, sequência ou estado.

2. Conceitos-chave

Fronteira do sistema

A fronteira do sistema é um retângulo que circunda os casos de uso que pertencem ao sistema.

Por exemplo, em um sistema de compras online:

+--------------------------------------+
|        Sistema de Compras Online     |
|                                      |
|  (Navegar pelos Produtos)            |
|  (Fazer Pedido)                      |
|  (Realizar Pagamento)                |
+--------------------------------------+

Os atores permanecem fora da fronteira porque são externos ao sistema.

A fronteira ajuda a esclarecer o escopodo sistema. Se uma capacidade está fora da fronteira, ela não é implementada pelo sistema que está sendo modelado.

Atores

Um atoré qualquer coisa externa que interage com o sistema para alcançar um objetivo.

Os atores podem incluir:

• Usuários humanos

• Aplicações externas

• Dispositivos de hardware

• Outras organizações

• Tempo ou eventos agendados, quando modelados como gatilhos externos

Exemplos:

• Cliente

• Bibliotecário

• Gateway de Pagamento

• Administrador

• Serviço de E-mail

Um ator representa um papel, não necessariamente uma pessoa específica. Por exemplo, “Cliente” é geralmente melhor do que “Alex”.

Os atores podem ser:

• Atores primários — iniciam interações para alcançar um objetivo.

• Atores de suporte — fornecem serviços ao sistema.

Por exemplo, um cliente pode iniciar “Fazer Pedido”, enquanto uma gateway de pagamento suporta “Processar Pagamento”.

Casos de Uso

Um caso de uso representa um objetivo significativo ou serviço fornecido pelo sistema.

Bons nomes de casos de uso geralmente seguem esta forma:

Verbo + objeto

Exemplos:

• Registrar Conta

• Pesquisar Catálogo

• Submeter Solicitação

• Gerar Relatório

• Cancelar Reserva

• Processar Pagamento

Um caso de uso deve descrever um resultado observável, em vez de uma etapa interna de implementação.

Prefira:

Fazer Pedido

em vez de:

Validar Objeto de Pedido

O segundo descreve uma operação interna, em vez de um objetivo do usuário.

Associações

Uma associação é um link de comunicação entre um ator e um caso de uso.

Isso indica que o ator participa ou inicia o caso de uso.

Cliente ---- (Fazer Pedido)

Associações normalmente não indicam sequência, fluxo de controle ou direção. Se a ordem das interações for importante, use um diagrama de sequência ou de atividade.

3. Relações entre Casos de Uso

<<include>>

Use <<include>> quando um caso de uso sempre utiliza outro caso de uso.

Por exemplo, realizar um pedido pode sempre exigir autenticação:

(Realizar Pedido) ..> (Autenticar Cliente) : <<include>>

O caso de uso base depende do caso de uso incluído.

Use include quando:

• O comportamento é obrigatório.

• O comportamento é reutilizado por vários casos de uso.

• Extrair o comportamento melhora a clareza.

Exemplo:

(Sacar Dinheiro) ..> (Autenticar Cartão) : <<include>>
(Verificar Saldo) ..> (Autenticar Cartão) : <<include>>

Ambos os casos de uso sempre exigem autenticação do cartão.

<<extend>>

Use <<extend>> quando um comportamento adicional é opcional ou inserido condicionalmente em um caso de uso base.

(Aplicar Desconto) ..> (Realizar Pedido) : <<extend>>

O comportamento de desconto ocorre apenas quando as condições de elegibilidade são atendidas.

Use extend quando:

• O comportamento é opcional.

• Ocorre apenas sob uma condição.

• O caso de uso base está completo sem ele.

Exemplos:

• “Adicionar Embalo de Presente” estende “Fazer Pedido.”

• “Solicitar Reembolso” estende “Cancelar Assinatura.”

• “Enviar E-mail Promocional” estende “Concluir Cadastro.”

A seta aponta do caso de uso que estende para o caso de uso base.

Generalização

A generalização representa uma relação “é-um” entre atores ou casos de uso.

Por exemplo:

Cliente Premium --|> Cliente

Um cliente premium é um tipo de cliente e herda as interações do cliente.

A generalização de atores pode ser útil quando vários atores compartilham comportamento comum:

Administrador --|> Funcionário
Bibliotecário --|> Funcionário

Use generalização com moderação. Se a relação for meramente “usa” ou “participa de”, uma associação geralmente é mais apropriada.

4. Atores Primários e de Suporte

Considere um cenário de pagamento online:

• O Cliente é o ator primário porque ele inicia a compra.

• O Gateway de Pagamento é um ator de suporte porque processa o pagamento a pedido do sistema.

Um modelo simples pode parecer com isto:

Cliente ---- (Fazer Pedido)
(Fazer Pedido) ---- Gateway de Pagamento

A distinção é útil porque esclarece quem se beneficia do caso de uso e quais sistemas externos estão envolvidos.

5. Como Identificar Casos de Uso

Uma maneira prática de descobrir casos de uso é perguntar:

1. Quem usa o sistema?

2. Qual objetivo cada ator deseja alcançar?

3. Quais serviços o sistema fornece?

4. Quais eventos desencadeiam o comportamento do sistema?

5. Com quais sistemas externos o sistema deve interagir?

6. Qual comportamento é sempre obrigatório?

7. Qual comportamento é opcional ou condicional?

Para cada ator, liste seus objetivos:

O objetivo deve ser significativo para o ator. Evite transformar cada pequena operação do sistema em um caso de uso.

6. Diretrizes de Nomenclatura

Use nomes claros e orientados a objetivos.

Exemplos bons:

• Criar Conta

• Atualizar Perfil

• Enviar Reclamação

• Rastrear Remessa

• Aprovar Solicitação

• Gerar Fatura

Evite nomes vagos:

• Processamento do Sistema

• Gerenciar Dados

• Função do Usuário

• Executar Operação

Evite detalhes técnicos excessivos:

• Executar Consulta SQL

• Chamar Endpoint REST

• Instanciar PaymentService

Estes podem ser etapas de implementação válidas, mas geralmente não são úteis como casos de uso de alto nível.

7. Exemplo: Sistema de Gerenciamento de Biblioteca

Suponha que um sistema de biblioteca suporte:

• Membros buscando livros

• Membros emprestando livros

• Membros devolvendo livros

• Bibliotecários gerenciando o catálogo

• Notificações de atraso

• Processamento de pagamentos para multas

Atores possíveis:

• Membro

• Bibliotecário

• Serviço de Notificação

• Serviço de Pagamento

Casos de uso possíveis:

• Pesquisar Catálogo

• Emprestar Livro

• Devolução de Livro

• Calcular Multa

• Pagar Multa

• Gerenciar Catálogo

• Enviar Notificação de Atraso

Relacionamentos:

• Empréstimo de Livro inclui Verificação de Cadastro.

• Empréstimo de Livro inclui Verificação de Disponibilidade do Livro.

• Devolução de Livro inclui Calcular Multa.

• Pagar Multa interage com o Serviço de Pagamento.

• Enviar Notificação de Atraso interage com o Serviço de Notificação.

8. Exemplo PlantUML

O seguinte código PlantUML cria um diagrama de casos de uso para o sistema de biblioteca:

@startuml
direção da esquerda para a direita

título Sistema de Gerenciamento de Biblioteca - Diagrama de Casos de Uso

ator Membro
ator Bibliotecário
ator "Serviço de Notificação" como Notificação
ator "Serviço de Pagamento" como Pagamento

retângulo "Sistema de Gerenciamento de Biblioteca" {

  caso de uso "Pesquisar Catálogo" como UC_Pesquisa
  caso de uso "Empréstimo de Livro" como UC_Emprestimo
  caso de uso "Devolução de Livro" como UC_Devolucao
  caso de uso "Verificação de Cadastro" como UC_VerificarMembro
  caso de uso "Verificação de Disponibilidade do Livro" como UC_VerificarDisponibilidade
  caso de uso "Calcular Multa" como UC_CalcularMulta
  caso de uso "Pagar Multa" como UC_PagarMulta
  caso de uso "Gerenciar Catálogo" como UC_GerenciarCatalogo
  caso de uso "Enviar Notificação de Atraso" como UC_Notificar
}

Membro --> UC_Pesquisa
Membro --> UC_Emprestimo
Membro --> UC_Devolucao
Membro --> UC_PagarMulta

Bibliotecário --> UC_GerenciarCatalogo
Bibliotecário --> UC_Emprestimo
Bibliotecário --> UC_Devolucao

Pagamento --> UC_PagarMulta
Notificação --> UC_Notificar

UC_Emprestimo ..> UC_VerificarMembro : <<include>>
UC_Emprestimo ..> UC_VerificarDisponibilidade : <<include>>
UC_Devolucao ..> UC_CalcularMulta : <<include>>

UC_Notificar ..> UC_Devolucao : <<extend>>

@enduml

9. Explicação do Exemplo

Atores

ator Membro
ator Bibliotecário
ator "Serviço de Notificação" como Notificação
ator "Serviço de Pagamento" como Pagamento

O diagrama modela dois atores humanos e dois serviços externos.

Apelidos como como Notificação tornam nomes longos mais fáceis de referenciar posteriormente.

Fronteira do Sistema

retângulo "Sistema de Gestão da Biblioteca" {
    ...
}

O retângulo define o escopo do sistema. Os casos de uso dentro do retângulo são fornecidos pelo sistema da biblioteca.

Associações de Atores

Membro --> UC_Pesquisar
Membro --> UC_Empréstimo

Essas associações mostram que um membro pode pesquisar o catálogo e fazer empréstimos de livros.

A direção da seta geralmente não é semanticamente importante em um diagrama de casos de uso básico. Ela é usada principalmente para tornar o diagrama legível.

Relacionamentos de Inclusão

UC_Empréstimo ..> UC_ChecarMembro : <<include>>
UC_Empréstimo ..> UC_ChecarDisponibilidade : <<include>>

Fazer um empréstimo de livro sempre requer verificações de membresia e disponibilidade, por isso são modelados como casos de uso incluídos.

Relacionamento de Extensão

UC_Notificar ..> UC_Retornar : <<extend>>

Isso indica que o comportamento de notificação de atraso é um comportamento adicional associado à devolução de um livro.

No entanto, em um modelo real de requisitos, um design mais natural poderia ser associar “Enviar Notificação de Atraso” a um processo agendado ou a um ator como “Agendador da Biblioteca”. O melhor relacionamento depende das regras de negócio reais.

10. Especificação de Caso de Uso Mais Detalhada

Um diagrama fornece uma visão geral, mas cada caso de uso importante deve geralmente ter uma especificação textual.

Caso de Uso: Empréstimo de Livro

Um diagrama de casos de uso não deve tentar conter todos esses detalhes. O diagrama fornece o mapa; a especificação fornece o comportamento.

11. Referência de Sintaxe do PlantUML

Declarando Atores

actor Cliente
actor "Gateway de Pagamento" as Gateway

Declarando Casos de Uso

usecase "Fazer Pedido" as PlaceOrder
usecase "Processar Pagamento" as ProcessPayment

Criando um Limite do Sistema

retângulo "Loja Online" {
    usecase "Navegar Produtos" como Navegar
    usecase "Fazer Pedido" como Pedido
}

Conectando Atores e Casos de Uso

Cliente --> Navegar
Cliente --> Pedido

Incluir

Pedido ..> ProcessarPagamento : <<incluir>>

Estender

AplicarCupom ..> Pedido : <<estender>>

Generalização de Atores

ClientePremium --|> Cliente

Agrupamento de Pacotes

Pacotes podem agrupar visualmente casos de uso relacionados:

retângulo "Sistema Bancário" {
  pacote "Gerenciamento de Conta" {
    usecase "Abrir Conta" como AbrirConta
    usecase "Fechar Conta" como FecharConta
  }

  pacote "Pagamentos" {
    usecase "Transferir Fundos" como TransferirFundos
    usecase "Pagar Conta" como PagarConta
  }
}

Notas

nota à direita de PlaceOrder
  O cliente deve ser autenticado
  antes de fazer um pedido.
fim da nota

12. Melhorando o Layout do Diagrama

O PlantUML organiza automaticamente os diagramas, mas várias técnicas melhoram a legibilidade.

Controlar Direção

direção da esquerda para a direita

Isso é frequentemente útil quando os atores devem aparecer nas laterais e os casos de uso no centro.

Outras direções comuns incluem:

direção de cima para baixo

Usar Aliases

Em vez de repetir nomes longos:

usecase "Verificar Identidade do Cliente" as VerifyIdentity

Em seguida, referencie:

RegisterAccount ..> VerifyIdentity : <<include>>

Agrupar Casos de Uso Relacionados

Use pacotes ou retângulos aninhados para separar áreas funcionais:

package "Gestão de Pedidos" {
    usecase "Criar Pedido" as CreateOrder
    usecase "Cancelar Pedido" as CancelOrder
}

Evitar Cruzamentos Excessivos

Um diagrama torna-se difícil de ler quando muitas linhas se cruzam. Você pode melhorá-lo por meio de:

• Posicionar atores relacionados próximos aos seus casos de uso

• Agrupar casos de uso em pacotes

• Dividir um único diagrama grande em vários diagramas menores

• Usar aliases para referências claras

• Evitar relacionamentos desnecessários

13. Erros Comuns

Modelar Funções Internas como Casos de Uso

Isso geralmente é muito técnico:

Validar Conexão com o Banco de Dados
Serializar Solicitação
Chamar API de Pagamento

Prefira objetivos com significado externo:

Realizar Pagamento
Submeter Solicitação
Gerar Relatório

Tratar Todo Ator como uma Pessoa

Sistemas e dispositivos externos também podem ser atores:

• Gateway de Pagamento

• Provedor de Identidade

• Sistema de Armazém

• Leitor de Código de Barras

• Serviço de Notificação

Usando includepara Comportamento Opcional

Se o comportamento for opcional, use estender em vez de incluir.

Incorreto:

Realizar Pedido ..> Aplicar Cupom : <<incluir>>

Se a aplicação de um cupom for opcional, use:

Aplicar Cupom ..> Realizar Pedido : <<estender>>

Usando estender para Comportamento Obrigatório

Se um comportamento sempre ocorre, ele deve geralmente ser modelado com incluir.

Realizar Pedido ..> Autenticar Cliente : <<incluir>>

Conectar Casos de Uso Diretamente Sem Significado

Uma linha entre dois casos de uso deve representar uma relação UML válida. Evite conexões arbitrárias que apenas implicam que os casos de uso estão de alguma forma relacionados.

Criar Um Único Diagrama Gigante

Um diagrama de casos de uso deve comunicar claramente em alto nível. Se contiver dezenas de atores e casos de uso, crie vários diagramas organizados por subsistema ou área de negócio.

Mostrar Sequência

Um diagrama de casos de uso não mostra que um caso de uso ocorre antes de outro. Para sequência, use um diagrama de sequência ou um diagrama de atividades.

14. Quando Usar Outros Diagramas UML

Diagramas de casos de uso são melhores para escopo do sistema e objetivos do usuário. Combine-os com outros diagramas quando mais detalhes forem necessários:

15. Processo de modelagem recomendado

1. Defina o limite do sistema.

2. Identifique todos os atores externos.

3. Identifique os objetivos de cada ator.

4. Converta esses objetivos em casos de uso.

5. Conecte os atores aos casos de uso em que participam.

6. Identifique o comportamento reutilizável obrigatório e modele-o com <<include>>.

7. Identifique o comportamento opcional ou condicional e modele-o com <<extend>>.

8. Adicione generalização apenas onde houver uma relação genuína de “é-um”.

9. Revise o diagrama com as partes interessadas.

10. Adicione especificações textuais para casos de uso importantes.

11. Divida o diagrama se ele ficar muito lotado.

16. Modelo compacto de PlantUML

Você pode usar isso como ponto de partida:

@startuml
left to right direction

title Diagrama de Casos de Uso do Sistema

actor Usuário
actor "Sistema Externo" as SistemaExterno

retangulo "Nome do Sistema" {
  usecase "Objetivo Principal do Usuário" as ObjetivoPrincipal
  usecase "Comportamento Compartilhado Necessário" as ComportamentoNecessario
  usecase "Comportamento Opcional" as ComportamentoOpcional
}

Usuário --> ObjetivoPrincipal
SistemaExterno --> ObjetivoPrincipal

ObjetivoPrincipal ..> ComportamentoNecessario : <<include>>
ComportamentoOpcional ..> ObjetivoPrincipal : <<extend>>

@enduml

O princípio central é modelar objetivos visíveis externamente, não detalhes internos de implementação. Um diagrama de casos de uso robusto torna imediatamente compreensíveis os limites do sistema, atores, capacidades e dependências importantes.

Referência

This post is also available in Deutsch, English, Español, فارسی, Français and Bahasa Indonesia.