Study on Aspect Extraction
and Program Analysis
for Effective Software Development
ソフトウェア開発支援のためのアスペクト抽出と
プログラム解析に関する研究
石尾 隆
井上研究室D3
[email protected]
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクト指向プログラミング
Gregor Kiczales らによって提案 (ECOOP 1998)
目標: 「横断的関心事の分離」
Separation of Crosscutting Concerns
新しいモジュール単位「アスペクト」の提案
AspectJ という Java の拡張実装も同時に提案
Java に,アスペクトを記述するための言語要素を追加
一部企業では,実際のソフトウェア開発でも使われている
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
関心事とは
「ソフトウェアが持つべき機能,品質」
1つの関心事はできるだけ1つのモジュールにまとめる
(構造の把握) 各モジュールの役割が把握しやすい
(再利用)
同じ処理を再利用可能になる
(変更の局所化) 変更をモジュールの内部に閉じ込める
横断的関心事
達成するために,複数のモジュールにコードを書く必要がある処理
例: 「メソッドの呼び出しをファイルに記録する」
各メソッドの先頭などにログ記録処理を追加する必要あり
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
モジュール単位「アスペクト」の役割
横断的関心事のモジュール化
アスペクト: 指定されたルールに基づいて,処理の追
加・置換などを行なう
Class Line
メソッドが呼ばれるとき
メソッド呼び出しの前に logs を呼び出す
setColor
Class Circle
setRadius
setColor
Logging
Aspect
Class Logger
logs()
開発者は,Line, Circle クラスを書き換えなくてよい
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクト指向プログラミングの利点
「いつ,何をするか」のルールによる記述
実行するタイミングが変更されやすい処理のモジュール化
に適する
例: ログを取る対象が変わっても,アスペクトの変更だけで済む
– 従来は,ログを取る処理すべてを検索してきて,変更する必要があった
クラスの機能とは関係ない処理の呼び出しをクラスか
ら除去する
クラス側は,主目的の機能だけを記述できる
 保守性,再利用性の向上
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトの用途
Development Aspect
ソフトウェア開発作業を支援するための処理
ロギング,パフォーマンス計測
Production Aspect
ソフトウェアの機能を実現するもの
ユーザ認証(アクセス管理),データベースの暗号化など
Runtime Aspect
実行時の性能改善
メモリ節約,ファイル先読み
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
研究の動向
アスペクトの有効な使い方を探る
Runtime Aspect の使い方が最初に提案された
開発者が手で最適化したコードと比較して,
半分以下のコード量で実用的なレベルの性能を達成
Production Aspect が最も活発
実際に,ソフトウェアを開発したケーススタディが多い
Development Aspect はあまり注目されていない
ロギング,パフォーマンス計測程度
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
本研究の着眼点
Development Aspect に属する関心事は頻繁に登場する
開発者はテスト用,デバッグ用などのコードをよく書く
アプリケーションドメインに依存せず発生する
通常,プログラムの複数の場所に,コードが分散する
Development Aspect のモジュール化は,
開発作業を効率よく進めるために有効である
2つの横断的関心事について,アスペクトでの実現を提案
プログラムの動的解析
オブジェクトを横断した表明
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトの複雑さ
一方で,アスペクトの問題点も指摘されている
アスペクトのクラスへの依存性
Fragile Base-Code Problem
「いつ処理を実行するか」という条件にメソッド名やクラス名を使う
 クラス側で名前を変更すると,アスペクトも修正が必要
AspectJ の場合,統合開発環境で対応
アスペクト間の干渉
Inter-aspect problem
「他のアスペクトに影響を与えるアスペクト」が問題を引き起こす
(例は次のスライド)
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトの干渉
例:
データベースコンポーネントに対して,
「メソッド呼び出しの引数を記録する」アスペクトと,
「データベースに渡す文字列引数を暗号化し,
戻り値の内容を復号化する」アスペクトを適用する
記録される文字列は,暗号化されているべきか?
Logging
A client
call
Logger
Database
Encryption
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
干渉の発見
アスペクトの干渉問題の難しさ
アスペクトの場合,必要ない限り,順序の指定をしない
実行順序の影響を受けるものは少ない
今までは,処理の実行順序を(とりあえず)指定する必要があった
 プログラムスライシングの導入によるデバッグ支援
指定した変数に影響を与えうるプログラム文の集合を抽出する
オブジェクト指向プログラミングに対応した手法を拡張
あるアスペクトのコードが,他のアスペクトからの影響を受けているか
調べることが可能
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
研究内容のまとめ
2つの Development Aspect の提案
プログラムの動的解析
オブジェクトを横断した表明
- アプリケーションに依存せず発生する横断的関心事
- モジュール性,保守性への影響を評価
プログラムスライシングによるデバッグ支援
既存のスライシング技術をアスペクト指向に拡張
アスペクト指向プログラミングの利用には重要
AspectJ プログラムに適用した結果を評価
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
論文の構成
1章: Introduction
2章: Dynamic Analysis for Program Slicing using AspectOriented Technique
文献 [2, 7]
プログラムの動的解析処理をアスペクトとして実現
3章: Modularization of Assertions Crosscutting Objects
文献 [3, 6]
表明の記述をアスペクトとして実現.
4章: Debugging Support for Aspect-Oriented Program Based
on Program Slicing and Call Graph
文献 [1, 5]
アスペクト指向プログラムに対するデバッグ支援
5章: Conclusions
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトの分類(再掲): 用途での分類
Development Aspect
ソフトウェア開発作業を支援するための処理
ロギング,パフォーマンス計測
Production Aspect
ソフトウェアの機能を実現するもの
ユーザ認証(アクセス管理),データベースの暗号化など
Runtime Aspect
実行時の性能改善
メモリ節約,ファイル先読み
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトの分類: 構造での分類
Homogeneous Aspect
多数の場所での同じ処理
システムの広範囲に渡るロギングなど
従来は,プログラム変換など,他の方法でも対応していた
Heterogeneous Aspect
クラスごとに異なる処理が,いくつかの場所に追加される
アクセス権管理など様々
ユーザ認証が必要な処理開始前に
割り込んで認証を要求
認証がないままデータベースへの
アクセスがないか監視
1つの目的のために
必要な処理が
複数ある
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトの設計方法 (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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトの設計方法 (2/2)
アクション・グラフを使った分析 †
システムの動作(アクション)の関連を分析
複数のアクションに関連したアクションをアスペクトとする
授業履修システムの分析例:
「学生が授業に登録するとき,その情報を記録する」
「学生が授業の登録を解除するとき,その情報を記録する」
登録
学生
解除
授業
記録
Elisa Baniassad and Siobhan Clarke: Theme: An Approach for Aspect-Oriented Analysis and
Design. Proceedings of ICSE 2004, pp.158-167, Edinburgh, Scotland, UK, May 2004.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
クラスとアスペクトの役割分担
アスペクトがどこまで担当するべきかについては,
未知の部分が多い
AspectJ は利便性のため,たくさんの言語要素を取り込
んでしまった
型チェックや例外処理など,Java との互換性のための制限あり
実装重視で,後付けで理論を固めている傾向が強い
最小限の機能だけを定義したアスペクト指向プログラミン
グ言語を考えようという議論が進行中
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
プログラミング言語 AspectJ
Java に,アスペクト記述のための言語要素を追加
アスペクトは,「いつ,何をするか」を指定する
「ポイントカット・アドバイス」という仕組みを導入
用語
ポイントカット: 処理を追加ないし代替する対象
例:「名前が set で始まるすべてのメソッド呼び出し」
アドバイス: ポイントカットに対する操作
例:「直前に,メソッド名を記録するという処理を追加」
AspectJ におけるアスペクトは,ポイントカットとアドバ
イスを定義するモジュール
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
ポイントカットの指定
ポイントカットはプログラム実行時の「いつ」を指定
ポイントカットは,Join Point の集合として定義される
Join Point: プログラム実行中のイベント
プログラムの実行は,Join Point の列としてモデル化される
よく使われる Join Point
メソッド呼び出し (call)
メソッドの実行 (execution)
フィールドの参照 (get)
フィールドへの代入 (set)
AspectJ の場合,クラス名,メソッド名などにワイルドカード
を許すことで「集合」を効果的に選択できる
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アドバイスの指定
ポイントカットで選択された対象(イベント)に対して
ある処理を,その直前に挿入する (before)
ある処理を,その直後に追加する (after)
ある処理で,その対象を置換する (around)
あるポイントカットの直前に処理を実行する場合:
before() : pointcut_definition { … }
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
AspectJ でのロギングの実現例
before(): call(* *.set*(..)) {
Logger.logs(thisJoinPoint.getSignature());
}
「名前が set で始まるメソッドの
呼び出し」を選択
“thisJoinPoint” は
Join Point の
コンテキスト情報を保持
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
3章: アスペクトを用いた表明の記述
表明(アサーション)とは
「特定の時点で成立しているべき条件」の記述
Java における Assert 文:
assert ( Boolean expression );
assert( true ): 正常
assert( false ): 不正な状態,例外を発生させる
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
ドキュメントとしての表明
表明は,あるコードのまとまり(ブロック,メソッドなど)
が「何をするか」を記述する
事前条件
例:
double sqrt (int x) {
assert( x >= 0 );
double result = /* 計算 */
事後条件
assert( result * result <= x );
assert( result * result > x-1 );
return result; }
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
表明の利点
明確な責任の分担を可能にする
契約による設計 (Design by Contract)
契約=メソッド単位での事前条件と事後条件
事前条件は,利用者側への要求
事後条件は,提供される機能
障害の原因がどちらにあるかを切り分けるために使われる
ソフトウェアの早期故障検出
ソフトウェアの障害が他の場所に波及する前に検出する
重要なデータなどを壊す前にプログラムを停止できる
デバッグ時,「どこで失敗したか」は有効な情報となる
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
研究の目的
モジュールを横断した表明をアスペクトで記述する
必要な言語要素と,その効果を検討
モジュールを横断した表明の例
Observer パターンに,制約を追加
従来の方法では,Observer のモジュール性を悪化させる
アスペクトを用いて書き換える
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
Motivating Example: Observer パターン
Observer
+ update();
例: 画面
attach, detach
Subject
update
+ attach(observer);
+ detach(observer);
ファイルが更新されたら
画面にも反映
ファイル
1. observer は subject に自分を登録する
2. subject は,自身が変化したとき, observer に通知する
3. observer は,不要になった時点で登録解除する
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
1 subject -to- N observers 制約
1 subject – to – N observers の制約
Observer 1つが 複数の Subject に接続されるのを禁止
Observer 1
Observer 2
接続済み
Subject 1
Subject 2
Observer は接続した相手の情報を保存していない
 Subject は,Observer が既に接続済みか検査できない
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
既存の表明による実現
Observer の接続相手を保存する subject フィー
ルドを Observer クラスに追加する
Subject.attach メソッドを実行したとき,フィールドが空
であることをチェックして,自分自身の参照をセットする
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
従来の解決方法の問題点
Observer クラスのカプセル化が破壊される
attach
Subject
Observer
must not
modify
subject
read/write
Subject クラスの attach メソッド,detach メソッドだけが
Observer のフィールドを読み書きしている
Observer クラス側からの書き込みは禁止されている
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
表明をアスペクトとして分離する
ケーススタディでは,独自の言語を使用
AspectJ で利用可能な機能のうち,表明の記述に必要
な部分だけ抽出したもの
AspectJ に変換可能
使用可能な言語要素
「メソッド呼び出し」だけをポイントカットとして選択可能
– 事前条件の評価= 「メソッド呼び出しの前」にassert文を実行,で表
現可能
– 呼び出し側,呼び出し先,引数にアクセス可能
既存のクラスに,必要なフィールド・メソッドを追加できる
表明検査・それに付随する処理の追加が可能
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトの導入後の形
Observer へのフィールド追加,
そのフィールドの操作部分をアスペクトとして分離
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトによるモジュール性の向上
関連した表明と,それに必要なメソッド,フィールドを
一箇所にまとめることができる
開発者に,それらが表明専用であることを明示し,他の
用途に誤って使われることを防ぐ
Observer パターンの例では,Observer の接続相手を保存し
た subject フィールド
モジュール間の結合度の減少,凝集度の向上
subject フィールドは,アスペクトの中で定義され,アスペクトの
中でだけ参照される
 Observer 内に定義し,Subject が参照する場合よりも良い
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトがもたらす有用性
コンテキストに依存した表明の定義が可能となる
例:信頼できないコードからの呼び出しのときだけ厳しいチェックを行
なうアスペクト
Experimental
Code
Well-tested
Component
Strict checking aspect
A component
十分テスト済みのコンポーネントに対しては,何もチェックしない
呼び出す側に依存した条件をコンポーネントから分離している
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
関連研究との組み合わせ (1/2)
動的アスペクト
実行時に,適用/無効化が可能
特定の処理を行っている間だけ有効化,といった使用が可能
インスタンスレベルアスペクト
特定のオブジェクトにだけ,アスペクトを適用する
AspectJ は,対象をクラス単位で選択する
通常は動的アスペクトとして実装される
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
関連研究との組み合わせ (2/2)
状態に基づくジョインポイントモデル
オブジェクトの状態(変数の値)を規定
状態遷移の発生に対して,処理を関連付ける
例: 「スタックが空でなくなるとき」
従来は,「Stack.push メソッドの呼び出し」を選択
この手法: 「Stack.size = 0 から Stack.size > 0 になったとき」
状態遷移に
処理を関連付ける
スタックの状態定義
Size = 0
Size > 0
メソッド呼び出し列に関わらず
状態変化だけで指定できる
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
分散システムなどへの適用可能性
環境整備は進みつつある
分散環境との親和性は報告されている
AspectJ の場合
分散システムにおけるログ取得のケーススタディが存在
分散環境向けの AspectJ の拡張の提案もなされている
「どのホストで動作しているか」といった動作条件など
AOP Alliance
異なるアスペクト指向システムの相互運用のための
「アスペクト適用」インタフェース定義プロジェクト
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
実行時オーバーヘッド
AspectJ コンパイラの最適化技術の進展
各モジュールに手でコーディングした場合と遜色ない†
ロギングの場合の実験では,最大でも,10%程度の性能劣化
手で書いたコードよりも高速になる場合も
表明で複雑な条件をチェックする場合のコスト
「条件の検査コードを実行するかどうか」が
静的に決定可能かどうかによって大きな影響を受ける
† Erik Hilsdale, Jim Hugunin: Advice Weaving in AspectJ.
Proceedings of AOSD 2004, pp.26-35, Lancaster, UK, March 2004.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
3章のまとめ
表明はソフトウェア開発における重要な道具
表明の中には,モジュールを横断するものがある
横断的な表明は,クラスのモジュール性を損なう
横断的な表明をアスペクトとして分離する
関連した表明を1箇所にまとめることが可能になる
コンテキストに依存した表明の記述など,柔軟な使い方
が可能
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
4章: プログラムスライシングによるデバッグ支援
アスペクト指向の利点
「いつ処理を実行するか」がポイントカットとして明記
される
横断的関心事を実行するルールの変更が容易となる
処理の対象となるクラスを簡単に変えられる
開発者は,必要なアスペクトを選んでコンポーネントに適
用するだけ
個々のアスペクトを作る人,クラスを作る人,クラスにアスペクト
を適用する人,クラスにさらに別のアスペクトを適用する人は,
同一人物とは限らない
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクト間の干渉 (再掲)
例: データベースコンポーネントに対して,
「メソッド呼び出しの引数を記録する」アスペクトと,
「データベースに渡す文字列引数を暗号化し,
戻り値の内容を復号化する」アスペクトを適用する
記録される文字列は,暗号化されているべきか?
Logging
A client
call
Logger
Database
Encryption
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクト間の干渉の原因
アスペクトを複数貼り付けたとき,予期せぬ動作をす
ることがある
主な要因:
アスペクトが仮定しているメソッドの呼び出し順序や,
使うデータが,他のアスペクトから影響を受けている
先ほどの例では,暗号化アスペクトが引数のデータを書き
換えるのと同時に,ロギングアスペクトが,同じデータを参
照している
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
「干渉」によって起きた問題への対応
基本的には,動作の順番を決めることで解決する
AspectJ では precedence という宣言を行う
従来のプログラミングでは,メソッド呼び出し文を並べると
きに決定している問題
人間でなければ決定できない
データベースへのメソッド呼び出しの引数の記録は,暗号
化前後,どちらがほしいか,開発者によって異なる
両方ほしい,という開発者もいるかもしれない
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
干渉の検出へのアプローチ
理想的には,アスペクトの動作順序の決定がそもそ
も必要かどうか自動チェックしてほしい
個々のアスペクトの処理内容を調べる手間がある
順序決定が必要でないことも多い
しかし,機械的な検出は困難
「同時に動くアスペクト間での干渉」といった条件付きでの検出
がいくつか研究されている
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
プログラムスライシングの適用
問題が起こってからの対処でのアプローチ
あるアスペクトが,他のアスペクトからどう影響を受けてい
るかを,機械的に調査して,開発者に提示する
プログラムスライシングとは
プログラム解析手法のひとつ
プログラム内部の依存関係を解析する
ある変数に対して,影響を与えるプログラム文の集合を
抽出する
アスペクト内の変数を基点にすると,そのアスペクトが,他のアス
ペクトから影響を受けていないか調べられる
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
プログラムスライスの定義
プログラムのある文sのある変数v(スライス基点
<s,v>)の値に“影響”を与えうる文の集合
影響 = 代入-参照 関係, if 文など制御関係
プログラム文を頂点,依存関係を辺としたグラフ探索
1:
2:
3:
4:
5:
6:
a = 5;
b = a + a;
if (b > 0) {
c = a;
}
d = b;
a
b
基点< 6, b >
制御
1:
2:
3:
4:
5:
6:
a = 5;
b = a + a;
if (b > 0) {
c = a;
}
d = b;
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
a
b
スライス計算に必要な情報
データ依存関係
ローカル変数の 代入 → 参照
フィールド(メンバ変数)の 代入 → 参照
制御依存関係
実行制御文の条件節 → 制御される文
メソッド呼び出し関係
メソッド呼び出し文 → 呼び出されるメソッドの文
メソッド呼び出し文の実引数 → 呼び出されるメソッドの仮引数
アスペクトの連動位置 → 動作するアスペクト
アスペクトの連動位置 → アスペクトが参照する実行時点情報
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクト指向のための拡張
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()
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
動的情報の利用
目的をデバッグに限定
実行が失敗するテストケースが特定されている状態を想
定
動的(実行時)情報 が利用可能
オブジェクトの区別,動的束縛の解決によってコード量を
減らす
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
スライスツールの実装
統合開発環境 Eclipse への統合
プラグイン形式で機能を追加できる
開発者がエディタ上でそのまま利用できる
コンパイル時にソースコード情報を収集
静的依存情報の収集
実行時情報が存在すれば読み込んで利用
動的解析モジュールを付加して実行しておく必要あり
実行時情報がなければ静的情報だけでスライス計算
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
プロトタイプのスクリーンショット
スライス基点をエディタ上で選択
コンパイル時に静的情報収集
スライス結果を
エディタ上に出力
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
適用実験
1. AspectJ のサンプルコードに対する適用
5つのデザインパターンの実装を対象
従来ツールで,どのくらい依存関係の追跡にコストがか
かるか評価
2. 学生12人によるデバッグ実験
AspectJ プログラムを対象にしたデバッグ作業
4つのアスペクトのうち1つが,他の1つの動作を阻害
12人中,6人が,プログラムスライスの情報を使用
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
評価 (1/2)
依存関係の追跡作業は,コストが高い
従来のツールは,他のアスペクトが「どこで動くか」を表示
するだけ
影響を与えるようなアスペクトかどうかは,コードを読まないと分
からない
スライシングでは,影響を与えるかどうかも同時に与えられる
– 「影響を与えない」ところは最初から無視できる
アスペクトは,通常,複数のファイルに定義されるので,
ファイルをまたいだ依存関係を接続していく必要がある
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
評価 (2/2)
バグの原因特定について
作業に取り掛かる段階で,コードを読む指針となる
「原因の候補」として目をつけた点に対して,その部分が
スライスに含まれているかどうかで,候補を絞り込める
バグの修正について
変更結果が他のアスペクトに影響を及ぼさないことを確
認するには,他のアスペクトも読まないといけない
 スライスだけで,作業時間を短縮できるとは限らない
影響波及解析手法との組み合わせが考えられる†
† 四野見,玉井: アスペクト指向における織り込みによる影響波及解析.
プログラミングおよびプログラミング言語ワークショップ(PPL2005) 論文集.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
4章のまとめ
アスペクト指向プログラムのデバッグ支援
プログラムスライシングの適用
従来手法に,「アスペクト呼び出し」を追加
アスペクトの動作を,メソッド呼び出しと同様の形式で扱う
静的情報,実行時情報を組み合わせた開発者の支援
評価実験の結果
スライシングは,アスペクトによる振る舞いの変化を効果
的に示すことができる
アスペクトによって引き起こされた問題の特定に有効
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクト指向プログラムの品質
モジュール性などを客観的に評価する指標は?
アスペクトの導入の影響を評価したい
オブジェクト指向での指標には,アスペクトに関する定義がない
CKメトリクスの拡張†
「クラス」 → 「クラスまたはアスペクト」
結合度: Coupling Between Objects の拡張
1つのクラスまたはアスペクト中に登場する他のクラス,アスペクトの数
凝集度: Lack of Cohesion の拡張
1つのクラスあるいはアスペクト中のメソッド単位で,お互いにメンバー変数を
まったく共有しないようなペアの個数(大きいほど悪い)
† 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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
新たな評価尺度の導入
新たな尺度: 関心事の分散度合い
1つの関心事は少数のモジュールで実現されるべき
提案は複数
1つの関心事を実装に関わる
クラス・アスペクトの数
+それらを直接参照する
クラス・アスペクトの数
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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
品質の評価ケーススタディ
シミュレータに対する変更操作†
オブジェクト指向システムに比べ,結合度は大きく低下
1つのメソッドから呼び出されるメソッドの数は増加する
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. 2004.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
むすび
アスペクト指向プログラミング
「横断的関心事の分離」を提案
モジュール単位「アスペクト」の導入
アスペクトの用途: Development / Production / Runtime Aspect
Development Aspect に属する関心事のモジュール化を提案
Development Aspect は,ソフトウェア開発作業全般で登場するため重要
プログラムの動的解析
オブジェクトを横断した表明
Production / Runtime Aspect での有用性は,他の研究者によって
示されている
横断的関心事のモジュール化にアスペクト指向プログラミングは有効
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクト指向のもたらす複雑さへの対処
プログラムスライシングによるデバッグ支援を実現
プログラムスライシングをアスペクト指向向けに拡張
変数の値にアスペクトが影響を与えている場合,それを提示できる
プログラムスライシングに基づく他の解析手法にも同様の拡
張は適用可能
影響波及解析は既に実現されている
プログラム解析手法を使うことで,アスペクト指向プログラミン
グの利用が容易となる
問題の発生を予測する方法の研究はまだ途上
型推論,プロセス代数など,理論的側面からの研究
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
今後の展望
アスペクト指向プログラミングから
アスペクト指向ソフトウェア開発へ
Early Aspects
要求間の依存関係の整理
システムの広範囲に影響を与える要求の発見
Aspect-Oriented Modeling
関心事のモデリング
アスペクト指向プログラムの設計
アスペクトのためのモデル記述言語
Aspect-Oriented Programming
横断的関心事のモジュール化
アスペクトのテスト方法
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクト指向の影響
横断的関心事のクラスからの分離
 以前よりも単一の部品は単機能に近づく
部品のモジュール性,凝集度,再利用性は向上
コンポーネント間の結合が増加
コンポーネントの結合を管理する必要性が増大
クラスの場合,「メソッド呼び出し」で明示的に結合されていた
アスペクトの場合,いつ動作するかは,結合対象のプログラムが
決まるまで分からない
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
研究課題
関心事の整理/管理
モデルとソースコードの関連付け
作ったものが,実際にモデルを反映しているか検査
ソフトウェアから,人間が「読める」情報を抽出する
関心事間の関係の可視化
1つのアスペクトが及ぼす影響の可視化は研究されているが,
複数のアスペクトの関連の可視化は実現されていない
広範囲に影響を与えるアスペクトの振る舞いの可視化も困難
大規模ソフトウェアの抽象化
ソフトウェアの適切な単位への分割
「関心事」ごとに,対応するソフトウェアの要素を発見する
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトの可視化
ある1つのアスペクトに対して,関連するクラスを表示
した場合
Logging
A client
A client
call
Logger
Database
call
Database
Encryption
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
終
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
補足資料
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
AOP一般
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
「横断的関心事」の問題
横断的関心事: 従来のモジュールが対応できない
関心事
他のモジュールに少しずつ変更を加える必要あり
例: 名前が set で始まるメソッドの呼び出しを記録
Class Line
setColor
各メソッドに,呼び出し文が必要
Logger.logs(methodName);
Class Logger
logs()
Class Circle
setRadius
setColor
一貫した実装の維持が困難
 保守性を悪化させる
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクト指向の実現方法
従来のモジュール単位ではまとめられなかったものを,
アスペクトにどのようにまとめるか?
できるだけモジュール間の依存関係を減らしたい
コンパイラがプログラムを組み立てるルールが必要
 Join Point Model の導入
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
Join Point Model
Join Point: プログラム中の特定の実行時点
プログラムの実行を「Join Point の列」としてとらえる
メソッド呼び出し,フィールドの参照,更新,...
Join Point の決め方が言語の特性を決める
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトの記述方法
アスペクト = 「いつ,何をするか」 で処理を記述
pointcut: イベント(join point)の集合
advice: pointcut に対応させる手続き
Pointcut の直前に処理を追加する
Pointcut の直後に処理を追加する
Pointcut の代替の処理を実行する(本来の処理を回避する)
advice の呼び出しは,コンパイラ・インタプリタが自動で埋め込む
メソッド呼び出しが,対象のプログラム側に出現しない
アスペクトは,他のクラスにメンバーを追加してよい
クラス階層で関係のないクラスにも同じメソッドをまとめて定義できる
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
「図形の移動が起きたら画面を更新」の例
「図形の移動」というイベントは
メソッド呼び出し
Line.setP1, Line.setP2,
Point.setX … である,と定義
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
表明
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトを用いた表明の書き換え
事前条件,事後条件は,アスペクトとして書きやすい
「メソッド呼び出しの直前と直後に条件を検査」という
簡潔なルールによって記述が可能
AspectJ による実装例
pointcut sqrt_call(int x): call(double aClass.sqrt(int)) && args(x);
before(int x): sqrt_call(int x) {
assert( x >= 0 );
}
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
言語要素の検討: Join point
Join Point Model
AspectJ の Join Point Model を採用
AspectJ のモデルはメソッド呼び出しなど,実行時のイベントに基づく
「メソッド呼び出しの前後」が表明の検査が一番多いタイミング
Pointcut: Join point の選択に使える述語
call pointcut が主体
Context exposure も重要
Context exposure: 呼び出しなどの時点でのオブジェクト,引数へのアクセ
スを提供する仕組み
AspectJ における this, target, args pointcuts
制御フローの cflow pointcut などの効果の検討は今後の課題
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アドバイスとインタータイプ宣言
Advice
assert 文を書くのが主な目的
1つの呼び出しに対して,事前・事後条件がペアで付く
両方をペアで書けるように言語を用意
AspectJ では before/after と個別で実現される
インタータイプ宣言
表明の記述に必要なメソッド・フィールドの定義
オブジェクトに,中間状態の保存用のフィールドの追加
データ集計用のメソッドの追加
表明 「専用」 であることが明示される
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
Aspect for Observer
定義の開始
Advice for Subject.attach (次のスライド)
Advice for Subject.detach (省略)
インタータイプ
宣言
(AspectJ 形式)
定義の終了
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
Advice for Subject.attach
The beginning of
advice definition
Pointcut declaration
this calls
target.method(args)
Preconditions
(before)
code block executed after the postconditions are checked.
The end of
advice definition
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトの導入によって生じる弱点
複数のコンポーネントの表明が,1つのアスペクトにな
る
1つのコンポーネントの表明が,複数のアスペクトに
分散する
アスペクトは,表明の追加だけが許されている
存在を知らなくても,テスト段階で検知可能
アスペクトの存在は,ツール等で検知可能
横断的な表明をすべて検知するよりも容易
– クラス名など,必要な情報がアスペクト内に提供されているため
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
動的解析
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクト指向での動的解析の実現
プログラムの動的解析とは
プログラム解析技術に必要な情報を,プログラムの実行
時に取り出すこと
メソッド呼び出しの発生順序
変数の代入・参照の発生順序
特定のメソッドの実行回数のカウント
オブジェクトの確保した個数
メソッドの実行時間,…
多数のメソッドに対して,解析用の処理を追加する必要
がある
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
従来の実現法との比較
通常は,プログラム変換技術を用いる
メタプログラミング技術が必要
構文のパース,構文木上での変換
たとえば,メソッドの先頭にロギング用のコードを追加する
実行したい処理内容と,実装(変換ルール)に隔たりが
大きい
アスペクト指向による実現
処理内容を明確に表現可能
メタプログラミングの知識がほとんど不要
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
ケーススタディ
プログラムスライシングに必要な動的解析モジュール
を AspectJ で実装
フィールド参照・代入,メソッド呼び出しで,実際にどのオ
ブジェクトが使われたか履歴を記録
イベントを取得するアスペクト + 解析用クラス + 結果
の圧縮処理クラス
合計で約1000行程度のモジュール群として実装
対象プログラムの一部としてコンパイルされるので,テスト
環境の構築やデバッグ作業が容易
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
他の方法と比べた場合
Java コンパイラのカスタマイズ
最適化したコードを生成するといった実装も(努力すれば)可能
そのかわり,実装に必要なコストが高い
プリプロセッサによる実装
やりたいことを,構文木の変換処理として書き下す必要あり
Java Virtual Machine Debugger Interface
JVM に付随するデバッガを作るためのインタフェースの利用
スレッド制御やメモリ確保などの分析も可能
そのかわり,JVM の動作に関する知識が必要
JVM が機能を提供しない場合もある
これ自身のテスト・デバッグが困難
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
プログラムスライシング
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
実験(1) ツールの適用
適用対象
AspectJ サンプルコード 5種類
プログラムの実行時情報解析アスペクト
各サンプルコードのサイズは平均500行
実験内容
サンプルコードを実行し,その結果に対してプログラムスラ
イスを計算
従来のツールを用いた依存関係の追跡との定性的比較
AJDE: どこでアスペクトが動作するかをマーカーで表示する
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
実験(2) 開発への影響の評価
大学院の授業での利用
大学院生(修士課程) 12名
授業で Java 使用経験あり,AspectJ は使用経験なし
開発環境: Eclipse + AspectJ plug-in
実験の手順
Eclipse についての解説
Eclipse を用いた Javaプログラムのデバッグ演習(事前課題1)
AspectJ についての解説
Eclipse を用いた AspectJ プログラミング演習(事前課題2)
Eclipse を用いた AspectJ プログラムのデバッグ(実験)
ランダムで選んだ 半数,6名 にプログラムスライスを渡す
– 時間の都合上,印刷物で提供
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
対象プログラムの概要
対象: 式評価プログラム
入出力例: (+ 4 3 (* 2 7 ) (* 2 7) )  35
一部のノードは共有されていることがある
クラス5つ(式構造クラス),アスペクト4つ,合計340行
処理経過の文字列出力
計算結果の共有 (同じ式が2度目以降は計算を飛ばす)
式のグラフ表現上でのループ検出
評価が終了したグラフの接続解除
アスペクトの干渉によって正しい結果が出力できない
原因: 計算を飛ばすアスペクトによって,文字列出力の処理もスキップされる
プログラムスライス
文字列出力アスペクトの,文字列を格納している変数がスライス基点
他3つのアスペクトのうち,計算結果の共有アスペクトだけが影響する
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
アスペクトの干渉
値の要求
計算結果
記録/共有
アスペクト
ノード
ノード
計算結果
途中を出力するアスペクト
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
提供したスライスの一部
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();
}
既に計算済みの場合は
計算を省略する
この計算省略機能が,
計算経過の文字列出力も
飛ばすことがバグの原因
計算が完全に終了した
時点で,フラグをクリア
出力結果には関係ないので
スライスに含まれない
}
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
実験の提出物
提出物 (事前の2回の演習課題,実験用の演習)
問題の原因
修正方針
変更したソースコード
作業に要した時間
スライスを使用した感想
提出した結果を分析
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
実験結果
Javaプログラム課題の作業時間との順位相関
相関係数 r = 0.54
AspectJ プログラミングでは Java に関するプログラミング能力が重
要な要素となる
スライス使用の効果
スライス使用者のほうが値は平均時間が短い
作業時間の平均 (単位: 分)
グループ 事前課題1 事前課題2 実験
(Java)
(AspectJ) (AspectJ)
1
150
186
200
2
200
210
190 (スライス使用)
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
「依存関係がなくなる」コードの例
開発者が意識する依存関係
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();
}
}
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
品質/メトリクス
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
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.
値が高いほど悪い状態を示す(他のメトリクスと共通)
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
ダウンロード

例 - Software Engineering Laboratory