netail.net

_ [論文]コンポーネント更新時の問題予測 ▲

Stephen McCamant, Michael D. Ernst:Early Identification of Incompatibilities in Multi-component Upgrades.Proceedings of 18th European Conference onObject-Oriented Programming (ECOOP 2004), pp.440-464,Oslo, Norway, June 14-18, 2004.

データフロー解析を使って，ある関数呼び出し先を新しい関数の実装で差し替えたときに問題が起きるかどうかを予想しようというもの．

基本的には，呼び出し側の事前条件→呼び出し先の事前条件，呼び出し側の事前条件＋呼び出し先の事後条件→呼び出し側の事後条件，というのが成立すればよいらしいのだが．

データフロー解析の例として挙がっている記述が，条件分岐や式の中身まできちんと意識しているっぽいのでそこまでうまく動くのかな？と少しあやしげな印象．入出力のパラメータの関係だけに注目すれば（どのパラメータがどの出力に到達するかだけ使えば）意外とうまくいくのかもしれないが．

C のライブラリに対して適用していて，結果としてはそれなり，ではあるみたい．

_ [論文]カプセル化のポリシー選択 ▲

Nathanael Schärli, Stéphane Ducasse, Oscar Nierstrasz, Roel Wuyts: Composable Encapsulation Policies. Proceedings of 18th European Conference onObject-Oriented Programming (ECOOP 2004), pp.26-50,Oslo, Norway, June 14-18, 2004.

クラスのどのメンバーにアクセスできるかはpublic, protected などで宣言できるが，クラスの利用方法をインスタンス化・継承の２択に決め付けていて，しかもあとから変更がきかない（サブクラスごとに個別にアクセス権を設定したりはできない）．

C++だと friend 宣言を導入したりして部分的に解決しているが，逆にいうとたいした解決方法がないのが現状．

で，この人たちは，クラスのメンバーをグループ化してポリシーとして名前をつけている．たとえば，MyCollectionクラスを作ったときに，add, collect, at だけにアクセスできる「AppendOnly」，remove にもアクセスできる「Collection」，internalAdd にもアクセスできる「All」という３つを定義して，MyCollectionを所有するTransactionProtocolはappendOnlyで，継承するMySetはCollectionポリシーでアクセスする，といったことを別個に宣言することができるようにしている．

Smalltalkをベースに例を説明していて，インスタンスを作る時点やサブクラス定義時に使うポリシーを記述するのだが，そのときに「BasicUseポリシーだけど，そのうちｘｘは除く」といったカスタマイズも許していたり，ポリシー自体はクラスとは個別に名前を付けられるのでReadOnlyポリシーのインスタンスなら……といった記述もできそう．

アイディアとしては面白くて，価値もわかりやすい．インタフェースにアクセス権に関するメタデータを付加する話とも言えなくはない．

_ [論文]動的リンクなコネクタ ▲

Yu David Liu, Scott F. Smith: Modules with Interfaces for Dynamic Linking and Communication. Proceedings of 18th European Conference onObject-Oriented Programming, pp.414-439,Oslo, Norway, June 14-18, 2004.

いわゆるコンポーネント間のコネクタ（import／export）を作りましょうという話を，動的リンク上で実現する話．コンポーネントが動的に差し替えられるような環境などを想定しているらしい．

CORBAなどのインタフェースを双方向性にした，とかJavaなどのクラス単位よりも粒度の粗いコンポーネント単位にした，といった感じの印象でよさそう．逆にいうと，あまり新鮮味のようなものはなかったりする．単に興味の範囲外だからか．

_ [AspectJ]アスペクト指向技術セミナー ▲

とりあえず，セミナー上で登場した質問などはWiki にまとめてみようかと試みてみたり．とりあえず Wiki 準備．アスペクト指向な wiki

_ [AspectJ]アスペクト指向技術セミナー ▲

とりあえず話を聞いてきたことをまとめておくと:

長瀬さんによる「アスペクト指向入門」．アスペクトって何，という基本的な話と，Eclipse による簡単なデモ．長瀬さんは，Join Point Model が話に出てこないので，「そのモジュールはどこで使われるのかを定義する」という形で話を進めていた．授業で使った「いつ実行するか」にも近いが，「どこで」のほうが，ソース上の位置という感じがしてわかりやすいかも．

_ 鷲崎先生による「実践アスペクト指向プログラミング」 ▲

一部，M1相手に授業やったときの資料が再利用されているけれど実行メカニズムとか，ソースコード例とかだいぶ詳しくなっていた．

ひがやすおさんによる「現場で使えるAOP」．Seasar2を使った場合のアスペクト記述方法など，実践よりの話．インスタンスごとに，実行時に適用するアスペクトで，実行のための環境は必要だが覚えることは少ない，という感じ．

立堀さんによる「応用アスペクト指向プログラミング」．アスペクトを使ってデザインパターンを記述した，アスペクト指向リファクタリング，などの話をまとめたもの．

ＱＡとしては以下のような感じ．

・パフォーマンスは悪くならないのか

・コンパイラのパフォーマンスはどうなのか→多少悪くなる．（AspectJ 1.2 でだいぶ良くなっているとは聞いているのだけど， 「手書きの最適化コードよりは遅い」のは宿命． オブジェクト指向が出てきた直後も「遅い」って言われたので， 保守性と速度とどっちが大事かという話？）

・スレッドの競合時，といった記述はできるのか→何らかの形でできたような気はするが不明

・デバッガなどの開発サポートは十分あるのか→ある程度使えるが，まだ十分ではない

・デバッグは難しくないのか． OOP では Liskov の置換原則のような問題を減らすための デザイン規則があるが，AOP にそういったものはないのか．

・設計方法というのはないのか？→設計まわりの話はまだまだ未成熟で， プログラミングがしっかりしてきて， 良いデザインというのが分かってくるまでは難しそう．

・Seasar2ではコンテナの適用作業が面倒ではないのか？→それぞれのフレームワーク個別の支援を用意して， コンテナに依存したコードは書かなくていいようにしている．