ay by day, Model Driven Architecture (MDA) is gaining more focus in many organizations. MDA stresses the benefits of modeling at various levels of abstraction and the integration and flow of information among models. With MDA, first the object model is built, which differentiates it from the traditional approach of server side development. Models are built after good communication between various team members, and after modeling completion, development of software and systems is enabled.

With the help of MDA, business and application logic remains shielded from burgeoning technologies. It results in increased productivity for developers by maximizing compatibility between systems, simplifying the process of design and by smooth flow of information. Code built using MDA approach is consistent and maintainable.

Figure 1. Figure GMF Development Flow: This chart shows the flow for developing a graphical editor using GMF.

MDA can be achieved by using UML, DSL (Domain Specific Language), or other modeling solutions. DSL is one of the most efficient and proven ways of creating an MDA-based solution. There are many frameworks available for DSL like xText, EMF, GMF, Groovy, etc. In the following article we will showcase how to achieve MDA using GMF as a domain specific language.

What Is GMF?

Eclipse Graphical Modeling Framework (GMF) is a Domain Specific language framework which is used to develop graphical editors based on Eclipse Modelling Framework (EMF) and Graphical Editing Framework (GEF). It helps in defining the domain model, their properties, and relationships among them. A set of configuration files like meta model, graphical model, tooling model, and the mapping model are defined. These configuration files provide graphical representation of domain model, its constraint etc.

GMF Development Flow

Figure 2. Use-Case Description: This method divides the application into three nodes.

The screen shot shows the basic flow for developing a graphical editor using GMF. The starting point for creating the graphical editor plugin is to create a domain model file. It is used for creating graphical model, tooling model and mapping model. The graphical model is used to define various graphical properties of nodes and links in editor. The tooling model defines the palette which contains tools for creating nodes and links. The mapping model binds the domain model, graphical model, and tooling model together, which is then used for further processing.

How to Create a Graphical Editor Plugin

This tutorial depicts the steps for creating a GMF-based plugin. Before creation, there is a need to define the metamodel / domain model which defines various models and relationships among them. Let?s take a simple example of Entity based Application development. We will divide the Model into 3 nodes ? Application, Entity & Attribute where application consists of one or more entities, where each entity dilutes into the set of attributes.

Follow Figure 2 for a better understanding.

This is the model that we are going to follow throughout our tutorial. Before directly diving into the series of steps, let?s see how the graphical editor looks after completion. This will give the basic idea of what we’re going to create.

Figure 3. Final Product — Graphical Editor: This is what the graphical editor looks like when you’re done.

In Figure 3, the root of the editor is the topmost node, i.e. Application. Customer and order are entities which contain attributes like custId, custName and orderId, address respectively. Arrow drawn between entities shows relation between them. So with the idea of what we are going to do, we will dig down further.

Step 1: Setup

To work with GMF, eclipse needs GMF-based plugins to be installed. GMF plugins and its build dependencies can be found on the eclipse downloads page.

Step 2: Create GMF Project

To create a new GMF project, go to File, New, Other, New GMF Project. The project created contains a model folder that will contain all model files.

Step 3: Define Domain Model

The domain model can be described as a conceptual model that describes various models involved in a particular system, their properties, and relationships between them.

Figure 4. ECore File: This file is the backbone of the user workspace.

An ECore file is used to define the domain model in GMF. ECore is a meta model representation of the grammar enforced in MDA. It describes models, relationship among models, and constraints on models. This file is the backbone of user workspace at runtime. See Figure 4.

A new or existing ECore file can be used to proceed. To create a new ECore file, right click on Model Folder, New, Other, Ecore Model. A new file with .ecore extension is created. In this file, define the nodes and their properties.

For tutorial purposes, we are demonstrating a sample ECore file, described below.

A sample model.ecore consists of three nodes:

• Application: This is the top node in the model. It consist of two properties: name and entities. Name property is of type EString and entities is of type Entity. The application can contain one or more entities.

  Figure 5. Wizard Interface for Genmodel: This step shows how to generate a genmodel file.

• Entity: It contains three properties: name, attributes, and relation: Name is of EString type, attributes is of EClass Attribute type, and relation is of Entity type. An entity can have more than one attribute.

• Attribute: It contains four properties: columnType, property, dataType, and column. All properties are of EString type.

Set containment property to true while creating an EReference in an EClass.

Step 4: Create genmodel file

The next step is to generate a genmodel file. See Figure 5. It is used to configure the code generation options such as setting base package structure, etc. Genmodel is used to generate model and edit code. Model code is basically the java bean representation of the ECore model. Edit code is used by the graphical editor to save the state of the node. Both sets of code are generated based on the ECore model definition.

Figure 6. Generated Genmodel File: To generate the code, right click anywhere on genmodel file.

To create an EMF model, right click on ECore File, New, Others, EMF Model.

Press Finish, and a genmodel file will be generated. See Figure 6. The genmodel is an exact representation of the ECore model. It provides us the flexibility to change code generation options.

To generate the code, right click anywhere on the genmodel file and click on Generate Model Code and Generate Edit Code.

The model code is generated in the main GMF project under the src directory (see Figure 7), and the edit code is generated as a different plugin project that is dependent on the main GMF project.

Step 5: Define graphical definition

The Graphical Definition model is used to define graphical properties of nodes, links, etc., in the editor. Canvas contains all nodes that are responsible for the graphical representation of the editor.

Figure 7. Model Code: Model code is generated in the main GMF project under the src directory.

There can be five nodes under canvas:

1. Figure Gallery
2. Node
3. Connection
4. Compartment
5. Diagram Label

Let?s have a look at them one by one.

• Figure Gallery: This is the repository of figures. Figures are defined here with specific shape, size, color, line width, line color, and various other graphical properties. Then these figures are used by nodes, connections, compartments, and diagram labels to set their graphical properties.
• Node: This is the graphical representation of the domain model (ECore model, see Figure 8). Classes in domain model are represented by node. Each node refers to a figure defined in the figure gallery.
• Connection: Connections are used to link nodes together. An attribute from the domain model can be represented by a connection. Each connection refers to a figure defined in the figure gallery to get its graphical properties.
• Compartment: Compartment acts as container, which can contain nodes or another container. It must refer to a figure from the figure gallery to specify the container node.

Figure 8. Domain Model Creation: Select the root node for the editor.

• Diagram Label: Diagram labels provides text labels to be attached to the node. Text labels are used to provide feedback to the user. There are two types of diagram labels ? internal and external labels.

To create the graphical definition model, right click on the ECore File and create a new Simple Graphical Definition Model.

Click Next, select the ECore Domain Model, and click on Load. Under diagram element, all nodes from the domain model will be listed. Select the root node for the editor. That application will be the root node for our use-case. This node will act as the base of the graphical editor on which other nodes will be drawn. Click Next. The next page shows all domain model elements and their associated attributes. On this page, the selection of making domain model element is done. In this step, the categorization of the domain model element as node, link, or attribute is made. Root domain element will not be selected under any category as it represents the actual editor file of user workspace.

So following this concept and the use-case; select Entity and Attribute as node, Relation as link, and Attributes (under Entity) and property (under Attribute) as attribute (Figure 9). After configuration, finish the wizard. As soon as you click finish, a file with gmfgraph extension is created.

Figure 9. Graphical Definitions: This step shows categorization.

?

Figure 10. Generated gmfGraph File: This graph model contains a figure gallery.

As can be seen in Figure 10, the graph model contains a figure gallery that consists of figure descriptors. Figure descriptors specify the properties such as shape, color, line width, line type, etc.

By default, figure descriptor defined for Entity is of rectangle shape, and it has one label corresponding to the name attribute. Apart from figure gallery, there are Nodes, Connections, Compartment, and Diagram Label. They will use figure from figure gallery for their graphical properties.

In our case, we want Attribute node to be inside Entity and it?s just a label without any shape. Hence, Entity node will act as compartment for Attribute node.

Follow these steps to modify .gmfgraph file according to the use-case requirement:

1. As Attribute node does not have any shape, delete Rectangle AttributeFigurenode from Figure Descriptor AttributeFigure and the child Access getFigureAttributePropertyFigure present under Figure Gallery.
2. Right click on Figure Descriptor AttributeFigure and New Child -> Label. In the properties view, assign a name to it. Leave everything else in figure gallery as it is.

   Figure 11. Modified gmfgraph File: This is what the final gmfgraph file will look like.

3. Now we will configure the nodes. Node Entity is auto generated, and we will leave it untouched.
4. As Attribute does not have any shape and does not require a separate node to be defined, therefore, from node Canvas EntityModelling, delete node Attribute (AttributeFigure).
5. Right click on Canvas EntityModelling, New Child, Labels DiagramLabel. In properties view, name it as AttributeProperty, and point its Figure property to Figure Descriptor AttributeFigure.
6. The next step is to make a compartment for Attribute. Right click on Canvas EntityModelling, New Child, Compartment. Give it a name AttributeCompartment, and set the Figure property to EntityFigure.

To summarize, we have the following things in .gmfgraph file (see Figure 11):

1. Three figures descriptors EntityFigure, EntityRelationFigure, and AttributeFigure in figure gallery.
2. One node for entity.
   

   Figure 12. Tool Generation Wizard: This screen shot shows some key definitions.

3. One connection for connecting entities.
4. One compartment AttributeCompartment which uses EntityFigure and will contain Attributes.
5. Two diagram labels: EntityName and AttributeProperty.

Step 6: Define Tooling Definition Model

Tooling definition is used to define palettes and menus in the graphical editor (see Figure 12). Palette consists of tools to draw nodes and links on the editor.

To create tooling definition, right click on ECore file, and create a Simple Tooling Definition Model.

Click next, assign a name, and a page will come up in the wizard where we will select the tools for the palette.

As creation tool for Entity, Attribute and relationship is required, so check the boxes against these names. Press Finish. A file with .gmftool extension will be created (Figure 13).

Figure 13. Generated Tooling File: A palette can have more than one tool group.

In the gmftool file, Creation tool element denotes the tool in palette. The image for tool can also be changed by changing the default image. A palette can have more than one tool group. A tool group contains Creation tool elements for nodes as well as for links. Default options for palette can be customized by changing the properties.

Step 7: Define Mapping Definition Model

This is the most important step in the creation of the graphical editor. GMFMap (Figure 14) binds the information from domain model (ECore), graphical definition (gmfgraph) and tooling definition (gmftool). It maps a particular graphical node with the corresponding domain model and palette tool. So which node to draw when any tool is selected from palette and which domain element should save its state, this is configured in this file.

To create mapping definition model, right click on the ECore file and create a Guide Mapping Model Creation.

Figure 14. gmfmap Wizard Interface: This step shows the mapping nodes.

Click Next and assign a name for it. Load the ECore file, select the same root node, load tooling model, and load graphical model. Now a page comes up where the classification of domain model elements as node or link is done. It lists all nodes and links. In our case, Attribute is not a link and it is not a top node (node having shape). It will come inside Entity node so we will remove Attribute from the list and press Finish.

A file with gmfmap extension will be created.

Let?s have a look into the details of .gmfmap file. There is top level map registry node, under which there is Mapping node. Mapping node consists of a Top Node reference (Figure 15), Link Mapping, Canvas Mapping, and few other nodes.

• Top Node reference is used to bind the node with its creation tool and domain model element, and it can contain only a Node Mapping. Node Mapping contains the information about the node which will be drawn on the editor when a tool is selected from the palette and its binding with domain element in metamodel. A Node Mapping can have Constraint, Label Mapping, Feature Label Mapping, etc.
• Label Mapping is used when the label is not to be mapped with any feature and its value is hardcoded in graph.
• Feature Label Mapping is used to put a label on the graphical node and it binds Diagram Label created in graph with the feature of domain element.
• Compartment Mapping is used for compartment creation and mapping it to some domain model element.

Figure 15. Binding of Domain Element, Tool, and Diagram Node: This step shows the top node reference options.

• Link Mapping is used to specify information about link, its diagram tool, and domain model element. It contains information about source feature, target feature, diagram node, tool, and many other properties.
• Canvas Mapping maps domain meta information, palette information, and visual representation together.

There is already a top node reference containing entity in the generated one. This top node reference contains mapping between diagram node, domain model element, and tool. It has a feature label mapping pointing to diagram label EntityName. This is a placeholder, where the name of entity will be given on final editor. Now, attribute node will come inside entity so we need to have a compartment for that and a label for displaying the name of attribute. There is also a link mapping which contains information about relation of two entities.

Some part of the requirement is auto-generated. The rest of it, we will create. Let?s see how. Follow the steps to change it:

Figure 16. Link Mapping: Right click on the node mapping step.

1. As Attribute node has to come under Entity node so we need a compartment mapping for it. Right click on Node Mapping -> New Child -> Compartment Mapping. Set its compartment property to AttributeCompartment (created in graphical model).
2. Attribute node is a child node for Entity. So we need to create a Child Reference and a node mapping for Attribute in compartment. For this, right click Node Mapping -> New Child -> Child Reference and set its compartment property to compartment mapping (just created) and point containment property to Entity.attributes:Attribute (Figure 16).
3. Right click on child reference, Node Mapping and set its Element, Diagram Node, and Tool property for Attribute.
4. We need to have a label also for the node created. So right click on Node Mapping, Feature Label Mapping, and set its Diagram Label to DiagramLabel AttributeProperty and features property to property: EString.

Now after defining all the nodes and links, the next step is to create a generator model.

Step 8: Create Generator Model

Generate model is input for the code generator. It is like a layer between mapping definition model and code generator. It contains the information from all files created till now. It provides more generation-specific details like class/package name or some specific parameters.

To create the generator model, right click on gmfmap file and Create Generator Model (Figure 17).

Figure 17. Generate Diagram Code: This creates a new project.

A file with gmfgen extension is created. The behavior of the graphical editor and its file can be customized by setting the properties such as diagram and domain file extension, package prefix, activator class name, saving diagram and domain information in same file, etc.

We will modify gmfgen file by changing its properties. We want single file for domain and diagram information and ?model? as extension. To achieve this, click on Gen Editor Node and set Same File For Diagram and Model to true and change Diagram File Extension & Domain File Extension properties to ?model.?

Step 9: Generate Diagram Code

The last step in the creation of the graphical editor is generating diagram code. Generated diagram code is based on the properties in gmfgen file which in turn represents metamodel, graphical, tooling and mapping models. GMF uses Java Emitter Templates (JET) to generate source files from its EMF models. Templates are located in the org.eclipse.gmf.codegen plug-in, under the templates directory and they are arranged in commands, editor, part, policies and providers folders. There is a main Generator class which utilizes EmitterFactory to load templates and generate the java code.

To generate Diagram code, right click on gmfgen file, Generate Diagram Code. This creates a new project with .diagram appended to the core project name in same workspace. That?s it.

Figure 18. All Projects Created: This step shows your directory structure.

After generating the diagram code, your directory structure (Figure 18) should consist of main core project, one project with .diagram appended and one project with .edit name appended.

To run it, right click on any of these projects and RunAs, EclipseApplication. In runtime environment, create a new Model Diagram by right clicking and selecting Model Diagram (under Examples menu). Give a name to it and press Finish. A file with .model extension will be created in the specified location. We can use plugin.xml to customize the menu under which we want it to display.

As we have selected Application node as the root node for editor, therefore, properties view is showing its attributes when clicked on it.

Now click Entity from palette and drop it on the editor and give it a name. Drop Attributes inside Entity and specify properties. Use EntityRelation to make a connection between two nodes. See Figures 19 and 20 for reference.

As MDA is gaining more and more attention every day, there is a need to create a solution following the MDA approach. GMF helps us in achieving it easily and creating models which simplifies the development of an application. Following the MDA approach increases the pace of development and results in ore consistent and maintainable code. Apart from benefits provided by MDA, below are the advantages of GMF over other domain specific language frameworks:

Figure 19. Graphical Editor: This step shows the properties view.

• GMF comprises of EMF and GEF which provides advantage of developing a rich, graphical, modeling oriented editor from a domain element.
• Efforts for graphical editor development reduce drastically.
• Various models can be visualized by using this framework.
• GMF generates the code based upon model that can be modified manually also.

Models created using MDA are ultimately transformed to source code like Java, C++, etc. and associated resource files. This is known as model-to-text transformation. Model-to-text transformation generally uses templates to generate the text files. Some of the commonly used templating languages are:

Figure 20. Graphical Editor with Entities and Attributes: Use EntityRelation to make a connection between two nodes.

• JET (Java Emitter Templates)
• Freemarker
• Velocity
• Xpand (part of openArchitectureWare)
• Acceleo Template Language

You now know all the required steps for creating a GMF-based plugin.