Unit-4

Data Flow Diagram

(Structuring System Process Requirements)
 Process Modeling:
• Process modeling graphically represents the processes that capture, manipulate,
store, and distribute data between a system and its environment and among
system components.
• It utilizes the information gathered during requirements determination. Main
focus is to model the processes and data structures.
• It is a formal way of representing how a business system operates.
• It also illustrates the activities that are performed and how data moves among
them.
• A process model is a formal way of representing how a business operates. It is a
core diagram in structured analysis and design.
• It shows the flow of information through a system.
• Each process transforms inputs into outputs. Process models are based on
behavior and actions. Example: Data flow diagram
 Data Flow Diagram (DFD)
• A DFD is a pictorial representation of the movement of data between external
entities and the processes and data stores within a system.
• It is a common technique for creating process models.
• A DFD shows how data moves through an information system but does not show
program logic or processing steps.
• DFDs can also be used for the visualization of data processing (Structured
Design).
• DFD has often been used due to the following reasons:
• Logical information flow of the system
• Determination of physical system construction requirement.
• Simplicity of notation
• Establishment of manual and automated system requirement
 Data Flow Diagramming Mechanics
Four symbols are used to represent DFDs (See Figure below). Two
different standard sets can be used as proposed by:
• 1. DeMarco and Yourdan
• 2. Gane and Sarson
 Data Flow Diagramming Mechanics
• Process
• A process is the work or actions performed on data so that they are transformed, stored, or
distributed.
• The symbol for a process is a rectangle with rounded corners.
• Inside the rectangle are written both the number of the process and a name, which indicates
what the process does.
• For example, the process may generate paychecks, calculate overtime pay, or compute grade-
point average.
• Data Flow
• A data flow is data that are in motion and moving as a unit from one place in a system to
another.
• A data flow is depicted as an arrow.
• The arrow is labeled with a meaningful name for the data in motion;
• for example, customer order, sales receipt, or paycheck.
 Data Flow Diagramming Mechanics
• Data Store
• A data store is data at rest.
• A data store may represent one of many different physical locations for data, including
a file folder, one or more computer-based file(s), or a notebook.
• The symbol for a data store is a rectangle with the right vertical line missing.
• Its label includes the number of the data store (e.g., D1 or D2) and a meaningful label,
such as student file, transcripts, or roster of classes.
• Source/Sink (External Entities)
• Source/Sink is the origin and/or destination of the data (outside of the system).
• Source/sinks are sometimes referred to as external entities because they are outside
the system and define the system’s boundaries.
• Data must originate outside a system from one or more sources, and the system must
produce information to one or more sinks.
• It is drawn as a square symbol.
• The name states what the external agent is. Because they are external, many
characteristics are not of interest to us.
• A person, organization, or system that is external to the system but interacts with it.
 DFD Diagramming Rules:
Rules for Process:
1. No process can have only outputs. It is making data from nothing (a
miracle). If an object has only outputs, then it must be a source.
2. No process can have only inputs (a black hole). If an object has only
inputs, then it must be a sink.
3. A process has a verb-phrase label.
DFD Diagramming Rules:
 DFD Diagramming Rules:
• Rules for Data Store:
1. Data cannot move directly from one data store to another data store. Data must
be moved by a process.
2. Data cannot move directly from an outside source to a data store. Data must be
moved by a process that receives data from the source and places the data into the
data store.
3. Data cannot move directly to an outside sink from a data store. Data must be
moved by a process.
4. A data store has a noun-phrase label.
DFD Diagramming Rules:
 DFD Diagramming Rules:
• Rules for Source/Sink (External Entities):
1. Data cannot move directly from a source to a sink. They must be moved by a
process if the data are of any concern to our system. Otherwise, the data flow is
not shown on the DFD.
2. A source/sink has a noun-phrase label.
DFD Diagramming Rules:
 DFD Diagramming Rules:
• Rules for Data Flow:
1. A data flow has only one direction of flow between symbols. It may flow in both directions
between a process and a data store to show a read before an update. The latter is usually
indicated, however, by two separate arrows because the read and update usually happen at
different times.
2. A fork in a data flow means that exactly the same data go from a common location to two or
more different processes, data stores, or sources/sinks (it usually indicates different copies of
the same data going to different locations).
3. A join in a data flow means that exactly the same data come from any of two or more
different processes, data stores, or sources/sinks to a common location.
4. A data flow cannot go directly back to the same process it leaves. At least one other process
must handle the data flow, produce some other data flow, and return the original data flow to
the beginning process.
5. A data flow to a data store means update (delete or change).
6. A data flow from a data store means retrieve or use.
7.A data flow has a noun-phrase label. More than one dataflow noun phrase can appear on a
single arrow as long as all of the flows on the same arrow move together as one package.
Rules for Data Flow:
 Summary of the Rules:
Additionally, each data store must have at least one input flow and one output flow
(read & write).
From/To Process Data Store External Entity

Process Ö Ö Ö

Data Store Ö × ×

External Entity Ö × ×
 Functional Decomposition:
• It is an iterative process of breaking a system description down into
finer and finer detail, which creates a set of charts in which one
process on a given chart is explained in greater detail on another
chart.
• Functional decomposition is an act of going from one single system to
many component processes. It is a repetitive procedure.
• Decomposition goes on until you have reached the point where no
sub process can logically be broken down any further.
• The lowest level of DFDs is called a primitive DFD.
 DFD Levels:
 Context Diagram
• Overview of the organizational system
 Level-0 DFD
• Representation of system’s major processes at high level of abstraction
 Level-1 DFD
• Results from decomposition of Level 0 diagram
 Level-n DFD
• Results from decomposition of Level n-1 diagram
 Context Diagram:
• Context diagram shows the system boundaries, external entities that interact
with the system, and major information flows between entities and the system.
• It is the first DFD in every business process.
• It shows the context into which the business process fits.
• It also shows the overall business process as just one process (process 0).
• It shows all the external entities that receive information from or contribute
information to the system.
• Note: Only one process symbol and no data stores are shown in context diagram.
Figure: Context Diagram of Food Ordering System
 Level-0 DFD:
• Level-0 DFD shows the system’s major processes, data flows, and data stores at a
high level of abstraction.
• It shows all the major processes that comprise the overall system – the internal
components of process 0.
• It also shows how the major processes are interrelated by data flows.
• It shows external entities and the major processes with which they interact. It
adds data stores.

• Note: Processes are labeled 1.0, 2.0, etc. These will be decomposed into more
primitive (lower- level) DFDs.
Figure: Level-0 DFD of Food Ordering System
 Level-1 DFD:

• Level-1 DFD shows the sub-processes of one of the processes in the Level-0 DFD.

• Generally, one level 1 diagram is created for every major process on the level 0
diagram.
• It shows all the internal processes that comprise a single process on the level 0
diagram.
• It also shows how information moves from and to each of these processes.

• If a parent process is decomposed into, for example, three child processes, these
three child processes wholly and completely make up the parent process.

• Note: Processes are labeled 1.1, 1.2, 4.1, 4.2, etc. These can be further decomposed
in more primitive (lower-level) DFDs if necessary. Sources and sinks are optional on
level-1 diagrams.
Figure: Level-1 Diagram Showing Decomposition of Process 1.0 from the Level-0 Diagram
Figure: Level-1 Diagram Showing the
Decomposition of Process 4.0 from the Level-0
Diagram
 Level-n DFD:

• Level-n DFD shows the sub-processes of one of the processes in the Level n-1
DFD.
• It shows all processes that comprise a single process on the level 1 diagram.
• It also 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.

• Note: Processes are labeled 4.3.1, 4.3.2, etc. If this is the lowest level of the
hierarchy, it is called a primitive DFD. Sources and sinks are optional on level-n
diagrams.
Figure: Level-2 Diagram Showing the
Decomposition of Process 4.3 from the Level-1
Diagram for Process 4.0
 DFD Balancing:
• When decomposing a DFD, you must conserve inputs to and outputs from a
process at the next level of decomposition. This conservation of inputs and
outputs is called balancing.

Balanced means:
Number of inputs to lower level DFD equals number of inputs to associated
process of higher-level DFD
Number of outputs to lower level DFD equals number of outputs to associated
process of higher-level DFD
DFD Balancing:
Figure: An unbalanced set of data flow diagrams – Figure A:
Context Diagram and Figure B: Level-0 DFD

The figure above is unbalanced because the process of the context diagram
has only one input but the Level-0 diagram has two inputs.
1 input
2 outputs
These are balanced because the numbers of inputs and
outputs of context diagram process equal the number of
inputs and outputs of Level-0 diagram.

1 input
2 outputs
 When to stop decomposing DFDs?
• Ideally, a DFD has at least three processes and no more than seven to nine. Some
other points may be
• When each process has been reduced to a single decision, calculation or database
operation
• When each data store represents data about a single entity
• When the system user does not care to see any more detail
• When every data flow does not need to be split further to show that data are
handled in various ways
• When you believe that you have shown each business form or transaction, online
display and report as a single data flow
• When you believe that there is a separate process for each choice on all lowest-
level menu options
 Logical DFD vs. Physical DFD
• Data flow diagrams are categorized as either logical or physical.
• A logical data flow diagram focuses on the business and how the business operates. It
is not concerned with how the system will be constructed.
• A physical data flow diagram shows how the system will be implemented, including
the hardware, software, files, and people in the system.
• It is developed such that the processes described in the logical data flow diagrams are
implemented correctly to achieve the goal of the business.
• A logical DFD captures the data flows that are necessary for a system to operate. It
describes the processes that are undertaken, the data required and produced by each
process, and the stores needed to hold the data.
• On the other hand, a physical DFD shows how the system is actually implemented,
either at the moment (Current Physical DFD), or how the designer intends it to be in
the future (Required Physical DFD).
• Thus, a Physical DFD may be used to describe the set of data items that appear on
each piece of paper that move around an office, and the fact that a particular set of
pieces of paper are stored together in a filing cabinet
Logical DFD vs. Physical DFD
 Advantages of Logical Data Flow Diagram
• Better communication: A logical diagram is easier to use when communicating with the
users of a system, because it is centered on business activities.
• More stable system: Systems formed using a logical data flow diagram are often more
stable than those that are not because they are based on business events and not on a
particular technology or method of implementation.
• Better understanding of business: A logical data flow diagram has a business emphasis
and helps the analyst to understand the business being studied, to grasp why
procedures are performed, and to determine the expected result of performing a task.
• Flexibility and maintenance: The new system will be more flexible and easier to
maintain if its design is based on a logical model and the business functions are not
subject to frequent change. Physical aspects of the system change more frequently than
do business functions.
• Simple to develop: The logical model is easy to create and simpler to use because it
does not often contain data stores other than files or a database.
• Easy conversion to physical model: Once the logical data flow diagrams are created, the
creation of physical data flow diagrams becomes easy.
 Advantages of Physical Data Flow Diagram
• Clarifying which processes are manual and which are automated: Manual
processes require detailed documentation and automated process require
computer programs to be developed.
• Describing processes in more detail than do logical DFDs: Describes all steps for
processing of data.
• Sequencing processes that have to be done in a particular order: Sequence of
activities that lead to a meaningful result are described. For example, update
must be performed before a producing a summary report.
• Identifying temporary data storage: Temporary storage such as a sales
transaction file for a customer receipt (report) in a grocery store, are described.
• Specifying actual names of files and printouts: Logical data flow diagrams
describes actual filenames and reports, so that the programmers can relate those
with the data dictionary during the developmental phase of the system.
• Adding controls to ensure the processes are done properly: These are conditions
or validations of data that are to be met during input, update, delete, and other
processing of data.
 Advantages of DFDs
• Since they are easily understood by users (i.e. presented in a non-technical format),
they are easier to validate for correctness. It is therefore easy to determine whether
requirements are correct. The probability of a better system is increased.
• It is argued that a picture can convey meaning more quickly than more traditional
methods such as textual narrative.
• DFDs allow the analyst to abstract to whatever level of detail is required so that it is
possible to examine a system in overview and at a more detailed level ,still keeping
sight of the links and interfaces among the different levels.
• It is useful from communicating current system knowledge to the user
• Used as part of the system documentation files
• 5.Data flow diagram helps to substantiate the logic underlining the dataflow of the
organization
• It gives the summary of the system
• DFD is very easy to follow errors and it is also useful for quick reference to the
development team for locating and controlling errors
 Disadvantages of DFDs
• For large systems it can be a time consuming and complex task to produce all
necessary levels of DFDs.
• It can be difficult to read and understand/appreciate what is going on at a first
glance.
• The symbols used are not common to all DFDs. Different models use different
symbols for the structure of a DFD.
• DFD is likely to take many alteration before agreement with the user
• Physical consideration are usually left out
• It is difficult to understand because it ambiguous to the user who have little or no
knowledge.
THANK YOU
 Decision Table
• Decision table is appropriate when large number of conditions are to be checked
to perform a set of action.
• It is divided into 4 parts by horizontal & vertical double line.
• The parts above two horizontal double line contains condition that are being
tested & the outcome of these test.
• The part of two left of vertical double line in the top portion of the table contains
list of the conditions known as Condition stub.
• The part to the right of double line contains list of the answer of these conditions
which are denotes by alphabets.
• The buttom half of which decision table contains the action to be perform.
• The left half is called “Action Stub” which contains action that are to be
performed.
• The right buttom part contains crosses(×) & Dash(-).
• The cross indicate that the action listed in that row has to be performed & dash
indicate that the action is not perform these are called action entry
 Decision tree
• Decision tree is a tree like structure that represents the various conditions and
the subsequent possible actions.
• It also shows the priority in which the conditions are to be tested or addressed.
• Each of its branches stands for any one of the logical alternatives and because of
the branch structure, it is known as a tree.
• The decision sequence starts from the root of the tree that is usually on the left
of the diagram.
• The path to be followed to traverse the branches is decided by the priority of the
conditions and the respectable actions.
• A series of decisions are taken, as the branches are traversed from left to right.
The nodes are the decision junctions.
• After each decision point there are next set of decisions to be considered.
• Therefore at every node of the tree represented conditions are considered to
determine which condition prevails before moving further on the path.
 Decision tree: Example
• Consider for example the discount policy of a saree manufacturer for his
customers. According to the policy the saree manufacturer give discount to his
customers based on the type of customer and size of their order.
• For the individual, only if the order size is 12 or more, the manufacturer gives a
discount of 50% and for less than 12 sarees the discount is 30%. Whereas in case
of shopkeeper or retailers, the discount policy is different.
• If the order is less than 12 then there is 15% discount. For 13 to 48 sarees order,
the discount is 30%, for 49 to 84 sarees 40% and for more than 85 sarees the
discount is 50%.
• The decision policy for discount percentage can be put in the form of a decision
tree displayed in the following figure.
Decision tree: Example
 Pseudocode
• Pseudocode is an artificial and informal language that helps programmers
develop algorithms. Pseudocode is a "text-based" detail (algorithmic) design tool.

• The rules of Pseudocode are reasonably straightforward.

• All statements showing "dependency" are to be indented.
• These include while, do, for, if, switch.
 Some Keywords That Should be Used
• For looping and selection, The keywords that are to be used include
Do While...EndDo; Do Until...Enddo; Case...EndCase; If...Endif; Call ...
with (parameters); Call; Return ....; Return; When; Always use scope
terminators for loops and iteration.
• As verbs, use the words Generate, Compute, Process, etc. Words such
as set, reset, increment, compute, calculate, add, sum, multiply, ...
print, display, input, output, edit, test , etc. with careful indentation
tend to foster desirable pseudocode.
 Examples:
1. If student's grade is greater than or equal to 60
• Print "passed"
• else
• Print "failed“
2. Set total to zero
• Set grade counter to one
• While grade counter is less than or equal to ten
• Input the next grade
• Add the grade into the total
• Set the class average to the total divided by ten
• Print the class average.