Hello,
The objective of these HOTs is to produce an ATL transformation
that translates a left model into a right model.
For example, in the transformation below:
rule Booktransf {
from
db : RDBMS!BookRcd
to
xml : XML!Book (
BookID <- db.ISBN
)
}
'db' is a variable, and "RDBMS!BookRcd" is the type of this variable.
BookID is the "propertyName" of a binding.
The transformation model is written using the metamodel elements.
They must be accessed in some way by the transformation model.
Thus, the HOTs transforms the elements from left and right
metamodels into "OclModelElement". This way it is possible to have
a self-contained transformation model.
Consider the first rule below: the "SimpleInPatternElement" (that
is the input variable) must have a type. We navigate through the
left metamodel using getInstanceById.
Since ATL is declarative, it will set the "type" attribute with the
element that is created when matching the selected MOF!EClassifier.
In our case, it will be a "OclModelElement" (created in the
"Classifiers" rule).
rule InPatternEndLeft {
from
amw : AMW!Left
to
atl : ATL!InPattern (
elements <- element ),
element : ATL!SimpleInPatternElement(
type <- MOF!EClassifier.getInstanceById('left',amw.element.ref)
)
}
rule Classifiers {
from
xml : MOF!EClassifier
to
atl : ATL!OclModelElement (
name <- xml.name
)
}
Marcos.
Didier Delanote wrote:
Hi Marcos,
first of all, thanks for this clarification. Could you give a bit
more explanation about these "OclModelElement"s? What exactly are
they for, when are they used and how exactly does the
getInstanceById method relate to it?
Thanks,
Didier
Marcos Didonet Del Fabro schreef:
Hi Didier,
I already had a similar question from another user. So I am
sending the message to the newsgroup as well.
I separated the message in two parts: first with general
considerations, then with more technical remarks about the example.
1 )
To start with, we still do not have too much documentation on
that, specially by lack of time. Writing these HOTs is not a
simple task. 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:
- first, the 'db0', 'xml1' are identifiers for the variables I
want to create (for example SimpleInPatternElement). This
attribute does not have an influence when generating the
transformation, however, it is a 'Required' field in the ATL
metamodel.
- 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.
Didier Delanote wrote:
> Hi Marcos,
>
> I'm writing you by email because this question is probably not
entirely
> relevant for the newsgroup.
>
> I'm currently studying the AMW2ATL.atl transformation that's
part of the
> Keys2Nested_AMW2ATL example. I need to adapt this
transformation for
> custom purposes. Would it be possible for the person who wrote
it (you I
> assume) to provide some short, more or less detailed
explanation about
> it? About the principle behind it and about the most important
> transformation rules, for example, and how these id's such as
"id0" or
> "xml1" are used. How transformation rules get structured,
because I can
> see that in and out patterns get generated, but can't see how
this all
> gets connected.
>
> Thanks in advance!
>
> Regards,
> Didier
>
>
> Marcos Didonet Del Fabro schreef:
>> :)
>>
>> The menu "Weaving element" is available when right-clicking
over a
>> "Left" or "Right" element.
>>
>> Marcos.
>>
>> Didier Delanote wrote:
>>> What magic... the drag-and-drop way works. Where can I find the
>>> "Weaving element" menu though? Thanks.
>>>
>>> Regards,
>>> Didier
>>>
>>> Marcos Didonet Del Fabro schreef:
>>>> Hello,
>>>>
>>>>
>>>> In a weaving model, the left and right elements (such as
"EAttribute
>>>> ISBN" and "EAttribute BookID") are represented by
"WElementRef"s.
>>>> They contain a text field with an unique ID for each linked
element.
>>>>
>>>> However, the 'WElementRef' elements are created only when
used for
>>>> the first time.
>>>> They may be created in two ways:
>>>>
>>>> - when dragging the elements from the left and right
metamodels and
>>>> dropping them over the "Left" or "Right" elements.
>>>> - when using the menu "Weaving element" and choosing the
linked
>>>> elements.
>>>>
>>>> So that's why you don't see them in the property view. You
should
>>>> create them using one of these two methods.
>>>>
>>>> This avoids having a lot of 'WElementRef' that are not
used, for
>>>> example when weaving large metamodels or models.
>>>>
>>>> After they are created for the first time, they will be
available in
>>>> the property view. This is the case of the examples.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Marcos.
>>>>
>>>>
>>>>
>>>> Didier Delanote wrote:
>>>>> Hi all,
>>>>>
>>>>> I've tried to set up the examples in my own configuration,
of which
>>>>> the Keys2Nested_AMW2ATL example is the most relevant one
to me.
>>>>> Running the example works fine, but now I wanted to define
my own
>>>>> weaving model. I've created a weaving model between the two
>>>>> metamodels, and one between two models from the examples
folder
>>>>> conforming to the right metamodel.
>>>>>
>>>>> The problem is I can add elements such as "Equals" to the
weaving
>>>>> model, and give them children such as "Left" and "Right",
but can't
>>>>> connect these elements to model elements of the left and
right
>>>>> models, such as "EAttribute ISBN" and "EAttribute BookID".
The
>>>>> "Element" combobox from the "Properties" window that
should allow
>>>>> me to do this, pops up blank, containing no elements to
choose
>>>>> from. In a custom defined example this turns out the same
way.
>>>>>
>>>>> If I create a weaving model from the "FK2Nested_AMW.ecore"
file,
>>>>> everything works fine and the "Properties" window pops up the
>>>>> appropriate elements.
>>>>>
>>>>> Could anyone tell me what's going wrong?
>>>>>
>>>>> Regards,
>>>>> Didier
>>>>>
>>>>>
>>>
>