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

信学技報
TECHNICAL REPORT OF IEICE.

コードクローンに対する集約結果に基づいた
削減可能なソースコード行数の測定手法
中川将†

肥後 芳樹†

楠本 真二†† 大阪大学大学院情報科学研究科〒 565–0871 大阪府吹田市山田丘 1–5
E-mail: †{t-nakagw,higo,kusumoto}@ist.osaka-u.ac.jp
あらまし コードクローンとは，ソースコード中に存在する互いに一致または類似しているコード片のことである．
コードクローンを一つのメソッドやクラスに集約することにより，ソースコード行数の削減が可能である．削減可能なソースコード行数を推定する手法として，コードクローンの情報を解析する手法が既存研究では提案されている．しかし，コードクローンの中には集約するとコンパイルやテストに失敗するものが存在すると著者らは考えた．
そのため，コードクローンの集約により削減可能なソースコード行数を推定するとき，コードクローンの情報のみ
では正確な推定を行うことはできない．そこで本研究では，より正確な削減可能なソースコード行数を推定する手法を提案する．提案手法では，それぞれのコードクローンの集合に対して集約，コンパイル，テストを自動で行い，それらが実際に集約可能なのかを判定したうえで，削減行数を測定する．さらに提案手法を用いてオープンソースソフトウェアの削減可能なソースコード行数の測定を行った．その結果，コードクローンの情報のみで推定された削減可能な行数とは異なる数値を得た．
キーワード

コードクローン，ソフトウェア保守，リファクタリング支援

1. ま え が き抽出を行うことで，クローンの集合（以下，クローンセット）を一つのメソッドに集約できる [5]． クローンの集約を行うこ

一度完成したソフトウェアであっても機能追加やバグ修正とでソースコードの行数が削減可能である．そのため，クローなどの保守が必要であり，保守にはコストが必要となる [1]．

ンの情報から削減可能なソースコード行数を推定できると考ソフトウェアの保守に必要なコストはそのソフトウェアの規えられている [6]． しかし，検出されたクローンの中には，集模や複雑さから算出されることが多い [2]．ソフトウェアの規約を行うことでコンパイルやテストに失敗するクローンがあ模はソースコードの行数から測定できる．しかし，冗長なソーる．また，異なるクローンが部分的に重なることで，どのクスコードが多く含まれているとソフトウェアの規模を正確にローンを集約するべきか選択する必要がある．このような問測定できない．したがって，ソフトウェアの規模を測定し保題点から，リファクタリングを行うことで削減可能なソース守に必要なコストを見積もるためには，冗長なソースコードコード行数を推定することは容易ではない．

を削減した場合の行数を推定する必要がある．

既存研究では，削減可能なソースコード行数を推定する手

冗長なソースコードの一つとしてコードクローン（以下，ク法としてクローンの情報を解析するという手法を提案していローン）が挙げられる． クローンとは，ソースコード中に存る [7]．しかし，実際にクローンの集約を行っていない．その在する互いに一致または類似しているコード片のことである．

ため，算出された推定値に対して，その行数が実際に削減可能

クローンの主な発生要因としてコピーアンドペーストが挙げであるかどうか分からない．また，実際にクローンの集約をられる [3]．クローンとなっているコード片を一つのモジュー行うと，コンパイルとテストに失敗して集約を行えない可能ルに集約することで，冗長なソースコードを削減できる．

性も考えられる．例えば，検出されたクローン間の対応するクローンを集約する方法の一つとしてリファクタリングが変数の型が異なる場合，集約を行うとコンパイルに失敗する挙げられる．リファクタリングとはソフトウェアの外部的振ので集約を行うことはできない．また，テストを行わなけれる舞いを保ちつつ内部の構造を改善することと定義されていば外部的振る舞いが保たれていることを保証できない．しかる [4]．リファクタリングの一つにメソッド抽出という手法がし，検出された大量のクローン全てに対して，手作業で実際にある．メソッド抽出とは，既存のソースコードから一部のコー集約が可能かを確認することには多大な労力が必要となる．

ド片を切り出し新たなメソッドにすることである．メソッド

そこで本研究では，クローンの検出，ソースコードの変更，—1—

inputStep 1
クローン検出準備のソースコード変更

クローンセット…
ソースコード変更された
ソースコードStep 2
ソースコード変更

テスト生成
変更された
ソースコード

…
50行削減

30行削減

終了条件達成20行削減
Step 3
変更された
ソースコードのコンパイルとテスト

テスト…
Step 4
変更された
ソースコードの選択
準備

outputコンパイルとテストの結果

集約済み
ソースコード+削減行数

クローン集約図 1 提案手法の概要

コンパイル及びテストを全て自動で行い，実際に削減行数を•

ローカル変数の初期化測定することで，より正確なソースコードの削減可能行数を•フォーマッタの適用算出する手法を提案する．また，提案手法を用いて Java 言語

この準備はクローン集約を行う度に実行する必要はない．

で記述されたプロジェクトに対して実験を行い，削減可能行

2. 2数を算出した．その結果，既存研究とは異なる数値を得た．

クローン集約は次の 4 ステップから構成される．これらは2. 提 案 手 法

クローン集約すべて自動で行われる．
Step 1:

クローン検出

本研究では，クローンの検出，ソースコードの変更，コンパ

Step 2:

ソースコード変更イル，テストを繰り返し行いソースコードの削減可能行数をStep 3:変更されたソースコードのコンパイルとテスト算出する手法を提案する．提案手法の概要を図 1 に示す．本Step 4:変更されたソースコードの選択研究における提案手法の入力はソースコードである．出力はStep 1 では，対象とするソースコード中に存在するクローン集約可能なクローンを全て集約したソースコードと削減されセットを検出する．Step 2 では，ソースコードに対して Stepたソースコード行数である．

1 で検出したクローンセットの一つを集約する変更を加える．

本研究の提案手法は以下の二つの工程で構成される．
• 準備
•
2. 1

クローン集約準備

集約の際に抽出されたメソッドは，2. 1 で説明した準備で用意したクラス内に宣言する．Step 3 では，変更されたソースコードに対してコンパイルとテストを行い，外部的振る舞いが変化していないかどうかを判定する．以降，Step 2 で変更された

準備ではソースコードの変更前後で外部的振る舞いが変化

ソースコードの中で，行数が削減されコンパイルとテストをしていないかを確認するために，対象とするソースコードの通過するようなソースコードを選択可能なソースコードと定単体テストを用意する．単体テストはソースコードから自動義する．Step 1 で検出したすべてのクローンセットに対して生成する．

Step 2 と Step 3 を行い，Step 4 で選択可能なソースコード

また，メソッド抽出で切り出されたメソッドの宣言を行うクの中で削減行数が最も多いソースコードを選択する．そしてラスを用意する．それに加えて，メソッドのアクセス修飾子選択したソースコードに対して繰り返し Step 1 以降を実行す及びローカル変数の未初期化によるコンパイルエラーとコーる．終了条件に到達した時点でクローン集約を終了し，削減行ディングスタイルによる削減行数の変化を防ぐために，ソース数を測定し出力する．クローン集約の終了条件は以下とする．
• クローンが検出されなくなるコードに変更を加える．合計で以下の四つの変更を行う．それぞれの変更内容については 3. 1 で詳しく述べる．
• 抽出されたメソッドの宣言を行うクラスの用意••

選択可能なソースコードが存在しなくなる

メソッドのアクセス修飾子の変更—2—

public class FizBuzz {public static String apply(int num){if (num % 15 == 0) {return "FizzBuzz";} else if (num % 5 == 0) {return "Fizz";} else if (num % 3 == 0) {return "Buzz";} else {return String.valueOf(num);}}}@Test(timeout = 4000)
public void test0() throws Throwable {String string0 = FizBuzz.apply(-74);
assertEquals("-74", string0);}@Test(timeout = 4000)
public void test1() throws Throwable {String string0 = FizBuzz.apply(-9);
assertEquals("Buzz", string0);}@Test(timeout = 4000)
public void test2() throws Throwable {String string0 = FizBuzz.apply(170);
assertEquals("Fizz", string0);
}

12
3
4
5
6if (a > b){
int temp = a;a = b;
b = temp;
}

12
3
4
5
6
1

- if (a > b)
- {int temp = a;a = b;
b = temp;- }+ method(a, b);@Test(timeout = 4000)
public void test3() throws Throwable {String string0 = FizBuzz.apply(660);
assertEquals("FizzBuzz", string0);}(a) 入力されたソースコード

3. 実3. 1

準if (a > b) {int temp = a;a = b;
b = temp;
}

12
34
5
1- if (a > b) {int temp = a;a = b;
b = temp;- }+ method(a, b);

5 行削減

4 行削減

(a)

(b)

図3

コードによって削減行数が異なる例(b) 出力されるテスト生成されるテストコードの例

図2

1
2
3
45

装備

まず，対象とするソースコードに対して単体テストを自動生成する．テストの自動生成ツールとして EvoSuite を用いるテストが生成されている．EvoSuite で自動生成された単体

1234

1234

if (x > y) {int tmp = x;x = y;
y = tmp;}if ($0 > $1) {int $2 = $0;$0 = $1;$1 = $2;
}

1234

1234

if (i < j) {int tmp = j;j = i;
i = tmp;}if ($0 < $1) {int $2 = $1;$1 = $0;$0 = $2;}...

るテストの例を図 2 に示す．例では全ての条件分岐を網羅す

クローン

if ($0 > $1) {int $2 = $0;$0 = $1;$1 = $2;}...

る最小の単体テストを出力する．EvoSuite を用いて生成され比較

if (a > b) {int temp = a;a = b;
b = temp;}...

力とし，そのソースコードに対して可能な限り分岐を網羅す

ハッシュ化

正規化

...

た [8]．EvoSuite は Java ソースコードのクラスファイルを入

ブロック

5678

5678

テストはソースコードの変更を行う前と行った後での外部的振る舞いに変化がないことを確認するために用いる．

図 4 クローン検出の例

次に，対象とするソースコードに 2. 1 で述べた四つの変更を加える．
抽出されたメソッドの宣言を行うクラスの用意

ローカル変数の初期化
Java の言語規約上，初期化されていないローカル変数を参メソッド抽出で切り出されたメソッドを宣言するクラスを新照することは禁止されている．そのため，抽出されたメソッしく用意する．このクラスは新しく用意したパッケージ内でドを呼び出すときに，初期化されていないローカル変数を引宣言される．このクラス内で宣言されたメソッドが元のコー数として与えるとコンパイルエラーが発生する．開発者がリド片があった場所から呼び出される際には完全修飾名で呼びファクタリングを行う際には何らかの値で初期化してから引出される．

数として与えることが考えられる．したがって本研究では，事メソッドのアクセス修飾子の変更前に final 修飾子がついておらず，宣言時に初期化されていな

public 以外のアクセス修飾子で宣言されたメソッドは，そのい全てのローカル変数を初期化する．ローカル変数が boolean

メソッドが宣言されているクラスとは別のクラスやパッケー型以外のプリミティブ型の場合は “0” ，boolean 型の場合はジから呼び出された場合コンパイルエラーとなることがある．

“false”，参照型の場合は “null” で初期化する．

この問題に対して，開発者がリファクタリングを行う際にはフォーマッタの適用様々な対応が可能である．例えば，メソッドのアクセス修飾

コーディングスタイルの規約はプロジェクト毎に定められ子を適切に変更したり，抽出されたメソッドをクローンが検ている．例えば，改行を多く使うような規約もあればその逆出されたクラスと同じクラスに宣言したりするといった対応も存在する．プロジェクト内でコーディング規約に従わないが考えられる．しかし，本研究ではメソッド抽出と宣言を自コードが存在した場合，正確な削減行数を測定できない可能動で行っているため，このような対応を行うことは困難であ性がある．コードによって削減行数が異なる例を図 3 に示す．

る． したがって，外部的振る舞いが変化しない範囲で，事前

図 3(a) ではコード片をメソッドに切り出すと 5 行削減されに全てのメソッドのアクセス修飾子を public に変更する．

るのに対して，図 3(b) では 4 行の削減になる． したがって，事前にフォーマッタを利用しコーディングスタイルを統一す—3—

る必要がある．本来ならプロジェクト毎のコーディング規約を再現したフォーマッタを用意するべきだが，それは困難なため，本研究では適用するフォーマッタは Eclipse の基本設定のフォーマッタで統一した．
3. 2

クローン集約

Step 1: クローン検出
クローン検出の例を図 4 に示す．クローンはブロック単位で変更前のクローンセット
if (a > b) {int temp = a;a = b;
b = temp;}

変更後のクローンセット
メソッド呼び出しに変更
引数の参照渡し化

if (x > y) {int temp = x;x = y;
y = temp;}

int[] a0 = {a}; int[] a1 = {b};package.Class.aggregated(a0, a1);
a = a0[0]; b = a1[0];int[] a2 = {x}; int[] a3 = {y};package.Class.aggregated(a2, a3);
x = a2[0]; y = a3[0];検出する． 本研究では， Eclipse JDT（注 1） で Statement としメソッド抽出
新クラスに宣言て定義されているものの内，以下をブロックとして検出する．
• Block

package/Class.java

aggregated(int[] p0,int[] p1){
if (p0[0] > p1[0]) {int temp = p0[0];p0[0] = p1[0];p1[0] = temp;}}•DoStatement•

EnhancedForStatement•

ForStatement•

IfStatement•

SwitchStatement•SynchronizedStatement•

TryStatement

変更の例を図 5 に示す．クローンをメソッドに抽出すること•WhileStatement

で，それぞれのクローンをメソッド呼び出しに変更でき，ソー図 5 ソースコード変更の例

ブロック単位で検出されたクローンは字句単位で検出されスコード行数を減らすことができる．抽出されたメソッドはたクローンと比べると粗粒度であり検出されるクローンの数は2. 1 で作成したクラスに宣言する．このメソッドは完全修飾名少なくなるが，文の集合として検出されメソッドとして抽出すで呼び出される．

ることが容易であるという特徴がある [9]．本研究では Eclipse

また，抽出されたメソッド内で引数として与えられた変数

JDT を用いて抽象構文木解析を行いソースコード中のブロッに変更がある場合，メソッド呼び出し以降の外部的振る舞いクを検出する．この時，return 文を含むコード片をメソッドに影響が出る可能性がある．そこで，抽出されたメソッドにとして抽出することは難しいとされているため，そのような参照渡しで引数を与えることで外部的振る舞いを保つようにブロックは検出を行わない [10]．

する．引数を参照渡しにするために配列を利用する．メソッ

識別子の正規化を行うことでより多くのクローンを検出でド呼び出し前にそのメソッド内で利用される変数の型の配列きるため，検出したブロックに対して以下のルールで正規化を定義する．これらの配列を各変数で初期化した後にそれらを行う．
• 変数名は “$” + “数字” で正規化するの配列をメソッドに引数として与える．抽出されたメソッド
内では，引数として与えられた配列の添字 0 の要素を参照す•

同一の変数名は同一の名前で正規化する

る．メソッド呼び出し後に元の変数に配列の添字 0 の要素を•リテラルは全て “$” で正規化する

代入する．

•修飾された変数名は一つの変数として正規化する•

クラス名は正規化しない

Step 2 で変更した結果，行数が削減したソースコードに対•メソッド名は正規化しない

してコンパイルとテストを行う．テストには 3. 1 で生成した

Step 3: 変更したソースコードのコンパイルとテスト

同一の変数名を同一の名前で正規化することで誤検出を防テストを用いる．初めにコンパイルを行い，コンパイルに成功

ぐ．クラス名とメソッド名を正規化しない理由は，クラスとすると次にテストを行う．コンパイルとテストのどちらにもメソッドはメソッドの引数として与えることができないので，成功した場合，変更されたソースコードを選択可能なソースクローンとして検出されるのを防ぐためである．

コードとして記録し，ソースコードを変更を加える前の状態正規化を行った後にブロックのハッシュ化を行う．ハッシュに戻し，次のクローンセットに対して Step 2 から繰り返す．

化には MD5 [11] を利用する．MD5 は 128 ビットのハッシュ

コンパイルあるいはテストのどちらかに失敗した場合，その値を出力するため，ハッシュ値の衝突の可能性は十分に低い

ソースコードは記録せず，成功した場合と同様にソースコーと考えられる．

ドを変更を加える前の状態に戻し，次のクローンセットに対最後にそれぞれのブロックのハッシュ値を比較し，同じ値のブロックをクローンとして検出する．
Step 2: ソースコード変更

して Step 2 から繰り返す．
Step 4: 変更したソースコードの選択
Step 1 で検出されたすべてのクローンセットに対して Step

Step 1 で検出されたクローンセットの一つに対してメソッ

2，Step 3 の処理を行った後に Step 4 に移る．Step 4 では，ド抽出を用いてソースコードに変更を加える．ソースコード

選択可能なソースコードの中から最も削減行数が大きいソースコードを選択する．選択されたソースコードに対して，Step（注 1）

Java Development Tools https://www.eclipse.org/jdt/—4—

1 から繰り返す．に含まない．ソースコードの行数は 3. で説明したフォーマッ4. 実

タを適用した後の行数である．

験ついて述べる．
4. 1

実験結果

4. 3

本章では，提案手法を用いて行った実験と，その実験結果に実験結果を表 2 に示す．実験結果から分かるように，検出されたクローンセットの中で，集約することで行数が減り，コ

実験概要

ンパイルとテストを通過するクローンセットは全体の 5 - 10

オープンソースソフトウェア（以下，OSS）に対して提案% ほどとそれほど多くない．また，集約可能なクローンセッ手法を適用することで，削減可能なソースコード行数を算出

ト数と削減行数から，一つのクローンセットあたり 10 行程度する．今回は，3. 2 で述べたクローン検出の際に正規化を行っ行数が削減されていることが分かる．

た場合と，正規化を行わなかった場合の二通りの実験を行っ

次 に 既 存 研 究 と の 比 較 を 行 う ．比 較 対 象 は jEdit，

た．また，算出した値に対して既存研究と削減行数の比較をJFreeChart，JRuby の三つのプロジェクトである．既存研行った．

究と本研究の提案手法で算出した削減行数を表 3 に示す．な

4. 2

実験対象

お，既存研究は対象のプロジェクトに対してフォーマッタを適

実験対象は Java 言語で記述された OSS である．本研究で用していないため，フォーマッタを適用していないプロジェ

は，既存研究で対象となったプロジェクトの中から EvoSuite

クトに対して提案手法で削減行数を測定した結果を記載する．

でのテスト生成に成功した jEdit，JFreeChart，JRuby の三つ

表から分かるように，既存研究と本研究とでは得られた削と，GitHub 上で公開されている fastjson，Checkstyle の二つ

減行数は大きく異なる．jEdit では既存研究と比べると提案手を加えた合計五つのプロジェクトを対象として実験を行った．

法がより多い削減行数を算出したが，jEdit 以外では既存研究

fastjson と Checkstyle は，GitHub 上で公開されており以下と比較して非常に少ない削減行数を算出した．の三つの条件を満たすプロジェクトの中で，スター数が上位二つのプロジェクトである．
• プロジェクトが Apache Maven で管理されている

5. 考

察

本章では，4. で述べた実験の考察を行う．

•

対象とするソースコードの行数が 50,000 行以上である

5. 1

実験結果に対する考察•

EvoSuite でのテストの生成に成功する

実験の結果から，集約することで行数が減り，なおかつコMaven で管理されているプロジェクトを選んだ理由は，Evo-ンパイルとテストを通過するクローンセットは検出されたク

Suite は Maven のプラグインとして提供されているため，テスローンセット全体の内 5 - 10 % ほどであることが分かった．

トの生成が容易であるからである．それに加えて，Maven をコンパイルに失敗する主な原因として以下が挙げられる．
• クローン間で対応する変数の型が異なる用いることでコンパイルとテストを容易に行うことができる．
対象としたプロジェクトの名前，バージョン及びソースコー•

super を使用して親クラスを参照している

ドの総行数を表 1 に示す．バージョンは，既存研究と同じプ•ブロック内で例外を throw しているがその例外の対応ロジェクトに関しては同じバージョン，異なるプロジェクトは実験時の最新リリースのバージョンである．なお，プロジェクはブロック外で行っている
ブロック内で break や continue しているが繰り返し処•

トのテストやチュートリアルなどのソースコードは実験対象

理はブロック外で行っている
これらの中には，提案手法の実装方法によってはコンパイ

表 1 実験対象の OSS（∗ 単位は K LoC）
バージョン

∗ 行数jEdit

5.4.0162

プロジェクト名

JFreeChart

1.0.19236

jEdit

136362JRuby

1.7.27332

JFreeChart

9,700

757

fastjson

1.2.54

50

JRuby

2,161

222

Checkstyle

8.1581

プロジェクト名表3算出された削減可能行数の比較結果（∗ 単位は LoC）
∗ 既存研究 ∗ 提案手法

表 2 実験結果（∗ 単位は LoC）
正規化を行った場合
プロジェクト名

正規化を行わなかった場合

検出された

集約可能なクローンセット数

クローンセット数∗ 削減行数

検出された

集約可能なクローンセット数

クローンセット数∗ 削減行数

jEdit

397

19213

273

17139

JFreeChart

872

43377

607

24217

JRuby

802

40326

515

44238

fastjson

491

44600

189

6400

Checkstyle

100

53651

2

1—5—ルが可能であるものも存在する．例えば，super を使用して親の結果からより正確な削減可能なソースコード行数を測定す

クラスを参照しているコードを含むクローンが同じクラス内る手法を提案した．また，実験の結果，既存研究とは大きく異にのみ存在した場合，抽出されたメソッドをそのクラスに宣なる削減可能行数が算出されるという結果となった．

言することでコンパイルを通過する可能性がある．
既存研究との比較に対する考察

5. 2

今後の課題としては次のようなものが考えられる．
複数のリファクタリング手法の採用

既存研究との比較を行った結果，算出された削減可能行数

本研究ではクローンの集約手法としてメソッドの抽出のみが大きく異なるという結果になった．このような結果となっを使用した．しかし，クローンに対するリファクタリング手た理由として以下の要素が考えられる．
• クローン検出法の違い

法はメソッドの抽出だけでなく，多くの手法が提案されてい•コンパイル，テストの有無形成などが挙げられる．これらの手法を採用することで，よ•

削減行数の計測法

り正確な削減行数の算出が可能になることが期待できる．

る．例えば，メソッドの引き上げやテンプレートメソッドのクローン検出法の違い

回避可能なコンパイルエラーを回避するための実装

本研究ではブロック単位でのクローン検出を行っているが，5. 1 で述べたように，本研究ではコンパイルエラーとなった

既存研究では字句単位でのクローン検出を行っている．字句が，実装を工夫することでコンパイルが可能になるようなク

単位でのクローン検出はブロック単位でのクローン検出よりローンセットが存在すると考えられる．このようなクローン多くのクローンの検出が可能である．クローン検出法の違い

セットに合わせて実装を改善することで，より正確な削減行から，集約対象となるクローンの数に差が出ることが考えら数の算出が可能になることが期待できる．

れる．
コンパイル，テストの有無
本研究では実際にクローンを集約したソースコードに対し謝辞
本研究は，日本学術振興会科学研究費補助金基盤研究（B）（課題番号：17H01725）の助成を得て行われた．
文てコンパイルとテストを行い集約可能かを判定している．しかし，既存研究では行っていない．したがって，既存研究で集[1]約可能と判断されたクローンセットは，実際は集約できない可能性があり，それが原因で削減行数に差が出ていることが[2]考えられる．
削減行数の計測法[3]

本研究では実際にクローンの集約を行い，集約の前後でのソースコード行数の変化から削減行数を測定している．しかし，既存研究では jEdit 以外のプロジェクトに対して実際の[4]削減行数の測定は行っていない．したがって，実際の削減行数が既存研究の推定値とは異なっている可能性がある．

[5]

6. 妥当性への脅威
本章では，本研究に対する妥当性への脅威について述べる．

[6]

本研究では 5 つの OSS を対象に実験を行った．しかし，他のプロジェクトに対して実験を行った場合，本研究で得られた結果とは異なる可能性がある．

[7]

本研究では，ハッシュ値の比較を行うことでクローンを検出している．ハッシュ値の衝突が発生した場合，誤ったクローンが検出される可能性がある．しかし，本研究では 128 ビッ[8]

トのハッシュ値を出力する MD5 を用いており，ハッシュ値の衝突の可能性は十分に低い．
本研究では，ソースコードの変更前後で外部的振る舞いが[9]変化していないことを確認するために EvoSuite によって自動生成された単体テストを用いた．しかし，自動生成されたテ[10]

ストが不十分で，外部的振る舞いの変化を正確に確認できていない可能性がある．
[11]

献

B.P. Lientz and E.B. Swanson, Software Maintenance Management, Addison-Wesley Longman Publishing Co., Inc.,
1980.
T.M. Pigoski, Practical Software Maintenance: Best Practices for Managing Your Software Investment, 1st edition,
Wiley Publishing, 1996.
肥後芳樹，楠本真二，井上克郎，“コードクローン検出とその関連技術，” 電子情報通信学会論文誌. D, 情報・システム = The
IEICE transactions on information and systems (Japaneseedition)，vol.91，no.6，pp.1465–1481，June 2008．
M. Fowler, Refactoring: Improving the Design of Existing
Code, Addison-Wesley Signature Series, Pearson Education,
1999.
肥後芳樹，吉田則裕，“コードクローンを対象としたリファクタリング，” コンピュータ ソフトウェア，vol.28，no.4，pp.4_43–4_56，2011．
N. Yoshida, T. Ishizu, B. Edwards, III, and K. Inoue, “Howslim will my system be?: Estimating refactored code size by
merging clones,” Proceedings of the 26th Conference on Program Comprehension, pp.352–360, ICPC ’18, 2018.
石津卓也，吉田則裕，崔 恩瀞，井上克郎，“コードクローンに対するリファクタリング可能性に基づいた削減可能ソースコード量の調査，” Technical Report 7，大阪大学, 名古屋大学, 奈良先端科学技術大学院大学, 大阪大学，Nov. 2017．
G. Fraser and A. Arcuri, “Evosuite: Automatic test suite generation for object-oriented software,” Proceedings of the 19th
ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering, pp.416–419,
ESEC/FSE ’11, 2011.
堀田圭佑，楊 嘉晨，肥後芳樹，楠本真二，“粗粒度なコードクローン検出手法の精度に関する調査，” 情報処理学会論文誌，vol.56，no.2，pp.580–592，Feb. 2015．
R. Komondoor and S. Horwitz, “Eﬀective, automatic procedure extraction,” 11th IEEE International Workshop on
Program Comprehension, pp.33–42, May 2003.
R. Rivest, “The md5 message-digest algorithm,” April 1992.

7. あ と が き
本研究では，コードクローンに対して実際に集約を行い，そ—6—