DFD (Data Flow Diagrams)

DFD Principles:

• The general principle in Data Flow Diagramming is that a system can be decomposed into subsystems, and subsystems can be decomposed into lower level subsystems, and so on.
• Each subsystem represents a process or activity in which data is processed. At the lowest level, processes can no longer be decomposed.
• Each 'process' (and from now on, by 'process' we mean subsystem and activity) in a DFD has the characteristics of a system.
• Just as a system must have input and output (if it is not dead), so a process must have input and output.
• Data enters the system from the environment; data flows between processes within the system; and data is produced as output from the system.

Data Flow Diagrams show:

• The processes within the system.
• The data stores (files) supporting the system's operation.
• The information flows within the system.
• The system boundary.
• Interactions with external entities.

DFD Notations:

• Processes, in other methodologies, may be called 'Activities', 'Actions', 'Procedures', 'Subsystems' etc.They may be shown as a circle, an oval, or (typically) a rectangular box.
• Data are generally shown as arrows coming to, or going from the edge of a process box.
  (Note that there is no 'Decision' symbol. A decision is a Process).

General Data Flow Rules:

1. Entities are either 'sources of' or 'sinks' for data input and outputs - i.e. they are the originators or terminators for data flows.
2. Data flows from Entities must flow into Processes.
3. Data flows to Entities must come from Processes.
4. Processes and Data Stores must have both inputs and outputs (What goes in must come out!).
5. Inputs to Data Stores only come from Processes.
6. Outputs from Data Stores only go to Processes.

Symbols:

Processes transform or manipulate data. Each box has a unique number as identifier (top left) and a unique name (an imperative - e.g. 'do this' - statement in the main box area) The top line is used for the location of, or the people responsible for, the process. Processes are 'black boxes' - we don't know what is in them until they are decomposed Processes transform or manipulate input data to produce output data. Except in rare cases, you can't have one without the other.

Nota: Nosotros lo representamos con un circulo y el numero identidicador lo ponemos en la parte superior central del mismo. (Aunque me parece mas prolijo de esta forma, pero va en gustos).

Data Flows depict data/information flowing to or from a process. The arrows must either start and/or end at a process box. It is impossible for data to flow from data store to data store except via a process, and external entities are not allowed to access data stores directly. Arrows must be named. Double ended arrows may be used with care .

Nota: Habla de usar las flechas bidireccionales con cuidado, en clases se explico que se utilizan cuando el intercambio de datos transcurre al mismo tiempo.

External Entities , also known as 'External sources/recipients, are things (eg: people, machines, organisations etc.) which contribute data or information to the system or which receive data/information from it.

The name given to an external entity represents a Type not a specific instance of the type.

When modelling complex systems, each external entity in a DFD will be given a unique identifier. It is common practice to have duplicates of external entities in order to avoid crossing lines, or just to make a diagram more readable.

Nota: Bueno, lo vamos a representar con un rectangulo por lo general, el identificador unico no lo usamos y si vamos a usar el duplicado de lo mismos para evitar cruzar lineas porque el diagrama tiene que ser lo mas entendible posible.

Data Stores are some location where data is held temporarily or permanently.
In physical DFDs there can be 4 types.
D = computerised Data
M = Manual, e.g. filing cabinet.
T = Transient data file, e.g. temporary program file
T(M) = Transient Manual, e.g. in-tray, mail box.

As with external entities, it is common practice to have duplicates of data stores to make a diagram less cluttered.



Nota: Las bases de datos como las damos con gustavo no las vamos a especificar tanto simplemente escribimos el nombre de esta entre dos lineas perpendiculares.







DFD Levels
The Context and Top Level diagram by themselve are not enough; they only provide a high level description. On the other hand, the initial diagrams do start to break down, decompose, what might be quite a complex system into manageable parts.
Each Process box in the Top Level diagram will itself be made up of a number of processes, and will need to be decomposed as a second level diagram.
Any box in the second level decomposition may be decomposed to a third and then a fourth level. Very complex systems may possibly require decomposition of some boxes to further levels.
Decomposition stops when a process box can be described with an Elementary Process Description using ordinary English, later on the process will be described more formally as a Function Description using, for example, pseudocode.

Nota: Nosotros vamos a trabajar dos capas (y en caso de que buscaramos descomponerlo todo lo posible seria hasta que se pueda describir usando español simple jajaja).

Webgrafia:

http://www.cems.uwe.ac.uk/~tdrewry/dfds.htm

Notas: Damian Merino