State Transition Diagrams

State transition diagrams have been used right from the beginning in object-oriented modeling. The basic idea is to define a machine that has a number of states (hence the term finite state machine). The machine receives events from the outside world, and each event can cause the machine to transition from one state to another. For an example, take a look at figure 1. Here the machine is a bottle in a bottling plant. It begins in the empty state. In that state it can receive squirt events. If the squirt event causes the bottle to become full, then it transitions to the full state, otherwise it stays in the empty state (indicated by the transition back to its own state). When in the full state the cap event will cause it to transition to the sealed state. The diagram indicates that a full bottle does not receive squirt events, and that an empty bottle does not receive cap events. Thus you can get a good sense of what events should occur, and what effect they can have on the object.

State transition diagrams were around long before object modeling. They give an explicit, even a formal definition of behavior. A big disadvantage for them is that they mean that you have to define all the possible states of a system. Whilst this is all right for small systems, it soon breaks down in larger systems as there is an exponential growth in the number of states. This state explosion problem leads to state transition diagrams becoming far too complex for much practical use. To combat this state explosion problem, object-oriented methods define separate state-transition diagrams for each class. This pretty much eliminates the explosion problem since each class is simple enough to have a comprehensible state transition diagram. (It does, however, raise a problem in that it is difficult to visualize the behavior of the whole system from a number of diagrams of individual classes - which leads people to interaction and activity modeling).

The most popular variety of state-transition diagram in object methods is the Harel Statechart as in Figure 1. This was introduced by Rumbaugh, taken up by Booch and adopted in the UML. It is one of the more powerful and flexible forms of state transition diagram. A particularly valuable feature of the approach is its ability to generalize states, which allows you to factor out common transitions (thus I can show that the break event applies to both full and empty states by creating the super-state of in-progress). It also has a flexible approach to handling processing. Processes that are instantaneous (i.e. cannot be interrupted) can be bound to the transitions or to the entry or exit of a state, these are called actions. Processes that are long (and can be interrupted) are bound to states, these are called activities. Transitions can also have a condition attached to them, which means that the transition only occurs if the condition is true. There is also a capability for concurrent state diagrams, allowing objects to have more than one diagram to describe their behavior.

A Harel Statechart

Figure 1: A Harel statechart

Not all methods use Harel Statecharts. One of the most notable dissenters is Shlaer/Mellor who use a simpler Moore model state diagram. This form only allows processes to occur when in a state (hence the extra state in Figure 8) and has no superstates. This is a good example of the question of expressiveness in techniques. The Harel Statechart is clearly a more expressive technique, but since it is more expressive there is more to learn when using it. In addition, it is more difficult to implement. Shlaer/Mellor take the view that since state diagrams do not get too complex when drawn for a single object, the extra expressiveness is not worthwhile.

A Shlaer/Mellor state diagram

Figure 2: Moore model state diagram as used by Shlaer/Mellor. It is the equivalent to figure 1.

When to Use Them

State models are ideal for describing the behavior of a single object. They are also formal, so tools can be built which can execute them. Their biggest limitation is that they are not good at describing behavior that involved several objects, for these cases use an interaction diagram or an activity diagram.

People often do not find drawing state diagrams for several objects to be a natural way of describing a process. In these cases you can try either drawing a single state diagram for the process, or using an activity diagram. This defines the basic behavior, which you then need to refactor to split it across a number of objects.

Where to Find Out More

UML uses Harel statecharts, which have also become the most popular style of state diagrams in object methods. For an initial tutorial on them I would suggest either [Booch] or [Rumbaugh]. For a more in-depth treatment take a look at [Cook and Daniels]; they give a lot of good details on formalisms, an integration of design by contract, and a discussion of the use of state diagrams with subclassing.