Estudio de caso: Diagrama de casos de uso para una plataforma de entrega de alimentos

Modelado de requisitos del mundo real con UML – Una guía práctica

---

1. Introducción

En el desarrollo de software moderno, diagramas de casos de uso son una herramienta fundamental para capturar los requisitos funcionales desde la perspectiva del usuario. Este estudio de caso presenta un análisis detallado de un diagrama de casos de uso realista para una plataforma de entrega de alimentos, utilizando sintaxis de PlantUML como lenguaje de modelado. El objetivo es demostrar no solo qué elementos se utilizan en el diagrama, sino también por qué se eligen — destacando decisiones prácticas de modelado, convenciones, y trampas comunes.

Este estudio de caso sirve tanto para principiantes que aprenden UML como para profesionales que perfeccionan sus prácticas de modelado. Descompone cada elemento del diagrama, explica su propósito y discute sus implicaciones en el mundo real.

---

2. Visión general del sistema

La plataforma de entrega de alimentoses una plataforma digital que conecta:

• Clientes (personas que ordenan comida),

• Restaurantes (proveedores de comidas),

• Conductores (personal de entrega),

• Pasarelas de pago externas (sistemas de terceros que gestionan transacciones).

La plataforma permite a los usuarios explorar restaurantes, realizar pedidos, rastrear entregas, gestionar pagos y aplicar promociones. El sistema se integra con servicios externos como procesadores de pagos y no gestiona la lógica de pagos internamente.

Código PlantUML:

@startuml
skinparam monochrome true
skinparam shadowing false

dirección de izquierda a derecha

‘ Todos los actores están definidos fuera del rectángulo
actor Cliente
actor “Cliente registrado” como RegCustomer
actor “Personal del restaurante” como Restaurant
actor Conductor
actor “Procesador de pagos” como PaymentGW

rectángulo “Plataforma de entrega de comida” {

(Explorar restaurantes)
(Hacer un pedido)
(Rastrear pedido)
(Gestionar menú)
(Aceptar / Preparar pedido)
(Entregar pedido)
(Procesar pago)
(Generar reembolso)
(Aplicar código promocional)
(Usar billetera)
(Pago con tarjeta)
(Pago con billetera digital)

‘ Asociaciones – las flechas cruzan el límite
Cliente –> (Explorar restaurantes)
Cliente registrado –> (Realizar pedido)
Cliente registrado –> (Rastrear pedido)

Restaurante –> (Gestionar menú)
Restaurante –> (Aceptar / Preparar pedido)

Conductor –> (Entregar pedido)

GW de pago –> (Procesar pago)
GW de pago –> (Generar reembolso)

‘ incluir
(Realizar pedido) ..> (Procesar pago) : <<incluir>>

‘ extender
(Realizar pedido) <.. (Aplicar código promocional) : <<extender>>
(Procesar pago) <.. (Usar billetera) : <<extender>>

‘ generalización
(Procesar pago) <|– (Pago con tarjeta)
(Procesar pago) <|– (Pago con billetera digital)
}

‘ Generalización de actor (también fuera)
Cliente <|– Cliente registrado

nota a la derecha de GW de pago
Pasarela de pago externa
(Stripe, PayPal, Adyen, …)
fin nota

nota abajo de (Aplicar código promocional)
Opcional – solo cuando se ingresa un código válido
nota final

@enduml

✅ Insight clave: El diagrama se centra en interacciones externas — muestra lo que el sistema hace para sus usuarios y sistemas, no en cómo está implementado.

---

3. Elementos del diagrama: Análisis profundo con significado práctico

A continuación se presenta un análisis completo de cada elemento UML utilizado en el diagrama, junto con su interpretación en el mundo real y la justificación del modelado.

#	Elemento	Notación	Significado y propósito	Decisión de modelado / Comentario
1	Límite del sistema	rectángulo "Plataforma de entrega de alimentos"	Define el alcance del sistema que se está modelando. Todos los casos de uso dentro son parte de este sistema.	El nombre es conciso pero descriptivo. En contextos empresariales, pueden usarse nombres más largos (por ejemplo, “Sistema de gestión de pedidos de clientes”).
2	Actor humano principal	actor Cliente, actor Repartidor	Representa roles externosque inician o participan en casos de uso.	Los nombres son simples e intuitivos. Evita estereotipos innecesarios como<<persona>>a menos que sea necesario para modelos grandes.
3	Actor con alias	actor "Personal del Restaurante" como Restaurante	Permite acortar un nombre de actor más largo y descriptivo para mejorar la claridad en las conexiones.	Altamente efectivo cuando los nombres de actores contienen espacios o son verbosos. Reduce el desorden y mejora la legibilidad.
4	Actor de sistema externo	actor "Procesador de Pagos" como PaymentGW	Modelasistemas de terceroscon los que interactúa la plataforma.	Sin estereotipo«sistema»se utiliza — aceptable en diagramas ligeros. Sin embargo, añadir«sistema»puede aclarar la intención en sistemas complejos.
5	Generalización de actor	`Cliente <	— ClienteRegistrado`	Indica que uncliente registradoes una versión especializada de uncliente invitado.
6	Asociación ordinaria	Cliente --> (Buscar restaurantes)	Muestra que el actoriniciaoparticipa enel caso de uso.	Línea sólida = comunicación. La dirección se infiere desde el actor hacia el caso de uso (no se necesita punta de flecha).
7	Relación «include»	(Colocar pedido) ..> (Procesar pago) : <<include>>	Procesar pagoessiempre necesariocuando se coloca un pedido.	La flecha apuntadesde incluyente → incluido. Esto es crítico:Colocar pedido incluye Procesar pagocomo un paso obligatorio.
8	Relación «extend»	(Colocar pedido) <.. (Aplicar código promocional) : <<extend>>	Aplicar un código promocional esopcionaly solo ocurre bajo ciertas condiciones.	La flecha apuntadesde extensión → base. El caso de uso base (Colocar Pedido) puede ser ampliado condicionalmente.
9	Generalización de Caso de Uso	`(Procesar Pago) <	— (Pago con Tarjeta)<br>(Procesar Pago) <	— (Pago con Billetera Digital)`
10	Nota	nota a la derecha de PaymentGW nota en la parte inferior de (Aplicar Código Promocional)	Proporciona explicación contextual sobre implementación o reglas de negocio.	Las notas son subutilizadas pero extremadamente valiosas. Evitan malentendidos (por ejemplo, aclarando que PaymentGW es externo).
11	Actores Fuera del Límite	Todos actor declaraciones preceden al rectángulo	Enfatiza que ningún actor forma parte del sistema — separación clara de responsabilidades.	Uno de dos diseños estándar. Preferido cuando hay muchos actores o son externos.
12	Dirección del diagrama	dirección de izquierda a derecha	Mejora el diseño cuando hay múltiples actores a la izquierda.	Mejora la legibilidad. Especialmente efectivo con 4 a 8 actores. Alternativa: diseño de arriba hacia abajo para menos actores.

---

4. Decisiones clave de modelado y justificación

✅ Por qué los actores están fuera del límite del sistema

• Mejor práctica: Los actores representan rolesfueradel sistema.

• Por qué importa: Evita la confusión entre los componentes del sistema y las entidades externas.

• Ejemplo: Conductorno es un módulo de la plataforma — son un rol de terceros que interactúa con ella.

📌 Consejo profesional: Si todos los actores estuvieran dentro del límite, se interpretaría que el sistema los incluye — lo cual sería engañoso.

---

✅ ¿Por qué usar Cliente <|-- ClienteRegistradoen lugar de duplicar enlaces

• Sin generalización, tendrías que dibujar:

  Cliente --> (Buscar Restaurantes)
  ClienteRegistrado --> (Buscar Restaurantes)
  ClienteRegistrado --> (Hacer Pedido)
  

• Con generalización, solo necesitas:

  Cliente <|-- ClienteRegistrado
  Cliente --> (Buscar Restaurantes)
  ClienteRegistrado --> (Hacer Pedido)
  

• Resultado: Diagrama más limpio y fácil de mantener.

📌 Mejor práctica: Utilice la generalización de actores siempre que un actor especializado herede todos los comportamientos de uno más general.

---

✅ ¿Por qué <<incluir>> y <<extender>> se utilizan correctamente

Relación	Propósito	Dirección	Ejemplo
<<incluir>>	Subflujo obligatorio	Desde incluyendo → incluido	Colocar pedido debe incluir Procesar pago
<<extender>>	Extensión opcional	Desde extensión → base	Aplicar código promocional extiende Colocar pedido solo si el código es válido

❗ Error común: Invertir la dirección de la flecha. Siempre recuerda:

• incluir: Base ..> Incluido

• extender: Extensión <.. Base

---

✅ ¿Por qué Procesar pago tiene generalizaciones

• Pago con tarjeta y Pago con billetera digital son formas especializadas de Procesar pago.

• Esto muestra que la plataforma admite múltiples métodos de pago, pero todos siguen el mismo flujo principal.

• La generalización permite comportamiento compartido y extensibilidad futura.

📌 Casos de uso: Agregar un nuevo método de pago (por ejemplo, Apple Pay) sería simplemente otra generalización de Procesar pago.

---

5. Interpretaciones del mundo real y preguntas respondidas

Este diagrama no es solo una ayuda visual — responde preguntas críticas de negocio y técnicas:

Pregunta	Respuesta del diagrama
¿Quiénes son los usuarios principales?	Clientes, Clientes registrados, Personal del restaurante, Repartidores, Pasarela de pago
¿Pueden los usuarios no registrados realizar pedidos?	❌ No — solo Cliente registrado puede Realizar pedido. Cliente puede solo Explorar restaurantes.
¿Se requiere siempre el pago?	✅ Sí — Realizar pedido incluye Procesar pago. Obligatorio.
¿Los clientes pueden aplicar códigos promocionales?	✅ Sí — pero soloopcionalmente a través de <<extender>>. Solo si se ingresa un código válido.
¿Qué métodos de pago están soportados?	Tarjeta y billetera digital (a través de generalización). El sistema externo maneja el procesamiento real.
¿Quién maneja el pago?	ExternoPaymentGW — no forma parte de la plataforma.
¿Pueden los restaurantes gestionar sus menús?	✅ Sí —Restaurante el actor interactúa con Gestionar menú y Aceptar / Preparar pedido.

✅ Valor empresarial: El diagrama comunica claramentequé hace el sistema, quién lo utiliza, yqué comportamientos son obligatorios frente a opcionales.

---

6. Guías comunes de modelado demostradas

El diagrama ejemplifica varias buenas prácticas en el modelado de casos de uso de UML:

Guía	Cómo se aplica
Utilice nombres de casos de uso orientados a objetivos	Colocar pedido, Rastrear pedido, Aplicar código promocional — todos comienzan con un verbo y describen un objetivo del usuario.
Mantenga el diagrama legible	Solo 10 casos de uso se muestran — ideal para la mayoría de los dominios empresariales (se recomienda 5–12).
Sistemas externos como actores	PaymentGW se modela como un actor, no como un caso de uso. Separa correctamente las responsabilidades.
Utilice notas para aclarar ambigüedades	Las notas explican que PaymentGW es externo y que el código promocional es opcional — crítico para evitar malentendidos.
Utilice la generalización de actores para reducir el desorden	`Cliente <
Utilice incluir y extender correctamente	Clara distinción entre el comportamiento obligatorio y el opcional.

📌 Advertencia: Muchos diagramas mal utilizan <<extend>> para significar “opcional” sin comprender la naturaleza condicional de las extensiones. Este diagrama evita ese error.

---

7. Mejoras potenciales y crítica

Aunque el diagrama es sólido, aquí hay sugerencias constructivas para su refinamiento:

🔧 1. Agregar estereotipos para claridad

actor "Procesador de Pagos" como PaymentGW <<sistema>>

• Por qué: Hace explícito que se trata de un sistema externo, no de un rol humano.

• Beneficio: Reduce la ambigüedad, especialmente en modelos grandes.

🔧 2. Aclarar Aplicar código promocional Condición de extensión

Actualmente:

nota abajo de (Aplicar código promocional)
  Opcional – solo cuando se ingresa un código válido
fin nota

• Mejor: Utilice una notación de condición o guardar en el <<extender>> flecha:

(Colocar pedido) <.. (Aplicar código promocional) : <<extender>> [código promocional válido]

• ¿Por qué: Más preciso que una nota — enlaza directamente la extensión con una condición.

🔧 3. Considera agregar un Ver historial de pedidos caso de uso

• Actualmente faltante, pero probablemente importante para clientes y restaurantes.

• Podría agregarse como un Cliente registrado caso de uso.

🔧 4. Agrupa casos de uso relacionados (opcional)

Para diagramas más grandes, agrupa los casos de uso en paquetes:

paquete "Gestión de pedidos" {
    (Colocar pedido)
    (Rastrear pedido)
    (Aplicar código promocional)
}
paquete "Pago" {
    (Procesar pago)
    (Usar billetera)
    (Pago con tarjeta)
    (Pago con billetera digital)
}

• Beneficio: Mejora la escalabilidad y legibilidad.

---

8. ¿Qué sigue?

Este estudio de caso ha mostrado cómo un diagrama de casos de uso bien estructurado puede capturar la lógica empresarial compleja de forma clara y concisa. Para profundizar tu comprensión, aquí tienes pasos siguientes sugeridos:

🔄 Opción 1: Vista centrada en el restaurante

Modelar el mismo dominio desde el perspectiva del restaurante:

• Enfocarse en Gestionar el menú, Aceptar / Preparar pedido, Ver pedidos, Actualizar estado.

• Mostrar Restaurante como actor principal.

• Incluir Cliente como actor secundario (por ejemplo, Cliente envía pedido → Restaurante lo recibe).

✅ Beneficio: Revela objetivos del sistema y roles de los actores diferentes.

🔄 Opción 2: Agregar más puntos de extensión

Mejorar Realizar pedido con:

• Aplicar cupón (si el código promocional es inválido → <<extender>> con mensaje de error)

• Solicitar instrucciones especiales (opcional)

• Programar pedido (para entrega futura)

🔄 Opción 3: Comparar incluir vs extender con ejemplos

Casos de uso	<<incluir>>	<<extender>>
Colocar pedido → Procesar pago	✅ Obligatorio	❌ No es opcional
Colocar pedido → Aplicar código promocional	❌ No es obligatorio	✅ Condicionado
Iniciar sesión → Verificar identidad	✅ Siempre necesario	❌ No aplicable
Finalizar compra → Aplicar descuento	✅ Siempre	✅ Solo si existe un descuento

📌 Regla general:

• Usar <<incluir>> cuando el comportamiento debe ocurrir.

• Usar <<extender>> cuando el comportamiento podría ocurrir bajo ciertas condiciones.

🔄 Opción 4: Convertir a diagramas de secuencia o de actividad

Para un análisis más profundo:

• Diagrama de secuencia: Mostrar el flujo de Colocar pedido → Procesar pago → Entregar pedido con mensajes entre actores y sistema.

• Diagrama de actividad: Modelar los puntos de decisión en Procesar pago (por ejemplo, tarjeta rechazada → reintento o cambio al monedero).

---

9. Conclusión

Este estudio de caso demuestra que un diagrama de casos de uso bien elaborado es mucho más que un bosquejo visual — es una herramienta estratégica de comunicación que:

• Aclara el alcance del sistema,

• Captura las reglas de negocio,

• Guía el desarrollo,

• Evita malentendidos.

El Plataforma de entrega de alimentos diagrama es un ejemplo sólido de:

• Uso adecuado de la notación UML,

• Decisiones de modelado sólidas,

• Separación clara de responsabilidades,

• Uso efectivo de notas y generalizaciones.

Siguiendo los principios mostrados aquí — nomenclatura orientada a objetivos, uso correcto de incluir/extender, generalización de actores, y uso estratégico de notas — puedes crear diagramas de casos de uso que sean ambos precisosy accionables.

---

✅ Conclusiones finales

Principio	¿Aplicado aquí?	¿Por qué es importante?
Utiliza nombres de casos de uso orientados a objetivos	✅ Sí	Mejora la claridad y el enfoque del usuario
Mantén el tamaño del diagrama manejable	✅ Sí (10 casos de uso)	Evita la sobrecarga cognitiva
Sistemas externos como actores	✅ Sí	Separación correcta de responsabilidades
Utiliza notas para contexto	✅ Sí	Evita malentendidos
Utiliza generalización para reducir la redundancia	✅ Sí	Hace que el diagrama sea escalable y mantenible
Correcto <<incluir>> y <<extender>> dirección	✅ Sí	Garantiza un modelado preciso del comportamiento

---