前回のまとめ
[ICONIXプロセス]
第5章 ロバストネス分析
ロバストネス図は、ユースケースをオブジェクトの絵として表現したもの。
ロバストネス分析は、分析と設計の間に位置する予備設計のプロセス。
ロバストネス図の構造
- ロバストネス図は、ユースケースに示された振る舞いを図式化したもので、クラスとソフトウェア両方の振る舞いを示している。
- ロバストネス図における動作の流れと、ユースケース記述で説明されたステップの間には、1対1の相関関係がある。
- バウンダリオブジェクト：インターフェース(通常は画面かWebページ) [名詞]
- エンティティオブジェクト：ドメインモデル上のクラス [名詞]
- コントローラ：バウンダリオブジェクトとエンティティオブジェクトの間の接着剤的役割。 [動詞]
[ロバストネス図のルール]
- アクターはバウンダリオブジェクトと関係を持つことができる
- 名詞と動詞はつなげることができる
- 名詞同士、動詞同士でつなげることはできない
※ もし上記のルールで図を描くことが難しければ、ユースケース自体に問題がある可能性がある。
ロバストネス分析のガイドライン
- ユースケース記述をロバストネス図に直接貼り付ける
- ドメインモデルからエンティティクラスを取り出し、不足しているものがあれば追加する
- ロバストネス図の作成中にも、ユースケース記述を書き直すことがある
- 画面単位にバウンダリオブジェクトを作成する
- コントローラは通常、論理的なソフトウェア機能であるということを忘れない
- ロバストネス図上の矢印の方向を気にしない
- 呼出し元のユースケースをロバストネス図上に置く
- ロバストネス図はユースケースに対する予備的な概念設計を示している
- 試験的な設計を行うことなしに、要求を完全に理解することはほぼ不可能
- よって、実際の設計を行う前に、振る舞い要求を検証する目的で概念的な設計を行う
- ロバストネス図上のオブジェクトは詳細設計へと姿を変える
- ロバストネス図はユースケースの「オブジェクトの絵」であることを忘れない
第6章 予備設計レビュー
予備設計レビューでは、ロバストネス図、ドメインモデル、及びユースケース記述の辻褄がすべて合っていることを確認する。
- このレビューは、プロセス中で顧客が直接介在する最後の作業になる(詳細設計に入る前に合意を取る必要がある)
- 顧客が新しい要求を加えたくなった場合、その要求については最初のステップ(ドメインモデル変更)から踏み直す必要がある
予備設計レビューガイドライン
- ユースケース記述とロバストネス図が一致しているかどうか蛍光ペンでチェックする
- すべてのエンティティが、更新後のドメインモデルに確実に存在すること
- オブジェクトの発見がロバストネス分析の主目的のひとつ
- エンティティクラスと画面の間で、データの流れを確実に追跡できるようにする
- 代替コースと、それらの振る舞いを明示する
- 各ユースケースでユーザー/システム間の対話が確実にカバーされるようにする
- ロバストネス図の構文ルールを破っていないことを確認する
- 構文ルールを破っている=分析にミスがある可能性が高い
- 技術者意外と技術者の双方をレビューに参加させる
- ユースケースがオブジェクトモデルとGUIの用語で記述されていることを確認する
- 詳細設計の領域に踏み込まない
- クラスに対する振る舞いの割り当てなどは、この工程でやってはいけない。詳細すぎる
- より良い予備設計のための「6つの簡単な手順」に従う
[6つの手順] ロバストネス図に対してチェックを行う
- 図がユースケース記述に合致しているか
- 図がロバストネス分析の規則に従っているか
- 図がユースケースの論理的な流れに注力しているか
- ユースケースの動作に必要となるすべての代替コースが、図に示されているかどうか
- 図がデザインパターン狂(?)になってないか
- 図が詳細設計に踏み込んでないか
感想
- この本って実演形式の説明や練習問題がすごく効果的なんだけど、ここにまとめるのはコストが高すぎるので要点の羅列にとどめています
- もしこの本を読まずに私の記事を見てくれている人がいたら、購入して実際に練習問題をやってみた方が絶対に良いです
