netail.net
自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.
最近のお知らせ (古いものはこちら)
2006-10-26 [長年日記] ▲
_ [論文] プログラム実行履歴からオブジェクトのステート図を抽出する ▲
Valentin Dallmeier, Christian Lindig, Andrzej Wasylkowski, Andreas Zeller: Mining Object Behavior with ADABU.
Proceedings of WODA 2006, pp.17-23.
状態遷移はメソッド呼び出しによって引き起こされるのだから,メソッド呼び出しによってラベル付けされる状態遷移図を実行履歴から抽出してしまおう,という論文.
状態遷移のラベルは状態変更を起こすメソッド群(mutator)とする一方で,状態のほうは状態監視用のメソッド群(inspector)の戻り値によって定義している.inspector メソッドの条件は,引数なし,戻り値が void で,副作用を持たないこと.
プログラムの監視方式はかなり単純.mutetaor メソッドの中身をすべてtry-finallyでくくって,finallyの中でinspectorをすべて呼び出し状態を記録している.
inspector によって int 型などを返されると状態数が大変なことになるので,整数値の範囲などを抽出して(dynamic invariant detection などの手法),abstract state として状態数を減らして,それらを mutator メソッドで接続することでモデルを作成する.
動的抽出なので,モデル上に,何回その遷移が起きたかを表示することで,一般的なパスとそうでないパスを明示したりできる.
関連研究としてはインタフェース抽出,dynamic invariant detection 他.けっこう挙げられているので,文献読みの基点としてもよさそう.
監視用のメソッドがある程度用意されていないと動かないかなとも思ったけれど,AspectJのインタータイプ宣言とかを使って監視用インタフェースを勝手に追加して,データ記録もアスペクトとして実装すれば,けっこう簡単に既存システムに組み込んで使えそう.状態の抽象化部分を何とか実装できればという条件付きだけど.
2006-10-24 [長年日記] ▲
_ 最近のお知らせを上に出すようにしてみました ▲
フリーソフト系なリンクでたどってくる人が多いと思うので,リリース関連情報を探しやすいようにと作ってみました.
tdiary のプラグインである category.rb をいじって,特定カテゴリの最新記事のリストを作っています.カテゴリ名をクリックすると表示される記事一覧の最新3つだけを出力しています.
実装は category_list_sections をかなり単純化したものです.コードはこちら(改造したところだけ抜粋しています).やっつけ仕事なのでコードは適当です.カテゴリごとの記事一覧のときだけ使われる categorize 処理を毎回呼び出すようになってるので,効率は少し悪いかもしれません.
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 の制約(入力がプログラムから制御可能で,結果の成功失敗が判定可能とか)をうまく満たせるような状況に持ち込んでるのは,やり方としてうまいと思う.
気になる弱点(?)は,特定のコンポーネントを怪しいとにらんで動作記録をとったときに,「なぜその入力が来たのか」を調べようとすると,境界を再設定してデータ取り直しという,大変な作業が待っていそう,というあたり.
今後どうなるかはけっこう楽しみ.
2006-10-21 [長年日記] ▲
_ [VolumeDeskbar][お知らせ] VolumeDeskbar 1.0.12 リリース ▲
リリースといっても,前バージョンからの変更は「枠を表示しない」オプションを追加しただけです.
標準では白い枠が消せます.そのぶん,音量バーが若干太く表示されます.
2006-10-19 [長年日記] ▲
_ [ツール][Java] soot の points-to set 解析設定 ▲
jEdit のようなGUI・スレッドをがりがり使ってるアプリケーションを解析するときは,-p cg verbose:true,jdkver:4,safe-forname:true,safe-newinstance:true
あたりのオプションを付け加えてやらないと,うまくコールグラフができず,GUI関連のコードに対してまったく points-to set が生成されない,ということになってしまうようです.
points-to set 解析には,Paddle よりも高速かつクラッシュしない Spark のほうが,現時点では良いようです(-p cg.spark verbose:true,enabled:true
).また-p cg.spark propagator:iter
オプションを追加すると,標準設定(propagator:worklist
)と結果が変わります.worklist では一部 points-to set が計算できない場所があるようです.iter による反復処理の結果が,worklistの結果と包含関係にあるかどうかは分かりません.
2006-10-14 [長年日記] ▲
_ visa RC1 を試してみた ▲
hyCalendarとVolumeDeskbarをテスト動作させてみるために,VMware PlayerにWindows Vista β2 をインストールするまとめのとおりにVMを作ってインストールしてみた.
オーディオデバイスは上記サイトの設定には書いてないので,以下のように追加してみた(VMWare Workstation で作った別VMの記述からコピーしてきた).
sound.present = "TRUE" sound.fileName = "-1" sound.virtualDev = "es1371" sound.autodetect = "TRUE"
シャットダウン時にブルースクリーンになったりする怪しさはあるものの,何とか動いた.
hyCalendarのほうは,全部をテストしたわけではないものの,いちおうある程度動作しているみたい.拡張子の関連付けだけ,「管理者として実行」しないと失敗した(Volume DeskbarのDLL登録は普通にできた).
Windows Vista では,ボリュームコントロール自体が,このスクリーンショット(png)のように,アプリごとの音量を一緒に表示されように変わっていたりする.VolumeDeskbar で音量をいじっても,「アプリケーションごとの音量設定」だけが変化して,Windowsの持つスピーカーの音量を調整できなかった.こちらは使っているコンポーネント依存なので,今のところどうしようもない.
2006-10-12 [長年日記] ▲
_ [論文] AOASIA2006関連その4(最後):余談 ▲
誰かの指摘やら何やら,適当にメモしたものの独立した文章にまとめるほどでもなかったので,とりあえずリストアップだけしときます.
- AOP のモジュール性などの特性についての議論を Awais Rashid が UML 2006 に投稿しているらしい.
- アスペクトって何?という高レベルのコンセプトが結局何なのか,まだ説明するのは難しそう.キラーアプリケーションはやっぱりロギング?
- アスペクトを導入したことで,設計段階で「意図」を表現しやすくなった.
- アスペクト指向は eXtreme Programming なんかに似ていて,手早く設計を表現するのに向いてる気がする.XPの結果分かったことは,設計をしなくて良いのではなく,設計を柔軟に変更できるようにするのが良いということで,設計は必要だった.
- 議論のやり方について,Guenter からもらったアドバイス: 「突っ込みどころを見つけたら,すぐに口を挟むんだ」(意訳)
お食事会のときはだいぶ人数減ってたものの,座ってたテーブルは賑やかでした.メニューにはアルファベット表記はまったくなかったんですが,同席してた東工大の柳澤さんが頑張ってくれたので助かりました :)
知らない言語に対するパターンマッチ能力の発揮というのはどこの人でも変わらないようで,「ここはビールの欄」と説明しただけで,「ビール/黒ビール/ハーフ&ハーフ」の意味を類推したりしてたのはちょっと面白かったです.