3. Data Flow Diagrams (DFDs)

  • Data flow diagrams describe the path data takes through a system. 
  • No attempt is made to indicate the timing of events. 
  • Think of a DFD as a railroad map: it shows where the train tracks are laid, but it does not give the timetables.
  • DFDs do not attempt to describe the step-by-step logic of individual processes within a system. 
  • Rather they describe the movement and changes in data between processes.
  • As all processes alter data then the data leaving or output from a process must be different in some way to the data that entered or was input into that process. 
    • This is what all processes do; they alter data in some way. 
    • The aim of DFDs is to represent systems by describing the changes in data as it passes through processes. 
  • For example a process that adds up numbers receives various numbers as its input and outputs their sum. On DFDs there is no attempt to describe how the numbers are summed. Rather the emphasis is on where the numbers come from and where the sum is headed.
DFD Summary Points

Consider the following DFD summary points:

  • All processes must have a different set of inputs and outputs.
  • All lower-level DFDs must have identical inputs and outputs as the higher-level process they expand.
  • External entities and data stores can be reproduced on lower-level DFDs.
  • External entities must be present on context diagrams (level 0 DFDs) but are optional on lower-level DFDs.
  • Data flows into and out of a data store must be connected to a process. They can never directly connect to an external entity or another data store.
  • A single output data flow can be the input to multiple other processes.
  • Labels for processes should include verbs that describe the action taking place.



Data Flow Diagrams



HSC Software Design Data Flow Diagrams



Text Book:  Context Diagram and Data Flow Diagrams



Subpages (1): 1. Student Activity
Comments