石尾 隆 井上研究室D3 t-isio@ist.osaka-u.ac.jp Study on Aspect Extraction and Program Analysis for Effective Software Development ソフトウェア開発支援のためのアスペクト抽出とプログラム解析に関する研究.

Presentation on theme: "石尾 隆 井上研究室D3 t-isio@ist.osaka-u.ac.jp Study on Aspect Extraction and Program Analysis for Effective Software Development ソフトウェア開発支援のためのアスペクト抽出とプログラム解析に関する研究."— Presentation transcript:

1 石尾 隆 井上研究室D3 t-isio@ist.osaka-u.ac.jp
Study on Aspect Extraction and Program Analysis for Effective Software Development ソフトウェア開発支援のためのアスペクト抽出とプログラム解析に関する研究 presentation: Thesis ppt Total m 41s Slide m 50s Slide m 17s Slide m 45s Slide m 22s Slide m 14s Slide m 9s Slide m 34s Slide m 9s Slide m 58s Slide m 45s Slide m 24s Slide m 52s Slide m 24s Slide m 31s Slide m 56s Slide m 18s Slide m 58s Slide m 32s Slide m 12s Slide m 41s Slide m 24s Slide m 8s Slide m 0s Slide m 1s Slide m 1s Slide m 27s Slide m 11s Slide m 42s Slide m 46s Slide m 39s Slide m 54s Slide m 35s Slide m 15s Slide m 14s Slide m 25s Slide m 45s Slide m 18s Slide m 27s Slide m 46s Slide m 55s Slide m 2s Slide m 28s Slide m 15s Slide m 31s Slide m 47s Slide m 40s Slide m 52s Slide m 1s 石尾 隆 井上研究室D3

2 アスペクト指向プログラミング Gregor Kiczales らによって提案 (ECOOP 1998) 目標： 「横断的関心事の分離」
Separation of Crosscutting Concerns 新しいモジュール単位「アスペクト」の提案 AspectJ という Java の拡張実装も同時に提案 Java に，アスペクトを記述するための言語要素を追加 一部企業では，実際のソフトウェア開発でも使われている

3 関心事とは 「ソフトウェアが持つべき機能，品質」 １つの関心事はできるだけ１つのモジュールにまとめる 横断的関心事
（構造の把握） 各モジュールの役割が把握しやすい （再利用） 同じ処理を再利用可能になる （変更の局所化） 変更をモジュールの内部に閉じ込める 横断的関心事 達成するために，複数のモジュールにコードを書く必要がある処理 例: 「メソッドの呼び出しをファイルに記録する」 各メソッドの先頭などにログ記録処理を追加する必要あり

4 モジュール単位「アスペクト」の役割 横断的関心事のモジュール化 アスペクト: 指定されたルールに基づいて，処理の追加・置換などを行なう
メソッドが呼ばれるとき メソッド呼び出しの前に logs を呼び出す Class Line setColor Logging Aspect Class Logger logs() Class Circle setRadius setColor 開発者は，Line, Circle クラスを書き換えなくてよい

5 アスペクト指向プログラミングの利点 「いつ，何をするか」のルールによる記述 クラスの機能とは関係ない処理の呼び出しをクラスから除去する
実行するタイミングが変更されやすい処理のモジュール化に適する 例: ログを取る対象が変わっても，アスペクトの変更だけで済む 従来は，ログを取る処理すべてを検索してきて，変更する必要があった クラスの機能とは関係ない処理の呼び出しをクラスから除去する クラス側は，主目的の機能だけを記述できる  保守性，再利用性の向上

6 アスペクトの用途 Development Aspect Production Aspect Runtime Aspect
ソフトウェア開発作業を支援するための処理 ロギング，パフォーマンス計測 Production Aspect ソフトウェアの機能を実現するもの ユーザ認証（アクセス管理），データベースの暗号化など Runtime Aspect 実行時の性能改善 メモリ節約，ファイル先読み

7 研究の動向 アスペクトの有効な使い方を探る Runtime Aspect の使い方が最初に提案された
開発者が手で最適化したコードと比較して， 半分以下のコード量で実用的なレベルの性能を達成 Production Aspect が最も活発 実際に，ソフトウェアを開発したケーススタディが多い Development Aspect はあまり注目されていない ロギング，パフォーマンス計測程度

8 本研究の着眼点 Development Aspect に属する関心事は頻繁に登場する
開発者はテスト用，デバッグ用などのコードをよく書く アプリケーションドメインに依存せず発生する 通常，プログラムの複数の場所に，コードが分散する Development Aspect のモジュール化は， 開発作業を効率よく進めるために有効である ２つの横断的関心事について，アスペクトでの実現を提案 プログラムの動的解析 オブジェクトを横断した表明

9 アスペクトの複雑さ 一方で，アスペクトの問題点も指摘されている アスペクトのクラスへの依存性 アスペクト間の干渉
Fragile Base-Code Problem 「いつ処理を実行するか」という条件にメソッド名やクラス名を使う  クラス側で名前を変更すると，アスペクトも修正が必要 AspectJ の場合，統合開発環境で対応 アスペクト間の干渉 Inter-aspect problem 「他のアスペクトに影響を与えるアスペクト」が問題を引き起こす (例は次のスライド)

10 アスペクトの干渉 例: データベースコンポーネントに対して， 「メソッド呼び出しの引数を記録する」アスペクトと，
「データベースに渡す文字列引数を暗号化し， 戻り値の内容を復号化する」アスペクトを適用する 記録される文字列は，暗号化されているべきか？ Logger Logging call Database A client Encryption

11 干渉の発見 アスペクトの干渉問題の難しさ  プログラムスライシングの導入によるデバッグ支援
アスペクトの場合，必要ない限り，順序の指定をしない 実行順序の影響を受けるものは少ない 今までは，処理の実行順序を（とりあえず）指定する必要があった  プログラムスライシングの導入によるデバッグ支援 指定した変数に影響を与えうるプログラム文の集合を抽出する オブジェクト指向プログラミングに対応した手法を拡張 あるアスペクトのコードが，他のアスペクトからの影響を受けているか調べることが可能

12 研究内容のまとめ ２つの Development Aspect の提案 プログラムスライシングによるデバッグ支援 プログラムの動的解析
オブジェクトを横断した表明 アプリケーションに依存せず発生する横断的関心事 モジュール性，保守性への影響を評価 プログラムスライシングによるデバッグ支援 既存のスライシング技術をアスペクト指向に拡張 アスペクト指向プログラミングの利用には重要 AspectJ プログラムに適用した結果を評価

13 論文の構成 １章: Introduction ２章: Dynamic Analysis for Program Slicing using Aspect-Oriented Technique 文献 [2, 7] プログラムの動的解析処理をアスペクトとして実現 ３章: Modularization of Assertions Crosscutting Objects 文献 [3, 6] 表明の記述をアスペクトとして実現. ４章: Debugging Support for Aspect-Oriented Program Based on Program Slicing and Call Graph 文献 [1, 5] アスペクト指向プログラムに対するデバッグ支援 ５章: Conclusions

14 アスペクトの分類（再掲）: 用途での分類 Development Aspect Production Aspect
ソフトウェア開発作業を支援するための処理 ロギング，パフォーマンス計測 Production Aspect ソフトウェアの機能を実現するもの ユーザ認証（アクセス管理），データベースの暗号化など Runtime Aspect 実行時の性能改善 メモリ節約，ファイル先読み

15 アスペクトの分類: 構造での分類 Homogeneous Aspect Heterogeneous Aspect 多数の場所での同じ処理
システムの広範囲に渡るロギングなど 従来は，プログラム変換など，他の方法でも対応していた Heterogeneous Aspect クラスごとに異なる処理が，いくつかの場所に追加される アクセス権管理など様々 ユーザ認証が必要な処理開始前に 割り込んで認証を要求 認証がないままデータベースへの アクセスがないか監視 １つの目的のために 必要な処理が 複数ある

16 アスペクトの設計方法 (1/2) 一般的指針 Role-based Design との親和性† 同時に変更されやすいものを一箇所にまとめる
例: Observer パターンのアスペクトとしての実現 Observer Role と Subject Role との間の関連を定義 Subject が更新されたときは Observer に通知する 実際の「アクター」を Role に割り当てる Window が Observer 役，File が Subject 役 Role 間の関連をアスペクトに落とし込む 役割を担当するアクターはクラスとして実現する †Tamai, T., Ubayashi, N. and Ichiyama, R. : An Adaptive Object Model with Dynamic Role Binding. Proceedings of ICSE2005, St. Louis, Missouri, USA, May, 2005.

17 アスペクトの設計方法 (2/2) アクション・グラフを使った分析 † システムの動作（アクション）の関連を分析
複数のアクションに関連したアクションをアスペクトとする 授業履修システムの分析例: 「学生が授業に登録するとき，その情報を記録する」 「学生が授業の登録を解除するとき，その情報を記録する」 登録 授業 学生 解除 記録 Elisa Baniassad and Siobhan Clarke: Theme: An Approach for Aspect-Oriented Analysis and Design. Proceedings of ICSE 2004, pp , Edinburgh, Scotland, UK, May 2004.

18 クラスとアスペクトの役割分担 アスペクトがどこまで担当するべきかについては， 未知の部分が多い
AspectJ は利便性のため，たくさんの言語要素を取り込んでしまった 型チェックや例外処理など，Java との互換性のための制限あり 実装重視で，後付けで理論を固めている傾向が強い 最小限の機能だけを定義したアスペクト指向プログラミング言語を考えようという議論が進行中

19 プログラミング言語 AspectJ Java に，アスペクト記述のための言語要素を追加 アスペクトは，「いつ，何をするか」を指定する 用語
「ポイントカット・アドバイス」という仕組みを導入 用語 ポイントカット: 処理を追加ないし代替する対象 例：「名前が set で始まるすべてのメソッド呼び出し」 アドバイス: ポイントカットに対する操作 例：「直前に，メソッド名を記録するという処理を追加」 AspectJ におけるアスペクトは，ポイントカットとアドバイスを定義するモジュール

20 ポイントカットの指定 ポイントカットはプログラム実行時の「いつ」を指定 よく使われる Join Point
メソッド呼び出し (call) メソッドの実行 (execution) フィールドの参照 (get) フィールドへの代入 (set) AspectJ の場合，クラス名，メソッド名などにワイルドカードを許すことで「集合」を効果的に選択できる

21 アドバイスの指定 ポイントカットで選択された対象（イベント）に対して ある処理を，その直前に挿入する (before)
ある処理を，その直後に追加する (after) ある処理で，その対象を置換する (around) あるポイントカットの直前に処理を実行する場合： before() : pointcut_definition { … }

22 AspectJ でのロギングの実現例 before(): call(* *.set*(..)) {
Logger.logs(thisJoinPoint.getSignature()); } “thisJoinPoint” は Join Point の コンテキスト情報を保持 「名前が set で始まるメソッドの 呼び出し」を選択

23 3章: アスペクトを用いた表明の記述 表明（アサーション）とは Java における Assert 文:
「特定の時点で成立しているべき条件」の記述 Java における Assert 文: assert ( Boolean expression ); assert( true ):　 正常 assert( false ): 不正な状態，例外を発生させる

24 ドキュメントとしての表明 表明は，あるコードのまとまり（ブロック，メソッドなど）が「何をするか」を記述する
事前条件 例: double sqrt (int x) { assert( x >= 0 ); double result = /* 計算 */ assert( result * result <= x ); assert( result * result > x-1 ); return result; } 表明は，様々なプログラミング言語で利用可能となっています．たとえば C言語やJavaでは，assert文という，条件の検査を行う文が利用できます．違反した場合は，その時点で，プログラムが停止されます． また，事前条件，事後条件，クラス不変条件などの記述は，Eiffel ではプログラミング言語のレベルで，またJavaやC++では支援ツールとしてサポートされています． 事後条件

25 表明の利点 明確な責任の分担を可能にする ソフトウェアの早期故障検出 契約による設計 (Design by Contract)
契約＝メソッド単位での事前条件と事後条件 事前条件は，利用者側への要求 事後条件は，提供される機能 障害の原因がどちらにあるかを切り分けるために使われる ソフトウェアの早期故障検出 ソフトウェアの障害が他の場所に波及する前に検出する 重要なデータなどを壊す前にプログラムを停止できる デバッグ時，「どこで失敗したか」は有効な情報となる

26 研究の目的 モジュールを横断した表明をアスペクトで記述する モジュールを横断した表明の例 必要な言語要素と，その効果を検討
Observer パターンに，制約を追加 従来の方法では，Observer のモジュール性を悪化させる アスペクトを用いて書き換える ここから，表明をアスペクトとして書いてみる，という話をしたいと思います．立場として，何でもアスペクトに書いてしまうというわけではなく，アスペクトで書いたほうがうれしいであろうと思われる表明だけを相手にします． そこで，ここでは２つの分類，コンテキストに依存した表明と，複数のモジュールに分散してしまう表明というのを紹介したいと思います． コンテキストに依存した表明というのは，あるコンポーネントが１つ与えられたときに，それを使う側に応じて，あるいはテスト中などの状況に応じて，カスタマイズしたい表明のことです．今回は例として，汎用的なリストに格納するものを長さ１以上の文字列に限定する，というケースについて説明します． また，もう１つの分類として，複数のモジュールに分散してしまう表明というのを考えます．こちらは，例として，Observer デザインパターンの特殊形として，Observer とSubject という，状態の変化を監視する側とされる側のオブジェクト間の関連に対して， Observer と Subject が１対１で対応しなければならない，という制約を付加することを考えます． それでは，ここから，この２つの例を順番に見ていくことにします．

27 Motivating Example: Observer パターン
Subject + attach(observer); + detach(observer); Observer + update(); attach, detach update 例: 　画面 　 　　　 　　 ファイル ファイルが更新されたら 画面にも反映 observer は subject に自分を登録する 2. subject は，自身が変化したとき， observer に通知する 3. observer は，不要になった時点で登録解除する Here is a structure of Observer pattern. Observer pattern includes two parts, Observer and Subject. Observer watches the state of Subject, observer wants to get the latest state when the subject is updated. Observer has update method, Subject has attach and detach methods. First an observer calls attach method to register itself to a subject. When the state of subject is changed, the subject calls the update method of attached observers. Called observer is usually calls some methods of Subject to get the latest state. An observer detached itself from a subject if the observer no longer needs notification from the subject.

28 1 subject -to- N observers 制約
Observer 1つが 複数の Subject に接続されるのを禁止 Observer は接続した相手の情報を保存していない  Subject は，Observer が既に接続済みか検査できない 接続済み Subject 1 Observer 1 Subject 2 Observer 2 Here we consider one constraint prohibiting an observer attached to multiple subjects. In this figure, observer1 is already attached to subject 1. So another observer 2 can call the attach method of subject 1 or subject 2, but observer 1 cannot call the attach method of subject 2 until the observer 1 calls the detach method of subject 1. This constraint is hard to describe from the viewpoint of a subject. Although A subject knows observers attached to itself, a subject doesn’t know whether an observer which called the attach method is already attached to other subjects.

29 既存の表明による実現 Observer の接続相手を保存する subject フィールドを Observer クラスに追加する
Subject.attach メソッドを実行したとき，フィールドが空であることをチェックして，自分自身の参照をセットする An approach using traditional assertion is shown in this figure. This approach adds a field recording an attached subject to Observer class. Subject.attach method updates the field when the observer is attached to the subject, and detach method resets the field, respectively.

30 従来の解決方法の問題点 Observer クラスのカプセル化が破壊される
Subject クラスの attach メソッド，detach メソッドだけが Observer のフィールドを読み書きしている Observer クラス側からの書き込みは禁止されている attach Subject Observer must not modify read/write subject This implementation is problematic because of broken encapsulation. Only attach and detach methods of Subject can modify the subject field of Observer. An observer must not modify its field. These constraints damage the encapsulation of Observer class.

31 表明をアスペクトとして分離する ケーススタディでは，独自の言語を使用
AspectJ で利用可能な機能のうち，表明の記述に必要な部分だけ抽出したもの AspectJ に変換可能 使用可能な言語要素 「メソッド呼び出し」だけをポイントカットとして選択可能 事前条件の評価＝ 「メソッド呼び出しの前」にassert文を実行，で表現可能 呼び出し側，呼び出し先，引数にアクセス可能 既存のクラスに，必要なフィールド・メソッドを追加できる 表明検査・それに付随する処理の追加が可能 複数のオブジェクトを横断した表明のモジュール化は，複数モジュールに表明を分散させた場合より見通しがよくなります．また，他の制約と混ざらないことから，変更や除去が容易になります． また，表明記述のための特殊な実装，先ほどの例であれば，ObserverとSubjectの参照の管理も，アスペクトの一部としておくことで，他の開発者が勝手にそのインタフェースを使ってしまうといった問題を避けることができます．

32 アスペクトの導入後の形 Observer へのフィールド追加， そのフィールドの操作部分をアスペクトとして分離
Our approach is separating assertions, related methods and fields from classes. In this figure, OneSubjectManyObserverAspect adds a field to Observer class, and adds assertion using the field to Subject class. Observer へのフィールド追加， そのフィールドの操作部分をアスペクトとして分離

33 アスペクトによるモジュール性の向上 関連した表明と，それに必要なメソッド，フィールドを一箇所にまとめることができる
開発者に，それらが表明専用であることを明示し，他の用途に誤って使われることを防ぐ Observer パターンの例では，Observer の接続相手を保存した subject フィールド モジュール間の結合度の減少，凝集度の向上 subject フィールドは，アスペクトの中で定義され，アスペクトの中でだけ参照される  Observer 内に定義し，Subject が参照する場合よりも良い This slide shows advantages of improved modularity of assertion. One advantage is that related assertions and methods groups together. An aspect can define application-specific constraint for multiple classes. Next advantage is that the aspect separates methods and fields for assertion from classes. In the observer example, the subject field is special field for assertion implementation. Aspect prevent developers from misusing such a special field for other purposes. On the other hand, developers can divide assertions to several aspects defined for each viewpoint. The last advantage of our approach is that the aspect allows context-specific assertions. Assertion can rich contextual information, such as caller objects. Using the caller information, for example, a developer can define a strict assertion for an experimental module to improve the robustness of the system.

34 Strict checking aspect
アスペクトがもたらす有用性 コンテキストに依存した表明の定義が可能となる 例：信頼できないコードからの呼び出しのときだけ厳しいチェックを行なうアスペクト 十分テスト済みのコンポーネントに対しては，何もチェックしない 呼び出す側に依存した条件をコンポーネントから分離している Experimental Code Strict checking aspect A component Well-tested Component

35 関連研究との組み合わせ (1/2) 動的アスペクト インスタンスレベルアスペクト 実行時に，適用／無効化が可能
特定の処理を行っている間だけ有効化，といった使用が可能 インスタンスレベルアスペクト 特定のオブジェクトにだけ，アスペクトを適用する AspectJ は，対象をクラス単位で選択する 通常は動的アスペクトとして実装される

36 関連研究との組み合わせ (2/2) 状態に基づくジョインポイントモデル オブジェクトの状態（変数の値）を規定
状態遷移の発生に対して，処理を関連付ける 例: 「スタックが空でなくなるとき」 従来は，「Stack.push メソッドの呼び出し」を選択 この手法: 「Stack.size = 0 から Stack.size > 0 になったとき」 状態遷移に 処理を関連付ける スタックの状態定義 Size = 0 Size > 0 メソッド呼び出し列に関わらず 状態変化だけで指定できる

37 分散システムなどへの適用可能性 環境整備は進みつつある AspectJ の場合 AOP Alliance 分散環境との親和性は報告されている
分散システムにおけるログ取得のケーススタディが存在 分散環境向けの AspectJ の拡張の提案もなされている 「どのホストで動作しているか」といった動作条件など AOP Alliance 異なるアスペクト指向システムの相互運用のための 「アスペクト適用」インタフェース定義プロジェクト

38 実行時オーバーヘッド AspectJ コンパイラの最適化技術の進展 各モジュールに手でコーディングした場合と遜色ない†
ロギングの場合の実験では，最大でも，10％程度の性能劣化 手で書いたコードよりも高速になる場合も 表明で複雑な条件をチェックする場合のコスト 「条件の検査コードを実行するかどうか」が 静的に決定可能かどうかによって大きな影響を受ける † Erik Hilsdale, Jim Hugunin: Advice Weaving in AspectJ. Proceedings of AOSD 2004, pp.26-35, Lancaster, UK, March 2004.

39 ３章のまとめ 表明はソフトウェア開発における重要な道具 横断的な表明をアスペクトとして分離する 表明の中には，モジュールを横断するものがある
横断的な表明は，クラスのモジュール性を損なう 横断的な表明をアスペクトとして分離する 関連した表明を１箇所にまとめることが可能になる コンテキストに依存した表明の記述など，柔軟な使い方が可能 最後にまとめます．表明とは，元々，コードが何をしているかを説明し，また誤った振る舞いを検出することから，Predictability を向上させ，システムが何をしているか，開発者の理解を促進します．また，表明を詳細に記述すればするほど，安全性は高くなりますが，不要な条件まで書き加えてしまうことでコードの再利用性が低下したり，仕様の変更時にあちこちの表明を直さなくてはならないといったように，Evolvabilityを悪化させる要因となることがあります． 表明をアスペクトとして記述すると，コンテキストに応じた性質をアスペクトとしてもとのコンポーネントとは分離して整理しておいたり，複数のモジュールを横断したような性質もまとめて書くことができます．これは，分散した表明記述と比べると，そのアスペクトを見ればオブジェクト間の性質が理解できることから，Predictability の向上が見込めますし，モジュールとして分離したことから追加や削除も容易となり，Evolvability も向上することができると考えられます．

40 4章: プログラムスライシングによるデバッグ支援
アスペクト指向の利点 「いつ処理を実行するか」がポイントカットとして明記される 横断的関心事を実行するルールの変更が容易となる 処理の対象となるクラスを簡単に変えられる 開発者は，必要なアスペクトを選んでコンポーネントに適用するだけ 個々のアスペクトを作る人，クラスを作る人，クラスにアスペクトを適用する人，クラスにさらに別のアスペクトを適用する人は，同一人物とは限らない

41 アスペクト間の干渉 （再掲） 例: データベースコンポーネントに対して， 「メソッド呼び出しの引数を記録する」アスペクトと，
例:　データベースコンポーネントに対して， 「メソッド呼び出しの引数を記録する」アスペクトと， 「データベースに渡す文字列引数を暗号化し， 戻り値の内容を復号化する」アスペクトを適用する 記録される文字列は，暗号化されているべきか？ Logger Logging call Database A client Encryption

42 アスペクト間の干渉の原因 アスペクトを複数貼り付けたとき，予期せぬ動作をすることがある 主な要因:
アスペクトが仮定しているメソッドの呼び出し順序や，使うデータが，他のアスペクトから影響を受けている 先ほどの例では，暗号化アスペクトが引数のデータを書き換えるのと同時に，ロギングアスペクトが，同じデータを参照している

43 「干渉」によって起きた問題への対応 基本的には，動作の順番を決めることで解決する 人間でなければ決定できない
AspectJ では precedence という宣言を行う 従来のプログラミングでは，メソッド呼び出し文を並べるときに決定している問題 人間でなければ決定できない データベースへのメソッド呼び出しの引数の記録は，暗号化前後，どちらがほしいか，開発者によって異なる 両方ほしい，という開発者もいるかもしれない

44 干渉の検出へのアプローチ 理想的には，アスペクトの動作順序の決定がそもそも必要かどうか自動チェックしてほしい
個々のアスペクトの処理内容を調べる手間がある 順序決定が必要でないことも多い しかし，機械的な検出は困難 「同時に動くアスペクト間での干渉」といった条件付きでの検出がいくつか研究されている

45 プログラムスライシングの適用 問題が起こってからの対処でのアプローチ プログラムスライシングとは
あるアスペクトが，他のアスペクトからどう影響を受けているかを，機械的に調査して，開発者に提示する プログラムスライシングとは プログラム解析手法のひとつ プログラム内部の依存関係を解析する ある変数に対して，影響を与えるプログラム文の集合を抽出する アスペクト内の変数を基点にすると，そのアスペクトが，他のアスペクトから影響を受けていないか調べられる 　以上が，アスペクトを組み込む段階での情報の提示でした．Call Graphを用いることで，少なくとも無限ループに陥るような重大な干渉は除去されており，プログラムを実行できるという状態になります． 　今度は，実行結果が正しくない場合，その原因を調べるための支援を行います．ここではプログラムスライシングと呼ばれるプログラム解析手法を利用します．プログラムスライシングは，プログラムの中に含まれるデータや制御の依存関係を解析し，開発者が注目する必要があるコードのみを抽出，提示するという手法です． 　元々は手続き的プログラムに対して提案されたものですが，オブジェクト指向プログラムに対しても既に拡張され，その有効性が確認されています．モジュール間の依存関係が複雑化するアスペクト指向プログラムでも，その効果が期待されるため，Call Graphの場合と同様の発想で，手法を拡張します．

46 プログラムスライスの定義 プログラムのある文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 に注目して，この変数に対するプログラムスライスを計算すると，右側に示したものになります．この計算は，プログラムの各文を頂点とし，依存関係を有効辺としたグラフにおいて，その依存辺を逆向きに辿っていく探索問題として考えることができます． 　求められたプログラムスライスを見ることで，開発者は，その値がどのように決まったかを知ることができます．たとえばデバッグ作業中，ある時点で変数の値がおかしくなっていることに気付いたとすると，その変数を基点にスライスを計算することで，無関係なコードをあらかじめ取り除くことができ，作業を効率的に進めることができます．

47 スライス計算に必要な情報 データ依存関係 制御依存関係 メソッド呼び出し関係 ローカル変数の 代入 → 参照
フィールド（メンバ変数）の 代入 → 参照 制御依存関係 実行制御文の条件節 → 制御される文 メソッド呼び出し関係 メソッド呼び出し文 → 呼び出されるメソッドの文 メソッド呼び出し文の実引数 → 呼び出されるメソッドの仮引数 アスペクトの連動位置 → 動作するアスペクト アスペクトの連動位置 → アスペクトが参照する実行時点情報 　プログラムスライスの計算を行うためには，データと制御，そしてメソッド呼び出しに関する依存関係を解析する必要があります． 　データ依存関係は，変数それぞれについて，ある代入文から，そこで代入された値を参照する文への依存関係として定義します． 　制御依存関係は，if や while などの実行制御文から制御される文への依存関係です． 　メソッド呼び出しは，呼び出し文から呼び出されるメソッドへの制御の流れと，引数によるデータの流れの，二つの依存関係が基本となっています．これにアスペクトが起動される時点から動作するアスペクトへ，という依存関係を追加します．これは，Call Graphのときと同じ発想です．また，多くのアスペクト指向言語処理系では，アスペクトは，どの時点で実行されたかという，実行時情報にアクセスすることができます．これは，引数として実行時点の情報が渡されているものと考えます． 目的をデバッグに限定するため，実行が失敗するようなテストケースが特定されている状態を想定します．この特定のテストケースの実行経過を監視し，その情報，たとえばオブジェクトの区別，動的束縛の解決を反映することで，扱うコード量を減少させることができます．静的情報のみの場合は，

48 アスペクト指向のための拡張 参照 Logging Aspect 呼出 「アスペクトが動作する」 = 対応するメソッドを
Class Line setColor Logging Aspect 参照 Class Logger logs() Class Circle setRadius setColor Class Line setColor 呼出 Aspect Logging before_call() 「アスペクトが動作する」 = 対応するメソッドを 呼び出している，とみなす Class Circle setRadius setColor Class Logger logs()

49 動的情報の利用 目的をデバッグに限定 実行が失敗するテストケースが特定されている状態を想定 動的（実行時）情報 が利用可能
オブジェクトの区別，動的束縛の解決によってコード量を減らす

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

51 プロトタイプのスクリーンショット スライス基点をエディタ上で選択 スライス結果を エディタ上に出力 コンパイル時に静的情報収集
　ツールのスクリーンショットはこのようになっています． 　プログラムをコンパイルすると，静的な情報が収集され，スライス計算が可能な状態になります．スライス基準をエディタ上で範囲選択し，ツールバーからスライス計算を指示すると，結果がエディタ上に，ここでは青い波線として表示されています． コンパイル時に静的情報収集

52 適用実験 AspectJ のサンプルコードに対する適用 学生12人によるデバッグ実験 5つのデザインパターンの実装を対象
従来ツールで，どのくらい依存関係の追跡にコストがかかるか評価 学生12人によるデバッグ実験 AspectJ プログラムを対象にしたデバッグ作業 4つのアスペクトのうち1つが，他の1つの動作を阻害 12人中，6人が，プログラムスライスの情報を使用

53 評価 (1/2) 依存関係の追跡作業は，コストが高い 従来のツールは，他のアスペクトが「どこで動くか」を表示するだけ
影響を与えるようなアスペクトかどうかは，コードを読まないと分からない スライシングでは，影響を与えるかどうかも同時に与えられる 「影響を与えない」ところは最初から無視できる アスペクトは，通常，複数のファイルに定義されるので，ファイルをまたいだ依存関係を接続していく必要がある 実験に関する評価は，次のとおりです． まず，アスペクト指向プログラムでは，横断要素だけがアスペクトというモジュールに分離された分，考慮すべき依存関係の数自体は増加しています．特に，複数のファイルにまたがる依存関係が多いため，手作業での追跡作業はコストが高くなります． また，プログラムスライシングを用いることで，アスペクトの動作によって実行されなくなる，依存関係がなくなるコードを発見できることが示されました．

54 評価 (2/2) バグの原因特定について バグの修正について 作業に取り掛かる段階で，コードを読む指針となる
「原因の候補」として目をつけた点に対して，その部分がスライスに含まれているかどうかで，候補を絞り込める バグの修正について 変更結果が他のアスペクトに影響を及ぼさないことを確認するには，他のアスペクトも読まないといけない  スライスだけで，作業時間を短縮できるとは限らない 影響波及解析手法との組み合わせが考えられる† プログラムスライスを用いた学生から意見を集めた結果，次のようなことが分かりました．まず，スライスを用いる利点として，プログラムと同時にスライスが与えられることで，作業の取り掛かりで，どのコードを読めばよいのか，という指針となります．また，原因の候補として目をつけた点が，スライスに含まれているかどうかで，候補を絞り込んでいくことができた，という報告がありました． しかし，同時に，バグを特定しても，修正が正しいかどうか，その変更が他のアスペクトに影響を及ぼしていないかどうかを確認するには，他のアスペクトも調べなければならず，結局，すべてのアスペクトを調べることになり，結果として作業時間が大幅に短縮されることはなかった，ということが分かりました． 　この結果から，プログラムスライスはバグの特定作業には役立ちますが，バグ修正においては影響波及解析など他のデバッグ支援手法との組み合わせることが重要であると考えられます． † 四野見，玉井: アスペクト指向における織り込みによる影響波及解析． プログラミングおよびプログラミング言語ワークショップ(PPL2005) 論文集．

55 ４章のまとめ アスペクト指向プログラムのデバッグ支援 評価実験の結果 プログラムスライシングの適用
従来手法に，「アスペクト呼び出し」を追加 アスペクトの動作を，メソッド呼び出しと同様の形式で扱う 静的情報，実行時情報を組み合わせた開発者の支援 評価実験の結果 スライシングは，アスペクトによる振る舞いの変化を効果的に示すことができる アスペクトによって引き起こされた問題の特定に有効 最後にまとめます． 　アスペクト指向プログラムに対する開発支援として，まず，Call Graphを用いたアスペクト干渉の検出を行いました．アスペクトの動作をメソッド呼び出しと同様に考えて呼び出し関係をグラフ化し，無限ループの発生のような，実行を不可能にするような重大な干渉を検出し，開発者に提示します． 　また，実行した結果が正しくないと判明した場合に対して，その原因の調査を支援するために，プログラムスライシングの適用を行います．プログラムスライシングは，依存関係を追跡して，開発者が調査すべきコードを抽出・提示する手法です．ソースコードの静的な情報と，実行時情報を組み合わせて，開発者の支援を行います． 　プログラムスライスの有効性を評価するために，プログラムスライス計算ツールの適用と，デバッグ作業への影響評価を行いました．この結果，プログラムスライスがアスペクトによる依存関係の変化を開発者に提示できるほか，バグの原因特定作業に対して効果があることが分かりました．ただし，バグの修正には他の手法が必要となります． 　今後の課題として，多数のオブジェクトを横断したアスペクトの効率的な扱いによるスケーラビリティの実現，影響波及解析などの他のデバッグ支援手法との連携が挙げられます． /*　アスペクト指向プログラミングの特徴は，横断要素のモジュール化にあります．複数のオブジェクトが関わる処理を単一のモジュールにまとめることで，保守性，再利用性を向上させることができます．しかし，ソースコードの見た目と実際の動作との間のギャップが拡大するという問題があります．*/

56 アスペクト指向プログラムの品質 モジュール性などを客観的に評価する指標は？ CKメトリクスの拡張† アスペクトの導入の影響を評価したい
オブジェクト指向での指標には，アスペクトに関する定義がない CKメトリクスの拡張† 「クラス」 → 「クラスまたはアスペクト」 結合度: Coupling Between Objects の拡張 1つのクラスまたはアスペクト中に登場する他のクラス，アスペクトの数 凝集度: Lack of Cohesion の拡張 １つのクラスあるいはアスペクト中のメソッド単位で，お互いにメンバー変数をまったく共有しないようなペアの個数（大きいほど悪い） † Sant Anna, C., Garcia, A., Chavez, C., Lucena, C. and Von Staa, A: On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework. Proceedings of XVII Brazilian Symposium on Software Engineering, Manaus, Brazil, 2003.

57 新たな評価尺度の導入 新たな尺度： 関心事の分散度合い 提案は複数 １つの関心事は少数のモジュールで実現されるべき
１つの関心事を実装に関わる クラス・アスペクトの数 ＋それらを直接参照する 1つのクラス（アスペクト）が 関わる要求の個数を数える† † Kassab, M., Ormandjieva, O. and Constantinides, C.: Providing Quality Measurement for Aspect-Oriented Software development. Proceedings of AO-ASIA Workshop, Taipei, Taiwan, December 2005.

58 品質の評価ケーススタディ シミュレータに対する変更操作† 保守性，再利用性は上がる モジュール数の増加が，理解容易性の足を引っ張る
オブジェクト指向システムに比べ，結合度は大きく低下 １つのメソッドから呼び出されるメソッドの数は増加する CKメトリクスにおける振舞いの複雑さの指標 RFC (Response For a Class) = 呼び出したメソッドから推移的に呼び出すメソッド数 保守性，再利用性は上がる 結合度の低下が大きく貢献する モジュール数の増加が，理解容易性の足を引っ張る 個々の部品は単純になっても，部品点数が増える † Shiu Lun Tsang, Siobhán Clarke, Elisa Baniassad: Object Metrics for Aspect Systems: Limiting Empirical Inference Based on Modularity. Trinity College Dublin technical report

59 むすび アスペクト指向プログラミング Development Aspect に属する関心事のモジュール化を提案
「横断的関心事の分離」を提案 モジュール単位「アスペクト」の導入 アスペクトの用途: Development / Production / Runtime Aspect Development Aspect に属する関心事のモジュール化を提案 Development Aspect は，ソフトウェア開発作業全般で登場するため重要 プログラムの動的解析 オブジェクトを横断した表明 Production / Runtime Aspect での有用性は，他の研究者によって示されている 横断的関心事のモジュール化にアスペクト指向プログラミングは有効

60 アスペクト指向のもたらす複雑さへの対処 プログラムスライシングによるデバッグ支援を実現
プログラムスライシングをアスペクト指向向けに拡張 変数の値にアスペクトが影響を与えている場合，それを提示できる プログラムスライシングに基づく他の解析手法にも同様の拡張は適用可能 影響波及解析は既に実現されている プログラム解析手法を使うことで，アスペクト指向プログラミングの利用が容易となる 問題の発生を予測する方法の研究はまだ途上 型推論，プロセス代数など，理論的側面からの研究

61 今後の展望 アスペクト指向プログラミングから アスペクト指向ソフトウェア開発へ Early Aspects
要求間の依存関係の整理 システムの広範囲に影響を与える要求の発見 Aspect-Oriented Modeling 関心事のモデリング アスペクト指向プログラムの設計 アスペクトのためのモデル記述言語 Aspect-Oriented Programming 横断的関心事のモジュール化 アスペクトのテスト方法

62 アスペクト指向の影響 横断的関心事のクラスからの分離  以前よりも単一の部品は単機能に近づく コンポーネント間の結合が増加
部品のモジュール性，凝集度，再利用性は向上 コンポーネント間の結合が増加 コンポーネントの結合を管理する必要性が増大 クラスの場合，「メソッド呼び出し」で明示的に結合されていた アスペクトの場合，いつ動作するかは，結合対象のプログラムが決まるまで分からない

63 研究課題 関心事の整理／管理 モデルとソースコードの関連付け 関心事間の関係の可視化 大規模ソフトウェアの抽象化
作ったものが，実際にモデルを反映しているか検査 ソフトウェアから，人間が「読める」情報を抽出する 関心事間の関係の可視化 １つのアスペクトが及ぼす影響の可視化は研究されているが， 複数のアスペクトの関連の可視化は実現されていない 広範囲に影響を与えるアスペクトの振る舞いの可視化も困難 大規模ソフトウェアの抽象化 ソフトウェアの適切な単位への分割 「関心事」ごとに，対応するソフトウェアの要素を発見する

64 アスペクトの可視化 ある１つのアスペクトに対して，関連するクラスを表示した場合 Logger call Database A client
Logging call Database A client call Database A client Encryption

65 終

66

67 補足資料

68 AOP一般

69 「横断的関心事」の問題 横断的関心事： 従来のモジュールが対応できない関心事 例: 名前が set で始まるメソッドの呼び出しを記録
他のモジュールに少しずつ変更を加える必要あり 例: 名前が set で始まるメソッドの呼び出しを記録 各メソッドに，呼び出し文が必要 Class Line setColor Logger.logs(methodName); Class Logger logs() Class Circle setRadius setColor 一貫した実装の維持が困難  保守性を悪化させる

70 アスペクト指向の実現方法 従来のモジュール単位ではまとめられなかったものを， アスペクトにどのようにまとめるか?
できるだけモジュール間の依存関係を減らしたい コンパイラがプログラムを組み立てるルールが必要 Join Point Model の導入

71 Join Point Model Join Point: プログラム中の特定の実行時点
メソッド呼び出し，フィールドの参照，更新，... Join Point の決め方が言語の特性を決める

72 アスペクトの記述方法 アスペクト ＝ 「いつ，何をするか」 で処理を記述 アスペクトは，他のクラスにメンバーを追加してよい
pointcut: イベント(join point)の集合 advice: pointcut に対応させる手続き Pointcut の直前に処理を追加する Pointcut の直後に処理を追加する Pointcut の代替の処理を実行する（本来の処理を回避する） advice の呼び出しは，コンパイラ・インタプリタが自動で埋め込む メソッド呼び出しが，対象のプログラム側に出現しない アスペクトは，他のクラスにメンバーを追加してよい クラス階層で関係のないクラスにも同じメソッドをまとめて定義できる

73 「図形の移動が起きたら画面を更新」の例 「図形の移動」というイベントは メソッド呼び出し Line.setP1, Line.setP2,
Point.setX … である，と定義

74 表明

75 アスペクトを用いた表明の書き換え 事前条件，事後条件は，アスペクトとして書きやすい AspectJ による実装例
「メソッド呼び出しの直前と直後に条件を検査」という 簡潔なルールによって記述が可能 AspectJ による実装例 pointcut sqrt_call(int x): call(double aClass.sqrt(int)) && args(x); before(int x): sqrt_call(int x) { assert( x >= 0 ); }

76 言語要素の検討: Join point Join Point Model Pointcut: Join point の選択に使える述語
AspectJ の Join Point Model を採用 AspectJ のモデルはメソッド呼び出しなど，実行時のイベントに基づく 「メソッド呼び出しの前後」が表明の検査が一番多いタイミング Pointcut: Join point の選択に使える述語 call pointcut が主体 Context exposure も重要 Context exposure: 呼び出しなどの時点でのオブジェクト，引数へのアクセスを提供する仕組み AspectJ における this, target, args pointcuts 制御フローの cflow pointcut などの効果の検討は今後の課題 Here we discuss about language constructs required for writing aspect for assertion. Preconditions and postconditions are usually checked before and after a method call, so aspect for modularizing assertion needs a join point model reflects the behavior of a program. Therefore, we are using AspectJ model in this research. We have chosen Join point model, next we consider pointcut selection. Call pointcut is main construct because we consider that assertions are written for each method call. Assertion expression needs to access contextual information including method caller object, callee object and arguments of a method call. Currently, we are focusing on a simple small set of pointcut designators to describe assertion. Therefore, cflow pointcut is unused in our current prototype.

77 アドバイスとインタータイプ宣言 Advice インタータイプ宣言 assert 文を書くのが主な目的
１つの呼び出しに対して，事前・事後条件がペアで付く 両方をペアで書けるように言語を用意 AspectJ では before/after と個別で実現される インタータイプ宣言 表明の記述に必要なメソッド・フィールドの定義 オブジェクトに，中間状態の保存用のフィールドの追加 データ集計用のメソッドの追加 表明 「専用」 であることが明示される Next, we discuss about advice and inter-type declaration. The main purpose of advice is writing assert statements. An advice definition should be able to contain both pre and postconditions because contract for a method usually consists of both preconditions and postconditions. Therefore, we can define a simple syntax to describe an advice. Inter-type declaration is needed to add fields and methods to objects. Fields are used to record the inter-mediate state for a sequence of a method calls, and methods are used to inspect the complex state or to simplify assertion statements.

78 Advice for Subject.attach (次のスライド) Advice for Subject.detach (省略)
Aspect for Observer 定義の開始 定義の終了 インタータイプ宣言 (AspectJ 形式) Advice for Subject.attach (次のスライド) Advice for Subject.detach (省略) This slide shows our aspect for Observer constraint. An aspect consists of inter-type declaration and advices. Current version doesn’t support named pointcut directly. This aspect contains two advices for attach method and detach method.

79 Advice for Subject.attach
The beginning of advice definition The end of Pointcut declaration this calls target.method(args) Preconditions (before) code block executed after the postconditions are checked. This slide shows an advice for attach method. An advice definition starts with the keyword “def”, and it ends with the keyword “end”. An advice is associated with a pointcut declaration. Pointcut specifies caller object, callee object, method signature, and argument object. In this definition, this assertion is checked for arbitrary method callers when the called object is an instance of ASubject class, and the parameter is an instanc of AnObserver class. Keyword “Pre” represents preconditions. This is same as “before” advice in AspectJ. Boolean expressions listed in the body are checked before the method call. The list is checked in the sequential order. Keyword “post” represents postconditions. The advice body is same as “after” advice in AspectJ. The lists of preconditions and postconditions may include a code block. A code block can calculate some complex conditions or update some fields. This code updates the subject field added by the aspect.

80 アスペクトの導入によって生じる弱点 複数のコンポーネントの表明が，１つのアスペクトになる
１つのコンポーネントの表明が，複数のアスペクトに分散する アスペクトは，表明の追加だけが許されている 存在を知らなくても，テスト段階で検知可能 アスペクトの存在は，ツール等で検知可能 横断的な表明をすべて検知するよりも容易 クラス名など，必要な情報がアスペクト内に提供されているため

81 動的解析

82 アスペクト指向での動的解析の実現 プログラムの動的解析とは プログラム解析技術に必要な情報を，プログラムの実行時に取り出すこと
メソッド呼び出しの発生順序 変数の代入・参照の発生順序 特定のメソッドの実行回数のカウント オブジェクトの確保した個数 メソッドの実行時間，… 多数のメソッドに対して，解析用の処理を追加する必要がある

83 従来の実現法との比較 通常は，プログラム変換技術を用いる アスペクト指向による実現 メタプログラミング技術が必要
構文のパース，構文木上での変換 たとえば，メソッドの先頭にロギング用のコードを追加する 実行したい処理内容と，実装（変換ルール）に隔たりが大きい アスペクト指向による実現 処理内容を明確に表現可能 メタプログラミングの知識がほとんど不要

84 ケーススタディ プログラムスライシングに必要な動的解析モジュールを AspectJ で実装
フィールド参照・代入，メソッド呼び出しで，実際にどのオブジェクトが使われたか履歴を記録 イベントを取得するアスペクト ＋ 解析用クラス ＋ 結果の圧縮処理クラス 合計で約1000行程度のモジュール群として実装 対象プログラムの一部としてコンパイルされるので，テスト環境の構築やデバッグ作業が容易

85 他の方法と比べた場合 Java コンパイラのカスタマイズ プリプロセッサによる実装
最適化したコードを生成するといった実装も（努力すれば）可能 そのかわり，実装に必要なコストが高い プリプロセッサによる実装 やりたいことを，構文木の変換処理として書き下す必要あり Java Virtual Machine Debugger Interface JVM に付随するデバッガを作るためのインタフェースの利用 スレッド制御やメモリ確保などの分析も可能 そのかわり，JVM の動作に関する知識が必要 JVM が機能を提供しない場合もある これ自身のテスト・デバッグが困難

86 プログラムスライシング

87 実験(1) ツールの適用 適用対象 実験内容 AspectJ サンプルコード ５種類 プログラムの実行時情報解析アスペクト
各サンプルコードのサイズは平均500行 実験内容 サンプルコードを実行し，その結果に対してプログラムスライスを計算 従来のツールを用いた依存関係の追跡との定性的比較 AJDE: どこでアスペクトが動作するかをマーカーで表示する 作成したツールの評価と，スライスが開発作業に与える影響の評価を行うために，２つの実験を行いました． ここでは，まず，ツールの適用実験について説明します． 適用対象は，インターネット上で公開されているAspectJのサンプルコード５種類と，プログラムの実行時情報を解析するために作ったアスペクトの合計６種類です．各サンプルコードのサイズは平均500行となっています． サンプルコードを実行し，その結果に対してプログラムスライスの計算を行い，その有効性に関する定性的な評価を行いました．比較対象として，AJDEという，Eclipseプラグインのひとつで，どこでアスペクトが動作するかをオブジェクト側のソースコードにマーカーで表示するツールを用いました．

88 実験(2) 開発への影響の評価 大学院の授業での利用 実験の手順 大学院生(修士課程) 12名
授業で Java 使用経験あり，AspectJ は使用経験なし 開発環境: Eclipse + AspectJ plug-in 実験の手順 Eclipse についての解説 Eclipse を用いた Javaプログラムのデバッグ演習（事前課題１） AspectJ についての解説 Eclipse を用いた AspectJ プログラミング演習（事前課題２） Eclipse を用いた AspectJ プログラムのデバッグ（実験） ランダムで選んだ 半数，６名 にプログラムスライスを渡す 時間の都合上，印刷物で提供 　さて，ここから，プログラムスライシングが，デバッグ作業へどのように影響を与えるか評価するための実験について説明します． 　実験は，大学院の授業において，14名の大学院生を対象としました．学生は，全員が過去の授業でJavaを使用した経験があり，AspectJを使うのはこの実験が初めてです．開発環境にはEclipseを用いました． 　実験は，次のような手順で行いました．まず，Eclipseについての解説を行い，小規模なJavaプログラムのデバッグ演習を行って開発環境に慣れてもらいました．次に，AspectJ を用いたプログラミングの方法について説明し，簡単なアスペクトを記述するプログラミング演習を行い，最後に，実験の課題を与えました．

89 対象プログラムの概要 対象: 式評価プログラム クラス５つ（式構造クラス），アスペクト４つ，合計340行
入出力例: (+ 4 3 (* 2 7 ) (* 2 7) )  35 一部のノードは共有されていることがある クラス５つ（式構造クラス），アスペクト４つ，合計340行 処理経過の文字列出力 計算結果の共有 （同じ式が２度目以降は計算を飛ばす） 式のグラフ表現上でのループ検出 評価が終了したグラフの接続解除 アスペクトの干渉によって正しい結果が出力できない 原因： 計算を飛ばすアスペクトによって，文字列出力の処理もスキップされる プログラムスライス 文字列出力アスペクトの，文字列を格納している変数がスライス基点 他３つのアスペクトのうち，計算結果の共有アスペクトだけが影響する この実験では，小規模な，複数のアスペクトを含んだ AspectJ のプログラムを対象として，アスペクトの干渉によって出力結果が正しく計算されないという問題に関するデバッグ作業を行いました．プログラムスライスの有効性を評価するために，学生の半数の６名に，ツールの使用方法などを訓練する時間がなかったため，プログラムの出力データを格納している変数をスライス基点として計算したプログラムスライスの情報を，印刷物の形で提供しました．

90 アスペクトの干渉 値の要求 計算結果 記録/共有 アスペクト ノード ノード 計算結果 途中を出力するアスペクト

91 提供したスライスの一部 既に計算済みの場合は 計算を省略する 計算が完全に終了した 時点で，フラグをクリア この計算省略機能が，
public aspect CachingAspect { // member of this Aspect static private Set workers = new HashSet(); // add a member to Worker class private boolean Worker.isAlreadyCalculated = false; pointcut work_call() : call(void Worker.work()); pointcut first_work_call() : work_call() && !cflowbelow(work_call()); void around(): work_call() { Worker w = (Worker)thisJoinPoint.getTarget(); if (w.isAlreadyCalculated) return; else { proceed(); w.isAlreadyCalculated = true; workers.add(w); } // clear the flag when calculation process is finished after(): first_work_call() { for (Iterator it = workers.iterator(); it.hasNext(); ) { Worker w = (Worker)it.next(); w.isAlreadyCalculated = false; workers.clear(); 既に計算済みの場合は 計算を省略する この計算省略機能が， 計算経過の文字列出力も 飛ばすことがバグの原因 計算が完全に終了した 時点で，フラグをクリア 提供したプログラムスライスの一部だけですが，このようになっています． 太字になっている部分がスライスです．このスライスでは，プログラムの出力に関係ない部分が取り除かれています．ここでは，対象プログラムに含まれていた４つのアスペクトのうちの１つしか挙げていませんが，残り３つのアスペクトのうち，２つにはまったくスライスが含まれておらず，プログラムが出力している誤った結果にはまったく関わっていないことが示されています． 出力結果には関係ないので スライスに含まれない

92 実験の提出物 提出物 （事前の２回の演習課題，実験用の演習） 提出した結果を分析 問題の原因 修正方針 変更したソースコード
作業に要した時間 スライスを使用した感想 提出した結果を分析 この実験と，事前準備として行ったJavaプログラムのデバッグの演習では，問題の原因，修正方針，修正したソースコード，作業に要した時間を提出してもらいました．また，スライスを使用した学生については，使用した感想についても報告してもらいました．これらを提出した12名，うちスライスを使用した学生は6名でしたが，その結果について，これから説明します．

93 実験結果 Javaプログラム課題の作業時間との順位相関 スライス使用の効果 グループ 事前課題1 (Java) 事前課題2
相関係数 r = 0.54 AspectJ プログラミングでは Java に関するプログラミング能力が重要な要素となる スライス使用の効果 スライス使用者のほうが値は平均時間が短い 作業時間の平均 (単位: 分) グループ 事前課題1　(Java) 事前課題2 (AspectJ) 実験 1 150 186 200 2 210 190 （スライス使用） 評価は，バグの特定および修正を合わせた時間をベースに行いました．JavaとAspectJの課題において順位相関を取ると，0.5と正の相関があり，AspectJプログラミングの能力は，Javaプログラミングの能力の影響を受けていることが分かりました．実験でスライスを使用しなかった学生をグループ１，スライスを使用した学生をグループ２として，作業に要した時間の統計を取ったところ，この表のようになりました．スライスを使用した学生のほうが，平均的には好成績となりましたが，統計的に有意な差は示せませんでした．

94 「依存関係がなくなる」コードの例 開発者が意識する依存関係 実際のスライス結果 void f1() { x = f2(); ： }
　： } int f2() { return doSomething(); int f3() { return doSomething2(); aspect redirectMethodCall { int around(): call(f2) { return f3(); 実際のスライス結果 void f1() { x = f2(); 　： } int f2() { return doSomething(); int f3() { return doSomething2(); aspect redirectMethodCall { int around(): call(f2) { return f3(); 依存関係がなくなるコードの例を示します．ここでは，メソッドf1の中でメソッドf2が呼び出されていますが，下にアスペクトがひとつ定義されており，f2への呼び出しに対して動作することがわかります．一見すると，色をつけた四箇所に依存関係がある，と考えられますが，このアスペクトは本来のメソッド呼び出しを完全に置き換えるアスペクトなので，元のf2への呼び出しは消えてしまい，実際のスライス結果は右側に示したものになります．従来のAJDEでは，アスペクトがどこで動作するか，という情報は示せましたが，このような依存関係がなくなるコードを明確に示すことができませんでした． このような，開発者が誤解しやすい点をサポートできることが，プログラムスライシングの利点だと言えます． メソッド呼び出しを 置き換えるアスペクト

95 品質／メトリクス

96 CKメトリクス: 凝集性の欠如(LCOM)
仮定： 凝集度の高いクラスは，各メソッドで，同じデータを扱っている＝インスタンス変数を共有しているはずである． 定義: クラス C1 に n 個のメソッド M1 … Mn があり，それぞれが参照するインスタンス変数の集合を I1… In とする． P = { (Ii, Ij) | Ii ∩ Ij = φ } インスタンス変数を共有しないようなメソッドペアの集合 ただし， I1 … In がすべてφのときは P = φ Q = { (Ii, Ij) | Ii ∩ Ij ≠ φ } LCOM = |P| - |Q| if |P| > |Q|, 0 otherwise. 値が高いほど悪い状態を示す（他のメトリクスと共通）