1 Diagramas de Flujo de Datos

1.1 Concepto

Los diagramas de flujos de datos (DFD), es una técnica de modelización, que

nos muestra un sistema como una red de procesos conectados entre ellos por

flujos y almacenamientos de datos. Es un modelo que proporciona el punto de

vista funcional de un sistema.

1.2 ¿Por qué análisis de flujo de datos?

Los analistas deben trabajar con los usuarios para hacerles comprender el

funcionamiento del sistema actual y el sistema futuro, para ello se hace

aconsejable utilizar un lenguaje común, sencillo y fiable, estas son las

características de los diagramas de flujo de datos. Los usuarios pueden hacer

sugerencias para modificar los diagramas con la finalidad de describir las

actividades con mayor exactitud, y permitirá evitar los errores desde el inicio

pudiendo prevenir una posible falla del sistema.

1.3 Notación de los Diagrama Flujo de Datos

Los métodos para el análisis de flujo de datos fueron desarrollados y

promovidos por dos organizaciones al mismo tiempo, Yourdon Inc (compañía

de consultoría) y Mc Donnell-Douglas (Gane and Sarson). En nuestro libro la

notación utilizada será la de Yourdon. Los DFD’s se pueden dibujar con sólo

cuatro elementos gráficos sencillos, que son:

Procesos: El primer componente del DFD. El proceso muestra una

parte del sistema que transforma entradas en salidas, suelen ser

personas, procedimientos o dispositivos que utilizan o transforman

datos. El proceso se representa gráficamente como un círculo. Los

sinónimos comunes son burbuja, función o transformación.

figura 1: Proceso

Flujo de datos: Se representa gráficamente por medio de una flecha

que entra o sale de un proceso. El flujo se usa para describir el

movimiento de bloques de información de una parte del sistema a otra.

Por ello, los flujos representan datos en movimiento, mientras que los

almacenes representan datos en reposo. En algún modelo puede

representar movimiento de material. Los flujos muestran la dirección;

según si los datos se está moviendo hacia adentro o hacia afuera de un

proceso (o ambas cosas).

Podemos hablar de varios tipos de flujos de datos:

Según dirección/sentido de los datos, respecto al proceso:

Entrada.

r

Salida.

Diálogo (Entrada y Salida).

Divergente, Convergente.

Cuando una misma información se envía a procesos diferentes, o cuando una

Información compleja se descompone en varios datos más sencillos cada uno

de los cuales va a un proceso diferente (divergente). Varios paquetes de datos

se juntan para formar parte de paquetes de datos mas complejos

(convergente).

Almacén de datos: El almacén se utiliza para modelar una colección

de datos en reposo. Se representa por dos líneas paralelas. Es tentador

asociar a los almacenes los archivos o bases de datos, es así como a

menudo se implantan en un sistema informático, pero un almacén

también puede consistir en datos almacenados en cualquier soporte

que contenga datos (archivos de papel, tarjetas etc).

Entidad (Terminador): El siguiente componente del DFD es un

terminador; representado gráficamente como un rectángulo representan

fuentes (origen) o destinos externos de datos que pueden ser:

personas, programas, organizaciones u otras entidades que interactúan

con el sistema pero se encuentran fuera de su frontera. En algunos

casos, un terminador puede ser otro sistema con el cual se comunica

éste.

Existen tres cosas importantes que debemos recordar acerca de los

terminadores:

Son externos al sistema que se está modelando ; los flujos que conectan

los terminadores a diversos procesos (o almacenes) en el sistema

representan la interfaz entre él y el mundo externo.

El analista de sistemas no puede modificar los contenidos, la

organización ni los procedimientos internos asociados en posibilidades

de cambiar los contenidos de un terminador o la manera en que trabaja.

El terminador con lo que representa está fuera del dominio.

Las relaciones existentes entre los terminadores no se muestran en el

modelo DFD. Si existen relaciones entre los terminadores y si es

esencial para el analista modelarlos para poder documentar los

requerimientos y si es esencial para el analista modelarlos para poder

documentar los requerimientos del sistema, entonces ,por definición ,los

terminadores son en realidad parte del sistema y debieran modelarse

como procesos.

Deberemos respondernos una serie de preguntas como ¿cómo se piden los

datos?,

¿en qué secuencia se reciben los datos?, ¿en qué secuencia se generan?, no

deben ser respuesta de los DFD´s, estas respuestas forman parte del

procedimiento. Cada componente en un diagrama de flujo de datos tiene una

etiqueta con un nombre descriptivo. Los nombres de los procesos también

reciben un número para poder identificarlo.

Los diagramas de flujo de datos se concentran en el movimiento de datos a

través del sistema, no en los dispositivos o el equipo. Se identifican y describen

los datos que fluyen por todo el sistema, explicando porque los datos entran o

salen y cual es el procesamiento que se realiza con ellos (guardan y recuperan

de almacenamiento de datos).

1.4 Directrices para la construcción de DFD´s

Hay una serie de reglas que son necesarias para poder construir los DFD's

correctamente. La finalidad de estas reglas es ayudar a confeccionar DFD`s

correctos, y permitir dibujar un DFD agradable a la vista y por tanto que tenga

mas probabilidades de que sea estudiado por el usuario con el objetivo de

ayudarle a su comprensión.

Las reglas a seguir para la construcción de un DFD son:

1. Elegir los nombres representativos para los procesos, flujos de datos,

almacenamientos y entidades externas de forma que describa lo mas

precisamente posible al objeto que representa. En el caso de los procesos

debemos identificar las funciones que el sistema está llevando a cabo, es decir

el nombre del proceso describirá lo que se hace:

o Función: Verbo + objeto.

o Verbo significativo (Validar, Registrar etc).

o Evitar palabras de uso exclusivo por parte de usuario.

o Evitar terminología informática (Rutina,Procedimiento etc).

2. Numerar los procesos para identificarlos de forma rápida y unívoca.

Los números no indican secuencia. El modelo de DFD es una red de procesos

asincrónicos que se intercomunican, lo cual es, una representación precisa de

la manera en la realidad muchos sistemas operan. El hecho que exista

procesos no pueda realizar su función por falta de algún dato de otro proceso

no implica correspondiente con la numeración. Son la base para crear la

jerarquía de diagramas cuando se introduzcan los diagramas de flujo por

niveles.

3. Evitar DFD excesivamente complejos y recargados, es decir, con muchos

elementos gráficos juntos. El propósito de un DFD es modelar de forma precisa

las funciones que deben llevar a cabo un sistema y las interacciones entre

ellas. Pero otro propósito del DFD, de igual importancia, es que sea leído y

comprendido, no sólo por el analista que construyo el modelo, sin por los

usuarios que sean los expertos en la materia de aplicación. Esto significa que

el diagrama debe ser fácilmente entendido, fácilmente asimilado y placentero a

la vista.

Existe una excepción, un DFD conocido como diagrama de contexto, que

representa el sistema entero como un solo proceso y destaca las interfaces

entre el sistema y los terminadores externos.

4. Consolidar flujos para ganar en legibilidad.

5. Redibujar el DFD tantas veces como sea necesario, con el objetivo de:

o Conseguir un DFD técnicamente correcto.

o Aceptado por el usuario

o Estar lo suficientemente bien dibujado como para que no sea

embarazoso mostrarlo a la dirección de la organización.

6. Asegurarse que el DFD es consistente.

Existen reglas para asegurar la consistencia del DFD con otros modelos de

sistemas ; el diagrama de entidad-relación, diagrama transción de estados,

diccionario de datos, y la especificación de procesos. Las principales reglas de

consistencia son :

o Evite sumideros infinitos, procesos que tienen entradas pero no salidas.

o Evite burbujas de generación espontánea, procesos que tienen salidas

sin tener entradas. Situación normalmente incorrecta.

o Cuidado con flujos y procesos no etiquetados, ya que puede esconder

errores importantes.

o Tener cuidado con los almacenes de “sólo lectura” o “sólo escritura”.

ya que todo almacenamiento debe tener un flujo entrante y uno saliente,

es decir, la información se almacena se consume.

o Las entidades externas no pueden acceder directamente a ningún

almacenamiento. Siempre debe mediar un proceso que haga de

intermediario y extraiga o inserte la información pertinente.

1.5 Niveles de un DFD

Cuando nos enfrentemos ante un modelo real, nos enfrentaremos ante un DF

grande y complejo. Deberemos evitar diagramas complejos y poco legibles, de

acuerdo pero ¿cómo ?. Si el sistema es intrínsecamente complejo y tiene

decenas de funciones que?.

La respuesta es organizar el DFD global en una serie de niveles de modo que

cada uno proporcione sucesivamente más detalles sobre una porción del nivel

anterior. Esto es análogo a la organización de mapas en una atlas, de modo

que un mapa global nos muestra un país completo, pero los mapas

subsecuentes mostrarían los detalles de los países individuales, los estados

individuales dentro de los países.

La división consiste en construir una jerarquía de diagramas, en donde cada

nivel inferior es una expansión de un proceso del nivel superior.

El DFD de primer nivel consta de una sola burbuja, y representa el sistema de

información completo, como un todo; los flujos de datos muestran las interfaces

entre el sistema y las entidades externas. Este DFD especial se conoce como

diagrama de contexto o nivel 0.

El nivel 1, que sería el siguiente nivel inferior en la jerarquía, descompondría

ese macro proceso, que representa a todo el sistema, en las actividades

principales que lo componen, así como los almacenamientos generales que

existan. A continuación se sigue el de modo que se construirá una jerarquía de

diagramas, en donde cada nivel inferior es una expansión de un proceso del

nivel superior.

1.6 Construcción de los niveles del DFD

Como podemos ver lo que se pretende es descomponer un todo en piezas con

el objetivo de reducir la complejidad. Pero debemos responder una serie de

cuestiones:

1. ¿Cómo saber cuantos niveles debe haber en un DFD?

No hay ninguna regla para decidir cuantos niveles ha de tener un DFD. Pero

dado que un DFD es aconsejable que no tenga mas de media docena de

burbujas y almacenes relacionados, si nos aparece un nivel que contenga un

número muy superior deberemos insertar un nuevo nivel a los que hubiere. Hay

que procurar que haya equilibrio en la distribución de todos los elementos

gráficos entre todos los niveles del DFD.

2. ¿Deberemos de dividir todas las partes del sistema con el mismo nivel de

detalle?

La respuesta será que no. Algunas partes del sistema pueden ser más

complejas que otras y pueden requerir uno o más niveles de partición. En el

caso que nos encontremos con desigualdades respecto a la división de un

procesos respecto a otros, deberemos nivelar el DFD para lograr un equilibrio.

3. ¿Cómo nos aseguraremos que los niveles del DFD son consistentes entre

sí?

Esta cuestión es importante, ya que normalmente existe un desarrollo entre

distintas personas en un proyecto real, así como una división del trabajo. Para

asegurarse que cada figura es consistente con su figura de más alto nivel se

sigue una regla sencilla : los flujos entrantes y salientes de una burbuja en un

nivel dado deben corresponder con los que entran y salen de toda la figura en

el nivel inmediatamente inferior que la describe.

4. ¿Cómo se muestran los almacenes en los distintos niveles

Introducimos redundancia deliberadamente en el modelo. La regla es la

siguiente: mostrar un almacén en el nivel más alto donde primeramente sirve

de interfaz entre dos o más burbujas; luego mostrarlo de nuevo en cada

diagrama de nivel inferior que describa más a fondo dichas burbujas de

interfase. Por lo tanto los almacenes locales, que utilizan sólo las burbujas en

una figura de menor nivel, no se mostrará en niveles superiores, dado que se

incluyen de manera implícita en un proceso del nivel inmediato superior.

5. ¿Cómo se realiza de hecho la partición de los DFD en niveles? La situación

que nos imaginamos como ideal es la de comenzar con el diagrama de

contexto y luego desarrollar cada figura para trabajar de forma progresiva hasta

los niveles de bajo nivel. Sin embargo éste planteamiento nos dará problemas,

de modo que el enfoque mmás aconsejable es identificar los acontecimientos

externos a los cuales debe responder el sistema y crear un primer DFD

borrador. Veremos como esta primera aproximación del DFD puede suponer un

punto de partida hacia arriba o hacia abajo.

6. Para decidir cuál es el último nivel no debemos seguir profundizando

mientras halla procesos que puedan ser descompuestos en subprocesos, ni

entrar en descripciones de tal detalle sobre los procesos que estemos

desarrollando su algoritmo. Es decir, los últimos niveles del DFD no deben

convertirse en un organigrama del algoritmo de cada proceso.

1.7 Explosión de un proceso

A medida que vayamos conociendo mas las actividades de un proceso,

podemos

representarlas con otro DFD. Para ello seguiremos las siguientes normas:

1. Se debe explosionar un solo proceso cada vez. Por ejemplo, consideremos

el

proceso 3 de la figura 11 como un proceso n genérico.

2. Se representa una caja de proceso grande para ver con mas detalle su

funcionamiento.

3. Todos los procesos a que da lugar la explosión del proceso n, se van

numerando como n.1, n.2, n.3, n.4, etc.

4. Todos los flujos de datos que llegaban al proceso n tienen que llegar al

conjunto n.1, n.2, n.3, etc. Aplicando estas normas a la explosión del proceso

3 obtendríamos el resultado de la figura 12.

5. Todos los flujos de datos que salían del proceso n tienen que salir del

conjunto

n.1, n.2, n.3, etc.

6. Al estudiar en más detalle el funcionamiento del proceso n, y tener en cuenta

el tratamiento de errores y excepciones es posible que surjan nuevos flujos de

datos del conjunto del procesos explosionados con el exterior.

Si estos flujos son fruto del tratamiento de errores figura 11 y excepciones se

marcan con una X para resaltar el hecho de que no tienen que aparecer en el

DFD original (donde se definió el proceso n). Si hay otros flujos adicionales con

el exterior se tendrían que reflejar en el DFD original.

7. En la explosión pueden aparecer almacenamientos de datos privados, es

decir que son utilizados exclusivamente por los procesos n.1, n.2, n.3, etc.

Estos almacenamientos quedan reflejados dentro del marco del proceso n y se

identifican como Dn.1, Dn.2, Dn.n, etc.

8. Todas las entidades externas han de estar fuera del marco de la explosión.

1.8 Desarrollo de DFD’s

El primer paso es hacer un estudio del sistema actual (estudio del sistema

físico). El sistema físico se traslada en una descripción lógica que se centra en

datos y procesos. Durante el análisis de flujo de datos se evalúan todos los

detalles en términos de los componentes lógicos de flujos de datos, procesos y

almacenes de datos, orígenes y destinos.

1.8.1 Tipos de diagramas de flujo de datos

Los diagramas de flujo de datos son de dos tipos:

1. Diagramas físicos de flujo de datos. Proporcionan un panorama del sistema

en uso, muestra las tareas que se llevan a cabo y como se hacen. Las

características físicas incluyen:

¨ Nombre de personas

¨ Nombre o formatos de documentos

¨ Nombres de departamentos

¨ Archivo de maestro y de transacciones

¨ Equipo y dispositivos utilizados

¨ Ubicaciones

2. Diagramas lógicos de flujo de datos.

Proporcionan un panorama del sistema independiente de la implantación, que

se centra en el flujo de datos entre los procesos sin considerar los dispositivos

específicos y la localización de almacenes de datos o personas en el sistema.

Los diagramas físicos de flujos de datos, no son un fin en si mismos, sino son

un medio para describir la implantación del sistema existente. El diagrama

lógico es un visión retrospectiva de la implantación actual y proporciona la base

para examinar la combinación de procesos, flujo de datos, almacenes de datos,

entradas y salidas sin importarnos los dispositivos físicos, personas o aspectos

de control que caracterizan la implantación. Así que el diagrama lógico se

obtiene del diagrama físico al llevar a cabo lo siguiente:

¨ Señalar los datos necesarios en este momento para un proceso, no

documentos que los contienen.

¨ Indicar los flujos entre los procedimientos y no entre personas, oficinas o

localidades.

¨ Eliminar herramientas y dispositivos.

¨ Eliminar información de control.

¨ Consolidar los almacenes de datos redundantes.

¨ Eliminar los procesos innecesarios (v.gr los que no cambian los datos,

independientes de los dispositivos donde ocurren, los que representan un

proceso único dentro del sistema). Cuando se inicia el estudio de sistemas en

un área de la Organización, el analista necesita obtener una visión del sistema.

Primero los elementos físicos: personas, documentos, listados. No es difícil

recordar lugares o personas importantes (' Este trabajo lo realiza Pérez ', ' La

autorización del pago de facturas se realiza en el departamento de contabilidad

', etc.). Los diagramas físicos representan estos elementos. Una vez superada

esta primera fase de conocimiento del sistema actual, es necesario descifrar

los aspectos más importantes de cada actividad. Los diagramas lógicos nos

permiten describir los datos, procesos y eventos de forma abstracta, ya que el

analista debe conocer el trabajo que debe realizarse mas que las personas que

en la actualidad lo realizan. Los analistas generalmente comienzan por la

construcción de un modelo físico por que los componentes físicos se pueden

identificar realmente durante el análisis y después lo convierten a un modelo

lógico. Pero veamos como podemos hacer esto con un ejemplo:

Partamos del siguiente DFD físico de la figura 13, donde podemos apreciar dos

Componentes físicos:

el encargado de recepción, que recibe un pedido y lo verifica para

determinar si es del tipo que fabrica la organización. Si la respuesta es

no, el pedido no se acepta; si es sí, pasa a la sección de producción.

sección de producción, que comprueba si la máquina para hacer el

pedido está disponible. Si no, el pedido no se acepta; en otro caso, se

encargan los recursos para la producción del pedido.

Durante la conversión, primero se pasan todos los procesos que hacen

referencia a actividades físicas, en el ejemplo y enviar a la sección de

producción. El resto de los procesos físicos se expanden después dentro de

sus funciones lógicas. Para ello se toma cada proceso físico, se busca qué es

lo que hace y se reemplaza por un DFD de funciones lógicas expandido que

represente las actividades de un objeto físico. En la figura 19 podemos apreciar

como el encargado de recepción se reemplaza por dos funciones que son

registrar pedido y comprobar tipo de pedido. De la misma forma sección de

producción es reemplazado por sus dos funciones comprobar recursos

disponibles y encargar recursos a producción.

Después se examina este último DFD, y cualquier función común o similar se

combina para formar un proceso de nivel más alto que se convierte el DFD

superior, en la figura 14 podemos apreciar como los procesos comprobar

pedido y comprobar recursos disponibles se combinan en uno sólo pues tiene

un propósito similar dando como resultado el proceso comprobar factibilidad

producción. También se añaden al nuevo DFD los procesos registrar pedido y

encargar recursos a producción.

1.8.2 Deducción del diagrama lógico

Los diagramas físicos de flujo de datos son un medio para alcanzar un fin, no

un fin en sí mismos. Se elaboran para describir la implantación del sistema

existente, con el objetivo de tener la comprensión correcta de la implantación

real del sistema existente. El panorama lógico es una visión retrospectiva de la

implantación actual y proporciona la base para examinar la combinación de

procesos, flujo de datos, almacenes de datos, entradas y salidas sin tomar en

cuenta dispositivos físicos, personas o aspectos de control que caracterizan la

implantación.

1.8.3 Reglas generales para el dibujo de diagramas lógicos de flujo de

datos

Las reglas a tener en cuenta, para el dibujo de los diagramas lógicos de flujo de

datos:

1. Cualquier flujo de datos que abandone un proceso debe estar basado en los

datos que entran al proceso.

2. Todos los flujos de datos reciben un nombre, el nombre refleja los datos que

fluyen entre procesos, almacenes de datos, fuentes o destinos.

3. Sólo deben entrar al proceso los datos necesarios para llevarlo a cabo.

4. Un proceso no debe saber nada de ningún otro en el sistema, es decir debe

ser independiente, la única dependencia que debe existir es aquella que esté

basada en sus propios datos de entrada y salida.

5. Los procesos siempre están en continua ejecución, no se inician, ni tampoco

se detienen.

6. La salida de los procesos puede tomar una de las siguientes formas:

¨ Flujo de datos con información añadida por el proceso (v.gr anotación en la

factura).

¨ Una respuesta o cambio en la forma de los datos (v.gr cambio en la forma de

expresar los datos).

¨ Un cambio de condición (v.gr de no autorizado a autorizado).

¨ Un cambio de contenido (v.gr integración o separación de la información

contenida en uno o mas flujos entrantes de datos).

¨ Cambios en la organización (v.gr separación física o reacomodo de datos).

1.8.4 Expansión de los procesos para mayor detalle

Dado que la información contenida en el diagrama de contexto, es inadecuada

para explicar en su totalidad los requerimientos del sistema, es deseable

describir el panorama lógico del procesamiento de facturas por pagar con

mayor detalle. Para identificar los procesos utilizamos los números 1.0, 2.0 y

3.0. Podemos hacer referencia por su número (1.0) o por su nombre

(Autorización de facturas).

Los diagramas de flujo de datos no tienen utilidad si se dibujan en forma

inapropiada o ser manejan sin cuidado. Aunque no hay leyes que establezcan

el número de niveles, el número de procesos por niveles, la norma común es

definir cada nivel inferior en términos de tres a siete de procesos por cada

proceso de nivel superior. La utilización de mas de siete procesos hace que el

diagrama sea difícil de manejar y dibujar. Lo importante es entender que los

diagramas de flujo de datos lógicos son una herramienta de ayuda para ayudar

la comprensión del sistema de la Organización. De modo que un diagrama deja

de ser útil cuando no es comprensible. Por lo tanto, debe primar el sentido

común, y no determinar normas estrictas para su construcción.

4.8.5 Mantenimiento de la consistencia entre procesos

Si comprobamos el diagrama de contexto, y el diagrama de primer nivel (figura

17), el primer proceso tiene el mismo flujo de entrada (factura del proveedor),

así como el flujo de salida (cheque), esto se debe a que la explosión es

consistente; los flujos de entradas o salidas del proceso de nivel superior están

presentes en el diagrama de nivel inferior, y apareciendo nuevos flujos,

almacenes. Esto es precisamente uno de los puntos importantes de la

expansión hacia niveles inferiores: encontrar mas detalles relacionados con los

procesos internos.

1.8.6 Convenciones de nivelación significativas

Nivelación es un término que se refiere al manejo de archivos locales (los

empleados dentro de un proceso). Los detalles relacionados con un solo

proceso en un determinado nivel deben permanecer dentro del proceso. Los

almacenes y flujos de datos que son

relevantes únicamente para el interior del proceso, son ocultados hasta que el

proceso se extiende con mayor detalle. Si nos fijamos en el diagrama de

contexto, aparece un almacenamiento de datos (datos del vendedor). Este

almacén se crea fuera del sistema de facturas por pagar. Por otro lado los

almacenes de datos de facturas por pagar, órdenes de compra y cuentas por

pagar están contenidos dentro del proceso, y aparecen en el próximo nivel

cuando se expansione el proceso. La convención de nivelación señala que

estos almacenes son internos al proceso, no entradas para él.

1.8.7 Añadir los controles sólo en los diagramas de bajo nivel

Hasta el momento los diagramas de flujos de datos desarrollados no incluyen

información sobre controles. No se hace referencia sobre como manejar

errores o excepciones, por ejemplo como procesar facturas incorrectas.

Aunque esta información no es importante para identificar todos los flujos de

datos, deben aparecer en segundo o tercer nivel deben aparecer el manejo de

errores y excepciones del proceso. En nuestro ejemplo, podemos comprobar la

figura 18 para el proceso de Autorización de factura. Se incluyen el control de

excepciones de facturas sin firma, o facturas de compra sin pedido. Los errores

mas comunes cometidos al incluir los controles físicos en los diagramas lógicos

de flujo de datos. Por ejemplo: El copiado de números para documentos (copia

1,copia 2, copia para contabilidad), de instrucciones (encontrar el registro,

revisar el registro), o días para el inicio de actividades (hacerlo el lunes) no

tienen nada que ver con los aspectos lógicos y de datos de determinación de

requerimientos.

1.8.8 Asignar etiquetas significativas

Todos los flujos de datos deben tener un nombre que refleje con exactitud su

contenido. Los nombres dados a los flujos de datos deben reflejar los datos de

interés para los analistas, no los documentos o el lugar donde residen. Por

ejemplo, una factura contiene varios elementos diferentes de información. Los

analistas están interesados en aquellos que son importantes para un proceso

en particular. Estos pueden ser el número de la factura y la fecha de

expedición, o la firma de autorización de la factura. Lo importante no es la hoja

de papel. Los datos que fluyen hacia los procesos experimentan cambios. Por

consiguiente, el flujo de datos de salida tiene un nombre diferente al de

entrada.

1.8.9 Asignar de nombre a los procesos

Se deben asignar nombre a todos los procesos que les digan a los usuarios

algo específico con respecto a la naturaleza de las actividades del proceso. Los

nombres Control de Inventarios, Compras y Ventas, es mejor utilizar Ajustar

cantidad, preparar orden de compra o corregir pedido de ventas.

Consideraciones para dar nombre de los procesos:

1. Seleccionar nombres que indiquen la acción que se lleva a cabo. Lo mas

apropiado es escoger un verbo y un objeto que reciba la acción del verbo.

2. Asegurar que el nombre describa completamente el proceso. (Si un proceso

edita y valida los datos de una factura, no se puede dar el nombre de Edición

de facturas).

3. Seleccionar nombres para los procesos que expliquen el enlace entre los

flujos de entrada y salida.

4. Evitar nombres vagos como proceso, revisión, reunir u organizar.

5. Utilizar los nombres de los procesos de bajo nivel ya que estos son mas

específicos y descriptivos que los asociados con los procesos de alto nivel.

6. Asignar nombres a los procesos que sean únicos para la actividad que ellos

describen. También hemos hablado de numerar los procesos con los números

1, 2, 3, 4 y 5. Los procesos generados con la expansión de cada uno de ellos

sen los niveles inferiores se les asigna un decimal para indicar que son

descripciones detalladas de un proceso de nivel superior.

1.8.10 Evaluación y verificación del diagrama de flujo de datos

Es fundamental verificar con cuidado todos los diagramas de flujo para

determinar si son correctos. La presencia de lo que parece ser un error señale

una deficiencia en el sistema. Debemos hacernos una serie de preguntas, que

nos sirvan de ayuda para evaluar los diagramas de flujo de datos:

1. ¿Existen en el diagrama de flujo de datos componentes que no tienen

nombre

(flujo de datos, procesos, almacenamientos, entradas o salidas)?

2. ¿Existen almacenes de datos que son entradas y a los que nunca se hace

referencia?

3. ¿Existen procesos que no reciben entradas?

4. ¿Existen procesos que no generan salida?

5. ¿Exsiten procesos que tienen varias finalidades?

6. ¿Existen almacenes de datos a los que no de referencien?

7. ¿Existen demasiados atributos en el almacen de datos (mas que los detalles

necesarios)?

8. ¿El flujo de datos que llega a un proceso es demasiado extenso para la

salida

1.9 DFD PARA SISTEMAS EN TIEMPO REAL.

Los flujos vistos hasta ahora, son simplemente los conductos a lo largo de los

cuales viajan los paquetes de datos entre procesos y almacenes. Podemos

considerar las burbujas de los DFD como procesadores de datos. Hay una

clase de sistemas, los de tiempo real, en los que necesitamos modelar flujos de

control (es decir señales o interrupciones). Y se requiere una manera de

mostrar procesos de control (esto es, burbujas cuya única labor es coordinar y

sincronizar las actividades de otras burbujas del DFD). Un flujo de control

puede imaginarse como un conducto que porta una señal binaria (esto es, está

encendido o está apagado). A diferencia de otros flujos que se discuten en este

capítulo, el flujo de control no porta datos con valores. El flujo de control se

manda de un proceso a otro (o de algún terminador externo a un proceso)

como una forma de decir que se inicie el proceso. Un proceso de control puede

considerarse como una burbuja ejecutiva, cuya función es coordinar las

actividades de otras burbujas en el diagrama ; sus entradas y salidas consisten

sólo en flujos de control. Los flujos de control salientes del proceso de control

se utilizan para despertar a otras burbujas ; los flujos de control entrantes

generalmente indican que una de las burbujas ha terminado su labor o que se

ha presentado alguna situación extraordinaria, de la cual necesita informarse a

la burbuja de control. Por lo común sólo hay un proceso de control de estos en

un DFD dado.

.com