読んだ : ユースケース駆動開発実践ガイド

作者: ダグ・ローゼンバーグ,Doug Rosenberg,三河淳一,船木健児,佐藤竜一
出版社/メーカー: 翔泳社
発売日: 2007/10/17
メディア: 大型本
購入: 11人クリック: 105回
この商品を含むブログ (33件) を見る

ユースケースを出発点とする開発プロセスを学びたかったので読んだ。ちなみにこの書籍が言っている「ユースケース」というのは Ivar Jacobson (イヴァー・ヤコブソン) によるものであり、Uncle Bob の Clean Architecture が言う「ユースケース」と (基本的には) 同じものである *1。

結論から言うと、本書は個人的に学びの多いものであった。私は「DDD を実際の開発プロセスにどう取り込んでいくと良いか？」「Clean Architecture でいうところの UseCases 層のメソッドって具体的にどういう粒度で書くことになるのか？」といったところを知りたかったのだが、非常に参考になった。また、ちゃんとした要求定義・要件定義などの経験がなく *2 て、要求定義を含んだ開発プロセスについても学びたかったので、その点を学ぶことができたのも良かった。

古い本ではあるが、開発プロセスを概念的に理解するという目的であれば現代でも十分に通用するものだと感じる。不要な内容もそれなりにある *3 が、そこはいい感じに飛ばして読むと良いだろう。

内容 : 開発プロセス概要

本書で述べられている開発プロセスは ICONIX プロセスと呼ばれるものである。大まかな流れは以下のようになる。

f:id:nobuoka:20190217132851p:plain — ICONIX プロセス

要求定義から始まり、実装・テストまで静的モデルと動的モデルをブラッシュアップしながら進めていく。全体の流れを説明すると下記のようになる。

要求定義
- 機能要求 : システムができることの定義。プロジェクトの組織化によって開発チームが機能要求の抽出に加わるのか、顧客やビジネス分析者が機能要求を開発チームに伝えるのかが決まる。
- ドメインモデリング : 問題領域からユビキタス言語を定義し、単語間の関連を表現する。
- 振る舞い要求 : 紙芝居から始めて、アクター (ユーザー) とシステムがどう対話するかをユースケースとして記述する。
- 要求レビュー : ユースケース記述が顧客の要望に応えているかレビューする。ユースケースごとに行っても良い。
分析・予備設計レビュー : 個別のイテレーションごとに (= ユースケースの小さな単位で) 下記を行う。
- ロバストネス分析
  - ユースケース記述とドメインモデルをブラッシュアップしながら進める。
- 予備設計レビュー
- テクニカルアーキテクチャもここで
詳細設計
- シーケンス図の作成
- ドメインオブジェクトに振る舞いを追加して、クラスモデルに昇華
- 詳細設計レビュー
実装
- コーディングと単体テスト
- 統合テストとシナリオテスト

ICONIX プロセスの特徴はロバストネス分析にあるらしく、ロバストネス分析により「ユースケースとシーケンス図の間のギャップが大きく、ユースケースとシーケンス図がうまく対応付けられていない」という状況が起こることを避けられるらしい。

ユースケースについて

Jacobson の「ユースケース」と言っても、いろいろ流儀があるらしい。本書では、ユースケースの記述として下記を重要と言っている。

イベントとその応答として、アクター (ユーザー) とシステムの対話を記述すること。すなわち、ユーザーがどういう操作をするのかだけでなく、システムの挙動も記述する。
UI についても考慮する。 GUI プロトタイプや画面モックアップを使用する。
ドメインモデル中の言葉や、画面のようなバウンダリクラスの名前を使って記述する。
代替コース (「雨の日」のシナリオ) (バリデーションエラー時のシステムの応答など) を忘れないようにする。
ユースケース記述は叙述的にする。要求自体をユースケース記述に含めたりはしない。 (要求は別に管理し、要求を満たすようにユースケースを記述すれば良い。)

思ったことなど

アジャイルなプロセスに適用できるのか？

本書ではできると書かれている。私自身の実感としても可能だと感じた。

上流工程でのモデリングを、コーディングの前に少しだけ (1 回にひとつのユースケースに対してだけ) 行うのか、すべてのユースケースをコーディング前にモデリングするのかの判断は、あなたに任されています。 ICONIX プロセスを利用する場合、プロジェクトに応じてアジャイルに行う (短いイテレーションによって、短期間で連続的にリリースする) ことも、ウォーターフォール的に行う (まずすべての要求を記述し、設計を行い、それからコードを書く) ことも可能です。

ユースケース駆動開発とドメイン駆動設計 (DDD)

「ユースケース駆動開発」と聞くと DDD とは全然違う概念のように思うが、実際のところはドメインモデリングをするし、動的モデルをユースケース記述からブラッシュアップしていくのにあわせて静的モデル (ドメインモデル) をブラッシュアップするという開発プロセスなので、ある意味 DDD (の一部？) を包含しているように思う。 DDD で難しいのは「ドメインオブジェクトにどういう振る舞いを割り当てるのか」というところ *4 だと私は思っているのだが、ICONIX プロセスではユースケース記述中に出てくる動詞がドメインオブジェクトの振る舞いの候補となるので、DDD をやりやすいと感じた。

つまり、ドメインモデルを使う側 (ユースケース側) の記述をもとにドメインモデルに振る舞いを割り当てられるわけである。さらに言うと、そうすることでアプリケーション上のユースケースのステップに相当する処理がユースケース記述に近いものになり、実装を理解しやすくなるという利点もある。

ドキュメントを書くべきなのか？

ICONIX プロセスではドキュメント (ユースケース記述やドメインモデル、ロバストネス図やシーケンス図など) をしっかりと作り、コードの変更に合わせてドキュメントを更新していくという教えになっている。個人的には、ユースケース記述とユビキタス言語についてはドキュメント化はした方が良くて (= 非開発者とも共有するため)、それ以外の設計用のドキュメントについては開発チームの練度によるかなーという気はする。ユースケース記述とユビキタス言語から直接設計・実装に入れる場合も多々ありそうなので、必要に応じてで良さそう。ロバストネス図やシーケンス図をしっかりと書くことでユースケースやドメインモデルのブラッシュアップに効くというのはわかるので、それを明示されたモデル上でやるのか、頭の中でやるのか、実際のコード上でやるのか、みたいな話になりそう。

Clean Architecture でいう UseCases との関係

冒頭でも述べた通り、Clean Architecture におけるユースケースも Jacobson のユースケースがもとになっている。『Clean Architecture 達人に学ぶソフトウェアの構造と設計』には、ユースケースについて『ユーザーとエンティティのインタラクションを支配するアプリケーション固有のルールを記述したものである』と書かれており、基本的には本書のユースケースと同じものを表している思って良いだろう。ただ、ユースケースの例を見るとシステムの挙動しか表していなかったり、『ユースケースは、ユーザーインターフェイスについては記述していない』と書かれていたりして、やや差異はあるようだ。ここら辺はユースケースの書き方の流儀の違いなどによるものだと思われる。

UseCases 層の実装として、『ユースケースはオブジェクトである。アプリケーション固有のビジネスルールを実装した関数を1つ以上持っている。』と書かれている。これをそのまま受け取ると、1 ユースケースに対して 1 つの UseCase クラスを用意し、ユースケース記述におけるシステムの応答のステップのひとまとまりを 1 メソッドとして実装する (ユースケースに複数の応答がある場合などは複数メソッドを定義する) という感じになりそう？

とはいえ Android だと非同期処理とか画面遷移とかで 1 ユースケースを 1 クラスで実装するのは設計的にやりにくい気もするので、「UseCases 層のメソッドはユースケース記述の粒度で実装する」ぐらいの感じで設計すれば良さそう。

ユースケース記述に技術的な内容を含めて良いか

例えば「キャッシュ」の扱いなど。個人的にはユーザーから検知できるものであればユースケースに含めるべきなきはしている。

例えばブラウザでスーパーリロードするとキャッシュがあっても再読み込みする、みたいな場合、ユーザーからキャッシュの存在が見えるわけなので、ユースケース記述に含めるべきな気がする。キャッシュの有無がユーザーから見える挙動に全く影響を与えない、本当にパフォーマンスのためだけのキャッシュだったらユースケースに含めない方が良さそう。