本連載36回ではアスペクト指向要求工学を紹介した[1]。連載36回では、
「ゴール指向手法でも関心事を扱うことができるが、すべてを同列に扱うため組合せが系統的に支援されていないこと、手段目的分析がアクタごとに局所的にしかできないことなどの問題がある。」
ことを指摘していた。また、
「ゴール指向で抽出したアクタとしてのステークホルダのニーズを、AOREでモジュール化して組み合わせることができる。」
ことを示唆していた。しかし、具体的な対応付けについては紹介していなかった。
今回は、ゴール指向要求工学とアスペクト指向要求工学の関係について具体的に紹介し、アクタ関係分析によるアスペクト指向要求分析についても述べよう。
アスペクト指向とは
アスペクト指向は、複数の場面に対して横断的に出現する共通的な関心事を抽出して独立に記述しておき、必要に応じて参照するという考え方に基づいている。このように共通的な関心事(アスペクト)を分離することをSoC(Separation of Concerns)という[2]。
SoCでは、できるだけ要求を単純化することが求められる。これによって、要求定義の重複を削減することができる。このような考え方は、ソフトウェア工学の基本原理の一つでもある。つまり定義は1箇所に限定しておき、必要な箇所で参照するのである。
アスペクト要求の構成要素
以下では、ゴール指向によるアスペクト要求の記述法を文献[3]を参考にして示そう(表1)。
構成要素 | 説明 | 分類 |
アスペクト要求 | ソフトゴール |
Why |
---|---|---|
アドバイス | アドバイス・タスク アスペクト要求が提供するサービス内容 |
What |
ジョインポイント | ゴール、タスク アスペクト要求と関係する構成要素 |
Where |
ポイントカット | 貢献関係 ジョインポイントの集合 |
Mapping |
織り込み手順 | サービスをいつどのように提供するかを示す |
When How |
アスペクト要求
ソフトゴールによりアスペクト要求を記述する。この理由は、アスペクト要求が、なぜ必要なのかを示すWhyに相当する要素がゴール指向ではソフトゴールになるからである。
アドバイス
アドバイス・タスクではアスペクト要求が提供するサービス内容を示す。この理由は、ゴール指向ではタスクによりWhatに相当する要求を記述するからである。
ジョインポイント
アスペクト要求と関係する構成要素として、ゴールおよびタスクによりジョインポイントを表現する。この理由は、アスペクト要求(ソフトゴール)がどこと関連するかを示すWhereに相当する構成要素がゴールとタスクになるためである。
ポイントカット
どのような状況でアドバイスがジョインポイントで用いられるかを示すのがポイントカット(ジョインポイントの集合)である。ゴール指向では、貢献関係によりアドバイス・タスクとゴールやソフトゴールとの関係を表す。
織り込み(weaving)手順
サービスをいつどのように提供するかを示す、WhenやHowに相当するのが織り込み手順である。ゴール指向では、織り込まれた結果がゴールグラフとして記述される。NFRフレームワークの一種であるVグラフに関する織り込み手順の例が文献[4]にある。
セキュリティに対するアスペクト要求の例
図1に示したのは、ネットワークを介した商品販売サービスに対するセキュリティ要求の例である。セキュリティ要求には、プライバシー保護と機密性という2つのソフトゴールがあるとしている。プライバシーについては、顧客口座に対するパスワード検査と通信路の暗号化が必要である。機密性については、これらの2つに加えて商品DBのアクセス制限が必要になる。ここで、パスワード検査、暗号化、アクセス制限がアドバイス・タスクの例である。また、商品販売ゴールを達成するために必要となる販売記録と個人認証はジョインポイントの例である。このとき、ジョインポイントとアドバイス・タスクとの間における貢献関係がポイントカットの例になる。
図1 ゴール指向におけるセキュリティ要求アスペクト
ここで、プライバシーや機密性は複数のタスクに分散するので、分散クロスカット要求である。また、プライバシーと機密性は同時に必要とされることもあるので、友連れクロスカット要求でもある。
アクタ関係表を用いたセキュリティ要求の記述例
アスペクト要求をアクタ関係表ではどのように記述すればいいだろうか?以下では、上述した商品販売サービスを例にこの問題を考えよう。
図1に示したNFRフレームワークを見ると、顧客口座、NW(通信路)、商品データベース(DB)というアクタがあることが分かる。アクタ関係分析では、この3つのアクタに加えて顧客を考慮して、表2のようなアクタ関係表を作成することができる。対角線上には、顧客、口座、NW、DBごとにソフトゴール、ゴール、タスクを記述している。
顧客 | 口座 | NW | DB | |
顧客 | ◎商品購入 プライバシー |
プライバシー |
プライバシー |
プライバシー |
---|---|---|---|---|
口座 | 個人認証 |
機密性 プライバシー ◇個人認証 ◆パスワード検査 |
◆暗号化 |
|
NW | 機密性 プライバシー ◆暗号化 |
|||
DB | アクセス制限 |
◆暗号化 |
機密性 プライバシー ◆商品販売 ◆アクセス制限 |
ここでは「プライバシー」や「機密性」のように、先頭に記号がない単語によりソフトゴールを示している。また「◎商品購入」では、顧客のゴールであることを◎で示した。「◇個人認証」や「◇商品販売」では、記号◇によりジョインポイントタスクであることを示した。同様に「◆パスワード検査」「◆暗号化」「◆アクセス制限」では、記号◆によりアドバイス・タスクであることを示した。
この例からも、アクタ関係表を用いることでアスペクト指向要求分析が容易にできることが分かるだろう。
ポイントカットは、ジョインポイントタスクへのアドバイス・タスクの貢献関係であるから、次のようにして対応関係を調べることができる。
たとえば、「◇個人認証タスク」がジョインポイントタスクである。このタスクは口座アクタのタスクである。口座アクタ内のアドバイス・タスクとして「◆パスワード検査」がある。また、口座タスクがNWに期待するアドバイス・タスクとして「◆暗号化」がある。したがって、ジョインポイントタスク「◇個人認証タスク」には「◆パスワード検査」と「◆暗号化」という2つのアドバイス・タスクが貢献する必要がある。
分散クロスカット要求は、同じ要求があちこちに散在することであるから、次のようにして調べることができる。
アクタ関係表から、プライバシーおよび機密性は複数個所に散在しているから、明らかに分散クロスカット要求である。
同様に友連れクロスカット要求は、複数の性質や機能を同時に必要とする要求であるから、次のようにして調べることができる
アクタ関係表の対角線要素を見ると「プライバシー」および「機密性」が同時に必要とされていることが分かるから、これらは友連れクロスカット要求である。
セキュリティ要求工学から見たゴール指向とアスペクト指向
セキュリティ要求工学では、図2に示したように、まず開発対象システムを構成する資源を識別する。次いで、攻撃による脅威に関する資源の脆弱性をどれだけ保護するかということに着目してセキュリティ要求を抽出する。
図2 資源に対する脅威分析
この観点からすると、NFRフレームワークのようにまずセキュリティをソフトゴールとして捉えて、それを段階的に分解していくアプローチだと、保護すべき資源が必ずしも明示的ではないと思われる。もちろん非機能ソフトゴールの中で、口座やNW、DBなどの対象として記述するけれども、対象をまとめて記述することができないことや対象間の関係について直接記述することはない。対象が、複数の異なる非機能ソフトゴールの中に分散して記述されてしまうという不便さが残ると思われる。
これに対してアクタ関係表では、アクタをまず識別してアクタ間の関係を明らかにする。したがって、保護すべきアクタを選択することができる点でセキュリティ要求分析との相性が良いと思われる。
アクタ関係表を用いたアスペクト指向要求分析プロセス
連載36回で紹介したアスペクト指向要求工学のプロセス[5]を拡張することにより、次のような4ステップからなる、アクタ関係表を用いたアスペクト指向要求分析プロセスを構成できる。
識別
要求の中から、クロスカット要求を探索してアスペクトを識別する。アクタ関係表の升目の中身を縦横対角線に見ていくことで、同じもしくは類似する要求(ソフトゴール)が出てくれば、アスペクト要求の候補になる。これを候補関心事とする。またアスペクトを探すときには、セキュリティ、一貫性、信頼性、性能などの品質特性や非機能要求を表すような言葉に着目しても良い。
獲得
候補関心事要求を共通化して一つのアスペクト要求にできることを確認する。たとえば、分散記述されている関心事を共通化して、複数個所で参照できるかどうか確認する。
ここで候補関心事がクロスカット要求ではない場合には、アスペクト要求とはならないことに注意する。たとえば、特定のアクタに対する期待要求は複数のアクタから要求されるソフトゴールであるかもしれないが、クロスカット要求ではないかもしれない。
合成
クロスカット要求が影響を与える要求の範囲を明示的に特定する。つまり、クロスカット要求を参照するすべての要求を列挙する。たとえば、分散クロスカット要求と友連れクロスカット要求ならびにジョインポイントタスクを列挙して、分離された関心事としてのアスペクト要求が参照元の要求に対応することを確認する。
分析
アスペクト要求と他の要求との矛盾がないことや一貫性を確認する。
まとめ
今回は、ゴール指向とアスペクト指向要求工学との関係について説明した。とくに、NFRフレームワークによるアスペクト指向要求の表現法を紹介した。さらに筆者らが提案する、アクタ関係分析を用いたアスペクト指向要求分析プロセスについても述べた。
アスペクト指向要求工学は、まだ研究の初期段階にあるだけでなく、ゴール指向要求工学との組み合わせは、まだ未解明の部分が多いことも事実である。今後、ゴール指向とアスペクト指向要求工学の統合に関する研究が進展することを期待したい。
■参考文献
- [1]連載要求工学第36回,http://www.bcm.co.jp/site/youkyu/youkyu36.html
- [2]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
- [3]Nan Niuy, Steve Easterbrooky, and Yijun Yuz, A Taxonomy of Asymmetric Requirements Aspects, www.cs.toronto.edu/~sme/papers/2007/Niu-EA07.pdf
- [4]Yijun Yu, Julio Cesar Sampaio do Prado Leite, John Mylopoulos, From Goals to Aspects:Discovering Aspects from Require ments Goal Models, Proceedings of the 12th IEEE International Requirements Enginee ring Conference, 2004
- [5]Lars Rosenhainer, Identifying Crosscutting Concerns in Requirements Specifications, trese.cs.utwente.nl/workshops/oopsla-early-aspects-2004/Papers/Rosenhainer.pdf
- 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:保証ケース作成支援ツールの概要