ユースケース図

Published by javaSilver on 08/21/2017 | Permalink

ユースケース、分かりそうで分かりにくい言葉です。useもcaseも聞いた事があるため、勝手な解釈で分かった気になりがちですが、そうすると間違った先入観で勉強することになるのでプログラミング上の意味をなかなかとらえることが出来ません。
プログラミングではこういう用語によく出会います。そういう時は英語の意味を確認し、用語の正しいイメージを持って勉強すると効果的です。

ユースケースは一般的には「使用事例」、製品説明などで使われる場合は「適用領域」などの意味です。つまり、ユースケース図は作ろうとしているシステムがどのように利用できるのか、システムが提供するサービスや機能はどのような領域に適用できるるのかを検討し、明示するために利用します。
ユースケース図はシステム開発の工程の中では要件定義の段階で、システムが満たすべき要件を表現し、関係者間の合意形成に使われます。

ユースケース
ユースケース図を描く前に、ユースケース自体は何かをもう少し考えてみましょう。
例えば、一般的なイベントのチケット販売システムを考えてみましょう。
まず、チケット販売システムはチケットを購入しようとしている顧客、公演主催者が利用するでしょう。そして劇場側も劇場の運営などのために、何らかのシステム(劇場運営システム)を通してチケット販売システムからの情報を入手するでしょう。
そして、チケット販売システムは、

–

チケットの予約をする

–

チケットの予約を変更する

–

チケットの予約を取り消す

–

チケットの予約状況を確認する

–

チケットの予約状況を取得する

などの機能、振舞いを持つことが期待されるでしょう。

これら、対象システムは何か、システムを使う人又は物は何か、システムが提供する機能は何かを文章で書こうとすると百人百様になってしまい、関係者が内容を理解するにも時間がかかります。
そこで、これらの事を図式化の決まりに従って簡潔にまとめたのがユースケース図です。ユースケース図を使えば、一目で「システムの利用者(アクター)」が何で、「システムで出来る事(枠の内側)」、「システムで出来ない事(枠の外)」がはっきり分かり、合意形成の議論もしやすいでしょう。

ユースケース図の構成要素

対象

ユースケース図で表現したいシステムを四角形で表し、対象の名前を上部に記述します。

アクター

システムの外でシステムと相互作用するユーザーや外部システムを丸と棒で描いた人型で表します。

ユースケース

システムが外部に対して提供するひとまとまりの機能を簡潔な一文で書き、楕円で囲みます。

関係

アクターと相互作用するユースケース、及び関係のあるユースケース相互を実線で結びます。

以上の構成要素をまとめると、ユースケース図は完成します。

ユースケース図作成上の注意

–

ユースケースはアクターから見た機能が重要なので、外からは見えない内部的な機能、実装技術、性能は記述しません。

–

ユースケースの表現は簡潔な一文が望ましいので、(顧客が）「チケットを予約する」のように、明確な目的語と動詞で表現します。

–

ユースケースの抽出粒度が個々に異なると全体が簡潔にまとまらなくなるので、アクターがある一つの目的を達成するために中断せずに行う機能を単位とすると良いでしょう。必要があれば、目的の粒度に応じてユースケース図を全体と詳細に分けるのも必要です。

–

ユースケース図で表現できるのは、どのような機能が、どのようなアクターと関連するかであって、期待する操作手順や前提条件などは表現できませんし、表現すべきではありません。それらが必要な場合はユースケース図ではなく補助資料としてユースケース記述書(UMLでの書式規定はありません。)などを用意して記述します。

ユースケースの相互関係
同じ粒度で列記したユースケース同士に共通する部分があったり、一部を独立させた方が全体のユースケースが簡潔になる場合、ユースケース間には次の関係があるといい、それらを以下のように記述します。

extend(拡張)
あるユースケースの機能を別のユースケースが拡張する関係。
機能を拡張するユースケースから基になるユースケースに向かって点線の矢印を引き、ステレオタイプ<< extend >>と線上に記述。実線で結びます。

include(包含)
あるユースケースが別のユースケースを内部に含む関係。
包含するユースケースから包含されるユースケースに向かって点線の矢印を引き、ステレオタイプ<< include >>と線上に記述。

設計に戻る