Statechart diagram

A statechart diagram shows the sequences of states that an object or an interaction goes through during its life in response to received stimuli, together with its responses and actions.

The semantics and notation described in this chapter are substantially those of David Harel's statecharts with modifications to make them object-oriented. His work was a major advance on the traditional flat state machines. Statechart notation also implements aspects of both Moore machines and Mealy machines, traditional state machine models.

 

Statechart diagram

Semantics

A state machine is a graph of states and transitions that describes the response of an object of a given class to the receipt of outside stimuli. A state machine is attached to a class or a method

Notation

A statechart diagram represents a state machine. The states are represented by state symbols and the transitions are represented by arrows connecting the state symbols. States may also contain subdiagrams by physical containment and tiling.

Mapping

A statechart diagram maps into a StateMachine. That StateMachine may be attached to a Class or a Method but there is no explicit notation for this.

 

States

Semantics

A state is a condition during the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event. An object remains in a state for a finite (non-instantaneous) time.

Actions are atomic and non-interruptible. A state may correspond to ongoing activity. Such activity is expressed as a nested state machine. Alternately, ongoing activity may be represented by a pair of actions, one that starts the activity on entry to the state and one that terminates the activity on exit from the state.

Each subregion of a state may have initial states and final states. A transition to the enclosing state represents a transition to the initial state. A transition to a final state represents the completion of activity in the enclosing region; completion of activity in all concurrent regions represents completion of activity by the enclosing state and triggers a ''completion of activity'' event'' on the enclosing state. Completion of the outermost state of an object corresponds to its death.

Notation

A state is shown as a rectangle with rounded corners. It may have one or more compartments. The compartments are all optional. They are as follows:

Name compartment. Holds the (optional) name of the state as a string. States without names are ''anonymous'' and are all distinct. It is undesirable to show the same named state twice in the same diagram, however, as confusion may ensue.

Internal transition compartment. Holds a list of internal actions or activities performed in response to events received while the object is in the state, without changing state. These have the format:

 

event-name argument-list '[' guard-condition ']' ' /' action-expression

Each event name or pseudo-event name may appear at most once in a single state.

The following special actions have the same form but represent reserved words that cannot be used for event names:

 

'entry' '/' action-expression An atomic action performed on entry to the state

 

'exit' '/' action-expression An atomic action performed on exit from the state

 

Entry and exit actions may not have arguments or guard conditions (because they are invoked implicitly, not explicitly). However, the entry action at the top level of the state machine for a class may have parameters that represent the arguments that it receives when it is created.

 

Action expressions may use attributes and links of the owning object and parameters of incoming transitions (if they appear on all incoming transitions).

The following keyword represents the invocation of a nested state machine:

 

'do' '/' machine-name (argument-list)

 

The machine-name must be the name of a state machine that has an initial and final state. If the nested machine has parameters, then the argument list must match correctly. When this state is entered, after any entry action then execution of the nested state machine begins with its initial state. When the nested state machine reaches its final state, then any exit action in the current state is performed and the current state is considered completed and may take a transition based on implicit completion of activity.

Example

Mapping

A state symbol maps into a State. See the next section for further details on which kind of state.

The name string in the symbol maps to the name of the state. Two symbols with the same name map into the same state. However, each state symbol with no name (or an empty name string) maps into a distinct anonymous State.

An internal action string with the name ''entry'' or ''exit'' maps into an association: the source is the State corresponding to the enclosing state symbol; the target is an ActionSequence that maps the action expression; the association is the Entry action or the Exit action association.

An internal action string with the name ''do'' maps into the invocation of a nested state machine.

Any other internal action maps into an internal Association from the corresponding State to a Transition. The action expression maps into the ActionSequence and Guard for the Transition. The event name and arguments map into an Event corresponding to the event name and arguments; the Transition has a trigger Association to the Event.

Composite states

Semantics

A state can be decomposed using and-relationships into concurrent substates or using or-relationships into mutually exclusive disjoint substates. A given state may only be refined in one of these two ways. Its substates can may be refined in the same way or the other way.

A newly-created object starts in its initial state. The event that creates the object may be used to trigger a transition from the initial state symbol.

An object that transitions to its outermost final state ceases to exist.

Notation

An expansion of a state shows its fine structure. In addition to the (optional) name and internal transition compartments, the state may have an additional compartment that contains a region holding a nested diagram. For convenience and appearance, the text compartments may be shrunk horizontally within the graphic region.

An expansion of a state into concurrent substates is shown by tiling the graphic region of the state using dashed lines to divide it into subregions. Each subregion is a concurrent substate. Each subregion may have an optional name and must contain a nested state diagram with disjoint states. The text compartments of the entire state are separated from the concurrent substates by a solid line.

An expansion of a state into disjoint substates is shown by showing a nested state diagram within the graphic region.

An initial (pseudo)state is shown as a small solid filled circle. In a top-level state machine, the transition from an initial state may be labeled with the event that creates the object; otherwise it must be unlabeled. If it is unlabeled, it represents any transition to the enclosing state. The initial transition may have an action. The initial state is a notational device; an object may not be in such a state but must transition to an actual state.

A final (pseudo)state is shown as a circle surrounding a small solid filled circle (a bull's eye). It represents the completion of activity in the enclosing state and it triggers a transition on the enclosing state labeled by the implicit activity completion event (usually displayed as an unlabeled transition).

Example

Mapping

A state symbol maps into a State. If the symbol has no subdiagrams in it, it maps into a SimpleState; if it is tiled by dashed lines into subregions then it maps into a CompositeState with the isConcurrent value true, otherwise it maps into a CompositeState with the isConcurrent value false.

An initial state symbol or a final state symbol map into a Pseudostate of kind initial or final.

 

Events

Semantics

An event is a noteworthy occurrence. For practical purposes in state diagrams, it is an occurrence that may trigger a state transition. Events may be of several kinds (not necessarily mutually exclusive):

 

a designated condition becoming true (usually described as a boolean expression). This is a ChangeEvent. These are notated with the keyword when followed by a boolean expression in parentheses. The event occurs whenever the value of the expression changes from false to true. Note that this is different from a guard condition: A guard condition is evaluated once whenever its event fires; if it is false then the transition does not occur and the event is lost. Example: when (balance < 0).

 

receipt of an explicit signal from one object to another. This is a SignalEvent. One of these is notated by the signature of the event as a trigger on a transition.

 

receipt of a call for an operation by an object. This is a CallEvent. These are notated by the signature of the operation as a trigger on a transitions. There is no visual difference from a signal event; it is assumed that the names with distinguish them.

 

passage of a designated period of time after a designated event (often the entry of the current state) or the occurrence of a given date/time. This is a TimeEvent. These are notated as time expressions as triggers on transitions. One common time expression is the passage of time since the entry to the current state; this is notated with the keyword after followed by an amount of time in parentheses. Example: after (10 seconds).

The event declaration has scope within the package it appears in and may be used in state diagrams for classes that have visibility inside the package. An event is not local to a single class.

Notation

A signal or call event can be defined using the following format:

 

event-name '(' comma-separated-parameter-list ')'

A parameter has the format:

 

parameter-name ':' type-expression

A signal can be declared using the «signal» keyword on a class symbol in a class diagram. The parameters are specified as attributes. A signal can be specified as a subclass of another signal. This indicates that an occurrence of the subevent triggers any transition that depends on the event or any of its ancestors.

An elapsed-time event can be specified with the keyword after followed by an expression that evaluates (at modeling time) to an amount of time, such as ''after (5 seconds)'' or after (10 seconds since exit from state A)''. If no starting point is indicated, then it is the time since the entry to the current state. Other time events can be specified as conditions, such as when (date = Jan. 1, 2000).

A condition becoming true is shown with the keyword when followed by a boolean expression. This may be regarded as a continuous test for the condition until it is true, although in practice it would only be checked on a change of values (and there are ways to determine when it must be check). This is mapped into a ChangeEvent in the model.

Signals can be declared on a class diagram with the keyword «signal» on a rectangle symbol. These define signal names that may be used to trigger transitions. Their parameters are shown in the attribute compartment. They have no operations. They may appear in a generalization hierarchy. Note that they are not real classes and may not appear in relationships to real classes.

Example

Mapping

A class box with stereotype «signal» maps into a Signal; the name and parameters are given by the name string and the attribute list of the box. Generalization arrows between signal class boxes map into Generalization relationships between the Signal.

The usage of an event string expression in a context requiring an event maps into an implicit reference of the Event with the given name. It is an error if various uses of the same name (including any explicit declarations) do not match.

 

Simple transitions

Semantics

A simple transition is a relationship between two states indicating that an object in the first state will enter the second state and perform certain specified actions when a specified event occurs if specified conditions are satisfied. On such a change of state the transition is said to ''fire''. The trigger for a transition is the occurrence of the event labeling the transition. The event may have parameters, which are available within actions specified on the transition or within actions initiated in the subsequent state. Events are processed one at a time. If an event does not trigger any transition, it is simply ignored. If it triggers more than one transition within the same sequential region (i.e., not in different concurrent regions), only one will fire; the choice may be nondeterministic if a firing priority is not specified.

Notation

A transition is shown as a solid arrow from one state (the source state) to another state (the target state) labeled by a transition string. The string has the following format:

 

event-signature '[' guard-condition ']' '/' action-expression '^' send-clause

The event-signature describes an event with its arguments:

 

event-name '(' parameter ',' . . . ')'

The guard-condition is a Boolean expression written in terms of parameters of the triggering event and attributes and links of the object that owns the state machine. The guard condition may also involve tests of concurrent states of the current machine (or explicitly designated states of some reachable object); for example, ''in State1'' or ''not in State2''. State names may be fully qualified by the nested states that contain them, yielding path names of the form ''State1::State2::State3''; this may be used in case same state name occurs in different composite state regions of the overall machine.

The action-expression is a procedural expression that is executed if and when the transition fires. It may be written in terms of operations, attributes, and links of the owning object and the parameters of the triggering event. The action-clause must be an atomic operation, that is, it may not be interruptible; it must be executed entirely before any other actions are considered. The transition may contain more than one action clause (with delimiter).

'The send-clause is a special case of an action, with the format:

 

destination-expression '.' destination-message-name '(' argument '.' . . . ')'

The transition may contain more than one send clause (with delimiter). The relative order of action clauses and send clauses is significant and determines their execution order.

The destination-expression is an expression that evaluates to an object or a set of objects.

The destination-message-name is the name of a message (operation or signal) meaningful to the destination object(s).

The destination-expression and the arguments may be written in terms of the parameters of the triggering event and the attributes and links of the owning object.

Branches. A simple transition may be extended to include a tree of decision symbols (see Decisions). This is equivalent to a set of individual transitions, one for each path through the tree, whose guard condition is the ''and'' of all of the conditions along the path.

Transition times. Names may be placed on transitions to designate the times at which they fire. See the section on Transition Times.

Example

right-mouse-down (location) [location in window] / object := pick-object (location)
^ object.highlight ()

The event may be of any of the types; selecting the type depends on the syntax of the name (for time events, for example) but SignalEvents and CallEvents are not distinguishable by syntax and must be discriminated by their declaration elsewhere.

Mapping

A transition string and the transition arrow that it labels together map into a Transition and its attachments. The arrow connects two state symbols; the Transition has the corresponding States as its source (the state at the tail) and destination (the state at the head) States in associations to the Transition.

The event name and parameters map into an Event element, which may be a Signal-Event, a CallEvent, or a TimeExpression (if it has the proper syntax). The event is attached as a trigger Association to the Transition.

The guard condition maps into a Guard element attached to the Transition.

An action expression maps into an ActionSequence attached as an effect Association to the Transition; the target object expression (if any) in the expression maps into a target ObjectSetExpression. Each term in the action expression maps into an Action that is a part of the ActionSequence. A send clause maps into a RaiseAction with an ObjectSetExpression for the destination.

A transition time label on a transition maps into a TimingMark attached to the Transition.

 

Complex transitions

A complex transition may have multiple source states and target states. It represents a synchronization and/or a splitting of control into concurrent threads without concurrent substates.

Semantics

A complex transition is enabled when all of the source states are occupied. After a complex transition fires all of its destination states are occupied.

Notation

A complex transition is shown as a short heavy bar (a synchronization bar, which can represent synchronization, forking, or both). The bar may have one or more solid arrows from states to the bar (these are the source states); the bar may have one or more solid arrows from the bar to states (these are the destination states). A transition string may be shown near the bar. Individual arrows do not have their own transition strings.

Example

Mapping

A bar with multiple transition arrows leaving it maps into a fork Pseudostate; a bar with multiple transition arrows entering it maps into a join Pseudostate. The Transitions corresponding to the incoming and outgoing arrows attach to the pseudostate as if it were a regular state. If a bar has multiple incoming and multiple outgoing arrows, then it maps into a Join connected to a Fork pseudostate by a single Transition with no attachments.