development of a refactoring plug-in for the eclipse ...swt/... · the osgi standard [6], a dynamic...

Philipps-Universität MarburgFachbereich Mathematik und Informatik

Diplomarbeit

Development of a Refactoring Plug-in for the

Eclipse Modeling Framework

Author: Lars Schneider

Professor: Prof. Dr. Gabriele Taentzer

December 18, 2008

Acknowledgements

I want to say thank you to a few people for supporting me during my studies of computerscience but especially during my diploma thesis. The �rst person I want to mention ismy mentoring professor Dr. Gabriele Taentzer. She supported me and encouraged meto get in contact with the Eclipse community and �nally send me to the Eclipse SummitEurope 2008 in Ludwigsburg for presenting her position paper concerning model qualityand the EMF Refactoring Plug-in.But I also want to thank Dr. Gabriele Taentzer for getting me in contact with Dr.

Michael Kersten of Siemens Corporate Technology. Siemens supported me �nanciallyduring my diploma thesis and for this I am truly grateful.Florian Mantz, a fellow student of mine, also earns thanks because he was the main

customer of the EMF Refactoring Plug-in. He designed several refactorings and thereforeI was able to test the generation process and the application of refactorings in everydetail.To my parents El� and Theo Schneider I want to say thank you very much for �nancial

but, more than that, for their personal support during my studies because they werealways there for me as well as my girlfriend Laura Kil. I want to thank her for herspecial support, for her kindness and patience during my diploma examinations andduring my diploma thesis. She encouraged me whenever I was powerless.And last but not least I want to thank Christina Heitzer and Stefan Jurack for proof-

reading this thesis and suggesting appropriate modi�cations.

II

Abstract

Code refactoring is a well known and investigated technique to improve software struc-ture without changing the observable behaviour. This includes improvement of read-ability, maintainability, adaptability, and e�ciency of code. On the contrary, modelrefactoring is much less explored and there is hardly any existing tool support which isdue to for one thing models being more versatile and for another thing models beingless used in software development than code. The idea for the EMF Refactoring Plug-inemerged during a practical programming course where I developed an Eclipse plug-in forUML refactorings. The requirements included designing refactorings as well as applyingthem. All refactorings should be designed as endogenous model transformations withthe aid of the EMF Transformation framework, which is not limited to UML2 as the un-derlying metamodel. Transformations may be de�ned for any EMF based model. Fromthis my diploma thesis emerged where I developed an Eclipse plug-in providing refac-toring functionality for EMF based models. Every refactoring should be self-containedin order to be exchangeable and, �rst of all, extensible concerning new refactorings.Since model refactorings should be as similar as possible to code refactorings providedby Eclipse, we integrated context menus, wizards, and EMF Compare. The result of allthis is an Eclipse plug-in providing for one thing the application of model refactoringsand for another thing with the use of EMF Transformation the design of completely newmodel refactorings for any kind of EMF based model and the subsequent generation ofa new model refactoring as a plug-in.

III

Kurzfassung

Code Refactoring ist eine wohlbekannte und gut erforschte Technologie um die Strukturvon Software zu verbessern ohne dabei die Funktionalität zu verändern. Dies beinhal-tet die Verbesserung von Lesbarkeit, Wartbarkeit, Anpassungsfähigkeit und E�zienzvon Code. Model Refactoring hingegen ist weit weniger erforscht und es existiert fastkeine Werkzeugunterstützung, was einerseits daran liegt, dass Modelle vielseitiger alsCode sind und zum anderen, dass sie weniger in der Softwareentwicklung eingesetztwerden. Die Idee zum EMF Refactoring Plug-in entstand ursprünglich in einem Pro-grammierpraktikum. Gefordert war die Möglichkeit, Refactorings für UML Modellezu erstellen und auch anzuwenden. Die Refactorings selber sollten als endogene Mod-elltransformationen mit Hilfe von EMF Transformation de�niert werden, welche sichnicht auf UML als Metamodell beschränken sondern für beliebige EMF basierte Mod-elle de�niert werden können. Hieraus entwickelte sich die Idee zu meiner Diplomarbeit,in der ich ein Eclipse Plugin entwickeln sollte, welches Refactoring-Funktionalität fürEMF basierte Modelle bereitstellt. Die Refactorings selber sollten als eigenständige Plu-gins bereitgestellt werden, um austauschbar und vor allem erweiterbar zu sein. ModellRefactorings sollten möglichst ähnlich zu den von Eclipse bereitgestellten Code Refac-torings sein, was durch die Verwendung von Kontextmenu, Wizards und EMF Compareverwirklicht wurde. Das Ergebnis ist ein Eclipse Plugin mit dem man zum einen ModellRefactorings anwenden kann und zum anderen mit Hilfe von EMF Transformation völligneue Refactorings zu beliebigen Metamodellen de�nieren und anschlieÿend als Pluginsgenerieren kann.

IV

Contents

1 Introduction 1

2 Eclipse plug-in development 3

2.1 Serving an extension point . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 De�ning an extension point . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Required plug-ins 9

3.1 Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . . . . . . . 93.2 EMF Transformation Project . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1 Code generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.2 Extending the context menu . . . . . . . . . . . . . . . . . . . . . 13

3.3 EMF Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Model refactorings 17

4.1 De�nition of refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 From code refactorings to model refactorings . . . . . . . . . . . . . . . 17

4.2.1 Pulling up code refactorings . . . . . . . . . . . . . . . . . . . . . 184.2.2 New refactorings for new languages . . . . . . . . . . . . . . . . . 23

4.3 UML refactorings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.1 Basic UML refactorings . . . . . . . . . . . . . . . . . . . . . . . 254.3.2 Extract Superclass . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Requirements 29

5.1 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . 295.2 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.1 Refactoring EMF models . . . . . . . . . . . . . . . . . . . . . . 305.2.2 Create EMF refactoring . . . . . . . . . . . . . . . . . . . . . . . 30

6 The EMF Refactoring Plug-in 31

6.1 Agile software development . . . . . . . . . . . . . . . . . . . . . . . . . 316.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.3 Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.3.1 Extension point: org.eclipse.ui.popupMenus . . . . . . . . . . . . 336.3.2 Extension point: org.eclipse.ui.actionSets . . . . . . . . . . . . . 346.3.3 Extending the generator of EMFTrans . . . . . . . . . . . . . . . 36

6.4 Implementation of the EMF Refactoring Plug-in . . . . . . . . . . . . . 366.4.1 Application of model refactorings . . . . . . . . . . . . . . . . . . 376.4.2 Generating new model refactorings . . . . . . . . . . . . . . . . . 38

6.5 The source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

V

Contents

6.5.1 Generate refactoring . . . . . . . . . . . . . . . . . . . . . . . . . 416.5.2 Automated generation . . . . . . . . . . . . . . . . . . . . . . . . 436.5.3 Applying a generated model refactoring . . . . . . . . . . . . . . 45

7 How to create a model refactoring 51

7.1 Installation of the EMF Refactoring Plug-in . . . . . . . . . . . . . . . . 517.2 Creating Move Package . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.3 Copying objects in refactorings . . . . . . . . . . . . . . . . . . . . . . . 54

8 How to apply a model refactoring 55

8.1 Installing model refactorings . . . . . . . . . . . . . . . . . . . . . . . . . 558.2 Applying Pull Up Property . . . . . . . . . . . . . . . . . . . . . . . . . 55

9 Conclusion and future prospects 59

9.1 The current version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599.2 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

9.2.1 Improvements to the refactoring generation process . . . . . . . . 609.2.2 Improvements to the application of refactorings . . . . . . . . . . 619.2.3 Internal improvements . . . . . . . . . . . . . . . . . . . . . . . . 61

List of Figures 63

Bibliography 65

VI

1 Introduction

Today, software systems are developed using models and writing code, but frequentlythese models are used for documentation purpose only. Model driven software develop-ment, on the contrary, emphasises models as primary artifacts and uses generators andinterpreters to obtain a software system. In order to develop high quality software it isnecessary to de�ne models as exactly as possible, because the better the model the betterthe resulting software systems [1]. Model refactorings can be used to improve softwarequality because they improve the internal structure, e. g. by removing redundancies.

Every software developer, whether using models, code, or a combination of both,would appreciate an improvement of the internal structure but the project managementusually makes sure that the developed software works and that the time schedule is met.And because of a tight time schedule, refactorings are often ignored because the customerdoes not perceive their results anyway. But I think that this course of action is a fallacy,because in general it does not save but occasion costs. For one thing refactorings mightimprove performance of the system because redundancy is minimized and for anotherthing, which is usually more important, the maintainability is improved such that itbecomes much easier to understand how the software works. This is of concern whena new developer joins the team, for either reinforcing the team or replacing someonewho left the team or even the company. A developer who leaves a company usuallytakes some knowledge away from the company but a well structured software systemminimises this removal. I think this points out that refactorings are necessary andshould be considered especially in huge projects even if the development of new featuresor the improvement of existing features comes to stagnation for a certain time.

In the context of my diploma thesis I developed a plug-in for Eclipse [2] providingmodel refactorings for EMF [3] based models de�ned as model transformations [4]. Ibegan writing this thesis after developing the EMF Refactoring Plug-in. Several bugswere uncovered and �xed and a few very useful enhancements were developed duringcomposing and it may be that there are still remains of old implementations in earlywritten chapters although I tried to adapt them. I added a CD-ROM to this thesis con-taining an Eclipse installation with the EMF Refactoring Plug-in and all other necessaryplug-ins.

This thesis starts with a short introduction to plug-in development in general in-cluding an easily understandable example of creating a view in Section 2. Thereafter Iaddress the plug-ins mainly used, namely EMF, EMF Transformation, and EMF Com-pare in order to implement the EMF Refactoring Plug-in in Section 3. For illustrationI developed an regularly revisited example of a library. Section 4 deals with modelrefactorings in general. It contains a de�nition of the term and describes how to adoptexisting refactorings and when to develop completely new refactorings. Again, I devel-oped several examples for demonstration. In the end of this chapter I as well take alook at UML refactorings. The requirements are put down in Section 5 and Section 6

1

1 Introduction

�nally describes the whole development process, including the method of software devel-opment, the software design, the realisation, and the implementation. Since the creationand the application of refactorings is not trivial I included Section 7 and Section 8 inorder to give the refactoring designer and the model developer a helping hand. Section 9completes this thesis because it summarises the existing functionality and contains allimprovements I was not able to implement because of a tight time schedule.

2

2 Eclipse plug-in development

Eclipse is based on a �exible plug-in model namely Equinox [5], an implementation ofthe OSGi standard [6], a dynamic module system for Java. For further readings aboutEquinox and OSGi I suggest [7]. Eclipse is designed to run on multiple operating systemsand provides a common user interface model. Most people know Eclipse as an integratedJava development environment which is possible due to the Java Development Tools(JDT) [8] plug-in. But there are other plug-ins available to support other programmingor scripting languages:

• Eclipse C/C++ Development Tooling - CDT [9]

• TeXlipse (LATEX) [10]

• PHP Development Tools (PDT) [11]

• Ruby Development Tools (RDT) [12]

But Eclipse is not con�ned to being an IDE for di�erent programming languages. EveryEclipse user can easily create his or her own plug-in using the Plug-in DevelopmentEnvironment (PDE) [13]. What else Eclipse can be is proposed by Wayne Beaton [14].Since I developed a tool for model refactorings I will show you how easy it is to developa new Eclipse plug-in by guiding you through the development of a sample plug-inby explaining how to serve existing extension points and how to create new extensionpoints.

2.1 Serving an extension point

The whole Eclipse window is called workbench. A workbench contains several pageswhich, in turn, contain a collection of editors or views. This section shows the devel-opment of a simple view displaying a string representation of all selected objects in theworkbench. Therefore we create a new plug-in project via the wizard. The name of theproject in this example is set to Selection View and all other settings in this wizardare left unchanged so that we can �nish the wizard. Thereafter you should be askedto open the associated perspective which, in this case, means nothing but opening theplug-in development perspective. If not, you can open this perspective via Window> Open Perspective > Other.... If not automatically opened you should open the �leplugin.xml in the newly created project with the �Plug-in Manifest Editor�. Navigateto the tab labeled Extensions and add the extension point org.eclipse.ui.views. Witha right mouse click on the newly created element you can add a new category and anew view. A category must have an id and a name. Also a view must have an id

and a name but additionally a class and optionally a category where this view shouldappear in. The other optional attributes are not used in this example and thereforeleft out here. The values of the above-mentioned attributes are shown in the resultingplugin.xml in Figure 2.1.

3


1 <?xml version="1.0" encoding="UTF -8"?>

2 <plugin >

3 <extension point="org.eclipse.ui.views">

4 <category id="Analyse_Selection"

5 name="Analyse Selection">

6 </category >

7 <view class="selection_view.SelectionView"

8 id="Selection View"

9 name="Selection View"

10 category="Analyse_Selection">

11 </view>

12 </extension >

13 </plugin >

Figure 2.1: The plugin.xml of the project Selection View de�ning a new categorycontaining a new view

The last thing to do is implementing the class de�ned in the new view which must be asubclass of ViewPart1 and therefore implement the methods createPartControl(Composite)

and setFocus(). Additionally we want to implement the interface ISelectionListener2

in order to change the content of our view if the selection in the workbench changes.For this we have to implement selectionChanged(IWorkbenchPart, ISelection). Our classhas two object �elds saving for one thing the selection and for the other thing a List3

displaying the selection. The method createPartControl(Composite) initialises this List,adds itself as a selection listener to the workbench, and �nally refreshes the content of theList. If the selection changes, the method selectionChanged(IWorkbenchPart, ISelection)

is invoked which saves the selection in the object �eld and refreshes the content of theList. The whole source is shown in Figure 2.2.Now we can test our new view in a runtime Eclipse application where the category

containing the view should be available by Window > Show View > Other.... You canalso export the project as a plug-in via File > Export and place it in the dropins folderof your Eclipse installation.This example shows, that serving extension points is quite easy. However, creating

sensible new plug-ins of course is much more challenging but the process of creating newplug-ins in general is reasonable for everyone. On the contrary, creating a new extensionpoint is a little more sophisticated because you need to de�ne it and you should also dosomething with extensions serving your extension point.

2.2 De�ning an extension point

In this section I will develop an extension point for model refactorings that should befurther developed and then integrated into future versions of the EMF Refactoring Plug-in. This is not done yet because I could not �gure out, how to wrap an extension pointaround other extension points (cf. Section 9).

1org.eclipse.ui.part.ViewPart2org.eclipse.ui.ISelectionListener3org.eclipse.swt.widgets.List

4


1 package selection_view;

23 import org.eclipse.jface.viewers.ISelection;

4 import org.eclipse.jface.viewers.StructuredSelection;

5 import org.eclipse.swt.SWT;

6 import org.eclipse.swt.layout.GridData;

7 import org.eclipse.swt.widgets.Composite;

8 import org.eclipse.swt.widgets.List;

9 import org.eclipse.ui.ISelectionListener;

10 import org.eclipse.ui.IWorkbenchPage;

11 import org.eclipse.ui.IWorkbenchPart;

12 import org.eclipse.ui.IWorkbenchPartSite;

13 import org.eclipse.ui.part.ViewPart;

1415 public class SelectionView extends ViewPart

16 implements ISelectionListener {

17 private ISelection selection;

18 private List list;

19 public void createPartControl(Composite parent) {

20 list = new List(parent , SWT.V_SCROLL | SWT.H_SCROLL );

21 list.setLayoutData(new GridData(GridData.FILL_BOTH ));

22 IWorkbenchPartSite site = this.getSite ();

23 IWorkbenchPage page = site.getPage ();

24 page.addSelectionListener(this);

25 refreshView ();

26 }

27 public void selectionChanged(IWorkbenchPart part ,

28 ISelection selection) {

29 this.selection = selection;

30 refreshView ();

31 }

32 private void refreshView () {

33 if (selection != null) {

34 if (selection instanceof StructuredSelection) {

35 list.removeAll ();

36 StructuredSelection strSel = (StructuredSelection) selection;

37 Object [] selections = strSel.toArray ();

38 for (Object object : selections) {

39 list.add(object.toString ());

40 }

41 }

42 }

43 }

44 public void setFocus () {}

45 }

Figure 2.2: Implementation of the class SelectionView showing the newly created view

5


A new extension point is created by opening the Plug-in Manifest Editor, navigatingto the tab Extension Points and clicking the button �Add...�. Thereupon a wizard popsup which should be �lled out as illustrated in Figure 2.3.

Figure 2.3: The wizard for creating a new extension point

Now we have to add a new element which should be allowed in the extension point.In the example in Figure 2.4 I named it modelRefactoring. After that we shouldtake a look at what is needed to integrate a model refactoring into an editor generatedby EMF.Codegen (cf. Section 3.1). There is always an id to reference an extension.For integrating the model refactoring into the context menu we need a label and theaccording action. Additionally we need to con�gure the visibility which is a class orinterface that must implement EObject4. Optionally we can de�ne a category in orderto group the model refactorings. All these are attributes of the element modelRefac-toring. At last we have to de�ne that any number of modelRefactorings is allowedin this extension point by adding a sequence to the extension element. The other optionwould be to add a choice but since we only have de�ned a single element that makes nosense here.Now we can access all extensions serving this extension point by using something like

the code snippet in Figure 2.5.

4org.eclipse.emf.ecore.EObject

6


Figure 2.4: The newly de�ned extension point for model refactorings

1 IConfigurationElement [] config = Platform.getExtensionRegistry ()

2 .getConfigurationElementsFor(

3 "de.unimarburg.refactoring.modelRefactorings");

4 for (IConfigurationElement e : config) {

5 Object o = e.createExecutableExtension("class");

6 doSomethingWith(o);

7 }

Figure 2.5: This code snippet shows how to access all extensions to the extension pointde.unimarburg.refactoring.modelRefactorings

7

3 Required plug-ins

The goal of this thesis is to develop an Eclipse plug-in for model refactoring. Talkingabout Eclipse and modeling leaves no doubt about the �rst pillar: The Eclipse ModelingFramework (EMF) [15].

The next arising question is how to achieve model refactorings. The challenge hereis to transform a source model and to receive a refactored model. In fact, this impliesthe need of for one thing the de�nition of refactorings as model transformations and foranother thing the actual model transformation implemented in Java. Hence, I decidedfor the EMF Transformation Project [16] to become the second pillar.

The last pillar was the result of testing the plug-in. It was quite laborious to �nd outwhether a transformation was successful or not. Thanks to the short-term memory. Alittle investigation brought up EMF Compare [17] which is now used to clearly show thedi�erences between the original model and the refactored model.

3.1 Eclipse Modeling Framework

The Eclipse Modeling Framework Project (EMF) [3] extends Eclipse by modeling fa-cilities including the generation, editing and view of models. EMF consists of threefundamental pieces:

• EMF (core)• EMF.Edit• EMF.Codegen

The core of EMF contains Ecore, a meta model similar to the metamodel of UMLclass diagrams, and a runtime support for models including change noti�cations, XMIserialization, and an API for manipulating EMF objects [18].

EMF.Edit is a framework including generic classes to build editors for EMF modelsusing JFace viewers and property sheets already supporting some functionality likeundo / redo or drag'n'drop.

EMF.Codegen contains a code generator that supports three levels of code generation:

1. Model Code generates Java interfaces re�ecting the model at code level. Usinginterfaces makes it very easy to exchange the actual implementation. Additionallya sample implementation of every interface is generated as well as a factory classto create instances of each class.

2. Edit Code is used to adapt each model class for editing and displaying which impliesthe generation of the model code �rst.

3. Editor Code generates an editor for instance models using both generation pro-cesses described above.

9

3 Required plug-ins

Example: Library Model

To demonstrate a few features of EMF I designed a simple meta model. This metamodel is - strictly speaking - an Ecore instance model like every meta model designedwith EMF. Figure 3.1 shows this model in an Ecore diagram created with Ecore Toolswhich is part of the Eclipse Modeling Framework Technology (EMFT) [19] project.

Figure 3.1: Modeling a library

A Library has one or two employees which are modeled as Librarians. The referenceemployees is contained in Library. The reference customers is structurally equal toemployees except the number of Customers which can be any number greater or equalzero. The fact that Librarians and Customers are both persons is modeled by a commonsupertype Person. Up to this point I only mentioned references. But each person alsohas the following attributes:

• Each Person has an attribute name and, by inheritance, Librarian and Customer,too.

• Since a Librarian is an employee, he or she gets a salary.• To be able to borrow a book from the library, each Customer owns a reader's passwith a unique readersPassID.

The third containment of a Library is the reference bookshelves. A Library canhave any number of bookshelves (if there is enough room) and each Bookshelf has aunique attribute id. Finally, what would a library be without Books. These Books areusually placedIn exactly one Bookshelf. In this model a Book is always placedIn aBookshelf even if this Book is borrowedBy a Customer. borrowedBy is an optionalreference belonging to Book and the opposite reference borrowedBooks predicatesthat a Customer can borrow as many Books as he or she likes.

As mentioned above EMF provides code generation facilities. Beforehand we need tocreate a new EMF Model called Library.genmodel based on Library.ecore. Withthis generator model we can invoke the code generation facilities from the context menuof the model's elements. The entry �Generate Model Code� generates the interfaces

10

3.1 Eclipse Modeling Framework

• Library,

• Book,

• Bookshelf,

• Librarian,

• Customer, and

• Person

and the corresponding implementing classes, which are su�xed with Impl and placed inthe subpackage impl. Additionally, the interface LibraryFactory and the correspondingimplementing class LibraryFactoryImpl are created to instantiate every model class. Allthese classes are generated by default into the existing project containing the generatormodel.

�Generate Edit Code� invokes the generation of item provider classes for each modelclass, an item provider adapter factory, several manifest �les, and an icon for each modelclass. The resulting project is a plug-in project that contains classes for UI-independentediting support.

Complementary, the entry �Generate Editor Code� generates a separate plug-in projectcontaining UI-dependent classes for opening, editing, and saving instance models inEclipse.

Now we have to start a new instance of Eclipse with these three plug-ins installed.This can be done in various ways. The easiest is to start a runtime Eclipse applicationbut you can also export your plug-ins into the dropins folder of an existing Eclipseinstallation. Assuming Eclipse running with installed plug-ins we can now generate anew instance model of a library by just creating a new Library Model using File >New > Other. . . . Editing a library instance model is identically equal to editing an ecoremodel except for icons and names. Figure 3.2 shows a small example from UmbertoEco's �The Name of the Rose� [20].

Figure 3.2: Example of a library instance model

11

3 Required plug-ins

3.2 EMF Transformation Project

The EMF Transformation Project (EMFTrans) [16] is a plug-in for Eclipse as wellas a standalone java application. It has been developed at the TU Berlin by severalstudents in their diploma theses (for example by Christian Köhler [21]) and severalresearch assistants. EMFTrans provides a graphical editor used for de�ning modeltransformations as a special kind of graph transformation.

But how can we actually manage to transform a model? Using EMF Trans we candesign rules which are very simple transformations. In a rule you can design a pat-tern in the left-hand side you want to �nd in the model and transform it into anotherpattern de�ned in the right-hand side. Additionally you can de�ne several negativeapplication conditions which are also patterns that prevent the rule from being applied.Transforming one pattern into another or testing negative application conditions re-quires mappings between objects in the left-hand side and objects in right-hand side ornegative application conditions or both in order to preserve, delete, or create objects.An object in the left-hand side with a mapped object in the right-hand side is preservedwhile without a mapped object in the right-hand side it is deleted from the model in-cluding all its possible children. An object in the right-hand side without a mappedobject in the left-hand side is newly created and attached to the model.

Objects in each of the three areas may have, according to the metamodel, certainattributes we can set using variables and in the right-hand side we can additionallyuse Java expressions. These variables can be set by the rule itself when matching thepattern in the left-hand side to the model or they can be declared as input parametersso that they have to be set before the transformation can be applied.

As already mentioned, a rule is a very simple transformation. For more complextransformations we need to compose several rules and apply them in a particular orderwhich is achieved by assigning each rule to a particular layer. Executing a layer means toapply every containing rule. These rules are applied in a non-deterministic way as longas any rule is applicable. Layers are executed sequentially, i. e. every layer is executedonly once and after the execution of a layer is �nished, the next layer is executed. Alayer is modeled simply as an EInt and they are executed in ascending order. An extractfrom the EMFTrans metamodel is contained in Figure 3.2 showing all above-mentionedfeatures of a rule and hence the features of a transformation.

After de�ning several rules ordered in layers we actually have a new model trans-formation which can be applied to EMF based models by either a interpreter or bygenerating code. For further information about the interpreter I refer the interestedreader to [22] and [23]. The generator is explained in the next section because we makeintensive use of it and even extended the generator as well as the templates.

3.2.1 Code generation

With EMFTrans it is possible to generate Java code performing the de�ned transfor-mation. This generator creates a new Java project containing two packages: rules andwrapper. The package rules contains a class for every designed rule su�xed with �Rule�.The most important methods in a rule are the ones starting with �setPar�, which setthe input parameters and the method execute(), which actually executes a rule. Ad-

12

3.2 EMF Transformation Project

Figure 3.3: Extract from the EMFTrans metamodel

ditionally to rule classes a class called Transformation is generated. This class providesthe application of a single rule by calling the method applyRule(...) or the applicationof the whole transformation calling transform(...). This applies all rules in the orderde�ned by the above-mentioned layers.

The second package created by the generator is called wrapper. Analogous to thepackage rules there is one class generated for each rule but this time su�xed with�Wrapper�. A Wrapper is used to �nd matchings for the LHS in the model to transform.Generally, this is done by

• setting input parameters (setPar...(...)),

• removing all objects not matching these input parameters (reduceDomains()),

• and �nally �nding a matching (getSolution()).

3.2.2 Extending the context menu

The generator of EMFTrans is entirely su�cient for a model transformation plug-in.You can use the generated code in your projects to transform a loaded model program-matically. But I needed an automated generation of model transformations includingthe transformation code but also graphical user interface components because the trans-formation is applied during a model driven software development process in a graphicalenvironment. So I downloaded the source code of EMFTrans and de�ned an exten-sion point1 for adding entries to the context menu of a rule. Luckily, the developers ofEMFTrans added this extension point de�nition and the according adjustment of thesource code to their main development branch. For a more detailed description of thisextension point see Section 6.

1de.tuberlin.emt.gui.othercontextmenuentries

13

3 Required plug-ins

Example: Library model

To resume the example introduced in Section 3.1 I designed a refactoring for a libraryinstance model. I will leave the question whether Move Book is a refactoring undecided.

Figure 3.4 shows a sample refactoring for instances of the library model. The refac-toring called Move Books moves all Books with the attribute title, equals to the inputparameter TitleOfBook into the Bookshelf with the attribute id equals to the secondinput parameter BookshelfID regardless in which Bookshelf the Books were placedbefore. The application of Move Books really terminates because every time the ruleis applied, a Book with the right title is moved from one Bookshelf to another. Thiscircumstance alone is not su�cient for termination. The point is that the two Book-shelf objects can not be one and the same object because EMFTrans maps di�erentmodel objects to di�erent LHS objects. Therefore the number of Books with the righttitle not placed inside the target Bookshelf decreases with every rule application. Thewhole refactoring consists of only a single rule without NACs. A more complex but stillrelatively simple refactoring is described in Section 4.3.

Figure 3.4: A sample refactoring for a library instance models

3.3 EMF Compare

EMF Compare [17] is an Eclipse plug-in that extends EMF with the ability of modelcomparison with any EMF based model. It provides not only comparing but also merg-ing models. However, in this context we only need to compare the original model tothe transformed one. It looks similar to text compare in Eclipse but it does more thansimply compare the xmi source of the two models.

EMF Compare �rst matches the models and then, according to the match, �nds thedi�erences between the models. Therefore, as shown in Figure 3.5, two models arecompared to each other using a match engine producing a new match model which�gures out which elements in the two models match each other. There is a genericimplementation provided by EMF Compare but you are free to implement and use your

14

3.3 EMF Compare

own speci�c match engine. The di� builder browses the match model and computes adelta which can be serialized as an EMF based model.

Figure 3.5: How EMF Compare works. This image was downloaded from http://wiki.

eclipse.org/Image:CompareGlobal.png

EMF Compare uses the the Eclipse compare API to compare two models to eachother. Therefore we need a CompareEditorInput2 for creating a new compare dialog orcompare editor. CompareEditorInput is an abstract class for running the compare oper-ation and presenting the results of this operation. For speci�c comparison this classis subclassed which in case of EMF Compare is performed by ModelCompareEditorInput3.This class is instantiated using a ModelInputSnapshot4 which contains the match modelrepresented by MatchModel5 and the di� model represented by DiffModel6. The MatchModel

can be created using MatchService.doMatch(EObject, EObject, Map<String, Object>) and theDiffModel using DiffService.doDiff(MatchModel).

Example: Library Model

Again I resume the library model example to show how EMF Compare works. Inpreparation I took the sample model from Figure 3.2 and applied the refactoring fromFigure 3.4 to it. In Figure 3.6 the result of this refactoring is compared to the originalmodel. The upper part of the editor can browse the structural di�erences betweenthe models which shows whether objects have been deleted, added, moved, etc. Thealert reader may have noticed that there is a bug in this example: The structuraldi�erences a�rm that the Books have been from Bookshelf 2 to the other bookshelvesbut it actually is the other way round as you can see in the visualisation of di�erencesbelow the structural di�erences. Di�erences according properties of certain objects arevisualised in the tab Properties below.

2org.eclipse.compare.CompareEditorInput3org.eclipse.emf.compare.ui.editor.ModelCompareEditorInput4org.eclipse.emf.compare.diff.metamodel.ModelInputSnapshot5org.eclipse.emf.compare.match.metamodel.MatchModel6org.eclipse.emf.compare.diff.metamodel.DiffModel

15

3 Required plug-ins

Figure 3.6: Example of EMF Compare

16

4 Model refactorings

The process of software development evolved from using Assembler to developing ina high-level language like C, C++, or Java. With this advancement the developer'swork became a hole lot simpler and increased their e�ciency. Since software systemsare becoming larger and therefore very unhandy, it becomes more and more di�cultto entirely overview even systems developed in a high-level language. In this processdevelopers may �nd documentations helpful because they often contain a graphicalmodel such as a UML Class Diagram or other kinds of diagrams. But these modelsusually are merely a snapshot of the ongoing development process and must be adaptedto every change in the system. This usually leads to an inconsistency of model andcode unless the code is re-engineered regularly which is coupled with plenty of work todo. Because of this progressive advancement one proceeds to develop new software in amodel-driven way which means that not the source code but the models are in the centreof attention whereas the source code is created by - possibly customized - generators.That is why models can be seen as some kind of a higher high-level language whichmakes it easier to entirely overview and develop even very large software systems [1].

4.1 De�nition of refactoring

Before the discussion of model refactorings it is essential to have an accurate de�nitionof the term refactoring. I would like to start with a de�nition taken from [24, p. 9] whichis probably the most frequent citation in the context of refactoring:

Refactoring is the process of changing a software system in such a way thatit does not alter the external behavior of the code yet improves its internalstructure.

Changing a software system is very easy, but ensuring not to change the externalbehaviour is quite di�cult. A formal programming language like Java allows a mathe-matical de�nition of the external behaviour. After refactoring the software system onecan verify that this behaviour did not change. But a semi-formal language like UMLmakes this approach more challenging.Improving the internal structure is the other challenge of a refactoring because the

quality of internal structure is not accurately de�ned. Of course, certain features likereadability, usability, adaptability, and e�ciency are considered but the focus dependson the angle of vision.

4.2 From code refactorings to model refactorings

According to [25] there are typical examples of refactorings:

17


• De�ne a new abstract superclass of several existing classes in order to summarizetheir similarities and to create a homogeneous interface.

• Move classes between or along inheritance hierarchies to adjust semantically in-correct or inadequate generalizations and make a proper use of inheritance.

• Move attributes and methods from one class to another to avoid needless param-eters in a method call and unnecessary associations between classes.

• Hide public attributes and de�ne the corresponding getter/observer and setter/-mutator method to achieve a higher level of encapsulation.

• Extract a code fragment into a method and replace it with the according methodcall to avoid long methods and duplicate fragments.

• Rename class, attribute, method, and parameter to reveal its purpose.

This list of refactorings provides a good basis but it is not complete by far because forone thing it only contains code refactorings and for another thing there are many othercode refactorings de�ned in Martin Fowler's book [24]. In this book, each description ofa code refactoring is separated into motivation and mechanics which is usually followedby at least one example.

The following chapter reveals di�erent techniques for de�ning refactorings. On theone hand, code refactorings can be pulled up to the level of models, and on the otherhand requires every new metamodel new model refactorings. There may also be somekind of adoption possible but in general, model refactorings have to be re-designed forevery metamodel.

4.2.1 Pulling up code refactorings

UML Class Diagrams are very closely related to source code. That is why many coderefactorings can be pulled up to UML Class Diagrams. Pulling up a code refactoringmeans to adopt the idea and de�ne a structural improving model transformation whichpreserves the external behaviour.

Example: Hide Property

Hide Property is a well known refactoring for object oriented programming languagesthough occasionally going under the name of Encapsulate Field [26]. Object-orientedprogramming languages use the encapsulation of �elds to protect them from beingchanged directly. Most �elds should be accessed by the according getter and settermethods. But what actually is the assignment of the UML refactoring Hide Property?Hide Property changes the visibility of the chosen property to a private visibility andcreates the according getter and setter operation. The visibility of these two opera-tions is usually set to the property's previous visibility to achieve the preservation ofexternal behaviour. Figure 4.2.1 illustrates the application of Hide Property to a verysimple class containing only one property �hideMe�. After apllying the refactoring thevisibility of this property has become private and two new operations, �getHideMe� and�setHideMe�, are created.

As described in the last chapter, model refactorings are considered as model transfor-mations. Therefore I designed this model transformation as illustrated in Figures 4.2through 4.6

18


Figure 4.1: Illustration of the result of the application of the UML refactoring HideProperty

The �rst layer contains the rules CreateGetterForeignType (cf. Figure 4.2) andCreateSetterForeignType (cf. Figure 4.3) which creates a getter and a setter Op-eration for a non-private Property because every rule contains a NAC avoiding theapplication to a Property with a private visibility. We used two separate rules for thedesign of generating getter and setter Operations because the existence of a setter shouldnot avoid the generation of a getter and vice versa.

Figure 4.2: Hide Property: Rule for creating a getter for a property

There should be at most one matching for the LHS of CreateGetterForeignTypein the model to transform because the Package is speci�ed by the structural featurequali�edName which should be unique in every model. Furthermore the name of aClass should be unique in a Package and the name of a Property should be uniquein a Class. These names are set using input parameters className and propName.

19


The name of the Property 's Type is stored in an input parameter typeName in orderto correctly compose the name of the getter Operation because in case of Boolean thegetter Operation should begin with �is� instead of �get�.

If this matching for the LHS is found and if the Class does not already contain agetter Operation for the Property this rule is applied. That means that the model partsmatching the LHS are transformed into the RHS pattern. At �rst, the new objectsOperation and Parameter are newly created using factory methods. Thereafter newreferences are set to connect the newly created objects to the model parts matching theLHS . The Operation is connected to the Class as an ownedOperation, the Parameter isconnected to the new Operation as an ownedParameter and the Parameter 's structuralfeature type is set to the Property 's type. Up to this point CreateGetterForeignTypeand CreateSetterForeignType are absolutely identical, thus no separate explanationof CreateSetterForeignType is needed so far.

The rules CreateGetterForeignType and CreateSetterForeignType only varyin the RHS pattern as follows:

CreateGetterForeignType: The name of the Operation is composed using the methodRefUtil.getter(propName, typeName), which is a proprietary development. It gen-erates the getter method for a Property by using �get� or �is� (according to theProperty 's type) as pre�x and the name of the Property starting with an uppercaseletter as su�x (just like Eclipse does it when applying Encapsulate Field). Thevisibility is set to vis which was set while matching LHS and model to the visibilityof the Property. The structural feature direction of the newly created Parameteris set to ParameterDirectionKind.RETURN_LITERAL which indicates that this Parameteris passed as a return value back to the caller of the Operation (cf. Figure 4.2).

CreateSetterForeignType: Here the Operation is also con�gured by structural featuresname and visibility where the visibility is set just like above. The name is com-posed using RefUtil.setter(propName) which uses �set� as pre�x and the name ofthe Property starting with an uppercase letter as su�x. Since the direction ofthe Parameter is set to ParameterDirectionKind.IN_LITERAL, which means that theOperation needs an argument, the name of Parameter is set to propName (cf.Figure 4.3).

These two rules are applied not more than once each because the second NAC �get-ter/setter already exists� avoids an application of the rule, if the Operation was alreadycreated or existed before. They are placed in the same layer because of their similarities.

The same mechanisms are used in the next layer which also consists of two rules,CreateGetterClassIsType (cf. Figure 4.4) and CreateSetterClassIsType (cf. Fig-ure 4.5), creating getter and setter Operations. The di�erence to the previous layer isthat here Class and Type are one and the same object. Yes, we really need separaterules for this because each matching for the LHS found by EMFTrans is a Vector1 con-taining pairwise distinct elements and therefore Class and Type in the previous layercannot be one and the same element. Figures 4.4 and 4.5 only show LHS and RHSof CreateGetterClassIsType and CreateSetterClassIsType because the NACs donot di�er from the NACs in the previous layer.

20


Figure 4.3: Hide Property: RHS of CreateSetterForeignType

The creation of getters and setters could, on the one hand, be placed in separatelayers and on the other hand, all four rules could be placed in one and the same layer.I decided for two layers because this way the two layers are mutually exclusive becauseClass and Type can either be one and the same or not.Finally, the visibility of the Property is changed to private by applying the ruleMake-

PropertyPrivate As described above this Property is uniquely speci�ed and, accordingto the NAC �property is private�, the rule is applied once at the most. All in all therefactoring Hide Property terminates and really does what it is supposed to do.As mentioned above, the creation of getters and setters could be placed in one single

layer. MakePropertyPrivate on the contrary, must be placed in a higher, hencesubsequently applied layer, because a private Property prevents the rules for the creationof getters and setters from being applied.

1java.util.Vector

21


Figure 4.4: Hide Property: Rule creating a getter for a property where Class and Typeare one and the same object (without NACs)

Figure 4.5: Hide Property: Rule creating a setter for the property where Class and Typeare one and the same object (without NACs)

Figure 4.6: Hide Property: Set the visibility to private

22


4.2.2 New refactorings for new languages

Unfortunately the approach of pulling up refactorings from code level to model level isnot the only case because most models do not reveal that close relation to the sourcecode. With a new metamodel some kind of new programming language is created andtherefore needs its own refactorings. A comparison of Java and C illustrates the needof own refactorings very clearly. Of course, some refactorings like Rename . . . are rea-sonable in both programming languages but the internal refactoring procedure di�ers.Other refactorings are reasonable in Java but have absolutely no usage in C. Exam-ples for this are object-related refactorings like Hide / Show Property and refactoringsconcerning the inheritance like Pull Up / Push Down Property since C is not objectoriented.

Example: Move Class in Ecore and UML

The following is an example of a refactoring which is applicable to instance models ofdi�erent metamodels. Ecore and UML class diagrams have much in common, thus itwas possible to �nd a refactoring suitable for both metamodels. Move Class generallymoves a class (whatever that is) from one container to another container. Ecore callsthese objects EClass and EPackage and in UML they are named Class and Package.In fact EClass and Class have syntactically nothing in common but being an EObject,which applies to every object in an instance model of on an EMF based metamodel. Wehave to design Move Class twice, once for every metamodel. To distinguish betweenthem the Ecore refactoring is called Move EClass and the UML refactoring Move Class.

The refactoring Move EClass in Figure 4.7 matches two EPackages and one EClassto the model to transform where the structural feature name of each object is set to theaccording input parameter. Since the name is not a unique identi�er, there are severalmatchings possible. The two NACs ensure that for one thing the target EPackage doesnot already contain an EClass with the same name as the EClass to move and for anotherthing there is no other EPackage with the same name in the model to transform.

The actual transformation removes the EClass from the containment relation eClas-si�ers in the source EPackage and adds it to the eClassi�ers in the target EPackage.Since the structural feature ePackage is the opposite of eClassi�ers it is changed auto-matically.

Move Class looks and works very similar as illustrated in Figure 4.8. Of course,it di�ers in the used objects but semantically Class and Package are closely related toEClass and EPackage. Although the two refactorings are quite similar there is obviouslyone NAC less and the Packages are referenced by their quali�edName. The second NACis missing just because quali�edNames should be unique in a model.

To keep this example clear I did not mention the visibility in UML. Moving a Classcan change the external behaviour because a Property or an Operation may becomeinvisible for another class. This is a semantic di�erence between Move EClass andMove Class because Ecore does not respect the visibility of objects at all.

23


Figure 4.7: Move EClass (Ecore): Moving an EClass to another EPackage

Figure 4.8: Move Class (UML): Moving a Class to another Package

Example: Create Superclass - suitable or not?

In an UML model the creation of superclasses surely makes sense. But when you takea look at the example of a library in Section 3 you cannot �nd any need of such arefactoring because the library metamodel does not consider any kind of inheritance.The other way round the refactoring Move Books introduced in the same chapter wouldmake no sense in UML although it is quite similar to the above-mentioned refactoringMove Class.

These are examples of refactorings which only make sense for certain models or certainclasses of models which hopefully emphasizes that every new metamodel needs its ownset of refactorings. Perhaps some refactorings can be adopted from code or other existingmetamodels but generally they have to be newly created.

24

4.3 UML refactorings


The following section is based on a still unpublished UML refactoring catalog [27] com-piled by our workgroup containing a huge set of UML class diagram refactorings andUML state machine refactorings. Refactorings are divided into basic and complex refac-torings and each refactoring is described very brie�y.For each refactoring we collected the following information:

• the inverse refactoring,• needed input parameters,• preconditions and postconditions to meet,• and strategies for implementing the refactoring.

Additionally, each refactoring is usually elucidated and illustrated by an example.Class diagram refactorings are mainly extracted from literature and completed by

other useful refactorings, most of them adopted from code refactorings. Some basicrefactorings are mentioned in the next paragraphs because afterwards I will explain howto compose a complex refactoring out of them.

4.3.1 Basic UML refactorings

A basic refactoring in the UML refactoring catalog is supposed to be atomic, i. e. itcannot be composed out of other refactorings, hence, causing only a few changes to themodel. On the contrary a complex refactoring usually is composed of basic refactoringsand causes numerous changes to the model. This course of action ensures, that everyrefactoring composed of others is automatically preserving the external behaviour and,hence, actually is a refactoring.

Create Superclass

The �rst refactoring is called Create Superclass which creates a new superclass for severalclasses. It needs the following input parameters for execution:

• A list of classes to extract the superclass from• The quali�ed name of the new superclass• The visibility of the new superclass

The refactoring has to check that the list of classes is not empty and that the newsuperclass must not exist. When these preconditions are met, the new class, if notexistent, and the inheritance relation between the superclass and all classes in the listare created. In case of creating an interface instead of a superclass, the kind of relationis changed from inherit to implement.

Pull Up Property

The next refactoring is called Pull Up Property which moves a property one level upwardsin the inheritance hierarchy. It needs the following input parameters for execution:

• The name of the property we want to pull up to from all subclasses to a commonsuperclass

• The quali�ed name of the superclass

25


Before the refactoring can be applied, it has to check whether the property really existsin all subclasses and is not already contained in the superclass. If these checks aresuccessful the refactoring moves the property from any subclass into the superclass andremoves the property in all other subclasses. The property's visibility is set to themaximum visibility of the properties in all subclasses but at least to protected. Sincethe visibility in UML2 is not totally ordered, the maximum of protected and packagedis public. After these changes the property must be visible in all subclasses but noneof the subclasses may contain the property anymore. In this refactoring superclass andinterface can also be exchanged.

Pull Up Operation

The last refactoring I want to introduce here is Pull Up Operation, which is quite similarto Pull Up Property but a class may contain several operations having the same name.They are distinguished from each other with the aid of their signatures. But the signa-ture of an operation is not stored in the object itself but is derived from its children.Therefore Pull Up Operation needs to pull a whole branch up the inheritance hierarchy.Nevertheless, the parameters used for execution is quite similar:

• The signature of the operation we want to pull up to from all subclasses to acommon superclass

• The quali�ed name of the superclass

There are also a few preconditions to check before applying the refactoring, in particularall subclasses must contain the operation and an operation with the same signature mustnot be visible in any kind in the superclass except it is also visible in all subclasses.Meeting this preconditions the refactoring is applied by moving the operation fromany subclass into the superclass and deleting it in all other subclasses. Probably thevisibility has to be changed just like it is done in Pull Up Property. Like the other tworefactorings, Pull Up Operation is also applicable to interfaces.

4.3.2 Extract Superclass

On the basis of the three basic refactorings we are able to compose a new complex refac-toring. By the order in which they are presented one may guess that the new complexrefactoring will create a new superclass or interface for a set of classes or interfaces andthen pull up several properties and operations; it is called Extract Superclass.

Extract Superclass summarises common features of several classes and places them ina newly created superclass in a way that all classes can access these features to avoidredundancies. At �rst Create Superclass is applied to a set of classes and then to eachproperty and each operation, we want to pull up, the according refactoring is applied.The resulting input parameters are the elements of a set union of all input parame-ters of the basic refactorings. Extract Superclass does not need to meet any additionalpreconditions and even not all preconditions required for the basic refactorings. SinceCreate Superclass is the �rst basic refactoring to apply, all preconditions of Create Super-class need to be met, but the preconditions of Pull Up Property and Pull Up Operationwhich check whether the property or the operation is contained in the superclass, may

26


be dropped out because we created an empty superclass. But all remaining precondi-tions have to be veri�ed before the application of the �rst basic refactoring. After therefactoring the postconditions of all three basic refactorings must be veri�ed.There are many other basic and complex refactorings for class diagrams as well as

state machines compiled in the refactoring catalog. This short extract should onlygive a short overview of the actual development of UML2 refactorings. This catalogis not meant to contain any implementations of refactorings but strategies to give therefactoring designer a helping hand.

27

5 Requirements

This chapter describes the initial requirements as well as the requirements which emergedduring developing the EMF Refactoring Plug-in because I chose the agile software de-veloping methodology of eXtreme Programming. It is separated into functional andnon-functional requirements. Non-functional requirements are not concerned to anyfunctions of software system but declare system properties, constraints, data represen-tation, etc. On the contrary, functional requirements describe what a software systemactually is supposed to do [28]. In this concrete case I will separate them into two dif-ferent roles. For one thing there is a refactoring designer who de�nes model refactoringsfor speci�c metamodels and for another thing there is the model designer manipulatingan instance model with model refactorings.

5.1 Non-functional requirements

As mentioned in several previous chapters and indicated by its name, the EMF Refac-torings Plug-in should be designed as an Eclipse plug-in using Java as programminglanguage. Here, being an Eclipse plug-in means to serve several extension points inorder to extend the UI by model refactoring facilities as similar as possible to coderefactorings provided by the Java Development Tools (JDT). The plug-in should pro-vide model refactoring facilities to every EMF based model, which implies a certainmetamodel independence. Of course, a model refactoring is based on a certain meta-model and is therefore only applicable to such instance models, but in general it shouldbe possible to generate model refactorings for any kind of EMF based model and applythem to according instance models. A model refactoring should use the plug-ins men-tioned in Section 3 for transforming and comparing EMF based model instances. Themodel refactoring itself should be con�gured as a plug-in in order to be exchangeableand highly extensible using a new extension point for model refactorings.

Each model refactoring must check whether it is applicable or not, including the veri-�cation that the external behaviour is preserved. Each model refactoring designer mustaccept full responsibility for the correct behaviour of the designed model refactoring.This comprises checking whether it is applicable or not, including the veri�cation thatthe external behaviour is preserved. Incidentally, this veri�cation is a very complex taskand hence, it should be possible to automatically test model refactorings, for exampleusing JUnit.

5.2 Functional requirements

The functional requirements brie�y describe the services to provide and how the systemshould react to particular input or in particular situations. In the following I will

29

5 Requirements

describe two di�erent types of customers requiring di�erent services. On the one handthere is the model developer who wants to apply refactorings to his model and on theother hand there is the model refactoring designer who wants to de�ne new refactoringsfor a certain metamodels.

5.2.1 Refactoring EMF models

The application of a model refactoring to an instance model should be as similar aspossible to code refactorings. Therefore he should open the model in a common editor,select at least one element from his model, and choose a refactoring from a list ofprobably applicable model refactorings. In case of necessary user input, a wizard shouldpop up awaiting the model developer to set these parameters. Thereafter a secondwizard should show a comparison between the original model refactoring and the resultof applying the chosen model refactoring. Finally, the model developer should be askedto either apply the model refactoring to his model, which saves exactly the model shownin the comparison, or to cancel the model refactoring which does not change the originalmodel at all.

5.2.2 Create EMF refactoring

A refactoring designer should use the EMF Transformation framework in order to de-sign new model refactorings. The refactoring designer must guarantee all refactoringcharacteristics because there are no veri�cation mechanisms scheduled, yet. To gener-ate a new model refactoring from the designed transformation, the refactoring designerneeds to con�gure how the parameters of the model refactoring are set. This shouldbe done by using a wizard awaiting settings like the kind of objects the model refac-toring is applicable to and which parameters have to be set additionally by the user.A model refactoring generator should then create a model refactoring plug-in providingthe designed model transformation without any further implementation necessary.

30

6 The EMF Refactoring Plug-in

This is the most important chapter of this thesis because it actually describes the devel-oped software. At �rst I will explain which software development method I chose andwhy, secondly I will describe the design of the plug-in. The remaining chapter deals withfurther details about the actual implementation of the EMF Refactoring Plug-in itselfas well as the implementation of a generated model refactoring plug-ins respectively thetemplates used for generation.

6.1 Agile software development

When I started developing the EMF Refactoring Plug-in I could orientate myself toan existing prototype for UML refactorings. But this prototype de�ned its own editorwhich was not suitable because it is highly probable that developers would not use aspecial editor just for applying refactorings. Because in the beginning there was onlythe requirement to develop a model refactoring plug-in for EMF based models, I chosean agile software development method, namely eXtreme Programming (XP) [29]. Usingthis method enabled me to easily determine and readjust the requirements. I began withextending the editor, generated by EMF, with a model refactoring facility. The core ofthese early model refactorings was already automatically generated by EMFTrans butthe classes to integrate them into the UI were implemented by hand. The requirementof automatically generating the UI integration emerged, whereupon I started imple-menting an extended generator for transformations designed with EMFTrans. Here,too, new requirements emerged gradually from discussions in our workgroup (e.g. sup-port primitive types in UML), from designing new refactorings (e.g. the copy functionin transformations in Section 7.3), and from things I worked out in my head (e.g. tomaintain distributed models).

While integrating new improvements to generated model refactorings, the resultingcode messed up gradually so there was a need for refactorings. Eclipse respectively theJava Development Tools provide great refactoring facilities which was used for refactor-ing the generated model refactorings. But these refactorings had to be transferred tothe code templates used for generation, which had to be done by hand.

If I had chosen no agile software development method I might not have been ableto quickly react on changing requirements like I did during this thesis. Additionally Ithink that a sequential development process, for instance the waterfall model, wouldhave broken the time frame of six month for this thesis.

31


6.2 Design

To my mind, modeling is the next generation of software development and therefore Itried to transfer the behaviour of code refactorings to the level of model refactorings.Users being familiar with Eclipse surely know the code refactoring facilities provided byEclipse. Since model refactorings show similarities to code refactorings, they should behandled in a similar way. When you open a Java source �le, the menu and the contextmenu are both extended by a new submenu labeled �Refactor� providing all appropriatecode refactorings according to the current selection. Choosing a refactoring usuallycauses the opening of a wizard where you can enter additional parameters and chooseeither �OK� or �Preview�. The preview opens an editor showing the di�erence betweenthe original source code and the refactored version.

Although we focused on developing new refactorings for the EMF UML2 metamodel,the EMF Refactoring Plug-in can handle every EMF based model, i. e. it brings modelrefactorings to the graphical user interface of Eclipse. We need the editor code generatedby EMF, which is able to display instance models of a certain metamodel. All objectsdisplayed by this editor implement the interface EObject in some way. To extend thecontext menu of each object displayed in a generated model editor by a new submenu�Model Refactoring�, it is su�cient to extend the context menu of EObject. This isachieved by serving the extension point org.eclipse.ui.popupMenus and using anobjectContribution (cf. Section 6.3.1), which adds a new entry to the contextmenu of objects of a certain type.

This indicates a closer relation between model refactorings and certain model objects,whereas code refactorings refer to textual selections in general. Applying a model refac-toring requires the selection of an object of a speci�c type. This type gives us the abilityto dynamically adapt the context menu to show appropriate model refactorings only.Please note that this does not mean that the o�ered refactorings are always applicableto this speci�c object because the refactoring designer may specify other preconditions,e.g. moving an attribute to another class already providing an equally named attributeis forbidden. Such preconditions may depend on both the model itself and user input,which are only available at runtime, so these preconditions can only be evaluated atruntime as well.

In order to apply a refactoring certain parameters may be needed. Some are deter-mined by the selected model element and its context, some cannot and must be de�nedby the model designer. Therefore the model designer is supported by dedicated wiz-ards for entering additional parameters using text�eds or drop-down menus. Since therefactoring designer knows best about the required parameters, each wizard is part ofits model refactoring plug-in.

If all information according to a speci�c refactoring are available, it can be applied tothe loaded model. In order to give the user the opportunity to cancel the application,the refactored model is compared to the original model stored in the �le system. Thecomparison of the two models is shown using EMF Compare [17] and while actuallyseeing the di�erences in a neatly arranged viewer the user can decide whether to applythe refactoring or keep the original model.

32

6.3 Realisation

6.3 Realisation

In Eclipse terminology a feature is an installation unit subsuming several related plug-ins [30]. The EMF Refactoring Plug-in is, strictly speaking, a feature subsuming theplug-ins

• de.unimarburg.refactoring.emtextension (abbr.: emtextension),

• de.unimarburg.refactoring.menu (abbr.: menu), and

• de.unimarburg.refactoring.util (abbr.: util).

This section describes the extensions points used to provide EMF refactoring facilitiesand the implementation of most classes implemented in these three plug-ins and forconvenience I will use the abbreviations in braces for the three plug-ins.

6.3.1 Extension point: org.eclipse.ui.popupMenus

This extension point is served to extend the context menu of a speci�c element or viewby new actions. An action is an event triggered by the end user and is usually associatedwith buttons, menu items, or items in toolbars. Contributing new actions to a speci�c el-ement is done with an objectContribution whose document type de�nition is shownin Figure 6.1. An objectContribution causes the label of the new action to appearin the context menu of every object implementing or extending the type de�ned by theattribute objectClass. When several objects are selected, the action is only contributedif a common supertype matches the given type. In other words, every selected elementmust match the type de�ned by objectClass. Since EObject1 is the common supertype ofall EMF based model elements, the plug-in menu contributes a new menu labeled �ModelRefactoring� to the context menu of every EObject. The unique attribute id is used to re-fer to this contribution and set to de.unimarburg.refactoring.menu.contributions.EOject.Further constraints can be de�ned by optional attributes like nameFilter and adapt-able but their explanation is left out because they are not used by the EMF RefactoringPlug-in or any generated model refactoring.

1 <!ELEMENT objectContribution (filter* , visibility? , enablement? ,

2 menu* , action *)>

3 <!ATTLIST objectContribution

4 id CDATA #REQUIRED

5 objectClass CDATA #REQUIRED

6 nameFilter CDATA #IMPLIED

7 adaptable (true | false) "false">

Figure 6.1: Document Type De�nition of objectContribution

In contrast to an objectContribution, using viewerContribution adds thenew action to the context menu of to the speci�ed view or editor part regardless ofthe selected element. Such a viewerContribution contains the attributes id, likeobjectContribution, and targetID which is used to identify the view part wherethe action shall be available.

1org.eclipse.emf.ecore.EObject

33


As depicted in Figure 6.2, the plugin.xml of menu uses an objectContribution

to add a new submenu to the context menu of every EObject. This new submenu is refer-enced by the unique id de.unimarburg.refactoring.menu.ModelRefactoring and labelledModel Refactoring. The attribute path is set to edit (just like the code refactoringmenu) de�ning the position in the existing context menu.

A separator is used to partition the submenu into certain areas or groups. Eachgenerated model refactoring is added to the submenu using a separator in order togroup similar model refactorings. Since there are just a few model refactorings designedby now, there exists only a single group referenced by refactorings. Using this separa-tor, a new model refactoring is added to the submenu setting the menubarPath ofthe action to de.unimarburg.refactoring.menu.ModelRefactoring/refactorings. In futureversions it may be meaningful to create a few more separators to aggregate similarrefactorings like it is done in the plug-in org.eclipse.jdt.ui.

1 <?xml version="1.0" encoding="UTF -8"?>

2 <?eclipse version="3.4"?>

3 <plugin >

4 <extension -point

5 id="modelRefactorings"

6 name="Model Refactorings"

7 schema="schema/modelRefactorings.exsd"/>

8 <extension

9 point="org.eclipse.ui.popupMenus">

10 <objectContribution

11 id="de.unimarburg.refactoring.menu.contributions.EOject"

12 objectClass="org.eclipse.emf.ecore.EObject">

13 <menu

14 id="de.unimarburg.refactoring.menu.ModelRefactoring"

15 label="Model Refactoring"

16 path="edit">

17 <separator

18 name="refactorings">

19 </separator >

20 </menu>

21 </objectContribution >

22 </extension >

23 </plugin >

Figure 6.2: plugin.xml of the plug-in menu de�ning the context menu entry �ModelRefactoring�

6.3.2 Extension point: org.eclipse.ui.actionSets

The extension point org.eclipse.ui.actionSets is used for de�ning a group of actionsand/or menus. There are two required attributes of an actionSet namely the idwhich is a unique identi�er and the label representing the actionSet to the user. Theattributes visible and description are optional (cf. Figure 6.3).

The plug-in emtextension donates an additional button to the toolbar by de�ningan action set including a single action as depicted in Figure 6.4. The attribute class

34

6.3 Realisation

1 <!ELEMENT actionSet (menu* , action *)>

2 <!ATTLIST actionSet

3 id CDATA #REQUIRED

4 label CDATA #REQUIRED

5 visible (true | false)

6 description CDATA #IMPLIED >

Figure 6.3: Document Type De�nition of actionSet

awaits the full quali�ed name of a class implementing IWorkbenchWindowActionDelegate2.The attribute icon declares the path of the icon to use in the toolbar. This path isrelative to the project's root folder. The id is a unique reference to this action and thevalue of the attribute tooltip appears when pointing with the mouse on the icon ina hovering box. The toolbarPath places the icon in a speci�c group which is, if notexistent, newly created.

1 <plugin >

2 <extension

3 point="de.tuberlin.emt.gui.othercontextmenuentries">

4 <OtherContextMenuEntries

5 class="de.unimarburg.refactoring.emtextension.generator.actions

6 .GenerateRefactoringAction"/>

7 </extension >

8 <extension

9 point="org.eclipse.ui.actionSets">

10 <actionSet

11 id="de.unimarburg.refactoring.emtextension.actionSet"

12 label="Model Refactoring Action Set">

13 <action

14 class="de.unimarburg.refactoring.emtextension.generator.actions

15 .AutomatedEMFRefactoringGenerationAction"

16 icon="icons/refactoring16x16.png"

17 id="de.unimarburg.refactoring.emtextension.generator.actions

18 .EMFRefactoringGenerationAction"

19 toolbarPath="modelRefactoringGroup"

20 tooltip="Generate EMF Model Refactorings from XML File">

21 </action >

22 </actionSet >

23 </extension >

24 </plugin >

Figure 6.4: plugin.xml of the plug-in emtextension serving two di�erent extensionpoints (the additional line breaks inside the value of attributes would cause errors andare only added for smoothly displaying this �le)

A brief description of the implementation of AutomatedEMFRefactoringGenerationAction

stated in the de�nition of the action is located in Section 6.5.2.

2org.eclipse.ui.IWorkbenchWindowActionDelegate

35


6.3.3 Extending the generator of EMFTrans

Every created refactoring makes intensive use of the transformation code generated byEMFTrans. But this transformation code is only programmatically usable and since arefactoring is applied in the user interface, a few additional classes are necessary. Tofacilitate the generation of code beyond transformation code I de�ned a new extensionpoint for EMFTrans which is integrated in the current version3. This extension pointsimply adds an entry for each extension to the context menu of a rule.For the convenience of the reader, Figure 6.5 shows an Eclipse screenshot of the

extension point speci�cation instead of the comprehensive textual description.

Figure 6.5: Extension point schema for othercontextmenuentries

The plugin.xml of the plug-in emtextension serves this newly created extensionpoint as shown in Figure 6.4 and therefore supplies a new entry to context menuof a rule. The only necessary attribute is class, whose value must be a class ex-tending AbstractEditorAction4. The label of this new entry must be de�ned using themethod Action#setText(String), so the development team of EMFTrans should thinkabout adding a second attribute specifying the label of the new context menu entry.

6.4 Implementation of the EMF Refactoring Plug-in

All three plug-ins subsumed in the EMF Refactoring Plug-in are singletons, which meansthat there can be one instance of each at the most. The instance of each plug-inis represented by and stored in the particular Activator (menu and util) respectivelyCustomGeneratorPlugin (emtextension) which are all subclasses of AbstractUIPlugin5 (cf.Figure 6.6 and Figure 6.7). One cannot create a new instance of a plug-in because thereare no public constructors. The static method getDefault() is de�ned in each of thethree classes returning the particular instance.Previous chapters distinguished the application and the generation of model refactor-

ings. The latter is implemented in the plug-in emtextension only but the application

3I want to thank the development team of the EMF Transformation Project for integrating thisextension point so quickly.

4de.tuberlin.emt.gui.actions.AbstractEditorAction5org.eclipse.ui.plugin.AbstractUIPlugin

36


Figure 6.6: The classCustomGeneratorPlugin contains theinstance of emtextension

Figure 6.7: The class Activator looksidentical in menu and util

of refactorings is distributed among several plug-ins because on the one hand the modelrefactoring itself is applied by the generated plug-in, but on the other hand there areseveral common methods and classes located in the plug-ins menu and util. The gen-erated model refactorings are explained in Section 6.5.3 whereas the following sectionexplains which common classes are used during the model refactoring application.

6.4.1 Application of model refactorings

The �rst common class used during model refactoring application is Utils6 providing themethod addReferencedObjectsToCombo(...) which is used by a generated model refactor-ing plug-in while creating the RefactoringWizardPage for automatically �lling drop-downmenus with particular object representations.

The StringConverter7 is used for converting strings from text �elds and drop-downmenus to Java objects with respect to a given EMF type.

After �nishing the wizard a WizardLogger8 can be used for storing all user input inan xml �le. This xml �le can later be used to automatically apply a refactoring withexactly these parameters automatically, e.g. in JUnit tests.

A LimitedBuffer9 is used in the generated transformation code to record the last nnames of applied rules. If a transformation is stuck in an in�nity loop, the user isinformed by a MessageDialog displaying the names of the last n applied rules which canthen be used to debug the model refactoring design.

Refactoring UML models

Since we mainly focused on designing refactorings for the EMF UML2 metamodel werevealed that certain conditions are not de�nable using EMFTrans only, e.g. to com-pare signatures of operations. The class RefUtil10 was implemented for this purposebut also for generating names for setter and getter, because the latter is di�erent for

6de.unimarburg.refactoring.menu.util.Utils7de.unimarburg.refactoring.util.StringConverter8de.unimarburg.refactoring.util.WizardLogger9de.unimarburg.refactoring.util.LimitedBuffer

10de.unimarburg.refactoring.util.uml2.RefUtil

37


boolean variables, and for computing the maximum visibility. This is necessary becausevisibilities in UML are only partially ordered.

JUnit testing

For testing model refactorings using JUnit I developed a ModelManager11 providing au-tomatically loading a model, comparing two models to each other, and storing thedi�erences in an emfdi� �le.

6.4.2 Generating new model refactorings

Generally, the plug-in emtextension it is an extension of the existing generator inEMFTrans, which uses Java Emitter Templates (JET) [31] to generate Java classesfrom transformations. Figure 6.4.2 illustrates the general functioning of Java EmitterTemplates. The JET compiler uses templates and optionally skeletons and compilestemplate classes into the .JETEmitters project. The default skeleton, which is usedwhen no other is declared, simply creates a class with a single method generate(Object).This method returns a String object, which is �nally written into the generated java�les. It is possible to customize the template classes with skeletons, but neither theEMFTrans generator nor the model refactoring generator use skeletons.

Figure 6.8: Code generation with JET

The plugin.xml in Figure 6.4 depicts the de�nition of a new entry in the con-text menu of a rule by serving the extension point othercontextmenuentries. HereGenerateRefactoringAction12 is declared as the action to be �red which starts the genera-tion process by creating and opening a GenerateRefactoringWizard13. This wizard awaitsuser input and after �nishing the wizard the actual generation process is started usinga CustomGenerator14. Figure 6.9 shows a class diagram generated with Ecore Tools, togive an overview of the most important classes during the generation process.

11de.unimarburg.refactoring.util.uml.ModelManager12de.unimarburg.refactoring.emtextension.generator.actions.GenerateRefactoringAction13de.unimarburg.refactoring.emtextension.generator.wizard.GenerateRefactoringWizard14de.unimarburg.refactoring.emtextension.generator.CustomGenerator

38


Figure 6.9: A class diagram showing an extract from emtextension concerning the theCustomGenerator and referenced classes

39


The main class here is CustomGenerator which controls the whole generation process.Therefore it needs certain parameters given during instantiation. The CustomGenerator

is adopted from the Generator15 implemented in EMFTrans but it does not extend itbecause the class Generator is not designed to be subclassed. The CustomGenerator refer-ences two classes containing data for parsing and assembling templates: PluginDataExt16

and TransformationDataExt17. The class PluginDataExt is used for creating the manifest�les, namely plugin.xml, build.properties, andMANIFEST.MF. Therefore it pro-vides all information stored in its superclass PluginData18 and additionally informationabout the transformation in its entirety like the name of the created project, the packagestructure, and the description of the transformation. The class TransformationDataExt isused for assembling Java source code and provides all information from its superclassTransformationData19. Additionally, TransformationDataExt provides the settings made inthe generation wizard to con�gure the input parameters of the transformation and storesthem in an object �eld of type Properties20. An instance of Properties contains all in-put parameters and the according con�guration made in the generation wizard. Theyare stored in a HashMap and the input parameter names are used as keys. Every inputparameter is herewith stored only once, regardless of how many rules contain this in-put parameter. On page 46 in Section 6.5.3 is a brief description of this workaroundproviding transformation-wide input parameters.

At last I had to extend the JETGateway21 of EMFTrans by JETGatewayExt22 in orderto add additional dependencies to the .JETEmitters project, which is created duringgenerating a model refactoring plug-in. The templates used in the EMF RefactoringPlug-in refer to PluginDataExt and TransformationDataExt and therefore it is necessary toadd a new dependency on the plug-in emtextension to the .JETEmitters project.The second task for the JETGateway is to transform the newly generated java project intoa plug-in project because every model refactoring is intended to be a plug-in. This keepsthe EMF Refactoring Plug-in highly extensible with regard to new model refactorings.

6.5 The source code

This chapter investigates the inner life of the EMF Refactoring Plug-in as well as theinner life of a generated model refactoring plug-in by means of source code and JETtemplates.

The EMF Refactoring plug-in extends the context menu in the graphical editor foremt �les with an entry called �Generate Refactoring� (cf. Section 6.3.3). Clicking on thisentry starts the generation process of a model refactoring which is brie�y explained inSection 6.5.1. Furthermore the toolbar is extended by a new button (cf. Section 6.3.2) forstarting the generation of several model refactorings plug-ins from di�erent refactoring

15de.tuberlin.emt.generator.Generator16de.unimarburg.refactoring.emtextension.generator.data.PluginDataExt17de.unimarburg.refactoring.emtextension.generator.data.TransformationDataExt18de.tuberlin.emt.generator.data.PluginData19de.tuberlin.emt.generator.data.TransformationData20de.unimarburg.refactoring.emtextension.generator.Properties21de.tuberlin.emt.generator.jet.JETGateway22de.unimarburg.refactoring.emtextension.generator.jet.JETGatewayExt

40

6.5 The source code

de�nitions (emt �les) at once. The internals are revealed in Section 6.5.2.At last there is the application of generated model refactorings. Section 6.5.3 explains

the code generation using the templates and how the generated code works when a modelrefactoring is applied.

6.5.1 Generate refactoring

If you choose �Generate Refactoring� from the context menu of a rule, the methodAbstractEditorAction#run() is invoked to check that the active editor is an instance ofEditor23 and that this editor is neither disposed nor corrupt. After these checks theabstract method AbstractEditorAction#execute(Editor) is invoked which is implementedin the concrete subclass GenerateRefactoringAction as illustrated in Figure 6.10. Themethod GenerateRefactoringWizard#execute(Editor) creates a new instance of the classGenerateRefactoringWizard and opens it via a WizardDialog (lines 31 and 39). CallingWizardDialog#create() (line 40) creates a new window containing the wizard and its con-tents. For content creation the WizardDialog calls the method IWizard#addPages() which is�nally implemented in GenerateRefactoringWizard. This methods adds two pages, �rstlya WizardNewProjectCreationPage and secondly a GenerateRuleProjectPropertyWizardPage toset all other refactoring properties, to the wizard. Finally WizardDialog#open() (line 45)opens the window containing the wizard.

33 public void execute(Editor editor) {

34 GenerateRuleProjectWizard wizard = new GenerateRefactoringWizard(

35 editor.getModelManager ());

36 wizard.setForcePreviousAndNextButtons(false);

37 wizard.setWindowTitle("Generator");

38 // creates a WizardDialog ...

39 IWorkbench workbench = PlatformUI.getWorkbench ();

40 Shell parent = workbench.getActiveWorkbenchWindow (). getShell ();

41 WizardDialog dialog = new WizardDialog(parent , wizard );

42 dialog.create ();

43 // ... sets help ...

44 workbench.getHelpSystem (). setHelp(dialog.getShell(),

45 CustomGeneratorPlugin.ID + ".new_wizard_context");

46 // ... and opens it.

47 if (Window.OK == dialog.open ()) {

48 }

49 }

Figure 6.10: Implementation of GenerateRefactoringAction#execute(Editor)

After con�guring the refactoring you have to click on �Finish�. This executes themethod IWizard#performFinish() which is implemented in GenerateRuleProjectWizard. Thisimplementation creates a new thread for the generation process. More precisely, anew WorkspaceModifyOperation is de�ned which is used for the invocation of the methodWizardDialog#run(boolean, boolean, IRunnableWithProgress). This runs the newly de�nedWorkspaceModifyOperation in a modal context and does nothing but executing the methodGenerateRuleProjectWizard#doFinish(IProject, IProgressMonitor) (cf. Figure 6.11)

23de.tuberlin.emt.gui.editor.Editor

41


57 protected void doFinish(IProject project , IProgressMonitor monitor)

58 throws CoreException {

59 NullProgressMonitor nullMonitor = new NullProgressMonitor ();

60 // create a sample file

61 if (! project.exists ()) {

62 project.create(nullMonitor );

63 project.open(null);

64 }

65 // Delete .JetEmitters project

66 try {

67 IWorkspaceRoot root = ResourcesPlugin.getWorkspace (). getRoot ();

68 IResource r = root.findMember(".JETEmitters");

69 if (r != null)

70 r.delete(false , nullMonitor );

71 } catch (CoreException e) {

72 } catch (Exception e) {

73 }

74 // Start generator

75 monitor.beginTask("Generating Refactoring", 1);

76 CustomGenerator generator = new CustomGenerator(emtModelManager ,

77 project.getName(), propertyPage.getProperties ());

78 generator.start(monitor );

79 }

Figure 6.11: GenerateRuleProjectWizard#doFinish(IProject, IProgressMonitor) rede�ned inGenerateRefactoringWizard

The �rst parameter of GenerateRefactoringWizard#doFinish(IProject, IProgressMonitor)

is a project handle for the project to generate. If that project does not exist, a newproject in the default location is created and opened, and otherwise the existent projectis taken for storing all generated �les. After that a new CustomGenerator is createdand the generation process is started (lines 76-78). All existing �les are overriddenexcept the custom wrapper classes because these are programmed by hand and notautomatically generated. I used two di�erent IProgressMonitor because the creation ofthe Java project and the feature project together take insigni�cant time in relation tothe whole generation process. Thus the parameter IProgressMonitor monitor which isused for the progress bar is only delegated to the generation of manifest and sourcecode �les. The other operations are executed using a NullProgressMonitor to suppressany kind of progress information.As already mentioned above, the process of generating refactorings or rather the

method CustomGenerator#start(IProgressMonitor) is partitioned into generating

• a java project (createProject(nullMonitor)),• manifest �les (generateManifest(subMonitor)),• source code (generateRuleClasses(subMonitor)), and• a feature project (createFeatureProject(nullMonitor)).

Since the project resource was created before, the creation of the java project is rathera con�guration of a java plug-in project which includes adding a java nature, addinga plug-in nature, con�guring the output and source directory, and adding classpaths.The next step is to generate the manifest �les which is followed by the generation of the

42

6.5 The source code

source code including

• a rule class, a wrapper class, and a custom wrapper class for each rule,• the transformation class applying all rules with respect to their layers,• a JUnit test case class,• a wizard and a wizard page, and• an action for the context menu.

At last a feature project is created to export this refactoring as a deployable featureeither for exporting it using the Eclipse exporter or for deploying it on an update site.Finally I should mention that canceling the wizard invokes IWizard#performCancel()

which is neither implemented in the class GenerateRuleProjectWizard nor in the classGenerateRefactoringWizard thus Wizard#performCancel() is executed which does nothingbut returning true.

6.5.2 Automated generation

Since designing refactorings is quite complex, a refactoring has to be tested and ad-justed frequently. Adjusting refactorings always causes a re-generation and to save thedesigners time and nerves the generation of several refactorings can be started by only afew mouse clicks. Installing the plug-in adds a button to the toolbar as it is elaboratedin Section 6.3.2The automatic generation of model refactorings awaits an xml �le containing infor-

mation about the new model refactorings. Therefore I created a new document typede�nition illustrated in Figure 6.12. An xml �le used for automatic generation must con-form to this DTD, which means that at �rst the root element must be named projects.An instance of projects contains any number of importPackage elements and atleast one project element. Both elements must not contain any kind of data butspecify some attributes. An importPackage element is used to import a metamodelused in emt �les. The required attribute uri de�ne the metamodel's location which istested with either by an absolute path using ��le:/� or by a workspace-relative pathusing �platform:/resource/� as pre�x but since these strings are used as an argument forURI.createURI(String)24 you may choose any kind of scheme [15].The class AutomatedEMFRefactoringGenerationAction, stated in the de�nition of the ac-

tion, is executed when pushing the toolbar button. This class implements the interfaceIWorkbenchWindowActionDelegate and since it is not declared abstract it implements thefollowing methods:

• IWorkbenchWindowActionDelegate#dispose(),• IWorkbenchWindowActionDelegate#init(IWorkbenchWindow),• IActionDelegate#selectionChanged(IAction, ISelection), and• IActionDelegate#run(IAction).

The implementation of dispose() is empty because I have no references to the classitself that should be unhooked. The method init(IWorkbenchWindow) is executed onceafter the creation of an object of AutomatedEMFRefactoringGenerationAction and only storesthe given parameter in the object �eld window. When the selected object in the work-bench changes, the method selectionChanged(IAction,ISelection) is invoked to store the

24org.eclipse.emf.common.util.URI

43


1 <!ELEMENT projects (importPackage*, project +)>

23 <!ELEMENT importPackage EMPTY>

4 <!ATTLIST project

5 uri CDATA #REQUIRED

67 <!ELEMENT project EMPTY >

8 <!ATTLIST project

9 emtFileName CDATA #REQUIRED

10 projectName CDATA #REQUIRED

11 xmlFileName CDATA #REQUIRED >

Figure 6.12: Document Type De�nition of an xml �le used to automatically generatemodel refactoring plug-ins

ISelection parameter in another object �eld called selection. Before opening a wizard,this �eld is used to check whether �les usable for automated model refactoring genera-tion are selected. The last method AutomatedEMFRefactoringGenerationAction#run(IAction)

actually starts the automated generation process. At �rst the above-mentioned selection

is checked whether it contains IFiles. If it does, the user is asked whether to use these�les or not. Answering yes starts the transformation process and otherwise, or if theselection does not contain IFiles, a wizard is opened where the user is asked to choosexml �les providing information for automated model refactoring generation.

Assuming we have at least one �le with refactorings to generate, this �le is parsed byAutomatedEMFRefactoringGenerationAction#getProjectsFromXMLFile(IResource). This methodparses an xml �le using DOM and constructs HashMaps with a structure similar to the xmlstructure. For each xml tag project a HashMap is created containing the xml attributesas keys and their values are the attribute's values. The method returns a Vector of allthe created HashMaps.

But the xml �le also contains information about the packages to import. This isfor example the UML2 metamodel. Therefore the xml �le is parsed again withinAutomatedEMFRefactoringGenerationAction#getImportPackagesFromXMLFile(IResource) where aVector of Strings identifying these metamodels is returned.

With these two parameters the generation is ready to start. Since the generation of asingle refactoring takes a couple of seconds, the generation of several refactorings shouldrun in the background in order not to block the whole Eclipse application. Thereforea WorkspaceJob25 is created and scheduled. This WorkspaceJob basically invokes the methodAutomatedEMFRefactoringGenerationAction#create(IProgressMonitor, Vector, Vector) to startthe generation of all refactorings. This method creates a CustomGenerator for each projectwhich is done by createGenerator(...) and starts it. The last remaining question ishow that generator is created. The parameters awaited by this method are as follows:

25org.eclipse.core.resources.WorkspaceJob

44

6.5 The source code

String emtFileName : The URI of the emt �le containing the transformation.String newProjectName : The name of the new project in the workspace.String xmlFileName : The URI of the xml �le containing all the setting

needed for the refactoring generation. Mostly this�le is generated by the button �Export� which isshown while generating a single refactoring.

Vector<String> importPackages : All packages that must be imported in order to openthe emt �le.

With emtFileName and importPackages an EMTModelManager26 is loaded and the xml �lereferenced by xmlFileName is parsed using ImportExportSelectionListener27. This parserreturns an object of Properties28 which is, together with the EMTModelManager and thenewProjectName, used to �nally create a new CustomGenerator. This CustomGenerator is �-nally started by the WorkspaceJob and the generation of a refactoring starts.

6.5.3 Applying a generated model refactoring

After successfully generating a refactoring, exporting and installing the refactoring canbe applied to a certain type of models de�ned during designing the refactoring. In thefollowing I will explain the templates used for code generation and what happens whenthis generated code is applied to a model. The templates are located in the templatesfolder of the plug-in emtextension.

RefactoringAction.javajet

The �rst template to mention, although it is generated at last, is RefactoringAc-tion.javajet. This template creates the class <%=RefactoringName%>Action in the newrefactoring project and is parsed using an instance of TransformationDataExt29 as the ar-gument, with which we can access for one thing all data of the transformation becauseTransformationDataExt inherits from TransformationData30 and for another another thingwe can additionally access all the information con�gured in the wizard during the refac-toring generation (in the following referred to as generation wizard). The resulting classstarts the application of a refactoring and since it extends AbstractRefactoringAction31

(and thereby implements IObjectActionDelegate32) it can be placed in the context menuusing org.eclipse.ui.popupMenus as already mentioned in 6.3.1. The most interest-ing method de�ned here is the method run(IAction) because it is executed by �ring theaction and applies the model refactoring. The UML2 activity diagram in Figure 6.13illustrates the abstract behaviour of this method and thereby depicts the application ofa model refactoring. At �rst the selected object in the model is determined with a typespeci�ed in the generation wizard. Afterwards the a wizard is opened asking the user

26de.tuberlin.emt.model.util.EMTModelManager27de.unimarburg.refactoring.emtextension.generator.wizard.ImportExportSelectionListener28de.unimarburg.refactoring.emtextension.generator.Properties29de.unimarburg.refactoring.emtextension.generator.data.TransformationDataExt30de.tuberlin.emt.generator.data.TransformationData31de.unimarburg.refactoring.menu.action.AbstractRefactoringAction32org.eclipse.ui.IObjectActionDelegate

45


for entering additional input data. All necessary input data was de�ned by he modelrefactoring designer during the generation of a new model refactoring plug-in.

Figure 6.13: Activity diagram for the application of a model refactoring

Now I will branch to this wizard constituted by the generated classes RefactoringWizardand RefactoringWizard and explain them as well as the according JET templates. There-after I will return to the <%=RefactoringName%>Action as illustrated in the activity diagramin Figure 6.13 to apply the model refactoring.

RefactoringWizard.javajet and RefactoringWizardPage.javajet

A RefactoringWizard implements the method addPages() which is executed when the win-dow containing the wizard is created and adds a RefactoringWizardPage to the wizard.This RefactoringWizardPage is generated using RefactoringWizardPage.javajet whichalso receives an instance of TransformationDataExt as argument. In the beginning of thistemplate I implemented a little workaround . The problem is, that EMFTrans does notprovide transformation wide input parameters but only input parameters for rules and auser applying the refactoring should not enter parameters for each rule but for the wholetransformation. So I decided, that input parameters with the same name but from dif-ferent rules are only de�ned once. A refactoring designer should be aware of this. Thislittle workaround is implemented using a HashMap<String, VariableData> inputParameters

which stores the VariableData33 for every name of an input parameter. This way it isguaranteed that input parameters with the same name are only stored once. If a key-value pair is saved into a HashMap and the key already exists its value is overwrittenwith the new value. The object �elds in a RefactoringWizardPage are, apart from the

33de.tuberlin.emt.generator.data.VariableData

46

6.5 The source code

selectedEObject, dynamically generated, i.e. for each input parameter a Label34 and aWidget35. This Widget is either an instance of Combo36 or Text37. A Text is generated if noobject in the rule could be assigned to the input parameter and possibly a preselectionmethod was declared (cf. Section 7), otherwise a Combo is generated. In other words,if several objects in the model can be automatically determined, a Combo is created and�lled with Strings representing these objects.

If the Widget is an instance of Combo the preselection method selects the �rst elementof all elements added to the Combo. Otherwise a method declared previously duringgenerating the model refactoring plug-in is executed and the string representation ofthe resulting object is added to the Text widget. If resulting object is an instance ofEList38 the string representation of the �rst element in the list is added to the Text

widget.

The RefactoringWizardPage inherits WizardPage39 and implements the interface Listener40

to listen for changes in any widget designed for user input (Combo or Text). The methodRefactoringWizardPage#createControl(Composite) creates the layout of the wizard page.The template generates a Label41 and an input �eld for each input parameter. In caseof the input �eld being a Combo, the method Utils.addReferencedObjectsToWidget(...) isinvoked adding all model objects quali�ed for this input �eld to the Combo.

Thereafter a Listener is added to the input �eld and the preselection method is in-voked. The added Listener is the class RefactoringWizardPage itself and therefore themethod handleEvent(Event event) is implemented. An if-block for every input parameteris generated by the template. Since Text as well as Combo both implement a methodcalled getText(), there is no distinction between these two cases. The generated methodretrieves the current value of every input �eld and for each input parameter invokes themethod AbstractRefactoringWizard#putParameter(String, Object, String) to save these val-ues in the object �eld parameters of the wizard containing this wizard page. That is whythe class AbstractRefactoringWizard must be the common superclass of every generatedRefactoringWizard which is illustrated in Figure 6.5.3.

Returning to RefactoringAction.javajet

Now it is time to return to <%=RefactoringName%>Action.run(IAction) and the accordingtemplate RefactoringAction.javajet. If the dialog containing the above-mentionedwizard is canceled this method �nishes, otherwise the refactoring is applied. In the lattercase, the parameters returned by RefactoringWizard#getParameters() must be delegatedto the generated class Transformation which awaits a HashMap storing a Parameter for eachrule name. Since this Parameter object contains every input parameter of every rule wecan store a reference to it for every rule name in the HashMap.

34org.eclipse.swt.widgets.Label35org.eclipse.swt.widgets.Widget36org.eclipse.swt.widgets.Combo37org.eclipse.swt.widgets.Text38org.eclipse.emf.common.util.EList39org.eclipse.jface.wizard.WizardPage40org.eclipse.swt.widgets.Listener41org.eclipse.swt.widgets.Label

47


Figure 6.14: An extract from the class diagram of a generated model refactoring plug-in showing the inheritance hierarchy of the generated classes RefactoringWizard andRefactoringWizardPage

The �rst approach of applying refactorings copied of the whole EObject tree, appliedthe refactoring to this copy, compared the original to the (now refactored) copy, appliedthe refactoring to the original model, and saved it. This was the best solution I couldthink about, because EMFTrans does an in-place model transformation and in case ofcanceling the refactoring I did not want to have any changes to the model at all. I alsotried to overwrite the original with the refactored copy but that caused modi�cation ofxmi ids which is unacceptable.

The matter with this solution was scalability. Very large models would have takenup too much time to copy and to transform twice. The solution for this might be tostore the large models in di�erent �les. But tests unveiled that the approach includingcopying was not aware of separated models and copying several models would have madescalability even worse. So I had to think about a completely new approach which is nowimplemented but not yet tested very well.

After constructing the HashMap containing rule names and their Parameters, a Vector

is created containing all root elements of Resources which are also located in the openResourceSet. This Vector is used for transformation because hereby models by any meansrelated to the opened model are considered, too. This includes for example UML2Primitive Types like Boolean, Integer, and String as well as models designed by otherusers declaring for example common supertypes or other data types. In the following theterm �joint model� includes all models in the open ResourceSet whereas the term �model�addresses a model loaded from a single Resource only which may still have references toother models.

When the method trans.transform(ruleParameters) returns, some models may havechanged but not saved to the �le system, yet. This entails that the original jointmodel can be accessed by loading every model from its Resource using the methodAbstractRefactoringAction#getOriginalModel(EObject) and then the original joint modelcan be compared to the refactored joint model. In the actual version we compare every

48

6.5 The source code

changed model to its origin by invoking AbstractRefactoringAction#compareInDialog(...).This method compares two models to each other and computes an editor input forthe Eclipse compare UI, which is shown in a newly opened dialog. As depicted inFigure 3.5, the two models are matched to each other and based on this MatchModel42

a di� builder computes a DiffModel43. These two instances are used to de�ne a newModelInputSnapshot44 which itself is used to create a new ModelCompareEditorInput45. Thisclass inherits from CompareEditorInput46 which is part of the Eclipse compare API and,hence, is used for opening a new compare dialog for every modi�ed model. Only if allcompare dialogs opened by this method were �nished by pushing the �Commit� button,the refactoring is �nally applied, which means that all changed resources are saved us-ing the method AbstractRefactoringAction#saveModels(Vector<EObject>). In all other casesthe editor content has to be reloaded from the �le system in order to show the origi-nal models by AbstractRefactoringAction#restoreAllModels(IEditorPart). Unfortunately Icould not �nd a way for reloading the content of an editor except for closing the editorand opening it again. In future versions this method can easily be exchanged by a lessrigorous implementation.

42org.eclipse.emf.compare.match.metamodel.MatchModel43org.eclipse.emf.compare.diff.metamodel.DiffModel44org.eclipse.emf.compare.diff.metamodel.ModelInputSnapshot45org.eclipse.emf.compare.ui.editor.ModelCompareEditorInput46org.eclipse.compare.CompareEditorInput

49

7 How to create a model refactoring

Since every metamodel needs its own set of model refactorings, a chapter about creationof new model refactorings is indispensable. The complexity of de�ning refactoringsdepends on the complexity of the underlying metamodel. UML2 refactorings for instanceare quite complex because very many details like visibilities have to be considered.The following chapter starts with a short installation manual for the EMF Refactor-

ing Plug-in and proceeds with the step-by-step creation of a new EMF UML2 modelrefactoring, namely Move Package.

7.1 Installation of the EMF Refactoring Plug-in

To install the EMF Refactoring Plug-in the following plug-ins are necessary:

• EMF [3]• EMF Transformation Project [16]• EMF Compare [17]

After conforming these requirements there mainly two di�erent ways of installing theEMF Refactoring Plug-in. On the one hand you can download the jar �les from theproject's website [32] and store them in the dropins folder of your Eclipse installationand on the other hand you can install the EMF Refactoring Plug-in using the updatesite [33]. The latter should automatically verify all necessary dependencies.

7.2 Creating Move Package

Conferring the last chapters, each model refactoring is designed using the EMF Trans-formation framework. If this plug-in is properly installed you can create a new EMFModel Transformation using File > New > Other. . . from the menu. For illustratingthis chapter I refer to the refactoring called Move Package introduced in Figure 4.8 inSection 4.2.2. Assuming the refactoring is already de�ned, the creation of the refac-toring plug-in project is quite simple. There is an entry in the context menu of thegraphical editor labeled �Generate Refactoring� which opens a wizard. The �rst pageis a WizardNewProjectCreationPage where you must enter the name of the new project.This should be the name of the refactoring because this name is used to identify therefactoring and shown in the �Model Refactoring� context menu. Furthermore you canchange the location of the project if you want to.The second page is for setting all other refactoring properties. In the �eld labeled

Description you should brie�y describe the refactoring because this is used for thedescription of the feature containing the refactoring. Specifying the Selection is morechallenging. It de�nes a starting point for the model refactoring. That means you haveto select the object to refactor. That selection also �lls out the next �eld Selection class

51


Figure 7.1: First page of the generation wizard

automatically. In most cases this value is correct but if the transformation contains twometamodels with an equally named object the correct value can not be determined sincethese names are not full quali�ed, which makes this �eld necessary.

For every declared input parameter the wizard page contains a Composite containingseveral con�guration �elds. Since EMFTrans does not provide global transformationinput parameters I implemented a workaround. If input parameters from di�erent ruleshave the same name, they are considered to be global. That means that they are set oncefor every rule with the same value and for the whole transformation input parameterswith the same name are only declared once. The �rst con�guration �eld to mention isType because there is an algorithm to preselect this �eld. The content of the left-handside of a rule is considerable as distinct graphs, each a connected component. On thisassumption the values of a few input parameters are already con�gured only by selectingthe starting point. The connected component including the starting point is used toprede�ne all input parameters because within this connected component you can specifythe path from the starting point to the component containing the input parameter.

If the Type �eld does not contain the appropriate entry and not available is selected,the �eld Preselection method is enabled. The string you enter here must be in Java syn-tax because it is directly written into the generated code. More precisely, the string mustbe a method invocation using the objects this refactoring is applied to. For instance,org.eclipse.uml2.uml.Property is the value of Selection class and the value of Preselectionmethod is getType().getName() then the generator creates the following lines of code:

1 try {

2 Object methodResult = selectedEObject.getType (). getName ();

3 // ...

4 } catch (Exception e) {

5 e.printStackTrace ();

6 }

This behavior is obviously in need of improvement. For a more detailed speci�cation

52

7.2 Creating Move Package

of this improvement please refer to Section 9.

Furthermore there is a check button labelled suppress in wizard which should bechecked if the value of this input parameter is deducible from the selected object andshould not be visible to or changeable by the user. The result is a disabled �eld becausethe EMF Refactoring Plug-in is still in its infancy and a lot of debugging and testingis necessary. But the �eld should be removed in future versions of the plug-in (cf.Section 9).

Figure 7.2: Second page of the generation wizard

After con�guring all input parameters you can click on �Finish� and your refactoringis created and ready to be deployed. But if some bugs arise while testing (and I amsure there will) you would have to �ll out the hole wizard page once again, maybewithout any di�erences. Therefore I added import and export functionality. Just clickon �Export� after �lling out the wizard and choose an XML �le to save the setting youmade. When you have to create the refactoring once again just click on �Import�, selectthe previously saved XML �le and the wizard page should be �lled out just as you savedit. That should also work although input parameters have been added or removed.

53


7.3 Copying objects in refactorings

During model refactoring design we revealed that some refactorings need to copy cer-tain objects, e. g. Push Down Operation need to copy the operation to every subclass.Using EMFTrans, copying is impossible hence we modi�ed the generated rules. Butthis approach was unacceptable because this modi�cation has to be adapted to everysingle model refactoring and after every re-generation, too. This problem was solved bymodifying the template for rule classes. Since this chapter is a practical one, I will notgo into implementation details but explain how to create such a �copy rule�.The design of a model refactoring refactoring did not change in any way. The only

constraint is, that the name of ordinary rules must not start with �COPY�, because theserules are interpreted as �copy rules�. The example in Figure 7.3 will copy an Operationto another class.

Figure 7.3: A rule interpreted as a �copy rule�

The LHS is de�ned to �nd the source (Class), the target Class, and the object beingcopied Operation. The RHS maps these three objects and adds two new objects, anEAnnotation and an Operation. The body of the EAnnotation must be set to �COPY�.The new objects are connected to the existing model as follows:

• The existing Operation contains the EAnnotation• The target Class contains the new Operation• The EAnnotation refers to the new Operation

Please note that these objects are not really created, especially the EAnnotation, butthe Operation is copied using the method EcoreUtil.copy(EObject). This method returnsa copy of the old Operation and assigns it to the new Operation. The NAC ensures thatthis rule is only applied once so that it can be used in a usual model refactoring design,but should be placed in a separate layer.Such a rule should be adoptable to any kind of metamodel because the EAnnotation

is part of the EMF metamodel which is loaded by default.

54

8 How to apply a model refactoring

This chapter is concerned with the application of model refactorings. But beforehandthe model refactorings have to be installed in your Eclipse installation. After a shortinstallation manual I will explain the application of the UML2 refactoring Pull UpProperty

8.1 Installing model refactorings

Like every Eclipse plug-in you can install new model refactorings by either storing themin your dropins folder or by installing them using an update site. But you have toassure that the EMF Refactoring Plug-in is installed (cf. Section 7.1).

8.2 Applying Pull Up Property

Refactorings are applied by loading a model into the EMF-generated editor. The exam-ple in Figure 8.1 shows this tree based editor of UML2 on the left side and for a betteroverview a graphical editor shipped with UML2Tools [34] on the right side. I want toapply Pull Up Property1 and to emphasise changes made by the refactoring the positionattributes in the subclasses of AngularObject are marked in the graphical editor.As described in the last chapter, every refactoring has a visibility option which con�g-

ures to which kind of element a refactoring is applicable. In Figure 8.2 only refactoringsapplicable to org.eclipse.uml2.uml.Property are listed although other refactorings are in-stalled. So, selecting an element from the model already adjusts the listed refactoringsin the context menu. This way it is impossible to, for instance, apply a class refactoring(like Move Class) to a package. After choosing a refactoring, a wizard pops up andasks for missing information to apply the refactoring. The input parameters that werecon�gured �suppress in wizard� while creating the refactoring plug-in are only disabledbut should be removed in later versions.As we can see in Figure 8.3 several �elds are disabled. The enabled �elds have to

be �lled out by the user because the required information is not uniquely deduciblefrom the selected object. However, in this example it is unique because all three classeshave only one common superclass. But since it is possible in UML2 to have severalsuperclasses, the common superclass is not generally unique.After �lling out all �elds, clicking on �Finish� applies the refactoring but does not

save the refactored model, yet. Like program refactorings EMF Refactoring providesa preview of all changes to give the user the chance to revert to the non-refactoredmodel. Figure 8.4 shows the compare editor for the example. As you see the left sidecontains the �Original Model� and the right side contains the �Refactored Model�. The

1In this case it could be named Pull Up Attribute as well

55


Figure 8.1: Before applying Pull Up Property

Figure 8.2: The context menu of Pull Up Property

56

8.2 Applying Pull Up Property

Figure 8.3: The wizard of Pull Up Property

di�erence view located above the two models contains a textual description of what therefactoring has done. In the example the attribute position has moved from Hexagon toAngularObject. In this case it reveals a bug within EMF Compare (cf. Section 3.3). Thesecond di�erence is the removal of position from Square. The same is done for Rectangle

although it is not visible. If �Commit� is pressed, all changes are applied to the originalmodel and the original model is saved.The result of Pull Up Property applied to Figure 8.1 is shown in Figure 8.5. The

tree editor is updated instantly but the graphical editor is not. To update the graphicaleditor just select the according tab or activate the editor. The yellow marks are, asbefore, only for emphasising changes to the model.

57


Figure 8.4: Comparison after applying Pull Up Property

Figure 8.5: After applying Pull Up Property

58

9 Conclusion and future prospects

9.1 The current version

As already mentioned, this thesis also comprises a CD-ROM containing an Eclipse instal-lation including all necessary plug-ins for generating and applying model refactorings.But I also established a website1 providing for one thing tutorials extracted from Sec-tion 7 and from Section 8 and for another thing an update site2 for installing the EMFRefactoring Plug-in in any other Eclipse installation.

The EMF Refactoring Plug-in is one of the �rst tools providing model refactoringfacilities, ever. It is possible to design new model refactorings for any kind of metamodelwith EMFTrans and with the EMF Refactoring Plug-in these refactorings can be appliedto instance models through the Eclipse API. But EMFTrans is not con�ned to modelrefactorings and neither is the EMF Refactoring Plug-in (in spite of its name). Everykind of model transformation can be generated as a model refactoring, which on the onehand is obviously confusing but on the other hand this provides even more applicationpossibilities. For instance, complex editor operations, e. g. to reduce the amount ofediting operations, could be de�ned and applied through the Eclipse user interface.

Although my thesis is not yet �nished and the EMF Refactoring Plug-in is still inits infancy, we already started developing a comprehensive EMF UML2 refactoring toolon the basis of this work. The already mentioned refactoring catalog [27] providesa huge set of class diagram and state chart refactorings and is used to de�ne EMFUML2 refactorings using EMFTrans. These transformations are used to generate modelrefactoring facilities for EMF UML2 instance models. We already designed several EMFUML2 refactorings and tested them very brie�y. In general it is possible to install theseEMF UML2 refactorings to any Eclipse installation meeting the dependencies, and applythem to EMF UML2 model instances.

Since the EMF Refactoring Plug-in is aware of any EMF based model, the nextstep is to integrate the EMF Refactoring Plug-in into the EMFT Project [19] to �ndmore people for improving the plug-in as well as designing new model refactorings formiscellaneous metamodels. The �rst steps are already made by getting in contact withone of the committers of EMF, namely Ed Merks, whom I met at the Eclipse SummitEurope 2008 in Ludwigsburg. Right now, we are preparing the project proposal forthe EMF Refactoring Plug-in and we are looking forward to getting feedback from theEclipse community.

1http://www.mathematik.uni-marburg.de/ swt/modref2http://www.mathematik.uni-marburg.de/ swt/modref/update

59


9.2 Improvements

This is probably the most cited chapter in this thesis because I developed the EMFRefactoring Plug-in and afterwards I wrote this thesis. While writing I revealed severalmissing features and because there was not enough time left for implementing thesefeatures I just wanted to assure that these ideas for new features will not get lost. Inthe future I hope there will be other friends of the Eclipse Modeling Framework who areseeing the need for EMF refactorings and are willing to develop more model refactoringsand improve the design of the plug-in. For the latter this chapter should give ideas fornew features and recommendations of how to implement them.

9.2.1 Improvements to the refactoring generation process

Generating a new model refactoring is, compared to the �rst UML2 Refactoring Plug-in, very comfortable. There is no need for a refactoring designer to implement a singleline of code except for perhaps the so called preselection method. When the refactoringdesigner �nishes his or her de�nition of rules and decides to generate the refactoring, thegeneration wizard shows for every input parameter de�ned in the transformation a text�eld awaiting java code in certain cases (cf. Section 7). In these certain cases it wouldbe very helpful to have some kind of code assist enabled in this text �eld. Thereforean object with the type of the selection must be created, which can easily be done bythe factory class, and chosen for code assist. On the other hand should this �eld alsobe aware of string values because sometimes the preselection is just a suggestion for aname to enter.

More important than code assist for some text �elds surely is the design of com-plex refactoring composed of basic refactorings. We already discussed this topic in ourworkgroup and we discovered that only creating a single wizard containing the alreadygenerated wizard pages of each refactoring is very unsuitable because on the one handthere may be several input parameters of di�erent refactorings semantically equal butrequested on each of the wizard pages separately. And on the other hand there may beinput parameters of complex refactorings which can be automatically determined buthave to be set explicitly in basic refactorings. An example for this are global refactoringslike Remove Unreachable States for state machines.

In the actual version there is no extension point for new refactorings de�ned whichshould be considered in future versions. All generated refactorings serve the extensionpoint org.eclipse.ui.popupMenus to extend the context menu of all EObjects but witha visibility limited to certain classes implementing this interface. This is something thatshould be encapsulated by a newly de�ned extension point because a refactoring itselfshould not be aware of the menus it is placed in and it would be easier to also placerefactorings in other menus. As described in 2.2 it is very easy to de�ne this extensionpoint but the still unsolved problem is how to wrap this extension point around anotherone; for example org.eclipse.ui.popupMenus.

Shortly before handing in this thesis we possibly found a problem while generating arefactoring without input parameters but I was not able to spend any time analysingor even solving this problem. I think this is a minor problem in comparison to theother improvements mentioned in this chapter and probably unnecessary because other

60

9.2 Improvements

improvements might supersede it.

9.2.2 Improvements to the application of refactorings

The EMF Refactoring Plug-in, primarily the generated refactorings are actually onlyaware of single selections when applying refactorings. A multiple selection leads to alist of selected objects and it should be possible for the refactoring designer to de�newhat to do with a multiple selection. On the one hand it could make sense to apply therefactoring to every selected object one after another similar to a complex refactoringbut on the other hand it may be more meaningful to use the selection for setting moreinput parameters automatically.

When applying a refactoring there are still a few debug settings left. For example therefactoring wizard still shows input parameters even if the refactoring designer wantedto suppress them. This was very useful for validating the automated parameter settingsbut should be removed completely from the wizard if the plug-in is deployed at sometime. This implies that empty wizards should not be shown at all.

While refactoring some errors may occur which could not be avoided by checking pre-conditions or even exceptions may be thrown. The generated refactorings are alreadyaware of loops seeming to run in�nitely and ask the user after 300 applied rules whetherto go on transforming or not which is a very simple check for possible errors. Thrownbut not yet caught exceptions have to be considered and handled in a sensible way. Er-rors concerning the refactoring design are also possible but this responsibility obviouslybehooves the refactoring designer. We though about adding special comments to themodel which might be readout in a message dialog.

After refactoring a model distributed amongst several �les the compare dialog isopened and compares the refactored models the their origins one after another. Animaginable improvement would be to merge all these comparisons into a single onecomparing several root elements, or all single comparisons could at least be integratedin a wizard where the user is able to navigate back and forth. Although a refactoringdoes not change the model in any way, currently a compare dialog is opened reportingno changes to the model but there should only be some kind of message dialog. Ialready investigated the method getUnMatchedElements() in MatchModel3 which returns anEList of unmatched elements. If this list contains no elements it might indicate that therefactoring did not change the model at all.

9.2.3 Internal improvements

There are also improvements to the existing code including new functionality I thoughtabout. At �rst I want to mention that the EMF Refactoring Plug-in itself needs tobe refactored because a few features were implemented on the quick. Besides, a veryimportant feature is to provide undo / redo functionality because the only way to undoa refactoring is to restore the changed �les from the local history or from a repositoryif available. This behaviour is absolutely inadequate and should be one of the �rstimprovements to the EMF Refactoring Plug-in.

3org.eclipse.emf.compare.match.metamodel.MatchModel

61


A quite simple looking change of behaviour is needed when canceling a refactoring.Actually the editor is closed and opened again which also closes all imported models ormodel parts. There should be a more adequate way of reloading all models from theirresources.I want to close this chapter with two very signi�cant improvements concerning gen-

erated refactorings. Currently the model is refactored and after applying, in case of acomplex refactoring, all basic refactorings the model is compared to its origin locatedsomewhere in the �le system. But it would be much easier if a transformation records allchanges made to the models. A possible solution might be to use a ChangeRecorder4 butthere was no time for su�cient tests whether this class is suitable for this task. Anothersolution is to already construct a MatchModel5 while applying rules. This MatchModel couldthen be used by EMF Compare directly without comparing the refactored model to anyother model which possibly saves some time and thus increases performance.The other signi�cant improvement is to use the Language Toolkit API [35] for ev-

ery model refactoring. The Language Toolkit was extracted by the JDT team fromtheir refactorings to create a language neutral layer which now is a standalone APIindependent of Java. This API is used among others by PDE (Plug-in DevelopmentEnvironment) and CDT (C/C++ Development Tooling) and I think that also a projectlike EMF should use it.The EMF Refactoring Plug-in would pro�t by using the LTK API because we would

get uni�ed way of applying refactorings, thus the creation of complex refactorings wouldbecome much easier and it would be possible to simultaneously apply model and coderefactorings.

4org.eclipse.emf.ecore.change.util.ChangeRecorder5org.eclipse.emf.compare.match.metamodel.MatchModel

62

List of Figures

2.1 plugin.xml of project Selection View . . . . . . . . . . . . . . . . . . 4

2.2 Implementation of the class SelectionView . . . . . . . . . . . . . . . . . 5

2.3 The wizard for creating a new extension point . . . . . . . . . . . . . . . 6

2.4 The newly de�ned extension point for model refactorings . . . . . . . . . 7

2.5 Accessing all extensions to an extension point . . . . . . . . . . . . . . . 7

3.1 Modeling a library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Example of a library instance model . . . . . . . . . . . . . . . . . . . . 11

3.3 Extract from the EMFTrans metamodel . . . . . . . . . . . . . . . . . . 13

3.4 A sample refactoring for a library instance models . . . . . . . . . . . . 14

3.5 How EMF Compare works . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.6 Example of EMF Compare . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Result of Hide Property . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Hide Property: CreateGetterForeignType . . . . . . . . . . . . . . . 19

4.3 Hide Property: CreateSetterForeignType . . . . . . . . . . . . . . . 21

4.4 Hide Property: CreateGetterClassIsType . . . . . . . . . . . . . . . 22

4.5 Hide Property: CreateSetterClassIsType . . . . . . . . . . . . . . . . 22

4.6 Hide Property: MakePropertyPrivate . . . . . . . . . . . . . . . . . . 22

4.7 Move EClass (Ecore): Moving an EClass to another EPackage . . . . . 24

4.8 Move Class (UML): Moving a Class to another Package . . . . . . . . . 24

6.1 Document Type De�nition of objectContribution . . . . . . . . . . 33

6.2 plugin.xml of plug-in menu . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.3 Document Type De�nition of actionSet . . . . . . . . . . . . . . . . . 35

6.4 plugin.xml of plug-in emtextension . . . . . . . . . . . . . . . . . . . . 35

6.5 Extension point schema for othercontextmenuentries . . . . . . . . . 36

6.6 The class CustomGeneratorPlugin contains the instance of emtextension . 37

6.7 The class Activator looks identical in menu and util . . . . . . . . . . . 37

6.8 Code generation with JET . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.9 Class diagram: CustomGenerator . . . . . . . . . . . . . . . . . . . . . . 39

6.10 Implementation of GenerateRefactoringAction#execute(Editor) . . . . . . . 41

6.11 GenerateRefactoringWizard.doFinish(IProject, IProgressMonitor) . . . . . . 42

6.12 DTD of xml �le for automated generation . . . . . . . . . . . . . . . . . 44

6.13 Activity diagram for the application of a model refactoring . . . . . . . . 46

6.14 Class diagram: Generated refactoring . . . . . . . . . . . . . . . . . . . . 48

7.1 First page of the generation wizard . . . . . . . . . . . . . . . . . . . . . 52

7.2 Second page of the generation wizard . . . . . . . . . . . . . . . . . . . . 53

63

List of Figures

7.3 A rule interpreted as a �copy rule� . . . . . . . . . . . . . . . . . . . . . 54

8.1 Before applying Pull Up Property . . . . . . . . . . . . . . . . . . . . . . 568.2 The context menu of Pull Up Property . . . . . . . . . . . . . . . . . . . 568.3 The wizard of Pull Up Property . . . . . . . . . . . . . . . . . . . . . . . 578.4 Comparison after applying Pull Up Property . . . . . . . . . . . . . . . . 588.5 After applying Pull Up Property . . . . . . . . . . . . . . . . . . . . . . 58

64

Bibliography

[1] T. Stahl, M. Völter, S. E�tinge, and A. Haase, Modellgetriebene Softwareentwick-lung: Techniken, Engineering, Management. Dpunkt Verlag, 2007.

[2] �Eclipse�, December 2008.http://www.eclipse.org

[3] �Eclipse Modeling Framework Project (EMF)�, December 2008.http://www.eclipse.org/modeling/emf/

[4] E. Biermann, K. Ehrig, C. Köhler, G. Kuhns, G. Taentzer, and E. Weiss, �EMFModel Refactoring based on Graph Transformation Concepts�, ECEASST, vol. 3,2006.

[5] �Equinox�, December 2008.http://www.eclipse.org/equinox/

[6] �OSGi Alliance�, December 2008.http://www.osgi.org

[7] G. Wütherich, N. Hartmann, B. Kolb, and M. Lübken, Die OSGi Service Platform:Eine Einführung mit Eclipse Equinox. Heidelberg: dpunkt, 2008.

[8] �Eclipse Java development tools (JDT)�, December 2008.http://www.eclipse.org/jdt/

[9] �Eclipse C/C++ Development Tooling - CDT�, December 2008.http://www.eclipse.org/cdt/

[10] �TeXlipse�, December 2008.http://texlipse.sourceforge.net/

[11] �PHP Development Tools�, December 2008.http://www.eclipse.org/pdt/

[12] �Ruby Development Tools�, December 2008.http://rubyeclipse.sourceforge.net/

[13] �Plug-in Development Environment (PDE)�, December 2008.http://www.eclipse.org/pde/

[14] W. Beaton, �What is Eclipse?�, technical report, Eclipse Foundation, May 2008.

[15] F. Budinsky, D. Steinberg, E. Merks, R. Ellersick, and T. J. Grose, Eclipse ModelingFramework (The Eclipse Series). Addison-Wesley Professional, August 2003.

65

Bibliography

[16] �EMF Transformation Project�, December 2008.http://tfs.cs.tu-berlin.de/emftrans/

[17] �EMF Compare�, December 2008.http://www.eclipse.org/modeling/emft/?project=compare

[18] E. Merks, �The Eclipse Modeling Framework - Introducing Modeling to the JavaTechnology Mainstream�, technical report, IBM Canada Ltd., 2004.

[19] �Eclipse Modeling Framework Technology (EMFT) project�, December 2008.http://www.eclipse.org/modeling/emft

[20] U. Eco, The Name of the Rose. Harvest Books, September 1994.

[21] C. Köhler, �A Visual Model Transformation Environment for the Eclipse ModelingFramework�, Diploma thesis, Institute for Software Technology and TheoreticalComputer Science, Technical University of Berlin, 2006.

[22] E. Biermann, K. Ehrig, C. Ermel, C. Köhler, and G. Taentzer, �The EMF ModelTransformation Framework.�, in AGTIVE (A. Schürr, M. Nagl, and A. Zündorf,eds.), vol. 5088/2008 of Lecture Notes in Computer Science, pp. 566�567, SpringerBerlin / Heidelberg, 2007.

[23] E. Biermann, K. Ehrig, C. Köhler, G. Kuhns, G. Taentzer, and E. Weiss, �GraphicalDe�nition of In-Place Transformations in the Eclipse Modeling Framework�, inProceedings of Model Driven Engineering Languages and Systems (MoDELS'06),vol. 4199 of LNCS, pp. 425�439, 2006.

[24] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts, Refactoring: Improvingthe Design of Existing Code. Addison-Wesley Professional, June 1999.

[25] R. Reiÿing, �Refactoring�, Informatik Spektrum, vol. 22, no. 3, pp. 210�211, 1999.

[26] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elementsof Reusable Object-Oriented Software. Addison-Wesley Professional ComputingSeries, New York, NY: Addison-Wesley Publishing Company, 1995.

[27] D. Müller, G. Taentzer, and F. Mantz, �Refactoring Catalog for UML Models (un-published manuscript).� Philipps-Universität Marburg, Germany, FB 12 - Mathe-matics and Computer Science, Software Engineering.

[28] I. Sommerville, Software Engineering: (Update) (8th Edition) (International Com-puter Science Series). Addison Wesley, June 2006.

[29] K. Beck and C. Andres, Extreme Programming Explained : Embrace Change (2ndEdition). Addison-Wesley Professional, November 2004.

[30] D. Gallardo, �Developing Eclipse plug-ins�, technical report, December 2002.

[31] A. Powell, �Developing Eclipse plug-ins�, technical report, IBM, April 2004.

66

Bibliography

[32] �EMF Refactoring Plug-in�, December 2008.http://www.mathematik.uni-marburg.de/~swt/modref/

[33] �EMF Refactoring Plug-in Update Site�, December 2008.http://www.mathematik.uni-marburg.de/~swt/modref/update/

[34] �UML2 Tools�, December 2008.http://www.eclipse.org/modeling/mdt/?project=uml2tools

[35] L. Frenzel, �Eclipse als Sprachtalent�, eclipse Magazin, vol. 4, 2005.

67

development of a refactoring plug-in for the eclipse ...swt/... · the osgi standard [6], a dynamic...

Documents