State Diagram
State Diagrams are not an invention of UML, they go back to David Harel’s state machines, developed in the 1980s. This form of visualisation was incorporated into UML.
A State Diagram shows a sequence of states that an object can assume in the course of its life and the causes of the state changes. You can model the state of an object and the change of state depending on the operations performed. Particular emphasis is placed on the transitions from one state to the next. An object can thus be modelled from initialisation to release.
The State Diagram describes which operations or events change the states of the object. It also shows which assignment the attributes of the object have or must have before the transition.
An object can be modelled as a state diagram/‘system’ provided that you can specify a list of states for which the following applies:
- The object is always (at any point in time of its existence) in a state of this list, in other words:
- The object is never in any of the specified states (if it is, then you are missing at least one state in the list).
- Never in several states of your list at the same time (if it is, then you have chosen the subdivision into states incorrectly).
Fig. 28: Samplel State-Machine-Diagram
An object in a state can rest there, but it is also possible to provide ‘activity’ in states.
If an object is in a state, sub-states can also be modelled for this state, e.g. in a subordinate diagram (composite element/child diagram). If the behaviour in a state is of a procedural nature, then the sub-diagram can of course also be a behaviour diagram of a different type.
State diagrams must have an initial state and can have a final state. State transitions are always triggered by an event (e.g. condition, time-out, …).
States
States are modelled using rounded rectangles. They can contain a name and can optionally be divided into up to three areas by horizontal lines. The topmost area contains the the state’s name. If the name is not specified, it is an anonymous state. In a further area, existing state variables can be listed with the typical value assignment for this state. The third area within the state symbol can contain a list of internal events, conditions and operations resulting from them.
Event stands for three types of behaviours:
- entry – automatically triggers the specified activity when entering a state, i.e. for all incoming transitions.
- exit – triggers automatically when leaving a state, i.e. for all outgoing transitions.
- do – is triggered again and again as long as the state is not changed.
State transitions
Transitions from one state to the next are triggered by events. An event consists of a name and a list of possible arguments. A state can link conditions to this event that must be fulfilled for this state to be assumed by this event. These conditions can be independent of a specific event.
An action can be carried out at the same time as a state transition. The notation of a transition is as follows:
Event [Condition] / Action
‘Event’, “[Condition]” and “/Action” are all optional components. The event entry at the transition from the starting point to the first state may be omitted. The event can also be omitted at other transitions. If this is the case, the state is automatically changed when all activities of the previous state have been processed (entry..). The NO event (trigger) is also known as the ANY trigger; this event is ALWAYS present.
Symbols
The following table contains the symbols of the state diagrams.
| Name/Symbol | Usage |
|---|---|
 | The state of an object is symbolised by a rectangle with rounded corners. The state is named within this symbol. |
 | The initial point of the state diagram is shown with a filled circle. It is identical to the object creation. Only one starting point per state diagram is permitted and must be present. The arrangement of the starting point is optional. |
 | The chain of state transitions ends with object destruction. The end point is represented by a filled circle surrounded by a concentric circle. For endlessly running processes, this symbol may be missing in the drawing, but it may also be entered multiple times. The token may return to the end of the activity in the parent diagram that called the sub-diagram. |
 | The transition is marked with an arrow. The arrow is labelled with the name of the trigger that changes the object state. You can specify a restriction [Guard] in square brackets, which means that the object status is only changed if it is fulfilled. In addition, an activity list to be executed during the transition can be specified after ‘/’. Guard and activity list are optional, the trigger can also be missing - at the transition from Initial and if an ANY trigger is modelled. |
Example
Booting up an ATM and main states. When switched on, the ATM runs through a self-test. Depending on the outcome of this test, either the home position or the fault state is reached. In addition, if the self-test takes too long, the fault state is also assumed. If the card is inserted, the card check is performed. Depending on the result, the device enters the pin request or cancellation state. The other states such as amount request, availability check, etc. are no longer displayed.
The chain symbols indicate that subdiagrams are available that describe the behaviour in the states in more detail. You are free to use any behaviour diagrams as sub-diagrams; they do not necessarily have to be additional state diagrams.
Fig. 29: Sample status diagram ‘ATM boot-up’
