3. Tipos de diagramas UML: estructura, comportamiento e interacción

3.1 Introducción

UML no tiene un único tipo de diagrama. Un sistema de software puede analizarse desde varias perspectivas, y cada perspectiva necesita una representación distinta. Algunos diagramas describen elementos estables, otros describen procesos y otros describen comunicaciones entre partes del sistema.

Por esta razón, UML organiza sus diagramas en tres grandes familias: diagramas de estructura, diagramas de comportamiento y diagramas de interacción. Comprender esta clasificación es fundamental para elegir el diagrama adecuado en cada situación.

3.2 Por qué existen varios diagramas

Un sistema no puede explicarse bien con una sola vista. Si se quiere saber qué funcionalidades ofrece, conviene usar un diagrama de casos de uso. Si se quiere estudiar qué clases participan en la solución, conviene usar un diagrama de clases. Si se quiere entender el orden de los mensajes en una operación, conviene usar un diagrama de secuencia.

Esto no significa que haya que construir todos los diagramas posibles. Significa que cada diagrama responde mejor a ciertas preguntas. La habilidad está en seleccionar el menor conjunto de diagramas que permita comprender, comunicar o diseñar lo necesario.

Idea clave: no se elige un diagrama por costumbre, sino por la pregunta que se necesita responder.

3.3 Clasificación general de los diagramas UML

Los diagramas UML pueden agruparse en tres familias principales. Los diagramas de estructura muestran elementos del sistema y sus relaciones. Los diagramas de comportamiento muestran procesos, funciones, estados y cambios. Los diagramas de interacción, que son una especialización de los de comportamiento, muestran cómo se comunican distintos participantes durante un escenario.

Clasificación de los diagramas UML en estructura, comportamiento e interacción

3.4 Diagramas de estructura

Los diagramas de estructura representan la parte más estable del sistema. Se enfocan en elementos, relaciones, dependencias, agrupaciones, componentes e infraestructura. Son útiles cuando se quiere comprender cómo está organizado un sistema o cómo se divide una solución.

Los diagramas de estructura más importantes son:

  • Diagrama de clases: muestra clases, atributos, operaciones y relaciones.
  • Diagrama de objetos: muestra instancias concretas y enlaces en un momento determinado.
  • Diagrama de paquetes: organiza elementos del modelo en grupos y dependencias.
  • Diagrama de componentes: representa módulos de software, interfaces y dependencias.
  • Diagrama de despliegue: muestra nodos físicos o virtuales donde se ejecutan artefactos.
  • Diagrama de estructura compuesta: detalla partes internas, puertos y conectores de un elemento complejo.

3.5 Diagrama de clases

El diagrama de clases es uno de los diagramas UML más usados. Permite representar clases, atributos, operaciones, responsabilidades y relaciones como asociación, dependencia, herencia, agregación y composición.

Puede usarse con distintos niveles de detalle. En análisis, puede mostrar conceptos importantes del problema. En diseño, puede acercarse más a la estructura que tendrá el código. Por eso es importante aclarar si se está trabajando con un modelo conceptual o con un modelo de diseño.

3.6 Diagrama de objetos

El diagrama de objetos representa ejemplos concretos de un diagrama de clases. Mientras una clase describe una plantilla general, un objeto representa una instancia particular. Por ejemplo, Cliente puede ser una clase, mientras que cliente123 puede ser un objeto concreto con valores específicos.

Este diagrama es útil para explicar situaciones particulares, validar multiplicidades, mostrar relaciones reales entre instancias y comprobar si el modelo de clases permite representar los casos necesarios.

3.7 Diagrama de paquetes

El diagrama de paquetes permite organizar modelos grandes. Un paquete agrupa clases, componentes, casos de uso u otros elementos relacionados. También permite mostrar dependencias entre grupos.

Este tipo de diagrama es útil cuando un sistema crece y ya no alcanza con mirar elementos sueltos. Ayuda a ordenar responsabilidades, separar áreas funcionales y reducir la complejidad visual.

3.8 Diagrama de componentes

El diagrama de componentes representa partes reemplazables o desplegables del software, como módulos, servicios, bibliotecas, aplicaciones, APIs o subsistemas. También muestra interfaces ofrecidas y requeridas.

Es especialmente útil en sistemas con varios módulos, integraciones externas, servicios distribuidos o arquitectura por capas. Permite discutir dependencias sin entrar en el detalle interno de cada clase.

3.9 Diagrama de despliegue

El diagrama de despliegue muestra dónde se ejecuta el software. Representa nodos como servidores, dispositivos, máquinas virtuales, contenedores, redes y artefactos desplegados.

Se usa cuando importa comprender la distribución física o lógica de la solución: qué se ejecuta en el cliente, qué se ejecuta en el servidor, dónde está la base de datos, qué servicios externos participan y cómo se comunican los nodos.

3.10 Diagramas de comportamiento

Los diagramas de comportamiento representan lo que ocurre en el sistema. Se enfocan en funcionalidades, actividades, decisiones, eventos y cambios de estado. Son útiles cuando se necesita comprender cómo actúa el sistema frente a una situación.

Los diagramas de comportamiento más importantes son:

  • Diagrama de casos de uso: muestra actores externos y funcionalidades principales del sistema.
  • Diagrama de actividades: representa flujos de trabajo, decisiones, bifurcaciones y tareas paralelas.
  • Diagrama de estados: describe los estados posibles de un objeto y las transiciones entre ellos.

3.11 Diagrama de casos de uso

El diagrama de casos de uso muestra qué puede hacer cada actor con el sistema. Es una vista de alto nivel orientada al alcance funcional. No describe la interfaz, la base de datos ni la lógica interna, sino los servicios que el sistema ofrece a su entorno.

Como ya se estudió en el curso de casos de uso, este diagrama es útil para conversar sobre objetivos, actores y límites del sistema. En este curso lo veremos como una pieza dentro del conjunto de diagramas UML.

3.12 Diagrama de actividades

El diagrama de actividades representa pasos de un proceso. Puede mostrar acciones, decisiones, caminos alternativos, tareas paralelas, inicio, fin y responsables mediante carriles.

Es útil para modelar procesos de negocio, flujos de uso, algoritmos de alto nivel y procedimientos que necesitan visualizarse paso a paso. También ayuda a detectar decisiones faltantes o caminos no considerados.

3.13 Diagrama de estados

El diagrama de estados se usa cuando un objeto importante cambia de situación a lo largo del tiempo. Por ejemplo, un pedido puede pasar por los estados creado, pagado, preparado, enviado, entregado o cancelado.

Este diagrama es valioso cuando el comportamiento depende del estado actual. Ayuda a definir qué eventos producen cambios, qué transiciones son válidas y qué acciones deben ejecutarse al entrar o salir de un estado.

3.14 Diagramas de interacción

Los diagramas de interacción son una familia especializada dentro de los diagramas de comportamiento. Su objetivo es mostrar cómo colaboran objetos, componentes o participantes para completar un escenario.

Los diagramas de interacción más importantes son:

  • Diagrama de secuencia: muestra participantes y mensajes ordenados en el tiempo.
  • Diagrama de comunicación: muestra una red de participantes y mensajes numerados.
  • Diagrama de tiempo: muestra cambios de estado o valores a lo largo del tiempo.
  • Diagrama de vista global de interacción: combina una visión de flujo con referencias a interacciones específicas.

3.15 Diagrama de secuencia

El diagrama de secuencia es muy utilizado para detallar escenarios. Ubica los participantes en columnas y muestra los mensajes de arriba hacia abajo, siguiendo el paso del tiempo.

Es útil para comprender responsabilidades, orden de llamadas, respuestas, validaciones y colaboración entre objetos o componentes. También ayuda a detectar si una clase está haciendo demasiado o si falta un participante que coordine la operación.

3.16 Cómo elegir el tipo de diagrama

La elección del diagrama depende de la pregunta que se desea responder. Si la pregunta es quién usa el sistema y qué objetivos tiene, conviene usar casos de uso. Si la pregunta es qué conceptos o clases existen, conviene usar clases. Si la pregunta es cómo fluye un proceso, conviene usar actividades. Si la pregunta es qué mensajes ocurren en un escenario, conviene usar secuencia.

Pregunta Diagrama recomendado
¿Qué funcionalidades ofrece el sistema y a quién? Casos de uso
¿Qué clases, conceptos o relaciones existen? Clases u objetos
¿Cómo se organiza el sistema en módulos? Paquetes o componentes
¿Qué pasos sigue un proceso? Actividades
¿Qué estados atraviesa un objeto? Estados
¿Qué mensajes ocurren durante un escenario? Secuencia o comunicación
¿Dónde se ejecutan los componentes? Despliegue

3.17 Errores frecuentes

  • Usar siempre el mismo tipo de diagrama, aunque no responda la pregunta necesaria.
  • Construir demasiados diagramas sin una finalidad clara.
  • Mezclar estructura, comportamiento e interacción en una sola representación confusa.
  • Elegir un diagrama muy técnico para comunicar una idea funcional.
  • Elegir un diagrama demasiado general para tomar decisiones de diseño.
  • No mantener coherencia entre diagramas que representan el mismo sistema.

3.18 Qué debes recordar de este tema

  • UML organiza sus diagramas en estructura, comportamiento e interacción.
  • Los diagramas de estructura muestran elementos y relaciones relativamente estables.
  • Los diagramas de comportamiento muestran procesos, estados y funcionalidades.
  • Los diagramas de interacción muestran comunicaciones entre participantes durante un escenario.
  • No es necesario usar todos los diagramas en todos los proyectos.
  • La elección del diagrama depende de la pregunta que se necesita responder.

3.19 Conclusión

Conocer los tipos de diagramas UML permite elegir mejor cómo representar un sistema. Algunos diagramas ayudan a ver la estructura, otros permiten entender procesos y otros muestran la colaboración entre partes. La claridad del modelo depende de seleccionar la vista correcta para cada problema.

En el próximo tema veremos principios para crear diagramas claros, simples y útiles, independientemente del tipo de diagrama elegido.