ユースケース駆動開発実践ガイドメモ
ユースケース駆動開発実践ガイドの読書メモ
ICONIXプロセストとは
ドメインモデリングによって対象領域を理解し、ユースケースを書くことで顧客の要求を目に見える形でまとめ上げ、ロバストネス図によってソフトウェアの振る舞いを明確化し、シーケンス図によって振る舞いをオブジェクトに割り当てる。ロバストネス分析によりソフトウェアの振る舞いを具体化することで顧客との要求とのズレが起きないようするというプロセスがICONIXには組み込まれている。 ICONIXプロセスではユースケースからソースコードを作っており、小さなユースケース群毎での開発・テストが行えるためアジャイルプロジェクトに適合しやすい。
ユースケースから曖昧さを排除し具体的で明確にする
ICONIXプロセス
ICONIXプロセスは以下の工程で行われる
- 要件定義
- 分析/概念設計
- マイルストーン2/予備設計レビュー
- 詳細設計
- シーケンス図作成
- クラス図作成
- マイルストーン3/詳細設計レビュー
- 実装
- コーディングと単体テスト
- 統合テストとシナリオテスト
- コードレビューとモデルの更新
要件定義
ドメインモデリング
ITプロジェクトではコミュニケーションでの齟齬が発生しやすい。例えばある人が"書籍のレビュー"と言ったとき、ある人は"編集者レビュー"だと思い、他のある人は"顧客レビュー"だと解釈すると言ったことが発生する。この様な誤解はドメインモデリングによりプロジェクト内の言語を統一することが問題解決に役立ちます。
オブジェクト同士の凡化・集約を図示化する。
凡化、集約はドメインモデルで重要なクラス間の関係で、クラス間の関係の95%はこれで表せられるらしい。一番最初のドメインモデルを書くときはクラスの属性などの詳細は考えなくても良い。
ドメインモデルとデータモデル、データベースのテーブルを混同しない
ドメインモデルとデータベースのテーブルなどは常に一致しているわけでなくインピーダンスミスマッチが生じることもある。
どうやってモデリングをするのか？
要件の一覧からモデルとして使える名詞を抜き出してモデル間の関係、集約を簡単に書いてみる。それからメンバー間でのレビューを通してオブジェクト間の関係、集約に齟齬がなくなるようにする。この時点では詳細な内容まで書こうととしないで大枠を捉えられるようにする。
ドメインに関係するものだけをモデリングする。
ドメインモデルはドメイン領域のみを対象としてモデリングする。問題を最適化するためのヘルパークラスなどは対象外。
小さすぎる情報は一つのモデルとして独立させない
属性などの情報は小さすぎるのでドメインモデルのクラスにする
ユースケースモデリング
プロジェクトの最初の方に出される機能要求は思いつきなどで書かれたことが多く、そこから見積もりを作成を作ることは不安要素が多く困難です。最初の機能要求だけでなく顧客との会話や紙芝居を使った説明を通してユースケースモデリングを行うことで不安要素をなくすことができます。
アクターとユースケース図を使う
開発対象システムが外部とどうやり取りするかを具体化する。この時のシステムの外部からアクセスするのがアクターでほとんどはユーザ以外にも、外部システムなどもアクターに含まれます。
アクターとシステムの対話を具体的に書く
例えばログイン認証について、 ユーザはパスワードを使った認証方式でログインできる。 と言った機能要求があったとする。これだけだとユーザが行う操作、システムの振舞いが不明瞭なので以下のように具体化する。
ユーザはユーザ名とパスワードを入力して「ログイン」ボタンをクリックする。システムはユーザ名からユーザの情報を取り出し、パスワードをチェックする。パスワードが一致していたらユーザはシステムにログインする
ユースケースは実行時の振る舞いの仕様書である
上記例のようにユースケースは実行時の振る舞いを具体化するのが肝である。ICONIXプロセスではユースケース毎でシーケンス図を活用することでオブジェクトの振る舞いを明確化する。
マイルストーン1/要件レビュー
ユースケースモデリングまで完了したところで顧客を加えてレビューを行い認識合わせをする
- 要件レビューのポイント
ドメインモデルに記述されている言葉が顧客にも理解できるかを確認する
大枠の部分でドメインモデルが正しく、用語がレビュアーに伝わることを確認する。詳細なモデルはユースケースの分析を通して改善していく
ドメインモデルが、ドメインオブジェクトの関係を示していることを確認する
ドメインオブジェクト間での凡化、集約、関連などの関係がわかるようにする。
ユースケースがオブジェクトモデルの用語で記述されていることを確認する
ユースケースの曖昧さの大部分はしばしばユーザの用語でユースケースが記述されることから発生する。曖昧さを排除するためにも適切なドメインオブジェクトを使って書く。
GUIのプロトタイプや紙芝居でより具体的なイメージが伝わるようにする
全てのユーザの振る舞いを確実にユースケース中で説明するようにする。時間がかからないレベルで画面のモックを作ることでユーザが取りうる行動を調査するための手助けとなる。
分析/概念設計
ロバストネス分析
ロバストネス分析ではユースケース記述を分析し、ユースケースごとにオブジェクト群を推定する。
ロバストネス図で以下のように表す。
- ロバストネス分析のポイント
ユースケース記述をロバストネス図に直接貼り付ける
ユースケース図をそのままロバストネス図にする。例えばログインは以下のようになる。
ロバストネス図作成中でもユースケース図を修正する
ロバストネス図作成中にユースケースを1文ずつ見直すことで曖昧さを解消できることがある。そのためロバストネス図作成と並行してユースケース図の修正も行う。
画面ごとでバウンダリオブジェクトを作成する
ロバストネス図を描くことによって、バウンダリオブジェクトに対する明確な命名を行うことができる。
ロバストネス分析は概念設計であり詳細設計ではない
ロバストネス分析では、実際の設計を行う前の振る舞い要求を検証する目的で概念設計を行う。ロバストネス分析を行うことにより正確で明確なユースケースを書く能力が磨かれる。
予備設計レビュー
ロバストネス図、ドメインモデル、およびユースケース記述があっていることを確認して詳細設計に橋渡しを行う間のフェーズ。レビューの参加者は顧客、開発チーム、マネージャ。
- ユースケース記述とロバストネス図が一致しているかどうか確認する
- ロバストネス図上の全てのエンティティが更新後のドメインモデル上に存在させる
- 代替コース(エラー処理、バリデーションなど)が漏れていないか、代替コースに対する振る舞いが記述されているか確認する
- ユースケースがオブジェクトモデルとGUIの用語で記述されていること
- シーケンス図のレベルの詳細な内容にはなっていないこと
ロバストネス図上の全てのエンティティが更新後のドメインモデル上に存在させる
オブジェクトの発見こそがロバストネス分析の主目的の一つなので、見つけたらドメインモデルにも反映しないとあまり意味がない。
代替コース(エラー処理、バリデーションなど)が漏れていないか、代替コースに対する振る舞いが記述されているか確認する
最初のユースケースで漏れがちな想定外のケースについても具体化、明確化する。
ユースケースがオブジェクトモデルとGUIの用語で記述されていること
ドメインオブジェクトや画面の取り扱いで名前の曖昧さを排除しておけば多くの問題が解決できる
詳細設計
シーケンス図
ロバストネス分析、予備設計レビューを完了し詳細設計に進む準備ができました。予備設計はクラスを発見するための作業で詳細設計では振る舞いの割り当てを行います。
- シーケンス図作成のポイント
なぜシーケンス図を描くか理解する
シーケンス図作成ではクラスに対する責務の割り当て、ユースケースの生存期間中に各クラスが他のクラスとどの様に相互作用するかの提示、クラスに対する操作の割り当ての完了を目標としている
ロバストネス分析を完了させたところから始める
ロバストネス図作成によりオブジェクト間の相互作用が識別できる様になった。シーケンス図はロバストネス図の概念設計よりもさらに具体的かつ詳細な設計になる。
シーケンス図はオブジェクトがどのように働くかを示す道具として使う
シーケンス図の「目的」とは、相互作用するオブジェクトに振る舞いを割り当てること
