What is the difference between include
and extend
in a use case diagram?
相关问题
- System sequence diagram - Can system request input
- Does Visual Studio 2010 Professional support UML m
- Can a [GoF]-ConcreteSubject override the notify me
- How to represent enumeration classes with methods
- How to specify “one at a time” in UML?
相关文章
- Code Iris plugin on Android Studio
- Designing a sequence diagram for an auction system
- Game engine design choice [closed]
- state transition with different guard condition
- Resources for learning how to better read code
- What is a use-case? How to identify a use-case? [c
- Relationships in a UML class diagram
- How do you convert a document in UML 1.3 - XMI 1.1
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.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 :
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.
I think it's important to understand the intention of includes and extends:
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 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
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!!!
I think what msdn explained here are quite easy to understand.
Include [5]
Extend [6]