Usecase: là chức năng nhỏ nhất của ứng dụng hoặc là nghiệp vụ của một hệ thống nào đó và được sử dụng bới 1 actor hoặc một nhóm actor. Mô tả hoạt động của usecase thì người ta thường dùng Workflow hoặc mô hình activity, uml,v..v
1. Use là gì
-
Use case là đối tượng người dùng muốn nhận được từ hệ thống. Nó được đặt tên giống Động từ hoặc Động từ + cụm danh từ. Tên Use case thường ngắn gọn, rõ ràng, cụ thể và miêu tả đủ nghĩa của đối tượng người dùng. Những động từ như “do”, “perform”, các danh từ như ”data”, “information” nên tránh nếu có thể.
-
Người dùng sử dụng Use case để đại diện cho các nghiệp vụ trong hệ thống. Lấy “hệ thống đặt khách sạn trực tuyến” làm ví dụ: thì chức năng “Đặt phòng” là một Use case rõ ràng nhất mà người dùng muốn nhận được từ hệ thống. Chức năng ”tìm kiếm” khách sạn trên bản đồ trực tuyến cũng có thể là chức năng mà người dùng cần, tuy nhiên nó không phải là một Use case vì nó cũng chỉ là một phần của quá trình xử lí đặt phòng thay vì một đối tượng.
-
Một vài phân tích cố gắng tạo ra Use case để diễn tả yêu cầu người dùng như hỗ trợ nhiều Look and feel, load in background, ready server, construct database … Tất cả chúng đều sai và sẽ không giúp bạn xác định được đối tượng người dùng muốn nhận về, do dó chức năng của hệ thống có thể được giải phóng.
2. Các thành phần của user case
A. Actor
-
Actor được dùng để chỉ người sử dụng hoặc một đối tượng nào đó bên ngoài tương tác với hệ thống chúng ta đang xem xét. Lưu ý, chúng ta hay bỏ quên đối tượng tương tác với hệ thống, ví dụ như Bank ở trên.
-
Để nhận diện các Actor, trả lời các câu hỏi sau:
+/ Ai sẽ sử dụng những chức năng chính của hệ thống (tác nhân chính)?
+/ Ai sẽ cần sự hỗ trợ của hệ thống để thực hiện những tác vụ hàng ngày của họ?
+/ Ai sẽ cần bảo trì, quản trị và đảm bảo cho hệ thống hoạt động (tác nhân phụ)?
+/ Hệ thống sẽ phải xử lý và làm việc với những trang thiết bị phần cứng nào?
+/ Hệ thống cần phải tương tác với các hệ thống khác nào? Nhóm các hệ thống này được chia ra làm hai nhóm, nhóm kích hoạt cho mối quan hệ với hệ thống, và nhóm mà hệ thống cần phải xây dựng của chúng ta sẽ thiết lập quan hệ. Khái niệm hệ thống bao gồm cả các hệ thống máy tính khác cũng như các ứng dụng khác trong chính chiếc máy tính mà hệ thống này sẽ hoạt động. +/ Ai hay cái gì quan tâm đến kết quả (giá trị) mà hệ thống sẽ sản sinh ra?
B. Use Case
-
Use Case là chức năng mà các Actor sẽ sử dụng.
-
Để 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:
+/ Actor này cần những chức năng nào từ hệ thống? Hành động chính của Actor là gì ?.
+/ Actor có cần phải đọc, phải tạo, phải hủy bỏ, phải sửa chữa, hay là lưu trữ một loại thông tin nào đó trong hệ thống?
+/ Actor có cần phải báo cho hệ thống biết về những sự kiện nào đó? Những sự kiện như thế sẽ đại diện cho những chức năng nào?
+/ Hệ thống có cần phải thông báo cho Actor về những thay đổi bất ngờ trong nội bộ hệ thống?
+/ Công việc hàng ngày của Actor có thể được đơn giản hóa hoặc hữu hiệu hóa qua các chức năng mới trong hệ thống (thường đây là những chức năng tiêu biểu chưa được tự động hóa trong hệ thống)?
+/ Use Case có thể được gây ra bởi các sự kiện nào khác?
+/ Hệ thống cần những thông tin đầu vào/đầu ra nào? Những thông tin đầu vào/đầu ra đó từ đâu tới và sẽ đi đâu?
+/ Khó khăn và thiếu hụt chính trong hệ thống hiện thời nằm ở đâu (thủ công /tự động hóa)?
C. Các quan hệ trong Use Case
-
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.
-
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.
-
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»
3. Các giai đoạn xây dựng một Use Case Diagram
-
Giai đoạn mô hình hóa:
+/ Bước 1: Thiết lập ngữ cảnh của hệ thống đích. +/ Bước 2: Chỉ định các Actor.
+/ Bước 3: Chỉ định các Use Case.
+/ Bước 4: Định nghĩa các quan hệ giữa các Actor và các Use Case.
+/ Bước 5: Đánh giá các Actor và các Use Case để tìm cách chi tiết hóa.
-
Giai đoạn cấu trúc:
+/ Bước 6: Đánh giá các Use Case cho quan hệ phụ thuộc «include».
+/ Bước 7: Đánh giá các Use Case cho quan hệ phụ thuộc «extend».
+/ Bước 8: Đánh giá các Use Case cho quan hệ generalizations.
-
Giai đoạn review: Sau khi định nghĩa Use Case, cần tiến hành thử nghiệm Use Case:
+/ Kiểm tra (verification): đảm bảo là hệ thống đã được phát triển đúng đắn và phù hợp với các đặc tả đã được tạo ra.
+/ Phê chuẩn (validation): đảm bảo rằng hệ thống sẽ được phát triển chính là thứ mà khách hàng hoặc người sử dụng cuối thật sự cần đến.
+/ 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).
Trên đây, là một số lý thuyết cơ bản khi thực hiện xác định các use case của một hệ thống. Đối với Tester, việc xác định các use case rõ ràng là một sự cần thiết.