Вы находитесь на странице: 1из 9
AIM: To study and draw data flow diagram for Online Training and Placement System. THEORY:

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
Figure 1: DFD notations 4. Data stores-Data Stores are repository for data that are temporarily

Figure 1: DFD notations

4. Data stores-Data Stores are repository for data that are temporarily or per- manently 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.

2

Rules in data flow diagram Naming conventions: • Processes: strong verbs • dataflows: nouns •

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 sig- nals 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 ar- rows. 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 im- plies 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

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 cre- ate (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 la- belled 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 corre- sponding 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 there- fore 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.

4

Figure 2: Level 0 DFD 5
Figure 2: Level 0 DFD 5

Figure 2: Level 0 DFD

5

Figure 3: Level 1 DFD 6
Figure 3: Level 1 DFD 6

Figure 3: Level 1 DFD

6

Figure 4: Level 2 DFD for Student 7
Figure 4: Level 2 DFD for Student 7

Figure 4: Level 2 DFD for Student

7

Figure 5: Level 2 DFD for Admin 8
Figure 5: Level 2 DFD for Admin 8

Figure 5: Level 2 DFD for Admin

8

Figure 6: Level 2 DFD for Company 9
Figure 6: Level 2 DFD for Company 9

Figure 6: Level 2 DFD for Company

9