c:\fakepath\diseño orientado al flujo de datos

15
DISEÑO ORIENTADO AL FLUJO DE DATOS

Upload: sistemas222

Post on 12-Jul-2015

282 views

Category:

Documents


0 download

TRANSCRIPT

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

DISEÑO ORIENTADO AL FLUJO DE DATOS

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

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.

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

DISEÑO Y FLUJO DE LA INFORMACIÓN

A partir del Diagrama de contexto (DFD de nivel 0), la información puederepresentarse mediante un flujo continuo que sufre una serie detransformaciones (procesos) conforme se dirige de la entrada a la salida.El Diagrama de Flujo de Datos (DFD) se utiliza como herramienta gráfica parala descripción del flujo de la información.

El Diseño Orientado al Flujo de Datos (DOFD) define varias representacionesque 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 queconsideraban la modularidad, el diseño descendente o refinamiento y laprogramación estructurada. EL DOFD amplió estas técnicas integrando el flujode información en el proceso de diseño.

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

Para las aplicaciones de tiempo real, conducidas por interrupciones, se realizan con una ampliación del DOFD, que lo que hacen es una adaptación del método.

En el caso en que el flujo de datos no importe realmente, se suelen utilizar métodos de diseño orientados a objetos.

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

CONSIDERACIONES SOBRE EL PROCESO DE DISEÑO

El DOFD permite una traducción sencilla de las representaciones de la información de los DFD contenidas en la especificación del sistema a una descripción del diseño de la estructura del programa.

La traducción desde el flujo de la información hasta la estructura consta decinco pasos:• Establecer el tipo de flujo de información• Determinar los límites del flujo• Convertir el DFD en la estructura del programa• Definir la jerarquía de control mediante factorización• Refinar la estructura resultante mediante heurísticas de diseñoEl tipo de flujo de información es el que determina cómo se realiza la

conversión del DFD a la estructura del programa.Los tipos de flujo de información son:• Flujo de transformación• Flujo de transacción

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

Flujo de transformación

En el Diagrama de Contexto (modelo fundamental del sistema) la información entra y sale de una forma.

A veces esta información tiene que ser convertida a una forma interna para el procesamiento. La información entra al sistema mediante caminos que transforman los datos externos a una forma interna y se identifica como flujo entrante. Es decir, un flujo entrante es un camino en el que se transforma la información externa en interna.

Los datos entrantes pasan a través de un proceso de transformación, moviéndose a través de caminos que conducen hacia la salida del software. El flujo saliente transforma la información interna en externa. El flujo de datos global ocurre de forma secuencial.

Cuando una parte de un DFD muestra estas características tenemos un flujo de transformación.

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

Flujo de transacción

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 9: C:\fakepath\diseño orientado al flujo de datos
Page 10: C:\fakepath\diseño orientado al flujo de datos

ANÁLISIS DE TRANSFORMACIÓN

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

Pasos del diseñoLos pasos comienzan con una comprobación del trabajo realizado durante el análisis

de requerimientos y luego evoluciona hasta las estructura del programa.

Paso 1. Revisión del modelo fundamental del sistemaEl paso de diseño comienza con una evaluación de la especificación del

sistema y de la especificación de requisitos del software. Estos dos documentos describen el flujo y la estructura de la información.

Paso 2. Revisión y refinamiento de los DFD del softwareCon el fin de conseguir un mayor detalle, se refina la información contenida

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

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

Paso 3. Determinar si el DFD tiene características de transformación o de transacciónEn este paso el diseñador selecciona la característica general del flujo basándose en la

naturaleza del DFD (transformación o transacción. Para ello se verían si existen centros de transacción claramente definidos). A continuación se aislan las regiones locales de flujo de transformación o de transacción.

Paso 4. Aislar el centro de transformación especificando los límites de los flujos entrantes y salientes

La interpretación de los límites de los flujos entrantes y salientes es algo subjetivo, dependiendo del lugar en el que se decida donde se realiza la transformación de externa a interna (transformación) y de interna a externa (transacción). Es decir, diferentes diseñadores pueden establecer límites diferentes para la situación de los límites del flujo.

Aunque se debe tener cuidado al establecer los límites, una variación de una, burbuja en un camino de flujo, normalmente tendrá poco impacto en la estructura final del programa.

En general se trata de establecer unos límites razonables, más que en establecer grandes discusiones sobre la ubicación de las separaciones.

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

Paso 5. Realización del Primer Nivel de FactorizaciónLa estructura de programa o jerarquía de control representa una

distribución descendente de control. La factorización da como resultado una estructura de programa en la que los módulos de nivel superior toman las decisiones de ejecución y los módulos de nivel inferior ejecutan la mayor parte del trabajo de entrada, computacional y de salida. Los módulos intermedios realizan algunas tareas de control y algunas tareas de trabajo.

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

La figura siguiente muestra este primer nivel de factorización

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

En la parte superior de la estructura de programa se encuentra un módulo decontrol, que sirve para controlar las funciones de control subordinadas.El número de módulos del primer nivel debe limitarse al mínimo necesario paraobtener buenas características de cohesión y acoplamiento.

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

Paso 6. Ejecución del Segundo Nivel de Factorización

El segundo nivel de factorización se realiza mediante la conversión de las burbujas de un DFD en los módulos correspondientes de la estructura de programa.

La conversión se realiza comenzando desde dentro y yendo hacia afuera comenzando por los caminos de entrada, y luego continuando con los caminos de salida.

Page 15: C:\fakepath\diseño orientado al flujo de datos

Paso 7. Refinar la estructura inicial del programa utilizando medidas y heurísticas de diseño

La estructura inicial del programa siempre puede refinarse aplicando los conceptos de independencia funcional. Se puede aumentar o reducir el número de módulos con el fin de conseguir una factorización sensata, una buena cohesión, un acoplamiento mínimo y una estructura que se pueda implementar sin dificultad, probarse sin confusión y mantenerse sin problemas.