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.