UML 2 ユースケース図の概要

図1はUMLユースケース図の例です。ユースケース図では、以下のものを記述します。

ユースケース：ユースケースとはアクターにとって重要な価値を持つアクションのシーケンスを記述するもので、横長の楕円で表されます。
アクター：アクターとはシステムとの相互作用においてある役割を果たす人や組織や外部システムで、線で描いた人型で表されます。
関連：アクターとユースケースの間の関連は、ユースケース図上では実線で示します。ユースケースで記述した相互作用にアクターが参加する場合、関連が存在することになります。関連はユースケースとアクターとを互いに結び付ける直線として、必要なら片側に矢印をつけてモデリングします。たいていはこの矢印によって、その関係が最初に呼び出される方向や、ユースケースの最初のアクターを表します。矢印をつけるとデータフローと間違われやすいので、私はあまり使わないようにしています。
システム境界を表す長方形(オプション)：ユースケースをシステム境界の長方形で囲んで、システムの範囲を示すことができます。この長方形に含まれているものはどれも範囲内の機能であり、長方形の外にあるものは範囲外です。システム境界を表す長方形はめったに使われませんが、私はときどき、システムの各主要リリースでどのユースケースを納品するかを明らかにするために使います(Ambler 2003b)。その方法を図2に示します。
パッケージ(オプション)：パッケージは、ユースケースなどのモデル要素をグループにまとめるためのUMLの構成概念です。ファイルフォルダの形で表し、ユースケース図やクラス図など、どのUMLダイアグラムでも使うことができます。私はダイアグラムが大きくて扱いにくくなったときだけ(通常は1ページに印刷できなくなる程度)、パッケージを使って大きな図を小さな複数の図に整理することにしています。図3は、パッケージを使って図1を整理したものです。

図1の例では、学生が講義に登録するときに、学籍係に手伝ってもらう可能性があります。教授は学生の課題の点数を入力し、学籍係は学生に対して成績証明書(通知表)を交付します。ユースケースの中には、複数のアクターが参加するものがあることに注意してください。さらに、いくつかの関連には矢印が付いていることにも注意してください。ユースケースの関連は、矢印を付けないか1つだけ付けるかのどちらかです。「学生」と「ゼミに登録する」の間の関連を見ると、このユースケースが学籍係ではなく学生によって開始されることがわかります(「学籍係」のアクターもこのユースケースに参加しますが)。重要なことですが、関連は情報の流れを表しているのではありません。単に、アクターが何らかの方法でユースケースに参加していることを表しているだけです。アクターとユースケースの間では情報がやり取りされます。たとえば、学生はどのゼミに登録したいかを意思表示しなければなりませんし、システムは学生が登録されたかどうかを示す必要があります。しかし、ユースケース図はそのような情報をモデリングするためのものではありません。情報の流れは、UMLアクティビティ図でモデリングすることができます。「ゼミに登録する」ユースケースと「学籍係」アクターの間の線には矢印が付いていません。これは、システムと学籍係の間の相互作用がどのように始まるかが明確になっていないという意味です。学生が困っているのに学籍係が気づいて手伝うこともあるでしょうし、学生が学籍係に助けを求めることもあるでしょう。この重要な情報は、ユースケース定義書内に文書化されることになります。アクターは、必ず少なくとも1つのユースケースに参加し、常にユースケース図の外周に書かれます。(*)

*:図1では金融機関アクターがやや図の内側に配置されていますが、これも概ね外周部だとご理解ください。

図1 システムユースケース図

図2 リリースを表すシステム境界の長方形

図3 パッケージによるユースケースの整理

ユースケース図の作成

私は通常、最初にできるだけ多くのアクターを洗い出します。そして、そのアクターがシステムとどう相互作用するかを考えて、初期の一連のユースケースを識別します。その後、ダイアグラムで、アクターとそのアクターが参加するユースケースとを線で結びます。アクターが情報を提供したり、ユースケースを開始したり、ユースケースの結果として情報を受け取ったりする場合には、アクターとユースケースの間に関連が必要です。通常私は関連の矢印を付けませんが、それは、私の経験では、最初の呼出しではなく情報の流れを表していると誤解されがちだからです。ユースケース間、あるいはアクター間に類似性が見えはじめたら、それらの間の適切な関係をモデリングします(再利用の方法のセクションを参照してください)。

前の段落で、私はたいてい「最初にアクター」のユースケースモデリング方法を使うと書きました。人によっては、1つのアクターとそのアクターが参加するユースケースをまず明らかにし、そこからモデルを発展させていきます。どちらの方法でもかまいません。重要なのは、人によって方法が異なるため、AMの「他の人と一緒にモデリングしよう」のプラクティスに従っているときには柔軟性が必要だということです。

再利用の方法

図4には、拡張 (extend)、包含 (include)、継承（汎化）というユースケース間の3種類の関係と、アクター間の継承が書かれています。拡張関係は「ハードウェア割り込み」と同じようなものだと考えると分かりやすいでしょう。拡張ユースケースがいつ呼び出されるか、そもそも呼び出されるのかどうかが分からないからです(拡張ユースケースは条件付きだと考えた方がよいかもしれません)。包含関係は手続き呼び出しに相当します。継承は、UMLクラス図と同様に適用することができます。つまり、ユースケースやアクターの特殊化をモデリングするためです。Reuse Use Case Modelsのエッセイではこれらの関係についてさらに詳しく説明しています。

図4 ユースケースの再利用

アジャイルさを保つ

では、ユースケースモデリングをアジャイルに行なうにはどうすればよいでしょうか。まず、できる限りシンプルにしておいてください。モデリング時にはシンプルで柔軟性の高いツールを使います。私は通常、ホワイトボード上でユースケース図を作成します。図5を見てください。これは私がプロジェクトの利害関係者と一緒に作成する初期の図の一例です。AMでは「見栄えより中身」だと説いているので、図が手書きであっても大きな問題ではありません。これで何とか役に立ちますし、私たちに必要なのはそれだけなのです。また、図が完結していなくてもまったく問題はありません。大学システムには当然ここに書かれている以上のものが含まれていますが、必要になればいつでも図を変更することができるのです。

図5 ホワイトボードの下絵

下絵を作成するのと並行して、私はユースケースごとに、非常に簡単な説明も記述します(これも多くはホワイトボードに書きます)。その目的は、ユースケースが何のためのものかを理解できるだけの情報を書きとめることです。さらに詳しい情報が必要であれば、後で好きなときに、本質/ビジネスユースケースあるいはシステムユースケースとして付け加えることができます。

注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。

推奨文献

	効果的なユースケースの書き方を学ぶにはもっとも適した本です。
	利害関係者と一緒に作業をする技法を説明した非常に優れた本です。ユースケースモデリングが含まれています。
その他の成果物の概要	システムユースケースおよび本質ユースケース.
その他のユースケースに関するホワイトペーパー	UML Use Case Diagram Style Guidelines Reuse in Use Case Models

その他の文献

アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。

Let Us Help　(以下、北米での話ですのでご注意ください）

Ronin International, Inc. continues to help numerous organizations to learn about and hopefully adopt agile techniques and philosophies. We offer both consulting and training offerings. In addition we host several sites - Agile Modeling, Agile Database Techniques, UML Modeling Style Guidelines, Enterprise Unified Process (EUP) - that you may find of value.

You might find several of my books to be of interest, including The Object Primer, Agile Modeling, The Elements of UML Style, and Agile Database Techniques.

For more information please contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).

visits since June 8, 2004.