Diseño orientado al flujo de datos

Download Report

Transcript Diseño orientado al flujo de datos

Diseño orientado al flujo de
datos
Miriam Meza Ponce
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.
DISEÑO Y FLUJO DE LA INFORMACIÓN
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.
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
Flujo de transformación
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.
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.
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.
Paso 1. Revisión del modelo fundamental del
sistema. El 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
software. Con el fin de conseguir un mayor
detalle, se refina la información contenida en
los DFD.
• Paso 3. Determinar si el DFD tiene características de
transformación o de Transacción En 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
aíslan 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.
• Paso 5. Realización del Primer Nivel de
Factorización La 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.
• 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.
• 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.
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.
• 2. Intentar minimizar las
estructuras con alto grado de
salida. Fomentar un alto grado de
entrada conforme aumente la
profundidad.
• 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.
5. Definir módulos cuyas funciones
sean predecibles.
6. Fomentar módulos con entrada
única y salida única
Fin