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"
(→Eclipse QVTr solutions) |
(→Eclipse QVTr solutions) |
||
| Line 94: | Line 94: | ||
===Invocation classes=== | ===Invocation classes=== | ||
| − | Each non-top not-overridden relation | + | Each non-top not-overridden relation has an invocation class to reify its invocation in QVTc. |
| + | |||
| + | The invocation class extends AbstractInvocation which is contained by the AllInvocations class. | ||
| + | |||
| + | Each invocation of a non-top not-overridden relation realizes an instance of the invocation class. | ||
| + | |||
| + | Each root variable is bound by a property in the invocation class. | ||
| + | |||
| + | For when invocations a further initially null property is assigned the trace class instance after successful/failed execution. | ||
| + | |||
| + | Execution occurs when the invoked (top) mapping responds to the invocation class instance and assigns its trace to the invocation. | ||
===Invocation interfaces=== | ===Invocation interfaces=== | ||
| − | Each non-top overridden relation | + | Each non-top overridden relation has an invocation class and an invocation interface to reify its invocation in QVTc. |
| + | The invocation interface inheritance inverts the overrides hierarchy with AbstractInvocation at the root. "inverts" since the least overridden relation is applicable to all overrides. | ||
| + | |||
| + | Each invocation class extends its corresponding invocation interface. | ||
| + | |||
| + | Each invocation of a non-top overridden relation realizes an instance of the invocation class. | ||
| + | |||
| + | Each root variable is bound by a property in the invocation class. | ||
| + | |||
| + | The properties are typed and hosted by the interface of the least overridden relation to which they apply. Pattern matching within the overriding relation checks/converts the overridden types to the overriding types. | ||
| + | |||
| + | For when invocations a further initially null property is assigned the trace class instance after successful/failed execution. | ||
| + | |||
| + | Execution occurs when the invoked (top) mapping responds to the invocation class instance and assigns its trace to the invocation. The derived invocation class selects only those overrides of the invoked relation. The invoked mapping matches its interface in order to consider only viable overrides. Internal not-predicates inhibit execution when an override succeeded. | ||
===Invocation statuses=== | ===Invocation statuses=== | ||
| + | |||
| + | Invocation statuses are only needed for explicit and implicit when invocations. The invocation class property is assigned to the trace of the mapping that executed. | ||
| + | |||
| + | Ambiguity, if multiple overrides succeed, is the status successful for all/any? Is the possibility of a multiple success a static error? | ||
===Trace classes=== | ===Trace classes=== | ||
| + | |||
| + | Each not-overridden relation has a trace class to reify the execution of the corresponding mapping. | ||
| + | |||
| + | The trace class has property for each 'bound' variable; separate issue; the status necessary fir incremental execution. | ||
| + | |||
| + | Invocation occurs when a matching pattern of input objects binds to the root variable, one of which is an invocation class instance for a non-top invocation. | ||
| + | |||
| + | Invocation creates the trace class instance. | ||
| + | |||
| + | If the invocation is a when invocation, an additional status property is assigned true on successful execution, or false after an unsuccessful (predicate failed) execution. The when-invoker may use this status. | ||
===Trace interfaces=== | ===Trace interfaces=== | ||
===Trace statuses=== | ===Trace statuses=== | ||
Revision as of 13:05, 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 has an invocation class to reify its invocation in QVTc.
The invocation class extends AbstractInvocation which is contained by the AllInvocations class.
Each invocation of a non-top not-overridden relation realizes an instance of the invocation class.
Each root variable is bound by a property in the invocation class.
For when invocations a further initially null property is assigned the trace class instance after successful/failed execution.
Execution occurs when the invoked (top) mapping responds to the invocation class instance and assigns its trace to the invocation.
Invocation interfaces
Each non-top overridden relation has an invocation class and an invocation interface to reify its invocation in QVTc.
The invocation interface inheritance inverts the overrides hierarchy with AbstractInvocation at the root. "inverts" since the least overridden relation is applicable to all overrides.
Each invocation class extends its corresponding invocation interface.
Each invocation of a non-top overridden relation realizes an instance of the invocation class.
Each root variable is bound by a property in the invocation class.
The properties are typed and hosted by the interface of the least overridden relation to which they apply. Pattern matching within the overriding relation checks/converts the overridden types to the overriding types.
For when invocations a further initially null property is assigned the trace class instance after successful/failed execution.
Execution occurs when the invoked (top) mapping responds to the invocation class instance and assigns its trace to the invocation. The derived invocation class selects only those overrides of the invoked relation. The invoked mapping matches its interface in order to consider only viable overrides. Internal not-predicates inhibit execution when an override succeeded.
Invocation statuses
Invocation statuses are only needed for explicit and implicit when invocations. The invocation class property is assigned to the trace of the mapping that executed.
Ambiguity, if multiple overrides succeed, is the status successful for all/any? Is the possibility of a multiple success a static error?
Trace classes
Each not-overridden relation has a trace class to reify the execution of the corresponding mapping.
The trace class has property for each 'bound' variable; separate issue; the status necessary fir incremental execution.
Invocation occurs when a matching pattern of input objects binds to the root variable, one of which is an invocation class instance for a non-top invocation.
Invocation creates the trace class instance.
If the invocation is a when invocation, an additional status property is assigned true on successful execution, or false after an unsuccessful (predicate failed) execution. The when-invoker may use this status.