Focusing on models

Eclipse Juno: The Eclipse Model Focusing Tools Project - Part 2

 

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.

Pages

Manuel Bork
Manuel Bork

What do you think?

JAX Magazine - 2014 - 06 Exclucively for iPad users JAX Magazine on Android

Comments

Latest opinions