Sự khác biệt giữa bao gồm và mở rộng trong sơ đồ ca sử dụng là gì?

Sự khác biệt giữa includevà extendtrong sơ đồ ca sử dụng là gì?

Extend được sử dụng khi ca sử dụng thêm các bước vào ca sử dụng hạng nhất khác.

Ví dụ: hãy tưởng tượng "Rút tiền mặt" là trường hợp sử dụng của Máy rút tiền tự động (ATM). "Phí đánh giá" sẽ mở rộng Rút tiền mặt và mô tả "điểm mở rộng" có điều kiện được khởi tạo khi người dùng ATM không gửi ngân hàng tại tổ chức sở hữu ATM. Lưu ý rằng trường hợp sử dụng "Rút tiền mặt" cơ bản tự đứng, không có phần mở rộng.

Bao gồm được sử dụng để trích xuất các đoạn trường hợp sử dụng được nhân đôi trong nhiều trường hợp sử dụng. Ca sử dụng đi kèm không thể đứng độc lập và ca sử dụng ban đầu không hoàn thành nếu không có trường hợp sử dụng đi kèm. Điều này nên được sử dụng một cách tiết kiệm và chỉ trong trường hợp sự trùng lặp có ý nghĩa và tồn tại theo thiết kế (chứ không phải do sự trùng hợp).

Ví dụ: luồng sự kiện xảy ra ở đầu mỗi trường hợp sử dụng ATM (khi người dùng đặt thẻ ATM, nhập mã PIN và được hiển thị menu chính) sẽ là một ứng cử viên tốt cho bao gồm.

Điều này có thể gây tranh cãi nhưng bao gồm các trò chơi luôn luôn và mở rộng đôi khi là một quan niệm sai lầm rất phổ biến mà gần như đã được hiểu là ý nghĩa thực tế. Đây là một cách tiếp cận đúng (theo quan điểm của tôi, và đã kiểm tra đối với Jacobson, Fowler, Larmen và 10 tài liệu tham khảo khác).

Mối quan hệ là phụ thuộc

Chìa khóa để Bao gồm và mở rộng các mối quan hệ tình huống sử dụng là nhận ra rằng, phổ biến với phần còn lại của UML, mũi tên chấm giữa các trường hợp sử dụng là mối quan hệ phụ thuộc. Tôi sẽ sử dụng các thuật ngữ 'cơ sở', 'bao gồm' và 'mở rộng' để chỉ các vai trò ca sử dụng.

bao gồm

Một ca sử dụng cơ sở phụ thuộc vào (các) ca sử dụng đi kèm; không có nó / ca sử dụng cơ sở không đầy đủ vì (các) ca sử dụng đi kèm đại diện cho các chuỗi con của tương tác có thể xảy ra luôn HOẶC đôi khi. (Điều này trái với quan niệm sai lầm phổ biến về điều này, trường hợp sử dụng của bạn cho thấy luôn xảy ra trong kịch bản chính và đôi khi xảy ra trong các luồng thay thế chỉ đơn giản phụ thuộc vào kịch bản chính của bạn; trường hợp sử dụng có thể dễ dàng được cấu trúc lại để thể hiện một luồng khác là kịch bản chính và điều này không thành vấn đề).

Trong thực tiễn tốt nhất về sự phụ thuộc một chiều, trường hợp sử dụng cơ sở biết về (và đề cập đến) trường hợp sử dụng đi kèm, nhưng trường hợp sử dụng đi kèm không nên 'biết' về trường hợp sử dụng cơ sở. Đây là lý do tại sao các trường hợp sử dụng được bao gồm có thể là: a) các trường hợp sử dụng cơ sở theo quyền riêng của họ và b) được chia sẻ bởi một số trường hợp sử dụng cơ sở.

mở rộng

Ca sử dụng mở rộng phụ thuộc vào ca sử dụng cơ sở; nó thực sự mở rộng hành vi được mô tả bởi trường hợp sử dụng cơ sở. Ca sử dụng cơ sở phải là trường hợp sử dụng đầy đủ chức năng theo quyền riêng của mình ('bao gồm tất nhiên) mà không có chức năng bổ sung của ca sử dụng mở rộng.

Mở rộng các trường hợp sử dụng có thể được sử dụng trong một số tình huống:

1. Ca sử dụng cơ sở đại diện cho các ứng dụng cơ bản phải có chức năng của một dự án trong khi ca sử dụng mở rộng thể hiện hành vi tùy chọn (nên / có thể / muốn). Đây là nơi thuật ngữ tùy chọn có liên quan - tùy chọn có xây dựng / phân phối thay vì tùy chọn cho dù đôi khi nó chạy như một phần của chuỗi trường hợp sử dụng cơ sở.
2. Trong giai đoạn 1, bạn có thể phân phối trường hợp sử dụng cơ sở đáp ứng các yêu cầu tại thời điểm đó và giai đoạn 2 sẽ thêm chức năng bổ sung được mô tả bởi trường hợp sử dụng mở rộng. Điều này có thể chứa các chuỗi luôn luôn hoặc đôi khi được thực hiện sau khi giai đoạn 2 được đưa ra (một lần nữa trái với quan niệm sai lầm phổ biến).
3. Nó có thể được sử dụng để trích xuất các phần tiếp theo của trường hợp sử dụng cơ sở, đặc biệt khi chúng thể hiện hành vi phức tạp 'đặc biệt' với các luồng thay thế của chính nó.

Một khía cạnh quan trọng cần xem xét là trường hợp sử dụng mở rộng có thể 'chèn' hành vi vào một số vị trí trong luồng của trường hợp sử dụng cơ sở, không chỉ ở một nơi như trường hợp sử dụng đi kèm. Vì lý do này, rất khó có khả năng một trường hợp sử dụng mở rộng sẽ phù hợp để mở rộng nhiều hơn một trường hợp sử dụng cơ sở.

Đối với sự phụ thuộc, trường hợp sử dụng mở rộng phụ thuộc vào trường hợp sử dụng cơ sở và lại là phụ thuộc một chiều, tức là trường hợp sử dụng cơ sở không cần bất kỳ tham chiếu nào đến trường hợp sử dụng mở rộng trong chuỗi. Điều đó không có nghĩa là bạn không thể chứng minh các điểm mở rộng hoặc thêm x-ref vào trường hợp sử dụng mở rộng ở nơi khác trong mẫu, nhưng trường hợp sử dụng cơ sở phải có thể hoạt động mà không có trường hợp sử dụng mở rộng.

TÓM LƯỢC

Tôi hy vọng tôi đã chỉ ra rằng quan niệm sai lầm phổ biến về bao gồm luôn luôn, mở rộng đôi khi là sai hoặc là đơn giản nhất. Phiên bản này thực sự có ý nghĩa hơn nếu bạn xem xét tất cả các vấn đề về tính định hướng của mũi tên mà quan niệm sai lầm thể hiện - trong mô hình chính xác, nó chỉ phụ thuộc và không có khả năng thay đổi nếu bạn cấu trúc lại nội dung ca sử dụng.

Tôi thường sử dụng điều này để ghi nhớ hai:

Trường hợp sử dụng của tôi: Tôi sẽ đến thành phố.

bao gồm -> lái xe

kéo dài -> đổ xăng

"Đổ xăng" có thể không cần thiết mọi lúc, nhưng có thể tùy chọn được yêu cầu dựa trên lượng xăng còn lại trong xe. "Lái xe" là điều kiện tiên quyết do đó tôi bao gồm.

Các trường hợp sử dụng được sử dụng để ghi lại hành vi, ví dụ trả lời câu hỏi này.

Một hành vi mở rộng một hành vi khác nếu nó ngoài nhưng không nhất thiết là một phần của hành vi, ví dụ như nghiên cứu câu trả lời.

Cũng lưu ý rằng nghiên cứu câu trả lời sẽ không có ý nghĩa nhiều nếu bạn không cố gắng trả lời câu hỏi.

Một hành vi được bao gồm trong hành vi khác nếu đó là một phần của hành vi bao gồm, ví dụ đăng nhập để trao đổi ngăn xếp.

Để làm rõ, hình minh họa chỉ đúng nếu bạn muốn trả lời ở đây trong stack overflow :).

Đây là các định nghĩa kỹ thuật từ UML 2.5 trang 671-672.

Tôi nhấn mạnh những gì tôi nghĩ là những điểm quan trọng.

Mở rộng

Extend là mối quan hệ từ UseCase mở rộng (phần mở rộng) đến UseCase mở rộng (ExtendedCase) chỉ định cách thức và thời điểm hành vi được xác định trong UseCase mở rộng có thể được chèn vào hành vi được xác định trong UseCase mở rộng. Tiện ích mở rộng diễn ra tại một hoặc nhiều điểm mở rộng cụ thể được xác định trong UseCase mở rộng.

Extend được dự định sẽ được sử dụng khi có một số hành vi bổ sung cần được thêm vào, có thể là điều kiện , cho hành vi được xác định trong một hoặc nhiều UseCase.

Các usecase mở rộng được xác định một cách độc lập của Usecase mở rộng và có ý nghĩa độc lập với usecase mở rộng . Mặt khác, UseCase mở rộng thường xác định hành vi có thể không nhất thiết phải có ý nghĩa . Thay vào đó, UseCase mở rộng xác định một tập các gia số hành vi mô đun làm tăng sự thực thi của UseCase mở rộng trong các điều kiện cụ thể.

...

Bao gồm

Bao gồm là một DirectedRelationship giữa hai UseCase, chỉ ra rằng hành vi của UseCase đi kèm (phần bổ sung) được chèn vào hành vi của UseCase ( bao gồm cảCase ). Nó cũng là một loại NamedE bổ sung để nó có thể có một tên trong bối cảnh sử dụng UseCase (bao gồm cảCase). UseCase bao gồm có thể phụ thuộc vào các thay đổi được tạo ra bằng cách thực thi UseCase đi kèm. UseCase đi kèm phải có sẵn để hành vi của UseCase bao gồm được mô tả hoàn toàn.

Mối quan hệ Bao gồm được dự định sẽ được sử dụng khi có các phần chung của hành vi của hai hoặc nhiều UseCase. Phần chung này sau đó được trích xuất thành một UseCase riêng biệt, được bao gồm bởi tất cả các UseCase cơ sở có phần chung này . Vì việc sử dụng chính của mối quan hệ Bao gồm là sử dụng lại các phần chung, phần còn lại trong cơ sở UseCase thường không hoàn thành mà chỉ phụ thuộc vào các phần được bao gồm có ý nghĩa. Điều này được phản ánh theo hướng của mối quan hệ, chỉ ra rằng UseCase cơ sở phụ thuộc vào sự bổ sung chứ không phải ngược lại.

...

Tôi nghĩ điều quan trọng là phải hiểu ý định bao gồm và mở rộng:

"Mối quan hệ bao gồm nhằm mục đích tái sử dụng hành vi được mô hình hóa bởi một trường hợp sử dụng khác , trong khi mối quan hệ mở rộng được dự định để thêm các phần vào các trường hợp sử dụng hiện tại cũng như để mô hình hóa các dịch vụ hệ thống tùy chọn " (Overgaard và Palmkvist, Các trường hợp sử dụng: Mô hình và Bản thiết kế. -Wesley, 2004).

Điều này đọc cho tôi là:

Bao gồm = tái sử dụng chức năng (nghĩa là chức năng đi kèm được sử dụng hoặc có thể được sử dụng ở nơi khác trong hệ thống). Bao gồm do đó biểu thị một phụ thuộc vào trường hợp sử dụng khác.

Mở rộng = thêm (không tái sử dụng) chức năng và cũng có tùy chọn chức năng. Do đó, mở rộng có thể biểu thị một trong hai điều:
1. thêm mới tính năng / khả năng mới vào trường hợp sử dụng (tùy chọn hoặc không)
2. bất kỳ trường hợp sử dụng tùy chọn nào (hiện có hay không).

Tóm lược:
Bao gồm = tái sử dụng chức năng
Mở rộng = chức năng mới và / hoặc tùy chọn

Bạn thường sẽ tìm thấy cách sử dụng thứ 2 (tức là chức năng tùy chọn) của phần mở rộng, bởi vì nếu chức năng không phải là tùy chọn, thì hầu hết thời gian nó được tích hợp vào trường hợp sử dụng, thay vì là phần mở rộng. Ít nhất đó là kinh nghiệm của tôi. (Julian C chỉ ra rằng đôi khi bạn thấy cách sử dụng thứ 1 (tức là thêm các tính năng mới) của các phần mở rộng khi dự án bước vào giai đoạn 2).

Để đơn giản hóa,

cho include

1. Khi trường hợp sử dụng cơ sở được thực thi, trường hợp sử dụng đi kèm được thực thi MỌI THỨ .
2. Ca sử dụng cơ sở yêu cầu hoàn thành ca sử dụng đi kèm để hoàn thành.

một ví dụ điển hình: giữa đăng nhập và xác minh mật khẩu

(đăng nhập) --- << bao gồm >> --- > (xác minh mật khẩu)

để quá trình đăng nhập thành công, "xác minh mật khẩu" cũng phải thành công.

cho extend

1. Khi trường hợp sử dụng cơ sở được thực thi, trường hợp sử dụng mở rộng chỉ được thực hiện SOMETIMES
2. Trường hợp sử dụng mở rộng sẽ chỉ xảy ra khi đáp ứng một số tiêu chí nhất định.

một ví dụ điển hình: giữa thông tin đăng nhập và hiển thị thông báo lỗi (đôi khi chỉ xảy ra)

(đăng nhập) < --- << extend >> --- (hiển thị thông báo lỗi)

"Hiển thị thông báo lỗi" đôi khi chỉ xảy ra khi quá trình đăng nhập thất bại.

Tôi nghĩ những gì msdn giải thích ở đây khá dễ hiểu.

Bao gồm [5]

Một bao gồm các cuộc gọi sử dụng hoặc gọi một cuộc gọi bao gồm. Bao gồm được sử dụng để hiển thị cách trường hợp sử dụng chia thành các bước nhỏ hơn. Trường hợp sử dụng bao gồm ở đầu mũi tên.

Kéo dài [6]

Trong khi đó, trường hợp sử dụng mở rộng thêm mục tiêu và các bước cho trường hợp sử dụng mở rộng. Các phần mở rộng chỉ hoạt động trong các điều kiện nhất định. Trường hợp sử dụng mở rộng là ở đầu mũi tên.

Hãy làm cho điều này rõ ràng hơn. Chúng tôi sử dụnginclude mỗi khi chúng tôi muốn bày tỏ sự thật rằng sự tồn tại của một trường hợp phụ thuộc vào sự tồn tại của một trường hợp khác.

VÍ DỤ:

Một người dùng chỉ có thể mua sắm trực tuyến sau khi anh ta đã đăng nhập vào tài khoản của mình. Nói cách khác, anh ta không thể mua sắm cho đến khi đăng nhập vào tài khoản của mình.

Người dùng không thể tải xuống từ một trang web trước khi tài liệu được tải lên. Vì vậy, tôi không thể tải xuống nếu không có gì được tải lên.

Bạn hiểu không?

Đó là về hậu quả có điều kiện. Tôi không thể làm điều này nếu trước đây tôi không làm điều đó .

Ít nhất, tôi nghĩ rằng đây là cách chúng ta sử dụng đúng Include. Tôi có xu hướng nghĩ ví dụ với Laptop và bảo hành từ ngay phía trên là thuyết phục nhất!

Bất cứ khi nào có điều kiện tiên quyết cho một usecase sau đó, hãy đi kèm.

đối với các giai đoạn có xác thực, trường hợp xấu nhất hoặc là tùy chọn thì hãy gia hạn ..

ví dụ: đối với trường hợp sử dụng tìm kiếm nhập học, cuộc hẹn, đặt vé BẠN PHẢI điền vào mẫu đơn (mẫu đăng ký hoặc phản hồi) .... đây là nơi bao gồm ..

ví dụ: đối với trường hợp sử dụng xác minh đăng nhập hoặc đăng nhập vào tài khoản của bạn, xác thực của bạn là điều bắt buộc. Cũng nghĩ về các trường hợp xấu nhất. Giống như trả lại sách với tiền phạt..Không nhận được đặt trước..tiết hóa đơn SAU NGÀY NGÀY..đây là nơi mở rộng đến chơi ...

không lạm dụng bao gồm và mở rộng trong các sơ đồ.

GIỮ NÓ ĐƠN GIẢN HƠN !!!

Ngoài ra, hãy cẩn thận với phiên bản UML: đã lâu rồi << sử dụng >> và << bao gồm >> đã được thay thế bằng << bao gồm >> và << mở rộng >> bằng << mở rộng >> VÀ khái quát hóa .
Đối với tôi đó thường là điểm gây hiểu lầm: như một ví dụ về bài đăng và liên kết của Stephanie là về một phiên bản cũ:

Khi thanh toán cho một mặt hàng, bạn có thể chọn thanh toán khi giao hàng, thanh toán bằng paypal hoặc thanh toán bằng thẻ. Đây là tất cả các lựa chọn thay thế cho trường hợp sử dụng "trả tiền cho mặt hàng". Tôi có thể chọn bất kỳ tùy chọn nào trong số này tùy thuộc vào sở thích của tôi.

Trong thực tế, không có thay thế thực sự cho "trả tiền cho mặt hàng"! Ngày nay, UML, "thanh toán khi giao hàng" là một phần mở rộng và "thanh toán bằng paypal" / "thanh toán bằng thẻ" là các chuyên ngành.

"Bao gồm" được sử dụng để mở rộng trường hợp sử dụng cơ sở và đó là điều kiện bắt buộc tức là bao gồm trường hợp sử dụng chạy phải chạy thành công để hoàn thành sử dụng cơ sở.

ví dụ: Xem xét trường hợp Dịch vụ Email, ở đây "Đăng nhập" là trường hợp sử dụng được bao gồm phải được chạy để gửi Email (Trường hợp sử dụng cơ sở)

"Loại trừ" mặt khác là trường hợp sử dụng tùy chọn mở rộng trường hợp sử dụng cơ sở, trường hợp sử dụng cơ sở có thể chạy thành công ngay cả khi không gọi / gọi trường hợp sử dụng mở rộng.

ví dụ: coi "Mua máy tính xách tay" là trường hợp sử dụng cơ sở và "Bảo hành bổ sung" là trường hợp sử dụng mở rộng, tại đây bạn có thể chạy trường hợp sử dụng cơ sở "Mua máy tính xách tay" ngay cả khi không có bảo hành bổ sung.

Đây là tài nguyên tuyệt vời với lời giải thích tuyệt vời: Bao gồm những gì trong trường hợp sử dụng? Mở rộng tại trường hợp sử dụng là gì?

Mở rộng trường hợp sử dụng thường xác định hành vi tùy chọn. Nó là độc lập với trường hợp sử dụng mở rộng

Bao gồm được sử dụng để trích xuất các phần chung của hành vi của hai hoặc nhiều trường hợp sử dụng

Các yếu tố sơ đồ

• Diễn viên: Còn được gọi là Vai trò. Tên và bản mẫu của một diễn viên có thể được thay đổi trong tab Thuộc tính của nó.

• Kế thừa: Quan hệ sàng lọc giữa các tác nhân. Mối quan hệ này có thể mang một tên và khuôn mẫu.

• Các trường hợp sử dụng: Chúng có thể có Điểm mở rộng.

• Điểm mở rộng: Điều này xác định vị trí có thể thêm tiện ích mở rộng.

• Hiệp hội: Giữa vai trò và trường hợp sử dụng. Nó rất hữu ích để cung cấp cho các hiệp hội nói tên.

• Phụ thuộc: Giữa các trường hợp sử dụng. Sự phụ thuộc thường có một khuôn mẫu để xác định rõ hơn vai trò của sự phụ thuộc. Để chọn bản mẫu, chọn phần phụ thuộc từ sơ đồ hoặc ngăn Điều hướng, sau đó thay đổi bản mẫu trong tab Thuộc tính. Có hai loại phụ thuộc đặc biệt: <<extend>>và <<include>>, mà Poseidon cung cấp các nút riêng (xem bên dưới).

• Mở rộng mối quan hệ: Một mối quan hệ đơn hướng giữa hai trường hợp sử dụng. Mối quan hệ mở rộng giữa ca sử dụng B và ca sử dụng A có nghĩa là hành vi của B có thể được bao gồm trong A.

• Bao gồm mối quan hệ: Một mối quan hệ đơn hướng giữa hai trường hợp sử dụng. Mối quan hệ như vậy giữa các trường hợp sử dụng A và B có nghĩa là hành vi của B luôn được bao gồm trong A.

• Đường viền hệ thống: Đường viền hệ thống thực sự không được triển khai như là thành phần mô hình trong Poseidon cho UML. Bạn có thể chỉ cần vẽ một hình chữ nhật, gửi nó vào nền và sử dụng nó làm đường viền hệ thống bằng cách đặt tất cả các trường hợp sử dụng tương ứng bên trong hình chữ nhật.

Cả hai <include>và <extend>đều phụ thuộc vào lớp cơ sở nhưng <extend>là tùy chọn, nghĩa là nó có nguồn gốc từ lớp cơ sở nhưng theo quan điểm của người dùng, nó có thể được sử dụng hoặc có thể không được sử dụng.

<include>được kết hợp trong lớp cơ sở, nghĩa là bắt buộc phải sử dụng <include>trong trường hợp sử dụng của bạn nếu không nó sẽ bị coi là không đầy đủ.

ví dụ:

Trong xây dựng máy ATM (theo quan điểm của người dùng):

1: Rút tiền, gửi tiền mặt và kiểm tra tài khoản theo <extend>vì nó phụ thuộc vào người dùng nên rút hay gửi hoặc kiểm tra. Đây là những điều tùy chọn người dùng làm.

2: "Nhập mã pin, đặt thẻ, xóa thẻ" đây là những điều thuộc về <include> vì người dùng phải, và nên, đặt thẻ và nhập mã pin hợp lệ để xác minh.

Tôi không khuyên bạn nên sử dụng điều này để ghi nhớ hai điều sau:

Trường hợp sử dụng của tôi: Tôi sẽ đến thành phố.

bao gồm -> lái xe

kéo dài -> đổ xăng

Tôi muốn bạn sử dụng: Trường hợp sử dụng của tôi: Tôi sẽ đến thành phố.

kéo dài -> lái xe

bao gồm -> đổ xăng

Am được dạy rằng mở rộng mối quan hệ tiếp tục hành vi của một lớp cơ sở. Các chức năng lớp cơ sở phải ở đó. Mặt khác, mối quan hệ bao gồm gần giống với các chức năng có thể được gọi. Tháng năm in đậm.

Điều này có thể được nhìn thấy từ việc tái sử dụng agilemodeling trong các mô hình ca sử dụng

Sự khác biệt giữa cả hai đã được giải thích ở đây. Nhưng điều chưa được giải thích là thực tế <<include>>và<<extend>> đơn giản là không nên sử dụng.

Nếu bạn đọc Bittner / Spence, bạn biết rằng các trường hợp sử dụng là về tổng hợp, không phải phân tích. Việc sử dụng lại các trường hợp sử dụng là vô nghĩa. Nó rõ ràng cho thấy rằng bạn đã cắt tên miền của bạn sai. Giá trị gia tăng phải là duy nhất mỗi se. Việc sử dụng lại giá trị gia tăng duy nhất mà tôi biết là nhượng quyền thương mại. Vì vậy, nếu bạn đang kinh doanh bánh burger, tốt đẹp. Nhưng mọi nơi khác, nhiệm vụ của bạn là BA là cố gắng tìm USP. Và điều đó phải được trình bày trong trường hợp sử dụng tốt.

Bất cứ khi nào tôi thấy mọi người sử dụng một trong những mối quan hệ đó là khi họ cố gắng thực hiện phân rã chức năng. Và điều đó hoàn toàn sai.

Nói một cách đơn giản: nếu bạn có thể trả lời sếp của mình mà không do dự "Tôi đã làm xong ..." thì "..." là trường hợp sử dụng của bạn kể từ khi bạn có tiền để làm việc đó. (Điều đó cũng sẽ làm rõ rằng "đăng nhập" hoàn toàn không phải là trường hợp sử dụng.)

Về khía cạnh đó, việc tìm kiếm các trường hợp sử dụng tự đứng được bao gồm hoặc mở rộng các trường hợp sử dụng khác là rất khó xảy ra. Cuối cùng, bạn có thể sử dụng <<extend>>để hiển thị tùy chọn của hệ thống của mình, tức là một số lược đồ cấp phép cho phép bao gồm các trường hợp sử dụng cho một số giấy phép hoặc bỏ qua chúng. Nhưng khác - chỉ cần tránh chúng.

Mở rộng được sử dụng khi bạn hiểu rằng trường hợp sử dụng của bạn quá phức tạp. Vì vậy, bạn trích xuất các bước phức tạp vào các trường hợp sử dụng "mở rộng" của riêng họ.

Bao gồm được sử dụng khi bạn thấy hành vi phổ biến trong hai trường hợp sử dụng. Vì vậy, bạn trừu tượng hóa các hành vi phổ biến thành một trường hợp sử dụng "trừu tượng" riêng biệt.

(ref: Jeffrey L. Whitten, Lonnie D. Bentley, Phương pháp phân tích & thiết kế hệ thống, McGraw-Hill / Irwin, 2007)

Các bao gồm mối quan hệ cho phép một trường hợp sử dụng để bao gồm các bước của trường hợp sử dụng khác.

Ví dụ: giả sử bạn có Tài khoản Amazon và bạn muốn kiểm tra đơn hàng, thì không thể kiểm tra đơn hàng mà không đăng nhập vào tài khoản của bạn trước. Vì vậy, dòng sự kiện muốn như vậy ...

Các mở rộng mối quan hệ được sử dụng để bổ sung thêm một bước đến dòng chảy của một trường hợp sử dụng, mà thường là một bước không bắt buộc ...

Hãy tưởng tượng rằng chúng tôi vẫn đang nói về tài khoản amazon của bạn. Giả sử trường hợp cơ sở là Đơn hàng và trường hợp sử dụng tiện ích mở rộng là Amazon Prime . Người dùng có thể chọn chỉ đặt hàng thường xuyên hoặc người dùng có tùy chọn chọn Amazon Prime để đảm bảo đơn hàng của mình sẽ đến nhanh hơn với chi phí cao hơn.

Tuy nhiên, lưu ý rằng người dùng không phải chọn Amazon Prime, đây chỉ là một tùy chọn, họ có thể chọn bỏ qua trường hợp sử dụng này.

Tôi thích nghĩ "bao gồm" như một điều kiện tiên quyết / đệm cần thiết của trường hợp sử dụng cơ sở. Điều này có nghĩa là trường hợp sử dụng cơ sở không thể được coi là hoàn thành nếu không có trường hợp sử dụng. Tôi sẽ đưa ra ví dụ về một trang web thương mại điện tử bán các mặt hàng cho khách hàng. Không có cách nào bạn có thể trả tiền cho một mặt hàng mà không cần chọn mặt hàng đó trước và đưa nó vào giỏ hàng. Điều này ngụ ý rằng trường hợp sử dụng "Trả tiền cho vật phẩm" bao gồm "mục chọn".

Có nhiều cách sử dụng khác nhau nhưng tôi muốn nghĩ về nó như là một cách thay thế có thể hoặc không thể sử dụng. Ví dụ - vẫn trên trang web thương mại điện tử. Khi thanh toán cho một mặt hàng, bạn có thể chọn thanh toán khi giao hàng, thanh toán bằng paypal hoặc thanh toán bằng thẻ. Đây là tất cả các lựa chọn thay thế cho trường hợp sử dụng "trả tiền cho mặt hàng". Tôi có thể chọn bất kỳ tùy chọn nào trong số này tùy thuộc vào sở thích của tôi.

Để rõ hơn và các quy tắc xung quanh các trường hợp sử dụng, hãy đọc bài viết của tôi ở đây:

http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics