28. Representación con diagramas de estados, actividades y objetos

28.1 Introducción

El diagrama de clases conceptual muestra conceptos, atributos y asociaciones, pero no siempre alcanza para explicar todo el dominio. Algunos aspectos se entienden mejor mostrando ciclos de vida, flujos de trabajo o ejemplos concretos. Para eso podemos usar otros diagramas UML: diagramas de estados, diagramas de actividades y diagramas de objetos.

Estos diagramas no reemplazan al modelo de dominio. Lo complementan. Cada uno responde una pregunta distinta y ayuda a validar conocimiento con expertos del negocio.

28.2 Imagen conceptual de los diagramas complementarios

28.3 Cuándo usar otros diagramas

Conviene usar diagramas adicionales cuando el diagrama de clases conceptual deja preguntas abiertas. Si un objeto cambia de estado y eso afecta reglas, un diagrama de estados puede ayudar. Si un proceso tiene pasos, decisiones y responsables, un diagrama de actividades puede ser más claro. Si necesitamos validar un caso concreto con datos de ejemplo, un diagrama de objetos puede ser suficiente.

28.4 Diagramas de estados

Un diagrama de estados muestra el ciclo de vida de un objeto importante. Representa estados posibles y transiciones entre ellos. Es útil cuando las acciones permitidas dependen de la situación actual del objeto.

Por ejemplo, un Turno puede pasar por estados como Disponible, Reservado, Confirmado, Atendido, Cancelado o Ausente. El diagrama ayuda a ver qué cambios son válidos y qué eventos los disparan.

28.5 Qué aporta un diagrama de estados

El diagrama de estados permite descubrir reglas como:

• Qué estados existen y cuáles son finales.
• Qué transiciones están permitidas.
• Qué acciones o eventos producen cada transición.
• Qué estados habilitan o impiden operaciones.
• Qué situaciones excepcionales deben contemplarse.

Si un objeto no tiene un ciclo de vida relevante, probablemente no necesita diagrama de estados.

28.6 Ejemplo: estados de Turno

Un ciclo simple de Turno puede ser:

También pueden existir caminos alternativos:

Este diagrama ayuda a validar con el negocio si se puede cancelar un turno confirmado, si se puede reprogramar un turno cancelado o si un turno ausente puede facturarse.

28.7 Diagramas de actividades

Un diagrama de actividades muestra un flujo de trabajo. Representa acciones, decisiones, bifurcaciones, uniones y pasos paralelos. Es útil para entender procesos del negocio que atraviesan varios conceptos.

Por ejemplo, el proceso de reservar un turno puede incluir consultar disponibilidad, elegir especialidad, seleccionar profesional, confirmar datos, registrar la reserva y enviar notificación.

28.8 Qué aporta un diagrama de actividades

El diagrama de actividades permite ver:

• El orden de los pasos de un proceso.
• Decisiones y condiciones alternativas.
• Responsables o áreas mediante carriles.
• Acciones que pueden ocurrir en paralelo.
• Puntos donde aparecen reglas de negocio.

Es especialmente útil para validar casos de uso y procesos con usuarios del negocio.

28.9 Ejemplo: reservar turno

Un flujo de actividad para reservar turno podría ser:

1. Paciente solicita un turno.
2. El sistema muestra especialidades disponibles.
3. El paciente selecciona profesional o especialidad.
4. El sistema consulta disponibilidad.
5. El paciente elige una franja horaria.
6. El sistema valida reglas de reserva.
7. El sistema registra el turno reservado.
8. El sistema envía confirmación.

Los caminos alternativos pueden incluir falta de disponibilidad, paciente bloqueado o cancelación de la operación.

28.10 Diagramas de objetos

Un diagrama de objetos muestra instancias concretas del modelo en un momento determinado. Permite representar ejemplos con datos específicos y relaciones reales o ficticias.

Es una herramienta muy útil para validar si el modelo conceptual funciona con casos concretos. En lugar de discutir solo clases, se muestran objetos: un paciente particular, un turno específico, una agenda determinada y una franja concreta.

28.11 Qué aporta un diagrama de objetos

El diagrama de objetos ayuda a:

• Validar multiplicidades con ejemplos reales.
• Mostrar cómo se relacionan instancias concretas.
• Detectar conceptos faltantes o relaciones ambiguas.
• Explicar escenarios a personas no técnicas.
• Construir contraejemplos para probar reglas.

28.12 Ejemplo de objetos

Un ejemplo concreto podría mostrar:

Este ejemplo permite preguntar: ¿el turno necesita una reserva separada?, ¿la franja pertenece a la agenda?, ¿el paciente puede tener otro turno en la misma especialidad?, ¿qué ocurre si cancela?

28.13 Cómo elegir el diagrama adecuado

La elección depende de la pregunta:

28.14 Coherencia entre diagramas

Los diagramas deben ser coherentes entre sí. Si el diagrama de clases conceptual incluye Turno, Agenda y Franja horaria, los diagramas de estados, actividades y objetos deberían usar esos mismos nombres, salvo que haya una razón clara para diferenciarlos.

La coherencia evita que cada diagrama cuente una historia distinta. Si un estado aparece en el diagrama de estados, debería coincidir con los estados usados en reglas y casos de uso.

28.15 Qué evitar

Al usar estos diagramas, conviene evitar:

• Dibujar diagramas sin una pregunta concreta.
• Mezclar detalles técnicos con conceptos del dominio.
• Crear diagramas grandes que nadie puede validar.
• Usar nombres distintos para el mismo concepto.
• Mostrar estados que no tienen reglas asociadas.
• Representar flujos ideales sin excepciones importantes.
• Hacer ejemplos de objetos que contradicen multiplicidades del modelo.

28.16 Preguntas para revisar los diagramas

Estas preguntas ayudan a revisar la utilidad de cada diagrama:

• ¿Qué pregunta responde este diagrama?
• ¿Usa lenguaje ubicuo?
• ¿Puede ser validado por expertos del dominio?
• ¿Es coherente con los demás diagramas?
• ¿Muestra reglas, estados o ejemplos que no estaban claros?
• ¿Tiene detalles técnicos innecesarios?
• ¿Debe simplificarse para comunicar mejor?

28.17 Errores frecuentes

Al complementar el modelo con estos diagramas, suelen aparecer estos errores:

• Usar diagramas de estados para objetos que no tienen ciclo de vida relevante.
• Usar diagramas de actividades como reemplazo de reglas de negocio.
• No mostrar flujos alternativos o excepciones.
• Crear diagramas de objetos sin datos concretos.
• No mantener consistencia con el diagrama conceptual.
• Intentar documentar todo en lugar de aclarar lo importante.
• No actualizar diagramas cuando cambia el modelo de dominio.

28.18 Qué debes recordar de este tema

• Los diagramas de estados muestran ciclos de vida y transiciones.
• Los diagramas de actividades muestran procesos, decisiones y flujos de trabajo.
• Los diagramas de objetos muestran ejemplos concretos del modelo.
• Estos diagramas complementan al diagrama de clases conceptual.
• Cada diagrama debe responder una pregunta clara del dominio.
• La coherencia de nombres y reglas entre diagramas es fundamental.
• No conviene agregar diagramas si no ayudan a comprender o validar.

28.19 Conclusión

Los diagramas de estados, actividades y objetos amplían la forma de representar el modelo de dominio. Permiten ver comportamiento, procesos y ejemplos concretos que no siempre se entienden con un diagrama de clases conceptual. Usados con criterio, mejoran la validación y reducen ambigüedad.

En el próximo tema estudiaremos cómo validar el modelo con escenarios, ejemplos y contraejemplos.