netail.net

_ AOSD 2003 ▲

AOSD2003 の Proceedings が ACM Digital Library で公開された．ということで，さっそく先生に入手してもらうようねだってみる．本当は素直に学会員になればいいんだが，手続きが面倒なのでしばらく先生に頼ることにする :-)

_ 通販 ▲

とあるサイトで，ワインのメールでの購入ができるというので，メールで注文を投げてみたが，返事が３日経っても来ない．サイト自体は生きてる様子なのだが，３日で返事が来ないというのは他の通販専門系のサイトに比べて圧倒的に遅いので，ちょっと不安だったりする．

_ 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

_ AOSD その他 ▲

Student Extravaganza や，その他の雑談で得られた話．

_ コードクローンからのアスペクトマイニングというのが狙っている人はやはりいるらしい．私自身は検討したけれど捨てているのだが． ▲

・どれがアスペクト候補か，というのをどうやって決めるか・うまくアスペクト候補を引き剥がせるか・アスペクト候補に該当するがクローンでないものを　どうやって一緒に引き剥がすか・クローンだけれどお互いに関係ないものをどうやって区別するかといった問題山積みなところが気になる．

_ 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 の効果をうまく使うべきか，といった悩ましい問題があるみたい．

_ [お出かけ]明石 ▲

私用で明石へ行ったので，ついでに駅前で明石焼きを食べる．５年前か６年前に姫路で食べて以来．

さらについでに，本屋で小栗左多里，トニーラズロ著「ダーリンの頭ン中」を購入．

_ [論文]属性ベースの(AspectJの)Join Pointで指定すると問題が起きる例 ▲

Donal Lafferty: Avoiding Incorrect and Unpredictable Behavior with Attribute-bassed Crosscutting.

Proceedings of ACP4IS, Chicago, Illinois, March 2005.

.NET用に言語非依存のAOPフレームワークを作っている人らしく，AspectJなどのメソッドの属性などでポイントカットを指定する方法だと，SML.NETなど一部の言語で，ポイントカットにマッチしてしまうような作業用メソッドがコンパイラによって生成されてしまうことがある，というもの．で，アトリビュート（メタデータ）をメソッドごとに付加した方法だったら，Join Pointが勝手に増加しないので無難だよ，というふうに主張している．

_ [論文]Pointcut記述のマッチ可能性の計算量 ▲

Karl J. Lieberherr, Jeffrey Palm, Ravi Sundaram: Expressiveness and Complexity of Crosscut Languages.

Proceedings FOAL, Chicago, Illinois, March 2005.

AspectJにおけるポイントカットやDemeterJにおけるインスタンス探索を，コールグラフやインスタンス関係のグラフからマッチ対象を選択する "Selector" として考える．このとき，Selectorが特定のノードに常にマッチする場所を見つけられるか，１つもマッチしないことが調べられるか，といったことが最適化時に重要となる．

で，アルゴリズムの計算量を調べたら，基本的には，intersectionとnegationを使わなければ，多項式時間でよく，それ以外でも一部多項式時間で解ける問題があるらしい（それ以外はNP完全）．

面白いところは，AspectJとDemeterJとをグラフ選択問題として共通化してるところ．AspectJで，コールグラフ上で

call(void f()) & !cflow(void g())

のようなメソッド選択の式を，DemeterJを使って

from main() bypassing g() to f()

のように置き換えることで negation や intersection を取り除いて多項式時間の問題に帰着できるらしい．

_ [ツール] XTMemo ▲

TODOというほどでもないメモを管理するのにいいツールはないかなと思って，XTMemoというツールを試してみた．

ファイル作る→ファイルの中にメモを作るという形で，メールボックスとメールにも似たインタフェースで，けっこう面白い．保存は単なるテキストファイルなので，加工しやすいのも利点．

とりあえずwikiに書いてたメモをいくらか移行してみた．作ったメモの保存順序が更新日時ではなく作成時の日付順序である（しかもソート機能を持たない）というのが少し気にかかるが，検索したキーをそのままタブとして保存してくれたり，タイトルの横に本文の内容の先頭部分を少しだけ出してくれるのは親切で，満足度はそこそこ．

研究関連のメモを整理しておくには，何か足りないような気もするのだけど，何が足りないか，使ってたらそのうちわかってくるかもしれない．

インストール時，データ保存フォルダを指定するときに，何も考えずに普通にテキストファイルが入ってるフォルダを選んだら，勝手に手元のテキストファイル群を加工されてしまった．なぜ保存先のフォルダを先に選ばされるのかなと思ったら，基本的には指定フォルダ内にあるデータは全部既定の形式のテキストファイルだとみなして扱うということらしい．