Use Case Modeling

1
 Use Case Modeling
• A Use Case is:
– a representation of a discrete and meaningful set of work
performed by a user (or another system)
– a typical sequence of actions that a user performs in
order to complete a given task
• Examples of Use Cases are Add Order, Delete Order, Modify
Order, Searching a customer, Registering a Student…
• Each Use Case has a description which describes
the functionality that will be built in the proposed
system
• A Use Case may:
– 'include' another Use Case's functionality or
– 'extend' another Use Case with its own behavior
• Use Cases are typically related to 'actors'
2
 Use Case Modeling…
• Actors: An actor portrays any entity (or entities) that performs
certain roles in a given system.
• The different roles the actor represents are the actual
business roles of users in a given system.
• An actor in a use case diagram interacts with a use case.
• For example, for modeling a banking application:
– a customer entity represents an actor in the application.
– the person who provides service at the counter is also an
actor.
• But it is up to you to consider what actors make an impact on
the functionality that you want to model.
• If an entity does not affect a certain piece of functionality that
you are modeling, it makes no sense to represent it as an
actor.
• An actor is shown as a stick-man figure in a use case
diagram depicted "outside" the system boundary.
3
 Use Case Modeling…
• Use Case diagrams are made up of one or
more Actors linked to one or more Use cases

4
 Includes
• One Use Case may include the functionality of another
as part of its normal processing
• Generally, it is assumed that the included Use Case will
be called every time the basic path is run
• An example may be to list a set of customer orders to
choose from before modifying a selected order - in this
case the <list orders> Use Case may be included every
time the <modify order> Use Case is run
• A Use Case may be included by one or more Use
Cases, so it helps to reduce duplication of
functionality by factoring out common behavior into
Use Cases that are re-used many times
<<includes>>
ModifyOrder ListOrders

5
 Extends
• One Use Case may extend the behavior of
another - typically when
– exceptional circumstances are encountered
– used to make optional interactions explicit
• Keeps the description of the basic use case simple.
• For example, if before modifying a particular
type of customer order, a user must get
approval from some higher authority, then
the <get approval> Use Case may optionally
extend the regular <modify order> Use Case.
<<includes>> <<extends>>
ListOrders ModifyOrders GetApproval

6
 Generalizations
– Much like super-classes in a class diagram.
– A generalized use case represents several
similar use cases.
– One or more specializations provides details
of the similar use cases.

7
 Scenarios
• A scenario is an instance of a use case
– A specific occurrence of the use case
• a specific actor ...
• at a specific time ...
• with specific data.

8
 Use Case Diagram
• The Use case diagram is used to identify the
primary elements and processes that form the
system.
• The primary elements are termed as "actors"
and the processes are called "use cases"
• The Use case diagram shows which actors
interact with each use case
• Generally, a use case diagram is primarily made
up of—actors and use cases

9
 Use Case Diagram…
• A use case diagram captures the functional aspects of a
system.
• More specifically, it captures the business processes
carried out in the system.
• As you discuss the functionality and processes of the
system, you discover significant characteristics of the
system that you model in the use case diagram.
• Due to the simplicity of use case diagrams, and more
importantly, because they are free of all technical jargon,
use case diagrams are a great storyboard tool for user
meetings.
• Use case diagrams define the requirements of the
system being modeled and hence are used to write test
scripts for the modeled system.

10
Example Use Case Diagram
<<includes>>

Login

<<includes>>

<<extends>> <<includes>>

Specify another
bank

11
Example of Generalization,
Extension and Inclusion

12
 How to go about Use Cases
• So who should normally be involved in the
creation of use cases?
• Normally, domain experts and business
analysts should be involved in writing use cases
for a given system.
• Use cases are created when the requirements
of a system need to be captured.
• Because, at this point no design or development
activities are involved, technical experts should
not be part of the team responsible for creating
use cases as their expertise comes in use later
in the software lifecycle.
13
 How to go about Use Cases…
• If you were analyzing a sentence in
English, the subject in the sentence can
be identified as a potential actor and the
verb part of the sentence can be a
potential use case.
• Remember, this may or may not apply to
the problem at hand, but is a good
starting point for use case modeling.

14
 Identifying Actors
• To identify an actor, search in the
problem statement for business terms
that portray roles(the act of showing or
describing picture, book) in the system.
• For example, in the statement "patients
visit the doctor in the clinic for medical
tests," "doctor" and "patients" are the
business roles and can be easily identified
as actors in the system.
15
 Identifying Use Cases
• A use case is a "distinct business functionality.“
• To choose a business process as a likely candidate for
modeling as a use case, you need to ensure that the
business process is discrete in nature.
• As the first step in identifying use cases, you should list
the discrete business functions in your problem
statement.
• Each of these business functions can be classified as a
potential use case.
• Remember that identifying use cases is a discovery
rather than a creation.
• As business functionality becomes clearer, the
underlying use cases become more easily evident.
• A use case is shown as an ellipse in a use case diagram

16
 System Boundary
 System boundary: A system boundary
defines the scope of what a system will be.
 A system cannot have infinite functionality.
 So, it follows that use cases also need to
have definitive limits defined.
 A system boundary of a use case diagram
defines the limits of the system.
 The system boundary is shown as a rectangle
spanning all the use cases in the system.

17
 Use Case Description
• The next step after finalizing of use case diagrams is to
document the business functionality into clear-cut and
detailed use case specifications.
• Because use cases are used as an input to the other
project phases such as design, development, and testing,
we need to ensure that the visual depiction of the business
requirements is translated into clear and well-defined
requirements in the form of use case specifications.
• Elaborated use case specifications are used as an input
for design and development and for writing test cases (unit,
system, and regression tests, as the case may be).
• A use case specification document should enable us to
easily document the business flow.
• Information that you document in a use case specification
includes what actors are involved, the steps that the use
case performs, business rules, and so forth.
• A use case specification document should cover the
following areas: 18
 Use Case Description…
• Use Case Name: a verb phrase used to identify the use case by a
name
• Actors: List the actors that interact and participate in this use case.
• Pre-conditions: Pre-conditions that need to be satisfied for the use
case to perform/execute.
• Post-conditions: Define the different states in which you expect the
system to be in, after the use case executes.
• Basic Flow: List the basic events that will occur when this use case is
executed. Include all the primary activities that the use case will
perform. Be fairly descriptive when defining the actions performed by
the actor and the response of the use case to those actions. This
description of actions and responses are your functional
requirements. These will form the basis for writing the test case
scenarios for the system.
• Alternative flows: Any subsidiary events that can occur in the use
case should be listed separately. Each such event should be completed
in itself to be listed as an alternative flow. A use case can have as
many alternative flows as required. But remember, if there are too
many alternative flows, you need to revisit your use case design to
make it simpler and, if required, break the use case into smaller
discrete units.
19
 Use Case Description…
• Special Requirements: Business rules for the basic and
alternative flows should be listed as special requirements
in the use case narration. These business rules will also
be used for writing test cases. Both success and failure
scenarios should be described here.

• Use case relationships: For complex systems, it is

recommended that you document the relationships
between use cases. If this use case extends from other
use cases or includes the functionality of other use
cases, these relationships should be listed here. Listing
the relationships between use cases also provides a
mechanism for traceability.

20
Use Case Description Template
Use Case ID:

Use Case Name:

Created By: Last Updated By:

Date Created: 04/07/07 Date Last Updated: 04/07/07

Version: 0

Actors:

Description:

Preconditions:

Post-conditions:

Normal Course:

Alternative Courses:

Includes:

Frequency of Use:

Business Rules
21
Example description of a use
Use case: Open file
case
Related use cases:
Generalization of:
• Open file by typing name
• Open file by browsing

Steps:
Actor actions System responses
1. Choose ‘Open…’ command 2. File open dialog appears
3. Specify filename
4. Confirm selection 5. Dialog disappears

22
 Example (continued)
Use case: Open file by typing name

Related use cases:

Specialization of: Open file

Steps:
Actor actions System responses
1. Choose ‘Open…’ command 2. File open dialog appears
3a. Select text field
3b. Type file name
4. Click ‘Open’ 5. Dialog disappears

23
 Example (continued)
Use case: Open file by browsing

Related use cases:

Specialization of: Open file
Includes: Browse for file

Steps:
Actor actions System responses
1. Choose ‘Open…’ command 2. File open dialog appears
3. Browse for file
4. Confirm selection 5. Dialog disappears

24
 Example (continued)
Use case: Attempt to open file that does not exist

Related use cases:

Extension of: Open file by typing name

Actor actions System responses

1. Choose ‘Open…’ command 2. File open dialog appears
3a. Select text field
3b. Type file name
4. Click ‘Open’ 5. System indicates that file
does not exist
6. Correct the file name
7. Click ‘Open’ 8 Dialog disappears

25
 Example (continued)
Use case: Browse for file (inclusion)

Steps:
Actor actions System responses
1. If the desired file is not displayed, 2. Contents of directory is
select a directory displayed
3. Repeat step 1 until the desired file is
displayed
4. Select a file

26
 Dos and Don'ts
• Use cases should not be used to capture all the details of a
system.
• The granularity to which you define use cases in a
diagram should be enough to keep the use case diagram
uncluttered and readable, yet, be complete without missing
significant aspects of the required functionality.
• You will encounter such decision points of the level of
granularity that you need to define when you build any of
the UML diagrams.
• An important rule that gets forgotten during use creation is
the creeping in of design issues. Use cases are meant to
capture "what" the system is, not "how" the system will be
designed or built.
• Use cases should be free of any design characteristics. If
you end up defining design characteristics in a use case,
you need to go back to the drawing board and start again.
27
 Case study- Courseware Management System
• Use case modeling involves analyzing the
problem statement to determine the
business processes of the system.
• We will now design the use case model for
the Courseware Management System
case study.

28
 Case study- Courseware Management System…
• Let us analyze the problem statement to identify the
potential actors and use cases of the system.
• First, let us list the potential actors. A quick look at the
problem statement shows up the following terms and
entities specific to the system:
– Courses and Topics that make up a course
– Tutors who teach courses
– Course administrators who mange the assignment of the
courses to tutors
– Calendar or Course Schedule is generated as a result of the
inputs of Tutors and Courses.
– Students who refer to the Course schedule or Calendar to
decide which courses they wish to take up for study

29
 Identifying Actors of the Courseware
Management System
• Out of the preceding list, one thing is clear. There are
certain terms and entities in the list that identify that they
perform certain roles or business processes. We will
discuss what these business processes are after we
complete our analysis for identifying actors. For now, we
focus on identifying the actors in the system. From the
preceding list, we can see that there are some entities
that perform an action and some that form the target for
the action. The entities that perform action will be the
actors for the Courseware Management System. In the
above list, the actors that we can identify are:
• Tutors
• Course administrators
• Students

30
 Identifying Actors of the Courseware
Management System…
• But, because students are not the potential active
participants for this system, we will drop them
from the list of actors. Similarly, tutors are not
active participants from our system's perspective,
and hence, we will exclude tutors from our list of
roles. Yet, we will still record them in our use
case model since we do not wish to loose this
business information. Our final list of primary
actors has now come down to only one:
• Course administrators

31
Identifying Use Cases of the Courseware
Management System
• Next, let us identify the potential business processes in the
Courseware Management System. The primary business flows in
the system are:
• Manage courses
• Manage course assignments
• As we analyze the problem statement further, we can determine
some discrete processes within these primary business flows. To
manage courses, the actor needs to have the ability to view existing
courses, manage the course information for a course, such as
duration and so forth, and also manage the addition or removal of
topics for a course. So, within the "Manage courses" use case, we
can identify the following sub processes:
• View courses
• Manage topics for a course
• Manage course information

32
 Identifying Use Cases of the Courseware
Management System…
• And similarly, the "Manage course assignment" use case can be refined into
smaller discrete processes such as viewing the course calendar, viewing
tutors, managing the tutor information of tutors working for the organization,
and of course, assigning courses to tutors. Now, the use cases that we have
identified within the "Manage course assignment" use case are:
• View course calendar
• View tutors
• Manage tutor information
• Assign courses to tutors
• Our final list of use cases for the courseware management system will now
be:
• View courses
• Manage topics for a course
• Manage course information
• View course calendar
• View tutors
• Manage tutor information
• Assign courses to tutors

33
Use case Diagram

34