コードクローンの複雑度メトリクスを用いた開発者の特徴分析
東誠†
松 下

肥 後 芳 樹†誠†
井 上

早 瀬克 郎†康裕†

ソフトウェアシステム内に存在する重複したコード片であるコードクローンは，単に取り除くのではなく適切に管理する必要がある．本研究では，コードクローンの管理を目的として，コードクローンを編集した開発者に着目したコードクローンの編集傾向分析を行う．具体的には，リポジトリに保存されたソフトウェア編集履歴から，コードクローンに対する変更を取り出し，そのコードクローンに対するメトリクス値の変化を計算する．そして，開発者によってメトリクス値の変化量に差があるかを分析する．提案する調査方法を用いて，実際のソフトウェア開発履歴を分析した結果，メトリクスの変化は開発者ごとに差があることが分かった．

Extracting Developers’ Characteristics from
Complexity Metric Values on Code Clones
M AKOTO H IGASHI ,† YOSHIKI H IGO ,† YASUHIRO H AYASE ,†M AKOTO M ATSUSHITA† and K ATSURO I NOUE†
A duplicated code fragment in a software system is called code clone, or simply clone. Clones degrade
software maintainability, but it is more practical to manage clones than to remove all of them. This paper
proposes a method to analyze developers’ tendencies to edit clones. At first, the snapshots of the source codeof the target software system are checked out from its software repository. Then, clone metric values for eachsnapshot are computed. Next, differences of metric values between adjacent snapshots are calculated. Finally, differences of metric values are grouped by developers and the developers are assessed statistically.
Applying the method to an open software project shows that developers edit clones in different manner.

向とする）を調査する．各開発者は様々な役割や目的

1. は じ め にに従って編集するため，それぞれの編集傾向は異なるソフトウェアシステムの保守性を悪化させる問題のと考えられる．また，編集傾向によって各コードクロー1 つとして，ソフトウェアシステム内に存在する重複しンの複雑度の変化を予測できると考えられる．よって，

9)たコード片（コードクローン）がある ．例えば，ある編集傾向を用いて，すべてのコードクローンの中からコード片に欠陥が存在する場合，そのコード片とコー将来複雑になって除去し難くなるものとそうでないもドクローンになっているコード片にも同様の修正を検のを区別できると考えられる．

3)

討する必要があり，修正の労力を増大させる ．

具体的には，版管理システムの 1 つである CVS1) にしかし，すべてのコードクローンを除去することが管理されているリポジトリに保存されたソフトウェア

効果的なわけではない4) ．このため，すべてのコードの編集履歴からコードクローンへの変更を取り出し，クローンを取り除くのではなく，コードクローンを適

そのコードクローンに対するメトリクス値の変化を計切に管理することが必要であるとされている4),6) ．

算する．そして，開発者ごとにメトリクス値の変化にそこで本研究では，コードクローン管理のための基差があるかを調査する．

準として，各開発者の編集時に他の開発者に比べて以降，2 章では編集傾向の詳細な定義を述べる．3

コードクローンの複雑度に表れる特徴（以下，編集傾

章では手法の説明として，版管理システムからソフト† 大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology, Osaka
University

ウェアの編集履歴を取り出し，それを利用して開発者の編集傾向の有無を検定する方法について述べる．4
章では本手法を実際のソフトウェアに対して適用した

結果と，それに対する考察を述べる．最後に，5 章で本研究のまとめと今後の課題について述べる．

2. 編集傾向の定義
本研究では，編集傾向を「ある開発者のソースコー

cd ∈TS(cb )}• TokSum(cc , cd ) =TokPair(cc , cd ) の要素数
• Sim(ca , cb ) =TokSum(ca , cb ) × 2 ÷ (ca のトークン数 +cb のトークン数 )2.2 検定用データ

ドに対する編集作業の前後において，ソースコードに複雑度の変化と開発の相関を検定するために，開含まれるコードクローンの複雑度の変化に関する，他発者を行，コードクローンの複雑さを表すメトリクの開発者と比べた傾向」として定義する．これは「複ス (以下，複雑度メトリクスとする) を列とする表を雑度を大きくする傾向にある」「複雑度を小さくする検定用データとする．本研究では，複雑度メトリクス傾向にある」「傾向があるとはいえない」のいずれかをコードクローンの長さ（LEN），コードクローンのであり，それぞれ +, −, = と表す．

トークンの種類数（TKS），コードクローン中のルー

本節では，編集傾向を定義するために必要となる諸定義について述べる．

2.1 クローン対応関係

プの数（LOOP），コードクローン中の条件分岐の数（COND），LOOP+COND（McCabe）2) とする．
行が開発者 A であり，列がメトリクス X である升編集によるコードクローンの複雑度の変化を取得す目の要素は，開発者 A が特定のソフトウェアのソースるために，編集前後のソースファイル中で同じ位置にあコードに対して行ったすべての編集についてクローンるコードクローンの対応関係を定義する．編集前後の対応関係にあるコードクローン Ct ,Ct+1 のメトリクス

ソースファイル Ft , Ft+1 にそれぞれ存在するコードク

X の値の差のうち，以下のいずれかの条件を満たすもローン Ct , Ct+1 について，以下の関係 CR(Ct , Ct+1 )ののリストとする．

が真である時，Ct は Ct+1 間でクローン対応関係があ• Ct と Ct+1 のメトリクス X の値の差が 0 でないるとする．

• 開発者 A が編集したファイルの変更差分と重複• CS(F ):ソースファイル F に存在するすべてのコー
ドクローンの集合• Sim(ca , cb ):コード片 ca ,cb の類似度．詳細は後述
する• O(cc , cd , F ) = (Sim(cc , cd ) > 0) ∧ (∀ca ∈CS(F )Sim(cc , ca ) ≤Sim(cc , cd ))• CR(Ct , Ct+1 , Ft , Ft+1 ) = O(Ct , Ct+1 , Ft+1 ) ∨O(Ct+1 , Ct , Ft )また，Ft , Ft+1 にそれぞれ存在するコード片 ca , cbの類似度 Sim(ca , cb ) は以下のようにして求める．
まず，Ft , Ft+1 をトークン列 Pt , Pt+1 に変換し，各トークンに通し番号を振る．

する箇所に Ct が存在する

2.3 開発者 A によるメトリクス X の値の変化頻度
各メトリクス値と開発者の相関を表すために，開発者 A の編集時に他の開発者と比べて表れることが多いメトリクス X の値の変化を，開発者 A によるメトリクス X の値の変化頻度として定義する．これは「大きくなることが多い」「小さくなることが多い」「頻度に有意差が見られない」のいずれかであり，それぞれ+,−,N で表す．
検定用データ中でメトリクス X の列に対し，開発者 A が他の開発者と有意差がなければ開発者 A によるメトリクス X の値の変化頻度を N とする．有意差

次に，Pt , Pt+1 にそれぞれ存在するトークン Tc , Tdがある場合，X の列の要素を開発者 A の群とそれ以がトークン列中で同じ位置にあることを表す対応関係

外の群に分け，各群の要素の順位平均 Aa ,Ar を求めTR(Tc , Td ) を求める．関係 TR(Tc , Td ) は以下の条件

る．Aa > Ar なら開発者 A によるメトリクス X の値をすべて満たす時に真とする．の変化頻度は +，そうでなければ − とする．

• Tc , Td がそれぞれ，差分情報中の Pt , Pt+1 の変
更箇所に含まれていない• Pt , Pt+1 中の各トークンの通し番号を対応付け
る5) と，Tc , Td の通し番号が一致する
そして，TR(Tc , Td ) の情報を用いて Sim(ca , cb ) を計算する．Sim(ca , cb ) は以下の式によって求められる．

• TS(C):コード片 C 中に存在するすべてのトークンの集合• TokPair(ca , cb ):{(cc , cd ) |TR(cc , cd ), cc ∈TS(ca ),2.4 開発者の編集傾向
開発者 A の編集傾向は，開発者 A によるすべての複雑度メトリクスの値の変化頻度の中で，+ が − より多い場合に +，− が + より多い場合に −，両者の個数が等しい場合に = とする．

3. 開発者ごとの編集傾向の調査手法
本節では，開発者ごとの編集傾向の調査手法について述べる．調査手法の概要を図 1 に示す．本手法は図U&WV +
78 9 --;: =< ?>A@  &/SR5TI-0/

B 9C >A@ 9 - &EFGAH,I-0/ =1 J *"O*POQ  
78 9 --;: < ?>A@  )B 9C >A@ 9 - )EFGAH,I-/ =1 J EFGAH,I-0/ =1 J $!&EF5KML,I-0/ =1 J 

EFGAH,I-/ =1 J 
EF5KNL,I-/ =1 J 

EF5KML,.-0/  1=J )

EF5KNL,I-/ =1 J   B 9C >A@ 9 -*DU )V + 

,.-0/  1!"#%$!&'(*)

UD V  +  ,I-0/

=1XZYM[I\$$ 2354 6

図 1 検定手法の概要
Fig. 1 abstract of method to test

中に示す (1) から (3) の 3 つのステップからなる．

データの要素に含める．また，ソースファイル Fb のまず，(1) で一度のコミット作業による一群のファコードクローンは編集されてないので，メトリクス X

イルに対する変更（以下，コミットトランザクションの値の差のうち，+2 だけを検定用データの要素に含とする）の情報を抽出し，各コミットトランザクショめる．

ン前後の時点のソースコードからコードクローンを検一方，開発者 B のコミットトランザクションではす出する．次に，(2) で対応関係にあるコードクローン

べてのメトリクス X の値の差が 0 だが，Fa のコードから，検定用データを取得する．最後に，(3) で検定クローンは編集されているので，そのメトリクス X の用データを対象として検定する．

値の差は検定用データの要素に含める．

以降，各ステップの詳細を説明する．

3.3 検定用データを対象とした検定

3.1 コミットトランザクション情報の抽出

3.2 節で取得した検定用データを対象として検定す

まず，版管理システムのリポジトリに保存されている (図 1 の (3))．

るソフトウェアの編集履歴から，コミットトランザク検定用データの開発者 A による各メトリクスの値ションの情報を抽出する (図 1 の (1))．各コミットトの変化頻度を求めるため，まず，各メトリクスを対象

ランザクションには，編集されたファイルのパス名やとして Kruskal-Wallis 検定7) を用いる．これにより，1

変更差分，編集後のリビジョン番号やファイルの状態，人以上の開発者が他の開発者と有意差があるかを調査

およびコミットの日時やログ，開発者の情報が含まれする．

る．また，コミットトランザクションはコミットの日時が早い順に並べ，1 から順に通し番号を振る．

次に，有意差があると判断されたメトリクスの列の検定用データに対し，各開発者と他の開発者間の有意そして，コミットトランザクション 1 の直前の時差の有無を検定する．開発者 A とメトリクス X に対す点および各コミットトランザクションの直後の時点のるこの検定を行うには，メトリクス X の列にある要素ソースコード（以下，スナップショットとする）を取得を開発者 A の群とそれ以外の群に分け，Mann-Whitney

し，日時の早い順に通し番号を振る．その後，スナップの U 検定8) (以下，単に U 検定とする) を行う．

ショット中のコードクローンを検出し，スナップショッ
トに存在するソースファイル間のクローン対応関係を抽出する．

4. ケーススタディ
3 章で説明した手順に従って，PostgreSQL の調

3.2 検定用データの取得査を行った．PostgreSQL の CVS リポジトリから，次に，3.1 節で取得したすべてのコミットトランザ

1997/01/01 〜 1999/06/30 の 2 年半を半年間ずつに分クション中のクローン対応関係から，検定用データをけ，各期間中の編集履歴を調査した．なお，各調査期取得する (図 1 の (2))．

間は 1〜5 の通し番号をつける．2.1 項のソースファイ

図 1 では，開発者 A のコミットトランザクション
ではソースファイル Fa のコードクローンが編集されているため，メトリクス X の値の差はすべて検定用

ルのトークン列変換および 3.1 節のコードクローン検
出には CCFinderX2) を用いた．
各期間中の編集履歴から得られた検定用データに対し有意水準 5%で Kruskal-Wallis 検定を行った結果をなる可能性が高い．そのため，前者の除去は優先

表 1 に示す．

し，後者の除去は後回しにすべきだと考えられる．

また，Kruskal-Wallis 検定によって有意差があると• 開発者 B や開発者 E は時期によって編集傾向が判断されたメトリクスの検定用データに対し，3.3 節で異なっているため，今後も継続して編集傾向を調述べた U 検定による方法を有意水準 5%で用いて，各査すべきだと考えられる．

開発者によるメトリクス値の変化を調べた結果を表 2に示す．
表 2 より，以下のことがわかる．

5. まとめと今後の課題
本研究では，複雑度メトリクス値の変化を用いて，• 開発者 G の編集傾向はすべての期間で + だが，コードクローンの編集傾向を調査した．その結果，メ開発者 A の編集傾向は各期間で − と = のいずれトリクスの変化は開発者ごとに差があり，各開発者のかである．これより，開発者 G，開発者 A の編集編集傾向によるコードクローン管理方法が提案できるするコードクローンはそれぞれ複雑，簡単になることが分かった．

傾向があるといえる．

今後の課題としては，他のメトリクス値を用いた編• 開発者 B，開発者 E の編集傾向は期間によって +と − の両方があり，正反対になっている．

者以外の要因による影響の除外が挙げられる．

これらの観察と，開発者が近傍のソースコードを連続して編集することが多いことから，以下のような方法でコードクローンを管理することが考えられる．

• 開発者 G，開発者 A が最近編集した所の近傍にあるコードクローンは，それぞれ今後複雑，簡単に
表 1 Kruskal-Wallis 検定の結果
Table 1 The result of Kruskal-Wallis test
期間LENTKSLOOPCOND
McCabe1有無有有有2有有無有無3有有無有有4有有無有有5有有有有有

表 2 U 検定の結果
Table 2 The result of Mann-Whitney U Test
人ABCDEF
G
H
IJK
L

期間
12345123451234512345345454513555LEN−+N
N+−
N
N+−
N
N+
N−+−−−−+
N−
N−+−N
N
N
N
N

TKS
NN
N
N
N
N+−−N
N
N
N
N
N
N
N
N
N
N
N+N
N−N+N
N+N−

LOOPNN
N
N
N+N
N
N
N
N
N
N
N+−N
N
N+N
N
N
N−N+N
N
N
N
NCOND
N−N−−−
N
N+N+
N
N−
N
N+−−+++−
N−
N+N
N
N
N
−

McCabe
N
N
N
−−−
N
N+N+
N
N
N
N
N
N−−+++−
N−
N+
N
N
N
N
−

集傾向の調査や，モジュールや開発時期といった開発傾向−==−−−+−+−+=+−===−−+++−
N−++==+=−

参考文献1) Berliner, B.: CVS II: Parallelizing Software Development, Proc. USENIX Winter 1990 Technical Conference, pp. 341-352 (1990).
2) Kamiya, T.: CCFinder Official Site, available from〈http://www.ccfinder.net/〉(accessed 2008-5-20).
3) Geiger, R., Fluri, B., Gall, H. C. and Pinzger, M.:
Relation of code clones and change couplings, In
Proc. FASE 2006, pp. 411-425 (2006).
4) Kapser, C. and Godfrey, M. W.: “Cloning Considered Harmful” Considered Harmful, Proc. 13thWorking Conference on Reverse Engineering, pp.1928 (2006).
5) 川口真司，松下誠，井上克郎，飯田元：コードクローン履歴閲覧環境を用いたクローン評価の試み，情報処理学会研究報告，Vol. 2006，No. 125，
pp. 49-56 (2006).
6) Kim, M. and Notkin, D.: Using a clone genealogy
extractor for understanding and supporting evolutionof code clones, Proc. 2nd Int. Workshop on Mining
Software Repositories, pp. 17-21 (2005).
7) Kruskal, W. H. and Wallis, W. A.: Use of ranks
in one-criterion variance analysis, J.Am.Stat.Assoc.,
Vol. 47, No. 260, pp. 583-621 (1952).
8) Mann, H. B. and Whitney, D. R.: On a test ofwhether one of two random variables is stochastically larger than the other, Annals of MathematicalStatistics, Vol. 18, pp. 50-60 (1947).
9) Roy, C. K. and Cordy, J. R.: A Survey on Software
Clone Detection Research, Technical Report 2007541 (2007).