Vol.2017-SE-197 No.7
2017/11/9

情報処理学会研究報告
IPSJ SIG Technical Report

コードクローンに対するリファクタリング可能性に基づいた
削減可能ソースコード量の調査
石津 卓也1,a)

吉田 則裕2崔 恩瀞3

井上 克郎1

概要：コードクローンとは，ソースコード中に存在する互いに一致または類似した部分を持つコード片のことである．また，集約とは，コードクローンを 1 つのメソッドやクラスなどにまとめることである．
集約によりコードクローンの行数は削減される．集約で削減できるコードクローン行数を推定するとき、
コードクローン片間での重複やリファクタリング可能性を考慮することで，より正確に測定できる．本稿では，クローンペア（コードクローンの関係にある 2 つのコード片）に対してリファクタリング支援ツー
ル JDeodorant のリファクタリング可能性判定機能を用いて，オープンソースソフトウェアを対象とした削減可能ソースコード量の推定を行った．その結果，検出されたコードクローン行数のおよそ 6%が削減可能で，クローンセット数にすると全体の 19%ほどが集約対象になることが明らかになった．
キーワード：コードクローン，リファクタリング可能性，削減可能ソースコード量

Investigating the amount of reducible source code based on the
refactorability of code clones
Takuya Ishizu1,a)Norihiro Yoshida2

1. まえがきEunjong Choi3

Katsuro Inoue1

として集約と呼ばれる手法が存在する．集約は互いにコー
ドクローンの集合 (以下，クローンセットと呼ぶ) に対し

ソースコード行数が開発や修正によって増大するにつれて，プログラムの振る舞いを保ちながらメソッドやクラスてソフトウェアの保守は困難になる傾向にある．コード行を作成し元のコードクローンから呼び出すことによって数の増大の一因には開発者がソースコード作成を効率良くコードクローンを削除する修正手法である．集約を行うに進めるためにコピーアンドペーストなど多用によって発はコストや手間といったコストが必要になるため，開発者

生するコードクローンが挙げられる [4][7]．コードクロー

は集約を行う動機となる指標が必要となる，ンとは，ソースコード中に存在する一致，または，類似し本稿では，その指標として開発者を支援する削減可能

た部分を持つコード断片のことである．コードクローンのソースコード量を定義した．削減可能ソースコード量は，削減はソースコード行数の削減に繋がると考えられるた

コードクローンに対して集約手法を適用してコードクロー

め，多くのコードクローンに関する既存研究が行われてきンを削除して減少する行数の推定値である．ただし，削減

た [1][4][6][10][11]．コードクローンの削減に貢献する手法

可能ソースコード量の算出には 2 つの解決すべき課題が存在する．1 つ目の課題は検出されたコードクローンの存在

大阪大学
Osaka University
名古屋大学
Nagoya University
奈良先端科学技術大学院大学
Nara Institute of Science and Technology
t-ishizu@ist.osaka-u.ac.jp

範囲が別の異なるコード片を持つコードクローンと重複す

c 2017 Information Processing Society of Japan
⃝

1

1

2

3

a)

るオーバーラップと呼ばれる現象が生じる点である．オー
バーラップ下における複数のクローンセットに対する集約の実作業を緻密に行おうとするのは非常に労力がかかる恐Vol.2017-SE-197 No.7
2017/11/9

情報処理学会研究報告
IPSJ SIG Technical Report

れがあり，本稿ではこの課題を解決するために，大まかな
コードクローン

集約手法を採用するものとして，削減可能ソースコード量
ファイルAを算出することとした．なお，コードクローン検出ツール

ファイルB

は存在範囲が部分的に異なる多様なコードクローンを検出するため，オーバーラップに関する問題を避けて削減可能
ソースコード量を算出することはできない．2 つ目の課題
集約

は，コードクローンのリファクタリング可能性である．本
稿では，この課題を解決するために，検出したクローンペ

呼び出し文
ファイルA

ア（コードクローン関係にある 2 つのコード片）に対して，

ファイルB

ファイルC

リファクタリング支援ツール JDeodorant のリファクタリ

共通のメソッド

ング可能性判定機能を利用して問題の解決を図った．本稿
ではこれらの課題を解決することで，より正確な削減可能
ソースコード量を算出する手法として提案する．
調査方法では，コンパイル可能であった 7 つの Java プロ

図 1

コードクローンとその集約例の図

ジェクトに対して削減可能ソースコード量の調査を行った．
具体的に，まず，コードクローン検出ツール CCFinderX[9]えば，コード片に修正が加えられる場合，それとコードクを用いてコードクローンを検出する．次に，JDeodorant

ローンになっているすべてのコード片に対して一貫性のあのリファクタリング可能性判定機能は検出されたクローン

る修正を検討する必要性を求める．これは修正の検討漏れ

ペアごとにリファクタリング可能性を評価する．リファクが動作の不具合を発生させる可能性を秘めているためでタリングが不可能なコードクローンを集約候補から除外す

ある．

る．さらにオーバーラップしているコードクローンに関し以上の困難さを解決するには開発者はコードクローンのてもメタヒューリスティック [3][12] を利用して除外する．

所在を逐一把握する必要がある．そのコードクローンのメタヒューリスティクスとは，特定の問題に依存しない，

所在はコードクローン検出ツールによって検出可能であ

組み合わせ最適化問題における近似解を求める解法をもつる [5][8][14]．しかし，大規模なソフトウェア開発においてアルゴリズムの基本的な枠組みである．こうしたリファク

常にコードクローンの発生を監視する必要があり，非常にタリング可能性とオーバーラップに関する 2 つのフィルタ

煩雑な作業が伴うと予想される．そこでコードクローンをリングで除外されなかったコードクローンに対して削減可

共通のメソッドやクラスにまとめて，コードクローンは呼能ソースコード量を算出した．

び出し文に置換して削減する操作として集約という手法が

2. 背景
2.1 コードクローン

考案されてきた．
図 1 は二つのファイル A，B から検出されたタイプ 1 あ
るいはタイプ 2 のコードクローンを集約した例を表していコードクローンとは，ソースコード中に存在する一致，まる．コードクローンを図 1 では，ファイル C にまとめてたは，類似した部分を持つコード断片のことである [4][7]．

いる．ただし，どこに共通のコード片をまとめるのか判断

また，コードクローン関係にある二つのコード片をクローするには，各コードクローンが存在する階層構造や継承関

ンペアと呼び，コードクローンの集合をクローンセットと係などを考慮する必要があり，必ずしも新しいファイルの呼ぶ．また，コードクローンには 3 つのタイプが存在する．

作成を推奨しているわけではない．集約されたメソッドにタイプ 1 は空白行やコメント行などのコーディングスタイ

は，メソッドの導入文と終了文の 2 行を新たに加える必ルを除いて完全に一致するコード片を持つ．タイプ 2 は変要がある．また，プログラムの振る舞いを保つためにコー数名や関数名，変数の型などの識別子のみが異なるコード

ドクローンであったコード片を共通化したメソッドを呼クローンである．そして，タイプ 3 はタイプ 2 である上にび出す文に置換する．なお，タイプ 3 のコードクローンの命令文の挿入や削除，変更が行われたコードクローンを指集約はさらなる工夫が必要になるため，本研究では取り扱

す．コードクローンの主要な発生原因にはソフトウェアのわず今後の課題としたい．最後に本稿では，これら以外の開発時や修正時に開発者が作業効率の向上を目的とした

import 文やコメント文などのプログラムの本質に関わら既存のコード片のコピーアンドペーストが挙げられる．コないと想定される追加行数については考えないものとしてピーアンドペーストによって作成されたコードクローンは議論する．

類似の機能を開発する際に作業効率の代償としてソース
コード行数を増大させてしまう傾向がある．そして，ソー
スコード行数の増大はソフトウェア保守を困難にする．例

c 2017 Information Processing Society of Japan⃝

2.2 削減可能ソースコード量
コードクローン検出ツールを用いて検出されたコードク

2Vol.2017-SE-197 No.7
2017/11/9

情報処理学会研究報告
IPSJ SIG Technical Report

ローンを集約する過程で，開発者は各コード片の所在や階

表 1 オーバーラップしているコードクローン例
行番号1-1
2-1 2-2
3-1
プログラム文層構造に着目をしてソフトウェア全体の振る舞いを変えな
いように慎重に作業を進める必要がある．このような作業に必要なコストや手間といった労力に対して見合う成果が得られるのか判断する指標が重要である．すなわち，開発

1

+

+

if(bool1){

2

+

+

...

3

+

+

}

4

+

+

if(bool2){

者は指標を見て対価に見合うと判断すれば，ソフトウェア

5

+

+

...

に存在する冗長なコード片を整理するための作業を積極的

6

+

+

に行えると考えられる．本稿では，その指標として削減可

7

+

+

while(roop){

能ソースコード量を定義している．削減可能ソースコード

8

+

+

...

量とは，仮にコードクローンを集約した場合に，コードク

9

+

+

}

}

ローンの削除によって元のソースコードから減少するであろうソースコード行数の推定値を表す．具体的な計算手法
は次章で説明する．
ソフトウェア全体から検出されたコードクローンの削減
可能ソースコード量を求めるには，これから詳細に説明す( 2 ) c1 の開始トークン番号が c2 の開始トークン番号より前に存在して，かつ c1 の終了トークン番号が c2 の終了トークン番号より前に存在していながら c2 とオー
バーラップする場合．

る 2 つの課題を解決する条件を満たしたすべてのクローン( 3 ) c1 の開始トークン番号が c2 の開始トークン番号よりセットについて，数式 T (S) の総和によって求められる．2

前に存在して，かつ c1 の終了トークン番号が c2 の終つの課題については次の 2 つである．

了トークン番号より後ろに存在していながら c2 とオー

2.2.1コードクローンのオーバーラップ

バーラップする場合（c1 が c2 を内包している）．

2.2.2 コードクローンのリファクタリング可能性

これらの位置関係に加えて，c1 と c2 を入れ替えれば 6 通詳細は次項以降で説明する．

りになる．

2.2.1 コードクローンのオーバーラップ

表 1 は，オーバーラップが発生するような代表的なソー1 つ目の課題はコードクローンのオーバーラップである．

スコードを簡潔に表現したものに対して，3 つのクローン

トークンに基づいたコードクローン検出ツールは，異なるセットにそれぞれ属する四つのコードクローンについて対トークン列ではあるものの存在範囲が重複しているコード

応する関係を示している．各クローンセットおよびコード

クローンを複数検出する．異なるトークン列を持っているクローンには互いに識別するために ID が割り振られておので別コードクローンとして扱えて，それぞれで削減可能

り，例えば，1 − 1 はクローンセット ID1 のクローンセット

ソースコード量を算出できるのだが，存在範囲が重複しての中でクローン ID（CID）1 に割り振られたコードクローいるためオーバーラップしているクローンは同時に集約でンであることを示している．プログラムは 2 つの IF 文（1きない．また，クローンセットに属するコードクローンが行目から 3 行目と 4 行目から 6 行目）と一つの WHILE 文

別のクローンセットに属するコードクローンとオーバー（7 行目から 9 行目）によって構成されている．クローン

ラップしている時，それらのクローンセットはオーバー

検出器は検出条件としてしきい値などを満たしているコー

ラップしていると表現する．

ドクローンであれば，表 1 のように 3 つのクローンセット

コードクローン c1 と c2 のオーバーラップ関係は次の数に分けて検出する可能性がある．このとき，クローンセッ

式で表現される．ただし，2 つのコードクローンは同一ファ

ト ID1 と ID2，ID1 と ID3 はそれぞれオーバーラップしてイル内に存在していて，どちらもクローン検出ツールなどいる．

で開始トークン番号と終了トークン番号が判明しているも2.2.2 コードクローンのリファクタリング可能性のとする．

(tend (c2 ) − tbegin (c1 ))(tend (c1 ) − tbegin (c2 ))2 つ目の課題はコードクローンのリファクタリング可能性である．コードクローン検出ツールが検出するコード片
は条件分岐やクラス階層などは考慮されていない．例えこの数式が 0 以上であるならば，2 つのコードクローン

ば，集約されたメソッドの返り値は最大で 1 つの型しか持はオーバーラップしている．負の数であるならば，2 つのてないが，コードクローンによっては条件分岐によって必

コードクローンはオーバーラップしていない．tend (c) とずしも同じ型の返り値を持つとは限らない．あるいは，そtbegin (c) はそれぞれコードクローン c の開始トークン番号

れぞれのクラスがディレクトリ構造で見たときに非常に離と終了トークン番号を指している．この数式は 2 つのコー

れていれば，その集約で考慮しなければならない制約条件

ドクローンの 6 通り存在する位置関係全てに対応している．

は複雑になる．このような複雑な要因を抱え込まないコー( 1 ) c1 の開始トークン番号が c2 の開始トークン番号より

ドクローンをリファクタリング可能であるとする．ただ前に存在して，c2 とオーバーラップしない場合．

し，コードクローンのリファクタリング可能性はプログラ

c 2017 Information Processing Society of Japan⃝3

Vol.2017-SE-197 No.7
2017/11/9

情報処理学会研究報告
IPSJ SIG Technical Report

ム言語の機能に大きく依存すると考えられる．そのため，

c∗size + 2 の部分であり，ここでは抽出されたメソッドの行

リファクタリング可能性を考える際には対象とするプログ数を表している．+2 と加えられているのは，メソッドのラミング言語を事前に決定する必要がある．本稿では，前

導入文および終了文を考慮しているためである．なお，こ述にある通り Java 言語を対象としている．

こでの計算は主に Java 言語を対象としているが，ほかのTsantalis らは Java 言語ソフトウェアを対象として検出されたコードクローンのリファクタリング可能性に関する言語では必ずしも 2 行の追加でサブルーチンの記述が完了するわけではないことに気を付けたい．

研究 [13] を行っている．彼らは，Java 言語で記述された

2 つ目の式は n であり，これはすべてのコードクローン

ソフトウェアから検出されたクローンペアを入力として，のコード片を呼び出し文に置換した場合に必要な行数と想そのクローンペアのリファクタリング可能性について判断定している．ここでも，本質的には呼び出し文は 1 行で完するための条件の洗い出しや手法が提案している．また，結するものとしているが，他の言語では必ずしもそうでは

彼らは提案手法に基づいて Eclipse プラグイン JDeodorant

ない．これら 2 つの計算部分がコードクローン削除によるを開発した．JDeodorant はリファクタリングを支援する

ソフトウェアの振る舞いの変更を防ぐための記述に必要なツールの機能としてリファクタリング可能性の判断が可能

最低限の行数である．よって，元のコードクローンの行数である．そのツールは複数のコードクローンがリファクタとこれらの差が削除可能ソースコード量である．

リング可能になるのに必要な制約条件とネスト構造木，プ
ログラム依存グラフを利用することによりリファクタリン

3.2 コードクローンのオーバーラップ

グ可能性を評価していて，非常に高い精度で評価が可能に

オーバーラップの問題を解決するために，いくつかのなっている．本研究では，コードクローンのリファクタリ手法が提案された．1 つ目はオーバーラップが存在しない

ング可能性の問題を解決するために JDeodorant のリファ

コードクローン検出，例えば，メソッド単位のコードク

クタリング可能性判定機能を使用した．

ローン検出を行うという案である．2 つ目に，Edwards III
ら [2] によって提案された手法で，オーバーラップしている

3. 削減可能ソースコード量の算出方法

コード片間で，そのオーバーラップしているクローンセッ

3.1 削減可能ソースコード量トの組み合わせに応じて新たなコードクローンへと分割しある 1 つのクローンセット S に属する n 個のコードクていく手法である．2 つ目の手法では，表 1 はクローンセッ

ローン ci を入力として得られる削減可能ソースコード量ト ID2 と ID3 を集約することになる．最後に，オーバー

T (S) は次の数式 (1)〜(3) によって与えられる．

ラップしているクローンセットの中から，削減可能ソース

size(c) = lend (c) − lbegin (c) + 1
c∗size =1nn∑

コード量に基づいて集約すべきクローンセットの組み合わ(1)

せを求める手法である．本稿では，3 つ目の集約すべきク
ローンセットの組み合わせを求める手法を採用した．これ

size(ci )

(2)

ci ∈S

T (S) = n ∗ c∗size − (c∗size + 2 + n)には，次の 2 つ理由があるから 3 つ目の手法が適していると判断したためである．

(3)

数式 (1) について，size(c) はコードクローン c が存在す

• コードクローン検出ツールに依存しない．
• 集約の手法はできる限り簡潔なものにする．

る行数を表していて，lend (c) と lbegin (c) はそれぞれコー

次に，集約すべきクローンセットの組み合わせを求める

ドクローン c の終了行番号と開始行番号を示している．こ

手法について説明する．まず，クローンセットの組み合わ

れらの情報はクローン検出ツールによって得られる．数式

せを考えなければならない理由について説明する．クロー(2) は，n 個のコードクローンの平均行数 c∗size を示していンセットがオーバーラップしている時には一部のコード片

る．これは同じコードクローンであっても，開発者ごとにが集約できなくなるため，集約するクローンセットの取捨

改行などの好みのコーディングスタイルが存在するために選択をする必要がある．表 1 では，クローンセット ID1 だ

必ずしもすべてのコードクローンが同じ行数を持っていなけを集約するのか，クローンセット ID2，ID3 を集約するいと想定しているためである．そのため，平均的なコードのでは変換された後のソースコードに違いがある．削減可∗クローン c を導入した．

能ソースコード量の算出で説明した通り，呼び出し文の数

数式 (3) で求められる削減可能ソースコード量はマイナや集約されたメソッドの追加行数に差異が生まれる．また，

ス記号を境目にその前後で別々のソースコードの状態を計

表 1 のプログラム文だけではクローンセット全体の削減可算している．マイナス記号より前では，元のソースコード

能ソースコード量が算出できない．すなわち，表 1 だけでに含まれるクローンセット S に属する n 個のコードクロー

は，クローンセット ID1 だけを集約する組み合わせを選ん

ン ci 全体のソースコード量を表している．マイナス記号

だ方が削減可能ソースコード量は大きくなるが，クローン

より後では，2 つの観点で計算がなされている．1 つ目はセット ID2，ID3 を集約した方が，コード片の粒度がより

c 2017 Information Processing Society of Japan⃝4

Vol.2017-SE-197 No.7
2017/11/9

情報処理学会研究報告
IPSJ SIG Technical Report

小さいために多くのコード片に適用可能なので，削減可能

している [13]．その代表的な制約を以下の通りである．

ソースコード量が大きくなる可能性が秘められていること( 1 ) 変数のパラメータ化の際に制御依存，データ依存，反に留意したい．これらが集約するクローンセットの組み合

復操作や出力の振る舞いに変更があってはならない．

わせを考えなければならない理由である．

( 2 ) それぞれ異なる子クラス型をもつ変数は，共通の親ク

これらの組み合わせを素直に全通り計算する場合，k 個

ラスで宣言されているか，あるいはオーバーライドさのオーバーラップが含まれる時に全通りの組み合わせを計れたメソッド内でのみ呼び出されている必要がある．

k

算するのに必要な時間計算量は O(2 ) である．実際はこれよりも計算量が低くなる傾向にあるが，それでも大規模なソフトウェアを対象にした場合に，非常に厳しい実行時間が求められることになる．
そこで本稿では，膨大な時間計算量を落としながらもある程度の精度を保つためにメタヒューリスティックな手法を採用した [3][12]．メタヒューリスティクスとは，特定の問題に依存しない，組み合わせ最適化問題における近似解( 3 ) フィールド変数のパラメータ化は，その値が不変の時のみ可能である．

( 4 ) メソッド呼び出しのパラメータ化は，void 型を返さない時のみ可能である．

( 5 ) 抽出されたメソッドは，2 つ以上の変数を返していはならない．

( 6 ) 条件付き return 文がコードクローンのコード片に含
まれてはならない．

を求める解法をもつアルゴリズムの基本的な枠組みである．

( 7 ) 分岐処理を意味する命令文（BREAK，CONTINUE）

我々の先行研究 [15] では，Java 言語のオープンソースソがあれば，それに対応する反復命令文がコード片に含フトウェア（以下，OSS とする）に対してメタヒューリス

まれていなければならない．

ティックを利用し，削減可能ソースコード量を推定を行っ

本研究ではタイプ 1 とタイプ 2 のコードクローンを集約対ている．その研究においてメタヒューリスティックなアル象としているために，タイプ 3 のコードクローンについて

ゴリズムは 4 つ使用されている．提案されているアルゴリ

扱っている制約の記載は省略した．JDeodorant はクロー

ズムの中で，本研究では貪欲法の利用を採用した．これら

ンペアに対してネスト構造木やプログラム依存グラフを利の 4 つのアルゴリズムによる推定値の差はほぼないが，本用してクローンペアのコード片間の対応関係を調べて差異研究では実行時間が特に短い貪欲法を採用した．

ある変数などをパラメータ化することで新たなメソッドに

なお，貪欲法によるクローンセットの組み合わせを決定

共通のコード片を抽出できるようにする．

するアルゴリズムについて説明する．貪欲法の方針は各要

JDeodorant のリファクタリング可能性判定機能を実行

素を評価値順にソートをして，評価値の高い順番に制約がするには，Java 言語で記述されたソースコードに対する特許す限り解の候補に加える．本手法の場合，要素に相当す

定のコードクローン検出ツールの検出結果が必要になる．

るクローンセットにおける評価値および制約について説明

ただし，対象のプロジェクトは Eclipse 上でコンパイル可する．評価値は削減可能ソースコード量である．削減可能能である必要がある．JDeodorant のリファクタリング可

ソースコード量が大きいほどそのクローンセットは集約後能性の評価結果はクローンペア単位で出力される．すなわに削減できるソースコードの行数が多いということにな

ち，同じクローンセットに属しているコードクローン間にる．また，制約がクローンセット間のオーバーラップになおいて，リファクタリング可能なクローンペアが存在すれる．1 つのクローンセットを解の候補に加えれば，そのク

ばリファクタリング不能なクローンペアも存在している

ローンセットとオーバーラップしているクローンセットは可能性がある．そこで，本研究ではクローンセットを 3 パ

除外される．

ターンに分類した．3 パターンについては次節で説明する．

最後にオーバーラップにおける考慮をしなければならな
い現象がある．クローンセットのオーバーラップには，13.4 算出手法

つのクローンセット内で生じるものもある．この現象は

本研究で用いた削減可能ソースコード量の算出手法につSWITCH 文など同じ命令文が連続しやすいコード片で生いて説明する．以下にプロジェクトごとの削減可能ソース

じやすい．同じ命令文が続くコード片であるため，コード

コード量を算出する 5 つの手順を示す．

片を分割すれば集約できそうではあるが，本研究ではこの

Step1

Eclipse 上に対象プロジェクトをコンパイルする．

ような現象が起きるクローンセット自体は除外するものとStep1 では，JDeodorant の利用のために Java プロジェ

する．これは削減可能ソースコード量の算出手法に適用でクトをコンパイルする．JDeodorant は Eclipse 依存がきない高度な集約である可能が高いためである．

強いプラグインとして開発されたツールである．そのため，Eclipse 上でプロジェクトをコンパイルできる

3.3 コードクローンのリファクタリング可能性
Tsantalis らはリファクタリング可能なクローンペアにいくつかの制約を課す形でリファクタリング可能性を評価

c 2017 Information Processing Society of Japan⃝必要がある．

Step2 コードクローン検出ツール CCFinderX によってコードクローンを検出する．

5Vol.2017-SE-197 No.7
2017/11/9

情報処理学会研究報告
IPSJ SIG Technical Report

Step2 では，トークンに基づいたコードクローン検出

欲法を用いて解の候補を選択する．そして，選択した

ツール CCFinderX を利用する．JDeodorant はいくつ解の候補であるクローンセットの削減可能ソースコー

かのコードクローン検出器のサポートしている．本研

ド量の和をプロジェクト全体の削減可能ソースコード

究では，CCFinderX を用いてコードクローンを検出

量とする．

する．

Step3 コードクローン検出ツールの出力結果を入力として，JDeodorant による各コードクローンのリファク4. 調査実験
この章では，Java 言語で記述された OSS を対象とする

タリング可能性を評価する．

コードクローンのリファクタリング可能性に基づいた削減

Step3 では，Step2 で得た CCFinderX の出力結果を可能ソースコード量に関する結果について説明する．削減

入力として JDeodorant を実行する．今回の調査にお可能ソースコード量の最終的な目標は，開発者が大規模ないてはコンパイルエラーが出たプロジェクトは除外す

ソフトウェアから検出したコードクローンの除去作業を実る．リファクタリング可能性はクローンペア単位でリ行するべきか判断する 1 つの指標として利用されることでファクタリング可能，リファクタリング不能，そして，ある．この調査ではそのような指標として利用されるため階層構造や複数のメソッドをまたいでいるようなコーに必要となる削減可能ソースコード量を調査する．

ド片を持つコードクローンに対しては評価そのものをスキップする明らかなリファクタリング不能の 3 種類に分けられる．リファクタリング可能とリファクタリ
ング不能であったクローンペアが属するクローンセッ
トは次の 3 パターンに分けられる．
パターン 14.1 調査対象のオープンソースソフトウェア
本調査で対象とした OSS について説明する．すべてのプロジェクトが主に Java 言語で記述されている．
表 2 は，対象とした 7 つの OSS プロジェクトとその行数，コードクローンが占める行数を表している．本研究でクローンセットに属するすべてのコードクローンには，既存研究 [13] や [15] で対象となったプロジェクトの中

対して，どのクローンペアにおいてもリファクタリ

から，Java 言語で記述されていて，コンパイルが可能だっング可能である．

たプロジェクトを載せている．調査手順における Step1 でパターン 2

コンパイル可能だったプロジェクトのみ選択している．表

クローンセットに属する任意のクローンペアにおい

2 でわかるように最もコードクローンが検出されたプロて，少なくとも 1 つ以上がリファクタリング可能で，ジェクトは JFreeChart である．

少なくとも 1 つ以上リファクタリング不能である．
パターン 3表 3 は CCFinderX で検出したコードクローンとクロー
ンセットの個数，クローンセット 1 つあたりに属するコー

クローンセットに属するすべてのコードクローンに

ドクローンの個数を示すコードクローンメトリクス POP

対して，どのクローンペアにおいてもリファクタリをまとめた表である．POP はコードクローンの総和からクング不能である．

ローンセットの個数の除算で求められる．POP 数が大きパターン 1 とパターン 2 のクローンセットにはリファ

いほど削減可能ソースコード量は大きくなると推測していクタリング可能なクローンペアが含まれている．また，

る．表 4 は検出されたクローンペアの個数と Step3 におけパターン 1 においてはクローンセットに対する削減可る JDeodorant で評価したリファクタリング可能なクロー

能ソースコード量の算出手法で求められる．パターン

ンペアの個数をまとめた表である．およそ全体のクローン

2 のクローンセットにおいては，リファクタリング不ペアの内、10%から 30%程度のクローンペアがリファクタ

能なコードクローンは除外する．

リング可能なクローンペアになる．これはクローン検出

Step4 リファクタリング不能なコードクローンを除外しツールが多様なコードクローンを見つけようとして，複数て，残るリファクタリング可能なコードクローンのにメソッドにまたがるコード片を持つようなコードクロー

オーバーラップ関係を抽出する．

ンや類似した命令文の繰り返しをするようなコードクロー

Step4 ではリファクタリング可能なクローンペア以外ンが検出結果に多く含まれているためと思われる．

（パターン 2 の一部とパターン 3）は除外する．その表 5 は各 OSS から検出されたクローンセットに関して，

後，リファクタリング可能なコードクローンに対してリファクタリング可能性に基づいてパターンごとの個数をオーバーラップを抽出する．

まとめたものである．すなわち，パターン 1 とパターン 2

Step5 各クローンセットの削減可能ソースコード量を算がリファクタリング可能なクローンペアが含まれるクロー

出する．その後，貪欲法を用いてプロジェクト全体のンセットになる．パターン 2 は 3 つのパターンの中で最削減可能ソースコード量を得る．

も低い割合を示した．部分的にリファクタリング可能にな

Step5 では，オーバーラップ関係を解決するために貪るパターンはディレクリ構造上機能は全く違うファイルにc 2017 Information Processing Society of Japan⃝

6

Vol.2017-SE-197 No.7
2017/11/9

情報処理学会研究報告
IPSJ SIG Technical Report

バーラップを考慮した削減可能ソースコード量が表になっ
表 2

調査対象の OSS(*単位はすべて KLoC)ている．括弧内の数値はコードクローン行数（表 2）に対する削減可能ソースコード量の比率となる．最小の削減率

プロジェクト名

バージョン

行数*

コードクローン行数*(%)となったのは JRuby の 3.2%で，最大は Columba の 10.7%

Apache Ant

1.10.1

268

60(22.3)であった．全体ではおよそ 6%ほどの削減が見込めること

Columba

1.4

54

4.6(8.5)が明らかになった．また，リファクタリング可能な行数にJMeter

3.2

91

5.6(6.1)

限ればおよそ 30%の行数を削減できることも分かった．表

JEdit

5.4.0

180

1.8(1.0)

JFreeChart

1.0.19310

175(56.4)

7 は各 OSS に対すりリファクタリング可能クローンセット

JRuby

1.7.27325

61(18.8)

Apache Xerces

2.10.0238

83(34.9)数とるオーバーラップを考慮した削減可能なクローンセッ
ト数になる．括弧内の数値は全クローンセット数（表 3）に対する削減可能クローンセット数の比率となる．これは

表 3

各 OSS から検出されたコードクローンとクローンセット

リファクタリング可能性とオーバーラップの 2 つの課題によっておよそ 70%から 80%のクローンセットは除外される

プロジェクト名

コードクローン数

クローンセット数

POP

Apache Ant

2981

264

2.96

Columba

335

135

2.48

ということである．
図 2 は削減可能ソースコード量を算出過程において変化

JMete

437

201

2.17

する除外されていないクローンセット数の棒グラフである．

JEdit

124

54

2.29

棒グラフの縦軸は最初に検出されたクローンセット数を 1

JFreeChart

9976

2309

4.32

として変化したクローンセット数を正規化している．横軸

JRuby

4383

1398

3.13

は各 OSS について左から順番に最初に検出したクローン

Apache Xerces

4889

1311

3.72

セット数，JDeodorant における評価でリファクタリング
可能と評価されたクローンセット数，オーバーラップの考表 4検出されたクローンペアとそのリファクタリング可能性

慮して貪欲法により削減可能とされたクローンセット数をプロジェクト名

クローンペア数

リファクタリング可能（%）

表している．1 番目のフィルタリングにおける効果が強く，Apache Ant

8785

2068(23.5)

70%以上のコードクローンが除外されているのがわかる．

Columba597

187(31.3)

2 番目のフィルタリングは検出しているコードクローンのJMeter294

99(33.7)

絶対数の大きな JFreeChart や Apache Xerces などがやや

JEdit

100

17(17.0)

減少しているのがわかる．

JFreeChart

84551

8765(10.4)

JRuby

15546

830(5.3)

Apache Xerces

44764

1612(3.6)

5. まとめと今後の課題
本稿では，ソフトウェア開発者がコードクローンの削減

表 5

クローンセットのパターン分類() 内の単位は%パターン 3によるソフトウェア保守を行うのを支援する指標の 1 つ

プロジェクト名パターン 1パターン 2Apache Ant

303(30.1)50(5.0)652(64.9)

可能ソースコード量を算出する上で生じる 2 つの課題でColumba37(27.4)4(3.0)

94(69.6)

あるコードクローン間のオーバーラップとコードクロー

JMeter43(21.4)2(1.0)

156(77.6)ンのリファクタリング可能性について解決を図った．オー

JEdit

14(25.9)1(1.9)

39(72.2)

JFreeChart

449(19.4)

180(7.8)1680(72.8)

JRuby

312(22.3)39(2.8)1047(74.9)

Apache Xerces292(22.3)82(6.3)937(71.5)として削減可能ソースコード量を定義した．そして，削減

バーラップはクローンセット単位で削減可能ソースコード
量がより大きいクローンセットを削減することにした．また，リファクタリング可能性はリファクタリング支援ツー
ル JDeodorant のリファクタリング可能性判定機能を利用記述されているが，振る舞いは同じであるようなコードク

した．

ローンは共通のメソッドを作成するクラスを確保しにくい調査実験では七つの Java 言語で記述された OSS を対象ためにリファクタリング不能であるようなクローンペアがとした削減可能ソースコード量を測定して，その傾向を考発生する．大規模なプロジェクトであるほど複数の機能を察した．削減可能なソースコード量は検出されたコードク持っている可能性が高く，そのことにより JFreeChart や

ローン行数全体の 10%以下である．また，検出されたクApacheXerces の割合が高くなっていることがわかる．

ローンセット数の 20%ほどが削減可能であった．
削減可能ソースコード量の算出結果からいくつかの課題

4.2 調査結果
表 6 は各 OSS に対するリファクタリング可能行数とオー

c 2017 Information Processing Society of Japan⃝が浮き彫りになる．一つは，実際に手動でソースコードからコードクローンを削減したときにどの程度の行数を削減

7

Vol.2017-SE-197 No.7
2017/11/9

情報処理学会研究報告
IPSJ SIG Technical Report

参考文献

1

[1]

0.9
0.8
0.7

0.6
0.5

[2]

0.4
0.3
0.2

[3]

0.1
0

Apache Ant

Columba

Jmeterすべて

Jedit

JFreeChart

集約可能

削減可能

Jruby

Apache
Xerces[4]

図 2 削減可能ソースコード量の算出過程におけるクローンセット

表 6

数の変化

[5]

各 OSS のリファクタリング可能行数と削減可能ソースコード[6]

量 () 内の単位は%プロジェクト名
リファクタリング可能

削減可能

Apache Ant11224

3429(5.7)

Columba1394

584(10.7)

JMeter1117

385(6.1)

JEdit

384

136(6.6)

JFreeChart

30495

9700(5.0)

JRuby

7708

2161(3.2)

Apache Xerces

16611

5533(5.8)

表 7 各 OSS の削減可能なクローンセット (CS) 数 () 内の単位は%プロジェクト名
リファクタリング可能 CS
削減可能 CS

Apache Ant353

264(5.6)

Columba41

35(25.9)

JMeter45

36(17.9)

JEdit

13

13(24.1)

JFreeChart

629

401(17.4)

JRuby

351

251(18.0)

Apache Xerces374

244(18.6)

[7]

[8]

[9]

[10]

[11]

[12]

[13]

できるのか議論しなければならない．ソフトウェア保守を支援する指標としての妥当性を得るために必要な検証と考える．また，対象が OSS に絞っている点について気をつけ[14]

たい．大規模な商用プログラムでは，調査実験で得られたような結果にならない恐れがある．それは，検出するコー
ドクローンの数やリファクタリング可能性に関する点で想定される．更に，プログラミング言語の違いも考えられる．

[15]

Bouktif, S., Giuliano, A., Merlo, E. and Neteler, M.:
A novel approach to optimize clone refactoring activity,
Proceedings of the 8th annual conference on Genetic
and evolutionary computation Proc. of GECCO 2006,
pp. 1885–1892 (2006).
Edwards III, B., Wu, Y., Matsushita, M. and Inoue,K.: Estimating Code Size After a Complete Code-Clone
Merge, 情報処理学会研究報告，Vol. 2016-EMB-41, No. 3,
pp. 1 – 8 (2016).
Harman, M., Phil, M., Jerﬀeson, de Souza, T. and Yoo,
S.: Search Based Software Engineering: Techniques,
Taxonomy, Tutorial, Empirical Software Engineeringand Verification, pp. 1–59 (2012).
肥後芳樹，楠本真二，井上克郎： コードクローン検出とその関連技術，電子情報通信学会論文誌，Vol. J91-D, No. 6,
pp. 1465–1481 (2008).
肥後芳樹，楠本真二，井上克郎： コードクローン分析ツー
ル Gemini を用いたコードクローン分析手法，電子情報通信学会，Vol. 105, No. 228, pp. 37–42 (2005).
肥後芳樹，吉田則裕： コードクローンを対象としたリファ
クタリング，コンピュータソフトウェア，Vol. 28, No. 4,
pp. 43–56 (2011).
井上克郎，神谷年洋，楠本真二： コードクローン検出法，
コンピュータソフトウェア，Vol. 18, No. 5, pp. 47–54(2001).
Jiang, L., Misherghi, G., Su, Z. and Glondu, S.:
DECKARD: Scalable and Accurate Tree-Based Detection of Code Clones, Proceedings of the 29th international conference on Software Engineering Proc. of
ICSE 2007, pp. 96–105 (2007).
Kamiya, T., Kusumoto, S. and Inoue, K.: CCFinder: amultilinguistic token-based code clone detection system
for large scale source code, IEEE Transactions on Software Engineering, Vol. 28, No. 7, pp. 654–670 (2002).
神谷年洋，肥後芳樹，吉田則裕： コードクローン検出技術の展開，コンピュータソフトウェア，Vol. 28, No. 3, pp.
29–42 (2011).
Kim, H., Jung, Y., Kim, S. and Yi, K.: MeCC: memory comparison-based clone detector, Proceedings of the
33rd International Conference on Software Engineering
Proc. of ICSE 2011, pp. 301–310 (2011).
O’Keeﬀe, M. and Cinneide, M. O.: Search-based refactoring: an empirical study, Journal of Software Maintenance and Evolution: Research and Practice - Search
Based Software Engineering [SBSE], Vol. 20, No. 5, pp.
345–364 (2008).
Tsantalis, N., Mazinanian, D. and Krishnan, G. P.: Assessing the Refactorability of Software Clones, IEEE
Transactions on Software Engineering, Vol. 41, No. 11,
pp. 1055–1090 (2015).
山中裕樹，崔 恩瀞，吉田則裕，井上克郎： 情報検索技術に基づく高速な関数クローン検出，情報処理学会論文誌，Vol. 55, No. 10, pp. 2245–2255 (2014).
石津卓也，吉田則裕，崔 恩瀞，井上克郎： メタヒュー
リスティクスを用いた集約可能コードクローン量の推定，情報処理学会研究報告，Vol. 2016-SE-193, No. 5, pp. 1 –
8 (2016).

削減可能ソースコード量の算出にはプログラミング言語の特性に大きく依存している．そのため，たとえば商用プロ
グラムで使用される COBOL などの言語では今回得られた調査実験の結果とは乖離する可能性が考えられる．
謝辞 本研究は JSPS 科研費 25220003, 16K16034,
15H06344 の助成を受けたものです．

c 2017 Information Processing Society of Japan⃝

8