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

Question

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

Solution 1

Extend is used when a use case adds steps to another first-class use case.

For example, imagine "Withdraw Cash" is a use case of an Automated Teller Machine (ATM). "Assess Fee" would extend Withdraw Cash and describe the conditional "extension point" that is instantiated when the ATM user doesn't bank at the ATM's owning institution. Notice that the basic "Withdraw Cash" use case stands on its own, without the extension.

Include is used to extract use case fragments that are duplicated in multiple use cases. The included use case cannot stand alone and the original use case is not complete without the included one. This should be used sparingly and only in cases where the duplication is significant and exists by design (rather than by coincidence).

For example, the flow of events that occurs at the beginning of every ATM use case (when the user puts in their ATM card, enters their PIN, and is shown the main menu) would be a good candidate for an include.

Solution 2

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.

Solution 3

I often use this to remember the two:

My use case: I am going to the city.

includes -> drive the car

extends -> fill the petrol

"Fill the petrol" may not be required at all times, but may optionally be required based on the amount of petrol left in the car. "Drive the car" is a prerequisite hence I am including.

Solution 4

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.

...

Solution 5

To simplify,

for include

1. When the base use case is executed, the included use case is executed EVERYTIME.
2. The base use case required the completion of the included use case in order to be completed.

a typical example: between login and verify password

(login) --- << include >> ---> (verify password)

for the login process to success, "verify password" must be successful as well.

---

for extend

1. When the base use case is executed, the extended use case is executed only SOMETIMES
2. The extended use case will happen only when certain criteria are met.

a typical example: between login and show error message (only happened sometimes)

(login) <--- << extend >> --- (show error message)

"show error message" only happens sometimes when the login process failed.

View more solutions

Comments

[mibollma]

would be great if you could add some references for that claim

[Andrew Barber]

Welcome to Stack Overflow! Thanks for posting your answer! Please be sure to read the FAQ on Self-Promotion carefully. Not a bad answer, really; but just be aware of what the FAQ says about self-promotional posts.

[Blaze Tama]

Include is used to extract use case fragments that are duplicated in multiple use cases, what is extracted in those steps : puts in their ATM card, enters their PIN, and is shown the main menu? Thanks

[Bruno Brant]

I must disagree with including the "login" steps being a good candidate for a include. Those steps form a use case own their own, and should be linked to the others use cases by post-conditions -> pre-conditions.

[Doug Knesek]

@Bruno - No one would log in to an ATM machine and just walk away happy. Concrete use cases must provide stand-alone value to the actor, otherwise they are just functions in a functional decomposition.

[Doug Knesek]

@Blaze - All parts of the login flow, including those steps.

[Petr Hudeček]

But, "fill the petrol" actually extends "going to the city", not the other way around, right?

[Daniel Perník]

I think it depend on point of view Petr. Imho "fill the petrol" can actually extend drive the car as well.

[BigMac66]

Sorry, creating a UML diagram in this fashion as software goes through iterations that add new functionality that was always intended be required in the end state would just be needlessly confusing and complex. I prefer Doug Knesek's approach, much simpler to understand and work with while not creating any unnecessary confusion or complexity.

[OdraEncoded]

Going to the city and filling the petrol sound like two completely unrelated things which just might happen by coincidence.

[qwerty_so]

How could Assess Fee be a UC? This is a conditional flow in a scenario. It's not an added value at all. It's the complete opposite.

[Doug Knesek]

@ThomasKilian - From the UML 2.5: "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." And "the extending UseCase typically defines behavior that may not necessarily be meaningful by itself." It's the concrete Use Case that must provide value to the Actor; not the extending Use Case.

[qwerty_so]

I know what the UML spec says. But honestly, even OMG can be wrong. And this is simply a bad concept. See my own answer above.

[Doug Knesek]

@ThomasKilian - My objective was simply to answer given question. So I provided a simple UML 2.5 introductory example very similar to Jacobson's examples, since he invented the damned things. Personally, I use Use Cases to contextualize User Stories, and have found little use for "extends" relationships in the last decade. The OMG isn't wrong by definition, as they own the spec. They just don't have a monopoly on useful modeling heuristics.

[qwerty_so]

Sure. It's never wrong as it's their standard. But you know that the fact not being useful is the same as being wrong (so to say). Additionally this concept leads to using it the wrong way and that's even worse. Though 2.5 is an improvement over previous versions it still has quite a number of bugs/issues/wrong concepts. I think we could have a lengthy discussion on this without being able to change matters. So let's agree to not start with that ;-)

[Doug Knesek]

@ThomasKilian - I didn't say it wasn't useful in an absolute sense. It (and most of the UML) just hasn't been useful to me for a very long time. However, others may find the concept, as specified, useful in their contexts.

[Doug Knesek]

Although you are right to challenge the "includes are always and extends are sometimes" as it relates to Use Case instances, your choice to exploit "extend" semantics to support incremental delivery may lead others to think "extend" is ABOUT incremental delivery.

[Doug Knesek]

Let us continue this discussion in chat.

[baxx]

perhaps the case of "making" payment would serve as an "includes" for purchasing a laptop? I say this as it's nice to have the examples 'together' in the same scenario. Also, making a payment is something that would be used in many different scenarios, so it seems like it might be a suitable candidate for <<include>>.

[Doug Knesek]

Extend has nothing to do with a use case that is simply too complex. That approach will lead to building a functional decomposition rather than an actual Use Case model.

[mrmashal]

I think software engineering concepts and, in general, everything that approaches human sciences becomes much opinion-based. I've included the ref (See page 248). Don't be too hard on it man :)

[Geert Bellekens]

You should at least quote the essence in your answer, not simply add a link to an answer. On top of that the explanation you reference isn't really good or precise either.

[Etic]

Hi @GeertBellekens, I've added some detail to explain the difference between include and extend. IMHO the diagram itself clearly communicate the difference and that is what the diagram are used for.

[Geert Bellekens]

I'm glad you added the explanations, but I still think that they aren't very good or precise. People (even, or especially if they write for msdn) should stop inventing their own definitions for something that is already defined in a standard.

[AlphaGoku]

About extends ?

[nonybrighto]

@OdraEncoded is correct. Fill petrol is not dependent on going to the city.

[qwerty_so]

It rather should read "fill the petrol -> extends" since your main UC does not extend "fill petrol". Except you are a petrol company.

[qwerty_so]

UC diagram at the bottom of your link is just an anti-pattern. Neither login nor create account are use cases. Both are functions. Therefore -1

[qwerty_so]

What sort of use case should Amazon Prime be? It doesn't even contain a verb.

[qwerty_so]

Login is not a use case at all. It's a function performed to fulfill a pre-condition.

[Pavel Durov]

great example !

[Underlines]

Here's the UML 2.0 Specification document. It clearly defines what include vs. extend means for use cases: "16.3.3" at omg.org/spec/UML/2.0/Superstructure/PDF

[Andrew S]

Underlines, this is a large document, it would be more useful to add a page number to that response.

[testing_22]

So include is for "need to" whereas extend is for "may"