Name: Shilpashree Srinivasamurthy
Subject: ACS 560- Software Engineering
Term: Fall 2010
Chapter 7: Use Case Modeling
Textbook: Designing Concurrent, Distributed, and Real-Time Applications with
UML
This chapter describes the use case approach to defining the functional requirements of
the system.
The chapter begins with the description of the use case and actor concepts.
- Use Case: A use case defines a sequence of interactions between one or more
actors and the system.
- Actor: An actor characterizes an outside user or related set of users who interact
with the system. In the use case model actors are the only external entities that
interact with the system. A primary actor initiates a use case. Other actors are
known as secondary actors. They participate in the use case by receiving outputs
and providing inputs.
- Actors, Roles, and Users: An actor represents a role played in the application
domain, typically by a user. A user is an individual, and actor represents the role
played by all users of the same type.
The next section describes about Identifying Use Cases along with a banking
example. To determine the use cases in the system, it is useful to start by considering
the actors and the actions they initiate in the system. Each use case describes a
sequence of interactions between the actor and the system. The functional
requirements of the system are defined in terms of use cases.
The following section describes about documenting use cases in the use case model.
The use cases in the use case model are documented as follows.
- Use Case Name: Name of the use case.
- Summary: A brief description of the use case in one or two sentences
- Dependency: This optional section whether the use case depends on other use
cases.
- Actors: This section names the actors in the use case
- Preconditions: This section consists of one or more conditions that must be true
at the start of the use case.
- Description: This section consists of narrative 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.
-
Alternatives: This section consists of the narrative description of alternative
branches off the main sequence.
Postcondition: This section states the condition that is always true at the end of
the use case if the main sequence has been followed.
Outstanding questions: This section consists of questions about the use case that
are documented for discussion with users.
The next section gives examples of the use cases for a Banking System namely Withdraw
Funds Use Case, Query Account Use Case, and Transfer Funds Use Case.
The next section describes use case relationships. Dependencies between use cases can be
defined using include and extends relationships.
- The Extend Relationship: The extend relationship is used to model alternative
paths that a basic use case might take. A use can become too complex if it has too
many alternative, optional, and exceptional sequences of events. A solution to this
problem is to split off an alternative or optional sequence of events into a separate
use case. The purpose of this new use case is to extend the old use case, if the
appropriate conditions hold. The use case that is extended is known as the “base
use case” and the use case that does the extending is referred to as “extension use
case”.
- The Include Relationship: After the use cases for an application are initially
developed, common sequences of interactions between the actor and the system
can sometimes be determined that span several use cases. A common pattern can
be extracted from several of the original use cases and made into a new use case
known as inclusion use case. This inclusion use case is abstract which cannot be
executed on its own and should be a part of the executable use case. Inclusion use
case can be reused by several other use cases. It is then possible to define a more
concise version of the old use case, with the common pattern removed. The
concise version of the old use case is referred to as concrete use case, which
includes the abstract use case.
The last section of the chapter talks about use case packages. A use case package consists
of related group of use cases which represents high-level requirements that address major
subsets of the functionality of the system. Use cases can be grouped into packages based
on the major actors who use them.