12. Diagramas de secuencia: interacción entre objetos a través del tiempo
12.1 Introducción
El diagrama de secuencia es un diagrama UML de interacción. Su objetivo es mostrar cómo colaboran distintos participantes para completar un escenario, indicando el orden de los mensajes a través del tiempo.
Mientras un diagrama de clases muestra estructura, el diagrama de secuencia muestra comportamiento dinámico. Permite ver qué objeto o componente solicita una operación, quién responde, qué mensajes se encadenan y qué responsabilidades aparecen durante un caso concreto.
12.2 Qué representa un diagrama de secuencia
Un diagrama de secuencia representa una interacción. Esa interacción suele corresponder a un escenario de un caso de uso, a una operación importante o a una colaboración entre objetos. La lectura principal se realiza de arriba hacia abajo: los mensajes superiores ocurren antes que los inferiores.
Por ejemplo, para reservar un turno, el usuario puede enviar una solicitud a una interfaz, la interfaz puede llamar a un controlador, el controlador puede consultar disponibilidad en un servicio, el servicio puede guardar el turno y luego devolver una confirmación.
12.3 Estructura básica de un diagrama de secuencia
Los participantes se ubican en la parte superior y cada uno tiene una línea de vida vertical. Los mensajes se dibujan como flechas horizontales entre participantes. El tiempo avanza desde arriba hacia abajo, por eso la posición vertical de cada mensaje indica su orden dentro del escenario.
12.4 Participantes
Los participantes son los elementos que intervienen en la interacción. Pueden representar actores, objetos, clases, componentes, servicios, interfaces de usuario, controladores, repositorios o sistemas externos, según el nivel de detalle del diagrama.
Conviene nombrarlos de forma clara. Por ejemplo, Usuario, PantallaReserva, ControladorTurnos, ServicioTurnos, RepositorioTurnos y ServicioNotificaciones. Los nombres deben ayudar a comprender la responsabilidad de cada participante.
12.5 Línea de vida
La línea de vida es la línea vertical que baja desde cada participante. Representa la existencia de ese participante durante la interacción. A lo largo de esa línea se reciben y envían mensajes.
No debe interpretarse como una línea de código ni como una pila exacta de ejecución. Es una representación visual del tiempo y de la participación dentro del escenario.
12.6 Mensajes
Un mensaje representa una comunicación entre participantes. Puede ser una llamada a una operación, una solicitud, una respuesta, una creación de objeto o una comunicación con un sistema externo.
Los mensajes deben tener nombres significativos. Por ejemplo, solicitarTurno(), consultarDisponibilidad(), guardarTurno() o enviarConfirmación(). Si el nombre es demasiado genérico, el diagrama pierde precisión.
12.7 Orden temporal
El orden de los mensajes se lee de arriba hacia abajo. Esta es la característica central del diagrama de secuencia. Permite ver qué debe ocurrir primero, qué depende de qué y en qué momento se obtiene una respuesta.
Si el orden de los mensajes no importa o si se quiere enfatizar más la red de colaboraciones que la secuencia temporal, puede ser más adecuado un diagrama de comunicación.
12.8 Activaciones
Una activación, también llamada foco de control, se representa como un rectángulo estrecho sobre la línea de vida. Indica que un participante está ejecutando una acción o procesando una solicitud durante cierto tramo de la interacción.
No siempre es necesario mostrar activaciones. En diagramas simples pueden omitirse para mejorar la legibilidad. En diagramas más técnicos ayudan a entender quién está ejecutando una operación en cada momento.
12.9 Mensajes síncronos
Un mensaje síncrono representa una llamada en la que el emisor espera una respuesta antes de continuar. Es común en llamadas a métodos o servicios donde una operación necesita el resultado para seguir.
Por ejemplo, un ControladorTurnos puede llamar a consultarDisponibilidad() en ServicioTurnos y esperar la lista de horarios disponibles antes de responder a la interfaz.
12.10 Mensajes asíncronos
Un mensaje asíncrono representa una comunicación donde el emisor no queda necesariamente esperando una respuesta inmediata. Puede usarse para eventos, colas de mensajes, notificaciones o tareas que se procesan en segundo plano.
Por ejemplo, después de reservar un turno, el sistema puede enviar un mensaje asíncrono a un servicio de notificaciones para que envíe un correo o mensaje al paciente.
12.11 Mensajes de retorno
Los mensajes de retorno representan respuestas. En UML suelen dibujarse con línea discontinua. Pueden mostrar valores devueltos, confirmaciones o resultados de una operación.
No siempre es necesario dibujar todos los retornos. Si cada llamada tiene una respuesta obvia, el diagrama puede saturarse. Conviene mostrar retornos cuando aclaran el escenario o cuando el resultado influye en los pasos siguientes.
12.12 Creación y destrucción de objetos
Un diagrama de secuencia puede mostrar la creación de un objeto mediante un mensaje que llega al objeto creado. También puede mostrar la destrucción de un objeto con una marca de finalización en su línea de vida.
Estos recursos son útiles cuando la creación o destrucción forma parte importante del escenario. En muchos diagramas de análisis se omiten para mantener la vista más simple.
12.13 Relación con casos de uso
Un diagrama de secuencia puede detallar un escenario de un caso de uso. Por ejemplo, el flujo principal de Solicitar turno puede transformarse en una secuencia de mensajes entre interfaz, controlador, servicio, repositorio y sistema de notificaciones.
El caso de uso explica el comportamiento desde la perspectiva del actor y del sistema. El diagrama de secuencia muestra cómo colaboran los participantes internos y externos para lograr ese comportamiento.
12.14 Relación con diagramas de clases
Los participantes de un diagrama de secuencia suelen corresponder a clases, objetos o componentes definidos en otros diagramas. Por eso, los diagramas de secuencia ayudan a validar responsabilidades del diagrama de clases.
Si una clase recibe demasiados mensajes y coordina todo, puede estar acumulando responsabilidades. Si un mensaje se envía a una clase que no debería conocer esa información, puede existir un problema de diseño.
12.15 Ejemplo: reservar un turno
En un escenario de reserva de turnos, el Usuario solicita horarios disponibles desde la InterfazTurnos. La interfaz envía una petición al ControladorTurnos. El controlador consulta al ServicioTurnos, que a su vez consulta el RepositorioTurnos. Luego el usuario selecciona un horario, el sistema guarda el turno y envía una confirmación.
El diagrama de secuencia permite observar el orden de esa colaboración y qué responsabilidad tiene cada participante.
12.16 Nivel de detalle
Un diagrama de secuencia puede ser conceptual o técnico. En una vista conceptual pueden aparecer Actor, Sistema y Servicio externo. En una vista de diseño pueden aparecer interfaz, controlador, servicio, repositorio, entidad y cliente de integración.
El nivel elegido debe responder al propósito del diagrama. Si se quiere validar un flujo con usuarios, no conviene mostrar detalles internos excesivos. Si se quiere guiar implementación, puede ser necesario incluir participantes técnicos.
12.17 Criterios de revisión
- ¿El diagrama representa un escenario concreto?
- ¿Los participantes tienen responsabilidades claras?
- ¿Los mensajes están ordenados de arriba hacia abajo?
- ¿Los nombres de mensajes son comprensibles?
- ¿El nivel de detalle coincide con el objetivo del diagrama?
- ¿El diagrama evita mostrar retornos o activaciones innecesarias?
- ¿La interacción es coherente con los casos de uso y diagramas de clases relacionados?
12.18 Errores frecuentes
- Usar un diagrama de secuencia para mostrar estructura estática.
- Incluir demasiados participantes sin necesidad.
- No respetar el orden temporal de arriba hacia abajo.
- Nombrar mensajes de forma vaga, como procesar() o hacer().
- Mezclar niveles de abstracción sin criterio.
- Mostrar todos los mensajes de retorno aunque no aporten claridad.
- Crear secuencias que contradicen responsabilidades definidas en el modelo de clases.
12.19 Qué debes recordar de este tema
- El diagrama de secuencia muestra interacción entre participantes a través del tiempo.
- Los participantes se ubican arriba y sus líneas de vida bajan verticalmente.
- Los mensajes se leen de arriba hacia abajo.
- Las activaciones indican períodos de ejecución o procesamiento.
- Los mensajes pueden ser síncronos, asíncronos o de retorno.
- Este diagrama ayuda a validar escenarios, responsabilidades y colaboraciones.
12.20 Conclusión
El diagrama de secuencia es una herramienta muy útil para comprender cómo se desarrolla un escenario. Permite visualizar participantes, mensajes y orden temporal, lo que facilita analizar responsabilidades y detectar problemas de colaboración.
En el próximo tema profundizaremos en mensajes, activaciones, retornos y creación de objetos dentro de diagramas de secuencia.