SYSML13 — Define the SysML profile as referencing UML and replace the UML4SysML subset with OCL constraints

Today, during the SysML1.3 RTF, we discussed simplifying the definition of the SysML profile by referencing the UML metamodel directly instead of the UML4SysML construction and replace the UML4SysML construction with OCL constraints about the scope of UML that defines strict conformance to SysML in the context of the UML4SysML subset. The practical advantages include:

• any UML tool can be used as the basis for implementing the SysML profile
• the SysML profile can be easily combined with other profiles that extend UML; e.g., SoaML, etc... (i.e., this could simplify the construction of UPDM)
• if users need to use more than the UML4SysML subset, they could simply disable the OCL constraints for strict UML4SysML conformance

Prior to UML2.4.1, the OMG never published the merged UML metamodel as a
normative machine-readable artifact nor specified compliance to UML in terms of
it. From an OMG Specification Management point of view (i.e., OMG’s SMSC
policy), it makes sense to require that the only dependencies a published
normative machine-readable artifact might have should be to other published
normative machine-readable artifacts.
For SysML1.2, the published normative machine-readable SysML1.2 profile
depended only on the published normative machine-readable UML4SysML
merged metamodel constructed from the published normative machine-readable
artifacts for UML2.3’s Infrastructure & Superstructure. Because the UML2.3
StandardProfileL2 was never published, this also meant that the SysML1.2
profile had to duplicate the definition of UML2.3’s StandardProfileL2::Trace
stereotype in the SysML profile, i.e., SysML::Trace.
The 2.4.1 series of UML, MOF and XMI made significant changes to the OMG
metamodel/profile architecture. In particular, the merged UML2.4.1 metamodel
and the UML2.4.1 StandardProfileL2 are both published as normative machinereadable
artifacts, which simplifies greatly problems of model interchange across UML 2.4.1 compliant tools. By aligning the SysML1.3 profile as a simpler
extension of the published, normative UML 2.4.1 metamodel rather than a
complicated extension of a partial merge of the UML Superstructure, SysML1.3
can also benefit from improvements in model interchange for UML 2.4.1
compliant modeling tools.
In SysML1.2, the UML4SysML subset served two distinct purposes:
1. Specifying which UML elements can be used in compliance with the
limited scope of the SysML language.
2. Constructing and publishing SysML in terms of a normative published
machine-readable artifacts, i.e., the UML4SysML metamodel.
The second purpose, constructing and publishing SysML, resulted in a significant
implementation complexity and caused significant problems for model
interchange testing. The UML4SysML metamodel represents a significant
disincentive for UML tool vendors to build a lesser capability metamodel, i.e.,
UML4SysML, just to provide support for the SysML profile. In fact, some UML
tool vendors used UML instead of UML4SysML to implement support for the
SysML profile. The publication of a normative merged metamodel in UML2.4.1
and the multi-vendor efforts in the Model Interchange Working Group (MIWG)
provide compelling reasons to do away with the special-purpose construction and
publication of UML4SysML as a merged metamodel just for defining SysML
properly.
The first purpose, specifying the scope of the SysML language as an extension
of a limited subset of UML, was perfectly within the spirit of the metamodel
architecture from UML2.0 until UML2.3 where the UML 2 Infrastructure &
Superstructure provided the basis for package-level reuse in the family of UML
languages. Since there was no published, normative, merged metamodel for
UML 2, it was perfectly legitimate and recommended to use package merge
techniques to construct special-purpose languages like the UML4SysML subset
for defining domain-specific extensions like SysML. With the publication of a
normative, merged metamodel in UML2.4.1 and the change in metamodel
architecture where UML2.4.1 is defined as an instance of itself, it makes sense to
define the SysML 1.3 profile as an extension of the UML 2.4.1 merged
metamodel. Unfortunately, this creates a complication for specifying the limited
reuse of UML in SysML.
According to UML, a Profile must reference the metamodel it extends via a
PackageImport relationship whose target is the referenced metamodel (see
section 18.3.7 in UML2.4.1 Superstructure). Consequently, any profile
referencing the merged UML2.4.1 metamodel potentially extends every
metaclass defined in UML2.4.1. SysML 1.3 effectively extends only a subset of
UML2.4.1 metaclasses. Whereas this subset was defined via a package merge
construction in SysML 1.2 for each SysML compliance level, each compliance
level subset is defined in SysML 1.3 via constraints specifying that there should not be any instances of metaclasses outside the scope of that subset in a
compliant model. For example, UML::Component is outside the UML4SysML
subset.
The corresponding compliance constraint in OCL for excluding the use of
UML::Component in a compliant SysML 1.3 model is:
Component.allInstances()->isEmpty()
For SysML1.3, the UML4SysML subset includes 213 of the 242 metaclasses in
UML2.4.1. The UML4SysML subset is further broken down into the 3 compliance
levels defined for SysML1.2 adjusted to ensure that the required classifier
dependencies for each classifier at a given level are also at that level or below.
All general classifiers and all of the classifiers typing a property with required
multiplicity are considered required classifier dependencies for a given classifier.
Specifying SysML1.3 as a profile referencing the UML2.4.1 metamodel provides
tangible practical benefits:
? Any UML2.4.1-compliant tool can be used as the basis for a compliant
implementation of SysML1.3.
? Model interchange for SysML1.3 reduces to the interchange of UML2.4.1
models with the application of one or more profiles extending UML2.4.1.
? Verifying a UML2.4.1 model with the SysML1.3 profiled applied for a given
level of SysML 1.3 compliance amounts to verifying an OCL constraint or
equivalently a QVT Operational query or QVT Relational pattern on that
model.
As of UML 2.4.1, the specification does not explicitly indicate if it is legal for a
profile (e.g., SysML) to be applied to a package defined within that profile (e.g.,
ModelLibrary in SysML 1.2). This resolution adopts a conservative, pessimistic
interpretation of UML 2.4.1 where the only capabilities that SysML can
normatively depend from UML are those that are explicitly called out in the
specification document. In this particular case, it means that the library of
predefined value types – see 8.3.3 in SysML 1.2 – cannot be nested within the
SysML profile itself since the UML::DataTypes in that library must have the
SysML::ValueType stereotype applied to them. In SysML 1.3, the predefined
library of such ValueTypes is moved outside of the SysML profile precisely to
avoid relying on undocumented profile semantics (see figures 4.3 and 8.7) .