ソフトウェア開発手法「ICONIX（アイコニクス）プロセス」の整理
概要
ICONIXプロセスの思想は「漸進的な反復と洗練による継続的な改善」。
ICONIXプロセスのワークフロー
- 要求段階
1-1. 機能要求：システムが提供する機能を定義
1-2. ドメインモデリング：問題領域の理解（ユビキタス言語の定義）※作業時間目安：2時間
1-3. 振る舞い要求：最初のユースケース（ドラフト版）を作成
1-4. 要求レビュー：ユースケースが顧客要求を満たしているか確認 - 分析・予備レビュー
2-1. ロバストネス分析：ロバストネス図を使ってユースケース記述を書き直す
2-2. ドメインモデルを更新（作業：見落としていたクラスの発見や曖昧だった部分を修正したり、属性の追加）
2-3. システムに機能名をつける
2-4. ユースケース（ドラフト版）を更新 - 予備設計レビュー
- 詳細設計
4-1. ユースケースごとにシーケンス図を作成（シーケンス図の目的はクラスの責務割当て）
4-2. ドメインモデルを更新（ドメインオブジェクトに操作を追加）
ドメインオブジェクトはエンティティとなり、ドメインモデルは静的クラス（クラス図）へ生まれ変わる
4-3. 静的モデルの整理 - 詳細設計レビュー
- 実装
学習範囲
1-2.ドメインモデリングと1-3.振る舞い要求まで
ドメインモデリング
[目的]
ドメインモデリングはプロジェクトで利用される共通言語（辞書）を作成する作業。
ドメインモデリングの目的はプロジェクトメンバー全員に明確な用語で問題領域を確実に理解させること。
プロジェクトのドメインモデルはスコープを定義しユースケース作成の基盤とする。
最初のドメインモデリングからユースケースを作成していく過程でドメインモデルを固めていく。
[ガイドライン]
現実世界（問題領域）に焦点をあてる
オブジェクト間の関係は汎化（A is B)、集約(A has B)を利用
最初のドメインモデリングにかける時間は2時間が目安
問題領域の主要な概念を中心にクラスを構成する
ドメインモデルとデータモデルはイコールではない
オブジェクト（単一インスタンスを表現した存在）とDBのテーブルを混同しない
ドメインモデルをプロジェクトの共通言語として利用する
名前が曖昧にならないようにユースケースを書く前にドメインモデルを作成する
最終的なクラス図とドメインモデルは正確に一致するとは限らない
画面やその他GUI固有の部品クラスを配置しない
[MEMO」
| 関係 | 記号 | 説明 |
|---|---|---|
| 汎化（A is B) | A --▷ B | AはBである（例：テレビは家電である） |
| 集約(A has B) | A ◇-- B | AはBをもっている（例：ソニーはテレビを持っている） |
振る舞い要求（最初のユースケース）
[目的]
ユースケースはシステムの振る舞い要求を得る為の構造化された手法。
具体的には「ユーザーはこのシステムで何をしたいのか。」「ユーザーは何を得たいのか。」といった疑問に答える。
[ガイドライン]
ユースケースのシナリオは「基本的なシナリオ」と「例外的なシナリオ」を用意する
ユースケースはドメインモデルで用いた単語を使って記述する
設計が可能となるユースケースを書く
ユースケース記述は2段階以内で記述する
アクターとユースケース図を使ってユースケースを組織化する
ユースケースは叙述的に記述する
イベントの応答の流れとしてユースケースを記述し、ユーザーとシステムの対話の両側を記述する
GUIプロトタイプや画面モックアップを使う
ユースケースは実行時の振る舞いの仕様である
名詞 - 名詞 -動詞という構文に従って記述する
バウンダリングクラス（システムと外部の境界）の名前を使う※ログイン画面、決済画面など
[MEMO]
ユースケースの関係
| 関係 | 説明 |
|---|---|
| A --▷ B | AはBの一種 |
| A <<invokes>> B | Aが実行中にBが実行される |
| A <<precedes>> B | Bの実行前にAが完全に実行されている |