PROGRAMMING LOGIC AND TECHNIQUES

PROGRAM MAINTENANCE
1. INTRODUCTION:
User requirements from a specific program do not remain static. They change frequently in response to such
factors as new laws, new ideas, new products, or new computer facilities. Program maintenance covers a wide
range of activities including correcting coding and design errors, updating documentation and test data, and
upgrading user’s support. In other words, maintenance may be viewed as enhancement i.e. adding, modifying, or
developing the code to support changes in the specifications. The term program maintenance or software
maintenance is commonly used to refer to the modifications that are made to a program system after initial
release. It is the technique of updating, alteration or correction of applications of the system. It is an important
activity of program development which takes significant part of the resources of a computer data processing
organization. It is used to be viewed as merely bugs fixing and defects fixing. It is the process of incorporating
changes in an existing system to enhance, update or upgrade its features. It is an important phase in program
development life cycle. Usually, the total cost of maintenance phase is much higher than the development cost of
the software. Normally the maintenance-to-development cost ratio is suggested as 80:20, 70:30, and 60:40.

Sometimes, it can be defined as the implementation process which contains programming system preparation
and transition activities, such as the conception and creation of the maintenance plan, the preparation for
handling problems identified during development, and the follow-up on product configuration management.
Today, it is used with cover a wide range of activities, all having to do with modification to every stage which
required in order making an implement. Every program system will need to be maintenance eventually due to the
some reasons which described below.

Why Program Maintenance?

Although software does not wear out like a piece of hardware, it "ages" and needs to be updated for the following
reasons:
 Errors are found that were not detected when the system was tested initially. Even though the system was
thoroughly tested, errors or bugs often appear after the system has been in use for some time.
 A new function may have to be added to the system. For example, the school management had initially asked
for the preparation of monthly report of those students who had not paid their fee in time. But at a later date,
the auditors or the principal of the school needs a report of those students who are defaulters in paying their
fee for more than three months so that their names can be struck from the school. In such a case, the report
format will need a change.
 Alteration in the original program may cause errors elsewhere in the program and detected later. This will
require modifications in the program.
 The requirements of the user change with time. For example, programs that produce income tax returns have
to be modified almost every year because of changing tax laws.
Summarized reasons:
 Changes in business conditions or operations of the organization using the program system.
 Changes in organizational policies or enforce new laws.
 Changes in user needs, demands for additional features.
 Changes in technology and advance system.

2. PROBLEMS IN PROGRAM MAINTENANCE:

Every program or software requires implementation and maintenance because the users’ requirements and
needs can be changed and according to change of requirements there to be maintained the program package also.
The modification, updating or up gradation of the program mostly done for the confirmation with the user
requirements and demands. But this is also can be seen that the data processing professionals do not get
intellectual satisfaction from their program up gradation in the earlier version or model. The professionals are
always looking to develop new program system using the latest packages and techniques place of maintenance of
old version of the program. This attitude of the program developers are conflict with the user’s interest with the
system, briefness for the system, view and improvement who finds better and more convenient In order
program with upgrade version with the new requirements and more flexible ,maintained system.
Some problems (Area) of the software maintenance:
 Programs are sometimes can be large and complex structured, they can be difficult to change.
 Most of the programmers or developers not interests to maintain the earlier version, they always wants to
work in new Environment so in this situation maintenance met very low.
 Very high cost of maintenance of the program maintenance than the program development.
1
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com
 PROGRAMMING LOGIC AND TECHNIQUES

So, overcome the problem of the maintenance problems of the program or software ,the developer or
programmer should adopt the good corporate policy that accept only those programs and products which are
easy to modify, upgrade ,and handle.

Explanations of two problem areas in program maintenance are:

1. High Cost of Software
Major problem with software maintenance is that the program writing is labour intensive in nature. Human
beings who write programs are likely to make errors. For example the programmer who was originally assigned
the task of solving and coding the
program may not be available to modify this program at a later date. Therefore, the new person who is given the
job of modification will have to study and understand the logic of the original program and then only he can
modify the program. This process may involve more time, money, and there are more chances of making errors.
In such cases, it may be easier and economical to rewrite a new program rather than amending the old one.
2. Errors Caused due to Modification in the Original Program
Alteration in the original program, no matter how slight, must be manually introduced. There is no easy way of
making sure that the modifications made will not cause any errors elsewhere in any of the subprograms or the
main program. Using the old codes depend mostly on the programmer’s ability to judge what the code can and
cannot do. Hence the program is to be thoroughly tested after modification before implementation.

3. COST ISSUES IN PROGRAM MAINTENANCE:

The cost issue about the software or program depends on the productivity of the programmers according to their
quality and quantity. The cost of the programmer’s product can be low according to the quality and structure of
the program. But mostly programmer’s product cost is high. The cost of the programmer’s product risen this is
not due to the shortage of skilled professionals but this is because of low interest of the programmers and low
numbers of the productivity of the programmer. The need for good quality programs better than other things but
there is also need to reduce the programming labour cost. When we compare the every part of program
development then we can get the result that the maintenance of the program exceed cost 60% of the total
development costs of the program. To analyse factors that affect such costs, maintenance of software is divided
into some categories which are explained below:
1. Correlative Maintenance:
It has to do with the removal residual errors that are present in the product when it is delivered and errors
introduced into the software during its maintenance. It is accounts for about 20% of maintenance costs.
2. Adaptive Maintenance:
This involves adjusting the product to change in the environment .It involves modifying the system with the new
environment according the demand. For instance, a new release of the hardware or the operating system or new
database system. It accounts for about 20% of the maintenance.
3. Perfective Maintenance:
It involves changing the software to improve some of its quantities. Perfective maintenance refers to changes that
originate from user requests; examples include inserting, deleting, extending, and modifying functions, rewriting
documentation, improving performances, or improving ease of use. Here, changes are due to need to modify the
functions, operations by the applications, add new functions, improve the performance of the applications make
easier to user etc. The request to perform perfective maintenance may come directly from the developer, in order
to improve the status of stats of product on the market or they make come from the customer to meet some new
requirements. It accounts for about more than 50% maintenance cost.
4. Emergency maintenance:
“Unscheduled corrective maintenance performed to keep a system operational.” According to Institute of
Electrical and Electronic Engineers (IEEE), Lientz and Swanson redefines the categories of Software
maintenance as corrective, adaptive, and perfective maintenance, and adds emergency maintenance as a fourth
category. In this system the operation solutions can be maintained.

4. DOCUMENTATION:
Documentation is the process of collecting and storing the overall activities and operations of the program or
software development which performed in every stages of the development. It is a complete record of every
aspects of the program or project development. That may be requirement analysis or data and task analysis or
reason for the program development. That may be about the functions, procedure, subroutines, algorithms,
pseudo code, flowcharts or other techniques which used for the program design and development. This is the
process of collecting, organising, storing and maintaining a complete historical record of program and other
documents used and prepared during the program or software development stage. Documentation is never
2
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com
 PROGRAMMING LOGIC AND TECHNIQUES
ending process throughout the life of the software. It has to be carried out from tome-to-time whenever the
software is modified during its maintenance phase.

Good documentation called that type of documentation where every stages of the development with problems
and their solution explained clearly and briefly. Good documentation implies that each aspect of the
documentation particularly explained with comments and remarks for the analysis, design, objects, procedures,
algorithm and other techniques and topics used in the development process. The most three forms that
commonly used for documentation are program comments or remarks, system manual and user manual.

Benefits of the Good documentation:

“Good documentation acts like a beacon, lighting the way for your users”
1. Unlocks your product’s power: Well-written instructions unlock the potential of your product by explaining
how to make full effective use of its outstanding features. Many hi-tech products contain superb features that
most users never use because they cannot figure out how to use them; often they don't know they even exist.
2. Add value to your product: Good documentation is an essential part of the complete package, not an
afterthought or last-minute addition. You designed your product with high design values and attention to detail –
now apply the same standards to your documentation.
3. Helps to sell more products: Good documentation increases customer loyalty and ensures that they will buy
your other products in the future. It can also be a great selling tool for prospective customers because it gives
them a clear idea of how they might use your product, and what they could achieve with it.
4. Reduce time spent supporting your product: Quality user information is the most cost-effective way of
answering the questions that your customers will encounter when using your product; otherwise they’ll call you
for the answer, a far more expensive solution.
5. Build confidence in your quality: Customers will often subconsciously judge the quality of your product by
the guides provided with it because they determine the first impressions. With well-designed, accurate
supporting information the customer will deduce that the product was designed and produced to the same high
standards.
6. Deliver on the promise: Are you currently carrying through the expectations created by your sales literature
and advertising? Good documentation enables your customers to achieve the results that your advertising
promised.

Documentation Standard:
The importance of software documentation has been well established by now. There have been too many
problems in the past with poorly documented software. Elimination of errors and incorporation of modifications
are usually very difficult in such software, making them very expensive to maintain. Realizing the importance of
software documentation, several computer organizations have developed strict documentation standards. These
standards describe in detail how documentation is to be done. Documentation standards are basic of document
quality assurance. Standards are designed to over all cases and sometimes seen unnecessary restrictive. It is
therefore important that for each project, the appropriate standards are chosen and modified to suit that
particular project. Small projects developing system with a relatively sort and large softwares project were the
software may have to be maintain for more times. It Document produced according to appropriate have a
constant appearance, structure and quality. The standards used in documentation process are following listed:
1. Process standard: Process standards define the approach to be taken in producing document these generally
means defining the softwares tools which should be used for document production and defining the quality
providing procedures which ensures that high quality documents are produced. Document process quality
standards should be flexible and most be able to adjust with all types of document.
2. Product standard: Product standards apply to all document produced in the course of software
development. Document should have a consistent appearance and, documents of the some class should have a
consistent structure. Document standards are project specific but should be based on more general
organization standards.
3. Interchange standard: Document interchange standards are important as more and more documents are
produced in electronic formats as well as or instead of paper on for documentation. That is delivered with a
software system Adobe portable document format (PDF) is now very commonly used. However, when
document are exchanged by the development team and when it is circulated within an organisation, these are
often in the format of whatever words processor user.

Documentation and its Importance:

Documentation provides a general outline as well a few specific details of the overall program structure. The
documentation of a program is a continuous process. After successfully completing the program, we must ensure
3
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com
 PROGRAMMING LOGIC AND TECHNIQUES
that documentation is complete and is in a finished, usable form. This includes both technical documentation for
the programmers who may be working with and modifying the completed program and user-level documentation
for the users of the program. Good user documentation is essential if a program is to be a useful tool. Good
technical documentation is essential for maintaining a program. We may decide at a future date to add features to
the program, or we may have to find and correct errors in the program, both of which can be virtually impossible
if the technical documentation is inadequate.

Types of Documentation:
1. Requirements Documentation
2. Architecture/Design Documentation
3. Technical Documentation
4. End User Documentation
5. Marketing Documentation

Requirements Documentation:
 Requirements documentation is the description of what particular software does or shall do.
 It is also used as an agreement or as the foundation for agreement on what the software shall do.
 It consists of statements that identify attributes, capabilities, characteristics, or qualities of a system.
 This is the foundation for what shall be or has been implemented.
Architecture/Design Documentation:
 Architecture documentation is a special breed of design document.
 A good architecture document is short on details but thick on explanation.
 It focuses on one specific aspect of the system and suggests alternate approaches.
 It could be at the user interface, code, design, or even architectural level.
Technical documentation:
 Technical documentation has become important within such organizations as the basic and advanced level of
information may change over a period of time with architecture changes.
 This documentation may be used by developers, testers and also the end customers or clients using this
software application.
 It consists of documentation of code, algorithms, interfaces, and APIs.
 Technical documentation is used by the programmers who may be working with and modifying the completed
program
End User Documentation:
 End User Documentations are usually far more diverse with respect to the source code of the program, and
instead simply describe how it is used.
 The user documentation describes each feature of the program, and assists the user in realizing these
features.
 There are three broad ways in which user documentation can be organized: Tutorial, Thematic and Reference.
 It is used by the users of the program.
Marketing Documentation:
 Marketing Documentation is used to provide clear and memorable catch phrases that exemplify the point we
wish to convey.
 It emphasizes the interoperability of the program with anything else provided by the manufacturer.

Requirements of Documentation:
The documentation of any program has various aspects and requirements, some of these are described
below:
1. Definitions of the program: This topic contains of acknowledgement of the program, reason for the program
development, dedication of the program and approval of the program, Scope of the system.
2. Description of the System: This factor consists of detail of the system or sub system environment
description with the used functions in that system and remarks and comments about the system. It describes
clearly form and type of input data to be used and the form and type of output required.
3. Description of the system design: this factor consists of description of all the design structure, used
techniques and tools such as algorithms, flowcharts, pseudo codes, decision tables etc.
4. Description of Operating instructions: This document gives the details to the computer operator of how to
run the program. It may include:
 Details of the procedure for starting the program.
 Details of disks and tapes required.
 Special stationery to be used.
4
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com
 PROGRAMMING LOGIC AND TECHNIQUES
 The number of copies of each report, and who is to receive the output.
 Backup procedures to be followed.
 Recovery procedures in the event of hardware failure.

5. Description of program controls: this document contains the description of the control structure of the
program .for example the document describes the programmed controls may be used to check on the
reasonableness and property of input data and so on.

5. IMPACT OF SOFTWARE ERRORS:

The quality of a software system depends on its design, development, testing, and implementation. An important
aspect of software quality is its reliability. A program is reliable if, when used in a reasonable manner, it does not
produce failures that are dangerous or costly. Software errors can cause failure of the system or produce
inaccurate results. Programmers should therefore strive to design error free programmes. The software errors
are mainly due to design errors or specifications. Hence these are also to be rechecked before studying the impact
caused by the errors. It is more difficult to debug a large program because the errors can affect the result in many
ways. More ever correcting an error in one part of a large program can create problems. A large program can be
90%debugged at a certain time but than at some later time, it might end up being only 80%debugged because
coding errors so much harder to uncovered in the later parts of the development process. The programmers
should exercise extreme care when they are establishing the requirement and designing the solution. It is noticed
that cost nearly two times as much to find and correct a particular error in the operation at phase as it does to
find it during the initial phase when the overall requirements are being set. The above figure clears about the fact
the developers have to work carefully and slowly in the every phases of the development process in order to
avoid mistakes that may turn out to be extremely expensive to correct.
The Problem of Software Modification:
The basic problems of modifying software can be attributed to time schedule and the user-need satisfaction.
These are as follows:
Time schedule
Modification of a program may not be feasible within the time schedule because of several reasons. The reasons
may be non availability of the right kind of manpower, improper documentation of the old program or testing
data. For such cases, the earlier version of the software will have to be used till all the errors are removed in the
newer version after it has been tested thoroughly.
User-need Satisfaction
People who are using the program are the final evaluators of the modification. Hence it should be found out
whether these users are now satisfied with the new version of the software or not. Further how useful is the new
software for them? How enthusiastic are they about the friendliness and ease of working with the new software?
Answers to all these questions are to be evaluated and implemented.

6. PROGRAM SPECIFICATION:
Specification is a process of detailed description of different tools and techniqaues and features of the whole
program. It is a precise statement of the requirements of the system. A program specification is a list of
requirements written for a computer program. The program specification is written before a computer scientist
or program developer makes the program. Then, after the computer scientist makes the program, she must check
that the program agrees with the requirements in the specification. It is a statement of the precise functions
which are to be carried out by a computer program, including descriptions of the input to be processed by the
program, the processing needed, and the output from the program. It is an activity a critical part of the whole
design process. Specifications themselves are the result of a complex and creative design activity. We can view
specification as the statement of an agreement between a producer of a system and the user of a system or
between an implementer and the consumer. Specification states what a system should do, the developer or
implementer decides how to do it. The developer or programmer must specify about the system requirements
and the subsystems and the components that will be used to make up the system.

A specification is a technical contract between a programmer and his/her user or client and is intended to provide
them with a mutual understanding of a program. A user uses the specification to guide his/her use of the
program;a programmer uses the specification to guide his/her construction of the program. A complex
specification may engender sub specifications, each describing a sub component of the program. The construction
of these sub components may then be delegated to other programmers so that a programmer at one level
becomes also a client at another. Experience shows that it is extremely challenging to create high quality software.
A clearly understandable specification is a vital ingredient in the creation process. However, the program is
available only at the conclusion of the programmer user interaction, and cannot be a factor in developing a
5
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com
 PROGRAMMING LOGIC AND TECHNIQUES
suitable initial contract. And even when it is completed, the plethora of details in programs overwhelms a clear
understanding and disqualifies the program from serving the purposes of a specification.

The purpose of a specification requires that all users have complete confidence in the properties of the results it
warrants. The focus of a specification should be on what is achieved using this program. Precise and formally
defined conventions for writing specifications are a much more recent invention than programming languages.
Since a specification provides a technical contract, it is only natural to base both the construction and the
verification of a program on its specification.
The uses of Specification:
 A statement of user requirements.
 Statement of interface between the machine and the controlled environment.
 A statement of the requirements for the implementation.
 a reference point during product maintenance.

Features of Program Specification:

 Conceptual elements for the development of precise specifications that can serve to guide programming
activity.
 The means to utilize a formal specification for a rigorous verification of the program when it is completed.
 The integration of these ideas into a "system of specification" that can be supported by computer-based tools
that assist the entire enterprise. It is this view that guides our course.

Classification of Specification Styles:

Specification can be stated formally or informally. Informal specifications are written in a natural language they
can however also make use of figures, tables and other notations to provide more structure. It helps the
understanding specification style can be operational or descriptive specification. Operational specification is
describing the intended system by explaining. It described behaviour using diagram or charts. Descriptive
specification tries to state desired properties of the system in brief.

System Flowchart:
System flowchart is the diagrammatically representation of an event of a system or part of the system for clearly
specification the current system. The system flow chart mostly shows three elements: The program, The Data and
Interaction between program and data. This can be defined as the programming process description chart which
can shows the decision that lead to different actions taken for the program .To draw a system flow chart firstly,
we should identify the main components or functions with main system and sub components and functions of the
system then we can properly maintain the system.
Example1:

Example 2:

DATA FLOW DIAGRAM:

Data Flow Diagram is a graphical representation of flow of data through any information. DFD is the technique
which provides overview of what data flows in a system, what transformations are done on the data, what files
are used and where results flow by the program. It is a process oriented graphical method to re-present an
organisation business with process, data storage, data flow and external entity information. DFD is originated
with Chris Gane and Trish Sarson in 1979 who popularized the technique for structured analysis and design. This

6
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com
 PROGRAMMING LOGIC AND TECHNIQUES
is commonly called a process model. It is sometimes also referred to as bubble chart. The DFD illustrate the
movement in the system. It shows the flow of information from and within and to a system. DFDs are useful tools
for the analysing the existing system. DFD is a network that describes the flow of data and the process that change
or transfer, data throughout a system. One of the reasons for the success of DFD is that they can express by means
of an attractive graphical notation that makes them easy to use. The main merit of DFD is that it provides an
overview of what data flows in a system, what transformations are done on the data, what files are used and
where results flow. A DFD model uses a very limited number of primitive symbols to represent the functions
performed by a system and the data flow among these functions.

DFD are structured in such way that starting from a simple diagram which provides a broad overview at
particular layout and they can be expanded to a hierarchy of diagram giving more and more detail. It is used to
describe and analyses the movement of data through the system manual or automated. It is used by the
information technology professionals and system analysts to show and document users how data moves between
different processes. It is a graphical tool that depicts the flow of data in an information systems, the relationship
among the data flows and how data come to be stored at specific location. It represents the functions or processes
which capture, manipulate, store and distribute data between a system and its environment and between
components within a system. An approach is to prepare DFDs for an overview of the system first, then add
detailed aspects of the diagram. In other words, the diagrams move from general to specific. DFD is an elegant
modeling technique that turns out to be useful not only to represent the results of structured analysis of a
software problem but also for several other applications such as showing the flow of documents or items in an
organization.

DFD is a way to model a real world situation. It is the interface between the real world activities and an
understanding of how this can be converted in to a computer system. DFD are structured in such way that starting
from a simple diagram which provides a broad overview at particular layout and they can be expanded to a
hierarchy of diagram giving more and more detail. A data flow diagram is strong in illustrating the relationship of
processes, data stores and external entities in business information system which graphically shows the relation
between process and data.

Advantages of DFD:
 It is easy to understand.
 It is easier and faster way to produce and amend.
 It is useful communicating tool.
 It is useful as the part of system documentation file.
 It explains the logic behind the data flow within the system.
 It provides a detailed representation of system components.
 It follows the top-down approach.

Disadvantages of DFD:
 DFDs for large systems can become cumbersome, difficult to translate and read, and be time consuming in
their construction.
 Data flow can become confusing to programmers, but DFDs are useless without the prerequisite detail.
 Different DFD models employ different symbols (circles and rectangles, for example, for entities).

Difference between DFD and Flow Chart

DATA FLOW DIAGRAM
1. A data flow diagram typically describes the data
flow within a system
2. Data flow diagrams represent the flow of data.
3. In a data flow diagram, identifying the procedural
information is not necessary.
4. It also not necessary to show information regarding
the timing of processes, or whether the process will
operate in a sequence or in a parallel, in the data flow
diagram.
5. In DFD there is not including flowchart loops of
control elements.
6. In DFD have no data flows that split up into a
7
FLOWCHART
1. A flow chart describes the detailed logic of a
business process.
2. A flow chart shows the flow of control.
3. In a flow chart, a reader can determine what
operations will be performed, in what order, and
under what circumstances.
4. But it is crucial in a flow chart.
5. In Flow Chart there is including flowchart loops
of control elements.
6. In Flow chart there is possible data flows that
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com
 PROGRAMMING LOGIC AND TECHNIQUES
number of other data flows split up into a number of other data flows and
controls.

Some Symbols used in Data Flow Diagram:

1. External Entity: An external entity is a route or destination of a data flow which is outside the area of study
only those entities which receive data and that data are represented on a business diagram. The
symbol used is oval containing a meaningful and unique identifier. It is also called external agent.
External entities are those things that are identified as needing to interact with the system under
consideration. The external entities either input information to the system, output information
from the system or both. These are called sources if they are external to the system and provide data to the
system, and sink if they are external to the system and receive information from the system. A person,
organization or system that is external to the system but interacts with it.

2. Process: A process shows a transformation and manipulation of data flows within the system.
The symbol is used rectangular box or a circle which contains three descriptive elements. It is also
referred to as a black box. It contains the business logic therefore it is also called business rules. It
receives input data and produces output that has a different content, form, or both. This may be a
department, a piece of hardware etc. It is an activity or function performed for a specific business reason. It can be
manual or computerized. Examples of good process names would be:
 Enter customer details
 Register new students
 Validate sales orders.
3. Data Flow: A data flow shows the flow of information from its source to its destinations. A data
flow is represented by a line with single or double arrowheads that swing the direction of flow.
Information always flows to or from a process. It represents one or more data items. It represents
movement of data. It always starts and ends at a process. It shows the connection of a single piece of data or a
logical collection of data. Flows of data between:
• external entities and processes
• processes and other processes
• processes and data stores

4. Data Store: A data store is a holding placing for information within the system. It is represented
by an open ended narrow rectangle. Data store may be a long time files such as sale ledgers or may
be short term accumulation. Data stores are places where data may be stored. This information
may be stored either temporarily or permanently by the user. In any system you will probably
need to make some assumptions about which relevant data stores to include. The data flowing out is retrieved
from the data store and data flowing in updates or is also added to the data store.

The symbols used for DFDs According to few authors:

SR. Operation Gane & Sarson DeMarco & Description
Yourdon
1. External entity Source or destination of data.

2. Process Location where data is transformed.

3. Flow Oriented link between objects, which conveys

data.
4. Data store Repository of data.

5. Split/Merge Splits a flow into several flows or merges flows

from different sources into one flow.

RULES OF DATA FLOW DIAGRAM:

8
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com
 PROGRAMMING LOGIC AND TECHNIQUES
 All processes must have at least one data flow in and one data flow out.
 All processes should modify the incoming data, producing new forms of outgoing data.
 Each data store must be involved with at least one data flow.
 Each external entity must be involved with at least one data flow.
 A data flow must be attached to at least one process.

1. Data can flow from:

 external entity to process
 process to external entity
 process to store and back
 process to process
2. Data cannot flow from:
 external entity to external entity
 external entity to store
 store to external entity
 store to store

Example1: DFD for withdrawn a deposited cash amount:

This diagram represents a banking process, with maintenance customer accounts. Customer withdrawn
deposited cash, request information about their account or update their account detail.

Example2: DFD for order processing system:

In this Physical DFD shows the actual details that perform the function in to a system thus, there is an “Order
processing Clerk” an “Entry into customer file” which processed and a “run locate program “process to locate the
parts ordered.

Example 3: DFD for Course Registration System:

Example: 4 DFD for patient information system:

9
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com
 PROGRAMMING LOGIC AND TECHNIQUES

Example: 5 DFD for students' registration system:

CLASSIFICATION OR CATEGORY OF DFDs:

Data flow diagrams (DFDs) are categorized as either logical DFD or physical DFD. A logical DFD focuses on the
business and how the business operates. It describes the business events that take place and the data required
and produced by each event. On the other hand, a physical DFD shows how the system will be implemented using
technology and manual procedures.
1. Physical Data Flow Diagram
2. Logical Data Flow Diagram

Physical Data Flow Diagram:

'Physical' means that we document the system as it appears in the 'real world'. The physical DFD is a model of
the current system and is used to ensure that the current system has been clearly understood. Physical DFD
shows actually devices, department people etc. involved in the current system.

Characteristics of Physical Data Flow Diagram (PDFD):

 It is easier to describe the interaction between physical components than to understand the policies used to
manage the application. The movement of people, documents and information between departments and
locations is also identified.
 Physical data flow diagrams are useful for communicating with users. Users relate easily to people, locations
and documents as they work with these each day.
 Physical DFDs provide a way to validate or verify the user's current view of the system with the way it is
actually operating. If there are differences, they will be noted and discussed.

Advantages of Physical DFD:

 Clarifying the manual and automated processes.
 Describing processes in more detail than logical DFDs.
 Sequencing processes that have to be done in a particular order.
 Identifying temporary data stores.
 Specifying actual names of files and printouts.
 Adding controls to ensure the processes are done properly.

Logical Data Flow Diagram:

Logical DFD is the model of the proposed system. 'Logical' means what the system actually does. A logical data
flow diagram, as the name indicates concentrates on the business and tells about the events that take place in a
business and the data generated from each such event. It describes the business events that take place and the
data required and produced by each event.

Both physical and logical DFD, support a top down approach to system analysis. For this purpose, analyst begin by
developing a general understanding of the system and gradually explode components is greater details. This is
achieved through context diagram, first level DFD, and second level DFD.

10
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com
 PROGRAMMING LOGIC AND TECHNIQUES
Advantages of Logical DFD:
 Better communication with users.
 More stable systems
 Better understanding of the business analysts
 Flexibility and easier maintenance
 Elimination of redundancies and easier creation of the physical model.

Levelling in Data Flow Diagram:

1. Context Diagram or Level 0(zer0)
2. Lower Level Diagrams (Level 1, Level 2…Level N)
Context Diagram:
A context diagram is a diagram to conceptualize data flows within an organization. It usually is a list of external
entities, data flows, processes, and data stores which determines the boundary of the target system. The context
diagram always has only one process labelled 0.
 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

Lower Level Diagrams:

Any "real" system is too large to represent as a single data flow diagram. The solution is to decompose the system
into a hierarchy of levels of processing. It is also called the partitioning. Partitioning is the process of dividing a
data flow diagram into manual procedures and computer programs. It is used after the physical data flow diagram
has been created by examining the processes and the data flowing from one process to another.

The process model of the system then consists of a set of levelled data flow diagrams. Levelling of DFDs improves
their readability and usefulness as a communication tool. A context diagram is expanded into a number of inter-
related processes. Each process may be further expanded into a set of inter-connected sub processes. This
procedure of expanding a DFD is known as levelling. A level-zero DFD is prepared to show an overview of the
system including basic inputs, processes, and outputs.

The rules to be followed while drawing Level 0 diagram:

 include all entities in the context diagram
 show any data store that are shared by the processes in the level 0 diagram
The 0 level DFD of system is as follows:
 Identify where data is captured from
 Identify where data is distributed to
 Describe the overall process
 Map these out using the correct symbols
 Link them with data flows

Exmple:6 Context diagram for food ordering system:

Exmple: 7 Context diagram for Airline Reservation system

11
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com
 PROGRAMMING LOGIC AND TECHNIQUES

Exmple: 8 Context diagram for student grading system:

Exmple: 9 Level 0 diagram for a grading system:

12
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com
 PROGRAMMING LOGIC AND TECHNIQUES

Exmple: 10 Level 0 DFD for student information system:

Exmple: 11 Level 1 DFD for student information system:

13
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com

Exmple: 12 Level 1 DFD for Payroll system:
Physical vs Logical DFD:
Design Feature
What the model depicts
What the process represent
What the data stores represent
Type of data source
System controls
PROGRAMMING LOGIC AND TECHNIQUES
Logical
How the business operates
Business activities
Collection of data, regardless of
how the data is stored
Show data stores representing
permanent data collections
Show business controls
14
Physical
How hue system will be implemented
(or how the current system operates)
Programs, program modules and
manual procedures
Physical files and databases, manual
files
Master files, transaction files. Any
processes that operate at two different
times must be connected by a data
source
Show controls for validating input data,
for obtaining a record (record found
status), for ensuring successful
completion of a process and for system
security (example: Journal records)
Prepared by: N.P.BHUSAL
Email ID: smcnpbhusl@gmail.com