アスペクトを用いた表明の記述

Assertion with Aspect
石尾隆†，神谷年洋‡，
楠本真二† ，井上克郎†
†大阪大学大学院情報科学研究科
‡ 科学技術振興機構さきがけ
{t-isio, kamiya, kusumoto, inoue}@ist.osaka-u.ac.jp
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
1
論文の出典
Software-engineering Properties of
Languages for Aspect-Technologies (SPLAT)
AOSD2004併設． Lancaster, UK, March 2004.
ワークショップのテーマ:
ソフトウェアの品質とアスペクト指向技術の関係
アスペクト指向技術の導入で
何が良くなり，何が悪くなるのか
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
2
議論する品質
Comprehensibility
設計，プログラムの目的（要求との対応など）の理解
Predictability
プログラムがどのように振舞うかの理解
Evolvability
将来の変更に対して適切に対応できるか
Semantic Interactions
導入しようとしている技術が，既存の技術とどのように相
互作用するか
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
3
論文の概要
表明（アサーション）をアスペクトとして記述したらどうなるか
論文は言語要素の提案を含むが，本発表では省略
表明がもたらす効果
プログラム理解のための情報提供
安全性の向上
表明をアスペクトとして記述する効果
既存の表明で記述しにくい性質の記述が可能となる
追加・削除・変更が容易となる
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
4
発表の流れ
論文の出典
表明とは
「普通の表明」の品質への影響
表明をアスペクトとして記述する
アスペクト化による品質への影響
関連研究の紹介
Moxa，表明記述言語JMLへのアスペクトの導入
まとめ
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
5
表明 (assertion) とは
特定の言語要素が「何をするのか」
関数，メソッド，プログラム文などに対して記述
その言語要素が実行される直前（または実行直後）に
成立していなくてはならない条件
実現方法とは無関係
例: 「sort 関数の終了時，配列の中身は昇順で整列」
「この関数は quick sort を使う」とは書かない
対応する実行時点ごとに異なる呼び名
メソッド実行の前後: 事前条件，事後条件
すべてのメソッドの実行前後: クラス不変条件
ループ文実行中: ループ不変条件
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
6
表明の用途
早期の故障検出
表明の違反＝プログラムが想定外の状態である
障害が他の場所に波及する前に検出する
障害範囲の切り分けによる原因の早期解明
責任の分担
ある一定範囲を表明で区切って責任を分担
各時点でどこまで処理が進んでいるべきか明確化
曖昧さのない分担が可能
契約による設計
手続きの事前条件を満たすのは利用側の責任
手続きの事後条件を満たすのは手続き側の責任
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
7
利用可能な記述手段
表明文（assert 文）
条件検査を行うプログラム文
assert(条件式);
条件式 = true なら何もしない， false ならプログラム停止
Java や C++ など，一般的な言語で利用可能
事前条件，事後条件，クラス不変条件
Eiffel では言語としてサポート
Java，C++ では JML, Larch などの支援ツール
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
8
表明の品質への影響
Predictability の向上
その言語要素が何をしているかを理解する手がかり
記述した性質に抵触するようなプログラムの誤りを検出
Evolvability は悪化する可能性もあり
詳細すぎる表明が，コンポーネントの再利用を阻害する
設計変更に対して，表明の修正が必要な場合が出てくる
リファクタリング時のバグ混入の防止には役立つ
Comprehensibility, Semantic Interactions には特に影
響しない
仕組みとして単純で，問題となるような動作を起こすことはない
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
9
アスペクトとして書くべき表明とは
(1) コンテキストに依存した表明
コンテキスト = コンポーネント（クラスなど）が利用される場面
コンポーネントの利用者側に依存した条件
例：長さ1以上の文字列しか格納しない List オブジェクト
特定のテストケースに対する強い制約の記述
(2) 複数のモジュールに分散してしまう表明
「関連」に対する制約
例: Observer パターンの特殊形
「Observer と Subject とは，1対1対応しなければならない
(1つの Subject に複数の Observer があってはならず，
1つの Observer に複数の Subject があってはならない) 」
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
10
(1) コンテキストに依存した表明
コンポーネント利用者に合わせた表明のカスタマイズ
A(持っているもの): List of Object
B(使いたいもの): List of 長さ１以上の String
A と B を継承関係で作成するのは設計上問題
A と B は Subtype 関係にない
型の指定だけなら，総称型(Generics)で対応する問題
A を内部的に使う B を実装するのは手間
A に適用できる操作が B には適用できなくなる
表明で，“少し安全に” A を使う
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
11
AspectJ での表明記述の一部
適用対象 = UserClass.stringList フィールド
UserClass からの stringList.add の呼び出しで，
文字列かどうか，その長さもチェック
UserClass 以外からアクセスされた場合への対応は別途必要
before (UserClass user, List list, Object added):
call(* List.add(..)) &&
this(user) &&
target(list) &&
if(list == user.stringList) &&
args(added)
{
assert (added instanceof String) &&
(((String)added).length() > 0);
}
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
12
アスペクトを用いる利点
コンテキストごとに表明を整理できる
分離しておいたほうが変更が容易
手軽に表明の導入が可能
コンテキストごとに専用のクラスが増加することを避け
られる
「安全性を向上するためのクラス」が増えすぎるのは設計
上うれしくない
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
13
(2) 複数のモジュールに分散した表明
Observer パターンの特殊形の例
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
14
Observer パターンへの制約付加
付加する制約: Observer と Subject を1対1対応させる
observer1
observer2
接続済
subject1
subject2
新たな接続を禁止
Subject は接続している Observer を知っている
別の Observer が接続してきても，容易に確認できる
Observer の，他の Subject への接続をどう防止するか？
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
15
従来の解決方法
Observer がどの Subject へ接続しているかという情報を
Subject からアクセス可能にする必要あり
Subject は「誰とも接続していない」 Observer だけ受け入れる
Subject は，接続してきた Observer の内部状態をチェックし，接
続したら Observer の内部状態を変更する
表明の検査のために実装が影響されてしまっている
制約に関する表明，実装が Observer/Subject に分散
Observer の状態に関する表明が分散
何のための表明であるかが明確でなくなる
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
16
アスペクトでの解決
AspectJ を用いた記述例
Observer がどの Subject に接続したかの状態の保存・チェックをアスペクトに取り込む
Subject Observer.connected = null;
before(Observer observer):
execution(Subject.attach(Observer)) &&
args(observer) {
assert (observer.connected == null);
}
after(Observer observer, Subject subject):
execution(Subject.attach(Observer)) &&
this(subject) && args(observer) {
observer.connected = subject;
}
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
17
アスペクトを用いた解決の利点
複数のオブジェクトを横断した表明のモジュール化
複数モジュールに分散させるより，見通しが良い
他の制約と「混ざらない」ため，変更や除去が容易
コンテキストに依存した表明のときと同様
表明記述用の特殊な実装を明示的に記述しておける
先の例では Observer が接続した Subject の参照管理
表明検査「専用」インタフェースを，他のモジュールに使わせない
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
18
アスペクトの導入による品質への影響
Predictability を強化
従来は書きにくかった表明への対応
コンテキストに応じた性質の書き分け
複数のモジュールを横断した性質を書ける
Evolvability もサポート
コンポーネント外部からの柔軟な表明の追加・削除
デバッグ用の一時的な表明の追加
汎用的なコンポーネントの安全性向上
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
19
関連研究: Moxa
契約による設計を支援するアスペクト指向的振舞イ
ンターフェース記述言語Moxa.
山田聖（JAIST），渡部卓雄（東工大）
出典: 情報処理学会第 52 回プログラミング研究会
(SIGPRO)
Java 用の表明記述言語 JML に，「表明アスペクト」モ
ジュールを追加
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
20
Moxa のアプローチ
メソッドごとに表明を書くのではなく，表明ごとにメソッ
ドをリストする
従来
Method 1
表明A
表明B
Moxa
表明A
表明A
Method 2
Method 3
表明B
Method 1
Method 2
表明B
表明A
表明C
Method 3
表明C
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
21
Moxa のモジュール機構の特徴
クラスと独立して表明を記述できる
主目的は，クラス内の表明の整理
表明が主体となった記述
同じ性質を持っているメソッドを一覧する場合に便利
初期化用メソッド，初期化が終了したら使えるメソッド，終了処
理用メソッド… のようにメソッドを分類するなど
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
22
まとめ
表明が元々持っていた影響
表明は Predictability を向上させる
コードが何をしているかを説明する
誤った振る舞いをしていれば，検出する
表明は Evolvability を悪化させることがある
詳細すぎる表明は，再利用性などにも悪影響
アスペクトが，表明の能力を強化する
Predictability を強化
コンテキストに応じた性質を書き分けておける
複数のモジュールを横断した性質を書ける
Evolvability もサポート
追加や削除が容易で，再利用性への悪影響も防ぎやすい
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
23
補足資料
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
24
表明の悪影響は？
表明の記述をアスペクトに分離することで，定義が分散して
かえって理解しにくくなる？
コンテキスト依存の表明は，コンポーネント本来の表明 + 「そのコン
テキスト依存の表明」だけ見つけられれば良い
利用場面に対応するクラスなどと一緒に配置することで管理が可能
複数オブジェクトを横断した表明は，元々，書きにくいものも存在
副作用のある表明
表明自体が何らかの作用を持つと，混乱を招く
プログラミング言語／コンパイラによる保護の活用
C++ における const キーワードなど
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
25
Moxa の特徴
クラス内の表明を整理する
表明の数が減少する
同じ性質を持ったメソッドを一覧できる
初期化用メソッド，初期化が終了したら使えるメソッド，終了処
理用メソッド… のようにメソッドを分類するなど
クラス間の関係も（たぶん）書ける
表明の記述に特化している利点
副作用の問題などが発生しにくい
表明記述用の便利な関数・演算子が使える
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
26
提案していた言語機構
assert(expr) の，expr の部分の関数の実装をアスペクトに
追い出す
// FileIsOpen の実装は誰かアスペクトが提供してくれる
// 複数提供された場合は全部の AND をとる
assert(FileIsOpen());
cflow 述語を使う
// この文は，Foo.foo から呼ばれたときだけ通過できる
assert ( cflow ( Foo.foo() ) );
AspectJ + Annotation などで実現可能な領域に近い
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
27
安全性と再利用性
表明は安全性を高める
安全のためには書きたい
条件を書きすぎてしまうと再利用しにくい
コンポーネントの２種類の制約
コンポーネント本来の制約
例: このList には「任意の null でないオブジェクトを格納する」
一般的なオブジェクトに適用できるので，再利用が容易
アプリケーションが必要とする「最小限の」機能
例: このListには「長さ1以上の文字列を格納する」
誤ったオブジェクトを格納する可能性はなくなる
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
28
「安全な再利用」のための制限
Behavioral Subtyping
あるオブジェクトが，別のオブジェクトの代替となる条件
Strong
（拡張ではない）
Original
Component
require
(事前条件)
Weak
Specialized
Implementation
Simple
Implementation
Weak
Extension
Behavioral Subtyping
Generalization
ensure (事後条件)
Strong
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
29

Download Report