ICONIX プロセス

拽㠼ክዙነዐእዊዙ዆ 拽㠼ክዙ栘䕅㏚ ᧶拽㠼ክዙ䕅㏚栘

⒦慙㘴扠ኘዐኒዙ

拽㠼ክዙነ ዐእዊዙ዆

⒦慙㮫⒉⏴┪㣑ቀቑ㣑቎棟ቭ

⒦慙㮫⒉䕅㏚ት21቎ሼቮ

᧶⒦慙㮫⒉㍔⫀

᧶拽㠼ክዙ䕅㏚栚 㘴扠⒦慙㮫⒉

᧶⒦慙㘴扠䕅㏚

⮘▥2))ൺ21

⒦慙㮫⒉䕅㏚21ቊ⒦慙㮫⒉ 䕅㏚ት2))ൺ21቎ሼቮ

⒦慙@㘴扠ኘዐኒዙሮቬቑ⏴┪

቎ቫቮ⒦慙㘴扠䕅㏚2))ൺ21

⒦慙㮫⒉嫷䯉⣷ ⒦慙㮫⒉ 䕅㏚21

᧶⒦慙㮫⒉䕅㏚21 拽㠼ክዙ䕅㏚栘ት

值㖐ሼቮ ቿኌኜዙ ክኃዐኝ዇

ኇኳንኄኌእ ነዐእዊዙ዆ ኅዐኣኀኣኀ ኇኳንኄኌእ

図 2.5: 遮断バー状態閉維持のロバストネス図例

しかし，ユースケースモデルは要求を利用者等のアクターとシステムとの間のインタラク ションとして定義するものであり，要求を体系的，論理的に抽出する方法を提供するもの ではない．従って，要求抽出にはユースケースモデルよりも体系的，論理的に要求を抽出，

分析できるゴール指向要求分析手法KAOSの方がより適していると言える．

ロバストネス図は，ユースケース記述からオブジェクトと振舞いを抽出しその関係を図 で表現したものである．ユースケース記述のイベントフローと1対1に対応させ，その内 容を図に張り付ける．ユースケースごとに作成する．ユースケースモデルで定義された要 求情報を設計モデルであるクラス図やシーケンス図に仲介するためのものであり，予備設 計に含まれる[51]．

イベントフローはアクターとシステム間インタラクションの流れを表現している．それ と対応するロバストネス図も，システムがハンドリングするエンティティオブジェクト，シ ステムとシステム外部とのインターフェイスであるバウンダリオブジェクト，システムの 処理や機能を示すコントローラ，およびシステムとインタラクションを行うアクターなど のシンボルを使って，イベントフローに基づくシンボル間の関連を模式図的に表現する．

ロバストネス図の例として，図 2.1のゴールG31「遮断バー状態閉維持」に関するものを 図 2.5にを示す．

2.3 ICONIX ^プロセス

ICONIXプロセスはユースケースとコードの間に存在する領域にフォーカスした，最小

限かつ効率的なアプローチであり，ユースケース駆動によるUMLを用いたオブジェクト 指向分析／設計のプロセスである[33, 51]．抽象的かつ本質的なユースケースからコードを

GUI Storyboard Use Case

Model Sequence

Diagram Robustness Diagram

Dynamic

Static

Domain Model

Updated

Domain Model Class Model

Test Plans

Code Tests + Unit

Test 1 Test 2

Test 3

図 2.6: ICONIXプロセス ，出典[33]

生成するためにはロバストネス分析が不可欠であり，それによって要求と設計を結ぶこと ができるとの考えに基づいており，多くの実務的なプロジェクトで実践されている．要求 定義工程から設計工程への移行部分までを重点に，ICONIXプロセスの要点を説明する．

ICONIXプロセスの全体像を図2.6に示す．図 2.6にあるように，ICONIXプロセスは動 的な側面のワークフロー（上側の破線矩形部分：Dynamic）と静的な側面のワークフロー

（下側の破線矩形部分：Static）からなり，お互いのプロセスの途中成果を反映させながら 進めていく．動的な側面のワークフローの入力（出発点）はユースケースモデルであり，静 的な側面のワークフローの入力（出発点）はドメインモデルである．動的な側面のワーク フローの左側枠外にあるGUIのストーリーボードは，ユースケースの根拠となる振舞い要 求を抽出するためのツールとして使う．

ICONIXプロセスの開始は，静的な側面のワークフローのドメインモデルの作成である．

ドメインモデルは対象ドメインで使用する用語を体系化したもの（用語集）であり，静的な 側面のワークフローの成果物としてクラス図に進化していく．ここで整理した用語を使っ

2.3. ICONIXプロセス 17 て，ストーリーボード等を参照しながらユースケースモデルを作成する作業が，動的な側 面のワークフローの出発点となる．

ユースケースモデルは振舞いに対する要求をユースケース図とユースケース記述で定義 したものであり，ユースケース図に記されたユースケースが要求機能に相当する．ユース ケースの詳細な振舞いは，アクターとシステムとのインタラクションとして，ユースケー ス記述の中で詳細に説明される．このユースケースモデリングによって見直された用語の 体系はドメインモデルに反映され，ドメインモデルはユースケースモデルと整合するよう に更新される．ここで説明したユースケースモデルとドメインモデルが要求定義工程の成 果物となる．

動的な側面のワークフローにおける設計工程の成果物はシーケンス図であり，要求を定 義するユースケースモデルとそのシーケンス図の間を仲介するのがロバストネス図である．

ロバストネス図の作成は予備設計に位置づけられる．ロバストネス図はユースケース記述 をオブジェクトの絵として表現したものであり，ユースケース記述から抽出したオブジェ クトを，ユースケース記述に記載されたシナリオ（イベントフロー）どおりに貼り付けて 作成する．シーケンス図は，ロバストネス図で抽出したドメインオブジェクト等（最終的 にはクラスに対応する）の相互作用を時系列に並べたものである．ロバストネス図で表現 されたシナリオをそのまま時系列の相互作用に置換えた記述となっている．シーケンス図 は詳細設計に位置づけられる．

ICONIXプロセスの範疇には含まれないが，ソフトウエアアーキテクチャの設計はロバ

ストネス図と並行して実施されるべきものとされる．ソフトウエアアーキテクチャの設計 プロセスがICONIXプロセスに含まれていないのは，ソフトウエアアーキテクチャが個々 のプロジェクトに依存する場合が大きいためである．すなわち，同様なシステムであって も，その実現を図るプロジェクトの構成員，スケジュール，技術的背景，またはそのほか の様々な制約等により，ソフトウエアアーキテクチャの設計プロセスは異なったものにな る．しかし，いずれにしても，ソフトウエアアーキテクチャの設計はロバストネス図の作 成完了と同時に終える必要があり，ロバストネス図分析の成果からシーケンス図を導出す るときにソフトウェアアーキテクチャ設計の成果も合わせて反映される．例えば，ライフ ラインとしてソフトウェアアーキテクチャ上必要なクラスが追加・変更・削除されたり，特

有な相互作用が追加されたりする．同様に，ロバストネス図分析によって定義されたドメ インオブジェクトは，ソフトウェアアーキテクチャやシーケンス図に反映されクラスへと 抽象化される．その結果，ドメインモデルはクラス図へと更新される．

このようにしてこれまでのプロセスに従い，要求定義モデルを入力とした予備設計・設 計工程の成果として，動的な側面のワークフローではシーケンス図が作成され，静的な側 面のワークフローではクラス図が作成される．最終的に，クラスはコードとして実装され，

シーケンス図に基づいた設計駆動のテストでその有効性が確認される．

以上説明したように，ICONIXプロセスでは，ユースケースで定義した要求を出発点と してロバストネス図で予備設計を行い，それを介して，クラス図，シーケンス図等での詳 細な設計へと進むプロセスが提供されている．すなわち，ICONIXはユースケース駆動プ ロセスであり，獲得された要求がユースケースモデルに適切に反映されていれば，要求を 正しく反映した設計を期待できる．

本論文は，KAOSによる要求モデルをICONIXの動的な側面のワークフローに漏れなく 反映させるための仕組みを提案するものである．

19