Home » Archived » M2M (model-to-model transformation) » [ATL] correspond m target elements to 1 source element
| [ATL] correspond m target elements to 1 source element [message #507329] |
Tue, 12 January 2010 23:05  |
|
Hi all,
I'm trying to create m target elements from 1 source element. This
certainly is quite simple with ATL. But how is it possible to let the
target elements (the to patterns) correspond to the source element (the
from pattern)?
Let's look at the following example transformation:
Actor "User" --> Class "UserCtrl" + Class "UserBoundary" + Association
"UserC2B"
That is, an (UML) actor "User" is to be transformed into two classes
(UserCtrl and UserBoundary), with an association between these two
classes.
How could that be done with ATL. A very simple approach would look like that:
____________________________________________________________ ____________________
--
@nsURI UML=http://www.eclipse.org/uml2/2.1.0/UML
module analyse;
create OUT : UML from IN : UML;
rule Package2Package {
from srcPackage: UML!Package
to destPackage: UML!Package (
name<-srcPackage.name+'Analyse',
packagedElement <- srcPackage.packagedElement->flatten()
)
}
rule linkAssociation(assoc: UML!Association, src: UML!Class, dst: UML!Class) {
to
propSrc: UML!Property (name<-'src', type<-src),
propDst: UML!Property (name<-'dst', type<-dst)
do {
assoc.ownedEnd <- propSrc;
assoc.ownedEnd <- propDst;
}
}
rule Actor2BoundaryClass {
from actor: UML!Actor
using { p: UML!Package =
thisModule.resolveTemp(actor.package ,'destPackage');
}
to boundary: UML!Class (name<-actor.name+'Boundary', package<-p),
ctrl: UML!Class (name<-actor.name+'Ctrl', package<-p),
assoc: UML!Association (name <- actor.name+'c2b', package<-p)
do { thisModule.linkAssociation(assoc, boundary, classes->ctrl); }
}
____________________________________________________________ ____________________
This
transformation works. However, not all target elements are contained in
the package. Only the first created target element, the "Boundary", is
actually contained in the target package. All other elements are only
contained by reference. This is visible in the XMI output:
____________________________________________________________ ____________________
0: <?xml version="1.0" encoding="ISO-8859-1"?>
1: <xmi:XMI xmi:version="2.1" ...>
2: <uml:Package xmi:id="a1" name="usecasesAnalyse">
3: <packagedElement xmi:type="uml:Class" xmi:id="a2" name="UserBoundary"/>
4: <packagedElement xmi:type="uml:Class" href="#a3"/>
5: <packagedElement xmi:type="uml:Association" href="#a4"/>
6: </uml:Package>
7: <uml:Class xmi:id="a3" name="UserCtrl"/>
8: <uml:Association xmi:id="a4" name="Userc2b" memberEnd="a5 a6">
9: <ownedEnd xmi:type="uml:Property" xmi:id="a5" name="src"
type="a3" association="a4"/>
10: <ownedEnd xmi:type="uml:Property" xmi:id="a6" name="dst"
type="a2" association="a4"/>
11: </uml:Association>
12: </xmi:XMI>
____________________________________________________________ ____________________
Instead
of using "href" in lines 4 and 5, the element should be defined just as
in line 3. How could that be achieved with ATL?
In a first attempt, I tried to create the classes using an iterative
target element pattern:
____________________________________________________________ ____________________
--
rule Package2Package etc. as above
rule Actor2BoundaryClass {
from actor: UML!Actor
using { p: UML!Package =
thisModule.resolveTemp(actor.package ,'destPackage');
}
to
classes: distinct UML!Class
foreach (s in Sequence{'Ctrl', 'Boundary'}) (
name <- actor.name+s, package <- p),
assoc: UML!Association (name <- actor.name+'c2b')
do {
thisModule.linkAssociation(
assoc, classes->at(1), classes->at(2));
}
}
____________________________________________________________ ____________________
With
this version, at least the second class is actually contained in the
package, that is the XMI output looks as follows:
____________________________________________________________ ____________________
1: <?xml version="1.0" encoding="ISO-8859-1"?>
2: <xmi:XMI xmi:version="2.1" ...>
3: <uml:Package xmi:id="a1" name="usecasesAnalyse">
4: <packagedElement xmi:type="uml:Class" xmi:id="a2" name="UserCtrl"/>
5: <packagedElement xmi:type="uml:Class" xmi:id="a3" name="UserBoundary"/>
6: <packagedElement xmi:type="uml:Association" href="#a4"/>
7: </uml:Package>
8: <uml:Association xmi:id="a4" name="Userc2b" memberEnd="a5 a6">
9: <ownedEnd xmi:type="uml:Property" xmi:id="a5" name="src"
type="a2" association="a4"/>
10: <ownedEnd xmi:type="uml:Property" xmi:id="a6" name="dst"
type="a3" association="a4"/>
11: </uml:Association>
12: </xmi:XMI>
____________________________________________________________ ____________________
You
can see the difference in line 5! Unfortunately, the association still
is only referenced by "href".
Since the "distinct .. foreach" pattern requires the same type, it
cannot be be used in order to let the association be created this way
as well.
How can I solve that problem? Is it possible to explicitly make
multiple target elements correspond to a single source element?
Cheers,
Jens
|
|
|
| Re: [ATL] correspond m target elements to 1 source element [message #507370 is a reply to message #507329] |
Wed, 13 January 2010 03:18  |
 Vincent MAHE
Messages: 129
Registered: July 2009 |
Senior Member |
|
|
Jens v.P. a écrit :
> Hi all,
>
> I'm trying to create m target elements from 1 source element. This
> certainly is quite simple with ATL. But how is it possible to let the
> target elements (the to patterns) correspond to the source element (the
> from pattern)?
>
> Let's look at the following example transformation:
>
> Actor "User" --> Class "UserCtrl" + Class "UserBoundary" + Association
> "UserC2B"
>
> That is, an (UML) actor "User" is to be transformed into two classes
> (UserCtrl and UserBoundary), with an association between these two classes.
>
> How could that be done with ATL. A very simple approach would look like
> that:
> ____________________________________________________________ ____________________
>
I would have written like this:
@nsURI UML=http://www.eclipse.org/uml2/2.1.0/UML
module analyse;
create OUT : UML from IN : UML;
rule Package2Package {
from srcPackage: UML!Package
to destPackage: UML!Package (
name<-srcPackage.name+'Analyse',
packagedElement <- srcPackage.packagedElement->flatten()
)
}
rule Actor2BoundaryClass {
from actor: UML!Actor
using { p: UML!Package =
thisModule.resolveTemp(actor.package ,'destPackage');
}
to
boundary: UML!Class (name<-actor.name+'Boundary', package<-p),
ctrl: UML!Class (name<-actor.name+'Ctrl', package<-p),
propSrc: UML!Property (name<-'src', type<-boundary),
propDst: UML!Property (name<-'dst', type<-ctrl),
assoc: UML!Association (name <- actor.name+'c2b',
ownedEnd <- propSrc,
ownedEnd <- propDst,
package<-p)
do {
-- if 'package<-p' does not work, you may force containment
p.packagedElement <- p.packagedElement->add(boundary);
p.packagedElement <- p.packagedElement->add(ctrl);
p.packagedElement <- p.packagedElement->add(assoc);
}
}
--
Cordialement
Vincent MAHÉ
Ingénieur plate-forme - Cesar/Artemisia - Équipe Espresso
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tél: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71
|
|
|
| Re: [ATL] correspond m target elements to 1 source element [message #507380 is a reply to message #507370] |
Wed, 13 January 2010 09:59 |
|
Vincent,
thank you for the help. Actually, it didn't worked like that, but it
helped me to figure out how it works:
On 2010-01-13 09:17:44 +0100, Vincent MAHE <vmahe@irisa.fr> said:
[...]
> -- if 'package<-p' does not work, you may force containment
> p.packagedElement <- p.packagedElement->add(boundary);
> p.packagedElement <- p.packagedElement->add(ctrl);
> p.packagedElement <- p.packagedElement->add(assoc);
> }
> }
"add" doesn't work ("Could not find operation add on Sequence(OclAny)
having supertypes: [Collection(OclAny)]" -- btw: why "Sequence(OclAny)"
and not "Sequence(PackageableElement)"?) but "append" does:
____________________________________________________________ __
do { ...
p.packagedElement <- p.packagedElement->append(boundary);
p.packagedElement <- p.packagedElement->append(ctrl);
p.packagedElement <- p.packagedElement->append(assoc);
}
____________________________________________________________ __
It compiles and transforms and even creates the correct output (i.e.
all three elements are actually contained in the package).
However: it isn't "append" which does the trick!
The following does exactly the same:
____________________________________________________________ __
do {
...
p.packagedElement <- p.packagedElement;
}
____________________________________________________________ __
I already did assume something like that to be necessary, as a
statement is necessary in called rules in order to "return" something.
For example, a called rule creating a new class needs the last
statement as shown in the listing below in order to "return" the class:
____________________________________________________________ __
rule createClass (className: String, p: UML!Package) {
to c: UML!Class (name <- className, package <- p)
do { c; } -- this statement "returns" the class
}
____________________________________________________________ __
However, simply
____________________________________________________________ __
do {
...
p.packagedElement;
}
____________________________________________________________ __
does not work, and "returning" some kind of collection doesn't either
(I tried that before by creating a sequence at the end of the do block).
Frankly, I don't understand that at all. IMHO "p.packagedElement <-
p.packagedElement" doesn't make any sense (at least not for me, but
apparently it does for ATL). What does it do (internally)? Is this
behaviour (the one with the called rule and the weird assignment in my
example) documented in ATL? Or is this some weird UML thing (i.e., why
is it necessary at all)?
Cheers
Jens
|
|
|
| Re: [ATL] correspond m target elements to 1 source element [message #507393 is a reply to message #507380] |
Wed, 13 January 2010 10:46 |
Vincent MAHE
Messages: 129
Registered: July 2009 |
Senior Member |
|
|
Jens v.P. a écrit :
> Vincent,
>
> thank you for the help. Actually, it didn't worked like that, but it
> helped me to figure out how it works:
>
> On 2010-01-13 09:17:44 +0100, Vincent MAHE <vmahe@irisa.fr> said:
> [...]
>> -- if 'package<-p' does not work, you may force containment
>> p.packagedElement <- p.packagedElement->add(boundary);
>> p.packagedElement <- p.packagedElement->add(ctrl);
>> p.packagedElement <- p.packagedElement->add(assoc);
>> }
>> }
>
> "add" doesn't work ("Could not find operation add on Sequence(OclAny)
Sorry for my mistake (I did not try this code)
> having supertypes: [Collection(OclAny)]" -- btw: why "Sequence(OclAny)"
> and not "Sequence(PackageableElement)"?) but "append" does:
> ____________________________________________________________ __
> do { ...
> p.packagedElement <- p.packagedElement->append(boundary);
> p.packagedElement <- p.packagedElement->append(ctrl);
> p.packagedElement <- p.packagedElement->append(assoc);
> }
> ____________________________________________________________ __
>
> It compiles and transforms and even creates the correct output (i.e. all
> three elements are actually contained in the package).
>
> However: it isn't "append" which does the trick!
It was an overwriting, as the opposite affectation 'x.package<-p' should
do the work.
>
> The following does exactly the same:
> ____________________________________________________________ __
> do {
> ...
> p.packagedElement <- p.packagedElement;
> }
> ____________________________________________________________ __
>
> I already did assume something like that to be necessary, as a statement
> is necessary in called rules in order to "return" something. For
> example, a called rule creating a new class needs the last statement as
> shown in the listing below in order to "return" the class:
>
> ____________________________________________________________ __
> rule createClass (className: String, p: UML!Package) {
> to c: UML!Class (name <- className, package <- p)
> do { c; } -- this statement "returns" the class
> }
> ____________________________________________________________ __
>
> However, simply
> ____________________________________________________________ __
> do {
> ...
> p.packagedElement;
> }
> ____________________________________________________________ __
>
> does not work, and "returning" some kind of collection doesn't either (I
> tried that before by creating a sequence at the end of the do block).
>
> Frankly, I don't understand that at all. IMHO "p.packagedElement <-
> p.packagedElement" doesn't make any sense (at least not for me, but
> apparently it does for ATL). What does it do (internally)? Is this
> behaviour (the one with the called rule and the weird assignment in my
> example) documented in ATL? Or is this some weird UML thing (i.e., why
> is it necessary at all)?
In ATL, the 'append()' operation on collection does a copy of the
collection and return this augmented copy so you must reaffect this copy
as the effective collection. That is why I wrote the package operation
this way.
It seems that ATL manages background appends on collections
corresponding to opposites in the same way it manages direct appends...
So the 'p.packagedElement <-p.packagedElement' refreshes the effective
owner of the collection with the last in-memory state of it.
--
Cordialement
Vincent MAHÉ
Ingénieur plate-forme - Cesar/Artemisia - Équipe Espresso
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tél: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71
|
|
|
Goto Forum:
Current Time: Wed Apr 24 23:04:51 GMT 2024
Powered by FUDForum. Page generated in 0.02336 seconds |
] 
Search
Help
Register
Login
Home
