Using EMF for META Modeling: generating concrete, reusable Java code Snippets

EMF is a major part of the Eclipse platform and is the basis for a number of relevant technologies and frameworks, such as Eclipse Visual Editor, SDO, XSD, and uml-, many of which are integrated into Rational®application develope R and Websphere®business Modeler and other IBM® platforms. The EMF now absorbs a number of Java technical features, such as enumeration types, annotations, and generics.

In most documents and tutorials, EMF is used to model data and interfaces (such as the Library and books in the EMF release document) and not for modeling behavior. There are, of course, some default method implementations for data object generation, but these implementations involve the relationship between the model elements. Also, there are very few archived examples that use EMF as a "meta model"-except for the Eclipse Foundation article "Modeling rule-based Systems with EMF"-but this example does not show how to extend the Ecore meta model 。

Finally, the process of using and extending the EMF JET template is not well documented. In addition, the JET Editor project has recently been migrated to another Eclipse project (M2T). This article is intended to clarify these issues and enable you to use dynamic templates in the EMF context to achieve more functionality. Therefore, this article assumes that you have a basic understanding of EMF.

Why extend the Ecore meta model?

What the hell is Ecore?

The Eclipse Modeling Framework (EMF) is a modeling framework for eclipse. Based on the definition of Eclipse Foundation, the core EMF framework includes a metamodel that describes the model (Ecore) and run-time support for the model, including change notification, persistent support for default XMI serialization, and reflection for performing general operations on EMF objects API (Reflective API). In other words, Ecore defines the structure of the core model, while the core model defines the model structure that developers use to maintain application data.

The Ecore meta model is a powerful tool that can be used to design model-driven architectures (Model-driven Architecture,mda), which can serve as a starting point for software development. In general, we define application-scoped objects (Eclass types), object properties, and the relationships between them. We also use the Eoperation model element to define specific actions that belong to these objects. By default, EMF will generate skeletons or method signatures for these operations, but we must go back and implement these operations, often rewriting similar logic over and over again.

But what if we want to specify some arbitrary implementation behavior in the model? One way is to add text-based annotations (eannotation types) to model objects and interpret the annotations in the template during code generation. For an excellent example of this approach, you can check out the Eclipse Foundation article "Implementing Model Integrity in EMF with MDT". However, as described in this article, our goal is not to validate the model elements, but to modeling the implementation itself so that any specific model can reuse the meta model elements. To do this, we need to extend the Ecore meta model.

Extended meta-model

This article comes with a highly simplified programming model for extending Ecore. It is not a complete or coherent meta model or framework; Strictly speaking, it is a prototype collection of elements that demonstrate the ability to use EMF to model the implementation of the Code. Figure 1 shows a snapshot of our extended Metamodel sample Ecorex, below is a short description of each element.

Figure 1. Ecorex model

Ecorex element

Epackagex extension Epackage

This is a simple "markup" extension of the Ecore element Epackage, without any additional attributes. This element is required because, by default, the element epackage EMF Editor plug-in does not allow the Eclass subclass to be added as a child element (see ECLASSX below). By providing an extensible epackage model element, the code is automatically generated, allowing a ECLASSX child element to be added to the Epackagex.