Guia Didático: O que é um Caso de Uso (Use Case)

1. O que é, de forma simples?

Pense em um Caso de Uso (ou Use Case, em inglês) como uma "história" que descreve uma interação.

Imagine um caixa eletrônico (ATM). Uma "história" seria "Cliente saca dinheiro". Outra seria "Cliente consulta o saldo".

No desenvolvimento de software, um Caso de Uso é exatamente isso: uma técnica que descreve, passo a passo, como um Ator (um usuário ou outro sistema) interage com um Sistema para atingir um objetivo de valor.

O foco principal do Caso de Uso é capturar os requisitos funcionais (o que o sistema deve fazer) do ponto de vista de quem o utiliza, e não do ponto de vista técnico (o "como" ele faz).

2. Autores Renomados e Documentos Oficiais (A Origem)

Para atualizar o conteúdo, é fundamental saber de onde essa técnica veio:

1. Ivar Jacobson: É considerado o "pai" dos Casos de Uso. Ele os criou nos anos 80 (antes da UML) como uma forma de capturar requisitos na Ericsson.
2. UML (Unified Modeling Language): Os Casos de Uso foram adotados como parte central da UML, o padrão oficial de modelagem de software mantido pelo OMG (Object Management Group). Na UML, eles são usados para definir o comportamento esperado do sistema.
3. Alistair Cockburn: É o autor do livro de referência no assunto (Writing Effective Use Cases). Ele popularizou a ideia de que um Caso de Uso deve, acima de tudo, descrever a meta do ator e entregar um valor observável.

3. A Anatomia de um Caso de Uso (Didático)

Um erro comum é pensar que o Caso de Uso é apenas o desenho. Na verdade, ele é composto por duas partes: a Especificação (o texto) e o Diagrama (o visual). A especificação é a parte mais importante.

Parte A: A Especificação (O "Recheio")

Este é o documento de texto que descreve a "história" em detalhes. Baseado nas melhores práticas (Alistair Cockburn), ele deve conter:

1. Nome: Um verbo + substantivo, indicando a meta do ator (Ex: "Sacar Dinheiro", "Gerar Relatório de Vendas").
2. Ator Principal: Quem inicia a interação (Ex: "Cliente").
3. Objetivo (ou Meta): Uma breve descrição do que o ator quer alcançar (o "valor").
4. Pré-condições: O que deve ser verdade para a história poder começar (Ex: "O Cliente está autenticado no sistema").
5. Pós-condições (Sucesso): O que será verdade se a história terminar com sucesso (Ex: "O dinheiro foi debitado da conta" e "A transação foi registrada").
6. Fluxo Principal (ou Básico): O "caminho feliz". A sequência de passos (1, 2, 3...) onde tudo dá certo e o ator atinge seu objetivo sem desvios.
7. Fluxos Alternativos: Outros caminhos que também levam ao sucesso, mas não são o principal (Ex: No "Pagar Compra", o fluxo principal é pagar com Cartão de Crédito; um fluxo alternativo é pagar com PIX).
8. Fluxos de Exceção: Os caminhos onde algo dá errado e o objetivo falha (Ex: "Senha inválida", "Saldo insuficiente", "Sistema offline").

Parte B: O Diagrama (A "Visão Geral")

O diagrama é o mapa que mostra todas as "histórias" do sistema e quem participa delas. Ele é simples e usa três elementos principais:

1. Ator (Actor):
   • O que é: Representa quem (ou o quê) está fora do sistema e interage com ele.
   • Representação: Um "boneco palito".
   • Exemplos: "Cliente", "Vendedor", "Gerente". Também pode ser outro sistema, como "Sistema de Banco" ou "API de Pagamento".
2. Caso de Uso (Use Case):
   • O que é: A meta/objetivo do ator (a "história").
   • Representação: Uma elipse (um círculo oval).
   • Exemplos: "Fazer Login", "Manter Cadastro de Cliente", "Emitir Nota Fiscal".
3. Sistema (System Boundary):
   • O que é: A "fronteira" do sistema.
   • Representação: Uma caixa (retângulo) onde os Casos de Uso ficam dentro e os Atores ficam fora.

4. Os Relacionamentos (<<include>> e <<extend>>)

O diagrama também mostra como os casos de uso se relacionam. Os dois mais importantes (e mais confundidos) são <<include>> e <<extend>>.

<<include>> (Inclusão)

• O que é: É usado para evitar repetição. O caso de uso base obrigatoriamente precisa executar outro caso de uso.
• Dica: Pense nisso como uma "sub-rotina obrigatória".
• Exemplo: Tanto "Sacar Dinheiro" quanto "Consultar Saldo" precisam "Validar Senha". Para não escrever a validação de senha duas vezes, ambos dão <<include>> no caso de uso "Validar Senha". Você não pode sacar dinheiro sem validar a senha.
• Seta: Aponta do caso de uso base para o caso de uso incluído (Base → Incluído).

<<extend>> (Extensão)

• O que é: É usado para adicionar comportamento opcional ou que só acontece sob certas condições. O caso de uso base não depende da extensão para funcionar.
• Dica: Pense nisso como um "plug-in" ou funcionalidade opcional.
• Exemplo: No "Finalizar Compra" (caso base), o usuário pode "Adicionar Cupom de Desconto" (a extensão). O caso "Finalizar Compra" funciona perfeitamente sem o cupom, mas o cupom estende sua funcionalidade.
• Seta: Aponta da extensão para o caso base (Extensão → Base).

5. Resumo: O que um Caso de Uso NÃO é

Para facilitar a compreensão, é útil saber o que ele não é:

• Não é um Design de Tela: Ele não diz onde os botões ficam, quais as cores ou como é a interface. Ele diz o que o usuário faz (Ex: "O usuário informa o CPF"), e não como (Ex: "O usuário clica no botão 'OK' azul").
• Não é um Fluxograma: Ele não detalha a lógica de programação (ifs/elses/loops). Ele descreve a interação do usuário.
• Não é (exatamente) uma Estória de Usuário (User Story): Embora ambos capturem requisitos, as Estórias de Usuário (comuns em métodos ágeis) são muito mais simples e curtas (Ex: "Como Cliente, eu quero..."). Um único Caso de Uso (como "Gerenciar Carrinho") pode precisar de várias Estórias de Usuário para ser implementado.