Data+Flow+Diagrams

A "context level" DFD can be used to show the interaction between a system and outside entities; it can also show the internal data flows within a system. This version is also called a **context diagram**. It often shows the information system as a single circular shape with no details of its inner workings: what it shows is its relationships with the //external entities//.
 * These are very similar to //system flow charts// which are not used as much any more ||
 * A **Data Flow Diagram** (**DFD**) is a design tool to represent the flow of data through an information system.

For a diagram to be called a DFD, it needs to show the inner workings of an information system. The different levels of a DFD indicate how detailed it is, e.g. a Level 0 DFD is a broad overview of a system, showing hardly any detail within the system. A level 2 DFD explodes more summarised processes and shows another level of complexity within them. A level 3 or 4 DFD shows even more components opened up to show their inner details.

With a DFD, developers can map how a system will operate, what the system will accomplish and how the system will be implemented. It's important to have a clear idea of where and how data is processed in a system to avoid double-handling and bottlenecks. A DFD also helps management organise and prioritise data handling procedures and staffing requirements.

A DFD lets a system analyst study how existing systems work, locate possible areas prone to failure, track faulty procedures and reorganise components to achieve better efficiency or effectiveness.

A DFD graphically represents:
 * Components**
 * **processes** - jobs that are done with the data. A process transforms incoming data flow into outgoing data flow.
 * **data stores** - files, databases, archives. They can be manual, digital or temporary.
 * **external entities**/terminators in a business or other system - other systems or people beyond the control of the current system. These are the places which provide the organisation with data, or have data sent to them by the organisation (e.g. customers, partners, government bodies). External entities are sources and destinations of the system's inputs and outputs.
 * **connecting data flows** - arrows show how data flows from one place to another. Flows that cross the system boundary are known as Input Output Descriptions. Label the arrows with the name of the data that moves through it.

Here are the basic DFD shapes :

DFD Conventions
A sample DFD from http://www.smartdraw.com ||
 * Do not allow a single page of a DFD to get too complex - it should have no more than 10 components. If it has more than this, combine some components into a single self-contained unit and create a new DFD for that unit.
 * Each component and subcomponent should be numbered. e.g. a top level DFD has components 1 2 3 4 5. The subcomponent DFD of component 3 would have components 3.1, 3.2, 3.3, and 3.4; and the subsubcomponent DFD of component 3.2 would have components 3.2.1, 3.2.2, and 3.2.3. This enables a developer to plan in a [| top-down] manner: starting with representing large concepts, and then repeatedly breaking these objects into their components.
 * All processes must have at least one data flow in and one data flow out.
 * All processes should modify the incoming data, producing new forms of outgoing data.
 * Each data store must be involved with at least one data flow.
 * Each external entity must be involved with at least one data flow.
 * A data flow must be attached to at least one process
 * Data flows cannot go directly from one external entity to another external entity: such flows need to go through at least one process.
 * Data flows cannot go directly from an external entity to a data store in the system: such flows need to go through at least one process. ||
 * [[image:http://www.vceit.com/designtools/dfd/dfdexample.gif width="455" height="383"]]
 * As you explore DFDs you will find two main types out there: the //Yourdon and Coad// style, and the //Gane and Sarson//

//style.// They have slight differences in the way components are shaped and where their numbering goes, for example: || || //Gane and Sarson// datastore notation || || "Student" box is an external entity.
 * [[image:http://www.vceit.com/designtools/dfd/yc-datastore.gif width="116" height="67"]] || //Yourdon and Coad// datastore notation ||  ||
 * ==SAMPLE DFDs== ||
 * http://www.smartdraw.com/examples/preview/index.aspx?example=Quiz_Software
 * http://www.smartdraw.com/examples/preview/index.aspx?example=Quiz_Software
 * An example from [|www.visualcase.com] - you can download a 30 day free trial of their DFD software

Blue circles are data transformations (processing).

Arrows are data flows.

The "Student database" is a data store. ||
 * Modified by L.Barnard from http://www.vceit.com/designtools/dfd/dfd.htm [Accessed: 2/2/13] ||

Return to Year 11 IT