Herramientas para el anlisis de flujo de datos

Las herramientas tienen el objetivo de ayudar a entender las caractersticas del

sistema. Por lo tanto no deben de ser un fin, sino un medio para el estudio del sistema.
Las herramientas utilizadas en el anlisis de flujo de datos son:
Diagrama de flujo de datos.
Diccionario de datos.
Diagrama entidad-relacin.
Miniespecificaciones o Especificacin de Procesos.
1. Diagramas de Flujo de Datos
Los diagramas de flujos de datos (DFD), es una tcnica de modelado, que nos
muestra un sistema como una red de procesos conectados entre ellos por flujos y
almacenamientos de datos.
Es un modelo que proporciona el punto de vista funcional de un sistema.
Los analistas deben trabajar con los usuarios para hacerles comprender el
funcionamiento del sistema actual y el sistema futuro, para ello se hace aconsejable
utilizar un lenguaje comn, sencillo y fiable, estas son las caractersticas de los diagramas
de flujo de datos. Los usuarios pueden hacer sugerencias para modificar los diagramas
con la finalidad de describir las actividades con mayor exactitud, y permitir evitar los
errores desde el inicio pudiendo prevenir una posible falla del sistema.
Notacin de los Diagrama Flujo de Datos
Los mtodos para el anlisis de flujo de datos fueron desarrollados y promovidos
por dos organizaciones al mismo tiempo, Yourdon Inc (compaa de consultora) y Mc
Donnell-Douglas (Gane and Sarson). En nuestro libro la notacin utilizada ser la de
Yourdon. Los DFD's se pueden dibujar con slo cuatro elementos grficos sencillos, que
son:
1) Procesos. Es el primer componente del DFD. El proceso muestra una parte del
sistema que transforma entradas en salidas. Suelen ser personas, procedimientos
o dispositivos que utilizan o transforman datos. Los sinnimos comunes son
burbuja, funcin o transformacin. El proceso se representa grficamente como un
crculo.

2) Flujo de datos. El flujo se usa para describir el movimiento de bloques de
informacin de una parte del sistema a otra. Por ello, los flujos representan datos
en movimiento. En algn modelo puede representar movimiento de material. Los
flujos muestran la direccin; segn si los datos se est moviendo hacia adentro o
hacia afuera de un proceso (o ambas cosas). El Flujo de Datos se representa
grficamente por medio de una flecha que entra o sale de un proceso.

Podemos hablar de varios tipos de flujos de datos, segn direccin/sentido de los
datos, respecto al proceso:
Entrada y Salida.
Divergente y Convergente.
Cuando una misma informacin se enva a procesos diferentes, o cuando una
informacin compleja se descompone en varios datos mas sencillos cada uno de los
cuales va a un proceso diferente (divergente). Varios paquetes de datos se juntan para
formar parte de paquetes de datos ms complejos (convergente).
A partir del contenido de los flujos podemos encontrar:
a) Dato Individual
Se refiere a que el flujo representa a slo un dato, indivisible
b) Grupo de Datos
En este caso el grupo corresponde a un conjunto de varios datos individuales, que
por necesidad del sistema no pueden separarse.
c) Paquete de Datos
El caso del paquete, se refiere a un grupo de grupos, esto es, un conjunto
repetitivo de un grupo en particular

3) Almacn de datos: El almacn se utiliza para modelar una coleccin de datos en
reposo. Es tentador asociar a los almacenes los archivos o bases de datos, es as
como a menudo se implantan en un sistema informtico, pero un almacn tambin
puede consistir en datos almacenados en cualquier soporte que contenga datos
(archivos de papel, tarjetas, etc.). El Almacn de Datos se representa grficamente
por dos lneas paralelas.


4) Entidad Externa (Terminador): Este componente del DFD representa fuentes
(origen) o destinos, externos de datos, que pueden ser: personas, programas,
organizaciones, sistemas u otras entidades que interactan con el sistema pero se
encuentran fuera de su frontera. Una Entidad Externa se representa grficamente
como un rectngulo.



Existen tres cosas importantes que debemos recordar acerca de las Entidades
Externas:
Son externos al sistema que se est modelando; los flujos que conectan los
terminadores a diversos procesos (o almacenes) en el sistema representan la
interfaz entre l y el mundo externo.
El analista de sistemas no puede modificar los contenidos, la organizacin ni los
procedimientos internos asociados en posibilidades de cambiar los contenidos de
un terminador o la manera en que trabaja. El terminador con lo que representa
est fuera del dominio.
Las relaciones existentes entre los terminadores no se muestran en el modelo
DFD. Si existen relaciones entre los terminadores y si es esencial para el analista
modelarlos para poder documentar los requerimientos del sistema, entonces, por
definicin, los terminadores son en realidad parte del sistema y debieran
modelarse como procesos.
Deberemos respondernos una serie de preguntas como: Cmo se piden los
datos?, En qu secuencia se reciben los datos? y En qu secuencia se generan?, pero
no deben ser respuesta de los DFD's, estas respuestas forman parte del procedimiento.
Los diagramas de flujo de datos se concentran en el movimiento de datos a travs
del sistema, no en los dispositivos o el equipo. Se identifican y describen los datos que
fluyen por todo el sistema, explicando porque los datos entran o salen y cual es el
procesamiento que se realiza con ellos (guardan y recuperan de almacenamiento de
datos).
Directrices para la construccin de DFD's
Hay una serie de reglas que son necesarias para poder construir los DFD's
correctamente. La finalidad de estas reglas es ayudar a confeccionar DFD's correctos, y
permitir dibujar un DFD agradable a la vista y por tanto que tenga mas probabilidades de
que sea estudiado por el usuario con el objetivo de ayudarle a su comprensin.
Las reglas a seguir para la construccin de un DFD son:
a. Elegir los nombres representativos para los procesos, flujos de datos,
almacenamientos y entidades externas de forma que describa lo ms
precisamente posible al objeto que representa.
Procesos: en el caso de los procesos debemos identificar las funciones que el
sistema est llevando a cabo, es decir el nombre del proceso describir lo que
se hace:
o Funcin: Verbo + objeto. El verbo no debe estar conjugado (terminaciones
ar, er e ir)
o Verbo significativo (Validar, Registrar, etc.).
o Evitar palabras de uso exclusivo por parte de usuario.
o Evitar terminologa informtica (Proceso, Funcin, Rutina, Procedimiento,
etc.).
Flujos: los flujos deben identificar la informacin y/o los datos que fluyen a
travs del sistema. Se deben evitar el uso de las palabras "informacin y dato".
o El nombre es una unidad, por lo tanto, si el nombre esta compuesto por
ms de una palabra, deber unirlas por un guin bajo ("_").
Almacenes: Los almacenes deben nombrarse con nombre que representen la
informacin y/o datos que estos contienen.
o Evitar el uso de palabras como Archivo, Almacn, etc.
Entidades: su nombre debe ser el que se utiliza tanto interna como
externamente al sistema, y no debe crear un nombre nuevo o particular de ella,
sino que usar el nombre universal de la entidad.
b. Numerar los procesos para identificarlos de forma rpida y unvoca.
Los nmeros no indican secuencia. El modelo de DFD es una red de procesos
asincrnicos que se intercomunican, lo cual es, una representacin precisa de
la manera en la realidad muchos sistemas operan. El hecho que existan
procesos no puedan realizar su funcin por falta de algn dato de otro proceso
no implica que corresponda con la numeracin. Son la base para crear la
jerarqua de diagramas cuando se introduzcan los diagramas de flujo por
niveles.
c. Evitar DFD excesivamente complejos y recargados, es decir, con muchos
elementos grficos juntos.
El propsito de un DFD es modelar de forma precisa las funciones que se
deben llevar a cabo un sistema y las interacciones entre ellas. Pero otro
propsito del DFD, de igual importancia, es que sea ledo y comprendido, no
slo por el analista que construyo el modelo, sino por los usuarios que no sean
expertos en la materia de aplicacin. Esto significa que el diagrama debe ser
fcilmente entendido, fcilmente asimilado y placentero a la vista.
Existe una excepcin, un DFD 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.
d. Consolidar flujos para ganar en legibilidad.
e. Re-dibujar el DFD tantas veces como sea necesario, con el objetivo de:
Conseguir un DFD tcnicamente correcto.
Aceptado por el usuario
Estar lo suficientemente bien dibujado como para que no sea embarazoso
mostrarlo a la direccin de la organizacin.
f. Asegurarse que el DFD es consistente.
Existen reglas para asegurar la consistencia del DFD con otros modelos de
sistemas; el diagrama de entidad-relacin, diagrama transicin de estados, diccionario de
datos, y la especificacin de procesos. Las principales reglas de consistencia son:
Evite sumideros infinitos, procesos que tienen entradas pero no salidas.
Evite burbujas de generacin espontnea, procesos que tienen salidas sin tener
entradas. Situacin normalmente incorrecta.
Cuidado con flujos y procesos no etiquetados, ya que puede esconder errores
importantes.
Tener cuidado con los almacenes de "slo lectura" o "slo escritura", ya que todo
almacenamiento debe tener un flujo entrante y uno saliente, es decir, la
informacin se almacena se consume.
Las entidades externas no pueden acceder directamente a ningn
almacenamiento. Siempre debe mediar un proceso que haga de intermediario y
extraiga o inserte la informacin pertinente.

Niveles de un DFD
Cuando nos enfrentemos ante un modelo real, nos enfrentaremos ante un DFD
grande y complejo. Deberemos evitar diagramas complejos y poco legibles, de acuerdo,
pero cmo? Si el sistema es intrnsecamente complejo y tiene decenas de funciones que
se constituyen de decenas de funciones menores. La respuesta es organizar el DFD
global en una serie de niveles de modo que cada uno proporcione sucesivamente ms
detalles sobre una porcin del nivel anterior. De modo que se construir una jerarqua de
diagramas, en donde cada nivel inferior es una expansin de un proceso del nivel
superior.
Como podemos ver lo que se pretende es descomponer un todo en piezas con el
objetivo de reducir la complejidad. Pero debemos responder una serie de preguntas:
1. Cmo saber cuntos niveles debe haber en un DFD?
No hay ninguna regla para decidir cuantos niveles ha de tener un DFD. Pero dado
que un DFD es aconsejable que no tenga ms de media docena de burbujas y almacenes
relacionados, si nos aparece un nivel que contenga un nmero muy superior deberemos
insertar un nuevo nivel a los que hubiere. Hay que procurar que haya equilibrio en la
distribucin de todos los elementos grficos entre todos los niveles del DFD.
2. Deberemos de dividir todas las partes del sistema con el mismo nivel de
detalle?
La respuesta ser que no. Algunas partes del sistema pueden ser ms complejas
que otras y pueden requerir uno o ms niveles de particin. En el caso que nos
encontremos con desigualdades respecto a la divisin de un proceso respecto a otros,
deberemos nivelar el DFD para lograr un equilibrio.
Sumidero de informacin Fuente de informacin
Los diagramas de flujo de datos no tienen utilidad si se dibujan en forma
inapropiada o ser manejados sin cuidado. Aunque no hay leyes que establezcan el
nmero de niveles, el nmero de procesos por niveles, la norma comn es definir cada
nivel inferior en trminos de tres a siete de procesos por cada proceso de nivel superior.
La utilizacin de ms de siete procesos hace que el diagrama sea difcil de manejar y
dibujar.
Lo importante es entender que los diagramas de flujo de datos lgicos son una
herramienta de apoyo para ayudar la comprensin del sistema de la Organizacin. De
modo que un diagrama deja de ser til cuando no es comprensible. Por lo tanto, debe
primar el sentido comn, y no determinar normas estrictas para su construccin.
3. Cmo nos aseguraremos que los niveles del DFD son consistentes entre
s?
Esta cuestin es importante, ya que normalmente existe un desarrollo entre
distintas personas en un proyecto real, as como una divisin del trabajo. Para asegurarse
que cada figura es consistente con su figura de ms alto nivel se sigue una regla sencilla:
"los flujos entrantes y salientes de una burbuja en un nivel dado deben corresponder con
los que entran y salen de toda la figura en su desagregacin", a esto se le llama
"balanceo de malla".
Si comprobamos el diagrama de contexto, y el diagrama de primer nivel, el primer
proceso tiene los mismos flujos de entrada, as como los flujos de salida, esto se debe a
que la explosin es consistente; los flujos de entradas o salidas del proceso de nivel
superior estn presentes en el diagrama de nivel inferior, y apareciendo nuevos flujos,
almacenes. Esto es precisamente uno de los puntos importantes de la expansin hacia
niveles inferiores: encontrar ms detalles relacionados con los procesos internos.
4. Dnde deben aparecer los almacenes?
La regla es la siguiente: "mostrar un almacn en el nivel ms alto donde
primeramente sirve de interfaz entre dos o ms burbujas; luego mostrarlo de nuevo en
cada diagrama de nivel inferior que describa ms a fondo dichas burbujas de interface".
Por lo tanto los almacenes locales, que utilizan slo las burbujas en una figura de menor
nivel, no se mostrarn en niveles superiores, dado que se incluyen de manera implcita en
un proceso del nivel inmediato superior.
Nivelacin es un trmino que se refiere al manejo de archivos locales (los
empleados dentro de un proceso). Los detalles relacionados con un solo proceso en un
determinado nivel deben permanecer dentro del proceso. Los almacenes y flujos de datos
que son relevantes nicamente para el interior del proceso, son ocultados hasta que el
proceso se extiende con mayor detalle.
Si nos fijamos en el diagrama de contexto, aparece un almacenamiento de datos
(datos del vendedor). Este almacn se crea fuera del sistema de facturas por pagar. Por
otro lado los almacenes de datos de facturas por pagar, rdenes de compra y cuentas por
pagar estn contenidos dentro del proceso, y aparecen en el prximo nivel cuando se
expansione el proceso. La convencin de nivelacin seala que estos almacenes son
internos al proceso, no entradas para l.
5. Cmo se realiza de hecho la particin de los DFD en niveles?
La situacin que nos imaginamos como ideal es la de comenzar con el diagrama
de contexto y luego desarrollar cada figura para trabajar de forma progresiva hasta los
niveles de bajo nivel. Sin embargo ste planteamiento nos dar problemas, de modo que
el enfoque ms aconsejable es identificar los acontecimientos externos a los cuales debe
responder el sistema y crear un primer DFD borrador. Veremos como esta primera
aproximacin del DFD puede suponer un punto de partida hacia arriba o hacia abajo.
6. Cul ser el ltimo nivel de desagregacin?
Para decidir cul es el ltimo nivel no debemos seguir profundizando mientras
halla procesos que puedan ser descompuestos en subprocesos, ni entrar en
descripciones de tal detalle sobre los procesos que estemos desarrollando su algoritmo.
Es decir, los ltimos niveles del DFD no deben convertirse en un organigrama del
algoritmo de cada proceso.
Diagrama de contexto

Explosin de un Proceso
Tipos de Diagramas de Flujo de Datos
Los diagramas de flujo de datos son de dos tipos:
1. Diagramas Fsicos de Flujo de Datos.
Proporcionan un panorama del sistema en uso, muestra las tareas que se llevan a
cabo y como se hacen. Las caractersticas fsicas incluyen:
Nombre de personas
Nombre o formatos de documentos
Nombres de departamentos
Archivo de maestro y de transacciones
Equipo y dispositivos utilizados
Ubicaciones
El empleo de estos diagramas es aconsejable por tres razones:
Para los analistas de sistema es ms fcil describir la interaccin entre los
componentes fsicos que comprender las polticas empleadas. De modo que
identifican las personas, lo que hacen, los documentos que inician las actividades
y el equipo para su procesamiento.
Los diagramas fsicos de flujos de datos son de utilidad para comunicarse con los
usuarios. Estos relacionan con facilidad a las personas, las ubicaciones y los
documentos ya que trabajan todos los das con estas entidades (Los diagramas
lgicos van a resultar abstractos para los usuarios).
Los diagramas fsicos proporcionan un camino para validar o verificar el punto de
vista del usuario sobre la forma en que opera el sistema en uso.
2. Diagramas Lgicos de Flujo de Datos.
Proporcionan un panorama del sistema independiente de la implantacin, que se
centra en el flujo de datos entre los procesos sin considerar los dispositivos especficos y
la localizacin de almacenes de datos o personas en el sistema. Los diagramas fsicos de
flujos de datos, no son un fin en si mismos, sino son un medio para describir la
implantacin del sistema existente. El diagrama lgico es una visin retrospectiva de la
implantacin actual y proporciona la base para examinar la combinacin de procesos, flujo
de datos, almacenes de datos, entradas y salidas, sin importarnos los dispositivos fsicos,
personas o aspectos de control que caracterizan la implantacin.
As que el diagrama lgico se obtiene del diagrama fsico al llevar a cabo lo
siguiente:
Sealar los datos necesarios en este momento para un proceso, no documentos
que los contienen.
Indicar los flujos entre los procedimientos y no entre personas, oficinas o
localidades.
Eliminar herramientas y dispositivos.
Eliminar informacin de control.
Consolidar los almacenes de datos redundantes.
Eliminar los procesos innecesarios (los que no cambian los datos, independientes
de los dispositivos donde ocurren, los que representan un proceso nico dentro del
sistema).
Evaluacin y verificacin del diagrama de flujo de datos
Es fundamental verificar con cuidado todos los diagramas de flujo para determinar
si son correctos. La presencia de lo que parece ser un error seale una deficiencia en el
sistema. Debemos hacernos una serie de preguntas, que nos sirvan de ayuda para
evaluar los diagramas de flujo de datos:
a. Existen en el diagrama de flujo de datos componentes que no tienen nombre
(flujo de datos, procesos, almacenamientos, entradas o salidas)?
b. Existen almacenes de datos que son entradas y a los que nunca se hace
referencia?
c. Existen procesos que no reciben entradas?
d. Existen procesos que no generan salida?
e. Existen procesos que tienen varias finalidades?
f. Existen almacenes de datos a los que no se referencien?
g. Existen demasiados atributos en el almacn de datos (ms que los detalles
necesarios)?
h. El flujo de datos que llega a un proceso es demasiado extenso para la salida
Construccin Sistemtica del DFD
Al desarrollar sistemas grandes y complejos, en general, no existen medios que
guen al analista de sistemas en el diseo de un DFD. El Analista se sienta en su mesa,
contemplando una hoja de papel, esperando por un momento de inspiracin divina o
saturndose de ideas que le son imposibles de expresar todas a la vez. Esta
incertidumbre puede eliminarse intentando aplicar un mtodo de construccin sistemtico,
asistido por herramientas complementarias que ayudan a desglosar el problema en partes
y tratarlas una por vez en una manera organizada.
A continuacin se desarrollar un ejemplo concreto de construccin sistemtica de
DFDs. El mtodo que aplicaremos es descrito de manera informal, a fin de presentar
algunas otras herramientas que asisten en la construccin de un modelo funcional de un
sistema, expresado en una jerarqua de DFD's. El mtodo, as como los modelos,
herramientas y criterios que apoyan las decisiones que involucra, ser explicado en mayor
detalle en el contexto de la metodologa de Anlisis Estructurado Moderno.
Al desarrollar un sistema, cualquiera fuere su tamao, es necesario contar en
primer trmino, con una narrativa textual y una declaracin concisa de los objetivos del
sistema (la funcionalidad que se requiere, es decir lo que se espera que el sistema haga),
por supuesto validada con el usuario del sistema (las personas a las que l esta
destinado).
A continuacin, se presenta una narrativa textual, y su correspondiente
declaracin de objetivos, referente al caso de estudio que abordaremos: el desarrollo de
un sistema de informacin para la administracin de un hotel.
Derivacin del DFD preliminar por eventos
Para cada evento:
a. Dibujar una burbuja que se ocupe de l.
b. Ponerle un nombre acorde con la transformacin que el sistema realiza con el
estmulo y observando la respuesta que debe dar.
c. Aadir los flujos existentes en el Diagrama de Contexto, asociados al evento.
d. Contestar para cada burbuja la pregunta: Qu datos necesita para producir la
respuesta? Y agregar los flujos que se necesiten para aportar estos datos.
e. Contestar para cada burbuja la pregunta: Qu otros datos produce? y agregar los
flujos que se necesiten para producir y responder estos datos.
Estas ltimas preguntas pueden ser contestadas apoyndose en la narrativa, y en
la tabla de estmulo-respuesta.