During the search for a replacement of our outdated OpenOME editor to obtain a new editor for iStar 2.0, we became aware of certain tools from the Eclipse Modeling Project. These tools provide the possibility to build modern graphical editors in a convenient way with little programming overhead. They also meet our requirements for an editor which should be exible in changing the metamodel of iStar and easy to extend. In this paper, we report on our quest to nd an Eclipse modelling framework which makes it easy to create and adapt an up-to-date iStar 2.0 editor.
For many years we have used an old version of the Eclipse-based OpenOME
[
First of all, we looked for the newest OpenOME version. The SourceForge
page [
Starting from scratch with a new editor for the iStar 2.0 dialect we need [
As stated above, we want to use MDSD for the easy creation of an editor for iStar 2.0 diagrams. To this end, we created a formal model of a fragment of iStar 2.0 which is interesting for us. Then in a further step, we investigated three di erent frameworks for creating graphical editors using this model. Here we only consider Eclipse-based tools, because for us it is important that we can connect the editor to other software which is quite easy to achieve within Eclipse.
All the frameworks we examined utilize an Ecore metamodel, which comes
from the Eclipse Modeling Framework (EMF) [
In the following we present the three frameworks we looked at: the Graphical
Modeling Framework, Graphiti and Sirius. All three frameworks are based on
EMF and the Graphical Editing Framework (GEF) [
As the rst of the three frameworks we considered GMF [
GMF works well for small Ecore models that result in simple editors so that little customization of the EMF-based models is required. For larger domains, like ours, for which we need to add constraints, such as tasks appearing only inside agents, the Graphical and Tooling De nition Model, in addition to the Mapping Model which links these two models, quickly become large and hard to maintain. In addition, changing one model usually requires changes to others, which makes GMF in exible, especially when changing the metamodel. Since exibility is a requirement of ours, this makes GMF not a good t for our purpose. An advantage of GMF is, that advanced feature customization outside of the framework's options can simply be added to the Java code GMF creates. 2.2
In contrast to GMF, Graphiti [
Because Graphiti does not provide automatic code generation, it loses an advantage of MDSD. Standard code, for example the feature delete, has to be rewritten for every Diagram Type Agent. In addition, Graphiti requires more knowledge of Java and plug-in development with Eclipse compared to GMF. But it is more exible than GMF, since it is not based on a complex network of models. Changes to the metamodel only require changes to our code, and Graphiti allows incremental development of an editor. It is also very customizable, since we can add additional functionality to our code. Developers might prefer Graphiti over GMF, because it is more similar to conventional coding. 2.3
The third framework we considered is Sirius [
Because Sirius does not require any code for an editor and allows changing the editor while using it, it is the most exible out of the three frameworks. Therefore Sirius allows changes to the Ecore model more easily than GMF and Graphiti. The VSM has an intuitive structure, so it does not require much practice to work with. A risk of the lack of code generation might be that we have to rely on Sirius for many customization options. But so far the limitations seem to be only of a visual nature, as we discuss in the next section. For the reasons listed above, we decided on the Sirius framework for an implementation of our editor. 3
As stated in the last section, creating an editor with Sirius requires little familiarization with the framework. We simply linked our Ecore model to a new Sirius project and accessed all its elements through a Domain-speci c language (DSL). After that we de ned the node and link types needed in our editor. For example, we speci ed a task as a node-type by setting its Domain Class to istarmodel.Task. This description refers to the class Task in our Ecore model called istarmodel from Figure 1. Then we set a relation between Task and the IstarDiagram class through the expression feature:elements, which refers to the reference elements in Figure 1 that Task inherits from the class IntentionalElement. Links between nodes are de ned similarly, by referring to the Ecore model and the node types to which they belong; for example the link neededBy has to reference the Task and Resource node types. Next, we speci ed creation tools that allow users the construction of diagrams with the editor. For example, the Task Creation Tool assigns the new task a name and links it to an actor. Figure 2 shows the editor that we created with Sirius. In the center the editor displays the current diagram, while all diagrams and their elements are listed on the left. Creation tools for all elements are listed on the right side and the bottom shows properties of the currently selected element, such as references to other elements.
As shown above, providing basic functionality for an editor is very simple
with Sirius. Adding more complex features, such as the capability for roles to
contain elements or adding validation of the diagram, does not require much work
either, thanks to the DSL and the query language AQL. Eclipse extension points
and the ability to call custom Java functions allow even more customizations.
The only limitations we found are of a visual nature, for example adding custom
edge decorators outside of the ones supplied by Sirius would require code changes
in the Sirius core [
In this paper, we investigated three Eclipse-based frameworks that generally follow the concept of Model-Driven Software Development. For our purposes we hoped to nd a framework which makes creating an editor for an iStar 2.0 fragment easy and exible. We think that we have found a suitable framework with the Sirius framework. The only drawback so far is that the AND-re nement can not have the right T-shaped arrowhead in its representation in the editor. To make this possible one has to change the core of the frame work. But this would not be a good option if we want a maintainable solution.
At the moment we only have a basic stand-alone editor. In future work, we need to connect our Sirius-based editor with other tools needed for multi-agent simulation.