PDF de programación - Unidad Nº III: Diseño Estructurado - Introducción al Diseño de Sistemas de Información

Introducción al Diseño de Sistemas de

Información

Unidad Nº III: Diseño Estructurado

Facultad Regional Santa Fe Universidad Tecnológica Nacional

Diseño Estructurado
Como vimos, el Diseño de Software es :

“Proceso mediante el que se traducen los requisitos en una representación del
software” (Robert Pressman)

El objetivo más importante es :

entregar las funciones requeridas por el usuario en una implementación de software
(satisfaga una especificación funcional dada).

El diseño es un proceso mediante el cual se traducen los requisitos del sistema en una
representación de software. A través de refinamientos sucesivos se genera una representación
de diseño que se acerca mucho al código fuente.
El diseño se realiza, generalmente, en dos pasos :

 Diseño preliminar, el cual se centra en la transformación de los requisitos en los
 Diseño detallado, el que se ocupa del refinamiento de

datos y la arquitectura del software.

arquitectónica que
representaciones algorítmicas del software.

lleva a una estructura de datos detallada y a

la representación
las

El Diseño Estructurado se fundamenta en una descomposición funcional sistematizada, la que
se lleva a cabo de acuerdo a las siguientes actividades/fases:

1. Representar el sistema como un Diagrama de Flujos de Datos (DFD).
2. Estructurar el sistema como jerarquías de procesos

(utilizando Diagramas

Estructurados).
Análisis transformacional.
Análisis transaccional.

3. Verificar proyecto y reestructurar.

La verificación se realiza analizado si están correctamente aplicados los conceptos de:

Cohesión
Acoplamiento
Alcance de efectos/control
Tamaño de la interfaces
Balance del diseño
Etc.
Descomposición de procesos
Refinamiento sucesivo
Factorización

4.

5. Preparar para la implementación.

El Diseño Estructurado (DE) se fundamenta en una descomposición funcional sistematizada, la
que se lleva a cabo convirtiendo sistemáticamente DFDs en Diagramas Estructurados (DE,
‘Structure Charts’)
Para realizar estar transformación podemos aplicar estrategias ascendentes o descendentes,
siendo sin embargo el diseño estructurado una técnica estrictamente ‘top-down’ (en el sentido
de que el diseño se va realizando gradualmente por refinamiento sucesivo).




Coordi
nador

A

B

C

Proce
so A

Proce
so B

Proce
so C

Figura III. 1 – Transformación de un DFD en un DE

Estrategias Ascendente (Bottom-Up) y Descendente (Top-Down)

Diseño ascendente (bottom-up)
El diseño ascendente se refiere a que la identificación de los procesos que se automatizarán se
realiza partiendo del nivel más bajo hasta llegar al nivel superior.
Desde el punto de vista de una organización, se hace referencia a que los problemas que
requieren una automatización inmediata se encuentran en los niveles inferiores, y por otra parte
son los de menor costo de implementación.
El problema que presenta este enfoque, es que es muy difícil integrar los objetivos de los
distintos subsistemas construidos en pos de un objetivo global. Esto es así debido a que cada
uno fue concebido persiguiendo un objetivo particular, y en consecuencia no se previeron los
mecanismos de interacción adecuados con otros subsistemas.
El principal problema de este enfoque es que no se consideran los objetivos globales de la
organización, y en consecuencia no se satisfacen. Pueden presentarse además duplicación de
esfuerzos para introducir y acceder a los datos; y también pueden introducirse al sistema datos
carentes de valor.

A

C

B

D

E

F

Figura III. 2 – Diseño Ascendente



Diseño descendente (top-down)
El enfoque descendente implica observar la gran imagen del sistema y luego, explosionarlo o
desglosarlo en partes más pequeñas o subsistemas.
El diseño descendente obliga a enterarse primero de los objetivos globales de la organización,
así como el establecimiento de la mejor manera de satisfacerlos dentro de un sistema integral.
Cuando se aplica un enfoque descendente se emplean las interrelaciones e interdependencias
de los subsistemas, para apegarse lo mejor posible a las necesidades de la organización.
En este enfoque se da la importancia debida a las interfaces requeridas entre el sistema y sus
subsistemas, lo cual no existe en el enfoque ascendente.
La aplicación de este enfoque posibilita contar con distintos grupos de desarrollo trabajando en
forma simultanea en subsistemas independientes.
Un inconveniente que presenta este enfoque es que se divida el sistema en subsistemas
‘incorrectos’. Se debe prestar atención para que la partición en subsistemas tenga sentido en
el esquema global del sistema, y que se integren en forma correcta al sistema.
Debe tenerse presente que una vez que se realizan las divisiones en subsistemas, sus
interfaces pueden descuidarse o simplemente ignorarse.
Debe tenerse siempre presente la retroalimentación entre los distintos subsistemas y grupos de
desarrollo para mantener unificados los criterios.

A

C

B

D

E

F

Figura III. 3 – Diseño Descendente

Diagramas Estructurados
Los Diagramas Estructurados (DE) describen una arquitectura de programas a través de una
jerarquía de llamadas a módulos.
Estos DE son elaborados a partir de la descomposición funcional pura de los DFDs, y
presentan una estructura de control limitada.
Como desventaja puede decirse que se tornan difíciles de leer cuando hay muchos detalles de
los flujos de datos y control entre los distintos módulos.

Existe un acuerdo general en el sentido de que los sistemas más fáciles de cambiar son
aquellos que están constituidos por módulos manejablemente pequeños, cada uno de los
cuales es independiente, hasta donde es posible, de cualquier otro, de manera que pueden
sacarse del sistema, cambiarse, y reponerse sin afectar el resto del sistema.

Un diseño modular reduce la complejidad, facilita los cambios, y produce como resultado una
implementación más sencilla, permitiendo el desarrollo paralelo de las diferentes partes de un
sistema.

Módulo lógico: es una función definida con un nombre que expresa el propósito de la función.
Los procesos definidos en los Diagramas de Flujos de Datos pueden
considerarse módulos lógicos.



Módulo físico: implementación particular de un módulo lógico. Generalmente está dado en
términos de un grupo de sentencias en un lenguaje de programación, al cual
puede hacerse referencia por un nombre.

Los módulos a menudo invocan a otra módulos, los cuales invocan a otros módulos, etc.. Esto
permite formar una jerarquía jefe-subjefe, hasta alcanzar los módulos de trabajo finales.

Módulo manejablemente pequeño: una persona competente será capaz de tomar un listado
del módulo, leerlo y hacerse mentalmente un cuadro de su función interna
mientras decide cómo cambiarlo.

Independencia: aislar la función en la menor cantidad de módulos posibles.

Idealmente las funciones estén contenidas en cajas negras, donde la función producirá
siempre resultados predecibles a partir de un conjunto de datos que pasen a través de la
misma.

Los módulos que componen un sistema no pueden ser completamente independientes unos de
otros o no existiría un sistema sino solamente un montón de módulos aislados.

Los nombres de los módulos siguen las mismas normas que para proceso: verbo activo y un
objeto único.

Comunicación entre módulos
La estructura es de “llamada” o invocación de módulos. El módulo de nivel superior invoca a
uno de nivel inferior (representado por una flecha que une al módulo llamador y el llamado).

Los módulos pueden intercambiar:

 Datos: representado por una flecha con un círculo vacío en un extremo.
Señales: representado por una flecha con un círculo lleno en un extremo.

La tarea del diseñador es formar los módulos y diseñar sus interconexiones para minimizar la
posibilidad del efecto onda (un cambio en un módulo repercute en otros módulos, y así).

Derivación del modelo físico a partir de un DFD
Para realizar la transición desde el flujo de información (DFD) a la estructura (DE) se debe
proceder de la siguiente manera:

1. Establecer el tipo de flujo de información;
2. Determinar los límites del flujo;
3. Convertir el DFD en la estructura del programa;
4. Definir la jerarquía de control mediante factorización;
5. Refinar la estructura resultante usando medidas y heurísticas de diseño.

Similar a una estructura militar. Cada módulo tiene su propia tarea, que desempeña cuando
recibe órdenes superiores; se comunica sólo con su jefe superior y con sus subordinados.
La no comunicación directa entre los módulos de trabajo de un mismo nivel o en general no
respetando la jerarquía estipulada, es una forma de simplificar el acoplamiento intermodular, y
facilita la comprensión del comportamiento del sistema.
El tipo de flujo de información es lo que determina el método de conversión requerido en el
paso 3, y existen dos tipos: flujos de transformación y flujos de transacción.

Sistemas centrados en flujos de transformación
Si tenemos en mente el diagrama de flujo de datos de nivel 0 de un sistema, la información
entra y sale en una forma del ‘mundo exterior’. Por ejemplo, algunas formas de información del
mundo exterior son las teclas pulsadas sobre un teclado de una terminal, los tonos sobre una
línea telefónica y los dibujos de un monitor gráfico de computadora. Tales datos externos
deben ser convertidos a una forma interna adecuada para el procesamiento. La Figura III.4




ilustra la evolución del flujo de datos a lo largo del tiempo. La información entra al sistema
mediante caminos que transforman los datos externos a una forma interna y se identifican
como flujo entrante. En el interior del software se produce una transición. Los datos entrantes
pasa