Date post: | 30-Dec-2015 |
Category: |
Documents |
Upload: | christen-alvarado |
View: | 34 times |
Download: | 2 times |
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