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, los diagramas de casos de uso son una herramienta fundamental para capturar 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 la 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 de modelado prácticas, convenciones, y errores comunes.

Este estudio de caso sirve tanto a principiantes que aprenden UML como a practicantes que perfeccionan sus prácticas de modelado. Desglosa cada elemento del diagrama, explica su propósito y discute las implicaciones del mundo real.

2. Descripción general del sistema

La plataforma de entrega de alimentos es un mercado digital que conecta:

• Clientes(personas que piden comida),
• Restaurantes(proveedores de comidas),
• Repartidores(personal de reparto),
• Pasarelas de pago externas(sistemas de terceros que gestionan transacciones).

La plataforma permite a los usuarios navegar por 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 pago internamente.

Código PlantUML:

@startuml
skinparam monochrome true
skinparam shadowing false

left to right direction

' Todos los actores se definen fuera del rectángulo
actor Cliente
actor "Cliente Registrado" as RegCliente
actor "Personal del Restaurante" as Restaurante
actor Repartidor
actor "Procesador de Pagos" as PasarelaPago

rectángulo "Plataforma de Entrega de Comida" {

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

' Asociaciones – las flechas cruzan el límite
Cliente --> (Navegar por restaurantes)
RegCliente --> (Hacer pedido)
RegCliente --> (Rastrear pedido)

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

Repartidor --> (Entregar pedido)

PasarelaPago --> (Procesar pago)
PasarelaPago --> (Emitir reembolso)

' incluir
(Hacer pedido) ..> (Procesar pago) : <<incluir>>

' extender
(Hacer 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 actores (también fuera)
Cliente <|-- RegCliente

nota derecha de PasarelaPago
Pasarela de pago externa
(Stripe, PayPal, Adyen, ...)
fin nota

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

@enduml

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

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

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

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 roles fueradel sistema.
• Por qué es importante: Evita la confusión entre componentes del sistema y entidades externas.
• Ejemplo: Conductor no 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, implicaría que el sistema los incluye, lo cual es engañoso.

✅ ¿Por qué usar Customer <|-- RegCustomer en lugar de duplicar enlaces

• Sin generalización, tendrías que dibujar:
  PlantUML
  
  
  Editar PlantUML en VPasCode
  

  PlantUML Edit PlantUML in VPasCode

  Customer --> (Explorar restaurantes)
  RegCustomer --> (Explorar restaurantes)
  RegCustomer --> (Realizar pedido)
  

  Edit PlantUML in VPasCode

  
  
  Editar PlantUML en VPasCode
  
• Con generalización, solo necesitas:
  PlantUML
  
  
  Editar PlantUML en VPasCode
  

  PlantUML Edit PlantUML in VPasCode

  Customer <|-- RegCustomer
  Customer --> (Explorar restaurantes)
  RegCustomer --> (Realizar pedido)
  

  Edit PlantUML in VPasCode

  
  
  Editar PlantUML en VPasCode
  
• Resultado: Diagrama más limpio y más fácil de mantener.

📌 Mejor práctica: Utiliza 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

❗ Error común: Invertir la dirección de la flecha. Recuerde siempre:

• 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 central.
• La generalización permite comportamiento compartido y extensibilidad futura.

📌 Caso 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:

✅ Valor Empresarial: El diagrama comunica claramente qué hace el sistema, quién lo usa, y qué comportamientos son obligatorios frente a opcionales.

6. Directrices de modelado comunes demostradas

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

📌 Advertencia: Muchos diagramas malutilizan <<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 refinar:

🔧 1. Agregar estereotipos para mayor claridad

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

• Por qué: Hace explícito que este es un sistema externo, no 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 en la parte inferior de (Aplicar código promocional)
  Opcional – solo cuando se ingresa un código válido
fin nota

• Mejor: Usar una notación de condición o guardia en el <<extend>> flecha:

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

• Por qué: Más preciso que una nota: vincula directamente la extensión a una condición.

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

• Actualmente falta, pero probablemente es importante tanto para clientes como para restaurantes.
• Podría agregarse como un Cliente Registrado caso de uso.

🔧 4. Agrupar casos de uso relacionados (opcional)

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

paquete "Gestión de Pedidos" {
    (Realizar 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 la legibilidad.

8. ¿Qué sigue?

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

🔄 Opción 1: Vista centrada en el restaurante

Modelar el mismo dominio desde la 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 diferentes objetivos del sistema y roles de los actores.

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

Mejorar Realizar Pedido con:

• Aplicar Cupón (si el código promocional no es válido → <<extend>> con mensaje de error)
• Solicitar Instrucciones Especiales (opcional)
• Programar Pedido (para entrega futura)

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

📌 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 Realizar pedido → Procesar pago → Entregar Pedido con mensajes entre actores y sistema.
• Diagrama de Actividad: Modelar los puntos de decisión en Procesar Pago (p. ej., tarjeta rechazada → reintentar o cambiar a billetera).

9. Conclusión

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

• Aclara el alcance del sistema,
• Captura las reglas de negocio,
• Guía el desarrollo,
• Previene malentendidos.

El Plataforma de Entrega de Comida 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.

Al seguir los principios mostrados aquí — nombres orientados 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 tanto precisos y accionables.

✅ Conclusiones finales