Use Case Là Gì? Bí Quyết để Xây Dựng 1 Sơ đồ Use Case Hoàn Hảo

Use Case là gì là từ khóa mà Google trả ra tới 3.200.000 kết quả chỉ sau 0.5 giây. Theo lý thuyết, phân tích Use Case là kỹ thuật giúp mô hình hóa các yêu cầu của hệ thống phần mềm. Một mô hình Use Case tốt sẽ mô tả hệ thống 1 cách trực quan và dễ hiểu nhất cho mọi đối tượng sử dụng. Để biết Use Case là gì và làm thế nào để xây dựng một sơ đồ Use Case hiệu quả, cùng tham khảo ngay!

Use Case là gì là câu hỏi được nhiều người dùng quan tâm

Mục lục

• 1 Giải đáp: Use Case là gì?
• 2 Các thành phần của Use Case là gì?
  • 2.1 Actor
  • 2.2 Use Case, Communication Link, Boundary of System
  • 2.3 Relationship
• 3 Cách xây dựng một Use Case Diagram hoàn chỉnh
  • 3.1 Giai đoạn mô hình hóa:
  • 3.2 Giai đoạn cấu trúc:
  • 3.3 Giai đoạn review:
• 4 Điểm mặt những sai lầm cần lưu ý khi thiết kế Use Case Diagram

Giải đáp: Use Case là gì?

Theo lý thuyết: Use Case là kỹ thuật mô tả sự tương tác giữa người dùng và hệ thống (trong 1 môi trường cụ thể, vì 1 mục đích cụ thể). Sự tương tác này có thể là:

• Cách thức mà người dùng tương tác với hệ thống;
• Cách thức mà hệ thống tương tác với các hệ thống khác.

Tất nhiên, sự tương tác này cần phải nằm trong một môi trường cụ thể – tức là nằm trong 1 bối cảnh, phạm vi cụ thể hoặc mở rộng ra là trong 1 hệ thống (phần mềm) cụ thể. Mục đích của Use Case là gì? Đó là phải diễn tả được yêu cầu theo góc nhìn cụ thể từ phía người dùng.

Use Case giống như một sơ đồ mô tả sự tương tác giữa các bên

Tên của Use Case được đặt ngắn gọn, rõ ràng, miêu tả đủ nghĩa đối tượng người dùng. 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 sử dụng. Tuy nhiên, chức năng “tìm kiếm” đây không phải là một Use Case vì nó chỉ là một phần của quá trình xử lý đặt vé.

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

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

Các thành phần của Use Case là gì?

Nếu thắc mắc sơ đồ Use Case là gì thì nội dung này sẽ cho bạn đáp án chính xác. Các thành phần của Use Case bao gồm:

Các thành phần cơ bản của Use Case là gì?

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.

Actor – thành phần quan trọng nhất

Để xác nhận đó có phải là Actor hay không thì cần xét trên 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 hệ thống hỗ trợ để thực hiện các 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?

Use Case, Communication Link, Boundary of System

Use Case là gì? Đây 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 cần 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? Actor có hành động chính 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?

Sự tương tác và phạm vi của Use Case

Communication Link thể hiện sự tương tác giữa người dùng (Actor) và hệ thống (System), nó kết nối giữa Actor và Use Case. Boundary of System chính là phạm vi mà Use Case xảy ra. Ví dụ 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 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ệ Include với Use Case B thì đ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. 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 (Use Case A) xảy ra thì Use Case xác thực tài khoản (Use Case B) phải hoàn thành. Đây là ví dụ hoàn hảo cho mối quan hệ Include.

Mối quan hệ Include và Extend được diễn tả trong sơ đồ Use Case

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 lựa chọn 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 (Use Case B) sẽ có mối quan hệ Extend với Use Case đăng nhập hệ thống (Use Case A). 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.

Ví dụ về mối quan hệ Generalization theo phương thức thanh toán

Tham khảo thêm các ví dụ dưới đây để hiểu chi tiết hơn nhé! Ví dụ về mối quan hệ cha – con giữa các Use Case là gì:

• Đăng nhập (cha): Có thể thông qua số điện thoại (con) hoặc Email (con).
• Đặt hàng (cha): Có đặt hàng qua số điện thoại (con) hoặc website (con).
• Thanh toán (cha): Có thể thông qua thẻ ATM (con), thẻ thanh toán quốc tế (con) hay các ví điện tử (con).
• Tìm kiếm (cha): Có thể qua từ khóa (con) hoặc theo nhóm sản phẩm (con).

Ví dụ về mối quan hệ cha – con giữa các Actor:

• Khách hàng (cha): Gồm khách hàng cũ (con) và khách hàng mới (con).

Nhìn chung, Generalization sẽ 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

Đến đây, chắc hẳn bạn đọc đã hiểu Use Case là gì. Và để xây dựng được một sơ đồ Use Case hoàn chỉnh cần trải qua nhiều giai đoạn với các bước sau:

Ví dụ về một Use Case Diagram hoàn hảo

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

• Bước 1: Thực hiện 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. Để biết những sai lầm thường gặp khi xây dựng Use Case là gì, cách khắc phục như thế nào, các bạn nên lưu tâm:

Tô màu cho Use Case Diagram để sơ đồ rõ ràng hơn

• Đặ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à lý do bạn tránh đặt tên quá dài;
• 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;
• Thiết kế quá nhiều Use Case: Là một sai lầm nhiều người mắc phải. 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. Để giải quyết, bạn có thể thử thêm 1 dòng note trước đoạn mô tả Use Case của tài liệu hoặc 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 cùng kích cỡ, đánh dấu các Use Case ID, không được chồng chéo các mối quan hệ, có thể tô màu lên Use Case,… để sơ đồ rõ ràng, mạch lạc hơn.

Những thông tin chia sẻ trên đây hy vọng sẽ giúp bạn đọc nắm được Use Case là gì và nắm được bí quyết xây dựng một sơ đồ Use Case hoàn hảo. Và nếu yêu thích các thủ thuật công nghệ hữu ích, hãy tiếp tục đồng hành cùng ITNavi bạn nhé!