State Modelling
A state model describes the lifecycle of a single business entity, an object with a beginning and an end such as a claim, an order or a contract: the set of states it can occupy, the order in which it moves from one to another, the events and conditions that drive those moves and the actions triggered along the way. It is the entity-centred view, complementary to the data model that shows its static structure and to the process model that follows the flow of activities across several entities. Its form is a state diagram, often preceded by a state table that elicits its content, and the level of reading it demands falls to the business analyst.
Goal
State modelling serves to describe, precisely and unambiguously, the lifecycle of a single entity: the set of states it can occupy, the order in which it moves from one to another, the events and conditions that drive those moves and the actions triggered along the way. An entity is a business object with a lifecycle that has a beginning and an end, a claim, an order, a permit, a contract. BABOK places the technique's use where the entity shows complex behaviour and complex rules that govern that behaviour (§10.44): it is this dual criterion that justifies the cost of the model. The deliverable is a state diagram accompanied by the text that documents it, often preceded by a state table that elicits its content.
The decision the model supports is that of the legal transitions: which changes are allowed from which state and which are not. A claim cannot be settled before it has been accepted, and this rule, which a requirements text buries in paragraphs, a state model makes visible and verifiable. It is the entity-centred view. A data model shows the static structure, which entities exist and how they relate; a state model shows the dynamic behaviour of one of them over time. Process modelling, for its part, follows the flow of activities across several entities; the state model takes one entity and gathers everything that can legally happen to it, across all the processes that touch it.
Usage
When to use it
- Entity with a rich, rule-governed lifecycle: many states, conditional transitions, behaviour that depends on the current status.
- The transition rules are the requirement: what matters is which changes are allowed from which state and which are forbidden.
- Status-driven behaviour: the events the entity responds to change according to the state it is in.
- Object crossed by several processes: an entity-centred view gathers what the process models scatter.
When not to use it
- Simple entity, two or three statuses: capturing the status as an attribute of the data model is enough, without the cost of a state model.
- The question is the workflow across several entities: this belongs to process modelling.
- The question is the static structure and the relationships of the entities: reach for the data model and its entity-relationship diagram.
Description
A business analyst does not need to master the whole notation of state machines to use it. What is needed is to read a handful of elements and, often, to facilitate the elicitation that brings them out. The rest, composite states, parallel regions, history, belongs to detailed modelling.
States, transitions, events and guards
A state is a status the entity holds over time, during which it responds to a defined set of events and may carry out activities. It is drawn as a rounded-corner rectangle bearing a name. A transition is a one-way arrow that runs from a source state to a target state, and it is read in the direction it points. Its label follows the form event [guard] / action: the event that triggers it, an optional guard, a condition in brackets that must be true for the transition to occur and an optional action carried out on the way. Two pseudostates bound the cycle: a solid black dot marks the initial state, the point where the entity comes into existence, and an encircled dot marks the final state, where the entity is closed and its cycle complete.
Transitions are not necessarily linear. An entity may skip a state, return to a previous state or loop back on the same state. A transition may be conditional, triggered by an event under a guard, or automatic, triggered by the completion of the state's activities or by the lapse of a delay. It is this combination that gives the model its precision: it says what can happen to the entity, from which state and under which condition.
The state table
Before drawing, one elicits. The state table is the low-technology form of the same model: one row per transition, with the source state, the event and its guard, the action and the target state. BABOK recommends it to have the business experts name the states and the events before the diagram is drawn (§10.44), and it remains the best support for that exchange, because an expert who hesitates in front of a diagram will readily complete a table row by row.
| Source state | Event [guard] | Action | Target state |
|---|---|---|---|
| ● (initial) | claim reported | none | Received |
| Received | [file complete] | none | Under assessment |
| Received | [documents missing] | none | Awaiting documents |
| Awaiting documents | documents received | none | Under assessment |
| Under assessment | coverage confirmed [amount > CHF 10'000] | assign an expert | Under expert review |
| Under assessment | coverage confirmed [amount ≤ CHF 10'000] | none | Accepted |
| Under assessment | not covered | none | Rejected |
| Under expert review | report favourable | none | Accepted |
| Under expert review | report unfavourable | none | Rejected |
| Accepted | payment made | none | Settled |
| Settled | (automatic) | none | ◉ (final) |
| Rejected | (automatic) | none | ◉ (final) |
The pitfalls
The most frequent pitfall is to take an attribute for a state. A state changes the events the entity responds to and the transitions that become legal, whereas an attribute is merely a piece of data it carries. "High priority" or "large amount" are not states, they command no transition. The test is simple: if the value does not change what can happen next, it is an attribute.
The other pitfalls all read off the graph. A missing transition leaves an event that can occur in a state with no defined response, and sweeping each state against each event brings them out. An unreachable state, to which no transition leads, signals dead modelling or a transition forgotten elsewhere, because every non-initial state needs at least one incoming arrow. A sink state, non-final and with no outgoing transition, traps the entity that never leaves it, whereas every state except the final one needs an exit. Omitting the final state hides the rules for closing, archiving or deleting the entity. There remains over-modelling: building a state machine for a simple entity spends expert time for little return.
AI considerations
A language model renders two services on this technique. The first is the derivation of a candidate state machine: it reads business rules, a requirements text or the logs of an existing system and proposes states, transitions and their events. On a legacy system whose behaviour is documented nowhere, the resulting draft is corrected faster than a blank page is filled. The second is the completeness check, a rule-bound task well suited to the machine: flagging an unreachable state, a sink state with no exit, a missing transition for a known event or the absence of a final state.
The limit is of a business nature. Distinguishing a state from an attribute presupposes knowing whether the value genuinely governs the behaviour, which only the business can settle. Whether a transition is legal, whether a claim may pass directly from Received to Rejected, is a business rule that the text does not deliver reliably, and a wrong transition makes the model lie. The language model also tends to over-model, to produce states that are attributes in disguise. Every proposal from the machine is a draft submitted to the domain experts and to the business analyst who holds the distinction between state and attribute.
Examples
The concept the example makes visible is the reading of a state machine on a single entity: the states, a transition that carries at once an event, a guard and an action, a step backwards and the initial and final pseudostates. The case is the lifecycle of a claim at an insurer, assembled into a diagram.
A single transition carries the essence of the notation. The transition from Under assessment to Under expert review is labelled coverage confirmed [amount > CHF 10'000] / assign an expert: the event is the confirmation of coverage, the guard in brackets restricts the move to amounts above CHF 10'000, and the action assigns an expert at the moment of the move. The same event, under the inverse guard [amount ≤ CHF 10'000], leads directly to Accepted: a single guard splits one event into two outcomes. Under expert review then resolves to Accepted or Rejected depending on the report returned. The return from Awaiting documents to Under assessment shows that a transition is not necessarily a progression, the claim returning to assessment as soon as the documents arrive. The solid dot marks the claim's entry into the system, and the two terminal branches, Settled and Rejected, reach the final state. A few states and their transitions are enough to carry all the notation a business analyst needs to read.
Visualizations
The form carries the meaning and reads without a legend. The rounded rectangle says a status held over time. The arrow says a legal transition, and it is read in the direction it points, because the rule is directional. The label says the event that triggers the move, the guard in brackets that conditions it and the action carried out on the way. The solid dot says the birth of the entity, the encircled dot its end. A reader who knows these five signs reads a state diagram with no other support, including the one for the claim.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Medium | Bring together the experts who know the lifecycle rules and gather the business rules, the existing statuses and the documents that describe the handling of the entity. |
| Execution | Medium | Eliciting the states and events in a table, then drawing and validating the diagram, takes a few sessions. The cost grows with the number of states and rules, and reaching a consensus of the experts on the detail of the transitions is the slow part. |
| Documentation | Medium to high | The model lives with the business rules and is updated at each new transition or closing rule. A model left behind the real behaviour makes the reading lie. |
Tooling
A whiteboard is enough for a first sketch, a few states and their transitions fitting on one surface and being corrected on your feet with the experts. The state table lives in a spreadsheet, the natural form of the elicitation before the drawing. General-purpose diagramming tools, diagrams.net, Lucidchart or Visio, carry UML state-machine stencils and give a clean, shareable diagram, well suited as long as it supports a discussion. Dedicated UML modelling workbenches, Enterprise Architect, Visual Paradigm, StarUML or Modelio, hold the state diagram as one view of a coherent model, check it and link it to the other diagrams. Text-generation tools, PlantUML or Mermaid, describe a state diagram in a few lines of versionable text, which suits a model kept alongside the code. Beyond documentation, a state model sometimes serves directly as configuration, workflow engines and software state machines executing the lifecycle the model describes.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.44 State Modelling: the definition of the technique, the entity with complex behaviour and rules, the elements state, transition, event and condition, the state table and the limit of over-modelling.
- OMG (Object Management Group), Unified Modeling Language (UML) Specification, version 2.5.1, State Machines: the specification that defines the notation of state machines, states, transitions labelled event-guard-action, initial and final pseudostates. The normative anchor of the notation.
- David Harel, "Statecharts: A Visual Formalism for Complex Systems", Science of Computer Programming, vol. 8, no. 3 (1987), pp. 231-274: the founding article of the statechart formalism on which UML's state machines rest.