[ATL] Attribute not being populated in target model [message #94754] |
Fri, 07 November 2008 13:35  |
Eclipse User |
|
|
|
Hi all,
I am having a bit of difficulty with my transformation. When I try to
populate a target model attribute with an element from a set, only the
last target model element is populated with the attribute.
For example, the transformation below creates 4 TargetElements. Only the
fourth (last) element will have a value for the attribute 'att1'. Why is
att1 not populated the first three times TARGET!TargetElement is generated?
rule xx{
from
s:SOURCE!SourceElement
to
t:TARGET!TargetElement(
att1 <-SOURCE!AnotherSourceElement.allInstances()->first()
)
Any help would be much appriciated!
Mark
|
|
|
|
|
Re: [ATL] Attribute not being populated in target model [message #95013 is a reply to message #94808] |
Mon, 10 November 2008 18:42   |
Eclipse User |
|
|
|
"Mark Melia" <mark.melia@gmail.com> schreef in bericht
news:b720a04b0d8317f6710f63732b8ae316$1@www.eclipse.org...
> Hi Marcos,
>
> Thanks for your reply, appriciate it!
>
> Just to confirm..
>
> what i expect in the target model is (roughly): targetElement1.att1 =
> anotherSourceElement1
> targetElement2.att1 = anotherSourceElement1
> targetElement3.att1 = anotherSourceElement1
> targetElement4.att1 = anotherSourceElement1
>
> This is perfectly acceptable to do in an ecore model, but can't be done in
> ATL?
>
I think the point of Marcos is that it is not acceptable in an ecore model.
Probably att1 is a containment attribute. If targetElement1 contains a
certain model elemnet, than targetElement2 cannot contain it. You wil need
to create a new anotherSourceElement1 for each assignment, this should be
done once you create a rule for AnotherSourceElement. Do you have one?
Regards,
Alfons
> Mark
>
> Marcos Didonet Del Fabro wrote:
>
>> Hi
>
>> The same model element cannot be referred by more than 1 attribute or 1
>> containment reference.
>
>> So, only the last 'att1' that is set up will refer to
>> 'SOURCE!AnotherSourceElement.allInstances()->first()'.
>
>> Marcos.
>
>> Mark Melia wrote:
>>> Hi all,
>>>
>>> I am having a bit of difficulty with my transformation. When I try to
>>> populate a target model attribute with an element from a set, only the
>>> last target model element is populated with the attribute.
>>> For example, the transformation below creates 4 TargetElements. Only the
>>> fourth (last) element will have a value for the attribute 'att1'. Why is
>>> att1 not populated the first three times TARGET!TargetElement is
>>> generated?
>>>
>>> rule xx{
>>> from s:SOURCE!SourceElement
>>> to
>>> t:TARGET!TargetElement(
>>> att1 <-SOURCE!AnotherSourceElement.allInstances()->first()
>>> )
>>>
>>> Any help would be much appriciated!
>>>
>>> Mark
>>>
>
>
|
|
|
Re: [ATL] Attribute not being populated in target model [message #95056 is a reply to message #95013] |
Tue, 11 November 2008 05:01   |
Eclipse User |
|
|
|
Hi Alfons,
Thanks for you reply and feedback, much appreciated!
I have investigated this and att1 is not containment attribute. Also in my
ecore model after the transformation I can edit the Ecore model to reflect:
targetElement1.att1 = anotherSourceElement1
targetElement2.att1 = anotherSourceElement1
targetElement3.att1 = anotherSourceElement1
targetElement4.att1 = anotherSourceElement1
Any other ideas?
thanks,
Mark
Alfons Laarman wrote:
> "Mark Melia" <mark.melia@gmail.com> schreef in bericht
> news:b720a04b0d8317f6710f63732b8ae316$1@www.eclipse.org...
>> Hi Marcos,
>>
>> Thanks for your reply, appriciate it!
>>
>> Just to confirm..
>>
>> what i expect in the target model is (roughly): targetElement1.att1 =
>> anotherSourceElement1
>> targetElement2.att1 = anotherSourceElement1
>> targetElement3.att1 = anotherSourceElement1
>> targetElement4.att1 = anotherSourceElement1
>>
>> This is perfectly acceptable to do in an ecore model, but can't be done in
>> ATL?
>>
> I think the point of Marcos is that it is not acceptable in an ecore model.
> Probably att1 is a containment attribute. If targetElement1 contains a
> certain model elemnet, than targetElement2 cannot contain it. You wil need
> to create a new anotherSourceElement1 for each assignment, this should be
> done once you create a rule for AnotherSourceElement. Do you have one?
> Regards,
> Alfons
>> Mark
>>
>> Marcos Didonet Del Fabro wrote:
>>
>>> Hi
>>
>>> The same model element cannot be referred by more than 1 attribute or 1
>>> containment reference.
>>
>>> So, only the last 'att1' that is set up will refer to
>>> 'SOURCE!AnotherSourceElement.allInstances()->first()'.
>>
>>> Marcos.
>>
>>> Mark Melia wrote:
>>>> Hi all,
>>>>
>>>> I am having a bit of difficulty with my transformation. When I try to
>>>> populate a target model attribute with an element from a set, only the
>>>> last target model element is populated with the attribute.
>>>> For example, the transformation below creates 4 TargetElements. Only the
>>>> fourth (last) element will have a value for the attribute 'att1'. Why is
>>>> att1 not populated the first three times TARGET!TargetElement is
>>>> generated?
>>>>
>>>> rule xx{
>>>> from s:SOURCE!SourceElement
>>>> to
>>>> t:TARGET!TargetElement(
>>>> att1 <-SOURCE!AnotherSourceElement.allInstances()->first()
>>>> )
>>>>
>>>> Any help would be much appriciated!
>>>>
>>>> Mark
>>>>
>>
>>
|
|
|
Re: [ATL] Attribute not being populated in target model [message #95134 is a reply to message #95056] |
Wed, 12 November 2008 11:46   |
Eclipse User |
|
|
|
Hi all,
Just to add a bit more details to this problem. I have defined two global
variables - the first one was an instance of a SourceElementA from the
source metamodel (MMa), 'c', the second a simple String attribute, 'str'
(see below).
helper def : c : MMa!SourceElementA =
MMa!SourceElementA.allInstances()->first();
helper def : str : String = 'test';
I have then defined a rule that converts from instances of SourceElementB
to instances of TargetElement. The instances of TargetElement are
populated with the attribute values defined in the global variables where
EReference (containment = false) attribute 'sourceEleA' is assigned c and
EAttribute 'stringAtt' is assigned str.
By debugging this transformation I have established that both global
variables are set once, and that each of the attributes in the
transformation rule gets called correctly for the number of SourceElementB
instances in the source model. When I check the target model produced, I
find that only one instance of SourceElementB is populated with c, while
all instances of SourceElementB are populated with str.
rule entryLearnersBasedOnGoal{
from
competency:MMa!SourceElementB()
to
entryLearner:MMb!TargetElement(
sourceEleA <- thisModule.c,
strAtt<-thisModule.name
)
}
Is this a bug or design feature does anyone know?
Mark Melia wrote:
> Hi Alfons,
> Thanks for you reply and feedback, much appreciated!
> I have investigated this and att1 is not containment attribute. Also in my
> ecore model after the transformation I can edit the Ecore model to reflect:
> targetElement1.att1 = anotherSourceElement1
> targetElement2.att1 = anotherSourceElement1
> targetElement3.att1 = anotherSourceElement1
> targetElement4.att1 = anotherSourceElement1
> Any other ideas?
> thanks,
> Mark
> Alfons Laarman wrote:
>> "Mark Melia" <mark.melia@gmail.com> schreef in bericht
>> news:b720a04b0d8317f6710f63732b8ae316$1@www.eclipse.org...
>>> Hi Marcos,
>>>
>>> Thanks for your reply, appriciate it!
>>>
>>> Just to confirm..
>>>
>>> what i expect in the target model is (roughly): targetElement1.att1 =
>>> anotherSourceElement1
>>> targetElement2.att1 = anotherSourceElement1
>>> targetElement3.att1 = anotherSourceElement1
>>> targetElement4.att1 = anotherSourceElement1
>>>
>>> This is perfectly acceptable to do in an ecore model, but can't be done in
>>> ATL?
>>>
>> I think the point of Marcos is that it is not acceptable in an ecore model.
>> Probably att1 is a containment attribute. If targetElement1 contains a
>> certain model elemnet, than targetElement2 cannot contain it. You wil need
>> to create a new anotherSourceElement1 for each assignment, this should be
>> done once you create a rule for AnotherSourceElement. Do you have one?
>> Regards,
>> Alfons
>>> Mark
>>>
>>> Marcos Didonet Del Fabro wrote:
>>>
>>>> Hi
>>>
>>>> The same model element cannot be referred by more than 1 attribute or 1
>>>> containment reference.
>>>
>>>> So, only the last 'att1' that is set up will refer to
>>>> 'SOURCE!AnotherSourceElement.allInstances()->first()'.
>>>
>>>> Marcos.
>>>
>>>> Mark Melia wrote:
>>>>> Hi all,
>>>>>
>>>>> I am having a bit of difficulty with my transformation. When I try to
>>>>> populate a target model attribute with an element from a set, only the
>>>>> last target model element is populated with the attribute.
>>>>> For example, the transformation below creates 4 TargetElements. Only the
>>>>> fourth (last) element will have a value for the attribute 'att1'. Why is
>>>>> att1 not populated the first three times TARGET!TargetElement is
>>>>> generated?
>>>>>
>>>>> rule xx{
>>>>> from s:SOURCE!SourceElement
>>>>> to
>>>>> t:TARGET!TargetElement(
>>>>> att1 <-SOURCE!AnotherSourceElement.allInstances()->first()
>>>>> )
>>>>>
>>>>> Any help would be much appriciated!
>>>>>
>>>>> Mark
>>>>>
>>>
>>>
|
|
|
|
|
|
|
|
|
Re: [ATL] Attribute not being populated in target model [message #95616 is a reply to message #95525] |
Mon, 17 November 2008 10:43  |
Eclipse User |
|
|
|
> Adding the unique keyword does succeed in eliminating duplicates, but the
> original problem is back in that only the last element created contains
> the reference. It is as if it thinks the reference is of type containment.
I use the unique keyword and it generates references to other objects. I
did not experiment the problem you're facing. Here is my code maybe it can
help:
myReferencesOnClasses <- s->collect(e | thisModule.myLazyRule(e)),
...
and the rule:
unique lazy rule myLazyRule {
from s : UML2!Class
to t : MM!Class (
name <- s.name,
implementations <- s.ownedPort
->collect(c | thisModule.myOtherLazyRule(c))
}
My Other Lazy Rule:
unique lazy rule myOtherLazyRule {
from s : UML2!Port
to t : MM!Port (
name <- s.name
)
}
This works fine for me, but you are using model elements that you collect
yourself, sometimes you can have a strange behaviour if you don't respect
the metamodel, i faced that problem.
|
|
|
Powered by
FUDForum. Page generated in 0.31558 seconds