アスペクト指向プログラムに対する プログラムスライシング 石尾 隆†，楠本 真二‡，井上 克郎‡ †大阪大学大学院基礎工学研究科 ‡大阪大学大学院情報科学研究科 {t-isio,kusumoto,inoue}@ist.osaka-u.ac.jp

発表の概要 アスペクト指向プログラミング アスペクト指向プログラムの開発支援 ツールの実装 今後の課題 アスペクト指向の特徴 アスペクト指向の問題点 アスペクト指向プログラムの開発支援 アスペクト干渉の検出 プログラムスライシングの適用 ツールの実装 今後の課題 この発表では，まず最初にアスペクト指向プログラミングの特徴と，その問題点について説明します．次に，この問題点に対して，有効な開発支援を行うためにアスペクト干渉の検出と，プログラム解析手法のひとつであるプログラムスライシングの適用について説明します．最後に，ツールの実装と今後の課題について述べます．

オブジェクト指向モデル オブジェクトの相互通信でシステムをモデル化 システムの機能をオブジェクトが分担して担当 オブジェクトは内部に必要なデータを隠蔽する 自分にない機能，データは他のオブジェクトに要求 例：学生の成績管理システムのモデル GUI Student 情報を要求 情報の保存・取得 Database それではまず，アスペクト指向プログラミングについて説明する前準備として，オブジェクト指向プログラミングの特徴について，簡単に触れたいと思います．オブジェクト指向プログラミングでは，オブジェクトの相互通信という形でシステムをモデル化します．オブジェクトがシステムの機能を分担し，それぞれ自分が担当する機能について内部に必要なデータを隠蔽します．自分が持っていないデータや必要な処理がある場合は，その要求をメッセージとして他のオブジェクトに送ります． 　例として，ここに学生の成績管理システムのモデルを挙げています．GUIが表示するデータを他のオブジェクトに要求したり，データの保存や取得の要求がDatabaseに送られています． 履修情報 統計情報を要求 Statistics Course 情報の保存・取得

オブジェクトの横断要素 横断要素＝複数のオブジェクトに要求される特性 横断要素をモジュール化する単位「アスペクト」の導入 例：「デバッグ用に，オブジェクトに送られたメッセージを記録したい」 例：「データベースでエラーが起こったらユーザの指示を仰ぎたい」 処理が複数のオブジェクトに分散する 　→ 分散したコードの一貫性の維持が困難 変更すべき場所を変更し忘れる 変更すべきでない場所まで一緒に変更してしまう 書かれたコードを後で見て，どこまでがその処理に関連するか分からない 横断要素をモジュール化する単位「アスペクト」の導入 しかし，複数のオブジェクトに要求される特性は，担当者を決められないためにうまく扱えないという問題があります．たとえばデバッグ用に，オブジェクトに送られたメッセージを記録したい，データベースでエラーが起こったらユーザの指示を仰ぎたい，といった要求です． 　このような，複数のオブジェクトが関わる処理のことを横断要素と呼びます．横断要素のコードは，それに関わるすべてのオブジェクトに分散するために一貫性の維持が難しく，保守性の悪化要因となります． 　横断要素が複数のオブジェクトに分散するために問題が発生するのですから，それを一箇所にモジュール化することで解決しよう，というのがアスペクト指向プログラミングの基本的なアイディアです．そのために，新しいモジュール単位アスペクトを導入します．

Error Notification Aspect アスペクト指向モデル アスペクト= (動作タイミング, 処理) の集合で定義 動作タイミングは，メッセージ送受信や例外の発生など 複数のメッセージを，集合として指定可能 明示的な呼び出しが不要 Error Notification Aspect 「DBへのアクセスは記録」 「エラーが起きたら通知」 ユーザへの通知 ユーザ からの 指示 GUI Student 監視 　アスペクト指向プログラムのモデルを図で説明します．アスペクトが加わったことを除けば，オブジェクト指向と変わりません．先に示した成績管理プログラムにエラー通知処理のアスペクトが加わっており，図には四角い枠として示してあります． 　アスペクトは，オブジェクト間でやりとりされるメッセージや，例外の発生など，プログラム実行中のイベントに連動して動作するプログラムとなります．「いつ，何をするか」という記述の集合がアスペクトとなります．たとえば，このエラー通知のアスペクトは，「Databaseオブジェクトに何であれメッセージが送られたとき」に「そのアクセス内容を記録する」，「Databaseが例外を発生させたとき」「ユーザへの通知を行って指示を待ち，結果をDatabaseに伝える」という記述を持ちます．手続き呼び出し処理を呼び出す側に書くのではなく，呼び出される側に動作する条件が書いてる，という形式です． Database Statistics Course

アスペクト指向プログラミングの利点 モジュール性の向上 オブジェクト側の変更はアスペクトに波及しにくい アスペクトの動作タイミングは集合演算的に取り出せる アスペクトはオブジェクトとは独立して変更可能 ユーザから受ける指示の選択肢が変わってもデータベース側は変更せずに済む 再利用性の向上 データベースオブジェクトがGUIオブジェクトに依存しないで済む アスペクトだけをGUIとデータベースが既にある他のアプリケーションへ移行できる 　アスペクト指向における利点は，モジュール性の向上という形で現れます．主な影響は，次の三つになります． 　まず，オブジェクト側の変更が，アスペクトに波及しにくくなります．アスペクトがオブジェクトに依存しすぎないように，「いつ動作するか」という条件をイベントの集合，たとえば「Databaseオブジェクトに対するすべてのメッセージ」といった集合単位での指定が可能です．オブジェクトごと，メッセージごとに個別に書いていた処理を，単一の宣言にまとめられるようになっています．アスペクトの動作するタイミングをうまく定義しさえすれば，オブジェクトのコードの変更は，アスペクト側のコードに影響を与えません． 　次に，横断要素に関する要求や仕様が変更された場合に，アスペクト以外への変更の波及が少なくなります．たとえば，エラーに際してユーザから受ける指示の選択肢を変えたという場合，GUI側は若干変わることはありますが，データベースオブジェクトはまったく変更せずに済みます． 　最後に，再利用性の向上があります．先ほどの例では，本来ならあるはずのデータベースからGUIへの依存関係が取り除かれており，データベースが再利用しやすくなっています．また，エラー通知処理そのものも．連動するタイミングの集合を置き換えることで，オブジェクトとは独立して再利用できる可能性があります．

アスペクト指向の「複雑さ」 アスペクトは便利だが…… オブジェクトを見ただけでは動作がわからない アスペクトの干渉 単純な代入文でさえも，アスペクトが連動していることがある アスペクトが，予想外の場面で作動してしまう可能性がある アスペクトの干渉 アスペクトの動作順序で実行結果が変わる アスペクトの動作中に別のアスペクトが動作する 　さて，ここまでアスペクト指向プログラミングがもたらす利点について説明しました．アスペクトの利便性については広く認められるようになってきましたが，プログラムの複雑さという観点では，新たな問題を導入しています． 　今までオブジェクト指向プログラミングでは，「誰が何をするか」を順番に書き下していたところが，アスペクト指向では「いつ，何をするか」という記述を列挙する方法に変わりました．そのため，ひとつのファイルに書いてあるプログラムの一部分を見ただけでは，その動作が分からなくなっています．単純な代入文ですら，それに連動するようなアスペクトがあるかもしれません．開発者が不用意なコードを書くと，予期せぬアスペクトの動作を引き起こす場合があります． 　また，アスペクトの干渉と呼ばれる問題があります．これは，単一のイベントに対して複数のアスペクトが動作するとき，その動作順序によって実行結果が変わってしまったり，アスペクトの動作中に別のアスペクトが動作するために，本来意図した振る舞いにならないという問題です．干渉によって発生するバグは，原因の特定が非常に難しいことが知られています． このような問題に対して，統合開発環境などのツールによる，アスペクトの表示やデバッグ支援といったサポートが非常に重要な要素となっています． ツールによるサポートが重要！ アスペクトの表示 デバッグ支援

関連研究 AspectJ† IDE for JBuilder, Forte, Emacs ソースコードエディタで，オブジェクトのコード上にアスペクトの連動位置を表示する アスペクト干渉の検出は行わない アスペクト指向プログラムに対するプログラムスライス計算の提案‡ 提案だけ，有効性については評価されていない 　この分野で，現在までに行われている研究のうち，二つを紹介します．まず一つ目は，AspectJ IDE と呼ばれるものです．Javaのアスペクト指向拡張言語であるAspectJを対象に，JBuilder, Forte, Emacs といった開発環境のエディタ上で，どのアスペクトが連動するかを表示するというものです．アスペクトの存在を意識してコードを書くことができますが，アスペクト干渉などについては，開発者が手作業で調べるしかありません． 　もう一つは，アスペクト指向プログラムに対する，ソースコード情報を用いたプログラムスライス計算の提案です．これは，提案だけが成されているものの，実際にツールとして実装されているわけではなく，有効性についても評価されていない，というのが現状です． †: AspectJ Official Site: http://www.eclipse.org/aspectj/ ‡: Jianjun Zhao, “Slicing Aspect-Oriented Software”, In Proc. of the 10th IEEE International Workshop on Programming Comprehension, pp.251--260, 2002

本研究の目的 アスペクトを組み込んだプログラムに対する依存関係解析結果を用いた開発支援手法を提案する． 対象: AspectJ アスペクト干渉の検出 アスペクトを組み込む時点での支援 プログラムスライスの抽出 アスペクトを組み込んだ後のデバッグ支援 対象: AspectJ そこで，本研究では，アスペクトを組み込んだプログラムに対する，依存関係解析結果を用いた支援手法の提案を行います． アスペクトを組み込む際に発生する干渉の検出と，アスペクトを実際に組み込んだ後の依存関係解析によるデバッグ支援とを組み合わせて用います． 対象としては，最も使われている処理系であることから，AspectJを選びました．

アスペクト干渉とは アスペクトが他のアスペクトに影響を与える 単体では正しいアスペクトでも，正しい動作が阻害されることがある 以下は無限ループの例 Client Object Disk I/O Object ディスク I/O を ネットワーク I/O にマップする アスペクト Network I/O Object 　ではまず，アスペクト干渉について説明します．アスペクト干渉とは，アスペクトが他のアスペクトの動作に影響を与えることで，単体では正しいアスペクトでも，同時に使用すると正しい動作が阻害されることがあるという問題です． 　図として，無限ループの例を挙げています．二つのアスペクト，ひとつはディスクI/OをネットワークI/Oにマップするアスペクトで，もうひとつは，ディスクI/O以外のすべての呼び出しをディスクに記録するためのアスペクトです．前者はシステムの機能として，後者はデバッグ等に利用されるものです．それぞれ，単体では正しい動作をします． 　しかし，二つを同時に用いると次のように問題が生じます．Client Objectがデータをディスクへ書き出そうと送ったメッセージを，アスペクトがとらえて，ネットワークへ出力しようとします．ここで，ディスクI/O以外の呼び出しはディスクに記録しよう，とアスペクトが作動し，Disk I/Oオブジェクトへメッセージを送ります．このメッセージさえもネットワークI/Oへマップしようとしますから，この呼び出しもまたディスクに記録する対象となる，というようにループに陥ってしまいます． 　ここでは単純な例ですが，二つではなく三つ以上のアスペクト，また複数のオブジェクトを経由してアスペクトが動作するようになると，開発者が気付く可能性はほとんど期待できません． ディスク I/O 以外の呼び出しを ディスクに記録するアスペクト

アスペクト干渉に対する方針 アスペクトの干渉は必要な場合もある ディスク I/O を置き換えるアスペクトなど コンパイル時に干渉可能性を検出してユーザに通知，実行するかどうかはユーザの選択 　アスペクト干渉をどう扱うかですが，ここで重要な点は，アスペクトの干渉は必要な場合もある，ということです．もし他のアスペクトに干渉できないとなると，先ほどのディスクI/Oの置き換えアスペクトは，他のアスペクトが勝手にディスクにデータを書き出すことを止められません． 　そこで，コンパイル時に干渉の可能性を検出し，開発者へ通知を行います．アスペクトがどのように関連しあっているか，特に先ほどのような無限ループに陥る可能性を通知し，開発者が意図していない関連性が生じていないか確認する機会を提供することにします．

アスペクト干渉の検出 Aspect を含めた Call Graph の利用 ある地点でアスペクトが作動する＝アスペクトを呼び出している 頂点：クラス，アスペクトに含まれるメソッド（手続き）単位 辺：メソッドの呼び出し，アスペクトの呼び出し （呼び出し関係はソースコードから解析） ある地点でアスペクトが作動する＝アスペクトを呼び出している 「Call Graphでアスペクトの頂点に到達可能」ならば「アスペクトの影響を受ける」 　アスペクトの干渉を検出するために，アスペクトを含めたCall Graphを作成します． 　具体的には，クラスやアスペクトに含まれたメソッドを頂点として，辺としてメソッドの呼び出し，アスペクトの動作を取ります．ある地点でアスペクトが動作する，ということを，アスペクトに対する一種のメソッド呼び出しとみなします．Call Graph上で，ある頂点から呼び出し辺を辿ってアスペクトの頂点に到達可能であれば，その頂点はアスペクトの影響を受けていると考えることができます．

Call Graph 例 凡例 Aspect Class 無限ループ call このグラフでは，ここにループが存在しており，実行すると無限ループに陥ってしまう可能性を示しています． 　プログラムの規模が大きくなるに従ってグラフのサイズも大きくなっていきますので，実際に開発者に提示するには，このグラフを直接与えるのではなく，ループ部分に対するマーキングや警告メッセージの出力など，開発者により理解しやすい形式での出力を行うことになります．

プログラムスライシングの適用 プログラムスライシングとは プログラム解析手法のひとつ プログラマが注目する必要があるコードのみを抽出し，提示する技術 元々は手続き的プログラム用に開発され，オブジェクト指向プログラムに対して拡張されている プログラム実行時情報を用いてデバッグを支援 　さて，ここまでは，プログラムを実行する前の，情報の提示でした．Call Graphを用いることで，少なくとも無限ループに陥るような重大な干渉は除去されており，予期せぬアスペクトの動作もある程度開発者が除去していて，プログラムが正しい結果を出せるかどうかはともかく，実行できる，という状態になります． 　今度は，実行結果が正しくない場合，その原因を調べるための支援を行います．ここで，関連研究の紹介でも名前だけ出ましたが，プログラムスライシングと呼ばれるプログラム解析手法を利用します．プログラムスライシングは，プログラムの中に含まれるデータや制御の依存関係を解析し，開発者が注目する必要があるコードのみを抽出，提示するという手法です． 　元々は手続き的プログラムに対して提案されたものですが，オブジェクト指向プログラムに対しても既に拡張され，その有効性が確認されています．先ほど，Call Graph にアスペクトの動作を表す辺を追加したのと同様の発想で，プログラムスライシングをアスペクト指向に対しても拡張し，適用することができると考えています．関連研究として挙げていたものはソースコード情報のみを用いる手法でしたが，ここではプログラムの実行時の情報を使用し，デバッグ支援に的を絞ります．

プログラムスライスの定義 プログラムのある文sのある変数v（スライス基点<s,v>）の値に“影響”を与えうる文の集合 影響 = 代入--参照 関係， if 文など制御関係 プログラム文を頂点，依存関係を辺としたグラフの探索問題 1: a = 5; 2: b = a + a; 3: if (b > 0) { 4: c = a; 5: } 6: d = b; 1: a = 5; 2: b = a + a; 3: if (b > 0) { 4: c = a; 5: } 6: d = b; a a 基点< 6, b > b 制御 b 　プログラムスライスがどういうものか，例を示して説明します．プログラムスライスは，プログラム文の中のある変数に注目し，その変数の値に影響を与える文の集合のことを言います．ここで言う影響とは，変数の代入・参照関係，if文やwhile文などの制御関係のことです． 　ここにプログラムの断片を示していますが，１行目で代入された変数aが２行目で参照されているので，１行目から２行目に依存関係がある，ということになります．同様に，２行目での代入文から，３行目と６行目へ依存関係があります．また，４行目が実行されるかどうかは３行目の条件判定によって決定されることから， ３行目から４行目に依存関係がある，ということになります． 　ここで，６行目の変数 b に注目して，この変数に対するプログラムスライスを計算すると，右側に示したものになります．これは，プログラムの各文を頂点とし，依存関係を有効辺としたグラフにおいて，その依存辺を逆向きに辿っていく探索問題として考えることができます． 　求められたプログラムスライスを見ることで，開発者は，その値がどのように決まったかを知ることができます．たとえばデバッグ作業中，ある地点で変数の値がおかしくなっていることに気付いたとすると，その変数を基点にスライスを計算することで，無関係なコードをあらかじめ取り除くことができ，作業を効率的に進めることができます．

スライス計算に必要な情報 データ依存関係 制御依存関係 フィールド（メンバ変数）の 代入 → 参照 関係 ローカル変数の 代入 → 参照 関係 制御依存関係 実行制御文の条件節 → 制御される文 メソッド呼び出し文 → 呼び出されるメソッドの文 アスペクトが連動するタイミング → 動作するアスペクト 　プログラムスライスの計算を実現するためには，データと制御という二つの依存関係を解析することが必要です． 　データ依存関係というのは，変数それぞれについて，どこで代入された値がどこで使用される可能性があるか，ということを意味します． 　制御依存関係は　if や while などの実行制御文と制御される文，またメソッド呼び出しと呼び出されるメソッド，という関係を表現しています． 　アスペクト指向プログラムを取り扱うために，ここにアスペクトが起動される地点から実際に動作するアスペクトへ，という依存関係を追加します．Call Graphのときと同じ発想です．

情報収集： 動的 or 静的 目的をデバッグに限定 データ依存関係 制御依存関係 実行が失敗するテストケースが特定されている状態を想定 動的（実行時）情報 が利用可能 オブジェクトの区別，動的束縛の解決によってコード量を減らす データ依存関係 フィールド（メンバ変数）の 代入 → 参照 関係 ローカル変数の 代入 → 参照 関係 制御依存関係 実行制御文の条件節 → 制御される文 メソッド呼び出し文 → 呼び出されるメソッドの文 アスペクトが連動するメッセージ → 動作するアスペクト 　ここではさらに，必要な情報をどのように集めるか，という問題があります．選択肢は，ソースコードから静的に解析するか，プログラムを実際に実行して動的に収集するか，という二つです． 　デバッグを支援するという目的に限定すると，開発者が，実行結果が正しくないようなテストケースを特定して，実際にバグがどこにあるか探そうとしている状況が想定できます．ですから，そのテストケースを実際に実行した時の情報をできるだけ利用することが望ましいということになります．ただし，すべて実行時の情報から計算しようとすると，プログラムの実行系列というのは一般にソースコードに比べて非常に大きなものとなるので，現実的ではありません． 　実行時情報を用いるものを，スライドでは，赤字で示しています．フィールドの代入・参照ではオブジェクトの区別を，メソッド呼び出しについては動的束縛の解決を行います．特に動的束縛の解決は，「呼ばれる可能性はあるが実際には呼ばれなかったコード」をメソッド単位でスライスから除去するために重要です．また，アスペクトの動作についても，実際の順序がどうであったかということを重視するため，実行時情報を用います． 　ローカル変数や実行制御文は，厳密に観察するにはコストがかかりすぎることから，静的解析のみで対応します．

動的情報収集の実装 アスペクトとして動的解析処理を記述する １つのモジュールにカプセル化可能 実現および実行時コストの軽減 可読性・保守性の向上 実現および実行時コストの軽減 実用上十分な情報が収集可能 Java を対象とした場合は十分に有効† → AspectJ で書かれたプログラム用に拡張 　このような実行時情報の収集を実現するために，本研究では，その情報収集処理自体も，アスペクトを用いて記述します．先に述べたような，メソッド呼び出しなどに対応する処理は，アスペクトを用いて作成すると，実現に必要なコストが非常に安く済ませられるだけでなく，実行時のオーバーヘッドについても小さく済ませることができます．これについては，Javaを対象とした実験結果が既に得られていますので，これをAspectJ用に拡張するだけ，となっています． † 石尾隆, 楠本真二, 井上克郎: “アスペクト指向プログラミングの動的スライス計算への応用", 2002年電子情報通信学会総合大会講演論文集，D-3-4，p.30 (2002).

スライスツールの動作概要 スライス 計算 スライス結果 依存関係解析 アスペクト スライス対象 ソースコード （含アスペクト） AspectJ Compiler アスペクト結合済み クラスファイル 通常の JVM 依存関係情報 通常の実行結果 　ここで，実際のツールがどういう手順でスライスを計算するか，ということを説明します．最初にスライスをとりたいプログラムのソースコードと，依存関係解析のアスペクトを一緒に AspectJのコンパイラを用いてコンパイルします．コンパイラはアスペクトが結合されたクラスファイルを生成します．この結合結果は通常の Java バイトコードとなっているので，標準の JVM 上で実行することができます．依存関係解析アスペクトは，解析結果をファイルに出力します．得られた実行時情報と，ソースコードを解析して得られた静的依存関係から，最終的にスライスを計算・出力します。

スライスツールの実装 統合開発環境 Eclipse への統合 コンパイル時にソースコード情報を収集 Eclipse: オープンソースIDE フレームワーク プラグインでIDEの機能を追加できる 開発者がエディタ上でそのまま利用できることが重要 コンパイル時にソースコード情報を収集 静的依存情報の収集 Call Graphの作成 スライス計算時に，実行時に収集した情報があれば，それを適用 現時点では未実装 静的情報のみを用いたスライスが計算可能 　開発者から利用しやすくするという観点から，スライスツールを統合開発環境に組み込む形で実装を行っています．オープンソースのIDEフレームワークであるEclipseが持つ，プラグインによる拡張機構を利用しています．Java，AspectJを対象としたソースコード入力支援プラグインなどが既に提供されており，それにスライス計算機能を上乗せする形式になっています． 　プラグインは，コンパイルの実行開始，終了や失敗，ソースファイルの保存など，重要なイベントの通知をフレームワークから受け取ることができます．そこで，現在実装中のスライスツールでは，コンパイル終了時に静的な情報をすべて収集し，Call Graphを構築します． 実行時情報の収集については現在のところ未実装で，静的情報のみを用いたスライスが計算可能という状態です．

プロトタイプのスクリーンショット 3. スライス計算実行を指示 2. スライス基準をエディタ上で選択 4. スライス結果を エディタ上に出力 　ツールのスクリーンショットはこのようになっています． 　プログラムをコンパイルすると，静的な情報が収集され，スライス計算が可能な状態になります．スライス基準をエディタ上で範囲選択し，ツールバーからスライス計算を指示すると，結果がエディタ上に，ここでは青い波線として表示されています． 　実行時のコストとしては，コンパイル時の情報収集が主なものとなっています．アルゴリズムのオーダーに関する評価はしていませんが，基本的にはコンパイラが解析した結果のデータを用いて，構文木を１パス辿るというものになっているので，体感的に通常の作業時より遅くなるということはありません．また，スライス計算自体は完成したグラフを辿ってそれをエディタ上に出すだけなので，ストレスなく使用可能なものとなっています． コンパイル時に静的情報収集

まとめ アスペクト指向プログラミングの特徴 Call Graphを用いた干渉の検出 プログラムスライシングの適用 今後の課題 横断要素のモジュール化 保守性，再利用性の向上 ソースコードの見た目と動作とのギャップが拡大 Call Graphを用いた干渉の検出 アスペクトの動作を，メソッド呼び出しと等価とみなす ループ等，実行を不可能にするような重大な干渉の提示 プログラムスライシングの適用 従来手法に，「アスペクト呼び出し」を追加 実行時情報を用いた開発者の支援 今後の課題 ツールの有効性の評価 動的情報の付加によるプログラムスライスの変化の評価 最後にまとめます． 　アスペクト指向プログラミングの特徴は，横断要素のモジュール化にあります．複数のオブジェクトが関わる処理を単一のモジュールにまとめることで，保守性，再利用性を向上させることができます．しかし，ソースコードの見た目と実際の動作との間のギャップが拡大するという問題があります． 　これに対して，まずCall Graphを用いたアスペクト干渉の検出を行いました．アスペクトの動作をメソッド呼び出しと同様に考えて呼び出し関係をグラフ化し，無限ループの発生のような，実行を不可能にするような重大な干渉を検出し，開発者に提示します． 　また，実行した結果が正しくないと判明した際には，その原因の調査を支援するために，プログラムスライシングの適用を行います．プログラムスライシングは，依存関係を追跡して，開発者が調査すべきコードを抽出・提示する手法です．現時点ではソースコードの静的な情報しか用いていませんが，実行時情報を取り込むことで，デバッグ作業を支援することができると考えています． 　今後の課題としては，ツールが実際のソフトウェア開発効率に与える影響の評価，また静的情報だけを用いた場合と，動的情報も含めた場合とのプログラムスライスの有効性の違いなどを比較していきたいと考えています．

終

利用例:プログラムの実行時情報収集† オブジェクト指向プログラムの実行経過を観測する 抽出した情報の主な用途 メソッドの呼び出し関係 データの依存関係（代入-参照） 抽出した情報の主な用途 デバッグ支援 ソフトウェアの定量的評価（複雑さ，品質等） 次の例は，アスペクトの応用例で，プログラムの実行時情報の収集，つまりプログラムの実行経過を監視し，メソッドの呼び出し関係やデータの代入-参照関係などを解析する処理です． これは，解析した結果をデバッグ支援に用いたり，たとえばメソッド呼び出しの深さであるとか，ある処理に関与するデータ個数などに，ソフトウェアの複雑さや品質などを評価するための定量的な値を算出するために利用されます．

情報収集の従来の実現方法 「監視」処理は対象ソフトウェア全体に影響する Java を対象とした場合のその他の実現方法 単純な実装：対象ソフトウェアの各所でログを生成する → アスペクトでモジュール化するべき Java を対象とした場合のその他の実現方法 Java Virtual Machine (JVM)の改造 移植性がない，実現に必要なコストが高い JVMの持つ Profiler Interface の利用 実行時のコストが高い，バイトコード最適化で結果が変わる プリプロセッサによるソースコード変換 構文木の変換ルールが複雑，保守性が低い このような目的に対して，ソースコードからの情報収集は構文解析や意味解析を実行するだけでよいのですが，実行時の情報収集では，その実現方法が問題となってきます． プログラムの実行状態を監視する処理が必要となりますが，この監視処理そのものも，対象ソフトウェア全体に影響するものとなっています．単純な実装では，対象ソフトウェアの各所でログを生成するという形式ですが，これは，アスペクト指向において，アスペクトで実装すべき処理のひとつとなっています． 対象とするプログラム言語として Java を選んだ場合，他にも次の三つのような選択肢があります．Java の実行環境である Java Virtual Machine の改造，Java Virtual Machine が公開している Profiler Interface と呼ばれる性能計測インタフェースの利用，プリプロセッサによるソースコードの変換です． ひとつめの JVM の改造という方式は，改造元となる JVM のバージョンに依存してしまうこと，つまりバージョンアップに対応して毎回作り直す必要があること，実現に必要なコストが高いという問題があります． 二番目のProfiler interface の利用という方式は，元々性能計測用のインタフェースであるため，メモリの確保や解放，スレッドの利用などの粒度の細かい情報が得られますが，逆に，データ依存解析のようなフィールドの参照や代入，メソッドの呼び出しといった粗い粒度の情報を得ようとするには，オーバーヘッドが若干高めになってしまうこと，バイトコード最適化の影響で結果が変わってしまうことなど，いくつかの弱点が知られています． プリプロセッサによるソースコードの変換は，この三つの中では一番有望な選択肢ですが，構文木ベースでの変換ルールは記述の手間が多く，現状では再利用しにくい問題があります．アスペクトによる実装は，アスペクトを注意深く記述する必要はありますが，導入が容易で，実現に要するコストが小さいものとなっています．

アスペクトによる実装の利点 アスペクトとして動的解析処理を記述 １つのモジュールにカプセル化可能 実現および実行時に要するコストの軽減 可読性・保守性の向上 実現および実行時に要するコストの軽減 実用上十分な情報が収集可能 成果については論文投稿中† アスペクトによる実装の利点をまとめると，このようになります． まず，アスペクトとしてひとつのモジュールにカプセル化が可能となります．これは，可読性と保守性の向上をもたらします． 次に，実現に要するコストを低く抑えることができ，また，実行時に要するコストも，コンパイラの最適化などの恩恵を受けることができるため，抑えやすいものとなっています． また，オブジェクト指向プログラムに対して，アスペクトを付加して情報を収集することは既に実現しており，実用上十分な情報が収集できることが分かっています．これについては，成果を論文投稿中です． †: 石尾 隆，楠本 真二，井上 克郎: アスペクト指向プログラミングの 動的プログラムスライスへの応用，情報処理学会論文誌，投稿中

その他のアスペクトの利用例 アスペクトによるトランザクションの実現† GoF デザインパターンのアスペクトによる書き換え‡ 種々のトランザクションメカニズムを利用したトランザクションのモジュール化 GoF デザインパターンのアスペクトによる書き換え‡ デザインパターン＝オブジェクトの「連携のやりかた」のパターン 設計レベルでの再利用，使うときは個別のコードを書く パターンに関連するオブジェクトにコードは分散する いくつかのパターンは，単独のアスペクトに簡潔に記述することができる アスペクトとして再利用可能なコードになったパターンも存在 さて，他にも，いくつものアスペクトの利用が報告されています．たとえば，データベースなどに対するトランザクション処理や，オブジェクト指向でデザインパターンとして知られるオブジェクトの連携パターンをアスペクトで実装した例があります．特にデザインパターンのいくつかでは，オブジェクト指向による実現に比べて，分散したコードの局所化が達成されたものや，パターンを実装したコードの再利用可能性が達成されたものもあります．従来は，パターンはあくまでパターンであり，プログラマが個々の状況に合わせて実際のコードを書かなければならなかったのですが，それが再利用可能なモジュールとしての記述に成功した例も報告されています． † S. Soares, E. Laureano, P. Borba: `Implementing Distribution and Persistence Aspects with AspectJ'', OOPSLA 2002 ‡ J. Hannemann, G. Kiczales: ”Design Pattern Implementation in Java and AspectJ'‘, OOPSLA 2002