Data Flow Diagrams
SE205 Software Engineering
Iteration 2:
Functional delivery in context
13-Apr-15
Functional delivery



Deliver to the client a
system that meets
most of their needs
Usable
Stable
13-Apr-15
13-Apr-15
Requirements determination


Determine how the current information
system operates and what users would
like to see in the new system.
Outcomes: Various forms of information
gathered
13-Apr-15
Structured Modeling
We can model the functions of a business
using a range of structured diagrams and
techniques:
 Functional
decomposition
 Data
flow
 Entity Relationship
 Logic structure
 Structure charts
13-Apr-15
Agile Modeling (AM)



AM is a chaordic, practices-based process for modeling
and documentation
AM is a collection of practices based on several values
and proven software engineering principles
AM is a light-weight approach for enhancing modeling
and documentation efforts for other software processes
such as XP and RUP
Principles and Practices of
Agile Modeling (AM)
Other Techniques
(e.g. Database refactoring)
A Base Software Process
(e.g. XP, RUP, DSDM, FDD, …)
Your Software Process
Copyright 2001-2005 Scott W. Ambler
13-Apr-15
What Are Agile Models?

Agile models:








Fulfill their purpose
Are understandable
Are sufficiently accurate
Are sufficiently consistent
Are sufficiently detailed
Provide positive value
Are as simple as possible
Just Barely
Good Enough
Ideal
Realistic
Value
Effort
Copyright 2005 Scott W. Ambler
Agile models are just
barely enough!
13-Apr-15
The Core of AM
You Need to Adopt at Least the Core
Core Principles
Core Practices
 Assume Simplicity
 Active Stakeholder Participation
 Embrace Change
 Apply the Right Artifact(s)
 Enabling the Next Effort is Your
 Collective Ownership
Secondary Goal
 Create Several Models in
 Incremental Change
Parallel
 Model With a Purpose
 Create Simple Content
 Multiple Models
 Depict Models Simply
 Maximize Stakeholder
 Display Models Publicly
Investment
 Iterate to Another Artifact
 Quality Work
 Model in Small Increments
 Rapid Feedback
 Model With Others
 Software Is Your Primary Goal
 Prove it With Code
 Travel Light
 Single Source Information
 Use the Simplest Tools
13-Apr-15
Model With Others



The modeling equivalent of pair
programming
You are fundamentally at risk whenever
someone works on something by
themselves
Several heads are better than one
13-Apr-15
Agile Models
www.agilemodeling.com/artifacts/
Usage Modeling
- Acceptance Tests
- Essential Use Cases
- Features
- System Use Cases
- Usage scenario
- User Stories
- UML Use Case Diagram
User Interface Development
- Essential User Interface Prototype
- User Interface Flow Diagram
- User Interface Prototype
Supplementary Requirements
Modeling
Detailed Structural Modeling
- External Interface (EI) Specification
- Physical Data Model (PDM)
- UML Class Diagram
- UML Object Diagram
- Business Rules
- Conceptual Cases
- Constraints
- Glossary
- Technical Requirements
Dynamic Object Modeling
Conceptual Domain Modeling
- UML Communication Diagram
- UML Composite Structure Diagram
- UML Interaction Overview Diagram
- UML Sequence Diagram
- UML State Machine Diagram
- UML Timing Diagram
- Class Responsibility Collaborator (CRC) Cards
- Logical Data Model (LDM)
- Object Role Model (ORM) Diagram
- Robustness Diagram
- UML Class Diagram
Architectural Modeling
- Change Cases
- Free Form Diagram
- Security Threat Modeling
- UML Component Diagram
- UML Deployment Diagram
- UML Package Diagram
Process Modeling
- Data Flow Diagram (DFD)
- Flow Chart
- UML Activity Diagram
- Value Stream Map
- Workflow diagram
13-Apr-15
Copyright 2003-2005
Scott W. Ambler
Agile Documentation

Agile documents:









Valid reasons to document:





Maximize stakeholder investment
Are concise
Fulfill a purpose
Describe information that is less likely to change
Describe “good things to know”
Have a specific customer and facilitate the work efforts of that customer
Are sufficiently accurate, consistent, and detailed
Are sufficiently indexed
Your project stakeholders require it
To define a contract model
To support communication with an external group
To think something through
www.agilemodeling.com/essays/agileDocumentation.htm
13-Apr-15
Data Flow Diagrams
13-Apr-15
Business Process
mapping - XSOL
13-Apr-15
Process Modeling
Data flow diagramming


Graphical depiction of a system
Show how data flows through your system
and what is being done to it along the way
13-Apr-15
Figure 2-2
A General Depiction of a System
13-Apr-15
Figure 2-4
A Fast Food Restaurant as a System
13-Apr-15
Figure 2-7
A Fast Food Restaurant’s Customer Order Information System Depicted in a Data Flow
Diagram
13-Apr-15
Process Modeling

Graphically Represents
Functions or
 Processes


Which
Capture
 Manipulate
 Store
 Distribute data between a system, its environment
and its components

13-Apr-15
Deliverables
Set of data flow diagrams showing:
 Scope
of system
 Existing system modeled
 New system modeled
13-Apr-15
Key Definitions


Logical process models describe
processes without suggesting how they
are conducted
Physical models include information about
how the processes are implemented
13-Apr-15
Deliverables - ideal
1. Context data flow diagram [DFD]

Shows system scope
2. DFD/s of current physical system

Specifies people and technologies used
3. DFD/s of current logical system

Show data processing functions
4. DFD/s of new logical system
5. Description of each DFD component

Data repository
13-Apr-15
Data Flow Diagram Symbols
13-Apr-15
Process

The work or actions performed on data so
that they are transformed, stored or
distributed

Verb phrase name, eg,
Update
 Calculate
 Verify

13-Apr-15
Data store

Data at rest, which may take the form of
many different physical representations
Eg,



Database
Files
Folder
13-Apr-15
Source/sink


The origin and/or destination of data,
sometimes referred to as external entities
Eg,




Clients
Employees
Bank
Inland Revenue
13-Apr-15
Data flow


Data in motion, moving from one place in the
system to another
Eg,



Invoice
Receipt
Enrolment form
Must be named, often has a paper form associated with
it.
13-Apr-15
Concepts
Data
movement
Coupling
Timing of data flow
DFD hides some Physical Characteristics
 Frequency
 Volume
of Data
13-Apr-15
Steps in Building DFDs





Build the context diagram
Create DFD fragments
Organize DFD fragments into level 0
Decompose level 0 DFDs as needed
Validate DFDs with user
13-Apr-15
Context Diagram



Shows the context into which the business
process fits
Shows the overall business process as just
one process
Shows all the outside entities that receive
information from or contribute information to
the system
13-Apr-15
Figure 8-4
Context Diagram of Hoosier Burger’s Food Ordering System
• One process only
13-Apr-15
• Single process (0)
represents entire system
13-Apr-15
Level 0 Diagram



Shows all the processes that comprise the
overall system
Shows how information moves from and to each
process
Adds data stores
13-Apr-15
Figure 8-5
Level-0 DFD of Hoosier Burger’s Food Ordering System
13-Apr-15
13-Apr-15
Decomposition of DFDs

Functional Decomposition
 iterative
process of breaking down the
description of a system into finer and finer
detail
 keep going until point where process can no
longer be logically broken down
 creates a series of exploding charts
Level-n diagram
13-Apr-15
Level 1 Diagrams




Shows all the processes that comprise a single process
on the level 0 diagram
Shows how information moves from and to each of these
processes
Shows in more detail the content of higher level process
Level 1 diagrams may not be needed for all level 0
processes
13-Apr-15
Figure 8-7
Level-1 Diagram Showing Decomposition of Process 1.0 from the Level-0 Diagram
13-Apr-15
Figure 8-5
Level-0 DFD of Hoosier Burger’s Food Ordering System
13-Apr-15
Level 2 Diagrams




Shows all processes that comprise a single process on
the level 1 diagram
Shows how information moves from and to each of these
processes
Level 2 diagrams may not be needed for all level 1
processes
Correctly numbering each process helps the user
understand where the process fits into the overall
system
13-Apr-15
Figure 8-8
Level-1 Diagram Showing the Decomposition of Process 4.0 from the Level-0
Diagram
13-Apr-15
Figure 8-9
Level-2 Diagram Showing the Decomposition of Process 4.3 from the Level-1 Diagram
for Process 4.0
13-Apr-15
Your Turn
At this point in the process it is easy to lose track
of the “big picture”.

Sketch a context diagram for your project


How many processes?
What are the external sources and sinks?
13-Apr-15
Creating Data Flow
Diagrams
Data flow diagram components




Data Store
Process
Source/Sink
Data flow
13-Apr-15
Process

The work or actions performed on data so
that they are transformed, stored or
distributed

Verb phrase name, eg,
Update
 Calculate
 Verify

13-Apr-15
Data store

Data at rest, which may take the form of
many different physical representations
Eg,



Database
Files
Folder
13-Apr-15
Source/sink


The origin and/or destination of data,
sometimes referred to as external entities
Eg,




Clients
Employees
Bank
Inland Revenue
13-Apr-15
Data flow


Data in motion, moving from one place in the
system to another
Eg,



Invoice
Receipt
Enrolment form
Must be named, often has a paper form associated with
it.
13-Apr-15
Concepts
Data
movement
Coupling
Timing of data flow
DFD hides some Physical Characteristics
 Frequency
 Volume
of Data
13-Apr-15
Steps in Building DFDs





Build the context diagram
Create DFD fragments
Organize DFD fragments into level 0
Decompose level 0 DFDs as needed
Validate DFDs with user
13-Apr-15
Context Diagram
Overview of the system showing:
 System
Boundaries
 External Entities that interact with the
system
 Major information flows between Entities
and System
13-Apr-15
Figure 2-2
A General Depiction of a System
13-Apr-15
13-Apr-15
Next step

What processes are represented by the
single process in the context diagram?
• Capturing data from
different sources
• Maintaining data stores
• Producing and distributing
data to different sinks
• High level descriptions of
data transformation
operations
13-Apr-15
DFD Layout Tips



All process names must be verb phrases
Maintain organisation’s viewpoint in naming
processes
Layouts often place
 processes in the center
 inputs from the left
 outputs to the right
 stores beneath the processes
13-Apr-15
Level - 0 diagram


A dataflow diagram that represents all of
the system’s major processes, data flows,
and data stores at a high level of detail.
Often corresponds to selection of activities
on main system menu.
13-Apr-15
Level 0 Tips



Generally move from top to bottom, left to
right
Minimize crossed lines
Iterate as needed
 The
DFD is often drawn many
times before it is finished, even with
very experienced systems analysts
13-Apr-15
Figure 8-5
Level-0 DFD of Hoosier Burger’s Food Ordering System
13-Apr-15
Tips for Level 1 and Below



Sources for inputs and outputs listed at higher
level
List source and destination of data flows to
processes and stores within each DFD
Depth of DFD depends on overall system
complexity
 Two processes generally don’t need lower
level
 More than seven processes become overly
complex and difficult to read
13-Apr-15
Data Flow Splits and Joins




A data flow split shows where a flow is broken into its
component parts for use in separate processes
Data flow splits need not be mutually exclusive nor use
all the data from the parent flow
As we move to lower levels we become more precise
about the data flows
A data flow join shows where components are merged to
describe a more comprehensive flow
13-Apr-15
Balancing DFD’s

Balancing involves ensuring that
information presented at one level of a
DFD is accurately represented in the next
level DFD.
13-Apr-15
Validating the DFD






Syntax errors
 Assure correct DFD structure
Semantics errors
 Assure accuracy of DFD relative to actual/desired
business processes
User walkthroughs
Role-play processes
Examine lowest level DFDs
Examine names carefully
13-Apr-15
Guidelines for drawing


Use a CASE tool: BPWin, Visible Analyst
Completeness


Consistency



no data flows leading to nowhere
is nesting appropriate?
Timing, never started, never stops
Iterative development
13-Apr-15
Summary

Requirements Structuring



Process modelling
Data flow diagrams
Deliverables


Three sets of DFDs
current physical, current logical, new logical
13-Apr-15