Data Flow Diagram and Context Diagram

"A perfect image can help to understand a topic more clearly".

Diagrams must help to understand the object behind the workings of a software. A properly defined flow model diagram, not only helps to understand the working of the model, but also helps the software designer to built it and test it for validation with ease.

A Data Flow Diagram (DFD) is a graphical representation that depicts the information flow and the transforms that are applied as data moves from input to output. It can be used to represent a software at any level of abstraction. In fact, DFD's may be partitioned into levels that represent increasing information flow and functional detail. Therefore, it provides mechanism for functional modeling as well as information flow modeling.

DFD models a system using external entities (or events) which defines the type and amount of data that flows to a process, which transforms it and then creates an output, which then flows to some other process or external entities as output flow. Data may even flow from or to some secondary storage (generally described as data dictionary). The graphical representation makes it a good tool for communication between designer and analyst.

DFD's are defined in levels, with every level decreasing the level of abstraction, as well as defining a greater details of the functional organs of the system. A 0'level DFD, also known as Context or Fundamental System Model, represents the entire software elements as a single bubble, with input and output data entities which are indicated as incoming and outgoing arrows respectively.

Additional processes and information flow path are represented as separate bubble as 0'level DFD is partitioned into level 1, which is then partitioned into level 2, and so on. The levels are partitioned till a crystal clear view of the system is achieved.

Following symbols used in a DFD

-1) Bubble: A circle (termed bubble) is used to depict a process. Both inputs and outputs to a process are dataflows. It is shown in fig. 8.8.

Fig. 8.8: Bubble

2) Arrow: Data flows are represented by a line with an arrow, illustrated in fig. 8.9.

Fig. 8.9: Arrows on Line Shows Input and Output Flows

Ward and Mellor used single head arrow to represent discrete data and double headed arrow to use time continuous data (fig. 8.10).

Fig. 8.10: Ward and Mellor Extension

(3) Rectangle: Rectangles are used to represent the entities and are outside the system. Designers do not have any control over them. They either supply or receives data. In the fig. 8.11, two entities supplier and receiver are shown as rectangles. So, supplier entity A supplies some stock delivered to the receiver entity B.

A B

XProcess

Supplier Entity Receiver Entity Fig. 8.11: Rectangle as an Entity

Even a single entity can both supply and receive data.

(4) Parallel Lines : Parallel lines are used to depict data stores. Process may store or receive data from data stores. Data cannot flow between two data stores. An arrow towards data store indicates writing data to data store and an arrow from data stores depicts retrieval of data from it, which is shown diagrammatically in fig. 8.12.

Fig. 8.12: Data Store Representation

There are some guidelines to create a data flow diagram. They are given below :

(i) Level 0 DFD should depict the entire system as single bubble along with all the related entities processing with the system.

ss

(ii) Primary input should be carefully noted.

(iii) Refinement should begin by isolating the candidate processes, data objects and stores to be repre-sented at the next level.

(iv) All arrows and bubbles should be named with meaningful names.

(v) Information flow continuity must be maintained at the next level.

(vi) Only one bubble should be refined at a time.

(vii) A good dataflow diagram should not possess:

a). loops,

b). a process which is taking a pure decision, c). flow lines crossing each other, and,

d). splitting of a data flow into different flows with different meaning.

(A) Logical and Physical DFD's

All the DFD's discussed earlier represented logical process/operations that are to be performed by the system. Such DFD's are known as Logical DFD's. They specify various logical processes.

Instead of logical processes, if DFD represents objects which perform the physical operations, that it is known as Physical DFD.

In fig. 8.13, the logical DFD is shown to process the order of vendor. If order is accepted then it the inventory file process is updated otherwise it is rejected.

Fig. 8.13: Logical DFDFig. 6.15 : Logical DFD

In fig. 8.14, the physical DFD is shown when vendor requests for his delivery note then it is checked by the clerk, if accepted then stored otherwise if rejected then returned back.

Fig. 8.14: Physical DFD

(B) Leveling of DFDs

As we know that it is easier to solve a problem in 'top-down' manner, that is starting with an overview and then working out the details. Similarly, it is easier to understand leveled DFDs as compared to single large detailed DFD.

Leveled DFDs are drawn in top-down approach, i.e. at top level 0-level DFD or context diagram is made then this 0-Level DFD is expanded to level-1 DFD from (expanding and dividing) the main process/bubble of 0-level DFD.

At level-1, the bubbles are also called as the processes. To draw level-2 DFD, these sub-processes are further expanded & divided individually in 3 to 5 bubbles and so on. A detailed illustration of leveling is shown in fig. 8.15.

Fig. 8.15: Leveling of a DFD 8.5 Various Tools Of Structured Analysis

There are various tools of structured analysis which are discussed one-by-one in the following sections.