Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » M2M (model-to-model transformation) » [ATL] Bug in ATL 3.0.0 final refining mode ?
[ATL] Bug in ATL 3.0.0 final refining mode ? [message #107589] Tue, 30 June 2009 18:10 Go to next message
Cédric Vidal is currently offline Cédric VidalFriend
Messages: 101
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------030408000804020606090703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi guys,

I'm preparing an article illustrating UML model scaffolding with ATL 3.0.0.

This article will follow up on (in french):
http://blog.proxiad.com/2009/06/18/mdsd-scaffolding-1-le-sca ffolding-applique-au-mdsd-explication-par-lexemple/

Everything is working fine except a tiny annoying detail which looks
like a bug to me but I'm not sure.

The following rule works nicely:

rule scaffoldDaoForEntity {
from
-- Match only UML Classes which are entities and must be scaffolded
entity : UML!Class (entity.isEntity and entity.scaffoldDao)
to
-- Copy Entity as is
refined : UML!Class,

-- Scaffold DAO ...
dao : UML!Class (
name <- entity.defaultDaoName,
package <- entity.package // this works
),
-- ... and usage from DAO to Entity
usage : UML!Usage (
name <- entity.defaultDaoUsageName,
client <- dao,
supplier <- entity
)
}

But Usage is stored at the root of the output UML model and I want it to
be stored in the same package as the input entity as with the output dao.

I want to set the the containment feature of UML Usage. So I tested
various combinations. First I tried 'namespace' as LHS:

usage : UML!Usage (
name <- entity.defaultDaoUsageName,
client <- dao,
supplier <- entity,
namespace <- entity.package
)

but this fails with attached atl-copy-namespace-stacktrace.log. Using
feature 'owner' as LHS fails with the same error.

I tried feature 'package' as LHS:

usage : UML!Usage (
name <- entity.defaultDaoUsageName,
client <- dao,
supplier <- entity,
package <- entity.package
)

which fails with the following message in the ATL console:

Feature package does not exist on Usage
<native>
at __applyRefiningTrace__(umlscaff.atl)
local variables: self=thisModule
at main(umlscaff.atl)
local variables: self=thisModule

This is wierd. Feature package doesn't exist in UML Usage so the output
is as expected but ATL code completion proposes 'package' to me.

On the other hand, features owner and namespace do exist in UML Usage
but ATL code completion proposes neither of them. Feature 'namespace' is
of type Namespace but Package extends Namespace so it should be possible
to set feature 'namespace' to entity.package

This looks like a bug. If it is, I can post a bug. Full source code of
the sample is attached.

Kind regards,

C
Re: [ATL] Bug in ATL 3.0.0 final refining mode ? [message #500976 is a reply to message #107589] Mon, 30 November 2009 14:42 Go to previous messageGo to next message
William Piers is currently offline William PiersFriend
Messages: 297
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090305040106050008010307
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hello,

Sorry for the late answer...

Could you report a bug about the incorrect completion proposals ?
Content assist will be improved in the next release.

About the containment issue, there is a kind of "hack" you can perform,
the reverse binding:

In your case, this will result in that code:

-- ... and usage from DAO to Entity
usage : UML!Usage -> (entity.package.packagedElement) (
name <- entity.defaultDaoUsageName,
client <- dao,
supplier <- entity
)

The reverse binding expression navigates from the Class to its package,
then the last member stands for the containment feature you want to fill
in. This makes the usage to be contained into the Package of the entity
Class.

I call that a "hack" because at this time there are limitations (only
navigation, no operation calls), the syntax could be discussed, etc. You
can open a bug if you want to open the discussion about it.
Reverse bindings are available since ATL 3.0.

Best regards,

William

C
Re: [ATL] Bug in ATL 3.0.0 final refining mode ? [message #630178 is a reply to message #500976] Thu, 30 September 2010 22:11 Go to previous message
Pierre-Alain BOURDIL is currently offline Pierre-Alain BOURDILFriend
Messages: 25
Registered: September 2010
Junior Member
Damn,

i faced a similar problem that i solve using the resolveTemp function. I needed to create automatically the opposite Ereference for each ref in an ECore model, and after searching a solution, i ended with the two rules solutions above :



--@begin rule CreateEOpposite
--@comments Create, for each EReference that not appears in an EOpposite feature, another EReference.
rule CreateEOpposite{
from
eref : Ecore!EReference(
not thisModule.hasEOpposite(eref)
)
to
eref2 : Ecore!EReference->()(
eOpposite <- eref3
),
eref3 :Ecore!EReference(
name <- eref.eContainingClass.name,
eType <- eref.eContainingClass,
eOpposite <- eref2
)
}
--@end rule Erefs

--@begin rule AttachEOpposite
--@comments For each referenced class, add the opposite EReference to its structural features.
rule AttachEOpposite{
from
-- Foreach class that is the etype of a EReference
eClassIn: Ecore!EClass(
thisModule.isEReferenced(eClassIn)
)
to
eClassOut: Ecore!EClass(
-- iterate the EREference of eClassIn and attach the previously created EOpposite to eClassOut
eStructuralFeatures <- thisModule.getEReferences(eClassIn)
->iterate(ite; result: Sequence(Ecore!EStructuralFeature) = eClassIn.eStructuralFeatures |
result->including(thisModule.resolveTemp(ite,'eref3') )
)
)
}
--@end rule AttachEOpposite


Reverse binding are much simpler than my solution, i think this feature must be describe in the documentation, (ATL Language)

Regards
Previous Topic:[QVTO]when a type does not conform to itself?
Next Topic:[ATL] Transformation of References with same name
Goto Forum:
  


Current Time: Wed Jun 26 14:13:49 GMT 2019

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

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

Back to the top