(Post 07/03/2006) Một Use Case là một đơn vị công việc riêng lẻ. Nó cung cấp một cái nhìn cấp cao của người ngoài hệ thống về một hành vi có thể nhận thấy được của hệ thống. Ký hiệu mô tả một Use Case là một hình ellipse. Ví dụ Use Case Perform ATM Transaction (Thực hiện giao dịch với máy rút tiền tự động ATM).

I. Use Case Model (mô hình trường hợp sử dụng)

Mô hình Use Case là một kỹ thuật được sử dụng để miêu tả những yêu cầu mang tính chức năng của một hệ thống. Tài nguyên của một mô hình Use Case bao gồm:

II. Các thành phần trong một Use Case Diagram

Một Use Case Diagram trình bày sự tương tác giữa hệ thống và những tác nhân bên ngoài hệ thống, thường được gọi là "mục lục" các yêu cầu chức năng của hệ thống.

Actors (tác nhân)

Các thực thể bên ngoài này được tham chiếu đến như các Actor. Actor giữ vai trò người dùng hệ thống, phần cứng hoặc các hệ thống khác bên ngoài. Một Actor thường được vẽ như hình một người (hình trái), hoặc cách khác, giống như hình chữ nhật mô tả lớp với stereotype «actor» (hình giữa). Một thực thể Actor (Actor Instance) chỉ một Actor cụ thể của lớp Actor đó (hình phải).

Actor này có thể sinh ra Actor khác (Actor Generalization) như trong diagram sau:

Hình dưới là một trường hợp nên sử dụng Actor Generalization: diagram bên trái gây cảm giác Use Case Lookup Customer tương tác với hai Actor khác nhau khi nó thực thi, diagram bên phải phân lớp Actor đến Use Case rõ ràng hơn.

Để nhận diện các Actor, trả lời các câu hỏi sau:

Use Case (trường hợp sử dụng)

Một Use Case là một đơn vị công việc riêng lẻ. Nó cung cấp một cái nhìn cấp cao của người ngoài hệ thống về một hành vi có thể nhận thấy được của hệ thống. Ký hiệu mô tả một Use Case là một hình ellipse. Ví dụ Use Case Perform ATM Transaction (Thực hiện giao dịch với máy rút tiền tự động ATM).

Để tìm các Use Case, bắt đầu với các Actor được xác định trước, trả lời các câu hỏi sau:

Ký hiệu cho việc sử dụng một Use Case là một đường kết nối với đầu mũi tên (tùy chọn) trình bày hướng điều khiển. Diagram sau chỉ rằng Actor Customer (Khách hàng) dùng Use Case Withdraw (Rút tiền).

Dùng đường kết nối có thể có hoặc không các trị chỉ số lượng (Multiplicity) tại các đầu cuối, như trong diagram sau trình bày một Customer chỉ có thể có một lần phiên giao dịch Withdraw tại một thời điểm, nhưng một nhà Bank có thể có một số lượng bất kỳ Customer cùng thực hiện Withdraw đồng thời.

System Boundary (khung hệ thống)

Các Use Case thường được bao trong một khung chữ nhật biểu thị hệ thống (System Boundary). Khi đó Uses Case đặt bên trong hệ thống và Actor đặt bên ngoài hệ thống. Ví dụ: Use Case Withdraw là một chức năng của hệ thống con («subsystem») ATM.

III. Use Case Narrative (tường thuật Use Case)

Use Case Narrative (còn gọi là Stories) là một bảng mô tả thông tin chi tiết cho một Use Case Diagram.
Bảng dưới là Use Case Narrative của Use Case Diagram ngay phía trên bảng.

Requirements (yêu cầu)

Requirement định nghĩa các yêu cầu chức năng một cách hình thức mà một use case phải cung cấp đến người dùng cuối. Chúng tương ứng với các đặc tả chức năng tìm thấy sau khi phân tích hệ thống. Một requirement là một giao ước mà Use Case sẽ thực hiện một hành động để đáp ứng.

Constraints (ràng buộc)

Một Constraint là một điều kiện hoặc giới hạn mà Use Case hoạt động dưới nó. Bao gồm: tiền điều kiện, hậu điều kiện và điều kiện bất biến. Một tiền điều kiện (precondition) chỉ định các điều kiện cần có trước khi Use Case có thể tiến hành. Một hậu điều kiện (post condition) dùng để mô tả thay đổi điều kiện phải là đúng (true) sau khi thực thi Use Case. Một điều kiện bất biến (invariant condition) chỉ định điều kiện phải là đúng (true) trong lúc thực thi Use Case.

IV. Use Case Scenarios (kịch bản)

Một Scenario (còn gọi là Use Case Variation – Biến thể Use Case) là một mô tả hình thức dòng các sự kiện sẽ xuất hiện trong khi thực thi một Use Case. Nói cách khác, mỗi kết quả có thể trong việc thử thực hiện trọn vẹn một Use Case gọi là một scenario. Như vậy, scenario định nghĩa những gì sẽ xảy ra với điều kiện trong tập điều kiện mà Use Case phải giải quyết.

V. Các quan hệ trong Use Case Diagram

Use Case «include»

Một Use Case (gọi là base Use Case) có thể chứa («include») chức năng của một Use Case khác (gọi là inclusion Use Case) như một phần xử lý của nó. Nói chung, nó giả sử rằng mọi Use Case «include» sẽ được gọi mỗi khi tuyến Use Case chính chạy. Quan hệ này còn gọi là quan hệ sử dụng «uses». Ví dụ, việc thực thi Use Case Card Identification (Xác nhận thẻ) là một phần của Use Case Withdraw (Rút tiền). Khi thực thi Use Case Withdraw, Use Case Card Identification sẽ được gọi.

Một Use Case có thể bao gồm một hoặc nhiều Use Case khác, giúp thu giảm mức độ trùng lặp chức năng bằng cách gom các hành vi chung nhóm vào một Use Case.

Hình dưới mô tả việc chuyển một Use Case với các hành vi chung (trái) thành các quan hệ phụ thuộc «include» (phải).

Use Case «extend»

Một Use Case mở rộng (gọi là extension Use Case) có thể được mở rộng («extend») hành vi từ một Use Case khác (gọi là base Use Case); điều này thường dùng cho các trường hợp tùy chọn, ngoại lệ, chèn thêm vào … Ví dụ, nếu trước khi thay đổi một kiểu đặt hàng cụ thể (Modify Order), người dùng có thể phải nhận được sự chấp thuận (Get Approval) từ cấp phân quyền cao hơn, thì Use Case Get Approval có thể tùy chọn mở rộng («extend») Use Case Modify Order thông thường.

Hình dưới mô tả việc chuyển một Use Case với các hành vi tùy chọn (trái) thành các quan hệ phụ thuộc «extend» (phải).

Extension Points (Điểm mở rộng)

Trong quan hệ «extend», vị trí trên base Use Case mà tại đó một extension Use Case có thể chèn thêm vào gọi là điểm mở rộng. Thường kèm theo các điều kiện trước, sau, trong lúc… mở rộng đến extension Use Case. Ví dụ: Khi thực hiện Use Case Perform Transaction, khách hàng có thể tùy chọn thực thi Use Case On-Line Help. Vì vậy Use Case On-Line Help là «extend» của Perform Transaction. Điều kiện trước để "đến được" điểm mở rộng này là khách hàng phải chọn mục HELP.

Use Case Generalizations

Một quan hệ generalization có giữa một Use Case cụ thể hơn (specifilized) đến với một Use Case tổng quát hơn (generalized). Một generalized có thể cụ thể hóa thành nhiều specifilized, một specifilized cũng có thể được cụ thể hóa từ nhiều generalized. Một quan hệ generalization giữa các Use Case trình bày thành một đường đặc từ specifilized đến generalized, với đầu mũi tên là một tam giác rỗng chỉ generalized. Tránh nhằm lẫn với quan hệ phụ thuộc «extend».

Hình dưới mô tả việc chuyển một Use Case với các hành vi tương tự (trái) thành quan hệ generalization (phải).

Ngoài 3 quan hệ trên, tránh kết nối khác giữa các Use Case, nghĩa là một Use Case không thể được điều khiển, kích hoạt, … từ một Use Case khác.

VI. Các giai đoạn xây dựng một Use Case Diagram

Giai đoạn mô hình hóa:

Giai đoạn cấu trúc:

Giai đoạn review:

Sau khi định nghĩa Use Case, cần tiến hành thử nghiệm Use Case:

Một trong những kỹ thuật hữu dụng được dùng trong cả giai đoạn định nghĩa lẫn thử nghiệm Use Case gọi là walk-throughs with use-case storyboards (đi bộ dọc Use Case).

VII. Một ví dụ về Use Case

Dương Thiên Tứ - Faculty FPT-Aptech