Software Development Life

Cycle

Chapter 5. Process Modeling

5-1
Chapter 5 Outline

Data flow diagrams.

- Reading data flow diagrams
- Elements of data flow diagrams
- Using data flow diagrams to define business
processes
- Process descriptions
Creating data flow diagrams.
5-2
INTRODUCTION

 A process model can be used to further clarify the

requirements definition and use cases.
 A process model is a graphical way of representing how a
business system should operate.
 A process model can be used to document the as-is system or
the to-be system, whether computerized or not.

5-3
(cont’d)

 Data flow diagramming is a technique that

diagrams the business processes and the
data that pass among them.
 Logical process models describe processes
without suggesting how they are conducted.
 Physical process models provide information
that is needed to build the system.

5-4
DATA FLOW DIAGRAMS (DFDs)

Reading Data Flow Diagrams

5-5
Elements of Data Flow Diagrams

 Process – A process is an activity or a function

performed for some specific business reason.
 Data Flow – A data flow is a single piece of data, or a
logical collection of several pieces of information.
 Data Store – A data store is a collection of data that is
stored in some way.
 External Entity – An external entity is a person,
organization, organization unit, or system that is
external to the system, but interacts with it.

5-6
(cont’d)

5-7
Using DFDs to Define Business Processes

 Business processes are too complex to be explained in one DFD.

 One important principle in process modeling with DFDs is the
decomposition of the business process into a series of DFDs,
each representing a lower level of detail.

5-8
(cont’d)

Decomposition

5-9
Context Diagram

 The first DFD in every business process is the context diagram.

 It shows the entire system in context with its environment.
 The context diagram shows the overall business process as just
one process and shows the data flows to and from external
entities.

5-10
Level 0 Diagram

The level 0 diagram (or level 0 DFD) shows all the major high-
level processes of the system and how they are interrelated.
The Level 0 diagram shows all the processes at the first level
the numbering, the data stores, external entities, and data
flows among them.
A key concept: Balancing
- Ensuring that all information presented in a DFD at one
level is accurately represented in the next-level DFD.
A process model has one and only one level 0 DFD.

5-11
Level 1 Diagrams

 Each process on the level 0 DFD can be

decomposed into a more explicit DFD called
level 1 diagram (or level 1 DFD).
 The set of children and the parent are
identical; they are simply different ways of
looking at the same thing.
 It is important to ensure that level 0 and level
1 DFDs are balanced.

5-12
(cont’d)

 All process models have as many level 1 diagrams as there are

processes on the level 0 diagram.
 The parent process and the children processes are numbered
consistently.

5-13
Level 2 Diagrams

 The next level of decomposition: a level 2 diagram, or level 2

DFD.
 A level 2 DFD shows all processes, data flows, and data stores
that comprise a single process on the level 1 diagram.
 It is important to ensure that level 1 and level 2 DFDs are
balanced.

5-14
Alternative Data Flows

 A process can produce different data flows under different

circumstance.
 We show both data flows and use the process description to
explain why they are alternatives.

5-15
Process Descriptions

 The purpose of the process descriptions is to

explain what the process does and provide
additional information that the DFD does not
provide.
 Three techniques are commonly used to describe
more complex processing logic:
 Structured English
 Decision trees
 Decision tables

5-16
CREATING DATA FLOW DIAGRAMS

 DFDs start with the information in the use cases and the
requirements definition.
 Generally, the set of DFDs integrates the individual use cases.
 The project team takes the use cases and rewrites them as
DFDs, following the DFD formal rules about symbols and syntax.
 CASE tools are used to draw process models.

5-17
(cont’d)

Example of the use of CASE Tools

5-18
(cont’d)

1. Build the context diagram.

2. Create DFD fragments for each use case.
3. Organize the DFD fragments into level 0 diagram.
4. Develop level 1 DFDs based on the steps with
each use case. In some cases, these level 1 DFDs
are further decomposed into level 2 DFDs, level 3
DFDs., and so son.
5. Validate the set of DFDs to make sure that they
are complete and correct. 5-19
Creating the Context Diagram

 The context diagram defines how the business process or

computer system interacts with its environment.
 Draw one process symbol for the business process or
system being modeled (numbered 0 and named for the
process or system).
 Add all inputs and outputs listed on the form of the use
cases as data flows.
 Draw in external entities as the source or destination of
the data flows.
 No data stores are included in the context diagram.

5-20
(cont’d)

Example of Context Diagram

5-21
Creating DFD Fragments

A DFD fragment is one part of a DFD that eventually will

be combined with other DFD fragments to form a DFD.
Each use case is converted into one DFD fragment using
the information given on the form of the use case: the
name, the ID number, and major inputs and outputs.
The information about the major steps that make up
each use case is ignored at this point; it will be used in a
later step.

5-22
(cont’d)

Example of Fragment

5-23
(cont’d)

Additional Example of Fragment

5-24
(cont’d)

Additional Example of Fragment

5-25
(cont’d)

Important changes are often made in converting the use case

into a DFD:
- modifications to the process names
- the addition of data flows.
Make sure that any information given to the user is obtained
from a data store.
There are not formal rules covering the layouts; typically
place the processes in the middle
inputs start from the left or top
outputs leave from the right or the bottom
place data stores below the processes

5-26
Creating the Level 0 Diagram

 Combine the set of DFD fragments into one

diagram – the level 0 DFD.
 There are not formal layout rules. Generally,
- to put the process that is first chronologically in
the upper-left corner and work the way from top
to bottom, left to right;
- to reduce the number of crossed data flow lines.
 Iteration is the cornerstone of good DFD design.
5-27
(cont’d)

Example of Level 0 DFD

5-28
Creating Level 1 Data Flow Diagrams (and
Below)
Level 1 DFD – lower-level DFDs for each process in the
level 0 DFD.
Each one of the use cases is turned into its own DFD
Each major step in the use case becomes a process on
the level 1 DFD, with the inputs and outputs becoming
the input and output data flows.
Level 1 DFDs include the sources and destinations of
data flows for data stores and data flows to processes.
Including external entities in level 1 and lower DFDs can
simplify the readability of DFDs. 5-29
(cont’d)

There is no simple answer to the “ideal” level of decomposition,

because it depends on the complexity of the system or business
process being modeled.
In general, you decompose a process into a lower-level DFD whenever
the process is sufficiently complex that additional decomposition can
help explain the process.
Rules of thumb:
- There should be at least 3, and no more than 7-9, processes on every
DFD.
- Decompose until you can provide a detailed description of the process in
no more than 1 page of process descriptions.

5-30
(cont’d)

Example of Level 1 DFD (for P3)

5-31
(cont’d)

Example of Level 1 DFD (for P4)

5-32
(cont’d)

Example of Level 2 DFD (for P4.3)

5-33
(cont’d)

Example of Level 1 DFD (for P5)

5-34
Validating the DFD

Checklist of Common Errors in DFDs

5-35
Validating the DFD (cont’d)

 There two fundamental types of errors in DFDs:

1. Syntax errors – can be thought of as grammatical errors that
violate the rules of the DFD language.
2. Semantics errors – can be thought of as misunderstandings by
the analyst in collecting, analyzing, and reporting information
about the system.

5-36
(cont’d)

 Syntax errors are easier to find and fix than are semantics
errors because there are clear rules that can be used to identify
them.
 Most CASE tools have syntax checkers that will detect syntax
errors.

5-37
(cont’d)

Common
Syntax
Errors

5-38
(cont’d)

 Semantics errors cause the most problems in

system development.
 Three useful checks to help ensure that models are
semantically correct:
1. to ensure that the model is an appropriate
representation by asking the users to validate the
model in a walk-through
2. to ensure consistent decomposition
3. to ensure that the terminology is consistent
throughout the model 5-39
SUMMARY

Data Flow Diagram Syntax – four symbols are used on data flow
diagrams (processes, data flows, data stores, and external entities).
Creating Data Flow Diagrams
- The DFDs are created from use cases.
- Every set of DFDs starts with a context diagram.
- DFDs segments are created for each use case, and are then
organized into a level 0 DFD.
- Level 1 DFDs are developed on the basis of the steps within each
use case.
- The set of DFDs are validated to make sure that they are complete
and correct and contain no syntax or semantics errors.
5-40