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

0 votes
asked Nov 8, 2009 by sevugarajan

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

17 Answers

0 votes
answered Nov 15, 2009 by doug-knesek

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 ATM machine. "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.

0 votes
answered Nov 17, 2010 by julian-c

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.


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.


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.


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.

0 votes
answered Nov 1, 2011 by vinay-narang

whenever there are prerequisites to a usecase then,go for include.

for usecases having authentication,worst case scenario,or are optional then go for extend..

example:for a use case of seeking admission,appointment,ticket reservation YOU MUST FILL A form (registration or feedback form)....this is where include comes..

example:for a use case verifying login or sign in your account,your authentication is a must.also think of worst case scenarios.like returning book with fine..NOT getting a reservation..paying the bill AFTER DUE DATE..this is where extend comes to play...

do not overuse include and extend in the diagrams.


0 votes
answered Jan 19, 2012 by lourdhu-kumar

Diagram Elements

  • Actors: Also referred to as Roles. Name and stereotype of an actor can be changed in its Properties tab.

  • Inheritance: Refinement relations between actors. This relation can carry a name and a stereotype.

  • Use cases: These can have Extension Points.

  • Extension Points: This defines a location where an extension can be added.

  • Associations: Between roles and use cases. It is useful to give associations speaking names.

  • Dependencies: Between use cases. Dependencies often have a stereotype to better define the role of the dependency. To select a stereotype, select the dependency from the diagram or the Navigation pane, then change the stereotype in the Properties tab. There are two special kinds of dependencies: <<extend>> and <<include>>, for which Poseidon offers own buttons (see below).

  • Extend relationship: A uni-directional relationship between two use cases. An extend relationship between use case B and use case A means that the behavior of B can be included in A.

  • Include relationship: A uni-directional relationship between two use cases. Such a relationship between use cases A and B means, that the behavior of B is always included in A.

  • System border: The system border is actually not implemented as model element in Poseidon for UML. You can simply draw a rectangle, send it to the background and use it as system border by putting all corresponding use cases inside the rectangle.

0 votes
answered Jan 24, 2012 by sarbjit

"Include" is used to extend the base use case and it is a must condition i.e. included use case run must run successfully to complete base use.

e.g. Consider a case of Email Service, here "Login" is a included use case which must be run in order to send a Email (Base use case)

"Exclude" on the other hand is optional use case which extends the base use case, base use case can run successfully even without invoking/calling the extending use case.

e.g. Consider "Laptop Purchase" as base use case and "Additional Warranty" as extending use case, here you can run base use case "Laptop Purchase" even without taking additional warranty.

0 votes
answered Nov 27, 2012 by alin-andrei

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


An user can do shopping online only after he logged into his account. Other said, he can't do any shopping until he logged into his account.

An 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!

0 votes
answered Jan 5, 2013 by navya-reddy-maistry

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.


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.

0 votes
answered Jan 23, 2013 by stephanie-famuyide

I like to think of "includes" as a necessary prerequisite/accompaniment of the base use case. This means that the base use case cannot be considered complete without the use case it includes. I'll give the example of an e-commerce website that sells items to customers. There's no way you can pay for an item without first selecting that item and putting it in the cart. This implies that the use case "Pay for Item" includes "select item".

There are varying uses of extends but I like to think of it as an alternative that may or may not be used. For example - still on the e-commerce site. When paying for an item, you may choose to pay on delivery, pay using paypal or pay by card. These are all alternatives to the "pay for item" use case. I may choose any of these options depending on my preference.

For more clarity and the rules surrounding use cases, read my article here:


0 votes
answered Nov 3, 2013 by skipy

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.

0 votes
answered Nov 21, 2013 by sylvain-h

Also beware of the UML version : it's been a long time now that << uses >> and << includes >> have been replaced by << include >>, and << extends >> by << extend >> AND generalization.
For me that's often the misleading point : as an example the Stephanie's post and link is about an old version :

When paying for an item, you may choose to pay on delivery, pay using paypal or pay by card. These are all alternatives to the "pay for item" use case. I may choose any of these options depending on my preference.

In fact there is no really alternative to "pay for item" ! In nowadays UML, "pay on delivery" is an extend, and "pay using paypal"/"pay by card" are specializations.

Welcome to Q&A, where you can ask questions and receive answers from other members of the community.
Website Online Counter