UMLユースケース図とは何ですか?

ユースケース図は、アクター、ユースケース、およびそれらの間の関係で構成されるシステム機能を記述するために使用されるビューであり、アクターと呼ばれるシステム機能のモデル図です。ユースケース図は、要件分析フェーズでよく使用されます。

・ユースケース図の目的

システムを開発する前に最も重要な作業はユーザーのニーズを把握することですが、ユーザーのニーズの中で最も重要なものは、ユーザーが提案するシステムの機能要件をユースケース図を使用して視覚的に表現することができます。

視覚的なユースケース図

・ユースケース図の構成

ユースケース図の主な要素には、アクター、ユースケース、要素間の関係が含まれます。これに加えて、ユースケース図には注釈と制約を含めることもできます。

参加者

1. 参加者の概念

アクターは、メインシステムと対話する外部エンティティであり、システムの外部にある人、サブシステム、その他のシステムなどが考えられます。

それぞれの俳優は実際には役割が設定されています。 UML では、アクターは人の形を使用してグラフィカルに表現され、名前が付けられます。下の図に示すように、「読者」は図書館の貸出システムの参加者です。

ユースケース図のアクター

アクターはシステムの一部ではなく、システム境界の外側にある必要があります。

2. 参加者の特定方法

ユースケースモデリングを行う場合、アクターを特定することがユースケース図モデリングの最初のステップです。では、システムの参加者をどのように決定するのでしょうか?次のような考え方から考えることができます。

(1) システムのサービス対象 - 図書館貸出システムにおけるリーダーなど。

(2) 作業を完了するためのサポートを提供する人 - 図書館貸出システムの図書館スタッフなど、読者が本の貸し出し、返却、リマインダーを完了するのを支援するためにシステムを使用する必要がある人。

(3) システム保守者: システムのインストール、保守、および管理を担当する人。この場合、システムは、そのような担当者がインストール、保守、および管理作業を完了できるように関連する機能を提供する必要があります。

(4) 外部デバイス: カードリーダーなどの外部デバイスに情報を送信したり、外部デバイスから情報を読み取る必要があります。

(5) 他のシステムまたはサブシステム: 融資システムの金融システムなど。金融システムは融資システムの機能ではありませんが、期限を過ぎた細かい作業を完了するために融資システムに情報を送信する必要があります。

(6) 時間: スケジュールされた瞬間に、自動バックアップ、定期的なリマインダーなどの特定のイベントが自動的に発生します。

(7) 特定のイベント: たとえば、テイクアウトシステムでの自動注文受信は、注文生成イベントによって駆動されます。

参加者を特定するときは、次の点に注意してください。

(1) 参加者はシステムの一部ではなく、システムの外部にいます。

(2) 参加者はシステム境界を介してシステムと対話します。

(3) 参加者のアイコンは人型のアイコンで表されているが、参加者は必ずしも人である必要はなく、他のサブシステム、他のシステム、時間、温度等の要因であってもよい。

3. 参加者同士の関係

参加者間の主な関係は一般化です。一般化は、より一般的な参加者を指し、「特定の」参加者の側で終わる実線の白三角矢印で表されます。一般化関係とは、一般的なものと特定のもの（具体的なもの）との間の関係です。一般化関係では、参加者の抽象的な説明を 1 人以上の具体的な参加者が共有できます。次の図は、図書館貸出システムの参加者間の一般化された関係を示しています。

図書館貸出システム参加者間の一般化関係

読者の下にある教員、学生、退職教員などが「特定」参加者です。参加者の一般化は次のように理解できます。「特定の」参加者は、一種の読者である教員などの「一般的な」参加者です。アクターの一般化では、「一般的な」アクターによって実行可能なユースケースは、「具体的な」（「特別な」）アクターによって実行可能なものとして表されます。

使用事例

1. ユースケースの概念

ユースケースは、参加者が体験できるシステムサービスまたは機能単位です。システムが達成すべき目標を定義します。ユースケースはシステムの動作を定義するだけで、システムの内部構造は明らかにしません。

ユースケースの最大の利点は、ユーザーの視点からシステム機能を説明できることです。グラフィカルに、ユースケースは実線の楕円で表され、楕円の内側または下にユースケースの名前が表示されます。

本を借りるユースケース

2. ユースケースを特定する

ユースケースは次の点から特定できます。

(1) 参加者が自分の作業をサポートするために、システムにどのような機能が必要ですか?

(2) 参加者はシステム内の情報をクエリする必要がありますか?

(3) 参加者は、作成、変更、削除操作など、システム内の一部の情報を変更する必要がありますか?

(4) 特定のイベントやシステムのステータスの変化について参加者に通知する必要がありますか?

(5) システム内のどのような外部イベントが、それに応じてシステムに関連する機能の実行を促すのでしょうか?

(6) システムは、保守担当者がシステムを保守するのに役立つ関連機能を提供しますか?

3. ユースケース特定の重要なポイント

(1) 特定されたユースケースは、システムの目標、つまり「方法」ではなく「何を行うか」を反映している必要があります。これは、ユースケースがシステム実装の詳細ではないことを意味します。

(2) システムの観点ではなく、参加者（ユーザー）の観点からユースケースを定義します。

(3) ユースケースは、アクションの集合ではなく、参加者に価値のある結果を提供する必要があります。

(4) 機能分解や段階分解に陥ることを避ける。

(5) 各参加者は実行可能なユースケースを持つ必要があり、各ユースケースは少なくとも 1 人の参加者に関連付けられる必要があります。

4. ユースケースの名前付け

システムのユースケースを決定したら、それぞれのユースケースに名前を付ける必要があります。ユースケースの名前付けでは、ユーザーの観点から参加者が達成する目標を説明する必要があります。次の名前付け方法を使用できます。

動詞+目的語

つまり、ユースケースの名前は動詞と目的語の句の形式である必要があります。コースの選択、本の貸し出し、商品の注文、クレジットカードでの支払いなど。

5. ユースケースの粒度

ユースケースの粒度は、ユースケースがシステム機能を洗練または統合する度合いを指し、ユースケースに含まれるシステムサービスまたは機能単位の数とも言えます。ユースケースの粒度が粗すぎるか大きすぎる場合、ユースケースにはより多くのシステム機能が含まれることになり、その逆も同様です。ユースケースの粒度が粗すぎるとシステムを理解することが難しくなり、粒度が細かすぎるとユースケースモデルが大きすぎて設計が困難になります。ユースケースが細分化しすぎると、次のような機能分解に陥る可能性があります。

ユースケース粒度の初期値

実際、多くのビジネスでは、システムに追加、削除、変更、確認などの操作が含まれており、これを行うとユーザーに意味のある目的は提供されず、ユーザーの本当の目的が無視されます。

上記の「追加・削除・修正・確認」は、参加者の真の目的であるユーザー管理に他なりません。上記のユースケースを次のように処理する方が良いかもしれません。

ユースケースの粒度の縮小

ユースケース「ユーザーの管理」は、システム管理者の目標またはタスクを表します。追加、削除、修正、問い合わせが必要な場合は、次のように表現するとよいでしょう。

ユースケース粒度の最適化後

ユースケースのモデリングでよくあるもう 1 つの間違いは、ステップをユースケースとして扱うことです。たとえば、次の例は完璧に見えますが、操作手順がユースケースとみなされていることは明らかです。

ユースケースとしての操作手順エラー例

上記の手順は、参加者としてのユーザーの目標である登録を完了することに他なりません。したがって、次のように変更する必要があります。

ユースケースの最適化後

ユースケースモデリングにおいて、3 番目によくある間違いは、システムアクティビティをユースケースとして扱うことです。以下のユースケース図では、接続オブジェクトの確立、コマンドオブジェクトの作成、および SQL ステートメントの実行は、ユーザーが認識できないシステム内のアクティビティであり、ユーザーの目的ではないため、ユーザーは気にしません。したがって、このユースケース図は不正確です。

システムアクティビティのユースケースエラーの例

ユースケースモデリングにおける 4 番目のよくある間違いは、システムの観点を使用してユースケースに名前を付けることです。

システムのパースペクティブを使用してユースケースのエラー例に名前を付ける

上の 2 つのユースケース図のうち、どちらが優れていますか?明らかに、右側のユースケースは左側よりも優れています。右側のユースケースはユーザーの観点から名前が付けられているのに対し、左側のユースケースはシステムの観点から名前が付けられているため、ユーザーは後で混乱を感じるでしょう。それを見て。

6. ユースケースの仕様

ユースケース図は一般にユーザーの機能要件 (システムが提供する機能やサービス) を説明しますが、各ユースケースが具体的に何をするのかを理解できるように、各ユースケースを詳細に説明する必要があります。これがユースケース仕様です。つまり、ユースケースモデルは本質的に、ユースケース図と各ユースケースの詳細な説明 (ユースケース仕様) で構成されます。

ユースケース仕様には次の内容を含める必要があります。

(1) ユースケースの識別名と名前。

(2) ユースケースに関与する参加者。

(3) 使用例の簡単な説明。

(4) その他の関連する使用例。

(5) ユースケース実行の前提条件

(6) 基本的なイベントの流れ。

(7) 代替イベントフロー。

(8) ユースケース実行の事後条件。

(9) その他の情報（非機能要件、設計制約、ユースケースの検討状況、作成者、変更記録等）

・ユースケース間の関係

ユースケース間の関係には主に、一般化、包含、拡張の 3 つのタイプがあります。

一般化関係

複数のユースケースが類似の属性または動作を持つ場合、それらの共通性を親ユースケースに抽象化し、他のユースケースを汎化関係の子ユースケースとして、親ユースケースの属性と動作を継承することができます。ユースケースの一般化関係は、同じビジネス目的に対する異なる実装パスとして理解できます。

一般化関係は、子ユースケースから親ユースケースを指す中空の三角形の矢印を持つ実装によってグラフィカルに表されます。

ユースケース図の一般化関係

上記の例では、「Payment Method 1 」と「Payment Method 2 」は「Payment」のサブユースケースです。親ユースケース「Payment」は特定の支払い方法を提供せず、支払いに必要な属性とインターフェイスのみを提供し、子ユースケースに特定の支払い機能を実装します。

包含関係

システムモデリングプロセスでは、いくつかの機能をさまざまなビジネスシナリオで繰り返し使用する必要があります。これらの繰り返し使用される関数を分離して別のユースケースを形成し、関連する関数を実行する際に、分離したパブリック関数をメインプロセスに含めることができます。さらに、基本的なユースケースの機能が多すぎる場合は、複数の小さなユースケースに分割することもできます。含まれるユースケースはプロバイダーユースケースと呼ばれ、他のユースケースを含むユースケースはクライアントユースケースと呼ばれます。

UML では、インクルード関係は、<<include>> ステレオタイプを持つ点線の矢印で表され、矢印は基本的なユースケース (ユースケース/顧客のユースケースを含む) から含まれるユースケース (プロバイダのユースケース) を指します。

関係を含むユースケース図

以下は具体的な例です。この例では、読者は書籍を事前に借りる前にクエリブックユースケースを実行する必要があります。そのため、クエリブックユースケースが含まれます。本の事前借入の使用例同時に、読者は次のことを行う必要があります。書籍を事前に借りる場合、読者はシステムにログインしている必要があり、事前借用操作を実行する前にシステムがログインステータスを保存します。本人確認のユースケースは、事前貸出本のユースケースにも含まれます。書籍の検索は、読者に必要な基本的な機能であるだけでなく、他の機能にも必要な操作プロセスです。本人確認は、書籍を事前に借りるときだけでなく、貸出記録の照会や罰金の支払いなどの機能を実行するときにも使用されます。ユースケースを形成するには、本人確認を個別に提案する方が適切です。