[qvtd-dev] Left to Middle Resolution

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi Horacio

I implemented a BoundMappingExp as a syntactic overload of a 
ConstructorExp so that

MyMapping{a:anA, b:aB}.c

'constructs' the unique Mapping instance in which anA and aB from the a 
and b inputs, and then navigates to the c variable.

It works but is rather painful.

As an OCLExpression, "MyMapping{a:anA, b:aB}" should have a type, but a 
Mapping is not a type so it is necessary to give it an extra inheritance 
(very nasty) or a MappingType co-object. Also  as a navigation ".c" 
should be a Feature but a Variable is not a Feature, so yet more 
MappingProperty co-objects to adapt the Variables to Properties.

Implementation-wise you would have to maintain a cache of these 
additional Mapping instances, with the added inconvenience of a 
multi-dimensional index.

====

So I thought again. ATL has a horrible resolveTemp helper function. QVTo 
has a few resolve* helpers. Epsilon has some kind of equivalence helper.

Perhaps a helper function for QVTi.

...

Then I thought again again.

Both of the above approaches invalidate the claim that the middle model 
provides the traceability. Why can't we use the middle model? We can...

OCL supports navigation of unnavigable opposites. Their name defaults to 
the opposite class name, but may be specified explicitly by an 
EAnnotation/MOF Tag, so

aLeftNode.MyMappingNode

already gives the Set of MyMappingNode instances in which there is a 
reference to the aLeftNode instance.

If the middle model has distinctive classes, where distinctive 
resolution is required, then the problem is solved. For multi-index 
resolution

aLeftNode.MyMappingNode->any(b = bLeftNode and c = cLeftNode)

solves the problem, and once you have a MyMappingNode instance, all 
variables are navigable provided there is an appropriate middle node 
class property from which to start.

Implementation-wise, it is desirable for an OCL-based application to 
start with

a) Analysis of the known suite of OCL queries to identify all 
occurrences of allInstances and unnavigable opposites

b) A single, perhaps total, model traversal to discover the required 
allInstances results, and to populate a cache of the required 
unnavigable opposites

The above are static. The unnavigable opposite to the middle model has 
an unstable value that evolves as the transformation progresses. It must 
therefore be identified to ensure that no reads are performed until the 
writes have completed. A simple debug check can maintain a state machine 
that evolves from WRITING to READING on the first read so that a write 
after read is diagnosed.

Since the unnavigable opposite is special, the initial analysis should 
identify those in use so that the run-time maintains only the opposite 
relationships that are actually required; quite possibly only 1% of the 
potentially required.

In the Pivot model, a PropertyCallExp has an 
org.eclipse.ocl.examples.domain.library.LibraryProperty implementation 
appropriate to the access strategy; we just need to ensure that a 
QVTiResolutionProperty is installed to evaluate the property access via 
the dynamic cache.

[Resolution is of course an important section of your eventual thesis.]

    Regards

        Ed Willink