Nghiên cứu trường hợp: Sơ đồ trường hợp cho một nền tảng giao đồ ăn

Mô hình hóa các yêu cầu thực tế bằng UML – Một hướng dẫn thực tiễn

---

1. Giới thiệu

Trong phát triển phần mềm hiện đại, sơ đồ trường hợp là một công cụ nền tảng để thu thập các yêu cầu chức năng từ góc nhìn người dùng. Nghiên cứu trường hợp này trình bày phân tích chi tiết về một sơ đồ trường hợp thực tế cho một nền tảng giao đồ ăn, sử dụng cú pháp PlantUML như ngôn ngữ mô hình hóa. Mục tiêu là minh họa không chỉ điều gì các thành phần nào được sử dụng trong sơ đồ, mà còn tại sao chúng được chọn — làm nổi bật các quyết định mô hình hóa thực tiễn, thủ tục, và những sai lầm phổ biến.

Nghiên cứu trường hợp này phục vụ cả người mới học UML và người thực hành đang tinh chỉnh các phương pháp mô hình hóa của họ. Nó phân tích từng thành phần trong sơ đồ, giải thích mục đích của từng thành phần và thảo luận về các hệ quả trong thực tế.

---

2. Tổng quan hệ thống

Các nền tảng giao đồ ăn là một nền tảng thương mại số kết nối:

• Khách hàng (các cá nhân đặt đồ ăn),

• Nhà hàng (nhà cung cấp bữa ăn),

• Tài xế (nhân viên giao hàng),

• Các cổng thanh toán bên ngoài (hệ thống bên thứ ba xử lý giao dịch).

Nền tảng cho phép người dùng duyệt nhà hàng, đặt hàng, theo dõi giao hàng, quản lý thanh toán và áp dụng các chương trình khuyến mãi. Hệ thống tích hợp với các dịch vụ bên ngoài như bộ xử lý thanh toán và không xử lý logic thanh toán nội bộ.

Mã PlantUML:

@startuml
skinparam monochrome true
skinparam shadowing false

hướng từ trái sang phải

‘ Tất cả các nhân vật được định nghĩa bên ngoài hình chữ nhật
actor Khách hàng
actor “Khách hàng đã đăng ký” as RegCustomer
actor “Nhân viên nhà hàng” as Restaurant
actor Tài xế
actor “Bộ xử lý thanh toán” as PaymentGW

hình chữ nhật “Nền tảng giao đồ ăn” {

(Duyệt nhà hàng)
(Đặt hàng)
(Theo dõi đơn hàng)
(Quản lý thực đơn)
(Chấp nhận / Chuẩn bị đơn hàng)
(Giao hàng)
(Xử lý thanh toán)
(Hoàn tiền)
(Ap dụng Mã khuyến mãi)
(Sử dụng Ví)
(Payment thẻ)
(Payment ví kỹ thuật số)

‘ Liên kết – mũi tên vượt qua ranh giới
Khách hàng –> (Duyệt nhà hàng)
Khách hàng đã đăng ký –> (Đặt hàng)
Khách hàng đã đăng ký –> (Theo dõi đơn hàng)

Nhà hàng –> (Quản lý thực đơn)
Nhà hàng –> (Chấp nhận / Chuẩn bị đơn hàng)

Tài xế –> (Giao hàng)

Cổng thanh toán bên ngoài –> (Xử lý thanh toán)
Cổng thanh toán bên ngoài –> (Hoàn tiền)

‘ bao gồm
(Đặt hàng) ..> (Xử lý thanh toán) : <<bao gồm>>

‘ mở rộng
(Đặt hàng) <.. (Áp dụng Mã khuyến mãi) : <<mở rộng>>
(Xử lý thanh toán) <.. (Sử dụng Ví) : <<mở rộng>>

‘ tổng quát hóa
(Xử lý thanh toán) <|– (Thanh toán bằng thẻ)
(Xử lý thanh toán) <|– (Thanh toán bằng ví kỹ thuật số)
}

‘ Tổng quát hóa Người tham gia (cũng ở bên ngoài)
Khách hàng <|– Khách hàng đã đăng ký

ghi chú bên phải của Cổng thanh toán bên ngoài
Cổng thanh toán bên ngoài
(Stripe, PayPal, Adyen, …)
Kết thúc ghi chú

ghi chú phía dưới (Áp dụng Mã khuyến mãi)
Tùy chọn – chỉ khi nhập mã hợp lệ
ghi chú cuối

@enduml

✅ Nhận thức cốt lõi: Sơ đồ tập trung vào tương tác bên ngoài — nó thể hiện hệ thống làm cho người dùng và hệ thống của nó, chứ không phải cách nó được triển khai.

---

3. Các yếu tố sơ đồ: Phân tích sâu với ý nghĩa thực tiễn

Dưới đây là phân tích toàn diện về từng yếu tố UML được sử dụng trong sơ đồ, cùng với cách diễn giải trong thực tế và lý do lập mô hình.

#	Yếu tố	Ký hiệu	Ý nghĩa và mục đích	Quyết định lập mô hình / Nhận xét
1	Biên giới hệ thống	hình chữ nhật "Nền tảng giao đồ ăn"	Xác định phạm vi của hệ thống đang được mô hình hóa. Tất cả các trường hợp sử dụng bên trong đều thuộc về hệ thống này.	Tên gọi ngắn gọn nhưng mang tính mô tả. Trong các bối cảnh doanh nghiệp, có thể sử dụng tên dài hơn (ví dụ: “Hệ thống quản lý đơn hàng khách hàng”).
2	Người dùng chính	actor Khách hàng, actor Tài xế	Đại diện cho vai trò bên ngoài mà khởi tạo hoặc tham gia vào các trường hợp sử dụng.	Tên là đơn giản và trực quan. Tránh các kiểu mẫu không cần thiết như <<người>> trừ khi cần thiết cho các mô hình lớn.
3	Người tác nhân với biệt danh	người tác nhân "Nhân viên Nhà hàng" như Nhà hàng	Cho phép tên tác nhân dài và mô tả được rút gọn để tăng tính rõ ràng trong các kết nối.	Rất hiệu quả khi tên tác nhân chứa khoảng trắng hoặc quá dài. Giảm sự lộn xộn và cải thiện tính dễ đọc.
4	Tác nhân Hệ thống bên ngoài	người tác nhân "Trình xử lý Thanh toán" như PaymentGW	Mô hình các hệ thống bên thứ ba nền tảng tương tác với.	Không có kiểu mẫu «hệ thống» được sử dụng — chấp nhận được trong các sơ đồ nhẹ. Tuy nhiên, việc thêm «hệ thống» có thể làm rõ mục đích trong các hệ thống phức tạp.
5	Tổng quát hóa Tác nhân	`Khách hàng <	— KhachHangDangKy`	Chỉ ra rằng một khách hàng đã đăng ký là phiên bản chuyên biệt của một khách hàng khách.
6	Quan hệ thông thường	Khách hàng --> (Duyệt nhà hàng)	Hiển thị rằng người dùng khởi tạo hoặc tham gia vào thuật toán sử dụng.	Đường liền = giao tiếp. Hướng được ngụ ý từ người dùng đến thuật toán sử dụng (không cần đầu mũi tên).
7	Mối quan hệ «include»	(Đặt hàng) ..> (Xử lý thanh toán) : <<include>>	Xử lý thanh toán là luôn luôn cần thiết khi đặt hàng.	Mũi tên chỉ từ bao gồm → được bao gồm. Điều này rất quan trọng: Đặt hàng bao gồm Xử lý thanh toán như một bước bắt buộc.
8	Mối quan hệ «extend»	(Đặt hàng) <.. (Áp dụng mã khuyến mãi) : <<extend>>	Việc áp dụng mã khuyến mãi là tùy chọn và chỉ xảy ra trong một số điều kiện nhất định.	Mũi tên chỉ từ mở rộng → cơ bản. Trường hợp sử dụng cơ bản (Đặt hàng) có thể được mở rộng có điều kiện.
9	Tổng quát hóa trường hợp sử dụng	`(Xử lý thanh toán) <	— (Thanh toán bằng thẻ)<br>(Xử lý thanh toán) <	— (Thanh toán bằng ví điện tử)`
10	Ghi chú	ghi chú bên phải của PaymentGW ghi chú phía dưới của (Áp dụng mã khuyến mãi)	Cung cấp giải thích ngữ cảnh về triển khai hoặc quy tắc kinh doanh.	Các ghi chú thường bị bỏ qua nhưng rất có giá trị. Chúng ngăn ngừa hiểu nhầm (ví dụ: làm rõ rằng PaymentGW là bên ngoài).
11	Các tác nhân bên ngoài ranh giới	Tất cả tác nhân khẳng định đứng trước hình chữ nhật	Nhấn mạnh rằng không có tác nhân nào thuộc về hệ thống — sự tách biệt rõ ràng về trách nhiệm.	Một trong hai bố cục tiêu chuẩn. Được ưu tiên khi có nhiều người tham gia hoặc bên ngoài.
12	Hướng biểu đồ	hướng từ trái sang phải	Cải thiện bố cục khi có nhiều người tham gia ở bên trái.	Tăng tính dễ đọc. Đặc biệt hiệu quả với 4–8 người tham gia. Phương án thay thế: bố cục từ trên xuống dưới cho ít người tham gia hơn.

---

4. Các quyết định mô hình hóa chính và lý do

✅ Tại sao người tham gia nằm ngoài ranh giới hệ thống

• Thực hành tốt nhất: Người tham gia đại diện cho các vai tròbên ngoàihệ thống.

• Tại sao điều này quan trọng: Ngăn ngừa sự nhầm lẫn giữa các thành phần hệ thống và các thực thể bên ngoài.

• Ví dụ: Tài xếkhông phải là một module của nền tảng — họ là một vai trò bên thứ ba tương tác với nó.

📌 Mẹo hay: Nếu tất cả người tham gia đều nằm trong ranh giới, điều đó sẽ ngụ ý rằng hệ thống bao gồm họ — điều này dễ gây nhầm lẫn.

---

✅ Tại sao lại sử dụngKhách hàng <|-- Khách hàng đã đăng kýthay vì sao chép các liên kết

• Không có khái quát hóa, bạn sẽ phải vẽ:

  Khách hàng --> (Duyệt nhà hàng)
  Khách hàng đã đăng ký --> (Duyệt nhà hàng)
  Khách hàng đã đăng ký --> (Đặt hàng)
  

• Với khái quát hóa, bạn chỉ cần:

  Khách hàng <|-- Khách hàng đã đăng ký
  Khách hàng --> (Duyệt nhà hàng)
  Khách hàng đã đăng ký --> (Đặt hàng)
  

• Kết quả: Sơ đồ sạch sẽ, dễ bảo trì hơn.

📌 Thực hành tốt nhất: Sử dụng tổng quát hóa tác nhân whenever một tác nhân chuyên biệt kế thừa tất cả các hành vi của một tác nhân tổng quát hơn.

---

✅ Tại sao <<bao gồm>> và <<mở rộng>> được sử dụng đúng cách

Mối quan hệ	Mục đích	Hướng	Ví dụ
<<bao gồm>>	Luồng con bắt buộc	Từ bao gồm → được bao gồm	Đặt hàng phải bao gồm Xử lý thanh toán
<<mở rộng>>	Mở rộng tùy chọn	Từ mở rộng → cơ sở	Áp dụng mã khuyến mãi mở rộng Đặt hàngchỉ khi mã hợp lệ

❗ Sai lầm phổ biến: Đảo ngược hướng mũi tên. Luôn nhớ:

• bao gồm: Cơ sở ..> Bao gồm

• mở rộng: Mở rộng <.. Cơ sở

---

✅ Tại sao Xử lý thanh toáncó các khái quát hóa

• Thanh toán bằng thẻvàThanh toán bằng ví điện tửlàcác dạng chuyên biệtcủaXử lý thanh toán.

• Điều này cho thấy nền tảng hỗ trợnhiều phương thức thanh toán, nhưng tất cả đều tuân theo cùng một luồng chính.

• Khái quát hóa cho phéphành vi chung và khả năng mở rộng trong tương lai.

📌 Trường hợp sử dụng: Việc thêm một phương thức thanh toán mới (ví dụ: Apple Pay) chỉ đơn thuần là một sự khái quát hóa khác của Xử lý Thanh toán.

---

5. Các giải thích thực tế & câu hỏi được trả lời

Sơ đồ này không chỉ là công cụ hỗ trợ trực quan — nó trả lời các câu hỏi quan trọng về kinh doanh và kỹ thuật:

Câu hỏi	Câu trả lời từ sơ đồ
Những người dùng chính là ai?	Khách hàng, Khách hàng đã đăng ký, Nhân viên nhà hàng, Tài xế, Cổng thanh toán
Người dùng chưa đăng ký có thể đặt hàng không?	❌ Không — chỉ có Khách hàng đã đăng ký có thể Đặt hàng. Khách hàng chỉ có thể Duyệt nhà hàng.
Thanh toán có luôn cần thiết không?	✅ Có — Đặt hàng bao gồm Xử lý Thanh toán. Bắt buộc.
Khách hàng có thể áp dụng mã khuyến mãi không?	✅ Có — nhưng chỉ khi tùy chọn thông qua <<mở rộng>>. Chỉ khi nhập mã hợp lệ.
Các phương thức thanh toán nào được hỗ trợ?	Thẻ và Ví số (thông qua tổng quát hóa). Hệ thống bên ngoài xử lý quá trình thực tế.
Ai xử lý thanh toán?	Bên ngoài PaymentGW — không thuộc về nền tảng.
Nhà hàng có thể quản lý thực đơn của mình không?	✅ Có — Nhà hàng tác nhân tương tác với Quản lý thực đơn và Chấp nhận / Chuẩn bị đơn hàng.

✅ Giá trị kinh doanh: Sơ đồ truyền đạt rõ ràng hệ thống làm gì, ai sử dụng nó, và hành vi nào là bắt buộc so với tùy chọn.

---

6. Các nguyên tắc mô hình hóa phổ biến được minh họa

Sơ đồ minh họa một sốthực hành tốt nhấttrong mô hình hóa use case UML:

Nguyên tắc	Cách áp dụng
Sử dụng tên use case hướng đến mục tiêu	Đặt hàng, Theo dõi đơn hàng, Áp dụng mã khuyến mãi— tất cả đều bắt đầu bằng động từ và mô tả mục tiêu của người dùng.
Giữ sơ đồ dễ đọc	Chỉ có10 use caseđược hiển thị — lý tưởng cho hầu hết các lĩnh vực kinh doanh (nên chọn từ 5–12).
Các hệ thống bên ngoài như người tham gia	PaymentGWđược mô hình hóa như một người tham gia, chứ không phải một use case. Phân biệt đúng vai trò.
Sử dụng ghi chú để làm rõ sự mơ hồ	Ghi chú giải thích rằngPaymentGWlà bên ngoài và mã khuyến mãi là tùy chọn — điều này rất quan trọng để tránh hiểu nhầm.
Sử dụng tổng quát hóa người tham gia để giảm sự rối mắt	`Khách hàng <
Sử dụngincludevàextend đúng cách	Sự phân biệt rõ ràng giữa hành vi bắt buộc và hành vi tùy chọn.

📌 Cảnh báo: Nhiều sơ đồ sử dụng sai <<extend>> để chỉ “tùy chọn” mà không hiểu rõ bản chất điều kiện của các phần mở rộng. Sơ đồ này tránh được lỗi đó.

---

7. Những cải tiến tiềm năng và đánh giá

Mặc dù sơ đồ này mạnh mẽ, dưới đây là những đề xuất mang tính xây dựng để hoàn thiện:

🔧 1. Thêm các kiểu dáng để rõ ràng hơn

actor "Payment Processor" as PaymentGW <<system>>

• Tại sao: Làm rõ rằng đây là một hệ thống bên ngoài, chứ không phải một vai trò con người.

• Lợi ích: Giảm sự mơ hồ, đặc biệt trong các mô hình lớn.

🔧 2. Làm rõ Áp dụng Mã Khuyến mãi Điều kiện mở rộng

Hiện tại:

note bottom of (Apply Promo Code)
  Tùy chọn – chỉ khi nhập mã hợp lệ
end note

• Tốt hơn: Sử dụng một ký hiệu điều kiện hoặc bảo vệtrong<<mở rộng>>mũi tên:

(Đặt hàng) <.. (Áp dụng mã khuyến mãi) : <<mở rộng>> [mã khuyến mãi hợp lệ]

• Tại sao: Chính xác hơn một ghi chú — liên kết trực tiếp phần mở rộng với một điều kiện.

🔧 3. Xem xét thêm mộtXem lịch sử đơn hàngTrường hợp sử dụng

• Hiện đang thiếu, nhưng có lẽ rất quan trọng đối với cả khách hàng và nhà hàng.

• Có thể được thêm vào như mộtKhách hàng đăng kýtrường hợp sử dụng.

🔧 4. Nhóm các trường hợp sử dụng liên quan (tùy chọn)

Đối với các sơ đồ lớn hơn, hãy nhóm các trường hợp sử dụng vàogói:

gói "Quản lý đơn hàng" {
    (Đặt hàng)
    (Theo dõi đơn hàng)
    (Áp dụng mã khuyến mãi)
}
gói "Thanh toán" {
    (Xử lý thanh toán)
    (Sử dụng ví)
    (Thanh toán bằng thẻ)
    (Thanh toán bằng ví điện tử)
}

• Lợi ích: Cải thiện khả năng mở rộng và tính dễ đọc.

---

8. Bước tiếp theo là gì?

Nghiên cứu trường hợp này đã cho thấy cách mộtsơ đồ trường hợp sử dụng được thiết kế tốtcó thể ghi lại logic kinh doanh phức tạp một cách rõ ràng và súc tích. Để hiểu sâu hơn, dưới đây làcác bước tiếp theo được đề xuất:

🔄 Tùy chọn 1: Góc nhìn tập trung vào nhà hàng

Mô hình hóa cùng một miền từ phía góc nhìn của nhà hàng:

• Tập trung vào Quản lý thực đơn, Chấp nhận / Chuẩn bị đơn hàng, Xem đơn hàng, Cập nhật trạng thái.

• Hiển thị Nhà hàng là tác nhân chính.

• Bao gồm Khách hàng là tác nhân phụ (ví dụ: Khách hàng gửi đơn hàng → Nhà hàng nhận được nó).

✅ Lợi ích: Làm nổi bật các mục tiêu hệ thống và vai trò của các tác nhân khác nhau.

🔄 Tùy chọn 2: Thêm các điểm mở rộng thêm

Nâng cao Đặt hàng với:

• Áp dụng mã giảm giá (nếu mã khuyến mãi không hợp lệ → <<mở rộng>> với thông báo lỗi)

• Yêu cầu hướng dẫn đặc biệt (tùy chọn)

• Lên lịch đặt hàng (để giao hàng trong tương lai)

🔄 Tùy chọn 3: So sánh bao gồm so với mở rộng với ví dụ

Trường hợp sử dụng	<<bao gồm>>	<<mở rộng>>
Đặt hàng → Xử lý thanh toán	✅ Bắt buộc	❌ Không phải tùy chọn
Đặt hàng → Áp dụng mã khuyến mãi	❌ Không bắt buộc	✅ Có điều kiện
Đăng nhập → Xác minh danh tính	✅ Luôn cần thiết	❌ Không áp dụng
Thanh toán → Áp dụng giảm giá	✅ Luôn luôn	✅ Chỉ khi có giảm giá

📌 Quy tắc thông thường:

• Sử dụng <<bao gồm>> khi hành vi phải xảy ra.

• Sử dụng <<mở rộng>> khi hành vi có thể xảy ra dưới một số điều kiện nhất định.

🔄 Tùy chọn 4: Chuyển đổi thành sơ đồ tuần tự hoặc sơ đồ hoạt động

Để phân tích sâu hơn:

• Sơ đồ tuần tự: Hiển thị luồng của Đặt hàng → Xử lý thanh toán → Giao đơn hàng với các tin nhắn giữa các tác nhân và hệ thống.

• Sơ đồ hoạt động: Mô hình hóa các điểm ra quyết định trong Xử lý thanh toán (ví dụ: thẻ bị từ chối → thử lại hoặc chuyển sang ví điện tử).

---

9. Kết luận

Nghiên cứu trường hợp này cho thấy rằng một sơ đồ use case được xây dựng cẩn thận không chỉ là một bản phác họa trực quan — nó là một công cụ giao tiếp chiến lược nghĩa là:

• Làm rõ phạm vi hệ thống,

• Ghi lại các quy tắc kinh doanh,

• Hướng dẫn phát triển,

• Ngăn ngừa hiểu lầm.

Sơ đồ Nền tảng giao đồ ăn là một ví dụ điển hình của:

• Sử dụng đúng ký hiệu UML,

• Các quyết định mô hình hóa hợp lý,

• Sự phân tách rõ ràng về vấn đề,

• Sử dụng hiệu quả các ghi chú và khái quát hóa.

Bằng cách tuân theo các nguyên tắc được nêu ở đây — đặt tên theo mục tiêu, sử dụng đúng include/mở rộng, tổng quát hóa tác nhân, và sử dụng ghi chú một cách chiến lược — bạn có thể tạo sơ đồ use case vừa chính xácvà có thể thực hiện được.

---

✅ Những điểm chính cuối cùng

Nguyên tắc	Áp dụng ở đây?	Tại sao điều này quan trọng
Sử dụng tên sơ đồ use case hướng đến mục tiêu	✅ Có	Cải thiện độ rõ ràng và tập trung vào người dùng
Giữ kích thước sơ đồ ở mức kiểm soát được	✅ Có (10 sơ đồ use case)	Ngăn ngừa quá tải nhận thức
Các hệ thống bên ngoài như tác nhân	✅ Có	Sự tách biệt đúng đắn về vấn đề
Sử dụng ghi chú để cung cấp ngữ cảnh	✅ Có	Ngăn ngừa hiểu nhầm
Sử dụng tổng quát hóa để giảm sự trùng lặp	✅ Có	Làm cho sơ đồ có thể mở rộng và dễ bảo trì
Đúng<<bao gồm>> và <<mở rộng>> hướng	✅ Có	Đảm bảo mô hình hóa hành vi chính xác

---