Applying Clone Change Notification System into an
Industrial Development Process
Yuki Yamanaka ∗ , Eunjong Choi ∗ , Norihiro Yoshida † , Katsuro Inoue ∗ , Tateki Sano ‡∗ Graduate School of Information Science and Technology, Osaka University, Japan{y-yuuki, ejchoi, inoue}@ist.osaka-u.ac.jp† Graduate School of Information Science, Nara Institute of Science and Technology, Japan

yoshida@is.naist.jp‡ Software Process Innovation and Standardization Division, NEC Corporation, Japant-sano@cp.jp.nec.com
Abstract—Programmers tend to write code clones unintentionally even in the case that they can easily avoid them. Clone change
management is one of crucial issues in open source software(OSS) development as well as in industrial software development(e.g., development of social infrastructure, financial system, andmedical equipment). When an industrial developer fixes a defect,
he/she has to find the code clones corresponding to the codefragment including it. So far, several studies performed on theanalysis of clone evolution in OSS. However, to our knowledge,a few researches have been reported on an application of a clonechange notification system to industrial development process.
In this paper, we introduce a system for notifying creationand change of code clones, and then report on the experience
with 40-days application of it into a development process in
NEC Corporation. In the industrial application, a developer
successfully identified ten unintentionally-developed clones thatshould be refactored.
Index Terms—Code Clone, Software Maintenance, Refactoring

I. Introduction
A code clone is a code fragment that has similar or identicalcode fragments in source code. Many code clone detection
tools [1], [2], [3] have been proposed to capture various
aspects of source code similarity. A code clone detection tool
generally finds all source code clones that match its own
definition of code clone; therefore, a tool may report a large
number of code clones for large scale software. On the other
hand, software developers are interested in only the subset
of code clones that are relevant to their activities [4]. For
example, although refactoring [5] is one of promising activities
to improve the maintainability of code clones, code clone is
not always appropriate for refactoring. One of the reasonsis that developers sometimes have to repeatedly write code
clones that cannot be merged due to the in-expressivenessof a programming language [6], [7], [8]. However, a cloneset (i.e., a set of code clones identical or similar to eachother) indicates considerable opportunities for developers tomerge code clones into one or a few program units (e.g., Javamethods) by refactoring [6], [7], [8].
Refactoring aimed to merge code clones is required not
only in open source projects but also in industry. A development team at NEC Corporation, a Japanese multinational
IT company, has been developed a web application software.

978-1-4673-3091-6/13/$31.00 c 2013 IEEE

Because the team plans long-time maintenance as well as
reuse for other system developments, the developers are highly
motivated to merge code clones into a single module.
However, the cost of refactoring cannot be ignored especially in industry. Regression test after refactoring takes muchcost to preserve behavior after refactoring. The development
team at NEC also considers the cost of refactoring. Basically,
they do not touch source code after large-scale system test for
releasing major version of the software because refactoring
after large-scale test leads the re-performance of such costly
test. Therefore, they need to know newly-appeared clones
regularly, especially before large-scale system test.
In this paper, we present clone change notification system
Clone Notifier (see Figure 3) for the promotion of eﬃcient
clone management (e.g., refactoring, simultaneous editing).
Clone Notifier notifies newly-appeared and changed clones
regularly to developers. As an industrial application, we applied Clone Notifier into the process of the web application
software development at NEC. The result shows 119 newlyappeared clone sets, and ten out of them are recognized as
refactoring candidates by an experienced project manager (i.e.,
he recognized that each of ten clone sets should be merged
into a single module).
As an ex-post analysis, we investigated the characteristics
of clone sets recognized as refactoring candidate by the experienced project manager at NEC. The aim of the analysis isdata collection for the development of technique to recommend
refactoring candidate from all newly-appeared and changed
clones. The recommendation is promising to help developers
to reduce the cost of finding clone sets should be merged intoa single module.
The rest of paper is organized as follows: Section II provides
a brief explanation of CCFinder, a code clone detection tool.
Section III describes categorization of code clones and clone
sets based on the evolution patterns between two versionsof source code. Section IV explains on our developed clonechange notification system, Clone Notifier. Section V describes
results of industry application and feedbacks from project
manager. Section VI explains ex-post analysis. Section VII
discusses threats to validity. Section VIII presents some related

199

ICPC 2013, San Francisco, CA, USAStep2 : Trace code clones between two versions based ona method which is described in section III-A.
Step3 : Categorize code clones in Ct and Ct−1 based on adefinition which is described in section III-B.
Step4 : Categorize clone sets in Ct and Ct−1 based on adefinition which is described in section III-C.

work. Section IX summarizes our paper with final remarks andindications about our future work.
II. Code Clone Detection Tool : CCFinderThis section briefly explains on CCFinder [3] that we use asa clone detection tool. CCFinder is a token-based code clone
detection tool. It takes source files as an input and outputs
location information of code clones in source code. It detects
identical code fragments except for variations in whitespaces
and comments. It also detects structurally/syntactically identical fragments except for variations in identifies, literals, types,
layout and comments [9].
The clone detection process of CCFinder consists of four
steps:• Lexical analysis: Each line of source files is divided into
tokens corresponding to a lexical rule of the programming
language. The tokens of all source files are concatenatedinto a single token sequence, so that finding clones in
multiple files is performed in the same way as single fileanalysis.
• Transformation: The token sequence is transformed (i.e.,
tokens are added, removed, or changed) based on thetransformation rules that aims at regularization of identifiers and identification of structures. Then, each identifier
related to types, variables, and constants is replaced witha special token. This replacement makes code fragmentswith diﬀerent variable names to become clone pairs.
• Match Detection: From all the substrings on the transformed token sequence, equivalent pairs are detected asclone pairs.
• Formatting: Each location of clone pair is converted intoline numbers of original source files.
The output file of it is represented in the form of clone pair(i.e., a pair of code clones) or clone set (i.e., a set of code
clones identical or similar to each other).
CCFinder is widely used in the universities as well as industries because of its high speed and accuracy to detect code
clones from source code. A division for software engineering
at NEC is one of CCFinder users. Several members of thedivision have worked for the promotion of the use of CCFinder
in NEC.
III. Categorization of Clone Clones and Clone Sets
Clone Notifier performs checkup of changed code clones
from source code based on categorizations of code clones
and clone sets. We defined these categorizations based on theevolution patterns between two versions of source code.
To describe categorization of code clones and clone sets,
we defined Vi as source code at the point of time i, and Ci
as a set of code clones detected in Vi . Input of this method is
Vt (the latest version of source code) and Vt−1 (the previous
version of source code). These categorizations consist of thefollowing steps:
Step1 : Detect Ct and Ct−1 by analyzing overall Vt and Vt−1
using CCFinder.

A. Tracing Code Clones
Our previous study [10] traced code clones across multiple
versions based on correspondence of the start and end line ofthem in source code. This study uses the same method with
our previous study to trace code clones between two versions.
Also, we defined the parent-child relationship to code
clones between two versions to trace code clones. When code
clone B ∈ Ct corresponds to code clone A ∈ Ct−1 , we define
B as a child clone of A, and A as a parent clone of B. The
following presents how we defined parent-child relationshipand trace code clones between two versions in three diﬀerent
cases with figure 1.
Case 1: In Figure 1(a), two lines were inserted to A. Thismeans that code clone A ∈ Ct−1 was modified between two
versions. In this case, code fragment B in Vt corresponding
to A can be traced by counting and inserted lines in A. Thus,
the start line number of B is the same as A, and the end line
number of B is increased by two lines. When Ct contains B,
we define B is a child clone of A.
Case 2: In Figure 1(b), one line was inserted to the edge of
A. This means that edge of code clone A ∈ Ct−1 was modified
between two versions. If we regard one line was inserted aboveA, code fragment B1 corresponds to A. In contrast, if we regard
one line was inserted to A, code fragment B2 corresponds to
A. If Ct contains both of B1 and B2 , we define the child clone
as which has the nearest number of lines with A. In this case,because A and B1 are identical, we define B1 as a child clone
of A.
Case 3: In Figure 1(c), two lines were inserted above A
and two lines were also inserted to A. This means that codefragment which is located above code clone A ∈ Ct−1 and code
clone A ∈ Ct−1 were modified between two versions. In thiscase, code fragment B in Vt corresponding to A can be traced
by counting inserted lines. Thus, the start line numbers of B is
increased by two lines and end line numbers of B is increasedby four lines. When Ct contains B, we define B as a childclone of A.
B. Categorization of Code Clones
All code clones in Vt and Vt−1 are categorized based on
evolution patterns of them. To explain categorization of code
clones, we defined propositional function about code clone
Xc ∈ Ct and X p ∈ Ct−1 .

200

P(Xc ) : Parent clone of Xc exists in Vt−1 .
C(X p ) : Child clone of X p exists in Vt .
• M(Xc ) : Xc was modified between two versions.
• R(Xc ) : A pair of Xc and its parent clone is a clone pair.
••ŝŶƐĞƌƚƚǁŽůŝŶĞƐ

ŝŶƐĞƌƚŽŶĞůŝŶĞ





ĞĚ

ŝŶƐĞƌƚƚǁŽůŝŶĞƐ

sƚͲϭ

sƚ
(a) Case 1



ϭ Ϯ



sƚͲϭ

sƚ

sƚͲϭ

ĞĚ

(b) Case 2ĞĚŝŶƐĞƌƚƚǁŽůŝŶĞƐsƚ(c) Case 3

Fig. 1. Tracing code clones: parent-child relationship of code clones

The followings are categorization of code clones that we
defined. We explain this categorization with aforementioned
propositional function.
Stable clone: When code clone Xc satisfies P(Xc ) ∧¬M(Xc ), we defined each of Xc and the parent clone of
Xc as a stable clone respectively. A pair of stable clones
between the versions Vt−1 and V t means that the code
clone in Vt−1 is unmodified until Vt .
• Modified clone: When code clone Xc satisfies P(Xc ) ∧M(Xc ) ∧ CP(Xc ), we defined each of Xc and the parent
clone of Xc as a modified clone respectively. A pair ofmodified clones between the versions Vt−1 and Vt meansthat the code clone in Vt−1 is modified but contained in
the same clone set until Vt .
• Moved clone: When code clone Xc satisfies P(Xc ) ∧M(Xc ) ∧ ¬CP(Xc ), we defined each of Xc and the parent
clone of Xc as a moved clone. A pair of moved clones
between the versions Vt−1 and Vt means that the code
clone in Vt−1 is modified and then moved diﬀerent clone
set until Vt .
• Added clone: When code clone Xc satisfies ¬P(Xc ), we
defined Xc as an added clone. Added clone in Vt meansthat the code clone is newly added in Vt .
• Deleted clone: When code clone X p satisfies ¬C(X p ), we
defined X p as a deleted clone. Deleted clone in Vt−1 meansthat the code clone is deleted in Vt−1 .

New clone set: New clone sets contain added clones suchas clone set C in Figure 2. These clone sets involved inonly Vt .
• Deleted clone set: Deleted clone sets contain deleted
clones such as clone set D in Figure 2. These clone sets
involved in only Vt−1 .
••C. Categorization of Clone Sets
All clone sets in Vt and Vt−1 are categorized based on evolution patterns of them. We defined the following categorizationof clone sets according to the categorization of code clones
that they contain.
Stable clone set: Stable clone set contains code clones
that did not changed between two versions such as clone
set A in Figure 2. These clone sets contain stable clones
that involved in Vt and Vt−1 respectively.
• Changed clone set: Changed clone set contain one of themodified clone, moved clone, added clone, and deleted
clone such as clone set B in Figure 2. These clone setscontain modified, moved, deleted and added clones thatinvolved in Vt and Vt−1 respectively.
•

IV. Clone Change Notification System
According the feedbacks from the CCFinder users in NEC,
we found that developers are interested in code clones thatare changed, but it is diﬃcult for them to check changed
code clones from all of detected code clones. Therefore, wedeveloped a clone change notification system, Clone Notifierthat performs checkup of changed code clones in source code.
A. Overview
Figure 3 shows the process of Clone Notifier. Clone Notifier
takes two versions of source code as an input. It assumes thatthe developers use version control system such as Subversion
in software development.
To detects all of code clones from each of the two versions,
CCFinder is used as an clone detection tool in Clone Notifier.
A main reason why we use CCFinder is high applicability
and understandability of detection. Although syntax-based
and semantic-based detection tools are accurate, those tools
are not applicable in the case of unexpected source codecauses errors of syntax or semantic analyses. In order tocatch up minor language upgrade, and deal with incomplete
source code, token-based tools such as CCFinder is more
promising than syntax-based and semantic-based ones. The
understandability of detection result is important for industrial
application because developers would like to know the reason
why each pair of code is recognized as clones to consider thereason of duplication and ways to merge those clones.
The process of this system is comprises of following four
steps:
Step1 : Get the current version of source code from version
control system as the latest version Vt . 1
Step2 : Categorize code clones and clone sets between Vt
and Vt−1 which is described in section III.
1 We use source code that were analyzed in the last time as the previous
version Vt−1 .

201^ƚĂďůĞϭϭ͛^ƚĂďůĞ

^ƚĂďůĞϮϮ͛^ƚĂďůĞ

ůŽŶĞ^ĞƚůŽŶĞ^ĞƚDŽĚŝĨŝĞĚ
^ƚĂďůĞ
ĞůĞƚĞĚ

DŽĚŝĨŝĞĚϮϮ͛^ƚĂďůĞ

ϯůŽŶĞ^ĞƚůŽŶĞ^ĞƚŵŽĚŝĨǇWƌŽǀŝĚĞtĞďͲďĂƐĞĚ
ĐŽĚĞĐůŽŶĞǀŝĞǁĞƌ

hƐĞƌ
;ĚĞǀĞůŽƉĞƌ͕ŵĂŶĂŐĞƌͿͲŵĂŝůŶŽƚŝĨŝĐĂƚŝŽŶ

ϭ͛
Ϯ͛

ĚĚĞĚ

ϯ͛

ĚĚĞĚ

ĞůĞƚĞĚ

ϮĞůĞƚĞĚ

ůŽŶĞ^ĞƚůŽŶĞ^ĞƚsƚŽĚĞůŽŶĞ ŽĚĞ&ƌĂŐŵĞŶƚ

WĂƌĞŶƚʹŚŝůĚZĞůĂƚŝŽŶƐŚŝƉ

'ĞŶĞƌĂƚĞĞͲŵĂŝůof Apach Ant3 . The following information is provided by thee-mail notification.
• Project information (the Figure 4(a) ).
– File information: the number of all files, added files,
deleted files, and files that contain code clones– Categorization of clone sets: the number of stable,changed, new and deleted clone sets in Vt and Vt−1
– Categorization of code clones: the number of stable,
modified and added clones in Vt and deleted clones
inVt−1• Clone set list: the list of changed clone sets which
categorized into changed, new and deleted clone sets. The
following information on each clone set is provided asshown in Figure 4(b).
– Clone set id: the index assigned for each clone set
in Vt and Vt−1
– Code clone list: the list of code clones involved ineach clone set between two versions– Code fragment: each code clone with the line number
on the source file in Vt (g+h represents added line
and g-h represents deleted line.)ŵŽĚŝĨǇsƚͲϭDĂŝů^ĞƌǀĞƌ

ĚĚĞĚ

EĞǁ

ϭ

ůŽŶĞEŽƚŝĨŝĞƌ

tĞď^ĞƌǀĞƌ

Fig. 3. Process of Clone NotifierůŽŶĞƐĞƚĞůĞƚĞĚ

'ĞŶĞƌĂƚĞ,dD>ĨŝůĞƐ

ŚĂŶŐĞĚ

ŵŽĚŝĨǇ

ĐŽƉǇ
ĐŽƉǇ
ĐŽƉǇ

ŚĞĐŬͲŽƵƚƚŚĞĐƵƌƌĞŶƚƐŽƵƌĐĞĐŽĚĞsĞƌƐŝŽŶŽŶƚƌŽů^ǇƐƚĞŵ

^ƚĂďůĞϭ͛ϭŽŵŵŝƚŶĞǁƐŽƵƌĐĞĐŽĚĞ^ĂŵĞůŽŶĞ^Ğƚ

Fig. 2. Example of categorization of code clones and clone sets

Step3 : Generate html files for web-based user interface(UI) and a text file for e-mail notification 2 .
Step4 : Send an e-mail with generated text file to developers
on changed clones.
As described above, Clone Notifier provides information ofchanged code clones and clone sets between the two versions
s by an e-mail.Also, Clone Notifier provides web-based code
clone viewer for developers who see an e-mail.
B. E-mail Notification
This e-mail notification is aimed to send an initial reportof new code clones and changed code clones. Figure 4 shows
the parts of a text file for e-mail notification of two versions

C. Web-Based UIThis viewer supports developers who see a notification email and would like to understand the detail of new andchanged clone sets. Once a developer select one of clone sets,
this Web-based UI shows source code and also highlights code
clones in the source code. Figure 5 shows clone set list pageand source file page in the web browser. This user interface
consists of the following pages• Clone set list page : It displays the list of clone sets
(Figure 5(a)).Users can move to the corresponding source
file page by clicking the links of each code clone.
• Source file page : It displays code clones that are involvedin the selected clone set in clone set list page (Figure5(b)). Each code clone is highlighted on this page.

2 Note that the analysis of the system is stored for two months as html files.

202

3 http://ant.apache.org/

###################################################
Project Name : Apach Ant
2012/XX/XX###################################################< File Informaon >The number of all ﬁles 䠖1193
Added ﬁles䠖8
Deleted ﬁles䠖1
The number of ﬁles which contain code clones 䠖506
< Categorizaon of Clone Sets >Stable Clone Sets䠖1676
Changed Clone Sets䠖29
New Clone Sets䠖34
Deleted Clone Sets䠖10

Clones set
ID*************************************************************@1*************************************************************@1.0:MODIFIED ¥src¥main¥org¥apache¥tools¥ant¥listener¥MailLogger.java 375.9-380.34@1.1:STABLE ¥src¥main¥org¥apache¥tools¥ant¥ﬁlters¥FixCrLfFilter.java 143.13-148.34@1.2:STABLE ¥src¥main¥org¥apache¥tools¥ant¥ﬁlters¥FixCrLfFilter.java 144.13-149.43@1.3:STABLE ¥src¥main¥org¥apache¥tools¥ant¥taskdefs¥MacroInstance.java 248.9-253.25---------------------------------------------### @1.0### ¥src¥main¥org¥apache¥tools¥ant¥listener¥MailLogger.java
372
}
373
// convert the replyTo string into a vector of emailaddresses
374
Vector replyToList = vectorizeEmailAddresses(values.replytoList());<START MODIFIED CLONE>
375
mailer.setHost(values.mailhost());
376
mailer.setPort(values.port());
377
mailer.setUser(values.user());
378
mailer.setPassword(values.password());
379
mailer.setSSL(values.ssl());
380 +mailer.setEnableStartTLS(values.starls());<END MODIFIED CLONE>
mailer.setEnableStartTLS(values.ssl());
381
Message mymessage =382
new Message(values.body().length() > 0 ? values.body() : message);383
mymessage.setProject(project);----------------------------------------------

Code Clone
List

Code
Fragment< Categorizaon of Code Clones >Stable Clones䠖5578
Modiﬁed Clones:䠖1
Moved Clones䠖60
Added Clones䠖40
Deleted Clones䠖25(a) Project information(b) Clone set list
Fig. 4. Example of e-mail notification

V. Industrial Application
To confirm that Clone Notifier is able to inform changed
code clone information, Clone Notifier was applied to process of an web-application software development in NEC.
Developers in NEC think that checking code clones that arecomprised of small fragments is useless because they are
rarely meaningful code clones according their experiences.
Therefore, code clones consists of less than 30 tokens were
excluded in this application.
The target system consists of approximately 350 files and
12 KLOC written in Java. The duration of the application was
about 40 days, from December 2011 to January 2012.
A. Application Result
During 40 days application, Clone Notifier notified overall
152 changed clone sets, 20 deleted clone sets and 119 newclone sets. Also, every time, it notifies approximately 870
stable clone sets.
In particular, between 119 clone set of newly-appeared clone
set, the project manager recognized 10 clone set as clone setsshould be refactored. Each of two of the ten clone sets wasmerged into a single function during the 40 days. The othereight clone sets were designated as refactoring candidates thatwill be merged during next maintenance project.
B. Feedback from the Project Manager
We regularly interview with the project manager and got
several feedbacks on application of Clone Notifier. According
to feedback from the project manager, without Clone Notifier,he could not notice all of the changed code clones. Especially,
he satisfied with the result that ten clone sets were recognized
as candidates should be merged, and two of ten clone sets
were merged during 40 days.
Also, he request us to implement the feature to present
numerical criteria of selecting code clones, such as length ofa code clones, the number of code clones in a clone set for

next time. He suggested that numerical criteria help a user tounderstand the benefit of merging each of clone set.
VI. Manual Observation of Newly-Appeared Clone Sets
As an ex-post analysis, we investigated the characteristics
of clone sets recognized as refactoring candidate by the experienced project manager at NEC. The aim of the analysis isdata collection for the development of technique to recommend
refactoring candidate from all newly-appeared and changed
clones. The recommendation is promising to help developers
to reduce the cost of finding clone sets should be merged intoa single module.
We manually checked the diﬀerences between ten clone setsshould be merged and the other 109 clone sets. As a result,
we learned interesting insights about ten clone sets should bemerged.
A. Code Clones Introduced without Code Addition
As the first insight, in the case of clone sets that were newlyappeared by adding new code, the project manager frequently
recognized them as ones should be merged. On the other hand,clone sets were sometimes accidentally created by only the
replacement or the deletion of statements. In other words, even
if no line is added to a code fragment, it sometimes became acode clone in a clone set together with other code fragments
when one (or greater than one) character is changed in it. In
such case, the project manager mostly decided to leave those
duplicates as it is.
From our observation of the 119 clone sets, we found that
only coding idioms (e.g., programming or API/library specificidioms) are involved in clone sets that were newly-appeared byonly the replacement or the deletion of statements. Basically,such idioms are diﬃcult to merge or have an overall positiveeﬀect on maintenance and development [7] therefore theyshould be eliminated from refactoring candidates.
According to this observation, we eliminated clone sets thatwere newly-appeared by only the replacement or the deletion203(a) Clone set list page(b) Source file pageFig. 5. Example of web-based UIof statements from the 119 clone sets. The result shows thatthe elimination not only left the all of clone sets should be
refactored but also reduced 119 newly-appeared clone sets byapproximately 87%.
B. Syntactically Incomplete Clone Sets
As the second insight, code sets include whole parts ofloop or branch statements were considered as ones shouldbe merged. Meanwhile, the project manager rarely recognizedclone sets include only parts of loop or branch statements
as ones should be merged because it is diﬃcult to merge
syntactically incomplete clone sets.
According to this observation, we eliminated syntactically
incomplete clone sets from the 119 clone sets. The resultshows that the elimination not only left the all of clone setsshould be refactored but also reduced 119 newly-appearedclone sets by approximately 90%.

VII. Threats to Validity
Even though Clone Notifier successively applied to processof development in NEC and we found some characterizationof code clones that should be merged in this study, our study
have several limitations. At first, detected code clones in thisstudy rely on detection results from CCFinder. Secondly, we
have applied Clone Notifier into only the development process
of only one project
To overcome these limitations, we are planning to apply
Clone Notifier to other software systems during long period.
Moreover, we consider using outputs of other code clone
detection tools.
VIII. Related WorkA lot of studies have been done for investigating andsupporting clone evolution [11].

204Kim et al. studied genealogies of code clone [8]. They
defined a model of clone genealogy in order to study evolutionof code clones across multiple versions of source code. We
presented a clone change notification system with the featureof the categorization of clone evolution, which is based on theopinions of industrial developers in NEC, and then reported anindustrial application of the clone change notification system.
Also, other models of clone evolution have been proposed,and discussed [12], [13], [14], [15].
Duala-Ekoko et al. presented Clone Region Descriptors to
track code clones moved to other locations in source code [16],[17]. The tracking code clones in proposed system is basedon text diﬀerence and similarity. For more accurate tracking
code clones, we should integrate CloneTracker into proposedsystem.
Nguyen et al. have developed a clone management tool
JSync to notify developers change and its inconsistency ofcode clones in source files [18]. Also, Jiang et al. [19] and Li
et al. [20] have been proposed on the inconsistency detectionof code clones from a single version of source code. Proposedsystem is promising to support inconsistency detection of code
clones but unable to show inconsistency between code clones
explicitly. We should add the feature of inconsistency detection
by them to proposed system.
Our earlier workshop paper [21] introduced Clone Notifier
and early-stage of the industrial application. In this paper,
we present not only completed industrial application but also
manual observation of newly-appeared clone sets as an ex-post
analysis.
IX. Summary and Future work
In this paper, we present clone change notification system, Clone Notifier that notifies newly-appeared and changed
clones regularly to developers. We applied Clone Notifier
into the process of the web application software development
at NEC. The application result shows 119 newly-appearedclone sets, and ten out of them are recognized as refactoring
candidates.
In ex-post analysis, we also investigated the characteristics
of clone sets recognized as refactoring candidate by theexperienced project manager at NEC for data collection for thedevelopment of technique to recommend refactoring candidatefrom all newly-appeared and changed clones.
As future work, we plan to integrate the filtering techniqueswith the clone change notification system, and then conduct
longer-term case study at NEC. The further case studies ofother industrial projects are needed for the generalization of
the findings.
Acknowledgment
We express our great thanks to Ms. Fusako Mitsuhashi and
Mr. Shin’ichi Iwasaki at NEC Corporation for data collection.
This work is partially supported by JSPS, Grant-in-Aid for
Scientific Research (A) (21240002).

References[1] L. Jiang, G. Misherghi, Z. Su, and S. Glondu, “DECKARD: Scalable
and accurate tree-based detection of code clones,” in Proceedings of the
29th International Conference on Software Engineering (ICSE 2007),
2007, pp. 96–105.
[2] Z. Jiang and A. Hassan, “A framework for studying clones in large
software systems,” in Proceedings of the 7th IEEE International Working
Conference on Source Code Analysis and Manipulation (SCAM 2007),
2007, pp. 203–212.
[3] T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder: a multilinguistic
token-based code clone detection system for large scale source code,”IEEE Transactions on Software Engineering, vol. 28, no. 1, pp. 654–670,
2002.
[4] E. Choi, N. Yoshida, T. Ishio, K. Inoue, and T. Sano, “Extractingcode clones for refactoring using combinations of clone metrics,” inProceedings of the 5th International Workshop on Software Clones(IWSC 2011), 2011, pp. 7–13.
[5] M. Fowler, Refactoring: improving the design of existing code. Addison
Wesley, 1999.
[6] Y. Higo, S. Kusumoto, and K. Inoue, “A metric-based approach toidentifying refactoring opportunities for merging code clones in a java
software system,” Journal of Software Maintenance and Evolution:
Research and Practice, vol. 20, no. 6, pp. 435–461, 2008.
[7] C. J. Kapser and M. W. Godfrey, “”cloning considered harmful” considered harmful: patterns of cloning in software,” Empirical Software
Engineering, vol. 13, no. 6, pp. 645–692, 2008.
[8] M. Kim, V. Sazawal, D. Notkin, and G. C. Murphy, “An empirical
study of code clone genealogies,” in Proceedings of the 10th European
software engineering conference held jointly with 13th ACM SIGSOFT
international symposium on Foundations of software engineering (ESEC/FSE 2005), 2005, pp. 187–196.
[9] S. Bellon, R. Koschke, G. Antoniol, J. Krinke, and E. Merlo, “Comparison and evaluation of clone detection tools,” IEEE Transations on
Software Engineering, vol. 31, no. 10, pp. 804–818, 2007.
[10] S. Kawaguchi, M. Matsushita, and K. Inoue, “Clone history analysis using configuration management system,” IEICE Transactions (inJapanese), vol. J89-D, no. 10, pp. 2279–2287, 2006.
[11] J. R. Pate, R. Tairas, and N. A. Kraft, “Clone Evolution: A Systematic
Review,” Journal of Software Maintenance and Evolution: Research andPractice, vol. 25, no. 3, pp. 261–283, 2013.
[12] L. Aversano, L. Cerulo, and M. D. Penta, “How clones are maintained:
An empirical study,” in Proceedings of the 11th European Conference
on Software Maintenance and Reengineering (CSMR 2007), 2007, pp.
81 –90.
[13] T. Bakota, R. Ferenc, and T. Gyimothy, “Clone smells in software
evolution,” in Proceedings of the 23rd IEEE International Conference
on Software Maintenance (ICSM 2007), 2007, pp. 24–33.
[14] J. Krinke, “A study of consistent and inconsistent changes to code
clones,” in Proceedings of the 14th Working Conference on Reverse
Engineering (WCRE 2007), 2007, pp. 170 –178.
[15] J. Harder and N. Gode, “Modeling clone evolution,” in Proceedings ofthe 3rd International Workshop on Software Clones (IWSC 2009), 2009,
pp. 17–21.
[16] E. Duala-Ekoko and M. P. Robillard, “Tracking code clones in evolving
software,” in Proceedings of the 29th International Conference on
Software Engineering (ICSE 2007), 2007, pp. 158–167.
[17] ——, “Clone Region Descriptors: Representing and Tracking Duplication in Source Code,” ACM Transactions on Software Engineering andMethodology, vol. 20, no. 1, pp. 3:1–3:31, 2010.
[18] H. A. Nguyen, T. T. Nguyen, N. H. Pham, J. Al-Kofahi, and T. N.
Nguyen, “Clone management for evolving software,” IEEE Transactions
on Software Engineering, vol. 38, no. 5, pp. 1008–1026, 2012.
[19] L. Jiang, Z. Su, and E. Chiu, “Context-based detection of clone-relatedbugs,” in Proceedings of the 6th joint meeting of the European Software
Engineering Conference and the ACM SIGSOFT Symposium on theFoundations of Software Engineering (ESEC/FSE 2007), 2007, pp. 55–
64.
[20] Z. Li, S. Lu, S. Myagmar, and Y. Zhou, “CP-Miner: Finding copy-paste
and related bugs in large-scale software code,” IEEE Transactions on
Software Engineering, vol. 32, no. 3, pp. 176–192, 2006.
[21] Y. Yamanaka, E. Choi, N. Yoshida, K. Inoue, and T. Sano, “Industrial
application of clone change management system,” in Proceedings of the205

6th International Workshop on Software Clones (IWSC 2012), 2012, pp.
67–71.

206