| [ATL] Varying rule behavior [message #86204] |
Wed, 09 July 2008 12:38  |
Eclipse User |
|
|
|
Originally posted by: apicard.tampabay.rr.com
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? 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).
Next, what is it that can affect the XMI in the output?
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>
|
|
|
| Re: [ATL] Varying rule behavior [message #86219 is a reply to message #86204] |
Wed, 09 July 2008 13:57  |
| Eclipse User |
|
|
|
Originally posted by: Hugo.Bruneliere.univ-nantes.fr
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@univ-nantes.fr
http://www.sciences.univ-nantes.fr/lina/atl/
--------------------------------------------------------
|
|
|
Powered by
FUDForum. Page generated in 0.01721 seconds
] 
Search
Help
Register
Login
Home
