Class Descriptions

 

ConnectionPointReference (from BehaviorStatemachines)

A connection point reference represents a usage (as part of a submachine state) of an entry/exit point defined in the statemachine reference by the submachine state.

Description

Connection point references of a submachine state can be used as sources/targets of transitions. They represent entries into or exits out of the submachine state machine referenced by the submachine state.

Attributes

No additional attributes.

Associations
Constraints

[1] The entry Pseudostates must be Pseudostates with kind entryPoint.

entry->notEmpty() implies entry.kind = #entryPoint

[2] The exit Pseudostates must be Pseudostates with kind exitPoint

exit->notEmpty() implies exit.kind = #exitPoint

Semantics

Connection point references are sources/targets of transitions implying exits out of/entries into the submachine state machine referenced by a submachine state.

An entry point connection point reference as the target of a transition implies that the target of the transition is the entry point pseudostate as defined in the submachine of the submachine state. As a result, the regions of the submachine state machine are entered at the corresponding entry point pseudo states.

An exit point connection point reference as the source of a transition implies that the source of the transition is the exit point pseudostate as defined in the submachine of the submachine state that has the exit point connection point defined.

When a region of the submachine state machine has reached the corresponding exit points, the submachine state exits at this exit point.

Notation



A connection point reference to an entry point has the same notation as an entry point pseudostate. The circle is placed on the border of the state symbol of a submachine state.

A connection point reference to an entry point can also be visualized using a rectangular symbol as shown in Figure 362.

The text inside the symbol shall contain the keyword `via' followed by the name of the connection point. This notation may only be used if the transition ending with the connection point is defined using the transition-oriented control icon notation as defined in "Transition (from BehaviorStatemachines)".



A connection point reference to an exit point has the same notation as an exit point pseudostate. The encircled cross is placed on the border of the state symbol of a submachine state.



A connection point reference to an exit point can also be visualized using a rectangular symbol as shown in Figure 362.

The text inside the symbol shall contain the keyword `via' followed by the name of the connection point. This notation may only be used if the transition associated with the connection point is defined using the transition-oriented control icon notation as defined in "Transition (from BehaviorStatemachines)".





Interface (from ProtocolStatemachines, as specialized)

Interface is defined as a specialization of the general Interface, adding an association to a protocol state machine.

Description

Since an interface specifies conformance characteristics, it does not own detailed behavior specifications. Instead, interfaces may own a protocol state machine that specifies event sequences and pre/post conditions for the operations and receptions described by the interface.

Attributes

No additional attributes.

Associations
Semantics

Interfaces can specify behavioral constraints on the features using a protocol state machine. A classifier realizing an interface must comply with the protocol state machine owned by the interface.

Changes from UML 1.x

Interfaces can own a protocol state machine.

FinalState (from BehaviorStatemachines)

A special kind of state signifying that the enclosing region is completed. If the enclosing region is directly contained in a state machine and all other regions in the state machine also are completed, then it means that the entire state machine is completed.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

[1] A final state cannot have any outgoing transitions

self.outgoing->size() = 0

[2] A final state cannot have regions

[3] A final state cannot reference a submachine

[4] A final state has no entry activity

[5] A final state has no exit activity

[6] A final state has no state (doActivity) activity

Semantics

When the final state is entered, its containing region is completed, which means that it satisfies the completion condition.

The containing state for this region is considered completed when all contained regions are completed. If the region is contained in a state machine and all other regions in the state machine also are completed, the entire state machine terminates, implying the termination of the context object of the state machine.

Notation

A final state is shown as a circle surrounding a small solid filled circle (see Figure 363). The corresponding completion transition on the enclosing state has as notation an unlabeled transition
 


Figure 384 has an example of a final state (the rightmost of the states within the composite state).

 Port ( (from ProtocolStatemachines, as specialized)

Port is defined as a specialization of the general Port, adding an association to a protocol state machine.

Attributes

No additional attributes.

Associations
Semantics

The protocol references a protocol state machine (see "ProtocolStateMachine (from ProtocolStatemachines)" ) that describes valid sequences of operation and reception invocations that may occur at this port.

ProtocolConformance (from ProtocolStatemachines)


Description

Protocol state machines can be redefined into more specific protocol state machines, or into behavioral state machines.

Protocol conformance declares that the specific protocol state machine specifies a protocol that conforms to the general state machine one, or that the specific behavioral state machine abide by the protocol of the general protocol state machine.

A protocol state machine is owned by a classifier. The classifiers owning a general state machine and an associated specific state machine are generally also connected by a generalization or a realization link.

Attributes

No additional attributes.

Associations

Constraints

No additional constraints

Semantics

Protocol conformance means that every rule and constraint specified for the general protocol state machine (state invariants, pre and post conditions for the operations referred by the protocol state machine) apply to the specific protocol or behavioral state machine.

In most cases, there are relationships between the classifier being the context of the specific state machine and the classifier being the context of the general protocol state machine. Generally, the former specializes or realizes the later. It is also possible that the specific state machine is a behavioral state machine that implements the general protocol state machine, both state machines having the same class as a context.

ProtocolStateMachine (from ProtocolStatemachines)

Description

A protocol state machine is always defined in the context of a classifier. It specifies which operations of the classifier can be called in which state and under which condition, thus specifying the allowed call sequences on the classifier's operations. A protocol state machine presents the possible and permitted transitions on the instances of its context classifier, together with the operations which carry the transitions. In this manner, an instance lifecycle can be created for a classifier, by specifying the order in which the operations can be activated and the states through which an instance progresses during its existence.

Attributes

No additional attributes.

Associations
Constraints

[1] A protocol state machine must only have a classifier context, not a behavioral feature context

[2] All transitions of a protocol state machine must be protocol transitions. (transitions as extended by the ProtocolStateMachines package)

[3] If two ports are connected, then the protocol state machine of the required interface (if defined) must be conformant to theprotocol state machine of the provided interface (if defined).

Semantics

Protocol state machines help defining the usage mode of the operations and receptions of a classifier by specifying:
Using pre and post conditions on operations is a technique well suited for expressing such specifications. However, pre and post conditions are expressed at the operation level, and therefore do not provide a synthetic overview at the classifier level. Protocol state machines provide a global overview of the classifier protocol usage, in a simple formal representation. Protocol state machines may not express all the pre- and postconditions of operations. In that case, additional pre- or postconditions can be added at the operation level. Formally, the pre condition of an operation will be the addition (logical "and") of the constraint defined as pre condition of the operation, if any, to the constraint deduced from the protocol state machine if any. The same applies to the post condition of an operation.

The protocol state machine defines all allowed transitions for each operation. The protocol state machine must represent all operations that can generate a given change of state for a class. Those operations that do not generate a transition are not represented in the protocol state machine.

Protocol state machines constitute a means to formalize the interface of classes, and do not express anything except consistency rules for the implementation or dynamics of classes.

Protocol state machine interpretation can vary from:
  1. Declarative protocol state machines that specify the legal transitions for each operation. The exact triggering condition for the operations is not specified. This specification only defines the contract for the user of the context classifier.
  2. Executable protocol state machines, that specify all events that an object may receive and handle, together with the transitions that are implied. In this case, the legal transitions for operations will exactly be the triggered transitions.

The call trigger specifies the effect action, which is the call of the associated operation.

The representation for both interpretations is the same, the only difference being the direct dynamic implication that the interpretation 2 provides.

Elaborated forms of state machine modeling such as compound transitions, sub-statemeachines, composite states and concurrent regions can also be used for protocol state machines. For example, concurrent regions make it possible to express protocol where an instance can have several active states simultaneously.

Sub-state machines and compound transitions are used as in behavioral state machines for factorizing complex protocol state machines.

A classifier may have several protocol state machines. This happens frequently, for example, when a class inherits several parent classes having protocol state machine, when the protocols are orthogonal. An alternative to multiple protocol state machines can always be found by having one protocol state machine, with sub-state machines in concurrent regions.

Notation

The notation for protocol state machine is very similar to the one of behavioral state machines. The keyword {protocol} placed close to the name of the state machine differentiates graphicaly protocol state machine diagrams.



ProtocolTransition (from ProtocolStateMachines)


Description

A protocol transition (transition as specialized in the ProtocolStateMachines package) specifies a legal transition for an operation. Transitions of protocol state machines have the following information: a pre condition (guard), on trigger, and a post condition. Every protocol transition is associated to zero or one operation (referred BehavioralFeature) that belongs to the context classifier of the protocol state machine.

The protocol transition specifies that the associated (referred) operation can be called for an instance in the origin state under the initial condition (guard), and that at the end of the transition, the destination state will be reached under the final condition (post).

Attributes

No additional attributes.

Associations
\referred: Operation[0..*] This association refers to the associated operation. It is derived from the operation of the call trigger when applicable.
postCondition: Constraint[0..1] Specifies the post condition of the transition which is the condition that should be obtained once the transition is triggered. This post condition is part of the post condition of the operation connected to the transition.
preCondition: Constraint[0..1] Specifies the precondition of the transition. It specifies the condition that should be verified before triggering the transition. This guard condition added to the source state will be evaluated as part of the precondition of the operation refered by the transition if any.


Constraints

[1] A protocol transition always belongs to a protocol state machine.

container.belongsToPSM()

[2] A protocol transition never has associated actions.

effect->isEmpty()

[3] If a protocol transition refers to an operation (i. e. has a call trigger corresponding to an operation), then that operation should apply to the context classifier of the state machine of the protocol transition.

Additional Operations

[1] The operation belongsToPSM () checks if the region belongs to a protocol state machine 

context
Region::belongsToPSM () : Boolean
result = if not stateMachine->isEmpty() then
                   oclIsTypeOf(ProtocolStateMachine)
            else if not state->isEmpty() then
                            state.container.belongsToPSM ()
                   else false

Semantics

No "effect" action

The effect action is never specified. It is implicit, when the transition has a call trigger: the effect action will be the operation specified by the call trigger. It is unspecified in the other cases, where the transition only defines that a given event can be received under a specific state and pre-condition, and that a transition will lead to another state under a specific post condition, whatever action will be made through this transition.

Unexpected event reception

The interpretation of the reception of an event in an unexpected situation (current state, state invariant, and pre-condition) is a semantic variation point: the event can be ignored, rejected or deferred, an exception can be raised, or the application can stop on an error. It corresponds semantically to a pre-condition violation, for which no predefined behavior is defined in UML.

Unexpected behavior

The interpretation of an unexpected behavior, that is an unexpected result of a transition (wrong final state or final state invariant, or post condition) is also a semantic variation point. However, this should be interpreted as an error of the implementation of the protocol state machine.

Equivalences to pre and post conditions of operations

The protocol transition can always be translated into pre and post conditions of the associated operation.

For example, the transition in Figure 365 specifies that:
  1. the operation "m1" can be called on an instance when it is in the state S1 under the condition C1,
  2. when m1 is called in the state S1 under the condition C1, then the final state S2 must be reached under the condition C2.
This can be translated into the following pre and post conditions of the operation m1 (Figure 365).



In a protocol state machine, several transitions can refer to the same operation as illustrated below. In that case, all pre conditions and post conditions will be combined in the operation pre condition as below:

Operation m1()

Pre: S1 is in the configuration state and C1
        or
        S3 is in the configuration state and C3
Post:
        if the initial condition was "S1 is in the configuration state and C1"
        then S2 is in the configuration state and C2
        else
                if the initial condition was "S3 is in the configuration state and C3"
                then S4 is in the configuration state and C4


A protocol state machine specifies all the legal transitions for each operation refered by its transitions. This means that for any operation refered by a protocol state machine, the part of its precondition relative to legal initial or final state is completely specified by the protocol stat machine.

Unreferred Operations

If an operation is not referred by any transition of a protocol state machine, then the operation can be called for any state of the protocol state machine, and does not change the current state.

Using events in protocol state machines

Apart from the operation call event, events are generally used for expressing a dynamic behavior interpretation of  protocol state machines. An event which is not a call event can be specified on protocol transitions.

In this case, this specification is a requirement to the environment external to the state machine : it is legal to send this event to an instance of the context classifier only under the conditions specified by the protocol state machine.

Just like call event, this can also be interpreted in a dynamic way, as a semantic variation point.

Notation

The usual state machine notation applies. The difference is that no actions are specified for protocol transitions, and that post conditions can exist. Post conditions have the same syntax as guard conditions, but appear at the end of the transition syntax.


PseudoState (from BehaviorStatemachines)


A pseudostate is an abstraction that encompasses different types of transient vertices in the state machine graph.

Description

Pseudostate are typically used to connect multiple transitions into more complex state transitions paths. For example, by combining a transition entering a fork pseudostate with a set of transitions exiting the fork pseudostate, we get a compound transition that leads to a set of orthogonal target states.

Attributes
Associations

No additional associations.

Constraints

An initial vertex can have at most one outgoing transition.

(self.kind = #initial) implies
    ((self.outgoing->size <= 1)

[2] History vertices can have at most one outgoing transition.

((self.kind = #deepHistory) or (self.kind = #shallowHistory)) implies
    (self.outgoing->size <= 1)

[3] In a complete statemachine, a join vertex must have at least two incoming transitions and exactly one outgoing transition.

(self.kind = #join) implies
    ((self.outgoing->size = 1) and (self.incoming->size >= 2))

[4] All transitions incoming a join vertex must originate in different regions of an orthogonal state.

(self.kind = #join
and not oclIsKindOf(self.stateMachine, ActivityGraph))
    implies
        self.incoming->forAll (t1, t2 | t1<>t2 implies
                (self.stateMachine.LCA(t1.source, t2.source).
                        container.isOrthogonal)

[5] In a complete statemachine, afork vertex must have at least two outgoing transitions and exactly one incoming transition.

(self.kind = #fork) implies
    ((self.incoming->size = 1) and (self.outgoing->size >= 2))

[6] All transitions outgoing a fork vertex must target states in different regions of an orthogonal state.

(self.kind = #fork
and not oclIsKindOf(self.stateMachine, ActivityGraph)) implies
    self.outgoing->forAll (t1, t2 | t1<>t2 implies
                  (self.stateMachine.LCA(t1.target, t2.target).
                        container.isOrthogonal)

[7] In a complete statemachine, ajunction vertex must have at least one incoming and one outgoing transition.

(self.kind = #junction) implies
        ((self.incoming->size >= 1) and (self.outgoing->size >= 1))

[8] In a complete statemachine, a choice vertex must have at least one incoming and one outgoing transition.

(self.kind = #choice) implies
    ((self.incoming->size >= 1) and (self.outgoing->size >= 1))

[9] Pseudostates of kind entryPoint can only be defined in the topmost regions of a StateMachine.

(kind = #entryPoint) implies (owner.oclIsKindOf(Region) and owner.owner.oclIsKindOf(StateMachine))

[10] Pseudostates of kind exitPoint can only be defined in the topmost regions of a StateMachine.

(kind = #exitPoint) implies (owner.oclIsKindOf(Region) and owner.owner.oclIsKindOf(StateMachine))

Semantics

The specific semantics of a Pseudostate depends on the setting of its kind attribute.

Notation

An initial pseudostate is shown as a small solid filled circle (see Figure 368). In a region of a classifierBehavior state machine, the transition from an initial pseudostate may be labeled with the trigger event that creates the object; otherwise, it must be unlabeled. If it is unlabeled, it represents any transition from the enclosing state.


A shallowHistory is indicated by a small circle containing an `H' (see Figure 369). It applies to the state region that directly encloses it.

A deepHistory is indicated by a small circle containing an `H*' (see Figure 370). It applies to the state region that directly encloses it.

An entry point is shown as a small circle on the border of the state machine diagram, with the name associated with it (see Figure 371).

Optionally it may be placed both the within state machine diagram and outside the border of the state machine diagram.

An exit point is shown as a small circle with a cross on the border of the state machine diagram, with the name associated with it (see Figure 372).

Optionally it may be placed both within the state machine diagram and outside the border of the state machine diagram.

A junction is represented by a small black circle (see Figure 373).


A choice pseudostate is shown as a diamond-shaped symbol as exemplified by Figure 374.


A terminate pseudostate is shown as a cross, see Figure 375.



The notation for a fork and join is a short heavy bar (Figure 376). The bar may have one or more arrows from source states to the bar (when representing a joint) The bar may have one or more arrows from the bar to states (when representing a fork). A transition string may be shown near the bar.


Presentation Options

If all guards associated with triggers of transitions leaving a choice PseudoState are binary expressions that share a common left operand, then the notation for choice PseudoState may be simplified. The left operand may be placed inside the diamond-shaped symbol and the rest of the Guard expressions placed on the outgoing transitions. This is exemplified in Figure 377.


Multiple trigger-free and effect-free transitions originating on a set of states and targeting a junction vertex with a single outgoing transition may be presented as a state symbol with a list of the state names and an outgoing transition symbol corresponding to the outgoing transition from the junction.

The special case of the transition from the junction having a history as target may optionally be presented as the target being the state list state symbol. See Figure 378 and Figure 379 for examples.





Changes from previous UML

PseudoStateKind (from BehaviorStatemachines)

PseudoStateKind is an enumeration type.

Description

PseudoStateKind is an enumeration of the following literal values:

· initial
· deepHistory
· shallowHistory
· join
· fork
· junction
· choice
· entryPoint
· exitPoint
· terminate

Attributes

No additional attributes.

Associations

No additional associations.

Changes from previous UML

EntryPoint, exitPoint, and terminate has been added.

 Region (from BehaviorStatemachines)

A region is an orthogonal part of either a composite state or a state machine. It contains states and transitions.

Attributes

No additional attributes.

Associations

Constraints

[1] A region can have at most one initial vertex

self.subvertex->select (v | v.oclIsKindOf(Pseudostate))->
    select(p : Pseudostate | p.kind = #initial)->size() <= 1

[2] A region can have at most one deep history vertex

self.subvertex->select (v | v.oclIsKindOf(Pseudostate))->
    select(p : Pseudostate | p.kind = #deepHistory)->size() <= 1

[3] A region can have at most one shallow history vertex

self.subvertex->select(v | v.oclIsKindOf(Pseudostate))->
    select(p : Pseudostate | p.kind = #shallowHistory)->size() <= 1

[4] The redefinition context of a region 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 constraints

[1] The query isRedefinitionContextValid() specifies whether the redefinition contexts of a region are properly related to the redefinition contexts of the specified region to allow this element to redefine the other. The containing statemachine/state of a redefining region must redefine the containing statemachine/state of the redefined region.

[2] `The query isConsistentWith() specifies that a redefining region is consistent with a redefined region provided that the redefining region is an extension of the redefined region, i.e. it adds vertices and transitions and it redefines states andtransitions of the redefined region.

Semantics

The semantics of regions is tightly coupled with states or state machines having regions, and it is therefore defined as part of the semantics for state and state machine.

When a composite state or state machine is extended, each inherited region may be extended, and regions may be added.

Notation

A composite state or state machine with regions is shown by tiling the graph region of the state/state machine using dashed lines to divide it into regions. Each region may have an optional name and contains the nested disjoint states and the transitions between these. The text compartments of the entire state are separated from the orthogonal regions by a solid line.



A composite state or state machine with just one region is shown by showing a nested state diagram within the graph region.

In order to indicate that an inherited region is extended, the keyword «extended» is associated with the name of the region.

State (from BehaviorStatemachines)

A state models a situation during which some (usually implicit) invariant condition holds.

Description

State in Behavioral State machines

A state models a situation during which some (usually implicit) invariant condition holds. The invariant may represent a static situation such as an object waiting for some external event to occur. However, it can also model dynamic conditions such as the process of performing some activity (i.e., the model element under consideration enters the state when the activity commences and leaves it as soon as the activity is completed).

The following kinds of states are distinguished:
· Simple state,
· composite state, and
· submachine state.

A composite state is either a simple composite state (with just one region) or an orthogonal state (with more than one region).

Simple state

A simple state is a state that does not have substates, i.e. it has no regions and it has no submachine state machine.

Composite state

A composite state either contains one region or is decomposed into two or more orthogonal regions. Each region has a set of mutually exclusive disjoint subvertices and a set of transitions. A given state may only be decomposed in one of these two ways.

Any state enclosed within a region of a composite state is called a substate of that composite state. It is called a direct substate when it is not contained by any other state; otherwise it is referred to as a indirect substate.

Each region of a composite state may have an initial pseudostate and a final state. A transition to the enclosing state represents a transition to the initial pseudostate in each region. A newly-created object takes it's topmost default transitions, originating from the topmost initial pseudostates of each region.

A transition to a final state represents the completion of activity in the enclosing region. Completion of activity in all orthogonal regions represents completion of activity by the enclosing state and triggers a completion event on the enclosing state. Completion of the topmost regions of an object corresponds to its termination.

Submachine state

A submachine state specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine.

A submachine state is semantically equivalent to a composite state. The regions of the submachine state machine are the regions of the composite state. The entry, exit and activity actions, and internal transitions, are defined as part of the state.

Submachine state is a decomposition mechanism that allows factoring of common behaviors and their reuse.

Transitions in the containing state machine can have entry/exit points of the inserted state machine as targets/sources.

State in Protocol State machines

The states of protocol state machines are exposed to the users of their context classifiers. A protocol state represents an exposed stable situation of its context classifier: when an instance of the classifier is not processing any operation, users of this instance can always know its state configuration.

Attributes
Associations

BehaviorStateMachines

  • connection: ConnectionPointReference
The entry and exit connection points used in conjunction with this (submachine) state, i.e. as targets and sources, respectively, in the region with the submachine state. A connection point reference references the corresponding definition of a connection point pseudostate in the statemachine referenced by the submachinestate.
  • deferrableTrigger: Trigger
A list of triggers that are candidates to be retained by the state machine if they trigger no transitions out of the state (not consumed). A deferred trigger is retained until the state machine reaches a state configuration where it is no longer deferred.
  • doActivity: Activity[0..1]
An optional activity that is executed while being in the state. The execution starts when this state is entered, and stops either by itself, or when the state is exited, whichever comes first.
  • entry: Activity[0..1]
An optional activity that is executed whenever this state is entered regardless of the transition taken to reach the state. If defined, entry actions are always executed to completion prior to any internal activity or transitions performed within the state.
  • exit: Activity[0..1]
An optional activity that is executed whenever this state is exited regardless of which transition was taken out of the state. If defined, exit actions are always executed to completion only after all internal activities and transition actions have completed execution.
  • redefinedState: State[0..1]
The state of which this state is a redefinition.
  • region: Region[*]
The regions of the state.
  • submachine: StateMachine[0..1]
The state machine that is to be inserted in place of the (submachine) state.
  • stateInvariant: Constraint [0..1]
Specifies conditions that are always true when this state is the current state. In protocol state machines, state invariants are additional conditions to the preconditions of the outgoing transitions, and to the postcondition of the incoming transitions.
  • /redefinitionContext: Classifier[1]
References the classifier in which context this element may be redefined.

MaximumOneRegion

Constraints

[1] There have to be at least two regions in an orthogonal composite state

(self.isOrthogonal) implies
    (self.region->size >= 2)

[2] Only submachine states can have connection point references.

[3] The connection point references used as destinations/sources of transitions associated with a submachine state must be defined as entry/exit points in the submachine state machine.

[4] A state is not allowed to have both a submachine and regions.

not
( self.isSubmachineState and self.isComposite )

[5] A simple state is a state without any regions.

isSimple = content.isEmpty()

[6] Acomposite state is a state with at least one region.

isComposite = content.notEmpty()

[7] An orthogonal state is a composite state with at least 2 regions

isOrthogonal = (context.size() >= 2)

[8] Only submachine states can have a reference statemachine.

isSubmachineState = submachine.notEmpty()

[9] A Protocol state (state belonging to a protocol state machine) has no entry or exit or do activity actions.

entry->isEmpty() and
exit->isEmpty() and
doActivity->isEmpty()

[10] Protocol states cannot be deep or shallow history pseudo states.

if oclIsTypeOf(Pseudostate) then (kind <> #deepHistory) and (kind <> #shallowHistory)

[11] The redefinition context of a state 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 constraints

[1] The query isRedefinitionContextValid() specifies whether the redefinition contexts of a state are properly related to the redefinition contexts of the specified state to allow this element to redefine the other. The containing region of a redefining state must redefine the containing region of the redefined state.

[2] The query isConsistentWith() specifies that a redefining state is consistent with a redefined state provided that the redefining state is an extension of the redefined state: A simple state can be redefined (extended) to become a composite state (by adding a region) and a composite state can be redefined (extended) by adding regions and by adding vertices, states,entry/exit/do activities (if the general state has none), and transitions to inherited regions.

Semantics

States in general

The following applies to states in general. Special semantics applies to composite states and submachine states.

Active states

A state can be active or inactive during execution. A state becomes active when it is entered as a result of some transition, and becomes inactive if it is exited as a result of a transition. A state can be exited and entered as a result of the same transition (e.g., self transition).

State entry and exit

Whenever a state is entered, it executes its entry activity before any other action is executed. Conversely, whenever a state is exited, it executes its exit activity as the final step prior to leaving the state.

Activity in state (do-activity)

The activity represents the execution of a activity, that occurs while the state machine is in the corresponding state. The activity starts executing upon entering the state, following the entry activity. If the activity completes while the state is still active, it raises a completion event. In case where there is an outgoing completion transition (see below) the state will be exited. Upon exit, the activity is terminated before the exit activity is executed. If the state is exited as a result of the firing of an outgoing transition before the completion of the activity, the activity is aborted prior to its completion.

Deferred events

A state may specify a set of event types that may be deferred in that state. An event that does not trigger any transitions in the current state, will not be dispatched if its type matches one of the types in the deferred event set of that state.

Instead, it remains in the event pool while another non-deferred event is dispatched instead. This situation persists until a state is reached where either the event is no longer deferred or where the event triggers a transition.

State redefinition

A state may be redefined, provided that the value of isFinal is False. A simple state can be redefined (extended) to become a composite state (by adding a region) and a composite state can be redefined (extended) by adding regions and by adding vertices, states, entry/exit/do activities (if the general state has none), and transitions to inherited regions. The redefinition of a state applies to the whole state machine, e.g. if a state list as part of the extended state machine includes
a state that is redefined, then the state list for the extension state machine includes the redefined state.

Composite state

Active state configurations

In a hierarchical state machine more than one state can be active at the same time. If the state machine is in a simple state that is contained in a composite state, then all the composite states that either directly or transitively contain the simple state are also active. Furthermore, since the state machine as a whole and some of the composite states in this hierarchy may be orthogonal (i.e. containing regions), the current active "state" is actually represented by a set of trees of states
starting with the top-most states of the root regions down to individual simple states at the leaves. We refer to such a state tree as a state configuration.
Except during transition execution, the following invariants always apply to state configurations:
Entering a non-orthogonal composite state

Upon entering a composite state, the following cases are differentiated:

· Default entry: Graphically, this is indicated by an incoming transition that terminates on the outside edge of the composite state. In this case, the default transition is taken. If there is a guard on the trigger of the transition it must be enabled (true). (A disabled initial transition is an ill-defined execution state and its handling is not defined.) The entry activity of the composite state is executed before the activity associated with the initial transition.

· Explicit entry: If the transition goes to a substate of the composite state, then that substate becomes active and its entry code is executed after the execution of the entry code of the composite state. This rule applies recursively if the transition terminates on a transitively nested substate.

· Shallow history entry: If the transition terminates on a shallow history pseudostate, the active substate becomes the most recently active substate prior to this entry, unless the most recently active substate is the final state or if this is the first entry into this state. In the latter two cases, the default history state is entered. This is the substate that is target of the transition originating from the history pseudostate. (If no such transition is specified, the situation is il defined and its handling is not defined.) If the active substate determined by history is a composite state, then it proceeds with its default entry.

· Deep history entry: The rule here is the same as for shallow history except that the rule is applied recursively to all levels in the active state configuration below this one.

Entering an orthogonal composite state

Whenever an orthogonal composite state is entered, each one of its orthogonal regions is also entered, either by default or explicitly. If the transition terminates on the edge of the composite state, then all the regions are entered using default entry. If the transition explicitly enters one or more regions (in case of a fork), these regions are entered explicitly and the others by default.

Exiting non-orthogonal state

When exiting from a composite state, the active substate is exited recursively. This means that the exit activities are executed in sequence starting with the innermost active state in the current state configuration.

Exiting an orthogonal state

When exiting from an orthogonal state, each of its regions is exited. After that, the exit activities of the state is executed.

Deferred events

Composite states introduce potential event deferral conflicts. Each of the substates may defer or consume an event, potentially conflicting with the composite state, e.g. a substate defers an event while the composite state consumes it, or vice versa. In case of a composite orthogonal state, substates of orthogonal regions may also introduce deferral conflicts.

The conflict resolution follows the triggering priorities, where nested states override enclosing states. In case of a conflict between states in different orthogonal regions, a consumer state overrides a deferring state.

Submachine state

A submachine state is semantically equivalent to the composite state defined by the referenced state machine. Entering and leaving this composite state is, in contrast to an ordinary composite state, via entry and exit points.

A submachine composite state machine can be entered via its default (initial) pseudostate or via any of its entry points, i.e. it may imply entering a non-orthogonal or an orthogonal composite state with regions. Entering via the initial pseudostate has the same meaning as for ordinary composite states. An entry point is equivalent with a junction pseudostate (fork in case the composite state is orthogonal): Entering via an entry point implies that the entry activity of the composite state is executed, followed by the (partial) transition(s) from the entry point to the target state(s) within the composite state. As for default initial transitions, guards associated with the triggers of these entry point transitions must evaluate to true in order for the specification not to be ill-formed.

Similarly, it can be exited as a result of reaching its final state, by a "group" transition that applies to all substates in the submachine state composite state, or via any of its exit points. Exiting via a final state or by a group transition has the same meaning as for ordinary composite states. An exit point is equivalent with a junction pseudostate (join in case the composite state is orthogonal): Exiting via an exit point implies that first activity/activities of the transition(s) with the
exit point as target is executed, followed exit activity of the composite state.

Notation

States in general

A state is in general shown as a rectangle with rounded corners, with the state name shown inside the rectangle.

Optionally, it may have an attached name tab, see Figure 382. The name tab is a rectangle, usually resting on the outside of the top side of a state and it contains the name of that state. It is normally used to keep the name of a composite state that has orthogonal regions, but may be used in other cases as well. The state in Figure 376 illustrates the use of the name tab.


A state may be subdivided into multiple compartments separated from each other by a horizontal line, see Figure 383.



The compartments of a state are:
· name compartment
· internal activities compartment
· internal transitions compartment

A composite state has in addition a
· decomposition compartment

Each of these compartments is described below.

· Name compartment

This compartment holds the (optional) name of the state, as a string. States without names are anonymous and are all distinct. It is undesirable to show the same named state twice in the same diagram, as confusion may ensue, unless control icons (page 502) are used to show a transition oriented view of the state machine.
Name compartments should not be used if a name tab is used and vice versa.
In case of a submachine state, the name of the referenced state machine is shown as a string following `:' after the name of the state.

· Internal activities compartment
This compartment holds a list of internal activities or state (do) activities that are performed while the element is in the state.
The activity label identifies the circumstances under which the activity specified by the activity expression will be invoked. The activity expression may use any attributes and association ends that are in the scope of the owning entity.
For list items where the activity expression is empty, the backslash separator is optional.
A number of activity labels are reserved for various special purposes and, therefore, cannot be used as event names. The following are the reserved activity labels and their meaning:


·Internal transition compartment
This compartment contains a list of internal transitions, where each item has the form as described for Trigger.
Each event name may appear more than once per state if the guard conditions are different. The event parameters and the guard conditions are optional. If the event has parameters, they can be used in the activity expression through the current event variable.


Composite state

· decomposition compartment
This compartment shows its composition structure in terms of regions, states and transition. In addition to the (optional) name and internal transition compartments, the state may have an additional compartment that contains a nested diagram. For convenience and appearance, the text compartments may be shrunk horizontally within the graphic region. In some cases, it is convenient to hide the decomposition of a composite state. For example, there may be a large number of states nested inside a composite state and they may simply not fit in the graphical space available for the diagram. In that case, the composite state may be represented by a simple state graphic with a special "composite" icon, usually in thelower right-hand corner (see Figure 385). This icon, consisting of two horizontally placed and connected states, is an optional visual cue that the state has a decomposition that is not shown in this particular statechart diagram. Instead, the contents of the composite state are shown in a separate diagram. Note that the "hiding" here is purely a matter of graphical convenience and has no semantic significance in terms of access restrictions.

Examples



Submachine state

The submachine state is depicted as a normal state where the string in the name compartment has the following syntax <state name> `:' <name of referenced state machine>

The submachine state symbol may contain the references to one or more entry points and to one or more exit points. The notation for these connection point references are entry/exit point pseudostates on the border of the submashine state. The names are the names of the corresponding entry/exit points defined within the referenced state machine. See ("ConnectionPointReference (from BehaviorStatemachines)").

If the substate machine is entered through its default initial pseudostate or if it is exited as a result of the completion of the submachine, it is not necessary to use the entry/exit point notation. Similarly, an exit point is not required if the exit occurs through an explicit "group" transition that emanates from the boundary of the submachine state (implying that it applies to all the substates of the submachine).

Submachine states invoking the same submachine may occur multiple times in the same state diagram with the entry and exit points being part of different transitions.
Examples

The diagram in Figure 387 shows a fragment from a statechart diagram in which a sub state machine (the FailureSubmachine) is referenced. The actual sub state machine is defined in some enclosing or imported name space.


In the above example, the transition triggered by event "error1" will terminate on entry point "sub1" of the FailureSubmachine state machine. The "error3" transition implies taking of the default transition of the FailureSubmachine.

The transition emanating from the "subEnd" exit point of the submachine will execute the "fixed1" activity in addition to what is executed within the HandleFailure state machine. This transition must have been triggered within the HandleFailure state machine. Finally, the transition emanating from the edge of the submachine state is taken as a result of the completion event generated when the FailureSubmachine reaches its final state.

Figure 388 is an example of a state machine defined with two exit points. The entry and exit points may also be shown on the frame or outside the frame (but still associated with it), and not only within the state graph.

In Figure 390 this state machine is referenced in a submachine state, and the presentation option with the exit points on the state symbol is shown.



Notation for protocol state machines

The two differences that exist for state in protocol state machine, versus states in behavioral state machine, are as follow:

Several features in behavioral state machine do not exist for protocol state machines (entry, exit, do); States in protocol state machines can have an invariant. The textual expression of the invariant will be represented by placing it after or under the name of the state, surrounded by square braquets.



Rationale

Submachine states with usages of entry and exit points defined in the corresponding state machine has been introduced in order for state machines with submachines to scale and in order to provide encapsulation.

 StateMachine (from BehaviorStatemachines)

State machines can be used to express the behavior of part of a system. Behavior is modeled as a traversal of a graph of state nodes interconnected by one or more joined transition arcs that are triggered by the dispatching of series of events.

During this traversal, the state machine executes a series of activities associated with various elements of the state machine.

Description

A
state machine owns one or more regions, which in turn own vertices and transitions.

The behaviored classifier context owning a state machine defines which signal and call triggers are defined for the state machine, and which attributes and operations are available in activities of the state machine. Signal triggers and call triggers for the state machine are defined according to the receptions and operations of this classifier.

As a kind of behavior, a state machine may have an associated behavioral feature (specification) and be the method of this behavioral feature. In this case the state machine specifies the behavior of this behavioral feature. The parameters of the state machine in this case match the parameters of the behavioral feature and provide the means for accessing (within the state machine) the behavioral feature parameters.

A state machine without a context classifier may use triggers that are independent of receptions or operations of a classifier, i.e. either just signal triggers or call triggers based upon operation template parameters of the (parameterized) statemachine.

Attributes

No additional attributes.

Associations

BehaviorStateMachines

MaximumOneRegion
Constraints

[1] The classifier context of a state machine cannot be an interface

[2] The context classifier of the method state machine of a behavioral feature must be the classifier that owns the behavioralfeature.

[3] The connection points of a state machine are pseudostates of kind entry point or exit point.

[4] A state machine as the method for a behavioral feature cannot have entry/exit connection points.

[5] The redefinition context of a state is the nearest containing statemachine or context classifier

    redefinitionContext =
            let sm = containingStateMachine() in
                if sm.context->isEmpty() or sm.general->notEmpty() then
                        sm
                else
                        sm.context
                endif

Additional Operations

[1] The operation LCA(s1,s2) returns the state which is the least common ancestor of states s1 and s2.

    context StateMachine::LCA (s1 : State, s2 : State) :
                                        CompositeState
    result = if ancestor (s1, s2) then
                s1
        else if ancestor (s2, s1) then
                        s2
                else (LCA (s1.container, s2.container))

[2] The query ancestor(s1, s2) checks whether s2 is an ancestor state of state s1.

    context StateMachine::ancestor (s1 : State, s2 : State) : Boolean
    result = if (s2 = s1) then
                        true
                else if (s1.container->isEmpty) then
                                true
                        else if (s2.container->isEmpty) then
                                            false
                                else (ancestor (s1, s2.container)

[3] The query containingStateMachine() yields the statemachine owning a given element, either directly as for regions or indirectly as for states and transitions.

[4] The query isRedefinitionContextValid() specifies whether the redefinition contexts of a statmachine are properly related to the redefinition contexts of the specified statemachine to allow this element to redefine the other. The containing clasifier of a redefining statemachine must redefine the containing classifier of the redefined statemachine.

[5] The query isConsistentWith() specifies that a redefining state machine is consistent with a redefined state machine provided that the redefining state machine is an extension of the redefined state machine: Regions are inherited and regions can be added, inherited regions can be redefined. In case of multiple redefining state machines, extension implies that the redefining state machine gets orthogonal regions for each of the redefined state machines.

Semantics

The event pool for the state machine is the event pool of the instance according to the behaviored context classifier, or the classifier owning the behavioral feature for which the state machine is a method.

Event processing - run-to-completion step

Events are dispatched and processed by the state machine, one at a time. The order of dequeuing is not defined, leaving open the possibility of modeling different priority-based schemes.

The semantics of event processing is based on the run-to-completion assumption, interpreted as run-to-completion processing. Run-to-completion processing means that an event can only be taken from the pool and dispatched if the processing of the previous current event is fully completed.

Run-to-completion may be implemented in various ways. For active classes, it may be realized by an event-loop running in its own thread, and that reads events from a pool. For passive classes it may be implemented as a monitor.

The processing of a single event by a state machine is known as a run-to-completion step. Before commencing on a run-to-completion step, a state machine is in a stable state configuration with all entry/exit/internal activities (but not necessarily state (do) activities) completed. The same conditions apply after the run-to-completion step is completed.

Thus, an event will never be processed while the state machine is in some intermediate and inconsistent situation. The run-to-completion step is the passage between two state configurations of the state machine.

The run-to-completion assumption simplifies the transition function of the state machine, since concurrency conflicts are avoided during the processing of event, allowing the state machine to safely complete its run-to-completion step.

When an event is dispatched, it may result in one or more transitions being enabled for firing. If no transition is enabled and the event is not in the deferred event list of the current state configuration, the event is discarded and the run-to-completion step is completed.

In the presence of orthogonal regions it is possible to fire multiple transitions as a result of the same event -- as many as one transition in each region in the current state configuration. In case where one or more transitions are enabled, the state machine selects a subset and fires them. Which of the enabled transitions actually fire is determined by the transition selection algorithm described below. The order in which selected transitions fire is not defined.

Each orthogonal region in the active state configuration that is not decomposed into orthogonal regions (i.e., "bottom-level" region) can fire at most one transition as a result of the current event. When all orthogonal regions have finished executing the transition, the current event is fully consumed, and the run-to-completion step is completed.

During a transition, a number of actions may be executed. If such an action is a synchronous operation invocation on an object executing a state machine, then the transition step is not completed until the invoked object complete its run-to-completion step.

Run-to-completion and concurrency

It is possible to define state machine semantics by allowing the run-to-completion steps to be applied orthogonally to the orthogonal regions of a composite state, rather than to the whole state machine. This would allow the event serialization constraint to be relaxed. However, such semantics are quite subtle and difficult to implement. Therefore, the dynamic semantics defined in this document are based on the premise that a single run-to-completion step applies to the entire state
machine and includes the steps taken by orthogonal regions in the active state configuration.

In case of active objects, where each object has its own thread of execution, it is very important to clearly distinguish the notion of run to completion from the concept of thread pre-emption. Namely, run-to-completion event handling is performed by a thread that, in principle, can be pre-empted and its execution suspended in favor of another thread executing on the same processing node. (This is determined by the scheduling policy of the underlying thread environment -- no assumptions are made about this policy.) When the suspended thread is assigned processor time again, it resumes its event processing from the point of pre-emption and, eventually, completes its event processing.

Conflicting transitions

It was already noted that it is possible for more than one transition to be enabled within a state machine. If that happens, then such transitions may be in conflict with each other. For example, consider the case of two transitions originating from the same state, triggered by the same event, but with different guards. If that event occurs and both guard conditions are true, then only one transition will fire. In other words, in case of conflicting transitions, only one of them will fire in
a single run-to-completion step.

Two transitions are said to conflict if they both exit the same state, or, more precisely, that the intersection of the set of states they exit is non-empty. Only transitions that occur in mutually orthogonal regions may be fired simultaneously. This constraint guarantees that the new active state configuration resulting from executing the set of transitions is well formed.

An internal transition in a state conflicts only with transitions that cause an exit from that state.

Firing priorities

In situations where there are conflicting transitions, the selection of which transitions will fire is based in part on an implicit priority. These priorities resolve some transition conflicts, but not all of them. The priorities of conflicting transitions are based on their relative position in the state hierarchy. By definition, a transition originating from a substate has higher priority than a conflicting transition originating from any of its containing states.

The priority of a transition is defined based on its source state. The priority of joined transitions is based on the priority of the transition with the most transitively nested source state.

In general, if t1 is a transition whose source state is s1, and t2 has source s2, then:
Transition selection algorithm

The set of transitions that will fire is a maximal set of transitions that satisfies the following conditions:


This can be easily implemented by a greedy selection algorithm, with a straightforward traversal of the active state configuration. States in the active state configuration are traversed starting with the innermost nested simple states and working outwards. For each state at a given level, all originating transitions are evaluated to determine if they are enabled. This traversal guarantees that the priority principle is not violated. The only non-trivial issue is resolving transition conflicts across orthogonal states on all levels. This is resolved by terminating the search in each orthogonal state once a transition inside any one of its components is fired.

StateMachine extension

A state machine is generalizable. A specialised state machine is an extension of the general state machine, in that regions, vertices and transitions may be added, regions and states may be redefined (extended: simple states to composite states and composite states by adding states and transitions), and transitions can be redefined.

As part of a classifier generalization, the classifierBehavior state machine of the general classifier and the method state machines of behavioral features of the general classifier can be redefined (by other state machines). These state machines may be specializations (extensions) of the corresponding state machines of the general classifier or of its behavioral features.

A specialised state machine will have all the elements of the general state machine, and it may have additional elements.

Regions may be added. Inherited regions may be redefined by extension: States and vertices are inherited, and states and transitions of the regions of the state machine may be redefined.

A simple state can be redefined (extended) to a composite state, by adding one or more regions.

A composite state can be redefined (extended) by either extending inherited regions or by adding regions. A region is extended by adding vertices, states and transitions and by redefining states and transitions.

A submachine state may be redefined. The submachine state machine may be replaced by another submachine state machine, provided that it has the same entry/exit points as the redefined submachine state machine, but it may add entry/exit points.

Transitions can have their content and target state replaced, while the source state and trigger is preserved.

In case of multiple general classifiers, extension implies that the extension state machine gets orthogonal regions for each of the state machines of the general classifiers in addition to the one of the specific classifier.

Notation

A statechart diagram is a graph that represents a state machine. States and various other types of vertices (pseudostates) in the state machine graph are rendered by appropriate state and pseudostate symbols, while transitions are generally rendered by directed arcs that connect them or by control icons representing the actions of the activity on the transition (page 502).

The association between a state machine and its context classifier or behavioral feature does not have a special notation.

A state machine that is an extension of the state machine in a general classifier will have the keyword «extended» associated with the name of the state machine.
The default notation for classifier is used for denoting state machines. The keyword is «statemachine».

Inherited states are drawn with dashed lines or

Presentation option

Inherited states are drawn with gray-toned lines.

Examples

Figure 392 is an example statemachine diagram for the state machine for simple telephone object. In addition to the initial


state, the state machine has an entry point called activeEntry, and in addition to the final state, it has an exit point called aborted.

As an example of state machine specialization, the states VerifyCard, OutOfService and VerifyTransaction in the ATM state machine in Figure 393 have been specified as {final}, which means that they can not redefined (i.e. extended) in specializations of ATM. The other states can be redefined. The (verifyTransaction,releaseCard) transition has also been specified as {final}, meaning that the effect activity and the target state cannot be redefined.

In Figure 394 a specialized ATM (which is the statemachine of a class that is a specialization of the class with the ATM statemachine of Figure 393) is defined by extending the composite state by adding a state and a transition, so that users can enter the desired amount. In addition a transition is added from an inherited state to the newly introduced state.


Rationale

The rationale for statemachie extension is that it shall be possible to define the redefined behavior of a special classifier as an extension of the behavior of the general classifier.

Changes from previous UML

Rationale


State machines are used for the definition of behavior for e.g. classes that are generalizable. As part of the specialization of a class it is desirable also the specialize the behavior definition.

Changes from previous UML

This is an extension to 1.x. In 1.x state machine generalization is only described through a note.

TimeTrigger ( from BehaviorStatemachines, as specialized)

Description

Extends time triggers to be defined relative to entering the current state of the executing state machine.

Constraints

[1] The starting time for a relative time event may only be omitted for a time event that is the trigger of a state machine.

Semantics

If the deadline expression is relative and no explicit starting time is defined, then it is relative to the time of entry into the source state of the transition triggered by the event. In that case, the time event occurrence is generated only if the state machine is still in that state when the deadline expires.

Notation

If no starting point is indicated, then it is the time since the entry to the current state.

 Transition (from BehaviorStatemachines)

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 a particular event.

Attributes
Associations

  • trigger: Trigger[0..*]
Specifies the triggers that may fire the transition.
  • 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 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.
  • effect: Activity[0..1]
Specifies an optional activity 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.
  • replacedTransition: Transition[0..1]
The transition of which this is a replacement.
  • /redefinitionContext: Classifier[1]
References the classifier in which context this element may be redefined.

Constraints

[1] A fork segment must not have guards or triggers.

(self.source.oclIsKindOf(Pseudostate)
and not oclIsKindOf(self.stateMachine, ActivityGraph)) implies
        ((self.source.oclAsType(Pseudostate).kind = #fork) implies
                ((self.guard->isEmpty) and (self.trigger->isEmpty)))

[2] A join segment must not have guards or triggers.

self.target.oclIsKindOf(Pseudostate) implies
        ((self.target.oclAsType(Pseudostate).kind = #join) implies
                ((self.guard->isEmpty) and (self.trigger->isEmpty)))

[3] A fork segment must always target a state.

(self.stateMachine->notEmpty ) implies
        self.source.oclIsKindOf(Pseudostate) implies
            ((self.source.oclAsType(Pseudostate).kind = #fork) implies
                    (self.target.oclIsKindOf(State)))

[4] A join segment must always originate from a state.

(self.stateMachine->notEmpty ) implies
        self.target.oclIsKindOf(Pseudostate) implies
            ((self.target.oclAsType(Pseudostate).kind = #join) implies
                    (self.source.oclIsKindOf(State)))

[5] Transitions outgoing pseudostates may not have a trigger.

self.source.oclIsKindOf(Pseudostate)
implies (self.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 constraints

[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 redefinining transition redefines all properties of the corresponding redefined transition, except the source state and the trigger.

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 transition 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 where the source is a composite state, a submachine state or an exit point, and without an explicit trigger, although it may have a guard defined. When all transitions and entry activities and state (do) activities in the currently active state are completed, a completion event is generated. 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 transition is the lowest composite state that contains all the explicit source states and explicit target states of the compound transition. In case of junction segments, only the states related to the dynamically selected path are considered explicit targets (bypassed branches are not considered).

If the LCA is not an orthogonal state, the main source is a direct substate of the least common ancestor that contains the explicit source states, and the main target is a substate of the least common ancestor that contains the explicit target states.

In case where the LCA is an orthogonal state, the main source and main target are the orthogonal state itself. The reason is that if an orthogonal region is exited, it forces exit of the entire orthogonal state.

Example

· The common simple case: A transition t between two simple states s1 and s2, in a composite states. 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.

· Activities are executed in sequence following their linear order along the segments of the transition: The closer the activity 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, provided that the value of  isFinal is False. A redefinition transition redefines all properties of the corresponding replaced transition in the extended state machine, except the source state and the trigger.

Transitions are identified by the (source state, trigger) pair. Only transitions that can be uniquely defined by this pair can be redefined. This excludes transitions with the same source, same trigger but different guards from being redefined.

Notation

In addition to the notation defined in Common Behaviors, an item of an assignment-specification can have this form:

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 "(RegionOrState1::RegionOrState2::State3." This may be used in case the same state name occurs in different composite state regions.

The activity-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 it's scope. The activity 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 activity-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 383.

The following icons provide explicit symbols for certain kinds of information that can be specified on transitions. The control icons are intended to provide a transition-oriented view of a state machine as exemplified in Figure 395. These icons are not necessary for constructing state machine diagrams, but many users prefer the added impact that they provide.

Signal receipt

The receipt of a signal may be shown as a concave pentagon that looks like a rectangle with a triangular notch in its side (either side). The signature of the signal is shown inside the symbol. A unlabeled transition arrow is drawn from the source state to the pentagon and another unlabeled transition arrow is drawn from the pentagon to the target state.

Signal sending

The sending of a signal may be shown as a convex pentagon that looks like a rectangle with a triangular point on one side (either side). The actual parameters of the signal is shown inside the symbol. A unlabeled transition arrow is drawn from the source state to the pentagon and another unlabeled transition arrow is drawn from the pentagon to the target state.

Action sequence

A sequence of actions in a transition may be shown as a rectangle that contains a textual description of the actions. The syntax used in the textual description is tool specific but must map to a sequence of Actions.


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.

Figure 397 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

Vertex (from BehaviorStatemachines)

A vertex is an abstraction of a node in a statechart graph. In general, it can be the source or destination of any number of transitions.

Attributes

No additional attributes.

Associations

TransitionKind

TransitionKind is an enumeration type.

Description

TransitionKind is an enumeration of the following literal values:

· external
· internal
· local

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

[1] The source state of a transition with transition kind local must be a composite state.
[2] The source state of a transition with transition kind external must be a composite state.

Semantics

Notation
Changes from previous UML

The semantics implied by local is new.