一般に，システム開発プロセスにおいては，要求記述に記載された情報は後継フェーズにお いて開発すべきシステムの拠り所となる．本研究では，1.2節で述べた開発プロセスに求めら れる要件を満たすために，前節までで定義した整形プロセスにより構築されたゴールモデルを 用いたシステム構成（コンフィギュレーション）の決定法を導入する．システム構成を表現す るモデルとしては，コンポーネントとその接続（コネクタ）により表現されるコンフィギュ レーションを用い，特に，コンポーネントの責務を可視化することのできるDarwinモデル[3]
（図3.22）をコンフィギュレーションを表現するためのコンポーネントモデルとして用いる．
3.4.1 コンポーネントのタイプ
本研究で導入するコンフィギュレーション決定法では，Control loop の構成要素として，
ゴールモデル上で定義したCollectタイプ，Analyze & Decideタイプ，Actタイプの3種類に 対応するコンポーネントを抽出することとする．CollectタイプとActタイプのコンポーネン
トを分離して抽出するのは，まずCollectタイプについては，情報収集においては定常的なモ ニタリングなど，Control loopの制御タイミングとは独立したサイクルでモニタリングを実行 する場合があることと，ソフトウェア進化を考慮した場合，Control loopの制御の変更と情報 収集メカニズムの変更のタイミングは必ずしも一致しないことによるものである．また，Act タイプに関しても，Collectタイプ同様にソフトウェア進化を考えた場合，Control loopの制御 の変更と処理部の変更のタイミングは必ずしも一致しないと考えられる点，Shawのプロセス コントロールモデルにおいても制御部と処理部が分離されている点から，独立したコンポーネ ントとして抽出する．一方で，通常は分析結果に対応してどのように制御するかを判断するた め，分析（Analyze）と決定（Decide）は同一コンポーネントの責務として集約する．
3.4.2 コンフィギュレーションへの変換
本研究で導入するコンフィギュレーション決定法では，整形されたゴールモデルをもとに，
ゴールモデル上のゴールをシステムコンフィギュレーション上のコンポーネントへと変換す る．変換の対象となるゴールは，整形プロセスにより責務割り当てをした主要ゴール以下の ゴール群，つまりControl loopを構成するゴール群となる．本手法においては，コンフィギュ レーション変換に2つのアルゴリズムを用いる．まずAlgorithm 2により，ゴールモデル上の ゴールのうち，Collectタイプ，Analyze & Decideタイプ，Actタイプ，およびConditional Actタイプに該当するゴールをコンポーネントに変換し，ゴール間の関連，つまり
AND/OR-refinementリンクをコンポーネント間の取り得る接続関係に変換する．Algorithm 2において，
AND-refinementは親ゴールに対応するコンポーネントが子ゴールに対応するコンポーネント
のサービスを利用する形態で，一対一の複数の接続関係に変換する．一方のOR-refinement に対しては，親コンポーネントのサービス利用ポートに対して子コンポーネントのそれぞれ のサービス提供ポートとを接続する．図3.23はAND-refinementとOR-refinementの変換イ メージを示したものである．
Example 9 —図3.18のゴールモデルを入力としたときに，Algorithm 2を適用して生成さ れる第一段階のコンフィギュレーションを図3.24に示す．このコンフィギュレーションでは，
例えばコンポーネント「個々のごみを清掃することができる」と，その子コンポーネント「ご み清掃に必要な情報が収集されている」，「適切な手段でごみを清掃できる」，「ごみの場所に到 達することができる」との接続はAND-refinementリンクに対応した接続であり，コンポーネ ント「適切な手段でごみを清掃できる」と「吸引によりごみを清掃することができる」および
「持ち上げることでごみを清掃することができる」との接続は，OR-refinementリンクに対応し た接続である．
Algorithm 2ゴールモデルからのコンフィギュレーション生成（第一段階）
[入力] gModel:ゴールモデル
[出力] config:（第一段階の）システムコンフィギュレーション
1: assignedGoals←gModel上でシステムに責務割り当てされているゴール群; 2: for all goal in assignedGoals do
3: goal.putLabel(“AD”);
4: comp←config.Components.add(goal.getOperation());
/*コンポーネントの生成*/
5: if goal.refinement=AND-refinement then 6: for all cGoal in goal.getChildren() do 7: pPort←comp.addRequiredPort();
8: cComp←config.Components.add(cGoal.getOperation());
9: cPort←cComp.addProvidedPort();
10: config.connectPorts(pPort, cPort);
11: if cGoal.hasConcerns(“:Monitor”) then
12: cGoal.putLabel(“C”); /* Collectタイプと同定*/
13: else
14: cGoal.putLabel(“A”); /* Actタイプと同定*/
15: if cGoal.refinement = OR-refinement then 16: pPort←comp.addRequiredPort();
17: for all condGoal in cGoal.getChildren() do
18: condComp←config.Components.add(condGoal. getOperation()); /* Conditional Act タイプ*/
19: condPort←condComp.addProvidedPort();
20: config.connectPorts(cPort, condPort);
21: end for
22: end if
23: end if
24: end for 25: end if 26: end for
得られたコンフィギュレーションをDarwinモデルの意味論に照らし合わせると，
AND-refinementリンクに該当する変換は，親ゴールに対応するコンポーネントが全ての子ゴール
に対応するコンポーネントのサービスを要求，つまり利用することで，自身のサービスを提 供することを意味している．また，OR-refinementリンクに該当する変換は，親ゴールに対応 するコンポーネントが子ゴールに対応するコンポーネントのいずれかのサービスを利用する ことで，自身のサービスを提供可能であることを意味している．従って，変換前後において，
Component
B Component
C Goal A
Goal B Goal C
Goal A
Goal B Goal C
AND-Refinement OR-Refinement
Component A
Component
B Component
C Component
A
図3.23.Algorithm 2におけ る AND/OR-refinement のコン フィ ギ ュレ ーシ ョ ンへ の変 換イ メージ
ゴールモデルとコンフィギュレーション間での意味上での不整合は生じないと考えることがで きる．
ゴールモデルからコンフィギュレーションへの変換が終わると，生成したコンフィギュレー
ションをAlgorithm 3に従って洗練化する．本アルゴリズムは，Usesラベルに従って，利用
関係にあるコンポーネントを接続するとともに，Control loopにおけるAnalyze & Decideタ イプのコンポーネントと，OR-refinementで複数記述されているConditional Actタイプのコン ポーネントとを直接接続するよう変更する．後者は，仲介しているActタイプのコンポーネン トを削除することを意味する．
Example 10 — Algorithm 3適用後のコンフィギュレーションを図3.25に示す．図3.25は，
図3.24と比較して，コンポーネント「適切な手段でごみを清掃できる」が削除され，Analyze
& Decideタイプのコンポーネント「個々のごみを清掃することができる」とConditional Act
タイプのコンポーネント「吸引によりごみを清掃することができる」および「持ち上げるこ とでごみを清掃することができる」とが直接接続されるように変更されている．また，Uses ラベルに従って，コンポーネント「ごみの場所に到達することができる」と「バッテリース テーションに到達することができる」が，コンポーネント「目標物に到達することができる」
のサービスを利用するための接続が追加されていることが分かる．これは，ごみ処理に関す るControl loopとバッテリー管理に関するControl loopが，対象物への到達に関するControl
䛤䜏ฎ⌮䛻㛵䛩䜛Control loop Collect
䝞䝑䝔䝸䞊䜢⟶⌮
䛩䜛䛣䛸䛜䛷䛝䜛
┠ᶆ≀䜢
Ⓨぢ䛷䛝䜛
䝞䝑䝔䝸䞊ṧ㔞 䜢ィ 䛷䛝䜛 䝞䝑䝔䝸䞊䜢
㟁䛷䛝䜛
⌧ᅾ䛾⨨䜢≉
ᐃ䛷䛝䜛 ಶ䚻䛾䛤䜏䜢Ύᤲ
䛩䜛䛣䛸䛜䛷䛝䜛
ᣢ䛱ୖ䛢䜛䛣䛸䛷 䛤䜏䜢Ύᤲ䛩䜛
䛣䛸䛜䛷䛝䜛
྾ᘬ䛻䜘䜚 䛤䜏䜢Ύᤲ䛩䜛
䛣䛸䛜䛷䛝䜛
䛤䜏Ύᤲ䛻ᚲせ 䛺ሗ䛜㞟䛥
䜜䛶䛔䜛
Analyze 㻌& Decide
Analyze & Decide Conditional
Act
Act Collect
┠ᶆ≀䛻ྥ䛛䛳 䛶⛣ື䛩䜛䛣䛸
䛜䛷䛝䜛
Analyze& Decide
Collect
䝞䝑䝔䝸䞊⟶⌮䛻㛵䛩䜛 Control loop
Analyyyze& Decide
┠ᶆ≀䛻฿㐩䛩䜛
䛣䛸䛜䛷䛝䜛 Act
┠ᶆ≀䜈䛾฿㐩䛻㛵䛩䜛Control loop Collect
䛤䜏䛾ሙᡤ䛻
฿㐩䛩䜛䛣䛸䛜 䛷䛝䜛
䝞䝑䝔䝸䞊䝇䝔䞊 䝅䝵䞁䛻฿㐩䛩䜛 䛣䛸䛜䛷䛝䜛
Act
Act
㐺ษ䛺ᡭẁ䛷䛤 䜏䜢Ύᤲ䛷䛝䜛
図3.24.生成されるコンフィギュレーション（第一段階）
䛤䜏ฎ⌮䛻㛵䛩䜛Control loop Collect
䝞䝑䝔䝸䞊䜢⟶⌮
䛩䜛䛣䛸䛜䛷䛝䜛
┠ᶆ≀䜢
Ⓨぢ䛷䛝䜛
䝞䝑䝔䝸䞊ṧ㔞 䜢ィ 䛷䛝䜛 䝞䝑䝔䝸䞊䜢
㟁䛷䛝䜛
⌧ᅾ䛾⨨䜢≉
ᐃ䛷䛝䜛 ಶ䚻䛾䛤䜏䜢Ύᤲ
䛩䜛䛣䛸䛜䛷䛝䜛
ᣢ䛱ୖ䛢䜛䛣䛸䛷 䛤䜏䜢Ύᤲ䛩䜛
䛣䛸䛜䛷䛝䜛
྾ᘬ䛻䜘䜚 䛤䜏䜢Ύᤲ䛩䜛
䛣䛸䛜䛷䛝䜛
䛤䜏Ύᤲ䛻ᚲせ 䛺ሗ䛜㞟䛥
䜜䛶䛔䜛
Analyze 㻌& Decide
Analyze & Decide Conditional
Act
Act Collect
┠ᶆ≀䛻ྥ䛛䛳 䛶⛣ື䛩䜛䛣䛸
䛜䛷䛝䜛
Analyze& Decide
Collect
䝞䝑䝔䝸䞊⟶⌮䛻㛵䛩䜛 Control loop
Analyyyyze& Decide
┠ᶆ≀䛻฿㐩䛩䜛
䛣䛸䛜䛷䛝䜛 Act
Collect
䛤䜏䛾ሙᡤ䛻
฿㐩䛩䜛䛣䛸䛜 䛷䛝䜛
䝞䝑䝔䝸䞊䝇䝔䞊 䝅䝵䞁䛻฿㐩䛩䜛 䛣䛸䛜䛷䛝䜛
Act
Act
┠ᶆ≀䜈䛾฿㐩䛻㛵䛩䜛Control loop
図3.25.生成されるコンフィギュレーション
loopの提供サービスを利用することを表現している．
このような変換により，本手法では，ゴールモデルの階層構造とControl loopパターンとを 利用して，システムのコンフィギュレーションを決定する．
Algorithm 3コンフィギュレーションの洗練化
[入力] config: Algorithm 2により生成されたコンフィギュレーション
[出力] config:洗練化後のコンフィギュレーション
1: Components←config.Components;
2: Connections←config.Connections;
3: /* “Uses”ラベルで定義されたコンポーネント間を接続する*/
4: for all comp in Components do
5: if comp.associatedGoal.hasLabel(“Uses <usedGoal>”) then 6: usedComp←Components.get(<usedGoal>);
7: rPort←comp.addRequiredPort();
8: config.connectPorts(rPort, usedComp.providedPort);
9: end if 10: end for
11: /* Conditional Actを直接接続（仲介するAct型コンポーネントを削除）する．
12: Requesters(comp) : compに対してreqPortポートで接続するコンポーネントの集合*/
13: for all comp in Components do 14: goal←comp.associatedGoal;
15: if goal.hasLabel(“A”)∧goal.refinement = OR-refinement then 16: for all requester in Requesters(comp) do
17: Connections←Connections− {con|con∈Connections∧con.reqPort = requester.reqPort∧ con.provPort = comp.provPort};
18: for all con in Connections do 19: if con.reqPort = comp.reqPort then 20: con.reqPort←requester.reqPort;
21: end if
22: end for
23: end for
24: Components←Components− {comp}; 25: end if
26: end for