Community
Participate
Working Groups
I'm trying to get the QVTr support for non-navigable expressions to work. For instance in c.key.part key may be an unnavigable opposite. The AbstractEnvironment.findNonNavigableAssociationEnds hints at some support for this, but it is never called. It would appear that AbstractOCLAnalyzer.simpleNameCS needs an additional branch following the failure of lookupProperty to try perhaps lookupOppositeProperty and synthesize the appropriate opposite operation call. Is this an oversight or just the first trace of some planned work?
Navigation of non-navigable and/or unnamed associations ends is applicable only to CompleteOcl, because EMOF does not have associations. Also, Ecore doesn't have the capacity to express an eOpposite that is not navigable. You will find that the UMLEnvironment makes use of this facility.
There seems to be an (Essential) OCL AST specification bug here. The only indication that Eseential OCL might not support full association navigation is (top of page 172) "Note - It is expected that further revisions of this specification will provide explicitly the complete set of well-formedness rules and additional operations that apply to Core::Basic - to replace the lazy re-interpretation statement we are using here." The OCL CS defines an opposite navigation capability, but the AST has only a PropertyCallExp that must refer to the forward Property. If the opposite is non-navigable, that Property does not exist and cannot be referenced. [Ecore of course has the same limitation on EReference.] Perhaps the problem is only showing up now that Sreedhar Reedy produced such a complicated multi-package QVTr example in which non-navigables are used in earnest. Either PropertyCallExp needs an additional isOpposite attribute, or an alternative OppositePropertyCallExp class must be introduced. ??? also a problem for TupleLiteralPart.attribute ???
(In reply to comment #2) > There seems to be an (Essential) OCL AST specification bug here. I don't think so. > Either PropertyCallExp needs an additional isOpposite attribute, or an > alternative OppositePropertyCallExp class must be introduced. No. The non-navigable end is a real Property, owned, in UML (hence in CompleteOcl), by the Association. The PropertyCallExp already does have the Property that it needs to reference. > ??? also a problem for TupleLiteralPart.attribute ??? How so? The TupleType owns the Property that is referenced by the literal-part. The EssentialOcl adaptation adds a generalization from TupleType to Class for this reason, so that the TupleType may own attributes.
Please help me here. I'm trying to make something work in QVTr that extends Essential OCL, not UML. I cannot find a way to express the PropertyCall AST of a Property that is only implicitly defined in Essential MOF (the opposite name is deduced by initialLower()). QVTr requires it. Essential OCL appears to support it. Essential MOF doesn't define it. Which of QVTr/OCL/EMOF needs fixing? I first tried to modify the QVTr AST to capture oppositeness. This was klunky and didn't resolve OCL AST issues. I then flattened the EMOF models to include all the opposites explicitly. This was unpleasant, because it required variant EMOF and Essential OCL meta-models that included all the opposites implicitly and explicitly defined by QVT. At EclipseCon my suggestion of carrying the lost opposite role name meta-model information as Comment/EAnnotation was agreed with Ed Merks and has been implemented in Ecore. So we have EMOF/Ecore models that do not provide an opposite Property/EReference that can be referenced. It seems that either a synthetic OppositeProperty must provide the missing definition, or the references must be modified to indicate the need to invert them. A synthetic OppositeProperty is unpleasant since it must extend Property but violates inherited constraints (e.g. self.opposite.opposite == self, self.container.ownedProperties includes self). Modified references are tractable since there are few meta-model references. So my preferred solution would be: Add PropertyCallExp.isOpposite : Boolean with default value false, to denote an opposite reference. Next best seems to be: Add OppositePropertyCallExp inheriting from PropertyCallExp. QVTr could add OppositePropertyCallExp. Essential OCL (or QVTr) could add PropertyCallExp.isOpposite. ----------------- I'm trying to identify whether this is a limitation that OCL or QVTr should solve. It seems that QVTr is using Essential OCL functionality that is specified and so should be available. ----------------- At the parser implementation level, AbstractOCLAnalyzer.simpleNameCS() has to be augmented for QVTr at least. A full rewrite in AbstractQVTrAnalyzer is probably possible. A more modular upgrade partitioning simpleNameCS() into a number of overrideable steps would be better. ----------------- At the execution implementation level, an efficient mechanism to traverse opposite properties is needed. EMF support for total cross-referencing could be used. Selective maintenance of Adapters for the inverse of only those properties actually used in opposite directions would incur smaller costs. ------------------ TupleLiteralPart.attribute composition is a different QVTr/OCL issue. I don't think anybody has used it and so nobody has debugged it or even understands it.
(In reply to comment #4) > Please help me here. > > I'm trying to make something work in QVTr that extends Essential OCL, not UML. > I cannot find a way to express the PropertyCall AST of a Property that is only > implicitly defined in Essential MOF (the opposite name is deduced by > initialLower()). I guess that I'm not convinced that EMOF does implicitly define any such property. CompleteOcl defines an implicit name (actually, the UML does) for an unnamed association end. But that's a different question. > QVTr requires it. Essential OCL appears to support it. Essential MOF doesn't > define it. Which of QVTr/OCL/EMOF needs fixing? I think that both the OCL spec and QVT need fixing. OCL needs to clarify that the semantics of Associations don't apply to the EssentialOcl because EMOF does not have associations. It does explicitly exclude AssociationClass calls and the dependencies on qualifiers and navigation source in Section 13. It also needs to exclude non-navigable association-end navigation because, like the concept of navigation source, it requires the existence of two association-end properties that are linked together, either by an Association or by the opposite meta-attribute. The non-navigable end simply doesn't exist in EMOF because there is nothing that would contain it or link it to the end that is navigable. QVT needs to be fixed because it depends on an EMOF construct that doesn't exist. > I first tried to modify the QVTr AST to capture oppositeness. This was klunky > and didn't resolve OCL AST issues. > > I then flattened the EMOF models to include all the opposites explicitly. This > was unpleasant, because it required variant EMOF and Essential OCL meta-models > that included all the opposites implicitly and explicitly defined by QVT. > > At EclipseCon my suggestion of carrying the lost opposite role name meta-model > information as Comment/EAnnotation was agreed with Ed Merks and has been > implemented in Ecore. So we have EMOF/Ecore models that do not provide an > opposite Property/EReference that can be referenced. Has this been implemented? That's news to me; I always find out about cool new EMF features indirectly. Does the annotation contain an EReference that references the navigable end as its eOpposite? Then, you would have the EReference that you need for the PropertyCallExp to link to. > It seems that either a synthetic OppositeProperty must provide the missing > definition, or the references must be modified to indicate the need to invert > them. But, how do you know which real property is the implicit opposite of the fictional non-navigable property? > A synthetic OppositeProperty is unpleasant since it must extend Property but > violates inherited constraints (e.g. self.opposite.opposite == self, > self.container.ownedProperties includes self). But, you don't have an EMOF "association" unless you have two Property instances that reference each other as opposite. Otherwise, there's nothing that restricts the number of implicit opposites of a real Property to just one. I don't see how this makes sense in EMOF. > Modified references are tractable since there are few meta-model references. > > So my preferred solution would be: > > Add PropertyCallExp.isOpposite : Boolean with default value false, to denote an > opposite reference. > > Next best seems to be: > > Add OppositePropertyCallExp inheriting from PropertyCallExp. > > QVTr could add OppositePropertyCallExp. > Essential OCL (or QVTr) could add PropertyCallExp.isOpposite. If QVTr really thinks that this construct exists, then perhaps it needs to make it work, somehow. MDT OCL's UML environment has no trouble implementing association semantics using the current AST, and it uses the AbstractEnvironment::findNonNavigableAssociationEnds API to do it. All that is needed is for the QVTr environment implementation to create a Property instance that the PropertyCallExp can reference, then implement the navigation using EMF's reference-inversion utilities (as UML did). > ----------------- > > I'm trying to identify whether this is a limitation that OCL or QVTr should > solve. It seems that QVTr is using Essential OCL functionality that is > specified and so should be available. I don't believe that EssentialOcl can specify these semantics. As I mentioned above, I think a clarfication is required in the OCL spec. > ----------------- > > At the parser implementation level, AbstractOCLAnalyzer.simpleNameCS() has to > be augmented for QVTr at least. A full rewrite in AbstractQVTrAnalyzer is > probably possible. A more modular upgrade partitioning simpleNameCS() into a > number of overrideable steps would be better. This may be useful in any case. Feel free to contribute a patch! > ----------------- > > At the execution implementation level, an efficient mechanism to traverse > opposite properties is needed. EMF support for total cross-referencing could be > used. Selective maintenance of Adapters for the inverse of only those > properties actually used in opposite directions would incur smaller costs. Yes, the UML implementation has the advantage of having the CacheAdapter impose the ECrossReferenceAdapter behaviour on it. :-) > ------------------ > > TupleLiteralPart.attribute composition is a different QVTr/OCL issue. I don't > think anybody has used it and so nobody has debugged it or even understands it. Well, I certainly didn't understand the issue, because you didn't say what it is. ;-)
Opposite role name annotations were fixed in bug 229998. This was simple and orthogonal enough to be a very late contribution to Ganymede. EMOFExtendedMetaData defines some new constants for reserved Comment/EAnnotation names and the EMOF Load/Save support provides Comment to EAnnotation conversion. EMOF Comments were previously not supported at all. There is no new Java API; just a Comment within Comment policy. See /cvsroot/modeling org.eclipse.m2m/org.eclipse.qvt.declarative/plugins/org.eclipse.qvt/model/traditionalEcore/EssentialOCL.ecore and org.eclipse.m2m/org.eclipse.qvt.declarative/plugins/org.eclipse.qvt/model/traditionalEMOF/EssentialOCL.xml for examples. Thanks for the readiness to accept a simpleNameCS refactoring. I think I'll introduce QVTRelation.OppositePropertyCallExp deriving from EssentialOCL.PropertyCallExp for now. This ensures that QVTr models that don't use non-navigable opposites will be 100% QVT 1.0 AST compliant. Models that do will use non-compliant extensions for what QVTr doesn't adequately define anyway. MDT OCL only needs to provide hooks for derived parsing and validation and interpretation variation.
Sorry for the delayed reply. (In reply to comment #6) > Opposite role name annotations were fixed in bug 229998. This was simple and > orthogonal enough to be a very late contribution to Ganymede. I see. Cool. Is this oppositeRoleName something that's in progress for EMOF 2.1, then? Or is it QVT that is defining this tag? > Thanks for the readiness to accept a simpleNameCS refactoring. No problem. We should be able to process a patch quite swiftly (I'm away next week, though). > I think I'll introduce QVTRelation.OppositePropertyCallExp deriving from > EssentialOCL.PropertyCallExp for now. This ensures that QVTr models that don't Sounds like a good plan. > MDT OCL only needs to provide hooks for derived parsing and validation and > interpretation variation. Right. Let's make that a priority for M2. After that, there will be some old generic-operations patches that I need to process.
> Is this oppositeRoleName something that's in progress for EMOF 2.1, then? Good point. I've just submitted a MOF issue to seek endorsement of the practice. > Or is it QVT that is defining this tag? No. It's EMF's EMOFExtendedMetaData that's offering this solution, and M22/QVT Declarative that's offering meta-models that carry this extra information.
Created attachment 111911 [details] Refactoring of AbstractOCLAnalyzer.simpleNameCS The attached makes AbstractOCLAnalyzer.simpleNameCS more modular and readable and provides an opportunity for AbstractQVTrAnalyzer to add support for opposite property resolution. [I've hand edited out the change for InvOrDefCS list rather than linked-list, so I hope the patch still works.]
(In reply to comment #9) > > [I've hand edited out the change for InvOrDefCS list rather than linked-list, > so I hope the patch still works.] I'm sure I'll be able to make it work, if it doesn't. Thanks!
Assigning to process the contribution.
Comment on attachment 111911 [details] Refactoring of AbstractOCLAnalyzer.simpleNameCS Patch committed. I merged the several changes since version 1.12 of the file and added doc comments for the new API.
Refactoring committed, with a few tweaks to conform to the OCL coding style and changes mentioned in comment 12.
Closing after over 18 months in resolved state.
