UML dinámico: secuencia, actividad y estados

"Un sistema no es solo lo que tiene — es lo que hace y cuándo lo hace."

Qué vas a aprender en este capítulo

El diagrama de clases muestra la estructura. Los diagramas dinámicos muestran el comportamiento: quién le habla a quién, en qué orden, cómo cambia el estado de un objeto a lo largo de su vida, y qué decisiones se toman en un proceso. Este capítulo cubre los tres diagramas dinámicos más usados en la industria: secuencia, actividad y estado.


4.1 Diagrama de secuencia

💡 Intuición

Un diagrama de secuencia es como un guión de teatro: muestra los actores (objetos) en columnas, y los mensajes que se intercambian en el tiempo de arriba a abajo.

Pregunta que responde: ¿Cómo colaboran los objetos para ejecutar un caso de uso?

Ejemplo: para el caso de uso "Registrar pedido" de La Esquina, los actores son: el Mozo (o la interfaz web), el controlador, el objeto Pedido, el objeto Mesa, y la pantalla de cocina. El diagrama muestra exactamente quién llama a quién y en qué orden.

📐 Fundamento

Elementos del diagrama de secuencia:

Elemento Representación Significado
Actor/Objeto Caja en la parte superior Participante en la interacción
Línea de vida Línea vertical punteada Existencia del objeto en el tiempo
Activación Rectángulo en la línea de vida Período en que el objeto está procesando
Mensaje síncrono Flecha sólida con punta llena El emisor espera la respuesta antes de continuar
Mensaje asíncrono Flecha sólida con punta abierta El emisor no espera respuesta
Respuesta Flecha punteada Valor de retorno de un mensaje
Autocall Flecha hacia sí mismo El objeto se llama a sí mismo

Fragmentos combinados (marcos):

  • alt: Alternativas (como un if-else). Cada alternativa tiene una guardia [condición].
  • opt: Opcional (como un if sin else). Solo se ejecuta si se cumple la condición.
  • loop: Repetición. Puede tener condición de fin: loop [0, *], loop [min, max].
  • ref: Referencia a otro diagrama de secuencia.
  • par: Flujos en paralelo.

🛠️ En la práctica

Diagrama de secuencia — "Registrar pedido" en La Esquina:

Mozo          InterfazWeb       Controlador         Pedido          Cocina
  |                |                 |                 |               |
  |─ seleccionar platillos ─────────>|                 |               |
  |                |                 |─ crearPedido() >|               |
  |                |                 |<─────── ok ─────|               |
  |                |                 |                 |               |
  |─ confirmarPedido() ─────────────>|                 |               |
  |                |                 |─ agregar(items)>|               |
  |                |                 |─ enviarACocina()>─────────────>|
  |                |                 |                 |<── ack ───────|
  |                |<─── "Pedido #42 enviado" ─────────|               |
  |<── confirmación en pantalla ─────|                 |               |

Con fragmento alt:

opt [mozo quiere agregar nota]
  Mozo ─── agregarNota(texto) ───> Pedido
end opt

alt [hay stock del platillo]
  Controlador ─── confirmar() ──> Pedido
  Pedido ─── enviar() ──────────> Cocina
else [sin stock]
  Controlador ─── mostrarError() > InterfazWeb
end alt

Uso práctico: El diagrama de secuencia es invaluable para revisar APIs y contratos entre servicios. Si diseñás una API REST, el diagrama de secuencia muestra exactamente qué endpoints se llaman y en qué orden para completar una operación.


4.2 Diagrama de actividad

💡 Intuición

Un diagrama de actividad es un diagrama de flujo mejorado. Muestra el flujo de pasos de un proceso, con decisiones, paralelismo y carriles (swimlanes) que indican qué actor hace qué parte.

Pregunta que responde: ¿Cómo funciona un proceso paso a paso?

Es como el diagrama de flujo de tu Programación I, pero con capacidad de modelar actividades paralelas y asignadas a roles específicos.

📐 Fundamento

Elementos del diagrama de actividad:

Elemento Representación Significado
Inicio Círculo negro sólido Punto de inicio del flujo
Fin de actividad Círculo negro con borde Fin del flujo completo
Acción Rectángulo redondeado Un paso del proceso
Decisión Rombo Bifurcación condicional (una entrada, múltiples salidas con guardias)
Unión Rombo Convergencia (múltiples entradas, una salida)
Fork Barra horizontal gruesa Inicio de flujos paralelos
Join Barra horizontal gruesa Fin de flujos paralelos (espera todos)
Swimlane Carriles verticales u horizontales Agrupan acciones por responsable

Guardias en decisiones:

Las flechas que salen de un rombo llevan guardias entre corchetes: [sí], [no], [stock > 0], [pago válido].

🛠️ En la práctica

Diagrama de actividad — "Proceso completo de toma de pedido" en La Esquina:

Con swimlanes (carriles) para Mozo, Sistema y Cocina:

Mozo                    Sistema                    Cocina
─────────────────────────────────────────────────────────
[●] Inicio

Seleccionar mesa
         │
         ▼
Elegir platillos del menú
         │
         ▼
Confirmar pedido
         │─────────────────> Validar pedido
                                    │
                             [sin stock?]──[Sí]──> Notificar al mozo ─────> Mozo modifica
                                    │[No]
                             Guardar pedido
                                    │
                             Enviar a cocina ─────────────────────────> Recibir pedido
                                    │                                         │
                                    │                                   Preparar platillos
                             Actualizar estado                                │
                                    │                                   Marcar como listo
                                    │<────────────────────────────────────────
                             Notificar al mozo
                                    │
Recibir notificación                │
         │
         ▼
Servir al cliente
         │
         ▼
[●] Fin (por esta mesa — el proceso continúa con más pedidos)

¿Cuándo usar actividad vs secuencia?

  • Secuencia: cuando querés mostrar qué objetos específicos interactúan y en qué orden exacto (nivel de código/API).
  • Actividad: cuando querés mostrar el flujo de un proceso de negocio, con decisiones y carriles por rol (nivel de proceso/negocio).

4.3 Diagrama de estados (máquina de estados)

💡 Intuición

Algunos objetos pueden estar en distintos estados a lo largo de su vida, y el comportamiento cambia según el estado. Un semáforo puede estar en "rojo", "amarillo" o "verde". Un pedido puede estar "en espera", "en preparación", "listo" o "cancelado".

Un diagrama de estados modela exactamente esto: los posibles estados de un objeto y los eventos que causan la transición de un estado a otro.

Pregunta que responde: ¿Por qué estados pasa un objeto a lo largo de su ciclo de vida?

📐 Fundamento

Elementos del diagrama de estados:

Elemento Representación Significado
Estado inicial Círculo negro El objeto comienza aquí
Estado Rectángulo redondeado Condición estable del objeto
Transición Flecha con etiqueta Cambio de estado causado por un evento
Evento Etiqueta en la flecha Lo que dispara la transición
Guardia [condición] en la flecha Condición adicional para la transición
Acción de transición /acción en la flecha Lo que hace el sistema al transicionar
Estado final Círculo negro con borde El objeto deja de existir o el ciclo termina

Notación de transición:

Evento [Guardia] / Acción

Ejemplo: confirmar [items > 0] / guardarEnBD

Estados especiales:

  • Entry action: Se ejecuta al entrar al estado. Notación dentro del estado: entry / acción.
  • Exit action: Se ejecuta al salir del estado. Notación: exit / acción.
  • Do action: Se ejecuta mientras el objeto está en el estado. Notación: do / acción.

🛠️ En la práctica

Diagrama de estados — ciclo de vida de un Pedido en La Esquina:

                    [●]
                     │
                     ▼
              ┌──────────────┐
              │   Borrador   │  entry/ asignarId()
              └──────────────┘
                     │ confirmar [items > 0] / guardarEnBD()
                     ▼
              ┌──────────────────┐
              │  En preparación  │  entry/ notificarCocina()
              └──────────────────┘
               │                │
     cancelar /           listo / notificarMozo()
     notificarCocina()          │
               │                ▼
               │         ┌────────────┐
               │         │   Listo    │
               │         └────────────┘
               │                │  servirMesa / marcarServido()
               │                ▼
               │         ┌────────────┐
               │         │  Servido   │
               │         └────────────┘
               │                │  cobrar / registrarPago()
               │                ▼
               │         ┌────────────┐
               └────────>│ Cancelado  │
                         └────────────┘
                                │
                               [●]

Uso práctico: Los diagramas de estado son fundamentales para implementar máquinas de estado en el código. Muchos frameworks modernos (XState en JavaScript, StateMachine en Python, Spring State Machine en Java) implementan directamente este modelo. El diagrama UML se convierte casi 1:1 en código.

¿Qué objetos necesitan diagrama de estados?

No todos los objetos tienen un ciclo de vida interesante. Los que sí:

  • Objetos con múltiples fases: Pedido, Factura, Solicitud, Ticket de soporte
  • Objetos reactivos: Semáforo, Sesión, Conexión
  • Objetos que se pueden cancelar, rechazar o revertir

Los objetos simples (como Platillo con solo nombre y precio) raramente necesitan diagrama de estados.


4.4 Elegir el diagrama correcto

📐 Fundamento

Resumen de los diagramas UML y cuándo usarlos:

Pregunta Diagrama
¿Qué entidades existen y cómo se relacionan? Diagrama de clases
¿Qué puede hacer el usuario con el sistema? Diagrama de casos de uso
¿Cómo colaboran los objetos en un escenario específico? Diagrama de secuencia
¿Cómo funciona un proceso paso a paso? Diagrama de actividad
¿Por qué estados pasa un objeto? Diagrama de estados
¿Cómo están desplegados los componentes en servidores? Diagrama de despliegue
¿Qué módulos/paquetes hay y cómo se agrupan? Diagrama de paquetes

Regla práctica: Para un proyecto típico, necesitás:

  1. Siempre: Diagrama de clases + Casos de uso
  2. Para cada caso de uso importante: Diagrama de secuencia
  3. Para procesos de negocio complejos: Diagrama de actividad
  4. Para objetos con ciclo de vida complejo: Diagrama de estados

4.5 Ejercicios

✏️ Ejercicio 4.1 — Diagrama de secuencia

Describí en texto el diagrama de secuencia para el caso de uso "Iniciar sesión" en La Esquina:

  • El mozo ingresa usuario y contraseña en la interfaz.
  • La interfaz envía las credenciales al controlador.
  • El controlador consulta la base de datos.
  • Si las credenciales son correctas, el controlador crea una sesión.
  • La interfaz muestra la pantalla principal.
  • Si son incorrectas, muestra un mensaje de error.

✏️ Ejercicio 4.2 — Diagrama de actividad

Describí el diagrama de actividad para el proceso de "Devolución de libro" en una biblioteca, con swimlanes para Estudiante, Recepcionista y Sistema:

  • El estudiante lleva el libro al mostrador.
  • La recepcionista escanea el código del libro.
  • El sistema verifica si está vencido.
  • Si está vencido, calcula la multa y la recepcionista la cobra.
  • En cualquier caso, el sistema marca el libro como disponible y cierra el préstamo.

✏️ Ejercicio 4.3 — Diagrama de estados

Modelá el ciclo de vida de una Solicitud de crédito en un banco:

Estados posibles: Borrador, Enviada, En revisión, Aprobada, Rechazada, Desembolsada, Cerrada.

Eventos: submit, asignar(analista), aprobar, rechazar, desembolsar, cancelar, pagar(completo).


4.6 Para profundizar


Definiciones nuevas: diagrama de secuencia, línea de vida, activación, mensaje síncrono/asíncrono, fragmento alt/opt/loop, diagrama de actividad, swimlane, fork, join, diagrama de estados, estado, transición, evento, guardia, entry action, exit action.