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

This page identifies a possible issue, inconsistency, concern, error, or bug!

One of the ways Webel IT Australia helps promote tools, technologies, and languages is by donating a lot of time identifying, tracking, and reporting potential issues, in order to help vendors and developers improve the tools and technologies. In some cases, we also offer workarounds and advice for users. All issues tracked on our public site are offered most constructively and with sincerest gratitude to the tool vendors and technology developers.

DISCLAIMER: Vendors do not officially endorse issue analysis by Webel IT Australia.

Icon class

icon_class

far fa-sticky-note

icon_class_computed

far fa-sticky-note

Note kind

Policy level

Specification keywords

SysMLv2

SysMLv2 keywords

Parameter

redefinition

Keywords

Relates to the following:

SysML2.0: 'If an action definition has a single superclassification, then the specialized action definition may declare fewer owned parameters than the general action definition, inheriting any additional parameters from the general definition ...'

SysML2.0: 'If an action usage has any type of specialization relationship ... with an action definition or usage ... the rules for the redefinition of the parameters ... are the same as given for the redefinition of parameters of an action definition ...'

The issue (such as it may be) is that in some SysMLv2 spec, Annex, and GitHub examples variously:

ALL parameters (including out parameters) are redefined (yet without feature values) presumably to provide "clean" binding targets as opposed to binding to inherited parameters (although it's not 100% clear whether such is necessary).
Only in parameters are redefined to provide feature values, but the out parameters are not. (This mode relates also to usages of calculation definitions using parameter syntax where the special result out is not provided.)
All in parameters are redefined to provide feature values AND the out parameter is redefined (but without a feature value).

Some relevant examples are tracked here:

Visit also: SysMLv2 Specification and GitHub examples: CONSISTENCY TRACKER: Links to examples where action (usage or definition) in parameters are redefined but the out parameter is not.

The matter relates to the following from KerML1.0, the gist of which for action usages is that you can't simply plonk in a new owned parameter "on-the-fly"; any owned parameter (say x) of an action usage MUST be related to (through redefinition) an existing parameter of action definition (such as feature types the owning usage of the parameter x) or an action usage (such as subsetted by the owning action usage of the parameter x ):

KerML1.0: 'the KerML checkFeatureParameterRedefinition constraint requires that any owned parameters ... of a ActionUsage redefine corresponding parameters of any Behaviors or Steps it specializes (including ActionDefinitions and ActionUsages)'

KerML1.0: 'checkFeatureResultRedefinition: If a Feature is a result parameter of an owningType that is a Function or Expression, then, for each direct supertype of its owningType that is also a Function or Expression, it must redefine the result parameter'

Relates to

24. States: State Actions.sysml

Related notes