State Machine diagrams are not an invention of UML, but can rather be traced to David Harel's statecharts developed in the 1980's. This display format was taken on in UML.

A State Machine diagram shows a series of conditions which an object can take up over its lifespan, and the causes of the state changes. One can model the state and the changes in state of an object in dependency on executed operations. Special value is placed on the changeover from one state to the next. In this way, one can model an object from initialization to release. The State Machine diagram describes through which operations or events the conditions of the objects are changed. Furthermore, one can also see which configuration the attributes of an object have or must have before changeover.

An object can be modeled as a state machine diagram / -"system" as long as it can be given a list of states for which the following applies:

An object in a state can remain there, but it is also possible to specify "Activity" in states.

If an object is in a state, then sub-states can also be modeled for this state; for example, in a sub-ordered diagram (Composite Element/Child Diagram). If the behavior in a state of a procedural nature, then the sub-diagram can of course also be a state diagram of another kind.

State Machine diagrams must have a starting state and can have an end state. State Machine diagrams, so-called transitions, are always triggered by an event (e.g. requirement, timeout, etc.).

Fig. 28: Example State Machine Diagram

States are modeled using rounded rectangles. They can contain a name and, optionally, can be divided by horizontal lines in up to three areas. At the top is the name of the state. If the name is not entered then the state is anonymous. Existing state variables with value allocations typical for this state can be entered in another area. The third area within the state symbols can contain a list of internal events, conditions and resultant operations.

Event stands for three possible behavioral patterns:

  • entry - triggers automatically when entering a state.
  • exit - triggers automatically when exiting a state.
  • do - is triggered over and over as long as the state isn't changed.

Transitions from one state to the next are triggered by events. An event is made up of a name and a list of possible arguments. A state can place conditions on the event which must be fulfilled so that this state can be taken in by this event. These conditions can be independent of a special event.

An action can be carried out parallel to a state transition. The notation of a transition appears as follows:

Event [Guard] / Action

"[Guard]" and "/Action" are optional components - obviously. The listing of an event at the transition from the start point to the first state may be omitted. The event itself can also be left out on other transitions. If this is the case, then the state will automatically be changed when all activities of the previous state have been processed. The NO event (Trigger) is also designated as ANY Trigger - this event is ALWAYS present.

The following table contains the state diagram symbols.




The state of an object is symbolized by a rectangle with rounded corners. The State is named within this symbol.

Start / Object creation

The start point of the state diagram is shown with a filled circle. It is identical with the object creation. Only one start point per State diagram is allowed and must be available. The location of the start point is optional.

End / Object destruction

The chain of state transitions ends with the object destruction. The end point is shown as a filled circle surrounded by a concentric circle. This symbol can be left out for endlessly running processes, but it may also be entered numerous times. Where applicable, the Token returns to the end of that activity in the super-ordinate diagram that called the sub-ordinate diagram.


Transition is drawn by an arrow. The arrow is labeled with the name of the trigger that changes the object state. A Restriction [Guard] can be entered in brackets. This causes the object State to be changed only when this restriction has been fulfilled. Furthermore, behind a “/“, an activity list can be entered to be executed at transfer. Guard and activity lists are optional – even the trigger may be omitted on the transition from the Initial or if an ANY-Trigger is modeled.


Startup of an automatic bank teller and main states. When switched on, the teller runs through a self-test. Depending upon the result, either the normal state or the error state is engaged. It has also been determined that, in case the self-test require too much time, that also here the error state is engaged. When a card is inserted, it is examined. Depending on the result, the machine continues to either the PIN-query or the cancel state. Further states such as account balance query, availability of funds, etc. are not shown here.

The chain symbols show that there are sub-diagrams that more precisely describe the behaviors in the states. Sub-diagrams can freely use as many Behavior diagrams as desired - these must not necessarily be additional State Machine diagrams.

Fig. 29: Example State Machine Diagram "Automatic Teller Start-up"