Técnicas Generales de Diseño Software

2 DESCOMPOSICIÓN MODULAR Los pasos a seguir son: Identificar los módulos Describir cada módulo Describir las relaciones entre módulos Tipos de módulos: Código fuente, en el lenguaje de programación usado Tabla de datos, para datos de inicialización u otros Configuración, se agrupa en un módulo toda la información de configuración en el entorno de trabajo Otros: ficheros de ayuda en línea, manuales, etc. Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda considerar suficientemente válida Independencia fucional Acoplamiento Cohesión Comprensibilidad Adaptabilidad

3 DESCOMPOSICIÓN MODULAR: INDEPENDENCIA FUNCIONAL Al final de los documentos ADD y DDD debe haber una matriz REQUISITOS/COMPONNETES. En principio, cada función será realizada en un módulo distinto. Si las funciones son independientes los módulos tendrán independencia funcional. Cada módulo debe realizar una función concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre módulos al mínimo. Para medir la independencia funcional hay dos criterios: acoplamiento y cohesión. DESCOMPOSICIÓN MODULAR: ACOPLAMIENTO El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y la complejidad de la interfase: FUERTE, POR CONTENIDO, cuando desde un módulo se pueden cambiar datos locales de otro COMÚN, se emplea una zona común de datos a la que tienen acceso varios módulos MODERADO, DE CONTROL, la zona común es un dispositivo externo al que están ligados los módulos, esto implica que un cambio en el formato de datos afecta a todos estos módulos POR ETIQUETA, en ontercambio de datos se realiza mediante una referencia a la estructura completa de datos (vector, pila, árbol, grafo, …) DÉBIL, DE DATOS, viene dado por los datos que intercambian los módulos. Es el mejor posible SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe

4 DESCOMPOSICIÓN MODULAR: COHESIÓN Es necesario lograr que el contenido de cada módulo tenga la máxima coherencia. Para que el nº de módulos no sea demasiado elevado y complique el diseño se tratan de agrupar elementos afines y relacionados en un mismo módulo. ALTA COHESIÓN ABSTRACCIONAL, se logra cuando se diseña el módulo como tipo abstracto de datos o como una clase de objetos COHESIÓN FUNCIONAL, el módulo realiza una función concreta y específica MEDIA COHESIÓN SECUENCIAL, los elementos del módulo trabajan de forma secuencial COHESIÓN DE COMUNICACIÓN, elementos que operan con le mismo conjunto de datos de entrada o de salida COHESIÓN TEMPORAL, se agrupan elementos que se ejecutan en el mismo momento. Ej. Arrancar o parar dispositivos BAJA COHESIÓN LÓGICA, se agrupan elementos que realizan funciones similares. Ejs.: módulos de E/S o de tratamiento de errores COHESIÓN COINCIDENTAL, es la peor y se produce cuando los elementos de un módulo no guardan relación alguna La descripción del comportamiento de un módulo permite establecer el grado de cohesión: Si es una frase compuesta y contiene más de un verbo la cohesión será MEDIA Si contiene expresiones secuenciales (primero, entonces, cuando…), será temporal o secuencial Si la descripción no se refiere a algo específico (Ej. Todos los errores), cohesión lógica Si aparece “inicializar”, “preparar”, “configurar”, probablemente sea temporal.

5 DESCOMPOSICIÓN MODULAR: COMPRENSIBILIDAD Para facilitar los cambios, el mantenimiento y la reutilización de módulos es necesario que cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero además es deseable: IDENTIFICACIÓN, el nombre debe ser adecuado y descriptivo DOCUMENTACIÓN, debe aclarar todos los detalles de diseño e implementación que no queden de manifiesto en el propio código SIMPLICIDAD, las soluciones sencillas son siempre las mejores La adaptación de un sistema resulta más dificil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseño es poco comprensible. Otros factores para facilitar la adaptabilidad: PREVISIÓN, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en módulos independientes, de manera que su modificación afecte al menor número de módulos posible ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de especificación, diseño, e implementación para obtener un conocimiento suficiente del sistema antes de proceder a su adaptación CONSISTENCIA, después de cualquier adaptación se debe mantener la consistencia del sistema, incluidos los documentos afectados DESCOMPOSICIÓN MODULAR: ADAPTABILIDAD

6 TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE La descomposición del sistema se hace desde un punto de vista funcional. Desde el punto de vista de la codificación, cada módulo corresponde esencialmente a un subprograma. TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE: DESARROLLO POR REFINAMIENTO PROGRESIVO Esta técnica consiste en la aplicación de la fase de diseño de la programación estructurada. Las estructuras básicas son la secuencia, la selección entre alternativas y la iteración. Cada paso en la descomposición consiste en refinar o detallar una parte del programa global u operación, que a su vez podrá ser descompuesta en otras operaciones. Los refinamientos se basan en la aplicación de estructuras de control en el programa. Veamos como ejemplo “obtener las raíces de una ec. de 2º grado”: Obtener raíces -> Leer coeficientes Resolver ecuación –> Calcular discriminante Calcular raíces –> SI el discriminante es negativo ENTONCES Calcular raíces complejas SI-NO Calcular raíces reales FIN-SI Imprimir raíces

7 TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE: PROGRAMACIÓN ESTRUCTURADA DE JACKSON Esta técnica sigue las ideas de la programación estructurada (secuencia, selección, iteración) y el método de refinamientos sucesivos pàra construir la estructura del programa en forma descendente. Se recomienda construir la estructura del programa de forma similar a las estructuras de datos de entrada y de salida Pasos de la técnica JSP: Analizar el entorno del problema y describir las estructuras de datos a procesar Construir la estructura del programa basándose en las estructuras de datos Definir las tareas a realizar en cada módulo de la estructura del programa Este tercer paso corresponde en su detalle a la fase de codificación Ej.: Programa para justificar el texto, es decir, reagrupar las palabras en líneas e intercalar los espacios adecuados para que se ajusten a los márgenes PASO 1. Las estructuras de datos que reconocemos son Texto de entrada = {[separador de párrafo | palabra]} Texto de salida = {[línea ajustada | línea final | línea en blanco]}

8 TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE: PROGRAMACIÓN ESTRUCTURADA DE JACKSON En el PASO 2 se trata de encontrar una estructura del programa que se ajuste a las estructuras de los datos de entrada y salida

9 TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE: DISEÑO ESTRUCTURADO Según esta técnica, la tarea de diseño consiste en pasar de los DFDs a los diagramas de estructura. Hay que establecer una jerarquía o estructura de control entre los diferentes módulos, que no está implícita en el modelo funcional descrito en los DFDs Para dos módulos relacionados en el DFD (A) tenemos 3 posibilidades de organización modular diferentes.

10 TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE: DISEÑO ESTRUCTURADO Para establecer la jerarquía de control entre módulos se recomienda hacer ciertos análisis en el flujo de datos: de flujo de transformación y de flujo de transacción. Para ello es recomendable construir un DFD con todos los procesos contenidos en los primeros niveles prescindiendo de los almacenes. El análisis de flujo de transformación consiste en identificar un flujo global de información desde los elementos de entrada hasta los de salida. Los procesos se agrupan en 23 regiones: flujo de entrada, de transformación y de salida.