Data Flow Diagrams (DFDs)

Use a Data Flow Diagram (DFD) to show the relationships among the business processes within an organization to: external systems, external organizations, customers, other business processes. Method Data flow diagrams are used to describe how the system transforms information. They define how information is processed and stored and identify how the information flows through the processes. When building a data flow diagram, the following items should be considered: where does the data that passes through the system come from and where does it go, what happens to the data once it enters the system (i.e., the inputs) and before it leaves the system (i.e., the outputs), what delays occur between the inputs and outputs (i.e., identifying the need for data stores).
Components of a Data Flow Diagram

STEPS TO DRAW A DATA FLOWDIAGRAM Steps Start from the context diagram. Identify the parent process and the external entities with their net inputs and outputs. Place the external entities on the diagram. Draw the boundary. Identify the data flows needed to generate the net inputs and outputs to the external entities. Identify the business processes to perform the work needed to generate the input and output data flows. Connect the data flows from the external entities to the processes. Identify the data stores. Connect the processes and data stores with data flows. Apply the Process Model Paradigm to verify that the diagram addresses the processing needs of all external entities. Apply the External Control Paradigm to further validate that the flows to the external entities are correct. Continue to decompose to the nthlevel DFD. Draw all DFDs at one level before moving to the next level of decomposing detail. You should decompose horizontally first to a sufficient nth level to ensure that the processes are partitioned correctly; then you can begin to decompose vertically. Tips and Hints Consider creating a data access model to document the processes that create, update, and delete data in the system. As an alternative to functional decomposition, consider using a bottom-up approach when the details about the system are well known. When analyzing the business system under study in terms of its response to events (for example, user interaction with windowed systems), consider the following:
Using External Events to Build DFDs

See Also
Context Diagram Entity-Relationship Modelling

References Biehl, Rick. Data-Oriented Quality Solutions. DeMarco, Tom. Structured Analysis and System Specification. New York: Yourdon. Gane, Chris, and Sarson, Trish. Structured Systems Analysis: Tools and Techniques. Missouri: McDonnell Douglas. Martin, James, and McClure, Carma. Diagramming Techniques for Analysts and Programmers. Englewood Cliffs: Prentice-Hall. Martin, James. Information Engineering: Book II Planning and Analysis. Englewood Cliffs: Prentice-Hall. Peters, Lawrence. Advanced Structured Analysis and Design. Englewood Cliffs: Prentice-Hall. Topper, Andrew, Ouellette, Daniel and Jorgensen, Paul. Structured Methods: Merging Models, Techniques and CASE. New York: McGraw-Hill.

Diagramas de flujo de datos (DFD) Utilice un diagrama de flujo de datos (DFD) para mostrar las relaciones entre los procesos de negocio dentro de una organizacin a: Los sistemas externos, Las organizaciones externas, Los clientes, Los procesos de negocio. Mtodo diagramas de flujo de datos se utilizan para describir cmo funciona el sistema transforma la informacin. Definen cmo la informacin se procesa y se almacena y determinar cmo la informacin fluye a travs de los procesos. Cuando se construye un diagrama de flujo de datos, los siguientes elementos deben ser considerados: de dnde viene la informacin que pasa a travs del sistema viene y adnde va, Qu ocurre con los datos una vez que entra en el sistema (es decir, las entradas) y antes de que salga del sistema (es decir, las salidas), lo que los retrasos se producen entre las entradas y salidas (es decir, la identificacin de la necesidad de almacenes de datos). Componentes de un diagrama de flujo de datos Pasos para dibujar una FLOWDIAGRAM DATOS Pasos Iniciar en el diagrama de contexto. Identificar el proceso de los padres y las entidades externas con sus entradas y salidas netas. Coloque las entidades externas en el diagrama. Dibuja el contorno. Identificar los flujos de datos necesarios para generar las entradas y salidas netas de las entidades externas. Identificar los procesos de negocio para realizar el trabajo necesario para generar los flujos de entrada y salida de datos. Conecte los flujos de datos de las entidades externas a los procesos. Identificar los almacenes de datos. Conecte los procesos y los almacenes de datos con los flujos de datos. Aplicar el modelo de proceso de paradigma para verificar que el esquema de direcciones de las necesidades de procesamiento de todas las entidades externas. Aplicar el paradigma de control externo para validar, adems, que los flujos de las entidades externas son correctos. Continuar descomponerse en el DFD nthlevel. Dibujar todos los DFD en un nivel antes de pasar al siguiente nivel de descomposicin de los detalles. Usted debe descomponer horizontal primero en un nivel suficiente para garantizar la ensima que los procesos se reparten correctamente, entonces usted

puede comenzar a descomponerse en posicin vertical. Consejos y sugerencias Considere la posibilidad de crear un modelo de acceso a datos para documentar los procesos que crear, actualizar y eliminar datos en el sistema. Como alternativa a la descomposicin funcional, considere el uso de un enfoque de abajo hacia arriba cuando los detalles sobre el sistema son bien conocidas. Al analizar el sistema de negocio objeto de estudio en trminos de su respuesta a los eventos (por ejemplo, la interaccin del usuario con los sistemas de ventanas), considere lo siguiente: Utilizar eventos externos para construir DFD Vea tambin Diagrama de Contexto Modelado Entidad-Relacin

Components of Data Flow Diagrams

Whatever convention is used to construct the Data Flow Diagram, all DFDs are composed of the following components: EXTERNAL ENTITIES ON A DFD External entities are also known as terminators, sources/sinks, and actors. External entities define the sources and destinations of information entering and leaving the system. An external entity can be a person, system, or organization that has pre-defined behaviour. External entities are mandatory on context diagrams but optional on data flow diagrams. Description of External Entities External entities are components that interact with a business process on the DFD but fall outside of the boundaries of the DFD. External entities can be: initiators of data (i.e., spontaneous generators) flowing into the business process, end recipients of data (i.e., data sinks) flowing from the business process. Examples Examples of external entities include: End User, Purchasing Department, Inventory System. Drawing External Entities on a DFD Place external entities on the diagram with all data flows. To reduce the visual complexity of the drawing, an external entity can be used more than once on the same DFD. Draw a diagonal line across the lower-left corner of the external entity square to indicate another occurrence of the external entity elsewhere on the same DFD.

Document External Entities Provide a description of external entities to support the DFD. FLOWS Definition Flows define the interfaces between the components within the system, and the system and its external components.
Types of Flows

Flows that transport data around the data flow diagram are called data flows. Description of Data Flows Data flows are the pipelines through which data are transmitted between any two components on a DFD. The composition of data is known and defined in a data dictionary. A data flow is also called a data flow vector. Examples of data flows are: purchase order, customer profile, account number, product. Naming Data Flows Data flows must be given a name that describes the content of the data being transmitted and a description of the data flow listing the data elements. For example:

Data Flow Name:Employee Info, Description: Data elements: Information stored about an employee, Employee Name, Employee Date of Birth, Employee ID.

Bi-Directional Data Flows Bi-directional data flows are used only when the information flowing in each direction is identical. Data Flows with the Same Name Multiple data flows can have the same name on a DFD. When this occurs, the data transmitted in all of the flows with the same name must be identical. Complex Data Flows Data flows are described as complex when there is more than one data flow going in the same direction between any two entities. Name the complex data flow to encompass the contents of all the data flowing along the pipeline. Trivial Data Flows DFDs do not show trivial (relative to the specification of functional requirements) flows, such as error messages, keys for retrieving data from a data store, or data store updating instructions. Guidelines for Drawing Data Flows on a DFD Connect the data flows from/to external entities to/from business processes within the boundary of the DFD. Connect internal business processes to data stores and other internal processes with appropriate data flows. Label all data flows with care for they indicate the interface requirements for a process. Use descriptive names for labelling data flows. Ensure that all flows to external entities on lower level diagrams balance with data flows from external entities on upper level diagrams. In other words, a new data flow cannot be created at a lower level if it was not identified on an upper level diagram. Double-headed data flows are permitted when the data flowing in both directions are identical. Data flows from/to external entities to/from data stores are not permitted. All data must flow through a process. Be careful not to produce long names for complex data flows. As a rule of thumb, a DFD component (process, data store, or external entity) should not have more than seven data flows connected to it. Flows that access stored data are called access flows. Flows that are used to synchronize the system control flow and do not require data are called event flows. Common uses include starting, stopping, and changing the system status. Event flows are also known as control flows. Flows can be continuous or discrete. A discrete flow is only present for an instant of time. A continuous flow persists over time. Types of Flows Example:

Guidelines A data flow name should be a singular noun phrase (e.g., delivery list, customer information, credit limit). Naming access flows is optional. An event flow name should be a singular verb or noun phrase (e.g., start, stop, item available, processing complete). If a data flow contains multiple attributes (i.e., data elements), an attribute list should be provided. STORES Definition Stores represent information (i.e., data or control) at rest. Stores are used when different processes need to share information but are active at different times. Information can be written to a store and read from a store.
Types of Stores

Stores that contain data are called data stores. DATA STORES ON A DFD Identifying Data Stores Data stores are usually derived from the entities in an entity-relationship diagram. Creation of Data Stores Data stores are created to store information for later use. They represent data that is temporarily at rest between processes. For example, a data store is needed to store data that is generated on a daily basis but is required for a process that runs weekly. Local and Shared Data Stores Local data stores are data stores whose accesses are contained completely within the boundary of a DFD.

A data store crossing the boundary of a DFD process indicates that it is shared by processes on another DFD. Drawing Data Stores on a DFD A data store can be drawn on the same DFD more than once to reduce the visual complexity of the drawing. An extra vertical bar is drawn in the duplicated data stores to indicate that it appears elsewhere on the same diagram. Stores that contain status or control information are called event stores. Event stores are used to save events that have occurred but have not yet been used. Unlike a data store, an event store has behaviour associated with it which is not apparent when looking at the data flow diagram. If the system accesses an event store and the event has not occurred, the system will be suspended until the event occurs. Once an event has occurred, accessing it will remove it from the event store. Types of Stores Example

Guidelines The data stores on the data flow diagram map to the entities on the entity-relationship diagram. Minimize the use of event stores on the DFD. Try using flags instead. PROCESSES Definition Processes are also known as data transforms. Processes transform input flows into output flows in a defined manner. A process is a distinct activity (or set of activities) described by its inputs and outputs. A process describes a unique behaviour that has a beginning and an end. A process is performed repeatedly.
Types of Processes

A data process transforms input data into output data. Data processes act directly on data, either from flows or stores. They represent the functionality of the system. A control process transforms input events into output events and is used on a data flow diagram to indicate the presence of a state transition diagram. Control processes cannot transform data but can control processes that do. A state transition diagram describes the behaviour of the control process. Types of Processes Example

Guidelines

A process name and number must be unique. A process can only exist once on a data flow diagram. A process must have at least one input and one output. In other words, a process is asked (i.e., triggered) to do something and then must deliver (i.e., respond). A data process cannot input or output discrete event flows (i.e., a data process should not control the system, it should do the work). A control process cannot input or output data flows (i.e., a control process should control the system, not do the work). A process name should start with an active verb (e.g., Produce Items, Control Production). A process exists to do something (i.e., transform input flows into output flows), therefore a process must have an incoming set of requirements to which it must conform. An nth-level (i.e., next level of detail) data flow diagram must describe its parent process. An nth-level data flow diagram is a decomposition of its parent process and cannot introduce new functionality. Notation There are several conventions used to depict the DFD. NOTATION ON A DATA FLOW DIAGRAM Gane and Sarson The notation described below and used in this technique was popularized by Gane and Sarson: Round-ended rectangles represent processes. Squares identify external entities. Arrows indicate flows. Open-ended rectangles identify stores. Diagonal line across the lower-left corner of an external entity square indicates it appears elsewhere on the same DFD.

 Extra diagonal line on a data store rectangle indicates it appears elsewhere on the same DFD. Double-headed arrow indicates the same data flowing in both directions. Yourdon, DeMarco, and Others Another notation popularized by Yourdon, DeMarco, and others is described below: Circles represent processes. Squares identify external entities. Arrows indicate flows. Rectangles open on both ends identify stores. Extensions To support the use of DFDs in describing how systems respond to events, the notation has been extended to include the control-oriented information typically needed to describe real-time systems. The widely adopted convention is to represent the control components using dashed lines. The extensions apply to both notations described above.

Cualquiera que sea la convencin se utiliza para construir el diagrama de flujo de datos, todos los DFD se componen de los siguientes componentes: ENTIDADES EXTERNAS EN DFD Las entidades externas son tambin conocidos como terminaciones, las fuentes y los sumideros, y los actores. Las entidades externas definir las fuentes y los destinos de la informacin que entra y sale del sistema. Una entidad externa puede ser una persona, sistema o la organizacin que tiene un comportamiento predefinido. Las entidades externas son obligatorios en los diagramas de contexto, pero es opcional en los diagramas de flujo de datos. Descripcin de las entidades externas Las entidades externas son componentes que interactan con un proceso de negocio en el DFD, pero quedan fuera de los lmites de la DFD. Las entidades externas pueden ser: iniciadores de datos (es decir, generadores espontnea) que desembocan en el proceso de negocio, los destinatarios finales de los datos (es decir, los sumideros de datos) se derivan de los procesos de negocio. Ejemplos Ejemplos de entidades externas incluyen: Usuario final, Departamento de Compras, Sistema de Inventario. Dibujo de entidades externas en un DFD Coloque las entidades externas en el diagrama con todos los flujos de datos. Para reducir la complejidad visual del dibujo, una entidad externa se puede utilizar ms de una vez en el DFD mismo. Dibuje una lnea diagonal a travs de la esquina inferior izquierda de la entidad externa corchetes para indicar otra ocurrencia de la entidad externa a otra parte en el DFD mismo. Documento de entidades externas Proporcionar una descripcin de las entidades externas para apoyar el DFD. FLUJOS Definicin Flujos de definir las interfaces entre los componentes dentro del sistema, y el sistema y sus componentes externos. Tipos de flujos Flujos de transporte de datos en todo el diagrama de flujo de datos se llaman los flujos de datos. Descripcin de los flujos de datos Los flujos de datos son los conductos por los que los datos se transmiten entre dos componentes de un DFD. La composicin de los datos es conocido y definido en un diccionario de datos.

Un flujo de datos tambin se conoce como un vector de flujo de datos. Ejemplos de flujos de datos son: orden de compra, perfil de cliente, nmero de cuenta, producto. De nombres de flujos de datos Los flujos de datos se debe dar un nombre que describe el contenido de los datos transmitidos y una descripcin de los datos de flujo que enumera los elementos de datos. Por ejemplo: Nombre de flujo de datos: Informacin del empleado, Descripcin: La informacin almacenada sobre un empleado, Elementos de datos: Nombre del empleado, Empleado Fecha de Nacimiento, Id. de empleado. Los datos bidireccional Flujos los flujos de datos bidireccional slo se utilizan cuando la informacin fluye en ambas direcciones es idntico. Flujos de datos con el mismo nombre Mltiples flujos de datos puede tener el mismo nombre en un DFD. Cuando esto ocurre, los datos transmitidos en todos los flujos con el mismo nombre debe ser idntico. Los flujos de datos complejos Los flujos de datos se describen como complejo cuando hay ms de un flujo de datos va en la misma direccin entre dos entidades. Nombre del flujo de datos complejos para abarcar el contenido de todos los datos que fluyen a lo largo de la tubera. Los flujos de datos Trivial DFD no muestran triviales (en relacin a la especificacin de requisitos funcionales), flujos, tales como mensajes de error, las claves para recuperar datos de un almacn de datos o almacn de datos de la actualizacin de las instrucciones. Directrices para la elaboracin flujos de datos en un DFD Conecte los flujos de datos desde / a entidades externas a / de los procesos de negocio dentro de los lmites de la DFD. Conecte los procesos internos de negocios a los almacenes de datos y otros procesos internos con los flujos de datos apropiadas. Etiquete todos los flujos de datos con cuidado para que indique los requisitos de interfaz para un proceso. Utilice nombres descriptivos para el etiquetado de los flujos de datos. Asegrese de que todas las corrientes a entidades externas en el nivel ms bajo balance de diagramas con los flujos de datos de entidades externas en los diagramas de nivel superior. En otras palabras, un flujo de nuevos datos no se pueden crear en un nivel inferior si no fue identificado en un diagrama de nivel superior. Dos puntas flujos de datos se permite cuando el flujo de datos en ambas direcciones son idnticas. Los flujos de datos desde / a entidades externas a / desde los almacenes de datos no estn permitidos. Toda la informacin debe fluir a travs de un proceso. Tenga cuidado de no producir los nombres largos de los flujos de datos complejos. Como regla general, un componente DFD (procesar, almacenar datos o entidad externa) no debe tener ms de siete flujos de datos conectados a l. Flujos que de acceso a datos almacenados se denominan flujos de acceso. Los flujos que se utilizan para sincronizar el flujo de control del sistema y no requieren de datos se denominan flujos de eventos. Las aplicaciones comunes incluyen iniciar, parar y cambiar el estado del sistema. los flujos de eventos tambin son conocidos como los flujos de control. Los flujos pueden ser continuos o discretos. Un flujo discreta slo est presente por un instante de tiempo. Un flujo continuo persiste en el tiempo. Ejemplo de tipos de flujos:

Directrices Un nombre de flujo de datos debe ser un sintagma nominal singular (por ejemplo, la lista de distribucin, informacin al cliente, lmite de crdito). De nombres de los flujos de acceso es opcional. Un nombre de flujo del evento debe ser un verbo en singular o sintagma nominal (por ejemplo, iniciar, detener, artculo disponible, el tratamiento completo). Si un flujo de datos contiene varios atributos (es decir, los elementos de datos), una lista de atributos deben ser proporcionados. TIENDAS Definicin Tiendas de representar la informacin (es decir, de datos o de control) en reposo. Las tiendas se utilizan cuando los diferentes procesos necesidad de compartir informacin, pero son activos en diferentes momentos. La informacin puede ser escrita a una tienda y leer de una tienda. Tipos de tiendas Las tiendas que contienen datos son llamados almacenes de datos. Almacena los datos en un DFD La identificacin de almacenes de datos Los almacenes de datos suelen ser derivados de las entidades en un diagrama de entidad-relacin. Creacin de almacenes de datos Los almacenes de datos se crean para almacenar informacin para su uso posterior. Representan los datos que se encuentra temporalmente en reposo entre los procesos. Por ejemplo, un almacn de datos es necesario para almacenar datos que se generan a diario, pero se requiere de un proceso que se ejecuta cada semana. Local y de datos compartidos Tiendas almacenes de datos locales son almacenes de datos cuyos accesos se encuentran totalmente dentro de los lmites de un DFD. Un almacn de datos de cruzar el lmite de un proceso DFD indica que es compartida por los procesos en otro DFD. Dibujo de almacenes de datos en un DFD Un almacn de datos se pueden dibujar en el DFD ms de una vez para reducir la complejidad visual del dibujo. Una barra vertical adicional se dibuja en los almacenes de datos duplicados para indicar que aparece en otra parte en el mismo diagrama. Las tiendas que contienen informacin de control de estado o se llaman las tiendas evento. tiendas de eventos se utilizan para guardar los eventos que han ocurrido pero que an no se ha utilizado. A diferencia de un almacn de datos, un almacn de evento tiene un comportamiento asociado a l que no es evidente al observar el diagrama de flujo de datos. Si el sistema tiene acceso a un almacn de evento y el evento no ha ocurrido, el sistema ser suspendido hasta que se produzca el evento. Una vez que un evento ha ocurrido, para acceder a l se lo quite de la tienda evento. Tipos de tiendas Ejemplo Directrices Los almacenes de datos en el mapa diagrama de flujo de datos a las entidades en el diagrama de entidad-relacin. Minimizar el uso de tiendas de eventos en el DFD. Trate de usar banderas en su lugar. PROCESOS Definicin Los procesos son tambin conocidos como datos transforma. Procesos de transformacin de los flujos de entrada en los flujos de salida de una manera definida. Un proceso es una actividad independiente (o conjunto de actividades), descrito por sus entradas y salidas. Un proceso describe un comportamiento nico que tiene un principio y un fin. Un proceso se lleva a cabo en varias ocasiones. Tipos de Procesos Un proceso de datos transforma los datos de entrada en los datos de salida. Datos de los procesos de actuar directamente en los datos, ya sea de los flujos o almacenes. Representan la funcionalidad del sistema.

Un proceso de control de eventos de entrada se transforma en eventos de salida y se utiliza en un diagrama de flujo de datos para indicar la presencia de un diagrama de transicin de estado. procesos de control no puede transformar los datos, pero puede controlar los procesos que lo hacen. Un diagrama de transicin de estados describe el comportamiento del proceso de control. Ejemplo de tipos de procesos Directrices A nombre del proceso y el nmero debe ser nico. Un proceso slo puede existir una vez en un diagrama de flujo de datos. Un proceso debe tener por lo menos una entrada y una salida. En otras palabras, un proceso que se le pide (es decir, activa) para hacer algo y luego tiene que entregar (es decir, responder). Un proceso de datos no puede de entrada o salida de flujos de eventos discretos (es decir, un proceso de datos no debe controlar el sistema, debe hacer el trabajo). Un proceso de control no puede datos de entrada o salida de flujos (es decir, un proceso de control debe controlar el sistema, no el trabajo). A nombre del proceso debe comenzar con un verbo activo (por ejemplo, producir artculos, Control de Produccin). Existe un proceso para hacer algo (es decir, transformar los flujos de entrada en los flujos de salida), por lo tanto un proceso debe tener un conjunto de requisitos de entrada a los que se deben cumplir. Un ensimo nivel (es decir, el siguiente nivel de detalle) Diagrama de flujo de datos debe describir su proceso padre. Un diagrama ensimo nivel de flujo de datos es una descomposicin de su proceso padre y no puede introducir nuevas funcionalidades. Notacin Hay varias convenciones utilizadas para representar el DFD. Anotacin en un diagrama de flujo DATOS Gane y Sarson La notacin se describe a continuacin y se utiliza en esta tcnica fue popularizada por Gane y Sarson: Ronda de composicin rectngulos representan los procesos. Plazas Identificar las entidades externas. Las flechas indican los flujos. composicin abierta rectngulos identificar las tiendas. La lnea diagonal en la esquina inferior izquierda de un cuadrado entidad externa indica que aparece en otra parte del DFD mismo. Lnea de Extra diagonales en un rectngulo de almacn de datos indica que aparece en otra parte del DFD mismo. flecha con dos puntas indica la misma informacin que fluye en ambas direcciones. Yourdon, DeMarco, y otros Otra notacin popularizado por Yourdon, DeMarco, y otros se describe a continuacin: Los crculos representan procesos. Plazas Identificar las entidades externas. Las flechas indican los flujos. Rectngulos abierta en ambos extremos identificar las tiendas. Extensiones Para apoyar el uso de DFD en la descripcin de cmo los sistemas de responder a los eventos, la notacin se ha ampliado para incluir la informacin de control orientado normalmente se necesitan para describir sistemas de tiempo real. La convencin ampliamente adoptada para representar los componentes de control con lneas discontinuas. Las extensiones se aplican tanto a anotaciones descrito anteriormente.

Using External Events to Derive Data Flow Diagrams

Identify the external events (from the event list) that have a data event classification. Data events cause data to be transformed. A data flow diagram is used to describe this type of behaviour. An external event may have multiple classifications. If one of the external event's classifications is "D" (i.e., data event) then a data flow diagram is used to model the data transformation component of the system response. USING EXTERNAL EVENTS TO IDENTIFY PROCESSES The event response can be used to determine the required behaviour and name of a process. Responses and processes are not necessarily at the same level of abstraction. Responses that represent low-level activities must be grouped into related processes. Responses that represent highlevel functions must be decomposed into low-level processes. Group related responses together. Responses can be related by the activities that they perform (i.e., if responses do the same things you may want to group them together). Responses can also be related by the data that they use (i.e., if responses use the same data you may want to group them together). If there are multiple responses to an event, multiple processes may be required. If an event has multiple responses and each response processes different data, then a different process should be created for each response since each process will use different data flows and data stores. Separating the processes will simplify their interfaces. Different processes should also be created when different external events have similar responses but process different data. The same process may be used by different responses as long as the process's behaviour and data requirements are the same for each event. USING EXTERNAL EVENTS TO GROUP PROCESSES You can also use external events to group related processes (i.e., identify parent processes). Identify control events (i.e., the events that use a state transition diagram to describe the system's response). State transition diagrams describe processing sequence, therefore the processes controlled by a state transition diagram should be grouped together with the control process that prompts (i.e., controls) them. Identify the data processes controlled by a control process. Group the data processes and the control process together under the same parent process.

Identificar los eventos externos (de la lista de eventos) que tienen una clasificacin de datos de evento. Eventos ocasionar que los datos se transforman. Un diagrama de flujo de datos se utiliza para describir este tipo de comportamiento. Un evento externo puede tener mltiples clasificaciones. Si una de las clasificaciones del evento externo es "D" (caso por ejemplo, datos), entonces se utiliza un diagrama de flujo de datos para modelar el componente de transformacin de datos de la respuesta del sistema. USO DE EVENTOS EXTERNOS PARA IDENTIFICAR LOS PROCESOS La respuesta de eventos se puede utilizar para determinar el comportamiento que se requiere y el nombre de un proceso. Las respuestas y los procesos no estn necesariamente en el mismo nivel de abstraccin. Las respuestas que representan las actividades de bajo nivel deben ser agrupados en los procesos relacionados. Las respuestas que representan funciones de alto nivel debe ser descompuesto en procesos de bajo nivel. Grupo relacionado con las respuestas juntos. Las respuestas pueden ser relacionados con las actividades que realizan (es decir, si las respuestas de hacer las mismas cosas que usted lo desea,

puede agruparlas). Las respuestas tambin puede estar relacionado con los datos que uso (es decir, si las respuestas de utilizar los mismos datos que usted lo desea, puede agruparlas). Si hay mltiples respuestas a un evento, varios procesos que sean necesarios. Si un evento tiene varias respuestas y cada respuesta de procesos de datos diferentes, entonces un proceso diferente se debe crear para cada respuesta, ya que cada proceso se utilizan diferentes flujos de datos y almacenes de datos. La separacin de los procesos se simplifican sus interfaces. Diferentes procesos Asimismo, debe crearse cuando diferentes eventos externos tienen respuestas similares, pero los datos de proceso diferentes. El mismo proceso puede ser utilizado por diferentes respuestas, siempre y cuando el comportamiento del proceso y los requisitos de datos son los mismos para cada evento. USO DE EVENTOS EXTERNOS PARA GRUPO DE PROCESOS Tambin puede utilizar los eventos externos al grupo de procesos relacionados (es decir, identificar los procesos de los padres). Identificar los eventos de control (es decir, los eventos que el uso de un diagrama de transicin de estados para describir la respuesta del sistema). diagramas de transicin de estado describen la secuencia de procesamiento, por lo tanto los procesos controlados por un esquema de transicin del estado deben agruparse con el proceso de control que le pide (es decir, los controles de) ellos. Identificar los datos de los procesos controlados por un proceso de control. Grupo de procesos de datos y el proceso de control junto con el proceso mismo padre.