Now Reading: Hướng dẫn toàn diện về Chi tiết Hóa Trường Hợp Sử Dụng: Các Khái niệm chính, Phương pháp và Ví dụ

1
  • 01

    Hướng dẫn toàn diện về Chi tiết Hóa Trường Hợp Sử Dụng: Các Khái niệm chính, Phương pháp và Ví dụ

Read this post in: de_DEen_USes_ESfr_FRhi_INid_IDjapl_PLpt_PTru_RUzh_CNzh_TW

Hướng dẫn toàn diện về Chi tiết Hóa Trường Hợp Sử Dụng: Các Khái niệm chính, Phương pháp và Ví dụ

UML2 days ago

Giới thiệu

Chi tiết hóa trường hợp sử dụng là một giai đoạn quan trọng trong vòng đời phát triển phần mềm, đặc biệt trong bối cảnh kỹ thuật yêu cầu và phân tích, thiết kế hướng đối tượng. Nó lấp đầy khoảng cách giữa các trường hợp sử dụng cấp cao và các đặc tả hệ thống chi tiết, giúp các nhà phát triển, nhà phân tích và các bên liên quan hiểu đượccách thứchệ thống phản ứng như thế nào trước các mục tiêu cụ thể của người dùng.

Hướng dẫn này cung cấp cái nhìn toàn diện vềchi tiết hóa trường hợp sử dụng, bao gồm mục đích, các khái niệm chính, phương pháp từng bước, các thực hành tốt nhất và các ví dụ thực tế.

1. Chi tiết hóa trường hợp sử dụng là gì?

Chi tiết hóa trường hợp sử dụng là quá trình tinh chỉnh một trường hợp sử dụng cấp cao thành một mô tả chi tiết, có thể hành động về hành vi của hệ thống. Nó chuyển đổi một bản kể đơn giản về tương tác người dùng thành một đặc tả chính xác, có thể kiểm thử và triển khai.

✅ Mục tiêu: Để xác địnhđiều gìhệ thống cần làm gì,cách thứccách thức nó cần làm điều đó, vàtrong điều kiện nào, ở mức độ chi tiết đủ để phát triển và kiểm thử.

2. Tại sao chi tiết hóa trường hợp sử dụng lại quan trọng

  • Giảm sự mơ hồ: Ngăn ngừa việc hiểu sai các yêu cầu.

  • Cải thiện khả năng truy xuất: Kết nối các yêu cầu với thiết kế, mã nguồn và các trường hợp kiểm thử.

  • Hỗ trợ thiết kế và triển khai: Cung cấp nền tảng cho các sơ đồ lớp, sơ đồ tuần tự và thiết kế cơ sở dữ liệu.

  • Cho phép kiểm thử: Hỗ trợ việc tạo ra các kịch bản kiểm thử và tiêu chí chấp nhận.

  • Nâng cao sự hợp tác: Đảm bảo sự hiểu biết chung giữa các bên liên quan, nhà phát triển và người kiểm thử.

3. Các khái niệm chính trong việc chi tiết hóa trường hợp sử dụng

3.1 Trường hợp sử dụng (UC)

Một trường hợp sử dụng mô tả một chuỗi các hành động mà một hệ thống thực hiện để tạo ra một kết quả có giá trị cho một tác nhân (người dùng hoặc hệ thống bên ngoài).

Ví dụ: “Rút tiền” từ một máy ATM.

3.2 Tác nhân

Một thực thể bên ngoài tương tác với hệ thống. Có thể là người dùng, một hệ thống khác hoặc một sự kiện thời gian.

Ví dụ: Khách hàng, máy ATM, cổng thanh toán.

3.3 Tác nhân chính và tác nhân phụ

  • Tác nhân chính: Khởi tạo trường hợp sử dụng.

  • Tác nhân phụ: Hỗ trợ tác nhân chính (ví dụ: máy chủ ngân hàng).

3.4 Điều kiện tiền đề

Các điều kiện phải đúng trước khi trường hợp sử dụng có thể bắt đầu.

Ví dụ: Người dùng phải có thẻ hợp lệ và mã PIN đúng.

3.5 Điều kiện hậu đề

Các điều kiện phải đúng sau khi trường hợp sử dụng hoàn tất.

Ví dụ: Tiền được phát ra, số dư tài khoản được cập nhật.

3.6 Tình huống thành công chính (Luồng cơ bản)

Đường đi phổ biến nhất trong trường hợp sử dụng dẫn đến thành công.

Ví dụ: Chèn thẻ → Nhập mã PIN → Chọn rút tiền → Nhập số tiền → Nhận tiền.

3.7 Luồng thay thế (Luồng ngoại lệ)

Các nhánh trong trường hợp sử dụng nhằm xử lý ngoại lệ, lỗi hoặc các biến thể.

Ví dụ: Mã PIN không hợp lệ → Thử lại hoặc hủy.

3.8 Mở rộng

Các điểm trong luồng chính nơi có thể chèn hành vi thay thế (ví dụ: thông qua “<>” trong UML).

Ví dụ: “<>: Thông báo cho ngân hàng về hoạt động đáng ngờ.”

3.9 Yêu cầu phi chức năng (NFRs)

Các ràng buộc về hành vi của hệ thống (ví dụ: hiệu suất, bảo mật, khả năng sử dụng).

Ví dụ: “Giao dịch phải hoàn tất trong vòng 3 giây.”

4. Quy trình chi tiết hóa trường hợp sử dụng (theo từng bước)

Bước 1: Xác định trường hợp sử dụng

Bắt đầu với một trường hợp sử dụng ở cấp độ cao (ví dụ: “Đặt hàng”).

Sử dụng một mẫu:
Tên trường hợp sử dụng: Đặt hàng
Người thực hiện chính: Khách hàng
Các bên liên quan: Khách hàng, Hệ thống quản lý đơn hàng, Cổng thanh toán

Bước 2: Xác định điều kiện tiền đề

Liệt kê tất cả các điều kiện phải được đáp ứng trước khi trường hợp sử dụng bắt đầu.

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

  • Giỏ hàng chứa ít nhất một mặt hàng.

  • Phương thức thanh toán đã được lưu.

Bước 3: Xác định điều kiện hậu đề

Nêu rõ điều gì phải đúng sau khi trường hợp sử dụng hoàn tất.

  • Đơn hàng được tạo trong hệ thống.

  • Kho hàng được cập nhật.

  • Thanh toán được xử lý.

  • Email xác nhận đã được gửi.

Bước 4: Viết kịch bản thành công chính (luồng cơ bản)

Chi tiết hóa con đường lý tưởng và thành công.

  1. Khách hàng chọn “Thanh toán” từ giỏ hàng.

  2. Hệ thống hiển thị tóm tắt đơn hàng.

  3. Khách hàng xác nhận địa chỉ giao hàng.

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

  5. Hệ thống xử lý thanh toán.

  6. Thanh toán được xác nhận.

  7. Hệ thống tạo đơn hàng và tạo xác nhận.

  8. Xác nhận được hiển thị và email được gửi.

Bước 5: Xác định các luồng thay thế (luồng ngoại lệ)

Liệt kê các khả năng lệch khỏi luồng chính.

Luồng thay thế A: Hàng tồn kho không đủ

  1. Hệ thống kiểm tra kho.

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

  3. Hệ thống hiển thị thông báo: “Sản phẩm không có sẵn.”

  4. Khách hàng có thể loại bỏ sản phẩm hoặc tiếp tục mà không cần nó.

Luồng thay thế B: Thanh toán bị từ chối

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

  2. Hệ thống hiển thị lỗi: “Thanh toán bị từ chối.”

  3. Khách hàng có thể thử lại hoặc chọn phương thức khác.

Luồng thay thế C: Địa chỉ giao hàng không hợp lệ

  1. Hệ thống xác thực địa chỉ.

  2. Địa chỉ không hợp lệ.

  3. Hệ thống nhắc khách hàng sửa lại.

Bước 6: Xác định các phần mở rộng (quan hệ <>)

Sử dụng các phần mở rộng theo kiểu UML để thể hiện hành vi tùy chọn.

  • <>: Thông báo cho hệ thống kho

    • Kích hoạt: Khi một sản phẩm hết hàng trong quá trình thanh toán.

    • Mục đích: Cảnh báo kho để bổ sung hàng.

  • <>: Áp dụng mã giảm giá

    • Kích hoạt: Khách hàng nhập mã giảm giá hợp lệ.

    • Mục đích: Giảm tổng chi phí.

Bước 7: Thêm các yêu cầu phi chức năng (NFRs)

Bao gồm các giới hạn của hệ thống.

  • Đơn hàng phải được xử lý trong vòng 5 giây.

  • Thanh toán phải được mã hóa bằng TLS 1.3.

  • Hệ thống phải hỗ trợ 10.000 người dùng đồng thời.

Bước 8: Xem xét và xác nhận

Hợp tác với các bên liên quan để đảm bảo tính đầy đủ và chính xác.

  • Hỏi: “Liệu điều này có bao quát tất cả mục tiêu người dùng không?”

  • Hỏi: “Liệu tất cả các trường hợp biên đã được xem xét chưa?”

  • Hỏi: “Liệu một nhà phát triển có thể xây dựng dựa trên điều này không?”

5. Công cụ và kỹ thuật để phát triển chi tiết

Công cụ/Kỹ thuật Mục đích
Sơ đồ trường hợp sử dụng (UML) Trực quan hóa các tác nhân và các trường hợp sử dụng.
Sơ đồ tuần tự Hiển thị luồng tin nhắn giữa các đối tượng trong quá trình sử dụng trường hợp.
Sơ đồ hoạt động Mô hình hóa các quy trình phức tạp và các điểm ra quyết định.
Sơ đồ bản chất người dùng Kết nối các trường hợp sử dụng với hành trình người dùng và ưu tiên.
Bảng quyết định Làm rõ logic phức tạp (ví dụ: quy tắc giảm giá).

6. Các thực hành tốt nhất

  1. Giữ các trường hợp sử dụng hướng đến người dùng: Tập trung vào mục tiêu người dùng, chứ không phải tính năng hệ thống.

  2. Sử dụng tên nhất quán: Sử dụng định dạng động từ-danh từ (ví dụ: “Cập nhật hồ sơ”).

  3. Tránh dùng thuật ngữ kỹ thuật: Viết dành cho các bên liên quan không chuyên về kỹ thuật.

  4. Sử dụng ngôn ngữ đơn giản: Rõ ràng và súc tích.

  5. Lặp lại: Refined các trường hợp sử dụng khi hiểu biết ngày càng tăng.

  6. Liên kết đến các tài sản khác: Kết nối các trường hợp sử dụng với sơ đồ lớp, các trường hợp kiểm thử và các câu chuyện người dùng.

  7. Ưu tiên: Tập trung vào các trường hợp sử dụng có giá trị cao hoặc rủi ro cao trước.

7. Ví dụ thực tế: Ngân hàng trực tuyến – Chuyển tiền

Trường hợp sử dụng: Chuyển tiền

Nhân vật chính: Khách hàng
Nhân vật phụ: Máy chủ ngân hàng, Hệ thống phát hiện gian lận

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

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

  • Tài khoản nguồn có đủ số dư.

  • Không vượt quá giới hạn chuyển tiền.

Điều kiện hậu hành động

  • Số tiền được chuyển từ tài khoản nguồn sang tài khoản đích.

  • Giao dịch được ghi nhận trong cả hai tài khoản.

  • Thông báo được gửi đến cả hai bên.

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

  1. Khách hàng chọn “Chuyển tiền” từ bảng điều khiển.

  2. Hệ thống hiển thị mẫu chuyển tiền.

  3. Khách hàng nhập tài khoản đích và số tiền.

  4. Hệ thống xác thực tài khoản và số tiền.

  5. Khách hàng xác nhận chuyển tiền.

  6. Hệ thống kiểm tra các quy tắc phát hiện gian lận.

  7. Giao dịch được phê duyệt và thực hiện.

  8. Thông báo xác nhận được hiển thị.

Các luồng thay thế

  • A1: Số dư không đủ
    → Hệ thống hiển thị: “Số dư không đủ.”
    → Khách hàng có thể hủy hoặc điều chỉnh số tiền.

  • A2: Phát hiện gian lận
    → Hệ thống chặn giao dịch và gửi thông báo.
    → Khách hàng phải xác minh qua 2FA hoặc liên hệ hỗ trợ.

  • A3: Tài khoản đích không hợp lệ
    → Hệ thống hiển thị: “Không tìm thấy tài khoản.”
    → Khách hàng có thể nhập lại hoặc sử dụng tra cứu tài khoản.

Mở rộng

  • <>: Gửi thông báo đến người nhận

    • Kích hoạt: Giao dịch hoàn tất.

    • Mục đích: Thông báo cho người nhận.

  • <>: Áp dụng phí chuyển tiền

    • Kích hoạt: Số tiền chuyển > 1.000 USD.

    • Mục đích: Trừ phí 5 USD.

Yêu cầu phi chức năng

  • Tất cả các giao dịch phải được ghi lại và kiểm toán được.

  • Thời gian phản hồi ≤ 2 giây.

  • Dữ liệu được mã hóa trong quá trình truyền và khi lưu trữ.

8. Những sai lầm phổ biến và cách tránh chúng

Sai lầm Giải pháp
Quá mơ hồ (ví dụ: “Hệ thống nên xử lý đơn hàng”) Sử dụng các hành động cụ thể, đo lường được.
Ngôn ngữ quá kỹ thuật Sử dụng ngôn ngữ tự nhiên; tránh dùng thuật ngữ mã nguồn hoặc cơ sở dữ liệu.
Thiếu các đường dẫn xử lý ngoại lệ Sử dụng các luồng thay thế để bao phủ các trường hợp lỗi.
Không có tiêu chí thành công rõ ràng Xác định rõ ràng các điều kiện hậu kỳ.
Không có đánh giá từ bên liên quan Tham gia người dùng, người kiểm thử và chuyên gia kinh doanh.

9. Kết luận

Phát triển trường hợp sử dụng không chỉ là một bài tập tài liệu hóa—đó là một quá trình chiến lược nhằm đảm bảo hệ thống đáp ứng nhu cầu thực tế của người dùng một cách rõ ràng, chính xác và đầy đủ. Bằng cách hệ thống hóa việc mở rộng các trường hợp sử dụng cấp cao thành các thông số chi tiết và có thể hành động, các đội nhóm giảm thiểu rủi ro, cải thiện giao tiếp và tạo nền tảng vững chắc cho việc triển khai phần mềm thành công.

✅ Lời khuyên cuối cùng: Xem việc phát triển trường hợp sử dụng như một cuộc trò chuyện lặp lại—không phải là một nhiệm vụ duy nhất. Cải tiến nó khi bạn hiểu thêm về hệ thống và người dùng.

Phụ lục: Mẫu phát triển trường hợp sử dụng

# Tên trường hợp sử dụng: [ví dụ: Cập nhật hồ sơ]

**Người thực hiện chính**: [ví dụ: Khách hàng]  
**Người thực hiện phụ**: [ví dụ: Cơ sở dữ liệu, Dịch vụ Email]  
**Các bên liên quan**: [ví dụ: Khách hàng, Đội hỗ trợ]

### Điều kiện tiền đề
- [Liệt kê các điều kiện]

### Điều kiện hậu kỳ
- [Liệt kê các kết quả]

### Diễn biến thành công chính (Luồng cơ bản)
1. [Bước 1]  
2. [Bước 2]  
...

### Luồng thay thế
- **A1: [Tên]**  
  1. [Bước]  
  2. [Bước]  
- **A2: [Tên]**  
  ...

### Mở rộng (<<extend>>)
- **<<extend>>: [Tên]**  
  - Kích hoạt: [Khi nào]  
  - Mục đích: [Tại sao]

### Yêu cầu phi chức năng
- [Hiệu suất, Bảo mật, Dễ sử dụng, v.v.]

### Ghi chú
- [Nội dung bổ sung hoặc giả định]

Bằng cách tuân theo hướng dẫn này, các đội nhóm có thể thành thạo nghệ thuật phát triển trường hợp sử dụng và xây dựng các hệ thống không chỉ hoạt động được mà còn thực sự phù hợp với mong đợi của người dùng.

Phụ lục – Mô tả trường hợp sử dụng rút tiền từ máy ATM:

Tên trường hợp sử dụng

Rút tiền

Người thực hiện chính

Khách hàng (chủ tài khoản ngân hàng)

Người thực hiện phụ

  • Máy ATM

  • Máy chủ ngân hàng (Hệ thống ngân hàng cốt lõi)

  • Cổng thanh toán (để xử lý giao dịch)

  • Hệ thống phát hiện gian lận

  • Máy in (để tạo hóa đơn)

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

  • Khách hàng: Muốn rút tiền một cách an toàn và hiệu quả.

  • Ngân hàng: Đảm bảo tính toàn vẹn giao dịch, phòng chống gian lận và cập nhật tài khoản chính xác.

  • Người vận hành máy ATM: Đảm bảo máy luôn sẵn sàng hoạt động và quản lý tồn kho tiền mặt.

  • Đội Bảo mật: Giám sát các hành vi đáng ngờ và ngăn chặn gian lận.

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

  1. Khách hàng đã đưa thẻ ngân hàng hợp lệ vào máy ATM.

  2. Khách hàng đã xác thực thành công (nhập đúng mã PIN).

  3. Tài khoản của khách hàng đang hoạt động và chưa bị khóa.

  4. Máy ATM có đủ tiền trong kho.

  5. Tài khoản của khách hàng có số dư khả dụng đủ.

  6. Giới hạn rút tiền hàng ngày chưa bị vượt quá.

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

  1. Số tiền yêu cầu được phát cho khách hàng.

  2. Số dư tài khoản của khách hàng bị giảm đi số tiền đã rút.

  3. Một bản ghi giao dịch được tạo trong hệ thống ngân hàng.

  4. Một biên lai được in ra (nếu được yêu cầu).

  5. Máy ATM ghi lại giao dịch để kiểm toán và đối chiếu.

Cảnh huống thành công chính (Luồng cơ bản)

Bước Hành động hệ thống Phản hồi của người dùng
1 Máy ATM hiển thị: “Vui lòng nhập mã PIN của bạn.” Khách hàng nhập mã PIN.
2 Máy ATM xác thực mã PIN với máy chủ ngân hàng. Hệ thống xác nhận mã PIN đúng.
3 Máy ATM hiển thị menu chính: “Rút tiền, Kiểm tra số dư, Chuyển tiền, Thoát.” Khách hàng chọn “Rút tiền.”
4 Máy ATM hiển thị: “Nhập số tiền cần rút.” Khách hàng nhập số tiền (ví dụ: 100$).
5 ATM xác minh:

  • Số tiền nằm trong giới hạn hàng ngày.

  • Tài khoản có đủ số dư.

  • ATM có đủ tiền mặt. | Hệ thống xác nhận tính hợp lệ. |
    | 6 | ATM yêu cầu xác thực từ Máy chủ Ngân hàng. | Máy chủ Ngân hàng chấp thuận giao dịch. |
    | 7 | ATM phát tiền từ kho. | Khách hàng nhận tiền. |
    | 8 | ATM hiển thị: “Bạn có muốn in hóa đơn không?” | Khách hàng chọn “Có” hoặc “Không”. |
    | 9 | Nếu “Có”: ATM in hóa đơn với:

  • Ngày/giờ

  • Số tiền rút

  • Số dư còn lại

  • Mã giao dịch | Khách hàng nhận hóa đơn. |
    | 10 | ATM hiển thị: “Cảm ơn quý khách. Vui lòng rút thẻ.” | Khách hàng rút thẻ. |
    | 11 | ATM quay về trạng thái chờ. | Hệ thống được khởi động lại. |

✅ Kết quả thành công: Khách hàng nhận tiền mặt và (tùy chọn) hóa đơn. Tài khoản được cập nhật.

Các luồng thay thế (các tình huống ngoại lệ)

A1: Nhập mã PIN không hợp lệ (3 lần)

  • Kích hoạt: Khách hàng nhập sai mã PIN ba lần.

  • Hành động hệ thống: ATM khóa thẻ và hiển thị: “Thẻ bị khóa. Liên hệ ngân hàng của bạn.”

  • Hành động người dùng: Khách hàng rời khỏi và liên hệ ngân hàng.

  • Điều kiện hậu: Thẻ bị tạm thời khóa; giao dịch được ghi lại.

⚠️ Lưu ý: Đây là một biện pháp bảo mật nhằm ngăn chặn truy cập trái phép.

A2: Số dư không đủ

  • Kích hoạt: Khách hàng nhập số tiền vượt quá số dư có sẵn.

  • Hành động của hệ thống: ATM hiển thị: “Số dư không đủ. Số dư hiện tại: $X.”

  • Hành động của người dùng: Khách hàng chọn “Hủy” hoặc nhập số tiền thấp hơn.

  • Điều kiện hậu: Không phát tiền; không thay đổi tài khoản.

A3: Tiền trong ATM không đủ

  • Kích hoạt: Khách hàng nhập số tiền hợp lệ, nhưng kho tiền ATM trống hoặc dưới mức tối thiểu.

  • Hành động của hệ thống: ATM hiển thị: “Tiền không có sẵn. Vui lòng thử lại sau.”

  • Hành động của người dùng: Khách hàng hủy hoặc quay lại sau.

  • Điều kiện hậu: Giao dịch không được xử lý; không thay đổi tài khoản.

A4: Số tiền rút vượt quá giới hạn hàng ngày

  • Kích hoạt: Khách hàng cố gắng rút số tiền vượt quá giới hạn hàng ngày (ví dụ: 1.000 USD).

  • Hành động của hệ thống: ATM hiển thị: “Vượt quá giới hạn rút hàng ngày. Vui lòng thử số tiền nhỏ hơn.”

  • Hành động của người dùng: Khách hàng giảm số tiền hoặc hủy.

  • Điều kiện hậu: Giao dịch không được xử lý.

A5: Giao dịch bị từ chối bởi máy chủ ngân hàng

  • Kích hoạt: Máy chủ ngân hàng từ chối giao dịch (ví dụ: do cảnh báo gian lận, tài khoản bị đóng băng).

  • Hành động hệ thống: ATM hiển thị: “Giao dịch bị từ chối. Vui lòng liên hệ ngân hàng của bạn.”

  • Hành động người dùng: Khách hàng hủy và liên hệ ngân hàng.

  • Sau điều kiện: Không phát tiền; không thay đổi tài khoản.

Mở rộng (mối quan hệ <>)

Mở rộng Kích hoạt Mục đích
<>: Thông báo cho Hệ thống Phát hiện Gian lận Khi rút tiền tại một quốc gia nước ngoài hoặc vượt quá hành vi thông thường Đánh dấu hoạt động đáng ngờ để xem xét
<>: Gửi thông báo SMS đến khách hàng Sau khi rút tiền thành công Thông báo cho khách hàng về giao dịch (an ninh nâng cao)
<>: Áp dụng phí rút tiền Đối với người dùng không phải chủ tài khoản chính hoặc một số loại tài khoản nhất định Thu phí cho các dịch vụ cụ thể
<>: In lịch sử giao dịch Nếu khách hàng chọn “In lịch sử” trên menu Cung cấp bản tóm tắt in ra về các giao dịch gần đây

Yêu cầu phi chức năng (NFRs)

Loại Yêu cầu
Hiệu suất Giao dịch phải được xử lý trong vòng 3 giây.
Bảo mật Tất cả giao tiếp được mã hóa (TLS 1.3). Mã PIN không bao giờ được lưu trữ hoặc truyền dưới dạng văn bản thuần.
Độ tin cậy ATM không được phát tiền trừ khi máy chủ ngân hàng xác nhận quyền truy cập.
Tính dễ sử dụng Giao diện phải dễ truy cập (ví dụ: nút lớn, hướng dẫn bằng giọng nói cho người khiếm thị).
Tính sẵn có ATM phải hoạt động 99,9% thời gian.
Kiểm toán và tuân thủ Tất cả giao dịch phải được ghi lại và truy xuất được trong 7 năm (theo quy định ngân hàng).

Ghi chú

  • ATM phải được bảo trì định kỳ để đảm bảo nguồn tiền mặt sẵn có và độ tin cậy của phần cứng.

  • Nếu thẻ không được rút ra trong vòng 30 giây sau khi giao dịch, thẻ sẽ được giữ tự động (tính năng chống trộm).

  • Hệ thống hỗ trợ nhiều loại tiền tệ và tính toán tỷ giá (nếu có áp dụng).

Sơ đồ trường hợp sử dụng (Tóm tắt UML)

[Khách hàng] --(Rút tiền)--> [ATM]
[ATM] --(Xác thực mã PIN)--> [Máy chủ ngân hàng]
[ATM] --(Kiểm tra số dư)--> [Máy chủ ngân hàng]
[ATM] --(Phát tiền)--> [Kho tiền]
[ATM] --(In hóa đơn)--> [Máy in]
[ATM] --(Thông báo hệ thống gian lận)--> [Hệ thống phát hiện gian lận]

(Ghi chú: Trong sơ đồ UML đầy đủ, các mối quan hệ trường hợp sử dụng như <> và <> sẽ được hiển thị.)

✅ Tóm tắt

Đây làtrường hợp sử dụng chi tiếtcho “rút tiền” cung cấp một tài liệu cụ thể, có cấu trúc và có thể kiểm thử, bao gồm:

  • Ghi lại mục tiêu người dùng và hành vi hệ thống.

  • Xử lý các ngoại lệ trong thực tế.

  • Hỗ trợ bảo mật, tuân thủ và tính dễ sử dụng.

  • Là nền tảng cho thiết kế, kiểm thử và triển khai.

Nó phù hợp để sử dụng trong các giai đoạn Agile, tài liệu thiết kế hệ thống hoặc các tài liệu yêu cầu chính thức.

📘 Bước tiếp theo:

  • Chuyển đổi điều này thành mộtsơ đồ tuần tự để hiển thị các tương tác đối tượng.

  • Tạo các trường hợp kiểm thử dựa trên mỗi luồng (chính và thay thế).

  • Liên kết đến sơ đồ lớp (ví dụ như Tài khoản, Giao dịch, ATM, Bộ phát hiện gian lận).

Related Posts

Recent Comments

Không có bình luận nào để hiển thị.
Sidebar Search
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...