Centro Universitario UAEM Atlacomulco Evelin Carbajal Garca Ico9 CONCEPTOS Y PRINCIPIOS DE DISEO El diseo del software, al igual

que los enfoques de diseo de ingeniera en otras disciplinas, va cambiando continuamente a medida que se desarrollan mtodos nuevos, anlisis mejores y se amplia el conocimiento. Las metodologas de diseo del software carecen de la profundidad, flexibilidad y naturaleza cuantitativa que se asocian normalmente a las disciplinas de diseo de ingeniera ms clsicas. Sin embargo, s existen mtodos para el diseo del software; tambin se dispone de calidad de diseo y se pueden aplicar notaciones de diseo. EL DISEO DEL SOFTWARE E INGENIERIA DEL SOFTWARE Una vez que se analizan y especifican los requisitos del software, el diseo del software es la primera de las tres actividades tcnicas -diseo, generacin de cdigo y pruebas- que se requieren para construir y verificar el software. Cada actividad transforma la informacin de manera que d lugar por ltimo a un software de computadora validado. Cada uno de los elementos del modelo de anlisis proporciona la informacin necesaria para crear los cuatro modelos de diseo que se requieren para una especificacin completa de diseo. El diseo de datos transforma el modelo del dominio de informacin que se crea durante el anlisis en las estructuras de datos que se necesitarn para implementar el software. El diseo arquitectnico define la relacin entre los elementos estructurales principales del software, los patrones de diseo que se pueden utilizar para lograr los requisitos que se han definido para el sistema, y las restricciones que afectan a la manera en que se pueden aplicar los patrones de diseo arquitectnicos El diseo de la interfaz describe la manera de comunicarse el software dentro de s mismo, con sistemas que interoperan dentro de l y con las personas que lo utilizan. El diseo a nivel de componentes transforma los elementos estructurales de la arquitectura del software en una descripcin procedimental de los componentes del software. El diseo proporciona las representaciones del software que se pueden evaluar en cuanto a calidad, es la nica forma de convertir exactamente los requisitos de un cliente en un producto o sistema de software finalizado. EL PROCESO DE DISEO El diseo del software es un proceso iterativo mediante el cual los requisitos se traducen en un plano para construir el software. Diseo y calidad del software. Para la evaluacin de un buen diseo:

Centro Universitario UAEM Atlacomulco Evelin Carbajal Garca Ico9 El diseo deber implementar todos los requisitos explcitos del modelo de anlisis, y debern ajustarse a todos los requisitos implcitos que desea el cliente; El diseo deber ser una gua legible y comprensible para aquellos que generan cdigo y para aquellos que comprueban y consecuentemente, dan soporte al software; El diseo deber proporcionar una imagen completa del software, enfrentndose a los dominios de comportamiento, funcionales y de datos desde una perspectiva de implementacin.

Con el fin de evaluar la calidad de una representacin de diseo, debern establecerse los criterios tcnicos para un buen diseo. 1. Un diseo deber presentar una estructura arquitectnica que (1) se haya creado mediante patrones de diseo reconocibles, (2) que est formada por componentes que exhiban caractersticas de buen diseo), y (3) que se puedan implementar de manera evolutiva, facilitando as la implementacin y la comprobacin. 2. Un diseo deber ser modular; esto es, el software deber dividirse lgicamente en elementos que realicen funciones y subfunciones especficas. 3. Un diseo deber contener distintas representaciones de datos, arquitectura, interfaces y componentes (mdulos). 4. Un diseo deber conducir a estructuras de datos adecuadas para los objetos que se van a implementar y que procedan de patrones de datos reconocibles. 5. Un diseo deber conducir a componentes que presenten caractersticas funcionales independientes. 6. Un diseo deber conducir a interfaces que reduzcan la complejidad de las conexiones entre los mdulos y con el entorno externo. 7. Un diseo deber derivarse mediante un mtodo repetitivo y controlado por la informacin obtenida durante el anlisis de los requisitos del software. La evolucin del diseo de software. Independientemente del modelo de diseo que se utilice, un ingeniero del software deber aplicar un conjunto de principios fundamentales y conceptos bsicos para el diseo a nivel de componentes, de interfaz, arquitectnico y de datos. PRINCIPIOS DEL DISEO El diseo de software es tanto un proceso como un modelo. El proceso de diseo es una secuencia de pasos que hacen posible que el diseador describa todos los aspectos del software que se va construir. El modelo de diseo es el equivalente a los planes de un arquitecto para una casa. Comienza representando la totalidad de todo lo que se va a construir (por ejemplo, una representacin en tres dimensiones de la casa) y refina lentamente lo que va a proporcionar la gua para construir cada detalle (por ejemplo, el diseo de fontanera).

Centro Universitario UAEM Atlacomulco Evelin Carbajal Garca Ico9 Los principios bsicos de diseo hacen posible que el ingeniero del software navegue por el proceso de diseo. En el proceso de diseo no deber utilizarse orejeras . Un buen diseador deber tener en cuenta enfoques alternativos, juzgando todos los que se basan en los requisitos del problema, los recursos disponibles para realizar el trabajo y los conceptos de diseo. El diseo deber poderse rastrear hasta el modelo de anlisis. Dado que un solo elemento del modelo de diseo suele hacer un seguimiento de los mltiples requisitos, es necesario tener un medio de rastrear cmo se han satisfecho los requisitos por el modelo de diseo. El diseo no deber inventar nada que ya est inventado. Los sistemas se construyen utilizando un conjunto de patrones de diseo, muchos de los cuales probablemente ya se han encontrado antes. Estos patrones debern elegirse siempre como una alternativa para reinventar. El diseo deber minimizar la distancia intelectual entre el software y el problema como si de la misma vida real se tratara. Es decir, la estructura del diseo del software (siempre que sea posible) imita la estructura del dominio del problema. El diseo deber presentar uniformidad e integracin. Un diseo es uniforme si parece que fue una persona la que lo desarroll por completo. Las reglas de estilo y de formato debern definirse para un equipo de diseo antes de comenzar el trabajo sobre el diseo. El diseo deber estructurarse para admitir cambios. El diseo deber estructurarse para degradarse poco a poco, incluso cuando se enfrenta con datos, sucesos o condiciones de operacin aberrantes. Un software bien diseado no deber nunca explotar como una <<bomba. Deber disearse para adaptarse a circunstancias inusuales, y si debe terminar de funcionar, que lo haga de forma suave. El diseo no es escribir cdigo y escribir cdigo no es disear. Incluso cuando se crean diseos procedimentales para componentes de programas, el nivel de abstraccin del modelo de diseo es mayor que el cdigo fuente. Las nicas decisiones de diseo realizadas a nivel de codificacin se enfrentan con pequeos datos de implementacin que posibilitan codificar el diseo procedimental. El diseo deber evaluarse en funcin de la calidad mientras se va creando, no despus de terminarlo. El diseo deber revisarse para minimizar los errores conceptuales (semnticos).. Un equipo de diseadores deber asegurarse de haber afrontado los elementos conceptuales principales antes de preocuparse por la sintaxis del modelo del diseo.

CONCEPTOS DEL DISEO El comienzo de la sabidura para un ingeniero del software es reconocer la diferencia entre hacer que un programa funcione y conseguir que lo haga correctamente. Los conceptos de diseo de software fundamentales

Centro Universitario UAEM Atlacomulco Evelin Carbajal Garca Ico9 proporcionan el marco de trabajo necesario para conseguir que lo haga correctamente. Abstraccin. La nocin psicolgica de abstraccin permite concentrarse en un problema a algn nivel de generalizacin sin tener en consideracin los datos irrelevantes de bajo nivel; la utilizacin de la abstraccin tambin permite trabajar con conceptos y trminos que son familiares en el entorno del problema sin tener que transformarlos en una estructura no familiar. Una abstraccin procedimental es una secuencia nombrada de instrucciones que tiene una funcin especfica y limitada. Una abstraccin de datos es una coleccin nombrada de datos que describe un objeto de datos La abstraccin de control es la tercera forma de abstraccin que se utiliza en el diseo del software. Al igual que las abstracciones procedimentales y de datos, este tipo de abstraccin implica un mecanismo de control de programa sin especificar los datos internos. Refinamiento. El desarrollo de un programa se realiza refinando sucesivamente los niveles de detalle procedimentales. Una jerarqua se desarrolla descomponiendo una sentencia macroscpica de funcin (una abstraccin procedimental) paso a paso hasta alcanzar las sentencias del lenguaje de programacin. El refinamiento verdaderamente es un proceso de elaboracin. Se comienza con una sentencia de funcin (o descripcin de informacin) que se define a un nivel alto de abstraccin. Esto es, la sentencia describe la funcin o informacin conceptualmente, pero no proporciona informacin sobre el funcionamiento interno de la informacin. Modularidad. La modularidad es el nico atributo del software que permite gestionar un programa intelectualmente. El software monoltico (es decir, un programa grande formado por un nico mdulo) no puede ser entendido fcilmente por el lector. Se definen cinco criterios que nos permitirn evaluar un mtodo de diseo en relacin con la habilidad de definir un sistema modular efectivo: Capacidad de descomposicin modular. Si un mtodo de diseo proporciona un mecanismo sistemtico para descomponer el problema en subproblemas, reducir la complejidad de todo el problema, consiguiendo de esta manera una solucin modular efectiva. Capacidad de empleo de componentes modulares. Si un mtodo de diseo permite ensamblar los componentes de diseo (reusables) existentes en un sistema nuevo, producir una solucin modular que no inventa nada ya inventado. Capacidad de comprensin modular. Si un mdulo se puede comprender como una unidad autnoma (sin referencias a otros mdulos) ser ms fcil de construir y de cambiar.

Centro Universitario UAEM Atlacomulco Evelin Carbajal Garca Ico9 Continuidad modular. Si pequeos cambios en los requisitos del sistema provocan cambios en los mdulos individuales, en vez de cambios generalizados en el sistema, se minimizar el impacto de los efectos secundarios de los cambios. Proteccin modular. Si dentro de un mdulo se produce una condicin aberrante y sus efectos se limitan a ese mdulo, se minimizar el impacto de los efectos secundarios inducidos por los errores.

Arquitectura del software. La arquitectura es la estructura jerrquica de los componentes del programa (mdulos), la manera en que los componentes interactan y la estructura de datos que van a utilizar los componentes. Dada la especificacin de estas propiedades, el diseo arquitectnico se puede representar mediante uno o ms modelos diferentes. Los modelos estructurales representan la arquitectura como una coleccin organizada de componentes de programa. Los modelos del marco de trabajo aumentan l nivel de abstraccin del diseo en un intento e identificar los marcos de trabajo (patrones) repetibles el diseo arquitectnico que se encuentran en tipos similares de aplicaciones. Los modelos dinmicos tratan los aspectos de comportamiento de la arquitectura del programa, indicando cmo puede cambiar la estructura o la configuracin del sistema en funcin de los acontecimientos externos. Los modelos de proceso se centran en el diseo del proceso tcnico de negocios que tiene que adaptar el sistema. Finalmente los modelos funcionales se pueden utilizar para representar la jerarqua funcional de un sistema.

Jerarqua de control. La jerarqua de control, denominada tambin estructura de programa, representa la organizacin de los componentes de programa (mdulos) e implica una jerarqua de control. La relacin de control entre los mdulos se expresa de la manera siguiente: se dice que un mdulo que controla otro mdulo es superior a l, e inversamente, se dice que un mdulo controlado por otro mdulo es subordinado del controlador. La jerarqua de control tambin representa dos caractersticas sutiles diferentes de la arquitectura del software: visibilidad y conectividad. La visibilidad indica el conjunto de componentes de programa que un componente dado puede invocar o utilizar como datos, incluso cuando se lleva a cabo indirectamente. La conectividad indica el conjunto de componentes que un componente dado invoca o utiliza directamente como datos. Divisin estructural. La estructura del programa se puede dividir tanto horizontal como verticalmente. La divisin horizontal de la arquitectura proporciona diferentes ventajas:

Centro Universitario UAEM Atlacomulco Evelin Carbajal Garca Ico9

proporciona software ms fcil de probar conduce a un software ms fcil de mantener propaga menos efectos secundarios proporciona software ms fcil de ampliar

La divisin vertical, frecuentemente llamada factorizacin (factoring) sugiere que dentro de la estructura de programa el control (toma de decisiones) y el trabajo se distribuyan de manera descendente. Los mdulos del nivel superior debern llevar a cabo funciones de control y no realizarn mucho trabajo de procesamiento. Los mdulos que residen en la parte inferior de la estructura debern ser los trabajadores, aquellos que realizan todas las tareas de entrada, proceso y salida. Estructura de datos. La estructura de datos es una representacin de la relacin lgica entre elementos individuales de datos. La estructura dicta las alternativas de organizacin, mtodos de acceso, grado de capacidad de asociacin y procesamiento de la informacin. La organizacin y complejidad de una estructura de datos estn limitadas nicamente por la ingenuidad del diseador. Sin embargo, existe un nmero limitado de estructuras de datos clsicas que componen los bloques de construccin para estructuras ms sofisticadas. Un elemento escalar es la estructura de datos ms simple. Como su nombre indica, un elemento escalar representa un solo elemento de informacin que puede ser tratado por un identificador Cuando los elementos escalares se organizan como una lista o grupo contiguo, se forma un vector secuencial. Los vectores son las estructuras de datos ms comunes y abren la puerta a la indexacin variable de la informacin. Cuando el vector secuencia1 se ampla a dos, tres y por ltimo a un nmero arbitrario de dimensiones, se crea un espacio n-dimensional. El espacio ndimensional ms comn es la matriz bidimensional. En muchos lenguajes de programacin, un espacio n-dimensional se llama array. Procedimiento de software. El procedimiento de software se centra en el procesamiento de cada mdulo individualmente. El procedimiento debe proporcionar una especificacin precisa de procesamiento, incluyendo la secuencia de sucesos, los puntos de decisin exactos, las operaciones repetitivas e incluso la estructura/organizacin de datos. Ocultacin de informacin. El procedimiento de software se centra en el procesamiento de cada mdulo individualmente. El procedimiento debe proporcionar una especificacin precisa de procesamiento, incluyendo la secuencia de sucesos, los puntos de decisin exactos, las operaciones repetitivas e incluso la estructura/organizacin de datos. DISEO MODULAR EFECTIVO

Centro Universitario UAEM Atlacomulco Evelin Carbajal Garca Ico9

Independencia funcional. La independencia funcional se consigue desarrollando mdulos con una funcin determinante y una aversin a una interaccin excesiva con otros mdulos. Dicho de otra manera, queremos disear el software de manera que cada mdulo trate una subfuncin de requisitos y tenga una interfaz sencilla cuando se observa desde otras partes de la estructura del programa. Cohesin. Un mdulo cohesivo lleva a cabo una sola tarea dentro de un procedimiento de software, lo cual requiere poca interaccin con los procedimientos que se llevan a cabo en otras partes de un programa. Dicho de manera sencilla, un mdulo cohesivo deber (idealmente) hacer una sola cosa. Acoplamiento. El acoplamiento mdulos dentro de una estructura la complejidad de interconexin realiza una entrada o referencia travs de la interfaz. es una medida de interconexin entre de software. El acoplamiento depende de entre los mdulos, el punto donde se a un mdulo, y los datos que pasan a

El grado ms alto de acoplamiento, acoplamiento de contenido, se da cuando un mdulo hace uso de datos o de informacin de control mantenidos dentro de los lmites de otro mdulo. En segundo lugar, el acoplamiento de contenido ocurre cuando se realizan bifurcaciones a mitad de mdulo. Este modo de acoplamiento puede y deber evitarse. HEURISTICA DE DISEO PARA UNA MODULARIDAD EFECTIVA La estructura de programa se puede manipular de acuerdo con el siguiente conjunto de heursticas:
1. Evaluar la primera iteracin de la estructura de programa para 2. 3. 4. 5. 6.

reducir al acoplamiento y mejorar la cohesin. Intentar minimizar las estructuras con un alto grado de salida; esforzarse por la entrada a medida que aumenta la profundidad. Mantener el mbito del efecto de un mdulo dentro del mbito de control de ese mdulo. Evaluar las interfaces de los mdulos para reducir la complejidad y la redundancia, y mejorar la consistencia. Definir mdulos cuya funcin se pueda predecir, pero evitar mdulos que sean demasiado restrictivos. Intentar conseguir mdulos de entrada controlada, evitando conexiones patolgicas.

DOCUMENTACION DEL DISEO La Especificacin del diseo aborda diferentes aspectos del modelo de diseo y se completa a medida que el diseador refina su propia representacin del software. En primer lugar, se describe el mbito global del esfuerzo realizado en el diseo. La mayor parte de la informacin que se presenta aqu se deriva de la Especificacin del sistema y del modelo de anlisis (Especificacin de los requisitos del software).

Centro Universitario UAEM Atlacomulco Evelin Carbajal Garca Ico9

Contiene una referencia cruzada de requisitos. El propsito de esta referencia cruzada (normalmente representada como una matriz simple) es: (1) establecer que todos los requisitos se satisfagan mediante el diseo del software, y (2) indicar cuales son los componentes crticos para la implementacin de requisitos especficos. Las restricciones de diseo, tales como limitaciones fsicas de memoria o la necesidad de una interfaz externa especializada, podrn dictar requisitos especiales para ensamblar o empaquetar el software. Consideraciones especiales originadas por la necesidad de superposicin de programas, gestin de memoria virtual, procesamiento de alta velocidad u otros factores podrn originar modificaciones en diseo derivadas del flujo o estructura de la informacin. Adems, esta seccin describe el enfoque que se utilizar para transferir software al cliente. La ltima seccin de la Especificacin del diseo contiene datos complementarios, ser aconsejable desarrollar un Manual preliminar de Operaciones de instalacin e incluirlo como apndice para la documentacin del diseo. CONCLUSIONES Una vez que se analizan y especifican los requisitos del software que se va a contruir, se deben contemplar tres tcnicas: el diseo, la generacin de codigo y las pruebas que se requieran para construir y verificar el software,estas actividades transforman la informacin de tal forma que el resultado sea un software por computadora validado. El proceso de diseo es una secuencia de pasos que hacen posible que el diseador describa todos los aspectos del software que se va construir. La utilizacin de mdulos es la manera en que los componentes interactan y definen la estructura de datos que van a utilizar los componentes del sistema que se desea disear. El obejtivo es disear el software de manera que cada mdulo trate una subfuncin de requisitos y que tenga una interfaz sencilla cuando se observa desde otras partes de la estructura del programa. Adems de proporcionar software mas fcil de probar, mantener y ampliar, que tenga menos efectos secundarios (inconsistencias y/o errores),un software de calidad.