Use Case ModelUse Case Model

C-S 546 2

Use case model

• describes what the user expects the system to do– functional requirements

• may describe only the functionalities that are visible to the user– requirements view

• may include additional functionalities to elaborate those in the previous step– design view

• consists of use case diagrams and textual descriptions

C-S 546 3

Elements of a Use Case diagram

actor

Use case Use case

Use case Use case

associa

tion

association

generalization

dependency

dependency

System

actor

C-S 546 4

Definitions• System

– a black box that describes the system or subsystem that is modeled

– example: ATM system, account verification subsystem– represented optionally as a rectangle in the use case diagram,

but generally not shown

• Actor– a role played by an external entity that interacts with the

system– One object may play multiple roles in a context in which case

there will be multiple actors• example: bank manager as a customer

C-S 546 5

Definitions (continued)

• Primary actor– an actor who initiates the major, main or important use

cases in the system– example : a customer in a banking system

• Secondary actor– an actor who is involved with one or more use cases but

does not initiate the use cases– example : database

• The concepts of primary and secondary actors will be useful in ranking the roles played by the actors

C-S 546 6

Definitions (continued)

• Generalization between actors– one actor can be a specialization of another

actor– based on the same concept as the specialization

relationship between classes– example : preferred customer in a bank is a

specialization of a customer

C-S 546 7

Definitions (continued)

• Use case– an important functionality to be implemented

and is visible to the actors– an interacting behavior between an actor and

the system• Must yield an observable result to the actor

– example: “deposit” in a banking system

C-S 546 8

Definitions (continued)

• Association– an interaction between an actor and a use case– represented by an arrow between an actor and a

use case– unidirectional associations must be represented

by arrows• direction of arrow indicate information flow

– bi-directional associations can be represented by double-sided arrows or straight lines

C-S 546 9

Definitions (continued)

• Generalization between use cases– based on the same concept as generalization

between classes; uses the same symbol– one use case can be designated as a

specialization of another use case– example: “withdraw with overdraft protection”

is a specialization of “withdraw”

C-S 546 10

Definitions (continued)

• “include” dependency– one use case may include another use case

– if use case A includes a use case B, B must be implemented in order to implement A

– based on the same concept as modular programming

– represented as a dashed arrow from A to B with a label “<<include>>”

– example : “withdraw” includes “update account”

C-S 546 11

Definitions (continued)• “extend” dependency

– one use case may be extended by another use case– if use case A is extended by a use case B, then both A and B

can be independently implemented and used• A will occasionally use B depending on some constraints

– based on the same concept as modular programming– represented as a dashed arrow from B to A with a label

“<<extend>>”• Notice that the arrow is reversed

– example : “withdraw” is extended by “check for privileged customer”

C-S 546 12

Constraints in a Use Case model

• every use case must be connected to an actor or be included in another use case or extends another use case

• every use case connected to an actor must return an observable result to the actor– may be data or confirmation of termination of

an action

C-S 546 13

How to find actors?

• those that interact with the system (provide input, observe results, provide control information, …)– primary actors

• those that are used by the system but external to the system– secondary actors such as data stores

• information about actors can be found in the problem description

• generally, users of the system are primary actors

C-S 546 14

How to find use cases?

• every requirement is a use case

• every functionality that supports the implementation of a requirement is a use case– design issue– found when the first (abstract) use case model

is refined to express a design

C-S 546 15

How to find use case relationships?

• extracted from the application domain• must be justifiable from the application domain or

from the designer’s choice• examples

– “withdraw” includes “update account” is justifiable from application domain

– “withdraw” is extended by “withdraw with overdraft protection” is a designer’s choice

• designer can always implement two different versions of withdrawals

C-S 546 16

Use case narrative

• not part of UML notation • textual descriptions of a use case

– important for design and implementation of use case

• most OO tools provide a mechanism to add use case narratives– see Rational Rose for example

• may include additional information and constraints on the use cases– pre and post-conditions

C-S 546 17

Use case instance

• a particular situation of a use case• generally described using an activity diagram (to

be discussed later)– shows the algorithmic version of a use case

• there can be several instances of the same use case, each having a different result

• examples– Successful withdrawal– “withdraw” denied because of insufficient balance– “withdraw” denied because of overdraft violation

C-S 546 18

Case Study - ATM

• Model only the transactions• Customer accounts assumed to exist

– Opening and closing of accounts is handled by another portion of the system

• Include operations “deposit”, withdraw”, “check balance”, “transfer”

• If balance is zero or less than the amount to be withdrawn, then withdrawal should fail

C-S 546 19

Deposit

Withdraw

Check balance

Transfer Database

customer

Login

Logout

All dependency relationships are of type <<include>>

C-S 546 20

Use case narratives - ATM• Deposit

– Using this functionality, a user will be able to add some money to his/her account

– Account identification and amount to be deposited must be input– Upon completion, the balance in the account will be updated to

include the additional amount

• Check balance – A user can check the balance in an account using this

functionality– Account identification must be input and the balance in the

account will be output– The account remains unchanged upon completion

C-S 546 21

Use case narratives – ATM (continued)

• Write the narratives for “withdraw” and “transfer”

• The narratives more or less reflect the requirements as written in a requirements document

• A requirements document may also be referred with a cross reference in each requirement pointing to the appropriate use case in the use case diagram

C-S 546 22

Use case instance – “deposit”

Deposit (ACCOUNT_IDENTIFIER acct, MONEY amount) {

if (validate_account (acct)) {

account = retrieve_account (acct);

account.balance = account.balance + amount;

write_account (account); // update the database

}

else display (“Invalid account identifier”);

}

C-S 546 23

Deposit

Withdraw

Check balance

Transfer Database

customer

Login

Logout Validate account

Update account

All dependency relationships are of type <<include>>

Use case diagram for ATM - revisited

C-S 546 24

ATM - Exercises

• Write the narratives for the revised version of ATM use case diagram

• Enhance the diagram to include the following:– A manager can open an account– A manager can close an account– An account may come with overdraft protection

during withdrawal