Use Case

Diagram
 • A requirements analysis concept
• A case of a use of the system/product
• is a type of diagram used in software
engineering to represent the
Use Case relationships between users, actors, and
use cases.
Diagram • Describes the system's actions from the
point of view of the user.
• Captures a piece of functionality that the
system provides.
• Use cases specify only what the system is
supposed to do, i.e., the system’s
functional requirements.
 A scenario describes a sequence
of steps that are executed in
Scenario order to fulfil the goal the use
case is supposed to deliver
 Buy Parking Ticket

1. The Car Driver enters a coin in the Ticket Machine

2. The Ticket Machine indicates until when the Car Driver

can park
Scenario 3. The Car Driver continues with step 1 and 2 until satisfied

4. The Car Driver presses the button to retrieve the parking

ticket

5. The Ticket Machine prints the parking ticket

 A picture
Use Case
describes how actors relate to use
Diagram cases
and use cases relate to one
another
 • Used to gather requirements of a
system.

Objective • Used to get an outside view of a

system.

• Identify external and internal

factors influencing the system.
 • Specify the context of a
system
Purpose • Capture the requirements
of a system
• Validate a systems
architecture
 • Actors - something with a behavior
or role,

• Scenario - a specific sequence of

actions and interactions between
actors and the system, a.k.a. a use
Descriptions case instance

• Use Case - a collection of related

success and failure scenarios,
describing actors using the system
to support a goal.
ACTOR • Include all user roles that interact with the
system

• Include system components only if they

responsible for initiating/triggering a use
case.

• Someone interacting with use case (system

function). Named by noun.

• Actor has responsibility toward the system

(inputs), and Actor have expectations from
the system (outputs).
 • External objects that
produce/consume data:

Finding • Must serve as sources and destinations

for data
ACTORS • Must be external to the system
 • Who are the system’s primary users?
• Who requires system support for daily
tasks?
• Who are the system’s secondary users?
Finding • What hardware does the system handle?
ACTORS • Which other (if any) systems interact with
the system?
• 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?
USE CASE
• System function

• Named by verb.

• Each Actor must be linked to a use

case, while some use cases may not
be linked to actors
Example USE CASE
USE CASE Other Details

Include relationship between use cases (one UC must call another.)

Extend relationship between use cases (one UC calls another under

certain condition.
 Association relationships
Participation of an actor in the use case
Generalization relationships
One element (child) "is based on" another
Linking Use element (parent)
Include relationships
Cases One use case (base) includes the functionality of
another (inclusion case)
Extend relationships
One use case (extension) extends the behavior of
another (base)
Use Case
Levels
Generalization
Generalization
Include
Extend
 1. List main system functions (use cases)
in a column

2. Draw ovals around the function labels

How to Create
3. Draw system boundary
Use Case
4. Draw actors and connect them with
use cases

5. Specify include and extend

relationships between use cases.
 Vending Machine(Self Service)

Scenario:

Example – A customer buys a product

– The supplier restocks the machine
– The supplier collects money from
the machine
 Create a use case diagram for
an ATM

Activity Create a use case diagram for

an online shopping system.
System
Modeling
 • The process of developing
abstract models of a system, with
each model presenting a different
System view or perspective of the system.
Modeling
• External perspective
• Behavioral perspective
• Structural perspective
 Models of the existing system are used
during requirements engineering. They help
clarify what the existing system does and can
be used as a basis for discussing its strengths
Existing & and weaknesses.
Planned Models Models of the new system are used during
requirements engineering to help explain
the proposed requirements to other system
stakeholders. Engineers use these models to
discuss design proposals and to document
the system for implementation.
 • Activity diagrams
• which show the activities involved in a
process or in data processing.
• Use case diagrams
• which show the interactions between a
system and its environment.
UML • Sequence diagrams
Diagram • which show interactions between actors and
the system and between system
Types components.
• Class diagrams
• which show the object classes in the system
and the associations between these classes.
• State diagrams
• which show how the system reacts to
internal and external events.
 • As a way of documenting an
existing system
Use of
Graphical
Models • As a detailed system description
that can be used to generate a
system implementation.
 are used to illustrate the
Context operational context of a system -
Models they show what lies outside the
system boundaries.
Activity
Diagram
 Activity diagrams describe the workflow
behavior of a system.
What is
Activity Describes how activities are coordinated.
Diagram? Activity diagrams are the object-oriented
equivalent of flow charts and data-flow
diagrams from structured development.
 • Model business workflows
Purpose
• Model operations
Elements
of Activity
Diagram
 • When the action or activity of a
state is completed, the flow of
control passes immediately to
the next action or activity state
Transitions • A flow of control has to start
and end someplace

• initial state -- a solid ball

• stop state -- a solid ball inside
a circle
Transitions
 • A branch specifies alternate
paths taken based on some
Branching Boolean expression

• A branch may have one

incoming transition and two or
more outgoing ones
Branching
Activity
Diagram
 • Use a synchronization bar to
specify the forking and joining
Forking of parallel flows of control
and Joining
• A synchronization bar is
rendered as a thick horizontal
or vertical line
 • A fork may have one incoming
transition and two or more
outgoing transitions
Fork
• each transition represents an
independent flow of control
• conceptually, the activities of
each of the outgoing
transitions are concurrent
Fork
 • A join may have two or more
incoming transitions and one
outgoing transition

Join • above the join, the activities

associated with each of
• these paths continue in
parallel
• at the join, the concurrent
flows synchronize
Activity
Diagram
Example
 • Arrange activity diagrams into
vertical zones separated by
Swimlanes dashed lines.

• Each zone represents the

responsibilities of a particular
class or department.
 • Each swimlane has a name
unique within its
• diagram
Swimlanes • Each swimlane may represent
some real-world
• entity
• Every activity belongs to
exactly one swimlane,
• but transitions may cross lanes
Swimlanes
 • Draw the activity diagrams for
• Library Information System
• Borrow Asset
Problem to • Return Asset
Ponder • Pay Overdue Fine
Data Flow
Diagram
 Data-flow diagrams (DFDs) model a
perspective of the system that is most readily
understood by users – the flow of information
through the system and the activities that
process this information.
Data
Flow Data-flow diagrams provide a graphical
representation of the system that aims to be
Diagram accessible to computer specialist and non-
specialist users alike.
The models enable software engineers,
customers and users to work together
effectively during the analysis and specification
of requirements.
 • Processes — the activities carried out by
the system which use and transform
information. Processes are notated as
rectangles with three parts, such as “Order
Supplies” and “Make Payments” in the
Main above example.
Symbols
• Data-flows — the data inputs to and
outputs from to these activities. Data-
flows are notated as named arrows, such
as “Delivery” and “Supply Order” in the
example above.
 • External entities — the sources from
which information flows into the system
and the recipients of information leaving
the system. External entities are notated
as ovals, such as “Supplier” in the
Main example above.
Symbols
• Data stores — where information is
stored within the system. Data stores
are notated as rectangles with two
parts, such as “Supplier Details” and
“Orders” in the example above.
 • The diagrams are supplemented by
Data Flow supporting documentation including
a data dictionary, describing the
Diagram contents of data-flows and data
stores; and process definitions, which
provide detailed descriptions of the
processes identified in the data-flow
diagram.
 • is also called a Context Diagram.
• It’s a basic overview of the whole
system or process being analyzed or
modeled.
Data Flow • It’s designed to be an at-a-glance
Diagram view, showing the system as a single
Level 0 high-level process, with its
relationship to external entities. It
should be easily understood by a
wide audience, including
stakeholders, business analysts, data
analysts and developers.
 • provides a more detailed breakout of
pieces of the Context Level Diagram.
Data Flow • You will highlight the main functions
Diagram carried out by the system, as you
break down the high-level process of
Level 1 the Context Diagram into its
subprocesses.
 • The system scope and boundaries are clearly
indicated on the diagrams (more will be
described about the boundaries of systems and
each DFD later in this chapter).

Benefits • The technique of decomposition of high level

data-flow diagrams to a set of more detailed
diagrams, provides an overall view of the
complete system, as well as a more detailed
breakdown and description of individual
activities, where this is appropriate, for
clarification and understanding.
 Context models are used to
Context illustrate the operational context
Models of a system - they show what lies
outside the system boundaries.
 Thank You!

Any Questions?