デバッギングのための 関心事指向推薦システム A Concern-oriented Recommendation System for Debugging 　　塩塚 大　九工大　鵜林研究室 Masaru Shiozuka Kyushu Institute of Technology Ubayashi Lab.　

概要 デバッグにおける関心事に応じた情報を推薦 発見！ 推薦！ bug 推薦はリポジトリ内のテスト結果、プログラム要素、修正パターンなど関連付けたグラフの探索で実現 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; } } 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; } } 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; } } 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 プロジェクトＸＸＸの リポジトリ 例）今まで見たことない例外発生 修正方法が分からない！ 修正の参考になりそうな ソースコードを推薦！

以降の内容 問題意識 提案手法 サポートツール 関連研究 まとめと今後の課題

デバッグで何が困るのか 例題シナリオ A君：プログラミング初心者 readFileメソッド：ファイルから1行読み込み返す 発生した問題：ファイルが存在する場合のテストtestReadFileには成功． しかし，ファイルが存在しない場合のテストtestReadFileFileNotExistで例外FileNotFoundが発生 public class Property { public String readFile (String pathname) throws IOException { String val = null; File file = new File(pathname); FileReader fr = new FileReader(file) ; BufferedReader br = new BufferedReader(fr); val = br.readLine(); // 1行読み込む return val; } } public class PropertyTest extends TestCase { public void testReadFile () throws IOException { Property property = new Property(); assertEquals(“true”, property.readFile("property.txt")); } public void testReadFileFileNotExist () throws IOException { // property2.txt は存在しないファイル assertEquals(null, property.readFile(“property2.txt”)); 例外発生！ テスト対象プログラム テストプログラム

デバッグの際にA君が困ったこと Q1. バグ情報の利用方法： 例外から察するにファイルが存在しない場合の処理が 要求されているが、どこをどのように修正すべきか？ Q2. ライブラリ利用方法： 使用したライブラリの使い方はこれであっているのか？ Q3. テスト作成方法： 他にテストすべき項目はないのか？ どのようにしてバグを再現させるか？ Q4. 修正箇所： ソースコードのどこを特に注意して見直すべきか？ Q5. ロジックの誤り： ロジックに問題がありそうだがどのように修正すべきか？ Q6. 類似バグの検索： 似たバグがあれば参考にしたいが、探すのが大変 現時点で 対応 将来的に 対応

考えられる解決策 Q1. ファイルが存在しない場合の処理が要求されているが、どこをどのように修正すべきか 例外に関連したソースコードを提示するのが有効 過去のデバッグで例外FileNotFoundに関連したコードなら、同じファイル操作のライブラリを使っているかもしれない 他の問題Q2～Q4についても、うまくデバッグ履歴を辿っていけば修正のヒントが得られるかもしれない デバッグ履歴を活用した支援を提案 デバッグ履歴の表現としてデバッグ関心事グラフ（ＤＣG）を提案

testReadFileFileNotExist 提案手法 検索の基盤として関心事グラフ*を利用 元々はプログラム理解/調査のために提案 作業毎に開発者が手作業で作成 推薦システムの分野でも利用されている** 関心事グラフを拡張したデバッグ関心事グラフ（ＤＣＧ）を提案（次ページ） ：作業 ：クラス ：メソッド/フィールド ：関連 ：declares：メンバー宣言 ：creates：インスタンス生成 ：calls：メソッド呼び出し BufferedReader readFile のデバッグ File FileReader PropertyTest Property readFile testReadFileFileNotExist 開発者が手作業で１）～３）で作成 １）作業の決定 ２）関連しそうなクラスを登録 ３）関係を辿ってその他の要素を追加 readLine testReadFile assertEquals readFileのテスト失敗直後の関心事グラフ *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.

ＤＣＧ テスト失敗/成功を監視しデバッグにおける関心事グラフを自動で生成 　　　：ＤＣＧで新たに追加された頂点 ・diff頂点：テスト実行間での差分を扱いたい ・テスト結果頂点：テスト結果を扱いたい ・修正パターン頂点：誤りの傾向を知りたい テスト成功直後の時点を表現 ※　説明の都合上，if文検査追加などの修正後に，テストを再実行し成功したとする readFile のデバッグ テスト失敗直後 の時点を表現 diff-1 diff-2 PropertyTest Property File exist BufferedReader 修正パターン： if文検査の追加 メソッド呼出の追加 testReadFileFileNotExist File readFile FileReader テスト成功 PropertyTest readFile Property testReadFileFileNotExist testReadFile readLine テスト失敗 例外：FileNotFound assertEquals テスト成功 readFileのテスト失敗～成功までのＤＣＧ

ツールサポート テスト結果：JUnitを利用 修正パターン：diff + ASTParser デバッグ活動を監視しグラフ構築＆検索を支援 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.

修正パターン（一覧） 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 解析の難易度が高いので除外したパターン 式の置換，変数の名前変え，死んだコードの削除

利用例：readFileの修正 Q1.例外から察するにファイルが存在しない場合の処理が 要求されているが、どこをどのように修正すべきか？ 一般的なデバッグの流れ テスト実行．例外FileNotFound発生！ トレース実行などで例外箇所を特定 ⇒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.」 ※　ドキュメントがない場合は省略 　　 ソースコードがあれば代わりに読む 原因として引数のfileに問題があるのではと推測 具体的な修正方法を考え修正． テスト再実行し成功すれば終了． 失敗した場合4, 5を繰り返す． 　頂点毎に関心事クエリを提供 　例外に関連した修正を検索 関心事クエリ このあたりの作業を支援

利用例 関連したコードの修正前・後を出力 修正前 修正後 JUnitTestRunMonitorコンストラクタが推薦された 修正箇所 － readFileメソッドと似たファイル操作をしている 　 － 修正後ではif文検査、メソッド呼出しが追記されている 　 － 修正方法として、if文検査、メソッド呼出しを追加すればいいと分かる！　

結果を得るまでの過程 入力 出力 readFileのデバッグ Q1. アルゴリズム calls 共通要素 関連性有り！ calls １）指定した例外から辿れる修正パターンを取得 ２）複数ある場合は、要素間の類似度が近いものから順に出力 ３）履歴は新しいもの、他のテストにより作られたものを優先する ・・・ ・・・ ・・・ ・・・ calls ・・・ 入力 共通要素 関連性有り！ 例外 FileNotFound readLine 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 calls 出力 ・・・ 修正 パターン ・・・ ・・・ ・・・ JUnitTestRunMonitorのデバッグ

他の推薦について 優先度高 例：関連したテストの推薦結果 関心事 入力 出力（推薦） 使用するメトリクス より優先度が高いテストが上位にくる Ｑ１． 例外やテスト結果を活用できない 例外 ソースコード ・プログラム要素間 の類似度 Ｑ２． ライブラリの利用方法が分からない ライブラリ ライブラリを利用したメソッド Ｑ３． テスト作成方法が分からない 関連したテスト ・テストtの実績値P(t) P(t) = (1 / 実行回数(t) ) Ｑ４． レビューすべき箇所が分からない 対象ソースコード 修正候補箇所 ・最頻修正パターン 優先度高 (1 / 成功回数(t) ) 例：関連したテストの推薦結果 より優先度が高いテストが上位にくる

本研究ではステップ４，５を支援、Ｑ１～Ｑ４を支援 関連研究 [クエリを使ったデバッグ] Debugging by Asking Questions About Program Output [Ko, A. J. ICSE2006] 問題コードの代わりに、実行履歴などの出力に対して質問を重ねていくことで問題箇所を絞り込んでいく方法を提案 問題コード修正箇所の推測の誤りや、ブレークポイントの誤った利用によるタイムロスを減らすことができる ステップ２（例外箇所の特定），４（原因推測）を支援、Ｑ５（論理エラー）を支援 [履歴活用のデバッグ] DebugAdvisor: A Recommender System for Debugging [Ashok, B., et al. FSE2009] 似たようなバグを探し出して修正の参考にしたい バージョン管理，バグデータベース，デバッガログなど情報が散らばっていて探すのが大変 区別することなく検索できるクエリ（fat query）を提案 デバッグにおけるステップ４，５（修正）を支援、Ｑ６（類似バグ）を支援 本研究ではステップ４，５を支援、Ｑ１～Ｑ４を支援

まとめと今後の課題 まとめ 今後の課題 関心事グラフにデバッグ情報を追加したＤＣＧを提案 関心事に応じたクエリを提案 オープンソースを使った評価 不足情報は適宜補う どういった状況でどの程度の支援ができるか 有効に機能するデバッグの種類の拡張 現状ではAPIの利用の誤りなどのデバッグが中心 関心事グラフに基づいているため 将来的にはロジックエラーなどのデバッグにも対応したい 実行履歴の追加（関連研究１） デバッガログ、ブレークポイント履歴の追加など（関連研究２）