Pseudostate

The transition from the initial pseudostate to StandBy has a relative TimeEvent with an expression indicating that the transition fires 5 seconds after the initial pseudostate is entered.

Source

The state machine has one initial pseudostate, and two states StandBy and On.

Source

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

Two types of history Pseudostates are provided.

Source

Unified Modeling Language 2.5.1

StateMachines - simplified metaclass hierarchy

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

01:03: UML Behavior: StateMachines quick start

Slide kind

UML Profile Diagram

UML2 StateMachine - metaclasses - ADVANCED REFERENCE ONLY

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

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

Slide kind

UML Profile Diagram

A Pseudostate is an abstraction that encompasses different types of transient Vertices in the StateMachine graph. A StateMachine instance never comes to rest in a Pseudostate, instead, it will exit and enter the Pseudostate within a single ... step

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

junction – ... If more than one guard evaluates to true, one of these is chosen. The algorithm for making this selection is not defined.

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

choice – ... If none of the guards evaluates to true, then the model is considered ill formed. To avoid this, it is recommended to define one outgoing Transition with the predefined “else” guard for every choice Pseudostate.

Source

Unified Modeling Language 2.5.1

choice – ... If more than one guard evaluates to true, one of the corresponding Transitions is selected. The algorithm for making this selection is not defined.

Source

Unified Modeling Language 2.5.1

Consequently, choice is used to realize a dynamic conditional branch. It allows splitting of compound transitions into multiple alternative paths such that the decision on which path to take may depend on the results of Behavior executions performed ...

Source

Unified Modeling Language 2.5.1

choice – This type of Pseudostate is similar to a junction Pseudostate ... and serves similar purposes, with the difference that the guard Constraints on all outgoing Transitions are evaluated dynamically ...

Source

Unified Modeling Language 2.5.1

(As a way of avoiding this situation in some cases, it is possible to associate a predefined guard denoted as “else” with at most one outgoing Transition. This Transition is enabled if all the guards attached to the other Transitions evaluate to false).

Source

Unified Modeling Language 2.5.1

junction – ...It may happen that, for a particular compound transition, the configuration of Transition paths and guard values is such that the compound transition is prevented from reaching a valid state configuration. In those cases, the entire ...

Source

Unified Modeling Language 2.5.1

NOTE. Such guard Constraints are evaluated before any compound transition containing this Pseudostate is executed, which is why this is referred to as a static conditional branch.

Source

Unified Modeling Language 2.5.1

.. a junction Pseudostate ... can be used to split an incoming Transition into multiple outgoing Transition segments with different guard Constraints.

Source

Unified Modeling Language 2.5.1

For example, a junction Pseudostate can be used to merge multiple incoming Transitions into a single outgoing Transition representing a shared continuation path.

Source

Unified Modeling Language 2.5.1

junction – This type of Pseudostate is used to connect multiple Transitions into compound paths between States.

Source

Unified Modeling Language 2.5.1

The Transitions outgoing from a fork Pseudostate cannot have a guard or a trigger.

Source

Unified Modeling Language 2.5.1

fork – fork Pseudostates serve to split an incoming Transition into two or more Transitions terminating on Vertices in orthogonal Regions of a composite State.

Source

Unified Modeling Language 2.5.1

Similar to junction points in Petri nets, join Pseudostates perform a synchronization function, whereby all incoming Transitions have to complete before execution can continue through an outgoing Transition.

Source

Unified Modeling Language 2.5.1

Transitions terminating on a join Pseudostate cannot have a guard or a trigger.

Source

Unified Modeling Language 2.5.1

join – This type of Pseudostate serves as a common target Vertex for two or more Transitions originating from Vertices in different orthogonal Regions.

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

Subscribe to Pseudostate