1. Định nghĩaLà một khối chức năng được thực hiện bởi hệ thống để mang lại một kết quả có giá trị đối với một actor nào đó.
2. Mô tảUse case mô tả sự tương tác đặc trưng giữa người dùng và hệ thống. Nó thể hiện ứng xử của hệ thống đối với bên ngoài, trong một hoàn cảnh nhất định, xét từ quan điểm của người sử dụng. Nó mô tả các yêu cầu đối với hệ thống, có nghĩa là những gì hệ thống phải làm chứ không phải mô tả hệ thống làm như thế nào. Tập hợp tất cả Use case của hệ thống sẽ mô tả tất cả các trường hợp mà hệ thống có thể được sử dụng.
Một Use case có thể có những biến thể. Mỗi một biến thể được gọi là một kịch bản (scenario). Phạm vi của một Use case thường được giới hạn bởi các hoạt động mà người dùng thực hiện trên hệ thống trong một chu kì hoạt động để thực hiện một sự kiện nghiệp vụ.
Một Use case mô tả một nghiệp vụ thông thường. Nghiệp vụ này bao gồm các bước riêng rẽ, còn được gọi là các hoạt động. Khi các bước được mô tả dưới dạng văn bản thì việc chỉ ra sự phụ thuộc giữa các bước là một việc mất nhiều thời gian. Việc thể hiện các bước dưới dạng kí hiệu là dễ dàng và dễ hiểu hơn. Do đó Use case thường được mô tả chi tiết thông qua các biểu đồ mô tả hành vi (behavior) như biểu đồ hoạt động (activity diagram), biểu đồ trình tự (sequence diagram), biểu đồ hợp tác(collaboration diagram).
Use case cũng có thể được mô tả thông qua các thiết kế nguyên mẫu màn hình, các ví dụ về biểu mẫu báo cáo. Điều này giúp cho người dùng dễ dàng mường tượng hệ thống sẽ làm việc như thế nào, qua đó có thể kiểm tra tính đúng đắn của Use case.
Các câu hỏi thường được sử dụng để xác định Use Case cho một hệ thống là:
* Nhiệm vụ của mỗi actor là gì?
* Có actor nào sẽ tạo, lưu trữ, thay đổi, xóa hoặc đọc thông tin trong hệ thống?
* Có actor nào cần báo tin cho hệ thống về một thay đổi đột ngột từ bên ngoài?
* Có actor nào cần được thông báo về một sự việc cụ thể xảy ra trong hệ thống?
* Trường hợp sử dụng nào sẽ hỗ trợ và bảo trì hệ thống?
* Tất cả các yêu cầu về mặt chức năng có được thể hiện hết thông qua các trường hợp sử dụng chưa?
Điều gì tạo nên một Use Case tốt
Có một câu hỏi thường xuyên được đặt ra về mức độ chi tiết của Use case. Nó nên ở mức độ nào là tốt. Có lẽ không có câu trả lời hoàn toàn đúng, nhưng có một số nhận xét như sau: "Một Use case thường biểu hiện một chức năng được thực hiện trọn vẹn (không ngắt quãng) từ đầu đến cuối. Một Use case phải mang lại một điều gì đó có giá trị đối với actor".
Mô tả Use case
Use case cần có một vài câu ngắn gọn mô tả mục đích của Use case, cho ta biết chức năng do Use case cung cấp.
3. Kí hiệuMột Use case được thể hiện bởi một hình ellip kèm theo tên của Use case. Ngoài ra còn có thể có thêm các chú thích để mô tả chi tiết hơn về ý nghĩa của Use case. Mỗi Use case trong hệ thống có tên phân biệt duy nhất. Use case có thể được đánh số để thuận tiện cho việc tra cứu nhanh trên biểu đồ hoặc trong tài liệu mô tả.
Ví dụ:
4. Luồng sự kiện cho một Use case (The Flow of events)Use case chỉ cung cấp một khung nhìn ở mức cao, tổng quát. Để hiểu rõ hơn hệ thống cần phải làm gì thì cần phải mô tả chi tiết hơn, gọi là luồng sự kiện. Nó là một tài liệu mô tả các hoạt động cần thiết để đạt được ứng xử mong đợi của Use case.
Tuy là mô tả chi tiết nhưng luồng sự kiện vẫn được viết sao cho có thể chỉ ra những gì hệ thống cần làm chứ không phải chỉ ra hệ thống làm như thế nào.
Ví dụ: trong luồng sự kiện chúng ta nói “Kiểm tra mã của người dùng” chứ không nói rằng việc đó phải thực hiện bằng cách xem xét ở trong một bảng nào đó trong cơ sở dữ liệu. Nó mô tả chi tiết những gì người dùng của hệ thống sẽ làm và những gì hệ thống sẽ làm. Nó cần phải đề cập tới:
* Use case bắt đầu và kết thúc khi nào và như thế nào
* Có những sự tương tác nào giữa Use case và actor để thực hiện chức năng đó.
* Những dữ liệu nào cần thiết cho Use case
* Thứ tự thực hiện thông thường của các sự kiện
* Các mô tả về các luồng ngoại lệ hoặc rẽ nhánh.
Mỗi dự án cần có một mẫu chuẩn cho việc tạo tài liệu về luồng sự kiện. Có thể dùng theo mẫu đơn giản như sau:
* X. Luồng sự kiện cho Use case ABC
* X1. Điều kiện bắt đầu: danh sách những điều kiện phải thỏa mãn trước khi Use case được thực hiện. Ví dụ như: một Use case khác phải thực hiện trước khi Use case này được thực hiện hay người dùng phải có đủ quyền để thực hiện Use case này. Không nhất thiết mọi Use case đều phải có điều kiện bắt đầu.
* X2. Luồng chính: mô tả những bước chính sẽ xẩy ra khi thực hiện Use case.
* X3. Các luồng phụ( luồng con).
* X4. Các luồng rẽ nhánh.
Trong đó X là số thự tự của Use case trong hệ thống.
Ví dụ: Luồng sự kiện mô tả Use case cho hệ thống rút tiền tự động như sau:
1.1 Điều kiện bắt đầu.
1.2 Luồng chính:
1.2.1 Người dùng đưa thẻ vào máy.
1.2.2. Máy hiển thông báo chào mừng và yêu cầu nhập mã số
1.2.3 Người dùng nhập mã số
1.2.4 Máy xác nhận mã số đúng. Nếu nhập sai mã số, luồng rẽ nhánh E-1 được thực hiện.
1.2.5 Máy hiện ra ba lựa chọn:
* Rút tiền: luồng con A-1
* Chuyển tiền: luồng con A-2
* Thêm tiền vào tài khoản: luồng con A-3
1.2.6 Người dùng chọn rút tiền
1.3. Luồng con:
1.3.1 Luồng con A-1:
1.3.1.1 Máy hỏi số lượng tiền cần rút
1.3.1.2 Người dùng nhập số tiền cần rút
Máy kiểm tra trong tài khoản có đủ tiền không. Nếu không đủ luồng rẽ nhánh E-2 được thực hiện
....
1.4. Luồng rẽ nhánh:
1.4.1 E-1: Người dùng nhập sai mã số
Máy thông báo là người dùng đã nhập sai mã số yêu cầu người dùng nhập lại hoặc hủy bỏ giao dịch.
1.4.2 E-2: Không đủ tiền trong tài khoản...
