Action

Webel: SysMLv1: MagicDraw/Cameo: CON: Using anonymous property and/or action names is not ideal for Element Compartment and Note callout displays when Usage level allocation is used. But allocation table and matrix views are better anyway.

Webel: Psy/MPsy: Psychrometrics for Mathematica: '$HC' in a function name indicates pure sensible heating or cooling (with no change in water vapour content). Such functions may also be used in the pure sensible portion of a 2-step treatment.

Webel: SysML4Mathematica: SysML Activities and SysML Activity Diagrams CAN represent some functional programming paradigms (sort of). You can type Parameters by encapsulations of functions and pass them to/from InputPins/OutputPins of Actions.

SysML: Cameo Systems Modeler: A ValueType that does not extend Real might not always simulate correctly when used to type a constraint parameter of a ConstraintBlock (in a SysML Parametric Diagram) or to type a parameter (in a SysML Activity Diagram)!

SysML/UML: MagicDraw/Cameo: GOTCHA: Connecting a typed OutputPin to an untyped (UNSPECIFIED) InputPin with an ObjectFlow changes the type of the InputPin

Webel: SysML4Mathematica: Convention: A '$E' in a function name indicates that all parameters (arguments and return) are Mathematica '_' expressions. However, when representing such functions as Activities they may end up getting strongly typed in tools!

TIP: Webel: SysML/UML: On the boundary of Action symbols in Activity Diagrams use any placement or "ordering" of Parameter symbols that works for the diagram. Ignore the Parameter ordering of Operation and Behavior signatures completely!

Webel: SysML4Mathematica: When modelling the main logic flow of Mathematica code with Activity Diagrams it isn't necessary to model every Mathematica construct. Placeholder Actions, OpaqueActions , and OpaqueBehaviors (as CallBehaviorActions) may be used.

MagicDraw SysML: [v2022xGolden,v2022xRefresh1]: ISSUE: Automatic assignment of the Type of the 'result' of a ReadStructuralFeatureAction not working with drag & drop.

Screencast: SysML/MBSE: An air conditioner refrigerant cycle in Cameo Simulation Toolkit

Keywords

Video style

This video only shows the Activities and StateMachines. For the underlying Block model please visit this accompanying slide trail:

TRAIL: SysML: Simple model of an air conditioner with a refrigerant cycle and StateMachine driven by Activities in MagicDraw/Cameo

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

SysML/SysPhS-1.1: Anonymous Property or Action names may not be an option if: You are exporting to Modelica or Simulink; You absolutely need names for generated query reports (such as generated Interface Control Documents).

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

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

Action::/output : OutputPin [0..*] ... The ordered set of OutputPins representing outputs from the Action.

Source

Unified Modeling Language 2.5.1

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

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

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

All concrete kinds of ExecutableNodes are Actions ...

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

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

UML2 Actions - 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

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.

MagicDraw/Cameo: You can allocate an Action to any NamedElement in the model via its specification box under the Allocations section by dragging and dropping an element (such as a part Property) from the model browser onto the Allocate To field.

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

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-6: Example of flow allocation from ObjectFlow to ItemFlow

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

SysML Activity Diagram

SysML Internal Block Diagram (IBD)

Figure 15-5: Example of flow allocation from ObjectFlow to Connector

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

SysML Activity Diagram

SysML Internal Block Diagram (IBD)

The allocation to Activity6 comes from a nested part, and uses the attributes of DirectedRelationshipPropertyPath to specify the path of properties to reach that part. The sourceContext of the allocation is Block4 and the sourcePropertyPath is (Part5).

Source

OMG Systems Modeling Language (SysML) 1.6

Note that the AllocateActivityPartition, if used in this manner, is unambiguously associated with behavior allocation.

Source

OMG Systems Modeling Language (SysML) 1.6

Specific behavior allocation of Actions to Parts are depicted in Figure 15-4.

Source

OMG Systems Modeling Language (SysML) 1.6

Figure 15-4: Behavior Allocation

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

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

Tokens are placed on control OutputPins according to the same semantics as tokens placed on ControlFlows coming out of an Actions.

Source

Unified Modeling Language 2.5.1

Tokens arriving at a control InputPin have the same semantics as control tokens arriving at the Action, except that control tokens can be buffered in control Pins.

Source

Unified Modeling Language 2.5.1

Control Pins are ignored in the constraints that Actions place on Pins (including matching to parameters for InvocationActions ...).

Source

Unified Modeling Language 2.5.1

Figure 11-3: CallBehaviorAction notation with action name

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

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

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

Webel: SysMLv1/UML: Prefer the Name Display Mode 'both' on CallBehaviorAction symbols (rather than 'Show Action Name', 'Show Behavior Name', or 'Show Both or Behavior Name')

MagicDraw/Cameo: ERROR: Incorrectly uses 2 ObjectFlow edges and a CentralBufferNode in place of "elided Pin notation" instead of an abstract ObjectNode symbol and 2 arrow symbols (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

Action::/input : InputPin [0..*] ... The ordered set of InputPins representing the inputs to the Action.

Source

Unified Modeling Language 2.5.1

A ValueSpecificationAction may not have any InputPins, because Action::/input:InputPin[0..*] is a derived union, and ValueSpecificationAction does not specify any InputPin subsets

Using an InstanceValue in a ValueSpecificationAction is similar to creating an instance using a CreateObjectAction, except that values may be given for the StructuralFeatures of the instance using slots on the InstanceSpecification of the InstanceValue.

Source

Unified Modeling Language 2.5.1

a LiteralSpecification may be used in a ValueSpecificationAction to produce a constant value.

Source

Unified Modeling Language 2.5.1

16.4.3.5 Value Specification Actions - A ValueSpecificationAction is an Action that evaluates a ValueSpecification and places the resulting value on its result OutputPin.

Source

Unified Modeling Language 2.5.1

Prefer anonymous Actions, or if they must be named, prefer code-like 'lowerCamelCase' or completely 'lower case' (if you do absolutely insist on having spaces in action names, but please no other punctuation).

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

If the input object is an instantiated Behavior that is not already executing, then it begins executing. If the input object has a classifierBehavior that is not already executing, then it is instantiated and started. In either case ...

Source

Unified Modeling Language 2.5.1

A StartObjectBehaviorAction is a CallAction that starts the execution either of a directly instantiated Behavior or of the classifierBehavior of an object. The object to be started is taken from the object InputPin.

Source

Unified Modeling Language 2.5.1

A CallOperationAction is a CallAction that transmits an Operation call request message to the target object, where it may cause the invocation of an associated Behavior. The target object is taken from the target InputPin of the CallOperationAction.

Source

Unified Modeling Language 2.5.1

A CallBehaviorAction is a CallAction that invokes a Behavior directly, rather than calling a BehavioralFeature that, in turn, results in the invocation of a Behavior.

Source

Unified Modeling Language 2.5.1

If the Trigger on the AcceptEventAction is chosen, then it completes and produces output on any result OutputPins.

Source

Unified Modeling Language 2.5.1

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

The context object for an AcceptEventAction is the context object of the Behavior execution within which the AcceptEventAction is executing (which may be the Behavior execution itself ...)

Source

Unified Modeling Language 2.5.1

AcceptEventAction is an Action with Triggers for one or more Events. When an AcceptEventAction is executed, it waits for an Event occurrence to be dispatched from the event pool of the context object for its execution that matches one of its Triggers.

Source

Unified Modeling Language 2.5.1

If isReplaceAll is true ... The StructuralFeature always has a single value when the Action completes, even if the lower multiplicity of the StructuralFeature is greater than 1.

Source

Unified Modeling Language 2.5.1

Subscribe to Action