A use case diagram is a type of behavioral diagram defined by the Unified Modeling Language (UML) that depicts the interactions between actors and the system under consideration. It visually shows the different use cases along with actors, theirgoals as related to the specific system, and any relationships that may exist between use cases. There are two main types of relationships that can exist between use cases in a use case diagram – include and extend relationships.

The include relationship shows that the behaviors of one use case are included in another use case. It represents a whole-part relationship where the behavior of the included use case is always executed as part of the behavior of the including use case. The included use case cannot exist by itself and is always executed when its including use case occurs. As an example, a ‘Place Order’ use case may include the behaviors of an ‘Add Item to Cart’ use case, since adding items to the cart needs to be completed before an order can be placed. In this scenario, the ‘Add Item to Cart’ use case would be the included use case and ‘Place Order’ would be the including use case.

There are some key characteristics of the include relationship:

The included use case is always executed when the including use case occurs. The including use case cannot be executed without the included use case also executing.

The included use case does not have a meaningful execution separate from the including use case. It augments or contributes to the behavior of the including use case but cannot occur independently.

The included use case must provide some functionality that is necessary for the successful completion of the including use case. Its inclusion is dependent on and subordinate to the including use case.

Breaking the included behavior out into a separate use case avoids cluttering the including use case with unnecessary details and subtasks.

An included use case is shown using a dashed arrow pointing from the including use case to the included use case.

In contrast, the extend relationship connects two different use cases where one use case sometimes conditionally extends the behavior of another use case under certain specific conditions or situations. It represents optional or alternative flows that may occur within another use case.

The characteristics of an extend relationship are:

The extending use case augments or interrupts the flow of the base use case under specific conditions or scenarios but is not always required for the execution of the base use case.

The extension adds extra behavioral flows to the base use case under predefined conditions or goals but the base use case can still be executed independently without the extension taking place.

The extension use case encapsulates the optional or conditionally dependent behaviors that sometimes occur with the base use case. This avoids cluttering the base use case with complex conditional or exception branches.

An extending use case is represented using a dashed lined arrow with a triangular arrow pointing from the extending use case to the base use case it extends.

Some examples could include optional registration/login extending a checkout process, additional validation steps extending a form submission, or upsell/cross-sell extensions occurring with a purchase process.

To summarize the main differences:

Include relationship represents behaviors that must always occur as part of another use case, while extend depicts optional behaviors that sometimes modify another use case conditionally.

Included use cases cannot exist independently, while extending use cases can exist on their own without the base use case.

Include focuses on mandatory subordinate behaviors while extend models exception/contingency flows.

Included use cases are integral to and dependent on the including use case, but extensions are independent of the base use case they extend.

So in use case diagrams, the include relationship decomposes mandatory behaviors into subordinate use cases, whereas the extend relationship encapsulates alternative or optional flows that may sometimes modify the primary usage workflow represented by another use case under certain preconditions. Understanding the contrasting semantics of include and extend relationships is important for accurately modeling system behavior and requirements using use case diagrams.