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 những đề nghị của hệ thống phần mềm. 1 mô hình Use Case phải chăng sẽ mô tả hệ thống 1 bí quyết trực quan và dễ hiểu nhất cho mọi đối tượng dùng. Để biết Use Case là gì và làm cho thế nào để xây dựng 1 sơ đồ Use Case hiệu quả, cùng tham khảo ngay!
Use Case là gì là câu hỏi được nhiều khách hàng để ý
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 khách hàng và hệ thống (trong 1 môi trường cụ thể, vì 1 phần đích cụ thể). Sự tương tác này có thể là:
- Bí quyết thức mà khách hàng tương tác sở hữu hệ thống;
- Bí quyết thức mà hệ thống tương tác sở hữu những hệ thống khác.
Tất nhiên, sự tương tác này cần nên nằm trong diện 1 môi trường cụ thể – tức là nằm trong diện 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ể. Phần đích của Use Case là gì? Ấy là nên diễn tả được đề nghị theo góc nhìn cụ thể từ phía khách hàng.
Use Case giống như 1 sơ đồ mô tả sự tương tác giữa những 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 khách hàng. Khách hàng sẽ dùng những Use Case để đại diện cho những nghiệp vụ của hệ thống.
Thí dụ về “hệ thống đặt vé máy bay trực tuyến” thì chức năng “đặt vé” là 1 Use Case rõ ràng nhất của hệ thống mà khách hàng muốn nhận được. Chức năng “kiếm tìm” vé trên hệ thống cũng có thể là chức năng được dùng. Tuy nhiên, chức năng “kiếm tìm” đây ko nên là 1 Use Case vì nó chỉ là 1 phần của quy trình xử lý đặt vé.
Bạn đọc tham khảo thêm:
Việc làm cho java net 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
Những thành phần của Use Case là gì?
Trường hợp 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. Những thành phần của Use Case bao gồm:
Những thành phần cơ bản của Use Case là gì?
Actor
Actor được dùng để chỉ khách hàng hoặc 1 đối tượng nào ấy bên bên cạnh tương tác sở hữu hệ thống.
Actor – thành phần quan yếu nhất
Để xác nhận ấy có nên là Actor hay ko thì cần xét trên những câu hỏi sau:
- Ai là người 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 tương trợ để thực hành những tác vụ hằng ngày?
- Hệ thống này có cần nên tương tác sở hữu những hệ thống nào khác ko?
- Ai là người enter dữ liệu vào hệ thống (đối sở hữu hệ thống lưu trữ dữ liệu)?
- Ai hay loại gì để ý tới giá trị mà hệ thống sẽ mang trong mình lại?
Use Case, Communication Hyperlink, Boundary of System
Use Case là gì? Đây là những chức năng mà những Actor sẽ dùng hay biểu lộ sự tương tác giữa khách hàng và hệ thống. Để tìm ra được những 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 new, hủy bỏ, chỉnh sửa hay lưu trữ loại thông tin nào trong hệ thống ko?
- Hệ thống có cần thông tin những thay thế đổi bất ngờ trong nội bộ cho Actor ko?
- 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 những 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 ko?
- Hệ thống cần những thông tin đầu vào/đầu ra nào, những thông tin ấy sẽ đi từ đâu tới đâu?
- Những khó khăn và thiếu hụt của hệ thống hiện tại nằm tại đâu?
Sự tương tác và phạm vi của Use Case
Communication Hyperlink biểu lộ sự tương tác giữa khách hà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. Thí dụ sở hữu 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ả 1 module lớn như quản lý bán hàng. Bạn đọc tham khảo thêm: Testcase là gì? Làm cho thế nào để tạo nên những biểu mẫu take a look at case chất lượng?
Relationship
Relationship gồm 3 loại: Embrace, Prolong, và Generalization. Embrace Embrace được định nghĩa là mối quan hệ nên} nên có giữa những Use Case sở hữu nhau. Xét về nghĩa, Embrace trong tiếng Anh nghĩa là bao gồm. Tức giả dụ nói Use Case A có mối quan hệ Embrace sở hữu Use Case B thì điều ấy có nghĩa Use Case A bao gồm Use Case B.
Để Use Case A xảy ra thì nên đạt được Use Case B. Thí dụ: để rút được tiền trong thẻ, khách hàng nên xác thực account. Chỉ lúc xác thực account xong, bạn new có thể rút được tiền trong thẻ. Hay nói bí quyết khác, để Use Case rút tiền (Use Case A) xảy ra thì Use Case xác thực account (Use Case B) nên hoàn thành. Đây là dí dụ hoàn hảo cho mối quan hệ Embrace.
Mối quan hệ Embrace và Prolong được diễn tả trong sơ đồ Use Case
Prolong Prolong biểu diễn mối quan hệ mở rộng giữa những Use Case sở hữu nhau. Trường hợp Embrace biểu lộ mối quan hệ nên} thì Prolong lại là mối quan hệ ko nên} (có thể có hoặc ko) giữa những Use Case sở hữu nhau. Trường hợp Use Case B là Prolong của Use Case A, điều này có nghĩa Use Case B chỉ là 1 lựa chọn chỉ xảy ra trong 1 hoàn cảnh cụ thể nào ấy.
Thí dụ: lúc 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ệ Prolong sở hữu Use Case đăng nhập hệ thống (Use Case A). Bởi, Use Case quên mật khẩu chỉ là 1 Use Case có thể xảy ra hoặc ko và nó có liên quan tới Use Case đăng nhập hệ thống chứ ko nên bất kỳ 1 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 những Use Case sở hữu nhau. Điểm khác biệt giữa Generalization sở hữu Embrace và Prolong chính là khả năng biểu lộ mối quan hệ giữa những Actor sở hữu nhau.
Thí dụ về mối quan hệ Generalization theo phương thức tính sổ
Tham khảo thêm những dí dụ dưới đây để hiểu chi tiết hơn nhé! Thí dụ về mối quan hệ cha – con giữa những Use Case là gì:
- Đăng nhập (cha): Có thể thông qua số điện thoại (con) hoặc Electronic mail (con).
- Đặt hàng (cha): Có đặt hàng qua số điện thoại (con) hoặc web site (con).
- Tính sổ (cha): Có thể thông qua thẻ ATM (con), thẻ tính sổ quốc tế (con) hay những ví điện tử (con).
- Kiếm tìm (cha): Có thể qua từ khóa (con) hoặc theo nhóm siêu phẩm (con).
Thí dụ về mối quan hệ cha – con giữa những Actor:
- Khách hàng (cha): Gồm khách hàng cũ (con) và khách hàng new (con).
Nhìn chung, Generalization sẽ giúp chúng ta hiểu rõ hơn về những đề nghị bằng những nhóm Use Case có quan hệ cha – con. Bên cạnh ra, Generalization còn có tính kế thừa, tức cha có gì thì con có ấy nói cả Use Case hay Actor.
Bí quyết xây dựng 1 Use Case Diagram hoàn chỉnh
Tới đây, kiên cố hẳn bạn đọc đã hiểu Use Case là gì. Và để xây dựng được 1 sơ đồ Use Case hoàn chỉnh cần trải trải qua giai đoạn sở hữu những bước sau:
Thí dụ về 1 Use Case Diagram hoàn hảo
Giai đoạn mô hình hóa:
- Bước 1: Thực hành thiết lập ngữ cảnh của hệ thống.
- Bước 2: Xác định những Actor.
- Bước 3: Xác định những Use Case.
- Bước 4: Định nghĩa những mối quan hệ giữa Actor và Use Case.
- Bước 5: Đánh giá những mối quan hệ ấy để tìm bí quyết chi tiết hóa.
Giai đoạn cấu trúc:
- Bước 6: Đánh giá những Use Case cho quan hệ Embrace.
- Bước 7: Đánh giá những Use Case cho quan hệ Prolong.
- Bước 8: Đánh giá những Use Case cho quan hệ Generalization .
Giai đoạn evaluate:
- Đánh giá (verification): đảm bảo hệ thống đúng sở hữu tài liệu đặc tả.
- Thẩm định (validation): đảm bảo hệ thống sẽ được phát triển thành 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 ý lúc thiết kế Use Case Diagram
Sơ đồ Use Case là thứ biểu lộ được những đề nghị 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 lúc xây dựng Use Case là gì, bí quyết khắc phục như thế nào, người mua nên lưu tâm:
Tô màu sắc cho Use Case Diagram để sơ đồ rõ ràng hơn
- Đặt tên ko chuẩn: Vì là mô hình hóa nên cần diễn đạt bằng hình ảnh, cố gắng dùng ít chữ nhất có thể. Vì vậy, những gì được ghi trên Use Case Diagram nên thực cô đọng và có giá trị tức thì. Ấy là nguyên nhân bạn giảm thiểu đặ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ý” (handle) trên sơ đồ. Use Case cần truyền tải được phần đích sau cùng, chứa đựng góc nhìn của khách hàng cuối cùng;
- Thiết kế quá nhiều Use Case: Là 1 sai lầm nhiều người mắc nên. Bạn nên tận dụng những Relationship để làm những Use Case hợp tác sở hữu nhau, tiếp tục dùng Boundary of System để phân nhóm, giới hạn cho những Use Case;
- Quá đi sâu vào chi tiết những chức năng CRUD: Trường hợp dùng từng thực thể là 1 lần CRUD thì sẽ siêu tốn công. Điều này cũng tạo sự lặp đi lặp lại tại những sơ đồ Use Case nhưng lại ko biểu lộ được nhiều thông tin cho người xem. Để giải quyết, bạn có thể thử thêm 1 dòng be aware 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à handle X sở hữu 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ỹ, ko có thiết kế hợp lý nên ko lôi kéo được khách hàng. Vì vậy, bạn cần chú ý thiết kế những Use Case trong Diagram cùng kích cỡ, đánh dấu những Use Case ID, ko được chồng chéo những mối quan hệ, có thể tô màu sắc lên Use Case,… để sơ đồ rõ ràng, nguồn 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 giải pháp xây dựng 1 sơ đồ Use Case hoàn hảo. Và giả dụ yêu thích những thủ thuật khoa học hữu ích, hãy tiếp tục đồng hành cùng ITNavi bạn nhé!
