Focusing on models
Eclipse Juno: The Eclipse Model Focusing Tools Project
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 .
- Introduction to Eclipse Model Focusing Tools
- Cross-domain task focusing