SysML 1.3 RTF Avatar
  1. OMG Issue

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

  • Key: SYSML13-12
  • Legacy Issue Number: 15876
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    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
  • Reported: SysML 1.2 — Mon, 6 Dec 2010 05:00 GMT
  • Disposition: Resolved — SysML 1.3
  • Disposition Summary:

    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
    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
    The corresponding compliance constraint in OCL for excluding the use of
    UML::Component in a compliant SysML 1.3 model is:
    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
    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) .

  • Updated: Thu, 28 Feb 2019 14:39 GMT