In fact, I created several profiles using MagicDraw to be used as source and target metamodels in qvt-o transformation. Is their any way to convert these profiles to *.ecore. or how to create meatamodel as ecore file bases on UML profiles

> Hello,
>
> How to create *.ecore model that represent a UML profile?
> In fact, I created several profiles using MagicDraw to be used as
> source and target metamodels in qvt-o transformation. Is their any way
> to convert these profiles to *.ecore. or how to create meatamodel as
> ecore file bases on UML profiles
>
>
> Please advice
> Thanks a lot for your support in advance :)

is there a difference in performance when using dynamic vs. generated
profile definitions?

Patrick

Am 25.09.2013 20:55, schrieb Christian W. Damus:
> Hi,
>
> The Eclipse UML2 run-time does this for you when you either
>
> * define the profile as a dynamic Ecore model using
> the Profile::define() API or
> * create a new EMF Generator Model and load the
> UML profile into it to create the Ecore and generate
> code
>
> See the tutorials on profiles for more details:
>
> http://wiki.eclipse.org/MDT-UML2#Tutorials
>
> HTH,
>
> Christian
>
>
> On 2013-09-25 18:24:13 +0000, Naif Mokhayesh said:
>
>> Hello,
>>
>> How to create *.ecore model that represent a UML profile?
>> In fact, I created several profiles using MagicDraw to be used as
>> source and target metamodels in qvt-o transformation. Is their any way
>> to convert these profiles to *.ecore. or how to create meatamodel as
>> ecore file bases on UML profiles
>>
>>
>> Please advice
>> Thanks a lot for your support in advance :)
>
>

Profiles that I want to use them are already created in MagicDraw and I just need to export them and use it in qvt-o transformation in eclipse.

is it a must to transform them to .ecore metamodel file or we can just use them in transformation declaration directaly by pointing to the uri ( modeltype ... uses ... <Uri of the profile>). how to do it in both cases?

The most significant advantage (for me) in the generated profile is
that it provides the same user-friendly model API that we are
accustomed to with EMF, except for instances of UML stereotypes.

The performance differences between the two variants is as for any
other Ecore model that may be used as "dynamic" or generated. The
dynamic profile doesn't burden the VM with more class definitions, but
maybe there are less efficient book-keeping structures in the
DynamicEObjectImpl? I suspect probably the performance is comparable
(Ed would know better).

I suppose performance differences may come into play when manipulate
stereotype applications with the UML API. I haven't done any tests on
it, but perhaps looking up the profile schema is faster with the
generated profile because the EPackage is available in the registry?
(people tend to forget that dynamic EPackages can also be registered)

Another benefit of the static definition is that it doesn't accumulate
EPackages every time you "define" the profile (because you don't!). It
just maintains a single EPackage and namespace URI even as the profile
definition evolves, subject to all the usual caveats of schema
evolution in EMF, of course.

cW

On 2013-09-26 07:08:28 +0000, Patrick Könemann said:

> Hi Christian,
>
> is there a difference in performance when using dynamic vs. generated
> profile definitions?
>
> Patrick
>
>
> Am 25.09.2013 20:55, schrieb Christian W. Damus:
>> Hi,
>>
>> The Eclipse UML2 run-time does this for you when you either
>>
>> * define the profile as a dynamic Ecore model using
>> the Profile::define() API or
>> * create a new EMF Generator Model and load the
>> UML profile into it to create the Ecore and generate
>> code
>>
>> See the tutorials on profiles for more details:
>>
>> http://wiki.eclipse.org/MDT-UML2#Tutorials
>>
>> HTH,
>>
>> Christian
>>
>>
>> On 2013-09-25 18:24:13 +0000, Naif Mokhayesh said:
>>
>>> Hello,
>>>
>>> How to create *.ecore model that represent a UML profile?
>>> In fact, I created several profiles using MagicDraw to be used as
>>> source and target metamodels in qvt-o transformation. Is their any way
>>> to convert these profiles to *.ecore. or how to create meatamodel as
>>> ecore file bases on UML profiles
>>>
>>>
>>> Please advice
>>> Thanks a lot for your support in advance :)

It depends on what your transformation does. If you are just
transforming the UML definition of the profile, then you don't its
Ecore definition. If you are transforming a UML model that has the
profile and its stereotypes applied, then you will certainly need the
Ecore definition because that is the way by which Eclipse UML2
implements support for stereotypes.

Perhaps I didn't understand the question. In any case, I know nothing
at all about MagicDraw and only slightly more about QVTo. Perhaps
you'd find more pertinent answers on QVTo's forum (I don't know which
that is).

cW

On 2013-09-26 13:56:04 +0000, Naif Mokhayesh said:

> Hi,
>
> Profiles that I want to use them are already created in MagicDraw and
> I just need to export them and use it in qvt-o transformation in
> eclipse.
>
> is it a must to transform them to .ecore metamodel file or we can just
> use them in transformation declaration directaly by pointing to the uri
> ( modeltype ... uses ... <Uri of the profile>). how to do it in both
> cases?
> thanks

thanks for the detailed answer!
Some final follow-up questions below :-)

Patrick

Am 26.09.2013 18:09, schrieb Christian W. Damus:
> Hi, Patrick,
>
> The most significant advantage (for me) in the generated profile is that
> it provides the same user-friendly model API that we are accustomed to
> with EMF, except for instances of UML stereotypes.

We already have an extensive helper class which provides getters and
setters for all our stereotypes and their values, but it is of course
not as type-safe as a generated model (via 'getValue' and 'setValue').

>
> The performance differences between the two variants is as for any other
> Ecore model that may be used as "dynamic" or generated. The dynamic
> profile doesn't burden the VM with more class definitions, but maybe
> there are less efficient book-keeping structures in the
> DynamicEObjectImpl? I suspect probably the performance is comparable
> (Ed would know better).
>
> I suppose performance differences may come into play when manipulate
> stereotype applications with the UML API. I haven't done any tests on
> it, but perhaps looking up the profile schema is faster with the
> generated profile because the EPackage is available in the registry?
> (people tend to forget that dynamic EPackages can also be registered)

Do you mean by registering a profile via the extension point
'org.eclipse.uml2.uml.dynamic_package'?

>
> Another benefit of the static definition is that it doesn't accumulate
> EPackages every time you "define" the profile (because you don't!). It
> just maintains a single EPackage and namespace URI even as the profile
> definition evolves, subject to all the usual caveats of schema evolution
> in EMF, of course.

Our profile is already defined at design-time and added to an
EAnnotation of our profile package. So there should be just a single
profile definition during runtime, right?

>
> cW
>
> On 2013-09-26 07:08:28 +0000, Patrick Könemann said:
>
>> Hi Christian,
>>
>> is there a difference in performance when using dynamic vs. generated
>> profile definitions?
>>
>> Patrick
>>
>>
>> Am 25.09.2013 20:55, schrieb Christian W. Damus:
>>> Hi,
>>>
>>> The Eclipse UML2 run-time does this for you when you either
>>>
>>> * define the profile as a dynamic Ecore model using
>>> the Profile::define() API or
>>> * create a new EMF Generator Model and load the
>>> UML profile into it to create the Ecore and generate
>>> code
>>>
>>> See the tutorials on profiles for more details:
>>>
>>> http://wiki.eclipse.org/MDT-UML2#Tutorials
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>>
>>> On 2013-09-25 18:24:13 +0000, Naif Mokhayesh said:
>>>
>>>> Hello,
>>>>
>>>> How to create *.ecore model that represent a UML profile?
>>>> In fact, I created several profiles using MagicDraw to be used as
>>>> source and target metamodels in qvt-o transformation. Is their any way
>>>> to convert these profiles to *.ecore. or how to create meatamodel as
>>>> ecore file bases on UML profiles
>>>>
>>>>
>>>> Please advice
>>>> Thanks a lot for your support in advance :)
>
>

> Hi Christian,
>
> thanks for the detailed answer!
> Some final follow-up questions below :-)
>
>
> Patrick
>
>
> Am 26.09.2013 18:09, schrieb Christian W. Damus:
>> Hi, Patrick,
>>
>> The most significant advantage (for me) in the generated profile is that
>> it provides the same user-friendly model API that we are accustomed to
>> with EMF, except for instances of UML stereotypes.
>
> We already have an extensive helper class which provides getters and
> setters for all our stereotypes and their values, but it is of course
> not as type-safe as a generated model (via 'getValue' and 'setValue').
>
>>
>> The performance differences between the two variants is as for any other
>> Ecore model that may be used as "dynamic" or generated. The dynamic
>> profile doesn't burden the VM with more class definitions, but maybe
>> there are less efficient book-keeping structures in the
>> DynamicEObjectImpl? I suspect probably the performance is comparable
>> (Ed would know better).
>>
>> I suppose performance differences may come into play when manipulate
>> stereotype applications with the UML API. I haven't done any tests on
>> it, but perhaps looking up the profile schema is faster with the
>> generated profile because the EPackage is available in the registry?
>> (people tend to forget that dynamic EPackages can also be registered)
>
> Do you mean by registering a profile via the extension point
> 'org.eclipse.uml2.uml.dynamic_package'?

The UML2 extension points that mirror the EMF package registrations
help the UML2 run-time to trace the Ecore definitions of profiles to
their UML definitions and/or the other way around.

What I was referring to is registering the dynamic EPackage definition
of a profile in the EPackage.Registry.INSTANCE via EMF's own
org.eclipse.emf.ecore.dynamic_package extension point.

>>
>> Another benefit of the static definition is that it doesn't accumulate
>> EPackages every time you "define" the profile (because you don't!). It
>> just maintains a single EPackage and namespace URI even as the profile
>> definition evolves, subject to all the usual caveats of schema evolution
>> in EMF, of course.
>
> Our profile is already defined at design-time and added to an
> EAnnotation of our profile package. So there should be just a single
> profile definition during runtime, right?

The UML Profile::define() API adds a new EPackage definition to this
annotation, but retains any previous packages because they may still be
used by stereotype applications in UML models to which the profile was
previously applied. Migration of profile applications over time makes
these historic package definitions obsolete so that they may eventually
be removed, but this is not done automatically by the UML2 API.

Perhaps if you use the Profile::URI attribute or the «ePackage»::nsURI
attribute on the profile's UML definition to specify a fixed nsURI of
the generated EPackage definition, then the Profile::define() operation
will replace the previous definition because the NS URI is unchanged
and no migration of profile applications will be required? (or possible)

>
>>
>> cW
>>
>> On 2013-09-26 07:08:28 +0000, Patrick Könemann said:
>>
>>> Hi Christian,
>>>
>>> is there a difference in performance when using dynamic vs. generated
>>> profile definitions?
>>>
>>> Patrick
>>>
>>>
>>> Am 25.09.2013 20:55, schrieb Christian W. Damus:
>>>> Hi,
>>>>
>>>> The Eclipse UML2 run-time does this for you when you either
>>>>
>>>> * define the profile as a dynamic Ecore model using
>>>> the Profile::define() API or
>>>> * create a new EMF Generator Model and load the
>>>> UML profile into it to create the Ecore and generate
>>>> code
>>>>
>>>> See the tutorials on profiles for more details:
>>>>
>>>> http://wiki.eclipse.org/MDT-UML2#Tutorials
>>>>
>>>> HTH,
>>>>
>>>> Christian
>>>>
>>>>
>>>> On 2013-09-25 18:24:13 +0000, Naif Mokhayesh said:
>>>>
>>>>> Hello,
>>>>>
>>>>> How to create *.ecore model that represent a UML profile?
>>>>> In fact, I created several profiles using MagicDraw to be used as
>>>>> source and target metamodels in qvt-o transformation. Is their any way
>>>>> to convert these profiles to *.ecore. or how to create meatamodel as
>>>>> ecore file bases on UML profiles
>>>>>
>>>>>
>>>>> Please advice
>>>>> Thanks a lot for your support in advance :)