slide - POSL

オープンソースリポジトリのバグ修正履歴
を再利用したデバッグ推薦の評価実験
九州工業大学塩塚大 ※
九州大学
鵜林尚靖
九州大学
亀井靖高
※ 現在，メルコ・パワー・システムズ株式会社
概要
デバッグ関心事
このAPIの使い方は？
この例外は。。。
本発表のポイント
public class Property {
public String readFile (String
pathname) throws IOException
{
String val = null;
File file = new
File(pathname);
Reader(fileReader);
val = br.readLine();
return val;
} } File file = new
File(pathname);
Reader(fileReader);
val = br.readLine();
return val;
dcNavi
(Debug Concern Navigator)
コード
dcNaviの適用実験（オープンソースプロジェクトで実験）
オープンソースリポジトリからDCGへの変換
public class Property {
public String readFile (String
pathname)
throws
IOException
public
class Property
{
{
public String readFile (String
String
val = null;
pathname)
throws IOException
File
public class Property {
{ file = new
File(pathname);
String readFile (String
Stringpublic
val = null;
Filepathname)
file = new throws IOException
{
File(pathname);
BufferedReaderString
br = new
val = null;
BufferedReader(fileReader);
File file = new
val = br.readLine();
File(pathname);
BufferedReader
br = new
return
val;
BufferedReader(fileReader);
}}
val = br.readLine();
BufferedReader
br = new
return val;
BufferedReader(fileReader);
}}
val = br.readLine();
return val;
}}
分析＆検索
推薦
（類似のコード修正例）
過去の
バグ修正履歴
DCG（Debug Concern Graph）
2
発表の流れ
１．はじめに〜デバッグと修正履歴の活用〜
２．dcNavi
・DCG（Debug Concern Graph）
・推薦アルゴリズム
３．実験
４．関連研究
５．まとめと今後の課題
3
１．はじめに
〜デバッグと修正履歴の活用〜
• 背景：類似したバグ修正が行われることがある
– 例：subclipseプロジェクトでの修正
• 目的：バグ修正の際に役立ちそうな過去の修正情報を見つけたい！
4
dcNaviをオープンソースに適用する際に
考慮すべき点
– １．バグ修正に関する変更情報の選別
• どの時点のリビジョンをバグ修正の開始、終了とするか
ＤＣＧ自動生成
– ２．類似したバグの検索
• できるだけ類似しているバグを発見したい
推薦アルゴリズム
＆
適用実験
（評価基準）
5
２．dcNavi
[DCG生成機能]
・DCGはバージョン管理システム
から生成
[推薦機能]
修正後
rev920
バグ修正パターン
の修正
(1) ライブラリの誤り易い例と、
そのときの修正方法（後述）
(2) 過去にある例外に関連した
ソースコードとそのときの修正方法
修正前
プログラム要素
～dcNaviのスナップショット～
・moveメソッドの修正前から修正後までに
作られたDCG
・Eclipseのプラグインとして実装
6
DCG（Debug Concern Graph)
•
下の図が、moveメソッドの修正前から修正後までに作られるDCG
– DCG ＝プログラム解析情報 + バグ修正情報から成るデバッグ履歴の表現
：メソッド宣言
：メソッド内のプログラム要素
：バグ修正パターン
move
のデバッグ
diff-1
calls
move
バグ修正パターン（全２７種）
diff-2
move
calls
move
getBaseDir
catches
calls calls
MC-DM:同一オブジェクトに対する呼
び出すメソッドの変更
move
wrapException
MC-DAP: メソッド呼出しのパラメータ
toString
の変更
デバッグ開始（修正前）
SQ-AROB:
メソッド呼出しの追加/削除
バグ修正パターン*：
MC-DM
デバッグ終了（修正後）
キーワード「bug, fix, patch」
*Pan, K., et al.: Toward an understanding of bug fix patterns. Empirical Software Engineering, pp.286-315, 2009.
7
推薦アルゴリズム
ライブラリの誤り易い例とそのときの修正方法
修正対象：rev984のremoveメソッド
remove
のデバッグ
diff-1
①関連したメソッドが修正されて
いる履歴を検索
②類似度（共通要素数の割合）を計算
し類似しているものを優先
③バグ修正パターンや修正差分を推薦
remove
delete
toString
move
のデバッグ
wrapException
diff-1
diff-2
SvnCommandLineクラスのメソッド
move
類似度：
共通要素数 ÷
{(G1の要素数 + G2の要素数) / 2}
= 2 / {(3 + 4) / 2} = 0.57
getBaseDir
move
wrapException
toString
バグ修正パターン*：
MC-DM
move
move
推薦対象：rev920のmoveメソッド
8
３．実験
• 目的
– 推薦量/推薦時間/推薦の質の確認
• 対象プロジェクト
– EclipseプラグインでMylynに関連した９つのオープンソース
• 手順
– リポジトリからライブラリに関連したバグを含んでいたメ
ソッド（修正対象）を選択し、修正方法（修正例）を推薦
推薦元データ
生成
DCG
推薦
修正対象
＋
自プロジェクトの
リビジョンの８０%内
のバグ修正情報
他の８プロジェクト
バグ修正情報
自プロジェクトの残りの２０%
のリビジョン内のバグ
9
正解の定義
• 実際の修正方法と修正例のバグ修正パターンを比較
• 条件１．バグ修正パターンの種類が一致
• 条件２．修正されたメソッドが一致
条件１
バグ修正パターン*：
MC-DM
条件２
修正されたメソッド
delete
一致！
不一致！
条件１は満たす
条件２は満たさない
（同一クラス内のメソッドまで正解にすれば一致）
条件１
バグ修正パターン*：
MC-DM
条件２
修正されたメソッド
move
10
質の表現
• 適合率（推薦の精度の指標）
– 推薦結果内にどれだけ正解が含まれるか、ノイズが少ないか
• 推薦結果内に含まれる正解の割合
• 再現率（正解の網羅率の指標）
– 推薦候補内に含まれる正解をどれだけ網羅できたか、漏れが
少ないか
• 全推薦候補内（自プロジェクト80%＋他の8プロジェクト）に含まれる
正解に対する，推薦結果内の正解の割合
• F値
– 適合率と再現率の調和平均
11
結果１
Ｎｏｔｅ．条件１および２を満たした場合を正解とした場合の結果
プロジェクト
NOM ANR
ATR(msec)
適合率(%)
再現率(%)
F値(%)
12
結果２
※ 9プロジェクトで平均した値
13
結果３
推薦候補内に存在する正解からなる集合
推薦結果のうち正解だった要素からなる集合
14
４．関連研究
修正履歴を活用した研究
• BugMem [Kim, S. FSE2006]
– ソースコード差分の検索を支援
– クラスライブラリやstatic呼出しを排除して差分を検索可能
• DebugAdvisor [Ashok, B. FSE2009]
– バージョン管理システム，バグデータベース，デバッガログなど統
合して類似バグが検索できるクエリ（fat query）を提案
• FixWizard [Nquyen, T. T. ICSE2010]
– メソッド呼出しなどの順序を考慮して類似バグの検索を支援
15
５．まとめと今後の課題
• まとめ
– オープンソースを用いた評価実験によりdcNaviの推薦
機能（ライブラリ利用例）の性能を確認
• 今後の課題
– グループ推薦
• 1つの推薦よりは関連する複数の事例を推薦する方式の方
が有効な場合も多いと考えられる
• バグの要因は1つだけでなく複合している場合が多い
• 類似した複数の事例を提示して貰った方がプログラマも修正
の確信が持てやすくなる
• ただし，どのようなポートフォリオにするかは今後の課
題
16

Download Report