OutputPin

Webel: SysML/UML: Dr Darren explains HOWTO use concise 'i'/'o' (input/output) Pin and Parameter naming conventions to promote a signal processing mindset in Activity Diagrams. And HOWTO get them compact.

TIP: SysMLv1: MagicDraw/Cameo: Activity Diagrams: Consider using the Pin display mode 'Name And Type Labels Inside' for 'Position of Labels'. Dr Darren swears by it!

TIP: UML/SysML: MagicDraw/Cameo: Activity Diagrams: Pins: You can display the 'multiplicity' of the underlying Parameter on Pins symbols using Edit Compartments. (The 'multiplicity' shows anyway if the :Type is shown.)

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.

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!

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

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

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

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

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

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

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

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

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

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

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

Figure 11-5: Block definition diagram with activities as blocks associated with types of object nodes, variables, and parameter

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

SysML Block Definition Diagram (BDD)

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

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

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

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

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

If it has isUnmarshall=true, then it must have result OutputPins corresponding to each of the attributes of the Signal of the SignalEvent (in order), and the attribute values of the Signal instance associated with an accepted SignalEvent occurrence ...

Source

Unified Modeling Language 2.5.1

If an accept signal action has isUnmarshall=false, then it must have a single result OutputPin on which the Signal instance associated with an accepted SignalEvent occurrence is placed.

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

An AcceptEventAction with a trigger for a SignalEvent is informally called an accept signal action.

Source

Unified Modeling Language 2.5.1

If the triggers of an AcceptEventAction are all for ChangeEvents and/or CallEvents, then the AcceptEventAction has no result OutputPins (unless the AcceptEventAction is an AcceptCallAction ...)

Source

Unified Modeling Language 2.5.1

Subscribe to OutputPin