UML State Machine Diagrams

When de­vel­op­ing a product or pro­gram­ming software, UML state machine diagrams help to represent the lifecycle of in­di­vid­ual objects in a clear and visual way. Although the diagram only comprises a few elements, it can be a key con­tri­bu­tion to the success of the end product when used correctly. Learn why and in which cases it can make sense to use this kind of diagram and how you can create your own UML state machine diagram in the sections below.

A UML state machine diagram (also known as a state diagram) vi­su­al­izes the states of a finite automaton, i.e. a be­hav­ioral model com­pris­ing actions and states or state tran­si­tions. The diagram provides for an initial and final state and at least one in­ter­me­di­ary state for each object within the model. The state machine diagram is, therefore, able to map the complete lifecycle of a system or subsystem or in­di­vid­ual com­po­nents and classes, re­gard­less of whether these processes concern a coffee machine, an e-book reader or a technical component in a car, for example.

The state machine diagram is one of 14 types of diagrams of the Unified Modeling Language (UML) and the Systems Model Language (SysML). It’s based on a concept by David Harel, published in the sci­en­tif­ic paper “Stat­e­charts: A Visual Formalism for Complex Systems” in 1987. Other UML diagram types include the ap­pli­ca­tion case diagram and the component diagram.

As mentioned above, state machine diagrams aim to describe the behavior of a system as precisely as possible. Among other things, the vi­su­al­iza­tion of in­di­vid­ual processes is designed to answer the following questions:

• What happens when the object is in a specific state?
• What state has to occur for a change in its behavior?
• What are the trig­ger­ing actions?
• Which prop­er­ties does the object need to have to switch state?

UML state machine diagrams are used wherever it makes sense to visualize states and tran­si­tion con­di­tions for an optimized de­vel­op­ment process. They are es­pe­cial­ly popular for designing embedded systems, for example, since these systems handle various automated signals and processes in the back­ground which need to be optimally co­or­di­nat­ed. In this case, a state machine diagram supports de­vel­op­ers by vi­su­al­iz­ing all relevant control and reg­u­la­to­ry functions, making them obvious at a glance.

The benefits of state machine diagrams can be il­lus­trat­ed using the example of the washing machine function “Aqua Stop”. The function regulates the in­ter­rup­tion of water supply to a washing machine. It can be un­der­stood as its own system as part of a UML state machine diagram. Here, the graphical rep­re­sen­ta­tion shows in which state and under which con­di­tions the “Aqua Stop” function takes effect.

Although UML state machine diagrams are based on just a few elements, the effective com­bi­na­tion of these com­po­nents allows complex sequences of states to be mapped. But what are the most important com­po­nents and what does the fun­da­men­tal structure of a state machine diagram look like?

If we consider the state machine diagram example for vi­su­al­iz­ing the states of a door, the following condition always needs to be met:

• The object is always in one of the two states: The door is either open or closed, but never si­mul­ta­ne­ous­ly open and closed.

In more complex state machine diagrams, the rectangle can be divided into three sections rep­re­sent­ing be­hav­ioral spec­i­fi­ca­tions (see “Tran­si­tion”).

To switch from one state to the next, an action has to be triggered which rep­re­sents a tran­si­tion. This tran­si­tion connects the states – visually depicted by an arrow. Con­di­tions can apply for trig­ger­ing such a tran­si­tion. In principle, a dis­tinc­tion is made between internal and external tran­si­tions in UML state machine diagrams. While external tran­si­tions are mandatory when creating a state machine diagram, internal tran­si­tions don’t nec­es­sar­i­ly have to be included in the diagram.

In the state machine diagram for an elevator, for example, the condition for the action “close elevator door” could be that it had to be open for at least five seconds pre­vi­ous­ly before switching state from “closed” to “open”.

In the case of an internal tran­si­tion, an activity rather than a state change is triggered.

Example: In an ac­count­ing system, the automatic sending of an invoice can be triggered for an out­stand­ing invoice (external tran­si­tion). If a reminder is sent in response to an out­stand­ing invoice, the dispatch of the reminder is con­sid­ered an internal tran­si­tion. Although the activity “send reminder” occurs, the invoice continues to be in the state “unpaid” until set­tle­ment.

If control elements influence the sequence of a state au­toma­tion but do not possess any value pa­ra­me­ters, these are called pseudo states. UML 2, the current version of the Unified Modeling Language, offers ten such pseudo states:

• Initial state: no incoming tran­si­tions and exactly one outgoing tran­si­tion revealed by the starting state
• Final state: no outgoing tran­si­tion and the end of the sequence
• Fork: split into multiple parallel states
• Join: merger of multiple parallel states
• Junction: hub for the con­nec­tion of multiple tran­si­tions
• Choice: node from which multiple al­ter­na­tive tran­si­tions can be started based on the decision taken
• Entry point: summary of ho­moge­nous tran­si­tions that enter a composite state
• Exit point: summary of ho­moge­nous tran­si­tions that leave a composite state
• Shallow history: archive of the last active sub-state of a composite state
• Deep history: archive of the last active sub-state of all hierarchy levels of a composite state

Depending on the com­plex­i­ty, sub-states are possible that provide a more detailed picture of the object state and possible be­hav­ioral patterns. These complex ex­pla­na­tions in UML state machine diagrams are par­tic­u­lar­ly common in technical contexts.

• Composite state: Here, a state can be defined in greater depth.

Example: A door can be in the state “open” or “closed”. Sub-states of the state “closed” could be “unlocked” and “locked”.

• Sub-machine state: Here a sub­or­di­nate state machine diagram is added to a state. Sub-states that comprise multiple sub-states are known as complex states. The various sub-states can be run in­de­pen­dent­ly of each other, although they stand in relation to one another.

Example: In the case of a smart­phone, the alarm function is just one of many features that can be as­so­ci­at­ed with multiple states. If multiple alarms are pro­grammed for different days of the week and times, they concern sub-states that run in­de­pen­dent­ly of each other.

After the initial state as a pseudo state, the invoice occupies the state “written”. Ideally, the process should tran­si­tion to the state “paid”. This tran­si­tion can be described in greater detail by adding the action name “send”.

Once the invoice is paid, the invoice enters the state “paid”. Before this state is reached, it may be necessary to send a “reminder”. Since the invoice doesn’t change state in this case, this rep­re­sents an activity or an internal tran­si­tion. If the invoice is not settled, up to three reminders are sent.