DFD Placement Cell

Download as pdf or txt
Download as pdf or txt
You are on page 1of 9

AIM:

To study and draw data flow diagram for Online Training and
Placement System.

THEORY:
What is Data Flow Diagram?
A data flow diagram (DFD) is a graphical representation of the flow of data
through an information system, modeling its process aspects. A DFD is often
used as a preliminary step to create an overview of the system, which can later
be elaborated. DFDs can also be used for the visualization of data processing
(structured design). A DFD shows what kind of information will be input to and
output from the system, where the data will come from and go to, and where the
data will be stored. It does not show information about the timing of process or
information about whether processes will operate in sequence or in parallel (which
is shown on a flowchart).

Symbols in the data flow diagram


1. External Entity- External entities determine the system boundary. They are
external to the system being studied. They are often beyond the area of
influence of the developer.
These can represent another system or subsystem. These go on margins/edges
of data flow diagram. External entities are named with appropriate name.
2. Process- Processes are work or actions performed on incoming data flows to
produce outgoing data flows. These show data transformation or change.
Data coming into a process must be worked on or transformed in some
way. Thus, all processes must have inputs and outputs. In some (rare)
cases, data inputs or outputs will only be shown at more detailed levels of
the diagrams. Each process in always running and ready to accept data.
3. Data flow-Data flow represents the input (or output) of data to (or from) a
process (data in motion). Data flows only data, not control. Represent
the minimum essential data the process needs. Using only the minimum
essential data reduces the dependence between processes. Data flows must
begin and/or end at a process.
Data flows are always named. Name is not to include the word data.
Should be given unique names. Names should be some identifying noun. For
example, order, payment, complaint.
1

Figure 1: DFD notations

4. Data stores-Data Stores are repository for data that are temporarily or permanently recorded within the system. It is an inventory of data. These are
common link between data and process models. Only processes may connect
with data stores.
There can be two or more systems that share a data store. This can occur
in the case of one system updating the data store, while the other system
only accesses the data.
Data stores are named with an appropriate name, not to include the word
file, Names should consist of plural nouns describing the collection of data.
Like customers, orders, and products. These may be duplicated. These are
detailed in the data dictionary or with data description diagrams.

Rules in data flow diagram


Naming conventions:
Processes: strong verbs
dataflows: nouns
datastores: nouns
external entities: nouns
1. No more than 7 - 9 processes in each DFD.
2. Dataflows must begin, end, or both begin and end with a process.
3. Dataflows must not be split.
4. A process is not an analog of a decision in a systems or programming
flowchart. Hence, a dataflow should not be a control signal. Control signals are modeled separately as controlflows.
5. Loops are not allowed.
6. A dataflow can not be an input signal. If such a signal is necessary, then it
must be a part of the description of the process, and such process must be
so labeled. Input signals as well as their effect on the behavior of the system
are incorporated in the behavioral model (say, state transition graphs) of the
information system.
7. Decisions and iterative controls are part of process description rather than
dataflows.
8. If an external entity appears more than once on the same DFD, then a
diagonal line is added to the north-west corner of the rectangle (representing
such entity).
9. Updates to datastores are represented in the textbook as double-ended arrows. This is not, however, a universal convention. I would rather you did
not use this convention since it can be confusing. Writing to a datastore implies that you have read such datastore (you can not write without reading).
Therefore, datastore updates should be denoted by a single-ended arrow from
the updating process to the updated datastore.
3

10. Dataflows that carry a whole record between a datastore and a process is
not labeled in the textbook since there is no ambiguity. This is also not a
universal convention. I would rather you labeled such dataflows explicitly.
Conservation Principles: Datastores and Dataflows: Datastores can not create (or destroy) any data. What comes out of a datastore therefore must
first have got into a datastore through a process. Processes: Processes can
not create data out of thin air. Processes can only manipulate data they
have received from dataflows. Data outflows from processes therefore must
be derivable from the data inflows into such processes.
Levelling Conventions: Numbering: The system under study in the context
diagram is given number 0. The processes in the top level DFD are labelled consecutively by natural numbers beginning with 1. When a process
is exploded in a lower level DFD, the processes in such lower level DFD are
consecutively numbered following the label of such parent process ending
with a period or full-stop (for example 1.2, 1.2.3, etc.). Balancing: The set
of DFDs pertaining to a system must be balanced in the sense that corresponding to each dataflow beginning or ending at a process there should be
an identical dataflow in the exploded DFD. Datastores: Datastores may be
local to a specific level in the set of DFDs. A datastore is used only if it is
referenced by more than one process. External entities: Lower level DFDs
can not introduce new external entities. The context diagram must therefore show all external entities with which the system under study interacts.
In order not to clutter higher level DFDs, detailed interactions of processes
with external entities are often shown in lower level DFDs but not in the
higher level ones. In this case, there will be some dataflows at lower level
DFDs that do not appear in the higher level DFDs. In order to facilitate
unambiguous balancing of DFDs, such dataflows are crossed out to indicate
that they are not to be considered in balancing. This convention of crossing
is quite popular, but this text does not follow it. I would rather you followed
this convention.

CONCLUSION: Hence we have drawn and studied data flow diagram for
Online Placement Cell System system.

Figure 2: Level 0 DFD

Figure 3: Level 1 DFD

Figure 4: Level 2 DFD for Student


7

Figure 5: Level 2 DFD for Admin


8

Figure 6: Level 2 DFD for Company

You might also like