第 3 章 関連研究
3.3 i* ， Tropos による一貫した開発手法
3.3. i*，Troposによる一貫した開発手法 23 している．Brescianiらによると，Troposによるエージェント指向開発は，ソフトウェア開 発工程を前期要求工程から後期要求工程，アーキテクチャ設計工程，詳細設計工程と実装 工程に分け，アクターに主眼を置いた意図ネットワーク（依存関係）を使ってモデルを詳 細化することで，各工程に一貫した開発手法を提供している．
その中では，i*のモデリング機能を使って，ステークホルダ(アクター）およびその意図
（ゴール）の特定とそれらのゴール分析結果を，アクター間の依存関係を示すSD(Strategic Dependency)モデルとアクター内部の依存関係を示すSR(Strategic Rationale)モデルで表 現している（前期要求工程）．さらにそれを，対象システムを示すアクター（以降，対象 アクター）とその他のアクター間の詳細な依存関係分析や対象アクターの詳細なSR分解
によってsystem-to-be（システムのあるべき姿）へと詳細化し，すべての機能要求や非機
能要求を具体化する（後期要求工程）．次に，アクターをマッピングしたエージェントの 依存関係からそれぞれのエージェントに機能を割付け（アーキテクチャ設計工程），さら にエージェントUML（AUML）を使ってその機能を詳細に仕様化している（詳細設計工 程）．AUMLでは，エージェント間のコミュニケーションプロトコルをアクティビティ図 やシーケンス図で表現する．
このように，Troposはi*のモデリング機能やAUMLの図表示などを使って要求定義か ら設計・実装までを一貫して実施するものであるが，i*によるモデリングやAUMLによる 設計をどのように実施するかについてはアルゴリズム的な手順はない．すなわち，Tropos による成果は実施者に依存し，知識や経験則の影響を大きく受けてしまう．
時間的に動的な関係を扱えるようTroposを拡張したものとして，Formal Tropos（FT） がある．KAOSで時間関係を形式的に記述するのに使う時相論理を扱えるよう，Troposを 拡張したものである．Fuxmanら[9]はFTを前期要求工程に適用した．FTでモデリングし た前期要求モデルを，モデル検査器を使って自動的にチェックし繰り返し洗練する，T-tool フレームワークを提案している．そこでは，i*モデルの親ゴール-子ゴール間の手段-目的関 係等で暗黙的に表現されているオブジェクト間の動的制約を導出し，時相論理で形式的に 定義している．
前期要求工程で抽出された時間的な動的制約を時相論理で定義することで，i*で分析・
定義された要求を矛盾なく設計工程に引き継ぐことができ，要求定義工程から設計・実装
工程までの一貫した実施を期待できる．しかし，一般的な設計者にとって，形式的なFT を習得し，時相論理式を使ってモデルを記述して分析することに対する負荷は大きい．
これまでに述べたように，i*，Troposによる開発は，要求定義から設計へ一貫性を持っ て移行する仕組みを持っている．しかし，アルゴリズム的な手順ではなく，手法に基づい た手動による作業であるため，設計者の知識や経験がその成果に及ぼす影響は大きい．FT はそれを改善するために，要求定義モデルをアルゴリズム的に設計に引き継ぐように時相 論理を用いて工夫したものであるが，実務の設計者にとって時相論理やFTの習得に対す る負荷は大きい．これに対して，本稿では，時相論理などの形式手法を使うことなく，要 求定義モデルをアルゴリズム的（規則的）に設計に引き継ぐアプローチを提案している．
25