Un diagrama de flujo de datos es una forma de representar un flujo de datos a través de un proceso o un sistema (normalmente un sistema de información ). El DFD también proporciona información sobre las salidas y entradas de cada entidad y del proceso en sí. Un diagrama de flujo de datos no tiene flujo de control : no hay reglas de decisión ni bucles. Las operaciones específicas basadas en los datos se pueden representar mediante un diagrama de flujo . [1]
Existen varias notaciones para visualizar diagramas de flujo de datos. La notación presentada anteriormente fue descrita en 1979 por Tom DeMarco como parte del análisis estructurado .
Para cada flujo de datos, al menos uno de los puntos finales (origen y/o destino) debe existir en un proceso. La representación refinada de un proceso puede realizarse en otro diagrama de flujo de datos, que subdivida este proceso en subprocesos.
El diagrama de flujo de datos es una herramienta que forma parte del análisis estructurado y el modelado de datos . Cuando se utiliza UML , el diagrama de actividades normalmente asume el papel del diagrama de flujo de datos. Una forma especial de plan de flujo de datos es un plan de flujo de datos orientado al sitio.
Los diagramas de flujo de datos pueden considerarse como redes de Petri invertidas , porque los lugares en dichas redes corresponden a la semántica de las memorias de datos. Análogamente, la semántica de las transiciones de las redes de Petri y los flujos de datos y funciones de los diagramas de flujo de datos deben considerarse equivalentes.
La notación DFD se basa en la teoría de grafos , utilizada originalmente en la investigación operativa para modelar el flujo de trabajo en las organizaciones, y en la informática para modelar el flujo de entradas y salidas a través de los cálculos. [2] [3] DFD se originó a partir de la metodología de técnica de diseño y análisis estructurado a mediados de la década de 1970. [3] Fue propuesto por primera vez por Larry Constantine, [4] y popularizado por Edward Yourdon , Tom DeMarco, [5] Chris Gane y Trish Sarson, [6] [7] quienes enriquecieron la técnica de diagramación con diferentes notaciones, prácticas de diccionario de datos [5] y orientación para la descomposición jerárquica de procesos. [6]
El objetivo principal de los diagramas de flujo de datos en el contexto del diseño estructurado era construir sistemas modulares complejos, racionalizando las interdependencias entre los diferentes módulos. [3] Los diagramas de flujo de datos (DFD) rápidamente se convirtieron en una forma popular de visualizar los principales pasos y datos involucrados en los procesos del sistema de software. Los DFD se usaban generalmente para mostrar el flujo de datos en un sistema informático, aunque en teoría también se podían aplicar al modelado de procesos de negocios . [8] Los DFD eran útiles para documentar los principales flujos de datos o para explorar un nuevo diseño de alto nivel en términos de flujo de datos. [9]
El DFD consta de procesos, flujos, almacenes y terminadores. Existen varias formas de ver estos componentes del DFD. [10]
Proceso
El proceso (función, transformación) es una parte de un sistema que transforma entradas en salidas. El símbolo de un proceso es un círculo, un óvalo, un rectángulo o un rectángulo con esquinas redondeadas (según el tipo de notación). El proceso se nombra con una palabra, una frase corta o una frase que exprese claramente su esencia. [7]
Flujo de datos
El flujo de datos (flujo, flujo de datos) muestra la transferencia de información (a veces también material) de una parte del sistema a otra. El símbolo del flujo es la flecha. El flujo debe tener un nombre que determine qué información (o qué material) se está moviendo. Las excepciones son los flujos en los que está claro qué información se transfiere a través de las entidades que están vinculadas a estos flujos. Los cambios de material se modelan en sistemas que no son meramente informativos. El flujo solo debe transmitir un tipo de información (material). La flecha muestra la dirección del flujo (también puede ser bidireccional si la información hacia/desde la entidad es lógicamente dependiente, por ejemplo, pregunta y respuesta). Los flujos vinculan procesos, almacenes y terminadores. [7]
Depósito
El almacén (datastore, almacén de datos, archivo, base de datos) se utiliza para almacenar datos para su uso posterior. El símbolo del almacén son dos líneas horizontales, la otra forma de visualización se muestra en la notación DFD. El nombre del almacén es un sustantivo plural (por ejemplo, pedidos) que deriva de los flujos de entrada y salida del almacén. El almacén no tiene por qué ser simplemente un archivo de datos, sino que también puede ser, por ejemplo, una carpeta con documentos, un archivador o un conjunto de discos ópticos. Por lo tanto, la visualización del almacén en un DFD es independiente de la implementación. El flujo desde el almacén generalmente representa la lectura de los datos almacenados en el almacén, y el flujo hacia el almacén generalmente expresa la entrada o actualización de datos (a veces también la eliminación de datos). El almacén está representado por dos líneas paralelas entre las que se encuentra el nombre de la memoria (puede modelarse como un nodo de búfer UML). [7]
Terminador
El terminador es una entidad externa que se comunica con el sistema y se encuentra fuera del mismo. Puede ser, por ejemplo, varias organizaciones (por ejemplo, un banco), grupos de personas (por ejemplo, clientes), autoridades (por ejemplo, una oficina de impuestos) o un departamento (por ejemplo, un departamento de recursos humanos) de la misma organización, que no pertenece al sistema modelo. El terminador puede ser otro sistema con el que se comunica el sistema modelado. [7]
Los nombres de las entidades deben ser comprensibles sin más comentarios. El DFD es un sistema creado por analistas basados en entrevistas con usuarios del sistema. Está determinado para desarrolladores de sistemas, por un lado, contratistas de proyectos por el otro, por lo que los nombres de las entidades deben adaptarse para el dominio del modelo o usuarios aficionados o profesionales. Los nombres de las entidades deben ser generales (independientes, por ejemplo, individuos específicos que realizan la actividad), pero deben especificar claramente la entidad. Los procesos deben estar numerados para facilitar el mapeo y la referencia a procesos específicos. La numeración es aleatoria, sin embargo, es necesario mantener la coherencia en todos los niveles del DFD (ver Jerarquía del DFD). El DFD debe ser claro, ya que se recomienda que el número máximo de procesos en un DFD sea de 6 a 9, el mínimo es de 3 procesos en un DFD. [1] [7] La excepción es el llamado diagrama contextual donde el único proceso simboliza el sistema modelo y todos los terminadores con los que se comunica el sistema.
El DFD debe ser coherente con otros modelos del sistema: diagrama de relación de entidad , diagrama de transición de estado , diccionario de datos y modelos de especificación de proceso . Cada proceso debe tener su nombre, entradas y salidas. Cada flujo debe tener su nombre (excepción: consulte Flujo). Cada almacén de datos debe tener un flujo de entrada y salida. Los flujos de entrada y salida no tienen que mostrarse en un DFD, pero deben existir en otro DFD que describa el mismo sistema. Una excepción es el almacén que se encuentra fuera del sistema (almacenamiento externo) con el que el sistema se comunica. [7]
Para que el DFD sea más transparente (es decir, no demasiados procesos), se pueden crear DFD de varios niveles. Los DFD que están en un nivel superior son menos detallados (agregan DFD más detallados en niveles inferiores). El DFD contextual es el más alto en la jerarquía (consulte las Reglas de creación de DFD). El llamado nivel cero es seguido por el DFD 0, comenzando con la numeración de procesos (por ejemplo, proceso 1, proceso 2). En el siguiente, el llamado primer nivel, DFD 1, la numeración continúa. Por ejemplo, el proceso 1 se divide en los primeros tres niveles del DFD, que están numerados 1.1, 1.2 y 1.3. De manera similar, los procesos en el segundo nivel (DFD 2) están numerados 2.1.1, 2.1.2, 2.1.3 y 2.1.4. El número de niveles depende del tamaño del sistema modelo. Los procesos DFD 0 pueden no tener el mismo número de niveles de descomposición. El DFD 0 contiene las funciones del sistema (agregadas) más importantes. El nivel más bajo debe incluir procesos que permitan crear una especificación de proceso para aproximadamente una página A4. Si la mini especificación debe ser más larga, es adecuado crear un nivel adicional para el proceso donde se descompondrá en múltiples procesos. Para obtener una visión general clara de toda la jerarquía DFD, se puede crear un diagrama vertical (transversal). El almacén se muestra en el nivel más alto donde se utiliza por primera vez y también en cada nivel inferior. [7]
Medios relacionados con Diagrama de flujo de datos en Wikimedia Commons