15. Diagramas de comunicación: colaboración entre objetos y responsabilidades
15.1 Introducción
El diagrama de comunicación es un diagrama UML de interacción. Al igual que el diagrama de secuencia, muestra cómo colaboran distintos participantes para completar un escenario. La diferencia principal está en el énfasis: el diagrama de secuencia resalta el orden temporal; el diagrama de comunicación resalta la red de objetos y sus vínculos.
Este diagrama es útil cuando se quiere observar qué objetos participan, cómo están conectados y qué responsabilidades asume cada uno durante una colaboración. Los mensajes también tienen orden, pero se indican mediante números en lugar de ubicarse verticalmente según el paso del tiempo.
15.2 Qué representa un diagrama de comunicación
Un diagrama de comunicación representa participantes conectados por enlaces. Sobre esos enlaces se colocan mensajes numerados que indican el orden de la interacción. La disposición visual es más libre que en un diagrama de secuencia, porque no depende de líneas de vida verticales.
Por ejemplo, para reservar un turno, pueden aparecer Usuario, InterfazTurnos, ControladorTurnos, ServicioTurnos, RepositorioTurnos y ServicioNotificaciones. Los mensajes numerados muestran cómo colaboran esos participantes para completar la reserva.
15.3 Colaboración entre objetos
Los participantes se representan como objetos, componentes o roles conectados mediante enlaces. Los mensajes numerados indican la secuencia de comunicación. Esta vista permite concentrarse en la estructura de colaboración y en la distribución de responsabilidades entre los participantes.
15.4 Participantes
Los participantes pueden representar objetos, clases, componentes, servicios o actores, según el nivel de detalle. En un modelo de diseño, suelen ser objetos o componentes que colaboran para resolver una operación. En un modelo más conceptual, pueden representar roles o partes del sistema.
Los nombres deben ser claros. Por ejemplo, controlador:ControladorTurnos, servicio:ServicioTurnos o repositorio:RepositorioTurnos. Esta notación permite indicar el nombre del objeto y su clase o tipo.
15.5 Enlaces
Un enlace conecta participantes que pueden comunicarse durante la interacción. El enlace no es el mensaje en sí; es el camino por el cual pueden enviarse mensajes. Sobre ese enlace se escriben los mensajes numerados.
Si dos objetos no tienen ninguna relación o posibilidad de comunicación en el escenario, no deberían aparecer conectados. Dibujar enlaces innecesarios puede sugerir colaboraciones que no existen.
15.6 Mensajes numerados
Los mensajes se escriben junto a los enlaces y se numeran para indicar el orden. Por ejemplo, 1: solicitarTurno(), 2: consultarDisponibilidad() y 3: guardarTurno().
La numeración reemplaza la lectura vertical del diagrama de secuencia. Por eso debe ser clara y consistente. Si el orden se vuelve difícil de seguir, quizá sea mejor usar un diagrama de secuencia.
15.7 Numeración jerárquica
UML permite usar numeración jerárquica para mostrar mensajes anidados. Por ejemplo, después del mensaje 1: reservarTurno(), pueden aparecer 1.1: validarDatos(), 1.2: consultarDisponibilidad() y 1.3: guardarTurno().
Esta numeración ayuda a expresar que ciertos mensajes ocurren dentro del contexto de otro mensaje principal. Debe usarse con moderación para no complicar la lectura.
15.8 Diferencia con el diagrama de secuencia
Ambos diagramas representan interacciones, pero priorizan aspectos distintos. El diagrama de secuencia facilita ver el tiempo y el orden de mensajes. El diagrama de comunicación facilita ver la red de objetos y sus vínculos.
| Aspecto | Diagrama de secuencia | Diagrama de comunicación |
|---|---|---|
| Énfasis | Orden temporal. | Colaboración y enlaces. |
| Lectura del orden | De arriba hacia abajo. | Por números de mensajes. |
| Disposición | Participantes en columnas. | Participantes distribuidos libremente. |
| Mejor para | Entender secuencia temporal detallada. | Entender qué objetos colaboran y cómo se conectan. |
15.9 Cuándo usar un diagrama de comunicación
Conviene usar un diagrama de comunicación cuando interesa destacar la colaboración entre objetos y la distribución de responsabilidades. Es útil si el escenario tiene una estructura de objetos interesante y el orden de mensajes no es demasiado complejo.
También puede servir para revisar si una responsabilidad está bien ubicada. Si todos los mensajes pasan por un único objeto, ese objeto puede estar concentrando demasiadas tareas.
15.10 Cuándo preferir un diagrama de secuencia
Conviene preferir un diagrama de secuencia cuando el orden temporal es central, cuando hay muchas alternativas, cuando se necesitan activaciones claras o cuando el escenario incluye muchos pasos que deben leerse con precisión.
En la práctica, el diagrama de secuencia suele ser más usado porque el tiempo queda visualmente más claro. El diagrama de comunicación resulta más útil cuando se quiere discutir colaboración y conexiones entre objetos.
15.11 Responsabilidades de los participantes
Un diagrama de comunicación ayuda a analizar responsabilidades. Cada mensaje enviado a un participante sugiere que ese participante debe saber hacer algo. Si recibe mensajes que no corresponden a su función, puede haber un problema de diseño.
Por ejemplo, si una InterfazTurnos recibe mensajes para calcular disponibilidad, guardar datos y enviar notificaciones, probablemente está asumiendo responsabilidades que deberían pertenecer a servicios o componentes especializados.
15.12 Acoplamiento entre objetos
La cantidad y dirección de enlaces puede sugerir el nivel de acoplamiento. Si muchos objetos conocen directamente a muchos otros, la colaboración puede ser difícil de mantener. Si las dependencias están mejor coordinadas, el diseño suele ser más comprensible.
El diagrama de comunicación permite visualizar estas relaciones de manera directa. Esto lo vuelve útil para revisar diseño orientado a objetos y distribución de responsabilidades.
15.13 Ejemplo: reserva de turno
En una reserva de turno, el usuario interactúa con la interfaz. La interfaz envía un mensaje al controlador. El controlador consulta el servicio de turnos. El servicio consulta el repositorio para verificar disponibilidad y luego guarda la reserva. Finalmente, el servicio de notificaciones recibe un mensaje para enviar confirmación.
En un diagrama de comunicación, estos participantes pueden distribuirse alrededor de la colaboración y los mensajes numerados indican el orden de la operación.
15.14 Ejemplo: compra en línea
En una compra en línea, pueden participar Carrito, ServicioPedidos, ServicioPagos, RepositorioPedidos, Inventario y ServicioNotificaciones. Los mensajes numerados permiten mostrar cómo se confirma el pedido, se procesa el pago, se descuenta stock y se notifica al cliente.
Esta vista ayuda a observar si la colaboración está equilibrada o si un participante centraliza demasiadas decisiones.
15.15 Mensajes condicionales
Los mensajes pueden incluir condiciones entre corchetes, por ejemplo 3: [pago aprobado] registrarPedido(). Esto permite representar que un mensaje solo se envía si se cumple cierta condición.
Si el escenario tiene muchas condiciones, puede ser más claro usar un diagrama de secuencia con fragmentos combinados o dividir el comportamiento en varios diagramas.
15.16 Iteraciones
También pueden representarse repeticiones, por ejemplo 2*: agregarLínea(producto) para indicar que el mensaje se repite. Algunas herramientas usan notaciones específicas para ciclos o condiciones.
Como siempre, la notación debe estar al servicio de la claridad. Si la repetición es compleja, quizá convenga usar un diagrama de secuencia con un fragmento loop.
15.17 Relación con diagramas de clases
Los enlaces del diagrama de comunicación deben ser compatibles con las relaciones del modelo de clases o con dependencias justificadas por el diseño. Si dos objetos se comunican, debe existir alguna razón para que uno conozca al otro o pueda acceder a él.
Por eso, este diagrama puede servir para revisar si el diagrama de clases soporta las colaboraciones necesarias para un escenario.
15.18 Criterios de revisión
- ¿El diagrama representa un escenario concreto?
- ¿Los participantes tienen responsabilidades claras?
- ¿Los enlaces indican comunicaciones reales o necesarias?
- ¿Los mensajes están numerados de manera clara?
- ¿La colaboración evita concentrar demasiadas responsabilidades en un solo objeto?
- ¿El diagrama se entiende mejor como comunicación que como secuencia temporal?
- ¿Es coherente con los diagramas de clases o componentes relacionados?
15.19 Errores frecuentes
- Olvidar numerar los mensajes.
- Usar numeración confusa o inconsistente.
- Dibujar enlaces entre objetos que no deberían comunicarse.
- Usar este diagrama cuando el orden temporal necesita verse con mucha precisión.
- Agregar demasiados participantes y perder legibilidad.
- No revisar si las responsabilidades quedan bien distribuidas.
- Crear un diagrama desconectado del modelo de clases.
15.20 Qué debes recordar de este tema
- El diagrama de comunicación muestra colaboración entre participantes.
- Los enlaces indican posibles comunicaciones entre objetos o componentes.
- Los mensajes se numeran para expresar el orden.
- Este diagrama enfatiza la red de colaboración más que el eje temporal.
- Ayuda a revisar responsabilidades y acoplamiento.
- Si el orden temporal es complejo, suele convenir un diagrama de secuencia.
15.21 Conclusión
El diagrama de comunicación permite observar cómo colaboran los objetos o componentes de un sistema durante un escenario. Su principal aporte es mostrar vínculos, mensajes numerados y distribución de responsabilidades en una vista compacta.
En el próximo tema veremos diagramas de actividades, que permiten representar flujos de trabajo, decisiones y concurrencia.