なぜ書くか
- ユースケースからロバストネス図を書くことによって、振る舞いが整理され実装時にあれこれ悩まなくても良い
ロバストネス分析
- ユースケースから詳細設計（とコード）を作成するには、ユースケースをオブジェクトに関連付ける必要がある。その「関連付け」を行い分析と設計のギャップを埋める
- ユースケースをオブジェクトの絵として表現したもの
- ユースケースに示された振る舞いを図式化したもの
- どの振る舞いがどのクラスの責務となるかはあえて示さず、ここのクラスはグラフィカルなステレオタイプのアイコンによって表される。
クラスステレオタイプ
- バウンダリオブジェクト（名詞）
システムと外部世界との「インターフェイス」 - エンティティオブジェクト（名詞）
ドメインモデル上のクラス - コントローラ（動詞）
バウンダリとエンティティの接着剤
規則
- 名詞は動詞とつなぐことができる。
- 名詞を他の名詞につなぐことができない。
- 動詞は他の動詞とつなぐことができる。
これらの規則に違うことで、「名詞ー動詞ー名詞」の形式でユースケース記述を確実にパターン化できる
ロバストネス分析は、ユースケースに対する健全性のチェックになる。
ガイドライン
- ユースケース記述をロバストネス図に直接貼り付ける。
これにより、ユースケースに記述されている内容をオブジェクトの絵として書いているという事実が、強く認識できる。 - ドメインモデルからエンティティクラスを取り出し、不足しているものがあれば追加する。
当然ながら取りこぼしたドメインクラスがあるかもしれない。発見したら追加する。 - ロバストネス図作成時中にも、ユースケース図記述を書き直して明確にすることがある。
ロバストネス図を書くためには、ユースケースを順に１文づつ見ていかなければならないため。 - 画面単位にバウンダリオブジェクトを作成し、明確な画面名をつける。
- コントローラは、本物のコントロールオブジェクトになることがあるかもしれないということを忘れない。これらは通常、論理的なソフトウェア機能にすぎない。
- ロバストネス図上の矢印の方向については気にしない。
ロバストネス図を書く目的。
* ユースケース記述から曖昧さを取り除く
* ドメインモデル内で見逃したオブジェクトの発見を助ける - 親のユースケースから起動するのであれば、ユースケースをロバストネス図上にドラッグ可。
- ロバストネス図はユースケースに対する予備的な概念設計を示している。文字通りの詳細設計ではない。
* 設計前に要求を完全に理解することは素晴らしい
* 試験的な設計を行うことなしに、要求を完全に理解することは不可能
実際の設計を行う前に、振る舞い要求を検証する目的で概念的な設計を行う。 - 一般的に、ロバストネス図上のバウンダリオブジェクトとエンティティクラスはシーケンス図上のオブジェクトインスタンスとなる。コントローラはシーケンス図上のメッセージとなる。
- ロバストネス図はユースケースの「オブジェクトの絵」である。その目的はユースケースの記述とオブジェクトモデルの両方を強制的に洗練させることである。