ユースケース駆動開発実践ガイド

なぜ、オブジェクト指向“らしく”ならないのか? 設計を強くするための教科書。オブジェクト指向開発の保守本流。必要最小限のステップでユースケースから保守性が高く動作するコードを得るための手法がここに。分析麻痺に陥らないための思考プロセスを、理論、実践、練習の 3 ステップを通して完全理解。

ユースケースを書いた後、それをどうクラスとコードに落とすのかという分析と設計の道筋を、ICONIX プロセスという手順に沿って一冊で示した教科書が『ユースケース駆動開発実践ガイド』 (ダグ・ローゼンバーグ、マット・ステファン 著、三河 淳一 監訳、佐藤 竜一、船木 健児 訳、翔泳社、2007 年 10 月刊) です。副題はオブジェクト指向分析から Spring による実装まで、原書は Use Case Driven Object Modeling with UML で、翔泳社の OOP foundations の一冊として刊行されました。版元は本書を「設計を強くするための教科書」と呼び、「必要最小限のステップでユースケースから保守性が高く動作するコードを得るための手法」を、理論、実践、練習の 3 つのステップで身につける本だと紹介しています。

ICONIX プロセスと全 5 部の構成、要求定義から要求の追跡まで

目次は ICONIX プロセスの解説から始まり、第 1 部から第 5 部へと工程の順に並びます。第 1 部の要求定義にはドメインモデリング、ユースケースモデリング、要求レビューが、第 2 部の分析/概念設計/テクニカルアーキテクチャにはロバストネス分析、予備設計レビュー、テクニカルアーキテクチャが置かれています。第 3 部の設計/コーディングはシーケンス図、詳細設計レビュー、詳細設計からコードへの実装、コードレビューとモデルの更新を扱い、第 4 部のテスト/要求の追跡は設計駆動テストと要求の収集で締めくくります。第 5 部は付録で、UML 2.0 での変更点と Spring Framework の補足が収められています。第 1 部から第 3 部にはそれぞれレビューの項目が置かれており、目次の並びからは、図を描いた後に次の工程へ進む前の点検が手順に組み込まれていることが分かります。

ロバストネス分析がユースケースとクラス設計をつなぐ理由

ユースケースは利用者とシステムのやり取りを文章で書いたもので、何をするかは分かっても、どのオブジェクトがその処理を受け持つかまでは決めてくれません。一方で オブジェクト指向 の設計で使うシーケンス図やクラス図は、メッセージの送り先や属性を一つずつ決める必要があり、文章からいきなり描こうとすると手が止まります。ロバストネス分析は、その間に画面などの境界、処理の流れを受け持つ制御、業務の概念を表すエンティティという 3 種類の要素だけを使った簡素な図を挟み、ユースケースの文章に抜けや曖昧さが無いかを確かめながら、オブジェクト指向の設計へ移る足場を作る手法です。先にドメインモデルで用語をそろえておくことで、ユースケースの文章と図の名前が食い違う事態も減らせます。要件定義 で決めた内容がコードまで追えるかという問いに、図の段階ごとの対応で答えようとするのがこの種の手法の考え方です。本書でも第 4 部の部題に要求の追跡が入っています。

Spring による実装の段と 2007 年刊の時点、読む前の準備

本書の実装の段は副題のとおり Spring を使います。Spring Framework は 依存性注入 を中核に据えた Java のフレームワークなので、Java のクラスとインターフェースを読めること、UML のクラス図とシーケンス図の記法を一通り知っていることが、読み進めるうえでの土台になります。刊行は 2007 年で、付録が UML 2.0 での変更点を扱っていることからも分かるとおり、図の記法やフレームワークの使い方はその時点のものです。Spring の設定方法やツールの操作を手元の環境で再現したい目的には合わないため、そこは別の資料で補う前提で、ユースケースからコードまでの考え方の筋道を学ぶ本として選ぶのが向いています。設計の本をどの順に読むか迷っている場合は、設計の技術書の選び方 で位置づけを確かめてから手に取ると、目的とのずれを避けられます。

要求を書いたのに設計の段で議論が止まってしまう、ユースケースとコードの対応が説明できないといった悩みを抱える設計者やリーダーにとって、要求定義からテストと要求の追跡までを一つの手順として通した本書は、チームで共有できる進め方の型を手に入れられる一冊です。