State

Slide kind

hybrid diagram

UML Activity Diagram

UML Class Diagram

Completion events have dispatching priority. That is, they are dispatched ahead of any pending Event occurrences in the event pool.

Source

In case of simple States, a completion event is generated when the associated entry and doActivity Behaviors have completed executing. If no such Behaviors are defined, the completion event is generated upon entry into the State.

Source

The event that enables this trigger is called a completion event and it signifies that all Behaviors associated with the source State of the completion Transition have completed execution.

Source

14.2.3.8.3 Completion Transitions and completion events: A special kind of Transition is a completion Transition, which has an implicit trigger.

Source

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

13:01: StateMachines [see UML 101 section]

UML-2.5.1: Has an incorrect local Transition with same source and vertex in 'Figure 14.34 Local Transitions'

Transitions of the kind internal are not shown explicitly in diagrams.

Source

kind = internal ... This kind of Transition can only be defined if the source Vertex is a State.

Source

kind = internal is a special case of a local Transition that is a self-transition (i.e., with the same source and target States), such that the State is never exited (and, thus, not re-entered), which means that no exit or entry Behaviors are executed ...

Source

kind = local ... However, for local Transitions the target Vertex must be different from its source Vertex. A local Transition can only exist within a composite State.

Source

kind = local is the opposite of external, meaning that the Transition does not exit its containing State (and, hence, the exit Behavior of the containing State will not be executed). ...

Source

kind = external means that the Transition exits its source Vertex. If the Vertex is a State, then executing this Transition will result in the execution of any associated exit Behavior of that State.

Source

The semantics of a Transition depend on its relationship to its source Vertex. Three different possibilities are defined, depending on the value of the Transition’s kind attribute ...

Source

When multiple triggers are defined for a Transition, they are logically disjunctive, that is, if any of them are enabled, the Transition will be triggered.

Source

A Transition may own a set of Triggers, each of which specifies an Event whose occurrence, when dispatched, may trigger traversal of the Transition. A Transition trigger is said to be enabled if the dispatched Event occurrence matches its Event type.

Source

Transitions are executed as part of a more complex compound transition that takes a StateMachine execution from one stable state configuration to another.

Source

NOTE. The duration of a Transition traversal is undefined, allowing for different semantic interpretations, including both “zero” and non-“zero” time.

Source

It may have an associated effect Behavior, which is executed when the Transition is traversed (executed).

Source

A Transition is a single directed arc originating from a single source Vertex and terminating on a single target Vertex (the source and target may be the same Vertex), which specifies a valid fragment of a StateMachine Behavior.

Source

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Transitions

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

Section

Slide kind

Otherwise, the appropriate history entry into the Region is executed (see above). If no default history Transition is defined, then standard default entry of the Region is performed ....

Source

This is a Transition that originates in the history Pseudostate and terminates on a specific Vertex (the default history state) of the Region containing the history Pseudostate. This Transition is only taken if execution leads to the history Pseudostate a

Source

In cases where a Transition terminates on a history Pseudostate when the State has not been entered before (i.e., no prior history) or it had reached its FinalState, there is an option to force a transition to a specific substate, using the default ...

Source

Shallow history (shallowHistory) represents a return to only the topmost substate of the most recent state configuration, which is entered using the default entry rule.

Source

The effect is the same as if the Transition terminating on the deepHistory Pseudostate had, instead, terminated on the innermost State of the preserved state configuration, including execution of all entry Behaviors encountered along the way.

Source

Deep history (deepHistory) represents the full state configuration of the most recent visit to the containing Region.

Source

Two types of history Pseudostates are provided.

Source

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Pseudostates - deepHistory and shallowHistory

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

Section

Slide kind

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Pseudostates - choice

Gallery

Tutorial

Section

Slide kind

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Pseudostates - junction

Gallery

Tutorial

Section

Slide kind

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Pseudostates - initial, fork, join, terminate

Gallery

Tutorial

Section

Slide kind

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

The entry, doActivity, and effect Behaviors defined on a submachine State are specific that particular usage of its Submachine

Using submachines

Gallery

Tutorial

Section

Slide kind

If there is no outgoing Transition inside the composite State, then the incoming Transition simply performs a default State entry.

Source

In effect, the latter is a continuation of the external incoming Transition, with the proviso that the execution of the entry Behavior of the composite State (if defined) occurs between the effect Behavior of the incoming Transition and the effect ...

Source

Entry points represent termination points (sources) for incoming Transitions and origination points (targets) for Transitions that terminate on some internal Vertex of the composite State.

Source

If the composite State has an exit Behavior defined, it is executed after any effect Behavior of the incoming inside Transition and before any effect Behavior of the outgoing external Transition.

Source

In a well-formed model, such a Transition should have a corresponding external Transition outgoing from the same exit point, representing a continuation of the terminating Transition.

Source

Exit points are the inverse of entry points. That is, Transitions originating from a Vertex within the composite State can terminate on the exit point.

Source

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Submachines: entryPoint and exitPoint

Gallery

Tutorial

Section

Slide kind

Regardless of how a State is entered, the StateMachine is deemed to be “in” that State even before any entry Behavior or effect Behavior (if defined) of that State start executing.

Source

If the Transition explicitly enters one or more Regions (in case of a fork), these Regions are entered explicitly and the others by default.

Source

If the Transition terminates on the edge of the composite State (i.e., without entering the State), then all the Regions are entered using the default entry rule above.

Source

If the composite State is also an orthogonal State with multiple Regions, each of its Regions is also entered, either by default or explicitly.

Source

Transition::trigger : Trigger [0..*] ... Specifies the Triggers that may fire the transition

Source

Transition::target : Vertex [1..1] ... Designates the target Vertex that is reached when the Transition is taken.

Source

Transition::source : Vertex [1..1] ... Designates the originating Vertex (State or Pseudostate) of the Transition.

Source

Transition::/redefinitionContext : Classifier [1..1] ... References the Classifier in which context this element may be redefined.

Source

Transition::redefinedTransition : Transition [0..1] ... The Transition that is redefined by this Transition.

Source

Transition::guard : Constraint [0..1] ... 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.

Source

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 occurrence is dispatched by the StateMachine. ...

Source

Transition::effect : Behavior [0..1] ... Specifies an optional behavior to be performed when the Transition fires.

Source

Transition::container : Region [1..1] ... Designates the Region that owns this Transition.

Source

Transition::kind : TransitionKind [1..1] = external Indicates the precise type of the Transition.

Source

A Transition represents an arc between exactly one source Vertex and exactly one Target vertex (the source and targets may be the same Vertex). It may form part of a compound transition, which takes the StateMachine from one steady State configuration...

Source

Regardless of how a State is exited, the StateMachine is deemed to have “left” that State only after the exit Behavior (if defined) of that State has completed execution.

Source

When exiting from an orthogonal State, each of its Regions is exited. After that, the exit Behavior of the State is executed.

Source

If the exit occurs through an exitPoint Pseudostate, then the exit Behavior of the State is executed after the effect Behavior of the Transition terminating on the exit point.

Source

When exiting from a composite State, exit commences with the innermost State in the active state configuration. This means that exit Behaviors are executed in sequence starting with the innermost active State.

Source

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Composite state entry and exit points

Gallery

Tutorial

Section

Slide kind

MagicDraw/Cameo: GOTCHA: ‘entry’, ‘exit’, ‘doActivity’ are all subsets of ‘ownedElement’; to use an existing Activity without changing its owner you need to create a “wrapper” Activity. Beware the tool does not simply move your Activity!

If the State has a doActivity Behavior that is still executing when the State is exited, that Behavior is aborted before the exit Behavior commences execution.

Source

When exiting a State, regardless of whether it is simple or composite, the final step involved in the exit, after all other Behaviors associated with the exit are completed, is the execution of the exit Behavior of that State.

Source

... if a doActivity Behavior is defined for the State, this Behavior commences execution immediately after the entry Behavior is executed. It executes concurrently with any subsequent Behaviors associated with entering the State, such as the entry ...

Source

... the entry Behavior of the State is executed (if defined) upon entry, but only after any effect Behavior associated with the incoming Transition is completed.

Source

A State may also have an associated doActivity Behavior. This Behavior commences execution when the State is entered (but only after the State entry Behavior has completed) and executes concurrently with any other Behaviors that may be associated ...

Source

In addition, a State may also have an associated exit Behavior, which, if defined, is executed whenever the State is exited.

Source

A State may have an associated entry Behavior. This Behavior, if defined, is executed whenever the State is entered through an external Transition.

Source

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Effect, Entry, Do, Exit

Gallery

Tutorial

Section

Slide kind

A State is said to be active if it is part of the active state configuration.

Source

StateMachine execution is represented by transitions from one active state configuration to another in response to Event occurrences that match the Triggers of the StateMachine.

Source

An executing StateMachine instance can only be in exactly one state configuration at a time, which is referred to as its active state configuration.

Source

For example, one valid state configuration for an execution of the StateMachine depicted in Figure 14.9 is: <CourseAttempt - Studying – (Studying::Lab2, Studying::TermProject, Studying::FinalTest)>.

Source

Similarly, we can talk about such a hierarchy of substates within a composite State. This complex hierarchy of States is referred to as a state configuration (of a State or a StateMachine).

Source

Consequently, a particular “state” of an executing StateMachine instance is represented by one or more hierarchies of States, starting with the topmost Regions of the StateMachine and down through the composition hierarchy to the simple, or leaf, States.

Source

In general, a StateMachine can have multiple Regions, each of which may contain States of its own, some of which may be composites with their own multiple Regions, etc.

Source

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

State configurations

Gallery

Tutorial

Section

Slide kind

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Kinds of States

Gallery

Tutorial

Section

Slide kind

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

uml101 - StateMachines - NOTATION REFERENCE CARD

Gallery

Tutorial

Section

Slide kind

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

01:03: UML Behavior: StateMachines quick start

Slides in this section

If you want to navigate the entire section including the additional explanatory text click on the title link of the first slide to view the full slide page, then use the next links to move through the slide pages. If you just want to view the slide images only in sequence, click on any slide to view it larger in a viewer, then click again to move through each slide in this tutorial trail section.

Behavior StateMachines can be used to specify any of the following

StateMachines - simplified metaclass hierarchy

UML Event types for triggering Transitions

uml101 - StateMachines - NOTATION REFERENCE CARD

Kinds of States

State configurations

Effect, Entry, Do, Exit

Composite state entry and exit points

Submachines: entryPoint and exitPoint

Using submachines

Pseudostates - initial, fork, join, terminate

Pseudostates - junction

Pseudostates - choice

Pseudostates - deepHistory and shallowHistory

Transitions

Completion transitions and implicit triggers

UML Event types for triggering Transitions

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Section

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Slide kind

UML Profile Diagram

StateMachines - simplified metaclass hierarchy

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

Section

TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo

Slide kind

UML Profile Diagram

UML2 StateMachine - metaclasses - ADVANCED REFERENCE ONLY

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

Section

01:02: UML 101 for model-based systems engineering with SysML

Slide kind

UML Profile Diagram

Parts in these systems may interact by many different means, such as software operations, discrete state transitions, flows of inputs and outputs, or continuous interactions.

Source

This diagram expresses only the nominal states. Exception states, like “acceleratorFailure,” are not expressed on this diagram.

Source

Also note that this state machine refines the requirement “PowerSourceManagment,” which will be elaborated in the requirements sub clause of this sample problem.

Source

Note that this state machine was developed in conjunction with the DriveBlackBox interaction in Figure D.7.

Source

Figure D.8 depicts the operational states of the HSUV block, via a State Machine named “HSUVOperationalStates.”

Source

TRAIL: The SysML-1.6 Hybrid SUV sample and specification diagrams in MagicDraw/Cameo (with annotations) [UNDERGOING UPDATE to SysML1.7]

Figure D.8 - Finite State Machine Associated with “Drive the Vehicle”

Gallery

Tutorial

Section

Section: SysML-1.6: HSUV sample

Slide kind

SysML StateMachine Diagram

Object Constraint Language Version 2.4

The operation oclIsInState(s) results in true if the object is in the state s. Possible states for the operation oclIsInState(s) are all states of the statemachine that defines the classifier's behavior. For nested states the statenames can be combined...

Source

The conditions for each alternative in the alt controlSpeed sub clause are expressed in OCL, and relate to the states of the HybridSUV block, as shown in Figure D.8.

Source

14.5.2 FinalState ... If the enclosing Region is directly contained in a StateMachine and all other Regions in that StateMachine also are completed, then it means that the entire StateMachine behavior is completed.

Source

14.5.2 FinalState - A special kind of State, which, when entered, signifies that the enclosing Region has completed.

Source

ObjectNodes may also specify an inState set of States. If such a set is specified, then any object token held by the ObjectNode shall have a value with a type that has or inherits a StateMachine as its classifierBehavior that has all of the states ..

Source

HOWTO simulate UML-2.5.1 'Figure 14.7 Composite State with two States' in Cameo Simulation Toolkit - Operation-driven Transition case study

Screencast: Tutorial: UML/SysML: StateMachines vs Activities: Operation-driven Transition case study - UML-2.5.1 'Figure 14.7 Composite State with two States' in Cameo Simulation Toolkit

Keywords

Video style

This video accompanies this detailed tutorial trail: HOWTO simulate UML-2.5.1 'Figure 14.7 Composite State with two States' in Cameo Simulation Toolkit - Operation-driven Transition case study.

This full length tutorial is a case study of the telephone dialer StateMachine shown in 'Figure 14.7 Composite State with two States' of the UML-2.5.1 specification.

Read more about Screencast: Tutorial: UML/SysML: StateMachines vs Activities: Operation-driven Transition case study - UML-2.5.1 'Figure 14.7 Composite State with two States' in Cameo Simulation Toolkit

StateMachine for the Dialer class

Gallery

Tutorial

Section

Slide kind

HOWTO simulate UML-2.5.1 'Figure 14.7 Composite State with two States' in Cameo Simulation Toolkit - Operation-driven Transition case study

Figure 14.7 Composite State with two States

Gallery

Tutorial

Section

Slide kind

HOWTO invoke an operation as a Transition guard in Cameo Simulation Toolkit

StateMachine diagram for comparing action language access to an operation for a guard

Gallery

Tutorial

Section

Slide kind

terminate – Entering a terminate Pseudostate implies that the execution of the StateMachine is terminated immediately. The StateMachine does not exit any States nor does it perform any exit Behaviors. Any executing doActivity Behaviors are ... aborted

Source

shallowHistory Pseudostate can only be defined for composite States and, at most one such Pseudostate can be included in a Region of a composite State.

Source

shallowHistory – ... A single outgoing Transition from this Pseudostate may be defined terminating on a substate of the composite State. This substate is the default shallow history state of the composite State.

Source

shallowHistory – ... this type of Pseudostate is a kind of variable that represents the most recent active substate of its containing Region, but not the substates of that substate. A Transition terminating on this Pseudostate implies rest

Source

A deepHistory Pseudostate can only be defined for composite States and, at most one such Pseudostate can be contained in a Region of a composite State.

Source

deepHistory – ... The entry Behaviors of all States in the restored state configuration are performed in the appropriate order starting with the outermost State

Source

deepHistory – This type of Pseudostate is a kind of variable that represents the most recent active state configuration of its owning Region. ... a Transition terminating on this Pseudostate implies restoring the Region to that same state ...

Source

exitPoint – ... If multiple Transitions from orthogonal Regions within the State terminate on this Pseudostate, then it acts like a join Pseudostate.

Source

Transitions terminating on an exit point within any Region of the composite State or a StateMachine referenced by a submachine State implies exiting of this composite State or submachine State (with execution of its associated exit Behavior).

Source

exitPoint – An exitPoint Pseudostate is an exit point of a StateMachine or composite State that provides encapsulation of the insides of the State or StateMachine.

Source

entryPoint – ... NOTE. ... If multiple Regions are involved, the entry point acts as a fork Pseudostate.

Source

entryPoint – ... NOTE. If the owning State has an associated entry Behavior, this Behavior is executed before any behavior associated with the outgoing Transition.

Source

In each Region of the StateMachine or composite State owning the entryPoint, there is at most a single Transition from the entry point to a Vertex within that Region.

Source

entryPoint – An entryPoint Pseudostate represents an entry point for a StateMachine or a composite State that provides encapsulation of the insides of the State or StateMachine.

Source

When a Region of the submachine StateMachine reaches the corresponding exit point, the submachine state is exited via this exit point.

Source

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.

Source

An entry point connection point reference as the target of a Transition implies that the target of the Transition is the entryPoint Pseudostate as defined in the submachine of the submachine State. As a result, the Regions of the submachine ...

Source

Connection point references are sources/targets of Transitions implying exits out of/entries into the submachine StateMachine referenced by a submachine State.

Source

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 StateMachine referenced by the submachine State.

Source

14.2.3.5 ConnectionPointReference ... a connection point reference represents a usage (as part of a submachine State) of an entry/exit point defined in the StateMachine referenced by the submachine State.

Source

Exiting via a FinalState or by a group Transition has the same meaning as for ordinary composite States.

Source

a submachine Statemachine can be exited as a result of: reaching its FinalState; triggering of a group Transition originating from a submachine State, or; via any of its exit points.

Source

Any guards associated with these entry point Transitions must evaluate to true in order for the specification to be well formed.

Source

An entry point is equivalent to a junction Pseudostate (fork in cases where the composite State is orthogonal): Entering via an entry point implies that the entry Behavior of the composite state is executed, followed by the Transition from the entry ...

Source

A submachine StateMachine 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 ...

Source

NOTE. Each submachine State represents a distinct instantiation of a submachine, even when two or more submachine States reference the same submachine.

Source

The entry, exit, and effect Behaviors and internal Transitions are defined as contained in the submachine State.

Source

The Regions of the submachine StateMachine are the Regions of the composite State.

Source

A submachine State implies a macro-like insertion of the specification of the corresponding submachine StateMachine. It is, therefore, semantically equivalent to a composite State.

Source

Each ConnectionPointReference is matched by a corresponding entry or exit point in the referenced submachine StateMachine. This provides the necessary binding mechanism between the submachine invocation and its specification.

Source

A ConnectionPointReference represents a point on the submachine State at which a Transition either terminates or originates. That is, they serve as targets for incoming Transitions to submachine States, as well as sources for outgoing Transitions ...

Source

The concept of ConnectionPointReference is provided to support binding between the submachine State and the referenced StateMachine.

Source

Consequently, they require a more complex binding. This is achieved through the concept of submachine State (i.e., States with isSubmachineState = true), which represent references to corresponding submachine StateMachines.

Source

However, whereas encapsulated composite States and their internals are contained within the StateMachine in which they are defined, submachines are, like programming language macros, distinct Behavior specification ...

Source

Submachines are a means by which a single StateMachine specification can be reused multiple times. They are similar to encapsulated composite States in that they need to bind incoming and outgoing Transitions to their internal Vertices.

Source