根本から理解するオブジェクト指向分析/設計

ユースケース記述を書かずにモデリングは終わらない

　では，図6の実施手順に沿って説明していきましょう。まず「1.アクターの導出」とは，システムと直接関係する人もしくは外部のシステムである“アクター”を定義することです。アクターは，人やシステムそのものではなく「役割」を表しています。例えば，“山田さん”という具体的な人ではなく，“システム管理者”や“営業担当者”のように，“山田さん”がシステムを使う際の役割を定義したものがアクターです。一人の人間が複数の役割をカバーしているなら，アクターとしては“システム管理者”と“営業担当者”の二つを定義することになります。

　アクターの導出は，後の作業であるユースケースの導出を目的としています。したがって，アクターの定義自体にあまりこだわる必要はありません。システムに関係するアクターを洗い出し，そのアクターが必要とするユースケースを漏れなく洗い出すことが重要です。今回のサンプルでは「貸出担当者」「図書館利用者」の二つのアクターを導出してみました（カコミ記事「アクターには2種類ある」を参照）。

　次に「2.ユースケースの導出」です。ユースケースとは，ユーザー(人間の場合もあれば，他のシステムの場合もあります）から見たシステムの外部機能を記述したものです。つまりユースケースの導出は，アクターに対してシステムがどのような機能を提供すべきなのかという観点で導出していくわけです。サンプルでは，図書館利用者向けに「書籍の検索を行う機能」，貸出担当者向けに「貸し出し，返却，督促の各業務を支援する機能」を洗い出しました。UMLのユースケース図を描くと図7のようになります＊4。

図7●図書貸し出し管理システムのユースケース図

　続いて行うのは「3.ユースケースの優先順位付け」です。ユースケースの優先順位付けは，原則としてビジネス上の重要度に基づいて行います。つまり，高い優先順位のユースケースから先に実装していきます。ウォータフォール型＊5の開発を行う場合は，ユースケースの優先順位はあまり意味を持ちませんが，イテレーション型開発を行う場合は，重要な意味を持ってきます＊6ので，よく考えて優先順位付けを行ってください。今回のサンプルでは「書籍を検索する」を最も優先順位を高くし，以下順番に「貸出を行う」「返却を受け付ける」「督促を行う」としました。

　最後は「4.ユースケース記述の作成」です。ここまでの作業で，アクターとユースケースを洗い出し，ユースケース図を作成しました。しかしユースケース図だけでは，システムがどのような機能を提供するべきなのか具体的にはわかりません。例えば「書籍を検索する」というユースケースが実際にどのような機能なのか，ユーザーにヒアリングしてみないとわかりません。ヒアリングしてその結果をドキュメントに残す必要があるのです。この，個々のユースケースが実際にどのような振る舞うべきなのかを定義したものが「ユースケース記述」です。アクターとシステムの間でどのようなやり取りがされるのかを対話形式で記述したものです。UMLが登場した当初のユースケース記述の書き方は，ユーザー・マニュアルに近いものでした。

　ここでぜひ覚えてほしいのが，ユースケース記述こそがユースケース・モデリングの成果物の本質であって，ユースケース図はユースケース全体を概観するために使う図でしかない，ということです。UMLが登場したばかりのころ，ユースケースはユースケース図のみで表すものだと誤解されていた時期がありました。しかし，一度でも実際にやってみればわかりますが（やってみなくてもわかるという話もありますが…），ユースケース図だけでシステムの機能を定義することは不可能です。

　とはいえ，画面に関する詳細な操作をユースケース記述に書いてしまうと，変更に対して影響を受けやすくなります。画面の変更に伴いユースケースも修正していたのでは，修正コストが膨大になってしまうでしょう。このような経験から，現在ではユースケースには画面の詳細な操作を書かず，どのような機能を提供するべきなのかという点に絞って書くことが多くなっています。画面の仕様は別途，画面仕様書や画面遷移図などを駆使して定義すればよいのです。

良いユースケース記述を書く五つのコツ

　それでは，ユースケース記述にはどのような事柄を書くのかを具体的に見ていきましょう。図8が今回のサンプルにおける「書籍を検索する」ユースケース記述の例です。

図8●ユースケース記述のサンプル

(1) 基本フローに記述するのは，正常ケースの中の一つの流れのみ
　基本フローには，正常終了する一つの流れのみを記述します。その流れ通りにはならない場合は，すべて代替フローに記述します。

(2) 代替フローには，実行される条件を明示する
　代替フローの一行目「2a 条件に一致する書籍が一つもない場合」という記述を見てください。最初の数字「2」は，基本フローの2行目で起こり得るフローということを，「a」は識別子を意味します＊7。“条件に一致する書籍が一つもない場合”という部分は，代替フローが実行される条件です。

(3)概念モデルに対して何をするのかという観点で記述する
　基本フローのシステムが実施する内容を見てください。2行目と4行目がそれです。それぞれに“書籍”という記述があります。これは，概念モデル上で出てきた“書籍”と同一のものです。概念モデルはシステムの静的な構造を，ユースケースはシステムの動的な構造を表しますから，ユースケース上に書くシステムが実施すべき内容というのは，概念モデル上の概念を操作することに相当するわけです＊8。

(4) ユーザー・インタフェースの操作は記述しない
　ユースケース記述の中には，前述のようにユーザー・インタフェースに関する記述は一切入れません。ユーザー・インタフェースの設計は，別途，画面仕様書なり画面遷移図なりを作成しそちらで行います。

(5) 各フローの中にすべてを記述しようとしない
　フローの中にすべてを記述しようとしても無理があるので，備考をうまく利用してなるべくわかりやすく書きます。図8では，検索条件の詳細を備考に記述したり，ログのフォーマットは別ドキュメントを参照するように記述しています。すべてをユースケース記述の中に記述する必要はないのです。

概念モデルとユースケースをクロスチェックする

　さて，ここまでで概念モデリングとユースケース・モデリングの内容を見てきました。これでシステムの静的/動的な側面モデルが完成したことになるので，全体像がかなり具体的に見えてきているはずです＊9。では分析工程のしめくくりとして，概念モデルとユースケース・モデルのクロスチェックを行いましょう。それぞれのモデルを，もう一度よく見てください。

　まず，ユースケース・モデリングでは「書籍を検索する」というユースケースのみユースケース記述を定義しました。この中で“書籍”という概念モデルが出てきましたが，もし概念モデル上の概念のうち，ユースケース記述の中に登場しない概念があった場合はどうなるのでしょうか？

　そのような場合，(1)ユースケースに漏れがある，(2)ユースケース記述に登場しなかった概念は，開発スコープ外の概念である，という点を疑ってください。(2)なら問題ありませんが，もし(1)だとユースケースを追加する必要があります。また逆に，ユースケース記述上に登場したデータが概念モデル上に存在しない場合は，概念モデルに概念を追加してください。

　このように，ユースケース・モデルと概念モデルとの間でクロスチェックを行うことで，両方のモデルをより洗練したものにしていくことができます。このほかにもやっておくべき作業はあるので，ぜひ実施してみてください（カコミ記事「分析工程で，ほかに行うべき作業」を参照）。

アクターには2種類ある 　アクターには2種類の異なる性質を持ったものが存在します。「主アクター」と「支援アクター」です。主アクターは，ユースケースの実行の引き金となるアクターです。ユースケースの主な目的は，主アクターの利益を実現することになります。一方，支援アクターは，ユースケースの実行に対して情報を提供したり，ユースケースから何らかの情報を受け取る役割のアクターです。 　例えば，インターネット上で書籍販売をするシステムの場合，顧客が商品の注文を完了した際に，配送担当者に注文内容をメールを送信するとします。このようなユースケースの場合，顧客が主アクター，配送担当者が支援アクターとなります。

分析工程で，ほかに行うべき作業 　分析で行うべき作業は，概念モデリングとユースケース・モデリングだけではありません。本記事では扱いませんが，非機能要件の定義とユーザー・インタフェース仕様の定義が挙げられるでしょう。 　前者は，システムとして許容されるダウンタイム，要求される応答時間などで，後者は，画面/帳票仕様（表示すべき項目やレイアウト）と画面遷移図が主なところになります。画面遷移図は，最近だとUMLのステートチャート図を使って書く場合が多くなってきました。 　これらの作業は，オブジェクト指向という観点ではあまり語られませんが，オブジェクト指向技術を採用しようとしまいとやらなければならない作業であることには変わりありません。