Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Model-Driven Architecture with GMF : Page 2

This approach results in increased productivity for developers by maximizing compatibility between systems and simplifying the design process.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

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.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date