• Author / Uploaded
• Chavez Moros

• Categories
• Ingeniería de software
• Informática
• Tecnología
• Informática y tecnología de la información
• Ciencia filosófica

Citation preview

25

DIAGRAMAS DE FLUJO DE DATOS La forma sigue a la funciòn. Louis Henri Sullivan “El gran edificio de oficinas, considerado artísticamente”, Lippincott’s, marzo de 1986

En este capítulo se aprenderá : Los componentes de un diagrama de flujo de datos. Como dibujar un diagrama de flujo de datos sencillo Guía para dibujar diagramas eficaces de flujo de datos. Cómo volver a dibujar diagramas nivelados de flujo de datos.

En este capítulo exploraremos una de las tres herramientas gráficas de modelado las importantes del análisis estructurado: el diagrama de flujo de datos. Esta es una herramientas que permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por “conductos” y “tanques de almacenamientos” de datos. En la literatura computacional, y en sus conversaciones con otros analistas y usuarios, puede utilizar cualquiera de los siguientes términos como sinónimos de diagramas de flujos de datos: - Carta de burbujas - DFD (abreviatura que se usará en todo este libro) - Diagrama de burbujas - Modelo de proceso - Diagrama de flujo de trabajo - Modelo de función - “una imagen de lo que está sucediendo aquí” El diagrama de flujo de datos es una de las herramientas mas comúnmente usadas, sobre todos por sistemas operacionales en los cuales las funciones del sistema son de gran importancia y son mas complejas que los datos que este manejo. Los DFD se utilizaron por primera vez en la ingeniería de software como notaciones para el estudio el diseño de sistemas (por ejemplo, en los libros y artículos de diseño estructurado tales como [Stevens, Myers y Constantine, 1974], [Yourdon y Constantine, 1975], [Myers, 1975], y otros). A su vez, la notación se tomó prestada de artículos anteriores sobre teorías de gráficas, y continúa siendo utilizada por los ingenieros de software que trabajan en la implementación directa de modelos de los requerimientos del usuario. Estos son antecedentes, pero con toda probabilidad no serán muy relevantes para los usuarios a quienes usted mostrará los modelos de DDF del sistema; de hecho, probablemente lo peor que usted pueda hacer sea decir, “sr. Usuario quisiera mostrarle un modelo gráfico-teórico descendente y por partes de sus sistemas”. En realidad

26 muchos usuarios estarán familiarizados con el concepto básico de DFD, pues la mismo notación a sido empleada con investigadores de operaciones durante los últimos 70 años para construir modelos de flujo de trabajo de organizaciones. Es importante tener esto en mente: los DFD no sólo se pueden utilizar para modelar sistemas de sistemas de procesos de información, sino también como manera de modelar organizaciones enteras, es decir, como una herramienta para la planeación estratégica y de negocios. Empezaremos nuestro estudio de los DFD examinando los componentes de un diagrama típico de flujo de datos: el proceso, el flujo, el almacén y el terminado. Utilizaremos una notación bastante común siguiendo los textos clásicos de [DeMarco, 1978], [Gane y Sarson, 1977] y otros. Sin embargo, también incluiremos la notación de DFD para modelar sistemas de tiempo real (es decir, flujo de control a procesos de control). Esta notación adicional generalmente no se ocupa de los sistemas dirigidos a los negocios, pero es crucial cuando se modela una variedad de sistemas científicos y de ingeniería. Enseguida, revisaremos algunas de las guías de elaboración de diagramas de flujos de datos para minimizar las posibilidades de construir un DFD confuso, incorrecto o inconsistente. Finalmente, discutiremos el concepto de DFD nivelado como método de modelar sistemas complejos. Tenga en mente que el DFD es tan sólo una de las herramientas de modelado disponibles y que únicamente proporciona un punto de vista de un sistema, el orientado a las funciones. Si se está desarrollando un sistema en donde las relaciones entre datos son más importante que las funciones, tal vez se dé menos importancia al DFD (o incluso ni nos molestemos en elaborarlo), para concentrarse más bien en desarrollare un conjunto de diagramas de entidad-relación, como se expone en el capítulo 12. de otra manera si el comportamiento dependiente del tiempo de un sistema domina sobre cualquier otro factor, tal vez nos concentremos más en el diagrama de transición de estados que se discute en el capítulo 13. LOS COMPONENTES DE UN DFD La figura 9.1 muestra un DFD típico para un sistema pequeño. Antes de examinar sus componentes en detalle, nótese lo siguientes: - prácticamente no requiere explicación; se puede simplemente ver el diagrama y entenderlo. La notación es sencilla y clara y, en cierto sentido intuitivamente obvia. Esto es particularmente importante cuando recordamos quien se supone que está viendo la figura 9.1: no el analista, sino el usuario. Si el usuario necesita una enciclopedia para poder leer y entender el modelo de su sistema, probablemente no se tomará la molestia de hacer ninguna de las dos cosas. - El diagrama cabe fácilmente en una página. Esto significa dos cosas:1) alguien puede mirarlo sin ofuscarse y 2) el sistema que se está modelando no es muy complejo. ¿Qué se hace si el sistema es intrínsecamente complejo, tanto –por ejemplo- que hubiera literalmente cientos de círculos y líneas en el diagrama? Discutiremos esto en la sección 9.4. - El diagrama se dibujó por computadora. Nada tiene de malo un diagrama hecho a mano pero la figura 9.1 y muchos otros de los DFD que se muestran en este libro se hicieron con la ayuda de un programa de la Macintosh llamado MacDraw. Esto significa que el diagrama probablemente se hará de manera más

27 ordenada y estándar que lo en general sería posible a mano. También significa que se pueden hacer cambios y producir nuevas versiones en cuestión de minutos.

Figura 9.1:DFD típico 9.l.1 El proceso El primer componente de DFD s conoce cómo proceso. Los sinónimos comunes son burbuja, función o transformación. El proceso muestra una parte del sistema que transforma entradas en salidas; es decir, muestra cómo es que una o más entradas se trasforman en salidas. El proceso se representa gráficamente como un círculo, cómo se muestra en la figura 9.2 (a). algunos analistas prefieren usar un óvalo o un rectángulo con esquinas redondeadas, como se muestra en la figura 9.2(b); y otros prefieren usar un rectángulo como se muestra en la figura 9.2(c). las diferencias entre estas tres formas son puramente cosméticas, aunque obviamente es importante usar la misma forma de manera consistente para representar todas las funcione de un sistema. A lo largo de este libro utilizaremos el círculo o burbuja

CALCULAR IMPUESTO S DE VENTAS

28

Figura 9.2(a): Ejemplo de un proceso

CALCULAR IMPUESTOS DE VENTAS Figura 9.2(b): Representación alternativa de un proceso CALCULAR IMPUESTOS DE VENTAS

Figura 9.2( c): Una representación más de un proceso Nótese que el proceso se nombra o describe con una sola palabra, frase u oración sencilla. En casi todos los DFD que se discutirán en este libro, el nombre del proceso se describirá lo que hace. En la sección 9.2 hablaremos más cerca de la nomenclatura correcta para burbujas de proceso. Por ahora es suficiente decir que un buen nombre generalmente consiste en una frase verbo objeto tal como VALIDAR ENTRADA O CALCULAR IMPUESTO. En algunos casos, el proceso contendrá el nombre de una persona o un grupo (por ejemplo, un departamento o una división de una organización), o de una computadora o un aparato mecánico. Es decir, el proceso a veces describe quién o qué lo está afectando, mas que describir el proceso mismo. Discutiremos esto con más detalle en el capítulo 17 cuando veamos el concepto de modelo esencial, y más adelante en la parte IV, cuando veamos los modelos de implantación. 9.1.2 El flujo Un flujo se representa gráficamente por medio de una flecha que entra o sale de un proceso; un ejemplo se m muestra en la figura 9.3. el flujo se usa para describir el movimiento de bloques o paquetes de información de una parte del sistema a otra. Por ello, los flujos representan datos en movimiento, mientras que los almacenes (que se describen en la sección 9.1.3) representan datos en reposo.

PREGUNTA DE UN CLIENTE Figura 9.3: Ejemplo de un flujo

29

En la mayoría de los sistemas que modele como analista, los flujos realmente representarán datos, es decir, bits, caracteres, mensajes, números de punto flotante y los diversos otros tipos de información con los que las computadoras pueden tratar. Pero los DFD también pueden utilizarse para modelar otros sistemas aparte de los automatizados y computarizados; pudiera escogerse, por ejemplo, usar un modelo de DFD para modelar una línea de ensamblado en la que no haya componentes computarizados. En tales casos, los paquetes o fragmentos mostrados por los flujos serán típicamente materiales físicos. Un ejemplo de esto se muestra en la figura 9.4. para muchos sistemas complejos del mundo real, el DFD mostrará el flujo de materiales y datos. Nótese que los flujos de las figuras 9.3 y 9.4 tienen nombre. El nombre representa el significado del paquete que se mueve a lo largo del flujo. Un corolario de esto es que el flujo sólo lleva un tipo de paquete, como lo indica su nombre. El analista no debe dar al flujo un nombre como MANZANAS Y ARTICULOS Y VARIAS COSAS MÁS. Sin embargo, veremos en la parte III que hay excepciones a este convenio: a veces es útil consolidar varios flujos elementales en uno solo. Por ello, se pudiera ver un solo flujo llamado VEGETALES en lugar de diversos flujos llamados PAPAS, COLES DE BRUSELAS y CHICHARROS. Como veremos, esto requerirá de alguna explicación en el diccionario de datos, que se discutirá en el capítulo 10. HARINA PARA PASTEL AZUCAR HORNEAR PASTEL

PASTEL

HUEVOS LECHE Figura 9.4:DFD con flujo de materiales Aunque parezca obvio, tenga en mente que el mismo contenido pudiera tener distintos significados en distintas partes del sistema. Por ejemplo, considere el fragmento de sistema que se muestra en la figura 9.5. El mismo fragmento de datos por ejemplo, 212_410_9955) tiene distinto significado cuando viaja a lo largo de un flujo llamado NUMERO TELEFÓNICO que cuando viaja a lo largo de uno llamado NUMERO TELEFONICO VALIDO. En el primer caso, significa un número telefónico que pudiera ser o no válido; en el segundo caso, significa un número telefónico que, dentro del contexto de este sistema se sabe que es válido. Otra forma de verlo es que el flujo denominado “número telefónico” es como un ducto, lo suficientemente poco discriminador como para permitir el paso de números no válidos al igual que válidos; el flujo denominado NUMERO TELEFONICO es más estrecho, o más discriminador y permite pasar datos definidos más estrechamente.

30

Nótese también que los flujos muestran la dirección: una cabeza de flecha en cualquier extremo (o posiblemente ambos) del flujo indica si los datos ( o el material) se está moviendo hacia adentro o hacia fuera de un proceso( o ambas cosas). El flujo que se muestra en la figura 9.6, por ejemplo, indica claramente que el número se está mandando hacia el proceso denominado VALIDAR NÚMERO TELEFÓNICO. Y el flujo denominado HORARIO DE ENTREGA DE COFERES de la figura 9.6(b) claramente india que es una salida generada por el proceso GENERAR HORARIO DE ENTREGA DE CHOFERES. Los datos que se mueven a lo largo de dicho flujo

NÚMERO TELEFONICO

VALIDAR NUMERO TELEFONIC O

NÚMERO TELÉFONICO VALIDO

NÚMERO TELEFONICO INVÁLIDO Figura 9.5: DFD típico Viajarán ya sea a otro proceso (como entrada) o a un almacén (como se discutirá en la sección 9.1.3) o a un terminador (como se indica en la sección 9.1.4). El flujo de dos cabezas que se muestra en la figura 9.6(c) es un diálogo, es decir un empacado conveniente de dos paquetes de datos (una pregunta y una respuesta) en el mismo flujo. En el caso de un diálogo, los paquetes en cada extremo de la flecha deben nombrarse, como se ilustra en la figura 9.6(c).

NUMERO TELEFONICO

VALIDAR NUMERO TELEFONIC O

Figura 9.6 (c): Flujo de entrada Los flujos de datos pueden divergir o converger en un DFD; conceptualmente esto es algo así como un río principal que se divide en varios más pequeños, o varios pequeños que se unen. Sin embargo, esto tiene un significado especial en un DFD típico en el cual hay paquetes de datos que se mueven a través del sistema: en el caso de un flujo divergente, esto significa que se están mandando copias por duplicado de un paquete de datos a diferentes partes del sistema, o bien que un paquete complejo de datos se está dividiendo en varias paquetes individuales más, cada uno de los cuales se está mandando a diferentes partes del sistema, o que el ducto de flujo de datos lleva artículos con distintos valores ( por ejemplo, vegetales cuyos valores pudieran ser “papa”, “col brúceles” o “ejote”) que están siendo separados. De manera inversa, en el caso de un flujo convergente, significa que v arios paquetes elementales de datos se están uniendo

31 para tomar agregados más complejos de paquetes de datos. Por ejemplo, la figura 9.7(a) muestra un DFD en el cual el flujo denominado DETALLES DE ORDENES diverge y lleva copias de los mismos paquetes a los procesos GENERAR DOCUMENTOS DE ENVIO, ACTUALIZAR INVENTARIO y GENERAR FACTURAS. La figura 9.7(b) muestra como el flujo DOMICILIO DE CLIENTE se divide en los paquetes más elementales NUMERO TELEFÓNICO, CÓDIGO POSTAL , y CALLE Y NÚMERO, los cuales se mandan a tres procesos de validación diferentes 4. INTINERARIO DE ENTREGA DE CONDUCTOR

GENERAR Figura 9.6 (b): Flujo de salida ITINERARIO PREGUNTA SOBRE STATUS DE PEDIDO DE ENTREGA DE RESPUESTA DE STATUS DE PEDIDO CONDUCTOR DETERMINAFigura 9.6(c): Flujo de diálogo NóteseRque el flujo no responde a muchas dudas de procedimiento que pudiera tener DE un DFD: no responde a dudas cerca de petición de entradas o de cuandoSTATUS está viendo flujos PEDIDO de salidas, por ejemplo. La figura 9.8 (a) muestra el caso sencillos de un flujo de

entrada que sale del proceso denominado PROCESADOR ORDEN. ¿Pero cómo sucede esto? ¡PROCESADOR ORDEN pide explícitamente al usuario las entradas? ¿O se mueven los paquetes a lo largo del flujo por su propia voluntad ser pedidos? Similarmente, al figura 9.8 (b) muestra un flujo de salidas sencillo quien emana de GENERAR REPORTE DE FACTURAS. ¿Acaso las FACTURAS se mueven a lo largo del flujo cuando GENERAR REPORTE DE FACTURAS los quieren mandar., o cuando alguna otra parte del sistema pide e paquete? Finalmente, considere la situación más común que se muestra en la figura 9.8(c), en donde hay múltiple flujos de entrada y de salida: ¿en qué secuencia llegan los paquetes de datos, en qué secuencia se generan los paquetes de salida? Es decir, ¿el proceso quiere exactamente un paquete de los flujos A, B, y C para producir exactamente un paquete de salida para los flujos X, Y y Z? ¿O existen dos Aes para cada tres Bes? PEDIDOS

GENERAR DOCUMENT O DE ENVIO

PRODUCT O PEDIDOS VALIDOS

DETALLES DE PEDIDOS

PEDIDOS NO VALIDOS ACTUALIZA R INVENTARIO

GENERAR PEDIDO

32

Figura 9.7 (a): Flujo divergente

DOMICILIO DEL USUARIO

VALIDAR CODIGO POSTAL

CODIGO POSTAL NUMERO TELEFONICO VALIDAR NUMERO TELEFONIC O

VALIDA R CALLE

Figura 9.7 (b): Otro ejemplo de flujo divergente

PEDIDO

PROCESA DOR PEDIDO

Figura 9.8 (a): Flujo de entrada

GENERAR REPORTE DE PEDIDO

PEDIDO

33

Figura 9.8 (b): Flujo de salida

A X B

Y

Q

Z C

Figura 9.8(c): Combinación de flujos de salidas y entrada La respuesta a todas estas preguntas es muy sencilla: no sabemos . todas estas interrogantes acarrearan detalle de tipo procedimiento, que son el tipo de pregunta que se modelaría normalmente con un diagrama de flujo de datos o alguna otra herramienta de modelado de tipo procedimiento. El DFD simplemente no intenta abordar estas cuestiones. Si estas preguntas se vuelven importantes, entonces tendrá que modelarse el procedimiento interno de los diversos procesos; las herramientas para hacer esto se discuten en el capítulo 11. 9.1.3 El almacén El almacén se utiliza para modelar una colección de paquetes de datos en reposo. Se denota por dos líneas paralelas, como lo muestra la figura 9.9(a); una alternativa de notación se muestra en la figura 9.9(b); 5 otra más, que se utiliza en el caso de estudio del apéndice F, se muestra en la figura 9.9(c). De modo característico el nombre que se utiliza para identificar al almacén es el plural del que se utiliza para los paquetes que entran y salen del almacén por medio de flujos. _____________ PEDIDOS _______________ Figura 9.9(a): Representación gráfica de un almacén

34

D1

PEDIDOS

Figura 9.9(B): Notación alternativa para un almacén PEDIDOS Figura 9.9 (c): Notación usada en el apéndice F Para el analista con conocimientos de proceso de datos es tentador referirse a los almacenes como archivos o bases de datos (por ejemplo, un archivo en cinta magnética o u archivo de disco organizado con IMS, DBS, ADABAS, IDMS, o algún otro sistema de manejo de bases de datos. De hecho, es así como a menudo se implantan los almacenes en un sistema computarizado; pero un almacén también pudiera consistir en datos almacenados en tarjetas perforadas, microfilm, microfichas, disco óptico o algunas más otras posibles formas electrónicas. Y un almacén también puede ser un conjunto de fichas de papel en una caja de cartón, nombres y domicilios en un directorio, diversos archivos en un archivero, o varias formas no computarizadas. La figura 9.9(d) muestra un ejemplo característico de “almacén” en un sistema manual existente. Es precisamente debido a la variedad de formas de implantación posibles de un almacén deliberadamente escogimos una notación gráfica simple y abstracta así como el término almacén en lugar de, por ejemplo, base de datos. Aparte de la forma física que toma el almacén, también existe la cuestión de su propósito: ¿existe el sistema por causa de un requerimiento fundamental del usuario o por algún aspecto conveniente de la realización del sistema? En el primer caso, la base de datos existe con un área de almacenamiento diferida en el tiempo necesario entre dos procesos que ocurren en momentos diferentes. Por ejemplo, la figura 9.0 muestra un fragmento de un sistema en el cual, como política del usuario (independientemente de la tecnología que se use para implantar el sistema), el proceso de entrada de órdenes puede operar en tiempos diferentes (o posiblemente en el mismo) que el proceso de investigación de órdenes. El almacén de ÓRDENES debe existir en alguna forma, ya sea en disco, cinta, tarjeta o inscrito en piedra.

35

La figura 9.11(a) muestra un tipo distinto de almacén: el almacén de implantación. Podemos imaginar del sistema interponiendo un almacén ÓRDENES entre ENTRA ORDEN y PROCESA ORDEN porque: 







Se espera que ambos procesos se ejecuten en la misma computadora pero no hay suficiente memoria ( o algún otro recurso de hardware) para cubrir ambos al mismo tiempo. Así, el almacén de ÓRDENES se crea como archivo intermedio, pues la tecnología de implantación disponible ha forzado a que los procesos se ejecuten en distinto tiempo. Se espera que cualquiera de los procesos, o ambos, se ejecuten en una configuración de hardware que es poco confiable. Así, el almacén de ÓRDENES se crea como respaldo en caso de que cualquiera de los procesos se aborte. Se espera que diferentes programadores implanten los procesos( o en un caso más extremo, que lo hagan diferentes grupos de programadores que trabajan en lugares geográficos distinto). Así, el almacén de ORDENES se crea para probar y corregir, de manera que si el sistema completo no trabaja ambos grupos puedan ver los contenidos de almacén y detectar el problema. El analista o el diseñador pensaron que el usuario pudiera algún dia hacer accesos al almacén de ÓRDENES por alguna otra razón, aun cuando no haya expresado tal interés. En este caso, el almacén se crea anticipando necesidades futuras del usuario (y dado que costará algo implantar el sistema de esta manera, el usuario acabará apagando por algo que no se pidió).

36

Si fueran a excluirse los asuntos y modelar sólo los requerimientos esenciales del sistema, no existiría necesidad de un almacén de ORDENES; en lugar de eso se tendría un DFD como el que se muestra en la figura 9.11(b). Como hemos visto hasta ahora, los almacenes se conectan por flujos a los procesos. Así, en el contexto que se muestra un almacén en un DFD, es uno de los siguientes (o ambos):  

Un flujo desde un almacén. Un flujo hacia un almacén.

DETALLES DE PEDIDO

INGRESA R PEDIDO PEDIDO

PEDIDOSR

PROCESA DOR RESÚEST A

RESPUESTA

37 INVALIDO Figura 9.11 (b): Almacén de implantación eliminado En la mayoría de los casos, los flujos se etiquetarán como se discute en la sección 9.1.3. Sin embargo, muchos analistas no se molestan en etiquetar el flujo si una instancia completa del paquete fluye hacia o desde el almacén.7 Por ejemplo en la figura 9.12 muestra un fragmento de típico de un DFD. Normalmente se interpreta un flujo que procede de un sistema como una lectura o un acceso a la información del almacén. Esto significa específicamente que: 

Se recupera del almacén un solo paquete de datos: esto es, de hecho el ejemplo más común de flujo desde un almacén. Imagínese, por ejemplo un almacén llamada CLIENTES, donde cada paquete contiene nombre, domicilio y número telefónico de los clientes individuales. Así, un ejemplo típico del almacén podría implicar la recuperación de un paquete completo de información acerca de un cliente.  Se ha recuperado más de un paquete del almacén. Por ejemplo, el flujo podría recuperar paquetes de información acerca de todos los clientes de la ciudad de Nueva York del almacén CLIENTES.  Se tiene una porción de un paquete del almacén. En algunos casos, por ejemplo, sólo se podría recuperar la información del número telefónico de cliente del almacén CLIENTES.

Figura 9.12: Almacenes con flujos no etiquetados 

Se tienen porciones de más de un paquete de almacén. Por ejemplo, un flujo podría recuperar del almacén CLIENTES la porción del código postal de todos los clientes que viven en el estado de Nueva York.

38

Como notamos antes cuando examinamos los flujos que entraban y salían de un proceso., tendríamos muchas preguntas de tipo procedimiento cuando examinemos los flujos que entran y salen de un almacén: ¿representa el flujo un solo paquete, muchos, porciones de diversos paquetes?. En algunos casos, podemos darnos cuenta simplemente viendo la etiqueta del flujo: si el flujo no está etiquetado, significa que todo el paquete de información se está recuperando (como se dijo antes esto es simplemente un convención cómoda); si la etiqueta del flujo es la misma que la del almacén significa que se recupera todo un paquete (p múltiples instancias de uno completo); si la etiqueta de flujo es diferente del nombre del almacén entonces se está recuperando uno o más componentes de uno o más paquetes.8 8

¿Cómo podemos saber que las etiquetas del flujo tienen que ver con los componentes de un paquete de información del almacén? ¿Cómo saber, por ejemplo, que le flujo etiquetado como NUMERO TELEFONICO tiene algo que ver con los paquetes de información del almacén de CLIENTES? Es tentador, sobre todo en un proyecto real donde todo mundo está relativamente familiarizado con el tema, decir simplemente “Es que es obvio”. Por supuesto que el número de teléfono forma parte del paquete de cliente. Pero para estar seguro, se requiere una definición rigurosa de la composición del paquete CLIENTES. Esto se encuentra en el diccionario de datos, que se discutirá en el capitulo 10. A pesar de que algunas de las preguntas de tipo procedimiento pueden responderse viendo cuidado las etiquetas del flujo, no serán evidentes todos los detalles. De hecho, para conocer todo lo deseado acerca del flujo que amana del almacén, tendrán que examinarse los detalles: la especifican del proceso al que se conecta el flujo. Las especificaciones de los procesos se examinan en el capítulo 11. Existe un detalle de tipo procedimiento del cual podemos ser seguros: el almacén es pasivo, y los datos no viajarán a lo largo del flujo a menos que el proceso lo solicite explícitamente. Existe otro detalle de tipo procedimiento que suponen, por convenio, los sistemas de proceso de datos: el almacén no cambia cuando un paquete se mueve del almacén a lo largo del flujo. Un programador pudiera referirse a esto como una lectura no destructiva o, en otras palabras, del almacén se recupera una copia del paquete y el almacén mantiene su condición original. 9 Un flujo hacia un almacén habitualmente se describe como una estructura, una actualización o posiblemente una eliminación. Específicamente, sólo puede significar que se tiene una de las situaciones siguientes: 



Se están guardando uno o más paquetes nuevos en el almacén. dependiendo de la naturaleza del sistema, los paquetes nuevos pudieran en anexarse (es decir, de alguna manera acomodarse para que estén “después” de los paquetes existentes), o pudieran colocarse en algún lado entre los paquetes existentes. Esto es a menudo un asunto de la implantación (es decir, controlado por el sistema específico de administración de bases de datos), por lo que el analista no debiera preocuparse acerca de ello. Podría ser, sin embargo, cuestión de una política del usuario. Uno o más paquetes se están borrando o retirando del almacén.

39 

Uno o más paquetes se están modificando o cambiando. Esto pudiera traer consigo un cambio de todo un paquete, o más (comúnmente), de sólo una porción, o de una porción, o de una porción de múltiples paquetes. Por ejemplo, suponga que la policía tiene un almacén de sospechosos y que cada paquete contiene sus nombres y domicilios; puede ofrecérsela una nueva “identidad” a un sospechoso que coopera, en cuyo caso toda la información relacionada con su paquete cambiará. Como alternativa, considera un almacén CLIENTES que contenga información acerca de los clientes que residen en Manhattan (como sucedió en 1983, cuando el área de Manhattan donde yo vivía cambio de código 10028 a 10 128), se necesitarán un cambio a una porción de diversos paquetes.

En todos estos casos es evidente que el almacén cambió como resultado del flujo que ingresa. El proceso (o procesos) conectados con el otro extremo del flujo es el responsable de realizar el cambio al almacén. Un punto que debiera ser evidente de todos los ejemplos que se han mostrado hasta ahora es el siguiente: los flujos conectados a un almacén sólo pueden transportar paquetes de información que el almacén sea capaz que guardar. Por ello, un flujo conectado a un almacén CLIENTES sólo puede transportar información relacionada con los clientes contenidos por el almacén.; no puede transportar paquetes de inventarios o paquetes de manufactura o datos astronómicos. 9.1.4 El Terminador El siguiente componente del DFD es un terminador; gráficamente se representa como un rectángulo, como se muestra en la figura 9.13. los terminadores representan entidades externas con las cuales el sistema se comunica. Comúnmente, un terminador es una persona o un grupo, por ejemplo una organización externa o una agencia gubernamental, o un grupo o departamento que está dentro de la misma compañía u organización, pero fuera del control del sistema que se está modelando. En algunos casos, un terminador puede ser otro sistema, como algún otro sistema computacional con el cual se comunica éste. DEPARTAMENTO DE CONTABILIDAD Figura 9.13: Representación gráfica de un terminador Suele ser muy fácil identificar los terminadores en el sistema que se está modelando. A veces el terminador es el usuario; es decir, en sus discusiones con el usuario, éste diría “Pretendo suministrar al sistema los datos X, Y y Z, y espero que me regrese los datos A, B y C”. en otros casos, el usuario se considera parte del sistema y ayudará a identificar los terminadores relevantes; por ejemplo, le dirá “Tenemos que estar listos para recibir las formas tipo 321 del departamento de contaduría, y debemos enviar

40 reportes financieros semanales al comité de finanzas”. En este último caso, es evidente que el departamento de contaduría y el comité de finanzas son terminadores separados con los cuales se comunica el sistema. Existen tres cosas importantes que debemos recordar acerca de los terminadores: 1.

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.

2.

Como consecuencia, es evidente que ni el analista ni el diseñador del sistema están en posibilidades de cambiar los contenidos de un terminador de texto clásicos sobre análisis estructurado, el terminador está afuera del dominio del camino. Lo que esto significa es que el analista está modelando un sistema con la intención de permitir una considerable flexibilidad y libertad al diseñador para elegir la mejor implantación posible (la más eficiente o la más confieble , etc). El diseñador puede implantar el sistema de manera bastante diferente de aquella en la actualmente está implantando; el analista puede escoger modelar los requerimientos del sistema en forma que se vea considerablemente diferente de la manera en la que actualmente el usuario visualiza mentalmente el sistema ( se verá más cerca de esto en la sección 9.4 y la parte III). Sin embargo, el analista de sistemas no puede modificar los contenidos, la organización ni los procedimientos internos asociados con los terminadores

3.

Las relaciones que existen entre los terminadores no se muestran en el modelo de DFD. Pudieran existir de hecho diversas relaciones, pero, por definición, no son parte del sistema que se está estudiando. De manera inversa, si esxisten relaciones entre los terminadores y si es esencial para el analista modelarlos para poder documentar los requerimientos del sistema, entonces, por definición, los terminadores son en realidad parte del sistema y debieran modelarse como procesos.

En los ejemplos sencillos que se han discutido hasta ahora vemos sólo uno o dos terminadores. En un sistema real típico pueden existir docenas de terminadores diferentes interactuando con él. Identificar los terminadores y su interacción el sistema es parte del proceso de construir el modelo del ambiente, que se discutirá en el capítulo 17. 9.2

GUIA PARA LA CONTRUCCIÓN DE DFD

En la sección anterior vimos que los diagramas de flujo de datos constan de cuatro componentes sencillos: procesos (burbujas), flujos, almacenes y terminadores. Armado con estas herramientas, puede comenzar a entrevistar a los usuarios a construir modelos de DFD de sistemas. Sin embargo, existe un número de reglas adicionales que se requieren para poder utilizar DFD con éxito. Algunas de estas reglas ayudarán para no elaborar DFD erróneos ( por ejemplo, incompletos o lógicamente inconsistentes). Algunas de las reglas tienen

41 la finalidad de ayudarles para que dibuje un DFD grato a la vista, y que, por tanto, tenga más probabilidades de que lo lea con cuidado el usuario. Las reglas incluyen las siguientes: 1. Escoger nombres con significados para los procesos, flujos, almacenes y terminadores. 2. Numerar los procesos 3. Redibujar el DFD tanta veces como sea necesario estéticamente. 4. Evitar los DFD excesivamente complejos. 5. Asegurarse que el DFD sea internamente y que también lo sea con cualesquiera DFD relacionados con él. 9.2 Escoger nombres con significado para los procesos, flujos, almacenes y terminadores Como se ha visto, 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. En el último caso, obviamente es importante etiquetar con precisión el proceso, de modos que quienes leen el DFD, especialmente los usuarios, puedan confirmar que se trata de un modelo preciso. Sin embargo, si el proceso lo hace una sola persona, recomiendo que identifique el papel que dicha persona está representando, más que su nombre o identidad. Así en lugar de dibujar un proceso como el que se muestra en la figura 9.14(a) , con el nombre de Paco inmortalizado a la vista de todos, sugerimos que represente el proceso como se muestra en la figura 9.14(b). la razón de esto tiene tres aspectos: 1. Paco pudiera ser reemplazado la próxima semana por María o por Juan. ¿Para qué introducir en el modelo algo susceptible de volverse obsoleto? 2. Paco pudiera estar realizando diversas labores diferentes en el sistema. En lugar de dibujar tres brujas distintas, cada una etiquetada como Paco pero con distinto significado, es preferible indicar la labor misma que se está logrando, o por lo menos el papel que Paco está jugando en el momento ( como se modela en cada una de las burbujas). 3. Identificar a Paco es probable que traiga atención hacia la manera particular en la que realiza la labor dada. Como veremos en la parte III, generalmente desearemos concentrarnos en la política de negocios que debe cumplirse, sisn referirnos a los procedimientos ( los cuales pueden basarse en costumbres e historia que ya no sean relevantes) que se utilizan para seguir dicha política. Pedido validos pedidos

PEDRO Pedidos inválidos

Figura 9.14(b):Nombre de proceso más apropiado

42

pedidos validos pedidos

VALIDAR PEDIDOS

pedidios inválidos

Figura 9.14 (b): Nombre de proceso más apropiado Si tenemos suerte de evitar nombres de personas ( o de grupos) y papeles políticos, entonces podemos etiquetar los procesos de tal manera que se puedan identificar las funciones que el sistema está llevando a cabo. 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, uno 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 INVENTARIO VALIDAR NUMERO TELEFONICO ASIGNAR ESTUDIANTES A LA CLASE

Encontrará, al seguir estas reglas, que considerablemente más fácil utilizar verbos y objetivos específicos si el proceso mismo es relativamente simple y está bien definido. Sin embargo, aun en los casos sencillos hay la tentación de utilizar nombres ambiguos como HACER, MANEJAR y PROCESAR. Cuando utilizan verbos tan “elásticos” (verbos con significados para cubrir casi cualquier situación), a menudo significa que el analista no está seguro de cuál función se está llevando a cabo o que se han agrupado diversas funciones que en realidad no debieran agruparse. Estos son algunos nombres de procesos poco adecuados:      

HACER ALGO FUNCIONES MISCELANIAS MANEJAR ENTRADAS ENCARGARSE DE CLIENTES DATOS DE PROCESOS EDICION GENERAL.

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. 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 subyacente. Pero se deben tener en cuenta dos precauciones:

43

1. Hay una tendencia natural de los usuarios de utilizar abreviaturas y acrónimos específicos con los que están familiarizados; esto es cierto tanto para los procesos como para los flujos que describen. Por desgracia, esto suele resultare en un DFD fuertemente orientado a la manera en la que hacen las cosas ahora. Por ello, el usuario podría decir: “Bueno, se consigue una copia de la forma 107, la forma rosada, usted sabe, y se la mandamos a José una vez llena”. Una buena manera de evitar tales términos idiocrásicos es escoger verbos (como “llenar”) y objetos ( como forma “107”) que tendrían significado para alguien de la misma industria o aplicación, pero que trabaje en una compañía u organización diferente. Si se está creando un sistema para bancos, los nombres de procesos y de flujos debieran, idealmente ser comprensibles para alguien de un banco distinto. 2. Si el DFD lo dibuja alguien que tenga bases de programación, habrá la tendencia a utilizar terminología orientada a la programación, tal como: “RUTINA”, “PROCEDIMIENTO”, “SUBSISTEMA” y “FUNCIÓN”, aunque dichos términos pudieran no tener significado alguno en el mundo del usuario. A menos que oiga a los usuarios utilizar estas palabras en su propia conversación, evite utilizarlas en su DFD. 9.2.2

Numerar el proceso

Como una forma conveniente de referirse a los procesos en un DFD, muchos analistas numeran cada burbuja. No importa mucho cómo se 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 un DFD, una cierta secuencia de ejecución. Esto es, cuando se muestre el DFD a un usuario, éste pudiera preguntar ¿Acaso la burbuja número 1 sucede primero, luego la 2 y luego la 3? De hecho, otros analistas y programadores pudieran hacer la misma pregunta; cualquiera que esté familiarizado con un diagrama de flujo puede cometer el error de suponer que los números asociados con las burbujas implican secuencia. Esto no es así en absoluto. El modelo de DFD es una red de procesos asincrónicos que se intercomunican, lo cual es hecho, una representación precisa de la manera en la que la realidad muchos sistemas operan. Alguna secuencia pudiera implicarse por la presencia o ausencia de datos ( por ejemplo, pudiera resultar que la burbuja 2 no pudiera realizar su función sino hasta que reciba datos de la burbuja 1, pero el esquema de numeración no tiene nada que ver con eso. ¿Para qué numerar entonces las burbujas? En parte, como se indicó anteriormente, es una manera muy conveniente de referirse a los procesos. Es más fácil en una discusión animada sobre un DFD decir “burbuja1” en lugar de “EDITAR TRANSACCION 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 cuando se introduzcan los diagramas de flujo por niveles en la sección 9.3.

44

9.2.2

Evitar los DFD demasiado 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 otros 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. Esto significa que el diagrama debe ser fácilmente entendido, fácilmente asimilado y placentero a la vista. Trataremos sobre varias reglas estéticas en la siguiente subsección, pero hay una regla principal que se debe tener en mente: no cree un DFD con demasiados procesos, flujos y almacenes y terminadores. En la mayoría de los casos, esto significa que no debiera haber más de media docena, f de procesos y almacenes, flujos y terminadores relacionados en un solo programa. 10 Otra manera de decir esto es que el DFD debe caber cómodamente en una hoja normal. 10 esta regla proviene de “The Magical Numbre Seven, Plus or Minus”, de George MIleer, Psicology Review 1956.

Existe una excepción importante a esto, que discutiremos en el capítulo 18: un DFD 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,. La figura 9,15 muestra un diagrama de contexto típico y, como pude verse, con él basta para asustar a muchos analistas, por no mencionar al usuario desprevenido. Comúnmente, los diagramas de contexto como el que se muestra en la figura 9.15 no se pueden simplificar, pues describen, con el más alto detalle, una realidad que es intrínsecamente compleja.11 PEDIDO AGENCIA DE VENDEDOR ENVIO CLIENTE PUBICIDAD SEC HACIENDA

BANCOS

CORPORACIO PREGUNTA N AJAX

RESPUESTA

CLIENTE

Figura 9.15: diagrama de contexto típico

9.2.2

Redibujar el DFD tantas veces como sea necesario.

En un proyecto real de análisis de sistemas, el DFD que se analiza en este capítulo tendrá que dibujarse y volverse 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 la dirección de la

45 organización. Esto pudiera parecer mucho trabajo, pero bien vale el esfuerzo de desarrollar un modelo preciso, congruente y agradable, de los requerimientos de un sistema. Lo mismo se cumple para cualquier otra disciplina de ingeniería: ¿querría usted volar en un avión diseñado por ingenieros que se aburrieron de sus dibujos de ingeniería tras la segunda iteración?12 ¿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 del usuario pudiera ser un tanto diferente de la suya; lógicamente, cualquier cosa que el usuario encuentre agradable debe determinar algunos de los asuntos que surgen para ser tratados en este área son los siguientes:







Tamaño y forma de las burbujas: algunas organizaciones dibujan diagramas de flujo de datos con rectángulos u óvalos en lugar de círculos; esto es obviamente una cuestión de estética. Además, algunos usuarios pudieran molestarse si las burbujas del DFD nos son del mismo tamaño: creen que si una burbuja es más grande que otra eso significa que esa parte del sistema es más importante o que difiere del resto de una manera significativa. (de hecho, por lo común sucede sólo debido a que el nombre de la burbuja era tan largo que el analista tuvo que dibujarla más grande para poderlo acabar.) Flujos curvos vs rectos. Para ilustra esto, considere los DFD de la figura 9.16(a) y 9.16(b). ¿Cuál es más agradable? Muchos observadores se encogerán de hombros y dirán “en realidad a igual”. Pero otros, y éste es el meollo del asunto, escogerán uno y rechazarán violentamente el otro. Obviamente, sería una buena idea conocer de antemano qué opción será aceptada y cuál será rechazada. El asunto de las flechas cruzadas es similar: ¿Se permite o no se permiten?. Diagramas hechos a mano vs. Los diagramas generados por maquina. Dentro de algunos años, casi todos los DFD y modelos de sistemas relacionados se dibujarán por sistemas gráficos por computadoras; sin embargo, muchos de los diagramas, todavía hoy se dibujan a mano porque los analistas no tienen accesos a tales herramientas. No obstante, del asunto aquí es la relación del usuario a este diagrama: algunos prefieren los diagramas generados por la maquina pues son más ordenados, mientras que otros prefieren los dibujados a mano porque los hace sentir que le diagrama no se he “congelado” aún, y que todavía pueden introducir cambios.

11.En la realidad, hay algo que podemos hacer: si hay diversos flujos distintos entre un terminador y una sola burbuja del sistema, pueden consolidarse en un solo flujo de datos. El diccionario de datos, que se discute en el capítulo 10, se usará para explicar la composición y significado de un flujo agregado. Y si, el diagrama de contexto se está mostrando a un público muy diverso ( por ejemplo, distintos grupos de usuarios con diferentes intereses), se puede dibujar varios diagramas de contexto que enfaticen los flujos particulares que puedan interesarle a cada grupo de usuarios. Pero en la mayoría de los casos, no hay

46 escapatoria: si el sistema global es intrínsecamente complejo, lo será también el diagrama de contexto. Se discutirá más a fondo en el capítulo 18

9.2.5

Asegúrese de que su DFD sea lógicamente consistente

Como se verá en el capítulo 14, existen reglas que ayudan a asegurar la consistencia del DFD con los otros modelos del sistema; el diagrama entidad relación, el diagrama de transición de estados, el diccionario de datos, y la especificación de procesos. Sin embargo, existen algunas reglas respecto a cómo asegurar que el DFD mismo sea consistente. Las principales reglas de consistencias son: 





Evite sumideros infinitos, burbujas que tienen entradas pero no salidas. También son conocidos por los analistas cómo “agujeros negros”, en analogía con las estrellas cuyo campo gravitacional es tan intenso que ni la luz se les escapa. Un ejemplo de vórtice infinito se da en la figura 9.17. Evite las burbujas de generación espontánea, que tienen salidas sin tener entradas, porque son sumamente sospechosas y generalmente incorrectas. Un ejemplo factible de una burbuja que sólo tiene salidas es un generador de números aleatorios, pero es difícil imaginar algún otro ejemplo razonable. Una burbuja típica que sólo tiene salidas se muestra en la figura 9.18. Tenga 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. En le caso de un flujo no etiquetado, pudiera significar que diversos datos elementales no relacionados se agruparan arbitrariamente; en el caso de un proceso no etiquetado, pudiera significar que el analista estaba tan confundido que dibujo un diagrama de flujo disfrazado en lugar de un diagrama de flujo de datos.13

Hay un convenio idiomático que viola esto, que se discutirá en la sección 9.1.3: un flujo no etiquetado que sale o entra de un almacén es, por acuerdo, un indicio de que una instancia ( o registro) completo se está metiendo o sacando del almacén

47

Figura 9.16 (b): Versión diferente de un DFD A

x

PROCESA R COSAS B

y

Figura 9.17: Ejemplo de sumidero infinito A

X PROCESA R COSAS

48 B

Y

Figura 9.18: Ejemplo de burbuja únicamente de salida 

Tenga cuidado con los almacenes de (sólo lectura) o (sólo escritura). Esta regla es análoga a la de los procesos de “únicamente entrada” o “únicamente salidas”. Un almacén típico debiere tener tanto entradas como salidas.14. la única excepción a esta regla es el almacén externo,. Que sirve de interfaz entre el sistema y algún terminador externo. La figura 9.19 muestra un ejemplo en un sistema de bolsa con un almacén legítimo que sólo es para escritura.

14. Aveces pudiera no ser evidente inmediatamente si el almacén tiene tanto entradas como salidas. Como veremos en la siguiente sección, a menudo los DFD se dividen en parte, por lo que pudiéramos encontrar que una parte del sistema parece sólo tener almacenes de únicamente lectura (o únicamente escritura). Alguna otra parte del sistema, documentada en otro DFD, pudiera tener la actividad de únicamente escritura ( o únicamente lectura) correspondiente. Para verificar que laguna parte del sistema lea y alguna otra escriba en el almacén se requiere de una labor muy teriosa de revisión; es aquí donde los paquetes de análisis automatizados de sistemas que se discuten en el apéndice A se vuelven extremadamente valiosos.

CLIENTES CORPORATIVOS

CLIENTE Reporte anual

DATOS DE MERCADO Datos de mercado

Reportes 10 -K

SISTEMA DE INVESTIGACIÓ N DE MERCADO Datos de investigación

SEC AGENCIAS DE INVESTIGACIÓN Figura 9.19: Caso legítimo de almacén de únicamente escritura

9.3

DFD por niveles

Hasta donde hemos llegado por capítulo los únicos diagramas de flujos de datos completos que hemos visto son el sistema sencillo de tres burbujas de la figura 9.1 y el

49 sistema de un burbuja de la figura 9.19, pero los DFD que veremos en proyectos reales son considerablemente mayores y más complejos. Considere por ejemplo el DFD que se muestra en la figura 9.20 ¿Puede imaginarse mostrándole esto al usuario típico? La sección 9.29.3 sugiere que deben evitarse diagramas como en la figura 9.20 ¿Pero cómo? Si el sistema es intrínsecamente complejo y tiene docenas o incluso cientos de funciones que modelar, ¿Cómo puede evitarse el tipo de DFD que muestra la figura 9.20? La respuesta es organizar el DFD global en una serie de niveles de modo que cada uno proporciones sucesivamente más detalles sobre una porción del nivel anterior. Esto es análogo a la organización mapas en un atlas, como se discutió en el capítulo 8: esperaríamos ver un mapa global que mostrará un país completo, o tal vez incluso el mundo completo; los mapas subsecuentes mostrarían los detalles de los países individuales, los estados individuales dentro de los países, etc. En el caso de los DFD, la organización de los DFD, la organización de los niveles se muestra conceptualmente en la figura 9.2.1. El DFD del primer nivel consta sólo de 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 pudiera haber, como lo ilustra la figura 9.19). Este DFD especial se conoce como diagrama de contexto y se explica en el capítulo 18.

Figura 9.20: DFD complejo El DFD que sigue el 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. Como se discutió en la sección 9.2.2, cada una de estas burbujas debiera numerarse para una referencia conveniente. Los números también sirven como una manera adecuada de relacionar una burbuja como en el siguiente nivel del DFD que la describe más a fondo. Por ejemplo:

50    

La burbuja 2 en la figura 0 se asocia con un DFD inferior conocido como figura 2. Las burbujas de la figura 2 se numeran 2.1, 2.2, 2.3, etc. La burbuja 3 de la figura 0 se asocia con un DFD inferior conocido como figura 3, las burbujas de la figura 3 se enumeran 3.1, 3.2, 3.3, etc. La burbuja 2.2 de la figura 2 se asocia con un DFD de nivel inferior conocido como figura 2.2. las burbujas de ésta se numeran 2.2.1, 2.2.2, 2.2.3, etc. Si una burbuja tiene nombre (que en realidad debiera tenerlo) entonces dicho nombre se reutiliza en la figura de nivel inmediato inferior. Así, si l burbuja 2.2 se llama CALCULAR IMPUESTO DE VENTA, entonces La figura 2.2 que parte de la burbuja 2.2 en más detalles, debe etiquetarse “figura 2.2: CALCULAR IMPUESTOS DE VENTA”.

Figura 9.21: DFD por niveles Como podrá verse, ésta es una manera bastante directa de organizar un DFD potencialmente enorme en un grupo de piezas manejables. Pero existen diversas cosas que debemos añadir a esta descripción de niveles: 1. ¿Cómo saber cuántos niveles debe haber en un DFD? La respuesta se sugirió en la sección 9.2.3: cada DFD debe tener no más de media docena de

51

2.

3.

4.

5.

burbujas y almacenes relacionados. Así, se ha partido un sistema grande en tres niveles, pero sus DFD de nivel más bajo aún contienen 50 burbujas cada uno, entonces falta por lo menos un nivel más. En el capítulo 11 se ofrece una alternativa de verificación, al discutir las especificaciones de proceso para las burbujas en los DFD del nivel más bajo: Si no podemos escribir una especificación de proceso razonable para una burbuja en alrededor de una página, entonces es probable que sea demasiado compleja y debiera partirse de un DFD de menor nivel antes de tratar de escribir la especificación. ¿Existen reglas acerca del número de niveles que debieran esperarse en un sistema típico? En un sistema simple, probablemente se encontrarán dos o tres niveles,; uno mediano tendrá generalmente de tres a seis niveles; uno grande tendrá de cinco a ocho niveles. Debe ser bastante precavido con quien le diga que todos los sistemas puedan modelarse exactamente tres niveles; tal persona también tratará de venderle la Torre Eifel. Por otro lado, recuerde que el número total de burbujas se incrementa exponencialmente a medida que se baja de nivel al inmediato inferior. Si, por ejemplo, cada figura tiene 7 burbujas, entonces habrá 343 en el tercer nivel, 16,807 en el quinto, y 40, 353,607 en el noveno. ¿deben partirse todas las partes del sistema con el mismo nivel de detalle? Por ejemplo, si la burbuja 2 de la figura 0 requiere tres niveles más de detalle, ¿es necesario que también la burbuja 3 tenga tres niveles más de detalle? Es decir la figura 3; un conjunto de figuras etiquetadas como figura 3.1, 3.2... y un conjunto de figuras etiquetadas 3.1.1, 3.1.2...etc. la respuesta es “no”. Algunos pates del sistema pueden ser más complejas que otras y pueden requerir un o más niveles de partición. Por otro lado, si la figura 2, que existe en la figura 0 , resulta primitiva, mientras que la burbuja 3 requiere de 7 niveles más de partición, entonces el modelo global del sistemas está ladeado y probablemente esté mal organizado. En este caso, lagunas porciones de la burbuja 3 debieran separarse en una burbuja aparte o tal vez ser asignadas a la 2. ¿Cómo se muestran estos niveles al usuario? Muchos usuarios solo quieren ver un diagrama: un usuario ejecutivo de alto nivel pudiere querer ver tan sólo el diagrama de contexto o tal vez la figura 0; un usuario de nivel operacional pudiera querer ver sólo la figura que describe el área en la cuál está interesado. pero si alguien quiere ver una parte más extensa del sistema, o tal vez todo, entonces tiene sentido presentar los diagramas de una manera decente: comenzar con el diagrama de contexto y continuar hasta niveles de más bajos de detalle. A menuda resulta útil tener dos diagramas juntos en el escritorio (o mostrarlo por un proyector cuando esté haciendo esto: el diagrama en el cual está particularmente interesado y el diagrama progenitor que provee un contexto de alto nivel. ¿Cómo asegurar que los niveles del DFD sean consistentes entre si? El asunto de la consistencia resulta ser de importancia crítica, pues los diversos niveles del DFD los desarrollan en general distintas personas en un proyecto real; un analista en jefe puede concentrarse en el diagrama de contexto y la figura 0, mientras que diversos analistas ayudantes trabajan en las figuras 1, 2 etc. Para asegurar que cada figura sea consistente con su figura de más alto nivel se sigue una regla sencilla: los flujos de datos que salen y entran de una burbuja en un nivel dado deben corresponder con los que entran y salen de

52 toda la figura en el nivel inmediato que la describe. La figura 9.22 (b) muestra dos niveles de un DFD que no están balanceados. 6. ¿cómo se muestran los almacenes en los diversos niveles? Esta es un área donde la redundancia se introduce deliberadamente en el modelo. La regla es la siguiente: mostrar un almacén en el nivel más alto donde primeramente sirve de interfaz entre dos o más burbujas; luego mostrarlo de nuevo en CADA diagrama de nivel inferior que describa más a fondo ( o parta más) dichas burbujas de interface. Así, la figura 9.23 muestra un almacén compartido por dos procesos de alto nivel: A y B; el almacén se mostrará nuevamente en las figuras del nivel inmediato inferior que describen más a fondo A y B. el corolario de esto es que los almacenes locales, que utilizan sólo las burbujas en una figura de menor nivel, no se mostrarán en niveles superiores, dado que se incluyen de manera implícita en un proceso de nivel inmediato superior. 7. ¿Cómo se realiza de hecho la participación de los DFD en niveles? La exposición hasta aquí ha sido un tanto sutil: a pesar de que ciertamente los DFD deben presentarse al público usuario de una manera descendente no es necesariamente cierto que el analista deba desarrollarlos así. El enfoque descendente intuitivamente es muy atractivo: puede imaginarse comenzando con el diagrama de contexto y luego desarrollando la figura 0 para ir trabajando en forma progresiva hasta los niveles más bajo de detalle. 15 sin embargo, como se verá en el capítulo 17 existen problemas con este enfoque, un enfoque que tiene más éxito es identificar primero los acontecimientos externos a los cuales deben responder el sistema y utilizarlos para crear un primer borrador del DFD. En el capítulo 20 veremos cómo es que esta primera aproximación del DFD pudiera requerir partirse hacia arriba ( para crear DFD de mayor nivel), y hacia abajo ( para crear DFD de bajo nivel). Por ahora es suficiente que simplemente se dé cuenta que la organización y presentación de un conjunto de DFD por niveles no necesariamente corresponde a la estrategia para desarrollar estos niveles en primer lugar. 15. También es atractivo para los administradores del proyecto. En una ocasión se escuchó que una administradora de un proyecto muy grande decirla a su equipo: “quiero que todos ustedes burbujeando hasta el siguiente nivel de detalle para este fin de semana”.

53

Figura 9.22(a): Fragmento balanceado de un DFD

54

Figura 9.22 (b): Fragmento de un DFD no balanceado

Figura 9.23: Cómo se muestran los almacenes en niveles inferiores 9.4

EXTENSIONES DEL DFD PARA SISTEMAS DE TIEMPO R

55 Los flujos que se discuten a lo largo de este capítulo son flujos de datos, son simplemente los conductos a lo largo de los cuales viajan los paquetes de datos entre procesos y almacenes. Similarmente, las burbujas en los DFD que hemos visto hasta sistemas, sobre todo de negocios, existen solo dos tipos de flujos necesarios en el modelo del sistema. Pero para otra clase de sistemas, los 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, como lo ilustra la figura 9.24). Un flujo de control puede imaginarse como un conducto que porta una serie binaria (esto es, encendido o está apagado). A diferencia de otros flujos que se discuten en este capítulo, el flujo de control no porta datos con valores. El flujo de control se manda de un proceso a otro ( o de algún terminador externo a un proceso como una forma de decir:”Despierta, es hora de trabajar”. Esto, desde luego implica que el proceso ha estado “dormido” hasta la llegada del flujo de control. Un proceso de control puede considerarse como una burbuja supervisora o ejecutiva, cuya labor es coordinar las actividades de otras burbujas en el diagrama; sus entradas y salidas consisten sólo de flujos de control. Los flujos de control salientes del proceso de control se utilizan para despertar a otras burbujas; los flujos de control entrantes generalmente indican que una de las burbujas ha terminado su labor o que se ha presentado alguna situación extraordinaria, de la cual necesita informarse al la burbuja de control. Por lo común sólo hay un proceso en DFD dado. Como se indicó anteriormente, un flujo de control se utiliza para despertar un proceso normal, una vez despierto, el proceso normal procede a llevar a cabo su labor como lo describe la especificación del proceso (véase el capítulo 11). Sin embargo, el comportamiento interno de un proceso de control es diferente; aquí es donde el comportamiento dependiente del tiempo del sistema se modela con detalle. El interior del proceso de control se modela con un diagrama de transición de estados, que muestra los varios estados en los que se puede encontrar todo el sistema y las circunstancias que lo llevan a cambiar de estado. Los diagramas de transición de estados se discuten en el capítulo 13.

56

9.5

RESUMEN

Como vimos e este capítulo, el DFD es una herramienta sencilla pero poderosa para modelar las funciones de un sistema. El material de las secciones 9.1, 9.2 y 9.3 debiera bastar para modelar la mayoría de los sistemas de información clásicos dirigidos a los negocios. Si está trabajando con un sistema de tiempo real (por ejemplo, control de procesos, dirección de proyectiles o conmutación telefónica), serían importantes las extensiones de tiempo real que se discuten en la sección 9.4. para más detalles sobre asuntos de tiempo real, consulte [Ward y Mellor, 1985]. Desafortunadamente muchos analistas piensan que los DFD son todo lo que necesitan conocer acerca del análisis estructurado. Si le pregunta a uno de sus colegas si está familiarizado con el análisis estructurado es probable que diga:” Ah, sí, aprendí acerca de las burbujas y esas cosas”. Por otro lado, esto es un tributo al poder de los DD; a menudo es lo único que el analista recuerda después de lee un libro o tomar un curso de análisis estructurado. Por otro lado es una situación peligrosa: sin las herramientas de modelado adicionales que presentan en los capítulos siguientes, los DFD no tienen valor alguno. Aún cuando las relaciones entre datos y el comportamiento dependiente del tiempo del sistema sean tribales (lo cual es improbable), será necesario combinar los DFD con el diccionario de datos (que se trata en el capítulo 10) y las especificaciones de proceso (que se explican en el capítulo 11).

57 REFERENCIAS 1.Wayne Stevens, Glen Myers y Larry Constantine, “Structured Design”, IBM Systems Journal, mayo de 1974. 2.Yourdon y Larry Constantine, Structure Design, Nueva York: YOURDON Press, 975. 3.Glen Myers, Reliable Software trough Composite Design, Nueva York: Petrocelli/Charter, 1975. 4 Tom de Marco, Structure Analysis and Systems Specification. Englewood Cliffs, N.J: Prentice-Hall, 1979 5 Chris Gane y Trhis Sarson, Structure Systems Analysis: Tolls and Techniques, Englewood Clifs, N.J: Prentice-Hall, 1978. 6 Doug Ross y Ken Schoman, Jr, “Structured Analysis for Requeriments DEfinition”, IEEE Transactions on Software Engineeering, enero 1997, pp. 41-48. También reimpreso en Ed Yourdon, Classics in Software Engineering: Nueva York: YOURDON Press, 1979. 7 Paul Ward y Steve Mellor Structure DEvelopment of Real-Time Systems, volúmenes 1-3.Nueva York: YOURDON press, 1986. 8 Edsger W.Dijkstra “Cooperating Sequential Processes”, Programming Laguages, F.Genuys (editor). Nueva York:Academic Press, 1968. 9 Paul Ward, “The Transformation Schema: An extensión of the Dataflow Diagram to REpresent Control and Triming”, IEEE Transactions on Software Engineering, febrero 1986 pp. 198-210. 10 Derek Hatley. “the Use of Structured Methods in teh Development of Large Software-Based Avionics Systems”, AIAA/IEE 6th Digital Avionics Conference, Baltimores, 1984. 11 M. Webb y Paul Ward “Executable Dataflow Diagrams: An Experimental Implementation”. Structured Development Forum, Seatle, agosto 1986. 12 E. Reilly y J. Brackett, “An Experimental System for Executing Real-Time Structured Analysis Models”, Proceedings of the 12 th Structured Methods Conference, Chicago, agosto de 1987. PREGUNTAS Y EJERSICIOS 1-Dé una breve descripción de un DFD. ¿Cuál es la diferencia entre un DFD y un diagrama de flujo? 2- Indique seis sinónimos de diagrama de flujos de datos. 3-¿Para qué pueden usarse los DFD aparte de modelar sistemas de información? 4- ¿Cuáles son los cuatro principales componentes de un DFD? 5- ¿Cuáles son los tres sinónimos comunes de “proceso” en un DFD?

58 6- ¿Existe algún significado en la elección de un círculo para un proceso? ¿Sería mejor utilizar un triangulo o un hexágono? ¿Por qué si o no? 7- ¿Qué esta mal en el siguiente proceso?

8- ¿Qué está mal en el siguiente proceso? SI X>3 IR A QUARK 7 9-¿Qué está mal en el siguiente proceso?

MANZANA S

10-¿Qué está mal en el siguiente proceso?

REGISTR O DE CLIENTE S

11-¿Qué está mal en el siguiente proceso?

COSAS

59 12- ¿Por qué quería un analista de sistemas dibujar un proceso que consistiera en el nombre de una persona o grupo organizacional? 13-¿Se registran los flujos en un DFD a mostrar el movimiento de ka información? ¿Podrían mostrar el movimiento de alguna otra cosa? 14- ¿Qué tiene de mal este DFD?

15- ¿Qué tiene de mal este DFD?

16- ¿Cómo puede tener diferentes significados el mismo fragmento de datos en un DFD? Dibuje un ejemplo de tal situación. 17- ¿Cuál es el significado del siguiente DFD? X

X

CALCULA R COSAS

18- ¿Existe un límite para el número de entradas y salidas que puede tener un proceso en un DFD? ¿Cuál sería su reacción si viera un proceso con 100 entradas y 100 salidas? 19- ¿Qué tiene de mal este DFD?

17- ¿ A

20- ¿Qué tiene de mal este DFD?

B

60

17- ¿ X

Y

21- ¿Qué tiene de mal estos DFD? X a

p

A Y

b

22- ¿Qué tiene de mal este DFD? a

c Calcula r Factor flurp

b

23- Qué tiene de mal este DFD? a

c Calcula r Factor flurp

b

q

61 24- Dé una descripción de flujo de diálogo. 25- ¿Es válido el siguiente DFD? ¿Hay alguna manera alternativa de dibujarlo?

X

Y

Y

26- ¿Es válido el siguiente DFD? ¿Hay alguna manera alternativa de dibujarlo?

27- Bajo qué circunstancias esperaría ver copias del flujo de salida de un proceso? 28- ¿Por qué los DFD evitan mostrar detalles de procedimiento? 29- en el diagrama siguiente, ¿Cuántos elementos X y cuántos Y se requieren para producir una salida Z?

X Z Y

62

30- ¿Que representa un almacén en un DFD? 31- ¿Cuál es la convención para nombrar los almacenes en un DFD? 32- ¿Qué nombres alternativos pueden tener un almacén? ¿Es aceptable el término archivo? ¿Por qué si o por qué no? 33- ¿Qué nombres se utilizan comúnmente para describir paquetes de información en un almacén? 34- ¿Cuáles son las cuatros razones comunes para mostrar almacenes de implantación en un DFD? 35- ¿Cree que los almacenes de implantación deben permitirse en DFD? ¿Por qué si o por qué no? 36- ¿Qué significa un flujo no etiquetado que entra o sale de un almacén? 37- ¿Existe el límite para el número de flujos que entran o salen de un almacén? De ser así, señale dicho límite. 38- ¿Qué tiene de mal los siguientes DFD? (a)

(b)

(c)

(d)

63

(e)

39- ¿Cuáles son las cuatro posibles interpretaciones de un flujo de datos de un almacén a un proceso? 40- ¿Tiene sentido el siguiente DFD? ¿Por qué?

CLIENTES

Registro de cliente

domicilio de cliente

41- dé un ejemplo de una situación donde un proceso pudiera extraer porciones de más de un registro de un almacén en un solo acceso lógico. 42- dé un ejemplo de una situación donde un proceso pudiera exraer más de un paquete de información de un almacén en un solo acceso lógico. 43- ¿puede distinguir viendo únicamente los diagramas si los siguientes DFD están correctos? (a)

64

CLIENTES numero telefónico

(b)

CLIENTES datos de inventario

(c)

X

44- ¿Qué le sucede a un almacén tras habérsele retirado datos, a lo largo de un flujo, hacia un proceso? ¿Sucede esto en todos los sistemas o sólo en los de información? 45- ¿Cuáles son las principales interpretaciones de un flujo hacia un almacén? 46- ¿Cómo se muestra le eliminación de paquetes de información en un almacén? 47- ¿Qué tiene de mal el siguiente DFD?

65

CLIENTES

Trayectoria del proyectil

48- ¿Cuál es el proceso de mostrar un terminador en un DFD? 49- ¿Cómo debiera al analista identificar los terminadores? 50- ¿Qué representan los flujos entre terminadores y procesos? 51- ¿Qué tienen de mal los siguientes DFDs? (a)

CLIENTES

SISTEMA DE ÓRDENE S (b)

CLIENTE

( c)

SISTEMA DE ÓRDENE S

CALCULAR IMPUESTOS CALCULA R PAGO NETO

66 (d)

JUAN

x

SISTE MA

z

ALFREDO y

52- ¿Se le permite al analista cambiar los contenidos u organización de un terminador como parte de su proyector? ¿Qué tal si opina rotundamente que debiera cambiarse? 53- ¿Por qué no deben los procesos mostrar el nombre de la persona que actualmente realiza dicha función? 54. ¿Cuál sería una buena regala para nombrar los procesos en un DFD? 55.Dé cinco ejemplos de nombres de procesos que no le gustaría ver en un DFD? 56. ¿Cómo se puede saber si es probable que el nombre escogido para un proceso tenga sentido? 57. ¿Cuál sería la mala interpretación que probablemente daría el usuario a los números en las burbujas de un DFD? 58. ¿Cómo puede saberse si es probable que un DFD dado es demasiado complejo para que lo comprenda el usuario? 59. ¿Cuánto se debería insistir en las reglas de complejidad? ¿Deben permitirse exepciones? ¿Por qué? 60. ¿por qué resulta a menudo necesario redibujar varias veces un DFD? 61. ¿Cuáles son los aspectos principales para determinar si un DFD será estéticamente agradable? ¿Cree que pudieran expresarse como estándares? 62. ¿Prefieren sus colegas burbujas u óvalos para los procesos? ¿Qué prefiere usted? 63. ¿Cree que los flujos entre procesos deben mostrarse como curvas o como rectas? ¿Se le ocurren ventajas o desventajas en cualquiera de éstas? ¿Es importante esto? 64. ¿Qué es un sumidero infinito? 65. ¿Qué es la generación espontánea de burbujas en un DFD? ¿Por qué debe evitarse en un DFD típico?

67 66. ¿Por qué son peligrosos los flujos y procesos no etiquetados? 67. ¿Por qué son generalmente erróneos los almacenes de únicamente lectura o únicamente escritura en un DFD? 68. ¿Por qué son importantes los DFD por niveles en el modelo de un sistema? 69. ¿Cuántos niveles de un DFD debiera el analista esperar ver en un sistema grande típico? ¿Puede sugerir un límite superior para el número de niveles en un DFD? 70. en un DFD por niveles: (a) ¿Cómo lamría a las burbujas “hijas” debajo de la burbuja 2.3? (b) ¿Y a la figura en la que aparece la burbuja 2.3? (c) ¿Cuántas figuras de mayor nivel hay por encima de la figura en la que aparece la burbuja 2.3? ¿Cómo se llaman? 71. ¿Es necesario que todas las partes de un sistema se dividan hasta el mismo nivel de detalle? ¿Por qué? 72. Suponga que alguien le mostraría un DFD en el cuál la burbuja 1 estuviera dividida en dos niveles inferiores, y la 2 en 17 niveles inferiores. ¿Cuál sería su reacción? ¿Qué podría recomendar? 73. ¿Qué significa balancear en el contexto de este capítulo? ¿Cómo puede darse cuenta si un DFD está balanceado? 74. ¿Por qué no está balanceada la figura 9.22 (b) de este capítulo? 75. ¿Cuál es la regla a seguir para mostrar almacenes en los diferentes niveles de un DFD? 76. ¿Qué es un almacén local? ¿Cuáles son las reglas para mostrar un almacén local en un DFD por niveles? 77. Proyecto de investigación: ¿Cuál es la relación entre la regla para mostrar un almacén local y el concepto de diseño orientado a objetos? Para más información acerca de esto, vea loa capítulos 19 y 20. 78. ¿Qué problemas pudieran asociarse con el desarrollo de un conjunto de DFD por niveles en forma descendente ( en comparación con la lectura de un conjunto de DFD que ya exista de manera descendente? 79. ¿Qué es un flujo de control? ¿En qué difiere de un flujo de datos? 80. ¿Qué es un proceso de control? ¿En qué difiere de un proceso normal en un DFD? 81. ¿Qué es un almacén de control? ¿En qué difiere de un almacén normal en un DFD? 82. dibuje un DFD para modelar la siguiente receta de Fruits de Mera u Riz ( calamares surtidos con arroz), tomada de The New York Times 60-Minute Gourmet, de Pierre FRaney (Nueva York: TIMES Books, 1979).