14
Sistemas de información II

C:\fakepath\diseño orientado a flujo de datos

Embed Size (px)

Citation preview

Page 1: C:\fakepath\diseño orientado a  flujo de datos

Sistemas de información II

Page 2: C:\fakepath\diseño orientado a  flujo de datos

Recordemos que el diseño es una actividad que consta de una serie

de pasos, en los que partiendo de la especificación del sistema (de

los propios requerimientos), obtenemos una representación de la

arquitectura del sistema, de las estructuras de datos y de los

procedimientos.

Se trata de una actividad en la que se toman decisiones muy

importantes, ya que sobre él se realizará la traducción al código que

implementan realmente las funciones.

Recordar también que el diseño comparte aspectos con la

programación, pero que no son lo mismo ni mucho menos, ya que

el nivel de detalle es muy diferente.

En este capítulo estudiaremos el método de Diseño Orientado al Flujo

de Datos, cuyo objetivo es el de proporcionar un enfoque

sistemático que nos permita obtener las estructuras de programa.

Page 3: C:\fakepath\diseño orientado a  flujo de datos

A partir del Diagrama de contexto (DFD de nivel 0), la información puede representarse

mediante un flujo continuo que sufre una serie de transformaciones (procesos)

conforme se dirige de la entrada a la salida.

El Diagrama de Flujo de Datos (DFD) se utiliza como herramienta gráfica para la

descripción del flujo de la información.

El Diseño Orientado al Flujo de Datos (DOFD) define varias representaciones que

transforman el flujo de la información en la estructura del programa.

El DOFD tiene sus orígenes en los primeros conceptos de diseño que

consideraban la modularidad, el diseño descendente o refinamiento y la programación

estructurada. EL DOFD amplió estas técnicas integrando el flujo de información en el

proceso de diseño.

Page 4: C:\fakepath\diseño orientado a  flujo de datos

El Diagrama de Contexto implica un flujo de transformación. Sin

embargo, a veces ocurre que un flujo de datos puede

desencadenar otro flujo de datos entre uno de varios caminos.

El flujo de transacción se caracteriza por el movimiento de datos a

través de un camino de llegada, que convierte la información, la

evalúa, (centro de transacción) y de acuerdo con el valor de la

comparación, el flujo sigue por alguno de los caminos de acción.

Page 5: C:\fakepath\diseño orientado a  flujo de datos

El análisis de transformación es un conjunto de

pasos de diseño que permiten convertir un DFD,

con características de flujo de transformación, en

una estructura de programa

Page 6: C:\fakepath\diseño orientado a  flujo de datos

Los pasos comienzan con una comprobación del trabajo realizadodurante el análisis de requerimientos y luego evoluciona hasta lasestructura del programa.

Paso 1. Revisión del modelo fundamental del sistema El paso dediseño comienza con una evaluación de la especificación delsistema y de la especificación de requisitos del software. Estos dosdocumentos describen el flujo y la estructura de la información.

Paso 2. Revisión y refinamiento de los DFD del software Con el fin deconseguir un mayor detalle, se refina la información contenida enlos DFD.

Se trata de ver que los niveles de los DFD muestren una cohesiónrelativamente alta, es decir, que cada proceso realice una funciónsencilla y clara. De esta forma se podría proceder sin necesidad derefinar más.

Page 7: C:\fakepath\diseño orientado a  flujo de datos

Paso 3. Determinar si el DFD tiene características detransformación o de Transacción En este paso el diseñadorselecciona la característica general del flujo basándose en lanaturaleza del DFD (transformación o transacción. Para ello severían si existen centros de transacción claramente definidos). Acontinuación se aislan las regiones locales de flujo detransformación o de transacción.

Paso 4. Aislar el centro de transformación especificando los límitesde los flujos entrantes y salientes La interpretación de los límitesde los flujos entrantes y salientes es algo subjetivo, dependiendodel lugar en el que se decida donde se realiza la transformaciónde externa a interna (transformación) y de interna a externa(transacción). Es decir, diferentes diseñadores puedenestablecer límites diferentes para la situación de los límites delflujo.

Page 8: C:\fakepath\diseño orientado a  flujo de datos

Paso 5. Realización del Primer Nivel de Factorización La estructura de programao jerarquía de control representa una distribución descendente de control. Lafactorización da como resultado una estructura de programa en la que losmódulos de nivel superior toman las decisiones de ejecución y los módulos denivel inferior ejecutan la mayor parte del trabajo de entrada, computacional y desalida. Los módulos intermedios realizan algunas tareas de control y algunastareas de trabajo.

Cuando se encuentra un flujo de transformación, el DFD se organiza en unaestructura específica que proporciona el control para procesamiento de lainformación entrante, de transformación y de salida.

Page 9: C:\fakepath\diseño orientado a  flujo de datos

Paso 6. Ejecución del Segundo Nivel de Factorización Elsegundo nivel de factorización se realiza mediante laconversión de las burbujas de un DFD en los móduloscorrespondientes de la estructura de programa.

La conversión se realiza comenzando desde dentro y yendohacia fuera comenzando por los caminos de entrada, yluego continuando con los caminos de salida como semuestra en la figura siguiente.

Page 10: C:\fakepath\diseño orientado a  flujo de datos

El análisis de transacción es un conjunto de pasosde diseño que permiten convertir un DFD, concaracterísticas de flujo de transacción, en unaestructura de programa

Pasos del diseño Los pasos del diseño para elanálisis de transacciones son similares (y enalgunos casos idénticos) a los pasos para elanálisis de transformaciones. La principaldiferencia se encuentra en la conversión del DFDen la estructura del programa.

Page 11: C:\fakepath\diseño orientado a  flujo de datos

Paso 1. Revisar el modelo fundamental del sistema

Paso 2. Revisar y refinar los DFD para el software

Paso 3. Determinar si el DFD tiene características de transformación o detransacción Si en un DFD apareciesen características de transformación y detransacción habría que establecer los límites para ambos tipos de flujo.

Paso 4. Identificar el centro de transacción y las características del flujo de cadacamino de acción La situación del centro de transacción puede localizarse deforma inmediata en el DFD, ya que es el origen de varios caminos deinformación que fluyen radialmente desde él.

También debe aislarse el camino entrante (es decir, el camino de flujo que recibeun centro de transacción) y todos los caminos de acción (es decir, todos loscaminos de flujo que salen del centro de transacción).

Paso 5. Transformar el DFD en una estructura de software adecuada alprocesamiento de transacciones El flujo de transacción se convierte en unaestructura de programa que contiene una rama entrante y una rama dedistribución.

Page 12: C:\fakepath\diseño orientado a  flujo de datos

Una vez que se ha desarrollado una estructura de programa utilizando el métododel DOFD, se puede conseguir una modularidad efectiva aplicando losprincipios de diseño y manipulando la estructura resultante de acuerdo con esteconjunto de heurísticas.

1. Evaluar la estructura de programa preliminar para reducir el acoplamiento yreducir la cohesión A menudo, se expande un módulo cuando en dos o másmódulos existe un componente de procesamiento común que puederedefinirse como un módulo cohesivo aparte.

Para reducir el acoplamiento, se pueden juntar varios módulos para evitar lasinterfaces complejas y reducir el número de referencias a datos globales.

2. Intentar minimizar las estructuras con alto grado de salida. Fomentar un altogrado de entrada conforme aumente la profundidad La estructura de control nodebe ser demasiado ancha, sino que se opta por estructuras con varias capasde control y gran utilización de los módulos inferiores.

Page 13: C:\fakepath\diseño orientado a  flujo de datos

3. Mantener el efecto de un módulo dentro del ámbito de control de ese

Módulo 4. Evaluar las interfaces de los módulos para reducir lacomplejidad y la redundancia y mejorar la consistencia La complejidaden las interfaces es una causa principal de los errores del software.Las interfaces deben diseñarse para que sólo se pase la informaciónnecesaria y deben ser consistentes con la función del módulo.

5. Definir módulos cuyas funciones sean predecibles Los módulos debentener una apariencia de caja negra, ocultando los detalles deprocesamiento.

6. Fomentar módulos con entrada única y salida única El software es másfácil de comprender, y por tanto, es más fácil de mantener, si a losmódulos se entra por el principio y se sale por el final.

Page 14: C:\fakepath\diseño orientado a  flujo de datos

El Diseño Orientado al Flujo de Datos (DOFD) es una metodología queutiliza las características del flujo de información para derivar laestructura del programa. Un DFD se convierte en una estructura deprograma en función de las características del flujo de información: detransformación o de transacción.

El análisis de transformación se aplica a un flujo de información quemuestra unos límites claros para los datos entrantes y los salientes. ElDFD se convierte en una estructura de control que asigna control a laentrada, al procesamiento y a la salida, en tres jerarquías de módulosfactorizadas por separado.

El análisis de transacción se aplica cuando un elemento de informaciónhace que el flujo se bifurque hacia uno entre muchos caminos. El DFDse convierte en una estructura que asigna el control a unasubestructura que toma y evalúa una transacción. Otras subestructurascontrolan todas las acciones basadas en una transacción