Phân tích Use Case là kỹ thuật chính giúp mô hình hóa các yêu cầu chức năng của hệ thống phần mềm. Use Case có thể được mô tả dưới dạng văn bản hoặc sơ đồ quan hệ (diagram). Một mô hình Use Case được đánh giá tốt khi nó mô tả hệ thống một cách trực quan, dễ hiểu nhất cho mọi đối tượng sử dụng. Vậy Use Case là gì, làm thế nào để thiết kế được mô hình Use Case hiệu quả? Cùng giải đáp ngay những thắc mắc này tại bài viết bên dưới nhé!

Use Case là gì?

Use Case là gì?

“Use Case là kỹ thuật dùng để mô tả sự tương tác giữa người dùng và hệ thống trong một môi trường cụ thể và vì một mục đích cụ thể.”

Use Case là đối tượng mà người dùng muốn nhận được từ hệ thống hoặc cách mà các hệ thống tương tác với nhau như thế nào. Sự tương tác này phải nằm trong một môi trường cụ thể, nghĩa là một bối cảnh, chức năng hay trong một hệ thống, phần mềm cụ thể. Việc mô tả sự tương tác này nhằm diễn đạt một mục đích nào đó và Use Case phải diễn đạt được yêu cầu theo góc nhìn cụ thể từ phía người dùng.

Tên của Use Case được đặt giống động từ hoặc động từ + cụm danh từ và thường được đặt ngắn gọn, rõ ràng, miêu tả đủ nghĩa đối tượng người dùng. Tuy nhiên nên tránh đặt tên với các động từ như “do”, “perform”, các danh từ “data”, “information”.

Người dùng sẽ sử dụng những Use Case để đại diện cho các nghiệp vụ của hệ thống. Ví dụ về “hệ thống đặt vé máy bay trực tuyến” thì chức năng “đặt vé” là một Use Case rõ ràng nhất của hệ thống mà người dùng muốn nhận được. Chức năng “tìm kiếm” vé trên hệ thống cũng có thể là chức năng được người dùng sử dụng, tuy nhiên đây không phải là một Use Case vì nó cũng là một phần của quá trình xử lý đặt vé thay vì một đối tượng.

Bạn đọc tham khảo thêm:

Việc làm java web lương cao chế độ hấp dẫn

Tuyển dụng php lương cao chế độ hấp dẫn

Các thành phần của Use Case

Những thành phần chính tạo nên Use Case và chức năng của chúng

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 với hệ thống.

Để xác nhận đó có phải là Actor hay không dựa vào câu trả lời của những câu hỏi sau:

• Ai là người sử dụng chức năng chính của hệ thống (tác nhân chính)?
• Ai sẽ là Admin của hệ thống – người cài đặt, quản lý và bảo trì hệ thống (tác nhân phụ)?
• 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?
• Hệ thống này có cần phải tương tác với các hệ thống nào khác không?
• 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)?
• Ai hay cái gì quan tâm đến giá trị mà hệ thống sẽ mang lại?

Actor thể hiện một đối tượng bên ngoài tương tác với hệ thống

Use Case, Communication Link, Boundary of System

Use Case là các chức năng mà các Actor sẽ sử dụng hay thể hiện sự tương tác giữa người dùng và hệ thống.

Để tìm ra được các Use Case, ta trả lời những câu hỏi sau:

• Actor cần những chức năng nào của hệ thống? Hành động chính của Actor là gì?
• Actor có cần đọc, thêm mới, hủy bỏ, chỉnh sửa hay lưu trữ loại thông tin nào trong hệ thống không?
• Hệ thống có cần thông báo những thay đổi bất ngờ trong nội bộ cho Actor 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 của hệ thống?
• Use Case có thể được 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 đó sẽ đi từ đâu đến đâu?
• Những khó khăn và thiếu hụt của hệ thống hiện tại nằm ở đâu?

Communication Link thể hiện sự tương tác giữa người dùng (Actor) và hệ thống (System), kết nối giữa Actor và Use Case.

Boundary of System là phạm vi mà Use Case xảy ra. Ví dụ đối với hệ thống CRM, phạm vi có thể là những cụm tính năng lớn như quản lý đơn hàng, quản lý khách hàng hoặc cả một module lớn như quản lý bán hàng.

Bạn đọc tham khảo thêm: Testcase là gì? Làm thế nào để tạo nên những biểu mẫu test case chất lượng?

Relationship

Relationship gồm 3 loại: Include, Extend, và Generalization.

Include, Extend, và Generalization là 3 relationship sử dụng để thiết kế Use Case Diagram

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. 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ệ với Use Case B, điều đó có nghĩa Use Case A bao gồm Use Case B. Để Use Case A xảy ra thì phải đạt được Use Case B.

Xét ví dụ: để rút được tiền trong thẻ, người dùng phải xác thực tài khoản. Chỉ khi xác thực tài khoản xong, 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 phải hoàn thành. Đó chính là mối quan hệ Include.

Extend

Extend biểu diễn mối quan hệ mở rộng giữa các Use Case với nhau. Nếu Include thể hiện 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.

Nếu Use Case B là Extend của Use Case A, điều này có nghĩa Use Case B chỉ là một optional chỉ xảy ra trong một hoàn cảnh cụ thể nào đó.

Ví dụ: khi bạn đăng nhập hệ thống, Use Case quên mật khẩu sẽ có mối quan hệ Extend với Use Case đăng nhập hệ thống. Bởi, Use Case quên mật khẩu chỉ là một Use Case có thể xảy ra hoặc không và nó có liên quan đến Use Case đăng nhập hệ thống chứ không phải bất kỳ một Use Case nào khác.

Generalization

Chúng ta có thể hiểu đơn giản Generalization là mối quan hệ cha con giữa các Use Case với nhau. Điểm khác biệt giữa Generalization với Include và Extend chính là khả năng thể hiện mối quan hệ giữa các Actor với nhau.

Tham khảo thêm các ví dụ dưới đây để hiểu chi tiết hơn nhé!

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

• Đăng nhập có thể thông qua số điện thoại hoặc Email.
• Đặt hàng có đặt hàng qua số điện thoại, website.
• Thanh toán thông qua thẻ ATM, thẻ thanh toán quốc tế hay các ví điện tử.
• Tìm kiếm có thể qua từ khóa hoặc 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à mới.
• Vendor thì có thể gồm Retailers và Wholesalers.

Nhìn chung, Generalization giúp chúng ta hiểu rõ hơn về các yêu cầu bằng các nhóm Use Case có quan hệ cha – con. Ngoài ra, Generalization còn có tính kế thừa tức cha có gì thì con có đó kể cả Use Case hay Actor.

Cách xây dựng một Use Case Diagram hoàn chỉnh

Để xây dựng được một Use Case hoàn chỉnh cần trải qua những giai đoạn với các bước sau:

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

• Bước 1: Thiết lập ngữ cảnh của hệ thống.
• Bước 2: Xác định các Actor.
• Bước 3: Xác định các Use Case.
• Bước 4: Định nghĩa các mối quan hệ giữa Actor và Use Case.
• Bước 5: Đánh giá các mối quan hệ đó để 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ệ Include.
• Bước 7: Đánh giá các Use Case cho quan hệ Extend.
• Bước 8: Đánh giá các Use Case cho quan hệ Generalization .

• Giai đoạn review:
• Kiểm tra (verification): đảm bảo hệ thống đúng với tài liệu đặc tả.
• Thẩm định (validation): đảm bảo hệ thống sẽ được phát triển là thứ mà khách hàng cuối thực sự cần thiết.

Điểm mặt những sai lầm cần lưu ý khi thiết kế Use Case Diagram

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, cần thiết kế sao cho đơn giản, chi tiết và dễ hiểu nhất. Dưới đây là một vài những sai lầm thường mắc phải khi xây dựng Use Case, các bạn nên lưu tâm:

Tránh thiết kế quá nhiều Use Case trong một Diagram, các mối quan hệ chồng chéo nhau

• Đặt tên: vì là mô hình hóa nên chúng ta cần dùng những hình ảnh để diễn đạt, cố gắng sử dụng số lượng chữ ít nhất. Do vậy, những gì được ghi trên diagram này phải thật cô đọng và có giá trị tức thì. Khi đặt tên nên tránh đặt quá dài và không nên dùng kiểu bị động.
• Không phân biệt được phân rã chức năng và Use Case: dấu hiệu thường thấy chính là đầy rẫy những từ “manage” (quản lý) trên sơ đồ. Use Case cần phải truyền tải được mục đích sau cùng và chứa đựng góc nhìn của End – Users.
• Thiết kế quá nhiều Use Case: không nên thiết kế quá nhiều Use Case trong một diagram. Bạn nên tận dụng các Relationship để khiến các Use Case không quá rời rạc, tạo sự logic và sử dụng Boundary of System để phân nhóm, giới hạn các Use Case.
• Quá chi tiết các chức năng CRUD: mỗi thực thể là một lần CRUD, điều này tạo sự lặp đi lặp lại ở các Use Case Diagram nhưng không thể hiện được nhiều thông tin cho người xem.
• Thẩm mỹ: bạn thích tham khảo một sơ đồ gọn gàng, ưa nhìn hay một sơ đồ cẩu thả? Một sơ đồ Use Case được thiết kế hợp lý sẽ giúp thu hút sự tập trung của người dùng hơn. Bạn nên thiết kế các Use Case trong Diagram cùng kích cỡ, đánh dấu các Use Case ID, các mối quan hệ không được chồng chéo lẫn nhau,…

Trên đây là những kiến thức chia sẻ về Use Case là gì và làm thế nào để tạo dựng được một Use Case Diagram hoàn hảo nhất. Mà các bạn đừng quên nhé, ngoài biết cách thiết kế, các bạn cũng cần phải vẽ đúng, đẹp và tránh được những lỗi sai thường gặp ở trên nữa nha. Nếu bạn là người yêu thích công nghệ thông tin thì đừng quên ghé thăm trang web của chúng tôi thường xuyên để cập nhật những kiến thức bổ ích nhé.