Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvtd-dev] Mapping composition 
Hi

I don't see the difference with

map HSV2MiddleRecursion in ColorChanger {
    hsv(hsvNode : HSVNode | ) {}
    where(middleParent : HSVNode2HLSNode | ) {
        realize middleNode : HSVNode2HLSNode |
        middleNode.parent := middleParent;
        middleNode.hsv := hsvNode;
        middleNode.rgb := hsv2rgb(hsvNode.hsv);
    }
    map HSV2MiddleRecursion {
        hsvNode := hsvNode.children;
        middleParent := middleNode;
    }
}
where the 'nested' mapping has two unbound variables, one bound to a parent and the other to each child in turn.
A 'nested' mapping, just like a function, can have as many passed variables as required.
The QVTi simplification is one new unbound variable at a time; not just one unbound variable in total.
[However since the nested mapping call is just a loop, I'm not sure that multiple loops are really much of a problem anyway; the binding order couyld impose the search order.] 

    Regards

        Ed

On 08/03/2013 15:35, Horacio Hoyos Rodriguez wrote:

Hi Ed,

I've started some tests and I think we need to rethink the composed
mappings a bit more. Looking at my simple Graph transformation and at the
UML2RDBMS it seems we still need composed mappings. For example in the
Graph transformation, the composed mapping that transforms nodes of a
graph:

...
     map {							        --
L to M for N
         check upperGraph(n1:Node | n1.graph = g1;) { }
         where () {
             realize n2n:Node2Node |
             n2n.owner := g2g;
             n2n.node1 := n1;
         }
         map {
             where () {
                 n2n.label := n1.label.toLowerCase();
             }
         }
   }

So far I have not been able to come up with a way to move this mapping to
the root and invoke it via a MappingCall, basically because I lose the
reference to g1 and that would mean that in a non-composed mapping I would

need 2 unbound variables: n1 and g1. Perhaps, as in the ColorTree example,

the association to the parent graph of G1 can be done through the middle
model:

   map NodeLM in copyGraph {
-- L to M for N
         check upperGraph(n1:Node |) { }
         where (g2g:Graph2Graph | g2g.graph1 := n1.graph;) {
             realize n2n:Node2Node |
             n2n.owner := g2g;
             n2n.node1 := n1;
         }
         map {
             where () {
                 n2n.label := n1.label.toLowerCase();
             }
         }
   }

However, as in the future this transformation is derived from a QVTc one,
I believe that if the original QVTc transformation had the composed
mapping using g1 it would be hard to replace a predicate at the L model
(n1.graph = g1;)) by one at the middle model (g2g.graph1 := n1.graph;).
Probably with this example it seems not that hard but I am guessing we
would have a challenge devising a strategy that correctly transforms L
predicates into M predicates.

Regards,


Horacio Hoyos Rodríguez
EngD Student
University of York

-----Original Message-----
From: qvtd-dev-bounces@xxxxxxxxxxx [mailto:qvtd-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ed Willink
Sent: 08 March 2013 14:35
To: qvtd-dev@xxxxxxxxxxx
Subject: [qvtd-dev] Distinct QVTi editor

Hi Horacio

The distinct QVTi editor is now available on GIT master. Attached is a
patch that eliminates the compilation errors in your plugins; no guarantee

that the fixes are actually correct.

A number of name changes are inevitable; e.g ImperativeModel rather than
CoreModel. QVTimperativeVisitor rather than QVTcoreVisitor.

Many names have been promoted to QVTcoreBase that is common to QVTcore and

QVTimperative.

I've eliminated the MappingCall from QVTc and the composed/refined
mappings from QVTi. Anything else fundamental that should change?

      Regards

          Ed
_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvtd-dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 2641/6155 - Release Date: 03/07/13

Back to the top