Date post: | 20-Dec-2015 |
Category: |
Documents |
View: | 219 times |
Download: | 0 times |
Sept 2004 91.3913 Ron McFadyen 1
Use Cases
Introduced by Ivar Jacobson in 1986
•literal translation from Swedish ”usage case”
www.usecases.org - may be of use to you in the future
“blackbox” style is recommended - specify what the system must do, and not how it must do it.
A project may begin with the definition of many “brief” or “casual” use case definitions. Later on, these can be become “fully dressed”
Sept 2004 91.3913 Ron McFadyen 2
Use Cases
Widely used.
Not just an OO technique.
Each Use Case will meet one or more user goals
Collectively, Use Cases represent the functionality required by a system.
Stories of using a system to meet goals
Sept 2004 91.3913 Ron McFadyen 3
Use Cases
Ch 6. Use Case example is very lengthy and fairly complete
must read: pages 45-61, and sections 6.12, 6.13, 6.15
Ch 25 shows ways of managing Use Cases
Ch 25. The Use Case has been broken down into multiple Use Cases that are related via <<extend>> and <<include>>
must read: sections 25.1, 25.2, 25.3, 25.5
Ch 13. Contracts
Ch 9. System Sequence Diagrams
SSDs show the events that actors generate. The system is a black box and so the diagram emphasizes the events the system must respond to.
Sept 2004 91.3913 Ron McFadyen 4
Use Cases in the UML
•Functionality under consideration is represented by use cases (named ellipses) enclosed in a box
•Actors are shown outside the box
•Actors are connected to use cases they use by associations
Sept 21, 2003
Sept 2004 91.3913 Ron McFadyen 5
• Actor
• Use Case
• Associations
– Between Actors and Use Cases
– Between Use Cases
– Between Actors
Use Cases in the UML
Sept 2004 91.3913 Ron McFadyen 6
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 Clerk
Department Chair
Sept 2004 91.3913 Ron McFadyen 7
Use Case Behaviour
• A Use Case describes a sequence of actions that a system performs to achieve an observable result of value to an actor (something meaningful to a user)
• A use case is drawn as an ellipse, with its name within or below the ellipse
• A Use Case Model comprises the individual use cases that describe the system
• A use case describe what a system does, not how it does it
• A use case must be written as a behaviour specification separately from the diagram (the written use case)
• We will see that other UML diagrams (e.g.statechart, sequence) can illustrate behavioural information about a use case
• A use case will be implemented as a computer program and the actors initiate execution (or instantiation) of a use case
Sept 2004 91.3913 Ron McFadyen 8
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 2004 91.3913 Ron McFadyen 9
Figure 6.2 – a portion of
Handle ReturnsCashierPayment
Authorization Service
Process Rental
NextGen
…
Process Sale
Page 50-53 gives a written description of the Process Sale use case
Sept 2004 91.3913 Ron McFadyen 10
Process Sale Use Case P. 50+
Primary Actor:
Preconditions: describes a state the system must be in prior to the execution of the use case
Postconditions: describes a state the system must be in after execution of the use case
Main Success Scenario:
Step by step description of the interaction between the actor and the executing use case
Extensions or Alternate Flows
Alternate ways steps could terminate
At this point in time (Inception), processing a sale is described in one use case that contains a main success scenario and all possible alternative scenarios.
Some components of the written use case:
Sept 2004 91.3913 Ron McFadyen 11
Process Sale Use Case P. 50+
• 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 2004 91.3913 Ron McFadyen 12
Process Sale Use Case P. 50+
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
• Extensions or Alternate Flows
*a. At any time, the System fails:
1. Cashier restarts System, logs in, and requests recovery of prior sale
2. System reconstructs prior state. …
…
Sept 2004 91.3913 Ron McFadyen 13
Process Sale Use Case P. 50+
• 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 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 2004 91.3913 Ron McFadyen 14
Use Cases in the text
Some places where use cases are specifically addressed:
• Chapter 9 introduces sequence diagrams, system events and system operations
• Chapter 13 adds contracts
• Chapter 25 discusses Include, Extend, and Generalization
…
Sept 2004 91.3913 Ron McFadyen 15
Chapter 25 Relating Use Cases
• Include relationship• If one use case (the base use case) is designed to use the
functionality of another use case (the addition use case), there is an “include” dependency
• Consider that the base use case is executing. When it reaches the inclusion point, the addition use case is 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. The written Process Sale use case has in its Extensions section two inclusions:
Sept 2004 91.3913 Ron McFadyen 16
Include Relationship
• UC1:Process Sale
…
• Main Success Scenario
…
7. Customer pays and System handles payment.
…
• Extensions or alternate flows:
7a. Paying by cash …
7b. Paying by credit: include Handle Credit Payment
7c. Paying by check: include Handle Check Payment
Sept 2004 91.3913 Ron McFadyen 17
Include Relationship
• In the UML diagram
Process Sale
Handle Check 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 dependencies
Sept 2004 91.3913 Ron McFadyen 18
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 2004 91.3913 Ron McFadyen 19
More terminology
• Place Order and Track Order are called concrete use cases because they are initiated directly by an actor.
• Validate Customer is an abstract use case because it is never instantiated by itself; Validate Customer is only instantiated as part of another use case.
Sept 2004 91.3913 Ron McFadyen 20
Include Relationship
• Suppose ATM is a base use case and contains:
1. Show advertisement of the day
2. Include identify customer
3. Include validate account
4. …
Validate Account
<<include>><<include>>
Identify customerCustomer
ATM session
Sept 2004 91.3913 Ron McFadyen 21
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 2004 91.3913 Ron McFadyen 22
Generalization/Specialization Relationship
• Example. Suppose we have a university registration system where people must be admitted to become students. Some potential students, who attended high school in the city, are already known to the university because they went through some prior screening processes.
Admit new student
Admit Student
Admit HS student
Admissions Clerk
Sept 2004 91.3913 Ron McFadyen 23
Generalization/Specialization Relationship
• Example. Suppose we have two ways to check someone’s identity: via a password or via a retinal scan
Check Password
Verify Identity
Retinal Scan
Sept 2004 91.3913 Ron McFadyen 24
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 2004 91.3913 Ron McFadyen 25
Use Case Associations
• Between use case and actor
– uses (unlabeled)
• Between use cases
– include (dependency)
– extend (dependency, condition)
– generalization
• Between actors
– generalization