続いて，要求が変化した際の対処法としてのゴールモデル変更法について，特に主要ゴール が新たに追加される場合と，既存の主要ゴール内の一部が変更される場合の2通りの進化につ いて説明する．以降本節では，清掃ロボットシミュレータの例を用いて進化への対応法を説明 する．
3.6.1 進化 1 ：ごみの積載量管理機能の追加
まず，主要ゴールが新たに追加される場合の進化として，清掃ロボットに対するごみ積載量 管理機能の追加を例に挙げ説明する．ごみ積載量管理機能の追加に関する新たな要求は，2.5 節で示した通りである．
［清掃ロボットに対する要求変化1］フィールド上のごみの増加により，清掃ロボットのご み積載量では一度に全てのごみが清掃できない場合が生じることとなった．そこで，清掃ロ ボットがごみの積載量を管理できる機能を新たに追加したい．清掃ロボットはごみの積載量 を監視し，積載量が一定値以上になった場合，ごみ箱の場所を探し，ごみ箱の場所へ移動後，
積載しているごみをごみ箱に捨てるという動作が求められる．
このような要求を記述すために，進化前の清掃ロボットに対応する図3.18のゴールモデル に対して，新たに追加するゴールツリーを図3.26に示す．このゴールツリーは，ごみの積載
図3.26.ごみ積載量管理機能の追加に伴い追加するゴールツリー
量を管理するためには，ごみ積載量の計測，ごみ箱への到達，ごみ捨ての3つの機能*4が必要 であることを示し，ごみ箱への到達に関しては，さらにゴールが詳細化されている．
提案する開発プロセスにおいては，ソフトウェア進化時にも，まずゴールモデル上に新たな 要求を記述し，その後，整形プロセスを再度適用することによりゴールモデルを洗練化させ る．以下，本例における整形プロセスを概説する．
初期ゴールモデルの確認
まず，要求の変化に対して，定義3.3.2で示した要件「システムに対する機能要求が，すべ てゴールモデル上にゴールとして記述されている」を満たすかどうかを判断する．本進化要求 に対しては，ゴールモデルに図3.26のサブツリーが追加されることとなるが，ごみ積載量管 理に必要と考えられる積載量計測，ごみ箱への移動，ごみ捨ての機能が機能要求として記述さ れているため，初期要求モデルが満たすべき要件は満足していると判断できる．もし，十分に ゴールが分解されていない，あるいは，追加・変更すべき機能要求をすべてゴールモデル上に 記述できていないと判断すれば，ゴールモデルを修正する．
エンティティの追加
次に，変化した要求に関連するエンティティをゴールモデルに追加する．図3.26で示した ゴール群に対して，関連エンティティとその関係を追加した後のゴールモデルを図3.27に示
*4それぞれ，ゴール「ごみの積載量を計測できる」，「ごみ箱に到達することができる」，「ごみ箱にごみを捨てる ことができる」が対応する．
図3.27.追加部分に対するエンティティの追加
す．本例では，ごみ積載量管理機能の追加に対して，「ごみ」，「ごみ積載量」，「ごみ箱」，「ロ ボットアーム」，「現在地の座標」，「ごみ箱の座標」，「ごみ箱との距離」を関連エンティティと して同定し，追加記述する．
共通ゴールの集約
エンティティを追加すると，新たに追加したゴール群に関しても，共通ゴールとして集約で きるゴールや，共通ゴールを利用することで達成できるゴールがあるかどうかを判断する．ご み積載量管理機能の追加により追加されるゴールモデルにおいても，ごみ箱への到達につい ては，既に共通ゴールとして集約されている対象物への移動に関するゴールを利用すること で達成できると考えられるため，ごみ箱への到達に関する詳細記述をゴールツリーから削除 し，ゴール「目標物に到達することができる」の利用を表現するUsesラベルを付与する（図 3.28）．
主要ゴールの同定
共通ゴール集約後は，再度主要ゴールを同定する．本例における共通ゴール集約後のゴール モデルを図3.29に示す．このゴールモデルにおいては，進化前と同様に，ゴール「個々のご みを清掃することができる」，「バッテリーを管理することができる」，「目標物に到達すること ができる」を主要ゴール候補として同定することができる．加えて，今回の進化に伴うゴール
Uses 目標物に到達 することができる
図3.28.共通ゴールの集約
モデルの変更により，指針2の「複数のサブゴールが同一エンティティとConcerns関係にあ る」について，ゴール「ごみの積載量を管理することができる」がエンティティ「ごみ積載 量」，「ごみ箱」，「ごみ」に対して合致し，ゴール「フィールド上のごみを清掃することができ る」がエンティティ「ごみ」に対して合致することとなる．
以上から，要求変化後のゴールモデルでは主要ゴール候補として，図3.29中の（A)〜(E)に 示される，「フィールド上のごみを清掃することができる」，「個々のごみを清掃することがで きる」，「バッテリーを管理することができる」，「ごみの積載量を管理することができる」およ び「目標物に到達することができる」が同定される．
続いて，これらの主要ゴール候補から主要ゴール集合を決定する．本進化後のゴールモデル においては，図3.29中の（A)〜(E)としてラベル付けされた主要ゴール候補の中から，以下の 2通りの組み合わせにより，充足性判定条件1の「すべての機能要求がいずれかの主要ゴール を根とするサブツリーに包含されている」と，条件2の「いずれの主要ゴールも，他の主要 ゴールを根とするサブツリーに包含されていない」が満たされる．
• 集合1：(A)
• 集合2：(B), (C), (D), (E)
本例においては，集合1を選択すると，システム中に唯一のControl loopしか抽出されなく なってしまい，進化に対しての変更影響が大きくなってしまうことと，進化前においては(B),
(C), (E)の構成で主要ゴール集合を同定していたことから，進化前の主要ゴール集合に「ごみ
の積載量を管理することができる」を追加した集合に該当する集合2を，主要ゴール集合とし
( A ) ( E )( D )( C )( B ) Uses 目標物に到達 することができる （目標物タイプ）
Uses 目標物に到達 することができる （目標物タイプ）Uses 目標物に到達 することができる （目標物タイプ）
Arg:目標物タイプ 主要ゴール候補
図3.29.共通ゴール集約後のゴールモデル
て採用する．
Control loopの構築
ゴールモデル上において主要ゴールが同定されると，各主要ゴールに対してControl loopを 割り当てる．本例では，追加された主要ゴールに対してControl loopを新たに構築する．新た に追加された主要ゴール「ごみの積載量を管理することができる」に対しては，まず，入力変 数としてエンティティ「ごみ積載量」を同定することができ，ごみ積載量を収集するゴールと して，既に記述されている「ごみの積載量を計測できる」をCollectタイプのゴールとして同 定できる．同定された入力変数とCollectゴール間のConcerns関係に対しては，：Monitor ラベルを付与する．
続いて，同定したCollectタイプゴールを除くサブゴールであるゴール「ごみ箱に到達する ことができる」とゴール「ごみ箱にごみを捨てることができる」がActタイプゴールであるか を判断する．これらのゴールはいずれも，アクションにより達成できる状態を表現しているた め，Actタイプのゴールとして同定できる．ここで，後者のゴール「ごみ箱にごみを捨てるこ とができる」については，エンティティ「ごみ積載量」を制御変数として同定することができ
るため，Concerns関係に：Controlラベルを付与する．また，エンティティ「ロボットアー
ム」はごみを捨てるために操作可能なエンティティであることから，操作変数として同定する ことができ，該当するConcerns関係に：Manipulateラベルを付与する．
新たに追加された主要ゴール「ごみの積載量を管理することができる」に対するControl loopが構築されると，本主要ゴールを清掃ロボットの責務として新たに追加する．Control loop構築後のゴールモデルを図3.30に示す．
競合の検出
最後に，Control loop間の競合が存在するかどうかを，Entity-conflictパターンにより形式 的に検査する．図3.30のゴールモデルでは，エンティティ「ロボットアーム」が，主要ゴー ル「個々のごみを清掃することができる」と「ごみの積載量を管理することができる」に対し て，競合の可能性のあるエンティティとして抽出される．この競合に対しては，それぞれの ゴールがごみの清掃と積載量管理を表現したものであり，今後の各機能個別の進化も考える と，2つのゴールを集約するのではなく，独立したControl loopとして構成した方が良いと判 断できるため，解消法1の共通ゴールの導入により競合の解消を図る．本例では，新たな主要 ゴール「アームを利用できる」を追加し，ロボットアームに関連するゴールには，新たな主要 ゴールの利用を表現するUsesラベルを付与する．解消法を適用し，新たな主要ゴールに対し
てControl loopを構築した後のゴールモデルを図3.31に示す．本ゴールモデルが，進化1に