Home » Modeling » EMF » UML profile and EMF ecore
| |
| Re: UML profile and EMF ecore [message #1117180 is a reply to message #1116693] |
Thu, 26 September 2013 03:08   |
|
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 :)
>
>
|
|
| |
| Re: UML profile and EMF ecore [message #1117597 is a reply to message #1117180] |
Thu, 26 September 2013 12:09 |
 Christian W. Damus
Messages: 603
Registered: July 2009 |
Senior Member |
|
|
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.
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 :)
|
|
| |
| Re: UML profile and EMF ecore [message #1121004 is a reply to message #1117597] |
Mon, 30 September 2013 02:57 |
|
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'?
>
> 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 :)
>
>
|
|
|
| Re: UML profile and EMF ecore [message #1121316 is a reply to message #1121004] |
Mon, 30 September 2013 09:43 |
Christian W. Damus
Messages: 603
Registered: July 2009 |
Senior Member |
|
|
Hi, Patrick,
Glad to help! Find some further follow-up in-line.
cW
On 2013-09-30 06:57:43 +0000, Patrick Könemann said:
> 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 :)
|
|
|
Goto Forum:
Current Time: Mon Oct 07 08:08:07 EDT 2013
Powered by FUDForum. Page generated in 0.02227 seconds
|
] 
Search
Help
Register
Login
Home
