Este documento describe los principios del diseño estructurado de software. El diseño estructurado divide un sistema en módulos, representa la estructura y comunicación entre módulos usando diagramas de estructura y especificaciones de módulos, y busca maximizar la cohesión y acoplamiento entre módulos. El documento explica conceptos como módulos, diagramas de estructura, acoplamiento, cohesión, y fan-in y fan-out.

1. Republica Bolivariana de Venezuela
Universidad Fermín Toro
Cabudare – Lara
Diseño Estructurado
Simón Azuaje v- 17.727.910

2. Diseño Estructurado
El diseño estructurado es un método de diseño de software concebido por Page-
Jones este método debe aplicarse después de analizar el software mediante un método
estructurado.
El método proporciona un conjunto de herramientas para la representación del
diseño del software, la organización de las actividades de diseño y criterios para
comprobar la calidad del diseño.
Cinco aspectos básicos pueden ser reconocidos en este diseño:
1. Permitir que la forma del problema guíe a la forma de la solución. Un concepto básico
del diseño de arquitecturas es: las formas siempre siguen funciones.
2. Intentar resolver la complejidad de los grandes sistemas a través de la segmentación
de un sistema en cajas negras, y su organización en una jerarquía conveniente para la
implementación.
3. Utilizar herramientas, especialmente gráficas, para realizar diseños de fácil
comprensión. Un diseño estructurado usa diagramas de estructura (DE) en el diseño de la
arquitectura de módulos del sistema y adiciona especificaciones de los módulos y cuplas
(entradas y salidas de los módulos), en un Diccionario de Datos (DD).
4. Ofrecer un conjunto de estrategias para derivar el diseño de la solución, basándose en
los resultados del proceso de análisis.
5. Ofrecer un conjunto de criterios para evaluar la calidad de un diseño con respecto al
problema a ser resuelto, y las posibles alternativas de solución, en la búsqueda de la
mejor de ellas.

3. Diagrama de Estructura
Los diagramas de estructura (DE) sirven para el modelamiento top-down de la
estructura de control de un programa descripto a través de un árbol de invocación de
módulos. Fueron presentados en la década de los 70 como la principal herramienta
utilizada en diseños estructurados.
Ejemplo:

4. Módulos
Un módulo es un conjunto de instrucciones que ejecutan alguna actividad, un
procedimiento o función en PASCAL, una función en C o un parágrafo en COBOL. Tal
vez, la definición más precisa es que un módulo es una caja negra, pero como será
mostrado a continuación son cajas “casi” negras o grises.
Desde un punto de vista práctico, un módulo es una colección de instrucciones de
un programa con cuatro características básicas:
1. Entradas y Salidas: lo que un módulo recibe en una invocación y lo que retorna como
resultado.
2. Función: las actividades que un módulo hace con la entrada para producir la salida.
3. Lógica Interna: por la cual se ejecuta la función.
4. Estado Interno: su área de datos privada, datos para los cuales sólo el módulo hace
referencia.

5. Ejemplo
Módulo. Seleccionar sitio de pasajeros.
Propósito. Elegir para cada cliente el sitio que cumpla los requisitos de su clase y
preferencias.
Usa. Preferencias_sitio.
Devuelve. Sitio_seleccionado,
Preferencias_disponibles.
Detalles funcionales. Buscar entre los sitios disponibles aquellos que cumplan las
condiciones en el siguiente orden: clase, fumador y fila.
Estructura de datos
Preferencias_sitio
Clase_asignada *Primera, Negocios, Turista
Fumador *S/N
Fila *Pasillo, Medio, Ventana

6. Comunicación entre Módulos (Cuplas)
Cuando una función o un procedimiento, en un lenguaje convencional, es
invocado, comúnmente un conjunto de argumentos es comunicado y, en el caso de las
funciones, también se espera que retorne un resultado. Estos datos comunicados en una
invocación son modelados por medio de flechas, sobre el símbolo de invocación,
llamadas cuplas.

7. Acoplamiento
El acoplamiento entre módulos clasifica el grado de independencia entre pares de
módulos de un DE. El objetivo es minimizar el acoplamiento, es decir, maximizar la
independencia entre módulos. A pesar de que el acoplamiento, es un criterio que clasifica
características de una invocación (una relación existente entre dos módulos), será usado
para clasificar un DE completo. Un DE se caracteriza por el peor acoplamiento existente
entre pares de sus módulos, ya que ese es el problema que debe ser resuelto para
mejorar la calidad del DE completo.
Un bajo acoplamiento indica un sistema bien particionado y puede obtenerse de
tres maneras:
• Eliminando relaciones innecesarias: Por ejemplo, un módulo puede recibir algunos
datos, innecesarios para él, porque debe enviarlos para un módulo subordinado.
• Reduciendo el número de relaciones necesarias: Cuanto menos conexiones existan
entre módulos, menor será la posibilidad del efecto en cadena (un error en un módulo
aparece como síntoma en otro).
• Debilitando la dependencia de las relaciones necesarias: Ningún módulo se tiene que
preocupar por los detalles internos de implementación de cualquier otro. Lo único que
tiene que conocer un módulo debe ser su función y las cuplas de entrada y salida (cajas
negras).
Cohesión
Se define como la medida de fuerza o relación funcional existente entre las
sentencias o grupos de sentencias de un mismo módulo. Un
módulo cohesionado ejecutará una única tarea sencilla interactuando muy poco o nada
con el resto de módulos del programa. Se persigue que los módulos tengan una alta
cohesión.
En el diseño estructurado podemos encontrarnos con los siguientes 7 tipos de
cohesión (de la mejor o más deseable a la menos recomendable):

8. Cohesión funcional: Los elementos del módulo están relacionados en el desarrollo
de una única función.
Cohesión secuencial: Un módulo realiza distintas tareas en secuencia, de forma que
las entradas de cada tarea son las salidas de la tarea anterior. No es una mala
cohesión si las tareas implicadas no son muy complejas y requieren pocas líneas de
código.
Cohesión comunicacional: El módulo realiza actividades paralelas usando los
mismos datos de entrada y salida. Como en el caso anterior, tampoco se trata de un
mal tipo de cohesión si las tareas son relativamente sencillas.
Cohesión procedimental: El módulo tiene una serie de funciones relacionadas por
un procedimiento efectuado por el código (a modo de biblioteca). Es similar a la
secuencial, pero puede incluir el paso de controles. Será deseable que las funciones
estén relacionadas o realicen tareas dentro del mismo ámbito (p.e. la
biblioteca string.h de C contienen funciones para operar con cadenas de caracteres).
Cohesión temporal: Los elementos del módulo están implicados en actividades
relacionadas con el tiempo.
Cohesión lógica: Las actividades que realiza el módulo tienen la misma categoría.
Esto es, es como si se tuvieran partes independientes dentro del mismo módulo.
Cohesión casual o coincidente: Los elementos del módulo contribuyen a las
actividades relacionándose mutuamente de una manera poco significativa. Este tipo
de cohesión viola el principio de independencia y de caja negra de los módulos.

9. Fan-In y Fan-Out
Además de los dos conceptos anteriores, se deben tener en cuenta el grado de
absorción (fan-in) y la diseminación del control (fan-out) de los módulos para garantizar la
calidad del diseño.
Fan-In: También llamado grado de absorción. Es el número de superordinados
inmediatos que tiene el módulo en cuestión. Es conveniente maximizar el fan-in
durante el proceso de diseño, ya que cada instancia de fan-in múltiple indica que se
ha evitado la duplicación de código.
Fan-Out: También llamado diseminación del control. Es el número de subordinados
inmediatos que tiene el módulo en cuestión. Conviene no tener un fan-out ni muy alto
ni muy bajo, ya que eso es un posible indicador de un diseño pobre. Si no es posible
evitarlo, es preferible un fan-out bajo antes que uno alto.