Herramientas de Anlisis Estructurado

Diagramas de Flujo de Datos

Los diagramas de flujo de datos (DFD) son utilizados para modelar la funcionalidad de un sistema. 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 transformacin de datos que intercambian informacin por medio de flujos de datos. Un proceso en un DFD puede representar funcionalidad en distintos niveles de abstraccin, desde unidades funcionales de una organizacin (por ejemplo: departamento de recursos humanos, seccin de ventas, etc.) hasta expresiones simples (por ejemplo: clculo de la taza nominal anual de un prstamo). La figura 1 presenta un ejemplo no necesariamente completo, pero que ilustra las distintas componentes de un DFD.
Proceso Datos del Cliente Validar Cliente Clientes Nuevo Cliente Datos de Mercaderia Flujo de Datos

Mercaderias

Pedido

Pedido Mercaderia Invlida Validar Existencia Informacin de Embarque Tarifas de Pedido Informacin de las Tarifas Generar Pedido del Cliente Pedido del Cliente Pedidos Aceptados Registrar Pedido Pendiente Pedido Pendiente Pedidos Pendientes Depsito de Datos Mercaderia no Disponble

Cliente Invlido Cliente Mensaje de Error Informar Error

Datos del Cliente Validados

Confirmacin de Pedido Agente Externo

Fig1.: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 mercaderia pedida. Si hay existencia suficiente, se registra como Pedido Aceptado y se genera una confirmacin del pedido. Si no hay existencia suficiente, el pedido se registra como pendiente. Si los datos ingresados no son vlidos, un mensaje de error es generado.

El diagrama de flujo de datos describe cmo los datos fluyen a travs del sistema, pero no proveen informacin acerca de estruturas de control o de secuencias de ejecucin. La nica secuencia que puede ser reconocida en un DFD es la determinada por la necesidad de

informacin: el proceso Generar Pedido del Cliente puede completar su funcionalidad slo en el caso que los flujos de datos Datos del Cliente Validados, Informacin de Embarque e Informacin de las Tarifas estn disponibles (fig.1). Por otra parte, los procesos Validar Cliente y Validar Existencia no tienen un orden definido de ejecucin 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 grfico, til para describir la funcionalidad de un sistema, en un cierto grado de detalle. La sintaxis de dicho lenguaje comprende los siguientes smbolos: Flujos de Datos: Informacin pasada de una componente a otra. Son representados por flechas rotuladas. Procesos: Porciones de funcionalidad del sistema. Son representados por burbujas o crculos con un nombre descriptivo de dicha funcionalidad. Depsitos de Datos: Representan un archivo, rea de memria compartida o cualquier mecanismo de almacenamiento de datos. Son representados por dos lneas 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 interactua con el sistema.

Flujos de Datos
Los flujos de datos son representados por arcos o flechas rotuladas. La flecha apunta en la direccin del flujo de la informacin, los datos fluyen en esa direccin. 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 depsito de datos representando un registro completo) pero, en general, esa prctica no es recomendable. Se han propuesto extensiones a la notacin utilizada por DeMarco y Gane & Sarson [Ward 85, 86; Gane 79; Yourdon 89] algunas de ellas destinadas a hacer mas descriptivo el DFD, incorporando informacin adicional por medio de convenciones de diseo de los flujos. En la tabla siguiente se presenta un resumen de las notaciones mas utilizadas. Flujos de Datos - Notaciones mas utilizadas Flujo Discreto Flujo Contnuo Flujo de Dilogo
A

F F

A A
Fa B

La informacin contenida en F solamente esta disponible para el proceso A, en un momento dado y con periodicidad discreta. La informacin contenida en F esta disponible, para el proceso A, en forma continua en un intervalo de tiempo. Es utilizado para modelar cantidades medibles (ej.: temperatura) en sistemas de tiempo real. El flujo de datos de dilogo es una simplificacin, de dos flujos de datos relacionados (uno es consecuencia del otro).

Fb

Flujo de Control Activaci n Suspensi n Flujo Temporal Fuente Mltiple Destino Mltiple Conjunci n Divisin
A

A A A

Un flujo con lnea de trazos es utilizado para modelar la ocurrencia de un evento que precisa que se ejecute una accin del sistema. Este flujo no transporta datos. Un flujo de control que representa la necesidad de activacin de un proceso. Es utilizado en protocolos de sincronizacin entre procesos. Un flujo de control que representa la necesidad de desactivacin o suspensin de un proceso. Es utilizado en protocolos de sincronizacin entre procesos. Un flujo de control que modela la ocurrencia de un evento temporal especificado por la condicin temporal Ct (ej.: fin del dia, etc.). Tpicamente se rotulan con un nombre con el prefijo: es hora de El flujo de datos F es provisto por una de dos fuentes. El proceso A precisa 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 destinatarios diferentes (simultaneamente). El flujo de datos F es la unin 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.

Ct

A
F

X Y
A F

A
X Y

Procesos
Un proceso representa una componente funcional del sistema. Un proceso transforma, distribuye o genera datos. Por ejemplo, los procesos pueden realizar operaciones aritmticas o lgicas sobre los datos que recibe para producir algn resultado. Los procesos en un DFD son representados por un crculo (en la notacin de DeMarco) o como una caja con bordes redondeados (en la notacin de Gane & Sarson) con el nombre del proceso en su interior. Deben utilizarse nombres significativos, conteniendo por lo menos un verbo, para definir la operacin desempeada.
Notacin de DeMarco
1.5

Notacin de Gane & Sarson Referencia al proceso comunmente un nmero compuesto representando niveles de refinamiento
1.5

Validar Cliente

Validar Cliente

Respecto de los procesos, un DFD describe nicamente los nombres y los flujos de entrada y salida, sin aportar ninguna otra informacin sobre las actividades internas de los procesos. Para describir con mayor detalle, y especificar la funcionalidad por la que es responsable el proceso, se utilizan tcnicas de especificacin de procesos, que sern descriptas mas adelante. Proceso
Ct de Control Controlar Ejecuin de A y B
3

Flujo Temporal

Proceso A

Inactivacin

Flujo de Control

Proceso B

Ocacionalmente, un proceso tendr por funcin la de controlar la ejecucin de otros procesos del DFD, en lugar de tener por funcionalidad la de transformar datos. Esos procesos son denominados procesos de control. Los procesos de control son representados por lneas de trazo en su contorno.

Depsitos de Datos
Un depsito de datos es incluido en un DFD para modelar la necesidad de almacenar datos. Un depsito de datos puede representar un archivo en el disco de la computadora o un rea de memria 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.
Notacin de DeMarco Cliente Notacin de Gane & Sarson
A1

Cliente

Las lecturas que se realizan a un depsito de datos son representadas por flujos de salida (del depsito), y las actualizaciones de informacin se representan por flujos de entrada (al depsito). Comunmente, el nombre de un depsito de datos es un sustantivo y puede estar compuesto tambin por adjetivos. Los verbos no son vlidos como parte del nombre, puesto que los almacenamientos de datos en los DFDs representan una entidad esttica, carente de funcionalidad o comportamiento alguno. La estructura de datos contenida en el archivo es documentada en un diccionrio de datos, como se mostrar ms adelante.

Agentes Externos
Un agente externo establece el origen o fuente de los datos utilizados por el sistema o el receptor de los datos producidos por l. Los agentesNotacin de DeMarco externos Notacin de Gane & Sarson (tambin denominados Departamento Departamento de Ventas entidades externas) de Ventas no son parte del sistema. Son modelados como cajas negras que generan o reciben datos del sistema. Su funcionalidad y comunicacin con otros agentes externos son irrelevantes, desde el punto de vista del sistema siendo desarrollado. Un agente externo puede representar algn rea funcional de una organizacin, o el cargo de un funcionario, una agencia del gobierno, un dispositivo generador de datos contnuos u otro sistema que debe interactuar con el sistema modelado.

Refinamiento de Procesos en un DFD

Un DFD es una herramienta comunmente utilizada para anlisis top-down, es decir que permite realizar un anlisis 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 representando el trabajo de toda un rea funcional de una organizacin. En ese caso, el proceso complejo puede ser especificado con otro DFD mas detallado. As, un rbol de DFDs puede ser desarrollado presentando diferentes niveles de abstraccin en el modelado de un sistema. La figura , presenta la especificacin de un proceso utilizando otro DFD. El proceso P resulta muy complejo y debe ser refinado para obtener una mejor comprensin de su
A Fa P Fs1 Fs2 Nivel N

Fa

x y P2

Fig 2.: Especificacin del proceso P con un DFD mas detallado (Refinamiento) P1
z w P3 Fs2

Ap

Fs1

Nivel N + 1

funcionalidad. El refinamiento de DFDs tiene una regla de validacin cruzada para garantizar consistencia en el modelado de los procesos, en los diferentes niveles de abstraccin: Los flujos de entrada y salida de un proceso deben ser preservados en el refinamiento. 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 figura presenta un ejemplo de refinamiento. Este ejemplo representa una vista mas detallada del proceso Validar Cliente del DFD de Procesar Pedido de Clientes presentado en la figura .

Datos del Cliente Pedido Obtener d oatos del Cliente

Cliente Datos del Nuevo Cliente

El Depsito de datos "Cliente" se representa nuevamente en este este Nivel nvel para destacar que es actualizado Nuevo Cliente Crear Registro de nuevo Cliente

Cliente Invlido

Datos de Cliente Existente Verificar Crdito del Cliente

Flujos de Entrada y Salida en el DFD de nivel inmediato superior

Datos del Cliente Validados

Fig 3.: Refinamiento del proceso Validar Cliente

Reglas de Validacin
El DFD es una herramienta de modelado muy simple de utilizar. La notacin incluye solamente cuatro tipos de smbolos, lo que permite una buena y rpida comprensin de los modelos. Si bien las reglas de construccin son simples y flexibles, existen algunas combinaciones de smbolos invlidas, que constituyen errores estructurales. Errores Estructurales Depsitos Activos Depsitos Mgicos Depsitos Sumideros Depsitos Externos Agentes Vinculados Procesos Mgicos Procesos Sumideros
Da Dm Ds
Ag f
f Ag1 Ag2

f f f

Dos depsitos de datos no pueden estar unidos por un flujo de datos sin un proceso que oficie de intermediario. Debe existir al menos un flujo de entrada y un flujo de salida en todos los depsitos de datos. Los depsitos no pueden generar "mgicamente" ni ser "sumideros" de datos.

Un agente externo no puede comunicarse directamente con un depsito de datos. Las vinculaciones entre agentes externos no son relevantes para el sistema. Ellos son cajas negras. Debe existir, al menos un flujo de entrada1 y un flujo de salida en todos los procesos. Los procesos no pueden generar "mgicamente", ni ser "sumideros de", datos.

f Pm

f Ps

Adems, debern tenerse en cuenta reglas de balance en los flujos de entrada y de salida de procesos y depsitos, con el objetivo de mantener el modelo del sistema consistente y completo. Balance de Entradas y Salidas

1 Sin considerar flujos de lectura de depsitos de datos.

Depsitos de Datos

x d y

Procesos
y

z P

Los flujos de entrada y salida de un depsito slo pueden contener un subconjunto 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 diseo de la estructura de un depsito de datos y de los flujos de entrada y salida de este, es el de: Todo lo que se ingresa en un depsito debe ser extrado en algn momento, de lo contrario no tiene sentido almacenarlo. Y todo lo que se extrae de l debe haber sido ingresado antes, o no podra encontrarlo. Los flujos de salida de un proceso deben poder ser definidos como una funcin de los flujos de entrada: z = p(x, y) = f(p'(x), p''(y), ) en la especificacin provista para el proceso p, debe resultar natural y simple de interpretar esa correspondencia (f), principalmente (que puede representar, por ej. , estados locales).

Construccin Sistemtica del DFD

Al desarrollar sistemas grandes y complejos, en general, no existen medios que guien al analista de sistemas en el diseo de un DFD. El Analista se sienta en su mesa, contemplando una hoja de papel, esperando por un momento de inspiracin divina o saturandose de ideas que le son imposibles de expresar todas a la vez. Esta incertidumbre puede eliminarse intentando aplicar un mtodo de construccin sistemtico, asistido por herramientas complementarias que ayudan a desglosar el problema en partes y tratarlas una por vez en una manera organizada. A continuacin se desarrollar un ejemplo concreto de construccin sistemtica de DFDs. El mtodo que aplicaremos es descripto de manera informal, a fin de presentar algunas otras herramientas que asisten en la construccin de un modelo funcional de un sistema, expresado en una jerarqua de DFDs. El mtodo, as como los modelos, herramientas y criterios que apoyan las decisiones que involucra, ser descripto en mayor detalle en el contexto de la metodologa de Anlisis Estructurado Moderno. Al desarrollar un sistema, cualquiera fuere su tamao, es necesario contar en primer trmino, con una narrativa textual y una declaracin concisa de los objetivos del sistema (la funcionalidad que se requiere, es decir lo que se espera que el sistema haga), por supuesto validada con el usuario del sistema (las personas a las que l esta destinado). A continuacin, se presenta una narrativa textual, y su correspondiente declaracin de objetivos, referente al caso de estudio que abordaremos: el desarrollo de un sistema de informacin para la administracin de un hotel.

Caso de Estudio - Administracin Hotelera Un hotel acepta reservas de habitaciones y exige el pago de un adelanto del 50% de la tarifa (precio de la habitacin * cant. de das). En la operacin de reservas, un pasajero, consulta sobre sus necesidades de alojamiento. El recepcionista, para poder responder, arma un cdigo segn lo que el cliente demande. Con este cdigo 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 empleado toma los datos personales y le da un nmero de reserva. Ante el pago de la reserva, se la registra junto con la fecha de pago y se enva un recibo a vuelta de correo. Este hotel tiene un concesionario en el servicio de bar y restaurante, cuyos comensales no necesariamente estn alojados. En el caso que s lo estn, los vales firmados por los clientes son procesados por la administracin 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 entregan recibos. Una vez por semana la administracin confecciona un informe para el concesionario del bar con el detalle de las consumiciones realizadas por los clientes, acompaado por el importe correspondiente. La gerencia, semanalmente recibe un informe de la facturacin emitida. A pedido de la misma se confecciona un informe estadstico de ocupacin de habitaciones. Objetivos Funcionales:

Administracin de Informacin sobre Reservas. Administracin de Informacin sobre Pasajeros. Administracin de tarifas y ocupacin de habitaciones. Facturacin en lnea. Generacin de Informe Semanal de Servicios. Generacin de Informe Semanal de Facturacin. Generacin de Estadsticas de Ocupacin de Habitaciones.

A partir de esta narrativa, se debe obtener una descripcin de los hechos, que ocurren en el entorno o ambiente en el que el sistema funcionar, y a los que el sistema debe dar una respuesta preplaneada. Es decir, podemos ver al sistema como un agente que reacciona ante determinados estmulos 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.

Construccin de la Lista de Eventos Para detectar los eventos se deben analizar todas las oraciones de la narrativa, analizando fundamentalmente, los diferentes sustantivos que aparecen. A partir de ellos podremos reconocer sujetos externos, es decir entidades que pueden generar estmulos al sistema, y otros objetos candidatos de los cuales el sistema mantenga informacin, es decir que constituiran su memoria esencial. En la mayora de los casos, el medio ms facil para identificar los eventos relevantes para un sistema es visualizar al sistema en accin: 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:

Ocurre en el ambiente del sistema (es generado por algn 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 artculo indefinido en forma singular (un, una).

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 consumicin Es hora de confeccionar el informe para el concesionario y pagar (C.t.: ha pasado una semana desde el ltimo informe) 10. Es hora de confeccionar el informe de facturacin para la Gerencia (C.t.: ha pasado una semana desde el ltimo informe) 11. La Gerencia realiza un pedido de estadsticas de ocupacin 12. La Gerencia enva nuevas tarifas para habitaciones

Adems de una descripcin de los estmulos a los que el sistema responde, es necesaria tambin, una descripcin de los lmites que separan al sistema de su medio ambiente. Con esta descripcin tendremos una buena comprensin de los alcances que tiene el sistema. Utilizaremos para describir 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 burbuja (proceso) es normalmente, el nombre del sistema o una sigla patrn o modelo. Construccin del Diagrama de Contexto La construccin del diagrama de contexto involucra los siguientes pasos:

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 estmulo. Para cada evento dibujar un flujo de la entidad externa al sistema, colocndole el nombre y el nmero de evento que lo genera. Dibujar la respuesta del sistema a cada estmulo y colocarle el nmero de evento correspondiente. (Si la respuesta es interna, es decir no sale del sistema, no se dibuja. Las externas se dibujan todas, y pueden ser ms de una por evento). Por ltimo, se debe controlar la falta de estmulos necesarios, observando otras respuestas en la narrativa.

Otra herramienta utilizada para describir los estimulos y respuestas del sistema es la tabla de estmulo-respuesta, que generalmente se construye junto con el diagrama de contexto. Esta tabla asocia cada estmulo que se produce en el ambiente con las respuestas que el sistema produce, describiendo adems las respuestas internas o actividades que el sistema realiza ante cada evento. Diagrama de Contexto y Tabla de Estmulo-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 tambin qu agentes externos estn involucrados (Diagrama de Contexto, figura ). Tambin tenemos una idea, aunque poco precisa, de las actividades a desarrollar ante cada evento (respuestas internas en Tabla Estmulo-Respuesta). Los modelos construidos hasta aqu se denominan comnmente, en su conjunto, Modelo Ambiental. Al final de la etapa de contruccin del modelo ambiental tambin se dispone de una primera versin del Diccionario de Datos (DD) conteniendo, al menos, una descripcin 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 exposicin en desarrollo. La construccin del diccionario de datos ser objeto de una seccin posterior. 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, tambin, se deben descubrir y modelar los depsitos persistentes que contendrn la informacin esencial a ser manejada por el sistema. Esto es, tendremos que

10

modelar todo lo que acontece en el interior del nico proceso del diagrama de Contexto, que representa al sistema.
pedido reserva (1) informe ocupacin (11) reserva disponible (1) confirmacin reserva (2) informe facturacin (10) nmero reserva (2) datos ingreso (5) pedido informe ocupacin (11) Gerente

nmero habitacin (5) Sistema de Administracin Hotel nuevas tarifas (12) Es hora de confeccionar informe al concesionario y pagar (9) Es hora de confeccionar informe de facturacin para la gerencia (10) factura consumicin (8) 1 semana 1 semana

Pasajero

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

cancelacin reserva (4) Concesionario informe pago (9)

factura (6) aviso retiro (6)

En este punto, podramosDiagrama de Contexto del caso de estudio anlisis estructurado para Fig 7: aplicar un enfoque clsico de descomposicin descendente o top-down [DeMarco 79; Gane 79]. Este enfoque propone la construccin de una jerarqua de DFDs, cada una representando un nivel de abstraccin diferente. Se comienza con la construccin de un DFD de primer nivel (o nivel 0), que constituye la explosin del diagrama de contexto. Para la construccin 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 aplicacin, y su sentido comn, 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 descripcin acerca del detalle de las transformaciones que el sistema produce sobre los datos que recibe. Este proceso de descomposicin se aplica a cada burbuja en cada nivel, describindola con un nuevo DFD, hasta alcanzar una burbuja que denominaremos atmica y que no requiere de mayor descomposicin, y cuyo funcionamiento pueda ser descripto por medio de una tcnica de especificacin complementaria (estas se vern en detalle ms adelante).

11

Estmulos Respuestas Eve Entidad Estmulo Externa Entidad Interna nto Externa (Flujo de (Flujo de Externa (Actividades o Origen datos) datos) Destino Procesos que involucra) 1 Pasajero Pedido_Res Reserva_Dispo Pasajero Codificar las erva nible necesidades del pasajero Verificar disponibilidad Informar al pasajero precio y disponibilidad 2 Pasajero Confirmacin_ Nmero_Reserva Pasajero Registrar reserva Reserva Registrar pasajero 3 Pasajero Pago_Reserva Recibo_Reserva Pasajero Registrar pago reserva 4 Pasajero Cancelacin_ ------------------------- --------------- Registrar cancelacin Reserva reserva 5 Pasajero Datos_Ingreso Nmero_Habitaci Pasajero Completar datos n pasajero Asignarle habitacin Actualizar reservas Abrir cuenta y factura 6 Pasajero Aviso_Retiro Factura Pasajero Cerrar cuenta y factura 7 Pasajero Pago_Factura Recibo_Factura Pasajero Registrar pago Registrar consumiciones pagadas 8 Concesionario Factura_ ------------------------- ------------- Registrar consumicin consumiciones para cada pasajero 9 Evento Informe_Pago Concesionario Seleccionar Temporal consumiciones pagadas Emitir informe concesionario Pagar concesionario 10 Evento Informe_Facturaci Gerencia Confeccionar informe Temporal n semanal de facturacin 11 Gerencia Pedido_Inform Informe_Ocupaci Gerencia Confeccionar informe e_Ocupacin n semanal de ocupacin 12 Gerencia Nuevas_Tarifas Registrar nuevas tarifas Fig 8: Tabla Estimulo-Respuesta del caso de estudio

Aunque el enfoque clsico de descomposicin descendente constituye el pilar fundamental en el que se apoya el anlisis estructurado, en la prctica presenta varios problemas:

12

parlisis e incertidumbre en el anlisis, particin fsica arbitraria del sistema, etc. Estos problemas se deben fundamentalmente a la falta de una estrategia robusta que conduzca la descomposicin. Podramos entonces, utilizar un enfoque ms sistemtico para hacer frente a los problemas mencionados, intentando explotar la burbuja del diagrama de contexto utilizando el lgebra de descomposicin de procesos, descripta en la seccin anterior. Utilizaremos sin embargo, otro enfoque, con el objeto de presentarlo quedando su descripcin detallada para la seccin que cubre la metodologa de Anlisis Estructurado Moderno. El enfoque que utilizaremos aqu se denomina comnmente Enfoque Medio, o como fuera llamado por McMenamim y Palmer, de particin por eventos [McMenam 84]. El enfoque de derivacin del DFD por particin 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 necesario crear algunos niveles superiores (abstraccin de funciones) y/o algunos niveles inferiores (descomposicin 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 comunicacin se da a travs de depsitos 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 general, asincrnicos. Es decir, no hay forma de garantizar que dos eventos ocurrirn en el mismo instante, o con segundos de diferencia, o con algn otro intervalo especfico 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 mltiples procesos interdependientes del DFD preliminar es mediante depsitos de datos. Derivacin del DFD preliminar por eventos Para cada evento: Dibujar una burbuja que se ocupe de l. Ponerle un nombre acorde con la transformacin que el sistema realiza con el estmulo y observando la respuesta que debe dar. Aadir los flujos existentes en el Diagrama de Contexto, asociados al evento.

13

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 apoyndose en la narrativa, y en la tabla de estmulo-respuesta. A continuacin se presenta el resultado de aplicar estos pasos a los eventos en nuestro caso de estudio. 1. Un pasajero realiza un pedido de reserva

pedido reserva reserva disponible

Informar Disponibilidad habitacin

reserva

2. Un pasajero acepta la reserva

confirmar

nmero reserva

reserva Registrar Reserva habitacin

3. Un pasajero paga la reserva

recibo pago reserva Registrar Pago Reserva pago reserva

4. U n pasaj ero canc ela la reser va

cancelacin de reserva Registrar Cancelacin reserva

Cancelacin de reserva registrada

14

5. Un pasajero se presenta para alojarse

datos ingreso reserva nmero Registrar Alojamiento habitacin

datos

ingreso

6. Un pasajero informa que se retira

Lliberacin habitacin aviso retiro

factura Facturar

pasajero servicio

7. Un pasajero paga la factura

pago recibo Registrar Pagos pago

8. El concesionario entrega factura por consumicin

factura consumicin

Registrar Consumicin

factura consumicin

15

9. Es hora de confeccionar el informe para el concesionario y pagar (C.t.: ha pasado una semana desde el ltimo informe)

servicio Es hora de confeccionar informe De acturacin para gerencia Pagar Concesionario

informe de pago

10. Es hora de confeccionar el informe de facturacin para la Gerencia (C.t.: ha pasado una semana desde el ltimo informe)
informe de facturacin Confeccionar Informe de Facturacin es hora de confeccionar informe De facturacin para Gerencia

servicio

11. La Gerencia realiza un pedido de estadsticas de ocupacin

pedido de informe de ocupacin habitacin Confeccionar Informe Estadstico Ocupacin informe de ocupacin

nro.de habitacin

12. La Gerencia enva nuevas tarifas para habitaciones

nuevas tarifas Registrar

16
tarifa

Nuevas 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 informacin entrante a un proceso que no proviene del medio ambiente externo, debe provenir necesariamente de un almacenamiento. Por otra parte, toda informacin generada que no se emita directamente al medio ambiente, deber almacenarse. Este paso puede apoyarse tambin en la construccin de un modelo de datos (objeto de estudio de una seccin 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.

17

DFD Preliminar Administracin Hotelera

pago reserva recibo

pedido reserva reserva disponible

Registrar Pago Reserva

cancelacin de reserva Registrar Cancelacin de reserva

Informar Disponibilidad

reserva pago reserva

confirmar reserva nmero reserva

habitacin reserva reserva

nuevas tarifas

Reservas

Registrar Nuevas Tarifas

Registrar Reserva habitacin datos ingreso reserva tarifa

pedido de informe de ocupacin habitacin Confeccionar Informe Estadstico de Ocupacin informe de ocupacin

Habitacione s
lliberacin nro. reserva

nmero habitacin

Registrar Alojamiento

habitacin

nro. habitacin

Pasajeros
aviso retiro datos ingreso Confeccionar Informe de Facturacin es hora de confeccionar informe de facturacin para Gerencia informe de facturacin

nro. habitacin factura Facturar servicio servicio pago recibo Registrar Pagos pago Registrar Consumicin factura consumicin pasajero

Servicios

servicio

es hora de confeccionar informe para el concesionario y pagar Pagar Concesionario

informe de pago factura consumicin

Por ltimo, habr que refinar el diagrama verificando que no tiene errores estructurales y corregir las fallas de comunicacin (agregar o refinar eventos). 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 ms eventos), el DFD preliminar contendr demasiados procesos y se presentar probablemente muy desnivelado, estando representados diferentes niveles de abstraccin de manera simultnea. Para mejorar su comprensin, precisamos subdividirlo realizando abstracciones. Esto quiere decir que deseamos agrupar los procesos estrechamente relacionados en funciones de ms alto nivel de abstraccin, en un diagrama de ms alto nivel. Se deben generar abstracciones para la obtencin

18

de un DFD de nivel 0 de complejidad adecuada, esto es, uno de no ms de 7 2 procesos. Este nmero no es arbitrario como tampoco debe ser rgido, y representa un lmite para la comprensin humana, que han encontrado expertos en ciencias de la comunicacin. Una vez obtenido el DFD de nivel 0 se procede a realizar nivelaciones descendentes o explosiones, 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 procesos atmicos o primitivos y requieran particiones descendentes en DFDs de nivel inferior, esto significa que dichos procesos pueden resultar demasiado complejos para ser descriptos adecuadamente en una especificacin de proceso de una pgina. Queda como ejercicio para el lector realizar abstracciones y explosiones adecuadas para lograr un modelo funcional completo de nuestro caso de estudio, compuesto por una jerarqua de DFDs. Adems, sera interesante completar el sistema con la funcionalidad que considere faltante, agregando nuevos eventos, y determinar el impacto que producimos en nuestro anlisis al incorporar nuevos requerimientos funcionales. Como sugerencia, mnimamente debiera atenderse lo siguiente: Todos los das acumular ocupacin y servicios; y Registrar habitacin fuera de servicio.

19

Diccionario de Datos (DD)

El diccionario de datos es una herramienta fundamental en el modelado de sistemas. Las herramientas grficas, como los diagramas de flujo de datos, los diagramas de estructura, los diagramas de transicin de estados, etc., son de mucha importancia al modelar la estructura de los sistemas (estructuras funcionales, estructuras de mdulos, estructuras de comportamiento, etc.) y permiten una interpretacin general de las ideas modeladas pero, no son completos. Para contar con una especificacin completa es preciso tener una descripcin 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 pertinentes al sistema (todos los nombres de las componentes de los diagramas), con definiciones precisas y rigurosas para que el usuario y el analista de sistemas puedan conocer todas las entradas, salidas, componentes de depsitos y estructuras intermedias existentes en el sistema. El diccionario de datos describe: El significado de los flujos y depsitos presentes en los DFDs. La composicin de los paquetes agregados de datos (paquetes compuestos o tems compuestos) que son transportados por los flujos de datos y que pueden ser divididos en tems ms elementales. La composicin de las estructuras de datos en los depsitos. Los valores y unidades relevantes de los tems elementales de informacin de los flujos de datos y depsitos de datos. Los detalles de las relaciones entre los depsitos de datos.

Notacin
Existen muchas propuestas para la notacin a ser utilizada en el diccionario de datos. La que se presenta a continuacin es una de las ms comunes, que utiliza un conjunto reducido y simple de smbolos: Smbolo Se lee Ejemplo de la Interpretacin Sintaxis Se define por o El tem I est definido por la expresin Y := I := Y + () {} i{}s [|]
Se compone de Junto con o Y Opcional Repeticiones de o Iteraciones de o Secuencia de

I := A + B I := A + ( B ) I := { A } I := 1 { A } 10 I := [ A | B | C ]

El tem I est compuesto de A y B (la concatenacin de A con B) El tem I est compuesto de A y B , o de A slo (B es opcional) El tem I est compuesto de una secuencia de As (iteracin) El tem I est compuesto de una secuencia de As (mnimo 1 y mximo 10). El tem I est compuesto de A o B o C. Slo uno de ellos. (o exclusivo)

Uno O

entre"

20

** @

Comentario Campo Clave

* Texto * @A

El Texto entre asteriscos es un comentario El elemento A es uno de los campos clave de un depsito de datos.

Ejemplos
CLIENTE cliente nro_cliente crdito := { cliente } * el archivo de Clientes * := @nro_cliente + nombre_cliente + direccin_para_remito + crdito := * identificador interno de un cliente, campo clave del depsito CLIENTES * * [ 1 ... 999 ]* * un nmero entre 1 y 999 * := [Positivo | Negativo] := [ Sr. | Srta. | Sra. | Dr. | Prof. | Don | Doa] := 1{ caracter_vlido }30 := 1{ carcter_vlido }30 := [ letra | dgito | ' | - | ] := [0 | 1 | 2 | 3 | 4| 5| 6| 7| 8| 9] := [letra_en_mayscula | letra_en_minscula] * [A ... Z | a ... z]*

nombre_cliente := ttulo_de_cortesa + primer_nombre + (nombre-intermedio) + apellido ttulo_de_cortesa primer_nombre apellido carcter_vlido dgito letra

nombre_intermedio := 1{ caracter_vlido }30

direccin_para_remito := calle + nmero_dir + (departamento) + (localidad) *si la localidad no se detalla, la direccin es de Tandil* calle nmero_dir localidad pedido item_pedido := {carcter_valido} := {dgito} := [Tandil | Villa Cacique | Barker | Jurez | Lobera | Posadas] * localidades en las que se entregan pedidos * := nro_cliente + nombre_cliente + direccin_para_remito + 1 {item_pedido} 10 * un pedido puede contener hasta 10 items * := cdigo_artculo + nombre_artculo + cantidad

cdigo_artculo := 1 {dgito} 3 * identificador interno de un artculo, un nmero de hasta tres dgitos *

21

Modelo Entidad Relacin (ERD)

La construccin del modelo entidad relacin (ERD) es el paso previo a la creacin y uso de bases de datos en un desarrollo. El proceso de generacin de la base de datos comienza desde la etapa de anlisis y se va completando hasta llegar a la etapa de implementacin. El modelo entidad relacin es una herramienta que permite especificar la estructura esttica de la aplicacin, modela dnde se encontrarn y cul ser la estructura de los datos. Los datos deben estar bien organizados ya que si datos que se refieren a algn objeto especfico son almacenados en diferentes lugares la bsqueda de estos datos resulta muy difcil. Este modelo tiene los siguientes requisitos: Accesibilidad: Si los datos no son fciles de acceder es muy difcil que sean utilizados. Oportunidad: Los datos deben reflejar un pasado relativamente inmediato. Los datos que no reflejan la situacin presente con suficiente validez no tienen valor para tomar decisiones. Precisin: Cada valor almacenado debe estar dentro de un rango aceptable de precisin alrededor del valor real. Consistencia: Los datos deben representar fielmente la realidad. Disponibilidad: Un dato que se necesita pero que no puede ser accedido es un sntoma de mala organizacin.

El modelo entidad relacin permite describir la informacin involucrada en un sistema como un conjunto de entidades y las relaciones existentes entre ellas.
Nombre Sexo Fecha de Nacimento Salario Empleado N Trabaja en 1 Departamento
Fig. 9: Ejemplo simple de diagrama de Entidad Relacin

Ttulo Cdigo de Funcin

La figura 9 presenta un ejemplo de diagrama entidad relacin. En esta figura se pueden distinguir tres tipos de componentes diferentes: Entidades: Tambin llamado Tipo de Objetos o Clase de Objetos. Es diseada como una caja y representa un conjunto de objetos, llamados instancias, que tienen caractersticas comunes. Por ejemplo, en la figura 9 la entidad Empleado representa el conjunto de todos los empleados que trabajan en una organizacin.

22

Atributos: Los valos vinculados a una entidad son llamados atributos. Representan caractersticas comunes a todas las instancias de una entidad. Relaciones: Son diseadas como un rombo y representan la relacin entre algunas instancias de una entidad con instancias de otra. Por ejemplo, en la figura 9 la relacin Trabaja en indica que un empleado (instancia de una entidad Empleado) trabaja en un Departamento. La notacin 1 del lado del Departamento y N del lado del Empleado indica que la relacin es uno a muchos, 1:N, y es interpretado como: varios empleados trabajan en un departamento, o en un departamento trabajan varios empleados.

Entidades y Atributos
Una entidad representa la informacin que es necesario almacenar, pudiendo esa necesidad de informacin abarcar personas o cosas tangibles como un empleado, un cliente o materiales. Puede ser intangible como el ttulo de una funcin, una asociacin, un prstamo, una compra o un pedido de seguro. Una entidad tiene varios atributos que describen la informacin que se desea mantener: tamao, valor, cdigo, fecha de nacimiento, direccin. Generalmente, en el procesamiento de datos se almacena una coleccin de objetos semejantes tales como los empleados y se registra la misma informacin para cada uno de ellos. Comnmente, el programador mantiene un registro sobre cada instancia de una entidad, y un tem de dato relacionado a cada atributo en cada uno de los registros. Los registros similares son agrupados en archivos y pueden presentarse como una tabla de dos dimensiones como la siguiente.
Estructura del Registro (Atributos de la Entidad) Nmero de Empleado Nombre Sexo Fecha de Nacimiento Depto Cdigo de Funcin la Ttulo Salario

Ocurrencia de un registro

(Instancia de una entidad) Archivo lgico o relacin (Entidad) 044 172 044 090 172 ... 73 43 02 11 07 ... Contado Abogado r Escribano Consulto Ingeniero r ... 2.000 1.800 1.100 5.000 2.500 ...

53730 28719 53550 79632 15971 ...

Perez Jos Balanagan Jos Lawrence Rockefeller Mara Fred Horseradish Freda ...

M M F M F ...

10/03/3 5 10/10/1 9 09/09/3 01/11/3 2 2 25/02/6 3 ...

Identificador registro (entidad) del

Conjunto de valores de un atributo o tipo de item de datos

Algunos atributos son si identificadores de por otro registro (entidad)

Valores atributo s

En el cuadro hay un conjunto de tems de datos y es mostrado el valor de cada uno. Cada lnea contiene los valores de los atributos de una instancia en particular de la entidad. Cada

23

columna contiene un tipo especfico de tem de datos, relativo a un tipo de atributo dado. La columna de la izquierda contiene los tems de datos que identifican a la entidad. En este ejemplo, la entidad es un empleado y el atributo designado como identificador de las instancias es el nmero de empleado. En un modelo de entidad relacin bien definido, las entidades y las relaciones deben estar en tercera formal normal [Chen 76], sin embargo, frecuentemente las entidades no estn bien definidas e incluyen caractersticas de otras entidades.

Relaciones
Una relacin representa un conjunto de vnculos lgicos entre instancias de dos o ms entidades. Cada una de las relaciones en un diagrama entidad relacin tiene una semntica propia que es definida por el tipo de vnculo existente en el dominio del problema modelado. Desde un punto de vista matemtico puede ser definido como: Una relacin entre entidades simples es una lista ordenada de entidades y una entidad dada puede aparecer una o ms veces en la lista [Ullman 82]. Si en un diagrama entidad relacin hay una relacin R entre las entidades E1, E2, ..., En, representa un conjunto compuesto por las listas (e1, e2, ..., en), (e1',e2', ..., en') ...; donde las componentes ei, ei', ... son instancias diferentes de la entidad Ei. La cantidad de entidades que participan en una relacin es arbitraria, sin embargo, se recomienda la utilizacin de relaciones entre dos entidades, es decir, relaciones binarias. Una entidad dada puede participar en ms de una relacin. Se pueden clasificar las relaciones binarias en diferentes tipos como base en la cantidad de participantes de cada una de las entidades. En las siguientes secciones se definen los diferentes tipos de relaciones. Existen diferentes convenciones para la notacin grfica de las relaciones. En las secciones siguientes se utilizan las ms usadas: la notacin original de Chen [Chen 76] y la notacin utilizada por James Martin [Martin 81], denominada tambin diagrama de Bachmann. Relacin Uno-a-Uno Una lnea uniendo las entidades A y B representa una relacin uno-a-uno. La barra corta, ms interna, cruzando la lnea de la relacin (notacin de Martin) indica la obligatoriedad de la relacin, es decir, una ocurrencia de la entidad tiene que existir para que la relacin tenga sentido.

24

Notacin de Martin

Solo una instancias es permitida

Notacin de Chen 1 1

R
Obligatoriedad

La figura representa grficamente la siguiente regla: Cada ocurrencia de la entidad A esta relacionada a una y solo una ocurrencia de la entidad B. Cada ocurrencia de la entidad B esta relacionada a una y solo una ocurrencia de la entidad A.

Por lo tanto, una ocurrencia, ni ms ni menos, de la entidad A puede existir con una, ni ms ni menos, ocurrencia de la entidad B. Esta relacin es denominada relacin uno-a-uno obligatoria. Las ocurrencias de las entidades A o B no pueden existir independientemente, una depende de la otra para existir. Chen, no considera la interpretacin de la obligatoriedad en las relaciones. La notacin en la parte superior de la relacin es interpretada como la cantidad permitida de B depende de la existencia de la entidad A, se disea una flecha apuntando a la entidad B.
Notacin de Chen 1

Opcionalidad Un crculo sobre la lnea de la relacin de lado de la entidad B indica una relacin de opcionalidad. Mientras que la relacin de B a A es obligatoria, la relacin de A para B es opcional.
Notacin de Martin
Opcionalidad

Notacin de Chen 1 0,1

Esto es interpretado de la siguiente manera: Cada ocurrencia de la entidad A esta relacionada con cero o una ocurrencia de la entidad B. Cada ocurrencia de la entidad B (si existe) esta relacionada a una y solamente una ocurrencia de la entidad A.

Una entidad A puede existir sin la presencia de una entidad B. Mientras que si la entidad B existe, no puede haber mas que una ocurrencia de la entidad A relacionada. La entidad B no

25

puede existir sin la presencia de la entidad A. La figura siguiente presenta una relacin uno-auno opcional en los dos sentidos:
Notacin de Martin Notacin de Chen* 0, 1 0,1

Cada ocurrencia de la entidad A esta relacionada con cero o una ocurrencia de la entidad B. Cada ocurrencia de la entidad B esta relacionada con cero o una ocurrencia de la entidad A.

Tanto la ocurrencia de la entidad A como de la entidad B puede existir sin la presencia de la otra. Si la relacin existe, cada ocurrencia de A puede estar relacionada solamente a una ocurrencia de la entidad B y viceversa. Relacin uno-a-muchos Las relaciones con varias instancias de una entidad se representa por medio del signo menor. Los siguientes ejemplos utilizan este tipo de relacin:
Notacin de Martin Notacin de Chen* 1 1,n

Este ejemplo representa una relacin uno-a-muchos obligatoria, debido a que las barras cortas cruzan a la lnea de la relacin. Este diagrama es interpretado de la siguiente manera: Cada ocurrencia de la entidad A esta relacionada a una o varias ocurrencias de la entidad B. Cada ocurrencia de la entidad B esta relacionada a uno y solamente una ocurrencia de la entidad A.

Ninguna de las entidades A o B pueden existir sin la presencia de la otra. La relacin debe existir entre ocurrencias especficas de las entidades A y B. Una ocurrencia de la entidad A en particular puede estar relacionada a varias ocurrencias de la entidad B, debe haber por lo menos una ocurrencia de la entidad B. Por otro lado, una ocurrencia de la entidad B debe estar relacionada, siempre, a una y solo una ocurrencia de la entidad A. Opcionalidad La siguiente relacin indica una relacin uno-a-muchos opcional con B: Cada ocurrencia de la entidad A esta relacionada con cero, una o varias ocurrencias de la entidad B.

26

Cada ocurrencia de la entidad B, si existe, ser relacionada con una y solamente una ocurrencia de la entidad A.
Notacin de Martin Notacin de Chen 1 0,n

Siempre que existe una ocurrencia de la entidad B ella debe estar relacionada a una ocurrencia de la entidad A y no ms ni menos que una. Si una ocurrencia en particular de la entidad A esta relacionada a cero ocurrencias de la entidad B, la relacin no existe para esa ocurrencia de la entidad A. Por otro lado, si la relacin existe, ella puede ser con una o varias ocurrencias de la entidad B.
Notacin de Martin Notacin de Chen* 0,1 0,n

La relacin anterior indica una relacin uno-a-muchos opcional entre A y B: Cada ocurrencia de la entidad A esta relacionada con cero, una o varias ocurrencias de la entidad B. Cada ocurrencia de la entidad B esta relacionada con cero o una ocurrencia de la entidad A.

Las entidades A o B no necesitan existir. Si existen, deben estar relacionadas. Si existe una relacin entre ellas, una ocurrencia especfica de la entidad A puede estar relacionada con cero, una o varias ocurrencias de la entidad B. Cada una de las ocurrencias de la entidad B pueden estar relacionadas a solamente una ocurrencia de la entidad A. Por lo tanto, las ocurrencias de la entidad B relacionadas a una ocurrencia de la entidad A no pueden estar relacionadas a ninguna otra ocurrencia de la entidad A. Relacin muchos-a-muchos Dos relaciones uno-a-muchos para ambos lados pueden existir entre entidades, ellas se convierten en una sola relacin muchos-a-muchos y es representada de la siguiente manera:
Notacin de Martin Notacin de Chen* 1,n 1,m

Cada ocurrencia de la entidad A esta relacionada con una o varias ocurrencias de la entidad B. Cada ocurrencia de la entidad B esta relacionada con una o varias ocurrencias de la entidad A.

27

Opcionalidad
Notacin de Martin Notacin de Chen* 1,n 0,m

Cada ocurrencia de la entidad A esta relacionada con cero, una o varias ocurrencias de la entidad B. Cada ocurrencia de la entidad B, si existe, esta relacionada con una o varias ocurrencias de la entidad A.
Notacin de Martin Notacin de Chen* 0,n 0,m

Cada ocurrencia de la entidad A, si existe, esta relacionada con cero, una o varias ocurrencias de la entidad B. Cada ocurrencia de la entidad B, si existe, esta relacionada con cero, una o varias ocurrencias de la entidad A.

Relaciones Indefinidas Se ha descripto cmo se representan grficamente las relaciones uno-a-uno y uno-amuchos, obligatoria y opcional. Sin embargo, cuando se esta desarrollando un modelo entidad relacin puede suceder que no se conozca el tipo de relacin existente y que el tipo de relacin no este hasta el momento definida. En estos casos la relacin es descripta de la siguiente manera:
Notacin de Martin Notacin de Chen

Mecanismos de Abstraccin
En la construccin de diagramas entidad relacin existen mecanismos que permiten modelar diversos tipos de abstraccin, muy tiles en la organizacin conceptual de los modelos de datos. Clasificacin El mecanismo de clasificacin fue introducido intuitivamente, puesto que los tres conceptos bsicos en los que se basan los diagramas entidad relacin fueron desarrollados como una aplicacin de abstracciones de clasificacin: Entidad: Una entidad es una clasificacin que representa un conjunto de objetos con caractersticas comunes.

28

Atributos: Un atributo es una clasificacin que representa un conjunto de valores de una propiedad atmica de una entidad o una relacin. Relacin: Una relacin es una clasificacin que representa el conjunto de vnculos entre objetos integrantes del mismo conjunto de entidades.

Agregacin de Atributos (atributos compuestos) Un atributo de una entidad o relacin puede ser una estructura compuesta de tems que se desean identificar. La figura siguiente presenta una entidad Cliente que tiene un atributo compuesto Direccin.
Calle Cliente Direccin Provincia Nmero Ciudad CP

Especializacin (es-un o es-subtipo-de) La relacin es-un o es-subtipo-de es una relacin muy comn en una clasificacin de entidades. Es til si existen entidades con la mayora de la caractersticas comunes, pero con algunas caractersticas diferentes. La figura siguiente presenta un ejemplo.
Notacin de Martin Nombre Edad Alumno Notacin de Chen* Nombre Edad Alumno

Alumno de Grado

Alumno de Pos-Grado

Alumno de Grado

Alumno de Pos-Grado

Una especializacin tambin puede ser til si solamente un sub-conjunto de ocurrencias de las entidades, a ser relacionadas, participan en la relacin. Agregacin de Entidades (compuesto-por) La relacin compuesto-por es una relacin que permite describir composicin, por ejemplo la composicin de una factura como se describe en el siguiente ejemplo.

29

Notacin de Martin Factura

Notacin de Chen* Factura 1 Comp por 1 1,n Linea 1 Totales

Encabezado

Linea

Totales

Encabezado

Entidades Relacionantes Existen situaciones en las cuales una relacin se convierte en una entidad. Por ejemplo, si una relacin tiene atributos asociados a ella, es una entidad sin perder su propiedad de vinculo entre entidades. La figura siguiente muestra un ejemplo.
Notacin de Martin Matricula Notacin de Chen* Matricula

Alumno

Disciplina

Alumno

1,n

1,n

Disciplina

Note que, la notacin de Martin no hace diferencia entre los dos tipos de entidades. Sin embargo, en la notacin de Chen la relacin convertida en entidad es notoriamente identificable.

Construccin de un Diagrama Entidad-Relacin

Existe un conjunto de pasos los cuales guian el proceso de contruccin de un modelo entidad relacin, a partir de una lista de eventos, los cuales son descriptos a continuacin: 1.- Para cada evento construir una relacin a.) El sujeto del evento es una de las entidades de la relacin. b.) El predicado del evento es la otra entidad de la relacin. c.) El verbo del evento es el nombre de la relacin.
Cliente Factura

paga

2.- Eliminar las entidades que no posean datos que identifiquen instancias diferentes.
Instancia nica BCRA Balance

recibe

30

3.- Identificar relaciones que puedan servir como entidades asociativas

Cliente pide Articulo

Cliente

Articulo

Pedido

4.- Construir el modelo resultante. 5.- Identificar entidades demasiado generales o grupos de entidades demasiado particulares y construir relaciones de especializacin. 6.- Identificar relaciones de composicin. 7.- Identificar entidades poco significativas: 8.- Completar el modelo de datos. Para cada entidad, cada relacin y cada entidad asociativa, completar la correspondiente entrada en el diccionario de datos.

31