Use case là gì? tìm hiểu về use case

Use case là gì? tìm hiểu về use case về các thành phần có trong một use case và cách để tạo ra chúng thông qua bài viết sau đây

1. Use case là gì?

Use case là một kỹ thuật được sử dụng trong kỹ thuật phần mềm và hệ thống để nắm bắt được các yêu cầu chức năng của hệ thống. Hoặc có thể nói Use case là kỹ thuật mô tả sự tương tác giữa người dùng và hệ thống trong một môi trường, vì một mục đích cụ thể. Sự tương tác này có thể là:

• Cách thức mà người dùng bên ngoài (actor) tương tác cùng một hệ thống.
• Cách thức mà hệ thống thống tương tác cùng các hệ thống khác.

[caption id="attachment_4137" align="aligncenter" width="600"] Use case là gì?[/caption]

Mỗi use case mô tả cách thức actor tương tác với hệ thống để đạt được mục tiêu nào đó. Mỗi use case có thể tạo ra được một hoặc nhiều kịch bản tương ứng với chi tiết về mỗi cách thức để đạt được mục tiêu nào đó.

Khi mô tả user case, người ta sẽ tránh dùng thuật ngữ kỹ thuật thay vào đó họ sử dụng ngôn ngữ của người dùng cuối hoặc chuyên gia về lĩnh vực đó. Tạo ra một user còn cần phải có sự hợp tác chặt chẽ giữa người phân tích hệ thống và người dùng cuối. Một trong những cách biểu diễn trực quan phổ biến hiện nay là lược đồ use case của UML.

2. Các thành phần của Use case

Actor

Actor được sử dụng để chỉ người dùng hoặc một đối tượng nào đó bên ngoài tương tác cùng với hệ thống. Để xác định được một actor đó có phải hay không, bạn cần xem xét qua những câu hỏi như sau:

• Ai là người sử dụng chức năng chính của hệ thống?
• Ai là admin của hệ thống, là người cài đặt, quản lý và bảo trì hệ thống,…?
• Ai là người sẽ cần hệ thống hỗ trợ để thực hiện các tác vụ hằng ngày?
• 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 là người input dữ liệu vào hệ thống (đối với hệ thống lưu trữ dữ liệu)?

User case

User case là chức năng mà các Actor sẽ sử dụng, để tìm các ra được các user ta phải trả lời được các câu hỏi như sau:

• Actor này cần những chức năng nào của hệ thống, hoạt động chính của actor là gì?
• Actor có cần phải tạo, phải đọc, 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 về những sự kiện nào đó không? Ngược lại 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 khô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?
• Use case có thể tạo ra bởi sự kiện nào khác không?
• Hệ thống cần những thông tin đầu vào/đầu ra nào? Những thông tin đó 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?

Các quan hệ trong Use case

Trong đó gồm có 3 loại: Include, Extend, và Generalization

Include

Include được định nghĩa là mối quan hệ bắt buộc phải có giữa các use case với nhau. Một Use case có thể chứa chức năng của một use case khác như một phần xử lý của nó. Xét về nghĩa, Include trong tiếng Anh nghĩa là bao gồm. Tức nếu nói Use Case A có mối quan hệ Include với Use Case B thì điều đó có nghĩa Use Case A bao gồm Use Case B.

Trên đây là một ví dụ:  Để rút được tiền trong thẻ, mọi người phải cần thông qua bước xác thực tài khoản. Chỉ khi xác thực được tài khoản bạn mới có thể rút được tiền trong thẻ, hay nói cách khác để Use case “rút tiền” xảy ra thì Use case “xác thực tài khoản” cần phải hoàn thành. Đây là mối quan hệ Include.

Extend

Extend được định nghĩa là mối quan hệ mở rộng giữa các Use case với nhau. Nếu đối với Include là mối quan hệ bắt buộc thì Extend lại là mối quan hệ không bắt buộc, có thể có hoặc không giữa các Use case với nhau. Một Use Case B là extend của Use Case A thì có nghĩa Use Case B chỉ là một thứ optional, và chỉ xảy ra trong một hoàn cảnh cụ thể nào đó.

Quan sát ví dụ sau đây:

Ở trong trường hợp này, Use case “ gửi tiền tip cho lái xe” là một Use case có quan hệ Extend đối với Use case “ đánh giá chuyến đi”. Tức là Use case “ gửi tiền tip cho lái xe” có thể xảy ra hoặc không xảy ra. Và nó chỉ liên quan đến Use case “ đánh giá chuyến đi” chứ không liên quan bất kỳ đến Use case nào khác.

Generalization

Generalization được hiểu đơn giản là mối quan hệ cha con giữa các Use case với nhau. Đây là điểm khác biệt nhất giữa Generalization với Include và Extend, chúng được dùng để thể hiện mối quan hệ giữa các Actor với nhau. Chúng được thể hiện qua ví dụ sau đây:

Mối quan hệ cha – con giữa các Use case

• Khi đăng nhập thì có thể đăng nhập qua số điện thoại hoặc đăng nhập qua email.
• Đặt hàng cũng có thể đặt qua điện thoại hoặc website.
• Thanh toán có thể thanh toán qua thẻ ATM, thẻ quốc tế, ví điện tử,…
• Tìm kiếm sản phẩm có thể tìm kiếm bằng từ khóa, theo nhóm sản phẩm,…

Mối quan hệ cha – con giữa các Actor

• Khách hàng gồm khách hàng cũ và khách hàng mới
• Hoặc Vendor thì có thể gồm Retailers và Wholesalers.

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ácActor 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 1: Đánh giá các Use Case cho quan hệ include

Bước 2: Đánh giá các Use Case cho quan hệ extend

Bước 3: Đánh giá các Use Case cho quan hệ Generalization

Giai đoạn review

Bước 1: Kiểm tra để đả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.

Bước 2: Phê chuẩn để đả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.

4. Những sai lầm hay gặp phải khi thiết kế Use Case

Sơ đồ Use Case là thứ thể hiện được những yêu cầu từ phía khách hàng, do vậy khi thiết chúng ta cần làm sao cho thật đơn giản mà vẫn đảm bảo chi tiết và dễ hiểu nhất. Dưới đây là những sai lầm mà các bạn khi thiết kế vẫn sẽ hay thường gặp phải nhất, vậy nên làm như thế nào để khắc phục?

Đặt tên không chuẩn

Vì là mô hình hóa nên cần diễn đạt bằng hình ảnh, cố gắng sử dụng ít chữ nhất có thể. Vì vậy, những gì được ghi trên Use Case Diagram phải thật cô đọng và có giá trị tức thì. Lưu ý dành cho bạn khắc phục chúng:

• Actor thì phải đặt tên bằng danh từ, không dùng động từ, và cũng không mệnh đề quan hệ gì hết.
• Tên Use Case thì phải ghi rõ ràng, rành mạch, đẹp nhất là dưới format: Verb + Noun.
• Tránh đặt tên quá dài và không nên dùng kiểu bị động.

Lẫn lộn giữa Use Case và phân rã chức năng

Sai lầm nhìn thấy ngay là những từ “quản lý” (manage) trên sơ đồ. Use Case cần truyền tải được mục đích sau cùng, chứa đựng góc nhìn của người dùng cuối cùng.

• End-users muốn làm gì? Nhằm mục đích gì? ==> tương tác giữa end-users và hệ thống
• Hệ thống phải nhận/ lấy data từ những nguồn nào? ==> tương tác giữa hệ thống với những hệ thống bên ngoài khác.

Thiết kế quá nhiều Use Case

Là một sai lầm nhiều người mắc phải ở những điểm như sau:

• Xác định sai Use Case (nên mới nhiều UC như vậy): những thứ như single, double, num of guest…
• Đặt tên Use Case sai: quá nhiều cụm danh từ cho Use Case.
• Không có Boundary of System.
• Những Use Case có extend không ghi chú cụ thể điều kiện khi nào thì UC extend xảy ra.

Bạn nên tận dụng các Relationship để khiến các Use Case liên kết với nhau, sau đó sử dụng Boundary of System để phân nhóm, giới hạn cho các Use Case

Quá đi sâu vào chi tiết các chức năng CRUD

Nếu sử dụng mỗi thực thể là 1 lần CRUD thì sẽ rất tốn công. Điều này cũng tạo sự lặp đi lặp lại ở các sơ đồ Use Case nhưng lại không thể hiện được nhiều thông tin cho người xem. Có hai cách để giải quyết, bạn có tham khảo:

• Thêm một dòng note trước đoạn mô tả Use Case trong tài liệu: “Toàn bộ dữ liệu đều có chức năng Thêm/ Đọc/ Sửa/ Xóa và chịu tác động bởi sự phân quyền từ phía Quản trị hệ thống” hoặc đại loại vậy. Để cho các stakeholder biết được rằng hệ thống có chức năng CRUD các dữ liệu này.
• Tạo hẳn 1 Use Case có tên là manage X với X là 1 đối tượng bất kỳ.

Thiếu thẩm mỹ

Nhiều sơ đồ Use Case khá thiếu thẩm mỹ, không có thiết kế hợp lý nên không thu hút được người dùng. Vì vậy, bạn cần chú ý thiết kế các Use Case trong Diagram như sau:

• Kích cỡ các Use Case trong Diagram là phải như nhau, kể cả cha-con, lẫn các mối quan hệ Include. Tuy nhiên, Use Case có Extend sẽ được vẽ to hơn một chút.
• Nhớ phải đánh dấu Use Case ID trong hình vẽ.
• Các mối quan hệ không được chồng chéo lẫn nhau. Anh em có thể vẽ 1 Actor ở 2 vị trí khác nhau để tránh các đường nối bắt chéo lên nhau.
• Khi vẽ Use Case Diagram, tập trung vào câu hỏi What để tìm ra Use Case, tránh câu hỏi How, vì khi đó anh em rất dễ đi vào detail.
• Và nếu được, hãy tô màu lên Use Case để nhìn Diagram được rõ ràng, sáng sủa và mạch lạc

>>> Xem thêm: Unit Test là gì? ứng dụng và vai trò