Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
Aspect Oriented Programming トップへ戻る

アスペクト指向プログラミングについて(2001/06 輪講資料)

石尾隆 (t-isio@ics.es.osaka-u.ac.jp)

オブジェクト指向の特徴

システムをコンポーネントに分解する
- コンポーネントはシステムの機能をカプセル化する
非機能的要求などはうまくカプセル化できない
- crosscutting concerns
- モジュールの境界を越えて影響する要素
  - エラーチェック
  - 同期処理
  - ロギング
  - パフォーマンス上の考慮
- コードが各所に分散し、モジュール性を悪化させる

アスペクトの導入

非機能的な要求を独立して記述
コンパイル時, 実行時に結合する
- Aspect Weaver (Weave: 織り込む)
- 結合の基準となる点: Join Points
  - Join Pointsの例: メソッド呼出, メソッドからのリターン(AspectJ)
アスペクトの変更は、コンポーネント側には影響を与えない
モジュール性、保守性が向上する

コンポーネントとアスペクト

コンポーネント
- 一般的オブジェクト指向言語でいうクラスのこと
- システムの機能的分解の単位
- 手続きとしてきれいにカプセル化できるもの
- 例: GUIの部品、画像フィルタ
アスペクト
- 新しく導入したモジュール単位
- きれいにカプセル化できない要素
- コンポーネントの意味や性能に影響する
- それだけで自立した記述
- 例: メモリアクセスパターン、並列オブジェクトの同期

記述に用いる言語

Component Language
- コンポーネントを記述する言語
- 従来のオブジェクト指向言語、手続き型言語
Aspect Language
- アスペクトを記述する言語
- ドメイン特化言語でもよい
- アスペクトをより自然な形で記述できることが望ましい
- AspectJではJavaの拡張

ケーススタディ (1)

CLOS(Common Lisp Object System)による画像処理システムの開発
128x128画像に対する同一の処理

画像にフィルタを順次適用していく

   +---------+              +---------+
   |old image| => Filter => |new image|
   +---------+              +---------+

フィルタを適用するごとに新しい画像を生成

ケーススタディ (2)

純粋なオブジェクト指向の実装
- LOC=1500, 8x8画像でも約100秒, 中間処理画像158250枚
手動での最適化
- LOC=35213, 195ms, 233枚
画像フィルタ処理に対するAspect Weaverによるパフォーマンス向上
- アスペクトを定義
  - メモリ領域の再利用
  - 中間結果の再利用
  - ループの最適化
- LOC=4105(weaverのコードを含む), 850ms, 43枚

Aspect Weaver

現時点で公開されているWeaver
- AspectJ
  - Javaを拡張したコンパイラ
  - アスペクトを言語要素として定義
  - http://aspectj.org/
- AspectR
  - Rubyの拡張モジュール
  - アスペクトをAspectクラスのサブクラスとして定義
  - http://www.ruby-lang.org/en/raa-list.rhtml?name=AspectR

AOPのメリット

crosscutting concernsのモジュール化
コード量を減らせる
- Asepct Weaverを作るほうが、自分で"tangled code"を扱うよりも容易
アスペクトとコンポーネントを独立して再利用できる
- そのシステム特有のコードを分離できれば、コンポーネントの再利用が容易になる
Aspectの"plug and play"

AOPについて考えられるデメリット,問題点

プログラムの動作順序が不透明になる
- コンポーネント側のコードからは、どのアスペクトの影響を受けるかわからない
  - アスペクトは"なくても機能を損なわない"ような自立した記述であるべき?
- コードレビューなどが困難になる可能性がある
- アスペクトに含まれたバグが拡散する可能性がある
AspectJにおける問題
- aspectの影響を受けるクラスについてはソースコードが必要
- ライブラリのクラスに対してはaspectを付与できない

その他

設計のプロセスがまだ存在しない
Aspect Weaverの実装、公開、再利用が少ない
デバッグ手法等が確立されていない
統合開発環境との連係
- アスペクトとコンポーネントの相互関係の取扱
- AspectJ: AJDE for JBuilder, Forte, Emacs

AOPはどこに使える?

アスペクトだけでプログラムが組めないのか?
- どのようにアスペクトを結合するかを示すプログラムが必要
- 「アスペクト指向」という名がないだけで既にあるアプローチ
高度なAssertion, あるいはプリプロセッサとしての利用
- コンポーネント側はアスペクトについて知るべきなのか?
- アスペクトはコンポーネントのカプセル化を破壊してよいのか?
- AspectJではやや機能不足?
  - たとえばある変数の値の変化に対しての処理を記述したい
  - 自分でWeaverを作成する手間はどの程度か?
オブジェクト指向プログラムが既にある場合
- モジュールに分散したプログラムを抽出するために役立つ
- 既にあるプログラムを壊さずに、裏で並行動作するプログラムを書ける
- 最初からアスペクトを考慮に入れることはできるのか?

AspectJに付属したサンプルプログラムの例

Timeserver
- Clientのsetup完了タイミングを"setup" pointcutとして公開
- TimeServiceへの接続処理を"serve"として公開
- Abort, Retry処理をaspectとして定義して"setup", "serve"に接続する

参考文献

[AOPatDSL 97] Aspect Oriented Programming, Kiczales,G., Irwin,J., Lamping,J., Loingtier,J.M., Lopes,C.,
Maeda,C., Mendhekar,A., DSL '97 - First ACM SIGPLAN Workshop on Domain-Specific Languages, 1997

[AOP 96] Aspect-Oriented Programming, Gregor Kiczales, John Irwin, John Lamping, Jean-Marc Loingtier,
Cristina Videria Lopes, Chris Maeda, and Anurag Mendhekar, ACM Computing Surveys Vol. 28, No. 4es, 1996