Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
QVTd Traces and Invocations
The QVT specification of QVTc trace class synthesis for QVTr transformations is very thin. This document considers the real requirements.
This working document takes over from
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=515327 [qvtc] Support overrides / refines
- QVTd_Relation_Overriding
Contents
QVTr specification oversights
Overrides
QVTc has no support for overriding and so overriding must be synthesized during the QVTr2QVTc transformation.
A simple synthesis requires two actions.
- callee-side, each overridden relation has an AND of when-not-predicate on each of the transitively overriding relations
- caller-side, each call of an override has an OR of all possible overriding relations
Non-top Relations
QVTc has no support for non-top mappings consequently a non-trivial synthesis of an X_Y mapping is suggested to accommodate the Y relation after X. This scales quadratically when X or Y has overrides.
Better to synthesize an invocation class produced by the caller and consumed by the callee. To accommodate overriding a hierarchy of invocation classes and interfaces is needed.
Statuses
A when/where predicate may involve complex boolean expressions involving the value of many RelationCallExp instances.
This can be accommodated if the trace class includes a status property denoting success/fail/not-ready. The run-time execution must ensure that a fail status is assigned implicitly; success can be assigned explicitly.
Implicit when's
RelationCallExp's in when predicates are synchronous
- invoker starts
- invoker initiates when calls
- invoker waits for when returns
- invoker resumes
RelationCallExp's elsewhere in Boolean expressions such as
where { if A(x,y) then B(x,y) else C(x,y) endif; }
make a synchronous (implicit-when) call of A(x,y).
Not a particular problem once the assumption of trivial predicates is removed.
CollectionTemplateExp traces
QVTr2QVTc omits CollectionTemplates. It is therefore unclear whether the collection and/or members and rest should be traced.
A fundamental requirement is that the trace should facilitate an incremental re-execution.
The members and rest can be deduced from the overall collection or vice-versa. So there might be a free design choice.
However anonymous members/rest are only interesting wrt existence rather than value, so members/rest offers significant space saving opportunities.
Temporarily the overall collection is more consistent with ObjectTemplateExp tracing.
Trace Packaging
The QVTr specification defines the basic naming and typing of trace Classes and Properties. It ignores Packages, Models and URIs.
Packages, Models and URIs are also a bit troublesome for QVTr/QVTc too. Eclipse QVTr therefore simplifies a Transformation to be just a Class and to require a conventional Model/Package hierarchy ancestry.
Trace Property opposites
OCL's opposites are fundamental to the reification of traceability by QVTc trace classes. However opposites are ignored by the trace class synthesis.
The opposite naming is trivial.
The opposite multiplicity requires careful consideration of whether the non-opposite occurs below a 1:N navigation.
For edogeneous transformations, a further complication arises with domain identification.
The Eclipse QVTr trace therefore has Ecore EAnnotations to fully characterize the opposites.