Jump to content

Data-flow diagram

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by SoftwareDeveloper (talk | contribs) at 15:10, 15 June 2006 (→DFD tools). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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 practise 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 modelled.

Data flow diagrams were invented by Larry Constantine, the original developer of structured design, based on Martin and Estrin's "data flow graph" model of computation. Data flow diagrams (DFDs) are one of the three essential perspectives of SSADM. The sponsor of a project and the end users will need to be briefed and consulted throughout all stages of a systems evolution. With a dataflow diagram, users are able to visualise in a physical visual form how the system will operate, what the system will accomplish and how the system will be implemented. Old system dataflow diagrams can be drawn up and compared with the new systems dataflow diagrams to draw comparisons to implement a more efficient system. Dataflow diagrams can be used to provide the end user with a physical idea of where the data they input, ultimately has an effect upon the structure of the whole system from order to dispatch to restock how any system is developed can be determined through a dataflow diagram.

The original book on DFDs is 'Structured Analysis and System Specification'. Tom DeMarco. Yourdon, Inc., Englewood Cliffs, New Jersey, 1978. For more information on Data Flow Diagrams, please consult chapter 9 of Ed Yourdon's on-line book, "Just Enough Structured Analysis".

Types of DFD

In analysing a business, several sets of DFD's are drawn. Initial DFD's might model the existing system (flaws and all), while later DFD's may model a solution to the problem being analysed. For these solution DFD's a logical and physical DFD is drawn. Physical DFD's represent physical files and transactions, while logical or conceptual DFD's can be used to represent business functions or processes.

Components

A data flow diagram illustrates the processes, data stores, and external entities in a business or other system and the connecting data flows.

The four components of a data flow diagram (DFD) are:

  • External Entities/Terminators/Sources/Sinks (represented by a square or oval)
  • Processes (represented by a circle or rounded rectangle)
  • Data Flows (represented by an arrow)
  • Data Stores (represented by two parallel lines, sometimes connected by a vertical line)
External Entities/Terminators
are outside of the system being modeled. Terminators represent where information comes from and where it goes. In designing a system, we have no idea about what these terminators do or how they do it.
Processes
modify the inputs in the process of generating the outputs
Data Stores
represent a place in the process where data comes to rest. A DFD does not say anything about the relative timing of the processes, so a data store might be a place to accumulate data over a year for the annual accounting process.
Data Flows
are how data moves between terminators, processes, and data stores.

Every page in an DFD should contain fewer than 10 components. If a process has more than 10 components, then one or more components (typically a process) should be combined into one and another DFD be generated that describes that component in more detail. Each component should be numbered, as should each subcomponent, and so on. So for example, a top level DFD would have 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

Data process

A data process represents the transformation of data in the system. Generally, this represents something that happens in the system, such as 'student enrollment' e.g. eddys enrolling into lumpender school for lumpy enders. Data that flows into a process should be different than the data that flows out of the process.

Data store

A data store is a repository for data. Data stores can be manual, digital, or temporary.

External entities

External entity
External entity that has been replicated

An external entity represents the source or sink of data external to the system. When modeling a DFD, the designer is not interested in the inner workings of the external entity, but only what data is produced/needed by the entity.

Duplication

External entities and data stores can be duplicated in the system for more clarity, while processes cannot. External entities that have been replicated are marked by an asterisk (*) in the lower right part of the oval that represents that entity. Data stores have a double line of the left side of their box.

Developing a DFD

Top-Down Approach

  1. 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).
  2. The system is decomposed in lower level DFD into a set of processes, data stores, and the data flows between these processes and data stores.
  3. Each process is then decomposed into an even lower level diagram containing its subprocesses.
  4. This approach then continues on the subsequent subprocesses, until a necessary and sufficient level of detail is reached.

Event Partitioning Approach

This approach was described by Edward Yourdon in "Just Enough Structured Analysis", chapter 19 .

  1. Construct detail DFD.
    1. The list of all events is made.
    2. For each event a process is constructed.
    3. Each process is linked (with incoming data flows) directly with other procesess or via datastores, so that it has enough information to respond to given event.
    4. The reaction of each process to a given event is modeled by an outgoing data flow.
  2. Develop higher level DFDs for clarity.
    1. A group of related processes is agregated into a process of higher level.
    2. Related agregated processes are agragated into a process of even higher level.
    3. This process than continues until a contectual level DFD is reached.

DFD tools

  • ConceptDraw - Windows and MacOS X data flow diagramming tool
  • Dia - open source diagramming tool with DFD support
  • MacA&D - Macintosh tool for multi-level data and control flow diagrams, data dictionary with verification and balancing reports
  • Microsoft Visio - Windows diagramming tool which includes DFD support
  • WinA&D - Windows tool for multi-level data and control flow diagrams, data dictionary with verification and balancing reports
Retrieved from "https://en.wikipedia.org/w/index.php?title=Data-flow_diagram&oldid=58772524"