実際のソフトウェア開発を行う上で、「ユースケース」をどのように作り上げていけばいいのかということが、ケーススタディを進める感じで学べます。RUPという開発プロセスに従ってユースケースの最初の一歩から、設計の前までをわかりやすくまとめてあります。190ページ弱という結構量が少ない中、ユースケースの色々な使い方、ドキュメントのまとめ方が書かれています。
今まで読んできた中で、ユースケースについて書かれている本でこの本ほどわかりやすいと思えたものはまだないです。
特徴
本書は、ユースケースの使い方をケーススタディに沿って解説されています。カズ・タラ・デニス・リサの4人のアメリカ人(?)が、通信販売の会社を作るという設定で進められていきます。
要所要所で、ドキュメントの書き方や中身についての議論もあり、一貫した取り組みができるのが魅力的です。読み物としても筋が通っており、実際に読み進めながら一緒にドキュメントを作り上げていくと、さらに理解度が増すと思います。
本書のカバー範囲は、RUPという開発プロセス上でユースケースをいかにして使うかというところです。顧客の要求に沿って、ユースケースを書き始めるところから、シナリオの書き方、個々のユースケースからシステムレベルのユースケースへの広げ方、ドキュメントの書き方、レビューの仕方、設計への入り方と進んでいきます。
ユースケースに特化した本はいくつかありますが、ケーススタディに沿って進めている本書は、他のどの本よりも理解しやすいと思います。4人の登場人物の議論の仕方がいかにもアメリカチックですが、的を得た疑問点に対して、論理的に解答されているところはケーススタディならではのものだと思いました。
覚書き
リスク管理
リスク分析には、基地のリスク、その他の既知の市場要因、プロジェクトに関する仮定事項が含まれていなければならない。
システムの境界を考える
システムの境界を明確に識別すること。何がシステムの内部にあり、何がシステムの外部にあるかを見つけ出すことが大切。システムの内部にあるものに関しては、自分たちが責任を持たなくてはいけない。反対に、システムの外部にあるものに関しては、インターフェースのみに責任をもつ。
アクターは常にシステムの外部に存在する。クラス図やシーケンス図にアクターがいるときは、何かが間違っている証拠である。
UMLでは、ユースケースは常にアクターによって開始される。時間などによって起動されるユースケースがあるかもしれないが、その場合は通常、タイマーをアクターとみなす。
アクターとして宣言されれるものについての一つのルールとして、自分たちは管理しない。
シナリオ
検討しなければならないもの：基本機能、あらゆる代替手順、エラー条件、ユースケースの開始時に成り立たなければならない事前条件、ユースケースの終了時に成り立たなければならない事後条件
事後条件は、ユースケースがどの分岐、代替パスを通った場合でも常に成り立たなければならない。
シナリオはアクターの視点から書くもの。シナリオのステップはアクターから見えるか、アクターが容易に推測できるものでなければならない。
参考
- ユースケース入門
- UMLのエッセンスならこちら
- ユースケースに関して、非常に実践的な観点から解説してあります。(おすすめ)