Purpose

To describe the functionality in (a part of) a system and the corresponding exchanges of data between the functions.

Example

Description

The DFD diagram style is a view of units of functionality and the exchanges of data between these units. The diagrams are hierarchical, often starting at a Context Diagram showing the entire system or subsystem as a single process with the exchanges of information between it and its environment.

Functionality is expressed in circular symbols called transformations or processes (colloquially, bubbles ). Flows of data between processes are called flows and are drawn as arcs with arrowheads indicating their direction. There are two fundamental types of processes and flows, data and control. Data flows convey information whilst control flows convey simply a status indication or signal.

Processes that operate only on control flows are called control processes, and can be defined by finite-state-machines depicted in State Transition Diagrams (STDs). They can also have a definition, held in a process specification.

Processes that operate on data and/or control flows are called data processes . They can also have a definition, and can be decomposed into a lower-level diagram that refines, or defines, their content. In Cradle, there are several possibilities for such child diagrams, including DFDs and other diagram types. In particular, a data process can be decomposed into a Use Case Diagram (UCD), as the top-level UCD for a UML model.

Flows can be discrete (drawn with a single arrowhead) or continuous (drawn with a double arrowhead). Continuous flows represent data (or signals for continuous control flows) that are always present, such as an analogue voltage from a transducer. Discrete flows can be thought of as conveying tokens of data. All flows are defined by a Data Dictionary entry (abbreviated to data definition) which defines the meaning of the data and its components. The data definition for a flow can have an arbitrary number of component data definitions, and can, in turn, be a component of arbitrarily many higher level data definitions.

Stores are places where data is at rest. There are data stores and control stores. Stores can represent files, global sections, databases or buffers. Using a store simply means that the output flows of one process which enter the store do not automatically act as a stimulus for the processes that read data from the store. If a flow links two processes together, data along the flow triggers the destination process to be potentially runnable, or indeed to run. Using stores removes this coupling, and so functions can run ascynchronously with respect to each other.

All stores are also defined in the Data Dictionary (DD). The data definition for a store will define the components of the single data record within the store or, more usually, the components of the set of data records within the store. The key, or identifying component of these records, is shown with a @ symbol in the data definition.

Stores can have un-named flows entering and leaving them. Un-named flows mean that an entire record is being read or written. If components of the records are being read or written, the input and output flows must be named, and these names must appear in the data composition of the store.

There is a special subclass of control flows called prompts , with special names ENABLE , DISABLE and TRIGGER , normally abbreviated to E , D and T . Enable and disable prompts are used to enable (turn on) or disable (turn off) destination processes. Triggers are used to single-shot a process, such as to sample an analogue signal. Enable and disable prompts can be combined as ENABLE/DISABLE or E/D .

Elements of the system's environment are shown as named rectangles, called terminators . Each has its own terminator description to describe its role and content. Terminators can be used at all levels of diagram for those flows entering the system from the environment, or going to it.

Except for the obvious restriction that a process cannot execute until it is enabled (if controlled by prompts) and runs only when all of its input data is present (so a chain of processes connected by flows will execute in series), all parts of a DFD conceptually execute in parallel.

Strengths

• Simply and effectively describes functionality and data exchange
• Allows data and control to be clearly distinguished
• Allows synchronous and asynchronous function couplings to be clearly shown
• Allows stored and buffered data to be clearly shown

Weaknesses

• Does not show time sequencing clearly
• Does not allow iterative cycles of functions to be shown easily
• Does not allow function outcomes (such as success or failure) to be shown, other than as control flows

Recommended Uses

• To show functionality and data exchange when time sequencing is either not of the essence or is meaningless
• To show functionality where there is both data and control
• To show functionality where there is buffered data
• To show functionality where control is best described by a finite-state-machine

Diagram Conversions

Implementation Model DFDs can be converted into Structure Charts (STCs). To convert a DFD, select Convert Type... from the Tools menu in the Diagram Editor.

The rules for the conversion are:

1. A master process must be selected in the DFD.
2. Each DFD process is converted into an STC module.
3. The master process has an off-page connector with the same name connected to it. All flows between the master process and the environment become couples associated with the call from the off-page connector to the module.
4. All stores are converted into global data areas.
5. or each process that interacts with a store, its associated module has a call to the store's global data area.
6. All un-named flows between processes and stores become couples between the module and the global data area, whose name is the same as the global data area. The couples are control couples if the flow was a discrete or continuous control flow, and are data couples if the flow was a discrete or continuous data flow.
7. All named flows between processes and stores become couples between the module and the global data area with the same name as the flow. The couples are control couples if the flow was a discrete or continuous control flow, and are data couples if the flow was a discrete or continuous data flow.
8. Calls are created between each process's corresponding module and the corresponding modules for all processes that the process exchanges flows with, starting at the master process. All flows between processes become couples, control couples if the flow was a discrete or continuous control flow, and are data couples if the flow was a discrete or continuous data flow.
9. All flows between non-master processes and the environment are ignored.
10. All flows to or from split gates and join gates are ignored.
11. Prompt control flows (control flows with any of the reserved names ENABLE , DISABLE , TRIGGER , E , D , T , ENABLE/DISABLE and E/D ) are ignored
12. The process specifications for the DFD processes are copied to become module specifications for the STC modules.

Characteristics

Linkage

Symbols

Back to top