Skip to main content

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.

Jump to: navigation, search

QVTd Traces and Invocations

Revision as of 10:50, 20 August 2017 by Ed.willink.me.uk (Talk | contribs) (QVTr specification oversights)

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

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

Invocation classes and interfaces

Trace classes and interfaces

Back to the top