Embed Size (px)
Citation preview
Carrera: Licenciatura en Informática
Nombre del trabajo:Diseño orientado al flujo de datos
Materia: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
Instituto Tecnológico Superior De Lerdo
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.
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.
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.
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 de
cinco 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ño
El 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
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ño
Los pasos comienzan con una comprobación del trabajo realizado durante el análisis de
requerimientos y luego evoluciona hasta las estructura del programa.
LOS PASOS SON:
1. Revisión del modelo fundamental del sistema
2. Revisión y refinamiento de los DFD del software
3. Determinar si el DFD tiene características de transformación o de transacción
4. Aislar el centro de transformación especificando los límites de los flujos entrantes y
salientes
5. Realización del Primer Nivel de Factorización
6. Ejecución del Segundo Nivel de Factorización
7. Refinar la estructura inicial del programa utilizando medidas y heurísticas de diseño
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:
1. Revisar el modelo fundamental del sistema
2. Revisar y refinar los DFD para el software
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
5. Transformar el DFD en una estructura de software adecuada al procesamiento de
transacciones
6. Factorizar y refinar la estructura de transacciones y la estructura de cada camino de
acción
7. Refinar la estructura inicial del software usando heurísticas de diseño para mejorar la
calidad
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.
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.
