[news.eclipse.modeling.m2m] Re: [ATL] Varying rule behavior

[Hugo Bruneliere <Hugo.Bruneliere@xxxxxxxxxxxxxx>]

Hi Alain,

Alain Picard a écrit :
> Hi,
>
> We have a rule that behaves differently depending on the order of one of 
> its target destinations.
>
> We can see (below) that the difference between A & B is the order of the 
> kdmSig to target. The first rule (A) throws the method unit at the end 
> of the generated model and rule B produces a correctly structured output 
> model, but without the correct XMI.
>
> What are the "rules" about ordering of target and why are we getting 
> those results? 

The difference comes from the way ATL automatically deals with
traceability between input and output model elements.
By default, an input model element (declared in the "source" pattern of 
a given rule) is linked to the first output model element declared in 
the "target" pattern of a same rule.

This means that when you refer to this input model element in the
"target" pattern of another rule, it will automatically resolve it as
the corresponding linked output model element (created by the initial 
rule). This is why you obtain different results in your two cases.

You can avoid this by explicitly stating that you want the input model 
element to be resolved as a certain output model element by using the 
"resolveTemp" method instead of the standard expression:

rule A {
	from
             ime1 : MMA!Concept1

	to
             ome1 : MMB!Concept1 (),
	     ome2 : MMB!Concept2 ()
}

rule B {
	from
             ime2 : MMA!Concept2

	to
             ome : MMB!Concept3 (
                value <- thisModule.resolveTemp(ime2.value,'om2') -- 
will be resolved as om2 from rule A
		-- value <- ime.value -- will be resolved as om1 from rule A
	     )
}


However, we recommend to use the implicit resolution as much as possible 
: it's more natural and makes the transformations easier and clearer to 
write and read.

> I would have thought that it either didn't matter or that 
> A would have been the correct choice. Other area of our transformation 
> use the pattern in A (based on the Modisco work).

Considering the previously given explanation, the simpler solution is
solution B because you don't need any explicit resolution using
"resolveTemp".

> Next, what is it that can affect the XMI in the output?

XMI is just a serialization format for your generated model but you may 
imagine considering any other if you want.

I think the XMI obtained using method B is correct and exactly reflects 
what you are doing in your transformation.

Best regards,

Hugo

> Cheers,
> Alain
>
>
> Rule A :
> rule CreateMethods {
>       from stmConcreteNode : STM!StConcreteNode (
>             stmConcreteNode.concreteId = 'MethodDeclaration'
>       )
>       using {
>             exportKind:String = 
> stmConcreteNode.getVisibility('./StConcreteNode[@concreteId=\'MethodDeclaration_Modifier\']/StToken[1]/@image'); 
>
>       }
>       to
>             kdmSig : kdm!Signature (
>                   name <- 'sig'
>             ),
>             kdmClass: kdm!MethodUnit (
>                   name <- 
> stmConcreteNode.getChildren('MethodDeclarator') -> collect (e | 
> e.children) -> flatten().first().image,
>                   export <- stmConcreteNode.getExport(exportKind),
>                   codeElement <- kdmSig
>             )
>
> }
>
> Rule B :
> rule CreateMethods {
>       from stmConcreteNode : STM!StConcreteNode (
>             stmConcreteNode.concreteId = 'MethodDeclaration'
>       )
>       using {
>             exportKind:String = 
> stmConcreteNode.getVisibility('./StConcreteNode[@concreteId=\'MethodDeclaration_Modifier\']/StToken[1]/@image'); 
>
>       }
>       to
>             kdmClass: kdm!MethodUnit (
>                   name <- 
> stmConcreteNode.getChildren('MethodDeclarator') -> collect (e | 
> e.children) -> flatten().first().image,
>                   export <- stmConcreteNode.getExport(exportKind),
>                   codeElement <- kdmSig
>             ),
>             kdmSig : kdm!Signature (
>                   name <- 'sig'
>             )
>
> }
>
>
> Result A :
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xmlns:code="http://kdm.castortech.com/spec/KDM/1.0/code"; 
> xmlns:kdm="http://kdm.castortech.com/spec/KDM/1.0/kdm";>
>   <kdm:Segment>
>     <model xsi:type="code:CodeModel" name="My project">
>       <codeElement xsi:type="code:Package" name="abc">
>         <codeElement xsi:type="code:ClassUnit" name="MyTestJavaCode">
>           <codeElement xsi:type="code:MemberUnit" name="myField" 
> export="private"/>
>           <codeElement xsi:type="code:MemberUnit" 
> name="myIntegrateField" export="private"/>
>         </codeElement>
>       </codeElement>
>       <codeElement xsi:type="code:LanguageUnit" name="Common Java 
> datatypes">
>         <codeElement xsi:type="code:BooleanType" name="boolean"/>
>         <codeElement xsi:type="code:CharType" name="char"/>
>         <codeElement xsi:type="code:FloatType" name="float"/>
>         <codeElement xsi:type="code:FloatType" name="double"/>
>         <codeElement xsi:type="code:IntegerType" name="int"/>
>         <codeElement xsi:type="code:IntegerType" name="long"/>
>         <codeElement xsi:type="code:VoidType" name="void"/>
>         <codeElement xsi:type="code:VoidType" name="null"/>
>       </codeElement>
>     </model>
>   </kdm:Segment>
>   <code:MethodUnit name="myMethod1">
>     <codeElement xsi:type="code:Signature" name="sig"/>
>   </code:MethodUnit>
>   <code:MethodUnit name="myMethod2">
>     <codeElement xsi:type="code:Signature" name="sig"/>
>   </code:MethodUnit>
>   <code:MethodUnit name="getProduct">
>     <codeElement xsi:type="code:Signature" name="sig"/>
>   </code:MethodUnit>
> </xmi:XMI>
>
>
> Result B :
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <kdm:Segment xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xmlns:code="http://kdm.castortech.com/spec/KDM/1.0/code"; 
> xmlns:kdm="http://kdm.castortech.com/spec/KDM/1.0/kdm";>
>   <model xsi:type="code:CodeModel" name="My project">
>     <codeElement xsi:type="code:Package" name="abc">
>       <codeElement xsi:type="code:ClassUnit" name="MyTestJavaCode">
>         <codeElement xsi:type="code:MethodUnit" name="myMethod1">
>           <codeElement xsi:type="code:Signature" name="sig"/>
>         </codeElement>
>         <codeElement xsi:type="code:MethodUnit" name="myMethod2">
>           <codeElement xsi:type="code:Signature" name="sig"/>
>         </codeElement>
>         <codeElement xsi:type="code:MethodUnit" name="getProduct">
>           <codeElement xsi:type="code:Signature" name="sig"/>
>         </codeElement>
>         <codeElement xsi:type="code:MemberUnit" name="myField" 
> export="private"/>
>         <codeElement xsi:type="code:MemberUnit" name="myIntegrateField" 
> export="private"/>
>       </codeElement>
>     </codeElement>
>     <codeElement xsi:type="code:LanguageUnit" name="Common Java datatypes">
>       <codeElement xsi:type="code:BooleanType" name="boolean"/>
>       <codeElement xsi:type="code:CharType" name="char"/>
>       <codeElement xsi:type="code:FloatType" name="float"/>
>       <codeElement xsi:type="code:FloatType" name="double"/>
>       <codeElement xsi:type="code:IntegerType" name="int"/>
>       <codeElement xsi:type="code:IntegerType" name="long"/>
>       <codeElement xsi:type="code:VoidType" name="void"/>
>       <codeElement xsi:type="code:VoidType" name="null"/>
>     </codeElement>
>   </model>
> </kdm:Segment>


--
--------------------------------------------------------
Hugo Bruneliere - R&D Engineer
ATLAS Group (INRIA & LINA) - University of Nantes
2, rue de la Houssiniere
44322 Nantes Cedex 3 - France
office +33 2 51 12 58 10 /\ cell.+33 6 07 42 45 30
EMail: Hugo.Bruneliere@xxxxxxxxxxxxxx
http://www.sciences.univ-nantes.fr/lina/atl/
--------------------------------------------------------