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.
Difference between revisions of "QVTd Traces and Invocations"
(→QVTr specification oversights) |
(→Eclipse QVTr solutions) |
||
Line 78: | Line 78: | ||
==Eclipse QVTr solutions== | ==Eclipse QVTr solutions== | ||
− | + | The synthesized trace comprises | |
+ | * a Model | ||
+ | * a Package per (typically one) Transformation | ||
+ | * a trace Class per Relation/Mapping | ||
+ | * a trace Property per traced Variable | ||
+ | * a status Property for tested progress | ||
+ | * an invocation Class per non-top Relation | ||
+ | * trace/invocation interface Classes for overriding Relation/Mapping | ||
+ | * infrastructure Classes | ||
− | ===Trace classes | + | The Package URI is configurable. |
+ | |||
+ | Package, Class, Property names are derived from Transformation, Relation, Variable names. | ||
+ | |||
+ | ===Invocation classes=== | ||
+ | |||
+ | Each non-top not-overridden relation uses an invocation class to reify its invocation in QVTc. The calling mapping realizes an invocation instance with a property for each root variable. The called mapping executes in response to the invocation instance. | ||
+ | |||
+ | ===Invocation interfaces=== | ||
+ | |||
+ | Each non-top overridden relation uses an invocation interface to reify its invocation in QVTc. The calling mapping realizes an invocation instance with a property for each root variable. The called mapping executes in response to the invocation instance. The realized instance is of a derived invocation class conforming to a derived invocation interface each corresponding to the actual invoked relation. | ||
+ | |||
+ | |||
+ | ===Invocation statuses=== | ||
+ | |||
+ | ===Trace classes=== | ||
+ | |||
+ | ===Trace interfaces=== | ||
+ | |||
+ | ===Trace statuses=== |
Revision as of 11:16, 20 August 2017
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
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.
Eclipse QVTr solutions
The synthesized trace comprises
- a Model
- a Package per (typically one) Transformation
- a trace Class per Relation/Mapping
- a trace Property per traced Variable
- a status Property for tested progress
- an invocation Class per non-top Relation
- trace/invocation interface Classes for overriding Relation/Mapping
- infrastructure Classes
The Package URI is configurable.
Package, Class, Property names are derived from Transformation, Relation, Variable names.
Invocation classes
Each non-top not-overridden relation uses an invocation class to reify its invocation in QVTc. The calling mapping realizes an invocation instance with a property for each root variable. The called mapping executes in response to the invocation instance.
Invocation interfaces
Each non-top overridden relation uses an invocation interface to reify its invocation in QVTc. The calling mapping realizes an invocation instance with a property for each root variable. The called mapping executes in response to the invocation instance. The realized instance is of a derived invocation class conforming to a derived invocation interface each corresponding to the actual invoked relation.