9.2 State Machine


A lifecycle is formally expressed as a state machine, comprising:

  • States. Each state represents a stage in the lifecycle of a typical instance of the class.

  • Events. Each event represents an incident or indication that a progression is happening.

  • Transitions. A transition rule specifies what new state is achieved when an object in a given state receives a particular event.

  • Procedures. A procedure is an activity or operation that must be accomplished when an object arrives in a state. Each state has its own procedure. Procedures comprise actions.

The state machine is represented as a statechart diagram, as defined first in [2]. That is, the statechart diagram is a representation of the underlying semantics defined by the state machine.

9.2.1 Example Class with a State Machine

To show how to create a state machine for a class, we'll use an example of a compact, inexpensive microwave oven, the One-Minute Microwaver. We've abstracted a class for the microwave oven:

graphics/09fig01a.gif

Its operation can be summarized as:

  • This simple oven has a single control button. When the oven door is closed and the user presses the button, the oven will cook (that is, energize the power tube) for 1 minute.

  • There is a light inside the oven. Any time the oven is cooking, the light must be turned on, so you can peer through the window in the oven's door and see if your food is bubbling. Any time the door is open, the light must be on, so you can see your food or so you have enough light to clean the oven.

  • When the oven times out (cooks until the desired preset time), it turns off both the power tube and the light. It then emits a warning beep to signal that the food is ready.

  • The user can stop the cooking by opening the door. Once the door is opened, the timer resets to zero.

  • Closing the oven door turns out the light.

Reading this specification, we see several pertinent incidents that affect the operation of the oven:

  • The door is opened.

  • The door is closed.

  • The control button is pressed.

  • The timer counts down to zero ("times out").

These incidents are abstracted as events.

Likewise, there are several behaviors that occur in response to these events:

  • Turn on the light.

  • Turn off the light.

  • Energize the power tube.

  • De-energize the power tube.

  • Set the timer for 1 minute.

  • Add 1 minute to the timer.

  • Clear the timer.

  • Sound the beeper.

These behaviors are abstracted as actions in the states' procedures.

We can express this behavior pattern as a statechart diagram. Figure 9.2 shows a statechart diagram for the microwave oven. The states are represented by rounded rectangles, each labeled with an appropriate name for the state. The transitions are shown by arrows connecting two states. Each transition is labeled with the event that causes the transition. The actions that make up each procedure associated with a state are described in the lower compartment of the state box.

Figure 9.2. Statechart for the One-Minute Microwave Oven

graphics/09fig02.gif

9.2.2 States

A state abstracts a distinct stage in the lifecycle.

Definition: A state represents a condition of an object in which a defined set of rules, policies, regulations, and physical laws applies.

Each state is given a name that is unique within this state machine. States are also numbered. The number of the state is arbitrary and does not imply any sequencing to the states. Figure 9.3 shows how the state names and numbers are written in the top compartment of the state box.

Figure 9.3. State Box Containing State Number, Name, and Procedure

graphics/09fig03.gif

graphics/exclamation.gif

An object is in exactly one state at a time. Although we can see from the microwave oven statechart diagram that the door is closed in several states, this does not mean that the microwave is in several states at once. The states Ready to Cook and Cooking are different because they exhibit different behaviors and they respond to events differently.

If your understanding of the domain under study leads you to a need to be in two (or more) states at once, build a new class (or classes).

While it's important to choose good, meaningful state names, the name of the state is just an arbitrary label. The real meaning of the state is in the behavior associated with the state the procedure executed upon entry to the state, the events that cause transitions into the state, and the events that cause transitions out of the state.

9.2.3 Events

Definition: An event is the abstraction of an incident in the domain that tells us that something has happened.

The event is named based on its meaning in the domain. In the case of the microwave oven, we have these meanings for the events: door opened, door closed, button pressed, and time complete.

An event is received by a state machine because something happens to it. Events are always received by a specific object; they are not broadcast. When the door of oven MM-231432 is opened, only that oven detects the doorOpened event; it is not seen by all of the ovens in the world.

Event names and labels.

The name of the event is based on its meaning. Each event also has a shorthand label based on the class abbreviation and a number. The order of the numbers is arbitrary and unrelated to the state numbers.

The microwave oven has events:

  • MicrowaveOven1: doorOpened

  • MicrowaveOven2: doorClosed

  • MicrowaveOven3: buttonPressed

  • MicrowaveOven4: timerTimesOut

graphics/mlu.jpg

graphics/09fig03a.gif

The events received by a class's state machine can be shown on the class diagram as shown on the left.

Place the signals in the bottom compartment with the stereotype «event».

UML does not specifically require that signals be shown on the class diagram, but some people have found it convenient if their tool allows it. We will use this as an illustration only.

Event specification vs. event occurrence.

When an event (buttonPressed, for example) appears on a statechart diagram, it represents the concept of a typical but unspecified occurrence of an incident in this case, any button-press on any microwave oven. This concept should be distinguished from the particular occurrences of a button-press on oven P at 3 P.M., another at 3:10, and a button-press on oven Q at 9 P.M. Both concepts are referred to informally as an event, and the meaning is generally clear from the context. However, when it is necessary to distinguish by means of terminology, we use event specification to refer to a typical unspecified occurrence (any button-press on any oven) and event occurrence to refer to a particular occurrence (the button-press on oven T at 3:10).

9.2.4 Transitions

Transitions specify what happens what new state is achieved when a particular event occurs while in a certain state.

Definition: A transition abstracts the progression from state to state as caused by an event.

Each transition is labeled with the event that causes the progression.

There may be multiple transitions out of a state only if they are caused by different events. Figure 9.2 showed that when the oven is in Door Closed state, opening the door transitions to Door Open, while pressing the button from the Door Closed state makes a transition to the Cooking state.

There may multiple transitions into a state, each caused by the same event or by different events. All such events must carry the same data.

graphics/exclamation.gif

The words "queue" and "buffer" appear nowhere in these explanations, nor, for that matter, in the remainder of the book, because an Executable UML model cannot manipulate or make assumptions about queues or buffers. (A model compiler may employ a queue, but that's its business, not ours.)

An object detects an event, and either it triggers a transition or it doesn't. If the event does not trigger a transition, it's gone forever, just as an astronomer who misses an eclipse can't save it until the telescope is set up. In this sense, an event is "consumed" at the moment of detection. See also Section 11.2: Rules about Signals.

Reflexive transitions.

An event may cause a reflexive transition from one state into the same state. For example, pressing the button on the microwave extends the cooking time by one minute per press. The effect is the same as with any other transition: on entry to the state, the procedure is executed.

See Figure 9.7 and Figure 9.10 for examples of reflexive transitions.

Figure 9.7. Statechart Diagram and STT with New Cooking Extended State

graphics/09fig07.gif

Figure 9.10. Statechart Diagram for the Order

graphics/09fig10.gif

9.2.5 Procedures

Definition: A state procedure is an operation executed by an object on entry to a state.

Each state has one associated procedure, which in turn comprises several actions. Actions in procedures can do just about anything.

To minimize distraction, the microwave oven example uses informal descriptions written as comments for the procedure. But the real value in Executable UML is that these procedures can be written formally they have a defined semantics and they can be executed.

Because all instances of a class share the same state machine specification, the procedures must be defined so that they can be executed by any object.



Executable UML. A Foundation for Model-Driven Architecture
Executable UML: A Foundation for Model-Driven Architecture
ISBN: 0201748045
EAN: 2147483647
Year: 2001
Pages: 161

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net