«前の日記(2006-10-21) 最新 次の日記(2006-10-24)» 編集

netail.net

自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.

最近のお知らせ (古いものはこちら)


2006-10-23 [長年日記]

_ [論文] イベントを記録/再生してデバッグ

Alessandro Orso, Shrinivas Joshi, Martin Burger, Andreas Zeller: Isolating Relevant Component Interactions with JINSI.

Proceedings of WODA 2006, pp.3-9.

プログラムの動作が失敗する場合に,コンポーネントレベルでのイベントを記録しておいて後から再生することで,デバッグを行う環境を作ろうと提案している.

注目する特定のコンポーネントに対して「境界」を越えるコンストラクタ呼び出し,メソッド呼び出しと戻り,フィールド操作を記録する.このときに,引数や外部メソッドからの戻り値などのプリミティブは全部値まで覚えておく,また,境界を越えない内部呼び出しなんかは無視するみたい.

で,その対象コンポーネントの周辺をすべてモックに差し替え,記録した外部とのやりとりを再生すれば,そのコンポーネントだけを独立してテストできる.この「再生」処理は完全に自動化できるので,delta-debuggingを適用し,問題が発生するような短いメソッド呼び出し列を探索する.

観測するのはあくまで境界を出入りする呼び出しなどだけなので,観測対象はコンポーネント単独でなく,特定のサブシステムなどの単位でも利用できる,とも述べている.一方で,外部からのメソッド呼び出し回数などは減らせるが,そのコンポーネント内部の処理量は減らせない(処理が多いコンポーネントのデバッグはこれでも大変かもしれない),リアルタイム系の処理は再現できない,といった弱点はあるし,コンポーネントの観測境界をどう適切に設置するかというのも難しいかもしれない.

個人的にはかなり良い印象のアプローチで,「プログラムの実行履歴データを全部保存するぞ」というomniscent debuggingよりはだいぶ現実的だという印象がある.それに,彼らが過去に提案している delta-debugging の制約(入力がプログラムから制御可能で,結果の成功失敗が判定可能とか)をうまく満たせるような状況に持ち込んでるのは,やり方としてうまいと思う.

気になる弱点(?)は,特定のコンポーネントを怪しいとにらんで動作記録をとったときに,「なぜその入力が来たのか」を調べようとすると,境界を再設定してデータ取り直しという,大変な作業が待っていそう,というあたり.

今後どうなるかはけっこう楽しみ.

お名前:
E-mail:
右の画像に書かれている文字列を入力してください:
コメント: