SysML 1.4 RTF Avatar
  1. OMG Issue

SYSML14 — SysML QuantityKind/Unit is incomplete and redundant with QUDV QuantityKind/Unit

  • Key: SYSML14-22
  • Legacy Issue Number: 18269
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In table 8.1, the notation for ValueType shows only the unit, it is missing the quantityKind.

    There is no indication about what is the notation for a value property whose ValueType has a unit U and quantityKind QK.
    Some tools show the unit and/or quantityKind tag/value pairs of the ValueType on the value property itself.
    This notation could suggest that one could change the tag/values shown on the value property itself.

    It is important for the SysML spec to clarify that the tag/values of the type of a property should not be shown on the property itself.
    This tool-specific practice in fact suggests that there is a missing capability; that is:

    QUDV unit and quantityKind could be specified on
    the ValueType itself (in which case it applies to all value properties typed by this ValueType without any possibility to modify them)
    The value property (in which case different value properties typed by the same ValueType could have different combinations of unit/quantityKind)
    A combination of the two (e.g., specify the QuantityKind on the ValueType and specify the Unit on the value property)
    However, what's really missing is support for specifying a "quantity value" in the sense of ISO 80000, that is: a combination of a number and a reference unit.
    Without Unit information on a value, it is impossible to verify that the values in the model conform to the Unit/QuantityKind specified on the value property and/or the ValueType that is typing the value property.
    This means that it is intrinsically impossible to have any verifiable guarantee that all values in a SysML model conform to the unit specified on the value properties (or their ValueType)

    Suggest the following:

    Replace SysML::Unit and SysML::QuantityKind with QUDV::Unit and QUDV::QuantityKind
    Add a new stereotype: ValueProperty extending UML::Property with:
    ValueProperty::unit : QUDV::Unit[0..1]
    ValueProperty::/effectiveUnit : QUDV::Unit[0..1] – it is derived by using ValueProperty::unit, if any and if not, by the ValueType::unit, if any, of the ValueProperty's type
    ValueProperty::/effectiveQuantityKind : QUDV::QuantityKind[0..1] – it is derived from the ValueType::quantityKind of the type of the ValueProperty.
    Add a new stereotype: QuantityValue extending UML::ValueSpecification with:
    QuantityValue::unit : QUDV::Unit[0..1]
    QuantityValue::/unitConstraint : QUDV::Unit[0..1] – if the QuantityValue is the default value of a ValueProperty, then unitConstraint is derived from ValueProperty::/effectiveUnit
    Define the stereotype & tag/value pair notation for QUDV::Unit, QUDV::QuantityKind, ValueType, ValueProperty and QuantityValue

  • Reported: SysML 1.3 — Tue, 20 Nov 2012 05:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    This resolution addresses the issue of the duplication of the concepts of Unit and
    QuantityKind between the SysML profile and the QUDV library by introducing a new,
    3rd model library called UnitAndQuantityKind. A separate resolution will address the
    issue of the notation for ValueType, including TypedElements (e.g. Property,
    ValueSpecification) typed by a ValueType.
    Since the SysML Architecture figures 4.2 and 4.3 need to be updated to reflect the
    addition of a new model library, this resolution also addresses the inaccuracies
    reported in issue 18456 where these figures only showed one of the 2 model
    libraries, PrimitiveValueTypes, omitting the 2nd library, ControlValues. Also, part of
    18456 involves showing the <<ModelLibrary>> stereotypes that should have been
    applied to each of SysML’s model libraries. As indicated in SysML 1.3, section 17.2,
    a SysML Model Library is a UML Package with the UML
    StandardProfileL2::ModelLibrary stereotype applied. Due to tool limitations, the BDD
    diagrams for the 2 SysML model libraries in this resolution show the UML notation for
    StandardProfileL2::ModelLibrary, that is <<ModelLibrary>> rather than the SysMLspecific
    notation which would be <<modelLibrary>> or “bdd [modelLibrary]” in the
    diagram frame. These notation details may change editorially without affecting the
    substance of the resolution.
    Originally, SysML 1.0 and 1.1 had a single concept of Unit and a single concept of
    Dimension. The duplication began in SysML 1.2 at the specification level where the concept of Dimension was renamed to QuantityKind as part of an alignment with the
    new ISO 80000-1 standard and a new conceptual model of Quantities, Units,
    Dimensions and Values (QUDV) was introduced only in the document as Annex C.5.
    The specification-level duplication became a practical problem in SysML 1.3 where
    the QUDV conceptual model became available as a non-normative machinereadable
    XMI artifact. With SysML 1.3, users and tool vendors have several options
    for modeling definitions of Units and QuantityKinds:

    • use the normative SysML stereotypes from the Blocks chapter
    • use the non-normative QUDV libraries from Annex D.4
    • use both in combination (e.g., apply the <<Unit>> stereotype to
      InstanceSpecifications classified by QUDV::Unit)
      These options multiply the cost of developing and maintaining libraries of Unit and
      QuantityKind definitions. The 3 different options above apply for defining a Unit or a
      QuantityKind. This means that there are 9 different options for defining the same pair
      of Unit/QuantityKind. Within the International System of Units alone, there are 20
      decimal prefixes and 8 binary prefixes that can each apply to a Unit. ISO 80000 has
      14 parts; part 1 defines 45 units (7 base units, 18 in Table 2, 4 in Table 3, 10 in Table
      5 and 6 in Table 6). Thus, a complete library of all legitimate pairs of
      Unit/QuantityKind in scope of ISO-80000-1 involves 45 * 28 = 1,260 pairs of prefixed
      units and quantity kinds. It would be counter-productive and prohibitively expensive
      to attempt supporting nearly 10x different options of defining the same 1,260 pairs for
      just ISO 80000-1. SysML needs to adopt one option. Which one?
      Since the SysML Unit and QuantityKind stereotype provide a strict subset of the
      functionality of the QUDV Unit and QuantityKind concepts, this resolution effectively
      replaces the SysML::Blocks:: {Unit,QuantityKind} stereotypes with their QUDV Block
      counterparts. That is, SysML::Blocks::Unit changes from being a Stereotype to being
      a Class stereotyped by SysML’s Block. Similarly, SysML::Blocks::QuantityKind
      changes from being a Stereotype to being a Class stereotyped by SysML’s Block.
      Having changed the nature of Unit and QuantityKind from a Stereotype to a Class
      means that Unit and QuantityKind are M1-level classes, not M2-level stereotype
      extensions of metaclasses, it is important to clarify how the new Class-based Unit
      and QuantityKind concepts are intended to be used for defining particular Units and
      QuantityKinds.
      In principle, there are three ways to define Units and QuantityKinds:
      1. as M1-level InstanceSpecifications classified by
      SysML::Blocks::{Unit,QuantityKind}

      2. as M1-level Classes specializing SysML::Blocks::

      {Unit,QuantityKind}

      3. as M1-level Classes that are instances of M2-level metaclasses Unit and
      QuantityKind The third approach is outside the scope of the nature of SysML as a profile (a profile
      cannot define new metaclasses).
      The second approach requires fairly sophisticated tool support for specializing the
      associations between SysML::Blocks::Unit and SysML::Blocks::QuantityKind.
      Modeling association specialization is a challenging topic in UML because the
      mechanisms involved (i.e., generalization, redefinition, subsetting) have subtle
      distinctions (e.g., subsetting and redefinition are, respectively, in the domain of
      extensional vs. intentional semantics respectively) and the consequences of their
      combinations are difficult to analyze (e.g., disjoint vs. overlapping specialization).
      These modeling challenge carry over to definitions of new ValueTypes where the
      associations between ValueType and Unit/QuantityKind have to be specialized as
      well. The specialization approach is particularly challenging to understand because it
      inherently leads to asking questions about the meaning of the class-based
      specializations of Unit/QuantityKind and about the existence and meaning of
      instances of these classes.
      The first approach based on InstanceSpecifications approach avoids the complexity
      of the Class-based specialization of the 2nd approach. However, this
      InstanceSpecification-based approach requires careful attention about the UML tool
      support for modeling link instances of associations. In particular, such links must be
      fully specified with slots for each association’s end property regardless of its
      ownership by the association or classifier typing the opposite end. This tool support is
      important for the unambiguous interpretation of an InstanceSpecification classified by
      an Association as a representation of an instance of that Association between the
      InstanceSpecifications interepreted as representations of instances of the related
      Classifiers typing the ends of that Association.
      This resolution adopts the first approach, i.e., the M1-level InstanceSpecification
      based paradigm for defining Units and QuantityKinds. To maintain the separation
      between the normative SysML profile and the non-normative QUDV conceptual
      model, this resolution splits the QUDV::Unit and QuantityKind in two parts:

    • the part corresponding to the SysML 1.3 Unit/QuantityKind stereotypes that
      will be refactored into Block definitions in a new UnitAndQuantityKind model
      library
    • the rest that is unique to QUDV and that will be refactored as a specialization
      of the corresponding blocks from the UnitAndQuantityKind model library
      Because this resolution effectively promotes the QUDV concepts of Unit and
      QuantityKind into the normative SysML profile, the normative specification of these
      concepts is aligned to the publicly available VIM3 document instead of the non-public
      ISO-80000-1 document.
  • Updated: Fri, 6 Mar 2015 20:58 GMT