-
Key: QVT-66
-
Legacy Issue Number: 9397
-
Status: closed
-
Source: Adaptive ( Mr. Pete Rivett)
-
Summary:
The QVT spec (ptc/05-11-01) is littered with references to EMOF but has not one reference to CMOF.
Hence it's not clear whether QVT can be used to transform models that instantiate CMOF metamodels. This is a major requirement since UML2 is itself a CMOF metamodel.Note that it's not important here that the QVT metamodel itself is expressed only in EMOF: but that it can be applied to CMOF metamodels. This means that references such as ObjectTemplateExp::referredClass(from EMOF) (see Fig 7.6) should also support references to CMOF metaclasses. Though CMOF is a compatible extension of EMOF, it is important that the QVT specification makes it clear that references to CMOF classes must be supported and that compliant QVT engines should not lose information when they transform models for CMOF metamodels. This is also likely to requires changes to the specification logic that describes the execution of transformations - for example to fully support non-unique Associations.
-
Reported: QVT 1.0b1 — Fri, 24 Feb 2006 05:00 GMT
-
Disposition: Resolved — QVT 1.0
-
Disposition Summary:
(1) Add a new top-level section named "QVT for CMOF" with the following content:
For the sake of simplicity all previous chapters assume QVT used in the context of EMOF conformant metamodels. However this specification is also applicable to CMOF metamodels with a few restrictions.
11.1 The QVT metamodel for CMOF
The QVT metamodel for CMOF is a CMOF metamodel that is obtained by executing the following steps:
The EMOF package is replaced by the CMOF Package.
All other packages - including the EssentialOCL - are cloned, with the exception that all references to the original EMOF metaclasses are replaced by references to the corresponding CMOF metaclass.11.2 Semantic specificities
The semantics of CMOF concerning the access and the modification of properties replaces the semantics of EMOF. For instance, in CMOF, setting a property that is specified as an association end implies that the corresponding association link instance is created and that any related sub-setted association is updated accordingly.
There are some limitations when using QVT on CMOF metamodels which comes from the fact that we are cloning EssentialOCL - at the time being, the OCL specification does not define an "OCL for CMOF metamodels".
- It is not possible to refer directly to an association; instead an association has to be accessed as a property from one of the owning classes. However, this does not address the case where both the ends of an association are owned by the association itself.
(2) In the Compliance section 2, add a sub-section named "EMOF and CMOF compliance" after Section 2.3 Interoperability Dimension with the following content:
A QVT tool may declare to be EMOF-compliant or CMOF-compliant (possibly both) depending on the kind of models that it is capable of working with. The same dimensions serving to characterize QVT-EMOF compliant implementations (in Figure 2.1) are applicable to QVT CMOF-compliant implementations. Note however that the XMI for an EMOF-compliant QVT tool is not the same as the XMI for a CMOF-compliant QVT tool since the XMI generation rules for CMOF are distinct from the corresponding generation rules for EMOF.
-
Updated: Fri, 6 Mar 2015 22:36 GMT