From DPFWiki

Jump to: navigation, search



Things related to the MUMS project goes here.


This project is the result of 100+ hours between May and September 2012 and focuses on creating a visualization for a DPF model using the Graphiti framework.


Graphiti is an abstraction layer on top of GEF/draw2d. It is an incubation component at the present time, but is part of the Graphical Modeling Project (GMP).

  • Graphiti is "platform-independent". It is designed to have different backends, but only GEF/draw2d has an implementation.
  • The objects which we want to draw in a diagram is defined through "Features", read tutorial to see an overview
  • A FeatureProvider controls which features that is assigned to a particular business object
  • Functionality related to the editor is defined through a ToolProvider
  • The framework is based on subclassing default implementations -> this (can) result in a lot of classes and similar code


The goal of this project was to do something which benefits the DPF project, but also is within the MUMS projects bounds. OSC in Ă…lesund creates simulators aimed at the shipping/oil industry. These simulators uses pre-built scenarios which an instructor defines using a tool which is created in-house at OSC. These scenarios contain different entities like a platform, offshore-crane, a ship which has a certain hull, engine, propulsor etc.

This pre-project tries to create a visualization for a DPF language using the Graphiti framework.






The models are without constraints, and lacks a lot of attributes.

Changing the DSML will require changes to the helper classes which queries the hierarchy



  • Check out code from MUMS git repo, or DPF svn (playground).
  • Install DPF (at least core and CG tool) on top of a Eclipse Modeling Tools bundle.
  • Install Graphiti (0.9 used for this project)
  • Import projects and run


The tool consists of two different editor environments. The whole project consists of four plugins:

  • no.hib.mums.partmaker
The PartMaker(PH) defines separate components in a scenario. This means that we do not define the relationship between the components, but rather define them separately and define its attributes' values.
  • no.hib.mums.shipmaker
The ShipMaker(SH) defines the relationship between the components defined in PH which in its turn will results in a ship.
  • no.hib.mums.shipmaker.generator
The code generator. Templates not yet written.
  • no.hib.mums.shared
Resources which are shared between PG and SH.

(Visual) Features

  • Creating the different parts
  • Directly defining its attributes
  • Loading a SH diagram based on xmi made by PH
  • Defining Relationship arrows between components
  • Simple properties view (only showing node name and id right now)
  • Generate Code from Model menu contribution on xmi files
    • The output folder is hardcoded as src-gen -> see GenerateCodeHandler
  • Arrows in SH maintains integrity based on functionality in the core model
  • Implemented dropdown menu on the Part nodes. Not in use as the attributes are listed in the node body.
  • Wizards for creating new PH/SH editor
  • The SH editor also has a dialog for loading a PH model

(Non-visual) Features

  • Implemented as two editors, each registering with the Eclipse workspace
  • Custom resource loading which used TransactionalEditingDomain (which is required by Graphiti)
  • In PH, there is default implementations for each Part node, which is subclassed to define unique properties for each node type (Hull, Propulsor, etc.)
    • Not implemented in SH -> it is a simple task to fix
  • Each SH model has a key/value pair which specifies the path to the PH model in addition to its project name
  • Code generator is invoked from context menu selection in the following views: Package Explorer, Project Explorer and Resource Navigator


  • Editors are marked dirty upon loading
  • Saving a SH editor and then a PH editor, will result in a deadlock. It is OK to save the same editor more than once. This is trouble relating to EMF and possibly TransactionalEditingDomain.
    • Both PH and SH utilize the same xmi file. Each editor has a separate TransactionalEditingDomain. It is possible that one domain does not release the resource and thus resulting in a deadlock. Using different TEDs on one resource should however be possible (I think).
  • UpdateFeature not properly implemented. This feature helps Graphiti to know when the underlying model has been changed and thus marking the pictogram-elements as dirty.
  • Code generator template/extension not implemented.
  • DeleteFeature not implemented. The default implementation deletes the EObject from the model, but this is disabled for testing purposes. Remove the overrides in the deletefeature class.
  • Properties view not fully implemented. Since each Part node has different attributes, we need to redraw the widgets for each pictogram-element. Possibly relevant interfaces are ISection, ISectionDescriptor and ISectionDescriptorProvider (perhaps also IFilter).
    • The solution to this is to have a class where we can identify which pictogramelement which is selected and then create an ISectionDescriptor which is linked to an ISection (see

Further work

It is my opinion that Graphiti is worth investigating, both as a long-term replacement for GEF/Draw2d in dpf.editor as well as the foundation for a visualization editor. The framework itself is relatively easy to master. It shouldnt take more than a few hours to get the fundamental concepts. The main piece of work in my opinion is the glue between the dpf.core and the editor specified in Graphiti. This might be due to my lack of understanding of resources in EMF, but it seems like a lot of the work lies here. A solution to this is to create a thin API which wraps dpf.core in a "transactional" manner, with the same convenience methods which dpf.core provides.

Another challenge I encountered was traversing the model hierarchy; it could be an interesting task to create a sane api where the whole hierarchy could be queried without chaining 6+ methodcalls. Perhaps an internal DSL could be suitable.

When creating two different editors I realized that there is a lot of code duplication going on. If the DPF project decide to create a visualization editor (that is an editor for creating visualizations based on a DPF DSML), it should be doable to either create a generic API in which the editors can be specified, or generate code that specify the editor.


  • Graphiti should be investigated further
  • It is a good target for code generation
  • The work might lie in creating good APIs for talking to dpf.core (not only for transactions, but perhaps something for traversing a model's hierarchy)
Personal tools