Giới thiệu
Trong kỹ thuật phần mềm, các sơ đồ trường hợp sử dụng giúp hình dung các tương tác giữa người dùng (người tham gia) và một hệ thống để ghi lại các yêu cầu chức năng của nó. Khi hệ thống mở rộng, các sơ đồ trường hợp sử dụng có thể trở nên khó kiểm soát, chứa đựng các hành vi lặp lại hoặc phức tạp làm mờ đi chức năng cốt lõi của hệ thống. Mối quan hệ mối quan hệ bao gồmtrong UML giải quyết thách thức này bằng cách cho phép các hành vi chung được trích xuất vào các sơ đồ trường hợp sử dụng có thể tái sử dụng và có tính module. Bài viết này đi sâu vào cách các mối quan hệ bao gồm đơn giản hóa các sơ đồ trường hợp sử dụng, những lợi ích chính của chúng và các ví dụ thực tế để minh họa tính hữu ích của chúng.
Mối quan hệ bao gồm là gì?
Một mối quan hệ bao gồmtrong UML xác định rằng một sơ đồ trường hợp cơ sở tích hợp hành vi của một sơ đồ trường hợp khác, được gọi là sơ đồ trường hợp được bao gồm. Sơ đồ trường hợp được bao gồm đại diện cho một chuỗi các hành động mà luôn được thực hiệnlà một phần trong luồng của sơ đồ trường hợp cơ sở. Về mặt trực quan, mối quan hệ này được biểu diễn bằng một mũi tên đứt đoạn với đầu mũi tên hởchỉ từ sơ đồ trường hợp cơ sở đến sơ đồ trường hợp được bao gồm, được đánh nhãn bằng kiểu đặc tả «bao gồm».
Mối quan hệ bao gồm tương tự như lời gọi hàm con trong lập trình: sơ đồ trường hợp cơ sở “gọi” sơ đồ trường hợp được bao gồm để thực hiện một nhiệm vụ cụ thể, thúc đẩy mô hình hóa có cấu trúc và phân cấp. Bằng cách trích xuất các hành vi chung hoặc phức tạp vào các sơ đồ trường hợp riêng biệt, các mối quan hệ bao gồm giảm thiểu sự trùng lặp, nâng cao tính rõ ràng và cải thiện khả năng bảo trì.
Lợi ích của các mối quan hệ bao gồm
Các mối quan hệ bao gồm mang lại nhiều lợi ích khi mô hình hóa các hệ thống lớn và phức tạp:
-
Tái sử dụng hành vi chung: Các chức năng chung giữa nhiều sơ đồ trường hợp có thể được đóng gói vào một sơ đồ trường hợp được bao gồm duy nhất, loại bỏ sự trùng lặp.
-
Đơn giản hóa các sơ đồ trường hợp phức tạp: Các sơ đồ trường hợp lớn có thể được chia thành các mô-đun nhỏ hơn, dễ quản lý, giúp sơ đồ trở nên ít rối rắm hơn.
-
Thực hiện bắt buộc: Sơ đồ trường hợp được bao gồm luôn được thực hiện như một phần của sơ đồ trường hợp cơ sở, đảm bảo tính đầy đủ mà không làm quá tải luồng chính bằng chi tiết.
-
Cải thiện tính rõ ràng và khả năng bảo trì: Bằng cách tách biệt các vấn đề, sơ đồ trường hợp cơ sở tập trung vào hành vi riêng biệt của nó, trong khi các sơ đồ trường hợp được bao gồm xử lý các chuỗi có thể tái sử dụng, giúp việc cập nhật trở nên đơn giản hơn.
-
Mô hình hóa có cấu trúc: Các mối quan hệ bao gồm hỗ trợ thiết kế phân cấp, tương tự như các hàm con, giúp hệ thống dễ hiểu và dễ mở rộng hơn.
Ví dụ về các mối quan hệ bao gồm
Để minh họa sức mạnh của các mối quan hệ bao gồm, hãy cùng khám phá một số ví dụ thực tế trong các lĩnh vực khác nhau.
Ví dụ 1: Hệ thống mua sắm trực tuyến
Hãy xem xét một nền tảng mua sắm trực tuyến nơi người dùng có thể duyệt sản phẩm, thêm hàng vào giỏ hàng và thanh toán. Nhiều sơ đồ trường hợp, chẳng hạn như “Mua sản phẩm”, “Đặt hàng”, và “Tặng sản phẩm”, đều yêu cầu người dùng phải xác thực trước khi tiến hành.
-
Các trường hợp sử dụng cơ bản: “Mua sản phẩm,” “Đặt trước hàng,” “Tặng hàng”
-
Trường hợp sử dụng được bao gồm: “Xác thực người dùng”
Thay vì lặp lại các bước xác thực trong từng trường hợp sử dụng, chúng tôi tách chúng ra thành một trường hợp sử dụng duy nhất là “Xác thực người dùng”. Trường hợp sử dụng được bao gồm này xử lý các nhiệm vụ như yêu cầu thông tin đăng nhập và xác minh chúng. Sơ đồ trường hợp sử dụng sẽ hiển thị:
-
Một mũi tên nét đứt từ “Mua sản phẩm” đến “Xác thực người dùng” với nhãn «include».
-
Các mũi tên tương tự từ “Đặt trước hàng” và “Tặng hàng” đến “Xác thực người dùng”.
Phương pháp này giảm thiểu sự trùng lặp, vì logic xác thực được định nghĩa một lần và được tái sử dụng trong nhiều trường hợp sử dụng, giúp sơ đồ luôn gọn gàng và dễ bảo trì.
Ví dụ 2: Hệ thống ngân hàng
Trong một hệ thống ngân hàng, khách hàng có thể thực hiện các hành động như “Rút tiền,” “Gửi tiền,” và “Chuyển tiền.” Mỗi trường hợp sử dụng này đều yêu cầu xác minh tài khoản của khách hàng trước khi tiếp tục.
-
Các trường hợp sử dụng cơ bản: “Rút tiền,” “Gửi tiền,” “Chuyển tiền”
-
Trường hợp sử dụng được bao gồm: “Xác minh tài khoản”
Trường hợp sử dụng “Xác minh tài khoản” kiểm tra trạng thái tài khoản, số dư và quyền hạn. Bằng cách bao gồm trường hợp này vào mỗi trường hợp sử dụng cơ bản, sơ đồ tránh được việc lặp lại logic xác minh. Biểu diễn trực quan bao gồm các mũi tên nét đứt có nhãn «include» từ mỗi trường hợp sử dụng cơ bản đến “Xác minh tài khoản”. Việc phân mảnh này làm đơn giản hóa sơ đồ và đảm bảo rằng việc xác minh tài khoản được thực hiện nhất quán.
Ví dụ 3: Hệ thống quản lý thư viện
Trong một hệ thống thư viện, người dùng có thể “Mượn sách,” “Trả sách,” hoặc “Đặt trước sách.” Mỗi hành động này đều yêu cầu kiểm tra tính sẵn có của sách.
-
Các trường hợp sử dụng cơ bản: “Mượn sách,” “Trả sách,” “Đặt trước sách”
-
Trường hợp sử dụng được bao gồm: “Kiểm tra tính sẵn có của sách”
Trường hợp sử dụng “Kiểm tra tính sẵn có của sách” xác minh xem sách có còn trong kho và chưa bị đặt trước hay không. Bằng cách bao gồm trường hợp này vào các trường hợp sử dụng cơ bản, sơ đồ vẫn giữ được sự gọn gàng, và các cập nhật về logic kiểm tra tính sẵn có (ví dụ: tích hợp hệ thống kho mới) chỉ cần thực hiện tại một điểm duy nhất.
Ví dụ 4: Hệ thống quản lý bệnh viện
Trong một hệ thống quản lý bệnh viện, bệnh nhân có thể “Đặt lịch hẹn,” “Hủy lịch hẹn,” hoặc “Điều chỉnh lịch hẹn.” Mỗi trường hợp sử dụng này đều yêu cầu xác minh danh tính của bệnh nhân.
-
Các trường hợp sử dụng cơ bản: “Đặt lịch hẹn,” “Hủy lịch hẹn,” “Điều chỉnh lịch hẹn”
-
Trường hợp sử dụng được bao gồm: “Xác minh danh tính bệnh nhân”
Trường hợp sử dụng “Xác minh danh tính bệnh nhân” xử lý các nhiệm vụ như kiểm tra ID hoặc thông tin bảo hiểm của bệnh nhân. Việc bao gồm trường hợp này vào các trường hợp sử dụng cơ bản đảm bảo rằng việc xác minh danh tính được thực hiện nhất quán mà không cần lặp lại các bước trong sơ đồ. Các mũi tên nét đứt có nhãn «include» kết nối mỗi trường hợp sử dụng cơ bản với “Xác minh danh tính bệnh nhân”, giúp tăng tính rõ ràng.
Ví dụ 5: Nền tảng học trực tuyến
Trong một nền tảng học tập trực tuyến, sinh viên có thể “Làm bài kiểm tra”, “Nộp bài tập” hoặc “Xem điểm số”. Mỗi hành động này đều yêu cầu sinh viên đăng nhập vào hệ thống.
-
Các trường hợp sử dụng cơ bản: “Làm bài kiểm tra”, “Nộp bài tập”, “Xem điểm số”
-
Trường hợp sử dụng được bao gồm: “Đăng nhập”
Trường hợp sử dụng “Đăng nhập” bao hàm các bước xác thực người dùng. Bằng cách bao gồm nó trong các trường hợp sử dụng cơ bản, sơ đồ tránh được việc lặp lại các bước đăng nhập, giúp dễ hiểu và dễ bảo trì hơn. Biểu diễn trực quan cho thấy các mũi tên đứt đoạn được đánh nhãn «include» đi từ mỗi trường hợp sử dụng cơ bản đến “Đăng nhập”.
Biểu diễn trực quan trong UML
Trong sơ đồ trường hợp sử dụng UML, mối quan hệ include được biểu diễn như sau:
-
Một mũi tên đứt đoạnvới một đầu mũi tên hởđi từ trường hợp sử dụng cơ bản đến trường hợp sử dụng được bao gồm.
-
Mũi tên được đánh nhãn với kiểu stereotype «include».
Ví dụ, trong ví dụ mua sắm trực tuyến:
-
Mua sản phẩm → «include» → Xác thực người dùng
-
Sơ đồ rõ ràng cho thấy “Xác thực người dùng” là một phần bắt buộc trong luồng “Mua sản phẩm”.
Thỏa thuận trực quan này đảm bảo rằng các bên liên quan có thể nhanh chóng nắm bắt được mối quan hệ giữa các trường hợp sử dụng và các phụ thuộc của chúng.
So sánh với mối quan hệ extend
Đáng chú ý là sự khác biệt giữa include và extendmối quan hệ để tránh nhầm lẫn:
-
Include: Trường hợp sử dụng được bao gồm là luôn được thực thi như một phần của use case cơ sở (bắt buộc).
-
Mở rộng: Use case mở rộng làtùy chọn và chỉ được thực thi trong các điều kiện cụ thể.
Ví dụ, trong hệ thống mua sắm trực tuyến, “Xác thực người dùng” được bao gồm vì nó là bắt buộc, nhưng một use case như “Áp dụng mã giảm giá” có thể là mối quan hệ mở rộng, vì nó là tùy chọn và phụ thuộc vào việc người dùng có mã hợp lệ hay không.
Các nguyên tắc tốt nhất khi sử dụng mối quan hệ bao gồm
Để tận dụng tối đa lợi ích của mối quan hệ bao gồm, hãy cân nhắc những điều sau:
-
Xác định các hành vi chung: Tìm kiếm các chuỗi hành động được lặp lại trong nhiều use case, chẳng hạn như xác thực, kiểm tra hoặc ghi nhật ký.
-
Giữ các use case được bao gồm tập trung: Đảm bảo rằng các use case được bao gồm bao hàm các hành vi cụ thể, có thể tái sử dụng thay vì toàn bộ quy trình.
-
Cân bằng giữa tính module và tính đơn giản: Tránh phân mảnh quá mức các use case, vì quá nhiều use case được bao gồm có thể khiến sơ đồ khó theo dõi hơn.
-
Sử dụng quy ước đặt tên rõ ràng: Đặt tên các use case được bao gồm để phản ánh mục đích của chúng (ví dụ: “Xác thực người dùng” thay vì “Quy trình đăng nhập”) để tăng tính dễ đọc.
-
Xác minh việc thực thi bắt buộc: Xác nhận rằng use case được bao gồm luôn là bắt buộc; nếu không, hãy cân nhắc sử dụng mối quan hệ mở rộng.
Tóm tắt các lợi ích
Bảng sau đây tóm tắt các lợi ích chính của mối quan hệ bao gồm:
|
Lợi ích |
Giải thích |
|---|---|
|
Tái sử dụng hành vi chung |
Trích xuất chức năng chung để tránh trùng lặp giữa các use case |
|
Đơn giản hóa các use case phức tạp |
Chia nhỏ các use case lớn thành các phần nhỏ, dễ quản lý |
|
Thực thi bắt buộc |
Use case được bao gồm luôn là một phần của use case cơ sở, đảm bảo tính đầy đủ |
|
Tính module và tính rõ ràng |
Tách biệt các vấn đề, cải thiện tính dễ đọc và khả năng bảo trì |
|
Mô hình hóa có cấu trúc |
Giống như gọi các hàm con, hỗ trợ thiết kế phân cấp |
Kết luận
Các mối quan hệ bao gồm là nền tảng của việc mô hình hóa use case hiệu quả trong UML, cho phép tái sử dụng và phân mảnh các hành vi chung, bắt buộc. Bằng cách trích xuất chức năng chung vào các use case được bao gồm, các nhà phát triển có thể tạo ra các sơ đồ sạch sẽ, dễ bảo trì hơn, dễ hiểu và cập nhật hơn. Các ví dụ được đưa ra—từ mua sắm trực tuyến đến quản lý bệnh viện—chứng minh tính linh hoạt của các mối quan hệ bao gồm trong nhiều lĩnh vực khác nhau. Bằng cách tận dụng cơ chế này, các nhóm có thể mô hình hóa các hệ thống phức tạp với độ rõ ràng và hiệu quả cao hơn, từ đó nâng cao chất lượng thiết kế phần mềm của họ.
Tham khảo
- Tài liệu chi tiết use case trong Visual Paradigm
Hướng dẫn cách chỉnh sửa và xem chi tiết use case trong Visual Paradigm. - Làm thế nào để vẽ sơ đồ use case? – Visual Paradigm
Hướng dẫn từng bước để tạo sơ đồ use case UML bằng Visual Paradigm. - Sơ đồ use case là gì? – Visual Paradigm
Tổng quan về sơ đồ use case và vai trò của chúng trong việc mô hình hóa hành vi hệ thống. - Sơ đồ use case trong Visual Paradigm
Giải thích chi tiết các thành phần của sơ đồ use case và cách tài liệu hóa các sự kiện use case. - Hướng dẫn ký hiệu sơ đồ use case – Visual Paradigm
Hướng dẫn toàn diện về các ký hiệu sơ đồ use case UML được hỗ trợ trong Visual Paradigm. - Hướng dẫn toàn diện về việc tạo sơ đồ use case với Visual Paradigm
Một bài hướng dẫn chi tiết về việc xác định các tác nhân, định nghĩa use case và mô hình hóa các mối quan hệ trong Visual Paradigm. - Mô tả use case trong Visual Paradigm cho UML – Angelfire
Giải thích mô tả use case, lập lịch, chi tiết hóa và tạo tài liệu trong Visual Paradigm. - Giải mã các mô hình use case: Kết nối chi tiết văn bản và cái nhìn trực quan
Thảo luận về cách kết hợp chi tiết use case văn bản với các sơ đồ trực quan trong Visual Paradigm. - Sơ đồ use case – Công cụ mô hình hóa UML – Visual Paradigm
Trang web chính thức của Visual Paradigm giới thiệu các tính năng và hỗ trợ ký hiệu của sơ đồ use case.