ユースケースの操作手順

「ユースケース」と言っても、それはユースケース図の中の楕円だけを表すのではありません。システムを実現するまでの過程では、それぞれのユースケースの詳細な操作方法を分析する必要があります。各ユースケースの詳細な操作方法は、「ユースケース記述」の中でイベントフローとして表されることが一般的です。

ユースケース記述には、ユースケース名、概要、主アクター、支援アクター、事前条件、事後条件（保障）、トリガー、基本フロー、代替フロー、例外フローなどの項目について日本語で記述します。これらのユースケース記述のテンプレート（様式）は、UML の範囲ではありませんので、プロジェクトによって異なります。

上記の項目は、一般的なユースケース記述のテンプレートに従っています。この他にも、「ユースケースID」や「版数」など追加的な項目を採用する場合があります。ユースケース記述では、あくまでもシステムの操作をブラックボックス的にとらえ、システムの内部的な内容は後の工程で検討するようにします。

ユースケースの詳細を表現する方法は、ユースケース記述だけではありません。前回、業務フローを表現するために使用したアクティビティ図でも記述することができます。また、ヤコブソンのOOSEで最初に提唱されたロバストネス分析は、現在も使われることが多い手法と言えます。

図3は、ロバストネス図の例です。ロバストネス図で使用されるアイコンは3種類あり、UMLの標準には組み込まれていません。UMLツールなどで記述する場合には、UMLプロファイルと呼ばれる、UMLの標準が用意している拡張機能を利用します。

バウンダリ「≪boundary≫」は、システムとアクターの境界で作用するクラスで、具体的には画面や外部システムアクセスを担当します。

コントロール「≪control≫」は、システムが行う主要な振る舞いを表すものです。

エンティティ「≪entity≫」は、システムで扱う情報を表しています。データベースなどに永続化されることが多いものです。

ロバストネス分析は、例のようにクラス図で記述する方法の他にも、コミュニケーション図やシーケンス図などで記述する方法もあります。いずれの場合でも、ロバストネス図はあくまでも、「何を」実現するのかを表す要求分析（ユースケース）から「どのように」実現するのかを表すオブジェクト設計の中間的な成果物であることが一般的です。

ユースケースの粒度

ユースケース図の表記だけを見ると、人のような形をしたアイコンと横長の丸が、線でつながっているだけの図で、シンプルで簡単すぎるとさえ思えます。しかし、何事もシンプルであることは、実はとても難しかったりします。

今回の連載のテーマであるモデリングそのものも、「システムを開発する」などの目的のために、物事をシンプルにするという行為に他なりません。

ユースケースをモデリングするときに、議論されることが多いのは「どんな単位を1つのユースケースとするか」という問題です。これは「ユースケースの粒度」という言葉で表されます。

あまりにも細かな単位のユースケースがたくさんできてしまったり、不要なユースケースであふれてしまったりする状況を「ユースケース爆発」と呼ぶことがあります。芸術は爆発ですが、ユースケースは爆発してはいけません。

これを回避するためには、「何がどうであれ、とにかくプロジェクトで扱いやすい単位にしましょう」ということです。いくら正しい基準を事細かに定めても、達成すべき目的にとって扱いにくいモデルは、UMLを採用する理由としては本末転倒になってしまいます。例えばユースケース記述を整理しやすいユースケースの単位などを考慮する必要があります。

次に言えるのはやはり「ユーザが必要とする単位にしましょう」ということです。これを実現するのに一番良い方法は、今回のように業務フローから必要なユースケースを抽出することです。ユーザが業務の流れの中で利用する単位に洗練できますし、思い付きだけで不要なユースケースを開発してしまうこともありません。

また、ユースケースの粒度は、何をサブジェクトとするかによっても異なります。システムを辞書で引くとわかりますが、何もコンピュータで作られたものだけをシステムと呼ぶのではありません。

会社も1つのシステムですし、地球や太陽系も1つのシステムということができます。話のスケールが少し膨らみすぎましたが、ユースケース図はコンピューターシステム以外のシステムもサブジェクトとして書くことがあります。これは、例えば消費者をアクターとして小売店をサブジェクトとするようなビジネスユースケースや、組み込みシステムの一部である部品をサブジェクトとするユースケースも、同じような要領で要求分析することが可能であるということです。 タイトルへ戻る