Section 8.6. Event Processing

8.6. Event Processing

Information within a state machine is conveyed via events. Events can be triggered by things outside of the state machine or as part of an activity executing within a state. An event can have parameters and attributes you can use when processing the event.

8.6.1. Dispatch

As events are triggered, they are added to an event pool. Once added to the event pool, events are sent out for processing by the state machine or are dispatched. The order of event dispatch and processing isn't specified by UML. This allows state machines to impose their own prioritization schemes on events if desired.

When dispatching events, a new event is dispatched and processed only after the previous event has been fully processed. This doesn't mean that all do activities (see "Activities") are complete, just that the state machine is in a well-defined condition, with entry and exit activities completed. This is called run-to-completion by the UML specification.

After an event is dispatched, if no transitions are enabled and the event isn't deferred (see "Deferred Events"), the event is discarded, and the next event can be processed.

If an event does trigger one or more transitions, such as in the case of orthogonal states (see "Composite States"), the order in which the transitions are fired isn't specified by UML. Once all transitions have been fired, the event is considered complete.

If a synchronous activity is triggered by a transition, the event processing isn't complete until the invoked object has finished its run-to-completion step.

When dispatching events, UML allows for transitions to conflict. However, only one out of a set of conflicting transitions is allowed to execute. If an event triggers two different transitions from the same state, the state machine must select only one transition to execute. The following rules determine which transition executes:

• A transition starting from a substate has higher priority than a transition from any of its containing states, and therefore is executed.

• Transitions from an orthogonal state are considered to have the same priority (assuming they are at the same level), so the first transition encountered is executed.

8.6.2. Deferred Events

You can list events that should be deferred from dispatching while in a given state. You show a deferred event by listing the event, followed by a forward slash and the keyword defer within the state. Figure 8-18 shows a state that defers the cancel event. If the cancel event does fire, it is held in the event pool until the state machine leaves this state.

Figure 8-18. State with deferred cancel event

If an event is triggered that doesn't cause a transition, and it is on the deferred list, it will be held in an event pool while nondeferred events are dispatched. The event will be held in the pool until the state machine enters a state in which the event is no longer deferred, or in which the event would cause a transition. The event is then dispatched.

To clarify, events that cause a transition can't be deferred. If the state machine enters a state that doesn't defer an event, and the event doesn't cause a transition, the event is lost.