Issue 11341: QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles (qvt-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: Issue : QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles UML models drawn with Rose allow an opposite role to be defined for a uni-directional role. This practice is common but haphazard in UML Infrastructure, EMOF, OCL and QVT specification diagrams. However EMOF provides only the (run-time) usage of the model and so any EMOF (or Ecore) model generator must strip non-navigable opposite roles. QVT matches models at compile-time and matching has no inherent need to observe navigation constraints. This is amply demonstrated by the Rel2Core transformation that makes extensive use of, for instance, the inverse Key to Class relationship. ---------------------------------- Problem: some QVT transformations require names for non-navigable opposite roles, but those names cannot be present in layered multi-package EMOF meta-models. The Rel2Core transformation of Section 10.3 cannot be implemented with QVT 1.0. ---------------------------------- Abandoning EMOF (or Ecore) compliance in favour of perhaps CMOF seems unacceptable. Changing EMOF (or Ecore) to incorporate opposite roles is not possible because an EMOF specification cannot be extended to include the opposite role of every meta-model that will ever exist. Even if it was, there would be a substantial delay until meta-modelling tools adopted the change and a problem with poor standardisation and global non-interference of opposite rolenames. QVT must therefore support definition of non-navigable role names as part of a transformation. ModelMorf provided a very practical concrete syntax solution, whereby the reserved operation opposite(qualified-role-name) could be used as the missing opposite role-name wherever a forward role-name could be used. An upward compatible abstract syntax requires an additional is-opposite qualifier for each referred property. So for QVTCore::PropertyAssignment add isOpposite:Boolean[0..1] default false. QVTTemplate::PropertyTemplateItem add isOpposite:Boolean[0..1] default false. QVTRelation::Key add oppositeParts:Property[0..*] { composed } and possibly relax the lower bound for QVTRelation::Key add parts:Property[0..*] { composed } with the constraint that parts.size() + oppositeParts.size() > 0 Perhaps QVTOperational::Module needs an additional oppositeConfigProperty and QVTOperational::ContextualProperty needs an additional isOpposite too. Resolution: Revised Text: (1) Replace the definition of Key (Section 7.11.3.5) by the following text: 7.11.3.5 Key A key defines a set of properties of a class that uniquely identify an instance of the class in a model extent. A class may have multiple keys (as in relational databases). Sometimes it may be necessary to specify a key in terms of opposite properties that are not navigable from the class. Please refer to section 7.4 for a detailed description of the role played by keys in the enforcement semantics of relations. Superclasses Element Associations identifies: Class [1] The class that is identified by the key. part: Property [0..*] Properties of the class that make up the key. oppositePart: Property [0..*] Opposite properties of the class that make up the key. (2) In the definition of PropertyTemplateItem (Section 7.11.2.4), add the following attribute definition: Attributes isOpposite:Boolean Specifies whether the referred property is owned by the opposite end class. An opposite property template item selects an object of the opposite end class that has this object as the value of the specified property. The default value of this property is false. Please refer to section 7.3 for an example that uses an opposite property in template specification. (3) Modify the grammar rule <keyDecl>, <classId>, <keyproperty> and <propertyTemplate> in section 7.13.5 as follows: <keyDecl> ::= 'key' <classId> '{' <keyProperty> (, <keyProperty>)* '}' ';' <classId> ::= <pathNameCS> <keyProperty> ::= <identifier> | 'opposite' '(' <classId> '.' <identifier> ')' <propertyTemplate> ::= <identifier> '=' <OclExpressionCS> | 'opposite' '(' <classId> '.' <identifier> ')' '=' <OclExpressionCS> (4) At the end of section 7.4 describing keys add the following text: Sometimes it may be necessary to use a non-navigable opposite role in the specification of a key. For instance, an attribute is identified by a combination of its name and the owning class. Suppose we have a meta model in which the 'Class' to 'Attribute' association 'attribute' is only navigable from Class to Attribute. We should still be able to use this association in the key specification of Attribute. E.g. key Attribute {name, opposite(Class.attribute)}; This specifies that an attribute is uniquely identified by its name and the class it belongs to. (5) At the end of section 7.3, just before the last sentence, add the following text: Sometimes it may be necessary to use a non-navigable opposite role in the specification of object templates. E.g. domain myModel a:Attribute {name = n, opposite(Class.attribute) = c:Class{}}; This specifies that the pattern will only match if the class the attribute belongs to is equal to 'c'. This is equivalent to the following template definition with condition: domain myModel a:Attribute {name = n} {c.attribute.includes(a)}; But the 'opposite' notation allows this to be specified in the template itself, leading to more compact specifications (6) In figure 7.6, add the new 'isOpposite : Boolean' attribute to the PropertyTemplateItem metaclass. (7) In Figure 7.7, add the additional 'oppositePart: Property [0..*]' association from Key metaclass to the Property metaclass. Actions taken: September 10, 2007: received issue April 26, 2010: closed issue Discussion: Agree with the suggested extensions to the key and property template parts of the relations language. As for a more general support in other expressions, we should perhaps wait until the next OCL revision. Sometimes it may be necessary to use a non-navigable opposite role in the specification of a key. For instance, an attribute is identified by a combination of its name and the owning class. Suppose we have a meta model in which the 'Class' to 'Attribute' association 'attribute' is only navigable from Class to Attribute. We should still be able to use this association in the key specification of Attribute. E.g. key Attribute {name, opposite(Class.attribute)}; This specifies that an attribute is uniquely identified by its name and the class it belongs to. Similarly, it is useful to be able to specify object templates in terms of opposite properties. E.g. domain myModel a:Attribute {name = n, opposite(Class.attribute) = c:Class{}}; This specifies that the pattern will only match if the class the attribute belongs to is equal to 'c'. This is equivalent to the following template definition with condition: domain myModel a:Attribute {name = n} {c.attribute.includes(a)}; But the 'opposite' notation allows this to be specified in the template itself, leading to more compact specifications. End of Annotations:===== m: "Ed Willink" To: Subject: Navigating non-navigable opposite roles Date: Mon, 10 Sep 2007 22:09:16 +0100 X-Mailer: Microsoft Outlook, Build 10.0.6822 Thread-Index: Acfz7tg5J0ta0dFQSo+fc1K2g2wTGA== Hi ********************************************* Issue : QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles UML models drawn with Rose allow an opposite role to be defined for a uni-directional role. This practice is common but haphazard in UML Infrastructure, EMOF, OCL and QVT specification diagrams. However EMOF provides only the (run-time) usage of the model and so any EMOF (or Ecore) model generator must strip non-navigable opposite roles. QVT matches models at compile-time and matching has no inherent need to observe navigation constraints. This is amply demonstrated by the Rel2Core transformation that makes extensive use of, for instance, the inverse Key to Class relationship. ---------------------------------- Problem: some QVT transformations require names for non-navigable opposite roles, but those names cannot be present in layered multi-package EMOF meta-models. The Rel2Core transformation of Section 10.3 cannot be implemented with QVT 1.0. ---------------------------------- Abandoning EMOF (or Ecore) compliance in favour of perhaps CMOF seems unacceptable. Changing EMOF (or Ecore) to incorporate opposite roles is not possible because an EMOF specification cannot be extended to include the opposite role of every meta-model that will ever exist. Even if it was, there would be a substantial delay until meta-modelling tools adopted the change and a problem with poor standardisation and global non-interference of opposite rolenames. QVT must therefore support definition of non-navigable role names as part of a transformation. ModelMorf provided a very practical concrete syntax solution, whereby the reserved operation opposite(qualified-role-name) could be used as the missing opposite role-name wherever a forward role-name could be used. An upward compatible abstract syntax requires an additional is-opposite qualifier for each referred property. So for QVTCore::PropertyAssignment add isOpposite:Boolean[0..1] default false. QVTTemplate::PropertyTemplateItem add isOpposite:Boolean[0..1] default false. QVTRelation::Key add oppositeParts:Property[0..*] { composed } and possibly relax the lower bound for QVTRelation::Key add parts:Property[0..*] { composed } with the constraint that parts.size() + oppositeParts.size() > 0 Perhaps QVTOperational::Module needs an additional oppositeConfigProperty and QVTOperational::ContextualProperty needs an additional isOpposite too. ************************************************ Regards Subject: RE: issue 11341 -- MOF QVT xTF issue Date: Wed, 12 Sep 2007 06:01:51 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 11341 -- MOF QVT xTF issue Thread-Index: Acf0o0NWOcS5uSrKSWKoSM1M7XYE6AAFmLxw From: "Pete Rivett" To: UML Infrastructure Basic (L0 compliance), which is the basis for EMOF, does have Property::opposite which I think addresses the issue. This is also available in CMOF but is derived (calculated using Associations). Furthermore I believe that OCL allows expressions to traverse associations in either direction. I disagree with some of the assertions in the issue such as "However EMOF provides only the (run-time) usage of the model and so any EMOF (or Ecore) model generator must strip non-navigable opposite roles." There is nothing at all in EMOF that restricts it in that way. "Problem: some QVT transformations require names for non-navigable opposite roles, but those names cannot be present in layered multi-package EMOF meta-models." I do not see why this is the case. "Changing EMOF (or Ecore) to incorporate opposite roles is not possible because an EMOF specification cannot be extended to include the opposite role of every meta-model that will ever exist." As above, EMOF already has the ability to represent opposite roles. if "an EMOF specification" means a specific EMOF metamodel then why would it need to be so extended? What would be an example use case? While not directly related to the issue which is about EMOF metamodels, people should also remember that, even if not shown in diagrams, any CMOF metamodel must have names for all Associations and the Properties at their ends. In the UML metamodel case, there is a documented algorithm for generating the names in the transformation from the UML depiction to the formal CMOF rendition of metamodel. More generally we MUST get round to recognizing that UML 2 Finalization changed the definition of 'navigable' and divorced it from the ownership of Properties. This QVT issue should be cast in terms of Property ownership and not navigability. It's unfortunate that the UML spec (for tooling and effort reasons) still relies on the convention of using navigability arrows to show property ownership, and not the new 'dot' notation introduced for the purpose. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Hello House, 135 Somerford Road, Christchurch, BH23 3PY, UK Tel: +44 (0)1202 491243 Fax: +44 (0)1202 491241 http://www.adaptive.com -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Tuesday, September 11, 2007 7:37 PM To: issues@omg.org; mof-qvt-ftf@omg.org Subject: issue 11341 -- MOF QVT xTF issue From: "Ed Willink" To: Subject: Navigating non-navigable opposite roles Date: Mon, 10 Sep 2007 22:09:16 +0100 X-Mailer: Microsoft Outlook, Build 10.0.6822 Thread-Index: Acfz7tg5J0ta0dFQSo+fc1K2g2wTGA== Hi ********************************************* Issue : QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles UML models drawn with Rose allow an opposite role to be defined for a uni-directional role. This practice is common but haphazard in UML Infrastructure, EMOF, OCL and QVT specification diagrams. However EMOF provides only the (run-time) usage of the model and so any EMOF (or Ecore) model generator must strip non-navigable opposite roles. QVT matches models at compile-time and matching has no inherent need to observe navigation constraints. This is amply demonstrated by the Rel2Core transformation that makes extensive use of, for instance, the inverse Key to Class relationship. ---------------------------------- Problem: some QVT transformations require names for non-navigable opposite roles, but those names cannot be present in layered multi-package EMOF meta-models. The Rel2Core transformation of Section 10.3 cannot be implemented with QVT 1.0. ---------------------------------- Abandoning EMOF (or Ecore) compliance in favour of perhaps CMOF seems unacceptable. Changing EMOF (or Ecore) to incorporate opposite roles is not possible because an EMOF specification cannot be extended to include the opposite role of every meta-model that will ever exist. Even if it was, there would be a substantial delay until meta-modelling tools adopted the change and a problem with poor standardisation and global non-interference of opposite rolenames. QVT must therefore support definition of non-navigable role names as part of a transformation. ModelMorf provided a very practical concrete syntax solution, whereby the reserved operation opposite(qualified-role-name) could be used as the missing opposite role-name wherever a forward role-name could be used. An upward compatible abstract syntax requires an additional is-opposite qualifier for each referred property. So for QVTCore::PropertyAssignment add isOpposite:Boolean[0..1] default false. QVTTemplate::PropertyTemplateItem add isOpposite:Boolean[0..1] default false. QVTRelation::Key add oppositeParts:Property[0..*] { composed } and possibly relax the lower bound for QVTRelation::Key add parts:Property[0..*] { composed } with the constraint that parts.size() + oppositeParts.size() > 0 Perhaps QVTOperational::Module needs an additional oppositeConfigProperty and QVTOperational::ContextualProperty needs an additional isOpposite too. ************************************************ Regards Ed Willink Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: "Willink, Ed" To: "'Pete Rivett'" , mof-qvt-ftf@omg.org Subject: RE: issue 11341 -- MOF QVT xTF issue Date: Wed, 12 Sep 2007 18:31:20 +0100 X-Mailer: Internet Mail Service (5.5.2656.59) Hi Pete I think we're discussing your navigability/ownership issue in so far as the original misunderstnadings have contributed to the EMOF representation limitation. The problem is that UML/CMOF has a nice general perspective with Classes and Associations almost independent; navigability has no impact on a Class. Projecting this on to EMOF hits a problem because an Association is realised by one or two Properties of Classes, depending on navigability. The target rolename is represented in Class's child Property. Therefore you need 2 mutually opposite Properties to represent the 2 role names, but you can only have one Property if the navigation is uni-directional. Therefore the non-navigable role name cannot be persisted in EMOF. When faced with a uni-directional association from A to B, an EMOF generator can create an A.b Property referring to B, but should not create the corresponding opposite B.a property since the model does not define a B.a property, just a B.a inverse role, so B.a is not present in the EMOF. A variant EMOF generator could create B.a to persist the "a" role name, but it would then need some additional "for-navigation-purposes-only" annotation for the 'compile-time' artefact. In Ecore, it might be appropriate to hijack transient and/or volatile. In 06-01-01 EMOF, there is no option. It would be great if you were correct. Can you provide a (small) EMOF file that demonstrates that you can persist a non-navigable opposite role? [An alternative solution for the concrete syntaxes might be to require a QVT typed-model loader to compute all possible inverse role names algorithmically so that these names become legal within a transformation. This is just auto-generating a name corresponding to every possible "opposite(qualified-property-name)". It doesn't change the requirement for the abstract syntax to be able to use missing opposite Properties.] Regards Ed Willink > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: 12 September 2007 14:02 > To: mof-qvt-ftf@omg.org > Subject: RE: issue 11341 -- MOF QVT xTF issue > > UML Infrastructure Basic (L0 compliance), which is the basis > for EMOF, does have Property::opposite which I think > addresses the issue. > This is also available in CMOF but is derived (calculated > using Associations). > > Furthermore I believe that OCL allows expressions to traverse > associations in either direction. > > I disagree with some of the assertions in the issue such as > "However EMOF provides only the (run-time) usage of the model > and so any EMOF (or Ecore) model generator must strip > non-navigable opposite roles." There is nothing at all in > EMOF that restricts it in that way. > > "Problem: some QVT transformations require names for > non-navigable opposite roles, but those names cannot be > present in layered multi-package EMOF meta-models." > I do not see why this is the case. > > "Changing EMOF (or Ecore) to incorporate opposite roles is > not possible because an EMOF specification cannot be extended > to include the opposite role of every meta-model that will > ever exist." > As above, EMOF already has the ability to represent opposite > roles. if "an EMOF specification" means a specific EMOF > metamodel then why would it need to be so extended? What > would be an example use case? > > While not directly related to the issue which is about EMOF > metamodels, people should also remember that, even if not > shown in diagrams, any CMOF metamodel must have names for all > Associations and the Properties at their ends. In the UML > metamodel case, there is a documented algorithm for > generating the names in the transformation from the UML > depiction to the formal CMOF rendition of metamodel. > > More generally we MUST get round to recognizing that UML 2 > Finalization changed the definition of 'navigable' and > divorced it from the ownership of Properties. This QVT issue > should be cast in terms of Property ownership and not > navigability. It's unfortunate that the UML spec (for tooling > and effort reasons) still relies on the convention of using > navigability arrows to show property ownership, and not the > new 'dot' notation introduced for the purpose. > > > Pete > > Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. > Hello House, 135 Somerford Road, Christchurch, BH23 3PY, UK > Tel: +44 (0)1202 491243 Fax: +44 (0)1202 491241 > http://www.adaptive.com > > > > > > > ________________________________ > > From: Juergen Boldt [mailto:juergen@omg.org] > Sent: Tuesday, September 11, 2007 7:37 PM > To: issues@omg.org; mof-qvt-ftf@omg.org > Subject: issue 11341 -- MOF QVT xTF issue > > > > > > From: "Ed Willink" > To: > Subject: Navigating non-navigable opposite roles > Date: Mon, 10 Sep 2007 22:09:16 +0100 > X-Mailer: Microsoft Outlook, Build 10.0.6822 > Thread-Index: Acfz7tg5J0ta0dFQSo+fc1K2g2wTGA== > > Hi > > ********************************************* > Issue : QVT 1.0 Section 7,8,9,10 : Navigating > non-navigable opposite roles > > UML models drawn with Rose allow an opposite > role to be defined for a > uni-directional role. This practice is common > but haphazard in UML Infrastructure, > EMOF, OCL and QVT specification diagrams. > > However EMOF provides only the (run-time) usage > of the model and so any > EMOF (or Ecore) model generator must strip > non-navigable opposite roles. > > QVT matches models at compile-time and matching > has no inherent need to > observe navigation constraints. This is amply > demonstrated by the Rel2Core > transformation that makes extensive use of, for > instance, the inverse Key to Class > relationship. > > ---------------------------------- > > Problem: some QVT transformations require names > for non-navigable opposite roles, > but those names cannot be present in layered > multi-package EMOF meta-models. > > The Rel2Core transformation of Section 10.3 > cannot be implemented with QVT 1.0. > > ---------------------------------- > > Abandoning EMOF (or Ecore) compliance in favour > of perhaps CMOF seems unacceptable. > > Changing EMOF (or Ecore) to incorporate > opposite roles is not possible because > an EMOF specification cannot be extended to > include the opposite role of every > meta-model that will ever exist. > > Even if it was, there would be a substantial > delay until meta-modelling tools > adopted the change and a problem with poor > standardisation and global > non-interference of opposite rolenames. > > QVT must therefore support definition of > non-navigable role names as part of a > transformation. ModelMorf provided a very > practical concrete syntax solution, > whereby the reserved operation > opposite(qualified-role-name) could be used as > the missing opposite role-name wherever a > forward role-name could be used. > > An upward compatible abstract syntax requires > an additional is-opposite qualifier > for each referred property. > > So for > > QVTCore::PropertyAssignment add > isOpposite:Boolean[0..1] default false. > > QVTTemplate::PropertyTemplateItem add > isOpposite:Boolean[0..1] default false. > > QVTRelation::Key add > oppositeParts:Property[0..*] { composed } > and possibly relax the lower bound for > QVTRelation::Key add parts:Property[0..*] { composed } > with the constraint that parts.size() + > oppositeParts.size() > 0 > > Perhaps QVTOperational::Module needs an > additional oppositeConfigProperty and > QVTOperational::ContextualProperty needs an > additional isOpposite too. > > ************************************************ > > Regards > > Ed Willink > > > Juergen Boldt > Director, Member Services > Object Management Group > 140 Kendrick St > Building A Suite 300 > Needham, MA 02494 > USA > > tel: +1 781 444 0404 x 132 > fax: +1 781 444 0320 > email: juergen@omg.org > www.omg.org > > > ******************************************************************************* Please consider the environment before printing this email. ******************************************************************************* This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may not be divulged to any third party without the express permission of the originator. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thales Research & Technology (UK) Limited. ******************************************************************************* Subject: RE: issue 11341 -- MOF QVT xTF issue Date: Wed, 12 Sep 2007 12:18:40 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 11341 -- MOF QVT xTF issue Thread-Index: Acf1Ysnz804Lj0CESoq7NwJj0WprwgABr8GQ From: "Pete Rivett" To: "Willink, Ed" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l8CJFNOQ027568 Hi Ed, One big assumption you're making is that an Association should be mapped to merely 2 opposite Properties in EMOF. This is not necessary or desirable (OMG has not standardized any CMOF-to-EMOF transformation though I have suggested it would be a good idea). A better approach IMHO is to map a CMOF Association to a Class in EMOF (this is in effect somewhat like an AssociationClass in full UML). This is a far better mapping of the association semantics into the limited world of EMOF (an instance of this class acts like a Link in UML/CMOF) and addresses many of the problems you identify). A separate question is one of metamodel design: I wonder why we need any 'unidirectional' associations/properties at all in metamodels. A metamodel can be regarded as the design model for the information structures of a 'modeling tool' (in its broadest sense) (in the same way as a UML model ahs that role for a business application). I would expect any modeling tool worth its salt to allow navigation in both directions (e.g. to support 'where used' or 'impact analysis' navigation/reporting). Hence, driven by the functionality of the end 'application' I would challenge the need for *any* unidirectionality of navigation. The argument for property ownership follows: if the only way of achieving the navigation through the defined programming interfaces (from EMOF) is to get the value of a property of a class then that property must be accessible from that class. [Though I should insert here that OMG has not yet defined a formal mapping from MOF2 (EMOF or CMOF) to Java - only to IDL. An initiative was started but got caught up in (IMHO) spurious legal concerns of the then-lead company and has not been picked up again.] One argument I often hear is the anthropomorphic one that a certain class should not 'know' about another class - which harks me back to the old days of 'pure' OO modeling. Which to be honest I just don't think applies here: in this case we are talking about the (information ) design of an application (a modeling tool) and it's that which needs to 'know' about both ends and navigate between them. See further comments below. Pete > -----Original Message----- > From: Willink, Ed [mailto:Ed.Willink@thalesgroup.com] > Sent: Wednesday, September 12, 2007 6:31 PM > To: Pete Rivett; mof-qvt-ftf@omg.org > Subject: RE: issue 11341 -- MOF QVT xTF issue > > Hi Pete > > I think we're discussing your navigability/ownership issue in > so far as the > original misunderstnadings have contributed to the EMOF representation > limitation. > > The problem is that UML/CMOF has a nice general perspective > with Classes > and Associations almost independent; navigability has no > impact on a Class. CMOF also has the possibility of Association ends/roles being owned by the Class. > > Projecting this on to EMOF hits a problem because an > Association is realised > by > one or two Properties of Classes, depending on navigability. > The target > rolename is > represented in Class's child Property. Therefore you need 2 mutually > opposite Properties > to represent the 2 role names, but you can only have one > Property if the > navigation > is uni-directional. Therefore the non-navigable role name cannot be > persisted in EMOF. > > When faced with a uni-directional association from A to B, an > EMOF generator > can create an A.b Property referring to B, but should not create the > corresponding > opposite B.a property since the model does not define a B.a property, > just a B.a inverse role, so B.a is not present in the EMOF. As I state above, there is no standard for an 'EMOF generator' - at least for Java. Just because the model does not define a property on B does not necessarily restrict the API from having one. Or at least a B.get_a() accessor. It is frequently the ce that a PSM (in this exampel Java) has more items generated than are in the PIM (in this case EMOF). A case in point is the need to generate Columns corersponding to Foreign Keys when generatign a relational database PSM from a UML PIM havign Associations (and maybe even a complete new Table if the Association is many-to-many). > > A variant EMOF generator could create B.a to persist the "a" > role name, but > it would > then need some additional "for-navigation-purposes-only" > annotation for the > 'compile-time' artefact. In Ecore, it might be appropriate to hijack > transient > and/or volatile. In 06-01-01 EMOF, there is no option. Why would this annotation be required? By 'for navigation only' do you mean that the property should be isReadOnly? If you're talking about 2 different implementations (compile time and runtime) then perhaps there should be 2 different generators? > > It would be great if you were correct. Can you provide a > (small) EMOF file > that > demonstrates that you can persist a non-navigable opposite role? As you know EMOF does not have the concept of roles or (non-)navigability. It seems like what you want is an EMOF representation of a CMOF/UML model which *does* have roles. In which case my recommended aproach would be to transform the association between A and B into a EMOF class called AB. > > [An alternative solution for the concrete syntaxes might be > to require a QVT > typed-model loader to compute all possible inverse role names > algorithmically so > that these names become legal within a transformation. This is just > auto-generating > a name corresponding to every possible > "opposite(qualified-property-name)". > It > doesn't change the requirement for the abstract syntax to be > able to use > missing > opposite Properties.] Does QVT not build on OCL which already allows this? > > Regards > > Ed Willink > > > -----Original Message----- > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > Sent: 12 September 2007 14:02 > > To: mof-qvt-ftf@omg.org > > Subject: RE: issue 11341 -- MOF QVT xTF issue > > > > UML Infrastructure Basic (L0 compliance), which is the basis > > for EMOF, does have Property::opposite which I think > > addresses the issue. > > This is also available in CMOF but is derived (calculated > > using Associations). > > > > Furthermore I believe that OCL allows expressions to traverse > > associations in either direction. > > > > I disagree with some of the assertions in the issue such as > > "However EMOF provides only the (run-time) usage of the model > > and so any EMOF (or Ecore) model generator must strip > > non-navigable opposite roles." There is nothing at all in > > EMOF that restricts it in that way. > > > > "Problem: some QVT transformations require names for > > non-navigable opposite roles, but those names cannot be > > present in layered multi-package EMOF meta-models." > > I do not see why this is the case. > > > > "Changing EMOF (or Ecore) to incorporate opposite roles is > > not possible because an EMOF specification cannot be extended > > to include the opposite role of every meta-model that will > > ever exist." > > As above, EMOF already has the ability to represent opposite > > roles. if "an EMOF specification" means a specific EMOF > > metamodel then why would it need to be so extended? What > > would be an example use case? > > > > While not directly related to the issue which is about EMOF > > metamodels, people should also remember that, even if not > > shown in diagrams, any CMOF metamodel must have names for all > > Associations and the Properties at their ends. In the UML > > metamodel case, there is a documented algorithm for > > generating the names in the transformation from the UML > > depiction to the formal CMOF rendition of metamodel. > > > > More generally we MUST get round to recognizing that UML 2 > > Finalization changed the definition of 'navigable' and > > divorced it from the ownership of Properties. This QVT issue > > should be cast in terms of Property ownership and not > > navigability. It's unfortunate that the UML spec (for tooling > > and effort reasons) still relies on the convention of using > > navigability arrows to show property ownership, and not the > > new 'dot' notation introduced for the purpose. > > > > > > Pete > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. > > Hello House, 135 Somerford Road, Christchurch, BH23 3PY, UK > > Tel: +44 (0)1202 491243 Fax: +44 (0)1202 491241 > > http://www.adaptive.com > > > > > > > > > > > > > > ________________________________ > > > > From: Juergen Boldt [mailto:juergen@omg.org] > > Sent: Tuesday, September 11, 2007 7:37 PM > > To: issues@omg.org; mof-qvt-ftf@omg.org > > Subject: issue 11341 -- MOF QVT xTF issue > > > > > > > > > > > > From: "Ed Willink" > > To: > > Subject: Navigating non-navigable opposite roles > > Date: Mon, 10 Sep 2007 22:09:16 +0100 > > X-Mailer: Microsoft Outlook, Build 10.0.6822 > > Thread-Index: Acfz7tg5J0ta0dFQSo+fc1K2g2wTGA== > > > > Hi > > > > ********************************************* > > Issue : QVT 1.0 Section 7,8,9,10 : Navigating > > non-navigable opposite roles > > > > UML models drawn with Rose allow an opposite > > role to be defined for a > > uni-directional role. This practice is common > > but haphazard in UML Infrastructure, > > EMOF, OCL and QVT specification diagrams. > > > > However EMOF provides only the (run-time) usage > > of the model and so any > > EMOF (or Ecore) model generator must strip > > non-navigable opposite roles. > > > > QVT matches models at compile-time and matching > > has no inherent need to > > observe navigation constraints. This is amply > > demonstrated by the Rel2Core > > transformation that makes extensive use of, for > > instance, the inverse Key to Class > > relationship. > > > > ---------------------------------- > > > > Problem: some QVT transformations require names > > for non-navigable opposite roles, > > but those names cannot be present in layered > > multi-package EMOF meta-models. > > > > The Rel2Core transformation of Section 10.3 > > cannot be implemented with QVT 1.0. > > > > ---------------------------------- > > > > Abandoning EMOF (or Ecore) compliance in favour > > of perhaps CMOF seems unacceptable. > > > > Changing EMOF (or Ecore) to incorporate > > opposite roles is not possible because > > an EMOF specification cannot be extended to > > include the opposite role of every > > meta-model that will ever exist. > > > > Even if it was, there would be a substantial > > delay until meta-modelling tools > > adopted the change and a problem with poor > > standardisation and global > > non-interference of opposite rolenames. > > > > QVT must therefore support definition of > > non-navigable role names as part of a > > transformation. ModelMorf provided a very > > practical concrete syntax solution, > > whereby the reserved operation > > opposite(qualified-role-name) could be used as > > the missing opposite role-name wherever a > > forward role-name could be used. > > > > An upward compatible abstract syntax requires > > an additional is-opposite qualifier > > for each referred property. > > > > So for > > > > QVTCore::PropertyAssignment add > > isOpposite:Boolean[0..1] default false. > > > > QVTTemplate::PropertyTemplateItem add > > isOpposite:Boolean[0..1] default false. > > > > QVTRelation::Key add > > oppositeParts:Property[0..*] { composed } > > and possibly relax the lower bound for > > QVTRelation::Key add parts:Property[0..*] { composed } > > with the constraint that parts.size() + > > oppositeParts.size() > 0 > > > > Perhaps QVTOperational::Module needs an > > additional oppositeConfigProperty and > > QVTOperational::ContextualProperty needs an > > additional isOpposite too. > > > > ************************************************ > > > > Regards > > > > Ed Willink > > > > > > Juergen Boldt > > Director, Member Services > > Object Management Group > > 140 Kendrick St > > Building A Suite 300 > > Needham, MA 02494 > > USA > > > > tel: +1 781 444 0404 x 132 > > fax: +1 781 444 0320 > > email: juergen@omg.org > > www.omg.org > > > > > > > > ************************************************************** > ***************** > Please consider the environment before printing this email. > ************************************************************** > ***************** > This email and any files transmitted with it are intended > solely for the use of > the individual or entity to whom they are addressed and may > not be divulged to > any third party without the express permission of the > originator. Any views > expressed in this message are those of the individual sender, > except where the > sender specifically states them to be the views of Thales > Research & Technology > (UK) Limited. > ************************************************************** > ***************** > > From: "Willink, Ed" To: "'Pete Rivett'" Cc: mof-qvt-ftf@omg.org Subject: RE: issue 11341 -- MOF QVT xTF issue Date: Thu, 13 Sep 2007 11:36:05 +0100 X-Mailer: Internet Mail Service (5.5.2656.59) Hi Pete Great, you cracked the principle, just some tedious details. Abstract Syntax --------------- The QVT abstract syntax defines a number of 'referredProperty' elements. I assumed these properties were owned by the source class and so might not have an opposite. You raise the interesting possibility that they're owned by an 'Association' Class that has a source property and a target property and so no problems with opposites. Concrete Syntax --------------- Your suggestion of mapping an Association to an EMOF Class solves the requirement for EMOF models that fully capture the QVT meta-models. However it would come as a big surprise to existing users. You take a top-down perspective and legitimately encounter no problems that cannot be solved by a responsible representation. Let us call this a specification-style model. I took a traditional bottom-up perspective trying to make the modelling style originally offered by, I think, Mariano at http://universalis.elibel.tm.fr/qvt/resources/qvt_metamodel.html and subsequently at http://www.omg.org/cgi-bin/doc?ptc/07-05-11 work. These and all Eclipse EMF working practices that I am familiar with expect Associations to be Properties/EReferences and observe the (informal) constraints: Property source == self.Property::class Property target == self.TypedElement::type The bottom-up style has a close correspondence to Java, each Property becomes a Java feature. Properties that are not to appear in Java for efficiency purposes should not appear in the model and so non-navigable information is suppressed. Let us call this an implementation-style model. MDA is all about separating specification and implementation, so I guess we should do precisely that. Perhaps QVT should publish both styles of model. An implementation-style model as-is with navigation honoured and opposite roles lost. A specification-style model that captures the full model and can be transformed into the implementation-style model. Since this is a transformation away from what tools expect, we could choose how to elaborate: a) add an xmi:Extension to Property to provide the opposite role name. This captures the model in conventional style but does not support the requirement for the opposite Property to exist for referencing by the abstract syntax -- doesn't work. b) introduce Association classes, so that: non-association Class Property.type is a PrimitiveType association Class Property.type is not a PrimitiveType the navigation invariants are then Property source == self.Property::class.'other-end'.TypedElement::type Property target == self.TypedElement::type -- works, but without any explicit EMOF support, it requires a stylised usage. It would be beneficial to introduce an EMOF::Association as a further form of Classifier. ---------------------------------------------------------------------------- Your solution works, but it's just going to surprise some people. QVT need only offer QVT.mdl that fully captures the model. However the current ZIP offers much more, mostly as Ecore, and my reworked ZIP offers yet more as coherent MDL, Ecore, EMOF with options for all packages in one file, or all classes in a single package. If QVT continues to offer more than just QVT.mdl, it could provide (for each package) XXX.xml (the specification-style EMOF with association classes) XXX.navigable.xml (the implementation-style EMOF with all opposites) XXX.minimal.xml (the implementation-style EMOF with only navigable opposites) Existing users wanting an implementation model can use XXX.minimal.xml. Existing modelling tools wanting a specification model can use XXX.navigable.xml. New tools should use XXX.xml and generate their own internal representation from it. Tools should be able to work with either style of model since specification-style association classes are easily synthesised from or flattened into implementation-style relationships. Since these issues affect only the courtesy ZIP the above content does not affect the ongoing QVT 1.0 vote. ---------------------------------------------------------------------------- -- Your solution nullifies my suggestions/requirements, and is totally in keeping with "referredProperty: Property [1] The EMOF Property that identifies the slot that is being constrained." however, given the difficulty I/we had in reaching your solution, it would be beneficial if QVT offered some additional editorial assistance. QVT should clearly state that the specification-style invariant Property source == self.Property::class.'other-end'.TypedElement::type is true for any referredProperty. The spelling of 'other-end' would benefit from standardisation. The association class is so stylised that an EMOF::Association variant of Classifier could enforce the presence of exactly two Property properties with non-PrimitiveType types, and provide a getOtherEnd() operation? This clearly should be in EMOF not QVT. In the absence of an EMOF standard, tools could have to detect arbitrary classes with 2 properties. However, since MOF neglected to define an EMOF namespace, there is no EMOF standard representation. (My reworked ZIP uses http:://schema.omg.org/spec/QVT/1.0/emof.xml and http:://schema.omg.org/spec/QVT/1.0/primitivetypes.xml to avoid prejudicing MOF decisions.) http:://schema.omg.org/spec/QVT/1.0/primitivetypes.xmlhas to do an intuitive package merge to locate OCL's Real that is 'provided by the OCL standard library'. http:://schema.omg.org/spec/QVT/1.0/emof.xml is not necessarily precisely EMOF and so could introduce an Association as a base for all associations. These ideas are necessary to publish coherent EMOF models. It is desirable but not mandatory to describe the ideas in the QVT spec. Any suggestions on how the ZIP might be structured? I already have a variant Rose UML to Ecore importer to sort out "{ordered}" correctly. A further variant to support specification-style should not be hard. Regards Ed Willink > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: 12 September 2007 20:19 > To: Willink, Ed; mof-qvt-ftf@omg.org > Subject: RE: issue 11341 -- MOF QVT xTF issue > > Hi Ed, > > One big assumption you're making is that an Association > should be mapped to merely 2 opposite Properties in EMOF. > This is not necessary or desirable (OMG has not standardized > any CMOF-to-EMOF transformation though I have suggested it > would be a good idea). A better approach IMHO is to map a > CMOF Association to a Class in EMOF (this is in effect > somewhat like an AssociationClass in full UML). This is a far > better mapping of the association semantics into the limited > world of EMOF (an instance of this class acts like a Link in > UML/CMOF) and addresses many of the problems you identify). > > A separate question is one of metamodel design: I wonder why > we need any 'unidirectional' associations/properties at all > in metamodels. A metamodel can be regarded as the design > model for the information structures of a 'modeling tool' (in > its broadest sense) (in the same way as a UML model ahs that > role for a business application). I would expect any modeling > tool worth its salt to allow navigation in both directions > (e.g. to support 'where used' or 'impact analysis' > navigation/reporting). Hence, driven by the functionality of > the end 'application' I would challenge the need for *any* > unidirectionality of navigation. The argument for property > ownership follows: if the only way of achieving the > navigation through the defined programming interfaces (from > EMOF) is to get the value of a property of a class then that > property must be accessible from that class. [Though I should > insert here that OMG has not yet defined a formal mapping > from MOF2 (EMOF or > CMOF) to Java - only to IDL. An initiative was started but > got caught up in (IMHO) spurious legal concerns of the > then-lead company and has not been picked up again.] > > One argument I often hear is the anthropomorphic one that a > certain class should not 'know' about another class - which > harks me back to the old days of 'pure' OO modeling. Which to > be honest I just don't think applies here: in this case we > are talking about the (information ) design of an application > (a modeling tool) and it's that which needs to 'know' about > both ends and navigate between them. > > See further comments below. > > Pete > > > > > -----Original Message----- > > From: Willink, Ed [mailto:Ed.Willink@thalesgroup.com] > > Sent: Wednesday, September 12, 2007 6:31 PM > > To: Pete Rivett; mof-qvt-ftf@omg.org > > Subject: RE: issue 11341 -- MOF QVT xTF issue > > > > Hi Pete > > > > I think we're discussing your navigability/ownership issue > in so far > > as the original misunderstnadings have contributed to the EMOF > > representation limitation. > > > > The problem is that UML/CMOF has a nice general perspective with > > Classes and Associations almost independent; navigability has no > > impact on a Class. > > CMOF also has the possibility of Association ends/roles being > owned by the Class. > > > > Projecting this on to EMOF hits a problem because an Association is > > realised by one or two Properties of Classes, depending on > > navigability. > > The target > > rolename is > > represented in Class's child Property. Therefore you need 2 > mutually > > opposite Properties to represent the 2 role names, but you can only > > have one Property if the navigation is uni-directional. > Therefore the > > non-navigable role name cannot be persisted in EMOF. > > > > When faced with a uni-directional association from A to B, an EMOF > > generator can create an A.b Property referring to B, but should not > > create the corresponding opposite B.a property since the model does > > not define a B.a property, just a B.a inverse role, so B.a is not > > present in the EMOF. > > As I state above, there is no standard for an 'EMOF > generator' - at least for Java. Just because the model does > not define a property on B does not necessarily restrict the > API from having one. Or at least a > B.get_a() accessor. It is frequently the ce that a PSM (in > this exampel > Java) has more items generated than are in the PIM (in this > case EMOF). > A case in point is the need to generate Columns corersponding > to Foreign Keys when generatign a relational database PSM > from a UML PIM havign Associations (and maybe even a complete > new Table if the Association is many-to-many). > > > > > A variant EMOF generator could create B.a to persist the "a" > > role name, but > > it would > > then need some additional "for-navigation-purposes-only" > > annotation for the > > 'compile-time' artefact. In Ecore, it might be appropriate > to hijack > > transient and/or volatile. In 06-01-01 EMOF, there is no option. > > Why would this annotation be required? By 'for navigation > only' do you mean that the property should be isReadOnly? > If you're talking about 2 different implementations (compile time and > runtime) then perhaps there should be 2 different generators? > > > > > It would be great if you were correct. Can you provide a > > (small) EMOF file > > that > > demonstrates that you can persist a non-navigable opposite role? > > As you know EMOF does not have the concept of roles or > (non-)navigability. > It seems like what you want is an EMOF representation of a > CMOF/UML model which *does* have roles. In which case my > recommended aproach would be to transform the association > between A and B into a EMOF class called AB. > > > > > [An alternative solution for the concrete syntaxes might be > to require > > a QVT typed-model loader to compute all possible inverse role names > > algorithmically so that these names become legal within a > > transformation. This is just auto-generating a name > corresponding to > > every possible "opposite(qualified-property-name)". > > It > > doesn't change the requirement for the abstract syntax to > be able to From: "Willink, Ed" To: mof-qvt-ftf@omg.org Subject: RE: issue 11341 -- MOF QVT xTF issue Date: Tue, 18 Sep 2007 10:26:33 +0100 X-Mailer: Internet Mail Service (5.5.2656.59) Hi Mariano, Sreedhar, Pete Issue Resolved. No need for abnormal EMOF or 'association' classes. No need to add explanatory OCL Property ownership constraints. Just a requirement for the UML to EMOF generator to represent the specification model. And perhaps editorial notes to stress: Since transformation pattern matching is blind to navigation constraints, conforming implementations must use a meta-model representation that supports bidirectional navigation for all associations with a Property at both ends. Anonymous opposite roles should be named in accordance with the OCL 2.0 Section 7.5.3 policy. Implementations may need to adopt a disambiguation mechanism when OCL 2.* defines one. ------------------------------------------------------------------ I experimented with various forms of EMOF generation. Using an 'association' class in the EMOF meta-model didn't really help. For code generation purposes an implementation-style EMOF (Ecore) is required in which only navigable Property elements are expressed. An approximation to this is generated by the Eclipse Rose to Ecore importer. It is no use for transformation meta-models since opposites are missing. For transformation meta-models, full navigability is required, and is readily generated by providing both Property ends for every association. This is bloated for code generation, and loses the original navigability constraints. For pedantic model accuracy, it is necessary to have both Property ends and find some way of indicating what is navigable. A variety of ad hoc mechanisms could be used such as 'association' class naming, 'association' class abstract-ness, a bogus 'association' class property, xmi:Extensions, ... A more relevant option is to (ab)use opposite to use what I will call a semi-opposite; the opposite property is present in navigable directions and omitted in a non-navigable direction. It is not clear from UML Infrastructure whether a semi-opposite is legal; there is no OCL constraint prohibiting it, just text implying reciprocity of opposites. If semi-opposite is used to denote navigability, then this can be expressed directly between Property elements of their container classes rather than of 'association' classes. ------------------------------------------------------------------ Therefore QVT could supply XXX.xml - using semi-opposite Property elements as necessary to exactly represent the navigability. XXX.max.xml - with all associations maximised to full navigability (2 mutually opposite Property elements always). XXX.min.xml - with all associations minimised to drawn navigability (a single Property element if uni-directional). XXX.xml is trivially transformed by expanding/contracting the semi-opposites. It is potentially useable by both specification and implementation-biased tools. XXX.max.xml is suitable for use in transformation transformations such as Rel2Core. It may be used by tools that consider the semi-opposites in XXX.xml illegal. XXX.min.xml is suitable for transformation tool code generation. I've generated all these. I'll post them off-list, as soon as I've verified that Rel2Core and FlatQVT.max.xml are consistent, after allowing for a couple of name evolutions. I'll make the revised Eclipse Rose UML importer and subsequent QVT generation tools on the Eclipse GMT/UMLX update site. Regards Ed Willink ******************************************************************************* Please consider the environment before printing this email. ******************************************************************************* This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may not be divulged to any third party without the express permission of the originator. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thales Research & Technology (UK) Limited. Ed Willink