Fundamentos del diseo de software

Fundamentos del diseo de software

El diseo es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniera. Definicin de diseo segn Taylor Proceso de aplicar distintas tcnicas y principios con el propsito de definir un dispositivo, proceso o sistema con los suficientes detalles como para permitir su realizacin fsica El diseo de software, al igual que los mtodos de diseo de todas las ingenieras, cambian continuamente al aparecer nuevos mtodos, mejores anlisis y ampliar los conocimientos. El problema es que el diseo de software se encuentra en una etapa relativamente temprana en su evolucin. La idea de realizar diseo de software en lugar de programar, surgi a principios de los aos 60, por lo que a las metodologas de diseo les falta la profundidad y la flexibilidad que tiene el diseo en otras ingenieras. Pero, ya existen tcnicas de diseo de software para poder evaluar la calidad del software. El objetivo de este tema es presentar los conceptos fundamentales que se pueden aplicar a todos los diseos de programas.

1. Ingeniera del software y diseo del software

Una vez que se han establecido los requisitos del software, el diseo es la primera de tres actividades tcnicas: diseo, codificacin y prueba. Cada actividad transforma la informacin de forma que al final se obtiene un software validado. El diseo es tcnicamente la parte central de la ingeniera del software. Durante el diseo se desarrollan, revisan y se documentan los refinamientos progresivos de las estructuras de datos, de la estructura del programa y de los detalles procedimentales. El diseo da como resultado representaciones cuya calidad puede ser evaluada. Mediante algunas metodologas de diseo se realiza el diseo de datos, el diseo arquitectnico y el diseo procedimental. El diseo de datos transforma el modelo de campo de informacin, creado durante el anlisis, en las estructuras de datos que se van a requerir para implementar el software. El diseo arquitectnico define las relaciones entre los principales elementos estructurales del programa. El diseo procedimental transforma los elementos estructurales en una descripcin procedimental del software.

A continuacin, se genera el cdigo fuente y, para integrar y validar el software, se llevan a cabo las pruebas.

Fundamentos del diseo de software

Las fases de diseo, codificacin y prueba absorben el 75% o ms del coste de la ingeniera del software (excluyendo el mantenimiento). Es aqu donde se toman las decisiones que afectarn finalmente al xito de la implementacin del programa, y tambin, a la facilidad de mantenimiento que tendr el software. Por tanto el diseo es un paso fundamental de la fase de desarrollo. El diseo es la nica forma mediante la que podemos traducir con precisin los requisitos del cliente en un producto o sistema acabado. El diseo de software es la base de todas las partes posteriores del desarrollo y de la fase de prueba, como muestra la figura 1.

Figura 1. Importancia del diseo Sin diseo, nos arriesgamos a construir un sistema inestable, un sistema que falle cuando se realicen pequeos cambios, un sistema que sea difcil de probar, un sistema cuya calidad no pueda ser evaluada hasta ms adelante, cuando quede poco tiempo y ya sea haya gastado mucho dinero.

2. El proceso de diseo
El diseo del software es un proceso mediante el que se traducen los requisitos en una representacin del software, que se acerca mucho al cdigo fuente. Desde el punto de vista de la gestin del proyecto, el diseo del software se realiza en dos etapas: el diseo preliminar y el diseo detallado. El diseo preliminar se centra en la transformacin de los requisitos en los datos y la arquitectura del software. El diseo detallado se ocupa del refinamiento y de la representacin arquitectnica que lleva a una estructura de datos refinada y a las representaciones algortimicas del software.

Adems del diseo de datos, del diseo arquitectnico y del desarrollo procedimental, muchas aplicaciones modernas requieren un diseo de la interfaz.

Fundamentos del diseo de software

Diseo de datos Diseo arquitectnico Punto de vista tcnico Diseo procedimental Diseo de la interfaz

Punto de vista gestin Diseo preliminar Diseo detallado * * * * * *

Figura 2. Relacin entre los puntos de vista de gestin y tcnicos 2.1. DISEO Y CALIDAD DEL SOFTWARE A lo largo del proceso de diseo, la calidad del diseo se evala mediante una serie de revisiones tcnicas formales (RTF) que son una actividad de garanta del software cuyos objetivos son: 1) Descubrir los errores en la funcin, la lgica o la implementacin de cualquier representacin del software. 2) Verificar que el software alcanza sus requisitos. 3) Garantizar que el software se ha representado segn los estndares establecidos. 4) Conseguir un software desarrollado de forma uniforme. 5) Hacer que los proyectos sean manejables. Cada RTF se lleva a cabo mediante una reunin y slo tendr xito si est bien planificada, controlada y atendida. A continuacin, se listan una serie de criterios para determinar la calidad del software. 1) Un diseo debe tener una organizacin jerrquica. 2) Un diseo debe ser modular, es decir, el software debe estar dividido en elementos que realicen funciones especficas. 3) Un diseo debe tener representaciones distintas y separadas de los datos y de los procedimientos. 4) Un diseo debe llevar a mdulos que exhiban caractersticas funcionales independientes. 5) Un diseo debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los mdulos y el exterior. 6) Un diseo debe obtenerse mediante un mtodo que sea reproducible y que est dirigido por la informacin obtenida durante el anlisis de requerimientos. Un buen diseo de software no se consigue fcilmente, resultando de la aplicacin de principios fundamentales de diseo, de una metodologa sistemtica y de una revisin exhaustiva.

Fundamentos del diseo de software

2.2. CARACTERSTICAS COMUNES DE LAS METODOLOGAS DE DISEO Independientemente de la metodologa de diseo que se utilice, todas tienen varias caractersticas comunes: 1) Mecanismo para la traduccin de requisitos en una representacin de diseo. 2) Notacin para representar los componentes funcionales y sus interfaces. 3) Heursticas para el refinamiento y la particin. 4) Criterios para la valoracin de la calidad. Independientemente de la metodologa de diseo que se utilice, el desarrollador tiene que aplicar una serie de conceptos fundamentales al diseo de datos, arquitectnico y procedimental.

3. Fundamentos del diseo

Los fundamentos del diseo ayudan al desarrollador de software a responder a estas preguntas: Qu criterios puedo utilizar para dividir el software en componentes individuales? Cmo se separan los detalles de una funcin o de la estructura de los datos de la representacin conceptual del software? Existen criterios uniformes que definan la calidad tcnica de un diseo de software?

Cita de Michael A. Jackson El principio de la sabidura de un programador est en reconocer la diferencia entre obtener un programa que funcione y uno que funcione correctamente. 3.1. ABSTRACCIN Cuando se considera una solucin modular para cualquier problema, pueden formularse varios niveles de abstraccin. En el nivel superior de abstraccin se establece una solucin en trminos generales, en lenguaje natural. En los niveles inferiores de abstraccin se utiliza una orientacin ms procedimental. Por ltimo, en el nivel ms bajo de abstraccin, se establece una solucin, de forma que pueda implementarse directamente. Cada paso de los procesos de la ingeniera del software es un refinamiento del nivel de abstraccin de la solucin software. Conforme nos movemos desde los preliminares hacia el diseo detallado, se reduce el nivel de abstraccin. Finalmente, el nivel ms bajo de abstraccin se alcanza cuando se genera el cdigo fuente.
4

Fundamentos del diseo de software

Conforme nos movemos por los diferentes niveles de abstraccin, trabajamos para crear abstracciones de datos y de procedimientos. Una abstraccin de datos es un conjunto de datos que describen un objeto, como puede ser el DNI de una persona, que est compuesta por conjunto de partes de informacin, pero que nos podemos referir a todos los datos mencionando el nombre de la abstraccin de datos. Una abstraccin procedimental es una determinada secuencia de instrucciones que tienen una funcin limitada y especfica, como puede ser mover objeto, que supone la secuencia de pasos abrir pinza, mover hasta posicin de destino 1, cerrar pinza, mover hasta posicin 2, abrir pinza, mover hasta posicin origen, cerrar pinza.

Estas abstracciones permiten al diseador representar un objeto a diferentes niveles de detalle. 3.2. REFINAMIENTO El refinamiento sucesivo es una primera estrategia de diseo descendente propuesta por Niklaus Wirth. La arquitectura de un programa se desarrolla en niveles sucesivos de refinamiento de los detalles procedimentales. Se desarrolla una jerarqua descomponiendo una funcin de forma sucesiva hasta que se llega a las sentencias del lenguaje de programacin. Comenzamos con una declaracin de la funcin (o una descripcin de la informacin) definida a un nivel superior de abstraccin. Es decir, la declaracin describe la funcin o la informacin conceptualmente, pero no proporciona informacin sobre el funcionamiento interno de la funcin o sobre la estructura interna de la informacin, sino que se va a realizando sucesivamente, dando cada vez ms detalles. 3.3. MODULARIDAD El software se divide en componentes con nombres y ubicaciones determinados, que se denominan mdulos y que se integran para satisfacer los requisitos del proveedor. El software monoltico (es decir, un programa grande compuesto de un solo mdulo) no puede ser estudiado fcilmente por un lector, ya que el nmero de caminos de control, el nmero de variables y la complejidad global haran el cdigo prcticamente indescifrable. Mtemticamente, esto se explica de esta forma: Sea C(x) una funcin que defina la complejidad de un problema x, y E(x) una funcin que defina el esfuerzo de desarrollo de un problema x.

Fundamentos del diseo de software

Para dos problemas p1 y p2, si se deduce que Adems, se cumple que y que

C(p1) > C(p2) E(p1) > E(p2)

C(p1 + p2) > C(p1) + C(p2) E(p1 + p2) > E(p1) + E(p2)

Esto nos lleva a la conclusin divide y vencers, por tanto la modularidad del software facilita el desarrollo del mismo, pero hasta un cierto lmite, porque si llegramos a dividir el problema en infinitos mdulos, los mdulos tendran una complejidad y un esfuerzo mucho menor, pero crecera el coste asociado a la creacin de interfaces entre los mdulos, tal y como muestra la figura 3.

Figura 3. Modularidad y coste del software 3.4. ARQUITECTURA DEL SOFTWARE La arquitectura del software se refiere a dos caractersticas importantes del software: La estructura jerrquica de los mdulos del software La estructura de los datos La arquitectura del software se obtiene mediante un proceso de particin, que relaciona los problemas del mundo real (definidos en el anlisis de requerimientos) con las soluciones software para resolver los problemas software.

Figura 4. Evolucin de la estructura

6

Fundamentos del diseo de software

Este proceso de transicin entre el anlisis de requerimientos y el diseo se representa es el que representa la figura 4. 3.5. JERARQUA DE CONTROL Tambin se le conoce como estructura del programa, y representa la organizacin jerrquica de los mdulos de un programa e implica una jerarqua de control. La representacin de jerarqua se suele representar con diagramas de rbol, aunque tambin se pueden utilizar otros tipos de notaciones. La figura 5 muestra un ejemplo de una estructura de un programa.

Figura 5. Estructura de un programa A continuacin definiremos los algunos trminos relacionados con la figura 5. Profundidad: Nmero de niveles de control Anchura: Amplitud global del control Grado de salida: Nmero de mdulos que controla un mdulo Grado de entrada: Nmero de mdulos que controlan a un mdulo Visibilidad: Conjunto de componentes del programa que pueden ser invocados por un mdulo (Herencia en entornos de POO). Todos los objetos seran visibles para el mdulo Conectividad: Conjunto de componentes a los que se invoca directamente o se utilizan sus datos. (La ejecucin de un mdulo puede suponer la ejecucin de otro mdulo) 3.6. ESTRUCTURA DE DATOS La estructura de datos es una representacin de la lgica que existe entre los elementos individuales de informacin. Debido a que la estructura de la informacin afectar de forma determinante al diseo procedimiental, la estructura de datos es tan importante como la estructura del programa en la representacin de la arquitectura del software. La estructura de datos dicta la organizacin, los mtodos de acceso, el grado de asociatividad y las alternativas para el tratamiento de la informacin.

Fundamentos del diseo de software

Las estructuras de datos clsicas son los elementos escalares, los arrays, las listas y los rboles. 3.7. PROCEDIMIENTOS DEL SOFTWARE La estructura del programa define la jerarqua de control, independientemente de las decisiones y secuencias de procesamiento. El procedimiento del software se centra en los detalles de procesamiento de cada mdulo individual, como muestra la figura 6.

Figura 6. Procedimiento dentro de un mdulo El procedimiento debe proporcionar una especificacin precisa del procesamiento, incluyendo la secuencia de sucesos, los puntos concretos de decisiones, la repeticin de operaciones e incluso la organizacin/estructura de los datos. Como existe una relacin entre la estructura y el procedimiento, ya que el procesamiento de un mdulo puede suponer la llamada a otros mdulos. A esto se le conoce como representacin procedimental del software por capas, como muestra la figura 7

Figura 7. Procedimiento realizado por capas

8

Fundamentos del diseo de software

3.8. OCULTAMIENTO DE INFORMACIN El concepto de modularidad nos lleva a esta pregunta: cmo descomponer una solucin de software en el mejor conjunto de mdulos? El principio de ocultamiento de la informacin sugiere que los mdulos deben especificarse de forma que la informacin (procedimientos y datos) contenida dentro de un mdulo sea inaccesible a otros mdulos que no necesiten tal informacin. Por tanto se trata de definir una serie de mdulos independientes que se comuniquen slo a travs de la informacin necesaria para realizar la funcin de software. El uso de ocultamiento de informacin en el diseo facilitar las modificaciones, prueba y mantenimiento del software, ya que como la mayora de los datos y de los procedimientos estn ocultos a otras partes del software, ser menos probable que los errores que se introduzcan durante la modificacin se propaguen a otros mdulos del software.

4. Diseo modular efectivo

Todos los fundamentos del diseo anteriores sirven para incentivar los diseos modulares. Un diseo modular: Reduce la complejidad Facilita los cambios Implementacin ms sencilla Permite el desarrollo paralelo de partes diferentes de un sistema 4.1. TIPOS DE MDULOS Para la definicin de mdulos en una arquitectura de software se utiliza la abstraccin y ocultamiento de informacin. Estos atributos tienen que ser traducidos a las caractersticas de ejecucin del mdulo, caracterizadas por el historial de ejecucin, el mecanismo de activacin y el camino de control, y que describimos a continuacin: El historial de incorporacin se refiere al momento en que se incluye el mdulo en la descripcin del software en lenguaje fuente. El mecanismo de activacin se refiere a la forma en que se invoca a un mdulo, que puede ser de referencia (mediante una llamada) o de interrupcin (en aplicaciones en tiempo real, ocurre un evento en el mundo exterior) El camino de control de un mdulo describe la forma en que se ejecuta internamente, y son los que se describen a continuacin. 4.1.1. Mdulos secuenciales Se ejecutan sin interrupcin aparente por parte del software de la aplicacin, es decir ejecutan secuencialmente una tarea.

Fundamentos del diseo de software

4.1.2. Mdulos incrementales Tambin se les conoce como corrutinas, y pueden ser interrumpidos antes de que terminen por el software de la aplicacin, y restablecerse posteriormente su ejecucin en el punto en que se interrumpi. 4.1.3. Mdulos paralelos Un mdulo paralelo se ejecuta a la vez que otro mdulo en entornos multiprocesadores. 4.2. INDEPENDENCIA FUNCIONAL La independencia funcional es una derivacin directa de la modularidad, de la abstraccin y del ocultamiento de informacin. La independencia funcional se adquiere desarrollando mdulos con una funcin clara y con pocas relaciones con otros mdulos, de forma que cada mdulo se centra en una subfuncin especfica de los requerimientos y tenga una interfaz sencilla. Esta independencia tiene varias consecuencias positivas como son: Mdulos independientes fciles de desarrollar Creacin de interfaces sencillas Facilidad para la prueba y el mantenimiento Se reduce la propagacin de errores Se fomenta la reutilizacin de mdulos. La independencia se mide con dos criterios cualitativos que son la cohesin y el acoplamiento. 4.2.1. Cohesin La cohesin es una extensin del concepto de ocultamiento de informacin. Un modulo cohesivo ejecuta una tarea sencilla de un procedimiento de software y requiere poca interaccin con procedimientos que ejecutan otras partes de un programa. Dicho de forma sencilla, un mdulo cohesivo slo hace (idealmente) una cosa. Por tanto el diseador debe comprender lo que es la cohesin y evitar la baja cohesin en el diseo de los mdulos.

Figura 8. Representacin de la escala de cohesin

10

Fundamentos del diseo de software

Lo importante es intentar conseguir una cohesin alta y saber reconocer la cohesin baja, de forma que pueda modificar el diseo del software para tener de una mayor independencia funcional. 4.2.2 Acoplamiento El acoplamiento es una medida de la interconexin entre los mdulos de una estructura de programa. El acoplamiento depende de la complejidad de las interfaces entre los mdulos y de los datos que pasan a travs de la interfaz. En el diseo de software buscamos el acoplamiento ms bajo posible. Una conectividad sencilla entre mdulos da como resultado un software ms fcil de comprender y menos propenso al efecto onda (propagacin de errores a lo largo del sistema).

5. Diseo de datos
El diseo de datos es la primera de las tres actividades de diseo realizadas durante la ingeniera del software. El impacto de la estructura de datos sobre la estructura de programa y la complejidad procedimental, hace que el diseo de datos tenga una gran influencia en la calidad del software. Los conceptos de ocultamiento de informacin y de abstraccin de datos conforman la base de los mtodos de diseo de datos. Segn Wasserman La actividad principal durante la fase de diseo de datos es la seleccin de las representaciones lgicas de las estructuras de datos, identificados durante las fases de definicin y especificacin de requerimientos. Una actividad importante durante el diseo es la de identificar los mdulos de programa que deben operar directamente sobre las estructuras de datos. De esta forma, puede restringirse el mbito del efecto de las decisiones concretas de diseo de datos. Los datos bien diseados conducen a: Mejor estructura de programa Modularidad efectiva Complejidad procedimental reducida 5.1. PRINCIPIOS PARA LA ESPECIFICACIN DE DATOS Los principios que se citan a continuacin son la base del mtodo de diseo de datos, y una definicin clara de la informacin es esencial para el desarrollo de un buen software. 1. Los principios sistemticos de anlisis aplicados a la funcin y el comportamiento tambin deben aplicarse a los datos. Al igual que en la fases de anlisis del sistema, tambin se debe:

11

Fundamentos del diseo de software

Desarrollar y revisar las representaciones del flujo y del contenido de los datos. Identificar las estructuras de datos. Considerar estructuras de datos alternativas. Evaluar el impacto de la modelizacin de datos sobre el diseo del software

Por ejemplo, la especificacin de una lista enlazada circular puede satisfacer los requerimientos de los datos, pero tambin puede conducir a un diseo del software difcil de manejar, por lo que deberemos ver si existen otras estructuras de datos alternativas que lleven a resultados mejores. 2. Se deben identificar todas las estructuras de datos y las operaciones que se han de realizar sobre cada una de ellas. El diseo de una estructura eficiente debe tener en cuenta las operaciones que han de realizarse sobre dicha estructura de datos. Por ejemplo, la especificacin de un tipo abstracto de datos puede simplificar considerablemente el diseo del software. 3. Debe establecerse y usarse un diccionario de datos para definir el diseo de los datos y del programa. Un diccionario de datos representa explcitamente las relaciones entre los datos y las restricciones sobre los elementos de una estructura de datos. 4. Se deben posponer las decisiones de diseo de datos de bajo nivel hasta ms adelante en el proceso de datos. Para el diseo de datos puede seguirse un proceso de refinamiento sucesivo, es decir, puede definirse una organizacin global de los datos durante el anlisis de requerimientos, refinarse durante el diseo preliminar y especificarse en detalle en el diseo detallado. 5. La representacin de una estructura de datos slo debe ser conocida por los mdulos que hagan uso directo de los datos contenidos en la estructura. El concepto de ocultamiento de informacin y el concepto de acoplamiento asociado proporcionan una valoracin importante de la calidad del diseo del software. 6. Se debe desarrollar una librera de estructuras de datos tiles y de las operaciones que se le pueden aplicar. Se pueden disear las estructuras de datos de forma que sean reusables, de forma que las estructuras de datos y las operaciones se vean como recursos para el diseo de software.

12

Fundamentos del diseo de software

7. El diseo de software y el lenguaje de programacin deben soportar la especificacin y realizacin de tipos abstractos de datos. La implementacin de una estructura de datos compleja puede convertirse en una tarea muy difcil si no hay una forma directa de realizar una especificacin directa de la estructura de datos.

6. Diseo arquitectnico
El objetivo principal del diseo arquitectnico es desarrollar una estructura de programa modular y representar las relaciones de control entre los mdulos. Adems el diseo arquitectnico mezcla la estructura de programas y la estructura de datos y define las interfaces que facilitan el flujo de los datos a lo largo del programa. Se trata de no centrarse en los detalles y cdigo de los procedimientos (tareas que se realizan ms adelante) sino en centrarse en la arquitectura del software que permita obtener una visin general del software.

7. Diseo procedimental
EL diseo procedimental se realiza despus de que se ha establecido la estructura del programa y de los datos. La especificacin procedimental que define los algoritmos, cabe pensar que se podra especificar en lenguaje natural, pero debido a la cantidad de ambigedades que este lenguaje acarrea, es necesario utilizar una forma ms restringida de representacin. 7.1. PROGRAMACIN ESTRUCTURADA A finales de los 60 se propuso la utilizacin de un conjunto de construcciones lgicas con las que poda formarse cualquier programa. Cada construccin tena estructura lgica predecible. Se entra por ella por el principio, se sale por el final y facilita al lector el seguimiento del flujo procedimental. Las construcciones son secuencia, condicin y repeticin, y son fundamentales en la programacin estructurada. La secuencia implementa los pasos de procedimiento esenciales de la especificacin de cualquier algoritmo. La condicin da la posibilidad de seleccionar un procedimiento basndose en alguna ocurrencia lgica. La repeticin proporciona iteracin. Las construcciones estructuradas se propusieron para limitar el diseo procedimental del software a un nmero pequeo de operaciones predecibles, lo que facilita la legibilidad, prueba y mantenimiento del software.

13

Fundamentos del diseo de software

Adems, la notacin debe facilitar la codificacin, de forma que el cdigo se obtenga de forma natural a partir del diseo. 7.1.1. Notaciones para la representacin grfica en diseo procedimental Para evitar desarrollar un software errneo, es fundamental que se utilicen correctamente las herramientas grficas para el diseo, como son los diagramas de flujo y los diagramas de cajas. Diagrama de flujo Es la representacin grfica que ms se utiliza en el diseo procedimental. Para representar un paso de procesamiento se utiliza un cuadro, para representar una condicin se utiliza un rombo, y para representar el flujo de control se utilizan flechas.

Figura 9. Construcciones de programacin estructurada con diagramas de flujo Las construcciones estructuradas pueden estar anidadas unas dentro de otras, cada una de estas puede realizar llamadas a mdulos, teniendo entonces una disposicin por capas procedimentales en un diagrama de flujo estructurado, como muestra la figura 10.

Figura 10. Un diagrama de flujo estructurado

14

Fundamentos del diseo de software

A veces, el restringirse al uso exclusivo de construcciones estructuradas puede introducir complicaciones en el flujo lgico. Por ejemplo, supongamos que como parte del proceso i surge una condicin, z, que requiere una bifurcacin inmediata al proceso j. Una bifurcacin directa violar la construccin lgica, escapando del dominio funcional de la sentencia repeat-until, de la cual forma parte el proceso i. Para implementar la bifurcacin anterior sin violar las caractersticas de las condiciones estructuradas, sera necesario aadir la condicin z a x7 y a x8. Estas comprobaciones se realizaran continuamente, incluso aunque no fuese necesario la ocurrencia de la z. De esta forma, habramos introducido una condicin adicional y una eficiencia en la ejecucin. Entonces qu podemos hacer?. El diseador tiene dos opciones: Redisear la representacin procedimental, de forma que no sea necesaria la bifurcacin de escape en una posicin interior del flujo de control. Violar las construcciones estructuradas de forma controlada, es decir, disear una bifurcacin restringida hacia fuera del flujo anidado. Diagrama de cajas Esta notacin surgi del deseo de desarrollar una representacin para el diseo procedimental que no permitiera la violacin de construcciones estructuradas. Estos diagramas fueron desarrollados por Nassi y Schneiderman y perfeccionados por Chapin.y tienen las caractersticas siguientes: El mbito funcional est bien definido y es claramente visible. La transferencia de control arbitraria es imposible. Es fcil determinar el mbito de los datos locales y globales La recursividad es fcil de representar La representacin grfica de construcciones estructuradas, usando diagramas de cajas, se muestra en la figura 11. El elemento fundamental del diagrama de cajas es la caja.

Figura 11. Construcciones en diagramas de cajas

15

Fundamentos del diseo de software

Al igual que con los diagramas de flujo, se pueden crear diagramas de cajas por capas en mltiples pginas. Se puede representar una llamada a un mdulo subordinado mediante una caja con el nombre del mdulo encerrado dentro de una circunferencia. La figura 12 muestra un diagrama de cajas que representa el mismo flujo de control que el de la figura 10.

Figura 12. Un diagrama de cajas estructurado Para ver la relativa facilidad con que puede comprenderse el dominio funcional, puede observarse el bucle repeat-until con la condicin x8. Todas las construcciones lgicas contenidas dentro del bucle se encuentran fcilmente, debido a que estn dispuestas en cajas interiores. 7.1.2. Notaciones tabulares de diseo En muchas aplicaciones de software puede ser necesario que un mdulo evale una compleja combinacin de condiciones, y de acuerdo con ellas, seleccione la opcin adecuada. Las tablas de decisin constituyen una notacin que traduce las acciones y condiciones a una forma tabular.

Figura 13. Esqueleto de una tabla de decisin

16

Fundamentos del diseo de software

La figura 13 muestra la organizacin de una tabla de decisin, que est dividida en cuatro cuadrantes por las lneas gruesas. El cuadrante superior izquierdo contiene una lista de todas las condiciones El cuadrante inferior izquierdo contiene una lista de todas las acciones que se pueden realizar en funcin de las condiciones Los cuadrantes de la derecha forman una matriz que contienen las combinaciones de las condiciones para producir las acciones. Por tanto, cada columna de la matriz representa una regla de procesamiento. Los pasos para la creacin de una tabla de decisin son los siguientes: Listar todas las acciones que se pueden asociar a un mdulo. Listar todas las condiciones necesarias para la ejecucin de un procedimiento. Asociar conjuntos de condiciones especficas a acciones especficas, eliminando combinaciones imposibles. Desarrollar las posibles combinaciones de condiciones. Definir reglas indicando las acciones que ocurren para una serie de condiciones. 7.1.3. Lenguaje de diseo de programas Un lenguaje de diseo de programas (LDP), tambin conocido como lenguaje estructurado o pseudocdigo es un lenguaje que utiliza el vocabulario de un lenguaje y la sintaxis de otro. Independientemente de su origen, un LDP tiene que tener las caractersticas siguientes: Una sintaxis fija de palabras clave que permitan construir todas las construcciones estructuradas, declarar datos y establecer caractersticas de modularidad. Una sintaxis libre en lenguaje natural para describir las caractersticas de procesamiento. Facilidades para la declaracin de datos, incluyendo estructuras de datos simples y complejas. Un mecanismo de definicin de subprogramas y de llamada a stos.

17

Fundamentos del diseo de software

8. Documentacin del diseo

Se puede utilizar un esquema de documento como el siguiente para la especificacin del diseo. Especificacin de diseo 1. Ambito 1.1 Objetivos del sistema 1.2 Hardware, software e interfaces humanas 1.3 Principales funciones del software 1.4 Base de datos definida externamente 1.5 Principales restricciones y limitaciones del diseo 2. Documentos de referencia 2.1 Documentacin del software existente 2.2 Documentacin del sistema 2.3 Documentos del vendedor (hardware o software) 2.4 Referencia tcnica 3. Descripcin del diseo 3.1 Descripcin de datos 3.1.1 Revisin del flujo de datos 3.1.2 Revisin de la estructura de datos 3.2 Estructura de programa derivada 3.3 Interfaces dentro de la estructura 4. Mdulos (Para cada mdulo) 4.1 Texto explicativo 4.2 Descripcin de la interfaz 4.3 Descripcin en lenguaje de diseo 4.4 Mdulos utilizados 4.5 Organizacin de los datos 4.6 Comentarios 5. Estructuras de archivos y datos globales 5.1 Estructura de archivos internos 5.1.1 Estructura lgica 5.1.2 Descripcin lgica de los registros 5.1.3 Mtodo de acceso 5.2 Datos globales 5.3 Referencias cruzadas entre archivos y datos (ver figura 14) 6. Referencias cruzadas para los requisitos 7. Provisiones de prueba 7.1 Directrices de prueba 7.2 Estrategia de integracin 7.3 Consideraciones especiales 8. Empaquetamiento 8.1 Provisiones especiales de solapamiento del programa 8.2 Consideraciones de transferencia 9. Notas especiales 10. Apndices

18

Fundamentos del diseo de software

Figura 14. Referencias cruzadas entre archivos y datos En la seccin 1 se describe el mbito global del trabajo de diseo. Gran parte de la informacin de esta seccin se deriva de la especificacin del sistema y de otros documentos obtenidos en la fase de definicin del software. La seccin 2 incluye las referencias especficas a la documentacin de soporte. En la seccin 3, que se desarrolla durante el diseo preliminar, se refinan y utilizan los DFD y otras representaciones de los datos, desarrollados durante el anlisis de requerimientos. Puesto que est definido el flujo de la informacin se pueden desarrollar las descripciones de la interfaz para los elementos del software. Las secciones 4 y 5 se realizan durante el paso del diseo preliminar al diseo detallado. Inicialmente se describen los mdulos mediante una descripcin procedimental del mdulo en lenguaje natural. Despus se utiliza una herramienta de diseo procedimental para traducir el texto explicativo a una descripcin estructurada. La seccin 5 contiene una descripcin de la organizacin de los datos, se asignan los datos globales y se establecen referencias cruzadas que conectan los mdulos individuales con los archivos o datos globales. La seccin 6 contiene las referencias cruzadas entre los requerimientos y los mdulos que los implementan y facilita la identificacin de los mdulos que se corresponden con requerimientos crticos. La seccin 7 contiene la primera etapa del desarrollo del procedimiento de prueba. Una vez que se han establecido la estructura y las interfaces del software podemos desarrollar directrices para la prueba de los mdulos individuales y de su integracin. La seccin 8 contiene las restricciones del diseo, tales como las limitaciones fsicas de memoria o la necesidad de un gran rendimiento del software, y tambin describe el mtodo que se usar para transferir el software al lugar del cliente. Las secciones 9 y 10 contienen datos complementarios como las descripciones de algoritmos o procedimientos alternativos y otro tipo de informacin relevante.

19