前回のまとめ
[ICONIXプロセス]
第3章 ユースケースモデリング
ユースケースは、「ユーザーはこのシステムで何をしたいのか？」「ユーザーは何を得たいのか？」といった、基本的な疑問に答える助けになる
ユースケースの留意点
ユースケースモデリングのガイドライン
[システムの使い方]
- 2段落ルールに従う
- アクターとユースケース図を使ってユースケースを組織化する
- アクターはユーザーが行える「役割」を示す。アクターはシステムの外部にいる
- アクターがユースケースを遂行する
- ユースケースを叙述的に書く
- 指示的に記述すると、アクターとソフトウェアの振る舞いが隠されてしまう
- 叙述的にユーザーの視点からシステムを記述することで、ユースケースは誤解が少ないものになる
- イベントとその応答の流れとしてユースケースを書く
- ユースケースはユーザーとシステムとの対話
- 紙芝居やGUIプロトタイプ、画面のモックアップを使う
- ユースケースは実行時の振る舞いの仕様である
- 現在のリリースの全ユースケースごとに、オブジェクトがどのように作用するか詳細に示されたシーケンス図を書く
[オブジェクトモデルの単語の使い方]
- オブジェクトモデルの言葉を使ってユースケースを書く
- ユースケースとオブジェクトを結びつけることで、ユースケース駆動のオブジェクト指向設計ができるようになる
- 「名詞-名詞-動詞」という文の構図に従ってユースケースを書く
- 名詞：オブジェクトのインスタンス
- 動詞：オブジェクト間のメッセージ
- ドメインクラスの名前を使う
- バウンダリクラスの名前を使う
- 振る舞い要求を明確に記述するためには、振る舞いに含まれるユーザーインターフェースも明確に名づける必要がある
ユースケースの関係について
- ユースケースの関係(汎化・拡張等)は細かく議論する必要がない
第4章 要求レビュー
要求レビューの目的
ユースケースの最初のドラフト版が完成した段階で、純粋に記述されたシステムが顧客の要求に合致しているかを確認する。
要求レビューのガイドライン
- ドメインモデルが問題領域をカバーしていることを確認する
- 汎化関係や集約関係を示す
- is-a と has-a だけで、シンプルに関係を表現する
- 基本コースと代替コースの双方を叙述的に記述する
- 機能要求をユースケース記述中に紛れ込ませない
- 機能要求は分離させて、ユースケースに割り当てないといけない
- ユースケースをパッケージによって組織化する
- ユースケース図はパッケージごとの図式化された目次である
- ユースケースはオブジェクトモデル用語で記述する
- ユースケースはユーザーインターフェースの用語で記述する
- ユースケースはユーザーインターフェースに基づいたものにした方が良い
- ユースケースに関係する画面に明確な名前を付ける
- 紙芝居、線図、画面モックアップ、あるいはGUIプロトタイプを使いなさい
- あくまでモックアップはシンプルに
- ユーザーが発生させるシステムの振る舞いが何かに焦点を絞る
- 振る舞い要求はふさわしい人にレビューしてもらう
- 開発メンバー・ステークホルダー・ユーザー等、全員の合意を得ることが大事
- レビューを「より良いユースケースのための8つの簡単なステップ」に沿って構成する
[8つのステップ]
- ユースケースのスコープ外のものすべてを取り除く
- 指示的な記述を叙述的に変える
- ユースケース記述が抽象的すぎないことを確認する
- GUIを正確にイメージする
- 関係するドメインオブジェクトに名前を付ける
- すべての代替コースが存在することを確認する
- ユーザーケースから、すべての要求を追跡する
- ユーザーの望むことが、個々のユースケースに記述されているかどうか確認する
