We have moved!

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

Posted in Uncategorized | Leave a comment

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.

Posted in Uncategorized | Leave a comment

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:

image

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

image

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

image

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.

image

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.

Posted in Uncategorized | 10 Comments

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!

Posted in Uncategorized | Leave a comment

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:

channels_mm_beforechannels_model_before

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:channels_mm_afterWhen 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:

channels_model_hutn_xmi_errors(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:

channels_hutn_with_errors

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.

Posted in Uncategorized | 3 Comments

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.

Posted in Uncategorized | 2 Comments

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.

image

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.

Posted in Uncategorized | 4 Comments