2015 12th Working Conference on Mining Software Repositories

Toward Reusing Code Changes
Yoshiki Higo∗ , Akio Ohtani∗ , Shinpei Hayashi† , Hideaki Hata‡ , and Kusumoto Shinji∗∗ Osaka University, Yamadaoka 1–5, Suita, Osaka 565–0871, Japan

Email: {higo,a-ohtani,kusumoto}@ist.osaka-u.ac.jp† Tokyo Institute of Technology, Ookayama 2–12–1, Meguro-ku, Tokyo 152–8552, Japan

Email: hayashi@se.cs.titech.ac.jp‡ Nara Institute of Science and Technology, Takayama-cho 8916–5, Ikoma, Nara 630–0192, Japan

Email: hata@is.naist.jp($% "#!%$ 
"%%# %$ "%%# $#%!'!"#$* "&%"&%

'!"#$ "&%Fig. 1.

•

Source code reuse is one of the promising ways to develop software systems efﬁciently. By bringing code fromother existing software systems, developers do not need to
implement functions required in a new system from scratch.
Moreover, reusing well-tested code realize that a new system
becomes highly reliable with low cost. So far, many techniquesand systems helping code reuse have been proposed andimplemented [1], [2], [3].

•
#
 
$%
$%

 "%%# $#  I NTRODUCTION $%!+!
!$# $&$%! $  Overview of proposed systema patch for ﬁxing the similar bug (code before andafter the bug ﬁx), andtest cases for checking the correctness of the bug ﬁx.

If we have the code before the bug ﬁx, we do not have tosearch the cause of the current bug by ourselves. We are able
to utilize the code to search the cause [5]. We are also able toreuse the test cases for the current bug.
Code changes can be conducted more efﬁciently by leveraging the past code change information. Existing code reusetechniques help developers implement code for new functions
meanwhile our novel system helps them change code forexisting functions. Our technique is available when there is
at least a past code change, which is similar to a code changethat a developer is about to conduct. The authors have revealed
that the same code changes are repeatedly conducted in every
software system during its evolution [6]. Consequently, we are
conﬁdent that our technique is useful for many code changes.

Code reuse techniques are very useful when softwaresystems require new functions. They help developers searchavailable code and understand how to reuse it. However, they
are not sufﬁcient when a system requires code changes. Duringsoftware evolution, source code are repeatedly changed due
to various reasons such as bug ﬁxes, function enhancements
and refactorings. Some investigations revealed that the ratio ofcosts required after the ﬁrst release of software systems are
increasing gradually and over 90% of the total costs are spent
after the ﬁrst release [4]. Consequently, it is very important tosupport source code changes as well as implementations.

II.

S YSTEM FOR R EUSING C ODE C HANGES

Figure 1 shows a system that we are envisioning. The
system takes the information of a code change that a developer
is about to conduct as its input. Then, the system suggests
the code to be changed and how to change the code. If
multiple suggestions are available, they are ranked based on
their signiﬁcances. The system consists of three components.

In this research, we are envisioning a novel system tosupport source code changes by reusing past code changes.
Herein, change reuse means leveraging information of pastcode changes on a current code change, which developers
are about to conduct. The purpose of our system is helping
developers change code efﬁciently.

Change Pattern Database: including information of pastcode changes. In order to reuse them easily, they are stored
into the database as patterns.
Change Pattern Search Engine: taking the information ofa code change that a developer wants to conduct as its input,
and searching code changes that are similar to it. Found similarcode are passed to code search engine.
Code Search Engine: taking past code changes as its input,
and searching which code of the developer’s system should bechanged. Identiﬁed code is suggested to developers.

The following operations are required when a developer
encounters a new bug in her/his software system:• identifying which code is the cause of the bug,• considering how to ﬁx the identiﬁed code,• conducting code changes, and• testing whether the change correctly ﬁxed the bug.
Assume that we are able to know that a similar bug had
occurred in the past and then we are able to obtain thefollowing information of the similar bug:978-0-7695-5594-2/15 $31.00 © 2015 IEEE
DOI 10.1109/MSR.2015.43

%$)$%
#%$)$%

Keywords—Change reuse, Source code analysis, Code cloneI.

$" ' )$%!#! #&$

Abstract—Existing techniques have succeeded to help developers implement new code. However, they are insufﬁcient to help tochange existing code. Previous studies have proposed techniques
to support bug ﬁxes but other kinds of code changes suchas function enhancements and refactorings are not supportedby them. In this paper, we propose a novel system that helps
developers change existing code. Unlike existing techniques, oursystem can support any kinds of code changes if similar codechanges occurred in the past. Our research is still on very earlystage and we have not have any implementation or any prototype
yet. This paper introduces our research purpose, an outline of oursystem, and how our system is different from existing techniques.

372specify a code change that they want to conduct as a query.
More concretely, in this research, a query should be a list ofwords representing a code change. For example, in cases of bug
ﬁxes, query words should be symptom of the buggy behavior
or variable/method names appearing in the thrown exception.
The system compares words in a given query to words ineach change patterns. In change patterns themselves, userdeﬁned names such as variable names have been replaced withspecial tokens to remove vocabulary differences. However,each change pattern has vocabulary information used in its
original code. We are going to use vocabulary not only inchanged code but also in signatures of the class and themethod that include the changed code because an existing
study reported that vocabulary in method’s signature is themost informative [9].

In the reminder of this section, we describe the scheme ofeach component. Please note that the details of the components
are still under consideration at this paper submission.
A. Change Pattern Database
Change pattern database includes code changes that wereextracted from existing software repositories such as Git andSubversion. There should be a huge amount of code changes inthis database because all the code changes are extracted. Someof them should be similar or identical to one another. If there
are multiple code changes that are available at developer’s
context, ranking them appropriately is very important.
Consequently, we utilize a notion change pattern, which
is a formalized pattern that shows how a code fragment waschanged to another one. In this research, every code change isregarded as a change pattern, and two or more code changes
are regarded as the same change pattern if they are identicalor enough similar to one another.

C. Code Search Engine
Code search engine takes a change pattern, which is an
output of Change pattern search engine, as its input, and it
searches code that is identical/similar to the pre-changed codeof the given pattern. Identiﬁed code is the locations to bechanged, and the post-changed code of the given pattern isa suggestion how to change them. Searching a given piece ofcode from a large amount of source code is a kind of clone
detections, and there exist some research studies [5], [10].

We do not regard the whole added/deleted code in acommit as a code change because multiple code fragments
could be changed in a commit. Some research studies havereported that there are commits including tangled changed incode repositories [7], [8]. We deﬁne that a code change is acorrespondence between an added code chunk and a deleted
one. Thus, there could be multiple code changes in a commit.

D. Scenario

Currently, we are going to regard two code changes, c1 andc2 , as the same pattern if they satisfy the following conditions:ac(c1 ) = ac(c2 ) ∧Herein, we describe how developers can use our systemon their change tasks. At the beginning of using our system,
developers need to construct a change pattern database. When
constructing a database, developers need to select existing
repositories as resources of change patterns. There is noconstraint for selecting repositories, but the followings should
be reasonable standards to extract useful change patterns.

pc(c1 ) = pc(c2 )where ac(c) means the code where code change c is applied,and pc(c) means the changed code by the code change c.
At present, we have not decided how we represent pre/postchanged code yet. The simplest way is representing them asconsecutive lines such as Unix diff command. An advantage
of such a line-based representation is its high speed.

Same libraries: the ﬁrst standard is using software repositories where the code uses the same libraries as developers’software. Existing studies reported that there are many stylized
patterns to use APIs [11], [12], [13], [14]. Consequently, using
such repositories will allow developers to reuse code changes
that are related to API invocations for the libraries.
Same domains: the second standard is using software
repositories that are the same domains as developer’s software. Functions included in software systems depend on their
domains, so that kinds of occurred code changes also dependon their domains. Using the same domains’ software will be
beneﬁcial to extract useful code changes.
Same organization: the third standard is using software
repositories that were developed in the same organizations.
Organizations occasionally have their local rules for programcoding. Using the same organization’s software allows developers to reuse code changes that depend on such local rules.
Same developers: the fourth standard is using software
repositories of the same developers. Developers learn their own
implementation styles intentionally or unintentionally if they
repeatedly develop the same kinds of functions. Using the samedevelopers’ software makes it possible to reuse code changes
on such developer-dependent implementations.
Same software: the last standard is using the repositoryof the developer’s software itself. This standard will be very

However, in such a representation, changes on consecutive
lines are regarded as one code change. If one actual codechange is conducted on multiple lines that are separated on
source ﬁles, changes of them are not regarded as the samecode change. Consequently, we are going adopt a graph-based
representation. In this approach, a program dependence graph(in short, PDG) is constructed from the code before and after
a given change on the changed method. Then, subgraphs
extracted from the before and after PDGs. Extracted subgraphs
consist of changed program elements. Even if multiple program elements located in separated lines are changed, they canbe regarded as one code change if the elements are directly
connected to each other in the PDGs.
In order to prioritize code changes when they are suggested
to developers, they are characterized by using some metrics.
At present, we are going to use the number of code changes
belonging to a given change pattern and the number of projects
where a given change pattern appear as metrics.
B. Change Pattern Search Engine
Change pattern search engine takes developers’ query as
its input and identiﬁes change patterns related to it. Developers373

helpful for bug ﬁxes caused by code clones. In other words,
if a bug occurs in a code fragment that was overlooked by adeveloper in the past code change, our system should be able
to detect it. Some existing research reported that developers
occasionally overlook code fragments to be changed [6], [15].
Our system will be helpful to ﬁx such bugs.

     

 

After a database is created, developers can use the system
whenever they want. The system has been designed to help
developers identify code fragments to be changed and detemine
how the code fragments are changed. This system can also
be used in other situations. For example, we assume that adeveloper has identiﬁed a code fragment to be changed byherself. In this case, if she inputs the identiﬁed code fragmentto the system, she will get examples showing how to change
the code fragments. She also will get other locations to bechanged in the same way. Another situation where this system
is useful is cases that a developer has identiﬁed and changed
code fragments. In this situation, she can leverage this system
to check if her changes are consistent to the changes that wereconducted on similar code fragments in the past.

 










                     











Fig. 2. Ratio of cross-project code changes for each project (the projects are
sorted in the descending order of the ratio)

managed in a single repository2 . Each project corresponds to a
subdirectory of the root directory of the repository. We mined
code changes in the past ﬁve years (from the beginning of2010 to the end of 2014). In the period, there were 324,992
commits that changed at least one Java source ﬁle and 122
projects were changed at least once.
B. Data Analysis

We are going to implement the system as a plugin of IDEs
such as Eclipse and IntelliJ IDEA. Our plugin will have a text
ﬁeld to input queries. After receiving a query from a developer,
the plugin suggests which code and how it should be changed
on IDE’s text editors. Integrating our system to IDEs shouldbe very helpful for developers because they do not need tomove away from IDEs for searching available past changes.
III.

  

In this preliminary study, we utilized our previous technique [6] to detect change patterns. It mines code changes
from code repositories. In order to explain change patterns, wedeﬁne program statements, code fragments, and code changes.
A program statement is represented as a sequence ofprogram tokens, which are identiﬁed by lightweight sourcecode analysis. User-deﬁned identiﬁers are replaced with special tokens with parameterized matching technique, which issometimes used in clone detection [16]. If two statements havethe same sequences of tokens, they are regarded as identical.

P RELIMINARY S TUDY

We have already conﬁrmed that the pattern-based suggestion works well within a project [6]. However, in order forthe proposed system to be useful, the same code changes
must occur cross projects. Consequently, we conducted apreliminary study to investigate the following questions.
RQ1: How often do the same code changes occur crossdifferent projects?
RQ2: How often do cross-project code changes1 appear ina project?

A code fragment is a sequence of program statements.
If two code fragments have the same sequences of program
statements, they are regarded as identical.

A. Data Collection

A code change is a transformation from a code fragment
to another code fragment. It is represented as a pair of a prechanged code fragment and a post-changed code fragment. If
two code changes have the same pre-changed and post-changed
code fragments, they are treated as an identical change pattern.
Even if a code change is not the same as any of the other codechanges, it is treated as a change pattern.

Projects in Apache Software Foundation (in short, ASF)
were selected as targets. All the ASF projects are being

C. Result and Discussion
Table I shows the number of detected change patterns
and code changes. The ﬁrst row shows within-project change
patterns and code changes. There are about 830K withinproject patterns, and they occupy 92.8% of all the patterns.
The within-project patterns consists of 1.8M code changes,
which occupy 51.5% of all the changes.

1 Cross-project code change means a code change belonging to a change
pattern that appears in two or more projects.

TABLE I.

D ETECTED CHANGE PATTERNS AND CODE CHANGES

Cross-projectWithin-project
2–10
11–20
21–30
31–40
41–50
51–60
61–70
71–80
81–90
91–10
over 100subtotal

Change patterns
Number
Percentage
828,61692.8%
59,658
6.68%
2,810
0.32%
856
0.096%
384
0.043%
189
0.021%
112
0.013%
71
0.0080%50
0.0056%28
0.0031%220.0025%130.0015%64,193
7.2%

Code changes
Number
Percentage
1,845,048
51.5%
548,464
15.3%
172,327
4.81%
110,453
3.08%
90,0262.51%
80,3892.24%
69,658
1.95%
64,2501.79%
91,887
2.57%
74,971
2.09%
120,732
3.37%
312,603
8.73%
1,735,760
48.5%

The rows from the second to the bottom show cross-projectchange patterns and code changes. The cross-project patterns
are grouped based on the number of projects where they were
found. For example, the second row shows change patterns
appeared in at least 2 projects but no more than 10 projects.
The table shows the more projects change patterns appear in,
the less the number of them becomes. However, the number of
2 http://svn.apache.org/repos/asf/374    one [20]. Their technique does not require the code change
history of the target software. However, queres to search codefragments are relatively complex. For example, in literature[20], the following query is introduced as an example:                       Fig. 3.

function A, function B, variable C, variable D; A contains”malloc” or contains ”realloc”, B contains ”malloc” orcontains ”realloc”; C dataDepends A, D dataDepends B, C
onestep dataDepends D, C is FieldOf D; want C.

Change pattern example

Meng et al. developed a tool named LASE to help developers locate code fragments to be changed and determine
how to change them [21]. LASE takes two or more codefragments that developers have already identiﬁed and changed.
Then, it identiﬁes other code fragments to be changed andsuggest how to change them. This technique is useful after
developers identiﬁed and changed two or more code fragments
by themselves. On the other hand, our technique aim to help
developers identify and change code fragments even if they
have not identiﬁed any of the code fragments to be changed
yet. Consequently, the situation for our proposed technique isdifferent from the one for LASE.

code changes does not follow this trend. Each group of crossproject changes occupies at least 1% of all the changes. The
bottom row shows a surprising result, 0.0015% of the patterns
occupy 8.73% of the changes.
Figure 2 shows the ratio of cross-project code changes
for each project. The minimum value is 15.4% for project
infrastructure (2/13). The maximum is 100% for kafka (1/1)
and phoenix (120/120). Median for the 122 projects is 44.9%.
There is a tendency that the ratio of the projects including alarge number of code changes is close to the median value.
Figure 3 shows an actual cross-project change pattern. Exactly the same changes occurred in 4 projects (directmemory,
incubator, myfaces, and portals); the ﬁgure shows original
tokens without special tokenization. This pattern included 8
code changes, the ﬁrst one occurred at 19/Mar/2010 andthe last one occurred at 8/Nov/2012. These changes wereconducted in code where two objects are compared. The code
before the change checked if the comparison target is null ornot. However, it was insufﬁcient as an object comparison. The
code was changed to perform another comparison by using
equals method if the comparison target was not null. Although
this pattern includes some syntax inconsistencies due to thelack of pattern reﬁnement, it indicates the existence of usefulpatterns in the extracted ones.

There are some existing techniques that extract codechanges by using abstract syntax trees [22], [23]. In their techniques, code changes are represented as changes on subtrees.
By recognizing patterns of subtree changes, the techniques
identify what a given change means. For example, renaming
variable names and extracting a code fragment as a new
method can be automatically identiﬁed.
Some existing research studies succeeded to generate automatically bug ﬁx patches to a certain extent. GenProg
generates candidates for a ﬁxed program by changing a buggy
program slightly with genetic programing techniques [24]. PAR
uses past patches that humans wrote for ﬁxing bugs [25]. It
identiﬁes bug ﬁx patterns from the human-written patches andtry to ﬁx a current bug. SemFix is a tool that automatically
repairs programs [26]. It derives repair constraints from test
cases and solves the repair constraints to generate a valid
repair. This technique can generate a repair even if its similar or
identical code does not exist in the program. Those techniques
require many test cases to ﬁx target programs. Chandra et al.
proposed a technique for identifying wrong conditions thatcause bugs in program source code [27]. Their technique also
can suggest how it should be changed.

Our answer to the RQ1 is as follows: cross-project codechanges occupy only 7.2% of all the change patterns, however
they cover 48.5% of all the code changes.
Our answer to the RQ2 is as follows: all the projects
include cross-project code changes. The median of the ratioof cross-project changes against all the changes is 44.9%.
The answers mean that a small number of cross-projectchange patterns cover about half of the code changes and all
the projects include cross-project code changes. Thus, if thesystem can utilize cross-project change patterns appropriately,
it would be able to support code changes for many projects.
IV.

At present, in the ﬁeld of software engineering, genetic
programming attracts much attention. It is used for not only
bug ﬁxes but also other purposes. For example, Langdon et al.
and White et al. proposed techniques that utilize genetic programming to improve performance of human-written programs[28], [29]. There are also some techniques that automatically
identify refactoring opportunities [30], [31], [32], [33].

R ELATED W ORK

Several existing studies have found some evidences that
our system will be a promising technique for reducing costof code changes. The authors reported that there are the samechange patterns that are applied to source code repeatedly [6].
Nguyen et al. reported there are large number of repetitive codechanges both within-project and across-project [17]. Negara etal. reported that different developers implemented code withthe same change patterns when they were gave the same tasks[18]. Barr et al. found that the content of a new code often
can be assembled out from the content of existing code [19].

V.

C ONCLUSION

In this paper, we introduced our system that helps developers change source code. The system utilizes past codechanges in other or same software and it supports any kindsof code changes such as bug ﬁxes, function enhancements,
and refactorings. The preliminary study shows that crossproject change patterns occupy about half of code changes.
Consequently, if we are able to utilize them appropriately, oursystem will be very helpful for developers.

Wang et al. proposed a technique to help developers
change code fragments at multiple places without missing any

375

R EFERENCES[1] M. Grechanik, C. Fu, Q. Xie, C. McMillan, D. Poshyvanyk, andC. Cumby, “A Search Engine for Finding Highly Relevant Applications,” in Proceedings of the 32nd International Conference on Software
Engineering, 2010.
[2]

[21]

[22]

K. Inoue, R. Yokomori, T. Yamamoto, M. Matsushita, and S. Kusumoto,“Ranking Signiﬁcance of Software Components Based on Use Relations,” IEEE Transactions on Software Engineering, vol. 31, no. 3, 2005.

[3] C. McMillan, M. Grechanik, D. Poshyvanyk, Q. Xie, and C. Fu, “Portfolio: Finding Relevant Functions and Their Usage,” in Proceedings ofthe 33rd International Conference on Software Engineering, 2011.

[23]

[4]

J. Koskinen, “Software Maintenance Costs,” http://web.archive.org/web/20040202105224/http://www.cs.jyu.ﬁ/∼koskinen/smcosts.htm.

[24]

[5]

Y. Higo, Y. Ueda, S. Kusumoto, and K. Inoue, “Simultaneous Modiﬁcation Support Based on Code Clone Analysis,” in Proceedings of the
14th Asia-Paciﬁc Software Engineereing Conference, 2007.

[6]

Y. Higo and S. Kusumoto, “How Often Do Unintended Incosistencies
Happend? –Deriving Modiﬁcation Patterns and Detecting Overlooked
Code Fragments–,” in Proceedings of the 2012 28th IEEE International
Conference on Software Maintenance, 2012.

[26]

[7]

K. Herzig and A. Zeller, “The Impact of Tangled Code Changes,”in Proceedings of the 10th Working Conference on Mining Software
Repositories, 2013.

[27]

[8]

H. Kirinuki, Y. Higo, K. Hotta, and S. Kusumoto, “Hey! Are You Committing Tangled Changes?” in Proceedings of the 22nd International
Conference on Program Comprehension, 2014.

[28][9] A. Corazza, S. D. Martino, V. Maggio, and G. Scanniello, “Investigating
the Use of Lexical Information for Software System Clustering,”
in Proceedings of the 2011 15th European Conference on Software
Maintenance and Reengineering, 2011.

[29][10] I. Keivanloo, J. Rilling, and P. Charland, “Internet-scale Real-time CodeClone Search Via Multi-level Indexing,” in Proceedings of the 2011 18th
Working Conference on Reverse Engineering, 2011.

[30]

[25]

[11] M. Acharya, T. Xie, J. Pei, and J. Xu, “Mining API Patterns As Partial
Orders from Source Code: From Usage Scenarios to Speciﬁcations,”in Proceedings of the the 6th Joint Meeting of the European Software
Engineering Conference and the ACM SIGSOFT Symposium on The
Foundations of Software Engineering, 2007.

[31]

[32]

[12] R. P. L. Buse and W. Weimer, “Synthesizing API Usage Examples,”in Proceedings of the 34th International Conference on Software
Engineering, 2012.

[33][13] H. A. Nguyen, T. T. Nguyen, G. Wilson, Jr., A. T. Nguyen, M. Kim, andT. N. Nguyen, “A Graph-based Approach to API Usage Adaptation,” inProceedings of the ACM International Conference on Object Oriented
Programming Systems Languages and Applications, 2010.
[14] H. Zhong, T. Xie, L. Zhang, J. Pei, and H. Mei, “MAPO: Mining
and Recommending API Usage Patterns,” in Proceedings of the 23rd
European Conference on Object-Oriented Programming, 2009.
[15] L. Barbour, F. Khomh, and Y. Zou, “An Empirical Study of Faults in
Late Propagation Clone Genealogies,” Journal of Software: Evolution
and Process, vol. 25, no. 11, 2007.
[16] B. S. Baker, “Parameterized Duplication in Strings: Algorithms and an
Application to Software Maintenance,” SIAM Journal on Computing,vol. 26, no. 5, 1997.
[17] H. A. Nguyen, A. T. Nguyen, T. T. Nguyen, T. N. Nguyen, and H. Rajan,“A Study of Repetitiveness of Code Changes in Software Evolution,”in Proceedings of the 28th International Conference on AutomatedSoftware Engineering, 2013.
[18] S. Negara, M. Codoban, D. Dig, and R. E. Johnson, “Mining Finegrained Code Changes to Detect Unknown Change Patterns,” in Proceedings of the 36th International Conference on Software Engineering,
2014.
[19] E. T. Barr, Y. Brun, P. Devanbu, M. Harman, and F. Sarro, “The
Plastic Surgery Hypothesis,” in Proceedings of the 22nd ACM SIGSOFTInternational Symposium on Foundations of Software Engineering,
2014.
[20] X. Wang, D. Lo, J. Cheng, L. Zhang, H. Mei, and J. X. Yu, “Matching
Dependence-related Queries in the System Dependence Graph,” in376

Proceedings of the IEEE/ACM International Conference on AutomatedSoftware Engineering, 2010.
N. Meng, M. Kim, and K. S. McKinley, “LASE: Locating and Applying
Systematic Edits by Learning from Examples,” in Proceedings of the2013 International Conference on Software Engineering, 2013.
J. Falleri, F. Morandat, X. Blanc, M. Martinez, and M. Montperrus,“Fine-grained and Accurate Source Code Differencing,” in Proceedingsof the 29th ACM/IEEE International Conference on Automated Software
Engineering, 2014.
B. Fluri, M. Wuersch, M. PInzger, and H. Gall, “Change Distilling:
Tree Differencing for Fine-Grained Source Code Change Extraction,”
IEEE Transactions on Software Engineering, vol. 33, no. 11, 2007.
C. Le Goues, M. Dewey-Vogt, S. Forrest, and W. Weimer, “A Systematic Study of Automated Program Repair: Fixing 55 out of 105 Bugs
for $8 Each,” in Proceedings of the 34th International Conference on
Software Engineering, 2012.
D. Kim, J. Nam, J. Song, and S. Kim, “Automatic Patch Generation
Learned from Human-written Patches,” in Proceedings of the 2013
International Conference on Software Engineering, 2013.
H. D. T. Nguyen, D. Qi, A. Roychoudhury, and S. Chandra, “SemFix:
Program Repair via Semantic Analysis,” in Proceedings of the 2013
International Conference on Software Engineering, 2013.
S. Chandra, E. Torlak, S. Barman, and R. Bodik, “Angelic Debugging,”
in Proceedings of the 33rd International Conference on Software
Engineering, 2011.
W. B. Langdon, M. Modat, J. Petke, and M. Harman, “Improving
3D Medical Image Registration CUDA Software with Genetic Programming,” in Proceedings of the 2014 Conference on Genetic andEvolutionary Computation, 2014.
D. R. White, A. Arcuri, and J. A. Clark, “Evolutionary Improvement of
Programs,” IEEE Transactions on Evolutionary Computation, vol. 15,
no. 4, 2011.
M. Fokaefs, N. Tsantalis, E. Stroulia, and A. Chatzigeorgiou, “Identiﬁcation and Application of Extract Class Refactorings in Object-oriented
Systems,” Journal of Systems and Software, vol. 85, no. 10, 2012.
A. Han and D. Bae, “Dynamic Proﬁling-based Approach to Identifying
Cost-effective Refactorings,” Information and Software Technology,
vol. 55, no. 6, 2013.
J. Henkel and A. Diwan, “CatchUp!: Capturing and Replaying Refactorings to Support API Evolution,” in Proceedings of the 27th International
Conference on Software Engineering, 2005.
N. Tsantalis and A. Chatzigeorgiou, “Identiﬁcation of Move Method
Refactoring Opportunities,” IEEE Transactions on Software Engineering, vol. 35, no. 3, 2009.