Often in Statemachines, duplication can arise. For example, the vending machine in our examples may need periodic repairs. It’s not certain which state the vending machine will be in when the repair man arrives. So all states should have a transition into the Repair Mode state.
In this diagram, both the
have a transition to the Repair Mode invoked by the
event. Duplication! We can dry this up by using the
construct. See below:
Here we introduce the Operational superstate. Both the
Paid states are contained within
the superstate which implies that they inherit all of the superstate’s
That means we only need one transition into the
Mode state from the
Operational superstate to
achieve the same behavior as the solution in diagram 1.
One Statemachine may have multiple superstates. And every superstate may contain other superstates. That is, superstates can be nested.
The solution in diagram 2 has an advantage over diagram
1. In diagram 11, once the repair man is done he
triggers the operate event and the vending machine transitions into the
Waiting event. This is unfortunate.
Even if the vending machine was in the
Paid state before
the repair man came along, it will be in the
after he leaves. Shouldn’t it go back into the
Superstates come with the
history state which solves this
problem. Every superstate will remember which state it is in before the
superstate is exited. This memory is stored in a pseudo state called
Transitions that end in the history state will recall the last active state of the superstate and enter it.
You can see the history state being use in diagram 2. In this solution, the history state allows the vending machine to return from a repair session into the same state it was in before, as though nothing happened at all.
The following code builds the Statemachine in diagram 2. Watch out for
_H. This is how the history state is denoted. If you
have a superstate named
foo, then it’s history state will
Next we should cover pseudo states.