Cradle from 3SL, the complete Model Based Systems Engineering Toolsuite, specialising in requirements management, requirements capture, model based systems engineering and for systems engineering software, support and consultancy, the logical choice: Cradle from 3SL.
login Register forgot password or username?
Search:         

Welcome to 3SL Reference Section

Data flow Diagram Data Flow Diagram (DFD)

Data Flow Diagram (DFD)

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

Converting DFDs

Implementation Domain DFDs can be converted into Structure Charts (STCs). To convert a DFD, select Convert to STC… from the Item pulldown menu:

Diagram Converter dialog

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 becomes couples associated with the call from the off-page connector to the module.
  4. All stores are converted into global data areas.
  5. For 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.

The specifications for the DFD processes are copied to become module specifications for the STC modules.

Converting a Data Flow Diagram to a Structure Chart
  1. From the DFD select Convert to STC… from the Item pulldown menu
  2. Choose the Scope as one of Item or With Definitions
  3. Select the model for the new STC by pressing the Choose Model… button

The chosen model is shown in the Diagram Converter dialog

  1. Enter the Number and Name for the STC to be created
  2. If required, check the Allow an existing item to be over-written checkbox
  3. Press the OK button to perform the conversion

The newly converted STC will be produced.

DFDs are hierarchical. Their connectivity is:

Diagram of the hierarchical connectivity of a Data Flow Diagram

DFDs are available in models in both the Essential and Implementation Domains.

Numbering of DFDs

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.

Symbols

An example DFD is:

Screenshot of a Data Flow Diagram

Prompts are discrete control flows with reserved names:

     
ENABLE or E - Activates a process
DISABLE or D - Deactivates a process
TRIGGER or T - Single-shot a process
ENABLE/DISABLE or E/D - Compound prompt flow

In the Implementation Domain DFDs can also contain:

  • Equipments from PADs - To show the hardware/software allocation of behaviour
  • Shared equipments from PADs - To show the hardware/software allocation of behaviour

The symbols available in DFDs are:

Symbol Name Description Definition Expansion
Comment Comment Makes a note anywhere in the diagram. Are always surrounded by * characters. None None
Data Process Data Process An active entity that is capable of processing information. Process
specification
BD
DFD
IDEF0
UCD
STC - (Implementation Domain only)
Data Store Data Store A named repository of data acting as a buffer between the real world and the system, or within it. Data definition None
Control Process Control Process An active entity that is capable of processing control or status signals and exercising control over other processes in the system. Process
specification
STD
BD
UCD
IDEF0
STC
Control Store Control Store A named buffer of a control or status signal, between the real world and the system. Data definition None
Split Gate Split Gate Used to divide incoming data into lower-level data items. None None
Join Gate Join Gate Used to rejoin lower-level data items into a higher-level item. None None
Environment 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 Equipment Represents a piece of hardware equipment within the system construct. Only available in the Implementation Domain. Process
specification
PAD
DFD
BD
UCD
Library Equipment Library Equipment Represents a piece of shared hardware equipment within the system construct. Only available in the Implementation Domain. Process
specification
PAD
Discrete Data Flow Discrete Data Flow A named flow of data. Data definition None
Continuous Data Flow Continuous Data Flow A named flow of data that is continually present, such as an analogue voltage. Data definition None
Discrete Control Flow Discrete Control Flow A control or status signal that carries no data, and is either present or not. Data definition None
Continuous Control Flow 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. Data definition None
Bidirectional Discrete Data Flow Bidirectional Discrete Data Flow A bidirectional named flow of data. Data definition None
Bidirectional Continuous Data Flow Bidirectional Continuous Data Flow A bidirectional named flow of data that is continually present, such as an analogue voltage. Data definition None
Bidirectional Discrete Control Flow Bidirectional Discrete Control Flow A bidirectional control or status signal that carries no data, and is either present or not. Data definition None
Bidirectional Continuous Control Flow 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. Data definition None
Boundary Point Boundary Point A connection point for the initial transition to enter the initial state. None None
Picture 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