*Description
A transition is a directed relationship between a source vertex and a target vertex. It may be part of a compound transition,
which takes the state machine from one state configuration to another, representing the complete response of the state machine
to an occurrence of an event of a particular type.
Attributes
Issue 9191 -add default value
• kind: TransitionKind [1] See definition of TransitionKind . Default value is external.
Associations
• trigger: Trigger[0..*] Specifies the triggers that may fire the transition.
Issue 8443 - add subsets constraint 9196 - change subsets constraint (override 8443)
• guard: Constraint[0..1] A guard is a constraint that provides a fine-grained control over the firing of the transition. The guard is evaluated when an event occurrence is dispatched by the state machine. If the guard is true at that time, the transition may be enabled, otherwise, it is disabled. Guards should be pure expressions without side effects. Guard expressions with side effects are ill formed. {Subsets Namespace ::ownedRule}
• effect: Behavior[0..1] Specifies an optional behavior to be performed when the transition fires.
• source: Vertex [1] Designates the originating vertex (state or pseudostate) of the transition.
• target: Vertex [1] Designates the target vertex that is reached when the transition is taken.
Issue 8443 - replace ‘replacedTransition’ with ‘redefinedTransition’ 9093 - add subsets constrain
• redefinedTransition: Transition[0..1] The transition of which this is a replacement. {Subsets RedefinableElement ::redefinedElement}
Issue 8443 - add subsets constraint 9188 - replace subsets with redefines constraint
• /redefinitionContext: Classifier[1] References the classifier in which context this element may be redefined. {Redefines RedefinableElement ::redefinitionContext}
• container [1] Designates the region that owns this transition. (Subsets Namespace .namespace)
Constraints
[1] A fork segment must not have guards or triggers.
(source.oclIsKindOf(Pseudostate) and source.kind = #fork) implies (guard->isEmpty() and trigger->isEmpty())
Issue 8443 - fix parentheses
[2] A join segment must not have guards or triggers.
((target.oclIsKindOf(Pseudostate)) and (target.kind = #join)) implies ((guard->isEmpty() and (trigger->isEmpty()))
[3] A fork segment must always target a state.
(source.oclIsKindOf(Pseudostate) and source.kind = #fork) implies (target.oclIsKindOf(State))
[4] A join segment must always originate from a state.
(target.oclIsKindOf(Pseudostate) and target.kind = #join) implies (source.oclIsKindOf(State))
[5] Transitions outgoing pseudostates may not have a trigger.
source.oclIsKindOf(Pseudostate) and ((source.kind <> #junction) and (source.kind <> #join) and (source.kind <> #initial))
implies trigger->isEmpty()
[6] An initial transition at the topmost level (region of a statemachine) either has no trigger or it has a trigger with the
stereotype create.
self.source.oclIsKindOf(Pseudostate) implies(self.source.oclAsType(Pseudostate).kind = #initial) implies(self.source.container = self.stateMachine.top) implies((self.trigger->isEmpty) or
(self.trigger.stereotype.name = 'create'))
[7] In case of more than one trigger, the signatures of these must be compatible in case the parameters of the signal are
assigned to local variables/attributes.
[8] The redefinition context of a transition is the nearest containing statemachine.
redefinitionContext =
let sm = containingStateMachine() in
if sm.context->isEmpty() or sm.general->notEmpty() then
sm
else
sm.context
endif
Additional operations
[1] The query isConsistentWith() specifies that a redefining transition is consistent with a redefined transition provided
that the redefining transition has the following relation to the redefined transition: A redefining transition redefines all
properties of the corresponding redefined transition, except the source state and the trigger.
[2] The query containingStateMachine() returns the state machine that contains the transition either directly or transitively.
context Transition::containingStateMachine() : StateMachine
post: result = container.containingStateMachine()
Semantics
High-level transitions
Transitions originating from composite states themselves are called high-level or group transitions. If triggered, they result
in exiting of all the substates of the composite state executing their exit activities starting with the innermost states
in the active state configuration. Note that in terms of execution semantics, a high-level transition does not add specialized
semantics, but rather reflects the semantics of exiting a composite state. A high-level transition with a target outside the
composite state will imply the execution of the exit action of the composite state, while a high-level transition with a target
inside the composite state will not imply execution of the exit action of the composite state.
Compound transitions
A compound transition is a derived semantic concept, represents a semantically complete path made of one or more transitions,
originating from a set of states (as opposed to pseudo-state) and targeting a set of states. The transition execution semantics
described below refer to compound transitions.
In general, a compound transition is an acyclical unbroken chain of transitions joined via join, junction, choice, or fork
pseudostates that define path from a set of source states (possibly a singleton) to a set of destination states, (possibly
a singleton). For self-transitions, the same state acts as both the source and the destination set. A (simple) transition
connecting two states is therefore a special common case of a compound transition.
The tail of a compound transition may have multiple transitions originating from a set of mutually orthogonal regions that
are joined by a join point.
The head of a compound transition may have multiple transitions originating from a fork pseudostate targeted to a set of mutually
orthogonal regions.
In a compound transition multiple outgoing transitions may emanate from a common junction point. In that case, only one of
the outgoing transitions whose guard is true is taken. If multiple transitions have guards that are true, a transition from
this set is chosen. The algorithm for selecting such a transition is not specified. Note that in this case, the guards are
evaluated before the compound transition is taken.
In a compound transition where multiple outgoing transitions emanate from a common choice point, the outgoing transition whose
guard is true at the time the choice point is reached, will be taken. If multiple transitions have guards that are true, one
transition from this set is chosen. The algorithm for selecting this transition is not specified. If no guards are true after
the choice point has been reached, the model is ill formed.
Internal transitions
An internal transition executes without exiting or re-entering the state in which it is defined. This is true even if the
state machine is in a nested state within this state.
Completion transitions and completion events
A completion transition is a transition originating from a state or an exit point but which does not have an explicit trigger,
although it may have a guard defined. A completion transition is implicitly triggered by a completion event. In case of a
leaf state, a completion event is generated once the entry actions and the internal activities (do activities) have been completed.
If no actions or activities exist, the completion event is generated upon entering the state. If the state is a composite
state or a submachine state, a completion event is generated if either the submachine or the contained region has reached
a final state and the state’s internal activities have been completed. This event is the implicit trigger for a completion
transition. The completion event is dispatched before any other events in the pool and has no associated parameters. For instance,
a completion transition emanating from an orthogonal composite state will be taken automatically as soon as all the orthogonal
regions have reached their final state.
If multiple completion transitions are defined for a state, then they should have mutually exclusive guard conditions.
Enabled (compound) transitions
A transition is enabled if and only if:
• All of its source states are in the active state configuration.
• One of the triggers of the transition is satisfied by the event (type) of the current occurrence. An event satisfies a trigger if it matches the event specified by the trigger. In case of signal events, since signals are generalized concepts, a signal event satisfies a signal event associated with the same signal or a generalization thereof.
• If there exists at least one full path from the source state configuration to either the target state configuration or to a dynamic choice point in which all guard conditions are true (transitions without guards are treated as if their guards are always true).
Since more than one transition may be enabled by the same event, being enabled is a necessary but not sufficient condition
for the firing of a transition.
Guards
In a simple transition with a guard, the guard is evaluated before the transition is triggered.
In compound transitions involving multiple guards, all guards are evaluated before a transition is triggered, unless there
are choice points along one or more of the paths. The order in which the guards are evaluated is not defined.
If there are choice points in a compound transition, only guards that precede the choice point are evaluated according to
the above rule. Guards downstream of a choice point are evaluated if and when the choice point is reached (using the same
rule as above). In other words, for guard evaluation, a choice point has the same effect as a state.
Guards should not include expressions causing side effects. Models that violate this are considered ill formed.
Transition execution sequence
Every transition, except for internal and local transitions, causes exiting of a source state, and entering of the target
state. These two states, which may be composite, are designated as the main source and the main target of a transition.
The least common ancestor (LCA) state of a (compound) transition is a region or an orthogonal state that is the LCA of the
source and target states of the (compound) transition. The LCA operation is an operation defined for the StateMachine class.
If the LCA is a Region , then the main source is a direct subvertex of the region that contains the source states, and the
main target is the subvertex of the region that contains the target states. In the case where the LCA is an orthogonal state,
the main source and the main target are both represented by the orthogonal state itself. The reason is that a transition crossing
regions of an orthogonal state forces exit from the entire orthogonal state and re-entering of all of its regions.
Examples
• The common simple case: A transition t between two simple states s1 and s2, in a composite state. Here the least common
ancestor of t is s, the main source is s1, and the main target is s2.
Note that a transition from one region to another in the same immediate enclosing composite state is not allowed: the two
regions must be part of two different composite states. Here least common ancestor of t is s, the main source is s and the
main target is s, since s is an orthogonal state as specified above.
Once a transition is enabled and is selected to fire, the following steps are carried out in order:
• The main source state is properly exited.
• Behaviors are executed in sequence following their linear order along the segments of the transition: The closer the behavior to the source state, the earlier it is executed.
• If a choice point is encountered, the guards following that choice point are evaluated dynamically and a path whose guards are true is selected.
• The main target state is properly entered.
Transition redefinition
A transition of an extended state machine may in the state machine extension be redefined. A redefinition transition redefines
all properties of the corresponding replaced transition in the extended state machine, except the source state and the trigger.
Notation
The default notation for a transition is defined by the following BNF expression:
Issue 8752 - replace ‘activity-expression’ with ‘behavior-expression’
8938 - make entire trigger optional (add brackets around the whole expression)
<transition> ::= [<trigger> [‘,’ <trigger>]* [‘[‘ <guard-constraint>’]’] [‘/’ <behavior-expression>]]
However, relative to its use for signal events (see SignalEvent (from Communications ) on page 468) and change events
(see
ChangeEvent (from Communications ) on page 454), the
<assignment-specification> when used in transitions is extended as follows:
<assignment-specification> ::= <attr-spec> [‘,’ <attr-spec>]*<attr-spec> ::= <attr-name> [‘:’ <type-name>]
Note that <attr-name> is the name of an attribute to which the corresponding parameter value of the event is assigned. If
a <type-name> is included with the attribute name, then it represents an implicit declaration of a local attribute of that
type in the context of the effect activity to which the corresponding parameter value of the event is assigned.
The <guard-constraint> is a Boolean expression written in terms of parameters of the triggering event and attributes and links
of the context object. The guard constraint may also involve tests of orthogonal states of the current state machine, or explicitly
designated states of some reachable object (for example, in State1 or not in State2). State names may be fully qualified by
the nested states and regions that contain them, yielding pathnames of the form (Region OrState1::Region OrState2::State3. This
may be used in case the same state name occurs in different composite state regions.
The behavior-expression is executed if and when the transition fires. It may be written in terms of operations, attributes,
and links of the context object and the parameters of the triggering event, or any other features visible in its scope. The
behavior expression may be an action sequence comprising a number of distinct actions including actions that explicitly generate
events, such as sending signals or invoking operations. The details of this expression are dependent on the action language
chosen for the model.
Both in the behavior-expression and in actions of the effect transition specified graphically, the values of the signal instance
(in case of a signal trigger) are denoted by signal-name ‘.’attribute-name in case of just one signal trigger, and by ‘msg.’attr-name
in case of more than one trigger.
Internal transitions are specified in a special compartment of the source state, see Figure 15.32.
Presentation options
The triggers and the subsequent effect of a transition may be notated either textually or as a presentation option, using
graphical symbols on a transition. This section describes the graphical presentation option.
The graphical presentation of triggers and effect of a transition consists of one or more graphical symbols attached to a
line connecting the symbols for source and target of the transition each representing a trigger or an action of the transition
effect. The action symbols split one logical transition into several graphical line segments with an arrowhead on one end
(see
Figure 15.44).
The sequence of symbols may consist of a single trigger symbol (or none), followed by a sequence of zero or more action symbols.
The trigger symbol maps to the set of Triggers. The sequence of action symbols maps to the Behavior representing the effect
of the transition. Each action symbol is mapped to an action contained within the single SequenceNode comprising an Activity
that is the effect Behavior. The SequenceNode orders the actions according to their graphical order on the transition path.
All line segments connecting the symbols representing source and target of the transition as well as all action symbols represent
a single transition, and map to a single behavior. This behavior owns the actions that are represented by the action symbols.
Signal receipt
The trigger symbol is shown as a five-pointed polygon that looks like a rectangle with a triangular notch in one of its sides
(either one). It represents the trigger of the transition. The textual trigger specification is denoted within the symbol.
If the transition owns a guard, the guard is also described within the signal receipt icon. The textual notation:
<trigger> [‘,’ <trigger>]* [‘[‘ <guard> ‘]’]
The trigger symbol is always first in the path of symbols and a transition path can only have at most one such symbol.
Signal sending
Signal sending is a common action that has a special notation described in SendSignalAction. The actual parameters of the
signal are shown within the symbol. On a given path, the signal sending symbol must follow the trigger symbol if the latter
exists.
The signal sending symbol maps to a SendSignalAction. If a tool does not use the actions package, the details of the sent
signal may be captured within the body of the behavior instead of the SendSignalAction instance. It is possible to have multiple
signal sending nodes on a transition path.
Other actions
An action symbol is a rectangle that contains a textual representation of the action represented by this symbol. Alternatively,
the graphical notation defined for this action, if any, may be used instead. The action symbol must follow the signal receipt
symbol if one exists for that transition. The action sequence symbol is mapped to an opaque action, or to a sequence node
containing instances of actions, depending on whether it represents one or more actions, respectively.
Note that this presentation option combines only the above symbols into a single transition. Choice and junction symbols
(see Figure 15.44) for example, are not mapped to actions on transition but to choice and junction pseudo-states.
Therefore, Figure 15.44 shows these transitions: one from the idle state to the choice symbol, one for each of the branches
of the choice through the junction symbol, and one from the junction pseudostate to the busy state.
Issue 8443 -add colon in front of equals sign for assignments
MinorReq := Id; MajorReq := Id;
Figure 15.44 - Symbols for Signal Receipt, Sending and Actions on transition
Deferred triggers
A deferrable trigger is shown by listing it within the state followed by a slash and the special operation defer. If the event
occurs, it is saved and it recurs when the object transitions to another state, where it may be deferred again. When the object
reaches a state in which the event is not deferred, it must be accepted or lost. The indication may be placed on a composite
state or its equivalents, submachine states, in which case it remains deferrable throughout the composite state. A contained
transition may still be triggered by a deferrable event, whereupon it is removed from the pool.
Turn on
Figure 15.46 shows an example of adding transitions in a specialized state machine.
Example
Transition with guard constraint and transition string:
right-mouse-down (location) [location in window] / object := pick-object (location);object.highlight ()
The trigger may be any of the standard trigger types. Selecting the type depends on the syntax of the name (for time triggers,
for example); however, SignalTriggers and CallTriggers are not distinguishable by syntax and must be discriminated by their
declaration elsewhere.
Changes from previous UML
• Transition redefinition has been added, in order to express if a transition of a general state machine can be redefined or not.
• Along with this, an association to the redefined transition has been added.
• Guard has been replaced by a Constraint.