aesi_cap4

Diagramas de Flujo de Datos

Página -1-

4 Diagramas de Flujo de Datos

4.1 Concepto

Los diagramas de flujos de datos (DFD), es una técnica de modelización, que nosmuestra un sistema como una red de procesos conectados entre ellos por flujos yalmacenamientos de datos.

Es un modelo que proporciona el punto de vista funcional de un sistema.

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

Los analistas deben trabajar con los usuarios para hacerles comprender elfuncionamiento del sistema actual y el sistema futuro, para ello se hace aconsejable utilizarun lenguaje común, sencillo y fiable, estas son las características de los diagramas de flujode datos. Los usuarios pueden hacer sugerencias para modificar los diagramas con lafinalidad de describir las actividades con mayor exactitud, y permitirá evitar los erroresdesde el inicio pudiendo prevenir una posible falla del sistema.


Página -2-

4.3 Notación de los Diagrama Flujo de Datos

Los métodos para el análisis de flujo de datos fueron desarrollados y promovidos pordos organizaciones al mismo tiempo, Yourdon Inc (compañía de consultoría) y McDonnell-Douglas (Gane and Sarson). En nuestro libro la notación utilizada será la deYourdon . Los DFD’s se pueden dibujar con sólo cuatro elementos gráficos sencillos, queson:

♦ Procesos: El primer componente del DFD. El proceso muestra una parte delsistema que transforma entradas en salidas, suelen ser personas,procedimientos o dispositivos que utilizan o transforman datos. El proceso serepresenta gráficamente como un círculo. Los sinónimos comunes sonburbuja, función o transformación.

figura 1: Proceso

♦ Flujo de datos: Se representa gráficamente por medio de una flecha que entrao sale de un proceso. El flujo se usa para describir el movimiento de bloquesde información de una parte del sistema a otra. Por ello, los flujos representandatos en movimiento, mientras que los almacenes representan datos en reposo.En algún módelo puede representar movimiento de material. Los flujosmuestran la dirección; según si los datos se está moviendo hacia adentro ohacia afuera de un proceso (o ambas cosas).

figura 2: Flujo de datos


Página -3-

Podemos hablar de varios tipos de flujos de datos:

◊ Segun dirección/sentido de los datos, respecto al proceso:

◊ Entrada.

ValidarNumero

Telefónico

número telefónico

figura 3: Flujo de Entrada

◊ Salida.

GenerarItinerario

Conductor

Itinerario Conductor

figura 4: Flujo de Salida

◊ Diálogo (Entrada y Salida).

Determ.Estado deun pedido

Pregunta sobreestado de pedido

Respuesta estado deun pedido

figura 5: Flujo de diálogo

◊ Divergente, Convergente.

Cuando una misma información se envía a procesos diferentes, o cuando unainformación compleja se descompone en varios datos mas sencillos cada unode los cuales va a un proceso diferente (divergente). Varios paquetes de datosse juntan para formar parte de paquetes de datos mas complejos(convergente).


Página -4-

Domicilio delusuario

Código Postal

Número telefónico

Calle

figura 6: Flujo divergente

♦ Almacen de datos: El almacen se utiliza para modelar una colección de datosen reposo. Se representa por dos líneas paralelas. Es tentador asociar a losalmacenes los archivos o bases de datos, es así como a menudo se implantanen un sistema informático, pero un almacen también puede consistir en datosalmacenados en cualquier soporte que contenga datos (archivos de papel,tarjetas etc).

figura 7: Almacenamiento

♦ Entidad (Terminador): El siguiente componente del DFD es un terminador ;representado gráficamente como un rectángulo representan fuentes (origen) odestinos externos de datos que pueden ser: personas, programas,organizaciones u otras entidades que interactúan con el sistema pero seencuentran fuera de su frontera. En algun casos, un terminador puede ser otrosistema con el cual se comunica éste.

figura 8: Entidad Externa o Terminador


Página -5-

Existen tres cosas importantes que debemos recordar acerca de losterminadores :

◊ Son externos al sistema que se está modelando ; los flujos que conectanlos terminadores a diversos procesos (o almacenes) en el sistemarepresentan la interfaz entre él y el mundo externo.

◊ El analista de sistemas no puede modificar los contenidos, laorganización ni los procedimientos internos asociados en posibilidadesde 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 elmodelo DFD. Si existen relaciones entre los terminadores y si esesencial para el analista modelarlos para poder documentar losrequerimientos y si es esencial para el analista modelarlos para poderdocumentar los requerimientos del sistema, entonces ,por definición ,losterminadores son en realidad parte del sistema y debieran modelarsecomo 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 serrespuesta de los DFD´s, estas respuestas forman parte del procedimiento.

Cada componente en un diagrama de flujo de datos tiene una etiqueta con un nombredescriptivo. Los nombres de los procesos también reciben un número para poderidentificarlo.

ENTIDAD ENTIDADDDD

PROCESO 1

PROCESO 2

ALMACEN DE DATOS

FLUJO 1 FLUJO 4

FLUJO 2

FLUJO 3

FLUJO 5

figura 9: Componentes de un Diagrama de Flujo de Datos

Los diagramas de flujo de datos se concentran en el movimiento de datos a través delsistema, no en los dispositivos o el equipo. Se identifican y describen los datos que fluyenpor todo el sistema, explicando porque los datos entran o salen y cual es el procesamientoque se realiza con ellos (guardan y recuperan de almacenamiento de datos).


Página -6-

4.4 Directrices para la construcción de DFD´s

Hay una serie de reglas que son necesarias para poder construir los DFD'scorrectamente. La finalidad de estas reglas es ayudar a confeccionar DFD`s correctos, ypermitir dibujar un DFD agradable a la vista y por tanto que tenga mas probabilidades deque 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 masprecisamente posible al objeto que representa.

En el caso de los procesos debemos identificar las funciones que el sistemaestá llevando a cabo, es decir el nombre del proceso describirá lo que sehace:

◊ Función: Verbo + objeto.◊ Verbo significativo (Validar, Registrar etc).◊ Evitar palabras de uso exclusivo por parte de usuario.◊ 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 procesosasincrónicos que se intercomunican, lo cual es, una representación precisa dela manera en la realidad muchos sistemas operan. El hecho que existaprocesos no pueda realizar su función por falta de algún dato de otro procesono implica correspondiente con la numeración. Son la base para crear lajerarquía de diagramas cuando se introduzcan los diagramas de flujo porniveles.

3. Evitar DFD excesivamente complejos y recargados, es decir, con muchoselementos gráficos juntos.

El propósito de un DFD es modelar de forma precisa las funciones que debellevar a cabo un sistema y las interacciones entre ellas. Pero otro propósito delDFD, de igual importancia, es que sea leído y comprendido, no sólo pr elanalista que construyo el modelo, sin por los usuarios que sean los expertosen la materia de aplicación. Esto significa que el diagrama debe ser fácilmenteentendido, fácilmente asimilado y placentero a la vista.

Existe una excepción, un DFD conocido como diagrama de contexto, querepresenta el sistema entero como un solo proceso y destaca las interfacesentre 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:

◊ Conseguir un DFD técnicamente correcto.◊ Aceptado por el usuario◊ Estar lo suficientemente bien dibujado como para que no seaembarazoso mostrarlo a la dirección de la organización.


Página -7-

6. Asegurarse que el DFD es consistente.

Existen reglas para asegurar la consistencia del DFD con otros modelos desistemas ; el diagrama de entidad-relación, diagrama transción de estados,diccionario de datos, y la especificación de procesos. Las principales reglas deconsistencia son :

◊ Evite sumideros infinitos, procesos que tienen entradas pero no salidas.◊ Evite burbujas de generación espontánea, procesos que tienen salidas

sin tener entradas. Situación normalmente incorrecta.◊ Cuidado con flujos y procesos no etiquetados, ya que puede esconder

errores importantes.◊ 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.

◊ Las entidades externas no pueden acceder directamente a ningúnalmacenamiento. Siempre debe mediar un proceso que haga deintermediario y extraiga o inserte la información pertinente.

SUMIDERO INFORMACION FUENTE INFORMACION

PROCESO(1/2)PROCESO(2/2)

figura 10 : Sumidero y Fuente de Información

4.5 Niveles de un DFD

Cuando nos enfrentemos ante un modelo real, nos enfrentaremos ante un DFDgrande y complejo. Deberemos evitar diagramas complejos y poco legibles, de acuerdopero ¿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 cadauno proporcione sucesivamente más detalles sobre una porción del nivel anterior. Esto es


Página -8-

análogo a la organización de mapas en una atlas, de modo que un mapa global nos muestraun país completo, pero los mapas subsecuentes mostrarían los detalles de los paísesindividuales, los estados individuales dentro de los países.

La división consiste en construir una jerarquía de diagramas, en donde cada nivelinferior es una expansión de un proceso del nivel superior.

El DFD de primer nivel consta de una sola burbuja, y representa el sistema deinformación completo, como un todo ; los flujos de datos muestran las interfaces entre elsistema y las entidades externas. Este DFD especial se conoce como diagrama de contextoo nivel 0 .

El nivel 1, que sería el siguiente nivel inferior en la jerarquía, descompondría esemacro proceso, que representa a todo el sistema, en las actividades principales que locomponen, 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 inferiores una expansión de un proceso del nivel superior.

4.6 Construcción de los niveles del DFD

Como podemos ver lo que se pretende es descomponer un todo en piezas con elobjetivo de reducir la complejidad. Pero debemos responder una serie de cuestiones :

1. ¿ Cómo saber cúantos niveles debe haber en un DFD ? No hay ninguna reglapara decidir cuantos niveles ha de tener un DFD. Pero dado que un DFD esaconsejable que no tenga mas de media docena de burbujas y almacenesrelacionados, si nos aparece un nivel que contenga un número muy superiordeberemos insertar un nuevo nivel a los que hubiere. Hay que procurar quehaya equilibrio en la distribución de todos los elementos gráficos entre todoslos niveles del DFD.

2. ¿Deberemos de dividir todas las partes del sistema con el mismo nivel dedetalle ? La respuesta será que no. Algunas partes del sistema pueden ser máscomplejas que otras y pueden requerir uno o más niveles de partición. En elcaso que nos encontremos con desigualdades respecto a la división de unprocesos respecto a otros, deberemos nivelar el DFD para lograr unequilibrio.

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 entredistintas personas en un proyecto real, así como una división del trabajo. Paraasegurarse que cada figura es consistente con su figura de más alto nivel sesigue una regla sencilla : los flujos entrantes y salientes de una burbuja en unnivel dado deben corresponder con los que entran y salen de toda la figura en


Página -9-

el nivel inmediatamente inferior que la describe.

4. ¿ Cómo se muestran los almacenes en los distintos nivelesintroducimos redunadancia deliberadamente en el modelo. La regla es lasiguiente: mostrar un almacén en el nivel más alto donde primeramente sirvede interfaz entre dos omás burbujas; luego mostrarlo de nuevo en cadadiagrama de nivel inferior que describa más a fondo dichas burbujas deinterface. Por lo tanto los almacenes locales, que utilizan sólo las burbujas enuna figura de menor nivel, no se mostrará en niveles superiores, dado que seincluyen 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ónque nos imaginamos como ideal es la de comenzar con el diagrama decontexto y luego desarrollar cada figura para trabajar de forma progresivahasta los niveles de bajo nivel. Sin embargo éste planteamiento nos daráproblemas, de modo que el enfoque mmás aconsejable es identificar losacontecimientos externos a los cuales debe responder el sistema y crear unprimer DFD borrador. Veremos como esta primera aproximación del DFDpuede suponer un punto de partida hacia arriba o hacia abajo.

6. Para decidir cuál es el último nivel no debemos seguir profundizando mientrashalla procesos que puedan ser descompuestos en subprocesos, ni entrar endescripciones de tal detalle sobre los procesos que estemos desarrollando sualgoritmo. Es decir, los últimos niveles del DFD no deben convertirse en unorganigrama del algoritmo de cada proceso.

4.7 Explosión de un proceso

A medida que vayamos conociendo mas las actividades de un proceso, podemosrepresentarlas con otro DFD. Para ello seguiremos las siguientes normas:

1. Se debe explosionar un solo proceso cada vez. Por ejemplo, consideremos elproceso 3 de la figura 11 como un proceso n genérico.

1 2

3

(n)

4Z

X Y

B

C

A

figura 11: Diagrama de nivel 1


Página -10-

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

3. Todos los procesos a que da lugar la explosión del proceso n, se vannumerando como n.1, n.2, n.3, n.4, etc.

4. Todos los flujos de datos que llegaban al proceso n tienen que llegar alconjunto n.1, n.2, n.3, etc. Aplicando estas normas a la explosión del proceso3 obtendríamos el resultado de la figura 12.

3.1

3.2

3.3

3.4

X

YZ

figura 12: Explosión proceso 3

5. Todos los flujos de datos que salían del proceso n tienen que salir del conjunton.1, n.2, n.3, etc.

6. Al estudiar en más detalle el funcionamiento del proceso n, y tener en cuentael tratamiento de errores y excepciones es posible que surjan nuevos flujos dedatos del conjunto del procesos explosionados con el exterior.

Si estos flujos son fruto del tratamiento de errores figura 11 y excepciones semarcan con una X para resaltar el hecho de que no tienen que aparecer en elDFD original (donde se definió el proceso n).

Si hay otros flujos adicionales con el exterior se tendrían que reflejar en elDFD original.

7. En la explosión pueden aparecer almacenamientos de datos privados, es decirque son utilizados exclusivamente por los procesos n.1, n.2, n.3, etc. Estosalmacenamientos quedan reflejados dentro del marco del proceso n y seidentifican como Dn.1, Dn.2, Dn.n, etc.

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


Página -11-

4.8 Desarrollo de DFD’s

El primer paso es hacer un estudio del sistema actual (estudio del sistema físico). Elsistema 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 loscomponentes lógicos de flujos de datos, procesos y almacenes de datos, orígenes ydestinos. En la fase de implementación, las especificaciones lógicas son trasladas en

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

El empleo de estos diagramas es aconsejable por tres razones:

♦ Para los analistas de sistema es mas fácil describir la interacciónentre los componentes físicos que comprender las políticasempleadas. De modo que identifican las personas, lo que hacen,los documentos que inician las actividades y el equipo para suprocesamiento.

♦ Los diagramas físicos de flujos de datos son de utilidad paracomunicarse con los usuarios. Estos relacionan con facilidad alaspersonas, las ubicaciones y los documentos ya que trabajan todoslos días con estas entidades (Los diagramas lógicos van a resultarabstractos para los usuarios).

♦ Los diagramas fisicos proporcionan un camino para validar overificar el punto de vista del usuario sobre la forma en que operael sistema en uso.

2. Diagramas lógicos de flujo de datos.

Proporcionan un panorama del sistema independiente de la implantación, quese centra en el flujo de datos entre los procesos sin considerar los dispositivosespecíficos y la localización de almacenes de datos o personas en el sistema.Los diagramas físcos de flujos de datos, no son un fin en si mismos, sino sonun medio para describir la implantación del sistema existente. El diagramalógico es un visión retrosprectiva de la implantación actual y proporciona la


Página -12-

base para examinar la combinación de procesos, flujo de datos, almacenes dedatos, entradas y salidas sin importarnos los dipositivos físicos, personas oaspectos de control que caracterizan la implantación.

Así que el diagrama lógico se obtiene del diagrama físico al llevar a cabo losiguiente:

♦ Señalar los datos necesarios en este momento para un proceso, nodocumentos que los contienen.

♦ Indicar los flujos entre los procedimientos y no entrepersonas,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 losdatos, independientes de los dispositivos donde ocurren, los querepresentan un proceso único dentro del sistema).

Cuando se inicia el estudio de sistemas en una area de la Organización, el analistanecesita obtener una visión del sistema. Primero los elementos físicos: personas,documentos, listados. No es dificil recordar lugares o personas importantes (' Este trabajolo realiza Perez ', ' La autorización del pago de facturas se realiza en el departamento decontabilidad ', etc.). Los diagramas físicos representan estos elementos.

Una vez superada esta primera fase de conocimiento del sistema actual, es necesariodescifrar los aspectos más importantes de cada actividad. Los diagramas lógicos nospermiten describir los datos, procesos y eventos de forma abstracta, ya que el analista debeconocer el trabajo que debe realizarse mas que las personas que en la actualidad lorealizan. Los analistas generalmente comienzan por la construcción de un modelo físicopor que los componentes físicos se pueden identificar realmente durante el análisis ydespués lo convierten a un modelo lógico. Pero veamos como podemos hacer esto con unejemplo:

Partamos del siguiente DFD físico de la figura 13, donde podemos apreciar doscomponentes físicos:

♦ el encargado de recepción, que recibe un pedido y lo verifica para determinarsi es del tipo que fabrica la organización. Si la respuesta es no, el pedido no seacepta; 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 pedidoestá disponible. Si no, el pedido no se acepta; en otro caso, se encargan losrecursos para la producción del pedido.


Página -13-

CLIENTESEncargado

deRecepción

1

Clasificarpor áreas

2

Enviar asección deproducción

3Sección deproducción

4

Pedidocomprobado

Pedidosclasificados

Pedidosdespachados

Imposibleservir pedido

Pedido noaceptado

Pedido

figura 13: DFD físico sistema de pedidos

Durante la conversión, primero se pasan todos los procesos que hacen referencia aactividades físicas, en el ejemplo y enviar a la sección deproducció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 unDFD de funciones lógicas expandido que represente las actividades de un objeto físico. Enla figura 19 podemos apreciar como el encargado de recepción se reemplaza por dosfunciones que son registrar pedido y comprobar tipo de pedido. De la misma formasección de producción es reemplazado por sus dos funciones comprobar recursosdisponibles y encargar recursos a producción.


Página -14-

CLIENTESRegistrarPedido

1.1

ComprobarPedido

1.2

Comprobarrecursos

disponibles

4.1

PEDIDOS

RECURSOS

Encargarrecursos aproducción

4.2

CLIENTES

Pedidorecibido

Pedidocomprobado

Pedido

Pedido no aceptado

Pedido aceptado

Imposibleservirpedido

figura 14: Conversión al DFD lógico

Después se examina este último DFD, y cualquier función común o similar secombina para formar un proceso de nivel más alto que se convierte el DFD superior, en lafigura 14 podemos apreciar como los procesos comprobar pedido y comprobar recursosdisponibles se combinan en uno sólo pues tiene un propósito similar dando como resultadoel proceso comprobar factibilidad producción.


Página -15-

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

CLIENTESRegistrarPedido

1

ComprobarFactibilidadProducción

2

EncargarRecursos aProducción

3

PEDIDOS RECURSOS

Pedidorecibido

Pedidoaceptado

Pedido

Imposible producir

figura 15: DFD lógico sistema de pedidos

4.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 finen sí mismos. Se elaboran para describir la implantación del sistema existente, con elobjetivo 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 yproporciona la base para examinar la combinación de procesos, flujo de datos, almacenesde datos, entradas y salidas sin tomar en cuenta dispositivos físicos, personas o aspectos decontrol que caracterizan la implantación.

4.8.3 Reglas generales para el dibujo de diagramas lógicos de flujode datos

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


Página -16-

1. Cualquier flujo de datos que abandone un proceso debe estar basado en losdatos que entran al proceso.

2. Todos los flujos de datos reciben un nombre, el nombre refleja los datos quefluyen 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 serindependiente, 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 tampocose 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.granotación en la factura).

♦ Una respuesta o cambio en la forma de los datos (v.gr cambio enla 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 lainformación contenida en uno o mas flujos entrantes de datos).

♦ Cambios en la organización (v.gr separación física o reacomodode datos).

4.8.4 Expansión de los procesos para mayor detalle

Dado que la información contenida en el diagrama de contexto, es inadecuada paraexplicar en su totalidad los requerimientos del sistema, es deseable describir el panoramaló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 hacerreferencia 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 inapropiadao ser manejan sin cuidado. Aunque no hay leyes que establezcan el número de niveles, elnúmero de procesos por niveles, la norma comun es definir cada nivel inferior en términosde tres a siete de procesos por cada proceso de nivel superior. La utilización de mas desiete 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 unaherramienta de ayuda para ayudar la comprensión del sistema de la Organización. Demodo que un diagrama deja de ser útil cuando no es comprensible. Por lo tanto, debeprimar el sentido común, y no determinar normas estrictas para su construcción.


Página -17-

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 flujode salida (cheque), esto se debe a que la explosión es consistente; los flujos de entradas osalidas del proceso de nivel superior están presentes en el diagrama de nivel inferior, yapareciendo nuevos flujos, almacenes. Esto es precisamente uno de los puntos importantesde la expansión hacia niveles inferiores: encontrar mas detalles relacionados con losprocesos internos.

4.8.6 Convenciones de nivelación significativas

Nivelación es un término que se refiere al manejo de archivos locales (los empleadosdentro de un proceso). Los detalles relacionados con un solo proceso en un determinadonivel deben permanecer dentro del proceso. Los almacenes y flujos de datos que sonrelevantes únicamente para el interior del proceso, son ocultados hasta que el proceso seextiende 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. Porotro lado los almacenes de datos de facturas por pagar, órdenes de compra y cuentas porpagar están contenidos dentro del proceso, y aparecen en el próximo nivel cuando seexpansione el proceso. La convención de nivelación señala que estos almacenes soninternos al proceso, no entradas para él.

4.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 incluyeninformación sobre controles. No se hace referencia sobre como manejar errores oexcepciones, por ejemplo como procesar facturas incorrectas. Aunque esta información noes importante para identificar todos los flujos de datos, deben aparecer en segundo o tercernivel deben aparecer el manejo de errores y excepciones del proceso.

En nuestro ejemplo, podemos comprobar la figura 18 para el proceso deAutorización de factura. Se incluyen el control de excepciones de facturas sin firma, ofacturas de compra sin pedido.

Los errores mas comunes cometidos al incluir los controles físicos en los diagramaslógicos de flujo de datos. Por ejemplo: El copiado de números para documentos (copia1,copia 2, copia para contabilidad), de instrucciones (encontrar el registro, revisar elregistro), o días para el inicio de actividades (hacerlo el lunes) no tienen nada que ver conlos aspectos lógicos y de datos de determinación de requerimientos.


Página -18-

4.8.8 Asignar etiquetas significativas

Todos los flujos de datos deben tener un nombre que refleje con exactitud sucontenido. Los nombres dados a los flujos de datos deben reflejar los datos de interés paralos analistas, no los documentos o el lugar donde residen. Por ejemplo, una facturacontiene varios elementos diferentes de información. Los analistas están interesados enaquellos que son importantes para un proceso en particular. Estos pueden ser el número dela factura y la fecha de expedición, o la firma de autorización de la factura. Lo importanteno es la hoja de papel. Los datos que fluyen hacia los procesos experimentan cambios. Porconsiguiente, el flujo de datos de salida tiene un nombre diferente al de entrada.

4.8.9 Asignar de nombre a los procesos

Se deben asignar nombre a todos los procesos que les digan a los usuarios algoespecífico con respecto a la naturaleza de las actividades del proceso. Los nombres Controlde Inventarios, Compras y Ventas, es mejor utilizar Ajustar cantidad, preparar orden decompra 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 masapropiado 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 procesoedita y valida los datos de una factura, no se puede dar el nombre de Ediciónde facturas).

3. Seleccionar nombres para los procesos que expliquen el enlace entre los flujosde 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 masespecí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 ellosdescriben.

También hemos hablado de numerar los procesos con los números 1, 2, 3, 4 y 5. Losprocesos generados con la expansión de cada uno de ellos sen los niveles inferiores se lesasigna un decimal para indicar que son descripciones detalladas de un proceso de nivelsuperior.

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

Es fundamental verificar con cuidado todos los diagrmas de flujo para determinar sison correctos. La presencia de lo que parece ser un error señale una deficiencia en elsistema. Debemos hacernos una serie de preguntas, que nos sirvan de ayuda para evaluarlos diagramas de flujo de datos:

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


Página -19-

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

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

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 detallesnecesarios)?

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

4.9 DFD PARA SISTEMAS EN TIEMPO REAL.

Los flujos vistos hasta ahora, son simplemente los conductos a lo largo de los cualesviajan los paquetes de datos entre procesos y almacenes. Podemos considerar las burbujasde los DFD como procesadores de datos. Hay una clase de sistemas, los de tiempo real, enlos que necesitamos modelar flujos de control (es decir señales o interrupciones). Y serequiere una manera de mostrar procesos de control (esto es, burbujas cuya única labor escoordinar y sincronizar las actividades de otras burbujas del DFD). Un flujo de controlpuede imaginarse como un conducto que porta una señal binaria (esto es, está encendido oestá apagado). A diferencia de otros flujos que se discuten en este capítulo, el flujo decontrol no porta datos con valores. El flujo de control se manda de un proceso a otro (o dealgú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 escoordinar las actividades de otras burbujas en el diagrama ; sus entradas y salidasconsisten sólo en flujos de control. Los flujos de control salientes del proceso de control seutilizan para despertar a otras burbujas ; los flujos de control entrantes generalmenteindican que una de las burbujas ha terminado su labor o que se ha presentado algunasituación extraordinaria, de la cual necesita informarse a la burbuja de control. Por locomún sólo hay un proceso de control de estos en un DFD dado.

Página -21-

aesi_cap4

Documents