UNIT 5: USE CASE MODELING
Unit outcomes
Write fully developed use case descriptions
Develop activity diagrams to model flow of activities
Develop system sequence diagrams
Use the CRUD technique to validate Use Cases
Explain how use case descriptions and UML diagrams
work together to define functional requirement
Introduction
The main objective of defining requirements in system development is understanding users’
needs, how the business processes are carried out, and how the system will be used to
support those business processes. Model building is one of the best ways for analysts to
understand the business processes and to remember what they have learned from their fact
finding activities.
This study unit explains four types of models and how they are used to capture the business
rules and processes. Three of the models extend the definitions of the use cases, and the
final model extends information about the classes. Use case related models are the “fully
developed use case description,” UML activity diagrams, and UML system sequence
diagrams (SSD). The “fully developed use case descriptions” are used to document the
context, purpose, description, conditions, and workflow of each use case. Activity diagrams
are a graphical depiction of the use case workflow and are useful in illustrating the
alternative paths through a business process. SSDs are used to document the inputs and
outputs that are passed between the user and the system during a use case. Not only do
these models document the internal steps of a use case, but the very act of developing
these models force the analyst to ask detailed questions and help improve the
understanding of the requirements.
The State machine diagram is a class related model. For some object classes in the domain
model it is necessary to understand the life cycle of individual objects. This is especially true
for business objects that can have different status conditions. A state machine diagram
documents what these status conditions are and how an object changes status condition by
transitioning from state to state.
A use case diagram contains the actor and use case symbols, along with connecting lines. Actors
are similar to external entities; they exist outside of the system. The term actor refers to a particular
role of a user of the system.
For example, an actor may be an employee, but also may be a customer at the company
store. Even though it is the same person in the real world, it is represented as two different
symbols on a use case diagram, because the person interacts with the system in different
roles.
The actor exists outside of the system and interacts with the system in a
specific way. An actor can be a human, another system, or a device such as a keyboard or
Web
connection. Actors can initiate an instance of a use case. An actor may interact with one or
more use cases, and a use case may involve one or more actors.
Actors may be divided into two groups. Primary actors supply data or receive information
from the system. Some users directly interact with the system (system actors), but primary
actors may also be businesspeople who do not directly interact with the system but have a
stake in it. Primary actors are important because they are the people who use the system
and can provide details on what the use case should do. They can also provide a list of goals
and priorities. Supporting actors (also called secondary actors) help to keep the system
running or provide other services
The use case model is based on the interactions and relationships of individual use cases.
A use case always describes three things:
an actor that initiates an event
the event that triggers a use case
the use case that performs the actions triggered by the event
Use cases are used to document a single transaction or event
Use Case Relationships
Active relationships are referred to as behavioural relationships and are used primarily in
use case diagrams. There are four basic types of behavioural relationships: communicates,
includes, extends,and generalizes
COMMUNICATES. The behavioral relationship communicates is used to connect an
actor to a use case. Remember that the task of the use case is to give some sort of
result that is beneficial to the actor in the system. Therefore, it is important to
document these relationships between actors and use cases. In our first example, a
Student communicates with Enroll in Course.
INCLUDES. The includes relationship (also called uses relationship) describes the
situation in
which a use case contains behavior that is common to more than one use case. In
other words, the common use case is included in the other use cases. Adotted arrow
that points to the common use case indicates the includes relationship. An example
would be a use case Pay Student Fees that is included in Enroll in Course and
Arrange Housing, because in both cases students must pay their fees. This may be
used by several use cases. The arrow points toward the common use case.
EXTENDS. The extends relationship describes the situation in which one use case
possesses the
behavior that allows the new use case to handle a variation or exception from the
basic use case.
Developing Use Case Diagrams
The primary use case consists of a standard flow of events in the system that describes a
standard system behaviour. The primary use case represents the normal, expected, and
successful completion of the use case. When diagramming a use case, start by asking the
users to list everything the system should do for them. This can be done using interviews, in
a joint application design session, or through other facilitated team sessions. The analyst
may also use agile stories sessions to develop use cases. Write down who is involved with
each use case, and the responsibilities or services the use case must provide to actors or
other systems. In the initial phases, this may be a partial list that is expanded in the later
analysis phases. Use the following guidelines:
1. Review the business specifications and identify the actors involved.
2. Identify the high-level events and develop the primary use cases that describe those
events and how the actors initiate them. Carefully examine the roles played by the actors to
identify all the possible primary use cases initiated by each actor. Use cases with little or
no user interaction does not have to be shown.
3. Review each primary use case to determine the possible variations of flow through the
use case. From this analysis, establish the alternative paths. Because the flow of events is
usually different in each case, look for activities that could succeed or fail. Also look for
any branches in the use case logic in which different outcomes are possible.
If a context-level data flow diagram has been created, it can be a starting point for creating
a use case. The external entities are potential actors. Then examine the data flow to
determine if it would initiate a use case or be produced by a use case.
Developing Use Case Scenarios
Each use case has a description. We will refer to the description as a use case scenario. As
mentioned, the primary use case represents the standard flow of events in the system, and
alternative paths describe variations to the behaviour. Use case scenarios may describe
what happens if an item purchased is out of stock, or if a credit card company rejects a
customer’s requested purchase. There is no standardized use case scenario format, so each
organization is faced with specifying what standards should be included. Often the use cases
are documented using a use case document template predetermined by the organization,
which makes the use cases easier to read and provides standardized information for each
use case in the model.
Creating Use Case Descriptions
Use the following four steps to create use case descriptions:
1. Use agile stories, problem definition objectives, user requirements, or a features list as a
starting point.
2. Ask about the tasks that must be done to accomplish the transaction. Ask if the use case
reads any data or updates any tables.
3. Find out if there are any iterative or looping actions.
4. The use case ends when the customer goal is complete.
Source
SYSTEMS ANALYSIS and DESIGN E I G H T H E D I T I O N (KENNETH E. KENDALL, JULIE E. KENDALL)
