Exemplo de diagrama de casos de uso: atores, casos de uso, include e extend

Um diagrama de casos de uso responde a uma pergunta em uma página: quem usa este sistema, e para quê? Gerentes de produto o usam para alinhar o escopo, engenheiros para ver cada ponto de entrada de um sistema e testadores para conferir se cada objetivo tem um caminho. Ele também é um dos diagramas UML mais desenhados de forma errada: as pessoas o transformam em fluxograma, desenham cada botão como um caso de uso ou usam include e extend ao contrário.

Este post explica a notação como a especificação UML 2.5.1 a define, resolve include versus extend com um teste simples, percorre um exemplo completo de um app de pedidos de comida, mostra o texto que deve ficar por trás de cada oval e lista os erros que tornam os diagramas de casos de uso inúteis.

A notação

A direção das setas vem direto da especificação UML 2.5.1, publicada pela OMG em dezembro de 2017: include aponta do caso de uso base para o incluído; extend aponta do caso que estende para o caso que ele estende. A especificação também permite pontos de extensão, lugares nomeados no caso base onde uma extensão pode se encaixar, listados dentro do oval.

Include versus extend: um teste

Pergunte se o caso de uso base está completo sem o outro.

• Incompleto sem ele: include. Fazer um pedido sempre envolve cobrar. “Place order” inclui “Pay for order”. A seta aponta para o que é incluído, e o caso base não roda sem ele.
• Completo sem ele: extend. Aplicar um cupom é opcional; um pedido é perfeitamente válido sem cupom. “Apply promo code” estende “Place order”, em um ponto de extensão como “antes do pagamento”, quando o cliente tem um cupom. A seta aponta para o caso base, que nem sabe que a extensão existe.

Mais duas regras evitam a maior parte dos abusos:

• Use include para compartilhar comportamento de que vários casos de uso precisam, como autenticação ou pagamento. Não o use para quebrar um caso de uso em passos; isso é um fluxograma.
• Use extend com moderação. Se você tem mais extends do que casos de uso base, está documentando opções de interface, não objetivos.

Atores são papéis

Um ator é um papel, não uma pessoa nem um cargo. A mesma pessoa pode ser cliente de manhã e gerente de restaurante à tarde. Atores também podem ser sistemas: um provedor de pagamentos que o app chama para autorizar um cartão é um ator de apoio. Algumas equipes modelam tarefas agendadas com um ator “Time”, uma convenção comum para casos de uso que ninguém inicia manualmente.

Por convenção, os atores primários, que iniciam casos de uso para alcançar seus objetivos, ficam à esquerda, e os atores de apoio, que o sistema aciona, ficam à direita.

Nomear casos de uso no nível certo

Nomeie os casos de uso com verbo e objeto, do ponto de vista do ator: “Fazer pedido”, e não “Pedido”, “Tela de pedido” ou “Botão Enviar”. Cada um deve ser um objetivo que o ator consiga concluir de uma vez só e que ficaria feliz em alcançar, o que Alistair Cockburn chama de nível do mar dos objetivos do usuário. Níveis mais altos (“Administrar o restaurante”) são amplos demais para um oval; níveis mais baixos (“Digitar o número do cartão”) são passos dentro de um caso de uso.

Um exemplo completo: pedidos de comida

O diagrama abaixo mostra um app de pedidos de comida com quatro atores:

• Customer navega pelo cardápio, faz pedidos e acompanha entregas.
• Restaurant staff aceita pedidos.
• Courier entrega pedidos.
• Payment provider, um sistema externo, apoia o pagamento.

E sete casos de uso dentro da fronteira:

1. Browse menu
2. Place order, que inclui Pay for order
3. Pay for order, que o provedor de pagamentos apoia
4. Apply promo code, que estende Place order antes do pagamento
5. Track delivery
6. Accept order
7. Deliver order

Repare no que não está no diagrama: nenhuma ordem de passos, nenhuma tela, nenhum oval “Log in” para cada ator. Autenticação é uma pré-condição, não um objetivo; ela entra nas descrições ou, se tiver comportamento real, em um único caso de uso incluído.

A descrição por trás de cada oval

O diagrama é um índice. O valor está em uma descrição curta para cada caso de uso, por exemplo:

Use case: Place order
Primary actor: Customer
Precondition: The customer is signed in and the basket is not empty.

Main success scenario:
  1. Customer reviews the basket and delivery address.
  2. System shows the total, including fees and estimated delivery time.
  3. Customer confirms the order.
  4. System takes payment (includes: Pay for order).
  5. System sends the order to the restaurant and confirms it to the customer.

Extensions:
  2a. Customer has a promo code: Apply promo code, then continue at step 2.
  4a. Payment is declined: System asks for another payment method.
  5a. Restaurant does not accept within 5 minutes: System cancels and refunds.

Postcondition: The order is paid and visible to the restaurant.

As extensões da descrição, os ramos numerados de “e se”, são de onde saem requisitos e casos de teste. Elas são muito mais detalhadas que as relações extend do diagrama, que deve mostrar só os objetivos opcionais que merecem uma figura.

Erros comuns

• Um fluxograma disfarçado. Setas entre casos de uso que significam “depois” transformam o diagrama em um modelo de processo. Para a ordem do trabalho, use um diagrama BPMN ou um diagrama de atividades.
• Um caso de uso por operação CRUD. “Criar item do cardápio”, “Atualizar item do cardápio” e “Excluir item do cardápio” costumam ser um único objetivo: “Gerenciar cardápio”.
• Telas e botões como casos de uso. “Clicar em Finalizar compra” é um passo, não um objetivo.
• Include para decompor. Se todo caso de uso inclui outros três, o diagrama descreve a estrutura do código, não os objetivos do usuário.
• Componentes internos como atores. O banco de dados não é um ator; ele está dentro do sistema. Os sistemas externos que você chama são.
• Sem fronteira. Sem o retângulo do sujeito, os leitores não conseguem distinguir o que você está construindo do que você depende.

Diagramas de casos de uso, histórias de usuário e diagramas de sequência

Eles funcionam juntos: o diagrama de casos de uso mapeia o território, as histórias o fatiam em partes entregáveis e um diagrama de sequência mostra como um cenário roda de verdade.

O diagrama de casos de uso

Como ler:

• O retângulo é a fronteira do sistema: tudo o que está dentro é o app de pedidos de comida.
• Os atores da esquerda iniciam casos de uso: o cliente tem três objetivos; a equipe do restaurante e os entregadores, um cada.
• O provedor de pagamentos à direita é um sistema de apoio que o app chama durante o pagamento.
• A seta «include» de Place order para Pay for order significa que o pagamento sempre acontece. A seta «extend» de Apply promo code para Place order significa que o cupom é opcional.
• O bloco Markdown é uma chave de notação para quem está começando com UML.

Desenhar diagramas de casos de uso que as pessoas leem de verdade

• Fique abaixo de uns 15 casos de uso por diagrama. Se um sistema tiver mais, divida por ator ou por subsistema.
• Coloque os atores primários à esquerda e os de apoio à direita, para que a direção de leitura corresponda a quem inicia o quê.
• Rotule include e extend de forma explícita, com as aspas angulares, e mantenha as setas tracejadas.
• Deixe os detalhes para as descrições. O diagrama deve caber em um slide; o texto pode ser tão longo quanto precisar.

Diagramas de casos de uso combinam bem com as outras visões da UML: o exemplo de diagrama de classes UML para o modelo de domínio e o exemplo de diagrama de estados para o ciclo de vida de um pedido.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione uma Moldura do pack Básico chamada Food ordering app como fronteira do sistema.
3. Adicione dentro da moldura sete nós Caso de uso do pack UML, com os nomes acima.
4. Adicione quatro nós Ator do pack UML: Customer, Restaurant staff e Courier à esquerda, Payment provider à direita.
5. Ligue os atores aos seus casos de uso com linhas simples. Adicione arestas tracejadas com o rótulo «include» de Place order para Pay for order e «extend» de Apply promo code para Place order.
6. Adicione um bloco Markdown do pack Básico com uma chave de notação curta.

O exemplo usa 13 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

Qual é a diferença entre include e extend em um diagrama de casos de uso? Include significa que o caso de uso base sempre executa o comportamento incluído, e a seta aponta para o caso incluído. Extend significa comportamento opcional adicionado sob uma condição, e a seta aponta da extensão para o caso de uso base.

Um ator pode ser um sistema? Sim. Qualquer papel externo que interage com o sistema pode ser um ator, incluindo outro software, como um provedor de pagamentos. Componentes dentro do seu sistema não são atores.

As setas devem ligar atores a casos de uso? A UML usa linhas de associação simples entre atores e casos de uso. Algumas equipes adicionam pontas de seta para mostrar quem inicia, mas a notação padrão não exige isso.

Quantos casos de uso um diagrama deve ter? Como referência, não mais que uns 15. Sistemas maiores ficam mais legíveis em vários diagramas, divididos por ator ou por subsistema.

Diagramas de casos de uso mostram a ordem dos passos? Não. Eles mostram objetivos, não sequências. A ordem dos passos fica nas descrições dos casos de uso, nos diagramas de atividades ou nos diagramas de sequência.

Comece grátis — um assento, sem cartão de crédito.