ソフトウェアエンジニアリングシンポジウム 2017
IPSJ/SIGSE Software Engineering Symposium (SES2017)

同一仕様プロジェクトを対象としたコードクローン
メトリクスとプロジェクトデータ間の相関分析
肥後 芳樹1

柗本 真佑1

楠本 真二1

三宅 武司2

藤波 崇志2

石橋 昭2

星野 隆2

概要：ソースコード中のコードクローンの存在は，ソフトウェアの保守性を悪化させる 1 つの要因であるといわれている．しかしその一方で，コードクローンに対して同時に変更が行われることはあまりなく，
コードクローンの存在が問題を引き起こすことは少ないという調査報告もある．また，コードクローンはソフトウェア開発に有用であると報告している研究もある．現在著者らはコードクローンの存在がソフトウェア開発や保守作業に与える影響について研究を行っている．この論文では，コードクローンメトリクスとテストケース数や検出バグ数といったプロジェクトデータ間の相関分析の結果を報告する．この分析対
象は 9 つのウェブシステムであり，同一の仕様に基いて異なる組織によって開発された．つまり，これらは機能が同一であり実装が異なるシステムである．この 9 つのシステムを対象とすることで，実装の違いとプロジェクトデータ間の関係を調査できる．調査の結果，コードクローンが多く存在しているプロジェ
クトほどコードのサイズが大きく実装の速度が早いことがわかった．コードクローンが多く存在している
ほど結合テストでバグを見逃す傾向であった．多くのファイルがコードクローンを共有している場合は結合テストは良く実施されていた．しかし，そのような場合は，単体テストでバグを見逃す傾向であった．

1. はじめに当に技術的負債となるのかを調査したいと考えている．しかし，これらの調査を厳密に行うことは非常に難しい．1

コードクローン（以降，クローン）の存在はソースコード

つのシステムを異なった 2 つの方法で開発および保守するの保守作業を困難にするといわれている．クローンが保守必要がある．一方は存在しているクローンに対してなにも作業に対して悪影響を与える原因の 1 つとして複数箇所へ対処することなく開発及び保守を行うシステム，他方はクの同時変更が挙げられる．あるクローンを変更した場合にローンをできる限り 1 つのモジュールにまとめた上で開発は，それと対応するクローンも変更する必要があるとされ及び保守を行うシステムである．これら 2 つを比較すればている．もし，同時に変更が行われなかった場合にはソー

クローンの影響を調べることができる．クローンの影響がスコード中に一貫性の欠如が発生してしまい，それが後に明らかになれば開発者はクローンを集約すべきかどうかをバグとしてソフトウェアに不具合をもたらしてしまう．

判断できる．しかし，このような調査を行うことは現実的クローンに関する問題の支援として，これまでにさまざではない．

まな研究が行われている [18], [25], [27], [29]．また，同時この論文では，コードクローンメトリクスとさまざまな変更の観点からクローンの存在がソースコードの保守性

プロジェクトデータの相関分析の結果を報告する．調査対に与える悪影響について，いくつか調査が行われてきてい象は 9 つのウェブシステムであり，それらは全て異なった

る [1], [5], [7], [10], [11], [14], [26], [28] ．これまでの調査組織により開発されたものである．これらのウェブシステ

により，全てのクローンが保守作業に悪影響を与えている

ムを調査対象として選定した理由は，それらが同一の仕様

わけではないが，バグの原因となるクローンも確かに存在に基いて開発されたシステムであるからである．つまり，しているということがわかってきた．

それらは同一の機能を有しているが実装が異なるシステム

著者らは，クローンの存在がどの程度ソフトウェア開発である．これらのシステムの実装の違い (クローンメトリや保守に影響をおよぼすのか，また，クローンの存在は本

クスの違い) とプロジェクトデータを比較することで，ク
ローンがソフトウェア開発および保守に与える影響を考察

1

2

大阪大学 大学院情報科学研究科 コンピュータサイエンス専攻〒 565-0871 大阪府吹田市山田丘 1-5
日本電信電話株式会社 ソフトウェアイノベーションセンタ
〒 108-0075 東京都港区港南 2-13-34©2017 Information Processing Society of Japanする．
以降，本論文は 2 章でクローンに関する説明を行い，3182

ソフトウェアエンジニアリングシンポジウム 2017
IPSJ/SIGSE Software Engineering Symposium (SES2017)

章で実験の設定について述べる．4 章では実験の結果を報る場合に，機能を追加する周辺のコードのクローンを作成

告し，5 章では実験の妥当性について述べる．最後に 6 章

し，そこに新しい機能を作成する．新しい機能を追加したで本論文をまとめる．

部分の動作が安定してくると，その部分をコピー元へと移2. コードクローン
この章では，クローンの種類ならびにクローンに関する既存調査について述べる．

す．このような手順で開発を行うことにより，新しい機能追加に起因するバグの発生を稼働中のシステムにおいて抑えることができる．Kapser らは 2 つのオープンソースソ
フトウェアについて調査を行い，71%のクローンはソフト
ウェアの保守性に良い影響を与えていたと報告している．

2.1 種類
クローンは，その類似度に基づいて一般的に以下の 3 種

山中らは，クローンの変更管理システムを作成し，実プ
ロジェクトへの適用を行った [23]．彼らの変更管理システ類に分類される．

ムは，バージョン管理システムに登録されている最新バー

TYPE-1 空白，タブ，改行文字，コメント等のソフト

ジョンのソースコードとその前のバージョンのソースコー

ウェアの振る舞いに影響を与えないソースコード中のドからそれぞれクローンを検出し，その 2 つの検出結果に要素を除いて完全に同一のクローン．

おいて対応が取れなかったクローンを変更が行われたクTYPE-2 変数名や関数名等のユーザ定義名の違いやリテローンとして開発者に通知する．ある企業のソフトウェア

ラルの違いのような字句単位での差異を含むクローン．

開発プロジェクトにこの変更管理システムを適用した結TYPE-3 字句単位よりも大きな違いを含むクローン．

果，開発者が把握していなかったクローンに対して変更がこれまでにさまざまな検出手法が提案されているが，行われ，その情報が開発者に電子メールにより何度か通知

クローンの定義は手法ごとに異なる [18], [20]．例えばされた．開発者はその情報に基いてクローンの把握や集約

CCFinder のような字句単位の検出手法では，一定数以上連を行うことができた．

続して重複する字句の列がクローンとして検出される [8]．

Chatterji らは，43 人の大学院生を対象として，クロー

CloneDR のような抽象構文木を用いた検出では，まず対象

ン情報を利用したバグの原因箇所特定に関する実験を行っ

ソースコードを解析することにより抽象構文木が生成され，た [4]．実験では，バグの原因箇所を 1 つ見つけた後にク同じ形状を持つ部分木がクローンとして検出される [2]．つローン情報を利用してその他のコード片もチェックするや

まり，異なる手法を利用して同一ソースコードからクローり方は効率的に他のバグ原因箇所を見つけることができンを検出した場合，その検出結果は異なる．本研究で利用た．その一方で，バグの原因箇所を見つける前に，クローしたクローン検出技術については 3.2 節で述べる．

ン情報を利用してコード片を閲覧していく方法では効率的にバグの原因箇所を見つけることができなかった．

2.2 既存調査

Zhan らは 10 年以上保守されている通信系のソフトウェ

Inoue らは，クローン間の変数の対応付けに着目したバアの開発者 21 人に対して，クローンの生成に関する調査をグ検出手法を考案した [7]．コピーアンドペーストによりク行った [24]．その結果，クローンを生成する理由として，既ローンが生成された後，変数名がペースト後の文脈に合わ

存コードの変更によるバグの混入を防ぐ，1 つのモジュー

せて変更されたとしても，クローン間では変数の対応付けがルに集約するのが難しいという理由に加えて，開発時間の保たれている場合が多い．そのため，クローン間で変数の制限上しかたなくクローンを生成したという組織的な理由

対応付けが保たれていない場合はバグの可能性があるとしや，他人のコードをコピーして変更を行うことで自分自身て，そのようなクローンを検出するツール CloneInspectorのコーディングスキルを上達させたいという個人的な理由を開発した．CloneInspector を企業で開発された 2 つの携があることがわかった．

帯端末関係のソフトウェアに適用したところ，68 のクローンが検出され，そのうちの 26 がバグを含んでいた．

Göde らは，C もしくは Java で記述された 3 つのオー
プンソースソフトウェアを対象として，クローンに対してMonden らは，COBOL で記述されたソフトウェアに対行われる変更について調査を行った [5]．彼らの調査では，してクローンとソースファイルの改版数の関係を調査し約 88%のクローンは生成された後に全く変更がされず，クた [15]．その結果，80%以上がクローンになっているソー

ローンに対して行われる変更のうちの約 15%が不注意によスファイルや，200 行以上のクローンを含むソースファイ

る一貫性の欠如を引き起こしていたという結果であった．

ルは，他のソースファイルに比べて改版数が多くなる傾向
であることがわかった．

堀田らは，クローンに対する変更の頻度とクローンではない部分に対する変更の頻度を調査した [28]．調査対象は

コピーアンドペーストを用いた開発が望ましい場合もあ

C/C++もしくは Java で記述された 15 のオープンソース

るとの報告もされている [9]．例えば，新しい機能を追加すソフトウェアである．調査の結果，クローンはそうでない©2017 Information Processing Society of Japan

183

ソフトウェアエンジニアリングシンポジウム 2017
IPSJ/SIGSE Software Engineering Symposium (SES2017)

部分に比べて変更される頻度が少ないという結果であった．

Tsunoda らは，バグを含むモジュールの予測モデルにクローンメトリクスを組み込む場合は，複数種類の検出結果をオンライン登録系処理

JSP

オンライン更新系処理利用したほうがモデルの予測精度が良くなることを実験により示した [12]．彼らは CCFinderX，PMD s Copy/Paste

Detector，Simian，Nicad の 4 つのソフトウェアそれぞれ

コードの重複度を算出し，それを予測モデルに組み込むこオンラインバッチ集計処理
バッ

CSV

モデルの比較評価を行った．その結果，全てのクローンメ

マスター
データ

バッチマスター登録処理

マスター
データ

(a) アーキテクチャ
クライアントメトリクスを組み込んだ予測モデル，いずれのクローンメ
トリクスも組み込まない予測モデルの，計 10 種類の予測

集計データ
集

オンライン集計処理とにより評価を行った．いずれかのクローンメトリクスを組み込んだ 8 種類の予測モデルに加え，すべてのクローン

データ

オンライン一覧紹介処理

帳票

を 2 つの設定を用いてクローン検出を行い，8 種類の検出結果を得た．それぞれのクローン検出結果から対象ソース

DBサーバ

Web/APサーバ

クライアントWeb/APサーバ

JSP

サービス層 イベント層

DBサーバ

DAO

APフレームワーク

ブラウザ

DBMS

APサーバ

トリクスを組み込んだ予測モデルが最も精度が高いというOS結果であった．単一のクローンメトリクスを組み込んだ予(b) 階層構造測モデルの中には，クローンメトリクスを組み込まない予

図 1

OS

対象システムの概要

測モデルに比べて精度が劣るものも存在した．

Saini らは，クローンになっているメソッドとそうでな発を行った．このシステムは同一仕様に基づいて開発されいメソッドの間での種々のメトリクスの値が異なるのか

た，実装の異なるソフトウェアである．なお，開発時の条を調査した [21]．調査対象のメトリクスは McCabe の複雑件をできる限り揃えるために，システム開発経験が浅い新度 [13] や Halstead のソフトウェアサイエンス [6] のように人や突出したスキルを持つ有識者はこのシステムの開発によく利用される伝統的なメトリクスから，引数の数やルーは加わっていない．

プの数などのようにプログラム要素の数を単純にカウント

個々のベンダーはそれぞれテストを行い，テストをパスししたメトリクスなどさまざまであり，計 27 種が計測された最終版のソースコードが発注元に納品された．この実験

た．その結果，メソッドのサイズはクローンになっているの対象は Java で記述された業務処理部分である．最終版のメソッドのほうが約 29%小さくなるという傾向であった

ソースコード規模は約 20,000∼44,000 行 (約 15,000∼24,000

が，他のメトリクスの場合はほとんど差がないという結果

ステップ数) である．発注元でも納品されたソースコードであった．

に対してテストを行った．以降，ベンダーが行ったテスト

3. 実験の設定
本章では，対象プロジェクトやクローン検出，プロジェ
クトデータ等の実験に関する設定について記述する．

をベンダーテスト，発注元が行ったテストを受入テストと呼ぶ．ベンダーテストと受入テストはそれぞれ以下の 3 つのテストからなる．
各モジュール単体での動作を検査する

単体テスト (UT)

ためのテスト．

3.1 対象プロジェクト
図 1 は対象プロジェクトの概要を表している．このプロジェクトは Web ベースの在庫管理システムである．オン
ラインのトランザクション処理を実現するために J2EE が結合テスト (IT)

モジュール間の引数や返り値の受け渡

し，データベースを介したデータのやり取り等を検査するためのテスト．
システムテスト (ST)

システムに対して実際と同じよう利用されている．このシステムの画面数は 11，および帳票な入力を与え，システム全体が要求された仕様通りに

数は 2 であり，32 種類の処理を持つ．ファンクションポイ

動作するかを検査するためのテスト．

ント数は 113FP である．画面処理 (クライアントサイド)
は JSP，業務処理 (サーバサイド) は Java を用いて開発された．
このシステムは実験用プロジェクトであり，ある組織が仕様を作成し，異なる 9 つの組織が開発した．以降，仕様

3.2 コードクローン検出
本研究では字句単位のクローン検出を行った．字句単位のクローン検出手法は他の検出手法に比べて以下の特徴を持つ [3], [18], [27]．

を作成した組織を発注元，開発を行った組織をベンダーと• 検出の速度が速い．

呼ぶ．9 つのベンダー（VA ∼VI ）は，それぞれ独立して開• 検出結果が膨大になる傾向にある．つまり，漏れなくクローンを検出することは得意だが，検出結果には大©2017 Information Processing Society of Japan184

ソフトウェアエンジニアリングシンポジウム 2017
IPSJ/SIGSE Software Engineering Symposium (SES2017)

量の誤検出が混じる傾向がある．

ファイル1: 80LOC• 完全に同一なクローン（T PE-1）や，変数名やリテラル等が異なるクローン（T PE-2）を検出する．T PE-3

ファイル2: 60LOC

ファイル3: 40LOC
C

10
C

30

B
10

クローンの検出は得意ではない．
著者らの研究グループでは，字句単位の長所を残しつつ

10
C

20

10

30

A
20

短所を改善することを目的として，クローン検出ツール

CloneGear を開発している*1 ．CloneGear は字句単位のク
ローン検出ツールであり，現在のところ，C/++，Java，

DOC = (3+2+2)/(0.08+0.06+0.04) = 38.89

Python，PHP，JavaScript に対応している．CloneGear は

DORF = 2/(0.08+0.06+0.04) = 11.11

ROC = ((30+20+20-10)+(10+30)+(10+10))/(80+60+40) = 66.7%

以下の特徴を持つ．
特徴 1

図 2

分からのクローン検出を行わない．この特徴により，は図 2 の下部に示す式で計算される．

人間が確認する必要のない重複部分からのクローン検
出を抑制できる．
特徴 2

クローンメトリクスの計算例

連続した変数宣言文等のプログラムの繰り返し部
各プロジェクトに対して，著者らは 3 つの設定を用いてクローンの検出を行った．設定の違いは検出する最小のク

類似したコード片が字句単位よりも大きな差異をローンの大きさであり，それぞれ 50 字句，100 字句，150含んでいたとしても，その全体を 1 つのクローンとし字句以上のクローンを検出するように設定した．クローンて検出できる．この特徴により，T PE-3 クローンのの検出結果は誤検出と見逃しが少ないほど良いとされる検出能力を向上できる．

が，誤検出と見逃しはトレードオフの関係にある．誤検出

特徴 1 は，著者らが過去に提案したソースコードの繰り返を少なくするような設定を利用してクローン検出を行えばし部分を折りたたんだ上でクローンを検出する技術 [17] を見逃しが増えてしまい，見逃しを少なくするような設定で利用して実現している．特徴 2 は，Smith-Waterman アル検出を行えば誤検出が増えてしまう．

ゴリズム [22] を利用することで実現している．いずれについても著者らが過去にその有効性を実験により示してい各設定は以下の意図により用いた*2 ．

50 字句 字句単位のクローン検出でよく利用されるしきる [16], [17]．

い値である．このしきい値を用いた場合，クローンの本研究ではクローンがどれくらい存在しているかの指標

検出ツールは見逃しは少ないが誤検出が多くなる傾向

として以下の 3 つのメトリクスを用いた．対象システムのソースコード規模が異なるため，いずれも正規化された値にある [8], [19]．

100 字句 誤検出を減らす目的で用いたしきい値である．

を持つメトリクスである．

DOC (Density Of Clones) 1,000 行あたりのクローン

見逃すクローンは多くなってしまう．

150 字句 できる限り誤検出を行わない目的で用いたしきの数を表すメトリクスである．対象システムから検出い値である．さらに見逃すクローンは多くなる．

されたクローンの数を対象システムのキロ行数で除算

表 1 は上記の 3 つの設定を用いて検出したクローンからすることにより求める．

ROC (Ratio Of Clones) 対象システムを構成する字句のうち，いずれかのクローンに含まれている字句の割算出したクローンメトリクスの値を表している．すべてのメトリクスにおいて，大きなしきい値を用いるほどメトリ
クス値が小さくなっていることがわかる．

合である．クローンが全く無い場合に最小値 0%，全ての字句がクローンになっている場合に最大値 100%を3.3 プロジェクトデータ

とる．

対象プロジェクトでは，発注元およびベンダーにおいて

DORF (Density of Related Files) 1,000 行あたりのさまざまなデータが記録されていた．本研究では，定量的クローンを共有しているファイルペア数を表す．対象な値を持つ以下のデータを利用した．なお，これらのデーシステムにおいてクローンを共有しているファイルペタの利用にあたり，クローンメトリクスと高い相関がある

ア数を対象システムのキロ行数で除算することによりという仮定があるわけではない．利用可能なデータを多く求める．

利用してその中から相関があるデータを見つけることが本

図 2 は 3 つのメトリクスの計測例を表す．この例では 3
つのソースファイルがあり，ABC の 3 つのクローンのグ
ループが検出されている．ABC に含まれる各クローンの字句数は，20，30，10 である．この例では，各メトリクス*1https://github.com/YoshikiHigo/CloneGear©2017 Information Processing Society of Japan*2

50 字句は，クローン検出の研究でしばしば用いられる値である [8], [19]．100 字句および 150 字句は，著者らのこれまでのク
ローン検出の経験に基づく値である．企業で開発されたソフト
ウェアはオープンソースソフトウェアに比べてクローンの量が多い傾向がある．新規でクローン検出を行う場合は 50 字句をしきい値としてクローン検出を行い，非常に多くのクローンが検出された場合には設定を 100 字句に変更して再度クローン検出を行う，というのが通常の検出プロセスである．

185

ソフトウェアエンジニアリングシンポジウム 2017
IPSJ/SIGSE Software Engineering Symposium (SES2017)

ベンダー

表 1 クローンメトリクス値の算出結果
しきい値の字句数 50
しきい値の字句数 100

DOC

ROC

DORF

DOC

ROC

DORF

しきい値の字句数 150

DOC

ROC

DORF

VA

11.66

12.3%

3.69

2.57

7.5%

0.59

1.07

4.4%

0.27

VB

61.17

43.1%

5.24

35.93

38.7%

2.64

22.06

33.8%

1.75

VC

24.85

22.4%

6.64

7.85

18.3%

1.77

3.76

13.7%

0.89

VD

20.92

26.2%

10.56

6.30

19.1%

3.46

2.10

10.1%

0.95

VE

30.18

22.1%

10.01

10.99

18.1%

3.03

4.99

13.1%

1.78

VF

14.60

20.6%

2.81

5.93

17.3%

1.00

3.45

14.6%

0.60

VG

17.38

19.6%

9.58

5.76

15.0%

3.50

1.46

6.7%

1.49

VH

33.52

34.1%

7.95

13.62

29.4%

3.79

5.45

19.5%

2.23

VI

32.86

32.1%

3.86

15.71

29.5%

2.78

5.20

17.9%

2.42

実験のアプローチである．
規模に関するデータとして以下のものを用いた．

< ステップ数 > ソースファイルの行数を基にした値であ< ベンダー UT・IT・ST バグ密度 > ベンダーが行った
単体テスト，結合テスト，システムテストにおけるバグ密度を表す．

る．ただし，空行やコメント行は除く．
開発コストに関するデータとして以下のものを用いた．

< 開発期間 > ベンダーが開発に要した期間を表す．
< 開発工数 > ベンダーが開発に要した工数（人月）を表す．

< 規模／週 > ベンダーの開発における週あたりの実装規模を表す．

3.4 相関係数の計算
表 1 で示したクローンメトリクスと，3.3 節で示した各プロジェクトデータの相関関係を分析した．具体的には，クローンメトリクスを降順に並べた時のプロシェクトの順が，プロジェクトデータを降順に並べた時のプロジェク
トの順とどの程度同じであるのかを Spearman の順位相関テストに関するデータとして以下のテスト件数を用い係数を計算することで調査した．クローン検出の設定が 3

た．このデータは，ベンダーテストにおけるテスト件数でつあり，各検出結果について 3 つのクローンメトリクス値ある．なお，発注元が納品された各ソースコードに対してがある．そのため，各プロジェクトデータに対して 9 つの行った受入テストは同一であるため，受入テストの件数は相関係数が得られることになる．

本研究では利用しない．

< ベンダー UT・IT・ST 件数 > ベンダーが単体テス
ト，結合テスト，システムテストを行うために作成したテストの件数を表す．

4. 実験の結果
図 3 は Spearman の順位相関係数 (以降，ρ と表す) の計
算結果を表している．各プロジェクトデータに対する各ク

テストに関するデータとして以下のテスト密度も用い

ローンメトリクスにおいて，線分が表示されている．線分た．テスト密度は，ベンダーにおけるテストの件数をそのの上端と下端はそれぞれ ρ の最大値と最小値を表してい時のソースコードのステップ数で割った値である．

る．この実験では 3 つの設定を用いてクローン検出を行っ< ベンダー UT・IT・ST 密度 > ベンダーが行った単体

たため，各プロジェクトデータにおける各クローンメトリ

テスト，結合テスト，システムテストにおけるテスト

クスの ρ は 3 つ存在する．中央値は × で示されている．ク

密度を表す．

ローンメトリクス名に付随しているアスタリスクの数は，バグに関するデータとして以下のバグ数を用いた．ベン

その線分を構成する ρ の p 値が 0.017 以下であった数を表

ダーテストに加えて，受入テストについてもバグ数のデーしている．0.017 を用いた理由は (1 − 0.017)3  0.95 とな

タを利用した．

るからである．つまり，3 つの検定結果に 1 つも偶然の結< ベンダー UT・IT・ST バグ数 > ベンダーが行った単果が含まれていないことが 95%以上の確率であるために

体テスト，結合テスト，システムテストにおいて発見

は，個々の検定結果は 98.3%以上の確率で偶然でないことされたバグの数を表す．

が求められるため，0.017 を用いた．各線分には 3 つの ρ

< 受入 UT・IT・ST バグ数 > 発注元が行った単体テスの値が含まれるため，アスタリスクの数は最大で 3 となる．

ト，結合テスト，システムテストにおいて発見された

本実験では，|ρ| が 0.4 以上のときにプロジェクトデータとバグの数を表す．

クローンメトリクスの間に相関があるとし，相関がある場

バグに関するデータとして，以下のバグ密度も用いた．

合をさらに以下のように 3 つに分類した．

バグ密度は，ベンダーテストにおいて，発見されたバグの強い相関 0.9 ≤ |ρ|

数をその時のソースコードのステップ数で割った値である．

中程度の相関 0.7 ≤ |ρ| < 0.9©2017 Information Processing Society of Japan186

ソフトウェアエンジニアリングシンポジウム 2017
IPSJ/SIGSE Software Engineering Symposium (SES2017)














































































































図 3




























































































  

クローンメトリクスとプロジェクトデータ間の相関係数の計算結果(アスタリスクの数は p 値が 0.017 以下であった検定の数を表している)

弱い相関 0.4 ≤ |ρ| < 0.7
図 3 では，正の相関部分は青，負の相関部分は赤で示さ• ベンダー UT バグ密度 (DORF)• ベンダー IT バグ密度 (DORF)

れており，相関が強いほど濃く強調表示されている．この以上のことから，ソフトウェア開発プロジェクトとク

実験では，7 つのプロジェクトデータが有意水準 0.017 にローンの存在には以下のような関係があると著者らは考おいていずれかのクローンメトリクスと正または負の相関えた．

があるという結果であった．

開発速度 規模／週と ROC に相関があった．これはソー以下のプロジェクトデータはいずれかのクローンメトリ

スコードが重複している割合が高いほど，週あたりのクスと有意に強い相関があったものである．括弧内は強い

実装規模が大きいことを表している．クローンの生成相関があったクローンメトリクスを表す．

理由がコピーアンドペーストであると仮定すれば，コ• 受入 UT バグ数 (DORF)• 受入 IT バグ数 (DOC)

ピーアンドペーストによるコードの再利用が実装のス
ピードの向上に貢献していると考えることができる．

以下は有意に中程度の相関があったプロジェクトデータで結合テスト 受入 IT バグ数と DOC および ROC に相関がある (有意に強い相関があったプロジェクトデータを除く)．

あった．これは，クローンの量が多いほど，受入結合• 規模／週 (ROC)

テストにおいて多くのバグが検出される傾向であるこ• ベンダー UT 件数 (DORF)とを表している．つまり，クローンの量が多いとベン• ベンダー IT バグ数 (DORF)

ダーの結合テストにおいてバグを見逃す傾向にあるこ• 受入 IT バグ数 (ROC, DORF)とがわかる．

©2017 Information Processing Society of Japan187

ソフトウェアエンジニアリングシンポジウム 2017
IPSJ/SIGSE Software Engineering Symposium (SES2017)

また DORF がベンダー IT バグ数およびベンダー ITに基いて開発された 9 つのシステムであり，すべて別の

バグ密度と正の相関があった．言葉を変えれば，ク

組織によって開発された．実験の結果，以下のことが判明

ローンを共有しているファイルの数が多いと，ベンした．

ダーにおける結合テストが良く実施されている傾向で• クローンの量が多いほど，実装スピードが早い傾向にあることを表している．

ある．

単体テスト ベンダー UT 件数およびベンダー UT バグ密

• クローンの数が多くソースコードの重複度が高いほ

度と DORF に負の相関があった．多くのファイルがど，ベンダーにおける結合テストで多くのバグが見逃クローンを共有していると，ベンダーにおいて単体テされてる傾向にある．

ストの達成度が低い傾向にあることを表している．受• 多くのファイルがクローンを共有しているほど，ベン入 UT バグ数と DORF の正の相関は，ベンダー単体

ダーにおける単体テスト数が少なくなり検出されるバテストにおいて見逃されたバグが受入単体テストで多グの数も減る傾向にある．しかし，興味深いことにベく見つかったことを表している．

ンダーにおける結合テスト数は多くなり検出されるバクローンの存在が結合テストと単体テストに与える負のグの数は多くなる傾向にある．

影響は，「テストされたコードをコピーアンドペーストした

この結果より，クローンの検出結果はテストの実施状況

場合はコピー先のコードは十分にテストしなくても良い」の確認に利用できると著者らは考えた．具体的には，多数という開発者の先入観が原因ではないかと著者らは考えてのクローンが検出された場合やソースコードの大部分がクいる．

ローンだった場合には結合テストの実施状況を確認した

以上のことから，クローンの検出結果は以下のようにテストの実施状況の確認に利用できると著者ら考えた．

り，多くのファイルがクローンを共有していた場合には単体テストの実施状況を確認したり，という作業がテストが• 多数のクローンが検出された場合やソースコードの大不十分な状態でソフトウェア開発が次の工程に移行してし部分がクローンである場合は，結合テストが十分に実まうことを予防する 1 つの手段となりうることを示した．

施されているかを確認する．

• 多数のファイルがクローンを共有している場合は単体
テストが十分に実施されているかを確認する．

5. 実験の妥当性について

今後の研究方針として，著者らは DORF メトリクスについてさらに調査を行うことを計画している．このメトリ
クスはクローンの量そのものではなく，クローンを共有しているファイルの数を表している．DORF が高い場合は多くのファイルがクローンを共有していることを意味してい本実験では有意水準 0.017 のもとで検定を行った．これる．著者らは DORF メトリクスがソフトウェアの設計のは，用いたクローンの検出結果が 3 つあり，その全てが偶

粗悪さを表しているのではないかと考えており，今後この然の結果ではないことを 95%担保するための設定である．

メトリクスの有用性について研究を行う予定である．

また，本実験では 57 の相関係数 (19 のプロジェクトデー
タと 3 つのクローン検出結果) を算出した．そのため，FDR

参考文献

法のような多重検定法を用いるのも 1 つの方法であっただ

[1]

ろう．
実験対象で利用した 9 つのシステムは，見つかったバグの位置についてはファイル単位の情報のみを含んでいた．

[2]

そのため，各バグがクローンの内部に存在していたのか，
クローンとそうでない部分の境界に存在していたのか，クローンとは関係のない部分に存在していたのかは不明で

[3]

ある．
今回の実験は 1 つの対象プロジェクト群にしか適用できていない．そのため今回の実験結果がどの程度他のプロ[4]

ジェクト群に対して当てはまるかは現在のところ不明である．

6. おわりに
本論文では，プロジェクトデータとクローンの相関関係を分析した結果について報告した．分析対象は同一の仕様©2017 Information Processing Society of Japan[5]

Barbour, L., Khomh, F. and Zou, .: An Empirical
Study of Faults in Late Propagation Clone Genealogies,
Journal of Software: Evolution and Process, Vol. 25,
No. 11, pp. 1139–1165 (2007).
Baxter, I. D., ahin, A., Moura, L., Sant Anna, M. andBier, L.: Clone Detection Using Abstract Syntax Trees,
Proceedings of the International Conference on Software Maintenance, pp. 368–377 (1998).
Bellon, S., Koschke, R., Antoniol, G., Krinke, J. andMerlo, E.: Comparison and Evaluation of Clone Detection Tools, IEEE Transactions on Software Engineering, Vol. 33, No. 9, pp. 577–591 (2007).
Chatterji, D., Carver, J. C., Massengil, B., Oslin, J. andKraft, N. A.: Measuring the Eﬃcacy of Code Clone Information in a Bug Localization Task: An Empirical
Study, Proceedings of the 2011 International Symposium on Empirical Software Engineering and Measurement, pp. 20–29 (2011).
Göde, N. and Koschke, R.: Fre uency and Risks of
Changes to Clones, Proceedings of the 33rd International Conference on Software Engineering, pp. 311–320(2011).

188

ソフトウェアエンジニアリングシンポジウム 2017
IPSJ/SIGSE Software Engineering Symposium (SES2017)

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

Halstead, M. H.: Elements of Software Science (Operating and Programming Systems Series), Elsevier Science
Inc. (1977).
Inoue, K., Higo, ., oshida, N., Choi, E., Kusumoto, S.,
Kim, K., Park, W. and Lee, E.: Experience of Finding
Inconsistently-changed Bugs in Code Clones of Mobile
Software, Proceedings of the 6th International Workshop on Software Clones, pp. 94–95 (2012).
Kamiya, T., Kusumoto, S. and Inoue, K.: CCFinder: A
Multilinguistic Token-based Code Clone Detection System for Large Scale Source Code, IEEE Transactions
on Software Engineering, Vol. 28, No. 7, pp. 654–670(2002).
Kapser, C. J. and Godfrey, M. W.: ”Cloning Considered Harmful” Considered Harmful: Patterns of Cloningin Software, Empirical Software Engineering, Vol. 13,
No. 6, pp. 645–692 (2008).
Li, Z., Lu, S., Myagmar, S. and 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).
Lozano, A. and Wermelinger, M.: Assessing the Eﬀect ofClones on Changeability, Proceedings of the 24th International Conference on Software Engineering, pp. 227–236 (2008).
Masateru Tsunoda, asutaka Kamei, A. S.: Assessing
the Diﬀerences of Clone Detection Methods Used in
the Fault-prone Module Prediction, Proceedings of the10th Internal Workshop on Software Clones, pp. 15–16(2016).
McCabe, T. J.: A Complexity Measure, IEEE Transactions on Software Engineering, Vol. 2, No. 4, pp. 308–
320 (1976).
Mondal, M., Roy, C. K., Rahman, M. S., Saha, R. K.,
Krinke, J. and Schneider, K. A.: Comparative Stabilityof Cloned and Non-cloned Code: An Empirical Study,
Proceedings of the 27th Annual ACM Symposium on
Applied Computing, pp. 1227–1234 (2012).
Monden, A., Nakae, D., Kamiya, T., Sato, S.-i. and Matsumoto, K.-i.: Software Quality Analysis by Code Clones
in Industrial Legacy Software, Proceedings of the 8th International Symposium on Software Metrics, pp. 87–94(2002).
Murakami, H., Hotta, K., Higo, ., Igaki, H. andKusumoto, S.: Folding Repeated Instructions for Improving Token-Based Code Clone Detection, Proceedings of the 12th International Working Conference on
Source Code Analysis and Manipulation, pp. 64–73(2012).
Murakami, H., Hotta, K., Higo, ., Igaki, H. andKusumoto, S.: Gapped Code Clone Detection with
Lightweight Source Code Analysis, Proceedings of the
21st International Conference on Program Comprehension, pp. 93–102 (2013).
Rattan, D., Bhatia, R. and Singh, M.: Software Clone
Detection: A Systematic Review, Information and Software Technology, Vol. 55, No. 7, pp. 1165–1199 (2013).
Roy, C. K. and Cordy, J. R.: NICAD: Accurate Detection of Near-Miss Intentional Clones Using Flexible
Pretty-Printing and Code Normalization, Proceedings ofthe 16th International Conference on Program Comprehension, pp. 172–181 (2008).
Roy, C. K., Cordy, J. R. and Koschke, R.: Comparison and evaluation of code clone detection techni ues
and tools: A ualitative approach, Science of Computer©2017 Information Processing Society of Japan

[21]

[22]

[23]

[24]

[25]
[26]

[27]

[28]

[29]

Programming, Vol. 74, No. 7, pp. 470–495 (2009).
Saini, V., Sajnani, H. and Lopes, C.: Comparing Quality Metrics for Cloned and non cloned Java Methods:
A Large Scale Empirical Study, Proceedings of the 32nd
International Conference on Software Maintenance andEvolution, pp. 256–266 (2016).
Smith, T. F. and Waterman, M. S.: Identiﬁcation ofCommon Molecular Subse uences, Journal of Molecular Biology, Vol. 147, No. 1, pp. 195–197 (1981).
amanaka, ., Choi, E., oshida, N., Inoue, K. andSano, T.: Applying Clone Change Notiﬁcation System
into an Industrial Development Process, Proceedings ofthe 21th International Conference on Program Comprehension, pp. 199–206 (2013).
Zhao, W., Xing, Z., Peng, X. and Zhang, G.: Cloning
Practices: Why Developers Clone and What Can Be
Changed, Proceedings of the 28th International Conference on Software Maintenance, pp. 285–294 (2012).
神谷, 肥後, 吉田：コードクローン検出技術の展開，コン
ピュータソフトウェア，Vol. 28, No. 3, pp. 28–42 (2011).
肥後, 楠本：コード修正履歴情報を用いた修正漏れの自動検出，情報処理学会論文誌，Vol. 54, No. 5, pp. 1686–1696(2013).
肥後, 楠本, 井上：コードクローン検出とその関連技術，
電子情報通信学会論文誌 D，Vol. J91-D, No. 6, pp. 1465–
1481 (2008).
堀田, 佐野, 肥後, 楠本：修正頻度の比較に基づくソフト
ウェア修正作業量に対する重複コードの影響に関する調査，情報処理学会論文誌，Vol. 52, No. 9, pp. 2788–2798(2011).
堀田, 肥後, 楠本：生成防止，分析効率化，不具合検出を中心としたコードクローン管理支援技術に関する研究動向，コンピュータソフトウェア，Vol. 31, No. 1, pp. 14–29(2014).

189