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