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

User · Answer

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.

User · Answer

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

User · Answer

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

User · Answer

The difference between both has been explained here  But what has not been explained is the fact that  lt  lt include gt  gt  and  lt  lt extend gt  gt  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  lt  lt extend gt  gt  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

User · Answer

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  ---  lt  lt  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   lt ---  lt  lt  extend    ---  show error message    show error message  only happens sometimes when the login process failed

User · Answer

Both  lt include gt  and  lt extend gt  are dependent on the base class but  lt extend gt  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    lt include gt  is incorporated in base class i e   it is compulsary to use  lt include gt  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  lt extend gt  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  lt include gt  because the user must  and should  place a card and enter a valid pin for verification

User · Answer

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   lt  lt extend gt  gt  and  lt  lt include gt  gt   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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

Also beware of the UML version   it s been a long time now that  lt  lt  uses    and  lt  lt  includes    have been replaced by  lt  lt  include     and  lt  lt  extends    by  lt  lt  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

User · Answer

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

User · Answer

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  amp  design methods  McGraw-Hill Irwin  2007

User · Answer

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

User · Answer

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

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

Examples related to uml

Examples related to use-case

Examples related to rational-unified-process