Ejemplos de diagramas de máquina de estados
Tres máquinas de estados que puede copiar hoy mismo: un ciclo de vida de pedido, un flujo editorial que vuelve atrás y el fragmento que muestra por qué un estado en espera no es un estado atascado.
8 min de lecturaUML 2.5.116 de 35
01Example 1: an order lifecycle
If a table in your database has a status column, this diagram is already implicit in the codebase - it is just written across a dozen guard clauses instead of drawn once. Making it explicit is the cheapest defect-finding exercise a state machine offers.
Read the transitions rather than the boxes. Each is labelled with the trigger that causes it - checkout, pay, dispatch, deliver - and one carries an effect after a slash: dispatch / print label. Those labels are the content. A diagram of six rounded boxes with unlabelled arrows says only that things change, which everybody already knew.
The two final states are deliberate. Cancelled and delivered are both terminal and they are not the same outcome, and drawing one ringed disc for both would say the order ended without saying how. Nothing in UML limits you to one.
02Example 2: a workflow that loops backwards
Real workflows rarely run in one direction. Something gets rejected, goes back, and comes round again - and the backwards transition is usually where the interesting rules live.
The revise transition from Rejected to Draftis what makes this a state machine rather than a checklist. It says a rejected article is not finished - it re-enters the same cycle, and any counter such as “rejected twice means escalate” hangs off that arrow rather than off a state.
Note that Rejected has an exit and Published does not. A state with no outgoing transition and no final state after it is a claim that the object stays there forever, which is occasionally true and more often an omission. Checking every leaf state for that is a two-minute review that finds real gaps.
The trigger names are events in the domain vocabulary - submit, approve, reject, revise - not method names. That keeps the diagram readable by the editors who own the process, which is the audience that can tell you it is wrong.
03Example 3: two exits that are not a decision
The most common confusion when someone moves from activity diagrams to state machines is what two arrows out of one box mean.
These are two triggers, not two branches of a decision. The order sits in Awaiting payment indefinitely; whichever event arrives first - pay or the time event timeout(72h) - decides where it goes. Nothing has to be exhaustive and there is no [else], because waiting is a legitimate outcome.
That is the opposite of an activity diagram, where a token arriving at a decision with no enabled guard is a stalled process. Same-looking geometry, opposite semantics - which is why the choice between the two notations is worth making on purpose rather than by habit.
04When to draw one at all
A state machine is cheap to draw and expensive to keep, so the question of whether the object has a lifecycle is worth asking before the first box.
Reach for it when
- The object has a status field with more than two values and rules about legal changes.
- Some transitions are forbidden and the prohibition matters - refunds, cancellations, approvals.
- The same object is touched by several services and they disagree about what it can do next.
- Timeouts or expiries change the object without anybody acting on it.
Reach for something else when
- A process crossing several objects and roles - that is an activity diagram.
- A class whose status is derived from other fields rather than stored.
- A workflow engine's own configuration, which is already a state machine written down.
- One diagram covering two objects. Draw one machine per lifecycle.
If the process spans several participants rather than one object's life, you want an activity diagram or, for a business audience, BPMN. The test is simple: if you cannot name the single thing whose states these are, it is not a state machine.
05What to remember
In one line each
- 01The transition labels are the content. Unlabelled arrows between states say nothing.
- 02Several final states are normal - cancelled and delivered are both terminal and not the same.
- 03The missing arrows are where the bugs are. Check every pair you did not draw.
- 04Two arrows out of a state are two triggers, not two branches. Nothing needs an [else].
- 05One state machine per object with a real lifecycle. A process spanning roles is an activity diagram.
06Preguntas frecuentes
¿Cuál es un buen ejemplo de diagrama de máquina de estados?
El ciclo de vida de un pedido: carrito, realizado, pagado, enviado, entregado, con una rama cancelado desde realizado. Tiene seis estados, un disparador por transición y dos finales distintos, que cubre todo lo que se le suele pedir a la notación.
¿Puede un diagrama de estados tener más de un estado final?
Sí, y normalmente debería. Un pedido cancelado y uno entregado están ambos terminados pero no son el mismo resultado, y llevar los dos al mismo disco con anillo oculta la diferencia. UML no limita el número de estados finales.
¿Cómo se modela un tiempo de espera en un diagrama de estados?
Como una transición cuyo disparador es un evento temporal, escrito por ejemplo timeout(72h) o after(72 horas). Sale del estado en el que el objeto espera y apunta a lo que produce el vencimiento. No hace falta guarda: el paso del tiempo es el disparador.
¿Qué ocurre si ninguna transición de salida está habilitada?
Nada, y es lo correcto. Una máquina de estados espera en su estado actual hasta que llega un disparador, así que un estado sin transición habilitada está inactivo, no roto. Es lo contrario de un diagrama de actividad, donde un token sin salida es un proceso detenido.
¿Debe haber una máquina de estados por clase?
Como mucho una, y solo para las clases con un ciclo de vida real. Si una clase tiene una columna de estado con más de dos valores y reglas sobre qué cambio es válido, dibújela. Si el estado es derivado o se fija una sola vez, la máquina no aporta nada.
Lecturas relacionadas