Etapas del diseño MSc. Alexis Cabrera Mondeja. Flujo de la Información La información se transforma a medida que fluye por un sistema basado en computadora.

Presentación del tema: "Etapas del diseño MSc. Alexis Cabrera Mondeja. Flujo de la Información La información se transforma a medida que fluye por un sistema basado en computadora."— Transcripción de la presentación:

1 Etapas del diseño MSc. Alexis Cabrera Mondeja

2 Flujo de la Información La información se transforma a medida que fluye por un sistema basado en computadora. El sistema acepta entradas en una gran variedad de formas; aplica elementos de hardware, software y humanos para transformar la entrada en salida, y produce salida en una gran variedad de formas. La entrada puede ser una señal de control transmitida por un controlador, una serie de números escritos por un enlace de una red o un archivo voluminoso de datos recuperado de un almacenamiento secundario.

3 La transformación puede ser, desde una sencilla comparación lógica, hasta un complejo algoritmo numérico o un mecanismo de reglas de inferencia de un sistema experto. La salida puede ser el encendido de un diodo de emisión de luz (LED) o un informe de 200 páginas. Efectivamente, podemos crear un modelo de flujo para cualquier sistema de computadora, independientemente del tamaño y de la complejidad.

4 Modelo del Flujo de Información Entidad externa Proceso n°3 Entidad externa Proceso n°4 Proceso n°2 Proceso n°1 Información de entrada Datos Intermedios Información de entrada Información de salida Almacenamiento Entrada de Almacenamiento Salida de Almacenamiento

5 Análisis del flujo de Información El análisis estructurado es una técnica del modelado del flujo y del contenido de la información. Tal como muestra la Figura anterior, el sistema basado en computadora se representa como una transformación de información. Se utiliza un rectángulo para representar una entidad externa, esto es, un elemento del sistema (por ejemplo, un elemento hardware, una persona, otro programa) u otro sistema que produce información para ser transformada por el software, o recibe información producida por el software.

6 Un círculo (también llamado burbuja) representa un proceso o transformación que es aplicado a los datos (o al control) y los modifica. Una flecha representa uno o más elementos de datos (objetos de dato). Toda flecha en un diagrama de flujos de datos debe estar etiquetada. Las líneas en paralelo representan un almacenamiento - información almacenada que es utilizada por el software-. La simplicidad de la notación del DFD es una razón por la que las técnicas del análisis estructurado son ampliamente utilizadas. El DFD no es procedimental. No permite representar con su notación gráfica tratamientos condicionales ni bucles. Simplemente muestro el flujo de datos.

7 Diagramas de flujo de datos A medida que la información se mueve a través del software, es modificada por una serie de transformaciones. El diagrama de flujo de datos (DFD) es una técnica que representa el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida. En la Figura mostrada anteriormente se observa la forma básica de un diagrama de flujo de datos. El DFD es también conocido como grafo de flujo de datos o como diagrama de burbujas.

8 CLAVE El DFD facilita un mecanismo para modelar el flujo de información y modelar las funciones. Se puede usar el diagrama de flujo de datos para representar un sistema o un software a cualquier nivel de abstracción. De hecho, los DFDs pueden ser divididos en niveles que representen un mayor flujo de información y un mayor detalle funcional. Por consiguiente, el DFD proporciona un mecanismo para el modelado funcional, así como el modelado del flujo de información. Al hacer esto, se cumple el segundo principio de análisis operacional (esto es, crear un modelo funcional).

9 Modelos de DFD Un DFD de nivel O, también denominado modelo fundamental del sistema o modelo de contexto, representa al elemento de software completo como una sola burbuja con datos de entrada y de salida representados por flechas de entrada y de salida, respectivamente. Al dividir el DFD de nivel O para mostrar más detalles, aparecen representados procesos (burbujas) y caminos de flujo de información adicionales.

10 Refinamiento del flujo de información F1 F3 F4 F2 F6 F7 F5 F41 F43 F42 F44 F45 F F A B A V X W Y Z z1 z2 z3 B X Y x1 y1 x2 y2 Z

11 La notación básica que se usa para desarrollar un DFD no es en sí misma suficiente para describir los requisitos del software. Por ejemplo, una flecha de un DFD representa un objeto de datos que entra o sale de un proceso. Un almacén de datos representa alguna colección organizada de datos. La notación gráfica debe ser ampliada con texto descriptivo. Se puede usar una especificación de proceso (EP) para especificar los detalles de procesamiento que implica una burbuja del DFD.

12 Además, la especificación de proceso indica las restricciones y limitaciones impuestas al proceso (función), las características de rendimiento que son relevantes al proceso y las restricciones de diseño que puedan tener influencia en la forma de implementar el proceso.

13 Ampliaciones para sistemas de tiempo real Muchas aplicaciones de software son dependientes del tiempo y procesan más información orientada al control de datos. Un sistema de tiempo real debe interactuar con el mundo real en marcos temporales que vienen dados por el mundo real. El control de naves o de procesos de fabricación, los productos de consumo y la instrumentación industrial son algunas de entre cientos de aplicaciones del software de tiempo real. Para que resulte adecuado el análisis del software de tiempo real, se han propuesto varias ampliaciones para la notación básica del análisis estructurado.

14 CONCEPTOS Y PRINCIPIOS DE DISEÑO EL objetivo de los diseñadores es producir un modelo o representación de una entidad que será construida a posteriori. Belady describe el proceso mediante el cual se desarrolla el modelo de diseño [BEL81]:

15 En cualquier proceso de diseño existen dos fases importantes: la diversificación y la convergencia. La diversificación es la adquisición de un repertorio de alternativas, de un material primitivo de diseño: componentes, soluciones de componentes y conocimiento, todo dentro de catálogos, de libros de texto y en la mente. Durante la convergencia, el diseñador elige y combina los elementos adecuados y extraídos de este repertorio para satisfacer los objetivos del diseño, de la misma manera a como se establece en el documento de los requisitos, y de la manera en que se acordó con el cliente. La segunda fase es la eliminación gradual de cualquier configuración de componentes excepto de una en particular, y de aquí la creación del producto final.

16 DISEÑO DEL SOFTWARE El diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se aplica independientemente del modelo de diseño de software que se utilice. Una vez que se analizan y especifican los requisitos del software, el diseño del software es la primera de las tres actividades técnicas -diseño, generación de código y pruebas- que se requieren para construir y verificar el software. Cada actividad transforma la información de manera que dé lugar por último a un software de computadora validado.

17 Cada uno de los elementos del modelo de análisis, visto anteriormente en clases, proporciona la información necesaria para crear los cuatro modelos de diseño que se requieren para una especificación completa de diseño. Mediante uno de los muchos métodos de diseño la tarea de diseño produce un diseño de datos, un diseño arquitectónico, un diseño de interfaz y un diseño de componentes. El diseño de datos transforma el modelo del dominio de información que se crea durante el análisis en las estructuras de datos que se necesitarán para implementar el software.

18 Diseño de datos Los objetos de datos y las relaciones definidas en el diagrama relación entidad y el contenido de datos detallado que se representa en el diccionario de datos proporcionan la base de la actividad del diseño de datos. Es posible que parte del diseño de datos tenga lugar junto con el diseño de la arquitectura del software. A medida que se van diseñando cada uno de los componentes del software, van apareciendo más detalles de diseño.

19 Diseño Arquitectónico El diseño arquitectónico define la relación entre los elementos estructurales principales del software, los patrones de diseño que se pueden utilizar para lograr los requisitos que se han definido para el sistema, y las restricciones que afectan a la manera en que se pueden aplicar los patrones de diseño arquitectónicos. La representación del diseño arquitectónico puede derivarse de la especificación del sistema, del modelo de análisis y de la interacción del subsistema definido dentro del modelo de análisis.

20 Diseño de la interfaz El diseño de la interfaz describe la manera de comunicarse el software dentro de sí mismo, con sistemas que inter-operan dentro de él y con las personas que lo utilizan. Una interfaz implica un flujo de información (por ejemplo, datos y/o control) y un tipo específico de comportamiento. Por tanto, los diagramas de flujo de control y de datos proporcionan gran parte de la información que se requiere para el diseño de la interfaz.

21 Diseño a nivel de componentes El diseño a nivel de componentes transforma los elementos estructurales de la arquitectura del software en una descripción procedimental de los componentes del software. La información que se obtiene de los procesos anteriores sirve como base para el diseño de los componentes. calidad La importancia del diseño del software se puede describir con una sola palabra -calidad-. El diseño es el lugar en donde se fomentará la calidad en la ingeniería del software.

22 Importancia del diseño El diseño proporciona las representaciones del software que se pueden evaluar en cuanto a calidad. El diseño es la única forma de convertir exactamente los requisitos de un cliente en un producto o sistema de software finalizado. El diseño del software sirve como fundamento para todos los pasos siguientes del soporte del software y de la ingeniería del software. Sin un diseño, corremos el riesgo de construir: un sistema inestable -un sistema que fallará cuando se lleven a cabo cambios; un sistema que puede resultar difícil de comprobar; y un sistema cuya calidad no puede evaluarse hasta muy avanzado el proceso, sin tiempo suficiente y con mucho dinero gastado en él-.

23 El Proceso de diseño El diseño del software es un proceso iterativo mediante el cual los requisitos se traducen en un «plano» para construir el software. Inicialmente, el plano representa una visión holística del software. Esto es, el diseño se representa a un nivel alto de abstracción -un nivel que puede rastrearse directamente hasta conseguir el objetivo del sistema específico y según unos requisitos más detallados de comportamiento, funcionales y de datos-. A medida que ocurren las iteraciones del diseño, el refinamiento subsiguiente conduce a representaciones de diseño a niveles de abstracción mucho más bajos.

24 Diseño y calidad del software Características de un buen diseño: El diseño deberá implementar todos los requisitos explícitos del modelo de análisis, y deberán ajustarse a todos los requisitos implícitos que desea el cliente; El diseño deberá ser una guía legible y comprensible para aquellos que generan código y para aquellos que comprueban y consecuentemente, dan soporte al software; El diseño deberá proporcionar una imagen completa del software, enfrentándose a los dominios de comportamiento, funcionales y de datos desde una perspectiva de implementación.

25 Con el fin de evaluar la calidad de una representación de diseño, deberán establecerse los criterios técnicos para un buen diseño: 1. Un diseño deberá presentar una estructura arquitectónica que (1) se haya creado mediante Patrones de diseño reconocibles, (2) que esté formada Por componentes que exhiban características de buen diseño (aquellas que se abordarán más adelante en este mismo capítulo), Y (3) que se Puedan implementar de manera evolutiva, facilitando así la implementación Y la comprobación.

26 2. Un diseño deberá ser modular; esto es, el software deberá dividirse lógicamente en elementos que realicen funciones y subfunciones específicas. 3. Un diseño deberá contener distintas representaciones de datos, arquitectura, interfaces y componentes (módulos). 4. Un diseño deberá conducir a estructuras de datos adecuadas para los objetos que se van a implementar y que procedan de patrones de datos reconocibles.

27 5. un diseño deberá conducir a componentes que presenten características funcionales diferentes. 6. Un diseño deberá conducir a interfaces que reduzcan la complejidad de las conexiones entre los módulos y con el entorno externo. 7. un diseño deberá derivarse mediante un método repetitivo y controlado por la información obtenida durante el análisis de los requisitos del software.

28 La evolución del diseño del software La evolución del diseño del software es un proceso continuo que ha abarcado las últimas cuatro décadas. El primer trabajo de diseño se concentraba en criterios para el desarrollo de programas modulares y métodos para refinar las estructuras del software de manera descendente.

29 Independientemente del modelo de diseño que se utilice, un ingeniero del software deberá aplicar un conjunto de principios fundamentales y conceptos básicos para el diseño a nivel de componentes, de interfaz, arquitectónico y de datos. Estos principios y conceptos se estudian en la sección siguiente.

30 Principios del diseño El diseño de software es tanto un proceso como un modelo. El proceso de diseño es una secuencia de pasos que hacen posible que el diseñador describa todas los aspectos del software que se va construir. Sin embargo, es importante destacar que el proceso de diseño simplemente no es un recetario. Un conocimiento creativo, experiencia en el tema, un sentido de lo que hace que un software sea bueno, y un compromiso general con la calidad son factores críticos de éxito para un diseño competente.

31 Modelo de diseño El modelo de diseño es el equivalente a los planes de un arquitecto para una casa. Comienza representando la totalidad de todo lo que se va a construir (por ejemplo, una representación en tres dimensiones de la casa) y refina lentamente lo que va a proporcionar la guía para construir cada detalle (por ejemplo, el diseño de fontanería). De manera similar, el modelo de diseño que se crea para el software proporciona diversas visiones diferentes de software de computadora.

32 Los principios básicos de diseño hacen posible que el ingeniero del software navegue por el proceso de diseño. Davis [DAV95] sugiere un conjunto de principios para el diseño del software, los cuales han sido adaptados y ampliados en la lista siguiente:  En el proceso de diseño no deberá utilizarse «orejeras». Un buen diseñador deberá tener en cuenta enfoques alternativos, juzgando todos los que se basan en los requisitos del problema, los recursos disponibles para realizar el trabajo y los conceptos de diseño.

33  El diseño deberá poderse rastrear hasta el modelo de análisis. Dado que un solo elemento del modelo de diseño suele hacer un seguimiento de los múltiples requisitos, es necesario tener un medio de rastrear cómo se han satisfecho los requisitos por el modelo de diseño.

34  El diseño no deberá inventar nada que ya esté inventado. Los sistemas se construyen utilizando un conjunto de patrones de diseño, muchos de los cuales probablemente ya se han encontrado antes. Estos patrones deberán elegirse siempre como una alternativa para reinventar. Hay poco tiempo y los recursos son limitados. El tiempo de diseño se deberá invertir en la representación verdadera de ideas nuevas y en la integración de esos patrones que ya existen.

35  El diseño deberá «minimizar la distancia intelectual » [DAV95] entre el software y el problema como si de la misma vida real se tratara. Es decir, la estructura del diseño del software (siempre que sea posible) imita la estructura del dominio del problema.  El diseño deberá presentar uniformidad e integración. Un diseño es uniforme si parece que fue una persona la que lo desarrolló por completo. Las reglas de estilo y de formato deberán definirse para un equipo de diseño antes de comenzar el trabajo sobre el diseño. Un diseño se integra si se tiene cuidado a la hora de definir interfaces entre los componentes del diseño.

36  El diseño deberá estructurarse para admitir cambios. Los conceptos de diseño estudiados en la sección siguiente hacen posible un diseño que logra este principio.  El diseño deberá estructurarse para degradarse poco a poco, incluso cuando se enfrenta con datos, sucesos o condiciones de operación aberrantes. Un software bien diseñado no deberá nunca explotar como una <<bomba»D. eberá diseñarse para adaptarse a circunstancias inusuales, y si debe terminar de funcionar, que lo haga de forma suave.

37  El diseño no es escribir código y escribir código no es diseñar. Incluso cuando se crean diseños procedimentales para componentes de programas, el nivel de abstracción del modelo de diseño es mayor que el código fuente. Las únicas decisiones de diseño realizadas a nivel de codificación se enfrentan con pequeños datos de implementación que posibilitan codificar el diseño procedimental. La consistencia del diseño y la uniformidad es crucial cuando se van a construir sistemas grandes. Se deben establecer un conjunto de reglas de diseño para el equipo del software antes de comenzar a trabajar.

38  El diseño deberá evaluarse en función de la calidad mientras se va creando, no después de terminarlo.  El diseño deberá revisarse para minimizar los errores conceptuales (semánticos). A veces existe la tendencia de centrarse en minucias cuando se revisa el diseño, olvidándose del bosque por culpa de los árboles. Un equipo de diseñadores deberá asegurarse de haber afrontado los elementos conceptuales principales antes de preocuparse por la sintaxis del modelo del diseño.

39 Conceptos del Diseño Durante las últimas cuatro décadas se ha experimentado la evolución de un conjunto de conceptos fundamentales de diseño de software. Aunque el grado de interés en cada concepto ha variado con los años, todos han experimentado el paso del tiempo. Cada uno de ellos proporcionarán la base de donde el diseñador podrá aplicar los métodos de diseño más sofisticados.

40  Cada uno ayudará al ingeniero del software a responder las preguntas siguientes: ¿Qué criterios se podrán utilizar para la partición del software en componentes individuales? ¿Cómo se puede separar la función y la estructura de datos de una representación conceptual del software? ¿Existen criterios uniformes que definen la calidad técnica de un diseño de software?

41 «El comienzo de la sabiduría para un ingeniero del software es reconocer la diferencia entre hacer que un programa funcione y conseguir que lo haga correctamente».

42 Conceptos del Diseño  Abstracción  Refinamiento  Modularidad  Arquitectura del software  Jerarquía de control  División estructural  Estructura de datos  Procedimiento de software  Ocultación de información Página 262- Roger Pressman