InputPin

Webel: Mathematica: CONVENTION: The Stereotype keyword «functional» indicates a "pseudo functional" representation of functional in SysML. There are limits to representation of functional programming in SysML, but it can be informative and is worth doing.

ISSUE: Cameo Simulation Toolkit: v2024x: Does not show argument Pins corresponding to inherited attributes of Signal on SendSignalAction or an un-marshalling AcceptEventAction. No known UML2.5.1 or fUML-1.4 constraint; no obvious tool display option.

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!

SendSignalAction::target: The InputPin that provides the target object to which the Signal instance is sent

Source

Unified Modeling Language 2.5.1

The stereotype does not override UML token offering semantics, just indicates what happens to the token when it is accepted. When the stereotype is not applied, the semantics is as in UML, specifically, tokens arriving at object nodes do not replace ...

Source

OMG Systems Modeling Language (SysML) 1.6

For object nodes that are the target of continuous flows, «overwrite» and «nobuffer» have the same effect.

Source

OMG Systems Modeling Language (SysML) 1.6

The number of tokens replaced is equal to the weight of the incoming edge, which defaults to 1.

Source

OMG Systems Modeling Language (SysML) 1.6

A null token removes all the tokens already there.

Source

OMG Systems Modeling Language (SysML) 1.6

Tokens arriving at a full object node with the Overwrite stereotype applied take up their positions in the ordering as normal, if any. The arriving tokens do not take the positions of the removed tokens.

Source

OMG Systems Modeling Language (SysML) 1.6

For upper bounds greater than one, the token removed is the one that has been in the object node the longest. For FIFO ordering, this is the token that is next to be selected, for LIFO it is the token that would be last to be selected.

Source

OMG Systems Modeling Language (SysML) 1.6

This is typically used on an input pin with an upper bound of 1 to ensure that stale data is overridden at an input pin.

Source

OMG Systems Modeling Language (SysML) 1.6

NoBuffer::1_not_overwrite The «nobuffer» and «overwrite» stereotypes cannot be applied to the same element at the same time

Source

OMG Systems Modeling Language (SysML) 1.6

The stereotype does not override UML token offering semantics; it just indicates what happens to the token when it is accepted. When the stereotype is not applied, the semantics are as in UML, specifically, tokens arriving at an object node ...

Source

OMG Systems Modeling Language (SysML) 1.6

For object nodes that are the target of continuous flows, «nobuffer» and «overwrite» have the same effect.

Source

OMG Systems Modeling Language (SysML) 1.6

This is typically used with fast or continuously flowing data values, to prevent buffer overrun, or to model transient values, such as electrical signals.

Source

OMG Systems Modeling Language (SysML) 1.6

When the «nobuffer» stereotype is applied to object nodes, tokens arriving at the node are discarded if they are refused by outgoing edges, or refused by actions for object nodes that are input pins.

Source

OMG Systems Modeling Language (SysML) 1.6

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

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

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

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

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

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

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

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

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

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

HOWTO set a ValueSpecificationAction to use the * LiteralUnlimitedNatural to drive an 'insertAt' InputPin on an AddStructuralFeatureValueAction in Cameo Simulation Toolkit and Cameo Systems Modeler

Adding a value to an ordered StructuralFeature requires an insertion point for the new value given in the insertAt InputPin, which is required for ordered StructuralFeatures when isReplaceAll is false and omitted for unordered StructuralFeatures.

Source

Unified Modeling Language 2.5.1

If the StructuralFeature is an Association end, the semantics are the same as for a CreateLinkAction ..., where the participants in the link are the object being acted on and the new value.

Source

Unified Modeling Language 2.5.1

The value to be added is given on the value InputPin, which is required. This InputPin has the same type as the StructuralFeature and a multiplicity of 1..1 (that is, a single value is added).

Source

Unified Modeling Language 2.5.1

Subscribe to InputPin