Diagramas de máquina de estados UML

Un diagrama de estados describe la vida de una sola cosa. No un proceso, no una interacción: un objeto, o un componente, y los estados por los que pasa desde su creación hasta su fin.

Su fuerza está en el espacio negativo. El diagrama de arriba dibuja seis transiciones. Todo lo demás queda por ello prohibido: un pago Refunded no puede volver a Captured, uno Failed no se puede capturar y uno Pending no se puede reembolsar. En un diagrama de clases esas restricciones viven en prosa o en la cabeza de nadie. Aquí son el dibujo.

El comportamiento puede colgar de una transición o de un estado, y elegir bien elimina mucha duplicación.

• Efecto en una transición: se escribe tras la barra. Se ejecuta una vez, en ese paso concreto. Úsalo cuando el comportamiento pertenezca a ese camino.
• entry / … - se ejecuta cada vez que se entra en el estado, por cualquier transición. Si tres flechas hacia Captured necesitan escribir un apunte contable, eso es una acción entry, no tres efectos.
• exit / … - se ejecuta cada vez que se sale del estado, por cualquier transición.
• do / … - se ejecuta de forma continua mientras se está en el estado y se interrumpe al salir. Esta es la del trabajo largo.

La regla práctica: si el comportamiento va de estar en el estado, usa entry/do/exit. Si va del viaje concreto entre dos estados, ponlo en la transición.

Los ciclos de vida reales acaban con un caso común: varios estados que responden igual a un mismo evento. Un pago en Pending, Authorized o Captured se puede cancelar, y dibujar tres flechas cancel separadas hacia Cancelled es ruido.

Un estado compuesto lo resuelve. Envuelve esos tres en un estado envolvente llamado Active y dibuja una sola transición cancel saliendo de Active. Se aplica al subestado que esté activo. Tres flechas se convierten en una, y añadir un cuarto subestado más adelante no cuesta nada.

Un pseudoestado de historia - una H rodeada por un círculo - se ocupa de la reanudación. Sin él, volver a entrar en un compuesto empieza por su subestado inicial. Con él, la máquina regresa al subestado en el que estaba al salir. La historia superficial (H) recuerda un nivel; la historia profunda (H*) recuerda todo el anidamiento. Esto es lo que quieres para cualquier cosa suspendible.

Un diagrama de estados se traduce casi directamente a código, algo inusual en UML. Los estados se convierten en un enum, las transiciones en una tabla y las guardas en las condiciones de cada entrada. Dibujarlo primero e implementar a partir de él es uno de los pocos sitios donde modelar ahorra tiempo sin más, en vez de solo documentar.

1. Estados nombrados como actividades. Authorizing sugiere trabajo en curso; si el objeto está esperando ahí, nombra la condición: Authorized, Awaiting capture.
2. Modelar un proceso, no un objeto.Si tus «estados» son pasos que realizan personas distintas, lo que quieres es un diagrama de actividad.
3. Transiciones sin disparador. Legal - se dispara cuando termina la actividad do del estado - pero normalmente es señal de que falta un evento.
4. Ningún estado final y ninguna explicación. O el objeto vive de verdad para siempre, o se olvidó un estado terminal. Pasan las dos cosas; solo una es intencionada.
5. Repetir la misma transición desde cada estado. Para eso está el estado compuesto.