Lesson 02:

Use Case Diagrams

Eng Marwa Ali Eissa

Software Developer
Email:marwa84eissa@gmail.com
You can Also Find Me on Facebook

Outline
Justify the need for a Use Case diagram

Identify and describe the essential elements in a UML

Use Case diagram
Identifying the Actors in a System.
Identifying Use Cases in a System
Create a Use Case Diagram that shows the Use
Cases in your system.
Recognize and document use case dependencies
using UML notation for extends, includes, and
generalization

Use Case Diagram

Built in early stages of development
Purpose
Specify the context of a system
Capture the requirements of a system
Identify external and internal factors influencing the system
Validate a systems architecture
Drive implementation and generate test cases
Developed by analysts and domain experts

Use Case Diagram Cont.

A Use Case diagram is one of the UML diagrams that uses the Use
Case - Driven approach for modeling the dynamic aspects of
systems
A Use Case Driven Approach to software development is an
approach where the focus of the requirements of a system is meeting
specific needs that Users of the System Under Development (SUD)
have. This approach helps ensure that Customers get the software
that they want.

What is a use case?

A case of a use of the system/product
Describes the system's actions from a the point of view of a user
The specification of actions, including variant sequences and error
sequences that a system, subsystem, or class can perform by
interacting with outside actors.
The specification of how a system interacts with external actors
Specifies one aspect of the behavior of a system, without
specifying the structure of the system
Is oriented toward satisfying a user's goal
A complete set of use cases = system requirements

How do use case diagrams fit in?

Elements of Use Case Diagram

Actor

Is a person , organization , or external system that plays a role in one or more

interactions with the system
Actors Usually represented with a stick figure
Actor triggers use case
Actor has responsibility toward the system (inputs), and Actor have
expectations from the system (outputs).

Use Cases
Are the sequence of action that can be provided as a measurable value
to an Actor. These Use Cases are represented using ovals that are
labeled with verbs that represent the systems functions

Each Actor must be linked to a use case, while some use cases may
not be linked to actors.

Elements of Use Case Diagram

Associations
Defines the relationship of an Actor with the Use Cases of the system ; Represented by a solid line.

System Boundary Box

Indicates the scope of the system functions with a rectangle drawn around
the Use Cases. The Use Cases inside the rectangle represent the
functionality that you intend to implement. Place Actors outside the Systems
boundaries.
Use Case

Use Case

Packages
Is a mechanism that allows you to organize model elements
such as Use Cases into groups.

Identifying the Actors in a System

Actors
Software systems are built to be used by people or machines.
Any person or machine that interacts with the System Under
Development is called an Actor. Actors are the users of a system.
An Actor may have one or more roles when using or interacting
with the system. In such cases, each role is considered to be a
separate Actor.
An actor represents a role that a user can play, but NOT a
specific user

Types of Actors
Human Actors
Are the people using the system who have a particular purpose or
task to accomplish.

Machine Actors
Are the machines that interact with the computer.

Primary Actors
Primary actors are those who use the systems main functions,
deriving benefits from it directly. Typically, the Primary Actor initiates
functionality with a System.
Primary actors are completely outside the system and drive the system
requirements
Primary actors use the system to achieve an observable user goal

Types of Actors cont.

Secondary Actors
An Actor who is an incidental user of the system. Typically this
includes Actors who serve in maintenance roles.
Secondary actors play a supporting role to facilitate the primary
actors to achieve their goals.
Secondary actors often appear to be more inside the system
than outside
Secondary actors are usually not derived directly from the
statement of
requirements. Hence, the designer can have more freedom in
specifying
the roles of these actors
Usually found on the right of the system (primary on the left)

Use Case Diagram :Actors

Actors are treated like classes and thus can be generalized

Finding Actors [1]

External objects that produce/consume data:
Must serve as sources and destinations for data
Must be external to the system

Finding Actors [2]

Ask the following questions:
Who are the systems primary users?
Who requires system support for daily tasks?
Who are the systems secondary users?
What hardware does the system handle?
Which other (if any) systems interact with the system in question?
Do any entities interacting with the system perform multiple roles
as actors?
Which other entities (human or otherwise) might have an interest
in the system's output?

Identifying Use Cases in a System

Use Case:
A particular task that a system can do for Actors.

Task:
A function to be performed an objective. This is not an official
UML word. The official word is Use Case.

Step:
One of a series of actions that is a stage in a process.

Sub-Task:
A function that is to be performed as a sub-process of a
higher level task or another sub-task.
For example, when a user uses an ATM, the task might be withdrawing
money from the account. On the other hand, inserting the ATM card into the
ATM is not a task; it is a step or subtask along the way to accomplishing the
task

Example Use Case Diagram : Example #1

Example Use Case Diagram : Example #2

Relationships in use-case diagrams

Association relationships
Generalization relationships
One element (child) "is based on" another element (parent)

Include relationships
One use case (base) includes the functionality of another (inclusion
case)
Supports re-use of functionality

Extend relationships
One use case (extension) extends the behavior of another (base)

Generalization relationships
A use case generalization shows that one use case is simply a special kind of
another.

In UML modeling, a generalization relationship is a relationship in which one model element (the child) is based on another model element (the parent). Generalization relationships
are used in class, component, deployment, and use-case diagrams to indicate that the child receives all of the attributes, operations, and relationships that are defined in the parent.

The child use case inherits the behavior and meaning of the parent use case.

The child may add to or override the behavior of its parent

Generalization relationships Example #1

The following figure illustrates an e-commerce application for a Web site that sells a
variety of merchandise. The application has an InventoryItem class that is a parent
class (also called a superclass). This class contains the attributes, such as Price, and
operations, such as setPrice, that all pieces of merchandise use.
After defining the parent class, a child class (also called a subclass) is created for each
type of merchandise, such as books and DVDs. The book class uses the attributes and
operations in the inventory class and then adds attributes such as author and
operations such as setAuthor. A DVD class also uses the attributes and operations in
the inventory class, but it adds attributes such as manufacturer and operations such as
setManufacturer, which are different from those in the book class.

Generalization relationships Example #2

Include relationships
In the process of developing a use case model, we may discover that some use
cases share common behaviors.
There are also situations where some use cases are very similar but they have some additional behaviors.
For example, Withdraw Money and Deposit Money both require the user to log-on to an ATM system

Include relationships cont.

Include relationships cont.

Include relationships are used when two or more use cases share
some common portion in a flow of events
This common portion is then grouped and extracted to form an
inclusion use case for sharing among two or more use cases
Most use cases in the ATM system example, such as Withdraw
Money, Deposit Money or Check Balance , share the inclusion usecase Login Account

Include relationships cont.

In UML modeling, an include relationship is a relationship in which one
use case (the base use case) includes the functionality of another use case
(the inclusion use case). The include relationship supports the reuse of
functionality in a use-case model.
You can add include relationships to your model to show the following
situations:
The behavior of the inclusion use case is common to two or more use
cases.
The result of the behavior that the inclusion use case specifies, not the
behavior itself, is important to the base use case.

a Use Case that is a subtask of

another Use Case

a Use Case that uses the

functionality of another Use
Case

Include relationships Example #1

In an ATM, the process of Login can be thought of as a subtask of
many different Use Cases. It can be used when a person Withdraws
Money, Deposits Money or Checks Balance .You can draw this in a
Use Case diagram.

Include relationships Example #2

In an ATM, the process of printing a receipt can be thought of as a
subtask of many different Use Cases. It can be used when a person
withdraws money or when he deposits money. It could also be used
when a bank customer wants to checks his balance. You can draw
this in a Use Case diagram.

Include relationships Example #3

in a hotel reservation system, you might find that both the Cancel
Reservation use case and the CheckIn Reservation use case need to
perform the same steps to find a reservation.

Extend relationships
In UML modeling, you can use an extend relationship to specify that
one use case (extension) extends the behavior of another use case
(base). The Extending Use Case adds to the existing functionality and
characteristics of the Base Use Case. This type of relationship reveals
details about a system or application that are typically hidden in a use
case.
The extend relationship specifies that the incorporation of the
extension use case is dependent on what happens when the base use
case executes. The extension use case owns the extend relationship.
You can specify several extend relationships for a single base use
case.
While the base use case is defined independently and is meaningful
by itself, the extension use case is not meaningful on its own.

Extend relationships cont.

You can add extend relationships to a model to show the following situations:

A part of a use case that is optional system behavior

A subflow is executed only under certain conditions
A set of behavior segments that may be inserted in a base use case

The extension takes place at one or more extension points defined in

the extended use case.
Extend relationship is shown as a dashed line with an open arrowhead
directed from the extending use case to the extended (base) use case. The
arrow is labeled with the keyword extend.

Extend relationships Example #1

Assume that a customer wants to withdraw money from an ATM. He
can withdraw the money from his savings account, credit card
account, or from another bank. Therefore, the task of withdrawing the
money can be extended with the tasks of withdrawing money from the
savings account, withdrawing money from the credit card account, and
withdrawing money from another bank.

Extension points
In UML models, an extension point identifies the point in the base
use case where the behavior of an extension use case can be
inserted. The extension point is specified for a base use case and is
referenced by an extend relationship between the base use case
and the extension use case.
A base use case can have several extension points. Each extension
point has a unique name that identifies one or several locations in
the behavior sequence of the base use case.
As the following figure illustrates, the name of the extension is listed
in the Extension Points compartment of the use case.

Conditions in an Extend Use Case

To show how one Use Case extends another Use Case, extension points are
added in the UML. In these extension points, the conditions from the UML
can also be specified that shows the actual logic necessary for one Use Case
to extend to another. They also show the exact extension point that is used
between the two Use Cases. These conditions are specified as a
note to the extend relationship

The extensions operate only under certain conditions

Extend relationships Example #2

Registration use case is complete and meaningful on its own.

It could be extended with optional Get Help On Registration use case.

Registration use case is conditionally extended by Get Help On Registration

use case in extension point Registration Help.

Summary of Notations

Summary of Notations Cont.

Use Case Relationships Compared

Generalization

Base use case could be

abstract use case(incomplete) or
concrete (complete).

Extend

Include

Base use case is complete (concrete) Base use case is incomplete (

by itself, defined independently.
abstract use case).

Specialized use case is required, not Extending use case is optional,

optional, if base use case is abstract. supplementary.

Included use case required, not

optional.

No explicit location to use

specialization.

Has at least one explicit extension

location.

No explicit inclusion location but is

included at some location.

No explicit condition to use

specialization.

Could have optional extension

condition.

No explicit inclusion condition.

Case Study : Online Shopping Portal

Case Statement
In this case, we will be designing a simple online shopping portal .The
site will provide a soothing shopping experience for customers. The
system will allow more than one categories and different brands under
the segment. The case will trace the following sequence.

Scenario
A customer visits the online shopping portal. A customer may buy
item or just visit the page and logout. The customer can select a
segment, then a category, and brand to get the different products in
the desired brand

Example #2 : Online Shopping Portal cont.

The customer can select the product for purchasing. The process can
be repeated for more items. Once the customer finishes selecting the
product/s the cart can be viewed , If the customer wants to edit the final
cart it can be done here.
For final payment the customer has to login the portal, if the customer
is visiting for the 1st time he must register with the site, else the
customer must use the login page to proceed
Final cart is submitted for payment and card details and address
(where shipment has to be made) are be confirmed by the
customer .Customer is confirmed with a shipment Id and delivery of
goods within 15 days.

Thank You !