Ingeniera del Software. .- Diseo Estructurado.

.- 1 -.
TEMA - DISEO ESTRUCTURADO

1. INTRODUCCIN
Los mtodos de diseo del software se obtienen del estudio de cada uno de los tres dominios del
modelo de anlisis. El dominio de los datos, el funcional y el de comportamiento sirven de directriz
para la creacin del diseo.
En el diseo estructurado orientado al flujo de datos, partimos de la representacin del flujo de
la informacin obtenida en la fase de anlisis, donde la informacin 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 grfica para la
descripcin del flujo de la informacin.

1. DISEO DE DATOS
El impacto de la estructura de datos sobre la estructura del programa y la complejidad procedi-
mental hace que el diseo de datos tenga una gran influencia en la calidad del software. Los datos
bien diseados pueden conducir a una mejor estructura de programa, a una modularidad efectiva y
a una complejidad procedimental reducida.

2. DISEO ARQUITECTNICO
El objetivo principal del diseo arquitectnico es desarrollar una estructura de programa
modular y representar las relaciones de control entre los mdulos. 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 diseo orientado al flujo de datos es compatible con un amplio rango de areas de aplicacin.
Es particularmente til cuando se procesa secuencialmente la informacin y no existe ninguna es-
tructura jerrquica formal. De hecho, todo el software puede representarse como un diagrama de
flujo de datos. Ejemplo: aplicaciones con microprocesadores, procedimientos de anlisis num-
rico, procesos de control, etc.

3. EL PROCESO DEL DISEO ARQUITECTNICO
El diseo orientado al flujo de datos define varias representaciones que transforman el flujo de la
informacin en la estructura del programa.
El Diseo Orientado al Flujo de Datos permite una cmoda transformacin de las representacio-
nes de la informacin (DFD) a una descripcin de la estructura del programa. Este proceso debe
seguir los siguientes pasos:
1. Establecer el tipo de flujo de informacin.
- Flujo de transformacin.
- Flujo de transaccin.
2. Determinar los lmites del flujo.
3. Convertir el DFD en la estructura del programa
4. Definir la jerarqua de control descomponindola mediante par-
ticionamiento.
Ingeniera del Software. .- Diseo Estructurado.

.- 2 -.
5. Refinar la estructura resultante usando medidas y heursticas de
diseo
El tipo de flujo de informacin es lo que determina el mtodo de conversin requerido en el pa-
so 3.

FLUJO DE TRANSFORMACIN:
En un sistema, la informacin entra y sale en una forma del mundo exterior (entradas de teclado,
tonos telefnicos, imgenes de visualizacin,...). Esos datos externos, deben ser convertidos a
una forma adecuada para el procesamiento.





La informacin 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 transicin, los datos entrantes pasan a travs de un
centro de transformacin, 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 caractersticas decimos que es un Flujo de Transformacin.

FLUJO DE TRANSACCIN:
El flujo de transaccin se caracteriza por el movimiento de datos a travs de un camino de llega-
da que convierte la informacin del mundo exterior en una transaccin. Se evalua la transaccin
y deacuerdo con su valor, el flujo sigue por uno de los muchos caminos de accin.

FLUJO ENTRANTE FLUJO SALIENTE FLUJO de
TRANSFORMACION
REPRESENTACION EXTERNA REPRESENTACION INTERNA REPRESENTACION EXTERNA
TRANSACCION
CENTRO DE
TRANSACCION
T
CAMINOS

DE

ACCION
Suele ser una seleccin,
dependiendo del valor del
dato se va por un camino
o por otro.
Ingeniera del Software. .- Diseo Estructurado.

.- 3 -.
El centro del flujo de informacin desde el que emanan los caminos de accin se denomina Cen-
tro de Transaccin. Dentro de un flujo de transaccin, el flujo de informacin a travs de un
camino de accin puede tener caractersticas de flujo de transformacin.

En el DFD de un sistema, generalmente estarn presentes los dos tipos de flujos: el flujo de
transformacin y el flujo de transaccin.

El Diseo Orientado al Flujo de Datos comienza con una evaluacin del DFD a nivel 2 3. Se
establece el tipo de flujo de informacin y se definen los lmites del flujo que delimitan el centro de
transformacin o de transaccin. Se convierten las transformaciones (burbujas del DFD) en mdu-
los, como estructuras de programa. Se factoriza la estructura, es decir, los mdulos se definen y
organizan mediante una distribucin descendente del control en la estructura. Por ltimo se refina la
estructura obtenida.

4. ANALISIS DE TRANSFORMACIN
El anlisis de transformacin es un conjunto de pasos de diseo que permiten convertir un DFD,
con caractersticas de flujo de transformacin, en una plantilla predefinida para la estructura del
programa.

4.1.- PASOS DEL DISEO

Los pasos comienzan con una reevaluacin del trabajo hecho durante el anlisis 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 informacin 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 transformacin tiene una cohesin alta (es decir, cada transformacin ejecuta una
funcin sencilla y diferenciada) pudiendose implementar como un mdulo. En este paso se
llega al nivel que contiene suficiente detalle como para establecer un diseo inicial para la es-
tructura del programa.
3. Determinar si el DFD tiene caractersticas de transformacin o de transaccin: en general,
el flujo de informacin de un sistema podr representarse siempre como una transformacin.
Si tiene una caracterstica obvia de transaccin es conveniente tratarla como tal.
El diseador selecciona la caracterstica general del flujo basandose en la naturaleza prevale-
ciente del DFD.
Se aislan las regiones locales de flujo de transformacin o de transaccin, lo que nos permiti-
r refinar la estructura del programa posteriormente.
4. Aislar el centro de transformacin especificando los lmites de los flujos entrante y salien-
te: la interpretacin de los lmites es algo subjetivo dependiente del diseador, as es posible
obtener distintas soluciones alternativas variando los lmites del flujo. El diseador debe esta-
blecer unos lmites razonables.
5. Realizar una descomposicin de primer nivel: la estructura del programa representa una dis-
tribucin descendente del control. La descomposicin da como resultado una estructura de
programa en la que los mdulos de nivel superior toman las decisiones de ejecucin y los
mdulos de nivel inferior ejecutan la mayora del trabajo de entrada, de procesamiento y de
Ingeniera del Software. .- Diseo Estructurado.

.- 4 -.
salida. Los mdulos de nivel intermedio ejecutan algn control y realizan moderadas cantida-
des de trabajo.

Ejemplo:













En la parte superior de la estructura del programa se encuentra un mdulo de control, que
sirve para coordinar las funciones de control subordinadas, que son:

a). Controlador del procesamiento de la informacin entrante, que coordina la recepcin
de todos los datos que llegan
b). Controlador del centro de transformacin, que supervisa todas las operaciones sobre
los datos en su forma interna
c). Controlador del procesamiento de la informacin saliente, que coordina la produccin
de la informacin que sale.

Cada mdulo de control tiene un nombre que indica la funcin de los mdulos subordinados
que controla.

6. Realizar descomposicin de segundo nivel: se realiza mediante la conversin de las trans-
formaciones individuales (burbujas) de un DFD, en los mdulos correspondientes a la estruc-
tura del programa.
Comenzando dentro de los lmites del centro de transformacin y yendo hacia fuera a travs
de los caminos de entrada y luego de salida, las transformaciones se convierten en niveles su-
bordinados de la estructura de control.


CONTROLADOR
PRINCIPAL
CONTROLADOR
DEL FLUJO
ENTRANTE
CONTROLADOR
DEL FLUJO DE
TRANSFORMACION
CONTROLADOR
DEL FLUJO
SALIENTE
B
C D
E
F
G
H I J K
FLUJO ENTRANTE FLUJO DE
TRANSFORMACION
FLUJO SALIENTE
A
Ingeniera del Software. .- Diseo Estructurado.

.- 5 -.

As obtenemos una estructura de programa inicial, tambin llamada Diagrama de Estructura.

Aunque hemos hecho una correspondencia uno a uno entre las burbujas del DFD y los mdu-
los del software, tambin se pueden combinar 2 3 burbujas, representndolas como un slo
mdulo, o tambien puede dividirse una burbuja en dos o ms mdulos.
Aunque los mdulos que forman la estructura de programa tienen un nombre que indica la
funcin que realiza, se debe escribir para cada uno de ellos un breve texto que explique su
procesamiento.

La informacin que contendr es:
La informacin que entra y la que sale del mdulo
La informacin que es retenida en el mdulo (ejemplo: en almacenamientos de datos)
Explicacin del procedimiento, indicando los principales puntos de decisin y las tareas.
Tratamiento de las restricciones y caractersticas especiales, si las hay.

7. Refinar la estructura inicial del programa usando heursticas para mejorar la calidad del
sofware.
La estructura inicial del programa siempre puede refinarse aplicando los fundamentos de di-
seo, por ello, se puede aumentar o reducir el nmero de mdulos para obtener una descom-
posicin con una buena cohesin, un mnimo acoplamiento, una estructura de fcil implemen-
tacin, prueba y mantenimiento.
Los refinamientos se rigen por consideraciones prcticas y de sentido comn.
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 mdulo subordinado al controlador de
CONTROLADOR
PRINCIPAL
CONTROLADOR
DEL FLUJO
ENTRANTE
CONTROLADOR
DEL FLUJO DE
TRANSFORMACION
CONTROLADOR
DEL FLUJO
SALIENTE
B D
C A
E F G H
I
J
K
Ingeniera del Software. .- Diseo Estructurado.

.- 6 -.
transformaciones, o no se puede conseguir un bajo acoplamiento por la necesidad de trabajar
con datos globales.

Conclusin :
El objetivo que se quiere conseguir con la aplicacin de estos pasos, es el desarrollo de una
Representacin general del software.
Podremos evaluar y refinar la arquitectura del software considerando que es la base de la ca-
lidad y fcil mantenimiento del software.

5. ANLISIS DE TRANSACCIN.
Cuando en un sistema hay un flujo de transaccin, dependiendo del valor de ese elemento-
transaccin, se seguir uno u otro camino de accin 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 caractersticas de transformacin o de transaccin.
4. Identificar el centro de transaccin y las caractersticas del flujo de cada camino de accin.
El centro de accin se localiza fcilmente en el DFD, es el origen de varios caminos de infor-
macin que fluyen radialmente de l. Tambin deben aislarse el camino entrante y todos los
caminos de accin.
5. Transformar el DFD en una estructura de software adecuada al procesamiento de tran-
sacciones. El flujo de transaccin se convierte en una estructura de programa que contiene
una rama entrante y una rama de distribucin.
la rama entrante se obtiene igual que el anlisis de transformacin, desde el centro de tran-
saccin hacia fuera, se convierten las burbujas en mdulos.
la rama de distribucin tiene un mdulo distribuidor que controls todos los mdulos de ac-
cin subordinados.
El flujo de cada camino de accin del DFD se convertir en una estructura que se corres-
ponda con las caractersticas del flujo (de transformacin o de transaccin).


Ejemplo:


A B C
D
E
F
G
H
I
J
K
L M
C
1

C
2

C
3

Ingeniera del Software. .- Diseo Estructurado.

.- 7 -.


6. Descomponer y refinar la estructura de transaccion y la estructura de cada camino de ac-
cin. Cada camino de accin del DFD tiene sus propias caractersticas de flujo de informa-
cin o de transaccin. La subestructura de cada camino de accin se obtiene siguiendo los
pasos del anlisis correspondiente.

7. Refinar la estructura inicial del software usando heursticas de diseo para mejorar la ca-
lidad.
Idem anterior.

6. HEURSTICAS DE DISEO
La Heurstica es un mtodo de resolver problemas utilizando tcnicas de ensayo y error. El dise-
o heurstico de programas provee de un marco para resolver el problema en contraposicin con un
conjunto fijo de reglas que no pueden variar.

Estas heursticas de diseo consisten en los siguientes pasos:

1. Evaluar la estructura de programa preliminar para reducir el acoplamiento y mejorar la
cohesin. Los mdulos pueden expandirse o reducirse siempre que se mejore la independencia
de los mdulos. A menudo se produce un mdulo expandido cuando en dos o ms mdulos
existe un componente de procesamiento comn y puede redefinirse como un mdulo cohesivo
aparte.

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

Ejemplo:
CONTROL DE
TRANSACCION
CONTROL DEL
FLUJO ENTRANTE
C

B

A
CAMINO 1 CAMINO 2 CAMINO 3
K L M
J
DISTRIBUIDOR
Ingeniera del Software. .- Diseo Estructurado.

.- 8 -.



3. Mantener el efecto de un mdulo dentro del mbito de control de ese mdulo.
El mbito del efecto de un mdulo m se define por todos los mdulos que quedan afectados por
una decisin tomada en el mdulo m.
El mbito de control del mdulo m est formado por todos sus mdulos subordinados.

Ejemplo:


4. Evaluar los interfaces de los mdulos para reducir la complejidad y la redundancia y mejo-
rar la consistencia. Quiere decir que se debe revisar la informacin que se pasa en los interfaces
para pasar nicamente la informacin necesaria.

5. Definir mdulos cuyas funciones sean predecibles, para evitar mdulos que sean demasiado
restrictivos.

6. Fomentar mdulos con entrada nica y salida nica, evitando las conexiones patolgicas.
El software es ms fcil de comprender y mantener cuando se entra a los mdulos por el princi-
pio y se sale por el final.
Se trata de evitar esto
y conseguir esto
Decisin
Efecto de
la decisin
Decisin
Efecto de la
decisin
Se trata de evitar esto y conseguir esto
Ingeniera del Software. .- Diseo Estructurado.

.- 9 -.

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

7. DISEO 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 ambigedad.
Los fundamentos del diseo procedimental se establecieron cuando se propuso el uso de un con-
junto de construcciones lgicas con las que poda formarse cualquier programa.

Las construcciones son: la secuencia ; la condicin ; y la repeticin.

Estas tres construcciones son fundamentales en la programacin estructurada. Las construccio-
nes estructuradas se propusieron para limitar el diseo procedimental del software a un conjunto
reducido de operaciones predecibles, facilitando la legibilidad, prueba y mantenimiento de los pro-
gramas.
































T
T
T
F
F
F
CASOS DE
CONDICIN
PARTE DEL
CASO
La SELECCIN
PRIMERA
TAREA
SEGUNDA
TAREA
La SECUENCIA
CONDICION
F T
PARTE
ELSE
PARTE
THEN
IF - THEN - ELSE
La CONDICION
Ingeniera del Software. .- Diseo Estructurado.

.- 10 -.
























NOTACIONES GRFICAS DE DISEO.

El DIAGRAMA DE FLUJO u ORGANIGRAMA es la representacin grfica ms amplia-
mente usada para el diseo procedimental. Como ya hemos visto en el grfico anterior, la no-
tacin es la siguiente:

Las construcciones estruc-
turadas pueden estar anidadas
unas en otras, desarrollando
de esta forma esquemas lgi-
cos complejos.



El DIAGRAMA DE CAJAS:










WHILE - DO
F
T
CONDICION
DEL BUCLE
CUERPO
DEL BUCLE
REPEAT - UNTIL
F
T
CONDICION
DEL BUCLE
CUERPO
DEL BUCLE
La REPETICION
un paso de procesamiento
una condicin lgica
flujo de control
CONDICION

F T


PARTE

ELSE


PARTE

THEN
IF - THEN - ELSE
TAREA1
TAREA2
. . .
SECUENCIA
Ingeniera del Software. .- Diseo Estructurado.

.- 11 -.




















NOTACIONES TABULARES DE DISEO:

Las Tablas de Decisin nos permiten representar las condiciones y acciones que se han de
contemplar en un mdulo.


Condiciones y Acciones Reglas
Condiciones Alternativas de la condicin
Acciones Registro de las Acciones


Ejemplo: Poltica de Ventas de un Almacn













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

3+6
---
N
N
S


X
X

Condiciones y Acciones
Reglas
1 2 3 4 5 6

Cantidad < 50.000 Pts. ...
Pago al contado
Pago con cheque
Pago con tarjeta
Registrar la venta .
Autorizar por el supervisor
Comprobar crdito tarjeta

S S S N N N
S N N S N N
N S N N S N
N N S N N S



X X X
X
X X
PARTE
REPEAT - UNTIL
CONDICION BUCLE
PARTE
WHILE - DO
CONDICION BUCLE
REPETICION
CASO DE CONDICION
VALOR

PARTE
DEL
CASO
. . . VALOR

PARTE
DEL
CASO
SELECCION
Ingeniera del Software. .- Diseo Estructurado.

.- 12 -.

OFERTA DE TRABAJOS. SELECCION.

Condiciones y Acciones

1+2

1
R
2
E
3
G
4
L
5
A
6
S
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-
sidio)
-- N S N S N S N S
Aadir a lista preferente X X
Aadir a lista ordinaria X X X X X

Para construir la tabla de decisin se define su tamao mximo, eliminando cualquier situacin
imposible.

Para desarrollar una tabla de decisin se aplican los siguientes pasos:

1. Listar todas las acciones que puedan realizarse
2. Listar todas las condiciones que puedan afectar a la condicin
3. Rellenar todas las alternativas de la condicin, eliminando posteriormente las situaciones
imposibles, contradictorias y redundantes
4. Asociar conjuntos especficos 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.


NOTACIN ALGORTMICA. LENGUAJE DE DISEO DE PROGRAMAS (LDP).

El LDP es el pseudocdigo de uso general, aunque existen LDP comerciales que permiten
traducirlo a representacin grfica (ej: Diagramas de flujo).
La diferencia entre un LDP y un lenguaje de programacin 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 diseo de programas debe tener las siguientes caractersticas:
a) Una sintaxis fija de palabras clave que permitan construir todas las construcciones
estructuradas, declarar datos y establecer caractersticas de modularidad.
b) Una sintaxis libre en lenguaje natural para describir las caractersticas del procesa-
miento.
c) Facilidades para la declaracin de datos, incluyendo estructuras de datos simples y
complejas.
d) Un mecanismo de definicin de subprogramas y de invocacin, soportando los dis-
tintos modos de descripcin de interfaces.
Normalmente se utiliza un lenguaje de programacin de alto nivel como base para el LDP.

Anteriormente hemos visto distintas notaciones de diseo:
Diagramas de Flujo
Diagramas de Caja
Tablas de Decisin
Lenguaje de diseo de programas
Ingeniera del Software. .- Diseo Estructurado.

.- 13 -.

Una notacin de diseo debe conducir a una representacin procedimental, que sea fcil de
comprender y revisar. Tambin debe de facilitar la codificacin.


8. RESUMEN

El diseo es tcnicamente la parte central de la ingeniera del software.

El diseo da como resultado representaciones del software cuya calidad se puede evaluar.

Los conceptos de modularidad y de abstraccin permiten al diseador 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 visin general de la arquitectura del soft-
ware.

La notacin del diseo, junto con los conceptos de programacin estructurada, permite al dise-
ador representar los detalles procedimentales, facilitando su traduccin al cdigo.

Las herramientas disponibles son:
grficas
tabulares
textuales