ユースケース図は、要件を引き出すための統一モデリング言語(UML)図です。ユースケース図は、ユーザー(アクターによって表される)がシステムを使用して達成したい目標(ユースケースによってモデル化された)のグラフィカルな概要を提供します。ユースケース図のユースケースは、関連性、抽象化のレベル、およびユーザーへの影響に応じて整理および配置できます。それらをリンクして、依存関係を表示し、関係を含め、拡張し、生成することができます。
ユースケースは、構築されるシステムが満たすことを目的とした特定のビジネス目標を説明します。グラフィカルに、それは単純に見える名前の楕円形ですが、ビジネス目標またはプロジェクト目標を管理するために使用される最も一般的なツールです。
ユースケース図の表記の概要
表記の説明 |
視覚的表現 |
俳優
- 誰かがユースケース(システム機能)と対話します。
- 名詞で名付けられました。
- 俳優はビジネスで役割を果たします
- ユーザーの概念に似ていますが、ユーザーはさまざまな役割を果たすことができます
- 例えば:
- 教授。インストラクターになることも研究者になることもできます
- 2つのシステムで2つの役割を果たします
- アクターはユースケースをトリガーします。
- アクターはシステム(入力)に対して責任があり、アクターはシステム(出力)からの期待を持っています。
|
。 |
使用事例
- システム機能(プロセス–自動または手動)
- 動詞+名詞(または名詞句)によって名前が付けられます。
- すなわち何かをする
- 各アクターはユースケースにリンクされている必要がありますが、一部のユースケースはアクターにリンクされていない場合があります。
|
。 |
アソシエーションリンク
- ユースケースへのアクターの参加は、アクターをユースケースに強固なリンクで接続することによって示されます。
- アクターは、関連付けによってユースケースに接続できます。これは、アクターとユースケースがメッセージを使用して相互に通信することを示します。
|
。 |
システムの境界
- システム境界は、要件ドキュメントで定義されているシステム全体である可能性があります。
- 大規模で複雑なシステムの場合、各モジュールがシステムの境界になることがあります。
- たとえば、組織のERPシステムの場合、人事、給与、経理などの各モジュール。
- これらの各ビジネス機能に固有のユースケースのシステム境界を形成できます。
- システム全体は、システム全体の境界を表すこれらすべてのモジュールにまたがることができます
|
。 |
延長
- 「無効なパスワード」の ユースケースには、基本ユースケース 「ログインアカウント」で指定された動作が含まれる可能性があることを示します (拡張機能で指定されている場合があります) 。
- 点線のある有向矢印で描いてください。矢印の先端はベースユースケースを指しており、子ユースケースは矢印のベースで接続されています。
- ステレオタイプ「<<extends>>」は、拡張関係として識別されます
|
。 |
含む
- ユースケースが別のユースケースの機能を使用するものとして描かれている場合、ユースケース間の関係は、包含または使用関係として名前が付けられます。
- ユースケースには、ビジネスプロセスフローの一部として別のユースケースで説明されている機能が含まれます。
- 基本ユースケースから子ユースケースへの使用関係は、基本ユースケースのインスタンスに、子ユースケースで指定された動作が含まれることを示します。
- 包含関係は、点線のある有向矢印で示されます。矢印の先端は、矢印の基部で接続されている子のユースケースと親のユースケースを指しています。
- ステレオタイプ「<<include>>」は、関係を包含関係として識別します。
|
。 |
一般化
- 一般化関係は、ユースケース間の親子関係です。
- 子のユースケースは、親のユースケースを拡張したものです。
- 一般化は、三角形の矢印の付いた有向矢印として示されています。
- 子のユースケースは、矢印の基部で接続されています。矢印の先端は、親のユースケースに接続されています。
|
ユースケース図–車両販売システム
次の図は、車両システムのユースケース図の例を示しています。ご覧のとおり、自動車販売システムと同じくらい大きなシステムでも、10個以下のユースケースが含まれています。それがユースケースモデリングの美しさです。
ユースケースモデルは、extendとincludeの使用法も示しています。さらに、アクターとユースケースを結び付ける関連付けがあります。