MASTER. Integration of Xtext and GMF editors in Eclipse. Dudojevic, E. Award date: Link to publication

Transcription

1 MASTER Integration of Xtext and GMF editors in Eclipse Dudojevic, E. Award date: 2014 Link to publication Disclaimer This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required minimum study period may vary in duration. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain

2 Technical University Eindhoven Master Thesis Integration of Xtextand GMFeditors in Eclipse Author: Edin Dudojević Supervisors: prof. dr. Mark van den Brand dr. ir. Arjan Mooij Software Engineering and Technology Department of Computer Science June 2014

3 Abstract Modern Integrated Development Environments (IDEs) provide interactive textual editors and often also offer graphical editors for additional visualization. Eclipse is a platform for developing IDEs, frameworks and other plug-in based applications. The Eclipse Modeling Framework (EMF) is one such framework that enables us to build textual, graphical and other editors on a structured data model. Multiple EMF based frameworks have been developed that offer textual and graphical model editors. However, these frameworks often only operate in isolation, and at best provide a partial integrated solution. Furthermore, textual frameworks can be used mainly to operate on full models. The main problem is that as models tend to get large a user quickly loses overview, which raises the question on how we can isolate certain parts of a model, edit these parts and do this from multiple active editors. In this work we investigate specifically the EMF based frameworks Xtext and GMF, used respectively for developing textual and graphical editors. For both frameworks we propose several approaches on how to apply and orchestrate partial model editing with an overall synchronization of multiple editors. We provide the relevant integration code and demonstrate the proposed solutions with a couple of implementations.

4 Acknowledgements First of all, I would like to to thank my supervisors Mark van den Brand and Arjan Mooij, which devoted a large amount of time to steer this project into the right direction. Their feedback and insightful criticisms have been very helpful and aided the succesful completion of this project. Big thanks also goes to Luo Yaping (Luna) for her overall help and useful discussions at times I faced challenging problems. Finally, a special thanks goes to my beloved fiance Ajka, but also my mother Emina and my brother Ermin who all supported me throughout my entire study, and especially during this project. iii

5 This thesis is dedicated to my father, Nedžad Dudojević... iv

6 Contents Abstract ii Acknowledgements iii Contents List of Figures Contents Abbreviations v ix xi xiii 1 Introduction Context Project background Problem domain Problem overview and goal restrictions Problem statement Summary and approach Integration requirements POOSL language POOSL Definition Relation to SHESim POOSL use cases Creating instantiations and editing existing cluster classes Instantiating clusters Renaming a process class and its ports Error propagation Integration requirements Conclusions State of the art Survey of EMF-based technologies The Eclipse Project Eclipse Modeling Framework (EMF) v

7 Contents vi Textual modeling frameworks Graphical modeling frameworks Evaluation Existing integration Propagation of changes GMF model referencing Summary and evaluation Conclusions Towards partial model editors Introduction Partial model Xtext editors The highlight range approach Synchronization of regular changes Eclipse editor operations Renaming elements Sub-grammar restrictions Evaluation of advantages and disadvantages Dedicated partial model Xtext editors GMF partial editors Embedded partial editors Possible combinations of embedded editors Viewing and editing textual partial models as labels Viewing and editing labels with syntax highlighting Evaluation Conclusion Architectural patterns Introduction Navigational structures Multi-editor architectures Conclusions Implementation Introduction Greetings Generating implementation code Customization Result State machines Generating implementation code Customization Result Web application Generating implementation code and customization Result POOSL

8 Contents vii Generating implementation code Result Evaluation Related work Related technologies Sirius Meta Programming System (MPS) Yakindu Statechart Tools BPEL Designer Related research Conclusions Results Further discussion on co-evolution Future work A Xtext grammars and model definitions 77 A.1 Greetings Xtext grammar A.2 Statemachines Xtext grammar A.3 Web application Ecore definition A.4 POOSL high-level meta-model B Integration code 81 B.1 Activator.java B.2 EditPolicyProvider.java B.3 OpenEditPolicy.java B.4 XtextNewTabEditor.java B.5 plugin.xml extension point C Tutorials 89 C.1 Creating an Xtext editor C.2 Creating a GMF editor C.3 Integrating YST plugins Bibliography 95

9

10 List of Figures 1.1 An example Eclipse instance using multiple editors SHESim interface, showing a high-level overview of a network layer model SHESim: Class editing window for DataLinkSender SHESim: Instantiation parameter editing window for DataLinkSender Selecting the process definition SomeProcessClass from the property view Connecting the ports with channel c Choosing the class definition of a process from the right-click menu Showing the class definition in a textual editor Showing the instantiation parameters in a textual editor Adding extra port q Creating a new cluster cluster The textual representation of cluster Adding and connecting cluster ports s and r Connecting the two processes to previously created cluster Renaming a process class and its ports Defining a custom process class in the textual editor Synchronization of graphical editor by using an incomplete textual model The relationship between EditPart, model element and graphical representation The relationship between GEF, GMF and EMF Simplified GMF workflow GMF synchronization with the standard outline and properties view Default Xtext-GMF synchronization overview Greetings example file An example with applying the highlight range functions Highlight range showing entire line where the offset range is located Editing a label in GMF An example use of GMF compartments Editing a label in GMF Editing a label in GMF Using the Open-declaration functionality with the highlight-range method Conceptual architecture for the default Xtext-GMF integration GMF diagram defined for the full model, and the Xtext editor defined for a sub-tree ix

11 List of Figures x 5.4 Multi-editor architecture using a full model Xtext editor and a subdiagram GMF editor Multi-editor architecture using one Xtext editor for full model and two different GMF editors Greetings example: the full textual model Greetings example: a partial textual model element Statemachines example diagram Web application example: meta-model definition Web application example: instantiated subdiagrams POOSL example: GMF editor for the system element, showing its highlevel instances POOSL example: Opening up a GMF sub-diagram from a cluster class element POOSL example: Showing instance parameters in Xtext POOSL example: Showing a cluster class definition in Xtext POOSL example: Showing system and its instances Projectional editors in MPS where effectively textual editors are embedded in other textual parts Yakindu wrapper example integrated with a state transition system Xtext integration in BPEL Designer Embedding textual editors into graphical host editors using the approach of Scheidgen A.1 High-level meta-model of POOSL C.1 GMF Dashboard C.2 Workflow for the creation of a GMF editor C.3 Yakindu wrapper example integrated with a state transition system C.4 Yakindu wrapper example integrated with a state transition system... 94

12 Listings 3.1 Greetings example diagram file: XMI content Greetings example diagram file: using indexes Applying the highlight range functions Determining the offset and length of a model element PartialParser example Statemachines: example file A.1 Xtext grammar: Greetings A.2 Xtext grammar: Statemachines A.3 Web application ecore file B.1 Activator.java B.2 EditPolicyProvider.java B.3 OpenEditPolicy.java B.4 XtextNewTabEditor.java B.5 plugin.xml extension point xi

13

14 Abbreviations API AST DSL EMF ESI GEF GMF IDE MPS MVC POOSL SLCO UI URI XMI XML YST Application Programming Interface Abstract Syntax Tree Domain Specific Language Eclipse Modeling Framework Embedded Systems Innovation (by TNO) Graphical Editing Framework Graphical Modeling Framework Integrated Development Environment Meta Programming System Model View Controller Parallel Object-Oriented Specification Language Simple Language of Communicating Objects User Interface Uniform Resource Identifier XML Metadata Interchange extensible Markup Language Yakindu Statechart Tools xiii

15

16 Chapter 1 Introduction 1.1 Context Domain-Specific Languages (DSLs) receive attention as the possible next abstraction step in programming that bring software development closer to the domain requirements. Modern implementation technologies like the Eclipse Modeling Framework (EMF) seem to boost the industrial interest in DSLs. There are several tools based on EMF for developing textual editors and graphical editors. Although EMF acts as a common base to such editors, the proper way to integrate them is not so clear. 1.2 Project background The origins of this project lie in the work of Zlatka Manevska who created a User Interaction Layer (UIL) for POOSL [1], which is a system-level description language that is used at Embedded Systems Innovation (ESI), a group of TNO in Eindhoven, for modeling complex systems. The UIL is meant to replace SHESim, which is a combination of textual and graphical editors used for specification of POOSL models. The main problem with SHESim is that it is outdated and poses several limitations such as the lack of interactivity and many other usability issues. Manevska developed a sophisticated textual editor for POOSL, but also provided a graphical editor prototype, both based on EMF. Based on an evaluation of existing technologies Xtext and GMF 1

17 Chapter 1. Introduction 2 were chosen for the development of respectively a textual and graphical editor. However, due to several difficulties, the integration of textual and graphical editing turned out to be far from trivial and was therefore left as an open issue. This served as a basis for the formulation of this research project, which in contrast to Manevska s project, however, focuses on the integration problem in general within the range of Eclipse and EMF based textual and graphical frameworks. 1.3 Problem domain In this section we analyse the problem of integrating editors by discussing various aspects that play an important role. Based on this discussion we formulate the problem and establish several research questions that will be answered at the end of this thesis Problem overview and goal restrictions Integration can be defined in a very broad way: the act of combining or adding parts to make a unified whole. From the perspective of models in modern IDEs, we look at combining different kinds of representations of such a model that we consequently want to view or edit. The Eclipse platform is a perfect example that allows the use of multiple windows with various editors and many more functionalities as one would expect from a mature IDE. In Figure 1.1 we see such an Eclipse instance where multiple editors ares used, indicated with red. The objects indicated with a green color are different representations of the same model element that is shown over multiple editors, and saved within one file. Changes to an object in one editor is in most cases directly reflected in other editors. To make this possible we require a tight integration between these editors, where we need to consider a couple of important aspects. From the user perspective we can think of the following characteristics: Partial views: The advantage of considering only a part of the model is mainly because of modularity: we only focus on the relevant part that we want to view and/or edit. Especially in case of big models which are often not useful to view at once, we would rather split them up in partial views from which we can navigate

18 Chapter 1. Introduction 3 Figure 1.1: An example Eclipse instance using multiple editors further through the rest of the model. In hierarchical models, for example, a navigation through layered views could be realized where each view contains a certain level of abstraction with information that is considered relevant at that point. Note furthermore that the use of partial model views also applies to small models in case we for example edit certain properties of a model element. In any case we want to restrict the information we see as the user. Multiple types of editors: A user should be able to use multiple types of editors: textual, graphical, tree editors, etc. Multiple editors at the same time: Modern IDEs usually allow the user to use multiple views and/or editors at the same time. Based on the above characteristics the following issues arise: Representation/Serialization: There are different kinds of representations to choose which in general are either textual or graphical, but the representations can also be of some other form like tree-views such as the outline in Eclipse. Moreover,

19 Chapter 1. Introduction 4 certain parts of our model are best represented textually, such as complex expressions, while others can be represented both textually and graphically. We can serialize our model to a certain format but in case of multiple representations we may have additional information. For example, graphical editors can have position information that, if adaptable by the user, typically needs to be saved. Textual editors, on the other hand, should be able to save textual layout information or comments. Furthermore, should we save this textual and/or graphical information to one or multiple files? Synchronization: Having multiple editors raises several important questions if we look at how we update and propagate information between them: Time of serialization: When do we save our model after changes are made? Is this done in real-time or only when a user explicitly saves the model? Synchronization: How do changes affect the model that is (partially) displayed in several editors? For example, one typically wants to always have an option to save a model, even if it contains errors. Synchronization therefore might not always be possible, or, if still performed, can lead to unexpected behavior. Navigation: When using multiple editors we can also think about the way we navigate between these editors. This especially plays a role when partial views are considered. With respect to this we can ask the following questions. What possibilities for navigation can we use in this case? What influence does the use of different kinds of editors have on this navigational structure? These questions provide a rough sketch of some of the possible problems that one might encounter. When dealing with existing technologies that need to be integrated it is necessary to analyze all the constraints and possibilities that each tool entails, which in turn can easily add up to the previously discussed complexities. This makes the problem very broad, which in the scope of this project, requires us to narrow the focus of this research. We will therefore restrict ourselves to the Eclipse ecosphere, and more specifically, on EMF based frameworks within Eclipse. Furthermore, we primarily look at integrations between textual and graphical editors.

20 Chapter 1. Introduction Problem statement Based on the previous discussions we can formulate the problem statement as follows: We want to be able to edit a model using multiple (partial) editors, both textually and graphically (or some other representation form), while keeping everything synchronized, independent of the modeling language being used. In addition, we also want to be able to navigate between these editors, where applicable. Regarding the above problem statement, there are furthermore a couple of important questions that need to be answered: Which EMF-based frameworks can and should be used? How can this integration of editors be done in a systematic and generic way? 1.4 Summary and approach In the previous sections we have discussed various aspects of integration in general and formulated the problem statement. Based on these integration aspects which encompass multiple problems including the creation of partial model editors and synchronization between them, it is clear that this is not a trivial problem, which was exactly one of the conclusions of Manevska in [1]. Moreover, there is also no single solution since integration strongly depends on the users specific needs (which will be discussed in the following chapters). Since the topic of integrating editors in general is too broad for this project, the scope was narrowed by explicitly choosing for Eclipse, and more specifically, EMF. To solve this problem we will use the following approach. We first establish the integration requirements based on a few uses cases for an existing modeling language (discussed in the next chapter). We will use the POOSL language, which fits in line with previous work by Zlatka Manevska [1]. In the next step we investigate existing technology and discuss whether it can be used to solve our problem. For the provided solution we will set as goal to provide an effective solution that is both practical and easy to apply. After proposing a solution we will show that these integrations can indeed be accomplished by implementing a couple of representative use cases.

21 Chapter 1. Introduction 6 The outline of this thesis is as follows: Chapter 2: In this chapter we discuss a couple of representative use cases and establish the integration requirements. Chapter 3: In this chapter we discuss related technologies, select the most applicable tools, and discuss existing integrations based on this selection. Chapter 4: This chapter describes a couple of approach on constructing partialmodel editors. Chapter 5: This chapter describes the integration patters when multiple editors are used in a larger context. Chapter 6: In this chapter we present a few implementations to confirm our findings. Chapter 7: In this chapter related work is discussed. Chapter 8: In this final chapter we reflect on the overall results and draw the necessary conclusions.

22 Chapter 2 Integration requirements In this chapter we show a few relevant use cases for the POOSL language. Based on these use cases we finally formulate the integration requirements. The SLCO language has also been investigated but will be omitted in this chapter since it is very similar to POOSL. 2.1 POOSL language POOSL Definition POOSL (Parallel Object-Oriented Specification Language) is a system-level modeling language that has been used at ESI (Embedded Systems Innovation by TNO) for modeling complex systems. It is part of the system-level design method SHE (Software/Hardware Engineering) and was formally defined in [2]. POOSL models can be executed with the simulation tool SHESim [3]. POOSL consists of three conceptual layers [4]: an architecture, a process and a data layer. The architecture layer describes reactive systems which can often be decomposed into several communicating subsystems, which may also be decomposable. The modeling elements of the architecture layer are: Processes: represent subsystems that are considered as single entities 7

23 Chapter 2. Integration requirements 8 Clusters: denote a group composed of processes and clusters, by which they introduce hierarchy to the models Channels: symbolize the communication paths between processes and clusters The process layer describes the behavior of processes, their communication interface and their message interface. Processes are instantiations of their process classes. A process consists of ports that are possibly connected to channels through which messages can travel. The data layer contains data classes that describe what variables and methods its instances have. A high-level meta-model of POOSL with the most important elements for our use cases is given in Appendix A Relation to SHESim It is important to note that we will loosely adhere to the navigational structure of SHESim [5]. The interface of SHESim with an example model of network layers is shown in Figure 2.1. Figure 2.1: SHESim interface, showing a high-level overview of a network layer model The SHESim concepts that we want to use in our use cases are mainly editing classes and instantiation parameters in separate windows. So if we want for instance to edit the class of DataLinkSender3 then we instantiate a new window from the right click menu as shown in Figure 2.2.

24 Chapter 2. Integration requirements 9 Figure 2.2: SHESim: Class editing window for DataLinkSender3 In this window we can add/remove/edit instance variables, instantiation parameters, instance methods, port interfaces and message interfaces. Editing of instantiation parameters is performed in a separate window. The instance parameters of DataLinkSender3 are edited in a separate window, as shown in Figure 2.3. Figure 2.3: SHESim: Instantiation parameter editing window for DataLinkSender3 2.2 POOSL use cases In this section we discuss a few relevant use cases for POOSL, based on SHESim. Note that the illustrations are used mainly as conceptual visualizations.

25 Chapter 2. Integration requirements Creating instantiations and editing existing cluster classes We start by creating an empty diagram. The next thing we want to do is add two instances, process1 and process2 which should both be instantiations of some process class (we assume the process class is already defined). We do this by placing the instantiation elements on our diagram and selecting for each the same process definition SomeProcessClass (from the property view for example - see also Figure 2.4). Properties Name process1 Class definition SomeProcessClass Figure 2.4: Selecting the process definition SomeProcessClass from the property view We also want these processes to communicate with each other, so we connect their ports p and q by adding channel c. Figure 2.5 shows a high-level view of our system: process1 : SomeProcessClass process2 : SomeProcessClass p : Port c : Channel p : Port System Figure 2.5: Connecting the ports with channel c process1 : SomeProcessClass Right-click menu.. p : Port Instantiation parameters Class definition.. Figure 2.6: Choosing the class definition of a process from the right-click menu Next we want to view and edit the process class SomeProcessClass. We do this by right clicking on the process1 figure and left clicking on the class definition option from the drop down menu (Figure 2.6). The class definition is shown in a textual editor (Figure 2.7). Similarly, we want to show the instantiation parameters. However, in this example the instance does not use any, so only the textual representation of the instance is shown without parameters (Figure 2.8).

26 Chapter 2. Integration requirements 11 process1 : ProcessClassY class definition process class ProcessClassY instance variables a : Integer; port interface p message interface p1!easy; p2!normal; p3!hard; initial method call somemethod()() instance methods somemethod()() sel in!easy; or in!normal; or in!hard; les; somemethod()(). Figure 2.7: Showing the class definition in a textual editor 1 instance process1 : SomeProcessClass () Figure 2.8: Showing the instantiation parameters in a textual editor We now want to add one extra port to our process class, let s say port q, by using the textual editor. The changes are saved (preserving textual layout (and possibly comments)) and we return to the previous high-level overview of our system. We directly see that the changes have been propagated since our port q is now also available in our graphical editor (Figure 2.9). process1 : SomeProcessClass p : Port c : Channel process2 : SomeProcessClass p : Port q : Port q : Port System Figure 2.9: Adding extra port q Instantiating clusters Based on the two processes and the process class changes from the previous use case, we continue by adding a cluster that will contain some internal processes that we want to hide from our high level view. We give our cluster the name cluster1 (Figure 2.10). The textual representation of our cluster is shown in Figure 2.11.

27 Chapter 2. Integration requirements 12 process1 : SomeProcessClass p : Port c : Channel process2 : SomeProcessClass p : Port q : Port q : Port cluster1 : SomeClusterClass System Figure 2.10: Creating a new cluster cluster1 1 instance cluster1 : SomeClusterClass () Figure 2.11: The textual representation of cluster1 In our new cluster we want to define some ports which we can connect to a channel between our defined processes. We do this by adding the cluster ports s and r. We also add two processes cp1 and cp2. We define the internal cluster structure as depicted in Figure r : Port rcp1 : Channel cp1r : Port cp1 : BClass cp1s : Port cp1s : Channel s : Port cp1out : Port cp1in : Port cp1cp2 : Channel cp2cp1 : Channel cp2in : Port cp2out : Port cp2 : SClass SomeClusterClass Figure 2.12: Adding and connecting cluster ports s and r

28 Chapter 2. Integration requirements 13 We save the model and return to our high-level overview. The final thing we want to do is to connect the processes process1 and process2 to our newly created cluster. We do this by defining two new channels qr and qs that connect ports q (process1) and r, and q (process2) and s. The result is shown in Figure Any position information of the graphical objects is preserved. process1 : SomeProcessClass p : Port c : Channel process2 : SomeProcessClass p : Port q : Port q : Port qr : Channel qs : Channel r : Port s : Port cluster1 : SomeClusterClass Figure 2.13: Connecting the two processes to previously created cluster Renaming a process class and its ports In this use case we want to rename the class definition from the example in Figure 2.5 by using a textual editor. We show the system with a graphical editor, as displayed in the same figure, and now want to change the name of the process class definition within a textual editor. Since both instances use the same process class SomeProcessClass, we can use either instance to instantiate the editor. Within the textual editor we change SomeProcessClass into ProcessClassX. In addition, we also want to change the name of the port from currently p into x. After changing the names we save the changes and return to our graphical model overview. The changes have been propagated to the graphical view automatically (Figure 2.14).

29 Chapter 2. Integration requirements 14 process1 : ProcessClassX process2 : ProcessClassX x : Port c : Channel x : Port System Figure 2.14: Renaming a process class and its ports Error propagation We continue with the example from previous section. We now want to create a custom class for the second process instance process2. We open up the textual editor and empty the content. The process class for the second instance should now have the name ProcessClassY instead. However, at the moment we do not know what the rest of the process should look like but still want to save our incomplete process. The textual model is shown in Figure Since we call the methode somemethody which we have not defined later on, the editor (correctly) shows an error on line 16. We save the textual model and return to our graphical view of the system x process class ProcessClassY instance variables b : Integer; port interface y message interface y1!easy; y2!normal; y3!hard; initial method call somemethody()() Figure 2.15: Defining a custom process class in the textual editor The incomplete textual model still gets synchronized with the graphical view. We can see the result in Figure We see that the name of the process is now shown as ProcessClassY, and the port name as y. However, since the channel connection is not defined correctly, it is not shown in our graphical model.

30 Chapter 2. Integration requirements 15 process1 : ProcessClassX process2 : ProcessClassY x : Port y : Port System Figure 2.16: Synchronization of graphical editor by using an incomplete textual model 2.3 Integration requirements Based on the previous use cases we can formulate the following global integration requirements: 1 IR0 It should be possible to instantiate editors both graphically and textually, where applicable. IR1 It should be possible to switch between multiple editors (textual or graphical) that are active at the same time. IR2 It should be possible to only show parts of a model, either textually or graphically. IR3 It should be possible to show multiple parts of a model (textually and/or graphically) at the same time. IR4 The editors should provide a proper navigation structure: [IR4.1] from graphical to textual [IR4.2] from graphical to graphical [IR4.3] from textual to graphical [IR4.4] from textual to textual IR5 Textual (including any comments, tabs, newlines etc.) saved for a model. and graphical layout is IR6 Changes are propagated to other editors/views. IR7 It should be possible to edit parts of a model in separate editors. 1 Some of the requirements are not directly covered by the use cases, but are rather implicitly derived.

31 Chapter 2. Integration requirements 16 We can directly relate these requirements to the integration aspects from Chapter 1: Partial views: IR2, IR3 Multiple types of editors: IR0, IR3 Multiple editors at the same time: IR1, IR3, IR7 Representation/Serialization: IR5 Synchronization: IR6 Navigation: IR4 2.4 Conclusions In this chapter we have used a few use cases for the POOSL language in order to establish integration and related functional requirements. From the use cases we can relate to the integration aspects that we discussed in the previous chapter. We use partial views to show parts of a model and use different kinds of representations to do so. We navigate our models hierarchically by opening sub-diagrams for clusters while having both textual and graphical representations for our model elements. By using subdiagrams and textual instantiations of parts of a model, we also use multiple editors. For the latter we of course require that changes are propagated correctly. Based on these observations we derived general integration requirements. However, it is necessary to investigate existing technology and what constraints they enforce. In the next chapter we will evaluate multiple existing frameworks and choose the most applicable in terms of our stated requirements. Based on these results we will mainly try to answer the posed research question Which EMF-based frameworks can and should be used?.

32 Chapter 3 State of the art In the previous chapter we established the most relevant integration requirements by using a few POOSL use cases. The purpose of this chapter is to give a brief survey of existing technology and choose a set of related tools that best suits our needs with respect to our stated integrations requirements. Next, a thorough analysis of the selected tools is performed which will serve as a basis for establishing a solution to the problem in the next chapter. 3.1 Survey of EMF-based technologies In this section we will briefly look at the existing technologies that are directly related to our stated problem, and more specifically, technologies based on EMF. We will start with the relevant concepts of Eclipse and EMF, followed by a breakdown of the available textual and graphical frameworks The Eclipse Project The Eclipse project supports the development of a platform, or framework, for the implementation of integrated development environments (IDEs) and other applications [6]. Eclipse is divided into several components, among which is the Plug-in Development Environment (PDE) that provides views and editors to facilitate the creation of plug-ins 1 At the time of this writing, the Eclipse Kepler version has been used. 17

33 Chapter 3. State of the art 18 for Eclipse. Views present information about the object that is selected in another view or editor and typically reflect any changes immediately. The most important and related views in Eclipse are the standard Outline and the Property view. Within our context we are mainly interested in the basic functionality provided by Eclipse for dealing with our models by using multiple editors. From that perspective, integrated tools in Eclipse work with ordinary files and folders, but use a higher level API (Application Programming Interface) that is based on resources, projects and a workspace. In this context, the most relevant concept is the Resource which is the Eclipse representation of a file. A resource contains change listeners, markers (such as error messages) and a history for previous content. Change listeners can be registered to receive resource change notifications (also called resource deltas) and used for synchronization on changes. Markers and history are less relevant for synchronization. A collection of resources which can contain cross references is called a ResourceSet Eclipse Modeling Framework (EMF) The Eclipse Modeling Framework (EMF) is a framework and code generation facility for building tools and other applications based on a structured data model [6] [7]. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. To get a better understanding how we can use EMF to describe our models, we need to look at its core concept which is Ecore - a model for describing models, also called a metamodel. Using EMF and such a meta-model definition, we can create model instances which are by default serialized as Ecore XMI (XML Metadata Interchange) files. We will see later on that such a file can be used as a central point of integration. Furthermore, EMF provides us with the possibility to automatically generate implementation code, which is directly used by higher-level frameworks that use EMF as their basis. This is done by a so called generator model that describes the translation of the content into executable code. We can also directly customize this code to meet our specific needs. For a detailed description of EMF see also [6].

34 Chapter 3. State of the art Textual modeling frameworks Xtext Xtext is an EMF-based framework for developing textual DSLs and it can be used to edit textual representations of models [8]. 2 The initial version of Xtext was part of the openarchitectureware framework [9], which now, after a rewrite, became part of the Textual Modeling Framework (TMF) in Eclipse. Xtext offers many useful functionalities such as syntax coloring, code-completion, outlineview, source-code navigation, hovers, etc. The runtime components (parser, lexer, linker, validation, etc.) are integrated with EMF which gives us the possibility to use Xtext with other EMF-based frameworks. Moreover, Xtext uses EMF models as in-memory representations of any parsed text files. We call such an in-memory object an Abstract Syntax Tree (AST) or simply model [? ]. After defining a DSL grammar, we can automatically generate an editor. Furthermore, Xtext automatically creates an EMF generator model and runs it, which in turn generates the EMF implementation code. Xtext also automatically generates an Ecore meta-model that corresponds to our previously defined Xtext grammar. EMFText EMFText is a framework that lets you define textual DSLs by using a predefined Ecore meta-model. 3 It provides provides a syntax specification language from which textual editors and components to load and store model instances can be generated [10]. offers, just like Xtext, advanced features such as code completion, customizable syntax, etc. Other textual modeling frameworks There exist also other, EMF-based textual modeling frameworks such as TEF (Textual Editing Framework) 4 [11], TCS (Textual Concrete Syntax) [12] and MontiCore 5 [13]. An extensive survey on language workbenches has been made by Erdweg et al. in [14], where additional textual frameworks are discussed such as Rascal and Spoofax. However, these frameworks are not based on EMF. Since this work has not been intended to It

35 Chapter 3. State of the art 20 provide an extensive investigation of all the frameworks, these other frameworks are omitted and serve here only for the sake of completeness Graphical modeling frameworks GEF The Graphical Editing Framework (GEF) is a framework that provides technology to create rich graphical editors and views for the Eclipse Workbench UI [15]. GEF is built on top of the following components: Draw2D (org.eclipse.draw2d) A layout and rendering toolkit for displaying graphics on an SWT Canvas [16]. GEF MVC framework (org.eclipse.gef) A model-view-controller framework that fosters the implementation of SWT-based tree and Draw2d-based graphical editors for the Eclipse Workbench UI. [17]. Zest (org.eclipse.zest) The Eclipse visualization toolkit [18]. Zest is based on the Standard Widget Toolit (SWT) [19]. GEF uses so called EditParts which are basically the building blocks for GEF viewers. They serve as a link between the application s model and the visual representation. This is illustrated in Figure 3.1. However, GEF uses quite low level functions for drawing and is best used by providing drawing functionality for any higher level framework. Furthermore, the components of GEF do not provide any connection with the EMF editor which was exactly one of the main requirements. GMF The Graphical Modeling Framework (GMF) is a framework within the Eclipse platform that provides a generative component and runtime infrastructure for developing graphical based editors based on EMF and GEF. Currently, it is part of the Graphical Modeling Project (GMP) as three separate components: GMF Tooling, GMF Runtime and GMF Notation. With GMF Tooling we can create and edit models, but also a generator for producing implementation code that uses GMF Runtime for the core functions of the graphical editor. GMF Notation provides a standard EMF notational meta-model

36 Chapter 3. State of the art 21 GraphicalViewer Model EditParts Figures x Figure 3.1: The relationship between EditPart, model element and graphical representation that takes care of persisting diagram information separately of the domain model. The dependencies of GEF, GMF and EMF are illustrated in Figure 3.2. GMF Editor uses uses GMF Runtime uses EMF uses GEF uses uses Eclipse Platform Figure 3.2: The relationship between GEF, GMF and EMF Developers that use GMF to create graphical editors typically follow the workflow as shown in Figure 3.3. We can summarize the steps as follows. After creating a domain model (.ecore) we can derive the following files: Graphical definition model: a.gmfgraph file where we define our concrete graphical syntax.

37 Chapter 3. State of the art 22.gmfgraph.ecore Graphical Definition Model.gmfmap.gmfgen Domain Model Mapping Model Generator Model generate Basic GMF-editor Tooling Definition Model.gmftool Figure 3.3: Simplified GMF workflow. Tooling definition model: a.gmftool file where we define the tools that will be available for creating graphical elements. By combining our domain model and the above two definition models we can generate a so called mapping model (.gmfmap) that essentially maps elements from our domain model to our graphical notation definition. Once we have created a mapping model we can create a generator model (.gmfgen) by which we are able to automatically generate implementation code that we can customize to our needs. On top of GMF, there exist (at least) three higher-level frameworks: EuGENia is a framework used on top of GMF that raises the level of abstraction in generating GMF editors, based on an annotated Ecore model [20]. Kaybele is very similar to EuGENia and is also a higher-level framework that provides the possibility for annotations and automatically generate GMF code. 6 GenGMF is another high-level framework that also aims at simplifying the incremental development of GMF editors [21]. 7 These higher-level frameworks can greatly decrease the development time and complexity of simple GMF editors. Although it can significantly increase the level of production, it should not be the point of investigation (in terms of our integration problem) since the core functionality that we will be focusing on resides in GMF. 6 The project seems abandoned with its last contribution dating to The project has been abandoned and the Eclipse project proposal has been withdrawn.

38 Chapter 3. State of the art 23 Graphiti Graphiti is a framework for developing graphical editors for models based on EMF [22] and is analogous to GMF. However, it currently still resides in the so called Incubation Phase, that is, it is still not a fully functioning product. Furthermore, in the work of Refsdal it is stated that edit policies, requests and commands are invisible to the user in Graphiti [23]. Another important fact is that Graphiti, unlike GMF, does not generate any implementation code. This raises questions regarding the practical difficulties with integration and whether this is achievable. With this in mind and without further investigation it is assumed that any integrations are at least more difficult to achieve than is the case with GMF. For the sake of completeness it is worth mentioning that a higher-level framework for Graphiti exists called Spray [24], which is somehow analogous to EuGENia and Kaybele Evaluation Just as Xtext, EMFText uses EMF for defining the abstract syntax and is considered very similar [25]. Although EMFText can probably also be used as an Xtext alternative, in this project the choice was made to use only Xtext, for several reasons. The most important one is that POOSL is used as a use case, but also because there was already an Xtext grammar available for POOSL [1]. Furthermore, the Xtext community seems significantly larger and there seem to be more examples and documentation available. Last but not least, the author was already familiar with Xtext. For constructing a graphical editor we considered several frameworks. GEF is considered quite low level and does not provide any linkage to EMF. The higher-level frameworks GMF and Graphiti do provide this linkage to EMF, but as we discussed Graphiti had major drawbacks in comparison with GMF: it does not generate implementation code and it is not published as a major version. This results in GMF as the clear choice. Other even higher-level framework exist on top of GMF (and Graphiti), but these are considered irrelevant since they mainly facilitate automation of generating implementation code.

39 Chapter 3. State of the art Existing integration We already mentioned that Eclipse provides two relevant views which are integrated into the workbench: the standard Outline and the Property view. 8 EMF, Xtext and GMF are directly integrated with these default Eclipse views. In case of GMF, for example, when viewing our model definitions we see the tree structure of our model displayed in the Outline view where we can also make certain changes. Other information such as selection of nodes in the Outline view is also propagated to the other view(s) (Figure 3.4). Figure 3.4: GMF synchronization with the standard outline and properties view. Besides the synchronization between default Eclipse components and Xtext/GMF there already exists an out of the box synchronization between Xtext and GMF on full models. 9 The typical way of achieving this is to start off with an Xtext grammar, generate the Xtext artifacts, and then use the obtained Ecore model in the GMF workflow to generate a GMF editor (discussed in Section 3.1.4). A simplified overview of the existing integration is depicted in Figure 3.5. The Xtext and GMF views (on top) are textual and graphical representations of our model, respectively. Each such editor uses a ResourceSet that in turn contains a Resource that reflects an in-memory model of our physical file. Xtext uses an XtextResource, which is an extension of the default Resource class. GMF, on the other hand, which needs to deal with both position information of the graphical elements and with the abstract 8 These views are sometimes also editors when we get the option to make changes. 9 Section: Integration with GMF Editors.

40 Chapter 3. State of the art 25 model elements, uses two resources: an XtextResource and a DiagramResource. The XtextResource contains our AST, and the DiagramResource contains the graphical elements and a reference to XtextResource elements. The XtextResource corresponding to Xtext and the other one to GMF are two strictly separate Resources, where the content is considered equal only after performing synchronization. Xtext GMF ResourceSet ResourceSet XtextResource XtextResource DiagramResource refers to save/load save/load save/load Xtext file GMF File Figure 3.5: Default Xtext-GMF synchronization overview Propagation of changes Any changes, either in our Xtext or GMF editor, are propagated to other active editors and views. So when we for example change our model by using our Xtext editor and save the changes, the XtextResource of GMF gets updated but also the content in the GMF editor. It is important to note that in this case we preserve layout information of other graphical objects that already existed and were displayed in our GMF editor. This is possible because GMF is able to perform a merge in a relatively straightforward way where it compares the previous and current state of our model. However, because of the integration of GMF with Xtext it is still possible to lose layout information. We will discuss this issue and the way GMF references domain model elements in more detail in Section Changes are propagated to other editors and views only when they are saved. Another option would be to perform this in real-time, so that changes in one editor are directly visible in other active editors. However, real-time synchronization adds much more complexity to the problem and would therefore easily fall outside the scope of this

41 Chapter 3. State of the art 26 project. Furthermore, van Rest et al. have already investigated this issue and proposed an approach in [26] (discussed in Chapter 5). Because of the stated reasons it was chosen explicitly not to handle this issue of real-time synchronization GMF model referencing In the previous section we have seen how existing synchronization between Xtext and GMF is realized. In the current approach (as depicted previously in Figure 3.5) Xtext and GMF both have their own XtextResource. Although it is possible to share this resource between Xtext and GMF so that changes on our domain model are reflected directly, it is duplicated in this way for a good reason: on each change Xtext parses the text and rebuilds the AST which means that a subtree (or even the entire tree depending on the specific change) gets removed and again inserted after parsing. If we would use the same XtextResource for Xtext and GMF, removing and adding nodes from our AST during reparsing by Xtext would result in GMF also removing graphical nodes and inserting it back into view. However, removing nodes from GMF would also mean that layout information gets lost, which in most cases gives unwanted behavior but it also does not fulfill our integration requirement where we explicitly state that any layout information should be preserved. However, this preservation of layout information is not foolproof. The problem lies in the way the diagram file references our textual model. Moreover, when we decide to use both Xtext and GMF, we by default use one file in which the textual representation of our model is stored. The GMF diagram file contains only layout information and maps graphical objects to their corresponding domain model elements stored in the textual file. Referencing is done by using so called URI fragments. In case of multiple elements of the same type, indexes are used to identify them. This gives problems in case the order of some elements is switched. We will illustrate this with a small example. Let us assume that we have already generated our Xtext and GMF editor (by following the steps as described in Appendix C.1 and C.2, respectively). We create a file default.mydsl containing three greetings objects and instantiate a diagram file default.mydsl diagram as shown in Figure 3.6. The contents of the diagram file are shown in Listing 3.1.

42 Chapter 3. State of the art 27 Figure 3.6: Greetings example file Listing 3.1: Greetings example diagram file: XMI content 1 <?xml v e r s i o n =" 1.0 " encoding ="UTF -8"?> 2 < notation:diagram xmi:version =" 2.0 " xmlns:xmi =" http: // www. omg. org / XMI " xmlns:mydsl =" http: // www. xtext. org / example / mydsl / MyDsl " xmlns:notation =" http: // www. eclipse. org / gmf / runtime /1.0.2/ notation " xmi:id =" _abexslh - EeOog7oksgXF9A " type =" MyDsl " measurementunit =" Pixel "> 3 < styles xmi:type =" notation:diagramstyle " xmi:id =" _abexsbh - EeOog7oksgXF9A "/ > 4 < element xmi:type =" mydsl:model " href =" default. mydsl #/"/> 5 </ notation: Diagram > On this first instantiation the generated diagram file does not include position information and assumes default positions that are to be determined by GMF when the file is opened. In our case line 4 references the entire model (the Model model element) by using href="default.mydsl#/". However, when we choose a specific position for our objects the layout information is added and then instead of referencing the whole model we reference each object separately, which in our case are the Greeting model elements. Indexes are then used as shown in Listing 3.2. Listing 3.2: Greetings example diagram file: using indexes < element xmi : type =" mydsl : Greeting " href =" default. mydsl 3 < element xmi : type =" mydsl : Greeting " href =" default. mydsl 4 < element xmi : type =" mydsl : Greeting " href =" default. mydsl

43 Chapter 3. State of the art 28 So if we swap lines 1 and 2 in our textual file (Figure 3.6) and save it, our diagram file will still point to the earlier specified index which now essentially is another object. This results in having the two elements switched graphically, while strictly speaking the graphical model should not have changed at all. Even though this issue can give some unwanted behavior we will accept the current situation and that our requirement of preserving layout information (at least to some extent) is met. Since this is core GMF functionality, and we explicitly avoid making changes to the source code of the chosen frameworks to avoid further complications, we will not dive deeper into the problem and how it can possibly be solved Summary and evaluation In this section we have discussed the existing integration between Xtext and GMF, which can be established when following a certain development workflow. Namely, we start off with an Xtext grammar from which we generate Xtext artifacts, and consequently generate a GMF editor that is automatically adapted such that the editors are synchronized on changes when they are saved. This directly fulfills the following integration requirements which we established in the previous chapter (Section 2.3): IR0: It should be possible to instantiate editors both graphically and textually, where applicable. We can instantiate an Xtext and GMF editor, for respectively textual and graphical editing IR1: It should be possible to switch between multiple editors (textual or graphical) that are active at the same time. We can switch between an Xtext and GMF editor. IR2: It should be possible to only show parts of a model, either textually or graphically. Showing parts of a model is only possible with GMF. IR3: It should be possible to show multiple parts of a model (textually and/or graphically) at the same time.

44 Chapter 3. State of the art 29 We can show the full model in Xtext and a graphical representation of the model in GMF at the same time. IR5: Textual (including any comments, tabs, newlines etc.) and graphical layout is saved for a model. Textual and graphical layout is saved. IR6: Changes are propagated to other editors/views. Changes between the Xtext and GMF editor are propagated when these are saved. IR7: It should be possible to edit parts of a model in separate editors. Editing parts of a model is essentially only possible with a defined GMF editor. Although this out of the box integration solves a significant portion our stated problem, it has also some drawbacks. After observing the above evaluation of integration requirements we can see that not all requirements are met. Moreover, integration requirements IR2 and IR7 are only partially satisfied since this only applies to GMF, while IR4 (Editors should provide a proper navigation structure) is not satisfied at all. Finally, a minor disadvantage of this integration is the fact that because of the GMF referencing mechanism we can possibly get unwanted behavior because elements cannot always be correctly identified. Because of its low impact on our situation, however, we will leave this referencing problem as is. 3.3 Conclusions After a short survey we have chosen Xtext and GMF as our respectively textual and graphical EMF based frameworks. Further investigation of the two showed that a basic and out-of-the-box integration exists which provides full model synchronization that can be achieved relatively easy. This gives a good basis, but does not solve our stated problem completely: we still need a solution for creating partial model editors. This is currently only possible with graphical models in GMF, but not with textual models in Xtext. In the next chapter we will see a couple of solutions on how to establish such editors.

45

46 Chapter 4 Towards partial model editors In this chapter we discuss a few possible approaches for partial model editing. For each approach we discuss the advantages, disadvantages and their applicability. 4.1 Introduction The advantage of considering only a part of the model is mainly because of modularity: we only focus on the relevant part that we want to view and/or edit. This usually results in higher productivity since we maintain a clear overview, which becomes even more apparent as the size of the model increases. Working on specific parts of a model has also the advantage of being able to apply different tools to different parts of the model. The default properties editor in Eclipse is a perfect example of such a partial model editor. In the following sections we discuss several approaches for establishing partial model editors. For Xtext we have identified the highlight range approach and the dedicated editor approach and how they can be used to achieve our goal. In this context the highlight range approach is the most promising one as it offers the most flexibility and is completely generic. In case of GMF we can simply use dedicated partial model editors which we can create by using the default functionality of GMF and GEF. Each of these approaches encompasses several integration aspects such as scoping and model synchronization that need to be considered carefully. We will discuss several approaches to deal with these issues. 31

47 Chapter 4. Towards partial model editors 32 Another group of partial model editors that are considered important are embedded partial editors where we do not necessarily have full functionality. We discuss in Section 4.4 several possible embeddings, but we have chosen to highlight mainly embedded textual editors in GMF. We furthermore discuss the limits of GMF and how the existing functionality can be extended to show and edit parts of the model contained within labels. 4.2 Partial model Xtext editors In this section we discuss two possible approaches to achieve partial Xtext editors: The highlight range approach: We apply basically a view on a full textual model and effectively restrict the editing area. Dedicated editor approach: We create a dedicated Xtext editor for each modeling element (and its children) The highlight range approach Any Xtext editor in a workbench window uses the XtextEditor class as defined in org.eclipse.xtext.ui.editor.xtexteditor. After instantiating the Xtext editor on some input file we will see the full contents of the file displayed directly in the editor. To show a part of the file we can basically use two built-in functions that allow us to apply a view within the text area of the editor. In general, we can do this as shown in Listing 4.1. Listing 4.1: Applying the highlight range functions 1 editor = page. openeditor ( editorinput, editorid ); 2 editor. showhighlightrangeonly ( t r u e ); 3 editor. sethighlightrange ( offset, numberofcharacters, t r u e ); In the first line we instantiate an Xtext editor in a new tab within the active page of the current workbench window where we assume a valid input (editorinput - corresponding to a file). We then apply the showhighlightrangeonly function that, as the name suggests, enables us to highlight a range within the current editor. To specify what range

48 Chapter 4. Towards partial model editors 33 exactly, we use the sethighlightrange function where we select the exact starting offset of the text and its length (and a third parameter which determines whether the cursor should be moved to the start of the highlighted range). This approach with an example model is depicted in Figure 4.1. (a) The Xtext editor on an example Greetings model when instantiated. (b) The Xtext editor after applying the highlight range functions. Figure 4.1: An example with applying the highlight range functions In this example we have applied the highlight range on the region of the second object in our model, corresponding to the textual representation Hello Mark!. This narrows the view so that we only see the editor containing the specified element. To determine the right offset we access the composite nodes from the parse tree created by Xtext as shown in Listing 4.2, where semanticelement is the in-memory model element. Listing 4.2: Determining the offset and length of a model element 1 ICompositeNode xtextnode = NodeModelUtils. getnode ( semanticelement ); 2 offset = xtextnode. getoffset (); 3 length = xtextnode. getlength (); Synchronization of regular changes Determining the offset and applying the highlight range on our partial model editor is the first step, but it also requires to update the document accordingly when changes are made within the partial model editor (or any other active editor for that matter). To solve this we need to setup a listener that continuously updates the offset of the model element. However, since Xtext reparses (a part of) the tree we cannot guarantee that our referenced compositional node is available after changes. So we essentially have lost important information about our node and we need to somehow identify our node again to be able to determine the offset and update the view. We can use one of the following strategies by which we can overcome this problem:

49 Chapter 4. Towards partial model editors 34 Identification by URI fragments Recall from the previous chapter how GMF references model elements from the notational model. In the same way we can use URI fragments to identify our model element. Identification by parent editor When we instantiate the partial text editor, we will do this probably from another editor that is either Xtext or GMF. 1 This parent editor can hold additional information by which we can identify which modeling element has been changed. Identification by unique model element A possible third approach is to use a unique textual identifier such as names of objects, if applicable. The identification by URI fragments approach is straightforward to apply. However, just like the GMF referencing problem it can give problems in case the order of the elements is changed. This problem occurs when elements are swapped in our textual model. So take for instance two active textual editors and assume they are active as shown in Figure 4.1. In this example the editor from Figure 4.1(b) is instantiated from the other editor. If we merely change the text Hello Mark!, the corresponding subtree will get reparsed and the Resource updated. If the modeling element is not deleted completely, the order of the element with respect to other hello modeling elements has not been changed and we can therefore use the same URI fragment to identify the corresponding modeling element. We can consequently use the index from the URI fragment and determine its offset to update the partial model editor. However, swapping lines 2 and 3 from the first editor invalidates our previously hold index since we then refer to a different model element. The identification by parent editor approach assumes that we instantiate the partial Xtext editor from another editor and that this parent editor has a separate in-memory Resource of our model. Note that the listener should be aware of the node for which the partial editor has been initialized. After changes in our partial model editor, Xtext reparses at most the entire subtree contained within that partial view and so we know for sure that only that region is affected. 2 In case of a parent Xtext editor we can 1 This is strictly not necessary, since we could also instantiate a partial model editor without having another parent editor active. However, for the sake of illustrating this approach we will assume that there does exist a parent editor. 2 The core function responsible for reparsing the dirty text region is defined in: org.eclipse.xtext.resource.xtextresource.update(..)

50 Chapter 4. Towards partial model editors 35 consider basically two approaches. The first approach is to apply the highlight range method on the parent Xtext editor, by which we only narrow the view and thereby effectively solve the problem of identification. In the second approach, we create a separate editor instance based on the same XtextResource as the parent editor and then apply the highlight range view on the corresponding modeling element. By using the same XtextResource the changes are propagated automatically between editors. However, since changes can affect the offset of the modeling element that is shown in the partial model editor, we need to determine the offset on each change which we can do by using a separate XtextResource. Since at most the entire subtree shown within the partial model editor is affected, we can use the XtextResource of the parent editor to identify the sub-tree that has been changed and thereby construct the new compositional node. By using this second approach, we can use multiple Xtext editors and synchronize changes between partial model editors (provided that they are instantiated from another parent Xtext editor). In case the parent is a GMF editor, we know that the notational element corresponding to the partial editor content is stored in a DiagramResource (as long as its corresponding node exists in the model). Our listener can access this graphical node and identify the corresponding model element by which we can determine the offset and length to update the partial model editor view. The identification by unique model element approach assumes that our meta-model defines a unique identifier such as unique element names. This is the least generic approach since in most models we do have duplicate elements which would make it unusable. Moreover, if we consider our use cases from Chapter 2 then we see that certain elements do have some unique identifier while others do not. So this would mean that the approach would indeed only work in certain cases. A remedy could be to define a unique identifier for our modeling elements. If our models are serialized as XMI files this could be an option, but in our case we have chosen to serialize our models as Xtext model files so that we are able to preserve layout information. Regardless of the choice for any of the above approaches, deleting the entire content contained in a partial model editor results in empty content. Moreover, when we delete a subtree from an editor of which the content is contained in its entirety in some other partial editor then that editor would essentially become empty since the corresponding

51 Chapter 4. Towards partial model editors 36 node does not exist anymore. In this case we can simply force the partial model editor to close Eclipse editor operations Apart from the above regular changes to our model, there are special operations in Eclipse available that need to be considered separately. For instance, the Open Declaration operation 3 opens and highlights the declaration of a selected element. So, if we, for example, use a string type for some variable and decide to open up the declaration, it will give the definition of that type, if available. After calling this operation our highlight range becomes invalid since we have now jumped to another part of our model, which results in showing the entire view again with the focus on the corresponding declaration part. To solve this we need to update our view accordingly and determine the offset and length of the corresponding model element that is selected. A better alternative would be to open a new editor to avoid any inconsistencies. Note however that this and other possible operations have not been investigated and are here covered only for the sake of completeness. However, at least the following operations have been identified that can affect our specified range, or even be limited by its use: Find references: 4 Finds the references to the selected object. From these found references, we can select an item and jump directly to its definition. Quick outline: 5 Gives a structural outline of the model in which we can select an element and jump to it. This operation does not invalidate our range, but instead only works for local elements (within the partial editor). Hence, selecting elements that lie outside the local scope will not work Renaming elements Being able to rename an element that possibly occurs at multiple places in a model is encompassed by the requirement that changes should be propagated accordingly. In case 3 Available in the right click menu. In Windows we can also use the F3 key. 4 Ctrl+Shift+G on Windows. 5 Ctrl+O on Windows.

52 Chapter 4. Towards partial model editors 37 of the example from Figure 4.1, the hello element s name is contained within the scope of the partial editor and so changing the name manually will maintain the correctness of our model (as long as the name itself is valid). However, in larger DSLs such as POOSL we can reference model elements from multiple places in our model. For example, assume that our partial model editor contains a process class Timer: 1 process c l a s s Timer ( timeouttime : Real ) 2.. We furthermore use an instance of this Timer type, defined in our system: 1 instance timer : Timer ( timeouttime := ) If we change the name of the Timer process class in our partial editor to some other nonexisting process class name, then the instance will reference an invalid process class. This means that we cannot simply change the identifiers of objects in such a partial model editor, if we want to keep the references consistent as well. Instead, renaming model elements can be performed by using the refactoring operation Rename. 6 This operation allows us to rename a specific model element in the entire model. So effectively all references are renamed and our model remains consistent. Fortunately, this renaming feature is part of the Eclipse functionality and therefore works out-of-the-box Sub-grammar restrictions The highlight range approach restricts our view on the model visually and retains all other model information to our disposal so that required functionality such as global scoping is still possible. However, with this approach we also preserve all the grammar information that can be used in our partial model editor, while this might not always be desirable. Let us take again the example from Figure 4.1. In the right editor we have instantiated the second element Hello Mark!. However, in this editor we are not restricted to only changing that part of text. In addition, we could add another Hello element in the partial model editor directly after the initial Hello Mark! statement. From a conceptual point of view a partial model editor that operates on a part of a model should also, strictly 6 Available in the right click menu. In Windows we can also use the shortcut key combination Alt+Shift+R.

53 Chapter 4. Towards partial model editors 38 speaking, be restricted to the sub-grammar that corresponds to the part being edited. In our example with the additional inserted statement we would be outside our partial model grammar. To solve this issue we can use the PartialParser function that is defined in Xtext. 7 Moreover, this function is used by Xtext internally as a partial parsing strategy to only update the minimal region of the model, based on the specific location of the performed changes. The following snippet of code essentially captures its use (Listing 4.3): Listing 4.3: PartialParser example 1 ParserRule parserrule = ( ParserRule ) node. getgrammarelement (); 2 partialparser = PartialParser. c l a s s. newinstance (); 3 partialparser. assignrootrule ( xtextresource, parserrule ); 4 Reader reader = new StringReader ( node. gettext ()); 5 IParseResult partialparseresult = partialparser. parse ( parserrule, reader ); It first needs an assignment of a so called root grammar rule by which the text will be parsed. In our case this is the rule corresponding to the modeling element contained in the partial model editor. For each model element we can get its corresponding grammar rule, assign this rule and parse some piece of text (which makes this approach completely generic). After the region has been parsed we can use the parse result and in case of errors attach an error marker to our editor. If necessary, we can use this approach to restrict our partial model editor to the corresponding sub-grammar and inform the user if he uses concepts that lie outside this sub-grammar. Note that we add this as an additional check on top of the existing check(s) of the model. Since this sub-grammar check is a subset of the total grammar check, we know implicitly that the total grammar check will always pass if the sub-grammar check passes (assuming no other changes have been) Evaluation of advantages and disadvantages The advantages of the highlight range approach are clear: 7 org.eclipse.xtext.ui.codetemplates.ui.projectedediting.partialparser.

54 Chapter 4. Towards partial model editors 39 Single Xtext editor Instantiating partial model editors on the same model does not require dedicated Xtext editors to be created. So we can just use the existing editor and apply the highlight range. Furthermore, it is also completely generic since we can instantiate such a partial model on any defined model element. Global scoping We have a global scope out of the box since the model is actually read in its entirety and we only apply a view on the model. Straightforward The approach is relatively easy to implement and does not require much code. The drawback of this approach is that certain operations such as finding the declaration of a model element probably each need to be considered separately. Another disadvantage is that we show entire lines of text that cover the range of our modeling element. This gives problems when (parts of) other elements are also contained on the same line. This is illsturated in Figure 4.2 (based on the Statemachine example defined by the Xtext grammer from Appendix A.2). The instantiated partial model editor shows the textual representation of the expression corresponding to the transition from which the editor is instantiated. However, we do not only see the expression but the entire transition definition that contains this expression since they are located on the same line within the file. Figure 4.2: Highlight range showing entire line where the offset range is located, which in this case is To solve the latter problem we can enforce a suitable structure by changing our Xtext grammar. Another approach is to add new lines before and after the textual representation of our element (in this case before and after the expression ), by which

55 Chapter 4. Towards partial model editors 40 we isolate the textual part we want to see. The latter approach is more generic than the former, but it suffers from the fact that when these new lines are added, the editor is marked as being in a dirty state, which should actually not be the case Dedicated partial model Xtext editors In the previous approach we have seen that by applying the highlight range approach we can achieve partial model editing. Another possible approach is to create dedicated Xtext editors for each modeling element that we want to edit separately. For instance, if we take the Statemachine example (Appendix A.2) we would generate one editor for the entire model, and then possibly one editor for editing states, one for transitions and one for expressions. There are however multiple drawbacks of this approach: Not generic For each element we need to define and generate a separate editor. In case of multiple layers of navigation, we would also need to integrate each such layer separately. No global scope There is no global scope by default. Referencing elements residing outside the partial model will therefore not be possible. This also has consequences for the validation in case global scope is required. Requires a custom model-linking strategy Since a dedicated Xtext editor needs a physical file as input, we would also need to think about how we store these sub-models, but also how we identify them. This separation of a model into sub-models stored in separate files means that the model will get fragmented, which might not always be desirable. Although this approach seems less useful than the highlight range approach (or even completely unusable), it turns out that there exist some architectures where this is still applicable. We will discuss this in the next chapter.

56 Chapter 4. Towards partial model editors GMF partial editors For graphical representations of parts of a model we can simply create dedicated GMF editors for all the modeling elements that we want to display, which essentially can be considered as partial model editors. Since we have to define a GMF editor for each different part of a model, this is obviously less generic in comparison with for example the Xtext highlight range approach. However, because the number of dedicated graphical editors is usually limited to a manageable amount, this lack of genericity for GMF editors is not considered a key issue. Moreover, even with complex models it would often suffice to have a few such dedicated graphical editors for a model, each representing a separate layer of a model. We will see in Chapter 6 that even for a mature DSL such as POOSL, it suffices to have at most a few GMF editors to capture the core concepts since most of the information is compacted in a textual form. In more customized scenarios each layer would also have its own graphical syntax of the elements available at that level, and hence requires a custom GMF editor. In addition, we can also have multiple graphical representations of the same model element (and its children), while again in contrast with Xtext you are confined to the single textual representation. 4.4 Embedded partial editors In the previous sections we have discussed how we can create partial model editors in Xtext and GMF. They are used as instances to show either a purely textual or graphical representation of a part of our model. However, we can also think about editors that combine both into one single editor. We will call these editors integrated within another editor embedded partial editors Possible combinations of embedded editors Aside from the kinds of embedded editors itself, it is important to also think about the host editor, that is, the editor in which the embedded editor will reside. If we only consider textual and graphical combinations of editors, we get the following possibilities:

57 Chapter 4. Towards partial model editors Textual host editor; textual embedded editor. 2. Textual host editor; graphical embedded editor. 3. Graphical host editor; textual embedded editor. 4. Graphical host editor; graphical embedded editor. Embedding textual editors in other textual editors might seem a bit unusual, but the Meta Programming System (MPS), for example, does embed textual representations of a model within a textual model. 8 We will discuss more about MPS in Chapter 7. Since our focus is primarily on Xtext and GMF, we can consider Xtext as our host editor. However, in Xtext there is (currently) no easy way to embed other editors (either textual or graphical) and therefore it has been omitted. In GMF, on the other hand, besides purely graphical elements we have (by default) also pieces of textual information embedded such as for example the name of some object which we can edit directly (see Figure 4.3). We will discuss this in more detail in Section Figure 4.3: Editing a label in GMF Embedding dedicated graphical editors in GMF has also been omitted because of its complex nature. Instead, we can use the so called GMF compartments. This is illustrated in Figure 4.4. For more information on how to achieve this see the GMF documentation online. 9 The last option, embedding textual editors within a host GMF editor, is considered to be the most relevant combination. We will discuss this in more detail in the next sections Viewing and editing textual partial models as labels The instantiated embedded editor from Figure 4.3 is a so called cell editor, which is implemented by the DirectEditManager class and provided by GEF. 10 This mixing of 8 Note that these editors, which are also called projectional editors, do not require a grammar or parser since they use the so called language composition mechanism [27] package org.eclipse.gef.tools

58 Chapter 4. Towards partial model editors 43 Figure 4.4: An example use of GMF compartments textual and graphical representations in GMF, however, is by default very limited. The first thing to note is that the generated GMF code confines us to simple labels. From a meta-model point of view, these are specifically attribute types such as EString. This is a major limitation since there exist cases where we would like to represent more than simply a name. Let us illustrate this with an example. Take for instance a simple state machine as described by the Xtext grammar in Appendix A.2. It consists of states and transitions between states. We represent states as circular objects and the transitions as links between states. A basic GMF editor with only labels and transitions can be created in a straightforward manner (assuming that an Xtext editor is already available). The result is illustrated in Figure 4.5. Figure 4.5: Editing a label in GMF A transition contains furthermore a simple expression that we want to show as labels on these transitions. The problem is that the defined expression is not an attribute but a subtree within our abstract model. We could solve this by altering our meta-model and define these expressions as attributes of our transition of the type EString. During the creation of the editor we would be able to select this attribute and display it as a label.

59 Chapter 4. Towards partial model editors 44 Although it solves our problem it has two major disadvantages. The first is that we need to change our meta-model in order to do this, which as we discussed in earlier chapters should ideally be avoided to maintain meta-model dependence. Another problem also directly related to the meta-model is that we now loose syntax checks and scoping on our expressions. As a result we could use any value and therefore input invalid expressions. We could restrict this by defining separate syntax check, but this might not be desirable. We can think of a restriction where the meta-model cannot be changed or simply the need to perform other operations where the structure of this part is required. So we want to keep our meta-model as is and display subtrees of our model as labels within GMF. To solve this we proceed as follows. We first need to locate the relevant EditPart. In our case this is the editpart TransitionEditPart.java which corresponds to our transition modeling element. We want to add a label and as its value the textual expression of the expression model element containing it. Within the TransitionFigure class we add the following private variable that will contain the label of our transition: 1 p r i v a t e WrappingLabel ffiguretransitionnamefigure ; We furthermore adapt the getfiguretransitionnamefigure function as follows: 1 p u b l i c WrappingLabel getfiguretransitionnamefigure () { 2 ffiguretransitionnamefigure = new WrappingLabel (); 3 TransitionEditPart editpart = geteditpart (); 4 EObject semanticelement = editpart. resolvesemanticelement (); 5 EObject subsemanticelement = semanticelement. econtents (). get (0) ; 6 ICompositeNode xtextnode = NodeModelUtils. getnode ( subsemanticelement ); 7 String s = xtextnode. gettext (); 8 ffiguretransitionnamefigure. settext ( xtextnode. gettext ()); 9 t h i s. add ( ffiguretransitionnamefigure ); 10 r e t u r n ffiguretransitionnamefigure ; 11 } In this function we essentially resolve the semantic element and get the textual representation of the expression (in our model a child of the transition). The result of this change is shown in Figure 4.6. Hence, we can now display subtrees as values in labels. To enable editing of these values we need to make sure that the editpart responsible for instantiating the DirectEditManager

60 Chapter 4. Towards partial model editors 45 Figure 4.6: Editing a label in GMF is also created by GMF. We can do this by customizing our mapping and generator models, or manually creating a class for handling these cases Viewing and editing labels with syntax highlighting When we apply the previous approach of inserting a textual representation of a subtree of our model as a label in GMF, it is possible that such a value contains keywords that are usually marked with a certain color in Xtext. The default cell editor poses a limitation in this context since there is no syntax highlighting present. To make this possible it would be necessary to extend the default cell editor class in such a way that it includes the necessary parser functionality from the generated Xtext editor. Such an extended class has already been developed as part of the Yakindu Statechart Tools (YST) [28] (the tool itself is described in more detail in Chapter 7), which is based on Eclipse. Since YST is based on Eclipse and made open source, it is possible to download and use the source code in order to create our custom cell editor. 11 To accomplish this we need to create a custom Xtext editor for editing state names and adapt the EditPart corresponding to the label we want to edit where we replace the default cell editor with the custom wrapper provided by the YST plugins (see Appendix C.3 for a detailed description of the necessary steps). The major drawback is its lack of genericity since we have to define such an Xtext editor for each type of label where we want to use this. Another drawback is the dependence on the plug-ins as provided by the YST developers since it gives no guarantees on how the project and the tool itself will evolve. For example, the plug-ins might get incompatible with the newest versions of Eclipse or any of the used frameworks, but the project might also even be discontinued. Aside from the syntax highlighting within the cell editor itself, we could also think about syntax highlighting when the labels are printed in a GMF editor. However, this 11

61 Chapter 4. Towards partial model editors 46 was considered to be outside the scope of this research and was therefore not investigated in further detail. 4.5 Evaluation We have discussed how to create partial model textual and graphical editors. In case of GMF, we can use its existing functionality and simply create dedicated editors for a part of a model. In case of Xtext, on the other hand, we offered two options: either also create dedicated editors, or otherwise, apply the highlight range approach. We argued that dedicated Xtext editors for parts of a model are less favorable mainly because of their lack of genericity, but also because it implies that we loose global scope and that the model might get fragmented. The highlight range approach, on the other hand, is completely generic since we basically only narrow the view to the modeling element in question. Besides the minor issues with showing content per line and special operations, we need to take care of synchronization by updating our highlight range, for which several approaches have been proposed. The suggested approaches for partial textual editors satisfy our previously partially fulfilled requirements IR2 and IR7 where we state that it should be possible to show and edit parts of a model at the same time, either textually or graphically. Integration IR4 (providing a proper navigation structure) is partially fulfilled since we can use the highlight range approach to cover the text-to-text navigational structure. 4.6 Conclusion In this chapter the partial model editors are discussed mainly in isolation in the context of the partial model editing problem. We have briefly touched the notion of a host editor from which the partial model editors could be instantiated in the highlight range approach. Although these approaches can be used to build partial model editors for single editor use, we are much more interested in more mature scenarios where we look at the entire architecture and how all these editors are interconnected. In the next chapter we will discuss these architectural patterns and the way we can navigate through these different editors.

62 Chapter 5 Architectural patterns In the previous chapter we have seen how we can create partial model editors for textual and graphical editors. When these approaches are combined in more mature scenarios we can identify certain patterns that significantly can affect their applicability. In this chapter we discuss the key aspects of navigation between these editors, their interlinking structure and the overall synchronization. 5.1 Introduction We discussed in Chapter 3 existing integrations where Xtext and GMF are interlinked by default. In this setting synchronization is performed after changes have been saved while using a single textual file for storing our domain model. However, when integrating multiple editors we do not necessarily have to follow this approach. We argued that there is a need to use partial model editors instead of editors that consider a full model, which particularly applies to textual based editors. When using multiple editors we need to think of how these will be interlinked in case we want to instantiate an editor from another. A key issue in this setting is to create a proper synchronization between these interlinked (partial) model editors. This problem can be summarized by the following questions: 1. How do we interlink multiple editors, with respect to each other so that we can enable a consistent navigational structure? 47

63 Chapter 5. Architectural patterns How do we synchronize these interlinked editors and keep the model(s) consistent? First we approach the problem of interlinking editors from the perspective of inter-editor navigation (Section 5.2). Moreover, we present the possible navigational structures, what their characteristics are and discuss briefly how such a navigation can be applied. Next, we discuss a few possible multi-editor architectures (Section 5.3), where we base our solutions and discussions on the chosen tools Xtext and GMF, while also keeping in mind their respective restrictions. We also discuss this in relation to the methods for using partial model editors from the previous chapter, where we show their applicability in different scenarios, and their advantages and disadvantages. 5.2 Navigational structures In this section we discuss the inter-editor navigation between textual and graphical representations, which we will base on Xtext and GMF. More precisely, we discuss how other editors can be instantiated, using the same, or a different representation. Other possibilities are navigations from structured views such as the outline and other views, but this is considered outside the scope of this project and will therefore be omitted. The Xtext-to-Xtext navigation structure encompasses instantiations of textual editors from other textual editors. We confine ourselves to partial model editors using the highlight range method, as this is considered the most relevant in this case. In the previous chapter we have briefly discussed the special operations in Eclipse and how we can for instance use the Open declaration operation to jump to the definition of the selected object. This is a perfect example since it shows the navigational aspect that we want to acquire in a text-to-text scenario. In this case we assume that we navigate within an Xtext editor where the highlight range method has already been applied, showing only the textual representation of one modeling element (and its children). This is illustrated in Figure 5.1. We have already discussed (in the previous chapter) that this gives problems since the range becomes invalid. To solve this we provide the approach of determining the offset of the corresponding declaration part. By using a custom listener we can monitor for these changes.

64 Chapter 5. Architectural patterns 49 Textual Model Partial-model editor Partial-model editor Open declaration Figure 5.1: Applying the highlight-range method on a different element when using the Open-declaration functionality. The bottom partial-model editor represents the source editor where an element type is used, defined earlier in our textual model. The upper partial-model editor shows the definition of the used type. In case of cross-document references the principle remains the same, except that we probably need to instantiate a new editor or use the same instance with a newly constructed editor input. As mentioned earlier, this is considered to be outside the scope and is therefore left for further work. Navigating from an Xtext editor to a GMF editor is another navigational structure to consider. Recall from the previous chapter that for graphical partial model editors we use the approach of generating dedicated GMF editors for each modeling element (and its possible subcomponents) that we want to display graphically. This GMF instantiation is typically useful when we want to show a graphical representation of the current textual representation that is shown. We can establish this structure by for example defining an action which can be called from the context menu in Eclipse. 1 We furthermore need to define a custom handler that will be called when executing this action from the menu. Navigation from GMF to Xtext is conceptually the same as the Xtext-to-GMF case: we instantiate a dedicated editor using a different kind of representation. However, we will see in Section 5.3 that this navigation structure touches multiple integration aspects on a deeper level. 1 The context menu can be used by right clicking on an element.

65 Chapter 5. Architectural patterns 50 In the last case we have the GMF to GMF navigation. Just as with the Xtext-to-GMF combination we again use dedicated GMF editors as our target. 2 To achieve this we can use the built-in GMF functionality Open Diagram Behavior that allows us to easily integrate two or more GMF editors (based on the same model), which greatly simplifies the overall integration complexity. This key functionality is defined in the generator model. We define this action for the source editor, where we we will point to our target editor by using a so called EDITOR ID. A detailed example that shows how this is done exactly is discussed in Section Multi-editor architectures Recall from Chapter 3 that we discussed the existing integration with Xtext and GMF. We can conceptualize the overal architecture as shown in Figure 5.2. The figure describes a typical scenario where we define a high-level GMF editor and an Xtext editor for the full model. Xtext GMF load/save.diagram synchronization on save Figure 5.2: Conceptual architecture for the default Xtext-GMF integration In this figure, and in what follows, we will use the notation as used in this figure. The blue box indicates the coverage of the Xtext definition, while the red box indicates the 2 Note that the target GMF editor will typically be a sub-diagram element, but this does not necessarily need to be the case. We can also think about showing a different visualization of the same graphical elements from which we instantiate the target editor. 3 Obviously, this feature is very important for every developer that wants to integrate these editors. Very surprisingly, during this research there was no official documentation found that describes this important functionality.

66 Chapter 5. Architectural patterns 51 coverage of the GMF editor. In this specific case, since the Xtext coverage is over our entire model, we assume that the Xtext grammar for the entire model is available. We define this coverage in terms of the meta-model elements that the editor can write/read, here illustrated as a tree corresponding to some model. When arrows are used that connect these boxes, we treat them as editors that are showing the covered part of the model. Furthermore, The.diagram and.xtext are files for storing the graphical layout information and the textual model, respectively. We identify the model elements by using URI fragments, and synchronize on saving. Synchronizing on file changes has the drawback that we are only able to make changes within one editor at a time. Moreover, changing the model in two editors and then saving the model from one editor will result in loosing the unsaved changes made in the other editor, which obviously is not an ideal situation. We will see from the related work in Chapter 7 there exist other approaches that can be applied to achieve for example a real-time synchronization. In the above approach we have defined an Xtext editor with a textual concrete syntax for the full model, which enables us to generically instantiate a partial editor on any part of our textual model. This represents the default behavior of Xtext and GMF, but does not necessarily have to apply in all the cases. Moreover, sometimes we do not have a textual definition for the entire model, but only for some of the modeling elements within our model, which we want to combine together. One such example architecture is depicted in Figure 5.3. In this case, the GMF-editor is defined as a full model diagram, while the Xtext editor is limited to only a part of the model. Note that the dashed line within the Xtext coverage indicates that the subtree on the left and the right are of the same type on which the same Xtext editor can be instantiated. The orange dashed arrow indicated that we follow the GMF-to-Xtext navigational structure. It is important to keep in mind that here we always take the GMF editor as a basis for instantiating Xtext editors. This scenario turns out to be very problematic for several reasons. If we need to keep the textual sub-models which are instantiated within Xtext, the textual representation of the left and right sub-tree needs to be stored. The most straightforward way is to do so in separate files. However, this approach is only directly applicable in very specific scenarios. Moreover, by decoupling the Xtext editor and its textual model, we also loose

67 Chapter 5. Architectural patterns 52 GMF Xtext instantiate Xtext editor from GMF Xtext load/save.diagram load/save.xmi load/save load/save.xtext.xtext Figure 5.3: GMF diagram defined for the full model, and the Xtext editor defined for a sub-tree. The left and right sub-tree can be opened by the same Xtext editor. From the graphical editor we can instantiate an Xtext editor that covers that part of the model. the global scope. So when for example we want to rename an element in such an Xtext editor instance, we are bound to the scope that is provided by the coverage of that Xtext editor, which in this case is only the sub-tree. If we choose to store the textual sub-models, during the first instantiation we need an initial textual representation of the model that is being instantiated (including its children). We can achieve this by using the serialize function of Xtext. Another approach, which is also applicable in very specific situations, is to choose not to store this textual model permanently, but to only use temporarily files for the lifetime of the instantiated partial model Xtext editor. The obvious drawback of this approach is that layout information will not be be preserved, but as mentioned earlier, this might not be an issue in certain scenarios and can therefore sometimes still be applicable. The architecture as illustrated in Figure 5.4 encompasses the Xtext-to-GMF navigational structure, where the Xtext editor is defined for the full model, while the GMF editor is limited to a sub-tree. Each GMF editor should use a separate diagram file for storing graphical layout information and pointing to the diagram root element which is located in the textual model.

68 Chapter 5. Architectural patterns 53 Xtext GMF instantiate GMF editor from Xtext GMF load/save load/save Figure 5.4: Multi-editor architecture using a full model Xtext editor and a subdiagram GMF editor The multi-editor architecture presented as depicted in Figure 5.5, uses one full-model Xtext editor and two separate GMF editors, defined for different parts of the model. Following the steps we first (1) open a sub-diagram from a higher-level GMF editor by using the Open Diagram functionality (GMF-to-GMF navigation) and then (2) open an Xtext editor from the sub-diagram editor (GMF-to-Xtext navigation). Xtext GMF load/save.xtext instantiate Xtext editor from sub-diagram 2 Xtext 1 instantiate sub-diagram load/save GMF GMF GMF GMF Figure 5.5: Multi-editor architecture using one Xtext editor for full model and two different GMF editors, where we can instantiate sub-diagrams. Since we have created a full model Xtext editor, instantiating this editor requires that the highlight range method is called with the proper begin and end offsets that need to be computed to limit the view. Note that in contrast to the previous architecture (Figure 5.4) where we use one GMF editor for two subtrees and thereby need to use two

69 Chapter 5. Architectural patterns 54 diagram files for our graphical notational model, in this case we use two GMF editors and just one diagram file (Figure 5.5). The reason for having one diagram file in the latter case is because of the coverage of the top-level node by a GMF diagram, by which we make a containment of model elements in subtrees possible (in terms of XMI). This can be equally stated as the top-level node being able to reach all the other nodes covered by the used editors. 5.4 Conclusions In Section 5.2 we discussed how to practically achieve navigational structures when interlinking different editors. These proposed approaches enable us to achieve the last unfulfilled integration requirement (Section 2.3): The editors should provide a proper navigation structure (IR4). We also looked in Section 5.3 at various multi-editor architectures where we showed that it is important to think about how we combine different Xtext and GMF editors. Based on the observations that were made it is recommended to always have a full model Xtext coverage (if possible), to ensure genericity and to avoid additional synchronization problems.

70 Chapter 6 Implementation In the previous chapters we have established solutions to our stated problem, where we have also discussed multiple practical approaches. We will confirm these findings in this chapter with a couple of implementations. 6.1 Introduction In the next sections we discuss what are considered the most representative use cases, covering various aspects of the previously obtained results. Each scenario has certain characteristics which can require custom adaptations, which are discussed in more detail if necessary. The outline of the chapter is as follows. We start off with a very basic language Greetings in Section 6.2 where we introduce the highlight range approach. In Section 6.3 we use a custom made state machines language as a more elaborate example where we again apply the highlight range method. In addition, we also illustrate how we can show subtrees as labels in GMF, which is also considered a form of integration but currently not available by default in GMF. In Section 6.4 we present a web application example where we illustrate how to instantiate sub-diagrams in GMF. A basic proof-of-concept implementation of the POOSL language is provided in Section 6.5 that encompasses all of the previously demonstrated elements where we show that the proposed solutions can also be applied to a mature language. 55

71 Chapter 6. Implementation Greetings To illustrate the most basic integration we will consider the default Greetings example in Xtext. 1 In this example we want to open an Xtext editor by clicking on an in-diagram element that shows us the corresponding textual representation. The Xtext grammar is given in Appendix A Generating implementation code We generate the Xtext artifacts and generate the code with the genmodel file. We then create the necessary GMF files and generate the GMF editor with Model as our diagram element and Greeting as our domain model element. We now have the following projects: org.xtext.example.mydsl org.xtext.example.mydsl.diagram org.xtext.example.mydsl.edit org.xtext.example.mydsl.editor org.xtext.example.mydsl.ui Customization We create a custom package in the src folder of org.xtext.example.mydsl.diagram/src with the name org.xtext.example.mydsl.mydsl.diagram.custom and put here the following files: Activator.java (Appendix B.1) EditPolicyProvider.java (Appendix B.2) OpenEditPolicy.java (Appendix B.3) 1 Section: 1.1. Creating A New Xtext Project.

72 Chapter 6. Implementation 57 Finally, we add the extension point as defined in Appendix B.5 to plugin.xml of the diagram plugin Result With a sample file as shown in Figure 6.1 we can now click on Mark, for example, and get its corresponding textual representation as shown in Figure 6.2. Figure 6.1: Greetings example: the full textual model Figure 6.2: Greetings example: a partial textual model element 6.3 State machines In this example we will demonstrate integrations for a custom made and simple state machines language (see Appendix A.2 for the Xtext grammar). A state machine consists of states and transitions between states. Each transition contains a simple expression that is evaluated when a transition from one to another state is taken. In this case we want to be able to click on transitions and show the textual representation of the text. We also want to show the expressions as labels in GMF Generating implementation code For our GMF editor we choose Statemachine as our diagram element, State as our modeling object and Transition as a connection.

73 Chapter 6. Implementation Customization After generating the implementation code we add the same files to our custom package as described in Section and adapt the following: Activator.java: adapt the value for PLUGIN ID to match the Plug-in ID. OpenEditPolicy.java: on line 25 adapt the Plug-in ID to match our Xtext editor. To show the expression as a label within the diagram we need to adapt the generated file TransitionEditPart.java. We add the following public function to the main class 1 p u b l i c TransitionEditPart geteditpart () { 2 r e t u r n t h i s ; 3 } In the TransitionFigure class we add the private variable 1 p r i v a t e WrappingLabel ffiguretransitionnamefigure ; and adapt the following getfiguretransitionnamefigure function as follows: 1 p u b l i c WrappingLabel getfiguretransitionnamefigure () { 2 ffiguretransitionnamefigure = new WrappingLabel (); 3 4 TransitionEditPart editpart = geteditpart (); 5 EObject semanticelement = editpart. resolvesemanticelement (); 6 EObject subsemanticelement = semanticelement. econtents (). get (0) ; 7 ICompositeNode xtextnode = NodeModelUtils. getnode ( subsemanticelement ) ; 8 String s = xtextnode. gettext (); 9 ffiguretransitionnamefigure. settext ( xtextnode. gettext ()); t h i s. add ( ffiguretransitionnamefigure ); 12 r e t u r n ffiguretransitionnamefigure ; 13 } Essentially, the above code gets the model element (in this case the expression of the transition), reads the textual representation and sets the value of the label.

74 Chapter 6. Implementation Result In Listing 6.1 an example model is given. 1 s t a t e s 2 s t a t e a; 3 s t a t e b; 4 s t a t e c; 5 s t a t e d; 6 s t a t e e; 7 end 8 t r a n s i t i o n s 9 a => c e x p r e s s i o n ; 10 a => d e x p r e s s i o n 2+3; 11 b => e e x p r e s s i o n ; 12 d => c e x p r e s s i o n 1+1+1; 13 end Listing 6.1: Statemachines: example file The corresponding graphical model is shown in Figure 6.3. We can now click on transitions or states and show their corresponding textual representation. We also see that expressions are shown as labels. Figure 6.3: Statemachines example diagram 6.4 Web application In this web application example we will demonstrate subdiagram instantiations with GMF. Our web application meta-model consists of data tables which in turn contain data columns. The meta-model is depicted in Figure Note that this is a custom DSL, which is made only to show how we can hierarchically navigate through a model.

75 Chapter 6. Implementation 60 Figure 6.4: Web application example: meta-model definition The idea is to have a top-level diagram showing us data tables that are contained in the web application. When double clicking on any of those data tables we want to show all the data columns it contains in a separate window Generating implementation code and customization We need to create two GMF editors: one for modeling element DataTable (WebApplication as the diagram element) and another for modeling element DataColumn (DataTable as the diagram element). After having two generator models, each for one editor, we need to link them. We do this by following the steps as described in Appendix C Result We take the following model as an example. Data table a containing data column X and data table b containing data columns Y and Z. The result after opening the web application and its tables is shown in Figure 6.5. On the left panel we have two files: default.core contains the model and default.core diagram contains the diagram. We can instantiate the latter and get the top right panel where we get the two data

76 Chapter 6. Implementation 61 tables. Double clicking on any of these data table produces the corresponding tabs at the bottom. Figure 6.5: Web application example: instantiated subdiagrams 6.5 POOSL Generating implementation code In this section we demonstrate the implementation of the POOSL language. We use an existing definition for the Xtext grammar to generate the Xtext implementation code and a meta-model. Because of lack of time we show only a partial implementation for the graphical editor. We use basically the same approach as shown in examples from the previous sections. We have used the POOSL definition and the use cases from Chapter 2 as a basis (the high-level meta-model is given in Appendix A.4). editor we take system as our root diagram element. For generating a high-level GMF Result The result of the high-level view is shown in Figure 6.6. The instance physicallayer is a cluster process which contains two process instances. element we open up a separate GMF editor (Figure 6.7). By double clicking on the

77 Chapter 6. Implementation 62 Figure 6.6: POOSL example: GMF editor for the system element, showing its highlevel instances Figure 6.7: POOSL example: Opening up a GMF sub-diagram from a cluster class element For each instance we can show its instance parameters (Figure 6.8) and its process class definition (Figure 6.9). In case of a process class we show an Xtext editor. In case of a cluster class we can either show an Xtext or GMF editor by using the right-click menu. To show the definition of system in an Xtext editor we right click on the background and instantiate the Xtext editor (Figure 6.10). 3 3 This works since the background is effectively a diagram element corresponding to our system.

78 Chapter 6. Implementation 63 Figure 6.8: POOSL example: Showing instance parameters in Xtext Figure 6.9: POOSL example: Showing a cluster class definition in Xtext Figure 6.10: POOSL example: Showing system and its instances 6.6 Evaluation In the previous sections we have shown implementations of a few languages covering different aspects of our proposed solutions. The main conclusion of these implementations is that the solutions of applying partial model editors can be relatively easily applied, which was exactly one of the main goals of this thesis. However, it must be noted that the synchronization between these editors turned out to be problematic which was partly related to practical implementation issues, but partly also to the fact that the problem in general is far from trivial to solve. The problem manifested itself mainly when multiple partial model Xtext editors were used, instantiated by using the highlight range approach. We therefore restricted ourselves to one active (partial model) Xtext editor

79 Chapter 6. Implementation 64 which could be synchronized with one or multiple active GMF editors, while working on one file and synchronizing on file save. The used languages have a few interesting points worth mentioning. The custom made state machine language is a good example where we show that besides showing a partial model Xtext editor, we can also take a sidestep and integrate additional parts into our GMF editor. In this case we showed that we can take a textual representation of a subtree from our model and display it as a label, which is not possible to achieve by using the default functionality of GMF. Although it is a small customization it illustrates that besides the main paths followed in this thesis there are more points of integration possible. One could think of other examples such as pretty printing of these labels and custom embedded editors. The web application example shows that in case of sub-diagrams we can relatively easy achieve the desired GMF-to-GMF navigational case, where we simply used the existing functionality of GMF. The implementation of the POOSL language shows that we can combine sub-diagrams together with instantiating partial model Xtext editors into one whole, which works satisfactory.

80 Chapter 7 Related work In this chapter we discuss related work in terms of related technologies where certain textual and/or graphical integrations have been implemented, and related research regarding this problem. 7.1 Related technologies In Chapter 3 we discussed the tools that are directly related to our stated problem, and whether and how they can be used. In this section we will discuss a few interesting tools where certain textual and graphical integrations already have been implemented, or that seemed promising for further investigation Sirius Sirius is a framework that provides multi-view workbenches through graphical, table or tree modeling editors [29]. It is developed by the company Thales and until recently was only used internally. Sirius uses EMF for models and GMF for the graphical modeling. According to the authors there is also support for Xtext which enables concurrent use of table and textual editors. 1 Sirius is tightly integrated with the Eclipse IDE and, according to the authors, provides direct synchronization between different editors

81 Chapter 7. Related work 66 The ideas in general are promising but until recently there was no publicly available source code, and therefore the project was not investigated in further detail. Furthermore, it is not clear whether the integration and synchronization is possible on partial models. If an integration with Xtext does not limit the Xtext editor, then we will probably be able to apply the highlight range approach. Sirius currently does have stable release which can be installed via the Eclipse Marketplace. 2 It is planned as part of the next Eclipse distribution: Eclipse Luna Meta Programming System (MPS) MPS is a DSL development environment where users can design own extensible DSLs [30], developed by the company JetBrains. A language is defined by an abstract syntax definition and an editor that supports the concrete syntax via a cell based editing style [31]. The concrete syntax does not have to be stored because it is part of of the language definition and hence known by the constructed language engine [32]. Unlike Xtext, TEF, TCS or EMFText, which are parsing based approaches, MPS distinguishes itself mainly by applying so called projectional editors. Text is projected from the AST and changes are essentially affecting the AST directly. This means that text does not need to be parsed, which effectively avoids a lot of problems that other parser-based strategies have to deal with. An example is depicted in Figure 7.1. In terms of partial models, these projections can be considered as separate partial model editors, defined within one bigger workspace. This approach seems the ideal since we can bind in the same way other and multiple editors on the same AST, avoiding problems like the earlier discussed GMF model referencing by URI fragments. The major drawback of MPS, however, is its non-trivial learning curve because of its contrastive approach which requires a significant investment in terms of time Yakindu Statechart Tools Yakindu Statechart Tools (YST) is a set of Eclipse plug-ins, based on on EMF, GEF, and GMF [33], which provide an integrated modeling environment for the specification and development of reactive, event-driven systems based on the concept of statecharts [28]. 2

82 Chapter 7. Related work 67 Figure 7.1: Projectional editors in MPS where effectively textual editors are embedded in other textual parts A custom cell editor and other relevant functionality has been developed as a separate plugin that is used by YST to edit parts of a model textually and with syntax highlighting. An example integration is shown in Figure 7.2 based on a simple state transition system (Appendix C.3 describes the exact steps to implement this). Figure 7.2: Yakindu wrapper example integrated with a state transition system We discussed already in Chapter 4 that the major drawback of this approach is its lack of genericity since we have to define such an Xtext editor for each type of label where we want to use this. When editing labels, however, this extended cell editor only operates on plain text which is defined as a String within our meta-model. This is not desirable since we want to edit parts of our model which are not defined as a String, but rather are complete subtrees of our AST. Another drawback to note is that the user depends on the plugins as these are provided by the YST developers. This might not be desirable in all

83 Chapter 7. Related work 68 cases since such third-party plug-ins can diverge in functionality and even get unusable in future versions of Eclipse or other related and used frameworks BPEL Designer The Eclipse BPEL Designer is a development tool for WS-BPEL 2.0 processes, based on the Eclipse frameworks GEF and EMF. 3 Bettini et al. presented an integration approach with Xtext in [34] where the goal was to create a custom editor for specific expression languages when editing the properties of a BPEL process. Bettini points out that the main problem with this integration was that the expressions which were supposed to be edited in such an Xtext editor were stored as a BPEL process file, which is defined in a custom format that and therefore not readable by an Xtext editor defined with the corresponding grammar for expressions. Moreover, Xtext requires an EditorInput based on a physical file, so it was not possible to isolate the expression and instantiate the Xtext editor with it. To solve this Bettini proposed to create temporary (and hidden) files for these expressions upon instantiation. These files would be given as input to Xtext, thereby satisfying the requirement of an EditorInput with a physical file. 4 An example of the resulting integration is shown in Figure Related research Research on integrating textual and graphical editors in Eclipse has been carried out in different areas, depending on the specific needs of the author. As discussed in the previous section, Bettini investigated integrating Xtext for a part of a BPEL process model and used temporary files to solve the need of Xtext to operate on physical files [34]. This integration is bound to the properties view (see also Figure 7.3) and therefore only applies to one model element at a time, that contains that specific expression. However, this work seems to be only published as an extended abstract and is therefore very limited, in the sense that it provides no further details on the exact approach that has

84 Chapter 7. Related work 69 Figure 7.3: Xtext integration in BPEL Designer been carried out. It would be for example interesting to see how synchronization between these editors has been accomplished. Scheidgen investigated a similar problem in more detail where he focused on embedding textual editors into graphical editors [35]. Since this research has much resemblance with the work presented in this thesis, it is worth mention it in more detail. The approach of this research is as follows. Upon request, instantiate an embedded editor from a graphical element, and give an initial textual representation of the partial model. This embedded editor operates on a copy of the subtree corresponding to the model element that is used. The user is allowed to change this textual model, which is parsed in the background during changes. During these changes the AST of the host editor is not affected, until the user decides to commit the changes and closes the embedded editor. When changes are committed, the old subtree is replaced with the new one. This is illustrated in Figure 7.4. Scheidgen correctly identifies multiple problems and proposes several solutions to approach them. One problem the author discusses is that of preserving layout information, and more specifically, preserving whitespace. Scheidgen proposes two solutions: either store whitespace within the model, or create this automatically. The main issue with both solutions is that it does not seem to work for incorrect partial models, that is, we cannot save them. This is in conflict with one of our requirements where we state

85 Chapter 7. Related work 70 host editor foo representation model bar 1 embedded editor 2 repr. 3model 1. copy 2. create initial representation 3. constant changes 4. replace the edited model element 4 Figure 7.4: Embedding textual editors into graphical host editors using the approach of Scheidgen that the user should be able to save incomplete (partial) models, which is considered a practically important requirement for the user. One additional point of remark is that we would also like to save comments within code (a must in some cases), which are not necessarily defined by the meta-model. In contrast to this approach, the highlight range method does not suffer from these problems since the partial model is directly edited from one file, in case we define the concrete syntax for the full model. If a full concrete textual definition is not applicable and if we therefore would need to define separate textual editors, it would be a better solution to store this layout information (including comments, and incorrect model elements) to separate files. This is roughly in line with the approach used by Bettini, except that we do want to keep these partial model files after the changes are saved and the partial model editor is closed. Another issue that is discussed by Scheidgen is that of how to deal with cross references when the identifier of a model element has been changed. In our case, this issue is solved quite easily: when the identifier is changed manually, we consider this as simply a change of identity; in the other case, when we want to apply this globally, we simply use the rename functionality as provided by Xtext/Eclipse. Until now we have mainly seen research within the scope of embedding and using textual model editors. In case of multiple active editors, as discussed earlier, it is important to define a proper synchronization to keep model representations in editors consistent with each other. In our case, we synchronize only when changes are saved by the user,

86 Chapter 7. Related work 71 and can therefore effectively work within only one editor concurrently. A real-time synchronization approach would be interesting to apply, but was outside the scope of this project. The work of van Rust et al. proposes a robust real-time synchronization between textual and graphical editors that deals with this problem [26]. The approach also recovers from errors during parsing and text-to-model synchronizations, preserves textual and graphical layout in the presence of erroneous texts and models, and provides provides synchronized editor services such as selection sharing and navigation between editors. The implementation that was carried out considered the Spoofax language workbench and GMF. It is left as future work to investigate whether and how this fits within the scope of partial model editors. During the final stage of this project, another relevant research project worth mentioning has been discovered which was carried out by Schneider who proposed to use transientview-based model representations [36]. This approach uses a single editor and applies views for other automatically derived representations, using own in-memory resources without using files. These views show parts of the model and are synchronized automatically on changes from the host editor. The transient-view approach has been realized in a tool called KIELER, which is an academic experimental modeling environment

87

88 Chapter 8 Conclusions 8.1 Results The major contribution of this work consists of giving an overall overview of the most important integration aspects, how partial model editors for Xtext and GMF can be constructed, and how these editors can be synchronized. The work consists of a conceptual and a practical approach for applying and integrating partial model editors in a generic and structured way. The conceptual part describes various aspects such as different forms of model representations, the synchronization between these editors and how we can navigate through them. This conceptual part has been been formalized in the form of several integration requirements. The practical part shows how we can apply this based on the chosen tools, and to what tool-specific constraints we are bound. This has been demonstrated with smaller custom made DSLs to show different parts of the proposed solution space, but also with the more mature language POOSL where we combine the concepts from the smaller DSLs into a big whole. These results enable us to answer our previously posed research questions from Chapter 1: Which EMF-based frameworks can and should be used? We discussed multiple textual and graphical EMF based frameworks in Chapter 3. For the textual framework we have chosen Xtext over EMFtext mainly because it has already been used to construct an Xtext grammar for POOSL. From the set 73

89 Chapter 8. Conclusions 74 of applicable graphical frameworks we chose GMF over Graphiti because Graphiti (in contrast to GMF) does not generate implementation code and has not been published yet as a major version. How can this integration of editors be done in a systematic and generic way? Based on the answer for the previous question, we have investigated the existing out-of-the-box integration between Xtext and GMF that covered most of our specified integration requirements. However, this existing integration turned out to be lacking with respect to partial model editing, but it also did not provide any navigational structure through which multiple editors could be combined. To solve this in the most generic way we proposed the highlight range approach for Xtext editors which basically applies views on a full textual models. For GMF editors we argued that dedicated editors for each partial model are practically the only option. We also argued that although we have to define a GMF editor for each root modeling element we want to graphically display, the amount of these dedicated editors is considered to be easily manageable in most cases. The synchronization between these editors turned out to be problematic which was partly related to practical implementation issues, but partly also to the fact that the problem in general is far from trivial to solve. The problem manifested itself mainly when multiple partial model Xtext editors were used, instantiated by using the highlight range approach. We therefore restricted ourselves to one active (partial model) Xtext editor which could be synchronized with one or multiple active GMF editors, while working on one file and synchronizing on file save. Aside from the synchronization issues, by combining these approaches we have shown how to successfully integrate Xtext and GMF editors into a modular and maintainable solution. 8.2 Further discussion on co-evolution Businge conducted a series of empirical analyzes to investigate the co-evolution of the Eclipse framework and its third-party plug-ins [37]. He observed that the use of unstable and unsupported Eclipse interfaces results in incompatibilities of the systems built on top of Eclipse and its new releases. The conclusion of his work is that many developers

90 Chapter 8. Conclusions 75 work on top of existing frameworks, which is also the case in this project where we base our proposed solutions on EMF, Xtext and GMF. In terms of creating partial model editors, we need to consider the solution for Xtext and GMF separately. The highlight range approach is basically based on one function, which the corresponding Xtext editor class inherits from a Eclipse editor class. Since this is therefore core functionality of Eclipse, used by almost any framework that uses editors, it is expected to outlast next versions of Eclipse. So even if the Xtext framework at some point gets discontinued, it is still possible to apply the same solution to alternatives such as EMFText. In case of GMF we have chosen to use dedicated editors, which in terms of creating partial model editors only has a direct negative effect on co-evolution if the project gets discontinued. The solutions provided for synchronization are depending on the very core concepts of Eclipse such as Resources and listeners, which means that it does not depend on any unstable or unsupported interfaces. It is therefore also expected to be applicable in the near future. It should be noted, however, that wrapper classes such as XtextNewTabEditor.java (Appendix B.4) that contain these core solutions, might need customization as new versions of Eclipse, EMF or any other used helper class emerge. 8.3 Future work The main recommendation for improving the current work is to solve the synchronization issues between partial model Xtext editors that are instantiated using the highlight range approach. It would be also interesting to investigate whether and how the work of Rust et al. [26] can be used to establish a real-time synchronization between these partial model editors.

91

92 Appendix A Xtext grammars and model definitions A.1 Greetings Xtext grammar Listing A.1: Xtext grammar: Greetings 1 grammar org. xtext. example. mydsl. MyDsl with org. eclipse. xtext. common. Terminals 2 3 g e n e r a t e mydsl " http :// www. xtext. org / example / mydsl / MyDsl " 4 5 Model : 6 greetings += Greeting *; 7 8 Greeting : 9 Hello name =ID! ; A.2 Statemachines Xtext grammar Listing A.2: Xtext grammar: Statemachines 1 grammar org. xtext. example. mydsl. MyDsl with org. eclipse. xtext. common. Terminals 2 3 g e n e r a t e mydsl " http :// www. xtext. org / example / mydsl / MyDsl " 4 5 Statemachine : 6 { Statemachine } 7 states 77

93 Appendix A. Concrete syntax definitions 78 8 ( states += State )+ 9 end 10 transitions 11 ( transitions += Transition ) + 12 end ; State : 15 state name =ID ; ; Transition : 18 fromstate =[ State ] => tostate =[ State ] expression expression = Expression ; 19 ; Expression : 22 TerminalExpression ({ Operation. left = c u r r e n t } 23 op= + right = Expression )? 24 ; TerminalExpression r e t u r n s Expression : 27 ( Expression ) 28 { IntLiteral } value = INT 29 ; A.3 Web application Ecore definition Listing A.3: Web application ecore file 1 <?xml v e r s i o n =" 1.0 " encoding ="UTF -8"?> 2 < ecore:epackage xmi:version =" 2.0 " xmlns:xmi =" http: // www. omg. org / XMI " xmlns:xsi =" http: // /2001/ XMLSchema - instance " 3 xmlns:ecore =" http: // www. eclipse. org / emf /2002/ Ecore " name =" core " nsuri =" core " nsprefix =" core "> 4 < eclassifiers xsi: type =" ecore: EClass " name =" WebApplication " > 5 < estructuralfeatures xsi: type =" ecore: EReference " name =" tables " upperbound =" -1" 6 etype =" #// DataTable " containment =" true "/> 7 </ eclassifiers > 8 < eclassifiers xsi: type =" ecore: EClass " name =" DataTable " > 9 < estructuralfeatures xsi: type =" ecore: EAttribute " name =" name " etype =" ecore:edatatype http: // www. eclipse. org / emf /2002/ Ecore #// EString " />

94 Appendix A. Concrete syntax definitions < estructuralfeatures xsi: type =" ecore: EReference " name =" columns " upperbound =" -1" 11 etype =" #// DataColumn " containment =" true "/> 12 </ eclassifiers > 13 < eclassifiers xsi: type =" ecore: EClass " name =" DataColumn " > 14 < estructuralfeatures xsi: type =" ecore: EAttribute " name =" name " etype =" ecore:edatatype http: // www. eclipse. org / emf /2002/ Ecore #// EString " /> 15 < estructuralfeatures xsi: type =" ecore: EAttribute " name =" type " etype =" ecore:edatatype http: // www. eclipse. org / emf /2002/ Ecore #// EString " /> 16 </ eclassifiers > 17 </ ecore: EPackage >

95 Appendix A. Concrete syntax definitions 80 A.4 POOSL high-level meta-model Figure A.1 shows the high-level meta-model of POOSL, with the most relevant modeling elements. Figure A.1: High-level meta-model of POOSL

96 Appendix B Integration code B.1 Activator.java Listing B.1: Activator.java 1 package org. xtext. example. mydsl. mydsl. diagram. custom ; 2 3 import org. eclipse. core. runtime. IStatus ; 4 import org. eclipse. core. runtime. Status ; 5 import org. eclipse. ui. plugin. AbstractUIPlugin ; 6 import org. osgi. framework. BundleContext ; 7 8 p u b l i c c l a s s Activator extends AbstractUIPlugin { 9 10 // Plug -in ID 11 p u b l i c s t a t i c f i n a l String PLUGIN_ID = " org. xtext. example. mydsl. mydsl. diagram. custom "; // Shared instance 14 p r i v a t e s t a t i c Activator plugin ; // Constructor 17 p u b l i c Activator () {} 18 Override 20 p u b l i c v o i d start ( BundleContext context ) throws Exception { 21 // TODO Auto - generated method stub 22 super. start ( context ); 81

97 Appendix B. Integration code plugin = t h i s ; 24 } 25 Override 27 p u b l i c v o i d stop ( BundleContext context ) throws Exception { 28 // TODO Auto - generated method stub 29 plugin = n u l l ; 30 super. stop ( context ); 31 } p u b l i c s t a t i c Activator getdefault () { 34 r e t u r n plugin ; 35 } p u b l i c s t a t i c v o i d logerror ( Throwable t) { 38 getdefault (). getlog ().log (new Status ( IStatus. ERROR, PLUGIN_ID, t. getmessage (), t)); 39 } 40 } B.2 EditPolicyProvider.java Listing B.2: EditPolicyProvider.java 1 package org. xtext. example. mydsl. mydsl. diagram. custom ; 2 3 import org. eclipse. gef. EditPart ; 4 import org. eclipse. gmf. runtime. common. core. service. AbstractProvider ; 5 import org. eclipse. gmf. runtime. common. core. service. IOperation ; 6 import org. eclipse. gmf. runtime. diagram.ui. editpolicies. EditPolicyRoles ; 7 import org. eclipse. gmf. runtime. diagram.ui. services. editpolicy. CreateEditPoliciesOperation ; 8 import org. eclipse. gmf. runtime. diagram.ui. services. editpolicy. IEditPolicyProvider ; 9 10 p u b l i c c l a s s EditPolicyProvider extends AbstractProvider implements IEditPolicyProvider { 11 Override

98 Appendix B. Integration code p u b l i c boolean provides ( IOperation operation ) { 14 // TODO Auto - generated method stub 15 i f ( operation i n s t a n c e o f CreateEditPoliciesOperation ) { 16 r e t u r n t r u e ; 17 } 18 r e t u r n f a l s e ; 19 } 20 Override 22 p u b l i c v o i d createeditpolicies ( EditPart editpart ) { 23 // TODO Auto - generated method stub 24 editpart. installeditpolicy ( EditPolicyRoles. OPEN_ROLE, new OpenEditPolicy ()); 25 } } B.3 OpenEditPolicy.java Listing B.3: OpenEditPolicy.java 1 package org. xtext. example. mydsl. mydsl. diagram. custom ; 2 3 import org. eclipse. emf. ecore. EObject ; 4 import org. eclipse. gef. EditPart ; 5 import org. eclipse. gef. Request ; 6 import org. eclipse. gef. commands. Command ; 7 import org. eclipse. gmf. runtime. diagram.ui. editparts. IGraphicalEditPart ; 8 import org. eclipse. gmf. runtime. notation. View ; p u b l i c c l a s s OpenEditPolicy extends org. eclipse. gmf. runtime. diagram.ui. editpolicies. OpenEditPolicy { Override 13 p r o t e c t e d Command getopencommand ( Request request ) { 14 EditPart targeteditpart = gettargeteditpart ( request ); 15 f i n a l EditPart editpart = gettargeteditpart ( request ); 16 i f ( f a l s e == targeteditpart. getmodel () i n s t a n c e o f View ) { 17 r e t u r n n u l l ;

99 Appendix B. Integration code } r e t u r n new Command () { p u b l i c v o i d execute () { 23 IGraphicalEditPart graphicaleditpart = ( IGraphicalEditPart ) editpart ; 24 EObject semanticelement = graphicaleditpart. resolvesemanticelement (); 25 new XtextNewTabEditor ( graphicaleditpart, semanticelement, " org. xtext. example. mydsl. MyDsl "). openeditor (); 26 } }; 29 } 30 } B.4 XtextNewTabEditor.java Listing B.4: XtextNewTabEditor.java 1 package org. xtext. example. mydsl. mydsl. diagram. custom ; 2 3 import org. eclipse. core. resources. IFile ; 4 import org. eclipse. emf. ecore. EObject ; 5 import org. eclipse. emf. ecore. resource. Resource ; 6 import org. eclipse. emf. workspace. util. WorkspaceSynchronizer ; 7 import org. eclipse. gmf. runtime. diagram.ui. editparts. IGraphicalEditPart ; 8 import org. eclipse. jface. text. DocumentEvent ; 9 import org. eclipse. jface. text. IDocumentListener ; 10 import org. eclipse. ui. IWorkbenchPage ; 11 import org. eclipse.ui. PlatformUI ; 12 import org. eclipse.ui. part. FileEditorInput ; 13 import org. eclipse. xtext. nodemodel. ICompositeNode ; 14 import org. eclipse. xtext. nodemodel. util. NodeModelUtils ; 15 import org. eclipse. xtext. resource. XtextResource ; 16 import org. eclipse. xtext.ui. editor. XtextEditor ; 17 import org. eclipse. xtext.ui. editor. info. ResourceWorkingCopyFileEditorInput ;

100 Appendix B. Integration code p u b l i c c l a s s XtextNewTabEditor { 20 p r i v a t e IGraphicalEditPart hosteditpart ; 21 p r i v a t e String semanticelementfragment ; 22 p r i v a t e XtextResource xtextresource ; 23 p r o t e c t e d i n t editoroffset ; 24 p r o t e c t e d i n t initialeditorsize ; 25 p r o t e c t e d i n t initialdocumentsize ; 26 p r i v a t e EObject semanticelement ; 27 p r i v a t e IWorkbenchPage page ; 28 p r i v a t e XtextEditor editor ; 29 p r i v a t e ResourceWorkingCopyFileEditorInput editorinput ; 30 p r i v a t e String editorid ; 31 p u b l i c XtextNewTabEditor ( IGraphicalEditPart editpart, EObject semanticelement, String editorid ) { 32 t h i s. hosteditpart = editpart ; 33 t h i s. semanticelement = semanticelement ; 34 t h i s. editorid = editorid ; 35 } p u b l i c v o i d openeditor () { 38 t r y { 39 i f ( semanticelement == n u l l ) { 40 r e t u r n ; 41 } Resource semanticresource = semanticelement. eresource (); xtextresource = ( XtextResource ) semanticresource ; i f (!( semanticresource i n s t a n c e o f XtextResource )) { 49 r e t u r n ; 50 } 51 semanticelementfragment = semanticresource. geturifragment ( semanticelement ); 52 i f ( semanticelementfragment == n u l l "". equals ( semanticelementfragment )) { 53 r e t u r n ; 54 } 55

101 Appendix B. Integration code page = PlatformUI. getworkbench (). getactiveworkbenchwindow (). getactivepage (); ICompositeNode xtextnode = getcompositenode ( semanticelement ); 59 editoroffset = xtextnode. getoffset (); 60 initialeditorsize = xtextnode. getlength (); IFile file = WorkspaceSynchronizer. getfile ( xtextresource ); 63 FileEditorInput editorinput = new FileEditorInput ( file ); editor = ( XtextEditor ) page. openeditor ( editorinput, editorid ); editor. showhighlightrangeonly ( t r u e ); 68 editor. sethighlightrange ( editoroffset +1, initialeditorsize -1, t r u e ) ; editor. getdocument (). adddocumentlistener (new IDocumentListener () { 71 Override 73 p u b l i c v o i d documentchanged ( DocumentEvent event ) { 74 semanticelement = hosteditpart. resolvesemanticelement (); i f ( semanticelement == n u l l ) { 77 r e t u r n ; 78 } 79 ICompositeNode xtextnode = getcompositenode ( semanticelement ); 80 i f ( xtextnode == n u l l ) { 81 r e t u r n ; 82 } editoroffset = xtextnode. getoffset (); 85 Integer nodesize = xtextnode. getlength (); editor. showhighlightrangeonly ( t r u e ); 88 editor. sethighlightrange ( editoroffset +1, nodesize -1, t r u e ); 89 editor. setfocus (); 90 } 91 Override 93 p u b l i c v o i d documentabouttobechanged ( DocumentEvent event ) { 94 }

102 Appendix B. Integration code }); } catch ( Exception e) { 100 Activator. logerror (e); 101 } 102 } p r o t e c t e d ICompositeNode getcompositenode ( EObject semanticelement ) { 106 r e t u r n NodeModelUtils. getnode ( semanticelement ); 107 } 108 } B.5 plugin.xml extension point This is the extension point for the Greetings example. One needs to change GreetingEditPart to match the EditPart that needs to be instantiated. Listing B.5: plugin.xml extension point 1 < extension point =" org. eclipse. gmf. runtime. diagram.ui. editpolicyproviders " id ="" > 2 < editpolicyprovider 3 class =" org. xtext. example. mydsl. mydsl. diagram. custom. EditPolicyProvider " > 4 < Priority name =" Medium "></ Priority > 5 < context editparts =" org. xtext. example. mydsl. mydsl. diagram. edit. parts. GreetingEditPart " > 6 </ context > 7 < object 8 class =" org. xtext. example. mydsl. mydsl. diagram. edit. parts. GreetingEditPart " 9 id=" org. xtext. example. mydsl. mydsl. diagram. edit. parts. 10 </ object > GreetingEditPart " > 11 </ editpolicyprovider > 12 </ extension >

103

104 Appendix C Tutorials C.1 Creating an Xtext editor Before creating an Xtext editor, make sure that Eclipse and Xtext are installed correctly. To create a default Xtext project template, we proceed as follows: 1. Select File > New... > Project and then select Xtext > Xtext Project. Click Next to continue to the next page. 2. After filling in the fields we click on Finish and our project is automatically created. Assuming that our project name is org.xtext.example.mydsl, we can navigate to org.xtext.example.mydsl > src > org.xtext.example.mydsl. Here we will find a.xtext file that contains our grammar. After defining a custom grammar, we simply right click on the.xtext file and then select Run as > Generate Xtext artifacts. The first time we call this generation procedure we will get the following message within the Eclipse console: *ATTENTION* It is recommended to use the ANTLR 3 parser generator (BSD licence - Do you agree to download it (size 1MB) from 89

105 Appendix C. Tutorials 90 (type y or n and hit enter) After typing in y and pressing enter, Xtext will automatically generate the necessary Xtext artifacts, such as the ecore file which describes our meta-model, based on our previously defined grammar. This ecore file is located in org.xtext.example.mydsl > model > generated (by default MyDsl.ecore). 1 C.2 Creating a GMF editor Before discussing how to create GMF editors, we assume that EMF and the GMF plugins are installed. The first step in creating a GMF editor is usually to define an EMF model (Ecore file). If we have previously created an Xtext editor, the EMF model is automatically generated. We assume in any case that we already have our EMF model defined. A convenient way to create GMF editors based on an existing EMF model is to use the so called GMF Dashboard, which is a utility that aides in the process of performing all the necessary steps. We can find this utility by selecting: Window > Show view > Other > GMF Dashboard. The utility is displayed in Figure C.1. Figure C.1: GMF Dashboard 1 This information is based on Xtext version