コードクローン分析ツール Gemini を用いたコードクローン分析手順
肥後 芳樹†

楠本 真二†

井上 克郎†

あらまし ソフトウェアの保守作業を困難にしている原因としてコードクローンが挙げられる．コードクロー
ンとは，ソースコード中の同一，または類似した部分を表す．あるコード片にバグが含まれていた場合，そのコード片のコードクローン全てについて修正の是非を検討する必要がある．我々の研究グループでは，コードク
ローンに対する保守支援を行うため，分析環境 Gemini を開発してきている．本稿では，Gemini を用いた効果的な分析手順について考察する．また，実際に提案した分析手順を用いて適用実験を行った．
キーワード

ソフトウェア保守，コードクローン

手順について述べる．コードクローン分析を行う目的

1. ま え が きとしては，例えば以下のものが考えられる．

ソフトウェアの保守作業を困難にする要因の 1 つと

（ 1 ） 設計とコードの一貫性確認：コードレビュー

してコードクローンが指摘されている [2]．コードクの 1 つの目的は，ソースコードと設計情報の間の一貫ローンとは，ソースコード中に含まれる同一または類性確認である．一貫性確認の 1 つの項目として，コー

似したコード片のことであり，「重複コード」とも呼ばドクローンの利用が考えられる．具体的には，設計情れる．コードクローンがソフトウェア中に作りこまれ報で重複している部分はソースコードでも重複しておる原因として，既存コードのコピーとペーストによるり，それ以外の部分には重複をしている部分がないか

再利用，頻繁に用いられる定型処理，パフォーマンス

を確認する．

改善のための意図的な繰り返し，コード生成ツールに（ 2 ） 信頼性の改善：長期間保守をされているシス

よって生成されたコードなどがある [1], [4]．コードク

テムのソースコードには多くのコードクローンが存在

ローンの存在が保守作業を困難にするのは，修正されする可能性が高い．新たなソフトウェア保守の際に，るコード片のコードクローンが存在すれば，その全て

保守対象のコード片に対するコードクローンを調査すのコードクローンに対して修正の是非を検討する必要ることで，変更漏れを防ぐことが可能となる．

があるからである．これまでに多くのコードクローン（ 3 ） 保守性の改善：複数のバージョンのソース

検出・保守支援手法が開発されている [1], [3], [7], [9].

コードが与えられたときに，バージョン間でのコード

我々の研究グループでもこれまでにコードクローン

クローンの遷移を調査し，保守作業の効率化を図る．

検出ツール CCFinder [4] と分析ツール Gemini [10]例えば，繰り返し修正が加えられているコードクロー

を開発してきている．CCFinder は大規模なソフトウェ

ンは，集約などを行い将来的な修正コストを抑えるべ

アから実用的な時間でコードクローンを検出することきであるかもしれない．一方で，安定しているコードが可能である．CCFinder の出力はテキストベースでクローンはシステムの保守コストを悪化させてはいな

あり，コードクローンの位置情報はファイル名・行番

いので，リファクタリングは不要であると思われる．

号・列番号で表される．しかし，実システムに対して

本稿で述べる分析手順は，このうち，1. 設計とコー

コードクローン検出を行うと，何万何十万というコードの一貫性の確認を目的としている．もちろん，設計

ドクローンが検出されてしまい，テキスト情報のみでとコードの一貫性確認にコードクローン分析だけが有は検出されたコードクローンの把握，理解は難しい．

効なわけではない．ソフトウェアのドメインに応じて，そこで，検出したコードクローンの分析には Gemini

より優先度の高い分析方法は多く存在する．コードクを用いる．Gemini はクローン散布図やメトリクスグ

ローン分析は，対象のドメインにあまり左右されない，

ラフなどさまざまなビューを用いてコードクローン情

二次的な解析として有効ではないかと思われる．適用

報の可視化を行う．Gemini を用いることで，ユーザ実験では，筆者らが開発した Gemini 自体を対象とは検出されたコードクローンの量や分布状態をより容した．

易に把握することができると期待される．
本稿では，Gemini を用いたコードクローンの分析†

2. コードクローン分析ツール: Gemini
本節では，コードクローン分析ツール Gemini [10]大阪大学大学院情報科学研究科，大阪府
Graduate School of Information Science and Technology, Osaka University, Toyonaka, 560-8531 Japanの紹介を行う．全ての機能を紹介することは紙面の都合上無理があるので，本稿で用いているコードクローン

第 5 回クリティカル・ソフトウェア・ワークショップ 2005 年 11 月

第 5 回クリティカル・ソフトウェア・ワークショップ 2005 年 11 月の定義，Gemini 内部で用いているコードクローン検出

f1

ツール CCFinder，そして本適用実験で用いたクローa b a ff1

タリングメトリクス RN R(S) について説明する．

f2

あるトークン列中に存在する 2 つの部分トークン
列 α，β が等価であるとき，α と β は互いにクローン
ぶ．α，β それぞれを真に包含する如何なるトークンf4

列も等価でないとき，α，β を極大クローンと呼ぶ．また，クローンの同値類をクローンセットと呼ぶ．ソー

j

k a

b c

k a

2. 2 コードクローン検出ツール: CCFinder
在する極大クローンを検出し，その位置をクローンペ

b c

f6

CCFinder [4] はプログラムのソースコード中に存

i

f6

j

f5

スコード中でのクローンを特にコードクローンという．

g h b c b d c e

f5

c b d c e if3であるという．またペア（α，β ）をクローンペアと呼f4

f g h b2. 1 コードクローンの定義 [5]

f3

a b a

ン散布図，メトリクスグラフ, ファイルリスト，フィル

f2

f1, f2, …, f6 : Filea, b, …, k : Token: Matched position

アのリストとして出力する．検出されるコードクロー
ンの最小トークン数はユーザが前もって設定できる．

図1

CCFinder のコードクローン検出手順（ソースコー

クローン散布図モデル

ドを読み込んで，クローンペア情報を出力する）は以
下の 4 つの STEP からなる．

STEP1（字句解析）: ソースファイルを字句解析することによりトークン列に変換する．入力ファイル
が複数の場合には，個々のファイルから得られたトー
クン列を連結し，単一のトークン列を生成する．

STEP2（変換処理）: 実用上意味を持たないコー
ドクローンを取り除くこと，及び，些細な表現上の違











 (a) 初期値



 (b) DF L 軸の下限を変更

いを吸収することを目的とした変換ルールによりトークン列を変換する．例えば，この変換により変数名は

図2

メトリクスグラフモデル

同一のトークンに置換されるので，変数名が付け替えられたコード片もコードクローンであると判定するこ

3 つのトークンを含んでいる．ファイルの並びはファとができる．

イル名の辞書順となっている．検出されるクローンペ

STEP3（検出処理）: トークン列の中から指定された長さ以上一致している部分をクローンペアとして全て検出する．

アは f1 と f6 に含まれるトークン列”ab”と，f3 と f6に含まれるトークン列”bc”である．

2. 4 メトリクスグラフ

STEP4（出力整形処理）: 検出されたクローンペ

メトリクスグラフは検出されたコードクローンをメ

アについて，ソースコード上での位置情報を出力する．

トリクスを用いて特徴づける．特徴づけされたコー

2. 3 クローン散布図

ドクローンはクローンセット単位で表される．メトリ

クローン散布図の簡単なモデルを図 1 に示す．散布

クスグラフの簡単なモデルを図 2 に表す．メトリク

図の原点は左上隅にあり，水平軸，垂直軸は，それぞ

スグラフは多次元並行座標表現 [6] を用いている．これソースファイルの並び (f1 から f6) に対応している．

のグラフで用いられているメトリクスは，RAD(S)，

両軸上で，原点から順にそれぞれのソースファイルにLEN (S)，RN R(S)，P OP (S)，DF L(S) の 5 つで含まれるトークンが並んでいる．座標平面内に点がプある．ここでは，RN R(S) を除く 4 つのメトリクス

ロットされている部分は，その両軸の対応するトークについて簡単に説明を行う．RN R(S) については 2. 6

ンが一致することを意味する．したがって，散布図の節を参照されたい．

主対角線は，両軸の同じ位置のトークンを比較するこRAD(S): クローンセット S 内のコード片が含まれとになり，全ての点がプロットされることになる．一るファイル集合 F が，ファイルシステムの中でディレ定の長さ (CCFinder で設定される最小一致トークン

クトリ構造的にどれだけ分散しているかを表す．ディレ数) 以上の対角線分が，検出されたクローンペアであクトリ構造を表す木構造を考え，F 内の全てのファイる．図 1 では，f1 から f6 までのファイルが，それぞれ

ルに共通の親ノードの中で最も下位層に存在するノーコードクローン分析ツール Gemini を用いたコードクローン分析手順

ドまでの距離を求め, S 内でのその最大値を RAD(S)として与えた場合，CCFinder は以下の 2 つのコードとして定義する．

片をクローンとして検出する．

LEN(S): S 内に含まれるコード片のトークン数のF1. x a b c a b c∗ a∗ b∗ c∗ y,

平均値を表す．

F2. x a b c a b c∗ a∗ b∗ c∗ y.

POP(S): S 内のコード片単位の要素数である．
P OP (S) が高いということは，同形のコード片が多く存在することになる．

DFL(S): S に含まれるコード片に共通するロジッ

コード片 F 1 は 6 トークンから成り，そのうち 1 トー
クンが繰り返しトークンである．一方コード片 F 2 もクを実装するサブルーチンを作り，各コード片をその6 トークンから成り，そのうち 4 トークンが繰り返し

サブルーチンの呼び出しに置き換えた場合の減少が予トークンである．この場合，これらのコード片からな測されるトークン数を表す．

るクローンセット S1 の RN R(S1 ) は，

5 つのメトリクスは図 2 の縦軸となっており，それRN R(S1 ) =ぞれにメトリクス名のラベルがついている．このグラ

5+2
7== 0.583̇
6+6
12

フではクローンセット毎に 5 つの縦軸上の点を結ぶ折れ線が引かれている．ユーザはこれら 5 つの座標の上限と下限を変更することで任意のクローンセットを選択することが可能である．例として図 2(b) は，DF L
軸の下限値を変更した状態を表している．この変更によって，図 2(a) では選択状態であったクローンセット

S2 が非選択状態となっている．
2. 5 ファイルリスト
ファイルリストでは，ユーザは定量的に特徴的なファイルを選択することができる．以下のメトリクス
がファイルを定量的に特徴付けるために用いられてとなる．これまでの経験から RN R(S) の値が低い場合
は，C 言語であれば連続した printf や scanf であったり，Java 言語であれば連続した import 文であったりと，目で確認を行ってもあまり意味のないコードク
ローンであることがわかっている．RN R(S) を用いる
ことでこのようなコードクローンを取り除くことが可能となる．また，RN R(S) はメトリクスグラフで用いられいているだけでなく，クローン散布図においても用いられている．クローン散布図では RN R(S) が低いコードクローンは青く描画され，他のクローンと区別がつくようになっている．

いる．

NOL(F): ファイル F の行数を表す．

3. 効果的な分析手順

NOT(F): F のトークン数を表す．
NOC(F): F に含まれているコードクローンの数

上記の特徴から，Gemini を用いた効果的であると思われる分析方法を提案する．なお，STEP2A, 2B,を表す．

ROC(F): F がどの程度重複化しているかを表す．
NOF(F): F がコードクローンを共有しているファイルの数を表す．

2C は順序不同である．

¶

提案する分析手順STEP1: 大まかな把握

ファイルリストはテーブル形式で実装されており，

STEP2A: 要素数の多いクローンセットの特定

各行に 1 つのファイルがそのメトリクス値と共に表示

STEP2B: トークン数の多いクローンセットのされる．ファイルリストは行のソーティング機能があ特定り，各メトリクス値の昇順，あるいは降順にファイル

STEP2C: 多くのファイルとクローンを共有しを並び替えることが可能である．また，ファイルリス
トはクローン散布図と連携しており，ファイルリスト³ているファイルの特定µにおいて選択されたファイルがクローン散布図で強調

以降本節では，各 STEP についての説明を行う．

表示される．

STEP1: 大まかな把握

2. 6 フィルタリングメトリクス: RNR(S)ここではフィルタリングメトリクス RN R(S) につ

ローン散布図を用いてコードクローンの分布状態を大´

新規でコードクローン分析を行う場合は，まずク

いて述べる．RN R(S) はクローンセット S 中に含ま

まかに把握するとよい．クローン散布図では，マウスれるコード片がどの程度非繰り返しであるかを表すメ

カーソル位置の垂直方向のファイル，水平方向のファトリクスである．例えば，以下のトークン列を考える．

イルのパスがリアルタイムで表示されるため，目立つ

x a b c a b c∗ a∗ b∗ c∗ y.

部分にマウスカーソルを移動させるだけで，その部分* がついたトークンはそれが繰り返しトークン列に含以下の 2 つの部分が目立ちやすい部分である．

まれていることを表している．このトークン列を入力• 一定の範囲内にコードクローンが密集しているがどのファイルであるのかを知ることができる．

第 5 回クリティカル・ソフトウェア・ワークショップ 2005 年 11 月

部分

• 同じようなパターンが繰り返し現れている部分 

また，クローン散布図はメトリクス RN R(S) を考慮したコードクローンの表示を行っている．ユーザはRN R(S) の閾値を決めることが出来る．RN R(S) の#%$'& %(*) +%, "!

 

値が閾値未満のコードクローンは青色，閾値以上の,6758 & ( $-%.( /103254%

P>PQP;<;>=@? ACBED@F G1H I ,%6758J K1LK#$M& %(*N O
RRR

コードクローンは黒色で描画される．目立つ部分のコードクローンの多くが青色の場合は，その部分に注意を払う必要は少ないと思われる．

STEP2A: 要素数の多いクローンセットの特定 



.9 : $ .

,%6758



図 3 Gemini の論理アーキテクチャ要素が多いということは，その機能がソフトウェアの多くの箇所で実装されていることを表しており，ソ絞込みと似ており，P OP (S) の代わりに LEN (S) をフトウェアの象徴的な処理部分であると考えられる．

用いればよい．

また，要素が多いということは，その部分にバグが検

STEP2C: 多くのファイルとコードクローンを共出された場合，多くの箇所で同様の修正を行わなけ有しているファイルの特定ればならないことを示しており，このようなコードク

多くのファイルとコードクローンを共有している

ローンは望ましくないと捉えることができる．このよ

ファイル内に存在するコードクローンは，現在の設計

うなことから，要素数の多いクローンセットはリファ

ではまとめることが困難なものであるかもしれない．

クタリングの対象となるのではないのかとも考えら

プログラミング言語に適切な抽象化機構が存在していれる．

ないのが原因であるかもしれないが，このようなコー

要素数の多いクローンセットの特定にはメトリクス

ドクローンが多く存在する場合は，設計をみなしたほ

グラフを用いる．要素数を表すメトリクスは P OP (S)うが良いのかもしれない．またこのようなコードク

であるが，フィルタリングメトリクス RN R(S) も同

ローンは，アスペクト思考プログラミングの「横断的時に用いた方が好ましい．なぜなら，これまでの経験関心事」であるかもしれない．

から，繰り返し部分は要素数の多いクローンセットに

多くのファイルとコードクローンを共有しているなりがちであることがわかっているからである．以下

ファイルの特定にはファイルリストを用いる．ファイの部分を変更することで，要素数の多いコードクロー

ルリストには，コードクローンの検出対象となっていンを特定することができる．

るファイルの一覧が表示されている．これらのファイ• RNR 軸の下限を上げて，繰り返し部分の多い
コード片から成るクローンセットを取り除く• POP 軸の下限を徐々に上げていき，該当クロー
ンセット数が少なくなるようにする
メトリクスグラフの絞込みの結果，該当したクロー
ンセット一覧は，クローンセットリストと呼ばれるビューに表示される．ユーザはこのリストから任意のクローンセットを選択し，そのソースコードを閲覧することができる．

ルをメトリクス N OF (F ) の値の降順にソーティングをすることによって，多くのファイルをクローンを共有しているファイルを特定することができる．また，ファイルリストでファイルを選択すると，クローン散布図の該当ファイルの部分が強調表示される．

4. 適 用 実 験
本実験の目的は，提案した分析手順を用いるとどのようなコードクローンが発見されるかを調査すること

STEP2B: トークン数の多いクローンセットの特定である．本実験の対象は Gemini のソースコードであ

トークン数が小さいコードクローンは，偶然の一致

る．筆者らが作成したソフトウェアを対象とすることによるものが存在するが，トークン数の大きいコード

で，検出されたコードクローンが設計情報に含まれるクローンはそのほとんどがコピーとペーストにより生ものかどうかを判断することができる．Gemini のソー成されたものであると考えられる．通常コピーとペー

スコードの総ファイル数は 126 個，総行数は約 26,000ストの後には，変数名の付け替えや呼び出すメソッド

行である．図 3 は Gemini の論理アーキテクチャを表の変更など細かな修正が行われる．もしこの修正漏れした図である．Gemini は分析の開始時に CCFinderがあった場合はバグが発生してしまう．トークン数のの出力ファイルを読み込み，各種メトリクスを計算し，大きいコードクローンを特定し，そのような確認作業

データベースを構築する．分析時は，各 UI はデータを行うことは有効ではないかと思われる．

ベースから必要は情報を入手し，さまざまな形でユー

トークン数の多いクローンセットの特定にもメトリ

ザに提示する．ユーザは，各 UI を用いてインタラク

クスグラフを用いる．要素数の多いクローンセットのティブにコードクローンの分析を進めることができる．

コードクローン分析ツール Gemini を用いたコードクローン分析手順










(a) 全体(b) 部分 A を拡大(c) 部分 B を拡大(d) 部分 C を拡大

図4

クローン散布図

4. 1 STEP1:大まかな把握

は複数の a3 を要素として持つ構造となっている．消図 4(a) は Gemini のソースコード全体のクローン

費メモリ量を抑えるためにこのような構造となってい散布図である．本実験ではこのクローン散布図上の目る．ソースコードを閲覧したところ，実際にクロー立つ部分，A，B，C がどのようなコードクローンでンとなっていたのは，クローンペアの情報をクローン

あるかの調査を行った．

散布図に書き込むメソッド群であった. 高いスケーラ

4. 1. 1 部分 A: クローンペアデータ

ビリティを実現するために，検出されたクローンの量

図 4(b) は図 4(a) の A の部分を拡大したものであによって異なった粒度でクローン散布図に書き込む実

る．a1，a2，a3 の３つのファイル (クラス) に多くの装としているため，似たような処理の流れを持ったメ

コードクローンが保有されている．これら 3 つのクラソッドが対象に定義されている．これは設計情報に含スは各々クローンペアデータを構成するためのクラス

まれるクローンであった．

である．a1 は 1 つのファイル内に存在するクローン

4. 1. 2 部分 B: Table ビュー

ペアデータを表すクラスであり，a2 の部分はいくつ

図 4(c) は図 4(a) の B の部分を拡大したものであかのファイル内のデータを表すクラスであり，a3 はる．この部分はディレクトリ単位で類似している部分

対象ソースコード全体のデータを表すクラスである．

が多数存在している．図 4(c) の太枠 (赤) の部分は類つまり a3 は複数の a2 を要素として持ち，さらに a2

似度の高いディレクトリを表している．この部分は，1

第 5 回クリティカル・ソフトウェア・ワークショップ 2005 年 11 月

つのディレクトリにつき，１つの Table ビューを作成

分がクローンとなっていた．ここで絞込まれたコードしている．Table ビューとは，J2SDK の標準ライブ

クローンは，4. 1. 3 節で述べたコードクローンと同一

ラリに含まれる javax.swing.JTable を継承して作成のものであった．この座標変換は，クローン散布図にしたビューを意味する．1 つの Table ビューは以下 6

データを描画する上で不可欠なものである．クローン

つのクラスから構成される．

散布図にはさまざまな機能があり，随所でデータの変• テーブルの実体となるクラス

換を行う必要がある．そのため，複数箇所で作業変換• テーブルのデータを表すクラスを行ってしまっており，コードクローンとなっている．

• テーブルの行の並び替え機能を実装するクラス

また，このクローンセットの RAD(S) の値は 0，つま(2 つ)り全てのクローンが 1 つのファイル内に含まれている• テーブルの見た目 (色，セルの幅など) を制御するクラス

• テーブルのポップアップメニューを構成するクことを表しており，集約を行うことは可能である．しかしクローンの長さが短いここと，外部に強く依存していることから集約をするべきかは疑わしい．

(2)Table ビューの行の並び替え部分: Table としラス

Gemini には Table として実装されているビューがて実装されているビューの行の並び替えを行っている複数存在する．例えば，対象ソースコードの Table

メソッドの一部がクローンとなっていた．ここで絞り

ビュー (ファイルリスト)，検出されたクローンセット

こまれたコードクローンは，4. 1. 2 節で述べたコードの Table ビュー，1 つのクローンセットに含まれるクローンの一部であった．前述のように，Gemini に

コード片の Table ビューなどがそうである．これらのはさまざまな情報を一覧表示するための Table ビュー

Table ビューでは扱うデータは異なるが，その機能はが存在する．全ての Table ビューは 2 つのクラスを用

非常に類似している．実際に新しい Table を作成する

いて行単位での並び替え機能を実装している．この中場合，既存のリストの実装部分をコピーし，細かい変で定義されていたメソッドがコードクローンとなって更を加えていくという方針で実装を行ったため，非常いた．

に類似したディレクトリとなっている．これも設計情報に含まれるクローンであった．

4. 1. 3 部分 C: ScatterPlotPanel

4. 3 STEP2B:トークン数の多いクローンセットの特定
ここではコード片が最も大きかったコードクローン

図 4(d) は図 4(a) の C の部分を拡大したものであがどのようなものであったかを述べる．なお，予めメる．この部分は，クローン散布図を描画する Panel をトリクス RN R(S) を用いて，その値が 0.5 未満のク

実装しているファイル (クラス) である．このファイローンセットは除いてある. クローン散布図を実装しルにはコードクローンが集中している部分が二箇所存ているファイル (クラス) には，マウスによるドラック

在した．c1 の部分は，マウスイベント (クリックやド部分を拡大する機能と，選択をする機能がある．いずラッグなど) が発生した時に呼び出されるメソッドのれの操作中もどこからどこまでをドラッグしているの定義部分であった．これらのメソッドの中では，イベかをユーザに伝えるために，開始部分から現在位置まントが発生した座標がどのファイルに該当するのかを

でを対角線とする長方形を描く実装となっている．し求めるために位置計算を行っており，その部分がコー

かし，ズーム時と選択時で，描かれる長方形が塗りつ

ドクローンとなっていた．c2 の部分はコードクローン

ぶされるか，塗りつぶされないかの違いがあるため，の描画の位置計算を行っている部分である．クローン

異なるメソッドで実装を行っている．各機能は 1 つの散布図は拡大表示機能などがあるために，位置計算をメソッドとして実装されており，そのメソッドが最も行う部分が複数箇所に存在してしまっている．これら

トークン数を多いコードクローンとして検出された．

は 1 つのメソッドにまとめられることなく実装されてなお，1 つのコード片のトークン数は 568(97 行) でしまっていたため，コードクローンとなっていた．こ

あった．このメソッドはコピーとペーストにより作成

れらは，設計情報に含まれないクローンであった．

されたものである．

4. 2 STEP2A:要素数の多いクローンセットの特定

4. 4 STEP2C:多くのファイルとコードクローンを共有しているファイルの特定同形のコード片が最も多かった 2 つのクローンセッ

ここでは最も多くのファイルとコードクローンを共トがどのようなものであったかを述べる．なお，予め有していたファイルがどのようなものであったかにつ

メトリクス RN R(S) を用いて，その値が 0.5 未満のいて述べる．

クローンセットは除いてある.

Table ビューを実装しているクラスがそれぞれ他の(1) 位置計算を行っている部分: 対象システム内の10 個のクラスとコードクローンを共有していた．共有

位置から，クローン散布図上での位置を求める計算部

していたコードクローンは，スクロールバーを生成しコードクローン分析ツール Gemini を用いたコードクローン分析手順ている部分，リスナーを登録している部分，マウスのとコードクローンの位置が関係している．例えば，100

右ボタンがクリックされた時にポップアップメニュー

個のコードクローンを含んでいるファイル (ファイルを表示するメソッドなど，Java の GUI の特徴的な部

A とする) があるとする．もしこの 100 個のコードク分が多くのファイルに共有されているコードクロー

ローンが全て，他の 1 つとのファイル (ファイル B とンであった．これらのコードクローンは，このソフトする) と共有していた場合は，クローン散布図上では，

ウェア独自の処理部分を実装しているというよりは，

水平方向がファイル A，垂直方向がファイル B の領域

Java での GUI を実装する場合の定型的な処理部分で内にコードクローンが密集しているのが目立つと考えあった．

られる．しかし，100 個の異なるファイルと共有して

5. 考

察

ここでは，クローン散布図，メトリクスグラフ，ファ
イルリストの特徴をまとめる．

いた場合は，特定の領域にコードクローンが密集することはなく，クローン散布図上でそのようなファイルを見つけることは困難である．しかし，ファイルリス
トを用いれば，N OC(S) の値を確認するだけで，そ5. 1 クローン散布図のファイルにどの程度コードクローンが含まれている• 対象ソフトウェアのどの部分にどの程度のコーのかを定量的に知ることができる．

ドクローンが存在するのかを俯瞰的に知ることができる．

6. 関 連 研 究• ファイルよりも大きな単位での類似部分を知る

門田ら [8] は COBOL で記述されたレガシーコードことができる．例えば，図 4(c) のコードクローンは複に対してコードクローン検出を行い，バグとの関係を数のディレクトリが類似していることを表している．

調査している．この研究では，各ファイルにおいてそ• クローン散布図において目立つコードクローンのファイルのクローンとなっている行の割合，ファイはある程度の領域内に密集している部分 (図 4(b)，図ル中の最大長クローンとそのファイルの改版数を定量

4(d)) や，繰り返し同じパターンが出現している部分

的に比較し，一定以上の割合でクローンが含まれてい(図 4(c)) である．

る場合や，非常に長いコードクローンが含まれていた• クローン散布図において目立つ部分は，必ずしもその部分に存在するコードクローンが特徴的である

場合，そのファイルの改版数が多くなることが示されいる．

ことを示しているわけではない．なぜなら，目立つ部

また，Kim ら [3] は，複数のバージョンに対してコー

分に存在するコードクローンは 1 種類ではなく，複数

ドクローン検出を行い，その情報がソフトウェア保守の種類のコードクローンが混在している場合があるかに利用できると提唱している．例えば，同様の修正がらである．

各コード片に施されているコード片は，将来の修正コ• 目立ちやすさとコードクローンの位置が関係しストを抑えるためにリファクタリングをするべきではている．要素数の多いコードクローンであっても，複ないかと考えられる．

数のファイル内に点在してしまうような場合は，ク

7. ま と め

ローン散布図上でそれらは互いに離れた部分に描画されてしまい，目立ちにくい．

本稿ではコードクローン分析ツール Gemini を用い

5. 2 メトリクスグラフ

た分析手順について述べた．また，適用実験では設計• 対象ソフトウェアに存在する特徴的なコードク情報に含まれるもの，含まれないもの，プログラミン

ローンを見つけることができる．クローン散布図でグ言語に依存したものなど，さまざまなコードクロー

は，コードクローンの位置が目立ちやすさに影響を与ンが検出された．既に，提案手法を複数の実ソフトえてしまうが，メトリクスグラフではそのようなこと

ウェアに対して適用しはじめている．これらの分析結はない．

果に基づいて，コードクローン分析方法の改善を行う• メトリクス RAD(S) を用いることによってク
ローンセット内の要素がどの程度ファイルシステム上で散らばっているか (クローン散布図上ではなれた位置に描画されているのか) を知ることができる．

5. 3 ファイルリスト

予定である．
謝辞

本研究は一部，日本学術振興会 科学研究費補助金 基盤研究 (A)(課題番号：17200001)，文部科学省
科学研究費補助金 特別研究員奨励費 (課題番号：16・8351) の助成を得た．
文• 定量的な情報に基づいてファイルを選択することができる．クローン散布図のように，コードクロー
ンの位置に影響されることはない．
前述したようにクローン散布図では，目立ちやすさ[1]

献

I.D. Baxter, A. Yahin, L. Moura, M.S. Anna, and
L. Bier,

Clone Detection Using Abstract Syntax

Trees, Proc. 14th International Conference on Software Maintenance, pp.368-377, Bethesda, Maryland,第 5 回クリティカル・ソフトウェア・ワークショップ 2005 年 11 月
Mar. 1998.
[2]

M. Fowler,

Refactoring: improving the design ofexisting code, Addison Wesley, 1999.
[3]

M. Kim, and D. Notkin, Using a Clone Genealogy
Extractor for Understanding and Supporting Evolution of Code Clones newblock Proc. The 2nd International Workshop on Mining Software Repositories,
pp.17-21, May 2005.

[4]

T. Kamiya, S. Kusumoto, and K. Inoue, CCFinder:
A multi-linguistic token-based code clone detection
system for large scale source code IEEE Transactions on Software Engineering, vol.28, no.7, pp.654670, Jul. 2002.

[5]

神谷年洋, “コードクローンとは，コードクローンが引き起こす問題，その対策の現状”, 電子情報通信学会誌 Vol.87,
No.9 pp.791-797, Sep. 2004.

[6]加藤 博己, “データベースのビジュアルな検索と分析(OLAP)”, 情報処理学会会誌，Vol.41 No.4 pp.363 368, Apr. 2000.

[7]

J. Mayland, C. Leblanc, and E.M. Merlo Experimenton the automatic detection of function clones in asoftware system using metrics, Proc. 12th International Conference on Software Maintenance, pp.244253, Monterey, California, Nov. 1996.

[8]

門田暁人, 佐藤慎一, 神谷年洋, 松本健一, “コードクローンに基づくレガシーソフトウェアの品質の分析”, 情報処
理学会論文誌, Vol.44, No.8, pp.2178-2187, Aug. 2003.

[9]

M. Toomim, A. Begel, and S.L. Graham, Managing Duplicated Code with Linked Editing Proc. 2004
IEEE Symposium on Visual Languages and HumanCentric Computing(VL/HCC’04), Rome, Italy, Sep.
2004

[10]

植田泰士, 神谷年洋, 楠本真二, 井上克郎 “開発保守支援を目指したコードクローン分析環境”, 電子情報通信学会論文誌, Vol.86-D-I, No.12, pp.863-871, Dec. 2003.