事例研究：飲食配達プラットフォーム用のユースケース図

UMLを用いた現実世界の要件のモデリング ― 実践ガイド

---

1. 序論

現代のソフトウェア開発において、ユースケース図は、ユーザーの視点から機能要件を捉えるための基盤となるツールである。本事例研究では、現実的なユースケース図を、飲食配達プラットフォームに対して、PlantUML構文をモデリング言語として用いて詳細な分析を提示する。目的は、図に使用される要素が何かを示すだけでなく、何が使用されている要素について説明するだけでなく、なぜそれらが選ばれる理由を明らかにすること――実践的なモデリングの意思決定, 規則、および一般的な落とし穴.

本事例研究は、UMLを学び始めた初心者とモデリングの実践を磨きたい実務者両者に役立つ。図のすべての要素を分解し、その目的を説明し、現実世界における影響について議論する。

---

2. システム概要

その飲食配達プラットフォームはデジタルマーケットプレイスで、以下のものを接続しています：

• 顧客（食事を注文する個人）,

• レストラン（食事の提供者）,

• ドライバー（配達担当者）,

• 外部決済ゲートウェイ（取引を処理する第三者システム）.

このプラットフォームはユーザーがレストランを閲覧し、注文を出し、配達状況を追跡し、支払いを管理し、プロモーションを適用できるようにします。システムは決済プロセッサなどの外部サービスと連携しており、支払いのロジックを内部で処理しません。

PlantUMLコード：

@startuml
skinparam monochrome true
skinparam shadowing false

左から右への方向

‘ すべてのアクターは矩形の外に定義されています
actor 顧客
actor 「登録済み顧客」を RegCustomer として
actor 「レストランスタッフ」を Restaurant として
actor ドライバー
actor 「決済プロセッサ」を PaymentGW として

rectangle 「フードデリバリー・プラットフォーム」 {

（レストランを閲覧）
（注文を出す）
（注文を追跡）
（メニューを管理）
（注文を承認／準備）
（注文を配達）
（支払いを処理）
（返金を発行）
（プロモコードを適用）
（ウォレットを使用）
（カード決済）
（デジタルウォレット決済）

‘ 関連 – 矢印が境界を越える
カスタマー –> （レストランを閲覧）
登録済みカスタマー –> （注文を確定）
登録済みカスタマー –> （注文を追跡）

レストラン –> （メニューを管理）
レストラン –> （注文を承認／準備）

ドライバー –> （注文を配達）

決済ゲートウェイ –> （決済処理）
決済ゲートウェイ –> （返金処理）

‘ include
（注文を確定） ..> （決済処理） : <<include>>

‘ extend
（注文を確定） <.. （プロモコードを適用） : <<extend>>
（決済処理） <.. （ウォレットを使用） : <<extend>>

‘ generalization
（決済処理） <|– （カード決済）
（決済処理） <|– （デジタルウォレット決済）
}

‘ キャラクターの一般化（外部も含む）
カスタマー <|– 登録済みカスタマー

note right of 決済ゲートウェイ
外部決済ゲートウェイ
（Stripe、PayPal、Adyen、…）
end note

note bottom of （プロモコードを適用）
オプション – 有効なコードが入力された場合にのみ
終了ノート

@enduml

✅ 重要な洞察: 図は～に注目しています外部の相互作用— それはシステムが～することを示しています行うユーザーおよびシステムに対して行う内容を示しており、実装方法については示していません。

---

3. 図の要素：実用的な意味を持つ詳細な解説

以下に、図で使用された各UML要素の包括的な分解を示し、現実世界での解釈およびモデル化の根拠を併記します。

#	要素	表記法	意味と目的	モデル化の判断／コメント
1	システム境界	長方形「フードデリバリー・プラットフォーム」	～を定義します範囲モデル化対象のシステムの範囲を定義します。図内のすべてのユースケースはこのシステムの一部です。	名前は簡潔でありながら記述的です。企業環境では、「カスタマーオーダー管理システム」など、より長い名前を使用する場合があります。
2	主要な人間アクター	アクター カスタマー, アクター ドライバー	～を表します外部の役割使用ケースを開始または参加するもの。	名前は単純で直感的です。不要なステレオタイプを避けます。<<人物>>大規模なモデルが必要な場合を除き。
3	別名付きのアクター	アクター "レストランスタッフ" を Restaurant として	長い説明的なアクター名を接続の明確化のために短縮できる。	アクター名にスペースが含まれる場合や冗長な場合に特に効果的。ごちゃごちゃを減らし、可読性を向上させる。
4	外部システムアクター	アクター "決済プロセッサ" を PaymentGW として	モデルサードパーティシステムプラットフォームがやり取りするもの。	ステレオタイプなし«システム»が使用される — 軽量な図では許容される。ただし、追加することで«システム»複雑なシステムにおいて意図を明確にすることができる。
5	アクターの一般化	`顧客 <	— 登録顧客`	これは、登録顧客が、ゲスト顧客.
6	通常の関連	顧客 --> (レストランを閲覧する)	アクターが開始するまたは参加するユースケースに参加する。	実線 = 通信。方向性はアクターからユースケースへと示される（矢印の先端は不要）。
7	«include» 関係	(注文を確定) ..> (支払い処理) : <<include>>	支払い処理は常に必要注文を行う際には常に必要。	矢印の先端は包含する側 → 包含される側。これは重要です：注文を確定 は 支払い処理必須の手順として含む。
8	«extend» 関係	(注文を確定) <.. (プロモコードを適用) : <<extend>>	プロモコードを適用することはオプションであり、特定の条件下でのみ行われる。	矢印の先端は拡張側 → 基本。基本のユースケース（注文を出す）は拡張可能である条件付きで.
9	ユースケースの一般化	`（支払い処理）<	— （カード決済）<br>（支払い処理）<	— （デジタルウォレット決済）`
10	注記	PaymentGWの右側に注記 （プロモコード適用）の下に注記	提供する文脈的な説明実装やビジネスルールに関するもの。	注記はあまり使われていないが、非常に価値がある。誤解を防ぐ（例：PaymentGWが外部であることを明確にする）。
11	境界外のアクター	すべてのアクター宣言は矩形の前にある	強調しているのはどのアクターもシステムの一部ではない— 明確な関心事の分離。	2つの標準レイアウトの一つ。アクターが多数または外部にある場合に推奨される。
12	図の方向	左から右への方向	複数のアクターが左側にある場合、レイアウトが改善される。	可読性が向上する。4～8人のアクターに対して特に効果的。代替案：アクターが少ない場合は上から下へのレイアウトを使用する。

---

4. 主要なモデル化の意思決定とその根拠

✅ なぜアクターがシステム境界の外にあるのか

• ベストプラクティス：アクターは役割を表す外側システムの

• なぜ重要なのか：システムの構成要素と外部エンティティとの混同を防ぐ。

• 例: ドライバーはプラットフォームのモジュールではない。彼らはそのプラットフォームとやり取りする第三者の役割である。

📌 プロのヒント：すべてのアクターが境界内にあるとすると、システムがそれらを含んでいると誤解される。これは誤解を招く。

---

✅ なぜ を使用するのかCustomer <|-- RegCustomerリンクを重複させることなく

• 一般化を行わなければ、次のように描かなければならない。

  Customer --> (レストランを閲覧する)
  RegCustomer --> (レストランを閲覧する)
  RegCustomer --> (注文する)
  

• 一般化を行うと、次のようにすれば十分である。

  Customer <|-- RegCustomer
  Customer --> (レストランを閲覧する)
  RegCustomer --> (注文する)
  

• 結果: クリーンで、より保守しやすい図。

📌 ベストプラクティス: 特殊なアクターがより一般的なアクターのすべての振る舞いを継承する場合、常にアクターの一般化を使用する。

---

✅ なぜ<<include>>および<<extend>>が正しく使用されている

関係	目的	方向	例
<<include>>	必須のサブフロー	から含む → 含まれる	注文を出す 必須を含む支払いを処理する
<<extend>>	オプションの拡張	から拡張 → ベース	プロモコードを適用 拡張する 注文を確定コードが有効な場合のみ

❗ よくあるミス：矢印の方向を逆にしている。常に思い出そう：

• 含む: ベース ..> 含まれる

• 拡張する: 拡張 <.. ベース

---

✅ なぜなら支払い処理は一般化を持つ

• カード決済およびデジタルウォレット決済は特殊化された形態の支払い処理.

• これにより、プラットフォームがサポートしていることがわかる複数の支払い方法しかし、すべて同じコアフローに従う。

• 一般化により、共有される振る舞い　および　将来の拡張性.

📌 ユースケース：新しい決済方法（例：Apple Pay）を追加することは、単に別の一般化にすぎません支払い処理.

---

5. 実世界における解釈と質問への回答

この図は単なる視覚的補助にとどまらず、重要なビジネスおよび技術的質問に答えています：

質問	図からの回答
主なユーザーは誰ですか？	顧客、登録済み顧客、レストランスタッフ、ドライバー、決済ゲートウェイ
登録されていないユーザーは注文できますか？	❌いいえ — ただしこのユーザーのみが可能登録顧客　が　注文を提出. 顧客　はただしこれだけが可能レストランを閲覧.
支払いは常に必要ですか？	✅ はい — 注文を提出 を含む 支払い処理。必須。
顧客はプロモコードを適用できますか？	✅ はい — ただし、僅かにオプションで経由で<<拡張>>。有効なコードが入力された場合にのみ。
どのような支払い方法がサポートされていますか？	カードおよびデジタルウォレット（一般化経由）。実際の処理は外部システムが担当します。
支払いは誰が担当しますか？	外部PaymentGW — プラットフォームの一部ではありません。
レストランはメニューを管理できますか？	✅ はい —レストランアクターは以下とやり取りしますメニュー管理および注文受付／準備.

✅ ビジネス価値：図は明確に伝えるシステムが何を行うか, 誰がそれを使用するか、および必須とオプションの行動とは何か.

---

6. 共通のモデリングガイドラインの実例

この図はいくつかのベストプラクティスUMLユースケースモデリングにおける

ガイドライン	適用方法
目的指向のユースケース名を使用する	注文を提出する, 注文を追跡する, プロモコードを適用する— すべて動詞で始まり、ユーザーの目的を記述している。
図の可読性を保つ	たった10個のユースケースが表示されている — 多くのビジネス分野にとって理想的（推奨範囲：5～12）。
外部システムをアクターとして扱う	PaymentGWはアクターとしてモデル化されているが、ユースケースではない。関心の適切な分離がなされている。
注釈を使用して曖昧さを明確にする	注釈はPaymentGWが外部であり、プロモコードはオプションであることを説明している — 間違った解釈を防ぐために重要である。
アクターの一般化を使用してごちゃごちゃを減らす	`顧客 <
使用するincludeおよびextend正しく	必須とオプションの動作の明確な区別。

📌 警告：多くの図では誤って使用されている<<extend>>「オプション」という意味に誤って使用しており、拡張の条件的な性質を理解していない条件的な性質拡張の性質。この図はその誤りを回避している。

---

7. 潜在的な改善点と批判

図は強力ですが、以下の建設的な提案を refining するために

🔧 1. 明確化のためのスタereotypeを追加

アクター "Payment Processor" を PaymentGW <<system>> として

• なぜ：これは外部システムであり、人間の役割ではないことを明確にしている。

• 利点：曖昧さを軽減する。特に大規模なモデルにおいて。

🔧 2. 明確化するプロモコードの適用拡張条件

現在：

ノート (プロモコードの適用) の下部
  オプション – 有効なコードが入力された場合のみ
end note

• より良い方法：使用する条件記法またはガード の <<拡張>> 矢印:

(注文を確定) <.. (プロモコードを適用) : <<拡張>> [有効なプロモコード]

• なぜ：ノートよりも正確です。拡張を条件に直接結びつけています。

🔧 3. 次の追加を検討する 注文履歴を表示 ユースケース

• 現在欠落していますが、顧客とレストランの両方にとって重要である可能性があります。

• 次のように追加できる RegCustomer ユースケース。

🔧 4. 関連するユースケースをグループ化する（オプション）

大きな図の場合、ユースケースを パッケージ:

パッケージ "注文管理" {
    (注文を確定)
    (注文を追跡)
    (プロモコードを適用)
}
パッケージ "支払い" {
    (支払い処理)
    (ウォレットを使用)
    (カード決済)
    (デジタルウォレット決済)
}

• 利点：スケーラビリティと可読性を向上させます。

---

8. 次に何をすべきか？

この事例研究は、 構造が整ったユースケース図 が複雑なビジネスロジックを明確かつ簡潔に捉えることができるということを示しています。理解を深めるために、以下の 推奨される次のステップ:

🔄 オプション1：レストラン中心のビュー

同じドメインを レストランの視点からモデル化する:

• 注目する メニューマネジメント, 注文の受領／準備, 注文の確認, 状態の更新.

• 表示 レストラン を主要なアクターとする。

• 含める 顧客 を補助的なアクターとする（例： 顧客 が注文を送信 → レストラン が受領する）。

✅ 利点：異なるシステムの目的とアクターの役割を明らかにする。

🔄 オプション2：より多くの拡張ポイントを追加する

強化する 注文を出す　による：

• クーポンを適用　（プロモコードが無効の場合→<<拡張>>　エラーメッセージ付き）

• 特別な指示をリクエスト　（任意）

• 注文のスケジュール　（将来の配送用）

🔄 オプション3：比較する　含む　対　拡張　例を含む

使用例	<<含む>>	<<拡張>>
注文を確定 → 支払い処理	✅ 必須	❌ 必須ではない
注文を確定 → プロモコードを適用	❌ 必須ではない	✅ 条件付き
ログイン → 身元の確認	✅ 必ず必要	❌ 適用されない
チェックアウト → 割引を適用	✅ 常に	✅ 割引が存在する場合のみ

📌 目安:

• 使用する <<含む>> 動作が発生するとき 発生しなければならない.

• 使用する <<拡張>> 動作が発生するとき 発生する可能性がある 特定の条件下で。

🔄 オプション4：シーケンス図またはアクティビティ図に変換

より深い分析のため：

• シーケンス図：流れを表示する 注文を出す → 支払いを処理 → 注文の配信アクターとシステム間のメッセージを含む。

• アクティビティ図：決定ポイントをモデル化する支払いの処理（例：カード拒否 → 再試行またはウォレットに切り替え）。

---

9. 結論

この事例研究は、よく作られたユースケース図は単なる視覚的スケッチ以上のものである——それは戦略的コミュニケーションツールであり、以下の通りである：

• システムの範囲を明確化する、

• ビジネスルールを把握する、

• 開発をガイドする、

• 誤解を防ぐ。

そのフードデリバリー・プラットフォーム図は強力な例である：

• UML表記の適切な使用、

• 妥当なモデル化の意思決定、

• 明確な関心事の分離、

• ノートおよび一般化の効果的な使用。

ここに示された原則に従うことで——目的指向の命名, 適切な使用include/拡張する, アクターの一般化、およびノートの戦略的使用— あなたは以下の両方の特徴を持つユースケース図を作成できます正確なおよび実行可能な.

---

✅ 最終的な教訓

原則	ここに適用されていますか？	なぜ重要なのか
目的指向のユースケース名を使用する	✅ はい	明確性とユーザーの注目を高める
図のサイズを管理可能に保つ	✅ はい（10つのユースケース）	認知的負荷を防ぐ
外部システムをアクターとして使用する	✅ はい	関心の適切な分離
文脈を示すためにノートを使用する	✅ はい	誤解を防ぐ
冗長性を減らすために一般化を使用する	✅ はい	図をスケーラブルで維持可能にする
正しい<<include>> と <<extend>> 方向	✅ はい	正確な行動モデル化を保証する

---