ユースケース図：実践ガイド

Aユースケース図は、外部のユーザーやシステムがシステムとどのように相互作用するかを示すUMLの行動図です。これは、アクターの視点からシステムが何を行うかに焦点を当て、内部の実装詳細には焦点を当てません。

ユースケース図は、システム機能と範囲の概要を提供するため、要件分析の段階で特に有用です。

1. ユースケース図が示すもの

ユースケース図には通常、次の要素が含まれます：

• システム境界 — モデル化されているシステム内の範囲を定義します。

• アクター — システムと相互作用する外部のユーザー、組織、デバイス、またはシステム。

• ユースケース — システムが提供する目標またはサービス。

• 関連 — アクターとユースケース間の通信リンク。

• ユースケース間の関係 — 例えば、<<include>>および<<extend>>.

• 一般化 — アクター間またはユースケース間の継承。

ユースケース図は通常、次のようなものは示しません：

• アルゴリズムの手順

• データベーステーブル

• プログラムのクラス

• 内部ワークフロー

• 詳細なユーザーインターフェースレイアウト

• 時間経過に伴うメッセージシーケンス

それらの詳細は、アクティビティ図、クラス図、シーケンス図、または状態図でより適切に表現されます。

2. 主要な概念

システム境界

システム境界は、システムに属するユースケースを囲む長方形です。

例えば、オンラインショッピングシステムでは：

+--------------------------------------+
|        オンラインショッピングシステム        |
|                                      |
|  (製品を閲覧)                   |
|  (注文を提出)                       |
|  (支払いを行う)                      |
+--------------------------------------+

アクターはシステム外部であるため、境界の外側に留まります。

境界はシステムの範囲を明確にするのに役立ちます。ある機能が境界の外側にある場合、それはモデル化されているシステムによって実装されません。

アクター

「アクター」とは、目標を達成するためにシステムと相互作用する外部のあらゆるものを指します。

アクターには以下が含まれます：

• 人間のユーザー

• 外部アプリケーション

• ハードウェアデバイス

• 他の組織

• 時間またはスケジュールされたイベント（外部トリガーとしてモデル化された場合）

例：

• 顧客

• 司書

• 決済ゲートウェイ

• 管理者

• メールサービス

アクターは「役割、必ずしも特定の個人を指すわけではありません。例えば、「顧客」は通常、「アレックス」よりも適切です。

アクターは次のように分類できます：

• 主たるアクター — 目標を達成するために相互作用を開始します。

• 支援アクター — システムにサービスを提供します。

例えば、顧客が「注文を提出する」を開始し、決済ゲートウェイが「支払い処理」をサポートします。

ユースケース

「ユースケース」は、システムが提供する意味のある目標またはサービスを表します。

適切なユースケース名は通常、次の形式に従います：

動詞 + 目的語

例：

• アカウントを登録する

• カタログを検索する

• 申請を提出する

• レポートを生成する

• 予約をキャンセルする

• 支払いを処理する

ユースケースは、内部の実装ステップではなく、観測可能な結果を記述すべきです。

以下を推奨します：

注文を提出する

ではなく、以下を避けてください：

注文オブジェクトを検証する

後者はユーザーの目標ではなく、内部操作を記述しています。

関連付け

関連付けは、アクターとユースケース間の通信リンクです。

これは、アクターがそのユースケースに参加するか、または開始することを示します。

顧客 ---- (注文を提出する)

アソシエーションは通常、順序、制御フロー、または方向を示しません。相互作用の順序が重要である場合は、シーケンス図またはアクティビティ図を使用してください。

3. ユースケース間の関係

<<include>>

使用<<include>>は、あるユースケースが常に別のユースケースを使用する場合に使用します。

例えば、注文を行う際には常に認証が必要となる場合があります：

(注文を行う) ..> (顧客認証) : <<include>>

基本ユースケースは、含まれるユースケースに依存します。

使用includeは、以下の場合に使用します：

• その動作が必須である場合。

• その動作が複数のユースケースで再利用される場合。

• その動作を抽出することで明確性が高まる場合。

例：

(現金を引き出す) ..> (カード認証) : <<include>>
(残高を確認する) ..> (カード認証) : <<include>>

両方のユースケースは常にカード認証を必要とします。

<<extend>>

使用<<extend>>は、追加の動作がオプションであるか、基本ユースケースに条件付きで挿入される場合に使用します。

(割引を適用する) ..> (注文を行う) : <<extend>>

割引動作は、適用条件が満たされた場合にのみ発生します。

使用extendは、以下の場合に使用します：

• その動作がオプションである場合。

• これは特定の条件下でのみ発生します。

• 基本ユースケースは、これなしでも完了します。

例：

• 「ギフト包装の追加」は「注文の提出」を拡張します。

• 「返金依頼」は「サブスクリプションのキャンセル」を拡張します。

• 「プロモーションメールの送信」は「登録完了」を拡張します。

矢印は、拡張するユースケースから基本ユースケースを指します。

一般化

一般化は、アクターまたはユースケース間の「～である」という関係を表します。

例：

プレミアム顧客 --|> 顧客

プレミアム顧客は顧客の一種であり、顧客のインタラクションを継承します。

複数のアクターが共通の動作を共有する場合、アクターの一般化は有用です：

管理者 --|> 従業員
司書 --|> 従業員

一般化は控えめに使用してください。関係が単に「使用する」または「参加する」だけである場合、通常は関連付けの方がより適切です。

4. 主要アクターと支援アクター

オンライン決済のシナリオを考えてみましょう：

• 「顧客」は主要アクターです。なぜなら、彼らが購入を開始するからです。

• 「決済ゲートウェイ」は支援アクターです。なぜなら、システムからの要求に応じて決済を処理するからです。

単純なモデルは次のようになります：

顧客 ---- (注文の提出)
(注文の提出) ---- 決済ゲートウェイ

この区別は有用です。なぜなら、誰がユースケースから利益を得るのか、およびどの外部システムが関与しているのかを明確にするからです。

5. ユースケースの特定方法

ユースケースを発見するための実用的な方法は、次のように問うことです：

1. 誰がシステムを使用しますか？

2. 各アクターが達成したい目標は何ですか？

3. システムはどのようなサービスを提供しますか？

4. どのようなイベントがシステムの動作を引き起こしますか？

5. システムはどのような外部システムと連携する必要がありますか？

6. 常に必要な動作は何ですか？

7. オプションまたは条件付きの動作は何ですか？

各アクターについて、その目標をリストしてください：

目標はアクターにとって意味のあるものであるべきです。システムのごく小さな操作をすべてユースケースに変換しないようにしてください。

6. 命名ガイドライン

明確で目標指向の名前を使用してください。

良い例：

• アカウントを作成

• プロフィールを更新

• 請求を提出する

• 荷物の追跡

• リクエストを承認する

• 請求書を生成する

あいまいな名称を避ける：

• システム処理

• データを処理する

• ユーザー機能

• 操作を実行する

過度な技術的詳細を避ける：

• SQL クエリを実行する

• REST エンドポイントを呼び出す

• PaymentService をインスタンス化する

これらは有効な実装ステップである可能性がありますが、通常、高レベルのユースケースとしては有用ではありません。

7. 例：図書館管理システム

図書館システムが以下の機能をサポートすると仮定します：

• 会員による書籍の検索

• 会員による書籍の貸出

• 会員による書籍の返却

• 司書によるカタログの管理

• 延滞通知

• 延滞料金の支払い処理

考えられるアクター：

• 会員

• 司書

• 通知サービス

• 支払いサービス

考えられるユースケース：

• カタログを検索する

• 書籍を貸し出す

• 本の返却

• 延滞料金の計算

• 延滞料金の支払い

• 目録の管理

• 延滞通知の送信

関係:

• 本の貸出には、会員確認が含まれます。

• 本の貸出には、本の可用性確認が含まれます。

• 本の返却には、延滞料金の計算が含まれます。

• 延滞料金の支払いは、支払いサービスと連携します。

• 延滞通知の送信は、通知サービスと連携します。

8. PlantUMLの例

以下のPlantUMLコードは、図書館システムのユースケース図を作成します:

@startuml
left to right direction

title 図書館管理システム - ユースケース図

actor Member
actor Librarian
actor "Notification Service" as Notification
actor "Payment Service" as Payment

rectangle "Library Management System" {

  usecase "Search Catalog" as UC_Search
  usecase "Borrow Book" as UC_Borrow
  usecase "Return Book" as UC_Return
  usecase "Check Membership" as UC_CheckMember
  usecase "Check Book Availability" as UC_CheckAvailability
  usecase "Calculate Fine" as UC_CalculateFine
  usecase "Pay Fine" as UC_PayFine
  usecase "Manage Catalog" as UC_ManageCatalog
  usecase "Send Overdue Notification" as UC_Notify
}

Member --> UC_Search
Member --> UC_Borrow
Member --> UC_Return
Member --> UC_PayFine

Librarian --> UC_ManageCatalog
Librarian --> UC_Borrow
Librarian --> UC_Return

Payment --> UC_PayFine
Notification --> UC_Notify

UC_Borrow ..> UC_CheckMember : <<include>>
UC_Borrow ..> UC_CheckAvailability : <<include>>
UC_Return ..> UC_CalculateFine : <<include>>

UC_Notify ..> UC_Return : <<extend>>

@enduml

9. 例の説明

アクター

actor Member
actor Librarian
actor "Notification Service" as Notification
actor "Payment Service" as Payment

この図は、2人の人間アクターと2つの外部サービスモデル化しています。

次のようなエイリアス:as Notificationは、後で長い名前を参照しやすくします。

システム境界

rectangle "ライブラリ管理システム" {
    ...
}

この長方形はシステムの範囲を定義します。長方形内のユースケースはライブラリシステムによって提供されます。

アクターの関連付け

Member --> UC_Search
Member --> UC_Borrow

これらの関連付けは、会員がカタログを検索し、本を借りられることを示しています。

矢印の方向は、基本的なユースケース図では通常、意味論的に重要ではありません。主に図を読みやすくするために使用されます。

包含関係

UC_Borrow ..> UC_CheckMember : <<include>>
UC_Borrow ..> UC_CheckAvailability : <<include>>

本の貸出には常に会員確認と在庫確認が必要であるため、これらは包含ユースケースとしてモデル化されています。

拡張関係

UC_Notify ..> UC_Return : <<extend>>

これは、延滞通知の動作が本の返却に関連する追加の動作であることを示しています。

ただし、実際の要件モデルでは、より自然な設計として、「延滞通知の送信」をスケジュールプロセスや「ライブラリスケジューラ」などのアクターに関連付けることが考えられます。最適な関係は実際のビジネスルールに依存します。

10. より詳細なユースケース仕様

図は概要を示しますが、各重要なユースケースには通常、テキストによる仕様が必要です。

ユースケース：本の貸出

ユースケース図は、すべての詳細を含めようとすべきではありません。図は地図を提供し、仕様書は振る舞いを提供します。

11. PlantUML 構文リファレンス

アクターの宣言

actor Customer
actor "Payment Gateway" as Gateway

ユースケースの宣言

usecase "Place Order" as PlaceOrder
usecase "Process Payment" as ProcessPayment

システム境界の作成

rectangle "オンラインストア" {
    usecase "商品閲覧" as Browse
    usecase "注文" as Order
}

アクターとユースケースの接続

Customer --> Browse
Customer --> Order

Include

Order ..> ProcessPayment : <<include>>

Extend

ApplyCoupon ..> Order : <<extend>>

アクターの一般化

PremiumCustomer --|> Customer

パッケージのグループ化

パッケージは関連するユースケースを視覚的にグループ化できます:

rectangle "銀行システム" {
  package "口座管理" {
    usecase "口座開設" as OpenAccount
    usecase "口座解約" as CloseAccount
  }

  package "支払い" {
    usecase "資金送金" as TransferFunds
    usecase "請求書支払い" as PayBill
  }
}

ノート

note right of PlaceOrder
  注文を行う前に顧客は認証されている必要があります。
end note

12. ダイアグラムのレイアウト改善

PlantUMLはダイアグラムを自動的にレイアウトしますが、いくつかの技術で可読性を向上させることができます。

方向の制御

左から右への方向

これは、アクターを左右に、ユースケースを中央に表示したい場合に特に役立ちます。

他の一般的な方向には以下が含まれます:

上から下への方向

エイリアスを使用

長い名前を繰り返す代わりに:

usecase "顧客IDの検証" as VerifyIdentity

その後、参照します:

RegisterAccount ..> VerifyIdentity : <<include>>

関連するユースケースをグループ化する

パッケージまたはネストされた矩形を使用して機能領域を分離する:

package "注文管理" {
    usecase "注文作成" as CreateOrder
    usecase "注文キャンセル" as CancelOrder
}

過度な交差を避ける

線が多すぎると図が読みづらくなります。以下のように改善できます:

• 関連するアクターをユースケースの近くに配置する

• ユースケースをパッケージにグループ化する

• 1つの大きな図を複数の小さな図に分割する

• 明確な参照のためにエイリアスを使用する

• 不要な関係性を避ける

13. 一般的な間違い

内部機能をユースケースとしてモデル化する

これは通常、技術的になりすぎます:

データベース接続を検証する
リクエストをシリアライズする
支払いAPIを呼び出す

外部から意味のある目標を優先する:

支払いを行う
申請を提出する
レポートを生成する

すべてのアクターを人間として扱う

外部システムやデバイスもアクターになり得ます:

• 支払いゲートウェイ

• IDプロバイダー

• 倉庫システム

• バーコードスキャナー

• 通知サービス

使用includeオプションの動作に使用

動作がオプションの場合は、拡張ではなく包含.

誤り:

注文を行う ..> クーポンを適用する : <<include>>

クーポンの適用が任意の場合は、次を使用してください:

クーポンを適用する ..> 注文を行う : <<extend>>

使用拡張を必須の動作に用いる

ある動作が常に発生する場合は、通常は次でモデル化する必要があります:包含.

注文を行う ..> 顧客を認証する : <<include>>

意味なくユースケースを直接接続する

2 つのユースケース間の線は、有効な UML 関係を表す必要があります。単にユースケースが何らかの形で関連していることを示唆するだけの任意の接続は避けてください。

1 つの巨大な図を作成する

ユースケース図は、高レベルで明確に伝達すべきです。数十人のアクターとユースケースが含まれる場合は、サブシステムまたはビジネス領域ごとに整理された複数の図を作成してください。

シーケンスの表示

ユースケース図は、あるユースケースが別のユースケースの前に発生することを示すものではありません。シーケンスについては、シーケンス図またはアクティビティ図を使用してください。

14. 他の UML 図をいつ使用するか

ユースケース図は、システムの範囲とユーザーの目標に最も適しています。より詳細な情報が必要な場合は、他の図と組み合わせてください:

15. 推奨されるモデリングプロセス

1. システムの境界を定義する。

2. すべての外部アクターを特定する。

3. 各アクターの目標を特定する。

4. それらの目標をユースケースに変換する。

5. アクターを、彼らが関与するユースケースに接続する。

6. 必須の再利用可能な振る舞いを特定し、それを「<<include>>.

7. オプションまたは条件付きの振る舞いを特定し、それを「<<extend>>.

8. 真の「is-a」関係がある場合にのみ一般化を追加する。

9. ステークホルダーと図を検証する。

10. 重要なユースケースにテキスト仕様を追加する。

11. 図が混雑した場合は分割する。

16. コンパクトなPlantUMLテンプレート

これを出発点として使用できます：

@startuml
left to right direction

title システムユースケース図

actor ユーザー
actor "外部システム" as ExternalSystem

rectangle "システム名" {
  usecase "主要なユーザー目標" as MainGoal
  usecase "必要な共有振る舞い" as RequiredBehavior
  usecase "オプションの振る舞い" as OptionalBehavior
}

User --> MainGoal
ExternalSystem --> MainGoal

MainGoal ..> RequiredBehavior : <<include>>
OptionalBehavior ..> MainGoal : <<extend>>

@enduml

中心となる原則は、外部から見える目標をモデル化することです内部の実装詳細ではなく、強力なユースケース図は、システム境界、アクター、機能、および重要な依存関係を即座に理解可能にします。

参照