ソフトウェアエンジニアリングシンポジウム 2012

リポジトリマイニング可能な
コードクローン版管理システムの提案
畑 秀明1,a)

肥後 芳樹1,b)

楠本 真二1,c)

概要：ソフトウェアのソースコード中には，同一または類似したコード片，コードクローンが存在する．
こういったコードクローンには，不具合の温床となるものだけでなく，保守性の面で好ましいものもあるとの報告が近年されている．例えば，長期間安定したコードクローンは除去する必要のないものが多い．
こういった新しい知見の発見と活用のためには，コードクローンの履歴管理や分析が重要である．これまでのコードクローン履歴分析の研究では，コードの変更のみに着目した分析が行われている．一方，リポ
ジトリマイニング（開発履歴のデータマイニング）の研究では，コードだけでなくプロセスや人的属性に関する履歴情報から有用な知見が報告されている．そこで，本稿では，こういった多様な面でのリポジト
リマイニングが可能であるコードクローン版管理システムを提案する．6 つのオープンソースソフトウェ
アへ適用し，その有用性を報告する．

Code Clone Version Control System
for Mining Rich Clone Histories
Hata Hideaki1,a)Higo Yoshiki1,b)Kusumoto Shinji1,c)Abstract: In source code, there exist code clones, that is duplicated or similar code fragments. Recent
empirical studies reported that not all code clones are harmful but some code clones have positive impact
on software maintenance. For example, we do not need to eliminate long-lived clones. To ﬁnd more eﬀects
of clones and manage clone evolutions, it is important to analyze clone histories and manage them. Stateof-the-art studies of clone evolution concentrate only on code-related histories. However, the research areaof mining software repositories has found the usefulness of not only code-related but process-related anddeveloper-related histories. Therefore, we propose code clone version control systems that enable us to minerich clone histories including code-related, process-related, and developer-related histories. We applied oursystems to 6 open source software repositories to show the usefulness.

1. はじめにソースコード中に存在する同一または類似したコード片

適切なコードパターンの実現のような好ましい現象であることが多々あり，保守性の面で好ましいものも多い [8], [15] ．

をコードクローンと呼ぶ．不用意なコピーアンドペース• コードクローンと不具合の相関を調査した場合，多くトによるコードクローンの生成は，ソフトウェアの保守の不具合はコードクローンとの相関が小さい．また，を困難にするといわれており，多くの研究が行われてきクローンとなるコード片の方が，クローンとならない

た [19], [21]．

コード片と比べて不具合との相関が小さい [13]．

一方，実証的な分析からコードクローンの負ではない面を指摘する以下のような報告がある．

• コードクローンの生成，すなわち類似コードの作成は
1

a)
b)
c)

大阪大学
Osaka University, Suita, Osaka 565–0871, Japanh-hata@ist.osaka-u.ac.jp
higo@ist.osaka-u.ac.jp
kusumoto@ist.osaka-u.ac.jp

c 2012 Information Processing Society of Japan• 長期間存在する安定したコードクローンがあり，それらは除去する必要がない [2], [9]．
特に，近年コードクローンの履歴を対象とした分析で新たな知見が報告されており，多くの実証的な分析を行うことが重要である．こうした開発履歴の分析は，リポジトリ
マイニングと呼ばれ多くの研究が行われている [23]．特に

1ソフトウェアエンジニアリングシンポジウム 2012

不具合予測の分野では，近年リポジトリマイニングの有用!"性が注目されている．マイニングの対象として，コードの履歴だけでなく，プロセスや人的属性の履歴についての!#データも重要とされている [18]．しかしコードクローン履歴の研究では，コードに着目した研究しか行われていない．

!$

そこで本稿では，コード履歴だけでなく，コードクローンに関わる開発履歴のプロセスや人的属性に関する情報に

図 1 コードクローン履歴

ついてのリポジトリマイニングが可能なコードクローン版

Fig. 1 Code clone histories

管理システムを提案する．提案するシステムを 6 つのオー
プンソースソフトウェアへ適用し，評価を行った．また，どのように変更されたかといった有用な特性が得られるこプロセスや人的属性に関するコードクローン履歴のマイニとから，注目されている．

ングを実現した．

ここでコードクローンの履歴の例を図 1 に示す．図の以降，2 章でリポジトリマイニングやコードクローンの丸がコード片を表し，それを囲む四角がコードクローンの履歴分析に関する関連研究を議論し，3 章でコードクロー

関係にあることを示す．それぞれの四角，つまりコードク

ン版管理システムを提案する．4 章でオープンソースソフ

ローン関係にあるコード片の集合をクローンセットと呼トウェアへの適用結果とリポジトリマイニングの分析結果

ぶ．また，水平方向の層はある版でのコードクローンの様を報告し，5 章で議論する．最後に 6 章でまとめる．

子を表す（ここでは v1 から v3 までの版がある）．丸を結

2. 関連研究2.1 リポジトリマイニング

ぶ線は，版間でのコード片の変遷を表す．図 1 では，版 v1の左側に存在するクローンセットが版 v3 まで存在すること，版 v1 の真ん中に存在するクローンセットには版 v2 で開発履歴が蓄積されたソフトウェアリポジトリに対するコード片の追加があり，版 v3 では残りのクローンセット

データマイニング（リポジトリマイニング）は，実際のソと合流していることがわかる．コードクローンの履歴に対

フトウェア開発における有用な知見の発見が期待され，近しては，コード片に対する変更だけでなく，クローンセッ

年の実証的ソフトウェア工学で多くの研究が行われていトの変遷などが分析対象となる．

る [23]．近年のソフトウェア工学の動向としても，実証的

コードクローン履歴を分析した初期の研究には Kim らの証拠（empirical evidence）を発見，収集することが重視さ成果が挙げられる [9]．Java 言語で書かれたオープンソー

れている [10]．

スソフトウェアを対象としたクローンセット変遷の分析か

ソースコードの版管理システムを対象としたリポジトリ

ら，36 から 38% のクローンセットはセット内で一貫した

マイニングが盛んな研究テーマに不具合予測がある [18]．

変更が行われていること，49 から 64% のクローンセット

不具合予測は，予測モデルの構築にソフトウェアメトリクは除去が簡単ではない，特に長期間存在するコードクロー

スを用いる [22]．このソフトウェアメトリクスとして，リンは除去の必要がないこと，また，48 から 72% のクローポジトリマイニングで得られる開発履歴メトリクスが注目

ンセットはわずかの期間で消滅することを報告している．

されている．開発履歴メトリクスとしては，ソースコード

コードクローンセットに対する一貫しない変更，すなわの変更履歴に注目したコード関連のもの，モジュールの変

ちクローンセット内の一部のコード片に行った変更を残り

更回数や過去の不具合修正の有無といったプロセス関連ののコード片に行わないことは，修正漏れなどの不具合混入

もの，開発した組織や開発者数などの開発組織関連のもの，の要因と考えられる．Juergens らは，2 つの社内プロジェ

分散開発に注目した地理的位置関係に関連するものなどがクトと 1 つのオープンソースプロジェクトを対象とした大提案され，多くのソフトウェア開発プロジェクトへの適用

規模な分析から，一貫しない変更が不具合に結びつきやすからその有効性が報告されている [18]．

いと報告している [7]．一方 Göde らは，多くのコードク

こういった成果から，リポジトリマイニングではコードの履歴情報だけでなく，開発プロセスや人的属性など様々な観点での実証的証拠の収集が，重要となると考えられる．

ローンセットはあまり変更されず，一貫しない変更はあまりないことを報告している [2]．

Thummalapenta らは，C 言語と Java 言語で書かれた 4
つのオープンソースプロジェクトとのコードクローン履歴

2.2 コードクローンの履歴分析分析から，クローンセットに対する変更は一貫して直ちに開発履歴を分析して，コードクローンの変遷を調査す

行われること，コードクローンをテンプレートとして用いる研究が近年数多く行われている [12]．単一の版に対するるのはソフトウェアシステム内の共通する現象であるこ

コードクローン分析と比べて，複数の版におけるコードクと，クローンの粒度やサイズ，範囲，プログラミング言語

ローン分析では，コードクローンとなったソースコードがといった特徴はコードクローン変遷のパターンに影響を与c 2012 Information Processing Society of Japan2

ソフトウェアエンジニアリングシンポジウム 2012

えないこと，また，一貫した変更を遅れて行う変更（latepropagation）は不具合修正の場合が多いことを報告してい-./012"3'1%45%.6%!&#

る [15]．

!&$ !&%

!"#

!"$
! !"%

従来のコードクローン履歴分析では，コードの履歴情報のみを分析対象としている．本研究は，開発プロセスや人!"#$%&'(

的属性の観点でもコードクローン履歴を分析することを目指す．

!"#$%&'(!"#$%&')!"#$%&')

!,#%

!,#%
!"#$%&'*!"#$%&'*!,#%!"#$%&'+!"#$%&'+!"#$%&'<

2.3 コードクローンの履歴管理!"#$%&';

Duala-Ekoko らは，CloneTracker というコードクロー!,#%

ン履歴管理システムを提案している [1]．CloneTracker は

7&,8,./#'1./012"3

Java のメソッド内のブロックに対するコードクローン履歴

9%:'1./012"3(a) スナップショットの再構成を追跡するシステムで，Eclipse のプラグインとして実装されている．

!"#$%&'($)*'+'

Nguyen らは，コードクローンの履歴管理だけでなく，ク
ローンセットに対して一貫した変更への支援を行う JSync!"#$%&'($というシステムを提案している [11]．システムのデータ
ベースには，コード片，コードクローン関係，コードクロー,#'--%&'($

ンへの変更などの情報を保存している．
($./0123'45-6

コードクローンの履歴管理は，コード片のモジュールの履歴だけでなく，クローンセットというモジュール集合の)))履歴も管理する必要があり，挑戦的な課題である．上述の2 つのシステムは，コードに関する履歴情報を保持しているが，2.1 節で議論した開発プロセスや人的属性などの面($./0123'45-6,#'--%&'($

でのリポジトリマイニングは難しい．
(b) ディレクトリ構造

3. コードクローン版管理システム

図 2 Historage のアイディア

3.1 コードクローン履歴の追跡

Fig. 2 Key idea of Historage

Zibran らはコードクローン履歴を追跡する技術を以下のようにまとめている [16]．

い可能性がある．

( 1 ) 各リビジョンでコードクローンを特定し，連続するリ
ビジョンのクローン間で対応付けを行う．

3.2 要求( 2 ) 最初のリビジョンでコードクローンを特定し，各ク

版管理システムは，コードの変更履歴だけでなく，変更

ローンを以降のリビジョンにマッピングする．

日時，開発者名，コミットログなどの開発プロセスや人的( 3 ) インクリメンタルなコードクローン検出ツールでク属性に関する情報をも保持している．この情報や，さらにローン特定とリビジョン間の対応付けを行う．

は障害管理システムや開発者データベースなどの情報を組( 4 ) 各リビジョンでコードクローンを特定する．連続する

み合わせることで多様なリポジトリマイニングが可能に

リビジョン間で関数の対応付けを行い，その情報を用いてクローン間の対応付けを行う．

(1), (4) のアプローチは，注目する全リビジョンに対してなっている．
コードクローンに関しても同様のリポジトリマイニングを可能にしたい．コードクローン版管理システムについて

任意のコードクローン検出ツールを用いてコードクローンの要求を以下に示す．

を特定することができるが，クローン間や関数間の対応付( 1 ) 全リビジョンでコードクローンを特定する．

けに時間がかかる．そのため分析可能なリビジョン数が限( 2 ) 全てのコードクローンの履歴を保持する．

られる．(2)，(3) のアプローチは高速であるため，多くの( 3 ) コードクローンの履歴を追跡できる．

リビジョンを対象とできる．しかし，(2) では 2 番目以降

( 4 ) 開発プロセスや人的属性に関する情報を保持する．

のリビジョンで発生したクローンを特定できない．また，(3) は特定のツールに依存し，非インクリメンタルなコー
ドクローン検出ツールで特定可能なクローンを特定できな

c 2012 Information Processing Society of Japan

3.3 キーアイディア：Historage
3.1 節で紹介した既存技術の課題や，3.2 節で掲げた要3

ソフトウェアエンジニアリングシンポジウム 2012

求に対するキーアイディアは，先に提案した細粒度履歴管
理リポジトリ，Historage である [3]．Historage は，ソー,.'/$)*$&)1,.'/$)*$&)1

スコード版管理システム Git の仕組みを活用して実現した [3], [17]．

Git はソースコードファイルの履歴を，(1) 各版のスナッ,.'/$)*$&)2

プショットを独立に保存し，(2) 連続するスナップショッ
ト間の差分からファイルに対する変更操作を推定する，と,.'/$)*$&)2いう仕組みで管理する．あるコミットの前後のスナップ,'-$)%.'/$)#$.0&"'/*

ショット間での，ファイルの有無や中身の違い，ファイル!"#$%&'#()*&#+%&+#$

名や存在するパスの違いから，そのコミットで特定のファ図 3 コードクローン関係を保持したディレクトリ構造

イルに対して追加，削除，修正，名前変更，移動といった

Fig. 3 Directory structure representing code clone relations

変更操作が行われたと報告する．また，関連する全スナッ
プショット間で同様の処理を行い，特定のファイルに対す対応付けを行って保存しないので高速である．対応付けはる全履歴を出力する．

履歴を出力するときに Git によって行われる．

Historage は，細粒度なモジュールである Java のメソッ
ド履歴を管理するシステムである．履歴を追跡したいメ

3.4 提案システム：CloneHistorage

ソッドをそれぞれ 1 つのファイルとして各スナップショッ

コードクローンの履歴管理を行うシステム CloneHistor-

トで保存することで，上述の Git の仕組みを活用してメage を提案する．図 3 に示すように，それぞれのクロー

ソッドの全履歴を管理する．図 2(a) に示すように，既にンセットごとにディレクトリを作成し，その中にコード

通常のソースコードの履歴が蓄積された Git リポジトリのクローンとなるモジュールを配置させる．これによって，各スナップショットを再構成することで，既存のファイル

コードクローン関係を保持したディレクトリ構造となる．

レベルの履歴管理システムをメソッドレベルの履歴管理シ

図 3 の左側に示す 2 つのモジュールを含むクローンセッ

ステムにする．

ト 1 と 3 つのモジュールを含むクローンセット 2 は，図 3

このスナップショットの再構成では，1 つのソースコーに右側に示すディレクトリ構造となる．このようなディレ

ドファイルに対して図 2(b) の灰色部分に示すようなディ

クトリ構造にすることによって，各ファイルに対する変更

レクトリ構造を作成する．各メソッドはそのメソッドシグを分析することでコードクローンとなるモジュールの履歴

ネチャをファイル名とし，ソースコードのファイル名（のが，ディレクトリに対する変更を分析することでクローン

拡張子を除去）を名前とするディレクトリに格納する．モ

セットの履歴が得られる．

ジュール履歴で最も難しい課題は，モジュールの中身の変CloneHistorage の実現には，以下の 2 点を決定する必要

更と名前変更や移動が同時に行われた場合のモジュールのがある．

追跡である．オープンソースソフトウェアでの適用実験で，モジュールの粒度と識別 モジュールの粒度には，ファイ

メソッドテキストの類似度が 30% 以上であれば 95% 以上

ル，メソッド，ブロックなどが考えられる．これはコーの精度でメソッドの追跡ができることを確認している．こドクローン検出手法にも依存する．対応するファイル

れは実用上十分な精度である*1 ．

名を定める必要がある．

Historage の基本的なアイディアは，履歴の管理を行いたいモジュールをディレクトリ構造に配置し，全スナップ

クローンセットの識別 対応するディレクトリの名前が必要である．

ショットで保存させることで Git の仕組みで履歴を追跡す

図 3 に示したように，クローン検出対象のモジュールとるというものである．Historage では，Java のメソッドがクローンセットは，それぞれファイルとディレクトリに対履歴を管理したいモジュールであった．本研究で対象とす応させる．このときそれぞれに名前が必要である．この名るコードクローンでは，コードクローンとなるモジュール

前付けには以下の要求がある．

とクローンセットの履歴管理が必要である．これらをディ
レクトリ構造に配置し，スナップショットを保存することができれば Historage と同様のアプローチで実現することができる．

• それぞれを識別するために，1 つのスナップショット
で唯一の名前をつける必要がある．

• スナップショット間で追跡可能な名前である必要があ
る．同じまたは対応する要素に同じ名前を付けること

3.1 節で議論した既存技術と比べると，本アプローチはができれば追跡が容易である．名前変更の検出は，ス

全リビジョンでコードクローンの特定を行うが，明示的にナップショット間の異なる名前の要素間で行われる．

*1

Git は類似度 50% をデフォルトの閾値にしており，それより低い類似度でも高い精度で追跡ができているから

c 2012 Information Processing Society of Japan

そのため，対応しない要素に同じ名前を付けてはならない．例えば，版 v1 で要素 1 に A，要素 2 に B と名4

ソフトウェアエンジニアリングシンポジウム 2012

前を付け，版 v2 で要素 1 に B，要素 2 に C と名付けると，正しく履歴を追跡できない．Git は同じ名前の( 1 ) クローンセット内の全メソッド名が一致した場合，そのメソッド名をクローンセット名とする．

要素を追跡するため，B と名付けられた要素を追跡す( 2 ) 全メソッド名は一致しないが，全メソッド名に共通部

ると版 v1 で要素 2，版 v2 で要素 1 という誤った履歴

分がある場合，異なる部分を @ に置換したものをクとなる．このため，連番などの単純な名前付けは適切

ローンセット名とする．例えばクローンセット内にでない．

含まれるメソッドが bindGridView と bindListView

以上の要求に加えて，履歴を理解するときには，分かりやすい名前である方が望ましい．そのため，適切な名前付
けは CloneHistorage の大きな課題の 1 つである．

というメソッド名である場合，クローンセット名はbind@View とする．
( 3 ) (2) で共通部分が 3 文字未満の場合（共通部分が無い

2.3 節で紹介した，JSync は，クローンセットに名前を場合も含む），メソッド名が長い順，同じ場合は辞書順

付けて識別していない [11]．また，CloneTracker はクローに 2 つ選び，2 つのメソッド名の最長共通部分文字列

ンセットに連番を振って識別している [1]．クローンセッ（longest common subsequence）をクローンセット名とトに名前をつけて管理することは，我々の知る限り行われする．Java のメソッド名は慣習として単語の最初が大ていない．

文字の複合語であるので，単語に分解して単語単位で最長共通部分文字列を取得する．例えば，クローンセッ

3.5 実装ト内の 3 つのメソッド名が dismissAllOtaDialogs と3.5.1 コードクローン検出対象モジュール

dismissAllDialogs，onDisconnect の場合，クロー

コードクローン検出対象となるモジュールには，Java のメソッドを選択した．これは，ファイルレベルと比べてンセット名は，先の 2 つのメソッド名の最長共通文字
列から dismissAllDialogs となる．

細粒度な分析ができ，メソッドシグネチャを名前とすれ( 4 ) (3) で最長共通文字列が 3 文字未満の場合，選択したば 3.4 節で示したモジュールの名前付けに対する要求を満

2 つのメソッド名をつなげたものをクローンセット名

足できるからである．加えて，先の研究でメソッドの履
歴追跡が実用上十分な精度で行えることを確認できている [3], [17]．

とする．

( 5 ) (1) から (4) までのいずれかで，何らかの名前が得られる．しかし，他のクローンセット名と名前の衝突が起

コードクローン検出には，検出ツール Scorpio を用いこる可能性がある．衝突が起こった場合には，scorpio

た [6], [20]．Scorpio はソースコードをプログラム依存グラが出力するクローンセットのハッシュ値をクローン

フとしてモデル化し，類似する部分グラフの特定からコー

セット名とする．これは，コードクローン検出時に内ドクローンセットを検出する．プログラム依存グラフを部で保持するオブジェクトから計算したものであり，用いたコードクローン検出は，検出の精度が高く，ソース

分かりやすい名前ではないが，スナップショットで唯

コード上で非連続な要素群に対してもコードクローン関係

一の名前という要求は満足する．

を検出ができる．また，Scorpio は計算コストを削減する
工夫によって，他のプログラム依存グラフを用いたコード

3.6 再構成するディレクトリ構造

クローン検出ツールと比べてスケーラビリティが高い．さ

図 2(a) に示したようにスナップショットを再構成する．

らに，Scorpio はメソッドごとにプログラム依存グラフを

まず，3.5.2 節で決定したクローンセット名を名前とする

作成するので，メソッド間のコードクローン検出ができる．

ディレクトリを作成する．そのディレクトリ内にクローン

本稿の Scorpio でのコードクローン検出では，検出する同セットに属するコード片をもつメソッドを入れる．そのメ

型部分グラフの頂点数の最小数を 10 とした．

ソッドは，属するファイルのパスと図 2(b) に示したディレ

3.5.2 クローンセットの識別

クトリ構造で配置する（/クローンセット名/path/to/java/

クローンセットの名前は，属するコード片の処理を表す

ファイル名/クラス名/method() となる）．

ものであれば理解しやすく望ましい．しかし，ソースコー

同一のメソッドが複数のクローンセットに属する場合

ドの処理を人が理解できるよう分かりやすくまとめるのは，全てのクローンセット内に配置する．コードクローン

は，挑戦的な課題であり難しい [14]．

とならなかったメソッドは，クローンセット名 none 内に

事前のコードクローン分析から，クローンセットとなる
コード片を含むメソッドには，同じ名前や似た名前のものが多いことを確認した．メソッド名はメソッドの処理を表しており，クローンセットに含まれるメソッド名を参考にすることは妥当である．そこで以下の手順でクローンセッ
トの名前を決定する．

c 2012 Information Processing Society of Japan

配置する．これによって非コードクローンの履歴分析も行える．

4. 適用実験
提案手法を Java で書かれたオープンソースのソフトウェ
アリポジトリに適用する．表 1 にリポジトリのデータを示

5ソフトウェアエンジニアリングシンポジウム 2012

表 1 対象リポジトリデータ

1,632

13,8223 年 7 ヶ月

4,083

2,363

Camera3 年 4 ヶ月

3,537

991

Music

3 年 1 ヶ月

672

534

Phone

3 年 4 ヶ月

3,271

1,341

days

6 年 2 ヶ月

Browser400

Struts 2

0

12,022800

最新版のメソッド数

1,141

days

コミット数

5年

400

期間

EMF Compare

0

リポジトリ

800

Table 1 Target repository data.

not cloned

cloned(a) Camera

not cloned

cloned(b) Music

図 4 クローン有無とメソッドの存在日数

Fig. 4 Method existing periods with/without clones
表 2 クローンセット名前付けの結果

Table 2 Results of naming clone sets.
(1)

(2)

(3)

(4)

(5)

ソッド名を参考に決定する．3.5.2 節に示す (1) から (5) の

リポジトリ

一致

共通

LCS

結合

ハッシュ

順にクローンセット名を決定するが，番号が若いほど元の

EMF Compare

22

18

1

2

4

メソッド名との一致度合いが高く分かりやすい名前といえStruts 2

13

75

1

5

4

る．特に (5) のハッシュ値は，わかりにくいだけでなく，

Browser

2

5

0

0

1

スナップショット間でも異なる値となり履歴の追跡が難し

Camera

2

5

1

0

1

Music

1

4

0

2

0

Phone

1

4

1

0

0

くなるため好ましくない．
実際にどのように名前付けが行えたかを調査する．表 2
は，最新版にあるクローンセットに対する名前付け結果の），Apache から 1分類である．多くのクローンセットには，手順 (1) と (2)つ（Struts 2*3 ），Android から 4 つ（Browser*4 ，Camera*5で得られる人目にも分かりやすい名前が付けられている．

，Music*6 ，Phone*7 ），計 6 つのリポジトリを対象にそ一方，好ましくない名前である (5) のハッシュ値はわずか

れぞれ CloneHistorage を構築する．開発履歴は 3 年からしかないことが確認できる．以上より，提案するクローン

6 年ほど蓄積されている．Android から取得したリポジト

セットの名前付け手法は多くのクローンセットに好ましい

リは，最新版のメソッド数が 500 から 2,000 程度の小規模

名前を付けられたと判断できる．この評価から，多くのクなものであり，Eclipse と Apache から取得したリポジトリ

ローンセットの履歴が容易に追跡可能であることを確認しは，最新版のメソッド数が 12,000 以上のやや規模の大きなた．ハッシュ値の名前を持つクローンセットの履歴も容易ものである．

ではないが可能である（クローンセットに含まれるメソッ

す．Eclipse から 1 つ（EMF Compare*2

3.2 節で示した要求について，全てのリビジョンでコードの履歴を追跡して，集合の履歴をまとめる）．

ドクローンを特定し，保存しているので要求 (1) と (2) を満
たす．また，要求 (3)：履歴の追跡については，Historage

4.2 開発プロセスや人的属性のマイニング

でメソッドレベルのモジュールを追跡可能であることを確

CloneHistorage を用いて，コードクローンに関するリポ認している [3]．そこで以降では，クローンセットの履歴追

ジトリマイニングを行う．コードクローンとなるメソッ

跡と，要求 (4)：開発プロセスや人的属性に関する情報のドの履歴とクローンセットの履歴を分析する．構築した保持について確認する．

CloneHistorage は，Git リポジトリであるのでこれまでのリポジトリマイニングと同様の分析ができる．

4.1 クローンセットの履歴追跡

まず，開発プロセスメトリクスの一つである，モジュー

クローンセットの履歴は，CloneHistorage においてディルの存在日数を計測した．図 4 に，コードクローンを含む

レクトリの履歴に対応させている．このディレクトリ名，

メソッドと含まないメソッドの存在日数をボックスプロッ

すなわちクローンセット名はコードクローン関係にあるメ

トにまとめた（(a) Camera と (b) Music の結果）．この結

*2
*3
*4
*5
*6
*7

http://git.eclipse.org/c/emfcompare/org.eclipse.emf.
compare.git
https://github.com/apache/struts2
https://github.com/android/platform_packages_apps_
browser
https://github.com/android/platform_packages_apps_
camerahttps://github.com/android/platform_packages_apps_
music
https://github.com/android/platform_packages_apps_phone

c 2012 Information Processing Society of Japan

果からは，クローン関係にあるメソッドの方がないものと比べて長期間存在していることが確認できる．今回の分析
では，長期間存在する安定したクローンセットが多かったとわかる．メソッドが，クローンセットでないディレクト
リ none からクローンセットのディレクトリに移動した場
合は，履歴の途中でコードクローンとなったことを意味する．本稿の分析では，ほとんどのメソッドが作成時にコー
ドクローンとなったのに対して，途中からコードクローン

6ソフトウェアエンジニアリングシンポジウム 2012

が必要かという要求にも依存する問題である．

40

5.2 機能コードクローン関係にあるメソッドは，Git 上で通常の歴出力に関する全てのコマンドが利用できる．

20

一方，クローンセットの履歴はディレクトリの履歴に対応させている．Git 上でディレクトリの履歴は，内包するファイルに対する変更の履歴として得られる．これは，ク

10# of developers30

ファイルと同様に管理されているので，Git に備わった履

ローンセットの履歴として期待する出力である．しかし，
0

ファイルは名前変更後も追跡可能であるのに対して，ディレクトリの名前変更に対して Git は対応していない．これbrowsercamera

music

phone

EMFC

struts2

は，版管理システムが各ファイルの版管理を対象としており，ディレクトリの版管理を対象としていないからである．
そのため，クローンセットに名前変更が起こった場合の履
図 5 クローンセットのメソッドを変更した開発者数

歴出力には Git 備え付けのコマンドだけでは十分でない．

Fig. 5 Number of developers who changed methods in clone

4.2 節の適用実験では，名前変更があった場合は変更前の追sets

跡をしていない．ディレクトリの名前変更や移動検出に対
応 [4] したコマンドの実装を行うことは今後の課題である．

となったものも一部あることを確認した．
次に，人的属性として開発者数を計測した．図 5 は，ソ

5.3 スケーラビリティ

フトウェアごとにクローンセットを変更した開発者数をまCloneHistorage の構築は，全コミット時のスナップショッ

とめたボックスプロットである．Camera や Music は，多トを再構成するため，コミット数とファイル数が多いほど

くの開発者に変更されているのに対して，Phone のクロー時間を必要とする．適用実験では CloneHistorage の構築

ンセットを変更した開発者数は少ないことが確認できる．

に，最も規模の小さい Music で 6 時間，最も規模の大きい

我々の知る限り，コードクローンの履歴に関して人的属性

Struts 2 で 4 日掛かった（Xeon 2×2.26GHz プロセッサ，に関する分析を行ったのは，これが初めてである．

16GB メモリの Mac Pro で実行）．CloneHistorage は一度

こうした多様な分析は，CloneHistorage を用いるからこそ容易にできる．

5. 議論
5.1 クローンセットの名前衝突
本稿では，クローンセットの名前付けが重複した場合，ハッシュ値を用いることで唯一の名前となるよう実装した．しかし，この名前は履歴を分析する場合にわかりやす
くない．今後の課題として，より適切な名前付けが課題となる．
クローンセットの名前衝突が起こるのは，以下の 2 つの場合がある．

構築すれば以降容易にリポジトリマイニングが可能になる．しかしその構築のスケーラビリティは高くない．これは，現状全スナップショットに対してコードクローン検出を行っているからである．各コミットでは一部のファイルしか変更しないことが多いため，変更したファイルだけを追加で処理するインクリメンタルなコードクローン検出 [5]を行えば実行時間を大幅に減らせる可能性がある．

6. おわりに
コードクローン履歴の管理と分析は，ソフトウェア進化に対する知見の発見と保守性向上の面から重要な課題であり，近年注目されている．一般的な開発履歴のデータマイ• 無関係のクローンセットに，偶然同じ名前付けを行った．

ニングは，ソフトウェア工学の多くの研究テーマで有用な• クローン検出では別々のクローンセットとされたが，知見を報告しており，コードクローンの履歴に対しても期人が見た場合には一つのクローンセットと判断できる．

待される．しかし，コードクローンの履歴分析は，コード

前者の場合に対応するためには，3.5.2 節に示した名前付

片とクローンセット（コードクローン関係にあるコード片

け手順の工夫が必要である．一方，後者の場合は同一のクの集合）履歴の追跡や，データベースの構築などが必要とローンセットとして扱った方が好ましいと思われる．コーなる難しい課題である．この難しさから，現状のコードク

ドクローン検出時の閾値調整や他のコードクローン検出

ローン履歴の研究は，版管理システム CVS を分析対象とツールの再実行などを行い，クローンセットの再評価を行していた初期のリポジトリマイニングの研究フェーズに似うことが必要と考える．どんなクローンセットの履歴情報ている．リポジトリマイニングの研究は，版管理システム

c 2012 Information Processing Society of Japan7

ソフトウェアエンジニアリングシンポジウム 2012の発展（Subversion や Git）からより簡単に履歴分析ができるようになり，コード履歴だけでなく，プロセスや人的[11]属性などの多様な面からのデータマイニングの研究が行われ，多くの有用な知見が報告されてきた．
本稿では，コードクローン履歴に対して，これまでのリポ[12]

ジトリマイニングと同様に多様な面からの分析を可能にするため，リポジトリマイニング可能なコードクローン版管

[13]

理システム CloneHistorage を提案した．Eclipse，Apache，

Android から選択した 6 つのオープンソースソフトウェア[14]に対して適用し，評価とリポジトリマイニングを行った．
今後の課題には，CloneHistorage 構築のスケーラビリティ
向上，履歴分析を容易にするコマンドの実装，クローンセットの名前付け方法の改善などがある．
謝辞

[15]

本研究は，日本学術振興会科学技術研究費補助金

特別研究員奨励費（課題番号：23・4335），日本学術振興会
科学研究費補助金基盤研究 (A)(課題番号：21240002)，萌[16]

芽研究 (課題番号：23650014，24650011)，若手研究 (A)(課
題番号：24680002) の助成を得た．

[17]

参考文献
[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

Duala-Ekoko, E. and Robillard, M. P.: Tracking CodeClones in Evolving Software, Proc. of 29th Int. Conf.
on Softw. Eng., ICSE ’07, pp. 158–167, (2007).
Göde, N. and Koschke, R.: Frequency and risks ofchanges to clones, Proc. of 33rd Int. Conf. on Softw.
Eng., ICSE ’11, pp. 311–320, (2011).
Hata, H., Mizuno, O. and Kikuno, T.: Historage: FineGrained Version Control System for Java, Proc. of 3rd
Joint Int. and Annual ERCIM Workshops on Principles of Softw. Evolution and Softw. Evolution Workshops, IWPSE-EVOL ’11, pp. 96–100, (2011).
Hata, H., Mizuno, O. and Kikuno, T.: Inferring Restructuring Operations on Logical Structure of Java Source
Code, Proc. of 3rd Int. Workshop on Empirical Softw.
Eng. in Practice, IWESEP ’11, pp. 17–22, (2011).
Higo, Y., Yasushi, U., Nishino, M. and Kusumoto, S.:
Incremental Code Clone Detection: A PDG-based Approach, Proc. of 18th Work. Conf. on Reverse Eng.,WCRE ’11, pp. 3–12, (2011).
Higo, Y. and Kusumoto, S.: Code Clone Detection on
Specialized PDGs with Heuristics, Proc. of 15th European Conf. on Softw. Maintenance and Reengineering,
CSMR ’11, pp. 75–84, (2011).
Juergens, E., Deissenboeck, F., Hummel, B. and Wagner,
S.: Do code clones matter?, Proc. of 31st Int. Conf. on
Softw. Eng., ICSE ’09, pp. 485–495, (2009).
Kapser, C. J. and Godfrey, M. W.: ”Cloning considered harmful” considered harmful: patterns of cloning insoftware, Empirical Softw. Eng., Vol. 13, pp. 645–692,(2008).
Kim, M., Sazawal, V., Notkin, D. and Murphy, G.: An
empirical study of code clone genealogies, Proc. of 5th
Joint Meeting of the European Softw. Eng. Conf. and
the ACM SIGSOFT Symp. on the Found. of Softw.
Eng., ESEC/FSE-13, pp. 187–196, (2005).
MacDonell, S., Shepperd, M., Kitchenham, B. and
Mendes, E.: How Reliable Are Systematic Reviews in
Empirical Software Engineering?, IEEE Trans. Softw.

c 2012 Information Processing Society of Japan

[18]

[19]

[20]

[21]

[22]

[23]

Eng., Vol. 36, pp. 676–687, (2010).
Nguyen, H. A., Nguyen, T. T., Pham, N. H., AlKofahi, J. and Nguyen, T. N.: Clone Management for
Evolving Software, IEEE Trans. Softw. Eng., Vol. 99,
No. PrePrints, (2011).
Pate, J. R., Tairas, R. and Kraft, N. A.: Clone evolution:a systematic review, Journal of Software Maintenanceand Evolution: Research and Practice, pp. 1–23, (2011).
Rahman, F., Bird, C. and Devanbu, P.: Clones: What isthat smell?, Proc. of 7th IEEE Work. Conf. on Mining
Softw. Repositories, MSR ’10, pp. 72–81, (2010).
Sridhara, G., Hill, E., Muppaneni, D., Pollock, L. andVijay-Shanker, K.: Towards automatically generating
summary comments for Java methods, Proc. of 25th
IEEE/ACM Int. Conf. on Automated Softw., ASE ’10,
pp. 43–52, (2010).
Thummalapenta, S., Cerulo, L., Aversano, L. and
Di Penta, M.: An empirical study on the maintenanceof source code clones, Empirical Softw. Eng., Vol. 15,
No. 1, pp. 1–34, (2010).
Zibran, M. F. and Roy, C. K.: The Road to Software Clone Management: A Survey, Technical report,
Department of Computer Science, The University of
Saskatchewan, Canada (2012).
畑 秀明，水野 修，菊野 亨：リポジトリ再構築によるメソッドトレーサビリティの実現，ソフトウェアエン
ジニアリングシンポジウム 2010 (SES2010)，情報処理学会，pp. 57–62 (2010).
畑 秀明，水野 修，菊野 亨：不具合予測に関するメト
リクスについての研究論文の系統的レビュー，コンピュー
タソフトウェア， Vol. 29, No. 1, pp. 106–117 (2012).
神谷年洋，肥後芳樹，吉田則裕：コードクローン検出技術の展開，コンピュータソフトウェア， Vol. 28, No. 3,
pp. 29–42, (2011).
肥後芳樹，楠本真二：実規模ソフトウェアへの適用を目的としたプログラム依存グラフに基づくコードクローン検出法，ソフトウェアエンジニアリング最前線 2008 (2008).
肥後芳樹，楠本真二，井上克郎：コードクローン検出とその関連技術 (ソフトウェア工学)，電子情報通信学会論文
誌. D, 情報・システム， Vol. 91, No. 6, pp. 1465–1481,(2008).
阿萬裕久，野中 誠，水野 修：ソフトウェアメトリクスとデータ分析の基礎，コンピュータソフトウェア，Vol. 28,
No. 3, pp. 12–28 (2011).
小林隆志，林 晋平：データマイニング技術を応用した
ソフトウェア構築・保守支援の研究動向，コンピュータ
ソフトウェア， Vol. 27, No. 3, pp. 13–23 (2010).

8