19
INSTITUTO TECNOLOGICO SUPERIOR DE LERDO MATERIA: SISTEMAS DE INFORMACION 2 PROFESOR: RICARDO DE JESUS BUSTAMANTE ALUMNA: DEAHESY NAJERA GARCIA # DE CONTROL: 07230484

Diseño orientado a flujo de datos deahesy

Embed Size (px)

Citation preview

INSTITUTO TECNOLOGICO SUPERIOR DE LERDO

MATERIA: SISTEMAS DE INFORMACION 2

PROFESOR: RICARDO DE JESUS BUSTAMANTE

ALUMNA: DEAHESY NAJERA GARCIA# DE CONTROL: 07230484

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 propiosrequerimientos), 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, yaque 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

A partir del Diagrama de contexto (DFD de nivel 0), la información puederepresentarse 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 queconsideraban la modularidad, el diseño descendente o refinamiento y laprogramació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.

Flujo de transformaciónEn 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 flujode transformación.

Flujo de transacciónEl 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

PASOS DEL D

ISEÑO

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 3. Determinar si el DFD tiene características de transformación o deTransacción

En este paso el diseñador selecciona la característica general del flujobasándose en la naturaleza del DFD (transformación o transacción. Para ellose 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 losflujos entrantes y salientes

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

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

Paso 5. Realización del Primer Nivel de FactorizaciónLa estructura de programa o jerarquía de control representa una distribucióndescendente de control. La factorización da como resultado una estructura deprograma 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 deentrada, computacional y de salida. Los módulos intermedios realizan algunastareas de control y algunas tareas de trabajo.

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

La figura siguiente muestra este primer nivel de factorización

Primer nivel de factorizaciónEn 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.

HEURÍSTICAS DE DISEÑO

Una vez que se ha desarrollado una estructura de programa utilizando elmé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 elacoplamiento y reducir la cohesiónA menudo, se expande un módulo cuando en dos o más módulos existe uncomponente de procesamiento común que puede redefinirse como un módulo cohesivo aparte.

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 consistenciaLa complejidad en las interfaces es una causa principal de los errores delsoftware. 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 predeciblesLos módulos deben tener una apariencia de caja negra, ocultando los detalles de procesamiento.

6. Fomentar módulos con entrada única y salida únicaEl 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.

RESU

MEN

El Diseño Orientado al Flujo de Datos (DOFD) es una metodología que utiliza las características del flujo de información para derivar la estructura del programa.

Un DFD se convierte en una estructura de programa en función de las características del flujo de información: de transformación o de transacción.

El análisis de transformación se aplica a un flujo de información que muestra unos límites claros para los datos entrantes y los salientes. El DFD se convierte en una estructura de control que asigna control a la entrada, al procesamiento y a la salida, en tres jerarquías de módulos factorizadas por separado.

El análisis de transacción se aplica cuando un elemento de información hace que el flujo se bifurque hacia uno entre muchos caminos. El DFD se convierte en una estructura que asigna el control a una subestructura que toma y evalúa una transacción. Otras subestructuras controlan todas las acciones basadas en una transacción.