Parameter

The sigsUp function with OptionsPattern modelled as a SysML Activity (and with "pseudo functional" representation)

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

[TECHNICAL SLIDE TRAIL] The Webel libraries for Wolfram Mathematica: With SysMLv1 models.

Section

SECTION: Modelling the Wolfram Language in SysMLv1 and related Webel coding conventions

SysMLv1: Cameo Simulation Toolkit: GOTCHA: Do not use Associations with Signal attributes, they will become null when fed as argument values for Parameters of 'effect' Behaviors of Transitions

SysMLv1.7/fUMLv1.4: Cameo Simulation Toolkit v2024x: Using an extending Enumeration literal as a parameter argument value runs but a WARN is issued.

SysMLv1: Cameo Simulation Toolkit: Cases for StateMachine Transitions with 'effect' Behaviors and/or States with 'entry' Behaviors triggered by a Signal with an attribute [with mini video]

Gallery

Tutorial

TRAIL: SysMLv1/UML: Cameo Simulation Toolkit® (Magic Model Analyst®): Some basics for beginners and some more advanced cases [with mini videos]

Section

Slide kind

SysML Activity Diagram

SysML Block Definition Diagram (BDD)

SysML StateMachine Diagram

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

TIP: UML/SysML: MagicDraw/Cameo: Activity Diagrams: ActivityParameterNodes: Displaying the underlying 'parameter::multiplicity' using Edit Compartments is extremely useful!

UML/SysML: MagicDraw/Cameo: Edit Compartments: ActivityParameterNode: Can't select the 'parameter::multiplicity'? Run the synchronisation between the Activity in the direction Synchronize Activity Parameter Nodes by Activity Parameter then try again!

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: POLICY: Handle flow sign changes via a single negative (not duplicated and "adjusted" algebra). This strategy may come at a very slight performance cost (for benefit of more robustness).

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.

Webel: SysML4Mathematica: TIP: Representing Mathematica functions as SysML ConstraintBlocks modelled in SysML Parametric Diagrams and as Activities in SysML Activity Diagrams is super for analysing the dependencies between functions and their arguments!

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

Webel: SysML4Mathematica: Convention: A Mathematica Blank '_' (which pattern-matches any Expression) is represented by a custom SysML ValueType '_'

ISSUE/GOTCHA: MagicDraw/Cameo v2022x: UML/SysML: If you "rename" an ActivityParameterNode symbol on the frame of an Activity Diagram it actually renames the underlying Parameter (only) NOT the name of the ActivityParameterNode element!

SysML/UML: MagicDraw/Cameo: The name of an ActivityParameterNode does not always stay in synch with its Parameter (and it is not always desirable that it does).

SysML/UML: MagicDraw/Cameo: Activity Diagrams: All Pins of CallBehaviorActions and CallOperationActions MUST be displayed (synchronised). All ActivityParameterNodes MUST be shown on the frame of an 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!

The stereotype applies to all parameters corresponding to the pins notated by the object node.

Source

OMG Systems Modeling Language (SysML) 1.6

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

OMG Systems Modeling Language (SysML) 1.6

«pa:term»: Dealing with synonyms, alternative names, and identifiers

Gallery

Tutorial

TRAIL: Theory and best practices for the Webel Parsing Analysis recipe for SysMLv1.6+

Section

Slide kind

SysML Block Definition Diagram (BDD)

REFERENCE CARD: Property cheat-sheet for Block

Gallery

Tutorial

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

Section

08:01: The building Blocks of SysML

Slide kind

SysML Block Definition Diagram (BDD)

1_lower_is_0 A parameter with the «optional» stereotypes applied shall have multiplicity.lower equal to zero, otherwise multiplicity.lower shall be greater than zero

Source

OMG Systems Modeling Language (SysML) 1.6

When the «optional» stereotype is applied to parameters, the lower multiplicity shall be equal to zero. This means the parameter is not required to have a value for the activity or any behavior to begin or end execution ...

Source

OMG Systems Modeling Language (SysML) 1.6

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

Parameter vs ActivityParameterNode vs Pin

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

Inherited Feature indicator

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

Generalization and VisibilityKind example

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

Class compartments

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

REFERENCE CARD: Types of Block Properties and Block compartments

Gallery

Tutorial

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

Section

08:01: The building Blocks of SysML

Slide kind

SysML Block Definition Diagram (BDD)

ExampleBlock in a Block Definition Diagram (BDD)

Gallery

Tutorial

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

Section

08:01: The building Blocks of SysML

Slide kind

SysML Block Definition Diagram (BDD)

Figure 13-1: Block definition diagram with state machines as blocks associated with submachines and types of parameters

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: 13 StateMachines

Slide kind

SysML Block Definition Diagram (BDD)

Properties with AdjunctProperty applied, where the principal of the AdjunctProperty is a parameter of the state machine, can be used as the end of the associations towards the parameter type.

Source

OMG Systems Modeling Language (SysML) 1.6

Interactions in block definition diagrams can also appear with the same notation as InteractionUses.

Source

OMG Systems Modeling Language (SysML) 1.6

Properties with AdjunctProperty applied, where the principal of the AdjunctProperty is a parameter of the interaction, can be used as the end of the associations towards the parameter type.

Source

OMG Systems Modeling Language (SysML) 1.6

Figure 11-8: Abstract Syntax for SysML Activity Extensions

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

UML Profile Diagram

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)

The associations may be composition if the intention is to delete instances of the classifier flowing the activity when the activity is terminated. See example in 11.4, Usage Examples.

Source

OMG Systems Modeling Language (SysML) 1.6

Like any association end or property these can be the subject of parametric constraints, design values, units, and quantity kinds.

Source

OMG Systems Modeling Language (SysML) 1.6

Properties with AdjunctProperty applied, where the principal of the AdjunctProperty is an object node, variable, or parameter, can be used as the end of the associations toward the object node, variable, or parameter type.

Source

OMG Systems Modeling Language (SysML) 1.6

This supports linking the execution of the activity with items that are flowing through the activity or assigned to variables or parameters, and happen to be contained by an object node or assigned to a variable or parameter at the time the link exists.

Source

OMG Systems Modeling Language (SysML) 1.6

Associations can be used between activities and classifiers (blocks or value types) that are the type of object nodes, variables, or parameters in the activity, as shown in Figure 11-5.

Source

OMG Systems Modeling Language (SysML) 1.6

The Webel trail versions of the Activity Diagrams D.36 and D.38 use the name 'transMode' for the output Parameter and corresponding ActivityParameterNode (consistent with the spec figure D.38) NOT 'transMode_imported' (as in spec figure D.36)

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

MagicDraw/Cameo 19SP3: if Continuous or Discrete are applied to the Parameter of an ActivityParameterNode the keywords «continuous» or «discrete» can be optionally displayed on the ActivityParameterNode symbol

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

SysML-1.6: Each «continuous» Parameter (of each corresponding ActivityParameterNode) in Figure D.36 and Figure D.38 should be set to be streaming, because the Continuous Stereotype has a Generalization to Rate

1_streaming When the «rate» stereotype is applied to a parameter, the parameter shall be streaming.

Source

OMG Systems Modeling Language (SysML) 1.6

Streaming is a characteristic of UML behavior parameters that supports the input and output of items while a behavior is executing, rather than only when the behavior starts and stops. The flow may be continuous or discrete ...

Source

OMG Systems Modeling Language (SysML) 1.6

Rate ... When the stereotype is applied to a parameter, the parameter shall be streaming, and the stereotype gives the number of objects or values that flow in or out of the parameter per time interval while the behavior or operation is executing.

Source

OMG Systems Modeling Language (SysML) 1.6

One or more result values may be posted to a streaming output Parameter any time after the invocation of a Behavior up to or at its completion. These result values are then available to affect the further course of the execution of the invoking Behavior..

Source

Unified Modeling Language 2.5.1

If an output Parameter is streaming, then a Behavior execution may provide result values for the Parameter during its course rather than just at completion.

Source

Unified Modeling Language 2.5.1

One or more argument values may be posted to a streaming input Parameter at or any time after the invocation of a Behavior and before its completion. These argument values are then available to affect the further course of the Behavior execution ...

Source

Unified Modeling Language 2.5.1

If an input Parameter is streaming, then argument values may be provided for the Parameter during the course of a Behavior execution rather than just at invocation.

Source

Unified Modeling Language 2.5.1

Parameters may also be marked as streaming (i.e., have the isStreaming property be true). Such Parameters allow values to be passed into and out of a Behavior execution any time during its course, rather than just on invocation and completion.

Source

Unified Modeling Language 2.5.1

Continuous ... It is independent from UML streaming, see clause 11.3.2.8. A streaming parameter may or may not apply to continuous flow, and a continuous flow may or may not apply to streaming parameters.

Source

OMG Systems Modeling Language (SysML) 1.6

Continuous rate is a special case of rate of flow (see Rate) where the increment of time between items approaches zero. It is intended to represent continuous flows that may correspond to water flowing through a pipe, a time continuous signal, or ...

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

The stereotypes on the object nodes between actions in the figure apply to parameters of the behaviors or operations called by the actions (see the notation for object nodes described in 11.3.1.4, ObjectNode, Variables, and Parameters).

Source

OMG Systems Modeling Language (SysML) 1.6

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

Note that the parentheses are not considered part of the output-argument list, so a reply-message-label without an output-argument-list may still optionally include an empty set of parentheses (“()”) after the message-name.

Source

Unified Modeling Language 2.5.1

If a reply-message-label does not include an output-argument-list and the Message has a signature, then this denotes that the Message has wildcard arguments corresponding to all out and inout ownedParameters of the signature Operation (if any).

Source

Unified Modeling Language 2.5.1

An output-argument always explicitly names the parameter to which it is to be matched. Any parameters that are not named are considered to have implicit wildcard arguments. (There is thus no need for an explicit wildcard notation for output-arguments.)

Source

Unified Modeling Language 2.5.1

If a reply Message does not have a signature, then the only argument that may be specified for it is a return argument as specified above. However, if the Message has a signature that is an Operation with out or inout ownedParameters, then ...

Source

Unified Modeling Language 2.5.1

If a reply Message does not have a signature, then the only argument that may be specified for it is a return argument as specified above.

Source

Unified Modeling Language 2.5.1

If the Message has a signature without a return parameter, then no assignment-target or value-specification may be given for the reply-message-label as a whole.

Source

Unified Modeling Language 2.5.1

If the Message has a signature that is an Operation with a return parameter, then this assignment-target and/or value-specification corresponds to the argument for that parameter (if no assignment-target is given, it is considered to be unknown).

Source

Unified Modeling Language 2.5.1

Note that the parentheses are not considered part of the input-argument list, so a request-message-label without an input-argument-list may still optionally include an empty set of parentheses (“()”) after the message-name.

Source

Unified Modeling Language 2.5.1

If a request-message-label does not include an input-argument-list and the Message has a signature, then this denotes that the Message has wildcard arguments corresponding to all in and inout ownedParameters of an Operation or attributes of a Signal ...

Source

Unified Modeling Language 2.5.1

Value types may be used to type properties, operation parameters, or potentially other elements within SysML.

Source

OMG Systems Modeling Language (SysML) 1.6

A decisionInput Behavior has no out parameters, no inout parameters, and one return parameter.

Source

Unified Modeling Language 2.5.1

incoming_control_one_input_parameter If the DecisionNode has a decisionInputFlow and an incoming ControlFlow, then any decisionInput Behavior has one in Parameter ...

Source

Unified Modeling Language 2.5.1

zero_input_parameters If the DecisionNode has no decisionInputFlow and an incoming ControlFlow, then any decisionInput Behavior has no in parameters.

Source

Unified Modeling Language 2.5.1

An inout Parameter shall be associated with at most one input ActivityParameterNode and at most one output ActivityParameterNode.

Source

Unified Modeling Language 2.5.1

An in Parameter shall not be associated with an output ActivityParameterNode and an out or return Parameter shall not be associated with an input ActivityParameterNode (though either may be associated with an ActivityParameterNode that does not have ..

Source

Unified Modeling Language 2.5.1

An Activity shall have one ActivityParameterNode corresponding to each in, out, or return Parameter and two ActivityParameterNodes for each inout Parameter.

Source

Unified Modeling Language 2.5.1

(Note that whether an ActivityParameterNode is for input or output is not determined until at least one ActivityEdge is connected to it.)

Source

Unified Modeling Language 2.5.1

An ActivityParameterNode shall have either all incoming or all outgoing ActivityEdges. An ActivityParameterNode with outgoing edges is an input ActivityParameterNode, while an ActivityParameterNode with incoming edges is an output ActivityParameterNode.

Source

Unified Modeling Language 2.5.1

Each ActivityParameterNode is associated with one Parameter of the Activity that owns the node. The type of an ActivityParameterNode shall be the same as the type of its associated Parameter.

Source

Unified Modeling Language 2.5.1

Within an Activity, inputs to and outputs from an Activity are handled using ActivityParameterNodes.

Source

Unified Modeling Language 2.5.1

When the Activity is invoked, values may be passed into the Activity execution on input Parameters (i.e., those with direction in or inout) and values may be passed out .. on output Parameters (i.e., those with direction inout, out or return).

Source

Unified Modeling Language 2.5.1

15.4.3.2 Activity Parameter Nodes - As a kind of Behavior, an Activity may have Parameters

Source

Unified Modeling Language 2.5.1

The append(n:int) operation and its Activity method Append

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

The number.append Activity as entry Behavior for the PartialDial State

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

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

Source

Unified Modeling Language 2.5.1

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

Unified Modeling Language 2.5.1

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

Source

Unified Modeling Language 2.5.1

Activity: DialN(n:int)

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

fUML-1.4 EXCLUDES Parameter::parameterSet

fUML-1.4 EXCLUDES Parameter::defaultValue

Subscribe to Parameter