1 / 23

Data Flow Diagrams

Data Flow Diagrams. Trisha Cummings. What are Data Flow Diagrams?. A data flow diagram ( DFD ) is a graphical representation of the "flow" of data through an information system. A data flow diagram can also be used for the visualization of data processing (structured design).

janeeva
Download Presentation

Data Flow Diagrams

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Data Flow Diagrams Trisha Cummings

  2. What are Data Flow Diagrams? • A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. • A data flow diagram can also be used for the visualization of data processing (structured design). • It is common practice for a designer to draw a context-level DFD first which shows the interaction between the system and outside entities. • This context-level DFD is then "exploded" to show more detail of the system being modeled

  3. Data Flow Diagram Symbols • There are only four symbols: • Squares representing external entities, which are sources or destinations of data. • Rounded rectangles representing processes, which take data as input, do something to it, and output it. • Arrows representing the data flows, which can either be electronic data or physical items. • Open-ended rectangles representing data stores, including electronic stores such as databases or XML files and physical stores such as or filing cabinets or stacks of paper.

  4. Data flow diagrams can be used to provide a clear representation of any business function. • The technique starts with an overall picture of the business and continues by analyzing each of the functional areas of interest. • This analysis can be carried out to precisely the level of detail required.

  5. Common Modeling Rules • 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.

  6. Ways to develop a DFD • Top-Down Approach • Event Partitioning Approach

  7. Top-Down Approach • The system designer makes a context level DFD, which shows the interaction (data flows) between the system (represented by one process) and the system environment (represented by terminators). • The system is decomposed in lower level DFD (Zero) into a set of processes, data stores, and the data flows between these processes and data stores. • Each process is then decomposed into an even lower level diagram containing its sub processes. • This approach then continues on the subsequent sub processes, until a necessary and sufficient level of detail is reached which is called the primitive process (aka chewable in one bite).

  8. Event Partitioning Approach • This approach was described by Edward Yourdon in Just Enough Structured Analysis • Construct detailed DFD. • The list of all events is made. • For each event a process is constructed. • Each process is linked (with incoming data flows) directly with other processes or via data stores, so that it has enough information to respond to a given event. • The reaction of each process to a given event is modeled by an outgoing data flow

  9. As an aid in developing DFDs, consider the following description of processing steps.

  10. Advantages to using a DFD • Data flows and process consequences. • Wherever we start in the process, we can understand the processing steps that the needed to take to complete the relevant transaction(s) and to inform its constituents of the results. • Data inputs and outputs. • The DFD also makes it possible to understand what data are needed to provide appropriate inputs to any processing step.

  11. Simplifying complexity by isolating process components. • The DFD would make it easier to capture the detail of such data flows. • At the time that DFDs were developed, this shift towards modularizing data flows and processing elements represented a major step forward in enabling systems analysts to add useful structure to process representations rapidly and easily.

  12. Common DFD Mistakes • Illegal data flows • Illegal data flows • DFDs are not flow charts

  13. Illegal data flows • One of the patterns of data flow analysis is that all flows must begin with or end at a processing step. • This makes sense, since presumably data cannot simply metastasize on its own without being processed (in spite of the circumstantial evidence we might have gathered in our own business experience...). • This simple rule means that the following mistakes can be fairly easily identified and corrected in a DFD. • The symbols shown on the next slide are purposefully left blank (e.g., without captions) so that it is easier for you to recognize patterns such as these in your own DFDs.

  14. Black holes, grey holes, and miracles • A processing step may have input flows but no output flows. This situation is sometimes called a black hole . • A processing step may have output flows but now input flows. This situation is sometimes called a miracle. • A processing step may have outputs that are greater than the sum of its inputs - e.g., its inputs could not produce the output shown. This situation is sometimes referred to as a grey hole.

  15. DFDs are not flow charts • Many of us have had prior experience developing flow charts. Flow chart diagrams can be useful for describing programming logic or understanding a single sequence of process activities. • It is important to recognize, however, that DFDs are not flow charts. • Flow charts often show both processing steps and data "transfer" steps (e.g., steps that do not "process" data); DFDs only show "essential" processing steps. • Flow charts might (indeed, often do) include arrows without labels: DFDs never show an unnamed data flow. • Flow charts show conditional logic; DFDs don't (the conditional decisions appear at lower levels, always within processing steps). • Flow charts show different steps for handling each item of data; DFDs might include several data items on a single flow arrow.

  16. Who makes DFD tools? • ConceptDraw - Windows and MacOS X data flow diagramming tool • Dia - Free source diagramming tool with flowchart support • Kivio - Free source diagramming tool for KDE • Microsoft Visio - Windows diagramming tool which includes very basic DFD support (Images only, does not record data flows) • SILVERRUNModelSphere - cross-platform tool for business process modelling and data flow diagramming • SmartDraw - Windows diagraming tool with "Yourdon and Coad Process Notations" and "Gane and Sarson Process Notation"

  17. Resources • Data Flow Diagrams • http://en.wikipedia.org/wiki/Data_flow_diagram • Agile Modeling • http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm • EDrawSoft – Data Flow Diagrams • http://www.edrawsoft.com/Data-Flow-Diagrams.php

  18. More Sources • Data flows: Note on Data-Driven Process Modeling • http://faculty.babson.edu/osborn/mis7520/readings/dfddiag.htm

More Related