Diseño orientado al flujo de datos

Slides:



Advertisements
Presentaciones similares
DISEÑO DE TRANSFERENCIA ENTRE REGISTROS
Advertisements

Fundamentos de Diseño de Software INFT.1
También conocido como Diseño Lógico Rodrigo Salvatierra Alberú.
DIAGRAMA DE ACTIVIDAD Roberto Certain Leonardo Molina.
PROCESO Y MODELOS EN LA INGENIERIA DE SOFTWARE
ANÁLISIS DE REQUERIMIENTOS
CARRERA: INGENIERIA CIVIL UNI-RUACS
Sistemas de Información Basados en Computadoras (CBIS)
METRICAS DE PROCESO Y PROYECTO
Resolución de Problemas Algoritmos y Programación
10º2 Sergio Posso. Jonatán Agualimpia. Julia Blandón. Docente:
DIAGRAMA DE FLUJO DE DATOS
MODELADO DE ANALISIS Y DISEÑO
CONCEPTOS Y PRINCIPIOS DE DISEÑO
Administración de Procesos de Pruebas
Evaluación de Productos
SISTEMAS DE INFORMACIÓN 2 SISTEMAS DE INFORMACIÓN 2.
Laura Patricia Pinto Prieto Ingeniera de sistemas.
Análisis y Diseño Orientado a Objetos utilizando UML CAPITULO V DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS.
Diseño del Software Diseño de datos Diseño arquitectónico
Ingeniería de Software Orientado a Objetos
Gestión por procesos.
DISEÑO DE SOFTWARE 1ª. Parte
Ciclo de Vida del Software Paradigmas de Desarrollo
PROGRAMACIÓN PROCEDIMENTAL
ISF5501 Ingeniería de Software
Diseño de algoritmos La computadora puede realizar procesos y darnos resultados, sin que tengamos la noción exacta de las operaciones que realiza. Con.
Organización y Estructuración de Datos Profesor Titular: Mg Carlos G. Neil 2009.
Comunicación y Multimedia
UNIDAD 2. ALGORITMOS Y ESTRUCTURAS DE DATOS.
CONCEPTOS BÁSICOS Diseño de Sistemas.
Análisis de Sistemas.
TEMAS PRINCIPALES. ALGORITMOS. CONCEPTOS El algoritmo es un método para resolver un problema mediante una serie de pasos definidos, precisos y finitos.
Organización y Estructuración de Datos
Diagramas de flujo de datos
Diseño: Fundamento y Documentación ISF5501 Ingeniería de Software Semana 13/2.
Metodología para la construcción de programas
Ingeniería de software
Análisis y Diseño de Sistemas
Diseño de Software y su Proceso
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
Trainning DFD.
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Dependiendo del.
Explica con tus propias palabras
Ámbito y Estimaciones de Proyecto ISF5501 Ingeniería de Software Semana 7/1.
Trainning DFD.
Metodología de la programación
Alexander Aristizabal Ángelo flores herrera
Diseño de Sistemas.
Edward Barrera Barrera Cristian Anderson Isacc
Ingeniería de Requisitos
Diseño del Software e Ingeniería del Software
Diseño Orientado al Flujo de Datos
TIPOS DE PRUEBAS DEL SOFTWARE
Diseño de Procedimientos
Actividades en el Proceso de desarrollo de Software
ANÁLISIS ESTRUCTURADO
Unidad 2: Análisis Estructurado de sistemas
Tecnicas del Mantenimiento del Software
3. Paradigmas de la ingeniería de software.
República Bolivariana de Venezuela Universidad Nacional Experimental Politécnica de la Fuerza Armada (UNEFA) Carrera: Ingeniería de Sistemas Cátedra: Análisis.
Licda. Noelia Gómez Gutiérrez
CICLO DE VIDA DE UN SOFTWARE. Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos asociados, que forman parte de.
Objetivos de la prueba Los objetivos principales de realizar una prueba son: Detectar un error. Tener un buen caso de prueba, es decir que tenga más probabilidad.
Presentación De UML Lenguaje estándar para escribir planos de software Se usa para visualizar, especificar, construir y documentar los artefactos de un.
La programación modular es un paradigma de programación que consiste en dividir un programa en módulos o subprogramas con el fin de hacerlo más legible.
Entregables del Proyecto
Profesor: Jesús Chaparro Bachilleres: Perez, emibeliz Prada, Rainer Villahermosa, José Abril 2014.
Instituto tecnológico superior de lerdo Sistemas de información II Diseño orientado a flujo de datos Profesor: Ing. Ricardo de Jesús Bustamante. Alumna:
Transcripción de la presentación:

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