「ユースケースと UML モデリングの例題がもっと必要だ」という声がきっかけになり書かれた本です。 ユースケースという抽象的な表現から、どのようなステップで具体的なコードにまで落とし込んでいくかが説明されています。 このような開発をユースケース駆動と呼んでおり、提唱者の Ivar Jacobson によると、ユースケース駆動は下記のように説明されています。
システム機能を変更する場合は、適切なアクタとユースケースを再モデル化します。 システムアーキテクチャ全体は、ユーザの要求にそって構築されます。 すべてのモデルはトレースできるようにしておくと、新しい要求仕様が発生した際にもシステムの修正が可能になります。 ユーザに対し、変更したい部分（もしくは変更したいユースケース）の内容を確認し、ほかのモデルの中でどの部分を変更するかを見極めます。
本書の著者、ダグ・ローゼンバーグはこれを以下のように簡単に解釈しています。
ユーザマニュアルを書けば、コードも書ける。
第1章: はじめに
- ここで用いる ICONIX プロセスは、重量級の RUP（ラショナル統一プロセス）と、軽量級の XP (eXtreme Programming) の間に位置する。具体的で理解しやすいユースケースが作成できるという点で、Ivar Jacobson が構想した「ユースケース駆動」の意味に一致している。
- ソフトウェアプロジェクトの進捗はどれだけのコードを書いたかによって測定されることが多いので、プロジェクトはコーディングに移行しようとする。そして、モデリングが十分にできていない段階でコーディングが始まってしまう。
- 本書の目的は、ソフトウェアプロジェクトにおいて、よい仕事をするために通常必要と思われる UML（およびモデリング全般）の、最小限ではあるが、十分なサブセットを定義すること。
- what（要求）と how（詳細）のギャップを埋めることが ICONIX プロセスの中心課題である。ロバストネス図を使って、あいまいで漠然としたユースケース（要求レベルのビュー）と、詳細で正確なシーケンス図（設計レベルのビュー）のギャップを解消する。ロバストネス図を使用せずにユースケースからシーケンス図を作成することは非常に難しい。ロバストネス分析は、要求と設計のギャップを解消するのにとても役に立つ。
- ギャップの解消するためには、ロバストネス分析の中で、下記のような作業を並行して行っていく。
- 見落としていたオブジェクトを見つける。
- データフローをトレースする際に、クラスに属性を追加する。
- ロバストネス図を描きながら、ユースケース記述を更新し洗練する。
- ドメインモデルで定義した「用語」を使ってロバストネス図を描く。
- ユースケースモデル ⇔ ロバストネス図 ⇒ シーケンス図
- ICONIX プロセス:
- プロトタイプを作る（おそらく画面の簡単な描画）。
- クライアントに誤りがないかを確認してもらう。
- ユースケース図のユースケースを識別する。
- ユースケース記述を書く。
- ロバストネス分析でユースケース記述を洗練する。
第2章: ドメインモデリング
- ドメインモデリングでは、UML モデルの静的な部分の基礎を形成する。
- ドメインモデルは実世界の問題空間オブジェクトを中心に構成するので、ソフトウェアの要求ほど頻繁には変化しない。
- ドメインモデルは、ユースケースを記述する作業の初期段階で使用できる「用語集」の役割を果たす。
- ドメインモデリングでは、属性と操作の把握には時間を費やさない。後の作業で明らかになった属性と操作を追加していけばよい。
- ドメインモデリングでは、オブジェクト間の関係（汎化や集約）を識別することに焦点を当てる。
- ソフトウェアが再利用できるかどうかは、このドメインモデリング作業にかかっている。
ドメインモデリングの誤りトップ10
ドメインモデリングのコツはすばやく作ること。ブラッシュアップは後のロバスト分析などの過程で行っていけばよい。
- 無駄にデザインパターンを適用しようとする
ドメインモデリングは、パターンの観点から考え始めるべきではない。 デザインパターンは、シーケンス図や設計レベルのクラス図で意識するもの。 - ドメインクラスと RDB のテーブルを 1対1 にマッピングしようとする
データベースのテーブルは、ドメインクラス名のよい情報源になるが、ドメインモデルは、オブジェクトモデルのコンテキストで考えるべき。 - フレンド関係やパラメータ化クラスのような実装の構成要素を登場させる
ドメインモデリングの焦点は、問題空間であるべき。 - PortfolioManager のような直観的な名前でなく cPortMgrIntf のような名前を使用する
ドメインモデリングの目的のひとつは、プロジェクトの全員が重要な抽象名に合意することである。 - 問題空間をモデル化せず具体的な実装方法を考える
RDB やサーバのような特定の技術に依存する内容を含めるべきではない。 - 各 a part of 関連に集約とコンポジションのどちらを使うかを議論する
ドメインモデリングの段階では、とりあえず集約を使用しておけばよい。 - 要求を満たすかを確認する前に再利用性のための最適化を行う
ドメインモデリングではクラスに操作を割り当てるべきではなく、再利用を考える段階でもない。 - ユースケースとシーケンス図を吟味せずにクラスに操作を割り当てる
ドメインモデルの段階では情報が十分ではないので、クラスに操作を割り当てるべきではない。 - 過度に名詞と動詞の分析を行う
オブジェクトの識別に没頭しすぎて、抽象度の低い抽象化にならないように。 - 関連に多重度を割り当てる
ドメインモデリングの段階では多重度を考えない方がよい。分析中毒の原因になる。