Vol. 45

情報処理学会論文誌

No. 6

June 2004

アスペクト指向プログラムのデバッグ支援環境– プログラムスライスとコールグラフの利用 –
石 尾

隆†

楠 本

真 二†

井 上 克 郎†アスペクト指向プログラミングは，複数のオブジェクトに関連した処理をオブジェクトから分離
し，新しいモジュール単位「アスペクト」として記述する．アスペクトは保守性や再利用性を向上させるが，同時に，プログラムに新たな複雑さを導入する．たとえば，アスペクトが相互に干渉して動作を阻害するなど，原因の特定が難しい欠陥が発生することがある．このような問題に対して，
本論文では，コールグラフとプログラムスライシングを用いたデバッグ支援を提案する．コールグ
ラフは，オブジェクトとアスペクトの制御関係を可視化することで，アスペクトによる無限ループの検出を支援する．また，プログラムスライシングは，プログラムの依存関係を解析することで 開発者が扱う必要があるコードを抽出する手法であり，アスペクトがプログラムに与える依存関係の変化をユーザに提示する．アスペクト指向言語 AspectJ を対象にツールの実装を行い，適用実験を行った．その結果，アスペクト指向プログラムにおいてアスペクトが与える影響を効果的に開発者に提示できることを示した．

Debugging Support Environment for Aspect-Oriented Program
Using Program Slicing and Call Graph
Takashi Ishio,† Shinji Kusumoto† and Katsuro Inoue †Aspect-Oriented Programming (AOP) introduces new software module named aspect for
encapsulating crosscutting concerns. Although a crosscutting concern is written as aspects
to improve maintainability and modularity, AOP introduces a new factor of complexity. For
example, ﬁnding defects caused by an aspect, which modiﬁes or prevents behavior of anotheraspect, needs much cost. In this paper, we examine a method to support such issues in developing aspect-oriented programs. We propose an application of call graph generation andprogram slicing to assist debugging. A call graph visualizes control dependencies between
objects and aspects and can detect inﬁnite loops. On the other hand, program slicing showschanges of dependencies to a user. We implement a program slicing tool for AspectJ and apply
it to certain programs. The experiment shows that our approach is eﬀective for a developer
in ﬁnding the inﬂuence of aspects in a program.

アスペクトは，アドバイスと呼ばれるプログラム中

1. ま え が きの特定の実行時点に連動して実行される処理の集合と

近年，プログラムの新しいモジュール化手法としてして記述される．実行時点とは，オブジェクト間でのアスペクト指向プログラミングが提案され，利用されメッセージの送受信等のイベントのことである．アド1)

るようになってきている ．従来のオブジェクト指向

バイスはクラスやメソッドの境界を越えて作用しうる

プログラミングにおいて，ロギングや同期処理のようため，横断要素をクラスから分離して記述することがな複数のクラスやメソッドが関わる処理のことを横断可能となる．横断要素のモジュール化は，再利用性お要素と呼ぶ．横断要素のコードはその処理に参加する

よび保守性の向上につながる．

すべてのクラスに分散するため，保守性を悪化させる

アスペクトの応用事例は数多く報告されている2)∼4) ．

要因となっている．アスペクト指向プログラミングは，

しかし，アスペクトの導入が，プログラムに新しい複横断要素を単一モジュールに記述するための新しい単雑さをもたらすことも知られている．アスペクトは，オ位「アスペクト」を導入する．

ブジェクトの外部からその振る舞いを変えることができる．そのため，開発者がオブジェクトの振る舞いを† 大阪大学 大学院情報科学研究科
Graduate School of Information Science and Technology, Osaka University

把握するには，オブジェクトに関連したアスペクトをすべて調べる必要がある．開発者の予期しない時点で
1522

Vol. 45

No. 6

アスペクト指向プログラムのデバッグ支援環境

1523

アスペクトが動作するといった，発見が困難な欠陥を担する都合上，担当するオブジェクトを１つに決めら作り込む可能性があることに加えて，アスペクトの干れないような特性はうまく扱えない．たとえばシステ

渉と呼ばれる，単体ではそれぞれ正しいアスペクトがムの動作を記録していくロギング，エラーが起こった

相互に動作を阻害するという問題も発生している5) ．

ときの例外処理，データベースなどにおけるトランザ

このような問題に対して，アスペクトの予期せぬ動クションの手続きは，システム内の複数のオブジェク

作の可能性や，アスペクトによって発生した障害の原トが連携して実現することが多い．このような処理は

因調査を支援する方法が必要である．

横断要素と呼ばれており，横断要素に関わる複数のク本研究では，アスペクト指向プログラムの開発を支ラスにコードが分散し，次のような事態を引き起こす．

援するために，コールグラフによる呼び出し関係の提• 横断要素に関係したクラスやメソッドの集合が変示と，プログラムスライシング技術6) を用いたデバッ

わると，すべての関連したコードをもれなく変更

グ支援を行う．コールグラフとは，メソッドを頂点としなければならない．

し，呼び出し関係を有向辺とするグラフである．これ• クラスやメソッドに，本来の機能と横断要素のコーにアドバイスの頂点と辺を加えて，予期せぬアスペク

ドが混在することにより，横断要素を含んだオブトの動作や，アスペクト間の相互依存による無限ルー

ジェクトの再利用性が低下する．クラスやメソッ

プ発生の可能性を提示する．これによって，開発者がプドを横断要素に関連したコードを除去して再利用

ログラムの実行制御に関連した欠陥を検出しやすくな

するか，あるいは，関連したオブジェクト群をまる．プログラムスライシングとは，プログラム内部のとめて再利用する必要がある．

依存関係を解析することで，開発者が注目すべきコー• 横断要素だけを独立して再利用することができなドを提示する技術である．アスペクト干渉が与える影い．もし別の場面で同じ種類の横断要素が必要で響を調べるためには，依存関係を解析し利用するプロ

あれば，その都度実装しなければならない．

グラムスライシング，特に実行時情報を用いた DC ス

これに対して，アスペクト指向プログラミングは，横ライス計算7) が有効であると期待できる．
統合開発環境 Eclipse8) をベースに，コールグラフ

断要素を分離・記述するためのモジュール単位「アスペクト」を導入する．

および DC スライスを計算するツールの実装を行い，AspectJ9) などのアスペクト指向プログラミング言

いくつかのアスペクト指向プログラムに対して適用実語では，オブジェクト指向プログラム内に含まれる実験を行った．その結果，プログラムスライシングがア

行時点 (join points) の中から，結合の基準となる集合

スペクト指向プログラミングのデバッグ支援に適して(pointcut) を選択し，手続きを関連付ける．関連付けられる手続きのことをアドバイス (advice) と呼ぶ．アいることを示した．
以降，2. ではアスペクト指向プログラミングの特徴と問題点について説明する．3. ではコールグラフを用

スペクトは，通常，１つ以上のアドバイスによって構成される．

いた，アスペクトを組み込む際の問題検出について説アドバイスが結合可能な実行時点は，言語処理系に明する．4. ではプログラムスライシングの概要とア

よって異なるが，次のようなものが使用されている．

スペクト指向プログラミングへの拡張について説明し，• オブジェクトに対するメソッド呼び出し．
• オブジェクトのメソッドの実行（動的束縛の解

5. でアスペクト指向プログラムに対するプログラムス
ライシングツールの実装と評価について説明する．最後に 6. でまとめと今後の課題を述べる．

2. アスペクト指向プログラミング

決後）．

• オブジェクトの持つフィールドへのアクセス．
• オブジェクトでの例外の発生．
このような実行時点に対して，アドバイスはその直2.1 アスペクト指向の特徴

前 (before)，直後 (after )，あるいは本来の処理を置きアスペクト指向プログラミングは，オブジェクト指換える (around ) 形式で動作する．言語処理系にもよ向プログラミングなど既存のモジュール機構を基に，そるが，このようなアドバイスは，その実行コンテキスの弱点を補うプログラミング手法である．たとえばオト（たとえば実行時点が何であるか，呼び出されよう

ブジェクト指向プログラミングでは，システムに必要としているオブジェクト，メソッド，引数といった）情な個々の機能をオブジェクトが分担し，それらが相互通報にアクセスし，適切な処理を実行することができる．

信し，協調することでシステムの目的を実現する．しAspectJ で 記 述 し た ア ス ペ ク ト の コ ー ド 例 をかし，オブジェクトという単位でシステムの機能を分

図 1 に示す．ここで定義している ParameterValida-

情報処理学会論文誌

1524

aspect ParameterValidationAspect {before(int x):args(x) && call(void *.doSomething(..)) {if ((x < 0)||(x > Constants.X_MAX_FOR_SOMETHING)) {throw new RuntimeException("invalid parameter!");}}}

図 1 AspectJ におけるパラメータ検査アスペクトの例
Fig. 1 A parameter checking aspect written in AspectJ.

June 2004

理解を行うが，読んでいるモジュールから参照しているモジュールなど，開発者から見えない部分でアスペクトから受けている影響には気づきにくい，ということが挙げられる14) ．
アスペクトの干渉は必要な場合もあるため，一概に禁止するというわけにはいかない．たとえば，先に登場した，引数の値の範囲をチェックするアスペクトは，
他のアスペクトからのメソッド呼び出しに対しても動tionAspect は，どのクラスであれ doSomething とい作しなければならない．これに対して，アスペクトがう名前のメソッドに対する呼び出しの直前に引数を検

他のアスペクトの振る舞いを破壊しないようにアスペ

査し，条件に違反した呼び出しに対して例外を発生さ

クトの種類を制限することで安全なアスペクトを記述せるアスペクトである．

する手法15) や，アスペクトの扱いを開発者が記述可能

2.2 アスペクトのもたらす複雑さとすることで干渉を回避する手法5) も研究されている．

アスペクトの用途については広く研究されている．

本研究では，アスペクトの干渉による動作不良の原

オブジェクト指向プログラミングで用いられているデ因を特定する作業を支援することを考える．アドバイ

ザインパターン10) は，複数のオブジェクトがどのようスの実行を，対応する実行時点でのメソッド呼び出しに連携するかを説明した設計部品である．これは，オに変換するというアイディアに基づいて，アスペクト

ブジェクトの横断要素の一種であると考えられるため，をプログラムに組み込む時点でのコールグラフを用いアスペクトとして記述することで，パターン自身が再た制御誤りの検出と，プログラムに組み込んだ後のプ

利用可能なソフトウェア部品となる場合があることがログラムスライシングを用いた欠陥特定の支援を提案

知られている3) ．また，ソフトウェア開発時のデバッ

する．

グ支援や，分散アプリケーションでのオブジェクトを

コールグラフは，(b) によるアスペクトの無限ルー横断した性質の記述など，様々な場面でその有用性がプの発生を検出するために使用する．プログラムスラ示されつつある2),4) ．しかし，アスペクトはプログラ

イシングは，特定の変数の値に注目して依存関係を解

ムに次のような新しい複雑さをもたらす．

析する．通常は，誤った出力値となった変数に注目し，(a) 同一の条件下で動作する複数のアスペクトが存(a) における同時に動作するアスペクトや，(c) におけ在しうる．アスペクトの動作順序によって，結果

る誤った動作条件がその変数の値に関わっていれば，そが異なる場合がある．

れらを検出し，問題の原因を追究する作業を支援する．

(b) あるアスペクトの動作中に，自分自身あるいは(a) については，アスペクトの動作順序が変化した場

他のアスペクトの動作条件が成立する場合がある．

合に問題が発生する可能性を検出するという方法も考

２つのアスペクトが相互に条件を満たすときは，えられるが，本研究では，実際に発生した問題の原因

無限ループを生じることもある．

を探す作業に注目した．また，(c) におけるプログラム(c) 動作条件の記述が必要十分であることを確認することが難しい．また，ソフトウェアを変更した際に，動作条件も変更が必要となる場合もある11) ．
これらのうち，(a) と (b) はアスペクトの干渉と呼の変更時に動作条件が変化する問題11) については対象外とした．

3. コールグラフによるアスペクト干渉の検出

ばれる問題である5) ．このような干渉を検出する，あアスペクト指向プログラミングでは，アスペクトがるいは予防するための研究が数多く成されている．ま実行される条件の誤りやアスペクト間の干渉によって，た，(c) はアスペクトが関係しているオブジェクトの情

本来動作するべきではない時点でアスペクトが動作す

報をどのように開発者に提示するかという問題である．

るといった故障が発生する．

これに対しては，統合開発環境による部分的なサポートが行われている

12),13)．

特に，アスペクトによって無限ループが生じやすい
ことが知られている9) ．実行することで無限ループにアスペクトの干渉や誤作動によって生じる障害の原

陥ってしまう可能性は，実行してから実際にループに因を見つけ出すことは難しい．この理由としては，通陥った状態をデバッガ等で検査するのではなく，プロ常，開発者はクラスやアスペクトのようなモジュール

グラムをコンパイルした段階で検出できることが望ま単位でプログラムを読んでいくことによって局所的なしい．そこで，プログラム実行前にソースコードに対Vol. 45

No. 6

アスペクト指向プログラムのデバッグ支援環境

1525

する静的な解析を行い，無限ループの発生可能性を調
public AnotherCounter()べる．
無限ループが発生する可能性を簡単に検出するもの

public Bar()public Foo()

public Main()public Counter()として，メソッドを頂点とし，メソッド間の呼び出し
関係を有向辺とするコールグラフ (Call Graph) があ

public Object()Main#main(String[])

る．グラフ内のある頂点 v から出発して v 自身に到Bar#before set(int Counter.f)

Main#getX()

PrintStream#println(int)

達可能な経路があるとき，無限ループの可能性がある，ということになる．

Foo#before call(public static int Main.getX(..))

コールグラフをアスペクト指向に対して拡張するた
AnotherCounter#incF()

めに，あるメソッド内部にアドバイスが連動する実行時点が含まれているとき，そのメソッドからアドバイスへの呼び出しがあると考え，アドバイスの頂点と動作辺を追加する．メソッド，アドバイスを頂点とし，メCounter#incF()

図 2 コールグラフ例
Fig. 2 A call graph.

ソッド呼び出し，アドバイスの起動を辺としたコールグラフを構築する．あるメソッド m の頂点 vm からア処法が考えられる．

ドバイス adv の頂点 vadv に到達可能であるとき，m

コールグラフの具体例を図 2 に示す．楕円形の頂点

は adv の実行に影響を与えている，と考える．あるア

はメソッド，矩形の頂点はアドバイスを示しており，内ドバイスが自分自身の影響を受けるとき，無限ループ

部にシグネチャを示している．このグラフでは，メソッに陥る可能性がある．

ド Main.getX に対応する頂点 からアスペクトを経由アドバイスの呼び出し順序は処理系依存であることから，呼び出しの順序に関する組み合わせの判定が必したループが存在していることから，無限ループに陥る可能性を知ることができる．

要となる．ここで，before および after アドバイスに

コールグラフは，プログラムのサイズに比例して巨

ついては，実行順序が変化しても呼び出し関係そのも大化していくことから，ツールの実装においては，どのは変化しないため，無視できる．around アドバイスのように提示するかも重要な問題となる．本研究で実が複数存在する場合には，その順序が呼び出し関係に装したツールでは，ループが発見された時点でユーザ影響を与えるが，around アドバイスの個数によってに通知を行うと同時に，ループに含まれる頂点と，そのは組み合わせ爆発を起こす可能性がある．本研究では，頂点から隣接している頂点（辺の向きに関係なく，高々複数の around が同一のメソッドに追加された場合に１回辺をたどって到達可能な頂点）だけをグラフからは，処理系依存の順序（AspectJ Project で開発され抽出して提示する方法を選択した．

ているコンパイラ16) が用いる順序）による扱いを行う
ことで，この問題を回避するものとした．

コールグラフを用いて，開発者はアスペクト間の制
御関係が意図したものであるかどうか確認し，無限ルー

コールグラフの構築においては，オブジェクト指向

プの可能性を除去することができる．コールグラフをプログラミング言語の場合と同様，アスペクト指向プ用いた手法以外には，他のアスペクトの干渉検出法とログラミング言語の実行時決定要素の扱いが問題となして，形式的仕様記述を用いる手法などが考えられる

る．AspectJ では，動的に判定される pointcut としが，それらに比べて実装が容易であり，開発者にとって制御フローに関する条件を指定する cflow，条件式て直観的な情報が提示できる点が特徴である．

を記述する if などがある．このうち，cflow につい

アスペクトの動作順序や相互依存関係を開発者が細てはコールグラフ上の到達可能性を調べることで，到かく指定することができる処理系5) や，そもそも干渉達しないものを取り除くことは可能である17) ．しかし，を起こさないような限定された種類のアスペクトの利

それでも解決できない場合や，if による判定，フラグ

用15) も研究されている．そのような場合でも，コール変数による無限ループの回避を行っているようなコーグラフを用いて依存関係を表示することで，予期せぬドは認識できず，無限ループとして判定してしまう．まアスペクト間の依存関係の存在を開発者が確認できる

た，故意の再帰呼び出しに対しても同様である．このことは有益である．

問題に対しては，特定の回避コードを使用していることを開発者側が XDoclet18) などのメタデータを用いて宣言することで故意のループを検知するといった対

4. プログラムスライシングプログラムスライシングは，プログラムに含まれる

1526

情報処理学会論文誌

June 2004

変数の参照・代入関係，実行制御文による制御関係，手め，プログラム理解や検証に用いられる6) ．動的スライ

続き呼び出し関係などの依存関係を解析し，プログラ

スはある特定の入力に対する実行系列上で依存関係をム内の注目すべき部分だけを抽出，提示する技術であ解析し，実際に依存関係が発生したコードだけを抽出す

る6) ．具体的には，ある文のある変数を入力として，そるため，デバッグ等に利用される19) ．しかし，実行系の変数の値に影響を与える文の集合を取り出す．入力

列を完全に保存する必要があるため，必要なコストは非として与えるコード内の変数の参照位置をスライス基常に高い．それらの中間的な Dependence-Cache(DC)点と呼び，抽出されたプログラム文の集合をプログラ

スライスは，実行系列を保存せずにデータ依存関係だ

ムスライス，あるいは単にスライスと呼ぶ．

けを動的に取得することで，実用的なコストで特定の4.1 スライス計算のアルゴリズム
プログラムスライシングは，次の３つのフェイズからなる．

(1) プログラムからの依存関係の抽出(2) プログラム依存グラフの構築(3) グラフ探索によるスライスの抽出

実行系列に関する情報を取得できる7) ．

4.2 アスペクト指向プログラムに対するスライス
計算の適用
アスペクト指向プログラムに対してプログラムスラ
イシングを適用し，デバッグ支援を行う．デバッグ作業において，開発者は，まずコールグラフを用いて無フェイズ (1) では，データ依存関係，制御依存関係の限ループの可能性を除去し，デバッグ対象のプログラ

２つの依存関係を解析する．データ依存関係とは，変ムの実行は少なくとも終了する状態とする．次に，プ数の代入と参照の関係である．プログラム中の２つのログラムに対しテストケースを与えて実行する．この

文 s, t について以下の条件がすべて成り立つとき，s か時得られた結果が不正であった場合に，その原因を調ら t に対して変数 v に関するデータ依存関係が存在す査するためにプログラムスライシングを用いる．

ると言う．

デバッグに用途を絞ると，どのようにしてその出力• 文 s で変数 v に値を代入している．
• 文 t で変数 v の値を参照している．
• 文 s から t に到達可能な制御フローがある．
• 文 s から t に到達する制御フローのうち，途中で値が出たか，という実際の経過に注目し，プログラム

変数 v への代入文がないような経路が少なくとも起こりうるアドバイスの実行順序をすべて調べる必要１つ存在する．

がある．これは，デバッグ作業を支援する用途には不スライスのサイズを小さく抑えることが重要となる．
単一の実行時点で複数のアドバイスが動作する場合の実行順序は処理系に依存するため，静的スライスでは，また，制御依存関係とは，実行制御文と制御される向きであると考えられる．そこで，本研究では，スラ文の関係である．プログラム中の文 s, t について，以イス計算手法として，実行時情報を用いる DC スライ

下の条件がすべて成り立つとき，s から t への制御依スを採用した．

存関係が存在すると言う．

• s が条件節である．
• t が実行されるかどうかが，s の判定結果によって決まる．
フェイズ (2) で，これらの依存関係と，手続き・メソッ
ドの呼び出し関係を用いて，プログラム文を頂点，依存

実行結果が不正となるテストケースを実行し，その実行経過を観測して得られた情報を基にプログラム依
存グラフの構築とスライス計算を行い，開発者にフィードバックを行う．開発者は，スライスに含まれたプロ
グラム部分だけを調べればよいので，欠陥の原因を特定する作業を軽減することができる．

関係を有向辺としたグラフを作成する．このグラフをプ

現在，オブジェクト指向言語 Java に対するプログ

ログラム依存グラフ（Program Dependence Graph，

ラムスライシングが既に実現されているが，アスペク

以下 PDG) と呼ぶ．フェイズ (3) では，PDG 上でス

ト指向プログラムに対する適用は基本的な手段の提案

ライス基点となる頂点を選び，有向辺を逆向きに探索にとどまっており，実装や評価は行われていない20) ．

していくことで，スライス基点となった変数に影響を本研究では，対象とするアスペクト指向言語として与える文を抽出していく．得られた頂点集合をエディ

AspectJ を選択し，Java に対するプログラムスライ

タなどに表示されたソースコード上へ反映し，プログ

シングを次のように拡張する．基本的なアイディアは，

ラマへ情報を提供する．

アドバイスの処理を，対応する実行時点でのメソッド

プログラムスライシングの性能は，その依存関係の抽出方法によって決まる．ソースコードから依存関係を取得する静的スライスは，すべての可能性を抽出するた呼び出しに変換するというものである．
データ依存関係

アドバイスは，その実行時点のコン

テキスト情報にアクセスすることができる．このVol. 45

アスペクト指向プログラムのデバッグ支援環境

No. 6

before() : call(Foo.foo());
call
before() :execution(Foo.foo());

call
call
Foo.foo();Foo.foo() bodyがスライスに含まれるときは結合基準もスライスに含まれるようにする．
アドバイスの呼び出し関係 アドバイスは，その実行時点の頂点に到達しない限りは実行されないため，

return value
call

1527

after() :execution(Foo.foo());

call

その実行時点によって制御されていると考える．
そこで，実行時点に対応する頂点を，アドバイス

after() : call(Foo.foo());

図 3 メソッド呼び出し頂点におけるアドバイス呼び出し
Fig. 3 Before advice call and after advice call at method
call node.

への呼び出し頂点として考える．図 3 に，メソッ
ド呼び出し頂点における手続き呼び出しの関係を示す．
動的な結合基準

アドバイスが実行されるかどうか，

特定のメソッドからの制御フローや変数の値など，
実行時の情報によって決定される場合がある．プ
around() : call(Foo.foo());
call

ログラムスライスの計算では，これらの実行時情

return value

報の条件以外で指定される「実行される可能性がadvice bodyある」すべての実行時点に，そのアドバイスが実
call

return value

行されるかどうかの判定文があると考え，各実行
Foo.foo() body

図4

メソッド呼び出し頂点における around アドバイスの呼び出しFig. 4 Around advice call at method call node.

時点からのアドバイス呼び出しを設定する．また，それらの実行時点に対して，条件判定に使われるデータの依存情報の設定も行う．制御フローに関しては，静的解析を行うことで実行される可能性

データは，本来の実行時点の頂点から，メソッド呼を絞り込み，結合基準をより正確に指定すること

び出しの引数としてデータが渡されているものとしができる17) が，それは今後の課題とする．

て考える．AspectJ では，アドバイス内で，そのアドバイスが動作する実行時点を表現した thisJoin-

実行時点の置き換え

AspectJ における around アド

バイスは，実行時点を完全に置き換える．そこで，Point オブジェクトを用いて，その時点でのメソッ実行時点に around アドバイスが関連付けられたドの名前や引数情報などを取得するリフレクショ

場合は，図 4 のように，その実行時点に対応するン機能が利用できる．これは，汎用的なアスペク

頂点を取り除き，代わりに around アドバイスへ

9)

トを記述するために使用される ．実行時情報をの呼び出し頂点を追加する．

用いて実際の動作を解析する方法21) も存在する

4.3 プログラム実行時情報の解析が，その適用は将来の課題とし，本研究では，次DC スライスでは，プログラムの実行時情報が必要のように，部分的な解決を行っている．

となる．ここで言う実行時情報とは，動的データ依存• メソッド名，ソースコードの位置情報のよう関係，メソッドの動的束縛情報である．このような実行に，取得に引数が不要なものは，先に書いた

時情報を収集する処理は，それ自体が横断要素の１つ

ように，本来の実行時点の位置からのデータであると考えられるため，アスペクトとしてモジュー依存関係とみなす．

ルを記述し対象プログラムに組み込む．我々は既に実• メ ソッド の 第 N 引 数 の 情 報 を 取 得 す る
getArgs(N) のように，引数に応じて参照さ

行時情報収集アスペクトを，Java を対象として実現しれる値が異なるものについては，「引数の列」

AspectJ ではローカル変数の監視はできないので，という単一の存在として取り扱うものとした．

この方法で計算されたスライスはメソッド内部の依存ている2) ．

このため，getArgs を使用している文は，メ関係を静的に計算し，メソッド間の依存関係を DC ス

ソッドの引数すべてを参照したのと同様の扱

ライスを用いて計算したものとなる．その結果，静的いとなる．結果として，プログラムスライス

スライスよりも小さく，完全な DC スライスに比べる

は冗長な文を含む可能性が生じる．

と冗長なプログラム文が含まれる場合がある．しかし，アドバイスの結合基準

アドバイスは，その結合基準

実行時のオブジェクトの個々のインスタンスの識別と，と関連付けられている．そこで，アドバイスは，結フィールドのデータ依存関係を取り出すだけでも，静合基準からの依存関係を持つと考え，アドバイス

的なプログラムスライスに比べると十分に有効な結果

1528

情報処理学会論文誌であることは Java を対象としたプログラムスライシングの実現で既に示されており2) ，この手法を AspectJに対して拡張して利用する．このアスペクトを加えた際の干渉の発生については，コールグラフを用いた制御エラーの検出と，AspectJ でのアスペクト間の動作
優先度の定義を用いて対処する．

June 2004
表 1 適用対象
Table 1 Target codes.
名称
ChainOfResponsibility
ObserverSingleton
Mediator
Strategy

サイズ (LOC)
517
667
375
401
465

5. 実装と評価
5.1 実装の概要

換後の言語上での解析結果を変換前の言語に還元でき

デバッグ作業は，コードを書き換え，テストケース

るように，変換の前後での言語要素の対応付けを保存

を再実行するという反復作業として考えられる．このする必要がある．AspectJ における pointcut 記述はような反復テストをサポートする統合開発環境も多く，

Java に変換された場合，言語要素として直接的に表現プログラムスライシングのような支援ツールも，それされなくなるといった問題が起きるため，言語要素のらと連携して利用可能であることが望ましい．本研究対応付けは難しいと考え，AspectJ の言語要素を直接では，統合開発環境として Eclipse8) を選択し，これ解釈する実装とした．

に統合する形式でツールの実装を行った．

5.2 適 用 実 験Eclipse はオープンソースの統合開発環境で，Java

作成したツールの効果を評価するために，２つの実で記述したプラグインを追加することでエディタやコ験を行った．まず最初に，作成したツールを，Java おンパイラの機能を拡張することができる．Java および

よび AspectJ を用いたデザインパターンの実装例とAspectJ を対象としたソースコード入力支援等のプラ

してインターネット上で公開されているコード23) にグインが既に開発されているため，それらを利用して対して適用した．ここでは，デザインパターンのうち，スライス計算機能を実装した．ソースコードの規模は

表 1 に示すような，アスペクトとして記述することが約 5000 行となった．

効果的とされている 5 種類のパターン3) の実装を用い

Eclipse のプラグインでは，ファイルの保存やコンた．実装例をそれぞれコンパイルして実行し，スライパイルの終了など，重要なイベントに応じて動作する

ス計算を行った．以降，5.3. ではスライス結果についアクションを定義することができる．そこで，コンパて，5.4. では計算コストについて述べる．次に，スライル時に静的な依存関係の抽出，コールグラフの構築

イスのデバッグ支援に対する効果についての評価を行を行うものとした．コールグラフ内部にループなどがうために，学生の演習課題において，資料としてプロ検出された場合には，それをメッセージとしてユーザ

グラムスライスを使用する実験を行った．この実験にに通知を行い，検出されたループに含まれる頂点と，関する詳細と結果については，5.5. で説明する．

その頂点から隣接している頂点（辺の向きに関係なく，

5.3 スライス結果の評価

高々１回辺をたどって到達可能な頂点）だけを抽出しデザインパターンを用いたプログラムは，それぞれたグラフを生成するようにした．また，エディタ上で動作の経過を表現するようなテキストを出力するようソースコードの選択を行い，その部分をスライス基点に実装されていた．そこで，それら出力用の変数を基としてスライス計算を実行できるようにした．

点にプログラムスライスの計算を行った．

本研究で開発したツールは，AspectJ 用の開発環境

たとえば Observer パターンでは，監視対象となるである AspectJ Development Tools (AJDT) プラグ

オブジェクト（Subject）に対して発行された値を変化

イン13) に含まれた構文解析，意味解析，エディタ等をさせる命令に対して，監視オブジェクト（Observer）

利用して，コールグラフおよびプログラム依存グラフが動作し，変化を検知したことを伝えるオブジェクトの構築，プログラムスライスの提示を行う．AspectJが動作する．この最後に実際の出力を行う文字列変数

は最終的に Java プログラムとして実行されることにをスライス基点とした．ツールによって得られたスラなるため，たとえば Java バイトコードを対象としたイス結果と同様の結果を手作業で得るためには，Observer パターンでは，実際の出力を行うメソッドから，

プログラムスライシング手法22) を適用することも可能である．このようなプログラム変換の結果に対するObserver，アスペクト，Subject，Subject に値を渡す

解析を行う場合，既存の様々な手法やツールが使える

オブジェクトという順序で制御依存関係を追跡し，そという利点がある．しかし，変換を行う場合には，変の後，制御フローに基づいてデータ依存関係が追跡すVol. 45

No. 6

アスペクト指向プログラムのデバッグ支援環境

表 2 動的解析処理の実行時間 (単位: 秒)
Table 2 Time cost of dynamic analysis (seconds).

class Sample {private int aField;
public int foo() {int x = bar();
... }

1529

activate

protected int bar() { // never executed
return 0; }private int baz() {return aField; }対象
ChainOfResponsibility
ObserverMediator
Singleton
Strategy

通常実行
3.76
0.32
3.21
0.14
0.18

動的解析付き実行
3.93
0.37
5.69
0.32
0.22

}
call
aspect redirectMethodCall {int around(Sample sample):this(sample) && call(int Sample.bar()) {return sample.baz(); }}図 5 の例では１行分の違いしかないが，実際にはこのクラスを継承したクラス，メソッド内で使用されている他のクラス，関連するアスペクトなどへと，誤認の影響が波及していく可能性がある．このような，アス

図 5 メソッド置換アスペクトのスライス結果
Fig. 5 A slice including an aspect which replaces amethod call.

ペクトによって変化した振る舞い，依存関係を指摘できることが，プログラムスライシングの大きな利点である．

る必要があった．
他のパターンにおいても同様に，複数のファイルに5.4 実行コストの評価
スライス計算の実行プロセスにおいて，実行コスト

分散して定義されたクラスやアスペクトの定義を順次

は以下の場面で影響を与える．

追跡する必要があった．プログラムスライシングを用コンパイル時いることで，必要な箇所がまとめて提示されるようになり，作業効率は向上したと考えられる．
このようなメソッドの制御関係を追跡する場合，ク

静的情報収集のために計算コストとメモリを必要とする．
動的情報解析時

動的情報収集モジュールを付加する

ため，通常の実行に比べて計算コストとメモリをロスリファレンス計算ツールは大きな助けとなる．今必要とする．

回の実験規模ではメソッド数，クラス数が少ないため

スライス計算実行時

スライス計算は，構築されたグに使用しなかったが，クロスリファレンスによって，実ラフの探索問題である．頂点数と辺数の和に比例行されるメソッドやアドバイスの候補が多数得られるした時間で終了する24) ．

ような状態ではそれらの候補がプログラムスライスにコンパイル終了時に行う静的解析は，AspectJ コン

含まれているかどうかという情報で候補を絞る，ある

パイラが意味解析なども含めて構築したモデル情報にいはプログラムスライスの中で使われているメソッド

アクセスできるため，構文木を１回トラバースして情をたどるためにクロスリファレンスを使う，といった報を収集する．そのため，プログラム依存グラフ構築

連携が作業の効率化に重要であると考えられる．

に必要な計算量の厳密な評価ではないが，トラバース

また，プログラムスライスは，次のような場合に有処理そのものは構文木のサイズに比例している．

効である．図 5 は，あるメソッド呼び出しを別のメソッ

動的情報解析時には，プログラムの実行経過を観測

ド呼び出しに置き換えるアスペクトを含んだプログラ

し，そこから動的依存関係を抽出するコストが必要とムに対するスライス結果である．このようなメソッドなる．この処理に要した時間コストについては，通常

置き換えアスペクトは，単体テスト時の便宜的な実装

実行との比較する形で表 2 に示しているが，実用的なの変更や，未実装部分の補完などに使用される．この範囲に収まっている．この種の動的解析は，大規模なようなアドバイスの存在による依存関係の変化を認識

テストケースになると莫大な情報を生成する可能性がすることは難しい．これは，クラスとアスペクトの定あり25) ，解析結果を保存するために必要な時間が大き

義位置が離れているためである．これに対するサポーなオーバーヘッドとなる．テストケースの規模としてトとしては，統合開発環境において，アドバイスがどのどの程度までが実用な範囲であるかについては，実験プログラム文に対して動作するかエディタにマークをなどを用いた検討が必要であると考えられる．

表示して知らせるためのツールが存在している13) ．しまた，メモリ消費量に関しては，主にプログラムのかし，アドバイスが動作することを知らせることはで規模によって影響を受けるが，アスペクトの種類によっ

きるが，そのアドバイスが動作したことによって本来ても大きく異なる．たとえば，デザインパターンを実の処理が実行されなくなることを示すことはできない．

装したアスペクトを含んだ約 10000 行のコードに必要1530

情報処理学会論文誌

June 2004

な解析コストは約 20MB だったが，このプログラムのすべてのメソッド呼び出しと実行，フィールドのアクセスに対して動作する，実行時情報収集アスペクトを加えたところ，１割に相当する約 1000 行程度のアス

Table 3

表 3 作業に要した平均時間 (単位: 分)Time required to debugging task (minutes).

グループ
1. スライスなし
2. スライスあり

課題１
150
200

課題２
186
210

課題３
200
190

ペクトであったにも関わらず，動作箇所はメソッド呼び出しに連動するアドバイスだけでも 1000 箇所以上処理を行うように記述されているため，再評価アスペに及ぶため，解析に必要なメモリは５倍の約 100MB

クトによって節点の評価が省略されると，文字列表現に増加し，単純な比例関係とはならなかった．このよの構築処理も飛ばされてしまい，正しい結果が出力さ

うな解析コストの問題は，AspectJ コンパイラの開発れない．

者らによって指摘されている9) もので，スケーラビリ

学生に与えた課題は，このプログラムが正しく出力

ティの実現への課題となっている．

すべき結果を参考にプログラムのバグを修正するとい

5.5 デバッグ支援への効果

うものである．学生には，プログラムが出力すべき結プログラムスライスの情報がデバッグ作業に与える

果と，それぞれのアスペクトの役割について簡単に説影響を評価するために，大学院の授業において，学生明した資料を渡した．また，学生の半分にあたる６名の演習課題の資料としてプログラムスライスを使用すを無作為に抽出し，追加の資料として，プログラムのる実験を行った．

結果出力を行う変数を基点として計算したプログラム

この実験に参加した学生は全部で 12 名で，全員がスライスの情報を印刷したものを与えた．このプログ

コンピュータサイエンスを専攻している．学生は Java

ラムスライスには，文字列構築アスペクトの最終結果

プログラミングについては学部の授業などでの使用経の変数に，再評価防止アスペクトが何らかの形で依存験があり，それまで AspectJ を用いたプログラミン

関係を持っていること，そして残る２つのアスペクト

グの経験はなかった．そこで，実験は次のような３つはまったく関与していないことが示されている．

の演習課題として実施した．まず，Java の開発環境と演習では，学生は，バグの原因，修正したコード，作して Eclipse の説明を行い，課題１として，小規模な業に要した時間を提出した．また，プログラムスライ

Java プログラムに対するデバッグの演習を行った．次スを用いた学生に対しては，その情報が役立ったかどに，アスペクト指向プログラミングに関する解説を行うか，利用した結果の感想についても提出した．以降，

い，課題２として，簡単なアスペクトを記述する演習得られた提出物を分析した結果について説明する．

を行った．最後に，課題３として，アスペクト指向プ
ログラムのデバッグ課題を与え，演習を行った．

学生が，３つの課題に要した時間の平均値を表 3 に示す．この実験では，プログラムスライスを用いた学

課題３に用いたプログラムは，AspectJ で記述され生のグループはプログラムスライスを用いなかったグ

た小規模なプログラムである．プログラムは，加算とループよりも良い結果を残したが，スライスを用いた乗算を行う計算式をグラフ構造で表現したオブジェク

グループと用いなかったグループとの間で，平均作業

トを用いて計算を行うというもので，プログラムには時間については統計的に有意な差は生じなかった．

次の４つのアスペクトが含まれている．

プログラムスライスを使用した学生の意見によると，• 節点が評価された際に，その節点の計算式の文字プログラムスライスは，デバッグ作業を開始したとき

列表現を構築し，結果を出力するアスペクト．

の作業の指針となり，バグの原因を追跡する際には，無• グラフに循環があった場合に，計算途中でそれを関係なアスペクトを調査の対象から除外するために役検出するアスペクト．

• 共有節点があった場合に，その節点の再評価を防止するアスペクト．

立つ．また，プログラムスライスとして依存関係のあるコードが明確に提示されることによって，アスペク
ト干渉の持っている複雑さのひとつである，開発者か• 節点を次の計算に再利用するために，計算が終了

ら見えないプログラム部分でアスペクトによる影響をした節点からグラフの接続を解除するアスペクト．

受けている可能性14) を開発者が考慮せずに済んだ．以

課題の作成は，複数のアスペクトが干渉したことに上が，プログラムスライシングの利点である．

よって発生するデータ誤りを検出する作業を設定する，

その一方で，実際にプログラムを修正する段階ではという方針で行った．上記のアスペクトのうち，再評価

他のアスペクトへ影響を及ぼさないかどうか調べる必を防止するアスペクトは，節点の評価を省略する．文要があり，結局他のアスペクトなども読む必要があっ字列表現を構築するアスペクトは，計算式の評価時にた．このことから，影響波及解析など，バグを特定しVol. 45

アスペクト指向プログラムのデバッグ支援環境

No. 6

た後の修正作業を支援するような他の手法と組み合わせることでデバッグ作業効率を向上させることが重要であると考えられる．

6. む す び
本研究では，アスペクト指向プログラムに対してプ
ログラムスライシングを適用し，デバッグ支援を行う
ための開発環境の実装を行った．
アスペクトの起動をメソッド呼び出しの一種とみなすことでコールグラフを構築し，無限ループの可能性を検出することを提案した．また，部分的に実行時情報を用いる DC スライス手法を，同様の発想で拡張した．
コールグラフ構築および DC スライス計算ツールを統合開発環境 Eclipse へのプラグインの形式で実装し，評価実験を行った．その結果，プログラマが誤解しやすいアスペクトの依存関係などを効果的に提示でき，バグを特定する作業を支援できることを確認した．プロ
グラムスライシングは，プログラムの誤った結果に対してどのアスペクトが関係しているかを開発者に提示することができ，開発者から見えないプログラム部分
でアスペクトによる影響を受けている可能性14) を開発者が考慮せずに済む．デバッグ支援においては，変更に伴うアスペクトの動作条件の変化11) への対処もまた重要であるが，本手法では対応していない．
今後は，プログラムの変更に伴うアスペクトの動作
条件への影響波及解析などを用いたプログラム修正作
業支援について調査する予定である．また，制御フロー
に関する静的解析を用いてアスペクトが動作する可能性をより正確に絞り込む手法17) ，実行時情報を用いる
ことでリフレクションの解析を行う手法21) を適用する
ことで，スライスの正確性を向上することを計画している．また，大規模なプログラム，多数のアスペクトを扱うためのスケーラビリティの改善を今後の課題と
する．

参 考

文 献

1) Kiczales, G., Lamping, J., Mendhekar, A.,
Maeda, C., Lopes, C.V., Loingtier, J. and Irwin, J.: Aspect Oriented Programming, Proceedings of ECOOP97, vol.1241 of LNCS,
pp.220-242 (1997).
2) 石尾 隆, 楠本 真二, 井上 克郎: アスペクト指向プ
ログラミングのプログラムスライス計算への応用,
情報処理学会論文誌, Vol.44, No.7, pp.1709-1719(2003).
3) Hannemann, J. and Kiczales, G.: Design Pat-

1531

tern Implementation in Java and AspectJ, Proceedings of OOPSLA 2002, pp.161-173 (2002)
4) Soares, S., Laureano, E. and Borba, P.: Implementing Distribution and Persistence Aspects
with AspectJ, Proceedings of OOPSLA 2002,
pp.174-190 (2002)
5) Pawlak, R., Seinturier, L., Duchien, L.
and Florin, G.: JAC: A Flexible Solution
for Aspect-Oriented Programming in Java,
Proceedings of REFLECTION 2001, pp.1-24(2001)
6) Weiser, M.: Program slicing. IEEE Transactions on Software Engineering, SE-10(4):pp.352-357 (1984).
7) Ohata, F., Hirose, K., Fujii, M. and Inoue,
K.: A Slicing Method for Object-Oriented Programs Using Lightweight Dynamic Information. Proceedings of APSEC2001, pp.273-280(2001).
8) Eclipse Project. http://www.eclipse.org/
9) AspectJ Team: The AspectJ Programming
Guide.
http://dev.eclipse.org/viewcvs/indextech.cgi/
˜checkout˜/aspectj-home/doc/progguide/10) Gamma, E., Helm, R., Johnson, R. andVlissides, J. : Design Patterns: Elements of
Reusable Object-Oriented Software. Addison
Wesley (1995).
11) Hanenberg, S., Oberschulte, C. and Unland,
R.: Refactoring of Aspect-Oriented Software.
Proceedings of Net.ObjectDays 2003, pp.19-35(2003).
12) Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W. G.: An
Overview of AspectJ. Proceedings of ECOOP
2001, vol.2072 of LNCS, pp.327-353 (2001).
13) AspectJ Team: AspectJ Development Environment. http://www.eclipse.org/ajdt/
14) Störzer, M. and Krinke, J.: Interference Analysis for ApsectJ. Proceedings of Workshop
FOAL, held in conjunction with AOSD 2003,
pp.35-44, (2003).
15) 一杉裕志，田中哲，渡部卓雄: 拡張ルール：安全に結合可能なアスペクトの記述ルール，日本ソフト
ウェア科学会，第５回プログラミングおよびプロ
グラミング言語ワークショップ (PPL 2003), pp.

58-73 (2003).
16) AspectJ Team: AspectJ project.
http://www.eclipse.org/aspectj/17) Sereni, D. and de Moor, O.: Static Analysis of
Aspects. Proceedings of AOSD2003 , pp.30-39(2003)
18) XDoclet Project. http://xdoclet.sourceforge.net/
19) Agrawal, H. and Horgan, J.: Dynamic Pro-

情報処理学会論文誌

1532

gram Slicing. SIGPLAN Notices, Vol.25, No.6,
pp.246-256 (1990).
20) Zhao, J.: Slicing Aspect-Oriented Software,
Proceedings of IWPC2002 , pp.251-260 (2002).
21) Gschwind, T., Oberleitner, J. and Pinzger M.:
Using Run-Time Data for Program Comprehension. Proceedings of IWPC 2003, pp.245250 (2003).
22) Umemori, F., Konda, K., Yokomori, R. andInoue, K.: Design and Implementation of
Bytecode-based Java Slicing System. Proceedings of SCAM 2003, pp.108-117, (2003).
23) Hannemann, J.: Aspect-Oriented Design Pattern Implementations.
http://www.cs.ubc.ca/˜jan/AODPs/
24) Preiss, B. R.: Data Structures and Algorithms
with Object Oriented Design Patterns in C++.
John Wiley & Sons, Inc., New Jersey (1999).
25) Reiss, S. P. and Renieris, M.: Encoding Program Executions. Proceedings of ICSE 2001,
pp.221-230, (2001).
(平成 2003 年 9 月 22 日受付)
(平成 2004 年 4 月 5 日採録)

June 2004

楠本 真二（正会員）
昭和 63 年大阪大学基礎工学部情報工学科卒業．平成 3 年同大学大学
院博士課程中退．同年同大学基礎工学部情報工学科助手．平成 8 年同大学講師．平成 11 年同大学助教授．平成 14 年大阪大学大学院情報科学研究科コンピュータ
サイエンス専攻助教授．博士（工学）．ソフトウェアの生産性や品質の定量的評価，プロジェクト管理に関する研究に従事．電子情報通信学会，IEEE，PM 学会，

JFPUG 各会員．
井上 克郎（正会員）
昭和 54 年大阪大学基礎工学部情報工学科卒業．昭和 59 年同大学大学院博士課程修了．同年同大学基礎
工学部情報工学科助手．昭和 59 年
〜昭和 61 年ハワイ大学マノア校情報工学科助教授．平成 1 年大阪大学基礎工学部情報工学科講師．平成 3 年同学科助教授．平成 7 年同学科教授．工学博士．平成 14 年大阪大学情報科学研究科コンピュータサイエンス専攻教授．ソフトウェア工学の研究に従事．電子情報通信学会，日本ソフトウェア科
学会，IEEE，ACM 各会員．

石尾隆（学生会員）平成 15 年大阪大学大学院博士前期課程修了．現在同大学院博士後期課程在学中．アスペクト指向プログ
ラミングおよびプログラム構造解析の研究に従事．