25. Coherencia entre diagramas: nombres, relaciones, escenarios y responsabilidades

25.1 Introducción

En un proyecto real, un sistema no se representa con un único diagrama. Puede haber casos de uso, clases, secuencias, actividades, estados, componentes y despliegue. Cada diagrama muestra una vista distinta, pero todas esas vistas deben describir el mismo sistema de manera compatible.

La coherencia entre diagramas evita contradicciones. Si un diagrama de casos de uso habla de Registrar pedido, un diagrama de secuencia relacionado no debería usar Confirmar orden sin aclarar si se trata del mismo objetivo o de otro. Si un diagrama de clases define Pedido, los diagramas de estados y secuencia deberían usar ese mismo concepto de manera consistente.

25.2 Qué significa coherencia en UML

La coherencia significa que los diagramas no se contradicen y que comparten conceptos, nombres, relaciones y responsabilidades compatibles. Cada diagrama puede tener su propio nivel de detalle, pero no debería representar una versión diferente del sistema.

Un modelo coherente permite pasar de una vista a otra sin perder sentido. Desde un caso de uso se puede llegar a una secuencia. Desde una secuencia se pueden revisar clases participantes. Desde esas clases se pueden analizar estados o componentes relacionados.

25.3 Vistas coherentes de un mismo sistema

Los diagramas UML pueden mostrar alcance, estructura, comportamiento, interacción y despliegue. La coherencia aparece cuando esas vistas comparten nombres, reglas, relaciones y responsabilidades compatibles. Así, cada diagrama aporta una mirada distinta sin contradecir a las demás.

25.4 Coherencia de nombres

Los nombres deben mantenerse consistentes. Si un concepto se llama Turno en el diagrama de clases, no conviene llamarlo Reserva en otro diagrama sin explicar la diferencia. Si un caso de uso se llama Solicitar turno, el flujo, las secuencias y las actividades deberían usar términos compatibles.

La falta de consistencia en nombres genera dudas. Puede parecer que existen conceptos distintos cuando en realidad se habla de lo mismo, o puede ocultar que se mezclaron responsabilidades diferentes.

25.5 Glosario compartido

Un glosario compartido ayuda a mantener coherencia. Allí se definen términos importantes del dominio y del sistema. Por ejemplo: Turno, Agenda, Profesional, Paciente, Reserva, Cancelación, Pago, Pedido, Factura.

El glosario no necesita ser extenso al principio. Puede crecer a medida que aparecen conceptos relevantes. Lo importante es que los diagramas usen los mismos términos con el mismo significado.

25.6 Coherencia entre casos de uso y actividades

Un caso de uso describe un objetivo funcional. Un diagrama de actividades puede detallar el flujo de ese objetivo. Ambos deben coincidir. Si el caso de uso indica que el usuario puede cancelar una operación, el diagrama de actividades debería contemplar ese camino si es relevante.

Si una actividad muestra pasos que no aparecen en el caso de uso, puede tratarse de un detalle interno válido o de una funcionalidad no documentada. En cualquiera de los dos casos, conviene revisar la relación entre ambas vistas.

25.7 Coherencia entre casos de uso y secuencias

Un diagrama de secuencia puede detallar cómo se realiza un escenario de un caso de uso. El actor, el objetivo y el resultado deberían corresponderse con lo definido en el caso de uso.

Por ejemplo, si el caso de uso es Solicitar turno, la secuencia debería mostrar participantes y mensajes relacionados con esa solicitud. Si aparecen pagos, notificaciones o validaciones, deben tener sentido dentro del escenario o estar justificados como colaboraciones internas.

25.8 Coherencia entre clases y secuencias

Los participantes de una secuencia suelen corresponder a clases, objetos, componentes o servicios. Si una secuencia envía un mensaje a ServicioTurnos, esa responsabilidad debería existir en el diseño. Si una clase recibe mensajes que no corresponden a su responsabilidad, puede haber un problema de modelado.

Las secuencias ayudan a validar diagramas de clases. Si una operación importante no tiene una clase responsable, el modelo puede estar incompleto. Si una clase concentra demasiados mensajes, puede estar haciendo demasiado.

25.9 Coherencia entre clases y estados

Un diagrama de estados suele aplicarse a una clase o entidad importante. Los estados y transiciones deben ser compatibles con los atributos, operaciones y reglas representadas en el modelo de clases.

Por ejemplo, si la clase Turno tiene un atributo estado, el diagrama de estados puede detallar los valores válidos y transiciones. Si el diagrama de estados incluye Cancelado, Confirmado y Atendido, esos estados deberían estar contemplados por el modelo o por las reglas de negocio asociadas.

25.10 Coherencia entre componentes y clases

Los componentes agrupan responsabilidades de mayor nivel. Las clases o servicios internos deberían pertenecer razonablemente a esos componentes. Si una clase de facturación aparece dentro del componente de usuarios sin justificación, puede haber una mala separación de responsabilidades.

La coherencia entre componentes y clases ayuda a mantener una arquitectura comprensible. También permite ubicar cambios con mayor facilidad.

25.11 Coherencia entre componentes y despliegue

El diagrama de componentes muestra módulos de software. El diagrama de despliegue muestra dónde se ejecutan esos módulos o artefactos. Si un componente importante existe en la arquitectura, el despliegue debería mostrar dónde se ejecuta cuando esa información sea relevante.

Por ejemplo, si existe un Servicio de pagos como componente, el diagrama de despliegue puede mostrar si se ejecuta en un contenedor propio, en el mismo servidor de la API o como servicio externo.

25.12 Coherencia de responsabilidades

Las responsabilidades deben mantenerse estables entre vistas. Si el ServicioTurnos es responsable de reservar turnos, no conviene que otro diagrama muestre a la interfaz de usuario realizando directamente validaciones complejas de disponibilidad, salvo que el diseño lo justifique claramente.

Cuando una responsabilidad cambia de lugar entre diagramas, puede ser señal de una decisión no actualizada o de una contradicción en el modelo.

25.13 Coherencia de relaciones

Las relaciones también deben ser compatibles. Si el diagrama de clases indica que Pedido se compone de LíneasDePedido, los diagramas de objetos y secuencia deberían respetar esa idea. Si un diagrama de paquetes indica que Dominio no depende de Infraestructura, los diagramas de componentes no deberían mostrar lo contrario sin explicar la excepción.

Las relaciones inconsistentes suelen revelar dependencias mal entendidas o cambios no reflejados en todos los diagramas.

25.14 Coherencia de escenarios

Un escenario debe mantener continuidad entre documentos y diagramas. Si el flujo principal dice que el sistema valida disponibilidad antes de reservar, la secuencia no debería guardar el turno antes de consultar disponibilidad.

La coherencia de escenarios es importante para pruebas. Si cada diagrama cuenta una versión distinta del flujo, será difícil derivar casos de prueba confiables.

25.15 Diferentes niveles de detalle no son contradicción

Dos diagramas pueden tener distinto nivel de detalle y seguir siendo coherentes. Un caso de uso puede decir "el sistema registra el pedido", mientras que una secuencia puede detallar validaciones, cálculo de total, persistencia y notificación.

La diferencia de detalle es aceptable si ambas vistas cuentan la misma historia y no se contradicen.

25.16 Cambios y actualización de diagramas

Los modelos evolucionan. Cuando cambia una regla, una clase, un componente o un flujo, conviene revisar qué otros diagramas quedan afectados. No todos los diagramas deben actualizarse ante cualquier cambio, pero los que se usan como referencia deben mantenerse consistentes.

Un diagrama obsoleto puede causar más daño que la ausencia de diagrama, porque transmite una versión incorrecta del sistema.

25.17 Lista práctica de coherencia

25.18 Criterios de revisión

• ¿Los diagramas usan el mismo vocabulario para los mismos conceptos?
• ¿Los escenarios se corresponden con los casos de uso documentados?
• ¿Las clases que aparecen en secuencias existen o están justificadas?
• ¿Las responsabilidades no cambian arbitrariamente entre vistas?
• ¿Los estados y transiciones son compatibles con las reglas del dominio?
• ¿Las dependencias de componentes coinciden con la arquitectura esperada?
• ¿Los diagramas vigentes representan la versión actual del sistema?

25.19 Errores frecuentes

• Usar nombres distintos para el mismo concepto.
• Crear diagramas aislados que no se relacionan con el resto del modelo.
• Actualizar un diagrama y olvidar otros que dependen de la misma decisión.
• Mostrar responsabilidades diferentes para una misma clase o componente.
• Representar escenarios incompatibles entre actividades y secuencias.
• Ignorar contradicciones porque cada diagrama parece correcto por separado.
• Mantener diagramas obsoletos como documentación vigente.

25.20 Qué debes recordar de este tema

• Los diagramas UML son vistas distintas de un mismo sistema.
• La coherencia evita contradicciones entre esas vistas.
• Los nombres deben mantenerse consistentes.
• Las relaciones y responsabilidades deben ser compatibles entre diagramas.
• Los escenarios deben contar la misma historia aunque tengan distinto nivel de detalle.
• Los diagramas usados como referencia deben actualizarse cuando cambian decisiones importantes.

25.21 Conclusión

La calidad de un modelo UML no depende solo de cada diagrama individual, sino también de la coherencia entre ellos. Cuando nombres, relaciones, escenarios y responsabilidades se mantienen consistentes, los diagramas funcionan como una documentación integrada y útil.

En el próximo tema veremos niveles de abstracción: diagramas conceptuales, de análisis y de diseño.