StateMachine

© Copyright 2020 Darren R C Kelly (Webel IT Australia).

Read more about Screencast: The Webel Digital Twin Pattern for SysML: Part 1: Simulating acquisition or creation of physical assets using Activities and StateMachines in Cameo Simulation Toolkit.

23: Mini StateMachine for DigitalTwin and DoAttach effect Activity

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

TRAIL: A SysML Pattern for Digital Twinning

Section

Slide kind

hybrid diagram

SysML Activity Diagram

SysML StateMachine Diagram

22: Mini StateMachines for @Entity, PotentialPhysicalAsset, ActualPhysicalAsset

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

TRAIL: A SysML Pattern for Digital Twinning

Section

Slide kind

hybrid diagram

SysML StateMachine Diagram

Chain on a CallBehaviorAction for an Operation trigger of a Transition with an effect

Gallery

Tutorial

HOWTO return chain on a CallBehaviorAction for an Operation trigger of a Transition with an effect

Section

Slide kind

hybrid diagram

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

SysML StateMachine Diagram

Cameo Simulation Toolkit matches the Parameters of an effect Behavior and a trigger Operation on a Transition under the hood.

HOWTO return chain on a CallBehaviorAction for an Operation trigger of a Transition with an effect

Jump to first slide

Chain on a CallBehaviorAction for an Operation trigger of a Transition with an effect

Sections

Screencast: UML/SysML: HOWTO Consume a SignalEvent message in a StateMachine Transition 'effect' or State 'entry' or 'exit' Activity

Keywords

Magic Model Analyst [Cameo Simulation Toolkit]

Unified Modeling Language

Cameo Systems Modeler

Systems Modeling Language

UML

SysML

MagicDraw SysML

Video style

narrated

screencast

4K

© Copyright 2020 Darren R C Kelly (Webel IT Australia). All rights reserved.

Consume a SignalEvent message in a StateMachine Transition 'effect' or State 'entry' or 'exit' Activity

Gallery

Tutorial

UML/SysML: HOWTO Consume a SignalEvent message in a StateMachine Transition 'effect' or State 'entry' or 'exit' Activity

Section

Slide kind

hybrid diagram

UML Activity Diagram

UML Class Diagram

UML StateMachine Diagram

UML/SysML: HOWTO Consume a SignalEvent message in a StateMachine Transition 'effect' or State 'entry' or 'exit' Activity

Jump to first slide

Consume a SignalEvent message in a StateMachine Transition 'effect' or State 'entry' or 'exit' Activity

Sections

Screencast: UML/SysML StateMachines: How a completion transition works (and why you should avoid them)

Keywords

Magic Model Analyst [Cameo Simulation Toolkit]

Unified Modeling Language

Cameo Systems Modeler

Video style

narrated

screencast

4K

Explains what a completion transition is and how to simulate and explore it in Cameo Simulation Toolkit for MagicDraw UML, MagicDraw SysML, or Cameo Systems Modeler.

Please note that this is NOT a recommendation to use completion transitions!

© Copyright 2020 Darren R C Kelly (Webel IT Australia). All rights reserved.

Completion transitions and implicit triggers

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

hybrid diagram

UML Activity Diagram

UML Class Diagram

UML StateMachine Diagram

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

BUG: Cameo Simulation Toolkit 19SP3: StateMachine: Crashes with an irrelevant "memory error" report if you fire a signal Trigger during execution of an 'entry' Activity with a timer

UML-2.5.1 does NOT permit a trigger or guard on a Transition from an initial pseudostate in a StateMachine but Cameo/MagicDraw does (please avoid).

REFERENCE CARD: Property cheat-sheet for Block

Gallery

Tutorial

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

Section

08:01: The building Blocks of SysML

Slide kind

SysML Block Definition Diagram (BDD)

13:01: StateMachines [see UML 101 section]

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

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

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

01:03: UML Behavior: StateMachines quick start

Slide kind

UML StateMachine Diagram

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

Pseudostates - deepHistory and shallowHistory

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 StateMachine Diagram

Pseudostates - choice

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 StateMachine Diagram

Pseudostates - junction

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 StateMachine Diagram

Pseudostates - initial, fork, join, terminate

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 StateMachine Diagram

Using submachines

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 StateMachine Diagram

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

Submachines: entryPoint and exitPoint

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 StateMachine Diagram

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

Composite state entry and exit points

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 StateMachine Diagram

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

... 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

Unified Modeling Language 2.5.1

... 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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

Effect, Entry, Do, Exit

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 StateMachine Diagram

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

State configurations

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 StateMachine Diagram

Kinds of States

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 StateMachine Diagram

uml101 - StateMachines - NOTATION REFERENCE CARD

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 StateMachine Diagram

01:03: UML Behavior: StateMachines quick start

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

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

01:03: UML Behavior: StateMachines quick start

Slide kind

UML Profile Diagram

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

Behavior StateMachines can be used to specify any of the following

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 Class Diagram

Class compartments

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 Class 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

Blocks may also specify operations or other features that describe the behavior of a system

Source

OMG Systems Modeling Language (SysML) 1.6

REFERENCE CARD: Types of Block Properties and Block compartments

Gallery

Tutorial

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

Section

08:01: The building Blocks of SysML

Slide kind

SysML Block Definition Diagram (BDD)

ExampleBlock in a Block Definition Diagram (BDD)

Gallery

Tutorial

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

Section

08:01: The building Blocks of SysML

Slide kind

SysML Block Definition Diagram (BDD)

The behaviors of a UseCase can be described by a set of Behaviors (through its ownedBehavior relationship), such as Interactions, Activities, and StateMachines, as well as by pre-conditions, post-conditions and natural language text where appropriate.

Source

Unified Modeling Language 2.5.1

The Verify relationship is shown on Figure 16-7 using callout notation anchored to the diagram frame, which indicates that the BurnishTest test case verifies the Burnish requirement.

Source

OMG Systems Modeling Language (SysML) 1.6

Figure 17-1 [Figure 16-7] is a state machine diagram of the BurnishTest test case, which expresses the textual sequence and criteria of the Burnish requirement in state machine form.

Source

OMG Systems Modeling Language (SysML) 1.6

Figure 13-1: Block definition diagram with state machines as blocks associated with submachines and types of parameters

Gallery

Tutorial

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

Section

Section: SysML-1.6 specification diagrams: 13 StateMachines

Slide kind

SysML Block Definition Diagram (BDD)

State machines in block definition diagrams can also appear with the same notation as submachine states.

Source

OMG Systems Modeling Language (SysML) 1.6

Properties with AdjunctProperty applied, where the principal of the AdjunctProperty is a parameter of the state machine, can be used as the end of the associations towards the parameter type.

Source

OMG Systems Modeling Language (SysML) 1.6

Properties with AdjunctProperty applied, where the principal of the AdjunctProperty is a submachine state, can be used as the end of the associations towards the sub state machine.

Source

OMG Systems Modeling Language (SysML) 1.6

State machines in block definition diagrams appear as regular blocks, except the «stateMachine» keyword may be used to indicate the Block stereotype is applied to a state machine, as shown in Figure 13-1.

Source

OMG Systems Modeling Language (SysML) 1.6

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

Source

OMG Systems Modeling Language (SysML) 1.6

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

Source

OMG Systems Modeling Language (SysML) 1.6

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

Source

OMG Systems Modeling Language (SysML) 1.6

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

Source

OMG Systems Modeling Language (SysML) 1.6

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

Gallery

Tutorial

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

Section

Section: SysML-1.6: HSUV sample

Slide kind

SysML StateMachine Diagram

UML StateMachine Diagram

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

Object Constraint Language Version 2.4

ObjectNodes may specify an inState set of States

Gallery

Tutorial

TRAIL: UML Behavior: Activities and Actions

Section

Slide kind

UML Activity Diagram

UML Class Diagram

UML hybrid diagram

UML StateMachine Diagram

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

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

A StateMachine or composite State may contain multiple Regions representing behaviors that may occur in parallel.

Source

Unified Modeling Language 2.5.1

A Region is a top-level part of a StateMachine or a composite State, that serves as a container for the Vertices and Transitions of the StateMachine.

Source

Unified Modeling Language 2.5.1

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

A Vertex is an abstraction of a node in a StateMachine graph. It can be the source or destination of any number of Transitions.

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

A quick look at accessing an Operation on a Transition or ActivityEdge guard with Alf vs ALH

Gallery

Tutorial

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

Section

Slide kind

UML Activity Diagram

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

Magic Model Analyst [Cameo Simulation Toolkit]

Unified Modeling Language

Video style

narrated

screencast

4K

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

The WhenValid Activity as effect Behavior

Gallery

Tutorial

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

Section

Slide kind

UML Activity Diagram

The number validation guard

Gallery

Tutorial

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

Section

Slide kind

UML StateMachine Diagram

StateMachine for the Dialer class

Gallery

Tutorial

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

Section

Slide kind

UML StateMachine Diagram

Overview: Controller class (and its Activity), Dialer Class (and its StateMachine), Number class

Gallery

Tutorial

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

Section

Slide kind

UML Class Diagram

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

Gallery

Tutorial

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

Section

Slide kind

UML StateMachine Diagram

Cameo Simulation Toolkit 19SP3 SUPPORTS StateMachine

fUML-1.4 EXCLUDES StateMachine

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

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

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

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

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

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

fUML-1.4 EXCLUDES ProtocolStateMachine

Screencast: Mini tutorial: UML/SysML: Cameo Simulation Toolkit: StateMachine with doActivity and a Transition with a ChangeEvent trigger

Keywords

SysML

UML

state machine

Magic Model Analyst [Cameo Simulation Toolkit]

Cameo Systems Modeler

MagicDraw UML

MagicDraw SysML

Video style

screencast

narrated

4K

A very simple demonstration of a StateMachine with a doActivity and a Transition that uses a trigger with a ChangeEvent for checking a value. Uses SysML but the same applies to UML.

Uses Magic Model Analyst^® (Cameo Simulation Toolkit^®) for MagicDraw SysML and Cameo System Modeler Enterprise Edition.

© Copyright 2020 Darren R C Kelly (Webel IT Australia). All rights reserved.

Screencast: Mini tutorial: UML/SysML: Cameo Simulation Toolkit: StateMachine with entry Activity and Transition guard

Keywords

SysML

UML

state machine

guard

Magic Model Analyst [Cameo Simulation Toolkit]

Cameo Systems Modeler

MagicDraw UML

MagicDraw SysML

Video style

screencast

narrated

4K

A very simple demonstration of a StateMachine with an entry Activity and Transitions that use guards to check a value. Uses SysML but the same applies to UML.

Uses Cameo Simulation Toolkit for MagicDraw SysML and Cameo System Modeler.

© Copyright 2020 Darren R C Kelly (Webel IT Australia). All rights reserved.

Subscribe to StateMachine