UML: comportamiento e interacción

El diagrama de transición de estados, o máquina de estados, describe el comportamiento de una parte concreta del sistema. Su aportación es poder especificar cómo transitan los objetos de una clase: en qué situaciones pueden estar y qué sucesos los llevan de una a otra.

No se dibuja para todo el sistema ni para todas las clases. Se reserva para aquellas cuyo ciclo de vida tiene sustancia: un intento que pasa de en curso a corregido y luego a revisado, o una matrícula que se solicita, se paga y se activa.

Es el único diagrama que mira el ciclo de vida de una sola clase. Los demás diagramas de comportamiento miran procesos o funcionalidades que atraviesan varias.

El diagrama de actividad es el diagrama de flujo de toda la vida, el flujograma, incorporado a UML. Encadena actividades, decisiones y caminos paralelos hasta llegar a un final.

Tiene dos usos habituales. Primero, definir procesos de negocio y apoyar la redacción de los casos de uso, porque un caso de uso escrito en prosa se entiende mucho mejor con su flujo dibujado al lado. Y segundo, plantear los casos de prueba: cada camino distinto que atraviesa el diagrama es un escenario que hay que probar.

Actividad y casos de uso se complementan: el caso de uso dice qué funcionalidad hay, y el diagrama de actividad dice por qué pasos discurre.

La máquina de estados se reserva para clases con comportamiento dinámico, y siempre hay una correspondencia directa entre el diagrama y la clase que modela. Es, además, la antesala del patrón de diseño State: un diagrama de estados con sustancia suele acabar implementado convirtiendo cada estado en una clase.

También sirve para preparar pruebas. En las transiciones hay condiciones, y cada condición es un caso que conviene probar por separado, así que el diagrama es una fuente directa de pruebas unitarias.

Cuando la condición de una transición se escribe entre corchetes, recibe el nombre de guarda. La transición solo se dispara si la guarda se cumple.

En el diagrama de actividad hay dos recursos que conviene conocer. Se pueden añadir los objetos sobre los que trabajan determinadas actividades, para ver no solo qué se hace sino sobre qué. Y el diagrama se puede repartir en capas, también llamadas calles o swimlanes, que agrupan las actividades según quién las ejecuta.

Los requisitos funcionales de la aplicación se recogen como casos de uso. Cada uno es una funcionalidad muy identificable, de esas que un usuario nombraría por su cuenta: corregir un test, consultar el progreso, darse de baja.

• No todos los casos de uso tienen el mismo tamaño, y no pasa nada: no hay que forzarlos a una medida común.
• No existen los casos de uso abstractos, del tipo «gestionar algo». Si no se puede contar qué ocurre de principio a fin, no es un caso de uso.
• Se pueden organizar en paquetes o subsistemas cuando son muchos.
• No se explotan en niveles como los diagramas de flujo de datos: no hay un caso de uso que se abra en otros cinco más pequeños.
• Capturan un nivel de granularidad medio-bajo.
• No reflejan flujo: dicen lo que ocurre, no cuándo ocurre. Para el cuándo está el diagrama de actividad.

El diagrama por sí solo no basta. Los casos de uso necesitan ir acompañados de una especificación de requisitos de software que desarrolle, para cada uno, quién lo lanza, qué condiciones hay que cumplir y qué pasa paso a paso.

El diagrama de casos de uso es un inventario de funcionalidades, no un flujo. Buscar en él el orden de las cosas es el malentendido más común.

La inclusión se usa para no repetir: si tres casos de uso pasan siempre por la misma comprobación de identidad, esa comprobación se saca a un caso de uso incluido. La extensión es lo contrario, un añadido que puede ocurrir o no.

Junto a la extensión aparece el punto de extensión, que es donde se especifica bajo qué condiciones se produce o no ese comportamiento opcional. Sin él, la extensión queda a medias.

La inclusión es obligatoria y la extensión es opcional. Es la pregunta más repetida de todo el apartado de casos de uso, y la confusión entre las dos, el fallo más frecuente.

En cuanto a los actores, hay una convención de colocación: el actor dibujado a la izquierda del diagrama es el actor principal, el que inicia la funcionalidad, y el de la derecha es secundario, normalmente un sistema externo al que se recurre para completarla.

Los diagramas de secuencia y de comunicación son equivalentes: enseñan la misma información con dos dibujos distintos, y de hecho se puede pasar de uno a otro sin perder nada. Los dos representan un único escenario, es decir, un camino concreto de los que puede seguir un proceso.

Lo que muestran es qué les pasa a los objetos por dentro de un caso de uso: qué mensajes se envían entre ellos y en qué orden, para poder cumplirlo. El caso de uso dice qué se consigue; estos diagramas, cómo se consigue por dentro.

Un matiz que conviene tener claro: como cada diagrama recoge un escenario concreto, no se usan para dibujar todas las alternativas posibles de un proceso. Eso no significa que no puedan expresar condiciones. Desde UML 2, el diagrama de secuencia dispone de fragmentos combinados que permiten marcar alternativas, partes opcionales, bucles y ejecuciones en paralelo dentro del propio diagrama.

Los cuatro diagramas de interacción son el de secuencia, el de comunicación, el de tiempos y el interaction overview. Los dos primeros son los de uso corriente; estos dos, los especializados.

El diagrama de tiempos se centra en las condiciones que cambian dentro de cada línea de vida y entre unas y otras, sobre un eje temporal lineal. Es el que se usa cuando lo que importa no es el orden de los mensajes sino cuánto duran las cosas, y aparece sobre todo en sistemas con requisitos temporales estrictos.

El interaction overview es una mezcla del diagrama de actividad con los de interacción. Mantiene la estructura de flujo del primero, pero en lugar de actividades sueltas puede llevar dentro diagramas de interacción completos, de modo que se ve qué ocurre internamente en una actividad determinada. Funciona como un acercamiento a una parte del flujo.

Una forma rápida de ordenarlos: secuencia y comunicación cuentan el orden de los mensajes, tiempos cuenta cuándo y cuánto, e interaction overview enlaza varios escenarios dentro de un flujo mayor.