SWD 392 - Software

Architecture and
Design
 SWD392

Use Case
Modeling
 Table of Contents
0 REQUIREMENTS 0 IDENTIFYING USE
MODELING CASES
1 4
0 USE CASES
0 DOCUMENTING USE
CASES IN THE USE
2 5 CASE MODEL
0 ACTORS
0 EXAMPLE OF USE
CASE DESCRIPTION
3 0 USE CASE 6
7 RELATIONSHIPS
 Table of Contents
THE INCLUDE 1 SPECIFYING
08 RELATIONSHIP NONFUNCTIONAL
1 REQUIREMENTS
0 THE EXTEND 1 USE CASE
RELATIONSHIP PACKAGES
9 2
1 USE CASE STRUCTURING 1 ACTIVITY DIAGRAMS
0 GUIDELINES
3
0
1
REQUIREMENT
S MODELING
 REQUIREMENTS
MODELING
● Requirements Analysis:
The software requirements describe the functionality that the system
must provide for the users. Requirements analysis involves analyzing the
requirements
● Requirements Specification:
After the analysis, the requirements need to be specified. The
requirements specification is the document that needs to be agreed on by the
requirements analysts and the users. It is the starting point for the subsequent
design and development, so it must also be understood by the developers.
Both functional requirements and nonfunctional requirements need to be
specified
● Quality Attributes of Software Requirements Specification
- Correct - Verifiable

- Complete -
Understandable by non-computer specialists.
- Unambiguous - Modifiable
0

2 USE CASES
 USE CASES
In the use case modeling approach, functional requirements are described in
terms
of actors, which are users of the system, and use cases. A use case defines a
sequence
of interactions between one or more actors and the system. In the
requirements
phase, the use case model considers the system as a black box and describes
the
interactions between the actor(s) and the system in a narrative form
consisting
of user inputs and system responses. The use case model describes the
functional
requirements of the system in terms of the actors and use cases. The system
is treated
as a black box – that is, dealing with what the system does in response to the
actor’s
 USE CASES
A Simple Use Case
The essentials of the use case description consist of
the following:
■ The name of the use case, View Alarms.
■ The name of the actor, Monitoring Operator.
■ A one-sentence use case summary, which provides a brief description.
■ The description of the main sequence of events. For this use case, the first
step
is the operator request and the second step is the system response.
■ The description of any alternative to the main sequence. For this use case,
there
could be an alternative at step 2, which would be executed if there is a
monitoring
emergency.
0

3 ACTORS
 USE CASES
• Actor models external entities of system
• Actors interact directly with system Actors interact directly with
system
– Human user
– External I/O device
– External system
– Timer
• Actor initiates actions by system
– May use I/O devices or external system to physically
interact with system
– Actor initiates use cases
0
IDENTIFYING USE
4 CASES
 IDENTIFYING USE CASES
● To determine the use cases in the system, it is useful to start
0 0 they have with
by considering the actors and the interactions
the system.
● 1
Each use case describes a sequence of4 interactions between
the actor and the system.
● 0
In this way, the functional requirements0 of the system are
described in terms of the use cases, which constitute functional
2
specification of a system. 5
● However, when developing use cases, it is important to avoid a
0
functional decomposition in which several small use cases
describe small individual functions of the system rather than
3
describe a sequence of events that provides a useful result to
the actor
 IDENTIFYING USE CASES
0 0
● In addition to withdrawing cash from the ATM, the ATM

1 4
Customer actor is also allowed to query an account or transfer
funds between two accounts.
0 0
● Because these are distinct functions initiated by the customer
with different useful results, the query and transfer functions

2 5
should be modeled as separate use cases, rather than being
part of the original use
0
case

3
 IDENTIFYING USE CASES
0 0
1 4
0 0
2 5
0 0
3 0 6
Thus, the customer can initiate three use cases, as shown in Figure 6.7: Withdraw Funds,

7
Query Account, and Transfer Funds.
0 DOCUMENTING USE

5 CASES IN THE USE

CASE MODEL
Use case name: Each use case is given a name.
IDENTIFYING USE CASES
Summary: A brief description of the use case, typically one or two
sentences.
Dependency: This optional section describes whether the use
0
case depends 0
on other use cases – that is, whether it includes or extends another
1
use case. 4
Actors: This section names the actors in the use case. There is
0 0
always a primary actor that initiates the use case. In addition, there
may be secondary
2 5
actors that also participate in the use case. For example in the
Withdraw
0
Funds use case, the ATM Customer is the only actor
Preconditions: One or more conditions that must be true at the
3
start of use
case, from the perspective of this use case; for example, the ATM
machine
is idle, displaying a “Welcome” message.
Description of main sequence: The bulk of the use case is a

IDENTIFYING USE CASES

narrative
description of the main sequence of the use case, which is the most
usual
0 0
sequence of interactions between the actor and the system. The
description
1 4
is in the form of the input from the actor, followed by the response
of the
0
system. 0
Description of alternative sequences: Narrative description of
2
alternative
5
branches off the main sequence. There may be several alternative
0
branches
from the main sequence. For example, if the customer’s account
3
has insufficient funds, display apology and eject card. The step in
the use case at which
the alternative sequence branches off from the main sequence is
identified
as well as a description of the alternative
 IDENTIFYING USE CASES
0
Nonfunctional 0
requirements: Narrative description of

1
nonfunctional
requirements, 4 requirements.
such as performance and security

case0 0
Postcondition: Condition that is always true at the end of the use
(from
the perspective of this use case) if the main sequence has been
2 for
followed; 5
0
example, customer’s funds have been withdrawn.
Outstanding questions: During development, questions about
the use case
3
are documented for discussions with users.
0
EXAMPLE OF USE
6 CASE DESCRIPTION
 IDENTIFYING USE CASES
0 0
● In the main sequence of the Make Order Request
1 use case, the customer makes an order 4 request to
0 sufficient credit to pay for the items0
purchase items from an online catalog and has

● The alternative sequences deal with other

2 situations, which occur less frequently:
5 the
0 the customer has an invalid credit card
customer has no account and has to create one, or

3
0
USE CASE
7 RELATIONSHIPS
 The Use Case
Relashionships
0 0
● When use cases get too complex, dependencies between use
1 can be defined by using the include4and extend
cases

● 0 use cases are determined to identify

relationships.
Inclusion 0 common
sequences of interactions in several use cases, which can then be

●
2 and reused.
extracted 5
Use case generalization is similar to the extend relationship
0 it is also used for addressing variations.
because 0
● Use case variations can be adequately handled by the extend
3
relationship.
0 6
7
 THE INCLUDE
08
RELATIONSHIP
 The Inlude Relationship
0 0
● A common sequence of interactions can be extracted from
1 of the original use cases and made4into a new use case,
several

It 0 0version of the old use

which is called an inclusion use case.
● is then possible to define a more concise
case, with the common interaction sequence removed. This
2 version of the old use case is referred
concise 5 to as a base use
case (or concrete use case), which includes the inclusion use
0
case. 0
● Inclusion use cases always reflect functionality that is common to
3 than one use0case.
more 6
7
0
THE EXTEND
9 RELATIONSHIP
 The Extend Relationship
0 0
● The extend relationship is used to model alternative paths that a
1case might take.
use 4
●
0the use case that does the extending0is referred to as the
The use case that is extended is referred to as the base use case,
and
extension use case.
● 2
The 5
extend relationship can be used as follows:
❏ To show a conditional part of the base use case that is
0executed only under certain circumstances
0
❏ To model complex or alternative paths.
3 0 6
7
1
USE CASE
0STRUCTURING
GUIDELINES
● Careful application of use case relationships can help with the

0 0
overall organization of the use case model; however, use case
relationships should be employed judiciously.

1 4 Print Receipt, and

● It should be noted that small inclusion use cases corresponding
to individual functions (such as Dispense Cash,

0
Eject Card) should not be considered.
0
● These functions are too small, and making them separate use

2
fragmented use cases in which the use case5
cases would result in a functional decomposition with
descriptions would

0 0
be only a sentence each and not a description of a sequence of
interactions.

3 0
difficult to understand 6 of not being
● The result would be a use case model that is overly complex and
– in other words, a problem
able to see the forest (the overall sequence of interactions) for

7
the trees (the individual functions)!
1 SPECIFYING
NONFUNCTIO
1 NAL
REQUIREMENT
S
● Nonfunctional requirements can be specified in a
0 0
separate section of the use case description, in
much the same way that alternative sequences
1are specified. 4
●0
For example, for the Validate PIN 0use case,
there could be a security requirement that the
2 5
card number and PIN must be encrypted. There
0 0 inputs
could also be a performance requirement that
the system must respond to the actor
3 6
within 5 seconds. If the nonfunctional
requirements0apply to a group of related use
cases, then they can be documented as such, as
described in 7
the next section.
1
2 PACKAGES
USE CASE
● For large systems, having to deal with a large
0 0
number of use cases in the use case model often
gets unwieldy.
●1
A good way to handle this scale-up4issue is to
0
introduce a use case package that 0groups
together related use cases. In this way, use case
2
packages can represent high-level 5requirements
0 0
that address major subsets of the functionality
of the system.
●3 6 to a
Nonfunctional0 requirements that apply
group of related use cases could be assigned to
the use case7 package that contains those use
cases.
1
3 DIAGRAMS
ACTIVITY
● An activity diagram is a UML diagram depicting
0 0
the flow of control and sequencing among
activities.
●1 4
An activity diagram shows the sequence of
0 0 even
activities, decision nodes, loops, and
concurrent activities. Activity diagrams are
2
widely used in workflow modeling5 – for example,
0
for service-oriented applications.
0
3 0 6
7
0 0
1 4
0 0
2 5
0 0
3 0 6
7
● A use case model can also be described using an
0 0
activity diagram. However, to depict a use case,
a subset of the activity diagram capabilities is
1sufficient. 4
●0
An activity diagram can be used to0represent the
sequential steps of a use case, including the
2 5
main sequence and all the alternative
0
represent one or more sequential0
sequences. An activity node can be used to
steps of the
3 6
use case. A high-level activity node can be used
to represent 0a use case, which can then be
decomposed into a separate activity diagram.
7 can also be used to depict
Activity diagrams
● For depicting a use case, an activity diagram uses
0 0
activity nodes, decision nodes, arcs to join sequential
activity nodes, and loops. An activity node is used to
1 4
depict one or more steps in the use case description.
A decision node is used to depict a situation in which,
0 0
based on the result of the decision, an alternative
sequence could branch off from the main sequence.
● 2
Activity nodes can be aggregate nodes 5that are
0 0
hierarchically decomposed to give a lower-level
activity diagram. This concept can be used to depict
3 use case can be used 6
inclusion and extension use cases. Thus, an activity
node in a base0 to represent a
link to an inclusion (or extension) use case, which is
then depicted 7 on a separate lower-level activity
diagram.
0 0
1 4
0 0
2 5
0 0
3 0 6
7
Thanks!