Part3では,オブジェクト指向に基づく基本設計の方法論を,UP(Unified Process)をベースに解説する。下流工程で試行錯誤を繰り返さないためには,「実行可能なアーキテクチャ」を構築することと,アーキテクチャの利用方法を解説した「アーキテクチャ説明書」が極めて重要になる。

 Part2では,主にウォーターフォール型開発プロセスとDOA(データ中心型アプローチ)に基づいた基本設計の手順を示した。だが,最近はWebシステム開発を中心に,反復型開発プロセスやオブジェクト指向設計を採用するケースが増えている。

 そこでPart3では,オブジェクト指向設計に基づく代表的な反復型開発プロセスであるUP(Unified Process)を例にとって,オブジェクト指向設計における基本設計の勘どころを解説しよう。

動くアーキテクチャを作る

 UPでは「方向付け」,「推敲」,「作成」,「移行」という4つのフェーズが定義されており,それぞれのフェーズで「要求」,「分析」,「設計」,「実装」,「テスト」という5つの作業を実施する。推敲フェーズを2回,作成フェーズを2回というように,あるフェーズを何度か繰り返すこともある。このために,UPは「反復型開発プロセス」と呼ばれる。

 UPの最大の特徴は,プロジェクトの早い段階で実際に“動く”アーキテクチャ(開発プラットフォーム)を構築することだ(これをUPでは「アーキテクチャ駆動」と呼ぶ)。また,機能要件については,「ユースケース」をベースに分析・設計・実装していく点も,UPの大きな特徴である(これを「ユースケース中心」と呼ぶ)。

 一般的な開発プロセスでは,システムの全体像を「基本設計」という形で表現し,基本設計に準拠してその後の詳細設計フェーズや実装フェーズに進む。実装が進んだ時点では,よほどのことがない限り基本設計を大きく改変することはない。

 オブジェクト指向の開発プロセス,特にUPでは「基本設計」という言葉は使わない。とは言え,もちろん基本設計に該当する作業がないわけではない。基本設計に該当する作業は,UPでは主に「推敲フェーズ」で,要求・分析・設計・実装・テストから成る一連の作業を通じて実施する。中でも中心的な作業となるのが,「機能設計」に相当する「ユースケース仕様書の作成」と,「方式設計」に相当する「アーキテクチャル・ベースラインの確立」である(図1)。

図1●UPにおける基本設計の位置付け
図1●UPにおける基本設計の位置付け
UP(Unified Process)では,主に推敲フェーズで「基本設計」に相当する作業を実施する

 アーキテクチャル・ベースラインとは,「実行可能なアーキテクチャ」(詳しくは後述)と,実行可能なアーキテクチャの利用方法について記述した「アーキテクチャ説明書」という2つの成果物の初期リリースを合わせたものである。

 推敲フェーズの最大の目的は,主要なリスクに対処しながら「試行錯誤を終えること」だ。このため,リスクへの対策が織り込まれたアーキテクチャル・ベースラインの確立が,推敲フェーズの終了基準(マイルストーン)となる。このマイルストーンの達成が確認されることで,推敲フェーズ,つまり基本設計が完了したことになる(図2)。

図2●UPにおける基本設計の流れ<br>「ユースケース仕様書」と環境/制約条件,および過去の類似プロジェクトを入力情報として「アーキテクチャル・ベースライン」を確立する。アーキテクチャル・ベールラインは,実行可能なアーキテクチャと「アーキテクチャ説明書」から成る
図2●UPにおける基本設計の流れ
「ユースケース仕様書」と環境/制約条件,および過去の類似プロジェクトを入力情報として「アーキテクチャル・ベースライン」を確立する。アーキテクチャル・ベールラインは,実行可能なアーキテクチャと「アーキテクチャ説明書」から成る
[画像のクリックで拡大表示]

 そして,推敲フェーズの成果物である実行可能なアーキテクチャに準拠して,次の作成フェーズでユースケースが分析・設計・実装されることとなる。これが一般的な詳細設計フェーズ,実装フェーズに当たる。ソフトウエア開発において「試行錯誤を終える」ことがどれほど難しいか,システム開発に携わっている読者はよくお分かりだろう。UPでは,その答えはアーキテクチャル・ベースラインにある。