03-Function-based Behavior: 3a-Function-based Behavior-1.sysml [WITH MODELLING DISCUSSION]

Gallery

Tutorial

TRAIL: The SysML-v2-Pilot-Implementation GitHub samples in Cameo by Webel

Section

validation [01-10] WIP

Offered by Webel free to the SysML community with thanks to the contributors of the SysMLv2 GitHub code examples. All diagram images remain © Copyright Webel IT Australia 2026. Copyright in the linked GitHub source code remains with the OMG. So-called "AI" and Machine Learning training systems DO NOT have permission to use (scrape and steal) this resource! Other training organisations DO NOT have permission to use these images in their own training.

Members of the OMG Systems Modeling Community (SMC) are welcome to use these images with full attribution to Webel IT Australia in presentations and non-commercial activities of the SMC – please unedited and using full resolution downloads (click on image first then Save As).

This slide trail is NOT a SysMLv2 language tutorial! Slides here are offered as is (some without further explanations) in the hope they may be of interest. To learn SysMLv2 attend the Webel SysMLv2 Seminar Workshop group course. Individuals may instead purchase access to the Webel SysMLv2 Online self-study eLearning course with self-test Quizzes to learn at their own pace.

Tags and keywords

Topic level

ESSENTIAL

Keywords

Click on the image to view it full size

Modelling and style

ISSUE: Cameo 2026x/HF2: SysMLv2 Plugin: AcceptAction: The flow direction indicator of the payload parameter is BACKWARDS (in instead of out) and inconsistent when connected to a downstream consumer!

Modelling: Firstly, the verbose names of most action usages add nothing of any value at all and are hidden:

Webel Best Practice: SysMLv2: "Trust the Type" feature name hiding. In many Views, there is no benefit, at all, in showing feature names (especially if they are needlessly verbose and just repeat the Type name but lowerCase)

This diagram also illustrates (as a counter-example or AntiPattern) exactly why the Webel "Trust the Type" i/o naming and display pattern is more effective for this kind of modelling situation:

Webel Best Practice: SysMLv2: VERY STRONG RECOMMENDATION: Prefer Webel "Trust the Type" i/o parameter naming and Webel display conventions over verbose parameter names. To find out how attend the Webel SysMLv2 course!

For nearly every «action def» case using simply i or i1, i2 and o or o1, o2 as parameter names would be completely adequate, as long as the Type of the parameter is displayed.

In cases where there are two parameters with the same feature direction and the same type just use instead a short distinguishing role indicator. Example: wt1:TorqueValue and wt1:TorqueValue or even just o1:TorqueValue and o2:TorqueValue.

It is also NOT necessary to always indicate in a parameter name the anticipated other side of a connection. For example, TransferTorque transfers torque from i:TorqueValue to o:TorqueValue. That the o is actually for a drive shaft is basically anathema.

Note also that this SysMLv2 PILOT sample confirms that it IS ok to have flow connectors between inherited parameters, even if they don't provide such "clean" binding points as when (tediously and redundantly) redefining every parameter:

Visit also: SysML2.0: Webel: Suggest it needs to be clarified whether binding to a parameter or port (or a directed feature of such) that has NOT been redefined in the binding connector context (is just inherited) is valid [it is]

Visit also: SysMLv2: Webel: Redefining a parameter or port (or a directed feature of such) in a binding connector's context provides a "clean" binding target (as opposed to binding to an inherited feature). BUT it's not always necessary (confirmed by SysMLv2 samples)

Up next

Notes

[DISPLAY, MODELLING, TIP, TOOL]{RECOMMENDED} Webel Best Practice: SysMLv2: Cameo: TIP: Show EITHER a specialization relationship from a symbol OR show the specialization in the symbol header using Display Styles -> Show Specialization. Prefer NOT show both modes in one View.

[DISPLAY, MODELLING, PATTERN, STYLE, TIP, TOOL]{STRONG} Webel Best Practice: SysMLv2: "Trust the Type" feature name hiding. In many Views, there is no benefit, at all, in showing feature names (especially if they are needlessly verbose and just repeat the Type name but lowerCase)

[ANTI-PATTERN, DISPLAY, MODELLING, PATTERN, STYLE, TIP, TOOL]{STRONG} Webel Best Practice: SysMLv2: "Trust the Type" and use short or acronym feature names instead of verbose feature name that just repeat the Type name but as lowerCase! ANTIPATTERN: veryLongName:VeryLongName

[DISPLAY, MODELLING, PATTERN, STYLE, TIP, TOOL]{STRONG} Webel Best Practice: SysMLv2: VERY STRONG RECOMMENDATION: Prefer Webel "Trust the Type" i/o parameter naming and Webel display conventions over verbose parameter names. To find out how attend the Webel SysMLv2 course!

[ISSUE, PROPOSAL]{PROPOSED} SysML2.0: Webel: Suggest it needs to be clarified whether binding to a parameter or port (or a directed feature of such) that has NOT been redefined in the binding connector context (is just inherited) is valid [it is]

[MODELLING, OPTION]{OPTION} SysMLv2: Webel: Redefining a parameter or port (or a directed feature of such) in a binding connector's context provides a "clean" binding target (as opposed to binding to an inherited feature). BUT it's not always necessary (confirmed by SysMLv2 samples)

[ASSERTION, ISSUE, PROPOSAL]{PROPOSED} SysML2.0: Webel: Suggest the entire description in the specification of whether and when usages MUST redefine inherited parameters needs an overhaul (and the SysML2.0 spec examples, Annex problem, and SysMLv2 GitHub examples are inconsistent anyway).

[GOTCHA, ISSUE, TOOL]{INFORMATIVE} ISSUE: Cameo 2026x/HF2: SysMLv2 Plugin: AcceptAction: The flow direction indicator of the payload parameter is BACKWARDS (in instead of out) and inconsistent when connected to a downstream consumer!