Vol.2014-SE-186 No.1
2014/11/13
情報処理学会研究報告
IPSJ SIG Technical Report

コードクローン編集者数に着目した開発履歴の分析
辻 健二1,a)崔 恩瀞1

吉田 則裕2

春名 修介1

井上 克郎1

概要：コードクローンとは，互いに一致もしくは類似したコード片のことである．一般的に，あるコードクローンが編集されると，同じクローンセット（コードクローンの関係となっている全てのコード片の集合）に属されている他のコードクローンも同様に編集される必要がある．しかし，異なる開発者がクロー
ンセット内の各コードクローンの編集を担当している場合は，コードクローンに対する一貫した編集が困難である．この問題を防ぐために，開発者間でのコードクローンの編集情報の共有を支援ツールが開発されている．しかし，このツールは複数人でコードクローンを編集する体制を前提としたものであり，実際のソフトウェア開発現場でのコードクローン編集管理が複数人によって行われているとは限らない．従って，コードクローンを編集している開発者の人数について調査する必要がある．本研究ではある成果物に対して最も編集を行っている開発者がどの程度編集を行っているかを示す Ownership メトリックを用いてオープンソース開発履歴に対してクローンセット毎の編集者の傾向を分析した．
キーワード：コードクローン，ソフトウェア保守，Ownership メトリック

A Version History Analysis Focused on
the Number of Developers Editing Code Clones
Abstract: A code clone is a code fragment that is identical or similar to other code fragments in sourcecode. Generally, when a code clone is changed, all the code clones in the same clone set (i.e. a set of code
clones that are identical or similar to each other) should be changed consistently. However, if clone codes inthe same clone set are changed by multiple developers, it is diﬃcult to change these code clones consistently.
To facilitate this problem, previous study developed a tool that notifies the change information of code clones
to the developers. The basic premise of this tool is that code clones are changed by multiple developers,
however, little is known about number of developers who changes the code clones in practice. In this study,
we analyzed the tendency of developers who changed each clone set using Ownership (i.e. a metric that
represents ratio of developers editing each component).
Keywords: Code Clone, Software Maintenance, Ownership Metric

1. まえがき

クローンセットである．
コードクローンとなっているコード片が編集された場

ソフトウェアの保守工程における大きな問題の一つとし合，同じクローンセットに属している他のコードクローンて，コードクローンが指摘されている．コードクローンとに対して一貫した編集が行われる必要がある．しかし，開は，ソースコード中に存在する互いに一致または類似した

発者が編集対象のコード片がコードクローンであることに部分を持つコード片のことである．コードクローンは，主気付かず，そのコード片のみに修正する可能性は非常に高に既存コードのコピーペーストによって生成される [1]．まい [2], [3]．この問題を防ぐためには，システムに関わる全

た，互いにコードクローンとなっているコード片の集合はての開発者の間で，コードクローンの編集情報が共有され

1

2

a)

大阪大学
Osaka University
名古屋大学
Nagoya University
k-tsuji@ist.osaka-u.ac.jp

c 2014 Information Processing Society of Japan⃝

る必要がある．
山中らは開発者間でのコードクローンの編集情報の共有を支援するため，Clone Notifier を開発した [4]．Clone

Notifier は，対象システム内にコードクローンが編集され

1Vol.2014-SE-186 No.1
2014/11/13
情報処理学会研究報告
IPSJ SIG Technical Report

た際，登録している開発者全員に対してクローン編集の通に置き換えることによって，ユーザ定義名や予約語が異な知を行うツールである．Clone Notifier はコードクローン

るコード片でもコードクローンとして検出することができが複数の開発者によって編集されている開発体制では有用

る．CCFinder は検出精度が高いことで知られており，さである．しかし，コードクローンが単独または複数の開発

まざまな研究や会社で利用されている．しかし，大規模の者によって編集されているかに関しての十分な調査は行わ

ソースコードが入力された場合，コードクローンを検出すれていない．Clone Notifier の有用性を検証するためには，るために，膨大な時間がかかるという短所を持っている．

コードクローンを編集する開発者の人数に関する詳細な調査が必要である．

この問題を解決するために，Choi らは CCFinder の前処理や後処理を行うことでコードクローンの検出時間を減

Harder はコードクローンの編集を行う開発者が単独か複らす手法を提案した [13]．彼らの手法は，各入力ファイル

数かを調査し，コードクローンが主に同一の開発者によっの MD5 ハッシュ値 [14] を計算し，そのハッシュ値が一致て編集を行われることが分かった [5]．しかし，この研究はしたファイルの集合を完全一致ファイルセットとして検編集割合の最も多い開発者の情報のみ焦点を当てた上に，出する．また，特殊なハッシュ値のファイルや，各完全一最も多い開発者のコードクローンの編集割合についても考致ファイルセットから選ばれた 1 つのファイル (代表ファ慮できていないという問題点がある．

イル) を CCFinder の入力とし，コードクローンの検出を

これらの問題点を解決するために，本研究は，コードク行っている．その後，代表ファイルからクローンが検出さローンに対する編集者の数を，Ownership[6] というメトれた場合，そのファイルのクローン情報に基づいて，マッリックを用いて調査している．Ownership とは，あるコン

ピングを行い同じ完全一致ファイルセットに属するファイポーネントに対して行われた全ての編集のうち，最も多くルクローンの位置を特定している．

編集した開発者が行った編集の割合を示すメトリックであ

本手法では Choi らの手法を拡張し，ファイル単位でのり，そのコンポーネントを担当する強さの度合いを示すもコードクローンを検出した．つまり，各入力ファイルを一のとなっている．本研究で Ownership メトリックを用いる

つのトークン列に連結した．その際，変数名や識別子名なことで，コードクローンの編集を担当している開発者が単

どのユーザ定義名は特殊文字に置き換えている．その後は，

独か複数かを判断できるだけでなく，その編集割合につい

Choi らの手法と同様，各変換された入力ファイルの MD5ても理解することが期待されている．Ownership メトリッ

ハッシュ値を計算を行い，各ファイルのハッシュ値に基づクを用いて，オープンソースソフトウェアである WildFly

きファイルクローンを検出した．

を対象に各クローンセット内のコードクローンの編集回数や最も多く編集を行った開発者の編集割合を計測した結果，半数以上のクローンファイルが，複数人によって編集されていることが分かった．

2. 背景
2.1 コードクローンの検出

2.2 コードクローンの編集管理
コードクローンが編集された際，そのコードクローンの編集に関わる全ての開発者がその編集内容について把握することで修正漏れやバグの混入などを防ぐことができると考えられる．そのため，コードクローン編集の情報を開発者間で共有することで開発を支援するツール Clone

ソースコード中からコードクローンを検出するために，

Notifier[4] が開発されている．Clone Notifier は，バージョ

さまざまな類似度に基づく手法が提案されている [7], [8]．

ン間でコードクローンの差分情報を検出し，その情報をBaker は，コードクローン検出する手法を提案し，Dup

ツールに登録している開発者に対してメールを送ることでを開発した [9]．Dup はトークンの類似度に基づいて，通知するツールである．Clone Notifier が行った企業でのユーザ定義名や予約語を除く一致箇所のコードクローン

ソフトウェア開発への適用実験の結果，開発者たちが意図を検出する．Jiang らは抽象構文木の類似度に基づいてしていなかったコードクローン編集を検出し，それを通知

コードクローンを検出する DECKARD を開発した [10]．

することができた．しかし，Clone Notifier は複数人でコー

DECKARD は，入力されたソースコードを抽象構文木に

ドクローンを編集する開発体制を前提としたものであり，

変換し，その後の各部分木を特徴ベクトルに変換する．ま実際のソフトウェア開発現場でのコードクローン編集が複た，LSH(Locality-Sensitive Hashing) アルゴリズム [11] を数人によって行われているとは限らない．従って，コード用いて，特徴ベクトル間の類似度を求めることによって，クローンを編集している開発者の人数の調査が必要である．

コードクローンの検出を行うことができる．Kamiya らは
ソースコードのトークン列の類似度に基づいてコードク

2.3 コードクローン編集者の分析

ローンを検出する CCFinder を開発した [12]．CCFinder

コードクローンの編集者とは，コードクローンを生成，は，入力されたソースコードをトークン列に変換する．そもしくは編集した開発者のことを指す．Harder はコードのとき，変数名や識別子名などのユーザ定義名を特殊文字

クローン編集者を分析し，同じクローンセット内のコード

c 2014 Information Processing Society of Japan⃝2

Vol.2014-SE-186 No.1
2014/11/13
情報処理学会研究報告
IPSJ SIG Technical Report

図 1 調査手順の概要

Fig. 1 Overview of analysis process

クローンの編集を行った開発者が単独かまたは複数かを調するため，コードクローンの編集を行う開発者が主に単独査した [5]．彼の研究では，トークン単位で編集を担当してか複数かをその担当割合にもとづいて調査する．図 1 はいる開発者の特定を行い，その情報を用いてコードクロー

本研究の調査実験の手順の概要を示している．この図でンの編集者を決定している．

表しているように，まず最初に開発履歴を記録している

この研究の結果，対象とした全てのソフトウェアにおいソースコードリポジトリの，ある時点でのソースコードて，単独で編集されているクローンセットの数が複数人のを対象にファイルクローンセットの検出を行う．また，リ

ものよりも多いことが明らかになった．しかし，この研究

ポジトリのコミットログから，ファイル編集履歴の分析

では，編集割合の最も多い編集者の情報のみに焦点を置いを行い，全てのファイルの編集者と編集回数を分析する．

ている．また，編集者のみに着目しているので，クローン

最後に，Ownership メトリックをファイルクローンセット

セットに対して行われた編集の割合については考慮されてに適用した CS-Ownership を，ファイルクローンセット

いない．

とファイルの編集者，編集回数の情報を用いて計測する．

本研究では，これらの問題点を考慮し，コードクローン

CS-Ownership については，3.3 節にて後述する．調査実に対する編集者の数を，Ownership メトリックを用いて調験の対象となるシステムは，バージョン管理システムで査している．このメトリックは，あるコンポーネントに対ある Subversion または Git を用いて開発履歴が管理され，して，開発者が明確に責任を持っているかどうかを表すもJava 言語で記述されているオープンソースソフトウェアプのである．Ownership メトリックを用いることで，コードロジェクトである．

クローンの編集を担当している開発者が単独か複数かを判断できるだけでなく，その編集割合についても理解するこ

本節では，本研究で行う各調査手順について具体的に説明している．

とができる．また，コード片単位でコードクローンを扱うと記述言語にイディオムを多く含むことがあり，検出され3.1 手順 1 クローンセット検出

るコードクローンはコピーペーストによって生成された以対象システムの Subversion リポジトリから，コードク

外のものも含まれてします．一方でファイル単位のコード

ローンとなっているクローンファイルを検出する．本研究

クローンは，コピーによって作成されている可能性が高いで扱うコードクローンは，変数名や関数名などのユーザ定と考えられる．このため，本研究ではファイルクローンに義名を除いて一致するコードクローンである．検出したク着目して調査を行っている．

ローンファイルのクローンセットをクローンファイルセッ

3. 調査手順
本研究では，複数開発者による管理支援の必要性を検証

c 2014 Information Processing Society of Japan⃝

トと定義する．各クローンファイルセットには，少なくとも 2 つ以上のファイルが含まれている．ファイル名が同じでも，パス名が異なるクローンファイルについては，両者

3Vol.2014-SE-186 No.1
2014/11/13
情報処理学会研究報告
IPSJ SIG Technical Reportは別のファイルであるものとして扱っている．
図 1 の中央上段は，クローンセットの検出によって得ら• 複数人での編集であった場合，Ownership メトリック

値はその分担の度合いを反映することが可能である．

れたファイルクローンリストを示した図である．ファイル

例えば，Ownership メトリックの値が 0.25 であった

A とファイル B は Clone set1 に属しているコードクロー

場合，複数の開発者が編集に関わっていること以外にンである．Clone set2 は，ファイル C，ファイル D，ファも，そのコンポーネントに対して，全ての開発者の編

イル E の 3 つのファイルがコードクローンとなっているク

集回数が 1/4 以下であることが把握できる．

ローンセットである．

一般的に，あるコンポーネントの Ownership メトリックの値は，コンポーネントの総コミット数を Ctotal ，そのコ

3.2 手順 2 ファイル編集履歴の分析
対象システムの開発履歴を元にコミットログを分析し，ンポーネントの最多コミットを行った開発者のコミット数
を Cmax とすると，以下の式で算出することができる．

各ファイル毎の編集者とその編集回数を取得する．コミッ

Ownership =トログの各リビジョンには編集を受けたファイルが記録

Cmax
Ctotal

されており，そのリビジョンをコミットした開発者をそのOwnership メ ト リ ッ ク の と り 得 る 値 は ，0

ファイルの編集者とする．また，あるファイルのコミット

Ownership ≤ 1 となる．Ownership メトリックの値が回数を，そのファイルの編集回数としている．図 1 の中央<

1 に近いほど，1 人の開発者がそのコンポーネントに対して下段は，分析後の出力であるファイル編集者と回数のリ

大きな責任を持ち，0 に近いほど複数の開発者が均等に編ストである．ファイル A に対して，開発者 Alice が 1 回，集する機会を持つことを表している．Ownership メトリッ

Bob が 3 回の編集を加えており，ファイル B については

クが 1 のとき，1 人の開発者が完全にそのコンポーネント

Bob が 1 回のみ編集を行っていることを表している．

を管理していることを示している．

本実験では，コードクローンの生成する過程ではなく本研究では，ファイルクローンセットを対象とした Own-

コードクローンに対する編集の回数を取得するのが目的で

ership メトリックとして，CS-Ownership を定義する．

あるため，コードクローンを検出したバージョン以降のリファイルクローンセットに含まれる全てのファイルについビジョンを対象にファイル編集履歴の分析を行う．そのたて，そのコミット数の総計を CStotal ，全コミットのうち

め，1 度も編集が検出されないファイルが含まれる可能性

最多の開発者コミット数を CSmax とすると，ファイルク

もある．

ローンセットの CS-Ownership は以下の式によって算出

本研究での開発履歴の分析は，Subversion のコミットロ

できる．

グを用いて行っている．そのため，Git で開発履歴の管理

CS-Ownership =を行っているシステムに関しては，Subversion のリポジト
リに変換した後に分析を行っている．

CSmax
CStotal

図 1 右 側 の 表 は ，各 ク ロ ー ン セ ッ ト と ，そ の

CS-Ownership 計測結果の例を表している．クローンセッ
3.3 手順 3 CS-Ownership の計測

ト 1 に含まれる全てのファイル (ファイル A，ファイル B)

手順 1 と 2 で得られたデータを元に，各クローンセット

に対する編集回数を合計すると，Alice が計 4 回，Bob がに対する Ownership メトリックの計測を行う．手順 1 で

計 3 回となる．この場合，最も多い編集回数は 4 回なので，検出したクローンセット内の全てのクローンファイルの編

クローンセット 1 の CS-Ownership は 4/(3 + 4) ≈ 0.57 と集者とその回数の総計を，手順 2 で求めたファイル編集履
歴を用いて計算する．このうち，最も編集回数の多い開発者についての Ownership メトリックを計算する．

なる．

4. 調査結果と考察

Ownership メトリックとは，あるコンポーネントに対し

本節では，本研究で行ったクローンセット編集者の調査て行われた全ての編集のうち，最も多く編集した開発者が結果を示し，それについての考察および妥当性への脅威に行った編集の割合を示すメトリックであり，開発者がそのついて述べる．

コンポーネントを担当する責任の強さの度合いを示すものとなっている [6]．単純に編集者の人数を数えるだけでは

4.1 調査対象システム

なく，Ownership メトリックを用いる利点として，以下のメリットが挙げられる．

本研究は，WildFly*1 を調査対象システムとして実験を行った．対象システムの概要を表 1 に示す．総リビジョン• Ownership メトリックの値を見て，関わっている開発数はバージョン管理システム内に記録されている全てのリ者が単独か複数かを直感的に判別可能である．値が 1

ビジョン数，調査リビジョン数は対象システム中の，ファであれば単独での編集，そうでなければ複数の開発者

イル編集者の分析を行ったリビジョンの数を示している．

が編集に関わっていることが容易に理解できる．

*1c 2014 Information Processing Society of Japan⃝

http://wildfly.org/

4Vol.2014-SE-186 No.1
2014/11/13
情報処理学会研究報告
IPSJ SIG Technical Report
表 1

セットは見つからなかった．

調査対象のシステム

Table 1 Characteristic of analyzed system

表 3，表 4 は，WildFly に存在したクローンセット内に対象システムWildFly

含まれるファイルと，その編集者 ID，編集回数を示してい

総リビジョン数

25256

る．表 3 では，編集者 brian.stansberry が最も多くファイ

バージョン

7.0.0

調査リビジョン数

ルの編集を行っているが，クローンセット内の 3 つのファ

23693

調査対象期間

3 年 10 ヶ月

イルのうち，1 つのファイルしか編集していない．また，

表 2

表 4 では，jason.t..greene が 11 回，david.m..lloyd が 8 回の編集を行っており，他の開発者は 1 回か 2 回のみの編集

調査結果の概要

Table 2 Investigation result

しかしていない．

ファイルクローンセット個数

14

クローンセット内ファイル数

最大 3 最小 2 平均 2.2

延べ編集回数

153

CS-Ownership の値が 0.50 より大きく 1 未満の場合，

平均 CS-Ownership

0.53

複数の開発者でコードクローンを編集しているが，強く4.3 結果の考察!"#$%&'(

責任を持っている開発者が存在する，といった開発体制'であると考えられる．このような開発体制の下では，中心&となる開発者がコードクローンの編集情報を把握できれ%ば良いため，他の開発者がコードクローンの編集情報を$共有する必要性が薄い．しかし，図 2 より，そのような#

CS-Ownership の値を取るファイルクローンが存在しない"ことから，上記の開発体制を取っていないことが理解でき!

る．CS-Ownership が 0.50 のクローンセットは 5 つ見られるが，いずれも 2 人の開発者による編集であった．2 人!"#$%&'()

図 2

CS-Ownership の分布

Fig. 2 Frequencies of CS-Ownershipの間で開発の連携が取れていればコードクローン編集の情報共有を支援する必要は無いが，連携が困難な場合はコー
ドクローン編集の情報共有を支援する必要がある．14 のク

これは，同じく表に記載している対象システムのバージョ

ローンセットのうち，6 つが 0.50 を下回る CS-Ownershipンがリリースされた段階でのソースコードからコードクであった．この状態は，複数人がコードクローンを編集しローン検出を行っているため，その段階以降にコミットさているが中心となる開発者がいないことを示している．互れたリビジョンの数を表す．調査対象期間は，ファイル編

いに連携してコードクローンの編集情報を共有することは集者の分析を行ったリビジョンがコミットされている期間困難であると考えられるため，コードクローン編集情報ののことを表している．今回対象としたシステムには，開発共有を支援するツールの必要性は高いと考えられる．

者の代わりに自動的にコミットされたリビジョンは存在しなかった．

表 3 は，CS-Ownership が 0.21 と最も低かったクロー
ンセットの詳細を示している．3 つのファイル全てを編集できている開発者はおらず，2 つのファイルを編集して4.2 CS-Ownership 計測結果

いる開発者も jason.t..greene だけである．最も編集回数のCS-Ownership の計測結果を表 2 に示す．延べ編集回数多い brian.stansberry も，1 つのファイルに対する編集しとは，全てのファイルクローンに対する編集回数の合計をか行っていない．よって，このファイルクローンセット

示している．本実験では，全てのクローンファイルに対しは，一貫した編集ができていないと言える．このようなて 1 回以上の編集が確認できた．

コードクローンの開発には，コードクローン編集情報を共

図 2 は，CS-Ownership によるクローンセットの度数分有する必要があると考えられる．表 4 は，CS-Ownership

布を示している．横軸は CS-Ownership の値，縦軸はそは 0.41 と低めの結果だが，ファイルクローンセット内のの値を取るクローンセットの数を示している．横軸の下に

全 2 ファイルを編集している開発者が，最も多く編集をついている数値は CS-Ownership が 1 であるファイルク行っている jason.t..greene を含めて 3 人存在している．まローンセットはいくつか存在するが，1 ではないファイル

た，その 3 人ともが 2 ファイルをほぼ均等に編集している．

クローンセットの方が多数を占めていることがわかる．つCS-Ownership の値は低いが現状では，コードクローンにまり，多数のファイルクローンが，複数の開発者によって対する一貫した編集は行われていると言える．しかし，分編集されていることを示している．また，0.50 より大きく担して編集を行っているため，将来的に人員異動などの要

1 より小さな値の CS-Ownership を持つファイルクローン

因で編集者が変更された際に連携が取れなくなる恐れがあc 2014 Information Processing Society of Japan⃝5

Vol.2014-SE-186 No.1
2014/11/13
情報処理学会研究報告
IPSJ SIG Technical Report
表 3

ファイルクローンセットの詳細データ（CS-Ownership = 0.21）

Table 3 Detailed data on file clones set（CS-Ownership = 0.21）
ファイル名

編集者 ID

編集回数/server/src/main/java/org/jboss/as/server/

heiko.braun

1markus.gaisbauer

2

frank.langelage

4matus.abaﬀy2

martin.kouba

2

scott.marlow

2jaikiran2

jason.t..greene

6

SystemExiter.java/server-manager/src/main/java/org/jboss/

kabir.khan

2brian.stansberry

10

radoslav.husar

4stuart.douglas

8emanuel.muckenhuber

1

kabir

1

jason.t..greene1

as/server/manager/SystemExiter.java/testsuite/protocol/modules/src/main/java/org/jboss/test/
as/protocol/support/server/manager/SystemExiter.java
表 4

ファイルクローンセットの詳細データ（CS-Ownership = 0.41）

Table 4 Detailed data on file clones set（CS-Ownership = 0.41）
ファイル名

編集者 ID

編集回数/jmx/src/main/java/org/jboss/as/jmx/tcl/

heiko.braun

1

kabir

1

jaikiran

1

jason.t..greene

5/sar/src/main/java/org/jboss/as/heiko.braun

1service/SecurityActions.java

david.m..lloyd

8

jaikiran2

jason.t..greene

6

brian.stansberry

2

SecurityActions.java

るので，クローン編集情報の共有支援ツールを検討する必要はある．

4.4 妥当性への脅威る必要がある．

5. まとめと今後の課題
本研究では，複数の開発者に対するコードクローン管理

本実験では，バージョン管理システムである Subversion

支援の必要性を検証するため，オープンソース開発履歴

もしくは Git を用いて開発履歴の管理を行っているオープに対してクローンセット毎の編集者数を，Ownership メト

ンソースシステムに対してログの分析を行っている．バーリックに基づいたメトリック CS-Ownership を定義する

ジョン管理システムの機能として，ファイルの移動やリことでクローンファイル単位で分析し，クローンセット

ネームなどによるパス名の変更も開発履歴として記録できの編集を行う編集者数を調査した．そして，同じクローン

るが，本研究の調査手順ではファイルの移動やリネームに

セット内のクローンファイルの編集を行う開発者が単独でよるパス名の変更には対応できていない．今後は，パス名

あることよりも，複数であることの方が多いという結果をの変更があった際もそのファイルを同じものと扱うことが得ることができた．また，CS-Ownership の値から，複数必要であるがバージョン管理システムを用いずにそのようの開発者によるコードクローン編集情報の共有を支援するな操作が行われていた場合は，以降のリビジョンで同じもシステムの必要性があることを確認した．

のとみなすことができなくなる．
また，オープンソースシステムである WildFly のコー
ドクローンに対して調査を行ったが，今後，他のオープン
ソースシステムに対しても調査を行い，その結果を比較す

c 2014 Information Processing Society of Japan⃝

今後の課題として，以下が挙げられる．

• 本研究では 1 つのシステムに対して調査を行ったが，他のシステムについても同様の調査を行い，今回の結果と比較することが必要であると考えられる．

6

Vol.2014-SE-186 No.1
2014/11/13
情報処理学会研究報告
IPSJ SIG Technical Report• ファイル単位でのコードクローンに着目していたが，機能別に編集管理を行っている場合もある．そのため，関数単位での Ownership メトリックを計測することも課題であると考えられる．
謝辞 本研究は，JSPS 科研費 25220003，26730036 の助成を受けたものである．
参考文献
[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

肥後芳樹，楠本真二，井上克郎：コードクローン検出とその関連技術，電子情報通信学会論文誌，Vol. J91-D, No. 6,
pp. 1465–1481 (2008).
Jiang, L., Su, Z. and Chiu, E.: Context-based Detection of Clone-related Bugs, Proc. of ESEC-FSE ’07, pp.
55–64 (2007).
Li, Z., Lu, S., Myagmar, S. and Zhou, Y.: CP-Miner:
finding copy-paste and related bugs in large-scale software code, Software Engineering, IEEE Transactions
on, Vol. 32, No. 3, pp. 176–192 (2006).
Yamanaka, Y., Choi, E., Yoshida, N., Inoue, K. andSano, T.: Applying clone change notification system into
an industrial development process, Proc. of ICPC ’13,
pp. 199–206 (2013).
Harder, J.: How Multiple Developers Aﬀect the Evolution of Code Clones, Proc. of ICSM ’13, pp. 30–39(2013).
Bird, C., Nagappan, N., Murphy, B., Gall, H. and Devanbu, P.: Don’T Touch My Code!: Examining theEﬀects of Ownership on Software Quality, Proc. of
ESEC/FSE ’11, pp. 4–14 (2011).
Roy, C. K. and Cordy, J. R.: A survey on software clone
detection research, School of Computing TR 2007-541,
Queen s University， Vol. 541 (2007).
Rattan, D., Bhatia, R. and Singh, M.: Software clone
detection: A systematic review, Inform. Softw. Tech.,Vol. 55, No. 7, pp. 1165 – 1199 (2013).
Baker, B. S.: On Finding Duplication and NearDuplication in Large Software Systems, Proc. of WCRE
’95, pp. 86–95 (1995).
Jiang, L., Misherghi, G., Su, Z. and Glondu, S.:
DECKARD: Scalable and accurate tree-based detectionof code clones, Proc. of ICSE ’07, pp. 96–105 (2007).
Indyk, P. and Motwani, R.: Approximate nearest neighbors: towards removing the curse of dimensionality,
Proc. of STOC ’98, pp. 604–613 (1998).
Kamiya, T., Kusumoto, S. and Inoue, K.: CCFinder: A
multilinguistic token-based code clone detection system
for large scale source code, IEEE Trans. Softw. Eng.,
Vol. 28, No. 7, pp. 654–670 (2002).
Choi, E., Yoshida, N., Higo, Y. and Inoue, K.: A
Clone Detection Approach for a Collection of Similar
Large-scale Software Products, IEICE Technical Report,
Vol. 112, No. 275, pp. 117–121 (2012).
Rivest, R. L.: The MD5 Message Digest Algorithm, Internet RFC 1321 (1992).

c 2014 Information Processing Society of Japan⃝

7