An Architecture for an Open Visual Editor for Software and System Design

Transcription

1 Torbjörn Lundkvist Ivan Porres An Architecture for an Open Visual Editor for Software and System Design TUCS Technical Report No 877, March 2008

2

3 An Architecture for an Open Visual Editor for Software and System Design Torbjörn Lundkvist Ivan Porres TUCS Turku Centre for Computer Science, Department of Information Technologies, Åbo Akademi University, Joukahaisenkatu 3 5 A, FIN Turku, Finland torbjorn.lundkvist@abo.fi, ivan.porres@abo.fi TUCS Technical Report No 877, March 2008

4 Abstract In this paper we present an architecture to develop editors for user-defined visual languages that supports OMG modeling standards. We will present a visual language editor architecture based on generic, configurable components integrated with a model repository. This architecture has a strong separation of abstract and concrete syntax and uses change propagation mechanisms to propagate changes in models to diagrams and views. We will also show how this approach has been realized in the Coral Modeling Framework. TUCS Laboratory Software Construction Laboratory

5 1 Introduction Visualization of software systems using diagrams can bring important benefits to software development. Software modeling is for this reason often based on visual notations, as it increases the understanding of the software system. However, software visualizations should still be based on rigorously defined formal languages since they need to be analyzed and maintained by computers [12]. Software modeling tools can therefore assist the developer in experimenting with different designs, while a computer program can analyze the designs to detect potential errors, or performing automated tasks on the software models such as generating new models or executable code. The Unified Modeling Language (UML) [20] has become the de facto language for software modeling in the software industry. UML is a general-purpose modeling language that can be used for describing a wide variety of application domains. However, for some application domains UML may be too general for effectively designing software systems. To still be able to use UML tools for these domains, specialized UML profiles have been introduced. Examples of these are the UML-RT, and UML-SoC for System-on-Chip design. These profiles extend UML with concepts needed for a particular application domain. Another approach is to create completely new modeling languages that includes only the concepts relevant for designing software for one specific domain. In these languages the modeling concepts are typically very close to the software domain. Many domainspecific modeling languages (DSML) have been developed, an effort to collect and list such languages can be found at the Atlantic Domain Model Zoo [1]. Using a UML profile or a DSML, however, requires tools that are designed for the language. To address the need to model software systems using UML profiles and DSMLs, special metamodeling tools have been created. These tools support the definition of new visual languages and have special development tools to support the development of visual editors for these languages. Several tools are available, for example MetaCase MetaEdit+ [14], the Generic Modeling Environment (GME) [17] and most notably the Eclipse Graphical Modeling Framework (GMF) [3], which is aiming at reducing the effort of developing DSML editors using Eclipse Graphical Editing Framework (GEF) [2] and the Eclipse Modeling Framework (EMF) [10] by introducing a well-defined editor construction process. In this paper we study the problem of constructing tools that can be used to edit visual languages using several different editing methods, based on the Object Management Group (OMG) standards. We will present a visual language editor architecture based on generic, configurable components integrated with a model repository. This architecture has a strong separation of abstract and concrete syntax (models and diagrams) and uses change propagation mechanisms to propagate changes in models to diagrams and views. We proceed as follows: In Section 2 we present some important tool requirements and design principles. We continue in Section 3 by presenting how models 1

6 are represented in a model repository. In Section 4 we propose an architecture for visual language editors. In Section 5 we will present how this architecture is realized in the Coral Modeling Framework. We finally conclude in Section 6. 2 Tool Requirements and Design Principles In this section we will outline and discuss the most important requirements we think should be considered in an open tool supporting a multitude of generalpurpose and domain-specific languages visual languages. We will then present some few key design principles that we consider that when applied systematically lead to a tool implementation that fulfill all the stated requirements. The main requirements are as follow: Multiple, user-uefined visual languages. Obviously, the first requirement is to support the creation and manipulation of models in different user-defined as well as general-purpose languages such as UML. Multiple interactive editors. The tool architecture should also allow several different methods of editing a model. Most software modeling languages are depicted using a visual diagrammatic notation. However, A model could also be represented using textual concrete syntax, where models are visualized as text and a user can edit models by using special text editors. An example of such frameworks are Textual Concrete Syntax (TCS) [13]. A developer may also want to edit the models using a form-based property editor, interactive shells and wizards or invoke model transformation programs. Support for automation. Besides interactive editors, the tool should support automatic model transformations that implement complex development steps. Modeling standards. The Object Management Group (OMG) maintains a series of modeling standards including UML and the Meta Object Facility (MOF)) [23]. The MOF is a standard used by OMG to define the abstract syntax of modeling languages. Other widely used languages are the Eclipse Modeling Framework (EMF) [10, 8] and the Graph exchange Language Metaschema (GXL) [26]. The concrete syntax of a language can be defined using the OMG DI standard [22], while models can be serialized into XML and exchange between tools using the OMG XMI standard [21]. We consider that modeling tools should try to adhere to these standards to ensure interoperability. Reduce effort to support new languages, editors and transformations. The development of complete tool support for new visual languages based on the requirements proposed in the previous section may involve the customization and integration of many different components and artifacts. Still, we consider important to reduce the effort necessary to complete this task, otherwise the costs of development of a new visual language may offset its benefits. Tool independence. Ideally, the artifacts needed to support a new modeling language in an editor should be independent of the actual implementation of the 2

7 editor. A truly tool independent approach to define editors for new modeling languages would allow us to share the definitions between tools. 2.1 Key Design Principles We consider that these requirements can be tackled successfully by implementing the following design principles: Use a metamodeling approach. We should be able to define the editors for a new modeling languages using high-level declarative languages, instead than by creating new components using the particular programmatic interface (API) of a given tool. Even if metamodeling is a common approach to define the (abstract syntax) of a modeling language, current metamodeling languages cannot be used to completely define the behavior of a tool editor supporting the requirements defined above. In the context of the OMG standards, the abstract syntax and the concrete syntax are two independently defined and maintained artifacts. The abstract syntax is defined by a metamodel and contains a description about the relationships between modeling elements in a form that can be processed by tools, such as model transformation components and code generators. The concrete syntax, on the other hand, contains information about how modeling elements are visually represented, e.g. shapes and layout information used in diagrams. The concrete syntax could be seen as a view or representation of the abstract syntax, meant for human users. Some information necessary to construct the diagrammatic representation of a model from it abstract syntax such as layout of diagrams is missing from the OMG standards. Therefore, we should extend and annotate a metamodel with additional information to describe the visual appearance of the models. Represent models as described in the metamodel internally and externally. The tool should represent a model using a data structure that conforms to the metamodel of its language both externally (when storing models to files) but also internally (as its working data structure while editing models). Representing tools externally according to a metamodel is necessary to ensure interoperability between tools from different parties. Representing models internally as described in the metamodel is necessary to ensure interoperability between tool components. We have now presented the most important requirements of a visual language tool architecture for supports many languages. In the next section we will discuss a general approach to construct editors and present an approach we think can realize the outlined requirements. 3 Representing Models Perhaps the most important component in a modeling tool is the model repository. A model repository creates and maintains models conforming to a modeling language. Model repositories provide the basic functionality to create models, add, 3

8 delete and update elements in existing models and to store and retrieve models from a file. Hence, all modifications made to a model are made via the model repository. Examples of model repositories are the Eclipse EMF project [10] and the Netbeans Metadata Repository [19]. Coral repository is based on a metamodeling approach inspired by MOF2 and its core metamodeling language is described in [4]. It can also import Eclipse Ecore metamodels. The Coral repository provides an uniform graph-based representation of all models and diagrams. That is, both the abstract and concrete syntax of all models in all modeling languages supported by the repository are represented as directed attributed hierarchical graphs. Therefore, the repository can be seen as an efficient graph-rewriting engine. The repository is based on a transaction mechanism. A new transaction should be started before a model is updated and closed to commit the updates. Transactions can be rolled back and committed again, providing the undo & redo feature found in most interactive editors. A tool component can register itself to the model repository as a reactive component. Every time that a transaction is committed (or rolled back), the model repository notifies the event to all registered reactive components. The notification event includes a list of updates performed (or rolled back) in the transaction. This include each individual change (creation, deletion, update) in the arcs and nodes of the graphs composing the models and diagrams. This change list can be seen as the difference from the current version of the repository and the previous and depending on the transaction it can include from one to tens of thousands of individual changes. Each reactive component has the responsibility of performing a designated task, such as layouting a diagram or updating a view. It is the responsibility of the reactive component to use the change list properly to perform its task incrementally, that is to only recreate parts of models and diagrams when that is required by the changes introduced in the last transaction. The change propagation mechanism is discussed in more detail in [6]. In the context of this article is the mechanism that allows loosely couple tool components to work together efficiently. There are three types of communication operations between models in the model repository and components. These are shown in Figure 1. The first type is an update, depicted as an arrow from a component to a model, occurs when a component wants to update a model. The second type is a read-only operation, depicted as an arrow from a model to a component. The third type is a notification, depicted as a double-stroked arrow. The notification is generated by the model repository and transmitted to the change propagation components, when changes occur in a model. This operation is combined with a read operation, as the component will always read which changes occurred in the models. The model repository allows us to represent models in many different modeling languages. However, it does not provide facilities to edit these models interactively. This is the responsibility of the editor components, that are described in 4

9 Component Model Update Component Model Read Only Component Model Notification Figure 1: Possible communication flows between components using the model repository. more detail in the next section. 4 Editing Models Probably the most known design approach to interactive tools is the model-viewcontroller pattern (MVC) [16]. We will use it to describe the architecture of a simple UML editor and then we will evolve the example to our final architecture. In our example the model role in the MVC pattern is played by a component model repository. The controller role is played by the interactive diagram editor. The interactive diagram modifies models and diagrams slightly each time a user performs an editing action, such as creating a new UML Association between two UML Classes. Here, we assume that the document, consisting of a model and a diagram, are separated as two different artifacts. In this case, the interactive diagram editor maintains the consistency between models and diagrams. Finally, the view role is played by the diagram view component. The diagram view reads the diagram and renders it according to the notation of the modeling language. The diagram view is a read-only component, hence it will not modify any diagrams. We can construct a diagram editor tool specifically for UML according to the setting in Figure 2. In this setting we can consider that there are three major components needed, a model repository, an interactive editor and a diagram view. In the figure, the arrows denote a read or update operation with respect to the direction of the arrow. Based on these three components, it is possible to construct a modeling tool based on the model-view-controller design pattern. In this example, the interactive editor modifies the abstract and concrete syntax via the repository simultaneously, and the diagram view redraws the diagram when it changes. Coordination between these components is usually implemented using the subject-observer pat- 5

10 Interactive UML Editor UML Diagram View UML Model Repository 2 UML Model UML Class Diagram Figure 2: Example architecture for an UML editor implemented using a MVC pattern. tern. The drawback of this approach is that there is a need to create new editors and view for each new modeling language. This task can require a substantial effort and it is accomplished by programming new components using the API of the tool editor. Also, if the tool is later extended with another type of editor component such a form-based editor, this new editor will need to create and maintain the diagrams. For example, if a form-based editor adds or deletes a class from a model, it should also add or delete it from the corresponding diagrams. This requires again a considerable effort and a certain duplication of responsibilities in the components. 4.1 Decoupling Editors from Diagrams We propose to represent the abstract syntax of a model and its concrete syntax (e.g. diagrams) as two different graphs managed by the model repository. Changes in the abstract syntax of a model should be propagated to its concrete syntax and vice versa. However, this task can be performed by an independent diagram reconciliation component. This diagram reconciliation component can be implemented as a reactive component. This is way is possible to decouple the updating of views and generation of derived artifacts from the editor component that introduced the changes. We modify our running example slightly and introduce a new diagram reconciliation component in Figure 3. The diagram reconciliation component here is a reactive component that will update a diagram associated to a model when changes occur in the model. This component has built-in information about UML diagrams to create and reconcile diagrams based on the UML syntax. The change propagation flow is as follows: First, the user inserts a new element in a UML 6

11 model using an interactive diagram editor (1). When the model changes, the model repository notifies the change propagation components that react to changes in UML Models, in this case the UML diagram reconciliation component (2.1). This component reads the changes made in the UML Model and updates the UML Class Diagram, which is derived from the UML Model (2.2). Finally, the diagram view component is notified that the UML Class Diagram has changed, after which the relevant parts of the diagram view are updated and rendered using the UML notation (3). From the figure we can see that in order to update a diagram, only the abstract model requires active modification. One clear benefit of automating the update of diagrams using change propagation components is that we only need to handle the abstract syntax in the interactive editor component, and consequently reducing its complexity. Interactive UML Editor UML Diagram Reconciler UML Diagram View Model Repository UML Model UML Class Diagram Figure 3: Example architecture for a UML specific editor. 4.2 Using Generic Diagram Editor Components In the previous example we could see that by using change propagation components we could distribute the responsibilities of updating derived artifacts and views in a UML tool. However, here we assumed that all knowledge about how UML models and diagrams was built into the editor component and change propagation components. If we would like to support another modeling language in the tool setting in the example, we would still need to construct similar components for that particular language. However, to construct new tool components for new languages by extending or duplicating components is time consuming and the result will not be tool independent. Instead, we propose that the language-specific parts of each component is separated from the core functionality of the component. That is, instead of using a UML specific component, we use a generic language-independent component that 7

12 will still perform the same tasks in the tool, but instead reads all language specific information needed to perform the tasks from an external configuration file. In this case we consider that these configuration files are also stored as models and managed by the model repository. These configuration models conform to one or more modeling language suitable for describing the structures the components use. Interactive Editor VL Diagram Reconciler Diagram View Model Repository UML Editor Definition UML Model UML Diagram Mapping UML Class Diagram UMLVisual Notation Definition Figure 4: Using Generic Diagram Editor Components. Based on the three UML-specific components in the previous example, we will now replace the language-specific components with generic components configured using a separate model managed by the model repository. The updated architecture is shown in Figure 4. In this case, we can think that the editing process starts with a user selecting an action that will insert a new Class into an existing model and diagram. The definition of this action is stored in the UML editor definition and read by the interactive editor (1.1), after which the editor executes the action and inserts the new class in the UML model (1.2). When the editor modifies the UML model, the model repository notifies the diagram reconciliation component that a model has changed and reads which elements changed (2.1). The diagram reconciliation component will then find how to construct the diagrammatic representation of a class from a set of UML diagram mappings which specify the relation between models and diagrams (2.2). The diagram reconciliation component will then be able to make the corresponding changes in the diagram (2.3). Since the UML class diagram was stored as a separate model alongside the UML model, the model repository will notify the diagram view component that the diagram has changed (3.1). The diagram viewer will then read from the UML visual notation definition how to draw the diagram (3.2). The most important benefit from moving the language-specific parts from a tool component to a separate configuration file, is that generic tool components 8

13 do not need to be modified in order to construct a diagram editor for another language than UML. To support other modeling languages, only the configuration files need to be modified. The generic components may, however, require more effort to design and implement than language-specific components. This is mainly because there is a need to find techniques to define and configure the components that are suitable for use with many languages. On the other hand, the effort of adding support for new languages is reduced. 4.3 Many Models and Many Editors We could consider a diagram editor as just one of many possible ways to edit a model. As discussed in Section 2, we will also need to edit models using formbased editor approaches, model transformation programs and interactive shells. While these components mostly operate on the abstract models alone, it is important that these do not invalidate existing diagrams when they are used to perform changes to the models. With the introduction of the diagram reconciliation component, the diagram editor component could be constructed to only modify the abstract models. Similarly, we could think that a model transformation component modifies the models and the diagram reconciliation component reacts to the changes and updates the diagrams accordingly. This way we could reuse the diagram reconciliation component with other editor components in the tool. Model Transformation Component Diagram Reconciler Diagram View Model Repository MT Definition UML Model UML Diagram Mapping UML Class Diagram UML Visual Notation Definition Figure 5: Using model transformations. In Figure 5 an example of a configuration is shown, where the interactive diagram editor has been replaced by a model transformation component. Similar to the other components in the system, we assume that the model transformation component is configured by a set of model transformation definitions written in a model transformation language. These definitions are read (1.1) by the model 9

14 transformation component before it executes the transformation and changes the model (1.2). As we can see from the figure, only minor modifications were required in the architecture. We can generalize the concept of a model transformation component to include many different kinds of interactive model editors. An interactive editor usually performs small changes to the model initiated by a user, where a model transformation engine can perform automated tasks based on a set of rules, without user interaction. From the perspective of the model repository, both components transform a model into a slightly different model, hence the notification and the change propagation mechanism will propagate the changes further in the tool to possible views in both cases. Consequently, new model editors can be designed to operate on the abstract syntax alone while still supporting diagrams. 5 Diagram Editor in the Coral Tool In the previous section we have seen an editor architecture for visual languages evolve from using the standard Model-View-Controller pattern supporting a single language, to an architecture based on change propagation with components that can be customized for many languages using configuration files. In this section we present a concrete realization of these diagram components in the Coral tool. 5.1 Diagram Editor The diagram editor component allows the user to create and modify models depicted in a visual language. It combines features from structured syntax-directed editing and free-form editing into what we call relaxed syntax-directed editing. Syntax-directed editing allows the editing of models and diagrams based on a grammar. It ensures that models constructed using this approach are always syntactically correct. However, this approach may be frustrating to the end user since it often imposes a certain ordering on the editing actions. On the other hand, freeform editing allows a user to construct a model in arbitrary order, but it may lead to models that are not syntactically correct. The editor implements a syntax-directed editing approach to add new elements to a model. The editor uses a graph grammar that describes all possible rules to add new elements to a model. Rules are defined using the double pushout approach [24]. The double pushout approach defines each transformation by declaring a left-hand side (LHS) and a right-hand side (RHS) as two separate graphs. In addition to these two artifacts, a mapping between the LHS and RHS, is explicit. Coral implements a graph rewriting engine that supports negative application condition and a star operator [18]. The star operator, which resembles the Kleene star operator used in textual grammars, allows us to describe recursion describing e.g. hierarchies using declarative graph transformation definitions. 10

15 SM:StateMachine LHS CS0:CompositeState container top statemachine RHS CS0:CompositeState container subvertex top SM:StateMachine statemachine statemachine subvertex CS1:CompositeState CS1:CompositeState container container container container subvertex subvertex subvertex subvertex CS2:CompositeState CS3:CompositeState CS2:CompositeState CS3:CompositeState container container container subvertex S1:StateVertex container subvertex S2:StateVertex subvertex subvertex source target S1:StateVertex T1:Transition S2:StateVertex outgoing incoming transitions Figure 6: A transformation rule to insert a new Transition between two UML states. A diagram editor action is a rule that, for example, describes how to insert a state in a statechart or a new association in class diagram. A diagram editor action is executed as an in-place transformation on the abstract model. The changes in the abstract model are then propagated to the diagram using the diagram reconciliation component. As an example, a rule to insert a Transition between two UML states is shown in Fig. 6. Here, the dashed rectangles denote a star region. The star regions used in this example are needed since the two states can be nested into an arbitrary number of composite states. In order to create new editing actions for the UML or other notations we only need to create new rules. Free-form editing is used to complement the syntax-directed in the diagram editor when editing an existing diagram. That is when the user deletes elements from a model or moves elements from one container to another such as moving a Class into a Package in a UML class diagram. In this case, the editor uses the information represented in the metamodel to decide what editing actions are possible. 5.2 Diagram Reconciliation Component Diagram support in the Coral Modeling Framework is based on the idea that the concrete syntax can be defined based on the abstract syntax with a special mapping language. This language, called the Diagram Interchange Mapping Language (DIML), defines the relation between a modeling language and DI diagrams. DIML itself is a modeling language that can be described using a standard metamodeling language such as MOF or the UML 2.0 Infrastructure. A DIML model maps an element in a modeling language to a parametrized skeleton of DI elements. This DIML model is then evaluated in the context of an abstract model to determine when a mapping can be applied to create the corresponding concrete syntax as a DI diagram. An example of a DIML model describing the concrete syntax of a UML Sim- 11

16 UML14::SimpleState acceptsconnector := true GraphNodePart GraphNodePart typeinfo : = NameCompartment GraphNodePart typeinfo : = CompartmentSeparator GraphNodePart typeinfo : = InternalTransitionCompartment [ self.stereotype->notempty() ] self.entry->asset() self.exit->asset() GraphNodePart GraphNodePart Delegation Delegation typeinfo : = StereotypeCompartment typeinfo : = Name self.doactivity->asset() Delegation Figure 7: A DIML model describing the mapping of UML SimpleStates to DI. plestate can be seen in Figure 7. The parametrization allows an abstract model element to have slightly different representations based on the structure of the abstract model. In addition, there can be several DIML models associated with one metaclass in a modeling language. For example, a UML Class can be represented as a rectangle with compartments for Attributes and Operations, or as the type of an Attribute. For more details about how DIML is defined and its semantics, we refer the reader to [5]. DIML models as such are declarative constructs that only describes how a diagram should be constructed. DIML does not define or enforce any specific method to apply the mappings on model data to create DI diagrams. One of the most important applications of the DIML language is a diagram reconciliation component. The diagram reconciliation component acts as a change propagation component, propagating changes in the abstract model to diagrams. This approach has the important benefit that it is possible to decouple the creation and reconciliation of diagrams from transformations on abstract models. That is, new editing components can be constructed to deal with the abstract syntax alone. 5.3 Diagram View It must be noted that the output of the diagram reconciliation component is a diagram according to the DI standard that can be used to exchange diagrams between different modeling tools that supports the standard. In order to display the diagram correctly, the nodes and edges of the diagram needs to be layouted based on a set of layouter constraints and rendered to an output device based on the definitions for the visual notation of the diagram elements. The definition of visual notation of diagram elements is based on parametrized SVG [25]. The parametrized SVG in Coral is implemented as an extension to 12

17 DIML, where each DIML element is annotated with a set of SVG primitives, such as rectangles, ellipses, polylines and text, which determine the exact notation used to draw diagrams. Each of the primitives can retrieve information from the abstract model or the DI model. The parametrization is, similar to the DIML mappings, defined declaratively. A group of SVG primitives are grouped as a symbol. Each diagram element can be associated with many symbols, of which one is selected based on the context of the diagram element or the underlying abstract model. The final notation is achieved by applying these definitions in the context of the model and the DI diagram. This mechanism is fully integrated with the diagram viewers and is used to draw diagrams both on screen and to files. 5.4 Related Work Several authors have studied how to construct generic visual language editors based on graph grammars. For example, Chok and Marriot present the intelligent diagram metaphor in the Penguins system in [9]. Other examples are GenGed [7], Tiger [11] and DiaGen [15]. There exists full-featured metamodel-based editors that allow the user to create and edit models in user-defined languages. Examples of these approaches are MetaEdit+ [14], Pounamu [27], the Generic Modeling Environment (GME) [17] and the Eclipse Graphical Modeling Framework (GMF) [3]. While all these approaches offer sophisticated methods to define visual language editors, many of the tools do not address all of the important requirements we stated in Section 2. To the best of our knowledge the previous approaches do not have a strong decoupling of the abstract and concrete syntax, to allow efficient management of derived artifacts such as diagrams and views, and do not define visual language editors using tool independent artifacts based on commonly available standards. We believe that in our approach we have addressed these requirements. However, we believe the Eclipse GMF shares most of the concerns mentioned in these requirements. 6 Conclusions and Future Directions In this paper we have studied an approach to construct editors for many visual languages based on the OMG standards. We have outlined what we consider the most important requirements and principles of tools for many visual languages and presented an architecture that realizes these ideas. This architecture and the key components presented in this paper has been implemented in the Coral Modeling Framework and has successfully been used to create several advanced modeling tools for DSMLs, as well as a UML editor. Perhaps the most important benefit of the proposed architecture is that responsibilities are clearly distributed between the model repository, editor and change 13

18 propagation components and views. The decoupling of model editors and diagram updates allows a DSML developer to focus on the abstract models alone when developing new editors. In addition, most components in the architecture are configured and customized using declarative tool-independent languages, reducing the need to do manual imperative programming using an API. The Coral Modeling Framework is ongoing research, and possible future directions is to investigate how the editor construction process can be simplified further. In addition there is future research work in finding new interesting ways of editing and visualizing models. Another direction is to investigate how Coral can be used to generate editors using other model repositories such as the Eclipse EMF. Acknowledgments. Torbjörn Lundkvist would like to acknowledge the financial support of the Nokia Foundation. References [1] The Atlantic Zoo. Available at [2] The Eclipse Graphical Editing Framework. Available at [3] The Eclipse Graphical Modeling Framework. Available at [4] Marcus Alanen. A Metamodeling Framework for Software Engineering. PhD thesis, May [5] Marcus Alanen, Torbjörn Lundkvist, and Ivan Porres. Creating and Reconciling Diagrams After Executing Model Transformations. Science of Computer Programming, 68(3): , Oct [6] Marcus Alanen and Ivan Porres. Change propagation in a model-driven development tool. In Proc. of the 3rd Workshop in Software Model Engineering WISME04, [7] R. Bardohl, H. Ehrig, J. de Lara, and G. Taentzer. Integrating Meta Modelling with Graph Transformation for Efficient Visual Language Definition and Model Manipulation. In Springer, editor, Proceedings of the Fundamental Aspects of Software Engineering (FASE), pages , [8] Frank Budinsky, David Steinberg, Ed Merks, Raymond Ellersick, and Timothy J. Grose. Eclipse Modeling Framework. Addison Wesley Professional, August

19 [9] Sitt Sen Chok and Kim Marriott. Automatic Generation of Intelligent Diagram Editors. ACM Transactions Computer-Human Interaction, 10(3): , [10] The Eclipse Modeling Framework website. emf. [11] Karsten Ehrig, Claudia Ermel, Stefan Hänsgen, and Gabriele Taentzer. Towards Graph Transformation Based Generation of Visual Editors Using Eclipse. Electronic Notes in Theoretical Computer Science, 127(4): , [12] David Harel. On Visual Formalisms. Communications of the ACM, 31(5): , May [13] Frédéric Jouault, Jean Bézivin, and Ivan Kurtev. Tcs:: a dsl for the specification of textual concrete syntaxes in model engineering. In GPCE 06: Proceedings of the 5th international conference on Generative programming and component engineering, pages , New York, NY, USA, ACM. [14] Steven Kelly. Comparison of Eclipse EMF/GEF and MetaEdit+ for DSM. In 19th Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications, Workshop on Best Practices for Model Driven Software Development, October [15] Oliver Köth and Mark Minas. Structure, Abstraction, and Direct Manipulation in Diagram Editors. LNCS, 2317: , [16] G. Krasner and S. Pope. A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80. Journal of Object-Oriented Programming, 1(3):26 49, [17] A. Ledeczi, M. Maroti, A. Bakay, G. Karsai, J. Garrett, C. Thomason, G. Nordstrom, J. Sprinkle, and P. Volgyesi. The Generic Modeling Environment. In Workshop on Intelligent Signal Processing, Budapest, Hungary, volume 17, May [18] Johan Lindqvist, Torbjörn Lundkvist, and Ivan Porres. A Query Language With the Star Operator. In Proceedings of the 6th International Workshop on Graph Transformation and Visual Modeling Techniques (GT-VMT 2007), volume 6(2007) of Electronic Communications of the EASST, Braga, Portugal, March EASST. [19] Netbeans. Netbeans Metadata Repository (NMR). Available at mdr.netbeans.org/. 15

20 [20] OMG. UML 2.0 Superstructure Specification, August Document ptc/ , available at [21] OMG. MOF 2.0/XMI Mapping Specification, v2.1, September Document formal/ , available at [22] OMG. Unified Modeling Language: Diagram Interchange version 2.0, June OMG document ptc/ Available at [23] OMG. Meta Object Facility (MOF) Core Specification, version 2.0, January Document formal/ , available at [24] Grzegorz Rozenberg, editor. Handbook of Graph Grammars and Computing by Graph Transformations, Volume 1: Foundations. World Scientific, [25] W3C. Scalable Vector Graphics (SVG) 1.1 Specification, January Available at [26] Andreas Winter, Bernt Kullbach, and Volker Riediger. An Overview of the GXL Graph Exchange Language. In Revised Lectures on Software Visualization, International Seminar, pages , London, UK, Springer- Verlag. [27] Nianping Zhu, John Grundy, and John Hosking. Pounamu: A Meta-Tool for Multi-View Visual Language Environment Construction. In VLHCC 04: Proceedings of the 2004 IEEE Symposium on Visual Languages - Human Centric Computing (VLHCC 04), pages , Washington, DC, USA, IEEE Computer Society. 16

21

22 Lemminkäisenkatu 14 A, Turku, Finland

23 University of Turku Department of Information Technology Department of Mathematics Åbo Akademi University Department of Computer Science Institute for Advanced Management Systems Research Turku School of Economics and Business Administration Institute of Information Systems Sciences ISBN ISSN