de_DEen_USes_ESfr_FRid_IDjapl_PLpt_PTru_RUzh_CNzh_TW

Một Hướng Dẫn Toàn Diện Về Các Mối Quan Hệ Include và Extend Trong Sơ Đồ Trường Hợp Sử Dụng UML

Ngôn Ngữ Mô Hình Hóa Đơn Nhất (UML)sơ đồ trường hợp sử dụng là công cụ mạnh mẽ để mô hình hóa các yêu cầu chức năng của một hệ thống. Chúng minh họa cách các tác nhân (người dùng hoặc hệ thống bên ngoài) tương tác với hệ thống thông qua các trường hợp sử dụng, đại diện cho các chức năng cụ thể. Hai mối quan hệ chính trong sơ đồ trường hợp sử dụng—IncludeExtend—giúp quản lý độ phức tạp bằng cách cấu trúc và phân mảnh hành vi. Bài hướng dẫn này cung cấp giải thích chi tiết về các mối quan hệ này, mục đích, đặc điểm và ứng dụng thực tế, kèm theo các ví dụ để đảm bảo sự rõ ràng.


Các mối quan hệ Include và Extend là gì?

Trong sơ đồ trường hợp sử dụng UML, IncludeExtendcác mối quan hệ Include và Extend cho phép bạn chia nhỏ các trường hợp sử dụng phức tạp thành các thành phần nhỏ hơn, có thể tái sử dụng hoặc tùy chọn. Các mối quan hệ này tăng tính module, giảm sự trùng lặp và cải thiện độ rõ ràng của sơ đồ.

Include” and “Extend” Use Cases - Visual Paradigm Blog

  • Mối quan hệ Include (<<include>>): Đại diện cho hành vi bắt buộc, luôn được thực hiện như một phần của trường hợp sử dụng cơ sở. Nó trích xuất chức năng chung được chia sẻ giữa nhiều trường hợp sử dụng vào một thành phần có thể tái sử dụng.

  • Mối quan hệ Extend (<<extend>>): Đại diện cho hành vi tùy chọn hoặc điều kiện, mở rộng trường hợp sử dụng cơ sở trong các điều kiện cụ thể, giúp trường hợp sử dụng cơ sở tập trung vào chức năng cốt lõi của nó.

Cả hai mối quan hệ đều sử dụng mũi tên gạch để kết nối các trường hợp sử dụng, với nhãn chỉ rõ<<include>> hoặc <<extend>>. Hướng của mũi tên là rất quan trọng, vì nó phản ánh mối phụ thuộc giữa các trường hợp sử dụng.


Mối quan hệ Include (<<include>>)

Mục đích

Cái Bao gồmMối quan hệ Bao gồm được sử dụng để trích xuất hành vi chung, bắt buộc từ nhiều trường hợp sử dụng vào một trường hợp sử dụng duy nhất, có thể tái sử dụng. Điều này thúc đẩy khả năng tái sử dụng và làm đơn giản hóa các trường hợp sử dụng cơ bản bằng cách tránh chức năng trùng lặp.

Đặc điểm

  • Bắt buộc: Trường hợp sử dụng được bao gồm luôn được thực hiện mỗi khi trường hợp sử dụng cơ bản được thực hiện.

  • Có thể tái sử dụng: Trường hợp sử dụng được bao gồm là một chức năng độc lập, mạch lạc, có thể được sử dụng bởi nhiều trường hợp sử dụng cơ bản.

  • Làm đơn giản hóa sơ đồ: Nhờ trích xuất các bước chung, trường hợp sử dụng cơ bản vẫn giữ được ngắn gọn và tập trung.

  • Hướng: Mũi tên chỉ từ trường hợp sử dụng cơ bản đến trường hợp sử dụng được bao gồm, cho thấy trường hợp sử dụng cơ bản phụ thuộc vào trường hợp được bao gồm.

Ký hiệu

  • Một mũi tên đứt đoạn được đánh nhãn <<bao gồm>> nối trường hợp sử dụng cơ bản với trường hợp sử dụng được bao gồm.

Ví dụ 1: Hệ thống mua sắm trực tuyến

Xét một hệ thống mua sắm trực tuyến mà khách hàng có thể Đặt hàng hoặc Hủy đơn hàng. Cả hai trường hợp sử dụng đều yêu cầu khách hàng Đăng nhập vào hệ thống.

  • Các trường hợp sử dụng cơ bản: Đặt hàng, Hủy đơn hàng

  • Trường hợp sử dụng được bao gồm: Đăng nhập

  • Giải thích: Đăng nhập là bước bắt buộc đối với cả việc đặt và hủy đơn hàng. Thay vì sao chép chức năng đăng nhập trong cả hai trường hợp sử dụng, nó được trích xuất thành một trường hợp sử dụng riêng biệtĐăng nhập trường hợp sử dụng, được bao gồm bởi cả hai.

Biểu diễn sơ đồ:

[Đặt hàng] ----<<bao gồm>>----> [Đăng nhập]
[Hủy đơn hàng] ----<<bao gồm>>----> [Đăng nhập]

Ví dụ 2: 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 hoặc Trả sách. Cả hai quy trình này đều yêu cầuXác minh người dùng.

  • Các trường hợp sử dụng cơ bản: Mượn sách, Trả sách

  • Trường hợp sử dụng được bao gồm: Xác minh người dùng

  • Giải thích: Xác minh danh tính người dùng (ví dụ: kiểm tra thẻ thư viện của họ) là bước bắt buộc trong cả việc mượn và trả sách. Trường hợp sử dụngXác minh người dùng use case được bao gồm để tránh lặp lại.

Biểu diễn sơ đồ:

[Mượn sách] ----<<bao gồm>>----> [Xác minh người dùng]
[Trả sách] ----<<bao gồm>>----> [Xác minh người dùng]

Khi nào sử dụng

  • Khi nhiều use case chia sẻ một bước bắt buộc chung.

  • Khi bạn muốn đơn giản hóa mô tả use case bằng cách trích xuất chức năng có thể tái sử dụng.

  • Khi use case được bao gồm có ý nghĩa độc lập (ví dụ như Đăng nhập hoặc Xác minh người dùngcó thể được hiểu là các chức năng độc lập).


Mối quan hệ mở rộng (<<mở rộng>>)

Mục đích

Mối quan hệ Mở rộngmối quan hệ được sử dụng để mô hình hóa hành vi tùy chọn hoặc điều kiện, chỉ được thực hiện trong các tình huống cụ thể. Nó cho phép use case cơ bản duy trì tập trung vào chức năng chính của mình trong khi thêm hành vi tùy chọn một cách có cấu trúc.

Đặc điểm

  • Tùy chọn/Điều kiện: Use case mở rộng sẽ được thực hiện chỉ khi các điều kiện nhất định được thỏa mãn.

  • Phụ thuộc: Use case mở rộng không có ý nghĩa độc lập và phụ thuộc vào use case cơ bản.

  • Điểm mở rộng: Use case cơ bản có thể xác định các điểm cụ thể nơi hành vi mở rộng có thể được chèn vào.

  • Hướng: Mũi tên chỉ từ use case mở rộng đến use case cơ bản, cho thấy use case mở rộng thêm hành vi vào use case cơ bản.

Ký hiệu

  • Một mũi tên đứt đoạn được đánh nhãn <<extend>> kết nối use case mở rộng với use case cơ bản, thường kèm theo ghi chú xác định điều kiện hoặc điểm mở rộng.

Ví dụ 1: Hệ thống ATM

Trong hệ thống ATM, use case cơ bản làRút tiền. Một hành vi tùy chọn,In hóa đơn, có thể xảy ra nếu người dùng yêu cầu in hóa đơn.

  • Use case cơ bản: Rút tiền

  • Use case mở rộng: In hóa đơn

  • Điều kiện: Người dùng chọn in hóa đơn sau khi rút tiền.

  • Giải thích: In hóa đơn không bắt buộc và chỉ xảy ra nếu người dùng yêu cầu rõ ràng. Use caseIn hóa đơn mở rộngRút tiền tại điểm mở rộng “Người dùng yêu cầu in hóa đơn.”

Biểu diễn sơ đồ:

[In hóa đơn] ----<<extend>>----> [Rút tiền]rn(Ghi chú: Điều kiện = Người dùng yêu cầu in hóa đơn)

Ví dụ 2: Nền tảng khóa học trực tuyến

Trong nền tảng khóa học trực tuyến, người dùng có thểLàm bài kiểm tra. Một hành vi tùy chọn,Yêu cầu gợi ý, xảy ra khi người dùng gặp khó khăn với một câu hỏi.

  • Trường hợp sử dụng cơ bản: Làm bài kiểm tra

  • Trường hợp sử dụng mở rộng: Yêu cầu gợi ý

  • Điều kiện: Người dùng yêu cầu gợi ý trong quá trình làm bài kiểm tra.

  • Giải thích: Việc yêu cầu gợi ý là tùy chọn và phụ thuộc vào nhu cầu của người dùng. Trường hợp Yêu cầu gợi ý trường hợp sử dụng mở rộng Làm bài kiểm tra tại điểm mở rộng “Người dùng cần hỗ trợ.”

Biểu diễn sơ đồ:

[Yêu cầu gợi ý] ----<<mở rộng>>----> [Làm bài kiểm tra]
(Ghi chú: Điều kiện = Người dùng cần hỗ trợ)

Khi nào sử dụng

  • Khi hành vi là tùy chọn hoặc phụ thuộc vào các điều kiện cụ thể.

  • Khi bạn muốn giữ cho trường hợp sử dụng cơ bản tập trung vào chức năng chính của nó.

  • Khi trường hợp sử dụng mở rộng không có ý nghĩa nếu không có trường hợp sử dụng cơ bản (ví dụ: In hóa đơn sẽ không có ý nghĩa nếu không có Rút tiền).


Sự khác biệt chính giữa Include và Extend

Bảng dưới đây tóm tắt sự khác biệt giữa IncludeMở rộng quan hệ để hướng dẫn cách sử dụng:

Tiêu chí

Bao gồm (<<bao gồm>>)

Mở rộng (<<mở rộng>>)

Hành vi này có bắt buộc không?

Có, luôn được thực hiện như một phần của trường hợp sử dụng cơ bản

Không, chỉ được thực hiện trong các điều kiện cụ thể

Hành vi có thể hoạt động độc lập không?

Có, đó là một chức năng mạch lạc và có thể tái sử dụng

Không, nó phụ thuộc vào trường hợp sử dụng cơ bản

Nó có xuất hiện trong nhiều trường hợp sử dụng không?

Có, được chia sẻ giữa nhiều trường hợp sử dụng

Thường chỉ cụ thể cho một trường hợp sử dụng

Mục đích

Khuyến khích tái sử dụng và đơn giản hóa trường hợp sử dụng cơ bản

Thêm hành vi tùy chọn hoặc đặc biệt một cách module

Hướng mũi tên

Cơ bản → Trường hợp sử dụng được bao gồm

Mở rộng → Trường hợp sử dụng cơ bản


Ví dụ thực tế: Hệ thống quản lý nhà hàng

Hãy áp dụng cả hai mối quan hệ trong một hệ thống quản lý nhà hàng để minh họa cách sử dụng chúng trong một tình huống thực tế.

Tình huống

Một hệ thống nhà hàng cho phép khách hàngĐặt món ănĐặt bàn. Hệ thống cũng xử lý các hành vi bổ sung như Thanh toán hóa đơnYêu cầu mang đi.

Các trường hợp sử dụng

  • Đặt món ăn: Khách hàng đặt món ăn từ thực đơn.

  • Đặt bàn: Khách hàng đặt bàn để ăn uống.

  • Xác thực khách hàng: Xác minh danh tính của khách hàng (ví dụ: thông qua tài khoản thành viên).

  • Thanh toán hóa đơn: Khách hàng thanh toán cho đơn hàng của họ (bắt buộc đối với Đặt món ăn).

  • Yêu cầu mang đi: Yêu cầu tùy chọn để đóng gói đơn hàng để mang đi.

Mối quan hệ

  • Bao gồm: Cả hai Đặt món ănĐặt bàn đều yêu cầu Xác thực khách hàng để xác minh danh tính của khách hàng.Đặt món ăn cũng bao gồm Thanh toán hóa đơn vì thanh toán là bắt buộc sau khi đặt hàng.

  • Mở rộng: Đặt món ăn có thể được mở rộng bởiYêu cầu mang đi nếu khách hàng chọn mang đồ ăn về.

Biểu diễn sơ đồ

[Đặt món ăn] ----<<bao gồm>>----> [Xác thực khách hàng]
[Đặt món ăn] ----<<bao gồm>>----> [Thanh toán hóa đơn]
[Đặt bàn] ----<<bao gồm>>----> [Xác thực khách hàng]
[Yêu cầu mang đi] ----<<mở rộng>>----> [Đặt món ăn]
(Ghi chú: Điều kiện = Khách hàng yêu cầu mang đi)

Giải thích

  • Xác thực khách hàng được bao gồm trong cảĐặt món ănĐặt bàn vì đây là bước bắt buộc để truy cập hệ thống.

  • Thanh toán hóa đơn được bao gồm trongĐặt món ăn vì thanh toán là bắt buộc để hoàn tất đơn hàng.

  • Yêu cầu mang đi mở rộngĐặt món ăn vì đây là hành vi tùy chọn chỉ xảy ra khi khách hàng yêu cầu mang đi.


Các nguyên tắc tốt nhất khi sử dụng Bao gồm và Mở rộng

  1. Sử dụng Bao gồm một cách tiết chế: Chỉ trích xuất hành vi vào một use case được bao gồm nếu nó được chia sẻ bởi nhiều use case hoặc làm đơn giản đáng kể use case cơ bản. Sử dụng quá nhiều bao gồm có thể khiến sơ đồ trở nên rối rắm.

  2. Xác định rõ các điểm mở rộng cho Mở rộng: Xác định rõ điều kiện hoặc điểm trong use case cơ bản nơi hành vi mở rộng được áp dụng để tránh hiểu nhầm.

  3. Giữ các trường hợp sử dụng tập trung: Đảm bảo trường hợp sử dụng cơ bản vẫn đơn giản và tập trung vào mục tiêu chính, sử dụngBao gồm cho các bước bắt buộc vàMở rộng cho các bước tùy chọn.

  4. Xác minh tính tái sử dụng cho Bao gồm: Trường hợp sử dụng được bao gồm nên có ý nghĩa và có thể tái sử dụng trong các ngữ cảnh khác nhau.

  5. Tránh làm phức tạp hóa sơ đồ: Sử dụngBao gồmMở rộngchỉ khi chúng mang lại sự rõ ràng. Các mối quan hệ phức tạp có thể gây nhầm lẫn cho các bên liên quan.


Những sai lầm phổ biến và cách tránh chúng

  1. Nhầm lẫn giữa Bao gồm và Mở rộng:

    • Sai lầm: Sử dụngBao gồm cho hành vi tùy chọn hoặcMở rộng cho hành vi bắt buộc.

    • Giải pháp: Luôn kiểm tra xem hành vi có bắt buộc hay không (sử dụngBao gồm) hay điều kiện (sử dụngMở rộng).

  2. Sử dụng quá nhiều mối quan hệ:

    • Hạn chế: Tạo quá nhiều Include hoặc Extend quan hệ, khiến sơ đồ trở nên khó đọc.

    • Giải pháp: Chỉ sử dụng các quan hệ này khi chúng làm giảm sự trùng lặp hoặc cải thiện độ rõ ràng.

  3. Điều kiện mở rộng mơ hồ:

    • Hạn chế: Không xác định điều kiện cho một Extend quan hệ, dẫn đến nhầm lẫn.

    • Giải pháp: Luôn luôn bao gồm ghi chú hoặc mô tả về điều kiện hoặc điểm mở rộng.

  4. Bao gồm hành vi không tái sử dụng được:

    • Hạn chế: Tạo một trường hợp sử dụng được bao gồm mà chỉ được sử dụng bởi một trường hợp sử dụng cơ sở duy nhất.

    • Giải pháp: Đảm bảo rằng trường hợp sử dụng được bao gồm có thể tái sử dụng hoặc làm đơn giản hóa đáng kể trường hợp sử dụng cơ sở.


Kết luận

Các quan hệ IncludeExtend trong sơ đồ trường hợp sử dụng UML là thiết yếu để quản lý độ phức tạp và đảm bảo tính module. Các Include mối quan hệ thúc đẩy khả năng tái sử dụng bằng cách trích xuất hành vi bắt buộc và chung, trong khi đó Mở rộngmối quan hệ giúp các trường hợp sử dụng cơ bản tập trung vào mục tiêu bằng cách mô hình hóa hành vi tùy chọn hoặc điều kiện. Bằng cách hiểu rõ mục đích, đặc điểm và các phương pháp tốt nhất, bạn có thể tạo ra các sơ đồ trường hợp sử dụng rõ ràng, dễ bảo trì và hiệu quả, giúp truyền đạt chức năng hệ thống đến các bên liên quan.

Tham khảo

Follow
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...