■■前回までのまとめ■■
要件定義で役立つ図：
・ドメインモデル図（概念モデル図） →自然言語レベルのクラス図のこと。用語整理に用いる。
・ユースケース図 →機能一覧。各ユースケースに対してユースケース記述がある。

詳細設計で役立つ図：
・クラス図 →クラスとそれらの間の関係を表す静的設計図。
・シーケンス図 →オブジェクトの振る舞いを表す動的設計図。

さて、それではどうやって要件定義から詳細設計への長いギャップを埋めればよいのでしょうか？
今回解説するロバストネス図は、まさにそのギャップを埋めるための図です。

■■ロバストネス図を描こう■■
ロバストネス図とは、ユースケース記述を絵にした図で、以下の三兄弟アイコンを用います。

・バウンダリ：画面
・コントロール：システムが行う1つ1つの処理
・エンティティ：ドメインモデルが実体化したもの

では、『商品の詳細を表示する』ユースケースのロバストネス図を描いてみます。

●ステップ1/2：基本コースを絵にする
基本コースを1文ずつ読んで、三兄弟アイコンを用いて図に起こします。
処理の移り変わりは、矢印で表現します。

（分かりやすいように三兄弟アイコンの種別ごとに色分けしています。）

ここで注意すべきは、コントロールはあくまで「システムの」処理なので、
ユーザの行動はコントロールではなく矢印のラベルとして表現するということです。

●ステップ2/2：代替コースをすべて絵に加え、表現が曖昧な記述は修正する

これでロバストネス図が完成し、基本コースと代替コースを1枚の絵で表現できたことになります。
最初は見慣れない図で混乱するかもしれませんが、2,3枚描けばすぐに感覚がつかめるはずです。

（ところで「商品の詳細を取得する」と「商品」の間が矢印ではなく普通の線になっていますが、
これは、矢印にするとエンティティで行き止まりになるためです。）

ロバストネス図を描く目的は、詳細設計に踏み込む前に要件の曖昧さを除去することです。
ロバストネス図を描くことで、ユースケース記述やドメインモデル図を
より明確で漏れのない「丈夫な（ロバストな）」ものにすることができます。
要点としては第一に、ロバストネス図を描きながらユースケース記述に不足や曖昧さが無いかチェックすることです。第二の要点は、エンティティに対応するドメインクラスがドメインモデル図に無ければ、逐一ドメインモデル図に追加することです。

■■ロバストネス図の秘密■■

●コントロールは何から生まれ、何に成るのか？
ユースケース記述の各文の主語として考えられるのは、「（設計対象の）システム」「利用者」「外部システム」の3種類です。
ここで主語が「システム」になっている文は特に重要です。この文の動詞こそが、
「システムがすべきこと＝実装すべき処理＝コントロール」になります。

その動詞がロバストネス図上ではコントロールとして現れ、
最終的には、いずれかのクラスのメソッド（複数可）に成ります。

したがって、

主語がシステムとなっている文の動詞 (＠ユースケース記述)
↓
コントロール (＠ロバストネス図)
↓
いずれかのクラスのメソッド (＠シーケンス図)

という風に化けます。

ということは、
SVO形式でユースケース記述をつらつら書くだけで、無意識に実装すべき処理を洗い出していることになります。
ユースケース記述なんて誰でも書けますから最初は地味に思えるのですが、実はこういったカラクリが潜んでいたのです。
（ICONIX流の）ロバストネス図は、ユースケース駆動開発において最も重要な図と言っても過言ではありません。

●エンティティはドメインモデルの実体
ドメインモデル図に出てくる「商品」は、商品という概念を表す分類子です。
一方、ユースケース記述の文中に出てくる「商品」は、特定の商品を指しますから、ドメインクラス「商品」の実体です。
例えば「システムは、入力内容を元に商品を新規登録する。」と言った場合の「商品」は実体を表しています。
つまり、ドメインモデル図は結局、エンティティたちのクラス図でもあったのです。
これを念頭に入れておけば、ドメインモデル図とロバストネス図の間の整合性を取りやすくなるでしょう。

●コントロールはユニットテストの良い対象
コントロールは、ユースケース記述つまりは要件から導出されたものです。
よってコントロールをユニットテスト項目とすれば、テスト項目が確実に要件に結びつきます。まさに理想のテストです。
コントロールは、シーケンス図上では1つ以上のメソッドに対応するので、
実際はそれらのメソッドをテスト対象とすることになります。
ロバストネス図を見れば何をテストすべきかが分かるということは、大きなメリットといえます。

■■まとめ■■
・ロバストネス図は、要件を明確化することで「丈夫な」設計を導く
・ユースケース記述を1枚の絵にできるため、基本設計レビューや仕様伝達に便利
・ユニットテストではコントロールをテスト項目とする

次回は、ロバストネス図からシーケンス図を起こす方法について書こうかなと思っています。

      
参考文献
[1] Doug Rosenberg and Matt Stephens, Use Case Driven Object Modeling with UML: Theory and Practice. Apress, 2007.
[2] Doug Rosenberg and Matt Stephens, Design Driven Testing: Test Smater, Not Harder. Apress, 2010.