FUNDAMENTOS DE DESARROLLO DE SOFTWARE (UNIDAD I - EL DISEO)

FUNDAMENTO DE DISEO DE SOFTWARE: UNIDAD I: EL DISEO UNIDAD II: ARQUITECTURA DEL DISEO UNIDAD III: INTERFAZ DE USUARIO UNIDAD IV: DISEO ORIENTADO A OBJETOS

EL DISEO DE UN SOFTWARE
"Es el lugar en donde una persona se puede parar con un pie en dos mundos (el de la tecnologa y el de la gente y los propsitos humanos) e intenta unirlos". El diseo pone un pie en el problema y otro en la solucin, e intenta hacer casar un problema con otro y el resultado de esa actividad es el modelo de diseo, en cuyo 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. En otras definiciones el diseo es citados por otros autores como: Proceso iterativo de tomar un modelo lgico de un sistema junto con un conjunto de objetivos fuertemente establecidos para este sistema y producir las especificaciones de un sistema fsico que satisfaga estos objetivos. (Gane - Sarson). Actividad por la cual un relevamiento de datos y funciones de un sistema (modelo esencial) se traduce en un plan de implementacin. El modelo es volcado en una tecnologa determinada. ...el 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. (E. Taylor)

HITORIA DEL DISEO DE SOFWARE.

A partir de los aos 50 se empez a ver la efectividad de las mquinas para resolver los problemas diarios, Se empez a informatizar los procesos que antes se hacan a mano. Hoy en da el software sirve para ese fin: resolver un problema automatizndolo. La evolucin del diseo de software, como parte del proceso de desarrollo de software, es un proceso continuo que se ha ido produciendo durante dcadas pasadas. Los primeros trabajos sobre diseo se centraron sobre los criterios para el desarrollo de programas modulares y los mtodos para mejorar la arquitectura del software de una manera descendente. Los aspectos procedimentales de la definicin del diseo evolucionaron hacia una filosofa denominada programacin estructurada. Posteriores trabajos propusieron mtodos para la traduccin del flujo de datos o de la estructura de los datos. La evolucin del diseo de software dentro del contexto de las reas de aplicacin de los sistemas basados en computadoras, puede verse el grafico siguiente: En los primeros aos de desarrollo de las computadoras, el hardware sufri continuos cambios, mientras que el software se contemplaba simplemente como un aadido. La programacin de computadoras era un arte para el cual existan pocos mtodos sistemticos. El desarrollo de software se realizaba virtualmente sin ninguna planificacin (hasta que los planes comenzaron a desfasarse y los costos a crecer). Durante este perodo se utilizaba en la mayora de los sistemas una orientacin por lotes.

Algunas excepciones fueron sistemas interactivos (Como es el caso de los sistemas de reservas de Amrica Airlines) y sistemas de tiempo real para la defensa (SAGE). No obstante esto, la mayor parte del hardware se dedicaba a la ejecucin de un nico programa que, a su vez, se dedicaba a una aplicacin especfica. Lo normal era que el hardware fuera de propsito general. Por otra parte, el software se diseaba a medida para cada aplicacin y tena una distribucin relativamente pequea. La mayora del software que se desarrollaba era utilizado por la misma persona u organizacin, es decir, La misma persona lo escriba, lo ejecutaba y si fallaba, lo depuraba. Debido a este entorno personalizado del software, el diseo era un proceso implcito, realizado en la mente de alguien, haciendo del diseo como tal una idea sin forma o sentido y la documentacin normalmente no exista. La segunda era, la evolucin de los sistemas de computadoras se extiende desde la mitad de la dcada de los 60 hasta finales de los setenta. La multiprogramacin y los sistemas multiusuarios introdujeron nuevos conceptos de interaccin hombre mquina. Las tcnicas interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de sofisticacin del hardware y del software. Los sistemas de tiempo real podan recoger, analizar y transformar datos de mltiples fuentes, controlando as los procesos y produciendo salidas en milisegundos en lugar de en minutos. Los avances en los dispositivos de almacenamiento en lnea condujeron a la primera generacin de sistemas de gestin de bases de datos. Ya en esta era se poda hacer referencia del software como producto y tambin de las llamadas casas de software. Conforme creca el nmero de sistemas, comenzaron a extenderse las bibliotecas de software de computadora. Se desarrollaban proyectos en los que se producan programas de decenas de miles de sentencias fuente. Todos esos programas (todas esas sentencias fuentes) tenan que ser corregidos cuando se detectaban fallos, modificados cuando cambiaban los requisitos de los usuarios o adaptados a nuevos dispositivos que se hubieran incorporado. Estas actividades se llamaron mantenimiento del software. El esfuerzo gastado en el mantenimiento comenz a absorber recursos en una medida alarmante. Haba comenzado una crisis del software. La tercera era en la evolucin de los sistemas de computadoras comenz a mediado de los setenta y llega hasta el momento actual. El procesamiento distribuido (mltiples computadoras, cada una ejecutando funciones concurrentemente y comunicndose con alguna otra) increment notablemente la complejidad de los sistemas informticos. Las redes de rea local y de rea global, las comunicaciones digitales de alto ancho de banda y la creciente demanda de acceso instantneo a los datos, pusieron una fuerte presin sobre los desarrolladores del software. En esta era se produce la llegada de los microprocesadores y las computadoras personales y con ella las ideas formales en el diseo de desarrollo de software. Las computadoras personales han sido el catalizador del gran crecimiento de muchas compaas de software. Estas compaas venden decenas y centenares de copias de sus productos de software. La cuarta era del software de computadora est comenzando ahora. Las tecnologas orientadas a objetos estn comenzando a ser utilizadas en muchas reas de aplicacin. Las tcnicas de cuarta generacin para el desarrollo de software ya estn cambiando la forma en que algunos segmentos de la comunidad informtica construyen los programas. Los sistemas expertos y el software de inteligencia artificial se han trasladado del laboratorio a las aplicaciones prcticas. El software de redes neuronales artificiales ha abierto excitantes posibilidades para el reconocimiento de formas y habilidades de procesamiento de informacin al estilo de como lo hacen los humanos.

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 guardarn 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).

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. 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 del 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 aun 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 est 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.

UNIDAD II: ARQUITECTURA DEL DISEO

ARQUITECTURA DEL DISEO
El diseo arquitectnico representa la estructura de los datos y los componentes del programa que se requieren para construir un sistema de computadora constituye el estilo arquitectnico que tendr el sistema, las estructuras de datos y las propiedades de los componentes y la interrelacin que tiene con otros componentes arquitectnicos del sistema

IMPORTANCIA DE LA ARQUITECTURA DE SOFTWARE

La necesidad del manejo de la arquitectura de un sistema de software nace con los sistemas de mediana o gran envergadura, que se proponen como solucin para un problema determinado. En la medida que los sistemas de software crecen en complejidad, bien sea por nmero de requerimientos o por el impacto de los mismos, se hace necesario establecer medios para el manejo de esta complejidad (Hofmeister et al., 1996). En general, la tcnica es descomponer el sistema en piezas que agrupan aspectos especficos del mismo, producto de un proceso de abstraccin (Bass et al., 1998) y que al organizarse de cierta manera constituyen la base de la solucin de un problema en particular.

Una arquitectura de software define la estructura del sistema. Esta estructura se constituye de componentes -mdulos o piezas de cdigo que nacen de la nocin de abstraccin, cumpliendo funciones especficas, e interactuando entre s con un comportamiento definido Los componentes se organizan de acuerdo a ciertos criterios, que representan decisiones de diseo. En este sentido, hay autores que plantean que la arquitectura de software incluye justificaciones referentes a la organizacin y el tipo de componentes, garantizando que la configuracin resultante satisface los requerimientos del sistema. De esta manera, la arquitectura de software puede ser vista como la estructura del sistema en funcin de la definicin de los componentes y sus interacciones. La prctica ha demostrado que resulta importante extender el concepto considerando los requerimientos y restricciones del sistema, junto a un argumento que justifique que la estructura definida satisface los requerimientos, dndole un sentido ms amplio a la definicin del trmino. La arquitectura de software puede considerarse entonces como el puente entre los requerimientos del sistema y la implementacin. Las actividades que culminan en la definicin de la arquitectura pueden ubicarse en las fases tempranas del ciclo de desarrollo del sistema: luego del anlisis de los requerimientos y el anlisis de riesgos, y justo antes del diseo detallado. Desde esta perspectiva, la arquitectura constituye un artefacto de la actividad de diseo, que servir de medio de comunicacin entre los miembros del equipo de desarrollo, los clientes y usuarios finales, dado que contempla los aspectos que interesan a cada uno. Adems, pasa a ser la base del diseo del sistema a desarrollar, razn por la cual en la literatura la arquitectura es considerada como plan de diseo del sistema, debido a que es usada como gua para el resto de las tareas del desarrollo. De igual manera, sern de particular importancia las propiedades no funcionales del sistema de software, pues influyen notoriamente en la calidad del mismo. Estas propiedades tienen un gran impacto en el desarrollo y mantenimiento del sistema, su operabilidad y el uso que ste haga de los recursos. Entre las propiedades no funcionales ms importantes se encuentran: modificabilidad, eficiencia, mantenibilidad, interoperabilidad, confiabilidad, reusabilidad y facilidad de ejecucin de prueba. Proponen que el trmino requerimiento no funcional es disfuncional, debido a que implica que tal requerimiento no existe, o que es una especie de requerimiento que puede ser especificado independientemente del comportamiento del sistema. Puede observarse que al hablar de arquitectura de software, se hace alusin a la especificacin de la estructura del sistema, entendida como la organizacin de componentes y relaciones entre ellos; los requerimientos que debe satisfacer el sistema y las restricciones a las que est sujeto, as como las propiedades no funcionales del sistema y su impacto sobre la calidad del mismo; las reglas y decisiones de diseo que gobiernan esta estructura y los argumentos que justifican las decisiones tomadas. Habiendo aclarado el alcance que puede tomar el trmino arquitectura de software, resulta de gran inters introducir formalmente otros trminos que resultan pilares fundamentales dentro del contexto de arquitectura, dado que en torno a ellos gira gran parte del estudio que hasta el momento se ha realizado sobre el tema. Tal es el caso de los componentes, los conectores y las relaciones.

COMPONENTES, CONECTORES Y RELACIONES Se entiende por componentes los bloques de construccin que conforman las partes de un sistema de software. A nivel de lenguajes de programacin, pueden ser representados como mdulos, clases, objetos o un conjunto de funciones relacionadas Se distinguen tres tipos de componentes, denominados tambin elementos, que son: 1. Elementos de Datos: contienen la informacin que ser transformada. 2. Elementos de Proceso: transforman los elementos de datos. 3. Elementos de Conexin: llamados tambin conectores, que bien pueden ser elementos de datos o de proceso, y mantienen unidas las diferentes piezas de la arquitectura. Una relacin es la conexin entre los componentes. Puede definirse tambin como una abstraccin de la forma en que los componentes interactan en el sistema a travs de los elementos de conexin. Es importante distinguir que una relacin se concreta mediante conectores. Algunos autores afirman que est conformado por componentes y relaciones entre ellos, todo sistema, por muy simple que sea, tiene asociada una arquitectura. Sin embargo, no es necesariamente cierto que esta arquitectura es conocida por todos los involucrados en el desarrollo del mismo. Esto hace evidente la diferencia entre la arquitectura del sistema y su descripcin. Esta particularidad propone la importancia de la representacin de una arquitectura. Adems de los componentes y conectores, contemplan las propiedades externamente visibles que comprenden los componentes del software, y las relaciones entre estos. En este sentido, las propiedades externamente visibles hacen referencia a servicios que los componentes proveen, caractersticas de desempeo, manejo de fallas, uso de recursos compartidos, etc. En relacin a los componentes definidos por la arquitectura de un sistema de software, se tiene la informacin referente a las interacciones, que son propias de la arquitectura, y que permiten, a nivel de diseo, tomar las decisiones necesarias durante la construccin de un sistema de software.

PATRN ARQUITECTNICO
El patrn arquitectnico es una regla que consta de tres partes, la cual expresa una relacin entre un contexto, un problema y una solucin. En lneas generales, un patrn sigue el siguiente esquema: 1. Contexto. Es una situacin de diseo en la que aparece un problema de diseo 2. Problema. Es un conjunto de fuerzas que aparecen repetidamente en el contexto 3. Solucin. Es una configuracin que equilibra estas fuerzas. sta ltima abarca:

Estructura con componentes y relaciones Comportamiento a tiempo de ejecucin: aspectos dinmicos de la solucin, como la colaboracin entre componentes, la comunicacin entre ellos, etc.

Partiendo de esta definicin, propone los patrones arquitectnicos como descripcin de un problema particular y recurrente de diseo, que aparece en contextos de diseo especfico, y presenta un esquema genrico demostrado con xito para su solucin. El esquema de solucin se especifica mediante la descripcin de los componentes que la constituyen, sus responsabilidades y desarrollos, as como tambin la forma como estos colaboran entre s.

Los patrones arquitectnicos expresan el esquema de organizacin estructural fundamental para sistemas de software. Provee un conjunto de subsistemas predefinidos, especifica sus responsabilidades e incluye reglas y pautas para la organizacin de las relaciones entre ellos. Propone que son plantillas para arquitecturas de software concretas, que especifican las propiedades estructurales de una aplicacin - con amplitud de todo el sistema - y tienen un impacto en la arquitectura de subsistemas. La seleccin de un patrn arquitectnico es, por lo tanto, una decisin fundamental de diseo en el desarrollo de un sistema de software. La coleccin de patrones arquitectnicos debe ser estudiada en trminos de factores de calidad e intereses, en anticipacin a su uso. Esto quiere decir que un patrn puede ser analizado previamente, con la intencin de seleccionar el que mejor se adapte a los requerimientos de calidad que debe cumplir el sistema. Debe estudiarse la composicin de los patrones, dado que sta puede dificultar aspectos como el anlisis, o poner en conflicto otros atributos de calidad. La tabla 10 presenta algunos patrones arquitectnicos, adems de los atributos que propician y los atributos en conflicto.

NOTACIONES DE LA ARQUITECTURA DE DISEO

Unified Modeling Language (UML) ha conseguido un rol importante en el proceso de desarrollo de software en la actualidad. La unificacin del mtodo de diseo y las notaciones, ha ampliado, entre otras cosas, el mercado de herramientas CASE que soportan el proceso de diseo de arquitecturas de software. UML ofrece soporte para clases, clases abstractas, relaciones, comportamiento por interaccin, empaquetamiento, entre otros. Estos elementos se pueden representar mediante nueve tipos de diagramas, que son: de clases, de objetos, de casos de uso, de secuencia, de colaboracin, de estados, de actividades, de componentes y de desarrollo. CARACTERSTICAS GENERALES DE UML E IMPORTANCIA DE SU APLICACIN. UML existe soporte para algunos de los conceptos asociados a las arquitecturas de software, como los componentes, los paquetes, las libreras y la colaboracin. UML permite la descripcin de componentes en la arquitectura de software en dos niveles; se puede especificar slo el nombre del componente o especificar las clases o interfaces que implementan estos. De igual forma, UML provee una notacin para la descripcin de la proyeccin de los componentes de software en el hardware. Esto corresponde a la vista fsica del modelo 4+1. La proyeccin de los componentes de software permite a los ingenieros de software hacer mejores estimaciones cuando se intenta medir la calidad del sistema implementado, lo cual contribuye a la bsqueda de la mejor solucin para un sistema especfico. Esta notacin puede ser extendida con mayor nivel de detalle y los componentes pueden ser conectados entre s con el uso de las bondades del lenguaje UML. La colaboracin entre componentes se puede representar mediante conjuntos de clases, interfaces y otros elementos que interactan entre s para proveer servicios que van ms all de la funcionalidad de cada uno de ellos por separado. La colaboracin posee un aspecto estructural, esto es, el diagrama de clases de los elementos involucrados en la interaccin y un diagrama de comportamiento. UML tambin permite que las colaboraciones posean relaciones entre s. Por ltimo, los patrones y frameworks estn tambin soportados por UML, mediante el uso combinado de paquetes, componentes y colaboraciones, entre otros. El modelo de Rausch (2001) plantea la inclusin de los componentes bsicos de una arquitectura: componentes, interfaces, conexiones, atributos, valores de los atributos y mensajes enviados a las interfaces. Todas las instancias nombradas representan las unidades operacionales de la arquitectura, y es necesario especificar su comportamiento.

En este sentido, se propone que deben considerarse tres categoras del comportamiento del sistema: comportamiento estructural, que captura los cambios del sistema, incluyendo la creacin y destruccin de instancias; evaluaciones de variables, que representan el espacio de variables globales y locales; y la comunicacin de los componentes, que describe la interaccin entre estos. Algunos autores proponen que es posible hacer la descripcin de los elementos bsicos de la arquitectura mediante el uso de UML, e indica que la especificacin de la estructura del sistema no es suficiente para obtener un modelo completo del mismo. Por esto, para la descripcin del comportamiento de los componentes de la arquitectura, propone el uso de OCL. Segn su estudio, este lenguaje ofrece facilidades que no provee UML, por lo que considera que el uso de ambos es una posible solucin para solventar los problemas de descripcin de las arquitecturas de software. En virtud de la importancia de la descripcin de la arquitectura de software, se plantea que los lenguajes de descripcin arquitectnica como elementos que, aunque presentan algunas desventajas, merecen atencin, puesto que pueden considerarse como una solucin alternativa al problema planteado.

EVALUACIN DE ARQUITECTURAS DE SOFTWARE

El primer paso para la evaluacin de una arquitectura es conocer qu es lo que se quiere evaluar. De esta forma, es posible establecer la base para la evaluacin, puesto que la intencin es saber qu se puede evaluar y qu no. Resulta interesante el estudio de la evaluacin de una arquitectura: si las decisiones que se toman sobre la misma determinan los atributos de calidad del sistema, es entonces posible evaluar las decisiones de tipo arquitectnico con respecto al impacto sobre estos atributos. La arquitectura de software posee un gran impacto sobre la calidad de un sistema, por lo que es muy importante estar en capacidad de tomar decisiones acertadas sobre ella, en diversos tipos de situaciones, entre las cuales destacan:

Comparacin de alternativas similares Comparacin de la arquitectura original y la modificada Comparacin de la arquitectura de software con respecto a los requerimientos del sistema Comparacin de una arquitectura de software con una propuesta terica Valoracin de una arquitectura en base a escalas especficas

Mediante la arquitectura de software, es posible tambin determinar la estructura del proyecto de desarrollo del sistema, sobre elementos como el control de configuracin, calendarios, control de recursos, metas de desempeo, estructura del equipo de desarrollo y otras actividades que se realizan con la arquitectura del sistema como apoyo principal. En este sentido, la garanta de una arquitectura correcta cumple un papel fundamental en el xito general del proceso de desarrollo, adems del cumplimiento de los atributos de calidad del sistema. De esta manera, el inters se centra en determinar el momento propicio para efectuar la evaluacin de una arquitectura. En este sentido, amplan el panorama clsico, indicando las ocasiones en que se hace posible hacer la evaluacin de una arquitectura. Su planteamiento establece que es posible realizarla en cualquier momento, pero propone dos variantes que agrupan dos etapas distintas: temprano y tarde. Para la primera variante, se establece que no es necesario que la arquitectura est completamente especificada para efectuar la evaluacin, y esto abarca desde las fases tempranas de diseo y a lo largo del desarrollo. En este punto, resulta interesante resaltar que es posible efectuar decisiones sobre la arquitectura a cualquier nivel, puesto que se pueden imponer distintos tipos de cambios arquitectnicos, producto de una evaluacin en funcin de los atributos de calidad esperados. Ahora bien, se establece que mientras mayor es el nivel de especificacin, mejores son los resultados que produce la evaluacin.

La segunda variante consiste en realizar la evaluacin de la arquitectura cuando sta se encuentra establecida y la implementacin se ha completado. Este es el caso general que se presenta al momento de la adquisicin de un sistema ya desarrollado. Los autores consideran muy til la evaluacin del sistema en este punto, puesto que puede observarse el cumplimiento de los atributos de calidad asociados al sistema, y cmo ser su comportamiento general. Tambin otros autores afirman que la evaluacin de una arquitectura de software es una tarea no trivial, puesto que se pretende medir propiedades del sistema en base a especificaciones abstractas, como por ejemplo los diseos arquitectnicos. Por ello, la intencin es ms bien la evaluacin del potencial de la arquitectura diseada para alcanzar los atributos de calidad requeridos. Las mediciones que se realizan sobre una arquitectura de software pueden tener distintos objetivos, dependiendo de la situacin en la que se encuentre el arquitecto y la aplicabilidad de las tcnicas que emplea. Los objetivos que menciona son tres: 1. cualitativos. 2. cuantitativos. 3. mximos y mnimos tericos. La medicin cualitativa se aplica para la comparacin entre arquitecturas candidatas y tiene relacin con la intencin de saber la opcin que se adapta mejor a cierto atributo de calidad. Este tipo de medicin brinda respuestas afirmativas o negativas, sin mayor nivel de detalle. La medicin cuantitativa busca la obtencin de valores que permitan tomar decisiones en cuanto a los atributos de calidad de una arquitectura de software. El esquema general es la comparacin con mrgenes establecidos, como lo es el caso de los requerimientos de desempeo, para establecer el grado de cumplimiento de una arquitectura candidata, o tomar decisiones sobre ella. Este enfoque permite establecer comparaciones, pero se ve limitado en tanto no se conozcan los valores tericos mximos y mnimos de las mediciones con las que se realiza la comparacin. Por ltimo, la medicin de mximo y mnimo terico contempla los valores tericos para efectos de la comparacin de la medicin con los atributos de calidad especificados. El conocimiento de los valores mximos o mnimos permite el establecimiento claro del grado de cumplimiento de los atributos de calidad. En lneas generales, el planteamiento anterior presenta los objetivos para efectos de la medicin de los atributos de calidad. Sin embargo, en ocasiones, la evaluacin de una arquitectura de software no produce valores numricos que permiten la toma de decisiones de manera directa. Ante la posibilidad de efectuar evaluaciones a cualquier nivel del proceso de diseo, con distintos niveles de especificacin, se propone un esquema general en relacin a la evaluacin de una arquitectura con respecto a sus atributos de calidad. En este sentido se afirman que de la evaluacin de una arquitectura no se obtienen respuestas del tipo si - no, bueno malo o 6.75 de 10, sino que explica cules son los puntos de riesgo del diseo evaluado.

TCNICAS DE EVALUACIN DE ARQUITECTURAS DE SOFTWARE

Las tcnicas utilizadas para la evaluacin de atributos de calidad requieren grandes esfuerzos por parte del ingeniero de software para crear especificaciones y predicciones. Estas tcnicas requieren informacin del sistema a desarrollar que no est disponible durante el diseo arquitectnico, sino al principio del diseo detallado del sistema. En vista de que el inters es tomar decisiones de tipo arquitectnico en las fases tempranas del desarrollo, son necesarias tcnicas que requieran poca informacin detallada y puedan conducir a

resultados relativamente precisos. Las tcnicas existentes en la actualidad para evaluar arquitecturas permiten hacer una evaluacin cuantitativa sobre los atributos de calidad a nivel arquitectnico, pero se tienen pocos medios para predecir el mximo (o mnimo) terico para las arquitecturas de software. Sin embargo, debido al costo de realizar este tipo de evaluacin, en muchos casos los arquitectos de software evalan cualitativamente, para decidir entre las alternativas de diseo. Existen diferentes tcnicas de evaluacin entre las cuales se pueden mencionar: Evaluacin basada en escenarios un escenario es una breve descripcin de la interaccin de alguno de los involucrados en el desarrollo del sistema con ste. Por ejemplo, un usuario har la descripcin en trminos de la ejecucin de una tarea; un encargado de mantenimiento har referencia a cambios que deban realizarse sobre el sistema; un desarrollador se enfocar en el uso de la arquitectura para efectos de su construccin o prediccin de su desempeo. Un escenario consta de tres partes:

el estmulo. el contexto. la respuesta.

El estmulo es la parte del escenario que explica o describe lo que el involucrado en el desarrollo hace para iniciar la interaccin con el sistema. Puede incluir ejecucin de tareas, cambios en el sistema, ejecucin de pruebas, configuracin, etc. El contexto describe qu sucede en el sistema al momento del estmulo. La respuesta describe, a travs de la arquitectura, cmo debera responder el sistema ante el estmulo. Este ltimo elemento es el que permite establecer cul es el atributo de calidad asociado. Los escenarios proveen un vehculo que permite concretar y entender atributos de calidad. Entre las ventajas de su uso estn:

Son simples de crear y entender Son poco costosos y no requieren mucho entrenamiento Son efectivos

Evaluacin basada en simulacin La evaluacin basada en simulacin utiliza una implementacin de alto nivel de la arquitectura de software. El enfoque bsico consiste en la implementacin de componentes de la arquitectura y la implementacin La finalidad es evaluar el comportamiento de la arquitectura bajo diversas circunstancias. Una vez disponibles estas implementaciones, pueden usarse los perfiles respectivos para evaluar los atributos de calidad. El proceso de evaluacin basada en simulacin sigue los siguientes pasos:

Definicin e implementacin del contexto. Consiste en identificar las interfaces de la arquitectura de software con su contexto, y decidir cmo ser simulado el comportamiento del contexto en tales interfaces. Implementacin de los componentes arquitectnicos. La descripcin del diseo arquitectnico debe definir, por lo menos, las interfaces y las conexiones de los componentes, por lo que estas partes pueden ser tomadas directamente de la descripcin de diseo. El comportamiento de los componentes en respuesta a eventos sobre sus interfaces puede no ser especificado claramente, aunque generalmente existe un conocimiento comn y es necesario que el arquitecto lo interprete, por lo que ste decide el nivel de detalle de la implementacin. Implementacin del perfil. Dependiendo del atributo de calidad que el arquitecto de software intenta evaluar usando simulacin, el perfil asociado necesitar ser implementado en el sistema. El arquitecto de software debe ser capaz de activar escenarios individuales, as como tambin ejecutar un perfil completo usando seleccin aleatoria, basado en los pesos normalizados de los mismos. Simulacin del sistema e inicio del perfil. El arquitecto de software ejecutar la simulacin y activar escenarios de forma manual o automtica, y obtendr resultados de acuerdo al atributo de calidad que est siendo evaluado. Prediccin de atributos de calidad. Dependiendo del tipo de simulacin y del atributo de calidad evaluada, se puede disponer de cantidades excesivas de datos, que requieren ser condensados. Esto permite hacer conclusiones acerca del comportamiento del sistema. En el mbito de las simulaciones, se encuentra la tcnica de implementacin de prototipos (prototyping). Esta tcnica implementa una parte de la arquitectura de software y la ejecuta en el contexto del sistema. Es utilizada para evaluar requerimientos de calidad operacional, como desempeo y confiabilidad. Para su uso se necesita mayor informacin sobre el desarrollo y disponibilidad del hardware, y otras partes que constituyen el contexto del sistema de software. Se obtiene un resultado de evaluacin con mayor exactitud. La exactitud de los resultados de la evaluacin depende, a su vez, de la exactitud del perfil utilizado para evaluar el atributo de calidad y de la precisin con la que el contexto del sistema simula las condiciones del mundo real. En trminos de los instrumentos asociados a las tcnicas de evaluacin basadas en simulacin, se encuentran los lenguajes de descripcin arquitectnica, descritos en la seccin 7, y los modelos de colas. Evaluacin basada en modelos matemticos La evaluacin basada en modelos matemticos se utiliza para evaluar atributos de calidad operacionales. Permite una evaluacin esttica de los modelos de diseo arquitectnico, y se presentan como alternativa a la simulacin, dado que evalan el mismo tipo de atributos. Ambos enfoques pueden ser combinados, utilizando los resultados de uno como entrada para el otro. El proceso de evaluacin basada en modelos matemticos sigue los siguientes pasos: Seleccin y adaptacin del modelo matemtico. La mayora de los centros de investigacin orientados a atributos de calidad han desarrollado modelos matemticos para medir sus atributos de calidad, los cuales tienden a ser muy elaborados y detallados, as como tambin requieren de cierto tipo de datos y anlisis. Parte de estos datos requeridos no estn disponibles a nivel de arquitectura, y la tcnica requiere

mucho esfuerzo para la evaluacin arquitectnica, por lo que el arquitecto de software se ve obligado a adaptar el modelo. Representacin de la arquitectura en trminos del modelo. El modelo matemtico seleccionado y adaptado no asume necesariamente que el sistema que intenta modelar consiste de componentes y conexiones. Por lo tanto, la arquitectura necesita ser representada en trminos del modelo. Estimacin de los datos de entrada requeridos. El modelo matemtico an cuando ha sido adaptado, requiere datos de entrada que no estn incluidos en la definicin bsica de la arquitectura. Es necesario estimar y deducir estos datos de la especificacin de requerimientos y de la arquitectura diseada. Evaluacin basada en experiencia En muchas ocasiones los arquitectos e ingenieros de software otorgan valiosas ideas que resultan de utilidad para la evasin de decisiones erradas de diseo. Aunque todas estas experiencias se basan en evidencia anecdtica; es decir, basada en factores subjetivos como la intuicin y la experiencia. Sin embargo, la mayora de ellas puede ser justificada por una lnea lgica de razonamiento, y pueden ser la base de otros enfoques de evaluacin. Existen dos tipos de evaluacin basada en experiencia: la evaluacin informal, que es realizada por los arquitectos de software durante el proceso de diseo, y la realizada por equipos externos de evaluacin de arquitecturas.

HERRAMIENTAS DE ANLISIS, DISEO Y EVALUACIN DE ARQUITECTURAS DE SOFTWARE

Una herramienta de anlisis y diseo de arquitecturas de software debe cumplir con ciertos requerimientos, entre los que se encuentran: Debe ser capaz de describir cualquier arquitectura. En principio, debe permitir la especificacin grfica de arquitecturas, de forma similar a como se lleva a cabo en un equipo de desarrollo. Los esbozos grficos de la arquitectura se realizan para facilitar el diseo, la exploracin y la comunicacin. Para lograr el mejor cumplimiento del objetivo, la herramienta deber hacer uso de los componentes y los conectores que el equipo de desarrollo actualmente usa, ms que el uso de un grupo preestablecido por la herramienta. Debe ser capaz de aadir elementos arquitectnicos de forma recursiva, y poder establecer asociaciones semnticamente significativas con elementos en otros niveles de abstraccin. El cumplimiento de este requerimiento es crucial para soportar el refinamiento iterativo y el anlisis de arquitecturas, donde el anlisis es significativo a cualquier nivel de refinamiento. Por ejemplo, debera permitir esbozar un nodo en la arquitectura bajo el nombre base de datos, y permitir preguntas importantes de diseo, o ejecutar anlisis de desempeo, sin la necesidad de mayor descomposicin del elemento definido. Con el cumplimiento de este requerimiento, la herramienta debera permitir el diseo y anlisis arquitectnico en cualquier grado de resolucin. Por supuesto, a mayor grado de resolucin, mejores deben ser las respuestas a la hora de comparar varias alternativas. Debe ser capaz de determinar la concordancia de interfaces entre componentes, tanto dentro de la arquitectura que se est diseando, como con sistemas externos. De igual forma, debe estar en capacidad de determinar la correspondencia de la arquitectura implementada con la arquitectura diseada.

Debe contar con la capacidad de realizar ingeniera de reverso. Debe ser capaz de analizar arquitecturas con respecto a mtricas. Debe asistir al desarrollador en el diseo, tanto como una actividad creativa, como una actividad de anlisis. En especfico, se propone que debe soportar distintos mtodos de diseo, y los procesos que estos mtodos implican. Debe funcionar como un repositorio que contenga diseos, trozos de diseo, justificaciones de diseo y escenarios. Como repositorio, debe permitir la bsqueda de una arquitectura, la extraccin de subconjuntos significativos de sta, y tambin permitir su actualizacin. Debe proveer la generacin de plantillas de cdigo, para simplificar la transicin del diseo al cdigo, contribuyendo as con la consistencia entre ambos. De igual forma, debe proveer herramientas de modelaje de control de datos y flujo, as como tambin modelaje de desempeo. El planteamiento de no contempla aspectos de evaluacin de las arquitecturas de software diseadas con una herramienta que cumpla con los requerimientos mencionados. Por otro lado, considerando que la calidad de un sistema de software est determinada en gran parte por su arquitectura, resulta de particular inters extender el alcance de tal herramienta, agregando la capacidad de evaluacin del diseo generado. La intencin es entonces resaltar algunos de los elementos que an pueden aadrsele a una herramienta como la propuesta por, que derive en un ambiente que tenga otras capacidades no consideradas an. Entre ellas se encuentran: 1. Inclusin de nuevos elementos de descripcin, tales como los ADL, vistas arquitectnicas y distintas notaciones. 2. Posibilidad de evaluar la calidad de la arquitectura diseada en base a los elementos de diseo utilizados. 3. Ofrecer la posibilidad de soporte a los distintos mtodos y tcnicas de evaluacin de arquitecturas de software. Para efectos de la evaluacin, resulta interesante conocer los distintos tipos de decisin que pueden ser tomados a nivel de diseo, puesto que un ambiente de evaluacin y anlisis debe estar en capacidad de soportar estos procesos. A nivel arquitectnico, establecen que los tpicos de decisin con frecuencia son:

Estilos y patrones arquitectnicos Arquitecturas de referencia Responsabilidades asociadas a los componentes Identificacin de interconexiones entre componente. Comportamiento dinmico del sistema Interfaces entre componentes y sus responsabilidades Manejo de mltiples configuraciones para sistemas distribuidos o concurrentes.

Este proceso de anlisis y diseo de arquitecturas de software presenta sobrecargas de recoleccin, manejo y presentacin de la informacin relevante a ellos. Esto resulta un impedimento sustancial para las organizaciones que quieren adoptar una actitud ms madura a su prctica en el diseo de arquitecturas de software. Proveer una herramienta que soporte estas prcticas es un primer paso de ayuda a extender su adopcin en la industria. Es importante que el ambiente est en capacidad de asistir en el proceso de

diseo para efecto de la toma de decisiones, independientemente de la metodologa y en el nivel en que se encuentre el proceso de desarrollo. Al aadirle la capacidad de apoyo a la evaluacin del diseo, con el manejo de las tcnicas y mtodos existentes hasta el momento, la herramienta proveer informacin acerca de los puntos de riesgo en el diseo que se est evaluando. Esto resulta de gran ayuda al arquitecto al momento de tomar decisiones que harn posible la satisfaccin de los requerimientos de calidad por parte del diseo en cuestin. Si bien es cierto que la calidad del sistema depende en gran parte de la implementacin, tambin es cierto que gran parte de ella depende de la arquitectura. De aqu la importancia de la correspondencia entre el diseo y la implementacin. Es por ello que el ambiente de anlisis, diseo y evaluacin de arquitecturas de software se propone como un medio que permitira la satisfaccin de los requerimientos de calidad del sistema establecidos por los involucrados en el desarrollo del mismo.

UNIDAD III: INTERFAZ DE USUARIO

DISEO DE INTERFACES DE USUARIO
La interfaz de usuario (IU) es uno de los componentes ms importantes de cualquier sistema computacional, pues funciona como el vnculo entre el humano y la mquina. La interfaz de usuario es un conjunto de protocolos y tcnicas para el intercambio de informacin entre una aplicacin computacional y el usuario. La IU es responsable de solicitar comandos al usuario, y de desplegar los resultados de la aplicacin de una manera comprensible. La IU no es responsable de los clculos de la aplicacin, ni del almacenamiento, recuperacin y transmisin de la informacin. El xito de un programa frecuentemente se debe a qu tan rpido puede aprender el usuario a emplear el software, de igual importancia es el que el usuario alcance sus objetivos con el programa de la manera ms sencilla posible. Para trabajar con un sistema, los usuarios necesitan ser capaces de controlar y monitorear el estado del sistema. Por ejemplo, para conducir un automvil, el conductor usa el volante para controlar la direccin del vehculo, el pedal del acelerador y el pedal del freno para controlar su velocidad. El conductor puede percibir la posicin del vehculo mirando a travs del parabrisas y leyendo el velocmetro puede conocer la velocidad exacta del vehculo. La interface del automvil est compuesta por la totalidad de instrumentos que el conductor usa para cumplir las tareas de llevar y dirigir el automvil. La interaccin hombre-computadora comprende todo lo que ocurre cuando un hombre y un sistema computarizado realizan tareas juntas. Esto involucra tanto al rol de programador como al rol de usuario final, en un dilogo hombre-computadora en el que media una interfaz. Esas interacciones estn relacionadas con una diversidad de aspectos, dentro de los que se incluye: la realizacin de tareas por hombres y mquinas, la estructura de la comunicacin hombre-mquina, las interacciones organizacionales y sociales, las capacidades humanas incluyendo el aprendizaje, los algoritmos y programacin de la propia interfaz, las restricciones de la propia tecnologa para el diseo y construccin de las interfaces. Por un lado el usuario debe conocer el funcionamiento de la interfaz a un nivel operativo, implicando adems una situacin de aprendizaje y el involucramiento de procesos cognitivos.

Todo aprendizaje implica tanto la creacin, como el cambio de estado de las estructuras del conocimiento. Ambos aspectos son necesarios para la adaptacin a nuevas experiencias y a la solucin de problemas. Los procesos cognitivos asociados a las estrategias de construccin del conocimiento involucran distintos tipos de operaciones:

exteriorizacin: es el proceso de externalizar el conocimiento que un individuo posee; representacin: implica como el conocimiento es exteriorizado y representado usando medios de comunicacin; asimilacin: proceso que se refiere a las formas por las cuales el conocimiento es exteriorizado, adquirido y utilizado

Por otra parte la interfaz debe estar diseada en funcin de las caractersticas de ese usuario o adecuarse a distintos tipos de usuarios. Uno de los caminos para lograr esto es el Modelado de Usuarios.

PRINCIPIOS PARA EL DISEO DE INTERFACES DE USUARIO.

Familiaridad del usuario:

Utilizar trminos y conceptos que se toman de la experiencia de las personas que ms utilizan el sistema.

Consistencia:

Siempre que sea posible, la interfaz debe ser consistente en el sentido de que las operaciones comparables se activan de la misma forma.

Mnima sorpresa:

El comportamiento del sistema no debe provocar sorpresa a los usuarios.

Recuperabilidad:

La interfaz debe incluir mecanismos para permitir a los usuarios recuperarse de los errores. Esto puede ser de dos formas:

1. Confirmacin de acciones destructivas 2. Proveer de un recurso para deshacer Gua al usuario:

Cuando los errores ocurren, la interfaz debe proveer retroalimentacin significativa y caractersticas de ayuda sensible al contexto.

Diversidad de usuarios:

La interfaz debe proveer caractersticas de interaccin apropiada para los diferentes tipos de usuarios.

INTERACCION CON EL USUARIO

Una interfaz coherente debe integrar la interaccin del usuario y la presentacin de la informacin. Shneiderman(1998) clasifica la interaccin en 5 estilos primarios: Manipulacin directa:

Interaccin directa con los objetos de la pantalla. Rpida e intuitiva Fcil de aprender Ejemplo: para borrar un archivo, el usuario lo arrastra al bote de basura. Videos de juegos Puede ser difcil de implementar. Slo es adecuada donde hay una metfora visual para las tareas y objetos.

Seleccin de mens:

El usuario selecciona un comando de una lista de posibilidades. Evita errores del usuario Se requiere teclear poco Lenta para usuarios experimentados. Puede llegar a ser complejo si existen muchas opciones en el men. Ejemplo: muchos de los sistemas de propsito general Puede ser difcil de implementar. Slo es adecuada donde hay una metfora visual para las tareas y objetos.

Lenguaje Natural:

El usuario emite comandos en lenguaje natural. Accesible a usuarios casuales Fcil de ampliar Se requiere teclear ms. Los sistemas de comprensin de lenguaje natural no son fiables. Ejemplo: Sistemas de horarios, sistemas www de recuperacin de la informacin.

COLOR DE LA INTERFAZ
Aunque se utilicen convenciones de color en la IU, se deberan usar otros mecanismos secundarios para proveer la informacin a aquellos usuarios con problemas en la visualizacin de colores El color ayuda y mejora la presentacin de la interfaz, permitiendo al usuario comprender y manejar la complejidad. Shneiderman(1998) establece 14 lineamientos claves para la utilizacin efectiva del color. Los ms relevantes:

Limitar el nmero de colores utilizados y ser conservador al momento de utilizarlos. No utilizar ms de 4 5 colores diferentes en una ventana y no ms de 7 en la interfaz total del sistema.

Utilizar un cambio de color para mostrar un cambio en el estado del sistema.

Ejemplo semforos de alerta que reportan estados normales, precaucin y alarma.

Utilizar el cdigo de colores para apoyar la tarea que los usuarios estn tratando de llevar a cabo.* Un color para resaltar una situacin anmala, otro para similitudes. Utilizar el cdigo de colores en una forma consciente y consistente.

Si usamos rojo para mostrar alarma , mantener esta lgica durante todo el sistema Ser cuidadoso al utilizar pares de colores Dada la fisiologa del ojo, las personas no pueden enfocar el rojo y el azul simultneamente.

En general el color no debe utilizarse para representar algn significado por dos razones:

Cerca del 10 % de los hombres no perciben el color y pueden malinterpretar el significado. Las percepciones humanas del color son diferentes y existen convenciones diversas para varias profesiones Ej. Rojo para conductor significa peligro, para el qumico es caliente.

Si se utilizan muchos colores o sin son muy brillantes, el despliegue puede ser confuso

DESCONOCIMIENTO DEL USUARIO

Es difcil saber el grado de conocimientos de cmputo del usuario final, lo cual, frecuentemente, hace que las interfaces de usuario desarrolladas no sean las apropiadas. Se da el caso de que el diseador implemente la IUs pensando en que la van a usar programadores avanzados, como el propio diseador, por lo que cuando el producto final es usado por el usuario es posible que se presenten una gran cantidad de problemas de usabilidad.

TIPOS DE INTERFACES DE USUARIO

Segn la forma de interactuar del usuario Atendiendo a como el usuario puede interactuar con una interfaz, nos encontramos con varios tipos de interfaces de Usuario:

Interfaces alfanumricas (intrpretes de mandatos) que solo presentan texto. Interfaces grficas de usuario (GUI, Graphics User Interfaces): las que permiten comunicarse con el ordenador de una forma muy rpida e intuitiva representando grficamente los elementos de control y medida. Interfaces tctiles: que representan grficamente un "panel de control" en una pantalla sensible que permite interaccionar con el dedo de forma similar a si se accionara un control fsico.

Segn su construccin Pueden ser de hardware o de software: * Interfaces hardware:Se trata de un conjunto de controles o dispositivos que permiten la interaccin hombre-mquina, de modo que permiten introducir o leer datos del equipo, mediante pulsadores, reguladores e instrumentos. * Interfaces software: Son programas o parte de ellos, que permiten expresar nuestros deseos al ordenador o visualizar su respuesta.

INTERFAZ GRFICA DE USUARIO

En el contexto del proceso de interaccin persona - ordenador, la interfaz grfica de usuario es el artefacto tecnolgico de un sistema interactivo que posibilita, a travs del uso y la representacin del lenguaje visual, una interaccin amigable con un sistema informtico. La interfaz grfica de usuario (en Idioma ingls Graphical User Interface, GUI) es un tipo de interfaz de usuario que utiliza un conjunto de imgenes y objetos grficos para representar la informacin y acciones disponibles en la interfaz. Habitualmente las acciones se realizan mediante manipulacin directa para facilitar la interaccin del usuario con la computadora. Surge como evolucin de la lnea de comandos de los primeros sistemas operativos y es pieza fundamental en un entorno grfico. Como ejemplo de interfaz grfica de usuario podemos citar el escritorio o 'desktop' del sistema operativo Windows y el entorno X-Window de Linux y tambin Aqua de Mac OS X

METFORAS VISUALES
Una metfora es una figura del lenguaje donde se realiza una comparacin entre dos objetos que no tienen ninguna relacin aparente. Un objeto es sustituido en una frase por un segundo objeto transmitindole al primer objeto sus caractersticas explcitas e implcitas. Un ejemplo de metfora es la conocida frase El tiempo es oro donde se transfieren las caractersticas de la palabra oro (valioso, escaso, preciado) a la palabra tiempo para dar a entender su valor. Originalmente metfora es una palabra griega que significaba transferir. Su etimologa viene de meta que significa cambio y pherein que significa llevar o trasladar. As, la palabra Metfora tiene a su vez un significado metafrico: llevar o transferir un significado de una cosa a otra. Las metforas visuales funcionan de una manera similar, se sustituye un mensaje complejo mediante una imagen ms simple pero evocativa que le transfiere a ste su significado. Por ejemplo cuando una empresa que produce jugos de frutas enlatados le pone a su producto una marca con un pictograma representando a un rbol est pretendiendo sustituir en la mente del receptor las caractersticas del producto (enlatado, industrializado, producido en serie etc.) por las del rbol (naturaleza,frescura,saludable). Eso es una metfora visual.

APLICACIONES CONOCIDAS
El Escritorio La metfora del escritorio (desktop) es una de las ms populares y extendidas en las interfaces humanocomputadora. sta fue muy conscientemente utilizada en el diseo del entorno de la Apple Macintosh. Es una metfora compleja, ya que lleva contenida dentro de s otras metforas ms simples. Simula el entorno del sistema como un escritorio sobre el cual se colocan archivos, ficheros, carpetas, discos, etc. con los cuales interactuamos y organizamos la informacin almacenada en el sistema. Tambin en el escritorio virtual de la computadora podemos encontrar otros objetos como el cesto de basura, un calendario o un reloj que permiten al usuario accesar a otros aspectos funcionales del sistema de una manera intuitiva. Su funcin es fcil de entender para un usuario, aun sin entrenamiento formal en informtica. Ya que puede trasladar los conocimientos adquiridos en su experiencia con objetos tangibles al entorno virtual e informtico. Esto es un logro muy significativo de las interfaces grficas sobre las antiguas Interfaces de Lnea de Comando. Si el usuario abre una carpeta y se encuentra con fichero que cree que no debera estar ah, simplemente lo arrastra con el puntero de su ratn hasta la carpeta correcta. Si el fichero en

cuestin ya no le es til, entonces lo arrastra al cesto de basura sabiendo que si se quedar ah por si cambia de opinin hasta que vace el cesto definitivamente. Casi como en la vida real. Las Pestaas. Las pestaas que sobresalen de entre todas las carpetas dentro del cajn de un archivero ayudan a separar visualmente en secciones los montones de carpetas beige que tienden a lucir todas iguales. A dems, sobre las pestaas se pueden escribir descripciones taxonmicas sobre el contenido de la seccin dndole un sentido ms formal y amigable a la categorizacin de los contenidos. Ya que un sitio web est por lo regular dividido en varias secciones que categorizan la informacin proporcionada por el sitio, para proveer al usuario una forma de acceso al contenido ms organizada. Para acceder a las diferentes secciones del sitio, se acostumbra colocar una lista de enlaces que sirven como atajos a todas y cada una de las categoras del sitio de forma consistente a travs de todas las pginas que la conforman. A esa lista consistente de enlaces se le denomina navegacin. La navegacin de un sitio puede ser presentada de muchas maneras, pero a medida que el desarrollo web va madurando se van creando estndares o patrones de diseo que son familiares a los usuarios y aumentan el sentido de usabilidad del sitio web en cuestin. Una de las maneras ms efectivas de presentar la navegacin es disendola de manera que se asemeje a las pestaas de los archiveros que mencionamos antes, esto es, la metfora de las pestaas (tabs). Las pestaas son mostradas en la parte superior de cada pgina y el rea inferior est conectada visualmente con sta. La informacin colocada en el panel debajo de la pestaa corresponde a la categora sealada en la pestaa seleccionada. La categora seleccionada es resaltada mediante contrastes de color, forma, tamao o tipografa. Es mejor combinar el contraste necesario haciendo combinaciones de color y tamao. Conectando usualmente la pestaa seleccionada con el rea debajo de sta, por ejemplo disendolas con el mismo color de fondo, la relacin es reforzada considerablemente. Cabe notar que la funcin de un sistema de navegacin diseado segn la metfora de pestaas y cualquier otra coleccin de enlaces sin estilo aplicado no cambia, pero para el usuario es ms fcil interactuar con algo que le resulta familiar. conos. Los conos son representaciones ideogrficas con un alto nivel de sntesis puesto que tienen que representar significados complejos en imgenes simples. Los conos han sido utilizados por mucho tiempo, desde la edad media se han desarrollado complejos sistemas icnicos como los escudos de armas herldicos y signos astrolgicos. En la sociedad moderna todos estamos familiarizados con los conos dentro y fuera del trabajo: por ejemplo, conos en la puerta de los baos, conos en las seales de trnsito e conos ms complejos en los aparatos electrnicos. La ideografa es ms fundamental al lenguaje de lo que nos damos cuenta. A travs de nuestro lenguaje hablado y escrito lo que hacemos es pintar imgenes en las mentes de los lectores y escuchas. De una manera anloga, las imgenes pueden ser utilizadas con propsitos comunicacionales. Los ideogramas son capaces de comunicar ideas abstractas a pasear de ser slo formas visuales y a travs del uso de metforas, las imgenes pueden encapsular prcticamente cualquier idea. En el mbito computacional, el uso de los conos ha sido una extensin de su uso tradicional con la posibilidad aadida de interaccin que ofrecen las tecnologas modernas. Idealmente, una interfaz

construida slo con conos debera ser comprensible por cualquier persona independientemente del lenguaje que habla puesto que sera capaz de reconocer las metforas representadas en pantalla e interpretarlas en base a su conocimiento adquirido sobre los objetos con los que tiene una se comparan esos conos. Por eso la metfora del escritorio tuvo tanto xito, ya que era sencillo reconocer la funcin de ciertos objetos en pantalla gracias a su apariencia. Un cono en forma de carpeta debera tener la funcionalidad de almacenar documentos y otro en forma de cesto de basura tendra que servir para deshacerse de aquello que se considera basura. Pero no siempre es tan sencillo construir los ideogramas, porque los significados no son siempre tan simples. A menudo un cono tiene que representar la funcionalidad compleja de una aplicacin y debe valerse de metforas compuestas para lograrlo. Antes de explorar el proceso de desarrollo de un sistema de metforas icnicas primero debemos ver el proceso de comunicacin. En este caso la comunicacin se refiere al mensaje transmitido entre el diseador de la aplicacin y el usuario. Un cono es percibido primero por su forma (sintaxis), despus por la forma entre su forma y su significado (semntica) y en tercer lugar por su utilidad (pragmatismo). Sintaxis de los conos El significado de un cono se puede alterar mediante la combinacin de varios conos en uno mismo, lo que nos permite crear metforas compuestas que abarquen un abanico mayor de significados abstractos. Las tcnicas de sintaxis son: Superimposicin: Sucede cuando cono es colocado encima de otro. Por ejemplo, colocando un pequeo cono de buscar generalmente un lente de aumento o unos binoculares sobre el cono de documento una hoja con una esquina doblada su significado combinado podra ser buscar en documento. Los elementos superpuestos tienen una jerarqua visual que separa los elementos primarios de los secundarios. Los elementos secundarios son denominados credenciales. El ejemplo anterior el cono pequeo de buscar es una credencial para documento. Si intercambiamos el sentido de la jerarqua visual y dejamos el elemento de documento como credencial para bsqueda entonces el significado podra cambiar a documento de bsquedas refirindose tal vez a un fichero donde se almacenan los resultados de las bsquedas realizadas. Yuxtaposicin: Sucede cuando dos conos son colocados en una determinada relacin espacial pero con el mismo peso visual, para expresar un mayor significado. Por ejemplo, un calendario junto a un reloj significa Fecha y hora. Tambin puede ser usada esta tcnica para representar causa y efecto, por ejemplo un globo de texto puede significar comentario, si es precedido por un smbolo de adicin (+) entonces su significado conjunto es aadir comentario. Duplicacin: Para indicar pluralidad, basta con colocar varias instancias de un smbolo uno encima de otro. Uno o ms conos de carpetas apilados significarn entonces carpetas.

FACTORES DE DISEO EN EL MENSAJE DE ERROR

Contexto:

El sistema gua del usuario debe estar pendiente de lo que hace el usuario y ajustar el mensaje de salida al contexto actual.

Experiencia:

Al aumentar la familiaridad con el sistema, aumenta la molestia por mensajes largos y sin significado. El usuario principiante no comprende los mensajes concisos. El sistema debe proveer de ambos tipos de mensajes

Nivel de habilidad:

Conocer al usuario y sus habilidades implica adecuar los mensajes a la terminologa que el utiliza.

Estilo:* Los mensajes deben ser positivos en lugar de negativos. Activos y no pasivos. No deben ser insultantes o tratar de ser chistosos. Cultura:

Reconocer la cultura del pas en lo posible evitar malas interpretaciones del contexto del mensaje.

EJEMPLO

RECUPERACION DE LA INFORMACION
La referencia a la Recuperacin de Informacin (RI) obedece a que es un claro ejemplo donde la interfaz juega un papel de intermediario entre el usuario y el objetivo que persigue. Los tems abordados por esta rea comprenden: cmo representar y organizar la informacin intelectualmente, cmo especificar una bsqueda intelectualmente y cules son los sistemas y tcnicas utilizadas para estos procesos. La efectividad de un sistema de recuperacin de informacin est relacionada a la relevancia de la informacin obtenida y a los procesos de interaccin. La relevancia refiere a la pertinencia de la informacin con respecto a las necesidades del usuario, involucrando tambin los estados cognitivos y afectivos y creencias del mismo. Los procesos de interaccin refieren al relacionamiento hombre-sistema de recuperacin de informacin mediado por la interfaz. En este contexto una interfaz debe posibilitar representar las necesidades de informacin del usuario, buscar la informacin apropiada para esas necesidades particulares y evaluar la efectividad de los resultados obtenidos. Para ello debe tener en cuenta:

Analizar el problema o consulta planteado por el usuario Elegir una estrategia de respuesta segn el tipo de problema o consulta Posibilitar el dilogo entre sistema y usuario Inferir la evaluacin del usuario sobre: La correspondencia de los resultados logrados con el problema

La necesidad de modificar la pregunta inicial o finalizacin si el usuario est satisfecho Vuelta sobre el anlisis de la pregunta y seleccin de nuevas respuestas si fuera necesario

TIEMPO DE RESPUESTA
Tiene dos caractersticas importantes: 1. El retardo. 2. La variabilidad. Si el retardo de respuesta es demasiado grande, producir frustracin y stress en el usuario. Sin embargo un retardo de respuesta muy rpido puede confundir al usuario que es guiado por la interfaz, llevndolo a producir errores. La variabilidad est referida a la desviacin del tiempo de respuesta medio

EVALUACION DE LA INTERFAZ
Aprendizaje: Cunto tiempo tarda un usuario nuevo en ser productivo con el sistema? Velocidad de operacin: Qu tan bien responde el sistema a las operaciones de trabajo del usuario? Robustez: Qu tan tolerante es el sistema a los errores del usuario? Recuperacin: Qu tan bien se recupera el sistema a los errores del usuario? Adaptacin: Qu tan atado est el sistema a un solo modelo de trabajo?

PSICOLOGIA HCI
HCI, son las siglas de Human Computer Interaction, expresin que hace referencia al mbito de investigacin y formacin cientfico tecnolgica orientado a la comprensin del fenmeno de la interaccin entre el usuario el humano y la computadora. En HCI se hacen aportaciones desde diversas reas de conocimiento tales como, la ingeniera informtica, la ingeniera del software, la ingeniera de sistemas, la psicologa (especialmente relevante la psicologa cognitiva y, ms recientemente la psicologa de la emociones y la psicologa de la conducta), la neurociencia, la sociologa o el diseo. Los conocimientos que se obtienen en la investigacin sobre la interaccin humana computadora, constituyen la base sobre la cual se construyen los propios ordenadores, se crean las aplicaciones informticas que se ejecutan en ellos, y se disean las interfaces de usuario que permiten la interaccin entre el humano y la mquina. Dentro de la HCI, un mbito de conocimiento relevante es el que gira entorno de lo que denominamos Factor Humano. La expresin Factor Humano se refiere al mbito de conocimiento cientfico sobre las capacidades del ser humano. Cuando este conocimiento es aplicado al diseo o desarrollo de productos, tales como los sistemas o aplicaciones informticas, se denomina Ingeniera de Factor Humano. Los orgenes de la HCI hay que buscarlas en la rama de la Psicologa Aplicada que estudia la Interaccin Persona-Ordenador. Las dos disciplinas de las que surge la IPO/HCI son las llamadas "Human Factors" y la Ergonoma (en realidad es la misma disciplina, el primer trmino se utiliza en EE.UU y el segundo en Europa). Actualmente el uso de estos trminos no est claramente establecido y incluso a veces se utilizan de manera indistinta. El predominio tradicional en la HCI ha sido de los ingenieros, aunque la

influencia de la psicologa es creciente. La Psicologa es la disciplina que estudia la percepcin, la memoria, la adquisicin de habilidades y el aprendizaje, la resolucin de problemas, el movimiento, las tareas de juicio, de bsqueda o procesamiento de informacin y de la comunicacin, es decir, procesos todos cuyo conocimiento se requiere para el adecuado diseo de mecanismos de interaccin del usuario. Aunque la Psicologa Cognitiva es una ciencia muy joven en lo que respecta a investigaciones de carcter bsico y sistemtico, existen actualmente suficientes hallazgos basados en resultados empricos que permiten el desarrollo de la HCI y, por ende, de sitios web adaptados a los usuarios. La HCI es tambin una disciplina joven, pero no tanto como pudiera parecer. Desde el primer ordenador ha sido necesario el diseo de un sistema de comunicacin persona-ordenador. Los estudios en esta disciplina han permitido dar una base terica al diseo y a la evaluacin de aplicaciones informticas. La importancia de esta disciplina se pone sobre relieve al leer artculos sobre el tema escritos hace cuarenta aos en los que se predecan elementos de interaccin de los que se dispone actualmente. Una de las asociaciones ms influyentes en este campo es la ACM SIGCHI (Association for Computing Machinery's Special Interest Group on Computer-Human Interaction) que desde 1982 rene a los mejores especialistas en IPO/HCI. Los primeros estudios especficos de IPO/HCI aparecieron en los aos sesenta y se referan a la simbiosis Persona-Ordenador (Licklider, 1960). Este autor afirm anticipndose a la problemtica posterior que el problema de la interaccin hombre-ordenador no es crear ordenadores productores de respuestas, sino ordenadores que sean capaces de anticipar y participar en la formulacin de las preguntas. Licklider y Clark (1962) elaboraron una lista de 10 problemas que deberan ser resueltos para facilitar la interaccin personas-ordenador. Segn el los cinco primeros problemas deberan ser resueltos de manera inmediata, el sexto en un tiempo intermedio y los cuatro ltimos, a largo plazo: 1. 2. 3. 4. 5. Compartir el tiempo de uso de los ordenadores entre muchos usuarios. Un sistema de entrada-salida para la comunicacin mediante datos simblicos y grficos. Un sistema interactivo de proceso de las operaciones en tiempo real. Sistemas para el almacenamiento masivo de informacin que permitan su rpida recuperacin. Sistemas que faciliten la cooperacin entre personas en el diseo y programacin de grandes sistemas. 6. Reconocimiento por parte de los ordenadores de la voz, de la escritura manual impresa y de la introduccin de datos a partir de escritura manual directa. 7. Comprensin del lenguaje natural, sintctica y semnticamente. 8. Reconocimiento de la voz de varios usuarios por el ordenador. 9. Descubrimiento, desarrollo y simplificacin de una teora de algoritmos. 10. Programacin heurstica o a travs de principios generales. 11. El tiempo ha demostrado que Licklider y Clark estaban en lo cierto en la mayora de sus observaciones, sin embargo, actualmente an no se han conseguido solucionar algunos de los problemas previstos para su resolucin a largo plazo. Hansen (1971) en su libro "User Engineering Principles for Interactive Systems" hace la primera enumeracin de principios para el diseo de sistemas interactivos: 1. Conocer al usuario 2. Minimizar la memorizacin, sustituyendo la entrada de datos por la seleccin de tems, usando nombres en lugar de nmeros, asegurndose un comportamiento predecible y proveyendo acceso rpido a informacin prctica del sistema.

3. Optimizar las operaciones mediante la rpida ejecucin de operaciones comunes, la consistencia de la interfaz y organizando y reorganizando la estructura de la informacin basndose en la observacin del uso del sistema. 4. Facilitar buenos mensajes de error, crear diseos que eviten los errores ms comunes, haciendo posible deshacer acciones realizadas y garantizar la integridad del sistema en caso de un fallo de software o hardware. A pesar de la obviedad y antigedad de estos principios es fcil encontrar en sitios web de comercio electrnico cdigos inmemorizables para identificar productos, mensajes de error ininteligibles y, en general, un maltrato constante al usuario.

UNIDAD IV: DISEO ORIENTADO A OBJETOS

DISEO ORIENTADO A OBJETO
Es una fase de la metodologa orientada a objetos para el desarrollo de Software. Su uso induce a los programadores a pensar en trminos de objetos, en vez de procedimientos, cuando planifican su cdigo. Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La 'interfaz del objeto', esto es, las formas de interactuar con el objeto, tambin es definida en esta etapa. Un programa orientado a objetos es descrito por la interaccin de esos objetos. El diseo orientado a objetos es la disciplina que define los objetos y sus interacciones para resolver un problema de negocio que fue identificado y documentado durante el anlisis orientado a objetos.

PATRONES DE DISEO
El diseo orientado a objetos es una etapa fundamental en el desarrollo de sistemas orientados a objetos, sin embargo, por lo general, en la prctica se observa que no se le dedica el tiempo suficiente o bien es efectuada de una manera muy superficial. Es comn observar una pequea etapa de anlisis de requisitos y un pasaje inmediato al proceso de programacin. Algunas veces para justificar esta superficialidad en cuanto a la manera de trabajar en la etapa de diseo, se atribuye a la falta de tiempo como causa principal. Sin embargo, sera ms que beneficioso aplicar las buenas prcticas en cuanto a desarrollo de software para lograr productos de calidad. Particularmente, durante la etapa de diseo se efectan decisiones relativas a qu mtodos se requerirn, dnde se los colocarn y cmo deberan interactuar los objetos, actividades nada triviales y muy importantes. Por tal motivo, sera altamente conveniente tener en cuenta algunos patrones de diseo fundamentales. En la tecnologa de objetos, un patrn es una descripcin del problema y la solucin, a la que se da un nombre, y que se puede aplicar a nuevos contextos; idealmente, proporciona consejos sobre el modo de aplicarlo en varias circunstancias, y considera los puntos fuertes y compromisos.[1] Unos de los patrones fundamentales es el GRASP (Patrones de Principios Generales para Asignar Responsabilidades). En esta entrada se describirn cinco:
1. Experto en informacin

2. 3. 4. 5.

Creador Alta cohesin Bajo acoplamiento Controlador

Experto en informacin

Problema Cul es un principio para asignar responsabilidades a los objetos? Solucin Asignar una responsabilidad al experto en informacin (la clase que tiene la informacin necesaria para realizar la responsabilidad) Si esta actividad se realiza bien, los sistemas tienden a ser ms fciles de entender, mantener y ampliar, y existen ms oportunidades para reutilizar componentes en futuras aplicaciones. El experto en informacin se utiliza con frecuencia en la asignacin de responsabilidades; es un principio de gua bsico que se utiliza continuamente en el diseo de objetos. El Experto no pretende ser una idea oscura o extravagante; expresa la intuicin comn de que los objetos hacen las cosas relacionadas con la informacin que tienen. Se debe notar que el cumplimiento de la responsabilidad a menudo requiere informacin que se encuentra dispersa por diferentes clases de objetos. Beneficios Se mantiene el encapsulamiento de la informacin, puesto que los objetos utilizan su propia informacin para llevar a cabo las tareas. Normalmente, esto conlleva un bajo acoplamiento, lo que da lugar a sistemas ms robustos y ms fciles de mantener. Se distribuye el comportamiento entre las clases que contienen la informacin requerida, por tanto, se estimula las definiciones de clases ms cohesivas y ligeras que son ms fciles de entender y mantener. Se soporta normalmente una alta cohesin.
Creador

Problema Quin debera ser el responsable de la creacin de una nueva instancia de alguna clase? Solucin Asignar a la clase B la responsabilidad de crear una instancia de la clase A si se cumple una o ms de los casos siguientes:

B agrega objetos de A B contiene objetos de A B registra instancias de objetos de A B utiliza ms estrechamente objetos de A B tiene los datos de inicializacin que se pasar a un objeto de A cuando sea creado (por tanto,

B es un Experto con respecto a la creacin de A) Si se asigna bien la responsabilidad de creacin, el diseo puede soportar un bajo acoplamiento, mayor claridad, encapsulacin y reutilizacin. Contraindicaciones

A menudo, la creacin requiere una complejidad significativa, como utilizar instancias recicladas por motivos de rendimiento, crear condicionalmente una instancia a partir de una familia de clases similares basadas en el valor de alguna propiedad externa, etc. En estos casos, es aconsejable delegar la creacin a una clase auxiliar denominada Factora.
Alta cohesin

Problema: Cmo mantener la complejidad manejable? Solucin: Asignar una responsabilidad de manera que la cohesin permanezca alta. La cohesin es una medida de la fuerza con la que se relacionan y del grado de focalizacin de las responsabilidades de un elemento. Un elemento con responsabilidades altamente relacionadas, y que no hace una gran cantidad de trabajo, tiene alta cohesin. Estos elementos pueden ser clases, subsistemas, etc. Una clase con baja cohesin hace muchas cosas no relacionadas, o hace demasiado trabajo. Tales clases no son convenientes, adolecen de los siguientes problemas:

Difciles de entender Difciles de reutilizar Difciles de mantener Delicadas, constantemente afectadas por los cambios.

Como regla emprica, una clase con alta cohesin tiene un nmero relativamente pequeo de mtodos, con funcionalidad altamente relacionada, y no realiza mucho trabajo. Colabora con otros objetos para compartir el esfuerzo si la tarea es extensa.
Bajo acoplamiento

Problema: Cmo soportar bajas dependencias, bajo impacto del cambio e incremento de la reutilizacin? Solucin: Asignar una responsabilidad de manera que el acoplamiento permanezca bajo. El acoplamiento es una medida de la fuerza con que un elemento est conectado a, tiene conocimiento de, confa en, otros elementos. Un elemento con bajo acoplamiento no depende de demasiados otros elementos. Una clase con alto acoplamiento confa en muchas otras clases. Tales clases podran no ser deseables; algunas adolecen de los siguientes problemas:

Los cambios en las clases relacionadas fuerzan cambios locales Son difciles de entender de manera aislada Son difciles de reutilizar puesto que su uso requiere la presencia adicional de las clases de las que depende.

En general, las clases que son inherentemente muy genricas por naturaleza, y con una probabilidad de reutilizacin alta, debera tener un acoplamiento especialmente bajo. El caso extremo de bajo acoplamiento es cuando no existe acoplamiento entre clases. Esto no es deseable porque una metfora central de la tecnologa de objetos es un sistema de objetos conectados que se comunican mediante el paso de mensajes. Si el bajo acoplamiento se lleva al extremo, producir un diseo pobre porque dar lugar a unos pocos objetos inconexos, saturados, y con actividad compleja que hacen todo el trabajo, con muchos objetos muy pasivos, sin acoplamiento que actan como simple repositorios de datos.
Controlador

Problema: Quin debe ser el responsable de gestionar un evento de entrada al sistema? Solucin: Asignar la responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase que representa una de las siguientes opciones:

Representa el sistema global, dispositivo o subsistema (controlador de fachada) Representa un escenario de caso de uso en el que tiene lugar el evento del sistema, a menudo denominado Manejador, Coordinador o Sesin (controlador de sesin o de caso de uso) Utilice la misma clase controlador para todos los eventos del sistema en el mismo escenario de caso de uso

Informalmente, una sesin es una instancia de una conversacin con un actor. Las sesiones pueden tener cualquier duracin, pero se organizan a menudo en funcin de los casos de uso (sesiones de caso de uso) Un controlador es un objeto que no pertenece a la interfaz de usuario, responsable de recibir o manejar un evento del sistema. Un controlador define el mtodo para la operacin del sistema. La primera categora de controlador es el controlador de fachada que representa al sistema global, dispositivo o subsistema. La idea es elegir algn nombre de clase que sugiera una cubierta, o fachada, sobre las otras capas de la aplicacin, y que proporciona la llamada a los servicios ms importantes de la capa de UI hacia las otras capas. Los controladores de fachada son adecuados cuando no existen demasiados eventos del sistema, o no es posible que la interfaz de usuario redirecciones mensajes de los eventos del sistema a controladores alternativos, como un sistema de procesamiento de mensajes. Si se elige un controlador de caso de uso, entonces hay un controlador diferente para cada caso de uso. Ntese que no es un objeto del dominio; es una construccin artificial para dar soporte al sistema. Un controlador de caso de uso es una alternativa a tener en cuenta cuando la asignacin de responsabilidades a un controlador de fachada nos conduce a diseos con baja cohesin o alto acoplamiento, generalmente cuando el controlador de fachada se est inflando con excesivas responsabilidades. El controlador recibe la solicitud del servicio desde la capa de UI y coordina su realizacin, normalmente delegando a otros objetos