| [ATL] Bug in ATL 3.0.0 final refining mode ? [message #107589] |
Tue, 30 June 2009 18:10  |
 Cédric Vidal
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  |
William Piers
Messages: 301
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 |
Pierre-Alain BOURDIL
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
|
|
|
Powered by
FUDForum. Page generated in 0.02551 seconds
] 
Search
Help
Register
Login
Home
