情報処理学会論文誌

Vol.54 No.5 1686–1696 (May 2013)

コード修正履歴情報を用いた修正漏れの自動検出
肥後 芳樹1,a)

楠本 真二1,b)

受付日 2012年9月27日, 採録日 2013年2月1日

概要：バグ修正や機能追加のためにソースコードを修正する場合は，修正が必要なすべてのコード片を把握する必要がある．修正の必要があるコード片を見落としてしまうと，ソースコード中に修正漏れが発生してしまう．修正前であれば，grep 等のキーワード検索ツールを用いることにより，修正が必要なコード片を見落とす可能性は低くなる．しかし，すでに発生した修正漏れに対しては，キーワード検索ツールでは十分な支援を得られない．本論文では，ソースコード中において修正漏れが発生しているコード片を自動的に検出する手法を提案する．提案手法は，過去のコード修正に関する情報を学習データとして利用する．そして，最新バージョンに対して学習データが適用できる箇所を検索することにより，修正漏れを検出する．提案手法を実装し，オープンソースソフトウェアに対して実験を行った．その結果，バグ修正漏れ，リファクタリング実施漏れ，機能変更・機能追加漏れ，コメント修正漏れが発生しているコード片を多数検出できた．
キーワード：コード修正支援，リポジトリマイニング

Automatic Detection of Unintentionally Unmodified CodeUsing Code Modification Histories
Yoshiki Higo1,a)Shinji Kusumoto1,b)Received: September 27, 2012, Accepted: February 1, 2013

Abstract: When we modify source code for performing a given bug fix or functional addition, we must
recognize all the code fragments to be modified. If not, unintended inconsistencies occur in the source code.
Before modifying the source code, keyword-based search tools like grep are suitable for preventing the codefragments from being overlooked. However, once inconsistencies occur in the source code, such tools cannot
help us adequately. In this paper, we propose a new method to identify unintended inconsistencies in sourcecode automatically. The proposed method analyzes source code modifications in a repository to derive modification patterns. A modification pattern indicates what kind of code it had been and how it was modified.
The derived modification patterns are queries to identify unintended inconsistencies from the latest versionof source files. We implemented the proposed method as a software tool and applied it to HTTPD and
FreeBSD. As a result, we identified many overlooked code fragments for bug fixes, refactorings, functional
enhancements, and code comments.
Keywords: code modification support, repository mining

1. はじめにバグ修正や機能追加を行う場合には，ソースコード中の修正が必要なすべてのコード片を把握する必要がある．も
1

a)
b)

大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology,
Osaka University, Suita, Osaka 565–0871, Japanhigo@ist.osaka-u.ac.jp
kusumoto@ist.osaka-u.ac.jp

c 2013 Information Processing Society of Japan

しそれらを見落とすと修正漏れが発生してしまう．その修正漏れは後にフォールトの原因となり，システムの可用性を下げるばかりではなく，修正漏れのコード片を特定し修正するためのコストも必要になる．
ソースコードの修正前であれば，grep 等のキーワード
検索ツールやクローン検出ツールを用いることにより，修正が必要なコード片を見落とす可能性は低くなる．泉田ら
は，オープンソースソフトウエアのバッファオーバフロー

1686

情報処理学会論文誌

Vol.54 No.5 1686–1696 (May 2013)の修正を題材に，修正が必要なコード片の見逃し防止対策に適用し，以下の結果を得た．

として，grep とクローン検出ツールが有効であることを示• 多くのリビジョンにおいて修正漏れが存在しているこ

した [4]．また，森崎らは，国内の企業が開発したシステムと，および，それらの多くは後に修正が加えられ，修に対してクローン検出ツールを適用し，それがコード片の正漏れではなくなることが分かった．

見逃し防止対策として有効であることを示した [8]．しか• 1 つのバージョンに着目した場合に，それまでの開発

し，それらのツールは，すでに発生している修正漏れにつ履歴から得た学習データを用いて多数の修正漏れを自いては十分に支援できない．

動的に検出できた．

• grep を利用するには検索対象キーワードが必要である．しかし，どのコード片において修正漏れが発生し

2. 研究の動機ているのか不明なため，キーワードの指定ができない．

図 1 は，HTTPD のソースコードである．このソース• クローン検出ツールを用いれば，コピーアンドペース

コードでは，356 行目，382 行目，1,085 行目，1,315 行目

ト後における変数名の置換漏れ等の軽微な修正漏れをに同様の命令がある．リビジョン 83,956 において，その検出できる [7]．しかし，文の追加・削除等の大きな単うちの 3 つ（356 行目，382 行目，1,085 行目）が変更され位の修正漏れは検出が難しい．また，クローンとしてている．その後，リビジョン 83,960 において，1,315 行目

検出されるためには，コード片が一定以上の大きさでにも同様の修正が行われている．リビジョン 83,960 のコ類似している必要がある．

ミットログには，修正漏れがあったことを表す文章が記述

本論文では，開発履歴をマイニングすることにより，修されている．このことから，これら 4 つのコード片は同時

正漏れが発生しているコード片を検出する手法を提案すに同様の修正がされるべきであったが，開発者がこのうちる．提案手法は，grep やクローン検出ツールの問題点を解の 1 つを見落としていたことが分かる．この例で示したよ

決しており，以下の特徴を持つ．

うに，複数のコード片に対して同様の修正を行う必要があ• 字句単位の修正漏れ（変数やリテラルの置換漏れ）だ
けではなく，文単位の修正漏れ（文の追加・削除漏れ）

る場合に，開発者が修正すべきすべてのコード片を把握しているとは限らない．
そこで，本論文では，下記のリサーチクエスチョンを設も検出可能．

• 修正漏れのコード片がある程度以上の大きさの重複コードである必要がない．

• ソースコードの深い解析を必要とせず，複数のプログ
ラミング言語への展開が容易．

• スケーラビリィが高く，数百万行規模のソフトウェア
であっても数十分程度で解析可能．
提案手法をツールとして実装し，HTTPD と FreeBSD

定する．

RQ1 同時に行われていない同様の修正がどの程度存在するのか．
修正すべきコード片を特定した場合に，grep 等のキー
ワード検索ツールを用いれば，他の修正すべき箇所を列挙できるため，修正漏れが発生する可能性が低くなる．しかし，すでに発生している修正漏れについては，grep で支援

図 1 server/mpm/winnt/mpm winnt.c の一部（リビジョン 83,955）

Fig. 1 A part of server/mpm/winnt/mpm winnt.c (revision 83,955).

c 2013 Information Processing Society of Japan


1687

Vol.54 No.5 1686–1696 (May 2013)

情報処理学会論文誌を得ることは難しい．

る．彼らはオープンソースにおけるバッファオーバフロー

クローン検出手法を用いて修正漏れを検出する方法が提の修正事例に対してこのツールを適用し，クローン検索が案されている [7]．この手法ではクローンを検出し，そこ

漏れのない修正支援に有効であることを示した．また，森に含まれている変数の対応関係を調べる．対応関係がとれ崎らは国内の企業で開発された 3 つのシステム対して，泉ていないクローンが修正漏れの候補としてユーザに提示さ田らが開発したツールを適用した [8]．その結果，平均でれる．この手法はクローンに含まれる修正漏れを提示する

78.6%の適合率，87.4%の再現率を得ることができ，類似不が，クローンとして検出されないコード片については修正

具合発見においてクローン検出技術が有効であることを示

漏れを指摘できない．図 1 では，修正を行うべき 4 つの行

した．

はクローンであるが，その前後の行は重複していない．つLi らは，クローン検出ツール CP-Miner を開発した [7]．

まり，1 行のみの小さなクローンが 4 つ存在している．ク

CP-Miner は，変数やリテラルの違いを無視したうえで，ローン検出ツールの設定を変更することで，このような小クローンを検出する．そして，検出したクローンの各ペア

さいクローンを検出することは可能である．しかし，そのについて，その中に存在する変数の対応関係を調べる．たような小さいクローンの検出を行った場合，多量のクロー

とえば，クローン A と B がペアになっている場合を考えンが検出されてしまうため，検出されたクローンを調査す

る．クローン A では，変数 a が 3 回参照されている．一る負荷が大きい．さらには，修正内容が図 1 に示すような方，クローン B では，変数 a が 1 回，変数 b が 2 回参照

変数名の変更ではなく，文の追加や削除といったより大きされている．このような場合は，B における変数 a の参照

な変更だった場合は，クローンとして検出されない．

は，変数 b への修正漏れであると認識し，修正漏れを含む

本論文では，開発履歴をマイニングすることにより修正

クローンのペアとしてユーザに提示する．彼らは Linux や

漏れコード片とその修正方法を提示する手法を提案する．

FreeBSD 等 4 つのオープンソースソフトウェアに対して

たとえば，図 1 の場合では，リビジョン 83,955 から 83,956

CP-Miner を適用し，計 87 個のバグを発見した．

への修正をマイニングすることにより，下記の変更が 3 回起こったことが分かる．

ap_get_os_sock(lr->sd, &nsd);↓
ap_get_os_sock(&nsd, lr->sd);Göde らは，クローンに対する修正の頻度を調査した [2]．
実験対象は，3 つのオープンソースソフトウェアである．
彼らは，ほとんどのクローンは修正はたかだか 1 回しか修
正されていないことを示した．また，クローンにおける修正漏れは全体の 14.8%であり，さらにバグに直結している
修正漏れは全体の 3%であるとの結果であった．彼らの調

こ の 情 報 を 用 い る こ と に よ り ，リ ビ ジ ョ

査では，クローンとして検出されたコード片のみが調査対

ン 83,956 以 降 で は ，ソ ー ス コ ー ド 中 に象であり，クローンとして検出されていないコード片につ“ap_get_os_sock(lr->sd, &nsd);” が 存 在 し た 場

いては，調査は行っていない．

合には，“ap_get_os_sock(&nsd, lr->sd);” に変更すべきである，という提示ができる．
また，提案手法の有効性を調査するために，下記のリ

Rahman らは，バグとクローンの関係を調査している [9]．
彼らは過去のバグ修正において修正されたコード片のうちのどの程度がクローンであったかを調査した．彼らの実験

サーチクエスチョンを設定する．

対象ソフトウェアでは，すべてのバグ修正のうちの 80%以

RQ2 開発履歴をマイニングすることにより，どの程度の上がまったくクローンを含まないコード片に対して行われ修正漏れを検出できるか．

3. 関連研究ていた．

Bettenburg らは，リビジョンではなくバージョンレベル
でのクローン間の修正漏れ調査を行っている [1]．すべて修正漏れを検出する方法として，クローン検出技術を用のクローンが長期間存在しているわけではない [6]．そのいた手法が提案されている．クローン検出技術は，ソース

ため，ユーザが実際に利用するバージョン単位でクローン

コード中の変数やリテラル等の違いを吸収したうえで，同の修正漏れの調査を行うことにより，ユーザに影響を与え

形のコード片をクローンとして検出する．そのため，そのるバグの調査が行える．彼らは 3 つのオープンソースに対ような字句単位の違いを含んでいても同時に修正すべき

して実験を行い，たかだか 4%のクローンのみが修正漏れ

コード片として提示できる．

によるバグを引き起こしていることを明らかにした．

泉田らは，コード片を入力として受け取り，そのコード2 章で示したように，クローンとして検出されないコー

片のクローンを対象システムから検索するツールを開発しド片についても修正漏れは発生する．提案手法を用いた実た [4]．このツールは，バグ修正時において，修正すべき験を行うことにより，Göde ら，Rahman ら，Bettenburg

コード片を特定した後に，そのコード片を入力として与えらの調査結果を補える．

ることにより，同様の修正が必要な他のコード片を検出す

c 2013 Information Processing Society of Japan

Ying らは，開発履歴情報を分析することにより，同時に1688情報処理学会論文誌

Vol.54 No.5 1686–1696 (May 2013)

修正されることが多いファイル群を特定している [11]．そ合は，それぞれの修正パターンは 1 回ずつ出現したことにして，バグ修正等を行う場合に，その情報を用いて同時になる．

2

修正すべきファイル群を推薦する．彼らは，2 つのオープ

次に，修正パターンの確信度を定義する．

ンソースプロジェクトに対して実験を行った．推薦の適合定義 4（確信度） 修正前コード片から，修正後コード片率と再現率は高くても 50%程度であったが，静的解析や動が生成される確率である．修正パターンの集合が与えられ的解析では特定できないファイルを特定できた．

たときに，それらの中で修正前コード片が CFbef ore である修正パターンの数を n とする．また，それらのうち，修4. 提案手法

正後コード片が CFaf ter である修正パターンの数を m とする．このとき，修正前コード片が CFbef ore ，修正後コー

4.1 概要本論文では，ソースコード中に存在する修正漏れを自動ド片が CFaf ter である修正パターンの確信度は，mn で表さ的に検出する手法を提案する．提案手法は，開発履歴を解れる．なお，1 種類の修正前コード片は複数種類の修正後析するマイニング処理と対象ソースコードから修正漏れをコード片に変化しうるため，m ≤ n となる．

2

検出する検出処理から構成されている．まず，4.2 節で提案手法で利用する用語の定義を行う．次に，4.3 節でマイ
ニング処理，その後，4.4 節で検出処理について述べる．なお，提案手法は，CVS や Subversion 等のバージョン管理シ
ステムで管理されているソフトウェアを前提としている．

4.3 マイニング処理
マイニング処理の入力と出力を以下に示す．
入力 対象ソフトウェアのリポジトリ，支持度と確信度の
しきい値
出力 修正パターン群

4.2 用語の定義

マイニング処理は下記の手順からなる．

まず，コード片を定義する．

手順 1

ソースファイルが修正されたリビジョン群の特定．

定義 1（コード片） ソースファイル中の一部分を表す，

手順 2

特定したリビジョン群から修正パターンを抽出．

2

手順 3

抽出した修正パターンの支持度と確信度を計算し，長さが 0 以上の文字列である．

修正パターンは，どのようなコード片が，いつ，どのようしきい値を満たすものを出力．

なコード片に修正されたのかを表す．以下に定義を示す．

手順 1 では，少なくとも 1 つのソースファイルが修正さ

定義 2（修正パターン） 修正前のコード片を CFbef ore ，れたリビジョンを特定する．リポジトリでは，ソースコー

修正後のコード片を CFaf ter ，修正が行われたリビジョンをドに加えてドキュメント等の成果物も管理されている．そr とした場合，その修正パターンを，(CFbef ore , CFaf ter , r)のため，すべてのリビジョンでソースコードが修正されて2いるわけではない．そのようなリビジョンは修正パターン

修正は，追加，削除，変更に分類される．表 1 に，その抽出対象とはならない．バージョン管理システムは，指の分類と修正前コード片，修正後コード片の長さの関係を定したリビジョンで修正されているファイル一覧を表示す示す．

る機能を持つ．この機能により表示されたファイルの拡張で表す．

次に，修正パターンの支持度を定義する．

子を調査することにより，マイニング処理が必要であるリ

定義 3（支持度） 修 正 パ タ ー ン の 出 現 回 数 を 表 す

ビジョン群の特定を行える．

値 で あ る ．2 つ の 修 正 パ タ ー ン M P1 = (CF 1bef ore ,手順 1 において，n 個のリビジョン {r1 , r2 , · · · , rn } で

CF 1af ter , r1 )，M P2 = (CF 2bef ore , CF 2af ter , r2 )，があっ

ソースファイルが修正されていた場合，手順 2 では，r1 とた場合に，CF 1bef ore = CF 2bef ore ∧CF 1af ter = CF 2af ter

r2 ，r2 と r3 ，· · · , rn−1 と rn の間の差分を取得する．取が真になれば，M P1 と M P2 は同じ修正パターンと定義さ得した差分に現れているコードが，修正パターンの修正前れる．よって，M P1 や M P2 が表す修正パターンの出現

コード片と修正後コード片である．図 2 は，修正前後の

回数は 2 回となる．もし，M P1 と M P2 が同じでない場

ソースコードとその差分を diﬀ コマンドを用いて出力した様子を表している．この例の場合だと図 2 (c) の “3,4c3,4”，

表 1

追加，削除，変更とその前後のコード片の長さの関係

Table 1 Length of added, deleted, and changed code frag-れる．
すべての修正パターンを抽出した後に，手順 3 では，抽

ments.
修正の分類“7,8d6”，“11a10,11” の 3 つが修正パターンとして抽出さ修正前コード片

修正後コード片（CFbef ore ）の長さ

（CFaf ter ）の長さ

追加

CFbef ore == 0

CFaf ter > 0

削除

CFbef ore > 0

CFaf ter == 0

変更

CFbef ore > 0

CFaf ter > 0

c 2013 Information Processing Society of Japan


出した修正パターンの支持度と確信度を計算する．支持度と確信度がともにしきい値を満たす場合，その修正パター
ンは出力される．

1689

情報処理学会論文誌

Vol.54 No.5 1686–1696 (May 2013)(a) 検出した修正パターンを出力したファイル(a) 修正前(b) 修正後(c) 差分

図 2 修正前ソースファイル，修正後ソースファイル，diﬀ コマンドを用いたそれらの間の差分出力

Fig. 2 Source ﬁles before and after a modiﬁcation, and diﬀ
outout between them.
(b) 検出した修正漏れ候補を出力したファイル

4.4 検出処理

図 3

まず，検出処理の入力と出力を以下に示す．

実装したツールの出力例

Fig. 3 Output example of the developed tool.

入力 対象リビジョンのソースファイル群，修正パターン群（マイニング処理の出力），一致箇所数のしきい値

ID が振られている（322 行目）．図 3 (b) は検出された修出力 対象リビジョンのソースファイル中における修正漏

正漏れ候補が記録されたファイルである．修正漏れ候補とれ候補とその修正方法
一致箇所数とは，1 つの修正パターンによって検出されたコード片（修正漏れ候補）の数である．たとえば，多くなったコード片を含むファイルのパス（169 行目）と行番
号（170 行目）
，対応する修正パターンの ID（171 行目）等が記録されている．

のコード片が 1 つの修正パターンによって検出された場

ツ ー ル か ら の Subversion リ ポ ジ ト リ の 操 作 に は ，合は，それらは修正漏れとは考えにくい．過去に修正され

SVNKit *1 を用いている．マイニング処理では，更新さたコード片と同形のコード片が，修正前の状態で対象ソーれたファイルの特定を行うために svn log コマンドを，リスファイルに存在していることは事実であるが，それらはビジョン間の差分取得のために svn diﬀ コマンドを用いて意図的にその状態であると考えられる．このような誤検出いる．しかし，diﬀ コマンドにより得られたコード片をそ（意図的に修正を行っていないコード片の検出）を抑えるのまま用いると修正パターンの誤検出*2 が多数検出されてために，一致箇所数にしきい値を設ける．たとえ修正漏れしまうため，コード片の正規化を行う．正規化後の修正前

候補のコード片が見つかった場合でも，そのしきい値以上

コード片と修正後コード片を比較し，それらが同じ文字列の数であれば，それらは検出処理において出力されない．

である場合は，修正パターンとしての抽出は行わない．具

検出処理では，入力として与えられた各修正パターンの体的には下記の手順で処理を行う．

修正前コード片を用いて対象リビジョンのソースファイル

手順 1

svn diﬀ コマンドを用いて差分を取得．

に対して検索処理を行う．一致したコード片が修正漏れの

手順 2差分に現れている修正前後のコード片を正規化（空白，タブ，改行文字の削除）．

候補となる．もし，一致したコード片が一致箇所数のしきい値以下であれば，それらは出力される．なお，その修正

手順 3ければ，修正パターンとして抽出．

パターンの修正後コード片が修正方法となる．

5. 実装

正規化後の修正前後のコード片が同一文字列でな

この実装では，コード片の同値性は以下のように定義されている．

提案手法をツールとして実装した．現在のところ，対応

定義 5（コード片の同値性） 2 つのコード片からすべてしているバージョン管理システムは Subversion のみであの空白，タブ，改行文字を取り除いた後に，それらが同一文る．作成したツールの入力を以下に示す．

字列になるのであれば，その 2 つのコード片は同値である．

• 対象システムのリポジトリ• 修正漏れコード片の検索対象ソースファイル群• 支持度，確信度，一致箇所数のしきい値
出力は検出された修正パターンと修正漏れ候補である．
図 3 は出力例を表している．図 3 (a) は検出された修正パ
ターンが記録された出力ファイルである．各パターンには

c 2013 Information Processing Society of Japan


*1
*2

http://svnkit.com/
ここでの誤検出とは，修正漏れの指摘には役にたたない修正パ
ターンの意味である．

1690

情報処理学会論文誌

Vol.54 No.5 1686–1696 (May 2013)

表 2

対象ソフトウェアの概要

Table 2 Outline of target software.
ソフトウェアHTTPDFreeBSD

開始リビジョン

終了リビジョン

（日付）

（日付）

81,44290,607（1998-06-02）（2001-08-24）

196,121225,533（2009-08-12）（2011-09-14）

表 3

対象リビジョン数

終了リビジョン
の総行数

2,784

131,675

7,689

3,570,021

RQ1 の調査で抽出した修正パターンの内訳

Table 3 Extracted modiﬁcation patterns in RQ1 investigation.
ソフトウェア

バグ修正

リファクタリング機能変更・機能追加

コメント

合計

HTTPD

19

22

93

11

145

FreeBSD

23

39

24

8

94

ンに出現していた．これら 145 個と 94 個の修正パターン

6. 評価

について，手作業でその修正内容を確認し*5 ，4 つのカテ

オ ー プ ン ソ ー ス ソ フ ト ウ ェ ア の HTTPD *3 とFreeBSD*4に 対 し て 実 験 を 行 っ た ．実 験 対 象 の 詳 細については，表 2 に示す．HTTPD の実験対象期間は，ゴリに分類した（表 3）．各カテゴリについて説明する．
バグ修正 バグを取り除くための修正．
リファクタリング リファクタリングのための修正．変数名の変更等の簡単な修正も含む．

1.3.x ブランチが作成される前とした．この期間では，バージョン 1.3.0 のリリースに向けて新機能の追加とバグ修正

機能変更・機能追加 すでに実装された機能の変更や，新機能の追加のための修正．

が行われていた．FreeBSD の実験対象期間は，STABLE8
ブランチが作成されてから STABLE9 ブランチが作成さコメント ソースコード中のコメントに対する修正．主として著作権関係の記述のため．

れるまでの期間とした．この期間では，バージョン 9 に搭載する新機能の追加を行い，期間終了間近では，新機能の42 個の修正パターンがバグ修正に分類された．これら追加は凍結され，安定化のためのバグ修正のみを行うといは，開発者がバグを取り除くために修正しなければならな

う開発プロセスがとられていた．これらの期間に存在しいコード片を見落としていたことを表している．117 個のており，かつ，1 つ以上の.c ファイルが更新されている

修正パターンが機能変更・機能追加に分類された．これら

2,784 個のリビジョン（HTTPD）と 7,689 個のリビジョンも必要な機能が正しく実装されていないリビジョンが存在（FreeBSD）を対象とした．また，この実験では，しきい

していたことを表している．61 個の修正パターンがリファ値を用いて下記の値を用いた．

クタリングに分類された．大部分は関数名やマクロ名の変支持度の下限 3更であった．これらはソフトウェアの振舞いに直接影響を確信度の下限 1.0

与えるわけではないが，ソースコード中に一貫性のない

一致箇所数の上限 1

コード片が存在しているという点では望ましくない．19 個

マイニング処理の結果として，HTTPD から 737 個，の修正パターンがコメントに分類された．すべての修正パ

FreeBSD から 983 個の修正パターンを得た．以降，本章でターンは，著作権記述部分における西暦の修正漏れであっは，これらの修正パターンを用いて，2 章でも示した下記

た．著作権情報を正しく記述するという点では，これらもの 2 つの RQ について調査した結果を述べる．

望ましくはない．
図 4 は，複数リビジョンに出現していた 145 個と 94 個

RQ1 同時に行われていない同様の修正がどの程度存在するのか．

RQ2 開発履歴をマイニングすることにより，どの程度の修正漏れを検出できるか．

の修正パターンの出現期間を表している．横軸には修正パ
ターンが並べられており，縦軸は日付を表している．Y 軸
方向の線分の両端は，その修正パターンが現れる最初のリ
ビジョンの日付と最後のリビジョンの日付を表している．

6.1 RQ1 に対する実験

たとえば，FreeBSD（図 4 (b)）の一番左に配置されている

HTTPD については 145/737（=19.6%），FreeBSD につ

修正パターンは，2009/8/20 に最初に現れ，2010/1/27 にいては 94/983（=9.6%）の修正パターンが複数のリビジョ

最後に現れている．修正パターンは最初に現れた日付が早

*3

*5

*4

http://svn.apache.org/repos/asf/httpd/httpd/trunk/
http://svn.freebsd.org/base/head/sys/

c 2013 Information Processing Society of Japan

著者らがリポジトリのログ，修正パターン周辺のコード，その後の修正の様子を調査した．

1691

情報処理学会論文誌

Vol.54 No.5 1686–1696 (May 2013)(a) HTTPD(b) FreeBSD
図 4

RQ1 で抽出した修正パターンの出現期間

Fig. 4 Occurrence periods of extracted modiﬁcation patterns in RQ1 investigation.
表 4

最も長期間にわたって現れた修正パターン

Table 4 Modiﬁcation patterns occuring longest period.
(a) HTTPD(a) HTTPD

リビジョン

日付

83,946

1999-10-08

support/ab.c (2 places)

修正されたファイル

88,628

2001-04-02

support/ab.c(b) FreeBSD(b) FreeBSD
図 5

最も長期間にわたって現れた修正パターンのソースコード

Fig. 5 Source code of modiﬁcation patterns occuring longest
period.

い順に並べられている．この図より，大部分の対象期間に

リビジョン

日付

修正されたファイル

200,965

2009-12-25

sys/dev/ste/if ste.c

213,438

2010-10-05

sys/dev/usb/net/usb ethernet.c

218,832

2011-02-19

sys/dev/dc/if dc.c

223,648

2011-06-29

sys/dev/gem/if gem.c

223,951

2011-07-12

sys/dev/cas/if cas.c (2 places)

おいて，少なくとも 1 つの修正漏れが含まれていることが分かる．具体的には，対象期間のうち，68.1%（HTTPD）
および 96.1%（FreeBSD）が該当する．
図 4 より，長期間にわたって出現するパターンも存在していることが分かる．最も長期間にわたって出現していた
修正パターンのコードを図 5 に，この修正パターンが出現したリビジョンの情報を表 4 に示す．HTTPD の修正パ
ターン（図 5 (a)）では，if 文の条件式が変更されている．

FreeBSD の修正パターン（図 5 (b)）では，インクリメント
する変数が変更されている．これら 2 つの修正パターンはバグ修正に分類された．いずれも軽微な変更ではあるが，最初の修正と最後の修正が 1 年半以上も離れている．

RQ1 に対する回答
以上のことから，RQ1 に対して以下のように回答でき
る：修正パターンのうちの 19.7%と 9.6%が複数のリビジョンに現れていた．また，これらの修正パターンは，対象期間の 68.1%と 96.1%にまたがって存在していた．

6.2 RQ2 に対する実験
マイニング処理で抽出した 737 個と 983 個の修正パター
ンを用いて，HTTPD のリビジョン 90,607 と FreeBSD のリビジョン 225,533 から修正漏れコード片を検出した（提案手法の検出処理を行った）．その結果，HTTPD から 18
個，FreeBSD から 94 個のコード片が検出された．これら

c 2013 Information Processing Society of Japan

1692

情報処理学会論文誌

Vol.54 No.5 1686–1696 (May 2013)

表 5

RQ2 の調査で検出した修正漏れ候補の内訳

Table 5 Detected overlooked code fragments in RQ2 investigation.
ソフトウェア合計

修正漏れと判断
バグ修正

リファクタリング機能変更・機能追加

コメント

誤検出

適合率

HTTPD

18

2

4

10

0

2

88.9%

FreeBSD

94

13

51

2

3

25

73.4%

ロは，この修正パターンを抽出したリビジョン 205,014 で追加されていた．また，このマクロはこのリファクタリン
グ漏れが検出されたファイルに定義されていた．よって，
簡単に置換によるリファクタリングを行える．このコード(a) バグ修正

片は，リビジョン 205,014 において実施したリファクタリ
ング実施時に見落とされたと考えられる．

6.2.3 機能変更・機能追加漏れ
12 個の機能変更・機能追加漏れが検出された．図 6 (c)(b) リファクタリング

はその一例である．この修正パターンでは，タイムアウトになった処理時間を表示する機能が追加されている．修正パターンの修正後コード片で出現している変数 timeout
は，検出されたコード片では利用可能であるため，簡単に機能追加を行える．

(c) 機能変更・機能追加

6.2.4 コメント修正漏れ
3 個のコメント修正漏れが検出された．図 6 (d) にその一例である．この修正パターンでは，西暦と開発者のメールアドレスが古い情報のままであった．

(d) コメント
図 6 リビジョン 225,533 において見つかった修正漏れの例

Fig. 6 Examples of detected overlooked code fragments in revision 225,533.

6.2.5 誤検出
27 個のコード片を誤って検出していた．これらは，手作業による調査により意図的に修正を行っていないと判断された．

すべてのコード片を手作業により調査し，一致した修正パ
ターンの修正後コード片のように変更すべきかどうかを確認した*6 ．調査の結果を表 5 に示す．

6.2.1 バグ修正漏れ
15 個のバグ修正漏れが検出された．図 6 (a) はその一例である．この修正パターンでは，配列の要素 dump avail[1]の計算方法が変更されている．修正パターンが現れたリ
ビジョンのコミットログには，“dump avail layout should

be sequence of [start, end) pairs, not <start, size>.” と記載されており，この修正パターンがバグ修正であることを表している．FreeBSD のリビジョン 225,533 のファイル

ar71xx machdep.c には “deleted line” に示す行が存在しており，この行は修正パターンの修正前コード片と一致する
ため，バグの修正漏れであると判断した．

6.2.2 リファクタリング漏れ
55 個のリファクタリング漏れが検出された．図 6 (b) はその一例である．この修正パターンでは，シフト演算および論理演算を行う式がマクロに変更されている．このマク*6

著者らがリポジトリのログ，修正パターン周辺のコード，その後の修正の様子から判断した．

c 2013 Information Processing Society of Japan

RQ2 への回答
以上のことから，RQ2 に対して以下のように回答でき
る：HTTPD と FreeBSD から，16 個と 69 個の修正漏れを検出できた．HTTPD については 8,229 行あたりに 1
つ，FreeBSD については 51,739 行あたり 1 つの修正漏れが存在していた計算になる．また，検出の精度は 88.8%と73.4%であった．
6.3 クローン検出ツールとの比較
2 章で述べたように，提案手法の目的はクローン検出手
法では検出できない修正漏れを検出することである．その目的が達成されているかを調査するために，クローン検出
ツールが RQ2 で検出した修正漏れコード片を検出できるのかを調査した．この調査では，CCFinder [5] と Nicad [10]を利用した．これらのツールの特徴を以下に述べる．

CCFinder 字句単位でクローンを検出するツール．変数
名や関数名等のユーザ定義名を置換したうえでクローンを検出するため，それらが異なっているコード片でもクローンとして検出できる．つまり，字句レベルでの修正漏れを検出できる．

1693

情報処理学会論文誌

Vol.54 No.5 1686–1696 (May 2013)

表 6

CCFinder と Nicad により検出された修正漏れの数

Table 6 Number of overlooked code fragments detected by CCFinder and Nicad.
(a) HTTPD
手法

合計

バグ修正

リファクタリング機能変更・機能追加

コメント

提案手法

16

2

4

10

0

CCFinder

2

0

0

2

0

Nicad

2

0

0

2

0

手法

合計

バグ修正

リファクタリング機能変更・変更

コメント

提案手法

69

13

51

2

3

CCFinder

39

1

38

0

0

Nicad

2

1

1

0

0

(b) FreeBSD

表 7 CCFinder と Nicad が検出したクローンの数

クローンの数を表している．2 つのツールともに多くのクTable 7 Number of code clones detected by CCFinder and

ローンを検出した．しかし，表 6 に示すように，修正漏Nicad.

れの多くを検出できなかった．この結果は，クローン検出(a) HTTPD

ツールを用いて効率的に修正漏れを検出するのは難しいこ

検出ツール

クローンセット数

クローン数

CCFinder

1,004

3,435

Nicad

117

324

とを示唆している．

7. 議論
7.1 diﬀ の利用について(b) FreeBSD
検出ツール

クローンセット数

クローン数

提案手法を実装したツールでは，diﬀ コマンドの出力に

CCFinder47,016357,353

現れるコード片を元に修正パターンを検出している．diﬀ

Nicad

3,871

138,233

コマンドを用いることにより自動的に修正パターンを抽出できるが，単一コミットにおいて異なる複数の修正がソー

関数単位やブロック単位*7 でクローンを検出す

スファイル内の隣接部分に行われていた場合は，その修正るツール．Nicad は，LCS（Longest Common Subse-

全体を 1 つの修正パターンとして認識してしまう．本論文

quence）アルゴリズムを用いて連続して字句が一致しの実験ではこのような誤った修正パターンの検出についてている部分を検出する．その一致部分が関数やブロッは調査できていない．

Nicad

ク全体の一定以上の割合であれば，その関数やブロッ
クがクローンとして検出される．つまり，Nicad は字

7.2 正規化について
現在の実装では，空白，タブ，改行文字を取り除く簡単

句単位だけではなく，より大きな単位の不一致部分が含まれていてもクローンとして検出できる．

な正規化しか行っていない．そのため，用いている変数はこの実験では，デフォルトの設定を用いてクローンを検異なるが処理内容自体は同じであるコード片を同値である

出した．表 6 は，ツールによる修正漏れの検出結果を表しと判定できない．よって，そのようなコード片に対してはている．CCFinder と Nicad ともに，提案手法が検出した

修正漏れの指摘ができない．

修正漏れの大部分を検出できなかった．この理由は，修正

すべての変数やリテラルを同一の特別な文字に置き換え

漏れの前後に十分な重複コードが存在しておらず，クローる正規化を行えば，より多くの修正漏れを検出できるだろンとして検出できなかったためである．

う．しかし，そのような正規化を行うためには，ソースファ

FreeBSD の場合は，CCFinder は 38 個のリファクタリ

イル全体に対する構文解析を行う必要がある．現在は，svn

ング漏れを検出できた．これらは関数名が変更されたリ

diﬀ コマンドを用いているため，各リビジョン間においてファクタリングであり，字句単位での修正漏れであるため，差分の解析を行うコードの量は多くない．よって，大規模CCFinder では検出できた．一方，この部分の重複コードなシステムからでも短時間でマイニング処理を行える．すはブロック内における割合が低かったために，Nicad では

べてのリビジョンのソースファイルをチェックアウトして検出できなかった．

（手元にダウンロードして）構文解析を行うことも可能で

表 7 はツールによって検出されたクローンセット*8 と*7

ここでブロックとは，if 文や while 文のように，関数内での構造的なまとまりのある部分を指す．

c 2013 Information Processing Society of Japan

あるが，処理時間が著しく長くなってしまう．
*8

クローンの集合．1 つのクローンセットに含まれる任意のコード
片のペアは互いにクローンである．

1694

情報処理学会論文誌

Vol.54 No.5 1686–1696 (May 2013)

7.3 コードの “追加” を考慮していない
提案手法は修正パターンの修正前コード片を基に修正漏れを検出する．そのため，修正前コード片の長さが 0 であ

検出数が多い場合には手作業による確認が困難であった．
対象システムの開発者がこの確認作業を行った場合には，検出された修正漏れの真偽を素早く判断できるだろう．

る，コードの追加が必要な部分を検出することができていない．コードの追加に分類される修正パターンがどの程度存在するのかを調査するために，下記の 2 つの条件を満た
す修正パターンを抽出した．

7.6 比較対象ツール
この実験では，CCFinder と Nicad のデフォルトの設定を用いてクローンを検出した．しかし，検出する最小のク• 修正前コード片（CFbef ore ）の長さが 0．

ローンの大きさ等の設定を変更することで検出結果は異な• 修正後コード片が同値である修正パターンが 3 つ以上るため，それらのツールがより多くの修正漏れを検出でき存在する．

る可能性がある．また，この実験では，提案手法が検出し抽出の結果，HTTPD から 2 つ，FreeBSD から 6 つのた修正漏れをクローン検出ツールが検出可能か調査したの

修正パターンを得た．このうちの 4 つはプリプロセッサのみである．しかし，提案手法では検出されないが，クロー#ifdef と#endif に関する修正パターンであった．残りのン検出ツールでは検出される修正漏れも存在するだろう．

4 つの修正パターンを以下に示す．

なぜなら，提案手法は，過去に同様の修正が行われている( 1 ) 変数宣言の追加ことを必要とするが，クローン検出ツールは必要としない( 2 ) goto 文のラベルの追加からである．つまり，本実験の結果と合わせると，提案手( 3 ) セマフォをアンロックするためのメソッド呼び出しの法とクローン検出ツールは相補的な関係にあるといえる．

追加( 4 ) 閉じ中括弧（“}”）の追加

8. おわりに

これらのうち，特に ( 3 ) のメソッド呼び出しは修正漏れ

本論文では，ソースコード中から修正漏れを自動的に検の検出に利用すべきである．しかし，それ以外の 7 つにつ出する手法を提案した．提案手法は，対象ソフトウェアのいては，特に重要ではないと著者らは考えた．たとえば，

開発履歴情報を用いているため，検出されるためにはある( 4 ) の閉じ中括弧の追加忘れはソースコードがコンパイル程度以上の大きな重複コードでなければならない，という不可能になるため，容易にその修正漏れを検出できるから

既存手法の弱点を持たない [3]．

である．

提案手法をツールとして実装し，オープンソースソフト

追加に関する修正パターンを利用するためには，その周ウェアに対して実験を行った．その結果，多数のバグ修正

辺コードを用いる方法が考えられる．たとえば，マイニン

漏れ，リファクタリング漏れ，機能変更・機能追加漏れ，グ処理において，修正前コード片の長さが 0 である場合にコメント修正漏れを検出できた．今後は，システムの開発

は，その前後の 1 行ずつを修正前コード片に含めることで，者に協力していただいて実験を行い，ツールの検出結果の追加に関する修正パターンを検出処理で利用可能になる．

正しさをより正確に評価する予定である．また，コードの正規化を工夫し，検出の精度も高めていく予定である．

7.4 手作業による確認作業

謝 辞 本 研 究 は ，日 本 学 術 振 興 会 科 学 研 究 費 補 助

この実験では，著者らが検出された修正漏れの確認作業

金基盤研究（A）（課題番号：21240002），萌芽研究（課を行った．しかし著者らは対象システムの開発者ではない

題番号：23650014，24650011），若手研究（A）（課題番

ため，バグ修正やリファクタリング等への分類が誤ってい

号：24680002）の助成を得た．

る可能性がある．より正確に手法を評価を行うためには，
対象システムの開発者に協力していただいて実験を行う必

参考文献

要がある．

[1]

7.5 実験で用いたしきい値
本実験では，支持度，確信度，一致箇所数の 1 つの組合せのみを修正漏れ検出のしきい値として用いた．たとえば，[2]

支持度を 2 にする等，より緩いしきい値を用いることにより，さらに多くの修正漏れが検出される．この実験では著者らが検出された修正漏れを手作業で確認したが，著者らは対象システムの開発者ではないために，確認作業には長い時間を必要とした．RQ1 と RQ2 で検出された修正漏れを確認するために要した時間は約 20 時間であり，これ以上

c 2013 Information Processing Society of Japan

[3]

Bettenburg, N., Shang, W., Ibrahim, W.M., Adams, B.,
Zou, Y. and Hassan, A.E.: An empirical study on inconsistent changes to code clones at the release level, Science of Computer Programming, Vol.77, No.6, pp.760–
776 (online), DOI: 10.1016/j.scico.2010.11.010 (2010).
Göde, N. and Koschke, R.: Frequency and risks ofchanges to clones, Proc. 33rd International Conference
on Software Engineering, ICSE ’11, pp.311–320 (online), DOI: http://doi.acm.org/10.1145/
1985793.1985836 (2011).
Higo, Y. and Kusumoto, S.: How Often Do Unintended Inconsistencies Happen? – Deriving Modification
Patterns and Detecting Overlooked Code Fragments,
Proc. 28th International Conference on Software Main-

1695

情報処理学会論文誌

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

Vol.54 No.5 1686–1696 (May 2013)tenance, ICSM ’12, pp.222–231 (2012).
泉田聡介，植田泰士，神谷年洋，楠本真二，井上克郎：ソフトウェア保守のための類似コード検索ツール，電子情報通信学会論文誌，Vol.86-D-I, No.12, pp.906–908 (2003).
Kamiya, T., Kusumoto, S. and Inoue, K.: CCFinder: A
Multilinguistic Token-Based Code Clone Detection System for Large Scale Source Code, IEEE Trans. Softw.
Eng., Vol.28, pp.654–670 (online), DOI:
http://doi.ieeecomputersociety.org/10.1109/
TSE.2002.1019480 (2002).
Kim, M., Sazawal, V., Notkin, D. and Murphy, G.: An
empirical study of code clone genealogies, Proc. 10th
European Software Engineering Conference Held Jointly with 13th ACM SIGSOFT International Symposium
on Foundations of Software Engineering, ESEC/FSE13, pp.187–196 (online), DOI: http://doi.acm.org/
10.1145/1081706.1081737 (2005).
Li, Z., Lu, S., Myagmar, S. and Zhou, Y.: CPMiner: Finding Copy-Paste and Related Bugs in LargeScale Software Code, IEEE Trans. Softw. Eng., Vol.32,
pp.176–192 (online), DOI:
http://doi.ieeecomputersociety.org/10.1109/
TSE.2006.28 (2006).
森崎修司，吉田則裕，肥後芳樹，楠本真二，井上克郎，
佐々木健介，村上浩二，松井 恭：コードクローン検索による類似不具合検出の実証的評価，電子情報通信学会
論文誌 D，Vol.J91-D, No.10, pp.2466–2477 (2008).
Rahman, F., Bird, C. and Devanbu, P.T.: Clones: Whatis that smell?, Proc. 7th International Working Conference on Mining Software Repositories, MSR 2010,
pp.72–81 (2010).
Roy, C.K. and Cordy, J.R.: NICAD: Accurate Detectionof Near-Miss Intentional Clones Using Flexible PrettyPrinting and Code Normalization, Proc. 2008 The 16th
IEEE International Conference on Program Comprehension, ICPC ’08, Washington, DC, USA, pp.172–181(online), DOI: 10.1109/ICPC.2008.41 (2008).
Ying, A.T.T., Murphy, G.C., Ng, R. and Chu-Carroll,
M.C.: Predicting Source Code Changes by Mining
Change History, IEEE Trans. Softw. Eng., Vol.30,
pp.574–586 (online), DOI: 10.1109/TSE.2004.52 (2004).

楠本 真二 （正会員）
1965 年生．1988 年大阪大学基礎工学部卒業．1991 年同大学大学院博士課程中退．同年同大学基礎工学部助手．1996 年同講師．1999 年同助教授．

2002 年同大学大学院情報科学研究科
助教授．2005 年同教授．博士（工学）．
ソフトウェアの生産性や品質の定量的評価に関する研究に従事．電子情報通信学会，IEEE，IFPUG 各会員．

肥後 芳樹 （正会員）
1980 年生．2002 年大阪大学基礎工学
部情報科学科中退．2006 年同大学大学院博士後期課程修了．2007 年同大
学院情報科学研究科コンピュータサ
イエンス専攻助教．博士（情報科学）．
ソースコード分析，特にコードクロー
ン分析，リファクタリング支援およびソフトウェアリポジ
トリマイニングに関する研究に従事．電子情報通信学会，
日本ソフトウェア科学会，IEEE 各会員．

c 2013 Information Processing Society of Japan

1696