UML2/SysMLv1: A control Pin (a Pin with isControl = True) for a CallBehaviorAction does not have a corresponding Parameter

In the example, the CallBehaviorAction ':ControlMeWithPins' has two Pins, but because the one 'iC' is a control Pin, the correctly synced Activity 'ControlMeWithPins' only has one Parameter, corresponding to the 'iData:Integer' InputPin.

In Magic Cyber-Systems Engineer^® (Cameo Systems Modeler^®), if you happen to have used an existing Activity that has Parameters for the CallBehaviorAction before you set isControl on the Pin, it will correctly remove any "corresponding" Parameter when you sync the CallBehaviorAction and the Activity.

There's a very detailed summary of nearly everything you might want to know (and some things your might not want to know) about control in UML2 and SysMLv1, and the SysMLv1 extensions ControlOperator and ControlValueKind in this slide:

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

Relates to

Related notes

Related notes (backlinks)

Related snippets (extracts)

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

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

[fUML-1.4] If isControlType=true for an ObjectNode, ControlFlows may be incoming to and outgoing from the ObjectNode, objects tokens can come into or go out of the ObjectNode along ControlFlows, and these tokens can flow along ControlFlows reached downstream ...

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

Visit also

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

Figure 11-9: Control values