Activity

26: Activity IdentifyAcquireAttachPhysical

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

TRAIL: The Webel SysMLv1 Pattern for Digital Twinning

Section

Slide kind

SysML Activity Diagram

23: Mini StateMachine for DigitalTwin and DoAttach effect Activity

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

TRAIL: The Webel SysMLv1 Pattern for Digital Twinning

Section

Slide kind

hybrid diagram

SysML Activity Diagram

SysML StateMachine Diagram

24: Case: Acquisition: Twin a pre-existing physical asset

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

TRAIL: The Webel SysMLv1 Pattern for Digital Twinning

Section

Slide kind

hybrid diagram

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

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

Simulation video of sending an receiving a Signal via a Port in Cameo Simulation Toolkit

Gallery

Tutorial

HOWTO: Send and receive a Signal via Ports in SysML and Cameo Simulation Toolkit

Section

Slide kind

still

Screencast: HOWTO: Send and receive a Signal via Ports in SysML and Cameo Simulation Toolkit

Keywords

• Magic Model Analyst [Cameo Simulation Toolkit]
• Unified Modeling Language
• Systems Modeling Language
• Cameo Systems Modeler

Video style

• narrated
• screencast
• 4K

This video accompanies this mini tutorial trail: HOWTO: Send and receive a Signal via Ports in SysML and Cameo Simulation Toolkit.

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

Activity of Display

Gallery

Tutorial

HOWTO: Send and receive a Signal via Ports in SysML and Cameo Simulation Toolkit

Section

Slide kind

SysML Activity Diagram

The Append activity within Number

Gallery

Tutorial

HOWTO: Send and receive a Signal via Ports in SysML and Cameo Simulation Toolkit

Section

Slide kind

SysML Activity Diagram

Activity of Receiver

Gallery

Tutorial

HOWTO: Send and receive a Signal via Ports in SysML and Cameo Simulation Toolkit

Section

Slide kind

SysML Activity Diagram

Activities of Keypad

Gallery

Tutorial

HOWTO: Send and receive a Signal via Ports in SysML and Cameo Simulation Toolkit

Section

Slide kind

hybrid diagram

SysML Activity Diagram

«effbd» Specifies that the activity conforms to the constraints necessary for EFFBD.

Source

OMG Systems Modeling Language (SysML) 1.6

«nonStreaming» Used for activities that accept inputs only when they start, and provide outputs only when they finish. The activity has no streaming parameters.

Source

OMG Systems Modeling Language (SysML) 1.6

«streaming» Used for activities that can accept inputs or provide outputs after they start and before they finish. The activity has at least one streaming parameter.

Source

OMG Systems Modeling Language (SysML) 1.6

StructuredActitivityNodes (structured actions) - 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:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

ExpansionRegion: running «iterative» example

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:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

Once the test fails and the loop is completed, the tokens on the bodyOutput OutputPins from the last iteration are moved to the result OutputPins and offered on any edges outgoing from those OutputPins.

Source

Unified Modeling Language 2.5.1

After the completion of each execution of the bodyPart of the LoopNode, any remaining tokens on the loopVariable OutputPins are destroyed and tokens on the bodyOutput OutputPins are copied to the corresponding loopVariable OutputPins so that they are ...

Source

Unified Modeling Language 2.5.1

When the LoopNode begins executing, the tokens on the loopVariableInput InputPins are moved to the corresponding loopVariable OutputPins before the first iteration of the loop.

Source

Unified Modeling Language 2.5.1

If a LoopNode has loopVariable OutputPins, then it must also have matching sets of loopVariableInput InputPins, bodyOutput OutputPins (owned by Actions within the bodyPart), and result OutputPins.

Source

Unified Modeling Language 2.5.1

A LoopNode may also define a set of loopVariable OutputPins used to hold intermediate values during each loop iteration. These OutputPins may have outgoing ActivityEdges, in order to make the values they hold available within the test and bodyPart ...

Source

Unified Modeling Language 2.5.1

After each execution of the bodyPart, the test section is executed again, for the next iteration of the loop.

Source

Unified Modeling Language 2.5.1

The test section has an Action owning the decider OutputPin with type Boolean identified by the LoopNode. When the test section has completed execution, if the value on the decider OutputPin is true, then the bodyPart is executed. Otherwise ...

Source

Unified Modeling Language 2.5.1

Execution of the test section may precede or follow execution of the bodyPart, depending on whether isTestFirst is true or false, respectively. ... If the bodyPart is executed first (isTestFirst=false), it is always executed at least once ...

Source

Unified Modeling Language 2.5.1

The setupPart of a LoopNode is executed first. When the setupPart has completed execution, the iterative execution of the loop begins.

Source

Unified Modeling Language 2.5.1

Any ExecutableNode in the LoopNode must be included in the setupPart, test or bodyPart for the LoopNode.

Source

Unified Modeling Language 2.5.1

A LoopNode is a StructuredActivityNode that represents an iterative loop. A LoopNode consists of a setupPart, a test and a bodyPart, which identify subsets of the ExecutableNodes contained in the LoopNode.

Source

Unified Modeling Language 2.5.1

LoopNode: running loopVariable example

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

LoopNode with loopVariable - ADVANCED REFERENCE

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:04: UML Behavior: Activities quick start

Loop: running example using DecisionNode and MergeNode and an Integer property in a context

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

LoopNode: basic running example

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

ExecutableNode has implicit fork

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

OPTION double InitialNode

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

CORRECT InitialNode explicit fork

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

INCORRECT InitialNode no implicit fork

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

ForkNode and JoinNode with optional ControlFlow guards - LIMITED SUPPORT

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

If a JoinNode does not have a joinSpec, then this is equivalent to a joinSpec Expression with the Boolean operator “and.” That is, the implicit default joinSpec condition is that there is at least one token offered on each incoming ActivityEdge.

Source

Unified Modeling Language 2.5.1

Alternatively, the joinSpec may consist of an Expression with the name of a single Boolean operator and no operands specified. In this case, the value of the joinSpec shall be given by applying the given operator to Boolean values indicating ...

Source

Unified Modeling Language 2.5.1

If the joinSpec ValueSpecification is given by a textual expression, then the names of the incoming edges may be used to denote ... the value associated with an object token offered from an ObjectFlow (if any).

Source

Unified Modeling Language 2.5.1

If the joinSpec ValueSpecification is given by a textual expression, then the names of the incoming edges may be used to denote a Boolean value indicating the presence (true) or absence (false) of an offer from a ControlFlow ...

Source

Unified Modeling Language 2.5.1

joinSpec ... This evaluation shall not be interrupted by any new tokens offered during the evaluation, nor shall concurrent evaluations be started when new tokens are offered during an evaluation. The ValueSpecification shall evaluate to a Boolean value.

Source

Unified Modeling Language 2.5.1

Join nodes may have a joinSpec, which is a ValueSpecification that determines the condition under which the join will emit a token. If a JoinNode has a joinSpec, then this ValueSpecification is evaluated whenever a new token is offered to the JoinNode ...

Source

Unified Modeling Language 2.5.1

AND with ForkNode and JoinNode

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

OR with DecisionNode and MergeNode

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

UML2 Types of Pins - metaclasses

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:04: UML Behavior: Activities quick start

Slide kind

UML Profile Diagram

ActivityParameterNode cases - REFERENCE CARD

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:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

Parameter vs ActivityParameterNode vs Pin

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

Starting an Action that has a ValuePin - LIMITED SUPPORT

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

Starting an Action that has a ControlPin

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

Starting an Action that has an InputPin with multiplicity

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

If the Action is an invocation of a Behavior with streaming Parameters ... the Action execution may consume additional data supplied to InputPins corresponding to streaming input Parameters ... Otherwise ... any additional data on InputPins has no effect

Source

Unified Modeling Language 2.5.1

For structured Actions (StructuredActivityNodes ... ), data can remain on InputPins during Action execution, otherwise they are immediately removed from the InputPins by the ActionExecution.

Source

Unified Modeling Language 2.5.1

The Action execution consumes input data on all InputPins on the Action up to the upper multiplicity for each InputPin.

Source

Unified Modeling Language 2.5.1

However, if the Action is an invocation of a Behavior with streaming Parameters ... then the Action execution may also post data to OutputPins corresponding to streaming output Parameters before completion of the execution ...

Source

Unified Modeling Language 2.5.1

When completed, an Action execution provides any output data on the OutputPins of the Action, and it terminates.

Source

Unified Modeling Language 2.5.1

An Action continues executing until it has completed. The detailed semantics of the execution of an Action and the definition of its completion depend on the particular kind of Action being executed.

Source

Unified Modeling Language 2.5.1

The time at which an Action executes and what inputs are accepted by each execution are determined by the kind of Action it is, characteristics of its InputPins, and the Behavior in which it is used.

Source

Unified Modeling Language 2.5.1

When an Action in an Activity completes execution, object tokens for output data placed on its OutputPins may be offered on any outgoing ObjectFlows from those Pins ... In addition, control tokens shall be offered on any outgoing ControlFlows ...

Source

Unified Modeling Language 2.5.1

A ValuePin provides a value by evaluating a ValueSpecification ... When the Action is enabled by other means, the ValueSpecifiation of the ValuePin is evaluated, and the result is provided as an input to the Action when it begins execution.

Source

Unified Modeling Language 2.5.1

When the Action is enabled by other means, values are computed as specified for the ValuePins and ActionInputPins owned by an Action, and the results are provided as inputs to the Action when it begins execution.

Source

Unified Modeling Language 2.5.1

ValuePins and ActionInputPins are InputPins, but are not used in the determination of whether an Action is enabled for execution. If an Action has no other way to start execution, simply having ValuePins or ActionInputPins for its inputs will not enable..

Source

Unified Modeling Language 2.5.1

An Action may not put more values into an output in a single execution than the [upper] multiplicity of that OutputPin.

Source

Unified Modeling Language 2.5.1

For each execution, an Action cannot terminate itself unless it can put at least as many values into its outputs as required by the multiplicity lower bounds on those OutputPins. Values that may remain on the OutputPins from previous executions are not...

Source

Unified Modeling Language 2.5.1

An OutputPin is a Pin that holds output values produced by an Action.

Source

Unified Modeling Language 2.5.1

Tokens consumed by an Action are immediately removed from its InputPins when the action begins an execution (except in some cases for StructuredActivityNodes, where tokens may remain on InputPins during the Action execution ...)

Source

Unified Modeling Language 2.5.1

The upper multiplicity determines the maximum number of values that can be consumed from an InputPin by a single execution of its Action.

Source

Unified Modeling Language 2.5.1

An Action cannot start execution if one of its InputPins has fewer values than the lower multiplicity of that InputPin.

Source

Unified Modeling Language 2.5.1

An InputPin is a Pin that holds input values to be consumed by its Action.

Source

Unified Modeling Language 2.5.1

Starting an Action that has an InputPin

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

ActivityPartitions using “swimlane” notation

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

Activity example: send and catch Signal

Gallery

Tutorial

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

Section

01:04: UML Behavior: Activities quick start

Slide kind

hybrid diagram

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

An Action may accept inputs and produce outputs, as specified by InputPins and OutputPins of the Action, respectively. Each Pin on an Action specifies the type and multiplicity for a specific input or output of that Action.

Source

Unified Modeling Language 2.5.1

Pins are used to specify the inputs and outputs for Actions.

Source

Unified Modeling Language 2.5.1

An ActivityFinalNode is a FinalNode that stops all flows in an Activity (or StructuredActivityNode, see sub clause 16.11). A token reaching an ActivityFinalNode owned by an Activity terminates the execution of that Activity.

Source

Unified Modeling Language 2.5.1

A FlowFinalNode is a FinalNode that terminates a flow. All tokens accepted by a FlowFinalNode are destroyed. This has no effect on other flows in the Activity.

Source

Unified Modeling Language 2.5.1

A FinalNode is a ControlNode at which a flow in an Activity stops. A FinalNode shall not have outgoing ActivityEdges. A FinalNode accepts all tokens offered to it on its incoming ActivityEdges. There are two kinds of FinalNode:

Source

Unified Modeling Language 2.5.1

An OpaqueAction is an Action whose specification may be given in a textual concrete syntax other than UML. An OpaqueAction may also be used as a temporary placeholder before some other kind of Action is chosen.

Source

Unified Modeling Language 2.5.1

All tokens offered on the incoming edges of a MergeNode are offered to the outgoing edge. There is no synchronization of flows or joining of tokens.

Source

Unified Modeling Language 2.5.1

If the outgoing edge of a MergeNode is a ControlFlow, then all incoming edges must be ControlFlows, and, if the outgoing edge is an ObjectFlow, then all incoming edges must be ObjectFlows.

Source

Unified Modeling Language 2.5.1

A MergeNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges.

Source

Unified Modeling Language 2.5.1

A MergeNode is a control node that brings together multiple flows without synchronization.

Source

Unified Modeling Language 2.5.1

If any of the incoming edges of a JoinNode are ObjectFlows, the outgoing edge shall be an ObjectFlow. Otherwise the outgoing edge shall be a ControlFlow.

Source

Unified Modeling Language 2.5.1

A JoinNode is a ControlNode that synchronizes multiple flows. A JoinNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges.

Source

Unified Modeling Language 2.5.1

Tokens offered to a ForkNode are offered to all outgoing ActivityEdges of the node. If at least one of these offers is accepted, the offered tokens are removed from their original source and the acceptor receives a copy of the tokens.

Source

Unified Modeling Language 2.5.1

If the incoming edge is a ControlFlow, then all outgoing edges shall be ControlFlows and, if the incoming edge is an ObjectFlow, then all outgoing edges shall be ObjectFlows.

Source

Unified Modeling Language 2.5.1

A ForkNode is a ControlNode that splits a flow into multiple concurrent flows. A ForkNode shall have exactly one incoming ActivityEdge, though it may have multiple outgoing ActivityEdges.

Source

Unified Modeling Language 2.5.1

ExecutableNodes actually carry out the desired behavior of an Activity. If an ExecutableNode has incoming ControlFlows, then there must be tokens offered on all these flows that it accepts before beginning execution.

Source

Unified Modeling Language 2.5.1

ObjectNodes hold object tokens accepted from incoming ObjectFlows and may subsequently offer them to outgoing ObjectFlows (with a modeler-specified exception for ControlFlows, see isControlType for ObjectNodes ...).

Source

Unified Modeling Language 2.5.1

ControlNodes act as “traffic switches” managing the flow of tokens across ActivityEdges. Tokens cannot “rest” at ControlNodes (with exceptions for InitialNodes and ForkNodes ...).

Source

Unified Modeling Language 2.5.1

There are three kinds of ActivityNodes:

Source

Unified Modeling Language 2.5.1

Unlike ControlFlows, ObjectFlows also provide additional support for multicast/receive, token selection from ObjectNodes and transformation of tokens

Source

Unified Modeling Language 2.5.1

An ObjectFlow is an ActivityEdge that can have object tokens passing along it. ObjectFlows model the flow of values between ObjectNodes.

Source

Unified Modeling Language 2.5.1

ControlFlows are used to explicitly sequence execution of ActivityNodes, as the target ActivityNode cannot receive a control token and start execution until the source ActivityNode completes execution and produces the token.

Source

Unified Modeling Language 2.5.1

A ControlFlow is an ActivityEdge that only passes control tokens (and some object tokens as specified by modelers, see isControlType for ObjectNodes ...).

Source

Unified Modeling Language 2.5.1

There are two kinds of ActivityEdges:

Source

Unified Modeling Language 2.5.1

InitialNodes are an exception to the rule that ControlNodes cannot “hold” tokens, but only manage their flow.

Source

Unified Modeling Language 2.5.1

The outgoing ActivityEdges of an InitialNode must all be ControlFlows. The control token placed on an InitialNode is offered concurrently on all outgoing ControlFlows.

Source

Unified Modeling Language 2.5.1

An InitialNode shall not have any incoming ActivityEdges, which means the InitialNodes owned by an Activity will always be enabled when the Activity begins execution and a single control token is placed on each such InitialNode when Activity execution sta

Source

Unified Modeling Language 2.5.1

When an ExecutableNode completes an execution, the control token representing that execution is removed from the ExecutableNode and control tokens are offered on all outgoing ControlFlows of the ExecutableNode. That is, there is an implicit fork ...

Source

Unified Modeling Language 2.5.1

In some cases, multiple concurrent executions of an ExecutableNode may be ongoing at one time (see the semantics of isLocallyReentrant=true for Actions ... ). In this case, the ExecutableNode holds one control token for each concurrent execution.

Source

Unified Modeling Language 2.5.1

While the ExecutableNode is executing, it is considered to hold a single control [token] indicating it is execution [executing].

Source

Unified Modeling Language 2.5.1

The effect of object tokens accepted from ControlFlows is not specified (see isControlType for ObjectNodes ...), but the semantics above applies if the effect is to execute the ExecutableNode.

Source

Unified Modeling Language 2.5.1

Before an ExecutableNode begins executing, it accepts all tokens offered on incoming ControlFlows. If multiple tokens are being offered on a ControlFlow, they are all consumed.

Source

Unified Modeling Language 2.5.1

An ExecutableNode shall not execute until all incoming ControlFlows (if any) are offering tokens. That is, there is an implicit join on the incoming Control Flows. Specific kinds of ExecutableNodes may have additional prerequisites ...

Source

Unified Modeling Language 2.5.1

An ExecutableNode may also consume and produce data, but it must do so through related ObjectNodes (Actions use Pins for this purpose ...

Source

Unified Modeling Language 2.5.1

An ExecutableNode is an ActivityNode that carries out a substantive behavioral step of the Activity that contains it.

Source

Unified Modeling Language 2.5.1

All concrete kinds of ExecutableNodes are Actions ...

Source

Unified Modeling Language 2.5.1

Generally, the ControlNodes and ObjectNodes in an Activity are largely there to control the sequencing and to manage the flow of data between the ExecutableNodes of the Activity.

Source

Unified Modeling Language 2.5.1

An ExecutableNode is a kind of ActivityNode that may be executed as a step in the overall desired behavior of the containing Activity.

Source

Unified Modeling Language 2.5.1

uml101 - Activity Diagram - notation - REFERENCE CARD

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:04: UML Behavior: Activities quick start

Slide kind

UML Activity Diagram

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!

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

11:01: [STUB] Activity modelling extensions in SysML

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.

SysMLv1.7 Activity extensions: ControlOperator and ControlValueKind: ADVANCED REFERENCE CARD

SysML Activity extension stereotypes - REFERENCE CARD

01:04: UML Behavior: Activities 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.

uml101 - Activity Diagram - notation - REFERENCE CARD

Activity example: send and catch Signal

ActivityPartitions using “swimlane” notation

Starting an Action that has an InputPin

Starting an Action that has an InputPin with multiplicity

Starting an Action that has a ControlPin

Starting an Action that has a ValuePin - LIMITED SUPPORT

Parameter vs ActivityParameterNode vs Pin

ActivityParameterNode cases - REFERENCE CARD

UML2 Types of Pins - metaclasses

OR with DecisionNode and MergeNode

AND with ForkNode and JoinNode

ForkNode and JoinNode with optional ControlFlow guards - LIMITED SUPPORT

INCORRECT InitialNode no implicit fork

CORRECT InitialNode explicit fork

OPTION double InitialNode

ExecutableNode has implicit fork

Loop: running example using DecisionNode and MergeNode and an Integer property in a context

LoopNode: basic running example

LoopNode with loopVariable - ADVANCED REFERENCE

LoopNode: running loopVariable example

ExpansionRegion: running «iterative» example

StructuredActitivityNodes (structured actions) - ADVANCED REFERENCE ONLY

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 SysMLv1

Slide kind

UML Class Diagram

UML2 Activity Diagram - essential 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 SysMLv1

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

Allocation table in the MagicDraw/Cameo tool

Gallery

Tutorial

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

Section

15:01: The Allocate relationship and functional analysis

Slide kind

MagicDraw/Cameo: allocation matrix

MagicDraw/Cameo: relationship dependency matrix

matrix

Allocation matrix in the MagicDraw/Cameo tool

Gallery

Tutorial

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

Section

15:01: The Allocate relationship and functional analysis

Slide kind

MagicDraw/Cameo: allocation matrix

MagicDraw/Cameo: relationship dependency matrix

matrix

Allocation via swimlanes in definition allocation mode - DOs and DON'Ts

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

15:01: The Allocate relationship and functional analysis

Slide kind

hybrid diagram

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

Allocation via swimlanes in usage allocation mode - DOs and DON'Ts

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

15:01: The Allocate relationship and functional analysis

Slide kind

hybrid diagram

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

MagicDraw/Cameo: In SysML Activity Diagrams you can only set the allocation mode in to 'usage' or 'definition' for an entire AllocateActivityPartition group at once, not for individual AllocateActivityPartition columns or rows.

Allocation of a CallBehaviorActionAction to a PartProperty via an AllocateActivityPartition "swimlane"

Gallery

Tutorial

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

Section

15:01: The Allocate relationship and functional analysis

Slide kind

hybrid diagram

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

Functional allocation of a CallBehaviorAction (usage level) in an Activity Diagram to elements in a BDD

Gallery

Tutorial

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

Section

15:01: The Allocate relationship and functional analysis

Slide kind

hybrid diagram

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

Functional allocation of an Activity (definition level) in a BDD with callouts

Gallery

Tutorial

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

Section

15:01: The Allocate relationship and functional analysis

Slide kind

SysML Block Definition Diagram (BDD)

The name of a «testCase» Behavior may be verbose and may use natural language, but should always start with a Capital letter.

TestCase and Verify example - callout style

Gallery

Tutorial

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

Section

16:01: Requirements engineering in SysML

Slide kind

SysML Block Definition Diagram (BDD)

TestCase and Verify metamodel

Gallery

Tutorial

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

Section

16:01: Requirements engineering in SysML

Slide kind

UML diagram

UML Profile Diagram

AdjunctProperty for CallBehaviorAction and ObjectNode

Gallery

Tutorial

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

Section

11:02: Activity Decomposition for functional allocation

Slide kind

SysML Block Definition Diagram (BDD)

A very simple Activity decomposition in a BDD using AdjunctProperty

Gallery

Tutorial

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

Section

11:02: Activity Decomposition for functional allocation

Slide kind

SysML Block Definition Diagram (BDD)

11:02: Activity Decomposition for functional allocation

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.

A very simple Activity decomposition in a BDD using AdjunctProperty

AdjunctProperty for CallBehaviorAction and ObjectNode

Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty

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: 15 Allocations

Slide kind

hybrid diagram

SysML Activity Diagram

SysML Internal Block Diagram (IBD)

AVOID "mixed" functional (behavioral) allocation levels! DO NOT Allocate from Usage level (Action) to Definition level (Block) or from Definition level (Activity) to usage level (part Property) - even if formally permitted in SysML.

Figure 15-4: Behavior Allocation

 ARCHIVAL (2021): This content is now considered historical only!

This content has been marked as discussing an ADVANCED topic!

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: 15 Allocations

Slide kind

hybrid diagram

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

In an instance of Operating Car, which is one execution of it, instances of Brake Pressure and Modulation Frequency are linked to the execution instance when they are in the object nodes of the activity.

Source

OMG Systems Modeling Language (SysML) 1.6

Figure 11-14 shows a block definition diagram with composition associations between the activity in Figure 11-10 and the types the object nodes in that activity, with AdjunctProperty applied to the object node type end.

Source

OMG Systems Modeling Language (SysML) 1.6

The edges coming out of the decision node indicate the probability of each branch being taken.

Source

OMG Systems Modeling Language (SysML) 1.6

The decision node and guards determine if the brake pressure is greater than zero, and flow is directed to value specification actions that output an enabling or disabling control value from the activity.

Source

OMG Systems Modeling Language (SysML) 1.6

The activity diagram for the control operator Enable on Brake Pressure > 0 is shown in Figure 11-12.

Source

OMG Systems Modeling Language (SysML) 1.6

The result of Calculate Traction is filtered by a decision node for a threshold value and Calculate Modulation Frequency determines the output of the activity.

Source

OMG Systems Modeling Language (SysML) 1.6

Figure 11-10: Continuous system example 1 {EXPLICIT PINS}

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: 11 Activities

Slide kind

SysML Activity Diagram

The rake notations on the control operator and Monitor Traction indicate they are further defined by activities, as shown in Figure 11-11 and Figure 11-12. An alternative notation for this activity decomposition is shown in Figure 11-13.

Source

OMG Systems Modeling Language (SysML) 1.6

Figure 11-10: Continuous system example 1 {ELIDED PINS}

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: 11 Activities

Slide kind

SysML Activity Diagram

CallBehaviorActions in activity diagrams may optionally show the action name with the name of the invoked behavior using the colon notation shown in Figure 11-3.

Source

OMG Systems Modeling Language (SysML) 1.6

MagicDraw/Cameo: For the "rake" symbol to show on a CallBehaviorAction typed by a Behavior you must have the Show Rake Icon display option on AND the Behavior must have a Diagram (such as an Activity Diagram)

Activities in block definition diagrams can also appear with the same notation as CallBehaviorAction, except the rake notation can be omitted, if desired. Also see use of activities in block definition diagrams that include ObjectNodes.

Source

OMG Systems Modeling Language (SysML) 1.6

Properties with AdjunctProperty applied, where the principal of the AdjunctProperties are call actions, including call behavior actions, can be used as the part end of the associations. See 8.3.2.2 for constraints when AdjunctProperty is used ...

Source

OMG Systems Modeling Language (SysML) 1.6

This provides a means for representing activity decomposition in a way that is similar to classical functional decomposition hierarchies.

Source

OMG Systems Modeling Language (SysML) 1.6

Activities in block definition diagrams appear as regular blocks, except the «activity» keyword may be used to indicate the Block stereotype is applied to an activity, as shown in Figure 11-1. See example in 11.4, Usage Examples.

Source

OMG Systems Modeling Language (SysML) 1.6

Figure 11-1: Block definition diagram with activities as blocks

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: 11 Activities

Slide kind

SysML Block Definition Diagram (BDD)

Figure D.38 - Detailed Behavior Model for “Provide Power” {EXPLICIT PINS}

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

Note that the incoming and outgoing object flows for the ProvidePower activity have been decomposed. This was done to distinguish the flow of electrically generated mechanical power and gas generated mechanical power, and to provide further insight ...

Source

OMG Systems Modeling Language (SysML) 1.6

Figure D.38 ... It also uses AllocateActivityPartitions and an allocation callout to explicitly allocate activities and an object flow to parts in the PowerSubsystem block.

Source

OMG Systems Modeling Language (SysML) 1.6

Figure D.38 shows the ProvidePower activity, which includes Actions invoking the decomposed Activities and ObjectNodes from Figure D.37.

Source

OMG Systems Modeling Language (SysML) 1.6

MagicDraw/Cameo: If the underlying Parameter of an InputPin or OutputPin on a CallBehaviorAction or CallOperationAction is set to streaming, the indicator {stream} optionally displays on the Pin

Figure D.38 - Detailed Behavior Model for “Provide Power” {ELIDED PINS}

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

SysML-1.6: The spec version of Figure D.37 does not show the breakdown from the top-level Accelerate activity

Associations can be used between activities and classifiers (blocks or value types) that are the type of object nodes, variables, or parameters in the activity, as shown in Figure 11-5.

Source

OMG Systems Modeling Language (SysML) 1.6

When composition is used with activity blocks, the termination of execution of an activity on the whole end will terminate executions of activities on the part end of the links.

Source

OMG Systems Modeling Language (SysML) 1.6

Activities as blocks can have associations between each other, including composition associations. Composition means that destroying an instance at the whole end destroys instances at the part end.

Source

OMG Systems Modeling Language (SysML) 1.6

Figure D.37 defines a decomposition of the activities and objectFlows from the activity diagram in Figure D.36.

Source

OMG Systems Modeling Language (SysML) 1.6

Figure D.37 - Decomposition of “Accelerate” Function (Activity and Object Flow Breakdown)

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 Block Definition Diagram (BDD)

Figure D.36 - Behavior Model for “Accelerate” Function (Activity Diagram) {EXPLICIT PINS}

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

The stereotypes on the object nodes between actions in the figure apply to parameters of the behaviors or operations called by the actions (see the notation for object nodes described in 11.3.1.4, ObjectNode, Variables, and Parameters).

Source

OMG Systems Modeling Language (SysML) 1.6

It is the intent of the systems engineer in this example to allocate this behavior to parts of the PowerSubsystem. It is quickly found, however, that the behavior as depicted cannot be allocated, and must be further decomposed.

Source

OMG Systems Modeling Language (SysML) 1.6

Figure D.36 shows the top level behavior of an activity representing acceleration of the HSUV.

Source

OMG Systems Modeling Language (SysML) 1.6

MagicDraw/Cameo: ERROR: Incorrectly uses 2 ObjectFlow edges and a CentralBufferNode for "elided Pin notation" instead of an abstract ObjectNode _symbol_ and 2 arrow _symbols_ (notations that are supposed to represent together 2 Pins and 1 ObjectFlow edge)

Figure D.36 - Behavior Model for “Accelerate” Function (Activity Diagram) {ELIDED PINS}

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

Figure D.28 - Defining Requirements and VnV viewpoints (Package Diagram)

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

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

The selection and transformation Behaviors on outgoing ObjectFlows can be used to get information out of a DataStoreNode as if a query were being performed.

Source

Unified Modeling Language 2.5.1

Unlike a regular CentralBufferNode, a DataStoreNode contains objects uniquely.

Source

Unified Modeling Language 2.5.1

When a DataStoreNode accepts an object token, if that token contains an object with the same identity as an object contained in a token already held by the node, then the duplicate object token shall not be placed on the DataStoreNode.

Source

Unified Modeling Language 2.5.1

... a copy is made of the removed object token, with the same value, and this is immediately placed back onto the DataStoreNode. Thus, the values held by a DataStoreNode appear to persist for the duration of each execution of its containing activity, even

Source

Unified Modeling Language 2.5.1

When an offer for an object token held by a DataStoreNode is accepted by a downstream object node, the offered token is removed from the DataStoreNode, per the usual CentralBufferNode semantics. However, a copy is made of the removed object token ...

Source

Unified Modeling Language 2.5.1

15.4.3.4 Data Store Nodes - A DataStoreNode is a CentralBufferNode that holds its object tokens persistently while its activity is executing.

Source

Unified Modeling Language 2.5.1

Held object tokens are offered to outgoing flows according to the general ordering rules for ObjectNodes. When an offer for a token is accepted by a downstream object node, that token is removed from the CentralBufferNode and moved to the accepting ...

Source

Unified Modeling Language 2.5.1

15.4.3.3 Central Buffer Nodes - A CentralBufferNode acts as a buffer between incoming ObjectFlows and outgoing ObjectFlows. It accepts all object tokens offered to it on all incoming flows, which are then held by the node.

Source

Unified Modeling Language 2.5.1

An inout Parameter shall be associated with at most one input ActivityParameterNode and at most one output ActivityParameterNode.

Source

Unified Modeling Language 2.5.1

An in Parameter shall not be associated with an output ActivityParameterNode and an out or return Parameter shall not be associated with an input ActivityParameterNode (though either may be associated with an ActivityParameterNode that does not have ..

Source

Unified Modeling Language 2.5.1

An Activity shall have one ActivityParameterNode corresponding to each in, out, or return Parameter and two ActivityParameterNodes for each inout Parameter.

Source

Unified Modeling Language 2.5.1

(Note that whether an ActivityParameterNode is for input or output is not determined until at least one ActivityEdge is connected to it.)

Source

Unified Modeling Language 2.5.1

An ActivityParameterNode shall have either all incoming or all outgoing ActivityEdges. An ActivityParameterNode with outgoing edges is an input ActivityParameterNode, while an ActivityParameterNode with incoming edges is an output ActivityParameterNode.

Source

Unified Modeling Language 2.5.1

Each ActivityParameterNode is associated with one Parameter of the Activity that owns the node. The type of an ActivityParameterNode shall be the same as the type of its associated Parameter.

Source

Unified Modeling Language 2.5.1

Within an Activity, inputs to and outputs from an Activity are handled using ActivityParameterNodes.

Source

Unified Modeling Language 2.5.1

When the Activity is invoked, values may be passed into the Activity execution on input Parameters (i.e., those with direction in or inout) and values may be passed out .. on output Parameters (i.e., those with direction inout, out or return).

Source

Unified Modeling Language 2.5.1

15.4.3.2 Activity Parameter Nodes - As a kind of Behavior, an Activity may have Parameters

Source

Unified Modeling Language 2.5.1

If the upperBound evaluates to *, then there is no limit on the number of tokens the ObjectNode may hold.

Source

Unified Modeling Language 2.5.1

If the removal of one or more tokens brings the number of tokens held below the evaluated upperBound, then the ObjectNode may accept any pending offers up to the limit of the upperBound.

Source

Unified Modeling Language 2.5.1

If the number of tokens already held by the ObjectNode is greater than or equal to the evaluated upperBound, then the ObjectNode shall not accept any further tokens until some of the ones it is holding are removed.

Source

Unified Modeling Language 2.5.1

An ObjectNode may not contain more tokens than specified by its upperBound, if any. If an ObjectNode has an upperBound, then this ValueSpecification shall evaluate to an UnlimitedNatural value. The upperBound is evaluated each time a token is offered ...

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

Null tokens (object tokens without a value) satisfy the type of all object nodes.

Source

Unified Modeling Language 2.5.1

ObjectNodes are TypedElements ... If an ObjectNode has a type specified, then any object tokens held by the ObjectNode shall have values that conform to the type of the ObjectNode. If no type is specified, then the values may be of any type.

Source

Unified Modeling Language 2.5.1

An ObjectNode may contain multiple object tokens with the same value. Such tokens are not normally combined (but see the special semantics for DataStoreNodes ...).

Source

Unified Modeling Language 2.5.1

A token may traverse only one of the outgoing edges.

Source

Unified Modeling Language 2.5.1

Except in the case of an output ActivityParameterNode, tokens held by an ObjectNode may leave the node on outgoing ActivityEdges.

Source

Unified Modeling Language 2.5.1

Except in the case of an input ActivityParameterNode ... the tokens held by an ObjectNode arrive from incoming ActivityEdges.

Source

Unified Modeling Language 2.5.1

15.4.3.1 Object Nodes - An ObjectNode holds object tokens during the course of the execution of an Activity.

Source

Unified Modeling Language 2.5.1

Prefer 'UpperCamelCase' (a.k.a. PascalCase) names for Behaviors such as Activities intended for use in CallBehaviorActions, or at least use a 'Capital first letter'; avoid 'all lower case' (as it leads to confusion with lower case Action names)

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

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 append(n:int) operation and its Activity method Append

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

StartDialTone and StopDialTone

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 Connect Activity

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

To get synchronisation of multiple AcceptEventAction "loops" to work in Cameo Simulation Toolkit one sometimes needs an additional ForkNode

The Controller Activity (classifierBehavior of the Controller 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 Activity Diagram

If a matching Event occurrence for an AcceptEventAction is dispatched from the event pool, then the AcceptEventAction is enabled to continue. However, if the containing Behavior execution has more than one waiting Trigger that matches ...

Source

Unified Modeling Language 2.5.1

An AcceptEventAction is a wait point ... except only the AcceptEventAction waits, rather than the whole Activity (Activities can have other Actions executing while AcceptEventActions are waiting).

Source

Unified Modeling Language 2.5.1

CatchDialN: Activity with AcceptEventAction for a SignalEvent and a CallBehaviorAction

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

Activity: DialN(n:int)

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

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

If an Activity has more than one InitialNode, then invoking the Activity starts multiple concurrent control flows, one for each InitialNode. (Additional concurrent flows may begin at input ActivityParameterNodes and enabled ExecutableNodes ...

Source

Unified Modeling Language 2.5.1

An Activity may have more than one InitialNode.

Source

Unified Modeling Language 2.5.1

An InitialNode is a ControlNode that acts as a starting point for executing an Activity.

Source

Unified Modeling Language 2.5.1

Such an AcceptEventAction is terminated when its immediately containing Activity (or StructuredActivityNode) is terminated.

Source

Unified Modeling Language 2.5.1

That is, it does not terminate after accepting an Event occurrence and outputting any values (as described above), but continues to wait for another Event occurrence.

Source

Unified Modeling Language 2.5.1

However, in addition, an AcceptEventAction with no incoming edges remains enabled after it accepts an Event occurrence.

Source

Unified Modeling Language 2.5.1

If the AcceptEventAction has no incoming edges, by the usual rules, it is enabled when its immediately containing Activity (or StructuredActivityNode) begins execution.

Source

Unified Modeling Language 2.5.1

If an AcceptEventAction is used in an Activity, there are special rules for when it is enabled ..

Source

Unified Modeling Language 2.5.1

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.