Monografías Plus »

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:

 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:

Ejemplos de nombres de procesos:

Monografias.com

Monografias.com

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:

 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:

 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.

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. 

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.  

Monografias.com

 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:

 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:

Monografias.com

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.

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

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.

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:

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 

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:

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

Típicamente describen:

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.

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.

Ejemplo de tabla de decisión típica. 

 

1

2

3

4

5

6

7

8

Edad >21

Y

Y

Y

Y

N

N

N

N

Sexo

M

M

F

F

M

M

F

F

Peso >100

Y

N

Y

N

Y

N

Y

N

Medicamento 1

X

 

 

 

X

 

 

X

Medicamento 2

 

X

 

 

X

 

 

 

Medicamento 3

 

 

X

 

 

X

 

X

Ningún Medicamento

 

 

 

X

 

 

X

 

 

Lenguaje Narrativo.

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

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.

Monografias.com

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

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.

Monografias.com

 

Monografias.com

 

 

Autor:

Cabello, Simón

Enviado por:

ASESOR ACADÉMICO:

MSc. Ing. Iván J. Turmero Astros

Monografias.com

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