1. Auburn University http://www.eng.auburn.edu/~xqin
COMP 2710 Software Construction Use Case Analysis and Exercises (Part 2)
Dr. Xiao Qin
Auburn University
Dropbox example:

2. Review: Use Case Diagrams UML use case relationship -symbols
Relationships: Use cases may be related to other use cases. 2

3. Review: UML use case relationship symbols - Generalization
A use case that is a variation on normal behavior of another use case describes a generalization relationship.
These generalization use case relationships can be used to describe actions when an alternative behavior must be carried out for some reason. 3

4. UML use case relationship Generalization - Example4

5. Exercise 3 – Generalization
Please create a use case diagram using the following component
Phone Order,
Customer
Internet customer
Place Order,
Internet Order 5

6. UML use case relationship symbols – include or use
A use case may include another use case.
A use case that is included is generally a common behavior that many use cases may need.
One use case will use the services of another use case.
<<includes>>, <<include>>, <<use>>, <<uses>> 6

7. UML use case relationship include or use - Example7

8. Exercise 4 – UML use case relationship include or use
Review Transcript Data use case is used by the Register for Course use case to be sure the student has met the course's prerequisites.
Review Transcript Data use case is also used by Review Graduate Student use case to be sure that all program requirements have been met for graduation.
(review transcript data) < <<include>> (register for course) students ^ |
<<include>>
reviewer (review graduate student) 8

9. UML use case relationship symbols – extend or extends
A use case may extend a use case by adding new actions to it.
<<includes>>, <<include>>, <<use>>, <<uses>> 9

10. UML use case relationship extend or extends - Example
Question? How about Turn – include -->turn left |
include V
turn right 10

11. Exercise 5 – UML use case relationship extend or extends
Use case Register for Distance Course may extend use case Register for Course.
Additional actions must be performed when a student registers for a distance course.
reviewer (register for course) <-- extend -- (register for distance course)
Pointing to the base case 11

12. What is the difference between uses/includes and extends?
Question? How about Turn – include -->turn left |
include V
turn right
Re: difference between extends and generalization in Use case diagrams?
References:
The extend relationship exists where one use case optionally has its behavior inserted into another. The extend relationship defines one or  more extension points within the extended use case and a condition.  When the first extension point is reached, the condition is evaluated  and the decision is made to insert the actions of the extending use  case or not.  The generalization relationship is good old fashioned inheritance. It  represents a taxonomic (eg "is a") relationship. In this case, the  specializing use case provides more specific actions that correspond to  the actions of the use case, but are special cases of those actions.  Ultimately, I think the difference here is comparable to the difference  between inheritance and composition of objects, just applied to use  cases. An extending use case may be reusable in ways that don't depend  on the extended case. For example, a retailer might extend a "make  payment" use case with "apply for credit card". The latter use case  need not be tied solely to the "make payment" use case.  The generalization relationship between use cases is under used in  practice, probably because there aren't many examples out there showing  how to use it. An example of this would be "make payment" generalizing  "make payment by check", "make payment by credit card", "make payment  by gift certificate" etc... Each of these specializations accomplishes  the actions of "make payment".  I personally, think generalization use cases are very useful, because  they allows you to outline a generic set of actions before enumerating  special cases that need special treatment. To use an extend  releationship, the extended use case has to identify the extensions,  including which use cases, the extension points, and the conditions.  Not so with a generalization. If tomorrow the system requirements  change so that payment via paypal is accepted, I do not have to rewrite  the "make payment" use case.  The biggest problem that prevents wider use of generalization is that  it seems hard to figure out a good way to document it when writing out  the use case steps in the typical actor action / system response  format. Some authors suggest a "do one of the following" step in the  general use case. I think that defeats the whole purpose of allowing  the parent not to care about what children exist or whether they even  do exist. I just imagine a "select payment type" question that will be  added at design time (or runtime via deployment descriptors, etc...) to  allow navigation to the use cases that specialize "make payment".  In UML 2.0 there are three kinds of directed relationships between use  cases: extend, include, and generalization. I actually think that  include is a special case of extend (occuring where the condition is  always true). These relationships have been revised several times, and  I still think they are somewhat confusing.  12

13. Development of a Use Case Diagram
Identify all of the actors who will use the system.
Interview these actors to identify the functions that they need to perform. (use cases)
Identify scenarios (sequence of steps to accomplish a use case).
Identify common steps within the different scenarios. Separate them into different use cases so that they can easily be included in other scenarios.
Identify relationships between use cases.
Give an example: Log in as a use case 13

14. Put it all together: 14

15. Flows of Events for Individual Use Cases - System Startup Use Case
The system is started up when the operator turns the operator switch to the "on" position.
The operator will be asked to enter the amount of money currently in the cash dispenser
A connection to the bank will be established.
Then the servicing of customers can begin.
Give an example: Log in as a use case 15

16. Flows of Events for Individual Use Cases Exercise - System shutdown Use Case
The system is shut down when the operator makes sure that no customer is using the machine, and then
turns the operator switch to the "off" position. The connection to the bank will be shut down. Then the
operator is free to remove deposited envelopes, replenish cash and paper, etc. 16

17. Summary Use Cases describe the behavioral aspects of the system.
Use cases are not design tools.
Use Cases are a convenient way to document the functions that the system must support.
Use Cases are used to identify the components (classes) of the system.
Use case relationships?
Why use cases are not design tools? - Just functional descriptions not software structure. 17