ユースケース図とは何ですか？
A ユースケース図は、システムのユーザー（通称アクター）と、それらが達成したい特定の行動や目標（通称ユースケース）の関係を可視化するために使用される行動の設計図です。ステップバイステップの論理ループを示すのではなく、ユースケース図はシステムの機能的範囲の高レベルな概要を提供し、プロジェクト要件、システム境界、ステークホルダーのワークフローを定義するのに非常に優れたツールです。
With VPasCode、視覚的なキャンバスの整合性を気にせず、すばやく明確でプロフェッショナルなユースケース図を構築できます。このガイドは、曖昧で古くから使われている表記法をスキップし、日々のソフトウェアドキュメント作成に必要な実用的な構文要素にのみ焦点を当てています。
コア構文ガイド：要素と構造
PlantUMLでユースケース図を構築するには、標準の @startuml と @enduml タグで囲まれた、いくつかの簡単な構造的要素に依存します。
1. アクターの宣言
アクターは、アプリケーションとやり取りする外部エンティティを表します（たとえば、人間のユーザー、バックグラウンドサービス、または外部のハードウェアAPIなど）。アクターを宣言するには、actor キーワードの後に内部的なショートハンドIDを記述します：
actor customer
actor admin as "システム管理者"
プロのヒント： には as キーワードを使用して、複雑なアクターIDにクリーンで人間が読みやすい表示文字列を割り当てます。
2. ユースケースの定義
ユースケースは、機能的な目標やビジネスプロセスを表します。ユースケースは2つの方法で定義できます：テキストを括弧内に囲んで (あなたのユースケース) とする方法、または明示的に ユースケース複雑な書式設定のキーワード：
(ダッシュボードにログインする)
ユースケース checkout を "クレジットカード決済の処理" として定義
3. 基本的な相互作用のマッピング
アクターを対応するユースケースに接続するには、基本的な方向性のあるまたは方向性のない関係線を使用してください。また、相互作用に重要な文脈を追加するために、テキストラベルを付加することもできます：
customer --> (ダッシュボードにログインする)
admin --> checkout : "返金を承認"
4. 高度な関係：包含と拡張
複雑なシステム動作をモデル化する際には、標準的なUMLステレオタイプを使用して、異なるユースケース間の依存関係を示すことが頻繁に必要になります：
- 包含（必須の依存関係）：基本となるユースケースが、その実行を成功させるために別の補助ユースケースに依存していることを示します。点線の接続線（
..>）にテキストラベルを付加して使用します：
- 拡張（オプション／条件付き動作）：特定の条件下で、オプションのワークフローが基本となるユースケースから分岐することを示します。矢印の方向は、*拡張*ユースケースから*基本*ユースケースへ向かうことに注意してください：
Plantuml Edit Plantuml in VPasCode
(プロモコードの適用) ..> (チェックアウト処理) : <<extend>>
5. システム境界の強制
ソフトウェアアプリケーション内で発生する内容と外部で発生する内容を明確に区別するために、”rectangle内部のユースケースを囲むためのキーワード。重要なのは、アクターはこのコンテナブロックの外に残しておくこと。これにより、外部参加者としての立場が明確になる。
actor customer
rectangle "E-Commerce Platform" {
(カタログを閲覧する)
(カートに追加する)
}
customer --> (カタログを閲覧する)
customer --> (カートに追加する)
クリーンなレイアウトのためのベストプラクティス
- テキストは簡潔に:ユースケースは常に明確な能動態の動詞から始めるべきである（例：「レポートを生成する」, 「プロフィールを更新する」）長文ではなく、というように。
- 方向性のアンカーを活用する:アクターとユースケースがごちゃごちゃと重なって混乱する場合、
-right->または-down->空間的な方向性の矢印を使って、レイアウトエンジンをクリーンで読みやすい構造にそっと誘導する。 - システム境界を明確に分離する:複数のサードパーティマイクロサービスとやり取りするアプリケーションを文書化する際は、常に境界矩形を使用する。これにより、どのプロセスが誰の所有であるかが一目でわかる。
実際のPlantUMLユースケース図の例
以下の実用的なブループリントを、そのままVPasCodeのライブエディタパネルにコピー＆ペーストして、動的にレンダリングされる様子を確認してください。
例1：コアユーザー認証およびアカウント管理
このブループリントは、主なユーザー、管理オペレーター、およびコアセキュリティメカニズムを含む境界ボックスを備えた標準的なアプリケーションエコシステムをモデル化している。
@startuml
' レイアウトの方向を左から右に設定
left to right direction
actor "エンドユーザー" as user
actor "セキュリティ管理者" as admin
rectangle "IDプロバイダーサービス" {
(ログインする)
(パスワードをリセットする)
(プロフィールデータを更新する)
(セキュリティログを確認する)
(アカウントを無効化する)
}
user --> (ログインする)
user --> (パスワードをリセットする)
user --> (プロフィールデータを更新する)
(セキュリティログを確認する) <-- admin
(アカウントを無効化する) <-- admin
@enduml
構文の分解: 指令 左から右への方向 レイアウトエンジンがアクターを外側の翼に配置し、使用ケースを垂直ではなく水平に拡大するように強制します。アクター宣言を明確に「」の外側に配置することで、整理された状態を保つことができます。長方形ラッパーはそれらを整理された状態に保ちつつ、管理者ユーザーの矢印の括弧の方向を逆転させます（<-- 管理者）はそれらを図の行列の右側に明確に固定します。
例2：外部依存関係を伴う高度な電子商取引チェックアウト
この現実世界のシステムレイアウトは、外部の銀行API、構造的包含、およびオプションの拡張フラグに依存する複雑なチェックアウトワークフローをマッピングしています。
@startuml
左から右への方向
actor "顧客" as customer
actor "倉庫スタッフ" as staff
actor "Stripeゲートウェイ" as stripe
rectangle "オンラインストア受注処理システム" {
(注文を確定する)
(クーポンを適用する)
(請求書を生成する)
(商品をピック・パックする)
(配送ステータスを更新する)
}
' システム境界への外部インタラクション
customer --> (注文を確定する)
(注文を確定する) --> stripe : "資金承認"
' 包含および拡張構造
(注文を確定する) ..> (請求書を生成する) : <<include>>
(クーポンを適用する) ..> (注文を確定する) : <<extend>>
' 処理パス
(商品をピック・パックする) <-- staff
(配送ステータスを更新する) <-- staff
(請求書を生成する) --> staff : "メールコピー送信"
@enduml
構文の分解： このテンプレートは、単一の使用ケース（注文を確定する）が（請求書を生成する）を呼び出すことを義務づけ、<<include>>というタグを点線で示しています。一方、クーポンコードの適用は、基本実行に後方に向かって指向する<<extend>>を介してオプションの分岐として正しくモデル化されています。すべての外部アクターはシステムの境界外に明確に分離された状態を保っています。