[news.eclipse.modeling.gmt.amw] Re: AMW to ATL

[Marcos Didonet Del Fabro <marcos.didonet-del-fabro@xxxxxxxxxxxxxx>]

Hello,

I had I similar question some time ago. I copy the answer below, with some adaptations.

I separated the message in two parts: first with general considerations, then with more 
technical remarks using the Keys2NestedAMW2ATL example.

1 )

The main requirement is to know well the input metamodel (the weaving metamodel) and the 
output metamodel (the ATL metamodel 
[http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt/ATL/org.atl.eclipse.engine/src/org/atl/eclipse/engine/resources/]).
The weaving metamodel varies according to the application scenario. The ATL metamodel is 
fixed.

In the Keys2Nested example, I created the weaving metamodel driven by the right metamodel, 
i.e., with nested structure. You can see in the weaving model that I have "Nested" 
subjects (which is under a link between "BookRcd" and "Book"). Then, we have the input 
values as equality of "FK"s.

So, usually we have extensions of "WLink"s and "WLinkEnd"s in the weaving metamodel, and 
rules, input and output patterns in the ATL metamodel.

I illustrate it with a simple example:

module A2B;
create OUT : B from IN : A;

an ATL has a "Module" as root element. A module has a "name".
Than it has the input and output models and metamodels (In, A, OUT, B).

After that, a module contains a set of rules:

rule A2B { <- this corresponds to a "rule" in the ATL metamodel

from
   in : A!Class  <- this is the "input pattern"
to
   out : B!Table ( <- this is the "output pattern"
      name <- in.name,     <- these are the "bindings"
      value <- in.value    <- bindings
   )
}

The initial part (module and input models), is usually fixed, so you may create them using 
a single rule.

- The rules will be according to the weaving model, so I usually transform WLinks and its 
extensions in rules. In the keys to nested example, this corresponds to the "ElementLink" 
element.
- The input pattern is a "left" WLinkEnd.
- The output pattern is a "right" WLinkEnd.

The bindings are child links ("Equals" are bindings).

------------------------------------------------------------------------------------------
2)

Now, some details using the example:

- Consider now the "ElementLink" rule. It creates an ATL "MatchedRule" for every 
"ElementLink" element.

You see in the bindings of this rule that it has 'inPattern' and 'outPattern' references.
The "inPattern"s will contain the left links (from the input model), and the "outPattern"s 
the  right links (output model).

This two patterns are created in the two following rules, "InPatternEndLeft", and 
"OutPatternEndRight". You can see that they match "Left" and "Right" elements.

We can consider that the "InPattern"s are complete, without any guard.

In the "OutPattern", we want to set the attribute values.
In the element variable, the "binding" reference is set up with amw.link.child. This means 
it will match the children links.
These set of bindings are created in the rules "EqualsNormal" and "EqualsEndLeft".

- Another issue concerns the initial rules that creates "OclModelElement" for all elements 
from left and right metamodels (these are the first rules in the transformation).
We need these rules because it is necessary to refer to the metamodel's elements).

These elements are equivalent to "RDBMS!Database", or "XML!Book" in the output 
transformation. We usually refer to them using the getInstanceById method.

- Finally, one hint to better understand the ATL metamodel (that is a key point) is to 
write a simple transformation by hand and to click over some element in the debug mode. 
The outline in the right shows the corresponding model elements.


Regards,

Marcos.



wg wrote:
> Hi
> Thanks,and where can I get more Information about,how to write AMW to 
> ATL Transformation?
>
> wg