USE CASES Ch 6 in Textbook ( Applying UML & Patterns )

1. USE CASESCh 6 in Textbook(Applying UML & Patterns)

2. Decision Point & BranchingBuy Items • A Use case may contain decision points such as in Buy Items, the customer may choose to pay via cash, credit or check. • If one of them is the typical case (usual), then the typical case is the one written in Typical course of events, and the other alternatives should be written in the Alternatives section. • If all the alternatives are equal in their likelihood, (like the payment types), write in the main section of Typical course of events a branch event, that indicates that the possible branches are written in subsections. • Then write a subsection for each branch, again using Typical course of events • If subsections have alternatives, write them in an Alternatives section.

3. Example: Decision Point & BranchingBuy Items Section: Main System Response 4. Logs the completed sale 5. Prints a receipt Actor Action • This use case begins when a Customer arrives at POST checkout with items to purchase • .. • Customer chooses payment type: a. If cash payment, see section pay by Cash b. If credit payment, see section pay by Credit d. If check payment, see section pay by Check 6. The cashier gives the receipt to the customer 7. The customer leaves with the items

4. Section: Pay by Cash System Response 3. Shows the balance due back to the Customer Actor Action • The customer gives a cash payment- possible greater than the sale total • The Cashier records the cash tendered 4. The Cashier deposits the cash received and extracts the balance owing The Cashier gives the balance owing to the Customer Alternative Courses: Line 4: Insufficient cash in drawer to pay balance. Ask for cash from supervisor, or ask Customer for a payment closer to sale total

5. POST Buy Items Customer Log In Refund Purchased Items Start Up Manager Manage Users System administrator Etc. <<actor>> CAS Cashier

8. Alternatives?

9. The <<extends>> Relationship • <<extends>> relationships represent exceptional or seldom invoked cases. • A reusable use case (component) that conditionally interrupts (is invoked optionally -- like a menu selection in an application) the execution of another use case to augment its functionality. • The functionality in the original problem statement needs to be extended. • The exceptional event flows are factored out of the main event flow for clarity. • The base use case can be executed without the use case extension in extend associations. • The responsibility for deciding when the extending use case should be used lies with the extending use case. • Arrow points to use case being extended. Extended use case Extending use case

10. Help FieldOfficer f <<extend>> ReportEmergency The <<extends>> Relationship • Use cases representing exceptional flows can extend more than one use case. • The direction of an <<extends>> relationship is to the extended use case • For example: the use case “ReportEmergency” is complete by itself , but can be extended by the use case “Help” for a specific scenario in which the user requires help

11. When to Use <<extends>> Relationship • Major variation: If you have a major alternative path in the use case, and it’s complex enough to have its own alternative paths, then placing it on your diagram will honestly expose the complexity—which is helpful in costing, assignment, and scheduling. • Optional subgoal: If you have parts of the use case that would be optional to implement (or even optional to execute) to meet the actor’s goals, put those parts into their own use case. Doing so clarifies the relationships between actors and their goals. It also emphasizes that you may deliver these optional goals in later releases. http://dotnet.org.za/hannes/archive/2006/01/31/use-cases-when-to-use-includes-generalization-and-extending.aspx

12. Passenger PurchaseTicket <<extends>> OutOfOrder TimeOut <<extends>> <<extends>> <<extends>> Cancel NoChange

13. ManageIncident CloseIncident HandleIncident CreateIncident The <<extends>> Relationship <<Extend>> <<Extend>> <<Extend>>

14. The <<extends>> Relationship

15. The <<extends>> Relationship

16. Bank System

18. The <<includes>> Relationship • <<includes>> relationship represents behavior that is factored out of the use case. A use case uses another use case (“functional decomposition”) • Used to indicate that one use case includes the functionality of another use case. • A function in the original problem statement is too complex to be solvable immediately • Describe the function as the aggregation of a set of simpler functions. The associated use case is decomposed into smaller use cases • A reusable use case (component) that is unconditionally called into the execution of another use case (always included in the process – like running BIOS in a system boot). Included use case Including use case

19. Passenger PurchaseMultiTicket PurchaseSingleTicket <<includes>> <<includes>> NoChange Cancel CollectMoney <<extends>> <<extends>> • Responsibility for the decision about when to use it lies with the calling use case. • Arrow points to the included use case. The direction of a <<includes>> relationship is to the using use case (unlike <<extends>> relationships).

20. The <<includes>> Relationship

24. Actor Generalization

25. University Registration System