Ingeniería del Software. .- Diseño Estructurado.

TEMA - DISEÑO ESTRUCTURADO

1. INTRODUCCIÓN
Los métodos de diseño del software se obtienen del estudio de cada uno de los tres dominios del
modelo de análisis. El dominio de los datos, el funcional y el de comportamiento sirven de directriz
para la creación del diseño.
En el diseño estructurado orientado al flujo de datos, partimos de la representación del flujo de
la información obtenida en la fase de análisis, donde la información puede representarse como un
flujo continuo que sufre una serie de transformaciones conforme va de la entrada a la salida.

El diagrama de flujo de datos DFD (o de burbujas) se utiliza como herramienta gráfica para la
descripción del flujo de la información.

1. DISEÑO DE DATOS
El impacto de la estructura de datos sobre la estructura del programa y la complejidad procedi-
mental hace que el diseño de datos tenga una gran influencia en la calidad del software. Los datos
bien diseñados pueden conducir a una mejor estructura de programa, a una modularidad efectiva y
a una complejidad procedimental reducida.

2. DISEÑO ARQUITECTÓNICO
El objetivo principal del diseño arquitectónico es desarrollar una estructura de programa
modular y representar las relaciones de control entre los módulos. Mezcla la estructura de
programas y la estructura de datos y define las relaciones que facilitan el flujo de los datos a lo
largo del programa.

El diseño orientado al flujo de datos es compatible con un amplio rango de areas de aplicación.
Es particularmente útil cuando se procesa secuencialmente la información y no existe ninguna es-
tructura jerárquica formal. De hecho, todo el software puede representarse como un diagrama de
flujo de datos. Ejemplo: aplicaciones con microprocesadores, procedimientos de análisis numé-
rico, procesos de control, etc.

3. EL PROCESO DEL DISEÑO ARQUITECTÓNICO

El diseño orientado al flujo de datos define varias representaciones que transforman el flujo de la
información en la estructura del programa.
El Diseño Orientado al Flujo de Datos permite una cómoda transformación de las representacio-
nes de la información (DFD) a una descripción de la estructura del programa. Este proceso debe
seguir los siguientes pasos:
1. Establecer el tipo de flujo de información.
- Flujo de transformación.
- Flujo de transacción.
2. Determinar los límites del flujo.
3. Convertir el DFD en la estructura del programa
4. Definir la jerarquía de control descomponiéndola mediante par-
ticionamiento.
.- 1 -.
 Ingeniería del Software. .- Diseño Estructurado.

5. Refinar la estructura resultante usando medidas y heurísticas de

diseño
El tipo de flujo de información es lo que determina el método de conversión requerido en el pa-
so 3.

• FLUJO DE TRANSFORMACIÓN:
En un sistema, la información entra y sale en una forma del mundo exterior (entradas de teclado,
tonos telefónicos, imágenes de visualización,...). Esos datos externos, deben ser convertidos a
una forma adecuada para el procesamiento.

REPRESENTACION EXTERNA REPRESENTACION INTERNA REPRESENTACION EXTERNA

FLUJO ENTRANTE FLUJO de FLUJO SALIENTE

TRANSFORMACION

La información entra al sistema mediante caminos que transforman los datos externos a una
forma interna y se identifica como Flujo Entrante.
En el interior del software se produce una transición, los datos entrantes pasan a través de un
centro de transformación, moviendose ahora hacia la salida del software. Estos datos forman el
Flujo Saliente.
El flujo de datos global ocurre de forma secuencial y sigue uno o pocos caminos directos. Cuan-
do una parte del DFD tiene estas características decimos que es un Flujo de Transformación.

• FLUJO DE TRANSACCIÓN:
El flujo de transacción se caracteriza por el movimiento de datos a través de un camino de llega-
da que convierte la información del mundo exterior en una transacción. Se evalua la transacción
y deacuerdo con su valor, el flujo sigue por uno de los muchos caminos de acción.

TRANSACCION CAMINOS
T
DE
CENTRO DE
TRANSACCION ACCION

Suele ser una selección,

dependiendo del valor del
dato se va por un camino
o por otro.

.- 2 -.
 Ingeniería del Software. .- Diseño Estructurado.

El centro del flujo de información desde el que emanan los caminos de acción se denomina Cen-
tro de Transacción. Dentro de un flujo de transacción, el flujo de información a través de un
camino de acción puede tener características de flujo de transformación.

En el DFD de un sistema, generalmente estarán presentes los dos tipos de flujos: el flujo de
transformación y el flujo de transacción.

El Diseño Orientado al Flujo de Datos comienza con una evaluación del DFD a nivel 2 ó 3. Se
establece el tipo de flujo de información y se definen los límites del flujo que delimitan el centro de
transformación o de transacción. Se convierten las transformaciones (burbujas del DFD) en módu-
los, como estructuras de programa. Se factoriza la estructura, es decir, los módulos se definen y
organizan mediante una distribución descendente del control en la estructura. Por último se refina la
estructura obtenida.

4. ANALISIS DE TRANSFORMACIÓN
El análisis de transformación es un conjunto de pasos de diseño que permiten convertir un DFD,
con características de flujo de transformación, en una plantilla predefinida para la estructura del
programa.

4.1.- PASOS DEL DISEÑO

Los pasos comienzan con una reevaluación del trabajo hecho durante el análisis de requisitos y
luego evoluciona hacia el desarrollo de la estructura del programa.
Estos pasos son:

1. Revisar el modelo fundamental del sistema: revisar el DFD nivel 0 y la información com-
plementaria.
2. Revisar y refinar los DFD del software: se examinan los DFD nivel 1, 2 y 3 hasta el nivel en
que cada transformación tiene una cohesión alta (es decir, cada transformación ejecuta una
función sencilla y diferenciada) pudiendose implementar como un módulo. En este paso se
llega al nivel que contiene suficiente detalle como para establecer un diseño inicial para la es-
tructura del programa.
3. Determinar si el DFD tiene características de transformación o de transacción: en general,
el flujo de información de un sistema podrá representarse siempre como una transformación.
Si tiene una característica obvia de transacción es conveniente tratarla como tal.
El diseñador selecciona la característica general del flujo basandose en la naturaleza prevale-
ciente del DFD.
Se aislan las regiones locales de flujo de transformación o de transacción, lo que nos permiti-
rá refinar la estructura del programa posteriormente.
4. Aislar el centro de transformación especificando los límites de los flujos entrante y salien-
te: la interpretación de los límites es algo subjetivo dependiente del diseñador, así es posible
obtener distintas soluciones alternativas variando los límites del flujo. El diseñador debe esta-
blecer unos límites razonables.
5. Realizar una descomposición de primer nivel: la estructura del programa representa una dis-
tribución descendente del control. La descomposición da como resultado una estructura de
programa en la que los módulos de nivel superior toman las decisiones de ejecución y los
módulos de nivel inferior ejecutan la mayoría del trabajo de entrada, de procesamiento y de

.- 3 -.
Ingeniería del Software. .- Diseño Estructurado.

salida. Los módulos de nivel intermedio ejecutan algún control y realizan moderadas cantida-
des de trabajo.

Ejemplo:

A B F
E H I J K
C D
G

FLUJO ENTRANTE FLUJO DE FLUJO SALIENTE

TRANSFORMACION

CONTROLADOR
PRINCIPAL

CONTROLADOR CONTROLADOR CONTROLADOR

DEL FLUJO DEL FLUJO DE DEL FLUJO
ENTRANTE TRANSFORMACION SALIENTE

En la parte superior de la estructura del programa se encuentra un módulo de control, que

sirve para coordinar las funciones de control subordinadas, que son:

a). Controlador del procesamiento de la información entrante, que coordina la recepción

de todos los datos que llegan
b). Controlador del centro de transformación, que supervisa todas las operaciones sobre
los datos en su forma interna
c). Controlador del procesamiento de la información saliente, que coordina la producción
de la información que sale.

Cada módulo de control tiene un nombre que indica la función de los módulos subordinados
que controla.

6. Realizar descomposición de segundo nivel: se realiza mediante la conversión de las trans-

formaciones individuales (burbujas) de un DFD, en los módulos correspondientes a la estruc-
tura del programa.
Comenzando dentro de los límites del centro de transformación y yendo hacia fuera a través
de los caminos de entrada y luego de salida, las transformaciones se convierten en niveles su-
bordinados de la estructura de control.

.- 4 -.
Ingeniería del Software. .- Diseño Estructurado.

CONTROLADOR
PRINCIPAL

CONTROLADOR CONTROLADOR CONTROLADOR

DEL FLUJO DEL FLUJO DE DEL FLUJO
ENTRANTE TRANSFORMACION SALIENTE

B D E F G H I

A C
J

Así obtenemos una estructura de programa inicial, también llamada Diagrama de Estructura.

Aunque hemos hecho una correspondencia uno a uno entre las burbujas del DFD y los módu-
los del software, también se pueden combinar 2 ó 3 burbujas, representándolas como un sólo
módulo, o tambien puede dividirse una burbuja en dos o más módulos.
Aunque los módulos que forman la estructura de programa tienen un nombre que indica la
función que realiza, se debe escribir para cada uno de ellos un breve texto que explique su
procesamiento.

La información que contendrá es:

• La información que entra y la que sale del módulo
• La información que es retenida en el módulo (ejemplo: en almacenamientos de datos)
• Explicación del procedimiento, indicando los principales puntos de decisión y las tareas.
• Tratamiento de las restricciones y características especiales, si las hay.

7. Refinar la estructura inicial del programa usando heurísticas para mejorar la calidad del
sofware.
La estructura inicial del programa siempre puede refinarse aplicando los fundamentos de di-
seño, por ello, se puede aumentar o reducir el número de módulos para obtener una descom-
posición con una buena cohesión, un mínimo acoplamiento, una estructura de fácil implemen-
tación, prueba y mantenimiento.
Los refinamientos se rigen por consideraciones prácticas y de sentido común.
Hay ocasiones en las que el controlador de flujo de datos entrante/saliente es innecesario, o
se requiere un procesamiento de la entrada en un módulo subordinado al controlador de

.- 5 -.
 Ingeniería del Software. .- Diseño Estructurado.

transformaciones, o no se puede conseguir un bajo acoplamiento por la necesidad de trabajar

con datos globales.

Conclusión :
• El objetivo que se quiere conseguir con la aplicación de estos pasos, es el desarrollo de una
Representación general del software.
• Podremos evaluar y refinar la arquitectura del software considerando que es la base de la ca-
lidad y fácil mantenimiento del software.

5. ANÁLISIS DE TRANSACCIÓN.
Cuando en un sistema hay un flujo de transacción, dependiendo del valor de ese elemento-
transacción, se seguirá uno u otro camino de acción de todos los posibles.

Pasos a seguir:
1. Revisar el modelo fundamental del sistema.
2. Revisar y refinar los DFD.
3. Determinar si el DFD tiene características de transformación o de transacción.
4. Identificar el centro de transacción y las características del flujo de cada camino de acción.
El centro de acción se localiza fácilmente en el DFD, es el origen de varios caminos de infor-
mación que fluyen radialmente de él. También deben aislarse el camino entrante y todos los
caminos de acción.
5. Transformar el DFD en una estructura de software adecuada al procesamiento de tran-
sacciones. El flujo de transacción se convierte en una estructura de programa que contiene
una rama entrante y una rama de distribución.
• la rama entrante se obtiene igual que el análisis de transformación, desde el centro de tran-
sacción hacia fuera, se convierten las burbujas en módulos.
• la rama de distribución tiene un módulo distribuidor que controls todos los módulos de ac-
ción subordinados.
El flujo de cada camino de acción del DFD se convertirá en una estructura que se corres-
ponda con las características del flujo (de transformación o de transacción).

Ejemplo:

E
C3 D
H
A B C
C2 F
G
C1 I
J
K
L M

.- 6 -.
 Ingeniería del Software. .- Diseño Estructurado.

CONTROL DE
TRANSACCION

CONTROL DEL C
DISTRIBUIDOR
FLUJO ENTRANTE

CAMINO 1 CAMINO 2 CAMINO 3

B

K L M

A J

6. Descomponer y refinar la estructura de transaccion y la estructura de cada camino de ac-

ción. Cada camino de acción del DFD tiene sus propias características de flujo de informa-
ción o de transacción. La subestructura de cada camino de acción se obtiene siguiendo los
pasos del análisis correspondiente.

7. Refinar la estructura inicial del software usando heurísticas de diseño para mejorar la ca-
lidad.
Idem anterior.

6. HEURÍSTICAS DE DISEÑO
La Heurística es un método de resolver problemas utilizando técnicas de ensayo y error. El dise-
ño heurístico de programas provee de un marco para resolver el problema en contraposición con un
conjunto fijo de reglas que no pueden variar.

Estas heurísticas de diseño consisten en los siguientes pasos:

1. Evaluar la estructura de programa preliminar para reducir el acoplamiento y mejorar la

cohesión. Los módulos pueden expandirse o reducirse siempre que se mejore la independencia
de los módulos. A menudo se produce un módulo expandido cuando en dos o más módulos
existe un componente de procesamiento común y puede redefinirse como un módulo cohesivo
aparte.

2. Intentar minimizar las estructuras con alto grado de salida, fomentar un alto grado de entra-
da conforme aumente la profundidad.

Ejemplo:

.- 7 -.
 Ingeniería del Software. .- Diseño Estructurado.

Se trata de evitar esto

y conseguir esto

3. Mantener el efecto de un módulo dentro del ámbito de control de ese módulo.

El ámbito del efecto de un módulo m se define por todos los módulos que quedan afectados por
una decisión tomada en el módulo m.
El ámbito de control del módulo m está formado por todos sus módulos subordinados.

Ejemplo:

Se trata de evitar esto y conseguir esto

Efecto de
la decisión
Decisión Decisión

Efecto de la
decisión

4. Evaluar los interfaces de los módulos para reducir la complejidad y la redundancia y mejo-
rar la consistencia. Quiere decir que se debe revisar la información que se pasa en los interfaces
para pasar únicamente la información necesaria.

5. Definir módulos cuyas funciones sean predecibles, para evitar módulos que sean demasiado
restrictivos.

6. Fomentar módulos con entrada única y salida única, evitando las “conexiones patológicas”.
El software es más fácil de comprender y mantener cuando se entra a los módulos por el princi-
pio y se sale por el final.
.- 8 -.
 Ingeniería del Software. .- Diseño Estructurado.

7. Empaquetar el software de acuerdo con las restricciones del diseño y los requisitos de porta-
bilidad.

7. DISEÑO PROCEDIMENTAL
Se realiza despues de que se ha establecido la estructura del programa y de los datos. Debe es-
pecificar los detalles de los procedimientos sin ambigüedad.
Los fundamentos del diseño procedimental se establecieron cuando se propuso el uso de un con-
junto de construcciones lógicas con las que podía formarse cualquier programa.

Las construcciones son: la secuencia ; la condición ; y la repetición.

Estas tres construcciones son fundamentales en la programación estructurada. Las construccio-

nes estructuradas se propusieron para limitar el diseño procedimental del software a un conjunto
reducido de operaciones predecibles, facilitando la legibilidad, prueba y mantenimiento de los pro-
gramas.

La CONDICION
La SECUENCIA
CONDICION
PRIMERA
TAREA F T
PARTE PARTE
ELSE THEN
SEGUNDA
TAREA

IF - THEN - ELSE
La SELECCIÓN

PARTE DEL
F CASO

CASOS DE T
CONDICIÓN

.- 9 -.
Ingeniería del Software. .- Diseño Estructurado.

La REPETICION

CUERPO
CONDICION T DEL BUCLE
DEL BUCLE

WHILE - DO

CUERPO
DEL BUCLE

CONDICION F
DEL BUCLE

T
REPEAT - UNTIL

NOTACIONES GRÁFICAS DE DISEÑO.

• El DIAGRAMA DE FLUJO u ORGANIGRAMA es la representación gráfica más amplia-

mente usada para el diseño procedimental. Como ya hemos visto en el gráfico anterior, la no-
tación es la siguiente:
un paso de procesamiento
Las construcciones estruc-
turadas pueden estar anidadas
una condición lógica unas en otras, desarrollando
de esta forma esquemas lógi-
flujo de control cos complejos.

• El DIAGRAMA DE CAJAS:
CONDICION
TAREA1
F T
TAREA2
...
PARTE PARTE
SECUENCIA
ELSE THEN

IF - THEN - ELSE

.- 10 -.
Ingeniería del Software. .- Diseño Estructurado.

CONDICION BUCLE CASO DE CONDICION

PARTE
WHILE - DO
VALOR VALOR . . .

PARTE PARTE
DEL DEL
PARTE CASO CASO
REPEAT - UNTIL

SELECCION

CONDICION BUCLE
REPETICION

NOTACIONES TABULARES DE DISEÑO:

Las Tablas de Decisión nos permiten representar las condiciones y acciones que se han de
contemplar en un módulo.

Condiciones y Acciones Reglas

Condiciones Alternativas de la condición
Acciones Registro de las Acciones

Ejemplo: Política de Ventas de un Almacén

Reglas
Condiciones y Acciones 1 2 3 4 5 6 3+6

Cantidad < 50.000 Pts. ... S S S N N N ---

Pago al contado S N N S N N N
Pago con cheque N S N N S N N
Pago con tarjeta N N S N N S S
Registrar la venta . X X X
Autorizar por el supervisor X
Comprobar crédito tarjeta X X X
X
Regla 5 ⇒ Si el total NO es inferior de 50.000 Pts. y el cliente NO paga al contado y Paga con
cheque y NO paga con tarjeta,
Entonces la venta se autorizará por el supervisor

.- 11 -.
Ingeniería del Software. .- Diseño Estructurado.

OFERTA DE TRABAJOS. SELECCION.

R E G L A S
Condiciones y Acciones 1+2 1 2 3 4 5 6 7 8
Está trabajando N N N N N S S S S
Tiene cargas familiares N N N S S N N S S
Recibe ayuda estado (sub- -- N S N S N S N S
sidio)
Añadir a lista preferente X X
Añadir a lista ordinaria X X X X X

Para construir la tabla de decisión se define su tamaño máximo, eliminando cualquier situación
imposible.

Para desarrollar una tabla de decisión se aplican los siguientes pasos:

1. Listar todas las acciones que puedan realizarse

2. Listar todas las condiciones que puedan afectar a la condición
3. Rellenar todas las alternativas de la condición, eliminando posteriormente las situaciones
imposibles, contradictorias y redundantes
4. Asociar conjuntos específicos de condiciones con acciones determinadas. Es decir, deter-
minar las reglas.
5. Combinar las reglas donde sea aparente que una alternativa no implique diferencias en la
salida.

NOTACIÓN ALGORÍTMICA. LENGUAJE DE DISEÑO DE PROGRAMAS (LDP).

El LDP es el pseudocódigo de uso general, aunque existen LDP comerciales que permiten
traducirlo a representación gráfica (ej: Diagramas de flujo).
La diferencia entre un LDP y un lenguaje de programación de alto nivel real se encuentra
en el uso de texto descriptivo en las sentencias del LDP, por lo que no puede ser compilado.

Un lenguaje de diseño de programas debe tener las siguientes características:

a) Una sintaxis fija de palabras clave que permitan construir todas las construcciones
estructuradas, declarar datos y establecer características de modularidad.
b) Una sintaxis libre en lenguaje natural para describir las características del procesa-
miento.
c) Facilidades para la declaración de datos, incluyendo estructuras de datos simples y
complejas.
d) Un mecanismo de definición de subprogramas y de invocación, soportando los dis-
tintos modos de descripción de interfaces.
Normalmente se utiliza un lenguaje de programación de alto nivel como base para el LDP.

Anteriormente hemos visto distintas notaciones de diseño:

• Diagramas de Flujo
• Diagramas de Caja
• Tablas de Decisión
• Lenguaje de diseño de programas

.- 12 -.
 Ingeniería del Software. .- Diseño Estructurado.

Una notación de diseño debe conducir a una representación procedimental, que sea fácil de
comprender y revisar. También debe de facilitar la codificación.

8. RESUMEN

El diseño es técnicamente la parte central de la ingeniería del software.

El diseño da como resultado representaciones del software cuya calidad se puede evaluar.

Los conceptos de modularidad y de abstracción permiten al diseñador simplificar y reutilizar los

componentes del software.

El refinamiento es un mecanismo que permite representar sucesivas capas de detalle funcional.

La estructura de programa y de datos contribuyen a la visión general de la arquitectura del soft-

ware.

La notación del diseño, junto con los conceptos de programación estructurada, permite al dise-
ñador representar los detalles procedimentales, facilitando su traducción al código.

Las herramientas disponibles son:

• gráficas
• tabulares
• textuales

.- 13 -.