[news.eclipse.modeling.m2m] Re: [ATL] Re: Does transformation rules orde

[Rene Ladan <r.c.ladan@xxxxxx>]

Brahim Loukil wrote:
> Jorge Manrubia a écrit :
> > Hi,
> >
> > Yes, that's exactly the case. We have a complex rule making use of 
> > elements that should be created by more simple rules. Indeed they are 
> > created, but are not linked with the elements created by the complex 
> > rule. If we put the complex rule first, it seems that primitive 
> > transformation target elements don't exist when it's executed, while 
> > they are properly created later. If we put the complex rule the last 
> > one, it works as expected.
> >
> > We are not using "resolveTemp()". I expect that normal ATL resolve 
> > behaviour would resolve assigned elements (invoking the corresponding 
> > SOURCE to TARGET rule first) when a SOURCE element is in the right 
> > part of a binding.
> >
> > We are very new with this engine (althought we already love it) so our 
> > assumptions might be totally wrong.
> >
> > Thank you very much for your help
> >
> > Rene Ladan wrote:
> >
> > > The order of the transformation rules should indeed be indifferent
> > > Every functional transformation language (XSLT/ATL/...) works this way.
> >
> > > Could there some dependency between them (e.g. that the complex rule
> > > references a resulting element from the simpler rules, either direct
> > > or through thisModule.resolveTemp()) ?
> >
> > > Rene
> Hi,
> As Rene said, the order of rules should be indifferent.
> However, in some cases and it doesn't depend on the complexity of the 
> rule, you have to specify a logic order. Take a look at the example below:
>
> rule EEnum2Enumeration extends EClassifier2Classifier {
>     from
>         ec    : Ecore!EEnum           
>     to
>         c    : UML!Enumeration (               
>                 ownedLiteral<- ec.eLiterals           
>             )
> }
>
> rule EDataType2DataType extends EClassifier2Classifier {
>     from
>         ec    : Ecore!EDataType           
>     to
>         c    : UML!DataType (
>         )
> }
>
> As you know EEnum is a subtype of EDataType in the Ecore metametamodel, 
> so if you put the rule for EDataType first, you will get a strange 
> behavior.
> You need to put rules for subtypes first.
No, that is what oclIsTypeOf() is for.

rule EEnum2Enumeration extends EClassifier2Classifier {
     from
         ec    : Ecore!EEnum(ec.oclIsKindOf(EEnum))
     to
         c    : UML!Enumeration (
                 ownedLiteral<- ec.eLiterals
             )
 }

rule EDataType2DataType extends EClassifier2Classifier {
     from
         ec    : Ecore!EDataType(ec.oclIsKindOf(EDataType))
     to
         c    : UML!DataType (
         )
 }

Alternatively, the oclIsKindOf() function checks if an element is of a certain
tpye or one of its subtypes.

> If you are not satisfy with this, you can open a bug via Eclipse Bugzilla.
Not needed.

Rene