『オブジェクトデザイン』読書メモ：第 2 章「責務駆動設計」
前回分（第 1 章）はこちら。
2 責務駆動設計
- 責務駆動設計についておおまかに説明
- 分析とオブジェクトの発見
- 責務の割り当て
- コラボレーションの設計
- それぞれの詳細は後の章で説明
2.1 見て、記述して、設計するためのプロセス
-
責務駆動設計
- アプリケーションの果たすべき責務を担うオブジェクトとそのコラボレーションを設計
- やり直ししづらい硬直化したプロセスではない
- 臨機応変、反復的、インクリメンタル
-
流れ
- プロジェクトの計画
- ユーザの要求などに基づいた分析の記述
- 設計の実施
- 探究的な設計
- 設計の洗練
-
ユーザ、業務分析担当者、テスト担当者といった利害関係者のそれぞれが持つ異なる関心事をできるだけ満たすように設計
2.2 台本を書く：分析の記述
-
要求を単純かつ明確な言語でアプリケーションの責務として表現
- アプリケーションの担当範囲（責務）を把握
-
ユースケースによる分析の記述
- アクターとアプリケーションの相互作用を記述
- アクター視点のユースケース記述からアプリケーションの責務を導出
- 以下の 3 形式を記述に利用
- 散文（ユーザから見た機能の記述）
- シナリオ（特定機能の実行手続きの記述）
- 会話（ユーザの操作とシステムの反応の対応表）
- ユーザを含む利害関係者が理解可能なレベルでの記述も可能
UML のユースケース図は、あくまでも上記形式によるユースケース記述の補助として利用されるものらしい（『UML モデリングのエッセンス』参照）。
- 概念オブジェクトの抽出
- 記述した分析結果から、アプリケーションの対象ドメインにおけるオブジェクト候補を抽出
- ワープロソフトなら文書、段落、スペルチェッカーなど
2.3 登場人物の配役：探究的設計
-
概念オブジェクトのレビュー
- ロールと責務の追加により設計オブジェクトへ変換
-
設計方法
- CRC カードの利用
- デザインパターンの利用
- 分析と設計の往復
- 分析時に発見した責務をオブジェクトに割り当ててみる
分析で抽出した概念オブジェクトから、実際のオブジェクト群へと変換するために、上記手法を活用する。
2.4 制作をチューニングする：設計の洗練
- 以下の観点で洗練
- コラボレーションスタイル
- 拡張性
- 理解しやすさ
- 頑健性