Researchers focused on activities such as clone maintenance to assist the programmers. Refactoring is a well-known process to improve the maintainability of the software. Program refactoring is a technique to improve readability, structure, performance, abstraction, maintainability, or other characteristics by transforming a program. This paper contributes to a more unified approach for the phases of clone maintenance with a focus on clone modification. This approach uses the refactoring technique for clone modification. To detect the clones ‘CloneManager’ tool has been used. This approach is implemented as an enhancement to the existing tool CloneManager. The enhanced tool is tested with the open source projects and the results are compared with the performance of other three existing tools.

1.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 2013 Method-Level Code Clone Modification using Refactoring Techniques for Clone Maintenance E. Kodhai1, S. Kanmani21 Research Scholar, Department of CSE, Pondicherry Engineering College , Puducherry, India. kodhaiej@yahoo.co.in 2 Department of IT, Pondicherry Engineering College, Puducherry, India. kanmani@pec.eduABSTRACTResearchers focused on activities such as clone maintenance to assist the programmers. Refactoring is awell-known process to improve the maintainability of the software. Program refactoring is a technique toimprove readability, structure, performance, abstraction, maintainability, or other characteristics bytransforming a program. This paper contributes to a more unified approach for the phases of clonemaintenance with a focus on clone modification. This approach uses the refactoring technique for clonemodification. To detect the clones ‘CloneManager’ tool has been used. This approach is implemented as anenhancement to the existing tool CloneManager. The enhanced tool is tested with the open source projectsand the results are compared with the performance of other three existing tools.KEYWORDSCode clone, Refactoring, Software maintenance.1. Introduction It is generally said that code clone is one of the factors that make software maintenancemore difficult [6]. Code clone is a code fragment that is identical or similar to another. Codeclones are introduced for various reasons like reusing code by ‘copy-and-paste’. Code clonedetection techniques can be categorized based on the types of clones they can detect [4] [36].Many clone detection approaches that can uncover duplication in large scale software systemshave been proposed [24- 28][30-31][37]. Information retrieval technique proposed in [18] is to detect trends and associationsamong the clustered clone classes and determine if they provide further comprehension to assistin the maintenance of clones. Nguyen et al. [20] have developed a clone management tool JSyncto notify developers change and its inconsistency of code clones in source files. Sandro et. al [23]approach is to take into account detailed code clone analysis and classification as well as how theanalysis results are presented to the user in order to guide an interactive removal process. One technique that helps to process the code clones is Refactoring. Refactoring is adisciplined technique for restructuring an existing body of code, altering its internal structureDOI : 10.5121/acij.2013.4202 7

2.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 2013without changing its external behavior [6]. By making refactoring efforts on a set of code clones,they can be merged into a method [5, 15], a component [7], or an aspect [9]. Program refactoring is not a very simple technique to apply. Firstly, it is often verydifficult to identify which part of the program should be refactored without understanding thebasic notion of software quality. Secondly, software in practice is so large in scale that developershave to spend a decent amount of time to inspect the whole target software. Finally, programrefactoring potentially introduces a new bug in the source code because it does require a sourcecode modification. Although, numerous techniques and tools have been proposed for code clone detection[30] and [31], only little has been known about which detected code clones are appropriate forrefactoring and how to extract code clones for refactoring. Roy [22] proposed an IntegratedDevelopment Environment (IDE) based clone management system to ﬂexibly detects, manage,and refactor both exact and near-miss code clones. Rajlich [16] use different ways of restructuring functions to remove clones. Komondor[32] and Liu [33] suggested approaches to extract a function from the clones, which is similar toExtract Method. These works provide extensive mechanisms for function extraction in procedurallanguages. Li and Thompson [34] proposed code clone removal for the functional languageErlang. This technique is integrated within a refactoring environment for the language. Thedetection process is limited to the associated detection tool for Erlang. The refactoring functions are performed one at a time on each duplicate code detected.Robert Tairas [19] conclude that sub-clone refactoring should be considered to augmentrefactoring performed on the entire clone. Popular development environments such as Eclipse,semi automatic refactorings [17] implementing Visual Studio or Squeak the programmer specifieswhich refactoring patterns to be applied and where to be applied. In this paper, we show that the existing refactoring patterns [6] can be used to modifycode clones and we propose an approach to support refactoring process by applying code clonedetection techniques. Furthermore, a tool CloneManager [38] is extended to support our proposedapproach. The functionality of this tool is to find certain code clones to which the refactoringpatterns can be applied. Existing refactoring patterns has different levels of elements for identifying refactoringopportunities such as field, method, class, objects, etc. As the detected clones by theCloneManager tool are methods, we need to go for identifying the method level refactoringopportunities. Moreover, as we are extending the CloneManager tool, it becomes capable of bothdetection and modification of clones as by its name. This paper is presented in four major sections. Section 2 presents the related work. Section 3presents the basics of refactoring. Section 4 describes the existing CloneManager tool [38].Section 5 describes the implementation of the proposed approach. Section 6 discusses theresults obtained using our proposed approach. Finally, section 7 concludes the paper. 8

3.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 20132. Related Work The tool Aries developed by Yoshiki et. al [3][10] supports removal of code clones fromsource code. This tool applies the characterization of code clones by some metrics, which suggesthow to remove them. A refactoring support tool was developed by them to remove code clones.This tool is developed for detecting only two types of refactoring patterns namely extract methodand pull up method. They have evaluated the tool with the open source software ant 1.6.0. The RefactoringCrawler tool developed by Danny Dig et. al. [8] detects refactoringpattern or performs refactoring during component evolution, by combining Shingles encodingwith traditional semantic analyses, and by iterating the analyses until a fixed point wasdiscovered. They detect over 85% of the refactoring opportunities. This is mainly useful for cloneevolution than maintenance. The CeDAR which stands for Clone Detection, Analysis, and Refactoring is developedby Robert Tairas [2]. A unified process where the phases of clone maintenance with a focus onclone removal (i.e., detection, analysis, and refactoring) are streamlined together within theprogrammer’s working environment. In this work, the extract method refactoring pattern alonehas been developed. The existing refactoring tool RefactoringCrawler is developed for clone evolution and notfor clone maintenance. The tools Aries and CeDAR are tools developed for clone maintenancebut with limited refactoring patterns applied such as extract method and/or pull up method.Whereas our proposal has applied three refactoring patterns such as extract method, move methodand pull up method.3. Program refactoring Refactoring is the process of changing the structure of a program while maintaining all of itsfunctionality. There are many types of refactoring patterns such as renaming a class, changing amethod signature, extracting some code. With each refactoring patterns, a number of steps arecarried out to keep the code consistent with the original code. Each refactoring patterns includesboth a description of a refactoring opportunity i.e., a set of code fragments that should berefactored and the corresponding procedure to perform refactoring. Martin Fowler et al.[6] introduced a catalog for refactoring patterns where they used astandard format to represent frequently needed refactoring process. They initially introduced 72refactoring patterns and later the number has been increased to 93[35]. In this work we apply only3 refactoring patterns as our detected clones are methods. They are extract method, move methodand pull up method. The following subsections will explain each of the refactoring patterns indetail.3.1 Extract Method Refactoring “Extract Method Refactoring” is intended for “a code fragment that can be groupedtogether”[6]. Refactoring turns this fragment into a method whose name explains the purpose of 9

4.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 2013the method. The rationale is that if there is a very large method that does require some addedcomments to understand its purpose, turning a fragment of code into method will increase theunderstandability. Fowler also emphasizes the importance of selecting an appropriate short namefor the extracted method refactoring. The “Extract Method” is classified into three types. They are as follows:  Clone sets that can be removed only by extracting them and making a new method in the same class.  Clone sets that can be removed by extracting them and making a new method with setting the externally defined variables as parameters of it because such variables are used in the clone.  Clone sets that can be removed by extracting them and making a new method with setting the externally defined variables as parameters of it and with adding parameters of return statement to deliver the results to the variables used in the caller. To put it plainly, “Extract Method” means extraction of a part of existing method as anew method, and the extracted part is replaced by a new method caller shown in Figure 1. Ingeneral, this pattern is applied to the case that there is a too long method. In applying the patternto code clones, a new method, that is a code fragment of code clone, is defined and the originalcode clones are replaced by the new method caller. As a result, we can modify the code clones. Void printTaxi( int amount){ Void printTaxi( int amount){ String name =getTaxiName(); String name =getTaxiName(); System.out.println(“name:” +name); print(name,amount); System.out.println(“amount:” } +amount); Void printBus(int amount){ } String name=getBusName(); Void printBus(int amount){ print(name,amount); String name=getBusName(); } System.out.println(“name:” +name); Void print(string name, int amount) { System.out.println(“amount:” +amount); System.out.println(“name:” +name); System.out.println(“amount:” +amount); } } Figure 1. One Scenario for Extract Method Refactoring }3.2 Move Method Refactoring A method is used or will be used by more features of another class than by its own. It canbe moved from one class to another. As one of the most elementary refactor operations, movemethod aids the reduction of a system’s complexity by moving functionality from classessuffering too much behavior or strong coupling. By moving methods around, it can make theclasses simpler and they end up being a crisper implementation of a set of responsibilities. Anillustration of move method refactoring is shown in Figure 2. 10

5.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 2013Moving a method actually consists of two actions: (1) removing the method from the originalclass and (2) adding the removed method to the new class.The move method from the source class to a target class is performed as follows:1. The tag indicating to which class the method belongs is changed from source class to targetclass.2. The entity sets of all methods accessing the method are updated according to the new tag.3. The entity sets of all attributes that are being accessed by the method are updated according tothe new tag.4. The method is removed from the entity set of the source class.5. The method is added to the entity set of the target class. Figure 2. One Scenario for Move Method Refactoring3.3 Pull Up Method Refactoring “Pull Up Method Refactoring” means moving identical methods in derived classes to thebase class, so it is necessary that the derived classes have common base class. Therefore, wemeasure the position and distance of clones in the class hierarchy. If the base class has severalderived classes and some of them have the same method (that is, code clone), pulling up themethod can modify the code clone. The easiest case of using Pull Up Method Refactoring occurs when the methods have thesame body, implying there’s been a copy and paste. The two methods in different classes can beparameterized in such a way they end up as essentially the same method. In that case the smalleststep is to parameterize each method separately and then generalizes them. A special case of the 11

6.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 2013need for Pull Up Method Refactoring occurs when there is a subclass method that overrides asuperclass method yet does the same thing. If all or most of a class’s subclasses declare the same method, then it should be pulled upinto the base class. This way it is only defined once in a central location instead of being definedmultiple times. If many of the subclasses have the same method and it should not be pulled upinto the base class, then extract superclass can be used. Refer Figure 3. Employee Employee getName() getName() Salesman Engineer getName() getName() Salesman Engineer getName() Figure 3. One Scenario for Pull Up Method Refactoring getName()4. Clone Manager The existing clone detection tool CloneManager [38] is used, to detect the clones. It iswell suited as it is a metric-based code clones because they can be the target of refactoringoperations in their entirety. The tool CloneManager is developed for clone detection toeffectively and accurately detect all four types of code clones at method level in C and Javasource codes through Lexical Analysis and Metrics. The tool is implemented in Java language. The various types of clones detected by the tool must then be classified and clustered asclone clusters and given as output. The granularity level for clone detection process of the toolCloneManager are methods. It means that the tool detects the functions or the methods of thesoftware system as clones. The tool requires users to select the project containing the necessaryfiles that are to be analyzed. The user is also given the choice of selecting the types of clones thathe/she wants to be detected and analyzed. The result of the code clone detection tool is given as clone pairs. Clone Pair (CP) is thepair of code portions / fragments which is identical or similar to each other. Having detected theclone pairs in each type, the results need to be given in a suitable form for review and analysis.The cloned methods detected in each type are clustered into groups called clone clusters (CC).Every clone pair is commutative and hence in a clone cluster all the members are associative, i.e.every member of the clone cluster is a clone of every other member of the clone cluster. Thus thedetected clones and clusters are stored in the text files. 12

7.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 20134.1 Final Result Set And Coverage Output i. Duplicates.txt: Contains list of all duplicates grouped by similarity which will be very useful for a quick overview of results and in the selection of ‘similarity groups’ for closer review, etc. The duplicates are listed as in the clustered order for easier verification. It also contains details of the no. of lines in the cloned method, cluster no., etc. ii. Duplicates_summary.txt: A summary version of the ‘Duplicates.txt’ containing information about the clone pairs and clusters without any source code. The clusters are represented as a set of cloned method names with the method name and line no. in the file specified along with it.5. Proposed approach The detected code clones can be modified automatically using refactoring technique. Therefactoring process is performed as follows. The clones are detected using the toolCloneManager[38] and the results are documented in a text file. To perform a refactoringprocess, the element(s) selected are methods in the source code. The results of the CloneManagerare method-level clones which are appropriate for refactoring process. The three types ofrefactoring discussed in section 3 are implemented by our approach. This approach has been usedto enhance the clone detection tool to extend the environment to realize the three refactoringmethods.The main window has two parts. The original source code will be displayed in the left side partand the results of the detected clones by CloneManager tool will be displayed in the right sidepart. Figure 4 shows the overall system architecture. The following are the steps to do clone modification by applying refactoring patterns inthe proposed approach.  Identify the possible refactoring opportunities and highlight those clones in the right side window  This clone in the left side window will be highlighted automatically  Determine which refactoring pattern should be applied to the identified places  Apply the refactoring pattern  Assess the effect of refactoring process  If the developer wants to reflect the changes, then the changes are store permanently in the original code itself. Otherwise, it will not reflect the changes in the original code 13

8.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 2013 Extract Move Pull Up Results of Method Method Method CloneManager Apply Refactoring Patterns Highlighting the clones Matching the token Behavioral verification on refactoring process Splitting Source Tokens Files Confirming refactoring Clone Collection process Figure 4: Extended CloneManager System ArchitectureThe implementation of proposed approach is carried out in four phases as follows 1. Clone Collection 2. Applying refactoring patterns 3. Behavioral verification on refactoring process 4. Confirming refactoring process5.1 Clone Collection Using the existing combination of clone metrics proposed in [1][21], the clone clusters areselected from the text file resulted from the tool CloneManager. These clone metrics helps us toidentify the clone clusters that are appropriate for refactoring process. After selection of cloneclusters, the exact locations of the clones in the source code are located using the string matchertechnique. Clone metrics namely LEN(S), POP(S) and RNR(S) are used for this purpose. Each of themcharacterize a clone cluster (i.e. an equivalent of code clone) S:  LEN(S) - The average number of token sequence of code clones in a clone cluster S  POP(S) - The number of code clones in a clone cluster S  RNR(S) - The ratio of non-repeated token sequence of code clone in a clone cluster S The definition of LEN(S) and POP(S) are explicit as they are the simple count metrics.Higher LEN(S) values mean that each code clone in a clone cluster S consists of more tokensequences. Clone Metric LEN(S) eliminates small size code clones detected. 14

9.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 2013 A clone cluster with a high value of POP(S) means that the code clones appears morefrequently in many places. A clone set who’s higher POP(S) apply good motivation forrefactoring to developers because to perform refactoring to code clones in a clone cluster appearmore frequently in software improves the maintainability. The definition of RNR(S) metric is defined by Equation (1). If clone set S includes n codeclones, c1; c2 : : : ; cn, LOSwhole(ci) is the Length of the whole token Sequence of code clone ci.LOSnon-repeated(ci) is the Length of non-repeated token Sequence of code clone ci, then, n ∑ LOSnon-repeated (ci) i=1 RNR(S) = __________________ x 100 (1) n ∑ LOSwhole (ci) i =1Higher RNR(S) values mean that each code clone in a clone cluster S consists of more non-repeated token sequences. It eliminates types of if (or if-else) blocks. It also eliminates languagedependent code clones.The following combination of the clone metrics are used for identifying the clone cluster1. Clone cluster whose LEN(S) and RNR(S) is the highest2. Clone cluster whose LEN(S) and POP(S) is highest3. Clone cluster whose RNR(S) and POP(S) is highest4. Clone cluster whose LEN(S), RNR(S), and POP(S) is highest These are the identified clone clusters for applying refactoring mechanisms. The clonecollector helps us to find the presence of code clones in the source code. The exact location of theclones in the source code can be determined by clone collector. Using the string matchertechnique the clone collector matches the similarity between the source code and the clonedcodes. After the above steps in the browser, the code clones are highlighted using a differentbackground color such as yellow to show the exact location and presence of the clones in theoriginal source code. The remaining part of the code is left with the white background color assuch. After highlighting the clones the clone files are integrated together into a single file. Theintegrated file contains all the copies of the cloned codes from the source code. This type of clonecollection is used in future by the user. i.e programmer who refer to the clones can decide whichtype of refactoring pattern will be made to the clones to correct them or to remove them. Figure 5illustration of highlighting clones. 15

10.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 2013 Figure 5. Illustration of Highlighting the Clone Clusters5.2 Applying Refactoring PatternsIn this phase the refactoring patterns extract method, move method and pull up method formodifying the clones are applied. The steps in each of the methods are explained in the followingsubsections.5.2.1 Extract methodMake a list of all methods in the selected clone cluster. For each method, count the lines of codeand the number of statements in the method’s body. If both of those counts exceed theircorresponding thresholds, then the method should probably be extracted into multiple smallermethods. The statement count is important because it prevents false positives from methods withstatements that span many lines. For example, a method may have just a few statements, but oneof those statements can contain a conditional expression that spans one or more screens. The linecount is less important; however, it is useful for users those who want to enforce strict policies onhow many lines a method may span.α:= 70,β := 50for m methods[clone set] doif lines-of-code[m] >= α ^|statements[m]| >= β thenreport (“Extract Method”, m)Figure 6. Algorithm for Extract Method The Extract Method algorithm is based on the assumption that a method with a largebody can most likely be split up into smaller methods. This is done by extracting chunks offunctionality from the large method into separate small methods. This algorithm also makes theassumption that the larger the method body is, the more likely it is to have multiple chunks ofcode that are mostly independent of each other. Those independent chunks of code are easily 16

11.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 2013extracted. This is not always the case; sometimes a method is so interconnected and cohesive thatthere is no multiple functionality. It cannot easily be extracted into separate methods.5.2.2 Move Method A data class is a class that holds data but does not make use of the data itself; it merelyholds the data for other classes to use. For each class or struct in the list, count the number ofattributes and methods declared. If there is a low ratio of methods to attributes, then theassumption is that the class is a data class and targets it as a candidate class for move method. Once a candidate class has been found, for each attribute in the class determine the set ofmethods referencing the attribute by using the forward reference chains previously built. If aforeign method makes too many references to a number of distinct fields, then move the methodor some of its functionality into the data class. The additional check on the number of distinctattributes is needed since some methods may reference a single attribute many times, but in fact atemporary variable could have been used to reference the attribute only once.α := 0.40,β := 4, µ := 2for c classes[program] doif |fields[c]| > α·|methods[c]| thenfor f fields[c] dofor r references[ f ] dom := containing-method(r)fields-referenced[m] := fields-referenced[m] ∪ { f }total-references[m] := total-references[m]+1for m fields-referenced doif total-references[m] >= β^|fields-referenced[m]| >=µ thenreport(“move method”,m,c)delete fields-referenced, total-referencesFigure 7.Algorithm for Move Method If there are duplicated methods in different classes that have no common base class, it isdifficult to apply refactoring using class hierarchy to them. In such case, the “Move Method” is agood solution for identifying refactoring opportunities for removing code clones as shown infigure 2.5.2.3 Pull Up Method This algorithm makes the assumption that multiple instances of any method in a classhierarchy with the same method signature will be used in very similar ways. It also assumes thatmethods with the same method signature and roughly the same number of lines are more likely tohave a similar purpose.β := 20for m methods[clone set] docommon-methods-count[m] := common-methods-count[m]+1 17

12.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 2013if common-methods-max-lines[m] < lines-of-code[m] thencommon-methods-max-lines[m] := lines-of-code[m]if common-methods-min-lines[m] > lines-of-code[m] thencommon-methods-min-lines[m] := lines-of-code[m]for m common-methods-count doif common-methods-max-lines[m]−common-methods-min-lines[m] <= β thenreport(“pull up method”,m)Figure 8: Algorithm for Pull Up Method5.3 Behavioral Verification on Refactoring Process The definition of behavior preservation states that, for the same set of input values, theresulting set of output values should be the same before and after refactoring process. So, we needto check the behavior of the system. For this the given input software are executed before andafter to check the output of the system. (i.e) to test the results are same after refactoring process.The tool allows the user to test that the files in the project all compile correctly before arefactoring process is performed. This is an essential feature since one of the assumptions madeby the tool is that the code compiles correctly. Thus it is automated to check the externalbehavior. The user can test whether refactoring patterns can be applied without actually applying therefactoring patterns. The JavaCompiler interface from the framework is used to provide a methodfor the user to compile files in the project. All files specified in the project are compiledaccording to the various settings specified in the project file. To check the external behavior, the refactored source code file is converted into executablefile. Hence the file can be run on a machine to produce output file. The code file is saved for thefuture reference and for the case study that is done on the source code.5.4 Confirming Refactoring Process If, the refactored codes do preserve the same external behavior as before, then accordingto the requirement of the software developer, the software can be made to change completely andpermanently in the original source code. The tool allows output conditions to be checked bytesting. If the conditions hold, apply the refactoring to the current source code. This confirms therefactoring. The user interface window has two options with button named doractoring and cancel. Theuser is enabled to select the dorefactoring option, if the user selects that option the code ismodified as per refactoring process and it is replaced and saved as such. If the developers don’twant to make any changes, then the changes will not be done in original source code. For this theuser has to select the cancel option. The tool provides facilities for undoing changes made by refactoring process. However itleaves the management of these changes up to the user so that they can be represented as desired. 18

13.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 2013It is necessary for the tool to use its own mechanisms to undo the refactoring process, for exampleby storing a textual representation in its own structure.6 Experiments and Results6.1 Experimental Setup The proposed method is implemented and experimented with seven Java Projects. Wehave chosen the dataset which have been already evaluated in the literature, so that it will behelpful for us to do comparison easier. We compared our results with three of the existing tools.To measure the accuracy of our proposed work, we use precision and recall, two standard metrics.  Precision is the ratio of the number of relevant refactoring opportunities found to the total number of irrelevant and relevant refactoring opportunities found.  Recall is the ratio of the number of relevant refactoring opportunities found to the total number of actual refactoring opportunities in the component. Ideally, precision and recall should be 100%. Finally, we also cross checked the resultsby manual inspection of the open source projects.6.2 Datasets We have analyzed with a medium sized program called JHotDraw 5.3 which is forstructured drawing editors of approximately 27,000 lines and to the large size program calledEclipse which is the java text editor along user interface with 352,000 lines. Table 1 lists thefeatures of open source projects which are taken for the performance analysis of ourCloneManager tool. Table 1: Projects chosen as dataset for Clone modification using refactoring S.No Project version Size KLOC #Methods #Classes 1 Eclipse UI 3.0 352 15894 1735 2 Struts 1.2.4 97 6044 469 3 JHotDraw 5.3 27 2038 195 4 JFreeChart 1.0.10 76 1847 436 5 JEdit 4.2 51 5418 426 6 Ant 1.6.0 180 9947 994 7 Ant 1.7.0 67 4231 778In Table 1, the second column is the list of open source program names as the input project. Thethird column is the version of the project. The fourth column is the no. of lines in the source codein thousands. The fifth column is the no. of methods in each project. The last column is the no. ofclasses in each project. Table 2 shows the results for all chosen dataset. 19

14.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 20136.3 Results In Table 2, the 2, 3 & 4 column shows the no. of refactoring opportunities identified andrefactoring patterns applied for clone modification. The last column shows the total no. ofrefactoring opportunities. From the results, we observed, that even though eclipse UI 3.0 is the largest open source insize, the total of number of the refactoring opportunities is very less. Next, we observed that thetotal no. of refactoring opportunities in ant 1.6.0 is 87, where as in ant 1.7.0 the number is only62. This shows that the number of refactoring opportunities reduced a lot in the next version ofant. Finally, we observed that the number of pull-up method is nearly 20 in average for all theprojects, where as the extract method and move method varies a lot among the projects. Table 2. No. of refactoring opportunities detected for each project Total Move Project Extract Method Pull Up Method Refactoring Method opportunities Eclipse UI 3.0 3 10 12 25 Struts 1.2.4 6 21 1 28 JHotDraw 5.3 5 0 26 31 JFreeChart 65 58 21 144 1.0.10 JEdit 4.2 20 58 23 101 Ant 1.6.0 35 29 23 87 Ant 1.7.0 32 27 03 626.4 Evaluation of the tool The table 3 shows the results produced for all the datasets to evaluate our tool. The column 3holds [M] the number of manually detected refactoring opportunities for all the datasets. TheColumn 4 holds [D] the number of refactoring opportunities detected by our tool CloneManager.The column 5 holds [C] the number of refactoring opportunities detected correctly by our tool.These values are used to calculate the two parameters precision and recall for evaluation. Theformula to calculate Precision = [C]/ [D] * 100 and Recall = [D]/ [M] * 100. Table 3: Results produced for evaluation of the tool Manually Detected Correctly detected Refactoring Refactoring Detected Project Refactoring patterns opportunities Refactoring opportunities [D] opportunities [C] [M] Extract Method 2 3 2 Eclipse UI Move Method 10 10 9 3.0 Pull Up Method 12 12 12 Struts 1.2.4 Extract Method 6 6 5 20

16.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 2013 100 99 100 99 100 100 98 98 100 98 97 97 97 98 98 96 96 96 93 94 92 94 92 92 90 90 88 88 Precision… Recall in… Figure 9. Precision values for all datasets. Figure 10. Recall values for all datasets. The system is also evaluated with overall detected refactoring opportunities for alldatasets. The parameters precision, recall and time taken in seconds are given for all datasets. Allthese values are tabulated in Table 4 respectively. The overall Precision and recall is above 90%.Figure 9 & 10 shows the precision and recall values in graph for all datasets. The maximum time taken is not even 2 minutes. This shows that our system is very fast.Finally we are able to get results for the Eclipse UI system also which is larger in size. Thisproves that our system is also scalable.6.5 Comparison of the tool Having computed the results for all three types of refactoring patterns and modified theclones in all datasets, we compared our results with three of the existing tools. Table 5 list outsthe existing refactoring tool along with their data. Table 5: Existing tools data considered for analysis Tool Name Refactoring patterns Used Projects considered Extract Method Aries [3] Ant 1.6.0 Pull Up method Move Method Eclipse UI 3.0 RefactoringCrawler [8] Struts 1.2.4 Pull Up Method JHotDraw 5.3 JfreeChart 1.0.10 CeDAR [2] Extract Method Jedit 4.2 Ant 1.7.0 a) The first tool considered for analysis is Aries for refactoring process. Aries developed by Yoshiki et. al [3] supports extract method and pull up method for code clones. Yoshiki et. al has tested the tool with only one open source program Ant 1.6.0. 22

17.
Advanced Computing: An International Journal ( ACIJ ), Vol.4, No.2, March 2013 b) The second tool we considered for analysis is the RefactoringCrawler developed by Danny Dig et. al. [8] an algorithm that detects refactorings opportunities performed during component evolution. c) The third tool we considered for analysis is the CeDAR which stands for Clone Detection, Analysis, and Refactoring is developed by Robert Tairas [2] . The information about a selected clone group can be forwarded to the Eclipse refactoring engine for the purpose of refactoring process. Table 6: comparison with the existing tool Aries for Ant 1.6.0 Refactoring No. of Refactoring Opportunities Patterns Aries CloneManager Manual Extract Method 32 35 36 Pull Up method 20 22 23 Total 52 57 59 Time in sec 120 56 - From the table 6, we compared our tool results; which shows more no. of refactoringopportunities identified in both refactoring patterns. This reveals that our tool is able to find anddo refactoring process better than Aries. The time taken to detect refactoring opportunities is alsolesser as shown in the table. Table 7: Comparison with the existing tool RefactoringCrawler RefactoringCrawler CloneManager Manual Pull Tot Pull Tot Total Move Move Move Pull Up Project Up al Up al Metho Metho Metho Metho Metho Metho d d d d d d Eclipse UI 8 11 19 9 12 21 10 12 22 3.0 Struts 1.2.4 20 1 21 21 1 22 23 1 24 JHotDraw 0 26 26 0 26 26 0 26 26 5.3 Table 8: Comparison of the evaluation parameters with RefactoringCrawler RefactoringCrawler CloneManager Project Precision% Recall% Time Precision% Recall% Time Eclipse UI 3.0 90 86 16.38 92 96 1.38 Struts 1.2.4 100 86 4.55 97 93 0.15 JHotDraw 5.3 100 100 0.37 100 100 0.05 From table 7, we observed that the value in pull up method for struts 1.2.4 and the valuesfor JHotdraw 5.3 project are same. Other values are higher than the refactoringCrawler tool. Thisshows that our tool is able to detect even more refactorings opportunities which are left by the 23