Mô tả trường hợp sử dụng giải thích cách một tác nhân đạt được mục tiêu thông qua tương tác với hệ thống. Nó bổ sung cho sơ đồ trường hợp sử dụng:

• Sơ đồ trường hợp sử dụng:Hiển thị các tác nhân, phạm vi hệ thống và các mối quan hệ.

• Mô tả trường hợp sử dụng:Giải thích hành vi chi tiết, điều kiện, quy tắc và kết quả.

Sơ đồ cung cấp bản đồ; mô tả cung cấp lộ trình.

1. Trường hợp sử dụng là gì?

Một trường hợp sử dụng đại diện cho một mục tiêu có giá trị mà một tác nhân bên ngoài đạt được thông qua hệ thống.

Ví dụ:

• Khách hàng đặt hàng

• Nhân viên nộp yêu cầu thanh toán chi phí

• Bệnh nhân đặt lịch hẹn

• Quản trị viên tạo tài khoản người dùng

• Khách hàng đặt lại mật khẩu

Một trường hợp sử dụng tốt là:

• Hướng đến mục tiêu

• Có giá trị đối với một tác nhân

• Được mô tả từ góc độ của người dùng

• Độc lập với bố cục màn hình cụ thể

• Tập trung vào hành vi có thể quan sát được của hệ thống

Tên trường hợp sử dụng kém và đã được cải thiện

Sử dụng một cụm từ ngắn gồm động từ–danh từ, chẳng hạn như “Gửi yêu cầu thanh toán chi phí, Theo dõi vận chuyển, hoặc Phê duyệt đơn xin vay.

2. Các khái niệm chính

2.1 Vai trò

Một vai trò là một vai trò bên ngoài tương tác với hệ thống.

Một vai trò có thể là:

• Một người

• Một tổ chức

• Một hệ thống phần mềm khác

• Một thiết bị phần cứng

• Một kích hoạt theo lịch trình hoặc dựa trên thời gian

Ví dụ:

• Khách hàng

• Nhân viên hỗ trợ

• Nhân viên kho

• Cổng thanh toán

• Dịch vụ Email

• Quản trị viên

Một vai trò là một vai trò, không nhất thiết là một cá nhân cụ thể. Ví dụ, “Khách hàng” thường tốt hơn “Jane Smith.”

Vai trò chính và vai trò hỗ trợ

Vai trò chính khởi tạo kịch bản sử dụng để đạt được mục tiêu.

Vai trò hỗ trợ hỗ trợ hệ thống trong quá trình thực thi.

Ví dụ:

• Vai trò chính: Khách hàng

• Vai trò hỗ trợ: Cổng thanh toán

• Kịch bản sử dụng: Đặt hàng

Khách hàng khởi tạo đơn hàng, trong khi cổng thanh toán xác thực thanh toán.

2.2 Ranh giới hệ thống

Ranh giới hệ thống xác định những gì nằm bên trong hệ thống đang được mô hình hóa.

Đối với một cửa hàng trực tuyến, ranh giới có thể bao gồm:

• Duyệt sản phẩm

• Thêm sản phẩm vào giỏ hàng

• Đặt hàng

• Thực hiện thanh toán

• Theo dõi đơn hàng

Những nội dung sau nằm ngoài ranh giới:

• Khách hàng

• Cổng thanh toán

• Công ty vận chuyển

• Nhà cung cấp email

Biên giới này ngăn ngừa sự nhầm lẫn về trách nhiệm của hệ thống.

2.3 Trường hợp sử dụng

Một trường hợp sử dụng nên mô tả một tương tác hoàn chỉnh tạo ra kết quả có ý nghĩa.

Ví dụ:

Đặt hàng:Một khách hàng chọn sản phẩm, cung cấp thông tin giao hàng, thanh toán cho đơn hàng và nhận xác nhận đơn hàng.

“Xác thực số thẻ tín dụng” có thể là một chức năng của hệ thống, nhưng thường quá nhỏ để trở thành mục tiêu người dùng độc lập. Nó có thể thay vào đó là một phần của Đặt hàng hoặc Thanh toán.

2.4 Điều kiện tiên quyết

Một điều kiện tiên quyết nêu rõ những gì phải đã đúng trước khi trường hợp sử dụng bắt đầu.

Ví dụ:

• Khách hàng có tài khoản đang hoạt động.

• Sản phẩm có sẵn để bán.

• Nhân viên đã được xác thực.

• Khung giờ hẹn tồn tại.

• Giỏ hàng chứa ít nhất một sản phẩm.

Một điều kiện tiên quyết không phải là một hành động được thực hiện bởi trường hợp sử dụng.

Điều kiện tiên quyết kém:

Khách hàng đăng nhập.

Điều kiện tiên quyết tốt hơn:

Khách hàng đã được xác thực.

2.5 Điều kiện hậu quả

Một điều kiện hậu quả nêu rõ những gì là đúng sau khi trường hợp sử dụng kết thúc.

Ví dụ:

• Đơn hàng đã được ghi nhận.

• Thanh toán đã được ủy quyền.

• Một email xác nhận đã được gửi.

• Yêu cầu chi phí có trạng thái đã nộp.

• Tài khoản người dùng được đánh dấu là đang hoạt động.

Hậu điều kiện nên mô tả kết quả, không phải chi tiết triển khai.

Hậu điều kiện kém:

Bảng đơn hàng được cập nhật.

Hậu điều kiện tốt hơn:

Đơn hàng được lưu trữ và sẵn sàng để thực hiện.

2.6 Kịch bản thành công chính

Kịch bản thành công chính, còn được gọi là luồng cơ bản hoặc đường thành công, mô tả tương tác thành công bình thường.

Mỗi bước nên mô tả:

1. Một tương tác giữa tác nhân và hệ thống

2. Một phản hồi của hệ thống

3. Một hành động kinh doanh có ý nghĩa

Ví dụ:

1. Khách hàng chọn sản phẩm.

2. Hệ thống hiển thị giỏ hàng hiện tại.

3. Khách hàng nhập thông tin giao hàng.

4. Hệ thống xác thực thông tin giao hàng.

5. Khách hàng nộp đơn hàng.

6. Hệ thống yêu cầu xác thực thanh toán.

7. Cổng thanh toán xác thực khoản thanh toán.

8. Hệ thống ghi nhận đơn hàng.

9. Hệ thống hiển thị xác nhận đơn hàng.

Tránh các chi tiết cụ thể cho giao diện trừ khi chúng thiết yếu đối với yêu cầu.

Bước kém:

Khách hàng nhấp vào nút màu xanh ở góc dưới bên phải.

Bước tốt hơn:

Khách hàng gửi đơn hàng.

2.7 Luồng thay thế

Một luồng thay thế mô tả một biến thể hợp lệ của kịch bản chính.

Ví dụ:

• Khách hàng chọn nhận hàng tại cửa hàng thay vì giao hàng.

• Khách hàng thanh toán bằng phương thức thanh toán đã lưu.

• Quản trị viên phê duyệt một yêu cầu với các điều kiện.

• Người dùng xác thực bằng mã dùng một lần.

Các luồng thay thế có thể quay lại luồng chính.

Ví dụ:

A1. Khách hàng sử dụng phương thức thanh toán đã lưu
Tại Bước 6, khách hàng chọn một phương thức thanh toán đã lưu. Hệ thống yêu cầu xác thực bằng phương thức đó, sau đó tiếp tục tại Bước 7.

2.8 Luồng ngoại lệ

Một luồng ngoại lệ mô tả một điều kiện không thành công hoặc bất thường.

Ví dụ:

• Thanh toán bị từ chối.

• Sản phẩm hết hàng.

• Xác thực thất bại.

• Dịch vụ bên ngoài không khả dụng.

• Dữ liệu bắt buộc không hợp lệ.

Một luồng ngoại lệ nên giải thích:

• Vị trí xảy ra vấn đề

• Hệ thống làm gì

• Người thực hiện thấy gì

• Trường hợp sử dụng kết thúc hay tiếp tục

Ví dụ:

E1. Thanh toán bị từ chối
Tại Bước 7, Cổng thanh toán từ chối giao dịch. Hệ thống hiển thị lý do, đánh dấu đơn hàng là chưa thanh toán và cho phép khách hàng chọn phương thức thanh toán khác.

2.9 Mối quan hệ Include và Extend

include

Sử dụng includekhi một kịch bản sử dụng luôn gọi một hành vi có thể tái sử dụng khác.

Ví dụ:

• Đặt hàng include Tính tổng

• Đặt hàng include Xác thực khách hàng

• Rút tiền include Xác minh mã PIN

Hành vi được include là bắt buộc.

Đặt hàng <<include>> Tính tổng

extend

Sử dụng extendkhi một hành vi tùy chọn hoặc có điều kiện bổ sung cho một kịch bản sử dụng cơ sở.

Ví dụ:

• Đặt hàng có thể được extend bởi Áp dụng mã giảm giá

• Thanh toán có thể được extend bởi Thêm lời chúc quà

Hành vi extend không phải lúc nào cũng được thực thi.

Áp dụng mã giảm giá <<extend>> Đặt hàng

Một quy tắc hữu ích:

• Include: “Điều này luôn xảy ra như một phần của kịch bản sử dụng.”

• Extend: “Điều này có thể xảy ra trong một số điều kiện nhất định.”

Không sử dụng include và mở rộngchỉ để chia nhỏ mọi luồng thành các phần nhỏ. Việc phân rã quá mức khiến mô hình trở nên khó hiểu.

2.10 Tổng quát hóa

Tổng quát hóa biểu thị sự thừa kế giữa các vai trò hoặc các trường hợp sử dụng.

Ví dụ:

• Nhân viên là một vai trò tổng quát.

• Quản lý là một vai trò chuyên biệt thừa kế hành vi của Nhân viên.

Manager --|> Employee

Sử dụng tổng quát hóa khi phần tử chuyên biệt thực sự là một loại của phần tử tổng quát, chứ không chỉ vì hai phần tử chia sẻ một vài bước.

3. Mẫu mô tả trường hợp sử dụng tiêu chuẩn

Mẫu sau đây hoạt động tốt cho các tài liệu yêu cầu, đặc tả dự án và các mô hình phân tích.

ID Trường hợp sử dụng:
Tên Trường hợp sử dụng:
Mục tiêu:
Phạm vi:
Mức độ:
Vai trò chính:
Vai trò hỗ trợ:
Các bên liên quan và lợi ích:

Kích hoạt:

Điều kiện tiên quyết:

Đảm bảo tối thiểu:

Đảm bảo thành công:

Kịch bản thành công chính:
1.
2.
3.

Luồng thay thế:
A1.
A2.

Luồng ngoại lệ:
E1.
E2.

Yêu cầu đặc biệt:
- Hiệu suất
- Bảo mật
- Khả năng sử dụng
- Khả năng sẵn sàng
- Tuân thủ

Quy tắc kinh doanh:

Yêu cầu dữ liệu:

Tần suất và khối lượng:

Giả định:

Câu hỏi mở:

Các trường hợp sử dụng liên quan:

Giải thích các trường

4. Ví dụ: Đặt hàng

UC-001 — Đặt hàng

Mục tiêu:
Cho phép khách hàng mua một hoặc nhiều sản phẩm.

Phạm vi:
Cửa hàng trực tuyến

Cấp độ:
Mục tiêu của người dùng

Diễn viên chính:
Khách hàng

Các diễn viên hỗ trợ:

• Cổng thanh toán

• Dịch vụ quản lý tồn kho

• Dịch vụ email

• Dịch vụ giao hàng

Các bên liên quan và lợi ích:

• Khách hàng:Muốn mua sản phẩm thành công và nhận được xác nhận.

• Cửa hàng:Muốn ghi nhận đơn hàng hợp lệ và thu tiền.

• Kho:Cần thông tin thực hiện đơn hàng chính xác.

• Cổng thanh toán:Cần một yêu cầu thanh toán hợp lệ.

• Dịch vụ giao hàng:Cần một địa chỉ giao hàng đầy đủ.

Kích hoạt:
Khách hàng gửi giỏ hàng để thanh toán.

Điều kiện tiên quyết:

• Khách hàng có ít nhất một sản phẩm trong giỏ hàng.

• Sản phẩm có sẵn để đặt hàng.

• Khách hàng cung cấp địa chỉ giao hàng hợp lệ.

• Hệ thống có thể giao tiếp với dịch vụ thanh toán.

Đảm bảo tối thiểu:

• Không có đơn hàng nào chưa thanh toán được coi là đã xác nhận.

• Khách hàng sẽ được thông báo nếu đơn hàng không thể hoàn tất.

• Hàng tồn kho đã được đặt trước sẽ được giải phóng nếu thanh toán thất bại.

Đảm bảo thành công:

• Thanh toán đã được phê duyệt.

• Đơn hàng đã được ghi nhận.

• Hàng tồn kho đã được đặt chỗ.

• Khách hàng nhận được xác nhận.

• Thông tin thực hiện đơn hàng được cung cấp cho kho hàng.

Kịch bản thành công chính

1. Khách hàng xem lại giỏ hàng.

2. Hệ thống hiển thị sản phẩm, số lượng, giá, thuế, phí vận chuyển và tổng tiền.

3. Khách hàng cung cấp thông tin giao hàng.

4. Hệ thống xác thực thông tin giao hàng.

5. Khách hàng chọn phương thức thanh toán.

6. Khách hàng gửi đơn hàng.

7. Hệ thống kiểm tra tình trạng sẵn có của sản phẩm.

8. Hệ thống yêu cầu phê duyệt thanh toán từ Cổng thanh toán.

9. Cổng thanh toán phê duyệt khoản thanh toán.

10. Hệ thống tạo đơn hàng.

11. Hệ thống đặt chỗ các sản phẩm đã đặt.

12. Hệ thống gửi xác nhận đơn hàng đến khách hàng.

13. Hệ thống hiển thị số đơn hàng và ngày giao hàng dự kiến.

Luồng thay thế

A1. Khách hàng sử dụng địa chỉ đã lưu

Tại Bước 3, khách hàng chọn một địa chỉ đã lưu trước đó. Hệ thống hiển thị địa chỉ và tiếp tục tại Bước 4.

A2. Khách hàng sử dụng phương thức thanh toán đã lưu

Tại Bước 5, khách hàng chọn một phương thức thanh toán đã lưu. Hệ thống sử dụng phương thức đó và tiếp tục tại Bước 6.

A3. Khách hàng chọn nhận hàng tại cửa hàng

Tại Bước 3, khách hàng chọn nhận hàng tại cửa hàng thay vì giao hàng. Hệ thống hiển thị các cửa hàng có sẵn và ngày nhận hàng, sau đó tiếp tục tại Bước 5.

Luồng ngoại lệ

E1. Sản phẩm không có sẵn

Tại Bước 7, hệ thống xác định rằng một sản phẩm không có sẵn. Hệ thống xác định sản phẩm không có sẵn, cập nhật giỏ hàng và yêu cầu khách hàng xem lại đơn hàng.

E2. Thanh toán bị từ chối

Tại Bước 9, Cổng thanh toán từ chối giao dịch. Hệ thống không xác nhận đơn hàng, giải phóng các khoản đặt trước tồn kho, hiển thị thông báo lỗi và cho phép khách hàng chọn phương thức thanh toán khác.

E3. Cổng thanh toán không khả dụng

Tại Bước 8, Cổng thanh toán không phản hồi trong thời gian chờ đã cấu hình. Hệ thống đánh dấu nỗ lực thanh toán là đang chờ, thông báo cho khách hàng và ngăn chặn việc gửi đơn hàng trùng lặp.

Quy tắc kinh doanh

• Một đơn hàng phải chứa ít nhất một sản phẩm.

• Số lượng sản phẩm phải lớn hơn không.

• Không thể đặt hàng một sản phẩm khi số lượng tồn kho hiện có không đủ.

• Thanh toán phải được phê duyệt trước khi đơn hàng được xác nhận.

• Giá cả và thuế được tính toán dựa trên các quy tắc định giá hiện hành.

• Khách hàng chỉ có thể hủy đơn hàng trước khi quá trình thực hiện bắt đầu.

Yêu cầu đặc biệt

• Tóm tắt đơn hàng phải được hiển thị trong vòng hai giây dưới tải trọng bình thường.

• Thông tin thanh toán không được lưu trữ dưới dạng văn bản thuần.

• Việc gửi trùng lặp không được tạo ra các đơn hàng trùng lặp.

• Hệ thống phải ghi lại nhật ký kiểm toán cho các thay đổi về trạng thái thanh toán và đơn hàng.

5. Các mức độ sử dụng trường hợp

Mô tả trường hợp sử dụng có thể được viết ở các mức độ chi tiết khác nhau.

Trường hợp sử dụng ở mức tổng quan

Một trường hợp sử dụng ở mức tổng quan mô tả một quy trình kinh doanh rộng.

Ví dụ:

Thực hiện đơn hàng của khách hàng

Điều này có thể bao gồm:

• Tiếp nhận đơn hàng

• Chọn sản phẩm

• Đóng gói đơn hàng

• Giao hàng đơn hàng

Trường hợp sử dụng ở mức mục tiêu người dùng

Đây thường là mức độ hữu ích nhất cho việc phân tích yêu cầu.

Ví dụ:

Đặt hàng

Nó mô tả một mục tiêu mà một vai trò chính có thể đạt được trong một phiên làm việc.

Trường hợp sử dụng ở mức con chức năng

Điều này mô tả một hành vi hệ thống nhỏ hơn có thể tái sử dụng.

Ví dụ:

• Tính tổng đơn hàng

• Xác thực thanh toán

• Tạo hóa đơn

Các trường hợp sử dụng ở mức con chức năng hữu ích khi hành vi được tái sử dụng hoặc có độ phức tạp kỹ thuật, nhưng chúng không nên thay thế các trường hợp sử dụng dựa trên mục tiêu của người dùng.

6. Viết mô tả trường hợp sử dụng chất lượng cao

Sử dụng ngôn ngữ tập trung vào vai trò

Viết từ góc độ của vai trò:

Khách hàng gửi đơn hàng.

Tránh dùng từ ngữ tập trung vào cách triển khai:

OrderController gọi dịch vụ đơn hàng.

Câu sau thuộc về tài liệu thiết kế, không phải trong một trường hợp sử dụng kinh doanh.

Giữ mỗi bước ở mức nguyên tử

Tránh kết hợp quá nhiều hành động:

Khách hàng nhập chi tiết, chọn phương thức thanh toán, xác nhận đơn hàng và nhận email.

Cải thiện bằng cách tách rời các tương tác:

1. Khách hàng nhập thông tin giao hàng.

2. Hệ thống xác thực thông tin.

3. Khách hàng chọn phương thức thanh toán.

4. Khách hàng xác nhận đơn hàng.

5. Hệ thống gửi xác nhận.

Mô tả hành vi có thể quan sát được

Người đọc phải có thể xác định xem yêu cầu đã được triển khai hay chưa.

Yếu:

Hệ thống xử lý yêu cầu.

Mạnh hơn:

Hệ thống xác thực yêu cầu, ghi nhận khiếu nại, gán số cho khiếu nại đó và hiển thị trạng thái gửi.

Tránh thiết kế giao diện người dùng quá sớm

Sử dụng:

Khách hàng cung cấp thông tin giao hàng.

Thay vì:

Khách hàng nhập địa chỉ vào ô văn bản và nhấp vào nút Tiếp tục màu xanh lá cây.

Phiên bản thứ hai hạn chế giao diện một cách không cần thiết.

Giữ luồng chính thành công

Đừng làm đầy luồng cơ bản với mọi lỗi có thể xảy ra. Hãy đưa các lỗi vào các luồng ngoại lệ.

Xác định các quy tắc kinh doanh riêng biệt

Các quy tắc kinh doanh thường áp dụng cho nhiều trường hợp sử dụng. Việc giữ chúng riêng biệt ngăn ngừa việc lặp lại văn bản không nhất quán.

Làm rõ hành vi khi thất bại

Đối với mọi lỗi quan trọng, hãy chỉ định:

• Dữ liệu có được lưu hay không

• Giao dịch có được hoàn tác hay không

• Người thực hiện có thể thử lại hay không

• Quản trị viên có được thông báo hay không

• Trường hợp sử dụng kết thúc hay tiếp tục

7. Từ yêu cầu đến trường hợp sử dụng

Một quy trình làm việc thực tế là:

1. Xác định hệ thống đang được mô hình hóa.

2. Liệt kê các tác nhân bên ngoài.

3. Hỏi xem mỗi tác nhân muốn đạt được điều gì.

4. Chuyển đổi mỗi mục tiêu thành tên trường hợp sử dụng.

5. Xác định ranh giới hệ thống.

6. Viết kịch bản thành công chính.

7. Thêm các luồng thay thế và luồng ngoại lệ.

8. Thêm các quy tắc kinh doanh và yêu cầu đặc biệt.

9. Vẽ sơ đồ trường hợp sử dụng.

10. Xem xét mô hình cùng các bên liên quan.

11. Liên kết các trường hợp sử dụng với các yêu cầu, bài kiểm tra và các tài liệu thiết kế.

Phân tích mục tiêu của vai trò

Một câu hỏi hữu ích là:

Kết quả kinh doanh nào mà vai trò này cần từ hệ thống?

8. Ký hiệu biểu đồ trường hợp sử dụng

Các thành phần phổ biến nhất là:

• Vai trò:Vai trò bên ngoài

• Trường hợp sử dụng: Khả năng hệ thống hoặc mục tiêu của tác nhân

• Ranh giới hệ thống: Phạm vi của hệ thống

• Liên kết: Tác nhân tham gia vào một kịch bản sử dụng

• Bao gồm: Hành vi được yêu cầu và có thể tái sử dụng

• Mở rộng: Hành vi tùy chọn hoặc có điều kiện

• Tổng quát hóa: Tác nhân hoặc kịch bản sử dụng chuyên biệt

Một sơ đồ kịch bản sử dụng không nên cố gắng hiển thị:

• Mọi bước trong quy trình làm việc

• Các bảng cơ sở dữ liệu

• Các thuộc tính của lớp

• Các quy tắc kinh doanh chi tiết

• Bố cục màn hình

• Các thuật toán nội bộ

Những nội dung này thuộc về sơ đồ hoạt động, sơ đồ lớp, sơ đồ trình tự hoặc các yêu cầu được viết thành văn bản.

9. Ví dụ về sơ đồ PlantUML

Ví dụ sau đây mô hình hóa Đặt hàng kịch bản sử dụng và các hành vi liên quan.

@startuml
left to right direction

skinparam packageStyle rectangle
skinparam shadowing false
skinparam usecase {
    BackgroundColor #F8FBFF
    BorderColor #2F5597
    ArrowColor #555555
}

actor Customer
actor "Payment Gateway" as Payment
actor "Inventory Service" as Inventory
actor "Email Service" as Email
actor "Delivery Service" as Delivery

rectangle "Online Store" {
    usecase "Browse Products" as Browse
    usecase "Manage Cart" as Cart
    usecase "Place Order" as PlaceOrder
    usecase "Calculate Order Total" as CalculateTotal
    usecase "Check Product Availability" as CheckStock
    usecase "Authorize Payment" as AuthorizePayment
    usecase "Reserve Inventory" as ReserveInventory
    usecase "Send Order Confirmation" as SendConfirmation
    usecase "Track Order" as TrackOrder
    usecase "Apply Discount Code" as ApplyDiscount
}

Customer --> Browse
Customer --> Cart
Customer --> PlaceOrder
Customer --> TrackOrder

Payment --> AuthorizePayment
Inventory --> CheckStock
Inventory --> ReserveInventory
Email --> SendConfirmation
Delivery --> TrackOrder

PlaceOrder ..> CalculateTotal : <<include>>
PlaceOrder ..> CheckStock : <<include>>
PlaceOrder ..> AuthorizePayment : <<include>>
PlaceOrder ..> ReserveInventory : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

ApplyDiscount ..> PlaceOrder : <<extend>>

@enduml

Giải thích

• Người Khách hàng khởi tạo Đặt hàng.

• Đặt hàng luôn bao gồm tính toán, kiểm tra tồn kho, ủy quyền thanh toán, đặt chỗ hàng tồn kho và xác nhận.

• Áp dụng mã giảm giá là tùy chọn, do đó nó mở rộng Đặt hàng.

• Các dịch vụ bên ngoài tham gia vào các hành vi cụ thể của hệ thống.

• Biên giới hệ thống là Cửa hàng trực tuyến hình chữ nhật.

Vị trí chính xác của các yếu tố được điều khiển bởi công cụ hiển thị. Các quyết định mô hình hóa quan trọng là các vai trò, các trường hợp sử dụng, biên giới và các mối quan hệ.

10. Tạo biểu đồ trong Visual Paradigm VPasCode

VPasCode là một nền tảng chuyển đổi văn bản thành biểu đồ dựa trên trình duyệt, hỗ trợ PlantUML, Mermaid, Graphviz và các định dạng biểu đồ khác. Nó cung cấp chỉnh sửa mã nguồn và hiển thị trực tiếp, cho phép biểu đồ được cập nhật khi mã thay đổi.

Quy trình làm việc cơ bản

1. Mở trình soạn thảo VPasCode.

2. Tạo một biểu đồ PlantUML mới.

3. Dán mã nguồn PlantUML.

4. Xác nhận rằng trình soạn thảo nhận diện cú pháp PlantUML.

5. Xem lại bản xem trước trực tiếp.

6. Chỉnh sửa các vai trò, trường hợp sử dụng, mối quan hệ và kiểu dáng trong bảng mã nguồn.

7. Xuất hoặc sao chép biểu đồ đã được hiển thị.

8. Thêm biểu đồ vào tài liệu dự án.

VPasCode hỗ trợ biểu đồ trường hợp sử dụng PlantUML và cung cấp khả năng hiển thị thời gian thực trên trình duyệt. Nó cũng cung cấp các ví dụ và tùy chọn kiểu dáng cho biểu đồ PlantUML.

Ví dụ về câu lệnh để tạo hỗ trợ bởi AI

Nếu sử dụng tính năng tạo biểu đồ bằng AI, một câu lệnh hữu ích là:

Tạo biểu đồ trường hợp sử dụng PlantUML cho một cửa hàng trực tuyến.

Vai trò chính:
- Khách hàng

Các vai trò hỗ trợ:
- Cổng thanh toán
- Dịch vụ tồn kho
- Dịch vụ email
- Dịch vụ giao hàng

Các trường hợp sử dụng chính:
- Duyệt sản phẩm
- Quản lý giỏ hàng
- Đặt hàng
- Theo dõi đơn hàng

Đặt hàng phải bao gồm:
- Tính tổng đơn hàng
- Kiểm tra tình trạng sẵn có của sản phẩm
- Ủy quyền thanh toán
- Đặt chỗ tồn kho
- Gửi xác nhận đơn hàng

Áp dụng mã giảm giá nên mở rộng Đặt hàng.

Sử dụng biên giới hệ thống có tên Cửa hàng trực tuyến.

Xem mã được tạo làm điểm khởi đầu. Hãy xem xét liệu:

• Các vai trò thực sự là bên ngoài

• Các trường hợp sử dụng đại diện cho mục tiêu của người dùng

• bao gồm và mở rộng được sử dụng đúng cách

• Biên giới hệ thống là chính xác

• Các mối quan hệ phản ánh hành vi kinh doanh thực tế

VPasCode cũng hỗ trợ chuyển đổi giữa việc chỉnh sửa sơ đồ dựa trên văn bản và các công cụ mô hình hóa đồ họa của Visual Paradigm, điều này có thể hữu ích khi các nhóm muốn chỉnh sửa dựa trên mã nguồn để quản lý phiên bản và chỉnh sửa trực quan để tinh chỉnh bố cục.

11. Duy trì sơ đồ trường hợp sử dụng PlantUML

Sử dụng biệt danh có ý nghĩa

Biệt danh giúp việc duy trì các mối quan hệ dễ dàng hơn:

usecase "Đặt hàng" as PlaceOrder
Customer --> PlaceOrder

Thêm nhận xét

' Giao dịch cốt lõi của khách hàng
usecase "Đặt hàng" as PlaceOrder

Nhận xét giúp các thành viên khác trong nhóm hiểu rõ nguồn gốc và duy trì sơ đồ.

Giữ cho sơ đồ tập trung

Nếu một sơ đồ chứa quá nhiều trường hợp sử dụng:

• Tạo sơ đồ ngữ cảnh

• Tạo các sơ đồ riêng biệt theo lĩnh vực kinh doanh

• Sử dụng nhóm gói

• Liên kết các sơ đồ liên quan thông qua tài liệu

• Tránh hiển thị mọi chức năng con ở cấp cao nhất

Sử dụng đặt tên nhất quán

Chọn một quy ước và áp dụng nó một cách nhất quán:

• Đặt hàng

• Hủy đơn hàng

• Theo dõi đơn hàng

Tránh trộn lẫn các phong cách như:

• Đặt hàng

• OrderCancellation

• tracking_function

Lưu trữ mã nguồn cùng với dự án

Cấu trúc kho lưu trữ điển hình có thể là:

docs/
  use-cases/
    UC-001-place-order.md
    UC-002-track-order.md
  diagrams/
    online-store-use-cases.puml

Việc giữ lại .puml mã nguồn dưới kiểm soát phiên bản giúp các thay đổi có thể được xem xét và tái tạo.

12. Khả năng truy vết

Một quy trình yêu cầu trưởng thành kết nối các trường hợp sử dụng với các tài liệu dự án khác.

Khả năng truy vết giúp trả lời:

• Yêu cầu nào đã được đáp ứng?

• Trường hợp sử dụng nào chưa được kiểm thử?

• Thành phần thiết kế nào hỗ trợ mục tiêu kinh doanh?

• Điều gì bị ảnh hưởng nếu một yêu cầu thay đổi?

13. Những lỗi phổ biến

Mô hình hóa các thành phần nội bộ dưới dạng tác nhân

Cơ sở dữ liệu hoặc dịch vụ nội bộ thường không phải là tác nhân nếu chúng nằm bên trong ranh giới hệ thống.

Một tác nhân phải nằm bên ngoài hệ thống đang được mô hình hóa.

Xem màn hình như các trường hợp sử dụng

Màn hình là một thành phần giao diện người dùng, không nhất thiết là mục tiêu của người dùng.

Sử dụng:

Gửi yêu cầu thanh toán chi phí

Thay vì:

Màn hình yêu cầu thanh toán chi phí

Sử dụng include cho mỗi bước được chia sẻ

Việc sử dụng chung từ ngữ đơn thuần không đủ để biện minh cho một trường hợp sử dụng được bao gồm. Sử dụng include khi hành vi là bắt buộc và có ý nghĩa độc lập.

Sử dụng extend cho các bước bình thường

Nếu một hành vi luôn xảy ra, nó không nên được mô hình hóa như một phần mở rộng.

Viết các chi tiết triển khai

Tránh tham chiếu đến:

• Bộ điều khiển

• Bảng cơ sở dữ liệu

• Điểm cuối API

• Lớp

• Phương thức nội bộ

trừ khi tài liệu đó cụ thể là một thiết kế kỹ thuật.

Bỏ qua hành vi thất bại

Một kịch bản sử dụng sẽ không đầy đủ nếu chỉ giải thích thành công. Việc từ chối thanh toán, dữ liệu không hợp lệ, thời gian chờ quá hạn, lỗi xác thực và tài nguyên không khả dụng cần được xử lý.

Làm cho kịch bản sử dụng quá rộng

“Quản lý toàn bộ doanh nghiệp” không thể thực hiện được. Hãy chia các mục tiêu rộng thành các kịch bản sử dụng ở mức mục tiêu của người dùng.

Làm cho kịch bản sử dụng quá nhỏ

“Xác thực trường” và “Hiển thị thông báo” thường là các bước của hệ thống, không phải là mục tiêu độc lập của người thực hiện.

14. Danh sách kiểm tra rà soát

Trước khi phê duyệt mô tả kịch bản sử dụng, hãy xác minh:

Phạm vi và người thực hiện

• Biên giới hệ thống có rõ ràng không?

• Tất cả các người thực hiện bên ngoài đã được xác định chưa?

• Người thực hiện có phải là vai trò thay vì tên riêng không?

• Các hệ thống hỗ trợ có chỉ được mô hình hóa khi chúng là bên ngoài không?

Chất lượng mục tiêu

• Kịch bản sử dụng có mang lại giá trị cho người thực hiện chính không?

• Tên có phải là một cụm danh từ–động từ rõ ràng không?

• Kịch bản sử dụng có ở mức độ phù hợp không?

Chất lượng luồng

• Kịch bản chính có mô tả kết quả thành công không?

• Mỗi bước có nguyên tử và có thể quan sát được không?

• Các đường dẫn thay thế đã được ghi lại chưa?

• Các đường dẫn ngoại lệ đã được ghi lại chưa?

• Hành vi khôi phục có rõ ràng không?

Điều kiện và kết quả

• Các điều kiện tiên quyết có thể kiểm tra được không?

• Các đảm bảo thành công có được nêu rõ ràng không?

• Các đảm bảo tối thiểu đã được xác định chưa?

• Các quy tắc kinh doanh có được tách biệt khỏi các bước thủ tục không?

Chất lượng biểu đồ

• Tất cả các trường hợp sử dụng có nằm trong ranh giới chính xác không?

• Các mối liên kết giữa các vai trò có ý nghĩa không?

• Các mối liên kết “include” có bắt buộc không?include” có bắt buộc không?

• Các mối liên kết “extend” có tùy chọn hoặc có điều kiện không?extend” có tùy chọn hoặc có điều kiện không?

• Biểu đồ có dễ đọc mà không cần chi tiết quá mức không?

Chất lượng yêu cầu

• Mỗi bước quan trọng có thể được kiểm thử không?

• Các yêu cầu phi chức năng đã được bao gồm chưa?

• Các câu hỏi chưa được giải quyết đã được ghi nhận chưa?

• Trường hợp sử dụng có được liên kết với các yêu cầu và các trường hợp kiểm thử không?

15. Cấu trúc tài liệu giao hàng được khuyến nghị

Đối với gói dự án hoàn chỉnh, hãy sử dụng cấu trúc sau:

1. Ngữ cảnh hệ thống
2. Danh mục vai trò
3. Biểu đồ trường hợp sử dụng
4. Danh mục trường hợp sử dụng
5. Mô tả chi tiết trường hợp sử dụng
6. Quy tắc kinh doanh
7. Yêu cầu phi chức năng
8. Ma trận truy vết
9. Câu hỏi mở và giả định
10. Tập nguồn PlantUML

Một mô tả trường hợp sử dụng mạnh mẽ phải đủ chính xác cho các nhà phân tích, dễ hiểu đối với các bên liên quan và có thể kiểm thử bởi đội ngũ đảm bảo chất lượng. Quy trình làm việc tốt nhất là sử dụng mô tả văn bản để xác định hành vi, sử dụng biểu đồ trường hợp sử dụng để truyền đạt phạm vi và mối quan hệ, và sử dụng PlantUML trong VPasCode để giữ cho mô hình trực quan dễ chỉnh sửa và bảo trì.

Tài liệu tham khảo

This post is also available in Deutsch, English, Español, فارسی, Français, English, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.