${taskforce.name} Avatar
  1. OMG Task Force

SysML-Modelica FTF — Closed Issues

  • Key: SYM
  • Issues Count: 13
Open Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

SysML-Modelica Transformation Spec problem with

  • Key: SYM-13
  • Legacy Issue Number: 16556
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    As found by Lenny Delligatti of Lockheed Martin.

    On page 5 of the spec., it shows that the SysML4Modelica profile references the SysML profile (Figure 2 in the screenshot below):

    But I believe that’s an error. I believe that a «reference» dependency is only legal from a profile to a metamodel.

    One profile can «import» another profile (and thus transitively reference a metamodel), but not «reference» another profile.

  • Reported: SyM 1.0b1 — Fri, 9 Sep 2011 04:00 GMT
  • Disposition: Resolved — SyM 1.0b2
  • Disposition Summary:

    See issue 16545 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SysML-Modelica Transformation Spec problem with

  • Key: SYM-12
  • Legacy Issue Number: 16545
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    As found by Lenny Delligatti of Lockheed Martin.

    On page 5 of the spec., it shows that the SysML4Modelica profile references the SysML profile (Figure 2 in the screenshot below):

    But I believe that’s an error. I believe that a «reference» dependency is only legal from a profile to a metamodel.

    One profile can «import» another profile (and thus transitively reference a metamodel), but not «reference» another profile.

  • Reported: SyM 1.0b1 — Fri, 9 Sep 2011 04:00 GMT
  • Disposition: Resolved — SyM 1.0b2
  • Disposition Summary:

    A UML dependency can be between any two NamedElements. The dependency can also be tagged with any stereotype and be given any name. So the <<reference>> dependency is by itself legal. However, a keyword such as <<import>> can also be applied to a dependency.The <<import>> keyword seems more suitable to be applied on a dependency between profiles. So the <<reference>> dependencies to the UML4SysML metamodel (as shown in the SysML spec) in Figure 2 are kept and the <<reference>> dependency between the SysML4Modelica and SysML profiles in Figure 2 is replaced by an <<import>> dependency.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incomplete Annex C Content

  • Key: SYM-11
  • Legacy Issue Number: 16490
  • Status: closed  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    Source: Georgia Institute of Technology (Mr. Axel Reichwein, axel.reichwein(at)me.gatech.edu)
    Summary: The QVT code shown in Annex C is incomplete. In addition, a figure showing an overview of the QVT implementation approach would be useful.

  • Reported: SyM 1.0b1 — Wed, 10 Aug 2011 04:00 GMT
  • Disposition: Resolved — SyM 1.0b2
  • Disposition Summary:

    The QVT code in Annex C is outdated and has to be replaced by the latest
    version. Since the current QVT code consists of approx. 5000 lines of code, it
    would be too large to be placed in Annex C. Instead, Annex C should contain a
    URL reference to a separate document containing all QVT transformations in a
    zipped file. In addition, a figure showing an overview of the QVT implementation
    approach should be placed in Annex C.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Not sure of the use of openmodelica.org.

  • Key: SYM-10
  • Legacy Issue Number: 16385
  • Status: closed  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    Not sure of the use of openmodelica.org.

  • Reported: SyM 1.0b1 — Thu, 21 Jul 2011 04:00 GMT
  • Disposition: Resolved — SyM 1.0b2
  • Disposition Summary:

    Issues 16384 and 16385 address the correctness of using non-normative URIs to
    identify the UML and Modelica metaclasses in the QVT transformation. The
    implementation of the transformation in QVT includes references to the
    metaclasses of both the UML and Modelica metamodels. These references are
    found next to the “modeltype” keyword at the beginning of each QVT
    transformation.
    Since no normative Modelica metamodel exists, there are no normative URIs to
    identify the Modelica metaclasses. The QVT code can thus not refer to Modelica
    metaclasses through normative URIs and be considered normative. The use of
    non-normative URIs to identify the UML and Modelica metaclasses in the QVT
    transformation is therefore acceptable.
    The QVT code does not need to be changed. However, the SysML-Modelica
    Transformation specification should not state that Parts III, IV and V of the
    SysML-Modelica Transformation specification are normative since they are all
    based on a non-normative Modelica metamodel from openModelica.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The QVT does not use the standard URI for the UML metamodel

  • Key: SYM-9
  • Legacy Issue Number: 16384
  • Status: closed  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    The QVT does not use the standard URI for the UML metamodel

  • Reported: SyM 1.0b1 — Thu, 21 Jul 2011 04:00 GMT
  • Disposition: Resolved — SyM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8

  • Key: SYM-8
  • Legacy Issue Number: 16383
  • Status: closed  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    Section 8: presumably these are production rules for Modelica syntax. Does this need to be duplicated in this spec?

  • Reported: SyM 1.0b1 — Thu, 21 Jul 2011 04:00 GMT
  • Disposition: Resolved — SyM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 2 uses stereotypes such as <> that are not defined

  • Key: SYM-7
  • Legacy Issue Number: 16382
  • Status: closed  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    Figure 2 uses stereotypes such as <<transformation>> that are not defined

  • Reported: SyM 1.0b1 — Thu, 21 Jul 2011 04:00 GMT
  • Disposition: Resolved — SyM 1.0b2
  • Disposition Summary:

    The <<transformation>> stereotype is a self-defined stereotype referring to a
    mapping definition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

P6 uses ‘meta-case’ for transformation technology.

  • Key: SYM-6
  • Legacy Issue Number: 16381
  • Status: closed  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    P6 uses ‘meta-case’ for transformation technology.

  • Reported: SyM 1.0b1 — Thu, 21 Jul 2011 04:00 GMT
  • Disposition: Resolved — SyM 1.0b2
  • Disposition Summary:

    The capabilities of meta-CASE tools are not well-known. Therefore, the sentence
    mentioning the implementation of the SysML-Modelica mapping by meta-CASE
    tools is relaxed by referring to “tools” in general instead of “meta-CASE” tools.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.1: this SysML issue does not belong here as such

  • Key: SYM-5
  • Legacy Issue Number: 16380
  • Status: closed  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    6.1: this SysML issue does not belong here as such: if a change is needed it should be specified as a detailed edit to the SysML spec. Otherwise just raise the issue in the normal way.

  • Reported: SyM 1.0b1 — Thu, 21 Jul 2011 04:00 GMT
  • Disposition: Resolved — SyM 1.0b2
  • Disposition Summary:

    Section 6.1 will be deleted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sections 3.1 and 3.2

  • Key: SYM-4
  • Legacy Issue Number: 16379
  • Status: closed  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    3.1 should reference version 1.1 of QVT.
    3.2: It’s not clear how the MDA Foundation Model ‘constitute provisions of this specification’.

  • Reported: SyM 1.0b1 — Thu, 21 Jul 2011 04:00 GMT
  • Disposition: Resolved — SyM 1.0b2
  • Disposition Summary:

    Section 3.1 will reference version 1.1 of QVT and Section 3.2 will not refer to any
    non-normative references including the MDA Foundation Model.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 2 Conformance requires more detail for practical definition of ‘full realization’ and ‘abstract syntax complianc

  • Key: SYM-3
  • Legacy Issue Number: 16378
  • Status: closed  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    Section 2 Conformance requires more detail for the practical definition of ‘full realization’ and ‘abstract syntax compliance’

  • Reported: SyM 1.0b1 — Thu, 21 Jul 2011 04:00 GMT
  • Disposition: Resolved — SyM 1.0b2
  • Disposition Summary:

    Proposed change: leave out ‘full realization’ and ‘abstract syntax compliance’. In
    addition, add a level 1 criteria referring to required level 0 compliance.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The UML Profile is represented in proprietary Eclipse format

  • Key: SYM-2
  • Legacy Issue Number: 16377
  • Status: closed  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    The UML Profile is represented in proprietary Eclipse format

  • Reported: SyM 1.0b1 — Thu, 21 Jul 2011 04:00 GMT
  • Disposition: Resolved — SyM 1.0b2
  • Disposition Summary:

    The SysML4Modelica has been converted into OMG-grade XMI and has been added to the inventory of files which still includes the profile in Eclipse format.
    Disposition:Resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ecore is used for the Modelica metamodel in Part III rather than EMOF

  • Key: SYM-1
  • Legacy Issue Number: 16376
  • Status: closed  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    Ecore is used for the Modelica metamodel in Part III rather than EMOF (EMOF is also supported by the EMF technology). Oddly though I can see no depiction of the metamodel in either ecore or EMOF: I would for example expect to see some UML class diagrams. Instead there is what appears to be Modelica syntax.

  • Reported: SyM 1.0b1 — Thu, 21 Jul 2011 04:00 GMT
  • Disposition: Resolved — SyM 1.0b2
  • Disposition Summary:

    The abstract syntax of Modelica, in other words its metamodel, needs to be represented in UML class diagrams. Figure 13 containing a representation of some Modelica metaclasses in an Ecore diagram will be replaced by UML class diagrams.

  • Updated: Fri, 6 Mar 2015 20:58 GMT