Eclipse Community Forums: UML2 » Creating a DSL / Extending UML2

Help

Home

Home » Modeling » UML2 » Creating a DSL / Extending UML2

Show: Today's Messages :: Show Polls :: Message Navigator

Creating a DSL / Extending UML2 [message #478007]

Mon, 24 November 2008 21:25

Cristian Spiescu

Messages: 100
Registered: July 2009

Senior Member

Hello,

I have followed the "Creating Robust Scalable DSL's with UML:
EclipseCon2008: Tutorial" article from the UML2 wiki. I must say that I'm
quite impressed by the extension mechanism within the UML2 project.

I have a few questions though. In the tutorials, a new EMF model is
created after the UML metamodel or profile has been defined, using the
"New EMF Model" wizard. This step generates a .genmodel file, and an
ecore file.

If I update the UML model (let's say I add a new property), I need to
regenerate the ecore file. How can I do this in a "clean" way?
My current approach is to re-run the "New EMF Model" wizard each time, and
save the .genmodel file under a different name (so it won't overwrite the
existing genmodel settings).

I have seen that there is a command in the "UML Editor" menu that converts
the current model. The problem is that when using this command, the
ecore.ecore and uml.ecore files are generated as well (besides my.ecore
file), and my.ecore references these 2 newly generated ecore models
(instead of the ones defined in the "pathmap", ie
UML_PROFILES/Ecore.profile.uml).

What is your approach when doing this kind of operations?

Thank you in advance.
CS.

Report message to a moderator

Re: Creating a DSL / Extending UML2 [message #478008 is a reply to message #478007]

Mon, 24 November 2008 21:45

Eclipse User

Originally posted by: cdamus.zeligsoft.com

Hi, CS,

This is the purpose of the "Reload..." action in the Generator editor
menu in the main menu bar.

The *.genmodel knows from which UML model it was initially loaded, and
also the options applied at the time, so you should be able to step
through the re-load wizard by just accepting all of the defaults.

Cheers,

Christian

Cristian wrote:
> Hello,
>
> I have followed the "Creating Robust Scalable DSL's with UML:
> EclipseCon2008: Tutorial" article from the UML2 wiki. I must say that
> I'm quite impressed by the extension mechanism within the UML2 project.
>
> I have a few questions though. In the tutorials, a new EMF model is
> created after the UML metamodel or profile has been defined, using the
> "New EMF Model" wizard. This step generates a .genmodel file, and an
> ecore file.
>
> If I update the UML model (let's say I add a new property), I need to
> regenerate the ecore file. How can I do this in a "clean" way?
> My current approach is to re-run the "New EMF Model" wizard each time,
> and save the .genmodel file under a different name (so it won't
> overwrite the existing genmodel settings).
> I have seen that there is a command in the "UML Editor" menu that
> converts the current model. The problem is that when using this command,
> the ecore.ecore and uml.ecore files are generated as well (besides
> my.ecore file), and my.ecore references these 2 newly generated ecore
> models (instead of the ones defined in the "pathmap", ie
> UML_PROFILES/Ecore.profile.uml).
>
> What is your approach when doing this kind of operations?
>
> Thank you in advance.
> CS.
>

Report message to a moderator

Design the extension as a UML model vs EMF model [message #478019 is a reply to message #478008]

Tue, 25 November 2008 15:15

Cristian Spiescu

Messages: 100
Registered: July 2009

Senior Member

Thank you Christian for your quick and precise answer. It helps me a lot.

I realized that I can design and maintain the extension of UML (my DSL)
directly via the EMF model (the .ecore files; if I do it in an uml file,
myDsl.metamodel.uml for example, in the end the UML model is reconverted
in an EMF model).

Are there benefits for using the "UML way" instead of "EMF way" (although
the former induces a little overhead (the need to generate an EMF model
from UML each time the metamodel (or profile) changes)).

For the moment I cannot really see the difference between these 2
approaches.

Thanks in advance,
CS.

Report message to a moderator

Re: Design the extension as a UML model vs EMF model [message #478025 is a reply to message #478019]

Tue, 25 November 2008 21:34

Eclipse User

Originally posted by: cdamus.zeligsoft.com

Hi, Cristian,

Well, when you generate from a UML model you get the following MOF
capabilities that are not available in EMOF (Ecore):

- property redefinition
- property subsetting
- profiles (users of your metamodel can extend it using profiles
just like you can extend UML)
- package merge to separate the concerns in your DSL (not really
much impact on the generated result, though)

Plus, you get certain code-generation enhancements provided by UML2:

- Operations classes to factor out single implementations of
your operations in a multiple-inheritance context
- derived-value caching in the CacheAdapter
- creation methods (including support for named elements)
- name-based search accessors for list properties
- pluralized getter methods for singular property names
- ... probably more ...

Finally, (and this is the best part!) you can use the MDT OCL
implementation's support for UML models to get more capabilities than
with Ecore models:

- navigation of non-navigable association ends
- navigation of unnamed association ends
- forbidden access to Operations that are not "isQuery"

Cheers,

Christian

Cristian wrote:
> Thank you Christian for your quick and precise answer. It helps me a lot.
>
> I realized that I can design and maintain the extension of UML (my DSL)
> directly via the EMF model (the .ecore files; if I do it in an uml file,
> myDsl.metamodel.uml for example, in the end the UML model is reconverted
> in an EMF model).
>
> Are there benefits for using the "UML way" instead of "EMF way"
> (although the former induces a little overhead (the need to generate an
> EMF model from UML each time the metamodel (or profile) changes)).
> For the moment I cannot really see the difference between these 2
> approaches.
>
> Thanks in advance,
> CS.
>

Report message to a moderator