Home » Archived » M2M (model-to-model transformation) » [ATL] resolveTemp
|
| Re: [ATL] resolveTemp [message #71326 is a reply to message #71266] |
Wed, 09 January 2008 16:33   |
Eclipse User |
|
|
|
Originally posted by: mikael.barbero.gmail.com
Dear Sebastian,
If some elements could not be resolved, it means they were not matched
by any rule. You have to check this manually.
Could you post your metamodel and an excerpt of your transformation and
tell us where it crashes?
Best regards,
Mikael
bfeater wrote:
> Hi,
>
> I am using the function resolveTemp for setting references in several
> rules. But when some element could not be resolved, the function
> crashes. Is this behavior intended? If not, how can I test whether a
> source element was translated or not?
>
>
>
> Thanks,
>
> Sebastian
--
Mikaël Barbero - PhD Candidate
ATLAS Group (INRIA & LINA) - University of Nantes
2, rue de la Houssinière
44322 Nantes Cedex 3 - France
tel. +33 2 51 12 58 08 /\ cell.+33 6 07 63 19 00
email: Mikael.Barbero@{gmail.com, univ-nantes.fr}
http://www.sciences.univ-nantes.fr/lina/atl/
|
|
|
| Re: [ATL] resolveTemp [message #71403 is a reply to message #71326] |
Thu, 10 January 2008 09:09 |
 No real name
Messages: 33
Registered: July 2009 |
Member |
|
|
Hi,
Mikaël Barbero schrieb:
> Dear Sebastian,
>
> If some elements could not be resolved, it means they were not matched
> by any rule. You have to check this manually.
in my setting it is intended not to match all elements (because the
elements are not well defined, etc.). But in the translation of other
elements I need to know whether an element was or will be translated.
How can I check this manually? Creating a global Set storing translated
elements (by a statement in the do section of the corresponding rule)
would not fit, right?
I would assume that resolveTemp returns OclUndefined when the element
is/will be not translated.
> Could you post your metamodel and an excerpt of your transformation and
> tell us where it crashes?
The translation rules are very extensive. The crash happens in the
following assignment (but only when the element to resolve is not created):
....
end <- thisModule.resolveTemp (uml_p, 'hrc_f'),
....
Best regardc,
Sebastian
>
> Best regards,
> Mikael
>
> bfeater wrote:
>> Hi,
>>
>> I am using the function resolveTemp for setting references in several
>> rules. But when some element could not be resolved, the function
>> crashes. Is this behavior intended? If not, how can I test whether a
>> source element was translated or not?
>>
>>
>>
>> Thanks,
>>
>> Sebastian
>
>
>
|
|
|
| Re: [ATL] resolveTemp [message #71460 is a reply to message #71403] |
Thu, 10 January 2008 10:28 |
| Eclipse User |
|
|
|
Originally posted by: mikael.barbero.gmail.com
Hi Sebastian,
My answer below
> in my setting it is intended not to match all elements (because the
> elements are not well defined, etc.). But in the translation of other
> elements I need to know whether an element was or will be translated.
> How can I check this manually?
When I was talking about checking this manually, I was thinking of not
calling a resolveTemp on some elements that will not actually be
transformed.
> Creating a global Set storing translated
> elements (by a statement in the do section of the corresponding rule)
> would not fit, right?
Right, tough because your are not sure about the order of the execution
of the rules. You should only do something local to a rule in a "do"
section.
In fact, you want to be sure that your elements has been filtered out by
some rules (which mean it have been transformed). I suggest to make all
of your filter of matched rule as an boolean helper and test it on each
element on which you want to call resolveTemp. Having this source metamodel:
class A {}
class B {}
class C {}
and those rules
rule A2Foo {
from
s : MM!A (
an_exp_on_MM!A
)
to
...
anAttribute <- thisModule.resolveTemp(s.something, 'tgtPatternElem')
...
}
rule B2Bar {
from
s : MM!B (
an_exp_on_MM!B
)
to
...
}
you can do three helpers:
helper context MM!A def: transformIt : Boolean =
an_exp_on_MM!A;
helper context MM!B def: transformIt : Boolean =
an_exp_on_MM!B;
helper context MM!C def: transformIt : Boolean =
false; -- MM!C are never matched in my transformation, then i return
false
and rewrite your rules:
rule A2Foo {
from
s : MM!A (
s.transformIt
)
to
...
anAttribute <- if (s.something.transformIt) then
thisModule.resolveTemp(s.something, 'tgtPatternElem') else OclUndefined
endif
-- or if s.something is multivalued
anAttribute <- s.something->collect(e | if (e.transformIt) then
thisModule.resolveTemp(e, 'tgtPatternElem') else OclUndefined endif)
...
}
rule B2Bar {
from
s : MM!B (
s.transformIt
)
to
...
}
There is no performance penalty because transformIt are attribute
helpers and are cached by the engine.
> I would assume that resolveTemp returns OclUndefined when the element
> is/will be not translated.
You're right, it should to have a similar behavior as the default
resolve. Can you open a bug about this?
Best regards,
Mikael
--
Mikaël Barbero - PhD Candidate
ATLAS Group (INRIA & LINA) - University of Nantes
2, rue de la Houssinière
44322 Nantes Cedex 3 - France
tel. +33 2 51 12 58 08 /\ cell.+33 6 07 63 19 00
email: Mikael.Barbero@{gmail.com, univ-nantes.fr}
http://www.sciences.univ-nantes.fr/lina/atl/
|
|
|
| Re: [ATL] resolveTemp [message #71498 is a reply to message #71460] |
Thu, 10 January 2008 10:34 |
No real name
Messages: 33
Registered: July 2009 |
Member |
|
|
Hi,
Mikaël Barbero schrieb:
> Hi Sebastian,
>
> My answer below
>
>> in my setting it is intended not to match all elements (because the
>> elements are not well defined, etc.). But in the translation of other
>> elements I need to know whether an element was or will be translated.
>> How can I check this manually?
>
> When I was talking about checking this manually, I was thinking of not
> calling a resolveTemp on some elements that will not actually be
> transformed.
>
>> Creating a global Set storing translated elements (by a statement in
>> the do section of the corresponding rule) would not fit, right?
>
> Right, tough because your are not sure about the order of the execution
> of the rules. You should only do something local to a rule in a "do"
> section.
ok, that was my consideration.
>
> In fact, you want to be sure that your elements has been filtered out by
> some rules (which mean it have been transformed). I suggest to make all
> of your filter of matched rule as an boolean helper and test it on each
> element on which you want to call resolveTemp. Having this source
> metamodel:
>
> class A {}
> class B {}
> class C {}
>
> and those rules
>
> rule A2Foo {
> from
> s : MM!A (
> an_exp_on_MM!A
> )
> to
> ...
> anAttribute <- thisModule.resolveTemp(s.something, 'tgtPatternElem')
> ...
> }
>
> rule B2Bar {
> from
> s : MM!B (
> an_exp_on_MM!B
> )
> to
> ...
> }
>
> you can do three helpers:
>
> helper context MM!A def: transformIt : Boolean =
> an_exp_on_MM!A;
>
> helper context MM!B def: transformIt : Boolean =
> an_exp_on_MM!B;
>
> helper context MM!C def: transformIt : Boolean =
> false; -- MM!C are never matched in my transformation, then i return
> false
>
> and rewrite your rules:
>
> rule A2Foo {
> from
> s : MM!A (
> s.transformIt
> )
> to
> ...
> anAttribute <- if (s.something.transformIt) then
> thisModule.resolveTemp(s.something, 'tgtPatternElem') else OclUndefined
> endif
> -- or if s.something is multivalued
> anAttribute <- s.something->collect(e | if (e.transformIt) then
> thisModule.resolveTemp(e, 'tgtPatternElem') else OclUndefined endif)
> ...
> }
>
> rule B2Bar {
> from
> s : MM!B (
> s.transformIt
> )
> to
> ...
> }
>
> There is no performance penalty because transformIt are attribute
> helpers and are cached by the engine.
Ok, thats the way I realized it. My source meta-model is UML and so I
added an attribute isTranslated to UML!Element which indicates whether
an element is translated or not.
And befor I want to call resolveTemp I test whether the source element
is translated or not.
>
>> I would assume that resolveTemp returns OclUndefined when the element
>> is/will be not translated.
>
> You're right, it should to have a similar behavior as the default
> resolve. Can you open a bug about this?
Yes.
>
> Best regards,
> Mikael
>
>
Thank you for the quick help
Sebastian
|
|
|
Goto Forum:
Current Time: Fri Apr 19 14:10:15 GMT 2024
Powered by FUDForum. Page generated in 0.02454 seconds |
] 
Search
Help
Register
Login
Home
