5-Data+Flow+Diagrams

. =**Data Flow Diagrams**=

Contents: Yourdon 9, class slides

=**What is a DFD?**=

A data flow diagram or "DFD" is a modeling tool that depicts the functional process of a system. It is a graphic representation of functions which manipulates, stores and distributes data. There are four components that make up the DFD: processes, data flows, store and entity.

=**DFD Components:**=


 * Process**- The process shows a part of a system that transforms inputs into outputs. __Ex__: Create a report, sorts, calculates, reads or writes. It is usually represented by a circle or oval. The shape of the process is purely cosmetic, that is it should be consistent throughout the entire diagram to be understood effectively.
 * The Flow-** This component of the DFD is used to show the movement of information from one part of the system to the other. It is represented graphically by an arrow.


 * The Store**- Is used to model a collection of data packets. The store is represented graphically by two parallel lines.

=Guidelines for Constructing DFD's=
 * Source/Entity**- Generates data as input to the system or accepts output from the system. The entity always exists outside the system that is being modeled. In this manner the entity represents the system's connection with the outside world. __Ex__: Customer submits an order. Customer receives an order. Graphically the entity is represented by a rectangle or square.
 * 1) Choose meaningful names for processes, flows, stores, and terminators.
 * 2) Number the processes.
 * 3) Redraw the DFD as many times as necessary for aesthetics.
 * 4) Avoid overly complex DFDs.
 * 5) Make sure the DFD is internally consistent and consistent with any associated DFDs.

= = =**Leveled DFD's**= It is often necessary for the DFD to be more complex than the three bubble systems we have seen thus far. To avoid overly complex diagrams we create leveled DFDs, which allow the information to be organized into manageable parts. Leveled DFD's are organized so that each successive level provides greater detail about the level above it. This is similar to the organization of an atlas, which start with a larger view such as the world, and then focus on smaller more detailed parts of that whole as they progress.
 * Choose Meaningful Names:**
 * Avoid names of people or groups
 * Identify functions the system is carrying out
 * Choose an active verb and an appropriate object for a descriptive phrase.
 * Ex: PRODUCE INVENTORY REPORT
 * Number the Processes:**
 * The DFD model is a network of communicating, asynchronous processes.
 * The numbers don't necessarily represent the sequence of the processes.
 * In this manner Its more convenient when explaining the DFD to number the bubbles.
 * The numbers become the basis for hierarchical numbering.
 * Redrawing the DFD**:
 * Must be technically correct
 * Acceptable to the user
 * Neatly organized for presentations
 * Avoid Overly Complex DFD's:**
 * The DFD must be readily understood, easily absorbed and pleasing to the eye
 * Dont create a DFD with too many processes, flows, stores and entities on a single diagram
 * Make sure the DFD is internally consistent:**
 * Avoid black holes, bubbles that have inputs but no outputs
 * Avoid miracles, bubbles that have outputs but no inputs
 * A typical store should have both inputs and outputs.

The top level iof a leveled DFD is a single bubble representing the complete system. The level directly shows the interaction between the system and its "external terminators". Each successive level focuses on smaller portions of the system in an effort to explain the whole.

=Guidelines for Constructing Leveled DFD's=
 * Each DFD should have at most a 6 bubbles and related stores to avoid overcomplexity.


 * Small systems would typically contain 2 to 3 levels, a medium 3 to 6, and a large system 6 to 8 levels. There is no rule to how many levels one should be able to model a system in. Those who say that every system should be able to be modeled in x number of levels are typically wrong.
 * The number of bubbles will increase exponentially from one level to the next.


 * All bubbles within a given level do not have to contain the same amount of detail. Some parts of the system will be more complex than others and as such, some bubbles could have several levels of further partitioning, while others require none.
 * Ex: If bubble 3 in figure 0 requires 3 levels of further partitioning, or detail, bubble 4 in figure 0 does not necessarily require 3 further levels of detail, unless the complexity of the system warrants it.


 * In order to maintain consistency across levels, dataflows coming and going to a bubble at one level must correspond to the dataflows coming and going to an entire figure at the next lower level which describes that bubble above.


 * To show stores at various levels, it is necessary to be redundant in our modeling. Stores are first shown on the levels in which it serves as an interface between two bubbles. You then show (re-represent) the store at each successive level of detail describing those bubbles.
 * Bubbles that are only present at lower levels of the diagram are not represented in higher levels in which they play no role.

Control Processes
Unlike the processes we have seen thus far are purely processors of data, control processes are bubbles within a DFD that coordinate the functions of other bubbles. Real Time systems require control processes because they need to be able to model control flows.Outgoing control flows direct the actions of the receiving process. Incoming control flows are us control flows are generally signals from the other processes telling the control process that it has completed its task. Control processes are represented by dashed lines in a DFD, as seen in the figure below.

REFERENCES:

 * 1) Ed Yourdon and Larry Constantine, [|//Structured Design//]. New York: YOURDON Press, 1975.