CRat: A Refactoring Support Toolfor Form Template Method
Keisuke Hotta, Yoshiki Higo, Hiroshi Igaki, Shinji Kusumoto
Graduate School of Information Science and Technology, Osaka University
1-5, Yamadaoka, Suita, Osaka, 565-0871, Japan{k-hotta, higo, igaki, kusumoto}@ist.osaka-u.ac.jp

Abstract—Refactoring is important for efficient software maintenance. However, manual operations for refactoring are complicated, and human-related errors easily occur. Tool support
can help users to apply such a complicated refactoring. Thispaper proposes a refactoring support tool with Form Template
Method pattern. The developed tool automatically identifies
method pairs that can be refactored with Form Template Method,and suggests information that is required for Form Template
Method application. It also has a function that metrics-based
filtering for detected method pairs. The function helps users toselect method pairs that should be refactored.
Index Terms—Refactoring, Form Template Method, Program
Dependence Graph, Software MaintenanceSite

beforedouble base = units * rate;
double tax = base * Site.RATE;
return base + tax;
double base = units * rate * 0.5;
double tax = base * Site.RATE * 0.2;
return base + tax;

Residential Site

Lifeline Site

getBillableAmount()

getBillableAmount()

return getBaseAmount() + getTaxAmount();

afterSite
return units * rate;

getBillableAmount()
getBaseAmount()
getTaxAmount()

return base * Site.RATE;
return units * rate * 0.5;
return base * Site.RATE * 0.2;

I. I NTRODUCTION
Refactoring is a set of operations for improving internal
structure of software without changing its external behavior[1]. It has been reported that maintainability of softwaresystems decays over time [2]. Refactoring is effective in sucha case because it can reduce the decay of maintainability.
However, applying refactorings takes much effort. Also, applying manual refactorings is a complicated task, so that humanrelated errors easily occur. Consequently, techniques or tools
for supporting refactoring are required, and many techniques
have been proposed to assist refactorings [3].
In this paper, we focus on Form Template Method pattern.
This pattern targets similar methods (see Fig 1). In this pattern,
programmers write an outline for similar methods into the baseclass and implement detail processes in each derived class. By
applying Form Template Method refactoring, code duplication(code clones) existing between the similar methods is merged
into the base class. One of the advantages of duplication
removal with Form Template Method is that this pattern canbe applied to methods having some gaps.
Some researchers have proposed techniques to support Form
Template Method refactorings [4], [5]. These techniques use
Abstract Syntax Tree (in short, AST) as their data structures.
However, these techniques cannot support removing codeclones if they include the following differences even if thesedifferences have no impacts on the behavior of the program:• different order of code fragments, and• different implementation (such as for- and while- loops).
We have proposed techniques for supporting Form Template Method applications [6]. This technique uses Program
Dependence Graph (in short, PDG) to resolve the above issues.

Fig. 1.

Residential Site

Lifeline Site

getBaseAmount()
getTaxAmount()

getBaseAmount()
getTaxAmount()

An Example of the Application of Form Template Method [1]This paper focuses a tool, CRat (Clones Removal AssistantTool), which implements the proposed refactoring supporttechniques. The features of CRat are as follows:• detects refactoring candidates automatically,• has metrics-based filtering function for selecting refactoring targets, and• visualizes each candidate with information used for applying refactoring.
II. D EVELOPED T OOL
A. Overview
CRat requires source code of target software systems asits input. It analyzes the source code and creates PDGs withMASU, a source code analysis platform [7]. Then it detects
code clones on PDGs with the existing clone detector, Scorpio[8]. CRat identifies refactoring candidates with information
about code clones, and detects common and unique processes
for each refactoring candidate. It visualizes each refactoring
candidate by highlighting common and unique processes. Notethat CRat does not modify the source code automatically, thus
users need to modify the source code by themselves.
Here, a refactoring candidate indicates a pair of similar
methods. CRat suggests a pair of methods as a refactoring
candidate if they satisfy the following requirements:

the two methods are defined in different classes,
the two methods have the same base class, and• there exists at least one clone pair (a pair of duplicate
code fragments) between the two methods.
••

B. Functionalities for Suggesting Refactoring Candidate
Figure 2 shows a snapshot of CRat. The table shows all thecandidate method pairs that CRat detected. When users selecta method pair from the table, the source code of the methods
included in the pair is shown in the right panel. We call theright panel as source code view.
Figure 3 shows a snapshot of the source code view. Common statements are colored with red, which means that theyshould be pulled up into the base class. On the other hand,unique statements are colored with other colors. Statements
surrounded by the same color rectangles means that they canbe extracted as a single method. In addition, if users clickstatements that are not highlighted by red, a set of statements
including the statement are highlighted. Moreover, if users
click a set of statements in one method, CRat also highlights
the corresponding set of statements in the other method. Here,the term ‘correspond’ indicates that the two sets of statements
can be extracted as the same signature methods. Additionally,
CRat shows the signature of the method created from a set ofstatements if users put the cursor on the set.
C. Functionalities for Refactoring Candidate Identifications
CRat has a metrics-based filtering function of candidate
method pairs. All metrics are calculated for each method pair.
Users can specify the upper and the lower thresholds for each
metric, and then CRat suggests candidates whose metrics arein the specified thresholds. The metrics are as follows.
• SIM: The degree of similarity between the two methods.
• CN: The number of statements that can be pulled up into
the base class.
• DN: The number of statements that need to remain ineach derived class.
• LOC: The number of lines of code.
• DG: The number of new methods that need to be createdfor Form Template Method application.
• DOI: The depth of inheritance from the common baseclass to the owner classes of the two methods.
CRat has a graphic interface to support users’ specificationof thresholds. This interface uses the metrics graph [9]. Figure
4 shows a snapshot of the metrics graph. Users specify
the thresholds of each metric by dragging the graph. The
area whose background color is gray indicates the range ofthresholds for every metric, and the area whose backgroundcolor is white indicates the outside of the range. In the metricgraph, each polygonal curve corresponds a method pair. The
polygonal curve becomes red if and only if all the metrics ofthe method pair represented by the polygonal curve are in thespecified threshold. If any of the metrics is not in the threshold,the polygonal curve becomes gray. By using the metrics graph,users can specify thresholds of each metric graphically, andcan find how many candidates satisfy the thresholds.

Method pairs represented by red polygonal curve satisfy thethresholds that users specified. Therefore, CRat shows thesemethod pairs after users specified thresholds for each metric.
III. R ELATED W ORK
Some techniques have been proposed to support Form
Template Method refactorings [4], [5]. They use ASTs as
their data structure, which is the most different point from theproposed method. In addition, users need to detect refactoring
candidates to use previously described techniques. On theother hand, CRat detects refactoring candidate automatically,
which helps users to detect refactoring opportunities.
IV. C ONCLUSION
This paper proposed a refactoring support tool with Form
Template Method. This tool is an implementation of the refactoring support technique that our research group has proposed[6]. The tool automatically detects and suggests method pairsthat can be refactored with Form Template Method. Also, thetool provides the functionality of method pairs filterings, whichhelps users to decide which candidates should be refactored.
As future work, we are going to conduct experiments toconfirm the effectiveness of the developed tool.
ACKNOWLEDGMENT
This study has been supported in part by Grants-in-Aidfor Scientific Research (A) (21240002), Grant-in-Aid for Exploratory Research (23650014), and Grand-in-Aid for Young
Scientists (A) (24680002) from the Japan Society for thePromotion of Science.
R EFERENCES[1] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts, Refactoring:
Improving the Design of Existing Code. Addison-Wesley Professional,
1999.
[2] S. G. Eick, T. L. Graves, A. F. Karr, J. S. Marron, and A. Mockus, “Doescode decay? assessing the evidence from change management data,” IEEE
Transactions on Software Engineering, vol. 27, no. 1, pp. 1–12, Jan. 2001.
[3] T. Mens and T. Tourwé, “A Survey of Software Refactoring,” IEEE
Transactions on Software Engineering, vol. 30, no. 2, pp. 126–139, Feb.
2004.
[4] N. Juillerat and B. Hirsbrunner, “Toward an implementation of the “FormTemplate Method” Refactoring,” in Proc. of the 7th International Working
Conference on Source Code Analysis and Manipulation, Sep. 2007, pp.
81–90.
[5] M. Ioka, N. Yoshida, T. Masai, Y. Higo, and K. Inoue, “A Tool Support
to Merge Similar Methods with a Cohesion Metric COB,” in Proc. ofthe 3rd International Workshop on Empirical Software Engineering inPractice, Nov. 2011, pp. 23–24.
[6] K. Hotta, Y. Higo, and S. Kusumoto, “Identifying, Tailoring, and Suggesting Form Template Method Refactoring Opportunities with Program
Dependence Graph,” in Proc. of the 16th European Conference on
Software Maintenance and Reengineering, Mar. 2012.
[7] Y. Higo, A. Saitoh, G. Yamada, T. Miyake, S. Kusumoto, and K. Inoue,“A Pluggable Tool for Measuring Software Metrics from Source Code,”in Proc. of the Joint Conference of the 21th International Workshop on
Software Measurement and the 6th International Conference on Software
Process and Product Measurement, Nov. 2011, pp. 3–12.
[8] Y. Higo and S. Kusumoto, “Code Clone Detection on Specialized PDGs
with Heuristics,” in Proc. of the 15th European Conference on SoftwareMaintenance and Reengineering, Mar. 2011, pp. 75–84.
[9] Y. Higo, S. Kusumoto, and K. Inoue, “A metric-based Approach toIdentifying Refactoring Opportunities for Merging Code Clones in aJava Software System,” Journal of Software Maintenance and Evolution:
Research and Practice, vol. 20, no. 6, pp. 435–461, 11 2008.

Source Code of the Methods
in the Selected Method Pair

Button to Call Filtering Function

List of Method Pairs

Fig. 2.

A Snapshot of CRat

Common statements

To be extracted as thesame signature method

A set of statementsthat can be extractedas a single method

Fig. 3.

A Snapshot of Source Code View

specify thresholdsby dragging
the graphFig. 4.

A Metrics Graph