Use Cases Alistair Cockburn, Writing Effective Use Cases, Addison- Wesley, 2000. Grady Booch, James...
Transcript of Use Cases Alistair Cockburn, Writing Effective Use Cases, Addison- Wesley, 2000. Grady Booch, James...
Use Cases
Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley, 2000.
Grady Booch, James Rumbaugh, and Ivar Jacobson, Unified Modeling Language User Guide, 2nd edition, Addision-Wesley, 2005.
Scott W. Ambler, The Elements of UML 2.0 Style, Cambridge University Press, 2005.
1
Groups of 3
• Recorder/timekeeper
• Participation checker
• Devil’s advocate
2
Motivation
• One way to describe a system is to create a “story”, the interaction between a user and the system.
• This story should be just one path through the system, start to finish, that a user will want to take.
3
Task
• Read the ATM description
• Describe the withdraw transaction from start to finish
• Make sure you describe exactly one path
• 10 minutes
4
Report
5
Questions
• What questions did you come up with about the ATM?
• Other than the customer, what other things did you need to interact with?
• How did you decide what is inside and outside of your system?
• Where in your description could things have been different?
6
What Is an Actor?
• Not part of a system
• Represents roles a user can play (not people or job titles)
• Represents a human, a machine or another system
• Actively exchanges information with the system: a giver or a recipient
7
Charlie asCaller
Charlie asCustomer
Charlie Phone Owner
Phone Carrier
A User Can Act As Several Actors
8
PhoneSystem
Voice mail
Caller Callee
Is the Voice Mail an actor or part of the system? What about other providers?
System boundary?
ActorsHelp Define System Boundaries
9
Questions to Identify Actors
• Who will use the system?• Who needs support from the system to do regularly
occurring tasks?• Who will maintain the system? • What hardware does the system support or interact with?• What other systems are needed for this system to work?• Who will supply, use, or remove information?
• Don’t just consider people in front of a computer screen…
10
Task
• Identify all of the actors in the ATM exercise.
• 3 minutes
11
Here on Thursday
• Fix ATM description so that only withdraw on sufficient funds.
12
ATM Actors
13
A use case defines a sequence of actions performed by a system that yields an observable result of value to an actor.
Use Cases
14
Use Cases
• A use case is always initiated by an actor.
• A use case provides value to an actor.
• A use case is complete.
15
Use Cases
• A use case is always initiated by an actor.– Is always performed on behalf of an actor.– Actor must directly or indirectly initiate the
use case.
• A use case provides value to an actor.
• A use case is complete.
16
Use Cases
• A use case is always initiated by an actor.
• A use case provides value to an actor.– The use case must deliver some tangible
value to an actor.
• A use case is complete.
17
Use Cases
• A use case is always initiated by an actor.
• A use case provides value to an actor.
• A use case is complete.– A use case is a complete description. – A use case is not complete until the end
value is produced.
18
For Each Actor, Ask the Following Questions:
• What are the primary tasks the actor wants the system to perform?
• Will the actor create, store, change, remove, or read data in the system?
• Will the actor need to inform the system about sudden, external changes?
• Does the actor need to be informed about certain occurrences in the system?
• Will the actor perform a system startup or termination?
19
Think About Data:
• Who creates it?
• Who displays or uses it?
• Who updates or modifies it?
• Who deletes it?
These are typical use cases for data objects in the system.
20
Candidate Use Cases: Must Be For the Actor
Rule #1: Be sure the use case provides value to the actor.
21
Task
• Identify the main use cases of the ATM system.
• 3 minutes
22
Main Use Cases:
23
Task:
• Identify the main use cases for Gas Pump.
• 3 minutes
24
Gas Pump Use Cases:
• Pump gas
25
Documenting Use Cases
• Use case diagrams consisting of– system– actors– use cases
26
<<include>>
User
Student
FacultyEnter Grades
Validate User
Check Grades
Get Roster
Register
<<include>>
<<extend>>
system boundary
use case
actor
Goldmine
Use Case Diagram: System
Diagram starts with a• bounding box • and a subject
• Goal: determine the boundaries of the system, i.e., what’s in, what’s out.
Cell-phone System
27
• An actor represents an external entity that interacts with the system.
• A use case defines a sequence of actions performed by a system that yields an observable result of value to an actor.
Actor
Use case
The Use-Cases ModelMajor Concepts
28
Actor Icons
<<actor>>Borrower
Borrower
These are the same, but the class rectangle is almost never used in use case diagrams.
29
Caller
A model of what the system is supposed to do (use case), and the system’s surroundings (actors).
A Sample System
Cell-phone System
30
Text Message
Place Call
Bill Customer
Customer
Callee
Billing manager
Non-networkprovider
Task
• Draw the Use Case Diagram for ATM.
• Time: 5 minutes
31
Use Case Model
• Model of system’s intended functions and its surrounding
• Answers the question “what the system does to benefit users?”
• Communicates the system’s functionality and behavior to the customer or end user– Use terminology that users understand.– Verifies developer’s understanding of the system. – Helps verify that all requirements are captured.
32
Use Case Model (Cont.)
• Identify external interactions• Provides a basis for system design• Provides a basis for system testing and walkthroughs• Can help avoid requirements creep
– “We’ll have to create a new use case and modify some existing ones …”
– Makes customers aware of impact of changes
33
So, What’s a Use Case?
• A scenario is a sequence of steps describing an interaction between a user and a system.
The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks the authorization on the credit card and confirms the sale both immediately and with a follow-up email.
• What if the credit card authorization fail? A separate scenario!
34
Use Cases (Cont.)
• A use case is a set of scenarios tied together by a common user goal (e.g., success and failure together, and other alternative paths).
35
An Example Use Case
• Main success scenarios along with alternatives and extensions
36
Buy product
Main Success Scenario:1.Customer browses through catalog and select items to buy2.Customer goes to check out3.Customer fills in shipping information (address)4.System presents full pricing information, including shipping5.Customer fills in credit card information6.System authorizes purchase7.System confirms sale immediately8.System sends confirmation email to customer
Extensions:3a: Customer is a regular customer
3a1: System displays current shipping, pricing and billing information3a2: Customer may accept or override these defaults, returns to MSS at step 6
6a: System fails to authorize credit purchase6a1: Customer may re-enter credit card information or may cancel.
Another Presentation
37
Extensions:3a: Customer is a regular customer
3a1: System displays current shipping, pricing and billing information3a2: Customer may accept or override these defaults, returns to MSS at step 6
6a: System fails to authorize credit purchase6a1: Customer may re-enter credit card information or may cancel.
Customer:
1. Browses catalog and select items2. Goes to check out3. Fills in shipping information (address)
5. Customer fills in credit card information
Buy product
Main Success Scenario:
System:
4. Presents full pricing information
6. Authorizes purchase7. Confirms sale immediately8. Sends confirmation email to customer
Scenarios - Flow of Events• Represents what system does, not how the system
performs behavior• Should be clear enough for outsider to understand• Guidelines:
– How use case starts and ends– What data is exchanged between actor and use case– Do not describe details of user interface– Describe flow of events, not only functionality– Do not describe what happens outside the system– Avoid vague terminology (etc.; information)
38
Documenting Use Cases
• Not part of UML but include (see template):– Brief description: describe the overall intent of the use case– Preconditions: conditions that must be true before the use
case can begin to execute– Basic flow: used to capture the normal flow of execution
through the use case– Alternative flows: used to capture variations to the basic
flows, such as decisions or error conditions.– Postconditions: conditions that must be true for the use case
to complete.
39
Scenario 1: Place Call
Preconditions: A caller wants to make a call to a callee. The cell phone is on and connected to a cell phone network. The phone is idle.
Postconditions: On successful completion, the phone is idle. The caller has been connected to the callee for voice communication.
Actors: Caller, Callee, Network Provider
40
Scenario 1: Place Call1. The caller activates the “call” option. (this may be by opening the
phone or selecting some UI element.)2. The system displays a blank list of digits and indicates it is in
“call” mode.3. The user enters digits (ALT 1).4. The system displays the entered digits.5. The user selects the “dial” option (ALT 2).6. The system sends the sequence of digits to the network provider. 7. The network provider accesses the network and makes a
connection (ALT 3, ALT 4).8. The callee answers (ALT 5).9. The network provider completes the voice connection.10. The caller and callee engage in voice communications.11. The caller hangs up (ALT 6).12. The system returns to idle mode.13. End of Use Case.
41
Scenario 1: Place CallALT 1: The user uses speed dial.A1-1: The user enters a single digit and selects “dial”.A1-2: The system accesses the phone number associated with
the digit (ALT 1.1).A1-3: Use case continues at step 6.
ALT 1.1: No speed dial number is associated with the entered digit.
A1.1-1: The system ignores the “dial” command and displays the digit.
A1.1-2: Use case continues at step 4.
ALT 2: The user cancels the operation.A2-1: Use case continues at step 12.
42
Task:
• Write the use case scenario for Withdraw.
• Include alternative flows.
• 10 minutes
43
More on UML Use Case Diagrams
• Relationships– Association between an actor and a use
case– Dependency between two use cases– Generalization between two actors– Generalization between two use cases
44
Actor and Use Case
• Indicate participation of actors in use cases
• Optional direction indicating the initiator of the use case, e.g.,
45
Caller
Place Call
Callee
Actor Generalization
Registered User
BorrowerManager
Generalization can be used to clarify the model when users have common behaviors; however, systems are frequently best understood by understanding a person plays more than one role.
46
47
“Include” Relationship
Withdraw Cash
IC1
… for identifying customer
ICm
W1
… for withdrawing cash
Wn
Deposit Cash
IC1
… for identifying customer
ICm
D1
… for depositing cash
Dn
WithdrawCash
DepositCash
Withdraw Cash
include::Identify Customer
W1
…
Wn
Deposit Cash
include::identify Customer
D1
…
Dn
Identify Customer
IC1
…
ICm
WithdrawCash
DepositCash
IdentifyCustomer
<<include>> <<include>>
Include Relationship• Used as follows:
– Factor out behavior that is common for 2+ use cases.
– Factor out behavior from base use case if not necessary for understanding of primary purpose of use case.
• Description– Define location within the
behavior sequence of base case where inclusion is to be inserted, e.g.includes the “Identify Customer” use case to determine the identity of the customer, orinclude::Identify Customer.
Identify Customer
WithdrawCash
DepositCash
TransferFunds
<<include>>
48
<<include>> <<include>>
49
“Extend” Relationship
Enroll In University
I1
…
Im
C1
… if int’l student
Cn
Im+1
…
Im+l
EnrollIn Univ.
Enroll In University
I1
…
Im
(Ext: int’l student)
Im+1
…
Im+l
Check Security
C1
…
Cn
CheckSecurity
EnrollIn Univ
<<extend>>
Extend Relationship
• Used to:– Show that a part of a use case is
optional– Show that a subflow is executed
only under certain conditions– Show that there may be set of
behavior segments that are inserted depending on interaction with actors
Check Security
Student
Enroll inUniversity
<<extend>>
50
Extend Relationship Description
• Each extend relationship has a list of references to extension points in the base case.
• Extension points are referenced by name.• Example:
– Condition: The student is an international student.– Extension Points: International Student– insert the whole
use case– In main flow of events, show the extension point as follows:
…(Ext 1: International Student). …
51
Use Case Generalization
• Use when two or more use cases have commonalities in behavior, structure, or purpose.
• Describe in child spec how behavior sequences from the parents are interleaved with the child.
Customer Internet Customer
52
PlaceOrder
PhoneOrder
InternetOrder
Use Case Relationships
PlaceOrder
Pay
CashCreditCard
RequestCatalog
<<extend>>
<<include>>
Extends: Insertion of additional behavior into a use case that does not know about it.
Generalization: relationship between general case and specific case that adds features to the general case 53
Difference Between Include And Extend
• Include:– Several use cases have common action.– Action is not a use case on its own.– Factor common action and include.– “Always” included and “explicit”
• Extends– Use case has as part of its action all of another
use case.– This use case provides service beyond other use
case.– “Optionally” extended and “implicit”
54
Stages of Use Case Construction
• Identify most important interactions• Fill in use cases
– Triggers, pre and post conditions, basic course of events, document exceptions
– Break out detailed use cases• Focus
– Clarify scope, separate essential from non-essential, eliminate duplicates, focused and detailed scenarios.
55
Candidate Use Cases: Verbs
• Strong verbs: – Create, remove, merge, defer, switch,
calculate, pay, credit, register, deactivate, review, view, enter, change, combine, release, search, migrate, receive, debit, activate, archive, browse
• Weak verbs:– Make, report, use, organize, record, find,
process, maintain, display, list, input
56
Style Notes (Ambler, 2005)
• Use case names begin with strong verbs.• While use cases do not imply timing, order cases from top
to bottom to imply timing (improves readability).• The primary actors should appear in the top left.• Actors are associated with one or more use cases. • Do not use arrows on the actor-use case relationship.• Include an actor called “time” to initiate scheduled events.• Do not show actors interacting with each other.• Apply <<include>> when you know exactly when to invoke
the use case. These should rarely nest more than 2 deep.• Avoid using <<extend>>.
57
Subflows: parts
• Extract parts of flow of events and describe these separately.– Alternative flow of events within base case
(variant, option, exception)– Explicit inclusion in base case (include-
relationship)– Implicit inclusion in base case (extend-
relationship)– Separate subflow (e.g., Maintain Employee
Information may have subflows for adding or deleting)
58
Subflows
• Flow may consist of several subflows.
• Subflows can be reused in other use cases.
• Avoid if-then-else constructs; pseudocode
• Extract parts of flow of events and describe these separately.
59