ユースケース駆動開発実践ガイドのまとめ 〜ICONIXプロセスとはなんなのか〜
この記事について
「ユースケース駆動開発実践ガイド」の内容を簡単に整理した記事です。
自分の理解を元に記述しているので、誤りなどがあれば指摘いただけると泣いて喜びます・・・！
ICONIXプロセスとは？
「アイコニクス」と読みます。
最小限のUMLを用いる、ユースケースを中心とした設計で、保守性が高く要求を満たすコードを実現する手法です。
ICONIXプロセスの全体像
本書内で用いられる全体像を示す図があるのですが、フローとして理解するには難解に感じたので、自分の理解で再整理。
※本来は要求レビュー、設計レビューのようなマイルストーンが発生しますが、図の中では省略しています。
ドラフトとして作成した初期のドメインモデルが、以降のユースケース駆動プロセスを通じて最終的にはクラス図に変化します。
以降では各プロセスの概要をまとめました。
プロセスの全体像をざっくり理解するのが目的なので、本書内に書かれているレビュープロセスやテストの詳細については省略しています。
要求定義
ドメインモデリング
ドメインモデリングでは、抽象度の高い要求を元にドメインクラスを抽出し、ドメインモデル図を作成します。
- 作業は2時間に限定する。（この時点では不完全という前提でICONIXプロセスが成り立っている）
- 現実世界のオブジェクトに焦点を合わせ、データベース設計やクラス設計と混同しない。
- 属性や振る舞いは記述せず、シンプルなドメイン名のみでモデリングを行う。
- 多重度の記述、デザインパターンの適用なども時期尚早。
- 汎化（is-a）・集約（has-a）関係を用いる。
上述したとおり、この時点のドメインモデルは不完全な前提です。
後続のプロセスの中で何度も修正されます。
ユースケースモデリング
ユースケース図とユースケース記述を作成します。
「ユースケース駆動開発」というタイトルが示す通り、ユースケースはクラス図と合わせて全体の中心となるアウトプットで、この後のプロセスで何度も立ち返ることになります。
「ユースケース」というと棒人間のアクターを用いたユースケース図のイメージが強いですが、本書の中では文章でまとめたユースケース記述により重点を置いています。
追記
本書からは読み取れていなかったのですが、
- 全体のユースケース図を書く
- ↑の各ユースケース毎にユースケース記述（以降で説明）を書く
という流れで作成するのが良いようです。
（実践しつつ経験者のお話を聞いてわかりました）
追記ここまで
ユースケース記述時に意識すべきポイントは以下。
- ドメインモデルの用語を用いる。
- バウンダリクラス（主に画面名）の名前を使う。
- ユーザーとシステムの対話の両側を記述する。
- 指示的ではなく叙述的に書く。
- ×ユーザーは著者名で検索できる。 ○ユーザーが著者名を入力して「検索」ボタンを押す。システムは著者名に一致する書籍一覧を検索結果画面に表示する。
- 基本コース（いわゆる正常系）と代替コース（いわゆる異常系）を記述する。
- ユースケース図上のの「関係」を正確に記述することを頑張らない。
- ほとんどの場合、ユースケース図の関係は invokes、precedes で十分で、extends や includes が必要になる機会は少ない。
上記を踏まえて本書の例に示されたユースケース記述の例です。
基本コース：
顧客は書店のホームページのURLを入力し、システムはそれを表示する。それから、顧客は書籍を見るためのリンクをクリックする。システムは書籍詳細を取得し、書籍詳細画面を表示する。代替コース：
書籍が見つからなかった場合： システムは「書籍詳細が見つかりません」画面を表示する。
完成したユースケースを元に、ドメインモデルの不足箇所を見つけてアップデートします。
以降のプロセスは、各ユースケース（e.g. 書籍詳細を表示する）毎に実施します。
分析/概念設計/テクニカルアーキテクチャ
ロバストネス分析
ここで作成するロバストネス図は UML には含まれず、ICONIXプロセスを最も特徴づける工程と言えるのではないのでしょうか。
概念設計（外部設計）のプロセスで、ロバストネス図を用いて詳細設計と要求定義の間を埋める作業を行います。
ロバストネス図のルールは以下の通り。
- バウンダリオブジェクト（画面）、エンティティオブジェクト（ドメインモデル上のクラス）、コントローラ（バウンダリとエンティティの「接着剤」）の3種類のオブジェクトで表現する。
- バウンダリとエンティティは名詞、コントローラは動詞として捉え、「名詞-名詞」にならないように表現する。
- ×バウンダリ-エンティティ ○バウンダリ-コントローラ-エンティティ
- ユースケース記述に合致させて表現する。
- 代替コースも漏れなく記述する。
- 詳細設計に踏み込まない。
以下の図は私が練習のために「ショッピングカートに商品を追加する」ユースケースを想定して作成してみたものです。
ロバストネス図の作成を通じて、ユースケースの曖昧さやドメインモデルに追加可能な属性を発見し、それぞれを更新します。
テクニカルアーキテクチャ
機能要求・非機能要件を踏まえてシステムアーキテクチャを決定するプロセス。
ハードウェア・フレームワークの決定、レイヤー分割やライフサイクルの記述などを行いアーキテクチャを決定する。
章のにまとめに書いてある通り、作業内容自体はICONIXの本質ではなく、プロジェクトによって様々なのでここでも深く触れないことにします。
設計/コーディング
シーケンス図
基本的には通常見慣れたシーケンス図と変わりませんが、ロバストネス図のアクター・バウンダリオブジェクト・エンティティオブジェクトをここでもオブジェクトとして用います。
原則、コントローラオブジェクトはシーケンス図上のメッセージ（エンティティ・バウンダリの操作）に変換します。
場合によってはコントロールクラスが必要になる場合もあります。
シーケンス図作成に当たって留意するポイントを以下にまとめます。
- 代替コースも含む、各ユースケースのアクション全てを表現する。
- 「どのコントローラをどのクラスに割り当てるか」を検討する。
- 責務駆動（機能データが存在するところに割り当てられるべき）の考えを中心に設計すること。
- 静的モデルをシーケンス図と同期させる。
シーケンス図を作成しながら/作成し終わったら、ドメインモデルにクラス・属性・操作を追加して、クラス図を完成させます。
また、ユースケースの不足や不備を見つけたら修正しておきます。
ロバストネス図は厳密に一致させる必要はありません。
実装
ここまでの設計・レビューがしっかり行われていればあとはコードに落とし込むだけ、というのが基本的な考え方です。
以下に留意しながらコードを書きます。
- 設計の不備を見つけたら設計を修正し、コードと同期させる。
- コードと同時に単体テストを書く。
- 後ろの章では、コーディングに着手する前にロバストネス図から単体テストを作成しておくことが推奨されています。
- フレームワークの制約により設計が実現困難な場合、フレームワークの変更も検討する。
以降、テストのプロセスについても記述がありますが、一般的に言われているとと大きな差を感じなかったので省略します。
まとめ
冒頭に書いた通り、「最小限の」UML（およびロバストネス図）で要求をコードまで落とし込めそうですね。
全体を通じてのポイントは以下の２点かと思います。
- 最初に作成したドメインモデルが、以降の各プロセスを通じてクラス図へ進化を遂げること。
- ユースケースを常に各プロセスのアウトプットと同期させること。
スモールスタートでスピーディな立ち上げを目指すベンチャーのような開発では上流工程は省略気味になることも多いですが、ICONIX プロセスであればスピードを損なわず恩恵を受けられそうな印象。
次回相性の良さそうな案件があればトライしてみます。
Discussion