Estudo de Caso: Diagrama de Casos de Uso para uma Plataforma de Entrega de Alimentos

Modelagem de Requisitos do Mundo Real com UML – Um Guia Prático

1. Introdução

No desenvolvimento de software moderno, diagramas de casos de usosão uma ferramenta fundamental para capturar requisitos funcionais sob a perspectiva do usuário. Este estudo de caso apresenta uma análise detalhada de um diagrama de casos de uso realistapara uma Plataforma de Entrega de Alimentos, utilizando sintaxe PlantUMLcomo linguagem de modelagem. O objetivo é demonstrar não apenas quais elementos são usados no diagrama, mas também por que eles são escolhidos — destacando decisões práticas de modelagem, convenções, e armadilhas comuns.

Este estudo de caso serve tanto para iniciantes aprendendo UML quanto para praticantes refinando suas práticas de modelagem. Ele decompõe cada elemento do diagrama, explica seu propósito e discute implicações do mundo real.

2. Visão Geral do Sistema

A Plataforma de Entrega de Alimentos é um mercado digital que conecta:

• Clientes(indivíduos que fazem pedidos de comida),
• Restaurantes(provedores de refeições),
• Entregadores(pessoal de entrega),
• Gateways de Pagamento Externos(sistemas de terceiros que processam transações).

A plataforma permite aos usuários navegar por restaurantes, fazer pedidos, rastrear entregas, gerenciar pagamentos e aplicar promoções. O sistema integra-se com serviços externos, como processadores de pagamento, e não lida com a lógica de pagamento internamente.

Código PlantUML:

@startuml
skinparam monochrome true
skinparam shadowing false

left to right direction

' Todos os atores são definidos fora do retângulo
actor Cliente
actor "Cliente Cadastrado" as RegCliente
actor "Funcionário do Restaurante" as Restaurante
actor Entregador
actor "Processador de Pagamento" as GatewayPagamento

rectangle "Plataforma de Entrega de Comida" {

(Navegar por Restaurantes)
(Fazer Pedido)
(Rastrear Pedido)
(Gerenciar Cardápio)
(Aceitar / Preparar Pedido)
(Entregar Pedido)
(Processar Pagamento)
(Emitir Reembolso)
(Aplicar Código Promocional)
(Usar Carteira)
(Pagamento com Cartão)
(Pagamento com Carteira Digital)

' Associações – setas cruzam a fronteira
Cliente --> (Navegar por Restaurantes)
RegCliente --> (Fazer Pedido)
RegCliente --> (Rastrear Pedido)

Restaurante --> (Gerenciar Cardápio)
Restaurante --> (Aceitar / Preparar Pedido)

Entregador --> (Entregar Pedido)

GatewayPagamento --> (Processar Pagamento)
GatewayPagamento --> (Emitir Reembolso)

' include
(Fazer Pedido) ..> (Processar Pagamento) : <<include>>

' extend
(Fazer Pedido) <.. (Aplicar Código Promocional) : <<extend>>
(Processar Pagamento) <.. (Usar Carteira) : <<extend>>

' generalização
(Processar Pagamento) <|-- (Pagamento com Cartão)
(Processar Pagamento) <|-- (Pagamento com Carteira Digital)
}

' Generalização de atores (também fora)
Cliente <|-- RegCliente

note right of GatewayPagamento
Gateway de pagamento externo
(Stripe, PayPal, Adyen, ...)
end note

note bottom of (Aplicar Código Promocional)
Opcional – apenas quando um código válido é inserido
end note

@enduml

✅ Insight Principal: O diagrama foca em interações externas — mostra o que o sistema faz para seus usuários e sistemas, não como é implementado.

3. Elementos do Diagrama: Análise Profunda com Significado Prático

Abaixo está uma análise abrangente de cada elemento UML usado no diagrama, juntamente com interpretação do mundo real e justificativa de modelagem.

4. Decisões Principais de Modelagem e Justificativa

✅ Por que os atores estão fora do limite do sistema

• Melhor prática: Os atores representam papéis forado sistema.
• Por que importa: Evita confusão entre componentes do sistema e entidades externas.
• Exemplo: Motorista não é um módulo da plataforma — são um papel de terceiros interagindo com ela.

📌 Dica Profissional: Se todos os atores estivessem dentro do limite, isso implicaria que o sistema os inclui — o que é enganoso.

✅ Por que usar Customer <|-- RegCustomer em vez de duplicar links

• Sem generalização, você teria que desenhar:
  PlantUML
  
  
  Editar PlantUML no VPasCode
  

  PlantUML Edit PlantUML in VPasCode

  Customer --> (Navegar em Restaurantes)
  RegCustomer --> (Navegar em Restaurantes)
  RegCustomer --> (Fazer Pedido)
  

  Edit PlantUML in VPasCode

  
  
  Editar PlantUML no VPasCode
  
• Com generalização, você só precisa:
  PlantUML
  
  
  Editar PlantUML no VPasCode
  

  PlantUML Edit PlantUML in VPasCode

  Customer <|-- RegCustomer
  Customer --> (Navegar em Restaurantes)
  RegCustomer --> (Fazer Pedido)
  

  Edit PlantUML in VPasCode

  
  
  Editar PlantUML no VPasCode
  
• Resultado: Diagrama mais limpo e mais fácil de manter.

📌 Melhor Prática: Use generalização de atores sempre que um ator especializado herdar todos os comportamentos de um ator mais geral.

✅ Por que <<include>> e <<extend>> são usados corretamente

❗ Erro Comum: Inverter a direção da seta. Sempre lembre-se:

• incluir: Base ..> Incluído
• estender: Extensão <.. Base

✅ Por que Processar Pagamento possui generalizações

• Pagamento com Cartão e Pagamento com Carteira Digital são formas especializadas de Processar Pagamento.
• Isso mostra que a plataforma suporta múltiplos métodos de pagamento, mas todos seguem o mesmo fluxo principal.
• A generalização permite comportamento compartilhado e extensibilidade futura.

📌 Caso de Uso: Adicionar um novo método de pagamento (por exemplo, Apple Pay) seria apenas mais uma generalização de Processar Pagamento.

5. Interpretações do Mundo Real & Perguntas Respondidas

Este diagrama não é apenas uma ajuda visual — ele responde a perguntas críticas de negócios e técnicas:

✅ Valor de Negócio: O diagrama comunica claramente o que o sistema faz, quem o usa, e quais comportamentos são obrigatórios versus opcionais.

6. Diretrizes Comuns de Modelagem Demonstradas

O diagrama exemplifica várias melhores práticas na modelagem de casos de uso UML:

📌 Aviso: Muitos diagramas usam incorretamente <<extend>> para significar “opcional” sem compreender a natureza condicionaldas extensões. Este diagrama evita esse erro.

7. Melhorias Potenciais e Crítica

Embora o diagrama seja robusto, aqui estão sugestões construtivas para refinamento:

🔧 1. Adicionar Estereótipos para Clareza

ator "Processador de Pagamento" como PaymentGW <<sistema>>

• Por quê: Torna explícito que se trata de um sistema externo, não de um papel humano.
• Benefício: Reduz ambiguidades, especialmente em modelos grandes.

🔧 2. Esclarecer Aplicar Código PromocionalCondição de Extensão

Atualmente:

nota na parte inferior de (Aplicar Código Promocional)
  Opcional – apenas quando um código válido for inserido
fim da nota

• Melhor: Use uma notação de condição ou guarda na <<extend>> seta:

(Fazer Pedido) <.. (Aplicar Código Promocional) : <<extend>> [código promocional válido]

• Por quê: Mais preciso que uma nota — vincula diretamente a extensão a uma condição.

🔧 3. Considere adicionar um Ver Histórico de Pedidos Caso de Uso

• Atualmente ausente, mas provavelmente importante tanto para clientes quanto para restaurantes.
• Poderia ser adicionado como um Cliente Registrado caso de uso.

🔧 4. Agrupar Casos de Uso Relacionados (Opcional)

Para diagramas maiores, agrupe os casos de uso em pacotes:

package "Gestão de Pedidos" {
    (Fazer Pedido)
    (Rastrear Pedido)
    (Aplicar Código Promocional)
}
package "Pagamento" {
    (Processar Pagamento)
    (Usar Carteira)
    (Pagamento com Cartão)
    (Pagamento com Carteira Digital)
}

• Benefício: Melhora a escalabilidade e a legibilidade.

8. Qual o Próximo Passo?

Este estudo de caso demonstrou como um diagrama de casos de uso bem estruturado pode capturar lógica de negócios complexa de forma clara e concisa. Para aprofundar seu entendimento, aqui estão próximos passos sugeridos:

🔄 Opção 1: Visão Centrada no Restaurante

Modele o mesmo domínio a partir do perspectiva do restaurante:

• Foque em Gerenciar Cardápio, Aceitar / Preparar Pedido, Visualizar Pedidos, Atualizar Status.
• Mostrar Restaurante como ator principal.
• Incluir Cliente como ator secundário (por exemplo, Cliente envia pedido → Restaurante o recebe).

✅ Benefício: Revela diferentes objetivos do sistema e papéis dos atores.

🔄 Opção 2: Adicionar Mais Pontos de Extensão

Melhore Fazer Pedido com:

• Aplicar Cupom (se o código promocional for inválido → <<extend>> com mensagem de erro)
• Solicitar Instruções Especiais (opcional)
• Agendar Pedido (para entrega futura)

🔄 Opção 3: Comparar incluir vs estender com Exemplos

📌 Regra Geral:

• Use <<include>> quando o comportamento deve ocorrer.
• Use <<extend>> quando o comportamento pode ocorrer sob certas condições.

🔄 Opção 4: Converter para Diagramas de Sequência ou de Atividade

Para uma análise mais profunda:

• Diagrama de Sequência: Mostrar o fluxo de Registrar Pedido → Processar Pagamento → Entregar Pedido com mensagens entre atores e sistema.
• Diagrama de Atividade: Modelar os pontos de decisão em Processar Pagamento (ex.: cartão recusado → tentar novamente ou alternar para carteira).

9. Conclusão

Este estudo de caso demonstra que um diagrama de casos de uso bem elaborado é muito mais do que um esboço visual — é um ferramenta estratégica de comunicação que:

• Clarifica o escopo do sistema,
• Captura as regras de negócio,
• Orienta o desenvolvimento,
• Previne mal-entendidos.

O Plataforma de Entrega de Alimentos diagrama é um exemplo sólido de:

• Uso adequado da notação UML,
• Decisões de modelagem sólidas,
• Separação clara de preocupações,
• Uso eficaz de notas e generalizações.

Ao seguir os princípios apresentados aqui — nomenclatura orientada a objetivos, uso correto de incluir/estender, generalização de ator, e uso estratégico de notas — você pode criar diagramas de caso de uso que são tanto precisos e acionáveis.

✅ Conclusões Finais