Tất cả những gì bạn cần biết về mô hình hóa trường hợp sử dụng

Lợi ích của sơ đồ trường hợp sử dụng

1. Các trường hợp sử dụng là một kỹ thuật mạnh mẽ để thu thập và tài liệu hóa các yêu cầu chức năng hộp đen.
2. Bởi vì, các trường hợp sử dụng dễ hiểu và cung cấp một cách tuyệt vời để giao tiếp với khách hàng và người dùng vì chúng được viết bằng ngôn ngữ tự nhiên.
3. Các trường hợp sử dụng có thể giúp quản lý độ phức tạp của các dự án lớn bằng cách phân chia vấn đề thành các tính năng người dùng chính (tức là, các trường hợp sử dụng) và bằng cách xác định các ứng dụng từ quan điểm của người dùng.
4. Một kịch bản trường hợp sử dụng, thường được đại diện bởi một sơ đồ tuần tự, liên quan đến sự hợp tác của nhiều đối tượng và lớp, các trường hợp sử dụng giúp xác định các thông điệp (các hoạt động và thông tin hoặc dữ liệu cần thiết – tham số) kết nối các đối tượng và lớp lại với nhau.
5. Các trường hợp sử dụng cung cấp một cơ sở tốt để liên kết giữa việc xác minh các mô hình cấp cao hơn (tức là tương tác giữa các diễn viên và một tập hợp các đối tượng hợp tác), và sau đó, để xác thực các yêu cầu chức năng (tức là bản thiết kế của bài kiểm tra hộp trắng).
6. Phương pháp dựa trên trường hợp sử dụng cung cấp các liên kết có thể theo dõi cho việc theo dõi dự án trong đó các hoạt động phát triển chính như các trường hợp sử dụng được triển khai, kiểm tra và giao hàng đáp ứng các mục tiêu và mục tiêu từ quan điểm của người dùng.

Cách vẽ sơ đồ trường hợp sử dụng?

Một mô hình Use Case có thể được phát triển bằng cách làm theo các bước dưới đây.

1. Xác định các Diễn viên (vai trò của người dùng) của hệ thống.
2. Đối với mỗi loại người dùng, xác định tất cả các vai trò mà người dùng đảm nhận liên quan đến hệ thống.
3. Xác định những gì người dùng yêu cầu hệ thống thực hiện để đạt được những mục tiêu này.
4. Tạo các use case cho mỗi mục tiêu.
5. Cấu trúc các use case.
6. Ưu tiên, xem xét, ước lượng và xác thực người dùng.

Lưu ý rằng: để làm cho phương pháp use case trở nên “Agile” hơn, không nên chi tiết hóa tất cả các use case, mà hãy ưu tiên chúng trong danh sách sản phẩm của bạn, bạn nên tinh chỉnh use case ở các mức độ chi tiết khác nhau tùy theo giai đoạn phát triển theo cách kịp thời và đủ mức.

Bạn cũng có thể:

1. Vẽ các gói để phân loại hợp lý các use case vào các hệ thống con liên quan.

Cấu trúc các Use Cases

UML định nghĩa ba kiểu mẫu của mối quan hệ giữa các Use Cases:

<<include>> Use Case

Thời điểm sử dụng mối quan hệ <<include>> là sau khi bạn đã hoàn thành mô tả lần đầu tiên của tất cả các Use Case chính. Bây giờ bạn có thể xem xét các Use Case và xác định các chuỗi tương tác giữa người dùng và hệ thống chung.

<<extend>> Use Case

Một use case mở rộng là, thực chất, một khóa học thay thế của use case cơ bản. Use case <<extend>> đạt được điều này bằng cách khái niệm chèn thêm các chuỗi hành động vào chuỗi use case cơ bản.

Use Case trừu tượng và tổng quát

Use case tổng quát là trừu tượng. Nó không thể được khởi tạo, vì nó chứa thông tin không đầy đủ. Tiêu đề của một use case trừu tượng được hiển thị bằng chữ nghiêng.

Ví dụ

Ví dụ này mô tả một mô hình của một số use case kinh doanh (mục tiêu) đại diện cho các tương tác giữa một nhà hàng (hệ thống kinh doanh) và các diễn viên chính của nó.

Sau khi các use case cơ bản đã được xác định trong lần cắt đầu tiên, có lẽ chúng ta có thể cấu trúc thêm các use case đó với các use case <<extend>> và <<include>> trong lần chỉnh sửa thứ hai như được hiển thị trong Hình dưới đây:

Use Case Kinh Doanh

Một use case kinh doanh được mô tả trong thuật ngữ không công nghệmà coi quy trình kinh doanh như một hộp đen và mô tả quy trình kinh doanh được sử dụng bởi các diễn viên kinh doanh của nó, trong khi một use case thông thường thường được mô tả ở mức mức độ chức năng của hệ thốngvà xác định chức năng hoặc dịch vụ mà hệ thống cung cấp cho người dùng. Nói cách khác, use case kinh doanh đại diện cho cách công việc được thực hiện thủ công trong tình huống hiện tại và không nhất thiết phải được thực hiện bởi hệ thống hoặc dự định được tự động hóa trong phạm vi hệ thống mục tiêu.

Cách xác định Diễn viên

Thường thì, mọi người thấy dễ dàng nhất để bắt đầu quá trình thu thập yêu cầu bằng cách xác định các diễn viên. Các câu hỏi sau đây có thể giúp bạn xác định các diễn viên của hệ thống của bạn (Schneider và Winters — 1998):

• Ai sử dụng hệ thống?
• Ai cài đặt hệ thống?
• Ai khởi động hệ thống?
• Ai bảo trì hệ thống?
• Ai tắt hệ thống?
• Hệ thống nào khác sử dụng hệ thống này?
• Ai nhận thông tin từ hệ thống này?
• Ai cung cấp thông tin cho hệ thống?
• Có điều gì xảy ra tự động vào thời điểm hiện tại không?

Cách xác định Use Cases?

Xác định các Use Cases, và sau đó quá trình thu thập dựa trên kịch bản tiếp tục bằng cách hỏi giá trị nào có thể nhìn thấy, quan sát được mà mỗi diễn viên mong muốn. Các câu hỏi sau đây có thể được đặt ra để xác định các use case, khi các diễn viên của bạn đã được xác định (Schneider và Winters — 1998):

• Diễn viên sẽ muốn những chức năng gì từ hệ thống?
• Hệ thống có lưu trữ thông tin không? Diễn viên nào sẽ tạo, đọc, cập nhật hoặc xóa thông tin này?
• Hệ thống có cần thông báo cho một diễn viên về những thay đổi trong trạng thái nội bộ không?
• Có sự kiện bên ngoài nào mà hệ thống phải biết không? Diễn viên nào thông báo cho hệ thống về những sự kiện đó?

Mẹo về Biểu đồ Use Case

Bây giờ, hãy kiểm tra các mẹo dưới đây để xem cách áp dụng use case một cách hiệu quả trong dự án phần mềm của bạn.

• Luôn cấu trúc và tổ chức biểu đồ use case từ góc độ của các diễn viên.
• Các use case nên bắt đầu đơn giản và ở mức độ cao nhất có thể. Chỉ khi đó chúng mới có thể được tinh chỉnh và chi tiết hơn.
• Các biểu đồ use case dựa trên chức năng và do đó nên tập trung vào “cái gì” chứ không phải “như thế nào”.

Mức độ chi tiết của Use Case

Độ chi tiết của trường hợp sử dụng đề cập đến cách mà thông tin được tổ chức trong các đặc tả trường hợp sử dụng, và ở một mức độ nào đó, mức độ chi tiết mà chúng được viết. Đạt được mức độ chi tiết đúng của trường hợp sử dụng giúp dễ dàng giao tiếp giữa các bên liên quan và các nhà phát triển, đồng thời cải thiện kế hoạch dự án.

Alastair Cockburn trong Viết các trường hợp sử dụng hiệu quả cung cấp cho chúng ta một cách dễ dàng để hình dung các mức độ khác nhau của mục tiêu bằng cách suy nghĩ theo cách của biển:

Lưu ý rằng:

• Trong khi một trường hợp sử dụng có thể đi sâu vào nhiều chi tiết về mọi khả năng, một sơ đồ trường hợp sử dụng thường được sử dụng để có cái nhìn tổng quan hơn về hệ thống như các bản thiết kế.
• Có lợi khi viết các trường hợp sử dụng ở mức độ chi tiết thô hơn với ít chi tiết hơn khi không cần thiết.

Tôi hy vọng bạn có thể trả lời “sơ đồ trường hợp sử dụng là gì” bây giờ và có thể áp dụng trường hợp sử dụng trong dự án của bạn. Nếu bạn muốn tìm hiểu thêm về các loại sơ đồ UML khác, vui lòng kiểm tra hướng dẫn UML: Tổng quan về 14 loại sơ đồ UML.

Chỉ hiển thị sơ đồ trường hợp sử dụng trong UML ký hiệu 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 cũng như chức năng nào được thực hiện khi một trường hợp sử dụng được thực thi.

Đặc tả trường hợp sử dụng thường được tạo ra trong giai đoạn phân tích và thiết kế theo cách lặp đi lặp lại.

• Ban đầu, chỉ có một mô tả ngắn gọn về các bước cần thiết để thực hiện luồng bình thường của trường hợp sử dụng (tức là, chức năng nào được cung cấp bởi trường hợp sử dụng) được viết.
• Khi phân tích tiến triển, các bước được phát triển để thêm nhiều chi tiết hơn.
• Cuối cùng, các luồng ngoại lệ được thêm vào trường hợp sử dụng
• Mỗi dự án có thể áp dụng một mẫu trường hợp sử dụng tiêu chuẩn để tạo ra đặc tả trường hợp sử dụng.

Trường hợp sử dụng so với đặc tả trường hợp sử dụng

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 tác nhân mang lại kết quả có giá trị kinh doanh cho một doanh nghiệp. Một trường hợp sử dụng có thể được hình dung dưới dạng sơ đồ trường hợp sử dụng hoặc/ và ở định dạng đặc tả văn bản có cấu trúc:

Trường hợp sử dụng (nhiệm vụ — một khách hàng muốn thực hiện) có thể là:

• Tương tác — Một trường hợp sử dụng hệ thống mô tả sự tương tác của một tác nhân với một hệ thống nhằm đạt được mục tiêu kinh doanh đã định
• Thủ công — Một chuỗi các hành động được thực hiện bởi một tác nhân
• Tự động — Một chuỗi các bước được thực hiện bởi một chương trình hoặc kịch bản

Đặc điểm của các trường hợp sử dụng

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ể

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

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

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

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

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

Cách tiếp cận trường hợp sử dụng linh hoạt

Mô hình trường hợp sử dụng và các trường hợp sử dụng riêng lẻ của nó phát triển theo từng cấp độ theo thời gian. Không phải tất cả các trường hợp sử dụng của một mô hình đều cần phải được chỉ định ở cùng một mức độ chi tiết.

Kịp thời và Đủ

Các trường hợp sử dụng có thể được viết ở các mức độ dữ liệu và phạm vi khác nhau, mỗi cái phục vụ một mục đích:

• Tóm tắt: Mô tả tổng quát và cái nhìn tổng quan về chức năng hệ thống hoặc quy trình kinh doanh.
• Cấp độ người dùng: Mô tả liên quan đến nhiệm vụ của người dùng và cách họ tương tác với hệ thống; mô tả một quy trình kinh doanh cụ thể. Các trường hợp sử dụng cấp độ người dùng thường được coi là ở mức độ nhiệm vụ chính của người dùng.
• Chức năng phụ: Mô tả các hoạt động cấp thấp hơn được sử dụng để hoàn thành các phần phụ của một trường hợp sử dụng cốt lõi.

Lưu ý: Một số trường hợp sử dụng có thể được chỉ định đủ đến cấp độ II. Bạn dừng lại khi đạt được đủ chi tiết bằng cách kịp thời và đủ.

Một đặc tả trường hợp sử dụng chi tiết

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