netail.net

_ AOSD ▲

aosd-discuss ML での「手動での join point 記述」から始まった一連の議論が一段落したので，自分用に少しまとめておく．けっこう色々な意見が出た．

発端の提案：予期しない変更に対する対処として，Join Point をプログラム内部に「変更しても良い場所」として記述するのはどうか？Join Point ごとに，他のアスペクトとの干渉しかたも違ってくるし，Aspect Weaving 用の情報も持たせておきたい．

出てきた意見：

・予期せぬ変更を綺麗に扱うのは重要だが，作業時間が短くなるかどうかは別の問題．

・コード単体から，簡単に join point が決められるのか？たぶん無理．

・複数のアスペクトを単一の join point に与えた際，その解決はコードレベルよりもっと上位で行うべき．それを妥当なコストで実現するツールが重要．

・アスペクトやハイパースライスをアプリケーションにマージするのは簡単ではない．注意深い計画と分析が必要である．Hyper/J で正しく作業しようとすると，再度モジュール分析して，影響を受けるハイパースライスを調べて，それぞれテストして，結合してテストして，……といった作業は必要となる．tangled code を避けるんだから，それくらいの作業は仕方ない．If you hack the code, your statements are true, though.If you hack the code, you have no place in a commercial project.

・標準のIDEやコンパイラで使えない言語要素の導入は，開発プロセスに大きな影響を与えてしまうのが問題．

・join point はコントロールされるべき．たとえば， - private なアスペクトはすべての join point にアクセスできてよい． - public なアスペクトは public な join point にのみアクセスする． - 何か適当な protected という範囲のアスペクトもあってよいはず．

・別に用意したスキーマを使ってアスペクトを結合するべき．

・スキーマも一種のプログラムだ．単に一緒に書くかどうかの違い．

_ 論文 ▲

以前，Extended Event Trace 図というのをコンポーネント間のインタラクション記述に使おう，という論文を読んだが，（タイトル：Using Extended Event Traces to describe communication in software architecture）実装言語があるかなーと思って論文の citation を探してみた．結果はゼロ．個人的には１個くらいは期待していたけど．設計時ドキュメントとしての価値はありそうだけど，それ以上の利用はされていないようだ．

_ 論文 ▲

実験の合間に論文を読むのが慣習になりそう．

L. Berger, A. M. Dery, M. Fornarino: ``Interactions between objects: an aspect of object-oriented languages''IL (Interaction Language) の紹介論文．IL はアスペクトを用いてオブジェクト間のインタラクションを書くための言語．

アスペクトを一種の手続き的な役割として使っている印象もあり，オブジェクト同士の対話をアスペクトが担当する．分散オブジェクトの管理なんかを頑張ろうと考えているらしい．これは，オブジェクトが処理の流れをコントロールするべきと思ってる人間にとってはあまり嬉しくない（単にオブジェクトの結合に用いる言語がアスペクトに移っただけであるが）．

アスペクトの利用の例示として挙げている「一貫性保持」はけっこう妥当なものだが，「対話」というほどのものでもないような気がする．もうちょっとリモートオブジェクトの例がほしいところ．

_ TA ▲

実験２回目のTA担当．みんな真面目なのはいいけど，時間ぎりぎりまで作業しようとして片付けが遅れるのは困ったものだ．