24. Elección del diagrama adecuado según el problema a comunicar

24.1 Introducción

Conocer muchos diagramas UML no significa que haya que usarlos todos. La habilidad más importante consiste en elegir el diagrama adecuado para la pregunta que se necesita responder. Un buen diagrama aclara una idea; un diagrama mal elegido puede agregar confusión aunque esté correctamente dibujado.

La elección depende del problema a comunicar, del público, del nivel de detalle y del momento del proyecto. No es lo mismo explicar alcance funcional, estructura de clases, flujo de trabajo, interacción entre objetos, arquitectura de componentes o despliegue en servidores.

24.2 Comenzar por la pregunta

Antes de elegir un diagrama, conviene formular una pregunta concreta. Por ejemplo: ¿quién usa el sistema?, ¿qué clases participan?, ¿qué pasos sigue el proceso?, ¿qué mensajes ocurren?, ¿qué estados puede tener un pedido?, ¿qué componentes existen?, ¿dónde se despliega el software?

La pregunta orienta la elección. Si la pregunta es de estructura, conviene un diagrama estructural. Si es de comportamiento, conviene un diagrama de comportamiento. Si es de colaboración entre participantes, conviene un diagrama de interacción.

24.3 Guía para elegir un diagrama UML

La elección del diagrama puede organizarse como un mapa de preguntas. Si se quiere mostrar alcance funcional, se usan casos de uso. Si se quiere mostrar estructura, se usan clases, objetos, paquetes o componentes. Si se quiere mostrar comportamiento, se usan actividades o estados. Si se quiere mostrar colaboración, se usan secuencia o comunicación. Si se quiere mostrar infraestructura, se usa despliegue.

24.4 Si necesitas mostrar alcance funcional

Cuando la pregunta es qué ofrece el sistema y a quién, el diagrama de casos de uso suele ser adecuado. Permite mostrar actores, límite del sistema y funcionalidades principales.

Es útil al inicio de un proyecto, en conversaciones sobre requisitos o cuando se quiere comunicar una visión general sin entrar en detalles internos.

24.5 Si necesitas mostrar conceptos o clases

Cuando la pregunta es qué conceptos existen y cómo se relacionan, conviene usar un diagrama de clases. Puede representar un modelo conceptual del dominio o un diseño más cercano al código, según el nivel de detalle.

Si se necesita mostrar ejemplos concretos con valores específicos, conviene usar un diagrama de objetos como complemento.

24.6 Si necesitas organizar un modelo grande

Cuando hay muchas clases, casos de uso o componentes, un diagrama de paquetes puede ayudar a organizar el modelo. Permite agrupar elementos y mostrar dependencias entre grupos.

Es útil para reducir complejidad visual y analizar si las dependencias entre áreas o capas son razonables.

24.7 Si necesitas mostrar un flujo de trabajo

Cuando la pregunta es qué pasos sigue un proceso, qué decisiones aparecen o qué tareas pueden ejecutarse en paralelo, conviene usar un diagrama de actividades.

Es útil para procesos de negocio, flujos de usuario, procedimientos, algoritmos de alto nivel y casos de uso con varios caminos alternativos.

24.8 Si necesitas mostrar el ciclo de vida de un objeto

Cuando el comportamiento depende del estado de un objeto, conviene usar un diagrama de estados. Este diagrama muestra estados, eventos, transiciones, guardas y acciones.

Es útil para pedidos, pagos, turnos, solicitudes, sesiones, documentos, incidencias y cualquier entidad con reglas importantes de cambio de estado.

24.9 Si necesitas mostrar mensajes en un escenario

Cuando la pregunta es qué participantes colaboran y en qué orden se envían mensajes, conviene usar un diagrama de secuencia. Es uno de los diagramas más claros para representar escenarios de interacción.

Si interesa más la red de objetos y responsabilidades que el eje temporal, puede ser más adecuado un diagrama de comunicación.

24.10 Si necesitas mostrar módulos de software

Cuando se quiere explicar la arquitectura modular, las interfaces ofrecidas y requeridas, o las dependencias entre servicios y componentes, conviene usar un diagrama de componentes.

Es útil para discutir división de responsabilidades, APIs, servicios, módulos, bibliotecas y dependencias de alto nivel.

24.11 Si necesitas mostrar infraestructura

Cuando la pregunta es dónde se ejecuta el software, qué servidores participan, qué artefactos se despliegan y cómo se conectan los nodos, conviene usar un diagrama de despliegue.

Es útil para arquitectura de ejecución, redes, contenedores, servicios externos, bases de datos, seguridad y ambientes productivos.

24.12 Si necesitas mostrar estructura interna de un componente

Cuando un componente, clase o subsistema tiene una organización interna relevante, puede usarse un diagrama de estructura compuesta. Permite mostrar partes internas, puertos y conectores.

Es un diagrama especializado. Conviene usarlo solo cuando aporta más claridad que un diagrama de componentes o clases.

24.13 Si necesitas mostrar restricciones temporales

Cuando el tiempo exacto, la duración, la sincronización o las ventanas temporales son importantes, puede usarse un diagrama de tiempo.

Es útil en sesiones, sensores, protocolos, monitoreo, alarmas, dispositivos y sistemas donde el comportamiento depende fuertemente del tiempo.

24.14 Si necesitas coordinar varias interacciones

Cuando un proceso largo está formado por varias interacciones complejas, puede usarse un diagrama de vista global de interacción. Sirve para mostrar el flujo general y referenciar secuencias más detalladas.

Es útil para evitar diagramas de secuencia gigantes que mezclan demasiados escenarios internos.

24.15 Tabla de elección rápida

24.16 Considerar el público

El público influye en la elección. Para usuarios o representantes del negocio, suelen ser más útiles casos de uso, actividades y algunos estados. Para desarrollo, pueden ser necesarios clases, secuencia, componentes y despliegue. Para arquitectura, componentes, paquetes y despliegue suelen aportar más valor.

Un diagrama correcto técnicamente puede ser inútil si no está adaptado a quienes deben leerlo. Elegir el diagrama también implica elegir el nivel de abstracción adecuado.

24.17 Evitar diagramas por obligación

No conviene crear diagramas solo para cumplir una lista. Cada diagrama debe tener una razón clara. Si un diagrama no ayuda a comprender, decidir, comunicar o validar, probablemente no aporta valor.

Es mejor tener pocos diagramas útiles y mantenibles que muchos diagramas incompletos, obsoletos o redundantes.

24.18 Criterios de revisión

• ¿Está clara la pregunta que el diagrama debe responder?
• ¿El tipo de diagrama elegido responde mejor que otras opciones?
• ¿El público puede comprender el nivel de detalle?
• ¿El diagrama evita mezclar demasiados propósitos?
• ¿Existe otro diagrama más simple para comunicar lo mismo?
• ¿El diagrama será usado, revisado o mantenido?
• ¿Aporta claridad real al proyecto?

24.19 Errores frecuentes

• Usar siempre el mismo diagrama para cualquier problema.
• Crear todos los diagramas UML aunque no sean necesarios.
• Elegir un diagrama técnico para una conversación funcional.
• Elegir un diagrama general cuando se necesita detalle de diseño.
• Mezclar alcance, estructura, comportamiento e infraestructura en una sola vista.
• No considerar quién leerá el diagrama.
• Conservar diagramas que ya no se usan ni representan el sistema real.

24.20 Qué debes recordar de este tema

• La elección del diagrama depende de la pregunta que se desea responder.
• No es necesario usar todos los diagramas UML en todos los proyectos.
• Casos de uso ayudan a comunicar alcance funcional.
• Clases, objetos, paquetes, componentes y despliegue ayudan a comunicar estructura.
• Actividades y estados ayudan a comunicar comportamiento.
• Secuencia y comunicación ayudan a comunicar interacción entre participantes.
• Un diagrama útil debe ser claro para su público y propósito.

24.21 Conclusión

Elegir bien un diagrama UML es tan importante como dibujarlo correctamente. Cada tipo de diagrama tiene una intención y responde mejor a ciertas preguntas. Cuando se parte del problema a comunicar, UML se convierte en una herramienta práctica para razonar, explicar y validar decisiones.

En el próximo tema veremos cómo mantener coherencia entre diagramas: nombres, relaciones, escenarios y responsabilidades.