eclipse-qvtd-bot
commented
18 hours ago By Ed Willink on Apr 12, 2015 05:19
(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 <
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.
| --- | --- | | Bugzilla Link | 463969 | | Status | NEW | | Importance | P3 normal | | Reported | Apr 06, 2015 10:04 EDT | | Modified | Sep 15, 2017 03:12 EDT | | Blocks | 522340 | | Reporter | Ed Willink |
Description
/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