Headline

reflexive Technology:EMF Model to Model transformation

Motivation

This implementation demonstrates Model to Model transformations with Technology:EMF for Language:Java. Contrary to Contribution:emfGenerative, the models properties are accessed and modified by reflexive method calls to the EMF Model itself. The metamodels used in this implementation are given in Language:Ecore, models are in Language:XMI. The implementation uses the Total scenario to show a exogenous model transformation. The Cut scenario shows an endogenous model transformation.

Illustration

The structure of a company can be modeled as a metamodel. By doing so, one can load any company conforming to this metamodel by first loading the metamodel and then loading the actual model:

/* Load metamodel */
Resource companyMetamodel = resourceSet.createResource(URI.createFileURI("Metamodels/Company.ecore"));
companyMetamodel.load(null);
EPackage.Registry.INSTANCE.put("http://www.company.com", companyMetamodel.getContents().get(0));

/* code ommited */

/* Load model */
Resource companySampleModel = resourceSet.createResource(URI.createFileURI("Models/sampleCompany.xmi"));
companySampleModel.load(null);

Then, attributes can be modified using reflexive calls. For example, the Cut operation can be implemented by iterating over all elements of the model, retrieving the value for the salary if the current element is a Employee and then setting the salary attribute for this employee to the half of what was returned earlier:

if( currentModelElement.eClass().getName().equals("Employee") ) {
   EStructuralFeature salaryAttribute = currentModelElement.eClass().getEStructuralFeature("salary");
   double currentSalary = (Double) currentModelElement.eGet(salaryAttribute);
   currentModelElement.eSet(salaryAttribute, currentSalary/2);
}

Architecture

Company.ecore is the implements the data model for Feature:Hierarchical company. It is the metamodel used for the transformation and can be found in the "Metamodels" directory.

The model that holds the actual data is sampleCompany.xmi and can be found in the "Models" directory.

The model sampleCompany holds the data for the Feature:Hierarchical company.

The metamodel Total is used for the Feature:Cut feature.

The actual transformations are implemented in the class RunTransfo.

Usage

In order to execute the transformations, a Eclipse version with EMF support is needed (e.g. the Eclipse EMF version).

The project can then be imported in Eclipse. To excercise the transformations, compile and execute the Java class RunTransfo.java.

Headline

An OO programming language

Illustration

Let's show "Hello World" for Java.

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello, World");
    }

}

Headline

A model the extension (semantics) of which is a set of models

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.

Headline

A toolkit for modelware for the Java platform

Spaces

• Objectware
• Modelware
• Auxiliary XMLware

Headline

Cut the salaries of all employees in half

Description

For a given company, the salaries of all employees are to be cut in half. Let's assume that the management of the company is interested in a salary cut as a response to a financial crisis. Clearly, any real company is likely to respond to a financial crisis in a much less simplistic manner.

Motivation

The feature may be implemented as a transformation, potentially making use of a suitable transformation or data manipulation language. Conceptually, the feature corresponds to a relatively simple and regular kind of transformation, i.e., an iterator-based transformation, which iterates over a company' employees and updates the salaries of the individual employees along the way. It shall be interesting to see how different software languages, technologies, and implementations deal with the conceptual simplicity of the problem at hand.

Illustration

The feature is illustrated with a statement in Language:SQL to be applied to an instance of a straightforward relational schema for companies where we assume that all employees belong to a single company:

UPDATE employee
 SET salary = salary / 2;

The snippet originates from Contribution:mySqlMany.

Relationships

• See Feature:Total for a query scenario instead of a transformation scenario.
• In fact, Feature:Total is likely to be helpful in a demonstration of Feature:Salary cut.
• The present feature should be applicable to any data model of companies, specifically Feature:Flat company and Feature:Hierarchical_company.

Guidelines

• The name of an operation for cutting salaries thereof should involve the term "cut". This guideline is met by the above illustration, if we assume that the shown SQL statement is stored in a SQL script with name "Cut.sql". Likewise, if OO programming was used for implementation, then the names of the corresponding methods should involve the term "cut".
• A suitable demonstration of the feature's implementation should cut the salaries of a sample company. This guideline is met by the above illustration, if we assume that the shown SQL statement is executed on a database which readily contains company data. Queries according to Feature:Total may be used to compare salaries before and after the cut. All such database preparation, data manipulation, and query execution should preferably be scripted. By contrast, if OO programming was used, then the demonstration could be delivered in the form of unit tests.

Headline

Support nested departments in companies

Description

The data model of the system:Company is required to support companies and employees, just as in the case of Feature:Flat company, but in addition, employees are organized in nested departments. A company breaks down into (top-level) departments, each of which may recursively break down into (sub-) departments. Such nesting of departments enables the hierarchical organization of companies. The features Feature:Flat company and Feature:Hierarchical company are mutually exclusive and either of them must be selected for any realization of System:Company. Some features, e.g., Feature:Depth, may effectively require Feature:Hierarchical company.

Motivation

The specific contribution of hierarchical companies is that they require a recursive treatment of departments as they aggregate both, sub-departments and employees. When using an abstraction mechanism of a programming language for modeling departments (e.g., classes or types), then the corresponding abstraction has to be accordingly recursive. When processing hierarchical companies, then the corresponding functionality must be accordingly recursive, too.

There is more than one way of modeling such hierarchical companies. One approach is to use separate (homogenous) containers for the sub-departments and the employees of a department. Another approach is to use one (heterogeneous) container for both kinds of sub-units: sub-departments and employees. In the former case, (recursive) data composition is used; in the latter case, data variation is taken into account. Data composition alone may be particularly simple to implement in some contexts, e.g., with non-virtual methods in the context of OO programming and object composition. Functionality may be implemented differently because of data variation. For instance, in the context of OO programming, data variation may correspond to type generalization giving rise to subtype polymorphism and virtual methods. Further, added data variation may enable extra extensibility of genericity.

Illustration

The feature is illustrated with a data model in Language:Haskell. Algebraic data types are used for the type of departments; a type synonym cannot be used because departments can be nested and thus, a recursive type is needed:

type Company = (Name, [Department])
data Department = Department Name Manager [Department] [Employee]
type Employee = (Name, Address, Salary)
type Manager = Employee
type Name = String
type Address = String
type Salary = Float

A sample company takes the following form:

sampleCompany :: Company
sampleCompany =
  ( "Acme Corporation",
    [
      Department "Research"
        ("Craig", "Redmond", 123456)
        []
        [
          ("Erik", "Utrecht", 12345),
          ("Ralf", "Koblenz", 1234)
        ],
      Department "Development"
        ("Ray", "Redmond", 234567)
        [
          Department "Dev1"
            ("Klaus", "Boston", 23456)
            [
              Department "Dev1.1"
                ("Karl", "Riga", 2345)
                []
                [("Joe", "Wifi City", 2344)]
            ]
            []
        ]
        []
    ]
  )

These snippets originate from Contribution:haskellComposition.

Hence, there are two top-level departments, "Research" and "Development". The "Development" department further breaks down further into sub-departments. All departments have managers. Some departments have employees. Each employee has a name, an address, and a salary.

An alternative illustration of the feature shows departments with data variation such that there is a general type of sub-units with derivations for employees and sub-departments, i.e., employee units and sub-department units:

data Department = Department Name Manager [SubUnit]
data SubUnit = EUnit Employee | DUnit Department

The snippet originates from Contribution:haskellVariation.

Headline

A type-preserving model transformation

Headline

A type-changing model transformation

Headline

A transformation that transform a model into another model

Headline

The language defined by the metamodel based on the EMOF standard

Description

Ecore is the modeling language implemented by the EMF Framework.

Discussion

Note that an actual classification of the language is difficult. First, there is an XMI subset for Ecore. Thus, there may be a language EcoreXMI. Second, the set of java objects conforming to the model classes from the Ecore API may be interpreted as a language. Thus, there may be a second language EcoreJVMObjects as those object might not always be persisted as XMI.

Headline

An abstract description of structure, behavior, or other aspects of software systems

Headline

An Language:XML-based interchange format for Technology:MOF-based metadata or models