FUNDAMENTOS DE DESARROLLO DE SOFTWARE (UNIDAD I - EL DISEÑO)

FUNDAMENTO DE DISEÑO DE SOFTWARE:

UNIDAD I: EL DISEÑO UNIDAD II: ARQUITECTURA DEL DISEÑO UNIDAD III: INTERFAZ DE USUARIO UNIDAD IV: DISEÑO ORIENTADO A OBJETOS

EL DISEÑO DE UN SOFTWARE

"Es el lugar en donde una persona se puede parar con un pie en dos mundos (el de la tecnología y el de la gente y los propósitos humanos) e intenta unirlos". El diseño pone un pie en el problema y otro en la solución, e intenta hacer casar un problema con otro y el resultado de esa actividad es el modelo de diseño, en cuyo modelo de diseño ya se empieza a hablar de elementos software que no se identifican con la realidad, sino que son parte de la solución al problema. En otras definiciones el diseño es citados por otros autores como:

“Proceso iterativo de tomar un modelo lógico de un sistema junto con un conjunto de objetivos fuertemente establecidos para este sistema y producir las especificaciones de un sistema físico 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 implementación. El modelo es volcado en una tecnología determinada”.

“...el proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, proceso o sistema con los suficientes detalles como para permitir su realización física.” (E. Taylor)

HITORIA DEL DISEÑO DE SOFWARE.

A partir de los años 50 se empezó a ver la efectividad de las máquinas para resolver los problemas diarios, Se empezó a informatizar los procesos que antes se hacían a mano. Hoy en día el software sirve para ese fin: resolver un problema automatizándolo. La evolución del diseño de software, como parte del proceso de desarrollo de software, es un proceso continuo que se ha ido produciendo durante décadas pasadas. Los primeros trabajos sobre diseño se centraron sobre los criterios para el desarrollo de programas modulares y los métodos para mejorar la arquitectura del software de una manera descendente. Los aspectos procedimentales de la definición del diseño evolucionaron hacia una filosofía denominada programación estructurada. Posteriores trabajos propusieron métodos para la traducción del flujo de datos o de la estructura de los datos.

La evolución del diseño de software dentro del contexto de las áreas de aplicación de los sistemas basados en computadoras, puede verse el grafico siguiente:

En los primeros años de desarrollo de las computadoras, el hardware sufrió continuos cambios, mientras que el software se contemplaba simplemente como un añadido. La programación de computadoras era un arte para el cual existían pocos métodos sistemáticos. El desarrollo de software se realizaba virtualmente sin ninguna planificación (hasta que los planes comenzaron a desfasarse y los costos a crecer). Durante este período se utilizaba en la mayoría de los sistemas una orientación por lotes.

Algunas excepciones fueron sistemas interactivos (Como es el caso de los sistemas de reservas de América Airlines) y sistemas de tiempo real para la defensa (SAGE). No obstante esto, la mayor parte del hardware se dedicaba a la ejecución de un único programa que, a su vez, se dedicaba a una aplicación específica.

Lo normal era que el hardware fuera de propósito general. Por otra parte, el software se diseñaba a medida para cada aplicación y tenía una distribución relativamente pequeña. La mayoría del software que se desarrollaba era utilizado por la misma persona u organización, es decir, La misma persona lo escribía, lo ejecutaba y si fallaba, lo depuraba. Debido a este entorno personalizado del software, el diseño era un proceso implícito, realizado en la mente de alguien, haciendo del diseño como tal una idea sin forma o sentido y la documentación normalmente no existía.

La segunda era, la evolución de los sistemas de computadoras se extiende desde la mitad de la década de los 60 hasta finales de los setenta. La multiprogramación y los sistemas multiusuarios introdujeron nuevos conceptos de interacción hombre máquina. Las técnicas interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de sofisticación del hardware y del software. Los sistemas de tiempo real podían recoger, analizar y transformar datos de múltiples fuentes, controlando así los procesos y produciendo salidas en milisegundos en lugar de en minutos. Los avances en los dispositivos de almacenamiento en línea condujeron a la primera generación de sistemas de gestión de bases de datos.

Ya en esta era se podía hacer referencia del software como producto y también de las llamadas “casas de software”.

Conforme crecía el número de sistemas, comenzaron a extenderse las bibliotecas de software de computadora. Se desarrollaban proyectos en los que se producían programas de decenas de miles de sentencias fuente. Todos esos programas (todas esas sentencias fuentes) tenían 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. Había comenzado una “crisis del software”.

La tercera era en la evolución de los sistemas de computadoras comenzó a mediado de los setenta y llega hasta el momento actual. El procesamiento distribuido (múltiples computadoras, cada una ejecutando funciones concurrentemente y comunicándose con alguna otra) incrementó notablemente la complejidad de los sistemas informáticos. Las redes de área local y de área global, las comunicaciones digitales de alto ancho de banda y la creciente demanda de acceso “instantáneo” a los datos, pusieron una fuerte presión 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 diseño de desarrollo de software.

Las computadoras personales han sido el catalizador del gran crecimiento de muchas compañías de software. Estas compañías venden decenas y centenares de copias de sus productos de software.

La cuarta era del software de computadora está comenzando ahora. Las tecnologías orientadas a objetos están comenzando a ser utilizadas en muchas áreas de aplicación. Las técnicas de cuarta generación para el desarrollo de software ya están cambiando la forma en que algunos segmentos de la comunidad informática construyen los programas. Los sistemas expertos y el software de inteligencia artificial se han trasladado del laboratorio a las aplicaciones prácticas. El software de redes neuronales artificiales ha abierto excitantes posibilidades para el reconocimiento de formas y habilidades de procesamiento de información al estilo de como lo hacen los humanos.

IMPORTANCIA DEL DISEÑO

En el diseño se busca la eficiencia, no solo la eficacia, es decir, desarrollar software que funcionen bien y además el diseño nos sirve para mantener la calidad. Aspectos funcionales: los aspectos funcionales se centran en la eficacia, que el código funcione. Aspectos no funcionales: son aspectos de calidad, se centran en la eficiencia, preocupándose 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, difícil de atacar/hackear.

Disponibilidad: que no se bloquee al ser accedido por muchos usuarios.

Mantenibilidad: que sea fácilmente ampliable. Las empresas están cambiando continuamente sus procesos de negocio, por eso el software tiene que ser fácil 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 lógico que antepongan los puntos de seguridad y rendimiento al de Mantenibilidad.

El diseño es la etapa en la que se tienen en cuenta esas necesidades del sistema que se está implementando y se van añadiendo una a una.

OBJETIVOS

El objetivo más importante es: Entregar las funciones requeridas por el usuario (Satisfaga una especificación funcional dada). Pero además para lograr esto deben considerarse los aspectos de: Rendimiento: cuán rápido permitirá el diseño 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: protección contra errores humanos, máquinas defectuosas, o daños intencionales.

Cambiabilidad: facilidad con la cual el diseño permite modificar el sistema. Generalmente estos tres factores trabajan unos contra otros : un sistema con muchos controles tenderá a degradar su rendimiento, un sistema diseñado para un alto rendimiento solo podrá ser cambiado con dificultad, etc...

Además deberá satisfacer criterios de diseño sobre la forma interna y externa del producto obtenido.

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

MODELO O METODOS PARA LA ACTIVIDAD DE DISEÑO

En el modelo de diseño vamos a destacar 5 mapas o planos, que se suelen seguir por orden: Diseño de datos: Aquí se guardarán los datos de la aplicación (P. ej.- información de clientes, pedidos, etc.) en clases, relaciones, atributos, etc. Respecto al modelo de análisis podemos decir que en el diseño de datos hablamos de tipos de datos concretos, ficheros de configuración, etc. La mayoría de las veces esto se traduce como la base de datos a usar. Diseño de la arquitectura: se hace una pequeña descomposición del sistema, dividiéndolo en bloques y estableciendo sus relaciones.

Diseño de interfaz: existen tres tipos de interfaces que se pueden diseñar: Interfaz de usuario

Interfaz de conexión con sistemas externos

Interfaz entre los bloques

Diseño de la microarquitectura: consiste en coger un bloque y mirar por dentro, es decir, nos centramos en un subsistema y vemos cómo están implementadas las clases, los atributos, etc.

Diseño del despliegue: se refiere a la parte de la instalación. Se ve sobre qué maquinas va a funcionar el sistema, se especifica sistema operativo necesario, servidor de aplicaciones, plataforma, etc.

El diseño es un proceso interactivo, las fases del proceso de diseño se suelen ejecutar de forma lineal, pero cíclicamente. Cuando se está en una fase, suelen aparecer nuevos problemas que nos hacen volver atrás en el modelo (P. ej.- nos damos cuenta en la fase de diseño de la microarquitectura que el módulo en el que hemos dividido es muy grande, con lo que hay que volver a dividir y crear nuevas interfaces, etc.).

MODELO DE ANÁLISIS VS. MODELO DE DISEÑO

Aunque en ambos modelos se usan las mismas herramientas (UML), son dos cosas muy diferentes: en el modelo de análisis las clases representan a los elementos de la realidad que forman parte del problema, mientras que en el modelo de diseño, ya se empieza a hablar de elementos software que no se identifican con la realidad, sino que son parte de la solución al problema (P. ej.- el Sr. Empleado para análisis y la clase empleado.java para diseño).

PRINCIPIOS DE DISEÑO

Los principios de diseño son aplicables a todos los niveles del diseño del software, desde la arquitectura a la microarquitectura, además todos estos principios se relacionan entre sí.

Los principios de diseño son los siguientes:

ABSTRACCIÓN Y REFINAMIENTO: se trata de ocultar los detalles, es decir no centrarse en detalles concretos del diseño, sino hacer un esquema visual a alto nivel. De esta manera tenemos una visión general de todo, también se utiliza en los microdiseños. La táctica del refinamiento es justamente lo contrario, es decir, centrarse en los detalles del modelo abstracto dado anteriormente.

La técnica de abstracción y refinamiento se complementa con la de refinamiento, es decir, primero se hace una abstracción del problema y una vez que tenemos un esquema abstracto usamos la técnica del refinamiento para centrarnos en detalles concretos.

MODULARIDAD: se basa en el principio de "Divide y Vencerás", que consiste un dividir el problema en varios problemas más pequeños para que el coste de resolverlos sea menor. Consiste en dividir un sistema en varios subsistemas, cada uno de estos resuelve un problema pequeñito y luego se vuelven a unir. Esta técnica se puede aplicar a distintas escalas. Esto nos plantea una pregunta: ¿Cómo lo divido? Pues no hay una forma exacta para hacer la división sino que depende de cada problema en particular.

En la gráfica podemos observar el coste de dividir en módulos frente al coste de unir esos módulos. Si dividimos en muchos módulos el coste disminuye, pero aumenta la integración de los módulos. Hay que buscar la justa medida que está comprendida en la región de costes mínimos.

VARIACIONES PROTEGIDAS: hay que tener claros dos conceptos: punto de variación y punto de evolución.

*Punto de variación: es un requisito del sistema que tiene características variables y puede cambiar, por tanto tengo que soportarlo en mi aplicación.

*Punto de evolución: es cuando nosotros prevemos que se puede convertir en un punto de variación.

En el desarrollo del software todo lo que sea cambios es un problema, hay que prestar atención a estos puntos que cambian, la idea es proteger al sistema de los cambios en los puntos de variación y en los puntos de evolución.

Cuando detecte un punto de variación y/o punto de evolución tengo que diseñarlo de forma que los cambios que se produzcan en el sistema afectan a lo mínimo posible.

David Parnas (1972) dijo: "...proponemos en lugar de eso (dividir en módulos) que uno comience con una lista de decisiones de diseño difíciles o con altas probabilidades de cambio. Cada módulo se diseña entonces para ocultar dichas decisiones a otros (módulos)..." Para hacer estos se puede usar alguno de los siguientes métodos:

-Encapsulación: por ejemplo lo que hacen las clases en Java, ocultan los atributos y solo muestran los métodos.

-Interfaces: por ejemplo lo que es una interfaz en Java, una misma interfaz puede tener distintas implementaciones.

-Datos externos: tener datos de configuración fuera del sistema (ficheros de configuración...).

-Ocultación de la estructura: un sistema no tiene necesidad de conocer los otros subsistemas, para ello están los interfaces internas.

¡CUIDADO! El coste de diseñar la protección de un punto de variación o de evolución es superior que resolver un diseño simple. No hay que usar la sobre ingeniería.

ACOPLAMIENTO: medida cualitativa del grado en el que un módulo está conectado a otros y el mundo exterior. El acoplamiento hay que mantenerlos bajo para que cada módulo sea lo más independiente posible. De esta forma si un módulo 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 controlándolo a medida que se diseña hay que estar evaluando el grado de acoplamiento para conseguir que sea lo más bajo posible Hay que ser cautelar, es decir, no hay que intentar disminuir el acoplamiento a toda costa, sino que hay que evaluar cómo hacerlo.

COHESIÓN: es la medida cualitativa del grado en el que un módulo se enfoca a una sola cosa. Un módulo hace cosas muy parecidas, la cohesión debe ser alta en cada módulo, se trata de conseguir módulos muy cohesivos y que estén poco acoplados. Para mejorar la cohesión lo mejor es dividir en subsistemas. Las clases con muchos métodos son poco cohesivas y habrá que dividir. La cohesión al igual que el acoplamiento es evolutiva, hay que ir evaluando a la vez que se diseña para aumentar la cohesión.

"Un elemento es altamente cohesivo si todos sus elementos trabajar juntos para proporcionar algún comportamiento bien determinado"

A la cohesión y al acoplamiento se les denomina el Ying y el Yang del diseño software.

REFACTORIZACIÓN: según Martin Fowler (1999) "Es el proceso de cambiar un sistema de software de tal forma que no se altere el comportamiento externo de su código (diseño) y aun así se mejora su estructura interna".

La funcionalidad sigue siendo la misma pero mejora la estructura interna del código, es decir, mejorando la cohesión y disminuyendo el acoplamiento, pero siempre hay que tener en cuenta que la funcionalidad no puede cambiar.

En lugar de aplicar la evaluación de la cohesión y el acoplamiento al principio, lo hago cuando ya tengo un poco de código hecho. Existen catálogos de refactorización que nos puede ayudar a llevar a cabo una refactorización.

REUTILIZACIÓN: no hay que reinventar la rueda, consiste en utilizar código 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.

DISEÑO DE ATRIBUTOS DE CALIDAD

La Calidad del software, es el desarrollo de software basado en estándares con la funcionalidad y rendimiento total que satisfacen los requerimientos del cliente. El proceso de desarrollo, gestión de proyectos, análisis y diseño, especificación de requerimientos, arquitectura, son solo algunos de los componentes que se aglomeran para conformar la ingeniería de software (IS) como disciplina para la creación y mantenimiento de software. Dentro de ésta, existe un subconjunto de teorías, herramientas y métodos 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 métricas para el desarrollo de software. Extrañamente dentro de la IS, la calidad del software es muy complicada de definir y de enmarcar en un simple concepto teórico, por lo que en esta nota, me concentraré solo en las diversas características que permiten describirla y en los elementos que importan específicamente al diseñador de software.

Una idea general sobre un software de calidad es aquel que debiera cumplir con los requerimientos funcionales y de performance además de ser mantenible, confiable y aceptable. Dentro de sus principales características tenemos:

FUNCIONABILIDAD: es la capacidad que tendrá el producto de satisfacer los requisitos funcionales prescriptos y las necesidades implícitas de los usuarios.

CONFIABILIDAD: El grado que se puede esperar de una aplicación lleve a cabo las operaciones especificadas y con la precisión requerida incluye varias características 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 específicas de uso.

EFICIENCIA: cuyo Conjunto de características determinan la relación entre el nivel de rendimiento del software y el número de recursos usados, bajo ciertas condiciones dadas. Se divide en las subcaracteríticas:

Comportamiento temporal: que indica las características del software que influyen en el tiempo de respuesta y procesado y productividad cuando se ejecuta su función.

Utilización de recursos: que indica las características del software que influyen en el número de recursos usados, y la duración de su uso, cuando se lleva a cabo su función.

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 modificación o borrado de un defecto

Estabilidad: que indica volumen de riesgos de efectos inesperados tras una modificación.

Facilidad de prueba: que indica la capacidad del software para permitir que sea validado tras ser modificado.

TRANSPORTABILIDAD: El esfuerzo requerido para transferir la aplicación a otro hardware o sistema operativo.

*COMPONENTES, SERVICIOS Y BIBLIOTECAS: tienen una funcionalidad empaquetada y diseñada para ser reutilizada, el manejo de periféricos, gráficos, gestión de documentos XML tienen funcionalidad lista para ser utilizada a través de una interfaz bien definida. Tienes una interfaz bajo/local en el diseño de la aplicación cliente. Una cuestión clave en el diseño de estos elementos reside en conseguir facilidad de uso para el máximo número de escenas sin complicar la interfaz ni reducir el rendimiento.

FRAMEWORKS: conjunto de clases parcialmente funcional (no es una aplicación) para un dominio de aplicación, es algo cuya funcionalidad no está definida, un Frameworks no tiene un ejecutable, le falta algo de la aplicación, por ejemplo. Junit es un frameworks. Los frameworks tienen una gran influencia en el diseño de la aplicación 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: reutilización de diseño y código, hay que tener en cuenta la experiencia del diseñador del framework, se reducen los costes de producción porque ya está hecho. -Inconvenientes: encontrar el frameworks apropiado para nuestro caso, usar más de un frameworks al mismo tiempo (temas de incompatibilidad entre los frameworks usados), son difíciles de construir y de aprender a usar.

*IDIOMAS: una forma de utilizar un Lenguaje de Programación, patrón de bajo nivel, es especifico de un Lenguaje de Programación. Describen soluciones a problemas de implementación de un determinado Lenguaje de Programación por ejemplo la gestión de memorias en C++.

*ANTIPATRONES: se aprende de los errores más que de los aciertos, nos dan recetas de cosas que no hay que hacer.

*PATRONES DE DISEÑO: "Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno. También describe el núcleo de la solución al problema, de forma que puede utilizar un millón de veces sin hacer dos veces lo mismo".

*PATRONES ARQUITECTÓNICOS: 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 DISEÑO:

Con los modelos que se disponen de las tareas y de la arquitectura del sistema, deberemos guiar el diseño para obtener una implementación correcta. Este proceso en algunos casos puede ser automático, pero en la mayoría de los casos, requerirá de un profundo reconocimiento de los aspectos más delicados del proceso de diseño y que está directamente relacionado con el diálogo con la máquina y la presentación de la información. Nos centraremos en los mecanismos básicos de interacción y el diálogo con la aplicación y la capa de presentación.

DISEÑO 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 representación gráfica y en la que existe una gran vinculación (mediante herencia) de unos componentes con otros.

Una estructura típica del modelo conceptual es un conjunto de objetos capaces de realizar una serie de acciones (modelo objeto–acción).

• Objetos: Un objeto es un elemento de información sobre el que el usuario tiene algún control. El conjunto de objetos posee usualmente alguna estructura. Dicho conjunto es una visión abstracta de la información gestionada por el sistema (modelo).

• Acciones: Una acción es una operación 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 serán las tareas que debe realizar el usuario para manipular los objetos del dominio de la aplicación.

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 posición de encendido, la bombilla se ilumina.

Podemos identificar dos tipos de objetos: a) aquellos que aparecen en la comunicación entre el usuario y el sistema y que típicamente pertenecen a la interfaz (objetos de control), y b) los que son propios de la aplicación (objetos intrínsecos). Por ejemplo, una barra de iconos, una regla o una ventana son objetos intrínsecos 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 aplicación (insertar, modificar, ver DNI, etc.). Para la descripción de los objetos y de las acciones podemos usar metáforas que ayuden a comprender su significado y utilización (ver capítulo ‘Metáforas, estilos y paradigmas’).

Para la especificación del sistema deberemos identificar tanto a los objetos como a sus acciones asociadas. Los objetos se describen identificando sus atributos más relevantes. Uno de los más importantes es su representación gráfica. Para describir las acciones se puede utilizar una notación de diálogo basada en diagramas de estado y lenguaje de órdenes (secuencia). El lenguaje de órdenes nos daría información necesaria acerca del protocolo (qué acción se realiza), mientras que el diagrama de estado indicaría cómo cambia el estado de los objetos con las modificaciones (cómo implementarlo).

ESTRATEGIAS DE DISEÑO ORIENTADO A ESTRUCTURA DE DATOS

El dominio de la información para un problema de software comprende el flujo de datos, el contenido de datos y la estructura de datos. Los métodos de análisis orientados a la estructura de datos representan los requerimientos del software enfocándose hacia la estructura de datos en vez de al flujo

de datos. Aunque cada método orientado a la estructura de datos tiene un enfoque y notación distinta, todos tienen algunas características en común:

1) todos asisten al analista en la identificación de los objetos de información clave (también llamados entidades o ítems) y operaciones (también llamadas acciones o procesos).

2) todos suponen que la estructura de la información es jerárquica.

3) todos requiere que la estructura de datos se represente usando la secuencia, selección y repetición.

4) todos dan un conjunto de pasos para transformar una estructura de datos jerárquica en una estructura de programa.

Como los métodos orientados al flujo de datos, los métodos de análisis orientados a la estructura de datos proporcionan la base para el diseño de software. Siempre puede extenderse un método de análisis para que abarque el diseño arquitectural y procedimental del software.

Patrón de Diseño

Un patrón de diseño provee un esquema para refinar los subsistemas o componentes de un sistema de software, o las relaciones entre ellos. Describe la estructura comúnmente recurrente de los componentes en comunicación, que resuelve un problema general de diseño en un contexto particular (Buschman et al., 1996). Son menores en escala que los patrones arquitectónicos, y tienden a ser independientes de los lenguajes y paradigmas de programación. Su aplicación 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 implementación, el comportamiento de los componentes del subsistema.

UNIDAD II: ARQUITECTURA DEL DISEÑO

ARQUITECTURA DEL DISEÑO

El diseño arquitectónico representa la estructura de los datos y los componentes del programa que se requieren para construir un sistema de computadora constituye el estilo arquitectónico que tendrá el sistema, las estructuras de datos y las propiedades de los componentes y la interrelación que tiene con otros componentes arquitectónicos 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 solución para un problema determinado. En la medida que los sistemas de software crecen en complejidad, bien sea por número 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 técnica es descomponer el sistema en piezas que agrupan aspectos específicos del mismo, producto de un proceso de abstracción (Bass et al., 1998) y que al organizarse de cierta manera constituyen la base de la solución de un problema en particular.

Una arquitectura de software define la estructura del sistema. Esta estructura se constituye de componentes -módulos o piezas de código que nacen de la noción de abstracción, cumpliendo funciones específicas, e interactuando entre sí con un comportamiento definido

Los componentes se organizan de acuerdo a ciertos criterios, que representan decisiones de diseño. En este sentido, hay autores que plantean que la arquitectura de software incluye justificaciones referentes a la organización y el tipo de componentes, garantizando que la configuración resultante satisface los requerimientos del sistema.

De esta manera, la arquitectura de software puede ser vista como la estructura del sistema en función de la definición de los componentes y sus interacciones. La práctica 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, dándole un sentido más amplio a la definición del término.

La arquitectura de software puede considerarse entonces como el “puente” entre los requerimientos del sistema y la implementación. Las actividades que culminan en la definición de la arquitectura pueden ubicarse en las fases tempranas del ciclo de desarrollo del sistema: luego del análisis de los requerimientos y el análisis de riesgos, y justo antes del diseño detallado. Desde esta perspectiva, la arquitectura constituye un artefacto de la actividad de diseño, que servirá de medio de comunicación entre los miembros del equipo de desarrollo, los clientes y usuarios finales, dado que contempla los aspectos que interesan a cada uno. Además, pasa a ser la base del diseño del sistema a desarrollar, razón por la cual en la literatura la arquitectura es considerada como plan de diseño del sistema, debido a que es usada como guía para el resto de las tareas del desarrollo.

De igual manera, serán 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 más importantes se encuentran: modificabilidad, eficiencia, mantenibilidad, interoperabilidad, confiabilidad, reusabilidad y facilidad de ejecución de prueba.

Proponen que el término “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 alusión a la especificación de la estructura del sistema, entendida como la organización 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 diseño que gobiernan esta estructura y los argumentos que justifican las decisiones tomadas.

Habiendo aclarado el alcance que puede tomar el término arquitectura de software, resulta de gran interés introducir formalmente otros términos 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 construcción que conforman las partes de un sistema de software. A nivel de lenguajes de programación, pueden ser representados como módulos, clases, objetos o un conjunto de funciones relacionadas

Se distinguen tres tipos de componentes, denominados también elementos, que son:

1. Elementos de Datos: contienen la información que será transformada. 2. Elementos de Proceso: transforman los elementos de datos. 3. Elementos de Conexión: llamados también conectores, que bien pueden ser elementos de datos o

de proceso, y mantienen unidas las diferentes piezas de la arquitectura.

Una relación es la conexión entre los componentes. Puede definirse también como una abstracción de la forma en que los componentes interactúan en el sistema a través de los elementos de conexión. Es importante distinguir que una relación 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 descripción. Esta particularidad propone la importancia de la representación de una arquitectura.

Además 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, características de desempeño, manejo de fallas, uso de recursos compartidos, etc. En relación a los componentes definidos por la arquitectura de un sistema de software, se tiene la información referente a las interacciones, que son propias de la arquitectura, y que permiten, a nivel de diseño, tomar las decisiones necesarias durante la construcción de un sistema de software.

PATRÓN ARQUITECTÓNICO

El patrón arquitectónico es una regla que consta de tres partes, la cual expresa una relación entre un contexto, un problema y una solución.

En líneas generales, un patrón sigue el siguiente esquema:

1. Contexto. Es una situación de diseño en la que aparece un problema de diseño 2. Problema. Es un conjunto de fuerzas que aparecen repetidamente en el contexto 3. Solución. Es una configuración que equilibra estas fuerzas.

Ésta última abarca:

Estructura con componentes y relaciones Comportamiento a tiempo de ejecución: aspectos dinámicos de la solución, como la colaboración

entre componentes, la comunicación entre ellos, etc.

Partiendo de esta definición, propone los patrones arquitectónicos como descripción de un problema particular y recurrente de diseño, que aparece en contextos de diseño específico, y presenta un esquema genérico demostrado con éxito para su solución. El esquema de solución se especifica mediante la descripción de los componentes que la constituyen, sus responsabilidades y desarrollos, así como también la forma como estos colaboran entre sí.

Los patrones arquitectónicos expresan el esquema de organización estructural fundamental para sistemas de software. Provee un conjunto de subsistemas predefinidos, especifica sus responsabilidades e incluye reglas y pautas para la organización de las relaciones entre ellos. Propone que son plantillas para arquitecturas de software concretas, que especifican las propiedades estructurales de una aplicación - con amplitud de todo el sistema - y tienen un impacto en la arquitectura de subsistemas. La selección de un patrón arquitectónico es, por lo tanto, una decisión fundamental de diseño en el desarrollo de un sistema de software.

La colección de patrones arquitectónicos debe ser estudiada en términos de factores de calidad e intereses, en anticipación a su uso. Esto quiere decir que un patrón puede ser analizado previamente, con la intención de seleccionar el que mejor se adapte a los requerimientos de calidad que debe cumplir el sistema. Debe estudiarse la composición de los patrones, dado que ésta puede dificultar aspectos como el análisis, o poner en conflicto otros atributos de calidad.

La tabla 10 presenta algunos patrones arquitectónicos, además de los atributos que propician y los atributos en conflicto.

NOTACIONES DE LA ARQUITECTURA DE DISEÑO

Unified Modeling Language (UML) ha conseguido un rol importante en el proceso de desarrollo de software en la actualidad. La unificación del método de diseño y las notaciones, ha ampliado, entre otras cosas, el mercado de herramientas CASE que soportan el proceso de diseño de arquitecturas de software. UML ofrece soporte para clases, clases abstractas, relaciones, comportamiento por interacción, 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 colaboración, de estados, de actividades, de componentes y de desarrollo.

CARACTERÍSTICAS GENERALES DE UML E IMPORTANCIA DE SU APLICACIÓN.

UML existe soporte para algunos de los conceptos asociados a las arquitecturas de software, como los componentes, los paquetes, las librerías y la colaboración. UML permite la descripción de componentes en la arquitectura de software en dos niveles; se puede especificar sólo el nombre del componente o especificar las clases o interfaces que implementan estos. De igual forma, UML provee una notación para la descripción de la proyección de los componentes de software en el hardware. Esto corresponde a la vista física del modelo 4+1. La proyección 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 búsqueda de la mejor solución para un sistema específico. Esta notación 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 colaboración entre componentes se puede representar mediante conjuntos de clases, interfaces y otros elementos que interactúan entre sí para proveer servicios que van más allá de la funcionalidad de cada uno de ellos por separado. La colaboración posee un aspecto estructural, esto es, el diagrama de clases de los elementos involucrados en la interacción y un diagrama de comportamiento. UML también permite que las colaboraciones posean relaciones entre sí. Por último, los patrones y frameworks están también soportados por UML, mediante el uso combinado de paquetes, componentes y colaboraciones, entre otros.

El modelo de Rausch (2001) plantea la inclusión de los componentes básicos 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 categorías del comportamiento del sistema: comportamiento estructural, que captura los cambios del sistema, incluyendo la creación y destrucción de instancias; evaluaciones de variables, que representan el espacio de variables globales y locales; y la comunicación de los componentes, que describe la interacción entre estos.

Algunos autores proponen que es posible hacer la descripción de los elementos básicos de la arquitectura mediante el uso de UML, e indica que la especificación de la estructura del sistema no es suficiente para obtener un modelo completo del mismo. Por esto, para la descripción del comportamiento de los componentes de la arquitectura, propone el uso de OCL. Según su estudio, este lenguaje ofrece facilidades que no provee UML, por lo que considera que el uso de ambos es una posible solución para solventar los problemas de descripción de las arquitecturas de software.

En virtud de la importancia de la descripción de la arquitectura de software, se plantea que los lenguajes de descripción arquitectónica como elementos que, aunque presentan algunas desventajas, merecen atención, puesto que pueden considerarse como una solución alternativa al problema planteado.

EVALUACIÓN DE ARQUITECTURAS DE SOFTWARE

El primer paso para la evaluación de una arquitectura es conocer qué es lo que se quiere evaluar. De esta forma, es posible establecer la base para la evaluación, puesto que la intención es saber qué se puede evaluar y qué no. Resulta interesante el estudio de la evaluación 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 arquitectónico 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:

Comparación de alternativas similares Comparación de la arquitectura original y la modificada Comparación de la arquitectura de software con respecto a los requerimientos del sistema Comparación de una arquitectura de software con una propuesta teórica Valoración de una arquitectura en base a escalas específicas

Mediante la arquitectura de software, es posible también determinar la estructura del proyecto de desarrollo del sistema, sobre elementos como el control de configuración, calendarios, control de recursos, metas de desempeño, estructura del equipo de desarrollo y otras actividades que se realizan con la arquitectura del sistema como apoyo principal. En este sentido, la garantía de una arquitectura correcta cumple un papel fundamental en el éxito general del proceso de desarrollo, además del cumplimiento de los atributos de calidad del sistema.

De esta manera, el interés se centra en determinar el momento propicio para efectuar la evaluación de una arquitectura. En este sentido, amplían el panorama clásico, indicando las ocasiones en que se hace posible hacer la evaluación 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 evaluación, y esto abarca desde las fases tempranas de diseño 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 arquitectónicos, producto de una evaluación en función de los atributos de calidad esperados. Ahora bien, se establece que mientras mayor es el nivel de especificación, mejores son los resultados que produce la evaluación.

La segunda variante consiste en realizar la evaluación de la arquitectura cuando ésta se encuentra establecida y la implementación se ha completado. Este es el caso general que se presenta al momento de la adquisición de un sistema ya desarrollado. Los autores consideran muy útil la evaluación del sistema en este punto, puesto que puede observarse el cumplimiento de los atributos de calidad asociados al sistema, y cómo será su comportamiento general.

También otros autores afirman que la evaluación 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 diseños arquitectónicos. Por ello, la intención es más bien la evaluación del potencial de la arquitectura diseñada para alcanzar los atributos de calidad requeridos. Las mediciones que se realizan sobre una arquitectura de software pueden tener distintos objetivos, dependiendo de la situación en la que se encuentre el arquitecto y la aplicabilidad de las técnicas que emplea.

Los objetivos que menciona son tres:

1. cualitativos. 2. cuantitativos. 3. máximos y mínimos teóricos.

La medición cualitativa se aplica para la comparación entre arquitecturas candidatas y tiene relación con la intención de saber la opción que se adapta mejor a cierto atributo de calidad. Este tipo de medición brinda respuestas afirmativas o negativas, sin mayor nivel de detalle.

La medición cuantitativa busca la obtención de valores que permitan tomar decisiones en cuanto a los atributos de calidad de una arquitectura de software. El esquema general es la comparación con márgenes establecidos, como lo es el caso de los requerimientos de desempeño, 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 teóricos máximos y mínimos de las mediciones con las que se realiza la comparación. Por último, la medición de máximo y mínimo teórico contempla los valores teóricos para efectos de la comparación de la medición con los atributos de calidad especificados. El conocimiento de los valores máximos o mínimos permite el establecimiento claro del grado de cumplimiento de los atributos de calidad.

En líneas generales, el planteamiento anterior presenta los objetivos para efectos de la medición de los atributos de calidad. Sin embargo, en ocasiones, la evaluación de una arquitectura de software no produce valores numéricos que permiten la toma de decisiones de manera directa.

Ante la posibilidad de efectuar evaluaciones a cualquier nivel del proceso de diseño, con distintos niveles de especificación, se propone un esquema general en relación a la evaluación de una arquitectura con respecto a sus atributos de calidad. En este sentido se afirman que de la evaluación de una arquitectura no se obtienen respuestas del tipo “si - no”, “bueno – malo” o “6.75 de 10”, sino que explica cuáles son los puntos de riesgo del diseño evaluado.

TÉCNICAS DE EVALUACIÓN DE ARQUITECTURAS DE SOFTWARE

Las técnicas utilizadas para la evaluación de atributos de calidad requieren grandes esfuerzos por parte del ingeniero de software para crear especificaciones y predicciones. Estas técnicas requieren información del sistema a desarrollar que no está disponible durante el diseño arquitectónico, sino al principio del diseño detallado del sistema.

En vista de que el interés es tomar decisiones de tipo arquitectónico en las fases tempranas del desarrollo, son necesarias técnicas que requieran poca información detallada y puedan conducir a

resultados relativamente precisos. Las técnicas existentes en la actualidad para evaluar arquitecturas permiten hacer una evaluación cuantitativa sobre los atributos de calidad a nivel arquitectónico, pero se tienen pocos medios para predecir el máximo (o mínimo) teórico para las arquitecturas de software. Sin embargo, debido al costo de realizar este tipo de evaluación, en muchos casos los arquitectos de software evalúan cualitativamente, para decidir entre las alternativas de diseño.

Existen diferentes técnicas de evaluación entre las cuales se pueden mencionar:

Evaluación basada en escenarios

un escenario es una breve descripción de la interacción de alguno de los involucrados en el desarrollo del sistema con éste. Por ejemplo, un usuario hará la descripción en términos de la ejecución 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 construcción o predicción de su desempeño.

Un escenario consta de tres partes:

el estímulo. el contexto. la respuesta.

El estímulo es la parte del escenario que explica o describe lo que el involucrado en el desarrollo hace para iniciar la interacción con el sistema. Puede incluir ejecución de tareas, cambios en el sistema, ejecución de pruebas, configuración, etc.

El contexto describe qué sucede en el sistema al momento del estímulo.

La respuesta describe, a través de la arquitectura, cómo debería responder el sistema ante el estímulo. Este último elemento es el que permite establecer cuál es el atributo de calidad asociado.

Los escenarios proveen un vehículo que permite concretar y entender atributos de calidad.

Entre las ventajas de su uso están:

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

Evaluación basada en simulación

La evaluación basada en simulación utiliza una implementación de alto nivel de la arquitectura de software. El enfoque básico consiste en la implementación de componentes de la arquitectura y la implementación

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 evaluación basada en simulación sigue los siguientes pasos:

Definición e implementación del contexto. Consiste en identificar las interfaces de la arquitectura de software con su contexto, y decidir cómo será simulado el comportamiento del contexto en tales interfaces.

Implementación de los componentes arquitectónicos. La descripción del diseño arquitectónico debe definir, por lo menos, las interfaces y las conexiones de los componentes, por lo que estas partes pueden ser tomadas directamente de la descripción de diseño. El comportamiento de los componentes en respuesta a eventos sobre sus interfaces puede no ser especificado claramente, aunque generalmente existe un conocimiento común y es necesario que el arquitecto lo interprete, por lo que éste decide el nivel de detalle de la implementación.

Implementación del perfil. Dependiendo del atributo de calidad que el arquitecto de software intenta evaluar usando simulación, el perfil asociado necesitará ser implementado en el sistema. El arquitecto de software debe ser capaz de activar escenarios individuales, así como también ejecutar un perfil completo usando selección aleatoria, basado en los pesos normalizados de los mismos.

Simulación del sistema e inicio del perfil. El arquitecto de software ejecutará la simulación y activará escenarios de forma manual o automática, y obtendrá resultados de acuerdo al atributo de calidad que está siendo evaluado.

Predicción de atributos de calidad. Dependiendo del tipo de simulación 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 técnica de implementación de prototipos (prototyping). Esta técnica 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 desempeño y confiabilidad. Para su uso se necesita mayor información sobre el desarrollo y disponibilidad del hardware, y otras partes que constituyen el contexto del sistema de software. Se obtiene un resultado de evaluación con mayor exactitud.

La exactitud de los resultados de la evaluación depende, a su vez, de la exactitud del perfil utilizado para evaluar el atributo de calidad y de la precisión con la que el contexto del sistema simula las condiciones del mundo real.

En términos de los instrumentos asociados a las técnicas de evaluación basadas en simulación, se encuentran los lenguajes de descripción arquitectónica, descritos en la sección 7, y los modelos de colas.

Evaluación basada en modelos matemáticos

La evaluación basada en modelos matemáticos se utiliza para evaluar atributos de calidad operacionales. Permite una evaluación estática de los modelos de diseño arquitectónico, y se presentan como alternativa a la simulación, dado que evalúan el mismo tipo de atributos. Ambos enfoques pueden ser combinados, utilizando los resultados de uno como entrada para el otro.

El proceso de evaluación basada en modelos matemáticos sigue los siguientes pasos:

Selección y adaptación del modelo matemático. La mayoría de los centros de investigación orientados a atributos de calidad han desarrollado modelos matemáticos para medir sus atributos de calidad, los cuales tienden a ser muy elaborados y detallados, así como también requieren de cierto tipo de datos y análisis. Parte de estos datos requeridos no están disponibles a nivel de arquitectura, y la técnica requiere

mucho esfuerzo para la evaluación arquitectónica, por lo que el arquitecto de software se ve obligado a adaptar el modelo.

Representación de la arquitectura en términos del modelo. El modelo matemático 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 términos del modelo.

Estimación de los datos de entrada requeridos. El modelo matemático aún cuando ha sido adaptado, requiere datos de entrada que no están incluidos en la definición básica de la arquitectura. Es necesario estimar y deducir estos datos de la especificación de requerimientos y de la arquitectura diseñada.

Evaluación basada en experiencia

En muchas ocasiones los arquitectos e ingenieros de software otorgan valiosas ideas que resultan de utilidad para la evasión de decisiones erradas de diseño. Aunque todas estas experiencias se basan en evidencia anecdótica; es decir, basada en factores subjetivos como la intuición y la experiencia. Sin embargo, la mayoría de ellas puede ser justificada por una línea lógica de razonamiento, y pueden ser la base de otros enfoques de evaluación.

Existen dos tipos de evaluación basada en experiencia: la evaluación informal, que es realizada por los arquitectos de software durante el proceso de diseño, y la realizada por equipos externos de evaluación de arquitecturas.

HERRAMIENTAS DE ANÁLISIS, DISEÑO Y EVALUACIÓN DE ARQUITECTURAS DE SOFTWARE

Una herramienta de análisis y diseño 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 especificación gráfica de arquitecturas, de forma similar a como se lleva a cabo en un equipo de desarrollo. Los esbozos gráficos de la arquitectura se realizan para facilitar el diseño, la exploración y la comunicación. 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, más que el uso de un grupo preestablecido por la herramienta.

Debe ser capaz de añadir elementos arquitectónicos de forma recursiva, y poder establecer asociaciones semánticamente significativas con elementos en otros niveles de abstracción. El cumplimiento de este requerimiento es crucial para soportar el refinamiento iterativo y el análisis de arquitecturas, donde el análisis es significativo a cualquier nivel de refinamiento. Por ejemplo, debería permitir esbozar un nodo en la arquitectura bajo el nombre “base de datos”, y permitir preguntas importantes de diseño, o ejecutar análisis de desempeño, sin la necesidad de mayor descomposición del elemento definido. Con el cumplimiento de este requerimiento, la herramienta debería permitir el diseño y análisis arquitectónico en cualquier grado de resolución. Por supuesto, a mayor grado de resolución, 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á diseñando, como con sistemas externos. De igual forma, debe estar en capacidad de determinar la correspondencia de la arquitectura implementada con la arquitectura diseñada.

Debe contar con la capacidad de realizar ingeniería de reverso.

Debe ser capaz de analizar arquitecturas con respecto a métricas.

Debe asistir al desarrollador en el diseño, tanto como una actividad creativa, como una actividad de análisis. En específico, se propone que debe soportar distintos métodos de diseño, y los procesos que estos métodos implican.

Debe funcionar como un repositorio que contenga diseños, trozos de diseño, justificaciones de diseño y escenarios. Como repositorio, debe permitir la búsqueda de una arquitectura, la extracción de subconjuntos significativos de ésta, y también permitir su actualización.

Debe proveer la generación de plantillas de código, para simplificar la transición del diseño al código, contribuyendo así con la consistencia entre ambos. De igual forma, debe proveer herramientas de modelaje de control de datos y flujo, así como también modelaje de desempeño.

El planteamiento de no contempla aspectos de evaluación de las arquitecturas de software diseñadas 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 interés extender el alcance de tal herramienta, agregando la capacidad de evaluación del diseño generado.

La intención es entonces resaltar algunos de los elementos que aún pueden añadírsele a una herramienta como la propuesta por, que derive en un ambiente que tenga otras capacidades no consideradas aún. Entre ellas se encuentran:

1. Inclusión de nuevos elementos de descripción, tales como los ADL, vistas arquitectónicas y distintas notaciones.

2. Posibilidad de evaluar la calidad de la arquitectura diseñada en base a los elementos de diseño utilizados.

3. Ofrecer la posibilidad de soporte a los distintos métodos y técnicas de evaluación de arquitecturas de software.

Para efectos de la evaluación, resulta interesante conocer los distintos tipos de decisión que pueden ser tomados a nivel de diseño, puesto que un ambiente de evaluación y análisis debe estar en capacidad de soportar estos procesos. A nivel arquitectónico, establecen que los tópicos de decisión con frecuencia son:

Estilos y patrones arquitectónicos Arquitecturas de referencia Responsabilidades asociadas a los componentes Identificación de interconexiones entre componente. Comportamiento dinámico del sistema Interfaces entre componentes y sus responsabilidades Manejo de múltiples configuraciones para sistemas distribuidos o concurrentes.

Este proceso de análisis y diseño de arquitecturas de software presenta sobrecargas de recolección, manejo y presentación de la información relevante a ellos. Esto resulta un impedimento sustancial para las organizaciones que quieren adoptar una actitud más madura a su práctica en el diseño de arquitecturas de software.

Proveer una herramienta que soporte estas prácticas es un primer paso de ayuda a extender su adopción en la industria. Es importante que el ambiente esté en capacidad de asistir en el proceso de

diseño para efecto de la toma de decisiones, independientemente de la metodología y en el nivel en que se encuentre el proceso de desarrollo. Al añadirle la capacidad de apoyo a la evaluación del diseño, con el manejo de las técnicas y métodos existentes hasta el momento, la herramienta proveerá información acerca de los puntos de riesgo en el diseño que se está evaluando. Esto resulta de gran ayuda al arquitecto al momento de tomar decisiones que harán posible la satisfacción de los requerimientos de calidad por parte del diseño en cuestión. Si bien es cierto que la calidad del sistema depende en gran parte de la implementación, también es cierto que gran parte de ella depende de la arquitectura.

De aquí la importancia de la correspondencia entre el diseño y la implementación. Es por ello que el ambiente de análisis, diseño y evaluación de arquitecturas de software se propone como un medio que permitiría la satisfacción de los requerimientos de calidad del sistema establecidos por los involucrados en el desarrollo del mismo.

UNIDAD III: INTERFAZ DE USUARIO

DISEÑO DE INTERFACES DE USUARIO

La interfaz de usuario (IU) es uno de los componentes más importantes de cualquier sistema computacional, pues funciona como el vínculo entre el humano y la máquina. La interfaz de usuario es un conjunto de protocolos y técnicas para el intercambio de información entre una aplicación computacional y el usuario. La IU es responsable de solicitar comandos al usuario, y de desplegar los resultados de la aplicación de una manera comprensible. La IU no es responsable de los cálculos de la aplicación, ni del almacenamiento, recuperación y transmisión de la información.

El éxito de un programa frecuentemente se debe a qué tan rápido 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 más 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 automóvil, el conductor usa el volante para controlar la dirección del vehículo, el pedal del acelerador y el pedal del freno para controlar su velocidad. El conductor puede percibir la posición del vehículo mirando a través del parabrisas y leyendo el velocímetro puede conocer la velocidad exacta del vehículo. La interface del automóvil está compuesta por la totalidad de instrumentos que el conductor usa para cumplir las tareas de llevar y dirigir el automóvil.

La interacción 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 diálogo hombre-computadora en el que media una interfaz.

Esas interacciones están relacionadas con una diversidad de aspectos, dentro de los que se incluye: la realización de tareas por hombres y máquinas, la estructura de la comunicación hombre-máquina, las interacciones organizacionales y sociales, las capacidades humanas incluyendo el aprendizaje, los algoritmos y programación de la propia interfaz, las restricciones de la propia tecnología para el diseño y construcción de las interfaces.

Por un lado el usuario debe conocer el funcionamiento de la interfaz a un nivel operativo, implicando además una situación de aprendizaje y el involucramiento de procesos cognitivos.

Todo aprendizaje implica tanto la creación, como el cambio de estado de las estructuras del conocimiento. Ambos aspectos son necesarios para la adaptación a nuevas experiencias y a la solución de problemas.

Los procesos cognitivos asociados a las estrategias de construcción del conocimiento involucran distintos tipos de operaciones:

exteriorización: es el proceso de externalizar el conocimiento que un individuo posee;

representación: implica como el conocimiento es exteriorizado y representado usando medios de comunicación;

asimilación: proceso que se refiere a las formas por las cuales el conocimiento es exteriorizado, adquirido y utilizado

Por otra parte la interfaz debe estar diseñada en función de las características 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 DISEÑO DE INTERFACES DE USUARIO.

Familiaridad del usuario:

Utilizar términos y conceptos que se toman de la experiencia de las personas que más 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.

Mínima 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. Confirmación de acciones destructivas 2. Proveer de un recurso para deshacer

Guía al usuario:

Cuando los errores ocurren, la interfaz debe proveer retroalimentación significativa y características de ayuda sensible al contexto.

Diversidad de usuarios:

La interfaz debe proveer características de interacción apropiada para los diferentes tipos de usuarios.

INTERACCION CON EL USUARIO

Una interfaz coherente debe integrar la interacción del usuario y la presentación de la información.

Shneiderman(1998) clasifica la interacción en 5 estilos primarios:

Manipulación directa:

Interacción directa con los objetos de la pantalla. Rápida e intuitiva Fácil de aprender Ejemplo: para borrar un archivo, el usuario lo arrastra al bote de basura. Videos de juegos Puede ser difícil de implementar. Sólo es adecuada donde hay una metáfora visual para las tareas y objetos.

Selección de menús:

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 propósito general Puede ser difícil de implementar. Sólo es adecuada donde hay una metáfora visual para las tareas y objetos.

Lenguaje Natural:

El usuario emite comandos en lenguaje natural. Accesible a usuarios casuales Fácil de ampliar Se requiere teclear más. Los sistemas de comprensión de lenguaje natural no son fiables. Ejemplo: Sistemas de horarios, sistemas www de recuperación de la información.

COLOR DE LA INTERFAZ

Aunque se utilicen convenciones de color en la IU, se deberían usar otros mecanismos secundarios para proveer la información a aquellos usuarios con problemas en la visualización de colores El color ayuda y mejora la presentación de la interfaz, permitiendo al usuario comprender y manejar la complejidad.

Shneiderman(1998) establece 14 lineamientos claves para la utilización efectiva del color. Los más relevantes:

Limitar el número de colores utilizados y ser conservador al momento de utilizarlos. No utilizar más de 4 ó 5 colores diferentes en una ventana y no más de 7 en la interfaz total del sistema.

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

Ejemplo semáforos de alerta que reportan estados normales, precaución y alarma.

Utilizar el código de colores para apoyar la tarea que los usuarios están tratando de llevar a cabo.* Un color para resaltar una situación anómala, otro para similitudes.

Utilizar el código de colores en una forma consciente y consistente.

Si usamos rojo para mostrar alarma , mantener esta lógica durante todo el sistema Ser cuidadoso al utilizar pares de colores Dada la fisiología del ojo, las personas no pueden enfocar el rojo y el azul simultáneamente.

En general el color no debe utilizarse para representar algún 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 químico es caliente.

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

DESCONOCIMIENTO DEL USUARIO

Es difícil saber el grado de conocimientos de cómputo del usuario final, lo cual, frecuentemente, hace que las interfaces de usuario desarrolladas no sean las apropiadas. Se da el caso de que el diseñador implemente la IUs pensando en que la van a usar programadores avanzados, como el propio diseñador, 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

Según 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 alfanuméricas (intérpretes de mandatos) que solo presentan texto. Interfaces gráficas de usuario (GUI, Graphics User Interfaces): las que permiten comunicarse con

el ordenador de una forma muy rápida e intuitiva representando gráficamente los elementos de control y medida.

Interfaces táctiles: que representan gráficamente un "panel de control" en una pantalla sensible que permite interaccionar con el dedo de forma similar a si se accionara un control físico.

Según su construcción

Pueden ser de hardware o de software:

* Interfaces hardware:Se trata de un conjunto de controles o dispositivos que permiten la interacción hombre-máquina, 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 GRÁFICA DE USUARIO

En el contexto del proceso de interacción persona - ordenador, la interfaz gráfica de usuario es el artefacto tecnológico de un sistema interactivo que posibilita, a través del uso y la representación del lenguaje visual, una interacción amigable con un sistema informático.

La interfaz gráfica de usuario (en Idioma inglés Graphical User Interface, GUI) es un tipo de interfaz de usuario que utiliza un conjunto de imágenes y objetos gráficos para representar la información y acciones disponibles en la interfaz. Habitualmente las acciones se realizan mediante manipulación directa para facilitar la interacción del usuario con la computadora.

Surge como evolución de la línea de comandos de los primeros sistemas operativos y es pieza fundamental en un entorno gráfico. Como ejemplo de interfaz gráfica de usuario podemos citar el escritorio o 'desktop' del sistema operativo Windows y el entorno X-Window de Linux y también Aqua de Mac OS X

METÁFORAS VISUALES

Una metáfora es una figura del lenguaje donde se realiza una comparación entre dos objetos que no tienen ninguna relación aparente. Un objeto es sustituido en una frase por un segundo objeto transmitiéndole al primer objeto sus características explícitas e implícitas. Un ejemplo de metáfora es la conocida frase “El tiempo es oro” donde se transfieren las características de la palabra “oro” (valioso, escaso, preciado) a la palabra “tiempo” para dar a entender su valor.

Originalmente metáfora es una palabra griega que significaba transferir. Su etimología viene de meta que significa “cambio” y pherein que significa “llevar o trasladar”. Así, la palabra Metáfora tiene a su vez un significado metafórico: “llevar o transferir un significado de una cosa a otra”.

Las metáforas visuales funcionan de una manera similar, se sustituye un mensaje complejo mediante una imagen más 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 características del producto (enlatado, industrializado, producido en serie etc.) por las del árbol (naturaleza,frescura,saludable). Eso es una metáfora visual.

APLICACIONES CONOCIDAS

El Escritorio

La metáfora del escritorio (desktop) es una de las más populares y extendidas en las interfaces humano-computadora. Ésta fue muy conscientemente utilizada en el diseño del entorno de la Apple Macintosh.

Es una metáfora compleja, ya que lleva contenida dentro de sí otras metáforas más 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 información almacenada en el sistema. También 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 función es fácil de entender para un usuario, aun sin entrenamiento formal en informática. Ya que puede trasladar los conocimientos adquiridos en su experiencia con objetos tangibles al entorno virtual e informático. Esto es un logro muy significativo de las interfaces gráficas sobre las antiguas Interfaces de Línea de Comando. Si el usuario abre una carpeta y se encuentra con fichero que cree que no debería estar ahí, simplemente lo arrastra con el puntero de su ratón hasta la carpeta correcta. Si el fichero en

cuestión ya no le es útil, entonces lo arrastra al cesto de basura sabiendo que si se quedará ahí por si cambia de opinión hasta que vacíe el cesto definitivamente. Casi como en la vida real.

Las Pestañas.

Las pestañas que sobresalen de entre todas las carpetas dentro del cajón de un archivero ayudan a separar visualmente en secciones los montones de carpetas beige que tienden a lucir todas iguales.

A demás, sobre las pestañas se pueden escribir descripciones taxonómicas sobre el contenido de la sección dándole un sentido más formal y amigable a la categorización de los contenidos.

Ya que un sitio web está por lo regular dividido en varias secciones que categorizan la información proporcionada por el sitio, para proveer al usuario una forma de acceso al contenido más 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 categorías del sitio de forma consistente a través de todas las páginas que la conforman. A esa lista consistente de enlaces se le denomina navegación.

La navegación de un sitio puede ser presentada de muchas maneras, pero a medida que el desarrollo web va madurando se van creando estándares o patrones de diseño que son familiares a los usuarios y aumentan el sentido de usabilidad del sitio web en cuestión. Una de las maneras más efectivas de presentar la navegación es diseñándola de manera que se asemeje a las pestañas de los archiveros que mencionamos antes, esto es, la metáfora de las pestañas (tabs).

Las pestañas son mostradas en la parte superior de cada página y el área inferior está conectada visualmente con ésta. La información colocada en el panel debajo de la pestaña corresponde a la categoría señalada en la pestaña seleccionada. La categoría seleccionada es resaltada mediante contrastes de color, forma, tamaño o tipografía. Es mejor combinar el contraste necesario haciendo combinaciones de color y tamaño.

Conectando usualmente la pestaña seleccionada con el área debajo de ésta, por ejemplo diseñándolas con el mismo color de fondo, la relación es reforzada considerablemente. Cabe notar que la función de un sistema de navegación diseñado según la metáfora de pestañas y cualquier otra colección de enlaces sin estilo aplicado no cambia, pero para el usuario es más fácil interactuar con algo que le resulta familiar.

Íconos.

Los íconos son representaciones ideográficas con un alto nivel de síntesis puesto que tienen que representar significados complejos en imágenes simples.

Los íconos han sido utilizados por mucho tiempo, desde la edad media se han desarrollado complejos sistemas icónicos como los escudos de armas heráldicos y signos astrológicos. En la sociedad moderna todos estamos familiarizados con los íconos dentro y fuera del trabajo: por ejemplo, íconos en la puerta de los baños, íconos en las señales de tránsito e íconos más complejos en los aparatos electrónicos.

La ideografía es más fundamental al lenguaje de lo que nos damos cuenta. A través de nuestro lenguaje hablado y escrito lo que hacemos es “pintar” imágenes en las mentes de los lectores y escuchas. De una manera análoga, las imágenes pueden ser utilizadas con propósitos comunicacionales. Los ideogramas son capaces de comunicar ideas abstractas a pasear de ser sólo formas visuales y a través del uso de metáforas, las imágenes pueden encapsular prácticamente cualquier idea.

En el ámbito computacional, el uso de los íconos ha sido una extensión de su uso tradicional con la posibilidad añadida de interacción que ofrecen las tecnologías modernas. Idealmente, una interfaz

construida sólo con íconos debería ser comprensible por cualquier persona independientemente del lenguaje que habla puesto que sería capaz de reconocer las metáforas 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 metáfora del escritorio tuvo tanto éxito, ya que era sencillo reconocer la función de ciertos objetos en pantalla gracias a su apariencia. Un ícono en forma de carpeta debería tener la funcionalidad de almacenar documentos y otro en forma de cesto de basura tendría 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 aplicación y debe valerse de metáforas compuestas para lograrlo.

Antes de explorar el proceso de desarrollo de un sistema de metáforas icónicas primero debemos ver el proceso de comunicación. En este caso la comunicación se refiere al mensaje transmitido entre el diseñador de la aplicación y el usuario. Un ícono es percibido primero por su forma (sintaxis), después por la forma entre su forma y su significado (semántica) y en tercer lugar por su utilidad (pragmatismo).

Sintaxis de los íconos

El significado de un ícono se puede alterar mediante la combinación de varios íconos en uno mismo, lo que nos permite crear metáforas compuestas que abarquen un abanico mayor de significados abstractos.

Las técnicas de sintaxis son:

Superimposición:

Sucede cuando ícono es colocado encima de otro. Por ejemplo, colocando un pequeño í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 podría ser “buscar en documento”. Los elementos superpuestos tienen una jerarquía visual que separa los elementos primarios de los secundarios.

Los elementos secundarios son denominados credenciales. El ejemplo anterior el ícono pequeño de buscar es una credencial para documento. Si intercambiamos el sentido de la jerarquía visual y dejamos el elemento de documento como credencial para búsqueda entonces el significado podría cambiar a documento de búsquedas refiriéndose tal vez a un fichero donde se almacenan los resultados de las búsquedas realizadas.

Yuxtaposición:

Sucede cuando dos íconos son colocados en una determinada relación espacial pero con el mismo peso visual, para expresar un mayor significado. Por ejemplo, un calendario junto a un reloj significa Fecha y hora. También puede ser usada esta técnica para representar causa y efecto, por ejemplo un globo de texto puede significar comentario, si es precedido por un símbolo de adición (+) entonces su significado conjunto es “añadir comentario”.

Duplicación:

Para indicar pluralidad, basta con colocar varias instancias de un símbolo uno encima de otro. Uno o más íconos de carpetas apilados significarán entonces carpetas.

FACTORES DE DISEÑO EN EL MENSAJE DE ERROR

Contexto:

El sistema guía 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 terminología 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 país en lo posible evitar malas interpretaciones del contexto del mensaje.

EJEMPLO

RECUPERACION DE LA INFORMACION

La referencia a la Recuperación de Información (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: cómo representar y organizar la información intelectualmente, cómo especificar una búsqueda intelectualmente y cuáles son los sistemas y técnicas utilizadas para estos procesos.

La efectividad de un sistema de recuperación de información está relacionada a la relevancia de la información obtenida y a los procesos de interacción. La relevancia refiere a la pertinencia de la información con respecto a las necesidades del usuario, involucrando también los estados cognitivos y afectivos y creencias del mismo. Los procesos de interacción refieren al relacionamiento hombre-sistema de recuperación de información mediado por la interfaz.

En este contexto una interfaz debe posibilitar representar las necesidades de información del usuario, buscar la información 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 según el tipo de problema o consulta Posibilitar el diálogo entre sistema y usuario Inferir la evaluación del usuario sobre: La correspondencia de los resultados logrados con el problema

La necesidad de modificar la pregunta inicial o finalización si el usuario está satisfecho Vuelta sobre el análisis de la pregunta y selección de nuevas respuestas si fuera necesario

TIEMPO DE RESPUESTA

Tiene dos características importantes:

1. El retardo. 2. La variabilidad.

Si el retardo de respuesta es demasiado grande, producirá frustración y stress en el usuario. Sin embargo un retardo de respuesta muy rápido puede confundir al usuario que es guiado por la interfaz, llevándolo a producir errores. La variabilidad está referida a la desviación del tiempo de respuesta medio

EVALUACION DE LA INTERFAZ

Aprendizaje: ¿Cuánto tiempo tarda un usuario nuevo en ser productivo con el sistema?

Velocidad de operación: ¿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?

Recuperación: ¿Qué tan bien se recupera el sistema a los errores del usuario?

Adaptación: ¿Qué tan atado está el sistema a un solo modelo de trabajo?

PSICOLOGIA HCI

HCI, son las siglas de “Human Computer Interaction”, expresión que hace referencia al ámbito de investigación y formación científico tecnológica orientado a la comprensión del fenómeno de la interacción entre el usuario el humano y la computadora. En HCI se hacen aportaciones desde diversas áreas de conocimiento tales como, la ingeniería informática, la ingeniería del software, la ingeniería de sistemas, la psicología (especialmente relevante la psicología cognitiva y, más recientemente la psicología de la emociones y la psicología de la conducta), la neurociencia, la sociología o el diseño.

Los conocimientos que se obtienen en la investigación sobre la interacción humana computadora, constituyen la base sobre la cual se construyen los propios ordenadores, se crean las aplicaciones informáticas que se ejecutan en ellos, y se diseñan las interfaces de usuario que permiten la interacción entre el humano y la máquina.

Dentro de la HCI, un ámbito de conocimiento relevante es el que gira entorno de lo que denominamos “Factor Humano”.

La expresión “Factor Humano” se refiere al ámbito de conocimiento científico sobre las capacidades del ser humano. Cuando este conocimiento es aplicado al diseño o desarrollo de productos, tales como los sistemas o aplicaciones informáticas, se denomina Ingeniería de Factor Humano.

Los orígenes de la HCI hay que buscarlas en la rama de la Psicología Aplicada que estudia la Interacción Persona-Ordenador. Las dos disciplinas de las que surge la IPO/HCI son las llamadas "Human Factors" y la Ergonomía (en realidad es la misma disciplina, el primer término se utiliza en EE.UU y el segundo en Europa). Actualmente el uso de estos términos 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 psicología es creciente. La Psicología es la disciplina que estudia la percepción, la memoria, la adquisición de habilidades y el aprendizaje, la resolución de problemas, el movimiento, las tareas de juicio, de búsqueda o procesamiento de información y de la comunicación, es decir, procesos todos cuyo conocimiento se requiere para el adecuado diseño de mecanismos de interacción del usuario. Aunque la Psicología Cognitiva es una ciencia muy joven en lo que respecta a investigaciones de carácter básico y sistemático, existen actualmente suficientes hallazgos basados en resultados empíricos que permiten el desarrollo de la HCI y, por ende, de sitios web adaptados a los usuarios.

La HCI es también una disciplina joven, pero no tanto como pudiera parecer. Desde el primer ordenador ha sido necesario el diseño de un sistema de comunicación persona-ordenador. Los estudios en esta disciplina han permitido dar una base teórica al diseño y a la evaluación de aplicaciones informáticas. La importancia de esta disciplina se pone sobre relieve al leer artículos sobre el tema escritos hace cuarenta años en los que se predecían elementos de interacción de los que se dispone actualmente. Una de las asociaciones más influyentes en este campo es la ACM SIGCHI (Association for Computing Machinery's Special Interest Group on Computer-Human Interaction) que desde 1982 reúne a los mejores especialistas en IPO/HCI.

Los primeros estudios específicos de IPO/HCI aparecieron en los años sesenta y se referían a la simbiosis Persona-Ordenador (Licklider, 1960). Este autor afirmó anticipándose a la problemática posterior que el problema de la interacción hombre-ordenador no es crear ordenadores productores de respuestas, sino ordenadores que sean capaces de anticipar y participar en la formulación de las preguntas.

Licklider y Clark (1962) elaboraron una lista de 10 problemas que deberían ser resueltos para facilitar la interacción personas-ordenador. Según el los cinco primeros problemas deberían ser resueltos de manera inmediata, el sexto en un tiempo intermedio y los cuatro últimos, a largo plazo:

1. Compartir el tiempo de uso de los ordenadores entre muchos usuarios. 2. Un sistema de entrada-salida para la comunicación mediante datos simbólicos y gráficos. 3. Un sistema interactivo de proceso de las operaciones en tiempo real. 4. Sistemas para el almacenamiento masivo de información que permitan su rápida recuperación. 5. Sistemas que faciliten la cooperación entre personas en el diseño y programación de grandes

sistemas. 6. Reconocimiento por parte de los ordenadores de la voz, de la escritura manual impresa y de la

introducción de datos a partir de escritura manual directa. 7. Comprensión del lenguaje natural, sintáctica y semánticamente. 8. Reconocimiento de la voz de varios usuarios por el ordenador. 9. Descubrimiento, desarrollo y simplificación de una teoría de algoritmos. 10. Programación heurística o a través de principios generales. 11. El tiempo ha demostrado que Licklider y Clark estaban en lo cierto en la mayoría de sus

observaciones, sin embargo, actualmente aún no se han conseguido solucionar algunos de los problemas previstos para su resolución a largo plazo.

Hansen (1971) en su libro "User Engineering Principles for Interactive Systems" hace la primera enumeración de principios para el diseño de sistemas interactivos:

1. Conocer al usuario

2. Minimizar la memorización, sustituyendo la entrada de datos por la selección de ítems, usando nombres en lugar de números, asegurándose un comportamiento predecible y proveyendo acceso rápido a información práctica del sistema.

3. Optimizar las operaciones mediante la rápida ejecución de operaciones comunes, la consistencia de la interfaz y organizando y reorganizando la estructura de la información basándose en la observación del uso del sistema.

4. Facilitar buenos mensajes de error, crear diseños que eviten los errores más 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 antigüedad de estos principios es fácil encontrar en sitios web de comercio electrónico códigos inmemorizables para identificar productos, mensajes de error ininteligibles y, en general, un maltrato constante al usuario.

UNIDAD IV: DISEÑO ORIENTADO A OBJETOS

DISEÑO ORIENTADO A OBJETO

Es una fase de la metodología orientada a objetos para el desarrollo de Software. Su uso induce a los programadores a pensar en términos de objetos, en vez de procedimientos, cuando planifican su código. Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La 'interfaz del objeto', esto es, las formas de interactuar con el objeto, también es definida en esta etapa. Un programa orientado a objetos es descrito por la interacción de esos objetos. El diseño 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 análisis orientado a objetos.

PATRONES DE DISEÑO

El diseño orientado a objetos es una etapa fundamental en el desarrollo de sistemas orientados a objetos, sin embargo, por lo general, en la práctica se observa que no se le dedica el tiempo suficiente o bien es efectuada de una manera muy superficial. Es común observar una pequeña etapa de análisis de requisitos y un pasaje inmediato al proceso de programación.

Algunas veces para justificar esta superficialidad en cuanto a la manera de trabajar en la etapa de diseño, se atribuye a la falta de tiempo como causa principal. Sin embargo, sería más que beneficioso aplicar las buenas prácticas en cuanto a desarrollo de software para lograr productos de calidad.

Particularmente, durante la etapa de diseño se efectúan decisiones relativas a qué métodos se requerirán, dónde se los colocarán y cómo deberían interactuar los objetos, actividades nada triviales y muy importantes. Por tal motivo, sería altamente conveniente tener en cuenta algunos patrones de diseño fundamentales.

En la tecnología de objetos, un patrón es una descripción del problema y la solución, 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 describirán cinco:

1. Experto en información

2. Creador 3. Alta cohesión 4. Bajo acoplamiento 5. Controlador

Experto en información

Problema ¿Cuál es un principio para asignar responsabilidades a los objetos?

Solución Asignar una responsabilidad al experto en información (la clase que tiene la información necesaria para realizar la responsabilidad) Si esta actividad se realiza bien, los sistemas tienden a ser más fáciles de entender, mantener y ampliar, y existen más oportunidades para reutilizar componentes en futuras aplicaciones.

El experto en información se utiliza con frecuencia en la asignación de responsabilidades; es un principio de guía básico que se utiliza continuamente en el diseño de objetos. El Experto no pretende ser una idea oscura o extravagante; expresa la “intuición” común de que los objetos hacen las cosas relacionadas con la información que tienen.

Se debe notar que el cumplimiento de la responsabilidad a menudo requiere información que se encuentra dispersa por diferentes clases de objetos.

Beneficios

Se mantiene el encapsulamiento de la información, puesto que los objetos utilizan su propia información para llevar a cabo las tareas. Normalmente, esto conlleva un bajo acoplamiento, lo que da lugar a sistemas más robustos y más fáciles de mantener.

Se distribuye el comportamiento entre las clases que contienen la información requerida, por tanto, se estimula las definiciones de clases más cohesivas y “ligeras” que son más fáciles de entender y mantener. Se soporta normalmente una alta cohesión.

Creador

Problema ¿Quién debería ser el responsable de la creación de una nueva instancia de alguna clase?

Solución Asignar a la clase B la responsabilidad de crear una instancia de la clase A si se cumple una o más de los casos siguientes:

B agrega objetos de A B contiene objetos de A B registra instancias de objetos de A B utiliza más estrechamente objetos de A B tiene los datos de inicialización que se pasará a un objeto de A cuando sea creado (por tanto,

B es un Experto con respecto a la creación de A)

Si se asigna bien la responsabilidad de creación, el diseño puede soportar un bajo acoplamiento, mayor claridad, encapsulación y reutilización.

Contraindicaciones

A menudo, la creación 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 creación a una clase auxiliar denominada Factoría.

Alta cohesión

Problema:

¿Cómo mantener la complejidad manejable?

Solución:

Asignar una responsabilidad de manera que la cohesión permanezca alta.

La cohesión es una medida de la fuerza con la que se relacionan y del grado de focalización de las responsabilidades de un elemento. Un elemento con responsabilidades altamente relacionadas, y que no hace una gran cantidad de trabajo, tiene alta cohesión. Estos elementos pueden ser clases, subsistemas, etc.

Una clase con baja cohesión hace muchas cosas no relacionadas, o hace demasiado trabajo. Tales clases no son convenientes, adolecen de los siguientes problemas:

Difíciles de entender Difíciles de reutilizar Difíciles de mantener Delicadas, constantemente afectadas por los cambios.

Como regla empírica, una clase con alta cohesión tiene un número relativamente pequeño de métodos, 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:

¿Cómo soportar bajas dependencias, bajo impacto del cambio e incremento de la reutilización?

Solución:

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, confía en, otros elementos. Un elemento con bajo acoplamiento no depende de demasiados otros elementos.

Una clase con alto acoplamiento confía en muchas otras clases. Tales clases podrían no ser deseables; algunas adolecen de los siguientes problemas:

Los cambios en las clases relacionadas fuerzan cambios locales Son difíciles de entender de manera aislada Son difíciles 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 genéricas por naturaleza, y con una probabilidad de reutilización alta, debería tener un acoplamiento especialmente bajo.

El caso extremo de bajo acoplamiento es cuando no existe acoplamiento entre clases. Esto no es deseable porque una metáfora central de la tecnología 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 diseño 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 actúan como simple repositorios de datos.

Controlador

Problema:

¿Quién debe ser el responsable de gestionar un evento de entrada al sistema?

Solución:

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 Sesión (controlador de sesión 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 sesión es una instancia de una conversación con un actor. Las sesiones pueden tener cualquier duración, pero se organizan a menudo en función 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 método para la operación del sistema.

La primera categoría de controlador es el controlador de fachada que representa al sistema global, dispositivo o subsistema. La idea es elegir algún nombre de clase que sugiera una cubierta, o fachada, sobre las otras capas de la aplicación, y que proporciona la llamada a los servicios más 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. Nótese que no es un objeto del dominio; es una construcción artificial para dar soporte al sistema.

Un controlador de caso de uso es una alternativa a tener en cuenta cuando la asignación de responsabilidades a un controlador de fachada nos conduce a diseños con baja cohesión 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 realización, normalmente delegando a otros objetos