Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[qvtd-dev] Mapping composition

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


Back to the top