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.

Each response gets its own section inside the state block — transitions, ignore and can't happen — and all three share the single -- that closes the block.

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 — along with any ignore and can't happen sections that come between them.

The optional destination in that rule is a leftover. It used to be how an ignore was written; see Ignore for why the ignore section replaced it and why old files still parse.

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 block, 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.

A final state may still declare non-transition responses. CANNOT CLOSE above does exactly that in the Door lifecycle, following its activity with a can't happen section and no transitions section at all.

See Ignore and Can't Happen for the other two responses, and Reason tags for how their explanations are written.