P. 1
Diagramas de Flujos de Datos

Diagramas de Flujos de Datos

|Views: 3.199|Likes:
Publicado porMaria Fernanda
dfd
dfd

More info:

Published by: Maria Fernanda on Feb 13, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

08/02/2013

pdf

text

original

Diagramas de Flujos de Datos

Como sabemos, la información se transforma a medida que fluye por un sistema basado en computadora. Un sistema acepta entradas en una gran variedad de formas, aplica elementos de hardware, de software y humanos para transformar la entrada en salida, produciendo salidas en una gran variedad de formas. Podemos, de forma efectiva, construir un modelo del flujo de la información para cualquier sistema de computadora, independientemente del tamaño y la complejidad del mismo. Para ello contamos con una herramienta gráfica muy simple: el Diagrama de Flujos de Datos (DFD). Los DFDs son una notación operacional semi-formal que ha sido ampliamente adoptada para la especificación de sistemas de información. Son una de las herramientas gráficas más importantes del Análisis Estructurado [3]. Un Diagrama de Flujos de Datos permite visualizar un sistema como una red de procesos funcionales. En la literatura computacional, es común referirse a éstos también como Diagrama de burbujas, Modelo de procesos o Modelo de función. Un tratamiento en profundidad del tema puede encontrarse en el capítulo 9 en [3]. En el capítulo 12 en [4], en el capítulo 5 de [5] y en capítulo 6 de [6], entre otros, puede también encontrarse información relacionada. Los DFDs no sólo se usan para modelar sistemas de información, sino también para modelar organizaciones enteras, es decir, como una herramienta para el planeamiento estratégico y de negocios. Los DFDs sirven para mostrar sólo una visión o punto de vista de un sistema: el orientado a la funcionalidad. Sin embargo, si lo que estamos desarrollando es un sistema donde las relaciones entre los datos son más importantes que las operaciones que se llevan a cabo sobre éstos, probablemente al DFD se le dé menos importancia que al DER. Por otro lado, si lo que domina es el comportamiento dependiente del tiempo, tal vez nos concentremos más en los diagramas de transición de estado (DTE). Sin embargo, es importante destacar que las distintas visiones del sistema, que podamos obtener a partir de distintos modelos del mismo, no se contraponen entre sí sino que más bien se complementan. El DFD es una técnica que representa el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida. Usaremos una notación bastante común que es la misma que utilizan Yourdon [3], DeMarco [7] y otros.

1. Componentes de un DFD
Los DFDs se construyen a partir de la combinación de componentes de cuatro tipos: procesos, flujos, almacenes y terminadores o entidades externas.

1.1. El proceso
Un proceso también suele ser llamado burbuja, función, transformación. Se representa gráficamente como un círculo, como se ve, por ejemplo, en la figura 1.

VALIDAR USUARIO

Figura 1
Especificaciones de Software -–DFD, DD, DTE 1 Ingeniería de Software I

Nótese que un proceso se nombra con una sola palabra, frase u oración sencilla. Esta describirá qué es lo que el proceso hace. En general, consiste en una frase del tipo verbo-objeto tal como VALIDAR ENTRADA o CALCULAR IMPUESTO. En algunos casos, el proceso podrá contener el nombre de una persona o grupo (por ejemplo, departamento o división de una organización), o de una computadora, o de un aparato mecánico. Es decir, en ocasiones, el proceso describe quién o qué lo está efectuando, en lugar de describir el proceso mismo; pero este último es un caso muy particular que se aplica para la construcción de los modelos de procesadores. Por ahora, a cada proceso lo nombraremos usando la convención verbo-objeto. Un proceso transforma entradas en salidas. Las entradas y salidas a un proceso de un DFD son representadas por los flujos de datos.

1.2. El flujo de datos
Un flujo se usa para describir el movimiento de paquetes de datos de una parte del sistema a otra. Por esto, los paquetes representan datos en movimiento, mientras que los almacenes (que veremos en el próximo punto) representan datos en reposo. Un flujo de datos se representa gráficamente como una flecha que entra o sale de un proceso, almacén o terminador. Un ejemplo de un flujo de entrada y uno de salida hacia y desde un proceso se muestra en la figura 2. usario + contraseña respuesta de validación

VALIDAR USUARIO

Figura 2 Nótese que los flujos están etiquetados. Esta etiqueta representa el significado de lo que viaja por el flujo. Ya veremos cómo por medio del diccionario de datos se especifica sin ambigüedad cuáles son los datos que viajan por ese flujo. Los flujos tienen una dirección dada por una cabeza de flecha en cualquier extremo (o posiblemente en ambos). Los flujos de dos cabezas muestran un diálogo, es decir, un pedido y una respuesta en el mismo flujo. En este último caso, los paquetes de cada extremo de la flecha deben etiquetarse, como se muestra en la figura 3. Una alternativa al diálogo es el uso de dos flujos diferentes, uno que muestre las entradas (pregunta) y otro que muestre las salidas (respuesta).
pregunta sobre estado de pedido respuesta sobre estado de pedido
DETERMINAR ESTADO DEL PEDIDO

Figura 3 En la mayoría de los sistemas que modelemos, los flujos representarán datos, es decir, bits, caracteres, números en punto flotante, etc. Pero los DFDs también pueden usarse para modelizar otro tipo de sistemas aparte de los basados en computadoras; podrían, por ejemplo, utilizarse para modelar una línea de ensamblado en la que por los flujos viajen materiales físicos. La figura 4 muestra un ejemplo de un DFD con flujo de materiales, que modeliza el proceso de preparación de una torta.
Especificaciones de Software -–DFD, DD, DTE 2 Ingeniería de Software I

leche harina huevos manteca

azúcar

MEZCLAR INGREDIENTES

masa

HORNEAR

torta

Figura 4 Los flujos de datos en un DFD pueden ser divergentes o convergentes, es decir, un flujo se divide en varios flujos o varios flujos se unen para formar uno solo. Cuando el flujo es divergente, puede significar dos cosas: (a) se están creando copias del paquete de datos que son enviadas a diferentes partes del sistema; (b) es un paquete complejo que se está dividiendo en paquetes más pequeños, cada uno de los cuales se está enviando a distintas partes del sistema. Cuando el flujo es convergente, varios paquetes se están uniendo para formar un paquete complejo. En las figuras 5 y 6 se ven ejemplos de las dos posibles situaciones para los flujos divergentes. La figura 7 muestra un ejemplo de flujo convergente.
ACTUALI ZAR INVENTA RIO

pedido

SELECCIO NAR PEDIDOS VALIDOS

detalle de pedidos

Figura 5

GENERAR PEDIDO

VALIDAR CODIGO POSTAL

código postal domicilio numero teléfono

VALIDAR NUMERO TELEFONO

calle

VALIDAR CALLE

Figura 6

Especificaciones de Software -–DFD, DD, DTE

3

Ingeniería de Software I

OBTENER CODIGO POSTAL

código postal domicilio numero teléfono calle

OBTENER NUMERO TELEFONO

VALIDAR DOMICILIO

OBTENER CALLE

Figura 7

1.3. El almacén de datos
Un almacén muestra una colección de datos en reposo. Se lo representa por medio de dos líneas paralelas con un nombre entre medio. En general, dicho nombre está en plural. En la figura 8 se muestra un ejemplo. CLIENTES Figura 8 Un almacén puede corresponder a una tabla en una base de datos, a un archivo en disco, pero también a datos almacenados en otros medios como por ejemplo microfichas, microfilms, o inclusive a datos almacenados en papel en un cajón. Los almacenes se conectan a los procesos por medio de los flujos de datos. Los flujos pueden salir o entrar a los almacenes. En la mayoría de los casos, los flujos se etiquetan de la forma que vimos anteriormente. Sin embargo, algunos analistas optan como convención no etiquetarlos cuando éstos transportan una instancia completa desde o hacia un almacenamiento. Un flujo que sale de un almacén se interpreta como una lectura a información del almacén: ya sea que se recupere un paquete completo, varios paquetes (que podrían cumplir con una cierta condición) o una parte de un paquete o una porción de varios paquetes. Para saber cuál de ellas representa usamos el diccionario de datos. Estas lecturas son no destructivas, es decir, el almacén no cambia cuando un paquete se mueve desde el almacén a lo largo del flujo de salida. En los modelos que no son de procesos de información, esto podría no darse; por ejemplo, un almacén podría contener cosas físicas y el flujo representar un mecanismo para transportar materiales hacia un proceso. En estos casos, el DFD debe incluir algún tipo de anotación extra para que el lector no se confunda. Un flujo de entrada a un almacén se interpreta como una escritura en el almacén. Esto podría significar que se agregan o borran paquetes, se modifican paquetes o porciones de los mismos. En todos los casos es evidente que el almacén cambiará. El proceso en el otro extremo del flujo es el encargado de producir el cambio en el almacén. Desde luego que los flujos de entrada a un almacenamiento sólo pueden transportar paquetes que el almacén sea capaz de guardar. Una cosa a tener en cuenta es que los almacenes son pasivos, es decir, los datos no viajarán hacia un flujo o desde un flujo a menos que un proceso lo solicite.
Especificaciones de Software -–DFD, DD, DTE 4 Ingeniería de Software I

1.4. El terminador o entidad externa Los terminadores o entidades externas representan objetos con los cuales el sistema se comunica (no confundir con las entidades de un DER). Estos producen información para ser transformada por el software o reciben información producida por el software. Un terminador puede ser una persona, una compañía, un departamento que se encuentran fuera del sistema que se está modelando. También puede ser otro sistema de software o de hardware con el cual el sistema se comunica. Se representan como un rectángulo con un nombre adentro, como se muestra en la figura 9.

CONTADURIA

Figura 9 Los podemos identificar a partir de las entrevistas con el usuario. Son aquellas entidades que se encuentran por afuera del sistema que proveen con datos al sistema y/o esperan algún tipo de salida del mismo. Por ejemplo, si el usuario dice:

“Cuando recibamos los formularios XYZ de Contaduría debemos producir los reportes financieros al Comité de finanzas”; de acá podemos concluir que tanto Contaduría como el Comité de finanzas son dos entidades externas. “Pretendo suministrar al sistema los datos X, Y y Z y espero que me devuelva los datos A y B”; el usuario es un terminador. Con respecto a los terminadores debemos recordar que: Son externos al sistema que se está modelando. Las relaciones existentes entre los terminadores no se muestran en el DFD. Si existiera la necesidad de modelar dichas relaciones, entonces, los terminadores en realidad son parte del sistema y deberían modelarse como procesos.

• •

2. DFD por niveles ¿Qué hacemos cuando el DFD es muy complejo y tiene docenas de funciones a modelar? La respuesta es organizar el DFD global en una serie de niveles de modo que cada DFD de nivel inferior proporcione más detalles sobre un proceso del DFD de nivel superior. Cuando construimos un DFD por niveles, el primer DFD consta de una sola burbuja, que representa el sistema completo y los flujos de datos muestran la comunicación entre el sistema y las entidades externas (y almacenes externos, si los hubiera). Este DFD especial se lo conoce como Diagrama de Contexto. El DFD de siguiente nivel se lo conoce como la figura 0. Muestra los procesos de más alto nivel del sistema y sus principales interfaces. Estas burbujas deberán numerarse de manera adecuada. Cada burbuja i de un nivel particular se asocia con una figura i del nivel siguiente (si es que existe). Por ejemplo, la burbuja 2 del DFD de la figura 0 se asocia con la figura 2 del nivel siguiente. Las burbujas en la figura j se numerarán j.1, j.2, j.3, etc. Por ejemplo, las burbujas de la figura 3 (obtenida por la explosión de la burbuja 3 de la figura 0) se numerarán 3.1, 3.2, etc.; las burbujas
Especificaciones de Software -–DFD, DD, DTE 5 Ingeniería de Software I

de la figura 3.1 (obtenida por la explosión de la burbuja 3.1 de la figura 3) se numerarán 3.1.1, 3.1.2, 3.1.3, etc. En la figura 10 se ve un ejemplo de explosiones.

E1
a EL SISTEMA

E2
b c
1

w

2

E3
Diagrama de Contexto

c

PA
x y z

PB
v

b

3

4

PC

PD
a

Figura 0: EL SISTEMA x
3.1

PE

o
3.2

y

PF
z t
3.3

PG

Figura 3: PC

Figura 10 El nombre de la figura es heredado de la burbuja correspondiente a su explosión. Por ejemplo, si la burbuja 2 de la figura 0 se llama VALIDAR DATOS, entonces la figura 2 se deberá etiquetar “Figura 2: VALIDAR DATOS” y así sucesivamente para todos los niveles. ¿Cuántos niveles debe tener un DFD? Dependerá del sistema. Podríamos aplicar la misma regla que antes para dar un indicativo: cada DFD no debería contener más de media docena de procesos y almacenes relacionados (entrar en una hoja). ¿Deben desarrollarse todas las partes del sistema con el mismo número de niveles? No. Pueden existir partes más complejas que otras que necesiten un mayor número de niveles de partición. Pero por otro lado, si por ejemplo, al explotar el diagrama de contexto obtenemos 2 burbujas, donde la burbuja 1 es primitiva (no necesita ser explotada) y la burbuja 2 debe ser explotada en 7 niveles, significa que el modelo está desequilibrado y probablemente algunas de las porciones de la funcionalidad asignada a la burbuja 2 deban ser asignadas a otra nueva burbuja o a la burbuja 1. ¿Cómo asegurar que los niveles de un DFD sean consistentes entre sí? Se sigue una regla simple: “los flujos de entrada y salida de una burbuja en un nivel dado deben corresponder con los
Especificaciones de Software -–DFD, DD, DTE 6 Ingeniería de Software I

que entran y salen de toda la figura asociada a dicha burbuja en el nivel inmediato inferior”. Los DFDs de la figura 10 son consistentes entre sí. ¿Cómo se muestran los almacenes en los diversos niveles? La regla es la siguiente: mostrar un almacén en el nivel más alto donde por primera vez sirve de interfaz entre dos o más procesos, luego mostrarlo en cada nivel inferior que describa más a fondo cada una de dichas burbujas. Un ejemplo se ve en la figura 11.

A ALMX

B

A1 ALMX

A2

B1 ALMX

B2

Figura 11 Cuando un almacén es local a los procesos de un figura de un nivel inferior, es decir, sólo es utilizado por los procesos de esa figura, no se lo mostrará en los niveles superiores, ya que quedará implícito en ellos. ¿Cómo se realiza la partición de los DFDs por niveles? Existen dos enfoques diferentes: (a) (b) el enfoque clásico descendente que consiste en partir del diagrama de contexto, para luego desarrollar la figura 0 y así sucesivamente; el enfoque por partición de acontecimientos que consiste en identificar primero los acontecimientos externos a los cuales debe responder el sistema y utilizarlos para realizar un primer borrador de DFD del sistema. Esto puede llevar a aplicar después un enfoque ascendente y, eventualmente, aplicar un enfoque descendente.

Es importante destacar acá que la organización y presentación de DFDs por niveles no necesariamente corresponde a la estrategia para desarrollar estos niveles. 3. Guía práctica para la construcción de un DFD
• •

Escoger nombres significativos para todos los componentes del DFD. Numerar los procesos, ya que además de permitir un modo abreviado de referirse a un proceso, sirve como base a una numeración jerárquica cuando se construyan DFDs por niveles. Esta numeración puede ser hecha en cualquier orden, de derecha a izquierda, de arriba abajo, de cualquier manera siempre que exista una forma consistente de aplicar los números. Lo que

Especificaciones de Software -–DFD, DD, DTE

7

Ingeniería de Software I

importa es no pensar que porque exista una numeración esto implicará algún tipo de secuencia entre los procesos.
• •

Redibujar los DFDs tantas veces como sea necesario. Evitar los DFD excesivamente complejos. En lo posible deberá entrar en una sola página. En la mayoría de los casos, esto significa que no deberían haber mas de media docena de procesos, almacenes, flujos de datos y terminadores relacionados en un solo diagrama. Esta regla proviene de “El número mágico siete, mas o menos dos” de George Miller, Psychology Review, 1956. Existe una excepción para esto: un caso especial de DFD, conocido como diagrama de contexto, que trataremos más adelante. Generalmente, estos últimos diagramas no pueden simplificarse. Asegurarse que el DFD sea lógicamente consistente. Las principales reglas de consistencia son:

Evitar sumideros infinitos, es decir DFDs donde solo existen flujos de entrada y ninguno de salida. Evitar burbujas de generación espontánea, es decir aquellas burbujas que tienen salidas y no tienen entradas, ya que son sumamente sospechosas. Sin embargo, podrían existir. Un ejemplo de esto es un proceso de generación de números random. Evitar los flujos y procesos no etiquetados. Esto no solo indica falta de esmero sino que podría estar ocultando un error o falta de comprensión del problema. Tener cuidado con los almacenes de solo lectura o solo escritura. Son sospechosos. Acá pasa lo mismo que con los procesos de sólo entrada y de sólo salida. Sin embargo, dado que los DFDs cuando son muy grandes se particionan, podríamos encontrarnos que una parte del sistema está modelada por un DFD en el cual un almacén es accedido como solo lectura, pero luego en otra parte del sistema, exista un DFD que se lo accede para escritura. Otra excepción a esta regla son los almacenes externos al sistema que sirven de interfaz entre el sistema y algún otro sistema.

Además de estas reglas propias de los DFDs, existen otras reglas que ayudan a asegurar la consistencia del DFD con respecto a otros modelos del sistema (DER, Diccionario de Datos y DTE). Esas reglas las veremos en la sección “Balanceo de Modelos”.

4. Observaciones sobre los DFDs
Es importante notar que, aunque los DFDs son una herramienta gráfica atractiva para capturar de manera bastante intuitiva los flujos de datos y las operaciones involucradas en un sistema de información, carecen de un significado preciso, ya que:

La semántica de los componentes usados solamente se encuentra especificada por los nombres elegidos por el analista. Carecen de aspectos de control. Por ejemplo, no está claro cuantos paquetes requiere un proceso de un flujo de entrada para producir una salida, o en qué orden los requiere si existen varios flujos de entrada.

El primer problema lo vamos a solucionar, en parte, acompañando al DFD con un diccionario de datos. Sin embargo, para la semántica de un proceso y los detalles de control será necesario usar otro tipo de herramienta que permita construir especificaciones de procesos no ambiguas. Por otro lado, imaginemos que queremos construir una máquina para simular el sistema modelado, a fin de controlar si las especificaciones reflejan las expectativas del usuario. Tal
Especificaciones de Software -–DFD, DD, DTE 8 Ingeniería de Software I

máquina no puede ser derivada directamente a partir del DFD ya que ninguna ejecución sobre la máquina es posible sin una semántica precisa para las notaciones. Un lector humano puede llenar el hueco semántico gracias al significado intuitivo de los identificadores usados en el DFD. Pero una máquina carece de intuición y no podrá interpretar una notación de este tipo. Por estas razones, decimos que los DFDs tradicionales son una notación semi-formal. Su sintaxis, es decir, la forma en que se componen los DFDs muchas veces se encuentra definida en forma precisa, pero su semántica no.

Especificaciones de Software -–DFD, DD, DTE

9

Ingeniería de Software I

Diccionario de Datos
El Diccionario de Datos (DD), aunque no es una herramienta gráfica, es de vital importancia para el desarrollo de un sistema. Sin él, por ejemplo, un modelo de los requerimientos del usuario construido haciendo uso de DFDs está incompleto. El DD es un listado organizado de todos los datos del sistema, con definiciones precisas. En las entradas de un DD tendremos:

Nombre, significado y composición de los flujos y almacenes que se muestran en un DFD. Cuando el paquete de datos que viaja por un flujo es compuesto, se describirá cada una de sus partes, los cuales a su vez si son complejos deberán aparecer como una nueva entrada del diccionario, y así sucesivamente. Lo mismo vale para los paquetes de datos de los almacenes. Nombre, significado y composición de las entidades dependientes e independientes que se muestran en el DER.

Notación
Existen varias notaciones alternativas, nosotros adoptaremos la siguiente: = + () {} [] * @ | Ejemplo: nombre = *nombre de una persona* primer nombre + (segundo nombre) + apellido primer nombre = {caracter válido} segundo nombre = {caracter válido} apellido = {caracter válido} caracter válido = [A-Z|a-z|’|-| |] Es importante que el diccionario esté completo y sea consistente. Para controlar la completitud deberemos verificar que se hayan definido todos los datos presentes en los diagramas; para la consistencia deberemos controlar que no exista más de una definición para un mismo dato y que no hayan entradas fantasmas, es decir, que no correspondan a ningún dato en los diagramas ni tampoco sean parte componente de otro dato definido en el diccionario. está compuesto de y opcional (lo que está entre los dos paréntesis puede estar presente o ausente) iteración. Cero o más ocurrencias de lo que se encuentra entre las dos llaves. seleccionar una de varias alternativas dadas entre los dos corchetes. principio y fin de comentario. El comentario se coloca entre los dos asteriscos. identificador para un almacén (clave primaria). Se coloca precediendo la clave. separa opciones alternativas de construcción

Especificaciones de Software -–DFD, DD, DTE

10

Ingeniería de Software I

Diagramas de Transición de Estados
El Diagrama de Transición de Estados (DTE) es una notación operacional semi-formal que permite construir modelos de comportamiento dependientes del tiempo.

1. Componentes de un DTE
Los principales componentes de un DTE son los estados y las transiciones (flechas que representan cambios de estado). Además, tenemos las condiciones y las acciones asociadas a las transiciones. 1.1. Estados Usaremos un rectángulo para representar cada uno de los estados en los cuales se puede encontrar un sistema. Un estado observable del sistema corresponde a períodos en los cuales (a) el sistema está esperando que algo ocurra en el ambiente externo ó (b) está esperando que alguna actividad que se está realizando en ese momento cambie a otra. Entonces, decimos que un estado representa algún comportamiento del sistema que es observable y que perdura durante algún período de tiempo.

Œ Esperando que el usuario ingrese una contraseña. Œ Acelerando el motor. Œ Mezclando los ingredientes.
1.2. Transiciones
Para representar los cambios del sistema de un estado a otro usamos una flecha conectando los dos estados involucrados. Por ejemplo, en la figura 12 se ve un DTE con tres estados y tres transiciones.
ESTADO 1

Ejemplos de estados pueden ser:

ESTADO 2

ESTADO 3

Figura 12 El sistema modelado por el DTE de la figura 12 puede alternar entre el estado ESTADO 1 y el estado ESTADO 2, pero una vez que pasó del estado ESTADO 2 al estado ESTADO 3 no puede volver más a ninguno de los otros dos estados. Dos de los estados tienen características particulares. El estado ESTADO 1 es el estado inicial del sistema. Se lo reconoce por la flecha de entrada que no viene de ningún estado anterior. Un DTE sólo puede tener un estado inicial. El estado ESTADO 3 es un estado final. Son estados finales aquellos estados que no tienen ninguna flecha de salida (o tienen una flecha de salida que no lleva a

Especificaciones de Software -–DFD, DD, DTE

11

Ingeniería de Software I

ningún otro estado), es decir, aquellos estados en los que una vez que se entró no se puede salir más. Pueden existir múltiples estados finales. Estos son mutuamente excluyentes.

1.3. Condiciones y acciones
Asociados a una transición, existen dos elementos más: las condiciones que se deben satisfacer para que se produzca el cambio de estado y las acciones que el sistema lleva a cabo cuando se realiza el cambio de estado. Se representan como se muestra en la figura 13.
ESTADO 1

Condición
ESTADO 2

Acción

Figura 13

2. Particionado de un DTE
Al igual que sucede con los DFDs, un DTE puede ser tan complejo que no sea posible visualizarlo cómodamente en una página. En este caso podemos descomponerlo por niveles: cualquier estado complejo puede dar origen a un nuevo nivel el cual muestre un nuevo DTE con un estado inicial y estados finales. El estado inicial corresponde al estado de nivel superior, es decir se entra en el estado inicial del DTE de nivel inferior cuando se entra al correspondiente estado compuesto del nivel superior. Los estados finales de los DTE de nivel inferior corresponden a las condiciones de salida del nivel superior.

ESPERANDO TARJETA

Se pulsó Cancelar Devolver Tarjeta

Se ingresó tarjeta Mostrar “Ingrese contraseña”
ESPERANDO CONTRASEÑA

Se pulsó Cancelar Devolver Trajeta Se pulsó “Finalizar” Devolver Tarjeta

Se ingresó contraseña Mostrar menú de opciones
ESPERANDO OPCION

Se pulsó “Extraer efectivo”

Se pulsó “Transferir Fondos”
TRANSFERENCIA

Se pulsó “Realizar Consulta” Mostrar opciones de consulta
CONSULTAS

EXTRACCION

Mostrar menú de opciones

DTE para un cajero automático

Especificaciones de Software -–DFD, DD, DTE

12

Ingeniería de Software I

ESPERANDO ELECCION

Se pulsó “Consulta de Saldo”

Se pulsó “Consulta de Ultimos Movimientos”

IMPRIMIENDO SALDO

IMPRIMIENDO MOVIMIENTOS

DTE correspondiente al estado “CONSULTAS”

Figura 14 En la figura 14 se ve un ejemplo de un DTE por niveles que modela el comportamiento de un cajero automático. Si bien el DTE no está completo, muestra cómo el estado “CONSULTAS” es una estado compuesto que puede ser modelado a su vez por un nuevo DTE.

Especificaciones de Software -–DFD, DD, DTE

13

Ingeniería de Software I

Balanceo de Modelos
El Análisis Estructurado hace uso de tres herramientas gráficas a la hora de construir una especificación de los requerimientos del usuario: los Diagramas de Entidad-Relación, los Diagramas de Flujo de Datos y el Diagrama de Transición de Estados. Cada uno de ellos nos brinda una visión diferente del sistema. El primero pone el énfasis en los datos y sus relaciones, el segundo centra la atención en la funcionalidad del sistema y el tercero en el comportamiento dependiente del tiempo. También, vimos que un complemento a estas herramientas es el Diccionario de Datos el cual nos permite definir con un mayor grado de detalle los datos presentes en los diagramas. Cuando reunimos todos lo modelos del sistema, corremos el riesgo de que aparezcan inconsistencias entre ellos. Esto suele suceder cuando se trata de proyectos particularmente grandes donde distintos grupos de personas han trabajado sobre diferentes modelos. Una especificación estructurada, en la cual se ha verificado que todos los modelos sean consistentes entre sí se dice que está balanceada. Hay dos tipos de errores comunes que se suelen detectar en la actividad de balanceo. Uno es una definición faltante de algún elemento; por ejemplo un almacén de datos definido en un DFD que no se encuentra en el DD. El otro tipo son las inconsistencias entre modelos: la misma realidad se describe de maneras contradictorias en modelos diferentes. 4.1. Balanceo del DFD con el DD

Cada flujo de datos y cada almacén de datos deben estar definidos en el DD. Caso contrario se dice que el dato está indefinido. Cada dato y almacén que se define en el DD debe encontrase en alguna parte del DFD. Si no aparece se dice que es un dato fantasma.

4.2. Balanceo del DFD con el DER

Cada almacén del DFD debe corresponderse con una entidad dependiente o independiente del DER. Los nombres de objetos en el DER deben coincidir con los nombres de los almacenes de datos del DFD. La convención a seguir es usar el plural para los nombres de los almacenes en el DFD y el singular para las entidades en el DER. Por ejemplo, si en el DFD tenemos un almacén CLIENTES, en el DER deberá existir una entidad CLIENTE; esto lleva a una definición en el dicccionario de datos como sigue: CLIENTES = {CLIENTE} CLIENTE = nombre + domicilio + teléfono + ... nombre = ...

Referencias
[3] Edward Yordon. Análisis Estructurado Moderno. Prentice Hall. 1989 [4] Roger Pressman. Ingeniería del Software, un enfoque práctico. Quinta edición. Mc Graw Hill. 2002 [5] Carlo Ghezzi y Dino Mandrioli. Fundamentals od Software Enginering. Prentice Hall. 1991 [6] Ian Sommerville. Software Enginering. Quinta Edición. Addison Wesley. 1996 [7] Tom De Marco. Structured Analysis and System Specification. Prentice Hall. 1979
Especificaciones de Software -–DFD, DD, DTE 14 Ingeniería de Software I

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->