Herramientas y metodologías de análisis y diseño estructurado (página 3)

Capítulo II. — El Modelo Ambiental 13 P

P

P Legislación promulgada por gobiernos. La mayoría de esos sistemas son del tipo de sistemas generadores de informe, por ejemplo, sistemas que informan el empleo (o desempleo) de obreros con base en la edad, sexo, nacionalidad y así sucesivamente. O un nuevo sistema po- dría construirse para acomodar alteraciones incluidas en nuevas leyes de impuestos. Deseo del cliente de minimizar los gastos operacionales de algún área de su compañía. Eso era especialmente común en los años 60/70 y en la actualidad se cumple en muchas compañí- as pequeñas que están instalando su primera computadora hoy. Aun así la mayoría de las or- ganizaciones que tienen computadoras instaladas hace 10 años ya se beneficiaron de las opor- tunidades evidentes de reducir el exceso de empleados. El deseo del cliente de obtener alguna ventaja estratégica para una línea de productos o área de negocio en que está operando. Esto podría hacerse organizando y manejando información sobre el mercado para que pueda producirse el género de producto de una manera más opor- tuna y económica. Un buen ejemplo de esto se da en las líneas aéreas donde una mejor infor- mación sobre las tendencias del mercado y las preferencias de los pasajeros puede manejar las escalas de los vuelos con mayor eficiencia y determinar precios más bajos. El modelo ambiental está compuesto de tres partes: la Declaración de Objetivos, el Diagrama de Contexto y la Lista de Eventos. Cada uno de esos componentes y las herramientas que se usan para su construcción, se describirán a continuación.

II.2.1. La Declaración de Objetivos

El primer componente del modelo ambiental es una declaración textual y concisa de los obje- tivos del sistema. Tal declaración se destina para la gerencia (o el cliente) y otras personas que no están involucradas directamente en el desarrollo del sistema. Un posible ejemplo de una declaración de objetivos es: El propósito es manipular todos los detalles de las ordenes de compra de libros, así como los remitos, facturación y recibos. La información sobre las demandas de libros también debe estar disponible para otros sistemas, como "Marketing"," Ventas" y" Contabilidad". La declaración de objetivos puede tener una, dos o varias frases, en un único párrafo simple- mente, puesto que no esta destinada a dar una descripción detallada y abarcativa del sistema. Seme- jante esfuerzo sería inútil: esa tarea pertenece a los modelos ambiental y comportamental. Como resultado, la declaración de objetivos será deliberadamente vaga respecto a muchos de- talles. Una buena declaración de objetivos es la que establece el ámbito del sistema, sin margen de duda y, con la menor cantidad posible de palabras. Tiene que ser formulado de una manera abstracta y conceptual. Muchos analistas de sistemas también consideran que la declaración de objetivos debe cuanti- ficar los beneficios que serán obtenidos por el nuevo sistema; por ejemplo: "el propósito del sistema es reducir el tiempo necesario para procesar una demanda de tres semanas en un día". Aunque esto puede ser muy útil en pequeños proyectos localizados, no es fácil de conseguir en grandes proyec- tos. En estos casos es necesario un análisis Costo/Beneficio en forma particular.

II.2.2. El Diagrama de Contexto

El diagrama de contexto realza varias características importantes del sistema: P Las personas, organizaciones o sistemas con los que el sistema se comunica. Esos elementos son conocidos como Agentes Externos, Entidades Externas o Terminadores.

14 P P P Cliente Gerencia pedidos, pedidos cancelados

factura nota de embarque informe de ventas Sistema de Pedidos de Libros pedidos de reimpresión

libros que llegan al depósito Situación de Crédito Editora factura Fig. II-2: Un ejemplo de Diagrama de Contexto para el Sistema de pedidos de libros

Los datos que el sistema recibe del mundo externo y que debe procesar de algún modo. La información producida por el sistema y enviada hacia el mundo externo. Los límites entre el sistema y el resto del mundo. Cliente Recetas Internas La Fig. II-2 muestra un ejemplo de Diagrama de Contexto.

II.2.2.1. Construcción del Diagrama de Contexto En el diagrama de contexto una única burbuja (proceso) representa el sistema. El nombre de ese proceso normalmente es el nombre del sistema o una sigla. Observe que, en el caso más extre- mo, el nuevo sistema puede representar una organización entera; en ese caso, en el nombre del pro- ceso estaría, normalmente, el propio de la organización. Los Agentes Externos (o Terminadores) son representados por un cuadro rectangular y se co- munican directamente con el sistema a través de los Flujos de Datos o de Control. Observe que los Agentes Externos no se comunican directamente entre sí. De hecho, los Agentes Externos tienen comunicaciones con el sistema, pero por definición, los Agentes Externos

Proveedor Bancos Cliente Agencia de Anuncios Seguros Libros Ltda. j i h g f e * d c b a k Fig. II-3: Ejemplo de Diagrama de Contexto con agentes externos duplicados

Capítulo II. — El Modelo Ambiental

Capítulo II. — El Modelo Ambiental 15 no son parte del sistema, la naturaleza y el volumen de las interacciones entre ellos son irrelevantes. Si durante las charlas con los usuarios se decidió que es esencial saber cuando, porque o como un Agente Externo se comunica con otro, entonces estos son parte del sistema y deben ponerse dentro del diagrama de contexto que representa el sistema completo. Deben hacerse otras observaciones sobre los agentes externos: P

P

P Algunos agentes externos pueden tener un gran número de entradas y salidas. Para evitar un diagrama muy congestionado, puede ser conveniente dibujarlos más de una vez. Los agentes externos duplicados están marcados para distinguirlos del otro. En la Fig. II-3, en la parte su- perior se presenta el agente con una línea diagonal. En el modelado de los roles llevados a cabo por los agentes externos se debe tener cuidado de no confundírselos con los agentes físicos que los llevan a cabo. Por ejemplo, la misma com- pañía puede llevar a cabo el rol del banco y agencia de seguros, pero tendrán flujos de infor- mación diferente y como otras compañías pueden especializarse en un solo rol, es conveniente especializar los roles en propios agentes. Los agentes externos pueden ser organizaciones, unidades o personas, que es la situación normal cuando se está modelando aplicaciones de comercio típicas. Pero los agentes también pueden estar generando y recibiendo señales de control, como cuando se modelan aplicacio- nes de automatización. Como estamos principalmente interesados en el desarrollo del modelo esencial del sistema, es importante que se distinga entre fuentes y manipuladores cuando se dibuja a los agentes externos en el diagrama de contexto. Un manipulador es un mecanismo, dispositivo, o el medio físico para transportar datos dentro o fuera del sistema. Cuando un manipulador es conocido y visible a los usuarios de la implementación actual del sistema, existe una tendencia a mostrar al manipulador, en lugar de la verdadera fuente de los datos. Sin embargo, como el nuevo sistema normalmente tendrá la opción de modificar la tecnología con que los datos se traen dentro y se envían fuera del sistema, el manipulador no debe mostrarse. Es preferible hablar de "Cliente" y no de "Correo" cuando las demandas se hacen a través de una agen- cia de correo. Como un compromiso, principalmente si el usuario insiste, un agente externo puede etiquetar- se para mostrar al verdadero origen y al manipulador que maneja los datos (por ejemplo para etique- tar con el nombre "Cliente vía Correo"). Los flujos mostrados en el diagrama de contexto modelan los datos que llegan y dejan el sis- tema. Estos serán incluidos en el diagrama de contexto si son necesarios para determinar un evento del ambiente al que el sistema debe contestar, o si son necesarios (como datos) para que se produzca una respuesta. También pueden mostrarse los flujos de datos en el diagrama del contexto cuando los datos son producidos por el sistema para responder a un evento. Sin embargo, habrá ocasiones en que un agente externo no iniciará entradas, porque este no conoce si el sistema necesita su entrada. Similarmente, hay ocasiones en que el sistema no comien- za una salida, porque no conoce si el agente externo la necesita (o la requiere). En esos casos una solicitud es una parte esencial del modelo. A veces es conveniente mostrar flujos de entrada y salida como un flujo de diálogo (una fle- cha de dos puntas). Esa concentración de dos flujos en uno puede clarificar el diagrama de contexto y describir la calidad de estar relacionados fuertemente de dos flujos. Hay también una clase de flujos que no representan entrada o salida de datos del sistema sino que establecen la necesidad de ejecutar una función dada. Estos flujos se denominan flujos de con- trol y son mostrados con una línea punteada. En la Fig. II-4 se muestra parte de un diagrama de contexto, que incluye algunas de las clases de flujos mencionadas.

16 Capítulo II. — El Modelo Ambiental AA El Sistema BB Cond Flujo Temporal Flujo de Control Fig. II-4: Un diagrama de contexto parcial

Una descripción detallada de los tipos de flujos en un diagrama de contexto se presentará en la sección siguiente con los tipos de eventos asociados.

II.2.3. La Lista de Eventos

La lista de eventos es una lista narrativa de los estímulos que ocurren en el mundo externo, y al que el sistema debe responder. El ejemplo que sigue presenta una lista de eventos para el sistema de demandas de libros: 1. Cliente entrega demanda. (F) 2. Cliente cancela demanda. (F) 3. La dirección recibe informe de ventas. (T) 4. La demanda de reimpresión llega al depósito. (C) Observe que cada evento se etiqueta con F, T o C que son para mostrar que el evento es guia- do a través de flujo (F), un evento temporal (T) o un evento de control (C). P Un evento dirigido por flujo se asocia a un flujo de datos; es decir, el sistema percibe la ocu- rrencia del evento cuando un grupo de datos llega (o varios grupos de datos). Sin embargo, no todos los flujos de datos en el diagrama de contexto son necesariamente eventos dirigidos por flujos. Considere el ejemplo (parcial) de la Fig. II-5. A primera vista podría deducirse que los flujos de datos A, B y C son todos los indicadores de eventos separados y discre- tos. Sin embargo, puede ser que el flujo de datos A este asociado a un evento (por ejemplo, el flujo de datos es iniciado por el agente externo X). Para procesar el evento, puede ser que el sistema exi- ge explícitamente a los otros agentes externos Y y Z las entradas relativas a los flujos de datos B y C para producir una respuesta. X Y A B El Sistema

C

Z

Fig. II-5

flujo de Ag 1 Ct Capítulo II. — El Modelo Ambiental 17 De ese modo, no existe necesariamente una correspondencia de uno a uno entre los flujos de datos del diagrama de contexto y los eventos de la lista de eventos. En general, cada flujo de datos o es un evento, o es exigido por el sistema con el propósito de procesar un evento. P Los Eventos Temporales se descargan en un cierto momento. Estos son algunos ejemplos de eventos temporales: – – – Un informe diario de todas las demandas de libros que se emite a las 9:00 horas. Las facturas deben generarse a las 15:00 horas. Deben generarse los informes para la dirección cada hora. Observe que los eventos temporales no se descargan ni son representados por cualquier flujo de datos de entrada; se puede imaginar que el sistema tiene un reloj interno con el que puede controlar el pasaje del tiempo. Recuerde, sin embargo, que un evento temporal puede exigir que el sistema pida entradas de uno de los agentes externos. Así, pueden asociarse uno o más flujos de datos a un evento temporal, aunque los flujos de datos no representen el propio evento. P Los eventos de control son estímulos externos que ocurren en momentos imprevistos. Un evento de control no se relaciona con el paso normal del tiempo, así, el sistema no lo puede prever por uso del reloj interno. Y al contrario de un evento orientado por flujo de datos, un evento de control no marca su presencia por la llegada de datos. Un evento de control está representado por un flujo de control (trazado) en el diagrama de contexto. Ese flujo no transporta datos, simplemente informa al sistema que debe ejecutar una acción inmediata. Estos son muy comunes en los sistemas de tiempo real [Ward 85b, 86].

Tipos de Eventos Evento de Flujo de Datos Ag 1 Ag 2 flujo de inicio flujo de salida Trans x El flujo de datos flujo de inicio es la entrada de datos para la transacción Trans x, tiene, implícitamente la función de activar la transacción, a causa de un Evento de Flujo (esto es modelado por el flujo de control que viene implícito con el flujo de inicio). Evento Temporal Ag 1 Ag 2 flujo de entrada flujo de salida Trans x Ct La condición Ct es una condición temporal que activa a la transacción Trans x a causa de un Evento Temporal. Evento de Control Ag 1 Ag 2 flujo de entrada flujo de salida Trans x Ag 2 El agente externo Ag 2 activa a la transacción Trans x a causa de un Evento de Control. Múltiples Eventos, Simple Respuesta Ag 1 Ag 2 flujo de entrada flujo de salida Trans x Ct1 Ct2 Hay múltiples condiciones temporales (Ct1 y Ct2) que activan a la transacción Trans x. Cada una de las condi- ciones se corresponde con un Evento Temporal. Eventos de Múltiples Respuestas Ag 1 Ag 1 entrada flujo de entrada Ag 2 flujo de Trans x salida flujo de salida Trans y Hay múltiples transacciones (Trans x y Trans y ) activadas por la condición temporal Ct. Dichas transacciones son activadas por un Evento Temporal que precisa de múlti- ples respuestas.

18 Capítulo II. — El Modelo Ambiental II.2.3.1. Construcción de la Lista de Eventos La lista de eventos es una simple lista textual de eventos del ambiente a los cuales el sistema debe responder. Al construirla asegúrese de distinguir entre un evento y un flujo relacionado a un evento. Por ejemplo, la sentencia de abajo probablemente no es un evento: "Un pedido de un cliente es recibido por el sistema" Sino que probablemente describe un flujo de datos de llegada por el cual el sistema toma co- nocimiento de la ocurrencia del evento. Un nombre más apropiado para el evento podría ser: "Cliente entrega pedido" Esto puede parecer un ejercicio semántico, pero no lo es. Si describiéramos un evento desde el punto de vista del sistema (esto es, visto desde adentro), podríamos identificar erróneamente los flujos de llegada que no son eventos por sí mismos, pero que son necesarios para procesar algún otro evento. De ese modo, siempre deseamos describir los eventos desde el punto de vista del am- biente (esto es, desde afuera del sistema). En la mayoría de los casos, el medio más fácil para identificar los eventos relevantes de un sistema es visualizar al sistema en acción: lo que implica examinar cada agente externo y preguntar cuál es el efecto que sus acciones pueden tener en el sistema. Esto se hace habitualmente en combi- nación con los usuarios del sistema, que pueden desempeñar el rol de agentes externos. Sin embar- go, debemos tener la precaución de distinguir entre los eventos discretos que hayan sido acciden- talmente empaquetados juntos, como si fueran un único evento; esto sucede casi siempre con los eventos Orientados por Flujos. Debemos examinar un evento candidato y preguntarnos si todas las instancias del evento en- vuelven los mismos datos; si los datos estuvieran presentes en algunas instancias y ausentes en otras, podemos tener de hecho dos eventos distintos. Por ejemplo, si examináramos cuidadosamente el evento "cliente entrega pedido", veremos que algunas instancias del evento incluyen al elemento de datos "vendedor" y otros no; y veremos que la respuesta del sistema será diferente cuando un vendedor estuviera involucrado. De este modo sería más apropiado tener los dos eventos separados: "cliente entrega pedido", y "vendedor entrega pedido de cliente", lo que también muestra que posi- blemente hay dos agentes externos (vendedor y cliente). Además de esto, conviene aclarar que la lista de eventos debe incluir no solamente las inter- acciones normales entre el sistema y sus agentes externos, sino que también, situaciones de fallas. Como estamos creando un modelo esencial, no tenemos que preocuparnos por las fallas del sistema; pero debemos tener en consideración las posibles fallas por errores causados por los agentes exter- nos. Como los agentes externos no son parte del sistema no es posible modificar su tecnología con el propósito de impedir errores, solo es posible responder con un mensaje e impedir que esos errores generen dificultades en el interior del sistema [Ward 85b].

II.2.4. ¿Qué va primero: el Diagrama de Contexto o la Lista de Eventos?

Se puede comenzar con la lista de eventos o con el diagrama de contexto. Realmente, esto no importa, a medida que los componentes del modelo ambiental son generados se debe confirmar que haya consistencia entre ellos. Que hacer primero depende en gran medida del interlocutor, con quien el analista procura co- nocimiento sobre el sistema. Si el interlocutor es un programador de mantenimiento de una versión actualmente en funcionamiento, es muy probable que sea más conveniente el desarrollo del diagra- ma de contexto. El programador de mantenimiento dará información focalizada sobre las entradas y salidas del sistema. En tanto que si el interlocutor es un usuario o algún funcionario de nivel inter- medio o alto en la organización, será más fácil la construcción de la lista de eventos.

Capítulo II. — El Modelo Comportamental 19 Cuando ambos componentes del modelo ambiental estuvieren terminados, estaremos en con- diciones de afirmar lo siguiente: P

P P

P Cada flujo de entrada en el diagrama de contexto será necesario en el sistema para reconocer que un evento ocurre o para la generación de una respuesta a un evento, o ambos. Cada flujo de salida debe ser una respuesta a un evento. Para cada evento (no temporal ni de control) de la lista de eventos, deberá haber un flujo de datos de entrada a partir del cual el sistema pueda detectar que dicho evento ha ocurrido. Cada evento debe generar una salida inmediata como respuesta, o almacenar datos para ser emitidos como salida posteriormente (como respuesta o parte de una respuesta para algún otro evento), o intervenir con que el cambio de estado del sistema (lo cual será indicado en el dia- grama de transición de estados que será elaborado más adelante).

II.2.5. El Diccionario de Datos Inicial

Un sistema de mediano porte acostumbra tener algunas decenas de flujos de datos que entran y salen; un gran sistema puede tener, literalmente, centenas. Ahora, esos flujos de datos serán even- tualmente definidos en gran detalle en el modelo comportamental, puede ser útil iniciar rápidamente la preparación de un diccionario de datos. Esto puede ser importante si las interfaces entre el siste- ma y los diversos agentes externos estuvieran sujetas a cambios y negociaciones; cuanto más rápido se comiencen a definir formalmente estas interfaces más rápido podrán ser finalizadas.

II.3. El Modelo Comportamental

Una vez construido el Modelo Ambiental, tenemos una buena idea del ambiente en el cual el sistema debe trabajar. Conocemos los eventos que lo estimulan (Lista de Eventos) y las respuestas que tienen que generar el tratamiento de cada evento, como también que agentes externos están in- volucrados (Diagrama de Contexto). Al final de la etapa de construcción del modelo ambiental también se dispone de una primera versión del Diccionario de Datos con una descripción de cada uno de los flujos de datos del Diagrama de Contexto. Con el Modelo Comportamental tenemos que descubrir y modelar la manera en la cual el sis- tema realiza los eventos, para generar las respuestas deseadas por los agentes externos y, también, los depósitos persistentes. Es decir, tenemos que modelar todo lo que acontece en el interior de la burbuja del Diagrama de Contexto. Para describir lo que sucede cuando un evento es recibido por el sistema se utiliza: Diagrama de Flujo de Datos preliminar, Diagrama de Entidades y Relaciones y Diccionario de Datos (Fig. II-6).

II.3.1. Creación del DFD

Para la creación del DFD básicamente existen dos enfoques: Partición en Eventos [McMenam 84; Yourdon 89] (Fig. II-6) y Enfoque de Análisis Estructurado Clásico [DeMarco 79; Gane 79] (Fig. II-7). En el enfoque de partición por eventos para la construcción del DFD preliminar (Fig. II-6), se agrega una burbuja por cada evento definido en la lista de eventos. Por cada evento, se especifican los flujos (control y datos), agentes externos y depósitos de datos. Al final, es validado en relación con el diagrama de contexto.

P

P

P

20 Parálisis del análisis: En muchos sistemas grandes y complejos, simplemente no existe algo que pueda orientar al analista de sistemas en el diseño del DFD de nivel 0 adecuado a partir del diagrama de contexto. De esta forma, el se sienta en su mesa, contemplando el diagrama de contexto, esperando por la inspiración divina, o por alguien que le diga que el proyecto so- brepaso el tiempo de análisis y que ya es hora de iniciar su codificación. El fenómeno de los seis analistas: En un sistema grande y complejo muchas veces hay más de un analista de sistemas contemplando el diagrama de contexto. Para dividir el trabajo sin que uno interfiera con el trabajo de los otros, ellos crean arbitrariamente un DFD de nivel 0 con una burbuja para cada uno de ellos. De este modo, si hubiera seis analistas, el DFD de nivel 0 tendría seis burbujas. La subdivisión física arbitraria: En muchos casos un nuevo sistema se basa en otro sistema ya existente o es la informatización de una organización. Muchas veces es utilizada la subdivi- sión del sistema actual (por ejemplo, las áreas actuales de la organización o los sistemas de procesamiento de datos existentes) para la subdivisión del sistema nuevo, entonces se obtiene

Capítulo II. — El Modelo Comportamental DFDs para cada Evento Lista de Eventos 1.- cliente vie 2.- client 3.- cliente 4.- cliente vie 5.- cliente vie DFD Diagrama de Contexto Validación Validación Opcional preliminar

Fig. II-6: Partición en Eventos [McMenam 84; Yourdon 89]

Diagrama de Contexto

Sin estrategia que asista en el criterio de partición DFD de primer nivel o de nivel 0

División top-down de cada proceso … … Fig. II-7: Enfoque de Análisis Estructurado Clásico [DeMarco 79; Gane 79]

Este enfoque, al contrario del enfoque clásico de análisis estructurado [DeMarco 79; Gane 79] (ilustrado en la Fig. II-7), presenta una manera sistemática para desarrollar el DFD preliminar, en base al estudio de cada uno de los eventos por separado, y fue llamado por McMenamim y Palmer de partición en eventos [McMenam 84]. En el enfoque de análisis estructurado clásico (Fig. II-7) para la construcción del DFD de primer nivel (o nivel 0), el analista (o el grupo de analistas) estudia el diagrama de contexto y crea un DFD de nivel 0 sin una estrategia que lo asista. Sobre la base de su conocimiento del sistema, o del tipo de aplicación, divide en "Burbujas Importantes" (por ejemplo, que representen subsiste- mas). Este enfoque tiene los siguientes problemas:

Capítulo II. — El Modelo Comportamental 21 una subdivisión desde el punto de vista funcional, lo que perpetua el sistema actual, con sus vicios y virtudes. Por esta razón el enfoque de partición por eventos es el mas utilizado. Este enfoque no esta- blece una actividad puramente top-down ni bottom-up. Una vez que el DFD preliminar está listo, puede ser preciso crear algunos niveles superiores (abstracción de funciones) y/o algunos niveles inferiores (descomposición de funciones). El DFD preliminar puede ser representado como un único diseño o por un conjunto de DFDs separados (uno por cada evento). En un sistema de poca o moderada cantidad de eventos (ej.: 20 o 30 eventos), la construcción de un único DFD compuesto permite una mejor comprensión global y facilita la actividad de abstracción pero, en un sistema con muchos eventos, esa posibilidad será impracticable. Para la construcción del diagrama de flujo de datos preliminar, con un enfoque de partición por eventos, la metodología de análisis estructurado moderna propone la siguientes cuatro etapas: 1. 2.

3.

4. Se diseña una burbuja (proceso) para cada evento de la Lista de Eventos. La burbuja recibe un nombre de acuerdo con la respuesta que el sistema debe dar al evento asociado. Se diseñan los flujos de entrada y salida apropiados de modo que cada burbuja sea capaz de emitir una respuesta necesaria, y se diseñan los depósitos para la comunicación entre las bur- bujas. El DFD preliminar resultante es verificado en relación con el Diagrama de Contexto, la Lista de Eventos y el Modelo de Datos para confirmar si esta completo y consistente. La primera etapa es mecánica por naturaleza. Si hubiera 25 eventos en la lista de eventos, habrá 25 diagramas comportamentales (25 burbujas en el DFD preliminar). Para facilitar consultas, se le asigna un número de evento para la burbuja a la que está asociado. Así, el evento 13 corres- ponderá a la burbuja 13. La segunda etapa también es mecánica, pero es necesario cierto análisis: cada burbuja recibe un nombre apropiado, en relación a la respuesta que genera. Es necesario examinar el evento y pre- guntar ¿Qué respuesta el sistema debe dar a este evento?. El objetivo es procurar un nombre lo más específico posible. Por ejemplo, para el evento Cliente Efectúa Pago, un nombre adecuado para la burbuja asociada sería Actualizar Cuenta (si es esta la única respuesta exigida), en vez de Procesar Pago de Cliente, que no dice nada sobre la naturaleza de la respuesta. La tercera etapa no es mecánica pero, normalmente, es bastante simple. Para cada evento se detallan sus diagramas comportamentales, es decir para cada burbuja diseñada se identifican: los flujos de entrada que la burbuja necesita para ejecutar su función, las salidas (si hubiera alguna) que la burbuja produce y los depósitos de datos a los que la burbuja debe tener acceso. Esto normalmen- te se hace mediante entrevistas con los usuarios apropiados y focalizando cada evento a la vez o, más precisamente, a su burbuja asociada. Entonces se debe preguntar: ¿Qué necesita esta burbuja para llevar a cabo su función? y ¿Qué salidas genera?. La cuarta etapa es una actividad de verificación de consistencia: P Se debe certificar que cada entrada en el diagrama de contexto este asociada a una entrada en uno de los diagramas comportamentales y que cada salida producida por un proceso en el DFD preliminar (una transacción) sea enviada a un depósito, o a una salida externa de las mostradas en el diagrama de contexto. Existen dos casos especiales: –

– Eventos únicos que provocan múltiples salidas: Por cada una de las respuestas, es incluida una burbuja en el DFD Preliminar. Eventos múltiples que causan la misma respuesta: En este caso, una burbuja está asociada a más de un evento. Esta situación solo es válida si los flujos de datos de entrada debidos a los eventos son idénticos, y las respuestas de la burbuja también.

22 Capítulo II. — El Modelo Comportamental P

P

P Cada entidad del modelo de datos debe ser referenciada por lo menos por un proceso (transac- ción), para escritura y uno para lectura. Cada atributo de una entidad del modelo de datos debe ser componente de por lo menos un flujo de escritura y uno de lectura. Los flujos de escritura y lectura de un depósito de datos deben contener solamente un subcon- junto de los atributos de la entidad asociada y ninguna otra cosa.

II.3.2. Creación del Modelo de Datos

La creación del modelo de datos es una actividad que puede ser hecha en paralelo o también anteceder a la creación del DFD Preliminar, los dos modelos son independientes y ninguno de ellos puede ser considerado como predominante en la construcción del otro. Para ver esto tenemos que: P

P P Son complementarios en la creación: Uno agrega información que puede ser usada en la cons- trucción del otro. Por ejemplo, las entidades del ERD, son depósitos en el DFD. Son complementarios en la validación: Pueden ser usados para verificaciones cruzadas. Son complementarios en el modelamiento: El diagrama de entidad-relación permite el mode- lamiento de los datos y las interrelaciones entre ellos (no incluidas en el DFD). Por otro lado, los DFDs permiten el modelado de funcionalidad de creación, mantenimiento, vinculación, análisis y derivación de datos. Esto es, permiten el modelamiento de las características diná- micas del sistema (no incluidas en el DER). Hasta ahora, no existe un orden establecido por la metodología para la construcción del DFD y del modelo de datos, es fuertemente recomendable elaborar un DER preliminar antes de detallar los diagramas comportamentales de cada evento. Con esto se evita el riesgo de diseñar un banco de datos como colección de archivos de intercambio entre procesos. El modelo ambiental también puede ser usado en la elaboración del DER inicial. Los sustanti- vos en la lista de eventos representan entidades en el DER; por ejemplo, en el evento Cliente intro- duce pedido, identificamos inmediatamente Cliente y Pedido como entidades candidatas. También los verbos son útiles pues pueden representar relaciones que se desean mantener registradas entre los sustantivos. En el ejemplo de evento Cliente introduce pedido identificamos el verbo Introduce posible- mente como una transacción que deberá ser modelada con un diagrama comportamental, pero tam- bién como una relación que tiene que ser registrada entre las entidades Cliente y Pedido. Por último, los adjetivos describen cualidades de los sustantivos y pueden representar atribu- tos de las entidades o la necesidad de una clasificación (o especialización) de ellas. Por ejemplo, si tuviéramos el evento Cliente joven introduce pedido, el adjetivo joven puede sugerir la posibilidad de existencia de una entidad Cliente y otra Cliente joven, que tienen características semejantes a la entidad Cliente, pero que agregan propiedades de juventud como atributos y relaciones específicos. La edad de un cliente puede ser interpretada de maneras diferentes en sistemas diferentes o puede ser irrelevante. Si el sistema es uno de ventas en un área comercial, la edad puede ser irrelevante pero, si el área se dedica a la venta de seguros de vida, la edad es una cualidad importante para la venta. Hay que tener mucho cuidado con una clasificación de entidades basada sobre un atributo que tiene muchas probabilidades de cambiar, pues puede producir más dificultades que los benefi- cios que modela. Podemos usar a lista de eventos como medio de verificación cruzada del DER inicial: todos los sustantivos de la lista de eventos deben corresponder a entidades del DER.

Capítulo II. — El Modelo Comportamental 23 1.

2.

3. Cada agrupamiento de procesos debe involucrar respuestas estrictamente relacionadas (véase que cada burbuja en el DFD preliminar tiene un nombre relativo a la respuesta de un evento de la lista de eventos). Esto habitualmente significa que los procesos trabajan con datos estre- chamente relacionados. Agrupar procesos que trabajen con los mismos almacenamientos. Así, si usted encontrara un grupo de procesos con flujos para el mismo depósito, sin que otros procesos (que no son del grupo) se refieran a este depósito, entonces puede crear una burbuja, en el nivel más alto, que oculte el depósito. La figura 6 presenta un ejemplo de un grupo de procesos más a la derecha. Se debe notar que la persona que examinara sus diagramas de flujo de datos, será un usuario o un analista de sistemas o un diseñador, que quiere ver todo de una sola vez. Un buen criterio de agregación o agrupamiento no tiene más de siete más o menos dos (7 ± 2) fragmentos de información (considerando como fragmentos de información a los Procesos y los Depósitos de Datos). La tercera regla no es un criterio dominante. No quiere decir que tenemos que construir gru- pos de siete burbujas en la abstracción. Las reglas están listadas en orden de dominancia, la tercera ayuda para controlar las complejidades de los DFDs resultantes. Aplicando estos criterios, usted tiene que generar abstracciones para la obtención de un DFD de nivel 0 de complejidad adecuada, esto es, uno de no más de 7 ± 2, fragmentos de información. El DFD Preliminar también puede tener burbujas muy complejas, situación que será evidente a la hora de detallar su especificación. Si la especificación de una burbuja es muy larga (una página o más), la función es muy compleja y debe ser subdividida. Por ello, puede ser preciso refinar el DFD Preliminar creando niveles más bajos. Algunas reglas a seguir para la subdivisión en niveles de detalle son las siguientes: DFD de nivel más alto

Abstracción

DFD preliminar

Fig. II-8: Abstracción Los procesos del DFD Preliminar que pueden ser asociados a una abstracción de mayor nivel, son agregados para crear una única burbuja en el DFD de nivel superior.

II.3.3. Subdivisión en Niveles

El DFD preliminar se compone de un solo nivel con una burbuja para cada uno de los even- tos. Para un sistema mediano o grande (50 o más eventos), el DFD preliminar contiene demasiadas burbujas. Para mejorar la comprensión, ahora, precisamos subdividirlo en niveles superiores (abs- tracción). Esto quiere decir que deseamos agrupar los procesos (o burbujas) relacionados en fun- ciones de más alto nivel de abstracción, cada uno representando una burbuja en el diagrama de más alto nivel (Fig. II-8). Existen tres reglas que nos ayudan en el proceso de abstracción:

24 Capítulo II. — El Modelo Comportamental P En algunos casos, el enfoque de descomposición funcional pura es adecuado. Esto es, si usted encuentra una burbuja de proceso que ejecute una función compleja, intente identificar sub- funciones, cada una de la cuales pueda ser un círculo de nivel inferior. Suponga, por ejemplo, que tengamos un proceso llamado Ajustar trayectoria de misil; este podría ser una burbuja responsable por el mantenimiento de un evento temporal en un sistema de dirección de misi- les en tiempo real. La funcionalidad general de ajustar la trayectoria del misil podría ser des- compuesta en varias subfunciones: – – – – – – Calcular la variación de la coordenada X. Calcular la variación de la coordenada Y. Calcular la variación de la coordenada Z. Calcular un nuevo factor de Arrastre Atmosférico. Calcular la nueva Velocidad del Viento. … P En otros casos, los flujos de datos que llegan y salen de la burbuja darán una mejor indicación para la subdivisión en niveles descendentes. Un criterio muy importante para la validación del trabajo de subdivisión (sea abstracción o refinamiento) es el balanceo. Es preciso verificar si las entradas y salidas a una burbuja de un de- terminado nivel corresponden a las entradas y salidas del diagrama de nivel inmediatamente infe- rior. Para la subdivisión del DFD en niveles inferiores pueden ser aplicados los siguientes criterios: P

P

P

P

P

P Si la burbuja es muy compleja, un DFD de nivel más bajo (más detallado) puede ser creado, explotando en varias subfunciones. Si la burbuja representa una transacción de generación de informes o unión de archivos, puede ser modelada a través de diagramas de Jackson. Si la burbuja es muy simple, basta una especificación del proceso usando Diagramas de Ac- ción, o Diagramas Nassi-Shneiderman, o un Pseudo-Lenguaje Estructurado, o cualquier otra técnica simple de especificación de procesos. Si la burbuja es una transacción de manipulación de la base de datos, no muy simple, un Dia- grama de Navegación puede ser creado. Si la burbuja representa un diálogo interactivo con un agente externo, un Diagrama de Tran- sición de Estados puede ser creado. Si la burbuja involucra varias condiciones de activación de varias posibles acciones, las Ta- blas de Decisión pueden ser convenientes.

II.3.4. El Diccionario de Datos

El diccionario de datos es una herramienta fundamental en el modelamiento de sistemas. Las herramientas gráficas como los diagramas de flujo de datos, los diagramas de entidad-relación, los diagramas de transición de estados, etc., son de mucha importancia para el modelamiento estructu- ral de los sistemas (estructuras funcionales, estructuras de información, estructuras de comporta- miento, etc.) y permiten una adecuada interpretación general de las ideas modeladas pero, no son completos. Para contar con una especificación completa es preciso tener una descripción textual de los detalles que no pueden ser especificados en los diagramas. La importancia del diccionario de datos queda mucho más clara si usted trata de recordar los días de escuela primaria, en las aulas de lengua cuando usted era constantemente asediado por nue- vas palabras. Recuerde también, los cursos de lengua extranjera, especialmente aquellos que exigían que leyera libros y revistas o hiciera traducciones. Sin un diccionario, usted estaría perdido. Lo mismo puede ser dicho en relación al diccionario de datos en el análisis de sistemas: sin él, usted

Capítulo II. — El Modelo Comportamental 25 estará perdido, y el usuario no tendrá certeza de que usted haya entendido completamente los deta- lles de la aplicación. El diccionario de datos es una lista organizada de todos los elementos de datos pertinentes al sistema (todos los nombres de las componentes de los diagramas), con definiciones precisas y rigu- rosas para que el usuario y el analista de sistemas puedan conocer todas las entradas, salidas, com- ponentes de depósitos y cálculos intermedios. El diccionario de datos define los elementos de datos de la siguiente manera: P

P

P P

P Describiendo el significado de los flujos y depósitos mostrados en los diagramas de flujo de datos. Describiendo la composición de paquetes agregados de datos que se mueven por los flujos y que pueden ser divididos en ítems más elementales. Describiendo la composición de las estructuras de datos de los depósitos. Especificando los valores y unidades relevantes de partes elementales de información de los flujos de datos y depósitos de datos. Describiendo los detalles de las relaciones entre los depósitos de los diagramas de entidades y relaciones.

26 Capítulo III. — El Modelo Comportamental III Capítulo III. Herramientas de Análisis Estructurado Contenidos

Diagramas de Flujo de Datos 27 Flujos de Datos 28 Procesos 29 Depósitos de Datos 29 Agentes Externos 30 Refinamiento de Procesos en un DFD 30 Reglas de Validación 31 Álgebra de Descomposición de Procesos 32 Construcción Sistemática del DFD 36 Caso de Estudio – Administración Hotelera 36 Diccionario de Datos (DD) 44 Notación 44 Modelo Entidad Relación (ERD 45 Entidades y Atributos 46 Relaciones 47 Relación Uno-a-Uno 48 Relación Uno-a-Muchos 49 Relación Muchos-a-Muchos………..50 Relaciones Indefinidas50 Mecanismos de Abstracción 51 Clasificación51 Agregación de Atributos (atributos compuestos).51 Especialización (es-un o es-subtipo-de51 Agregación de Entidades (compuesto-por) 51 Entidades Relacionantes52 Construcción de un Diagrama Entidad-Relación 52 Especificación de Procesos 53 Lenguaje Estructurado 53 Pre/Pos Condiciones 54 Tabla de Decisión 56 Árboles de Decisión 56 Diagramas de Nassi-Shneiderman 57 Diagramas de Transición de Estados (DTE) 58 Estados 58 Transiciones 59 Representación en Tabla de Transición 59 Representación en Diagramas de Grade 60

Capítulo III. — Diagramas de Flujo de Datos 27 III.1. Diagramas de Flujo de Datos

Los diagramas de flujo de datos (DFD) son utilizados para modelar la funcionalidad de un sis- tema. Tal como es descripto por DeMarco [DeMarco 79] y Gane & Sarson [Gane 79], un DFD permite representar un sistema como una red de procesos de transformación de datos que intercam- bian información por medio de flujos de datos. Un proceso en un DFD puede representar funcionalidad en distintos niveles de abstracción, desde unidades funcionales de una organización (por ejemplo: departamento de recursos humanos, sección de ventas, etc.) hasta expresiones simples (por ejemplo: cálculo de la taza nominal anual de un préstamo). La Fig. III-1 presenta un ejemplo no necesariamente completo, pero que ilustra las distintas componentes de un DFD. El diagrama de flujo de datos describe cómo los datos fluyen a través del sistema, pero no proveen información acerca de estructuras de control o de secuencias de ejecución. La única se- cuencia que puede ser reconocida en un DFD es la determinada por la necesidad de información: el proceso Generar Pedido del Cliente puede completar su funcionalidad sólo en el caso que los flujos de datos Datos del Cliente Validados, Información de Embarque e Información de las Tarifas estén disponibles (fig.1). Por otra parte, los procesos Validar Cliente y Validar Existencia no tienen un orden definido de ejecución relativo entre ellos, puesto que ninguno de ellos recibe flujos de salida del otro proceso. Podemos considerar al diagrama de flujo de datos como un lenguaje gráfico, útil para descri- bir la funcionalidad de un sistema, en un cierto grado de detalle. La sintaxis de dicho lenguaje com- prende los siguientes símbolos: P Flujos de Datos: Información pasada de una componente a otra. Son representados por fle- Validar Cliente Validar Existencia Informar Error Generar Pedido del Cliente Registrar Pedido Pendiente Cliente Mercaderias Pedido Datos del Cliente Clientes Nuevo Cliente Pedido Mercadería Mercadería no Disponible Mercadería Inválida Cliente Inválido Mensaje de Error Información de las Tarifas

Pedido del Cliente Pedidos Aceptados Información de Embarque

Tarifas de Pedido Datos del Cliente Validados Proceso Confirmación de Pedido

Agente Externo Pedido Pendiente

Pedidos Pendientes

Depósito de Datos Flujo de Datos

Datos de Fig. III-1: Ejemplo de DFD – “Procesar Pedido de Clientes” Cuando un pedido es ingresado, se consultan los datos del cliente y se valida su estado de cuenta. Luego, se verifica la existencia en stock de la mercadería pedida. Si hay existencia suficiente, se registra como Pedido Aceptado y se genera una confirmación del pedido. Si no hay existencia suficiente, el pedido se registra como pendiente. Si los datos ingresa- dos no son válidos, un mensaje de error es generado.

28 Capítulo III. — Diagramas de Flujo de Datos P

P

P chas rotuladas. Procesos: Porciones de funcionalidad del sistema. Son representados por burbujas o círculos con un nombre descriptivo de dicha funcionalidad. Depósitos de Datos: Representan un archivo, área de memoria compartida o cualquier meca- nismo de almacenamiento de datos. Son representados por dos líneas paralelas. Agentes Externos: Es una caja negra que genera flujos hacia el sistema o recibe respuestas de él. Representa alguna cosa o entidad externa que interactúa con el sistema.

III.1.1. Flujos de Datos

Los flujos de datos son representados por arcos o flechas rotuladas. La flecha apunta en la di- rección del flujo de la información, los datos fluyen en esa dirección. El nombre con el que se rotula el arco debe ser representativo de los datos contenidos en él. En algunos casos, cuando el nombre es obvio, puede ser omitido (por ejemplo: un flujo que entra o sale de un depósito de datos represen- tando un registro completo) pero, en general, esa práctica no es recomendable. Se han propuesto extensiones a la notación utilizada por DeMarco y Gane & Sarson [Ward 85, 86; Gane 79; Yourdon 89] algunas de ellas destinadas a hacer mas descriptivo el DFD, incorpo- rando información adicional por medio de convenciones de diseño de los flujos. En la tabla siguien- te se presenta un resumen de las notaciones mas utilizadas.

Flujos de Datos – Notaciones mas utilizadas Flujo Discreto Flujo Continuo

Flujo de Diálogo B A

A

Fa A F

F

Fb La información contenida en F solamente esta disponible para el proceso A, en un momento dado y con periodicidad discreta.

La información contenida en F esta disponible, para el proceso A, en forma continua en un intervalo de tiempo. Es utilizado para modelar can- tidades medibles (ej.: temperatura) en sistemas de tiempo real. El flujo de datos de diálogo es una simplificación, de dos flujos de datos relacionados (uno es consecuencia del otro). Flujo de Control

Activación

Suspensión A

A

A Un flujo con línea de trazos es utilizado para modelar la ocurrencia de un evento que precisa que se ejecute una acción del sistema. Este flujo no transporta datos. Un flujo de control que representa la necesidad de activación de un proce- so. Es utilizado en protocolos de sincronización entre procesos. Un flujo de control que representa la necesidad de desactivación o sus- pensión de un proceso. Es utilizado en protocolos de sincronización entre procesos. Flujo Temporal A Ct Un flujo de control que modela la ocurrencia de un evento temporal espe- cificado por la condición temporal Ct (ej.: fin del dia, etc.). Típicamente se rotulan con un nombre con el prefijo: “es hora de ” Fuente Múltiple

Destino Múltiple Conjunción

División A

X Y

A F

F

F

F A

A

X Y El flujo de datos F es provisto por una de dos fuentes. El proceso A preci- sa de los datos contenidos en el flujo pero no tiene mayor importancia la fuente. El flujo de datos F es generado por el proceso A y es enviado a dos desti- natarios diferentes (simultáneamente).

El flujo de datos F es la unión de los flujos X e Y generados por fuentes diferentes.

Dos subconjuntos diferentes del flujo de datos F (X e Y) son enviados hacia dos destinatarios diferentes.

Capítulo III. — Diagramas de Flujo de Datos 29 III.1.2. Procesos

Un proceso representa una componente funcional del sistema. Un proceso transforma, distri- buye o genera datos. Por ejemplo, los procesos pueden realizar operaciones aritméticas o lógicas sobre los datos que recibe para producir algún resultado. Los procesos en un DFD son representados por un círculo (en la notación de DeMarco) o como una caja con bordes redondeados (en la nota- ción de Gane & Sarson) con el nombre del proceso en su interior. Deben utilizarse nombres signifi- cativos, conteniendo por lo menos un verbo, para definir la operación desempeñada. A continuación se muestran ambas notaciones: 1.5 Validar Cliente Notación de DeMarco Notación de Gane & Sarson Referencia al proceso comúnmente un número compuesto representando niveles de refinamiento 1.5 Validar Cliente Respecto de los procesos, un DFD describe únicamente los nombres y los flujos de entrada y salida, sin aportar ninguna otra información sobre las actividades internas de los procesos. Para des- cribir con mayor detalle, y especificar la funcionalidad por la que es responsable el proceso, se utili- zan técnicas de especificación de procesos, que serán descriptas mas adelante. Ocasionalmente, un proceso tendrá por función la de controlar la ejecución de otros procesos del DFD, en lugar de tener por funcionalidad la de transformar datos. Esos procesos son denomina- dos procesos de control. Los procesos de control son representados por líneas de trazo en su con- torno. La Fig. III-2 muestra un ejemplo.

III.1.3. Depósitos de Datos

Un depósito de datos es incluido en un DFD para modelar la necesidad de almacenar datos. Un depósito de datos puede representar un archivo en el disco de la computadora o un área de me- moria global a los procesos. En la literatura es posible encontrar que este mismo concepto puede recibir otros nombres como por ejemplo: Archivo, Almacenamiento de Datos o Repositorio. Notación de DeMarco Cliente Notación de Gane & Sarson A1Cliente Las lecturas que se realizan a un depósito de datos son representadas por flujos de salida (del depósito), y las actualizaciones de información se representan por flujos de entrada (al depósito). Comúnmente, el nombre de un depósito de datos es un sustantivo y puede estar compuesto también Ct

Flujo Temporal Proceso A Proceso B Proceso de Control

Inactivación Controlar Ejecución de A y B

Flujo de Control

Fig. III-2

30 por adjetivos. Los verbos no son válidos como parte del nombre, puesto que los almacenamientos de datos en los DFDs representan una entidad estática, carente de funcionalidad o comportamiento alguno. La estructura de datos contenida en el archivo es documentada en un diccionario de datos, como se mostrará más adelante.

III.1.4. Agentes Externos

Un agente externo establece el origen o fuente de los datos utilizados por el sistema o el re- ceptor de los datos producidos por él. Notación de DeMarco

Departamento de Ventas Notación de Gane & Sarson

Departamento de Ventas Los agentes externos (también denominados entidades externas) no son parte del sistema. Son modelados como cajas negras que generan o reciben datos del sistema. Su funcionalidad y comuni- cación con otros agentes externos son irrelevantes, desde el punto de vista del sistema siendo des- arrollado. Un agente externo puede representar algún área funcional de una organización, o el cargo de un funcionario, una agencia del gobierno, un dispositivo generador de datos continuos u otro siste- ma que debe interactuar con el sistema modelado.

III.1.5. Refinamiento de Procesos en un DFD

Un DFD es una herramienta comúnmente utilizada para análisis top-down, es decir que per- mite realizar un análisis que va de lo general a lo particular del problema. Los DFDs son utilizados para modelar tanto vistas detalladas como de alto nivel de un sistema o programa [Yourdon 78]. La funcionalidad de un proceso puede llegar a ser tan compleja que para comprenderlo sea necesario detallar sus actividades de manera separada. Como ejemplo, consideremos un proceso representan- do el trabajo de toda un área funcional de una organización. En ese caso, el proceso complejo puede ser especificado con otro DFD mas detallado. Así, un árbol de DFDs puede ser desarrollado presen- tando diferentes niveles de abstracción en el modelado de un sistema. La Fig. III-3 presenta la especificación de un proceso utilizando otro DFD. El proceso P resul- ta muy complejo y debe ser refinado para obtener una mejor comprensión de su funcionalidad. El refinamiento de DFDs tiene una regla de validación cruzada para garantizar consistencia en el modelado de los procesos, en los diferentes niveles de abstracción: P A Fs1 Fs2 P1 P3 Ap Fs1 Nivel N+1 Nivel N x y z w Fa Fa P2 Fs2

Fig. III-3: Especificación del proceso P con un DFD más detallado (Refinamiento)

Capítulo III. — Diagramas de Flujo de Datos

Capítulo III. — Diagramas de Flujo de Datos 31 Depósitos Activos Da D f Dos depósitos de datos no pueden estar unidos por un flujo de datos sin un proceso que oficie de intermediario. Depósitos Mágicos Da f Debe existir al menos un flujo de entrada y un flujo de salida en todos los depósitos de datos. Depósitos Sumideros

Depósitos Externos

Agentes Vinculados x

y

Ag

Ag1 P

f

f z

D

Ag2 Los depósitos no pueden generar "mágicamente" ni ser "sumi- deros" de datos.

Un agente externo no puede comunicarse directamente con un depósito de datos. Las vinculaciones entre agentes externos no son relevantes para el sistema. Ellos son cajas negras. Procesos Mágicos Pm f En todos los procesos debe existir al menos un flujo de entrada, sin considerar flujos de lectura de depósitos de datos, y un flujo de salida. Procesos Sumideros Pm f Los procesos no pueden generar "mágicamente", ni ser "sumi- deros de", datos. registro de nuevo Cliente Datos de Cliente existente Verificar crédito del Cliente inválido Pedido Cliente

Datos del nuevo Cliente Datos del Cliente

Obtener datos del Cliente Datos del Cliente validados El depósito de datos “Cliente” se representa nuevamente en este nivel para destacar que es actualizado Nuevo Cliente Crear Cliente

Flujos de entrada y salida en el DFD inmediato superior

Fig. III-4: Refinamiento del proceso “Validar Cliente”

Los flujos de entrada y salida de un proceso deben ser preservados en el refina- miento. Es decir, todos los flujos de entrada y de salida de un proceso deben ser los mismos flujos de entrada y salida del DFD de nivel inmediatamente inferior, en el árbol de niveles generado por el proceso de refinamiento.

La Fig. III-4 presenta un ejemplo de refinamiento. Este ejemplo representa una vista más detallada del proceso Validar Cliente del DFD de Procesar Pedido de Clientes presentado en la Fig. III-1.

III.1.6. Reglas de Validación

El DFD es una herramienta de modelado muy simple de utilizar. La notación incluye sola- mente cuatro tipos de símbolos, lo que permite una buena y rápida comprensión de los modelos. Si bien las reglas de construcción son simples y flexibles, existen algunas combinaciones de símbolos inválidas, que constituyen errores estructurales.

Errores Estructurales

y c y 32 Además, deberán tenerse en cuenta reglas de balance en los flujos de entrada y de salida de procesos y depósitos, con el objetivo de mantener el modelo del sistema consistente y completo.

Balance de Entradas y Salidas Depósitos de Datos D z x

y Los flujos de entrada y salida de un depósito sólo pueden contener un subcon- junto de la estructura de datos almacenada en él. Así, observando el ejemplo de la izquierda, la estructura de datos de d debe ser tal que: ((x? y)? d)?(z ? d) En general, un principio a tener en cuenta en el diseño de la estructura de un depósito de datos y de los flujos de entrada y salida de este, es el de: “Todo lo que se ingresa en un depósito debe ser extraído en algún mo- mento, de lo contrario no tiene sentido almacenarlo. Y todo lo que se ex- trae de él debe haber sido ingresado antes, o no podría encontrarlo.” Procesos z x

y P Los flujos de salida de un proceso deben poder ser definidos como una función de los flujos de entrada: z = p(x, y)= f(p'(x),p''(y),?) en la especificación provista para el proceso p, debe resultar natural y simple de interpretar esa correspondencia (f), principalmente ? (que puede representar, por ej. , estados locales).

III.1.7. Álgebra de Descomposición de Procesos

Los procesos del DFD pueden ser refinados en otra red de procesos conectados por flujos de datos, constituyendo un DFD de menor nivel de abstracción. Esta forma de especificar un proceso, por medio de otro DFD completo se denomina refinamiento, descomposición o explosión. El pro- blema es definir cual es el criterio mas adecuado para hacer esto y, determinar hasta dónde bajar en la jerarquía de DFDs, es decir cuando parar de realizar explosiones. Una de las formas más sistemáticas de realizar el refinamiento de un proceso es el que propo- ne Mike Adler [Adler 88], con el Álgebra de Descomposición de Procesos. Se aplica un álgebra, definida por un conjunto de operadores, a cada uno de los procesos del DFD por separado. En los procesos que generan dudas con relación a su funcionalidad sirve como una guía para su descompo- sición, mientras que para los procesos que generan muy pocas dudas con relación a su funcionali- dad, puede ser utilizado como un método de validación. El álgebra es aplicada a un único proceso del DFD por vez, y precisa como entrada adicional

Tabla de Entradas vs. Salidas

a b c d e x y z 1 Proceso z z z (a y,z), (b x,y,z), (c x,y,z), (d y), (y z) y x x a b d e y z Fig. III-5: Ejemplo de argumentos del álgebra de descomposición de procesos

Capítulo III. — Diagramas de Flujo de Datos

a Capítulo III. — Diagramas de Flujo de Datos 33 una tabla relacionando cada salida del proceso con las entradas usadas para generarla. Se presenta un ejemplo en la Fig. III-5. La notación (a ?ß,?,K,?) será utilizada como alternativa frente a la tabla de entradas vs. sa- lidas, donde el símbolo " " debe ser interpretado como "es utilizado para generar". Así, en la tabla ejemplo, la expresión (a y,z) es interpretada como "a es utilizado para generar y y z". La relación "es utilizado para generar" puede ser representada gráficamente como se observa al pie de la figura , donde las flechas de entrada a una burbuja representan los flujos de entrada al proceso, y las flechas de salida de la burbuja representan los flujos generados utilizando los flujos de entrada. La burbuja representa un proceso generado (que será parte de la descomposición del proceso original). La transformación se realiza intentando aplicar en orden cada uno de los operadores indicados a continuación. Oper Antes Después Oper Antes Después 1 absorb (a a z )) z z , (b z l b (b (a a b z z )) local 4 subst subset (a a z) z x, z),(b x b z (a a z)) z x , (b x l b 2 collect (b (a a b z z)) local (a, b a b z ) z 5 subst weak (a a x z),(b x b z , y,z) z y l (a x,(b x b y,z)) z y 3 subst exact (a a x,z),(b x b z x,z) z x l (a a (b

b x, z)) z x 6 connect (a a z ), (b z b y) y (a a b y )) y z,(b z l Los operadores son aplicados para producir una expresión mínima. Cuando un término nuevo es generado, los operadores son re-aplicados a él. La expresión subrayada (burbuja llena en la re- presentación gráfica) representa los parámetros para la operación siguiente. El proceso de transformación del ejemplo de la Fig. III-5 es presentado a continuación. Oper Expresión Representación Gráfica 0 Expr Inicial (a y,z), (b x,y,z), (c x,y,z), (d y), (y z) a b y z y z x c y z x d y y z 1 subst exact (a y,z), (b (c x,y,z)), (d y), (y z) a b y z y z x d y y z l1 c 2 collect (a y,z), (b,c x,y,z), (d y), (y z) a y z b c y z x d y y z 3 subst subset (b,c x, (a y,z)), (d y), (y z) y z b c x

a d y y z l 1

34 Oper Expresión Representación Gráfica 4 connect (b, c x, (d y), (a y,z)), (y z) y z b c x

a y y z d l 2 l 1 5 subst subset (b, c x, (a z, (d y))), (y z) z x

a y

b c z

l 1 d l 2 y 6 connect (b,c x, (y z),(a z, (d y))) z b c x d l 2 y y z l 3 l 1 a 7 subst subset (b, c x, (a (y z), (d y))) a b c d z l 1 x l 2 y y ly 3 En este caso, la aplicación del álgebra de descomposición generó un DFD con cuatro procesos y tres nuevos flujos (l1, l2 y l3). La Fig. III-6 presenta un ejemplo más concreto de la aplicación del álgebra de descomposi- ción. El proceso Generar Pedido es parte de un DFD que modela la generación de facturas por la venta de mercaderías. La tabla siguiente detalla la aplicación del álgebra en el ejemplo de la figura Fig. III-6. Oper Expresión DFD 0 Expr Inicial (nom ic),(c p,qsn),(q p,qsn),(qs qsn) c q qsn qsn p p qs qsn nom ic 1 Subst exact (nom ic),(c (q p, qsn)), (qs qsn) c q qsn p l 1 nom ic qs qsn Tabla de Entradas vs. Salidas P11 Generar Pedido Cliente Mercaderías cantidad (q) nombre cliente (nom) código (c) cantStock (qs) pedido + IdCliente (p+ic) cantStock nueva (qsn) (nom ic), (c p,qsn), (q p,qsn), (qs qsn) q p qs nom ic c qsn qsn p qsn

Fig. III-6: Ejemplo de Argumentos del Álgebra de Descomposición de Procesos

Capítulo III. — Diagramas de Flujo de Datos

(q) 35 Oper Expresión DFD 2 collect (nom ic),(c, q qsn, p), (qs qsn) c q p qs qsn qsn nom ic 3 subst subset (nom ic), (c, q (qs qsn), p) q p qs qsn l 1 nom ic c P11.1 P11.3 Cliente nombre cliente (nom) La figura Fig. III-7 presenta el resultado de la aplicación del álgebra, una descomposición del proceso de la figura. Resta solamente determinar los nombres de los tres nuevos procesos y el nom- bre del nuevo flujo l1 que, en este caso son bastante evidentes. El proceso P11.1 podría llevar el nombre “Armar Pedido” y el proceso P11.2 “Actualizar Stock”, mientras que el flujo l1 podría lle- var el nombre “cantidad requerida”. El proceso P11.3 debe obtener un identificador de cliente a partir de un nombre, y podría lle- var por nombre “Obtener Identificador de Cliente”. Este proceso, probablemente deberá recuperar el identificador de un almacenamiento donde se codifican los clientes, por lo tanto habrá que agre- gar a nuestro DFD el almacenamiento y el flujo de lectura necesarios. El proceso “Armar Pedido” es factible que deba ser descompuesto en el caso que entendamos al flujo de salida “pedido” como un flujo compuesto por un número de pedido además de la canti- dad y código del artículo requeridos (esto puede determinarse con el diccionario de datos y el desti- no del flujo). En tal caso, dicho número de pedido debe ser generado, con seguridad teniendo en cuenta el último número de pedido existente. Esto presupone la existencia de un depósito de Pedi- dos, que habrá que agregar al DFD junto con el correspondiente flujo de lectura para obtener el úl- timo pedido pendiente. Además, se observa que el pedido es generado sin tener en cuenta la cantidad en existencia del artículo requerido, esto se debe a que no consideramos al flujo “qs” como necesario para gene- rar “p”. Esta hubiera sido una visión más realista del problema, y queda como ejercicio para el lec- tor intentar una nueva descomposición introduciendo esta dependencia. A priori, es razonable pen- sar que introducir esta dependencia hará que el proceso “Armar Pedido” sea aún más factible de ser descompuesto en otros sub-procesos (digamos Validar pedido, Obtener número de pedido y Armar pedido, siguiendo el orden de suposiciones expuesto). Por otra parte, el DFD de la Fig. III-6 preveía un flujo de salida compuesto por pedido e iden- tificador de cliente, que puede modelarse por medio de la conjunción de los flujos “p” e “ic”. Con frecuencia no será tan simple darles nombre a los nuevos procesos y flujos generados al aplicar el álgebra de descomposición. En ese caso, para darles un nombre adecuado es necesario analizar la narrativa que describe el problema, y aplicar sentido común para aportar claridad y evitar ambigüedad.

IdCliente (ic) pedido (p) l1 = código + cantidad código (c) cantidad cantStock nueva (qsn) Artículos P11.2

cantStock (qs) Fig. III-7: Resultado de la Aplicación del Álgebra de Descomposición

Capítulo III. — Diagramas de Flujo de Datos

III.1.8. Construcción Sistemática del DFD

Al desarrollar sistemas grandes y complejos, en general, no existen medios que guíen al ana- lista de sistemas en el diseño de un DFD. El Analista se sienta en su mesa, contemplando una hoja de papel, esperando por un momento de inspiración divina o saturándose de ideas que le son impo- sibles de expresar todas a la vez. Esta incertidumbre puede eliminarse intentando aplicar un método de construcción sistemático, asistido por herramientas complementarias que ayudan a desglosar el problema en partes y tratarlas una por vez en una manera organizada. A continuación se desarrollará un ejemplo concreto de construcción sistemática de DFDs. El método que aplicaremos es descripto de manera informal, a fin de presentar algunas otras herra- mientas que asisten en la construcción de un modelo funcional de un sistema, expresado en una jerarquía de DFDs. El método, así como los modelos, herramientas y criterios que apoyan las deci- siones que involucra, será descripto en mayor detalle en el contexto de la metodología de Análisis Estructurado Moderno. Al desarrollar un sistema, cualquiera fuere su tamaño, es necesario contar en primer término, con una narrativa textual y una declaración 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 continuación, se presenta una narrativa textual, y su correspondiente declaración de objeti- vos, referente al caso de estudio que abordaremos: el desarrollo de un sistema de información para la administración de un hotel.

III.1.8.1. Caso de Estudio – Administración Hotelera Un hotel acepta reservas de habitaciones y exige el pago de un adelanto del 50% de la tarifa (precio de la habitación * cant. de días). En la operación de reservas, un pasajero, consulta sobre sus necesidades de alojamiento. El recepcionista, para poder responder, arma un código según lo que el cliente demande. Con este código verifica la disponibilidad, y se la comunica al pasajero junto con el precio, o si no tiene lo requerido, pide alternativas. Al confirmar el pasajero su reserva, el em- pleado toma los datos personales y le da un número de reserva. Ante el pago de la reserva, se la registra junto con la fecha de pago y se envía un recibo a vuelta de correo. Este hotel tiene un concesionario en el servicio de bar y restaurante, cuyos comensales no ne- cesariamente están alojados. En el caso que sí lo estén, los vales firmados por los clientes son pro- cesados por la administración del hotel, que agregará el importe de esas consumiciones a la factura que emita cuando el pasajero se retire del hotel. Ante el pago de los clientes se confeccionan y en- tregan recibos. Una vez por semana la administración confecciona un informe para el concesionario del bar con el detalle de las consumiciones realizadas por los clientes, acompañado por el importe correspondiente. La gerencia, semanalmente recibe un informe de la facturación emitida. A pedido de la misma se confecciona un informe estadístico de ocupación de habitaciones.

III.1.8.1.1. Objetivos Funcionales P P P P P P P

36 Administración de Información sobre Reservas. Administración de Información sobre Pasajeros. Administración de tarifas y ocupación de habitaciones. Facturación en línea. Generación de Informe Semanal de Servicios. Generación de Informe Semanal de Facturación. Generación de Estadísticas de Ocupación de Habitaciones.

Capítulo III. — Diagramas de Flujo de Datos

Capítulo III. — Diagramas de Flujo de Datos 37 A partir de esta narrativa, se debe obtener una descripción de los hechos, que ocurren en el en- torno o ambiente en el que el sistema funcionará, y a los que el sistema debe dar una respuesta pre- planeada. Es decir, podemos ver al sistema como un agente que reacciona ante determinados estí- mulos que ocurren en su mundo exterior. Una vez conocido lo que estimula al sistema, nuestra tarea consistirá en planificar sus reacciones acorde con los objetivos. Utilizaremos, para describir y enumerar los hechos o eventos que estimulan al sistema y que hacen a este reaccionar, una herramienta denominada lista de eventos.

III.1.8.1.2. Construcción de la Lista de Eventos Para detectar los eventos se deben analizar todas las oraciones de la narrativa, analizando fun- damentalmente, los diferentes sustantivos que aparecen. A partir de ellos podremos reconocer suje- tos externos, es decir entidades que pueden generar estímulos al sistema, y otros objetos candidatos de los cuales el sistema mantenga información, es decir que constituirán su memoria esencial. En la mayoría de los casos, el medio más fácil para identificar los eventos relevantes para un sistema es visualizar al sistema en acción: implica examinar cada sujeto (entidad, agente) externo y preguntar cual es el efecto que sus acciones pueden tener en el sistema. Al extraer los eventos de la narrativa y construir la lista de eventos, es necesario tener en cuenta que un evento: P P P Ocurre en el ambiente del sistema (es generado por algún sujeto externo al sistema). Genera una respuesta, del sistema, preplaneada. Ocurre en un punto del tiempo. Los eventos detectados se redactan de la siguiente forma: < sujeto> < verbo> < objeto> Para los sujetos utilizaremos el artículo indefinido en forma singular (un, una).

III.1.8.1.3. Lista de Eventos construida para el Caso de Estudio 1. 2. 3. 4. 5. 6. 7. 8. 9. Un pasajero realiza un pedido de reserva Un pasajero acepta la reserva Un pasajero paga la reserva Un pasajero cancela la reserva Un pasajero se presenta para alojarse Un pasajero informa que se retira Un pasajero paga la factura El concesionario entrega factura por consumición Es hora de confeccionar el informe para el concesionario y pagar (C.t.: ha pasado una se- mana desde el último informe) 10. Es hora de confeccionar el informe de facturación para la Gerencia (C.t.: ha pasado una semana desde el último informe) 11. La Gerencia realiza un pedido de estadísticas de ocupación 12. La Gerencia envía nuevas tarifas para habitaciones Además de una descripción de los estímulos a los que el sistema responde, es necesaria tam- bién, una descripción de los límites que separan al sistema de su medio ambiente. Con esta descrip- ción tendremos una buena comprensión de los alcances que tiene el sistema. Utilizaremos para des- cribir esto, el Diagrama de Contexto. Este diagrama es un caso especial del diagrama de flujo de datos, en el cual una única burbuja representa al sistema entero. El nombre que se le da a dicha bur- buja (proceso) es normalmente, el nombre del sistema o una sigla patrón o modelo.

38 III.1.8.1.4. Construcción del Diagrama de Contexto La construcción del diagrama de contexto involucra los siguientes pasos: P P P

P

P Para cada sujeto de la lista de eventos se dibuja una entidad externa. Para cada evento, buscar un nombre para el paquete de datos que sirve de estímulo. Para cada evento dibujar un flujo de la entidad externa al sistema, colocándole el nombre y el número de evento que lo genera. Dibujar la respuesta del sistema a cada estímulo y colocarle el número de evento correspon- diente. (Si la respuesta es interna, es decir no sale del sistema, no se dibuja. Las externas se dibujan todas, y pueden ser más de una por evento). Por último, se debe controlar la falta de estímulos necesarios, observando otras respuestas en Pasajero Concesionario Sistema de Administración Hotel reserva disponible (1)

confirmación reserva (2)

número reserva (2)

datos ingreso (5)

número habitación (5) la narrativa. Otra herramienta utilizada para describir los estímulos y respuestas del sistema es la tabla de estímulo-respuesta, que generalmente se construye junto con el diagrama de contexto. Esta tabla asocia cada estímulo que se produce en el ambiente con las respuestas que el sistema produce, des- cribiendo además las respuestas internas o actividades que el sistema realiza ante cada evento.

III.1.8.1.5. Diagrama de Contexto y Tabla de Estímulo-Respuesta para el Caso de Estudio Hasta aquí lo que se ha logrado es comprender mejor el problema, es decir, el sistema que debemos desarrollar. Conocemos los eventos que lo estimulan (Lista de Eventos) y las respuestas que se generan por cada evento, como así también qué agentes externos están involucrados (Dia- grama de Contexto, Fig. III-8). También tenemos una idea, aunque poco precisa, de las actividades a desarrollar ante cada evento (respuestas internas en Tabla Estímulo-Respuesta). Los modelos construidos hasta aquí se denominan comúnmente, en su conjunto, Modelo Ambiental. Al final de la etapa de construcción del modelo ambiental también se dispone de una primera versión del Diccionario de Datos (DD) conteniendo, al menos, una descripción de cada uno de los flujos de datos del diagrama de contexto. El DD será omitido por simplicidad, y a los efectos de no saturar la exposición en desarrollo. La construcción del diccionario de datos será objeto de una sec- ción posterior.

pedido reserva (1) recibo reserva (3) pago reserva (3) recibo factura (7) pago factura (7)

cancelación reserva (4) factura (6) informe ocupación (11)

informe facturación (10) pedido informe ocupación (11) Gerente

nuevas tarifas (12) informe pago (9) 1 semana

1 semana de facturación para la gerencia (10)

factura consumición (8) Es hora de confeccionar informe al concesionario y pagar (9) Es hora de confeccionar informe aviso retiro (6)

Fig. III-8: Diagrama de Contexto del caso de estudio

Capítulo III. — Diagramas de Flujo de Datos

Capítulo III. — Diagramas de Flujo de Datos 39 A partir del modelo ambiental tendremos que descubrir y modelar la manera en que el sistema trata los diferentes eventos que recibe para generar las respuestas deseadas por los agentes externos y, también, se deben descubrir y modelar los depósitos persistentes que contendrán la información esencial a ser manejada por el sistema. Esto es, tendremos que modelar todo lo que acontece en el interior del único proceso del diagrama de Contexto, que representa al sistema. En este punto, podríamos aplicar un enfoque clásico de análisis estructurado para descompo- sición descendente o top-down [DeMarco 79; Gane 79]. Este enfoque propone la construcción de una jerarquía de DFDs, cada una representando un nivel de abstracción diferente. Se comienza con la construcción de un DFD de primer nivel (o nivel 0), que constituye la explosión del diagrama de contexto. Para la construcción del DFD de primer nivel, el analista (o el grupo de analistas) estudia el diagrama de contexto y crea un DFD (de nivel 0) sin una estrategia que lo asista. Utilizando su propio conocimiento del problema, o del tipo de aplicación, y su sentido común, divide al sistema en "Burbujas Importantes" (representando por ejemplo subsistemas). Estas burbujas importantes, o subsistemas principales, son particionadas a su vez en otras, representando un nuevo nivel de des- cripción acerca del detalle de las transformaciones que el sistema produce sobre los datos que reci- be. Este proceso de descomposición se aplica a cada burbuja en cada nivel, describiéndola con un nuevo DFD, hasta alcanzar una burbuja que denominaremos “atómica” y que no requiere de mayor descomposición, y cuyo funcionamiento pueda ser descripto por medio de una técnica de especifi- cación complementaria (estas se verán en detalle más adelante).

40 Capítulo III. — Diagramas de Flujo de Datos Aunque el enfoque clásico de descomposición descendente constituye el pilar fundamental en el que se apoya el análisis estructurado, en la práctica presenta varios problemas: parálisis e incerti- dumbre en el análisis, partición física arbitraria del sistema, etc. Estos problemas se deben funda- mentalmente a la falta de una estrategia robusta que conduzca la descomposición. Podríamos entonces, utilizar un enfoque más sistemático para hacer frente a los problemas mencionados, intentando explotar la burbuja del diagrama de contexto utilizando el álgebra de des- composición de procesos, descripta en la sección anterior. Utilizaremos sin embargo, otro enfoque, con el objeto de presentarlo quedando su descripción detallada para la sección que cubre la metodo- logía de Análisis Estructurado Moderno. El enfoque que utilizaremos aquí se denomina comúnmen- te Enfoque Medio, o como fuera llamado por McMenamim y Palmer, “de partición por eventos” [McMenam 84]. El enfoque de derivación del DFD por partición de eventos propone desarrollar un Diagrama de Flujo de Datos Preliminar y al nivel de detalle dado por los eventos en la lista de eventos, que describirá las transformaciones que el sistema produce sobre los datos como respuesta a los eventos. Este enfoque, suele denominarse Enfoque Medio debido a que no es una actividad puramente top- down ni tampoco es puramente bottom-up. Una vez que el DFD preliminar está listo, puede ser ne- cesario crear algunos niveles superiores (abstracción de funciones) y/o algunos niveles inferiores (descomposición de funciones). El DFD construido con este enfoque (DFD preliminar) presenta una burbuja por cada evento existente en la lista de eventos, y estas burbujas no se comunican directamente unas con otras, sino que la comunicación se da a través de depósitos de datos. Esto último se debe a que las burbujas o procesos del DFD preliminar representan funciones que generan las respuestas que el sistema da ante cada uno de los eventos, y los eventos que ocurren en el medio ambiente externo son, en gene- ral, asincrónicos. Es decir, no hay forma de garantizar que dos eventos ocurrirán en el mismo ins- tante, o con segundos de diferencia, o con algún otro intervalo específico de tiempo. Los eventos ocurren cuando tienen que ocurrir, por lo tanto, como la respuesta a un evento puede requerir de datos producidos por otro proceso atendiendo otro evento, la única manera de sincronizar los múlti- ples procesos interdependientes del DFD preliminar es mediante depósitos de datos.

III.1.8.1.6. Derivación del DFD preliminar por eventos Para cada evento: P P

P P

P Dibujar una burbuja que se ocupe de él. Ponerle un nombre acorde con la transformación que el sistema realiza con el estímulo y ob- servando la respuesta que debe dar. Añadir los flujos existentes en el Diagrama de Contexto, asociados al evento. Contestar para cada burbuja la pregunta: ¿Qué datos necesita para producir la respuesta? y agregar los flujos que se necesiten para aportar estos datos. 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 apoyándose en la narrativa, y en la tabla de es- tímulo-respuesta. A continuación se presenta el resultado de aplicar estos pasos a los eventos en nuestro caso de estudio. 1. Pasajero Informar Disponibilidad Un pasajero realiza un pedido de reserva pedido reserva reserva disponible reserva

habitación Reservas

Habitaciones

Capítulo III. — Diagramas de Flujo de Datos 41 2. Un pasajero acepta la reserva Reservas

Habitaciones Pasajeros Registrar Reserva confirmación reserva

número reserva reserva

habitación

nro. reserva Pasajero 3. Un pasajero paga la reserva Reservas Registrar Pago Reserva pago reserva recibo reserva pago reserva Pasajero 4. Un pasajero cancela la reserva Reservas Registrar Cancelación Reserva cancelación de reserva registrada cancelación de reserva Pasajero 5. Un pasajero se presenta para alojarse Reservas

Habitaciones

Pasajeros Servicios Registrar Alojamiento número habitación reserva habitación

datos ingreso Pasajero nro. habitación 6. Un pasajero informa que se retira Habitaciones Pasajeros Servicios Pasajero Facturar aviso retiro factura pasajero servicio liberación habitación 7. Un pasajero paga la factura Servicios Pasajero Registrar Pagos pago factura pago factura recibo factura

42 Capítulo III. — Diagramas de Flujo de Datos 8. Servicios Registrar Consumición El concesionario entrega factura por consumición

factura consumición factura consumición Concesionario 9. Servicios Pagar Concesionario servicio Es hora de confeccionar el informe para el concesionario y pagar (C.t.: ha pasado una semana desde el último informe)

Es hora de confeccionar informe para el concesionario y pagar

informe pago Concesionario 10. Servicios Confeccionar Informe de servicio Es hora de confeccionar el informe de facturación para la Gerencia (C.t.: ha pasado una sema- na desde el último informe) informe facturación Gerencia 11. Confeccionar Informe Estadístico de Ocupación habitación nro. habitación Facturación Es hora de confeccionar informe de facturación para Gerencia

La Gerencia realiza un pedido de estadísticas de ocupación pedido informe ocupación informe ocupación Habitaciones Gerencia 12. Servicios

La Gerencia envía nuevas tarifas para habitaciones Habitaciones Gerencia Registrar Nuevas tarifa nuevas tarifas Tarifas

Luego de desarrollar un diagrama por cada evento se deben conectar los diagramas en uno único, agregando los repositorios necesarios entre los datos que una burbuja produce y que otra consume. Conviene tener en cuenta en este paso, que toda información entrante a un proceso que no proviene del medio ambiente externo, debe provenir necesariamente de un almacenamiento. Por otra parte, toda información generada que no se emita directamente al medio ambiente, deberá al- macenarse. Este paso puede apoyarse también en la construcción de un modelo de datos (objeto de estudio de una sección posterior) y en los objetos candidatos a memoria esencial observados en la lista de eventos, para identificar los repositorios de datos. En el caso de estudio, los repositorios identificados son: Reservas, Habitaciones, Pasajeros, y Servicios. Por último, habrá que refinar el diagrama verificando que no tiene errores estructurales y co- rregir las fallas de comunicación (agregar o refinar eventos). La Fig. III-9 muestra el DFD preliminar completo de nuestro caso de estudio.

Gerencia Tarifas Pagar Concesionario Capítulo III. — Diagramas de Flujo de Datos 43 Confeccionar Informe Estadístico de Ocupación nro. habitación informe ocupación reserva disponible

confirmación reserva Registrar Reserva Informar Disponibilidad

habitación

reserva

habitación Registrar Pago Reserva

pago reserva reserva

Reservas Registrar Alojamiento datos ingreso número habitación número reserva reserva habitación

datos ingreso nro. reserva

Pasajeros pedido reserva

Pasajero * Registrar Pagos pago factura pago factura recibo factura Facturar aviso retiro factura pasajero

servicio habitación Habitaciones liberación habitación nro. habitación

Servicios Registrar Consumición factura consumición Concesionario servicio

factura consumición Es hora de confeccionar informe para el concesionario y pagar

informe pago Confeccionar Informe de Facturación servicio informe facturación Es hora de confeccionar informe de facturación para Gerencia pago reserva Registrar Cancelación Reserva cancelación de reserva registrada

tarifa recibo Pasajero * reserva cancelación de reserva nuevas tarifas Registrar Nuevas pedido informe ocupación Fig. III-9: DFD Preliminar – Administración Hotelera

Es necesario observar que el DFD resultante (DFD preliminar) se compone de un solo nivel con un proceso por cada uno de los eventos. Para un sistema mediano o grande (50 o más eventos), el DFD preliminar contendrá demasiados procesos y se presentará probablemente muy desnivelado, estando representados diferentes niveles de abstracción de manera simultánea. Para mejorar su comprensión, precisamos subdividirlo realizando abstracciones. Esto quiere decir que deseamos agrupar los procesos estrechamente relacionados en funciones de más alto nivel de abstracción, en un diagrama de más alto nivel. Se deben generar abstracciones para la obtención de un DFD de ni- vel 0 de complejidad adecuada, esto es, uno de no más de 7 ± 2 procesos. Este número no es arbitra- rio como tampoco debe ser rígido, y representa un límite para la comprensión humana, que han en- contrado expertos en ciencias de la comunicación. Una vez obtenido el DFD de nivel 0 se procede a realizar nivelaciones descendentes o explo- siones, las que se consideren adecuadas para lograr especificaciones adecuadas de las funciones del sistema. Es decir, posiblemente los procesos identificados en el DFD de nivel 0, resulten no ser pro- cesos atómicos o primitivos y requieran particiones descendentes en DFDs de nivel inferior, esto significa que dichos procesos pueden resultar demasiado complejos para ser descriptos adecuada- mente en una especificación de proceso de una página. Queda como ejercicio para el lector realizar abstracciones y explosiones adecuadas para lo- grar un modelo funcional completo del caso de estudio, compuesto por una jerarquía de DFDs. Además, sería interesante completar el sistema con la funcionalidad que considere faltante, agregando nuevos eventos, y determinar el impacto que producimos en nuestro análisis al incorpo- rar nuevos requerimientos funcionales. Como sugerencia, mínimamente debiera atenderse lo si- guiente: Todos los días acumular ocupación y servicios; y Registrar habitación fuera de servicio.

44 Capítulo III. — Diccionario de Datos (DD) III.2. Diccionario de Datos (DD)

El diccionario de datos es una herramienta fundamental en el modelado de sistemas. Las herramientas gráficas, como los diagramas de flujo de datos, los diagramas de estructura, los dia- gramas de transición de estados, etc., son de mucha importancia al modelar la estructura de los sis- temas (estructuras funcionales, estructuras de módulos, estructuras de comportamiento, etc.) y per- miten una interpretación general de las ideas modeladas pero, no son completos. Para contar con una especificación completa es preciso tener una descripción textual de los detalles que no pueden ser especificados en el diagrama. El diccionario de datos es una lista organizada de todos los elementos de datos que le son per- tinentes al sistema (todos los nombres de las componentes de los diagramas), con definiciones pre- cisas y rigurosas para que el usuario y el analista de sistemas puedan conocer todas las entradas, salidas, componentes de depósitos y estructuras intermedias existentes en el sistema. El diccionario de datos describe: P P

P P

P El significado de los flujos y depósitos presentes en los DFDs. La composición de los paquetes agregados de datos (paquetes compuestos o ítems compues- tos) que son transportados por los flujos de datos y que pueden ser divididos en ítems más elementales. La composición de las estructuras de datos en los depósitos. Los valores y unidades relevantes de los ítems elementales de información de los flujos de datos y depósitos de datos. Los detalles de las relaciones entre los depósitos de datos. III.2.1. Notación

Existen muchas propuestas para la notación a ser utilizada en el diccionario de datos. La que se presenta a continuación es una de las más comunes, que utiliza un conjunto reducido y simple de símbolos:

Capítulo III. — Modelo Entidad Relación (ERD) 45 Ejemplos

CLIENTE cliente nro_cliente

crédito nombre_cliente

título_de_cortesía primer_nombre nombre_intermedio apellido carácter_válido dígito letra := { cliente } * el archivo de Clientes * := @nro_cliente