Focusing on models

Eclipse Juno: The Eclipse Model Focusing Tools Project


This article from Manuel Bork introduces the Eclipse project Model Focusing Tools (MFT) that brings Mylyn’s task-focused interface to the modeling domain.

Originally appearing in the Eclipse Juno issue of JAX Magazine, Manuel Bork discusses the Eclipse Model Focusing Tools project as it heads toward 1.0 in Kepler

Introduction to MFT

Eclipse Mylyn keeps developers in the flow of development by hiding unnecessary and irrelevant information. Modeling takes a different approach: reducing complexity by abstracting the unnecessary detail. Why not combine both approaches? This article introduces the Eclipse project Model Focusing Tools (MFT) that brings Mylyn’s task-focused interface to the modeling domain.

We are overloaded with information. Our day-to-day work consists of navigating through an increasingly complex IDE managing hundreds and thousands of software artifacts. In an average project for example, the Eclipse IDE’s project explorer alone typically contains two or three dozen projects, each consisting of some hundred source code files.

We investigate problems. We debug applications and hunt down bugs, until the relevant piece of source code is found – and then the telephone rings. Or the next meeting starts. Or a co-worker enters the room with a bunch of questions.

Keeping Information Overload low and counteracting Context Loss when switching tasks is Mylyn’s strength. It keeps developers focused on the task at hand by filtering what’s not important right now. Mylyn introduces the task as a first-class citizen into the IDE and learns about a task’s context by keeping track of all user interaction. Modifying source code, opening editors, selecting items in views – Mylyn records it and builds-up an Interaction History, adds it to the active task’s context and combines it with a quantifier (so called degree of interest).

The benefit of this? Views and editors can be filtered on the active task’s context. Irrelevant elements are hidden, interesting ones highlighted. And all this works instantly, by simply activating a task.


We create solutions for complex problems. As computation power increases, the problems that can be addressed become more and more elaborate – this has a big impact on the data software has to deal with, as well as on the software itself and its algorithms. Thinking of the automotive or aerospace industry, modeling is the only feasible solution to managing this complexity.

Eclipse Modeling delivers a rich ecosystem of technologies and tools that help reduce complexity with abstraction. Depending on their level, models serve different purposes. On higher levels, models provide overview and are a tool for communication. Being very informal, models on this abstraction layer often consist of nothing more than some lines and boxes and a few words of descriptive text. Everybody knows these sort of diagrams painted on flip charts or whiteboards. This way teams can easily discuss software architecture and corresponding design decisions. The more formal models become, the more they can be used in automatic tooling. The most famous example is of source code generation, but there are other applications, like interpreting models or automatic model validation. This sort of automatic model processing saves a lot of time and increases software quality.

Models of real life software become large. And the value of a wall-filling class diagram with a thousand classes is dubious at best (unless the goal is to create nerdy wall decorations). Typically, models can be decomposed into many smaller diagrams and views that show different aspects of the whole, somewhat alleviating this problem. For example, the class structure of a software system can be broken down into diagrams showing the data model; one containing the external API, and maybe one or two highlighting some interesting architectural aspects. Still, diagram views can quickly feel overcrowded and maintaining the right view for every occasion can be a tedious task if done manually on an evolving model. This is where Eclipse MFT comes in.

Eclipse Model Focusing Tools (MFT)

The goal of the Eclipse MFT project in a nutshell: bring Mylyn’s task-focused interface to the existing modeling tools. From a user’s perspective, working with model artifacts in a task-focused way should be as easy as it is for Java or XML: capturing a task’s modeling context based on user interaction, focusing modeling views like diagram editors or a model outline view on task-relevant items and easily switching between model-related tasks.

To do this, Mylyn needs to understand the technical aspects of a model: its structural building blocks as well as interactions on it that need to be recorded like selecting, adding or editing elements.

Figure 1 shows a high-level architectural overview of Eclipse MFT. At its core, MFT is built on top of the Mylyn Context project that acts as the foundation of this architecture. It provides the infrastructure for Mylyn’s degree-of-interest model, which gives associating task contexts and interest data with any domain-specific element. On top of this infrastructure, context bridges provide the necessary access and understanding for the different domains. The JDT bridge for example makes Eclipse’s Java tooling accessible to Mylyn by offering support for elements like Java classes, fields, and methods. In the Modeling domain, the elements Mylyn needs to understand are the building blocks of EMF’s metamodel, with the EObject class at its core.

Figure 1: Architecture of the org.eclipse.mylyn.mft project.

Thanks to EMF’s standardized access to all EMF instance models, most of the heavy lifting can be done in the basic EMF modeling bridge provided by MFT: it provides Mylyn with access to the model’s containment hierarchy and exposes the unique URIs identifying every EObject as domain object handles to the degree-of-interest model. On top of this generic modeling bridge, it is easy to build custom bridges for more specific models. Out of the box, MFT comes with task-focused editing support for Ecore models and diagrams.

The next step for MFT is to support user interaction with the model. Most model editors are already hooked into Eclipse’s selection event framework, which Mylyn supports out of the box for interaction recording. Additional listener frameworks can easily be hooked into Mylyn through its monitor API.

To provide a truly task-focused experience, model editors and views need to filter and highlight their contents based on the degree-of-interest data. Mylyn provides ready-to-use filters and decorators for structured views like lists or trees. MFT extends this support to GMF-based graphical editors through its GMF bridge. It supports fading out and hiding elements based on their current interest, keeping the layout of task-focused GMF diagrams intact. But how to interact with elements that are currently hidden because they are not part of the task context?

MFT addresses this issue by fading in hidden elements in the vicinity of the mouse cursor. Technically, hiding and fading out are realized with background-colored overlay boxes that can change their transparency. This way, existing GMF editors don’t need to be changed to add focusing support. Figure 2 shows an example of a focused EcoreTools Class Diagram editor with partial fade-in. The reference implementation for this task-focusing support using the MFT GMF bridge is shipped with the MFT project.

Figure 2: Example of a task-focused EcoreTools class diagram

If the user interacts with an element by selecting or changing it for example, the element becomes part of the task-context and stays visible. This basic functionality can easily be reused by other GMF-based editors. We will have a detailed look at this in “Mylynize your GMF-based editor with MFT” later on .


Cross-domain task-focusing

So far, we have seen Mylyn add task-focusing support to a wide range of different domains like Java and C++ programming and now, thanks to MFT, modeling. So far all these bridges coexist side by side, but isolated from one another. But are they really that separated?

Models often have a strong bonds to source code artifacts based on code generation. And next-generation reverse engineering approaches like UML Lab’s adaptable Round-Trip-EngineeringNG [2] can create compact models from existing source code, bringing modeling to legacy projects and helping stem the information flood with improved model abstraction and better overview in clean diagrams.

With this connection between models and source code in place, why not connect their task-context data as well? This is the idea of UML Lab’s Mylyn MFT integration. In [3], Andreas Scharf shows you how to bring source code context information to modeling through reverse engineering. In the meantime, UML Lab has taken this a step further, implementing a two-way-synchronization between the model’s task context on the one hand side and the JDT’s task context on the other. Figure 3 shows the synchronization process, starting with a user interaction with the Java source code and ultimately updating the model editor.

Figure 3: Synchronization between Java and MFT context information.

The user changes a method in the Java source code; the JDT Bridge’s change-listener recognizes it and pushes the information into Mylyn’s degree-of-interest model of the active task. As the interest for the Java method is changed, the JDT context informs its registered listeners about the context change.

UML Lab has such a listener and is notified about the context change. Based on round-trip information, the corresponding model element is looked up and its degree-of-interest model is updated through MFT.

As the interest of the model element changes, the model editor is updated and the corresponding visual element is revealed.

What is the benefit of synchronizing task contexts in this manner? Some development tasks are more efficiently done in the model, others directly in the source code. The user should decide where to work and when, not the tool or the process. Synchronizing contexts allows switching seamlessly between model and source code without losing focus of what’s important.

Mylynize your GMF-based editor with MFT

The MFT project aims to enable the community to bring Mylyn’s task-focused interface to their own model editors easily. The MFT framework provides ready-to-use tooling for GMF-based editors to instantly add focusing support. The EcoreTools class diagram editor showcases this tooling. Now let’s see how to support other GMF-based editors.

The Eclipse GMF project contains several example projects that show how to create GMF-based graphical editors for EMF models. Let’s pick the Taipan Example and add task-focusing support with Mylyn MFT. Taipan is part of the GMF-Tooling project located here. First import all Eclipse projects located in /examples/org.eclipse.gmf.examples.taipan.* into your workspace and resolve missing dependencies. The projects should compile error free, and if you start an Eclipse runtime instance with it, Taipan model and diagram wizards should be available. Check out this tutorial if you want to build the Taipan example on your own or are experiencing problems setting up the project.

Now let’s create a new PDE plug-in project for our Taipan Mylyn bridge, give it a name like “org.example.gmf.taipan.mylyn” and let the Plug-In wizard create an Activator. Next, set up some project dependencies. The new plug-in requires dependencies to the GMF runtime, to some Mylyn projects including MFT, and to some parts of the Taipan project, of course. Listing 1 shows the relevant section of the project’s manifest.

Listing 1


Require-Bundle: org.eclipse.ui,



To provide focusing support for the Taipan editor, Mylyn MFT needs to understand the structure of its data model. To do that, we just need to create our own simple TaipanContextStructureBridge using MFT’s GmfStructureBridge as super class and register it with the org.eclipse.mylyn.context.core.bridges extension point. The bridge tells MFT everything it needs to know about our Taipan model:

  • Classes representing nodes

  • Classes representing edges

  • The common base class of all nodes

  • The common base class of all edges

  • The bridge’s content type (a unique name identifying the domain supported by the bridge, for example the plug-in’s id)

In order to provide this information, it’s necessary to take a quick look at the data model. The Taipan model can be found in models/Taipan.ecore in the main project org.eclipse.gmf.examples.taipan. Figure 4 shows a class diagram of the model.

Figure 4: Data model of the Taipan example project.

Obviously Ship and Port show up as nodes in the Taipan editor, while Order and Route represent edges. As there are no common super classes for nodes or edges, we’ll have to leave those at EObject.class. That’s okay because this is only used for performance reasons. Listing 2 shows the resulting implementation:

Listing 2


public class TaiPanContextStructureBridge extends 
GmfStructureBridge {
   public String getContentType() {
      return TaiPanActivator.PLUGIN_ID;
   public Class<?> getDomainBaseNodeClass() {
      // better: common super type != EObject.class
      return EObject.class;
   public Class<?>[] getDomainNodeClasses() {
      // better: use constant
      return new Class[] { Ship.class, Port.class }; 
   public Class<?> getDomainBaseEdgeClass() {
      return Eobject.class; // only for convenience
   public Class<?>[] getDomainEdgeClasses() {
      // better: use constant
      return new Class[] { Route.class, Order.class };


Now that MFT understands the Taipan structure, the next extension point to implement is org.eclipse.mylyn.context.ui.bridges by subclassing MFT’s DiagramUiBridge. Its purpose is to define which UI views and editors should be supported. The implementation will be responsible for the previously defined content type (the same id as used in the content bridge) and should handle all Taipan implementations of IWorkbenchPart, which is just the TaiPanDiagramEditor. More fine-grained control is available to decide which combination of model and view instances are related to each other, which is simple in the Taipan example, since each model object has exactly one view representation. Listing 3 shows the relevant parts of the implementation class.

Listing 3 – Implementation of the org.eclipse.mylyn.context.ui.bridges extension point.

public class TaiPanContextUiBridge extends DiagramUiBridge {
   /* skipped singleton implementation here for convenience */
   public String getContentType() {
      return TaiPanActivator.PLUGIN_ID;
   public boolean acceptsPart(IWorkbenchPart part) {
      // support TaiPanDiagram editors
      return part instanceof TaiPanDiagramEditor;
   public boolean acceptsViewObject(Object modelObject, Object viewObject)
      // support all combinations of model and view objects
      return true;

Note that it’s currently required to implement the class as a singleton to access the shared instance in the plug-in’s activator and from a decorator provider – this boilerplate code is skipped here for convenience. The full source code of this example is downloadable from here.

Last thing that we need to do is connect Mylyn’s selection monitor to the freshly created bridges. This is easily done in the plug-in activator by calling

That’s it – Figure 4 shows a task-focused Taipan editor. Though it’s obviously only a play example, it shows how easy GMF-based editors can be enhanced with MFT’s capabilities.

Fig. 5: Task-focused Taipan editor: The fog of war.


The Eclipse Model-Focusing-Tools project brings Mylyn’s task-focused interface to modeling tools both old and new. Where modeling serves the understanding of concepts and leverages complexity through abstraction, Mylyn keeps the developer task-focused by filtering unnecessary information. MFT combines both advantages for even more productivity.

This new open source project depends on community feedback to grow and mature. So please test MFT and provide feedback, check out the example application and mylynize your own diagram editors!

Author Bio: 

Manuel Bork is IT-Consultant and Technology Evangelist with Yatta Solutions. He is kept busy with Round-Trip-Engineering and being a core developer of UML Lab, an Eclipse based Plug-In and RCP application for agile UML modeling. He is Eclipse committer and a regular speaker and author on Eclipse-related topics. In his spare time Manuel is a passionate mountain biker. Email: [email protected], Twitter: @manuelbork. Web:

This article appeared in JAX Magazine: Eclipse Juno. Check out that issue and others here.

Manuel Bork is IT-Consultant and Technology Evangelist with Yatta Solutions. He keeps busy with Round-Trip-Engineering and being a core developer of UML Lab, an Eclipse-based Plug-in and RCP application for agile UML modeling. He is Eclipse committer and a regular speaker and author on Eclipse-related topics. In his spare time Manuel is a passionate mountain biker. Email: [email protected], Twitter: @manuelbork. Web: http://www.

Inline Feedbacks
View all comments