HOME / PREVIOUS

Use Case図

Use Case図とは
システムの使われ方（システムへの要求・機能）を記述するための図。
Keywords
Actor(アクター)
Use Case (ユースケース)
Subject(対象)

ユースケース図を学ぶ前に「ユースケース」を学ぶべき

いきなりで恐縮だが、筆者は「UMLのユースケース図」を勉強するぐらいなら、「ユースケースの書き方 を学んだほうがよいと思っている。「ユースケース図」と「ユースケース」は何か違うのか、という問いにはこのあと答えたい。そのあと、UMLのユースケース図の書き方を示す。

このようなことを書くのは、UMLに初めて出会った人がよく言う言葉に、「クラス図とシーケンス図が意味があるのはわかったし、使いやすいとも思った。だが、ユースケース図は何のために使うのかわからない。あれは単なるお絵かきではないのか？」というのがあるからである。

したがって、ほかのページとは構成が異なるため、戸惑われる方がいらっしゃるのを覚悟しながら、こんな前置きを書くことにした。既に「ユースケース」とは何なのかをご存知で、UML2.0のユースケース図自体に関心がある方は、次の2つの項目は飛ばしていただきたい。

なお、UML1.5のユースケース図とUML2.0のユースケース図には目立った違いはない。あるとすれば、パッケージがユースケースを所有する場合に、シーケンス図で用いるフレームをパッケージ表記として使うことになったという程度である。

ユースケース図とユースケースの違い

ユースケースは、システムに要求された機能を定義する。定義の中には、対象となっているものの振る舞いを書くが、内部構造については記述しない。つまり、内部で何がどうなってその機能を実現するかについては書かない。

ユースケースの対象となるものについては、物理的なシステムであってもよいし、振る舞いを持つその他のものでもよい。たとえば、サブシステムやコンポーネント、クラスであってもよい。ただし、その中身については書かない。外から見て、どういう振る舞いをするかを書くだけである。たとえば、クラスについてユースケースを書くとしたら、そのクラスがどういった機能を実現するかを書くだけであり、中にどのようなOperationやPropertyがあるかについては書かない。

UMLのユースケース図は、このようなユースケースについて、ひとつの書き方を提供するが、ユースケースを必ずしもUMLのユースケース図で書く必要はない。ユースケースは、テキストで記述してもよいし、場合によってはState Machine図、Interaction図(Sequence図など）、Activity図、Composite Structure図(Collaboration)などの表記法を借りてきて表記することもできる。

次の項目で挙げる書籍は、テキストで記述するユースケースについて書いている。

「ユースケース」の学び方

ここでは、ユースケースの学び方について詳細は述べない。というのは、ユースケースの書き方についての名著があるからである。なお、下の2冊は言語が違うだけである。こちらを学ばれた上で、ユースケース図について学んだほうがよい。そのほうが「ユースケースとは何なのか」ということについて正しい理解が得られると思う。

ユースケース図の例

上に示したのは、もっともオーソドックスなユースケース図である。図書館の業務について表している。

楕円の中に描かれたものが、それぞれユースケースである。ユースケースについてユースケース図で書ける内容は、この程度である。上に挙げた書籍で書かれたテキストによるユースケースに比べ、このユースケースの書き方では不十分な印象をもたれることと思う。

四角の枠は、外部との境界を表している。この図の場合、「図書館」システムの外側と内側を区別するために用いている。

アクター

この図形をアクターと呼ぶ。この図形自体は一般にスティックマンと呼ばれる。

アクターは、ユースケースを書く対象の外側にいて、その対象とかかわりを持っている役割(role)を表現している。上の図書館の例では、利用者や図書館職員がこのアクターに当たり、それぞれ図書館システムの提供する機能である「本を借りる」などのユースケースと関わりを持っている。

アクターは、必ずしもスティックマンでなくてもよい。外部から関わるものが、別のシステムである場合もある（たとえば、「クラス」を対象としてユースケース図を書くときには、他のクラスが対象クラスに関わることは明白だろう）。そういった場合、このようなアイコンを用いて表現してもよい。別のシステムが関わる場合などには、こういったコンピュータの絵を用いることが多い。

パッケージ

あるユースケース群がパッケージに含まれたものである場合は、上の図のようにフレームで囲って表示する。（パッケージ図で用いるパッケージ表記とは異なる。）この図では、図書館パッケージに図書館に関するユースケース群(「本を借りる」「本を返却する」「本を登録する」)が含まれていることになる。

クラス図の表記を用いた表記

UML2.0のSpecification(Superstructure)を読むと、「ユースケース図はクラス図の特化したものである」とはっきり書かれている。違いは、各クラシファイアをアクター（￥(スティックマン等)やユースケース(楕円)で表していることである。このページの最初のほうに、Use Case図はState Machine図やInteraction図の表記を使って書いてもよいことを書いたが、元々UMLで示されているUse Case図の表記法自体も、クラス図の表記を借りてきているだけなのである。

次に示すのは、ユースケース図で用いる矢印・線のリストである。クラス図の表記に大変近いことがわかるはずである。

汎化
A)

ユースケース図では、ユースケース間およびアクター間に汎化関係を持たせることができる。A)はユースケース間、B)はアクター間である。C)はあとで説明するが、誤った汎化関係である。

ユースケース間の汎化を示したA)では、「本を貸し出す」には「自動貸し出し」と「手動貸し出し」の2つの特化した形があることを示す。「自動貸し出し」（図書館利用者がＩＤカードを専用機器に通して自分で貸し出し手続きを済ませる形態）と「手動貸し出し」（利用者が職員のところへ本を持っていき、貸し出して続きをしてもらう形態）は、ともにユースケース「本を貸し出す」に定義された一連の流れを持ちながら、それぞれ独自の振る舞いを持っている。このような場合に汎化を用いる。

つまり、「ユースケースＡがあり、ユースケースＢはＡと同じ一連の流れを持ちながら、Ｂ独自の機能も持っている」という場合、「ＡはＢを汎化する」という。（逆に言えば 「ＢはＡを特化する」。）

次に、アクター間の汎化を示したB)では、図書館職員は常勤職員と非常勤職員にそれぞれ特化される。

ところで、最初に示した図書館のユースケースの例で、「図書館職員も図書館で本を借りるのだから、図書館職員は利用者を汎化して作るべきではないか」と考えると、C)のような汎化関係を作ってしまいがちであるが、これは汎化の使い方としては誤りである。 なぜなら、利用者と図書館職員では役割が全く異なるからである。アクターの汎化を考えるときには、「役割(role)」を意識すればよいだろう。

B)
C)

拡張

上に示したのは「拡張」という概念である。拡張されるユースケースを実行するとき、拡張するユースケースの内容を常には含まないが、ある条件のときに拡張するユースケースの内容を含む場合にこの概念を使う。

たとえば、左の例では、「返却された本が予約されている」という条件下で、ユースケース「本の返却を予約者に知らせる」によってユースケース「本を返却する」は拡張される。「本を返却する」というユースケースが、「拡張されるユースケース」にあたる。

拡張されるユースケースには、拡張点(extension point)を書く。つまり、そのユースケースのどの振る舞いの時点で拡張が起こるのかを書く。

拡張条件(condition)は、UMLのComment表記を用いて書く。コメント表記と矢印の接点には、白抜きの丸を描く。

拡張関係自体は、この図のようにクラス図の依存表記を用いて描く。ギルメット(<<>>)に「extends」という文字を挟んで、拡張であることを示す。


包含

包含は拡張とは違い、あるユースケースが常に別のユースケースを用いる場合に使う。

上の例では、ユースケース「本を借りる」では常にユースケース「ＩＤカードで利用者を確認する」を用いる。拡張同様、ギルメットで「includes」という文字を挟んで表記する。

他の表記法

先に書いたように、ユースケースは様々な記法を用いて表せばよい。最も単純なのはテキストで書くことであるが、システムの機能を表すのにStateMachine図を用いたほうが適切な場合もあろうし、Activity図を用いたほうがわかりやすく表現できる場合もあろう。これは筆者の見解であるが、UMLのユースケース図にこだわらなければならない理由がない限り、わかりやすさと正確さを発揮できる表記を優先するべきであると考える。

HOME / PREVIOUS