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

CRD を用いた
コードクローンの生存期間と修正回数に関する調査堀田 圭佑1,a)

肥後 芳樹1,b)

楠本 真二1,c)

概要：これまでに，コードクローンの進化の様子を分析し，その特徴を調査する研究が多数行われている．
しかし，これまでの調査手法には，コードクローンに対して大きな修正が加えられた場合に追跡に失敗するおそれがあるという課題がある．また，ソフトウェア保守に悪影響を与えるコードクローンがどの程度存在するのか，という点や，コードクローンが修正される時期に何らかの特徴があるか，という点は明らかになっていない．本研究では，ソースコードに対する修正に強いコードクローン追跡手法である CRDを用いて，これまでに明らかにされていない事項に対する調査を行った．調査の結果，コードクローンの多くは短命であり，かつ修正されにくいという既存研究の知見を改めて確認した．また，コードクローン
は生存期間の前半に修正されやすいことが明らかになった．さらに，生存期間が長く，かつ修正回数の多いコードクローンが全体の約 3.3%存在することがわかった．
キーワード：コードクローン，CRD，ソフトウェア進化

A CRD-based Analysis on Survival Periods andModifications of Code Clones
Keisuke Hotta1,a)Yoshiki Higo1,b)

Shinji Kusumoto1,c)Abstract: Many researchers analyzed evolution of code clones based on clone tracking. However, clone
tracking used in previous research has an issue that it might miss links of clones among revisions if a large
modification was applied to them. In addition, there are some characteristics that the previous research did
not reveal. This research revisits findings of previous research with a clone tracking technique that ahas agood change-tolerance, named CRD. Our experimental results support findings of previous research, including ‘most of clones are short-lived’, and ‘there are a few clones that are modified multiple times’. In addition,
the results showed that about 3.3% of clones are long-lived and modified multiple times. Moreover, we foundthat there is no obvious trends on the timing when clones are modified.
Keywords: Code Clone, CRD, Software Evolution

1. まえがき因として糾弾され，注目を集める研究分野となって久し
い [1], [2]．コードクローンによってもたらされる弊害を防

コードクローン (ソースコード中の同一，あるいは類似

ぐために，ソースコード中からコードクローンを自動的にするコード片) が効率的なソフトウェア保守を阻害する要検出する手法や，その除去作業を支援する手法がこれまでに多数提案されている [3], [4]．

1

a)
b)
c)

大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology, Osaka University
k-hotta@ist.osaka-u.ac.jp
higo@ist.osaka-u.ac.jp
kusumoto@ist.osaka-u.ac.jp©2013 Information Processing Society of Japan

コードクローンへの効率的な対処 (除去や監視など，コー
ドクローンに対して注意を払うすべての行為 [1]) を実現するためには，コードクローンが持つ特性を理解する必要がある．この考えに基づき，コードクローンを分析する研究1

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

が多数行われている [5], [6], [7], [8]．コードクローンの分の対処が効果を発揮する事例が実在するといえる．また，析を行うために，修正前後のソースコード間でコードク

コードクローンは生存期間の前半に修正されやすいというローンの対応付けを行うこと，すなわちコードクローンの知見は，なるべく早期にコードクローンに対処を行うこと

追跡を行うことが必要となる．既存研究は，コード片の文が重要であることを示唆している．ただし，コードクロー

字列の類似度を算出し，高い類似度を持つコード片を対応

ンの多くは生存期間が短く，かつ修正されにくいものであ付けることでコードクローンの追跡を実現している．しかるということも改めて確認できたという点から，対処する

しこの追跡方法には，コードクローンを構成するコード片

コードクローンを慎重に選択する必要性があるといえる．

に大きな修正が施された場合，対応付けができず，追跡に失敗するおそれがある，という課題点が存在する．
また，近年の調査の結果，すべてのコードクローンがソ

2. 調査の目的
2.1 コードクローンの進化に関する既存研究

フトウェア保守に悪影響を与えているとは言い難く，一部

これまでに，コードクローンがどのように進化していのコードクローンのみが対処を必要とするものであること

るのかを調査する研究が行われている．Kim らの研究はが指摘されている [6], [9]．対処を必要とするコードクロー

それらのさきがけとなったものである [5]．この研究では，

ンの特性として，以下のものが挙げられる．

CCFinder を用いて検出されたコードクローンを追跡し，• 生存期間が長いこと

その生存期間の長さを調査している．調査の結果，コード• 頻繁に修正されることクローンの多くは生存期間が短いことが明らかとなった．

生存期間の短いコードクローンへ対処を行った場合，対Göde と Koschke はコードクローンがその進化の過程で処したコードクローンがすぐに消滅してしまうため，かけどの程度修正されているのかを調査した [6]．その結果，た労力に見合う恩恵が得られない [5]．また，コードクロー

コードクローンのほとんどは修正回数が 1 回以下であり，ンによってもたらされる悪影響の最たるものとして，修正

複数回修正されるものは全体の約 12%程度であったことが漏れによる不具合が指摘されていることから，修正されな報告されている．

い安定したコードクローンへ対処を行うことも効果的であThummalapenta らはコードクローンに加えられる修正るとは言い難い [9], [10]．しかし，これまでの調査では，生のパターンに関する調査を行った [12]．その結果，コード

存期間が長くかつ多数修正されているコードクローンがどクローンに対する修正漏れはほとんど起きていないことがの程度存在するのかという点は明らかにされていない．

明らかになった．その一方で，コードクローンに対する修

また，コードクローンがその生存期間のどの時点で修正されるのか，という点も効率的なコードクローンへの対処

正漏れは数こそ少ないものの，不具合に直結する危険性が高いということも報告されている．

を考える上で重要である．例えば，コードクローンが生成

これら以外にも，コードクローンに対する修正漏れの発された直後に頻繁に修正され，その後安定するのであれば，生頻度は低いこと [13]，また，コードクローンに起因する

生成直後に対処を行うことが必要であると考えられる．

不具合の数は多くないこと [7] が指摘されている．

そこで本研究では，ソースコードに対する修正に強い

さらに，コードクローンに加えられる修正の頻度を比較

コードクローン追跡手法である CRD [11] を用いることですることでコードクローンの有害性を調査する研究が多く

既存研究の課題点を解決するとともに，まだ明らかにされの研究者によって行われている [9], [10]．これらの研究のていないコードクローンの特性を調査する．

結果，コードクローンはコードクローンとなっていない箇

6 つのソフトウェアに対する調査の結果，以下のことが明らかになった．

• コードクローンの多くは短命であること，また複数回修正されるコードクローンは少ないことが報告されて所と比較して修正されにくいことが明らかになっている．
その一方で，コードクローンに対する修正漏れが多数存在し，またそれらによって多くの不具合が引き起こされているとする結果も報告されている [14]．

いるが，CRD を用いた場合でもそれらが成り立つ．

これらの調査結果は，「すべてのコードクローンが有害• コードクローンの生存期間と修正回数の間に相関はとはいえないが，一部有害なコードクローンが実在する」

ない．

• コードクローンは生存期間の前半に修正されやすい傾向にある．

ことを示唆している．したがって，コードクローンに対して効率的に対処を行うためには，有害なものを特定し，それらに注力することが必要であるということができる [6]．

• 生存期間が長く，かつ複数回修正されるコードクロー
ンは，すべてのコードクローンのうち約 3.3%である．

2.2 調査項目

これらの調査結果を総合すると，生存期間が長いコード

本研究では，コードクローンの追跡を通じてコードク

クローンの中にはほとんど修正されないものもあれば，頻ローンの進化の様子を分析し，その特性を明らかにするこ繁に修正されるものも存在しており，コードクローンへとを目指す．本調査の目的は以下の 2 点である．

©2013 Information Processing Society of Japan2

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

int method(int a, int b) {int c = 0;
if (a == 0) {c = c + 1;}
if (b == 1) {c = c + 2;}
return a + b + c;
}

STEP
1&2

int method(int a, int b) {int c = 0;
IF (a == 0)
IF (b == 0)
return a + b + c;}
if (a == 0) {c = c + 1;}

図 1

int method(int $, int $) {int $ = $;STEP
IF (a == 0)
3&4&5
IF (b == 0)
return $ + $ + $;}if (b == 0) {c = c + 2;}

if ($ == 0) {$ = $ + $;
}

20

10

if ($ == 0) {$ = $ + $;}20

コードクローン検出手法の概要

Fig. 1 An Overview of the Clone Detection Method• コードクローンの追跡を行う際に，修正に強い追跡手法を用いることで，これまでの研究で得られた知見に差異が生じるか否かを確認する．

• これまでの研究で明らかにされていないコードクロー
ン進化の特性を明らかにする．
これらの調査目的を達成するために，以下に挙げる 4 つ

調査を実現するためには高速なコードクローン検出方法を用いる必要がある．
そこで本研究では，ブロック単位のコードクローン検出手法を採用した．このコードクローン検出手法における処理の手順は以下の通りである．
ステップ 1: 字句解析及び構文解析の研究課題を設定した．

ステップ 2: ブロックの特定

RQ1: 既存研究 [5] から得られた ‘コードクローンの多く

ステップ 3: 正規化

は生存期間が短い’ という知見は CRD を用いた場合

ステップ 4: ハッシュ値の算出でも成立するか.

ステップ 5: コードクローンの特定

RQ2: 既存研究 [6] から得られた ‘複数回修正されるコー
ドクローンは少ない’ という知見は CRD を用いた場

図 1 に本研究で用いるコードクローン検出手法の概要を示す．以降，それぞれのステップについて述べる．

合でも成立するか．

RQ3: コードクローンの生存期間の長さとコードクロー
ンに加えられる修正回数の間に正の相関はあるか．

RQ4: コードクローンは生存期間の前半に修正されやすステップ 1: 字句解析及び構文解析
入力として与えられたソースコードに対して，字句解析
及び構文解析を行う．

い傾向にあるか．
このうち，RQ1 と RQ2 は既存研究で調査されている項

ステップ 2: ブロックの特定目であり，修正に強い追跡手法を用いた場合でも同様の知

このステップではブロックの特定を行う．ここで “ブ見が得られるのかを確認するために設定した. 今回は比較

ロック” には，各種ブロック文に加え，クラス，メソッド，

対象として，Kim らの研究 [5]，及び Göde らの研究 [6] を関数なども含まれている．さらに，このステップではサブ選定した．これらの研究を比較対象として選択した理由

ブロックを特殊な文字列に置き換える処理も併せて行う．

は，これらの研究から得られている上述の知見がコードク

この特殊な文字列には以下の情報が含まれている．

ローン分析の研究に与えている影響が大きいためである．
一方，RQ3 及び RO4 はこれまでの研究で得られていな• ブロックの種類• 条件式 (条件式を持つ場合のみ)

い特性を明らかにするために設定した項目である．生存期• シグネチャ (メソッド，関数の場合のみ)間の長さと修正回数の間に正の相関があれば，生存期間の• クラス名 (クラスの場合のみ)

長いものは修正の回数が多くなるため，生存期間の長いもこの処理により，ブロックで行われている処理の流れはのに注力をすることが修正回数が多いものに注力すること同じであるが，サブブロックで行われている処理が異なるにもつながるといえる．また，コードクローンがその生存場合であっても，それらのブロックをコードクローンとし期間の前半に修正されやすい傾向にあるのであれば，コーて検知することが可能となる．

ドクローンに対して何らかの対処を行う場合，そのコードクローンの生存期間の早い段階，すなわち生成された後なるべく早い段階で対処を始めることが，効率的なコードク
ローンへの対処の実現につながると考えられる．

3. コードクローンの検出方法
本調査では，対象ソフトウェアのすべてのリビジョンに対してコードクローン検出を行う必要がある．そのため，©2013 Information Processing Society of Japan

ステップ 3: 正規化
各ブロックに含まれる変数名並びにリテラルを特殊文字に置換する．これにより，変数名やリテラルのみが異なる
ようなコードクローンを検出することが可能となる．
ステップ 4: ハッシュ値の算出
正規化後の各ブロックを文字列に変換し，その文字列を3

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

<CRD> ::= <file> <class> <CM> [<method>]<method> ::= <signature> <block>*<block> ::= <btype> <anchor> <CM>
<btype> ::= ‘for’ | ‘while’ | ‘do’ | ‘if’ | ‘else’ | ‘switch’| ‘try’ | ‘catch’ | ‘finally’ | ‘synchronized’(a) 定義public class DeleteManager {...
public void delete(int n) {...
for (int i = 0; i < delete.size(); i++) {...
if (delete.get(i) instanceof ElementNode) {// some code}...

4.2 コードクローンの系譜
本小節では，コードクローンの系譜の定義を与える．なお以降の説明では，対象ソフトウェアのそれぞれのリビ
ジョンにはその識別のために一意な整数 (リビジョン番号)が割り当てられており，また連続するリビジョン間のリビ
ジョン番号は連続しているものと仮定している．
はじめに，互いにコードクローン関係にあるブロックの集合であるクローンセットを定義する．
定義 4.1 (クローンセット)

Br をあるリビジョン r に存在するブロックの集合とする．また，hash(b) をブロッCRD
packagename.DeleteManager.java,DeleteManager,5delete(int),5
for,delete.size(),4if,delete.get(i) instanceof ElementNode, 2

(b) 例
図 2

CRD の定義と例

Fig. 2 Definition and Example of CRD

ク b のハッシュ値とする．このとき，‘ハッシュ値が同じ’であることを同値関係としたときの同値類をクローンセッ
トと呼ぶ．また，以降ではリビジョン r に存在するすべてのクローンセットからなる集合を Cr と表記する．
次に，連続する 2 つのリビジョン間におけるブロック及びクローンセットの対応関係をそれぞれ以下に定義する．
定義 4.2 (ブロックの対応関係) br ，br+1 をそれぞれリ

もとにハッシュ値を算出する．

ビジョン r，r + 1 に存在するブロックであるとする．br のステップ 5: コードクローンの特定関係にあるといい，br ↔ br+1 と表記する．

CRD と br+1 の CRD が一致するとき，br と br+1 は対応
各ブロックから得られたハッシュ値を比較し，コードク
ローンの検出を行う．複数のブロックが同じハッシュ値を

定義 4.3 (クローンセットの対応関係)

リビジョン r に存在するクローンセット cr と，リビジョン r + 1 に存在持っている場合，それらのブロックは正規化後の文字列がするクローンセット cr+1 を考える．cr と cr+1 が以下のすべて等しい．したがって，同じハッシュ値を持つブロッ式 (1) を満たすとき，cr と cr+1 は対応関係にあるといい，クの集合が 1 つのコードクローンであるとみなされる．

4. コードクローンの追跡
4.1 Clone Region Descriptor

cr ⇔ cr+1 と表記する．なおこの対応関係は対称律を満たすため，cr ⇔ cr+1 が成り立つ場合，cr+1 ⇔ cr も成り立つ．
∃br ∈ cr , ∃br+1 ∈ cr+1 [br ↔ br+1 ](1)

これらを用い，コードクローンの系譜を以下に定義する．

Clone Region Descriptor (以降，CRD) とは，Duala-

定義 4.4 (コードクローンの系譜) 互いに対応関係にあEkoko と Robillard によって提案された，コードクローン

るクローンセットの集合をコードクローンの系譜 (以降，を構成するコード片のおおよその位置情報を示す表現形系譜) と呼ぶ．すなわち，CALL を検査対象期間において式である [11]．図 2 に CRD の定義，及びその具体例を示検出されたすべてのクローンセットからなる集合としたとす．CRD の定義は図 2(a) のようになっている．CRD はき，以下の式 (2)，及び式 (3) をともに満たす，クローンJava を対象に定義されているため，ブロックの種類にはセットの集合 g を系譜と定義する．

Java に存在するもののみが現れている．ここで，定義中のanchor はそのブロック特有の文字列を表しており，条件式などが該当する．また，signature はメソッドのシグネチャ
を，CM は各ブロックのメトリクス値 (サイクロマチック
数+fan-out 数) をそれぞれ表している．次に，CRD の例
を図 2(b) に示す．この例には，最もネストの深い位置に存在する if 文に対する CRD を記載している．あるブロックに対する CRD は，そのブロックに加えてその外側に位置するすべてのブロックの情報を用いて定義される．この例の場合，1 行目から 3 行目までの文字列は if 文の外側のブロックの情報を用いて算出されたものであり，4 行目の文字列が着目している if 文そのものの情報を用いて算出されたものとなっている．なお，この例は文献 [11] で用いられているものと同じものである．

©2013 Information Processing Society of Japan∀c ∈ g, ∀c′ ∈ CALL [(c ⇔ c′ ) → (c′ ∈ g)]′′′∀c ∈ g, ∃c ∈ g[c ⇔ c ∧ c ̸= c ]

(2)
(3)

4.3 コードクローンの生存期間
それぞれの系譜 g について，その始端リビジョン，終端
リビジョン，並びに生存期間を以下のように定義する．
定義 4.5 (始端リビジョン，終端リビジョン，生存期間)
T を分析対象となるリビジョンすべてからなる集合であるとする．このとき系譜 g について，式 (4) を満たすリビ
ジョン first ∈ T を g の始端リビジョンと定義する．
∃cfirst ∈ Cfirst [cfirst ∈ g]∧∀l ∈ T [l < first → ∀cl ∈ Cl (cl ∈
/ g)]

(4)

同様に，式 (5) を満たすリビジョン last ∈ T を g の終端

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

リビジョンと定義する．

B

A∃clast ∈ Clast [clast ∈ g]∧∀l ∈ T [last < l → ∀cl ∈ Cl (cl ∈
/ g)]

D

C

10

40

40

40

10

40

40

40

20

20

40

50

50

30

30

30

50

50

r+2

r+3

(5)

F

E

さらに，g の生存期間 R を以下の式 (6) に定義する．
R = {r ∈ T |first ≤ r ≤ last}

(6)
r
n

4.4 コードクローンへの修正

r+1
ハッシュ値 n のブロック

本研究では，系譜 g に加えられた修正の回数を以下のよ

クローンセット

うに算出する．
定義 4.6 (修正回数)

ある系譜 g ，及びその生存期間に

ブロックの
対応関係

r+4
クローンセットの
対応関係

修正された
クローンセット

図 3 コードクローン追跡の例

Fig. 3 An Example of Clone Tracking

含まれるあるリビジョン r を考える．g ，r が以下の式 (7)及び式 (8) のうち 1 つ以上を満たすとき，g はリビジョン
リビジョン r において修正されたと判断される．次に，リr において修正されたと定義する．

ビジョン r + 2 への修正により要素数が増加しているが，本∃cr ∈ Cr [cr ∈ g ∧ ∃br ∈ cr , ∃br+1 ∈ Br+1
[br ↔ br+1 ∧ hash(br ) ≠ hash(br+1 )]]研究では要素数の増加は修正とみなさないため，リビジョ(7)ン r + 1 では修正は行われなかったものとみなされる．リ
ビジョン r + 2 からリビジョン r + 3 への修正により，系譜∃cr ∈ Cr [cr ∈ g∧に枝分かれが生じている．このとき，式 (7) が成立するため，この系譜はリビジョン r + 2 において修正されたとみ∃br ∈ cr , ∀br+1 ∈ Br+1 [(br ̸↔ br+1 )∨ (br ↔ br+1 ∧ ∀cr+1 ∈ Cr+1 [br+1 ∈/ cr+1 ])]]

(8)

なされる．次にリビジョン r + 3 からリビジョン r + 4 への修正によって，D のクローンセットを構成するコード片式 (7) は対応関係にあるブロックのハッシュ値が異なる，
すなわちブロックを構成する文字列に修正が加えられた場
合を表している．また式 (8) は対応関係にあるブロックがリビジョン r + 1 に存在しない場合，あるいは対応関係にあに対応するブロックがリビジョン r + 4 に存在しなくなっている．したがって，式 (8) より，この系譜はリビジョン

r + 3 で修正されたと判断される．以上より，この系譜に加えられた修正回数は 3 となる．

るブロックがリビジョン r + 1 ではいずれのクローンセッ

5. 調査の準備

トにも含まれていない場合を表している．
さらに，対象ソフトウェアの最終リビジョンに存在しない系譜は開発期間の途中で消滅しており，その消滅のきっかけとなる何らかの修正が加えられていると考えられる．
このような理由から，本調査では系譜が最終リビジョンに存在しない場合，その系譜は終端リビジョンにおいて修正されたとみなす．すなわち，T を対象ソフトウェアのすべてのリビジョンからなる集合とし，last g を系譜 g の終端リビジョンとしたとき，以下の式 (9) が成立すれば g は last g

5.1 調査手法の実装
本研究では，4 で述べた調査手法を実装したツール Clone-

Tracker を用いて調査を行う．CloneTracker は Java で記述されており，3 で述べたコードクローン検出機能を内含している．CloneTracker は現在のところ，Java で記述されており，かつバージョン管理システム Subversion を用いて管理されているソフトウェアのみを解析可能である．なにおいて修正されたとみなす．以降，式 (9) により特定さ

お，文字列からのハッシュ値計算には，String 型が提供すれた修正を “消滅に関わる修正” と呼ぶ．

る hashCode メソッドを使用している．

∃r ∈ T [last g < r](9)

また，系譜 g が修正されたリビジョンの数を g に加えられた修正回数と定義する．

5.2 調査対象
本研究では，6 つのオープンソースソフトウェアを対象に調査を行った. それぞれのソフトウェアの概要を表 1 に示す. 表中の “リビジョン数” は分析対象となったリビジョ

4.5 追跡の例

ンの数，すなわちソースファイルに修正が加えられたリビ

図 3 にコードクローンの追跡の例を示す．この例には，ジョンの数を示している. また “行数” は終了リビジョンに

A，B，C，D，E，及び F の 6 つのクローンセットから構おける，調査対象以下のソースコードの行数を表している.

成される系譜が 1 つ存在する．リビジョン r に存在するク

これらはすべて Java で記述されたソフトウェアであり，

ローンセットは，次のリビジョンへの修正によりハッシュ

Subversion を用いて管理されている. これらのソフトウェ

値が変化している．したがって，式 (7) より，この系譜はアを選択した理由は以下の通りである.

©2013 Information Processing Society of Japan5

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

表 1

対象ソフトウェア

Table 1 Target Software Systems
ソフトウェア

調査対象

Ant/ant/core/trunk/src/main/

開始リビジョン (日付)

終了リビジョン (日付)

リビジョン数

系譜の数

行数

268,623(2001/2/9)

909,962(2010/2/14)

5,154

211,958

715/trunk/src/

1(1998/1/27)

19,893(2012/7/10)

3,918

362,783

2,760

/

1

(2012/6/19)

419(2013/5/3)

152

22,872

66/trunk/carol/src/

9(2002/8/6)

1,335(2007/10/22)

250

17,251258

DNSJava/trunk/org/xbill/DNS/

2(1998/9/6)

1,670(2012/10/26)

1,285

22,512406

JabRef/trunk/jabref/src/java/net/

6(2003/10/17)

3,718(2011/11/11)

1,489

113,277

703

CloneTracker
Carol

100

100

80

80

60

60
40

20

20

0

0

1500

500

0
200
400
600
800
1000
1200
1400
1600
1800
2000
2200
2400
2600
2800
3000
3200

(a) Ant00(b) DNSJava
図 4

100

500

100

80

400

80

60

300

60

40

200

40

20

100

0

0

1000

0
250
500
750
1000
1250
1500
1750
2000
2250
2500
2750
3000
3250
3500
3750
4000
4250
4500
4750

40

2000

1

2

3

生存日数

• 著者らが開発したソフトウェアであり，詳細な分析が可能であるため (CloneTracker).

• 既存研究で用いられているソフトウェアであるため

20
0
0

1

2

3

4

5-

(b) JabRef
図 5

修正回数

Fig. 5 The Number of Modifications

10

7
6
5
4
3
2
1
0

8
6
4

2
0
1
51
101
151
201
251
301
351
401
451
501
551
601
651
701

ソフトウェアであるため (Ant, ArgoUML).

5-(a) ArgoUML

Fig. 4 Alive Days

• 長い開発期間を有しており，また広く利用されている

4

1
11
21
31
41
51
61
71
81
91
101
111
121
131
141
151
161
171
181
191
201
211
221
231
241
251

ArgoUML(a) Ant(Carol, DNSJava, JabRef).

(b) Carol
図 6

各系譜の修正回数

6. 調査結果

Fig. 6 The Number of Modifications on Individual Genealogies

6.1 RQ1: ‘コードクローンの多くは生存期間が短い’ とソフトウェアも同様の傾向にあった．

いう知見は CRD を用いた場合でも成立するかしたがって，RQ2 に対する回答は Yes となる．

図 4 に Ant 及び DNSJava における系譜の生存日数を示す．このグラフの x 軸は日数を，y 軸は生存日数がその日

6.3 RQ3: コードクローンの生存期間の長さとコードク数以下である系譜数の百分率をそれぞれ表している．例え

ローンに加えられる修正回数の間に正の相関はあるかば Ant の場合，生存期間が 400 日以下の系譜が全系譜のう
ち約 40%を占めていることがわかる．

図 6 に Ant 及び Carol におけるの各系譜ごとの修正回

いずれのソフトウェアについても，グラフの左側では急数を示す．グラフの x 軸は各系譜を生存期間 (リビジョン

激に上昇しているが，右側では上昇が緩やかになっている．

数) の降順に並べたものであり，左側ほど生存期間の長い

他のソフトウェアについても同様の傾向がみられた．この系譜となる．

傾向は特に DNSJava において顕著であり，生存期間が開

また，生存期間と修正回数の間に相関があるか否かをス

発日数の 5%である 250 日以下という系譜が約 80%を占めピアマンの順位相関係数を用いて判定した (表 2)．そのている．

結果，Ant，CloneTracker，DNSJava については有意水準

この結果から，RQ1 には Yes と回答することができる．

5%で相関がみられなかったが，ArgoUML，Carol，JabRef
については相関がみられた．ただし，相関がみられた 3 つ

6.2 RQ2: ‘複数回修正されるコードクローンは少ない’という知見は CRD を用いた場合でも成立するか
図 5 に ArgoUML 及び JabRef における系譜の修正回数のソフトウェアについても，正負にはばらつきがあり，かつ強い相関ではなかった．
この結果から，RQ3 には No と回答することができる．

を示す．グラフの x 軸は修正回数を棒グラフは修正回数がx 軸の値である系譜の数を表している (左軸)．また折れ線
グラフは累積度数の百分率を表している (右軸)．

6.4 RQ4: コードクローンは生存期間の前半に修正されやすい傾向にあるか

図 5 より，ほとんどの系譜がまったく修正されないか 1

図 7 に Ant 及び ArgoUML について，各系譜に加えられ回だけ修正されるかのいずれかであることがわかる．他のた修正の時期を示す．グラフの x 軸は系譜を表しており，©2013 Information Processing Society of Japan6

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

100

100

19.9%

80

60

0

200

400

21.7%

20

28.9%

0

27.1%

40

20.7%

20

14.1%

60

19.5%

40

22.8%

0

600

…
9: public class FinallyBlockInfo extends BlockInfo {…
15:
public FinallyBlockInfo(String core, List<String> types) {16:
super(BlockType.FINALLY, core);
17:
this.types = new LinkedList<String>();18:
this.types.addAll(types);
19:
StringBuilder builder = new StringBuilder();20:for (String type : types) {21:
builder.append(type + “ “);
22:
}
23:
this.concatenatedTypes = builder.toString();24:
this.crdElement = new BlockCRD(bType);
25:
}
…
40: }

14.3%

80

10.9%

0

1000

(a) Ant

2000(b) ArgoUML
図 7

修正の時期

Fig. 7 Timing of Modifications
図 8

図 6 と同様に生存期間の降順に並べられている．グラフ中生存期間が長く，かつ修正回数が多いコードクローンの例

Fig. 8 An Example of Long-Lived Clone which is Modified
Multiple Timesの各点は 1 つの修正を表しており，y 軸はそれぞれの修正が加えられた時期を表している．y 軸は各系譜の生存期間
が 100 になるように正規化した値となっており，0 に近い
位置に点が存在する場合は，生成後すぐに修正されたことを示している．またグラフ右側の数値は，その時期に加え

7. 考察
7.1 生存期間が長く，修正回数が多いコードクローン

られた修正が全体に占める割合 (百分率) を表しており，例1 で述べたように，生存期間が長く，かつ修正される回

えば一番下の数値 (Ant の場合，28.9%) は生成直後から生数の多いコードクローンに注力することが，効率的なコー存期間の 20%が経過するまでの間に加えられた修正の割合

ドクローンへの対処を実現する上で重要である．そこで，を示している．なお，ここでは生存期間の途中で加えられそのようなコードクローンがどの程度存在するのかを分析た修正の時期を分析することを目的としているため，消滅した．その結果を表 4 に示す．ここでは，‘生存期間が長に関わる修正は考慮していない．

い’ か否かの判別基準として，Kim らの研究 [5] で用いら生存期間の前半と後半に加えられる修正回数に差がある

れている基準と同様に，‘分析期間の半分以上生存しているか否かを χ2 検定を用いて判定した．その結果を表 3 に示

かどうか’ を用いた．表 4 より，生存期間が長く，かつ複す．表 3 の “前半” の列は生存期間の 50%が経過するまで数回修正されるようなコードクローンは全体の約 3.3%存の間に，“後半” の列は生存期間の 50%が経過した後に加え在していた．したがって，すべてのコードクローンに対しられた修正の回数をそれぞれ表している．いずれのソフトて平等に対処を行うことは効率的とは言い難く，対処する

ウェアについても前半の方が後半よりも修正回数が多いと

コードクローンを慎重に選択する必要があるといえる．

いう結果となった．また，Ant，ArgoUML，及び DNSJava
については有意水準 5%で有意な差となった．

図 8 に生存期間が長く，修正回数の多いコードクローンの例を示す．この例は CloneTracker に存在するコード

以上より，RQ4 には Yes と回答することができる．

クローンであり，リビジョン 3 で生成されて以降，最終リ
ビジョンまで生存していた．このコードクローンは計 6 回修正されており，修正が加えられたリビジョンは 17，19，

表 2

修正回数と生存期間に対するスピアマンの順位相関係数

Table 2 Spearman’s Rank Correction Coeﬃcients
ソフトウェアρAnt−0.004515

0.9117

ArgoUML−0.4130

2.2 × 10−16

CloneTracker−0.05487

0.6617ンに対する修正漏れは存在していなかったものの，このよ
うに生存期間が長く修正回数の多いコードクローンは修正

p-value

4.736 × 10

24，121，234，及び 244 となっている．このコードクロー

−8

Carol

0.3320

DNSJava

0.08566

0.08473

JabRef−0.13930.0002124

漏れの要因となる危険性が高い．早期にこのようなコード
クローンへの対処を行うことで，修正漏れを効率的に防ぐことができると考えられる．
表4

全期間の半分以上生存し，かつ複数回修正されている系譜の数

Table 4 The Number of Long-Lived Genealogies which are
修正時期に関する χ2 検定

表 3

Modified Multiple Times

2

Table 3 χ -test for Timing of Modifications

ソフトウェア

系譜数

全系譜に占める割合

ソフトウェア

前半

後半

χ2

Ant

155

101

5.34070.02083

ArgoUML

540

305

32.7572

1.044 × 10−8

CloneTracker

4

6.06%

CloneTracker

156

1.22280.2688Carol30

11.63%
0.99%

p-value

Ant

52

7.27%

ArgoUML

48

1.74%

Carol

71

54

0.9042

0.3417

DNSJava

4

DNSJava

169

115

4.804

0.02839

JabRef23

3.27%

JabRef133

98

2.37070.1236

計

161

3.28%

©2013 Information Processing Society of Japan7

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

7.2 結果の妥当性
本小節では，本研究の結果の妥当性を脅かすおそれのあ

謝辞

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

研究 (S)(課題番号：25220003)，挑戦的萌芽研究 (課題番号：

る要因について述べる．

24650011)，特別研究員奨励費 (課題番号：25・1382)，文部科

対象ソフトウェア

学省科学研究費補助金若手研究 (A)(課題番号：24680002)，

今回の調査では，Java で記述されたオープンソースソフ

及び独立行政法人情報処理推進機構技術本部ソフトウェア

トウェアのみを対象としている．そのため，他の言語で記

高信頼化センターが実施した「2012 年度ソフトウェア工学

述されたソフトウェアや商用ソフトウェアを対象として調分野の先導的研究支援事業」の助成並びに支援を受けて行査を行った場合，本研究で得られた結果とは異なる結果がわれた．

導かれる可能性がある．
コードクローンの検出方法
本研究では，調査に要する時間的コストを低減するため

参考文献
[1]

に，ブロック単位のコードクローン検出手法を用いている．
そのため，他の検出手法を用いて調査を行った場合，本研
究と異なる結果が得られる可能性がある．また本研究で用[2]いたコードクローン検出手法はサブブロックや変数名などの正規化を行っている．正規化の方法を変更することで，[3]

調査結果に影響が及ぶ可能性がある．
コードクローンの追跡
本研究ではコードクローンの追跡に CRD を用いた．

[4]

CRD はソースコードに対する修正に強いコードクローン
追跡手法であるが，CRD を用いた場合でも，コード片が[5]

別のファイルに移動した場合など，位置情報が変わるような修正が行われた場合，コードクローンを適切に追跡できない可能性がある．また，本研究で用いた追跡手法は，系[6]

譜が途中で途切れることを考慮していない．すなわち，あるコードクローンが一旦消滅した後，再度出現した場合，消滅前後の系譜はそれぞれ別の系譜として扱われる．

8. あとがき[7][8]

本研究では，コードクローン追跡手法 CRD を用いてコー
ドクローンの進化の特性を分析した．分析を通じ，これまでの調査で報告されている，‘コードクローンの多くは生存[9]期間が短い’，及び ‘複数回修正されるコードクローンは少ない’ という知見が成り立つことを改めて確認するとともに，コードクローンの生存期間の長さと修正回数に相関が[10]みられないこと，及びコードクローンは生存期間の前半において修正されやすい傾向にあることを明らかにした．ま[11]

た，生存期間が長く，かつ修正される回数の多いコードク
ローンが全体の約 3.3%であることを示した．
今後の重要な課題として，生存期間が長く，かつ修正さ[12]れる回数の多いコードクローンを予測すること挙げられる．本研究を通じて注力すべきコードクローンの割合が高くないことが明らかになった．すなわち，効率的にソフト[13]

ウェア保守を行うためには対処するコードクローンを慎重に選択する必要があるといえる．現存するコードクローン
が今後長く生存するのか，また頻繁に修正されるのかを予測することで，対処すべきコードクローンの選択を支援することができる．

©2013 Information Processing Society of Japan[14]

Koschke, R.: Frontiers on Software Clone Management,
Proceedings of the Frontiers of Software Maintenance inthe 24th International Conference on Software Maintenance, pp. 119–128 (2008).
神谷年洋，肥後芳樹，吉田則裕：コードクローン検出技術の展開，コンピュータソフトウェア，Vol. 28, No. 3, pp.
28–42 (2011).
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).
肥後芳樹，吉田則裕：コードクローンを対象としたリファ
クタリング，コンピュータソフトウェア，Vol. 28, No. 4,
pp. 42–56 (2011).
Kim, M., Sazawal, V., Notokin, D. and Murphy, G. C.:
An Empirical Study of Code Clone Genealogies, Proceedings of the 13th International Symposium on Foundations of Software Engineering, pp. 187–196 (2005).
Göde, N. and Koschke, R.: Frequency and Risks of
Changes to Clones, Proceedings of the 33rd International Conference on Software Engineering, pp. 311–320(2011).
Rahman, F., Bird, C. and Devanbu, P.: Clones: What isthat Smell?, Proceedings of the 7th Working Conferenceon Mining Software Repositories, pp. 72–81 (2010).
Monden, A., Nakae, D., Kamiya, T., Sato, S. and Matsumoto, K.: Software Quality Analysis by Code Clones
in Industrial Legacy Software, Proceedings of the 8th International Symposium on Software Metrics, pp. 87–94(2002).
Hotta, K., Sasaki, Y., Sano, Y., Higo, Y. and Kusumoto,S.: An Empirical Study on the Impact of Duplicate
Code, Advances in Software Engineering, Vol. 2012(2012).
Harder, J. and Göde, N.: Cloned code: stable code,
Journal of Software : Evolution and Process (2012).
Duala-Ekoko, E. and Robillard, M. P.: Clone Region
Descriptors: Representing and Tracking Duplication in
Source Code, ACM Transactions on Software Engineering and Methodology, Vol. 20, No. 1, pp. 3:1–3:31 (2010).
Thummalapenta, S., Cerulo, L., Aversano, L. and Penta,
M. D.: An empirical study on the maintenance of sourcecode clones, Empirical Software Engineering, Vol. 15,
No. 1, pp. 1–34 (2010).
Krinke, J.: A Study of Consistent and Inconsistent
Changes to Code Clones, Proceedings of the 14th Working Conference on Reverse Engineering, pp. 170–178(2007).
Juergens, E., Deissenboeck, F., Hummel, B. and Wagner, S.: Do Code Clones Matter?, Procedings of the 31st
International Conference on Software Engineering, pp.
485–495 (2009).

8