Home » Archived » M2M (model-to-model transformation) » [QVT] Are oml output models write-only by spec?
| [QVT] Are oml output models write-only by spec? [message #60381] |
Tue, 04 September 2007 05:07  |
Eclipse User |
|
|
|
Hi everybody,
I tried to write a transformation with a mapping operation that changes
behavior after when called the second time. Therefore I wrote conditions
that resolve elements in the output model and check the multiplicity of
added elements:
mapping copyNewPackage(in p : UML::Package, in super : UML::Package) :
UML::Package {
init {
var superIsModel : Boolean := super.oclIsTypeOf(UML::Model);
var superHasChild : Boolean := super.resolveoneIn(copyModel,
UML::Model).ownedElements != null;
.. conditions ..
}
Somehow I'm not able to check the contents of the output model during
the transformation. I tried reading simple string fields and checking
the number of super.resolve.ownedElements. Yet I can write to
super.resolve.ownedElements, so it resolves fine.
This leads me to the conclusion that outputmodels are strictly
write-only, although I the QVT specs or any other document I could find
don't confirm this.
Is this somehow a shortcoming of the oml contribution or is it specified
or is it configurable?
Regards,
Alfons
|
|
| |
| Re: [QVT] Are oml output models write-only by spec? [message #60470 is a reply to message #60381] |
Tue, 04 September 2007 13:32  |
| Eclipse User |
|
|
|
Hi Alfons,
There is a couple of things that might be influencing the problem,
1) beware of single mapping execution for the same inputs, the next call=
s =
use traces
to fetch the result. In this case your conditions might not get =
evaluated.
2) expression 'super.resolveoneIn(copyModel, UML::Model).ownedElements !=
=3D =
null'
always results in true.
Regards,
/Radek
On Tue, 04 Sep 2007 11:07:07 +0200, Alfons Laarman =
<alfons.laarman@obeo.fr> wrote:
> Hi everybody,
>
> I tried to write a transformation with a mapping operation that change=
s =
> behavior after when called the second time. Therefore I wrote conditio=
ns =
> that resolve elements in the output model and check the multiplicity o=
f =
> added elements:
>
> mapping copyNewPackage(in p : UML::Package, in super : UML::Package) :=
=
> UML::Package {
> init {
> var superIsModel : Boolean :=3D super.oclIsTypeOf(UML::Model);
> var superHasChild : Boolean :=3D super.resolveoneIn(copyModel,
> UML::Model).ownedElements !=3D null;
> .. conditions ..
> }
>
>
> Somehow I'm not able to check the contents of the output model during =
=
> the transformation. I tried reading simple string fields and checking =
=
> the number of super.resolve.ownedElements. Yet I can write to =
> super.resolve.ownedElements, so it resolves fine.
>
> This leads me to the conclusion that outputmodels are strictly =
> write-only, although I the QVT specs or any other document I could fin=
d =
> don't confirm this.
> Is this somehow a shortcoming of the oml contribution or is it specifi=
ed =
> or is it configurable?
>
>
> Regards,
>
> Alfons
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: [QVT] Are oml output models write-only by spec? [message #60514 is a reply to message #60470] |
Wed, 05 September 2007 04:38 |
| Eclipse User |
|
|
|
Radek Dvorak a écrit :
> Hi Alfons,
>
> There is a couple of things that might be influencing the problem,
>
> 1) beware of single mapping execution for the same inputs, the next
> calls use traces
> to fetch the result. In this case your conditions might not get
> evaluated.
Does this mean that, in a recursive mapping call, I cannot resolve the
mappings made in the first recursion in the later recursions?
Then this should not be the problem, because I execute 'copyModel' and
subsequently 'copyNewPackage'.
>
> 2) expression 'super.resolveoneIn(copyModel, UML::Model).ownedElements
> != null'
> always results in true.
I tried other ways to check the contents, like
'super.resolveoneIn(copyModel, UML::Model).name' and the like. So I
think this is also ruled out. Actually the strangest thing was that
'super.resolveIn(copyModel, UML::Model)->size().toString()' resulted
always null instead of a number.
> Regards,
> /Radek
>
>
> On Tue, 04 Sep 2007 11:07:07 +0200, Alfons Laarman
> <alfons.laarman@obeo.fr> wrote:
>
>> Hi everybody,
>>
>> I tried to write a transformation with a mapping operation that
>> changes behavior after when called the second time. Therefore I wrote
>> conditions that resolve elements in the output model and check the
>> multiplicity of added elements:
>>
>> mapping copyNewPackage(in p : UML::Package, in super : UML::Package) :
>> UML::Package {
>> init {
>> var superIsModel : Boolean := super.oclIsTypeOf(UML::Model);
>> var superHasChild : Boolean := super.resolveoneIn(copyModel,
>> UML::Model).ownedElements != null;
>> .. conditions ..
>> }
>>
>>
>> Somehow I'm not able to check the contents of the output model during
>> the transformation. I tried reading simple string fields and checking
>> the number of super.resolve.ownedElements. Yet I can write to
>> super.resolve.ownedElements, so it resolves fine.
>>
>> This leads me to the conclusion that outputmodels are strictly
>> write-only, although I the QVT specs or any other document I could
>> find don't confirm this.
>> Is this somehow a shortcoming of the oml contribution or is it
>> specified or is it configurable?
>>
>>
>> Regards,
>>
>> Alfons
>
>
>
|
|
|
| Re: [QVT] Are oml output models write-only by spec? [message #60905 is a reply to message #60514] |
Wed, 05 September 2007 06:24 |
| Eclipse User |
|
|
|
>> 1) beware of single mapping execution for the same inputs, the next =
=
>> calls use traces
>> to fetch the result. In this case your conditions might not get =
>> evaluated.
> Does this mean that, in a recursive mapping call, I cannot resolve the=
=
> mappings made in the first recursion in the later recursions?
> Then this should not be the problem, because I execute 'copyModel' and=
=
> subsequently 'copyNewPackage'.
I just wanted to point out that calling a single mapping operation =
recursively
(or repeatedly) for the same source objects will impact whether its =
operation
body will be executed or not. In such cases the conditions in your init =
=
section
might get evaluated only during the first call.
>
>> 2) expression 'super.resolveoneIn(copyModel, UML::Model).ownedElemen=
ts =
>> !=3D null'
>> always results in true.
> I tried other ways to check the contents, like =
> 'super.resolveoneIn(copyModel, UML::Model).name' and the like. So I =
> think this is also ruled out. Actually the strangest thing was that =
> 'super.resolveIn(copyModel, UML::Model)->size().toString()' resulted =
> always null instead of a number.
>
Sorry, I have overlooked it's not 'resolveIn' but resolveoneIn'.
In this case for sure you should resolve successfully only if
the mapping got already executed.
If executed for the first time, resolve in
'super.resolveoneIn(copyModel, UML::Model).ownedElements'
returns null and a property call on null results in Invalid,
which is not equal to null. Then <> null results in true.
This could also affect your usecase I guess.
>> Regards,
>> /Radek
>> On Tue, 04 Sep 2007 11:07:07 +0200, Alfons Laarman =
>> <alfons.laarman@obeo.fr> wrote:
>>
>>> Hi everybody,
>>>
>>> I tried to write a transformation with a mapping operation that =
>>> changes behavior after when called the second time. Therefore I wrot=
e =
>>> conditions that resolve elements in the output model and check the =
>>> multiplicity of added elements:
>>>
>>> mapping copyNewPackage(in p : UML::Package, in super : UML::Package)=
: =
>>> UML::Package {
>>> init {
>>> var superIsModel : Boolean :=3D super.oclIsTypeOf(UML::Model);
>>> var superHasChild : Boolean :=3D super.resolveoneIn(copyModel,
>>> UML::Model).ownedElements !=3D null;
>>> .. conditions ..
>>> }
>>>
>>>
>>> Somehow I'm not able to check the contents of the output model durin=
g =
>>> the transformation. I tried reading simple string fields and checkin=
g =
>>> the number of super.resolve.ownedElements. Yet I can write to =
>>> super.resolve.ownedElements, so it resolves fine.
>>>
>>> This leads me to the conclusion that outputmodels are strictly =
>>> write-only, although I the QVT specs or any other document I could =
>>> find don't confirm this.
>>> Is this somehow a shortcoming of the oml contribution or is it =
>>> specified or is it configurable?
>>>
>>>
>>> Regards,
>>>
>>> Alfons
>>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
Goto Forum:
Current Time: Thu May 01 05:00:56 EDT 2025
Powered by FUDForum. Page generated in 0.06488 seconds |
Home