From Front End To Code - MDSD in Practice

By Markus Voelter, Bernd Kolb, Sven Efftinge, and Arno Haase, all Independent Consultants June 15, 2006
For model-driven development it is essential that we provide an end-to-end tool chain. The following challenges arise:
Note that in this article we're not going to address issues such as why you would want to do model-driven software development (MDSD) at all, which advantages it has, how you'll have to organize your project, etc. If you're interested in these aspects (which we assume you already know for this article), we recommend reading [SV06]. We assume that you consider MDSD to be useful – and based on that, we'll show you how to do it effectively with today's tooling.
Our example is based on state machines. Everybody knows state machines, so this sounds like a reasonable example. We will start by defining a metamodel for state machines. This will be based on the UML metamodel. We use Eclipse Modeling Framework (EMF) to define it. We will then build a graphical editor for state machines using the well-known UML-based notation; for this task we'll use the Eclipse Graphical Modeling Framework (GMF) framework. We will then add additional constraints (e.g. "states must have unique names"). To make things more convenient, we'll use the oAW Checks language and integrate it with GMF. Next up will be a code generator that creates an implementation of state machines in Java. We use oAW's xPand language. We'll then create a set of recipes that help developers with the implementation of the actions associated with states – this illustrates the problem of integrating generated and manually written code. We will then cover model-to-model transformations and model modifications using oAW's xTend language. Finally, we will build a textual editor for rendering the state machines textually using oAW's xText framework.
Note that all the code is available from http://www.eclipse.org/gmt/oaw/doc/s10_gmfAndOAW_src.zip
The metamodel for state machines is probably well-known. A state machine consists of a number of states. States can be start states, stop states and "normal" states. A transition connects two states. States know their outgoing and incoming transitions. We also support composite states that themselves contain sub state machines. A state machine is itself a composite state. A state has actions. Actions can either be entry or exit actions. Here's the UML diagram for that metamodel, rendered with the GMF Ecore Modeler.
In the properties view, as shown in the next screenshot, you can adjust the properties of the metamodel elements.
You can find the metamodel in the oaw4.demo.gmf.statemachine2 project.
To do useful work with this metamodel, we have to generate a number of artifacts (note that you could in theory work with dynamic EMF models, but for our case (GMF, Recipes, etc.) this will not work). First of all, you need to generate the genmodel. This is basically a decorator model (or a marker model) around our metamodel that "decorates" a number of extra properties on top of it. The yellow area in the following screenshot shows the genmodel file. If you're familiar with EMF you'll know how to generate it; if you're not familiar with EMF it's not important here.
Once you have generated the genmodel, open it, select the root element, and execute Generate All from the context menu. This is what will be generated:
As of now, there's no reason to look into any of these models or projects in more detail. You just have to make sure they're there.
Building a graphical editor for your own DSL is probably the most complex and intricate of the steps of this tutorial. This is for two reasons. The first reason is that this tutorial has been written before GMF was finalized. So there are still a couple of glitches in the software (to get an updated tutorial, see [GmfTut]). The second reason is that building an editor is simply non-trivial! Before GMF arrived, you had to do it manually with the Graphical Editing Framework (GEF) which was a very daunting task (unless you'd write your own generator, as in [RV05]). Before even GEF, building a custom editor was not a viable alternative for most projects at all. So, GMF really is a huge step forward. And the remaining complexity is actually a joke, compared to what you'd have had to do pre-GMF. So let's get started.
For building a GMF editor (as shown in the next illustration) you start from your metamodel (the .ecore file) and the .genmodel defined above. We assume that these are already there. Also, the .edit and .editor projects generated from them are also assumed to be available.
To get us a step further, a number of additional models have to be defined (we'll look into each of the later):
Take a look at this illustration to understand how those models fit together. From all of these additional models, GMF creates the .gmfgen model – again a "low level" model that the code generator uses as an input, finally creating the .diagram project which contains your desired editor.
We use another project for the GMF models from which we'll create the editor: oaw4.demo.gmf.statemachine2.gmf. This project contains all the additional models just talked about. Here's a screenshot.
The .gmftool model defines – in our example – only a set of palette entries. The palette is the set of buttons (usually) on the right of an editor that allows you to add model elements to your model. So we need a creation tool for each of the metamodel elements that we want to be able to place onto the editor.
We also assign icons to each of the of the creation tools. Note that we don't need a creation tool for the state machine itself, since the state machine will be represented by the editor itself (more specifically, it's Canvas).
The graph model defines several (relatively separate) things.
Looking at the screenshot above, you can see Nodes named after the metamodel elements we're going to map in a minute. In the properties (which you can't see here) we connect the Node elements to the