Dominar el Enfoque Dirigido por Casos de Uso: Una Guía Completa de Requisitos y Diseño

Introducción

En la ingeniería de software, cerrar la brecha entre las necesidades de las partes interesadas y la implementación técnica es a menudo la fase más desafiante del desarrollo. El Enfoque Dirigido por Casos de Uso ofrece una metodología estructurada e iterativa para resolver este problema. Al centrarse en cómo los usuarios interactúan con el sistemapara lograr objetivos específicos, este enfoque garantiza que los requisitos sean claros, verificables y directamente rastreables a los artefactos de diseño.

Esta guía proporciona un recorrido completo del Enfoque Dirigido por Casos de Uso, avanzando desde los requisitos de alto nivel hasta el diseño detallado. Utilizaremos un único ejemplo continuo: un Sistema de Gestión de Pedidos en Línea—para ilustrar cada etapa, asegurando coherencia y claridad durante todo el proceso.

---

Resumen de la Metodología

El Enfoque Dirigido por Casos de Uso sigue una progresión natural de arriba hacia abajo. Cada etapa refina la anterior, añadiendo precisión y reduciendo la ambigüedad.

¿Por qué importa este orden?

1. Diagrama de Casos de Uso: Proporciona un inventario completo de capacidades y alcance. Es rápido de escanear e ideal para el acuerdo de las partes interesadas sobre quéhace el sistema.
2. Descripción del Caso de Uso: Elimina la ambigüedad al definir las precondiciones, postcondiciones, actores y prioridad. “Congela” el contrato de comportamiento.
3. Flujo de Eventos: Convierte el contrato en pasos concretos y verificables. Esto sirve como materia prima tanto para los casos de prueba como para el diseño técnico.
4. Actividad/Diagrama de Secuencia: Actúa como el puente hacia el código. Identifica los objetos participantes, sus responsabilidades, los intercambios de mensajes y las reglas de ramificación exactas.

---

Etapa 1: Diagrama de Casos de Uso (Requisitos)

El Diagrama de Casos de Uso capturaquién interactúa con el sistema (actores) yqué pueden hacer (casos de uso), junto con las relaciones entre ellos.

Conceptos Clave

• Actor Primario: Inicia el caso de uso (colocado a la izquierda).
• Actor Secundario: Apoya el sistema o recibe notificaciones (colocado a la derecha).
• Límite del Sistema: El rectángulo que define el alcance del sistema.
• <<include>>: Representa un comportamiento compartido obligatorio. Si el Caso de Uso A incluye el Caso de Uso B, B debe ocurrir para que A se complete.
• <<extend>>: Representa un comportamiento opcional. El Caso de Uso B extiende el Caso de Uso A solo bajo condiciones específicas.

Ejemplo: Sistema de Gestión de Pedidos en Línea

@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(Primario)" as cust
actor "Almacénn(Secundario)" as wh

rectangle "Sistema de Gestión de Pedidos" {
  usecase "Realizar Pedido" as UC1
  usecase "Cancelar Pedido" as UC2
  usecase "Rastrear Pedido" as UC3
  usecase "Iniciar Sesión" as UC4
  usecase "Imprimir Factura" 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álisis del Diagrama:

• ElCliente inicia la colocación, cancelación y seguimiento de pedidos.
• El Almacén participa en la colocación y cancelación de pedidos (probablemente para actualizaciones de inventario).
• Inicio de sesión está incluido en Colocar, Cancelar y Rastrear Pedidos, lo que significa que la autenticación es obligatoria para estas acciones.
• Imprimir factura extiende Colocar Pedido, lo que significa que es un paso opcional que puede ocurrir después de que se coloque un pedido.

---

Etapa 2: Descripción del caso de uso (Especificación)

Un diagrama nombra los casos de uso pero carece de detalle. El Tabla de descripción del caso de usoespecifica el contrato preciso para cada caso de uso.

Ejemplo: UC-01 Colocar Pedido

Campo	Valor
ID del caso de uso	UC-01
Nombre	Colocar Pedido
Actor principal	Cliente
Actor secundario	Almacén
Precondiciones	El cliente ha iniciado sesión; el carrito contiene al menos un artículo; los artículos están en stock
Postcondiciones (Éxito)	El pedido se persiste con estado confirmado; el pago se captura; se emite el número de seguimiento
Postcondiciones (Fallo)	No se creó pedido; carrito sin cambios; usuario informado de la razón
Flujo principal	→ Véase Etapa 3
Flujos alternativos / excepcionales	Stock insuficiente; pago rechazado
Prioridad	Alta

Propósito: Esta etapa define qué debe ser verdadero antes que se ejecute el caso de uso (precondiciones) y qué debe cumplirse después (postcondiciones), estableciendo criterios claros de éxito/fallo.

---

Etapa 3: Flujo de eventos (Escenarios)

Este es el núcleo conductual del enfoque. El caso de uso «Realizar pedido» se expande en un guion de escenario—una secuencia de pasos numerados escrita antes de que existan diagramas de diseño detallados.

Escenario principal de éxito (flujo básico)

1. El cliente inicia sesión.
2. El cliente envía el carrito con los artículos seleccionados.
3. El sistema valida el contenido del carrito y la disponibilidad del stock.
4. El sistema cobra el total a través de la pasarela de pago.
5. El sistema guarda el pedido con estado confirmado.
6. El sistema devuelve una confirmación de pedido con un ID de pedido.
7. El sistema notifica al Almacén para que recoja, empaque y envíe.

Escenarios Alternativos

• 3a. Stock Insuficiente: El sistema informa sobre los artículos no disponibles y devuelve al carrito.
• 4a. Pago Rechazado: El sistema informa al cliente y no crea el pedido.

Convención Clave: Cada escenario se mapea directamente a un paso en la descripción. Estos flujos se convierten en la base para los diagramas de Actividad y Secuencia en la siguiente etapa.

---

Etapa 4: Diseño Detallado (Diagramas de Secuencia y Actividad)

En esta etapa, elige la notación según el aspecto del sistema que deseas resaltar.

• Diagrama de Secuencia: Resalta líneas de vida, orden de mensajes y responsabilidades entre objetos. Ideal para descubrir clases y métodos.
• Diagrama de Actividad: Resalta flujo de control y decisiones a través de carriles/partes. Ideal para documentar procesos y responsabilidades de roles.

4A. Diagrama de Secuencia (Perspectiva de Interacción)

@startuml
título Diagrama de Secuencia 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 "Servicio de Pedidos" as OS
participant "Pasarela de Pago" as PG
database "Base de Datos de Pedidos" as DB

activate USR
USR -> OS : submitOrder(items)
activate OS
alt Validación y Pago
  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 Stock Insuficiente
  OS -> DB : checkStock(items)
  activate DB
  DB --> OS : stockUnavailable
  deactivate DB
  OS --> USR : error("Sin stock")
else Pago Fallido
  PG --> OS : paymentFailed
  OS --> USR : error("Pago rechazado")
end
deactivate OS
@enduml

Conceptos Clave:

• Llamadas Síncronas: Flechas sólidas (->).
• Respuestas: Flechas discontinuas (-->).
• Barras de activación: Muestra la vida útil del procesamiento de un objeto.
• alt Fragmento combinado: Envuelve los tres escenarios (Éxito, Stock insuficiente, Fallo de pago), reflejando directamente el Flujo de Eventos de la Etapa 3.

4B. Diagrama de actividades (Perspectiva de proceso)

@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 actividades de realizar pedido

|#F0F8FF|Cliente|
start
:Iniciar sesión;
:Navegar por el catálogo;
:Añadir artículos al carrito;

if (¿Listo para pagar?) then (sí)
  :Proceder al pago;
else (no)
  :Volver a navegar;
  stop
endif

|#E8F5E9|Sistema|
:Validar carrito;
:Procesar pago;

if (¿Pago aprobado?) then (sí)
  :Crear pedido (estado=confirmado);
else (no)
  :Notificar fallo de pago;
endif

|#F5EEF8|Almacén|
if (¿Pago aprobado?) then (sí)
  :Seleccionar y embalar artículos;
  :Enviar pedido;
  :Enviar número de seguimiento;
  stop
else (no)
  stop
endif
@enduml

Conceptos clave:

• Carriles: Asignar cada acción a la parte responsable (Cliente, Sistema, Almacén).
• Nodos de decisión: if/then/else/endif las estructuras codifican escenarios de ramificación.
• Marcadores de inicio/fin: Delimitan el inicio y el fin del proceso.

---

Puntos clave de PlantUML

Para modelar eficazmente este enfoque usando PlantUML, recuerda los siguientes elementos esenciales de sintaxis:

1. Diagramas de casos de uso:
   • Usa usecase para funciones.
   • Usa ...> para <<include>> relaciones.
   • Use <... para <<extend>> relaciones.
   • Use rectangle "Nombre del sistema" {} para definir el límite del sistema.
2. Diagramas de secuencia:
   • Defina participantes usando actor, participante, o base de datos.
   • Use -> para llamadas síncronas y --> para respuestas.
   • Use activar y desactivar para mostrar los ciclos de vida de los objetos.
   • Use alt, else, y fin para fragmentos combinados que representan flujos alternativos.
3. Diagramas de actividad:
   • Use |#color|NombreCarril| para definir carriles.
   • Use :acción; para actividades.
   • Use if/else/endif para nodos de decisión.
   • Use inicio y fin para marcar los límites del proceso.

---

Conclusión

El Enfoque impulsado por casos de uso es más que una simple técnica de documentación; es un marco para el refinamiento progresivo. Al comenzar con la visión general (Diagrama de casos de uso) y profundizar en comportamientos específicos (Flujo de eventos) e interacciones técnicas (Secuencia/Diagramas de actividad), los equipos pueden garantizar que cada línea de código se remonta a una necesidad de usuario verificada.

Este método reduce el riesgo de malentendidos entre las partes interesadas y los desarrolladores, facilita pruebas más sencillas mediante escenarios claros y da como resultado un diseño de sistema robusto y centrado en el usuario. Ya sea que esté construyendo una plataforma de comercio electrónico sencilla o un sistema empresarial complejo, seguir esta progresión estructurada conducirá a requisitos más claros y a un software de mayor calidad.