Este documento describe el diseño orientado al flujo de datos, un método de diseño de software que parte del análisis del flujo de información. Explica los pasos para convertir diagramas de flujo de datos en estructuras de programa, dependiendo de si el flujo es de transformación o transacción. También cubre heurísticas para refinar la estructura inicial y el diseño procedimental basado en construcciones lógicas como la secuencia, condición y repetición.

1. INSTITUTO TECNOLÓGICO SUPERIOR DE LERDO SISTEMAS DE INFORMACION II LICENCIATURA EN INFORMÁTICA DISEÑO ORIENTADO AL FLUJO DE DATOS ALUMNA: GUADALUPE ELIZABETH HERRERA CISNEROS

2. Los métodos de diseño del software se obtienen del estudio de cada uno de los tres dominios del modelo de análisis. El dominio de los datos, el funcional y el de comportamiento sirven de directriz para la creación del diseño. En el diseño estructurado orientado al flujo de datos, partimos de la representación del flujo de la información obtenida en la fase de análisis, donde la información puede representarse como un flujo continuo que sufre una serie de transformaciones conforme va de la entrada a la salida. El diagrama de flujo de datos DFD (o de burbujas) se utiliza como herramienta gráfica para la descripción del flujo de la información.

3. DISEÑO DE DATOS

4. El impacto de la estructura de datos sobre la estructura del programa y la complejidad procedimental hace que el diseño de datos tenga una gran influencia en la calidad del software. Los datos bien diseñados pueden conducir a una mejor estructura de programa, a una modularidad efectiva y a una complejidad procedimental reducida.

5. DISEÑO ARQUITECTÓNICO

6. El objetivo principal del diseño arquitectónico es desarrollar una estructura de programa modular y representar las relaciones de control entre los módulos. Mezcla la estructura de programas y la estructura de datos y define las relaciones que facilitan el flujo de los datos a lo largo del programa. El diseño orientado al flujo de datos es compatible con un amplio rango de áreas de aplicación. Es particularmente útil cuando se procesa secuencialmente la información y no existe ninguna estructura jerárquica formal. De hecho, todo el software puede representarse como un diagrama de flujo de datos. Ejemplo: Aplicaciones con microprocesadores, procedimientos de análisis numérico, procesos de control, etc.

7. EL PROCESO DEL DISEÑO ARQUITECTÓNICO

8. El diseño orientado al flujo de datos define varias representaciones que transforman el flujo de la información en la estructura del programa. El Diseño Orientado al Flujo de Datos permite una cómoda transformación de las representaciones de la información (DFD) a una descripción de la estructura del programa. 1. Establecer el tipo de flujo de información. - Flujo de transformación. - Flujo de transacción. 2. Determinar los límites del flujo. 3. Convertir el DFD en la estructura del programa 4. Definir la jerarquía de control descomponiéndola mediante particionamiento. 5. Refinar la estructura resultante usando medidas y heurísticas de diseño El tipo de flujo de información es lo que determina el método de conversión requerido en el paso 3.

9. En un sistema, la información entra y sale en una forma del mundo exterior (entradas de teclado, tonos telefónicos, imágenes de visualización,...). Esos datos externos, deben ser convertidos a una forma adecuada 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. En el interior del software se produce una transición, los datos entrantes pasan a través de un centro de transformación, moviéndose ahora hacia la salida del software. Estos datos forman el Flujo Saliente. El flujo de datos global ocurre de forma secuencial y sigue uno o pocos caminos directos. Cuando una parte del DFD tiene estas características decimos que es un Flujo de Transformación FLUJO DE TRANSFORMACIÓN

10. 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 del mundo exterior en una transacción. Se evalúa la transacción y de acuerdo con su valor, el flujo sigue por uno de los muchos caminos de acción. El centro del flujo de información desde el que emanan los caminos de acción se denomina Centro de Transacción. Dentro de un flujo de transacción, el flujo de información a través de un camino de acción puede tener características de flujo de transformación. FLUJO DE TRANSACCIÓN

12. ANALISIS DE TRANSFORMACIÓN

14. 3. Determinar si el DFD tiene características de transformación o de transacción: en general, el flujo de información de un sistema podrá representarse siempre como una transformación. Si tiene una característica obvia de transacción es conveniente tratarla como tal. El diseñador selecciona la característica general del flujo basándose en la naturaleza prevaleciente del DFD. Se aíslan las regiones locales de flujo de transformación o de transacción, lo que nos permitirá refinar la estructura del programa posteriormente. 4. Aislar el centro de transformación especificando los límites de los flujos entrante y saliente: la interpretación de los límites es algo subjetivo dependiente del diseñador, así es posible obtener distintas soluciones alternativas variando los límites del flujo. El diseñador debe establecer unos límites razonables.

15. 5. Realizar una descomposición de primer nivel: la estructura del programa representa una distribución descendente del control. La descomposició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ía del trabajo de entrada, de procesamiento y de salida. Los módulos de nivel intermedio ejecutan algún control y realizan moderadas cantidades de trabajo . En la parte superior de la estructura del programa se encuentra un módulo de control, que sirve para coordinar las funciones de control subordinadas, que son : a). Controlador del procesamiento de la información entrante, que coordina la recepción de todos los datos que llegan.

16. b). Controlador del centro de transformación, que supervisa todas las operaciones sobre los datos en su forma interna. c). Controlador del procesamiento de la información saliente, que coordina la producción de la información que sale. Cada módulo de control tiene un nombre que indica la función de los módulos subordinados que controla.

17. 6. Realizar descomposición de segundo nivel: se realiza mediante la conversión de las transformaciones individuales (burbujas) de un DFD, en los módulos correspondientes a la estructura del programa. Comenzando dentro de los límites del centro de transformación y yendo hacia fuera a través de los caminos de entrada y luego de salida, las transformaciones se convierten en niveles subordinados de la estructura de control . Así obtenemos una estructura de programa inicial, también llamada Diagrama de Estructura. Aunque hemos hecho una correspondencia uno a uno entre las burbujas del DFD y los módulos del software, también se pueden combinar 2 ó 3 burbujas, representándolas como un solo módulo, o también puede dividirse una burbuja en dos o más módulos. Aunque los módulos que forman la estructura de programa tienen un nombre que indica la función que realiza, se debe escribir para cada uno de ellos un breve texto que explique su procesamiento. La información que contendrá es: · La información que entra y la que sale del módulo · La información que es retenida en el módulo (ejemplo: en almacenamientos de datos) · Explicación del procedimiento, indicando los principales puntos de decisión y las tareas. · Tratamiento de las restricciones y características especiales, si las hay.

18. 7 . Refinar la estructura inicial del programa usando heurísticas para mejorar la calidad del software. La estructura inicial del programa siempre puede refinarse aplicando los fundamentos de diseño, por ello, se puede aumentar o reducir el número de módulos para obtener una descomposición con una buena cohesión, un mínimo acoplamiento, una estructura de fácil implementación, prueba y mantenimiento. Los refinamientos se rigen por consideraciones prácticas y de sentido común. Hay ocasiones en las que el controlador de flujo de datos entrante/saliente es innecesario, o se requiere un procesamiento de la entrada en un módulo subordinado al controlador de transformaciones, o no se puede conseguir un bajo acoplamiento por la necesidad de trabajar con datos globales.

19. ANÁLISIS DE TRANSACCIÓN.

20. Cuando en un sistema hay un flujo de transacción, dependiendo del valor de ese elemento transacción, se seguirá uno u otro camino de acción de todos los posibles. Pasos a seguir: 1. Revisar el modelo fundamental del sistema. 2. Revisar y refinar los DFD. 3. Determinar si el DFD tiene características de transformación o de transacción. 4. Identificar el centro de transacción y las características del flujo de cada camino de acción. El centro de acción se localiza fácilmente en el DFD, es el origen de varios caminos de información que fluyen radialmente de él. También deben aislarse el camino entrante y todos los caminos de acción. DEFINICION

21. 5. Transformar el DFD en una estructura de software adecuada al procesamiento de transacciones. El flujo de transacción se convierte en una estructura de programa que contiene una rama entrante y una rama de distribución. · la rama entrante se obtiene igual que el análisis de transformación, desde el centro de transacción hacia fuera, se convierten las burbujas en módulos. · la rama de distribución tiene un módulo distribuidor que controla todos los módulos de acción subordinados. El flujo de cada camino de acción del DFD se convertirá en una estructura que se corresponda con las características del flujo (de transformaci ón o de transacción).

22. 6. Descomponer y refinar la estructura de transacción y la estructura de cada camino de acción. Cada camino de acción del DFD tiene sus propias características de flujo de información o de transacción. La subestructura de cada camino de acción se obtiene siguiendo los pasos del análisis correspondiente. 7. Refinar la estructura inicial del software usando heurísticas de diseño para mejorar la calidad

23. HEURÍSTICAS DE DISEÑO

25. 3. Mantener el efecto de un módulo dentro del ámbito de control de ese módulo. El ámbito del efecto de un módulo m se define por todos los módulos que quedan afectados por una decisión tomada en el módulo m. El ámbito de control del módulo m está formado por todos sus módulos subordinados 4. Evaluar los interfaces de los módulos para reducir la complejidad y la redundancia y mejorar la consistencia. Quiere decir que se debe revisar la información que se pasa en los interfaces para pasar únicamente la información necesaria. 5. Definir módulos cuyas funciones sean predecibles, para evitar módulos que sean demasiado restrictivos. 6. Fomentar módulos con entrada única y salida única, evitando las “conexiones patológicas”. El software es más fácil de comprender y mantener cuando se entra a los módulos por el principio y se sale por el final. 7. Empaquetar el software de acuerdo con las restricciones del diseño y los requisitos de portabilidad.

26. DISEÑO PROCEDIMENTAL

27. Se realiza después de que se ha establecido la estructura del programa y de los datos. Debe especificar los detalles de los procedimientos sin ambigüedad. Los fundamentos del diseño procedimental se establecieron cuando se propuso el uso de un conjunto de construcciones lógicas con las que podía formarse cualquier programa. Las construcciones son: la secuencia ; la condición ; y la repetición. Estas tres construcciones son fundamentales en la programación estructurada. Las construcciones estructuradas se propusieron para limitar el diseño procedimental del software a un conjunto reducido de operaciones predecibles, facilitando la legibilidad, prueba y mantenimiento de los programas.