Eclipse RCP Part 1: Designing the Model
Join the DZone community and get the full member experience.Join For Free
In this tutorial we will see how to use the Eclipse Modeling Framework in order to manage the application Model. If you have EMF and the related tools already installed, please follow the steps illustrated here. The Library model we will use as a sample is taken from the official EMF Tutorial : it consists of two entities, Author and Book.
For the purposes of this tutorial the model has been simplified to this:
- Author: has a String attribute name
- Book: has a String attribute title and an author attribute of type Author
Ok, let's start Creating a New (File->New->Other...) Empty EMF Project
Give it a name (e.g. com.rcpvision.rcptutorial.model) and click Finish. Select the model folder that the EMF wizard just created, right-click New->Other->Ecore Tools->Ecore Diagram
then press Next, change the value of the Domain file name field into Library.ecore
and press Finish. We now have a blank canvas where we can literally design our model.
While editing to the opened .ecorediag file, the correspending .ecore file will be kept in synch.
Please note that the .ecore file is the main EMF domain file and that we could have started editing that file.
In this tutorial instead we decided to explore the Ecore Dialog Tools and have the .ecore file automatically generated and synchronized with the diagram.
So let's start by dragging & dropping an EClass object from the Palette on the blank page and rename it as Author
Then move the cursor over the box and select the icon correspondent to the action "Add EAttribute"
and rename the attribute as name
Then right-click the name attribute and select Show Properties View
go to the Properties View, click the button right to the EType field
Type for instance "ES" in order to filter the prompted list and select EString as the attribute type
Let's do the same for the entity Book and its String attribute title.
Now, in order to add to the Book entity a reference attribute to Author, click on the EReference icon on the Palette
Then click on the Book entity
And release the mouse button over the Author entity
Rename the reference as author
Please note that we just created a 0..1 author link from Book to Author.
If now we save the .ecorediag file and open the .ecore file, we'll see this
You may prefer managing an EMF Model directly via this .ecore file editing (you can find an example here), it's just a matter of taste. The important thing is that now you have an Ecore Model ready to go. Yes, go, but where? The answer is: to generate the model source.
Until now in fact we did not write a single line of code, but we know we will need it at some point. For this purpose select the .ecore file, right-click New->Other...,
select EMF Generator Model
click Next button
click Next button again
now click the Load button, then Next
In the end we obtain a Genmodel file:
from which we can quite "magically" generate the Model code, simply by right-clicking and selecting Generate Model Code
and ... here is the Model code, written out for you by EMF!
Take some time looking at the generated code and ask yourself how much time it would have taken to you to create it by hand (please consider that it embeds, among other features, a notification mechanism associated to each setter method, just to mention one). Also have a look at the end of this other tutorial to see how an EMF Model can be used (it's just one of the possible ways).
Now let's see how EMF is effective when it comes to maintaining a Model. That is, when we need to change the Model. To do so, let's imagine we, all of a sudden, realize that a Book can have more than one Author! Oh, well, we need a Collection instead of a single flat attribute!
Wait, we've got EMF! Then you simply do this: select the author reference from Book to Author and change the Upper Bound value from 1 to * (unlimited)
now save, re-open the Genmodel file and do again Generate Model Code
to have your Model fixed.
What are then the advantages with introduction of EMF ?
- the Model can be designed by non-developers (maybe the analysts, which probably have a deep knowledge of the Customer Domain Model gained through decades, but know almost nothing about a single programming language, including Java)
- the Model code is being generated automatically at 0-time (that is: the time is spent in designing the Model)
- the Model code is created and maintained automatically, thus is potentially 0-error-prone.
Opinions expressed by DZone contributors are their own.