code generation | Can I change this later???

I am a great advocate of software modeling, which provides a higher abstraction of software artifacts that allow us easier work with them. For my current project (OPM Editor and Interpreter) I use a model based on the eclipse modeling framework (EMF). Until now I had only a model for the editor, and when I started to implement the interpreter the names of the packages that I set for the editor model didn’t seem good enough, so I decided to refactor them. Oh what a headache. I changed the name of the package in the genmodel file and regenerated everything… but now I have to manually update and remove all the old files, trying to remember which files has manual changes (with @generated NOT annotations).

What is the problem here? that the current MDE methodologies (Model Driven Engineering) or any of its names (MDA, MDD…) support mostly forward transformations (from model to code) but if the code is modified the model does know this. Furthermore, the model is not aware of the code, and like in my case this can create duplicate files (if you changed the name of the package for example) and other strange stuff.

So take this into account when you are using model driven methodologies and code generation. At my previous job we NEVER mixed manual code with mixed code, so changes to the generated code did not alter the manual code, and we could always plug the manual code into any generated code changes (with manual hooks). This is a good practice that should be followed. And if you don’t know if your generated code can be refactored, spend more time thinking on how you will name things, because they will be hard (and expensive) to change later.

Previous Tutorial: Creating a GEF editor – Part 1: Defining the Model

The eclipse EMF framework provides tools for the creation of structured data models and the generation of code based on these models. In this tutorial we generate the model and edit code for the model we created on the previous tutorial.
Just a short reminder of the status of the project:

We have 5 EClasses (ObjectProcessDiagram, OPMThing, OPMObject, OPMProcess and OPMLink), some attributes and links between the EClasses. We are now ready for code generation, using the EMF Generator Model.

Right click on the model directory on your project, select “New”->”Other…”. The new file wizard will open. Select the “EMF Generator Model” file kind and click “Next”:
I will name my file “opm.genmodel” (note that the filename must end in .genmodel). Click next once again (and forgive me for not adding another screenshot).
Now it’s time to select from where the model is loaded. An EMF Model Generator file is kind of a “decorator” for a model, which provides extra information to enable code generation of the model. Since we just created and Ecore model in the previous tutorial, we will be using it. You can also create a model using comment annotations in java interfaces (a good tutorial can be found here), which is actually how I started in the first place, but since the annotations are in the comments (and not real java annotations) you have to remember all the syntax, there is no error checking when editing, and after some playing with the Ecore model editor I got pretty used to it. So I’ll click on “Ecore model” in this screen and click “Next”:
Since we have our model file in a project in the workspace, select “Browse Workspace” and find the Ecore model find you want. It should appear in the model URI textbox. You should be able to click on “Load” and nothing bad should happen. Click “Next” once again.
Leave the next wizard page with no changes and click “Finish”. This page lets you select which packages to generate and reference from other generator models, but since I really don’t know what this means, and in any way we only have one package to model, just ignore.
Voila! we have our EMF Generator Model:

Take some time to inspect it. It looks just like our Ecore model, but the properties window suddenly has a lot more lines! This is where all of the information for code generation is stored. We will be editing it a bit and also checking that the generated values are correct. Note that I am not really an expert on EMF, and if you want to understand all of the details you should probably read the EMF book.
Lets define the properties of the Generation Model.
- Root properties: changed the Model Name to OPM which better matches the name I want to give my models.
- Package properties: changed the prefix (which provides a string prefix for some utility generated classes) to OPM.
This should be all we need for now. Right click on the root of the genmodel and select “Generate All” (there is no real need to generate all, but it is nice to use generated editor and test if the model works as expected).
That is basically it. This is how my environment looks now:

If you want to test your model, you can run a model editor by clicking on the execute button (the green one with the white triangle). Another possibility if this does not work is to right-click on the “com.vainolo.phd.opm.model.edit” project, and select “Run As->Eclipse Application”. Create a new project: “File”->”New”->”Project” and select “General”->”Project”:

Click next and name your project as you like (I named mine “test”. Very original). Now we’ll create a new OPM model file! Right click on the project and select “New”->”Other…”. The wizard now also contains “OPM Model” as one possible option!

Click “Next” and give your model a nice name, for example “TheBestOPMModel.opm”. Click “Next”. You now have to select which model class to create as the root of your model’s hierarchy, so select the ObjectProcessDiagram, which is the container of all other EClasses in our model.