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

信学技報
TECHNICAL REPORT OF IEICE.

集約されたメソッドを利用したコードクローンベンチマークの作成
幸 佑亮†

肥後

芳樹†

堀田

圭佑†

楠本 真二†† 大阪大学大学院情報科学研究科 〒 565–0871 大阪府吹田市山田丘 1-5
E-mail: †{y-yusuke,higo,k-hotta,kusumoto}@ist.osaka-u.ac.jp
あらまし

コードクローンとは，ソースコード中に存在する互いに類似したコード片のことである．一般的に，コー

ドクローンはソフトウェアの保守性を低下させる原因になるとされている．そのため，コードクローン情報を理解す
ることはソフトウェア保守の観点から重要であり，これまでに多くのコードクローン検出ツールが開発されている．
そこで，コードクローン検出ツールがどの程度正確にコードクローンを検出できるかどうかの精度評価が必要となる．
コードクローン検出ツールの精度評価では，ベンチマーク（コードクローンの正解集合）を作成し，適合率と再現率の観点から評価することが多い．そのため，コードクローン検出ツールの精度評価は使用するベンチマークに依存する．
先行研究で作成されたベンチマークは作成者の主観に依存していることと実際の開発過程で発生したコードクローン
ではないことが課題である．そこで本研究では，ソースコードリポジトリに蓄えられているソフトウェアの開発履歴
情報を利用して集約されたメソッドを検出し，集約前のメソッドを正解のコードクローンと定義することで上記の課
題を解決するベンチマークを提案する．このベンチマークはコードクローン検出ツールがどの程度正確に集約すべき
コードクローンを検出できるかどうかを評価する際に有用である．
キーワード

コードクローン，コードクローン検出ツール，精度評価，ベンチマーク，集約

1. ま え が きらは以下のいずれかの方法でベンチマークを作成している．
人間が目視によって判断：クローン検出ツールが検出したク

コードクローン（以降，クローンと表記する）とは，ソース

ローンのペアや対象の機能を持つ可能性があるコード片の集

コード中に存在する互いに同一，あるいは類似したコード片で合に対して，人間がクローンか否かを 1 つずつ目視で判断すある．クローンの主な発生要因はコピーアンドペーストである [3] [6]．この手法は正解クローンか否かの判断がベンチマー

る [1]．一般的に，クローンはソフトウェアの保守性を低下させ

ク作成者の主観に依存していることが課題である．ベンチマーる原因になるとされている．例えば，あるコード片にバグが存

クに含まれる正解クローンはその作成者のクローンの定義に依在した場合，そのコード片のクローンに対しても同様のバグが存するため，精度評価の客観性が乏しい．また，検出ツールの存在する可能性があり，同様の変更を検討する必要がある．そ検出結果を基に正解集合を作成している場合，検出されなかっのため，クローンがソフトウェア中にどの程度存在しているか，

たクローンが正解クローンに含まれないことも課題である．

及びどこに存在しているかを理解することはソフトウェア保守

人工的にクローンを生成：あるソフトウェアに存在するコーの観点から重要であり，これまでに多くのクローン検出ツール

ド片を無作為に抽出し，そのコード片に対して何かしらの変更が開発されている [1] [2]．そこで，検出ツールがどの程度正確を加えた後，そのソフトウェアの任意の場所にペーストし，人にクローンを検出できるかどうかの精度評価が必要となる．

工的に正解クローンを生成する [7]．この手法は実際の開発過程

クローン検出ツールの精度評価では，ベンチマーク（クローで発生したクローンではないことが課題である．実際の開発過ンの正解集合）を作成し，適合率と再現率の観点から評価する

程でほとんど発生しないようなクローンが正解クローンとされことが多い [3]〜 [5]．適合率は検出ツールの検出結果のうちどることによって，正確な精度評価ができなかった可能性があるの程度が正解のクローン（以降，正解クローンと表記する）か事例が存在した [4]．

を指し，再現率は正解クローンをどの程度検出できたかを指す．

上記の手法の課題を解決するために本研究では，実際の開発

そのため，検出ツールの精度評価は使用するベンチマークに含過程で発生したクローンから成るベンチマークを自動で作成すまれる正解クローンに依存する．ベンチマークに誤りが存在す

る．具体的にはソースコードリポジトリに蓄えられているソフ

れば，精度評価の結果に影響を与えることになる．

トウェアの開発履歴情報を利用し，集約されたメソッドを検出

これまでにいくつかのベンチマークが作成されている．それする．集約はクローンに対するリファクタリングの 1 つであり，—1—

表 1 先行研究のベンチマークのまとめ
ベンチマーク

手法

良い点

課題点

Bellon’s benchmark

クローン検出ツールの実行とクローンのベンチマークの先駆け

作成者の主観に依存

目視による判断

クローン検出ツールの検出結果に依存

Mutation and Injection

擬似コピーアンドペースト

作成者の主観に依存しない

Framework

によるクローン生成

正解クローンを自動で生成

開発者が作成したクローンではない

BigCloneBench

対象機能の検索とクローン検出ツールの作成者の主観に依存

目視による判断

検出結果に依存しない

正解クローンの候補が限定

集約前のメソッドを正解クローンと定義することでベンチマー

2. 1 Bellon’s benchmark

クを作成する．また，自動で作成することによって主観に依存

Bellon’s benchmark の作成手順は以下の通りである．

しない正解クローンを多量に取得できる．
集約されたメソッドを検出するツールを実装し，実際にメソッドの集約が行われているかどうかを目視によって評価した．

STEP1：Bellon らは比較対象となる 6 つのクローン検出ツー
ルと検出対象となる 8 つのソフトウェアを選択した．

STEP2：Bellon らは各クローン検出ツールの開発者に検出対その結果，ツールは 19 個のメソッドの集約を検出し，全てが正象に対するクローン検出を依頼し，開発者は検出結果を Bellon

しい検出であることを確認した．作成したベンチマークはウェらに送付した．

ブサイト（注 1） で公開している．

STEP3：Bellon らは検出結果のうち 2%を無作為に抽出し，そ2. 先行研究のベンチマーク
本章では，クローン検出ツールの精度評価の先行研究にてれらがクローンか否かを 1 つずつ目視によって判断した．

Bellon’s benchmark の課題点として以下の 4 つが挙げられる．
•

クローンか否かの判断が Bellon らの主観に依存してい使用されたベンチマーク（Bellon’s benchmark [3]，Mutation

る．正解クローンがベンチマーク作成者に依存するため，精度and Injection Framework [7]，BigCloneBench [5] [6]）を紹介

評価の客観性が乏しくなり，結果に影響を与える．

する．以下では，各ベンチマークの概要を説明する．各ベンチ
マークの特徴を表 1 にまとめた．

Bellon’s benchmark について説明する．このベンチマークは対象ソフトウェアに対してクローン検出ツールを実行し，その検出結果に対してクローンか否かを 1 つずつ目視で判断することで作成された．クローン検出ツールの精度評価で使用するベ•クローン検出ツールの検出結果に依存している．正解ク

ローンの候補はベンチマーク作成当時（2002 年）のクローン検出ツールが検出したクローンに限定されているため，検出されなかったクローンは正解クローンに含まれない．

•

現代のツールによって再現不可能である．Bellon らの正解クローンの定義が十分に文書化されていない．

ンチマークとして先駆けて作成された．正解クローンか否かの2. 2 Mutation and Injection Framework

判断がベンチマーク作成者の主観に依存していることとクロー

Mutation and Injection Framework の作成手順は以下の通ン検出ツールの検出結果に依存していることが課題である．
次に，Mutation and Injection Framework について説明すりである．

STEP1：Svajlenko らは対象ソフトウェアから 250 個のコーる．このベンチマークは人工的にクローンを生成することで作

ド片を無作為に抽出した．

成された．主観に依存しない正解クローンを自動で生成できる．

STEP2：Svajlenko らは抽出したコード片に対して 15 種類の正解クローンが実際の開発過程で発生したクローンではないこ

変更を適用し，トータルで 3,750 個のコード片を生成した．

とが課題である．

STEP3：Svajlenko らは抽出元のソフトウェアに対して変更

最後に，BigCloneBench について説明する．このベンチマー
クはバブルソートやファイルコピーなどのソースコード中に頻繁に出現する機能を対象とする．まず，対象の機能を持つ可能を適用した各コード片を無作為に 10 箇所へ挿入した．
以上の手順を踏むことで，擬似的にコピーアンドペーストを実行し，人工的にクローンを生成した．

性があるコード片の集合を，その機能の特徴を基に対象ソフト

Mutation and Injection Framework の課題点を以下に示す．

ウェアから抽出することで作成した．次に，その集合に対して•生成したクローンが実際の開発過程で発生したクローン

その機能を持つコード片か否かを 1 つずつ目視で判断した．対ではない．識別子のインスタンス名の変更という実際の開発環

象の機能を持つと判断されたコード片を正解クローンとするこ

境でほとんど存在しないような変更を適用したクローンが正解とでベンチマークが作成された．クローン検出ツールを使用せクローンとされることによって，正確な精度評価ができなかっずに正解クローンを取得することができる．対象の機能か否かた可能性がある事例が存在した [4]．

の判断がベンチマーク作成者の主観に依存していること正解ク

2. 3 BigCloneBench

ローンの候補が対象の機能に限定していることが課題である．

BigCloneBench の作成手順は以下の通りである．

以降では，以上 3 つのベンチマークの作成手順と課題点を詳細に説明する．

STEP1：Svajlenko らはバブルソートやファイルコピーなどの計 43 種類の対象となる機能を選択した．

STEP2：Svajlenko らは対象の機能がどのように実装されているかとその機能の特徴を StackOverflow や API のドキュメ（注 1）：http://sdl.ist.osaka-u.ac.jp/~y-yusuke/2016_clone_references_

ントなどで調査した．

contain_merged_methods/

—2—

𝑑1𝑟

𝑑1𝑟+1

𝑎𝑟+2

𝑛𝑟

リビジョン𝑟におけるメソッド𝑛
メソッドの
変更なし

𝑑2𝑟

メソッドの
削除

𝑑2𝑟+1

methodX(){

methodZ(){

機能α

機能α

機能α

methodZ(){
if{
機能α

}

}

}

methodX(){}else{
methodY(){

methodY(){

機能α

機能β

集約前の
メソッド候補

}

機能β

}
}

}

集約後の
メソッド候補Rev.𝑟

Rev.𝑟 + 1

Rev.𝑟 + 1

Rev.𝑟 + 2

図 1 集約パターン 1
𝑐𝑟

𝑐𝑟+1

𝑑𝑟

𝑐𝑟+2

𝑑𝑟+1

(a) クローンの集約の例
𝑛𝑟

リビジョン𝑟におけるメソッド𝑛Rev.𝑟 + 1

Rev.𝑟 + 2(b) クローンの集約ではない例

図 3 構文の類似度を利用したクローンの集約かどうかの判断

情報を利用することで作成する．具体的には全リビジョンを対象にリビジョン間の情報を利用し，集約されたメソッドを検出

メソッドの
削除

することでベンチマークを作成する．集約はクローンに対す

集約後のメソッド候補STEP3：Svajlenko らは調査した情報を基にサンプルコードを作成し，IJaDataSet 2.0 [9] から候補を抽出した．

STEP4：Svajlenko らは機能の特徴とサンプルコードの情報を基に抽出した候補に対して 1 つずつ目視によって対象の機能か否かを判断した．

STEP5：Svajlenko らは対象の機能であると判断したコード
片とサンプルコードの集合を正解クローンとして，構文の類似度によってタイプ別に仕分け，ベンチマークに追加した．

STEP6：Svajlenko らは対象の機能ではないと判断したコード
片とサンプルコードの集合を不正解クローンとしてベンチマー
クに追加した．
以上の手順を踏むことで，クローン検出ツールを使用せずに正解クローンを取得した．

BigCloneBench の課題点として以下の 2 つが挙げられる．
対象の機能か否かの判断が Svajlenko らの主観に依存している．これはクローンか否かの判断が主観に依存していることと同義であると考える．

•

Rev.𝑟 + 2

メソッドの
変更あり

図 2 集約パターン 2•

Rev.𝑟 + 1

メソッドの
変更なし

集約前の
メソッド候補Rev.𝑟

Rev.𝑟 + 2

正解クローンの候補がソースコード中に頻繁に出現する機能に限定している．

3. 提案するベンチマーク
2. 章で先行研究のベンチマークについて述べたが，共通する課題点として，ベンチマークに客観性がないことと正解クローンが実際の開発過程で発生したクローンではないことが挙げられる．そこで本研究では，これら 2 つの課題点を同時に解決するベンチマークを提案する．

3. 1 キーアイデア
先行研究におけるベンチマークでは，対象ソフトウェアの単一のリビジョンのみを対象に 1. 章で述べた 2 つの手法を適用することで作成したが，本研究におけるベンチマークでは，ソースコードリポジトリに蓄えられているソフトウェアの開発履歴

るリファクタリングの 1 つであり，集約前のメソッドを正解ク
ローンと定義する．集約されたメソッドを自動で検出すること
で主観に依存しない正解クローンを多量に取得できる．

3. 2 概要本研究では，メソッドの集約が行われるパターンを 2 つ定義
する．各集約パターンを検出した後，構文の類似度とメソッドの呼び出し関係の情報を利用して誤検出を減らす．
まず，各集約パターンについて以下に説明する．
集約パターン 1：複数のメソッドが削除されて，追加されたメソッドに集約された場合である．例を図 1 に示す．
リビジョン r でメソッド d1，メソッド d2 が存在し，リビジョ
ン r + 1 でも存在していたとする．そして，リビジョン r + 1
から r + 2 へのコミットでメソッド d1，メソッド d2 が削除されたとする．また，メソッド a が追加されたとする．ここでリビジョン r + 1 におけるメソッド d1，メソッド d2 を集約前のメソッド候補，リビジョン r + 2 におけるメソッド a を集約後のメソッド候補と仮定する．
集約パターン 2：複数のメソッドが削除されて，既存のメソッドに集約された場合である．例を図 2 に示す．
リビジョン r でメソッド c，メソッド d が存在し，リビジョ
ン r + 1 でも存在していたとする．そして，リビジョン r + 1
から r + 2 へのコミットでメソッド c に何かしらの変更が行われたとする．また，メソッド d が削除されたとする．ここでリビジョン r + 1 におけるメソッド c，メソッド d を集約前のメソッド候補，リビジョン r + 2 におけるメソッド c を集約後のメソッド候補と仮定する．変更されたメソッドを対象とした理由は，メソッドの集約が行われる際，引数の変更や条件分岐の追加などの変更が行われることがあるためである．

2 つの集約パターンの検出に加えて，構文の類似度とメソッ
ドの呼び出し関係の情報を利用する．構文の類似度を利用する
理由は，2 つの集約パターンの検出だけでは集約されたメソッドとは限らないためである．例を図 3 に示す．図 3(a) に示す
ように，リビジョン r + 1 におけるメソッド x とメソッド y が同じ機能 α を持つメソッドであるとする．そして，リビジョ
ン r + 1 から r + 2 へのコミットで機能 α をメソッド z がまとめて保持するように集約する場合，クローンの集約である．し

—3—

𝐴𝑟+1

𝑥𝑟+1

履歴情報であり，出力は集約されたメソッドの情報である．

𝐴𝑟+2
𝑛𝑟

𝐵𝑟+1

𝐵𝑟+2

𝑦𝑟+1

検出する．

呼び出し元

STEP2：STEP1 で検出されたメソッドを対象に 2 つの集約パ

呼び出し
関係

𝑧𝑟+2

STEP1：リビジョン間で追加，削除，変更されたメソッドをリビジョン𝑟におけるメソッド𝑛

ターンから集約前と集約後のメソッド候補を対応付ける．

STEP3：STEP2 で検出された集約前のメソッド候補と集約後のメソッド候補の類似度を用いて集約前のメソッド候補を絞る．

Rev.𝑟 + 1

Rev.𝑟 + 2

STEP4：STEP3 で絞り込まれたメソッドの呼び出し元の情報を利用して集約されたメソッドを検出し，正解クローンとする．

(a) クローンの集約の例

以上の STEP をソースコードリポジトリの全リビジョン間に対して実行する．以降，各 STEP の詳細について説明する．

𝐴𝑟+1

𝑥𝑟+1

3. 4 STEP1

𝐶𝑟+2
𝑛𝑟

𝐵𝑟+1

𝑦𝑟+1

𝐷𝑟+2

呼び出し元

𝑧𝑟+2
Rev.𝑟 + 1

リビジョン𝑟
における
メソッド𝑛

呼び出し
関係

Rev.𝑟 + 2

ECTEC [10] を使用してソースコードリポジトリに蓄えられているソフトウェアの開発履歴情報を解析する．ECTEC の入力
は Java で記述されており，バージョン管理システム Subversion
及び Git で管理されたソフトウェアである．出力はリビジョン
間の追加，削除，変更の情報が保存されたデータベースである．
クラス，メソッド，ブロック単位でリビジョン間の追加，削除，変更を検出することができる．本研究では，ECTEC を使用してリビジョン間で追加，削除，変更されたメソッドを検出する．

(b) クローンの集約ではない例

図 4 メソッド呼び出し関係を利用したクローンの集約かどうかの判断

かし，図 3(b) に示すように，メソッド x とメソッド y が全く異なる機能 α，β を持つメソッドであるとして，その 2 つの機能をメソッド z がまとめて保持するように集約する場合，ク
ローンの集約ではない．そこで，クローンの集約ではない場合を除くためにメソッド x とメソッド z ，メソッド y とメソッド

z の構文の類似度を算出する．
メソッドの呼び出し関係を利用する理由は，集約前のメソッド候補が構文上は類似しているが，全く異なる機能を持つメソッドである場合が存在するためである．クローンの集約の場
合，同じ機能を持つ複数のメソッドが 1 つのメソッドに集約される．その集約の過程において，削除されたメソッドを呼び出している場所は追加あるいは変更されたメソッドを代わりに呼び出す．例を図 4 に示す．集約されたメソッド候補を呼び出し

先述の各集約パターンを例として説明する．以降の説明では，リビジョン r + 1 から r + 2 へのコミットで追加されたメソッドの集合を Ar+2 ，削除されたメソッドの集合を Dr+2 ，変更前
(b)

(a)

のメソッドの集合を Cr+2 ，変更後のメソッドの集合を Cr+2 とする．また，リビジョン r + 1 におけるメソッド n を nr+1 と表記する．
集約パターン 1 の場合：リビジョン r+1 から r+2 へのコミッ
トでメソッド d1 とメソッド d2 が削除された．また，メソッドa が追加された．式 (1) で表記することができる．
d1r+1 , d2r+1 ∈ Dr+2 ，ar+2 ∈ Ar+2

(1)

集約パターン 2 の場合：リビジョン r+1 から r+2 へのコミッ
トでメソッド d が削除された．また，メソッド c が変更された．
式 (2) で表記することができる．
(b)

(a)

dr+1 ∈ Dr+2 ，cr+1 ∈ Cr+2 ，cr+2 ∈ Cr+2

(2)ている場所（以降，呼び出し元と表記する）を，そのメソッドを呼び出しているメソッドと定義する．リビジョン r + 1 から

r + 2 へのコミットでメソッド x とメソッド y が削除されて，メソッド z が追加されたとする．図 4(a) に示すように，リビ
ジョン r + 1 におけるメソッド x とメソッド y の呼び出し元とリビジョン r + 2 におけるメソッド z の呼び出し元が一致する
場合，クローンの集約である．しかし，図 4(b) に示すように，
メソッド x とメソッド y の呼び出し元とメソッド z の呼び出
し元が一致しない場合，クローンの集約ではない．そこで，ク
ローンの集約ではない場合を除くためにメソッドの呼び出し関係の情報を利用する．

3. 3 作 成 手 順
提案するベンチマークの作成手順について説明する．入力はソースコードリポジトリに蓄えられているソフトウェアの開発

3. 5 STEP2
この STEP では，STEP1 で検出されたリビジョン間で追加，削除，変更されたメソッドを対象に先述の 2 つの集約パターンを利用して集約前と集約後のメソッド候補を対応付ける．先述の各集約パターンを例として説明する．以降の説明では，リビ
ジョン r + 1 から r + 2 へのコミットで集約された可能性があ(b)

るメソッドの集合に対して，集約前のメソッド候補を Ir+2 ，集(a)

約後のメソッド候補を Ir+2 とする．
集約パターン 1 の場合：集約前のメソッド候補である全ての削除されたメソッドを，集約後のメソッド候補である追加されたメソッドと対応付ける．式 (3) で表記することができる．
(b)

(a)

Ir+2 = Dr+2 ，Ir+2 = Ar+2

(3)

集約パターン 2 の場合：集約前のメソッド候補である全ての—4—

表 2 対象ソフトウェアと検出結果
ソフトウェア

対象ディレクトリ

開始リビジョン（日付）

ArgoUML/trunk/src

jEdit/jEdit/trunk

6,022

7

r19893（2012/07/10）

3,925

10

r3791（2001/09/02）

r22016（2012/08/17）

5,168

2

候補である変更後のメソッドと対応付ける．式 (4) で表記することができる．
(b)(a)

リビジョン数 検出数r1（1998/01/27）

削除されたメソッドと変更前のメソッドを，集約後のメソッド(b)

終了リビジョン（日付）/ant/core/trunk/main r267549（2000/01/13） r1240680（2012/02/05）

Ant

(a)

Ir+2 = Dr+2 ∪ Cr+2 ，Ir+2 = Cr+2

(4)

約されたメソッドとする．
′(b)

Oar+2 = {m|∃e ∈ Em [e ∈ Ear+2 ], m ∈ Ir+2 }(7)

ただし，|Oar+2 | < 2 の場合，Oar+2 = ∅ とする．
′

(b)

集約パターン 2 の場合：式 (8) に条件を示す．Ir+2 に含まれ(a)以降では，説明の簡略化のため，Ir+2 に含まれるメソッドのるメソッドの呼び出し元と，集約後のメソッド候補である cr+2

うち 1 つを対象に説明する．集約パターン 1 では，追加されたとその変更前である cr+1 の呼び出し元の差分を比較し，少な(a)

メソッド ar+2 （ar+2 ∈ Ir+2 ），集約パターン 2 では，変更さ
(a)

(a)

くとも 1 箇所が一致するようなメソッドを集約されたメソッド

れたメソッド cr+2 （cr+2 ∈ Ir+2 ）を対象とする．Ir+2 に含まとする．Ir+2 に含まれるメソッドのうち cr+1 は，呼び出し元

れる各メソッドに対して STEP3 以降に説明する処理を行う．

の比較をせず，集約されたメソッドとする．

3. 6 STEP3
この STEP では，STEP2 で検出された集約前のメソッド候(b)

Ocr+2 = {cr+1 , m|∃e ∈ Em [e ∈ (Ecr+2 − Ecr+1 )],′ド候補を絞り込む．先述の各集約パターンを例として説明する．
集約パターン 1 の場合：式 (5) に集約前のメソッド候補を絞り込むための条件を示す．similarity(p, q) は，メソッド p と(b)メソッド q の構文の類似度を算出する関数とする． Ir+2 に含(b)m ∈ (Ir+2 − cr+1 )}補と集約後のメソッド候補の類似度を算出し，集約前のメソッ(8)

ただし，|Ocr+2 | < 2 の場合，Ocr+2 = ∅ とする．
上記の STEP を実行することで，ar+2 もしくは cr+2 に集(a)

約されたメソッドが検出できる．ar+2 , cr+2 ∈ Ir+2 であり，他にもリビジョン r + 2 において集約後のメソッド候補は存在す

まれるメソッドと集約後のメソッド候補である ar+2 の類似度

る．また，ソースコードリポジトリの全リビジョン間に対してを算出し，類似度が閾値 θ 以上のメソッドをこの STEP で絞

各 STEP を実行するため，ベンチマークとなる正解クローンの′(b)り込まれた集約前のメソッド候補 Ir+2 とする．

集合 O は，以下の式 (9) によって表記できる．リポジトリの開

′

(b)
(b)
Ir+2 = {m|similarity(m, ar+2 ) >= θ, m ∈ Ir+2 }
′

(5)

(b)

|Ir+2 | < 2 の場合，ar+2 に集約されたメソッドは存在しないと始リビジョンを start，終了リビジョンを end とする．

O = {Oa |a ∈{Oc |c ∈集約パターン 2 の場合：式 (6) に集約前のメソッド候補を絞θ 以上のメソッドをこの STEP で絞り込まれた集約前のメソッ′(b)

ド候補 Ir+2 とする．

∪

(a)Ck , start + 1 <=k<= end}

(9)

k

(b)

のメソッド候補である cr+2 の類似度を算出し，類似度が閾値

Ak , start + 1 <=k<= end} ∪k

して，この STEP で処理を終了する．
り込むための条件を示す． Ir+2 に含まれるメソッドと集約後

∪

4. 評

価

4. 1 準備

3. 章で述べたベンチマークの作成手順を基に集約されたメ

′

(b)
(b)
Ir+2 = {m|similarity(m, cr+2 ) >= θ, m ∈ Ir+2 }(6)′

ソッドを検出するツールを実装した．実装したツールは，Javaで記述されており，かつ Subversion を使用して管理されている(b)|Ir+2 | < 2 の場合，cr+2 に集約されたメソッドは存在しないと′(b)
して，この STEP で処理を終了する．また，cr+1 ∈/ Ir+2 の場

ソフトウェアのみを対象に検出可能である．検出対象のメソッ

合，cr+2 の変更前である cr+1 が集約前のメソッド候補に含ま設けた．また，構文の類似度を算出する際の閾値を 70%に設定れていないため，cr+2 に集約されたメソッドは存在しないとしした．これらの条件は先行研究 [3] [6] を参考にした．

ドの制限として，6 行以上，かつ 50 トークン以上という条件を本研究では，3 つのオープンソースソフトウェアを対象に実て，この STEP で処理を終了する．

3. 7 STEP4

装したツールを実行した．それぞれのソフトウェアの概要と検この STEP では，STEP3 で絞り込まれた集約前のメソッド

出結果を表 2 に示す．表中の リビジョン数 は，検出対象と候補を対象にそのメソッドの呼び出し元（そのメソッドを呼びなったリビジョンの数，つまりソースファイルに追加，削除，出しているメソッド）の情報を抽出し，その情報を利用して集変更が加えられたリビジョンの数を示している． 検出数約されたメソッドを検出する．先述の各集約パターンを例としツールが検出した集約されたメソッドのグループ数である．

は，て説明する．以降では，Em をメソッド m の呼び出し元の集

これらのソフトウェアを選定した基準は以下の通りである．

合，Om をメソッド m に集約されたメソッドの集合とする．

•

′

(b)
集約パターン 1 の場合：式 (7) に条件を示す． Ir+2 に含まれるメソッドと集約後のメソッド候補である ar+2 の呼び出し元を比較し，少なくとも 1 箇所が一致するようなメソッドを集Java で記述されており，かつ Subversion を使用して管理されていること．

•

長い開発期間を有し，かつ広く使用されているソフト

ウェアであること．

—5—

4. 2 実 験 結 果
実装したツールが集約されたメソッドをどの程度正確に検出度含まれているかを評価する適合率の算出は現時点では難しい．

•

正解クローンの粒度がメソッド単位に限定している．ク

できているかを目視により評価した．その結果，検出された 19

ローンの粒度は行単位や字句単位など様々な粒度が存在する．

個のメソッドの集約は全て正しい検出であることを確認した．

集約されたクローンの粒度も多岐に亘るため，様々な粒度に対4. 3 妥当性の評価
評価手法：本研究では，実装したツールが集約されたメソッ応する必要があるが，現時点では対応できていない．

•

数が少ない．ベンチマークに含まれる正解クローンの数

ドをどの程度正確に検出できているかを目視によって評価した．

が少ないため，クローン検出ツールの精度評価の結果は一般性

しかし，著者らは本研究で対象としたソフトウェアの開発者でに欠ける可能性がある．

はないため，判断に誤りが混入している可能性がある．
対象ソフトウェア：本研究では，3 つのオープンソースソフ

6. あ と が き

トウェアを対象にしている．しかし，他のソフトウェアに対し

本研究では，ソースコードリポジトリに蓄えられている開発て実装したツールを実行し，再度ツールの検出精度を評価した

履歴情報を利用して集約されたメソッドを検出し，集約前のメ

場合，誤検出が検出される可能性がある．

ソッドを正解のクローンと定義することでベンチマークを作成

5. 作成したベンチマークの特徴

した．提案するベンチマークは以下の利点を持つ．

•

ベンチマークに客観性がある．

5. 1 ベンチマークの使用方法•

正解クローンが実際の開発過程で発生したものである．

本研究におけるベンチマークでは，検出対象期間内の全リ集約されたメソッドを検出するツールを実装し，実際にメビジョンを対象に作成したため，正解クローンが存在するリビ

ソッドの集約が行われているかどうかを評価した．その結果，ジョンの全 Java ソースファイルに対してクローン検出ツール

ツールは 19 個のメソッドの集約を検出し，全てが正しい検出を実行する必要がある．そして，その検出結果を基に適合率やであることを確認した．

再現率を評価する．

5. 2 ベンチマークの有用性

このベンチマークはクローン検出ツールがどの程度正確に集約すべきクローンを検出できるかを評価する際に有用である．

このベンチマークの有用性をクローン検出ツールが集約すべ

本研究の今後の課題として，他のソフトウェアに対するツーきクローンを検出できているかを評価する場合と検出すべきクルの実行，ブロック単位の集約の検出，集約以外のクローンにローンを検出できているかを評価する場合に分けて説明する．

対するリファクタリングの検出が挙げられる．最終的には，本集約すべきクローンを検出できているかを評価する場合：こ研究のベンチマークを使用してクローン検出ツールの精度評価の場合において正解クローンは集約すべきクローンである．本を行う予定である．

研究の正解クローンは集約されたクローンであり，集約すべ

謝辞 本研究は，日本学術振興会科学研究費補助金基盤 研究きクローンは集約されたクローンを包含する．よって，正解ク（S）（課題番号：25220003），および文部科学省研究費補助金

ローンの定義に主観は入っていないため，客観的なクローン検

若手研究（A）（課題番号：24680002）の助成を得て行われた．

出ツールの評価が可能である．
検出すべきクローンを検出できているかを評価する場合：この場合において正解クローンは検出すべきクローンである．先行研究の正解クローンはベンチマーク作成者が検出すべきと考えたクローンであり，本研究の正解クローンも先行研究と同様に我々が検出すべきと考えたクローンである．その点は先行研
究と同様である．しかし，先行研究と異なる点は，クローンか否かの判断に主観が入っていない点と正解クローンが実際の開発過程で発生したクローンである点である．よって，先行研究よりも客観的なクローン検出ツールの評価が可能である．

5. 3 ベンチマークの制限
このベンチマークの制限として以下の 3 点が挙げられる．

•

正解クローンを集約されたクローンに限定している．集

約されたクローン以外にも検出すべきクローンは存在し，ク
ローン検出ツールは集約されたクローン以外のクローンを検出する可能性がある．しかし，その検出結果に誤りが存在していたとしても，クローンではないコード片が誤ってクローンと検出されたのか，それとも集約されたクローン以外の検出すべきクローンが検出されたのかをこのベンチマークで判断することは不可能である．また，検出結果のうち正解クローンがどの程文

献[1] 肥後，楠本，井上， コードクローン検出とその関連技術 ，電子情報通信学会論文誌，Vol.91-D，No.6，pp.1465-1481，2008．
[2] 神谷，肥後，吉田， コードクローン検出技術の展開 ，コン
ピュータソフトウェア，Vol.28，No.3，pp.28-42，2011．
[3] S. Bellon, R. Koschke, G. Antniol, J. Krinke, and E. Merlo.
Comparison and evaluation of clone detection tools , IEEE
TSE, Vol.31, No.10, pp.804-818, 2007.
[4] J. Svajlenko and C. K. Roy. Evaluating modern clone detection tools, in ICSME, 2014.
[5] J. Svajlenko and C. K. Roy. Evaluating Clone Detection
Tools with BigCloneBench, in ICSME, 2015.
[6] J. Svajlenko, J. F. Islam, I. Keivanloo, C. K. Roy, and
M. Mia. Towards a big data curated benchmark of interproject code clones, in ICSME, 2014.
[7] J. Svajlenko, C. K. Roy, and J. R. Cordy. A mutation analysis based benchmarking framework for clone detectors, in
IWSC, 2013.
[8] S. Bellon. Detection of software clones, Technical Report, Institute for Software Technology, Universityof Stuttugart, 2003. available at http://www.bauhaus-stuttgart.
de/clones/.
[9] Ambient Software Evoluton Group. IJaDataset 2.0, http://secold.org/projects/seclone, 2013.
[10] Y. Higo, K. Hotta, and S. Kusumoto. Enhancement of
crd-based clone tracking, in IWPSE, 2013.

—6—