An event is an occurrence at a point in time; it is also known as a discrete signal or stimulus. An event is an atomic occurrence (not interruptible) and conceptually has zero duration. Examples of events are ATM Card Inserted, Part Removed, Part Placed, Brake Pressed, and Elevator Departed.

A timer event is a special event, specified by the keyword after, which indicates that an event occurs after an elapsed time identified by an expression in parentheses, such as after (10 seconds) or after (elapsed time). On a statechart, the timer event causes a transition out of a given state. The elapsed time is measured from the time of entry into that state until exit from the state, which is caused by the timer event.

A state represents a recognizable situation that exists over an interval of time. Whereas an event occurs at a point in time, a finite state machine is in a given state over an interval of time. The arrival of an event at the finite state machine usually causes a transition from one state to another. Alternatively, an event can have a null effect, in which case the finite state machine remains in the same state. In theory, a state transition is meant to take zero time to occur. In practice, the time for a state transition to occur is negligible compared to the time spent in the state.

The initial state of a statechart is the state that is entered when the statechart is activated.

As an example of a statechart, consider the Microwave Oven Control kernel statechart, which is taken from the microwave oven product line case study and shown in Figure 8.1. The statechart follows the sequencing described in the Cook Food use case (see Chapter 13) and shows the different states for cooking food. The initial state is Door Shut. When the user opens the door, the statechart transitions into the Door Open state. The user places an item in the oven, causing the statechart to transition into the Door Open with Item state. When the user closes the door, the statechart then transitions into the Door Shut with Item state. After the user inputs the cooking time, the Ready to Cook state is entered. When the user presses the Start button, the statechart transitions into the Cooking state. When the timer expires, the Door Shut with Item state is reentered. If instead the door were opened during cooking, the Door Open with Item state would be entered. Another possibility is for the user to press the Cancel button during cooking, in which case the Ready to Cook state is entered.

Figure 8.1. Statechart for Microwave Oven Control (kernel functionality)

In the microwave oven product line, the Microwave Oven Control kernel object executes the statechart shown in Figure 8.1. The sequence numbers in Figure 8.1 correspond to the main sequence of events and actions for the Cook Food kernel communication diagram, as explained in Section 8.7.

Events and guard conditions may be combined in defining a state transition. The notation used is Event [Condition]. Thus an event is allowed to cause a state transition, provided that the guard condition given in parentheses is true. Conditions are optional.

In some cases an event does not cause an immediate state transition, but its impact needs to be remembered because it will affect a future state transition. The fact that an event has occurred can be stored as a condition that can be checked later.

Examples of guard conditions in Figure 8.1 are Zero Time and Time Remaining. The two transitions out of the Door Open with Item state are Door Closed [Zero Time] and Door Closed [Time Remaining]. Thus the transition taken depends on whether the user has entered the time or not. If the condition Zero Time is true, the statechart transitions to Door Shut with Item, waiting for the user to enter the time. If the condition Time Remaining is true, the statechart transitions to the Ready to Cook state.

Associated with a state transition is an optional output action. An action is a computation that executes as a result of a state transition. An action is triggered at a state transition. It executes and then terminates itself. The action executes instantaneously at the state transition; thus, conceptually an action is of zero duration. In practice, the duration of an action is very small compared to the duration of a state.

To show an action on a statechart, the state transition is labeled Event/Action or Event [Condition]/Action. For example, when the microwave oven transitions from Ready to Cook state back to Door Shut with Item state as a result of the Cancel input event (because the user pressed the Cancel button), the action Cancel Timer is executed (see Figure 8.1). This state transition is labeled Cancel/Cancel Timer. More than one action may be associated with a transition. The actions all execute simultaneously; consequently, they must not have any interdependencies.

Certain actions may also be depicted more concisely as being associated with the state rather than with the transition into or out of the state. These are entry and exit actions, which are represented by the reserved words entry and exit. An entry action is depicted as entry/Action and is an instantaneous action that is performed on entry to the state. An exit action is depicted as exit/Action and is an instantaneous action that is performed on exit from the state.

Examples of entry and exit actions are given in Figure 8.1. If the Start button is pressed (resulting in the Start event) while the microwave oven is in the Ready to Cook state, the statechart transitions to the Cooking state. One transition action, Start Timer, is executed; and one entry action, Start Cooking, is also executed. If the timer expires, or the Cancel button is pressed, or the door is opened, the oven will transition out of the Cooking state. In all these cases, the exit action is Stop Cooking. Having the action as an exit action instead of an action on the state transition is more concise. The alternative of having transition actions would require the action to be explicitly depicted on each of the state transitions out of the Cooking state.

In addition to actions, it is possible to have an activity executed as a result of a state transition. An activity is a computation that executes for the duration of a state. Thus, unlike an action, an activity executes for a finite amount of time. An activity is enabled on entry into the state and disabled on exit from the state. Enable and disable actions always come in pairs. The cause of the state change, which results in disabling the activity, is usually an input event from a source that is not related to the activity. In some cases, however, the activity itself generates the event that causes the state change.

One way to depict an activity on the statechart is to label the transition into the state in which the activity executes as Event/enable Activity and the transition out of the state as Event/disable Activity. However, it is more concise not to show the enable and disable actions on the transitions and instead to show the activity as being associated with the state, by depicting the activity in the state box with a dividing line between the state name and the activity name. The activity is shown as do/Activity, where do is a reserved word. This means that the activity is enabled on entry into the state and disabled on exit from the state.

For examples of activities, consider the Cruise Control statechart shown in Figure 8.2. Initially the statechart is in the Idle state. When the driver switches the ignition switch on, the Engine On event occurs and the Cruise Control statechart transitions to the Initial state. When the driver engages the cruise control lever in the ACCEL position, the Accel event occurs and the statechart transitions to the Accelerating state. During this state, the statechart executes the Increase Speed activity shown on Figure 8.2 as do/Increase Speed. In the Accelerating state, when the driver releases the cruise control lever, the Cruise event occurs, and the statechart transitions to the Cruising state, disabling the Increase Speed activity and enabling the Maintain Speed activity. The statechart executes the Maintain Speed activity for the duration of the Cruising state. If the driver places his/her foot on the brake, the Brake Pressed event occurs, and the statechart transitions to the Cruising Off state, disabling Maintain Speed. If the driver later engages the cruise control lever in the RESUME position, the Resume event occurs and the statechart transitions to the Resuming state. During this state, the statechart executes the Resume Cruising activity. When the car reaches the cruising speed, the statechart reenters the Cruising state, disabling the Resume Cruising activity and enabling the Maintain Speed activity.

Figure 8.2. Statechart for Cruise Control (with activities)

Statecharts can often be significantly simplified by the hierarchical decomposition of states, in which a superstate is decomposed into two or more interconnected sequential substates. This kind of decomposition is referred to as sequential state decomposition. The notation for state decomposition also allows both the superstate and the substates to be shown on the same diagram or, alternatively, on separate diagrams, depending on the complexity of the decomposition.

An example of hierarchical state decomposition is given in Figure 8.3, where the Door Shut with Item superstate is decomposed into the Waiting for User and Waiting for Cooking Time substates. (On the hierarchical statechart, the superstate is the outer rounded box, which contains the name of the superstate at the top left. The substates are shown as inner rounded boxes.) When the system is in the Door Shut with Item superstate, it is in one (and only one) of the substates. Because the states are executed sequentially, this kind of hierarchical state decomposition is referred to as resulting in a sequential statechart.

Figure 8.3. Hierarchical statechart for Microwave Oven Control (kernel functionality): decomposition of the Door Shut with Item state

Note that each transition into the superstate is a transition into one (and only one) of the substates on the lower-level statechart. Each transition out of the superstate has to originate from one (and only one) of the substates on the lower-level statechart.

The hierarchical statechart notation also allows a transition out of every one of the substates on a statechart to be aggregated into a transition out of the superstate. Careful use of this feature can significantly reduce the number of state transitions on a statechart. In Figure 8.3, for example, the Door Opened event may occur in either the Waiting for User or the Waiting for Cooking Time substate, in which case the statechart transitions to the Door Open with Item state. Instead of depicting the Door Opened event as causing a transition out of each substate, it is more concise to show this event causing the transition out of the superstate Door Shut with Item.

The history state is another useful characteristic in hierarchical statecharts. Indicated by an H inside a small circle, a history state is a pseudostate within a sequential superstate, which means that the superstate remembers its previously active substate after it exits. Thus, when the superstate is reentered, the previously active substate is entered.

Consider how the history state is used within the Door Shut with Item superstate shown in Figure 8.3. The history state is used to remember which of the two substates the superstate Door Shut with Item is in when an event transitions the statechart out of the superstate. Thus the previous substate is reentered when the Door Shut with Item superstate is reentered. For example, if the superstate is in the Waiting for User substate when the door is opened, the statechart will transition to Door Open with Item. When the door is closed (and assuming zero time), the Door Shut with Item superstate is reentered, and in particular the Waiting for User substate is reentered. On the other hand, if the superstate is in the Waiting for Cooking Time substate when the door is opened, then that substate is reentered when the door is closed. Without the history state, this behavior would be much more difficult to model.

Another kind of hierarchical state decomposition is concurrent state decomposition. That is, a state on one statechart can be decomposed into two or more concurrent statecharts. The two concurrent statecharts are shown separated by a dashed line. Consider the case of a superstate on a statechart that is decomposed into two lower-level concurrent statecharts. When the higher-level statechart is in the superstate, it is simultaneously in one of the substates on the first lower-level concurrent statechart and in one of the substates on the second lower-level concurrent statechart.

The most effective use of a concurrent statechart is for modeling the orthogonal aspects of the same object. Although the name concurrent statechart implies that there is concurrent activity within the object containing the statechart, this kind of decomposition can also be used to show different aspects of the same object that are not concurrent. Designing objects with only one thread of control is much simpler and is strongly recommended. Where true concurrency is required, use multiple concurrent objects and define each object with its own statechart, as described in more detail in Section 8.9.

The term orthogonal statechart describes a concurrent statechart used to depict the states of different aspects of an object. An example of using orthogonal statecharts to depict guard conditions is given in Figure 8.4 for the microwave oven statechart. The Microwave Oven Control statechart is now decomposed into two orthogonal statecharts: one for sequencing the events and actions in the oven (Microwave Oven Sequencing), and the other for Cooking Time Condition. The two statecharts are depicted on a high-level statechart, with a dashed line separating them.

Note: Microwave Oven Sequencing superstate is decomposed into Microwave Oven Control Statechart in Figure 8.1.

Figure 8.4. Orthogonal statecharts for Microwave Oven Control

At any one time, the Microwave Oven Control superstate is in one of the substates of the Microwave Oven Sequencing statechart and one of the substates of the Cooking Time Condition statechart. Cooking Time Condition is a simple statechart consisting of two states—Zero Time and Time Remaining—with Zero Time as the initial state. The Update Cooking Time event causes a transition from Zero Time to Time Remaining. Either the Timer Expired event or the Cancel Timer event can cause a transition back to Zero Time. The Microwave Oven Sequencing statechart depicts the sequence of states the oven goes through while handling a user request to cook food, as shown in Figure 8.1. The Microwave Oven Control statechart is the union of the Microwave Oven Sequencing and the Cooking Time Condition statecharts.

The Zero Time and Time Remaining states of the Cooking Time Condition statechart (see Figure 8.4) are the guard conditions checked on the Microwave Oven Sequencing statechart when the Door Closed event is received while in the Door Open with Item state (see Figure 8.1). Cancel Timer is an action (cause) on the Microwave Oven Sequencing statechart and an event (effect) on the Cooking Time Condition statechart, which causes a transition to the Zero Time state. Update Cooking Time is also an action on the former statechart and an event on the latter. Timer Expired is an event on both statecharts.

As an example of an inherited state machine, consider the Microwave Oven Control class from the microwave oven software product line, which specifies the state machine of the same name. The Microwave Oven Control kernel state machine, which captures the kernel functionality of the product line, is depicted in Figures 8.1, 8.3, and 8.4. The Microwave Oven Control state machine is then specialized to provide the additional features for the Enhanced Microwave Oven Control child state machine. The specialization of the Microwave Oven Control state-dependent control superclass to produce the Enhanced Microwave Oven Control subclass is depicted in the class diagram of Figure 8.5.

Figure 8.5. Example of inheritance of a state-dependent control class

The statechart for the Enhanced Microwave Oven Control class is shown in Figures 8.6 and 8.7. Only parts of the solution are given in this chapter; for the full solution, refer to Chapter 13. Consider the impact of the following features incorporated into the specialized state machine:

As a second example, consider the Oven Timer state machine. The kernel Oven Timer (Figure 8.8) has three states: Cooking Time Idle, Cooking Food, and Updating Cooking Time. Oven Timer & Minute Plus is a variant state machine that supports the Minute Plus optional feature (Figure 8.9). It inherits the Oven Timer state machine and adds two new transitions to address two new events when the Minute Plus key is pressed: Start Minute and Add Minute. Another inherited state machine is Oven & Recipe Timer (Figure 8.10), which also inherits from the kernel Oven Timer statechart and adds an orthogonal state machine for Recipe Timer, which consists of four sequential states: Recipe Idle, Cooking with Recipe, Updating Recipe Time, and Ending Recipe Step (see Chapter 13).

Figure 8.8. Kernel statechart for Oven Timer

Figure 8.9. Inherited statechart for Oven Timer & Minute Plus

Figure 8.10. Inherited statechart for Oven & Recipe Timer

Although this approach works quite well when the effects of individual features are considered, feature interactions become a major problem when combinations of features are considered. Each feature combination could require a new state machine. Consider the state machine for Oven & Recipe Timer & Minute Plus, which combines the Recipe and Minute Plus features. This is an example of feature interaction because the two previous state machines—the Oven & Recipe Timer statechart and the Oven Timer & Minute Plus statechart—have to be replaced by one state machine that combines the effects of the Minute Plus and Recipe features. Oven & Recipe Timer & Minute Plus inherits from Oven Timer, and then one orthogonal state machine is added for Recipe Timer (see Figure 8.10), as well as two new transitions for Minute Plus (see Figure 8.9). Note that Cooking Timer Superstate on Figure 8.10 is decomposed into the three substates on Figure 8.9.

There is a state-dependent control class for each of these statecharts. The generalization/specialization hierarchy for these classes is depicted in Figure 8.11, which shows that the kernel Oven Timer state-dependent control class is specialized into the Oven & Recipe Timer, Oven Timer & Minute Plus, and Oven & Recipe Timer & Minute Plus state-dependent control classes. The combinatorial problem is exacerbated if one more feature is added, affecting the statechart as described further in Section 8.6.

Figure 8.11. Oven Timer generalization/specialization hierarchy

Now consider some examples of both inherited and parameterized state machines from the microwave oven product line. Consider the features that affect the Microwave Oven Control state-dependent control class. These include Power Level, Recipe, TOD Clock, Minute Plus, Light, Turntable, and Beeper. If an inherited state machine were designed for each feature and feature combination, the result would be a large number of possible combinations. Each feature and feature combination would need its own inherited state machine and subclass. With a parameterized state machine, there would be only one parameterized state machine and class, so parameterization is the preferred approach.

Consider another example from the microwave oven product line—namely, Oven Timer. Two features affect this state machine: Recipe and Minute Plus. The result is four variants, as described in Section 8.4. However, consider the impact of another feature, Delayed Timer. Even with this small number of variations, the effects of the combinatorial explosion are obvious. Designing an inherited state machine for each feature and feature combination would result in eight variants to support each of the possible combinations: Timer, Timer & Minute Plus, Timer & Delayed Timer, Timer & Recipe, Timer & Minute Plus & Delayed Timer, Timer & Minute Plus & Recipe, Timer & Delayed Timer & Recipe, and Timer & Minute Plus & Delayed Timer & Recipe. It is possible to reduce the number of combinations by restricting the number of combinations—for example, by specifying beforehand certain permitted packaged feature combinations for the product line. For example, the number of variants could be reduced from eight to four if the following kernel plus three feature combinations were chosen: Timer, Timer & Minute Plus, Timer & Minute Plus & Recipe, Timer & Minute Plus & Recipe & Delayed Timer.

Because of the potential combinatorial explosion with inheritance, parameterization is the preferred approach and is used in the statecharts for the microwave oven product line case study in Chapter 13.

In state-dependent dynamic analysis, the objective is to determine the interactions among the following objects:

The interaction among these objects is depicted on a communication diagram or sequence diagram.

The main steps in the state-dependent dynamic analysis strategy are as follows:

This section describes how interaction diagrams—in particular, communication diagrams and statecharts—can be used together to model state-dependent interaction scenarios.

A message on an interaction diagram consists of an event and the data that accompanies the event. Consider the relationship between messages and events in the case of a state-dependent control object that executes a statechart. When a message arrives at the control object on a communication diagram, the event part of the message causes the state transition on the statechart. The action on the statechart is the result of the state transition and corresponds to the output event depicted on the communication diagram. In general, a message on an interaction diagram (communication or sequence diagram) is referred to as an event on a statechart; in descriptions of state-dependent dynamic scenarios, however, for conciseness only the term event is used.

A source object sends an event to the state-dependent control object. The arrival of this input event causes a state transition on the statechart. The effect of the state transition is one or more output events. The state-dependent control object sends each output event to a destination object. An output event is depicted on the statechart as an action (which can be a state transition action, an entry action, or an exit action), an enable activity, or a disable activity.

The statechart needs to be considered in conjunction with the communication diagram. In particular, it is necessary to consider the messages that are received and sent by the control object, which executes the statechart. An input event into the control object on the communication diagram must be consistent with the same event depicted on the statechart. The output event (which causes an action, enables an activity, or disables an activity) on the statechart must be consistent with the output event shown on the communication diagram.

To ensure that the communication diagram and statechart are consistent with each other, the equivalent communication diagram message and statechart event must be given the same name. Furthermore, for a given state-dependent scenario it is necessary to use the same message numbering sequence on both diagrams. Using the same sequence ensures that the scenario is represented accurately on both diagrams and can be reviewed for consistency. These issues will be illustrated in the following example.

As an example of the kernel first approach to state-dependent dynamic modeling, consider the kernel communication diagram for the Cook Food use case. Several objects support this use case, as depicted in Figure 8.14. The state-dependent control object, Microwave Oven Control, executes the Microwave Oven Control statechart and thereby controls the execution of several objects. To fully understand and design the state-dependent interactions, it is necessary to analyze how the communication diagram and statechart work together. A message on the communication diagram and its equivalent event on the statechart are given the same name and sequence number to emphasize how the diagrams work together.

Figure 8.14. Communication diagram for a kernel use case: Cook Food

Consider one event sequence initiated by an external object—namely, Keypad. At the start of this scenario, the statechart is in the Ready to Cook state (see Figure 8.1). When the user presses the Start key, the external Keypad object sends the Start Key Input message (message 6 on Figure 8.14) to the software Keypad Interface object, which in turn sends a Start message (message 6.1) to the Microwave Oven Control object. The arrival of the message triggers the Start event on the Microwave Oven Control statechart (event 6.1 on Figure 8.1), which in turn causes the state transition from the Ready to Cook state to the Cooking state. The resulting actions are the transition action Start Timer and the entry action Start Cooking. The effect of the Start Timer action (event 6.2a on Figure 8.1) is that the Microwave Oven Control object sends the Start Timer message (message 6.2a on Figure 8.14) to the Oven Timer object. The arrival of this event at Oven Timer triggers a state transition from Cooking Time Idle to Cooking Food (event 6.2a on Figure 8.8). The effect of the Start Cooking action (event 6.2 on Figure 8.1) is that the Microwave Oven Control object sends the Start Cooking message (message 6.2 on Figure 8.14) to the One-level Heating Element Interface object, which then sends Start Cooking Output (message 6.3) to the external One-level Heating Element object. Switching on this actuator physically initiates the cooking.

When the timer counts down to zero, the Oven Timer object sends the Timer Expired message (event 8.3 on Figures 8.1, 8.8, and 8.14) to Microwave Oven Control, resulting in the transition to Door Shut with Item and the execution of the exit action Stop Cooking. The effect of the Stop Cooking action (event 8.4 on Figures 8.1 and 8.14) is that the Microwave Oven Control object sends the Stop Cooking message to the One-level Heating Element Interface object, which then sends Stop Cooking Output to the external One-level Heating Element object. Switching off this actuator physically stops the cooking.