Ingeniera del Software.

.- Diseo Estructurado.

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 procedimental 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 estructura jerrquica formal. De hecho, todo el software puede representarse como un diagrama de flujo de datos. Ejemplo: aplicaciones con microprocesadores, procedimientos de anlisis numrico, 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 representaciones 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 particionamiento. .- 1 -.

Ingeniera del Software.

.- Diseo Estructurado.

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 paso 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.
REPRESENTACION EXTERNA REPRESENTACION INTERNA REPRESENTACION EXTERNA

FLUJO ENTRANTE

FLUJO de TRANSFORMACION

FLUJO SALIENTE

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. Cuando 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 llegada 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.

TRANSACCION

CAMINOS T DE ACCION

CENTRO DE TRANSACCION

Suele ser una seleccin, dependiendo del valor del dato se va por un camino o por otro.

.- 2 -.

Ingeniera del Software.

.- Diseo Estructurado.

El centro del flujo de informacin desde el que emanan los caminos de accin se denomina Centro 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 mdulos, 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 complementaria. 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 estructura 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 prevaleciente del DFD. Se aislan las regiones locales de flujo de transformacin o de transaccin, lo que nos permitir refinar la estructura del programa posteriormente. 4. Aislar el centro de transformacin especificando los lmites de los flujos entrante y saliente: 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 establecer unos lmites razonables. 5. Realizar una descomposicin de primer nivel: la estructura del programa representa una distribucin 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 .- 3 -.

Ingeniera del Software.

.- Diseo Estructurado.

salida. Los mdulos de nivel intermedio ejecutan algn control y realizan moderadas cantidades de trabajo. Ejemplo: A B E C D G FLUJO DE TRANSFORMACION FLUJO SALIENTE F H I J K

FLUJO ENTRANTE

CONTROLADOR PRINCIPAL

CONTROLADOR DEL FLUJO ENTRANTE

CONTROLADOR DEL FLUJO DE TRANSFORMACION

CONTROLADOR DEL FLUJO SALIENTE

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 transformaciones individuales (burbujas) de un DFD, en los mdulos correspondientes a la estructura 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 subordinados de la estructura de control.

.- 4 -.

Ingeniera del Software.

.- Diseo Estructurado.

CONTROLADOR PRINCIPAL

CONTROLADOR DEL FLUJO ENTRANTE

CONTROLADOR DEL FLUJO DE TRANSFORMACION

CONTROLADOR DEL FLUJO SALIENTE

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 mdulos 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 diseo, por ello, se puede aumentar o reducir el nmero de mdulos para obtener una descomposicin con una buena cohesin, un mnimo acoplamiento, una estructura de fcil implementacin, 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

.- 5 -.

Ingeniera del Software.

.- Diseo Estructurado.

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 calidad y fcil mantenimiento del software.

5. ANLISIS DE TRANSACCIN.
Cuando en un sistema hay un flujo de transaccin, dependiendo del valor de ese elementotransaccin, 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 informacin 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 transacciones. 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 transaccin hacia fuera, se convierten las burbujas en mdulos. la rama de distribucin tiene un mdulo distribuidor que controls todos los mdulos de accin subordinados. El flujo de cada camino de accin del DFD se convertir en una estructura que se corresponda con las caractersticas del flujo (de transformacin o de transaccin).

Ejemplo: E
C3

D H F G I J K L M

C
C2 C1

.- 6 -.

Ingeniera del Software.

.- Diseo Estructurado.

CONTROL DE TRANSACCION

CONTROL DEL FLUJO ENTRANTE

DISTRIBUIDOR

CAMINO 1 B K A J L M

CAMINO 2

CAMINO 3

6. Descomponer y refinar la estructura de transaccion y la estructura de cada camino de accin. Cada camino de accin del DFD tiene sus propias caractersticas de flujo de informacin 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 calidad. Idem anterior.

6. HEURSTICAS DE DISEO
La Heurstica es un mtodo de resolver problemas utilizando tcnicas de ensayo y error. El diseo 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 entrada conforme aumente la profundidad. Ejemplo:

.- 7 -.

Ingeniera del Software.

.- Diseo Estructurado.

Se trata de evitar esto

y conseguir esto

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: Se trata de evitar esto y conseguir esto

Efecto de la decisin

Decisin

Decisin Efecto de la decisin

4. Evaluar los interfaces de los mdulos para reducir la complejidad y la redundancia y mejorar 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 principio y se sale por el final. .- 8 -.

Ingeniera del Software.

.- Diseo Estructurado.

7. Empaquetar el software de acuerdo con las restricciones del diseo y los requisitos de portabilidad.

7. DISEO PROCEDIMENTAL
Se realiza despues de que se ha establecido la estructura del programa y de los datos. Debe especificar los detalles de los procedimientos sin ambigedad. Los fundamentos del diseo procedimental se establecieron cuando se propuso el uso de un conjunto 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 construcciones 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 programas. La SECUENCIA
PRIMERA TAREA PARTE ELSE SEGUNDA TAREA

La CONDICION CONDICION F T
PARTE THEN

IF - THEN - ELSE La SELECCIN T

PARTE DEL CASO

F
CASOS DE CONDICIN

T F T F

.- 9 -.

Ingeniera del Software.

.- Diseo Estructurado.

La REPETICION

CONDICION DEL BUCLE F WHILE - DO

CUERPO DEL BUCLE

CUERPO DEL BUCLE CONDICION DEL BUCLE T REPEAT - UNTIL NOTACIONES GRFICAS DE DISEO. El DIAGRAMA DE FLUJO u ORGANIGRAMA es la representacin grfica ms ampliamente usada para el diseo procedimental. Como ya hemos visto en el grfico anterior, la notacin es la siguiente: un paso de procesamiento una condicin lgica flujo de control Las construcciones estructuradas pueden estar anidadas unas en otras, desarrollando de esta forma esquemas lgicos complejos. F

El DIAGRAMA DE CAJAS: TAREA1 TAREA2 ... SECUENCIA

CONDICION F T

PARTE PARTE ELSE THEN

IF - THEN - ELSE .- 10 -.

Ingeniera del Software.

.- Diseo Estructurado.

CONDICION BUCLE PARTE WHILE - DO

CASO DE CONDICION

VALOR PARTE DEL CASO

VALOR PARTE DEL CASO

. . .

PARTE REPEAT - UNTIL

SELECCION CONDICION BUCLE REPETICION

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 Condiciones Acciones

Reglas Alternativas de la condicin Registro de las Acciones

Ejemplo: Poltica de Ventas de un Almacn Reglas 3 4 5

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

6 N N N S

3+6 --N N S

S S S N N S N N S N N S N N S N N S N N X X 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 -.

Ingeniera del Software.

.- Diseo Estructurado.

OFERTA DE TRABAJOS. SELECCION. R E G Condiciones y Acciones 1+2 1 2 3 4 Est trabajando N N N N N Tiene cargas familiares N N N S S Recibe ayuda estado (sub- -N S N S sidio) Aadir a lista preferente X X Aadir a lista ordinaria X X X

L 5 S N N

A 6 S N S

S 7 S S N

8 S S S

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, determinar 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 procesamiento. 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 distintos 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 .- 12 -.

Ingeniera del Software.

.- Diseo Estructurado.

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 software. La notacin del diseo, junto con los conceptos de programacin estructurada, permite al diseador representar los detalles procedimentales, facilitando su traduccin al cdigo. Las herramientas disponibles son: grficas tabulares textuales

.- 13 -.