International Journal of Operations System and Human Resource Management

Vol. 2, Nos. 1-2, January-December 2012, pp. 69– 77 © International Science Press

ABSTRACTION OF DATA FLOW DIAGRAM FOR A C PROGRAM

Vijaylaxmi Bittal 1, and Manjula Dyavanur2*

Abstract: Data flow diagrams (DFDs) reveal relationships among and between the various
components in a program or system. DFDs are an important technique for modeling a
system’s high-level detail by showing how input data is transformed to output results
through a sequence of functional transformations. DFDs consist of four major
components: entities, processes, data stores, and data flows. The symbols used to depict
how these components interact in a system are simple and easy to understand; however,
there are several DFD models to work from, each having its own symbology. In this
paper we have given steps for abstraction of data flow diagram for a ‘C’ program by
taking student record as a case study.
Keywords: DFD, Abstraction, Context diagram, OMT.

1. INTRODUCTION
Data flow diagrams have[1] replaced flowcharts and pseudo code as the tool of choice for showing
program design. A DFD illustrates those functions that must be performed in a program as well as the
data that the functions will need. A DFD is illustrated in Figure 1

Figure 1: Example

1
DAssistant Professor, Department Of Computer Science, SKSVMACET, Laxmeshwar-582116,Dist-Gadag
2*
Corresponding Author Lecturer, Department Of Computer Science, SKSVMACET, Laxmeshwar-582116,
Dist-Gadag,
70 International Journal of Operations System and Human Resource Management

1.1. Defining DFD Components

DFDs [2] consist of four basic components that illustrate how data flows in a system: entity, process,
data store, and data flow.
Entity
An entity is the source or destination of data. The source in a DFD represents these entities that are
outside the context of the system. Entities either provide data to the system (referred to as a source)
or receive data from it (referred to as a sink). Entities are often represented as rectangles (a diagonal
line across the right-hand corner means that this entity is represented somewhere else in the DFD).
Entities are also referred to as agents, terminators, or source/sink.
Process
The process is the manipulation or work that transforms data, performing computations, making
decisions (logic flow), or directing data flows based on business rules. In other words, a process
receives input and generates some output. Process names (simple verbs and dataflow names, such as
“Submit Payment” or “Get Invoice”) usually describe the transformation, which can be performed
by people or machines. Processes can be drawn as circles or a segmented rectangle on a DFD, and
include a process name and process number.
Data Store
A data store is where a process stores data between processes for later retrieval by that same process
or another one. Files and tables are considered data stores. Data store names (plural) are simple but
meaningful, such as “customers”, “orders”, and “products”. Data stores are usually drawn as a rectangle
with the right hand side missing and labeled by the name of the data storage area it represents,
though different notations do exist.
Data Flow
Data flow is the movement of data between the entity, the process, and the data store. Data flow
portrays the interface between the components of the DFD. The flow of data in a DFD is named to
reflect the nature of the data used (these names should also be unique within a specific DFD). Data
flow is represented by an arrow, where the arrow is annotated with the data name.
These DFD components are illustrated in Figure 2

Figure 2: DFD Components

Abstraction of Data Flow Diagram for a C Program 71

2. PROCESS OF DEVELOPING DFD’S

Data flow diagrams can be expressed as a series of levels. We begin by making a list of business
activities to determine the DFD elements (external entities, data flows, processes, and data stores).
Next, a contextdiagram is constructed that shows only a single process (representing the entire
system), and associated external entities. The Diagram-0, or Level 0 diagram, is next, which reveals
general processes and data stores. Following the drawing of Level 0 diagrams, child diagrams will be
drawn (Level 1 diagrams) for each process illustrated by Level 0 diagrams.

2.1. Steps for Abstraction of a Data Flow Diagram for a C Program

1. Read the input.
2. Determine the data items.
[ which are usually located in documents (but not always).]
3. Determine where they come from and where they go. Construct a table to organize your
information, as shown in Table 1
Table 1
Source and Destination for Data Items

Data Item Source Destination

Need Account Project
Analysis Executive Manager
ROI Study Presales Proposal
Support Manager

4. Determine the system boundaries

[In this determining which entities belong internal to the system and which ones are external to
the system]
5. All components within the system boundary are included within a single system/process box in
the DFD. [External entities lie outside the system boundary, internal entities lie outside the
system boundary and internal entities will become locations for process]
6. Next check for a data flow, if there is a flow from external entity to process within a system
boundary, make a data flow with a solid line.(in either direction)
7. OR if a data flow from process to data store (in either direction) make a dataflow with solid line
between process to data store.
8. OR if a data flow is from process to process means that can only run simultaneously then make
a data flow from process to process.
9. Before terminating if you want to express DFD in series of levels // level1 DFD Yes go for step
10, else go to step 15.
10. Identifies the major process and data stores.
72 International Journal of Operations System and Human Resource Management

11. Identify or list each incoming and outgoing data flow with a corresponding process that receives
generates data.
12. Make sure you refer to your data item table for any missing internal data flows and to identify
data stores. [If your table contains documents with the same source and destination, so select
only one flow]
13. Identify these processes that only address internal output and outputs and use one process for
each source or destination from the DFD.
14. Revising the Level 1 DFD.
(a) Check that level1 processes correspond with the major functions.
(b) Check level of detail balanced across the DFD.
(c) Check that it is possible to merge some processes.
(d) Check that it is possible to remove data stores not shared by more than one processes.
(e) Check that it is avoided crossed data flow lines making use of duplicated components
[ external entities and data stores] or not.
15. Terminate.

2.2. Case Study

C program to create a sequential file with atleast 5 records each record having following structure. (Table 2)
Table 2
Student Record

USN Name Marks 1 Marks 2 Marks 3

+ ve integer 25 character + ve integer + ve integer +ve integer

#include<stdio.h>
#include<process.h>
#include<string.h>
typedef struct
{ int usn;
char name[20];
int marks1; int marks2; int marks3;
}STUDENT;
void main()
{
STUDENT st;
char fname[10];
FILE *fp;
Abstraction of Data Flow Diagram for a C Program 73

int key_usn;
int flag;
int choice;
printf(“enter the file name\n”);
scanf(“%s”,fname);
for(;;)
{
printf(“1:insert Record 2: Search record 3: Display record 4: Quit\n”);
scanf(“%d”,&choice);
switch(choice)
{
case 1: fp=fopen(fname,“a+”);
if(fp==NULL)
{
printf(“Fopen failed\n”); break;
} Append_record();
fclose(fp); break;
case 2:fp= fopen(fname,“r”);
if(fp==NULL)
{
printf(“File open failed\n”); break;
}
printf(“Enter USN:”);
scanf(“%d”,&key_usn);
flag=search_record(key_usn, fp);
if(flag==0)
printf(“unsuccessfull search\n”); else
printf(“successful search\n”); fclose(fp);
break;
case 3:fp=fopen(fname,“r”);
if(fp==NULL)
{
printf(“File opened failed\n”);
break;
}
74 International Journal of Operations System and Human Resource Management

display_records(fp);
fclose(fp);
break;
default: exit(0);
}
}
int search_record(int key_usn, FILE *fp)
{
STUDENT st;
for(;;)
{
fscanf(fp,“%d,%s,%d,%d,%d”,&st.usn,st.name,&st.marks 1,&st.marks2,&st.marks3); if((feof(fp))
break;
if(key_usn==st.usn)
return 1;
}
return 0;
}
void append_record(FILE *fp)
{
STUDENT at;
printf (“USN:”);
scanf(“%d”,&st.usn);
printf(“name”);
scanf(“%d”,&st.usn);
printf(“marks1:”);
scanf(“%d”, &st.marks1);
printf(“marks2”);
scanf(“%d”,&st.marks2);
printf(“marks3”);
scanf(“%d”,&st.marks3);
fprintf(fp,“%d,%s,%d,%d,%d”,&st.usn,st.name,&st.marks1 ,&st.marks2,&st.marks3);
}
void display_records(FILE *fp)
{
Abstraction of Data Flow Diagram for a C Program 75

STUDENT st;
printf(“USN NAME MARKS1 MARKS2 MARKS 3”);
for(;;)
{ fscanf(fp,“%d,%s,%d,%d,%d”,&st.usn,st.name,&st.marks1 ,&st.marks2,&st.marks3);
if(feof(fp))
break;
printf(“%d,%s,%d,%d,%d”,st.usn,st.name,st.marks1,st.mar ks2,st.marks3);
}}

2.1.1. Now Apply Steps to the Above Case Study

1. Read the input.
2. Determining data items. In this program data items are mainly the user and program for sequential
file.
3. Determine where they come and where they go. Here user is an external entity and sequential
program is a process.
4. Determining system boundaries. ( as shown in Figure 3)

Figure 3: Determining System Boundaries

5. This program contain 3 more processes but they are kept in a single process box that is sequential
program box [Developing level0 DFD]
6. There is a flow from user to a sequential program process will take a flow between in either
direction.
9. Suppose we want to represent DFD in series of levels,then goto step 10.
10. Identify a major process and data items.
Major process - Sequential program
Sequential program - append_record(process)
- display_records(process)
- search_record(process)
- student_record( data store)
76 International Journal of Operations System and Human Resource Management

11. Listing incoming and outgoing data flow.

Table 3
Incoming and Outgoing Data Flow

Source Destination
User append_record
append_record student_record
user display_record
student-record display_record
user serach_record
student-record serch_record

12. Make sure that we referring to these data item table for any missing internal data flows and to
identify data store.
13. The processes
→ append_record
→ display_record
→ search_record
The generated DFD for above steps is shown in Figure 4.

Figure 4: Level 1 DFD

14. Apply the revising steps for level1 DFD.

15. Terminate.
Abstraction of Data Flow Diagram for a C Program 77

3. STEPS IN OBJECT ORIENTED ANALYSIS

The first step in OOA is often the identification of important classes, which is done by identifying
the nouns in the requirement specification. Many times, classes are defined from tangible things,
roles, or incidents. Analysis also includes defining object attributes and object and class or other
relationships. Analysis also attempts to identify the behavior of objects and classes as well as data
flow between objects.

3.1. OMT Modeling

The output of OMT is a three-dimensional view (from three different models) of the system that stays
the same during the transition from analysis to design.
The Object Model describes the static system components and is modeled using object diagrams.
The Dynamic Model describes the dynamic system components that change over time and are
modeled using state diagrams. The Functional Model describes operations performed on data in a
system and uses data flow diagrams.

4. CONCLUSION
Data flow diagramming is a highly effective technique for showing the flow of information through
a system. DFDs are used in the preliminary stages of systems analysis to help understand the current
system and to represent a required system. We have given steps for abstraction of DFD for ‘C’
program, verified these steps for case study and also given brief steps for object oriented analysis.
DFDs are extremely useful in systems analysis as they help structure the steps in object-oriented
design and analysis. Because DFDs and object technology share the same syntax constructs, DFDs
are appropriate for the OO domain only.

REFERENCES
[1] Perry, Greg. Sams Teach Yourself Beginning Programming in 24 Hours, Sams Publishing, 1998.
[2] Le Vie, Jr., Donald, “An eCommerce Primer for Technical Communicators”, STC Proceedings of
the 47th Annual Conference, 2000. Donald.