社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

大規模ソフトウェア群に対するメソッド単位のコードクローン検出石原知也†

堀田 圭佑†

肥後 芳樹†

井垣宏†

楠本真二†

† 大阪大学大学院情報科学研究科
あらましソフトウェアシステムには，他のソフトウェアにまたがるコードクローンが多数存在することが予測される．このようなコードクローンを検出することは，ライセンスに違反しているソースコードを発見できる，また複数のソフトウェア間に共通する処理をライブラリとしてまとめる等の観点から有益である．しかし既存研究では，ファイルの一部がコードクローンであるものは検出できない．本研究では大規模ソフトウェア群から，メソッド単位のコードクローンを高速に検出するツールを開発し，実験を行った．
キーワード

コードクローン，メソッドクローン，ソースコード流用，ソフトウェア保守

Method-based Code Clone Detection for a Large Number of Software
Systems
Tomoya ISHIHARA† , Keisuke HOTTA† , Yoshiki HIGO† , Hiroshi IGAKI† , and Shinji
KUSUMOTO†† Graduate School of Information Science and Technology, Osaka University
Abstract It is predicted that there are many code clones across software systems. Detecting such code clones
is useful from the viewpoint that we can discover source code licensing violations or merge common functions intolibraries. However, existing research cannot detect code clones which are a part of a source file. In this research, wedeveloped a tool that quickly detects method-based code clones and experimented on a huge set of software systems.
Key words Code Clone, Method Clone, Source Code Plagiarism, Software Maintenance

1. は じ め にとができる反面，ファイルの一部がコードクローンであるものは検出できないという問題点を抱えている．例えば，ファイル再利用などの理由により，複数のソフトウェアにまたがるのある一部分のみが流用されている場合，ファイル単位のコーコードクローンが多数存在することが予測される [1] [2]．コー

ドクローン検出手法では流用部分をコードクローンとして検出

ドクローンとは，ソースコード中に存在する同一，あるいは類することができない．

似したコード片のことである．このような複数のソフトウェア

本研究では，ファイル単位より小さい粒度であるメソッド単にまたがるコードクローンを検出することは，ライセンスに違位でのコードクローン検出手法を提案する．メソッド単位での反して流用されているソースコードの特定や，複数のソフトコードクローン検出手法では，大規模なソフトウェア群に対しウェア間に頻出する処理のライブラリ化による開発効率の向上て実用的な時間で検出を行うことができると同時に，ファイルなどの観点から有益である．しかし，既存のコードクローン検単位のコードクローン検出手法では検出できない，ファイルの出手法 [3] [4] は 1 つのソフトウェア内のコードクローンを見つ一部がコードクローンであるものを検出することが可能である．

けることを目的としているため，ソースコードを文や字句な実験の結果，約 3 億 6 千万行のソースコードから約 4.91 時間

どの細粒度で比較している．そのため，大規模なソフトウェアでコードクローンを検出することができた．また，検出された群を対象としたコードクローン検出には膨大な時間的・空間的コードクローンを分析した結果，ソースコードの流用を特定すコストを必要とする．この問題を改善し，大規模なソフトウェることや複数のソフトウェア間に共通する処理をライブラリ化

ア群から実用的なコストでコードクローンを検出する手法とすることに有用であるコードクローンの存在を確認することがして，ファイル単位のコードクローン検出手法が提案されていできた．

る [5] [6]．ファイル単位のコードクローン検出手法は，大規模なソフトウェア群に対して高速にコードクローン検出を行うこ—1—

78 public class TreeBidiMap implements
OrderedBidiMap, Serializable {40 final class PortletRequestScopeMap implements
Map {

(中略)

(中略)

219 public void putAll(Map t){
220 Iterator it = t.entrySet().iterator();
221 while(it.hasNext()){
222
Map.Entry entry = (Map.Entry)it.next();
223
put(entry.getKey(),entry.getValue());
224 }
225 }

132 public void putAll(Map t){
133 Iterator entries = t.entrySet().iterator();
134 while(entries.hasNext()){
135
Map.Entry entry = (Map.Entry)entries.next();
136
put(entry.getKey(),entry.getValue());
137 }
138 }

(a) apache.commons.collections

TreeBidiMapクラス(b) apache.commons.chain

ServletApplicationScopeMapクラス

図 1 Motivating Example

2. 準備

2. 1 ソフトウェア間にまたがるコードクローン
本研究では特にソフトウェア間にまたがるコードクローンに着目する．ソフトウェア間にまたがるコードクローンを検出する利点として，以下の点が挙げられる [5] [6]．
他のソフトウェアから流用したソースコードの特定て検出することができない．
以降，ファイル単位のコードクローンをファイルクローン，メソッド単位のコードクローンのことをメソッドクローンと呼ぶ．

3. 研 究 動 機
3. 1 既 存 研 究
佐々木らは，ファイルクローン検出ツール FCFinder を開発

ソフトウェア間にまたがるコードクローンの生成要因の 1 つし，ファイルクローンがどのような性質を持っているかを調査として，他のソフトウェアからソースコードを流用する場合がした [5]．FCFinder はファイルをハッシュ値に変換することで考えられる．流用されたソースコードの中には，ライセンスにファイルクローン検出を行っている．また，FCFinder はコメ違反して流用されたソースコードが含まれている可能性がある．

ント文の削除や字句解析を行っているため，コメント文やイソフトウェア間にまたがるコードクローンを検出することで，ンデントの違いを吸収することが可能である．佐々木らは，大ライセンスに違反して流用されているソースコードの特定を支規模なソフトウェア群である FreeBSD Ports Collection に対援することができる．

し FCFinder を適用した結果，FreeBSD Ports Collection の約複数のソフトウェアに存在する共通処理のライブラリ化68%がファイルクローンであったことを報告している．また，複数のソフトウェアにまたがってコードクローンとして検出検出されたファイルクローンのうち 27%はコメントやインデンされたコード片が行う処理は，複数のソフトウェアで共有されトの違いであり，ファイルサイズの分布はファイルクローンとている共通の処理である．複数のソフトウェアに頻出する共通そうでないファイルで違いが見られなかったとも報告している．の処理は，今後のソフトウェア開発でも使用される可能性が高Ossher らは，ファイルクローン検出手法を提案し，ファイいと考えられる．このような複数のソフトウェアに頻出する共ルクローンが発生する状況を調査している [6]．Ossher らの手通の処理をライブラリ化することで，開発者が新たに処理を記

法は，exact，FQN，fingerprint の 3 つの要素を組み合わせて述する必要がなくなり，開発効率の向上が期待できる．

ファイルクローン検出を行う．exact では，各ソースファイル

2. 2 ファイル単位のコードクローンを 1 つの文字列とみなし，その文字列をハッシュ値に変換して行や字句単位などの既存のコードクローン検出手法は，主に一致するかどうかを調査する．FQN では，クラスの完全限定単一のソフトウェアを検出対象としている．そのため，このよ名が等しいかを調査する．fingerprint では，ソースコード中うな既存の手法は高精度でコードクローンを検出すべくソースのフィールド名とメソッド名がどの程度等しいかを調査する．

コードを細粒度で比較している．しかし大規模なソフトウェア

Ossher らは，約 1 万 3 千の Java ソフトウェアに対し Ossher

群を対象に検出を行う場合，細粒度のコードクローン検出手法らの手法を適用し，上記 3 つの手法の結果を結合させたとこ

では比較回数が多くなり，その検出処理に膨大な時間的・空間ろ，全ファイルの約 10%超がコードクローンとして検出された的コストを必要とする．このため，大規模なソフトウェア群かと報告している．また，ファイルクローンが発生する状況としら実用的な時間でコードクローンを検出することは困難である．て，同じライブラリを使用していることや新たなソフトウェア

この問題を解決するために，ファイル単位のコードクローン開発を始めるために以前のソフトウェアを再利用することなど検出手法が提案されている [5] [6]．ファイル単位のコードクローが挙げられるとも報告している．

ン検出手法では，ファイルを単位として比較を行い，一致する

3. 2 Motivating Example

場合のみコードクローンとみなす．この手法は，行単位や字句

図 1 は，ソフトウェア間にまたがるコードクローンの例であ単位のような細粒度の検出手法と比べ，ソースコードの比較回る．2 つのクラスはそれぞれ別のソフトウェアに存在するが，い数が小さくなるため，高速な検出が可能である．しかし，ファずれもインタフェース Map を継承している．そのため，putAll

イルの一部がコードクローンであるものはコードクローンとしメソッドを実装した親クラスを作成することでライブラリ化す

—2—

•
xml
Java
html
Java

STEP1
解析対象の特定STEP2
メソッドの切り出し

xml
Java
html
Java

methodA

STEP3
正規化

変数名，文字列リテラル，メソッド・クラス・インターフェース宣言部のメソッド名は 1 つの特殊な文字列に置換する$A•

methodB$B

methodC$C

methodD$D

空白，改行，修飾子，アノテーション，コメント文，インポート文，パッケージ文は削除する

STEP4：フィルタリング
STEP4
フィルタリング$A

STEP5
ハッシュ値の計算$B$D

methodhashmethodA 010101
methodB 001100
methodD 010101

STEP6
ハッシュ値によるグループ化

methodhashmethodA 010101
methodD 010101
methodB 001100

ゲッタメソッドやセッタメソッドのように，処理が単純でありかつ短いメソッドは多くのソースファイルに存在すると考えられる．そのため，このようなメソッドは大量にコードクローンとして検出されるおそれがある．このようなコードクローンは，流用の特定や複数のソフトウェアに存在する共通処理のラ

図2

提案手法の概要

イブラリ化に対して有用ではない．したがって，処理の単純かつ短いメソッドは検出が不要である．このステップでは，このよることができる．この例では，ファイルの一部分の処理のみが，多数のソフトウェア間で共有されているライブラリ化可能な処理に該当する．しかしながら，ファイルクローン検出手法ではこのようなコード片をコードクローンとして検出できない．本
研究では，この課題点を解決するためにより細かい粒度であるメソッド単位のコードクローン検出手法を提案する．

3. 3 Research Question
本研究ではメソッドクローンに関する以下の問題を調査する．

RQ1：ファイル単位で検出できなかったコードクローンがメソッド単位で検出を行うことで新たにどの程度検出できるか

RQ2：メソッド単位で検出を行うことで新たに検出されたコー
ドクローンの発生原因にはどのようなものがあるか

RQ3：メソッド単位で検出を行うことで新たに検出されたコー
ドクローンは流用の特定などに有用であるか

4. 調 査 方 法
この章では，大規模なソフトウェア群からメソッドクローンを検出する調査方法について述べる．今回の調査では，ファイルクローンとの比較を行うため，メソッドクローンとファイルクローンの両者を検出する．

4. 1 概要対象とするデータセットからその中に存在するメソッドクうなメソッドを検出の対象から除外する．今回の調査では，メソッド内の複文の数が 0 であるメソッドについては検出の対象から除外する．ここで複文とは複数の文から成り立つブロックを指し，do，for，if，switch，try，while 文を複文と定義する．

STEP5：ハッシュ値の計算
解析対象となるメソッドそれぞれに対して，ハッシュ値を算出する．今回の調査では，MD5 [7] によりハッシュ値を計算する．等しい記述を持つメソッドはハッシュ値が等しくなるため，ハッシュ値が等しいメソッドはコードクローンと考えられる．算出されたハッシュ値は，メソッドごとデータベースに格納する．

STEP6：ハッシュ値によるグループ化
ハッシュ値の等しいメソッドをグループ化する．それらのメソッドグループのうち，要素数が 2 以上のグループがメソッドクローンとして検出される．

5. 実

験

5. 1 実 験 対 象
本研究では，実験対象として”UCI source code data sets” [6][8](以降，UCIdatasets と呼ぶ) を用いた．しかし，UCIdatasetsには trunk,tags,branches を同時に含むソフトウェアやバージョンが違う同一ソフトウェアが複数含まれている．ソフトウェア
は処理の追加，修正，削除を行い，新しいバージョンに進化しローンとファイルクローンを検出する．図 2 に検出処理の概要ていく．しかし，処理の修正などが行われないソースコードを示す．以降，図 2 に示す各処理について詳細に述べる．

は，バージョンが新しくなってもその内容が変更されないた

STEP1：解析対象の特定入力として与えられたデータセットから，解析対象となるソースファイルを特定する．今回の調査では，Java を用いて記述されたソフトウェアのみを解析対象としているため，入力として与えられたデータセットから拡張子が.java であるファイルを特定する．

め，コードクローンとして検出される．したがって，このようなソフトウェアに対してコードクローン検出を行うと，検出されるコードクローンが不必要に多くなるおそれがある．そこで
本研究では，trunk,tags,branches を同時に含むソフトウェア
は trunk 以下のファイルのみを，バージョンの違う同一ソフトウェアは最新バージョンのみを検出対象とした．また，いくつ

STEP2：メソッドの切り出し

かのソフトウェアにはソースコード自動生成ツールによって作STEP1 で得られたソースファイルから，メソッドを切り出成されたソースコードが存在した．このようなソースコードはす．今回の調査では，ソースファイルから抽象構文木を作成してメソッドの切り出しを行う．

STEP3：正規化
このステップでは，コメント文の有無や空白・改行回数などの違いを取り除くために正規化を行う．今回の調査では，以下に示す正規化処理を行う．

コードクローンとして検出されるが，検出されたコードクローンは流用の特定や複数のソフトウェアに存在する共通処理のライブラリ化に対して有用ではない．そのため本研究では，ソースコード自動生成ツールによって作成されたソースコードは検出の対象から除外した．さらに，UCIdatasets から今回解析対象とする拡張子が.java であるファイル以外を削除している．こ—3—

のような処理を行うことで，解析対象以外のファイルに対してスを継承したクラス内で宣言されているメソッドであることが解析対象であるかを判定する必要がなくなり，検出速度が高速わかった．AbstractTableModel は Table 関連の処理を行うク化する．

ラスであり，SwingWorker は GUI における時間のかかる処理

表 1 は，UCIdatasets の構成を表したものである．上記処理の結果，検出対象ファイル数が全ファイル数の約半数に減少している．

を別のスレッドで実行させるためのクラスである．
また，他のソフトウェアとコードクローンを共有しているファイルにどのようなものがあるかを分析するため，コードク

5. 2 定量的な結果

ローンを共有しているソフトウェア数上位 500 ファイルを調UCIdatasets に対して，実装したツールを適用してコードク査した．調査の結果，約 330 ファイルが SwingWorker クラス，ローンを検出した．メソッドクローン数は 2,937,047，メソッ

約 150 ファイルが ResourceBundle を使用するクラス，残り 20

ドクローンの種類数は 814,391 となった．814,391 種類のうち，ファイルほどが GUI 関連のメソッドクローンを内包している

約 60%にあたる 490,206 が複数のソフトウェアにまたがってファイルであった．ResourceBundle はプロパティファイルにいた．

記述されているデータを読み込むために使用される．

表 2，3 は，それぞれメソッドクローンとコードクローンを含むファイルの分析結果である．また表中の百分率は，それ実験の結果から，メソッドクローンの発生原因として以下の要因が挙げられる．

ぞれ検出対象メソッド数，検出対象ファイル数に対する割合に抽象クラスの継承，インターフェースの実装なっている．表 2 より，ファイルクローンでないファイルに存抽象クラスを継承するクラスやインターフェースを実装する

在するメソッドクローンは，検出された全メソッドクローン

クラスでは，全ての抽象メソッドをオーバーライドしなければ2,937,047 の 40%を占めることがわかる．また表 3 より，ファならない．またこのようなクラスでは，新たに処理を記述する

イルクローンではないがメソッドクローンを含むファイルは，際に別々のソフトウェアであっても処理が類似することがある．

コードクローンを含む全ファイル 1,079,789 の 27%を占めるこ

その結果，多くのソフトウェアにまたがるコードクローンが発とがわかる．

生すると考えられる．

5. 3 発 生 原 因

ソースコードの流用検出したメソッドクローンにどのようなものが存在するかをソフトウェア開発では，web 上などで公開されているソース分析するために，またがっているソフトウェア数上位 100 種類

コードを開発中のソフトウェアに使用することがある．このとのメソッドクローンを調査した．調査の結果を表 4 に示す．表

き，自分の作成したソースコードに対応させるといった理由で，4 より，上位 100 種類のメソッドクローンのうち 40%が GUI使用するソースコードに変更を加えることが考えられる．その関連の処理を行うメソッドであることがわかる．また，GUI 関

結果，ソースコードの一部のメソッドがコードクローンとして連の処理をするメソッドのうち約半数は，SwingWorker など検出される．の抽象クラス内もしくは AbstractTableModel などの抽象クラ汎用的な処理を行うメソッド

size や close といったメソッドは多くのクラスで定義されて表1いる．このようなメソッドは，特定の変数が null や 0 であると

実験対象の構成

全ファイル数

3,963,896

いった条件判定と併用されやすい．そのため，4. で述べたフィ

検出対象ファイル数

2,072,490

ルタリング処理を通過しコードクローンとして検出される．

ソフトウェア数

13,193

検出対象メソッド数

5. 4 解 析 速 度

5,953,165

FCFinder [5] では，1CPU,1core(2.50GHz)，メモリ 4GByte

検出対象ファイルの総行数 361,663,992
全容量の環境で，11.2GByte のソースコードに対して 17.16 時間

30.6GByteでコードクローンの検出を終えている．一方今回の実験では，

1CPU,4core(2.00GHz)，メモリ 8GByte の環境で実装したツー

表 2 検出したメソッドクローンの数
ソフトウェアにソフトウェアにまたがる

またがらない

合計

ファイルクローンの一部

1,407,338(24%)

365,150(6%)

1,772,448(30%)

ファイルクローンでない

658,500(11%)

506,059(9%)

1,164,559(20%)

合計

2,065,838(35%)

871,209(15%)

2,937,047(49%)

表 4 またがっているソフトウェア数上位 100 種類のメソッドクロー
ンの分類
メソッドの種類

表3

検出したコードクローンを含むファイルの数

検出対象メソッドを含む
ファイルクローン

検出対象メソッドを含まない
合計

ファイルクローンではないがメソッドクローンを含む
合計

ソフトウェアにソフトウェアにまたがる

またがらない

288,185(14%)

84,213(4%)

合計

372,398(18%)

304,779(15%)

114,412(6%)

419,191(20%)

592,964(29%)

198,625(10%)

791,589(38%)

147,532(7%)
740,496(36%)

140,668(7%)
339,293(16%)

288,200(14%)
1,079,789(52%)

GUI 関連検出数

AbstractTableModel

15

その他 Table 関連

10

SwingWorker

7

その他

8

64bit-encorder,decorder

13

FileFilter

7

ResourceBundle

4

その他

36—4—

39 private static Converter stringConverter =new Converter() {40 public Short convert(Object o) {41
return parseShort(((String) o));
42 }
43 };

(中略)
49 public Object convertFrom(Object in) {50 if (!CNV.containsKey(in.getClass())) throw
new ConversionException("cannot convert type: "51+ in.getClass().getName() + " to: " +Short.class.getName());
52 return CNV.get(in.getClass()).convert(in);
53 }
(中略)

62
63
64

CNV.put(String.class,stringConverter);(a) mvel

(中略)
30
31
32
33
34
3536

CNV.put(String.class,
new Converter() {public Short convert(Object o) {return Short.parseShort(((String) o));}});

ShortCHクラス(b) mvflex
図3219 public void n2sort() {220 for (int i = 0; i < getRowCount(); i++) {221for (int j = i+1; j < getRowCount(); j++) {222if (compare(indexes[i], indexes[j]) == -1) {223swap(i, j);
224}
225}
226 }
227 }

TableSorterクラス(b) Perham
図4ShortCHクラス

流用特定の例

244 public void n2sort() {245 for(int i = 0; i < getRowCount(); i++) {246
for(int j = i+1; j < getRowCount(); j++) {247
if (compare(indexes[i], indexes[j]) == -1) {248swap(i, j);
249}
250}
251 }
252 }

(a) sun

17 public Object convertFrom(Object in) {18 if (!CNV.containsKey(in.getClass())) throw
new ConversionException("cannot convert type: "19+ in.getClass().getName() + " to: " +Short.class.getName());
20 return CNV.get(in.getClass()).convert(in);21 }TableSorterクラス

ライブラリ化の例

ルを UCIdatasets に適用した結果，4.91 時間でコードクローファイルクローンとしては検出されず，かつ流用の特定や処理ンの検出が完了した．表 5 に各処理に要した時間を示す．こののライブラリ化が実現できそうなメソッドクローンが存在する

ような検出時間でコードクローン検出が完了した理由として，かを調査した．流用の特定はまたがっているソフトウェア数のデータベースを SSD 上においているためデータベースアクセ

下位，処理のライブラリ化はまたがっているソフトウェア数のス速度が高速であることや，UCIdatasets から今回解析対象と上位のメソッドクローンを調査した．図 3，4 は実装したツー

する拡張子が.java であるファイル以外を削除していることが

ルが検出したメソッドクローンの例である．

挙げられる．実行環境やソースコードのサイズが異なるため厳まず図 3 について，ハイライトされている部分が検出され密な比較は困難であるが，十分に実用的な時間で検出が完了したメソッドクローンである．図 3(a) のソースコードはファイたものと考えられる．

ルの先頭にライセンスについての記述があったが，図 3(b) の6. 議

ソースコードは記述が存在しなかった．また，図 3(a) のソース論

コードでは stringConverter という変数を宣言し，put メソッ6. 1 検出したメソッドクローンの有用性ドで stringConverter を呼び出している．一方，図 3(b) のソー検出したメソッドクローンが有用であるかを評価するために，スコードでは put メソッドの内部で処理を記述している．いずれのソースコードも処理の内容自体は変わらないため，違いは表5

記述方法のみである．以上二点から，図 3 はソースコード流用

解析時間

処理内容時間

対象ファイルの特定

0.46h

メソッドの切り出し正規化
フィルタリング

次に図 4 について，2 つのソースコードは Table に関する処理を行うクラスで宣言されているソートを行うメソッドである．

2.98h

swing の JTable におけるソート機能は Java1.6 から実装された機能であるため，それ以前の開発ではソート機能は開発者がハッシュ値の計算ハッシュ値のグループ化 1.47h
合計の一例であると考えられる．

4.91h

自ら実装する必要があった．したがって，図 4 の 2 つのソースコードは実際にライブラリ化された例であり，このようなメ—5—

ソッドクローンを今回の調査で検出することができた．

6. 2 Research Question に対する回答
3. 3 で述べた RQ に対して得られた考察を述べる．
RQ1 は，ファイル単位の検出手法で検出できなかったコーおそれがある．そのため，不必要に多くコードクローンを検出している可能性がある．

7. お わ り に

ドクローンがメソッド単位で検出を行うことで新たにどの程度

本研究では，メソッド単位とファイル単位の 2 つの手法を用検出できるかというものである．今回対象とした UCIdatasets

いて大規模なソフトウェア群からコードクローン検出を行った．

ではファイルクローン検出手法に対し，新たに 1,164,559 のメ実験の結果，検出したメソッド単位のコードクローンのうちソッドクローンが検出され，それらは全メソッドクローンの約約 40%，コードクローンを含むファイルのうち約 27%がメソッ40%を占めることが確認された．また，ファイルクローンではド単位の検出手法で新たに検出されたコードクローンであるとないがコードクローンを含むファイルが 288,200 存在し，それいう結果が得られた．また，ソースコードの流用を特定するこらがコードクローンを含むファイルの約 27%を占めることが確とや複数のソフトウェア間に共通する処理をライブラリ化する認された．

ことに有用であるコードクローンが存在することが確認された．

RQ2 は，メソッド単位で検出を行うことで新たに検出されたコードクローンの発生原因にはどのようなものがあるかというものである．発生原因として以下のようなものが存在した．

•

同じ抽象クラスを継承する複数のクラスを実装する際に処理の内容が類似する•

ソースコードを流用した後，それぞれのソフトウェアに応じた変更を加える•

本研究の今後の課題は以下のとおりである．

•本研究とは別の正規化やフィルタリング処理を実装して検出されるコードクローンに違いがあるかを調査する．

•

対象となるファイルを Java 以外にも拡張して，言語によって検出されるコードクローンに違いがあるかを調査する．
謝辞 本研究は一部，文部科学省「次世代 IT 基盤構築のための研究開発」（研究開発領域名：ソフトウェア構築状況の可視化

サイズを取得する処理や終了処理などの汎用的な処理技術の開発普及）の委託に基づいて行われた．また，日本学術

RQ3 は，メソッド単位で検出を行うことで新たに検出された振興会科学研究費補助金基盤研究（A）（課題番号：21240002）

コードクローンは流用の特定などに有用であるかというものでおよび萌芽研究（課題番号：23650014），文部科学省科学研究ある．6. 1 で述べたように，メソッド単位のコードクローン検費補助金若手研究（B）（課題番号：22700031）の助成を得た．

出で新たに検出したコードクローンには，ソースコードの流用を特定することや複数のソフトウェア間に共通する処理をライブラリ化することに有用なものが存在した．また，またがっているソフトウェア数上位 100 種類のメソッドクローンを調査した結果，56 種類のメソッドクローンが流用の特定や処理のライブラリ化に有用であることを確認した．

6. 3 結果の妥当性
本研究の結果の妥当性に関して，以下で挙げる点に留意する必要がある．
正規化の種類
今回の調査では，4. で述べた正規化を行っている．しかし，型名や数値リテラルを正規化することなど，異なる方法を用いて正規化を行うことで本研究で得られた結果と異なる結果が導かれる可能性がある．
メソッドのフィルタリング方法
今回の調査では，4. で述べたフィルタリング処理を行っている．しかし，このフィルタリング処理では代入文やメソッド呼び出し文のみで構成されるメソッドは，その大小にかかわらず全て検出対象から除外される．そのため，フィルタリング処理の方法を変えることで本研究で得られた結果と異なる結果が得られる可能性がある．
バージョンの異なる同一ソフトウェアの存在

5. 1 で述べたように，UCIdatasets にはバージョンが違う同文

献[1] S.Livieri, Y.Higo, M.Matushita, and K.Inoue, “Very-large
scale code clone analysis and visualization of open source
programs using distributed ccfinder: D-ccfinder,” Proc. ofthe 29th International Conference on Software Engineering,
pp.106–115, 2007.
[2] A.W. Brown and G. Booch, “Reusing open source softwareand practices: The impact of open source on commercialvendors,” Proc. of the 7th International Conference on Software Reuse, pp.123–136, 2002.
[3] T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder: A
multi-linguistic token-based code clone detection system forlarge scale source code,” IEEE Transactions on Software
Engineering, vol.28, no.7, pp.654–670, July 2002.
[4] J. Mayrand, C. Leblanc, and E.M. Merlo, “Experiment on
the automatic detection of function clones in a software system using metrics,” Proc. of the 12th IEEE International
Conference on Software Maintenance, pp.244–253, 1996.
[5] 佐々木裕介，山本哲男，早瀬康裕，井上克郎，“大規模ソフトウェアシステムを対象としたファイルクローンの検出，” 電子情報通信学会論文誌 D，vol.J94-D，no.8，pp.1423–1433，2011．
[6] J. Ossher, H. Sajnani, and C. Lopes, “File cloning in open
source java projects: The good, the bad, and the ugly,”
Proc. of the 27th International Conference on Software
Maintenance, pp.283–292, Sep. 2011.
[7] R. Rivest, “The md5 message-digest algorithm,” April 1992.
http://www.ietf.org/rfc/rfc1321.txt.
[8] C. Lopes, S. Bajracharya, J. Ossher, and P. Baldi, “Ucisource code data sets”. http://www.ics.uci.edu/~lopes/datasets/.

一ソフトウェアが複数含まれている．本研究では，実装したツールを適用する前に可能な限り最新のバージョン以外のソフトウェアを検出対象から除外しているが完全ではなく，バージョンの違う同一ソフトウェアが検出対象に複数含まれている—6—