ヤコブソン氏は,「オブジェクト指向」というソフトウエアの表現手段とその可能性に着目し,大規模並行開発に対応できる「システマチックな基本行動」を定義した。それが「ユースケース駆動開発(UCDD)」というアプローチである。今回は,UCDDの開発手順を解説しよう。

 「ソフトウエア・エンジニアリング」――。今から20年以上前,1980年代にイヴァー・ヤコブソン氏がソフトウエア開発に求めた姿である。日本語では「ソフトウエアの工業化」とされることが多く,少なからず否定的な感覚を持たれることもある。

 しかし,彼は「ソフトウエアをベルトコンベアの上で大量生産できる環境」を作り出すことを目指していたわけではない。当時は一般的だった“職人的な開発方法”では,ソフトウエアの規模と複雑性の増大に対応できないことを認識していたのである。

 そこでヤコブソン氏は,「オブジェクト指向」というソフトウエアの表現手段とその可能性に着目し,大規模並行開発に対応できる「システマチックな基本行動」を定義した。それが「ユースケース駆動開発(UCDD)」というアプローチである。

UCDDは,“ユーザーの要求からオブジェクトを定義する”ための定型的な手順を規定し,業務からシステムまでのトレーサビリティを維持すること,そして定義されたオブジェクトの再利用を促進することを目指し,「OOSE(Object-Oriented Software Engineering)」という開発方法論に組み込まれた形で公開された(表1)。

表1●ユースケース駆動開発(UCDD)の目標とその実現手段
表1●ユースケース駆動開発(UCDD)の目標とその実現手段
[画像のクリックで拡大表示]

 「当たり前のことは考える必要はない。考えるべきことに集中せよ」。当たり前の行動基準を準備することの裏側には,このようなメッセージが込められている。ソフトウエア業界では常に声高に叫ばれている「ユーザー志向」や「サービス志向」という言葉も,いざ開発の現場でコードに向かうと,多くの人が忘れ去ってしまう。「ユースケース」を開発の中心に置いて開発行動の中で意識せざるを得ない環境を作ることもまた,開発者の人間としての行動特性を踏まえた,現実的な解決策である。

 表2に,UCDDの開発手順を示した。順を追って解説していこう。

表2●ユースケース駆動開発の主な作業手順
表2●ユースケース駆動開発の主な作業手順
[画像のクリックで拡大表示]

ワークフロー:要求の把握

(1)アクターとユースケースの識別

 UCDDの最初の作業として「アクター」の識別を行う。開発対象となるシステムの外部の存在かつシステムと直接相互作用する存在を「アクター」として識別し,アクター名を付与する。アクターは,システムを「操作する人」として識別される場合や,「情報を連携する他システム」として識別される場合がある。

 アクターの識別に続いて,アクターがシステムに対して依頼すべき事項を「ユースケース」として識別する。例えば,銀行の顧客がアクターとして識別されたとすると,システムに対して「入金」「出金」「残高照会」「口座振替」「暗証番号の変更」などをシステムへの依頼事項として見つけることができるだろう。これらがユースケースとなる。各ユースケースには,依頼事項を「ユースケース名」として付与しておく。

 アクター,ユースケースともに,定義する際の「粒度」に注意を払う必要がある。あくまでも「ユーザーの視点」に立ち,「意味のある大きさ」で識別することを心がけよう。開発者の視点では,どうしても細かなディティールに気を取られやすい。

 識別したそれぞれのユースケースに対しては,システムとして実行する際の大まかな流れを,3~10ステップの手順で簡単に記述しておく。この手順の記述は「ユースケースイベントフロー(初期記述)」として保存しておく。

 次に,ここまで個別に識別を進めてきたアクターとユースケースをUMLの「ユースケース図」として表現する。ユースケース図は,部門別,アクター別に作ったり,一連の業務フローを1枚の図にまとめる場合がある。

 ユースケース図は「開発の入力」であると同時に,ユーザーが将来のシステムを知るためにも存在する。あくまでも「顧客にとって分かりやすい」という観点で,手間をいとわずに,様々な観点でユースケース図を作成してユーザーに提示することが重要だ。

(2)ユースケースの詳細化

 ユースケースイベントフロー(初期記述)を拡張する形で,イベントフローの詳細な記述を進める。同時に,代替フローや事前条件・事後条件などの付加情報を定義する。イベントフローは「アクターとシステムの相互コミュニケーション」の形式で詳細化を進めるが,「技術的な実装手段は記述しない」ことに注意する必要がある。また条件分岐が多い場合など,文章としての記述や理解が難しい場合,UMLの「アクティビティ図」を使った表現を補助的に使用することも有効だ。

 次に,あらかじめ用意されたテンプレート(ひな形)に従って,個々のユースケースが持つべき能力を“可視化”した「ユースケース仕様書」を作成する。テンプレートに従うことで完全性を担保するとともに,「分かりやすさ」の観点でUMLの「ステートチャート図」などの補助ダイアグラムも利用する。

(3)ユースケース図の作成

 ユースケースとアクターは,ここまで個々に定義されてきた。それらをイベントフローも含めて並べたときに,本質的に共通であったり,あるフローの拡張としてとらえられる別のフローを見出したり,一部が全く同じフローを発見することがある。それらを,ユースケース図の汎化,拡張,包含の関係を利用して構造化する。

 注意すべきことは,ユースケース図が常に顧客から「理解しやすい」状態を維持することである。構造化を進めると,理解は難しくなる。あくまで理解を促進するための構造化を第一に考え,作業効率は2番目に考えなければ,本末転倒となる。