• 検索結果がありません。

変換アルゴリズムの適用範囲

ᢤ⢋ 䠖

5.7 変換アルゴリズムの適用範囲

構成を特有なものとする.ケース分解については,それぞれのケースにおける目標達成が 親ゴールの目標達成に相当するので,親ゴールの結果状態に相当するバウンダリオブジェ クトとそれぞれのケースにおける結果状態に相当するバウンダリオブジェクトを汎化/特 化の関係で関連付ける.分割・統治については,分割されたそれぞれの目標は全体目標を 構成するので,親ゴールの結果状態に相当するバウンダリオブジェクトとそれぞれの分割 目標の結果状態に相当するバウンダリオブジェクトをコンポジションの関係で関連付ける.

このようにして,下段のWhere節の規則に従って左右モデルのモデル要素間をマッピング する.

次に,操作モデルからロバストネス図への変換アルゴリズムを疑似コードにより具体化 する.図 4.8の“操作モデル→ロバストネス図”変換テンプレートに基づき,操作モデル からロバストネス図に変換する詳細なアルゴリズムを示す.変換アルゴリズムの抜粋とし て,マイルストーン駆動洗練パターンの変換部分を図 5.12に示し説明する.STEP7で配 列OGに蓄積した変換結果操作モデルそれぞれについて,以下の変換処理を実行する(3 行).図 4.8にある「マイルストーン駆動」のロバストネス図で操作モデルを置換え(4–6 行等),モデル要素間で情報をマッピングする(13–16行).また,変換テンプレートより も操作数が多かった場合には,必要なモデル要素を追加する(7–12行).最後に,変換結 果ロバストネス図を配列RBDに蓄積する.

5.7 変換アルゴリズムの適用範囲

これまでに,新規に提案するそれぞれの変換アルゴリズムを説明した.そこでは変換テ ンプレート(図4.8)やQVTによる変換規則(図5.4,図 5.6,図 5.9,図 5.11)は,マイ ルストーン駆動洗練パターンにおけるマイルストーンがひとつの場合など各洗練パターン の基本的な型に対する変換を定義している.マイルストーン駆動のマイルストーンが2つ 以上の場合,ケース分解で3ケース以上の場合,分割・統治で3分割以上の場合など基本 的な型からはずれる場合は,基本的な変換の枠組みを決定した後,ゴールモデルの情報に 基づきマイルストーンを増やす等拡張することで対応している.

また,各ゴール,各イベントにそれぞれソフトウエアエージェント,環境エージェントを

752*>@7UDQVIRUPDWLRQIURP2SHUDWLRQPRGHOVWR5REXVWQHVVGLDJUDPV 752*>@

IRUHDFK2*ಬ2*>@቎坓䳜ሸቯ቉ሧቮ⮘㙪俟㨫㝜⇫኿ኤወ^ VZLWFK㾦傃ኮኜዙዐ ^

FDVHኻኁወኖእዙዐ汕╤

ኻኁወኖእዙዐ汕╤ዊክኖእኪኖ⦂⮘㙪ኣዐኴዉዙእ^

RJRSQ᧶⮘㙪俟㨫㝜⇫኿ኤወቑ㝜⇫㟿

RSRSQ᧶㝜⇫኿ኤወ⮘㙪ኣዐኴዉዙእቑ㝜⇫㟿 LIRJRSQ !RSRSQ^

ነዐእዊዙ዆᧨ክኃዐኝ዇᧨ቿኌኜዙ᧨ኅዐኣኀኣኀት RJRSQ RSRSQቃሴ抌┯ሼቮ

ₙቑ嫛ቊ抌┯ሺቂኇኳንኄኌእ቎ቇሧ቉᧨⸩⨚䤓ቍ栱≑ት抌岧ሼቮ

`

䜿⬒ኅዙንኄዐእት⺍㉫ሼቮቿኌኜዙ቎ቀቯቁቯኻአ኱ዐኍሼቮ ኅዐኣኀኣኀት⺍㉫ሼቮኅዐኣኀኣኀ቎ቀቯቁቯኻአ኱ዐኍሼቮ 栚ⱚ᧨₼栢᧨俑ℕቑኁ኶ዐእት⺍㉫ሼቮክኃዐኝ዇቎ቀቯቁቯኻአ኱ዐ

ኍሼቮ

㝜⇫ት⺍㉫ሼቮነዐእዊዙ዆቎ቀቯቁቯኻአ኱ዐኍሼቮ

`

5%'>QU@⮘㙪俟㨫ዊክኖእኪኖ⦂揜⒦ ኻኁወኖእዙዐ汕╤ዊክኖእኪኖ⦂⮘㙪 ኣዐኴዉዙእ᧷

QU QU EUHDN ዘዘዘዘዘ

`

`UHWXUQ5%'>@᧷

ᢤ⢋ 䠖

᧯స䝰䝕䝹 䝻䝞䝇䝖䝛䝇ᅗ

䠄䝬䜲䝹䝇䝖䞊䞁㥑ືᢤ⢋䠅

ͤ ⎔ቃ䜶䞊䝆䜵䞁䝖䛿䠈䠍䜲䝧䞁䝖䛻 䛴௨ୖ㛵㐃䛩䜛ሙྜ䛜䛒䜛䠊

図 5.12: 操作モデル→ロバストネス図変換アルゴリズムの抜粋(マイルストーン駆動)

5.7. 変換アルゴリズムの適用範囲 73 ひとつずつ割り当てているが,それらは同一エージェントであっても良い.また,親ゴー ルに複数のエージェントが関与する場合やゴールに関連するオブジェクトが複数ある場合 は,できるだけそれらを汎化した名称にしたり,それらを併記した名称とすることで対処 できる.逆にない場合には,とりあえずダミーとして付与し,STEP8の終了後に見直すこ とによって必要であれば修正する.なお,STEP6の要求ゴールの分解はゴールとイベント が1対1になると終了するので,ゴールに対応するイベントは必ず存在する.

提案する変換アルゴリズムは,洗練パターンを用いてモデリングしたゴールモデルを対 象としている.洗練パターンを使用していないAND/OR分解の部分は対象外のため変換さ れない.その詳細は本稿の範囲外となるので省略するが,STEP4またはSTEP8,STEP9 の終了後に見直しが必要である.OR分解の場合は,代替処理になるので修正せずそのま ま分離するのが適切であると考える.AND分解の場合は,必須処理になるので,ユース ケースもしくはイベント処理,コントローラに関連する機能として追加するのが適切であ ると考える.

また,アクターとユースケースとの関連で多重度を明記する場合があるが,現時点では 対応していない.しかし,環境エージェントとそれに関するイベントの組と操作との関連 に多重度の情報を付加することによって対応可能と思われる.これは操作モデルを拡張す ることになるが,今後の検討課題としたい.

75

6 章 ゴール指向 UML 設計手法の適用