Focusing on models

Eclipse Juno: The Eclipse Model Focusing Tools Project

ManuelBork
egg-eclipse

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.

Modeling

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,
 org.eclipse.ui.ide,
 org.eclipse.core.runtime,
 org.eclipse.mylyn.context.core,
 org.eclipse.mylyn.context.ui,
 org.eclipse.mylyn.monitor.ui,
 org.eclipse.mylyn.mft.gmf.ui,
 org.eclipse.mylyn.mft.emf.core,
 org.eclipse.mylyn.mft.emf.ui,
 org.eclipse.gmf.runtime.diagram.ui,
 org.eclipse.gmf.runtime.diagram.ui.resources.editor.ide,
 org.eclipse.gmf.examples.taipan,
 org.eclipse.gmf.examples.taipan.gmf.editor

 

 

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.

Conclusion

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:
bork@yatta.de, Twitter:
@manuelbork. Web:
http://www.yatta.de

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

Author
ManuelBork
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: bork@yatta.de, Twitter: @manuelbork. Web: http://www. yatta.de.
Comments
comments powered by Disqus