13. Mensajes, activaciones, retornos y creación de objetos en diagramas de secuencia
13.1 Introducción
En el tema anterior vimos que un diagrama de secuencia muestra participantes y mensajes ordenados en el tiempo. Ahora profundizaremos en algunos elementos que permiten representar con más precisión una interacción: tipos de mensajes, activaciones, retornos y creación de objetos.
Estos recursos ayudan a explicar qué participante ejecuta una acción, qué resultado se devuelve, cuándo se crea un objeto y cómo se comunican las partes del sistema. No siempre es necesario usar todos; conviene incorporarlos cuando aportan claridad al escenario.
13.2 Mensajes en un diagrama de secuencia
Un mensaje representa una comunicación entre dos participantes. Puede ser una llamada a una operación, una solicitud a un servicio, una respuesta, un evento, una creación de objeto o una señal enviada a otro componente.
El nombre del mensaje debe expresar la intención de la comunicación. Por ejemplo, validarCredenciales(), consultarDisponibilidad(), registrarPago() o enviarConfirmación(). Nombres como procesar() o hacer() suelen ser demasiado generales.
13.3 Recursos principales de una secuencia
Los mensajes muestran comunicaciones, las activaciones indican períodos de ejecución, los retornos representan respuestas y la creación de objetos permite mostrar cuándo aparece una nueva instancia durante el escenario. Combinados con criterio, estos elementos permiten describir una interacción de forma ordenada y precisa.
13.4 Mensaje síncrono
Un mensaje síncrono representa una llamada en la que el emisor espera que el receptor complete la operación antes de continuar. Es habitual en llamadas a métodos, servicios o funciones donde se necesita una respuesta inmediata para seguir el flujo.
Por ejemplo, un ControladorTurnos puede llamar a obtenerHorariosDisponibles() en ServicioTurnos y esperar la lista de horarios antes de responder a la interfaz.
13.5 Mensaje asíncrono
Un mensaje asíncrono representa una comunicación en la que el emisor no queda obligado a esperar la finalización inmediata del receptor. Es útil para eventos, colas, notificaciones o tareas en segundo plano.
Por ejemplo, después de registrar un pedido, el sistema puede enviar un mensaje asíncrono a un ServicioNotificaciones para que envíe un correo. La operación principal puede continuar sin esperar todos los detalles del envío.
13.6 Mensaje de retorno
El mensaje de retorno representa una respuesta. Puede indicar un valor devuelto, una confirmación, un error o el resultado de una operación. Normalmente se dibuja con línea discontinua.
No todos los retornos deben dibujarse. Si cada mensaje síncrono tuviera siempre su retorno visible, muchos diagramas se volverían innecesariamente largos. Conviene mostrar retornos cuando el resultado influye en decisiones posteriores o cuando evita ambigüedad.
13.7 Mensaje de creación
Un mensaje de creación indica que durante la interacción se crea un nuevo objeto. La flecha suele apuntar al encabezado del objeto creado, y su línea de vida comienza en ese punto del diagrama, no desde la parte superior.
Por ejemplo, un ServicioPedidos puede crear un nuevo objeto Pedido después de validar los datos de compra. Mostrar la creación es útil cuando la aparición del objeto forma parte importante del escenario.
13.8 Mensaje de destrucción
La destrucción de un objeto puede representarse con una marca al final de su línea de vida. Indica que ese objeto deja de existir durante la interacción.
No es necesario mostrar destrucción en todos los diagramas. Se usa principalmente cuando el ciclo de vida del objeto es relevante para comprender el escenario, por ejemplo en objetos temporales, sesiones o recursos que deben liberarse.
13.9 Mensaje encontrado y mensaje perdido
UML permite representar mensajes cuyo origen o destino no se muestra completamente. Un mensaje encontrado parece venir desde fuera del diagrama. Un mensaje perdido sale hacia un destino que no se detalla.
Estos recursos son útiles cuando se quiere concentrar la vista en una parte del sistema sin modelar todo el entorno. Deben usarse con cuidado para no ocultar participantes importantes.
13.10 Activaciones
Una activación, o foco de control, muestra que un participante está ejecutando una operación durante un intervalo. Se dibuja como un rectángulo delgado sobre la línea de vida. Puede comenzar cuando llega un mensaje y terminar cuando se devuelve una respuesta o finaliza la operación.
Las activaciones ayudan a visualizar qué participante tiene el control en cada momento. En diagramas simples pueden omitirse; en diagramas técnicos pueden aportar precisión.
13.11 Activaciones anidadas
Una activación anidada ocurre cuando un participante, mientras está ejecutando una operación, invoca otra operación propia o de otro participante. Esto puede mostrar llamadas internas o delegaciones.
Conviene no abusar de activaciones anidadas. Si el diagrama empieza a parecer una traza completa de ejecución, tal vez se está mostrando demasiado detalle para el propósito del modelo.
13.12 Auto-mensajes
Un auto-mensaje ocurre cuando un participante se envía un mensaje a sí mismo. Representa una llamada interna, una validación propia o una operación auxiliar dentro del mismo objeto o componente.
Por ejemplo, ServicioTurnos puede ejecutar internamente validarReglasDeReserva() antes de guardar un turno. Mostrar el auto-mensaje puede ser útil si esa validación es importante para entender el escenario.
13.13 Parámetros y valores de retorno
Los mensajes pueden incluir parámetros y valores de retorno. Por ejemplo, buscarTurnos(fecha, especialidad) o horariosDisponibles como respuesta. Esto ayuda a aclarar qué información viaja entre participantes.
No conviene incluir listas largas de parámetros si no son necesarias para el objetivo del diagrama. En muchos casos alcanza con nombrar la operación y destacar solo los datos importantes.
13.14 Condiciones en mensajes
Un mensaje puede tener una condición o guarda, por ejemplo [pago aprobado] enviarConfirmación(). Esto indica que el mensaje se envía solo si se cumple cierta condición.
Cuando existen varias alternativas, conviene usar fragmentos combinados como alt, opt o loop. Esos fragmentos se estudiarán en el próximo tema.
13.15 Ejemplo: creación de un pedido
En un sistema de ventas, la interfaz envía confirmarCompra() al controlador. El controlador solicita al servicio que valide el carrito. Luego el servicio crea un objeto Pedido, genera sus líneas, calcula el total y solicita al repositorio que lo guarde. Finalmente se devuelve una confirmación.
En este escenario, el mensaje de creación del objeto Pedido es importante porque muestra en qué momento nace la entidad principal de la operación.
13.16 Ejemplo: notificación asíncrona
Después de reservar un turno, el sistema puede enviar una notificación al paciente. Si esa notificación no es necesaria para completar la reserva, puede representarse como un mensaje asíncrono hacia ServicioNotificaciones.
Esta decisión comunica que el flujo principal no depende de esperar el envío completo del mensaje. Es una diferencia importante frente a una llamada síncrona.
13.17 Nivel de detalle recomendado
Un diagrama de secuencia no debe convertirse automáticamente en una traza de cada línea de código. Debe mostrar las comunicaciones relevantes para comprender el escenario. Si se agregan demasiados mensajes internos, el diagrama se vuelve difícil de leer y mantener.
Una buena práctica es comenzar con los participantes y mensajes principales. Luego se agregan activaciones, retornos, parámetros o creación de objetos solo cuando realmente aclaran el modelo.
13.18 Criterios de revisión
- ¿Cada mensaje tiene un propósito claro dentro del escenario?
- ¿Los mensajes síncronos y asíncronos se distinguen cuando la diferencia importa?
- ¿Los retornos mostrados aportan información útil?
- ¿La creación de objetos aparece solo cuando es relevante?
- ¿Las activaciones ayudan a entender la ejecución o solo agregan ruido?
- ¿Los nombres de mensajes expresan acciones específicas?
- ¿El nivel de detalle es adecuado para el objetivo del diagrama?
13.19 Errores frecuentes
- Mostrar todos los retornos aunque no agreguen claridad.
- Confundir mensaje asíncrono con respuesta diferida sin analizar el comportamiento real.
- Representar creación de objetos que no es relevante para el escenario.
- Usar nombres de mensajes demasiado genéricos.
- Agregar activaciones en exceso y volver pesado el diagrama.
- Convertir el diagrama en una copia visual de la implementación línea por línea.
- Omitir un retorno importante que afecta una decisión posterior.
13.20 Qué debes recordar de este tema
- Los mensajes representan comunicaciones entre participantes.
- Los mensajes síncronos esperan respuesta; los asíncronos no necesariamente.
- Los retornos se muestran cuando aclaran resultados importantes.
- Las activaciones indican períodos de ejecución o procesamiento.
- La creación de objetos permite mostrar cuándo nace una instancia dentro del escenario.
- El nivel de detalle debe mantenerse al servicio de la comprensión.
13.21 Conclusión
Mensajes, activaciones, retornos y creación de objetos permiten representar con mayor precisión una interacción en un diagrama de secuencia. Usados con criterio, ayudan a entender responsabilidades, orden de ejecución y resultados importantes dentro de un escenario.
En el próximo tema veremos fragmentos combinados: alternativas, ciclos, opciones y paralelismo.