resolving conflict and dependency in refactoring to a desired … · 2018-12-15 · tomate this...

e-Informatica Software Engineering Journal, Volume 9, Issue 1, 2015, pages: 37–56, DOI 10.5277/e-Inf150103

Resolving Conflict and Dependency in Refactoring

to a Desired Design

Iman Hemati Moghadam∗, Mel O Cinneide∗∗

∗Department of Computer Science, University College London, United Kingdom∗∗School of Computer Science and Informatics, University College Dublin, Ireland

[email protected], [email protected]

Abstract

Refactoring is performed to improve software quality while leaving the behaviour of the systemunchanged. In practice there are many opportunities for refactoring, however, due to conflicts anddependencies between refactorings, only certain orders of refactorings are applicable. Selectingand ordering an appropriate set of refactorings is a challenging task for a developer. We propose anovel automated approach to scheduling refactorings according to their conflicts and dependenciesas well as their contribution to design quality expressed by a desired design. The desired designis an improved version of the current program design, and is produced by the developer. Ourapproach is capable of detecting conflicts and dependencies between refactorings, and uses asequence alignment algorithm to identify the degree of similarity between two program designsexpressed as sequence of characters, thereby measuring the contribution of a refactoring to achiev-ing the desired design. We evaluated our approach on several sample programs and one non-trivialopen source application. Our results demonstrate the ability of the approach to order the inputrefactorings so as to achieve the desired design even in the presence of intense inter-refactoringconflict and dependency, and when applied to a medium-sized, real-world application.

Keywords: Refactoring, Refactoring Scheduling, Design Similarity

1. Introduction

Refactoring is performed to improve the qual-ity of the software in some way. It may involvefloss refactoring, where minor improvements areapplied frequently, typically several times a day,or it may involve remedial refactoring1 where amore significant design overhaul takes place [1].In this paper we are concerned with automatedrefactoring support for the remedial refactoringscenario. A developer performing remedial refac-toring typically has a notion of a desired designthat they are refactoring the program towards.This desired design may come about by way of

an interactive design process, as in the work ofSimons et al. [3, 4] or it may be created by theintellectual effort of the developer [5, 6]. Eitherway, the challenge the developer faces is that ofrefactoring the program from its current designto its new, desired design.

In earlier work, we presented an approachto refactor a program based both on its desireddesign and on its source code [5]. In this work,a new UML-based desired design is first createdby the developer based on the current softwaredesign and their understanding of how it may berequired to evolve. The resulting design is thencompared with the original one using a differenc-

1 Termed ‘root canal’ refactoring by Murphy-Hill et al. [1] and ‘batch mode’ refactoring by Liu et al. [2]. Liu etal. [2] provide strong evidence of the practical importance of this type of refactoring.

http://www.e-informatyka.pl/wiki/e-Informatica

http://www.e-informatyka.pl/attach/e-Informatica_-_Volume_9/eInformatica2015Art3.pdf

38 Iman Hemati Moghadam, Mel O Cinneide

ing algorithm [7], and the detected differencesare expressed as refactoring instances. The origi-nal source code is then refactored using a heuris-tic approach based on the detected refactoringsto conform more closely to the desired design [5].Overall, the process of refactoring the programto comply with its desired design involves threedistinct steps as follows:1. The developer must decide what refactorings

are required to bring the program from itscurrent design to its desired design.

2. They must decide in what order the refac-torings should be applied.

3. The refactorings must then be applied to theprogram in this sequence.As mentioned, recent work has sought to au-

tomate this refactoring process. For example,UMLDiff [7, 8] is a tool that addresses step (1)by detecting what refactorings are required tobring a program design from its current state toa new desired design. Step (3) is supported bya broad range of refactoring tools that apply in-dividual refactorings, such as the Eclipse Refac-toring Tools, and also by more sophisticated re-search prototypes, such as Code-Imp, that canapply a series of refactorings guided by a fitnessfunction [9]. The focus of this paper however, isstep (2), the ordering of the refactorings into avalid sequence.

Given a set of refactorings, finding a validsequence in which they may be applied isa non-trivial problem. A refactoring is charac-terised by a precondition and a postcondition.The precondition determines if the refactoringmay be applied, and the postcondition stateswhat the result of applying the refactoring is,assuming its precondition was true when it wasapplied. A refactoring may be applicable to theinitial program, but if it is not applied then, an-other refactoring in the sequence may render itinapplicable. Conversely, a refactoring may beinapplicable to the initial program, but anotherrefactoring in the sequence may render it ap-plicable later on. These observations have ledto the notions of conflict and dependency ina refactoring sequences [10,11]. Two refactoringsare in conflict if they cannot both be applied tothe program, e.g. a method cannot be moved

to a deleted class. A dependency exists betweentwo refactorings if they can only be applied ina particular order, e.g. a refactoring that createsa new class must be executed before a refac-toring that moves a method to that new class.Precise definitions of these terms are providedin Section 3.2.

The question addressed in this paper thenis as follows. Given a set of proposed refactor-ings that are to be applied to a program so asto bring its design to a desired state, how canthe refactorings be ordered such that they canbe applied to the program while respecting theconstraints imposed by the conflicts and depen-dencies that may exist between the refactoringsin the set? To answer this question, we proposean automated refactoring scheduling approachthat finds a valid order of the refactorings inthe set, according to their conflict and depen-dency relationships as well as their contributionto achieving the desired design. The main con-tribution of this paper is two-fold:– We extend the refactoring scheduling algo-

rithm proposed by Liu et al. [10] by con-sidering not just conflicts between refactor-ings but also dependencies. Furthermore, wetake into account a type of refactoring con-flict not handled in the work of Liu at al.,where the application of one refactoring vi-olates the precondition of another. We referto this algorithm as REDaCT (REfactoringDependency and ConflicT).

– We develop the idea of refactoring to a de-sired design, introduced by the authors inearlier work [5], and show how it can be usedto guide the refactoring process more effec-tively. In particular we measure not only theeffect of a refactoring in terms of its directcontribution to achieving the desired design,but also its indirect contribution in terms ofthe refactorings it enables and disables. Thisextension to the REDaCT algorithm is re-ferred to as REDaCT+.The remainder of this paper is structured as

follows. Section 2 presents a motivating exampleto illustrate the necessity of scheduling refactor-ings. In Section 3 we deal with preliminaries byproviding a brief description of the software tool

Resolving Conflict and Dependency in Refactoring to a Desired Design 39

(a) The initial design (b) The desired design

Figure 1: UML class diagrams of an Event application

upon which our approach is based, Design-Imp,and defining precisely our notions of conflict anddependency. The proposed scheduling approachto find a valid order between the set of refactor-ings according to their conflict and dependencyrelationships, REDaCT, is explained in Section4, while in Section 5 the REDaCT+ algorithm ispresented which extends REDaCT by consider-ing the direct and indirect contribution of eachrefactoring to achieving the desired design. InSection 6 the REDaCT and REDaCT+ algo-rithms are evaluated on a number of examples.A survey of related work is presented in Sec-tion 7, while in Section 8 we conclude the paperand provide some suggestions for future work.

2. Motivating Example

Consider as a motivating example, the simpli-fied UML class diagrams shown in Figure 1.The design in Fig. 1a represents the originaldesign while the design in Fig. 1b representsthe desired design that the developer wouldlike the program to have. We applied the de-sign differencing approach proposed by the au-thors in earlier work [5] that takes as input twoUML class diagrams and then uses a UML de-sign differencing algorithm to find differencesbetween the designs and categorises these asrefactoring instances. In other words, the ap-

proach returns the refactorings that are requiredto bring a program design from its currentstate to a new desired design. In this exam-ple, the desired design is achieved after apply-ing 15 refactorings to the initial design as fol-lows:R1,R2: Two classes, Event and Concert, areadded to the design using Extract Hierarchy andExtract Subclass refactorings respectively.R3,R4: Field address and method setAddress,both in class Entertainment, are renamed to lo-cation and setLocation using Rename Field andMethod refactorings respectively. These refac-torings prepare the application of refactoringsR7 and R10 described below.R5,R6,R7: The location fields in classes Discus-sion and Reading and the field address in theclass Entertainment are pulled up to the classEvent using three separate Pull Up Field refac-torings.R8,R9,R10: The setLocation methods in classesDiscussion and Reading and the method setAd-dress in the class Entertainment are pulled upto the class Event using three separate Pull UpMethod refactorings. Refactorings R5 to R10 re-duce code duplication and improve readability.R11,R12,R13: Two methods getPrice and re-trieveDetails as well as the field conductor, alldefined in the class Entertainment, are pusheddown to the class Concert using two separatePush Down Method refactorings and one Push


Down Field refactoring respectively. The moti-vation for these refactorings is to move featuresthat are used only in some instances of the orig-inal class.R14,R15: To simplify the interface and im-prove understandability, the method retrieveDe-tails and the field conductor are made more pri-vate using the Decrease Method Accessibility andDecrease Field Accessibility refactorings respec-tively.

The aim is to find an order between theaforementioned refactorings that, while requir-ing the minimum effort, results in the desireddesign from the initial design. However, becauseof interdependencies between the refactorings,only some specific refactoring orders are appli-cable to the initial design. A list of interdepen-dencies between the aforementioned refactoringsis as below:– Refactorings R3 to R13 are directly depen-

dent on R1, or R2, i.e. a method or field can-not be moved to a class if the target classhas not been created yet.

– The setLocation methods in the class Discus-sion use the field location of the local class.Therefore, Pull Up setLocation (R8) shouldbe applied to the design after Pull Up loca-tion (R5). Were the method to be pulled upbefore the field, it would also be necessary toadd an instance of the local class as parame-ter to the method, resulting in a method withtwo input parameters, which differs from thecorresponding method in the desired design.

– For the same reason, two Pull Up Methodrefactorings, R9 and R10, should be appliedto the design only after their correspondingPull Up Field refactorings, R6 and R7, havebeen applied.

– The refactoring Rename address (R3) canbe applied to the design before or after PullUp address (R5). If R3 is performed beforeR5, then other two Pull Up Field refactor-ings namely R6 and R7 can be applied be-fore or after R3. Otherwise, R6 and R7 mustbe applied to the design after R3. The sec-ond case happens because a precondition inRename Field prevents the field name frombeing changed if there is already a field with

the same name in the class and the fields areused by different methods.

– The method getPrice should be pushed downto its subclass using refactoring R11 beforemoving the method retrieveDetails and thefield conductor. This is necessary as get-Price uses both this method and field. WereretrieveDetails or conductor to be pusheddown to the subclass (using R12 or R13) be-fore getPrice, then they would not be ac-cessible in getPrice. Similarly, the methodretrieveDetails should be moved before thefield conductor.

– The accessibility of the field conductor canbe reduced using R15 after the field is pusheddown to the subclass by R13. Were the ac-cessibility of the field to be reduced beforethe push down refactoring, then the fieldwould not be accessible in the subclass. Thiswould prevent the pushing down of the meth-ods getPrice and retrieveDetails as well asthe field itself to the subclass. A similar sit-uation arises for the Decrease AccessibilityMethod refactoring (R14). The accessibilityof the method retrieveDetails should be re-duced only after the method is pushed downto the subclass (R12) in order for it to beaccessible in getPrice.

– The above dependencies also reveal an im-plicit dependency between the two refactor-ings Decrease Accessibility Method (R14) andDecrease Accessibility Field (R15) with theExtract Subclass refactoring (R2). Both De-crease Accessibility refactorings can be per-formed only after the class Concert has beencreated and the corresponding methods andfields have been moved to the newly createdclass.As the example above demonstrates, there

can be many relationships between refactorings,and even in this simple motivating example it isdifficult to identify them all manually. As shown,the application of one refactoring may preventcertain other refactorings or make possible cer-tain other refactorings. What makes the refactor-ing process more difficult is that the effect of eachrefactoring is only seen after the refactoring is ap-plied to the design. The preconditions of a refac-


Figure 2: Typical workflow when using Design-Imp

toring fail at its turn even though they were sat-isfied at the start of the sequence, and vice versa.

We describe our automated scheduling ap-proach (REDaCT and REDaCT+) that ad-dresses these problems in Sections 4 and 5, butwe first present some preliminary informationabout the software tools we use in this work, andprecise definitions of conflict and dependency.

3. Preliminaries

This section provides some necessary prelimi-nary information about the software tool em-ployed in our experiments (Section 3.1) and for-mal definitions for conflict and dependency ina refactoring sequence (Section 3.2).

3.1. Design-Imp

The investigations described in this paper makeuse of a software tool named Design-Imp.Design-Imp is an interactive refactoring frame-work developed by the authors to facilitate ex-perimentation in improving the design of exist-ing programs. It refactors the software systemat a higher level of abstraction than its sourcecode. Figure 2 depicts a typical workflow whenusing Design-Imp.

Design-Imp takes Java version 7 sourcecode as input, extracts design information fromthe source code using the extract model pro-cess and expresses the extracted information asan attributed type graph [12]. This graph is

then refactored using an interactive evolution-ary search technique to improve the program ac-cording to a fitness function, expressed in termsof standard software quality metrics such asa combination of cohesion and coupling metrics.

The output comprises the refactored graph,expressed as a UML class diagram, as well asdetailed refactoring and metrics information. Asmost of the program detail, especially methodbodies, has been abstracted away, faster pre-condition checking and refactoring execution ispossible. The result of the refactoring process isa desired design based on the employed fitnessfunction and confirmed by the developer.

Design-Imp uses AGG API2 as a graphtransformation engine [13, 14] to implementgraph transformation rules. Each rule (i.e. refac-toring) includes a pattern that is specified bytwo graphs, left and right hand side, and a mor-phism between them. Transformation rules mayspecify negative and positive application condi-tions as transformation preconditions. A nega-tive application condition (NAC) specifies cer-tain structures that are forbidden, while a posi-tive application condition (PAC) expresses cer-tain structures that are necessary to performa transformation. Currently, Design-Imp sup-ports 20 refactorings shown in Table 1. In therest of this paper we use the term refactoringinstead of transformation rule when referring toa transformation on the graph.

Design-Imp defines a meta-model, expressedas a type graph, based on the syntax of the Javalanguage in order to specify how a Java program

2 http://user.cs.tu-berlin.de/∼gragra/agg/

http://user.cs.tu-berlin.de/~gragra/agg/


Table 1: A list of refactorings provided by Design-Imp

No. Class-Level Refactorings Description

1 Rename Class Changes the name of a class to a new name, and updates its references.2 Extract Hierarchy Adds a new subclass to a non-leaf class C in an inheritance hierarchy.3 Extract Subclass Adds a new subclass to class C and moves the relevant features to it.4 Extract Superclass Adds a new super class to class C and moves the relevant features to it.5 Collapse Hierarchy Removes a non-leaf class from an inheritance hierarchy.6 Inline Class Moves all features of a class into another class and deletes it.7 Extract Class Creates a new class and moves the relevant features from the old class

into the new one.

Method-Level Refactorings

8 Push Down Method Moves a method from a class to those subclasses that require it.9 Pull Up Method Moves a method from some class(es) to the immediate superclass.10 Rename Method Changes the name of a method to a new one, and updates its references.11 Decrease Method Accessibility Decreases the accessibility of a method, i.e from protected to private.12 Increase Method Accessibility Increases the accessibility of a method, i.e from protected to public.13 Move Method Creates a new method with a similar body in the class it uses most.

Either turns the old method into a simple delegation, or removes it.

Field-Level Refactorings

14 Push Down Field Moves a field from a class to those subclasses that require it.15 Pull Up Field Moves a field from some class(es) to the immediate superclass.16 Move Field Moves a field from a class to another one which uses the field most.17 Rename Field Changes the name of a field to a new name, and updates its references.18 Decrease Field Accessibility Decreases the accessibility of a field, i.e from protected to private.19 Increase Field Accessibility Increases the accessibility of a field, i.e from protected to public.20 Encapsulate Field Creates getter and setter methods for the field and uses only those to

access the field.

should be represented as a graph. It is not pos-sible to define all necessary Java constraints asa type graph, e.g. cyclical inheritance is hard toprevent, so we added some general constraintssimilar to those defined by Mens [15] to ourmodel.

Design-Imp is also capable of detecting con-flicts and dependencies between refactoringsthrough the use of a static analysis techniqueprovided by AGG API called critical pair anal-ysis. Critical pair analysis computes all the po-tential conflicts and dependencies between refac-torings based on the notion of independenceof graph transformations [12]. Using this tech-nique, Design-Imp can distinguish three kinds ofconflict and three kinds of dependency betweenrefactorings as described in Table 2. Definitionsfor conflict and dependency are presented nextin Section 3.2.

3.2. Definitions of Conflict andDependency between Refactorings

In this section we provide precise definitions forthe concepts of conflict and dependency. Theseare concerned with the relationships betweenrefactorings and are widely used in this paper.Definition 1: DependencyFor two given refactorings (R1 and R2), R2 isdependent on R1 (R2 → R1) if R2 can be ap-plied after R1, but not before that.

In this paper, as shown in Table 2, we dis-tinguish three types of dependency betweenrefactorings: produce-use, delete-forbid, andchange-use. A produce-use dependency can hap-pen if R1 produces an element that is used byR2. For example, in the motivating example,refactorings R3 to R15 are dependent on one ofR1 or R2. It is a kind of produce-use dependency


Table 2: Relationships that can be detected between refactorings using AGG [16]

No. Conflict Description

1 Delete – Use A refactoring deletes a graph object that is used by another refactoring.

2 Produce – Forbid A refactoring produces a graph structure that is forbidden by another refactoring.

3 Change – Use A refactoring changes an attribute value of a graph object in such a way that it canno longer be used by another refactoring.

No. Dependency Description

1 Produce – Use A refactoring produces a graph object that is used by another refactoring.

2 Delete – Forbid A refactoring deletes a graph objects that is forbidden by another refactoring.

3 Change – Use A refactoring changes an attribute value of a graph object in such a way that it canbe used by another refactoring.

as a method or field can be moved to a class onlyif the class has already been created.

As another example, consider a method thatuses directly a private field in its own class. Topush this method down to a subclass it is nec-essary first to increase the accessibility of thefield to at least protected to make it accessibleto the method in the subclass. In this case, thePush Down Method refactoring has a change-usedependency on the Increase Field Accessibilityrefactoring.Definition 2: Asymmetrical ConflictFor two given refactorings (R1 and R2), R1 hasan asymmetrical conflict with R2 (R1 9 R2)if R2 cannot be applied after R1.

In this paper, as shown in Table 2, wedistinguish three kinds of conflicts: delete-use,produce-forbid, and change-use. As an exam-ple, a delete-use conflict between R1, and R2

can happen if R1 deletes one or more elements(classes, methods, or fields) that are used by R2.

Asymmetrical conflict is a one-way conflict.Thus, a conflict between R1 and R2 (R1 9 R2)does not imply that the application of R2 willdisable R1. In addition, while an asymmetricalconflict is indeed a kind of dependency, we dis-tinguish between them in this paper. In a con-flict situation (R1 9 R2), both refactoringscan be run individually, but R2 cannot be runafter R1. However, in a dependency situation(R1 → R2), R2 can only be run if R1 is run first.Definition 3: Symmetrical ConflictFor two given refactorings (R1 and R2), R1 has

a symmetrical conflict with R2 (R1 = R2)if and only if they cannot both be performed onthe design in any order, i.e. (R1 9 R2 ∧R2 9R1 ⇒ R1 = R2).

As an example of a symmetrical conflict, con-sider a case where a method is moved fromthe same original class to two different tar-get classes using two separate Move Methodrefactorings. While both refactorings are ap-plicable, only one of them can be performedon the design. The other refactoring will failsubsequently as the method is no longer inits original class and so cannot be movedfrom there.Definition 4: Uninjurious RefactoringA refactoring with no symmetrical or asym-metrical conflict with any other refactoring istermed an uninjurious refactoring, in the termi-nology of Liu et al. [10]. This type of refactoringis of interest as it can be added to a refactoringsequence at any stage with no deleterious effectin terms of disabling other refactorings.

4. The REDaCT algorithm: HandlingConflict and Dependencyin Software Refactoring Scheduling

In this section we describe one of the key contri-butions of this paper: the creation of a refac-toring scheduling algorithm that can handlethe conflicts and dependencies described in Sec-tion 3.2.


To find a valid refactoring sequence, we ex-tend the conflict-aware scheduling approach pro-posed by Liu et al. [10]. They propose a heuris-tic algorithm to improve refactoring activities byarranging an application sequence for the avail-able conflicting refactorings. Their approachcomputes symmetrical and asymmetrical con-flicts between refactorings, where, in a conflictsituation, the refactoring that has more effecton software quality, as defined by the QMOODmetric suite [17], has a higher priority than theother one. The solution we present here improveson the approach of Liu et al. in the followingregards:– The approach of Liu et al. only supports

delete-use and change-use conflicts, anddoes not support produce-forbid conflicts, al-though they do propose this idea as futurework. A produce-forbid conflict occurs whena refactoring produces an element or struc-ture that is prohibited by the precondition ofanother refactoring [18]. Our approach han-dles all the conflict types in Table 2.

– The approach of Liu et al. does not sup-port any kind of dependency between refac-torings. In contrast, our approach is capa-ble of detecting all inter-refactoring depen-dency types as shown in Table 2. By con-sidering dependencies between refactorings,our scheduling algorithm is able to take intoaccount the effect of a refactoring in termsof the other refactorings that it enables,whereas Liu et al. only consider cases wherea refactoring disables other refactorings.

In Section 4.1 we describe how our refactoringscheduling algorithm, REDaCT, handles conflictand dependency relationships between refactor-ings. In Section 4.2 we discuss the strengthsand weaknesses of this approach to refactoringscheduling.

4.1. The REDaCT Scheduling Algorithm

Our proposed scheduling algorithm, REDaCTis presented as pseudocode in Fig. 3. As illus-trated, the algorithm takes as input the set ofrefactorings to be scheduled as well as a squarematrix, called RMatrix, that contains informa-

tion about how the input refactorings are relatedto each other. It is assumed that the refactoringsare all beneficial, so a perfect solution is whereall the refactorings can be applied. REDaCT isa heuristic that attempts to find the longest pos-sible valid sequence of refactorings that can beapplied to the initial design.

RMatrix is computed by Design-Imp andcontains information about conflicts and de-pendencies between refactorings. A character‘C’ in (rowi, columnj) of the matrix means anasymmetrical conflict exists between refactor-ings Ri and Rj , so applying Ri will preventRj from running. A symmetrical conflict willexist if (rowi, columnj) also contains a charac-ter ‘C’. On the other hand, a character ‘D’ in(rowi, columnj) means that Rj is dependent onRi, so Rj is only applicable if Ri has alreadybeen applied to the design. Note that a sym-metrical dependency is an impossibility.

The REDaCT scheduling algorithm is de-picted in Fig. 3. Five critical steps in the algo-rithm are highlighted and are elucidated in theparagraphs below:Step 1: In the first step, it is necessary tofind refactorings that are not dependent on anyrefactorings as well as having no conflict withother refactorings. A refactoring with no sym-metrical or asymmetrical conflict with otherrefactorings is selected in order to prevent itfrom being disabled by other refactorings thatmight have an asymmetrical conflict with it [10].However, such an uninjurious refactoring (seeSection 3.2) is only selected if it is also notdependent on any refactorings except those al-ready added to the refactoring sequence. Thisstep guarantees that, where possible, all refac-torings upon which a candidate refactoring isdependent are added to the refactoring sequenceearly in the process.

After a refactoring is added to the refactor-ing sequence, its corresponding row and columnis removed from RMatrix as well. The algorithmmay terminate at the end of first step if all refac-torings have been added to the refactoring se-quence. This only happens if there is no symmet-rical conflict between any pair of refactorings inthe set.


Step 2: In the second step, assuming that RMa-trix is not empty, the score for each applicablerefactoring Rc is computed using the followingformula:

score(Rc) = directEffect(Rc)+

positiveEffect(Rc)−negativeEffect(Rc)

(1)

It is assumed that each refactoring in therefactoring set has a positive effect, i.e. thatthe developer has selected only refactoringsthat have a positive effect on the design ofthe program. Therefore, the maximum qual-ity improvement is obtained if all refactoringsin the refactoring set are applied to the ini-tial design. Hence, we set the directEffect ofeach refactoring to 1, meaning that the ap-plication of each refactoring leads the refac-toring process one step closer to the maxi-mum achievable quality improvement. (Later,in Section 5, we will use a more sophisticatedapproach for computing the direct effect ofa refactoring.)

The application of a refactoring Rc enablesrefactorings that are dependent on Rc to be run,assuming that they are not dependent on otheravailable refactorings (see Section 3.2). In thispaper, we count all these effects as the positive-Effect of the candidate refactoring Rc. So thepositive effect of a candidate refactoring is thetotal number of refactorings that are enabledby it.

When a candidate refactoring Rc is appliedto the design, it also disables other refactorings,Ro, with which it has an asymmetrical conflict[10]. In addition, if Ro is disabled, its dependentrefactorings are disabled as well. In this paper,we count all these effects as the negativeEffectof the candidate refactoring, Rc. So the nega-tive effect of a candidate refactoring is the totalnumber of refactorings that are disabled by it.Step 3: In the third step, the refactoring withthe highest score is selected and added to therefactoring sequence. Since the score is based onthe number of refactorings that will be disabledor enabled by the refactoring, the selection ofa high-scoring refactoring promotes refactorings

that increase the number of refactorings that canbe selected in subsequent iterations.Step 4: After the best refactoring is added tothe refactoring sequence, it is necessary to up-date the scoring of refactorings that have beenpositively affected by the application of thisrefactoring. This includes refactorings that havean asymmetrical conflict with the selected refac-toring [10], as well as refactorings that are de-pendent on the selected refactoring. The scorefor these positively affected refactorings is up-dated using Eq. 2 below. As shown, the merit ofthe selected refactoring is added to its affectedones in order to increase their chance of beingselected in subsequent iterations.

score(Raffected) = score(Raffected)+

score(Rselected)(2)

As shown in Figure 3, after the best refac-toring is added to the refactoring sequence, allnewly disabled refactorings are also removedfrom RMatrix to prevent them from being need-lessly selected in subsequent iterations.

Step 5: In this step, refactorings that areneither dependent on, nor in conflict with, anyremaining refactorings are added to the refactor-ing sequence. They can be safely applied at thisstage, and doing so immediately prevents sucha refactoring from being subsequently disabledby a refactoring with a better score that has anasymmetrical conflict with it.

At the end of the algorithm, refactoringSeqwill contain the longest sequence of refactoringsfound that can be applied to the initial design.

4.2. Summary

To summarise this section, we have presentedthe REDaCT algorithm, which is our novel ap-proach to refactoring scheduling that extendsthe state of the art [10] by handling a moreextensive range of conflicts and dependencies.This algorithm is evaluated later in Section 6.REDaCT ignores the effect the refactorings havein terms of how close they bring the program toits desired design. In the next section we addressthis issue.


Input: refactoringSet: set of refactorings to be scheduled.Input: RMatrix: square matrix contains relationships between refactorings.Output: refactoringSeq: contains a valid order of refactorings.

procedure Scheduling Algorithm(refactoringSet, RMatrix )refactoringSeq = null

while (hasUninjuriousRefactoring()) do . Step 1refactoringSeq.add(pickUninjuriousRefactoring()updateRMatrix ()

end whileif (!RMatrix.isEmpty()) then

measureScore() . Step 2repeat

refactoringSeq.add(pickBestRefactoring())) . Step 3updateScores() . Step 4updateRMatrix ()while (hasUninjuriousRefactoring()) do . Step 5

refactoringSeq.add(pickUninjuriousRefactoring())updateRMatrix ()

end whileuntil (RMatrix.isEmpty())

end ifreturn refactoringSeq

end procedure

The functions used are defined as follows:hasUninjuriousRefactoring(): Returns true if RMatrix contains at least one independent and unin-jurious refactoring. Otherwise, returns false.pickUninjuriousRefactoring(): Returns the first independent and uninjurious refactoring.pickBestRefactoring(): Returns the refactoring with the highest score.updateRMatrix(): The selected refactoring is removed from RMatrix(). The refactorings with whichthe selected refactoring has a conflict are removed from RMatrix () as well.measureScore(): Computes the score for all remaining refactorings using equation 1.updateScores(): Updates the score for the affected refactorings using equation 2.

Figure 3: The REDaCT algorithm. It orders the input refactorings to create the longest possibleapplicable refactoring sequence, in the presence of conflict and dependency between the refactorings.

5. The REDaCT+ algorithm:Improving Refactoring Schedulingby Estimating the Contribution ofRefactorings to Achieving theDesired Design

The approach proposed by Liu et al. usesthe QMOOD metric suite [17] to measurethe effect of refactorings on software qual-ity. However, applying refactorings to the de-sign and measuring their effect requires con-siderable effort. In addition, as no depen-dency between refactorings is detected byLiu et al., the impact of each refactoring is

measured individually, and that cannot cap-ture the real effect of a sequence of refac-torings. In Section 5.1 below we describea known, string-based approach to compar-ing software designs and put this to noveluse in Section 5.2 to introduce a novel,lightweight approach to measuring the ef-fect of a refactoring without actually apply-ing the refactoring to the design. Finally,in Section 5.3, this approach to measuringrefactoring effect is included in the schedul-ing algorithm to improve the accuracy of thescheduling approach; we term this extensionREDaCT+.


5.1. Measuring Similarity betweenSoftware Designs

In this paper, an improvement in quality meansan improvement in the similarity between theinitial and desired designs. Therefore, during therefactoring process, a refactoring that improvesthe similarity between the initial and desired de-signs has priority over other refactorings.

To measure the degree of similarity betweentwo designs, REDaCT+ uses a sequence align-ment algorithm called Fast Optimal Global Se-quence Alignment Algorithm (FOGSAA) de-veloped by Chakraborty and Bandyopadhyay[19]. This algorithm is capable of finding thebest alignment between two input strings witha lower computational complexity than otherglobal alignment approaches. Full details ofthis algorithm are presented in the paper citedabove.

To use the FOGSAA alignment algorithm inREDaCT+, the first step is to represent pro-gram’s features such as classes, methods, fieldsetc. as a sequence of characters. In this paper, weuse the approach proposed by Kessentini et al.[20] as a method to represent program elementsas a string. Each element in the input Java pro-gram is represented using a specific characteras follows: Class (C), generalization relationship(G), realization relationship3 (I), attribute (A),method (M), method parameter (P), and a cou-pling between two classes (R). As an example,the representation of class B shown in Fig. 4a isCGMMPR. This sequence shows that the classinherits from another class, has a coupling rela-tionship with one other class in the program andcontains two methods, where the second methodhas a parameter.

However, our representation differs from thatof Kessentini et al. [20] in two significant ways.Firstly, in their work each character includesmore detailed information such as name, type,accessibility etc. depending on the program el-ement it represents. However, in our approachthe element name is the only information thatis included with each character. Secondly, inKessentini et al. [20] every method invocation

or field reference is represented by one R charac-ter. Therefore, if a class invokes a method in an-other class n times, n R characters are added tothe resulting string. However, the number of ac-cesses to fields and methods in a class is usuallyfar greater than the number of fields and meth-ods in the class, so this approach overempha-sises the importance of R relationships over theother types when measuring similarity. To im-prove the efficiency of the alignment algorithm,we use a single R character to denote a couplingfrom the original class to another class withoutcounting the number of connections between thetwo classes.

5.2. Expressing Refactoring Effect on theString Representation of a Program

Expressing the program as a sequence of charac-ters and using an alignment algorithm to mea-sure similarity between strings helps in measur-ing the effect of refactorings without actuallyapplying them to the design. However, in or-der to do this it is necessary to determine firsthow the resulting string should be changed whena refactoring is applied to it.

Figure 4 illustrates an example of how theMove Method refactoring changes the softwaredesign and the related string representation.In this example, method b2(c) is moved fromits original class, named B, to a related tar-get class named C. Figures 4a, and 4b showthe UML design and the related string beforeand after refactoring respectively. Because theclasses are related through the method param-eter, after refactoring the input parameter isremoved from the method signature. As illus-trated, the sequence that shows class A (thefirst part in each sequence indicated by CA)is not changed as the refactoring has no ef-fect on that. However, both sequences relatedto class B, and C (the second and third partsin each sequence) are changed because of therefactoring.

For each of the refactoring types in Ta-ble 1, its effect on the string representationof a program design is defined in a similar

3 Realization in Java is the relationship between a class and an interface that it implements.


(a) The initial design: CA (class A) CGMMPR(class B) CGAMR (class C)

(b) The refactored design: CA (class A)CGMR (class B) CGAMMRR (class C)

Figure 4: How refactoring effect is expressed on the string representation of a design.

way as described for the Move Method refac-toring. This enables us to estimate quicklythe approximate effect of a refactoring with-out having to operate on source code parsetrees. Note that the effect of a refactoring isonly measurable when all refactorings uponwhich it depends have been applied to the de-sign, e.g. the effect of a Move Method refac-toring is only measurable if the target classhas already been created. We use a topologi-cal sort to create a linear ordering of the refac-torings based on their dependency to ensurethat all refactorings upon which a refactoringdepends precede it in the ordering. Note thatthe refactoring sequence produced by the topo-logical sort algorithm does not show the op-timal ordering between refactorings as it doesnot take conflicts between refactorings into ac-count.

The quality improvement achieved bya refactoring is thus measured by the FOGSAAstring alignment algorithm. It expresses the dif-ference in similarity between the current anddesired designs before and after the appliedrefactoring. Using this approach, we can deter-mine, for any refactoring under consideration,to what extent it contributes to achieving thedesired design. In the next section we includethis measure in the refactoring scheduling ap-proach.

5.3. Including Refactoring Effect in theScheduling Algorithm

The REDaCT scheduling algorithm describedearlier in Section 4 tries to order the refactoringsso that the maximum number of refactorings canbe applied to the design. However, finding thelongest sequence of refactorings is not alwaysthe best option to order refactorings, especiallyif there are symmetrical conflicts between refac-torings, and different refactorings make differentcontributions to achieving the desired design.

To improve the scheduling algorithm, we ex-tend it to include the contribution of the refac-toring to achieving the desired design. We termthis contribution the refactoringEffect, and it ismeasured as described in Section 5.2. Thus, thescoring function defined by Eq. 1 in Section 4 ischanged as below. As shown, the default valuefor directEffect used in Eq. 1 is changed from1 to the contribution of the refactoring on thesimilarity between designs:

score(Rc) =refactoringEffect(Rc)+

positiveEffect(Rc)−negativeEffect(Rc)

(3)

All components of this summation are equallyweighted. Thus the decision on whether to ac-cept a refactoring depends equally on the con-


tribution the refactoring makes to the desireddesign, the effect of refactorings it enables andthe effect of refactorings it disables. In Section6 this new approach, REDaCT+, is evaluatedand it is compared with the vanilla REDaCTalgorithm.

6. Evaluation

We have presented an algorithm for refactoringscheduling in the presence of conflict and depen-dency (REDaCT) and augmented this algorithmto exploit a desired design, if one is available(REDaCT+). In this section we evaluate thesealgorithms by applying them to a number of ex-amples and assessing the results.

This section is structured as follows. In Sec-tion 6.1 we test the correctness of the REDaCTalgorithm by applying it to the Event systemdescribed in the motivating example of Section2. In Section 6.2 we demonstrate the necessityfor the REDaCT+ algorithm, and evaluate thisalgorithm. In Section 6.3 we evaluate the abilityof the REDaCT+ algorithm to schedule a ‘noisy’refactoring sequence to achieve a desired design,while in Section 6.4 we evaluate the REDaCT+algorithm on a medium-sized open source appli-cation. In Section 6.5 we summarise the resultsof our experiments.

6.1. Testing the correctness of theREDaCT algorithm

To test that the scheduling algorithm operatescorrectly, we applied it to the Event system thatwas used as a motivating example in Section2. The aim is to determine if our refactoringscheduling algorithm can order the refactoringsin such a way as to generate the desired designshown in Fig. 1b from its initial one depictedin Fig. 1a. The refactorings in question are R1

to R15 as defined in Section 2. As detailed inthat section, a considerable amount of conflictand dependency exists between these refactor-ings and it is not immediately clear if they canall be applied to the initial design or not, so thisforms a robust test for the REDaCT algorithm.

Applying REDaCT to the refactoring setshown in Section 2 yielded an ordering that en-abled all 15 refactorings to be applied to thedesign as follows: R1, R3, R5, R8, R4, R2, R6,R7, R10, R9, R11, R12, R13, R14, R15. The result-ing design was identical to the refactored design,meaning that the refactorings were indeed per-formed in the correct order. As no symmetricalconflict was detected between the input refac-torings, all 15 refactorings could be applied tothe design.

The example used here is small, but the con-flicts and dependencies between the refactoringsare more complicated than would usually be en-countered in a real-world system. In a larger sys-tem, typically only a few refactorings are appliedto a class and its immediate relatives, so the levelof conflict and dependency tends to be lower andsparser than in the example we use here. Nev-ertheless, when such conflicts and dependenciesoccur, they have to be addressed.

The result we obtain above demonstrates theability of the REDaCT algorithm to handle theconflicts and dependencies between refactoringsand hence to find an effective application orderfor the given refactorings.

6.2. Contrasting the REDaCT andREDaCT+ algorithms

The example we use here is a simplistic Au-tomatic Teller Machine (ATM) simulation ap-plication [21]. It was developed by an inexperi-enced Java programmer, and so we expect thatits design is not optimum and is easy to im-prove. Using Design-Imp, this ATM applicationwas refactored using a fitness function defined asa combination of the two software metrics SCC(Similarity-based Class Cohesion) [22] and DCC(Direct Class Coupling) [17]. Table 3 depicts therefactoring sequence R1 . . . R10 that led to thedesign for the ATM system depicted in Fig 5.

When REDaCT was applied to the origi-nal ATM design and the set of refactorings, itproduced the refactoring sequence R8, R5, R1,R2, R4, R3, R6, R9, R7, R10. This refactoring se-quence is correct in that it yields the de-sired design when applied to the original ATM


Figure 5: UML class diagram of an ATM application after refactoring

program design. However it is apparent thatduring the refactoring process the methodsprintReceipt() and displayBalance() are need-lessly moved around various classes before beingplaced in their final target class.

To test if REDaCT is capable of find-ing a better sequence, we added two newMove Method refactorings, R11 and R12, to therefactoring set. These new refactorings directlymove the methods printReceipt() and display-Balance() from their original class to their cor-rect target class. These refactorings are high-lighted in grey in Table 3. The addition of thenew refactorings created two symmetrical con-flicts as follows: R1 = R12, and R3 = R11, and,because of the dependencies among the refactor-ings, three new symmetrical conflicts as follows:R2 = R12, R6 = R11 and R9 = R11.

In this new situation, an optimal schedul-ing algorithm should select both new MoveMethod refactorings instead of other refactorings(R1, R2, R3, R6 and R9), as the newly addedMove Method refactorings move the methods di-rectly to their target class, which is the clear-est and most comprehensible solution. However,the REDaCT algorithm still selects the samesequence as it did before, without includingR11 and R12 in the sequence. This happens be-

cause the REDaCT algorithm favours refactor-ings that in turn increase the number of refactor-ings that can be selected in subsequent iterationsof the algorithm.

We tested if the REDaCT+ algorithm couldfind the optimum refactoring sequence for theexample described above, where the vanillaREDaCT algorithm failed, and found that theimproved REDaCT+ algorithm did indeed findthe equally good, but shorter, order amongthe 12 input refactorings shown in Table 3.REDaCT+ moved the two methods printRe-ceipt, and displayBalance directly to their tar-get class using the two added Move Methodrefactorings R11 and R12, and rejected thenow-superfluous refactorings R1, R2, R3, R6 andR9. REDaCT+ succeeded as it does not simplyapply the maximum number of refactorings asREDaCT does, but it uses its knowledge of thedesign desired to select refactorings that movedthe program design towards this desired design,as detailed in Section 5.

6.3. Evaluating REDaCT+ on a ‘noisy’refactoring sequence

To test how REDaCT+ would deal with a largerapplication, we applied it to the Design-Imp


Table 3: Sequence of refactorings applied to the ATM application. R1 to R10 represent the sequenceproduced by Design-Imp in creating the design of Fig. 5. R11 and R12 were both added by handto test the REDaCT+ algorithm.

No. Refactoring Feature Source class Target class

R1 Move Method displayBalance() Transaction CustomerInfoR2 Move Method displayBalance() CustomerInfo ATMR3 PullUp Method printReceipt() ATM AccountR4 Encapsulate Field customers AccountR5 PushDown Method print() CustomerInfo AccountR6 PullUp Method printReceipt() Account CustomerInfoR7 Decrease Method Accessibility displayBalance() ATMR8 Encapsulate Field holderName CustomerInfoR9 Move Method printReceipt() CustomerInfo TransactionR10 Decrease Method Accessibility printReceipt() Transaction

R11 Move Method printReceipt() ATM TransactionR12 Move Method displayBalance() Transaction ATM

software itself. Design-Imp contains 65 classesthat include 227 attributes and 600 methods,and so is larger than the earlier examples. Inthis experiment we also wanted to test how wellREDaCT+ could deal with a ‘noisy’ refactor-ing set, one that contains redundant refactoringsand so is a superset of the set of refactorings re-quired to bring the initial program to its desireddesign.

The ‘noisy’ refactoring set was created as fol-lows. First we use Design-Imp to automaticallyrefactor the Design-Imp software twice in or-der to create two separate desired designs. Asdescribed in Section 3.1, the search-based algo-rithm used by Design-Imp is a stochastic oneso each refactoring process yields a different setof refactorings but with the possibility of somecommonality between the two refactoring sets.Fig 6 shows a breakdown of the combined set ofrefactorings produced by both refactoring pro-cesses. The ‘noisy’ refactoring set then is theunion of these two sets. Duplicates were not re-moved, so this set (technically a multiset) con-tained 60 refactorings in total. In fact only onerefactoring appeared in both refactoring sets, sothe combined set contained 59 unique refactor-ings. A total of 3 conflicts and 298 dependencieswere found to exist in this combined refactor-ing set.

We then selected one of these resultingdesigns as the final desired design and used

REDaCT+ to try to refactor the initial de-sign towards the selected final desired design.This is a robust challenge, where both theconflict and dependency aspects of the baseREDaCT algorithm have to combine with the‘desired design’ aspects of the REDaCT+ al-gorithm in order to filter out the unnecessaryrefactorings and attempt to produce a refactor-ing sequence that yields the given desired de-sign.

REDaCT+ was able to find a refactoring se-quence that was 93% correct and brought theprogram design to one close to the given desireddesign. In two cases the algorithm categorisedtwo correct Move Field refactorings as detrimen-tal even though both refactorings were critical toachieving the desired design. This problem oc-curred as Design-Imp incorrectly detected a spu-rious dependency between these two refactoringsand another truly detrimental refactoring.

To sum up, this example shows the ability ofthe REDaCT+ algorithm to filter out refactor-ings that do not help in achieving the desired de-sign. It also reveals how invalid inter-refactoringdependencies detected by Design-Imp can affectthe accuracy of the REDaCT+ algorithm, lead-ing to two correct refactorings being ignored.From this we see that the ability of REDaCT+to correctly order a refactoring set is dependenton the accuracy of the detected conflicts and de-pendencies between the refactorings.


Figure 6: Breakdown of the 60 refactorings included in the refactoring set

6.4. Evaluating REDaCT+ on an opensource example

To investigate how REDaCT+ works witha non-trivial open source application, we usedJGraphX 4 as an application to investigate.JGraphX is a medium-sized Java library that isused to display interactive diagrams and graphsand comprises 188 classes, 1356 attributes and2908 methods.

In this experiment, we used Design-Imp toautomatically refactor the design of the origi-nal JGraphX application to create a desired de-sign to use in our experiments. We then usedDesign Imp to generate a refactoring set fromthe differences between the two designs, whichyielded a refactoring set containing 50 refactor-ings.

To test the REDaCT+ algorithm, we ap-plied it to the initial and desired designs ofthe JGraphX application as well as the gen-erated refactoring set. The challenge here isthat this is an open source application that theexperimenters have no a priori knowledge of,and the refactoring set is non-trivial in size.However, REDaCT+ produced a refactoring se-quence that transformed the initial design tothe desired design with 100% success and withno spurious refactorings appearing in the se-quence.

Note that in a large software system there aremany possibilities for refactoring, and the size ofthe system tends to lead to less dependency andconflict between applied refactorings. However,as mentioned, the aim of this experiment wasto show the proposed approach can be used forlarger applications as well.

6.5. Evaluation Conclusion

The goal of this evaluation section was to pro-vide an overall assessment of how the REDaCTand REDaCT+ algorithms perform when facedwith a variety of challenges.

We demonstrated the basic correctness of theREDaCT algorithm in Section 6.1 by showingthat it able to correctly sequence a heavily con-flicted and interdependent set of refactorings.While the refactoring set was small in size, theintensity of the conflict and dependency was fargreater than that found in our tests with an opensource example in Section 6.4.

In Section 6.2 we demonstrated that, whenseveral options exist, REDaCT fails to findthe shortest refactoring sequence but thatREDaCT+ is able to succeed by using its extraknowledge of the desired design that the refac-toring sequence is trying to achieve. This estab-lished the case for the the REDaCT+ algorithmand this is the algorithm that we evaluate fur-ther.

In Section 6.3 we demonstrated thatthe REDaCT+ algorithm can schedulea ‘noisy’ refactoring sequence that has manyoptically-relevant but useless refactorings. Aperfect solution was not achieved, but the 93%success rate is very satisfactory. In effect thismeans that a design very close to the desireddesign is achieved, and it is left to the developerto perform the final refactoring steps by hand.

In our final evaluation in Section 6.4 wedemonstrated that the REDaCT+ algorithmcan find a correct refactoring sequence whentrying to schedule a non-trivial refactoring set(50 refactorings) on a medium-sized open source

4 http://www.jgraph.com/jgraphdownload.html

http://www.jgraph.com/jgraphdownload.html


application. This demonstrates that REDaCT+can perform well in a more realistic context.

We found that the size of program under in-vestigation has only a minor effect on the speedof the REDaCT+ scheduling algorithm. Theonly time-consuming part is the algorithm usedto identify conflicts and dependencies betweenrefactorings. The number of comparisons to findconflict and dependency between refactorings isequal to n ∗ (n− 1)/2, where n is the number ofrefactorings included in the refactoring set.

7. Related Work

The work related to this paper can be di-vided into three research areas: ranking refac-toring opportunities, search-based refactoringand scheduling refactoring. These topics are dis-cussed below.

Ranking refactoring opportunities involvessorting refactoring opportunities according toone or more criteria such as their impact on theoverall design quality. Tsantalis and Chatzige-orgiou [23] propose a semi-automatic approachto identifying refactoring opportunities relatedto code smells based on system history and findthat a refactoring opportunity involving a highlychangeable code fragment is most likely to beimproved through refactorings in the future, andtherefore such refactorings should have a higherpriority than others. In other work they pro-pose an approach for detecting Move Methodrefactoring opportunities based on code smells[24] and also propose an approach to findingrefactoring opportunities that introduce poly-morphism as an alternative to state checking[25]. In these approaches, detected refactoringopportunities are ranked based on their impacton the overall design quality. However, the effectof refactorings is measured individually, with-out considering impact of refactorings on oneanother, and so it cannot guarantee to find thebest sequence in which to apply the proposedrefactorings.

In contrast to the aforementionedsemi-automatic approaches, other researchworks aim to automate the whole process by

using search based refactoring to find and applya sequence of refactorings to a program [26].In this approach, the process of refactoring isguided by a fitness function and a refactor-ing is accepted only if it improves the meritof the design based on metrics included in thefitness function. This approach has been usedfor several purposes: software quality improve-ment [27,28], to fix code smells [20,29] and to ap-ply design patterns [30]. Although search-basedrefactoring techniques help to automatically finda close-to-optimal sequence of refactorings basedon the employed fitness function, they do notusually generate the most effective refactoringorder.

In the remainder of this section we examineclosely related research that also aims to detectdependencies and conflicts between refactoringsin order to sort refactorings into an optimum or-der for application. Mens et al. [11] use paralleland sequential dependency analysis to detect re-lationships among a set of input refactorings. Likeour approach, the program and refactoring activ-ities are considered as a graph and graph-basedrules respectively. However, they only focuson specifying relationship between refactoringswithout introducing a practical algorithm on howthe refactorings should be arranged. Further, intheir work, sequential dependencies are only de-tected after a candidate refactoring is applied tothe design and then find out which refactoringsbecome applicable or inapplicable. Thus, the ap-proach cannot detect existing sequential depen-dencies between refactorings at once without ap-plying refactorings to the source code.

Zibran and Roy [31] introduce a schedul-ing approach based on three factors: maximisedquality gain measured based on standard soft-ware quality metrics, minimised refactoring ef-fort estimated by a proposed refactoring effortmodel and satisfaction of higher priorities de-fined manually by the developer. They formu-late the scheduling of code clone refactorings asa constraint satisfaction optimisation problem,and use constraint programming to implementthe proposed model.

Estimation of clone refactoring effort usingan effort model has also been investigated by


Bouktif et al. [32]. They use a simple geneticalgorithm to schedule clone refactoring activi-ties in order to achieve the greatest quality im-provement with minimum resource consumptionwhile satisfying priority constraints. However,they ignore conflicts between clone refactoringsand assume that duplicated codes can be refac-tored independently, which is not a correct as-sumption.

Among the research works focused onscheduling code smell refactoring, the work ofLiu et al. [10] is most closely related to ours.They propose a heuristic algorithm to schedulecode smell refactorings. We extend their refac-toring scheduling algorithm by considering notjust conflicts between refactorings but also de-pendencies. Furthermore, we take into accounta type of refactoring conflict not handled in theirwork, where the application of one refactoringviolates the precondition of another. We also in-troduce the idea of a desired design and showhow it can be included in the scheduling al-gorithm to guide the refactoring process moreeffectively. We measure not only the effect ofa refactoring in terms of its direct contributionto achieving the desired design, but also its indi-rect contribution in terms of the refactorings itenables and disables. Later work by Liu at al. [2]looks at the related problem of scheduling codesmell detection and resolution when a softwaresystem is radically refactored in ‘batch’ mode.They show that the order in which code smellsare addressed is significant due to the overlapbetween smells, and show that refactoring effortcan be reduced significantly (by up to 20%) byappropriate scheduling.

Lee et al. [33] also take into account thata refactoring can also enable other refactorings.They use a genetic algorithm to identify an ap-propriate refactoring schedule for code clones.To support both cases, the original refactor-ing set is updated according to changes ap-plied in the program after the refactoring is per-formed. The effect of each refactoring sequenceexpressed as a chromosome is measured usingthe QMOOD quality model [17]. However, thefitness evaluation is expensive due to the factthat each chromosome must be individually ap-

plied to the system and then its effect on qual-ity measured. It is different from our approach,where refactorings are applied to a sequence ofcharacters (representing the source code) andeach refactoring is simulated only once and itseffect on the quality is measured at that time.

8. Conclusions and Future Work

In this paper we presented the REDaCT algo-rithm, our approach to refactoring schedulingin the presence of inter-refactoring conflicts anddependencies that extends the state of the art [10]by handling a more extensive range of conflictsand dependencies. We also developed an exten-sion to this algorithm, REDaCT+, that also takesinto account the contribution of each refactoringtowards achieving a given desired design for thesoftware. To validate our proposed schedulingapproach, we carried out evaluations on fourexamples: two small constructed examples, asoftware tool developed by the authors and amedium-sized open source software system. Theresults obtained demonstrated that REDaCT canorder a refactoring sequence in the presence ofconflicts and dependencies, that REDaCT+ canoutperform REDaCT and that REDaCT+ workswell even when many irrelevant refactorings areincluded in the refactoring set.

In future work we plan to explore further theprocess of creating the desired design, using aninteractive process similar to that proposed bySimons et al. [3, 4]. This paves the way for theREDaCT+ refactoring algorithm to form partof a larger, interactive framework that helps thedeveloper to create a desired design, and thenrefactors the code to comply with this design, anotion described in our earlier work [5]. In thiscontext, more extensive evaluation with largersoftware systems and with software developerswill be necessary.

Acknowledgement

This work was funded by the Irish Pro-gramme for Research in Third-Level Institutions


(PRTLI) and in part by Science Foundation Ire-land grant 10/CE/I1855 to Lero – the Irish Soft-ware Research Centre (www.lero.ie).

References

[1] E. Murphy-Hill and A. P. Black, “Refactor-ing tools: Fitness for purpose,” IEEE Software,Vol. 25, No. 5, 2008, pp. 38–44.

[2] H. Liu, Z. Ma, W. Shao, and Z. Niu, “Sched-ule of bad smell detection and resolution: Anew way to save effort,” IEEE Transactions onSoftware Engineering, Vol. 38, No. 1, 2012, pp.220–235.

[3] C. L. Simons, I. C. Parmee, and R. Gwynllyw,“Interactive, evolutionary search in upstreamobject-oriented class design,” IEEE Transac-tions on Software Engineering, Vol. 36, 2010,pp. 798–816.

[4] C. L. Simons and I. C. Parmee, “Elegantobject-oriented software design via interactive,evolutionary computation,” IEEE Transactionson Systems, Man, and Cybernetics: Part C Ap-plications and Reviews., Vol. 42, No. 6, Novem-ber 2012, pp. 1798–1805.

[5] I. Hemati Moghadam and M. O Cinneide, “Au-tomated refactoring using design differencing,”in Proceedings of the 16th European Conferenceon Software Maintenance and Reengineering,ser. CSMR ’12. Washington, DC, USA: IEEEComputer Society, 2012, pp. 43–52.

[6] I. Hemati Moghadam, “Multi-level automatedrefactoring using design exploration,” in Pro-ceeding of the 3rd International Symposium onSearch Based Software Engineering, ser. SSBSE’11. Springer, September 2011, pp. 70–75.

[7] Z. Xing and E. Stroulia, “Differencing logicalUML models,” Journal of Automated SoftwareEngineering., Vol. 14, June 2007, pp. 215–259.

[8] ——, “Refactoring detection based on UMLDiffchange-facts queries,” in Proceedings of the 13thWorking Conference on Reverse Engineering.Washington, DC, USA: IEEE Computer Soci-ety, 2006, pp. 263–274.

[9] I. Hemati Moghadam and M. O Cinneide,“Code-Imp: a tool for automated search-basedrefactoring,” in Proceeding of the 4th workshopon Refactoring tools, ser. WRT ’11. New York,NY, USA: ACM, 2011, pp. 41–44.

[10] H. Liu, G. Li, Z. Y. Ma, and W. Z. Shao,“Conflict-aware schedule of software refactor-ings.” IET Software, Vol. 2, No. 5, 2008, pp.446–460.

[11] T. Mens, G. Taentzer, and O. Runge,“Analysing refactoring dependencies usinggraph transformation,” Software and SystemsModeling, Vol. 6, No. 3, 2007, pp. 269–285.

[12] R. Heckel, J. M. Kuster, and G. Taentzer, “Con-fluence of typed attributed graph transforma-tion systems,” in Graph Transformation, ser.Lecture Notes in Computer Science. Springer,2002, Vol. 2505, pp. 161–176.

[13] G. Taentzer, “AGG: A tool environment for al-gebraic graph transformation,” in Applicationsof Graph Transformations with Industrial Rele-vance, ser. Lecture Notes in Computer Science,Vol. 1779. Springer, 2000, pp. 481–488.

[14] ——, “AGG: A graph transformation environ-ment for modeling and validation of software,”in Applications of Graph Transformations withIndustrial Relevance, ser. Lecture Notes in Com-puter Science. Springer, 2004, Vol. 3062, pp.446–453.

[15] T. Mens, “On the use of graph transformationsfor model refactoring,” in Generative and trans-formational techniques in software engineering.Springer, 2006, pp. 219–257.

[16] O. Runge, “The AGG 1.5.0 developmentenvironment – the user manual,” 2014. [On-line]. http://user.cs.tu-berlin.de/∼gragra/agg/AGG-ShortManual/AGG-ShortManual.html

[17] J. Bansiya and C. Davis, “A hierarchical modelfor object-oriented design quality assessment,”IEEE Transactions on Software Engineering,Vol. 28, 2002, pp. 4–17.

[18] L. Lambers, H. Ehrig, and F. Orejas, “Conflictdetection for graph transformation with nega-tive application conditions,” in Graph Transfor-mations, ser. Lecture Notes in Computer Sci-ence. Springer, 2006, Vol. 4178, pp. 61–76.

[19] A. Chakraborty and S. Bandyopadhyay,“FOGSAA: Fast optimal global sequencealignment algorithm,” Scientific reports, Vol. 3,2013.

[20] M. Kessentini, R. Mahaouachi, and K. Ghedira,“What you like in design use to correctbad-smells,” Software Quality Journal, Vol. 21,No. 4, 2013, pp. 551–571.

[21] O. Mursleen, “Java code for atmoperations,” June 2010. [Online]. http://freesourcecode.net/javaprojects/13191/Java-code-for-ATM-Operations#.VL PC6YqYaA

[22] J. A. Dallal and L. C. Briand, “Anobject-oriented high-level design-based classcohesion metric,” Journal of Information &Software Technology, Vol. 52, No. 12, 2010, pp.1346–1361.

http://user.cs.tu-berlin.de/~gragra/agg/AGG-ShortManual/AGG-ShortManual.html

http://user.cs.tu-berlin.de/~gragra/agg/AGG-ShortManual/AGG-ShortManual.html

http://freesourcecode.net/javaprojects/13191/Java-code-for-ATM-Operations#.VL_PC6YqYaA




[23] N. Tsantalis and A. Chatzigeorgiou, “Rank-ing refactoring suggestions based on histori-cal volatility,” in Proceedings of the 15th Euro-pean Conference on Software Maintenance andReengineering, ser. CSMR ’11. IEEE ComputerSociety, March 2011, pp. 25–34.

[24] ——, “Identification of move method refactor-ing opportunities,” IEEE Transactions on Soft-ware Engineering, Vol. 35, 2009, pp. 347–367.

[25] ——, “Identification of refactoring opportuni-ties introducing polymorphism,” Journal of Sys-tems and Software, Vol. 83, March 2010, pp.391–404.

[26] O. Raiha, “A survey on search-based soft-ware design,” Computer Science Review, Vol. 4,No. 4, 2010, pp. 203 – 249.

[27] M. Harman and L. Tratt, “Pareto optimalsearch based refactoring at the design level,”in Proceedings of the 9th annual Conferenceon Genetic and Evolutionary Computation, ser.GECCO ’07. New York, NY, USA: ACM, 2007,pp. 1106–1113.

[28] M. O’Keeffe and M. O Cinneide, “Search-basedrefactoring for software maintenance,” Journalof Systems and Software, Vol. 81, No. 4, 2008,pp. 502–516.

[29] A. Ouni, M. Kessentini, H. Sahraoui, and

M. Boukadoum, “Maintainability defects de-tection and correction: a multi-objective ap-proach,” Automated Software Engineering,Vol. 20, No. 1, 2013, pp. 47–79.

[30] A. C. Jensen and B. H. Cheng, “On the useof genetic programming for automated refactor-ing and the introduction of design patterns,” inProceedings of the 12th annual Conference onGenetic and Evolutionary Computation, 2010,pp. 1341–1348.

[31] M. F. Zibran and C. K. Roy, “Conflict-aware op-timal scheduling of prioritised code clone refac-toring,” IET Software, Vol. 7, No. 3, 2013, pp.167–186.

[32] S. Bouktif, G. Antoniol, E. Merlo, andM. Neteler, “A novel approach to optimizeclone refactoring activity,” in Proceedings of the8th Annual Conference on Genetic and Evolu-tionary Computation, ser. GECCO ’06. Seattle,Washington, USA: ACM, 8-12 July 2006, pp.1885–1892.

[33] S. Lee, G. Bae, H. S. Chae, D.-H. Bae, and Y. R.Kwon, “Automated scheduling for clone-basedrefactoring using a competent GA,” Software:Practice and Experience, Vol. 41, No. 5, 2011,pp. 521–550.

resolving conflict and dependency in refactoring to a desired … · 2018-12-15 · tomate this...

Documents