Previous UML Classes Table of Contents UML Packages Next


15.3.14 Transition

BehaviorStateMachines


*Generalizations

Issue 9196 -change superclass to Namespace

*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)

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

   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:

   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:

   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.45 - Deferred Trigger Notation

    Figure 15.46 shows an example of adding transitions in a specialized state machine.

Figure 15.46 - Adding Transitions

   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