Operation

SysMLv1: Cameo Simulation Toolkit: Sequence Diagrams: HOWTO Send an asynchronous Signal message and HOWTO handle a Reply message value from a synchronous Operation call message [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 Sequence Diagram

Webel Radio Net: Focus BDD for the SessionSpec exchange item (and the NetManager)

Gallery

Tutorial

[TRAIL] SysMLv1: The Webel Radio Net port-based messaging example model in Cameo Systems Modeler and Cameo Simulation Toolkit

Section

Webel Radio Net: Model overview, exchange items, and Ports

Slide kind

SysML Block Definition Diagram (BDD)

Mathematica: Webel ADT pseudo classes: NAMING CONVENTION: An UpValue that can be invoked on an ADT accepting its unique 'signature' pattern as (at least) 1st argument is called an 'ADT-Method'. They are NOT methods in the general object-oriented sense!

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!

Webel: WISHLIST: MagicDraw/Cameo: UML/SysML: Ability to freeze the Feature lines shown on symbols under Edit Compartments so that the diagram does not "break" when new Features are added elsewhere (reduce graphical coupling)

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

Containment tree view of members of a «snippet» ElementGroup in MagicDraw/Cameo

Gallery

Tutorial

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

Section

Slide kind

Focus BDD for block EnglishPangram

Gallery

Tutorial

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

Section

Slide kind

SysML Block Definition Diagram (BDD)

Focus PAD for the Snippet ''an English-language pangram — a sentence that contains all of the letters of the English alphabet'

Gallery

Tutorial

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

Section

Slide kind

SysML Block Definition Diagram (BDD)

Focus BDD for block FoxDogPangramContext

Gallery

Tutorial

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

Section

Slide kind

SysML Block Definition Diagram (BDD)

Focus PAD for the Snippet 'The quick brown fox jumps over the lazy dog'

Gallery

Tutorial

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

Section

Slide kind

SysML Block Definition Diagram (BDD)

Package Diagram overview of a simple domestic air conditioner with an inverter

Gallery

Tutorial

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

Section

Slide kind

SysML Package Diagram

23: Mini StateMachine for DigitalTwin and DoAttach effect Activity

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

TRAIL: A SysML Pattern for Digital Twinning

Section

Slide kind

SysML Activity Diagram

SysML StateMachine Diagram

22: Mini StateMachines for @Entity, PotentialPhysicalAsset, ActualPhysicalAsset

This content has been marked as discussing an ADVANCED topic!

Gallery

Tutorial

TRAIL: A SysML Pattern for Digital Twinning

Section

Slide kind

SysML StateMachine Diagram

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 SysMLv1

Slide kind

SysML Block Definition Diagram (BDD)

A SignalEvent represents the receipt of an asynchronous Signal instance.

Source

Unified Modeling Language 2.5.1

A CallEvent models the receipt by an object of a message invoking a call of an Operation.

Source

Unified Modeling Language 2.5.1

A MessageEvent specifies the receipt by an object of either an Operation call or a Signal instance.

Source

Unified Modeling Language 2.5.1

Behavior StateMachines can be used to specify any of the following

Gallery

Tutorial

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

Section

01:03: UML Behavior: StateMachines quick start

Slide kind

UML Class 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 SysMLv1

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 SysMLv1

Slide kind

UML Class Diagram

The operations compartment of a Class contains notation for its ownedOperations ...

Source

Unified Modeling Language 2.5.1

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 SysMLv1

Slide kind

UML Class Diagram

Blocks may also specify operations or other features that describe the behavior of a system

Source

OMG Systems Modeling Language (SysML) 1.6

It captures the definition of blocks in terms of properties and operations, and relationships such as a system hierarchy or a system classification tree

Source

OMG Systems Modeling Language (SysML) 1.6

Each block defines a collection of features to describe a system or other element of interest. These may include both structural and behavioral features, such as properties and operations, to represent the state of the system and behavior ...

Source

OMG Systems Modeling Language (SysML) 1.6

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 SysMLv1

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 SysMLv1

Slide kind

SysML Block Definition Diagram (BDD)

Viewpoint::2_create_view_operation The property ownedOperation shall include at least one operation named "View" with the UML Create stereotype applied.

Source

OMG Systems Modeling Language (SysML) 1.6

Viewpoint::1_method_derived_from_create_operations The derived values of the method attribute shall be the names of the methods of the operations stereotyped by the UML Create stereotype on the classifier stereotyped by Viewpoint.

Source

OMG Systems Modeling Language (SysML) 1.6

Viewpoint::/method : Behavior [0..*] The behavior is derived from the method of the operation with the Create stereotype. (derived)

Source

OMG Systems Modeling Language (SysML) 1.6

SysMLv1.x: An ElementGroup used for basic Parsing Analysis model element elicitation: Example 2

Gallery

Tutorial

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

Section

18:01: Logical grouping with the ElementGroup extension of Comment in SysMLv1.x

Slide kind

MagicDraw/Cameo: table

SysML Block Definition Diagram (BDD)

«interfaceRequirement»: satisfied by a port, conector, item flow, and/or constraint property.

Source

OMG Systems Modeling Language (SysML) 1.6

«functionalRequirement»: satisfied by an operation or behavior

Source

OMG Systems Modeling Language (SysML) 1.6

TestCase and Verify example - callout style

Gallery

Tutorial

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

Section

16:01: Requirements engineering in SysML

Slide kind

SysML Block Definition Diagram (BDD)

A Class has four mandatory compartments: attributes, operations, receptions ... and internal structure ... A Class may also have optional compartments as described for Classifiers in general

Source

Unified Modeling Language 2.5.1

For example, a block might provide particular services to other blocks as operations, or have a particular geometry accessible to other block, or it might require services and geometries of other blocks.

Source

OMG Systems Modeling Language (SysML) 1.6

Required and provided features are operations, receptions, and non-flow properties that a block supports for other blocks to use, or requires other blocks to support for its own use, or both.

Source

OMG Systems Modeling Language (SysML) 1.6

Provided behavioral features are invoked with the owning block as target, while required behavioral features are invoked with an external block as target (required).

Source

OMG Systems Modeling Language (SysML) 1.6

Using non-flow properties means to read or write them, and using behavioral features means to invoke them.

Source

OMG Systems Modeling Language (SysML) 1.6

MagicDraw/Cameo: By implementation the name of some Stereotype attributes and operations is UpperCase instead of lowerCase like in the UML and SysML specs

Figure 16-1: Abstract Syntax for Requirements Stereotypes

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: 16 Requirements

Slide kind

UML Profile Diagram

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

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

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

In addition, behavior allocation may also include the allocation of Behaviors to BehavioralFeatures of Blocks (e.g., Operations).

Source

OMG Systems Modeling Language (SysML) 1.6

It is expected that an «allocate» relationship between model elements is a precursor to a more concrete relationship between the elements, their properties, operations, attributes, or sub-classes.

Source

OMG Systems Modeling Language (SysML) 1.6

For example, the ICE block specifies the provided operations setMixture and setThrottle, the provided properties RPM, temperature, and isKnocking, and required property isControlOn, as shown in Figure D.20. This block types the ctrl port of ...

Source

OMG Systems Modeling Language (SysML) 1.6

MagicDraw/Cameo 19SP3: Does not yet handle Feature-wise validation of provided/required DirectedFeature contracts (it only handles them at the level of entire Block types). Webel asserts the spec is inconsistent w.r.t. ProxyPort connection compatibility.

SysMLv1.6 Provided/required DirectedFeature contracts for ProxyPorts SHOULD be satisfiable Feature-wise (including as subsets of Features) not necessarily just at the level of entire Blocks (types)! [See also the SysMLv1.7 spec changes.]

Figure D.10 - White Box Interaction for “StartVehicle”

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

UML Sequence Diagram

If the reply Message has a signature, then wildcard arguments are provided for all return, out and inout ownedParameters of the signature Operation.

Source

Unified Modeling Language 2.5.1

If the identity of a reply Message is obvious (e.g., when its sendEvent is the only reply within the extent of an ExecutionOccurence where there is only one receipt of an Operation call message), the label may be omitted to simplify the diagram.

Source

Unified Modeling Language 2.5.1

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

If the Message has a signature, this will be the name of the Operation referenced by the signature (which should be the Operation for whose call this is a reply). Otherwise the name is unconstrained.

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

Message::signature : NamedElement [0..1] ... The signature of the Message is the specification of its content. It refers either an Operation or a Signal.

Source

Unified Modeling Language 2.5.1

A SysML ValueType may define its own properties and/or operations, just as for a UML DataType.

Source

OMG Systems Modeling Language (SysML) 1.6

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

OMG Systems Modeling Language (SysML) 1.6

The control value inputs do not enable or disable the control operator execution based on their value, they only enable based on their presence as data.

Source

OMG Systems Modeling Language (SysML) 1.6

When the «controlOperator» stereotype is not applied, the behavior may not have a parameter typed by ControlValue.

Source

OMG Systems Modeling Language (SysML) 1.6

When the «controlOperator» stereotype is applied to behaviors, the behavior takes control values as inputs or provides them as outputs, that is, it treats control as data

Source

OMG Systems Modeling Language (SysML) 1.6

A control operator is a behavior that is intended to represent an arbitrarily complex logical operator that can be used to enable and disable other actions. ... The «controlOperator» stereotype also applies to operations with the same semantics.

Source

OMG Systems Modeling Language (SysML) 1.6

Screencast: Tutorial: UML/SysML: StateMachines vs Activities: Operation-driven Transition case study - UML-2.5.1 'Figure 14.7 Composite State with two States' in Cameo Simulation Toolkit

Keywords

Video style

This video accompanies this detailed tutorial trail: HOWTO simulate UML-2.5.1 'Figure 14.7 Composite State with two States' in Cameo Simulation Toolkit - Operation-driven Transition case study.

This full length tutorial is a case study of the telephone dialer StateMachine shown in 'Figure 14.7 Composite State with two States' of the UML-2.5.1 specification.

Read more about Screencast: Tutorial: UML/SysML: StateMachines vs Activities: Operation-driven Transition case study - UML-2.5.1 'Figure 14.7 Composite State with two States' in Cameo Simulation Toolkit

The number.print Activity as exit 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 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

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

A CallAction is an InvocationAction that calls a Behavior or an Operation. There are three kinds of CallActions

Source

Unified Modeling Language 2.5.1

Figure 14.7 Composite State with two States

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

<assignment-specification> is optional and may be omitted even if the Operation has Parameters. No standard mapping is defined from an assignment specification to the UML abstract syntax. A conforming tool is not required to support this notation. ...

Source

Unified Modeling Language 2.5.1

<assigned-name> is an implicit assignment of the argument value for the corresponding Parameter of the Operation to a Property or Variable of the context object for the triggered Behavior.

Source

Unified Modeling Language 2.5.1

A CallEvent is denoted by the name of the triggering Operation, optionally followed by an assignment specification: <call-event> ::= <name> [‘(‘ [<assignment-specification>] ‘)’] <assignment-specification> ::= <assigned-name> [‘,’ <assigned-name>]*

Source

Unified Modeling Language 2.5.1

StateMachine diagram for comparing action language access to an operation for a guard

Gallery

Tutorial

HOWTO invoke an operation as a Transition guard in Cameo Simulation Toolkit

Section

Slide kind

UML StateMachine Diagram

Class diagram for comparing action language access to an operation for a guard

Gallery

Tutorial

HOWTO invoke an operation as a Transition guard in Cameo Simulation Toolkit

Section

Slide kind

UML Class Diagram

fUML-1.4 EXCLUDES Operation::datatype

fUML-1.4 EXCLUDES Operation::interface

fUML-1.4 EXCLUDES Operation::precondition, Operation::postcondition and Operation::bodyCondition

fUML-1.4 EXCLUDES Operation::templateParameter

fUML-1.4 EXCLUDES Operation::raisedException

NOTE. Operation referenced in the CallEvent of an AcceptCallAction should not have an associated method Behavior. Otherwise, a call to the Operation will have the immediate effect of executing the method and will not be placed into the event pool ...

Source

Unified Modeling Language 2.5.1

Subscribe to Operation

Site looks mangled? Get help here

We are Australia's Systems Modeling Language (SysML^®) and Model-Based Systems Engineering (MBSE) specialists!

Catch our SysML/MBSE course Early Bird Deal 30% off all courses fully booked by 31st May 2025!

SysMLv1 slide set PDFs now available for purchase!

Home of the Webel Parsing Analysis recipe for Model-Based Systems Engineering with SysML^®

Visit our Client showcase