eclipse-qvt-oml-bot
commented
1 week ago By Ed Willink on Jun 18, 2019 04:48
For QVTd, there are multiple pre-execution input model analyses that can be usefully merged into a single pass.
- allInstances/objectsOfKind => per-relevant type element caches
- unnavigable opposites => per-relevant references opposite lookups
- containment hierarchy traversal => faster eContents()
- proxy resolution => transitive models
Most of the above could be beneficially performed for QVTo too.
See org.eclipse.qvtd.runtime.evaluation.EClassAnalysis for the optimized meta-structures.
| --- | --- | | Bugzilla Link | 547990 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 06, 2019 06:41 EDT | | Modified | Jun 18, 2019 04:48 EDT | | See also | 533565, 547993 | | Reporter | Ed Willink |
Description
Created attachment 278833\ Repro project
Following on from the discussion in Bug 533565 where the prevailing lazy-resolve-proxy rather than eager-resolveAll was advocated ....
The attached project contains a trivial transformation that maps input EClasses to output EClasses with a modified name.
The example model comprises three classes; My1 extends My2 extends My3. Each is in its corresponding My1.ecore file.
Execution of the ResolveBug.launch using My1.ecore gives an output comprising only a conversion of My1; My2 and My3 conversions are missing.
Problem 1. If My1.ecore is loaded and it references My2.ecore and My3.ecore, are My2 and My3 part of the QVTo Model loaded wrt the ecoreIn Model Parameter?
If they are not, then QVTo must ignore them completely since QVTo provides no alternative Extent in which they could exist. Clearly unnacceptable, so since QVTo has no concept of partitioned models, the multi-file Ecore XMI must be treated as a single composite input.
QVT 1.3 added section 8.1.3 where "8.1.3.3 Models A Model comprises a forest of model elements (objects) with each tree defined by MOF containment relationships. For many applications, a single root, and its containment tree, rather than a forest is sufficient.". Multi-file XMI or multi-rooted XMI are two alternative ways of populating the forest roots.
Problem 2. If composite models are to be handled how can Eclipse QVTo work on a partial model? It cannot, since it is not normally possible to tell how many additional objects and what type of objects lie on the other side of an unresolved proxy. There is no alternative to an EcoreUtil.resolveAll to ensure that all the objects in the composite model are available.
It seems the only question is whether to extend the lazy policy to resolveAll for objectsOfKind or accept that resolveAll is inevitable allowing a robust eager resolveAll rather than a fragile lazy resolve some.
As an experiment, I instrumented
/org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/qvto/UML2EcoreAnalyzer.qvto
invoked within
/org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/GeneratePivotModel.mwe2
(Instrumentation involved a resolveProxy log in EcoreUtil.resolve and commenting out the validation that would also resolve everything.)
The transformation involves a 7 resource input model including UML. A total of 445 lazy proxy resolutuions were required of which 428 were distinct. When I added an eager resolveAll, exactly the same number of eager proxy resolutions occurred.
The subsequent
/org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/qvto/UML2EcoreAnalyzer.qvto
involed precisely 0 proxy resolutions in both cases.
This suggests that if there are proxies, they are going to get resolved anyway. Might as well do it early. The overhead of a resolveAll is a full model traversal with eIsProxy() tests. Redundant resolution is probably not a cost.
:compression: ResolveBug.zip