はじめに
A ユースケース図は、次の定義に基づく行動図の一種である統一モデリング言語(UML)。ユーザー(アクター)とシステムの間の相互作用を、特定の目標を達成するために記述するために使用される。ユースケース図は、ユーザーの視点からシステムの機能要件を理解し、文書化するために不可欠である。このチュートリアルでは、Wheels自転車レンタルシステムを例に、ユースケース図の作成と理解の方法を紹介する。
ユースケース図とは何か?
A ユースケース図は以下の主要な構成要素で構成される:
- アクター:システムと相互作用するユーザーまたは外部システムを表す。アクターは人間、他のシステム、またはハードウェアデバイスであることができる。
- ユースケース:システムがアクターに提供する特定の機能またはサービスを表す。各ユースケースは、アクターがシステムと相互作用することで達成したい目標を記述する。
- 関係:
- 通信関連:アクターとユースケースを結ぶ線で、アクターがそのユースケースに参加していることを示す。
- 包含:1つのユースケースが別のユースケースの振る舞いを含むユースケース間の関係。
- 拡張:特定の条件下で、1つのユースケースが別のユースケースの振る舞いを拡張するユースケース間の関係。
ユースケース図の作成
ステップ1:アクターの特定
システムと相互作用するすべてのアクターを特定する。Wheels自転車レンタルシステムの場合、アクターは以下の通りである。
- 管理者
- 受付担当者
ステップ2:ユースケースの特定
システムが提供する主要な機能またはサービスを特定する。各ユースケースは、アクターが達成しようとする具体的な目標を表すべきである。Wheelsシステムにおけるユースケースは次のとおりである。
- 自転車リストの維持
- 顧客リストの維持
- 問い合わせの対応
- 自転車の発行
- 自転車の返却処理
- 自転車の検索
- 領収書の印刷
ステップ3:ユースケース図の作成
- アクターの描画:アクターを人形で表す。
- ユースケースの描画:ユースケースを楕円で表す。
- アクターとユースケースを接続する:線を使って、アクターとそれらが参加するユースケースを接続する。
- 関係の追加:点線の矢印を使って、「include」および「extend」の関係を表す。
例:Wheels自転車レンタルシステム
提供された画像をもとに、Wheels自転車レンタルシステムのユースケース図を作成しましょう。
アクター:
- 管理者
- 受付担当者
ユースケース:
- 自転車リストの維持
- 顧客リストの維持
- 問い合わせの対応
- 自転車の発行
- 自転車の返却処理
- 自転車の検索
- レシートの印刷
ユースケース図:

説明:
- アクター:
管理者(管理者)受付担当者(受付)
- ユースケース:
自転車リストの管理(UC1)顧客リストの管理(UC2)問い合わせの対応(UC3)自転車の発行(UC4)自転車の返却処理(UC5)自転車の検索(UC6)レシートの印刷(UC7)
- 関係:
- その
受付担当者は以下の関与を含む問い合わせの対応,自転車の発行、および自転車の返却の対応. - その
管理者は関与している自転車リストの維持および顧客リストの維持. - その
自転車の発行ユースケースには以下のものが含まれる問い合わせの対応ユースケース。 - その
自転車の返却の対応ユースケースには以下のものが含まれる領収書の印刷ユースケース。 - その
自転車の発行ユースケースは以下のものを拡張する顧客リストの維持ユースケース。 - その
自転車の検索使用ケースは以下のものに含まれます自転車リストの維持,顧客リストの維持,問い合わせの対応、および自転車の発行.
- その
使用ケースの説明
図の他に、使用ケースを説明とともに記録することが重要です。使用ケースの説明には通常、以下の内容が含まれます:
- 使用ケース名:使用ケースの名前。
- アクター:使用ケースに関与するアクター。
- 目的:使用ケースの目的または目的。
- 概要:使用ケースで何が起こるかの簡単な説明。
- 通常のイベントの流れ:イベントの通常の流れを段階的に説明。
- 代替の流れ:イベントの代替的または例外的な流れの説明。
例:自転車発行の使用ケースの説明
使用ケース:自転車の発行
アクター:受付担当者
目的:自転車を貸し出すこと
概要: 顧客が店に来店すると、レンタルする自転車を選択します。受付担当者はシステム上で自転車を検索し、指定された期間のレンタル料金を顧客に伝えます。顧客は料金を支払い、領収書を受け取り、その後自転車を持って店を出ます。
通常の流れ:
- 顧客は自転車を選択する。
- 受付担当者は自転車番号を入力する。
- システムは自転車の詳細(日額レンタル料金および保証金を含む)を表示する。
- 顧客はレンタル期間を指定する。
- 受付担当者はレンタル期間を入力する。
- システムは合計レンタル料金を表示する。
- 顧客は料金に同意する。
- 受付担当者は顧客の情報を入力する。
- システムは顧客の情報を表示する。
- 顧客は合計料金を支払う。
- 受付担当者は支払い金額を記録する。
- システムは領収書を印刷する。
代替の流れ:
- ステップ8と9:顧客の情報はすでにシステムに登録されているため、受付担当者は識別子を入力するだけでよく、システムは顧客の情報を表示する。
- ステップ7~12:顧客が料金に満足せず、取引を中止する可能性がある。
自転車発行ユースケース:詳細説明
Wheels自転車レンタルシステムにおける「自転車発行」ユースケースは、顧客に自転車を貸し出すプロセスを表しています。このユースケースでは、受付担当者とシステムとの間で複数のやり取りが行われ、自転車の発行という目的を達成します。以下では、「自転車発行」ユースケースのイベントの流れと、「include」と「extend」ユースケースとの関係について説明します。
参加者:
- 受付担当者: 自転車を発行するためにシステムとやり取りする主要な参加者。
目的:
- 顧客に自転車を貸し出すこと。
概要:
顧客が店に来店すると、レンタルする自転車を選択します。受付担当者はシステム上で自転車を検索し、指定された期間のレンタル料金を顧客に伝えます。顧客は料金を支払い、領収書を受け取り、その後自転車を持って店を出ます。
通常の流れ:
- 顧客が自転車を選択する: 顧客は利用可能な選択肢から自転車を選択する。
- 受付担当者が自転車番号を入力する: 受付担当者が自転車番号をシステムに入力する。
- システムが自転車の詳細を表示する: システムは自転車の詳細(日額レンタル料金や保証金を含む)を表示する。
- 顧客がレンタル期間を指定する: 顧客は自転車をどのくらいの期間借りたいかを示す。
- 受付担当者がレンタル期間を入力する: 受付担当者がレンタル期間をシステムに入力する。
- システムがレンタル総額を表示する: システムは自転車のレンタル総額を計算し、表示する。
- 顧客が価格に同意する: 顧客はレンタル料金に同意することを確認する。
- 受付担当者が顧客情報を入力する: 受付担当者が顧客の情報をシステムに入力する。
- システムが顧客情報を表示する: システムは入力された顧客情報を確認のために表示する。
- 顧客が総額を支払う: 顧客が支払いを行う。
- 受付担当者が支払額を記録する: 受付担当者がシステムに支払いを記録する。
- システムが領収書を印刷する: システムは顧客用の領収書を生成して印刷する。
他のユースケースとの関係:
- 包含関係を含む:
- 問い合わせの対応: 「自転車発行」ユースケースは「問い合わせの対応」ユースケースを含む。これは、自転車が発行されるたびに、システムが自転車の利用可能状況や料金に関する問い合わせに対応しなければならないことを意味する。『自転車発行』ユースケースのイベントフローは、常に問い合わせの対応を含む。
- 自転車を探す: 「バイク発行」ユースケースは「バイク検索」ユースケースを含みます。これは、受付担当者が入力されたバイク番号に基づいてバイクの詳細をシステムで検索することを意味します。これはバイクを発行するための必須ステップです。
- 拡張関係:
- 顧客リストの維持: 「バイク発行」ユースケースは「顧客リストの維持」ユースケースを拡張します。これは、バイクを発行する過程で、新しい顧客を追加するか、既存の顧客情報の更新が必要になる可能性があることを意味します。この拡張は条件付きであり、必要がある場合にのみ発生します。
包含および拡張ユースケースを含むイベントの流れ:
- 顧客がバイクを選択する: 顧客はバイクを選択します。
- 受付担当者がバイク番号を入力する: 受付担当者がバイク番号を入力します。
- 包含:バイク検索: システムは入力された番号に基づいてバイクの詳細を検索します。
- システムがバイクの詳細を表示する: システムは、日額レンタル料金および保証金を含むバイクの詳細を表示します。
- 包含:問い合わせの処理: システムはバイクの利用可能状況および料金に関する問い合わせを処理します。
- 顧客がレンタル期間を指定する: 顧客はレンタル期間を示します。
- 受付担当者がレンタル期間を入力する: 受付担当者がレンタル期間を入力します。
- システムが総レンタル料金を表示する: システムは総レンタル料金を計算して表示します。
- 顧客が価格に同意する: 顧客はレンタル料金を確認します。
- 受付担当者が顧客情報を入力する: 受付担当者が顧客の情報を入力します。
- 拡張:顧客リストの維持: 顧客が新規の場合、または情報の更新が必要な場合、システムは顧客情報を追加または更新します。
- システムが顧客情報を表示する: システムは入力された顧客情報を確認のために表示します。
- 顧客が合計費用を支払う: 顧客が支払いを行う。
- 受付担当者が支払額を記録する: 受付担当者が支払いを記録する。
- システムが領収書を印刷する: システムは顧客向けの領収書を生成して印刷する。
「自転車発行」ユースケースは、受付担当者とシステムの間で複数の相互作用を含む包括的なプロセスである。「自転車検索」と「問い合わせ対応」ユースケースとの「include」関係を使用することで、自転車の詳細の検索や問い合わせの対応といった必要手順が常に実行されることを保証する。「顧客リストの維持」ユースケースとの「extend」関係により、顧客情報の条件付き追加または更新が可能となり、自転車発行プロセスに柔軟性を提供する。これらの関係を理解することで、機能要件を効果的に満たす堅牢でユーザー中心のシステムの構築が可能となる。
結論
ユースケース図はソフトウェア開発プロセスにおいて特にオブジェクト指向開発の分野で不可欠なツールである。ユーザー(アクター)がシステムとどのように相互作用して特定の目的(ユースケース)を達成するかを明確かつ簡潔に視覚的に表現する。アクター、ユースケース、およびそれらの関係を特定することで、開発者はシステムの機能要件を効果的にモデル化し、伝達できる。
Wheels自転車レンタルシステムの文脈において、我々は以下のように作成する方法を示した。ユースケース図異なるアクター(受付担当者および管理者)とシステムの機能(自転車および顧客リストの維持、問い合わせの対応、自転車の発行、自転車の返却など)の相互作用を捉える。また、「include」と「extend」の関係を組み込むことで、共通の行動と追加の行動をそれぞれ表現する方法も示した。
ユースケース図とその説明は、他のUMLモデルの作成やシステムの最終的な実装を含む、さらなる開発活動の基盤となる。本チュートリアルで示された手順に従うことで、開発者はシステムの要件について包括的な理解を得られ、ステークホルダーにこれらの要件を効果的に伝えることができる。
要するに、ユースケース図の作成と解釈を習得することは、堅牢でユーザー中心のシステムを構築しようとするすべてのソフトウェア開発者にとって不可欠である。ユースケース図実践を重ねることで、これらの図は、あらゆるソフトウェアプロジェクトの機能要件のモデル化、文書化、検証において不可欠なツールとなる。










