Exeed is an extended version of the built-in EMF reflective editor that enables customisation of labels and icons by adding annotations to ECore metamodels. Another feature it provides is the ability to display structural information about the elements of an EMF model. To see the types of all elements in the editor tree as well as the feature in which each element is contained, open your EMF model with Exeed and click Exeed->Show Structural Info.

By doing this, the structural information of each element appears next to its label. For example, selecting this option for a GMF .gmfgraph model will make it look like this:

The red-underlined text shows the type of the element (FigureGallery), the blue-underlined text shows the feature in which it is contained (figures), and the green-underlined text shows the EClass that owns the containing feature (Canvas). So next time you need to open an EMF model with a text editor to inspect its structure by reading the underlying XMI, you may want to consider giving Exeed a try instead.

We’ve launched a satellite project of Epsilon, called EpsilonLabs (http://epsilonlabs.sourceforge.net), where we are hosting experimental contributions built atop Epsilon and contributions that use libraries which conflict with EPL (and as such they cannot be hosted in the Eclipse CVS). The initial contributions to EpsilonLabs include two non-EPL drivers for accessing MDR (MOF 1.4, XMI 1.x) and Z (LaTeX) models from Epsilon programs, and an experimental integration of (a slightly modified version of) EMF Compare with the Epsilon Comparison Language (ECL).

For the past couple of weeks we’ve been working on migrating to ANTLR 3 (to get rid of the dependency to the nasty ANTLR 2.x jar which we are not allowed to store in the CVS). Although ANTLR 3 was made available quite sometime ago, it didn’t provide any grammar reuse/inheritance mechanisms (which is essential for Epsilon since all its languages reuse the grammar of the core EOL language, and the merging language (EML) also reuses the grammar of the transformation language (ETL)).

Fortunately, an early version of ANTLR 3.1 which was released a month ago added support for grammar reuse and it is now possible to do the migration. Rewriting the grammars for v3.1 has not been as smooth as we expected, however, we will have (hopefully) fully migrated to ANTLR 3.1 by early July.

[Update 23/6/2008] The migration process is now finished. This includes all the languages of the platform as well as the HUTN implementation.

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:

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);
	}
}

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.

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.

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.

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.

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…

context UML!Class {

	constraint CorrespondingTableExists {

		guard : not self.abstract

		check : DB!Table.allInstances.
			exists(t|t.name = self.name)

		message : 'Table ' + self.name +
			' not found in the DB model'

		fix {

			title : 'Create table ' + self.name

			do {
				var t := new DB!Table;
				t.name := self.name;
			}
		}

	}

}

The constraint is expressed in the context of UML!Class which means that it will be evaluated for all instances of Class in the UML model. In its guard part, the constraint defines that it does not apply to abstract classes. The check part iterates through all the instances of Table in the DB model and tries to find one that has the same name with the class the constraint is currently being checked on (self). If the check part is not satisfied for some particular class, the message part of the constraint is evaluated to provide a meaningful message to the user (e.g. for a Customer class the message would read Table Customer not found in the DB model).

Finally, the constraint also defines a fix that attempts to resolve the inconsistency by creating a table with that name in the DB model. The fix part defines 2 sub-parts: the title (which would evaluate to Create table Customer) and the do part that actually resolves the inconsistency by creating a table. Here it is worth mentioning that one can define multiple alternative fixes for a constraint which the user can select (or not) to execute if the constraint fails.