Estudo de Caso: Diagrama de Caso 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 uso são uma ferramenta fundamental para capturar requisitos funcionais do ponto de vista do usuário. Este estudo de caso apresenta uma análise detalhada de um diagrama de casos de uso realista para uma Plataforma de Entrega de Alimentos, usando sintaxe PlantUML como linguagem de modelagem. O objetivo é demonstrar não apenas o que elementos são utilizados 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 como para profissionais aprimorando suas práticas de modelagem. Ele analisa cada elemento do diagrama, explica seu propósito e discute implicações no mundo real.

---

2. Visão Geral do Sistema

A Plataforma de Entrega de Alimentosé uma plataforma digital que conecta:

• Clientes (pessoas que pedem comida),

• Restaurantes (fornecedores de refeições),

• Motoristas (pessoal de entrega),

• Gateways de Pagamento Externos (sistemas de terceiros que gerenciam transações).

A plataforma permite que os usuários naveguem por restaurantes, faça pedidos, acompanhem entregas, gerenciem pagamentos e apliquem promoções. O sistema integra-se a serviços externos, como processadores de pagamento, e não gerencia a lógica de pagamento internamente.

Código PlantUML:

@startuml
skinparam monochrome true
skinparam shadowing false

direção da esquerda para a direita

‘ Todos os atores são definidos fora do retângulo
ator Cliente
ator “Cliente Registrado” como RegCliente
ator “Equipe do Restaurante” como Restaurante
ator Motorista
ator “Processador de Pagamento” como PaymentGW

retângulo “Plataforma de Entrega de Comida” {

(Navegar por Restaurantes)
(Fazer Pedido)
(Acompanhar 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)
Cliente Registrado –> (Fazer Pedido)
Cliente Registrado –> (Rastrear Pedido)

Restaurante –> (Gerenciar Menu)
Restaurante –> (Aceitar / Preparar Pedido)

Motorista –> (Entregar Pedido)

Gateway de Pagamento –> (Processar Pagamento)
Gateway de Pagamento –> (Emitir Reembolso)

‘ incluir
(Fazer Pedido) ..> (Processar Pagamento) : <<incluir>>

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

‘ generalização
(Processar Pagamento) <|– (Pagamento com Cartão)
(Processar Pagamento) <|– (Pagamento com Carteira Digital)
}

‘ Generalização de Ator (também fora)
Cliente <|– Cliente Registrado

nota à direita de Gateway de Pagamento
Gateway de pagamento externo
(Stripe, PayPal, Adyen, …)
fim da nota

nota abaixo de (Aplicar Código Promocional)
Opcional – apenas quando um código válido for inserido
nota final

@enduml

✅ Ponto-chave: O diagrama se concentra em interações externas — ele mostra o que o sistema faz para seus usuários e sistemas, e não como ele é implementado.

---

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

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

#	Elemento	Notação	Significado e Propósito	Decisão de Modelagem / Comentário
1	Fronteira do Sistema	retângulo "Plataforma de Entrega de Comida"	Define o escopo do sistema sendo modelado. Todos os casos de uso dentro são parte deste sistema.	O nome é conciso, mas descritivo. Em contextos empresariais, nomes mais longos (por exemplo, “Sistema de Gestão de Pedidos de Clientes”) podem ser usados.
2	Ator Humano Principal	ator Cliente, ator Motorista	Representa papéis externosque iniciam ou participam de casos de uso.	Os nomes são simples e intuitivos. Evita estereótipos desnecessários como<<pessoa>>a menos que necessário para modelos grandes.
3	Ator com Apelido	ator "Funcionários do Restaurante" como Restaurante	Permite que um nome de ator mais longo e descritivo seja abreviado para clareza nas conexões.	Altamente eficaz quando os nomes de atores contêm espaços ou são verbosos. Reduz o acúmulo de elementos e melhora a legibilidade.
4	Ator de Sistema Externo	ator "Processador de Pagamentos" como PaymentGW	Modelasistemas de terceiroscom os quais a plataforma interage.	Sem estereótipo«sistema»é usado — aceitável em diagramas leves. No entanto, adicionar«sistema»pode esclarecer a intenção em sistemas complexos.
5	Generalização de Ator	`Cliente <	— ClienteRegistrado`	Indica que umcliente registradoé uma versão especializada de umcliente convidado.
6	Associação Comum	Cliente --> (Navegar por Restaurantes)	Mostra que o atoriniciaouparticipa noo caso de uso.	Linha contínua = comunicação. A direção é implícita do ator para o caso de uso (não é necessário ponta de seta).
7	Relação «include»	(Fazer Pedido) ..> (Processar Pagamento) : <<include>>	Processar Pagamentoésempre necessárioquando fazer um pedido.	A seta apontado incluindo → incluído. Isso é crítico:Fazer Pedido inclui Processar Pagamentocomo uma etapa obrigatória.
8	Relação «extend»	(Fazer Pedido) <.. (Aplicar Código Promocional) : <<extend>>	Aplicar um código promocional éopcionale só ocorre sob certas condições.	A seta apontada extensão → base. O caso de uso básico (Efetuar Pedido) pode ser estendido condicionalmente.
9	Generalização de Caso de Uso	`(Processar Pagamento) <	— (Pagamento com Cartão)<br>(Processar Pagamento) <	— (Pagamento com Carteira Digital)`
10	Nota	nota à direita de PaymentGW nota na parte inferior de (Aplicar Código Promocional)	Fornece explicação contextual sobre implementação ou regras de negócios.	As notas são subutilizadas mas extremamente valiosas. Elas evitam mal-entendidos (por exemplo, esclarecendo que o PaymentGW é externo).
11	Ator Fora do Limite	Todos ator declarações antecedem o retângulo	Enfatiza que nenhum ator faz parte do sistema — separação clara de responsabilidades.	Um dos dois layouts padrão. Preferido quando os atores são numerosos ou externos.
12	Direção do Diagrama	direção da esquerda para a direita	Melhora o layout quando múltiplos atores estão à esquerda.	Melhora a legibilidade. Especialmente eficaz com 4 a 8 atores. Alternativa: layout de cima para baixo para menos atores.

---

4. Decisões-Chave de Modelagem e Racional

✅ Por que os atores estão fora da fronteira do sistema

• Melhor prática: Os atores representam papéisforado sistema.

• Por que isso importa: Evita a confusão entre componentes do sistema e entidades externas.

• Exemplo: Motoristanão é um módulo da plataforma — eles são um papel de terceiros interagindo com ela.

📌 Dica Profissional: Se todos os atores estivessem dentro da fronteira, isso implicaria que o sistema os inclui — o que seria enganoso.

---

✅ Por que usarCustomer <|-- RegCustomerem vez de duplicar os links

• Sem generalização, você teria que desenhar:

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

• Com generalização, você precisa apenas de:

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

• Resultado: Diagrama mais limpo e mais fácil de manter.

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

---

✅ Por que <<incluir>> e <<estender>> são usados corretamente

Relacionamento	Propósito	Direção	Exemplo
<<incluir>>	Sub-fluxo obrigatório	De incluindo → incluído	Fazer Pedido deve incluir Processar Pagamento
<<estender>>	Extensão opcional	De extensão → base	Aplicar Código Promocional estende Colocar Pedido apenas se o código for válido

❗ Erro Comum: Invertendo a direção da seta. Lembre-se sempre:

• inclui: Base ..> Incluído

• estender: Extensão <.. Base

---

✅ Por que Processar Pagamento tem 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últios 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 outra generalização de Processar Pagamento.

---

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

Este diagrama não é apenas um auxílio visual — ele responde perguntas críticas de negócios e técnicas:

Pergunta	Resposta do Diagrama
Quais são os principais usuários?	Clientes, Clientes Registrados, Funcionários do Restaurante, Motoristas, Gateway de Pagamento
Usuários não registrados podem fazer pedidos?	❌ Não — apenas ClienteRegistrado pode Fazer Pedido. Cliente pode apenas Navegar por Restaurantes.
O pagamento é sempre necessário?	✅ Sim — Fazer Pedido inclui Processar Pagamento. Obrigatório.
Os clientes podem aplicar códigos promocionais?	✅ Sim — mas apenasopcionalmentevia<<expandir>>. Apenas se um código válido for inserido.
Quais métodos de pagamento são suportados?	Cartão e Carteira Digital (via generalização). O sistema externo realiza o processamento real.
Quem gerencia o pagamento?	ExternoPaymentGW— não faz parte da plataforma.
Os restaurantes podem gerenciar seus cardápios?	✅ Sim —Restauranteator interage comGerenciar CardápioeAceitar / Preparar Pedido.

✅ Valor de Negócio: O diagrama comunica claramenteo que o sistema faz, quem o utiliza, equais comportamentos são obrigatórios em vez de opcionais.

---

6. Orientações Comuns de Modelagem Demonstradas

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

Orientação	Como é Aplicado
Use nomes de casos de uso orientados a objetivos	Colocar Pedido, Rastrear Pedido, Aplicar Código Promocional — todos começam com um verbo e descrevem um objetivo do usuário.
Mantenha o diagrama legível	Apenas 10 casos de uso são mostrados — ideal para a maioria dos domínios empresariais (recomendado entre 5–12).
Sistemas externos como atores	PaymentGW é modelado como um ator, não como um caso de uso. Separa corretamente as responsabilidades.
Use notas para esclarecer ambiguidades	As notas explicam que PaymentGW é externo e que o código promocional é opcional — essencial para evitar mal-entendidos.
Use a generalização de atores para reduzir o acúmulo	`Cliente <
Use inclua e estenda corretamente	Distinção clara entre comportamento obrigatório e opcional.

📌 Aviso: Muitos diagramas mal utilizam <<extend>> para significar “opcional” sem compreender o natureza condicional das extensões. Este diagrama evita esse erro.

---

7. Melhorias Potenciais e Crítica

Embora o diagrama seja forte, aqui estão sugestões construtivas para aprimoramento:

🔧 1. Adicione estereótipos para clareza

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

• Por que: Deixa claro que se trata de um sistema externo, e não de um papel humano.

• Benefício: Reduz a ambiguidade, especialmente em modelos grandes.

🔧 2. Esclareça Aplicar Código Promocional Condiçã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 um notação de condição ou guarda no <<estender>> seta:

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

• Por que: Mais preciso do que uma nota — liga diretamente a extensão a uma condição.

🔧 3. Considere Adicionar um Visualizar Histórico de Pedidos Caso de Uso

• Atualmente ausente, mas provavelmente importante para clientes e restaurantes.

• Poderia ser adicionado como um RegCliente caso de uso.

🔧 4. Agrupe Casos de Uso Relacionados (Opcional)

Para diagramas maiores, agrupe casos de uso em pacotes:

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

• Benefício: Melhora a escalabilidade e legibilidade.

---

8. O que vem a seguir?

Este estudo de caso mostrou como um diagrama de casos de uso bem estruturado pode capturar logicamente e concisamente lógica de negócios complexa. 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.

• Inclua Cliente como ator secundário (por exemplo, Cliente envia pedido → Restaurante recebe-o).

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

🔄 Opção 2: Adicionar mais pontos de extensão

Melhore Fazer Pedido com:

• Aplicar Cupom (se o código promocional for inválido → <<expandir>> com mensagem de erro)

• Solicitar Instruções Especiais (opcional)

• Agendar Pedido (para entrega futura)

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

Caso de Uso	<<incluir>>	<<expandir>>
Fazer Pedido → Processar Pagamento	✅ Obrigatório	❌ Não é opcional
Fazer Pedido → Aplicar Código Promocional	❌ Não é obrigatório	✅ Condicional
Entrar → Verificar Identidade	✅ Sempre necessário	❌ Não aplicável
Finalizar Compra → Aplicar Desconto	✅ Sempre	✅ Apenas se o desconto existir

📌 Regra de Ouro:

• Use <<incluir>> quando o comportamento deve acontecer.

• Use <<estender>> quando o comportamento pode acontecer em certas condições.

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

Para uma análise mais aprofundada:

• Diagrama de Sequência: Mostrar o fluxo de Colocar Pedido → Processar Pagamento → Entregar Pedido com mensagens entre atores e sistema.

• Diagrama de Atividade: Modelar os pontos de decisão em Processar Pagamento (por exemplo, cartão recusado → tentar novamente ou alternar para carteira).

---

9. Conclusão

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

• Define o escopo do sistema,

• Captura regras de negócios,

• Orienta o desenvolvimento,

• Evita 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,

• Clara separação de responsabilidades,

• Uso eficaz de notas e generalizações.

Ao seguir os princípios mostrados aqui — nomenclatura orientada a objetivos, uso correto de include/estender, generalização de ator, e uso estratégico de notas — você pode criar diagramas de casos de uso que são ambos precisose acessíveis.

---

✅ Conclusões Finais

Princípio	Aplicado Aqui?	Por que isso importa
Use nomes de casos de uso orientados a objetivos	✅ Sim	Melhora a clareza e o foco do usuário
Mantenha o tamanho do diagrama gerenciável	✅ Sim (10 casos de uso)	Evita sobrecarga cognitiva
Sistemas externos como atores	✅ Sim	Separação correta de preocupações
Use notas para contexto	✅ Sim	Evita mal-entendidos
Use generalização para reduzir redundância	✅ Sim	Torna o diagrama escalável e passível de manutenção
Corrigir <<incluir>> e <<estender>> direção	✅ Sim	Garante a modelagem precisa do comportamento

---