Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 09:07 Go to next message
Alfons Laarman is currently offline Alfons LaarmanFriend
Messages: 35
Registered: July 2009
Member
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 #60428 is a reply to message #60381] Tue, 04 September 2007 15:38 Go to previous messageGo to next message
Sergey Boyko is currently offline Sergey BoykoFriend
Messages: 171
Registered: July 2009
Senior Member
Hi Alfons,

Output models differ only in that they initially have empty extent. And
they are not restricted to be write-only. Newly created objects go to
extent and can be queried with .objects() call or resolved with
resolve..() family.

So your case likely a bug. Could you please submit CR. Sample script to
reproduce would be the best.

Best Regards,
Sergey.


> 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 17:32 Go to previous messageGo to next message
Radomil Dvorak is currently offline Radomil DvorakFriend
Messages: 249
Registered: July 2009
Senior Member
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 08:38 Go to previous messageGo to next message
Alfons Laarman is currently offline Alfons LaarmanFriend
Messages: 35
Registered: July 2009
Member
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 10:24 Go to previous message
Radomil Dvorak is currently offline Radomil DvorakFriend
Messages: 249
Registered: July 2009
Senior Member
>> 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/
Previous Topic:[ATL] atlcommandline
Next Topic:avoiding : trying to register several rules...
Goto Forum:
  


Current Time: Sat Apr 10 15:45:36 GMT 2021

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

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

Back to the top