SysMLv1: Summary of some important changes between SysMLv1.2 and SysMLv1.7 and some DEPRECATED modelling elements [PARTIAL LIST ONLY]

Icon class

icon_class_computed

fas fa-book

Keywords

This page collects some information on various significant changes between the SysMLv1.2 and SysMLv1.7 language specifications, in no particular order. This information may be useful if you are studying for the OCSMP exams.

Visit also: Dr Darren's general TIPS (only) for the OMG-Certified Systems Modeling Language™ (SysML®) Professional (OCSMP) exams

Given the arrival of SysMLv2 and the rapid development of the new SysMLv2 tools, this page is low priority and is largely incomplete:

Links to PDF downloads of formal OMG SysMLv1 versions:

SysMLv1.2 SysMLv1.3 SysMLv1.4 SysMLv1.5 SysMLv1.6 SysMLv1.7

Each SysMLv1 specification version (except the very first) has information on deprecated elements in an Annex (the exact Annex number varies between versions). Some of the information on deprecated elements is highly technical, such as migration instructions primarily for use by tool vendors.

BEWARE: Many SysMLv1 tools offer menus for DEPRECATED elements even many years after their use is no longer recommended

SysMLv1: CAUTION: The notation and recommended use for PropertySpecificType changed significantly between SysMLv1.2 and SysMLv1.7. And the spec itself does not seem to use the new notation (which is also not supported by Cameo Systems Modeler v2024x)

Is the Quantity and Units system of SysMLv1.7 the same as for SysMLv1.2, SysMLv1.3, and SysMLv1.4?

No! There was a major change between SysMLv1.3 and SysMLv1.4! Please refer to the ANNEX C.6 of OMG SysMLv1.7 (formal/24-01-07): C.6 Transitioning SysML 1.3 Units and QuantityKinds to SysML 1.4 (informative)

OMG Systems Modeling Language (SysML) 1.7

FlowSpecification and FlowPort were DEPRECATED in SysMLv1.3

FlowSpecification and FlowPort were DEPRECATED in SysMLv1.3 (formal-12-06-01) long before SysMLv1.7 (and even if they still appear in your tool)

Although the older SysML FlowPort is strictly deprecated, the term "ports with flows" is often used for a Port typed by a block with a FlowProperty. The expression "flow port" is best avoided to prevent confusion.

SysML: MagicDraw/Cameo: DO NOT use the FlowPort or FlowSpecification menu items or smart manipulator items they are completely OBSOLETE (they create DEPRECATED SysML model element types)! Use FlowProperty and FlowDirectionKind on Block features instead.

In SysMLv1.7 you should (usually) use InterfaceBlock and ~InterfaceBlock and DirectedFeature

Since SysML-1.6 use of direct UML conjugation of Ports is NOT supported; If you are using InterfaceBlocks use instead a conjugated ~InterfaceBlock type!

09:03: Port conjugation in SysMLv1 is now Type-based

Conjugation in SysML-1.7 is Type-based: InterfaceBlock, ~InterfaceBlock, and DirectedFeature

Note that the UML-style Interface with provided/required Interface is NOT officially deprecated (and may still be used for software-like contracts).

Beware however that UML Port::isConjugated is DEPRECATED in UML because of side-effects for use with the wider SysMLv1 Port system

The UML Interface does not support the same compartments as a SysMLv1 InterfaceBlock and does not "play nicely" with all SysMLv1 constructs

The FullPort and ProxyPort stereotype were first introduced in SysMLv1.3 (formal-12-06-01), along with the InterfaceBlock (used primarily to type ProxyPorts, and acting as the SysMLv1 "replacement" for the UML Interface).

The conjugating ~InterfaceBlock was first introduced in SysMLv1.6 (SysML-1-6-formal-19-11-01). It addressed numerous issues that arose when using the UML Port::isConjugated with nested ports and with FullPorts with behaviours.

The RequirementRelated stereotype of SysMLv1.2 is FULLY DEPRECATED

SysMLv1: The SysMLv1.6 ConnectorProperty was DEPRECATED in SysMLv1.7. see SysMLv1.7 formal/24-01-07: Annex C: Deprecated Elements and Migration: C.1.3 ConnectorProperty. Use AdjunctProperty with a connector as principal instead.

The mechanism for Viewpoint and View changed substantially between SysML 1.3 and SysML 1.4

The useful and popular "user-defined" stereotypes «system context», «system», «subsystem», «external», and «domain» (which appear in some SysMLv1.7 spec figures) are NOT official non-normative extensions of SysMLv1.7 (even if they still appear under Blocks > Non-Normative in the SysML Profile of Magic Cyber-Systems Engineer^® (Cameo Systems Modeler^®).

Visit also: Useful "user-defined" stereotypes for Blocks: «system context», «system», «subsystem», «external», «domain»

SysML-1.6: 'The «system» and «external» stereotypes are user defined, not specified in SysML, but help the modeler to identify the system of interest relative to its environment. '

"Context specific values" (aka "initial values"

The compartment name for context-specific values was (for better or worse) changed to initialValues in SysMLv1.2 and then by SysMLv1.7 is initial values.

They are a very important concept when modelling real world systems in SysMLv1 and are handled in detail in the Webel course for SysML/MBSE.

08:04: Deep configuration using SysMLv1 context-specific values

SysMLv2 has a new powerful and elegant way of handling this important concept and (with completely different terminology)

The SysMLv1.6 ConnectorProperty was deprecated in SysMLv1.7

The same functionality can be achieved using AdjunctProperty with a Connector as the 'principal' instead of 'connector:Connector'.

SysMLv1.5 introduced the AbstractRequirement, which extends only NamedElement

In SysMLv1.2, a Requirement extended Class and carried the attributes 'text' and 'id' and derived values such as '/derived', '/derivedFrom', and '/satisfiedBy' etc.

Since SysMLv1.5, Requirement extends AbstractRequirement, which extends NamedElement and carries the attributes and derived values. Since SysMLv1.5, a Requirement is a stereotype of both Class and AbstractRequirement. Refer to SysMLv1.7 Figure 16.1. Abstract Syntax for Requirements Stereotypes.

The SysMLv1.7 Annex E.3 Requirements Diagram Extensions describes the non-normative extendedRequirement and its further extensions.

There was a major change for Viewpoint and View between SysML 1.3 and SysML 1.4

In SysMLv1.3 View extended Package; in SysMLv1.7 View extends Class.

In SysMLv1.3 View::stakeholder was a String[0..*]; in SysMLv1.7 Stakeholder extends Classifier, with Viewpoint::stakeholder:Stakeholder[0..*], and derived View::/stakeholder:Stakeholder[0..*].

In SysMLv1.3 Conform extended Dependency (for use with View extends Package); In SysMLv1.7 Conform extends Generalization (for use with View extends Class).

Refer also to this Annex in SysMLv1.7: C.5 Transitioning SysML 1.3 Viewpoint and View to SysML 1.4 (informative)

No ConstraintProperty stereotype since SysMLv1.4

Since SysMLv1.4 there is no ConstraintProperty stereotype, however some tools may still use a vendor specific ConstraintProperty extension to implement the 'constraint property' concept.

No Allocated since SysMLv1.4, just Allocate

SysMLv1.2 had an additional Allocated stereotype (as well as Allocate). The additional Allocated stereotype was removed in SysMLv1.4, the same role is played by the query getAllocatedFrom().

SysMLv1.7 has some incorrect typo references to “Allocated” (see 'Annex B.3 SysML DI usage notes'). There is no Allocated stereotype in SysMLv1.7, just Allocate.

Notes

[GOTCHA, ISSUE, MODELLING, NAMING, WARNING]{INFORMATIVE} SysMLv1: CAUTION: The notation and recommended use for PropertySpecificType changed significantly between SysMLv1.2 and SysMLv1.7. And the spec itself does not seem to use the new notation (which is also not supported by Cameo Systems Modeler v2024x)

[DEPRECATION, TOOL, WARNING]{STRONG} SysML: MagicDraw/Cameo: DO NOT use the FlowPort or FlowSpecification menu items or smart manipulator items they are completely OBSOLETE (they create DEPRECATED SysML model element types)! Use FlowProperty and FlowDirectionKind on Block features instead.

[ISSUE, TOOL] MagicDraw/Cameo v19SP3 vs SysML&SysPhS: The sample project for the Humidifier example uses DEPRECATED FlowPorts (and sets values directly on them in the StateMachines).

[DEPRECATION] Although the older SysML FlowPort is strictly deprecated, the term "ports with flows" is often used for a Port typed by a block with a FlowProperty. The expression "flow port" is best avoided to prevent confusion.

[POLICY] Since SysML-1.6 use of direct UML conjugation of Ports is NOT supported; If you are using InterfaceBlocks use instead a conjugated ~InterfaceBlock type!

[DEPRECATION, ISSUE] SysML-1.6: Figure D.23 has FuelFlow redundantly stereotyped by the DEPRECATED «flowSpecification»

[MODELLING, TIP, TOOL]{INFORMATIVE} SysML1.x: MagicDraw/Cameo: The constraint property concept is (was) implemented using a vendor-specific stereotype extension ConstraintProperty [VENDOR-DEPRECATED]

[DEPRECATION, WARNING]{INFORMATIVE} [OBSOLETE] Until tool support for ~InterfaceBlock comes you have to make a decision: (1) Bake your own «~InterfaceBlock» then deal with clashes when tool support comes; (2) stick with the DEPRECATED UML conjugation (not nested-port friendly).

[WARNING]{INFORMATIVE} SysMLv1: The SysMLv1.6 ConnectorProperty was DEPRECATED in SysMLv1.7. see SysMLv1.7 formal/24-01-07: Annex C: Deprecated Elements and Migration: C.1.3 ConnectorProperty. Use AdjunctProperty with a connector as principal instead.

[ASSERTION, NAMING, WARNING] The SysML block compartment name 'initialValues' for what are really "context-specific values" is confusing - even completely misleading; please just think of them as 'contextValues' (and initial values as a special context case)

Relevant snippets (from other sources)