ユースケース駆動開発実践ガイド

「ユースケース駆動開発実践ガイド」を読んで、この手法がまさにRUPなんだな、とようやく気づいた。
理解した内容をまとめてみる。
＃一部はメモなので論理的整合性は無視。

【1】ドメインモデルはプロジェクトの用語集

　「ユースケース駆動開発実践ガイド」では、プロジェクトで実際に使われている単語を全て収録した「生きている」辞書だ。
　単なるプロジェクトの用語集よりもはるかに優れている。
　それぞれの単語間の関係がグラフィカルに表現されているから。

【2】ユースケースは叙述的に書く

　「ユースケース駆動開発実践ガイド」では、ユースケースに「～しなければならない」という命令形が混じる時がある。
　機能要求は「～しなければならない」のように指示的に書かれた要求。
　機能要求を分離してユースケースに割り当てなければならない。

　ユースケースに機能要求が混在している時は、ユースケースが良くない兆候。
　ユースケースは要求とリンクしているが、要求から分離すべきもの。
　ユースケースは、実行時の振る舞い要求だから。

　ユースケースから機能要求は省く。
　ユースケースに機能要求が混在していると、オブジェクトモデルの用語で記述できなくなる。

　また、ユースケースの汎化は無意味だ。
　ユースケースの汎化を書くと、それはユースケースの具体例に過ぎない。
　ユースケースはクラスではない。
　ユースケースはユーザーガイドの断片。

　手続き型の発想でユースケースを書くと、「～させる」という受動態が多い。
　オブジェクト指向の発想でユースケースを書くと「～画面が～する」のような能動態が多くなる。

　イベントとその応答の流れとしてユースケースを書く。
　ユースケースはユーザーとシステムの対話が記述されている。

　ユースケース中の単語はドメインモデルに合わせる。
　ユースケースはオブジェクトモデルの用語で記述されるべき。

　外部システムは常にアクターとしてモデル化される。

　また、長いユースケーステンプレートは良くない兆候だ。
　ユースケース内に長い機能要求のリストを含めるべきではない。
　ユーザがシステムをどのように使うか、システムがどのように応答するかを書くだけ。
　ユースケースとアルゴリズムは違うから。

　ユースケース図はパッケージごとの図式化された目次。

　ユースケースには、必ず正常フローと代替フローを必ず明記する。
　ソフトウェアプロジェクトの複雑性の半分以上は、代替コースを扱うことで生じる。
　全ての代替コースを担保していることを確実にするのが重要。
　

【3】ロバストネス図こそ要求と設計の間のミッシングリング

　「ユースケース駆動開発実践ガイド」では、ユースケースからオブジェクトモデルを導出する技術として、ロバストネス図が大事。
　ロバストネス図は、ユースケースをオブジェクトの絵として表現したもの
　取りこぼしていたオブジェクトがロバストネス分析中で発見される過程を「オブジェクトの発見」と呼ぶらしい。

　バウンダリオブジェクトは画面単位に作る。
　用語体系の統制にもなる。
　バウンダリオブジェクトに対する明確な命名ができる。

　コントローラーは論理的なソフトウェア機能である。
　最近のシステム開発では、コントローラーを使いすぎる傾向が多い。
　だが、コントローラーを抽出する時、「～を表示する」コントローラーが多くなる。
　表示するコントローラーは必要だ。存在意義がある。

　ロバストネス図では、オブジェクトと機能を混在させて表示する。
　コラボレーション図と本質的に違う。

　シーケンス図上にはコントローラーオブジェクトが存在しない。
　コントローラーの80%は操作として実装される。
　つまり、バウンダリやエンティティのメソッドとして吸収される。

　ユースケース記述をシーケンス図に貼り付ける。
　要求から振る舞いを設計する時に役立つ。

　いかにコントローラーをドメインクラスの操作へと進化させるか、が大事だし、最も難しい。
　基本思想は、責任駆動。
　基本アーキテクチャは、凝集性の最大化、結合の最小化。

　「ユースケース駆動開発実践ガイド」は、ユースケース記述と実際のプログラミングの間にある大きいギャップを埋めるノウハウが書かれているように思う。

【4】ユースケースをTestlinkで保守する

　TestLinkというオープンソースのテスト管理Webツールがある。

　Testlinkを使うと、要求とユースケース、テストケースを登録すれば、理論上は一貫してトレースできる。
　プロジェクト管理ツールRedmineと同様に、要注目のツールだと思う。