Guidelines for Drawing Dataflow Diagrams

• Naming conventions:
  • Processes: strong verbs

  • dataflows: nouns

  • datastores: nouns

  • external entities: nouns

• No more than 7 - 9 processes in each DFD.

• Dataflows must begin, end, or both begin & end with a process.

• Dataflows must not be split.

• A process is not an analog of a decision in a systems or programming flowchart. Hence, a dataflow should not be a control signal. Control signals are modeled separately as controlflows.

• Loops are not allowed.

• A dataflow can not be an input signal. If such a signal is necessary, then it must be a part of the description of the process, and such process must be so labeled. Input signals as well as their effect on the behavior of the system are incorporated in the behavioral model (say, state transition graphs) of the information system.
• Decisions and iterative controls are part of process description rather than dataflows.

• If an external entity appears more than once on the same DFD, then a diagonal line is added to the north-west corner of the rectangle (representing such entity).

• Updates to datastores are represented in the textbook as double-ended arrows. This is not, however, a universal convention. I would rather you did not use this convention since it can be confusing. Writing to a datastore implies that you have read such datastore (you can not write without reading). Therefore, datastore updates should be denoted by a single-ended arrow from the updating process to the updated datastore.

• Dataflows that carry a whole record between a datastore and a process is not labeled in the textbook since there is no ambiguity. This is also not a universal convention. I would rather you labeled such dataflows explicitly.

• Conservation Principles:

  Datastores & Dataflows: Datastores can not create (or destroy) any data. What comes out of a datastore therefore must first have got into a datastore through a process.

  Processes: Processes can not create data out of thin air. Processes can only manipulate data they have received from dataflows. Data outflows from processes therefore must be derivable from the data inflows into such processes.

• Levelling Conventions:

  Numbering: The system under study in the context diagram is given number `0'. The processes in the top level DFD are labelled consecutively by natural numbers beginning with 1. When a process is exploded in a lower level DFD, the processes in such lower level DFD are consecutively numbered following the label of such parent process ending with a period or full-stop (for example 1.2, 1.2.3, etc.).

  Balancing: The set of DFDs pertaining to a system must be balanced in the sense that corresponding to each dataflow beginning or ending at a process there should be an identical dataflow in the exploded DFD.

  Datastores: Datastores may be local to a specific level in the set of DFDs. A datastore is used only if it is referenced by more than one process.

  External entities: Lower level DFDs can not introduce new external entities. The context diagram must therefore show all external entities with which the system under study interacts. In order not to clutter higher level DFDs, detailed interactions of processes with external entities are often shown in lower level DFDs but not in the higher level ones. In this case, there will be some dataflows at lower level DFDs that do not appear in the higher level DFDs. In order to facilitate unambiguous balancing of DFDs, such dataflows are crossed out to indicate that they are not to be considered in balancing. This convention of crossing is quite popular, but this text does not follow it. I would rather you followed this convention.