1. UNIVERSIDAD FERMIN TORO
DECANATO DE INGENIERIA
CABUDARE, EDO. LARA
Alumna: Marian A. Lugo Salesi
CI:19.884.787
Diseño de Software
Saia

2. En programación y diseño de algoritmos, el diseño
estructurado persigue elaborar algoritmos que cumplan la
propiedad de modularidad, para ello, dado un problema
que se pretende resolver mediante la elaboración de un
programa de ordenador, se busca dividir dicho programa
en módulos siguiendo los principios de diseño de
Descomposición por refinamientos sucesivos, creación de
una Jerarquía modular y elaboración de módulos
Independientes.

3.  Descomposición
¿Por qué descomponer un problema en partes? Experimentalmente está comprobado que:
Un problema complejo cuesta más de resolver que otro más sencillo (de Perogrullo).
La complejidad de un problema global es mayor que el valor de las complejidades de cada una
de sus partes por separado.
Según esto, merece la pena el esfuerzo de dividir un problema grande en subproblemas más
pequeños. Si el objetivo es elaborar un programa para resolver dicho problema grande, cada
subproblema (menos complejo) podrá ser resuelto por un módulo (subalgoritmo) relativamente
fácil de implementar (más que el programa global No dividido). Ahora la cuestión es ¿cómo
realizar la descomposición?; realizando un estudio descendente Top-Down que nos lleve desde
la concepción del problema (programa o algoritmo) global hasta identificar sus partes
(módulos). Esta técnica se repite aplicando una estrategia llamada de refinamiento sucesivo
propuesta por el experto en Ciencias de la Computación Niklaus Wirth, que consiste
precisamente en volver a aplicar el estudio descendente Top-Down a cada subproblema una y
otra vez hasta obtener subproblemas suficientemente pequeños, que puedan ser resueltos por
módulos que cumplan, en la medida de lo posible, las características deseables en un módulo
en el ámbito de la programación. En palabras del propio Niklaus Wirth:

4.  En cada paso (del refinamiento), una o varias instrucciones del programa dado, se
descomponen en instrucciones más detalladas. Esta descomposición sucesiva o
refinamiento de especificaciones termina cuanto todas las instrucciones están expresadas
en términos de la computadora usada o del lenguaje de programación...
 Conforme se refinan las tareas, también los datos pueden ser refinados, descompuestos o
estructurados, siendo lo natural refinar las especificaciones del programa y de los datos en
paralelo.
 Cada paso de refinamiento implica algunas decisiones de diseño. Es importante que el
programador sea consciente de los criterios subyacentes (en las decisiones de diseño
adoptadas) y de la existencia de soluciones alternativas...
Problema del refinamiento sucesivo
¿Cuándo parar el refinamiento?. Un refinamiento excesivo podría dar lugar a un número tan
grande de módulos que haría poco práctica la descomposición. Se tendrán en cuenta estos
criterios para dejar de descomponer:
 Cuando no haya tareas bien definidas.
 Cuando la interfaz de un módulo sea tan complicada como el propio módulo

5.  Jerarquía de módulos
Ésta es una consecuencia directa de la descomposición del problema mediante refinamientos
sucesivos, el resultado será un conjunto de módulos estratificados en capas a modo de
pirámide donde en la cima habrá un único módulo que representará al programa global y en los
niveles inferiores aparecerán los módulos resultantes de las sucesivas divisiones.
Al final, debe obtenerse una estructura piramidal donde los módulos de los niveles superiores
se encargan de las tareas de coordinación, lógica de la aplicación y manipulación de los
módulos inferiores; estos otros deberán realizar tareas de cálculo, tratamiento y entrada/salida
de información.

6.  Acoplamiento
Se define como el grado de interdependencia que hay entre los distintos módulos de un
programa; lo deseable es que esta interdependencia sea lo menor posible, es decir, un bajo
acoplamiento. Los niveles de acoplamiento, ordenados de menor (más deseable) a mayor
(menos deseable) son:
Acoplamiento normal.- Un módulo llama a otro de un nivel inferior y tan solo intercambian
datos (parámetros de entrada/salida). Dentro de este tipo de acoplamiento podemos
encontrarnos 3 subtipos, dependiendo de los datos que intercambien los módulos:
Acoplamiento de datos: Los módulos se comunican mediante parámetros.
Acoplamiento de marca o por estampado: Los módulos se pasan datos con estructura de
registro. No es muy deseable si el módulo receptor sólo requiere parte de los datos que se
le pasan.
Acoplamiento de control: Los datos que se intercambian entre los módulos son controles.
Debido a que en este subtipo un módulo controla la ejecución del otro, no es un buen
acoplamiento, ya que impide que sean totalmente independientes.

7. Acoplamiento Común.- Dos módulos acceden a un mismo recurso común, típicamente
memoria compartida, una variable global o un fichero. Una variante de este tipo de
acoplamiento es el acoplamiento externo:
Acoplamiento externo.- Los módulos están ligados a componentes externos. Por
ejemplo, dispositivos de E/S, protocolos de comunicaciones... etc.
Acoplamiento de contenido.- Ocurre cuando un módulo necesita acceder a una parte de otro
módulo.
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.

8.  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):
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.

9. 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.

10.  Top Down
Técnica para diseñar que consiste en tomar el problema en forma
inicial como una cuestión global y descomponerlo sucesivamente en problemas más pequeños
y por lo tanto, de solución más sencilla.
La descomposición del problema original (y de las etapas subsecuentes),
puede detenerse cuando los problemas resultantes alcanzan un nivel de detalle
que el programador o analista pueden implementar fácilmente.
Objetivos básicos del Top-Down
Simplificación del problema y de los subprogramas de cada descomposición.
Las diferentes partes del problema pueden ser programadas de modo independiente e incluso
por diferentes personas.
El programa final queda estructurado en forma de bloque o módulos lo que hace mas sencilla
su lectura y mantenimiento.

11.  Bottom up
El diseño ascendente se refiere a la identificación de aquellos procesos que necesitan
computarizarse con forme vayan apareciendo, su análisis como sistema y su codificación, o
bien, la adquisición de paquetes de software para satisfacer el problema inmediato.
Cuando la programación se realiza internamente y haciendo un enfoque ascendente, es difícil
llegar a integrar los subsistemas al grado tal de que el desempeño global, sea fluido.
Los problemas de integración entre los subsistemas son sumamente costosos y muchos de
ellos no se solucionan hasta que la programación alcanza la fecha limite para la integración
total del sistema.
En esta fecha, ya se cuenta con muy poco tiempo, presupuesto o paciencia de los
usuarios, como para corregir aquellas delicadas interfaces, que en un principio, se ignoran.
Aunque cada subsistema parece ofrecer lo que se requiere, cuando se contempla al sistema
como una entidad global, adolece de ciertas limitaciones por haber tomado un enfoque
ascendente. Uno de ellos es la duplicación de esfuerzos para accesar el software y mas aun al
introducir los datos. Otro es, que se introducen al sistema muchos datos carentes de valor. Un
tercero y tal vez el mas serio inconveniente del enfoque ascendente, es que los objetivos
globales de la organización no fueron considerados y en consecuencia no se satisfacen.

12.  Warnier Orr
Es una técnica que utiliza una representación semejante a la de cuadros
sinópticos para mostrar el funcionamiento y organización de los elementos que conforman el
algoritmo.
Los diagramas Warnier Orr son útiles porque son compatibles con las
técnicas de programación estructurada ; y además, son fáciles de
desarrollar. Los diagramas Warnier Orr son fáciles de leer y modificar y
no tienen que completarse antes de ser útiles. Se van desarrollando
hacia otras salidas del sistema.
Básicamente, utiliza una notación de llaves para organizar los módulos y se
auxilia en la siguiente simbología para indicar operaciones de control.
Símbolo Significado +
OR (uno, otro o varios)
XOR (uno u otro, solo uno)
(x,y) puede hacerse tantas veces desde x hasta y
Nota : Los diagramas Warnier Orr se leen de izquierda a derecha y de arriba hacia abajo.
Ejemplo de un diagrama de Warnier Orr, de un control de almacén
(0,n) = De cero veces a n veces
(1,n) = De una vez a n veces

13. Obtener la estructura modular y los detalles de proceso del sistema, partiendo solamente de
los «productos» obtenidos en la fase de Análisis del Sistema.
• Cambiar la atención del QUE al COMO.
• Obtener un diseño que no sólo «funcione», sino que también sea mantenible, mejore la
reutilización y se pueda probar y entender fácilmente.
• Utilizar herramientas gráficas (Diagramas de Estructura de Cuadros) para representar la
estructura modular del sistema.
Se trata por tanto, de conseguir que cada módulo de la estructura en árbol que se obtenga
cumpla
las siguientes características:

14.  Módulos de pequeño tamaño:
El impacto de un cambio a realizar puede ser perfectamente aislado. Si el tamaño de los
módulos es reducido, una determinada modificación afectará a un número mayor de
módulos, sin embargo, la cantidad de código a considerar será menor.
 Independencia modular:
Cuanto mayor es la independencia de un módulo es más sencillo trabajar con él, por tanto, el
diseño debe reducir la compartición de ficheros, de datos, la de dispositivos, las interfaces
comunes con el Sistema Operativo y las llamadas, desde o hacia otros módulos.
 Características de Caja Negra:
La característica de Caja Negra se aplica a cualquier sistema, programa o módulo, para dar una
visión exclusiva de sus entradas y salidas, sin tener en cuenta los detalles de cómo se realiza el
proceso. El uso de la Caja Negra permite una visión más fácil del conjunto, posponiendo la
consideración de los detalles para una etapa posterior.

15.  Modelización conceptual:
Un sistema será más fácil de mantener si el modelo utilizado en su diseño se ha basado en los
conceptos lógicos de la organización, los cuales serán más familiares y comprensibles para el
personal de mantenimiento que las descripciones físicas (equipo, organización de la
unidad, cómo se realiza el trabajo en la actualidad,...).
 Aislamiento de los detalles:
En un sistema existen partes que reflejan la filosofía y otras partes que reflejan los detalles.
Debido a que los detalles son más susceptibles de cambiar, ambas partes deben diseñarse por
separado para evitar que una variación en los detalles afecte a la filosofía del sistema.