Transcript Use Case Model - University of Wisconsin–La Crosse

Use Case Model
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
2
Elements of a Use Case diagram
System
dependency
Use case
Use case
generalization
Use case
actor
actor
dependency
C-S 546
Use case
3
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
4
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
5
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
6
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
7
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
8
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
9
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
10
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
11
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
12
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
13
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
14
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
15
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
16
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
17
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
18
Login
Logout
customer
Deposit
Withdraw
Check balance
Database
Transfer
All dependency relationships are of type <<include>>
C-S 546
19
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
20
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
21
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
22
Login
Logout
customer
Validate
account
Deposit
Withdraw
Update
account
Check balance
Database
Transfer
All dependency relationships are of type <<include>>
Use case diagram for ATM - revisited
C-S 546
23
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
C-S 546
24