Home » Modeling » EMF » UML profile and EMF ecore
| | | |
| Re: UML profile and EMF ecore [message #1117597 is a reply to message #1117180] |
Thu, 26 September 2013 12:09   |
Eclipse User |
|
|
|
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 |
| Eclipse User |
|
|
|
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 |
| Eclipse User |
|
|
|
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 :)
|
|
|
| Re: UML profile and EMF ecore [message #1840452 is a reply to message #1116693] |
Thu, 15 April 2021 10:50 |
| Eclipse User |
|
|
|
Hi Christian,
This thread is quite old but my question is somewhat relevant to this one so I am replying to this thread. Hopefully, I can get some advice on my problem.
I am not sure if you would remember but we are using a Dynamic profile thus the ecore would be generated during the runtime as you mentioned above. And the EClass contains the UML annotation that references the stereotype from the profile. So we could create a model element that is unattached to the resource but we can still apply stereotype and do all the usual things with it.
However, the problem occurs when we switch to static profile. We had to switch to a static profile because EMFCompare/Papyrus Compare was causing too much grief when even trying to compare smallest model if it is using dynamic profile.
Anyway, now the problem is that the ecore is generated from genmodel but the EClasses that are generated do not reference back to the stereotype. What it means is that all our profile utility(ZDLUtil) is unable to create a model element and apply stereotype if the model is not attached to the resource. In fact, stereotype application is successfully created but the applied stereotype could not be found from the model element. The following code is where it makes difference between static and dynamic profile.
static NamedElement basicGetNamedElement(ENamedElement definition,
EObject context) {
if (definition instanceof EClassifier) {
EAnnotation eAnnotation = definition
.getEAnnotation(UML2_UML_PACKAGE_2_0_NS_URI);
if (eAnnotation != null) {
........
With dynamic profile the eAnnotation is found containing the reference to the stereotype so it will return the stereotype correctly, but the eAnnotation is null when static profile is used. (I can actually open generated ecore and it doesn't contain UML annotation).
For example,
You can successfully apply stereotype to a unattached model like below
STEREOTYPE_APPLICATION_HELPER.applyStereotype(element, definition, stereotype);
However, if you run the following code you will not get the stereotype just applied.
element.getAppliedStereotypes();
I tried to see if there is an option in the genmodel to see if we can generate ecore with this annotation but I couldn't find it.
Do you think of a way to make this work? so we don't have to fix all our code to attach model before applying stereotypes?
Thanks
[Updated on: Thu, 15 April 2021 11:00] by Moderator |
|
| |
| Re: UML profile and EMF ecore [message #1840468 is a reply to message #1840455] |
Thu, 15 April 2021 17:41 |
| Eclipse User |
|
|
|
Thanks for the quick reply.
I will implement a work around to add stereotype application after model element is added to the resource. I think that would be the easiest solution for now.
Thanks
|
|
|
Goto Forum:
Current Time: Tue Jul 22 19:38:44 EDT 2025
Powered by FUDForum. Page generated in 0.04486 seconds |
Home