Pin | Webel IT Australia

Stereotypes applying to parameters can appear on object nodes in activity diagrams, as shown in Figure 11-7, when the object node notation is used as a shorthand for pins.

Source

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

Webel: SysMLv2: PROPOSAL: New Causality Graph Diagram for coordinating MetaEvents across an entire model

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:

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

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

Slide kind

UML Profile Diagram

ActivityParameterNode cases - REFERENCE CARD

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

Section

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

Slide kind

UML Activity Diagram

Parameter vs ActivityParameterNode vs Pin

Gallery

Tutorial

Section

Slide kind

UML Activity Diagram

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

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

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

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

Source

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

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

Source

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

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

Source

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

Source

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

Source

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

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

Source

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

Source

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

uml101 - Activity Diagram - notation - REFERENCE CARD

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

Section

Slide kind

UML Activity Diagram

Webel: If you must name your Ports or Pins, name them simply 'i', 'o', or 'io' (or 'oi') to indicate direction UNLESS you have to indicate a special role like 'iRole', 'oAuxiliary'. DO NOT use Port or Pin names like 'input', 'output', etc.

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

Source

A control Pin (with isControl=true) must have a control type (isControlType=true), so that they may be used with ControlFlows.

Source

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

MagicDraw/Cameo 19SP3: If Continuous or Discrete are applied to the underlying Parameter of an InputPin or an OutputPin the keywords «continuous» or «discrete» can't be displayed

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

Gallery

Tutorial

Section

Slide kind

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

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

MagicDraw/Cameo 19SP3: Continuous and Discrete have metaclass [ActivityEdge, ObjectNode, Parameter] not just [ActivityEdge, Parameter] (via Rate), so may be applied directly to Pin and ActivityParameterNode

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

Gallery

Tutorial

Section

Slide kind

These two extensions are useful for ensuring that the most recent information is available to actions by indicating when old values should not be kept in object nodes, and for preventing fast or continuously flowing values from collecting ...

Source

SysML also extends object nodes with the option to discard values if they do not immediately flow downstream (see NoBuffer in Figure 11-8).

Source

Extension of object nodes, including pins, with the option for newly arriving values to replace values that are already in the object nodes (see Overwrite in Figure 11-8).

Source

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

Webel recommends when using MagicDraw/Cameo: AVOID the "elided Pin" abstract ObjectNode notation on Activity Diagrams, use explicit Pins!

MagicDraw/Cameo: DO NOT use the ObjectNode menu item on Activity Diagrams ever!

[BUG: FIXED]: MagicDraw/Cameo SP193: Offers the display option to show the name and type label inside a Pin symbol, but it does not seem to work. [FIXED since 2022xRefresh2]

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

Gallery

Tutorial

Section

Slide kind

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

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

Section

Slide kind

isControl : Boolean [1..1] = false Indicates whether the Pin provides data to the Action or just controls how the Action executes.

Source

Pins for control parameters are regular pins, not UML control pins. This is so the control value can be passed into or out of the action and the invoked behavior, rather than control the starting of the action, or indicating the ending of it.

Source

The type, ordering, and multiplicity of the argument and result pins of a CallAction shall be the same as the corresponding Parameters.

Source

The argument Pins of a CallAction are matched, in order, to the sublist of input Parameters, while the result Pins are matched, in order, to the sublist of output Parameters.

Source

Behaviors and Operations have totally ordered lists of owned Parameters, and these Parameters are matched to Pins on a CallAction using that ordering.

Source