slide - POSL

デバッギングのための
関心事指向推薦システム
A Concern-oriented Recommendation System for Debugging
塩塚大九工大鵜林研究室
Masaru Shiozuka Kyushu Institute of Technology Ubayashi Lab.
1
概要
• デバッグにおける関心事に応じた情報を推薦
– 推薦はリポジトリ内のテスト結果、プログラム要素、
修正パターンなど関連付けたグラフの探索で実現
public class Property {
public String readFile (String pathname) throws
IOException {
String val = null;
File file = new File(pathname);
FileReader fileReader = new FileReader(file) ;
BufferedReader br = new
BufferedReader(fileReader);
val = br.readLine();
return val;
}}
推薦！
bug
例）今まで見たことない例外発生
修正方法が分からない！
public class Property {
publicString
class readFile
Property(String
{
public
publicString
class Property(String
{
public
pathname)
throwsreadFile
IOException {
public String readFile
(String
pathname)
String val =throws
null; IOException {
pathname)
throws
IOException {
String
val
=
null;
File file = new
val = null;
File String
file = new
File(pathname);
File file = new
File(pathname);
FileReader fileReader = new
File(pathname);
FileReader
FileReader(file)
; fileReader = new
FileReader(file)
BufferedReader; br = new
BufferedReader br = new
BufferedReader(fileReader);
BufferedReader br = new
BufferedReader(fileReader);
val = br.readLine();
BufferedReader(fileReader);
val val;
= br.readLine();
return
val val;
= br.readLine();
return
}}
return val;
}}
}}
発見！
プロジェクトＸＸＸの
リポジトリ
修正の参考になりそうな
ソースコードを推薦！
2
以降の内容
•
•
•
•
•
問題意識
提案手法
サポートツール
関連研究
まとめと今後の課題
3
デバッグで何が困るのか
• 例題シナリオ
– A君：プログラミング初心者
– readFileメソッド：ファイルから1行読み込み返す
– 発生した問題：ファイルが存在する場合のテストtestReadFileには成功．
しかし，ファイルが存在しない場合のテストtestReadFileFileNotExistで
例外FileNotFoundが発生
public class Property {
public class PropertyTest extends TestCase {
public String readFile (String pathname)
public void testReadFile () throws IOException {
throws IOException {
Property property = new Property();
String val = null;
assertEquals(“true”, property.readFile("property.txt"));
例外発生！
File file = new File(pathname);
}
FileReader fr = new FileReader(file) ;
public void testReadFileFileNotExist () throws IOException {
BufferedReader br =
Property property = new Property();
new BufferedReader(fr);
// property2.txt は存在しないファイル
assertEquals(null, property.readFile(“property2.txt”));
val = br.readLine(); // 1行読み込む
return val;
}
}}
}
テスト対象プログラム
テストプログラム
4
デバッグの際にA君が困ったこと
Q1. バグ情報の利用方法：
– 例外から察するにファイルが存在しない場合の処理が
要求されているが、どこをどのように修正すべきか？
Q2. ライブラリ利用方法：
– 使用したライブラリの使い方はこれであっているのか？
Q3. テスト作成方法：
– 他にテストすべき項目はないのか？
– どのようにしてバグを再現させるか？
Q4. 修正箇所：
– ソースコードのどこを特に注意して見直すべきか？
現時点で
対応
Q5. ロジックの誤り：
– ロジックに問題がありそうだがどのように修正すべきか？
Q6. 類似バグの検索：
– 似たバグがあれば参考にしたいが、探すのが大変
将来的に
対応
5
考えられる解決策
• Q1. ファイルが存在しない場合の処理が要求されているが、どこを
どのように修正すべきか
• 例外に関連したソースコードを提示するのが有効
– 過去のデバッグで例外FileNotFoundに関連したコードなら、同じファイ
ル操作のライブラリを使っているかもしれない
• 他の問題Q2～Q4についても、うまくデバッグ履歴を辿っていけば
修正のヒントが得られるかもしれない
• デバッグ履歴を活用した支援を提案
• デバッグ履歴の表現としてデバッグ関心事グラフ（ＤＣG）を提案
6
提案手法
• 検索の基盤として関心事グラフ*を利用
– 元々はプログラム理解/調査のために提案
– 作業毎に開発者が手作業で作成
– 推薦システムの分野でも利用されている**
• 関心事グラフを拡張したデバッグ関心事グラフ（ＤＣＧ）を提案（次ページ）
readFile
のデバッグ
BufferedReader
File
readFile
readLine
FileReader
Propert
y
PropertyTest
testReadFileFileNotExist
testReadFile
assertEquals
readFileのテスト失敗直後の関心事グラフ
：作業
：クラス
：メソッド/フィールド
：関連
：declares：メンバー宣言
：creates：インスタンス生成
：calls：メソッド呼び出し
開発者が手作業で１）～３）で作成
１）作業の決定
２）関連しそうなクラスを登録
３）関係を辿ってその他の要素を追加
*Robillard, M. P. et al. : Concern Graphs: Finding and Describing Concerns Using Structural Program Dependencies. In ICSE 2002, pp.406-416, 2002.
**Robillard, M. P.: Automatic Generation of Suggestions for Program Investigation. In FSE 2005, pp.11-20, 2005.
7
ＤＣＧ
テスト失敗/成功を監視しデバッグにおける関心事グラフを自動で生成
：ＤＣＧで新たに追加された頂点
・diff頂点：テスト実行間での差分を扱いたい
・テスト結果頂点：テスト結果を扱いたい
・修正パターン頂点：誤りの傾向を知りたい
テスト失敗直後
の時点を表現
テスト成功直後の時点を表現
※ 説明の都合上，if文検査
追加などの修正後に，テスト
を再実行し成功したとする
readFile
のデバッグ
diff-1
diff-2
Propert
y
BufferedReader
修正パターン：
if文検査の追加
メソッド呼出の追加
File
FileReader
readFile
readLine
Propert
y
testReadFile
テスト成功
PropertyTest
File
exist
testReadFileFileNotExist
readFile
テスト成功
PropertyTest
testReadFileFileNotExist
assertEquals
テスト失敗
例外：FileNotFound
readFileのテスト失敗～成功までのＤＣＧ
8
ツールサポート
• デバッグ活動を監視しグラフ構築＆検索を支援
– Eclipseのプラグインとして作成
– 開発者ごとにグラフを生成．プロジェクト内で共有（現状は個人支援）
テスト結果：JUnitを利用
修正パターン：diff + ASTParser
IF-APC: if文検査の追加
SQ-AROB: メソッド呼び出しの追加
構文の変更をもとにで２７パターン*に分類
関連したメソッド、フィールド、クラス：
Mylyn**を利用
ファイル閲覧、編集などを監視し関連した要素を取得．
関係した要素（コンテキスト）をプロジェクトで共有．
ある程度関心事グラフを自動で作れる．
*Pan, K., Kim, S. and Whitehead, Jr. E. J.: Toward an understanding of bug fix patterns. Empirical Software Engineering, pp.286-315, 2009.
**Kersten, M. and Murphy, G. C.: Mylar: a degree-of-interest model for IDEs. In AOSD 2005, pp.159-168, 2005.
9
修正パターン（一覧）
1. if文関連のカテゴリー
1.1 Addition of Precondition (IF-APC） ※★＝対応済み
1.2 Addition of Precondition Check with Jump (IF-APCJ)
1.3 Addition of Post-condition Check (IF-APTC)
1.4 Removal of an If Predicate (IF-RMV)
1.5 Addition of an Else Branch (IF-ABR)
1.6 Removal of an Else Branch (IF-RBR)
1.7 Change of If Condition Expression (IF-CC) ★
2. メソッド呼出しのカテゴリー
2.1 Method Call with Different Number of Parameters of Different
Types of Parameters (MC-DNP)
2.2 Method Call with Different Actual Parameter Values (MC-DAP) ★
2.3 Change of Method Call to a Class Instance (MC-DM) ★
3. 式のカテゴリー
3.1 Addition of Operations in an Operation Sequence of Method Calls
to an Object (SQ-AMO)
3.2 Removal of Operations from an Operation Sequence of Method
Calls to an Object (SQ-RMO)
3.3 Addition of Operations in a Field Setting Sequence (SQ-AFO)
3.4 Removal of Operations from a Field Setting Sequence (SQ-FRO)
3.5 Addition or Removal of Method Calls in a Short Construct Body
(SQ-AROB) ★
4. ループのカテゴリー
4.1 Change of Loop Predicate (LP-CC)
4.2 Change of the Expression that Modifies the Loop Variable (LP-CE)
5. 代入文のカテゴリー
5.1 Change of Assignment Expression (AS-CE) ★
6. スイッチ文のカテゴリー
6.1 Addition/Removal of Switch Branch (SW-ARSB)
7. トライ式のカテゴリー
7.1 Addition/Removal of Try Statement (TY-ARTC) ★
7.2 Addition/Removal of a Catch Block (TY-ARCB) ★
8. メソッド宣言のカテゴリー
8.1 Change of Method Declaration (MD-CHG) ★
8.2 Addition of a Method Declaration (MD-ADD)
8.3 Removal of Method Declaration (MD-RMV)
9. フィールド宣言のカテゴリー
9.1 Addition of a Class Field (CF-ADD)
9.2 Removal of a Class Field (CF-RMV)
9.3 Change of Class Field Declaration (CF-CHG)
10. 無視したパターン
10.1 本質的に修正に影響しないので除外したパターン
コメントの変更，デバッグ情報の追加・削除，コードの整形，
フォーマトの変更，出力の下の追加・削除，import文の変更
10.2 解析の難易度が高いので除外したパターン
式の置換，変数の名前変え，死んだコードの削除
10
利用例：readFileの修正
Q1.例外から察するにファイルが存在しない場合の処理が
要求されているが、どこをどのように修正すべきか？
一般的なデバッグの流れ
1.
テスト実行．例外FileNotFound発生！
2.
トレース実行などで例外箇所を特定
3.
FileReader()のドキュメントを読む
⇒FileReaderを特定
「FileNotFoundException - if the file does not
exist, is a directory rather than a regular file, or
for some other reason cannot be opened for
reading.」
※ ドキュメントがない場合は省略
ソースコードがあれば代わりに読む
4.
原因として引数のfileに問題があるの
ではと推測
5.
具体的な修正方法を考え修正．
テスト再実行し成功すれば終了．
失敗した場合4, 5を繰り返す．
頂点毎に関心事クエリを提供
関心事クエリ
例外に関連した修正を検索
このあたりの作業を支援
11
利用例
• 関連したコードの修正前・後を出力
修正箇所
修正前
修正後
• JUnitTestRunMonitorコンストラクタが推薦された
－ readFileメソッドと似たファイル操作をしている
－修正後ではif文検査、メソッド呼出しが追記されている
－修正方法として、if文検査、メソッド呼出しを追加すればいいと分かる！
12
結果を得るまでの過程
readFileのデバッグ
Q1. アルゴリズム
・・・
・・・
・・・
１）指定した例外から辿れる修正パ
ターンを取得
・・・
２）複数ある場合は、要素間の類似
calls
度が近いものから順に出力
共通要素
関連性有り！３）履歴は新しいもの、他のテストに
より作られたものを優先する
readLine
・・・
入力
例外
FileNotFound
calls
出力
修正
パターン
・・・
・・・
・・・
・・・
JUnitTestRunMonitorのデバッグ
H1：readFileのデバッグ
H2：JUnitTestRunMonitorのデバッグ
プログラム要素間の類似度(H1, H2) =
共通要素数/ ((H1の総数 + H2の総数) / 2)
例1）|H1| = 30, |H2| = 40, |H1∧H2| = 10
10 / ((30 + 40)/2) = 0.28
例2）|H1| = 30, |H2| = 40, |H1∧H2| = 20
20 / ((30 + 40)/2) = 0.57
例3）|H1| = 30, |H2| = 40, |H1∧H2| = 30
30 / ((30 + 40)/2) = 0.85
13
他の推薦について
関心事
入力
出力（推薦）
使用するメトリクス
Ｑ１．
例外やテスト結
果を活用できな
い
例外
ソースコード
・プログラム要素間
の類似度
Ｑ２．
ライブラリの利
用方法が分か
らない
ライブラリ
ライブラリを利用
したメソッド
・プログラム要素間
の類似度
Ｑ３．
テスト作成方法
が分からない
ライブラリ
関連したテスト
・プログラム要素間
の類似度
・テストtの実績値P(t)
(1 / 成功回数(t) )
優先度高
P(t) = (1 / 実行回数(t) )
Ｑ４．
レビューすべき
箇所が分から
ない
対象ソース
コード
修正候補箇所
・最頻修正パターン
例：関連したテストの推薦結果
より優先度が高いテストが上位にくる
14
関連研究
[クエリを使ったデバッグ]
• Debugging by Asking Questions About Program Output [Ko, A. J. ICSE2006]
– 問題コードの代わりに、実行履歴などの出力に対して質問を重ねていくことで問題箇所を絞
り込んでいく方法を提案
– 問題コード修正箇所の推測の誤りや、ブレークポイントの誤った利用によるタイムロスを減ら
すことができる
– ステップ２（例外箇所の特定），４（原因推測）を支援、Ｑ５（論理エラー）を支援
[履歴活用のデバッグ]
• DebugAdvisor: A Recommender System for Debugging [Ashok, B., et al. FSE2009]
–
–
–
–
似たようなバグを探し出して修正の参考にしたい
バージョン管理，バグデータベース，デバッガログなど情報が散らばっていて探すのが大変
区別することなく検索できるクエリ（fat query）を提案
デバッグにおけるステップ４，５（修正）を支援、Ｑ６（類似バグ）を支援
本研究ではステップ４，５を支援、Ｑ１～Ｑ４を支援
15
まとめと今後の課題
• まとめ
– 関心事グラフにデバッグ情報を追加したＤＣＧを提案
– 関心事に応じたクエリを提案
• 今後の課題
– オープンソースを使った評価
• 不足情報は適宜補う
• どういった状況でどの程度の支援ができるか
– 有効に機能するデバッグの種類の拡張
• 現状ではAPIの利用の誤りなどのデバッグが中心
– 関心事グラフに基づいているため
• 将来的にはロジックエラーなどのデバッグにも対応したい
– 実行履歴の追加（関連研究１）
– デバッガログ、ブレークポイント履歴の追加など（関連研究２）
16

Download Report