Hướng Dẫn Nhanh Về Mô Hình Trường Hợp Sử Dụng

Mô hình trường hợp sử dụnglà một công cụ hữu ích để ghi lại các yêu cầu. Nó cung cấp một biểu diễn đồ họa của các yêu cầu của một hệ thống phần mềm.

Với sự công bố củaIvar Jacobson(1991) cuốn sáchKỹ Nghệ Phần Mềm Hướng Đối Tượng, Một Cách Tiếp Cận Dựa Trên Trường Hợp Sử Dụng, mô hình trường hợp sử dụng đã trở thành một kỹ thuật phân tích thực tiễn”. Ngày nay, Jacobson tiếp tục thúc đẩy cách tiếp cận này đến phân tích hệ thống và đã nâng cấp nó lên Use Case 2.0, mà chính thức là một trong số14 loại biểu đồ UML.

Bởi vì mô hình trường hợp sử dụng đơn giản về khái niệm và hình thức, nên tương đối dễ dàng để thảo luận về tính chính xác của nó với nhân viên không kỹ thuật (như khách hàng).

Một trường hợp sử dụng không phải là một quy trình, quá trình, hoặc chức năng.

Các Thành Phần Của Biểu Đồ Trường Hợp Sử Dụng

Cácthành phần của một biểu đồ trường hợp sử dụnglà các diễn viên (thực thể bên ngoài) và chính trường hợp sử dụng. Nói chung, một trường hợp sử dụng là một đơn vị chức năng (yêu cầu) hoặc dịch vụ trong một hệ thống.

Diễn viên

Mộtdiễn viênlà bất kỳ thực thể nào bên ngoài hệ thống thiết kế, cho dù đó là một người hay một thực thể không phải con người khác. Một người dùng của một hệ thống là một ví dụ điển hình của một diễn viên. Các loại diễn viên khác bao gồm các hệ thống phần mềm đang được tích hợp với hệ thống hiện tại (ví dụ: một hệ thống cơ sở dữ liệu), phần cứng bên ngoài như cảm biến và nhiều thứ khác.Types of Actors

Có hai ký hiệu trongđặc tả UML:

Sử dụng hình người que cho các diễn viên thì biểu cảm hơn, nhưng có thể dẫn đến sự nhầm lẫn nếu diễn viên không thực sự là một người, mà là một máy hoặc thiết bị bên ngoài. Ký hiệu hình chữ nhật là ký hiệu chuẩnký hiệu UMLcho mộtlớp.

Một Diễn viên là Vai trò Thay vì Một Người Thực

Một diễn viên đại diện cho vai trò của thực thể tương tác với hệ thống hiện tại, không phải là một thể hiện.Ký hiệu diễn viên chỉ ra rằng thực thể là một lớp thay vì một thể hiện cụ thể (tức là một người dùng thực sự như John hoặc Mary). Lý do mà một diễn viên là một loại lớp là vì nó không phải là diễn viên đó, mà làvai trò mà anh/cô ấy đảm nhận.

Ví dụ, một diễn viên có thể đại diện cho khách hàng của một ngân hàng, thay vì chỉ định một diễn viên riêng cho mỗi khách hàng. Tương tự, có thể có một diễn viên khác đại diện cho giám đốc ngân hàng. Thú vị là, trong thế giới thực, giám đốc của một ngân hàng cũng có thể là một khách hàng của cùng một ngân hàng. Nói cách khác, cùng một người đảm nhận vai trò của cả khách hàng và giám đốc.

Diễn viên Chính và Diễn viên Phụ

Diễn viên Chínhcủa một trường hợp sử dụng là bên liên quan yêu cầu hệ thống cung cấp dịch vụ của nó. Nó có một mục tiêu liên quan đến hệ thống – một mục tiêu có thể được đáp ứng bởi hoạt động của hệ thống. Diễn viên chính thường là, nhưng không phải lúc nào cũng vậy, diễn viên kích hoạt trường hợp sử dụng.

Diễn viên Phụđược hệ thống sử dụng, nhưng họ không tương tác với hệ thống một cách độc lập. Nói cách khác, các diễn viên phụ không khởi xướng bất kỳ trường hợp sử dụng nào.

Các trường hợp sử dụng thường được khởi xướng bởi các diễn viên chính. Hệ thống sử dụng một diễn viên phụ như một cơ sở dữ liệu thông qua một tập hợp các trường hợp sử dụng. Mối quan hệ giữa các trường hợp sử dụng và các bên tham gia đại diện cho một giao tiếp hai chiều.

Vì vậy, đối với mỗi trường hợp sử dụng được khởi xướng bởi một diễn viên chính, trường hợp sử dụng liên kết phải được phản hồi. Tương tự, đối với mỗi mối quan hệ giữa một diễn viên phụ và một trường hợp sử dụng, giao tiếp bắt đầu từ trường hợp sử dụng và diễn viên phụ nên phản hồi lại sự khởi xướng.

Trường Hợp Sử Dụng

Các trường hợp sử dụngđại diện cho các chức năng (thường là yêu cầu) dự kiến sẽ được thực hiện bởi hệ thống. Các chi tiết của trường hợp sử dụng, ngoại trừ tên duy nhất của nó, không được thể hiện một cách trực quan trong biểu đồ; Các chi tiết này được cung cấp trong mô tả trường hợp sử dụng.

Các trường hợp sử dụng thường được khởi xướng bởi các diễn viên chính. Hệ thống sử dụng cơ sở dữ liệu và các bên tham gia phụ trợ khác thông qua một tập hợp các trường hợp sử dụng.

Mối quan hệ giữa các trường hợp sử dụng và các diễn viên đại diện cho giao tiếp hai chiều. Do đó, đối với mỗi trường hợp sử dụng được khởi xướng bởi diễn viên chính, diễn viên đó phải được phản hồi. Tương tự, đối với mỗi mối quan hệ giữa diễn viên phụ và trường hợp sử dụng, giao tiếp bắt đầu từ trường hợp sử dụng, và diễn viên phụ nên phản hồi lại sự khởi xướng.

Ranh Giới Hệ Thống

Ranh giới hệ thống xác định hệ thống quan tâm liên quan đến thế giới xung quanh nó.

Ví Dụ Biểu Đồ Trường Hợp Sử Dụng: Hệ Thống Đặt Vé Máy Bay

Các trường hợp sử dụng xác định các tương tác giữa các diễn viên bên ngoài và hệ thống để đạt được các mục tiêu cụ thể. Một biểu đồ trường hợp sử dụng chứa bốn thành phần chính

Trong biểu đồ trường hợp sử dụng của một hệ thống đặt vé, hệ thống được đại diện bởi các hộp chứa nhiều trường hợp sử dụng khác nhau. Diễn viên chính là khách hàng và diễn viên phụ là quản trị viên. Khách hàng khởi xướng các trường hợp sử dụng, chẳng hạn như đặt vé, duyệt và hủy chuyến bay, trong khi quản trị viên khởi xướng các trường hợp sử dụng, chẳng hạn như cập nhật hồ sơ chuyến bay, nhưng được coi là một diễn viên phụ trong trường hợp sử dụng hủy chuyến bay, vì cô ấy chỉ giúp hoàn thành các trường hợp sử dụng do khách hàng khởi xướng.

Chỉnh sửa ví dụ Biểu Đồ Trường Hợp Sử Dụng UML này

Cấu Trúc Các Trường Hợp Sử Dụng

Theo lĩnh vực ứng dụng và sự lựa chọn của nhà thiết kế, một trường hợp sử dụng có thể được chia thành nhiều trường hợp sử dụng, được kết nối thông qua các mối quan hệ < < bao gồm > > hoặc < < mở rộng > >.

Liên Kết Hiệp Hộiđại diện cho một giao tiếp hai chiều giữa một diễn viên và một trường hợp sử dụng, và do đó là một mối quan hệ nhị phân. Vì đây là một giao tiếp hai chiều, đối với mỗi trường hợp sử dụng được khởi xướng bởi một diễn viên chính, diễn viên đó phải nhận được phản hồi từ trường hợp sử dụng.

Customer pays bill

Tương tự, đối với mỗi giao tiếp giữa một trường hợp sử dụng và một diễn viên phụ (được khởi xướng bởi trường hợp sử dụng), diễn viên phụ phải gửi phản hồi trở lại cho trường hợp sử dụng.

Khái Quát Hóa

Khái quát hóa đại diện cho mối quan hệ giữa

  • các vai trò hoặc
  • các trường hợp sử dụng.

Chỉnh sửa mẫu Biểu Đồ Trường Hợp Sử Dụng UML này

Nếu hai diễn viên được kết nối bởi mối quan hệ này, thì diễn viên (hoặc trường hợp sử dụng) ở cuối mũi tên (kết nối với đáy của tam giác) là một phiên bản chuyên biệt của diễn viên (hoặc trường hợp sử dụng) ở đầu kia.

Thông thường, diễn viên (hoặc trường hợp sử dụng) ở cuối dưới (kết nối với đáy của tam giác) được gọi là phiên bản chuyên biệt của diễn viên (hoặc trường hợp sử dụng) ở đầu kia.

Khái quát hóa có nghĩa là phiên bản chuyên biệt có mọi tính năng của phiên bản tổng quát, và có thể nhiều hơn.

Bao Gồmlà một loại mối quan hệ đặc biệt giữa hai trường hợp sử dụng. Nếu một trường hợp sử dụng A bao gồm một trường hợp sử dụng khác B, thì việc thực hiện A yêu cầu việc thực hiện B để hoàn thành nhiệm vụ của nó. Tuy nhiên, B độc lập với chính nó. Tức là, B không cần biết gì về A. B cũng có thể được bao gồm trong bất kỳ trường hợp sử dụng nào khác.

Chỉnh sửa ví dụ Biểu Đồ Trường Hợp Sử Dụng này

Mở Rộnglà một loại mối quan hệ đặc biệt khác giữa hai trường hợp sử dụng. Nếu một trường hợp sử dụng B mở rộng một trường hợp sử dụng khác A, thì việc thực hiện A có thể điều kiện bao gồm việc thực hiện B để hoàn thành nhiệm vụ của nó. Tức là, trong một số trường hợp, A có thể hoàn thành nhiệm vụ của mình mà không cần B. Tuy nhiên, tùy thuộc vào các điều kiện được mô tả.

Chỉnh sửa ví dụ Biểu Đồ Trường Hợp Sử Dụng này

Ký Hiệu Biểu Đồ Trường Hợp Sử Dụng

Use Case Diagram Tutorial

Chỉnh sửa ví dụ Biểu Đồ Trường Hợp Sử Dụng này trực tuyến

9 Bước Đơn Giản Để Thực Hiện Phân Tích Trường Hợp Sử Dụng

  1. Xác định ai sẽ trực tiếp sử dụng hệ thống. Những người này là các diễn viên.
  2. Chọn một trong những diễn viên này.
  3. Xác định những gì diễn viên đó muốn làm với hệ thống. Mỗi việc mà diễn viên muốn làm với hệ thống trở thành một trường hợp sử dụng.
  4. Lặp lại các bước 2-3 cho tất cả các trường hợp sử dụng khác
    Xác định các vai trò phụ và hỗ trợ vai trò không phải con người cho các trường hợp sử dụng mà bạn đã xác định.
  5. Vẽ phiên bản ban đầu của trường hợp sử dụng, không làm phức tạp hóa các mối quan hệ trường hợp sử dụng tại thời điểm này
  6. Thảo luận và xem xét với người dùng để xác thực các mục tiêu của mỗi trường hợp sử dụng (lợi ích của chức năng đề xuất) Sau khi sửa đổi, bạn có thể tiếp tục chi tiết các trường hợp sử dụng trong các bước 8 – 10
  7. Đối với mỗi trường hợp sử dụng, quyết định quy trình phổ biến nhất mà diễn viên sẽ theo khi sử dụng hệ thống. Điều gì sẽ xảy ra bình thường.
  8. Mô tả quy trình cơ bản này trong mô tả của trường hợp sử dụng.
  9. Khi bạn đã hài lòng với quy trình cơ bản, hãy xem xét các kịch bản thay thế và thêm chúng như các trường hợp sử dụng mở rộng.

Mô Hình và Đặc Tả Trường Hợp Sử Dụng

Chỉ hiển thị biểu đồ trường hợp sử dụng trong ký hiệu UML là không đủ. Mỗi trường hợp sử dụng đi kèm với văn bản giải thích mục đích của trường hợp sử dụng và chức năng được thực hiện khi trường hợp sử dụng được thực thi.

Một trường hợp sử dụng mô tả một nhiệm vụ được thực hiện bởi một diễn viên tạo ra giá trị kinh doanh cho doanh nghiệp. Một trường hợp sử dụng có thể được hình dung như một biểu đồ trường hợp sử dụng hoặc/ và trong mộtđặc tả văn bản có cấu trúcđịnh dạng.

Use Case vs Use Case Specification

Kịch Bản Trường Hợp Sử Dụng

Một trường hợp sử dụng bao gồm một số kịch bản, mỗi kịch bản đại diện cho một thể hiện cụ thể của trường hợp sử dụng, tương ứng với các đầu vào cụ thể từ diễn viên hoặc các điều kiện cụ thể trong môi trường. Mỗi kịch bản mô tả một cách thay thế cho hệ thống hoạt động, hoặc có thể mô tả các lỗi hoặc ngoại lệ.

Một trường hợp sử dụng có:

  • Chỉ một mục tiêu
  • Một điểm bắt đầu duy nhất
  • Một điểm kết thúc duy nhất
  • Nhiều con đường để đi từ bắt đầu đến kết thúc
    • tức là. Xác định hành vi cho nhiều điều kiện có thể xảy ra
    • Mỗi điều kiện có thể yêu cầu hành động cụ thể

Characteristics of Use Cases

Ví dụ – Khách hàng thanh toán hóa đơn:

Customer pays bill

Có nhiều con đường đểđạt được mục tiêu:

  • Thanh toán qua điện thoại
  • Qua bưu điện
  • Trực tiếp
  • bằng séc
  • bằng tiền mặt, v.v.

Một con đường mà không dẫn đến mục tiêu:

  • Thẻ tín dụng bị từ chối

Nhóm các trường hợp sử dụng với các gói

Bạn cũng có thể: Vẽ các gói để phân loại hợp lý các trường hợp sử dụng vào các hệ thống con liên quan.

UML Use Case Diagram with Packages

Chỉnh sửa ví dụ sơ đồ trường hợp sử dụng này

Thông số kỹ thuật trường hợp sử dụng chi tiết

Một trường hợp sử dụng chi tiết là một đại diện bằng văn bản mô tả một chuỗi sự kiện và các thông tin liên quan khác về trường hợp sử dụng theo một định dạng cụ thể. Một mẫu trường hợp sử dụng tiêu chuẩn thường được sử dụng để ghi lại các chi tiết của một trường hợp sử dụng

A Detailed Use Case Specification

Mô tả trường hợp sử dụng là gì

Một mô tả trường hợp sử dụnglà một mô tả bằng văn bản về chuỗi các bước mà một nhà phân tích thực hiện để hoàn thành một giao dịch hệ thống hoàn chỉnh. Nó được khởi xướng bởi một diễn viên, cung cấp giá trị cho diễn viên đó, và là mục tiêu của các diễn viên làm việc trong hệ thống.

Diễn viên – Bất kỳ người hoặc hệ thống nào bên ngoài hệ thống sử dụng hoặc tương tác với hệ thống để đạt được một mục tiêu. Mỗi diễn viên được giao một vai trò để đại diện cho sự tương tác của họ với giải pháp. Các diễn viên là người nên được đặt tên theo hình thức vai trò và không nên được gán tên thực. Các diễn viên thường được phân loại thành chính, phụ hoặc bên liên quan.

Diễn viên chính – Diễn viên khởi xướng trường hợp sử dụng.
Diễn viên phụ – Diễn viên phản ứng hoặc đáp lại các hành động được thực hiện bởi diễn viên chính.
Các bên liên quan – các diễn viên ngoài sân khấu không tương tác trực tiếp với trường hợp sử dụng, nhưng có mối quan tâm đến kết quả của trường hợp sử dụng.

Luồng sự kiện (đường đi) – chuỗi các bước mà các diễn viên và giải pháp phải thực hiện để thực hiện một trường hợp sử dụng. Nói chung, một trường hợp sử dụng bao gồm một con đường thành công chính (còn gọi là cơ bản hoặc chính), một con đường thay thế và một con đường ngoại lệ.

Con đường bình thường – đầu vào từ diễn viên và phản hồi từ hệ thống – đại diện cho con đường thành công phổ biến nhất để đạt được mục tiêu của diễn viên.

Các con đường thay thế – đầu vào từ diễn viên và phản hồi từ hệ thống, đại diện cho các con đường ít phổ biến hơn để đạt được mục tiêu của diễn viên

Các con đường ngoại lệ – đầu vào từ diễn viên và phản hồi từ hệ thống, đại diện cho các con đường không thành công khi mục tiêu của diễn viên không thể đạt được.

Mô tả trường hợp sử dụng
Tên trường hợp sử dụng: Rút tiền mặt
Diễn viên: Khách hàng (chính), Hệ thống Ngân hàng (phụ)
Mô tả tóm tắt: Cho phép bất kỳ khách hàng ngân hàng nào rút tiền mặt từ tài khoản ngân hàng của họ.
Ưu tiên: Phải có
Trạng thái: Mức độ chi tiết trung bình
Điều kiện tiên quyết: Khách hàng ngân hàng có thẻ để đưa vào máy ATM
Máy ATM hoạt động trực tuyến đúng cách
Điều kiện hậu kỳ:
  • Khách hàng ngân hàng đã nhận được tiền mặt của họ (và tùy chọn một biên lai)
  • Ngân hàng đã ghi nợ tài khoản ngân hàng của khách hàng và ghi lại chi tiết giao dịch
Đường đi cơ bản:
  1. Khách hàng đưa thẻ của họ vào máy ATM
  2. Máy ATM xác minh rằng thẻ là thẻ ngân hàng hợp lệ
  3. Máy ATM yêu cầu mã PIN
  4. Khách hàng nhập mã PIN của họ
  5. Máy ATM xác thực thẻ ngân hàng với mã PIN
  6. Máy ATM đưa ra các tùy chọn dịch vụ bao gồm “Rút tiền”
  7. Khách hàng chọn “Rút tiền”
  8. Máy ATM đưa ra các tùy chọn về số tiền
  9. Khách hàng chọn một số tiền hoặc nhập một số tiền
  10. Máy ATM xác minh rằng nó có đủ tiền mặt trong khoang chứa
  11. Máy ATM xác minh rằng khách hàng nằm dưới giới hạn rút tiền
  12. Máy ATM xác minh đủ tiền trong tài khoản ngân hàng của khách hàng
  13. Máy ATM ghi nợ tài khoản ngân hàng của khách hàng
  14. Máy ATM trả lại thẻ ngân hàng của khách hàng
  15. Khách hàng lấy thẻ ngân hàng của họ
  16. Máy ATM phát tiền mặt cho khách hàng
  17. Khách hàng lấy tiền mặt của họ
Các con đường thay thế:
  1. 2a. Thẻ không hợp lệ
  2. 2b. Thẻ bị lật ngược
  3. 5a. Thẻ bị đánh cắp
  4. 5b. Mã PIN không hợp lệ
  5. 10a. Không đủ tiền mặt trong khoang chứa
  6. 10b. Mệnh giá tiền mặt không đúng trong khoang chứa
  7. 11a. Rút tiền vượt quá giới hạn rút tiền
  8. 12a. Không đủ tiền trong tài khoản ngân hàng của khách hàng
  9. 14a. Thẻ ngân hàng bị kẹt trong máy
  10. 15a. Khách hàng không lấy thẻ ngân hàng của họ
  11. 16a. Tiền mặt bị kẹt trong máy
  12. 17a. Khách hàng không lấy tiền mặt của họ
    • a Máy ATM không thể giao tiếp với Hệ thống Ngân hàng
    • b Khách hàng không phản hồi với yêu cầu của máy ATM
Quy tắc kinh doanh:
  1. B1: Định dạng của mã PIN
  2. B2: Số lần thử mã PIN
  3. B3: Tùy chọn dịch vụ
  4. B4: Tùy chọn số tiền
  5. B5: Giới hạn rút tiền
  6. B6: thẻ phải được lấy ra trước khi phát tiền mặt
Yêu cầu phi chức năng:
  1. NF1: Thời gian cho giao dịch hoàn chỉnh
  2. NF2: Bảo mật cho việc nhập mã PIN
  3. NF3: Thời gian cho phép thu thập thẻ và tiền mặt
  4. NF4: Hỗ trợ ngôn ngữ
  5. NF5: Hỗ trợ cho người mù và người khiếm thị một phần

Liên kết liên quan

  1. Ngôn ngữ mô hình hóa thống nhất là gì?
  2. Slide trường hợp sử dụng / Ghi chú bài giảng
  3. Vai trò của các trường hợp sử dụng trong yêu cầu và mô hình phân tích
  4. Danh sách các công cụ UML
  5. Thử Visual Paradigm MIỄN PHÍ
  6. Tình huống sử dụng – Ghi chú cho Khóa đào tạo
  7. Cách viết các tình huống sử dụng hiệu quả?
  8. Chương sách – PDF – Mô hình tình huống sử dụng: Viết yêu cầu trong ngữ cảnh

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

Leave a Reply

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *