Model Refactoring in EMF editors

In this post we demonstrated how EWL from the Epsilon GMT component can be used to automate model refactoring (in-place model transformation in general) in GMF-based editors. Since version 1.3.2, the same wizards can be executed in EMF tree-based editors as well. The following screenshots demonstrate the application of the CreateAssociationClassCase1 wizard (originally described by Ed Merks here) in the default ECore tree-based editor.

The original ECore metamodel:

Selecting the classes and applying the wizard:

The ECore metamodel after the wizard has executed:

Extended properties in EOL

Below is a simple metamodel (in Emfatic) for modelling Trees (however interesting this might be)

package SimpleTree;

class Tree {
	attr String name;
	ref Tree#children parent;
	val Tree[*]#parent children;
}

Now, what we want to do is to traverse a model that conforms to this metamodel and calculate and print the depth of each Tree in it. We can do this using this simple EOL program:

var depths := new Map;

for (n in Tree.allInstances.select(t|not t.parent.isDefined())) {
	n.setDepth(0);
}

for (n in Tree.allInstances) {
	(n.name + ' ' + depths.get(n)).println();
}

operation Tree setDepth(depth : Integer) {
	depths.put(self,depth);
	for (c in self.children) {
		c.setDepth(depth + 1);
	}
}

Because the Tree EClass doesn’t have a depth property, we have to use the depths Map to store the calculated depth of each Tree. Another solution would be to add a depth property to the Tree EClass so that its instances can store such information; but applying this tactic will soon pollute our metamodel with information of secondary importance.

We’ve often come across similar situations where we needed to attach some kind of information (that is not supported by the metamodel) to particular model elements during model management operations (validation, transformation etc.). Until now, we’ve been using Maps to achieve this (similarly to what we’ve done above). However, from version 1.3.0, EOL (and all languages built atop it) support non-invasive extended properties which provide a more elegant solution to this recurring problem.

An extended property is a property that starts with the ~ character. It’s semantics are quite straightforward: the first time a value is assigned to an extended property of an object (e.g. x.~a := b;), the property is created and associated to the object and the value is assigned to it. Similarly, x.~a returns the value of the property or undefined if the property has not been set on the particular object yet. Using extended properties, we can rewrite the above code (without needing to use a Map) as follows:

for (n in Tree.allInstances.select(t|not t.parent.isDefined())) {
	n.setDepth(0);
}

for (n in Tree.allInstances) {
	(n.name + ' ' + n.~depth).println();
}

operation Tree setDepth(depth : Integer) {
	self.~depth := depth;
	for (c in self.children) {
		c.setDepth(depth + 1);
	}
}

Model Refactoring in GMF editors

To extract an interface from a UML class using the GMF-based UML2Tools class-diagram editor, one has to manually go through the following steps:

• create and name the new interface
• move the methods from the concrete class to the interface
• create a generalization between the class and the interface
• update all association ends that pointed to the class to now point to the interface

Having a wizard that could do all the above with a single click instead would arguably be a good thing. Even more, having a tool that would allow us to easily define custom wizards at a high level of abstraction by hiding the complexity of GMF would be even better.

Motivated by such scenarios, in the Epsilon GMT component we have implemented a small dedicated language (EWL) and supporting tools that enable users to specify and execute such wizards from within GMF-based editors. Our solution works with existing editors, such as the UML editors provided by the UML2Tools project, without needing to customize or re-generate them. Wizards appear in a sub-menu of the right-click menu and their effects can be undone/redone using the standard Ctrl-Z/Ctrl-Y shortcuts. Wizards are also interactive in the sense that they can prompt the user to provide additional information through standard Eclipse dialogs.

This screencast demonstrates defining and executing a wizard that implements the scenario above, as well as undoing/redoing its effects on the model. A detailed discussion on EWL can be found here and an overview of the GMF/EWL integration can be found here.

Using HUTN for T2M transformation

Recently, we have been investigating the appropriateness of using the Human-Usable Textual Notation (HUTN) as a means for providing a generic concrete syntax for instances of Ecore metamodels. A number of solutions (xText, TCS) exist for performing T2M transformation, but these solutions require the definition a specific concrete syntax for each metamodel.

Like Pierre-Alain Muller and Michel Hassenforder we have discovered that this is not always appropriate. For example, when a metamodel is being defined incrementally and iteratively, any specific concrete syntax may need to be updated regularly in order to remain compatible. clearly, this is not the case for a generic concrete syntax.

Thus far, we have constructed tooling that implements many of the core features of the HUTN specification, and provided integration with the Eclipse Modelling Framework through development tools for the Eclipse platform. In order to perform validation upon the input text and the transformation to the target model, our tooling extensively utilises model-management languages provided by Epsilon.

Presently, we are concentrating on ensuring our implementation is well-aligned with the HUTN specification, and investigating the feasibility of using HUTN during the testing of model management activities.

This flash screencast demonstrates some of the capabilities of our tooling.

Establishing links between EMF models

This flash screencast demonstrates a technique for establishing strongly-typed links between elements that belong to models of different metamodels (a.k.a weaving) using EMF and ModeLink, a simple 3-panel editor provided by Epsilon. The next part of the screencast demonstrates how to exploit such links programmatically with languages provided by Epsilon.

Critiquing the Application of Pattern Languages

In this interesting paper, Bahman Zamani and Greg Butler compare the Epsilon Wizard Language (EWL) to ArgoUML and OCLE for detecting and repairing design smells in UML models.

Using EVL to check inter-model consistency

As EVL builds on EOL, it inherits the capability to access multiple models simultaneously. An interesting application of that is that it can be used to express inter-model constraints. For example, say you have a UML and a DB model and you need to check that for each non-abstract class in the UML model there is a table with the same name in the DB model. This can easily be captured with the following EVL constraint…

Interactive Model Transformation with ETL

Sometimes, a user may need to transform only selected model elements instead of the entire model. There are (at least) three approaches to achieving this:

• mark the elements that need to be transformed
• provide an external (weaving) model that specifies which elements need to be transformed
• ask the user directly during the transformation

Cached operations in EOL

To simulate derived properties, EOL supports cached operations. A cached operation - parameter-less operation annotated with a @cached annotation - is only executed once: subsequent calls return the same result without executing its body again. An example that calculates the Fibonacci number of a given Integer follows:

15.fib();

@cached
operation Integer fib() : Integer {
	if (self = 1 or self = 0) {
		return 1;
	}
	else {
		return (self-1).fib() + (self-2).fib();
	}
}

Using Java objects in EOL

As it is the case with all languages, model management languages have a particular scope of applicability. So, while a model-transformation language is expected to be efficient at navigating and modifying models, it is not really expected to be able e.g. to perform complex string comparison efficiently or to access an external system (e.g. a DBMS).