USE CASES

Ch 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 eventsIf subsections have alternatives, write them in an Alternatives section.

3

Example: Decision Point & BranchingBuy Items

Actor Action1. This use case begins when a

Customer arrives at POST checkout with items to purchase

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

System Response

4. Logs the completed sale

5. Prints a receipt

Section: Main

4

Section: Pay by Cash

Actor Action1. The customer gives a

cash payment- possible greater than the sale total

2. The Cashier records the cash tendered

4. The Cashier deposits the cash received and extracts the balance owingThe Cashier gives the balance owing to the Customer

System Response

3. Shows the balance due back 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

Start Up

Refund Purchased Items

Log In

Buy Items

System administrator

Manage Users

Etc.

Manager

Customer

Cashier

<<actor>>

CAS

6

7

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.

Extendeduse case

Extending use case

10

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

ReportEmergency

FieldOfficerfHelp

<<extend>>

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.

11http://dotnet.org.za/hannes/archive/2006/01/31/use-cases-when-to-use-includes-generalization-and-extending.aspx

12

Passenger

PurchaseTicket

TimeOut

<<extends>>

NoChange

<<extends>>OutOfOrder

<<extends>>

Cancel

<<extends>>

13

The <<extends>> Relationship

ManageIncident

CreateIncidentHandleIncident CloseIncident

<<Extend>>

<<Extend>><<Extend>>

The <<extends>> Relationship

14

The <<extends>> Relationship

15

16

Bank System

17

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

PurchaseSingleTicket

PurchaseMultiTicket

NoChange

<<extends>>

Cancel

<<extends>>

<<includes>>

CollectMoney

<<includes>>

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

The <<includes>> Relationship

20

21

22

23

Actor Generalization

24

25

University Registration System