Usabilidad
Se podria decir que, en el diseño de un sistema, hay tres apariencias a tener en cuenta: la presentación de la información la funcionalidad de la aplicación la Arquitectura del Software Hasta hace poco, se asumia que la usabilidad era una propiedad exclusiva de la presentacion de la inmaneracion. Se creia que, encapsulando la capa de presentacion y separandola del resto, se permitia construir la aplicacion y, de manera iterativa, pasar los tests de usabilidad. Tras cada test, tan solo seria indispensable resolver los dificultades modificando la presentacion y, gracias a esta separacion, la funcionalidad no quedaria afectada. En realidad, este modelo de desarrollo ha fallado a menudo. ¿Cuantas veces hemos tenido que correr a hacer cambios profundos en la funcionalidad de una aplicacion despues de haber detectado dificultades de usabilidad? Dick Berry, en su analogia del Iceberg de la usabilidad, explica que los apariencias relacionados con la presentacion, es decir, lo que usualmente entendemos como look & feel, solo afectan en un 40% a la usabilidad. El 60% restante esta influenciado por lo que el llama ?modelo del usuario?, que esta constituido por los metas que el usuario desea conseguir con sus tareas. Berry relaciona el modelo del usuario con el modelo de objetos propio de la interfaz de usuario, en el sentido estricto de la OOP (programacion enfocada a objetos), que incluye, entre otras cosas, los objetos y las metaforas de la interfaz. Este modelo de objetos, siempre segun Berry, es el que faculta al usuario relacionar sus metas con la funcionalidad del sistema. Por lo tanto, y esto ya es de cosecha propia, para obtener una buena usabilidad, no basta con tener en cuenta la capa de presentación, sino que es preciso que la usabilidad se contemple también en el momento de la definición de la funcionalidad de la aplicación. Usabilidad y Arquitectura del Software Sin embargo, a menudo hay que ir mas lejos y no basta con tener en cuenta la presentacion y la funcionalidad. Sobre todo en sistemas complejos, como pueden ser los ambitos distribuidos, los transaccionales, los multicanal y aquellos en los que puede haber miles de usuarios conectados simultaneamente, hay que tener en cuenta la usabilidad desde el origen del diseño del sistema, es decir, desde lo que se designa momento de Arquitectura del Software. Es bien sabido por los ingenieros del software que cuanto más tarde se detectan los problemas, más cuesta arreglarlos. ¿Cuántas veces nos ha pasado que, al diseñar una interfaz, desearíamos crear interacciones y diálogos que el ámbito tecnológico no nos permite? Y siempre acabamos exclamando: ¡Pero si esto mismo lo hice en tal otro sitio! La respuesta de los técnicos no se hace esperar y, utilizando un vocabulario lleno de siglas y conceptos técnicos, nos dicen que en su plataforma esto no es posible. Me refiero a cosas como que el usuario pueda visualizar el progreso de sus peticiones, que pueda deshacer acciones (undo), que pueda disponer de un entono multilingüe, que pueda cancelar una operación que lleva mucho tiempo en espera, que pueda reutilizar información que ha introducido anteriormente, y muchas otras cosas. Si analizamos estos escenarios de interaccion, veremos que la motivo de que no se puedan implementar es que no se tuvo en cuenta al usuario al origen del diseño del sistema, es decir, en la Arquitectura del Software. ¿Que es la Arquitectura del Software? Tienen lugar muchas definiciones de Arquitectura del Software y no parece que ninguna de ellas haya sido totalmente aceptada. En un sentido amplio podriamos estar de acuerdo en que la Arquitectura del Software es el diseño de mas alto nivel de la articula de un sistema, proyecto o aplicacion y tiene la responsabilidad de: Definir los módulos principales Definir las responsabilidades que tendrá cada uno de estos módulos Definir la interacción que existirá entre dichos módulos: Control y flujo de datos Secuenciación de la información Protocolos de interacción y comunicación Ubicación en el hardware La Arquitectura del Software aporta una visión abstracta de alto nivel, posponiendo el detalle de cada uno de los módulos definidos a pasos posteriores del diseño. La definicion oficial de Arquitectura del Software es la IEEE Std 1471-2000 que Rezad asi: ?La Arquitectura del Software es la organizacion importante de un sistema constituida por sus componentes, las vinculos entre ellos y el contexto en el que se implantaran, y los comienzos que orientan su diseño y evolucion?. Los artículos resultantes de la Arquitectura del Software El meta principal de la Arquitectura del Software es aportar fundamentos que ayuden a la coge de decisiones y, al mismo tiempo, proporcionar conceptos y un lenguaje general que permitan la generalicacion entre los equipos que participen en un proyecto. Para conseguirlo, la Arquitectura del Software construye abstracciones, materializandolas en manera de diagramas (blueprints) comentados. No hay estandares en cuanto a la manera y lenguaje a utilizar en estos blueprints. De todas maneras, tiene lugar consenso en cuanto a la necesidad de estructurar felicidades abstracciones en vistas, tal y como se hace al diseñar un edificio. La porción y tipos de vistas difiere en funcion de cada tendencia arquitectonica. Quiza uno de los modelos mas conocidos es el ?4+1? de Philippe Kruchten, asociado al Rational Unified Process (RUP), que determina cuatro vistas diferentes: Vista logica: detalla el modelo de objetos. Vista de proceso: presenta la concurrencia y sincronía de los procesos. Vista física: presenta la ubicación del software en el hardware. Vista de desarrollo: detalla la organizacion del ámbito de desarrollo. Tiene lugar una quinta vista que consiste en una seleccion de casos de uso o de escenarios que los arquitectos pueden elaborar a dividir de las cuatro vistas anteriores. Ejemplos de Arquitectura del Software: J2EE y MVC Para ilustrar un escaso lo que se ha explicado hasta ahora, a continuación se muestran dos diagramas de arquitectura en un ámbito J2EE. Ambos diagramas están disponibles en Designing Enterprise Applications with the J2EE Platform, Second Edition. El primer diagrama consiste en una vista lógica que presenta los componentes y servicios típicos de un ámbito J2EE. El segundo diagrama es una vista de proceso que presenta las vinculos entre las capas model, view y controller de la arquitectura MVC debajo J2EE. La investigación sobre Arquitectura del Software y Usabilidad El interes por la relacion entre Arquitectura del Software y usabilidad no es nuevo, pero recientemente han aparecido algunos esfuerzos que abren el sendero a la practica del fruto de las investigaciones. Este año, tanto en Viena, en la Conference on Human Factors in Computing Systems (CHI2004), como en Edimburgo, en la International Conference on Software Engineering (ICSE04), un equipo liderado por Len Bass ha impartido un tutorial sobre el tema, cuyo titulo es bastante ilustrativo: Avoiding ?We can?t change THAT!?: Software Architecture & Usability (Como eludir ?¡Esto no se puede cambiar!?: Arquitectura del Software y Usabilidad). En el equipo docente, junto a Bass estaban Bonni E. John y dos investigadoras españolas, Natalia Juristo y Maribel Sanchez-Segura. Escenarios de usabilidad sensibles a la Arquitectura del Software El esfuerzo de Bass y de este equipo se cimienta en inventariar una serie de escenarios de usabilidad sensibles a la Arquitectura del Software. Esto implica decidir una serie de momentos de interaccion o tareas del usuario que, para que el sistema los pueda soportar, tienen que estar definidos en la Arquitectura del Software. Hasta el momento, este inventario está compuesto de 26 escenarios que se pueden consultar en el documento CMU/SEI-2001-TR-005 de Bass y otros. La lista completa es demasiado extensa para el meta del presente artículo pero, a modo de ejemplo, se enumeran a continuación los cinco primeros escenarios: Agregación de datos: Poder aplicar simultáneamente una acción a un conjunto de datos u objetos. Agregación de comandos: Agrupar acciones que se puedan ejecutar de una sola vez. Comandos de cancelación Uso de aplicaciones de manera concurrente Validación automática de la acceso de datos Patrones arquitecturales Bass continua con una propuesta de patron arquitectural para cada escena (sobre el asunto de patrones, consultad el producto de Luis Villa, Patrones para el diseño de interfaz, publicado en Grancomo). El meta es doble: Facilitar a los entendidos en usabilidad una checklist con escenarios que muestre apariencias de usabilidad significativos a tener en cuenta en tiempo de requerimientos. Facilitar a los arquitectos patrones que los guíen en el momento de dar soporte a los escenarios. Otro documento interesante es: Patrones de Usabilidad: Mejora de la Usabilidad del Software desde el momento Arquitectonico (PDF), de Natalia Juristo y Maribel Sanchez-Segura. Una de las aportaciones mas interesantes de este documento es que detalla el procedimiento de obtencion de los patrones de usabilidad que han de servir para desarrollar los patrones arquitectonicos.