2004年にはアスペクト指向要求工学のワークショップが開催される[1]など、アスペクト指向開発のための要求工学手法が注目されている。今回は、アスペクト指向開発における要求工学AORE(Aspect Oriented Requirements Engineering)がどういうものなのかについて紹介しよう。
アスペクト指向開発とは
アスペクト指向開発は、オブジェクト指向開発における次のような問題を解決するために提案された。
【分散(scatter)問題】
オブジェクトに機能が隠蔽されるため、同様の記述が複数のオブジェクトに分散する
【友連れ(tangle)問題】
オブジェクトの中で複数の機能が同時に混在して記述される
このため、複数のオブジェクトに対して横断的に出現する共通的な関心事を抽出して独立に記述しておき、必要に応じて参照するという考え方としてアスペクト指向が提案された。
このように共通的な関心事(アスペクト)を分離することをSoC(Separation of Concerns)という[2]。
SoCでは、できるだけ機能を単純化することが求められる。これによって、機能定義の重複を削減することができる。このような考え方は、ソフトウェア工学の基本原理の一つでもある。つまり機能の定義は1箇所に限定しておき必要な箇所で参照するのである。
なぜアスペクト指向要求工学が必要なのか?
この理由は以下の3点に整理できるだろう[3]。
共通関心事を識別する必要がある
そうしないと、複数個所に同じ要求が分散して重複記述されるために変更時の影響範囲が特定できないだけでなく、理解容易性も低下する。
要求のモジュール化
共通関心事を独立に記述することで要求のモジュール化が可能になり、理解容易性を向上できる。
影響範囲の明確化と限定
アスペクトを独立に記述し参照元との関係を明示的に記述することで、アスペクトの影響範囲を限定できる。
クロスカット要求とは
要求Bの構成要素が要求Aを考慮しないと満足できないとき、要求Aが要求Bをクロスカットするという。この場合、要求Aがクロスカット要求になる[2]。
クロスカット要求の形態は、オブジェクトの分散問題と友連れ問題と同様に、分散要求と友連れ要求の2つがある(図1)。
図1 クロスカット形態
分散要求
同じ要求が異なる複数の要求に散在する。このとき、複数の要求で必要とされる要求がクロスカット要求になる。
友連れ要求
ある要求が、複数の性質や機能要求を同時に必要とする。このとき同時に必要とされるクロスカット要求が友連れ要求になる。
クロスカット要求の例(表1)
要求 | 要求 | クロスカット要求 |
---|---|---|
応答時間 | システムはプラットフォームXと相互接続する |
10秒以内にすべてのシステム応答が完了する |
セキュリティ | 要求された場合、ユーザー名、生年月日、住所を表示する |
認証されたユーザーだけに個人情報を表示する |
例外 | システムが指定されたftpサイトからコンポーネントをダウンロードする |
指定された時間内にftpミラーサイトとの接続が出来ない場合、ダウンロードプロセスを中断する |
(例1)応答時間要求
R2は、R1の相互接続時の応答時間に関する制約条件を与えるクロスカット要求の例である。
R1. システムはプラットフォームXと相互接続する
R2. 10秒以内にすべてのシステム応答が完了する
(例2)セキュリティ要求
R4は、R3を実行するときの事前条件を与えるクロスカット要求の例である。
R3. 要求された場合、ユーザー名、生年月日、住所を表示する
R4. 認証されたユーザーだけに個人情報を表示する
(例3)例外要求
R6は、R5を実行するときの制約条件を与えるクロスカット要求の例である。
R5. システムが指定されたftpサイトからコンポーネントをダウンロードする
R6. 指定された時間内にftpミラーサイトとの接続ができない場合、ダウンロードプロセスを中断する
クロスカット要求の記述形態
クロスカット要求をどのように記述すればいいだろうか?以下では、銀行口座処理を例にこの問題を考えよう[4]。
簡単のために、銀行口座の預金への利子の追加処理と口座からの預金の引出処理を考える。これらの処理では、トランザクションの完了確認処理とトランザクションの履歴を記録する処理が必要になる。つまり処理完了確認と処理履歴登録の2つがクロスカット要求である。図2に示すように、以下の3つの記述形態が考えられる。
図2 クロスカット要求の構成方法
分散記述
2つのクロスカット要求を利子処理と引出処理の中に分散して埋め込む方法である。
この方法では、クロスカット要求を分離できないので、記述が重複してしまいモジュール化できていないという問題がある。
暗黙的関心記述
この方法ではクロスカット要求としての関心事を独立に定義し、参照もとの要求からクロスカット要求への関係は定義しているが、クロスカット要求から利子処理と引出処理への関係が暗黙的であるため、クロスカット要求の変更時の影響範囲を追跡しにくいという問題がある。
明示的関心記述
この方法ではクロスカット要求としての関心事を独立に定義するだけでなく、参照もとの要求とクロスカット要求との関係を双方向で定義する。このためクロスカット要求から利子処理と引出処理への関係が明示的であるため、クロスカット要求の変更時の影響範囲を特定できるという特徴がある。
そういう意味では、クロスカット要求の記述は、要求間の共通性を分析し、記述の独立性を高めると同時に追跡性を管理する手法であるといえる。
アスペクト指向要求分析プロセス
アスペクト指向要求工学のプロセスには、表2に示すように次の4ステップがある[4]。
ステップ | 説明 |
---|---|
識別 | 要求の中からクロスカット要求を探索してアスペクトを識別する。 |
獲得 | 各要求が一つだけの関心事に対応することを確認する。 |
合成 | クロスカット要求が影響を与える要求の範囲を明示的に特定する。つまりクロスカット要求を参照する全ての要求を列挙する。 |
分析 | アスペクトとしての関心事と他の要求との矛盾がないことや一貫性を確認する。 |
識別
要求の中からクロスカット要求を探索してアスペクトを識別する。
アスペクトを探すときには、セキュリティ、一貫性、信頼性、性能などの品質特性や非機能要求を表すような言葉に着目すると良い。
獲得
各要求が一つだけの関心事に対応することを確認する。たとえば、暗黙的関心記述で示したように、分散記述されている関心事を独立させるのである。
合成
クロスカット要求が影響を与える要求の範囲を明示的に特定する。つまりクロスカット要求を参照するすべての要求を列挙する。たとえば、明示的関心記述で示したように、分離された関心事が参照元の要求に対応することを確認する。
分析
アスペクトとしての関心事と他の要求との矛盾がないことや一貫性を確認する。
AOREの特徴[3]
AOREの特徴をまとめると、次のようになる(表3)。
ステップ | 説明 |
---|---|
抽象化 | 共通関心事の詳細を隠蔽して抽象化することで、要求を複数個所に分散することなく一意に記述できる。 |
モジュール化 | 共通関心事を分離独立させておくことで、影響範囲を限定できる。 |
一貫性 | 共通関心事と他の要求との相互関係を明示的に記述できるようになるのでその一貫性を系統的に保証できる。 |
抽象化
共通関心事の詳細を隠蔽して抽象化することで、要求を複数個所に分散することなく一意に記述できる。
モジュール化
共通関心事を分離独立させておくことで、影響範囲を限定できる。
一貫性
共通関心事と他の要求との相互関係を明示的に記述できるようになるのでその一貫性を系統的に保証できる。
関連する要求工学手法
AOREは従来の要求工学を補完する技術であって、ゴール指向要求工学やシナリオ指向要求工学などと組み合わせることができる[5]。
たとえば、ゴール指向手法でも、関心事を扱うことができるが、すべてを同列に扱うため組合せが系統的に支援されていないこと、手段目的分析がアクタごとに局所的にしかできないことなどの問題がある。そこで、ゴール指向で抽出したアクタとしてのステークホルダのニーズをAOREでモジュール化して組み合わせることができる。
シナリオ指向要求工学では、機能シナリオをユースケースとして識別すると、それに対する品質特性として、たとえば性能やセキュリティをアスペクトとして識別することができる。
まとめ
今回はアスペクト指向要求工学について説明した。アスペクト指向もオブジェクト指向と同様にはじめはプログラミング技法として提案され、アーキテクチャ設計法、要求工学手法へと下流から上流に向けて研究が進んできた。そういう意味でアスペクト指向要求工学はまだ研究の初期段階にある。今後アスペクト指向要求工学の研究が進展することを期待したい。
■参考文献
- [1] Early Aspects 2004: Aspect-Oriented Requirements Engineering and Architecture Design Workshop, http://www.early-aspects.net/events/oopsla04ws
- [2] Lars Rosenhainer, Identifying Crosscutting Concerns in Requirements Specifications, trese.cs.utwente.nl/workshops/oopsla-early-aspects-2004/Papers/Rosenhainer.pdf
- [3] Awais Rashid, Aspect-Oriented Requirements Engineering,www.resg.org.uk/EAslides/Awais RashidSlides.pdf
- [4] Baniassad,E.,etal,Discovering Early Aspects,IEEE Software,Jan./Feb.,pp.61-70,2006.
- [5]Safoora Shakil Khan, Muhammad Jaffar-ur- Rehman, A Survey on Early Separation of Concerns,Proceedings of the 12th Asia-Pacific Software Engineering Conference (APSEC'05),Pages: 776 - 782 , 2005
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要