Diseño Estructurado - Diseño de Software

1. Nombre:
Amael Castellano
21.126.854
Universidad Fermín Toro
Vice-rectorado académico
Decanato de Ingeniería
Escuela de computación

2.  La siguiente presentación trata sobre el Diseño Estructurado
para la elaboración y desarrollo de softwares, donde definiremos
el mismo, las etapas que conlleva, así como algunas estrategias y
técnicas para llevarlo acabo. Además se verán algunos puntos
para la evaluación del diseño mencionado.

3. Persigue elaborar algoritmos que cumplan la
propiedad de modularidad, se busca dividir el
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.
•El diseño estructurado es utilizado en
programación y diseño de algoritmo, como una
herramienta que tiene como objetivo realizar
algoritmos que sean modulares, es decir crear una
jerarquía modular y módulos independientes
siguiendo los principios del diseño de
descomposición por refinamientos sucesivos.

4. Descomposición
La descomposición es la separación de una función en otras que
estuvieran contenidas en la primera.
La descomposición consigue los siguientes objetivos:
 Reducir el tamaño del módulo.
 Hacer el sistema más fácil de entender y modificar.
 Minimizar la duplicidad de código. Se evita tener que realizar
una función en más de un módulo.
 Crear módulos útiles.

5. El problema puede surgir cuando el diseñador se pregunte en
qué momento debe dejar de descomponer módulos.
 Se debe dejar de descomponer cuando no se encuentren
funciones bien definidas.
 Se puede parar la descomposición cuando la interface con un
módulo sea tan complicada como el módulo en sí mismo.
Un módulo de mil líneas es malo, ya que trata demasiados
asuntos en su interior, pero mil módulos de una línea son
peores.

6. Jerarquía de Módulos
Al dividir los módulos jerárquicamente, es posible controlar el
número de ellos que interactúan directamente con cualquiera
de los otros.
El objetivo de aplicar una jerarquía de módulos es conseguir
separar los módulos que realizan tareas de cálculo y edición de
aquellos que toman decisiones y llaman a otros módulos.
Se debe lograr un tipo de organización en donde los módulos
de niveles medios y altos del diagrama, ejerzan el trabajo de
coordinación y manipulación de los módulos de niveles más
bajos, que son los que deben realizar tareas de cálculo y
edición.

7. Independencia Modular
Si los módulos individuales son completamente
independientes unos de otros, entonces el esfuerzo total
implicado en el desarrollo del sistema es una función lineal del
número de módulos del sistema.
La definición de módulos está cerca de la idea de CAJA
NEGRA: un módulo no tiene que preocuparse de los detalles de
la construcción interna del resto de los módulos.
Hay que ver a los módulos solamente por su función y por su
apariencia externa.

8. Análisis de Transformación
El análisis de transformación es un conjunto de pasos que permiten
obtener, a partir de un DFD (diagrama de flujo de datos) con
características de transformación, la estructura del sistema.
El DFD con características de transformación es aquél en el que se
pueden distinguir tres zonas:
 Flujo de llegada o entrada.
 Flujo de transformación o centro de transformación.
 Flujo de salida.

9. Esta división en tres partes va a facilitar que, los datos que
necesite el sistema se recojan por los módulos que se
encuentren en la/s rama/s de la izquierda, los datos que se
intercambian en esa rama serán ascendentes: información de
entrada al sistema.
En las ramas centrales habrá movimiento de información
compartida tanto ascendente como descendente porque aquí
los módulos elaboran nuevos datos.
En la/s rama/s de la derecha, la información ya será la
definitiva y el sentido de los datos debe ser descendente.
En algún caso particular puede suceder que alguna de las partes
sea vacía, esto es, no exista.

10. Análisis de Transacción
El análisis de transacción se aplica cuando un DFD toma una
forma, en la que un dato determina la elección de uno o más flujos
de información.
La transacción es evaluada y, basándose en su valor, el flujo se
inicia por uno de los muchos caminos de acción.
El centro de flujo de información desde el que emanan varios
caminos de acción se llama centro de transacción.

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

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

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

14. 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 (Dentro de este tenemos: Acoplamiento de datos,
Acoplamiento de marca o por estampado, Acoplamiento de
control), Acoplamiento Común, Acoplamiento externo,
Acoplamiento de contenido.

15. 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: Funcional, Secuencial, Comunicacional,
Procedimental, Temporal, Lógica y Casual o Coincidente.

16. Fan-In y Fan-Out
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.

17.  Luego de haber planteado los puntos anteriores, se concluye que
el diseño estructurado posee ciertos pasos concretos y específicos
que se han de tomar en cuenta a la hora de diseñar un software
dado que esto hará que el código del mismo sea mucho más
entendible y eficiente al hacerlo, valga la redundancia,
debidamente bien estructurado.