2.
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.
Diseño Estructurado
3.
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.
Etapas
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
interfase 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. ANALISIS DE TRANSFORMACION
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.
Estrategias
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, ésto es, no exista.
10.
ANALISIS DE TRANSACCION
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 ininicial 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.
Técnicas
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.
Evaluación del Diseño
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, Logica 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.