ユースケース図2-4～ FM11012 中島拓也

ユースケース記述とは。 ユースケースだけでは詳細な記述ができない。 その為、情報が不足してしまう。 １つ１つのユースケースに対して、詳細なユースケースのドキュメントを追加する事。

ユースケース記述は、以下の３つを指します。 概要 シナリオ イベントフロー

概要 ユースケースの役割、目的などを数行で記述する。 例えば、Webショッピングシステムにおいて、　　　　　　　「商品を購入するためには、会員になる必要があります。このユースケースは会員の登録を行います。」 と記述します。

シナリオ ユースケースの具体的な流れの１つを記述する。 ここでの名前、数字などは具体的に記述する。 つまり、システムを実際に使用した場合のやり取りをそのまま記述したようなものになる。 シナリオは１つのユースケースに複数存在することになるが、以下の２つに大別できる。 基本シナリオ・・・目的が達成できたシナリオ 例外シナリオ・・・目的が達成できなかったシナリオ

Webショッピングシステムの会員登録するユースケースの例では、 基本シナリオ 実際に会員登録できた場合。 例外シナリオ クレジット番号が照合できないなど、会員として登録できなかった場合。

イベントフロー ユースケースの流れをすべてを網羅するように記述する。 具体的な名前や数字は用いず、汎用的に表現する。

以下がイベントフローで記述する項目。 事前条件 事後条件 ユースケースが終了した後のシステムに対する制約。 基本フロー 基本的な流れ。 ユースケースを開始できる状態についてのシステムに対する制約。 事後条件 ユースケースが終了した後のシステムに対する制約。 基本フロー 基本的な流れ。 代替フロー 頻度が少ない正常な流れ。 例外フロー 正常終了しない流れ。

ユースケース図で使用する関係 関連 包含 拡張 汎化 アクターとユースケースの関係に使用。 ユースケース同士の関係に使用。 アクター同士の関係に使用。

関連 実線で表現する。 多重度(他のクラスのオブジェクトが接続される可能性のある要素の数)をつけることも可能。 「注文受付係」アクターから「注文を受け付ける」ユースケースへの関連を表現。 関連 注文を受け付ける １ ＊ 多重度 アクター

包含 イベントフローで共通だった部分を図示でき、複数のイベントフローの関係を視覚的に理解することが可能となる。 例えば、ユースケースAとユースケースBの一部に同様の流れがある場合、その部分をくくりだして新たなユースケースCを作成する。 ステレオタイプをつけた依存関係を、包含するユースケースから包含されるユースケースに対して引いて表現する。 A <<include>> ------------------> 包含するユーケース C ------------------> B <<include>> 包含されるユースケース

そこで、これらのユースケースから、新たに「ログインする」というユースケースを作成し、包含の関係を引くことが出来る。 Webショッピングシステムの例で考えると、「買い物かごに入れる」「買い物かごから戻す」「商品一覧を表示する」「購入する」というユースケースはすべて、ログインしてから行う。 そこで、これらのユースケースから、新たに「ログインする」というユースケースを作成し、包含の関係を引くことが出来る。 かごに入れる <<include>> -------------------> かごから戻す <<include>> ----------------- ログインする -----------------> 一覧を表示 <<include>> -----------------> <<include>> 購入する

拡張 あるユースケースAの、一部分を利用したり利用しなかったりする場合に、その部分を新たなユースケースBとして作成する。 そして、 <<extend>>を付けた依存関係を、ユースケースBからユースケースAに対して、拡張の関係を引く。 ユースケースBがもともと独立したユースケースで、それをユースケースAがオプショナルに利用する場合も同様に拡張の関係を引く。

拡張されるユースケースの流れの中で拡張を提供するユースケースへ分岐するところが拡張点である。 拡張点はユースケース名の下に線を引いて区間を設け、そこに記述する。 A 拡張点 拡張を提供される ユースケース <--- -------- <<extend>> B 拡張を提供する ユースケース

「配送先を指定する」というユースケースを新たに作成して、もとの「購入する」ユースケースと拡張の関係で接続する。 例えば、Webショッピングシステムで「購入する」というユースケースの場合、配送先の確認画面が出る。配送をデフォルトの設定以外にする時、配送先を指定しなおさなければならない。 「配送先を指定する」というユースケースを新たに作成して、もとの「購入する」ユースケースと拡張の関係で接続する。 <---------------------- 購入する 配送先の確認 配送先を指定 <<extend>>

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

抽象アクター アクター同士に汎化関係を導入したとき、上位のアクターが抽象アクターになる場合がある。 下位アクターをまとめる意味で作成するもの。 抽象アクターは斜体で表記する。 例えば、Webショッピングシステムでは、「特別会員」と「一般会員」の」２種類の会員がいる。 抽象アクター 会員 特別会員 一般会員

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

抽象ユースケース Webショッピングシステムにおいて、「商品を検索する」というユースケースを作成したが、実際には「商品名で検索する」または、「商品カテゴリで検索する」のどちらかを使用する。 「商品を検索する」を直接アクターが起動するわけではない、このような時に抽象ユースケースと呼ぶ。 商品を検索する 抽象ユースケース(斜体) 商品名で 検索する 商品カテゴリで検索する

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

問題２ アクターの候補にならないものを選択しなさい。 ① システムを利用するユーザ ② 既存システム ③ 開発対象の機能 ① システムを利用するユーザ ② 既存システム ③ 開発対象の機能 ④ システムと直接通信をするハードウェア

問題３ 正しいアクターの表記を選択しなさい。 ① ② アクター アクター ③ ④ アクター アクター

問題４ 以下の図にあるすべてのユースケースを含むものを選択しなさい。 従業員情報システム 従業員情報を参照する 従業員 メンテナンスする 管理者 ①　「従業員」と「管理者」 ②　「従業員情報を参照する」と「メンテナンスする」 ③　「従業員情報を参照する」と「メンテナンスする」と「従業員情報システム」 ④　「従業員情報システム」

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