netail.net

_ AOSD Keynote ▲

Keynote 1:Aspects - From Promise to RealityDr Daniel Sabbah, Vice President, IBM Development and SWG Technology,Application Integration and Middleware Division,Software Group

AOSD を IBM では使ってます，という keynote．AspectJ の使い方としては，private な（バージョン依存の）API 呼び出しを禁止するといった渋い方法も．アスペクト干渉など，一部では問題が山積みのような気もするのだが，使い方次第，ということだろうか．実際の開発では，干渉っていうのはあんまり起きないのか，それとも干渉が起きないようにうまく書いているのか．

Java クラスを EJB コンポーネントとして動かすなんてこともやっているらしいので，たいしたもの．

ソフトウェア工学をきちんと教えるような体制が重要だよ，というところは主張していた．

質疑応答では，ドキュメントはどうしてますか，とかIBM は資源がいっぱいあるからいいけど，資源がない人はどこから始めるのでしょう，といったものが出ていた．これだ，という解決方法はどうも今のところないみたいだが．オブジェクト指向でもドキュメントなどが固まったのはだいぶ後になってからなので，アスペクト指向もそうなのかもしれない．

_ AOSD Tutorial ▲

Tutorial T5: Good AOP: Idioms, Rules and Patterns in AspectJWes Isberg, Adrian Colyer によるチュートリアル．

アスペクトは Role-based design に親和性が高く，デザインパターンには Role-base なものが多いらしい．

基本的には，「同時に変更されるようなコードは１つのモジュールに」というデザインが良いらしい．また，モジュールを abstract/concrete に分類したとき，concrete -> abstract という依存関係は OK だが，逆はよくない，という基準で作れ，とも言っていた．このあたり，わりと一般的ではある．

_ AOSD Tutorial ▲

Aspect の使い方として，・元の振る舞いを変えない検査など（Invariants の追加）・制約の付加（古いコードとの整合性チェックなど）・新しい join point 指定 (「JUnit テストの assert 前後」など）を挙げていた．

面白い idiom としては，次のようなものがあった．

"_" で始まるフィールド以外を禁止するdeclare error: set(* *) && !set(* _*)

あるインタフェースを implement しているすべてのクラスを検知する（implements している == クラス初期化コードが動くので検知できる）pointcut anyRunnableImplementation(): staticinitialization(IRunnable);

delegation を行うための this 差し替えpointcut delegationScope(D d): this(d);around(D d): delegationScope(d) { proceed(expr ? delegate : d);}

_ AOSD Tutorial ▲

注意点として挙げられていたのは，Abstract Aspect を使うとき．

抽象アスペクトに定義された pointcut を，複数の継承したアスペクトでオーバーライドした場合，それらの pointcut を p1 と p2 とすると，p1 && p2 であるような join point ではadvice が２回実行されるので注意が必要．declare error: p1 && p2; のようにしてエラーを出させる方法もあるが，これは p1 と p2 が両方とも static でないといけない．

また，やはり，join point が変化したら pointcut も変わる，というところだけは注意が必要らしい．何か依存関係解析でも必要だろうか．

_ SPLAT2004 ▲

SPLAT2004 のまとめ．

Comprehensibility セッションでは，

Karl Lieberrharl は，Demeter ツールを使ってオブジェクトを traverse するコードを書き直したら，どのくらい短くなって，理解性が上がったか，という話をしていた．

Abstractness = 書き直し前コードの長さ / 書き直し後のコードの長さという考え方は単純だけど．

また，Role モデルが好きっぽい人が，アスペクトの依存関係の管理することが大事だ，というように発言していた．しかし，依存関係を explicit にすると non-invasive adaptation がなくなってしまう，ということで対立していた．今のところ non-invasiveness のほうが大事で，explicit にするのは統合開発環境の役目じゃないか，というような考え方ではあるらしいが．

また，pointcut は構文的なものと論理的なものとでは差異があるため，semantic な join point という考え方がもっと必要そうだ，という意見には，みんな賛同していたが，今のところこれだ，というものはない様子．来年くらいにはいっぱい出てきそう．

しかし，「汎用的な（どんな場面でも動く）コードは複雑」という考え方と，「抽象的なコードのほうが理解しやすいのではないか」というすごく微妙な対立が起こっていたりした．

_ SPLAT2004 ▲

Predictability セッションでは，アスペクトを使って表明を書きましょう，という話と，アスペクトを使ってデータ暗号化アスペクトを書いてみました，という話の二軸．

表明を複数に分離する（コンポーネント側に「本来の制約」を書いて，アプリケーション側に「アプリケーション依存の制約」を書く）という考えに，Erik Ernst が食いついてきた．

表明の持つ副作用の問題について，データ暗号化のアスペクトを書いた人が，副作用の問題は非常に大きくて，アスペクトが気づかないうちにデータを壊したりする可能性を何とかして防げたらうれしい，というふうに発言していた．しかし，副作用を防ぐという意味では C++ の const などがあるが，「本当の」const はデータフロー解析などを使えばある程度できるがdata flow pointcut などは難しいのではないか，とも言っていた．JAC (Java Access Control?) という論文が ECOOP に出ているらしい．

しかし，実用的には，Java 1.5 で導入された readonly 属性付加などを使えばそれに近いことができるのではないか，ということを言っていたので，実践してみる価値は大きそう．表明に違反したときどうするか，は考えないといけないようだが．

ただ，みんな Predictability と Comprehensibility について明確な区別を持っているわけではないらしい．Predictability は「あるコード片の動作を予測できるか」という感じで何となく思っていて，Comprehensibility は「全体的に依存関係などを把握できるか」というくらい，らしい．Predictability は f(A) + f(B) と f(A+B) がどう違うか，といった問題のようでもある，とも言っていた，

_ SPLAT2004 ▲

Evolvability については，Erik Ernst が，アプリケーションの修正単位（アスペクト）が「相互に干渉しないべきだ」という立場を取っていた．pluggability というのを重視して，「あってもなくても動く」ような状態をうまく作ることで，システムの信頼性などを上げようとしている．

でも，「そんなので本当に必要なものが作れるのか」みたいにけっこう対立していた．どうも，「こう書けるとうれしい」派と「こう制限すると保守性が上がってうれしい」派に別れているような印象．

ベースプログラムを変更すると join point が変わるのでpointcut 側も変更しなきゃいけない，というのが嫌なので何か semantic な情報があればいいのだが，というような話もあった．下手に，「AのあとのBの呼び出し」といった言葉を作ると，ドメインに対応する言葉がないので困る，というような発言もあった．特定のイベントに名前をつける，といったイベントモデルなどが似ているといえば似ているか．

_ SPLAT2004 ▲

Semantic Interaction については，Aldrich という人が，external/internal 呼び出しを区別したり，モジュール境界をきちんと考えましょう，と発言していた．ただ，モジュール境界による区別をしてはいけない場合もあるよ，と反論も出ていた．その場合はモジュール境界をちゃんと引き直せばいいだけのような気もするのだが……．

アスペクトやクラスをグループ化して，何らかの制約を付加する，というのはやはり他の人も考えていたらしい．振る舞いを「変更していい」「値にアクセスしていい」といった情報をモジュール側に記述してアスペクトが「不用意に」値を変更したりしないように，という考え方も提案されていたが，簡単には解決しなさそう．「どこでモジュールを切りますか？」というのが出てこないので議論がうまくいってないような気がする．

ワークショップ全体の総括としては，

・Core Logic (class) と Aspect が明確に結びつきすぎるのはよくない

・何らかの情報隠蔽がほしい

・高水準言語を目指すべき？

・core と aspect の双方に表明を付加して，結果を予測可能とすることが有効？

といった形で締めくくられた．

_ AspectJ ▲

"Lancaster" のリリースは結局AOSDには間に合わず．コードネームに締め切りいれるのは間違いということか．