netail.net
自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.
最近のお知らせ (古いものはこちら)
2003-02-03 古い日記からの変換データ [長年日記] ▲
2003-02-05 古い日記からの変換データ [長年日記] ▲
_ MD ▲
ポータブルMDが謎のエラーを出すようになってしまった.故障のようだが,保証書その他の周辺品をどこへやったか思い出せない.
とりあえず,当座は PDA + マイクロハードディスクでしのぐことにする.
2003-02-11 古い日記からの変換データ [長年日記] ▲
2003-02-12 古い日記からの変換データ [長年日記] ▲
2003-02-15 古い日記からの変換データ [長年日記] ▲
2003-02-19 古い日記からの変換データ [長年日記] ▲
2003-02-21 古い日記からの変換データ [長年日記] ▲
_ LaTeX ▲
LaTeX で,表の幅がどうしても広くなってしまう.横方向の位置を指定する lrc のかわりに列幅指定の p を使うと位置指定ができない,と困っていたら,表のセルの中で makebox{幅}{文字列} としていればよかったらしい.
2003-02-22 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
何となく検索してたら見つけた論文.
Doug Palmer: "Dynamic Aspect-Oriented Programming in an Untrusted Environment"
動的アスペクトの世界(JACなど)では,特に分散環境の場合,アスペクトが信頼できるかどうかが重要となる.
で,アスペクトを Wrapper として考えたとき,External Wrapper (事前・事後条件と関係ない)とInternal Wrapper (事前・事後条件を維持する)に分類できる.
External Wrapper はアクセス制御アスペクトなど,メッセージを握りつぶすようなものでもよい.なお,Internal Callに対しては External Wrapper は動作しない.
各メソッドに,事後条件を定義しておくと,Internal Wrapper の終了時点で事後条件を検査し,違反していたら処理をロールバックするような仕組みを導入する,(この処理そのものは Validator アスペクトがやる)というもの.考え方としては妥当な気もするが,Wrapper がInternal かExternal かを決めるのは誰の仕事なんだろう.また,悪意あるExternal Wrapperなんかはどうやって対処するんだろう.ディジタル署名とかかなぁ.いちおう,変なinternal wrapperのせいで振る舞いが壊れる可能性は検出できるのかな? 6ページの短いpaperで実験的な評価がないので詳細は不明.
_ 論文 ▲
先の論文で関連研究として挙げていたものは次のとおり.
Software Reconnaissanceテストケースを複数用意して,あるfeatureを「使っている」ケースと「使わない」ケースを用意して,その実行時の違いから Concept Analysis を行う.
BEE++: C++ベースの,分散システムの動的解析フレームワーク.アプリケーションのどこを解析するかは手作業で指定.
ATOM: プログラム解析ツールを作るためのフレームワーク.オブジェクトファイルレベルで行うので,ソース情報は取れない.
Form: 実行時情報取得ツール.実行時のデータからコールグラフを構築する.JVMPI で実装しているので,詳細な情報までは取れない.
_ 論文 ▲
久々に論文読み.Thomas Gschwind, Johann Oberleitner:"Improving Dynamic Data Analyhsis with Aspect-Oriented Programming"To appear in Proccedings of the 7th European Conference on Software Maintenance and Reengineering, March 26--28, 2003, Benevento, Italy, Europe
プログラムの実行時解析で,現在利用可能な方法には次のような問題がある.
- トレースを実行するまでに色々手間がかかる.
- トレースをオブジェクトごとに有効にすることができない
- 特定インスタンスやメソッドごとに指定することができない.
- 引数などへアクセスできない.など.
で,筆者らはARE: A Reverse Engineering tool というものをAspectJ を使ってARE の解析モジュールを作成している.AspectJ の利点は,細かいアクセスが設定できること.ここから,オブジェクトごとのアクセストレースを作れる.具体的には, before() call と after() call を使う.
利点は,
- アスペクトは自動的に組み込まれる.
- AspectJ は JIT をオフにしなくてよい(JVMDIに比べて有利).
- Join Points からソースコードへのマッピングが取れる.
- 呼び出しのときの引数へのアクセスや,インスタンスの識別ができる.
- 開発者が対象のソースコードを読まなくてもよい.
- リフレクションを使っていても大丈夫.
- 引数などの情報も取れる.
- 余分な情報をフィルタリングできる.
- 利用が簡単.
動的解析をして,インスタンスを識別したシーケンス図のようなものを作っているだけで,静的解析との組み合わせは将来の課題としている.
やはり,同じことを考える人はいるらしい.
2003-02-24 古い日記からの変換データ [長年日記] ▲
2003-02-27 古い日記からの変換データ [長年日記] ▲
2003-02-28 古い日記からの変換データ [長年日記] ▲
_ AspectJ ▲
AspectJの,SourceLocation.getFileName が返す形式をどうすべきか,という話が AspectJ-dev に投稿されていた.クラスファイルには Foo.java という感じで,生成ディレクトリの名前が入っていないので(当然だが),バイトコードへのアスペクト結合処理の途中で,今まで getFileName が返していたようなフルパス名を埋め込むことができない,というもの.パッケージ名をディレクトリ階層にして先頭に付けるか,コンパイラに weave 作業しているパス情報を渡すか,と色々考えている様子.
でも,よく考えてみれば,バイトコード中にそのファイルのフルパス名が入っているっていうのは反則に近くて,ファイル移動したら再コンパイルしないといけない.個人的には,パッケージ階層を含めた相対パス形式,つまり foo/bar/Foo.java のような形式で返ってこないかなーと期待しているが,どうなるだろうか.