Home » Modeling » EMF » UML profile and EMF ecore
|
| Re: UML profile and EMF ecore [message #1116693 is a reply to message #1116665] |
Wed, 25 September 2013 18:55   |
|
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 #1117180 is a reply to message #1116693] |
Thu, 26 September 2013 07:08 |
Eclipse User |
|
|
|
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 16:09 |
|
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 #1117602 is a reply to message #1117485] |
Thu, 26 September 2013 16:13 |
|
Hi,
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
|
|
|
| Re: UML profile and EMF ecore [message #1121004 is a reply to message #1117597] |
Mon, 30 September 2013 06: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 13:43 |
|
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 14:50 |
 Young-Soo Roh
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
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 15:00] Report message to a moderator |
|
|
| Re: UML profile and EMF ecore [message #1840455 is a reply to message #1840452] |
Thu, 15 April 2021 16:40 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
This all seems very unlikely and without a repro hard to investigate.
My suspicion is that you expect the static to behave like the dynamic. The static is much more powerful so you can almost certainly use types that you already have directly rather than trying to discover them through EAnnotations. maybe there is a missing registration so that your loader/generator is not loading the static correctly.
Regards
Ed Willink
[Updated on: Thu, 15 April 2021 19:21] Report message to a moderator |
|
| |
Goto Forum:
Current Time: Thu Apr 25 03:56:08 GMT 2024
Powered by FUDForum. Page generated in 0.04415 seconds |
] 
Search
Help
Register
Login
Home
