Professional Documents
Culture Documents
1 - Use Case Overview
1 - Use Case Overview
The requirements of a system describe what the user expects from the system – in
other words, what the system will do for the user. When defining the requirements
of a system, the system should be viewed as a black box, so that only the exter-
nal characteristics of the system are considered. Both functional and nonfunctional
requirements need to be considered. Requirements modeling consists of require-
ments analysis and requirements specification.
Use case modeling is an approach for describing the functional requirements of
the system, as described in this chapter. The system’s data requirements in terms of
the information that needs to be stored by the system are determined using static
modeling, as described in Chapter 7. The inputs to the system and the outputs from
the system are described initially in the use case models and then specified in more
detail during static modeling.
This chapter gives an overview of software requirements analysis and specifica-
tion in Section 6.1. It then goes on to describe the use case approach to defining
functional requirements, as well as how to extend use cases to describe nonfunc-
tional requirements. This chapter describes the concepts of actors and use cases,
and then goes on to describe use case relationships, in particular, the include and
extend relationships. Section 6.2 gives an overview of use case modeling followed
by an example of a simple use case. Section 6.3 then describes actors and their
role in use case modeling. The important topic of how to identify use cases is cov-
ered in Section 6.4. Section 6.5 describes how to document use cases. Section 6.6
gives some examples of use case descriptions. Section 6.7 then describes use case
relationships. Modeling with the include relationship is described in Section 6.8;
modeling with the extend relationship is described in Section 6.9. Use case
guidelines are described in Section 6.10, specifying nonfunctional requirements is
described in Section 6.11, use case packages are described in Section 6.12, and
how to describe use cases more precisely using activity diagrams is described in
Section 6.13.
71
72 Software Modeling
needs to output to the external environment, and what stored information the sys-
tem reads or updates. For example, for a functional requirement to view the bal-
ance of a bank account, the user would need to input the account number, and the
system would need to read the balance from the customer account and output the
balance.
A nonfunctional requirement, sometimes referred to as a quality attribute, refers
to a quality-of-service goal that the system must fulfill. Examples of nonfunctional
requirements are a performance requirement specifying a system response time
of 2 seconds, an availability requirement specifying a system must be operational
for 99% of the time, or a security requirement, such as protection from system
penetration.
Withdraw Funds
ATM Customer
customer and the system; the use case starts when the customer inserts an ATM
card into the card reader, then responds to the system’s prompt for the PIN, and
eventually receives the cash dispensed by the ATM machine.
View Alarms
Monitoring Operator
6.3 ACTORS
An actor characterizes an external user (i.e., outside the system) that interacts with
the system (Rumbaugh et al. 2005). In the use case model, actors are the only exter-
nal entities that interact with the system; in other words, actors are outside the sys-
tem and not part of it.
Generate Monitoring
Data
Generate Alarm
Remote Sensor
The Report Timer actor initiates the Display Daily Report use case, which periodically
(e.g., at noon every day) prepares a daily report and displays it to the user. In this
example, the timer is the primary actor and the user is the secondary actor. In use
cases in which a timer is the primary actor, it is usually the secondary actor (the user
in this example) who gains value from the use case.
If it is possible for a human user to play two or more independent roles, this
is represented by a different actor for each role. For example, the same user might
play, at different times, both an ATM Operator role (when replenishing the ATM cash
dispenser with cash) and an ATM Customer role (when withdrawing cash) and thus
be modeled by two actors.
In some systems, different actors might have some roles in common but other
roles that are different. In this situation, the actors can be generalized, so that the
common part of their roles is captured as a generalized actor and the different parts
by specialized actors. As an example, consider the Emergency Response System
(Chapter 23), in which two actors, a Monitoring Sensor actor and a Remote System
actor, behave in a similar way by monitoring remote sensors and sending sensor data
and alarms to the system. This similar behavior can be modeled by a generalized
actor, Remote Sensor, which represents the common role (i.e., the behavior that is
common to both the specialized actors), as shown in Figure 6.6.
Withdraw Funds
Query Account
ATM Customer
Transfer Funds
of interactions between the actor and the system. In this way, the functional
requirements of the system are described in terms of the use cases, which consti-
tute a functional specification of a system. However, when developing use cases, it
is important to avoid a functional decomposition in which several small use cases
describe small individual functions of the system rather than describe a sequence of
events that provides a useful result to the actor.
Let us consider the banking example again. In addition to withdrawing cash from
the ATM, the ATM Customer actor is also allowed to query an account or transfer
funds between two accounts. Because these are distinct functions initiated by the
customer with different useful results, the query and transfer functions should be
modeled as separate use cases, rather than being part of the original use case. Thus,
the customer can initiate three use cases, as shown in Figure 6.7: Withdraw Funds,
Query Account, and Transfer Funds.
The main sequence of the use case describes the most common sequence of inter-
actions between the actor and the system. There may also be branches off the main
sequence of the use case that describe less frequent interactions between the actor
and the system. These alternative sequences are deviations from the main sequence
that are executed only under certain circumstances – for example, if the actor makes
an incorrect input to the system. Depending on the application requirements, an
alternative sequence through the use case can sometimes join up later with the main
sequence. The alternative sequences are also described in the use case.
In the Withdraw Funds use case, the main sequence is the sequence of steps for
successfully achieving a withdrawal. Alternative sequences are used to address var-
ious error cases, such as when the customer enters the wrong PIN and must be re-
prompted, when an ATM card is not recognized or has been reported stolen, and so
on.
Each sequence through the use case is called a scenario. A use case usu-
ally describes several scenarios, one main sequence and a number of alternative
sequences. Note that a scenario is a complete sequence through the use case, so a
scenario could start out executing the main sequence and then follow an alterna-
tive branch at the decision point. For example, one of the Withdraw Funds scenarios
starts with the main sequence of the customer inserting the ATM card into the card
80 Software Modeling
reader, entering the PIN number in response to the prompt but then receiving an
error message because the PIN was incorrect, and then entering the correct PIN.
Browse Catalog
Make Order
Request
Customer
View
Order Status
diagram for the customer-initiated use cases in the Online Shopping System. There
is one actor – namely, the Customer, who browses a catalog and requests to purchase
items – and three use cases that are the major functions initiated by the actor, which
are Browse Catalog, to browse the catalog and select items, Make Order Request, to
provide the account and credit card information for the purchase, and View Order,
to view the status of the order. In the main sequence of the Make Order Request use
case, the customer makes an order request to purchase items from an online catalog
and has sufficient credit to pay for the items. The alternative sequences deal with
other situations, which occur less frequently: the customer has no account and has
to create one, or the customer has an invalid credit card.
Alternative sequences:
Step 2: If customer does not have account, the system creates an account.
Step 3: If the customer’s credit card request is denied, the system prompts
the customer to enter a different credit card number. The customer can
either enter a different credit card number or cancel the order.
Postcondition: System has created a delivery order for the customer.
Validate PIN
Withdraw Transfer
Query Account Funds
Funds
ATM Customer
An inclusion use case is executed in conjunction with a base use case, which
includes and, hence, executes the inclusion use case. In programming terms, an
inclusion use case is analogous to a library routine, and a base use case is analo-
gous to a program that calls the library routine.
An inclusion use case might not have a specific actor. The actor is, in fact, the
actor of the base use case that includes the inclusion use case. Because different
base use cases use the inclusion use case, it is possible for the inclusion use case to
be used by different actors.
The main parts of the use case descriptions are given for the inclusion use case,
Validate PIN, and a base use case, Withdraw Funds, that includes the Validate PIN use
case:
Validate PIN Inclusion Use Case
Process Part at
Receive Part High-Volume Ship Part
Workstation
Production
Manager
Manufacturing
Robot
Figure 6.10. Example of multiple inclusion use cases and include relationships
actor(s) and system. An example of this is the Manufacture High-Volume Part use
case (Figure 6.10), which describes the sequence of interactions in manufacturing
a part. This process involves receiving the raw material for the part to be manu-
factured (described in the Receive Part use case), executing a manufacturing step
at each factory workstation (described in the Process Part at High-Volume Worksta-
tion use case), and shipping the manufactured part (described in the Ship Part use
case).
■ To show a conditional part of the base use case that is executed only under cer-
tain circumstances
■ To model complex or alternative paths.
It is important to note that the base use case does not depend on the extension
use case. The extension use case, on the other hand, depends on the base use case
and executes only if the condition in the base use case that causes it to execute is
true. Although an extension use case usually extends only one base use case, it is
86 Software Modeling
possible for it to extend more than one. A base use case can be extended by more
than one extension use case.
Checkout
Customer
payment
Supermarket «extend»
«extend» (payment)
Customer (payment) «extend» [debit card
[cash payment] (payment) payment]
[credit card
payment]
In this base use case description, at step 6 «payment» is a placeholder that identi-
fies the location at which the appropriate extension use case is executed. For the Pay
by Cash extension use case, the extension condition is a selection condition called
[cash payment]. This extension use case is executed if the condition [cash payment]
is true.
Pay by Cash Extension Use Case
For the Pay by Credit Card extension use case, the selection condition is called
[credit card payment] (see Figure 6.11). This extension use case is executed if the
[credit card payment] condition is true, meaning that the user chose to pay by credit
card. Of course, if the user chose instead to pay by cash, then the Pay by Cash use
case would be executed instead.
Pay by Credit Card Extension Use Case
The use case description for the Pay by Debit Card extension use case is handled
in a similar way, except that the customer also needs to enter a PIN. Pay by Cash has
a selection condition called [debit card payment].
see the forest (the overall sequence of interactions) for the trees (the individual
functions)!
Security requirement: System shall encrypt ATM card number and PIN.
Performance requirement: System shall respond to actor inputs within 5
seconds.
View Alarms
Monitoring
Operator Generate Alarm
A use case model can also be described using an activity diagram. How-
ever, to depict a use case, a subset of the activity diagram capabilities is suf-
ficient. In particular, it is not necessary to model concurrent activities for use
cases.
An activity diagram can be used to represent the sequential steps of a use case,
including the main sequence and all the alternative sequences. An activity diagram
can therefore be used to provide a more precise description of the use case, because
it shows exactly where in the sequence and what the condition is for an alterna-
tive sequence to diverge from the main sequence. An activity node can be used to
represent one or more sequential steps of the use case. A high-level activity node
can be used to represent a use case, which can then be decomposed into a separate
activity diagram. Activity diagrams can also be used to depict sequencing among use
cases.
For depicting a use case, an activity diagram uses activity nodes, decision
nodes, arcs to join sequential activity nodes, and loops. An activity node is used
to depict one or more steps in the use case description. A decision node is used
to depict a situation in which, based on the result of the decision, an alterna-
tive sequence could branch off from the main sequence. Depending on the use
case, the alternative sequence could rejoin the main sequence – for example, by
looping back to a previous activity node or rejoining the main sequence further
down.
Activity nodes can be aggregate nodes that are hierarchically decomposed to
give a lower-level activity diagram. This concept can be used to depict inclusion
and extension use cases. Thus, an activity node in a base use case can be used to
Use Case Modeling 91
Receive
Order Request
[account exists]
Create Get
New Account Account Information
Authorize
Credit Card
[invalid]
[valid]
Display Create
Invalid Credit Card New Delivery Order
represent a link to an inclusion (or extension) use case, which is then depicted on a
separate lower-level activity diagram.
An example of an activity diagram is given in Figure 6.13 for the Make Order
Request use case of the Online Shopping System (see Section 6.6). This use case
consists of a main sequence in which the customer makes an order request to pur-
chase items from an online catalog and has sufficient credit to pay for the items. The
alternative sequences are for creating a new customer account and for an invalid
credit card. Each decision point that results in an alternative scenario is explicitly
depicted. In the example, the customer enters the order request information, system
gets account information (with an alternative sequence to create a new account),
and requests credit card authorization. If the credit card is valid, the system creates
a new delivery order and displays the order. If the credit card is invalid, the system
displays an invalid credit card prompt.