Professional Documents
Culture Documents
A continuacin, se genera el cdigo fuente y, para integrar y validar el software, se llevan a cabo las pruebas.
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.
Diseo de datos Diseo arquitectnico Punto de vista tcnico Diseo procedimental Diseo de la interfaz
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.
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.
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
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.
Para dos problemas p1 y p2, si se deduce que Adems, se cumple que y que
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.
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.
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
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.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.
10
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