Qué es la Arquitectura del Software y que relación tiene con la usabilidad. Tener en cuenta la usabilidad en el momento del diseño de la arquitectura de un sistema interactivo nos puede ahorrar muchos quebraderos de cabeza.
El Iceberg de la usabilidad
Se podría decir que, en el diseño de un sistema, hay tres aspectos a tener en cuenta:
En realidad, este modelo de desarrollo ha fallado a menudo. ¿Cuántas veces hemos tenido que correr a realizar cambios profundos en la funcionalidad de una aplicación después de haber detectado problemas de usabilidad? Dick Berry, en su analogía del Iceberg de la usabilidad, explica que los aspectos relacionados con la presentación, es decir, lo que normalmente entendemos como look & feel, sólo afectan en un 40% a la usabilidad. El 60% restante está influenciado por lo que él llama modelo del usuario, que está constituido por los objetivos que el usuario quiere alcanzar 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 (programación orientada a objetos), que incluye, entre otras cosas, los objetos y las metáforas de la interfaz. Este modelo de objetos, siempre según Berry, es el que permite al usuario relacionar sus objetivos con la funcionalidad del sistema.
Por lo tanto, y esto ya es de cosecha propia, para conseguir 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 más lejos y no basta con tener en cuenta la presentación y la funcionalidad. Sobre todo en sistemas complejos, como pueden ser los entornos distribuidos, los transaccionales, los multicanal y aquéllos en los que puede haber miles de usuarios conectados simultáneamente, hay que tener en cuenta la usabilidad desde el inicio del diseño del sistema, es decir, desde lo que se denomina 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 entorno 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 interacción, veremos que la causa de que no se puedan implementar es que no se tuvo en cuenta al usuario al inicio del diseño del sistema, es decir, en la Arquitectura del Software.
¿Qué es la Arquitectura del Software? Existen muchas definiciones de Arquitectura del Software y no parece que ninguna de ellas haya sido totalmente aceptada. En un sentido amplio podríamos estar de acuerdo en que la Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema, programa o aplicación y tiene la responsabilidad de:
La definición oficial de Arquitectura del Software es la IEEE Std 1471-2000 que reza así: La Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución.
Los productos resultantes de la Arquitectura del Software
El objetivo principal de la Arquitectura del Software es aportar elementos que ayuden a la toma de decisiones y, al mismo tiempo, proporcionar conceptos y un lenguaje común que permitan la comunicación entre los equipos que participen en un proyecto. Para conseguirlo, la Arquitectura del Software construye abstracciones, materializándolas en forma de diagramas (blueprints) comentados.
No hay estándares en cuanto a la forma y lenguaje a utilizar en estos blueprints. De todas formas, existe consenso en cuanto a la necesidad de organizar dichas abstracciones en vistas, tal y como se hace al diseñar un edificio. La cantidad y tipos de vistas difiere en función de cada tendencia arquitectónica.
Quizá uno de los modelos más conocidos es el 4+1 de Philippe Kruchten, vinculado al Rational Unified Process (RUP), que define cuatro vistas diferentes:
Para ilustrar un poco lo que se ha explicado hasta ahora, a continuación se muestran dos diagramas de arquitectura en un entorno 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 muestra los componentes y servicios típicos de un entorno J2EE.
El segundo diagrama es una vista de proceso que muestra las relaciones entre las capas model, view y controller de la arquitectura MVC bajo J2EE.
La investigación sobre Arquitectura del Software y Usabilidad
El interés por la relación entre Arquitectura del Software y usabilidad no es nuevo, pero recientemente han aparecido algunos trabajos que abren el camino a la práctica del resultado 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 título es bastante ilustrativo: Avoiding We cant change THAT!: Software Architecture & Usability (Cómo evitar ¡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 Sánchez-Segura.
Escenarios de usabilidad sensibles a la Arquitectura del Software
El trabajo de Bass y de este equipo se basa en inventariar una serie de escenarios de usabilidad sensibles a la Arquitectura del Software. Esto significa determinar una serie de momentos de interacción 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 objetivo del presente artículo pero, a modo de ejemplo, se enumeran a continuación los cinco primeros escenarios:
Bass continúa con una propuesta de patrón arquitectural para cada escenario (sobre el tema de patrones, consultad el artículo de Luis Villa, Patrones para el diseño de interfaz, publicado en Grancomo).
El objetivo es doble:
Resumen
Siempre que se tenga la oportunidad, sería necesario que la usabilidad se tuviera presente desde el inicio del diseño de un sistema, es decir, desde el momento de la Arquitectura del Software. Pero, para que esta participación sea realmente efectiva, arquitectos y expertos en usabilidad deberían tener un lenguaje común. Es en este sentido en el que los escenarios de usabilidad y los patrones arquitectónicos pueden ser de gran ayuda.
Artículo original en Alzado.org
Se podría decir que, en el diseño de un sistema, hay tres aspectos a tener en cuenta:
- la presentación de la información
- la funcionalidad de la aplicación
- la Arquitectura del Software
En realidad, este modelo de desarrollo ha fallado a menudo. ¿Cuántas veces hemos tenido que correr a realizar cambios profundos en la funcionalidad de una aplicación después de haber detectado problemas de usabilidad? Dick Berry, en su analogía del Iceberg de la usabilidad, explica que los aspectos relacionados con la presentación, es decir, lo que normalmente entendemos como look & feel, sólo afectan en un 40% a la usabilidad. El 60% restante está influenciado por lo que él llama modelo del usuario, que está constituido por los objetivos que el usuario quiere alcanzar 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 (programación orientada a objetos), que incluye, entre otras cosas, los objetos y las metáforas de la interfaz. Este modelo de objetos, siempre según Berry, es el que permite al usuario relacionar sus objetivos con la funcionalidad del sistema.
Por lo tanto, y esto ya es de cosecha propia, para conseguir 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 más lejos y no basta con tener en cuenta la presentación y la funcionalidad. Sobre todo en sistemas complejos, como pueden ser los entornos distribuidos, los transaccionales, los multicanal y aquéllos en los que puede haber miles de usuarios conectados simultáneamente, hay que tener en cuenta la usabilidad desde el inicio del diseño del sistema, es decir, desde lo que se denomina 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 entorno 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 interacción, veremos que la causa de que no se puedan implementar es que no se tuvo en cuenta al usuario al inicio del diseño del sistema, es decir, en la Arquitectura del Software.
¿Qué es la Arquitectura del Software? Existen muchas definiciones de Arquitectura del Software y no parece que ninguna de ellas haya sido totalmente aceptada. En un sentido amplio podríamos estar de acuerdo en que la Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema, programa o aplicación 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 definición oficial de Arquitectura del Software es la IEEE Std 1471-2000 que reza así: La Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución.
Los productos resultantes de la Arquitectura del Software
El objetivo principal de la Arquitectura del Software es aportar elementos que ayuden a la toma de decisiones y, al mismo tiempo, proporcionar conceptos y un lenguaje común que permitan la comunicación entre los equipos que participen en un proyecto. Para conseguirlo, la Arquitectura del Software construye abstracciones, materializándolas en forma de diagramas (blueprints) comentados.
No hay estándares en cuanto a la forma y lenguaje a utilizar en estos blueprints. De todas formas, existe consenso en cuanto a la necesidad de organizar dichas abstracciones en vistas, tal y como se hace al diseñar un edificio. La cantidad y tipos de vistas difiere en función de cada tendencia arquitectónica.
Quizá uno de los modelos más conocidos es el 4+1 de Philippe Kruchten, vinculado al Rational Unified Process (RUP), que define cuatro vistas diferentes:
- Vista lógica: describe el modelo de objetos.
- Vista de proceso: muestra la concurrencia y sincronía de los procesos.
- Vista física: muestra la ubicación del software en el hardware.
- Vista de desarrollo: describe la organización del entorno de desarrollo.
- Existe una quinta vista que consiste en una selección de casos de uso o de escenarios que los arquitectos pueden elaborar a partir de las cuatro vistas anteriores.
Para ilustrar un poco lo que se ha explicado hasta ahora, a continuación se muestran dos diagramas de arquitectura en un entorno 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 muestra los componentes y servicios típicos de un entorno J2EE.
El segundo diagrama es una vista de proceso que muestra las relaciones entre las capas model, view y controller de la arquitectura MVC bajo J2EE.
La investigación sobre Arquitectura del Software y Usabilidad
El interés por la relación entre Arquitectura del Software y usabilidad no es nuevo, pero recientemente han aparecido algunos trabajos que abren el camino a la práctica del resultado 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 título es bastante ilustrativo: Avoiding We cant change THAT!: Software Architecture & Usability (Cómo evitar ¡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 Sánchez-Segura.
Escenarios de usabilidad sensibles a la Arquitectura del Software
El trabajo de Bass y de este equipo se basa en inventariar una serie de escenarios de usabilidad sensibles a la Arquitectura del Software. Esto significa determinar una serie de momentos de interacción 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 objetivo 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 forma concurrente
- Validación automática de la entrada de datos
Bass continúa con una propuesta de patrón arquitectural para cada escenario (sobre el tema de patrones, consultad el artículo de Luis Villa, Patrones para el diseño de interfaz, publicado en Grancomo).
El objetivo es doble:
- Facilitar a los expertos en usabilidad una checklist con escenarios que muestre aspectos de usabilidad importantes 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.
Resumen
Siempre que se tenga la oportunidad, sería necesario que la usabilidad se tuviera presente desde el inicio del diseño de un sistema, es decir, desde el momento de la Arquitectura del Software. Pero, para que esta participación sea realmente efectiva, arquitectos y expertos en usabilidad deberían tener un lenguaje común. Es en este sentido en el que los escenarios de usabilidad y los patrones arquitectónicos pueden ser de gran ayuda.
Artículo original en Alzado.org
Josep Casanovas
Area de Innovación de La Caixa