netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-04-03 古い日記からの変換データ [長年日記] ▲
_ EDエディタ ▲
1.2 から 1.3 に移行してみたら，なぜかファイルから関連付けで開いたとき，ファイルはちゃんと復号されるのだが，なぜか暗号化エラーのダイアログが出る．謎．
ファイルごとのパスワード設定機能とかは必要ないので，とりあえず 1.2 に戻してみた．
_ Java ▲
Java から USB を使えるらしい．JVM さえあれば OS を選ばない，という意味では，能動的にユーザが制御するようなデバイスを作るときにはけっこういいかも．ネイティブコンパイルできるのならカーネルに組み込み……というわけにはいかないんだろうけど（JDK をリンクするとバイナリが大きくなるだろうから）．
http://www-6.ibm.com/jp/developerworks/java/040312/j_j-usb.html
_ コードクローンからのアスペクトマイニングというのが狙っている人はやはりいるらしい．私自身は検討したけれど捨てているのだが． ▲
・どれがアスペクト候補か，というのをどうやって決めるか・うまくアスペクト候補を引き剥がせるか・アスペクト候補に該当するがクローンでないものを どうやって一緒に引き剥がすか・クローンだけれどお互いに関係ないものをどうやって区別するかといった問題山積みなところが気になる．
_ PROSE ▲
Dynamic AOP の実装．ミドルウェアとかに使おうと思っているらしい．しかし，ユビキタス・コンピューティングな世界では，端末が，移動先で（地域的な設定を持った）アスペクトの影響を受ける可能性がある．このとき，アスペクトは，他のベンダーが提供したものである可能性が高いので，セキュリティ上の問題などがかなり大きいように思われるので，そのあたりに研究ネタがありそう．……という話を，某企業から東工大に出かけている人がしていた．
_ Fragile Base Code Problem ▲
ベース（通常はクラス）コードが変更されて，Join points が変化し，アスペクトの pointcut 定義がうまく動かなくなって，プログラムが壊れてしまう問題．
これに対して，semantic join points のような，もっと違う「何か」を使おう，という動きがある．region アプローチなどは，システムの状態に注目しているので，ある意味では semantic join points に属するのかもしれない．
_ AOSD ▲
AOSD 2004 Technical Papers: Languages II
Maja D'Hondt, Viviane Jonckers:Hybrid Aspects for Weaving Object-Oriented Functionality and Rule-Based Knowledge.
business rule を論理型言語(prolog)で書いて，メインプログラムはオブジェクト指向(smalltalk)で書いて，メソッド呼び出しに対して assert や query のような論理型言語が得意とする部分を実行させる，らしい．効果のほどは不明．
メソッドのパラメータなどが prolog 側にどう渡されるか，といったGeneral Model がよく分からない，といった指摘が出ていた．
Remi Douence, Pascal Fradet, Mario Sudholt:Composition, Reuse and Interaction Analysis of Stateful Aspects.
Aspect Interaction を真面目に取り扱っている数少ない人たち．この人たちは，ベースプログラムと，アスペクトの実行はまったく別のものだ，と考えているよう．同じ join point で複数のアドバイスが動くとき，干渉であると考えている．
また，「ひとつのアスペクトは必ずしも *すべての* アプリケーションで動く必要はない」と言っている点もえらいところかも．
ベースプログラムを，正規言語のようなものに直して，アスペクトとくっつけて，問題が起きないか調べましょう，という形式的手法を用いたアプローチ．
この手の形式手法は，どう動くのか直観的でないので，有効性についてもあまり考えられないのだが，もうちょっと，形式手法，制約言語といった系統のベースプログラムが壊れない，アスペクトが壊れないといったことを調べる人には頑張ってほしいところ．
_ AOSD ▲
AOSD 2004 Technical Papers: Applications II
Charles Haley, Robin Laney, Bashar Nuseibeh:Deriving Security Requirementsfrom Crosscutting Threat Descriptions.
「脅威」を { (action, harm), asset } と定義して，要求と，それに対応するドメイン要素，エンティティをインタフェースで相互に接続し，問題が起きるかどうかを考えよう，というもの．
あまり縁がない分野だったりするので効果のほどはよくわからないが．脅威を明示する，というタイプの手法なので，Potential Problem については対処できない．たとえば，金庫の鍵がないと金庫は開けられない，ということは明示できるが，鍵の管理に問題がある可能性に気づくことはない，らしい．
_ AOSD ▲
Bruno Harbulot, John Gurd:Using AspectJ to Separate Concernsin Parallel Scientific Java Code.
Java コードを，並列処理(MPI)な部分だけをアスペクト化した，という論文．しかし，スレッドが増えると，同期コードのコストが上がって高速化されていなかったり，どうも取り上げている例が悪いような気がする．ちょっと残念．
_ AOSD Invited Paper ▲
What are the Key issues for Commercial AOP Use - How does AspectWerkz Address them ?Jonas Boner, BEA
AspectWerkz は，XML と xDoclet 的タグ付けを使ってアスペクトを記述する．基本は「多少特殊な情報を付加した」 Java コードという形．そのおかげでIDEは自由に選べるようになっている．
また，AspectWerkz では，AspectJ などで使う pointcuts / advice 以外に，pointcuts--advice 連結の「binding」が増えているところも特徴らしい．
Class loader の管理はけっこう大事だと考えている様子（複数のクラスローダが同時には使えないため）．Runtime Weaving は，unwoven なメソッドの実行にはオーバーヘッドがかからないところが利点である，といっていた．
IDE 等ツール連携に関しては JSR-175 のメタデータ付加によって対応するつもりらしい．また，将来的には AOP をサポートするJVM (JRockit JVM 1.5)，JVMTI ベースの Weaving，Java 1.5 への対応を考えているらしい．
開発環境に対して依存しすぎないように，という立場などは特徴的なところか．今のところ使う必要がないので AspectWerkz を使おうとは思わないが．
_ AOSD ▲
AOSD 2004 Technical Papers: Industry Paper
Miguel Pessoa Monteiro, Joao Miguel Femandes:Object-to-Aspect Refactorings For Feature Extraction.
リファクタリングを行う際に，・ローカル変数への参照の扱い・抽出したアスペクトの配置（可視性）という問題がある，ということを言っている論文．
「どこをアスペクトに追い出すべきか」といった議論とは，論点が違う．可視性の問題には，Encapsulation を守るべきか，Aspect の効果をうまく使うべきか，といった悩ましい問題があるみたい．
