Transitions

When dynamic conditions evolve, objects change state by following the rules described in the state machine associated to their classes. Statechart diagrams are directed graphs. States are linked via unidirectional connections called transitions. The passing from one state to another is performed when a transition is triggered by an event that occurs within the problem domain. The change from one state to another is instantaneous, since the system must always be in a known state.

A transition enables going from one state to another; it is represented using an arrow drawn from the initial state to the final state

Transitions do not necessarily link distinct states. The following example describes a fragment of a lexical analyzer. The recognition of lexical units is performed in a 'reading' state. The state machine remains in that state as long as the characters read are not separators.

Events

An event corresponds to the occurrence of a given situation in the problem domain. In contrast to lasting states, an event is by nature an information snapshot that must be treated immediately. An event is used as a trigger to go from one state to another. Transitions specify paths in the statechart. Events determine which paths must be followed. Events, transitions, and states cannot be dissociated from the description of dynamic behavior. An object, when put in a given state, waits for the occurrence of an event to go to a different state. From that perspective, objects behave as passive elements that are controlled by events coming from the system.

An event triggers the transition associated with it.

The general syntax of an event looks like this:

Name_Of_The_Event (Parameter_Name : Type, ...)

The complete specification of an event includes:

In the following example, each transition holds the event that triggers it:

Communication by events is asynchronous, atomic, and unidirectional. An object may send an event to another object, which must always be able to interpret it.

An object may send an asynchronous event to another object

Requirements for communication by synchronous events or bi-directional exchanges can be represented using two asynchronous exchanges going in opposite directions:

In this case, it is the role of the object sending the request to wait for the answer. This implies that the state machine describing it has a sequence of the following type:

© 1997 Editions, Eyrolles, Paris, France . All rights reserved.