ArticlePDF Available

Verificación de Datos en la GUI como un Aspecto Separado de las Aplicaciones

Authors:

Figures

Content may be subject to copyright.
Verificación de Datos en la GUI como un Aspecto
Separado de las Aplicaciones
Pedro Luis Mateo Navarro
1,2
, Gregorio Martínez Pérez
1
, Diego Sevilla Ruiz
2
1
Departamento de Ingeniería de la Información y las Comunicaciones
2
Departamento de Ingeniería y Tecnología de Computadores
Universidad de Murcia, 30.071 Murcia, España
{pedromateo, gregorio, dsevilla}@um.es
Resumen. La verificación de datos es un elemento esencial y crítico dentro de
un software. Con este fin, en este trabajo se propone un framework que describe
una capa de verificación situada entre la interfaz gráfica (GUI) y la lógica de
aplicación. Esta capa analiza los eventos GUI generados por la interacción del
usuario para detectar cambios, ante los cuales lanza un proceso de
comprobación sobre los requisitos asociados al elemento interactuado. Además,
la capa puede realizar intervenciones sobre la GUI, completando así un proceso
de verificación rico e interactivo. Esta solución trata la verificación de datos
como un aspecto independiente, donde la lógica del proceso es transparente al
desarrollador, y las reglas se incluyen en ficheros separados.
Palabras clave: Verificación Entrada/Salida, Verificación GUI, Verificación
en Tiempo Real, Software Orientado a Aspectos.
1 Introducción
Según el estándar IEEE 1012-2004 [23], la Verificación y Validación Software
(V&V) tiene como principal fin determinar, durante el ciclo de vida del software, si
los requisitos del propio software y del sistema son correctos, completos, precisos y
consistentes, y asegurar así la calidad de un producto software. Los procesos de
Validación y Verificación de la Entrada surgieron para asegurar que sólo las entradas
válidas sean aceptadas, y las que no, sean rechazadas [14]. Un caso especial es la
Verificación Runtime (RV), donde la especificación de requisitos se comprueba en
tiempo de ejecución sobre la propia ejecución de la aplicación [5], en vez de sobre un
modelo, un diseño, o un trozo de código como hacen las técnicas estáticas [4].
La solución propuesta también está basada en el Desarrollo de Software Orientado
a Aspectos (AOSD), ya que el proceso de verificación queda aislado de la lógica
principal, consiguiendo así una mayor modularidad, encapsulación y especialización.
Este trabajo se centra en el procesamiento dinámico de la entrada de datos a través
de la interfaz gráfica (GUI). En las GUIs, tanto las entradas proporcionadas por los
usuarios como las generadas automáticamente son propensas a errores [10]. Por lo
tanto, con el fin de evitar un mal funcionamiento del software, resulta imprescindible
que los sistemas sean tolerantes a los datos, y puedan responder adecuadamente ante
valores esperados e inesperados. Esto nos lleva a proponer este framework, el cual
describe una capa de verificación situada entre la GUI y la lógica de aplicación. Esta
capa de verificación analiza los eventos GUI para monitorizar los cambios
producidos. Ante un cambio, se buscan todas las reglas del SRS (Especificación de
Requisitos Software) relacionadas con el campo modificado, y se comprueban sobre
el estado actual de la GUI.
El resto del artículo se estructura como sigue. El trabajo relacionado es comentado
en la Sección 2. En la sección 3 se comenta el enfoque de verificación propuesto, y en
la Sección 4 se incluyen algunas discusiones. Finalmente, en la Sección 5 se añaden
unas conclusiones y se comentan las líneas de trabajo futuro.
2 Estado del Arte
En esta sección se analizan una serie de soluciones que, al igual que la propuesta
en este trabajo, se centran en mejorar la calidad del software mediante el uso de
procesos RV. El primer ejemplo es RAVEN [9], un framework para la validación de
propiedades de accesibilidad en GUIs Java. Se trata de un inspector de propiedades
que valida mientras la aplicación está siendo usada. RAVEN posee un conjunto de
reglas asociadas a cada tipo Java definidas en un lenguaje propio basado en XML.
Otras soluciones utilizan lógicas formales para validar propiedades. Barringer et
al. describen en [2] un framework general para monitorizado de propiedades sin
estado (no almacena la traza de ejecución) basado en la lógica EAGLE. MaCS [12] es
otra herramienta cuyo objetivo es corregir el comportamiento del sistema en tiempo
de ejecución. Utiliza un filtro de eventos (cambios en la aplicación); cada uno de los
eventos está ligado a una serie de propiedades que deben ser validadas. Las
validaciones pueden implicar acciones para corregir el comportamiento de la
aplicación. En [26] Zee et al. describen una solución que combina validación estática
y en tiempo de ejecución basada en Jahob. Jahob utiliza fórmulas de alto orden
lógico (HOL) que son comprobadas constantemente en tiempo de ejecución como si
de un invariante se tratara. RuleR y LogScope son otros dos sistemas basados en
reglas propuestos por Barringuer et al. en [3]. El primero utiliza reglas single-shot
(escritas en lógicas temporales) que operan sobre una colección de estados. El
segundo es una derivación de RuleR en la que la especificación está basada en
patrones de alto nivel que internamente son traducidos a un autómata.
En [5] Chen y Rosu presentan MOP, un framework que genera monitores
encargados de comprobar ciertas restricciones sobre las propiedades seleccionadas.
Éstos son posteriormente integrados en el código de la aplicación. Para realizar las
comprobaciones, MOP utiliza instantáneas del estado de la aplicación extraídas en
tiempo de ejecución, llamadas “eventos”. En dicho trabajo hacen referencia a
soluciones como Tracematches [1] (Alian et al.) y J-LO [4] (Bodden), las cuales usan
pointcuts de AspectJ [6] para disparar la ejecución de pequeñas piezas de código que
validan propiedades. Por último, Falcone et al. describen en [8] unos monitores
especiales para modificar propiedades en tiempo de ejecución, llamados Enforcement
Monitors. En caso de que la comprobación de ciertas reglas no tenga éxito, dichos
monitores corrigen el error para que el flujo de ejecución no se desvíe del
comportamiento deseado. Estos monitores están basados en el Autómata de
Seguridad (Schneider [25]) y el Autómata de Edición (Ligatti et al. [13]).
En trabajos anteriores se propuso el Open HMI Tester [15,20], un framework
abierto y adaptable para el desarrollo de herramientas de pruebas. Este framework es
capaz de extraer la información incluida en los eventos GUI generados por la
interacción del usuario utilizando introspección no intrusiva. Como resultado se
presentó un prototipo de código abierto para el sistema de ventanas Qt [24], que fue
implantado con éxito en escenarios industriales. En [16,21,20] se presentó una
solución para generar automáticamente casos de prueba sobre GUIs. Para ello se
utilizaban anotaciones que incluían, para cada elemento relevante de la GUI, los
valores soportados y ciertas reglas de validación asociadas a esos valores.
3 Proceso de Verificación de Datos Orientado a Aspectos
Las GUIs se usan básicamente para la introducción de datos y para que el sistema
muestre los resultados. En ambos casos los datos deberían ser verificados para evitar
efectos no deseados, y también para comprobar su coherencia y consistencia.
Tradicionalmente las comprobaciones suelen realizarse en la lógica de aplicación, y
más raramente en el código de los widgets. En la primera, las reglas se incluyen en el
código de los métodos manejadores, empeorando la legibilidad del código, y por tanto
los procesos de depuración y mantenimiento. En la otra, las reglas están en la propia
especificación de la GUI, cuando deberían estar en el controlador. Además, la gestión
de un flujo de log único para verificación suele ser compleja en ambos enfoques.
Fig. 1: Vista general de la Capa de Verificación
3.1 Propuesta de Verificación como un Aspecto Separado del Software
El enfoque propuesto en este artículo describe un framework abierto y adaptable que
despliega una capa de verificación entre la GUI y la lógica de aplicación (Figura 1).
Esta capa representa un elemento independiente dentro del software capaz de analizar,
dinámicamente y de forma transparente, el flujo de eventos GUI generado por la
interacción del usuario y la lógica. Como se aprecia en la Figura 2, ese análisis
permite detectar los cambios realizados en la GUI. Una vez identificado el elemento
modificado, se buscan sus reglas de verificación, las cuales representan los requisitos
asociados a dicho elemento. Luego, éstas se comprueban sobre el estado actual de la
GUI para asegurar que todos los requisitos se cumplen. Si todas las reglas se cumplen,
el evento continúa el flujo normal hacia la lógica de aplicación para ser manejado. En
caso contrario, la Capa de Verificación responde con el comportamiento adecuado
(e.g. mostrar un mensaje, colorear el elemento, sugerir el formato esperado, etc.)
Podemos diferenciar entre verificación top-down (intercepta los cambios realizados
por el usuario para evitar entradas inválidas) y bottom-up (comprueba si los valores
establecidos por la lógica de aplicación en la GUI también son correctos). Además,
esta técnica es dinámica y permanente, ya que las reglas son comprobadas en tiempo
de ejecución como si se trataran de un invariante en Diseño por Contrato [18]. Esta
solución también está basada en el concepto AOSD, ya que el proceso de verificación
se trata y gestiona como un aspecto aparte dentro de la propia aplicación. Por último,
esta solución no utiliza un modelo joint-point como los lenguajes orientados a
aspectos (AOP) más utilizados [6,7], sino que es no intrusiva en código.
Fig. 2: Funcionamiento de la verificación top-down
En la Figura 3 podemos ver un ejemplo real de verificación hacia abajo. El usuario
establece el valor del campo Buffer Size a 25, el cual sólo soporta valores enteros
menores o iguales que 20. Al abandonar dicho campo se genera un evento Focus Lost,
el cual es interceptado por la Capa de Verificación. Una vez interceptado, se buscan
las reglas asociadas al elemento y se comprueban sobre el estado actual de la GUI.
Tras la comprobación (en este caso hay un error), se actualiza el fichero de log de
verificación y se llevan a cabo las intervenciones GUI necesarias. En este caso, se
establece un valor por defecto (i.e. 0) y se decora con color rojo para indicar el error.
Fig. 3: Ejemplo real de verificación top-down
3.2 Las reglas de verificación
Las reglas representan los requisitos SRS referentes a los valores de entrada/salida.
Éstas pueden ser simples y hacer referencia a un sólo elemento (e.g. “w1.value >=
10”), o complejas, las cuales hacen referencia a más de un elemento y además pueden
incluir estructuras de control de flujo, funciones, etc. (e.g. “if (w1.selectedIndex() ==
2) then w2.isEmpty() == false”). Para definirlas es necesario un lenguaje que dé a los
desarrolladores flexibilidad suficiente para representar fielmente todos los requisitos.
Por esto, la solución propuesta no está ligada a ningún lenguaje en concreto, y son los
propios desarrolladores los que eligen el lenguaje utilizar (e.g. lenguajes de
restricciones como OCL [22], de script como Ruby [17] o JavaScript [19], etc.)
Ya que la solución propuesta es orientada a aspectos, se utilizan ficheros externos
para separar las reglas del código fuente. Así, las reglas relacionadas se incluirían en
el mismo fichero, y el resto en ficheros diferentes. De esta manera se aumenta la
encapsulación y modularidad, facilitando la reutilización de la especificación de
verificación. Además, facilita la realización de otros procesos tales como la
depuración o la auditoría. Usar ficheros externos para las reglas también permite
cambiar la especificación de verificación en tiempo de ejecución, muy útil durante el
Proceso de Desarrollo. Por ejemplo, durante la fase de pruebas, los desarrolladores
podrían cambiar o ajustar las reglas sin necesidad de recompilar ni de volver a lanzar
la aplicación. Otro ejemplo sería el de cambiar la especificación completa en caso de
que aparezca un nuevo diálogo en la GUI, cambie el estado de la aplicación, etc.
La Figura 4 representa el proceso de carga de reglas, las cuales se obtienen a partir
de los ficheros facilitados por los desarrolladores (o los propios usuarios). Éstas deben
ser cargadas al lanzar la aplicación, y actualizadas cada vez que alguno de estos
ficheros cambie. Después, los elementos GUI se registran en la Capa de Verificación
para que puedan ser verificados. Finalmente, en la fase de enlace, se decide qué reglas
deberán ser comprobadas cuando se interactúa con un elemento concreto de la GUI.
Fig. 4: Proceso de carga de reglas
4 Discusiones
La solución propuesta describe un entorno para diseñar, implementar, probar, y
desplegar una solución completa de verificación en un software. Además, las técnicas
de Intervención GUI mejoran la experiencia del usuario, ofreciendo un proceso de
verificación más rico e interactivo. Tras las pruebas realizadas, se ha observado un
coste computacional despreciable ( 0.3ms/acción); además, se utilizan los intervalos
de tiempo existentes entre las acciones que componen la interacción del usuario.
Su naturaleza orientada a aspectos hace que la solución propuesta sea no invasiva e
independiente del código. La separación lógica entre código y reglas permite una
mayor encapsulación y modularidad. Por una parte se mejora la legibilidad del
código, facilitando los procesos de desarrollo y depuración. Por otra, mejora la
eficiencia en los procesos que trabajan con las reglas, y mejora su reutilización. El
hecho de que las reglas puedan ser modificadas en tiempo de ejecución es otra ventaja
interesante de este modelo. Finalmente, poder utilizar lenguajes de script proporciona
a los desarrolladores una gran flexibilidad al especificar las reglas.
Otro beneficio inherente parte de la necesidad de trabajar en profundidad, y desde
el inicio del proceso de desarrollo, en el análisis de requisitos. Esto permitiría detectar
posibles errores no detectados previamente en la fase de análisis, mejorando así la
especificación de requisitos (SRS) y el propio diseño de la GUI [10] desde el inicio.
Entre sus principales limitaciones, la desestructuración de los requisitos (reglas), la
imposibilidad de establecer todos los requisitos (e.g. los que dependen de valores
almacenados en BBDD), y las limitaciones de los módulos de intervención GUI.
5 Conclusiones y Trabajo Futuro
La verificación de la entrada es un elemento esencial y crítico dentro del Proceso
de Desarrollo Software. Por eso, se propone un framework abierto y adaptable que
describe una capa de verificación situada entre la GUI y la lógica de aplicación.
Esta solución AOSD se integra fácilmente en un software, y trabaja en paralelo
mientras la aplicación está en ejecución. La lógica de verificación es transparente, y
las reglas se incluyen en ficheros separados. Este framework permite implementar una
solución completa de verificación que convierte al proceso en una parte integral de las
etapas de desarrollo, pruebas, y ejecución del software. Además, su carácter abierto
no lo restringe a ningún sistema de ventanas o lenguaje de verificación concretos.
Nuestro siguiente objetivo es encontrar un framework más general (no sólo para
verificación) pasando de un modelo (Evento GUI Comprobación de Reglas) a un
modelo (Elemento GUI + Evento GUI Acción). Esto facilitaría la implementación
ágil de soluciones GUI orientadas a aspectos, por ejemplo el Prototipado Rápido de
GUIs, GUI Mocking Ágil, procesos de GUI Logging & Auditing, Software Adaptable,
etc., o incluso para usarlo como un nuevo modelo de desarrollo donde la definición de
la GUI y los métodos manejadores están separados y son intercambiables.
Agradecimientos
Este trabajo ha sido parcialmente financiado por la Cátedra SAES de la Universidad
de Murcia (http://www.um.es/catedrasaes). Este acuerdo engloba un esfuerzo
conjunto entre la empresa SAES (Sociedad Anónima Electrónica Submarina
(http://www.electronica-submarina.com) y la Universidad de Murcia, para trabajar en
software de código abierto y en sistemas de tiempo real y aplicaciones críticas.
Referencias
[1] Allan, C., Avgustinov, P., Christensen, A. S., Hendren, L. J., Kuzins, S., Lhotak, O., de Moor, O.,
Sereni, D., Sittampalam, G., and Tibble, J. Adding trace matching with free variables to AspectJ. In
OOPSLA (2005), R. Johnson and R. P. Gabriel, Eds., ACM, pp. 345–364.
[2] Barringer, H., Goldberg, A., Havelund, K., and Sen, K. Rule-based Runtime Verification. Verification,
Model Checking, and Abstract Interpretation (2004), Springer, pp. 44–57.
[3] Barringer, H., Havelund, K., Rydeheard, D. E., and Groce, A. Rule systems for runtime verification:
A short tutorial. In RV (2009), Bensalem and Peled, Eds., vol. 5779 LNCS, Springer, pp. 1–24.
[4] Bodden, E. J-LO-A tool for runtime-checking temporal assertions. In AOSD’08: Proceedings of the 7th
international conference on Aspect-oriented software development (2008), ACM, pp. 36–47.
[5] Chen, F., and Rosu, G. Mop: an efficient and generic runtime verification framework. In OOPSLA ’07:
Proceedings of the 22nd annual ACM SIGPLAN conference on Object-oriented programming systems
and applications (New York, NY, USA, 2007), ACM, pp. 569–588.
[6] Xerox Corp., AspectJ: The Aspect-Oriented language for Java. http://www.eclipse.org/aspectj/, 2010.
[7] Olaf Spinczyk et al,AspectC++: The Aspect-Oriented language for C++. http://www.aspectc.org/, 2010.
[8] Falcone, Y., Fernandez, J., and Mounier, L. Runtime Verification of safety-progress properties. In RV
(2009), S. Bensalem and D. Peled, Eds., vol. 5779 of LNCS, Springer, pp. 40–59.
[9] Feigenbaum, B., and Squillace, M. Accessibility validation with raven. In WoSQ ’06: Proceedings of
the 2006 international workshop on Software quality (New York, NY, USA, 2006), ACM, pp. 27–32.
[10] Hayes, J. H., and Offutt, J. Input validation analysis and testing. Empirical Software Engineering 11, 4
(2006), 493–522.
[11] Ierusalimschy, R. et al. Lua - The Programming Language. http://www.lua.org/, 2010.
[12] Kima, M., Leeb, I., Sammapunb, U., Shinb, J., and Sokolskyb, O. Monitoring, checking, and steering
of real-time systems. In RV’02, (FLoC Satellite Event) (December 2002), vol. 70, Elsevier, pp. 95–111.
[13] Ligatti, J., Bauer, L., and Walker, D. Enforcing non-safety security policies with program monitors. In
ESORICS (2005), Vimercati, Syverson, and Gollmann, Eds., vol. 3679 of LNCS, Springer, pp. 355–373.
[14] Liu, H., and Tan, H. B. K. Covering code behavior on input validation in functional testing.
Information and Software Technology 51, 2 (2009), 546 – 553.
[15] Mateo, P., Sevilla, D., and Martínez G., Open HMI Tester: An Open and Cross-Platform Architecture
for GUI Testing and Certification, in press. JCSSE (The International Joint Conference on Computer
Science and Software Engineering) Special Issue on Open Source Certification (February 2009).
[16] Mateo, P., Sevilla, D., and Martínez, G. A Proposal for Automatic Testing of GUIs Based on
Annotated Use Cases. Advances in Software Engineering 2010, 671284 (2010).
[17] Matsumoto, Y. The Ruby Scripting Language. http://www.ruby-lang.org/, 2010.
[18] Meyer, B. Applying ”design by contract”. Computer 25, 10 (1992), 40–51.
[19] Sun Microsystems. JavaScript Scripting Language. http://developers.sun.com/javascript/, 2010.
[20] Mateo, P., Martínez, G., and Sevilla, D. Open HMI Tester: un Framework Open-source para
Herramientas de Pruebas de Software. Actas de los Talleres de las Jornadas de Ingeniería del Software y
Bases de Datos 3, 4 (2009).
[21] Mateo, P., Martínez, G., and Sevilla, D. Automated GUI Testing Validation Guided by Annotated Use
Cases. In GI Jahrestagung (2009), Fischer, Maehle, and Reischuk, Eds., vol. 154 of LNI, pp. 2796–2804.
[22] Object Management Group. Object Constraint Language (OCL), version 2.0, OMG document
formal/2006-05-01, 2006. http://www.omg.org/spec/OCL/2.0/.
[23] IEEE. IEEE 1012-2004 - ieee standard for software verification and validation. IEEE, IEEE, pp. 0-
110. Revision of IEEE Std 1012-1998.
[24] Cátedra SAES of the University of Murcia, OpenHMI-Tester Prototype.
http://sourceforge.net/projects/openhmitester/, 2009.
[25] Schneider, F. B. Enforceable security policies. ACM Trans. Inf. Syst. Secur. 3, 1 (2000), 30–50.
[26] Zee, K., Kuncak, V., Taylor, M., and Rinard, M. C. Runtime checking for program verification. In
RV (2007), O. Sokolsky and S. Tasiran, Eds., vol. 4839 of LNCS, Springer, pp. 202–213.
Thesis
Full-text available
1 Introduction 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1 Human-Computer Interaction . . . . . . . . . . . . . . . . . . . . 2 1.1.2 Software Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.3 Data Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1.4 Software Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1.5 Quality of Experience . . . . . . . . . . . . . . . . . . . . . . . . . 10 Enhancing Software Quality . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2.1 Block 1: Achieving Quality in Interaction Components Separately . 12 1.2.2 Block 2: Achieving Quality of User-System Interaction as a Whole . 14 1.3 Goals of this PhD Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.4 Publications Related to this PhD Thesis . . . . . . . . . . . . . . . . . . . . 19 1.5 Software Contributions of this PhD Thesis . . . . . . . . . . . . . . . . . . 22 1.5.1 OHT: Open HMI Tester . . . . . . . . . . . . . . . . . . . . . . . . 23 1.5.2 S-DAVER: Script-based Data Verification . . . . . . . . . . . . . . 24 1.5.3 PALADIN: Practice-oriented Analysis and Description of Multi-modal Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 CARIM: Context-Aware and Ratings Interaction Metamodel . . . . 25 1.6 Summary of Research Goals, Publications, and Software Contributions . . 25 1.7 Context of this PhD Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.8 Structure of this PhD Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2 Related Work 2.1 Group 1: Approaches Assuring Quality of a Particular Interaction Component 30 2.2 Validation of Software Output . . . . . . . . . . . . . . . . . . . . 30 2.1.1.1 Methods Using a Complete Model of the GUI . . . . . . 31 2.1.1.2 Methods Using a Partial Model of the GUI . . . . . . . . 32 2.1.1.3 Methods Based on GUI Interaction . . . . . . . . . . . . 32 Validation of User Input . . . . . . . . . . . . . . . . . . . . . . . . 33 2.1.2.1 Data Verification Using Formal Logic . . . . . . . . . . . 34 2.1.2.2 Data Verification Using Formal Property Monitors . . . . 35 2.1.2.3 Data Verification in GUIs and in the Web . . . . . . . . . 36 Group 2: Approaches Describing and Analyzing User-System Interaction as a Whole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.2.1 Analysis of User-System Interaction . . . . . . . . . . . . . . . . . 37 2.2.1.1 Analysis for the Development of Multimodal Systems . . 37 2.2.1.2 Evaluation of Multimodal Interaction . . . . . . . . . . . 41 2.2.1.3 Evaluation of User Experiences . . . . . . . . . . . . . . 44 Analysis of Subjective Data of Users . . . . . . . . . . . . . . . . . 45 2.2.2.1 User Ratings Collection . . . . . . . . . . . . . . . . . . 45 2.2.2.2 Users Mood and Attitude Measurement . . . . . . . . . . 47 Analysis of Interaction Context . . . . . . . . . . . . . . . . . . . . 49 2.2.3.1 Interaction Context Factors Analysis . . . . . . . . . . . 49 2.2.3.2 Interaction Context Modeling . . . . . . . . . . . . . . . 50 3 Evaluating Quality of System Output 3.1 Introduction and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.2 GUI Testing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.3 Preliminary Considerations for the Design of a GUI Testing Architecture . 57 3.3.1 Architecture Actors . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.3.2 Organization of the Test Cases . . . . . . . . . . . . . . . . . . . . 57 3.3.3 Interaction and Control Events . . . . . . . . . . . . . . . . . . . . 58 The OHT Architecture Design . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.4.1 The HMI Tester Module Architecture . . . . . . . . . . . . . . . . 60 3.4.2 The Preload Module Architecture . . . . . . . . . . . . . . . . . . . 61 3.4.3 The Event Capture Process . . . . . . . . . . . . . . . . . . . . . . 63 3.4.4 The Event Playback Process . . . . . . . . . . . . . . . . . . . . . . 64 The OHT Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.5.1 Implementation of Generic and Final Functionality . . . . . . . . . 66 3.5.1.1 Generic Data Model . . . . . . . . . . . . . . . . . . . . 66 3.5.1.2 Generic Recording and Playback Processes . . . . . . . . 66 Implementation of Specific and Adaptable Functionality . . . . . . 67 3.5.2.1 Using the DataModelAdapter . . . . . . . . . . . . . . . 68 3.5.2.2 The Preloading Process . . . . . . . . . . . . . . . . . . . 68 3.5.2.3 Adapting the GUI Event Recording and Playback Processes 69 3.7 Technical Details About the OHT Implementation . . . . . . . . . 70 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3.6.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.6.2 The Test Case Generation Process . . . . . . . . . . . . . . . . . . 73 3.6.3 Validation of Software Response . . . . . . . . . . . . . . . . . . . 74 3.6.4 Tolerance to Modifications, Robustness, and Scalability . . . . . . . 75 3.6.5 Performance Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 76 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4 Evaluating Quality of Users Input 4.1 Introduction and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.2 Practical Analysis of Common GUI Data Verification Approaches . . . . . 82 4.3 Monitoring GUI Data at Runtime . . . . . . . . . . . . . . . . . . . . . . . 83 4.4 Verification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.4.1 Rule Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.4.2 Using the Rules to Apply Correction . . . . . . . . . . . . . . . . . 87 4.4.3 Rule Arrangement . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.4.4 Rule Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.4.4.1 88 Loading the Rules . . . . . . . . . . . . . . . . . . . . . xviiContents 4.4.4.2 Evolution of the Rules and the GUI . . . . . . . . . . . . 89 Correctness and Consistency of the Rules . . . . . . . . . . . . . . 90 4.5 The Verification Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.6 S-DAVER Architecture Design . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.6.1 Architecture Details . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.6.2 Architecture Adaptation . . . . . . . . . . . . . . . . . . . . . . . . 94 4.7 S-DAVER Implementation and Integration Considerations . . . . . . . . . 95 4.8 Practical Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.8.1 Integration, Configuration, and Deployment of S-DAVER . . . . . 99 4.8.2 Defining the Rules in Qt Bitcoin Trader . . . . . . . . . . . . . . . 100 4.8.3 Defining the Rules in Transmission . . . . . . . . . . . . . . . . . . 103 4.8.4 Development and Verification Experience with S-DAVER . . . . . 106 4.9 Performance Analysis of S-DAVER . . . . . . . . . . . . . . . . . . . . . . 106 4.10 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.10.1 A Lightweight Data Verification Approach . . . . . . . . . . . . . 108 4.10.2 The S-DAVER Open-Source Implementation . . . . . . . . . . . . . 110 4.10.3 S-DAVER Compared with Other Verification Approaches . . . . . . 111 4.11 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 5 Modeling and Evaluating Quality of Multimodal User-System Interaction 115 5.1 Introduction and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 116 5.2 A Model-based Framework to Evaluate Multimodal Interaction . . . . . . . 118 5.2.1 Classification of Dialog Models by Level of Abstraction . . . . . . 119 5.2.2 The Dialog Structure . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.2.3 Using Parameters to Describe Multimodal Interaction . . . . . . . 121 5.2.3.1 Adaptation of Base Parameters . . . . . . . . . . . . . . 121 5.2.3.2 Defining new Modality and Meta-communication Param- eters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.2.3.3 Defining new Parameters for GUI and Gesture Interaction 123 5.2.3.4 Classification of the Multimodal Interaction Parameters . 124 5.3 Design of PALADIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.4 Implementation, Integration, and Usage of PALADIN . . . . . . . . . . . . 129 5.5 Application Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 5.6 Assessment of PALADIN as an Evaluation Tool . . . . . . . . . . . 132 5.5.1.1 Participants and Material . . . . . . . . . . . . . . . . . 134 5.5.1.2 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5.5.1.3 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . 137 Usage of PALADIN in a User Study . . . . . . . . . . . . . . . . . 140 5.5.2.1 Participants and Material . . . . . . . . . . . . . . . . . 140 5.5.2.2 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 144 5.5.2.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 5.6.1 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 146 5.6.2 Practical Application of PALADIN . . . . . . . . . . . . . . . . . . 147 5.6.3 Completeness of PALADIN According to Evaluation Guidelines . . 148 5.6.4 Limitations in Automatic Logging of Interactions Parameters . . . 151 5.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 5.8 Parameters Used in PALADIN . . . . . . . . . . . . . . . . . . . . . . . . . 152 6 Modeling and Evaluating Mobile Quality of Experience 163 6.1 Introduction and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 164 6.2 Context- and QoE-aware Interaction Analysis . . . . . . . . . . . . . . . . 166 6.2.1 Incorporating Context Information and User Ratings into Interaction Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 6.2.2 Arranging the Parameters for the Analysis of Mobile Experiences . 168 6.2.3 Using CARIM for QoE Assessment . . . . . . . . . . . . . . . . . . 169 Context Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 6.3.1 Quantifying the Surrounding Context . . . . . . . . . . . . . . . . 170 6.3.2 Arranging Context Parameters into CARIM . . . . . . . . . . . . . 173 User Perceived Quality Parameters . . . . . . . . . . . . . . . . . . . . . . 173 6.4.1 Measuring the Attractiveness of Interaction . . . . . . . . . . . . . 173 6.4.2 Measuring Users Emotional State and Attitude toward Technology Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 6.5 Arranging User Parameters into CARIM . . . . . . . . . . . . . . . 177 CARIM Model Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 6.5.1 The Base Design: PALADIN . . . . . . . . . . . . . . . . . . . . . 177 6.5.2 The New Proposed Design: CARIM . . . . . . . . . . . . . . . . . 178 6.6 CARIM Model Implementation . . . . . . . . . . . . . . . . . . . . . . . . 181 6.7 Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 6.7.1 Participants and Material . . . . . . . . . . . . . . . . . . . . . . . 183 6.7.2 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 6.7.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 6.9 Comparing the Two Interaction Designs for UMU Lander 185 Validating the User Behavior Hypotheses . . . . . . . . . 186 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 6.8.1 Modeling Mobile Interaction and QoE . . . . . . . . . . . . . . . . 188 6.8.3 CARIM Implementation and Experimental Validation . . . . . . . 190 CARIM Compared with Other Representative Approaches . . . . . 191 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 7 Conclusions and Further Work 7.2 Conclusions of this PhD Thesis . . . . . . . . . . . . . . . . . . . . . . . . 196 7.1.2 Driving Forces of this PhD Thesis . . . . . . . . . . . . . . . . . . 196 Work and Research in User-System Interaction Assessment . . . . 197 7.1.3 Goals Achieved in this PhD Thesis . . . . . . . . . . . . . . . . . . 200 Future Lines of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Bibliography 205 A List of Acronyms 231
Conference Paper
This paper is a position paper of my PhD thesis: https://www.researchgate.net/publication/264194567_Enhancing_Software_Quality_and_Quality_of_Experience_through_User_Interfaces With this work we expect to provide the community and the industry with a solid basis for the development, integration, and deployment of software testing tools. As a solid basis we mean, on one hand, a set of guidelines, recommendations, and clues to better comprehend, analyze, and perform software testing processes, and on the other hand, a set of robust software frameworks that serve as a starting point for the development of future testing tools.
Article
Full-text available
Software testing is usually used to report and/or assure about the quality, reliability and robustness of a software in the given context or scenario where it is intended to work. This is specially true in the case of user interfaces, where the testing phase is critical before the software can be accepted by the final user and put in execution mode. This paper presents the design, and the later implementation as a contribution to the open-source community, of a Human-Machine Interface (HMI) testing architecture, named OpenHMI-Tester. The current design is aimed to support major event-based and open-source windowing systems, thus providing generality, besides some other features such as scalability and tolerance to modifications in the HMI design process. The proposed architecture has been also integrated as part of a complex industrial scenario, which helped to identify a set of realistic requirements of the testing architecture, as well as to test it with real HMI developers.
Article
Full-text available
The MaC system has been developed to provide assurance that a target program is running correctly with respect to formal requirements specification. This is achieved by monitoring and checking the execution of the target program at run-time. MaC bridges the gap between formal verification, which ensures the correctness of a design rather than an implementation, and testing, which only partially validates an implementation. One weakness of the MaC system is that it can detect property violations but cannot provide any feedback to the running system. To remedy this weakness, the MaC system has been extended with a feedback capability. The resulting system is called MaCS (Monitoring and Checking with Steering). The feedback component uses the information collected during monitoring and checking to steer the application back to a safe state after an error occurs. We present a case study where MaCS is used in a control system that keeps an inverted pendulum upright. MaCS detects faults in controllers and performs dynamic reconfiguration of the control system using steering.
Article
Full-text available
Testing is, for most, a necessary evil in the software life cycle. One very important form of testing is the evaluation of software products according to mandated criteria or guidelines such as those that specify level of accessibility. Such evaluations can be quite tedious, especially if they must be done manually and applied consistently to each and every component of an application. The use of assistive technologies like screen readers to demonstrate the compliance of a software product to a set of regulations is time-consuming, error-prone, and expensive. Validation tools that can perform such evaluations are becoming more popular as integrated development environments become more sophisticated but, in the area of accessibility validation, they are sorely lacking if not nonexistent. This paper introduces the IBM Rule-based Accessibility Validation Environment, an Eclipse-based tool for inspecting and validating Java rich-client GUIs for accessibility using non-invasive, semi-to fully-automatic, rule-based validation and inspection.
Conference Paper
Full-text available
We present a rule-based framework for defining and implementing finite trace monitoring logics, including future and past time temporal logic, extended regular expressions, real-time logics, interval logics, forms of quantified temporal logics, and so on. Our logic, Eagle, is implemented as a Java library and involves novel techniques for rule definition, manipulation and execution. Monitoring is done on a state-by-state basis, without storing the execution trace.
Article
An abstract is not available.
Article
Input validation is the enforcement built in software systems to ensure that only valid input is accepted to raise external effects. It is essential and very important to a large class of systems and usually forms a major part of a data-intensive system. Most existing methods for input validation testing are specification-based. However, to test input validation more accurately, a code-based method is also required. In this paper, we propose an approach to extract path partition and input conditions from code for testing input validation. The path partition can be used to design white-box test cases for testing input validation. It can also be used to measure the coverage of input validation testing. The valid and invalid input conditions recovered can be used to check against the specifications and aid the test suite design in black-box testing. We have also evaluated the proposed method through experimental study.