[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.modeling.gmt.amw] Re: AMW examples (continued) 
Hi,

another question about these examples. In my application, I would like to weave to UML models, left and right. So the woven models are not metamodels but models. With the weaving model as input, I'd like to use a higher order transformation to create a transformation model.
My question is, do I need to copy all the UML metamodel into the generated transformation? Do I need to copy the UML model elements into this generated transformation? Or can I generate a transformation model without OCL Model or OCL Model elements?

Thanks,
Didier


Marcos Didonet Del Fabro schreef: 
Hello,

You mean to have an Ecore file of your weaving metamodel? For this there is a context menu when you right click over the weaving panel: "Save weaving metamodel in Ecore format".

At the moment there is two implementations to identify the linked elements. The first is using ModelRefXMI. It requires that the elements of the woven models have XMI:IDs. You can verify if you have this in your UML models.

The second way is to use only "ModelRef". In this case, it uses the standard identification mechanism of EMF, based on the XPointer syntax. In this case, it works for most part of the cases. The main drawback is that the IDs are order dependent. This means that if you change the order of an element, it may not work anymore, because the ID changes.

Regards,

Marcos.



Didier Delanote wrote: 
Hi,

thanks again. Now I'd like to adapt this transformation to weave two UML models, through weaving operations defined in a custom weaving metamodel.

To give this metamodel as an input to the AMWtoATL transformation, I need to extract the km3 file to an ecore metamodel (like mwcore.ecore in the example). This doesn't work though, because the parent model (the base weaving metamodel) is used but never referenced. How could I extract an ECore model from this km3-file? This question is probably more about EEcore syntax, but I can't seem to find the answer online.

For weaving UML models, what happens to the ModelRefXMI logic? Is it sufficient to leave it as it was?

Thanks,
Didier


Marcos Didonet Del Fabro schreef: 
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
>>>>>
>>>>>
>>>
>