Ejemplos de diagramas de máquina de estados

Si una tabla de tu base de datos tiene una columna status, este diagrama ya está implícito en el código: solo que está escrito a lo largo de una docena de cláusulas de guarda en vez de dibujado una vez. Hacerlo explícito es el ejercicio de búsqueda de defectos más barato que ofrece una máquina de estados.

Lee las transiciones en vez de las cajas. Cada una está etiquetada con el disparador que la causa - checkout, pay, dispatch, deliver - y una lleva un efecto tras una barra: dispatch / print label. Esas etiquetas son el contenido. Un diagrama de seis cajas redondeadas con flechas sin etiqueta solo dice que las cosas cambian, cosa que ya sabía todo el mundo.

Los dos estados finales son deliberados. Cancelado y Entregado son ambos terminales y no son el mismo desenlace, y dibujar un solo disco con anillo para los dos diría que el pedido terminó sin decir cómo. Nada en UML te limita a uno.

Los flujos de trabajo reales rara vez van en una sola dirección. Algo se rechaza, vuelve atrás y da otra vuelta, y en la transición hacia atrás es donde suelen vivir las reglas interesantes.

La transición revise de Rechazado a Borradores lo que convierte esto en una máquina de estados y no en una lista de comprobación. Dice que un artículo rechazado no está terminado: vuelve a entrar en el mismo ciclo, y cualquier contador del tipo «rechazado dos veces significa escalar» cuelga de esa flecha y no de un estado.

Fíjate en que Rechazado tiene salida y Publicado no. Un estado sin transición de salida y sin estado final detrás afirma que el objeto se queda ahí para siempre, cosa que a veces es cierta y más a menudo es una omisión. Comprobar cada estado hoja por esto es una revisión de dos minutos que encuentra huecos reales.

Los nombres de los disparadores son eventos del vocabulario del dominio - submit, approve, reject, revise - no nombres de métodos. Eso mantiene el diagrama legible para los editores que son dueños del proceso, que es el público capaz de decirte que está mal.

La confusión más común cuando alguien pasa de los diagramas de actividad a las máquinas de estados es qué significan dos flechas saliendo de una caja.

Estos son dos disparadores, no dos ramas de una decisión. El pedido se queda en A la espera de pago indefinidamente; adónde va lo decide el evento que llegue primero: pay o el evento temporal timeout(72h). Nada tiene que ser exhaustivo y no hay ningún [else], porque esperar es un desenlace legítimo.

Es lo contrario de un diagrama de actividad, donde un token que llega a una decisión sin guarda habilitada es un proceso detenido. Geometría de aspecto idéntico, semántica opuesta, y por eso la elección entre las dos notaciones merece hacerse a propósito y no por costumbre.

Una máquina de estados es barata de dibujar y cara de mantener, así que la pregunta de si el objeto tiene un ciclo de vida merece hacerse antes de la primera caja.

Si el proceso abarca varios participantes en vez de la vida de un objeto, quieres un diagrama de actividad o, para un público de negocio, BPMN. La prueba es sencilla: si no puedes nombrar la única cosa cuyos estados son estos, no es una máquina de estados.