netail.net
自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.
最近のお知らせ (古いものはこちら)
2004-11-17 古い日記からの変換データ [長年日記] ▲
_ [work][Java]Ant with Eclipse ▲
久しぶりに Ant の build.xml を書いてみた.JAR を生成する処理とソースコードおよび周辺ファイルのZIP アーカイブ作成処理だが,それぞれ [Run]-[External Tools] から Ant build を使うと,ボタン一つで両方の処理を実行できてかなりお手軽な感じになってきた.
user.dir が build.xml を配置しているディレクトリになるようで,eclipse.home は Eclipse インストール先を指すようだし,プロジェクト自体のディレクトリを指してくれるものが見つからなくてちょっと微妙な感じ.プロジェクトのトップディレクトリに配置しろということか.
_ [論文]イベントパターンを使ったアスペクト記述 ▲
Robert J. Walker, Kevin Viggers:Implementing Protocols via Declarative Event Patterns.Proceedings of the 12th FSE (FSE2004), pp.159-169,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.
FTPプロトコルでのユーザ認証を題材にした論文で,pointcut でイベントを定義する以外に,tracecut というイベント列(pointcut を使って正規表現ぽく指定する)で処理の実行を記述できるようにしたもの.実行が済んだ部分にアクセスする history(tracecut) という述語を使って,過去のイベント情報(システムの状態?)をアスペクトの記述の基準にできる.
状態を保存する部分が自動化されていて便利だ,という主張ぽい.イベントベースのAOP,AspectJ などと比べて表現力,追跡性,拡張性,理解容易性が全部「高い」と言ってるあたりは少し「?」だが,個人的にはけっこうよさげな手法のように見える.うまくベースのイベントと切り分けられるものについては,AspectJ よりもうまくいきそう.
_ [論文]Pointcut のマッチの検査 ▲
Shriram Krishnamurthi, Kathi Fisler, Michael Greenberg:Verifying Aspect Advice Modularity.Proceedings of the 12th FSE (FSE2004), pp.137-146,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.
基本的には pointcut をオートマトンと考えて(受理状態になると関連付けられたアドバイスが実行される),メソッド呼び出し列などのプログラムの状態に対してpointcut がいつ受理されるかどうかを判定しつつ,CTL によって記述した性質をテストするらしい.
使い道としては,pointcut の状態を見ることができるので,複数の類似した pointcut の性質の違いを調べたりするのに使えそうな気はするが….
_ [論文]良い反例の出力 ▲
Sagar Chaki, Alex Groce, Ofer Strichman:Explaining Abstract Counterexamples.Proceedings of the 12th FSE (FSE2004), pp.73-82,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.
モデル上でエラーとなるような反例を見つけて,実行が成功するような実行系列の例と「距離」が近いような実行系列の例として出力したいねという話.
一方の実行系列を他方へと変換するような基本操作の数が,実行系列間の距離となる.ここで,実行系列は,状態と,実行する命令の組の系列らしい.
発想はそのうち参考にすることになるかも?
_ [論文]動的解析による不変条件の推定 ▲
Jeff H. Perkins, Michael D. Ernst:Efficient Incremental Algorithms for Dynamic Detection of Likely Invariants.Proceedings of the 12th FSE (FSE2004), pp.23-32,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.
実行時の各変数の状態から,不変条件を推定するという話."Incremental" なのは,最初の実行で成立した条件を仮に全部不変条件だと思っておいて,反例が見つかった時点でそれを捨てていくというもの.
条件がプログラムのどの場所で成立しているかによって,広い範囲で成立する条件とその部分範囲でのみ成立する条件とをツリー階層で管理することで,反例が見つかった瞬間にツリー間で条件式を移動して,「条件が成立している範囲」の情報を調整する形になっている.
この論文の主旨としては Incremental なアルゴリズムに対して適用したいくつかの最適化方針に対してパフォーマンスを測ってみたというところ.
時間の単位が1000〜20000秒となっているので,実用かどうかというとちょっと怪しげな側面もあるが,重要な場所だけ絞って判定するとか工夫すればそれなりの結果は得られるのかな?と思わないこともない.ただ,サンプルが多くないと「そのテストケースでの不変条件」という微妙な出力を得ることになるので,使い道としては微妙か.