Single message run-to-completion processing

IBM® Rational® Rhapsody® assumes that statecharts react to a single message applied by some external actor to the statechart. The external actor can be either the system event queue or another object.

Message processing by a statechart is partitioned into steps. In each step, a message is dispatched to the statechart for processing.

Once a message is dispatched, it might enable transitions triggered by the message. Each orthogonal component can fire one transition at most as a result of the message dispatch. Conflicting transitions will not fire in the same step.

The order in which selected transitions fire is not defined. It is based on an arbitrary traversal that is not explicitly defined by the statechart.

Each component can execute one transition as a result of the message. Once all components complete executing the transition, the message is said to be consumed, and the step terminates.

After reacting to a message, the statechart might reach a state configuration in which some of the states have outgoing, active null transitions (transient configurations). In this case, further steps need to be taken until the statechart reaches a stable state configuration (no more transitions are active). Null transitions are triggered by null events, which are dispatched to the statechart whenever a transient-configuration is encountered. Null events are dispatched in a series of steps until a stable configuration is reached. Once a stable configuration is reached, the reaction to the message is completed, control returns to the dispatcher, and new messages can be dispatched.

Note: Theoretically, it is possible that the statechart will never reach a stable configuration. The practical solution is to set a limit to the maximum number of steps allowed for a statechart to reach a stable configuration. In the current implementation, reaching the maximum number of steps is treated as if the message processing has been completed.

Feedback