Cualquier aplicación de software que utilice un negocio o una organización que administra información, requiere del ingreso de datos para poder transformarlos en información.

Otra de las herramientas de la que puedes hacer uso para expresar los requerimientos es el diagrama de flujo de datos. Se trata de una técnica de análisis estructurado que permite observar de forma gráfica los procesos de datos que utiliza una organización.

Esta herramienta no es parte formal del grupo de diagramas UML, sin embargo, es ampliamente utilizada en proyectos de ingeniería de software, ya que es sencilla de implementar, comunica la transformación de los datos a través de diferentes procesos de una forma simple y además es posible ir incorporando mayor detalle sobre lo que sucede en dentro de los procesos a través de niveles.

8.1 Fundamentos del modelo de flujo de datos

En opinión de Pressman (2010), el modelo de datos y el diagrama de flujo de datos es todo lo que se necesita para obtener una visión significativa de los requerimientos de algunas aplicaciones de software.

El modelo es bastante útil para diferentes personas involucradas en el proyecto de desarrollo de software. Por ejemplo:

Para el ingeniero de requerimientos, permite modelar flujos de información independiente de su implantación física, además que no le impone una carga de trabajo al tener que definir si los procesos que transforman la información son manuales o automáticos. Será labor del diseñador del software determinar este mecanismo.

Para el usuario final (stakeholder) es muy sencillo comprender los diagramas porque no requieren de conocimientos técnicos detallados sobre cómo se implementa un software, a diferencia del modelo de clases en el que se debe explicar el paradigma orientado a objetos.
El mismo usuario puede realizar diagramas de flujo de datos que pueden servir para documentar sus procesos internos como parte del sistema de gestión de la calidad.

Para el ingeniero diseñador de software, los diagramas son bastante útiles ya que aclaran las estructuras de datos necesarias, los repositorios y las interfaces fundamentales que se necesita implementar.

Según Kendall y Kendall (2011), algunas de las ventajas que este modelo tiene son:

8.2 Creación del modelo de flujo de datos.

El diagrama de flujo de datos (DFD) utiliza una combinación de 4 símbolos básicos:

Haz clic en el nombre de cada símbolo para conocer el detalle

Imagen recuperada de Kendall E., Kendall, J. (2011). Systems analysis and design (8ª ed.). New Jersey: Prentice Hall. Figura 7.1. Sólo para fines educativos.

Las 7 reglas del juego

Para crear un modelo de flujo de datos se tienen que seguir algunas reglas esenciales, considéralas como si fueran las reglas de un juego de mesa.

1. Un diagrama de flujo debe tener al menos 1 proceso.
2. Todo proceso debe tener al menos un flujo de entrada y un flujo de salida.
3. Los flujos de datos que entran a un proceso nunca deberán ser los mismos, es decir, el flujo deberá cambiar de etiqueta.
4. No deben existir conexiones directas entre entidades o entre almacenes de datos, o entre entidades y almacenes. Este tipo de comunicación no es parte del sistema que representa el diagrama.
5. Las entradas y salidas de niveles inferiores debe corresponder con las entradas y salidas de niveles superiores.
6. Ningún elemento del diagrama puede permanecer incomunicado (sin conexión alguna).
7. Por simplicidad, un diagrama de flujo de datos no debe tener más de 9 procesos.

Diagrama de contexto o diagrama de nivel 0

Al modelar el sistema a través de un DFD, se inicia con un diagrama de contexto o también llamado diagrama de nivel 0, que expresa el sistema de manera más general. Este diagrama permite establecer las fronteras del sistema y es la perspectiva más amplia del sistema. Contiene solo un proceso que representa el sistema y se incluyen las entidades que participan ingresando o solicitando información del sistema.
Puedes hacerte las siguientes preguntas para ayudarte a construir el diagrama de contexto identificando las entidades y los flujos de datos principales.

• ¿Quiénes participan en el sistema?
• ¿Existe alguna entidad (sistema o persona) que requiera obtener información?
• ¿Para que el sistema genere información, qué entidades introducen información?

Diagrama nivel 0

A partir de este diagrama se dibujan los siguientes niveles, como si estuvieras haciendo un zoom con una cámara para ver qué hay adentro del proceso 0. El recuadro gris de fondo te permite expresar la frontera del sistema.

Diagrama Nivel 1

Imagen de Nivel 1. Obtenida de libro de Kendall E. y Kendall, J. (2011). Systems analysis and design (8ª ed). New Jersey: Prentice Hall. Figura 7.3. Sólo para fines educativos.

Observa como el DFD mantiene una consistencia entre las entradas y salidas del nivel 0 al nivel 1. La entidad 1, entidad 2 y entidad 3 aparecen en ambos niveles, así como la Entrada A, Entrada B y la Salida C.
Intenta revisar las reglas del juego anteriores y verifica cómo todas se cumplen.

Para determinar los procesos necesarios, piensa lo que se necesita para que las entradas produzcan las salidas del sistema. La numeración de los procesos del nivel 1 inicia de izquierda a derecha y de arriba abajo.

Creación de niveles inferiores:
Los niveles inferiores del DFD son necesarios para detallar lo que sucede dentro de los procesos. Es importante que cuides de igual manera la consistencia del flujo de información con respecto a los diagramas superiores. La numeración de los procesos inferiores corresponde al proceso que se detalla de tal suerte que facilite su trazabilidad. Así por ejemplo si se detallan los subprocesos del proceso 1, entonces la numeración empezará en el 1.1.

Diagrama Nivel 2

Adecuación a la imagen obtenida de libro de Kendall E. y Kendall, J. (2011). Systems analysis and design (8ª ed.). New Jersey: Prentice Hall. Sólo para fines educativos.

En este nivel de detalle es posible incluir otros flujos de datos y almacenes que no aparecen en niveles superiores, como el Flujo A, Flujo B, Registro B y el almacén D3 que puedes observar en el Nivel 2 del proceso 1.

No todos los procesos requieren subniveles si es que el proceso no se descompone en otros subprocesos, como sucede con el Proceso 2 y el Proceso 4 del ejemplo anterior, a estos procesos se les conoce como procesos primitivos.

8.3 Diccionario de datos

Un diccionario de datos funciona de la misma forma como lo hace un diccionario común, es decir, es una colección de palabras ordenadas de forma alfabética y ofrece un significado utilizando sinónimos que puedan ayudar a las personas a entenderlas. El diccionario de datos también es una colección, sólo que es una colección de datos ordenados de forma alfabética y define su estructura.

En opinión de Kendall y Kendal (2011), el objetivo principal de un diccionario de datos es mantener limpios los datos, esto quiere decir que deben mantenerse consistentes. Por ejemplo, si estuvieras registrando los datos de un cliente y estableces que pertenece a la región “N” para la región norte, significa entonces que “N” siempre se interpretará como región norte. Si utilizas otro acrónimo como “Nte” “north” o incluso “norte”, estarías siendo inconsistente al definir tus datos.  

Entender cómo están compuestos los datos a través del diccionario de datos, ayuda a conceptualizar el sistema, permite, a quienes participan en el proyecto de desarrollo, entenderlo mejor ya que describe las estructuras elementales del diagrama de flujo.

Cómo los diccionarios de datos se relacionan con los diagramas de flujo – Figura recuperada de Kendall E. y Kendall, J. (2011). Systems analysis and design (8ª ed.). New Jersey: Prentice Hall. Figura 8.1. Sólo para fines educativos.

Descripción de las estructuras de datos
El diccionario de datos describe estructuras de datos. Al relacionar este grupo de datos obtenemos cierta información a la que llamamos elementos de datos. Por ejemplo, el domicilio es una estructura de datos que está compuesta por los siguientes elementos de datos: calle, número, colonia, ciudad, país y código postal.

La forma que utiliza un diccionario de datos para describir las estructuras de datos es haciendo uso de la siguiente notación:

1. Signo = que significa está compuesto por.
2. Signo + que significa “y”.
3. Llaves { } que significa que los elementos se repetirán.
4. Corchetes [ ] que significa que incluye algún dato de una lista separada por comas. Los datos son mutuamente excluyentes.
5. Paréntesis ( ) que representa que el elemento puede o no ser incluido en la estructura.

Por ejemplo:

Ticket de Compra = nombre del establecimiento + dirección del establecimiento + fecha de compra + artículo comprado + precio unitario + cantidad + subtotal + total + método de pago + (cambio)

Dirección del establecimiento: calle + número + colonia + ciudad + país + código postal
Método de pago =  [efectivo, tarjeta de crédito. tarjeta de débito]

Observa que en la estructura ticket de compra incluye subestructuras que se definen posteriormente como dirección del establecimiento y método de pago.

Descripción de elementos de datos

En un diccionario de datos también se describe cada elemento de dato o también llamado campo. Cada elemento se describe utilizando el siguiente formato:

Descripción del elemento:

Características del elemento:

Criterio de validación:

Ejemplo de la descripción de un elemento:

Imagen obtenida de Kendall E. y Kendall, J. (2011). Systems analysis and design (8ª ed.). New Jersey: Prentice Hall. Figura 8.6. Sólo para fines educativos.

Existen diferentes tipos de elementos según el tipo de datos que se describen a continuación:

Con la estructura de datos anterior es posible describir los flujos de información de un diagrama de flujo de datos como el siguiente:

Imagen obtenida de Kendall E. y Kendall, J. (2011). Systems analysis and design (8ª ed.). New Jersey: Prentice Hall. Figura 8.11. Sólo para fines educativos

Observa cómo cada uno de los flujos son estructuras de datos descritas con campos específicos. Cada diccionario de datos puede describir estructuras de datos diferentes aunque se les nombre de la misma forma. Por ejemplo, el Registro Empleado puede estar compuesto por idempleado + nombre empleado + id_area. Cada organización describe sus propias estructuras de datos como mejor le convenga.

Asegúrate de poder:

• Interpretar las herramientas que ayudan a modelar sistemas para documentar los procesos internos de las empresas.
• Aplicar los diagramas de flujos de datos y el diccionario de datos como herramientas de la ingeniería de requerimientos del software para ayudar a documentar el sistema.

• Kendall E. y Kendall, J. (2011). Systems analysis and design (8ª ed.). New Jersey: Prentice Hall.
• Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7ª ed.) México: McGraw Hill.

• Flujo de información: es la transferencia de datos relacionados de un origen a un destino con la finalidad de proveer información que es útil para realizar alguna acción.
• Diagrama: es un dibujo que permite la abstracción de conceptos a través de elementos gráficos, con el objetivo de solucionar un problema.