emfGenerative

Headline

Model-Object mapping for Language:Ecore and Language:Java with Technology:EMF

Motivation

Model to Model transformations with the help of Model-Object mapping within the Java platform is exercised. The Cut feature shows an endogenous model transformation, the Total feature shows an exogenous model transformation. The primary data model for companies is an Ecore model from which an object model for "Model Code" in Technology:EMF's sense is derived. The classes of the Ecore-derived object model are somewhat richer than POJO, but their core properties and relationships are similar to a regular OO design (such as the one of Contribution:javaComposition), and operations on the Technology:EMF objects can be implemented as instance methods on the Ecore-derived classes. It should be noted that instance methods on generated classes survive re-generation because Technology:EMF is capable of distinguishing generated versus programmer-inserted class members. The Language:Ecore model is interesting in so far that it clearly demonstrates the difference between containment vs. reference relationships. In particular, the association of mentees and mentores requires a reference.

Illustration

Ecore supports modeling of structure. Ecore models are represented as XML documents. The following excerpt shows the declaration of the "classifier" for companies: elements in the Ecore-specific namespace are used to break down companies into a name and a list of departments:

<eClassifiers xsi:type="ecore:EClass" name="Company">
  <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
    ordered="false" lowerBound="1"
    eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
  <eStructuralFeatures xsi:type="ecore:EReference" name="depts"
    ordered="false" upperBound="-1" 
    eType="#//Department" containment="true"/>
</eclassifiers>

The Ecore-derived, Java-based object model will not be illustrated here because it covers properties and relationships that are similar to a regular OO design, and all additional fields and methods are not used in the basic scenario at hand.

Objects of the Ecore-derived model can also be serialized to or de-serialized from XML (XMI). To this end, the namespace for the model and its implementing package need to be registered with the registry of EMF EPackage. Thus:

EPackage.
  Registry.
  INSTANCE.
  put(CompanyPackage.eNS URI, CompanyPackage.eINSTANCE);

Further, a specific serialization format has to be chosen. To this end, a number of idiosyncratic objects have to be constructed and configured so that a preferred file extension is mapped to the intended serialization behavior. For instance, the process of loading a company from an ".xmi" file is organized as follows:

ResourceSet resourceSet = new ResourceSetImpl();
resourceSet.
  getResourceFactoryRegistry().
  getExtensionToFactoryMap().
  put("xmi", new XMIResourceFactoryImpl());
Resource xmiResource = 
  resourceSet.
  createResource(URI.createFileURI("sampleCompany.xmi"));
xmiResource.load(null);
Company c = (Company)xmiResource.getContents().get(0);

That is, XMIResourceFactoryImpl is a resource factory for XMI; there is also a resource factory XMLResourceFactoryImpl for XML. When they are used upon saving, XMI and XML output are almost identical; the XMI file though contains a namespace declaration and an attribute referring to XMI.

Architecture

Summary

File model/Company.ecore is the Ecode model of companies. File model/Company.genmodel is the EMF generator model which has been derived from the Ecore model; see below. Files model/Company*.xsd are XML schemas for XML instances of the Ecore model; they were derived with the Export functionality from the generator model; see below. Package company and subpackages contain the model code for companies. Most of this code has been generated from the generator model (see below) but the generated code has been enriched with instance methods for Feature:Total and Feature:Cut. (We leverage the EMF convention that all generated members are marked by @generated whereas the manually injected members do not carry such markers. In this manner the model code can be regenerated without overriding manually injected members.) Package org.softlang.features.Serialization contains boilerplate code for serialization. Package org.softlang.tests contains JUnit tests for operations on companies and serialization.

Transcript

Creation and evolution of an EMF project with support for serialization is not straightfoward.

The following transcript documents the essential steps and constraints.

Create EMF Project

• -> New -> Empty EMF Project ...

Create Ecore Model

• -> New -> Ecore Model
• Choose the "model" folder of the EMF project.
• Adjust name of model (default My.ecore) if needed.
• Now it is time to work out the Ecore model.
• One needs to define name of the package, namespace URI, and prefix.

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="foo"
    nsURI="www.foo.com" nsPrefix="bar">
  <eClassifiers xsi:type="ecore:EClass" name="xyz"/>
</ecore:epackage>

Create EMF Generator Model

• Select the Ecore model in the package explorer.
• -> New -> Generator model
• Choose the "model" folder of the EMF project.
• When asked for a Model Importer, choose Ecore Model.
• When asked for Model URIs, you must Browse Workspace, and select the Ecore file.

Generate Model Code

• Open the generator model.
• Right click on it in the opened view.
• -> Generate Model Code

• build.properties
• plugin.properties
• plugin.xml
• src/<your-ecore-name></your-ecore-name>
• src/<your-ecore-name/impl></your-ecore-name/impl>
• src/<your-ecore-name/util></your-ecore-name/util>

Enable XMI/XML resources

• Open plugin.xml with plug-in manifest editor.
• Select Dependencies tab.
• Add org.eclipse.emf.ecore.xmi.impl to imported packages.

Create XML Schemas

• Right click on Company.genmodel.
• Select "Export Model ...".
• Select "XML Schema" and provide name such as "Company.xsd".
• Select "XML Schema for XMI" and provide name such as "CompanyXMI.xsd".

Usage

If you use Eclipse Modeling Tools, then you have everything you need.

If you use a different Eclipse Download, you may need to add the EMF plugin (it is tested with Version 2.6.1).

Update-Site: http://download.eclipse.org/modeling/emf/updates/releases/

• The implementation is provided as an Eclipse project.
• Hence, open the project with Eclipse; this will also build the project.
• There are JUnit tests available in package org.softlang.tests.
• If you change the Ecore or generator models, you may need to rerun some EMF tools; see the transcript above.

Issues

• It is not obvious how to make good use of the generated XML schemas. Validation code should be added so that it is shown how the two schemas Company.xsd and CompanyXMI.xsd can be used for actual validation of presumably sampleCompany.xml and sampleCompany.xmi. In fact, it would also be good to some negative testcases such as an XMI file that can be validated with the XML schema, but which cannot be loaded as a resource. This would make the point that extra validation is performed by EMF. The particular negative test case could exercise, for example, stress the issue of references for mentors. Likewise, some test case should demonstrate the substantial differences between Company.xsd and CompanyXMI.xsd; to this end, it needs to be understood how these different schemas are actually supposed to be used.
• The generated types end up in the "company" package at the top, whereas it should be "org.softlang.company" for better alignment with other implementations. It is not obvious how to control the package accordingly.
• This is more of an idea for another implementation. The generated classes are only used in the simplest POJO-like manner. The generated code also supports richer idioms/design patterns, which should be possibly demonstrated. Likewise, an editor for companies based on EMF or GMF could be targeted.