Diagramas de Flujo de Datos: una guía para su construcción

Diagrama de Flujo de Datos

 ¿Qué es un Diagrama de Flujo?

Es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por conductos y tanques de almacenamiento de datos. Proporciona un punto de vista de un sistema, el orientado a funciones.

Podemos encontrarlo en la literatura con los siguientes sinónimos:

•  Carta de burbujas.

•  DFD (abreviatura que usaremos).

•  Diagrama de burbujas.

•  Modelo de proceso.

•  Diagrama de flujo de trabajo.

•  Modelo de función.

•  Una imagen de lo que sucede. 

 Un poco de Historia.

Los DFD se utilizaron por primera vez en la ingeniería de software como notación para el diseño de sistemas (por ejemplo, en los libros y artículos de diseño estructurado tales como [STEVENS, MYERES y CONSTANTINE, 1974] y otros). A su vez, la notación se toma prestada de artículos anteriores sobre teoría de gráficas, y continúa siendo utilizada por los ingenieros de software que trabajan en la implantación directa de modelos de los requerimientos del usuario.

 Guía para la construcción de un DFD.

Algunas de estas reglas ayudan a no elaborar un DFD erróneo (como incompleto o inconsistente). Además puede ayudarle a que aumentar las probabilidades de que el usuario lo lea con mas cuidado.

Las Reglas incluyen las siguientes:

•  Elegir nombres con significado para los procesos, flujos, almacenes y terminadores.

•  Numerar los procesos.

•  Redibujar el DFD tantas veces como sea necesario estéticamente.

•  Evitar los DFD demasiado complejos.

•  Asegurarse de que el DFD sea internamente consistente y que también lo sea con cualquier DFD relacionado con él.

•  Elegir nombres con significado para los procesos, flujos, almacenes y terminadores

•  Un proceso en un DFD puede identificar una función que se está llevando a cabo, o puede identificar como se está llevando a cabo identificando a la persona o grupo; en este último caso identifique la tarea que se realiza no nombres de personas.

•  Etiquete los procesos de manera que se puedan identificar las funciones que el sistema está llevando a cabo. Un buen sistema que se puede utilizar para nombrar procesos es usar un verbo y un objeto. Es decir, elegir un verbo activo y un objeto apropiado para formar una frase descriptiva para el proceso.

Ejemplos de nombres de procesos:

• CALCULAR TRAYECTORIA DE PROYECTIL.

• PRODUCIR INFORME DE INVENTARIO.

• VALIDAR NUMERO TELEFONICO.

• ASIGNAR ESTUDIANTE A LA CLASE. 

Pedro nombre invalido para un proceso. 

  Resultará fácil utilizar verbos y objetos específicos si el proceso es relativamente simple y está bien definido. Sin embargo, aún en casos sencillos hay tentación por utilizar nombres ambiguos como: HACER, MANEJAR y PROCESAR. Cuando se utilizan verbos tan elásticos (con significados para cubrir casi cualquier situación) a menudo significa que el analista no está seguro de cual función se está llevando a cabo o que se han agrupado diversas funciones que en realidad no debieran agruparce.

Estos son algunos nombres de proceso no adecuados:

HACER ALGO.

MANEJAR ENTRADAS.

ENCARGARCE DE PROCESOS.

EDICIÓN GENERAL.

Los nombres de procesos (al igual que los nombres de flujos y terminadores) deben provenir de un vocabulario que tenga algún significado para el usuario. Esto sucederá de manera muy natural si el DFD se dibuja como resultado de una serie de entrevistas con los usuarios y si el analista tiene algún entendimiento mínimo de la materia de aplicación. Debe tener en cuenta dos precauciones:

•  Evitar en lo posible el uso de abreviaturas y acrónimos específicos con los que están familiarizados los clientes (Ej. Consigue copia de la forma 107, forma rosada y se la manda a José una vez llena). Una buena forma de evitarlo es elegir (como LLENAR) y objetos (como FORMA 107) que tendría sentido para alguien que trabaje en la misma industria, pero en una organización diferente.

•  Si el DFD lo dibuja alguien con conocimientos en programación habrá tendencia a utilizar terminología orientada a la programación, tal como RUTINA, PROCEDIMIENTO, FUNCION, aunque muchos términos no tienen significado para el usuario. Evite usarlos a menos que el usuario los maneje.

 Numerar los procesos.

Es una buena forma de referirse a los procesos de un DFD. No importa como se haga esta numeración, de izquierda a derecha, de arriba abajo, mientras haya constancia en la forma de aplicar los números.

Lo que deberá tener en cuenta es que para algunos lectores del DFD la numeración implicará secuencia, podría preguntarle ¿ la burbuja 1 sucede primero y luego la 2?. Esto no es así en absoluto, el modelo de DFD es una red de procesos asincrónicos que se intercomunican; representan la manera en que en realidad muchos sistemas operan. Alguna secuencia podría implicarse por la presencia por la presencia o secuencia de datos (Ej. Puede resultar que la burbuja 2 no pueda realizar su función hasta que no reciba datos de la burbuja1) pero el esquema de numeración no tiene nada que ver con eso.

Entonces, para que numerar los procesos; primero para poder referirnos en una discusión a una burbuja por su número en vez de por su nombre. En segundo lugar, y más importante aún, los números se convierten en base para la numeración jerárquica cuando se introduzcan diagramas de flujos por niveles.

 Redibujar el DFD tantas veces como sea necesario estéticamente.

En un proyecto real de análisis de sistema, el DFD se dibujará tantas veces como se necesite antes de: ser técnicamente correcto, ser aceptable para el usuario, estar lo suficientemente bien dibujado como para que no embarazoso mostrarlo a la dirección de la organización.

¿Qué hace estéticamente agradable un DFD?

Tamaño y forma de las burbujas, procure que estas sean similares en tamaños para no crear confusiones acerca de importancia de un proceso en el proyecto. Otras organizaciones preferirán óvalos en vez de círculos.

Flujos Curvos vs. Rectos, sería lo ideal conocer que opción prefiere el observador; para muchos será lo mismo para otros no, lo mismo sucede con las flechas cruzadas.

 Evitar los DFD demasiado complejos.

 El propósito de un DFD es modelar de manera precisa las funciones que deberá llevar a cabo un sistema y las interacciones entre ellas. Otro propósito de este es ser leído y comprendido, no sólo por quien construye el modelo sino también por los usuarios que participan. Entonces el diagrama deberá: ser fácilmente entendido, fácilmente asimilado y placentero a la vista.

Una regla importante a tener en cuenta es la de no crear DFD con demasiados procesos, flujos, almacenes y terminadores. Por lo general no debiera haber más de media docena de procesos, flujos, almacenes y terminadores relacionados en un mismo diagrama. Otra regla dice que el DFD deberá caber fácilmente en una hoja normal.

 Asegurarse de que el DFD sea internamente consistente y que también lo sea con cualquier DFD relacionado con él.

Las principales reglas para asegurar la consistencia de un DFD son:

•  Evite sumideros infinitos, burbujas que tienen entradas pero no salidas.

•  Evite burbujas de generación espontánea, que tienen salidas sin tener entradas; son generalmente erróneas.

•  Cuidado con flujos y procesos no etiquetados, suele indicar falta de esmero; pero peor aún confusión respecto a la información que contienen.

•  Cuidado con almacenes de solo lectura o solo escritura, esta regla es similar a la de los procesos de solo entradas o solo salidas, los almacenes comunes deben tener tanto entradas como salidas. La única excepción son los almacenes externos que sirve de interfaz entre el sistema y algún terminador externo. 

 DFD por Niveles

Anteriormente se sugirió que debían evitarse los DFD demasiado complejos, pero si el sistema es intrínsecamente complejo y tiene decenas o incluso cientos de funciones que modelar ¿qué debemos hacer?. La respuesta es organizar el DFD global en una serie de niveles de modo de que cada uno proporcione sucesivamente más detalles sobre una porción del nivel anterior.

El DFD de primer nivel consta de solo una burbuja, que representa el sistema completo; los flujos de datos muestran las interfaces entre el sistema y los terminadores externos (junto con los almacenes externos que podría haber).

Este DFD se conoce como Diagrama de Contexto.

El DFD que sigue del diagrama de contexto se conoce como la figura 0. Representa la vista de más alto nivel de las principales funciones del sistema, al igual que sus principales interfaces.

•  Los números en las burbujas sirven también para relacionar una burbuja con el siguiente nivel de DFD, que la describe más a fondo.

Ejemplo: la burbuja 3 de la figura 0 se asocia con un DFD inferior, conocido como figura 3, las burbujas de la figura 3 se numeran 3.1, 3.2, 3.3, etc. 

•  Si una burbuja tiene nombre (debe tenerlo), este se utiliza en la figura de nivel inmediato inferior como nombre de la figura.

Ejemplo: si la burbuja 2.2, se llama CALCULAR IMPUESTO DE VENTA, entonces la figura 2.2, que parte la burbuja 2.2 en más detalle debe etiquetarse "figura 2.2: CALCULAR IMPUESTO DE VENTA".

Esta es una buena manera de organizar un DFD bastante grande en un grupo de piezas manejables. Ahora, existen aspectos importantes que debemos conocer al trabajar con niveles:

 ¿Cuántos niveles debe tener un DFD?

Como se dijo antes en la construcción de DFD no complejos; cada DFD debe tener en lo posible, hasta 6 burbujas y almacenes relacionados. Si se ha partido un sistema grande en tres niveles, pero sus DFD de nivel más bajo contiene 20 burbujas, entonces falta un nivel más por lo menos. Existe otro consejo para la mini- especificación de proceso de una burbuja de nivel más bajo y es que sino podemos escribirla razonablemente en una hoja, entonces es muy compleja y necesitamos un nivel más.

 ¿Existen reglas acerca del número de niveles de un sistema típico?

En un sistema simple, se encontraran probablemente dos o tres niveles; uno mediano, tendrá generalmente de tres a seis niveles y uno grande, tendrá de cinco a ocho niveles.

Recuerde que, él número total de burbujas tiene un crecimiento exponencial a medida que descendemos de nivel.

 ¿Deben partirse todas las partes del sistema con el mismo nivel de detalle?

No, algunas partes del sistema pueden ser más complejas que otras y pueden requerir uno o más niveles de partición.

 ¿Cómo se muestran estos niveles al usuario?

Muchos usuarios querrán ver solo un diagrama: un usuario ejecutivo de alto nivel puede querer ver solo el diagrama de contexto, otro más operacional solo la parte que lo involucra. Pero si alguien desea ver con más detalle el sistema, entonces tendrá sentido mostrar los diagramas de manera descendente; comenzando con el diagrama de contexto hasta el nivel más bajo de detalle.

 ¿Cómo asegurarse de que los niveles de DFD serán consistentes entre sí?.

Este suele ser un tema crítico ya que en un gran proyecto podrían estarse encargando distintas personas de cada nivel. Para asegurarnos existe una regla sencilla: los flujos de datos que entran y salen de una burbuja en un nivel dado deben corresponder con los que entran y salen en toda la figura en el nivel inmediato inferior que la describe.

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

Aquí la redundancia se introduce deliberadamente. La regla es mostrar el almacén más alto donde sirve de interfaz entre dos o más burbujas; luego mostrarlo en cada diagrama de nivel inferior que describa más a fondo dicha burbuja de interfaz. Ahora, como corolario decimos: los almacenes locales que utilicen solo las burbujas en una figura de menor nivel, no se muestra en el nivel superior; puesto que se incluye de manera implícita en un proceso de un nivel inmediato superior.

Ejemplo de DFD por niveles.  

 Diccionario de Datos

No vamos ha desarrollar aquí este tema con la profundidad que merece solo vamos a explayarnos un poco más es sus características más relevantes.

¿ Porque se necesita un Diccionario de Datos en un proyecto de desarrollo de sistemas?.

No posee el atractivo gráfico de los diagramas; pero sin él, el modelo de los requerimientos del usuario no puede considerarse completo. Es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento común de todas las entradas, salidas, componentes de almacenes y cálculos internos.

El diccionario de datos define los datos haciendo lo siguiente:

•  Define el significado de los flujos y almacenes que se muestran en el DFD.

•  Describe la composición de agregados de paquetes de datos que se muestran a lo largo de flujos, paquetes complejos (ej. Domicilio de un cliente), que pueden descomponerse en unidades más elementales (como ciudad, estado y código postal).

•  Describe la composición de los datos en los almacenes.

•  Especifica los valores y unidades relevantes de piezas elementales de información en los flujos de datos y en los almacenes de datos.

•  Describe los detalles de las relaciones entre almacenes que se enfatizan en un diagrama de entidad – relación.

 Notación del Diccionario de Datos.

Existen muchos esquemas de notación comunes utilizados por los analistas de sistemas. El que se muestra a continuación es uno de los comunes y utiliza varios símbolos sencillos:

Como mostrar el diccionario de datos al usuario.

El diccionario de datos lo crea el analista durante el desarrollo del modelo del sistema, pero el usuario debe ser capaz de leerlo y entenderlo para poder verificar el modelo.

La aceptación del usuario de la notación del diccionario, es todo un tema; puesto que esta se ve algo matemática; pero el número de símbolos que el debe aprender es muy pequeño.

Es muy difícil en realidad que el usuario quiera verificar el diccionario de datos; lo más probable es que verifique que el diccionario es correcto en conjunto con el DFD, el diagrama de entidad – relación, el diagrama de transición de estados o la especificación del proceso que este leyendo.

 Implantación del Diccionario de Datos.

Ahora le sugerimos solo algunos de los tantos aspectos que es necesario recordar para la construcción de un buen Diccionario de Datos. Muchos dependen de la herramienta que estemos utilizando para la confección.

•  Puede verse forzado a limitar los nombres de los datos a una cierta longitud. En este caso utilice abreviaturas representativas y claras.

•  Puede que no le permita utilizar símbolos como – y deba utilizar _. O pude que le exija utilizar prefijos en todos los nombres.

•  Puede verse obligado a asignar atributos físicos (como número de bytes, etc.).

•  No utilice acentos, muchas herramientas hacen distinción; al igual que de mayúscula y minúscula.

•  Puede que esté obligado a no dejar espacios en blanco entre palabras, en estos casos utilice guión bajo (_). 

 Especificaciones del Proceso

No se hará aquí una investigación profunda, puesto que no es nuestro eje central, si resaltaremos las principales características del tema.

 ¿Qué es la especificación del proceso?.

La especificación del proceso es la descripción de lo que sucede en cada burbuja primitiva de nivel más bajo en un DFD. También se las conoce como Mini- especificación.

El propósito de una especificación del proceso es bastante claro: define lo que debe hacerse para transformar entradas en salidas. Es una descripción detallada de la política de negocios del usuario que cada burbuja lleva a cabo.

Deberá cumplir con los siguientes requerimientos:

•  La especificación del proceso debe expresarse de una manera que puedan verificar tanto el usuario como el analista. Por esto se evita el lenguaje narrativo como herramienta de especificación, suele confundir cuando expresa condiciones booleanas compuestas (combinadas con AND, OR y NOT).

•  El proceso debe especificarse en una forma que pueda ser comunicada efectivamente al público amplio que este involucrado. Puede suceder con tablas de decisiones, con el lenguaje estructurado o con otras herramientas de especificación; en gran medida dependerá del humor o la personalidad de los usuarios con los usuarios con los que trate.

La confección de la especificación es una tarea difícil, puesto que el usuario suele describir la especificación en términos en los que la lleva a cabo en la actualidad. Su trabajo será destilar de esto la esencia de lo que dicha política es no como se lleva a cabo hoy en día.

Una buena herramienta no debe imponer (o implicar) decisiones de diseño e implantación arbitraria.

 Herramientas Principales de Especificación de Proceso.

• Lenguaje Estructurado (español, ingles, etc.).

• Pre/Post condiciones.

• Tablas de Decisión. 

• Lenguaje Estructurado.

Es el lenguaje español (ingles u otro) con estructura. Es un subconjunto de todo el idioma con importantes restricciones sobre el tipo de frases que pueden utilizarse y la manera en que puedan juntarse dichas frases.

Los verbos deben elegirse de un pequeño grupo de verbos orientados a la acción como:

Conseguir (o aceptar o leer).

Dividir.

Poner (o mostrar o escribir).

Calcular.

Encontrar (buscar o localizar).

Borrar.

Sumar.

Encontrar.

Restar.

Validar.

Multiplicar.

Mover.

Reemplazar.

Fijar.

Ordenar.

Los objetos (el tema de las frases imperativas sencillas) deben consistir solo en datos definidos en el diccionario o en términos locales. Los términos locales son aquellos que se definen explícitamente en una especificación de proceso individual, son solo conocidos, relevantes y con significado dentro de dicha especificación de proceso. Un ejemplo es un cálculo intermedio que se produce para una salida final del proceso.

El lenguaje estructurado permite que se combinen frases en unas cuantas formas limitadas que se toman de las construcciones de la programación estructurada.

•  La construcción SI-ENTONCES-OTRO se utiliza para describir frases alternativas que se deben realizar según el resultado de la decisión binaria.

•  La construcción CASO se utiliza para describir frases alternativas que se efectuarán basándose en los resultados de una decisión multivaluada.

•  La construcción HACER-MIENTRAS se usa para describir una frase que deberá llevarse a cabo repetitivamente hasta que alguna condición booleana se haga verdadera. Una variante es REPITE-HASTA.

Desventaja.

La principal desventaja del lenguaje estructurado es que si el analista compone una especificación de proceso demasiado compleja para ser entendida y verificada por el usuario, entonces falló. Para evitar esto se sugieren las siguientes reglas:

•  Restrinja la especificación de proceso a una pagina de texto (66 líneas), si ocupa más de una página seguramente el proceso es muy complejo y debe partirse en un nivel más.

•  No permita más de tres niveles de anidamiento.

•  Evite confusión en los niveles de anidamiento utilizando sangrías.

Ejemplo:

Gran-total=0

HACER-MIENTRAS haya mas pedidos que procesar

Total_de_pedidos = 0

LEER el siguiente pedido de PEDIDOS

HACER-MIENTRAS haya mas artículos en el pedido

Total_de_pedidos = Total_de_pedidos + numero_de_articulos

FIN HACER

MOSTRAR numero_de_pedido, Total_de_pedidos

Gran_total = gran_total + total_de_pedidos

FIN HACER

MOSTRAR gran_total 

•  Pre/Pos condiciones.

Las pre/pos condiciones son una manera conveniente de describir la función que debe realizar el proceso, sin decir mucho del algoritmo que se utilizará. Uno de los aspectos que la haría útil es cuando el analista está razonablemente seguro de que existen muchos algoritmos distintos que podrían utilizarse.

Las pre- condiciones describen todas las cosas que deben darse antes de que el proceso pueda comenzar a ejecutarse.

Describirán lo siguiente:

•  Que entradas se encuentran disponibles.

•  Que relación debe existir entre las entradas.

•  Que relación debe existir entre entradas y almacenes de datos.

•  Que relaciones deben existir entre diferentes almacenes o dentro de un almacén dado.

De manera similar, las post- condiciones describen lo que debe darse cuando el proceso ha concluido.

Típicamente describen:

•  Las salidas que generará o producirá el proceso.

•  Las relaciones que existirán entre los valores de salida y los valores originales de entrada al proceso.

•  Las relaciones que existirán entre los valores de salida y los valores en uno o varios de los almacenes.

•  Los cambios que se hayan dado en los almacenes.

Ejemplo de especificación narrativa.

Precondición 1

El comprador llega con un numero_de_cuenta que

Corresponde con un número de cuenta en CUENTAS,

Cuyo código_de_status se pone en "válido".

Postcondición 1

Se produce una factura con numero_de_cuenta y monto_de_venta

Precondición 2

La precondición 1 falla por algún motivo (el numero_de_cuenta no se encuentra en CUENTAS, o él código_de_status no es "valido")

Postcondición 2

Se produce un mensaje de error.

•  Tablas de Decisión.

Se utilizan cuando el proceso debe producir alguna salida o tomar alguna acción basada en decisiones complejas. En especial si las decisiones se basan en diversas variables distintas y dichas variables pueden tomar diversos valores.

•  Si existen N variables con valores binarios (verdadero – falso), entonces existirán 2**n(dos elevado a la N) reglas distintas.

•  Debe discutirse cada regla con el usuario para asegurarse de que se ha identificado la acción o acciones correctas para cada combinación de variables.

•  No implica ninguna forma particular de decisión.

Ejemplo de tabla de decisión típica. 

Lenguaje Narrativo.

No es una herramienta recomendable para escribir especificaciones del proceso debido a:

•  Un vocabulario no restringido, hace que sea posible la descripción del proceso incluyendo términos que no estén definidos en el diccionario de datos y cuyo significado no quede claro.

•  Las acciones alternativas a menudo se expresan de manera burda y ambigua.

•  Los ciclos también se expresan burda y ambigua.

•  El concepto de estructura de bloque solo puede expresarse con sangrías; si lo necesita conviene usar lenguaje estructurado.

Diagramas de Flujo.

Si el diagrama de flujo se usa solo para describir lógica detallada y si el analista de sistemas se limita a los símbolos de elaboración de diagrama de flujo equivalente a las construcciones en español estructurado, entonces no tiene nada de malo su uso. Para crearlos, el analista tiene que organizar su lógica con las combinaciones anidadas de los símbolos del diagrama de flujo.

Los símbolos de BOHM-JACOPINI en un diagrama de flujo estructurado  

•  Los Diagramas de NASSI-SHNEIDERMAN.

A mediados de Los años 70, se introducen como técnica estructurada de creación de diagramas de flujos. Son más organizados, más estructurados y más comprensibles que un diagrama de flujos típico; por esto a veces se los prefiere como herramienta para crear especificaciones del proceso.

Requieren una cantidad no trivial de gráficos y no está claro que los gráficos añadan mucho valor.

  Ejemplo de Diagramas de NASSI-SHNEIDERMAN.

Autor:

Cabello, Simón

Enviado por:

ASESOR ACADÉMICO:

MSc. Ing. Iván J. Turmero Astros

UNIVERSIDAD NACIONAL EXPERIMENTAL POLITÉCNICA

"ANTONIO JOSÉ DE SUCRE"

VICE-RECTORADO PUERTO ORDAZ

DEPARTAMENTO DE INGENIERÍA INDUSTRIAL

SISTEMAS DE INFORMACIÓN

SECCIÓN: N1

PUERTO ORDAZ, JULIO DE 2007