Community
Participate
Working Groups
/org.eclipse.qvtd.xtext.qvtimperative.tests/src/org/eclipse/qvtd/xtext/qvtimperative/tests/SimpleUML2RDBMS/SimpleUML2RDBMS.ecore has Property.oppositeUpper and Property.oppositeRoleName EAnnotations to define a name and upper bound for the non-navigable side-to-middle opposites. Other models do not, which means that an implicit opposite is created whose name is the target type and whose type is Bag(target-type). A Bag is at best unhelpful for something that is precisely 1. This is a particular problem for: /org.eclipse.qvtd.build.etl.tests/src/org/eclipse/qvtd/build/etl/tests/UpperToLower/SimpleGraph2Graph.ecore where both sides are the same model and so two implicitly named opposites with the same name are required. The Pivot synthesis creates both, preferring to reify the ambiguity for the user, although the ambiguous message while correct is far from obvious. Conclusion: middle model elements must have Property.oppositeUpper and Property.oppositeRoleName EAnnotations. a) automated synthesis should create them b) manual synthesis should create them c) QVTimperative.ocl should diagnose them
(In reply to Ed Willink from comment #0) > Conclusion: middle model elements must have Property.oppositeUpper and > Property.oppositeRoleName EAnnotations. This is not enough. The DomainAnalysis for Bug 464444 needs to identify domains by exploiting the package content uniqueness at the ends of Middle-to-Source and Middle-to-Target properties. For Homogenous transformations these are not unique at all and while some lexical ordering heuristics could exploit the fortuitously consistent ordering of name pairs such as "source"/"target", "from"/"to", "left"/"right", "node1"/"node2", fortune is not a good basis for design. Using UML, the middle model domain-crossing properties could have <<MiddleToSource>> or <<MiddleToTarget>> stereotypes (exact spelling to be decided). Using Ecore, we are probably forced into some more EAnnotations (spelling to be decided). The Pivot model should not rely on Stereotypes or Annotations for first class metamodeling, but the Pivot metamodel should not be bloated by QVT specific support. Perhaps QVTcoreBase adds derived Middle2SourceProperty and Middle2TargetProperty classes. Perhaps more flexibly we have a derived CoreProperty that can identify containing/referred domains and also support the cache line index and so make MiddlePropertyCallExp obsolete. The Pivot model is derived from UML/Ecore so it should not be too hard to ensure that the exiensibility is available to support CoreProperty rather than Property for QVT.
Branch hhoyos/463969 addes the Property.oppositeUpper and Property.oppositeRoleName EAnnotations to the test case metamodels, and automatically craetes the annotations in the QVTrToQVTc treansformation. Somewhere in the documentation the need for this annotations must be stated. Can the existance of the annotations be validated via OCL?
(In reply to Horacio Hoyos from comment #2) > Branch hhoyos/463969 addes the Property.oppositeUpper and > Property.oppositeRoleName EAnnotations to the test case metamodels, and > automatically craetes the annotations in the QVTrToQVTc treansformation. All manual examples need manual fixing. > Somewhere in the documentation the need for this annotations must be stated. > Can the existance of the annotations be validated via OCL? Bug 464693 calls for QVTimperative.ocl to validate automatically. Users should never need to know since users should never create middle metamodels.
(In reply to Ed Willink from comment #3) > All manual examples need manual fixing. Surprisingly the unfixed metamodels have survived, but attempting to strengthen the region analysis identifies that the QVTc SimpleUML2RDBMS test is relying on wacky code.
(In reply to Ed Willink from comment #4) > Surprisingly the unfixed metamodels have survived, but attempting to > strengthen the region analysis identifies that the QVTc SimpleUML2RDBMS test > is relying on wacky code. No. Bug 464693 identifies Upper2Lower as a bad test. Until the subtle distinctions between isConditional and isRequired are resolved all sorts of things seem wacky; an isRequired navigation from a !isRequired source implies that the target must be treated as isConditional.
