State machine models

Astate machine model describes how a system responds to internal or external events.
The state machine model shows system states and events that cause transitions from
one state to another. It does not show the flow of data within the system. This type
of model is often used for modelling real-time systems because these systems are
often driven by stimuli from the system's environment. For example, the real-time

alarm system discussed in Chapter 13 responds to stimuli from movement sensors,
door opening sensors, and so on.
State machine models are an integral part of real-time design methods such as
that proposed by Ward and Mellor (Ward and Mellor, 1985) and Harel (Harel, 1987;
Harel, 1988). Harel's method uses a notation called Statecharts and these were the
basis for the state machine-modelling notation in the UML.
A state machine model of a system assumes that, at any time, the system is in
one of a number of possible states. When a stimulus is received, this may trigger
a transition to a different state. For example, a system controlling a valve may move
from a state 'Valve open' to a state 'Valve closed' when an operator command (the
stimulus) is received.
This approach to system modelling is illustrated in Figure 8.5. This diagram shows
a state machine model of a simple microwave oven equipped with buttons to set
the power and the timer and to start the system. Real microwave ovens are actually
much more complex than the system described here. However, this model includes
the essential features of the system. To simplify the model, I have assumed that the
sequence of actions in using the microwave is:
1. Select the power level (either half-power or full-power).
2. Input the cooking time.
3. Press Start, and the food is cooked for the given time.
For safety reasons, the oven should not operate when the door is open and, on
completion of cooking, a buzzer is sounded. The oven has a very simple alphanumeric
display that is used to display various alerts and warning messages.
The UML notation that I use to describe state machine models is designed for
modelling the behaviour of objects. However, it is a general-purpose notation that
can be llSed for any type of state machine modelling. The rounded rectangles in a
model rl~present system states. They include a brief description (following 'do') of
the actions taken in that state. The labelled arrows represent stimuli that force a
transition from one state to another.
Therefore, we can see that the system responds initially to either
the full-power or the half-power button. Users can change their mind after selecting
one of these and press the other button. The time is set and, if the door is closed,
the Start button is enabled. Pushing this button starts the oven operation and cooking
takes place for the specified time.
The UML notation lets you indicate the activity that takes place in a state. In a
detailed system specification, you have to provide more detail about both the stimuli
and the system states . This information may be maintained in a data
dictionary or encyclopaedia that is maintained by the CASE
tools used to create the system model.
The problem with the state machine approach is that the number of possible states
increases rapidly. For large system models, theref~re, some structuring of these state
models is necessary. One way to do this is by using the notion of a superstate that
encapsulates a number of separate states. This superstate looks like a single state
on a high-level model but is then expanded in more detail on a separate diagram.
To illus:trate this concept, consider the Operation state . This is a superstate
that can be expanded.
The Operation state includes a number of sub-states. It shows that operation starts
with a status check, and that if any problems are discovered, an alarm is indicated
and operation is disabled. Cooking involves runnmg the microwave generator for
the specified time; on completion, a buzzer is sounded. If the door is opened during
operation, the system moves to the disabled state,