SysML2.0: Inconsistent use of the term 'composite' used to describe BOTH elements that own usages of the corresponding kind AND for usages with isComposite=true (as opposed to referential usages with isComposite=true). Suggest use instead 'composed'.

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

ISSUE

Policy level

EDITORIAL

Specification keywords

SysMLv2

SysMLv2 keywords

isComposite

composite view

requirement

The issue is highlighted by:

SysML2.0: 'A composite requirement usage nested in a requirement definition or usage is a subrequirement of the containing requirement definition or usage.'

SysML2.0: 'For the overall requirement to then be satisfied, all such composite or referenced requirements must be satisfied.'

If the owned requirement usage is a 'composite requirement' then what is the owning requirement to be called? In some other places in the spec 'composite' is used to refer to an element than owns other 'nested' element usages of the corresponding kind. Compare with composite view:

SysML2.0: 'View usages can be nested and ordered within a composite view to generate composite view artifacts.'

The inconsistency arises because of the isComposite Boolean.

Owned usages with isComposite=true are described multiple times in the spec as 'composite' (in contrast to 'referential' usages with isComposite=false). It might be clearer if throughout the spec these were instead referred to as composed usages.

Note that a 'nested' usage could have either isComposite=true ("composite") or isComposite=false ("referential") ; the suggested term composed makes it clear that the nested usage has isComposite=true.

Similarly, a "composite state" is widely understood to mean a state with substates, NOT a substate that is not owned but not referential.

Relates to

Related notes

Related notes (backlinks)

Related snippets (extracts)

[SysMLv2] A composite requirement usage nested in a requirement definition or usage is a subrequirement of the containing requirement definition or usage.

[SysMLv2] View usages can be nested and ordered within a composite view to generate composite view artifacts.

[SysMLv2] For the overall requirement to then be satisfied, all such composite or referenced requirements must be satisfied.

Visit also

OMG Systems Modeling Language TM (SysML®) Version 2.0 formal/2025-09-03 (Sep 2025)

Visit also (backlinks)

Flags