Diagramas de flujos de datos: teoría y práctica

Introducción

EL DIAGRAMA DE FLUJO DE DATOS ilustra una de las técnicas para representar "Soluciones" a problemas del Mundo Real en forma visual, es decir; en forma grafica.

Esta técnica mediante graficas de Diagrama de Flujo, ilustra como diseñar los procedimientos o sentencias con coherencia lógica, que representan la solución al problema planteado.

Hasta la presente década, para el desarrollo de cursos, tales como Algoritmos y Estructuras de Datos, no ha existido un Software que permita implementar el Diagrama de Flujo del problema planteado y que en especial permita su Ejecución (Compilación) y ver los resultados dentro del mismo diagrama de flujo, según el objetivo del problema. Es decir, se puede comprobar la lógica de su algoritmo, sin utilizar algún Compilador Real o Lenguaje de Programación específico (Turbo Pascal, Borland C++ 5.0, entre otros).

El Diagrama de Flujo de Datos es un producto desarrollado en la Universidad del Magdalena Santa Marta, Colombia. Este producto, cubre en forma eficiente la ejecución de programas usando Estructuras de Control, Vectores, matrices y Programación Modular Dependiente, pero el Software tiene limitaciones para implementar problemas usando Registros, Archivos, Punteros y Diseño de Programación Independiente, los Programas, fuentes.

Puede encontrarse en las textos de : Algoritmos en Borland Pascal For Windows versión 7.0 o en el texto Algoritmos y sus Aplicaciones en Borland C++ 5.0. Obras publicadas por el autor.

Diagrama de flujo de datos

 Es un modelo que describe los flujos de datos o tuberías, los procesos que cambian o transforman los datos en un sistema, las entidades externas que son fuente o destino de los datos (y en consecuencia los límites del sistema) y los almacenamientos o depósitos de datos a los cuales tiene acceso el sistema, permitiendo así describir el movimiento de los datos a través del sistema.

Un Diagrama de Flujo de Datos es una descripción gráfica de un procedimiento para la resolución de un problema. Son frecuentemente usados para describir algoritmos y programas de computador. Los diagramas de flujo de datos están compuestos por figuras conectadas con flechas. Para ejecutar un proceso comienza por el INICIO y se siguen las flechas de figura a figura, ejecutándose las acciones indicadas por cada figura; el tipo de figura indica el tipo de paso que representa.

DFD es un software diseñado para construir y analizar algoritmos. Se puede crear diagramas de flujo de datos para la representación de algoritmos de programación estructurada a partir de las herramientas de edición que para éste propósito suministra el programa. Después de haber ingresado el algoritmo representado por el diagrama, se podrá ejecutar, analizar y depurar en un entorno interactivo diseñado para éste fin. La interfaz gráfica de Dfd, facilita en gran medida el trabajo con diagramas ya que simula la representación estándar de diagramas de flujo en hojas de papel.

En síntesis, el Diagrama de Flujo de Datos describe:

• los lugares de origen y destino de los datos (los límites del sistema).

• las transformaciones a las que son sometidos los datos (los procesos internos).

• los lugares en los que se almacenan los datos dentro del sistema, y

• los canales por donde circulan los datos.

Características:

• Relevante: Ya que posibilitar comunicar diferentes modelos para así facilitar el entendimiento entre el usuario y el analista de sistemas.

• Lógico: Ya que no identifica soporte físico.

• Descendente: Se construye en forma descendente, de lo general a lo particular.

 El DFD posee niveles de desagregación o explosión o apertura de burbujas. El Nivel 0 ó Diagrama de Contexto es aquel que muestra una sola burbuja y las entidades externas ó terminadores con los que interactúa el sistema.

Uso de Los Diagramas de Flujos de Datos

  Los diagramas de flujos de datos son una técnica de análisis estructurado que van de lo general a lo específico muestran las posibles entradas, procesos y salidas del sistema. Los diagramas son usados cuando los analistas tratan de comprender los requerimientos de información de los usuarios de una manera gráfica utilizando solo cuatro símbolos combinados entre sí.

El uso de los diagramas de flujo de datos da ciertas ventajas como pueden ser las siguientes:

 a)    Libertad para realizar en forma temprana la implementación técnica de un sistema.

b)    Mejor comprensión entre las interrelaciones de los sistemas y los subsistemas.

c)     Comunicación del conocimiento del sistema actual a los usuarios por medio de diagramas de flujos de datos.

d)    Análisis de un sistema propuesto para determinar si han sido definidos los datos y los procesos necesarios.

Los diagramas de flujos de datos utilizan cuatro símbolos básicos como los son un cuadrado doble para representar las entidades del sistema,  una flecha para representar los flujos dentro del sistema, un rectángulo con esquinas redondas para representar los procesos y un rectángulo con un lado abierto para representar los almacenamientos de datos.

Cada elemento del diagrama de flujos de datos debe estar debidamente identificado, tanto los procesos como los almacenamientos de datos, como los flujos y las entidades.

El primer diagrama ayuda al analista a ilustrar el movimiento de datos básicos. El diagrama de contexto (Lo que llamamos el nivel 0 del diagrama), contiene un único proceso que representa al sistema en general; en este nivel 0 se muestran todas las entidades externas y los flujos de datos que entran y salen del sistema. Dentro de dicho nivel no se colocan los almacenamientos de datos.

El proceso del diagrama 0 se explota y se crea un diagrama hijo el cual no puede tener entradas ni salidas que no las tenga el diagrama padre o diagrama de contexto.  En este diagrama cada proceso debe llevar el mismo número que en el diagrama padre para así poder identificar que proceso esta siendo explotado, al mismo tiempo este número debe esta acompañado de un punto decimal y un número único para cada proceso hijo.

En los diagramas hijos no son mostradas las entidades externas. Cada proceso debe puede o no ser explotado, todo esto depende de cuan complejo sea. Los procesos que no son explotados son llamados procesos primitivos.

En la realización de los diagramas de flujos de datos no puede existir comunicación entre entidades, dichos flujos deben salir o llegar a un proceso, al mismo tiempo cada proceso debe tener al menos un flujo de entrada y uno de salida, en caso de no ser así se estaría produciendo un error en la creación del diagrama. Un flujo no puede ser divido, es decir que un mismo flujo no se puede dividir para llegar a dos destinos distintos.

Los almacenamientos de datos no pueden estar conectados con entidades externas. Un diagrama no debe tener mas de nueve procesos ya que crea confusión a la hora de ser leído, es por eso que se deben agrupar los procesos que trabajen juntos y colocarlos en un diagrama hijo.

 Existen dos tipos de diagramas de flujo de datos:

a)    El diagramas de flujos de datos lógico que es el que se enfoca en el negocio y en la manera en que opera el negocio. En este diagrama no importa la manera que en el sistema va a ser realizado o construido. Es por esto que solo describe los eventos del negocio que suceden y los datos requerido y producidos por cada evento. La utilización de estos diagramas tiene ciertas ventajas como es que puede existir mejor comunicación con los usuarios, sistemas más estables, que el analista comprenda mejor el funcionamiento del negocio o como se maneja el negocio.

b)    El diagrama de flujos de datos físico es todo lo contrario, en este diagrama se muestra como va a ser realizado el sistema incluyendo tanto el hardware como el software del sistema. La utilización de los diagramas de flujos de datos físicos también tiene algunas ventajas como son el de calificar los tipos de procesos, describen procesos a mayor detalle, identifican almacenamientos de datos temporales, añaden controles para asegurar que los procesos son realizados adecuadamente.

Los diagramas de flujos de datos son útiles en el análisis y diseño de sistemas ya que nos permiten ver o visualizar de una forma clara como va a ser el funcionamiento del sistema que se quiere realizar. Estos diagramas se realizan luego de haber recolectado y analizado el resultado de entrevistas, cuestionarios, etc. Hechos a los futuros usuarios del sistema.

 Análisis de Sistemas utilizando diccionarios de datos

Los diccionarios de datos son otro método u otra herramienta que ayuda con el análisis y diseños de sistemas. Los diccionarios de datos son parte de las herramientas case y pueden ser creados con el fin de recolectar, confirmar y coordinar lo que significa un término de datos para diferentes personas dentro de la organización, en otras palabras le permite al analista saber el concepto de los datos, estos diccionarios son una herramienta muy importante en los grandes sistemas que producen miles de elementos de datos.

Los diccionarios de flujos de datos pueden ser usados para validar el diagrama de flujos de datos y para verificar que este esté competo y preciso. Al mismo tiempo dan un punto de inicio a la hora de desarrollar pantallas y reportes, así como determinan el contenido de los datos almacenados en archivos.

          Dentro de los diccionarios de flujos de datos se deben guardar los flujos de datos dándoles un nombre único para este flujo, este nombre debe ser el mismo que aparece en el DFD, también se debe guardar una descripción general de los flujos, así mismo como el origen y el destino de dicho flujo. Se debe colocar también si el flujo es una entrada o una salida.

Las estructuras de datos son descritas por lo general usando notaciones algebraicas. Esto sirve para que el analista pueda crear una lista de los elementos que conforman la estructura de datos.

 La notación algebraica usa los siguientes signos:

  a)    = significa "esta compuesto de"

b)    + significa "y"

c)     { } indican los elementos repetidos

d)    [ ] representan una situación disyuntiva

e)    ( ) representan un elemento opcional

Existen estructuras de datos físicas y lógicas. Las estructuras de datos son los elementos que el usuario podrá ver mostrando los datos que el negocio necesita para su operación diaria. Luego de este diseño lógico, el analista diseña las estructuras de datos físicas que son los elementos adicionales para la implantación del sistema.

Los diccionarios de flujos de datos se crean luego de haber realizado los diagramas de flujos de datos o mientras se esta realizando el diagrama de flujos de datos.

Si se tiene prototipos o documentos de muestra, puede hacerse el diccionario de flujos de datos sin tener que haber hecho primero el diagrama de flujos de datos.

Para la creación de los diccionarios de flujos de datos es importante identificar los flujos de entrada y salida del sistema para poder organizar la información obtenida de entrevistas y análisis de documentos, al mismo tiempo para la creación de los diccionarios se debe desarrollar los almacenes de datos, ya que los almacenes de datos representan los datos en reposo. Los datos pueden estar almacenados de manera permanente o semi-permanente. Cuando los almacenes son creados únicamente para un reporte o pantalla se les llama lista de usuarios ya que de esa forma es que el usuario quiere ver la información.

Un diccionario de datos es ideal automatizado, en línea, evolucionario e interactivo. Mientras que el analista aprende sobre los sistemas de la organización, son añadidos conceptos de datos al diccionario de datos. La creación de los diccionarios de datos es una actividad que va de la mano con el análisis y diseño de sistemas. El diccionario de datos puede ser usado para crear pantallas y formas.

 Descripción de especificaciones de proceso y decisiones estructuradas

Las especificaciones de procesos son creadas para los procesos primitivos en los DFD así como para algunos procesos de más alto nivel que explotan hacia un diagrama hijo.

La producción de especificaciones de procesos tiene tres objetivos fundamentales los cuales son:

  a)    Minimizar la ambigüedad del proceso ya que permite al analista a aprender la manera en que trabajan los procesos.

b)    Obtener una descripción precisa de lo que se logra.

c)     Validar los diseños del sistema para asegurarse que un proceso tenga todos los flujos de datos para poder producir la salida.

Existen categorías de procesos que no necesitan especificaciones; estas categorías son las siguientes:

a)    Procesos que son de entrada o salida típica

b)    Procesos que representan validación de datos simple

c)     Procesos que usen códigos prescrito.

Para escribir en lenguaje estructurado es recomendable usar las siguientes convenciones:

a)    Toda la lógica debe estar expresada en términos de estructuras secuenciales, estructuras de decisión, de casos o iteraciones

b)    Dejar sangría en los bloques de enunciados para así demostrar la jerarquía.

c)     Cuando hayan palabras definidas en el diccionario de datos, dichas palabras deben ser subrayadas para indicar que tienen un significado especializado.

d)    Hay que tener cuidado al utilizar "y" o "o" para que no se confunda con "mayor que" o "menor que"

Las tablas de decisión son renglones y columnas separadas en cuatro cuadrantes, el primer cuadrante, es decir el cuadrante superior izquierdo, contiene la condición. El segundo cuadrante (cuadrante superior derecho), contiene las alternativas de condición. En la parte inferior izquierda están las acciones a ser tomadas y al lado inferior izquierdo las reglas para ejecutar las acciones.

Las tablas de decisión al ser utilizadas para ver que acciones son las que deben ser tomadas, la lógica se mueve en el sentido de las agujas del reloj comenzando por la esquina superior izquierda.

Para construir una tabla de decisión el analista necesita eliminar cualquier situación imposible, inconsistente, redundancias, y necesita simplificar la tabla lo mas que se pueda.

El analista debe determinar que condiciones pueden afectar la decisión, las acciones posibles que pueden ser tomadas, la cantidad de alternativas de condición para cada condición, calcular la máxima cantidad de columnas en la tabla de decisión multiplicando la cantidad de alternativas para cada condición, llenar las alternativas de condición, completar la tabla colocando una X donde las reglas sugieran determinadas acciones, combinar las reglas donde sea aparente que una alternativa no produce diferencia de salida, revisar la tabla por cualquier situación imposible y reacomodar las condiciones y las acciones.

Las tablas de decisión pueden crecer muy rápido según vaya aumentando la cantidad de condiciones y alternativas. Una manera de reducir la complejidad de las tablas es usando entradas extendidas, usar la regla SINO y crear varias tablas.

Los árboles de decisión se usan cuando ocurren ramificaciones complejas en un proceso de decisión estructurado. Para dibujar un árbol de decisión se utiliza un cuadrado para representar una acción y un círculo para representar una condición, al mismo tiempo hay que numerar cada círculo y cada cuadrado. Los cuadrados se pudiese decir que significan ENTONCES y los círculos SI.

Para dibujar un árbol de decisión se deben seguir los siguientes pasos:

a)    Identificar las condiciones

b)    Identificar las alternativas de condición

c)     Identificar las acciones

d)    Identificar las reglas de acción (en orden)

 Análisis de sistemas de apoyo a decisiones Semi-Estructuradas

          Un sistema de apoyo de decisiones se puede definir como un proceso que ayuda al tomador de decisiones a dar una respuesta más efectiva.

Para crear un sistema de apoyo a decisiones (DSS) el analista debe estar al tanto de los siguientes puntos importantes. Debe saber si los tomadores de decisiones son personas objetivas (analistas) o subobjetivas (heurísticas), de como son tomadas las decisiones en la resolución de problemas a nivel de inteligencia, diseño y selección y los métodos para resolución de problemas sem.-estructurados.

          Las características principales de un sistema de apoyo de decisiones son:

• Organizar la información que se va a usar en la toma de decisiones.

• Proporcionara nuevas perspectivas sobre el proceso de toma de decisiones que son atractivas y comprensibles.

• Ayudara a las decisiones que involucran problemas complejos que tienen forma semi-estructutrada.

Una de las teorías clásicas de un sistema de apoyo de decisiones es que asume que las decisiones son tomadas bajo tres condiciones. La certidumbre, es cuando el usuario sabe por anticipado que decisión tomara, la incertidumbre que es todo lo contrario y el factor riesgo.

Podemos decir que un tomador de decisiones es analista, cuando se apoya en la información que es adquirida y evaluada sistemáticamente, es decir, son personas metódicas que para llegar a una decisión pasan por una serie de pasos, ya sea utilizando operaciones matemáticas o pequeños algoritmos. Por otro lado están las heurísticas, estos son los que utilizan más la experiencia adquirida a graves de los años y aplican lineamientos propios, se basan en la prueba y error para encontrar una solución.

Los tomadores de decisión pasan por unas fases para la resolución de los problemas. La inteligencia es la conciencia de un problema u oportunidad, aquí el tomador busca problemas a resolver y oportunidades a examinar. En al fase de diseño, el tomador formula un problema y analiza varias soluciones para ver su aplicabilidad potencial. Y la última fase es la de selección.

Cuando hablamos de un problema semi-estructurado, nos referimos a los problemas que son parcialmente programables y que a su vez requieren discernimiento humano. Estas decisiones semi-estructuradas tienen ciertas dimensiones, la más destacada es el grado de habilidad para la toma de decisiones, se basa en la madurez y experiencia que tiene el tomador. Los DSS ayudan al tomador a definir cuales serán las variables posibles que pueden estar en la decisión y así poder reducir el grado de complejidad del problema. Y la cantidad de criterios de decisión considerados.

 Hoy en día existen varios enfoques para la toma de decisiones que ayudan al tomador de decisiones a ir de acuerdo a sus prioridades. Un enfoque es el uso de proceso de pro y contrahaz, es un estilo de tabla con dos columnas donde se muestra los pros en una columna y los contra en la otra y se van tachando uno con otro hasta encontrar el más efectivo. También existe el de métodos ponderados, en este método a todas las decisiones posibles el tomador le asigna una puntuación equivalente a todos los atributos que existan en diferentes softwares para luego quedarse con el paquete que tenga la calificación más alta.

El método de la eliminación secuencial por lexicografía es aquel que utiliza una tabla de comparación parecida a la de ponderación pero a su vez posee un rango. Se escogen las posibilidades de mayor puntaje del primer rango, luego las mayores puntaciones del segundo rango y así sucesivamente y después se toman las posibilidades que obtuvieron mayores puntaciones.

La eliminación secuencial por restricciones conjuntivas es cuando el tomador pone restricciones o estándares y luego pasa a eliminar las que no cumplan con esas restricciones, aquí mientras más restricciones mayor efectividad pero menor posibilidad de que una respuesta cumpla con todos los requisitos pedidos. Y el uso de programación por metas es un estilo mixto aquí podemos encontrar variables de decisión, prioridades y a veces ponderaciones, aquí el tomador debe tener la posibilidad de crear ecuaciones de objetivo.

Preparación de la Propuesta de Sistemas

En la preparación de las propuestas de sistemas el analista hace una destilación de todo lo que ha aprendido acerca del negocio y lo que necesita para mejorar su desempeño.

El analista primero que todo debe tener una idea con respecto al hardware y software que posee la empresa para manejar adecuadamente las cargas de trabajo. El analista hace un inventario del hardware computacional, aquí hace un lista de los productos que posee que pueden ser expandidos o que tienen que reciclarse, tales como: Tipo de equipo, numero de modelo, fabricante, el estado de operación del equipo, edad estimada, vida proyectada, ubicación física, persona que va utilizar el equipo y la propiedad del equipo (Propio, rentado, etc.), en fin tener una lista detallada de todos los accesorios que posea la maquina

Luego de que el analista hace el estudio de todo el hardware disponible, hace un cuadro comparativo donde mide la estimación de las cargas, es decir, en una columna muestra la máxima operacionalidad del hardware que posee la empresa y en la otra columna muestra lo que necesita el sistema propuesto. Si existe algún hardware que no cumpla con los requerimientos ahí es donde decide que habrá que actualizar el hardware que posee la empresa. De no ser así quedaría el hardware anterior a menos que la empresa decida estar al día con la tecnología y hace un cambio.

 Todo hardware debe ser evaluado para medir su rendimiento y aquí entran a trabajar los usuarios, los vendedores y los analistas, juntando todos sus conocimientos con respecto a los equipos, este proceso es llamado prueba de desempeño, aquí miden tiempo requerido para las transacciones promedio, la capacidad de volumen total del sistema, el tiempo inactivo de la unidad central de proceso y el tamaño de memoria proporcionado. Aquí es donde se define una respuesta final si hay que adquirir nuevos equipos.

          Ahora es cuando se hace la adquisición del hardware. Aquí se toman tres puntos importantes para adquirir el producto. Si se va a comprar, arrendamiento financiero o renta simple. No siempre la compra de un equipo es la opción correcta. Una de las ventajas de comprar es que es mas barato que el arrendamiento o renta a la larga, pero una desventaja es el riesgo de no poder continuar si la selección fue equivocada. Una ventaja de arrendamiento es que no requiere financiamiento, una desventaja es que la compañía no posee los equipos cuando finaliza el mismo. Para la renta la ventaja es que por lo general están incluidos mantenimiento y seguro, la desventaja es que el costo es muy alto debido a que el vendedor asume el riesgo. Todo va depender del uso y durabilidad del equipo que se vaya a adquirir.

           Otro punto importante aparte del hardware, es la evaluación del Software. Esta evaluación se basa en 6 puntos importantes tales como:

• Efectividad de desempeño; que sea capaz de realizar todas las tareas requeridas.

• Eficiencia de desempeño; tiempo de respuesta rápida, entrada y salida eficiente.

• Facilidad de uso; interfaz amigable, disponibilidad de menús de ayuda.

• Flexibilidad; Opciones para la entrada y la salida y compatibilidad con otro software.

• Calidad de documentación; Buena organización, tutorial adecuado.

• Soporte del fabricante; Línea directa, Actualizaciones

Para finalizar antes de hacer la propuesta se debe hacer una identificación y estimación de costos y beneficios, desde le punto de vista Costos/Beneficios y viceversa.  Existen muchas técnicas para comparar de costos y beneficios una de ellas es el análisis de punto de equilibrio se hace una comparación del costo del equipo actual con el propuesto y se lleva a un punto de equilibrio. Esta la técnica de recuperación es cuando se hace un estimado de las ganancias y se saca el tiempo en que pueden recuperar los gastos del equipo. Una muy parecida a la de recuperación es la de análisis de flujo de efectivo, que también se hace el estudio de los ingresos del equipo, de no ser así se hace un búsqueda de cerca buscando beneficios tangibles. Y el análisis de valor presente este consiste en comparar los costos actuales con los costos futuros y los beneficios actuales con los beneficios futuros. 

Escritura y presentación de la propuesta del sistema

          A la hora de hacer la propuesta escrita a la empresa, el analista debe tener en cuenta todo lo que ha venido recolectado y ensamblarlo de forma efectiva, tanto lógica como visualmente. La propuesta consta de 10 secciones principales donde cada una cumple una función específica, debe llevar la siguiente forma:

1.     Carta de presentación: Dentro de esta carta se incluye un pequeño resumen de los objetivos del sistema y una lista de las personas que hicieron el estudio.

2.     Pagina del titulo del Proyecto: Aquí lleva el nombre del proyecto, el nombre de los miembros del equipo y la fecha de entrega

3.     Tabla de contenido: Lleva todos los títulos y subtítulos mientras mas especifica mejor.

4.     Resumen ejecutivo: En este resumen encontramos el quien, que, cuando, donde, porque y como de la propuesta.

5.     Guión del estudio de sistemas con la documentación apropiada: Aquí se muestra los métodos usados, muestreo de datos de archivo, prototipos usados en el estudio.

6.     Resultados detallados del estudio de sistemas: Aquí se reflejan todos los resultados arrojados por el estudio, se indican los problemas que hay con el sistema existente

7.     Alternativas de sistemas: El analista muestra dos o tres alternativas que solucionen los problemas, es obligatoria que una de ellas es la de mantener el sistema como esta.

8.     Recomendaciones del analista de sistemas: El equipo de trabajo da una opinión acerca de cual solución es mas operable, dan las razones de por que escogieron ese sistema.

9.     Resumen: Es un resumen muy general que proviene del resumen ejecutivo pero con menos detalle.

10. Apéndices: Aquí el analista coloca cualquier punto que el crea que es de interés para el usuario.

El uso de tablas también es método bastante efectivo en la entrega de la propuesta, se utilizan más que todo para presentar y agrupar datos analizados durante todo el proceso. Es recomendable que la tabla quepa en una sola pagina, que este bien numerada y titulada, que todos sus renglones tengan sus identificaciones, si posees códigos puede definirlos en la parte superior de la hoja.

          Graficas de barras, pasteles, etc… Pueden usarse para comparar variables, otras muestran composición de 100 por ciento de una entidad, hay mucha información que se puede representar a graves de una grafica. Los lineamientos para incluir graficas. Incluir una grafica por pagina amenos que se quiera hacer una comparación con otra, enumere la grafica y de un titulo significativo, etiquete cada eje, líneas, columnas, barras o rebanadas de pastel grafica y es bueno incluir una leyenda si es necesaria. Las graficas más utilizadas son las siguientes: Grafica de líneas, en columnas, de barra y de pastel.

          Es recomendable que estas graficas, tablas o cifras estén ubicadas es la paginas siguiente de la referencia de la misma. Siempre deben estar mencionadas en los textos anteriores. Interpretar figuras en palabras, ponerles títulos a todas las figuras, si es necesario usar más de una figura para que el punto importante quede claro.

          Finalmente llegamos a la presentación de la propuesta, este es el punto más importante, ya que el analista dará su presentación en público a la empresa. En esta presentación se deben tomar muchos puntos en cuenta. Primero que todo el analista debe demostrar que tiene un amplio conocimiento del sistema, deberá hablar con bastante fluidez, es muy útil utilizar ayudas visuales, debe dirigirse al publico en todo momento, hablar con voz alta y clara, reflejar confianza, en fin desde utilizar colores llamativos hasta la forma de respirar.

Simbología

Entidad Externa:

Son generalmente clases lógicas de cosas o de personas, las cuales representan una fuente o destino de transacciones, como por ejemplo clientes, empleados, proveedores, entre otros, con las que el sistema se comunica. También pueden ser una fuente o destino específico, como por ejemplo Departamento Contable.z

Como el sistema que esta bajo análisis acepta datos de otro sistema o bien se los provee, este otro sistema es una Entidad Externa.

Mediante la designación de alguna cosa o de algún sistema como Entidad Externa estamos estableciendo implícitamente que se encuentra fuera de los límites del sistema que estamos considerando por lo cual no nos interesa la transformación o proceso que se realiza dentro de ellos, es decir que están fuera del control del sistema que se está modelando. Son sólo proveedores o requeridores de datos del sistema bajo consideración.

Por todo ello, ni el analista ni el diseñador pueden cambiar ni los contenidos ni la forma de trabajo de un terminador.

Proceso:

Indican aquellos lugares dentro del sistema en donde la información (flujos de datos) que ingresan, se procesan o transforman. Es decir, son las funciones o procesos que transforman entradas de datos en salidas de información.

Su nombre deberá ponerse mediante una frase imperativa, que consistirá idealmente de un verbo activo seguido por una claúsula objeto, cuanto mas simple mejor. Al analista le servirá pensar que la descripción de la función es "una orden a un empleado sin conocimiento del tema". Estas frases imperativas no tienen sujeto; tan pronto como se introduce un sujeto se habrá indicado como deberá realizarse físicamente la función ("El operador ingresará los datos del alumno").

Un proceso puede ser físicamente una oficina repleta de empleados, un procedimiento, o una combinación de actividades manuales y automatizadas.

 Flujo de datos:

Representa un transporte de paquetes de datos desde su origen hasta su destino, es decir que representa una estructura de datos en movimiento de una parte del sistema a otro. Un flujo muestra las interfaces entre los elementos del DFD.

Puede imaginarse como una tubería por donde se envían paquetes de datos, pero deberá tener una descripción de su contenido la cual deberá elegirse de forma que sea lo más útil posible a los usuarios que revisen el DFD. La flecha indica la dirección del flujo.

Puede estar contenido físicamente en una nota, una factura, una llamada telefónica, de programa a programa, etc. Es decir, en cualquier medio por el cual los datos pasan de una entidad o proceso a otra.

 Almacén o archivo:

Representa un archivo lógico en donde se agregan o de donde se extraen datos. Es una estructura de datos, pero estática. Puede ser físicamente un archivo de tarjetas, una microficha, un archivo, o un archivo en cinta o diskette. Deberá elegirse el nombre que sea más descriptivo para el usuario, que identifique los paquetes de datos que contiene.

Guía para la construcción de DFD

Además de la regla básica que existen para la elaboración de DFD tal como, los componentes básicos de DFD son: proceso (burbuja) flujo, almacenes y terminadores. Existen otras reglas adicionales que nos permitirán no elaborar DFD erróneos y gratos a la vista de los usuarios.

Las reglas incluyen las siguientes:

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

• Numerar los procesos.

• Evitar los DFD excesivamente complejos.

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

• Asegurarse de que el DFD sea lógicamente consistente y que también sea con cualesquiera DFD relacionados con él.

• Extensiones del DFD para sistemas de tiempo real.

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

Un proceso en un DFD puede representar una función que se está llevando a cabo, o pudiera indicar cómo se está llevando a cabo, identificando a la persona, grupo o mecanismo involucrado.

Un buen sistema que se puede utilizar para nombrar procesos es usar un verbo y un objeto. Es decir, escoja un verbo activo (un verbo transitivo que tenga objeto) y un objeto apropiado para formar una frase descriptiva para el proceso. Los siguientes son ejemplos de nombres de procesos:

• Calcular trayectoria del proyectil.

• Producir informe de inventario.

• Validar número telefónico.

• Asignar estudiante a la clase.

Los nombres de los procesos (al igual que los nombres de flujos y de terminadores) deben provenir de un vocabulario que tenga algún significado para el usuario.

• Numerar los procesos.

Como una forma conveniente de referirse a los procesos en un DFD, muchos analistas numeran cada burbuja. No importa mucho como sea haga esto, de izquierda a derecha, de arriba abajo o de cualquier otra manera servirá, mientras haya constancia en la forma de aplicar los números.

La única cosa que se debe tener en mente es que el sistema de numeración implicará, para algunos lectores casuales de su DFD, una cierta secuencia de ejecución. Esto es, cuando se muestre el DFD a un usuario, él pudiera preguntar: ¿Acaso la burbuja número 1 sucede primero, luego la 2 y luego la 3? Y esto no es así en absoluto. El modelo de DFD es una red de procesos asincrónicos que se intercomunican, lo cual es, de hecho, una representación precisa de la manera en la que en realidad muchos sistemas operan.

Un ejemplo de la funcionalidad de enumerar las burbujas es el siguiente: Es más fácil en una discusión sobre un DFD decir " burbuja 1" en lugar de "Editar transacción y reportar errores". Pero de mayor importancia aún es el hecho de que los números se convierten en base para la numeración jerárquica.

• Evitar los DFD excesivamente complejos.

El propósito de un DFD es modelar de manera precisa las funciones que debe llevar a cabo un sistema y las interacciones entre ellas. Pero otro propósito del DFD es ser leído y comprendido, no sólo por el analista que construyó el modelo, sino por los usuarios que sean los expertos en la materia de aplicación.

Existe una regla principal para la elaboración de un DFD, que se debe tener en mente: no cree un DFD con demasiados procesos, flujos, almacenes y terminadores. En la mayoría de los casos, esto significa que no debería haber más de media docena de procesos y almacenes, flujos y terminadores relacionados en un solo diagrama.

Existe una excepción importante a esto, un diagrama especial 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.

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

En un proyecto real de análisis de sistemas el DFD debe dibujarse y volver a dibujar a menudo hasta 10 veces o más, antes de 1) ser técnicamente correcto, 2) ser aceptable para el usuario y 3) estar lo suficientemente bien dibujado como para que no sea embarazoso mostrarlo a las dirección de la organización.

¿Qué hace estéticamente agradable a un DFD?. Esto es obviamente una cuestión de gustos y puede determinarse por normas dispuestas por su organización o por las características particulares de cualquier paquete que utilice de diseño de diagramas basado en una estación de trabajo automatizada. Y la opinión de usuario pudiera ser un tanto diferente de la suya; lógicamente, cualesquiera cosas que el usuario encuentre agradable debe determinar la manera de la que se dibuje el diagrama.

Se debe revisar que el DFD sea lógicamente consistente.

Las principales reglas de consistencia son:

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

• Evitar las burbujas de generación espontánea, que tienen salidas sin tener entradas, porque son sumamente sospechosas y generalmente incorrectas.

• Tener cuidado con los flujos y procesos no etiquetados. Esto suele ser un indicio de falta de esmero, pero puede esconder un error aún más grave: a veces el analista no etiqueta un flujo o un proceso porque simplemente no se le ocurre algún nombre razonable.

• Extensiones del DFD para sistemas de tiempo real.

Para los sistemas de tiempo real necesitamos alguna manera de 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). Se muestran gráficamente con líneas punteadas en el DFD.

 Todos los elementos se relacionan entre sí a través de flujos de datos. 

Procesos: Se relacionarán con:

• Almacenes: Se relacionarán solamente con Procesos.

• Entidades externas. Se relacionarán solamente con Procesos.

• Otros procesos

Deberán tener al menos una Entrada y una Salida, no son manantiales de datos. 

En todos los niveles del Diagrama de Flujo de Datos deberá haber igual cantidad de Entradas y de Salidas.

Niveles del DFD:

Nivel de Partida: Diagrama de Contexto:

• No existirán almacenes o archivos.

• Se representarán las entidades externas que son fuente y destino de los datos.

• El sistema será representado como un proceso simple.

• Se dibujarán sólo los flujos de datos de comunicación exterior-sistema.

Nivel 1 y subsiguientes:

Deberá haber igual cantidad de archivos. Aunque podrá existir mayor cantidad de almacenamientos en el nivel 2 debido a la explosión de algún proceso. En el último nivel, cada proceso realizará una función específica y concreta.

 Cada proceso en el DFD de alto nivel de un sistema puede ser "explotado" para convertirse en un DFD en si mismo.

 En el nivel inferior cada proceso deberá estar relacionado, inversamente, con el proceso del nivel superior. Es decir que, cada proceso "padre" que se detalla en el DFD, ha de estar balanceado. La regla del balanceo consiste en que cada proceso debe tener exactamente los mismos datos de entrada/salida netos que el DFD hijo.

 Los flujos de datos pueden descomponerse en la "explosión" del proceso en un DFD hijo.

 No se deberá prestar atención a las condiciones de tiempo, excepto a las naturales precedencias lógicas y a los almacenamientos de datos necesarios desde el punto de vista lógico. Se deberá dibujar un sistema que nunca comience ni pare.

 Para evitar el cruzamiento de las líneas de flujo de datos, la misma entidad (o el mismo almacén) se podrá dibujar mas de una vez en el mismo diagrama; las dos (o mas) casillas por entidad pueden identificarse con dos líneas inclinadas en el ángulo superior izquierdo de las mismas.

Al mirar un DFD típico para un sistema chico se nota lo siguiente:

• Requiere poca explicación.

• Cabe fácilmente en una página.

• Se dibujó con computadora.

DFD por niveles

Organizar el DFD global en una serie de niveles de modo que cada uno proporcione más detalle sobre una porción del nivel anterior. El primer nivel consta de una sola burbuja que representa la totalidad del sistema (diagrama de contexto). El DFD que sigue se conoce como nivel 0 y representa la vista de más alto nivel de las principales funciones del sistema.

Los números de las burbujas sirven para relacionar una burbuja con el nivel siguiente del DFD.

DFD jerarquizados

No es eficiente trabajar con diagramas muy extensos, en los que parezcan muchos procesos.

En una jerarquía de DFDs se distinguen:

? de contexto: es el diagrama situado en la raíz del árbol, muestra su interacción con el entorno.

? intermedio: como su nombre indica son nodos del árbol no terminales.

? primitivas funcionales: son los procesos a los que no corresponde ningún DFD en un nivel inferior.

Tipos de Datos

• Real: valores numéricos que van desde -1*10 ^ 2000 hasta 1*10 ^ 2000. Los valores más cercanos a 0 que se pueden manejar son 1*10 ^ -2000 y -1*10 ^ -2000.

Ejemplo: 1998, 1.0007, 0, 328721, -3242781

• Cadena de Caracteres: secuencia de caracteres encerrada entre comillas simples.

Ejemplo: "Diagramar es fácil", "París", "1955".

• Lógico: la letra V ó F encerrada entre puntos, para indicar verdadero ó falso respectivamente.

Ejemplo: .V. , .F. , .v. , .f.

Campos de Datos

• Constantes: con su nombre muestran su valor y éste no se puede cambiar.

Ejemplo: 1996, "Los algoritmos son útiles", .V.

Variables: es posible modificar su valor. El nombre de una variable debe comenzar por una letra seguida de letras, números o el caracter ( _ ).

Ejemplo: Valor, Contador, año, Valor_1.

No se tiene en cuenta la diferencia entre mayúsculas y minúsculas para el nombre de una variable; es decir, CASA equivale a casa. Cuando una variable recibe un valor por primera vez, el tipo de dato de ésta será igual al tipo de dato del valor.

Arreglos

Dfd soporta arreglos n-dimensionales de cualquier tipo de dato. El nombre de un arreglo debe comenzar por una letra seguida de letras, números o el carácter ( _ ).

Ejemplo: Vector ( 5 ) , Matriz ( i , j ) , v ( 7, j, ñ, p )

Partes: 1, 2