日本語ユースケースモデリングは、要件を把握するための便利なツールです。これは、ソフトウェアシステムの要件をグラフィカルに表現したものです。
Ivar Jacobson（1991）の著書Object-Oriented Software Engineering、A Use-Case-Driven Approachの出版により、ユースケースモデリングは効果的に実用的な分析手法になりました。今日、ジェイコブソンはシステム分析へのこのアプローチを推進し続け、公式には14種類のUML図の1つであるユースケース2.0にアップグレードしました。1つであるユースケース2.0にアップグレードしています。
ユースケースモデルは概念と外観が単純であるため、技術者以外の担当者（顧客など）とその正確性について比較的簡単に話し合うことができます。
ユースケースは、手順、プロセス、または機能ではありません。
ユースケース図の要素
ユースケース図の要素は、アクター（外部エンティティ）とユースケース自体です。大まかに言えば、ユースケースはシステム内の機能ユニット（要件）またはサービスです。
俳優
アクターとは、人であろうと人間以外の別のエンティティであろうと、設計システムの外部にあるエンティティです。システムのユーザーは、アクターの典型的な例です。他のタイプのアクターには、現在のシステムと統合されているソフトウェアシステム（データベースシステムなど）、センサーなどの外部ハードウェアなどがあります。
UML仕様には2つの表記法があります。
アクターに棒人間を使用する方が表現力がありますが、アクターが実際には人ではなく、機械または外部デバイスである場合、混乱を招く可能性があります。長方形の記号は、クラスの標準のUML表記です。
俳優は実在の人物ではなく役割です
アクターは、インスタンスではなく、現在のシステムと対話するエンティティの役割を表します。 アクター表記は、エンティティが読み取りインスタンスではなくクラスであることを示します（つまり、実際のユーザーJohnまたはMary）。アクターがクラスの一種である理由は、アクター自身ではなく、アクター自身であるためです。
役割だからです。
たとえば、アクターは、顧客ごとに個別のアクターを指定するのではなく、銀行の顧客を表すことができます。同様に、銀行のマネージャーを代表する別のアクターがいる可能性があります。興味深いことに、現実の世界では、銀行のマネージャーが同じ銀行の顧客である場合もあります。言い換えれば、同じ人が顧客とマネージャーの両方の役割を果たします。
ユースケースの主なアクターは、システムにサービスを提供することを要求する利害関係者です。これには、システムに関連付けられた目標があります。これは、システムの操作によって満たすことができる目標です。主なアクターは、常にではありませんが、通常、ユースケースをトリガーするアクターです。
二次俳優はシステムによって使用されますが、それらはそれ自体ではシステムと対話しません。つまり、セカンダリアクターはユースケースを開始しません。
ユースケースは通常、主要なアクターによって開始されます。システムは、一連のユースケースを通じてデータベースなどのセカンダリアクターを使用します。ユースケースと参加者の間の関連付けは、双方向のコミュニケーションを表しています。
したがって、プライマリアクターによって開始されたユースケースごとに、接続されたユースケースに応答する必要があります。同様に、セカンダリアクターとユースケースの間の関連付けごとに、通信はユースケースから始まり、セカンダリアクターは開始に応答する必要があります。
使用事例
ユースケースは、システムによって実装されることが期待される機能（通常は要件）を表します。ユースケースの詳細は、その一意の名前を除いて、図では直感的に表現されていません。これらの詳細は、ユースケースの説明に記載されています。
ユースケースは通常、主要なアクターによって開始されます。システムは、一連のユースケースを通じてデータベースおよびその他の補助参加者を使用します。
ユースケースとアクターの関連付けは、双方向のコミュニケーションを表しています。したがって、メインアクターによって開始されたユースケースごとに、メインアクターに対応する必要があります。同様に、セカンダリアクターとユースケースの間の関連付けごとに、通信はユースケースから始まり、セカンダリアクターは開始に応答する必要があります。
システム境界
システム境界は、周囲の世界に関連して関心のあるシステムを定義します。
ユースケース図の例：航空会社の予約システム
ユースケースは、特定の目標を達成するための外部アクターとシステム間の相互作用を定義します。ユースケース図には、4つの主要なコンポーネントが含まれています
チケット予約システムのユースケース図では、システムは多くの異なるユースケースを含むボックスで表されます。プライマリアクターは顧客であり、セカンダリアクターは管理者です。顧客はフライトの予約、閲覧、キャンセルなどのユースケースを開始し、管理者はフライトレコードの更新などのユースケースを開始しますが、フライトのキャンセルのユースケースでは、完了を支援するだけであるため、セカンダリアクターと見なされます。お客様が開始したユースケース。
ユースケースの構造化
アプリケーション分野と設計者の選択に応じて、ユースケースは複数のユースケースに分割できます。これらのユースケースは、<< include >>または<< extend >>の関係で接続されます。
アソシエーションリンクは、アクターとユースケース間の双方向通信を表すため、バイナリ関係です。これは双方向通信であるため、プライマリアクターによって開始されたユースケースごとに、そのアクターはユースケースから応答を取得する必要があります。
同様に、ユースケースとセカンダリアクター（ユースケースによって開始される）の間の通信ごとに、セカンダリアクターはユースケースに応答を返送する必要があります。
一般化
一般化は、
- 役割または
- ユースケース。
2つのアクターがこの関係で接続されている場合、矢印の端（三角形の下部に接続されている）のアクター（またはユースケース）は、もう一方の端のアクター（またはユースケース）の特殊なバージョンです。
通常、下端（三角形の底に接続されている）のアクター（またはユースケース）は、もう一方の端のアクター（またはユースケース）の特殊バージョンと呼ばれます。
一般化とは、特殊バージョンが一般バージョンのすべての機能を備えていることを意味します。
インクルード は、2つのユースケース間の特別なタイプの関係です。ユースケースAに別のユースケースBが含まれている場合、Aの実装では、タスクを完了するためにBの実装が必要です。ただし、Bはそれ自体から独立しています。つまり、BはAについて何も知る必要はありません。Bは他のユースケースにも含めることができます。
拡張は、2つのユースケース間のもう1つの特別な種類の関係です。ユースケースBが別のユースケースAを拡張する場合、Aの実装には、そのタスクを完了するためのBの実装を条件付きで含めることができます。つまり、場合によっては、AはBなしでタスクを完了することができます。ただし、説明されている条件によっては。
ユースケース図の表記
ユースケース分析を実行するための9つの簡単なステップ
- 誰がシステムを直接使用するかを決定します。これらの人々は俳優です。
- これらの俳優の1人を選んでください。
- そのアクターがシステムで何をしたいのかを定義します。アクターがシステムでやりたいことはすべてユースケースになります。
- 他のすべてのユースケースについて手順2〜3を繰り返します
。特定したユースケースの二次的な役割と人間以外の役割のサポートを特定します。 - ユースケースの初期バージョンを描画します。この時点でユースケースの関係を過度に複雑にしないでください
- 各ユースケースの目標を検証するためにユーザーと話し合い、確認します（提案された機能の利点）変更後、ステップ8〜10でユースケースの詳細を引き続き説明できます。
- ユースケースごとに、システムを使用するときにアクターが従う最も一般的なプロセスを決定します。通常何が起こるか。
- ユースケースの説明で、この基本的なプロセスを説明してください。
- 基本的なプロセスに満足したら、代替シナリオを検討し、これらを拡張ユースケースとして追加します。
ユースケースモデルと仕様
ユースケース図をUML表記で表示するだけでは不十分です。各ユースケースには、ユースケースの目的とユースケースの実行時に実現される機能を説明するテキストが付属しています。
ユースケースは、企業のビジネス価値の結果を生み出すアクターによって実行されるタスクを説明します。ユースケースは、ユースケース図として、または構造化テキスト仕様形式で視覚化できます。
ユースケースシナリオ
ユースケースはいくつかのシナリオで構成され、それぞれがユースケースの特定のインスタンスを表し、アクターからの特定の入力または環境内の特定の条件に対応します。各シナリオは、システムが動作するための代替方法を説明するか、障害または例外を説明する場合があります。
ユースケースには次のものがあります。
- たった1つの目標
- 単一の出発点
- 単一の終点
- 最初から最後まで取得するための複数のパス
- つまり、考えられるさまざまな条件の動作を指定します
- 各条件には、特定のアクションが必要な場合があります
例–顧客は請求書を支払います：
目標を達成するための複数のパスがあります ：
- 電話での支払い
- メールで
- 直接会って
- チェックで
- 現金等
目標に到達しないパス ：
- クレジットカードは拒否されます
パッケージを使用したユースケースのグループ化
次のこともできます。ユースケースを関連するサブシステムに論理的に分類するためのパッケージを描画します。
詳細なユースケース仕様
詳細なユースケースは、イベントのフローおよびその他の関連するユースケース情報を特定の形式で説明するテキスト表現です。標準のユースケーステンプレートは、ユースケースの詳細を文書化するためによく使用されます
ユースケースの説明とは
ユースケースの説明は、アナリストが完全なシステムトランザクションを完了するために実行する一連のステップの説明です。これはアクターによって開始され、そのアクターに価値を提供し、システムで作業するアクターの目標です。
アクター–目標を達成するためにシステムを使用または相互作用する、システムの外部にある人またはシステム。各アクターには、ソリューションとの相互作用を表す役割が与えられます。人物アクターには役割の形で名前を付ける必要があり、実際の名前を割り当てないでください。アクターは通常、プライマリ、セカンダリ、または利害関係者として分類されます
プライマリアクター–ユースケースを開始するアクター。
セカンダリアクター–プライマリアクターによって実行されたアクションに反応または応答するアクター。
利害関係者–ユースケースと直接対話しないが、ユースケースの結果に関心を持っているステージ外のアクター。
イベントフローのフロー（パス） –ユースケースを実行するためにアクターとソリューションが実行する必要のある一連のステップ。一般に、ユースケースは、プライマリ成功パス（基本またはプライマリとも呼ばれます）、代替パス、および例外パスで構成されます。
通常のパス（アクターからの入力とシステムからの応答）は、アクターの目標を達成するための最も一般的な成功パスを表します。
代替パス–アクターからの入力とシステム応答。アクターの目標を達成するための他のあまり一般的でないパスを表します
例外的なパス–アクターからの入力とシステム応答。アクターの目標を達成できない場合の、失敗したパスを表します。
| ユースケースの説明 | |
|---|---|
| ユースケース名： | 現金を引き出します |
| 俳優： | 顧客（一次）、銀行システム（二次） |
| 概要説明： | 銀行の顧客が自分の銀行口座から現金を引き出すことができるようにします。 |
| 優先順位： | 持つ必要があります |
| スターテス： | 中レベルの詳細 |
| 事前条件： | 銀行の顧客はATMに挿入するカードを持っています ATMは正しくオンラインです |
| 事後条件： |
|
| 基本パス： |
|
| 代替パス： |
|
| ビジネスルール： |
|
| 非機能要件： |
|
日本語
English
简体中文
繁體中文
Deutsch
Español
Français
العربية
Italiano
Português
Nederlands
Русский