A DFD 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 one process with the exchanges of information between it and its environment.
Functionality is shown 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 description, held in a specification.
Processes that operate on data and/or control flows are called data processes. They have a description and can be decomposed into a lower-level diagram that refines 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. Each flow is described in a 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 part 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 asynchronously 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 an @ 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 rectangles. Each has an environment description to describe its role and content. Environment symbols 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.
DFDs are hierarchical. Their connectivity is:
DFDs are available in models in both the Essential and Implementation Domains.
Numbering of DFDsThe numbering system is dot-decimal. The Context Diagram is numbered C, the child of the Context Diagram is numbered 0, the Preliminary Diagram is numbered P and a subtree below P is numbered P.nnn.
SymbolsAn example DFD is:
Prompts are discrete control flows with reserved names:
In the Implementation Domain DFDs can also contain:
The symbols available in DFDs are:
| Symbol | Name | Description | Definition | Expansion |
|---|---|---|---|---|
 | Comment | Makes a note anywhere in the diagram. Are always surrounded by * characters. Note: If you do not want Cradle to automatically add an * go to the Graphics Settings section of Project Setup and turn off the Automatically add asterisks to diagram's comment symbols option. | None | None |
 | Data Process | An active entity that is capable of processing information. | Equipment specification | BD DFD IDEF0 UCD STC - (Implementation Domain only) |
 | Control Process | An active entity that is capable of processing control or status signals and exercising control over other processes in the system. | Equipment specification | STD BD UCD IDEF0 STC - (Implementation Domain only) |
 | Split Gate | Used to divide incoming data into lower-level data items. | None | None |
 | Data Store | A named repository of data acting as a buffer between the real world and the system, or within it. | Store data definition | None |
 | Control Store | A named buffer of a control or status signal, between the real world and the system. | Store data definition | None |
 | Join Gate | Used to rejoin lower-level data items into a higher-level item. | None | None |
 | Boundary Point | A connection point for the initial transition to enter the initial state. | None | None |
 | Environment | An element of the real world that is outside the system but that interacts with it. Environments are normally only shown on the Context Diagram and DFD 0, although Cradle imposes no such restrictions. | Environment | None |
 | Equipment | Represents a piece of hardware equipment within the system construct. Only available in the Implementation Domain. | Equipment specification | PAD DFD BD UCD IDF |
 | Library Equipment | Represents a piece of shared hardware equipment within the system construct. Only available in the Implementation Domain. | Equipment specification | PAD |
 | Internal Port | The internally-visible side of an interface which cannot be embedded in an equipment. Only available in the Implementation Domain. | Port specification | None |
 | Picture | Allows you to choose the location of a GIF or JPEG image to be displayed as a diagram symbol or to be embedded in an existing diagram symbol. | None | None |
 | Discrete Data Flow | A named flow of data. | Flow data definition | None |
 | Continuous Data Flow | A named flow of data that is continually present, such as an analogue voltage. | Flow data definition | None |
 | Discrete Control Flow | A control or status signal that carries no data, and is either present or not. | Flow data definition | None |
 | Continuous Control Flow | A control or status signal that carries no data but is significant when in one or two levels. These flows may be raised or lowered. | Flow data definition | None |
 | Bidirectional Discrete Data Flow | A bidirectional named flow of data. | Flow data definition | None |
 | Bidirectional Continuous Data Flow | A bidirectional named flow of data that is continually present, such as an analogue voltage. | Flow data definition | None |
 | Bidirectional Discrete Control Flow | A bidirectional control or status signal that carries no data, and is either present or not. | Flow data definition | None |
 | Bidirectional Continuous Control Flow | A bidirectional control or status signal that carries no data but is significant when in one or two levels. These flows may be raised or lowered. | Flow data definition | None |
 | Item | Represents a requirement or system note in the diagram. | None | None |
 | Context Item | Represents a requirement or system note in a diagram and is a container within which other object symbols can be drawn or attached. | None | None |
 | Cross Reference Link | Represents a cross reference that exists between a pair of system notes/requirements. It can also represent a cross reference between a system note/requirement and a specification or data definition or system that describes the objects symbols that it connects. | None | None |