Ở kỳ trước "Tìm hiểu về Use Case Diagram trong UML" mình đã giải thích sơ qua về lý thuyết của Use Case Diagram. Trong kỳ này, chúng ta sẽ thực hành phân tích một số yêu cầu và vẽ thành một Use Case Diagram nho nhỏ nhé.
Xây dựng Use Case Diagram
Bước 1: Thu thập kiến thức liên quan đến hệ thống sẽ xây dựng
Trước hết, để phân tích hệ thống trên bạn phải có kiến thức về hệ thống thương mại điện tử, chúng ta có thể tìm hiểu thông qua các nguồn sau:
– Xem qua các forum
– Xem các hệ thống mẫu
– Hỏi những người chuyên về lĩnh vực này
Lưu ý: Bạn không thể thiết kế tốt được nếu bạn không có kiến thức về lĩnh vực của sản phẩm mà bạn sẽ xây dựng.
Bước 2: Xác định các Actor
Bạn hãy trả lời cho câu hỏi “Ai sử dụng hệ thống này?”
Xem xét Website chúng ta nhận thấy:
– Những người chỉ vào để đọc bài viết. Những người này là Người xem [Guest].
– Những người vào để đăng topic, bình luận,… v.v.. gọi là Thành viên [Member].
Về phía quản trị forum, có những người sau đây tham gia vào hệ thống:
– Mod: Quản lý các bài viết, đăng cảnh báo, xóa bài viết, tắt bình luận
– S-mod: Quản lý các bài viết, đăng cảnh báo, xóa bài viết, tắt bình luận, đề cử Mod
– Admin: Quản lý các bài viết, đăng cảnh báo, xóa bài viết, tắt bình luận, Tạo người dùng, Phân quyền, Ban người dùng, chỉ định Mod, S-mod
Tiếp theo chúng ta trả lời câu hỏi “Hệ thống nào tương tác với hệ thống này?”
Ví dụ chúng ta sử dụng Facebook, Gmail để thực hiện chức năng Login thì chúng ta sẽ có các Actor tương ứng tương tác với hệ thống
Như vậy, chúng ta đã có các Actor của hệ thống gồm: Guest, Member, Mod, S-mod, Admin, Facebook, Google
Bạn cần khảo sát và phân tích thêm cũng như hỏi trực tiếp khách hàng để xác định đầy đủ các Actor cho hệ thống.
Bước 3: Xác định Use Case
Bạn cần trả lời câu hỏi “Actor sử dụng chức năng gì trên hệ thống?”.
Trước tiên, xem xét với Actor “Guest” trên trang bkc.vn để xem họ sử dụng chức năng nào?
– Xem trang chủ
– Xem bài viết
– Tìm kiếm bài viết
– Đăng ký tài khoản để trở thành Member
– .......
Tiếp theo, xem xét Actor “Member” và nhận thấy họ sử dụng chức năng:
– Đăng nhập
– Bình luận
– Đăng bài
– ...
Tương tự như vậy bạn xác định chức năng cho các Actor còn lại.
Bước 4: Vẽ bản vẽ Use Case
Trước hết chúng ta xem xét và phân tích các chức năng của “Guest” chúng ta nhận thấy.Chức năng tìm kiếm bài viết sẽ bao gồm chức năng xem những bài viết đã tìm kiếm ấy. Tuy nhiên chức năng xem bài viết vẫn là một chức năng độc lập. Vì thế mình nối Association vào cả 2. Và đặt mối quan hệ Extend cho chúng.
Đặt lại tên cho gọn và xác định các mối quan hệ của chúng, chúng ta có thể vẽ Use Case Diagram cho Actor này như sau:
Tiếp theo, chúng ta xem xét đến Actor "Member", Actor này có những chức năng tương tự với "Guest" nhưng họ có thể tạo bài viết, bình luận, trả lời một bình luận. Ta có thể vẽ như sau:
Thay vì nối tất cả như thế sẽ rất rối mắt. "Member" có tất cả Use Case của "Guest", có thể xem "Member" là con của "Guest", vì thế ta có thể sử dụng quan hệ kế thừa. Chúng ta sẽ tối giản sơ đồ như ảnh dưới:
Đỡ đau mắt hơn rồi đúng không nào?
Tiếp tục xem xét các Actor còn lại, xem cả những hệ thống nào tương tác với phần mềm và xác định các mối quan hệ, thêm những Actor/ Use Case cần thiết hoặc bớt những thứ không liên quan, mở rộng System Boundary khi hết chỗ. Cuối cùng chúng ta có sơ đồ thế này:
Kết luận
Như vậy, chúng ta đã hoàn thành bản vẽ Use Case cho trang web CForum. Hy vọng, các bạn có thể hiểu và sử dụng bản vẽ này trong việc phân tích hệ thống một cách hiệu quả.
Tips: Nếu phần mềm của bạn được xây dựng theo mô hình Agile/Scrum, các bạn đã có trong tay Use Story rồi thì việc chuyển chúng thành Use Case sẽ dễ như trở bàn tay.
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
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.
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ộtUse 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 lập trình viên php lương cao chế độ hấp dẫn
Tuyển dụng lập trình viên 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.IncludeInclude đượ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
ExtendExtend 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].
- Khách hàng [cha]: Gồm khách hàng cũ [con] và khách hàng mới [con].
Bạn đọc tham khảo thêm: Việc làm IT tại HCM hot nhất hiện nay
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.