Use Cases
Introduction to Software Engineering
1
Context models
Context models are used to illustrate the operational context of a
system - they show what lies outside the system boundaries.
Social and organisational concerns may affect the decision on where
to position system boundaries.
Architectural models show the system and its relationship with other
systems
System boundaries are established to define what is inside and what
is outside the system.
◦ They show other systems that are used or depend on the system being
developed.
The position of the system boundary has a profound effect on the
system requirements.
Defining a system boundary is a political judgment
◦ There may be pressures to develop system boundaries that increase /
decrease the influence or workload of different parts of an organization.
2
Context models simply show the other systems in the environment,
not how the system being developed is used in that environment.
Process models reveal how the system being developed is used in
broader business processes.
UML activity diagrams may be used to define business process
models.
3
Introduction
Use Case: “... a typical interaction between a user and
a computer system”, Booch
◦ Here, “user” is anything that needs or invokes the functionality of the
system
◦ “Computer system” is the system being modeled
Use cases capture and document the user-visible
functionality of a system (functional requirements)
Use cases capture how the system will benefit the user
Each use case represents a discrete goal for the user
4
Example Use Case Diagram
5
Use Case Diagrams
Use Case Diagrams provide a visual way to document user goals and
explore possible functionality
Three primary modeling components:
◦ Actors – Relationships between
◦ Use Cases use cases
Record class Review
grades Transcripts
Teacher
Authorized Student
Staff Worker
6
Actors
Actors are people or external systems that need to interact with our
system
Finding Actors
● Who or what will use the main functionality of the system?
● Who or what will provide input to this system?
● Who or what will use output from this system?
● Who will need support from the system to do their work?
● Are there any other software systems with which this one
needs to interact
● Are there any hardware devices used or controlled by this
system?
Answer these questions to find actors for an iPod
7
Relationships Between Actors
Actors can be related by generalization/specialization
Actors are classifiers (not individual users)
Student e
w is
e r
th
s . .o
u
b vio
y o t
Graduate r
e ip i
n v sk
Student
whe
s
thi
Do
8
Use Case Relationships
Includes
Extends
Generalization
After a while you realize extends and generalization are not too
different. Just know generalization and includes… forget about
extends (the difference is only in intent)
9
Use-Case Relationships
Includes Dependency: Defines how one use case can invoke behavior
defined by another use case
Alter Student
Grade
<<includes>>
Record Grades for a
Teacher
Section
10
Use-Case Relationships
Extends dependency: defines a use-case that is a variation of another,
usually for handling an abnormal situation
Alter Student
Grade
<<extends>>
Alter student grade for Authorized
a class taken more Staff Worker
than a year ago
11
Use-Case Relations
Generalization: Defines one use case as a generalization of another.
Replaces generic functionality with alternate implementation
Alter Student
Grade
Alter Student Grade for
Teacher
a Graduate Course
12
Documenting Use Cases
List Actors What is system response
to external event? What is
the user’s goal?
List External Events Determine expected
behavior
Name behaviors as use
cases
Add relations (includes,
Document use case (basic
extends, generalization)
flow, alternate, exception)
Be Patient… let them unfold
13
Benefits of Use Cases
Use cases diagrams capture user-visible functions
Identifying actors help capture who needs the system
functionality
Relationships between use cases document opportunities for
reuse
Use cases provide a basis planning and scheduling incremental
development
Use cases can provide a basis for system testing
14
In Class Exercise
Lets create a use case diagram for
◦ iPod
◦ Television set
◦ Elevator
◦ ATM
◦ Online Scrabble game
◦ Word Processor
15
Use cases for BSCS Show system
boundary
Show Actors
outside boundary
Use extend, include,
generalization/speci Typically one
alization where diagram for your
appropriate project is sufficient
16
Extends vs. Includes vs.
Generalization
Extends, includes, and generalization may appear similar, but differ in
intent
◦Extend dependencies model variations from normal
workflows
◦Specializations are refinements of a general use cases
◦“Include” uses case (or sub-use cases), unlike
specializations, can represent different goals or processes
◦Include dependencies are a form of aggregation
◦The actors for a general use case are also actors for the use
cases that specialize it
◦Often there are no actors for sub-use cases
17
User Goals
User Goals are statements that represent what the users need to
accomplish, independent of specific software features
Examples of user goals for a Student Records Management System
◦Ensure that a student’s records reflects courses taken and
grades received in those courses
◦Allow only authorized faculty and staff to update student
records
◦Ensure that students can obtain copies of their own (and
only their) records in a timely manner
18
System Interactions
Represent expected interacts between users and the
computer-based system
Suggest how the system fulfills a user goal
Examples:
◦ A teacher alters a course grade for a student by
◦ selecting a semester
◦ selecting a course
◦ selecting a student
◦ reviewing the previous grade
◦ entering a new grade
◦ confirming the change
◦ A process for an administrator to create a new user
◦ A process for granting a user access rights
19
Difference between state diagram and flowchart –
The basic purpose of a state diagram is to portray various changes in
state of the class and not the processes or commands causing the
changes. However, a flowchart on the other hand portrays the
processes or commands that on execution change the state of class or
an object of the class.
20
Difference b/w Activity and
use case diagram
Use case diagrams and activity diagrams are UML diagrams that
describe changes within a system. The key difference between the two
diagrams is that a use case diagram is designed to model the user
interactions within the system. In contrast, an activity diagram is
designed to model the system's workflow.
21
Unified Modeling Language
(UML)
Structure Diagrams – Used to model the static structure of a system,
for example- class diagram, package diagram, object diagram,
deployment diagram etc.
Behavior diagram – Used to model the dynamic change in the system
over time. They are used to model and construct the functionality of a
system. So, a behavior diagram simply guides us through the
functionality of the system using Use case diagrams, Interaction
diagrams, Activity diagrams and State diagrams.
22
behavioral Model
Behavioral model describe the overall behavior of the system.
There are two types of behavioral models that are used to describe the
system behavior, one is data processing model and another is state
machine models.
Data processing models are also known as DFD (Data Flow Diagram)
which is used to show how data is processed as it moves through the
system. State machine model is also known as State diagram which is
used to show how the system will react with external events.
23
Data Flow Diagram
Data flow diagram is used to model the system’s data processing.
It is also cay as the Functional model as it is a graphical representation
of an enterprise function within a defined scope. Data flow diagram
shows end to end data processing.
It can be easily converted into software as they just represent flow of
the data objects. DFD diagram enable Software engineer to develop a
model of the information domain and Functional domain at the same
time.
It provide a logical model of the system and show the flow of the data
and the flow of logic involved.
24
Characteristics of Data Flow
Diagram
It shows the process, that transforms incoming data flows into outgoing
data flows.
Process that performs this transformation normally creates as well as
uses data.
External entities send and receive data flow from the systems.
It is also called a bubble chart.
Data flow diagram support a top-down approach for analysis.
25
Guidelines for Data Flow
Diagram
Level 0 DFD should depict software system as single bubble.
Primary input and output are carefully noted.
Refinement should begin by isolating candidate processes, data objects,
data stores to be represented at the next level.
All arrows and bubbles should be labeled with full names.
Information flow continuity must be maintained from level to level.
That means the data objects that flow into the system of any
transformation at one level must be the same. Data objects that flow
into transformation at the more refined level.
One bubble at a time should be refined.
26
Data Flow Diagram Notation
Data flow diagram consists of a series of symbols joined together by a
line. Data objects are represented by circles which are also called
bubble charts.
Data flow diagram are represented in hierarchical order.
The first level data flow model is also called as DFD 0 level or context
diagram which represents the system as a whole.
Second level data flow model refines the context diagram and provides
more details of first-level DFD.
In a similar way, third level DFD refines the second level DFD, and so on
27
Data Flow: It represents the movement of data flow from a specific
origin to a destination.
Process: It represents the users, procedures, or devices that use the
data.
Entity: It represents the source of data or destination data external
sources or destination of data which may be users, programs,
organizations or other entities that interact with the system but are
outside its boundary.
Data Store: There can be a single DFD diagram or can be exploded into
various levels lime level 1, level 2, level 3, etc.
28
Notations
29
State Diagram
State diagram is a dynamic model which represents the changes of state
that an object goes through during the lifetime in response to events. It is
used to help the developer better understand any complex functionality of
specialized areas of the system.
Initial State
It represents the start point of the diagram. It is also called as pseudo state
where state has no variables and no activities.
Final State
It represents the end point of the diagram. It is also pseudo state as it
doesn’t have any variable or activities. State diagram can have zero or more
final states.
30
State
It represents the state of the object at an instant of time. State is a
recognizable situation and exists over an interval of time.
Transition
It represents the changes from one state to other. It is denoted by an
arrow. The event or action causing the transition is written beside the
arrow, separated by slash. Trigger less transition occurs when the state
completed an activity.
Event and Action
Trigger that causes a transition to occur and changes the state is
called event or action.
31
Fork – We use a rounded solid rectangular bar to represent a Fork
notation with incoming arrow from the parent state and outgoing arrows
towards the newly created states. We use the fork notation to represent
a state splitting into two or more concurrent states
History State
A flow may require that the object go into a wait state and on the
occurrence of a certain event, go back to the state it was in, in this
situation this notation is used.
Signal
When even causes the trigger to be sent to a state that causes the
transition, then that message sent by the event is called a signal.
Self Transition
A state that has a transition that returns to itself is called self-transition.
32
State Diagram
33
state diagram for an online
order
34
35