Date post: | 19-Jan-2016 |
Category: |
Documents |
Upload: | donald-mathews |
View: | 216 times |
Download: | 4 times |
Sept 2005 92.3913 Ron McFadyen 1
Use Cases
Introduced by Ivar Jacobson in 1986
•literal translation from Swedish ”usage case”
Used to capture and describe the functionality encompassed in some system or subsystem – a tool for analysis
A use case will illustrate one or more scenarios – one typical path and many alternative scenarios
A use case captures a goal of using the system
Use cases can be used to guide development of testing plans
Sept 2005 92.3913 Ron McFadyen 2
Use Cases
Illustrated with diagrams and/or a behaviour specification (written in text form)
A project may begin with the definition of many “brief” or “casual” use case definitions – a few sentences each.
Later on, these can be become very formal or “fully dressed”
(for example see alistair.cockburn.us/usecases/uctempla.htm)
The UML defines the nature of the diagrams, but not the behaviour specifications – companies standardize their own approaches
Sept 2005 92.3913 Ron McFadyen 3
Use Cases in the UML
•Functionality under consideration is represented by use cases (named ellipses)
•Actors are connected to use cases they use through associations
Use Cases
Sept 2005 92.3913 Ron McFadyen 4
• Actor (typically a stick person)
• Use Case (a named ellipse)
• Associations (lines)
– Between Actors and Use Cases
– Between Use Cases
– Between Actors
Use Cases
Sept 2005 92.3913 Ron McFadyen 5
Actors
• Actors represent the people or other systems that interact with the system.
• Each actor is drawn as a stick person with the name written underneath
• An actor represents a set of roles that users of a system may assume
• In a university registration system, we might have:
Student Registration Manager
Registration Advisor
Chair
Sept 2005 92.3913 Ron McFadyen 6
Use Case Behaviour
• A use case is drawn as an ellipse, with its name within or below the ellipse
• A use case should be written as a behaviour specification separately from the diagram (the written use case)
• other UML diagrams (statechart, sequence, activity) can be used to illustrate behavioural information in a use case
• A use case will be implemented as a computer program and the actors initiate execution (or instantiation) of a use case
• A use case describe what a system does, not how it does it – a design activity is to determine how a use case is carried out.
Sept 2005 92.3913 Ron McFadyen 7
Use Case Example
• We might begin describing a registration system as:
Register
Manage coursesStudent
Department Chair
Generate report
Registration Clerk
Registration
Between actors and use cases we draw associations (the lines) to indicate the use cases each actor can instantiate
Sept 2005 92.3913 Ron McFadyen 8
Example: Processing a Sale at a Cash Register
• Use Case UC1: Process Sale• Primary Actor: Cashier• …• Preconditions: Cashier is identified and authenticated• Postconditions: Sale is saved…Commissions recorded…Payment
authorization approvals recorded• Main Success Scenario:1. Customer arrives at POS checkout with goods and/or services to
purchase2. Cashier starts a new sale3. Cashier enters item identifier4. System records sale line item and presents item description, price, and
running total. Price calculated from a set of price rules.Cashier repeats steps 3-4 until indicates done.5. System presents total with taxes calculated…
Sept 2005 92.3913 Ron McFadyen 9
Process Sale Use Case
Cashier repeats steps 3-4 until indicates done.
5. System presents total with taxes calculated
6. Cashier tells customer the total, and asks for payment.
7. Customer pays and System handles payment
8. System logs completed sale and sends sale and payment information to the external Accounting System and Inventory System.
9. System presents receipt
10. Customer leaves with receipt and goods
Sept 2005 92.3913 Ron McFadyen 10
Process Sale Use Case
• Extensions or Alternate Flows*a. At any time, the System fails:
1. Cashier restarts System, logs in, and requests recovery of prior sale2. System reconstructs prior state. …
3a. Invalid identifier:1. System signals error and rejects entry
3b. There are multiple of same item category and tracking unique item identity is not important (e.g. 5 packages of veggie burgers)1. Cashier can enter item category identifier and the quantity
…4a. The system generated item price is not wanted …
1. Cashier enters override price.2. System presents new price.
… Identifies the step where this condition may arise.
“*” means any step; “4” means at step 4; a letter following identifies a different exception
Sept 2005 92.3913 Ron McFadyen 11
Use Case Associations
• Between use case and actor
– uses
• Between use cases
– include
– extend
– generalization
• Between actors
– generalization
Sept 2005 92.3913 Ron McFadyen 12
Relating Use Cases
• Include relationship
• If one use case is designed to utilize the functionality of another use case there is an “include” dependency
• Consider that a base use case is executing. When it reaches the inclusion point, the included use case is instantiated and executed, and when it finishes the base use case continues.
• “Include” is a way to factor commonality out of use cases to make the design more modular
• Suppose the Process Sale use case is designed to use the functionality of Handle Credit Payment and the Handle Check Payment use cases.
Sept 2005 92.3913 Ron McFadyen 13
Process Sale Use Case
• Extensions or Alternate Flows
……
7a. Customer pays with a credit card: include HandleCreditPayment
7b. Customer pays by cheque: include HandleChequePayment
7a and 7b show alternative ways for step 7 to complete
The Process Sale use case has explicit statements referring to other use cases ….. These are include dependencies …. Like calling a function or subroutine
Instead of the word include, we could use something else such as execute
Sept 2005 92.3913 Ron McFadyen 14
Include Relationship
• In the UML diagram
Process Sale
Handle Cheque Payment
Handle Credit Payment
<<include>>
<<include>>
Process Sale has a dependency on Handle Check Payment, and another dependency on Handle Credit Payment
The dashed lines and the stick arrowhead are the correct way to depict these dependencies
Sept 2005 92.3913 Ron McFadyen 15
Include Relationship
• Suppose a Purchase order system has two use cases Place Order and Track Order and both contain customer validation.
• Customer validation could be factored out, resulting in:
Validate Customer
<<include>>
<<include>>
Track Order
Place Order
Customer
Sept 2005 92.3913 Ron McFadyen 16
Generalization/Specialization Relationship
• Suppose there is more than one version of a use case, and that the different versions have some things in common and other things that differentiate them
• The general notation is
Specialized use case name
Generalized use case name
Sept 2005 92.3913 Ron McFadyen 17
Generalization/Specialization Relationship
• Example. Figure 3.14: specializations of RegisterCarSharer
Manually add car sharer
Register car sharer
Transfer car sharer from web-server
Car match administrator
Add car sharer web service
Third party
Sept 2005 92.3913 Ron McFadyen 18
Generalization/Specialization of Actors
• Generalization can be applied to Actors.
• Example. Suppose for the department chair, who is a member of the faculty, there are some special duties
Faculty
Chair
Assign Grades
Manage Sections
Note that the Chair can do everything a faculty member can do, but also the Chair manages the sections of courses the department offers.
Sept 2005 92.3913 Ron McFadyen 19
Generalization/Specialization of Actors
• What use cases can a Faculty execute?
• What use cases can a Chair execute?
Faculty
Chair
Assign Grades
Manage Sections
Sept 2005 92.3913 Ron McFadyen 20
Extend Relationship
• The extend relationship is typically used for optional behaviour
• Extend is used to separate optional from mandatory behaviour
• Under a specified condition the base use case is extended with the behaviour specified in the extending use case.
• We say the extending use case is dependent on the base use case (note the directed line in the drawing)
Sept 2005 92.3913 Ron McFadyen 21
Extend Relationship
• Process Sale collects the payment from the customer. Suppose payment via a gift certificate is considered an exceptional case, or for some reason we don’t want to alter the Process Sale use case
<<extend>>
Handle Gift Certificate Payment
Cashier Payment, if the Customer presents a gift certificate
Process SaleExtension Points:
Payment
Sept 2005 92.3913 Ron McFadyen 22
Extend Relationship
• Process Sale declares/states “Payment” is an extension point, but Process Sale does not know anything more about this - the condition, the name of the other use case, …
<<extend>>
Handle Gift Certificate Payment
Cashier Payment, if the Customer presents a gift certificate
Process SaleExtension Points:
Payment
Sept 2005 92.3913 Ron McFadyen 23
Example: Handle Gift Certificate Use Case
• Use Case UC7: Handle Gift Certificate
• Trigger: customer intends to pay with a gift certificate
• Extension Points: Payment in Process Sale
• Level: subfunction
• Main Success Scenario:
1. Customer gives gift certificate to cashier
2. Cashier enters id for gift certificate
3. System verifies certificate
Sept 2005 92.3913 Ron McFadyen 24
Example: Processing a Sale at a Cash Register
• Use Case UC1: Process Sale• Primary Actor: Cashier• …• Preconditions: Cashier is identified and authenticated• Postconditions: Sale is saved…Commissions recorded…Payment
authorization approvals recorded• Extension Points: Payment, step 7.• Main Success Scenario:1. Customer arrives at POS checkout with goods and/or services to purchase2. Cashier starts a new sale3. Cashier enters item identifier4. System records sale line item and presents item description, price, and
running total. Price calculated from a set of price rules.Cashier repeats steps 3-4 until indicates done.5. System presents total with taxes calculated…
There are no substantive changes to the Process Sale use case
Why would we use extend instead of include?