Data flow diagram (DFD)
|Previous Page||Home Page||Next Page|
Data flow diagrams are the most commonly used way of documenting the process of current and required systems. As their name suggests they are a pictorial way of showingthe flow of data into/within the system, around the system and out ofa system. It is a graphical representation of flow of data within asystem. Unlike, flowcharts, DFDs do not give detailed descriptions of modules but graphically describe data and how the data interact with the system. The DFD enable us to visualize how the system operates,its final output and the implementation of the system as a whole including modification if any.
Components of DFD
DFDs are constructed using four majorcomponents
- external entries
- data stores
- processes and
- data flows
External entities represent thesource of data as input to the system. They are also the destinationof system data. External entities can be called data stores outsidethe system. These are represented by squares.
Data stores represent stores ofdata within the system, for example, computer files or databases. Anopen-ended box represents a data, which implies store data at rest ora temporary repository of data.
Processes represent activities inwhich data is manipulated by being stored or retrieved or transferredin some way. In other words, we can say that process transforms theinput data into output data. Circles stand for a process thatconverts data into information.
Data flow represents the movementof data from one component to the other. An arrow (→) identifiesdata flow, i.e. data in motion. It is a pipeline through whichinformation flows. Data flows are generally shown as one-way only.Data flows between external entities are shown as dotted lines(------›).
Types of DFDs: Physical &Logical DFD
It is clear from the following figure that orders are placed, orders are received, the location of ordered parts is determined and delivery notes are dispatched along with theorder.
It does not, however, tell us how thesethings are done or who does them. Are they done by computers ormanually and if manually who does them? A logical DFD of anyinformation system is one that models what occurs without showing howit occurs.
A physical DFD shows, how the variousfunctions are performed and who does them.
The above figure shows the actual devices that perform the functions. Thus there is an “order processing clerk”, an “entry into computer file” process and a“run locate program” process to locate the parts ordered. DFD that shows how things happen or the physical components are calledphysical DFD.
Typical processes that appear inphysical DFDs are methods of data entry, specific data transfer or processing methods.
A complete representation of an order processing system may be depicted as follow:
Difference between flowcharts &DFD
The program flowchart describes boxesthat describe computations, decisions, interactions and loops. It isimportant to keep in mind that data flow diagrams are not programflowcharts and should not include control elements. A good DFDshould
- have no data flows that split up intoa number of other data flows
- have no crossing lines
- not include flowchart loops ofcontrol elements
- not include data flows that act assignals to activate processes.
DECISION TABLES AND DECISION TREES
Decision tables and trees were developed long before the widespread use of computers. They not only isolate many conditions and possible actions but they help ensure that nothing has been overlooked.
Decision Tables allow us to analyze certain outcomes and to conclude which is the best outcome/option. The decision table is a chart with four sections listing all the logical conditions and actions. A decision table is a matrix of rows and columns that shows conditions and actions. Decision rule, are also included in the table, which state what procedure to follow when a certain condition exist .Structure of a decision tree is given below:
The Condition stub contains a list of all the necessary tests in a decision table. In the lower left-hand corner of the decision table we find the Action Stubwhere one may note all the processes desired in a given module. Thus Action Stub contains a list of all the processes involved in a decision table. The upper right corner provides the space for theCondition Entry - all possible permutations of Yes andNo responses related to the condition stub. The Yes and No possibilities are arranged as a vertical column called rules. Rules are numbered 1, 2, 3 and so on. The Condition entry contains a list of all Yes/No permutations in a decision table. The lower right corner holds the Action Entry. Xs or dots indicate whether anaction should occur as a consequence of the Yes/No entries under condition entry. Xs indicate action; dots indicate no action.
Thus Action entry indicates via dot orX whether something should happen in a decision table. Let usconsider the following example of book order:
If order is from book store
And if order is for 6 copies
Then discount is 25%
Else (if order is for less than 6copies)
No discount is allowed
Else (if order is from libraries)
If order is for 50 copies or more
Then discount is 15%
Else if order is for 20 to 49 copies
Then discount is 10%
Else if order is for 6 to 19 copies
Then discount is 5%
Else (order is for less than 6 copies)
No discount is allowed
A decision table for the above processis illustrated below.
The decision tree defines the conditions as a sequence of left to right tests. A decision tree helps to show the paths that are possible in a design following an action or decision by the user. Given below is the concept of decision tree.
Decision tree turns a decision table into a diagram. This tool is read from left to right, decision results in a fork, and all branches end with an outcome. Following figure illustrates the decision tree for the above book order decision table.
Summary: Although there are various techniques to represent a system, but it is up to the software developer / programmer to follow a particular technique. Itis always beneficial to draw flow chart, DFDs etc. of a given or proposed system for better understanding of the system. It helps in development and coding of the system being developed and also acts as documentation for future reference.
|Previous Page||Home Page||Next Page|