5- BiỂu đỒ Use Case

Tóm tắt: Một biểu đồ Use Case thể hiện:

- Hệ thống

- Tác nhân

- Use Case.

Ví dụ biểu đồ Use Case trong UML:

Trong đó :

- Hệ thống được thể hiện qua hình chữ nhật với tên hệ thống ở bên trên

- Tác nhân được thể hiện qua kí hiệu hình nhân

- Use Case được thể hiện qua hình ellipse

5.1- Hệ thống:

Vì hệ thống là một thành phần của mô hình Use Case nên ranh giới của hệ thống mà ta muốn phát triển cần phải được định nghĩa rõ ràng.

5.2- Tác nhân:

Một tác nhân là một người hoặc một vật nào đó tương tác với hệ thống, sử dụng hệ thống. một tác nhân có thể là người mà cũng có thể là một hệ thống khác (ví dụ như là một chiếc máy tính khác được nối kết với hệ thống của chúng ta hoặc một loại trang thiết bị phần cứng nào đó tương tác với hệ thống).

Một tác nhân là một dạng thực thể (một lớp), chứ không phải một thực thể. Tác nhân mô tả và đại diện cho một vai trò, chứ không phải là một người sử dụng thật sự và cụ thể của hệ thống.  Một tác nhân sẽ có một tên, và cái tên này cần phải phản ánh lại vai trò của tác nhân.

Một tác nhân giao tiếp với hệ thống bằng cách gửi hoặc là nhận thông điệp

Tác nhân cũng có thể được xếp loại. Một tác nhân chính (Primary Actor) là tác nhân sử dụng những chức năng căn bản của hệ thống, tức là các chức năng chính. Một tác nhân phụ (secondary actor) là tác nhân sử dụng các chức nặng phụ của hệ thống, ví dụ như các chức năng bảo trì hệ thống như quản trị ngân hàng dữ liệu, giao tiếp, back-up và các tác vụ quản trị khác.

5.3- Tìm tác nhân:

Khi nhận diện tác nhân, có nghĩa là chúng ta lọc ra các thực thể đáng quan tâm theo khía cạnh sử dụng và tương tác với hệ thống. Sau đó chúng ta có thể thử đặt mình vào vị trí của tác nhân để cố gắng nhận ra các yêu cầu và đòi hỏi của tác nhân đối với hệ thống và xác định tác nhân cần những Use Case nào. Có thể nhận diện ra các tác nhân qua việc trả lời một số các câu hỏi như 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?

- Ai hay cái gì quan tâm đến kết quả (giá trị) mà hệ thống sẽ sản sinh ra?

Để có thể nhận dạng được tốt nhiều tác nhân khác nhau, hãy tiến hành nghiên cứu những người sử dụng của hệ thống hiện thời (một hệ thống thủ công hoặc một hệ thống đang tồn tại), hỏi xem họ đóng những vai trò nào khi thực thi công việc hàng ngày của họ với hệ thống. Cũng người sử dụng đó có thể thực thi nhiều vai trò khác nhau tại nhiều thời điểm khác nhau, tùy thuộc vào việc chức năng nào trong hệ thống đang được sử dụng.

5.5- Use Case:

Một Use Case là đại diện cho một chức năng nguyên vẹn mà một tác nhân nhận được. Một Use Case trong ngôn ngữ UML được định nghĩa là một tập hợp của các chuỗi hành động mà một hệ thống thực hiện để tạo ra một kết quả có thể quan sát được, tức là một giá trị đến với một tác nhân cụ thể. Những hành động này có thể bao gồm việc giao tiếp với một loạt các tác nhân cũng như thực hiện tính toán và công việc nội bộ bên trong hệ thống.

Các tính chất tiêu biểu của một Use Case là:

- Một Use Case bao giờ cũng được gây ra bởi một tác nhân, được thực hiện nhân danh một tác nhân nào đó.

- Một Use Case phải cung cấp một giá trị cho một tác nhân. Giá trị đó không phải bao giờ cũng cần thiết phải nổi trội ra ngoài, nhưng luôn phải được thấy rõ.

- Một Use Case là phải hoàn tất.

5.6- Tìm Use Case:

Quá trình tìm các Use Case bắt đầu với các tác nhân đã được xác định ở phần trước. Đối với mỗi tác nhân, hãy hỏi các câu hỏi sau:

a. Tác nhân này cần những chức năng nào từ hệ thống? Hành động chính của tác nhân là gì ?.

b. Tác nhân 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?

Ví dụ :

- Nhân viên nhà băng liệu có quyền truy xuất hay thay đổi mức tiền lãi?

- Khách hàng có thể thay đổi password của mình.

c. Tác nhân 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?

Ví dụ :

- Khách hàng kết thúc tài khoản, nhân viên cung cấp những thông tin này cho hệ thống.

- Có một chương trình đầu tư mới, các chi tiết của chương trình này sẽ phải được nhân viên nhà băng nhập vào hệ thống.

d. 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?

- Trong tài khoản còn quá ít tiền.

- Ba kỳ liên tiếp tiền lương chưa đổ về tài khoản.

e. Công việc hàng ngày của tác nhân 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)?

f. Các câu hỏi khác:

- Use Case có thể được gây ra bởi các sự kiện nào khác?

Ví dụ :

Sự kiện thời gian: Cuối tháng, hết hạn đầu tư.

Sự kiện bình thường của hệ thống: Tự động chuyển tiền theo các lệnh xác định trước.

Các sự kiện bất bình thường: Hợp đồng đầu tư kết thúc trước thời hạn.

- 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)?

Đối với nhóm câu hỏi cuối không có nghĩa là Use Case ở đây không có tác nhân, mà tác nhân sẽ được nhận ra chỉ khi chúng ta nhận diện ra các Use Case này và sau đó xác định tác nhân dựa trên cơ sở là Use Case. Xin nhắc lại, một Use Case bao giờ cũng phải được liên kết với ít nhất một tác nhân.