4 Diagramas de Flujo de Datos

Transcripción

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 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. 4.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. Página -1-

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 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 módelo 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). figura 2: Flujo de datos Página -2-

3 Podemos hablar de varios tipos de flujos de datos: Segun dirección/sentido de los datos, respecto al proceso: Entrada. número telefónico Validar Numero Telefónico figura 3: Flujo de Entrada Salida. Generar Itinerario Conductor Itinerario Conductor figura 4: Flujo de Salida Diálogo (Entrada y Salida). Determ. Estado de un pedido Pregunta sobre estado de pedido Respuesta estado de un pedido figura 5: Flujo de diálogo Divergente, Convergente. Cuando una misma información se envía a procesos diferentes, o cuando una información compleja se descompone en varios datos mas 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). Página -3-

4 Domicilio del usuario 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 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 almacen también puede consistir en datos almacenados 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) 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 algun casos, un terminador puede ser otro sistema con el cual se comunica éste. figura 8: Entidad Externa o Terminador Página -4-

5 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. ENTIDAD PROCESO 1 FLUJO 1 FLUJO 4 ENTIDAD DDD FLUJO 2 PROCESO 2 FLUJO 3 FLUJO 5 ALMACEN DE DATOS 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 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). Página -5-

6 4.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: 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 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 debe 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 pr 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: Conseguir un DFD técnicamente correcto. Aceptado por el usuario Estar lo suficientemente bien dibujado como para que no sea embarazoso mostrarlo a la dirección de la organización. Página -6-

7 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 : 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ún almacenamiento. Siempre debe mediar un proceso que haga de intermediario 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 DFD 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 Página -7-

8 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. 4.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 cúantos 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 Página -8-

9 el nivel inmediatamente inferior que la describe. 4. Cómo se muestran los almacenes en los distintos niveles introducimos redunadancia 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 omás burbujas; luego mostrarlo de nuevo en cada diagrama de nivel inferior que describa más a fondo dichas burbujas de interface. 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. 4.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. A 1 2 B X Y 3 (n) Z 4 C figura 11: Diagrama de nivel 1 Página -9-

10 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 X Z Y figura 12: Explosión proceso 3 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. Página -10-

11 4.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. En la fase de implementación, las especificaciones lógicas son trasladas en 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 El empleo de estos diagramas es aconsejable por tres razones: Para los analistas de sistema es mas fácil describir la interacción entre los componentes físicos que comprender las políticas empleadas. De modo que identifican las personas, lo que hacen, los documentos que inician las actividades y el equipo para su procesamiento. Los diagramas físicos de flujos de datos son de utilidad para comunicarse con los usuarios. Estos relacionan con facilidad alas personas, las ubicaciones y los documentos ya que trabajan todos los días con estas entidades (Los diagramas lógicos van a resultar abstractos para los usuarios). Los diagramas fisicos proporcionan un camino para validar o verificar el punto de vista del usuario sobre la forma en que opera el sistema en uso. 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íscos 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 retrosprectiva de la implantación actual y proporciona la Página -11-

12 base para examinar la combinación de procesos, flujo de datos, almacenes de datos, entradas y salidas sin importarnos los dipositivos 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 una area de la Organización, el analista necesita obtener una visión del sistema. Primero los elementos físicos: personas, documentos, listados. No es dificil recordar lugares o personas importantes (' Este trabajo lo realiza Perez ', ' 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. Página -12-

13 CLIENTES no aceptado Encargado de Recepción comprobado Clasificar por áreas 2 s clasificados 1 Imposible servir pedido Sección de producción s despachados Enviar a sección de producción 3 4 figura 13: DFD físico sistema de pedidos 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. Página -13-

14 no aceptado CLIENTES Registrar 1.1 recibido Comprobar 1.2 comprobado PEDIDOS Encargar recursos a producción 4.2 aceptado RECURSOS Comprobar recursos disponibles 4.1 Imposible servir pedido CLIENTES figura 14: Conversión al DFD lógico 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. Página -14-

15 También se añaden al nuevo DFD los procesos registrar pedido y encargar recursos a producción. Imposible producir CLIENTES Registrar 1 recibido Comprobar Factibilidad Producción 2 aceptado PEDIDOS RECURSOS Encargar Recursos a Producción 3 figura 15: DFD lógico sistema de pedidos 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 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: Página -15-

16 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) 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 comun 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. Página -16-

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 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 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 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. Página -17-

18 4.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 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 Evaluación y verificación del diagrama de flujo de datos Es fundamental verificar con cuidado todos los diagrmas 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 Página -18-

19 (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 4.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. Página -19-

20

21 Página -21-