Transitions

The transitions section closes out a state block and explicitly or implicitly provides a response to any incoming events.

Shlaer-Mellor defines three possible responses to an incoming event:

• Transition Follow a transition labeled with the incoming event
• Ignore Just ignore the event
• Can't happen Model level exception for the model execution platform to handle

In the first two cases the behavior is managed by modeled activity, whereas any system behavior triggered by the third is beyond the scope of the models. The model execution platform must provide a way to manage such exceptions consistent with the requirements of a deployed system.

state CLOSING
activity
transitions
    Door closed > CLOSED
    Passenger open > OPENING
    Door blocked > Count block
--

In the above example we see three explicit transition responses. Let's review the grammar for these before getting into the other two kinds of event responses.

The grammar:

transitions = transition_header transition*
transition_header = "transitions" EOL*
transition = INDENT event_name (SP '>' SP state_name)? EOL*

An unindented transitions keyword opens the section, and each transition is an indented line naming the event, then >, then the destination state.

Note that the transitions section has no -- of its own. The unindented -- that follows is the block_end of the enclosing state block, so it closes the transitions and the state together.

Spacing

The grammar asks for exactly one space on each side of the >. Not zero, not two.

Events must be declared

Every event_name here must appear in the model's Events section, and every state_name must be a real state in this file. The grammar does not check either of those but any inconsistency will be detected when the downstream popsystem module attempts to populate the metamodel.

The transitions section is optional

Unlike the activity (see Activities), transitions may be left out entirely:

state CANNOT CLOSE
activity
    Take out of service -> /R4/Cabin
--

A state with no transitions is a final state — nothing gets the instance out of it. In a born and die lifecycle, the final state may be a deletion state (see Deletion states), where the instance ceases to exist. Otherwise, be sure the final state is what you intended.

Ignoring an event

That optional destination in the grammar — (SP '>' SP state_name)? — is not an accident. An event name on its own, with no > and no destination, means the event is accepted in this state and deliberately ignored:

Consider the door's OPENING state:

transitions
    Door opened > OPEN
    Passenger close > CLOSING
    Passenger open
    Lock

Those last two events are ignored. It makes sense since if the door is already in the process of opening any open button presses by a passenger would simply be ignored in the real world.

Notice then that ignore event reponses are proper system behavior, not errors!

Can't happen

The omission of an event from the Events section implicitly indicates a Can't Happen response. So the model is saying that if an the Door closed occurs in this state, there is no prescribed model level recovery behavior and the model execution platform will have to clean up the mess.

Note: Most of the elevator xsm files (including the fudged example I inserted above) have not yet been updated with the ignore and can't happen responses prescribed in the event reponse spreadsheets that pre-date the xsm file format. For now, those tables are the ground truth, with detailed explanations of why each event reponse is considered. I will post an update when I get those xsm files properly updated! — LS 26-7-27