We have moved!

We’ve moved most of the articles in this blog and added lots more under http://eclipse.org/epsilon/doc/articles/

Epsilon Flock

We’ve just released Epsilon v0.8.9, which includes many improvements and bug fixes, as well as a new task-specific language, Epsilon Flock. Epsilon Flock is a model-to-model transformation language tailored for migrating models following changes to their metamodels.

In some cases, specifying migration with existing model-to-model transformation languages can be cumbersome. For example, consider the ETL code below, for migrating Persons to a metamodel that has extracted a Telephone class:

rule Person2Person
  transform old : Old!Person
  to        p   : New!Person  {

    p.name = old.name;
    p.address = old.address;
    p.gender = old.gender;
    p.dob = old.dob;

    p.telephoneNumber = new New!TelephoneNumber;
    p.telephoneNumber.areaCode = old.areaCode;
    p.telephoneNumber.number = old.number;
}

In the transformation above, there is some redundancy. Firstly, model elements that have not been affected by the metamodel evolution (such as name, address, gender and dob), must be copied from old to new Persons. In Epsilon Flock, the values of these features are copied automatically. Secondly, the Person rule must define a source type and variable and a target type  and variable. In Epsilon Flock, migration rules are scoped to a single type, and two built-in variables (original and migrated) are used to access old and new Persons. The following Epsilon Flock code is equivalent to the ETL above:

migrate Person {
    migrated.telephoneNumber = new Migrated!TelephoneNumber;
    migrated.telephoneNumber.areaCode = original.areaCode;
    migrated.telephoneNumber.number   = original.number;
}

Epsilon Flock also provides concise mechanisms for changing the type of  and deleting model elements, and we have plans to enhance the language in future versions of Epsilon.

We’ve added to the Epsilon website documentation, an example and a screencast to help you get started with Epsilon Flock. There’s also a technical report, which includes examples of Epsilon Flock for migrating a Petri nets model and a UML class diagram. The Epsilon Flock paper will appear at ICMT 2010 in late June. As always, please do leave questions and feedback in the Epsilon Forum, and we’ll get back to you.

EuGENia: Polishing your GMF editor

EuGENia is a front-end for GMF that enables developers to generate a fully functional GMF editor by attaching a few high-level annotations to the Ecore metamodel. The original aim of EuGENia was to lower the entrance barrier for new GMF users and enable people to quickly and easily develop the first version of their editor.

However, after the initial excitement of (at last) being able to get a working GMF editor with minimal effort and no cryptic error messages, all users (including ourselves) used to come to a dead-end. EuGENia could generate an editor that looked 90% similar to what we wanted but when we started polishing the .gmfgraph, .gmftool, .gmfmap and .gmfgen models manually to get to 100%, it meant we couldn’t use EuGENia any more as subsequent invocations of the tool would overwrite our manual changes. Obviously, providing support in EuGENia for all the options that GMF provides wouldn’t be reasonable either as this would progressively make EuGENia as complex as GMF itself.

Our first thought was to try merging (instead of overwriting) the generated with the existing GMF models, but due to the complexity and inter-weaving of these models we’ve found no sensible way of doing this in an automated way. Therefore, we’ve come up with a different solution.

Behind the scenes, EuGENia runs set of model-to-model transformations written in EOL which generate the necessary GMF models from the annotated Ecore metamodel. In order to accommodate the need for persistent customizations, we’re now allowing developers to specify their own little EOL scripts next to the annotated Ecore metamodel, which are responsible for customizing the generated GMF models.

Let’s go straight into a short example. We define this minimal flowchart metamodel using Emfatic.

@namespace(uri="flowchart", prefix="flowchart")
package flowchart;

@gmf.diagram(foo="bar")
class Flowchart {
   val Node[*] nodes;
   val Transition[*] transitions;
}

@gmf.node(label="name", label.icon="false")
abstract class Node {
   attr String name;
   ref Transition[*]#source outgoing;
   ref Transition[*]#target incoming;
}

@gmf.link(label="name", source="source",
   target="target", target.decoration="arrow")
class Transition {
   attr String name;
   ref Node#outgoing source;
   ref Node#incoming target;
}

class Subflow extends Flowchart, Node{

}

@gmf.node(figure=
	"org.eclipse...examples.flowchart.diagram.figures.SquareFigure")
class Action extends Node {

}

@gmf.node(figure=
	"org.eclipse...examples.flowchart.diagram.figures.DiamondFigure")
class Decision extends Node {

}

We then use EuGENia to generate a GMF editor out of it and here is what we get:

However, what we’d really like to get is this (spot the differences?)

To achieve this we need to tweak a few things in the flowchart.gmfgraph model:

We can either do these changes manually after every invocation of EuGENia (boring), or specify the changes in the following ECore2GMF.eol script next to our metamodel.

ECore2GMF.eol:

-- Set text of transitionLabel to empty string
var transitionLabel = GmfGraph!Label.
	selectOne(l|l.name='TransitionLabelLabel');
transitionLabel.text = '';

-- Add bold font to actionLabel
var actionLabel = GmfGraph!Label.
	selectOne(l|l.name='ActionLabelFigure');
actionLabel.font = new GmfGraph!BasicFont;
actionLabel.font.style = GmfGraph!FontStyle#BOLD;

-- Add italic font to actionLabel
var decisionLabel = GmfGraph!Label.
	selectOne(l|l.name='DecisionLabelFigure');
decisionLabel.font = new GmfGraph!BasicFont;
decisionLabel.font.style = GmfGraph!FontStyle#ITALIC;

Now, each time we click Eugenia->Generate GMF tool, graph and map models, EuGENia will perform the built-in transformation and then it will also run our custom script on the generated models so that we can get the tailored output we need. Similarly, by specifying a transformation named FixGMFGen.eol we can customize the generated .gmfgen model (in this example we add a dependency to the figures plugin).

Except for enabling developers to now use EuGENia throughout the GMF editor development process, this extension also provides a good evolution mechanism for EuGENia itself. Reoccurring scripts will be good candidates for inclusion in the form of high-level annotations, that will be natively supported by future versions of the tool.

The complete source code of this example is available (projects named org.eclipse.epsilon.eugenia.examples.flowchart.*) in the SVN. You can also find another example, as well as more technical details about this extension here.

New in Epsilon 0.8.5

Apart from adding support for managing inconsistent EMF models with HUTN, and fixing several bugs, version 0.8.5 of Epsilon also includes a few new and noteworthy features.

Use of = both for assignment and for comparison

As EOL builds on OCL, it (re)uses = for comparison (e.g. if (a = b) {…}) and := for assignment (e.g. a := b;). As Louis reported here, this has been a source of confusion and well-camouflaged errors because when a mistyped a = b; assignment statement is executed, it will do nothing, but will not complain either. To deal with this we decided to follow the old VB6 paradigm and support = both for assignment (in addition to the := that of course still works) and for comparison. Therefore, since 0.8.5 the following code runs just fine:

var x = 2;
(x*x).println(); -- prints 4

Support for additional options in EuGENia

We’ve added support for several more options to EuGENia (the front-end provided by Epsilon for simplifying the development of GMF editors), such as for specifying if the model and the diagram are to be stored in the single file, for defining the extensions of the model and diagram files etc. A complete list of the supported options is available here. Kudos to Michael Moser for putting in these requests for enhancement in the bugzilla.

Support for float and double numbers in EOL

The EOL Real type now provides support both for Double and for Float numbers (only floats were supported up to 0.8.4). Kudos to Aleksander Bandelj for raising this issue in the bugzilla.

ANT tasks for EMF models

The new epsilon.emf.loadModel task has been added to the list of Epsilon ANT tasks as an alternative for the generic – but more cumbersome – epsilon.loadModel task. Using the new task, a sample UML model can be loaded as follows:

<project default="main">
  <target name="main">

    <epsilon.emf.loadModel
      name="MyUMLModel"
      modelfile="sample.uml"
      metamodeluri="http://www.eclipse.org/uml2/2.1.0/UML"
      read="true"
      store="false"
      />

    <epsilon.eol>
      MyUMLModel!Class.all.size().println();
      <model ref="MyUMLModel"/>
    </epsilon.eol>

  </target>
</project>

We’ve also added two more EMF-specific tasks. The epsilon.emf.register task, which registers the EPackages of an Ecore file to the EPackage registry:

<project default="main">
  <target name="main">

    <epsilon.emf.register
      file="sample.ecore"
    />

  </target>
</project>

and the epsilon.emf.loadRegisteredMetamodel which can load a registered EPackage as a model that can be then accessed by other Epsilon tasks:

<project default="main">
  <target name="main">

    <epsilon.emf.loadRegisteredMetamodel
      name="UMLM2"
      metamodeluri="http://www.eclipse.org/uml2/2.1.0/UML"
      />

    <epsilon.eol>
      UMLM2!EClass.all.size().println(); -- Prints 246
      <model ref="UMLM2"/>
    </epsilon.eol>

  </target>
</project>

We are working on more enhancements, such as support for multiple iterators in first order logic operations (kudos to Edd Turner), and Java-ifications for the upcoming 0.8.6 which will be made available in late June. Stay tuned!

Managing Inconsistent Models with HUTN

A model and metamodel are consistent when the metamodel specifies every concept used in the model definition. A metamodel can evolve (be adapted by a developer), which can cause inconsistency. We’ve recently added a tool to Epsilon, the HUTN / XMI bridge, that seeks to aid developers in manually managing inconsistency.

HUTN, an OMG standard, specifies a human-usable, textual notation for MOF-based models. Epsilon provides an implementation of HUTN for Ecore-based models. HUTN can be thought of as an alternative concrete syntax to XMI. While XMI is optimised for use by machines, HUTN is optimised for use by humans. We discuss HUTN in more detail in this paper at MoDELS 2008.

We have recently extended our HUTN implementation to include an XMI bridge, which allows us to generate HUTN source code from EMF models. Furthermore, the HUTN / XMI bridge can be used to report inconsistencies between a model and its metamodel, and to resolve those inconsistencies using a human-usable notation.

Example

To demonstrate the HUTN / XMI bridge, here’s a short example. Below is an exemplar metamodel, along with a sample model:

Channel B has ConnectionPoint both?! as its reader and as its writer.

Suppose we now wish to make distinct ConnectionPoints that are used for writing and ConnectionPoints that are used for reading. We may elect to change our metamodel, as shown in the diagram below:When we try to load our model with EMF, we receive a single error, stating, for example, that “The class ‘ConnectionPoint’ is not a valid classifier.” By contrast, the HUTN/XMI bridge is able to produce a complete list of the inconsistencies:

(Produced by the Check Consistency option, available by right-clicking a .model file).

To aid developers in resolving consistency, the HUTN / XMI bridge can generate HUTN from a model’s XMI, even when that model is inconsistent with its metamodel:

Once there are no further inconsistencies, HUTN can be used to generate a model that is now consistent with its metamodel.

Related Work

The HUTN / XMI bridge is a tool for manually managing inconsistency between models and metamodels. There are situations in which an automatic approach is more suitable. For example, perhaps you have a large number of inconsistent models. In those situations, we’d recommend using a different tool, such as COPE. You may also be interested in Antonio Cicchetti’s work; Cicchetti advocates a fundamentally different approach to the one used in COPE.

Installation

If you’d like to try the HUTN / XMI bridge, it’s available from the Epsilon SVN repository (access instructions). It will also appear in the upcoming 0.7.5 HUTN release*. We’ll be adding new features and fixing problems per user requests – do drop by the Epsilon newsgroup if you have questions, problems or suggestions.

* [Update 27/04/09] The HUTN XMI Bridge is included in HUTN 0.7.5, which was released today, as part of Epsilon 0.8.5.

Test-Driven Development for Epsilon

Test-Driven Development (TDD) is an approach to software development that advocates writing tests before implementation. TDD has many advantages when compared to other forms of development, in which tests are often an after-thought. Proponents argue that TDD produces clean interfaces, minimal implementations and a suite of tests that can be used to guard against regressions. (See “TDD by Example,” Beck and, to some extent, “Refactoring,” Fowler).

In the past, we’ve been reluctant to construct automated unit tests for Epsilon, largely because we lacked structures and processes for constructing and checking models in the context of a testing framework, such as jUnit.

Since developing HUTN, we’ve been discovering/inventing/hallucinating patterns for constructing and checking models that allowed us to construct tests that were readable and malleable. This week, we wanted to make an enhancement to EOL, and, using these patterns, I was able to do so in a (more) test-driven manner.

EOL defines distinct operators for comparing expressions and for performing assignment. The concrete syntax is = for the former and := for the latter. We’ve found that we’ve had a few reports of code like the following:

var a : Integer;
a = 2;

EOL compares a and 2 in the second line, rather than assigning a to 2.

We decided that we could change EOL to rewrite statements whose first operator was = to an equivalent statement whose first operator was :=

I started by defining some tests that exercised the EOL execution engine with the old behaviour and with the new behaviour:

private static final EolEvaluator evaluator = new EolEvaluator();

@Test
public void assignment() {
	evaluator.execute("var a; a := 1 + 2;");
	assertEquals(new EolInteger(3), evaluator.evaluate("a"));
}

@Test
public void equalityActsAsAssignment() {
	evaluator.execute("var a; a = 1 + 2;");
	assertEquals(new EolInteger(3), evaluator.evaluate("a"));
}

I’m using the EolEvaluator class, which decorates the EOL execution engine and can be used to execute small snippets of EOL code.

The first test passed, and the second test failed as expected. Typically, we’d now define some unit tests on the unit that needs to change to accommodate those changes, but I’ll leave that as an exercise for your imagination.

Crucially, because I’d used TDD, I felt comfortable editing a piece of code that I’d not developed, and never touched before – I had tests that verified (to some extent) my work. Plus, we’ve got tests that guard against regression in this part of EOL.

Epsilon + AppEngine + Ajax = Epsilon Live

The Epsilon website already includes several screencasts and examples that demonstrate the tools and languages it provides. The preview release of the Google App Engine for Java has made it possible to go one step further and allow people to actually write and execute EOL (the core language of Epsilon) programs straight from their browser without needing to download or install anything.

http://www.eclipse.org/gmt/epsilon/live includes an editor where one can write and execute EOL scripts, and a console that captures their output. Apart from playing with the basic features of EOL (variables, control flow structures etc.) one can also query/modify a live EMF model (which for simplicity is Ecore itself). To help you get started, the page also provides a number of ready-to-run scripts as a starting point for further exploration.

The EMF EPackage Registry View

The EPackage registry (EPackage.Registry.INSTANCE) contains references to all registered ECore EPackages in EMF. To visualise the contents of the registry, we have implemented the following EPackage Registry view.

Using this view, one can browse through the EClasses contained in each registered EPackage, discover the super/sub types of each EClass, and navigate through its features and operations. The view provides options to show/hide derived features, operations, inherited features and opposite references, supports quick navigation from a feature to it’s type (double-click), and integrates with the Properties view.

If you’d like to give it a spin, it comes as a part of Epsilon 0.8.3 (or later) and can be installed via the update site.

Error Markers and Quick Fixes in GMF editors using EVL

The Epsilon Validation Language (EVL) is a model validation language that provides additional features to OCL, such as guards, constraint dependency management, user interaction, access to Java objects, and the ability to specify a number of fixes for each constraint, that the user can invoke if the constraint fails in order to repair the model. We’ve been recently working on integrating EVL with GMF so that failed constraints can appear as error/warning markers in GMF editors, and fixes can be invoked using the standard Quick Fix mechanism. An example follows:

The following screenshot shows a file system model in a GMF-based editor (constructed here).

We now specify the following EVL constraints and bind them to the editor (using the instructions provided here):

context File {
 
    constraint HasName {
 
        check : self.name.isDefined()
 
        message : 'Unnamed ' + self.eClass().name + ' not allowed'
 
    }
 
}
 
context Folder {
 
    critique NameStartsWithCapital {
 
        guard : self.satisfies('HasName')
 
        check : self.name.firstToUpperCase() = self.name
 
        message : 'Folder ' + self.name +
            ' should start with an upper-case letter'
 
        fix {
 
            title : 'Rename to ' + self.name.firstToUpperCase()
 
            do {
                self.name := self.name.firstToUpperCase();
            }
        }
 
    }
 
}
 
context Sync {
 
    constraint MustLinkSame {
 
        check : self.source.eClass() = self.target.eClass()
 
        message : 'Cannot synchronize a ' + self.source.eClass().name
            + ' with a ' + self.target.eClass().name
 
        fix {
 
            title : 'Synchronize with another ' +
                self.source.eClass().name
 
            do {
 
                var target := UserInput.choose('Select target',
                    _Model.getAllOfType(self.source.eClass().name));
 
                if (target.isDefined()) self.target := target;
 
            }
 
        }
 
    }
 
}

Then, we evaluate the constraints by clicking Diagram->Validate, and our editor and Problems view now look like this:

We can now right click on the warning and invoke quick fix we have defined for the NameStartsWithCapital critique.

 

By clicking Finish, the fix is executed and the warning disappears.

A complete reference of the syntax and semantics of EVL can be found in Chapter 6 of the Epsilon Book (PDF). Also, instructions for binding EVL constraints with an existing GMF editor can be found here. Finally, a Flash screencast of this example is available here.

New in HUTN 0.7.1

Last week we released v0.7.1 of our Human-Usable Textual Notation implementation. It’s available as part of Epsilon 0.8.1. In this release, we’ve aligned our implementation more closely to the OMG specification, and added some new features. Here’s a summary of the changes:

Validation

An error is now produced when enumerations, data types and abstract classes are specified as the type of an object.

An error is now produced for objects that do not specify the value of attributes with a lower bound greater than zero.

Adjectives

Positive adjectives are no longer prefixed with the # symbol. For instance:

DogPackage {
    male Dog "Fido" {}     // old syntax was #male Dog
}

Adjectives prefixed with the # symbol will cause a deprecation warning.

Enumeration Values

Support for enumeration values in association instances has been added. The syntax is:

DogPackage {
    Dog "Lassie" {
        breed: Collie    // Enumeration value
        name: "Lassie"   // String value
    }
}

Classifier-Level Attributes

Support for classifier-level attributes has been added. The syntax is:

DogPackage {
    Dog.breed: Collie;  // All dogs in this package are Collies by default

    Dog "Lassie" {}
    Dog "Jessie" {}

    Dog "Scooby" {
        breed: GreatDane
    }
}

Classifier-level attribute values take precedence over any default value rules specified in a HUTN configuration model.

Associations: Block and Infix Notations

Support for association blocks has been added. Assuming that the Family class has a reference called “pets” accepting objects of type Dog, the syntax is:

DogPackage {
    Family "The Smiths" {}
    Dog "Rover" {}
    pets {
        Family "The Smiths"
        Dog "Rover"        // Refers to the existing Pet object, defined above
        Family "The Smiths"
        Dog "Fido"        // Created automatically by the association block
    }
}

Similarly, associations may be specified using an infix notation. The example above could be written:

DogPackage {
    Family "The Smiths" {}
    Dog "Rover" {}
    Family "The Smiths" pets Dog "Rover";
    Family "The Smiths" pets Dog "Fido";
}

We hope you find the improved validation and more flexible syntax useful. You can update your installation using the Eclipse update manager, or follow the instructions on the Epsilon download page.