Efficient Code Clone Management Based on
Historical Analysis and Refactoring Support

July 2013

Keisuke HOTTA

Efficient Code Clone Management Based on
Historical Analysis and Refactoring Support

Submitted to
Graduate School of Information Science and Technology
Osaka University

July 2013

Keisuke HOTTA

Abstract
Code clones have recieved great interests in recent years from many researchers,
engineers, and practitioners in the field of software engineering. A code clone isdefined as a group of code fragments that are identical or similar to one another.
Code clones are introduced into source code of software systems by various reasons, and the most typical one is code cloning by copy-and-paste operations forreusing existing features. Typical software systems contain a certain amount ofcode clones because code cloning is a common practice for software developers.
The existence of code clones has been regarded as a bad smell for software evolution over a period of time because code clones require much attention to be maintained. Once code clones are introduced into source code, most of them should beconsistently maintained. Unintended inconsistencies among code clones have ahigh risk for introducing bugs in software systems. However, it is not an easy task
for developers or maintainers to be aware of all the code clones and maintain allof them consistently, specifically in the case of large software systems. This is areason why code clones are regarded as bad factors for software evolution.
Many researchers have proposed a variety of techniques to cope with code
clones based on this common wisdom. However, some of recent empirical studies
have been against it. That is, these studies revealed that code clones do not highly
affect software evolution. The discussion for harmfulness of code clones remains
inconclusive, but it is widely accepted that not all but a part of code clones havenegative impacts on software evolution.
For these reasons, it is not effective to prohibit software engineers from codecloning. Furthermore, prohibiting code cloning is also unrealistic because of advantages of it. Therefore, it is strongly required to manage code clones effectively.
The objective of the work described in this dissertation is to promote efficient
software evolution through effective managements for code clones.
To achieve this objective, it is necessary to know state-of-the-art of researchachievements. Therefore, we conducted a survey on research literatures on code
clones. This survey categorized literatures into five categories, detection, removal,
prevention, analysis, and bug detection. The survey told us current states of re-search on code clones. It also told us limitations of previous research on code
clone analysis, and unclear points of characteristics of them.
Based on the results of the survey, we conducted an empirical study to reveal
how negative impacts code clones have. Although some existing studies investigated the impacts of code clones, they have some limitations to genealize theirfindings. To resolve these limitations, this study proposed a new metric and used
multiple clone detectors. The metric proposed by this study captures modification frequencies on code clones, which is under an assumption that code clones
have negative impacts if they are frequently modified. This study compared metricvalues on cloned code with non-cloned code to judge whether code clones affectsoftware evolution on 15 open source software systems with four clone detectors.
The experimental results indicate that code clones do not tend to be modified more
frequently than non-cloned code, hence the study concluded that code clones do
not have seriously negative impacts on software evolution.
Through the emprical study, we recognized a necessity of further analyses on
impacts of code clones. This is because our first study lumped code clones all together, and so it did not consider how individual code clones affect on software
evolution. Analyzing histories of individual code clones is helpful to investigate
the research problem. To anlayze histories of individual code clones, it is necessary to track code clones across version histories of source code. There are sometechniques to tackle this challenging task, but they still remain some issues. Therefore, we developed a new technique to track code clones by enhancing an existingclone tracking technique. The key idea of the enhancement is to link clones located in not only exactly the same regions but also similar ones. We confirmed
an improvement of accuracy of clone tracking through an experiment on two open
source software systems. Furthermore, we conducted an investigation for reasons
why code clones are gone as an application of the proposed technique for clone
tracking.
With the new tracking technique, we conducted another empirical study on
evolution of code clones. This study detected clone genealogies, which represent
how individual code clones evolved, and analyzed them. This investigation wasinterested in how long code clones survived and how many times they were modified throughout their lifetimes. The experimental results reaffirmed that most ofclones had short lifetimes and were modified at most once, both of which werereported in previous research. Furthermore, the results revealed some characteritics that have not been revealed in previous research. One of the findings is thatapproximately 3% of code clones are long-lived and modified multiple times. In
other words, approximately 97% of code clones do not require high costs to be
maintained. This finding empirically supports an opinion that not all but a part ofclones affect software evolution. Another finding is that code clones tend to bemodified more frequently in the former halves of lifetimes than in the latter ones.
This finding suggests that it is necessary to start managing code clones in earlier
stages of their lifetimes for an effective code clone management.
In the next, we proposed a way to cope with code clones, which is a support to remove them with a particular refactoring pattern. The refactoring patternused in this study enables to remove code clones even if they include some gaps.
Moreover, the proposed technique performs a fine-grained analysis on source code,
which allows to handle instances that any of previous refactoring supports cannot
handle. Furthermore, the proposed technique can handle all the code fragments
included in a code clone as against to existing techniques that can only handle apair of code fragments. We have developed a software tool as an implementationof the proposed technique, and validated the usefulness of the technique throughtwo experiments, one is on open source software systems, and the other is withsubjects.
This dissertation is organized as follows.
Chapter 1 gives the background of this work and an overview of this dissertation.
Chapter 2 presents the survey results on literatures that are related to code
clones. This chapter explains a definition of code clones, and then it discusses
some perspectives of them. The introductions of each research achievement follow
the discussion, with categorized loosely into five categories.
In Chapter 3, we present the result of the empirical study on stabilities of code
clones. The chapter describes how to perform the investigation, the experimental
targets of this study, and the experimental results. In this study, we compared theexperimental results of our experimental methodology with other methodologies
proposed by other researchers. This chapter refers to the results of the comparisons,and then it discusses the experimental results.
Chapter 4 proposes the new clone tracking technique. This technque is anenhanced version of an existing technique. We fist explain the key idea of theenhamcement, and then discuss the effectiveness of the proposed technique withan experiment on open source software systems. Furthermore, we conduct anotherexperiment to reveal why clones are gone, which is an application of the proposed
technique.
Chapter 5 presents the result of the empirical study on genealogies of code
clones. This chapter revisits two major findings on evolution of code clones, andthen reveals some characteristics that any of previous reseach did not address.
Chapter 6 proposes the refactoring support technqiue for code clones including
some gaps. This chapter formally describes the technique and introduces an implementation of the proposed technique. It also presents the experimental results
to confirm the usefulness of the proposed technique.

Finally, Chapter 7 summalizes this dissertation and shows some future directions of this work.

List of Publications
Major Publications[1-1] Keisuke Hotta, Yukiko Sano, Yoshiki Higo, and Shinji Kusumoto: “Is Duplicate Code More Frequently Modified than Non-duplicate Code in Software
Evolution?: An Empirical Study on Open Source Software,” in Proceedings of the 11th International Workshop on Principles of Software Evolution(IWPSE-EVOL 2010), pp.73-82, Antwerp, Belgium, September 2010.
[1-2] Keisuke Hotta, Yukiko Sano, Yoshiki Higo, and Shinji Kusumoto: “An Empirical Study of Influence of Duplicate Code on Software Maintenance Basedon Modification Frequency Comparison,” IPSJ Journal, Vol.52, No.9, pp.27882798, September 2011 (in Japanese).
[1-3] Keisuke Hotta, Yoshiki Higo, and Shinji Kusumoto: “Identifying, Tailoring, and Suggesting Form Template Method Refactoring Opportunities with
Program Dependence Graph,” in Proceedings of the 16th European Conference on Software Maintenance and Reengineering (CSMR 2012), pp.53-62,
Szeged, Hungary, March 2012.
[1-4] Keisuke Hotta, Yui Sasaki, Yukiko Sano, Yoshiki Higo, and Shinji Kusumoto:“An Empirical Study on the Impact of Duplicate Code,” Advances in Software Engineering, Hindawi Publishing Corporation, Vol.2012, May 2012.
[1-5] Keisuke Hotta, Yoshiki Higo, Hiroshi Igaki, and Shinji Kusumoto: “CRat:
A Refactoring Support Tool for Form Template Method,” in Proceedings ofthe 20th International Conference on Program Comprehension (ICPC 2012),
pp.250-252, Passau, Germany, June 2012.
[1-6] Keisuke Hotta, Yoshiki Higo, and Shinji Kusumoto: “Supporting Template
Methods Pattern Application on Code Clones by Program Dependence Graph,”
IEICE Journal, Vol.J95-D, No.7, pp.1439-1453, July 2012 (in Japanese).
i[1-7] Keisuke Hotta, Yoshiki Higo, Hiroshi Igaki, and Shinji Kusumoto: “A Refactoring Support with Form Template Method for Groups of Multiple Similar
Methods,” IEICE Journal, Vol.J96-D, No.2, pp.362-364, February 2013 (inJapanese).
[1-8] Keisuke Hotta, Yoshiki Higo, and Shinji Kusumoto: “A Survey on CodeClone Management Focusing on Prevention, Methodology for Efficient Analysis, and Bug Detection,” accepted by JSSST Computer Software, February
2014 (in Japanese).

Related Publications[2-1] Yui Sasaki, Keisuke Hotta, Yoshiki Higo, and Shinji Kusumoto: “Is Duplicate Code Good or Bad? An Empirical Study with Multiple Investigation
Methods and Multiple Detection Tools,” in Proceedings of the 22nd International Symposium on Software Reliability Engineering (ISSRE 2011), Hiroshima, Japan, December 2011.
[2-2] Yoshiki Higo, Keisuke Hotta, and Shinji Kusumoto: “Enhancement of CRDbased Clone Tracking,” accepted by the 13th International Workshop on
Principles on Software Evolution (IWPSE 2013), Saint Petersburg, Russia,
August 2013.

ii

Acknowledgements
During this work, I have been fortunate to have received assistance from many
individuals.
First, I would like to express my heartfelt gratitude to my supervisor, Professor Shinji Kusumoto, for his considerate support, encouragement, and guidance
throughout this work. He has spent much time and effort for this work. I do notbelieve this work would have been possible without his help.
I would like to express my sincere gratitude to Dean and Professor Katsuro
Inoue for his helpful comments, valuable questions, and kind advice for this work.
I also would like to express my sincere appreciation to Professor Toshimitsu
Masuzawa for his valuable comments and helpful suggestions on this dissertation.
I would like to express my sincere appreciation to Professor Ken-ichi Matsumoto, in Nara Institute of Science and Technology, for his valuable questions
and discussions for this work.
Also, I would like to thank Associate Professor Kozo Okano for his valuablesuggestions and discussions for this work.
I am deeply grateful to Associate Professor Hiroshi Igaki. I could not complete
this work without his helpful comments, valuable suggestions, and kind encouragement.
I would like to express my heartfelt appreciation to Assistant Professor Yoshiki
Higo for his great contributions throughout this work. His zealous coaching andsupport have strongly encouraged me, and his helpful comments and suggestions
made it possible to complete this work.
Many of courses that I have taken during my graduate and undergraduate careers have been helpful in preparing this thesis. I would especially like to acknowledge the guidance of Professor Ken-ichi Hagihara and Professor Yasushi Yagi.
I also would like to express my appreciation to Assistant Professor Takeshi
Kakimoto, in Kagawa National College of Technology, for his valuable suggestions
and helpful advice.
I would like to thank Assistant Professor Norihiro Yoshida, in Nara Institute of
Science and Technology, and Assistant Professor Hideaki Hata, in Nara Institute ofiii

Science and Technology, for their valuable feedback for this work. I also would liketo thank researchers on software engineering who have given me helpful comments
and encouragement.
I would like to thank all the members and graduates of our laboratory, Kusumoto
Laboratory.
I would like to express my sincere appreciations to the clerks of our laboratory,
including Ms.Tomoko Kamiya and Ms.Kaori Fujino. Their kind support has beenquite helpful for me to prepare this dissertation.
I owe deep debts of gratitude to my contemporaries at our laboratory, Mr.Kazuki
Kobayashi, Mr.Tatsuya Fujikawa, and Ms.Yuko Muto, for their kind assistance andhelpful comments. Loosing any of them must make it impossible to complete thiswork because their assistance has strongly helped and encouraged me.
My heartfelt thanks go to Ms.Yui Sasaki for her valuable comments, helpful
suggestions, and close cooperation throughout this work, especially for the work
described in Chapter 3. It must be impossible to accomplish this work without her
kind assistance and great contributions.
I would like to express my appreciation to Dr.Takeshi Nagaoka for his help
to prepare this dissertation. I also would like to thank Ms.Yukiko Sano for hercoaching and assistance, especially for the work described in Chapter 3. I would
like to appropriate Mr.Masayuki Owashi, Mr.Akihiko Ito, Mr.Masataka Ugumori,
Mr.Kensuke Tanaka, Mr.Tetsuaki Nakamura, and Mr.Keizo Miyamoto for theirhelpful suggestions and valuable advice. I learned many things from them, including how to work on research problems and how to enjoy the work.
I would like to express my gratitude to Mr.Shinya Yamada for his coaching,warm encouragement, and helpful advice. Moreover, I am deeply grateful to
Mr.Katsuma Ubukata, Ms.Tomoko Kanemitsu, and Mr.Minoru Nishino for theirvaluable discussions for this work. I also would like to thank Mr.Toshiaki Tanaka
and Mr.Kiyoyuki Miyazawa for their valuable technical advice. I could not finish
this work without kind support from the above individuals.
I am grateful to the members of our research group, including Mr.Tomoya
Ishihara, Mr.Shuhei Kimura, Mr.Hiroaki Murakami, Mr.Jiachen Yang, Ms.Ayaka
Imazato, and Mr.Noa Kusunoki for their valuable comments and kind support.
Their technical advice has been very helpful to prepare this dissertation, and theirassistance has encouraged me many times.
Moreover, I would like to appreciate Mr.Yoshihiro Nagase, Mr.Kentaro Hanada,
Mr.Kazuki Yoshioka, Mr.Yoshitomo Okada, Mr.Akiyoshi Taguchi, Mr.Takuya Yasunaga, Mr.Koichi Umekawa, Mr.Yukihiro Sasaki, and Mr.Hiroaki Shimba for
their encouragement. I could have had cheerful days in our laboratory becauseof their delightful breezinesses.
I feel deep appreciations for all the other members and graduates of our laboraiv

tory. I think I am very fortunate because I could work with such great colleagues.
I also wish to thank the members and graduates of Inoue Laboratory for theirassistance, including Ms.Eunjong Choi, Mr.Yu Kashima, Mr.Masayuki Tokunaga,
Mr.Tomoo Masai, Mr.Masakazu Ioka, Mr.Pei Xia, Mr.Akira Goto, and Mr.Yuki
Yamanaka. Their technical comments have been very valuable for this work.
Finally, I would like to thank my famirly and all of my friends in or graduatedfrom Osaka University for their kind support and encouragement. I could complete
this work because I could have really enjoyed my days in Osaka University, which
is owing to them.

v

Contents
1 Introduction
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Overview of the Research . . . . . . . . . . . . . . . . . . . . . .
1.3 Overview of the Dissertation . . . . . . . . . . . . . . . . . . . .

1
1
3
6

2 A Survey on Code Clone Management
2.1 Code Clones . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Discussions on Code Clones . . . . . . . . . . . . . . . . . . . .
2.2.1 Causes of Creation . . . . . . . . . . . . . . . . . . . . .
2.2.2 Harmfulness . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Management of Code Clones . . . . . . . . . . . . . . . . . . . .
2.3.1 Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Definition . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 Text-based Techniques . . . . . . . . . . . . . . . . . . .
2.4.3 Token-based Techniques . . . . . . . . . . . . . . . . . .
2.4.4 Tree-based Techniques . . . . . . . . . . . . . . . . . . .
2.4.5 Graph-based Techniques . . . . . . . . . . . . . . . . . .
2.4.6 Other Detection Techniques . . . . . . . . . . . . . . . .
2.4.7 Comparison and Evaluation of Clone Detectors . . . . . .
2.5 Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1 Refactoring . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.2 Refactoring Patterns Used for Code Clone Removals . . .
2.5.3 Research on Clone Removal . . . . . . . . . . . . . . . .
2.6 Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7 Analytic Methodology . . . . . . . . . . . . . . . . . . . . . . .

7
7
7
8
10
10
12
15
15
15
16
16
17
17
18
19
20
21
21
22
23
29
31
32

vii

2.7.1 Filtering and Categorizing . . . . . . . . . . . . . . . . .
2.7.2 Visualizing . . . . . . . . . . . . . . . . . . . . . . . . .
Detection and Prevention of Clone Related Bugs . . . . . . . . .
2.8.1 Preventing Clone Related Bugs . . . . . . . . . . . . . .
2.8.2 Detecting Clone Related Bugs . . . . . . . . . . . . . . .

32
35
38
38
39

3 An Empirical Study on Influences for Clones on Software Evolution
3.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Motivating Example . . . . . . . . . . . . . . . . . . . .
3.2.2 Objective of this Study . . . . . . . . . . . . . . . . . . .
3.3 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Clone Detectors Used in This Research . . . . . . . . . .
3.3.2 Revision . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Target Revision . . . . . . . . . . . . . . . . . . . . . . .
3.3.4 Modification Place . . . . . . . . . . . . . . . . . . . . .
3.4 Proposed Method . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Research Questions and Hypotheses . . . . . . . . . . . .
3.4.2 Modification Frequency . . . . . . . . . . . . . . . . . .
3.5 Design of Experiment . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 Experiment 1 . . . . . . . . . . . . . . . . . . . . . . . .
3.5.2 Experiment 2 . . . . . . . . . . . . . . . . . . . . . . . .
3.6 Experiment 1 - Result and Discussion . . . . . . . . . . . . . . .
3.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.2 Result of Experiment 1-1 . . . . . . . . . . . . . . . . . .
3.6.3 Result of Experiment 1-2 . . . . . . . . . . . . . . . . . .
3.6.4 Answers to Research Questions . . . . . . . . . . . . . .
3.6.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 Experiment 2 - Result and Discussion . . . . . . . . . . . . . . .
3.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.2 Result of MASU . . . . . . . . . . . . . . . . . . . . . .
3.7.3 Result of OpenYMSG . . . . . . . . . . . . . . . . . . .
3.7.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . .
3.8 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41
41
42
42
45
45
45
47
47
48
48
48
49
52
53
53
57
57
57
61
65
66
67
67
70
71
72
74
76

4 Enhancing CRD-based Clone Tracking based on Similarity of CRD
4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Tracking clones . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Clone Region Descriptor . . . . . . . . . . . . . . . . . .

79
79
81
82

2.8

viii

4.3

4.4

4.5
4.6
4.7

4.2.2 Hash generation . . . . . . . . . . . . . . . . . . . . . . 83
4.2.3 Clone Linking . . . . . . . . . . . . . . . . . . . . . . . 84
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.3.1 Hash generation . . . . . . . . . . . . . . . . . . . . . . 88
4.3.2 Clone Linking . . . . . . . . . . . . . . . . . . . . . . . 90
Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.4.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.4.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . 92
4.4.3 Answer to QUESTION1 . . . . . . . . . . . . . . . . . . 92
4.4.4 Answer to QUESTION2 . . . . . . . . . . . . . . . . . . 96
Revealing why clones are gone . . . . . . . . . . . . . . . . . . . 98
Threats To Validity . . . . . . . . . . . . . . . . . . . . . . . . . 102
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5 Analyzing Clone Genealogies with the Enhanced Clone Tracking
5.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Detecing Clone Genealogies . . . . . . . . . . . . . . . . . . . .
5.3.1 Detection of Code Clones . . . . . . . . . . . . . . . . .
5.3.2 Definition of Clone Genealogy . . . . . . . . . . . . . . .
5.3.3 Definitions of Terms Related to Clone Genealogy . . . . .
5.3.4 Example of Clone Genealogy . . . . . . . . . . . . . . .
5.4 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . .
5.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.1 Long-Lived and Frequently Modified Code Clones . . . .
5.6.2 Threats to Validity . . . . . . . . . . . . . . . . . . . . .
5.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

105
105
106
107
107
107
109
110
111
113
125
125
125
126

6 Clone Removal with Form Template Method Refactoring
6.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Issues of Previous Studies . . . . . . . . . . . . . . . . .
6.2.2 Objective of This Study . . . . . . . . . . . . . . . . . .
6.3 Outline of the Proposed Method . . . . . . . . . . . . . . . . . .
6.3.1 Inputs and Outputs . . . . . . . . . . . . . . . . . . . . .
6.3.2 Specialization of PDGs . . . . . . . . . . . . . . . . . . .
6.3.3 Processing Flow . . . . . . . . . . . . . . . . . . . . . .
6.3.4 Definitions . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Supporting for Method Pairs . . . . . . . . . . . . . . . . . . . .

127
127
128
128
132
133
133
134
136
138
142

ix

6.4.1
6.4.2
6.4.3
6.4.4
6.4.5

6.5

6.6

6.7

6.8

6.9

STEP-P1: Create PDGs . . . . . . . . . . . . . . . . . .
STEP-P2: Detect Code Clones . . . . . . . . . . . . . . .
STEP-P3: Identify Method Pairs . . . . . . . . . . . . . .
STEP-P4: Detect Common and Unique Processes . . . . .
STEP-P5: Detect Sets of Statements Extracted as a Single
Method . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.6 STEP-P6: Detect Pairwise Relationships . . . . . . . . .
Supporting for Method Groups . . . . . . . . . . . . . . . . . . .
6.5.1 STEP-S7: Identify Method Groups . . . . . . . . . . . .
6.5.2 STEP-S8: Detect Common and Unique Processes . . . . .
6.5.3 STEP-S9: Detect Relationships on ENSs . . . . . . . . .
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.2 Functionalities for Method Pairs . . . . . . . . . . . . . .
6.6.3 Functionalities for Method Groups . . . . . . . . . . . . .
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7.1 Evaluation of Supporting for Method Pairs . . . . . . . .
6.7.2 Evaluation of Supporting for Method Groups . . . . . . .
6.7.3 Experiment with Subjects . . . . . . . . . . . . . . . . .
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8.1 PDG Creation . . . . . . . . . . . . . . . . . . . . . . . .
6.8.2 Detection of Common Statements . . . . . . . . . . . . .
6.8.3 Candidates that Need to be Tailored . . . . . . . . . . . .
6.8.4 Detection of Method Groups . . . . . . . . . . . . . . . .
6.8.5 Threats to Validity of the Experiment with Subjects . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

142
142
144
145
147
155
159
159
159
161
162
162
162
168
168
169
171
172
176
176
177
177
178
178
178

7 Conclusion
181
7.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
7.2 Future Research Directions . . . . . . . . . . . . . . . . . . . . . 183

x

List of Figures
2.1 Clone Pair and Clone Set . . . . . . . . . . . . . . . . . . . . . .
2.2 Types of Clones . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 An Example of ASTs . . . . . . . . . . . . . . . . . . . . . . . .
2.4 A Clone Pair with a Differnt Order of Statements . . . . . . . . .
2.5 An Example of Extract Class . . . . . . . . . . . . . . . . . . .
2.6 An Example of Extract SuperClass . . . . . . . . . . . . . . . .
2.7 An Example of Extract Method . . . . . . . . . . . . . . . . . .
2.8 An Example of Pull Up Method . . . . . . . . . . . . . . . . . .
2.9 An Example of Parameterize Method . . . . . . . . . . . . . .
2.10 An Example of Refactorings with Form Template Method . . .
2.11 Rieger et al.’s Visualization (Duplication Web) (Cited from the literature [130]) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.12 An Arc Diagram (Cited from the literature [152]) . . . . . . . . .
2.13 Clone Visualization with Bundle Edge View (Cited from the literature [40]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.14 Clustered Source Files based on Their Similarities (Cited from theliterature [162]) . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.15 An Exapmle of Scatter Plots Shown by Gemini [147] . . . . . . .

8
9
18
19
24
24
25
26
26
28

3.1 Motivating Example of Our Empirical Study . . . . . . . . . . . .
3.2 A Simple Example of Comparing Two Source Files with diff . . .
3.3 Result of Item A on Experiment 1-1 . . . . . . . . . . . . . . . .
3.4 Result of Item B on Experiment 1-1 . . . . . . . . . . . . . . . .
3.5 Result of Item A on Experiment 1-2 . . . . . . . . . . . . . . . .
3.6 Result of Item B on Experiment1-2 . . . . . . . . . . . . . . . . .
3.7 An Example of Unstable Cloned Code . . . . . . . . . . . . . . .
3.8 Result of the Proposed Method on MASU . . . . . . . . . . . . .
3.9 Result of Krinke’s Method on MASU . . . . . . . . . . . . . . .
3.10 Result of Lozano’s Method on MASU with Simian . . . . . . . .
3.11 Result of the Proposed Method on OpenYMSG . . . . . . . . . .

43
47
57
59
62
63
68
70
70
71
72

xi

35
36
36
37
37

3.12 Result of Krinke’s Method on OpenYMSG . . . . . . . . . . . .
3.13 Result of Lozano’s Method on OpenYMSG with Simian . . . . .
3.14 An Example of Modification by Refactoring . . . . . . . . . . . .

72
73
73

4.1
4.2
4.3
4.4
4.5
4.6

Actual modification that existing techniques cannot track clones . 80
Clone Region Descriptor . . . . . . . . . . . . . . . . . . . . . . 82
Intuitive example how hash values are measured from source code
85
Example of clone tracking . . . . . . . . . . . . . . . . . . . . . 87
Example of Database Updating . . . . . . . . . . . . . . . . . . . 89
Number of blocks that were not tracked by the proposed or conventional methods . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.7 An EBG that only the proposed method tracked . . . . . . . . . . 95
4.8 Cloned blocks not tracked by the proposed method because types
in their conditions were changed . . . . . . . . . . . . . . . . . . 97
4.9 Cloned blocks not tracked by the proposed method because theirconditions were changed . . . . . . . . . . . . . . . . . . . . . . 98
4.10 Number of EBGs whose elements disappeared . . . . . . . . . . . 100
4.11 Code where an unintended inconsistency occurred . . . . . . . . . 101
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8

An Example of Clone Genealogies . . . . . . . . . . . . . . . . .
The Length of Lifetime (Revisions) . . . . . . . . . . . . . . . .
The Length of Lifetime (Days) . . . . . . . . . . . . . . . . . . .
CDF(k) and R(k) . . . . . . . . . . . . . . . . . . . . . . . . . .
The Number of Modifications . . . . . . . . . . . . . . . . . . .
Modifications on Each Genealogy . . . . . . . . . . . . . . . . .
Timing of Modifications on Individual Clone Genealogies . . . .
An Instance of Long-Lived and Frequently Modified Clones . . .

111
114
115
117
119
121
123
124

6.1 Motivating Example 1 . . . . . . . . . . . . . . . . . . . . . . .
6.2 Motivating Example 2 . . . . . . . . . . . . . . . . . . . . . . .
6.3 The Output of the Proposed Method . . . . . . . . . . . . . . . .
6.4 An Example of PDG . . . . . . . . . . . . . . . . . . . . . . . .
6.5 An Example of PDG with Execute Dependence Edges . . . . . .
6.6 Data Dependence Considering State Changes of Objects . . . . .
6.7 A Directed Graph . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8 A PDG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.9 ClonePairs(G1 , G2 ) . . . . . . . . . . . . . . . . . . . . . . . .
6.10 An example of Method Pairs Including Redundant Clone Pairs . .
6.11 An example of the Detection of ENSs . . . . . . . . . . . . . . .
6.12 An Example of Inputs and Outputs of ENSs . . . . . . . . . . . .

130
131
134
135
136
137
138
140
141
147
148
149

xii

6.13 Behavior of Algorithm 6.4 . . . . . . . . . . . . . . . . . . . . . 154
6.14 An Instance of Segmentalization of Block Statements . . . . . . . 154
6.15 An Example of Wrong Pairwise Relationships Caused by not Considering Conditions for Call . . . . . . . . . . . . . . . . . . . . . 157
6.16 An Example of Pairwise Relationships . . . . . . . . . . . . . . . 158
6.17 An Example of Method Group . . . . . . . . . . . . . . . . . . . 160
6.18 A Whole Snapshot of CRat (for Method Pairs) . . . . . . . . . . . 162
6.19 A Snapshot of Source Code View . . . . . . . . . . . . . . . . . . 163
6.20 A Snapshot of PDG View . . . . . . . . . . . . . . . . . . . . . . 164
6.21 A Snapshot of Apposing View of Source Code View and PDG View 165
6.22 An Example of Candidate Method Pair . . . . . . . . . . . . . . . 166
6.23 A Snapshot of Filtering View . . . . . . . . . . . . . . . . . . . . 167
6.24 A Metrics Graph . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6.25 View of the Metrics Values . . . . . . . . . . . . . . . . . . . . . 168
6.26 A Whole Snapshot of CRat (for Method Groups) . . . . . . . . . 169
6.27 An Example of Application of Form Template Method with the
Proposed Method . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.28 The Box-Plot of the Time to Apply Form Template Method on
Synapse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
6.29 Candidate Method Groups . . . . . . . . . . . . . . . . . . . . . 173

xiii

List of Tables
2.1

Overview of Methods for Filtering/Categorizing/Clustering Clones

33

3.1 Target Software Systems - Experiment 1 . . . . . . . . . . . . . .
3.2 Overview of Investigation Methods . . . . . . . . . . . . . . . . .
3.3 Target Software Systems - Experiment 2 . . . . . . . . . . . . . .
3.4 Ratio of Code Clones - Experiment 1 . . . . . . . . . . . . . . . .
3.5 Overall Results - Experiment 1 . . . . . . . . . . . . . . . . . . .
3.6 The Average Values of M F in Experiment 1-1 . . . . . . . . . .
3.7 Comparing M F s based on Programming Language and Detector .
3.8 The Average Values of M F in Experiment 1-2 . . . . . . . . . .
3.9 Ratio of Code Clones - Experiment 2 . . . . . . . . . . . . . . . .
3.10 Overall Results - Experiment 2 . . . . . . . . . . . . . . . . . . .

54
54
57
58
60
60
64
64
67
69

4.1
4.2
4.3
4.4
4.5
4.6

Overview of Target Software - Target Revisions - . . . . . . . . .
Overview of Target Software - LOC - . . . . . . . . . . . . . . .
Timing information on experiment (execution with eight threads) .
Modification types that the proposed technique could track . . . .
Moditications preventing the proposed method from tracking clones
Reasons why clones were gone . . . . . . . . . . . . . . . . . . .

91
91
92
96
99
99

5.1
5.2
5.3
5.4
5.5

Target Software Systems . . . . . . . . . . . . . . . . . . . . . .
Long-Lived Genealogies which are Modified Multiple Times . . .
Spearman’s Rank Correlation Coefficients . . . . . . . . . . . . .
Timing of Modifications on Quartered Periods . . . . . . . . . . .
The Results of Chi-Square Test . . . . . . . . . . . . . . . . . . .

112
120
122
122
124

6.1
6.2
6.3

The Values of Metrics in the Method Pair of Figure 6.22 . . . . . 166
Target Software Systems . . . . . . . . . . . . . . . . . . . . . . 169
The Number of Detected Candidates and Elapsed Time on Method
Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
xv

6.4
6.5
6.6
6.7
6.8
6.9

The Number of Detected Candidates and Elapsed Time on Method
Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Features of Target Method Groups . . . . . . . . . . . . . . .
Groups of Subjects . . . . . . . . . . . . . . . . . . . . . . . . .
Elapsed Time to Finish Form Template Method Application . .
The Average Time . . . . . . . . . . . . . . . . . . . . . . . . . .
The Candidates that Need some Modifications for CRat’s Outputs

xvi

171
172
174
175
175
177

Chapter 1

Introduction
1.1 Background
Software evolution refers to the process of developing software initially andrepeatedly updating it for various reasons. The term lacks a general definition, but
it is used as a substitute of software maintenance [17, 123]. One of the reasons
why it refers to specifically the maintenance phase of software development isthat the phase consumes a large amount of costs for developing typical softwaresystems [19].
Software maintenance is one of the software life cycle processes [1]. It is aset of activities associated with changes to a software product after it has beendelivered to end users. ISO/IEC 14764 presents the following four categories ofsoftware maintenance activities [2].
Corrective: reactive modification to correct discovered problems. This category
also includes emergency maintenance which is defined as unsheduled andtemporary maintenance to keep a software system operational.
Adaptive: modification to keep a software product usable in a changed/changing
enviroment.
Perfective: modification to improve some aspect of software quality, such as performance, maintainability, or reliability.
Preventive: modification to detect and correct latent faults in a software productbefore they appear as actual faults.
The role of software systems in social activities has become more and more
important, which also inidicates the high importance of software maintenance activities. However, the growth of size and complexity of software products makes
1software maintenance more difficult and more burdensome. Czerwonka et al. reported common characteristics of software maintenance as follows [25].
• Software maintenance phase comsumes the majority of resources of software
life cycle processes. Vliet said that maintenance phase requires at least 50%
of total costs in his book [149].
• It often happens that maintenance tasks are done by people who had not
created the software product.
• The maintenance team is typically much smaller than the development team.
• Changes on deployed software sometimes introduce unwanted behavior, whichindicates that maintenance activities have a high risk.
• Creating and verifying a fix for deployed software frequently have to be donein a limited time frame.
These characteristics indicate how difficult and how severe software maintenance is. Because of these factors, technologies that make software maintenancemore efficient are strongly required in society.
This dissertation focuses on code clones to meet such a challenging requirement. A code clone, or simply a clone, is defined as ‘a code fragment that has
identical or similar code fragments to one another’. The presence of code clones
is pointed out as a bad smell for software maintenance [32]. The reason is that: if
we need to make a change in one place, we will probably need to change the others
as well, but we sometimes might miss it [98].
The harmfulness of code clones could cause collapses of software projects at
the worst case. One of such cases is the collapse of the software project of theJapan Patent Office in the Ministry of Economy, Trade and Industry, Japan. Reusesof existing code that was not well-tested introduced many negative code clones,
which was pointed out as one of the causes of the collapse [52]. As just described,
the harmfulness of code clones appears in real software projects. For these reasons,code clones have a high level of interest, which makes code clone analysis a hot
topic in the research area of software engineering.
In spite of the potential harmfulness of code clones, software systems contain acertain amount of code clones [7]. One of the typical situations where code clones
are introduced in software systems is cloning existing code by copy-and-paste operations. Code cloning by copy-and-paste operations should result in creating newcode clones, but it has a strong advantage that it allows developers to implement
new functions quickly. Developers, therefore, often perform such instant reuses ofcode [76, 163]. This is a typical reason why code clones exist in software systems
2even though the presence of code clones is regarded as a bad smell for software
maintenance.
For these reasons, managing code clones is necessary to avoid or reduce negative impacts of code clones and to take advantage of code cloning. Herein, theterm ‘code clone management’ means the whole activities on code clones, including locating, monitoring, tracking or removing them [84]. The eventual goal of thisresearch is to achieve an effective management of code clones for efficient software
maintenance.

1.2 Overview of the ResearchThis dissertation presents the results of four studies, all of which are closely
related to management of code clones. The first one is an empirical study on theinfluences of code clones. The second one improves a conventional technique to
track code clones across version histories of source code. The third one is anotherempirical study on clone evolution, which analyzes genealogies of code clones.
The last one is a technique to support removing code clones that cannot be removed
easily.
An Empirical Study on the Influences of Code Clones
For efficient management of code clones, it is necessary to know how harmfulcode clones are. If code clones are not harmful, it should be reasonable for efficient software maintenance to deal with other factors instead of code clones. On
the other hand, if code clones have negative impacts on software maintenance, it
should be valid to pay attention to code clones. Although some research efforts
have been done to reveal the impact of code clones on software maintenance, theargumentation on the harmfulness of code clones is still open.
In this study, we conducted an empirical study on how harmful code clones
are. The key idea of this study is that code clones have a negative impact if codefragments included in at least one code clone are modified more frequently thanones that are not included in any code clones. We proposed a new metric named
Modification Frequency to capture our key idea, which is calculated based on thenumber of modifications, not the number of changed lines of code. We conducted
an experiment on open source software systems with multiple code clone detectors.
Our experimental results showed the following findings:• Code fragments included in code clones are not modified more frequently
than ones not included in code clones totally, but there exists some code
clones modified frequently.
3• Modification frequencies on code clones differ from code clone detectors.
• Modification frequencies on code clones are variable throughout their lifetime.
To summarize our experimental results, it is not always true that code clones
have a negative impact on software maintenance, but there exists some instancesthat have a negative impact. This finding indicates the importance to detect andfocus on code clones that affect software maintenance negatively.
Tracking Clones’ Evolution across Version Histories
Tracking clones allows us to know how they evolved. Detecting clone evolution, which represents how a code clone evolves, should contribute to a successful
clone management. The bases of this are as follows.
• Analyzing clone evolution provides us with phenomena and characteristics
of clones that cannot be revealed by analyzing clones at the latest revision ofcode.
• Clone evolution tells us when and how it was modified, which enables us
to find unintended inconsistencies of modifications on code clones. In otherwords, clone evolution can be used to detect bugs related to code clones.
There exists some techniques to track clones in version histories. Clone Region
Descriptor [27] (refered as CRD) is one of the well known techniques for clone
tracking. CRD tracks clones based on their locations, which allows CRD to surpassthe other techniques in change-tolerance on clones. In other words, CRD can trackclones that the other techniques cannot.
Although the original CRD-based tracking has good change-tolerance, it has aroom for improvement. This study enhances the original CRD-based tracking andrealizes better change-tolerance than the original one. Also, this study reveals thereason of clone disappearances with the enhanced CRD. As well as the investigation of clone disappearances, the enhanced tracking will be able to be a basis of thefurther research on clone evolution.
Analyzing Genealogies of Code Clones with the Enhanced Clone Tracking
Technique
Clone tracking allows us to analyze the influences of clones more detail because it can tell how an individual clone evolves. However, because our previous
study on the influcences of clones does not consider evolution of them, it cannot
4

reveal the influcences of individual clones. Although our manual inspections foundsome instances of clones having negative impacts, our previous study did not reveal how many clones have negative impacts on software evolution. To know theinfluences of clones more detail, this study analyzes the influences of clones withthe clone tracking technique that enhances the CRD-based tracking.
This fine-grained analysis revealed that there are a few code clones that should
require much attention of developers or maintainers. This finding empirically supports the results of the first study, which is that not all but a part of clones havenegative impacts. Our another finding through this study is that clones tend to bemodified more frequently in former halves than in latter halves of their lifetimes.
Hence, we can say that it is important to find negative clones in their earlier stages
and start dealing with them as soon as possible.
A Support for Removing Code Clones
The two previous studies revealed that not all but a part of clones has negative
impacts on software maintenance. To achieve an intelligent clone management, itis necessary to handle negative clones.
Removing code clones is one of the effective ways to handle negative clones.
However, the activity has not just positive aspects but also negative ones. The
negative aspects of removing code clones are as follows.
Risky: To remove code clones from source code, of cource, it is necessary to
make some modifications on the source code. Careless removal of code
clones may introduce new bugs into the source code.
Costly: Removing code clones requires much effort for software maintainers.
They need to locate code clones to be removed, consider how to remove
them, and decide whether they should remove the code clones or not.
These characteristics become more noticeble in the case that code clones tobe removed have some gaps. Gaps included in code clones make the removal
process of the clones more complicated. This means that removing such clones ismore risky and more costly. Therefore, techniques to assist removing clones havingsome gaps are required for software maintainers to achieve such a challenging task.
This study proposed a novel technique to support removing code clones havingsome gaps. This technique regards wholes of methods having code clones as its target, instead of targetting code clones themselves. Focusing on wholes of methods
enables to remove code clones having some gaps easily. By applying the proposed
technique to similar methods, code clones existing between them are merged withunique processes of each method remained preserved.
5

We have implemented the proposed technique as a tool named CRat, and confirmed the effectiveness of it through case studies.

1.3 Overview of the Dissertation
The rest of this dissertation is organized as follows.
Chapter 2 refers to current states of research on code clones. It privides a definition of code clones, and introduces some discussions around them. Furthermore,
it explores literatures of research on code clones with five categories, including
detection, removal, prevention, analysis, and finding bugs related to clones.
Chapters 3, 4, 5, and 6 present the four studies described above. In Chapter 3,
we describe the study on stability of code clones. This chapter presents the methodology, the experimental targets, and the results of this empirical experiment, andthen it compares the experimental results with other experimental methodologies
proposed by other researchers.
Chapter 4 explains a new clone tracking technique based on CRD. It describes
our key idea to track code clones more accurately, and comfirms improvements ofaccuracy of clone tracking through an experiment on two open source software systems. Moreover, it presents an application of the clone tracking technique, which
reveals why and how frequently clones are gone.
Chapter 6 presents a refactoring support for code clones. It formally describes
the clone removal technique, and then it explains a tool implementation of the
proposed method. In addition, it validates the usefulness of the proposed method
through two experiments, one of which is on open source software systems, andthe other one is with some subjects.
Finally, Chapter 7 concludes this dissertation with a summary and directions
for future work.

6

Chapter 2

A Survey on Code Clone
Management
2.1 Code Clones
2.1.1 Definition
A code clone is a set of code fragments that are similar to each other according
to some definitions of similarity [15]. As this definition expresses, there exists avagueness on the definition of code clones. That is, there is no formal or genericdefinition of them. Therefore, every clone detector has its own definition of code
clones [43,54,131]. Establishing a suitable definition of code clones is still an open
issue for all the researchers who are intereseted in them [84].
Here, we introduce some terms around code clones; clone relationship, clone
pair, cloned fragment, and clone set. Let α and β be code fragments, and assume
that they are similar to each other. Then, it is defined that there is a clone relationship between α and β. In addition, a pair of the two code fragments (α, β) is
called a clone pair, and each code fragment of which a clone pair consists is calleda cloned fragment. Moreover, a set of code fragments is called a clone set if every
code fragment included in the set is similar to all the other fragments in the set.
Note that clone set has alternative names such as clone class or clone group. Thisdissertation, however, uses clone set among its alternatives.
Figure 2.1 shows a simple example of clone pairs and clone sets. This example
has three code fragments, α, β, and γ, and they have clone relationships to eachother. Hence, there are three clone pairs (α, β), (β, γ), and (α, γ) in this example.
In addition, there is a clone set that consists of the three cloned fragments α, β, andγ.
7

A Clone Pairαγ

A Clone Pair

A Clone Pairβ

A Clone Set

Figure 2.1: Clone Pair and Clone Set
2.1.2 Types
Code clones can be categorized into the following three types by the degree of
their similarities [16].
Type-1: An exact copy except for white spaces and comments.
Type-2: Syntactically identical copy; only identifiers of variables, types, literals,
or functions were changed.
Type-3: A copy with further modifications in Type-2; statements were changed,
added, or removed.
Adding to the traditional three types, some researchers have proposed anothertype of clones, which is referred as Type-4 clones. The following is the definition
of Type-4 clones [131].
Type-4: Fragments perform the same computation but implemented through different syntactic variants.
Type-1, Type-2, and Type-3 clones can be said as syntactically similar, whereas
Type-4 clones can be said as semantically similar.
Figure 2.2 describes each type of clones. Figure 2.2(a) represents the originalcode fragment, and the other fragments shown in Figures 2.2(b), 2.2(c), 2.2(d), and2.2(e) are clones of the original fragment.
8

1: public static int sum(int[] a) {2:
int result = 0;
3:
for (int i = 0; i < a.length; i++) {4:
result += a[i];5:}6:return result;
7: }(a) Original Fragment
1: public static int sum(int[] a) {2:
int result = 0;
3:
4:
for (int i = 0; i < a.length; i++) {5:// adding a[i] into result
6:
result += a[i];
7:
}
8:
9:
return result;
10: }1: public static int sum(int[] a) {2:
int s = 0;
3:
for (int j = 0; j < a.length; j++) {4:
s += a[j]; // adding a[j] into s
5:}
6:
return s;
7: }(b) Type-1 Clone(c) Type-2 Clone
1: public static int sum(int[] a) {2:
return calc(a, 0);
3: }4:
5: public static int calc(int[] a, int i) {6:
if (i < a.length) {7:
return a[i] + calc(a, i + 1);
8:} else {9:return 0;
10:
}
11: }

1: public static int sum(int[] a) {2:
int s = 0;
3:
for (int i = 0; i < a.length; i++) {4:
s += a[i];5:}6:// printing the result
7:
System.out.println(“the sum is “ + s);
8:return s;
9: }(d) Type-3 Clone(e) Type-4 Clone

Figure 2.2: Types of Clones

The code fragment in Figure 2.2(b) is an exact copy of the original one except
for the different layout and the presence of a comment. This means that the codefragment in Figure 2.2(b) and the original one consists of a Type-1 clone. Figure
2.2(c) shows another code fragment having some differences compared to the one
in Figure 2.2(a). In addition to the presence of a comment, this code fragment has
different names of variables from the original one. Hence, the code fragment in
Figure 2.2(c) is a Type-2 clone of the original one. Figure 2.2(d) presents a codefragment having more gaps than the one in Figure 2.2(c). This code fragment has
not only differences of variable names and comments but also a statement that theoriginal fragment does not have. Therefore, the clone shown in 2.2(d) is a Type-3
clone.
As these figures show, code fragments shown in Figures 2.2(b), 2.2(c), and2.2(d) are textually similar. In contrast, the one in Figure 2.2(e) is no longer similar
to the original in the text level. However, the method sum in Figure 2.2(e) and theoriginal method sum in Figure 2.2(a) compute the same values from the same9

arrays. In other words, these two methods functionally equal to each other. This isan example of Type-4 clones that are semantically similar to each other.

2.2 Discussions on Code Clones
2.2.1 Causes of Creation
Code clones are created into software systems by a variety of reasons. Baxter
et al. listed the followings as the reasons [15].
Code reuse by copying pre-existing idioms: Code cloning by developers will introduce code clones into software systems. This is the most popular situationthat code clones are created. Code reuse by copy-and-paste operations is acommon practice in software development, because it is quite easy, and it
enables to make software development faster.
Coding styles: Some functions should be coded in accordance with standard styles.
Error reporting or user interface displays will be typical instances of suchfunctions. These styles sometimes create clones, because functions that arecoded in the same style have a high possibility that they are similar to eachother.
Instantiations of definitional computations: Many of simple and frequently usedfunctions will be repeated in software systems even when copying is not
used, which results in the presence of clones. Payroll tax, queue insertion,
or data structure access are instances of such functions.
Failure to identify/use abstract data types: Some programming languages do
not support abstract data types. If software systems are written in such languages, functions intended for use on another data structure of the same typewill be duplicated. Baxter et al. reported that “we have founded many systems with poor copies of insertion sort on different arrays scattered aroundthe code”, which is an instance of clones created by this reason.
Performance enhancement: Some clones are introduced intentionally for performance reasons. Code abstraction, such as extracting existing features as
new methods, will reduce code duplications, but may introduce overheadsof execution. Hence, developers of systems having tight time constraints
sometimes repeat the same functions without abstracting them to avoid occurences of such overheads.
Accidents: Different developers may write similar code accidentally. However, it
is rare that the amount of similar code generated accidentally becomes high.
10In addition, using code generation tools, plagiarism of code, and padding theamount of code by intentional cloning are pointed out as causes of clone creation[71].
Among a variety of reasons, code cloning by developers is the most typicalcause of clone creation.
Kapser and Godfrey categorized patterns of cloning into the following fourgroups [74].
Forking: cloning the existing code as a ‘springboard’ of development of similarsolutions. A case of this group of cloning is that developers create a new
driver for a hardware family by cloning the existing driver and tailor it to
new one. In this cloning group, cloned fragments will evolve independently
from the original code.
Templating: cloning when the desired behavior is already known and an existing solution closely satisfies this need. One simple example is to achieve
the same behavior for float and short in the C programming language.
Cloned fragments created by patterns of cloning categorized into this groupwill evolve closely to the original code.
Customization: cloning when existing code solves a very similar problem to thecurrent development problem, but it cannot be used to solve the current problem as is. In such a case, developers clone the existing code, and make somecustomizations on it to handle the current problem.
Exact Matches: cloning to solve a particular problem repeated with in a softwaresystem. Cloning categorized into this group occurs in the case that the cloned
code is too small or there is little worthwhile to abstract the solution of the
problem. One of the examples is cross-cutting concerns such as logging or
debugging.
Some researchers revealed why code cloning occurs in development of experimental software systems.
Kim et al. investigated the reasons why developers clone code with researchers
in IBM Corporation [76]. Their research showed that some clones were created byunavoidable reasons including limitations of programming languages.
As well as Kim et al.’s investigation, Zhang et al. analyzed the situations wherecode cloning occurs in a commercial software system [163]. Their interviews fordevelopers of the system revealed that close to half of developers claimed that they
“often” clone code by copy-and-paste, and almost all of the remaining subjects
claimed that they “sometimes” do code cloning. Furthermore, they found that developers copy existing code by not only technical reasons, including “Avoiding
11

breaking existing features” and “Difficult to be reused”, but also the presence oftime limitations or some organizational reasons, including “Issues of code ownership”.
Summarizing these findings, ad hoc reuse of the existing code by code cloning
is not only a common practice but also sometimes unavoidable one. Hence, it is
impossible to avoid creating clones in software systems completely.
2.2.2 Harmfulness
At present, there is a huge body of work on empirical evidence on code clones,
starting with Kim et al.’s report on clone genealogies [78]. They have conducted
an empirical study on two open source software systems, and found that 38% or
36% of groups of code clones were consistently changed at least once. On theother hand, they observed that there were groups of code clones that existed only
for short periods (five or ten revisions) because each instance of the groups was
modified inconsistently. Their work is the first empirical evidence that a part ofcode clones, not all of them, increases costs required for modifications on source
code.
However, Kasper and Godfrey have different opinions regarding code clones.
They reported that code clones can be a reasonable design decision based on an
empirical study on two large-scale open source systems [74]. They built several
patterns of code cloning in the target systems, and they discussed the pros andcons of code cloning using the patterns. Bettenburg et al. also reported that code
clones do not seriously affect software quality [18]. They investigated inconsistentchanges to code clones at the release level on two open software systems, and theyfound that only 1.26% to 3.23% of inconsistent changes introduced software errors
into the target systems.
Monden et al. investigated the relation between software quality and code
clones on the file level [115]. They used the number of revisions of every file
as a barometer of quality: the larger the number of revisions of a file is, the lower
its quality is. They selected a large scale legacy system, which had been being operated in a public institution, as the target of their experiment. The result showed
that, modules including code clones were 40% lower quality than modules not including code clones. Moreover, they reported that the more code clones a source
file included, the lower quality it has.
Lozano et al. investigated whether the presence of code clones was harmful or
not [100]. They developed a tool that traces which methods include code clones (inshort, duplicate method) and which methods are modified in each revision. They
conducted a pilot study, and found that: duplicate methods tended to be more frequently modified than non-duplicate methods; however, duplicate methods tended
12to be modified less simultaneously than non-duplicate methods. Their findings
imply that the presence of code clones increased costs for modifications, and programmers were not aware of code duplications, so that they sometimes overlooked
code fragments that had to be modified simultaneously.
Also, Lozano and Wermelinger investigated the impact of code clones on software maintenance [101]. Three barometers were used in the investigation. The firstone is likelihood, which indicates the possibility with which a method is modified
in a revision. The second one is impact, which indicates the number of methods thatare simultaneously modified with a method. The third one is work, which can be
represented as a product of likelihood and impact (work = likelihood × impact).
They conducted a case study on four open source systems for comparing the threebarometers of methods including and not including code clones. The result showed
that: likelihood of methods including code clones was not so different from oneof methods not including code clones; there were some instances that impact of
methods including code clones were greater than one of methods not includingcode clones; if code clones existed in methods for a long time, their work tended
to increase greatly.
Moreover, Lozano et al. investigated the relation between code clones, features of methods, and their changeability [103]. Changeability means the ease ofmodifications. If changeability decreased, it will be a bottleneck of software maintenance. The result showed that the presence of code clones can decrease changeability. However, they found that changeability was more greatly affected by otherproperties such as length, fan-out, and complexity of methods. Consequently, they
concluded that it was not necessary to consider code clones as a primary option.
Krinke hypothesized that if code clones are less stable than code fragments thatare not included in any code clones, maintenance costs for cloned code are greaterthan those for non-cloned code. He conducted a case study in order to investigate
whether the hypothesis is true or not [88]. The targets were 200 revisions (a version per week) of source code of five large scale open source systems. He measured
added, deleted, and changed LOCs on cloned code and non-cloned code, and compared them. He reported that non-cloned code was more frequently added, deleted,and changed than cloned code. In other words, code clones are more stable thannon-cloned code. Consequently, he concluded that the presence of code clones did
not necessarily make it more difficult to maintain source code.
Göde et al. replicated Krinke’s experiment [34]. Krinke’s original experiment
adopted line-based approach whereas their experiment adopted token-based approach. The experimental result was basically the same as Krinke’s one: cloned
code was more stable than non-cloned code in the viewpoint of addition and change.
On the other hand, from the viewpoint of deletion, non-cloned code is more stable
than cloned code.
13

Also, Krinke conducted an empirical study to investigate ages of code clones[89]. In this study, he calculated and compared average ages of cloned code andnon-cloned code on four large-scale Java software systems. He found that the
average age of cloned code is older than non-cloned code, which implies cloned
code is more stable than non-cloned code.
Rahman et al. investigated the relationship between code clones and bugs[128]. They analyzed four software systems written in C language with bug information stored in Bugzilla. They used Deckard, which is an AST-based clone
detector, and reported that only a small part of bugs located on code clones, andthe presence of code clones did not dominate bug appearances.
Göde modeled how Type-1 code clones were generated and how they evolved[33]. He investigated how code clones evolved with nine open source softwaresystems. The result showed that: the ratio of code duplications was decreasing as
time passed; the average lifetime of code clones was over a year; in the case thatcode clones were modified inconsistently, there were a few instances that additional
modifications were performed to restore their consistency.
Also, Göde et al. conducted an empirical study on clone evolution and performed a detailed tracking to detect when and how clones had been changed [35].
In their study, they traced clone evolution and counted the number of changes oneach clone genealogy. They manually inspected the result in one of the target systems, and categorized all the modifications on clones into consistent or inconsistent. In addition, they carefully categorized inconsistent changes into intentional orunintentional. They reported that almost all clones were never changed or changed
only once during their lifetimes, and only 3% of the modifications had high severity. Therefore, they concluded that many of clones do not cause additional change
effort, and it is important to identify clones having high threat potential to manage
code clones effectively.
To summarize these experimental results, some empirical studies reported thatcode clones should have a negative impact on software evolution whereas the others
reported the opposite result.
The former, which claims that clones are harmful, is summalized as follows.
• There exists many clone related bugs [65, 98].
• Methods having clones are more frequently modified than those not havingclones [100, 102].
• Methods having clones require more maintenance costs than those not having clones [101, 114].
• Modules having clones have less maintainability than those not having clones[115].
14

On the other hand, the latter, which states clones are not harmful, is summalized
as follows.
• Many clones live for only a short time period [78].
• Lack of modifing correspondents of cloned fragments rarely occur [5,18,35,
135, 143].
• Most of code clones have no relation to bugs [128].
• Clones are modified less frequently than non-cloned code [34, 38, 88, 89].
• There exists little clones that affect software maintenance (such as having
the same bugs) [74].
At present, there is no consensus on the impact of the presence of code clones
on software evolution. However, these variabilities of investigational results indicate that not all of clones are harmful, but a part of them negatively affect software
maintenance.

2.3 Management of Code Clones
2.3.1 Needs
As described in 2.2.1, code cloning is a common practice in actual softwaredevelopment. Moreover, in some cases, it is unavoidable because of limitationsof time, programming languages, or organizations. In addition, some researchers
claimed that most of clones cannot be easily removed [77, 78].
These facts indicate that it is no longer possible to completely prohibit clones
from existing in software systems.
Furthermore, as described in 2.2.2, not all but a part of clones has negative
impacts on software maintenance. This indicates that it is not effective to spend
much effort to prevent or remove clones that are not harmful [150].
Therefore, software maintainers should pay their attention to harmful clones by
preventing or removing them, or by assessing the presence of such harmful clones.
In other words, managing code clones is necessary to achieve effective software
evolution.
2.3.2 Definition
Because of the abstractiveness of the term “clone management”, there can bea variety of its definitions. This dissertation gets into line with the definition that15

Rainer Koschke stated in the literature [84]. He defined clone management asfollows.
“Software clone management comprises all activities of looking afterand making decisions about consequences of copying and pasting.”
This definition includes not only detetion or removal of clones but also all theother activities that are concerened about code clones.
This dissertation categorizes all the activities of clone management into thefollowing five categories.
• Detection• Removal• Prevention• Analytic methodology• Detection and prevension of clone related bugs
Research achievements in each category are introduced in the following subsections.

2.4 Detection
2.4.1 Overview
Clone detection is the most hot topic in the research area of code clones. Clone
detection reports the information where code clones are in target software systems. The role of clone detection is quite important because many of research or
techniques of clone management stand on it. Hence, great effort has been spenton clone detection, which has yielded many techniques and tools to automaticallydetect code clones from source code [43, 54, 71, 83, 129, 131].
Detectors of code clones can be classified into the following categories [16,43].
• Text-based• Token-based• Tree-based• Graph-based• Others
The remainder of this section describes each category in detail.
162.4.2 Text-based Techniques
Text-based detection techniques detect code clones by comparing every line ofcode as a string. They detect multiple consecutive lines that match in specified
threshold or more lines as code clones. The biggest advantage of this technique isthat it can detect code clones quickly compared with other detection techniques.
This technique requires no pre-processing on source code, which realizes the fast
detection. However, detectors based on this technique cannot detect code clones
including differences of coding styles (e.g. whether long lines are divided into
multiple lines or not).
The method proposed by Johnson [64] and the method proposed by Ducasse
et al. [28] are instances of text-based clone detectors. In these methods, every lineof code is compared after white spaces and tabs are removed. These methods arelanguage-independent because they compare lines of code textually.
Simian is one of the well-used text-based clone detectors [140], which canhandle many programming languages. DuDe is another text-based clone detector
that detects chains of smaller extract clones [154]. SDD is a scalable detector,
which generates index and inverted index for code fragments and their positions
and finds similar fragments with an n-neighbor distance algorithm [95].
2.4.3 Token-based Techniques
In the token-based approach, source code is lexed/parsed/transformed to a sequence of tokens. This technique detects common subsequences of tokens as code
clones. Compared to the text-based approach, the token-based approach is usuallyrobuster against code changes such as formatting and spacing. Detection speed isinferior as compared with text-based techniques, meanwhile superior as tree- orgraph-based approaches. This is because, in token-based approach, source codeneed not to be transformed into intermediate representations.
One of the famous clone detectors categorized into the token-based detectors
is CCFinder, developed by Kamiya et al. [72]. It has been widely used among researchers or engineers. A variety of enhancements has been proposed on CCFinder,
including an extended version named CCFinderX [21] and a distributed version
named D-CCFinder [99].
CP-Miner is also a token-based detector. CP-Miner has been developed by
Li et al. [98]. CP-Miner calculates a hash value from every statement, and thenit applies a frequent pattern mining algorithm to detect code clones [4]. Frequent
patterns do not have to be consecutive, which means that CP-Miner can detect
Type-3 clones.
RTF, a clone detector proposed by Basit et al, uses suffix arrays on tokens to17int num = k + size * 4;

Variable Declaration Statement

int

num

+
k

*
size

4

Figure 2.3: An Example of ASTs
reduce costs for clone detection [13].
Kawaguchi et al. developed SHINOBI, a token-based clone detector on an
IDE [75]. It works as an add-in of Microsoft Visual Studio, and it applies a tokenbased clone detection engine, which is similar to CCFinder.
2.4.4 Tree-based Techniques
In the tree-based detection, a program is parsed to a parse tree or an abstract
syntax tree (in short, AST) with a parser of the language in interest. An AST is oneof the intermediate representations that capture structures of source code. Figure
2.3 shows an example of ASTs. Tree-based techniques regard common subtrees ascode clones. This approach considers the structure of source code, therefore treebased detectors do not detect code clones ignoring the structure of source codesuch as code clones including a part of a method and a part of another method.
However, a disadvantage of this approach compared with text- and token-based
approaches is that it requires more costs including both of time and memories for
its clone detection because of the additional costs required to transform source code
to parse trees or ASTs.
One of the pioneers of AST-based clone detectors is CloneDR developed by
Baxter et al. [15, 23]. CloneDR compares subtrees of ASTs by characterization
metrics based on a hash function through tree matching, instead of comparing subtrees of ASTs directly. This processing allows CloneDR to detect code clones
quickly from large software systems. It can handle many programming languages.
18

fp3 = lookaheadset + tokensetsize;for (i = lookaheads(state); i < k; i++) {%fp1 = LA + I * tokensetsize;%
fp2 = lookaheadset;%
while (fp2 < fp3)%
*fp2++ |= fp1++;}

fp3 = base + tokensetsize;…
if (rp) {while ((j = *rp++) >= 0) {…
#fp1 = lookaheadset;#
fp2 = LA + j * tokensetsize;#
while (fp1 < fp3)#
*fp1++ |= *fp2++;}}(a) Code Fragment 1(b) Code Fragment 2

Figure 2.4: A Clone Pair with a Differnt Order of Statements
Moreover, it has a function to assist clone removal.
DECKARD is another well-used clone detector based on tree comparisons [61].
It applies a locality sensitive hashing algorithm [26] to detect code clones, whichallows DECKARD to detect Type-3 code clones.
Koschke et al. developed clones [85], which is also a tree-based approach aswell as CloneDR and DECKARD. It compares ASTs with a suffix tree algorithm
to have an increase of detection speed.
2.4.5 Graph-based Techniques
In the graph-based approach, code clones are detected by comparing graphs
created from source code. Isomorphic subgraphs are regarded as code clones inthis approach. Program dependence graph (in short, PDG) is one of the well-usedgraphs to detect code clones, which is a directed graph that represents dependencies
between elements of programs [31, 153].
These graphs require semantic analyses for their creation, therefore this approach requires much more costs including both of time and memories than theother detection techniques. However, this technique can detect code clones withadditions/deletions/changes in statements or code clones including some differences that have no impact on the behavior of program. This is because graph-based
techniques can consider the meanings of program.
Figure 2.4 shows one of the code clones that include some differences that haveno impact on the behavior of programs. Other techniques cannot detect these twocode fragments as a code clone because there is a different order of statements.
One of the leading graph-based clone detection methods is the one proposedby Komondoor and Horwitz [81]. Their method detects isomorphic subgraphsof PDGs with program slicing. Krinke’s method [86], and Higo et al.’s method[42, 139] are also included in graph-based techniques. Each detection method is
optimized to reduce detection cost. Krinke sets a limit of search ranges of PDGs
19

with a threshold. By contrast, Higo et al. confine nodes to be bases of subgraphswith some conditions. Moreover, Higo et al. use execution dependence, whichenables detecting code clones that other graph-based methods could not detect.
2.4.6 Other Detection Techniques
One of the detection techniques that can be categorized into this category isa metrics-based approach. First, metrics-based detectors calculate metrics on every program module (such as files, classes, or methods), then detect code clones bycomparing the coincidence or the similarity of these values. CLAN is a clone detector categorized into the metrics-based approach [109]. CLAN finds duplications bycomparing metrics obtained from ASTs created from source code. Kontogiannis
et al. developed another metrics-based detector [82], which uses ASTs to calculations of metric values as well as CLAN. Ottenstein proposed an approach to detect
plagiarisms of source code with metrics [126]. Lanubile and Mallard developed ametrics-based approach to find functional clones in web applications [91]. Kodhai
et al. combined metrics-based approach and texual comparison of source code to
detect Type-1 and Type-2 functional clones [79].
Beside this, there are some file-based detection methods [125, 138]. This detection technique detects code clones by comparing every file instead of statements
or tokens, which let it be one of the most scalable approach to detect clones. However, this technique cannot find code clones that exist in a part of a file. In addition,
there exists method-based techniques that are more fine-grained compared with
file-based techniques [56]. Although these techniques are inferior to file-based
ones in the point of detection speed, they can detect code clones that file-based
techniques miss.
Moreover, incremental detection techniques are under intense studies [36, 47,
51, 120]. The incremental clone detection keeps results of clone detection in previous revisions and their intermediate products, and it uses them in the next detectionof code clones. Reusing results and intermediate products of analyses on previous
revisions can reduce cost of the clone detection on the current revision substantially.
There exists some techniques not classified into the above categories. The followings briefly describe them. NICAD is able to detect Type-3 clones on the levelsof methods or blocks by using pretty printing and an algorithm to detect longest
common subsequences [122, 132]. Basit and Jarzabek proposed a technique todetect higher-level clones than code fragments, which means structual clone detection [11, 12]. Murakami et al. developed a clone detector named FRISC, whichuses hash sequences created from statements to detect code clones [116]. FRISC
holds repeated instructions as a pre-processing of clone detetion to eliminate false
20

positives and detect clones that other detectors cannot detect. Murakami et al. also
developed another detector that is also based on comparison of hash sequences,which is named CDSW. [117] CDSW uses a well-known algorithm, the SmithWaterman algorithm [141], that finds similar alignments between two sequences.
They optimized the Smith-Waterman algorithm for the purpose of clone detection. Li and Thompson combined tokens and ASTs to detect and remove code
clones [96]. Maeda proposed a technique for clone detection using PALEX [105].
PALEX is a representation of source code that contains recorded parsing actions
and lexical formatting information, and using it enables his technique to be language independent.
2.4.7 Comparison and Evaluation of Clone Detectors
Comparing and evaluating clone detectors plays an important role to identify
an efficient clone detector. However, lacking generic or strict definitions of code
clones makes it challenging to compare and to evaluate clone detectors. Furthermore, suitable detectors should vary with individual purposes or individual users.
Therefore, it is impossible to decide what is the best detector among all the clone
detectors.
There are some empirical studies for comparison and evaluation of clone detectors [16, 20, 30, 85, 133, 134, 144]. Rattan et al. reported some general remarks
among the above studies through their systematic review as follows [129].
• Token-based detectors have high recall and reasonable precision because
they detect a large number of clones.
• Tree-based detectors detect less number of clones than token-based detectors, which results high precision and low recall compared to token-based
detectors.
• Metrics-based detectors have good precision but low recall because less number of clone candidates are detected.
• Graph-based tools is robust for Type-3 clone detection, but they suffer fromhigh time complexity.

2.5

RemovalClone removal is also an active research area as well as clone detection, andso many researchers proposed techniques to remove clones from source code [48].
Basically, clone removal stands on refactoring. Refactoring means changing the21internal structures of software systems without changing their external behavior.
Because clone removal must not change the behavior of its target software, it canbe said that clone removal is a kind of refactoring.
First, this section describes what is refactoring, and then refers how to remove
clones, and finally introduces research achievements on clone removal after that.
2.5.1 Refactoring
Definition
Refactoring is one of the frequently performed activities in the maintenancephase. Fowler, a pioneer of refactoring, defined refactoring as “the process ofchanging a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure” [32]. It has been reported
that the maintainability of software systems decays over time [29]. A set of suitable refactorings could be beneficial to prevent decays of software maintainability.
However, applying refactorings requires much effort for software maintainers, and
it is quite difficult for maintainers to apply refactorings manually without introducing any human errors because of the difficulty of applying refactorings [118].
Because of these factors, techniques to assist refactoring activities are required.
This fact makes refactoring as one of the hot topics in the research area of software
engineering [111].
Process
The refactoring process consists of several activities as follows [111]:
1. Identify places that should be refactored,
2. Determine which refactroing(s) should be applied to the places,
3. Guarantee that the behavior of the program is preserved by the selected refactoring(s),4. Apply the refactoring(s),5. Assess the effect of the refactoring(s) on quality of the software or the process and
6. Maintain the consistency between the refactored program and other software
artifacts (e.g. documentation, design documents, requirements specification,
tests).
22

Each of these activities can be supported by different tools, techniques or formalisms.
Behavior Preservation
Refactoring must not change the behavior of program accoring to its definition.
The original definition of behavior preservation is suggested by Opdyke [124].
The definition states that, for the same set of input values, the resulting set of output values should be the same before and after the refactoring. However, requiring
the preservation of input-output behavior is insufficient, since many other aspectsof the behavior may be relevant as well. For example, in the case of real-time
software, an essential aspect of the behavior is the execution time of certain operations. Thus, refactoring must preserve all the kinds of temporal constraints. For
embedded software, memory constraints and power consumption are also important aspects.
Another pragmatic way to guarantee the behavior preservation is using test
suites. This means that if all the test suites are passed before and after refactorings,
it is regarded that the refactorings do not affect the behavior of the program. If
sufficient test suites are prepared, the fact that all the test suites still pass after the
refactorings will be a good evidence that the behavior of the program is preserved.
Another approach is to formally prove that refactorings preserve the full program semantics. The bahavior preservation can be formally proved if a languagewith a simple and formally defined semantics is used in the target software systems. However, it is difficult to prove the behavior preservation for more complex
languages such as C++.
2.5.2 Refactoring Patterns Used for Code Clone Removals
This subsection describes refactoring patterns that can be used for clone removal, all of which were proposed by Fowler [32, 44].
Extract Class/SuperClass
Extract Class indicates extracting a part of a class as a new class. If there isa large and/or complex class, the class requires much costs for its maintainance.
Extract Class is useful in such a case. If there is a class-level duplication, Extract Class will remove code clones included in the duplicated classes. Figure 2.5
shows an example of refactoring with Extract Class. In this case, there are duplicate fields officeAreaCode and officeNumber, and duplicate operation
about them. By applying Extract Class to this example, duplicate fields and duplicate operation are extracted as a new class TelephoneNumber, and the classes
23Person

PersonnameofficeAreaCode
OfficeNumber

namegetTelephoneNumber()

getTelephoneNumber()Company

Company

address
officeAreaCode
OfficeNumber

address

getTelephoneNumber()

getTelephoneNumber()

1

1

1

1

TelephoneNumber
areaCode
numbergetTelephoneNumber()Figure 2.5: An Example of Extract Class
Department

Party

getTotalAnnualCost()
getName()getHeadCount()

getTotalAnnualCost()
getName()getHeadCount()

Employee
getAnnualCost()
getName()getId()

Department
getAnnualCost()
getHeadCount()

Employee
getAnnualCost()
getId()

Figure 2.6: An Example of Extract SuperClass

Person and Company uses the class. By this modification, the duplicate code isremoved from the two classes.
If duplicate classes do not extend different base classes, Extract SuperClass
may be a better solution for clone removal. Extract SuperClass is similar to Extract Class. The difference is that Extract SuperClass uses inheritance; meanwhile Extract Class uses delegation. In Extract SuperClass, duplications between two (or more) classes are extracted as a new class and all the original classes
are changed to extend the new class. Figure 2.6 shows an example of the application of Extract SuperClass. In this example, a new class Party is created byextracting the duplication of two classes Department and Emproyee, then thetwo classes are changed to extend the class Party.
24

void printTaxi(int amount) {String name = getTaxiName();void printTaxi(int amount) {String name = getTaxiName();print(name, amount);}

System.out.println(“name: “ + name);
System.out.println(“amount: “ + amount);}

void printBus(int amount) {String name = getBusName();print(name, amount);}

void printBus(int amount) {String name = getBusName();
System.out.println(“name: “ + name);
System.out.println(“amount: “ + amount);

void print(String name, int amount) {System.out.println(“name: “ + name);
System.out.println(“amount: “ + amount);}}

Figure 2.7: An Example of Extract Method
Extract Method
Extract Method indicates extracting a part of a method as a new method. This
refactoring pattern is often used for improving reusability by segmentalizing toolong and/or too complex methods into short and simple methods. Extract Method
can remove code clones by extracting them as a new method and replace them bymethod call instructions for the method. Figure 2.7 shows an example of clone
removal with the application of Extract Method. In this example, there are thesame statements between two methods printTaxi and printBus. By applying
Extract Method, these duplicate statements are extracted as a new method print,
and the original statements are replaced by the method call. As a result, code clones
between the two methods are merged into a single method. An advantage of thispattern as clone removal technique is that it can be applied if a part of a method
contain code clones and the other part does not contain code clones. In addition,
this pattern is capable of wide applications because it does not use class hierarchies.
Therefore, this pattern is useful in such a case that versatile processes, which canbe merged as a library, are scattered across source code as code clones. However,this pattern introduces many methods if multiple cloned fragments exist in a single
method and there are some non-cloned fragments between every two fragments.
Pull Up Method
Pull Up Method indicates pulling up identical methods existing in derived
classes into their common base class as a new method. This pattern is effective
if there are some methods that behave the same way in all the derived classes.
By applying this pattern, duplicate methods are merged into a base class, which
25

Employee

Employee
getName()SalesmanEngineer

getName()SalesmanEngineer

getName()Figure 2.8: An Example of Pull Up Method

Employee

Employee

fivePercentRaise()raise(percentage)

tenPercentRaise()

Figure 2.9: An Example of Parameterize Methodmeans that code clones existing in derived classes are removed. Figure 2.8 shows
an example of the application of Pull Up Method. In this case, two duplicate
methods getName in class Salesman and Engineer are pulled up into thesame base class Employee. This pattern can be applied if and only if target
methods are exactly the same. Moreover, this pattern uses inheritance relationships
among classes. Therefore, the range of application of this pattern is narrower thanthat of Extract Method refactoring pattern.

Parameterize Method
If there are similar methods in a single class, the duplication may be removed
by Parameterize Method. Parameterize Method is used in a case that several methods do similar things but with different values contained in the method
body. In this pattern, a new method that uses a parameter for different values
is created. Figure 2.9 shows an example of Parameterize Method refactoring.
The class Employee before refactored in this example has two similar methods, named fivePercentRaise and tenPercentRaise. A Parameterize
Method refactoring creates a new method that uses a parameter for different values
between the two methods, which removes clones between them.
26

Pull Up Constructor
This pattern is very similar to the Pull Up Mehtod. The only difference is thetarget of this pattern is not a method but a constructor.
Replace Method with Method Object
This pattern is a hybrid of Extract Class and Extract Method refactoring
patterns. This pattern is used in the case that there exists long and similar methods
that use local variables, which make it difficult to extract these methods by Extract
Method refactoring pattern. This patten applies Extract Class refactoring pattern
to such methods. Extract Class replaces local variables into fileds of the extractedclass, and so Extract Method can be applied easily after Extract Class refactoring
is applied.
Form Template Method
Form Template Method refactroing pattern is a hybrid of Extract Method
and Pull Up Method refactoring patterns. This pattern targets similar methods
existing in derived classes that have a same base class. In this pattern, processes
that are common in all the target methods are pulled up into the base class with
Pull Up Method refactoring pattern. On the other hand, the processes that are
not common in the target methods remain in each derived class. The remaining
processes are unique in each derived classes. These unique processes are extracted
as a new method with Extract Method refactoring pattern.
The steps for applying Form Template Method are as follows:
1. Detect common processes in all the target methods,
2. Extract unique processes as new methods with Extract Method refactoring
pattern,
3. Rename methods to make correspondence of signatures. The targets of renaming are methods that created in 2. and called in the same point of thecommon processes and4. Pull up common processes as a new method in the base class with Pull Up
Method refactoring pattern.
Figure 2.10 shows an example of refactorings with this pattern. There are twoclasses that have the same base class, Site, and these two classes have the methods that are similar to each other, getBillableAmount.
27

Site

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

ResidentialSite

LifelineSite

getBillableAmount()

getBillableAmount()

double base = method1();
double tax = method2();
return base + tax;

Site

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

double base = method3();
double tax = method4();
return base + tax;

return units * rate;

ResidentialSite

LifelineSite

getBillableAmount()
method1()
method2()

getBillableAmount()
method3()
return units * rate * 0.2;
method4()

return base * Site.Rate;(a) before refactoring
Site

ResidentialSite
getBillableAmount()
getBase()getTax()(b) after step1 and step2

double base = getBase();double tax = getTax();
return base + tax;

Site
getBillableAmount()
getBase()getTax()

double base = getBase();double tax = getTax();
return base + tax;

return units * rate;

double base = getBase();double tax = getTax();
return base + tax;

return units * rate;

LifelineSite

ResidentialSite

getBillableAmount()
getBase()return units * rate * 0.2;
getTax()return base * Site.Rate;

return base * Site.Rate * 0.5;

getBase()getTax()return base * Site.Rate * 0.5;

LifelineSite
getBase()getTax()return base * Site.Rate;(c) after step3

return units * rate * 0.2;

return base * Site.Rate * 0.5;(d) after refactored

Figure 2.10: An Example of Refactorings with Form Template Method

To apply Form Template Method to this target, at first, it is necessary to
distinguish the common and unique processes in the two methods. In this example,
the differences of the two methods are in the calculation ways of variables baseand tax.
The next step extracts each of the calculations of base and tax as new methods (shown in Figure 2.10(b)), which results in four methods (currently, they are
named as method1, method2, method3, and method4).
In the next step, the four new methods are renamed to make correspondence of
signatures (shown in Figure 2.10(c)). In this example, method1 in ResidentialSite
and method3 in LifelineSite are called as the first processing of the original
methods. Also, method2 and method4 are called as the second processing of
the original methods. Therefore, method1 and method3 are renamed to maketheir signatures correspondent. In this example, method1 and method3 are renamed as getBaseAmount. Similary, method2 and method4 are renamed as
getTaxAmount.
Finally, the common processes are pulled up as a new method in the base class
Site. Note that this step defines getBaseAmount and getTaxAmount as abstract methods in the base class. Figure 2.10(d) shows the code after the refactoring28

has finished.
By applying this refactoring pattern to similar methods, code clones existing
between these methods are merged into a base class. An advantage of clone removal with this pattern compared with Pull Up Method is that this pattern canbe more widely used than Pull Up Method because this pattern can be applied tomethods that are not exactly the same. Compared with clone removal with Extract Method refactoring pattern, the application range of this pattern is narrower.
However, this pattern is effective in such a case that common processes are segmentalized by unique processes. This is because separated common processes canbe merged as a single method with Form Template Method refactoring pattern,meanwhile each fragment of common processes is extracted as a method with Extract Method refactoring pattern.
The rest of this dissertation calls a method created in base classes by pullingup the common processes template method.
2.5.3 Research on Clone Removal
Fowler, a pioneer in the field of refactoring, mentioned that “the number one in
the stink parade is duplicate code” [32]. He also presented some sets of operations
for merging code clones. However, because it is quite difficult for maintainers toapply refactorings manually without introducing any human errors, much research
effort has been performed on refactoring assistance [111].
Choi et al. found from open source software systems that most of refactorings applied to code clones are either Extract Method or Replace Method with
Method Object [22].
Higo et al. proposed a method for merging code clones [44]. Their method consists of two phases. The first phase is quick detection of refactoring-oriented code
clones from source code. The second phase is measurement of metrics indicating
how the refactoring-oriented code clones should be merged. They implemented
their method as a tool named ARIES. Using ARIES in the refactoring process, maintainers of software systems can readily know which and how code clones can bemerged. They conducted a case study with ARIES, and they confirmed that ARIES
performs the process successfully.
CloneDR, which is an implementation of the AST-based technique of clone detection, offers not only the locations of code clones but also forms of merged codefragments [15]. The forms help users understand what operations are required tomerge code clones. However, the tool does not care about the positional relationship between code clones in the class hierarchy.
Bakazinska et al. proposed a refactoring technique for duplicate methods [9].
Their technique provides the differences between code clones, which help users
29

to determine whether code clones can be merged or not. Also, their techniquemeasures the coupling between a duplicated method and its surrounding code. In
their method, code clones are removed by using two design pattern Strategy andTemplate Method.
Cottrell et al. implemented a tool that visualizes the detailed correspondences
between a pair of classes [24]. The classes are generalized to form an intermediate,
AST-like structure that distinguishes between what is common and what is specificto each class. The specific instructions will influence the degree of relatively between the classes. The tool works after users identify two classes that should bemerged.
Komondoor et al. proposed an algorithm for procedure extraction [80]. The
inputs to the algorithm are the CFG (control-flow graph) of a procedure and aset of nodes in the CFG. The goal of the algorithm is to revise the CFG with thefollowing conditions:• The set of nodes that are extractable from the revised CFG;
• The revised CFG is semantically equivalent to the original CFG.
The implementation of this algorithm adopts heuristics for enhancing scalability. Although the algorithm has a worst-case exponential time complexity, theirexperimental results indicated that it may work well in practice. However, the algorithm can be applied only to a single clone pair. Different techniques are needed
to determine how two or more code clones can be extracted as a single procedure
with preserving semantics.
The majority of clone removal techniques is based on Extract Method or PullUp Method refactorings, and there are few techniques based on Form Template
Method refactoring.
Juillerat et al. proposed a method to automatically apply Form Template
Method to a pair of similar methods with ASTs [66]. Their method can show
source code after the application of the pattern, and the execution time and memory space required to the calculation are not so high.
Masai et al. proposed a method to support refactorings with Form Template
Method with ASTs likewise Juillerate et al. [107]. Their method considers the
structural information of ASTs to detect unique processing, meanwhile Juillerat etal. compare ASTs with token sequences that are made from ASTs. Also, they implemented a function to suggest suitable divisions between common- and differentparts on the specified method pair to users with a cohesion metric COB [37, 55].
Although many reseachers have spent their effort on research of clone removal,
as described in 2.2.2, it cannot be said that all the clones are “bad smells” for30software maintenance. In addition, clone removal has been countered by somereseachers [77, 78]. The bases of such counter opinions are as follows.
• Many code clones live in a short time.
• Most of code clones that live in a long time cannot be easily refactored.
Hence, it is important before removing clones to select targets of removal carefully, with pros and cons of it (including benefits that the removal will offer, costs
that the removal will require, and risks that the removal might bring) being considered.

2.6 Prevention
As 2.2.1 described, code cloning by copy-and-paste operations should resultin creation of code clones. Although clones created by the operations may affectsoftware maintenance adversely, it has a big advantage that is hard to be abandoned.
That is to say, it can rapidly provide functions that are similar to the existing ones.
Almost all of recent software development has a strictly-limited time and resources,
which forms a hotbed of cloning. In addition, cloning is sometimes unavoidable
because of technical or organizational limitations [163].
However, it is quite obvious that unlimited cloning wreaks enormous damage
on software evolution because of a large amount of negative clones. Hence, it isimportant for effective software evolutaion to prohibit creating negative clones andto allow creating only positive ones.
Laguë et al. proposed a strategy of clone prevention named “Preventive Control” [90]. It allows code cloning only when the cloning has a valid reason. Whendevelopers want to clone any code fragment, preventive control forces them to explain the reason of the cloning that they want to do. In the case that the explained
reason is regarded as valid, developers can perform the cloning. If it is not the case,the cloning will be rejected. Therefore, preventive control can prevent introducing
negative clones in software systems.
Another way of clone prevention stands on watching behavior of developers on
IDEs. Venkatasubramanyam et al. proposed a framework to observe developers’
behavior to prevent clone creation [148]. When developers are just about to clone
any code, the framework checks whether the cloning satisfies constraints that all thecloning is imposed. If the cloning violates any constraints, the framework rejects
the cloning. A big feature of this framework is that its users can define the constraints of cloning as they like. Venkatasubramanyam et al. provided an instance ofconstraints that “Do not clone code fragments whose cyclomatic complexity [110]values are larger than or equal to five”.
31Furthermore, there exists a techique to predict harmfulness of clones that are
created by copy-and-paste operations at the point of these operations, which was
proposed by Wang et al. [151]. They regarded code cloning as harmful if clones
created by it need any consistent modifications in the future. On the other hand,code cloning is regarded as not harmful in the case that clones created by thecloning no longer need any modifications, or they do not need any consistentmodifications. Their prediction uses 21 metrics that are collected based on features or locations of code. They predicted harmfulness of clones with Bayesian
Networks [127], a well-known machine learning technique, and collected metrics.
This technique can be used in the following two strategies.
• Prohibiting cloning that is predicted to produce any harmful clones.
• Allowing cloning only if it is predicted to produce non-harmful clones only.
Wang et al. evaluated their technique on both of the two strategies with commercial software products of Microsoft, and they stated that their technique isenough effective on both of the two strategies.

2.7 Analytic Methodology
As described in 2.4, much effort has been spent on clone detection, which
produces a variety of clone detectors. Coupled with advanced hardware, clone
detectors are now substainable for use on very large scale software in industry.
Of course, detecting clones is not enough to promote effective software evolution. Clone detectors come into their own when their outputs are used in someway. A particular way to make use of detected clones is to analyze them. However,clone detectors tend to report a long list of clones from a large scale software system. Hence, it becomes a challenging task for developers or maintainers of large
scale software systems to treat such a large amount of clones [63]. This indicatesthat there is a strong demand for techniques to analyze a large amount of clones
effectively.
This section introduces some techniques that can respond to such a request.
2.7.1 Filtering and Categorizing
One way to promote efficient analysis of clones is to reduce the amount ofclones by filtering out uninteresting clones. Similarly, categorizing or clustering
clones should allow developers or maintainers to analyze clones in a shorter timeframe. Table 2.1 summalizes these techniques.
32

Table 2.1: Overview of Methods for Filtering/Categorizing/Clustering Clones
Proposed by
Basis
Overview
Jiang et al. [63]Specified by users
Omitting clones not satisfying
specified conditions
Yang et al. [158, 159] Machine learning with Learning useful clones speciTF-IDF
fied by individual user
Zhang et al. [164]Specified as the SQL Getting clones that satisfy conformat
ditions specified with the SQL
formatTairas & Gray [142]Latent semantic analy- Clustering clones sharing manysis based on identifier identifiers having the samenames
names into the same cluster.
Kapser & Godfrey [73] Locations of clones
Categorizing clones with theirlocations such as Same File,
Same Dir, Different File.
Merlo & Lavoie [112] Owner blocks of clones
Categorizing
cloneslikemethod-method, block-block,or method-block.
Balazinska et al. [10]Comparison of meth- Categorizing clones into 18
ods shairing cloned types based on differences offragments
methods.
Xing et al. [156]Comparison of PDGs
Categorizing clones into 7
types based on differences of
PDGs
Kamiya [69]Configurations such as Classifying clones based on
Makefiles
configuration information suchas appearing in a configuration, but not in another configuration
Kamiya [70]Caller-callee relation- Classifying cloned functions
ships
that call the same funciton ascontent clone, and those thatare called by the same function
as context clone.

33

Jiang et al. proposed a filtering technique for code clones based on data mining
techniques [63]. This filtering ommits “uninteresting” clones from the results ofclone detectors. Their method allows its users to decide criterion of “interesting”
clones because it strongly depends on the purpose of clone analysis or the analyzers’ notions whether a code clone is “interesting” or “uninteresting”. In otherwords, a code clone can be “interesting” even though it is “uninteresting” in another situation or for another analyzer.
Yang et al. proposed another technique to filter code clones [158,159], which isbased on a machine learning technique. In similar to Jiang et al., Yang et al. standon the basis that usefulness of a code clone should differ in according to situations
or users. To be flexible to such variability of usefulness of clones, they developed a
web-base system named Fica for filtering of clones. Fica internally uses a machinelearning technique to predict whether a given code clone is “interesting” or not in
a particular situation and/or for a particular user. Fica learns judgements of usefulness of clones from training data sets, and predicts whether clones not includedin the training data sets are “interesting” or not. Each user of Fica has her/his own
training data set, thus Fica can be flexible to different notions of different users. In
addition, every user of Fica can have multiple training data sets, which offers Ficaa great frexibility for different usages.
They performed an open survey, with 33 participants contributed. The survey
revealed a high accuracy of Fica’s prediction. Furthermore, it found the following
observations.
• “Uninteresting” clones tend to fall into several categories, thus they are likely
to form clusters.
• “Interesting” clones tend to be unique comparing to uninteresting ones.
• Users having more experience on code clones are more likely to agree witheach other compared to users having less experience. In other words, experts
on code clones share common opinions on interests of clones.
Zhang et al. developed a filtering of clones based on SQL instructions [164].
Their method stores results of a clone detector, named CloneMiner [12], whichallows users to select clones with any SQL instructions. In addition, they have
implemented their method as a plugin of Eclipse, the de-facto standard of IDEs for
Java, which is named CloneVisualizer.
Tairas and Gray proposed a technique to cluster clones based on a latent semantic analysis [142]. This method regards an identifier as a word, thus clones
sharing many identifiers with the same names are clustered into a single group.
34

Figure 2.11: Rieger et al.’s Visualization (Duplication Web) (Cited from the literature [130])
Many categorizations of clones have been proposed in recent years, including
techniques based on locations [73], syntactical information [112], differences [10,156], configurations [69], or caller-callee relationships [70]. These categorizations
will be helpful to assess or understand code clones in software systems.
2.7.2 Visualizing
Software visualization is quite useful to understand software systems [14].
Many researchers successifully have made use of visualization techniques to understand circumstances of code clones.
Rieger et al. applied polymetric views to clone visualization [130]. Polymetricview is a visualization technique that represents mulitple characteristics in a single
view [92]. They proposed six types of clone visualization, one of which is shownin Figure 2.11. Figure 2.11 shows an instance of duplication web. Duplication
web places all the source files as boxes in a concentric fashion, and draws edges
between source files if they share any code clones. The width of each edge represents the amount of shared clones between two source files. This means that there
is a heavy edge between two source files if they share a large amount of clones.
Furthermore, the length of each box indicates the amount of code clones whose elements are included only in the file represented by the box without any exceptions.
Duplication web shows which files share a lot of clones, which will be helpful forsoftware maintainers.
Wattenberg proposed Arc Diagram that visualizes patterns of strings that frequently occur [152]. Figure 2.12 describes an example of an arc diagram. Arc
diagrams can show patterns frequently observed in not only source code but also
other sequences including byte code, DNA arrangements or musical scores.
35

Figure 2.12: An Arc Diagram (Cited from the literature [152])

Figure 2.13: Clone Visualization with Bundle Edge View (Cited from the literature[40])
Hauptmann et al.’s technique uses bundle edge views [40]. Bundle edge viewis a kind of graph visualizing techniques. To reduce the number of edges of graphs,
bundle edge view bundles edges with similar origins and destinations together [49].
Figure 2.13 shows an example of bundle edge views for clone visualization. Eachedge of the graph indicates that two source files connedted by the edge sharesclones. This view shows distribution of clones across the whole of a given softwaresystem in a concise way.
Yoshimura and Mibe proposed a technique to visualize analogous relationships
between source files [162], which is shown in Figure 2.14. Their goal is to explain
how clones distribute for stakeholders who are not experts of software development. This visualization technique can show how many source files share clones
in one glance.
Ueda el al. developed Gemini [147], which is a GUI frontend of CCFinder[72]. Gemini uses scatter plots to look down at distributions of clones. In addition,it has a function to filter out clones with some metrics. It is equipped a graphnamed Metric Graph to support the filtering. Users of Gemini can filter clones in a36

Figure 2.14: Clustered Source Files based on Their Similarities (Cited from theliterature [162])

Figure 2.15: An Exapmle of Scatter Plots Shown by Gemini [147]
intuitive way with the graphs. As another research related to Gemini, Miyazaki etal. proposed a technique to support users of Gemini to decide where they should
start analysis of clones [113].
Adar and Kim have offered a library for clone visualization named SoftGUESS[3]. Their library includes visualizations for clone genealogies, for hierarchicalstructures of clones, and dependencies of clones at the package level.
Recent research has high interests on clone genealogies. As described above,
SoftGUESS can visualize clone genealogies. Another technique to visualize clone
genealogies is proposed by Saha et al., which uses scatter plots [136].
37

2.8 Detection and Prevention of Clone Related Bugs
The presence of code clones can be a cause of bug spreadings. That is to say, if
a bug hides in one of cloned fragments, its correspondents have high probabilities
that they also have the same bug. Hence, developers or maintainers may neglect
to fix all the cloned fragments in a clone set if they are unaware of the presenceof the clone. Moreover, it is quite natural that similar bugs will be exposed insimilar situations. This means that, if a bug in a system was fixed and the fixed bug
was one of clone related bugs, the system should still fail to work in the similar
situations that the fixed bug occured. In this case, users of the system will thinkthat “the bug has not been fixed even though the provider of the system said the
bug was already fixed”. They might even say that “the provider and the developers
have low technical capabilities because they could not fix a bug”. Therefore, clone
related bugs may force providers, developers or maintainers of software systems tolose their users’ trust.
Unfortunately, it is sometimes not enough for finding clone related bugs to runclone detectors, specifically in large scale software systems. Many researchers havespent great effort to detect clone related bugs efficiently from large scale softwaresystems for this reason. This section simply describes their achievements.
2.8.1 Preventing Clone Related Bugs
There is a variety of approaches to prevent introducing clone related bugs.
The approaches include supporting simultaneous modifications, suggesting cloned
fragments of the code fragments that a developer is about to modify, or finding
oversights of simultaneous modifications.
Toomim et al. proposed a technique to support simultaneous modifications onclones, which is named “Linked Editing” [145]. Users of linked editing prescribe
it to link two code fragments as the first step of use. Once links of two code fragments are specified, modifications applied on a code fragment will be automaticallyapplied to the other code fragment. If users do not want to apply a modification
simultaneously to the other fragment, they can flexibly avoid the automatic modification. Another technique to encourage simultaneous modifications on clones
is the one proposed by Higo et al. [46]. Their technique detects cloned fragmentsthat have clone relationships between the user-specified fragment and shows themto users. Unlike linked editing, Higo et al.’s technique requires only a single codefragment to be specified, because it automatically detects clones with a code clone
detector.
Other techniques monitor developers’ copy-and-paste operations to preventclone related bugs. They automatically record links between the original and the38

destination fragments, and support simultaneous modifications on them [50,57,58,
155]. Another technique achieves prevension of introducing clone related bugs byshowing code clone information as comments [137].
There are some systems available to prevent clone related bugs. One of themis JSync, which is proposed by Nguyen et al. [119]. JSync automatically detects
uninconsistent changes on clones and alerts its users. In addition to that, JSync has
a function to suggest how to fix the uninconsistent changes.
Duala-Ekoko and Robillard developed another clone management system, which
informs users of modifications applied on clones [27]. It tells the locations ofcloned fragments that have clone relationships to the code fragment that users are
modifying.
The system proposed by Yamanaka et al. reports how clones are modified
across version histories [157]. Their method informs users of additions, deletions,or changes on clones, which prevents unawareness of them. They evaluated theeffectiveness of their method on an experimental web system developed in NEC
Corporation.
2.8.2 Detecting Clone Related Bugs
Many techniques have been proposed to detect clone related bugs. It is said thatmost of clone related bugs are introduced by unintended inconsistencies on clones.
Hence, most of these techniques find and use inconsistencies of cloned fragments
in code clones to detect bugs. Inconsistencies used to detect clone related bugs
have a wide variety, including identifier names [53, 98], and control structures ofowners of clones [62]. In addition, there is a technique for detecting clone relatedbugs that uses differences of results of multiple clone detectors [45].
Li and Ernst developed CBCD, which suggests code fragments having a highpossibility to have a clone related bug [97]. CBCD is used when its users find abug. CBCD takes the code fragment having the found bug as its input, and detects
code fragments that are suspected to have similar bugs.
There exists some other ways that are similar to CBCD, including using information about identifiers [160, 161] or targetting concurrent processing [59].
Lucia et al. stated that bug detection tools for clones tend to report many false
positives, and proposed a technique that eliminates such false positives from theresults of the tools [104]. Their method refines clone anomaly reports to achieve
the objective. Using thier method after clone related bug detection enables to findclone related bugs more efficiently. In similar to Lucia et al,’s technique, Hayase etal. proposed a filtering for CP-Miner to eliminate false positives [41].
In addition, there are some techniques that combine fault-prone module prediction with code clones [6, 68].
39

Some configuration management systems have been proposed for code clones
in recent years [39, 121]. It is difficult to detect clone related bugs only with thecode of the latest revision of the target software system if many modifications wereadded after copy-and-paste operation. This is because the origin and the destinationof the cloning are no longer detected as clones because of gaps between them.
Clone-aware configuration management systems will resolve such issues because
they are able to provide historical information of the clones. In addition, they haveanother advantage than clone related bug detection. As Hata et al. have stated in
the literature [39], using clone-aware configuration management systems allows
us to gain rich data about clones including process related information or human
attributes. That is, by using clone-aware configuration management systems, we
can apply techniques of repository mining, which is one of the most hot topics inthe research area of software engineering, to histories of code clones.

40

Chapter 3

An Empirical Study on Influences
for Clones on Software Evolution
3.1 Background
It was generally believed that code clones negatively affect software evolution.
However, some researchers doubted the accepted notion, and conducted empiricalstudies to reveal whether it is really true.
In order to answer the question whether code clones are harmful or not, they
compare characteristics of cloned code and non-cloned code instead of directly
investigating maintenance costs that they require. This is because measuring theactual maintenance costs is quite difficult. The experimenal results are split: someof them supported the accepted notion and claimed that code clones are harmful forsoftware evolution [100, 101, 115], and others argued that code clones do not haveseriously negative impacts [34, 35, 78, 88, 89, 103, 128]. There even exists opinions
that code cloning is a good choice for design of the source code [74].
Such a variation of opinions on harmfulness of clones may imply that many ofclones are not harmful, however, there still exists some instances having negative
impacts on software maintenance. This fact indicates that managing all of clones
carefully is not only effort-consuming but also uneffective. In other words, we thus
have to carefully select the clones to be managed to avoid unnecessary effort managing clones with no risk potential [35]. To achieve such a challenging objective,
it is necessary to know the characteristics that harmful clones have.
In this study, we conduct an empirical study that compares cloned code to
non-cloned code from a different standpoint of previous research, and reports theexperimental result on open source software. The features of the investigation inthis study are as follows:41• every line of code is investigated whether it is cloned code or not. Sucha fine-grained investigation enables an accurately judge on whether every
modification conducted to cloned code or to non-cloned code;• maintenance cost consists of not only source code modifications but also
several phases prior to it. In order to estimate maintenance cost more appropriately, this study defines and uses a new indicator that is not based on
modified lines of code but the number of modified places;• we evaluate and compare modifications of cloned code and non-cloned codeon multiple open source software systems with multiple clone detectors.
That is because every clone detector detects different code clones from thesame source code.
We also conducted a comparison experiment with two investigation methods
previously proposed by other researchers. The purpose of this experiment is to reveal whether comparisons between cloned code and non-cloned code with different
methods yield the same result or not. In addition, we carefully analyzed the resultsin the cases that the comparison results were different from each method to reveal
the causes behind the differences.

3.2 Motivation
3.2.1 Motivating Example
As described in Chapter 2, much research effort has been performed on evaluating the influence of code clones. However, these investigation methods still havesome points that they did not evaluate. This subsection explains these points withthe example shown in Figure 3.1. In this example, there are two similar methods
and some places are modified, with the modified places classified into four parts,
modification A, B, C, and D.
Investigated Units
In some studies, large units (e.g. files or methods) are used as their investigation units. In those investigation methods, it is assumed that code clones havea negative impact if files or methods having a certain amount of code clones are
modified, which can cause a problem. The problem is the incorrectness of modifications count. For example, if modifications are performed on a method which hasa certain amount of code clones, all the modifications are assumed as performedon the cloned code even if they are actually performed on non-cloned code of the42

Revision R
public void highlight(Graph target) {if (target.isEmpty()) {return;}Set<Node> nodes = target.getNodes();
Set<Node> uninterestNodes =new HashSet<Node>();for (Node node : target.getNodes()) {if (node.getEdges().isEmpty()) {uninterestNodes.add(node);}}
nodes.removeAll(uninterestNodes);public void highlight(Graph target) {if (target.isEmpty()) {return;}Set<Node> nodes = target.getNodes();
Set<Node> uninterestNodes =new HashSet<Node>();for (Node node : target.getNodes()) {if (node.getEdges().isEmpty()) {uninterestNodes.add(node);}}
nodes.removeAll(uninterestNodes);System.out.println(“Processing Nodes");for (Node node : uninterestNodes) {drawLineThrough (node);}for (Node node : nodes) {addHighlight(node, Color.red);}for (Node node : nodes) {addHighlight(node, Color.red);}}code clones detectedby both CCFinder & Scorpio
code clones detectedby only Scorpio}

Revision R+1
public void highlight(Graph target) {public void highlight(Graph target) {if (target == null || target.isEmpty()) {if (target == null || target.isEmpty()) {return;return;modification A }}Set<Node> nodes = target.getNodes();
Set<Node> nodes = target.getNodes();
Set<Node> uninterestNodes =new HashSet<Node>();for (Node node : target.getNodes()) {if (node.getEdges().isEmpty()) {modification B
uninterestNodes.add(node);}}
nodes.removeAll(uninterestNodes);System.out.println(“Processing Nodes");for (Node node : uninterestNodes) {paint (node, getPaintColor());}
for (Node node : nodes) {addHighlight(node, getColor());}

modification C
for (Node node : nodes) {addHighlight(node, getColor());}}

modification D}

Figure 3.1: Motivating Example of Our Empirical Study43

method. Modification C in Figure 3.1 is an instance that suffers from this problem.
This modification is performed on non-cloned code, nevertheless method or file
based investigations regard that this modification is performed on cloned code.

Line-based Barometers
Some other studies used line-based barometers to measure the influence of code
clones on software evolution. Herein, the line-based barometer indicates a barometer calculated with the amount of added/changed/deleted lines of code. However,line-based barometer cannot distinguish the following two cases: the first case isthat consecutive 10 lines of code were modified for fixing a single bug; the secondcase is that 1 line modification was performed on different 10 places of code forfixing 10 different bugs. In real software maintenance, the latter should require
much more costs than the former because software maintainers have to conduct
several steps before actual modifications on source code such as identifying buggy
modules, identifying buggy instructions and so on.
In Figure 3.2.2, Modification A is a single line modification, and performedon two places, meanwhile Modification B is a modification including seven consecutive lines on a single place. With line-based barometers, it is regarded that
Modification B has the impact 3.5 times larger than Modification A. However, thisis not true because software maintainers have to identify two places of code for
Modification A meanwhile a single place need to be identified for Modification B.

A Single Clone Detector
Each of the previous studies used a single clone detector to detect code clones
in target software systems. However, as discussed in Chapter 2, there is neither
a generic nor strict definition of code clones. Each detector has its own uniquedefinition of code clone, and it detects code clones based on the own definition.
Consequently, different code clones are detected by different detection tools fromthe same source code. Therefore, the investigation result with one detector is different from the one from another detector. Figure 3.1 shows the differences ofdetected clones between a detector CCFinder and another detector Scorpio. Consequently, if we use Scorpio, Modification D is regarded as being affected withcode clone, nevertheless it is regarded as not being affected with code clone if we
use CCFinder. Therefore, the investigation with a single detector is not sufficientto get a generic result about the impact of code clones on software evolution.
44

3.2.2 Objective of this Study
This study stands on a different point from previous research. The features ofthis study are as follows:
Fine-grained Investigation Units: In this study, every line of code is investigated whether it is included in any code clones or not, which offers us withmore accurate judgements on whether every modification is conducted oncloned code or non-cloned code.
Place-based Indicator: This study uses a new indicator based on the number ofmodified places, not the number of modified lines. The purpose of using
such a place-based indicator is to evaluate the impact of the presence ofcloned code with different standpoints from the previous research.
Multiple Detectors: This study uses four clone detectors to reduce biases of eachdetector.

3.3 Terms
This section describes clone detectors used in this study, and then explainssome terms to which the remainder of this study refers.
3.3.1 Clone Detectors Used in This Research
CCFinderCCFinder is one of the famous token-based clone detectors developed by Kamiya
et al. [72]. The major features of CCFinder are as follows:• CCFinder replaces user-defined identifiers such as variable names or function names with special tokens before the matching process. Consequently,
CCFinder can identify code fragments that use different variables as code
clones.
• Detection speed is very fast. CCFinder can detect code clones from millions
lines of code within an hour.
• CCFinder can handle multiple popular programming languages including
C/C++, Java, and COBOL.
45

CCFinderX
CCFinderX is a major version up from CCFinder [21]. CCFinderX is a tokenbased clone detector as well as CCFinder, but the detection algorithm was changed
to bucket sort from suffix tree. CCFinderX can handle more programming languages than CCFinder. Moreover, it can effectively use resources of multi-core
CPUs, which realizes faster detection.
SimianSimian is a text-based clone detector [140]. As well as the CCFinder family,
Simian can handle multiple programming languages. Its text-based technique realizes clone detection on small memory usage and short running time. Also, Simian
allows fine-grained settings to its users. For example, users can configure to ignore
import statements in the case of Java language.
Scorpio
Scorpio is one of the graph-based clone detectors developed by Higo et al. [42].
Currently, Scorpio can handle software systems written in Java. The major featuresof Scorpio are as follows.
Detecting code clones with different user-defined variables: Scorpio replaces userdefined identifiers by special characters. Therefore, it can detect code clones
having different user-defined variables.
Detecting Type-3 code clones and non-contiguous code clones: Scorpio can detect Type-3 code clones and non-contiguous code clones because it is a PDGbased clone detector.
Robustness for detecting contiguous code clones: One of the disadvantages of
PDG-based clone detectors is that they cannot regard sequences of program
elements as code clones if every element in the sequences has no dependence
between other elements in the sequences. To improve this matter, Scorpio
introduces execute dependence, which enables it to expand the range of program slicing, so that the ability to detect contiguous code clones is improved.
Using both of two graph search algorithms: There are two ways to search graphs,
forward and backward slicing. Scorpio uses both of forward and backward
slicing, which enlarges results of clone detection because there are similar
subgraphs that cannot be detected by using only forward or backward slicing.
46

1: A
2: B
3: will be changed 1
4: will be changed 2
5: C
6: D
7: will be deleted 1
8: will be deleted 2
9: E
10: F
11: G
12: H

(a) before modification

1: A
2: B
3: changed 1
4: changed 2
5: C
6: D
7: E
8: F
9: G
10: added 1
11: added 2
12: H(b) after modification

3,4c3,4< will be changed 1< will be changed 2--> changed 1> changed 2
7,8d6< will be deleted 1< will be deleted 2
11a10,11> added 1> added 2(c) diff output

Figure 3.2: A Simple Example of Comparing Two Source Files with diff

Heuristics for reducing costs of detection: To reduce detection costs, Scorpio
makes a limitation on start points of slicing. Unnecessary slicing points are
identified and removed by this heuristic.

3.3.2 Revision
In this study, it is necessary to analyze historical data of code. Therefore,
this study targets software systems managed by version control systems. Version
control systems store information about snapshots of software products, including
source code and documents, and changes applied to them. Each snapshot is identified by a number, called “revision”. We can get source code in arbitrary revision,
and we can also get modified files, change logs, and the name of developers who
made changes in arbitrary two consecutive revisions with version control systems.
Due to the limit of implementation, we restrict the target version control system
to Subversion. However, it is possible to use other version control systems such as
CVS.

3.3.3 Target RevisionThis study is only interested in changes in source files. Therefore, we findout commits that have some modifications in source files. The remainder of thischapter uses a term target revisions, which indicates revisions that are related toany of such commits. That is, a revision R is regarded as a target revision if at least
one source file is modified from R to R + 1.
47

3.3.4 Modification PlaceThis study uses the number of places of modified code, instead of lines ofmodified code. That is, even if multiple lines are modified, this study regards it asa single modification if the modified lines are consecutive. In order to identify the
number of modifications, this study uses the traditional diff command of UNIX.
Figure 3.2 shows an example of diff output. In this example, we can find threemodification places. One is a change in the third and fourth lines, another is adeletion of the seventh and eighth lines, and the other is an addition of statements
between the 11th line and the 12th line. As shown in Figure 3.2, it is very easy
to identify modified places from diff outputs; all we have to do is just parsing theoutput of diff so that start lines and end lines of all the modifications are identified.

3.4 Proposed Method
This section describes our research questions and the investigation method.
3.4.1 Research Questions and Hypotheses
The purpose of this study is to reveal whether the presence of code clones reallyaffects software evolution or not. This study is under an assumption that if cloned
code is more frequently modified than non-cloned code, the presence of cloned code
has a negative impact on software evolution. The basis of this assumption is that
if much cloned code that is never modified during its lifetime is included in source
code, the presence of cloned code never causes inconsistent changes or additional
maintenance effort. Our research questions are as follows.
RQ1: Is cloned code more frequently modified than non-cloned code?
RQ2: Are the comparison results of stability between cloned code and non-cloned
code different from multiple detection tools?
RQ3: Is cloned code modified uniformly throughout its lifetime?
RQ4: Are there any differences in the comparison results on types of modifications?
To answer these research questions, we define a new indicator, named modification frequency (in short, M F ). We measure and compare M F of cloned code(in short, M Fd ) and M F of non-cloned code (in short, M Fn ) for investigation.
48

3.4.2 Modification Frequency
Definition
As described above, this study uses M F to estimate the influence of code
clones. M F is an indicator based on the number of modified code, not lines ofmodified code.
The following formula (3.1) describes the definition of M Fd .
∑M Cd (r)M Fd =

r∈R

|R|

(3.1)

where,• R is a set of target revisions.
• M Cd (r) is the number of modifications on cloned code between revision r
and r + 1.
We also define M Fn in the formula (3.2).
∑
M Cn (r)M Fn =

r∈R

|R|

(3.2)

where,• M Cn (r) is the number of modifications on non-cloned code between revision r and r + 1.
These values mean the average number of modifications on cloned code or
non-cloned code per revision. However, in these definitions, M Fd and M Fn arevery affected by the amount of code clones included the source code. For example,
if the amount of code clones is very small, it is quite natural that the number ofmodifications on cloned code is much smaller than non-cloned code. However,
if a small amount of cloned code is included but it is quite frequently modified,
we need additional maintenance effort to judge whether its correspondents need
the same modifications or not. We cannot evaluate the influence of code clones inthese situations in these definitions.
In order to eliminate the bias of the amount of code clones, we normalize theformulae (3.1) and (3.2) with the ratio of cloned code. Here, we assume that:• LOCd (r) is the total lines of cloned code in revision r.
49• LOCn (r) is the total lines of non-cloned code on r.
• LOC(r) is the total lines of code on r, so that the following formula issatisfied:
LOC(r) = LOCd (r) + LOCn (r)(3.3)

Under these assumptions, the normalized M Fd and M Fn are defined in thefollowing formulae (3.4) and (3.5).
∑
normalized M Fd =r∈R∑

LOC(r)

r∈R|R|∑

normalized M Fn =M Cd (r)

×∑

(3.4)

LOCd (r)r∈R

M Cn (r)∑LOC(r)

r∈R

r∈R

|R|

×∑

(3.5)

LOCn (r)r∈R

In the reminder of this chapter, the normalized M Fd and M Fn are refered asjust M Fd and M Fn , respectively.
Measurement Steps
M Fd and M Fn are calculated with the following steps:
STEP1: Identify target revisions from the repositories of target software systems.
Then, all the target revisions are checked out into our local storage.
STEP2: Normalize all the source files in every target revision.
STEP3: Detect code clones within every target revision, and then the detection
result is analyzed in order to identify the file path and the lines of all thedetected cloned code.
STEP4: Identify differences between two consecutive revisions. The start lines
and the end lines of all the differences are stored.
STEP5: Count the number of modifications on cloned code and non-cloned code.
STEP6: Calculate M Fd and M Fn .
The remainder of this subsection explains each step of measurement in detail.
50

STEP1: Obtains target revisions
In order to measure M Fd and M Fn , it is necessary to obtain historical dataof source code. As described above, this study uses a version control system,
Subversion, to obtain the historical data.
This step identifies which files were modified, added, or deleted in each revision and finds out target revisions. After identifying all the target revisions fromthe historical data, they are checked out into the local storage.
STEP2: Normalizes source files
STEP2 normalizes every source file in all the target revisions with the following
rules:• deletes blank lines, code comments, and indents,• deletes lines that consist of only a single open/close brace, and the open/close
brace is added to the end of the previous line.
The presence of code comments influences the measurement of M Fd andM Fn . If a code comment locates within cloned code, it is regarded as a partof cloned code even if it is not a program instruction. Thus, the LOC of cloned
code is counted greater than it really is. Also, there is no common rule how code
comments should be treated if they are located in the border of cloned code andnon-cloned code, which can cause a problem that a certain detector regards sucha code comment as cloned code meanwhile another tool regards it as non-clonedcode.
As mentioned above, the presence of code comments makes it more difficult
to identify positions of cloned code accurately. Consequently, this step completely
eliminates all the code comments from source code. As well as code comments,
different clone detectors handle blank lines, indents, lines including only a single
open or close brace in different ways, which also influences results of clone detection. For this reason, blank lines and indents are removed, and lines that consistof only a single open or close brace are removed, and the removed open or close
brace is added to the end of the previous line.
STEP3: Detects code clones
This step detects code clones from every target revision with clone detectors,
and stores the detection results into a database. Each detected cloned code is identified as a three-tuple (v, f, l), where: v is the revision number where a given cloned
51

code was detected; f is the absolute path to the source file where a given cloned
code exists; l is a set of line numbers where cloned code exists. Note that storing
only the start line and the end line of cloned code is not feasible because a part ofcloned code is non-contiguous.
This step is very time consuming because this step need to run each clone
detector on every target revisions. That is, if the history of the target software
includes 1,000 target revisions, cloned code detection need to be performed 1,000
times. However, this step is fully-automated, and no manual work is required.
STEP4: Identifies differences between two consecutive revisions
STEP4 finds out modification places between two consecutive revisions. As
described above, just parsing outputs of diff offers this information.
STEP5: Counts the number of modifications
In this step, we count the number of modifications on cloned code and noncloned code with the results of the previous two steps. Here, we assume the variable
for the number of modifications of cloned code is M Cd , and the variable for noncloned code is M Cn . Firstly, M Cd and M Cn are initialized with 0, then they are
increased as follows; if the range of specified modification is completely included
in cloned code, M Cd is incremented; if it is completely included in non-cloned
code, M Cn is incremented; if it is located across the border of cloned code andnon-cloned code, both M Cd and M Cn are incremented. All the modifications areprocessed with the above algorithm.
STEP6: Calculates M Fd and M Fn
STEP6, the last step of measurement, calculates values of M Fd and M Fn withthe definitions in the formulae (3.4) and (3.5).

3.5 Design of Experiment
The investigation in this study consists of the following two experiments.
Experiment 1: Compare M Fd and M Fn on 15 open source software systems.
Experiment 2: Compare the result of the proposed method with two conventional
investigation methods on five open source software systems.
The remainder of this section describes the design of these experiments in detail.
52

3.5.1 Experiment 1
Outline
The purpose of this experiment is to answer our research questions. This experiment consists of the following two sub-experiments.
Experiment1-1: Compare M Fd and M Fn on software systems having various
sizes with a scalable clone detector, CCFinder.
Experiment1-2: Compare M Fd and M Fn on small size software systems withfour clone detectors described in section 3.3.1.
The following items are investigated in each sub-experiment.
Item A: Investigate whether cloned code is modified more frequently than noncloned code, with M Fd and M Fn calculated on the entire periods.
Item B: Divide the entire period into 10 sub-periods and calculate M F s on everyof the sub-periods.
Target Software Systems
Experiment 1 targets 15 open source software systems shown in Table 3.1. Five
software systems are investigated in Experiment 1-1, and the other 10 softwaresystems are investigated in Experiment 1-2. The criteria for the selection of thesetarget software systems are as follows:• the source code is managed with Subversion;• the source code is written in C/C++ or Java.
Note that we took care not to bias the domains of the targets.
3.5.2 Experiment 2
OutlineExperiment 2 compares the results of the proposed method and two investigation methods that are previously proposed by other researchers on the same targets. The purpose of this experiment is to reveal whether comparisons of cloned
code and non-cloned code with different methods always introduce the same result. Also, we evaluate the efficacy of the proposed method compared to the othermethods.
53

Investigation Methods to be Compared
Here, we describe investigation methods used in Experiment 2. Experiment 2
uses two investigation methods. One is proposed by Krinke [88] (in short, Krinke’s
method) and the other is one proposed by Lozano et al. [101] (in short, Lozano’s
method). Table 3.2 shows an overview of these methods and the proposed method.
The selection of the two investigation methods was performed based on the following criteria:

Table 3.1: Target Software Systems - Experiment 1

Name
EclEmma
FileZilla
FreeCol
SQuirrel SQL Client
WinMerge(a) Experiment 1-1
Programming
DomainLanguage
Testing
Java
FTP
C++
Game
Java
Database
Java
Text Processing
C++(b) Experiment 1-2
Programming
DomainLanguage
3D ModelingJava
Database
Java
Web
Java
Network(NAT)
Java
Messenger
Java
Mail
C
Database
C/C++
Network(NNTP)
C
GUI,Network(VPN)
C
Game
C/C++

Name
ThreeCAM
DatabaseToUMLAdServerBeans
NatMonitor
OpenYMSG
QMailAdmin
Tritonn
Newsstar
Hamachi-GUI
GameScanner# of Revisions
788
3,450
5,963
5,351
7,082

# of Revisions
14
59
98
128
141
312
100
165
190
420

LOC
(Latest Revision)
15,32887,282
89,661
207,376
130,283

LOC(Latest Revision)
3,854
19,6957,406
1,139
130,072
173,688
45,368
192,716
65,7901,214,570

Table 3.2: Overview of Investigation Methods
MethodTarget Revisions
Investigation Unit
MeasureKrinke [88]a revision per week
line
ratio of modified lines

54

Lozano et al. [101]allmethodwork

Proposed Method
all
place
MF

• The investigation is based on the comparison of some characteristics between cloned code and non-cloned code.
• The method has been published at the time when our research started (at2010/9).
In the experiments of Krinke’s and Lozano’s papers, only a single clone detector, Simian or CCFinder, was selected, respectively. However, this experimentapplies all the four clone detectors used in Experiment 1 for bringing more general
results.
We have developed software tools for Krinke’s and Lozano’s methods basedon their papers. The followings are brief explanations for Krinke’s method andLozano’s method.
Krinke’s Method
Krinke’s method compares stability of cloned code and non-cloned code [88].
Stability is calculated based on ratios of modified lines in cloned code and in noncloned code. This method uses not all the revisions but a revision per week.
First of all, a revision is extracted from every week history, and then cloned
code is detected from every of the extracted revisions. Next, every consecutive
two revisions are compared for obtaining where added lines, deleted lines, andchanged lines are. With this information, the ratios of added lines, deleted lines,
and changed lines on cloned code and non-cloned code are calculated and compared.
Lozano’s Method
Lozano’s method categorizes Java methods, then compares distributions ofmaintenance costs based on the categories [101].
First, Java methods are traced based on their owner class’s full qualified name,start/end lines, and signatures. Methods are categorized as follows:
AC-Method: methods that always had cloned code during their lifetimes;
NC-Method: methods that never had cloned code during their lifetimes;
SC-Method: methods that sometimes had cloned code and sometimes did not.
Lozano’s method defines the following terms, where m is a method, P is aperiod (a set of revisions), and r is a revision.
55

• ChangedRevisions(m, P ): a set of revisions that method m was modifiedin period P ,• Methods(r): a set of methods that existed in revision r,• ChangedMethods(r): a set of methods that were modified in revision r,• CoChangedMethods(m, r): a set of methods that were modified simultaneously with method m in revision r. If method m is not modified in revisionr, it becomes 0. Note that the following formula holds if method m was
modified in revision r.
ChangedMethod (r) = m ∪ CoChangedMethod (m, r)(3.6)

Then, this method calculates the following formulae with the above definitions.
Lozano’s method regards work as an indicator for estimating the maintenance costs.
ChangedRevisions(m, P )likelihood (m, P ) = ∑|ChangedMethods(r)|

(3.7)

r∈P

∑ |CoChangedMethods(m, r)|
impact(m, P ) =|Methods(r)|r∈P|ChangedRevisions(m, P )|work (m, P ) = likelihood (m, P ) × impact(m, P )

(3.8)
(3.9)

In this research, we compare work between AC-Method and NC-Method. In
addition, we also compare SC-Methods’ work on cloned period and non-cloned
period.
Target Software Systems
Experiment 2 targets five open source software systems shown in Table 3.3.
Two targets, OpenYMSG and EclEmma, are selected as well as Experiment 1.
Note that the number of revisions and LOC of the latest revision of these twotargets are different from Table 3.1. This is because they had been being in development between the time-lag in Experiment 1 and Experiment 2. Every source fileis normalized with the rules described in Section 3.4.2 as well as Experiment 1. In
addition, automatic generated code and testing code had been removed from all therevisions before the investigation methods were applied.
56

20changeadd

delete

MF

15
10

5
0
d

n
EclEmmadnFileZilladnFreeColdnSquirreldnWinMerge

Figure 3.3: Result of Item A on Experiment 1-1

3.6 Experiment 1 - Result and Discussion
3.6.1 Overview
Table 3.4 shows the average ratio for each target of Experiment 1. Note that“ccf”, “ccfx”, “sim”, and “sco” in the table are the abbreviated form of CCFinder,
CCFinderX, Simian, and Scorpio, respectively.
Table 3.5 shows the overall result of Experiment 1. In this table, label “C”
means M Fd > M Fn in that case, and “N” means the opposite result. For example, the comparison result in ThreeCAM with CCFinder is M Fd < M Fn , whichmeans cloned code was not modified more frequently than non-cloned code.
The following subsections describes the experimental results in detail.
3.6.2 Result of Experiment 1-1
Figure 3.3 shows all the results of Item A on Experiment 1-1. The labels ‘d’and ‘n’ in X-axis means M F in cloned code and non-cloned code, respectively,
and every bar consists of three parts, which means change, delete, and add. As
shown in Figure 3.3, M Fd is lower than M Fn on all the target systems. Table 3.6
shows the average values of M F based on the modification types. The comparison

Table 3.3: Target Software Systems - Experiment 2
Name

DomainOpenYMSG
EclEmma
MASU
TVBrowser
Ant

Messenger
Testing
Source Code Analysis
Multimedia
Build

Programming
Language
Java
Java
Java
Java
Java

57

# of Revisions
194
1,220
1,620
6,829
5,412

LOC
(Latest Revision)
14,111
31,40979,360264,796
198,864results of M Fd and M Fn show that M Fd is less than M Fn in the cases of all themodification types. However, the degrees of differences between M Fd and M Fn
are different for each modification type.
Figure 3.4 shows the result of Item B on Experiment 1-1. X-axis is the divided
periods. Label ‘1’ is the earliest period of the development, and label‘10’ is themost recent period. In the case of EclEmma, the number of periods that M Fd isgreater than M Fn is the same as the number of periods that M Fn is greater than
M Fd . In the case of FileZilla, FreeCol, and WinMerge, there is only one periodthat M Fd is greater than M Fn . In the case of Squirrel SQL Client, M Fn is greaterthan M Fn in all the periods. This result implies that if the number of revisions
becomes large, cloned code tends to become more stable than non-cloned code.
However, the shapes of M F transitions are different from every software system.
For WinMerge, we performed detail investigation on two periods. One is period ‘2’, where M Fn is much greater than M Fd , and the other is period ‘10’, where

Table 3.4: Ratio of Code Clones - Experiment 1(a) Experiment 1-1
Software Name
ccf
ccfx
EclEmma
13.1%
FileZilla
22.6%
FreeCol
23.1%
SQuirrel
29.0%
23.6%
WinMergesim-(b) Experiment 1-2
Software Name
ccf
ccfx
sim
ThreeCAM
29.8% 10.5%
4.1%
DatabaseToUML 21.4% 25.1%
7.6%
AdServerBeans 22.7% 18.2% 20.3%
9.0%
7.7%
0.7%
NatMonitor
OpenYMSG
17.4%
9.9%
5.8%
QMailAdmin
34.3% 19.6%
8.8%
Tritonn
13.8%
7.5%
5.5%
Newsstar
7.9%
4.8%
1.5%
Hamachi-GUI
36.5% 23.1% 18.5%
GameScanner
23.1% 13.1%
6.6%
58

sco
-

sco
26.2%
11.8%
15.9%
6.6%
9.9%
-

MF

MF

25
20
15
10
5
0

2

3

5

6

Time Period(a) EclEmma

4

7

8

9

10

1

2

3

6

Time Period

5

8

9

10

2

3

1

2

3

5

6

Time Period(e) WinMerge

4

5

6

Time Period(b) FileZilla

4

7

8

9

10

1

2

3

7

8

9

5

6

Time Period(d) SQuirreL

4

10

7

8

9

10

d n d n d n d n d n d n d n d n d n d n1

d n d n d n d n d n d n d n d n d n d nd n d n d n d n d n d n d n d n d n d n

7

0

10

20

30

40

0

5

10

15

20

Figure 3.4: Result of Item B on Experiment 1-1

25
20
15
10
5
0

(c) FreeCol4d n d n d n d n d n d n d n d n d n d n1

d n d n d n d n d n d n d n d n d n d n

MF
MF

25
20
15
10
5
0

MF

59

is only the period that M Fd is greater than M Fn . In period ‘10’, there are many
modifications on test cases. The number of revisions that test cases are modified
is 49, and the ratio of cloned code in test cases is 88.3%. Almost all modifications
for test cases were performed on cloned code, so that M Fd is greater than M Fn .
Omitting the modifications for test cases, M Fd and M Fn became inverted.

Table 3.5: Overall Results - Experiment 1(a) Experiment 1-1
Software Name ccf ccfx sim
EclEmmaN
N
FileZilla
FreeColN
SQuirrelN
WinMerge
N
-

sco
-

(b) Experiment 1-2
Software Name ccf ccfx sim
ThreeCAM
N
C
N
DatabaseToUML N
N
N
AdServerBeans
N
N
N
C
C
N
NatMonitor
OpenYMSG
C
C
C
C
C
C
QMailAdmin
Tritonn
N
C
N
N
N
N
Newsstar
Hamachi-GUI
N
N
N
GameScanner
C
C
N

sco
N
N
N
C
N
-

Table 3.6: The Average Values of M F in Experiment 1-1
Modification
Typechangedeleteadd
ALLcloned code
7.03371.0216
1.953910.0092
60

MF
non-cloned code
8.10391.48473.737813.3264

The summary of Experiment 1-1 is as follows: cloned code detected by CCFinder
was modified less frequently than non-cloned code. Consequently, we conclude
that code clones detected by CCFinder do not have a negative impact on software
evolution even if the software is large and has a long lifetime.
3.6.3 Result of Experiment 1-2
Figure 3.5 shows all the results of Item A on Experiment 1-2. In Figure 3.5,
each clone detector is abbreviated as follows: CCFinder → C; CCFinderX →X; Simian → Si ; Scorpio → Sc . There are the results of three detectors except
Scorpio on C/C++ systems, because it does not handle C/C++. As shown in the
figure, M Fd is less than M Fn in the 22 comparison results out of 35. In the fourtarget systems out of 10, cloned code is modified less frequently than non-cloned
code in the cases of all the detectors. In the case of the other target system, M Fd
is greater than M Fn in the cases of all the detectors. In the remaining systems,
the comparison results are different from the detectors. In addition, we compared
M Fd and M Fn based on programming languages and detectors. The comparison
results are shown in Table 3.7. The result shows that M Fd is less than M Fn on
all the programming languages, and M Fd is less than M Fn on the three detectors, CCFinder, CCFinderX, and Simian, whereas the opposite result is shown inthe case of CCFinderX. We also compared M Fd and M Fn based on modification
types. The result is shown in Table 3.8. As shown in Table 3.8, M Fd is less than
M Fn in the cases of change and addition, whereas the opposite result is shown inthe case of deletion.
We investigated whether there is a statistically-significant difference between
M Fd and M Fn by t-test. The result is as follows: there is no difference between
them where the level of significance is 5 %. Also, there is no significant differencein the comparison based on programming languages and detectors. It is generally
said that the presence of code clones makes it more difficult to maintain software.
However, these experimental results do not show such a tendency.
Figure 3.6 shows the result of Item B on Experiment 1-2. Figure 3.6 contains
graphs for the results of three software systems: Figure 3.6(a) shows the resultsof AdServerBeans, Figure 3.6(b) shows those of OpenYMSG, and Figure 3.6(c)shows those of NatMonitor, respectively.
In Figure 3.6(a), period ‘4’ shows that M Fn is greater than M Fd on all the detectors meanwhile period ‘7’ shows exactly the opposite result. In period ‘5’, there
are also hardly differences between cloned code and non-cloned code. We investigated the source code of period ‘4’ to reveal the reason why such grate differences
between M Fd and M Fn occured. In this period, many source files were createdby copy-and-paste operations, and a large amount of code clones was detected by
61

62

MF

MF

0

50

100

150

200

250

80
70
60
50
40
30
20
10
0

delete

add

d

C

C

d
X

n

d

QMailAdminnSi

ThreeCAM

X

Si

n

Sc

d

Si

n
X

n

Tritonn

d

d

n

Sc

Si

DatabaseToUML

X

Si

C

n
X

n

Newsstard(b) C/C++ SoftwareddAdserverBeans

X(a) Java Software

C

Si

n

Sc

d
C

C

d
X

n

d

Hamachi-GUInSi

NatMonitor

X

Figure 3.5: Result of Item A on Experiment 1-2

C

C

Si

n

Sc

d
C

C

d
X

n

d

GameScannern

Si

OpenYMSG

X

Si

n

Sc

d n d n d n d n d n d n d n d n d n d n d n d n d n d n d n d n d n d n d n d nchange

63
0

10

20

30

40

50

60

0

10

20

30

40

50

0

50

100

150

200

250
deleteaddchange2

delete

3

4

6

add

(a) AdServerBeans

5

7

8

9

10

change2

delete

3

4

add

6

(b) OpenYMSG

5

7

8

9

10

1

2

4

6

(c) NatMonitor

5

7

8

Figure 3.6: Result of Item B on Experiment1-2

3

9

10

C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc

dndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndn

1

C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc

dndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndn

1

C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc C X Si Sc

dndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndndn

changeeach clone detector. The code generated by the copy-and-paste operations was very
stable whereas the other source files were modified as usual. This is the reason why
M Fn is much greater than M Fd in period ‘4’.
Figure 3.6(b) shows a tendency of modification frequencies: cloned code tends
to be modified more frequently than non-cloned code in the anterior half of theperiod, whereas the opposite occurred in the posterior half. We found that there
was a large number of cloned code that was repeatedly modified in the anterior
half. On the other hand there was rarely such cloned code in the posterior half,
which results in the occurrence of such a tendency.

Table 3.7: Comparing M F s based on Programming Language and Detector(a) Comparison on Programming Language
ProgrammingMF
Languagecloned code non-cloned codeJava
20.4370
24.1739
C/C++
49.4868
57.2246ALL
32.8869
38.3384(b) Comparison on Detection Tool
DetectionMF
Toolcloned code non-cloned code
CCFinder38.2790
40.7211
CCFinderX40.354140.0774
Simian26.0084
42.1643
Scorpio20.925424.1628ALL
32.8869
38.3384

Table 3.8: The Average Values of M F in Experiment 1-2
Modification
Typechangedeleteadd
ALLcloned code
26.80653.8706
2.209832.8869
64

MF
non-cloned code
29.2549
3.52285.560838.3384

Figure 3.6(c) shows an opposite tendency of modification frequencies of Figure 3.6(c): cloned code was modified more frequently in the posterior half of theperiod. In the anterior half, the amount of code duplications was very small, andmodifications were rarely performed on it. In the posterior half, amount of clones
became large, and modifications were performed on it repeatedly. In the case of
Simian detection, no cloned code was detected except period ‘5’. This is because
Simian detects only the exact-match clones whereas the other tools detect exactmatch and renamed clones in the default setting.
The summary of Experiment 1-2 is as follows: we found some instances thatcloned code was modified more frequently than non-cloned code in a short period
on each clone detector; however, in the entire period, cloned code was modified
less frequently than non-cloned code on every target software with all the detectors. Consequently, we conclude that the presence of code clones does not have aseriously negative impact on software maintenance.

3.6.4 Answers to Research Questions
This subsection offers the answers to every research question.

RQ1: Is cloned code more frequently modified than non-cloned code?
The answer is No. In Experiment 1-1, we found that M Fd is lower than M Fn
in all the target systems. Also, we found a similar result in Experiment 1-2: 22
comparison results out of 35 show that M Fd is lower than M Fn , also M Fd islower than M Fn in average. This result indicates that code clones tend to be morestable than non-cloned code. Hence, the presence of code clones does not seriously
affect software evolution, which is different from the common belief.

RQ2: Are the comparison results of stability between cloned code and non-cloned
code different from multiple detection tools?
The answer is Yes. In Experiment 1-2, the comparison results with CCFinderX
are different from the results with other three detectors. Moreover, M Fn is muchgreater than M Fd in the case of Simian. At present, we cannot have found thecauses of the differences of the comparison results. One of the causes may be theratio of code clones. The ratio of code clones is quite different in each clone detector on the same software systems. However, we cannot see any relation between
the ratio of code clones and values of M F .
65

RQ3: Is cloned code modified uniformly throughout its lifetime?
The answer is No. The results of Item B of Experiment 1-1 and Experiment1-2 showed that there are some instances that cloned code was modified more frequently than non-cloned code in a short period even though M Fd is less than M Fn
in the whole period. However, these M F ’s tendencies varied according to target
software systems, so that we cannot find any common tendency. We also cannot
find any characteristic that causes such variability.
RQ4: Are there any differences in the comparison results on types of modifications?
The answer is Yes. The experimental results in Experiment 1-1 revealed that
M Fd is less than M Fn on all the modification types. However, there is a small
difference between M Fd and M Fn in the case of deletion, whereas there is a large
difference in the case of addition. The results in Experiment 1-2 showed similar
results in the cases of change and addition: M Fd is less than M Fn . Specifically,
M Fn is more than twice as large as M Fd in the case of addition. However, M Fd
is greater than M Fn in the case of deletion. These results show that deletion tends
to be affected by code clones, meanwhile addition tends not to be affected by them.
3.6.5 Discussion
The results of Experiment 1 showed that cloned code tends to be more stable
than non-cloned code, which indicates that the presence of code clones does nothave a negative impact on software evolution. To reveal the reasons why code
clones are stable, we investigated how the software evolved in some of the periods
that M Fd is less than M Fn . The manual investigation found that the following
activities should be a part of factors that cloned code is modified less frequently
than non-cloned code.
Reusing stable code: When developers want to implement new functionalities,
reusing stable code will be a good way to reduce the number of introduced
bugs. If most of cloned code is created by reusing stable code, M Fd becomesless than M Fn .
Using generated code: Automatically-generated code is rarely modified manually. The generated code also tends to be cloned code. Consequently, M Fd
will become less than M Fn if the amount of generated code is high.
On the other hand, there are some cases that cloned code was more frequently
modified than non-cloned code in a short period. The period ‘7’ on AdServer66

Beans (Experiment 1-2, Item B) is one of these instances. We analyzed the sourcecode of this period to detect why M Fd was greater than M Fn in this period eventhough the opposite results were shown in the other periods. Our manual inspection showed that there are some instances that the same modifications were applied
to multiple places of code, which is a situation that the precense of code clones hasa bad effect on software evolution.
Figure 3.7 shows an instance of unstable code clones. This code clone has fivecode fragments as its members, and the figure shows one of the code fragments
included in the code clone. First, lines labeled with ‘%’ (shown in Figure 3.7 (b))
were modified to replace the getter methods into direct accesses into fields. In
the next, a line labeled with ‘#′ is removed (shown in Figure 3.7 (c)). These two
modifications were concentrically conducted in period ‘7’. Reusing unstable codelike this example can cause additional costs for software evolution. Moreover,a code fragment was not simultaneously changed with its correspondents at thesecond modification. If this inconsistency was introduced unintentionally, it mightcause a bug. If so, this is a typical situation that the presence of code clones affects
software evolution.

3.7

Experiment 2 - Result and Discussion

3.7.1 Overview
Table 3.9 shows the average ratios of code clones included in each target, andTable 3.10 shows the comparison results of all the targets. In Table 3.10, “C” meansthat cloned code requires more costs than non-cloned code, and “N” means its opposite. The discriminant criteria of “C” and “N” are different in each investigation
method.
In the proposed method, if M Fd is lower than M Fn , the column is labeledwith “C”, and the column is labeled with “N” in its opposite case.

Table 3.9: Ratio of Code Clones - Experiment 2
Software Name
OpenYMSG
EclEmma
MASU
TVBrowser
Ant

ccf
12.4%
6.9%
25.6%
13.6%
13.9%

ccfx
6.2%
4.8%
26.5%
10.9%
12.1%
67

sim
2.7%
2.0%
11.3%
5.4%
6.2%

sco
5.5%
3.7%
15.4%
19.0%
15.6%

int offsetTmp = dataGridDisplayCriteria.getItemsPerPage() *(dataGridDisplayCriteria.getPage() - 1);
if (offsetTmp > 0) --offsetTmp;
if (offsetTmp < 0) offsetTmp = 0;
final int offset = offsetTmp;
String sortColumn =dataGridDisplayCriteria.getSortColumn();
Order orderTmp =dataGridDisplayCriteria.getOrder().equals(AdServerBeansConstants.ASC) ?
Order.asc(sortColumn) :Order.desc(sortColumn);(a) Before Modification
int offsetTmp = dataGridDisplayCriteria.getItemsPerPage() *(dataGridDisplayCriteria.getPage() - 1);
if (offsetTmp > 0) --offsetTmp;
if (offsetTmp < 0) offsetTmp = 0;
final int offset = offsetTmp;
String sortColumn =%dataGridDisplayCriteria.sortColumn;
Order orderTmp =%dataGridDisplayCriteria.order.equals(AdServerBeansConstants.ASC) ?
Order.asc(sortColumn) :Order.desc(sortColumn);(b) After 1st Modification
int offsetTmp = dataGridDisplayCriteria.getItemsPerPage() *(dataGridDisplayCriteria.getPage() - 1);#
if (offsetTmp < 0) offsetTmp = 0;
final int offset = offsetTmp;
String sortColumn =dataGridDisplayCriteria.sortColumn;
Order orderTmp =dataGridDisplayCriteria.order.equals(AdServerBeansConstants.ASC) ?
Order.asc(sortColumn) :Order.desc(sortColumn);(c) After 2nd Modification
Figure 3.7: An Example of Unstable Cloned Code68

In Krinke’s method, if the ratio of changed and deleted lines on cloned code isgreater than changed and deleted lines on non-cloned code, the column is labeledwith “C”, and in its opposite case the column is labeled with “N”. Note that herein
we do not consider added lines because the amount of add is the lines of code
added in the next revision, not in the current target revision.
In Lozano’s method, if work in AC-Method is statistically greater than one in
NC-Method, the column is labeled with “C”. On the other hand, if work in NCMethod is statistically greater than one in AC-Method, the column is labeled with“N”. Here we use Mann-Whitney’s U-test under setting 5% as the level of significance. If there is no statistically-significant difference in AC- and NC-Method,
we compare work in cloned period and non-cloned period in SC-Method with Wlcoxon’s singed-rank test. We also set 5% as the level of significance. If there is no
statistically-significant difference, the column is labeled with “-”.
As this table shows, different methods and different clone detectors brought
almost the same result in the case of EclEmma and MASU. On the other hand, inthe case of other targets, we get different results with different methods or different
detectors. Specifically, in the cases of TVBrowser and Ant, the proposed methodbrought the opposite results to those of Lozano’s and Krinke’s method.

Table 3.10: Overall Results - Experiment 2
Software Name
OpenYMSG

EclEmma

MASU

TVBrowser

Ant

MethodProposed
KrinkeLozanoProposed
KrinkeLozanoProposed
KrinkeLozanoProposed
KrinkeLozanoProposed
KrinkeLozano
69

ccf
N
N
N
N
N
C
C
C
N
C
C
N
C
C

Tools
ccfx sim
C
C
C
C
N
N
N
N
N
N
N
C
C
C
C
C
N
N
C
C
C
C
N
N
C
C
C
C

sco
N
N
N
C
C
C
C
N
C
C
N
C
C

25

changedelete

add

n

d

n

20

15
10
5

0
d
ccf

d

ccfx

n

d

sim

n
sco

Figure 3.8: Result of the Proposed Method on MASU
1.4
1.2
1
0.8
0.6
0.4
0.2
0

changedn
ccf

delete

d

add

n
ccfx

d

n
sim

d

n
sco

Figure 3.9: Result of Krinke’s Method on MASU
3.7.2 Result of MASU
Herein, we show comparison figures of MASU. Figure 3.8 shows the resultsof the proposed method. In this case, all the clone detectors except CCFinderX
brought the same result that cloned code is more frequently modified than noncloned code. Figure 3.9 shows the results of Krinke’s method on MASU. As thisfigure shows, the comparison of all the detectors brought the same result that cloned
code is less stable than non-cloned code. Figure 3.10 shows the results of Lozano’s
method on MASU with Simian. Figure 3.10(a) compares AC-Method and NCMethod. X-axis indicates maintenance costs (work) and Y-axis indicates cumulated
frequency of methods. For readability, we adopt logarithmic axis on X-axis. In
this case, AC-Method requires more maintenance costs than NC-Method. Figure3.10(b) compares cloned periods and non-cloned periods of SC-Method. In thiscase, the maintenance cost in cloned period is greater than in non-cloned period.
In the case of MASU, Krinke’s method and Lozano’s method regard cloned
code as requiring more costs than non-cloned code in the cases of all the detectors.
70

100.0%AC-Method
NC-Method

80.0%

60.0%
40.0%

20.0%
0.0%
1

10

100

1000

(a) AC-Method v. NC-Method

100.0%

duplicate period
non-duplicate period

80.0%
60.0%
40.0%
20.0%
0.0%

1

10

100

1000

(b) SC-Method

Figure 3.10: Result of Lozano’s Method on MASU with Simian
The proposed method indicates that cloned code is more frequently modified thannon-cloned code with CCFinder, Simian, and Scorpio. In addition, there is little
differences between M Fd and M Fn in the result of the proposed method with
CCFinderX, which is the only case that cloned code is more stable than non-cloned
code. Considering all the results, we can say that cloned code has a negative impact
on MASU. This result is reliable because all the investigation methods show suchtendencies.
3.7.3 Result of OpenYMSG
Figures 3.11, 3.12, and 3.13 show the results of the proposed method, Krinke’s
method, and Lozano’s method on another experimental target, OpenYMSG. In
71

30changedelete

add

n

d

n

25
20
15

10
5
0
d
ccf

d

ccfx

n

d

sim

n
sco

Figure 3.11: Result of the Proposed Method on OpenYMSG
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0

changedn
ccf

delete

d

add

n
ccfx

d

n
sim

d

n
sco

Figure 3.12: Result of Krinke’s Method on OpenYMSG
the cases of the proposed method and Krinke’s method, cloned code is regarded
as having a negative impact with CCFinderX and Simian, whereas the opposing
results are shown with CCFinder and Scorpio. In Lozano’s method with Simian,cloned code is regarded as not having a negative impact. Note that we omit thecomparison figure on SC-Method because there are only three methods that are
categorized into SC-Method in OpenYMSG with Simian.
As these figures show, the comparison results are different for detectors orinvestigation methods. Therefore, we cannot judge whether the presence of cloned
code has a negative impact or not on OpenYMSG.
3.7.4 Discussion
In the case of OpenYMSG, TVBrowser, and Ant, different investigation methods and different clone detectors brought opposing results. Figure 3.14 shows anactual modification in found in Ant. Two methods were modified in this modification. The hatching parts are detected as cloned code and frames in them mean pairs72100.0%AC-Method

80.0%

NC-Method

60.0%
40.0%
20.0%
0.0%

1

10

100

1000

Figure 3.13: Result of Lozano’s Method on OpenYMSG with Simiancode fragment 1

code fragment 2

private void doClassicComplie() throws BuildException {log(“Using classic compiler”, Project.MSG_VERBOSE);
Path classPath = getCompileClasspath(false);
7 lines...
argList.addElement(“-classpath”);
if (...) { ...
} else {...
}if (debug) { ... }17 lines...
log(“Compilation args: “ + argList.toString(),
Project.MSG_VERBOSE);

private void doClassicComplie() throws BuildException {...
log(“Using classic compiler”, Project.MSG_VERBOSE);
Path classPath = getCompileClasspath(false);
7 lines...
argList.addElement(“-classpath”);...
if (debug) { ... }17 lines...
log(“Compilation args: “ + argList.toString(),
Project.MSG_VERBOSE);

32
lines

38
lines

String[] args = new String[argList.size() + complieList.size()];...
Enumeration enum = complieList.elements();
while (enum.hasMoreElements()) { ... }log(niceSourceList.toString(), Project.MSG_VERBOSE);...
...

String[] args = new String[argList.size() + complieList.size()];...
Enumeration enum = complieList.elements();
while (enum.hasMoreElements()) { ... }log(niceSourceList.toString(), Project.MSG_VERBOSE);
ByteArrayOutputStream out = new ByteArrayOutputStream();
...
...

}

Clone pair relationship}

Modified lines between this revision and the next

Figure 3.14: An Example of Modification by Refactoringof cloned code between two methods. Vertical arrows show modified lines by thismodification (77 lines of code were modified).
This modification is ain instance of Extract Method refactoring, which extracts the duplicated instructions from the two methods and merges them as a
new method. In the proposed method, it is regarded that there are two modification places in cloned code and four places in non-cloned code, so that M Fd andM Fn became 51.13 and 18.13, respectively. In Krinke’s method, DC + CC and
DN + CN became 0.089 and 0.005, where DC, CC, DN , and CN indicate theratio of deleted lines on cloned code, changed lines on cloned code, deleted lines
on non-cloned code, and deleted lines on non-cloned code, respectively.
73

In this case, both the proposed method and Krinke’s method regarded thatcloned code required more maintenance costs than non-cloned code. However,there is a great difference in Krinke’s method than the proposed method. Thisis caused by the difference of the barometers used in each method. In Krinke’s
method, the barometer depends on the amount of modified lines, whereas thebarometer depends on the amount of modified places in the proposed method. This
example is one of refactorings on code clones. In Krinke’s method, if removed
cloned code is large, cloned code is regarded as having more influence. However,in the cases of cloned code removal, we have to spend much effort if the numberof cloned fragments is high. Therefore, we can say that the proposed method canaccurately measure the influence of cloned code in this case.
This is an instance that is advantageous for the proposed method. However,
we cannot investigate all the experimental data because the amount of the data is
too vast to conduct manual checking for all the modifications. Hence, there is apossibility that the proposed method cannot accurately evaluate the influence ofcloned code in some situations.
In Experiment 2, we found that the different investigation methods or different
detectors draw different results on the same target systems. In Experiment 1, we
found that cloned code is less frequently modified than non-cloned code. However,
the result of Experiment 2 indicates that we cannot generalize the result of Experiment 1. We have to conduct more experiments and analyze the results of them indetail to gain more general results.

3.8 Threats to Validity
This section describes threats to validity of this study.
Cost required for every modification
In this study, we assume that cost required for every modification is equal toone another. However, the cost must be different between every modification in
the actual software evolution. Consequently, the comparison based on M F values
may not appropriately represent the costs required for modifying cloned code andnon-cloned code.
In addition, when we modify cloned code, we have to consider keeping theconsistency between the modified cloned code and its correspondents. If the modification lacks consistency by error, we have to re-modify them for repairing theconsistency. The effort for keeping consistency is not necessary for modifying
non-cloned code. Consequently, the average costs required for cloned code may
74be different from the one required for non-cloned code. In order to compare themmore appropriately, we have to consider the costs for keeping consistency.
Identifying the number of modifications
This study regards modifying consecutive multiple lines are regarded as a single modification. However, it is possible that such an automatically processing
identifies an incorrect number of modifications. If multiple lines that were notcontiguous are modified for fixing a single bug, the proposed method presumes
that multiple modifications were performed. On the other hand, if multiple consecutive lines were modified for fixing two or more bugs by chance, the proposed
method presumes that only a single modification was performed. Consequently, it
is necessary to manually identify modifications if we have to use the exactly correct
number of modifications.
Besides, we investigated how many the identified modifications occurred acrossthe boundary of cloned code and non-cloned code. If this number is high, then theanalysis suspects because such modifications increase both the counts at the sametime. The investigation result is that, in the highest case, the ratio of such modifications is 4.8%. That means that almost all modifications occurred within eithercloned code or non-cloned code.
Category of modifications
This study does not consider meanings of modifications, and so we counted all
the modifications regardless of their meanings. As a result, the number of modifications might be incorrectly increased by unimportant modifications such as format
transformations. A part of unimportant modifications remained even if we had used
the normalized source code described in section 3.4.2. Consequently, manual categorization for the modifications is required for using the exactly correct number ofmodifications.
In addition, the code normalization used in this study removed all the comments in the source files. If considerable cost was expended to make or change
code comments on the development of the target systems, we incorrectly missed
the cost.
Property of target software
In this study, we used only open source software systems, so that different
results may be shown with industrial software systems. It is generally said thatindustrial software includes more cloned code than open source software. Consequently, cloned code may not be managed well in industrial software, which may
75increase M Fd . Also, properties of industrial software are quite different from onesof open source software. In order to investigate the impact of cloned code on industrial software, we have to compare M F on industrial software systems.
Division of development period
In this study, we divided the development periods of target software systems in
an automatic way based on the number of revisions. However, a different division
may yield different results. For example, if we divide the periods based on theborder of versions, we may be able to grasp the properties of every version. Or,
more fine grained division, that is, the period of every version is divided into multiple sub-periods, which will let us know how cloned code and non-cloned code aremodified from a start of a version to the end of the version.
Settings of detection tools
In this study, we used default settings for all clone detectors. All the four clone
detectors used in this study have flexible settings, including the minimum length ofdetected code clones or the way of code normalization before clone detection. It isnatural that the same clone detector reports different clones even in the same software if it runs under different settings. Therefore, different results will be shown if
we adopt each clone detector in different settings.

3.9 Summary
In this study, we conducted an empirical study on the impact of the presenceof cloned code on software evolution. We assumed that if cloned code is modified
more frequently than non-cloned code, the presence of cloned code affects software
evolution, and compared the stability of cloned code and non-cloned code. To
evaluate from a different standpoint from previous studies, we used a new indicator,
modification frequency, which is calculated with the number of modified places ofcode. In addition, we used four clone detectors to reduce the bias of detectors.
We conducted an experiment on 15 open source software systems, and the result
showed that cloned code was less frequently modified than non-cloned code. We
also found some cases that cloned code was intensively modified in a short period
though cloned code was stable than non-cloned code in the whole development
period.
Moreover, we compared the proposed method to other two investigation methods to evaluate the efficacy of the proposed method. We conducted another experiment on five open source software systems, and in the cases of two targets, we76got the opposing results to other two methods. We carefully investigated the result
in detail, and found some instances that the proposed method could evaluate moreaccurately than other methods.
Our experimental result showed that cloned code tends to be stable than noncloned code though there exists some clones that negativelly affect software evolution. However, more studies are required to generalize this result, because wefound that different investigation methods may bring different results. In summary, our experimental results indicated that it is necessary to select and address
harmful clones to be managed from all the detected clones to achive effective clone
management.

77

Chapter 4

Enhancing CRD-based Clone
Tracking based on Similarity of
CRD
4.1 Motivation
As described in Chapter 3, our experimental results revealed that not all but apart of clones has negative impacts on software evolution. However, there are stillsome open issues. One of the issues is how many clones have negative impacts on
software evolution. To tackle these open issues, it is necessary to analyze clones inmore detail ways. That is, extracting and analyzing clone genealogies are required.
A clone genealogy indicates how a clone has been evolved across the version
history of the software having the clone [77, 78]. Therefore, using clone genealogies enables to analyze how many times a particular clone has been changed. Thismeans that we can know how many clones have negative impacts on software evolution, which is a fundamental qustion not addressed by our previous study.
There are some research reports that analyze clone genealogies [5, 8, 35, 78, 87,143]. However, these studies focus on investigating how clones have evolved, nottracking clones. That means, tracking techniques that they used were not feasible
if the clones were drastically modified or the clones were moved into other files
between the revisions.
Currently, there are several techniques for tracking clones. Some techniques
detect clones from every revision, and then link them between every of two consecutive revisions [8, 33, 78]. These techniques link clones based on textual similarity of clones between two revisions, thus they will miss some links of clones if
modifications applied on the clones are not small, or the clones were moved. Some79

SSHExec.java (revision 581,375)	
139	
  	
  public	
  void	  execute()	
  throws	
  BuildException	
  {	
  
	
  	
  	
  	
  	
  	
  	
  ...	  surrounded	
  by	
  try	
  block	  	
  revision 581,376	
for	
  JSchException	
155	
  	
   if	  (command	
  !=	
  null)	
  {	
  
156	
  	
  	
  	
  	
  	
  log("cmd	
  :	
  "	
  +	
  command,	
  Project.MSG_INFO);	
  
157	
  	
  	
  	
  	
  	
  executeCommand(command);	
  
158	
  	
  	
  	
  }	
  else	  {	  //	
  read	  command	  resource	
  and	
  execute	  for	
  each	  command	
  
159	
  	
  	
  	
  	
  	
  try	
  {	
  
160	
  	
  	
  	
  	
  	
  	
  	
  BufferedReader	
  br	
  =	
  new	
  BufferedReader(	
  
161	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  new	
  InputStreamReader(commandResource.getInputStream()));	
  
162	
  	
  	
  	
  	
  	
  	
  	
  String	
  cmd;	
  
163	
  	
  	
  	
  	
  	
  	
  	
  while	  ((cmd	
  =	
  br.readLine())	
  !=	
  null)	
  {	
  
164	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  log("cmd	
  :	
  "	
  +	
  cmd,	
  Project.MSG_INFO);	
  
165	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  executeCommand(cmd);	
  
166	
  	
  	
  	
  	
  	
  	
  	
  }	
  
167	
  	
  	
  	
  	
  	
  	
  	
  FileUtils.close(br);	
  
168	
  	
  	
  	
  	
  	
  }	
  catch	  (IOException	
  e)	
  {	
  
169	
  	
  	
  	
  	
  	
  	
  	
  throw	  new	  BuildException(e);	
  
170	
  	
  	
  	
  	
  	
  }	
  
171	
  	
  	
  	
  }	

Figure 4.1: Actual modification that existing techniques cannot track clones
other techniques detect clones from the initial revision, then tracking the clones
using change histories stored in historical code repositories [5, 87, 143]. These
techniques are robust for modifications on clones. That means, they can extract
some links of clones that techniques based on textual similarities of clones miss.
However, they have a weak point that they cannot track clones that appeared during
the target period because they are interested in only clones that exist in the initialrevision.
Among these techniques that track clones across version histories, Clone Region Descriptor (in short CRD) based tracking is one of the best techniques. CRD
was proposed by Duala-Ekoko and Robillard [27], and it is an abstract form torepresent locational information of a clone. Clone tracking using CRDs is robust
for large modifications on clones compared to the other clone tracking techniques.
The reason is that the linking technique of clones with CRD is based on locationsof clones, not their textual similarities. The location-based linking enables to linkclones even if they were drastically modified between two revisions.
Even though CRD is a well-designed clone tracking technique, it still has aroom for improvement. This means that the CRD based tracking is not so robust forchanges that affect locations of clones. Figure 4.1 shows an actual example of code
modifications on which the existing CRD-based technique cannot work well, which
is found in Ant. In the figure, the hatched part is detected as a clone. In revision581,376, a try-block for catching JSchException was added outside of theclone. This modification also added a new parameter to the signature. In the CRDbased technique, blocks are tracked based on the nesting structures. Consequently,
the technique cannot regard that the else-block after the modification corresponds
to the else-block inside the new try-block. As a result, the clone is regarded as80

disappeared.
Tracking clones is a fundamental technique in the field of software evolution
because it should be a basis of a variety of research relating to software evolution.
Consequently, accurate and scalable clone tracking techniques are necessary forbetter results of research.
This study proposes another clone tracking technique based on CRDs. The proposed technique borrows the basic idea of the original CRD-based tracking, with
the idea enhanced. The key idea of the enhancement is to use similarities of CRDs,
not CRDs themselves. Using similarities of CRDs enables clone tracking to be robust compared to the original CRD, with detecting few false positives. In addition,
we have implemented a clone tracking system based on the proposed method. The
system includes a function to detect clones, which has a high scalability because
it is incremental and block-based. This study evaluates the correctness of clone
tracking of the proposed method, and also shows an application result of the proposed method for revealing why clones are gone in software evolution, which has
not been investigated yet.

4.2 Tracking clones
This section describes the proposed clone tracking technique. The primary
requirements for tracking clones are accuracy and speed. In order to achieve accurate and rapid clone tracking, the proposed technique uses incremental hash-based
clone detection. The processing of the proposed technique consists of two phases,hash generation and clone linking, each of which is described briefly as follows.
HASH GENERATION
Hash values are calculated from every block in source files in every revision.
If two or more blocks have the same hash value, they are regarded as clones.
All the hash values are stored into a database with their locational information such as file paths, start lines, and end lines. In addition, a CRD [27] ismeasured from every block, and it is also stored into the database.
CLONE LINKING
Cloned blocks in every revision are linked to blocks in its next revision basedon similarities of their CRDs. Then, their hash values are checked: if two
blocks having the same hash value (hr ) in revision r have also the samehash value (hr+1 ) in revision r + 1, they are regarded as maintaining a clone
relationship during r and r + 1 even if hr+1 is different from hr .
The remainder of this section firstly introduces the definition CRD with a simple example in Subsection 4.2.1. Secondly, it describes the processings of the phase81

<CRD> ::= <file> <class> <CM> [<method>]	
<method> ::= <signature> <block>*	
<block> ::= <btype> <anchor> <CM>	
<btype> ::= ‘for’ | ‘while’ | ‘do’ | ‘if’ | ‘else’ | ‘switch’ |	
‘try’ | ‘catch’ | ‘finally’ | ‘synchronized’	(a) Definition
public class DeleteManager {	…	public void delete (int n) {	…	
for(int i = n ; i < delete.size() ; i++ ) {	…	
if (delete.get(i) instanceof ElementNode) {	// some code	
}	
…
	

A

(b) Code situation

packagename.DeleteManager.java,DeleteManager,5	delete(int),5	
for,delete.size(),4	if,delete.get(i) instanceof ElementNode,2	(c) Example

Figure 4.2: Clone Region Descriptor“hash generation” in Subsection 4.2.2. Finally, it explains the processings of thephase “clone linking” in Subsection 4.2.3.
4.2.1 Clone Region Descriptor
CRD (, which is an abbreviation of Clone Region Descriptor) is an abstract
description for location of a clone region in a software system. A CRD provides anapproximate location of a clone. CRD is independent of specification of based onlines of source files. Figure 4.2 shows the definition and an example of CRD1 . Figure 4.2(a) shows the definition of CRD in the extended Backus-Naur form. Figure
4.2(c) shows an example of CRD, which represents the block labeled with “A” in
Figure 4.2(b). In the technique proposed by Duala-Ekoko and Robillard [27], if a
block in revision r has the same CRD as a block in revision r +1, they are regarded
1

These figures shows the same example used in the literature [27].

82as the same block. On the other hand, the proposed technique uses the similarities
of CRDs for clone tracking to improve the clone tracking based on CRDs.
4.2.2 Hash generation
The purpose of this step is to analyze source code in every revision in thetarget software system and to store the results into a database. The processingof this phase takes a repository of a target system as its input. From the given
repository, it extracts every block in all the source files of all the target revisions,calculates hash values and CRDs for all the extracted blocks, and store the resultof the calculation into a database. Thus, the output of this processing is a databasestoring all the blocks with hash values and CRDs. There are five steps in thisprocessing as follows.
STEP1 (Syntax Analysis) This step performs lexical and syntax analyses for all
the source files. Every source file is transformed into a sequence of tokens
through lexical analysis. After the lexical analysis, this step detects all theblocks from the sequences of tokens through syntax analysis. Note that thesyntax analysis is necessary because performing only lexical analysis is not
sufficient for identifying blocks from source files.
STEP2 (Splitting) Every subsequence of tokens corresponding to a block is extracted from the token sequences of the source files in this step. This step
puts a special token into the extracted position of token sequences that represents the information of the extracted block. The information described in
the special token includes the following information:• type of the block (e.g., if, while, for),• the conditional predicate (if the block is conditional one), and• parameters (if the block is method or constructor).
STEP3 (Normalization) This step normalizes token sequences to detect clones
even if they have some trivial differeces. In this normalization, variablenames and literals are replaced with special tokens. Note that invoked method
names and type names are not normalized. It is easy to distinguish types oftokens because syntax analysis performed in STEP1 provides type information of tokens. The type information enables to normalize only variablenames and literals.
STEP4 (Building block texts) This step builds a character sequence for every of
token sequences that represent blocks. A hash value is calculated from every83

of the character sequences with a hash function. A CRD is also calculated
from every of them in this step.
STEP5 (Persisting hash values) Hash values of all the blocks are stored into a
database. At the same time, file paths, start lines, end lines, revision numbers, and CRDs of every block are stored into the same database.
Figure 4.3 shows how source files are handled in every step. A remarkable
point of the processing “hash generation” is included in STEP2, which is a set ofoperations that every of the sub-blocks in a block is extracted, then a small marker
is put into every of the extracted positions. This operation enables to identify blocks
including the same instructions as clones even if their sub-blocks are different. If
a block is totally duplicated to another block, their hash values and all the hashvalues of their sub-blocks become the same.
4.2.3 Clone Linking
The input of the processing of this phase is an output of the processing “hashgeneration”, which is a database that contains hash values and other attributes of
all the blocks in all the target revisions. This phase links blocks in every revision
to blocks in the next revision.
Hash values of blocks are used for identifying clone relationships in every revision. The same hash value means that blocks having the hash value are texutually
identical except for differences in their sub-blocks, variable names, and literals.
In other words, blocks having the same hash value are regarded as clones. The
remainder of this paper uses a term Equivalent Block Group (in short, EBG),
which represents a group of blocks having the same hash value.
In this processing, the proposed technique identifies links of blocks between
revisions r and r + 1 based on the similarities of their CRDs. If block br in revisionr and block br+1 in revision r + 1 satisfy all the following conditions, br+1 isregarded as the corresponding block of block br .
CONDITION1 The type of br+1 is the same as the one of br .
CONDITION2 If br and br+1 are conditional blocks, their conditions are the same
except variable names, method names and literals in them.
CONDITION3 If br and br+1 are methods or constructors, their names are thesame or their parameters are the same.
CONDITION4 In revision r + 1, CRD of br+1 has the highest similarity with oneof br .
84	
 1:	 public	
 void	
 quicksort(int[]	
 array,	 int	
 left,	
 int	
 right){	
 
	
 2:	
 	
 	
 	
 	
 if	
 (left	 <=	
 right)	
 {	
 
	
 3:	
 	
 	
 	
 	
 	
 	
 	
 	
 int	
 p	
 =	
 array[(left+right)	
 /	
 2];	
 	
 
	
 4:	
 	
 	
 	
 	
 	
 	
 	
 	
 int	
 l	
 =	
 left;	
 	
 
	
 5:	
 	
 	
 	
 	
 	
 	
 	
 	
 int	
 r	
 =	
 right;	
 	
 
	
 6:	
 	
 	
 	
 	
 	
 	
 	
 	
 while(l	
 <=	
 r)	
 {	
 	
 
	
 7:	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 while(array[l]	
 <	
 p){	
 
	
 8:	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 l++;	
 	
 
	
 9:	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 }	
 	
 
10:	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 while(array[r]	
 >	
 p){	
 	
 
11:	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 r--;	
 	
 
12:	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 }	
 	
 
13:	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 if	
 (l	
 <=	
 r)	
 {	
 	
 
14:	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 int	
 tmp	
 =	
 array[l];	
 	
 
15:	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 array[l]	
 =	 array[r];	
 	
 
16:	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 array[r]	
 =	
 tmp;	
 	
 
17:	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 l++;	
 	
 
18:	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 r--;	
 	
 
19:	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 	
 }	
 
20:	
 	
 	
 	
 	
 	
 	
 	
 	
 }	
 	
 
21:	
 	
 	
 	
 	
 	
 	
 	
 	
 quickSort(array,	
 left,	
 r);	
 	
 
22:	
 	
 	
 	
 	
 	
 	
 	
 	
 quickSort(array,	
 l,	
 right);	
 	
 	
 
23:	
 	
 	
 	
 	
 }	
 
24:	
 }	
 	
 

STEP1	

1-24	

{

void	
 quicksort	 (IFleft<=right	

array	 ,	int[]	

int	

left	
 ,	

int	

void	
 quicksort	
 (

if	

left	

(

<=	

p

=

array	
 [

int	

l	
 =

left	
 ;	

int	

r

=

right	

;	

<=	

r

int	

2-23	

p

right	<=	=array	
 [

l	
 =

left	
 ;	

int	

r

right	

(

)

(

left	
 +

left	
 +

right	

array	 ,	 left	
 ,	
 r

)

{
<

p

)

{

l	

++	

;	
 }

r

]

>

p

)

{

r

--	

;	
 }

<=	

)

{

(

int	

l	
tmp	

r

=

array	 [l	
 ]array	
 [

l	
 ]

=

array	
 [array	
 [

r

=

tmp	

--	

;	

l	

++	

]

;	
 r

<=	

	
P2

]

array	 ,	 l	 ,	quicksort	 (array	 ,	 left	 ,	 r;	right	

)

;	

)

;	

}

token of block start	}token of block end	

)

/

2

]

{

right	

)
)

r

{

2-23	

;	

$

<=	

int	

$

=

$

[

int	

$

=

$

;	

int	

$

=

$

;	

(

$

)
$

WHILEarray[r]>p	

IFl<=r	

,	
 $

,	
 $

)

;	

$

,	
 $

,	
 $

)

;	

)

{

l	

++	

;	
 }

6-20	
 while	
 (

$

<=	

$

p

)

{

r

--	

;	
 }

7-9	
 while	
 (

$

[

$

]

l	

<=	

)

{

]

tmp	

=

}

10-12	
 while	
 (

tmp	

--	

;	
 }

int	

$

)

;	

[

$

$

$

<=	

$

)

WHILEarray[l]<p	

WHILEarray[r]>p	

<

{
$

)

{

$

++	

;	
 }

>

$

)

{

$

--	

;	
 }

IFl<=r	

}

;	
r

]

if	

;	

(

int	

;	

special token	

$

=

$

[

$

]

=

$

[

$

[

$

]

=

$

;	

$

++	

;	
 $

[

)

13-19	
 $

4	
EP
ST

$

--	

{
]

;	
$

]

;	

;	
 }

10	

1-24	
 publicvoidquicksort(int[]$,int$,int$){IFleft<=right}	

2-23	
 if($<=$){int$=$[($+$)/2];int$=$;int$=$;WHILEl<=rquicksort($,$,$);quicksort($,$,$);}	

20	

30	

6-20	
 while($<=$){WHILEarray[l]<pWHILEarray[r]>pIFl<=r}	

STEP5	

40	50	13-19	
 if($<=$){int$=$[$];$[$]=$[$];$[$]=$;$++;$--;}	

/

$

p

array	
 [

]

,	

}

>

=

2

)

quicksort	
 (

<

=

+

quicksort	
 (

]

l	
 ]

$

$

{

(

l	
 ]

r

int	

WHILEl<=r	;	

WHILEarray[l]<p	

l	
 ]

,	

;	

r

array	
 [int[]	
 $}array	
 [

r

)

void	
 quicksort	 (IFleft<=right	

array	
 [10-12	
 while($[$]>$){$--;}	

;	rquicksort	
 (7-9	
 while	 (7-9	
 while($[$]<$){$++;}	

{}10-12	
 while	
 (

;	
 r

)

}

STEP3	++	right	

;	

l	

l	

int	

;	

)

right	}]]

array	
 [6-20	
 while	 (array	
 [2

while	
 (if	array	 ,	 l	 ,	13-19	 array	
 [

/

)

l	
 ]

;	

quicksort	 ((right	

array	
 [{quicksort	
 (

if	

left	
 ,	

l	

WHILEl<=r	

int	

int	

}

int	

=

array	 ,	{while	 (public	
left	

(

)

while	
 (

1-24	
if	

int[]	

right	

int	

if	

E
ST
public	public	

60	

ID	

FileID	

CRD	

Hash	

StartLine	

EndLine	

1	

1	

………	

10	

1	

24	

StartRevision	
 EndRevision	
1	

………	

2	

1	

………	

20	

2	

23	

1	

………	

3	

1	

………	

30	

6	

20	

1	

………	

4	

1	

………	

40	

7	

9	

1	

………	

5	

1	

………	

50	

10	

12	

1	

………	

6	

1	

………	

60	

13	

19	

1	

………	

:	
:	

Figure 4.3: Intuitive example how hash values are measured from source code85

CONDITION5 In revision r, CRD of br has the highest similarity with one ofbr+1 .
The CRD similarity between blocks br and br+1 are measured by Levenshtein
Distance (in short, LD) of string representations of two CRDs calculated frombr and br+1 . If the two blocks have the identical CRDs, the LD between them
becomes 0, which is the minimum value of LD. If the two blocks have completely
different CRDs, the LD becomes maximum value, which is the higher value of thelengths of two string representations of two CRDs. Considering the similarity of
two CRDs enables to track clones even if they were moved.
Figure 4.4 shows examples of a revision history and a result of clone linking
from it. In Figure 4.4(a), the following modifications are performed.
• Method b2 in file B.java was changed (r1 → r2 )• Method a1 in file A.java was changed (r2 → r3 )• b2 was moved to file C.java (r2 → r3 )• Method c1 in C.java was deleted (r2 → r3 )• b1 in B.java was changed (r3 → r4 )In Figure 4.4(b), circles, arrows, and rectangles have the following meanings.
Circles: Every circle means a block. Numbers in blocks are their hash values.
Arrows: Every arrow means a link of two blocks between consecutive two revisions.
Rectanbles: Every rectangle means an EBG. All the blocks in a rectangle havethe same hash value.
For example, blocks a1 and b1 are modified between revisions r2 and r3 , sothat each of them has different hash values between the revisions. Even after themodification, they have the same hash value, which means that they continue to be
duplicated in revision r3 . However, between revisions r3 and r4 , only block b1 is
modified, and the two blocks have different hash values to each other in revision
r4 . Hence, the EBG consisting of a1 and b1 is regarded as disappeared in revisionr4 .
Blocks a2 and c1 have the same hash value in revisions r1 and r2 , which meansthat they consist of a clone in the revisions. However, in revision r3 , block c1
86

revision r1	

revision r2	

a1{	
  
	
  	
  	
  	
  …	
  
}	
  
A.java	
 a2{	
  
	
  	
  	
  	
  …	
  
}	
  

revision r3	

a1 was changed	

b1{	
  
	
  	
  	
  	
  …	
  
}	
  
B.java	
 b2{	
  
	
  	
  	
  	
  …	
  
}	
  

b2 wasmoved tob1{	  C.java	
 	
  	
  	
  	
  …	
  

b1{	
  

b2 was 	
  	
  	
  	
  …	
  
changed	
 }	
  
b2{	
  
	
  	
  	
  	
  …	
  
}	
  

c1{	
  
	
  	
  	
  	
  …	
  
}	
  
C.java	
 c2{	
  
	
  	
  	
  	
  …	
  
}	
  

revision r4	

a1{	
  
	
  	
  	
  	
  …	
  
}	
  
a2{	
  
	
  	
  	
  	
  …	
  
}	
  

b1 wasb1{	  changed	
 	
  	
  	
  	
  …	
  

}	
  

}	
  

c2{	
  
	
  	
  	
  	
  …	
  
}	
  
b2{	
  
	
  	
  	
  	
  …	
  
}	
  

c1 was deleted	(a) Revisions
revision r1	

revision r2	

revision r3	

revision r4	

block a1	

10	
  

10	
  

20	
  

20	
  

block b1	

10	
  

10	
  

20	
  

30	
  

block a2	

40	
  

40	
  

40	
  

40	
  

block c1	

40	
  

40	
  

block b2	

50	
  

60	
  

60	
  

60	
  

block c2	

60	
  

60	
  

60	
  

60	
  

n	
  

block whose hash value is n	
tracing result between two revisions	block whose hash value is n	(b) Tracking result

Figure 4.4: Example of clone tracking

87itself disappeared. In this case, the EBG consisting of a2 and c1 is regarded as
disappeared in revision r3 .
Blocks b2 and c2 have the different hash values in revision r1 . Block b2 ismodified between revisions r1 and r2 , so that they have the same hash value inrevision r2 . Even block b2 was moved to C.java in revision r3 , it can be tracked.
This is because the proposed method tracks cloned blocks based on similarities of
their CRDs.

4.3 Implementation
We have developed a software tool, CTEC based on the proposed technique.
Currently, CTEC handles only Java language. However, it is not difficult to expand CTEC to be able to handle other programming languages because it performs
only lexical and syntax analyses as language dependent processings. The language
dependent processing has been implemented with Java Development Tools [60].
CTEC uses SQLite as the database module because of its ease to use. Anyother database systems can take the place of SQLite. If we use other SQL databasesystems such as PostgreSQL or Oracle database, the analysis speed will become
more rapid. However, we believe that the speed with SQLite is sufficient.
In CTEC, the two processings “hash generation” and “clone linking” are implemented as independent ones. “Hash generation” registers hash values of blocks
in the target revisions into an SQL-based database. “Clone linking” takes the SQLbased database that the “hash generation” phase outputs, and identifies links ofblocks in the next revision for every cloned block in every revision with comparing
similarities of CRDs.
The remainder of this section describes each of the processings, respectively.
4.3.1 Hash generation
In order to achieve high scalability, CTEC adopts an incremental hash generation. The following is an explanation of “processing for the first revision” and“processing for the 2nd or later revisions”. This explanation is under an assumption that the target revisions are {r1 , r2 , · · · , rn }. Figure 4.5 describes an example
of initializing and updating a database.
In the processing for the first revision (r1 ), all the blocks in all the source files
in revision r1 are stored into an SQL database. Note that column “EndRevision” of
all the blocks are set as rn , which is the last revision of the target.
In the processing for the 2nd or later revision (rk , 2 ≤ k ≤ n), blocks in only
source files modified, added, and deleted in rk are stored into the database. If
88After analyzing revision r1	
ID	

FileID	

CRD	

Hash	

StartLine	

EndLine	A.java	

A.a1	

10	

1	

10	

StartRevisiorn	

EndRevision	

0	

1	

r4	

1	

A.java	

A.a2	

40	

11	

20	

r1	

r4	

2	

B.java	

B.b1	

10	

1	

10	

r1	

r4	

3	

B.java	

B.b2	

50	

11	

20	

r1	

r4	

4	

C.java	

C.c1	

40	

1	

10	

r1	

r4	

5	

C.java	

C.c2	

60	

11	

20	

r1	

r4	

After analyzing revision r2	
ID	

FileID	

CRD	

Hash	

StartLine	

EndLine	A.java	

A.a1	

10	

1	

10	

StartRevisiorn	

EndRevision	

0	

1	

r4	

1	

A.java	

A.a2	

40	

11	

20	

r1	

r4	

2	

B.java	

B.b1	

10	

1	

10	

r1	

r1	

3	

B.java	

B.b2	

50	

11	

20	

r1	

r1	

4	

C.java	

C.c1	

40	

1	

10	

r1	

r4	

5	

C.java	

C.c2	

60	

11	

20	

r1	

r4	

6	

B.java	

B.b1	

10	

1	

10	

r2	

r4	

7	

B.java	

B.b2	

60	

11	

20	

r2	

r4	

After analyzing revision r3	
ID	

FileID	

CRD	

Hash	

StartLine	

EndLine	A.java	

A.a1	

10	

1	

10	

StartRevisiorn	

EndRevision	

0	

1	

r2	

1	

A.java	

A.a2	

40	

11	

20	

r1	

r2	

2	

B.java	

B.b1	

10	

1	

10	

r1	

r1	

3	

B.java	

B.b2	

50	

11	

20	

r1	

r1	

4	

C.java	

B.b1	

40	

1	

10	

r1	

r2	

5	

C.java	

B.b2	

60	

11	

20	

r1	

r2	

6	

B.java	

B.b1	

10	

1	

10	

r2	

r2	

7	

B.java	

B.b2	

60	

11	

20	

r2	

r2	

8	

A.java	

A.a1	

20	

1	

10	

r3	

r4	

9	

A.java	

A.a2	

40	

11	

20	

r3	

r4	

10	

B.java	

B.b1	

20	

1	

10	

r3	

r4	

11	

C.java	

C.c2	

60	

1	

10	

r3	

r4	

12	

C.java	

C.b2	

60	

11	

20	

r3	

r4	

After analyzing revision r4	
ID	

FileID	

CRD	

Hash	

StartLine	

EndLine	A.java	

A.a1	

10	

1	

10	

StartRevisiorn	

EndRevision	

0	

1	

r2	

1	

A.java	

A.a2	

40	

11	

20	

r1	

r2	

2	

B.java	

B.b1	

10	

1	

10	

r1	

r1	

3	

B.java	

B.b2	

50	

11	

20	

r1	

r1	

4	

C.java	

B.b1	

40	

1	

10	

r1	

r2	

5	

C.java	

B.b2	

60	

11	

20	

r1	

r2	

6	

B.java	

B.b1	

10	

1	

10	

r2	

r2	

7	

B.java	

B.b2	

60	

11	

20	

r2	

r2	

8	

A.java	

A.a1	

20	

1	

10	

r3	

r4	

9	

A.java	

A.a2	

40	

11	

20	

r3	

r4	

10	

B.java	

B.b1	

20	

1	

10	

r3	

r3	

11	

C.java	

C.c2	

60	

1	

10	

r3	

r4	

12	

C.java	

C.b2	

60	

11	

20	

r3	

r4	

13	

B.java	

B.b1	

30	

1	

10	

r4	

r4	

Figure 4.5: Example of Database Updating89

the database already includes blocks in the files, their columns “EndRevision” areupdated to rk−1 .
The following explanation uses the example shown in Figure 4.5 to describe
how these processings work with. This example shows how database is updated
for revisions shown in Figure 4.4. Figure 4.5 shows the database content after theprocessing for every revision. Gray cells mean that they have just been inserted or
updated. Note that, in this example, column “FileID” contains file names for easeto explain. However, in the actual implementation, column “FileID” includes IDs
for source files. CTEC has another database table for mapping file name and its ID.
In the processing for revision r1 , which is the first revision of the target, all thesource files are analyzed and their blocks are stored into the database. Note thatthe values of column “EndRevision” of their blocks become r4 , which is the last
revision of the target.
In the processing for revision r2 , file B.java is reanalyzed, and its blocks are
stored into the database. The reason why only file B.java is reanalyzed is that
only file B.java is modified between revisions r1 and r2 . In this case, the databasealready has blocks in file B.java, and so their columns “EndRevision” are updated
to r1 . This updating operation is performed for only blocks whose “EndRevision”
are r4 .
In revision r3 , files A.java, B.java, and C.java are modified. Hence, the processing for those files in revision r3 is performed as well as the processing for fileB.java in revision r2 . Note that the rows whose “ID” values are 2 and 3 are nolonger updated even though their owner file B.java is modified. This is because thevalues of “EndRevision” in these rows are not r4 .
In a similar way, the processing for revision r4 analyzes file B.java, inserts
newly detected blocks into the database, and updates the column “EndRevision” at
the row whose “ID” is 10.
4.3.2 Clone Linking
In order to link cloned blocks in every revision to corresponding blocks in thenext revision (rk and rk+1 ), it is necessary to obtain EBGs in revision rk from thegiven database. The followings describe the steps to obtain EBGs in revision rk .
STEP1 obtaining records (blocks) satisfying the following formula. This operation means obtaining all the blocks existing in rk .

(StartRevision ≤ rk )90∧

(rk ≤ EndRevision)(4.1)

STEP2 classifying the blocks obtained in the STEP1 based on their hash values.
Two or more blocks having the same hash value form an EBG.
For each block in the EBGs identified in the STEP2, its corresponding block
is found with the proposed technique described in Subsection 4.2.3.

4.4 ExperimentThis section describes the result of an experiment on well-known systems withthe proposed clone tracking technique. The purpose of this experiment is confirming that the proposed technique has a beneficial effect on tracking clones. In orderto achieve the purpose, this experiment has investigated tracking results in the way
to answer the following questions.
QUESTION1 Could the proposed technique track clones that the conventional
technique could not track?
QUESTION2 Did clones that the proposed technique could not track really disappear?
Firstly, this section describes the experimental setup, then shows the performance of CTEC. Lastly, it provides answers for our research questions.
4.4.1 Setup
We selected Ant and ArgoUML as the targets of this experiment. Tables 4.1 and4.2 show an overview of the target systems. They are managed by using Subversion(in short, SVN) The targets of the investigation are the source code under directory

Table 4.1: Overview of Target Software - Target Revisions Software
Start revision (date)
End revision (date) # of target revisions
ArgoUML
15,880 (2008-10-04)
19,794 (2011-11-17)
2,222
Ant
268,587 (2001-02-05) 904,537 (2010-01-30)
5,143
Table 4.2: Overview of Target Software - LOC Software LOC of start revision LOC of end revision
ArgoUML
329,170
362,604
Ant
57,124
211,855
91

“/ant/core/trunk/src/main” and “/trunk/src”, respectively. This experiment is interested only in the source code under the directories “trunk”, which is the main lineof the development in SVN repositories. This experiment also narrows down theexperimental target to particular subdirectories of “trunk” to exclude test files. The
target period of the investigation was carefully decided because we would like toinvestigate development histories of multiple versions.
In this experiment, we specified 30 tokens as the threshold of minimum clone
length. If and only if a block includes 30 or more tokens, it can be stored into
databases and can be a member of a code clone. On the other hand, blocks including less than 30 tokens will be ignored, and so they are not inserted into the
database.
4.4.2 Performance
Table 4.3 shows the performance of two processings, “hash generation” and“clone linking”, from the view point of the elapsed time. A processing “hash generation’ consists of the analysis on all the target revisions of a target software system. Hence, the processing “hash generation” was performed only once on eachof the experimental targets. On the other hand, a processing “clone linking” means
analyzing a pair of two consecutive revisions. Therefore, “clone linking” needs tobe performed multiple times, the number of pairs of two consecutive revisions, oneach of the experimental targets. The table shows total, maximum, minimum, andaverage time of “clone linking”. We can see that maximum time is 46 seconds,
which means that CTEC can perform a processing “clone linking” interactively on
demand from users. In the case of batch executions, CTEC takes a few hours toanalyze several thousand of revisions. Considering the elapsed time shown in thetable, it can be said that CTEC works very well in the point of scalability.
4.4.3 Answer to QUESTION1
We tracked clones by using the proposed technique and a conventional technique proposed by Duala-Ekoko and Robillard [27]. The conventional technique
has been implemented by us based on the description of the paper of Duala-Ekoko

Table 4.3: Timing information on experiment (execution with eight threads)
Clone linking
Software Hash generation
total
max.
min.
ave.
ArgoUML
132 mins. 43 mins. 46.0 secs. 0.043 secs. 21.3 secs.
Ant
100 mins. 50 mins. 31.2 secs.
2.8 secs. 17.1 secs.
92

conven-onal	
  method	
  

0.28	

20	
  

0.30	

proposed	
  method	
  

0.32	

0.34	

18	
  
16	
  
14	
  
12	
  
10	
  
8	
  
6	
  
4	
  
2	
  
0	
  

15,880	

17,148	

18,179	
 18,964	

19,794	

(a) ArgoUML

20	
  

1.4	

conven-onal	
  method	
  proposed	
  method	
  

1.6	

1.7	

1.5	

1.8	

18	
  
16	
  
14	
  
12	
  
10	
  
8	
  
6	
  
4	
  
2	
  
0	
  

268,587	
269,531	
272,632	

275,279	

554,389	
904,537	(b) Ant

Figure 4.6: Number of blocks that were not tracked by the proposed or conventional methods

and Robillard. In the whole of the target period, the number of untrackable clonesof the proposed technique and the conventional technique is 345 and 581 in Ant,and 537 and 739 in ArgoUML, respectively. There exists no clones that the conventional technique tracked but the proposed technique could not. That is, 236 and202 clones were tracked only by the proposed technique, respectively.
Figure 4.6 shows the number of clones that did not tracked by the proposed orconventional techniques in every revision. Clones not tracked by the conventional
93

technique are colored red, and ones not tracked by the proposed technique arecolored black. Every black bar is drawn in front of red ones. If a red bar is taller
than its corresponding black bar, there are clones that were tracked only by the
proposed technique. The length of difference between red and black bars means
the number of such clones. Again, there exists no clones that the conventional
technique tracked but the proposed technique could not. Therefore, no black bar istaller than its corresponding red bar.
We investigated clones tracked only by the proposed technique to reveal whether
tracking by the proposed technique had been correct or not. This was a manual
investigation, so that we narrowed down period “1.8” in Ant and “0.32” in ArgoUML. In this investigation, we checked what kinds of modifications were performed in both the cases that tracking was correct and not correct. The following
is a list of kinds of modifications. Prefix “T” means that tracking was correct even
if the modifications were performed and “F” means that tracking was incorrect
because of the modifications.
T1 Clones (and their surrounding code) were extracted as new methods.
T2 New blocks were added as surrounding code of clones such as null checking.
T3 Conditional predicates on conditional blocks including clones were changed.
T4 Methods including clones were moved to other classes.
T5 New catch clauses were added on try blocks including clones. In the CRD
definition of try-block, it includes exception types of catch clauses attachedto the try-block [27]. Consequently, if a new catch clause is added to a try
block, CRD of the try block changes.
T6 Methods were inlined to other methods.
F1 Cloned blocks were deleted. As a result, other blocks in the next revision wereincorrectly linked to the deleted blocks.
F2 Cloned block became smaller than the threshold (30 tokens). Smaller blocks
than the threshold are not registered to the database. They are treated as thesame as deleted blocks. As a result, incorrect linking happened.
Figure 4.7 shows actual clones classified into T1. In this case, cloned ifblocks and their subsequent code were extracted as new methods. Such modifications change CRDs of cloned if-blocks, hence the conventional technique misses
the links of clones. Therefore, this clone is regarded as disappeared if we use the
94

459	
  	
  	
  	
  */	
  
460	
  	
  public	  synchronized	
  void	  createStreams()	
  {	
  
461	
  	
  	
  	
  if	
  (out	
  !=	
  null	  &&	
  out.length	
  >	
  0)	
  {	
  
462	
  	
  	
  	
  	
  	
  String	
  logHead	
  =	
  new	  StringBuffer("Output	
  ").append(	
  
463	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  ((append)	
  ?	
  "appended"	
  :	
  "redirected")).append(	
  
464	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  "	
  to	
  ").toString();	
  
465	
  	
  	
  	
  	
  	
  outputStream	
  =	
  foldFiles(out,	
  logHead,	  Project.MSG_VERBOSE);	
  
466	
  	
  	
  	
  }	
  
467	
  	
  	
  	
  if	
  (outputProperty	
  !=	
  null)	
  {	
  
	
  
...	
  	
  	
  	
  	
  	
  ...	
  
	
  
479	
  	
  	
  	
  }	
  
480	
  
481	
  	
  	
  	
  if	
  (error	
  !=	
  null	
  &&	
  error.length	
  >	
  0)	
  {	
  
482	
  	
  	
  	
  	
  	
  String	
  logHead	
  =	
  new	  StringBuffer("Error	  ").append(	
  
483	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  ((append)	
  ?	
  "appended"	
  :	
  "redirected")).append(	
  
484	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  "	
  to	
  ").toString();	
  
485	
  	
  	
  	
  	
  	
  errorStream	
  =	
  foldFiles(error,	
  logHead,	  Project.MSG_VERBOSE);	
  
486	
  	
  	
  	
  }	
  else	  if	
  (!(logError	
  ||	
  outputStream	
  ==	
  null))	
  {	
  
	
  
...	
  	
  	
  	
  	
  	
  ...	
  
	
  
510	
  	
  	
  	
  }	
  
511	
  	
  	
  	
  if	
  (alwaysLog	
  ||	
  outputStream	
  ==	
  null)	
  {	
  
	
  
...	
  	
  	
  	
  	
  	
  ...	  (a) Before modification (revision 567,592)
459	
  	
  	
  	
  */	
  
460	
  	
  public	  synchronized	
  void	  createStreams()	
  {	
  
461	
  	
  	
  	
  outStreams();	
  
462	
  	
  	
  	
  errorStreams();	
  
463	
  	
  	
  	
  if	
  (alwaysLog	
  ||	
  outputStream	
  ==	
  null)	
  {	
  
	
  
...	
  	
  	
  	
  	
  	
  ...	
  
	
  
573	
  	
  }	
  
574	
  
575	
  	
  /**	
  outStreams	
  */	
  
576	
  	
  private	
  void	  outStreams()	
  {	
  
577	
  	
  	
  	
  if	
  (out	
  !=	
  null	  &&	
  out.length	
  >	
  0)	
  {	
  
578	
  	
  	
  	
  	
  	
  String	
  logHead	
  =	
  new	  StringBuffer("Output	
  ").append(	
  
579	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  ((append)	
  ?	
  "appended"	
  :	
  "redirected")).append(	
  
580	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  "	
  to	
  ").toString();	
  
581	
  	
  	
  	
  	
  	
  outputStream	
  =	
  foldFiles(out,	
  logHead,	  Project.MSG_VERBOSE);	
  
582	
  	
  	
  	
  }	
  
583	
  	
  	
  	
  if	
  (outputProperty	
  !=	
  null)	
  {	
  
	
  
...	
  	
  	
  	
  ...	
  
	
  
595	
  	
  	
  	
  }	
  
596	
  	
  }	
  
597	
  
598	
  	
  private	
  void	  errorStreams()	
  {	
  
599	
  	
  	
  	
  if	
  (error	
  !=	
  null	
  &&	
  error.length	
  >	
  0)	
  {	
  
600	
  	
  	
  	
  	
  	
  String	
  logHead	
  =	
  new	  StringBuffer("Error	  ").append(	
  
601	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  ((append)	
  ?	
  "appended"	
  :	
  "redirected")).append(	
  
602	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  "	
  to	
  ").toString();	
  
603	
  	
  	
  	
  	
  	
  errorStream	
  =	
  foldFiles(error,	
  logHead,	  Project.MSG_VERBOSE);	
  
604	
  	
  	
  	
  }	
  else	  if	
  (!(logError	
  ||	
  outputStream	
  ==	
  null))	
  {	
  
	
  
...	
  	
  	
  	
  ...	
  
	
  
628	
  	
  	
  	
  }	
  
629	
  	
  }	
  

(b) After modification (revision 567,593)

Figure 4.7: An EBG that only the proposed method tracked95

conventional technique. On the other hand, the proposed technique could continue
to track these blocks.
Table 4.4 shows the number of clones fallen into each category. The number ofcorrect tracking is 40, and the number of incorrect is only four. That is, the accuracyof tracking for clones that were tracked only the proposed technique becomes about
91%.
4.4.4 Answer to QUESTION2
We investigated whether clones not tracked by the proposed technique had really disappeared. We conducted a manual investigation on period “1.8” in Ant and“0.32” in ArgoUML as well as the investigation for QUESTION1. As a result, werevealed the following modifications were factors that clones were not tracked by
the proposed technique. Note that prefixes “T” and “F” mean correct and incorrect
tracking respectively, as well as the investigation for QUESTION1.
T1 Cloned blocks existed after modifications. However, their sizes became smaller
than the threshold (30 tokens), so that they were regard as disappeared by the
proposed technique.
T2 Cloned blocks (and their surrounding code) were deleted from the source code.
T3 Cloned blocks evolved to different code by large modifications.
F1 Types appearing in conditions of cloned blocks were changed. In the proposed
method, variable names, method names, and literals are normalized but types

Table 4.4: Modification types that the proposed technique could track
category
Ant ArgoUML
T tracking was appropriate
37
3
T1 extracting as new methods
18
0
T2 becoming deeper nested
90
T3 changing block’s conditions
5
2
T4 moving methods
2
1
T5 adding new catch clauses
20
T6 in-lined to other methods
10
F tracking was NOT appropriate
40
F1 deleting blocks
30
F2 shrinking blocks
1
096

ExecuteOn.java (revision 668,723)	
425	
  	
  File	  base	  =	
  null;	
  revision 668,724	
426	
  	
  String	  name	  =	
  res.getName();	
  res	
  instanceof	  FileProvider	
427	
  	
  if	
  (res	  instanceof	  FileResource)	
  {	
  
428	
  	
  	
  	
  FileResource	
  fr	
  =	
  (FileResource)	
  res;	
  
429	
  	
  	
  	
  base	  =	
  fr.getBaseDir();	
  
430	
  	
  	
  	
  if	
  (base	
  ==	
  null)	
  {	
  
431	
  	
  	
  	
  	
  	
  name	  =	
  fr.getFile().getAbsolutePath();	
  
432	
  	
  	
  	
  }	
  
433	
  	
  }	
  
434	
  
435	
  	
  if	
  (restrict(new	  String[]	
  {name},	
  base).length	
  ==	
  0)	
  {	
XSLTProcess.java (revision 668,723)	
592	
  	
  	
  	
  File	  base	  =	
  baseDir;	
  revision 668,724	
593	
  	
  	
  	
  String	  name	  =	
  r.getName();	
  
594	
  	
  	
  	
  if	
  (r	
  instanceof	  FileResource)	
  {	
  
r	
  instanceof	  FileProvider	
595	
  	
  	
  	
  	
  	
  FileResource	
  f	
  =	
  (FileResource)	
  r;	
  
596	
  	
  	
  	
  	
  	
  base	  =	
  f.getBaseDir();	
  
597	
  	
  	
  	
  	
  	
  if	
  (base	
  ==	
  null)	
  {	
  
598	
  	
  	
  	
  	
  	
  	
  	
  name	  =	
  f.getFile().getAbsolutePath();	
  
599	
  	
  	
  	
  	
  	
  }	
  
600	
  	
  	
  	
  }	
  
601	
  	
  	
  	
  process(base,	
  name,	  destDir,	
  stylesheet);	
  
602	
  	
  }	

Figure 4.8: Cloned blocks not tracked by the proposed method because types intheir conditions were changed
are not. Consequently, changes of types makes CONDITION2 unsatisfied,
which makes a failuer of tracking.
F2 Conditions of cloned blocks were changed. This kind of change makes CONDITION2 unsatisfied.
F3 New catch clauses were added to cloned try blocks. Such modifications make
CONDITION2 unsatisfied.
Figure 4.8 shows an actual instance of untracked clones found in Ant becauseof a type in its condition (F1). In revision 688,724, FileResource was changed
to FileProvider in the condition of the cloned block. If the proposed technique was designed to normalize types in conditions of clone blocks, this clones
would tracked correctly. However, the more normalized conditions are, the moreincorrectly blocks will be tracked.
Figure 4.9 shows another example of clones not tracked by the proposed technique (F2), which is also found in Ant. The change performed in this example
is larger than the one in Figure 4.8. In order to track clones even if this kind oflarge modifications were performed on conditions of cloned block, CONDITION2
97

ExecuteOn.java (revision 718,386)	
427	
  	
  File	  base	  =	
  null;	
  revision 718,387	
428	
  	
  String	  name	  =	
  res.getName();	
  
429	
  	
  if	
  (res	  instanceof	  FileProvider)	
  {	
   fp	  !=	  null	
430	
  	
  	
  	
  FileResource	
  fr	
  =ResourceUtils.asFileResource((FileProvider)res);	
  
431	
  	
  	
  	
  base	  =	
  fr.getBaseDir();	
  
432	
  	
  	
  	
  if	
  (base	
  ==	
  null)	
  {	
  
433	
  	
  	
  	
  	
  	
  name	  =	
  fr.getFile().getAbsolutePath();	
  
434	
  	
  	
  	
  }	
  
435	
  	
  }	
  
436	
  
XSLTProcess.java (revision 718,386)	
593	
  	
  	
  	
  File	  base	  =	
  baseDir;	
  revision 718,387	
594	
  	
  	
  	
  String	  name	  =	
  r.getName();	
  
595	
  	
  	
  	
  if	
  (r	
  instanceof	  FileProvider)	
  {	
   fp	  !=	  null	
596	
  	
  	
  	
  	
  	
  FileResource	
  f	
  =	
  ResourceUtils.asFileResource((FileProvider)	
  r);	
  
597	
  	
  	
  	
  	
  	
  base	  =	
  f.getBaseDir();	
  
598	
  	
  	
  	
  	
  	
  if	
  (base	
  ==	
  null)	
  {	
  
599	
  	
  	
  	
  	
  	
  	
  	
  name	  =	
  f.getFile().getAbsolutePath();	
  
600	
  	
  	
  	
  	
  	
  }	
  
601	
  	
  	
  	
  }	
  
602	
  	
  	
  	
  process(base,	
  name,	  destDir,	
  stylesheet);	
  
603	
  	
  }	

Figure 4.9: Cloned blocks not tracked by the proposed method because their conditions were changed
must become much weaker or even be removed. However, such changes on CONDITION2 will yield much more incorrect tracking. Consequently, tracking clones
correctly even if their conditions are largely changed is not realistic on CRD-based
clone tracking approaches.
Table 4.5 shows the number of clones not tracked by the proposed technique
because of such modifications. We manually investigated 61 untracked clones,
and 56 out of them were correct. That is, accuracy of untracking of the proposed
technique is about 92%.

4.5 Revealing why clones are gone
As an application of the proposed technique, we investigated why clones aregone in software evolution2 . In the past, several studies investigated occurrencesand evolutions of clones [74, 78, 93, 121]: however there is no research focusing
on investigation of reasons why clones are gone. Several empirical investigations
on clones found that a part of clones was gone in software evolution [78, 121].
2

In this application, we investigated why clone relationships among blocks had disappeared. On
the other hand, the experiment described in Section 4.4 focuses on tracking each cloned block98

However, in those investigations, clone removal is a pattern of clone evolution.
They did not investigate why clones were gone.
This investigation was also conducted on Ant and ArgoUML. Figure 4.10 shows
the number of EBGs whose elements disappeared in every revisions. As shown inthis figure, clone are gone in every time of software evolution.
In order to reveal the reasons why clones are gone, we investigated disappeared
EBGs manually. We narrowed the target periods of this manual inspection because
investigating all the disappeared EBGs is not realistic. Herein, we investigated
all the disappeared EBGs in periods “0.32” of ArgoUML (see Figure 4.10(a)) and“1.8” of Ant (see Figure 4.10(b)) as well as the manual inspections conducted in
the experiment described in section 4.4. The number of investigated EBGs are 43
and 37, respectively. Table 4.6 summarizes the investigation result.
The number of disappeared EBGs due to refactoring is 10 and 7, respectively.
However, some of those refactorings were not intended for removing duplicate
code. We found that the other intentions were shortening long methods or simplifying complicated methods. Most of refactoring that caused disappearances ofTable 4.5: Moditications preventing the proposed method from tracking clones
category
Ant ArgoUML
T not tracking was appropriate
23
33
T1 shrinking blocks
7
9
T2 deleting blocks
824
T3 changing blocks
80
F not tracking was NOT appropriate
50
F1 changing Types in block’s conditions
20
F2 changing block’s conditions
20
F3 adding catch clauses to try blocks
10

Table 4.6: Reasons why clones were gone
ReasonArgoUML
Ant
Refactoring
10 (9) 7 (3)Different evolution
6
11
Unintended inconsistency
15
10
Unneeded code deletion
8
5
Shrinking
40
CRD limitation
0
3
Total
43
36
99

0.28	

20	
  

0.30	
 0.32	

0.34	

18	
  
16	
  
14	
  
12	
  
10	
  
8	
  
6	
  
4	
  
2	
  
0	
  

15,880	

17,148	

18,179	
 18,964	

19,794	

(a) ArgoUML
20	
  

1.4	

1.5	

1.6	

1.7	

1.8	

18	
  
16	
  
14	
  
12	
  
10	
  
8	
  
6	
  
4	
  
2	
  
0	
  

268,587	
269,531	
272,632	

275,279	

554,389	
904,537	(b) Ant

Figure 4.10: Number of EBGs whose elements disappearedclones were Extract Method pattern. As a result of refactorings, CONDITION2
became unsatisfied, so that EBGs could not be tracked.
Different evolution means that, different modifications (e.g., functionality enhancements or expansions) were applied to one or more blocks in an EBG, so thatthey evolved differently. We classified 6 and 11 EBGs into this category.
Unintended inconsistency means that clones were gone unintentionally. For
example, incomplete simultaneous modifications for bug fix or error checking wereclassified into this category. Disappearances of clones by these reasons will cause
100PropertySet.java (revision 671,017)	
265	
  	
  Hashtable	
  ret	  =	  new	  Hashtable();	
  266 for	
  (Enumeration	
  e	
  =	
  System.getProperties().propertyNames();	
  
267	
  	
  	
  	
  e.hasMoreElements();)	
  {	
  
268	
  	
  	
  	
  String	  name	  =	
  (String)	
  e.nextElement();	
  
269	
  	
  	
  	
  ret.put(name,	
  System.getProperties().getProperty(name));	
  
270	
  	
  }	
  
271	
  	
  return	
  ret;	  CommandlineJava.java (revision 671,017)	
140	
  	
  Properties	
  p	
  =	
  new	
  Properties();	
  
141	
  	
  for	
  (Enumeration	
  e	
  =	
  sys.propertyNames();	
  e.hasMoreElements();)	
  {	
  
142	
  	
  	
  	
  String	  name	  =	
  (String)	
  e.nextElement();	
  
143	
  	
  	
  	
  p.put(name,	
  sys.getProperty(name));	
  
144	
  	
  }	
  
145	
  	
  p.putAll(mergePropertySets());	
  revision 671,018	
String	  value	
  =	
  sys.getProperty(name);	
  if	
  (name	  !=	
  null	
  &&	
  value	
  !=	
  null)	
  {	
  
	
  	
  	
  	
  p.put(name,	
  value);	  }	

Figure 4.11: Code where an unintended inconsistency occurred

maintenance problems because they have high risks to introduce or to remain bugs.
In this investigation, 15 and 10 EBGs were classified into this category. Figure
4.11 shows actual code of this category. This EBG consists of two blocks, which
are different source files. Only one of them was modified (null checking code wasadded) in revision 671,018. However, those two blocks are logically the same. The
null checking must be added to the other code simultaneously.
Unneeded code deletion means EBGs were gone by deleting unneeded code.
We investigated commit logs for deciding whether the commits were for deleting
unneeded code or not. We classified 8 and 5 EBGs into this category.
Shrinking means the size of blocks in EBGs becomes smaller than the threshold of minimum clone size to be detected. All the blocks consisting of an EBG
continue to be duplicated: however their size became smaller than the threshold byconsistency modifications. In consequent, they are not detected as clones after themodifications. In this investigation, four EBGs in ArgoUML were classified into
this category.
CRD limitation means EBGs are judged as disappeared because tracking was
performed incorrectly. In this investigation, three EBGs in Ant were classified into
this category.
1014.6 Threats To Validity
EBGs categorization
In this experiment, we conducted manual investigations on open source systems. However, the investigation result may not be correct entirely because theauthors are not developers of the target systems. In order to eliminate incorrectness as much as possible, two of the authors performed the investigation together.
Totally, we spent approximately 10 hours for the categorizations.
Target systems
In this experiment, we targeted only two system written in Java. Currently,
it is difficult to generalize the investigation result because (1) only one programming language was investigated and (2) the number of investigated systems is only
two. We selected ArgoUML and Ant as our targets because they are popular andsuccessful systems. However, if we selected other systems that are no more thanmoderately successful, the investigation results may be different from this experiment. In addition, a further investigation on industrial software systems is required
to generalize the experimental results on industrial software systems. This is because industrial software systems should have different characteristics comparedto open source software systems.
Clone detection
This study adopted a block-based clone detection technique. The block-based
approach enables CTEC to find clones rapidly. However, the block-based detector should miss clones that detectors based on other approaches can find. Our
first experiment, which validates the accuracy of clone tracking with the proposed
technique, never be affected by this factor because it did not use information ofcode clones: it only uses links of blocks. However, the experiment on investigating why clones are gone will be affected by this factor. That is, using different
clone detectors should introduce different results. However, it is difficult to use
other fine-grained clone detectors such as text-based or token-based techniques inthe experiment because the experiment forces the detectors to run a few thousand
times.

4.7 Summary
This study proposed a technique for tracking clones in software evolution. The
proposed technique is an enhanced version of the CRD-based clone tracking. The
102

proposed technique includes incremental hash-based clone detection for realizing
rapid clone tracking. We conducted experiments on open source systems and confirmed the followings.
• The proposed technique tracked many clones that were not tracked by a conventional technique. The correctness of tracking such clones was 91%.
• In the experiment, many clones were not tracked by even the proposed technique. The untracking correctness for such clones was 92%.
Moreover, we investigated why clones are gone with the proposed technique.
We revealed that refactoring, different evolution, and unintended inconsistencies
are major factors of clone disappearing. Interestingly, some of the refactorings
were not intended for removing duplicate code but shortening long methods orsimplifying complicated methods.

103

Chapter 5

Analyzing Clone Genealogies
with the Enhanced Clone
Tracking
5.1 Motivation
As discussed in Chapter 4, the research area of code clones still has some open
issues even though many researchers have analyzed code clones to reveal characteristics of them. Concretely, the following questions have not been revealed eventhough they play fundamental roles on effecient management of clones.
• How many clones have negative impacts on software evolution?
• Do long-lived clones tend to be modified more frequently than short-lived
ones?
• Are there any characteristics when clones are modified in their lifetime?
To answer the first question is quite important to decide how many costs weshould pay to manage code clones. If there are many negative clones, softwaresystems should require many costs to manage code clones. On the other hand, if
there are few negative clones, paying too much attention on clones might be notcost-effective.
The answer to the second question should be useful to consider negative clones.
If it is the case that long-lived clones tend to be modified more frequently thanshort-lived ones, it will be efficient to focus on long-lived clones. However, it will
not be enough to detect long-lived clones if the above theory does not hold. This is105because clones will not require much attention if they are stable regardless of thelength of their lifetimes.
Answering the third question will guide when we should start managementof clones. If clones tend to be modified in the earlier periods of their lifetimes,
managing clones in the earlier periods will be necessary. In addition, if clones tend
to become more stable in the latter period, it is not cost-effective to manage clones
after a certain period of time elapsed from their creation.
To reveal the above open questions, we conduct an empirical study on six open
source software systems. The experiment analyzes clone genealogies detected withthe enhanced CRD-based clone tracking, which is described in Chapter 4, to trackcode clones across version histories of code. Using the enhanced technique enables
to overcome shortcomings of existing clone tracking techniques.
The empirical study that this chapter presents mainly has the following twocontributions.
Revisiting Common Findings on Clone Evolution
Many researchers have analyzed evolution of clones, which offers many interesting findings. However, existing studies used their own techniques totrack clones. As discussed above, these clone tracking techniques have someissues, and so it is not obvious that their findings still hold with more intelligent ways to track clones. Therefore, this study revisits the common findings
on clone evolution with the enhanced CRD-based tracking. We select two
findings as our revisiting target, both of the two have great influences on the
research area of clones.
Answering Open Issues
This study analyzes clone genealogies detected with the enhanced techniqueto answer the above questions. The experimental results offer answers to thequestions, and it also shows how important selecting clones to be managed
carefully is.

5.2 Research Questions
The study that this chapter presents has two objectives as follows.
• Revisiting common findings on characteristics of clones with a clone tracking technique that has a high change-tolerance.
• Revealing some open issues about lifetime and the number of modificationsof clones.
106

We investigate the following five research questions to achieve the above objectives.
RQ1: Does the finding ‘most of clones are short-lived’ hold as well as Kim et al.
reported in the literature [78]?
RQ2: Does the finding ‘there is a few clones that are modified multiple times’
hold as well as Göde and Koschke reported in the literature [35]?
RQ3: Are there many long-lived clones that are modified multiple times?
RQ4: Is there a positive correlation between the length of clones’ lifetime and thenumber of modifications applied to them?
RQ5: Do clones tend to be modified more frequently in the former half of their
lifetimes than the latter one?

5.3 Detecing Clone Genealogies
This section describes definitions of code clone and clone genealogy in thisstudy at first. Explanations of some terms relating to clone genealogies and an
example of clone genealogies follow the definitions.
5.3.1 Detection of Code Clones
This study selects a block-based clone detector among a variety of clone detectors for its clone detection. The reason of this is that this study needs high scalability for its clone detection because it imposes its clone detectors on running every
revision of the target software systems. In addition to that, block-based clones arecompatible with our CRD-based clone tracking because CRDs are calculated onblocks.
More concretely, this study uses the clone detection technique described in
section 4.2 in Chapter 4. This detector finds clones by comparing hash values
created from string representations of blocks after normalized.
5.3.2 Definition of Clone Genealogy
This subsection offers the definition of clone genealogy in this study. The
following explanations assume that every revision has a unique number (revision
number) for its identification. In addition, they also assume that the revision numbers of contiguous revisions are also contiguous.
At the beginning, we define clone sets in formal.
107

Definition 5.3.1 (Clone Set). Let Br be a set of blocks in revision r, and hash(b)be the hash value of the given block b. If a set of blocks c satisfies both of thefollowing two forumlae (5.1) and (5.2), c is defined as a clone set.
∀bα , bβ ∈ c[hash(bα ) = hash(bβ )](5.1)∀bα ∈ c, ∀bβ ∈ Br [(hash(bα ) = hash(bβ )) → bβ ∈ c]

(5.2)

The remainder of this section represents a set of all the clone sets in revision r
as Cr .
The next defines correspondence relationships of blocks and clone sets between
two contiguous revisions
Definition 5.3.2 (Correpondence Relationship of Blocks). Let br and br+1 be blocks
in revision r and revision r + 1, respectively. This study regards that br and br+1
are under a correspondence relationship of blocks if they are linked with the enhanced CRD-based clone tracking. The remainder of this section uses the symbol↔ to represent the correspondence relationship of blocks. For instance, br ↔ br+1
means that br and br+1 are under a correspondence relationship of blocks.
Definition 5.3.3 (Correspondence Relationship of Clone Sets). Consider two clone
sets cr and cr+1 , and assume that cr is in revision r and cr+1 is in revision r + 1.
This study regards that cr and cr+1 are under a correspondence relationship ofclone sets if the following formula (5.3) holds.
∃br ∈ cr , ∃br+1 ∈ cr+1 [br ↔ br+1 ](5.3)

The remainder of this section uses the symbol ⇔ to represent the correspondence relationship of clone sets, as well as those of blocks.
Using these definitions, a clone genealogy is defined as follows.
Definition 5.3.4 (Clone Genealogy). Let CALL be a set consisting of all the clone
sets that are detected in the revisions under the target period. This study calls a
set of clone sets g as a clone genealogy if it satisfies both of the following two
formulae (5.4) and (5.5).
∀ci ∈ g, ∀cj ∈ CALL [(ci ⇔ cj ) → (cj ∈ g)](5.4)∀ci ∈ g ∃cj ∈ g[ci ⇔ cj ]

(5.5)

108

5.3.3 Definitions of Terms Related to Clone Genealogy
Lifetime of Clone Genealogy
For each clone genealogy g, its start revision, end revision, and lifetime aredefined as follows. All the following definitions refer a set consisting of all thetarget revisions as T .
Definition 5.3.5 (Start Revision). The revision first ∈ T is defined as the startrevision of g if it satisfies the following formula (5.6).
∃cfirst ∈ Cfirst [cfirst ∈ g] ∧ ∀l ∈ T [l < first → ∀cl ∈ Cl (cl ∈
/ g)]

(5.6)

Definition 5.3.6 (End Revision). The revision last ∈ T is defined as the end revision of g if it satisfies the following formula (5.7).
∃clast ∈ Clast [clast ∈ g] ∧ ∀l ∈ T [last < l → ∀cl ∈ Cl (cl ∈
/ g)]

(5.7)

Definition 5.3.7 (Lifetime). Let first and last be the start revision and the end
revision of the given clone genealogy g. Then, the lifetime of g refered as R is
defined in the following formula (5.8).
R = {r ∈ T |first ≤ r ≤ last}(5.8)

Modifications Applied on Clone Genealogy
This study defines modifications applied on a clone genealogy g as follows.
Definition 5.3.8 (Modifications). Let g be a clone genealogy, and r be a revisionthat are included in the lifetime of g. This study says “g was modified at therevision r” if at least one of the following two formulae (5.9) and (5.10) hold.

∃cr ∈ Cr [cr ∈ g ∧ ∃br ∈ cr , ∃br+1 ∈ Br+1
[br ↔ br+1 ∧ hash(br ) ̸= hash(br+1 )]] (5.9)∃cr ∈ Cr [cr ∈ g ∧ ∃br ∈ cr , ∀br+1 ∈ Br+1 [(br ̸↔ br+1 )∨ (br ↔ br+1 ∧ ∀cr+1 ∈ Cr+1 [br+1 ∈/ cr+1 ])]] (5.10)
109

The formula (5.9) refers the case that the hash value of a block in revision r
was changed bacause of modifications on the block. On the other hand, the formula(5.10) refers another case of modifications that a block in revision r disappeared in
the next revision r + 1, or the block is no longer a member of any of clone sets in
the revision r + 1.
In addition, genealogies should disappear if they do not exist in the latest revision of target revisions. In this case, it is natural to regard these genealogies as
modified in their end revisions and these modifications made the genealogies disappear. In formal, let T be a set consisting of all the target revisions and last g be
the end revision of a clone genealogy g, then g is regarded as modified in the revision last g if the following formula (5.11) holds. The remainder of this chapter calls
modifications that satisfy the formula (5.11) “modification for disappearance”.
∃r ∈ T [last g < r]

(5.11)

Furthermore, the number of modifications applied to a clone genealogy g as
defined as follows.
Definition 5.3.9 (The Number of Modifications). This study regards the number ofrevisions that the given clone genealogy g as the number of modifications applied
to the clone genealogy.
5.3.4 Example of Clone Genealogy
Figure 5.1 shows an example of clone genealogies. This example has a clone
genealogy consisting of six clone sets, A, B, C, D, E, and F.
In revision r, there exists a clone set A consisting of two blocks. The two
blocks included in clone set A were modified in revision r, which results changesof hash values of the two blocks. Hence, this genealogy is regarded as modified inrevision r because of the formula (5.9).
Clone set B that exists in revision r + 1 recieved a new member in the next
revision r + 2. The genealogy, however, is not regarded as modified in revisionr + 1 because this study is not interested in addition of cloned blocks.
The genealogy was branched by the modification from revision r+2 to revisionr + 3. The formula (5.9) holds in the case that the genealogy was branched, hence
the genealogy is regarded as modified in revision r + 2.
Both of the two blocks of clone set D that exists in revision r +3 have no correspondents in the next revision r + 4. In other words, the two blocks disappeared bymodifications between revisions r + 3 and r + 4. Hence, the genealogy is regarded
as modified in revision r + 3 because of the formula (5.10) even though the otherclone set E was not modified between the two revisions.
110

B

A

D

C

10

40

40

40

10

40

40

40

20

20

40

50

50

30

30

30

50

50

r

r+1

r+2

r+3

r+4

F

E

n

A Block Whose
Hash Value is n

A Clone Set

Correspondence
Relationship of Blocks

A Modified Clone Set
Correspondence
Relationship of Clone Sets

Figure 5.1: An Example of Clone Genealogies
In summary, it is regarded that the clone genealogy was modified three times inrevisions r, r +2, and r +3. Note that there is no way to know the start revision andthe end revision of the genealogy only from this figure because revisions before r
and after r + 4 are omitted in the figure.

5.4

Experimental Setup

The experiment uses the enhanced CTEC to be able to detect clone genealogies.
The experimental targets are five open source software systems and CTEC itself.
Table 5.1 shows an overview of target software systems. Table 5.1(a) shows
directories of the experimental target. Note that we narrowed the target directories on almost all of the target systems to eliminate uninterested code duplications,
including test code or branches. Table 5.1(b) describes target revisions for every
experimental targets. Herein, the number of revisions (the right most column) considers revisions that at least one source file in the target directories was modified.
Table 5.1(c) shows LOCs and the number of detected genealogies of each target
111

Table 5.1: Target Software Systems(a) Target Directories

Name
Ant
ArgoUMLCTEC
Carol
DNSJava
JabRefTarget Directory/ant/core/trunk/src/main//trunk/src///trunk/carol/src//trunk/org/xbill/DNS//trunk/jabref/src/java/net/(b) Target Revisions

Name
Ant
ArgoUMLCTEC
Carol
DNSJava
JabRefFirst Revision(Date)
268,623(2001/2/9)
1(1998/1/27)
1(2012/6/19)
9(2002/8/6)
2(1998/9/6)
6(2003/10/17)

Latest Revision(Date)
909,962(2010/2/14)
19,893(2012/7/10)
419(2013/5/3)
1,335(2007/10/22)
1,670(2012/10/26)
3,718(2011/11/11)# of Revisions
5,154
3,918
152
250
1,285
1,489

(c) LOCs and Numbers of Genealogies

Name
Ant
ArgoUMLCTEC
Carol
DNSJava
JabRef

LOC (in the Latest Revision)
211,958
362,783
22,872
17,251
22,512
113,277112# of Genealogies
668
2,710
63
233
386
682

system.
Every of our experimental targets is written in Java, and managed with Subversion. The reason why we chose these software systems as follows.
• Ant and ArgoUML have long histories of development, and they are widelyused.
• CTEC has been developed by our own hands, and so we can deeply analyzeit.
• Carol and DNSJava were used in the previous research conducted by Kim
et al. [78].
• JabRef was used in the previous research conducted by Göde and Koschke[35].

5.5 Experimental Results
This section describes our experimental results for each of our research questions, and then offers the answers to them.
RQ1: Does the finding ‘most of clones are short-lived’ hold as well as Kim et al.
reported in the literature [78]?
Figures 5.2 and 5.3 show the length of lifetimes of clone genealogies in eachof the experimental targets. The x-axes of the graphs indicate the length of clone
genealogies, which are the numbers of revisions in Figure 5.2 and the numbers ofdays in Figure 5.3, respectively. The y-axes indicate the cumulative frequenciesof clone genealogies in percentage whose lifetimes are less than the number ofrevisions or days specified in the x-axes. For instance, we can see it from Figure
5.3 that approximately 40% of all the genealogies of Ant survived for less than 400
days.
All of the graphs have a common characteristic that they drastically grow inthe left of the graphs. This means that most of genealogies have short lifetimes.
This tendency is the most remarkable in DNSJava. That is, approximately 80% of
genealogies in DNSJava are alive in less than 100 revisions and 250 days, which
are less than 10% of its development period.
However, it is unclear from these graphs whether clone genealogies are shortlived or not. This is because these graphs take genealogies that are alive in thelatest revisions of each software system into count. There is no way to know how
long clone genealogies will survive if they are alive in the latest revisions.
113

0# of alive revisions(e) DNSJava

114(f) JabRef

Figure 5.2: The Length of Lifetime (Revisions)# of alive revisions

80

200
220
240

1400

160

140

120

100

1300

100
90
80
70
60
50
40
30
20
10
0

180

(d) Carol

1200# of alive revisions

1100

1000

900

800

700

(c) CTEC

600# of alive revisions

500

60

40

20

0

150

140

130

120

110

100

90

80

70

60

50

40

30

20

cumulative frequency (%)(a) Ant

400

300

200

100

100
90
80
70
60
50
40
30
20
10
0

cumulative frequency (%)

010cumulative frequency (%)
100
90
80
70
60
50
40
30
20
10
0

0

1100

1000

900

800

700

600

500

400

300

200

100

cumulative frequency (%)
0
250
500
750
1000
1250
1500
1750
2000
2250
2500
2750
3000
3250
3500
3750
4000
4250
4500
4750
5000

0
100
200
300
400
500
600
700
800
900
1000
1100
1200
1300
1400
1500

cumulative frequency (%)

cumulative frequency (%)

100
90
80
70
60
50
40
30
20
10
0
100
90
80
70
60
50
40
30
20
10
0

# of alive revisions# of alive days

100
90
80
70
60
50
40
30
20
10
0

(b) ArgoUML# of alive days(e) DNSJava

115
800

Figure 5.3: The Length of Lifetime (Days)(f) JabRef# of alive days

2800

2600

2400

2200

2000

1800

1600

1400

1200

(c) CTEC

1000

0
20
40
60
80
100
120
140
160
180
200
220
240
260
280
300

0
100
200
300
400
500
600
700
800
900
1000
1100
1200
1300
1400
1500
1600
1700
1800
1900

cumulative frequency (%)(a) Ant

600

400

100
90
80
70
60
50
40
30
20
10
0

cumulative frequency (%)

cumulative frequency (%)
100
90
80
70
60
50
40
30
20
10
0

200

0

0
250
500
750
1000
1250
1500
1750
2000
2250
2500
2750
3000
3250
3500
3750
4000
4250
4500
4750

cumulative frequency (%)
0
200
400
600
800
1000
1200
1400
1600
1800
2000
2200
2400
2600
2800
3000
3200

0
100
200
300
400
500
600
700
800
900
1000
1100
1200
1300
1400
1500

cumulative frequency (%)

cumulative frequency (%)

100
90
80
70
60
50
40
30
20
10
0
100
90
80
70
60
50
40
30
20
10
0

# of alive days
# of alive days

100
90
80
70
60
50
40
30
20
10
0

(b) ArgoUML# of alive days
# of alive days(d) Carol

100
90
80
70
60
50
40
30
20
10
0

To investigate how long genealogies survived, this experiment uses some additional terms, all of which are used in the research conducted by Kim et al. [78].
The followings are the definitions of the terms.
Definition 5.5.1 (Dead Genealogy). A genealogy g is regarded as a dead genealogy
if the end revision of g is not the latest revision of the software.
Definition 5.5.2 (k-volatile Genealogy). Let k indicate the number of revisions.
For given k, it is defined that a dead genealogy gdead is a k-volatile genealogy if
the following formula (5.12) holds for gdead .
0 ≤ |Rgdead | ≤ k(5.12),where Rgdead indicates the lifetime of gdead .
Definition 5.5.3 (CDF (k)). Let fdead (k) be the number of k-volatile genealogies.
CDF (k) is a cumulative distribution function of f (k), whose definition is given as
follows.
∑kfdead (k)CDF (k) = ∑i=0n
i=0 fdead (k)(5.13), where n means the maximum value of k in the software.
Definition 5.5.4 (R(k)). Let f (k) be the number of all the genealogies whose
lifetimes are less than k revisions, and fdead (k) be the number of k-volatile genealogies. R(k) is defined by the following formula (5.14), which indicates theratio of k-volatile genealogies among all the genealogies in the system.
∑k
i=0 fdead (k)R(k) = ∑m
i=0 f (k)(5.14), where m indicates the maximum value of the length of the lifetimes among
all the genealogies in the system.
The values of CDF (k) and R(k) tell us how many genealogies are short-lived.
We calculate these values with k is being changed and plot them as graphs.
Figure 5.4 shows the graphs for every of the target systems. For all the graphs,
the x-axes show the values of k, and the y-axes indicate the values of CDF (k)and R(k) in percentage. The values of CDF (k) and R(k) are shown with different types of lines, the solid ones show CDF (k) and the broken ones show R(k),respectively.
As we can see from the graphs, all the solid lines drastically grow in the leftof the graphs, which means that most of dead genealogies are short-lived. The
116

CDF(k)

R(k)

2800

2600

2400

2200

2000

1800

1600

1400

1200

k (# of alive revisions)

CDF(k)R(k)(b) ArgoUML
100
90
80
70
60
50
40
30
20
10
0

0
10
20
30
40
50
60
70
80
90
100
110
120
130
140
150
160
170
180

%

100
90
80
70
60
50
40
30
20
10
0

0
2
4
6
8
10
12
14
16
18
20
22
24
26
28
30
32
34
36
k (# of alive revisions)k (# of alive revisions)

CDF(k)

CDF(k)R(k)(c) CTEC# of alive days

k (# of alive revisions)

R(k)CDF(k)(e) DNSJava

R(k)(f) JabRef

Figure 5.4: CDF(k) and R(k)

117

1100

1000

900

800

700

600

500

300

200

0
50
100
150
200
250
300
350
400
450
500
550
600
650
700
750
800
850
900

0

100
90
80
70
60
50
40
30
20
10
0

100

%

100
90
80
70
60
50
40
30
20
10
0

CDF(k)R(k)(d) Carol

400

%

800

k (# of alive revisions)(a) Ant

%

1000

600

400

0

200

%

100
90
80
70
60
50
40
30
20
10
0

0
200
400
600
800
1000
1200
1400
1600
1800
2000
2200
2400
2600
2800
3000
3200
3400
3600
3800
4000
4200
4400
4600
4800

%

100
90
80
70
60
50
40
30
20
10
0

broken lines also drastically grow in the left side with an exception of CTEC.
ArgoUML and DNSJava have remarkable tendencies, which means that most of
genealogies in the two systems are short-lived. Compared to the two systems, thedegree of growth is not so high in the case of Carol even though it has a highratio of dead genealogies in the maximum value of k. However, approximately
70% of genealogies died within 125 revisions, which is the half of target revisionsof Carol. In the cases of Ant and JabRef, the maximum values of R(k) are nothigh compared to ArgoUML, Carol, and DNSJava. This means that there exists a
number of genealogies that are alive in the latest revisions of the systems. However,approximately 40% of genealogies in Ant and 50% in JabRef died within the halfof the target revisions. In summary, we can say that most of genealogies are shortlived.
CTEC, however, has a different characteristic compared to the other five systems. That is, it has a low ratio of dead genealogies among all the genealogies.
This means that genealogies in CTEC is not short-lived. A possible reason for thedifferent characteristic of CTEC is that it has been developed by us, researchers ofcode clones. This might result in the less amount of dead genealogies.
In summary of our experimental results for RQ1, it is revealed that most ofclone genealogies have short lifetimes and are short-lived. This finding supports thefindings reported by Kim et al. in the literature [78]. Therefore, our experimental
results give Yes as the answer to RQ1.
RQ2: Does the finding ‘there is a few clones that are modified multiple times’ holdas well as Göde and Koschke reported in the literature [35]?
Figure 5.5 shows the number of modifications on clone genealogies in eachtarget system. The x-axes indicate the number of modifications, and “5 -” indicatesthat the number of modifications are greater than or equal to five. The gray bars
indicate the number of genealogies that is modified the times specified in the xaxes, and the values are shown in the y-axes in the left. The lines show cumulative
frequencies with the y-axes in the right.
For all the experimental targets, over 70% of genealogies are modified at mostonce. This is the most remarkable in the case of CTEC, over 90% of whose genealogies are modified at most once. In addition, “0” shows the highest value inthe case of CTEC, whereas “1” shows the highest values in the case of the otherfive systems.
In summary, these graphs tell us that most of genealogies are never modified
or modified only once in their lifetimes. In other words, our experimental results
support the finding reported by Göde and Koschke in the literature [35]. Therefore,
we can answer Yes for RQ2.
118

250

60

200
40

150
100

20

50
0

60
1000
40
500

2
3
4
# of modifications

20

0

5-

0
0

1

(a) Ant
80

40

60

30
40

20

20

10
0
4

80

120
100

60

80
40

60
40

20

20

0
2
3
# of modifications

100

140

# of genealogies# of genealogies

50

160
cumulative frequency (%)

100

1

0

5-

0
0

1

100

200

80

150

60

100

40

50

20

0

0
2
3
4
# of modifications

5-

400

100

350

# of genealogies

250

1

2
3
4
# of modifications(d) Carol
cumulative frequency (%)# of genealogies(c) CTEC

05-(b) ArgoUML

60

0

2
3
4
# of modifications

cumulative frequency (%)

1

80

1500

0
0

100
cumulative frequency (%)

300

2000

80

300
250

60

200
40

150
100

20

50
0

5-

0
0

(e) DNSJava

cumulative frequency (%)# of genealogies

80# of genealogies

100

350

cumulative frequency (%)

400

1

2
3
4
# of modifications

5-(f) JabRef

Figure 5.5: The Number of Modifications
RQ3: Are there many long-lived clones that are modified multiple times?
To answer RQ3, we investigate how many genealogies are long-lived and modified multiple times. Herein, a genealogy is regarded as “long-lived” if it survive
more than the half of target revisions of the software system. This criterion was
also used in the research conducted by Kim et al. [78].
Table 5.2 shows the numbers and ratios of long-lived genealogies which aremodified multiple times. The ratio of Carol is the highest among all the experimental targets, and Ant also has a high ratio compared to other four systems. In
other words, Carol and Ant have more genealogies that developers or maintainers
119

should look out for than other systems.
In total, the ratio of genealogies that are long-lived and modified multiple times
is approximately 3.0% among all the genealogies detected from the six softwaresystems. Hence, the answer to RQ3 is No.
RQ4: Is there a positive correlation between the length of clones’ lifetime and thenumber of modifications applied on them?
Figure 5.6 shows the numbers of modifications on each of clone genealogies.
The x-axes indicate genealogies in the descending order of the length of their lifetimes, and the y-axes show the numbers of modifications. Each bar means thenumber of modifications on each genealogy. Note that the red and black bars indicate modifications for disappearance and the other modifications respectively, withthe red bars putted on the black bars.
These graphs show that there exists a number of modifications for disappearance, but they do not show any obvious correlations between the length of clones’
life time and the number of modifications. We calculated, therefore, Spearman’srank correlation coefficients to statistically judge whether there is any correlations
or not.
Table 5.3 shows Spearman’s rank correlation coefficients for all the experimental targets. For Ant, CTEC, and DNSJava, there exists no correlations between the length of clones’ lifetimes and the number of modifications. On the other
hand, there are correlations between them for the other three systems, ArgoUML,
JabRef, and Carol. The correlations are positive in the case of Carol, and negativein the cases of ArgoUML and JabRef. Therefore, we cannot say that there exists
positive or negative correlations between the length of clones’ lifetimes and thenumber of modifications because there is no common tendencies of correlations.
In addition, the ρ values are not so high in all the experimental targets.

Table 5.2: Long-Lived Genealogies which are Modified Multiple Times
Software # of genealogies ratio among all the genealogies
Ant
42
6.29%
ArgoUML
49
1.81%
CTEC
2
3.17%
Carol
29
12.45%DNSJava4
1.04%
JabRef
21
2.08%
Total
147
3.10%
120

10

6

8

# of modifications# of modifications

7
5
4
3
2

1

6

4
2

0

0
0

50 100 150 200 250 300 350 400 450 500 550 600 650
genealogies(in the descending order of # of alive revisions)other modifications

0

modifications for disappearance

250 500 750 1000125015001750200022502500
genealogies(in the descending order of # of alive revisions)other modifications(b) ArgoUML

7

7

6

6

# of modifications# of modifications(a) Ant

5
4
3
2

1
0

5
4
3
2

1
0

0

5

10 15 20 25 30 35 40 45 50 55 60
genealogies(in the descending order of # of alive revisions)other modifications

0

modifications for disappearance

20

40

60

80 100 120 140 160 180 200 220
genealogies(in the descending order of # of alive revisions)other modifications(c) CTEC

modifications for disappearance(d) Carol

14

20

12

# of modifications# of modifications

modifications for disappearance

10
8
6
4

2
0

15
10
5

0
0

50

100

150 200 250 300 350
genealogies(in the descending order of # of alive revisions)other modifications

0 50 100 150 200 250 300 350 400 450 500 550 600 650
genealogies(in the descending order of # of alive revisions)modifications for disappearance

other modifications(e) DNSJava

modifications for disappearance(f) JabRef

Figure 5.6: Modifications on Each Genealogy

These findings indicate that there is no obvious correlations between the lengthof clones’ lifetimes and the number of modifications applied on them. Hence, theanswer to RQ4 is No.
121

RQ5: Do clones tend to be modified more frequently in the former half of their
lifetimes than the latter one?
Figure 5.7 shows the timing when each of clone genealogies was modified.
The x-axes list clone genealogies in the descending order of the length of their
lifetimes. The y-axes indicate normalized lifetime of each genealogy, with every
lifetime of genealogies normalized from 0 to 100. Each dot means a modificationthat was applied at the timing specified with the y-axes. If a modifications wasapplied shortly after the modified clone genealogy was born, a dot will be plottednear 0 of y-axes. Note that these graphs do not consider any of modifications
for disappearance because they are interested only in modifications applied during
lifetimes of clones.
We cannot find any obvious tendencies of timings when clone genealogies weremodified. That is, clone genealogies tend to be evenly modified among their lifetimes.
To reveal characteristics of timigs of modifications on clone genealogies, we
calculated the number of modifications for every of quartered periods of lifetimes.
Table 5.4 summarizes the results. As shown in the table, the first periods of all

Table 5.3: Spearman’s Rank Correlation Coefficients
Softwareρ
p-valueAnt-0.03350
0.3873
ArgoUML-0.4529 under 2.2e−16CTEC-0.03290
0.798
Carol
0.32922.724e−7
DNSJava 0.06206
0.2238
JabRef-0.1901
5.694e−07
Table 5.4: Timing of Modifications on Quartered Periods
1st period 2nd period 3rd period 4th period
SoftwareTotal
0 - 2525 - 50
50 - 75
75 - 100
Ant
65
37
41
39
182
ArgoUML
152
279
138
115
684
CTEC
8
3
5
1
17
Carol
49
23
28
21
121
DNSJava
124
50
92
21
287
JabRef
67
40
38
35
180
Total
465
432
342
232 1471
122normalized lifetime

normalized lifetime

100
90
80
70
60
50
40
30
20
10
0
0

100
90
80
70
60
50
40
30
20
10
0

200

400
600
genealogies(in descending order of # of alive revisions)

0

0

20
40
genealogies(in descending order of # of alive revisions)

100
90
80
70
60
50
40
30
20
10
0

60

0

50
100
150
200
genealogies(in descending order of # of alive revisions)(d) Carol

100
90
80
70
60
50
40
30
20
10
0

normalized lifetime

normalized lifetime(c) CTEC

0

1000
1500
2000
2500
genealogies(in descending order of # of alive revisions)(b) ArgoUML

100
90
80
70
60
50
40
30
20
10
0

normalized lifetime

normalized lifetime(a) Ant

500

100
200
300
genealogies (in descending order of # of alive
revisions)

100
90
80
70
60
50
40
30
20
10
0
0

(e) DNSJava

200

400
600
genealogies(in the descending order of # of alive revisions)(f) JabRef

Figure 5.7: Timing of Modifications on Individual Clone Genealogies
the software systems except for ArgoUML have the highest numbers of modifications, and the second period of ArgoUML has the highest value. From the table,
modifications seem to tend to be applied in the earlier periods of lifetimes of clone
genealogies.
We further performed a statistical testing, which is the chi-square (χ2 ) test, toreveal whether these tendencies have statistical meanings or not. Table 5.5 shows
the results of chi-square tests. As the table shows, there exists a strong significant
difference between the numbers of modifications on the former and latter halves
123

…
9: public class FinallyBlockInfo extends BlockInfo {…
15:
public FinallyBlockInfo(String core, List<String> types) {16:
super(BlockType.FINALLY, core);
17:
this.types = new LinkedList<String>();18:
this.types.addAll(types);
19:
StringBuilder builder = new StringBuilder();20:for (String type : types) {21:
builder.append(type + “ “);
22:
}
23:
this.concatenatedTypes = builder.toString();24:
this.crdElement = new BlockCRD(bType);
25:
}
…
40: }

Figure 5.8: An Instance of Long-Lived and Frequently Modified Clones

in the case of ArgoUML, and there exists a weak one in DNSJava. For the othersystems, there are no significant differences between them. The numbers of modifications on the former half, however, are greater than those on the latter half for
all the six experimental targets. A possible reason why there are no significant differences in four systems is that the numbers of modifications on the four systems
are less than those of ArgoUML and DNSJava. Therefore, it has a high possibility
that the differences between the numbers of modifications on the former half andthe latter half will become larger if the four systems further evolve.
Hence, it can be said that these experimental results answer Yes for RQ5.

SoftwareAnt
ArgoUMLCTEC
Carol
DNSJava
JabRefTable 5.5: The Results of Chi-Square Test
The Former Half The Latter Half
χ2
102
80
1.1029431
253 23.0332
11
60.270672
49
1.8389174
113
6.1337
107
73
2.87
124

p-value
0.29631.592e−60.603
0.17510.01326
0.09024

5.6 Discussion
5.6.1 Long-Lived and Frequently Modified Code Clones
In this experiment, we stood a basis that we need to pay attention on code
clones that are long-lived and modified multiple times. The experimental results
revealed that approximately 3% of clones were instances of such negative clones.
Figure 5.8 shows an instance of such clones. This instance was found in CloneTracker. It was introduced into the software in the third revision, and it is still alivein the latest revision. This clone was modified six times in revisions, 17, 19, 24,
121, 234, 244, respectively. Although this clone has been completely consistentacross its lifetime, such a long-lived and frequently modified clone has a high risk
to suffer inconsistencies of modifications. Dealing with such a code clone in theearlier stage of its lifetime should be effective to prevent such unintended inconsistencies.
5.6.2 Threats to Validity
Target Software Systems
This study analyzed only software systems written in Java, and so more investigations are necessary to genelarize our findings on software systms written in any
other programming languages. In addition, none of the exprimental targets of thisstudy is industrial software system. Therefore, it is possible to gain another finding
if further analysis is performed on industrial software systems.
Detection of Code Clones
Clone detection in this study is a block-based detection. Such a fast detectionof code clones is necessary for this study because it need to run a clone detector
for all the target revisions, which is quite time-consuming. Therefore, further investigations with other clone detectors may report other different results because
different clone detectors should find different clones in the same source code. In
addition, the clone detection used in this study normalizes source code, including
replacing sub blocks with special strings. Hence, changing the way of normalization will result another experimental findings.
Clone Tracking
This study used a new technique described in Chapter 4 to track clones acrossversion histories. It has a high accuracy for the traditional clone tracking based on
125CRD, but it is possible some linkes of clones were missed even with the enhancement technique. If a more intelligent technique is available, a further investigation
with such a technique will offer different experimental results.

5.7 Summary
This chapter presented an empirical study on clone genealogies. This study
used a clone tracking technique desribed in the previous chapter to detect clone
genealogies. The purposes of this study are twohold. One is to revisit common
findings on clone evolution with a new clone tracking technique having a highchange-tolerance, and the other one is to answer some open questions that previous
research did not reveal.
The experimenal results supported two major common findings on clone evolution. That is, they revealed that most of clones have short lifetimes, and mostof clones are modified at most once through their lifetimes. Furthermore, the results revealed the following findings on clone evolution, all of which have not beenaddressed yet.
• Approximately 3% of all the code clones survived over the halves of experimental periods and were modified two or more times.
• There is no correlation between the length of lifetimes and the number ofmodificaions of clone genealogies.
• Clones tend to be modified more frequently in the former halves of their
lifetimes than in the latter halves of them.
In summary, these findings indicate that managing all the clones equally is not asuitable way to cope with code clones. This is because approximately 97% of code
clones did not require much attention of developers or maintainers because they
disappeared in a short time period or they were not frequently modified. Hence, it isnecessary to carefully select code clones that you pay any attention for achieving aneffective code clone management. In addition, one of our findings, clones tend to
be modified more frequently in the former halves of their lifetimes than in the latter
halves of them, indicates that it should be effective to start dealing with harmfulcode clones as soon as possible. However, we cannot say that it is not a good way
to pay attentions on clones that have survived a certain period. The reason of thisis that clones were also modified in the latter halves of their lifetime even though
the number of modifications on the period will be less than the former ones.

126Chapter 6

Clone Removal with Form
Template Method Refactoring
6.1 Background
One of the ways to prevent the influence of harmful code clones is removing
them by refactorings. Refactorings can improve software maintainability withoutchanging external behaviors of software. However, a fully manual refactoring is adifficult task for software maintainers. That is, it is quite difficult for maintainers toapply refactorings manually without introducing any human errors [118]. In otherwords, fully manual refactorings have high risks to introduce new bugs. Applying manual refactorings is not only complicated but also costly. This is because
maintainers need to detect where they should refactor, consider how the candidates
are refactored, and confirm that the refactorings do not change the behavior of thetarget software. Because of these factors, it is almost necessary to support maintainers with tools or techniques for applying refactorings. Tool supports enable
maintainers to apply refactorings easily and safely. These needs encourage many
researchers in recent years and they produce many tools and techniques [111].
It is quite natural that refactorings requiring complex procedures are more risky
and more costly than ones requiring simple procedures. This implies that the former requires more supports than the latter. From the point of clone removal, clones
having some gaps require more complex procedures to be removed than exact
clones. Therefore, for the purpose of effective clone management, tool supports
are required to remove clones having gaps. The majority of clone removal techniques, however, cannot handle gaps included in clones because they are based on“Extract Method” or “Pull-Up Method”.
Using “Form Template Method” can overcome this issue. Form Template
127

Method refactorings pull the common statements between similar methods into acommon base class, and leave gaps between target methods in the original classes.
Form Template Method is a hybrid of Extract Method and Pull-Up Method.
This implies that Form Template Method requires much effort and attention than
Extract Method and Pull-Up Method.
Some researchers have proposed techniques to support refactorings with Form
Template Method [55,66,107]. However, these techniques cannot support removing code clones if they include the following differences even if these differences
have no impacts on the behavior of the program:• Different order of code fragments and• Different implementation styles (such as for- and while- loops).
Moreover, the existing techniques can handle only pairs of methods though
Form Template Method refactoring can be applied to groups consisting of threeor more similar methods.
This study proposes a new technique to support applying Form Template
Method with program dependence graphs, which allows us to resolve the firstissue. We also extend the proposed method to be able to handle groups of three ormore similar methods.

6.2 Motivation
6.2.1 Issues of Previous Studies
As described in Chapter 2, there are some studies to support Form Template
Method refactoring application. However, they still have some issues as follows.
• They cannot handle trivial differences that have no impact on the behaviorof programs.
• They cannot handle groups of three or more similar methods in spite of thatForm Template Method itself can be applied to them.
The following subsections describe these issues in detail.
Issue of Trivial Differences
In previous studies, all the differences between target methods are regarded
as unique processing even if some of them do not affect the meaning of program.
The following situations may be instances of the differences that do not affect the
behavior of program.
128• The order of code statements is different in target methods. However, thebehavior of the program is preserved even if they are reordered.
• Iterations are implemented with for statements in a method of target methods, meanwhile they are implemented with while statements in another methodof target methods. However, the semantics of the iterations are exactly thesame.
Figure 6.1 shows an example of our motivating example for this issue. In thisexample, there is a difference of the order of code statements, and there is also a
difference of the implementation style of loop statements. However, these differences do not influence the meaning of the program. The only meaningful differenceof these two methods is the ways of calculations of variable points. Neverthelessthe methods described in previous studies regard these trivial differences as gaps
between the two methods. Therefore, they can suggest only four lines as duplicate
statements in the two methods (shown in Figure 6.1(a)). This study aims to improve this issue by using PDGs, and it will suggest 11 lines except the calculationsof variable points as duplicate statements (shown in Figure 6.1(b)).
Issue of Groups of Three or More Methods
Form Template Method can be applied to a group of three or more similar
methods. Nevertheless, the previous methods can handle only a pair of similar
methods. Supporting Form Template Method application on only a pair of similar
methods is not sufficient for clone removal. This is because code clones should
remain after a refactoring with Form Template Method on a pair of methods if
there are three or more similar methods.
In the example shown in Figure 6.2, there are four similar methods in four
different classes, and these four classes have the same base class. If we apply
Form Template Method refactoring on the pair of method() in ClassA andmethod() in ClassB, we get source code shown in Figure 6.2(b). As the figure
shows, there are still code clones between method() in ClassC and method()in ClassD because we did not modify these two methods. Also, there are code
clones between the template method and method() in ClassC and ClassD.
Moreover, it is difficult to remove code clones from the source code of Figure
6.2(b) with Form Template Method refactoring. That is because a conflict of two
template methods should occur if we apply Form Template Method on a pairof method() in ClassC and method() in ClassD. However, we can apply
Form Template Method on all the four similar methods at a time. If we do so, we
get the source code shown in Figure 6.2(c). As the figure shows, code clones arecompletely removed by the refactoring.
129

public int calc() {int result = 0;

public int calc() {int result = 0;
int s = 0;
int points = 0;

int dc = getDC(getRegion());
result += dc;

int i = 0;
while (i < getList().size()) {Item item = getList().get(i);s += item.getPrice();points += item.getPoints();i++;}
addPoints(points);
int dc = getDC(getRegion());
result += dc;
result += s * TAX_RATE;

int sum = 0;
int points = 0;
for (int i = 0; i < getList().size(); i++) {Item item = getList().get(i);sum += item.getPrice();
gaps
points++;}result += sum * TAX_RATE;
addPoints(points);

DuplicatedStatements

return result;}

return result;}(a) The Method Proposed by Juillerat et al. [66]public int calc() {int result = 0;

public int calc() {int result = 0;
int s = 0;
int points = 0;

int dc = getDC(getRegion());
result += dc;

int i = 0;
while (i < getList().size()) {Item item = getList().get(i);s += item.getPrice();points += item.getPoints();i++;}
addPoints(points);
int dc = getDC(getRegion());
result += dc;
result += s * TAX_RATE;

int sum = 0;
int points = 0;
for (int i = 0; i < getList().size(); i++) {Item item = getList().get(i);sum += item.getPrice();points++;gaps}
result += sum * TAX_RATE;
addPoints(points);
return result;}

DuplicatedStatements

return result;}(b) The Proposed Method

Figure 6.1: Motivating Example 1

130SuperClass

Code Clones

ClassAmethod()ClassBmethod2()
method()ClassC
method()ClassD
method()(a) before refactoring
SuperClass
method()Code Clones

ClassA
newMethod()ClassBClassC
method()method2()
newMethod()ClassD
method()(b) after refactoring on two methods
SuperClass
method()ClassA
newMethod()ClassBmethod2()
newMethod()ClassC
newMethod()ClassD
newMethod()(c) after refactoring on all the four methods

Figure 6.2: Motivating Example 2131

Moreover, some researchers reported that the quality of software systems aftersome refactorings is affected by the order of the refactorings [94, 165]. In thecase that refactorings on only a pair of methods are supported, the number of thecandidates (pairs of methods) of Form Template Method refactorings is equal to
the number of 2-combinations from a set of all the target methods. It is too difficult
to detect the most appropriate order of refactorings from such a huge number ofcandidates. In the example of Figure 6.2, there are six pairs of methods that can be
refactored with Form Template Method. However, it is difficult to decide whichpair is most suitable to be refactored.
For these reasons, it is necessary to handle three or more methods at a time for
effective clone removal with Form Template Method refactoring pattern. In thisstudy, therefore, we propose a refactoring support technique on pairs of methods
to be able to handle groups of three or more methods.
6.2.2 Objective of This Study
This study proposes a new refactoring support technique with Form Template
Method refactoring pattern. We aim to resolve the first issue of previous studies(described in Section 6.2.1), and we aim to resolve the second issue described in
Section 6.2.1 by expanding the proposed method on pairs of methods to be able tohandle groups of three or more methods.
Moreover, we aim to assist users in detecting refactoring candidates with Form
Template Method. Users need to specify a refactoring candidate (which meansa pair of methods) for using the previous techniques for Form Template Method
application assistance. The approach of previous studies is useful for actual modifications in source code associated with refactoring activities. However, it is notpossible to reduce effort required for identifying opportunities on which users want
to apply Form Template Method refactorings in this approach. Because softwaresystems become larger and more complex, it is difficult to comprehend structuresof software systems appropriately. Hence, it is difficult to identify suitable clone
removal candidates. This is the reason why we aim to support the detection of
refactoring candidates.
To reduce efforts for identifying refactoring candidates, the proposed method
detects refactoring candidates automatically, and suggests all the candidates to its
users. Consequently, the proposed method can suggest refactoring candidates ofwhich users are not aware. In addition, the proposed method also suggests common
processing and unique processing in each of refactoring candidate to reduce efforts
required for modifying source code to apply Form Template Method refactoring
pattern.
Note that the proposed method aims to suggest candidates that can be refac132

tored, not should be refactored. The reason is that there is not strict and genericstandard to judge whether code clones should be removed. Also, there does not exist a strict and generic standard to judge whether Form Template Method should
be used to remove code clones. Accordingly, the proposed method leaves such decisions to its users whether they need to apply refactorings on each candidate thatthe proposed method suggests.

6.3

Outline of the Proposed Method

6.3.1 Inputs and Outputs
The proposed method takes source code of target software systems as its input.
Then, the proposed method detects all the candidates of Form Template Method
refactoring, and it suggests them to users. For each of the refactoring candidates,
the proposed method suggests program statements that can be merged into the baseclass as the common processes, and program statements that should be remained ineach derived class as the unique processes. Additionally, for the unique processes,
the proposed method suggests the following information.
• Sets of program statements that should be extracted as a single method.
• Relationships of new methods created by extracting the unique processes
between the derived classes. This relationship means that the new methods
under this relationship can be extracted as methods whose signatures are thesame to each other.
Figure 6.3 shows the output information of the proposed method. In this example, there are two similar methods named validate, and the owner classesof these two methods have the same base class. The proposed method detects thecommon and unique processes between these methods. Herein, the hatched program statements are the common processes that should be merged into the baseclass. Program statements that are not included in the common processes are regarded as the unique processes in each derived classes. For the unique processes,
the proposed method detects sets of program statements that can be extracted as asingle method. In this case, we get three sets of program statements (labeled with‘A’, ‘B’ and ‘C’ in the figure). The proposed method also detects relationshipsof new methods created by extracting the unique processes. In this example, theproposed method detects a relationship between ’A’ and ‘B’, which means that the
new methods created by extracting ‘A’ and ‘B’ should have the same signature toeach other. Here, there is no correspondence of ‘C’. In this case, we have to write
an empty method that has the same signature of the method created from ‘C’ in theowner class of the left method.
133

public void validate() {Apublic void validate() {verifySettings();

if (isReference()) {getCheckedRef().validate();}To be extracted as same
signature methods

B

dieOnCircularReference();CommonProcesses

C

String errmsg = getError();if (errmsg != null) {throw new BuildException(errmsg);}

dieOnCircularReference();
Enumeration e = selectorElements();
while (e.hasMoreElements()) {Object o = e.nextElement();((BaseSelector) o).validate();}Enumeration e = selectorElements();
while (e.hasMoreElements()) {Object o = e.nextElement();((BaseSelector) o).validate();}}}UniqueProcesses

Code fragments
surrounded
by a rectangle are
to be extracted
as a single method

Figure 6.3: The Output of the Proposed Method
6.3.2 Specialization of PDGs
Definition of Traditional PDG
As metioned in 2.4.5, a PDG (Program Dependence Graph) is a directed graphthat represents dependencies between the elements of the program [31, 153]. A
node in a PDG indicates an element of a program (such as a statement and a conditional predicate), and an edge in a PDG indicates a dependence between twoelements. PDG is created based on flows of data and controls. Therefore, we get
the same PDGs from two programs if their flows of data and controls are same,
though the programming styles are not equal.
There are the following two types of dependencies in PDG.
Data Dependence: There is a data dependence from element s to element t, if avalue is assigned to variable x in s, and t references x without changing thevalue of x.
Control Dependence: There is a control dependence from element s to elementt, if s is a conditional predicate and it directly determines whether t is executed or not.
Figure 6.4 shows an example of PDG. In this example, there are three data
dependencies from the 2nd, 3rd, and 5th lines to the 4th line because variables y andz are referenced in the 4th line. On the other hand, there is a control dependence
from the 4th line to the 5th line because the conditional predicate in the 4th line
directly controls the execution of the 5th line. In addition, there is a node labeled134

1: x = 0;
2: y = 0;
3: z = MAX;
4: while (y < z) {5:
y = x + 1;
6: }7: println(y);method
enter
<1>

<2>

<3>
<4>

Data Dependence Edge

Control Dependence Edge

<5>

<7>

Figure 6.4: An Example of PDG
with “method enter” that means the enter node of the method. In general, PDG
contains a method enter node, and there are control dependencies from the enter
node to all nodes that are directly contained by the method. Note that we regard anode n as being directly contained by the method if s has no control dependencies
from any other nodes in the PDG.
Specialization
PDGs used in this study is specialized for code clones detection and refactoring. The major differences of a traditional PDG and a specialized PDG are as
follows:• having execute dependences and• tracing state changes of objects.
Execute Dependence
PDGs used in this study have an additional dependence called “execute dependence”. The definition of execute dependence is as follows.
Execute Dependence: There is an execute dependence from element s to elementt, if t can be executed in the next that s is executed.
Figure 6.5 shows an example of PDG with execute dependence edges. We candetect more code clones with PDGs having execute dependence than with traditional PDGs. This is because the range of program slicing is expanded by introducing this dependence.
135

1: x = 0;
2: y = 0;
3: z = MAX;
4: while (y < z) {5:
y = x + 1;
6: }7: println(y);method
enter

<1>

<2>

<3>

<4>

Data Dependence Edge
Control Dependence Edge

<5>

<7>

Execute Dependence Edge

Figure 6.5: An Example of PDG with Execute Dependence Edges
Tracing State Changes of Objects
In this study, we create data dependence edges with considering state changesof objects caused by method calls. Concretely, we regard that there is a data dependence from a method call statement s to other statement t, if the state of any
objects is changed in s and t references the objects without redefining them.
Figure 6.6 compares a traditional PDG and a specialized PDG created fromthe same source code. This figure omits control and execute dependences and themethod enter node. In this example, the state of an object builder is changed in
the 2nd, 3rd, and 4th lines by calling a method append. In the traditional PDG,
all the elements that reference builder have data dependences from the 1st line.
This is because the object builder does not re-defined or re-assigned until theend of the method. However, the specialized PDG used in this study considers statechanges of objects. Therefore, we get the PDG shown in Figure 6.6(c) from thesource code.
Note that it is regarded that states of objects are changed by a method call if
the values of any fields in the objects are changed by the method [146].
6.3.3 Processing Flow
The processing of the proposed method can be separated into one for methodpairs and one for method-groups. The processing for method-groups is implemented as an extended version of method-pairs one.
The processing flow of the proposed method on pairs of methods is shown
below.
136

1: StringBuilder builder = new StringBuilder();
2: builder.append(“A”);
3: builder.append(“B”);
4: builder.append(“C”);
5: return builder.toString();(a) Source Code

1
1

2

2
3

3

4

4

5

5
(b) Traditional(c) Specialized

Figure 6.6: Data Dependence Considering State Changes of Objects
STEP-P1: Analyze target source code, and create PDGs.
STEP-P2: Detect code clones with PDGs.
STEP-P3: Identify pairs of methods on which Form Template Method can beapplied.
STEP-P4: Detect common processes and unique processes for each of method
pairs.
STEP-P5: Detect sets of statements included in unique processes that should be
extracted as a single method.
STEP-P6: Detect pairwise relationships between new methods created by extracting unique processes.
STEP-P7: Show all the analysis results.
137

A

e1

B

e5

e4

E

e3

e2

C
e8

D

e6

F

e7

Figure 6.7: A Directed Graph
The processing for method-groups uses the results of the method-pairs version.
Therefore, processing steps from STEP-S1 to STEP-S6 are exactly identical to theprocessing steps from STEP-P1 to STEP-P6. The processing flow of the proposed
method on method groups after STEP-S6 is shown below.
STEP-S7: Detect groups of methods on which Form Template Method can beapplied with the information about pairs of methods.
STEP-S8: Detect common processes and unique processes for each of method
groups.
STEP-S9: Detect relationships between new methods created by extracting uniqueprocesses.
STEP-S10: Show all the analysis results.
We describe each step in detail in Sections 6.4 and 6.5.
6.3.4 Definitions
Here, we describe definitions of terms referenced in the following explanations.
A Directed Graph
A directed graph G is represented as G = (f, V, E), where, V is a set ofnodes, E is a set of edges, and f is a map from edges to ordered pairs of nodes(f : E → V × V ). The remainder of this chapter writes the set of nodes in G as
VG , the set of edges in G as EG , and the map between edges and ordered pairs of
nodes in G as fG , respectively.
138

Figure 6.7 shows an example of directed graphs. Given that the graph of the
figure is G, VG , EG , and fG become as follows.
VG = {A, B, C, D, E, F }EG = {e1 , e2 , e3 , e4 , e5 , e6 , e7 , e8 }
fG (e1 ) = (A, B), fG (e2 ) = (A, C), fG (e3 ) = (A, D), fG (e4 ) = (B, E)
fG (e5 ) = (E, C), fG (e6 ) = (C, F ), fG (e7 ) = (F, D), fG (e8 ) = (E, F )We define a tail of an edge e ∈ EG as tail (e) and a head of e as head (e). The
definitions are as follows.
Definition 6.3.1 (tail (e), head (e)). We define tail (e) as the first element of fG (e),and head (e) as the last element of fG (e). In other words, tail (e) := u andhead (e) := v, where fG (e) = (u, v).
For example, for an edge e1 in the graph of Figure 6.7, tail (e1 ) = A andhead (e1 ) = B.
In the next, we define sets of edges BackwardEdges(v) and ForwardEdges(v)for v ∈ VG . BackwardEdges(v) is a set of edges whose head is v (defined in theformula (6.1)), and ForwardEdges(v) is a set of edges whose tail is v (defined in
the formula(6.2)).
Definition 6.3.2 (BackwardEdges(v), ForwardEdges(v)).
BackwardEdges(v) := {e ∈ EG | head (e) = v}

(6.1)

ForwardEdges(v) := {e ∈ EG | tail (e) = v}

(6.2)

For a node C in the graph of Figure 6.7, BackwardEdges(C) and ForwardEdges(C)become as follows.
BackwardEdges(C) = {e2 , e5 }ForwardEdges(C) = {e6 }PDG
A PDG is one of the directed graphs. Given a PDG G = (f, V, E), a nodeof G corresponds to an element of programs, and an edge of G corresponds to adependence between two elements. In this study, an element of programs indicatesa statement of programs. Note that we build a PDG in each of methods, therefore
every method has a corresponding PDG.
139

A

e1

x

x e2

B

C

e
e4 y 5

e3

x

y

E

z

F

e8

Data Dependence

D

e6

e7

Control Dependence

Figure 6.8: A PDG
As described above, there are three types of dependencies in PDGs used in thissutdy.
Definition 6.3.3 (Dependencies in PDG). This study represents data dependencies as data, control dependencies as control, and execute dependencies as execute, respectively. It uses a term type to represent a map from edges to thetypes of dependences that the edges represent (type : E → EdgeType), where
EdgeType = {data, control , execute}. In addition, a data dependence edge has
the information about the variable that the edge represents. We define var (ed ) as
the represented variable by a data dependence edge ed .
In the PDG of Figure 6.8, type and var become as follows.

type(e1 ) = data, type(e2 ) = data, type(e3 ) = data, type(e4 ) = data,type(e5 ) = control , type(e6 ) = control , type(e7 ) = data, type(e8 ) = data,var (e1 ) = x, var (e2 ) = x, var (e3 ) = x,var (e4 ) = y, var (e7 ) = z, var (e8 ) = y
Clone Pairs
In the proposed method, code clones are detected with PDGs. PDG-based
clone detectors regard isomorphic subgraphs of PDGs as code clones. Here, we
define ClonePairs(G1 , G2 ) as a set of isomorphic subgraphs between PDGs G1and G2 .
140

G’’1 E

A
B

C

F

D

G
H

G’1

I

G1

J

G’’2 5

1
2

3

6

7

4

G’2

Cloned Node
Non-Cloned Node

8
9
10

G2

Figure 6.9: ClonePairs(G1 , G2 )Definition 6.3.4 (ClonePairs(G1 , G2 ) and a clone pair). ClonePairs(G1 , G2 ) isdefined in the formula (6.3), and we call every element of ClonePairs(G1 , G2 ) aclone pair.
ClonePairs(G1 , G2 ) := {(G′1 , G′2 ) | G′1 ⊂ G1 ∧ G′2 ⊂ G2 ∧ G′1 ∼= G′2 } (6.3)
where, G1 and G2 are PDGs given as input data, G′ ⊂ G indicates G′ is a
subgraph of G, and G′ ∼= G′′ indicates G′ and G′′ are isomorphic subgraphs toeach other.
In the example of Figure 6.9, there are two isomorphic subgraphs between G1and G2 . Therefore, ClonePairs(G1 , G2 ) become as follows.
ClonePairs(G1 , G2 ) = {(G′1 , G′2 ), (G′′1 , G′′2 )}where, VG′1 = {A, B, C, D}, VG′2 = {1, 2, 3, 4}, VG′′1 = {E, F, G}, andVG′′2 = {5, 6, 7}.
We also define duplicate relationships on nodes of PDGs as follows.
Definition 6.3.5 (Duplication of nodes). The two nodes v1 ∈ VG1 and v2 ∈ VG2
are duplicated to each other if and only if they satisfy the formula (6.4). This
chapter uses a symbol ∼ to represent a node duplication. For instance, v1 ∼ v2
means that v1 and v2 are duplicated to each other.
∃(G′1 , G′2 ) ∈ ClonePairs(G1 , G2 )[v1 ∈ VG′1 ∧ v2 ∈ VG′2 ∧ φ(v1 ) = v2 ](6.4)

where, G1 and G2 are PDGs, and φ indicates the isomorphism between G′1 andG′2 (G′1 ∼= G′2 ).
141

In the example of Figure 6.9, the binary relation ∼ becomes as follows.
∼ = {(A, 1), (B, 2), (C, 3), (D, 4), (E, 5), (F, 6), (G, 7)}

6.4 Supporting for Method Pairs
6.4.1 STEP-P1: Create PDGs
The proposed method internally uses an existing PDG-based clone detector,
Scorpio [139], to detect code clones. In addition, Scorpio internally uses a sourcecode analysis tool, MASU [108], to create PDGs. The first step of the proposed
method is covered with MASU.
In PDGs created by MASU, a node corresponds to a statement of program. Additionally, PDGs created by MASU have another dependence, “execution dependence”, in addition of traditional two dependences, data and control dependences.
Execution dependences indicate execution-next links.
Note that PDGs used in the proposed method need not to be always createdby MASU. Any tools or techniques that are able to create PDGs can take place of
MASU.
6.4.2 STEP-P2: Detect Code Clones
As described above, the proposed method uses Scorpio to detect code clones.
Therefore, the second step of the proposed method is fully covered with Scorpio.
Here, we describe the clone detection algorithm used in Scorpio briefly.
First, Scorpio calculates hash values for every node of PDGs. The hash values are calculated with information about the structure of the statement that every
node represents. Scorpio replace variables’ names or literals by their types, whichenables to detect code clones with different variables’ names or literals. Next, Scorpio classifies every node with its hash value. Nodes having the same hash value areclassified as an equivalence class. Then, every pair (r1 , r2 ) of nodes are selectedfrom every equivalence class, and two isomorphic subgraphs that include r1 and r2
are identified. Both forward and backward slices are used to identify isomorphic
subgraphs.
Algorithms of each slicing are shown in Algorithm 6.1 and Algorithm 6.2,
respectively. Suppose G1 and G2 are the target PDGs. The algorithm to detectisomorphic subgraphs between G1 and G2 with the forward slice is shown in Algorithm 6.1. Note that R1 and R2 must be initialized as empty sets to run thisalgorithm. In Scorpio, hash values are used to compare two nodes. Therefore,
142

Algorithm 6.1 ForwardSlice(G1 , G2 , r1 , r2 , R1 , R2 )Require: G1 , G2 , r1 , r2 , R1 , R2 , r1 = r2
Ensure: R1 ∼= R2+
1: R1 ← r1+
2: R2 ← r2
3: for all e1 ∈ ForwardEdges(r1 ) do
4:
for all e2 ∈ ForwardEdges(r2 ) do
5:
r1′ ← head (e1 )6:r2′ ← head (e2 )7:
if r1′ ̸= r2′ then8:
continue9:
end if10:
if r1′ ∈ R1 or r2′ ∈ R2 then11:
continue12:
end if13:
if r1′ ∈ R2 or r2′ ∈ R1 then14:
continue15:
end if16:
ForwardSlice(G1 , G2 , r1′ , r2′ , R1 , R2 )17:
end for
18: end for

Algorithm 6.2 BackwardSlice(G1 , G2 , r1 , r2 , R1 , R2 )Require: G1 , G2 , r1 , r2 , R1 , R2 , r1 = r2
Ensure: R1 ∼= R2+
1: R1 ← r1+
2: R2 ← r2
3: for all e1 ∈ BackwardEdges(r1 ) do
4:
for all e2 ∈ BackwardEdges(r2 ) do
5:
r1′ ← tail (e1 )6:r2′ ← tail (e2 )7:
if r1′ ̸= r2′ then8:
continue9:
end if10:
if r1′ ∈ R1 or r2′ ∈ R2 then11:
continue12:
end if13:
if r1′ ∈ R2 or r2′ ∈ R1 then14:
continue15:
end if
16:
BackwardSlice(G1 , G2 , r1′ , r2′ , R1 , R2 )17:
end for
18: end for143r1 = r2 indicates that the hash value of r1 is equal to that of r2 . Also, the algorithm with the backward slice is shown in Algorithm 6.2. Both of the forward andbackward slices are used to detect code clones in Scorpio.
Isomorphic subgraphs detected in this step is regarded as a clone pair. We set
a minimal size of each isomorphic subgraph to six nodes to be detected as code
clones. In the next step, Scorpio removes uninteresting clone pairs. The algorithm
is that if a clone pair (s1 , s2 ) is subsumed by another clone pair (s′1 , s′2 ), it isremoved from the set of clone pairs. Finally, clone sets are generated from clone
pairs sharing the same isomorphic subgraphs.
Note that it is not necessary to detect code clones with this way to use the proposed method. The proposed method only needs ClonePairs(Gm1 , Gm2 ) for any
pair of methods (m1 , m2 ) contained in the target program, where Gmi indicates a
PDG of method mi . The proposed method does not care how they are identified.
6.4.3 STEP-P3: Identify Method Pairs
This step detects pairs of methods on which Form Template Method can beapplied with the information about code clones detected by Scorpio. The proposed
method regards a pair of methods as a refactoring candidate if it satisfies following
requirements.
Requirement A: The two methods in the method pair are defined in different
classes.
Requirement B: The owner classes of the two methods have the same base class.
Requirement C: There is at least one clone pair between the method pair.
The followings discuss these requirements in detail.
Requirement A
Form Template Method cannot be applied on methods defined in the sameclass because it uses the inheritance relationships and the polymorphism. Thus,
the method pair that the proposed method targets has to be defined in different
classes.
Requirement B
Form Template Method targets similar methods whose owner classes havethe same base class. It is possible that we apply Form Template Method on
methods whose owner classes do not have the same base class. The way is that we
144

insert a new class into class hierarchy and make the owner classes inheriting the
new class. However, refactorings with this way may decay the quality of program
design because two non-related classes are forced to be jointed in the class hierarchy. For this reason, the target method pairs are limited to having the same baseclass.
Requirement C
If there is no duplicate statement, Form Template Method cannot be appliedon such a method pairs because no statement is pulled up into the base class. Therefore, we make a requirement that there is at least one clone pair between the two
methods of every target method pair.
Suppose that Gm1 and Gm2 are PDGs of methods m1 and m2 . If there is noclone pair between a method pair (m1 , m2 ), ClonePairs(Gm1 , Gm2 ) is empty.
Therefore, we can check whether there is at least one clone by checking whether
ClonePairs(Gm1 , Gm2 ) is empty or not. In other words, the method pair (m1 , m2 )must satisfy the formula (6.5).
ClonePairs(Gm1 , Gm2 ) ̸= ∅(6.5)

6.4.4 STEP-P4: Detect Common and Unique Processes
In this step, the proposed method detects common and unique processes in eachmethod pair. Suppose that a method pair of m1 and m2 is the given method pair,and Gm1(2) is the PDG of method m1(2) .
The proposed method regards statements as common processes if and only
if they are included in code clones existing between the two methods of the given
method pair. We define CommonNodes(Gm1(2) ) as a set of nodes in Gm1(2) whose
representing statements form common processes. The formula (6.6) represents thedefinition, where Gm1(2) indicates the PDG of method m1(2) .
CommonNodes(Gm1(2) ) := {v ∈ VGm1(2) | ∃w ∈ VGm2(1) [v ∼ w]}(6.6)

However, a node in Gm1(2) can be duplicated between two or more nodes in
Gm2(1) . In other words, the formula (6.7) can be satisfied in some cases, considering the two clone pairs (G′m1 , G′m2 ), (G′′m1 , G′′m2 ) ∈ ClonePairs(Gm1 , Gm2 ).
∃v ∈ VG′m

1(2)[v ∈ VG′′m

145

1(2)

]

(6.7)

Algorithm 6.3 Removing Redundant Clone Pairs
Require: ClonePairs(Gm1 , Gm2 )Ensure: ClonePairs(Gm1 , Gm2 ) after repaired
1: CopyOfClonePairs = ∅+2: CopyOfClonePairs ←ClonePairs(Gm1 , Gm2 )′′3: for all (Gm1 , Gm2 ) ∈ CopyOfClonePairs do
4:
for all (G′′m1 , G′′m2 ) ∈ CopyOfClonePairs do
5:
if (∃v1 ∈ G′m1 [v1 ∈ G′′m1 ])&(G′m1 ̸= G′′m1 ) then6:
if |G′m1 | < |G′′m1 | then7:
ClonePairs(Gm1 , Gm2 ) ← (G′m1 , G′m2 )
8:
else
9:
ClonePairs(Gm1 , Gm2 ) ← (G′′m1 , G′′m2 )10:
end if11:
end if12:
if (∃v2 ∈ G′m2 [v2 ∈ G′′m2 ])&(G′m2 ̸= G′′m2 ) then13:
if |G′m2 | < |G′′m2 | then14:
ClonePairs(Gm1 , Gm2 ) ← (G′m1 , G′m2 )
15:
else
16:
ClonePairs(Gm1 , Gm2 ) ← (G′′m1 , G′′m2 )17:
end if18:
end if
19:
end for
20: end for

In this case, we cannot merge all the nodes that are duplicate to other nodes in
the other method. We remove some clone pairs from ClonePairs(Gm1 , Gm2 ) to
resolve this problem. Algorithm 6.3 shows the algorithm for removing clone pairs.
Note that |R| means the number of elements in a set R and R ← r means theprocess to remove an element r from R.
This algorithm ensures that there is at most one duplicate node in the othermethod for all nodes in method m1 and m2 . Nodes should be pulled up into thebase class if they are contained in CommonNodes(Gm1(2) ) after this processing.
Figure 6.10 shows an instance of method pairs that contain redundant clone
pairs. There are two clone pairs; one is labeled with ‘α’, and another one is labeledwith ‘β’. The clone pair α consists of ({a, b, c, d, e}, {A, B, C, D, E}), and theclone pair β consists of ({a, b, d, e}, {F, G, H, I}). In this case, the algorithm
selects α as the remaining clone pair, and removes β from ClonePairs(Gm1 , Gm2 )because the number of elements of α is larger than those of β. As a result, thecommon statements that the proposed method detects in this method pair (m1 , m2 )become as follows.
146

a

b

c

A

α
d

B

C

e

F

D

G

E

H
I

β
f

J

method m1

method m2

Figure 6.10: An example of Method Pairs Including Redundant Clone Pairs

CommonNodes(Gm1 ) = {a, b, c, d, e}CommonNodes(Gm2 ) = {A, B, C, D, E}
On the other hand, the proposed method regards that program statements form
unique processes in a given method pair if they are not included in the common
processes. We define DiﬀNodes(Gm1(2) ) as a set of nodes in Gm1(2) that needto remain in the derived class that has method m1(2) . Formula (6.8) shows thedefinition of DiﬀNodes(Gm1(2) ).
DiﬀNodes(Gm1(2) ) := {v ∈ VGm1(2) | v ∈/ CommonNodes(Gm1(2) )}(6.8)

In the method pair (m1 , m2 ) shown in Figure 6.10, DiﬀNodes(Gm1(2) ) becomes as follows.
DiﬀNodes(Gm1 ) = {f }DiﬀNodes(Gm2 ) = {F, G, H, I, J}
6.4.5 STEP-P5: Detect Sets of Statements Extracted as a Single Method
In this step, the proposed method detects sets of statements that can be extracted
as a single method in the unique processes. For applying Form Template Method
147

a
d

b
e

f

c

a

h

d

g

b
e

f

c
h

g
i

l

j

i

l

j

k
m

k
m

Nodes contained in CommonNodes

An ENS

Figure 6.11: An example of the Detection of ENSs
refactorings, it is necessary that nodes remaining in derived classes are extracted
as new methods. Therefore, we have to detect sets of program statements included
in DiﬀNodes(Gm1(2) ), each of which can be extracted as a single method. The
reminder of this chapter represents a set of nodes that should be extracted as asingle method as an Extract Node Set (in short, ENS).
Definition of the Extract Node Set
The proposed method regards nodes included DiﬀNodes(Gm1(2) ) as an ENS
if there is at least one path that does not include nodes in CommonNodes(Gm1(2) )for any pairs of the nodes in it ignoring directions of each edges. In other words,
we regard a set of nodes Sm1(2) ⊂ VGm1(2) as an ENS if there is at least one paththat satisfies the formula (6.9) for any two nodes v1 , vn (v1 ̸= vn ) in Sm1(2) .
∀i ∈ {1 . . . n}[vi ∈ DiﬀNodes(Gm1(2) )](6.9)

In the example shown in Figure 6.11 we can find two ENSs; one consists of{d, g} and the other consists of {b, c, h, k, l}. As shown in this example, each of
methods in refactoring candidates can contain multiple ENSs. This study uses aterm DiﬀNodeSets(Gm1(2) ) to represent a family of ENSs in method m1(2) . Suppose that m1 indicates the name of the method shown in the figure, and Gm1 indicates its PDG, then, in the example of Figure 6.11, DiﬀNodeSets(Gm1 ) becomes
as follows.
148

Before1: double width = triangle.getWidth();
2: double height = triangle.getHeight();
3: double area = width * height / 2:
4: System.out.println(“The area is “ + area);

1

2

width

e1

e2

height3
e3 areaAfter
1: double width = triangle.getWidth();
2: double height = triangle.getHeight();
3: double area = calcArea(width, height):
4: System.out.println(“The area is “ + area);4: Cloned Statements: An ENS

Figure 6.12: An Example of Inputs and Outputs of ENSs

DiﬀNodeSets(Gm1 ) = {{d, g}, {b, c, h, k, l}}Note that any of nodes in DiﬀNodes(Gm1(2) ) must be included in at least andat most one ENS in DiﬀNodeSets(Gm1(2) ) (forumla (6.10)).
∀v ∈ DiﬀNodes(Gm1(2) ) ∃S ∈ DiﬀNodeSets(Gm1(2) )[v ∈ S]

(6.10)

Parameters of ENSs
Parameters of the method created by extracting an ENS S can be defined as
variables represented by data dependence edges whose heads are included in S
and whose tails are not included in S. Assume that G indicates a PDG, andS indicates an ENS of G. Under these assumptions, we define a set of data
dependence edges whose tails are not included in S and whose heads are included in S as InputDataEdges(G, S). Formula (6.11) shows the definition of
InputDataEdges(G, S).

InputDataEdges(G, S) :={e ∈ EG | (tail (e) ∈/ S) ∧ (head (e) ∈/ S) ∧ (type(e) = data)} (6.11)
Here, we define a set of variables to represent parameters of the method createdby extracting S consist as InputVariables(S) in forumla (6.12).
149

InputVariables(G, S) :={p | ∃e ∈ InputDataEdges(G, S)[var (e) = p]} (6.12)
In the example of Figure 6.12, there is an ENS consisting of the 3rd line. In
this case, InputDataEdges(G, S) and InputVariables(G, S) become as follows
InputDataEdges(G, S) = {e1 , e2 }InputVariables(G, S) = {width, height}
Thus, a method created by extracting the ENS needs two parameters, one iswidth, and the other is height.
Output of ENSs
Suppose that G indicates a PDG of a method, and S indicates an ENS of G.
The output values of the method created by extracting S are defined as variables
that are represented by data dependence edges whose heads are not included in S
and whose tails are included in S.
First, we define OutputDataEdges(G, S) as a set of data dependence edges
whose tails are included in S and whose heads are not included in S. The definitionis shown in formula (6.13).
OutputDataEdges(G, S) :={e ∈ EG | tail (e) ∈ S ∧ head (e) ∈/ S ∧ type(e) = data} (6.13)
Herein, we can define a set of output variables of S with this definition. We
define it as OutputVariables(G, S) in the formula (6.14).
OutputVariables(G, S) :={p | ∃e ∈ OutputDataEdges(G, S)[p = var (e)]} (6.14)
In the example of Figure 6.12, OutputDataEdges(G, S) and OutputVariables(G, S)
become as follows.
OutputDataEdges(G, S) = {e3 }OutputVariables(G, S) = {area}
Therefore, a method created from the ENS needs to return a value of double.
150Conditions for Call
The conditions to call methods created by extracting ENSs are represented bycontrol dependence edges. For example, if there are control dependences from a
conditional predicate of if statement to all the nodes included in an ENS S, amethod created from S should be called in the case that the conditional predicate
is satisfied.
First, we define InputControlEdges(G, S) as a set of control dependenceedges whose tails are not included in S and whose heads are included in S in
the formula (6.15), where G is a PDG of a method and S is an ENS of G.

InputControlEdges(G, S) :={e ∈ EG | tail (e) ∈/ S ∧ head (e) ∈ S ∧ type(e) = control } (6.15)
In the next, we define nodes that have control dependences to nodes included
in S as InputControlNodes(G, S). The definition is shown in formula (6.16).

InputControlNodes(G, S) :={v ∈ VG | ∃ec ∈ InputControlEdges(G, S)[v = tail (ec )]} (6.16)
As described above, a PDG has a method enter node, and there are control dependencies from the node to all the nodes that are directly contained by the method.
In addition, nodes contained in conditional blocks have control dependence fromthe conditional predicates of the blocks. In this case, there is no control dependence
from the method enter node to nodes contained in conditional blocks because thesenodes are not directly contained by the method. Therefore, all the nodes except
the method enter node have at least and at most one control dependence from othernodes.
Requirements for ENSs to be Extracted as a Single Method
In some cases, we cannot extract each of ENSs as a single method. Concretely,
we cannot extract an ENS S as a single method if it satisfies the following conditions.
• There are multiple return values in the method created from S.
• S includes a part of nodes in a block statement, and it also includes somenodes out of the block statement.
151

Multiple Return Values
It is necessary that an ENS S has at most one return value to be extracted asa method. Therefore, if there are two or more return values of S, it cannot be
extracted as is.
To resolve this problem, we divide S into multiple ENSs satisfying the condition. Here, we describe the algorithm.
First, we define a set of nodes in S that locate at boundary of data dependences
between S and out of S as BoundaryNodes(G, S). Formula (6.17) is its definition.

BoundaryNodes(G, S) :={v ∈ VG | ∃e ∈ OutputDataEdges(G, S)[tail (e) = v]} (6.17)+
Then, we divide S with the Algorithms 6.4, 6.5, and 6.6. Note that R ← rmeans adding an element r into a set R. Besides, detect(v, S) and parse(S, R)
indicates the following processing, respectively.
detect(v, S): Return an ENS S ′ satisfying the condition that BoundaryNodes(G, S ′ ) ={v} by dividing the original ENS S.
parse(S, R): Return a node set R′ created by adding some nodes into the specified node set R. The added nodes must be reached from a node in R by
tracing an edge in the reverse direction. Moreover, the addition of nodes
must preserve the condition that |BoundaryNodes(G, R)| = 1.
Here, we describe the behavior of the algorithm with the example shown in
Figure 6.13.
In the beginning, BoundaryNodes(G, S) = {n, o}. Here we consider the casethat detect(n, S) is called in the 3rd line in Algorithm 6.4.
In detect(n, S), a node set R is initialized with n, then R is expanded by traceedges in the reverse direction. Obviously, |BoundaryNodes(G, R)| = 1.
In the next, parse(S, R) is called. At first, we reach a node k and we need tojudge whether it can be added into R or not. In this case, k has no dependences
to nodes except n, therefore we judge that it can be included in R. In the next,
we reach another node f . The node f has two dependences whose tail is f ; one isto k, and the other is to another node i. Herein, the node i are not included in R.
Consequently, if we add f into R, BoundaryNodes(G, R) becomes {f, n}. Thus
we judge that we cannot add f into R. parse(S, R) stops here because there is nonodes that can be a candidate of expansion, and it returns R′ = {k, n}.
152

Algorithm 6.4 Division of an ENS
Require: G, S
Ensure: SeparetedNodeSets
1: while S ̸= ∅ do2:
for all v ∈ BoundaryNodes(G, S) do+
3:
SeparetedNodeSets ←detect(v, S)
4:
end for5:
for all T ∈ SeparetedNodeSets do
6:
for all v ′ ∈ T do
7:
S ← v′
8:end for9:
end for
10: end while

Algorithm 6.5 detect(v, S)
Require: v, S
Ensure: R
1: R ← {v}
2: while |R| ̸= |parse(S, R)| do
3:
for all v ′ ∈ parse(S, R) do+
4:
R ←v ′
5:end for
6: end while

Algorithm 6.6 parse(S, R)
Require: S, R
Ensure: R′
1: R′ = R
2: for all v ∈ R do
3:
for all e ∈ BackwardEdges(v) do
4:
if tail (e) ∈ S ∧ tail (e) ∈/ R then5:
if ∀ed ∈ ForwardDataEdges(tail (e))[head (ed ) ∈ R] then+
6:R′ ←tail (e)7:end if8:
end if
9:end for
10: end for

153

a
b

c

d

j

f

g

i

k

h
y z

l

x
n

z e z

y

i

i

After Resolved

a

y
y

x

z
o

b

d

f

i

j

m

g
i

k

z
o

y

n

Sx

i
w

m

y

x

Sy

q

p

r

h
y z

l

x
S

z e z

y

Si i

i
w

q

p

c

r
Figure 6.13: Behavior of Algorithm 6.4

1: if (x > 0) {2: y = x;
3: z = x * 2;
4: }5: w = x + y + z;

S

Figure 6.14: An Instance of Segmentalization of Block Statements

Then the algorithm backs to the 3rd line in Algorithm 6.4. Here, detect(o, R)
is called, and it returns R′ = {d, e, g, h, i, l, m, o}.
Then the algorithm goes to the 5th line in Algorithm 6.4. Here, nodes included
in any element in SeparetedNodeSets are removed from the original ENS S. In thiscase, SeparetedNodeSets = {{k, n}, {d, e, g, h, i, l, m, o}}, therefore S becomes
S = {f, c}.
The algorithm repeats this process until S ̸= ∅. Finally, we get 3 ENSs Sx , Sy ,and Si from the original ENS S, and all of them have to return only a single value
x, y, and i, respectively.
154

Segmentalization of Block Statements
Suppose that Nodes(b) indicates a set of nodes that are included in the given
block statement b. If an ENS S satisfies all the following formulae (6.18) and(6.19), we cannot extract it as a single method.

∃v ∈ Nodes(b)(v ∈ S) ∧ ∃u ∈ Nodes(b)(u ∈/ S)(6.18)∃v ∈ S(v ∈ Nodes(b)) ∧ ∃u ∈ S(u ∈/ Nodes(b))(6.19)

Figure 6.14 shows an instance of ENSs that satisfy these formulae. As thisfigure shows, we cannot extract S as is. This is because one node in S is included
in if statement, and the other node is not included in the statement. To resolve
this problem, we restrict nodes in each of ENSs to be in the same block statement.
By this restriction, the 3rd line and the 5th line in Figure 6.14 can be included in
the same ENS. Therefore, we get two ENSs in this example, and each of them canbe extracted as a single method.
6.4.6 STEP-P6: Detect Pairwise Relationships
In this step, we detect pairwise relationships of ENSs in a given method pair.
In other words, assuming that ⇌ indicates the pairwise relationships and Sm1(2) isan ENS of method m1(2) , for each of Sm1(2) ∈ DiﬀNodeSets(Gm1(2) ) we detect
whether Sm2(1) ∈ DiﬀNodeSets(Gm2(1) ) satisfies Sm1 ⇌ Sm2 exists or not. Notethat Sm1 ⇌ Sm2 indicates that Sm1 and Sm2 can be extracted as methods whose
signatures are the same as each other. If an ENS S has no correspondent in theother method, we have to make an empty method whose signature is the same as S
in the derived class that does not have S.
We regard a pair of ENSs Sm1 and Sm2 as Sm1 ⇌ Sm2 if they satisfy thefollowing two requirements.
Requirement P6-1: The types of return values of Sm1 and Sm2 are the same aseach other.
Requirement P6-2: The conditions to call the new methods created by extracting
Sm1 and Sm2 are the same as each other.
The following subsections describe these requirements in detail. Herein, EM Sm1(2)means the method created by extracting the ENS Sm1(2) .
155

Requirement P6-1: Requirement the Type of the Return Value
To make EM Sm1 and EM Sm2 have the same signature, it is necessary that thetypes of return values of EM Sm1 and EM Sm2 are same to each other.
As described in 6.4.5, the return values of EM Sm1(2) are defined as
OutputVariables(Gm1(2) , Sm1(2) ) (formula (6.14)). In addition, the number of elements in OutputVariables(Gm1(2) , Sm1(2) ) is at most one because of the processing described in 6.4.5.
We define that EM Sm1 and EM Sm2 have the same type of the return value if
they satisfy formula (6.20).

(|OutputVariables(Gm1 , Sm1 )| = |OutputVariables(Gm2 , Sm2 )|)∧ (∀p ∈ OutputVariables(Gm1 , Sm1 )∃q ∈ OutputVariables(Gm2 , Sm2 )[varType(p) = varType(q)]) (6.20)
Note that we do not consider parameters of EM Sm1 and EM Sm2 to detect
the pairwise relationships. This is because we can make them having the same
signature by adding non-used parameters in the case that the parameters of EM Sm1
and EM Sm2 are different. For example, suppose that EM Sm1 needs one parameter
whose type is integer and EM Sm2 needs one parameter whose type is string. In
this case, we can match the signatures of EM Sm1 and EM Sm2 by adding a string
parameter in EM Sm1 and an integer parameter EM Sm2 .
Requirement P6-2: Requirement about Conditions for CallTo extract EM Sm1 and EM Sm2 as same signature methods, it is necessary thatEM Sm1 and EM Sm2 are called under the same conditions.
Figure 6.15 shows an example of wrong correspondence of ENSs. This iscaused by not considering the conditions for call of each ENSs. In this example,
there are two ENSs A1 and A2 in methodA, and there are also two ENSs B1 andB2 in methodB. All of the ENSs are in if statements, which means that methods
created by extracting these ENSs are called if the conditional predicates of the corresponding if statements are satisfied. However, the pairwise relationships shownin the figure do not consider the conditions, therefore the behavior of methodB ischanged after the refactoring.
As described in 6.4.5, the conditions to call EM Sm1(2) are represented by control dependence edges, and all the nodes always have one control dependence fromother nodes. In addition, all the nodes in an ENS are contained by a single blockstatement or contained by their owner method directly by the process described in156

if (x == 0) {A1
System.out.println(“2nd line”);}

B1
if (x == 0) {System.out.println(“2nd”);}

if (y == 1) {A2
System.out.println(“6th line”);}

if (y == 1) {B2
System.out.println(“6th”);}

method A

method B
if (x == 0) {process2ndLine();}System.out.println(“2nd line”);

if (y == 1) {process6thLine();}System.out.println(“6th line”);

System.out.println(“6th”);

System.out.println(“2nd”);

behavior is changed
Figure 6.15: An Example of Wrong Pairwise Relationships Caused by not Considering Conditions for Call

6.4.5. Consequently, all the control dependence edges to S have the same tail node.
In other words, the formula (6.21) is always satisfied for every ENS S.
|InputControlNodes(G, S)| = 1(6.21)

Here, we define ICN S as the unique element in InputControlNodes(G, S).
We regard a pair of ENSs (Sm1 , Sm2 ) as having same conditions for call if andonly if they satisfy the formula (6.22).

(ICN Sm1 ∼ ICN Sm2 )∨(∃S1′ ∈ DiﬀNodeSets(Gm1 )∃S2′ ∈ DiﬀNodeSets(Gm2 )[S1′ ⇌ S2′ ∧ ICN Sm1 ∈ S1′ ∧ ICN Sm2 ∈ S2′ ]) (6.22)
157

methodm1

method
m2

a

b

d

c

e

B

g
x(int)

C

E

f

β
α

A

F

D
h

γ

str(String)Gi(int)i

H

I: Clone Nodes: Control Dependence

α

β

γ

δ

int

Stringint

Stringtext(String)“*” means
Method EnterNode: Non-Clone Nodes: Data Dependenceδ

Input Control Node
α

β

γ

δ

*

c

*

C

c～C
Satisfy Requirement P6-1

Satisfy Requirement P6-2α⇀↽δ↽γ，β ⇀
Figure 6.16: An Example of Pairwise Relationships
An Example of Pairwise Relationships Detection
Figure 6.16 shows an example of pairwise relationships detection. Note that
this figure ommits method enter nodes and control dependence.
In this example, there are two ENSs α and β in method m1, and there are also
two ENSs γ and δ in method m2. Return values of EMα and EMγ are integer
values, and return values of EMβ and EMδ are string values. Consequently, twopairs of ENSs (α, γ) and (β, δ) satisfy Requirement P6-1.
Then, the proposed method checks the correspondence of call conditions. In
this example, ICN α and ICN γ are the method enter nodes, which means that a158

pair of ENSs (α, γ) satisfies Requirement P6-2. In the case of (β, δ), ICN β is c,
and ICN δ is C. Consequently, the pair of ENS (β, δ) satisfies Requirement P6-2
because c ∼ C.
As a result, we get two pairs of ENSs (α, γ) and (β, δ) in this example.

6.5 Supporting for Method Groups
In this section, we describe the steps of the proposed technique for method
groups. As described in 6.3.3, we use method pair information calculated in STEPP1 to STEP-P6, therefore the steps from STEP-S1 to STEP-S6 are identical tofrom STEP-P1 to STEP-P6. Therefore, we describe the steps after STEP-S6 in thefollowing subsections.
6.5.1 STEP-S7: Identify Method Groups
This step detects groups of methods on which Form Template Method can be.
applied. In the reminder of this chapter, suppose that m1 = m2 indicates that a pairof methods m1 and m2 is a refactoring candidate detected in the process describedin 6.4.3.
.
.
.
Obviously, the binary relation = is a symmetric relation (m1 = m2 ⇒ m2 =m1 ). However, it is not a transitive relation. Assume that there are three methods.
.
m1 , m2 and m3 , and m1 = m2 , m2 = m3 . In this case, there is at least one clone.
pair between m1 and m2 , and between m2 and m3 because of the definitions of =.
However, there is no clone pair between m1 and m3 if all the clone pairs between
m1 and m2 are not overlapped by any of clone pairs between m2 and m3 . If there.
is no clone pair between m1 and m3 , m1 ≠ m3 because of its definitions.
However, the proposed method temporarily regards a group of methods as a
candidate method group if it satisfies the formula (6.23).
.
∀m ∈ MS , ∃m′ ∈ MS (m = m′ )(6.23).
.
Under this definition, if m1 = m2 and m2 = m3 are satisfied, a group of
methods m1 , m2 , and m3 is regarded as a candidate method group regardless of.
whether m1 = m3 is satisfied or not. If there is no clone pairs between m1 andm3 , the proposed method omits the method group from candidate method groups
in the next step.
6.5.2

STEP-S8: Detect Common and Unique Processes

In this step, the proposed method detects common processes and unique processes in every method group. Suppose that MS indicates a method group and Gmi
159

a
b
d

c
e

A

A

f

B
D

1

B

C

D

E

C

E

h

2

3

4

5

6

7

b
d

e

1
c

2

3

f

4

5

h

6

7

G

G
g

a

F

F

g

i

H

H

8

i

8

methodm1

methodm2

methodm2

methodm3

methodm1

method
m3

a
b
d

A
c

e

f

B
D

1
C

E

2

3

4

5

6

7

G

: Common Nodesgh: Unique Nodes

F

i

H

8

methodm1

methodm2

methodm3

Figure 6.17: An Example of Method Groupmeans the PDG of method mi .
Statements must be duplicated between all the methods in the method group
to be pulled up into a base class as a template method. We use the representation
CommonNodes group (Gmi ) for a group of nodes in VGmi that are pulled up into abase class. The definition is shown in formula (6.24).

CommonNodes group (Gmi ) :={vi ∈ VGmi | ∀mj ∈ MS , ∃vj ∈ VGmj [vi ∼ vj ]} (6.24)
We define DiﬀNodes group (Gmi ) as a group of nodes that need to remain in thederived class that has method mi . The definition is shown in the formula (6.25).

DiﬀNodes group (Gmi ) :={vi ∈ VGmi | vi ∈/ CommonNodes group (Gmi )} (6.25)
Figure 6.17 shows an example of method group. In this example, there arethree methods (m1, m2, and m3) and all the pairs of them are detected as can.
.
.
didate method pairs, in other words m1 = m2, m2 = m3, and m1 = m3. In
this example, CommonNodes group (Gm1 ) and DiﬀNodes group (Gm1 ) become asfollows.
160

CommonNodes group (Gm1 ) = {a, b, c, i}
DiﬀNodes group (Gm1 ) = {d, e, f, g, h}
In some cases, some nodes included in CommonNodes(Gmi ) are omitted tomake CommonNodes group (Gm1 ). Consequently, the amount of common processes on method groups might be quite smaller than that on method pairs. As
a result, the number of elements in CommonNodes(Gmi ) might be less than thethreshold of minimum code clone size that is specified by users. Therefore, the proposed method omits method groups if the number of their common nodes is less.
.
than the minimum clone size. Consequently, in the case that m1 = m2 , m2 = m3 ,.
and m1 ≠ m3 , the proposed method omit the method group that consists of m1 ,m2 , and m3 .
In the next, the proposed method detects ENSs for every method in MS . Thereis no difference in the definitions of ENSs between method pairs and method
groups because the detection of ENSs is closed in each method.
6.5.3 STEP-S9: Detect Relationships on ENSs
In this step, the proposed method detects correspondences of ENSs between
methods in MS .
Likewise on method pairs, the correspondence relationship means that ENSs
in a correspondence relationship can be extracted as methods whose signatures are
the same. As described in 6.4.6, the proposed method regards a pair of ENSs Sm1
and Sm2 as Sm1 ⇌ Sm2 if they satisfy the requirements about their return values
and their call conditions. We can detect this relationship by expanding that on
method pairs.
Suppose that Sm1 , Sm2 , and Sm3 are ENSs in methods m1 , m2 , and m3 , respectively. In addition, assume that Sm1 ⇌ Sm2 and Sm2 ⇌ Sm3 . Moreover,assume that EM S means a method created by extracting an ENS S. Under theseassumptions, the types of return values EM Sm1 and EM Sm2 are the same. Moreover, those of EM Sm2 and EM Sm3 are also the same. Therefore, the return valuesof EM Sm1 and EM Sm3 are the same. Similarly, the call conditions for EM Sm1 ,EM Sm2 , and EM Sm3 are same to each other. Consequently, the binary relationship⇌ is a transitive relation (Sm1 ⇌ Sm2 ∧ Sm2 ⇌ Sm3 ⇒ Sm1 ⇌ Sm3 ).
Obviously, the binary relation ⇌ is a symmetric relation (Sm1 ⇌ Sm2 ⇒Sm2 ⇌ Sm1 ). Moreover, it is also a reflexive relation (Sm1 ⇌ Sm1 ). Consequently, the binary relation ⇌ is an equivalence relation.
Therefore, we can detect correspondence relationships between three or more
ENSs by detecting equivalent classes.
161

Source Code of the Methods
in the Selected Method Pair

Button to Call Filtering Function

List of Method Pairs

Figure 6.18: A Whole Snapshot of CRat (for Method Pairs)

6.6 Implementation
6.6.1 Overview
We have implemented the proposed method as a tool named CRat (Clone Removal Assistant Tool) in Java. CRat can handle software systems written in Java,because Scorpio, the clone detection tool used in CRat, can handle only Java. However, the proposed method can be applied to other programming languages if PDGs
can be built.
The LOC of CRat is 17,290 with comments and white lines. It becomes 11,125
without comments and white lines. Moreover, CRat consists of 136 source files. In
addition, it uses the external libraries except for Scorpio and MASU.
JUNG: JUNG (Java Universal Network/Graph Framework) is a framework thatprovides software libraries for the modeling, analysis, and visualization ofdata that can be represented as a graph or network [67]. CRat uses it tovisualize PDGs. JUNG is an open source project in SourceForge likewise
MASU.
CRat has two modes. One is for method pairs, and the other is for method
groups. We describe each of them in detail in the following subsections. Note that
CRat does not modify the source code by itself. Therefore, users need to performsource code modification by their own effort.
6.6.2 Functionalities for Method Pairs
Figure 6.18 shows a snapshot of CRat for method pairs. The table shows all
the candidate method pairs that CRat detected. When users select a method pair162

Common Statements

To Be Extracted as theSame Signature Method

An ENS

Figure 6.19: A Snapshot of Source Code View

from the table, the source code of methods included in the pair is shown in the rightpanel.
Figure 6.19 shows a snapshot of source code view. In the source code view,common statements are highlighted with red. Statements highlighted by red meanthat they should be pulled up into the base class as a template method. On theother hand, the other statements are unique processes in each method. Statements
surrounded by the same color rectangles make an ENS. In addition, if users clickstatements that are not highlighted by red, an ENS that includes the statements ishighlighted. Moreover, if users click an ENS in one method, CRat also highlights
the corresponding ENS in the other method. ENSs highlighted by the same color
are under the correspondence relationship (Sm1 ⇌ Sm2 ), which indicates that themethods created by extracting them have the same signature. Additionally, CRatshows the signature of the method created from an ENS if users put cursor on the
ENS.
CRat also has a PDG view. Figure 6.20 shows a snapshot of PDG view. Eachcircle indicates a node of PDG, and each line indicates an edge of PDG. Nodes colored by red are nodes whose owner statements are included in common statements.
The blue lines indicate data dependence edges, and the black broken lines indicate
control dependence edges. The character string on each data dependence edge indicates the name of the variable that the edge represents. Note that CRat omits
the method enter nodes and execute dependence edges in PDG view. To visualize
163

Control Dependence Edge

Common Statements
Data Dependence Edge

Unique Statements

Figure 6.20: A Snapshot of PDG View
PDGs, CRat uses APIs provided by JUNG.
CRat can show both the source code view and PDG view at a time. Figure 6.21
shows the apposing view of source code view and PDG view. The functionalitiesof the source code view and the PDG view in the apposing view are exactly sameto the original ones.
In addition, CRat has a filtering function of method pairs with some metrics.
All the metrics are calculated for each method pair. The metrics are as follows
under the assumption that m1 and m2 are methods in a method pair, and Gm is the
PDG of the method m.
SIM: The similarity between two methods of each method pair (defined in theformula (6.26)).

SIM :=|CommonNodes(Gm1 )| + |CommonNodes(Gm2 )||VGm1 | + |VGm2 |(6.26)

CN: The number of nodes whose owner statements are included in common statements (defined in the formula (6.27)).
CN := |CommonNodes(Gm1(2) )|(6.27)

DN+, DN-: The number of nodes whose owner statements are not included incommon statements. Note that the values of this metric are different between
164

Figure 6.21: A Snapshot of Apposing View of Source Code View and PDG View
each method. Therefore, we define DN+ as the larger one (formula (6.28)),and DN- as the smaller one (formula (6.29)), respectively.

DN + := max (|DiﬀNodes(Gm1 )|, |DiﬀNodes(Gm2 )|) (6.28)
DN − := min(|DiﬀNodes(Gm1 )|, |DiﬀNodes(Gm2 )|)(6.29)

LOC+, LOC-: The number of lines of each method. Obviously, the values ofthis metric are different between each method. Likewise DN+ and DN-, wedefine LOC+ as the larger one, and LOC- as the smaller one, respectively.
DG: The number of new methods that are created by extracting ENSs. DG isdefined in the formula (6.30), where N is the number of ENSs that have theircorrespondents in the other method. Note that the ‘correspondent’ of an ENS
S1 is ⇋ (S1 ).

DG := |DiﬀNodeSets(Gm1 )| + |DiﬀNodeSets(Gm2 )| − N
165(6.30)

BaseClass

Common Statements

SubClassA

SubClassB
ENSs

SubClassC

StringBuilder builder = new StringBuilder();StringBuilder builder = new StringBuilder();if (Setting.isVerbose()) {System.out.println(“create a string”);}
builder.append(“A”);
builder.append(“B”);
builder.append(“C”);
builder.reverse();return builder.toString();builder.append(“A”);
builder.append(“B”);
builder.append(“C”);
builder.insert(1,”D”);
return builder.toString();

Figure 6.22: An Example of Candidate Method Pair
DOI: The depth of inheritance from the common base class to the owner classesof the two methods. If the value is different for each method, we choose thelarger one as the value of DOI.
Table 6.1 shows the values of metrics of the method pair shown in Figure 6.22.
Note that the values of inheritance depth from the common base class are different
for each class that has the target method, therefore the larger value ‘2’ is chosen as
the value of DOI in this example.
Users can make a short list of candidate method pairs with the filtering function.
The filtering function returns a list of method pairs whose metrics values are in therange that users specified. To call the filtering function, users push the button on
the top of the table listing the method pairs.

Table 6.1: The Values of Metrics in the Method Pair of Figure 6.22
SIM CN DN+ DN- LOC+ LOC- DG DOI
0.769
5
3
1
9
6
2
2
166

Metrics Graph

List of Method Pairs
that Pass the Filter

Metrics Values

Figure 6.23: A Snapshot of Filtering View

The number of
selected method pairs / all the method pairs

Each method pair corresponds to a single polygonal curve
the red one is in the range at all the metrics
the gray one is not in the range at some of metrics

The range of valuesof each metric

Metrics

Figure 6.24: A Metrics Graph

167

The Lower Limit

The Upper Limit

Figure 6.25: View of the Metrics Values
A filtering view is launched when users push the button. Figure 6.23 shows asnapshot of the filtering view. The filtering view consists of three parts: a metrics
graph, a list of metrics values, and a list of method pairs that pass the filtering.
Figure 6.24 shows a metrics graph. Users specify the thresholds of each metric bydragging the graph. The area whose background color is gray indicates the range ofthresholds for every metric, and the area whose background color is white indicatesthe outside of the range. In the metric graph, each polygonal curve corresponds toa method pair. The polygonal curve becomes red if and only if all the metrics ofthe method pair represented by the polygonal curve are in the specified threshold.
If any of the metrics is not in the threshold, the polygonal curve becomes gray. The
specified lower limit and the specified upper limit of each metric are shown in themetrics values view (Figure 6.25). The list of selected method pairs is shown in theright of the filtering view. Users can view the source code and the PDGs of method
pairs that are listed in the view. The functionalities of the source code view and the
PDG view in the filtering view are exactly same to the original ones.
6.6.3 Functionalities for Method Groups
Figure 6.26 shows a snapshot of CRat for method groups. The left table shows
all the candidate method groups that CRat detected. When users select a method
group from table A, all the methods in the selected method group are shown in
the tables B-1 and B-2. Note that the tables B-1 and B-2 show the same contents.
If users choose one of the methods in table B-1, the source code of the selected
method is shown in the source code view C-1. Similarly, if users choose one of themethods in table B-2, its source code is shown in the source code view C-2. The
source code view and the PDG view are the same to those of described in 6.6.2.

6.7 Evaluation
In order to evaluate the proposed method, we conducted experiments on two
open source software systems. Table 6.2 shows the target software systems, theirscale, and the environment of the experiments. The following subsections describe
each of the experiments.
168

Source Code of theSelected Methods

B-1

List of Methods
in the Selected
Method Group

C-1

C-2

B-2

A

List of
Method Groups

Figure 6.26: A Whole Snapshot of CRat (for Method Groups)
6.7.1 Evaluation of Supporting for Method Pairs
Table 6.3 shows the the number of detected candidates, and elapsed time to
execute CRat on each target software system. The numbers of candidate method
pairs are 226 and 45, so that it can be difficult for users to identify all the candidates
manually. In addition, CRat can detect all the candidates in a few minutes although
the target software systems have hundreds of source files.
Figure 6.27 shows a refactoring candidate in Ant detected by CRat and theresult of the refactoring. In this example, there is a base class, ClearCase,

Name
Ant
SynapseTable 6.2: Target Software Systems
LOC # of Files
Environment
212,401829
CPU: Xeon 2.27GHz(8 core)，RAM: 32GB
58,418383

Table 6.3: The Number of Detected Candidates and Elapsed Time on Method Pairs
Name# of Candidates Elapsed Time [s]
Ant
226
178
Synapse45
66
169

ClearCase

if (getComment() != null) {…
} else {…
}ClearCasecheckOption(cmd)checkOther(cmd)pull up
CCCheckout

CCCheckin

CCCheckout

CCCheckincheckOption(cmd)checkOption(cmd)checkOther(cmd)checkOther(cmd)

if (getNoWarn()) {…
}checkOther(cmd);

cmd.createArgument().setValue(getViewPath());

extract
if (getReserved()) {cmd.createArgument().setValue(FLAG_RESERVED);} else {cmd.createArgument().setValue(FLAG_UNRESERVED);}…

A

if (getNoWarn()) {cmd.createArgument().setValue(FLAG_NOCOMMENT);}B

if (getComment() != null) {getCommentCommand(cmd);} else {if (getCommentFile() != null) {getCommentFileCommand(cmd);} else {cmd.createArgument().setValue(FLAG_NOWARN);}}C

cmd.createArgument().setValue(getViewPath());

extractB

if (getComment() != null) {getCommentCommand(cmd);} else {if (getCommentFile() != null) {getCommentFileCommand(cmd);} else {cmd.createArgument().setValue(FLAG_NOCOMMENT);}}A

if (getNoWarn()) {cmd.createArgument().setValue(FLAG_NOWARN);}
if (getPreserveTime()) {cmd.createArgument().setValue(FLAG_PRESERVETIME);}

if (getPreserveTime()) {…
}…
if (getReserved()) {…
} else {…
}…

: Code Clone
method : abstract method…

C

cmd.createArgument().setValue(getViewPath());

Figure 6.27: An Example of Application of Form Template Method with the
Proposed Method

and there are two derived classes, CCCheckout and CCCheckin.There are alsosimilar methods in the derived classes, checkOption. By applying Form Template Method to this target, duplicate statements are pulled up into in the method
checkOption defined in the base class and new methods checkOther are created to implement the unique statements in each derived class. Note that there is adifference of the order of code fragments in code clones: in CCCheckout the codefragments labeled A, B, and C are executed in this order, however in CCCheckinthe order of code fragments is B-A-C. Therefore, this example is an instance thatthe previous techniques cannot detect.
In addition, we applied Form Template Method refactoring to all the 45 candidates that the proposed method had suggested in sf Synapse in order to confirm
the adequacy and the efficiency of the proposed method as a technique to support
refactorings. In this experiment, we successfully refactored all the 45 candidates
detected with CRat in sf Synapse, and confirmed that the behavior of the programis preserved by using test suites attached to the software system. Additionally, wemeasured the time needed to each of the refactorings. Figure 6.28 shows the boxplots of the time needed to apply refactorings. Because CRat suggests that all the
candidates can be refactored at a time, we run CRat at once and apply refactorings
170

3000

2500
2000
1500
1000
500

0
[sec]

Elapsed Time to Refactor

Figure 6.28: The Box-Plot of the Time to Apply Form Template Method on
Synapseusing the output. The time to execute CRat to sf Synapse is 95 seconds as shownin Table 6.3. As a result, we could apply refactorings in few minutes in average
nevertheless we are unfamiliar with the software.

6.7.2 Evaluation of Supporting for Method Groups
Table 6.4 shows the number of detected method groups, the number of themthat have three or more methods, and elapsed time to detect them on each target
software.
Likewise on method pairs, we applied Form Template Method refactoring to
all the six method groups that the proposed method had suggested in sf Synapse.
As a result, we successfully refactored all the candidates and confirmed that the
behavior is preserved by using test suites.

Table 6.4: The Number of Detected Candidates and Elapsed Time on Method
Groups# of Candidates
Name# of Candidates
Elapsed Time [s](3 or more methods)
Ant
48
18
195
Synapse62
68171

6.7.3 Experiment with Subjects
Overview of the Experiment
We conducted an experiment with seven subjects. All the subjects belong to
Graduate School of Information Science and Technology, Osaka University, or Department of Information and Computer Sciences in School of Engineering Science,
Osaka University.
The objective of this experiment is to investigate the effectiveness of the proposed method as refactoring support method. In this experiment, subjects applied
Form Template Method refactoring after a short introduction and practice, and wemeasured elapsed time that they needed to finish the refactoring. All the subjects
refactored two method groups described in 6.7.3. Subjects applied refactorings to
one candidate method group with CRat, and they applied refactorings to the othercandidate with CCFinder.
Target Method Groups
As described above, subjects applied Form Template Method to two method
groups. We call the two method groups Candidate-A and Candidate-B, respectively.
Figure 6.29 shows the source code and the outputs of CRat on each candidate.
The features of the two method groups are shown in Table 6.5.
Prodcedure of the Experiment
The procedure of the experiment consists of five steps as follows.
1. We give a brief introduction to subjects.
2. Subjects apply Form Template Method to a simple example.
3. We divide subjects into four groups. Table 6.6 shows the groups and assignments of each subject.
4. Subjects apply refactorings to the assigned method group.

Table 6.5: The Features of Target Method Groups
Label# of Methods # of Common Nodes # of ENSs
Candidate-A3
193
Candidate-B
12
9
5
172

public PlanarImage executeDrawOperation() {BufferedImage bi = new BufferedImage(width, height,
BufferedImage.TYPE_4BYTE_ABGR_PRE);
Graphics2D graphics = (Graphics2D) bi.getGraphics();
if (!stroke.equals(“transparent”) {BasicStroke bStroke = new BasicStroke(stroke_width);graphics.setColor(ColorMapper.getColorByName(stroke));graphics.setStroke(bStroke);graphics.draw(new Ellipse2D.Double(0, 0, width, height);{
if (!fill.equals(“transparent”)) {graphics.setColor(ColorMapper.getColorByName(fill));grahpics.fill(new Ellipse2D.Double(0, 0, width, height));}for (int i = 0; i < instructions.size(); i++) {ImageOperation instr = ((ImageOperation) instructions.elementAt(i));
if (instr instanceof DrawOperation) {PlanarImage img = ((DrawOperation) instr).executeDrawOperation();graphics.drawImage(img.getAsBufferedImage(), null, 0, 0);} else if (instr instanceof TransformOperation) {graphics = (Graphics2D) bi.getGraphics();
PlanarImage image = ((TransformOperation) instr).executeTransformOperation(PlanarImage.wrapRenderedImage(bi));bi = image.getAsBufferedImage();}}return PlanarImage.wrapRenderedImage(bi);}: Common Statements: ENSs(a) Candidate-A
public void execute throws BuildException {Commandline commandline = new Commandline();Project aProj = getProjcet();int result = 0;
if (getViewPath() == null) {setViewPath(aProj.getBaseDir().getPath());}

commandLine.setExecutable(getClearToolCommand());
commandLine.createArgument().setValues(COMMAND_MKBL);
checkOption(commandLine);if (!getFailOnErr()) {getProject().log(“Ignoring any errors that occur for: “ +getBaselineRootName(), Ptoject.MAG_VERBOSE);}
result = run(commandline);
if (Execute.isFailure(reault) && getFailOnErr()) {String msg = “Failed executing: “ + commandLine.toString();
throw new BuildException(msg.getLocation());}}: Common Statements: ENSs(b) Candidate-B

Figure 6.29: Candidate Method Groups

173

5. Subjects apply refactorings to the other method group.

Introduction to subjects
At first, we gave an introduction to subjects about the background of this study
and the experimental procedure. The introduction includes the following information.
• Code clones and their removal techniques.
• Form Template Method refactoring pattern.
• How to apply Form Template Method.
• How to use CRat.
• The procedure of the experiment.
Practice
Second, we have subjects practice applying Form Template Method with asimple method group. The target method group consists of two methods, and it
contains two ENSs (note that we count a pair of ENSs (S1 , S2 ) as 1 ENS if S1 ⇌S2 ). The purposes of the practice are (1) to have subjects understand refactoring
steps of Form Template Method, and (2) to have subjects be familiar with thetool.

Table 6.6: Groups of Subjects
Group ID Subjects
First
SecondSubject 1 Candidate-A Candidate-B
1
Subject 2
CRat
CCFinderCandidate-B Candidate-A
2
Subject 5
CRat
CCFinderSubject 6 Candidate-A Candidate-B
3
Subject 7
CCFinderCRat
Subject 3 Candidate-B Candidate-A
4
Subject 4
CCFinderCRat174

GroupingIn the next, we divide subjects into four groups. Table 6.6 shows the groups ofsubjects. As this table shows, the differences between each group are as follows:• Which candidate do they refactor first?
• Which candidate do they use CRat?
Apply Refactoring
Subjects apply refactoring to the assigned target method group. For example,
subjects in Group 1 refactor candidate A with CRat. We measure the elapsed timerequired to finish the refactoring for every subject.
ResultTable 6.7 shows the elapsed time to finish Form Template Method for every
subject. The numeric characters in this table ‘hh:mm:ss’ indicates that the subject
need hh hours and mm minutes and ss seconds to finish their refactoring tasks.
For example, Subject 1 had finished applying refactoring on Candidate-A in 22
minutes and 45 seconds. ‘N/A’ means that the subject cannot finish refactoring in
the case.

Table 6.7: Elapsed Time to Finish Form Template Method Application
Subjects Group ID
Candidate-A
Candidate-B
Subject 1
1
0:22:45
0:50:30
0:52:00
1:17:00
Subject 2
1with CRat
with CCFinder
Subject 3
4
0:19:22
N/A
Subject 4
4
0:09:58
0:27:45
Subject 52
0:12:04
0:25:30
Subject 63with CCFinder 0:22:55
with CRat
0:50:28
Subject 7
3
0:35:20
1:04:15
Table 6.8: The Average Time
Candidate-A Candidate-B
with CRat
0:28:140:46:44with CCFinder
0:23:26
0:51:45
Both
0:25:50
0:49:15175

Both0:34:54
0:37:360:36:09

As the table shows, the time required to finish refactoring tasks varies greatly
among subjects. There is also great variability among Candidate-A and CandidateB; all the subjects required much time on Candidate-B than Candidate-A. This isbecause the degree of difficulty of Candidate-B is higher than that of Candidate-A.
Table 6.8 shows the average time to finish the refactorings. As the table shows,the elapsed time with CRat is higher than that with CCFinder in Candidate-A,
meanwhile the opposite result is shown in Candidate-B. As a result, CRat cannot
reduce time required for the refactorings in the easier candidate, but it can redusetime required for the refactorings in the more difficult candidate. Therefore, CRat
is useful in a case that the target method group is complex and it has a number ofthe methods.

6.8 Discussion
6.8.1 PDG Creation
There are some other dependences except data, control, and execute dependence that should be considered in PDGs. In the proposed method, dependence of
break and continue statements and dependence of exception are considered. However, the proposed method does not consider dependence caused by the following
factors.
• Library call.
• Alias.
• Presence of innner classes.
• Reflection.
Of these factors, we can consider dependence caused by library calls by giving
the source code of libraries as additional input of the proposed method. However,
it is quite difficult to give the source code of all the libraries that are used in thetarget software systems as the input.
In the experiments of this study, we cannot find instances that suffer any problems by dependence that are not considered in the proposed method. However,there is a risk that the proposed method suggests refactoring candidate incorrectlyby these dependence. Thus, it is necessary to consider these factors to make theproposed method robust.
176

6.8.2 Detection of Common Statements
As described in 6.4.4, the proposed method omits clone pairs except the mostlargest one in the case that there are duplications of clone pairs. The purpose ofthis is to suggest more nodes as common statements. However, in some cases, thisselection may be not appropriate. We can avoid this problem by delegating theselection to users. However, the proposed method does not have this function atpresent.
6.8.3 Candidates that Need to be Tailored
As we described in Section 6.7.1, we applied Form Template Method refactoring to 45 method pairs detected in Synapse on method pairs. In some cases,
we had to make some modifications that CRat did not indicate, or we had to makesome tailoring to the output of CRat to apply the pattern. Table 6.9 shows the modifications or adjustments needed to apply refactorings, and the number of candidates
that needed them. The definitions of the terms in the table are as follows: the term
“modify ENS” means the cases in which we had to modify ENSs or their pairwise
relationships between two methods that CRat suggests; the term “move methods
into base class or change their visibility” means the cases in which some methods
defined in derived classes are used in common processes and we had to move thosemethods into the base class and/or change their visibilities; and the term “replace
field references to calls of getter methods” indicates the cases in which some fields
are used in duplicate statements and they are not visible from the base class and we
had to replace references of these fields to calls of getter methods of them.
Issues of Visibility
The proposed method does not consider the visibility of methods and fields
in the source code. Therefore, code fragments that should be pulled up into thetemplate method can call methods or reference fields that are not accessible fromthe base class. In such cases, we need additional modifications on the source code

Table 6.9: The Candidates that Need some Modifications for CRat’s Outputs# of candidates that need no modifications
29# of candidates that need some modifications
16
modify ENS
12move methods into base class and/or change their visibilities
4
replace field references to calls of getter methods
2177to apply Form Template Method. We can apply the pattern to such candidates
by changing the visibility of methods and fields. However, it is not desirable thatcode clone removal requires increasing the visibility of methods or fields, becausesuch changes could cause vulnerability [106]. For fields, if fields have getters andsetters, we can resolve this problem by using them.
Issues of ENSs and their Relationships
The proposed method automatically detects ENSs and correspondence relationships of ENSs. However, the automatically detected ENSs or relationships of
ENSs may not fit with users’ sensibilities. Although the automatically detected
ENSs and their relationships do not always suitable, they can help users apply
refactoring.
6.8.4 Detection of Method Groups
The proposed method forms method groups from all the methods that satisfy
the requirements described in 6.4.3. However, it may be more suitable to form
method groups from a subset of the methods. We can improve this issue by delegating the selection of methods that should be included in method groups to users.
However, the proposed method currently does not have this functionality.
6.8.5 Threats to Validity of the Experiment with Subjects
In the experiment with subjects, we confirmed that the proposed method reduces time to refactor in a case that the target is complex and there is a number ofmethods in the target method group. However, we found the opposite result in acase that the target is not complex. There might be bias of subjects’ abilities, sothat the result might occur. We may get another result with different grouping of
subjects.

6.9 Summary
Form Template Method enables maintainers to remove code clones withsome gaps. Because of its difficulty, there exists some techniques to support Form
Template Method applications. However, the existing techniques still remainsome issues.
This chapter proposed a new technique to assist developers to apply Form
Template Method refactorings to code clones. It detects refactoring candidates
automatically and suggests them to its users. It uses program dependence graphs as
178

its data structure, which enables to assist developers removing code clones having
trivial differences that have no impact on the meanings of the program. Moreover,it can handle a group of three or more methods, which increases the practicality ofcode clones removal.
We implemented the proposed method as a tool, and conducted an experimentto evaluate the proposed method. We applied Form Template Method to all the
candidates that the tool suggests in an open source software, and confirmed that we
can refactor the candidates with preserving the behavior of the program.

179

Chapter 7

Conclusion
7.1 Contributions
The objective of the work presented in this dissertation is to promote efficiencies of development and maintenance of software systems. This dissertation focused on code clones to achieve the objective, and it presented some studies oncode clones. In summary, it contributes to the followings:• A survey on research literatures that are related to code clone management.
• An empirical study on impacts of code clones on software evolution by comparing stabilities of cloned and non-cloned code.
• A new technique to track code clones across version histories of softwaresystems based on an enhancement of an existing clone tracking technique,which is named CRD.
• An empirical investigation on clone genealogies to reveal characteristics ofharmful clones.
• A refactoring support for code clones with Form Template Method refactoring pattern.
There are many research papers relating to code clones because code clones
have recieved great attention and interests as a research topic on the field of software engineering. This dissertation, therefore, presented a survey at first to lookdown at the current state and open issues around code clones. The survey introduced discussions on code clones, specifically on the perspectives of causes ofcreation and harmfulness. After that, it introduced techniques, ideas, and findings181

relating to code clones. The introduction of research achievements loosely classified them into five categories; detection, removal, prevention, analysis, and finding
bugs.
Based on the survey results, we conducted four studies to promote efficientmanagement of code clones.
An empirical study on impacts of code clones aimed to reveal whether code
clones are generally harmful or not. The study stood on a basis that code clones
are harmful if code clones are frequently modified than non-cloned code. The study
defined a metric, named modification frequency, to calculate frequencies of modifications on cloned and non-cloned code, and then it calculated values of the metrics
on 15 open source software systems with four clone detectors. As a result, it was
revealed that cloned code tends to be stable compared to non-cloned code. This
experimental finding indicates that clones do not have seriously negative impacts
on software evolution. However, our detail analysis on the finding revealed that
there existed some instances of code clones that were frequently modified. Therefore, we can say that not all but a part of clones have negative impacts on software
evolution as a summary of the experimental results.
The dissertation presented the study result on an enhancement of CRD-based
clone tracking. Tracking clones across version histories plays an important role on
analyzing code clones. That is, it enables researchers to analyze evolution of code
clones. Analyzing clone evolution has a wide variety of applications, including
revealing characteristics of clones and finding inconsistencies of clones. Althoughsome techniques have been proposed to track code clones, they have still someissues. The clone tracking technique proposed in this dissertation resolved issuesof the previous technqiues by enhancing an existing technique, named CRD. CRD
represents information of the location where a code fragment stands. The original
CRD-based technique to track clones realizes clone tracking with exact matches of
CRDs. On the other hand, the new clone tracking technique proposed in this dissertation uses not only exact matches of CRDs but also similarities of CRDs. The
idea is quite simple, but it was confirmed that the simple idea improved accuracies
of clone tracking through the experimental results on two open source softwaresystems.
Analyzing clone genealogies with the new tracking technique followed theenhancement of CRD-based clone tracking. Our first empirical study revealed thata part of clones have negative impacts, but there still exists some questions on
harmfulness of clones. To reveal such questions, we detected and analyzed clone
genealogies that describe how individual clones evolved in version histories of software systems. The detection of clone genealogies was based on the clone tracking
techniques proposed by this dissertation. First, this study revisited some common
findings on clone evolution with the new clone tracking technique, and the experi182

mental results supported the common findings. In the next, this study investigatedsome open questions, including how many clones have negative impacts on software evolution and there is any characteristics of timings when clones were modified across their lifetimes. As a result, it revealed that approximately 3% of clones
had negative impacts. Hence, this finding empirically supports our fingings that
not all but a part of clones are harmful. Furthermore, it was revealed that clones
tended to be modified more frequently in the former halves of their lifetimes thanthe latter halves. This fact indicates an importance for start managing clones in theearlier stage of their lifetimes.
Finally, we proposed a refactoring support for code clones with Form Template Method. One of the ways to cope with harmful code clones is removing themfrom source code. However, removing clones should be performed in a cautious
manner because it is quite challenging to complete refactorings on clones without
introducing any failures. This fact indicates a requirement for tool support. In addition, removing clones will become more difficult in the case they include somegaps. Form Template Method is a refactoring technique that can be used forremoving clones including some gaps. However, applying the refactoring pattern
is a more complicated task compared to other refactoring applications because of
the complexity of the pattern. Hence, tool supports are strongly required to apply
Form Template Method refactroing pattern. For these reasons, this dissertation
proposed a refactoring support for Form Template Method to cope with harmfulclones after they are detected. The proposed technique automatically detects all the
refactoring candidates that can be refactored by Form Templete Method pattern.
The purpose of automatic detection of refactoring candidates is to reduce costs to
identify where to be refactored. Form Template Method is a complex pattern,
and so detecting candidates of the refactoring pattern is a costly task. Therefore,
supporting for identifications of refactoring candidates is necessary. Furthermore,
the technique shows how to refactor each of detected candidates to be refactored.
This function should reduce costs to apply refactorings. We have developed the
proposed technique as a software tool named CRat, and confirmed the usefulness
and effectiveness of the proposed method through two experiments.

7.2

Future Research Directions

This section discusses open issues and future research directions of the work
presented in this dissertation.
The empirical study presented in Chapter 3 targets 15 software systems withfour different clone detectors, and so we believe that the findings will have sufficient generalities. However, the study has a limitation that the experimental targets
183

of it are only open source software systems. Industrial software systems shouldhave different characteristics from open source software systems, which makes it
difficult to generalize our findings to industrial software systems. One of the future
directions of this study is to reval characteristics of clones that are frequently modified. Revealing the characteristics of frequently modified clones should help us todetect or predict harmful clones.
Clone tracking technique proposed in Chapter 4 has higher accuracy than theoriginal CRD based clone tracking. However, there exists some instances thateven the improved technique cannot track. These failures of clone tracking will
be resolved by relaxing the conditions for clones to be linked. On the other hand,relaxed conditions have a risk to introduce more false positives. Therefore, oneof the important future work of this study is to seek more appropriate conditions
for linking clones that improve accuracy of clone tracking without introducing any
false positives.
The empirical study for clone genealogies presented in Chapter 5 has a similar
issue of the study presented in Chapter 3. That is, the study targets only open source
software systems. Hence, as well as the study in Chapter 3, it requires more experiments on industrial software systems to generalize the findings. In addition, it
also has another limitation that it adopts only a block-based clone detector. It is required to use other clone detectors to generalize the findings although experimentswith other detectors should need much time. Furthermore, the block-based clone
detector used in this study can handle only Java. Therefore, more experiments arenecessary on other software systems written in other programming langauges.
One of the important future work for the refactoring support proposed in Chapter 6 is automatic code transformation. Form Template Method refactoring is acomplex refactoring pattern, so manual refactorings with this pattern have a highrisk to introduce human errors. Automatic code transformation will contribute tosafe refactoring with Form Template Method, and so it is necessary to realize thisfunctionality to better refactoring support. Futhermore, combining this techniqueand other refactoring support techniques for other refactoring patterns will be useful to remove code clones. Form Template Method is nothing more than one of
the choises for clone removal. Therefore, not Form Template Method but otherrefactoring patterns should be suited for some cases. Supporting multiple patterns
at a time will be helpful to choose the best solution for individual cases.
The most fundamental and important challenge of our future research is to detect harmful clones. Our investigations on code clones are based on histories ofthem, but our reserach does not reach detection of harmful clones. Our findings
suggested to manage a part of code clones, but they cannot answer the questionthat what clones should be managed. Idengifying harmful clones must be a basis of efficient clone management because developers or maintainers need to pay
184attention only for such harmful clones. For these reasons, we need to develop atechnique to detect harmful clones as a major future research direction.
One of the way to detect harmful clones is to learn characteristics of harmfulclones existed in previous revisions of the software system with machine learningtechniques. However, there is no generic definitions for the harmfulness of clones.
To detect harmful clones, it is necessary to reveal what clones are harmful. Thisdissertation regarded clones as harmful if they are frequently modified, or they
are long-lived. However, there will exist some other definitions of harmful clones,
including clones are harmful if they cause any bugs. Hence, much more discussions
are required for harmfulness of clones.

185

Bibliography[1] IEEE Standard 12207. Standard for Information Technology - Software Life
Cycle Processes, 1996.
[2] ISO/IEC 14764. Software Engineering - Software Maintenance, 1999.
[3] E. Adar and M. Kim. SoftGUESS: Visualization and Exploration of CodeClones in Context. In Proceedings of the 29th International Conference on
Software Engineering (ICSE 2007), May 2007.
[4] R. Agrawal and R. Srikant. Mining Sequential Patterns. In Proceedings ofthe 11th International Conference on Data Engineering (ICDE 1995), pages
3–14, Mar. 1995.
[5] L. Aversano, L. Cerulo, and M. Di Penta. How Clones are Maintained:
An Empirical Study. In Proceedings of the 11th European Conference on
Software Maintenance and Reengineering (CSMR 2007), pages 81–90, Mar.
2007.
[6] S. Baba, N. Yoshida, S. Kusumoto, and K. Inoue. Application of Code Clone
Information to Fault-Prone Module Prediction. IEICE Transactions on Information and Systems, J91-D(10):2559–2561, Oct. 2008. (in Japanese).
[7] B. Baker. On Finding Duplication and Near-Duplication in Large Software
Systems. In Proceedings of the 2nd Working Conference on Reverse Engineering (WCRE 1995), pages 86–95, July 1995.
[8] T. Bakota, R. Ferenc, and T. Gyim’othy. Clone Smells in Software Evolution. In Proceedings of the 23rd International Conference on Software
Maintenance (ICSM 2007), pages 24–33, Oct. 2007.
[9] M. Balazinska, E. Merlo, M. Dagenais, and B. Lague. Advanced CloneAnalysis to Support Object-Oriented System Refactoring. In Proceedings of187

the 7th Working Conference on Reverse Engineering (WCRE 2000), pages
98–107, Nov. 2000.
[10] M. Balazinska, E. Merlo, M. Dagenais, B. Lagüe, and K. Kontogiannis.
Measuring clone based reengineering opportunities. In Proceedings of
the 6th International Software Symposium on Software Metrics (METRICS
1999), pages 292–303, Nov. 1999.
[11] H. Basit and S. Jarzabek. A Data Mining Approach for Detecting HigherLevel Clones in Software. IEEE Transactions on Software Engineering,35(4):497–514.
[12] H. A. Basit and S. Jarzabek. Detecting Higher-level Similarity Patterns in
Programs. In Proceedings of the 13th International Symposium on Foundations of Software Engineering (ESEC/FSE 2005), pages 156–165, Sep.
2005.
[13] H. A. Basit, S. J. Puglisi, W. F. Smyth, A. Turpin, and S. Jarzabek. Efficient
Token Based Clone Detection with Flexible Tokenization. In Proceedingsof the 6th Joint Meeting of the European Software Engineering Conference
and the 15th International Symposium on the Foundations of Software Engineering (ESEC/FSE 2007), pages 513–516, Nov. 2007.
[14] S. Bassil and R. K. Keller. Software Visualization Tools: Survey and Analysis. In Proceedings of the 9th International Workshop on Program Comprehension (IWPC 2001), pages 7–17, May 2001.
[15] I. Baxter, A. Yahin, M. Anna L. Moura, and L. Bier. Clone Detection Using
Abstract Syntax Trees. In Proceedings of the 14th International Conference
on Software Maintenance (ICSM 1998), pages 368–377, Mar. 1998.
[16] S. Bellon, R. Koschke, G. Antniol, J. Krinke, and E. Merlo. Comparison
and Evaluation of Clone Detection Tools. IEEE Transactions on Software
Engineering, 31(10):804–818, Oct. 2007.
[17] K. H. Bennett and V. T. Rajlich. Software Maintenance and Evolution: A
Road Map. In Proceedings of the Conference on the Future of Software
Engineering in the 22nd International Conference on Software Engineering(ICSE 2000), pages 73–87, June 2000.
[18] N. Bettenburg, W. Shang, W. M. Ibrahim, B. Adams, Y. Zou, and A. E. Hassan. An empirical study on inconsistent changes to code clones at the releaselevel. Science of Computer Programming, 77(6):760–776, June 2012.
188

[19] F. Brooks. The Mythical Man-Month. Addison-Wesley, 1975.
[20] E. Burd and J. Bailey. Evaluating Clone Detection Tools for Use during Preventative Maintenance. In Proceedings of the 2nd International Workshop
on Source Code Analysis and Manipulation (SCAM 2002), pages 36–43,
Oct. 2002.
[21] CCFinderX.
available
ccfinderx-j.html>.

<http://www.ccfinder.net/

at[22] E. Choi, N. Yoshida, and K. Inoue. What kind of and how clones are refactored? : A case study of three OSS projects. In Proceedings of the 5thWorkshop on Refactoring Tools (WRT 2012), pages 1–7, June 2012.
[23] CloneDR.
available
Products/Clone/>.

at<http://www.semdesigns.com/[24] R. Cottrell, J. J. Chang, R. J. Walker, and J. Denzinger. Determing Detailed
Structural Correspondence for Generalization Tasks. In Proceedings of the
6th Joint Meeting of the European Software Engineering Conference and the15th International Symposium on the Foundations of Software Engineering(ESEC/FSE 2007), pages 165–174, Nov. 2007.
[25] J. Czerwonka, R. Das, N. Nagappan, A. Tarvo, and A. Teterev. CRANE:
Failure Prediction, Change Analysis and Test Prioritization in Practice - Experiences from Windows. In Proceedings of the 4th International Conference on Software Testing, Verification and Validation (ICST 2011), pages
357–366, Mar. 2011.
[26] M. Datar, N. Immorlica, P. Indyk, and V. S. Mirrokni. Locality-Sensitive
Hashing Scheme Based on p-Stable Distributions. In Proceedings of the
12th Annual Symposium on Computational Geometry (SCG 2004), pages =253-262, year = 2004, month = June.
[27] E. Duala-Ekoko and M. P. Robillard. Clone Region Descriptors: Representing and Tracking Duplication in Source Code. ACM Transactions on
Software Engineering and Methodology, 20(1):3:1–3:31, June 2010.
[28] S. Ducasse, M. Rieger, and S. Demeyer. A Language Independent Approachfor Detecting Duplicated Code. In Proceedings of the 15th International
Conference on Software Maintenance (ICSM 1999), pages 109–118, Aug.
1999.
189

[29] S. G. Eick, T. L. Graves, A. F. Karr, J. S. Marron, and A. Mockus. Does Code
Decay? Assessing the Evidence from Change Management Data. IEEE
Transactions on Software Engineering, 27(1):1–12, Jan. 2001.
[30] R. Falke, P. Frenzel, and R. Koschke. Empirical Evaluation of Clone Detection Using Syntax Suffix Trees. Empirical Software Engineering, 13(6),Dec. 2008.
[31] J. Ferrante, K. J. Ottenstein, and J. D. Warren. The Program Dependence
Graph and Its Use in Optimization. ACM Transactions on Programming
Languages and Systems, 9(3):319–349, 1987.
[32] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts. Refactoring: Improving the Design of Existing Code. Addison-Wesley Professional, 1999.
[33] N. Göde. Evolution of Type-1 Clones. In Proceedings of the 9th IEEE International Working Conference on Source Code Analysis and Manipulation(SCAM 2009), pages 77–86, Sep. 2009.
[34] N. Göde and J. Harder. Clone Stability. In Proceedings of the 15th European Conference on Software Maintenance and Reengineering (CSMR2011), pages 65–74, Mar. 2011.
[35] N. Göde and R. Koschke. Frequency and Risks of Changes to Clones. In
Proceedings of the 33rd International Conference on Software Engineering(ICSE 2011), pages 311–320, May 2011.
[36] N. Göde and R. Kosheke. Incremental Clone Detection. In Proceedings ofthe 13th European Conference on Software Maintenance and Reengineering(CSMR 2009), pages 219–228, Mar. 2009.
[37] A. Goto, N. Yoshida, M. Ioka, E. Choi, and K. Inoue. How to Extract Differences from Similar Programs? A Cohesion Metric Approach. In Proceedings of the 7th International Workshop on Software Clones (IWSC 2013),
pages 23–29, May 2013.
[38] J. Harder and N. Göde. Cloned code: stable code. Journal of Software :Evolution and Process, Mar. 2012. doi: 10.1002/smr.1551.
[39] H. Hata, Y. Higo, and S. Kusumoto. Code Clone Version Control System
for Mining Rich Clone Histories. IPSJ Journal, 54(2):894–902, Feb. 2013.
(in Japanese).
190

[40] B. Hauptmann, V. Bauer, and M. Junker. Using Edge Bundle Views forClone Visualization. In Proceedings of the 6th International Workshop on
Software Clones (IWSC 2012), pages 86–87, June 2012.
[41] Y. Hayase, Y. Yong Lee, and K. Inoue. A Criterion for Filtering CodeClone Related Bugs. In Proceedings of International Workshop on Defects
in Large Software (DEFECTS 2008).
[42] Y. Higo and S. Kusumoto. Code Clone Detection on Specialized PDGs with
Heuristics. In Proceedings of the 15th European Conference on Software
Maintenance and Reengineering (CSMR 2011), pages 75–84, Mar. 2011.
[43] Y. Higo, S. Kusumoto, and K. Inoue. A Survey of Code Clone Detection and
Its Related Techniques. IEICE Transactions on Information and Systems,
91-D(6):1465–1481, June 2008. (in Japanese).
[44] Y. Higo, S. Kusumoto, and K. Inoue. Identifying Refactoring Opportunities
for Removing Code Clones with A Metrics-based Approach. In K. Cai,
editor, Java in Academia and Research, chapter 3, pages 57–82. Concept
Press Ltd., 2011.
[45] Y. Higo, K. Sawa, and S. Kusumoto. Problematic Code Clones Identification using Multiple Detection Results. In Proceedings of the 16th AsiaPacific Software Engineering Conference (APSEC 2009), pages 365–372,
Dec. 2009.
[46] Y. Higo, Y. Ueda, S. Kusumoto, and K. Inoue. Simultaneous Modification
Support based on Code Clone Analysis. In Proceedings of the 14th AsiaPacific Software Engineering Conference (APSEC 2007), pages 262–269,
Dec. 2007.
[47] Y. Higo, Y. Ueda, M. Nishino, and S. Kusumoto. Incremental Code Clone
Detection: A PDG-based Approach. In Proceedings of the 18th Working
Conference on Reverse Engineering (WCRE 2011), pages 3–12, Oct. 2011.
[48] Y. Higo and N. Yoshida. An Introduction to Code Clone Refactoring. Computer Software, 28(4):42–56, 2011. (in Japanese).
[49] D. Holten. Hierarchical Edge Bundles: Visualization of Adjacency Relations in Hierarchical Data. IEEE Transactions on Visualization and Computer Graphics, 12(5):741–748, Sep. 2006.
191

[50] D. Hou, P. Jablonski, and F. Jacob. CnP: Towards an Environment for the
Proactive Management of Copy-and-Paste Programming. In Proceedingsof the 17th International Conference on Program Comprehension (ICPC2009), pages 238–242, May 2009.
[51] B. Hummel, E. Juergens, L. Heinemann, and M. Conradt. Index-Based
Code Clone Detection: Incremental, Distributed, Scalable. In Proceedings of the 26th International Conference on Software Maintenance (ICSM
2010), pages 1–9, Sep. 2010.
[52] The Japan Patent Office in the Ministry of Economy, Trade, and Industry in Japan. http://www.jpo.go.jp/shiryou/toushin/kenkyukai/jyouhou_iinkai.htm (in Japanese).
[53] K. Inoue, Y. Higo, N. Yoshida, E. Choi, S. Kusumoto, K. Kim, W. Park, andE. Lee. Experience of Finding Inconsistently-Changed Bugs in Code Clonesof Mobile Software. In Proceedings of the 6th International Workshop on
Software Clones (IWSC 2012), pages 94–95, June 2012.
[54] K. Inoue, T. Kamiya, and S. Kusumoto. Code-Clone Detection Methods.
Computer Software, 18(5):529–536, 2001. (in Japanese).
[55] M. Ioka, N. Yoshida, T. Masai, Y. Higo, and K. Inoue. A Tool Support toMerge Similar Methods with a Cohesion Metric COB. In Proceedings of the
3rd International Workshop on Empirical Software Engineering in Practice(IWESEP 2011), pages 23–24, Nov. 2011.
[56] T. Ishihara, K. Hotta, Y. Higo, H. Igaki, and S. Kusumoto. Inter-Project
Functional Clone Detection toward Building Libraries - An Empirical Studyon 13,000 Projects. In Proceedings of the 19th Working Conference on Reverse Engineering (WCRE 2012), pages 387–391, Oct. 2012.
[57] P. Jablonski and D. Hou. CReN: A Tool for Tracking Copy-and-Paste CodeClones and Renaming Identifiers Consistently in the IDE. In Proceedings of
the OOPSLA Workshop on Eclipse Technology eXchange (ETX 2007), pages
16–20, Oct. 2007.
[58] F. Jacob, D. Hou, and P. Jablonski. Actively Comparing Clones Inside The
Clone Editor. In Proceedings of the 4th International Workshop on Software
Clones (IWSC 2010), pages 9–16, May 2010.
[59] K. Jalbert and J. S. Brandbury. Using Clone Detection to Identify Bugs in
Concurrent Software. In Proceedings of the 26th International Conference
on Software Maintenance (ICSM 2010), pages 1–5, Sep. 2010.
192

[60] Java Development Tools. available at <http://www.eclipse.org/
jdt/>.
[61] L. Jiang, G. Misherghi, Z. Su, and S. Glondu. DECKARD : Scalable andAccurate Tree-based Detection of Code Clones. In Proceedings of the 29th
International Conference on Software Engineering (ICSE 2007), May 2007.
[62] L. Jiang, Z. Su, and E. Chiu. Context-Based Detection of Clone-Related
Bugs. In Proceedings of the 6th Joint Meeting of the European Software Engineering Conference and the 15th International Symposium on the Foundations of Software Engineering (ESEC/FSE 2007), pages 147–156, Nov.
2007.
[63] Z. M. Jiang and A. E. Hassan. A Framework for Studying Clones In Large
Software Systems. In Proceedings of the 7th Working Conference on Source
Code Analysis and Manipulation (SCAM 2007), pages 203–212, Oct. 2007.
[64] J.H. Johnson. Substring Matching for Clone Detection and Change Tracking. In Proceedings of the 10th International Conference on Software Maintenance (ICSM 1994), pages 120–126, Sep. 1994.
[65] E. Juergens, F. Deissenboeck, B. Hummel, and S. Wagner. Do Code Clones
Matter? In Proceedings of the 31st International Conference on Software
Engineering (ICSE 2009), pages 485–495, June 2009.
[66] N. Juillerat and B. Hirsbrunner. Toward an Implementation of the “Form
Template Method” Refactoring. In Proceedings of the 7th International
Working Conference on Source Code Analysis and Manipulation (SCAM
2007), pages 81–90, Sep. 2007.
[67] JUNG. avilable at <http://jung.sourceforge.net/>.
[68] Y. Kamei, H. Sato, A. Monden, S. Kawaguchi, H. Uwano, M. Nagura, andK. Matsumoto. An Empirical Study of Fault Prediction with Code Clone
Metrics. In Proceedings of the Joint Conference of International Workshop
on Software Measurement and International Conference on Software Process and Product Measurement (IWSM/Mensura 2011), pages 55–61, Nov.
2011.
[69] T. Kamiya. Classifying Code Clones with Configuration. In Proceedingsof the 4th International Workshop on Software Clones (IWSC 2010), pages
75–76, May 2010.
193

[70] T. Kamiya. Conte*t Clones or Re-thinking Clone on a Call Graph. In
Proceedings of the 6th International Workshop on Software Clones (IWSC
2012), pages 74–75, June 2012.
[71] T. Kamiya, Y. Higo, and N. Yoshida. Evolving and Hot Topics on CodeClone Detection Techniques. Journal of Computer Software, 28(3):28–42,
Aug. 2011. (in Japanese).
[72] T. Kamiya, S. Kusumoto, and K. Inoue. CCFinder: A Multi-Linguistic
Token-based Code Clone Detection System for Large Scale Source Code.
IEEE Transactions on Software Engineering, 28(7):654–670, July 2002.
[73] C. Kapser and M. W. Godfrey. Aiding Comprehension of Cloning ThroughCategorization. In Proceedings of the 7th International Workshop on Principles of Software Evolution (IWPSE 2004), pages 85–94, Sep. 2004.
[74] C. J. Kapser and M. W. Godfrey. “Cloning considered harmful” consideredharmful: patterns of cloning in software. Empirical Software Enginieering,13(6):645–692, Dec. 2008.
[75] S. Kawaguchi, T. Yamashita, H. Uwano, K. Fushida, Y. Kamei, M. Nagura,and H. Iida. SHINOBI: A Tool for Automatic Code Clone Detection in the
IDE. In Proceedings of the 16th Working Conference on Reverse Engineering (WCRE 2009), pages 313–314, Oct. 2009.
[76] M. Kim, L. Bergman, T. Lau, and D. Notokin. An Ethnographic Study of
Copy and Paste Programming Practices in OOPL. In Proceedings of the 3rdInternational Symposium on Empirical Software Engineering (ISESE 2004),
pages 83–92, Aug. 2004.
[77] M. Kim and D. Notokin. Using a Clone Genealogy Extractor for Understanding and Supporting Evolution of Code Clones. In Proceedings of the
2nd International Workshop on Mining Software Repositories (MSR 2005),
pages 1–5, May 2005.
[78] M. Kim, V. Sazawal, D. Notkin, and G. C. Murphy. An Empirical Studyof Code Clone Genealogies. In Proceedings of the 13th International Symposium on Foundations of Software Engineering (ESEC/FSE 2005), pages
187–196, Sep. 2005.
[79] E. Kodhai, S. Kanmani, A. Kamatchi, R. Radhika, and B. V. Saranya. Detection of Type-1 and Type-2 Code Clones Using Textual Analysis and Metrics.
194

In Proceedings of 2010 International Conference on Recent Trends in Information, Telecommunication and Computing (ITC 2010), pages 241–243,
Mar. 2010.
[80] R. Komondoor and S. Horwitz. Semantics-Preserving Procedure Extraction. In Proceedings of the 27th Symposium on Principles of Programming
Language (POPL 2000), pages 155–169, Jan. 2000.
[81] R. Komondoor and S. Horwitz. Using Slicing to Identify Duplication in
Source Code. In Proceedings of the 8th International Symposium on Static
Analysis (SAS 2001), pages 40–56, July 2001.
[82] K. Kontogiannis. Evaluation experiments on the detection of programming
patterns using software metrics. In Proceedings of the 4th Working Conference on Reverse Engineering (WCRE 1997), pages 44–54, Oct. 1997.
[83] R. Koschke. Survey of Research on Software Clones. In Duplication, Redundancy, and Similarity in Software, Dagstuhl Seminar, July 2006.
[84] R. Koschke. Frontiers on Software Clone Management. In Proceedings ofthe Frontiers of Software Maintenance in the 24th International Conference
on Software Maintenance (ICSM 2008), pages 119–128, Oct. 2008.
[85] R. Koschke, R. Falke, and P. Frenzel. Clone Detection Using Abstract Syntax Suffix Trees. In Proceedings of the 13th Working Conference on Reverse
Engineering (WCRE 2006), pages 253–262, Oct. 2006.
[86] J. Krinke. Identifying Similar Code with Program Dependence Graphs. In
Proceedings the 8th Working conference on Reverse Engineering (WCRE2001), pages 301–309, Oct. 2001.
[87] J. Krinke. A Study of Consistent and Inconsistent Changes to Code Clones.
In Proceedings of the 14th Working Conference on Reverse Engineering(WCRE 2007), pages 170–178, Oct. 2007.
[88] J. Krinke. Is Cloned Code More Stable than Non-cloned Code? In Proceedings of the 8th International Working Conference on Source Code Analysis
and Manipulation (SCAM 2008), pages 57–66, Sep. 2008.
[89] J. Krinke. Is Cloned Code older than Non-Cloned Code? In Proceedingsof the 5th International Workshop on Software Clones (IWSC 2011), pages
28–33, May 2011.
195

[90] B. Laguë, D. Proulx, J. Mayrand, E. M. Merlo, and J. P. Hudepohl. Assessing the Benefits of Incorporating Function Clone Detection in a Development Process. In Proceedings of the 13th International Conference on
Software Maintenance (ICSM 1997), pages 314–321, Oct. 1997.
[91] F. Lanubile and T. Mallardo. Finding Function Clones in Web Applications.
In Proceedings of the 7th European Conference on Software Maintenanceand Reengineering (CSMR 2003), pages 379–386, Mar. 2003.
[92] M. Lanza and S. Ducasse. Polymetric Views - A Lightweight Visual Approach to Reverse Engineering. IEEE Transactions on Software Engineering, 29(9):782–795, Sep. 2003.
[93] T. D. LaToza, G. Venolia, and R. DeLine. Maintaining Mental Models: A
Study of Developer Work Habits. In Proceedings of the 28th International
Conference on Software Engineering (ICSE 2006), May 2006.
[94] S. Lee, G. Bae, H. S. Chae, D. Bae, and Y. R. Kwon. Automated Schedulingfor Clone-based Refactoring Using a Competent GA. Software: Practiceand Experience, 41(5):521–550, Apr. 2010.
[95] S. Lee and I. Jeong. SDD: High Performance Code Clone Detection System for Large Scale Source Code. In Proceedings of the Object Oriented
Programming Systems Languages and Applications Companion to the 20th
annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2005), pages 140–141, Oct.
2005.
[96] H. Li and S. Thompson. Clone Detection and Removal for Erlang/OTP
within a Refactoring Environment. In Proceedings of the 2009 ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation (PEPM
2009), pages 169–178, Jan. 2009.
[97] J. Li and M. D. Ernst. CBCD: Cloned Buggy Code Detector. In Proceedingsof the 34th International Conference on Software Engineering (ICSE 2012),
pages 310–320, June 2012.
[98] Z. Li, S. Myagmar, S. Lu, and Y.Zhou. CP-Miner: Finding Copy-Paste
and Related Bugs in Large-Scale Software Code. IEEE Transcations on
Software Engineering, 32(3):176–192, Mar. 2006.
[99] S. Livieri, Y. Higo, M. Matsushita, and K. Inoue. Very-Large Scale CodeClone Analysis and Visualization of Open Source Programs Using Dis196

tributed CCFinder: D-CCFinder. In Proceedings of the 29th International
Conference on Software Engineering (ICSE 2007), May 2007.
[100] A. Lozano and M. Wermelinger. Evaluating the Harmfulness of Cloning: A
Change Based Experiment. In Proceedings of the 4th International Workshop on Mining Software Repositories (MSR 2007), May 2007.
[101] A. Lozano and M. Wermelinger. Assessing the Effect of Clones on Changeability. In Proceedings of the 24th International Conference on Software
Maintenance (ICSM 2008), pages 227–236, Sep. 2008.
[102] A. Lozano and M. Wermelinger. Tracking clones’ imprint. In Proceedingsof the 4th International Workshop on Software Clones (IWSC 2010), pages
65–72, May 2010.
[103] A. Lozano, M. Wermelinger, and B. Nuseibeh. Evaluating the Relation between Changeability Decay and the Characteristics of Clones and Methods.
In Proceedings of the 23rd International Conference on Automated Software
Engineering (ASE 2008), pages 100–109, Sep. 2008.
[104] Lucia, D. Lo, L. Jiang, and A. Budi. Active Refinement of Clone Anomaly
Reports. In Proceedings of the 34th International Conference on Software
Engineering (ICSE 2012), pages 397–407, June 2012.
[105] K. Maeda. Syntax Sensitive and Language Independent Detection of CodeClones. World Academy of Science, Engineering and Technology, (36):350–354.
[106] K. Maruyama and T. Omori. A Security-Aware Refactoring Tool for Java
Programs. In Proceedings of the 4th Workshop on Refactoring Tools (WRT2011), pages 22–28, May 2011.
[107] T. Masai, N. Yoshida, M. Matsushita, and K. Inoue. Supporting Difference
Extraction for Merging Similar Methods. In IEICE Technical Report, pages
45–50, May 2010. (in Japanese).
[108] MASU.
avilable at <http://sourceforge.net/projects/
masu/>.
[109] J. Mayrand, C. Leblanc, and E. Merlo. Experiment on the Automatic Detection of Function Clones in a Software System Using Metrics. In Proceedings of the 12th International Conference on Software Maintenance (ICSM
1996), pages 244–253, Nov. 1996.
197

[110] T. J. McCabe. A Complexity Measure. IEEE Transactions on Software
Engineering, SE-2(4):308–320, Dec. 1976.
[111] T. Mens and T. Tourwé. A Survey of Software Refactoring. IEEE Transactions on Software Engineering, 30(2):126–139, Feb. 2004.
[112] E. Merlo and T. Lavoie. Computing Structural Types of Clone Syntactic
Blocks. In Proceedings of the 16th Working Conference on Reverse Engineering (WCRE 2009), pages 274–278, Oct. 2009.
[113] H. Miyazaki, Y. Higo, and K. Inoue. Increasing Code Clone Analysis Efficiency Using Itemset Mining. In Technical Report of IEICE (SIGSS), volume 108, pages 31–36, July 2008. (in Japanese).
[114] M. Mondal, C. K. Roy, M. S. Rahman, R. K. Saha, J. Krinke, and K. A.
Schneider. Comparative Stability of Cloned and Non-cloned Code: An
Empirical Study. In Proceedings of the 27th Annual ACM Symposium on
Applied Computing (SAC 2012), pages 1227–1234, Mar. 2012.
[115] A. Monden, D. Nakae, T. Kamiya, S. Sato, and K. Matsumoto. Software
Quality Analysis by Code Clones in Industrial Legacy Software. In Proceedings of the 8th IEEE Internaitional Software Metrics Symposium (METRICS
2002), pages 87–94, June 2002.
[116] H. Murakami, K. Hotta, Y. Higo, H. Igaki, and S. Kusumoto. Folding Repeated Instructions for Improving Token-Based Code Clone Detection. In
Proceedings of the 12th International Working Conference on Source CodeAnalysis and Manipulation (SCAM 2012), pages 64–73, Sep. 2012.
[117] H. Murakami, K. Hotta, Y. Higo, H. Igaki, and S. Kusumoto. Gapped CodeClone Detection with Lightweight Source Code Analysis. In Proceedingsof the 21st International Conference on Program Comprehension (ICPC2013), pages 93–102, May 2013.
[118] E. Murphy-Hill and A. P. Black. Breaking the Barriers to Successful Refactoring. In Proceedings of the 30th International Conference on Software
Engineering (ICSE 2008), pages 421–430, May 2008.
[119] H. A. Nguyen, T. T. Nguyen, N. H. Pham, J. Al-Kofahi, and T. N. Nguyen.
Clone Management for Evoluving Software. IEEE Transactions on Software
Engineering, 38(5):1008–1026, Sep. 2012.
198

[120] T. T. Nguyen, H. A. Nguyen, N. H. Pham, J. M. Al-Kofahi, and T. N.
Nguyen. ClemanX: Incremental Clone Detection Tool for Evoluving Software. In Proceedings of the 31st International Conference on Software Engineering (ICSE 2009), pages 437–438, June 2009.
[121] T. T. Nguyen, H. A. Nguyen, N. H. Pham, J. M. Al-Kofahi, and T. N.
Nguyen. Clone-aware Configuration Management. In Proceedings of the24th International Conference on Automated Software Engineering (ASE2009), pages 123–134, Nov. 2009.
[122] NiCad3 Clone Detector.
available at <http://www.txl.ca/
nicaddownload.html>.
[123] T. Omori, K. Maruyama, S. Hayashi, and A. Sawada. A Literature Review
on Software Evolution Research. Computer Software, 29(3):3–28, Aug.
2012. (in Japanese).
[124] W. F. Opdyke. Refactoring: A Program Restructuring Aid in Designing
Object-Oriented Application Frameworks. PhD thesis, University of Illinois, 1992.
[125] J. Ossher, H. Sajnani, and C. Lopes. File Cloning in Open Source Java
Projects: The Good, The Bad, and The Ugly. In Proceedings of the 27th International Conference on Software Maintenance (ICSM 2011), pages 283–
292, Sep. 2011.
[126] K. J. Ottenstein. An Algorithmic Approach to the Detection and Preventionof Plagiarism. ACM SIGCSE Bulletin, 8(4):30–41, Dec. 1976.
[127] J. Pearl. Probablistic Reasoning in Intelligent Systems: Networks of Plausible Inference. Morgan Kaufmann, 1988.
[128] F. Rahman, C. Bird, and P. Devanbu. Clones: What is that Smell? In Proceedings of the 7th IEEE Working Conference on Mining Software Repositories (MSR 2010), pages 72–81, May 2010.
[129] D. Rattan, R. Bhatia, and M. Singh. Software clone detection: A systematic
review. Information and Software Technology, 55(7):1165–1199, July 2013.
[130] M. Rieger, S. Ducasse, and M. Lanza. Insights into System-Wide CodeDuplication. In Proceedings of the 11th Working Conference on Reverse
Engineering (WCRE 2004), pages 100–109, Nov. 2004.
199

[131] C. K. Roy and J. R. Cordy. A Survey on Software Clone Detection Research.
School of Computing Technical Report 2007-541, Queen’s University, 115,
2007.
[132] C. K. Roy and J. R. Cordy. NICAD: Accurate Detection of Near-Miss Intentional Clons Using Flexible Pretty-Printing and Code Normalization. In
Proceedings of the 16th International Conference on Program Comprehension (ICPC 2008), pages 172–181, June 2008.
[133] C. K. Roy and J. R. Cordy. A Mutation / Injection-based Automatic Framework for Ecaluating Code Clone Detection Tools. In Proceedings of theInternational Conference on Software Testing, Verification, and Validation
Workshops (ICSTW 2009), pages 157–166, Apr. 2009.
[134] F. V. Rysselberghe and S. Demeyer. Evaluating Clone Detection Techniquesfrom a Refactoring Perspective. In Proceedings of the 19th International
Conference on Automated Software Engineering (ASE 2004), pages 336–
339, Sep. 2004.
[135] R. K. Saha, M. Asaduzzaman, M. F. Zibran, C. K. Roy, and K. A. Schneider.
Evaluating Code Clone Genealogies at Release Level: An Empirical Study.
In Proceedings of the 10th Working Conference on Source Code Analysis
and Manipulation (SCAM 2010), pages 87–96, Sep. 2010.
[136] R. K. Saha, C. K. Roy, and K. A. Schneider. Visualizing the Evolution of
Code Clones. In Proceedings of the 5th International Workshop on Software
Clones (IWSC 2011), pages 71–72, May 2011.
[137] T. Sasaki, Y. Higo, T. Kamiya, S. Kusumoto, and K. Inoue. A Code Clone
Information Supplement Tool to Support Program Change. IEICE Journal,
J87-D-I(9):868–870, Sep. 2004. (in Japanese).
[138] Y. Sasaki, T. Yamamoto, Y. Hayase, and K. Inoue. Finding File Clones in
FreeBSD Ports Collection. In Proceedings of the 7th IEEE Working Conference on Mining Software Repositories (MSR 2010), pages 102–105, May
2010.
[139] Scorpio. available at <http://www-sdl.ist.osaka-u.ac.jp/
˜higo/cgi-bin/moin.cgi/scorpio>.
[140] Simian. available at <http://www.redhillconsulting.com.
au/products/simian/>.
200

[141] T. F. Smith and M. S. Waterman. Identification of Common Molecular Subsequences. Journal of Molecular Biology, 147(1):195–197, 1981.
[142] R. Tairas and J. Gray. An Information Retrieval Process to Aid in the Analysis of Code Clones. Empirical Software Engineering, 14(1):33–56, Feb.
2009.
[143] S. Thummalapenta, L. Cerulo, L. Aversano, and M. Di Penta. An empirical study on the maintenance of source code clones. Empirical Software
Engineering, 15(1):1–34, Feb. 2010.
[144] R. Tiarks, R.Koshcke, and R. Falke. An Assessment of Type-3 Clones as
Detected by State-of-the-Art Tools. In Proceedings of the 9th IEEE International Working Conference on Source Code Analysis and Manipulation(SCAM 2009), pages 67–76, Sep. 2009.
[145] M. Toomim, A. Begel, and S. L. Graham. Managing Duplicated Code with
Linked Editing. In Proceedings of the 2004 Symposium on Visual Languages
and Human Centric Computing (VL-HCC 2004), pages 173–180, Sep. 2004.
[146] N. Tsantalis and A. Chatzigeorgiou. Identification of Extract Method Refactoring Opportunities for the Decomposition of Methods. Journal of Systems
and Software, 84(10):1757–1782, Oct. 2011.
[147] Y. Ueda, T. Kamiya, S. Kusumoto, and K. Inoue. Gemini: MaintenanceSupport Environment Based on Code Clone Analysis. In Proceedings of
the 8th IEEE Internaitional Software Metrics Symposium (METRICS 2002),
pages 67–76, June 2002.
[148] R. D. Venkatasubramanyam, H. K. Singh, and K. Ravikanth. A Method
for Proactive Moderation of Code Clones in IDEs. In Proceedings of the
6th International Workshop on Software Clones (IWSC 2012), pages 62–66,
June 2012.
[149] H. V. Vliet. Software Engineering: Principles and Practices. John Wiley &Sons, 2008.
[150] W. Wang and M. W. Godfrey. We Have All of the Clones, Now What?
Toward Integrating Clone Analysis into Software Quality Assessment. In
Proceedings of the 6th International Workshop on Software Clones (IWSC
2012), pages 88–89, June 2012.
201

[151] X. Wang, Y. Dang, L. Zhang, D. Zhang, E. Lan, and H. Mei. Can I Clone
This Piece of Code Here? In Proceedings of the 27th International Conference on Automated Software Engineering (ASE 2012), pages 170–179, Sep.
2012.
[152] M. Wattenberg. Arc Diagrams: Visualizing Structure in String. In Proceedings of the IEEE Symposium on Information Visualization (InfoVis 2002),
pages 110–116, Oct. 2002.
[153] M. Weiser. Program Slicing. In Proceedings of the 5th International Conference on Software Enginieering (ICSE 1981), pages 439–449, Mar. 1981.
[154] R. Wettel and R. Marinescu. Archeology of Code Duplication: Recovering
Duplication Chains From Small Duplication Fragments. In Proceedings ofthe 7th International Symposium on Symbolic and Numeric Algorithms for
Scientific Computing (SYNASC 2005), Sep. 2005.
[155] M. D. Wit, A. Zaidman, and A. V. Deursen. Managing Code Clones Using
Dynamic Change Tracking and Resolution. In Proceedings of the 24th International Conference on Software Maintenance (ICSM 2009), pages 169–
178, Sep. 2009.
[156] Z. Xing, Y. Xue, and S. Jarzabek. CloneDifferentiator: Analyzing Clones
by Differentiation. In Proceedings of the 26th International Conference on
Automated Software Engineering (ASE 2011), pages 576–579, Nov. 2011.
[157] Y. Yamanaka, E. Choi, N. Yoshida, K. Inoue, and T. Sano. Industrial Application of Clone Change Management System. In Proceedings of the 6th International Workshop on Software Clones (IWSC 2012), pages 67–71, June2012.
[158] J. Yang, K. Hotta, Y. Higo, H. Igaki, and S. Kusumoto. Filtering Clones
for Individual User Based on Machine Leraning Analysis. In Proceedingsof the 6th International Workshop on Software Clones (IWSC 2012), pages
76–77, June 2012.
[159] J. Yang, K. Hotta, Y. Higo, H. Igaki, and S. Kusumoto. A Method for
Identifying Useful Code Clones with Machine Learning Techniques Basedon Similarity Between Clones. IPSJ Journal, 54(2):807–819, Feb. 2013. (inJapanese).
[160] N. Yoshida, T. Hattori, Y. Hayase, and K. Inoue. Retrieving Similar
Code Fragments Based on Synonymous Word Identification. IPSJ Journal,
50(5):1506–1509, May 2009. (in Japanese).
202[161] N. Yoshida, T. Ishio, M. Katsushita, and K. Inoue. Retrieving Similar CodeFragments based on Identifier Similarity for Defect Detection. In Proceedings of International Workshop on Defects in Large Software (DEFECTS
2008), pages 41–42, July 2008.
[162] K. Yoshimura and R. Mibe. Visualizing Code Clone Outbreak: An Industrial
Case Study. In Proceedings of the 6th International Workshop on Software
Clones (IWSC 2012), pages 96–97, June 2012.
[163] G. Zhang, X. Peng, Z. Xing, and W. Zhao. Cloning Practices: Why Developers Clone and What can be Changed. In Proceedings of the 28th International Conference on Software Maintenance (ICSM 2012), pages 285–294,
Sep. 2012.
[164] Y. Zhang, H. A. Basit, S. Jarzabek, D. Anh, and M. Low. Query-based Filtering and Graphical View Generation for Clone Analysis. In Proceedings ofthe 23rd International Conference on Software Maintenance (ICSM 2008),
pages 376–385, Oct. 2008.
[165] M. F. Zibran and C. K. Roy. A Constraint Programming Approach toConflict-aware Optimal Scheduling of Prioritized Code Clone Refactoring.
In Proceedings of the 11th International Working Conference on Source
Code Analysis and Manipulation (SCAM 2011), pages 105–114, Sep. 2011.

203