What's is the difference between include and e

Question

What is the difference between include and extend in a use case diagram?

Answer 1

This is great resource with great explanation: What is include at use case? What is Extend at use case?

Extending use case typically defines optional behavior. It is independent of the extending use case

Include used to extract common parts of the behaviors of two or more use cases

Answer 2

The include relationship allows one use case to include the steps of another use case.

For example, suppose you have an Amazon Account and you want to check on an order, well it is impossible to check on the order without first logging into your account. So the flow of events would like so...

The extend relationship is used to add an extra step to the flow of a use case, that is usually an optional step...

Imagine that we are still talking about your amazon account. Lets assume the base case is Order and the extension use case is Amazon Prime. The user can choose to just order the item regularly, or, the user has the option to select Amazon Prime which ensure his order will arrive faster at higher cost.

However, note that the user does not have to select Amazon Prime, this is just an option, they can choose to ignore this use case.

Answer 3

Both <include> and <extend> are dependent on the base class but <extend> is optional i.e., it is derived from the base class but in the point of users view it may be used or may not be used.

<include> is incorporated in base class i.e., it is compulsary to use <include> in your use case or else it would be considered incomplete.

eg:

In ATM machine construction (according to users point of view):

1: Withdrawal,deposit of cash and checking the account comes under <extend> because it depends on the user whether to withdraw or deposit or check. These are optional things the user does.

2: "Enter the pin, placing card, removal of card" these are the things that come under <include> because the user must, and should, place a card and enter a valid pin for verification.

Answer 4

Let's make this clearer. We use include every time we want to express the fact that the existence of one case depends on the existence of another.

EXAMPLES:

A user can do shopping online only after he has logged in his account. In other words, he can't do any shopping until he has logged in his account.

A user can't download from a site before the material had been uploaded. So, I can't download if nothing has been uploaded.

Do you get it?

It's about conditioned consequence. I can't do this if previously I didn't do that.

At least, I think this is the right way we use Include. I tend to think the example with Laptop and warranty from right above is the most convincing!

Answer 5

This may be contentious but the “includes are always and extends are sometimes” is a very common misconception which has almost taken over now as the de-facto meaning. Here’s a correct approach (in my view, and checked against Jacobson, Fowler, Larmen and 10 other references).

Relationships are dependencies

The key to Include and extend use case relationships is to realize that, common with the rest of UML, the dotted arrow between use cases is a dependency relationship. I’ll use the terms ‘base’, ‘included’ and ‘extending’ to refer to the use case roles.

include

A base use case is dependent on the included use case(s); without it/them the base use case is incomplete as the included use case(s) represent sub-sequences of the interaction that may happen always OR sometimes. (This is contrary to a popular misconception about this, what your use case suggests always happens in the main scenario and sometimes happens in alternate flows simply depends on what you choose as your main scenario; use cases can easily be restructured to represent a different flow as the main scenario and this should not matter).

In the best practice of one way dependency the base use case knows about (and refers to) the included use case, but the included use case shouldn’t ‘know’ about the base use case. This is why included use cases can be: a) base use cases in their own right and b) shared by a number of base use cases.

extend

The extending use case is dependent on the base use case; it literally extends the behavior described by the base use case. The base use case should be a fully functional use case in its own right (‘include’s included of course) without the extending use case’s additional functionality.

Extending use cases can be used in several situations:

1. The base use case represents the “must have” functionality of a project while the extending use case represents optional (should/could/want) behavior. This is where the term optional is relevant – optional whether to build/deliver rather than optional whether it sometimes runs as part of the base use case sequence.
2. In phase 1 you can deliver the base use case which meets the requirements at that point, and phase 2 will add additional functionality described by the extending use case. This can contain sequences that are always or sometimes performed after phase 2 is delivered (again contrary to popular misconception).
3. It can be used to extract out subsequences of the base use case, especially when they represent ‘exceptional’ complex behavior with its own alternative flows.

One important aspect to consider is that the extending use case can ‘insert’ behavior in several places in the base use case’s flow, not just in a single place as an included use case does. For this reason, it is highly unlikely that an extending use case will be suitable to extend more than one base use case.

As to dependency, the extending use case is dependent on the base use case and is again a one-way dependency, i.e. the base use case doesn’t need any reference to the extending use case in the sequence. That doesn’t mean you can’t demonstrate the extension points or add a x-ref to the extending use case elsewhere in the template, but the base use case must be able to work without the extending use case.

SUMMARY

I hope I’ve shown that the common misconception of “includes are always, extends are sometimes” is either wrong or at best simplistic. This version actually makes more sense if you consider all the issues about the directionality of the arrows the misconception presents – in the correct model it’s just dependency and doesn’t potentially change if you refactor the use case contents.

Answer 6

Use cases are used to document behavior, e.g. answer this question.

A behavior extends another if it is in addition to but not necessarily part of the behavior, e.g. research the answer.

Also note that researching the answer doesn't make much sense if you are not trying to answer the question.

A behavior is included in another if it is part of the including behavior, e.g. login to stack exchange.

To clarify, the illustration is only true if you want to answer here in stack overflow :).

These are the technical definitions from UML 2.5 pages 671-672.

I highlighted what I think are important points.

Extends

An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase. The extension takes place at one or more specific extension points defined in the extended UseCase.

Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in one or more UseCases.

The extended UseCase is defined independently of the extending UseCase and is meaningful independently of the extending UseCase. On the other hand, the extending UseCase typically defines behavior that may not necessarily be meaningful by itself. Instead, the extending UseCase defines a set of modular behavior increments that augment an execution of the extended UseCase under specific conditions.

...

Includes

Include is a DirectedRelationship between two UseCases, indicating that the behavior of the included UseCase (the addition) is inserted into the behavior of the including UseCase (the includingCase). It is also a kind of NamedElement so that it can have a name in the context of its owning UseCase (the includingCase). The including UseCase may depend on the changes produced by executing the included UseCase. The included UseCase must be available for the behavior of the including UseCase to be completely described.

The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common. As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. This is reflected in the direction of the relationship, indicating that the base UseCase depends on the addition but not vice versa.

...