UML use case diagram - extension points identification

UML use case diagram - extension points identification - uml

Can you tell me if I understand extension points correctly in use cases (and in the diagram)?
For use case 'Card Payment' and and extend use case 'Pay by credit card' is it properly identified that extension point wil be "User clicks pay by card button"? Or should it be "system asks for the payment method"?

The identification of the extension points is correct.
The problem is however that the extensions should not be extensions at all.
From the UML specs 2.5:
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.
So your use case make a payment should be indedepent from the extending use cases pay by credit card and pay by cash. This is clearly not the case since you need the extending use cases to have a meaningful and complete behavior.
There are several alternative solutions to using extensions in this case.
A single use case: Simply incorporate the extending use cases into the main make a payment use case. You can create alternate scenarios for the different payment options. This is probably the best option as your use cases are way too granular anyway. Use cases should be about the main goals a user should have when using the system. Not about functions the system provides.
Include: You can use an include relation to (conditionally) include the other use cases behavior into your main use case. This would be more appropriate because the main use cases relies in the result of the included use cases and is incomplete without them.
Generalization: You could specialize make a payment with pay by cash and pay by credit card. Generalization between use cases is allowed, but generally discouraged by a lot of practitioners.

Related

Can someone explain the difference between <<extends>> and <<includes>> relationships? [duplicate]

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

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.

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:
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.
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).
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.

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.

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.
...

To simplify,
for include
When the base use case is executed, the included use case is executed EVERYTIME.
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
When the base use case is executed, the extended use case is executed only SOMETIMES
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.

I think it's important to understand the intention of includes and extends:
"The include relationship is intended for reusing behaviour modeled
by another use case, whereas the extend relationship is intended for
adding parts to existing use cases as well as for modeling optional system services" (Overgaard and Palmkvist, Use Cases: Patterns and Blueprints. Addison-Wesley, 2004).
This reads to me as:
Include = reuse of functionality (i.e. the included functionality is used or could be used elsewhere in the system). Include therefore denotes a dependency on another use case.
Extends = adding (not reusing) functionality and also any optional functionality. Extends therefore can denote one of two things:
1. adding new features/capabilities to a use case (optional or not)
2. any optional use cases (existing or not).
Summary:
Include = reuse of functionality
Extends = new and/or optional functionality
You will most often find the 2nd usage (i.e. optional functionality) of extends, because if functionality is not optional, then most times it is built into the use case itself, rather than being an extension. At least that's been my experience. (Julian C points out that you sometimes see the 1st usage (i.e. adding new features) of extends when a project enters it's 2nd phase).

I think what msdn explained here are quite easy to understand.
Include [5]
An including use case calls or invokes the included one. Inclusion is used to show how a use case breaks into smaller steps. The included use case is at the arrowhead end.
Extend [6]
Meanwhile, an extending use case adds goals and steps to the extended use case. The extensions operate only under certain conditions. The extended use case is at the arrowhead end.

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!

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.
KEEP IT SIMPLE SILLY!!!

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.

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

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.

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.

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

I don't recommend the use of this to remember the two:
My use case: I am going to the city.
includes -> drive the car
extends -> fill the petrol
I would rather you use:
My use case: I am going to the city.
extends -> driving the car
includes -> fill the petrol
Am taught that extend relationship continues the behaviour of a base class. The base class functionalities have to be there.
The include relationship on the other hand, are akin to functions that may be called. May is in bold.
This can be seen from
agilemodeling Reuse in Use-Case Models

The difference between both has been explained here. But what has not been explained is the fact that <<include>> and <<extend>> should simply not be used at all.
If you read Bittner/Spence you know that use cases are about synthesis, not analysis. A re-use of use cases is nonsense. It clearly shows that you have cut your domain wrongly. Added value must be unique per se. The only re-use of added value I know is franchise. So if you are in burger business, nice. But everywhere else your task as BA is to try to find an USP. And that must be presented in good use cases.
Whenever I see people using one of those relations it is when they try to do functional decomposition. And that's plain wrong.
To put it simple: if you can answer your boss without hesitation "I have done ..." then the "..." is your use case since you got money for doing it. (That will also make clear that "login" is not a use case at all.)
In that respect, finding self standing use cases that are included or extend other use cases is very unlikely. Eventually you can use <<extend>> to show optionality of your system, i.e. some licensing schema which allows to include use cases for some licenses or to omit them. But else - just avoid them.

Extends is used when you understand that your use case is too much complex. So you extract the complex steps into their own "extension" use cases.
Includes is used when you see common behavior in two use cases. So you abstract out the common behavior into a separate "abstract" use case.
(ref: Jeffrey L. Whitten, Lonnie D. Bentley, Systems analysis & design methods, McGraw-Hill/Irwin, 2007)

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.

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:
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics

A way I remember it is by video games. For example,
(the below is not for 100% of all cases but just an example of a use case)
Extends: The main menu extends some functionality, which means they have some functionality on them but not necessary to be pressed
Includes: in order to fire a weapon in a video game you must have one first.

UML Extend relationship [duplicate]

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

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.

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.

To simplify,
for include
When the base use case is executed, the included use case is executed EVERYTIME.
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
When the base use case is executed, the extended use case is executed only SOMETIMES
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.

I think it's important to understand the intention of includes and extends:
"The include relationship is intended for reusing behaviour modeled
by another use case, whereas the extend relationship is intended for
adding parts to existing use cases as well as for modeling optional system services" (Overgaard and Palmkvist, Use Cases: Patterns and Blueprints. Addison-Wesley, 2004).
This reads to me as:
Include = reuse of functionality (i.e. the included functionality is used or could be used elsewhere in the system). Include therefore denotes a dependency on another use case.
Extends = adding (not reusing) functionality and also any optional functionality. Extends therefore can denote one of two things:
1. adding new features/capabilities to a use case (optional or not)
2. any optional use cases (existing or not).
Summary:
Include = reuse of functionality
Extends = new and/or optional functionality
You will most often find the 2nd usage (i.e. optional functionality) of extends, because if functionality is not optional, then most times it is built into the use case itself, rather than being an extension. At least that's been my experience. (Julian C points out that you sometimes see the 1st usage (i.e. adding new features) of extends when a project enters it's 2nd phase).

I think what msdn explained here are quite easy to understand.
Include [5]
An including use case calls or invokes the included one. Inclusion is used to show how a use case breaks into smaller steps. The included use case is at the arrowhead end.
Extend [6]
Meanwhile, an extending use case adds goals and steps to the extended use case. The extensions operate only under certain conditions. The extended use case is at the arrowhead end.

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!

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.
KEEP IT SIMPLE SILLY!!!

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.

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

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.

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.

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

I don't recommend the use of this to remember the two:
My use case: I am going to the city.
includes -> drive the car
extends -> fill the petrol
I would rather you use:
My use case: I am going to the city.
extends -> driving the car
includes -> fill the petrol
Am taught that extend relationship continues the behaviour of a base class. The base class functionalities have to be there.
The include relationship on the other hand, are akin to functions that may be called. May is in bold.
This can be seen from
agilemodeling Reuse in Use-Case Models

The difference between both has been explained here. But what has not been explained is the fact that <<include>> and <<extend>> should simply not be used at all.
If you read Bittner/Spence you know that use cases are about synthesis, not analysis. A re-use of use cases is nonsense. It clearly shows that you have cut your domain wrongly. Added value must be unique per se. The only re-use of added value I know is franchise. So if you are in burger business, nice. But everywhere else your task as BA is to try to find an USP. And that must be presented in good use cases.
Whenever I see people using one of those relations it is when they try to do functional decomposition. And that's plain wrong.
To put it simple: if you can answer your boss without hesitation "I have done ..." then the "..." is your use case since you got money for doing it. (That will also make clear that "login" is not a use case at all.)
In that respect, finding self standing use cases that are included or extend other use cases is very unlikely. Eventually you can use <<extend>> to show optionality of your system, i.e. some licensing schema which allows to include use cases for some licenses or to omit them. But else - just avoid them.

Extends is used when you understand that your use case is too much complex. So you extract the complex steps into their own "extension" use cases.
Includes is used when you see common behavior in two use cases. So you abstract out the common behavior into a separate "abstract" use case.
(ref: Jeffrey L. Whitten, Lonnie D. Bentley, Systems analysis & design methods, McGraw-Hill/Irwin, 2007)

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.

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:
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics

A way I remember it is by video games. For example,
(the below is not for 100% of all cases but just an example of a use case)
Extends: The main menu extends some functionality, which means they have some functionality on them but not necessary to be pressed
Includes: in order to fire a weapon in a video game you must have one first.

Use Case Inlcude vs Extend [duplicate]

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

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.

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.

To simplify,
for include
When the base use case is executed, the included use case is executed EVERYTIME.
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
When the base use case is executed, the extended use case is executed only SOMETIMES
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.

I think it's important to understand the intention of includes and extends:
"The include relationship is intended for reusing behaviour modeled
by another use case, whereas the extend relationship is intended for
adding parts to existing use cases as well as for modeling optional system services" (Overgaard and Palmkvist, Use Cases: Patterns and Blueprints. Addison-Wesley, 2004).
This reads to me as:
Include = reuse of functionality (i.e. the included functionality is used or could be used elsewhere in the system). Include therefore denotes a dependency on another use case.
Extends = adding (not reusing) functionality and also any optional functionality. Extends therefore can denote one of two things:
1. adding new features/capabilities to a use case (optional or not)
2. any optional use cases (existing or not).
Summary:
Include = reuse of functionality
Extends = new and/or optional functionality
You will most often find the 2nd usage (i.e. optional functionality) of extends, because if functionality is not optional, then most times it is built into the use case itself, rather than being an extension. At least that's been my experience. (Julian C points out that you sometimes see the 1st usage (i.e. adding new features) of extends when a project enters it's 2nd phase).

I think what msdn explained here are quite easy to understand.
Include [5]
An including use case calls or invokes the included one. Inclusion is used to show how a use case breaks into smaller steps. The included use case is at the arrowhead end.
Extend [6]
Meanwhile, an extending use case adds goals and steps to the extended use case. The extensions operate only under certain conditions. The extended use case is at the arrowhead end.

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!

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.
KEEP IT SIMPLE SILLY!!!

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.

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

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.

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.

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

I don't recommend the use of this to remember the two:
My use case: I am going to the city.
includes -> drive the car
extends -> fill the petrol
I would rather you use:
My use case: I am going to the city.
extends -> driving the car
includes -> fill the petrol
Am taught that extend relationship continues the behaviour of a base class. The base class functionalities have to be there.
The include relationship on the other hand, are akin to functions that may be called. May is in bold.
This can be seen from
agilemodeling Reuse in Use-Case Models

The difference between both has been explained here. But what has not been explained is the fact that <<include>> and <<extend>> should simply not be used at all.
If you read Bittner/Spence you know that use cases are about synthesis, not analysis. A re-use of use cases is nonsense. It clearly shows that you have cut your domain wrongly. Added value must be unique per se. The only re-use of added value I know is franchise. So if you are in burger business, nice. But everywhere else your task as BA is to try to find an USP. And that must be presented in good use cases.
Whenever I see people using one of those relations it is when they try to do functional decomposition. And that's plain wrong.
To put it simple: if you can answer your boss without hesitation "I have done ..." then the "..." is your use case since you got money for doing it. (That will also make clear that "login" is not a use case at all.)
In that respect, finding self standing use cases that are included or extend other use cases is very unlikely. Eventually you can use <<extend>> to show optionality of your system, i.e. some licensing schema which allows to include use cases for some licenses or to omit them. But else - just avoid them.

Extends is used when you understand that your use case is too much complex. So you extract the complex steps into their own "extension" use cases.
Includes is used when you see common behavior in two use cases. So you abstract out the common behavior into a separate "abstract" use case.
(ref: Jeffrey L. Whitten, Lonnie D. Bentley, Systems analysis & design methods, McGraw-Hill/Irwin, 2007)

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.

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:
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics

A way I remember it is by video games. For example,
(the below is not for 100% of all cases but just an example of a use case)
Extends: The main menu extends some functionality, which means they have some functionality on them but not necessary to be pressed
Includes: in order to fire a weapon in a video game you must have one first.

what is the difference and purpose of Include and Exclude? [duplicate]

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

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.

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.

To simplify,
for include
When the base use case is executed, the included use case is executed EVERYTIME.
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
When the base use case is executed, the extended use case is executed only SOMETIMES
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.

I think it's important to understand the intention of includes and extends:
"The include relationship is intended for reusing behaviour modeled
by another use case, whereas the extend relationship is intended for
adding parts to existing use cases as well as for modeling optional system services" (Overgaard and Palmkvist, Use Cases: Patterns and Blueprints. Addison-Wesley, 2004).
This reads to me as:
Include = reuse of functionality (i.e. the included functionality is used or could be used elsewhere in the system). Include therefore denotes a dependency on another use case.
Extends = adding (not reusing) functionality and also any optional functionality. Extends therefore can denote one of two things:
1. adding new features/capabilities to a use case (optional or not)
2. any optional use cases (existing or not).
Summary:
Include = reuse of functionality
Extends = new and/or optional functionality
You will most often find the 2nd usage (i.e. optional functionality) of extends, because if functionality is not optional, then most times it is built into the use case itself, rather than being an extension. At least that's been my experience. (Julian C points out that you sometimes see the 1st usage (i.e. adding new features) of extends when a project enters it's 2nd phase).

I think what msdn explained here are quite easy to understand.
Include [5]
An including use case calls or invokes the included one. Inclusion is used to show how a use case breaks into smaller steps. The included use case is at the arrowhead end.
Extend [6]
Meanwhile, an extending use case adds goals and steps to the extended use case. The extensions operate only under certain conditions. The extended use case is at the arrowhead end.

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!

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.
KEEP IT SIMPLE SILLY!!!

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.

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

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.

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.

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

I don't recommend the use of this to remember the two:
My use case: I am going to the city.
includes -> drive the car
extends -> fill the petrol
I would rather you use:
My use case: I am going to the city.
extends -> driving the car
includes -> fill the petrol
Am taught that extend relationship continues the behaviour of a base class. The base class functionalities have to be there.
The include relationship on the other hand, are akin to functions that may be called. May is in bold.
This can be seen from
agilemodeling Reuse in Use-Case Models

The difference between both has been explained here. But what has not been explained is the fact that <<include>> and <<extend>> should simply not be used at all.
If you read Bittner/Spence you know that use cases are about synthesis, not analysis. A re-use of use cases is nonsense. It clearly shows that you have cut your domain wrongly. Added value must be unique per se. The only re-use of added value I know is franchise. So if you are in burger business, nice. But everywhere else your task as BA is to try to find an USP. And that must be presented in good use cases.
Whenever I see people using one of those relations it is when they try to do functional decomposition. And that's plain wrong.
To put it simple: if you can answer your boss without hesitation "I have done ..." then the "..." is your use case since you got money for doing it. (That will also make clear that "login" is not a use case at all.)
In that respect, finding self standing use cases that are included or extend other use cases is very unlikely. Eventually you can use <<extend>> to show optionality of your system, i.e. some licensing schema which allows to include use cases for some licenses or to omit them. But else - just avoid them.

Extends is used when you understand that your use case is too much complex. So you extract the complex steps into their own "extension" use cases.
Includes is used when you see common behavior in two use cases. So you abstract out the common behavior into a separate "abstract" use case.
(ref: Jeffrey L. Whitten, Lonnie D. Bentley, Systems analysis & design methods, McGraw-Hill/Irwin, 2007)

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.

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:
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics

A way I remember it is by video games. For example,
(the below is not for 100% of all cases but just an example of a use case)
Extends: The main menu extends some functionality, which means they have some functionality on them but not necessary to be pressed
Includes: in order to fire a weapon in a video game you must have one first.

Use case generalization versus extension

UML Use Case Diagrams allow for two seemingly equivalent ways to show that a given use case might be realised in several different ways namely use case generalizations as opposed to use case extensions. I have seen the following basically example modelled using either approach with equal frequency, sometimes within a single source.
To my mind an extension is a weaker relationship than generalization as a direct substitution of the specialised use case for the base case must be possible in generalization but not necessarily in extensions.
It seems to me that generalisation implies a polymorphic implementation is desired while extension implies some branching structure is to be used.
void makePayment(const PaymentDetails* pd)
{
pd->pay();
}
as opposed to
void makePayment(const PaymentDetails* pd)
{
switch(pd->type)
{
case EFT:
payViaEFT(pd);
break;
case PAYPAL:
payViaPayPal(pd);
break;
case CREDITCARD:
payViaCreditCard(pd);
break;
}
}
Isn't the Use Case stage far too early for such implementation specific concerns to be modelled? There are much more appropriate UML diagrams for that. Is there a hard and fast rule regarding which of the two to use and if so what is it?

To my mind an extension is a weaker relationship than generalization
as a direct substitution of the specialised use case for the base case
must be possible in generalization but not necessarily in extensions.
That is true.
It seems to me that generalisation implies a polymorphic
implementation is desired while extension implies some branching
structure is to be used.
The diagram does not dictate any implementation.
You can interpret a hint from the diagram for yourself, though. UML remains independent of language and solution there.
Isn't the Use Case stage far too early for such implementation
specific concerns to be modelled?
Well, as indicated above, UML does not enforce any specific kind of implementation.
However, you are gathering some important functional requirements here that might greatly influence your time schedule and workload. ("Pay with credit card" is way more complex to handle than "pay in advance by bank transfer"). So you'd strive to capture that but remain open to different solution approaches.
There are much more appropriate UML
diagrams for that.
You can really use them in parallel :) as they are different views on the same subject.
Is there a hard and fast rule regarding which of
the two to use and if so what is it?
I prefer the generalization in this case because the extensions falsely suggest there could be a way of paying without using any of the three named options. As you indicated yourself.
Addendum (as per comments): The high-level purpose of the example diagram is to outline the foreseen payment means. A payment needs at least one means (unless payment is cancelled), just like "print" is too vague without clarifications such as "what" and "where". Hence my preference for using the generalization, despite "make payment" being a valid use case in itself.

When modelling with an extend relationship, the extending use case (pay via xxx) is executed when the extended use case (make payment) is at a precise location (given by the extension point, payment type) if the condition for such extend relationship holds (e.g. for "Pay via Paypal", the condition would be payment_type=PAYPAL). In this model, "Pay via Paypal" does only deals with the details of completing a payment transaction with Paypal, while "Make Payment" specifies all the behaviors that are independent of the payment method (such as computing the total amount, and saving the result of the transaction once that it was performed).
On the other hand, generalization (which is defined not only for use cases, but also for any classifier) is a broader concept, since it do not detail (at the diagram level) the details of when and how the specialized behaviors are executed. If "Pay via Paypal" were a specialization of "Make Payment" it would redefine the behavior of "Make Payment", which could be substantially different from the behavior of "Pay via credit card".
Being an extending use case does not means that the alternatives have to be hardcoded. Indeed, your first example is also a valid implementation of a extend relationship, since pd->pay(pd) will invoke different behaviors depending on the selected payment type. Actually, use case diagram models what a system is supposed to do, while low-level implementation details are better specified in activity diagrams.

An example of an extension would be a "Discount Payment" use case. Discounting a payment has to do with making a payment, but you don't have to discount a payment in order to make the payment.
You can look at the "is a" relationship to make the determination of which to use. Pay by PayPal "is a" make payment, a specific way of making a payment. Discounting a payment isn't. It's something additional you can do while making a payment.

Develop Reference

node.js excel linux python-3.x azure haskell apache-spark rust .htaccess string