The namespace definition in the XMI and the URI attribute of the Profile is xmlns:SysML4Modelica=http://www.omg.org/spec/SysM/20120213. This uses SysM not the official directory (according to the other documents) which is the shorter SyM.

The spec name “SysM” was wrongly used in the XMI definition of the SysML4Modelica profile. It needs to be changed to the shorter "SyM" version.

The figure references UML4SysML which is no longer part of/used by the version of SysML (1.3) included in the normative references

The figure should reference UML package instead of the UML4SysML package.

The figure references UML4SysML which is no longer part of/used by the version of SysML (1.3) included in the normative references

See issue 17214 for disposition

In general the Part structure used is not appropriate for OMG specifications. It does not make sense to label Part I as non-normative. Especially as Part I includes Conformance and Normative References!

The part structure is kept since it is still considered helpful to structure the document. Part 1 needs to be labeled as normative.

the new figure still uses <<conformsTo>> <<transformation>> and <<instanceOf>> applied to lines using the Dependency notation. These have no defined meaning (either as keywords nor as stereotypes defined either in this specification, SysML or UML). Whatever <<instanceOf>> means it’s not the case that a transformationRecord is an instance of a transformation. If these stereotypes are retained there should be an explanation to say they are purely informal

An additional sentence needs to be added stating that the <<conformsTo>>, <<transformation>> and <<instanceOf>> stereotypes are purely informal

Section 2 includes in Level 0 Compliance “The SysML4Modelica profile must be compliant with OMG SysML v1.3.”. However a) this profile is part of this specification and b) SysML does not define compliance for Profiles. So it’s unclear what compliance would mean

In order to avoid any confusion, the sentence "The SysML4Modelica profile must be compliant with OMG SysML v1.3" should be remove.

In the SysML-Modelica Transformation Specification (http://www.omg.org/spec/SyM/1.0/Beta1/PDF/), the attribute fromLibrary for the stereotype «modelicaClassDefinition» is not sufficiently clearly defined (Section 8.2, page 10). The spec mentions that some details (e.g. "value properties and parts") can be omitted when using the fromLibrary tag, but the spec is not sufficiently precise as to which details exactly can/should be omitted and which should still be retained. Since this is a construct that will likely be used extensively, it should be defined more precisely.

The identified issue does not relate to the mapping of language constructs between SysML and Modelica but rather to a user- and tool-specific usability aspect of the transformation. The issue therefore does not identify a problem with the specification. Additionally, the “fromLibrary” attribute of the «modelicaClassDefinition» stereotype will be removed since it does not relate to the mapping of language constructs between SysML and Modelica.

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.

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.

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.

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.

Not sure of the use of openmodelica.org.

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.

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

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

The UML Profile is represented in proprietary Eclipse format

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

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.

See issue 16545 for disposition

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.

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.

P6 uses ‘meta-case’ for transformation technology.

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.

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.

Section 6.1 will be deleted.

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

No Data Available

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

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

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’.

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.

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

No Data Available