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.
The 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.
An 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: