Revision as of 06:02, 18 March 2017

The QVT specification has vague indications that QVTr / QVTc supports in-place transformations but provides no real details.

Copy transformations in which the output is very similar to the input are not considered at all.

This working document considers how copy and in-place might be supported. It takes over from

• https://bugs.eclipse.org/bugs/show_bug.cgi?id=462165
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=512028
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=512735

The Use Case

Support an EcoreUtil.Copier-like capability:

• deep copy of an input model
• arbitrary input classes, some of which may use an extension metamodel not known until run-time
• references to copied class instances are redirected to the copies
• references to external class instances reference the unchanged external class instance

QVTr solution

Impossible, since there is no ability to create a dynamically determined type.

Even if all classes are known at programming time, it is necessary to enumerate an explicit copy of each class. See the

-- copy an ocl expression
-- For space reasons this relation is not expanded out here

at the end of the RelToCore example.

QVTc solution

Impossible, since there is no ability to create a dynamically determined type.

Copy versus In-Place transformation

These could be treated as separate challenges, but from a programmer perspective they are identical; a potentially late run-time option can specify whether the output overlays or replicates the input. We therefore treat copy and in-place as the same problem when considering UMLX, QVTr, QVTc. THe distinction may perhaps occurs as alternate qvts2qvti synthesizes generate different code, or perhaps just in the qvti run-time.

Copy versus non-copy transformation

A non-copy transformation specifies all created types explicitly. Output slots are populated explicitly.

A copy transformation can re-use the source type/object as the target type/object. Output slots may be populated implicitly (by copy/re-use).

Using a non-copy language semantics for a copy requires all slots to be enumerated to participate in the copy. This is verbose and error prone.

An alternative copy language semantics need only specify deviations from a perfect deep copy. cf. Henshin's create/delete markups.

QVTr copy semantics

QVTr copy syntax

ModelMorf

ModelMorf introduces a replace keyword that may qualify a relation to support in-place. Unfortunately I do not understand the description in the Readme.htm of its Beta-4. Perhaps there is some similarity with the domain declaration proposed below.

Transformation declaration

Applying a magic copy keyword to the transformation declaration could change the semantics/syntax but how might a transformation that needs a bit of copy and a bit of non-copy select between semantics. Seems too coarse grained.

Relation declaration

Applying a magic copy keyword to the relation declaration is more flexible but limiting for examples such as the TTC PetriNet2Statechart that need to trans form a pair of domains in-place.

Relation inheritance

Copy semantics could be inherited if default copy relations are auto-generated and available for re-use by derived relations. Unfortunately QVTr overrides is a replace rather than augment capability, so this would need changing. It is not clear how this handles types not known at programming time.

Absolute Domain declaration

Applying a magic copy keyword to the domain declaration creates a problem that there are then pairs of domains with the same name. The intuitive WFR could be relaxed.

Relative Domain declaration

A copies xxxx clause could suffix a domain declaration to indicate that the new domain is based on a copy of the xxxx domain.

Within the copy domain we can exploit the multi-rooted capability to require that all root-variables of the copy domain have names that appear in the copied domain. The copy domain therefore defines one or more Henshin-like overlay patterns; a pattern for creation, an equals null for deletion.

A very similar effect could be achieved by adding a mutation { ... } clause to the copied domain. This is slightly shorter and avoids a duplicated name, but adds to the brace syntax complexity of domains, wheres and collections.

QVTc copy syntax