Conceptos de diseño

13,636 views

Published on

UTN-FRT. Cátedra de Diseño de Sistemas. Unidad I. Conceptos de Diseño. 3K1 - 2011

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
13,636
On SlideShare
0
From Embeds
0
Number of Embeds
8,911
Actions
Shares
0
Downloads
137
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Conceptos de diseño

  1. 1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
  2. 2. Contenidos de la Unidad 1 Introducción al Diseño f) Ingeniería del Software Asistida por Computadora. Clasificación de CASE   Sommerville. Sección 4.5   C. Proceso de Diseño Pressman. Cap. 13.2 Introducción.   I. Fases del diseño. Pressman. Sección 13.1 Sommerville. Sección 4.3.2 II. Diseño y calidad del software Pressman. 13.2.1 III. Principios y conceptos del diseño. Pressman . Sección 13.3 y 13.4 IV. Documentación del Diseño. Pressman, Sección 13.8 V. Análisis y Diseño Orientado a Objetos Sommerville, Cap.14 Larman, 2ª. Ed., Cap. 1.4 Pressman, Cap.21 y 22 VI. Modelos de dominio, Casos de Uso. (revisión) Larman, 1ª. Ed.,Cap. 9/11 Larman, 2a. Ed. Cap. 9/11 VII. Del Análisis al Diseño Larma n, 1ª. Ed. Cap. 15 Larman, 2ª. Ed. Cap. 14
  3. 3. <ul><li>Durante las últimas cuatro décadas ha habido una evolución de los Conceptos fundamentales de Diseño de Software . </li></ul><ul><li>El grado de interés en cada concepto ha variado con los años. </li></ul><ul><li>Cada uno de ellos proporciona la base desde donde el diseñador podrá aplicar los mejores Métodos de Diseño . </li></ul><ul><li>Cada uno ayudará al Ingeniero del Software a responder a estas preguntas : </li></ul>Conceptos del Diseño (Pressman 13.4)
  4. 4. <ul><li>¿Qué criterios usamos para la partir el software en componentes individuales? </li></ul><ul><li>¿Cómo se puede separar la función y la estructura de datos de una representación conceptual del software? </li></ul><ul><li>¿Existen criterios uniformes que definen la calidad técnica de un Diseño de Software ? </li></ul>Conceptos del Diseño Preguntas que permiten responder
  5. 5. <ul><li>« 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 ». [ Jackson ] </li></ul><ul><li>Los Conceptos de Diseño de Software fundamentales proporcionan el marco de trabajo necesario para conseguir que lo haga correctamente. </li></ul>Conceptos del Diseño
  6. 6. <ul><li>« La abstracción es una de las formas fundamentales en que los hombres enfrentan a la complejidad » </li></ul><ul><li>Cuando buscamos una solución modular a cualquier problema, pueden existir varios niveles de abstracción. </li></ul><ul><li>En el nivel más alto , la solución se expone como una medida extensa, empleando el lenguaje del entorno del problema . </li></ul><ul><li>En niveles inferiores de abstracción , se toma una orientación más procedimental . </li></ul>Conceptos del Diseño La Abstracción
  7. 7. <ul><li>La terminología orientada a problemas va emparejada con la terminología orientada a la implementación en un esfuerzo por solucionar el problema . </li></ul><ul><li>En el nivel más bajo de abstracción , se establece la solución para poder implementarse directamente . </li></ul><ul><li>La noción psicológica de « abstracción » permite concentrarse en un problema a algún nivel de generalización sin tener en consideración los datos irrelevantes de bajo nivel ; </li></ul><ul><li>La abstracción permite trabajar con conceptos y términos familiares en el entorno del problema, sin tener que transformarlos en una estructura no familiar. </li></ul>Conceptos del Diseño La Abstracción
  8. 8. <ul><li>Cada paso del proceso del software es un refinamiento en el nivel de abstracción para la solución del software. </li></ul><ul><li>Durante el Análisis de los requisitos del software, la solución del software se establece en términos « familiares del entorno del problema ». </li></ul><ul><li>A medida que nos adentramos en el Diseño , se reduce el nivel de abstracción . </li></ul><ul><li>Finalmente el nivel de abstracción más bajo se alcanza cuando se genera el código fuente. </li></ul>Conceptos del Diseño La Abstracción
  9. 9. <ul><li>A medida que alcanzamos diferentes niveles de abstracción, creamos abstracciones procedimentales y de datos . </li></ul><ul><li>Abstracción procedimental => secuencia de instrucciones con una función específica y limitada. </li></ul><ul><li>Ejemplo de abstracción procedimental => « abrir » una puerta. </li></ul><ul><li>« Abrir » implica una secuencia larga de pasos procedimentales: </li></ul><ul><li>Llegar a la puerta; alcanzar y agarrar el picaporte; girarlo y tirar la puerta; separarse al mover la puerta, etc. </li></ul>Conceptos del Diseño La Abstracción
  10. 10. <ul><li>Abstracción de datos => colección de datos que describe un objeto de datos . </li></ul><ul><li>En el contexto de la abstracción procedimental abrir , hay una abstracción de datos llamada puerta . </li></ul><ul><li>La abstracción de datos para puerta son el conjunto de atributos que describen esta puerta . </li></ul><ul><li>Ejemplo => tipo de puerta, dirección de apertura, mecanismo de apertura, peso, dimensiones. </li></ul><ul><li>La abstracción procedimental abrir hace uso de la información contenida en los atributos de la abstracción de datos puerta . </li></ul>Conceptos del Diseño La Abstracción
  11. 11. <ul><li>La abstracción de control es la tercera forma de abstracción que se utiliza en el diseño del software . </li></ul><ul><li>Al igual que las abstracciones procedimentales y de datos , este tipo de abstracción implica un mecanismo de control de programa sin especificar los datos internos . </li></ul><ul><li>Un ejemplo de abstracción de control es el semáforo de sincronización que se utiliza para coordinar las actividades en un sistema operativo . </li></ul>Conceptos del Diseño La Abstracción
  12. 12. <ul><li>Consejo: </li></ul><ul><li>Como diseñador, trabaje mucho y duro para derivar a bstracciones, tanto procedimentales como de datos, que sirvan para el problema que tenga en ese momento, pero que también se puedan volver o utilizar en otras situaciones. </li></ul>Conceptos del Diseño La Abstracción
  13. 13. <ul><li>El refinamiento paso a paso es una estrategia de diseño descendente propuesta originalmente por Wirth . </li></ul><ul><li>El desarrollo de un programa se realiza refinando sucesivamente los niveles de detalle procedimentales . </li></ul><ul><li>Una jerarquía se desarrolla descomponiendo una sentencia macroscópica de función (una abstracción procedimental ) paso a paso hasta alcanzar las sentencias del lenguaje de programación. </li></ul>Conceptos del Diseño Refinamiento
  14. 14. <ul><li>Wirth brinda una visión general del Refinamiento : </li></ul><ul><li>En cada paso (del Refinamiento ), se descomponen una o varias instrucciones del programa en instrucciones más detalladas . </li></ul><ul><li>Esta descomposición sucesiva ( refinamiento de especificaciones ) termina cuando todas las instrucciones se expresan en función de cualquier lenguaje de programación . </li></ul><ul><li>Así como se refinan las tareas, los datos también se tienen que refinar , descomponer o estructurar, en paralelo con el programa. </li></ul><ul><li>Todos los pasos del refinamiento implican decisiones de diseño. </li></ul>Conceptos del Diseño Refinamiento
  15. 15. <ul><li>El Proceso de Refinamiento de Programas es similar al proceso de refinamiento y partición que se utiliza durante el Análisis . </li></ul><ul><li>La diferencia radica en el nivel de detalle de implementación que se haya tomado en consideración, no en el enfoque. </li></ul><ul><li>Consejo => Existe la tendencia de entrar en detalle inmediatamente, saltándose los pasos de refinamiento . </li></ul><ul><li>Ésto conduce a errores y omisiones y hace que el diseño sea más difícil de revisar . </li></ul><ul><li>Realice el refinamiento paso a paso . </li></ul>Conceptos del Diseño Refinamiento
  16. 16. <ul><li>El Refinamiento es un proceso de Elaboración . </li></ul><ul><li>Se comienza con una sentencia de función que se define a un nivel alto de abstracción . </li></ul><ul><li>Esta sentencia describe la función conceptualmente , pero no proporciona información sobre su funcionamiento interno . </li></ul><ul><li>El refinamiento hace que el diseñador trabaje sobre la sentencia original , proporcionando cada vez más detalles a medida que van teniendo lugar sucesivamente todos y cada uno de los refinamientos ( Elaboración ). </li></ul>Conceptos del Diseño Refinamiento
  17. 17. <ul><li>El software se divide en componentes que se abordan por separado , llamados Módulos , que se integran para satisfacer los requisitos del problema . </li></ul><ul><li>Modularidad => Único atributo del software que permite gestionar un programa intelectualmente . </li></ul><ul><li>El software monolítico (programa grande formado por un Único módulo) no puede ser entendido fácilmente . </li></ul><ul><li>La cantidad de rutas de control, la amplitud de referencias, la cantidad de variables y la complejidad global lo hará difícil de entender . </li></ul>Conceptos del Diseño Modularidad
  18. 18. <ul><li>Esto es obvio: Se tarda más en resolver un problema difícil . </li></ul><ul><li>Esto lleva a una conclusión: « divide y vencerás » es más fácil resolver un problema complejo cuando se rompe en piezas manejables . </li></ul><ul><li>Consejo => No modularice de más . La simplicidad de cada módulo se eclipsará con la complejidad de la integración . </li></ul>Conceptos del Diseño Modularidad
  19. 19. <ul><li>El esfuerzo ( costo ) para desarrollar un módulo individual disminuye a medida que aumenta el número total de módulos . </li></ul><ul><li>Con los mismos requisitos, tener más módulos conduce a un tamaño menor de cada módulo . </li></ul><ul><li>Sin embargo, a medida que aumenta el número de módulos, también crece el esfuerzo (costo) asociado con la integración de módulos . </li></ul>Conceptos del Diseño Modularidad
  20. 20. <ul><li>¿Cómo se define un módulo con un tamaño adecuado? </li></ul><ul><li>La respuesta se encuentra en los métodos utilizados para definir los módulos dentro de un sistema. </li></ul><ul><li>Hay 5 criterios que ayudan a definir un sistema modular efectivo: </li></ul>Conceptos del Diseño Modularidad
  21. 21. <ul><li>Capacidad de descomposición modular . </li></ul><ul><li>Si un Método de Diseño proporciona un mecanismo sistemático para descomponer el problema en subproblemas , reducirá la complejidad de todo el problema, consiguiendo así una solución modular efectiva. </li></ul><ul><li>Capacidad de empleo de componentes modulares . </li></ul><ul><li>Si un Método de Diseño permite ensamblar los componentes de diseño (reusables) existentes en un sistema nuevo , producirá una solución modular que no inventa nada ya inventado . </li></ul>Conceptos del Diseño Criterios para definir Modularidad
  22. 22. <ul><li>Capacidad de comprensión modular . </li></ul><ul><li>Si un módulo se puede comprender como una unidad autónoma (sin referencias a otros módulos ) será más fácil de construir y de cambiar . </li></ul><ul><li>Continuidad modular . </li></ul><ul><li>Si pequeños cambios en los requisitos del sistema provocan cambios en los módulos individuales, en vez de cambios generalizados en el sistema, se minimizará el impacto de los efectos secundarios de los cambios . </li></ul>Conceptos del Diseño Criterios para definir Modularidad
  23. 23. <ul><li>Protección modular . </li></ul><ul><li>Si dentro de un módulo se produce una condición aberrante y sus efectos se limitan a ese módulo , se minimizará el impacto de los efectos secundarios inducidos por los errores . </li></ul>Conceptos del Diseño Criterios para definir Modularidad
  24. 24. <ul><li>Un Sistema se puede diseñar modularmente, aunque su implementación sea «monolítica». </li></ul><ul><li>=> El Software puede diseñarse modularmente . </li></ul><ul><li>El código se puede desarrollar «en línea». </li></ul><ul><li>Aunque el código fuente del programa puede no tener un aspecto modular a primera vista, se ha mantenido la filosofía y el programa proporcionará los beneficios de un sistema modular. </li></ul>Conceptos del Diseño Modularidad: Corolario
  25. 25. <ul><li>Arquitectura del Software => « Estructura Global del Software y a las formas en que esa Estructura proporciona la integridad conceptual de un sistema ». </li></ul><ul><li>Es la estructura jerárquica de los componentes del programa (módulos) , la manera en que los componentes interactúan y la estructura de datos que van a utilizar los componentes . </li></ul><ul><li>« Componentes » => representan los elementos principales del sistema y sus interacciones . </li></ul>Conceptos del Diseño Arquitectura del Software
  26. 26. <ul><li>Objetivo del Diseño del Software => derivar una representación arquitectónica de un sistema. </li></ul><ul><li>Esta representación sirve como marco de trabajo desde donde se llevan a cabo actividades de diseño más detalladas . </li></ul><ul><li>Un conjunto de patrones arquitectónicos permiten que el ingeniero del software reutilice los concepto s a nivel de diseño. </li></ul>Conceptos del Diseño Arquitectura del Software
  27. 27. <ul><li>Propiedades que deben especificarse en el D iseño Arquitectónico : </li></ul><ul><li>Propiedades Estructurales : Definen los componentes de un sistema (módulos, objetos, filtros) y la manera en que éstos se empaquetan e interactúan unos con otros. </li></ul><ul><li>Por ejemplo, los objetos se empaquetan para encapsular: los datos y el procesamiento que manipula los datos e interactúan mediante la invocación de métodos . </li></ul>Conceptos del Diseño Arquitectura del Software
  28. 28. <ul><li>Propiedades Extra-Funcionales : </li></ul><ul><li>El Diseño Arquitectónico debe ocuparse de lograr los requisitos de rendimiento , capacidad , fiabilidad , seguridad , capacidad de adaptación y otras características del sistema. </li></ul><ul><li>Familias de sistemas relacionados . </li></ul><ul><li>El D iseño Arquitectónico se dibuja sobre patrones repetibles basados en diseños de familias de sistemas similares . </li></ul><ul><li>El diseño debe reutilizar los bloques de construcción arquitectónicos . </li></ul>Conceptos del Diseño Arquitectura del Software
  29. 29. <ul><li>El D iseño Arquitectónico se puede representar mediante 5 tipos distintos de modelos : </li></ul><ul><li>Modelos Estructurales => representan la arquitectura como una colección organizada de componentes de programa. </li></ul><ul><li>Modelos de Marco de Trabajo => aumentan el nivel de abstracción del diseño. Identifican los marcos de trabajo ( Patrones ) repetibles en tipos similares de aplicaciones. </li></ul>Conceptos del Diseño Arquitectura del Software
  30. 30. <ul><li>M odelos Dinámicos => tratan sobre el Comportamiento de la Arquitectura . Indican cómo puede cambiar la estructura del sistema en función de los acontecimientos externos. </li></ul><ul><li>Modelos de Proceso => se centran en el diseño del proceso técnico de negocios al cual tiene que adaptar el sistema. </li></ul><ul><li>Modelos Funcionales => se utilizan para representar la jerarquía funcional de un sistema. </li></ul>Conceptos del Diseño Arquitectura del Software
  31. 31. <ul><li>La Jerarquía de Control , llamada « estructura de programa », representa la organización de los componentes de programa (módulos) e implica una jerarquía de control . </li></ul><ul><li>El diagrama más común es el de forma de árbol , que representa el control jerárquico para las arquitecturas de llamada y de retorno . </li></ul>Conceptos del Diseño Jerarquía de Control
  32. 32. <ul><li>Según la Figura siguiente, la profundidad y el ancho indican la cantidad de niveles de control y el ámbito de control global , respectivamente. </li></ul><ul><li>El grado de salida mide el número de módulos que son controlados directamente por otro módulo. </li></ul><ul><li>El grado de entrada indica la cantidad de módulos que controlan directamente a un módulo dado . </li></ul><ul><li>La relación de control entre los módulos se expresa así: un módulo que controla a otro módulo es superior a éste, e inversamente, un módulo controlado por otro es subordinado del controlador . </li></ul>Conceptos del Diseño Jerarquía de Control
  33. 33. Conceptos del Diseño Jerarquía de Control
  34. 34. <ul><li>Si el estilo arquitectónico de un sistema es jerárquico, la estructura del programa se puede dividir tanto horizontal como verticalmente. </li></ul><ul><li>El enfoque más simple de la división horizontal define tres particiones -entrada, transformación de datos (procesamiento) y salida-. </li></ul><ul><li>La división horizontal de la arquitectura proporciona ventajas: </li></ul><ul><li>Software más fácil de probar. </li></ul><ul><li>Software más fácil de mantener </li></ul><ul><li>Propaga menos efectos secundarios </li></ul><ul><li>Software más fácil de ampliar </li></ul>Conceptos del Diseño División Estructural
  35. 35. <ul><li>Como las funciones principales se desacoplan unas de otras, el cambio tiende a ser menos complejo y la extensión del sistema es más fácil de llevar, sin efectos secundarios. </li></ul><ul><li>Desventaja de la división horizontal: Los datos pasan a través de interfaces de módulos que pueden complicar el control global del flujo del programa. </li></ul>Conceptos del Diseño División Estructural
  36. 36. <ul><li>La División Vertical o Factorización ( Factoring ) sugiere que la estructura de control ( toma de decisiones ) y el trabajo se distribuyan de manera descendente . </li></ul><ul><li>Los módulos superiores harán funciones de control y no trabajo de procesamiento. </li></ul><ul><li>Los módulos inferiores deberán ser los trabajadores => a cargo de todas las tareas de entrada, proceso y salida. </li></ul>Conceptos del Diseño División Estructural
  37. 37. <ul><li>Un cambio en un Módulo de Control (parte superior de la estructura) tiene mayor probabilidad de propagar efectos secundarios a sus módulos subordinados. </li></ul><ul><li>Un cambio en un módulo trabajador, por su nivel bajo en la estructura, es menos probable que propague efectos secundarios. </li></ul><ul><li>El comportamiento básico de un programa es menos probable que cambie. </li></ul><ul><li>Por eso, las estructuras con división vertical son menos susceptibles a efectos secundarios cuando hay cambios y se pueden mantener mejor -un factor de calidad clave-. </li></ul>Conceptos del Diseño División Estructural
  38. 38. <ul><li>Consejo => los módulos-trabajador tienden a cambiar de forma más frecuente que los módulos de control. </li></ul><ul><li>Si se colocan en la parte inferior de la estructura, se reducen los efectos secundarios (originados por el cambio). </li></ul>Conceptos del Diseño División Estructural
  39. 39. <ul><li>La Estructura de Datos es una representación de la relación lógica entre elementos individuales de datos. </li></ul><ul><li>Como la estructura de la información afectará invariablemente al diseño procedimental final, la estructura de datos es tan importante como la estructura de programa para la representación de la arquitectura del software. </li></ul>Conceptos del Diseño Estructura de Datos
  40. 40. <ul><li>Elemento escalar => Estructura de Datos más simple . </li></ul><ul><li>Representa un solo elemento de información que puede ser tratado por un identificador => se puede acceder a él especificando un sola dirección en memoria . </li></ul><ul><li>El tamaño y formato de un elemento escalar puede variar. </li></ul><ul><li>Por ejemplo: una entidad lógica de un bit de tamaño ; un entero o número de coma flotante con un tamaño de 8 a 64 bits ; una cadena de caracteres de cientos o miles de bytes . </li></ul>Conceptos del Diseño Estructura de Datos
  41. 41. <ul><li>Cuando los elementos escalares se organizan como una lista o grupo contiguo , se forma un vector secuencia . </li></ul><ul><li>Los vectores son las estructuras de datos más comunes y abren la puerta a la indexación variable de la información . </li></ul><ul><li>Cuando el vector secuencial se amplía a dos, tres o un número arbitrario de dimensiones, se crea un espacio n-dimensional . </li></ul><ul><li>El espacio n-dimensional más común es la matriz bidimensional ( array ). </li></ul>Conceptos del Diseño Estructura de Datos
  42. 42. <ul><li>Los elementos , vectores y espacios ( nodos ) pueden estar organizados en diversos formatos. </li></ul><ul><li>Una lista enlazada es una estructura de datos que organiza elementos escalares , vectores o espacios ( nodos ) no contiguos y les permite ser procesados como una lista . </li></ul><ul><li>Cada nodo contiene la organización de datos y un puntero o más, que indican la dirección de almacenamiento del siguiente nodo de la lista . </li></ul><ul><li>Se pueden añadir nodos en cualquier punto de la lista . </li></ul>Conceptos del Diseño Estructura de Datos
  43. 43. <ul><li>Otras estructuras de datos incorporan o construyen con las estructuras de datos fundamentales descriptas. </li></ul><ul><li>Por ejemplo, una estructura de datos jerárquica se implementa con listas mul tienlazadas , que contienen elementos escalares , vectores y espacios n-dimensionales . </li></ul><ul><li>Consejo : lnvierta todo el tiempo necesario para diseñar estructuras de datos (el mismo invertido en diseñar algoritmos). Ello ahorra, a la larga, mucho tiempo . </li></ul>Conceptos del Diseño Estructura de Datos
  44. 44. <ul><li>El Procedimiento de Software se centra en el Procesamiento de cada módulo individualmente . </li></ul><ul><li>El Procedimiento debe brindar una especificación precisa de procesamiento , incluyendo la secuencia de sucesos , los puntos de decisión , las operaciones repetitivas y la estructura/organización de datos . </li></ul><ul><li>Hay, una relación entre la Estructura y el Procedimiento . </li></ul><ul><li>El Procesamiento de cada módulo debe incluir una referencia a todos los módulos subordinados a él. </li></ul><ul><li>=> La Representación Procedimental del Software se distribuye en capas . </li></ul>Conceptos del Diseño Procedimiento de Software
  45. 45. <ul><li>La « Modularidad » nos conduce a esta pregunta: </li></ul><ul><li>« ¿Cómo se puede descomponer un software para obtener el mejor conjunto de módulos? » </li></ul><ul><li>El principio de ocultación de información sugiere que los módulos se caracterizan por las decisiones de diseño que (cada uno) oculta al otro. </li></ul><ul><li>=> Los módulos deben diseñarse para que su información ( procedimiento y datos ) interna sea inaccesible a otros módulos que no necesiten esa información . </li></ul>Conceptos del Diseño Ocultación de la Información
  46. 46. <ul><li>Ocultación => permite una modularidad efectiva definiendo un conjunto de módulos independientes que se comunican entre sí intercambiando sólo la información necesaria para lograr la función del software . </li></ul><ul><li>La abstracción ayuda a la ocultación . </li></ul>Conceptos del Diseño Ocultación de la Información

×