Precise behavioral models · Standard notation
Statecharts & SCXML
Describe which events can change a system’s state, including states where an action is no longer valid.
What it helps you do
Make lifecycle behavior explicit when the same event can have different consequences in different states.
Starting knowledge: Understand states, events, and conditions. XML helps when reading the executable notation.
- Name states according to what is true in them.
- Specify event, optional guard, target, and relevant effects for each transition.
- Consider absent transitions and terminal states deliberately.
The problem it came from
David Harel introduced statecharts in 1987 to describe complex reactive behavior. W3C’s SCXML Recommendation, published in 2015, provides an XML-based state-machine execution model.
Statecharts support richer structures than a simple flat transition table. This entry begins with a small flat lifecycle so the meaning of a transition stays visible.
Work through an example
<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0" initial="waitlisted">
<state id="waitlisted">
<transition event="offer" target="offered"/>
</state>
<state id="offered">
<transition event="accept" target="confirmed"/>
<transition event="expire" target="expired"/>
</state>
<final id="confirmed"/>
<final id="expired"/>
</scxml>- Accept has a transition only in the offered state.
- The expire event must be supplied; this example does not schedule a timer.
- This simplified model ends at confirmed or expired and omits later cancellation.
Where it helps. Where it stops.
Use it when
- Bookings, approvals, offers, connection lifecycles, and interactive workflows.
- An expired or canceled object receives another event.
Potential benefits
- State makes otherwise hidden preconditions visible.
- A transition table can reveal actions that have no defined valid path.
Limits and common mistakes
- A state diagram alone does not implement durable processing, timers, or concurrency control.
- The correctness of a lifecycle still depends on agreed policy and implementation.
The prompt below asks for this structure. It does not guarantee accuracy, complete coverage, better learning, or conformance to a standard. Treat those outcomes as separate checks.
Practise the judgment
Try a choice, inspect a boundary, then explain a case yourself. Hints and answers are available whenever you need them.
In the example, what happens after the model reaches expired?
Hint
Read the transitions rather than inferring a policy.
Explained answer
Best answer for this case: There is no later accept transition in this terminal model
Expired is a final state in the supplied model. It does not contain an accept transition.
Does an expire transition itself schedule a real timeout?
Hint
Receiving an event and scheduling it differ.
Explained answer
Best answer for this case: No; an event source or timer mechanism must supply the event
A transition responds to an event. The surrounding system must arrange for that event to occur.
What would you need to decide before adding cancellation after confirmation?
Hint
Do not add an arrow without its consequence.
Explained answer & self-review rubric
Decide who may cancel, under what conditions, the target state, and whether a place is released. Then extend the lifecycle and test repeat cancellation. The current final state intentionally does not define those rules.
- Identify missing policy
- Specify state and effects
- Consider duplicate events
Take it into your own work
Manual template
Use this structure yourself, with a colleague, or in your preferred writing tool.
# State model
Entity and identity:
States and what each means:
Initial state:
Event | source state | guard | effect | target state:
Events with no transition:
Terminal states:
Timer and persistence responsibilities:
Review the result
- Is each event evaluated in an explicit state?
- Are expiry and cancellation considered?
- Which mechanisms exist outside the model?
Use this approach with your own AI tool
Help me apply Statecharts & SCXML to the material below.
Reader and existing knowledge: [describe]
Task and desired outcome: [describe]
Use these principles: Name states according to what is true in them.; Specify event, optional guard, target, and relevant effects for each transition.; Consider absent transitions and terminal states deliberately..
Preserve source facts, identifiers, quantities, conditions, exceptions, and uncertainty.
Separate supplied facts from assumptions. Ask for missing information instead of inventing it.
Explain your representation choices and provide a review checklist. Do not claim formal compliance or correctness from formatting alone.
Material: [paste only information you are permitted to share]Go to the source
History and the underlying approach are grounded in these references. Examples, prompts, and practice cases here are original educational adaptations. Edition-specific details should be checked against the referenced publication.
- Statecharts & SCXML — primary reference
- Harel, 1987 — Statecharts: A visual formalism for complex systems
Last editorial review: 2026-10-24. An overview is not certification, and this guide is not a reproduction of a standard.