Dominando a Abordagem Orientada a Casos de Uso: Um Guia Completo para Requisitos e Design

Introdução

Na engenharia de software, preencher a lacuna entre as necessidades das partes interessadas e a implementação técnica é frequentemente a fase mais desafiadora do desenvolvimento. A Abordagem Orientada a Casos de Uso oferece uma metodologia estruturada e iterativa para resolver esse problema. Ao focar em como os usuários interagem com o sistemapara alcançar objetivos específicos, essa abordagem garante que os requisitos sejam claros, testáveis e diretamente rastreáveis aos artefatos de design.

Este guia oferece um roteiro completo da Abordagem Orientada a Casos de Uso, indo dos requisitos de alto nível até o design detalhado. Utilizaremos um único exemplo contínuo — um Sistema de Gerenciamento de Pedidos Online—para ilustrar cada etapa, garantindo consistência e clareza em todo o processo.

---

Visão Geral da Metodologia

A Abordagem Orientada a Casos de Uso segue uma progressão natural de cima para baixo. Cada etapa refina a anterior, adicionando precisão e reduzindo ambiguidades.

Por que essa ordem importa?

1. Diagrama de Casos de Uso:Fornece um inventário completo de capacidades e escopo. É rápido de analisar e ideal para o acordo das partes interessadas sobre o queo sistema faz.
2. Descrição do Caso de Uso:Remove ambiguidades ao definir pré-condições, pós-condições, atores e prioridade. Ele “congela” o contrato de comportamento.
3. Fluxo de Eventos:Transforma o contrato em etapas concretas e testáveis. Isso serve como matéria-prima tanto para casos de teste quanto para o design técnico.
4. Atividade/Diagrama de Sequência: Atua como a ponte para o código. Identifica os objetos participantes, suas responsabilidades, trocas de mensagens e regras de ramificação exatas.

---

Etapa 1: Diagrama de Casos de Uso (Requisitos)

O Diagrama de Casos de Uso captura quem interage com o sistema (atores) e o que eles podem fazer (casos de uso), juntamente com as relações entre eles.

Conceitos Chave

• Ator Primário: Inicia o caso de uso (colocado à esquerda).
• Ator Secundário: Suporta o sistema ou recebe notificações (colocado à direita).
• Fronteira do Sistema: O retângulo que define o escopo do sistema.
• <<include>>: Representa comportamento compartilhado obrigatório. Se o Caso de Uso A inclui o Caso de Uso B, B deve ocorrer para que A seja concluído.
• <<extend>>: Representa comportamento opcional. O Caso de Uso B estende o Caso de Uso A apenas sob condições específicas.

Exemplo: Sistema de Gerenciamento de Pedidos Online

@startuml
skinparam linetype ortho
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam vpDiagramType UseCaseDiagram
skinparam actor {
  BackgroundColor #E8F5E9
}
skinparam usecase {
  BackgroundColor #BBDEFB
  BorderColor #1976D2
  ArrowColor #1976D2
}

left to right direction
actor "Clienten(Primário)" as cust
actor "Armazémn(Secundário)" as wh

rectangle "Sistema de Gerenciamento de Pedidos" {
  usecase "Fazer Pedido" as UC1
  usecase "Cancelar Pedido" as UC2
  usecase "Rastrear Pedido" as UC3
  usecase "Login" as UC4
  usecase "Imprimir Fatura" as UC5
}

cust -[#black]- UC1
cust -[#black]- UC2
cust -[#black]- UC3
UC1 -[#crimson]- wh
UC2 -[#crimson]- wh
UC1 ...> UC4 : <<include>>
UC2 ...> UC4 : <<include>>
UC3 ...> UC4 : <<include>>
UC1 <... UC5 : <<extend>>
@enduml

Análise do Diagrama:

• O Cliente inicia o pedido, o cancelamento e o rastreamento de pedidos.
• O Armazém está envolvido no pedido e no cancelamento de pedidos (provavelmente para atualizações de estoque).
• Login está incluído em Fazer Pedido, Cancelar Pedido e Rastrear Pedidos, o que significa que a autenticação é obrigatória para essas ações.
• Imprimir Fatura estende Fazer Pedido, o que significa que é uma etapa opcional que pode ocorrer após o pedido ser feito.

---

Etapa 2: Descrição do Caso de Uso (Especificação)

Um diagrama nomeia os casos de uso, mas carece de detalhes. O Tabela de Descrição do Caso de Usoespecifica o contrato preciso para cada caso de uso.

Exemplo: UC-01 Fazer Pedido

Campo	Valor
ID do Caso de Uso	UC-01
Nome	Fazer Pedido
Ator Primário	Cliente
Ator Secundário	Armazém
Pré-condições	Cliente está logado; o carrinho contém pelo menos um item; os itens estão em estoque
Pós-condições (Sucesso)	Pedido é persistido com status confirmado; pagamento é capturado; número de rastreamento emitido
Pós-condições (Falha)	Nenhuma ordem criada; carrinho inalterado; usuário informado da razão
Fluxo Principal	→ Consulte a Etapa 3
Fluxos Alternativos / Exceções	Estoque insuficiente; pagamento recusado
Prioridade	Alta

Propósito: Esta etapa define o que deve ser verdadeiro antes o caso de uso for executado (pré-condições) e o que deve ser válido após (pós-condições), estabelecendo critérios claros de sucesso/falha.

---

Etapa 3: Fluxo de Eventos (Cenários)

Este é o coração comportamental da abordagem. O caso de uso “Fazer Pedido” expande-se para um roteiro de cenário—uma sequência de passos numerados escrita antes de existirem quaisquer diagramas de design detalhados.

Cenário Principal de Sucesso (Fluxo Básico)

1. O cliente faz login.
2. O cliente submete o carrinho com os itens selecionados.
3. O sistema valida o conteúdo do carrinho e a disponibilidade do estoque.
4. O sistema cobra o total por meio da gateway de pagamento.
5. O sistema salva o pedido com status confirmado.
6. O sistema retorna uma confirmação de pedido com um ID de pedido.
7. O sistema notifica o Armazém para separar, embalar e enviar.

Cenários Alternativos

• 3a. Estoque Insuficiente: O sistema relata os itens indisponíveis e retorna ao carrinho.
• 4a. Pagamento Recusado: O sistema informa o cliente e não cria o pedido.

Convenção Principal: Cada cenário mapeia diretamente para uma etapa na descrição. Esses fluxos tornam-se a base para os diagramas de Atividade e de Sequência na próxima etapa.

---

Etapa 4: Projeto Detalhado (Diagramas de Sequência e de Atividade)

Nesta etapa, você escolhe a notação com base no aspecto do sistema que deseja enfatizar.

• Diagrama de Sequência: Enfatizalinhas de vida, ordem das mensagens e responsabilidades entre objetos. Ideal para descobrir classes e métodos.
• Diagrama de Atividade: Enfatizafluxo de controle e decisões por meio de faixas/partes. Ideal para documentar processos e responsabilidades de funções.

4A. Diagrama de Sequência (Perspectiva de Interação)

@startuml
title Diagrama de Sequência de Realizar Pedido
skinparam linetype ortho
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam sequenceParticipant underline
skinparam vpDiagramType InteractionDiagram
skinparam {
  FontSize 14
  ArrowColor #4A4A4A
  ArrowFontColor #4A4A4A
  BackgroundColor #FFFFFF
  BorderColor #DEDEDE
  FontColor #333333
  Participant {
    BorderColor #0077B6
    BackgroundColor #F0F8FF
    FontColor #005691
  }
  Actor {
    BorderColor #6A057F
    BackgroundColor #F5EEF8
    FontColor #510363
  }
  Sequence {
    ArrowThickness 2
    LifeLineBorderColor #444444
    LifeLineBackgroundColor #F7F7F7
    BoxBorderColor #AAAAAA
    BoxBackgroundColor #FFFFFF
    BoxFontColor #333333
  }
}

actor "Cliente" as USR
participant "Serviço de Pedido" as OS
participant "Gateway de Pagamento" as PG
database "Banco de Dados de Pedidos" as DB

activate USR
USR -> OS : submitOrder(items)
activate OS
alt Validação e Pagamento
  OS -> OS : validateCart(items)
  OS -> PG : charge(total)
  activate PG
  PG --> OS : paymentOk
  deactivate PG
  OS -> DB : saveOrder(status=confirmed)
  activate DB
  DB --> OS : orderId
  deactivate DB
  OS --> USR : orderConfirmation(orderId)
else Estoque Insuficiente
  OS -> DB : checkStock(items)
  activate DB
  DB --> OS : stockUnavailable
  deactivate DB
  OS --> USR : error("Fora de estoque")
else Pagamento Falhou
  PG --> OS : paymentFailed
  OS --> USR : error("Pagamento recusado")
end
deactivate OS
@enduml

Conceitos Principais:

• Chamadas Síncronas: Setas sólidas (->).
• Respostas: Setas tracejadas (-->).
• Barras de Ativação: Mostra a duração do processamento de um objeto.
• alt Fragmento Combinado: Envolve os três cenários (Sucesso, Estoque Insuficiente, Falha no Pagamento), refletindo diretamente o Fluxo de Eventos da Etapa 3.

4B. Diagrama de Atividades (Perspectiva de Processo)

@startuml
<style>
  element { MaximumWidth 150 }
  start   { Backgroundcolor #00695C }
  stop    { Backgroundcolor #C2185B }
  activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
  diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
  arrow   { LineColor #424242; Fontcolor #000000 }
  swimlane{ Fontcolor #000000; FontSize 14 }
</style>
title Diagrama de Atividades de Realizar Pedido

|#F0F8FF|Cliente|
start
:Login;
:Navegar no Catálogo;
:Adicionar Itens ao Carrinho;

if (Pronto para Finalizar Compra?) then (sim)
  :Prosseguir para Finalização;
else (não)
  :Voltar à Navegação;
  stop
endif

|#E8F5E9|Sistema|
:Validar Carrinho;
:Processar Pagamento;

if (Pagamento Aprovado?) then (sim)
  :Criar Pedido (status=confirmado);
else (não)
  :Notificar Falha no Pagamento;
endif

|#F5EEF8|Armazém|
if (Pagamento Aprovado?) then (sim)
  :Selecionar e Embalar Itens;
  :Enviar Pedido;
  :Enviar Número de Rastreio;
  stop
else (não)
  stop
endif
@enduml

Conceitos-Chave:

• Faixas de Navegação: Atribua cada ação à parte responsável (Cliente, Sistema, Armazém).
• Nós de Decisão: if/then/else/endif estruturas codificam cenários de ramificação.
• Marcadores de Início/Fim: Delimitam o início e o fim do processo.

---

Principais Lições do PlantUML

Para modelar efetivamente esta abordagem usando PlantUML, lembre-se dos seguintes elementos essenciais de sintaxe:

1. Diagramas de Casos de Uso:
   • Use usecase para funções.
   • Use ...> para <<include>>relacionamentos.
   • Use <... para <<extend>>relacionamentos.
   • Use rectangle "Nome do Sistema" {} para definir o limite do sistema.
2. Diagramas de Sequência:
   • Defina participantes usando ator, participante, ou banco de dados.
   • Use -> para chamadas síncronas e --> para respostas.
   • Use ativar e desativar para mostrar os ciclos de vida dos objetos.
   • Use alt, senão, e fim para fragmentos combinados que representam fluxos alternativos.
3. Diagramas de Atividade:
   • Use |#color|NomeDaFaixa| para definir faixas.
   • Use :action; para atividades.
   • Use if/else/endif para nós de decisão.
   • Use início e parada para marcar os limites do processo.

---

Conclusão

A Abordagem Orientada a Casos de Uso é mais do que apenas uma técnica de documentação; é um framework para refinamento progressivo. Ao começar com a visão geral (Diagrama de Casos de Uso) e aprofundando-se em comportamentos específicos (Fluxo de Eventos) e interações técnicas (Sequência/Diagramas de Atividade), as equipes podem garantir que cada linha de código remonte a uma necessidade de usuário verificada.

Este método reduz o risco de má comunicação entre as partes interessadas e os desenvolvedores, facilita testes mais simples por meio de cenários claros e resulta em um design de sistema robusto e centrado no usuário. Seja você estiver construindo uma plataforma simples de comércio eletrônico ou um sistema empresarial complexo, seguir essa progressão estruturada levará a requisitos mais claros e a um software de maior qualidade.