不具合修正履歴の理解に向けたソースコードの変更解析
畑水 野秀明†1
修†2

森 井菊 野亮介†1
亨†1

ソースコードの変更解析は，プログラム理解などの重要な技術であるが，構文変化を指摘するにとどまっている．不具合の修正前後で何を対象とした修正が行われたのかを理解するには，構文変化が何に影響するかを人目で見て判断する必要があった．本論文ではプログラム依存グラフを用いて，各データが何に使われるか，構文変化がどのデータに影響するか，データに対する処理の流れはどう変わるかといった分析を行い修正対象を分析した．修正対象として，メソッドコールに限定して，オープンソースプロジェクトの開発履歴を調査した結果，よく修正されるメソッドがあることを明らかにした．

Change Analysis Toward an Understanding of Fixing Bugs
H IDEAKI H ATA ,†1 RYOSUKE M ORII ,†1 O SAMU M IZUNO†2and T OHRU K IKUNO†1
Investigating bug fix changes that occur across several versions in software repositories has been a key
issue in software analysis. We propose a PDG (Program Dependency Graph)-based source code change
analysis technique. To clarify fixing targets, we conducted data-centric analysis. We analyzed which data
is affected by a change and what operations the data is used. With this technique, we conducted an experiment with an open source project. Fixing number of method calls are counted and it revealed that there areproject-specific method calls that induce bugs.

1. は じ め にる．本論文では (i) についてのこれまでの成果を述べる．
これまでのソースコードの変更解析は，構文の変更ソフトウェア開発において，低コストで信頼性を確を指摘するにとどまっている．不具合の修正における保するためにはツールによる支援が必要である．我々

変更解析を行った研究でも，if 条件の変更などがよくは，開発履歴中の不具合修正の情報をもとに，似たよ起こる構文変更だと明らかにしたのみである [2]．我々

うな不具合の混入を早期に防止するシステムの開発をが目指すのは，修正対象を明らかにすることであり，目指している．これまでの研究では，モジュールに不例えば if 条件の変更においては，その条件変更がどの具合がありそうか否かの判定を行うことを目指し，一処理に影響するかまで分析することである．

定の成果を得た [1]．また，プロジェクトごとに不具合混入モジュールに頻発するメソッドコールや変数名などがあることを明らかにした．

2. 提 案 手 法
修正対象を分析するためのキーアイディアは，どこ発展的課題として，どこを修正すべきかという修正で使われるデータの処理が修正されたかを明らかにす

対象の提示を目指している．課題実現の方針として，るということである．このために，以下のことを分析

まず，(i) 不具合修正履歴からの修正対象分析を行い，する．

(ii) 開発中のモジュールと過去のモジュールとのパター• 構文変化は，どのデータに影響するかンマッチから修正対象の候補を出力したいと考えてい• 各データは何に使われるか（データの依存関係）• データに対する処理の流れはどう変わるか（処理†1 大阪大学 大学院情報科学研究科
Graduate School of Information Science and Technology, OsakaUniversity†2 京都工芸繊維大学 大学院工芸科学研究科
Graduate School of Science and Technology, Kyoto Institute ofTechnologyのパス，制御の依存関係）
データの依存関係，制御の依存関係を把握するため，ソースコードをメソッド単位でプログラム依存グラフ（Program Dependency Graph, PDG）として表し，分析

%!!!!

$!!!!
&!!
#"!!!
%!!
#!!!!
$!!

#!!! $!!!

#!!+!
$!!+!

"*!! #*!!

")!! #)!!

"(!! #(!!

"'!! #'!!

"&!! #"!!

"%!! #&!!

6785!

"$!! #%!!

"#!! #$!!

""!! ##!!

*!! *!!

"!!! #!!!

)!! )!!

(!! (!!

'!! '!!

!!

&!! "!!

図 1 修正前後のソースコード
Fig. 1 Source code before and after a bug fix%!! &!!

(b) 修正後$!! %!!

"!!
!!

(a) 修正前#!! $!!

"!!!
#!!
"!! #!!

String format( Object obj )｛String str = ””;
str = obj.toString( );return str;
｝

(!!
$"!!!
'!!

,-./012345!
,-./012345!

String format( Object obj )｛String str = ””;
if ( obj != null )｛str = obj.toString( );｝return str;
｝

6785!

図 3 メソッドコールごとの修正回数のヒストグラム
Fig. 3 Histogram of fixing numbers for method calls

Object obj的な分析が可能である．そこで，修正対象をメソッド
str = obj.toString();コールに限定して不具合履歴の調査を行った．調査対obj

String str = "";象はオープンソースプロジェクトの Eclipse Web Tools

return str;
str

Platform で，開発言語は Java である．開発履歴から不(a) 修正前

具合修正前後のソースコードを取得し，メソッドコー

Object obj

ルを対象とする修正に関し，呼び出されるメソッドごobj != nullとに修正回数を測定した．

true

図 3 は，修正対象ごとの修正回数をヒストグラムとString str = "";して描いたものである．95% 以上のメソッドコール

str = obj.toString();obj
return str;
str(b) 修正後
図 2 ソースコードからの PDG
Fig. 2 Constructed PDGsを行う．修正対象を特定する分析を，図 1 に示した修正前後のソースコードを用いて説明する．これは引数obj を String へ変換するメソッドの修正である．

は，修正回数が 10 以下であった．それに対し，一部のメソッドコールは何度も修正対象となっていることが分かった．本調査から，メソッドの呼び出し側において，何度も修正されているメソッドがあることが分かった．

4. お わ り に
本論文では，不具合修正履歴における不具合対象を特定する手法を提案した．不具合対象をメソッドコー

図 2 は，図 1 のソースコードをそれぞれ PDG へ変ルに限定した調査では，よく修正される典型的なメ換し，関係するデータごとに頂点をまとめたものであソッドコールがあることを明らかにした．今後は修正る．またデータが到達するまでのパスを楕円で，制御内容の分析を行い，適切な修正対象を提示する手法に条件を太矢印でそれぞれ示している．図 2 の差分から，ついて検討を行う．

影響するパスの到達点の操作を修正対象として特定する．この例では，メソッドコール toString と返り値を対象とした修正であったと決定する．
ただし，この手法では変更が影響する対象を全て修正対象として特定するため，リファクタリングなどの不具合修正以外も含めてしまう．そのため，修正内容のさらなる分析が必要である．

3. 不具合履歴の調査
前述したように提案手法はさらなる改善が必要である．しかし，これまで行われていない，修正対象の自動参考文

献1) Hata, H., Mizuno, O. and Kikuno, T.: Fault-prone
module detection using large-scale text features
based on spam filtering, Empirical Software Engineering (to appear).
2) Pan, K., Kim, S. and Whitehead, Jr., E. J.: Toward an understanding of bug fix patterns, Empirical Software Engineering, Vol.14, No.3, pp.286–315(2009).