1. Instituto TecnológicoSuperior De Lerdo Carrera: Licenciatura en Informática Nombre del trabajo:Diseño orientado al flujo de datosMateria:sistemas de información II Maestro:M.E. E.D. I.S.C. Ricardo de Jesús Bustamante González Alumno:Juan Armando Bautista Martínez Numero de Control:07230461

2. 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. 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.

3. DISEÑO Y FLUJO DE LA INFORMACIÓN 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.

4. La elección de un método de diseño depende del área de aplicación. El método de DOFD es particularmente útil cuando la información se procesa de forma secuencial y no existe una estructura de datos jerárquica. 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.

6. Determinar los límites del flujo

7. Convertir el DFD en la estructura del programa

8. Definir la jerarquía de control mediante factorización

11. ANÁLISIS DE TRANSACCIÓN El análisis de transacción es un conjunto de pasos de diseño que permiten convertir un DFD, con características de flujo de transacción, en una estructura de programa Pasos del diseño Los pasos del diseño para el análisis de transacciones son similares (y en algunos casos idénticos) a los pasos para el análisis de transformaciones. La principal diferencia se encuentra en la conversión del DFD en la estructura del programa. LOS PASOS SON: Revisar el modelo fundamental del sistema Revisar y refinar los DFD para el software Determinar si el DFD tiene características de transformación o de transacción Identificar el centro de transacción y las características del flujo de cada camino de acción Transformar el DFD en una estructura de software adecuada al procesamiento de transacciones Factorizar y refinar la estructura de transacciones y la estructura de cada camino de acción Refinar la estructura inicial del software usando heurísticas de diseño para mejorar la calidad

12. HEURÍSTICAS DE DISEÑO Una vez que se ha desarrollado una estructura de programa utilizando el método del DOFD, se puede conseguir una modularidad efectiva aplicando los principios de diseño y manipulando la estructura resultante de acuerdo con este conjunto de heurísticas. 1. Evaluar la estructura de programa preliminar para reducir el acoplamiento y reducir la cohesión A menudo, se expande un módulo cuando en dos o más módulos existe un componente de procesamiento común que puede redefinirse como un módulo cohesivo aparte. Para reducir el acoplamiento, se pueden juntar varios módulos para evitar las interfaces complejas y reducir el número de referencias a datos globales. 2. Intentar minimizar las estructuras con alto grado de salida. Fomentar un alto grado de entrada conforme aumente la profundidad La estructura de control no debe ser demasiado ancha, sino que se opta por estructuras con varias capas de control y gran utilización de los módulos inferiores.

13. 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 la complejidad y la redundancia y mejorar la consistencia La complejidad en las interfaces es una causa principal de los errores del software. Las interfaces deben diseñarse para que sólo se pase la información necesaria y deben ser consistentes con la función del módulo. 5. Definir módulos cuyas funciones sean predecibles Los módulos deben tener una apariencia de caja negra, ocultando los detalles de procesamiento. 6. Fomentar módulos con entrada única y salida única El software es más fácil de comprender, y por tanto, es más fácil de mantener, si a los módulos se entra por el principio y se sale por el final.