Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Jens von Pilgrim is currently offline Jens von PilgrimFriend
Messages: 313
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
Vincent MAHE is currently offline Vincent MAHEFriend
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 Go to previous messageGo to next message
Jens von Pilgrim is currently offline Jens von PilgrimFriend
Messages: 313
Registered: July 2009
Senior Member
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 Go to previous message
Vincent MAHE is currently offline Vincent MAHEFriend
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
Previous Topic:[QVTO] Evaluator: QvtRuntimeException by Transformation
Next Topic:[QVTO] QVT doesn't find objects
Goto Forum:
  


Current Time: Tue Oct 15 21:43:50 GMT 2019

Powered by FUDForum. Page generated in 0.02772 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top