SWD 392 - Software

Architecture and Design

 SWD392

Use Case Modeling

 Table of Contents
01 REQUIREMENTS
MODELING 04 IDENTIFYING USE CASES

02 USE CASES 05 DOCUMENTING USE CASES

IN THE USE CASE MODEL

03 ACTORS 06 EXAMPLE OF USE CASE

DESCRIPTION

07 USE CASE RELATIONSHIPS

 Table of Contents
SPECIFYING
08 THE INCLUDE RELATIONSHIP 11 NONFUNCTIONAL
REQUIREMENTS

09 THE EXTEND RELATIONSHIP 12 USE CASE PACKAGES

10 USE CASE STRUCTURING GUIDELINES 13 ACTIVITY DIAGRAMS

01 REQUIREMENTS
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
- Consistent - Traceable
02 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
inputs, not the internals of how it does it.
 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.
03 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
04 IDENTIFYING USE CASES
 IDENTIFYING USE CASES
● To determine the use cases in the system, it is useful to start by
01 04
considering the actors and the interactions they have with the system.
● Each use case describes a sequence of interactions between the actor and
the system.
● In this way, the functional requirements of the system are described in
02 05
terms of the use cases, which constitute 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
03
functions of the system rather than describe a sequence of events that
provides a useful result to the actor
 IDENTIFYING USE CASES
01 04
● 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

02 05
different useful results, the query and transfer functions should be
modeled as separate use cases, rather than being part of the original use
case

03
 IDENTIFYING USE CASES
01 04

02 05

03 06
07
Thus, the customer can initiate three use cases, as shown in Figure 6.7: Withdraw Funds,
Query Account, and Transfer Funds.
05
DOCUMENTING USE CASES
IN THE USE CASE MODEL
 IDENTIFYING USE CASES
Use case name: Each use case is given a name.
01 04
Summary: A brief description of the use case, typically one or two sentences.
Dependency: This optional section describes whether the use case depends
on other use cases – that is, whether it includes or extends another use case.
Actors: This section names the actors in the use case. There is always a primary
02 05
actor that initiates the use case. In addition, there may be secondary
actors that also participate in the use case. For example in the Withdraw
Funds use case, the ATM Customer is the only actor
Preconditions: One or more conditions that must be true at the start of use
03
case, from the perspective of this use case; for example, the ATM machine
is idle, displaying a “Welcome” message.
 IDENTIFYING USE CASES
Description of main sequence: The bulk of the use case is a narrative
01 04
description of the main sequence of the use case, which is the most usual
sequence of interactions between the actor and the system. The description
is in the form of the input from the actor, followed by the response of the
system.
02 05
Description of alternative sequences: Narrative description of alternative
branches off the main sequence. There may be several alternative branches
from the main sequence. For example, if the customer’s account has insufficient
funds, display apology and eject card. The step in the use case at which
03
the alternative sequence branches off from the main sequence is identified
as well as a description of the alternative
 IDENTIFYING USE CASES
01 04
Nonfunctional requirements: Narrative description of nonfunctional
requirements, such as performance and security requirements.

02 05
Postcondition: Condition that is always true at the end of the use case (from
the perspective of this use case) if the main sequence has been followed; for
example, customer’s funds have been withdrawn.
Outstanding questions: During development, questions about the use case
are documented for discussions with users.
03
06
EXAMPLE OF USE CASE
DESCRIPTION
 IDENTIFYING USE CASES
01● In the main sequence of the Make Order04
Request use case,
the customer makes an order request to purchase items
from an online catalog and has sufficient credit to pay for
02 the items 05
● 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
03
07 USE CASE RELATIONSHIPS
 The Use Case Relashionships
01 04
● When use cases get too complex, dependencies between use cases can be
defined by using the include and extend relationships.
● Inclusion use cases are determined to identify common sequences of
interactions in several use cases, which can then be extracted and reused.
02 05
● Use case generalization is similar to the extend relationship because it is also
used for addressing variations.
● Use case variations can be adequately handled by the extend relationship.

03 06
07
 THE INCLUDE
08
RELATIONSHIP
 The Inlude Relationship
01 04
● A common sequence of interactions can be extracted from several of the
original use cases and made into a new use case, which is called an inclusion
use case.
● It is then possible to define a more concise version of the old use case, with
02 05
the common interaction sequence removed. This concise version of the old
use case is referred to as a base use case (or concrete use case), which
includes the inclusion use case.
● Inclusion use cases always reflect functionality that is common to more than
03
one use case. 06
07
 THE EXTEND
09
RELATIONSHIP
 The Extend Relationship
01 04
● The extend relationship is used to model alternative paths that a use case
might take.
● The use case that is extended is referred to as the base use case, and the use
case that does the extending is referred to as the extension use case.
02
● The extend relationship can be used as follows: 05
❏ To show a conditional part of the base use case that is executed only
under certain circumstances
❏ To model complex or alternative paths.
03 06
07
10
USE CASE
STRUCTURING
GUIDELINES
● Careful application of use case relationships can help with the overall
organization of the use case model; however, use case relationships should

01 04
be employed judiciously.
● It should be noted that small inclusion use cases corresponding to individual
functions (such as Dispense Cash, Print Receipt, and Eject Card) should not
be considered.
●
02 05
These functions are too small, and making them separate use cases would
result in a functional decomposition with fragmented use cases in which the
use case descriptions would be only a sentence each and not a description
of a sequence of interactions.
●
03 06
The result would be a use case model that is overly complex and difficult to
understand – in other words, a problem of not being able to see the forest
(the overall sequence of interactions) for the trees (the individual functions)!
07
11
SPECIFYING
NONFUNCTIONAL
REQUIREMENTS
● Nonfunctional requirements can be specified in a
separate section of the use case description, in much the
01 04
same way that alternative sequences are specified.
● For example, for the Validate PIN use case, there could
be a security requirement that the card number and PIN
02 05
must be encrypted. There could also be a performance
requirement that the system must respond to the actor
inputs within 5 seconds. If the nonfunctional
03 06
requirements apply to a group of related use cases, then
they can be documented as such, as described in the next
section.
07
12
USE CASE
PACKAGES
● For large systems, having to deal with a large number of
use cases in the use case model often gets unwieldy.
01 04
● A good way to handle this scale-up issue is to introduce a
use case package that groups together related use cases.
In this way, use case packages can represent high-level
02 05
requirements that address major subsets of the
functionality of the system.
● Nonfunctional requirements that apply to a group of
03 06
related use cases could be assigned to the use case
package that contains those use cases.
07
13
ACTIVITY
DIAGRAMS
● An activity diagram is a UML diagram depicting the flow
of control and sequencing among activities.
01 04
● An activity diagram shows the sequence of activities,
decision nodes, loops, and even concurrent activities.
Activity diagrams are widely used in workflow modeling
02 05
– for example, for service-oriented applications.

03 06
07
01 04

02 05

03 06
07
● A use case model can also be described using an activity
diagram. However, to depict a use case, a subset of the
01 04
activity diagram capabilities is sufficient.
● An activity diagram can be used to represent the
sequential steps of a use case, including the main
02 05
sequence and all the alternative sequences. An activity
node can be used to represent one or more sequential
steps of the use case. A high-level activity node can be
03 06
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. 07
● For depicting a use case, an activity diagram uses activity
nodes, decision nodes, arcs to join sequential activity nodes,
01 04
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
alternative sequence could branch off from the main sequence.
02 05
● 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
03 06
cases. Thus, an activity node in a base use case can be used to
represent a link to an inclusion (or extension) use case, which is
then depicted on a separate lower-level activity diagram.
07
01 04

02 05

03 06
07
Thanks!