IMPORTANCIA DEL DISEO

En el diseo se busca la eficiencia, no solo la eficacia, es decir, desarrollar software que funcionen bien y adems el diseo nos sirve para mantener la calidad. Aspectos funcionales: los aspectos funcionales se centran en la eficacia, que el cdigo funcione. Aspectos no funcionales: son aspectos de calidad, se centran en la eficiencia, preocupndose de que el software funcione bien. Dependiendo del contexto en el que estemos, habr que primar un aspecto u otro: Rendimiento: rapidez, eficiencia. Seguridad: que sea seguro, difcil de atacar/hackear. Disponibilidad: que no se bloquee al ser accedido por muchos usuarios. Mantenibilidad: que sea fcilmente ampliable. Las empresas estn cambiando continuamente sus procesos de negocio, por eso el software tiene que ser fcil de mantener Facilidad: que al usuario no le cueste mucho trabajo usarlo. Entre otros. La importancia de estos puntos depender del tipo de software a desarrollar, o de los requisitos del problema. Por ejemplo, si el software se aplicar en una central nuclear, es lgico que antepongan los puntos de seguridad y rendimiento al de Mantenibilidad. El diseo es la etapa en la que se tienen en cuenta esas necesidades del sistema que se est implementando y se van aadiendo una a una.

OBJETIVOS
El objetivo ms importante es: Entregar las funciones requeridas por el usuario (Satisfaga una especificacin funcional dada). Pero adems para lograr esto deben considerarse los aspectos de: Rendimiento: cun rpido permitir el diseo realizar el trabajo dado un recurso particular de hardware. Es decir que contemple las limitaciones del medio donde ser implementado el sistema, y alcance los requerimientos de performance y uso de recursos. Control: proteccin contra errores humanos, mquinas defectuosas, o daos intencionales. Cambiabilidad: facilidad con la cual el diseo permite modificar el sistema. Generalmente estos tres factores trabajan unos contra otros : un sistema con muchos controles tender a degradar su rendimiento, un sistema diseado para un alto rendimiento solo podr ser cambiado con dificultad, etc... Adems deber satisfacer criterios de diseo sobre la forma interna y externa del producto obtenido.

Satisfacer restricciones sobre el proceso de diseo en s mismo, tales como su tiempo o costo, o las herramientas disponibles para hacer el diseo.

MODELO O METODOS PARA LA ACTIVIDAD DE DISEO

En el modelo de diseo vamos a destacar 5 mapas o planos, que se suelen seguir por orden: Diseo de datos: Aqu se guardaan los datos de la aplicacin (P. ej.- informacin de clientes, pedidos, etc.) en clases, relaciones, atributos, etc. Respecto al modelo de anlisis podemos decir que en el diseo de datos hablamos de tipos de datos concretos, ficheros de configuracin, etc. La mayora de las veces esto se traduce como la base de datos a usar. Diseo de la arquitectura: se hace una pequea descomposicin del sistema, dividindolo en bloques y estableciendo sus relaciones. Diseo de interfaz: existen tres tipos de interfaces que se pueden disear: Interfaz de usuario Interfaz de conexin con sistemas externos Interfaz entre los bloques Diseo de la microarquitectura: consiste en coger un bloque y mirar por dentro, es decir, nos centramos en un subsistema y vemos cmo estn implementadas las clases, los atributos, etc. Diseo del despliegue: se refiere a la parte de la instalacin. Se ve sobre qu maquinas va a funcionar el sistema, se especifica sistema operativo necesario, servidor de aplicaciones, plataforma, etc. El diseo es un proceso interactivo, las fases del proceso de diseo se suelen ejecutar de forma lineal, pero cclicamente. Cuando se est en una fase, suelen aparecer nuevos problemas que nos hacen volver atrs en el modelo (P. ej.- nos damos cuenta en la fase de diseo de la microarquitectura que el mdulo en el que hemos dividido es muy grande, con lo que hay que volver a dividir y crear nuevas interfaces, etc.).

MODELO DE ANLISIS VS. MODELO DE DISEO

Aunque en ambos modelos se usan las mismas herramientas (UML), son dos cosas muy diferentes: en el modelo de anlisis las clases representan a los elementos de la realidad que forman parte del problema, mientras que en el modelo de diseo, ya se empieza a hablar de elementos software que no se identifican con la realidad, sino que son parte de la solucin al problema (P. ej.- el Sr. Empleado para anlisis y la clase empleado.java para diseo). ANALISIS VS. DISEO.jpg ANALISIS VS. DISEO

PRINCIPIOS DE DISEO
Los principios de diseo son aplicables a todos los niveles del diseo del software, desde la arquitectura a la microarquitectura, adems todos estos principios se relacionan entre s. Los principios de diseo son los siguientes: ABSTRACCIN Y REFINAMIENTO: se trata de ocultar los detalles, es decir no centrarse en detalles concretos del diseo, sino hacer un esquema visual a alto nivel. De esta manera tenemos una visin general de todo, tambin se utiliza en los microdiseos. La tctica del refinamiento es justamente lo contrario, es decir, centrarse en los detalles del modelo abstracto dado anteriormente. La tcnica de abstraccin y refinamiento se complementa con la de refinamiento, es decir, primero se hace una abstraccin del problema y una vez que tenemos un esquema abstracto usamos la tcnica del refinamiento para centrarnos en detalles concretos. MODULARIDAD: se basa en el principio de "Divide y Vencers", que consiste un dividir el problema en varios problemas ms pequeos para que el coste de resolverlos sea menor. Consiste en dividir un sistema en varios subsistemas, cada uno de estos resuelve un problema pequeito y luego se vuelven a unir. Esta tcnica se puede aplicar a distintas escalas. Esto nos plantea una pregunta: Cmo lo divido? Pues no hay una forma exacta para hacer la divisin sino que depende de cada problema en particular. COSTE DE DISEO.jpg COSTE DE DISEO En la grfica podemos observar el coste de dividir en mdulos frente al coste de unir esos mdulos. Si dividimos en muchos mdulos el coste disminuye, pero aumenta la integracin de los mdulos. Hay que buscar la justa medida que est comprendida en la regin de costes mnimos. VARIACIONES PROTEGIDAS: hay que tener claros dos conceptos: punto de variacin y punto de evolucin. *Punto de variacin: es un requisito del sistema que tiene caractersticas variables y puede cambiar, por tanto tengo que soportarlo en mi aplicacin. *Punto de evolucin: es cuando nosotros prevemos que se puede convertir en un punto de variacin. En el desarrollo del software todo lo que sea cambios es un problema, hay que prestar atencin a estos puntos que cambian, la idea es proteger al sistema de los cambios en los puntos de variacin y en los puntos de evolucin.

Cuando detecte un punto de variacin y/o punto de evolucin tengo que disearlo de forma que los cambios que se produzcan en el sistema afectan a lo mnimo posible. David Parnas (1972) dijo: "...proponemos en lugar de eso (dividir en mdulos) que uno comience con una lista de decisiones de diseo difciles o con altas probabilidades de cambio. Cada mdulo se disea entonces para ocultar dichas decisiones a otros (mdulos)..." Para hacer estos se puede usar alguno de los siguientes mtodos: -Encapsulacin: por ejemplo lo que hacen las clases en Java, ocultan los atributos y solo muestran los mtodos. -Interfaces: por ejemplo lo que es una interfaz en Java, una misma interfaz puede tener distintas implementaciones. -Datos externos: tener datos de configuracin fuera de el sistema (ficheros de configuracin...). -Ocultacin de la estructura: un sistema no tiene necesidad de conocer los otros subsistemas, para ello estn los interfaces internas. CUIDADO! El coste de disear la proteccin de un punto de variacin o de evolucin es superior que resolver un diseo simple. No hay que usar la sobre ingeniera. ACOPLAMIENTO: medida cualitativa del grado en el que un mdulo est conectado a otros y el mundo exterior. El acoplamiento hay que mantenerlos bajo para que cada mdulo sea lo ms independiente posible. De esta forma si un mdulo cambia, su cambio afecta lo menos posible al resto de sistema. Nunca se puede dar el acoplamiento. El acoplamiento es un principio evolutivo, tenemos que ir controlndolo a medida que se disea hay que estar evaluando el grado de acoplamiento para conseguir que sea lo ms bajo posible Hay que ser cautelar, es decir, no hay que intentar disminuir el acoplamiento a toda costa, sino que hay que evaluar cmo hacerlo. COHESIN: es la medida cualitativa del grado en el que un mdulo se enfoca a una sola cosa. Un mdulo hace cosas muy parecidas, la cohesin debe ser alta en cada mdulo, se trata de conseguir mdulos muy cohesivos y que estn poco acoplados. Para mejorar la cohesin lo mejor es dividir en subsistemas. Las clases con muchos mtodos son poco cohesivas y habr que dividir. La cohesin al igual que el acoplamiento es evolutiva, hay que ir evaluando a la vez que se disea para aumentar la cohesin. "Un elemento es altamente cohesivo si todos sus elementos trabajar juntos para proporcionar algn comportamiento bien determinado" A la cohesin y al acoplamiento se les denomina el Ying y el Yang del diseo software.

REFACTORIZACIN: segn Martin Fowler (1999) "Es el proceso de cambiar un sistema de software de tal forma que no se altere el comportamiento externo de su cdigo (diseo) y an as se mejora su estructura interna". La funcionalidad sigue siendo la misma pero mejora la estructura interna del cdigo, es decir, mejorando la cohesin y disminuyendo el acoplamiento, pero siempre hay que tener en cuenta que la funcionalidad no puede cambiar. En lugar de aplicar la evaluacin de la cohesin y el acoplamiento al principio, lo hago cuando ya tengo un poco de cdigo hecho. Existen catlogos de refactorizacin que nos puede ayudar a llevar a cabo una refactorizacin. REUTILIZACIN: no hay que reinventar la rueda, consiste en utilizar cdigo que se sabe que funciona bien, en vez de hacerlo nosotros de nuevo. Buscar que hay que resuelva mi problema y adaptarlo a mi caso.

DISEO DE ATRIBUTOS DE CALIDAD

La Calidad del software, es el desarrollo de software basado en estndares con la funcionalidad y rendimiento total que satisfacen los requerimientos del cliente. El proceso de desarrollo, gestin de proyectos, anlisis y diseo, especificacin de requerimientos, arquitectura, son solo algunos de los componentes que se aglomeran para conformar la ingeniera de software (IS) como disciplina para la creacin y mantenimiento de software. Dentro de sta, existe un subconjunto de teoras, herramientas y mtodos orientados a lo que se denomina la calidad del software. Para resumir de alguna manera la amplitud de este concepto, se puede decir que la calidad de software ha sido usada desde un simple argumento de venta, hasta verdaderos estudios formales y usos de mtricas para el desarrollo de software. Extraamente dentro de la IS, la calidad del software es muy complicada de definir y de enmarcar en un simple concepto terico, por lo que en esta nota, me concentrar solo en las diversas caractersticas que permiten describirla y en los elementos que importan especficamente al diseador de software. Una idea general sobre un software de calidad es aquel que debiera cumplir con los requerimientos funcionales y de performance adems de ser mantenible, confiable y aceptable. Dentro de sus principales caractersticas tenemos: FUNCIONABILIDAD: es la capacidad que tendr el producto de satisfacer los requisitos funcionales prescriptos y las necesidades implcitas de los usuarios. CONFIABILIDAD: El grado que se puede esperar de una aplicacin lleve a cabo las operaciones especificadas y con la precisin requerida incluye varias caractersticas como la seguridad, control de fallos, etc USABILIDAD: Capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones especficas de uso.

EFICIENCIA: cuyo Conjunto de caractersticas determinan la relacin entre el nivel de rendimiento del software y el nmero de recursos usados, bajo ciertas condiciones dadas. Se divide en las subcaracterticas: Comportamiento temporal: que indica las caractersticas del software que influyen en el tiempo de respuesta y procesado y productividad cuando se ejecuta su funcin. Utilizacin de recursos: que indica las caractersticas del software que influyen en el nmero de recursos usados, y la duracin de su uso, cuando se lleva a cabo su funcin. MATENIBILIDAD:Esfuerzo requerido para implementar cambios. Se divide en: Capacidad de ser analizado:que indica la cantidad de esfuerzo requerido para diagnosticar la causa de un fallo. Cambiabilidad: que indica la cantidad de esfuerzo requerido para una modificacin o borrado de un defecto Estabilidad: que indica volumen de riesgos de efectos inesperados tras una modificacin. Facilidad de prueba: que indica la capacidad del software para permitir que sea validado tras ser modificado. TRANSPORTABILIDAD:El esfuerzo requerido para transferir la aplicacin a otro hardware o sistema operativo. *COMPONENTES, SERVICIOS Y BIBLIOTECAS: tienen una funcionalidad empaquetada y diseada para ser reutilizada, el manejo de perifricos, grficos, gestin de documentos XML tienen funcionalidad lista para ser utilizada a travs de una interfaz bien definida. Tienes una interfaz bajo/local en el diseo de la aplicacin cliente. Una cuestin clave en el diseo de estos elementos reside en conseguir facilidad de uso para el mximo nmero de escenas sin complicar la interfaz ni reducir el rendimiento.

FRAMEWORKS: conjunto de clases parcialmente funcional (no es una aplicacin) para un dominio de aplicacin, es algo cuya funcionalidad no est definida, un Frameworks no tiene un ejecutable, le falta algo de la aplicacin, por ejemplo. Junit es un frameworks. Los frameworks tienen una gran influencia en el diseo de la aplicacin del cliente. Est basado en el principio de Hollywood "Don't call us, we'll call you!" que significa "No nos llames, nosotros te llamaremos".

-Ventajas del framework: reutilizacin de diseo y cdigo, hay que tener en cuenta la experiencia del diseador del framework, se reducen los costes de produccin porque ya est hecho.-Inconvenientes: encontrar el frameworks apropiado para nuestro caso, usar ms de un frameworks al mismo tiempo (temas de incompatibilidad entre los frameworks usados), son difciles de construir y de aprender a usar.

*IDIOMAS: una forma de utilizar un Lenguaje de Programacin, patrn de bajo nivel, es especifico de un Lenguaje de Programacin. Describen soluciones a problemas de implementacin de un determinado Lenguaje de Programacin por ejemplo la gestin de memorias en C++. *ANTIPATRONES: se aprende de los errores ms que de los aciertos, nos dan recetas de cosas que no hay que hacer. *PATRONES DE DISEO: "Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno. Tambin describe el ncleo de la solucin al problema, de forma que puede utilizar un milln de veces sin hacer dos veces lo mismo". *PATRONES ARQUITECTNICOS: definen la estructura general del software, indican las relaciones entre los subsistemas y los componentes del software y definen las reglas para especificar las relaciones entre los elementos de la arquitectura.

ESTRATEGIAS DE DISEO:
Con los modelos que se disponen de las tareas y de la arquitectura del sistema, deberemos guiar el diseo para obtener una implementacin correcta. Este proceso en algunos casos puede ser automtico, pero en la mayora de los casos, requerir de un profundo reconocimiento de los aspectos ms delicados del proceso de diseo y que est directamente relacionado con el dilogo con la mquina y la presentacin de la informacin. Nos centraremos en los mecanismos bsicos de interaccin y el dilogo con la aplicacin y la capa de presentacin. DISEO ORIENTADO A OBJETOS Los interfaces de usuario son muy adecuados para un desarrollo basado en el paradigma de objetos [COX93], ya que el sistema est formado por componentes de naturaleza manipuladora (interactiva) con representacin grfica y en la que existe una gran vinculacin (mediante herencia) de unos componentes con otros. Una estructura tpica del modelo conceptual es un conjunto de objetos capaces de realizar una serie de acciones (modelo objetoaccin). Objetos: Un objeto es un elemento de informacin sobre el que el usuario tiene algn control. El conjunto de objetos posee usualmente alguna estructura. Dicho conjunto es una visin abstracta de la informacin gestionada por el sistema (modelo). Acciones: Una accin es una operacin que el usuario puede realizar con un objeto. El conjunto de acciones define la capacidad funcional del sistema. El conjunto de acciones no tiene que ser necesariamente ortogonal al de los objetos. Estas acciones sern las tareas que debe realizar el usuario para manipular los objetos del dominio de la aplicacin.

Ejemplo: Flexo. Un flexo dispone de una bombilla, un interruptor y una clavija de enchufe. El interruptor puede estar en una de dos posiciones (encendido o apagado), la clavija se puede conectar y desconectar a una base de enchufe. Cuando la clavija est conectada a una base en buen estado y el interruptor esta en la posicin de encendido, la bombilla se ilumina. Podemos identificar dos tipos de objetos: a) aquellos que aparecen en la comunicacin entre el usuario y el sistema y que tpicamente pertenecen a la interfaz (objetos de control), y b) los que son propios de la aplicacin (objetos intrnsecos). Por ejemplo, una barra de iconos, una regla o una ventana son objetos intrnsecos con acciones propias (mover, ocultar, redimensionar, etc.) mientras que el registro de una persona es un objeto de control susceptible de aplicarle acciones del dominio de la aplicacin (insertar, modificar, ver DNI, etc.). Para la descripcin de los objetos y de las acciones podemos usar metforas que ayuden a comprender su significado y utilizacin (ver captulo Metforas, estilos y paradigmas). Para la especificacin del sistema deberemos identificar tanto a los objetos como a sus acciones asociadas. Los objetos se describen identificando sus atributos ms relevantes. Uno de los ms importantes es su representacin grfica. Para describir las acciones se puede utilizar una notacin de dilogo basada en diagramas de estado y lenguaje de rdenes (secuencia). El lenguaje de rdenes nos dara informacin necesaria acerca del protocolo (qu accin se realiza), mientras que el diagrama de estado indicara cmo cambia el estado de los objetos con las modificaciones (cmo implementarlo). ESTRATEGIAS DE DISEO ORIENTADO A ESTRUCTURA DE DATOS El dominio de la informacin para un problema de software comprende el flujo de datos, el contenido de datos y la estructura de datos. Los mtodos de anlisis orientados a la estructura de datos representan los requerimientos del software enfocndose hacia la estructura de datos en vez de al flujo de datos. Aunque cada mtodo orientado a la estructura de datos tiene un enfoque y notacin distinta, todos tienen algunas caractersticas en comn: 1) todos asisten al analista en la identificacin de los objetos de informacin clave (tambin llamados entidades o tems) y operaciones (tambin llamadas acciones o procesos). 2) todos suponen que la estructura de la informacin es jerrquica. 3) todos requiere que la estructura de datos se represente usando la secuencia, seleccin y repeticin. 4) todos dan un conjunto de pasos para transformar una estructura de datos jerrquica en una estructura de programa. Como los mtodos orientados al flujo de datos, los mtodos de anlisis orientados a la estructura de datos proporcionan la base para el diseo de software. Siempre puede

extenderse un mtodo de anlisis para que abarque el diseo arquitectural y procedimental del software.

Patrn de Diseo
Un patrn de diseo provee un esquema para refinar los subsistemas o componentes de un sistema de software, o las relaciones entre ellos. Describe la estructura comnmente recurrente de los componentes en comunicacin, que resuelve un problema general de diseo en un contexto particular (Buschman et al., 1996). Son menores en escala que los patrones arquitectnicos, y tienden a ser independientes de los lenguajes y paradigmas de programacin. Su aplicacin no tiene efectos en la estructura fundamental del sistema, pero s sobre la de un subsistema (Buschman et al., 1996), debido a que especifica a un mayor nivel de detalle, sin llegar a la implementacin, el comportamiento de los componentes del subsistema.