VISUAL FORMALISM, STATECHARTS, AND STATEMATE

STATECHARTS 135

to another state takes place when the associated event(s) and condition(s) are enabled. A state can be decomposed into lower-level states via refinement, and a set of states can be combined into a higher-level state via clustering. This hierarchical specification approach makes it possible for the specifier to zoom-in and zoom-out of a section of the Statecharts specification, thus partially remedying the exponentialstate explosion problem in classical FSMs. Furthermore, AND and OR clustering relations, together with the notions of state exclusivity and orthogonality, can readily support concurrency and independence in system specification. As we will see in this chapter, these features dramatically reduce the state-explosion problem by not considering all states in a classical FSM at once.

To develop a comprehensive tool capable not only of system specification, [Harel et al., 1990b] extended the work on Statecharts, which is capable also of behavioral description, to derive high-level languages for structural and functional specifications. The language module-charts is used to describe a structural view with a graphical display of the components of the system. The language activity-charts is used to describe a functional view with a graphical display of the functions of the system. They also added mechanisms that provide a friendly user interface, simulated system executions, dynamic analysis, code generation, and rapid prototyping. The entire specification and development environment is known as STATEMATE.

5.1 STATECHARTS

Statecharts [Harel, 1987] is an extension of classical finite-state machines and their visual counterparts, state-transition diagrams. This visual language is better than classical FSMs for specifying the behavior of reactive systems. It supports the AND or OR decomposition of states into substates with an instantaneous broadcast communication between states at different levels. Statecharts thus combines the concepts of state diagrams, depth, orthogonality, and broadcast communication into one specification language.

5.1.1 Basic Statecharts Features

In Statecharts, labeled boxes are used to denote states and directed edges indicate the transitions between states. A transition takes place when the associated event(s) occur(s) and condition(s) is/are satisfied. More precisely, an expression labeling a transition is of the form

event[condition]/action

where event is the event enabling the transition, condition is the condition which must hold for event to enable transition, and action is the action that is executed at precisely the time when the transition is taken. Usually, events and conditions can be treated as inputs and actions as outputs, as in traditional FSMs. However, these three parts of the transition label are optional. A selected list of special events, conditions,

136 VISUAL FORMALISM, STATECHARTS, AND STATEMATE

Figure 5.1 Special events, conditions, and actions.

and actions is shown in Figure 5.1. Extensions to FSMs include the use of variables in the label of a transition, logical comparisons in conditions, and assignnment statements in actions.

Example. The following label for a transition indicates that when the system is in the countdown state, the emergency state is not active, and the triggering event “started(ignition) occurs,” then both the action “start(launch)” and the two assignments (“a := b + c + 1” and “d := a + 2”) are executed in parallel:

started(ignition)[in(countdown) and not active(emergency)]/start(launch);

a := b + c + 1; d := a + 2

Note that the expressions to the right of the assign operator “:=” must be side-effect free. The parallel execution of these assignments consists of the evaluation of all these expressions using the values of the variables prior to the assignments, followed by updating the variables to the left of the assign operator with the values of the corresponding expressions. Suppose a = 1, b = 2, c = 3. Then after the transition is taken: a = 6, d = 3. Chapter 10 describes additional details of parallel assignments in the context of real-time rule-based systems.

Actions can also be associated with the entrance to and an exit from a state at any level.

Before we proceed to describe more details of the syntax and semantics of Statecharts, we illustrate several basic concepts of Statecharts with an automotive example.

Example. Figure 5.2 shows two Statecharts of specifications of the behavior of the pedals of an automobile. Here, the specified parts of the automobile is the specified system. Both specifications show that the automobile can be in one of three states:

Figure 5.2 Two Statecharts of the behavior of a car’s pedals.

stop, move, and slow. Figure 5.2(a) shows that (1) the transition from the state “stop” to the state “speedup” occurs when the accelerator is applied; (2) the transition from the state “speedup” to the state “slow” occurs when the brake is applied provided that the condition within the bracket is true (accelerator is not applied); (3) the transition from the state “slow” to the state “speedup” occurs when the accelerator is applied; and (4) the transitions from the states “speedup” and “slow” to the state “stop” occur when the hand brake is applied.

OR-Decomposition By clustering the states “speedup” and “slow” into a new state “move,” we obtain an equivalent specification in Figure 5.2(b). Now, saying that the automobile (specified system) is in state “move” means that it is either in state “speedup” OR state “slow.” The transition labeled “apply hand brake” leaving state “move” is a high-level interrupt and denotes an exit from “move.” Whether the system is in state “speedup” OR “slow” does not matter; this transition takes the system from either state to state “stop.” Note that the transition labeled “apply accelerator” from state “stop” to the outside of state “move” seems to be ambiguous. However, the internal default arrow attached to state “speedup” means the system enters state “speedup” if the transition labeled “apply accelerator” is taken. When the system designer works with the higher control levels of the automobile, there is no need to view the details within state “move.” Thus the specification and analysis complexity can be simplified with OR-decomposition through clustering.

AND-Decomposition Another way to reduce the number of states is to use AND-decomposition, as shown in the following example.

Example. Figures 5.3 and 5.4 show two equivalent Statecharts of specifications of a solution to the two-process mutual exclusion problem. In any correct solution, only one process is allowed in the critical section (c1 or c2) at any given time. The first Statechart specification, in Figure 5.3, resembles a classical FSM, whereas the second Statechart specification, in Figure 5.4, applies AND-decomposition to reduce

138 VISUAL FORMALISM, STATECHARTS, AND STATEMATE

Figure 5.3 Statechart A of a solution to the mutual exclusion problem.

Figure 5.4 Statechart B of a solution to the mutual exclusion problem.

the number of states. In the second specification, if the system is in state “mutex,” then it must be in both states “process 1” (p1) and “process 2” (p2). In the first specification, the initial entrance is to state “n1,n2,” whereas in the second specification, the unspecified entrance to “mutex” is resolved by the default arrows to enter the pair {n1,n2}.

Transitions in “process 1” and “process 2” take place concurrently as governed by the transition labels. Therefore, if “p1 requests” is true, then the system will be in state pair {t1,n2}. If “p2 requests” is true simultaneously, then the system will be

STATECHARTS 139

in pair {t1,t2}. Here, “process 1” and “process 2” are called orthogonal state components obtained by AND-decomposition. AND-decomposition can be applied at any level of states and is more convenient than single-level communicating FSMs. As seen in this example, this orthogonality feature can reduce the state-explosion problem.

Next we describe selected features of Statecharts.

Delays and Timeouts The event expression timeout(event, number) represents the event that happens right after the specified number of time units have passed since the occurrence of the specified event. In a real-time system, it is often required to specify that the system stays in a particular state for a certain period of time. This can be done graphically by a box (representing the state) with a squiggle (a resistorlike notation), and a numerical bound is specified next to it. Both lower and upper bounds can be specified. In the case of a state with a lower bound and an exit, events do not apply in this state prior to the lower bound. After the system stays in this state for the specified period of time, it moves to another state.

In the specification of real-time systems, a need exists to specify an upper bound or a lower bound on the time spent in a state. A box with a squiggle along with a time upper bound (or lower bound) represents a state with a duration. The syntax for the duration specification is t1 < t2, where either ti may be omitted. A generic event stands for timeout(entered state, bound), where state is the source of the transition and bound is the specified bound.

Condition and Selection Entrances To reduce the number of line drawings in a complicated entrance to substates of a superstate, Statecharts employs two connectives represented by a circle. The conditional connective C replaces two or more arrows from outside a state to this state’s substates. This is done by drawing one arrow from outside the state to the C-connective (a circle with a C in it) and then drawing arrows from the connective to their respective substates. The user has the option of separately specifying the arrows from the C-connective to their corresponding states.

The selection connective S also replaces two or more arrows from outside a state to this state’s substates. Here, the state to be entered is selected by the value of a generic event and this value is one of the values labeling the substates. For example, a robotic arm operator can move the robot arm “up,” “down,” “left,” “right,” “forward,” or “backward” by pressing one of the corresponding six buttons. These six events can be modeled by six substates within a “move” state. There is an arrow enters the “move” state from outside this state to the S-connective (a circle with an ‘S’ in it), but no arrows need to be drawn from this connective to the six states.

Unclustering If the Statechart description is large, we can uncluster it by keeping the parts of interest large. This is done by drawing parts of the Statechart outside of their natural boundaries. This technique is useful for describing a large system. However, unclustering should not be used often since it can create a tree-like structure.