PDF de programación - Diseño Estructurado de Sistemas

Introducción a la Programación

Diseño Estructurado de Sistemas

Diseño Estructurado de Sistemas

El diseño estructurado de sistemas se ocupa de la identificación, selección y organi-
zación de los módulos y sus relaciones. Se comienza con la especificación resultante del
proceso de análisis, se realiza una descomposición del sistema en módulos estructurados
en jerarquías, con características tales que permitan la implementación de un sistema
que no requiera elevados costos de mantenimiento.

La idea original del diseño estructurado fue presentada en la década de los '70, por
Larry Constantine, y continuada posteriormente por otros autores: Myers, Yourdon y
Stevens.
1.

Introducción

El diseño estructurado es un enfoque disciplinado de la transformación de qué es ne-

cesario para el desarrollo de un sistema, a cómo deberá ser hecha la implementación.

La definición anterior implica que: el análisis de requerimientos del usuario (deter-
minación del qué) debe preceder al diseño y que, al finalizar el diseño se tendrá medios
para la implementación de las necesidades del usuario (el cómo), pero no se tendrá im-
plementada la solución al problema. Cinco aspectos básicos pueden ser reconocidos:
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 com-
prensió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 cu-
plas (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.
El diseño estructurado produce sistemas fáciles de entender y mantener, confiables,

fácilmente desarrollados, eficientes y que funcionan.

Página 1 de 8

2006

Introducción a la Programación

Diseño Estructurado de Sistemas

2. Diagrama de Estructura

Los diagramas de estructura (DE) sirven para el modelamiento top-down de la es-
tructura 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 utiliza-
da en diseños estructurados, por autores como Constantine, Myers, Stevens e Yourdon.
La Fig. 1 muestra un ejemplo:

Invocación

Cupla de Datos

Cupla de Control

Registro de
empleado

Fin de
archivo

Registro de
empleado

Emitir cheques
de pago a los
Empleados

Pago líquido
de jornaleros

Registro de
empleado
asalariado

Número de
empleado

Pago líquido
de asalariado

Nombre de
empleado

Pago de
empleado

Leer registro
de Empleado

Valor
hora

Horas

trabajadas

Calcular salario

líquido para
jornaleros

Calcular salario

líquido para
asalariados

Imprimir cheque

de pago

Pago bruto
de jornaleros

Deducciones

normales

Pago bruto
de asalariados

Detalle de
impuesto

Detalle de
impuesto

Pago
básico

Bonos

Módulo

Calcular salario

bruto para
jornalero

Calcular

deducciones
normales

Calcular salario

bruto para
asalariados

Fig. 1: Ejemplo de Diagrama de Estructura

Un diagrama de estructura permite modelar un programa como una jerarquía de mó-
dulos. Cada nivel de la jerarquía representa una descomposición más detallada del mó-
dulo del nivel superior. La notación usada se compone básicamente de tres símbolos:
• Módulos
• Invocaciones
• Cuplas

2.1 Módulos

Un módulo es un conjunto de instrucciones que ejecutan alguna actividad, un proce-
dimiento 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.

Página 2 de 8

2006

Introducción a la Programación

Diseño Estructurado de Sistemas

Las entradas y salidas son, respectivamente, datos que un módulo necesita y produce.
Una función es la actividad que hace un módulo para producir la salida. Entradas, sali-
das y funciones proveen una visión externa del módulo. La lógica interna son los algo-
ritmos que ejecutan una función, esto es, junto con su estado interno representan la vi-
sión interna del módulo.

Un módulo es diseñado como una caja, su función es representada por un nombre en
el interior y las entradas y salidas de un módulo son representadas por pequeñas flechas
que entran y salen del módulo.
Módulo

S Un módulo es una caja negra conteniendo una colección de
instrucciones y áreas de datos locales. Los módulos tienen una
función, definida por el nombre contenido en el interior (M),
datos de entrada y datos de salida generados por la aplicación
de la función a los datos de entrada.

E

M

2.2 Relaciones entre Módulos (Invocaciones)

En la realidad, los módulos no son realmente cajas negras. Los diagramas de estruc-
tura muestran las invocaciones que un módulo hace a otros módulos. Estas invocaciones
son diseñadas como una flecha que sale del módulo llamador y apunta al módulo llama-
do. La Fig. 2 muestra un ejemplo:

A

C

Módulo llamador

Invocación

Módulo llamado

D

Fig. 2: Ejemplo de Invocación

B

En el ejemplo de la Fig. 2, el módulo A invoca (o llama) a los módulos B, C y D. La
interpretación de las invocaciones provee información de la estructura interna del mó-
dulo llamador, que no concuerda con la idea de caja negra. Una caja negra no permite
que se observe su interior y, las invocaciones que un módulo hace son componentes de
su estructura interna. De todas formas, se dice que un módulo es una caja casi negra o
caja gris porque ella permite que se observe solo las invocaciones.

Los diagramas de estructura no tienen especificado el orden de invocación de los
módulos invocados. El orden de dibujo de los módulos B, C, y D (de izquierda a dere-
cha) no debe ser interpretado como el orden de invocaciones ejecutado por el módulo
A. Ese orden puede ser cambiado, al dibujar, para evitar que se crucen flechas o se du-
pliquen módulos, como ocurre con el módulo Calcular Deducciones Normales en la
Fig. 1. A pesar que el orden de invocación de los módulos del mismo nivel en un dia-
grama de estructura, no es especificado por el formalismo, se recomienda que siempre
que fuese posible, se siga un orden de izquierda a derecha (si esto no produce que se
crucen flechas) que se corresponde con el orden de invocación, y permitiendo un orden
de lectura que es patrón en la mayoría de los idiomas.

Página 3 de 8

2006

Introducción a la Programación

Diseño Estructurado de Sistemas

Una invocación, representa la idea de llamada a funciones o procedimientos en los
lenguajes de programación convencionales. A continuación se describe una invocación
estándar:
Invocación
Estándar

El módulo A invoca al módulo B con la semántica de invoca-
ción de procedimientos o funciones en los lenguajes de pro-
gramación convencionales (C, Pascal, etc.).

A

B

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

Cupla de datos

Cupla sin tipo
(o de datos
o de control
o híbrida)

X

Z

Y

B

A

C

Cupla modificada

f

W

h

Cupla de control (flag)

Cupla híbrida
(datos y control)

D

Fig. 3: Ejemplo de invocación con cuplas

Como se muestra en la Fig. 3, existen varios tipos de cuplas, basado en lo que ellas

pueden producir en el módulo receptor, las cuales se describen a continuación:

Cupla de

Datos

Cupla

Modificad

a

Cupla de
Resultados

Tipos de Cuplas

Una cupla de datos transporta datos “puros” a un módulo. No es
necesario conocer la lógica interna del módulo receptor, para de-
terminar los valores válidos de la cupla (ej.: número de cuenta, sal-
do, tabla de movimientos).
Con una flecha doble (apuntando al modulo llamador y al módulo
llamado) se especifica un argumento enviado a un módulo que de-
berá modificar su valor, fijando un nuevo valor disponible para el
módulo llamador (en la implementación, se precisará que el len-
guaje posea un mecanismo de pasaje de parámetros por referencia)
(ej.: el buffer enviado a un módulo de lectura de un archivo).
Existen módulos que retornan valores sin la necesidad de que estén
inicializados en el momento que se invocan. Estos casos son dos:
1. Cuplas similares al tipo Modificada cuyos valores previos a la
invocación del módulo NO se utilizan para calcular el valor de
retorno. Si bien en Pascal se implementa como las “Cuplas Mo-
dificadas”, es conveniente documentarlas en el DE como “de
Resultados” por cuestiones de claridad.

2. Si el Módulo en cuestión es una función (retorna un valor), se
debe documentar este valor de retorno como “Cupla de Resulta-
do” cuyo nombre se corresponderá con el nombre de la función.

Página 4 de 8

2006

Introducción a la Programación

Diseño Estructurado de Sistemas

3. Criterios de Va