ユースケース図 2-4 ～

FM11012中島拓也

ユースケース記述とは。• ユースケースだけでは詳細な記述ができな

い。

• その為、情報が不足してしまう。

• １つ１つのユースケースに対して、詳細なユースケースのドキュメントを追加する事。

• ユースケース記述は、以下の３つを指します。

• 概要• シナリオ• イベントフロー

概要• ユースケースの役割、目的などを数行で記述す

る。

• 例えば、 Web ショッピングシステムにおいて、　　　　　　　「商品を購入するためには、会員になる必要があります。このユースケースは会員の登録を行います。」

と記述します。

シナリオ• ユースケースの具体的な流れの１つを記述する。• ここでの名前、数字などは具体的に記述する。

• つまり、システムを実際に使用した場合のやり取りをそのまま記述したようなものになる。

• シナリオは１つのユースケースに複数存在することになるが、以下の２つに大別できる。– 基本シナリオ・・・目的が達成できたシナリオ– 例外シナリオ・・・目的が達成できなかったシナリオ

• Web ショッピングシステムの会員登録するユースケースの例では、

• 基本シナリオ– 実際に会員登録できた場合。

• 例外シナリオ– クレジット番号が照合できないなど、会員と

して登録できなかった場合。

イベントフロー

• ユースケースの流れをすべてを網羅するように記述する。

• 具体的な名前や数字は用いず、汎用的に表現する。

• 以下がイベントフローで記述する項目。• 事前条件

– ユースケースを開始できる状態についてのシステムに対する制約。

• 事後条件– ユースケースが終了した後のシステムに対する制約。

• 基本フロー– 基本的な流れ。

• 代替フロー– 頻度が少ない正常な流れ。

• 例外フロー– 正常終了しない流れ。

ユースケース図で使用する関係• 関連– アクターとユースケースの関係に使用。

• 包含– ユースケース同士の関係に使用。

• 拡張– ユースケース同士の関係に使用。

• 汎化– ユースケース同士の関係に使用。– アクター同士の関係に使用。

関連• 実線で表現する。• 多重度 ( 他のクラスのオブジェクトが接続される可能

性のある要素の数 ) をつけることも可能。• 「注文受付係」アクターから「注文を受け

付ける」ユースケースへの関連を表現。

アクター

１ ＊注文を受け付ける

多重度

関連

包含• イベントフローで共通だった部分を図示でき、複数のイ

ベントフローの関係を視覚的に理解することが可能となる。

• 例えば、ユースケース A とユースケース B の一部に同様の流れがある場合、その部分をくくりだして新たなユースケース C を作成する。

• ステレオタイプをつけた依存関係を、包含するユースケースから包含されるユースケースに対して引いて表現する。 A

B

C包含するユーケース

<<include>>

<<include>> 包含されるユースケース

------------------>

--------------

---->

• Web ショッピングシステムの例で考えると、「買い物かごに入れる」「買い物かごから戻す」「商品一覧を表示する」「購入する」というユースケースはすべて、ログインしてから行う。

• そこで、これらのユースケースから、新たに「ログインする」というユースケースを作成し、包含の関係を引くことが出来る。

かごから戻す

かごに入れる

一覧を表示

購入する

ログインする

------------------->-----------------------------

----->

------------

----->

<<include>>

<<include>><<include>>

<<include>>

拡張• あるユースケース A の、一部分を利用したり利

用しなかったりする場合に、その部分を新たなユースケース B として作成する。

• そして、 <<extend>> を付けた依存関係を、ユースケース B からユースケース A に対して、拡張の関係を引く。

• ユースケース B がもともと独立したユースケースで、それをユースケース A がオプショナルに利用する場合も同様に拡張の関係を引く。

• 拡張されるユースケースの流れの中で拡張を提供するユースケースへ分岐するところが拡張点である。

• 拡張点はユースケース名の下に線を引いて区間を設け、そこに記述する。

A拡張点

<--- --------<<extend>>

B

拡張を提供されるユースケース

拡張を提供するユースケース

• 例えば、 Web ショッピングシステムで「購入する」というユースケースの場合、配送先の確認画面が出る。配送をデフォルトの設定以外にする時、配送先を指定しなおさなければならない。

• 「配送先を指定する」というユースケースを新たに作成して、もとの「購入する」ユースケースと拡張の関係で接続する。

購入する配送先の確認

<----------------------<<extend>> 配送先を指定

アクターの汎化• アクター A がいくつかのユースケースと関

連があり、別のアクター B がアクター A とすべて同じユースケースと関連が合う場合、アクター A とアクター B は汎化の関係で接続できる。

A

B

case1

case2

case3

case4

A

case1

case2

case3

case4B

汎化関係

抽象アクター• アクター同士に汎化関係を導入したとき、上位

のアクターが抽象アクターになる場合がある。• 下位アクターをまとめる意味で作成するもの。• 抽象アクターは斜体で表記する。• 例えば、 Web ショッピングシステムでは、「特

別会員」と「一般会員」の」２種類の会員がいる。

会員

特別会員 一般会員

抽象アクター

ユースケースの汎化• ユースケース A の流れをユースケース B がすべ

て利用し、かつユースケース B はそれに加えて他の流れを持っている場合、ユースケース A とユースケース B の間に汎化関係を引きます。

A

B

汎化関係

A B

△△△△△△△△△△△△

△△△△△△△△△△△△△△△△△△△△△△△△△△△△△△

△△△△△△△△△△△△○○○○○○ ○○○○○○

△△△△△△△△△△△△△△△△△△・・・

異なる部分

抽象ユースケース• Web ショッピングシステムにおいて、「商品を検索する」というユースケースを作成したが、実際には「商品名で検索する」または、「商品カテゴリで検索する」のどちらかを使用する。

• 「商品を検索する」を直接アクターが起動するわけではない、このような時に抽象ユースケースと呼ぶ。 商品を検索する

商品名で検索する

商品カテゴリで検索す

る

抽象ユースケース ( 斜体 )

問題１• 「田中さんは、総務部に所属しています。従業員情報の変更や新入社員の情報を登録する係です。田中さんの同僚である伊藤さんも同様の作業を行っています。」

田中さん

メンテナンス係

伊藤さん

田中さん

従業員情報をメンテナンスす

る

従業員情報をメンテナンスす

る

従業員情報を変更する

従業員情報を登録する

①

②

③

問題２• アクターの候補にならないものを選択しなさい。

① システムを利用するユーザ② 既存システム③ 開発対象の機能④ システムと直接通信をするハードウェ

ア

問題３• 正しいアクターの表記を選択しなさい。

アクター

アクター アクター

アクター

① ②

③ ④

問題４• 以下の図にあるすべてのユースケースを含むも

のを選択しなさい。従業員情報システム

従業員情報を参照する

メンテナンスする

①　「従業員」と「管理者」②　「従業員情報を参照する」と「メンテナンスする」③　「従業員情報を参照する」と「メンテナンスする」と「従業員情報システム」④　「従業員情報システム」

従業員

管理者

問題５• ユースケース図の特徴を選択しなさい。①　システムの提供する機能とその利用者との関係を　　 明らかにする。②　システムの内部構造を明らかにする。③　システムのデータの流れを明らかにする。④　システムで使用するコンピュータなどのシステム

構成を明らかにする。⑤　システムの状態の遷移を明らかにする。