netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-10-28 古い日記からの変換データ [長年日記] ▲
2004-10-27 古い日記からの変換データ [長年日記] ▲
_ [work]エイリアス解析の価値の謎 ▲
エイリアス識別付きのフィールド間データ依存関係の解析を実装しようとしてこける．エイリアス情報が変わるとデータフローが変わってデータフローが変わるとエイリアスの流れも変わるんでは…．という疑問があるし，あまり効果的な解析方法がない．
Flow Sensitive にエイリアスを解析しようとするとメソッド呼び出し順序などが必要になってくるのだが，外部へのメソッド呼び出し時に何が起きるかは（多態性の都合で）決定できないので，外部からメソッド呼び出しを受ける可能性を考えると非現実的．
結局手抜きな実装としては，自分のメソッド内で作ったオブジェクトに対してだけ，外部から参照可能なフィールドに代入されるかメソッドの引数で外へ出て行くまでエイリアスを識別しておくということになるのだろうか．ここでも「外部から参照可能な」が曲者で，Java の private フィールドって自分自身の他のインスタンス（this.class.new したもの）からは参照できてしまう．
こうなると，ローカル変数に代入されているものだけが対象となるわけで，エイリアス解析で解決できる問題がすごく狭いような気がしてきた．
this と，それ以外（thisあるいは他のインスタンスを指す参照）はいちおう区別しておいたほうが良さそうに思えるが，それ以外の場面ではあまり真面目にエイリアス解析しないほうが幸せっぽい気がしてきた．
2004-10-26 古い日記からの変換データ [長年日記] ▲
_ [work]例外ハンドラのデータ依存解析 ▲
OOPSLA 開催でまた論文リストが増えるぞっと思いながらコード書きが続く．
例外ハンドラ（catch ブロック，finally ブロック）へはどこから例外で移動してくるか分からないので，実はデータフローが決定できない．Checked Exception や Null Pointer Exception 系などは絞れないことはないのだが，あまり効果として嬉しくないので，とりあえず例外ハンドラの先頭（Handler Entry 仮頂点）ですべてのローカル変数を初期化したとみなしてデータ依存関係を整理することにした．
_ [Java]enum ▲
enum 型が使いたくなったので Eclipse 3.1M2 で使えたのかなと思って試してみたら，まだ対応してなかった．Eclipse 3.1M2 のリリースノート
構文的には通るが型としては認識できないみたい．
2004-10-23 古い日記からの変換データ [長年日記] ▲
_ AspectBench ▲
AspectJ の言語をサポートしたコンパイラの別の実装としてAspectBench 1.0.0 がリリース．パフォーマンスとかを重視しているらしい．http://aspectbench.org
フロントエンドの言語拡張，バックエンドの最適化にそれぞれなんかフレームワークを使っているらしい．AspectJ ベースで言語を少し実験するとかの材料になるかも？
Sable Research Group とかも絡んでると書いてるのでパーサが SableCC でできてたりするのだろうか．色々気になるところはあるツール．
_ [Java]バージョンＩＤ ▲
Serializable なクラス（独自の例外クラス）を作ったら serialVersionUID を定義しなさいと警告が出てきた．
どうやら serialver とかいうツールで作れるらしい．
serialver -classpath クラスパス クラス名
単にメソッドとかのシグネチャから計算してるみたいだけど．リファクタリングとかしたらパッケージを移動すると値が変わってしまう（ソースコードを修正しないといけない）のかな？
_ [work]バイトコードのスタック変化 ▲
Java バイトコード上でのデータ依存関係を調べるのにスタックの変化情報が必要なのだが，BCELの org.apache.bcel.generic のパッケージサマリを見るとだいたいの情報が載っていることが判明．
抽象クラスで複数の命令の処理をまとめて書かないと，オブジェクトの種類による条件分岐がえらいことなりそうだが．
_ [論文]モデルの一貫性管理 ▲
Models for Non-functional Aspects of Component-Based Software (NfC'04) の論文を消化．
Francois Mekerke, Wolfgang Theurer, and Joel Champeau:Non-functional aspects management for craft-oriented design.利害関係者ごと（あるいは開発チームごとなど）に作成したモデルをいかに一貫性を保つかが問題となるが，そこで， Facet と Pivot という二つを使ってモデルを管理しようというもの．Facet は，システムの色々な側面を表現したもので，最終的にはプロダクトとなるもの．それぞれ，external (pivot から可視)なものとinternal (外部から不可視) なもので構成される．モデル自体は，それぞれの Facet ごとに独立な構築になるみたい．で，Pivot というのが連携用の道具で，各 Facet の external な要素間での結合として，データの流れや，成立する不変条件を記述する．
Pivot を先に作って，Facet がそれぞれ何を提供すればいいか明示してから Facet を個別に定義していくような感じなのか．
_ [論文]アスペクト指向なモデリング ▲
Aspect-Oriented Modeling Workshop の論文のうち興味を引いたもの若干をメモ．
Shin Nakajima, Tetsuo Tamai:Lightweight Formal Analysis of Aspect-Oriented Models.Aspect-Oriented Modeling Workshop 2004.
各アスペクトは，ロール同士のインタラクションとしてアスペクトを複数使ったときに正しく動くかどうか，「複数使ったときにどう動くべきか（どう重なるか）」を書いてモデルを動かしてみてチェックしましょうということになるらしい．
Mark Mahoney, Atef Bader, Tzilla Elrad:Using Aspects to Abstract and Modularize Statecharts.Aspect-Oriented Modeling Workshop 2004.
複雑なシステムのステートチャートを作るとき，直交した状態は別々のステートチャートに分離しておいて，あるステートチャートのイベントが，他のステートチャートのどのイベントとして「解釈」しうるか，という定義を付加してステートチャート間の結合を整理しようという話．
あるステートチャートでのイベント発生に他のステートの遷移を設定するというのはAspectJ の before/after の考え方にも近い概念だ，と言っている．
ステートチャート間のイベント連動をどこに書くかというのが問題のような気はするが，それ以外はわりとシンプルな感じ．
Alexis Muller:Reusing functional aspects: from composition to parameterization.Aspect-Oriented Modeling Workshop 2004.
コンポーネントの再利用のためには，関連しあったクラス群をまとめてビューとして扱うのがよい，ということでビューというのがどうあればよいか，メタモデルを定義している．
Subject-Oriented など従来のアプローチでは，再利用を狙ってシステムとは独立にモデルの設計などを行うときにシステムごとの名前の変化などが扱いづらいので，型やメソッド名のパラメータを使って制御するタイプの手法を使って作ったビューを適用していくのが良さそうだ，と言っている．
