Home » Archived » M2M (model-to-model transformation) » [QVTO] extension again!
| [QVTO] extension again! [message #101443] |
Mon, 09 March 2009 14:37  |
Eclipse User |
|
|
|
Originally posted by: loic.fejoz.realtimeatwork.com
Hello,
It's not clear at all how to make transformation or library reuse works!
Let us say I have a library (well, finally a transformation)
UmlPrimitiveTypes. It needs the uml primitive library in entry.
Here a snippet:
transformation UmlPrimitiveTypes(in umlPrimitiveTypes : UML);
modeltype UML uses 'http://www.eclipse.org/uml2/2.1.0/UML';
query getUmlBooleanType() : UML::Type {
return getUmlPrimitiveType('Boolean');
}
Then I have another library JavaTypes:
import UmlPrimitiveTypes;
transformation JavaTypes(in javaModel : UML, in umlModel : UML, out UML)
access transformation UmlPrimitiveTypes(in umlModel : UML);
Then a third one:
import JavaTypes;
import JniSignature;
import UmlPrimitiveTypes;
transformation JniSignatureTest(in javaModel : UML, in umlModel : UML,
out output : UML)
access UmlPrimitiveTypes(in umlModel : UML)
access JavaTypes(in javaModel : UML, in umlModel : UML, out UML)
access JniSignature(in javaModel : UML, out output : UML)
;
In this transformation I call getUmlBooleanType. Since the signature are
not the same, the getUmlBooleanType return undefined! Thus simple import
does not work when the signature grows in the inheritance hierarchy...
How to make things works and be reusable?
Thanks in advance!
--
Regards,
Loïc Fejoz
|
|
|
| Re: [QVTO] extension again! [message #101542 is a reply to message #101443] |
Tue, 10 March 2009 22:20  |
 Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi,
First, I would like to mention that the current QVTo implementation is not
correct in terms
of module_usage by "access" or "extends", more precisely it is not
supported directly ;).
There is a legacy support for resuse at the module level, realized via
plain unit import statement
and which works like "extends" with the following limitations:
operations, properties are resolved only within the scope of the importing
and the immediate
extended modules; operation overriding is not supported.
The same scope is used for virtual operations lookup.
At the moment, I'm sorting these things out. The first (easier) issue to
fix is the import
by "access", in which case there should be no signature collisions
possible,
as transformations are to be instantiated explicitly, using "new
MyTransf(...)".
It should be available this week via I-build.
Note, signatures of libraries should never be in collision in both cases
"access" and "extends"
as there are no actual model parameters associated with a library instance.
It is more or less an optional declarative info.
In case of transformation extension, the extended and extending
transformation must have
compatible signatures to ensure that model parameters in both of them are
mapped to the
appropriate model extents passed to the transformation execution.
As for full support of the import by "extension" semantics, I'm not sure
we will manage to implement
it by M6 which is comming quite soon.
However, it should be definitely part of the Galileo release.
Regards,
/Radek
On Mon, 09 Mar 2009 15:37:06 +0100, Loïc Fejoz
<loic.fejoz@realtimeatwork.com> wrote:
> Hello,
>
> It's not clear at all how to make transformation or library reuse works!
>
> Let us say I have a library (well, finally a transformation)
> UmlPrimitiveTypes. It needs the uml primitive library in entry.
> Here a snippet:
> transformation UmlPrimitiveTypes(in umlPrimitiveTypes : UML);
> modeltype UML uses 'http://www.eclipse.org/uml2/2.1.0/UML';
> query getUmlBooleanType() : UML::Type {
> return getUmlPrimitiveType('Boolean');
> }
>
> Then I have another library JavaTypes:
> import UmlPrimitiveTypes;
> transformation JavaTypes(in javaModel : UML, in umlModel : UML, out UML)
> access transformation UmlPrimitiveTypes(in umlModel : UML);
>
> Then a third one:
> import JavaTypes;
> import JniSignature;
> import UmlPrimitiveTypes;
> transformation JniSignatureTest(in javaModel : UML, in umlModel : UML,
> out output : UML)
> access UmlPrimitiveTypes(in umlModel : UML)
> access JavaTypes(in javaModel : UML, in umlModel : UML, out UML)
> access JniSignature(in javaModel : UML, out output : UML)
> ;
>
> In this transformation I call getUmlBooleanType. Since the signature are
> not the same, the getUmlBooleanType return undefined! Thus simple import
> does not work when the signature grows in the inheritance hierarchy...
>
> How to make things works and be reusable?
>
> Thanks in advance!
>
|
|
|
| Re: [QVTO] extension again! [message #101591 is a reply to message #101542] |
Wed, 11 March 2009 10:18 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
I have to correct myself ;), module features are resolved recursively.
On Tue, 10 Mar 2009 23:20:54 +0100, Radek Dvorak
<radek.dvorak@borland.com> wrote:
> Hi,
>
> First, I would like to mention that the current QVTo implementation is
> not correct in terms
> of module_usage by "access" or "extends", more precisely it is not
> supported directly ;).
>
> There is a legacy support for resuse at the module level, realized via
> plain unit import statement
> and which works like "extends" with the following limitations:
> operations, properties are resolved only within the scope of the
> importing and the immediate
> extended modules; operation overriding is not supported.
> The same scope is used for virtual operations lookup.
>
> At the moment, I'm sorting these things out. The first (easier) issue to
> fix is the import
> by "access", in which case there should be no signature collisions
> possible,
> as transformations are to be instantiated explicitly, using "new
> MyTransf(...)".
> It should be available this week via I-build.
>
> Note, signatures of libraries should never be in collision in both cases
> "access" and "extends"
> as there are no actual model parameters associated with a library
> instance.
> It is more or less an optional declarative info.
>
> In case of transformation extension, the extended and extending
> transformation must have
> compatible signatures to ensure that model parameters in both of them
> are mapped to the
> appropriate model extents passed to the transformation execution.
>
> As for full support of the import by "extension" semantics, I'm not sure
> we will manage to implement
> it by M6 which is comming quite soon.
> However, it should be definitely part of the Galileo release.
>
>
> Regards,
> /Radek
>
>
> On Mon, 09 Mar 2009 15:37:06 +0100, Loïc Fejoz
> <loic.fejoz@realtimeatwork.com> wrote:
>
>> Hello,
>>
>> It's not clear at all how to make transformation or library reuse works!
>>
>> Let us say I have a library (well, finally a transformation)
>> UmlPrimitiveTypes. It needs the uml primitive library in entry.
>
>> Here a snippet:
>> transformation UmlPrimitiveTypes(in umlPrimitiveTypes : UML);
>> modeltype UML uses 'http://www.eclipse.org/uml2/2.1.0/UML';
>> query getUmlBooleanType() : UML::Type {
>> return getUmlPrimitiveType('Boolean');
>> }
>>
>> Then I have another library JavaTypes:
>> import UmlPrimitiveTypes;
>> transformation JavaTypes(in javaModel : UML, in umlModel : UML, out UML)
>> access transformation UmlPrimitiveTypes(in umlModel : UML);
>>
>> Then a third one:
>> import JavaTypes;
>> import JniSignature;
>> import UmlPrimitiveTypes;
>> transformation JniSignatureTest(in javaModel : UML, in umlModel : UML,
>> out output : UML)
>> access UmlPrimitiveTypes(in umlModel : UML)
>> access JavaTypes(in javaModel : UML, in umlModel : UML, out UML)
>> access JniSignature(in javaModel : UML, out output : UML)
>> ;
>>
>> In this transformation I call getUmlBooleanType. Since the signature
>> are not the same, the getUmlBooleanType return undefined! Thus simple
>> import does not work when the signature grows in the inheritance
>> hierarchy...
>>
>> How to make things works and be reusable?
>>
>> Thanks in advance!
>>
>
|
|
|
| Re: [QVTO] extension again! [message #101636 is a reply to message #101591] |
Thu, 12 March 2009 10:08 |
| Eclipse User |
|
|
|
Originally posted by: loic.fejoz.realtimeatwork.com
Hi,
Well, I thought I got it but I could not make anything work... Well,
except when all transformations have the same signature!
I always have errors about either misplaced transformation name or
incompatible signatures...
Anyway thanks for your answer.
--
Regards,
Loïc Fejoz
Radek Dvorak a écrit :
> I have to correct myself ;), module features are resolved recursively.
>
>
> On Tue, 10 Mar 2009 23:20:54 +0100, Radek Dvorak
> <radek.dvorak@borland.com> wrote:
>
>> [...]
>> At the moment, I'm sorting these things out. The first (easier) issue
>> to fix is the import
>> by "access", in which case there should be no signature collisions
>> possible,
>> as transformations are to be instantiated explicitly, using "new
>> MyTransf(...)".
>> [...]
>> Note, signatures of libraries should never be in collision in both
>> cases "access" and "extends"
>> as there are no actual model parameters associated with a library
>> instance.
>> It is more or less an optional declarative info.
>> [...]
|
|
|
Goto Forum:
Current Time: Sat Apr 27 02:40:31 GMT 2024
Powered by FUDForum. Page generated in 0.03221 seconds |
] 
Search
Help
Register
Login
Home
