· Web viewEvaluación del sistema Tabla de contenido 1.Introducción3 2.Evaluación técnica3...

DYNUI: Capability and Context-aware Dynamic Adaptation of User Interfaces for Ambient Assisted Living (PC2012-73)

Evaluación del sistema


Tabla de contenido1. Introducción.....................................................................................................................3

2. Evaluación técnica............................................................................................................3

2.1. Evaluación de Pellet4Android.......................................................................................3

2.1.1. Pellet vs. Pellet4Android...........................................................................................4

2.1.2. Aumentando los axiomas ABox................................................................................4

2.1.3. Aumentando los axiomas SWRL...............................................................................5

2.2. Comparando DYNUI e Imhotep....................................................................................6

2.2.1. Caso de uso: AssistedCity.........................................................................................8

2.3. Identificación de patrones y cambios.........................................................................10

2.4. Evaluación de desarrolladores....................................................................................13

3. Evaluación de usuarios...................................................................................................16


1. IntroducciónEl presente documento contiene la descripción y los resultados del proceso de evaluación de la plataforma DYNUI. Las pruebas, divididas en 3 partes, se han realizado entre un total de 30 usuarios y 5 desarrolladores expertos en el desarrollo en aplicaciones Android y uso de semántica.

2. Evaluación técnicaLa evaluación técnica contiene diversas pruebas realizadas contra el sistema DYNUI, con el objetivo de medir las respuestas en cuanto a rendimiento cuantitativo y cualitativo. Estas pruebas se han realizado de la siguiente manera:

Midiendo la capacidad y rendimiento del motor de razonamiento Pellet4Android, el cual es parte fundamental del core de DYNUI.

Comparación con otras plataformas de adaptación de interfaces de usuario. En este caso se ha optado por utilizar Imhotep, un framework de desarrollo de interfaces de usuario adaptables desarrollada por la Universidad de Deusto.

Midiendo la capacidad del sistema para la detección de comportamientos habituales y su cambios. Para ello se ha contado con datos reales, tanto obtenidos en laboratorios de Mondragon Goi Eskola Politeknikoa, así como en otros entornos con usuarios reales.

Finalmente, se han realizado pruebas con un pequeño conjunto de desarrolladores. Mediante la presentación de las API correspondientes y de unas aplicaciones pre-desarrolladas se les solicita a los desarrolladores participantes que completen una serie de tareas, tanto de adaptación de las interfaces como de modificación del conocimiento representado en la ontología.

2.1.Evaluación de Pellet4AndroidLa evaluación del motor de razonamiento Pellet4Android se ha llevado a cabo en 3 fases diferentes:

El primero de los experimentos consiste en comparar el rendimiento de ambas versiones de Pellet. Esto es, se comparan las versiones de Pellet para Java y para Android (desarrollada para DYNUI).

Seguidamente se modifican los conjuntos de axiomas de la ontología diseñada para DYNUI. En primer lugar, se aumentan los axiomas pertenecientes al conjunto ABox. A continuación, los pertenecientes al conjunto.

Por último, se modifican los elementos pertenecientes al grupo de reglas SWRL para comprobar su impacto en el rendimiento de la plataforma.

Para las pruebas detalladas a continuación se han utilizado los siguientes dispositivos:

3


Tabla 1. Dispositivos utilizados en la evaluación.

2.1.1. Pellet vs. Pellet4AndroidEn esta sección se detallan los resultados obtenidos de la comparación directa entre ambas versiones de Pellet. Como se puede ver en la siguiente Tabla, el rendimiento de Pellet en su versión Java es mucho más potente. Esto se debe a la alta dependencia que existe en cuanto al hardware se refiere para ejecutar las tareas necesarias para el proceso de conocimiento representado de forma semántica.

Tabla 2. Resultados de rendimiento de Pellet y Pellet4Android.

2.1.2. Aumentando los axiomas ABoxEl conjunto ABox de axiomas representan y describen los atributos de las instancias de una ontología. Para este experimento se ha cogido la ontología por defecto de DYNUI y se ha modificado la cantidad de axiomas del conjunto ABox en 5.000, 10.000, 15.000 y hasta 20.000 instancias, con el objetivo de determinar el impacto que tiene este conjunto en el rendimiento final de la plataforma haciendo uso del motor Pellet4Android.

4


Tabla 3. Resultados aumentando axiomas de ABox.

En la tabla anterior se puede comprobar como el aumento del conjunto de axiomas pertenecientes a ABox lacra claramente el rendimiento de la plataforma Pellet4Android. En el caso del dispositivo menos potente de los utilizados (Samsung Galaxy SIII Mini) podemos comprobar como de un rendimiento medio de 36 segundos para el manejo de una ontología con 5.000 instancias, el rendimiento se dispara negativamente hasta alcanzar los 183 segundos de media. Obviamente, cabe destacar que en el caso de Pellet para Java las desviaciones son sumamente menores.

2.1.3. Aumentando los axiomas SWRLEn último lugar se ha incrementado el conjunto de axiomas SWRL de la ontología. Este conjunto almacena los axiomas relacionados con las reglas incluidas en la ontología base. De este modo, se ha incrementado este conjunto llegando a tener versiones de la ontología que alcanzan los 5.000, 10.000, 15.000 y 20.000 axiomas. El objetivo es comprobar y evaluar el comportamiento del motor Pellet4Android ante situaciones de estrés en cuanto a la carga de trabajo a la hora de procesar las reglas SWRL. La Tabla 4 muestra los resultados del experimento descrito utilizando las diferentes versiones de Pelley y las plataformas y dispositivos indicados previamente.

5


Tabla 4. Pellet y Pellet4Android utilizando diversas versiones de la ontología base modificando el conjunto de axiomas SWRL.

Como se puede observar el comportamiento de Pellet4Android es claramente inferior en cuanto a rendimiento en comparación con la versión oficial desarrollada en Java. Obviamente estas diferencias se acentúan según las especificaciones técnicas del hardware que utilicemos. Así, el dispositivo que menor rendimiento ha producido durante las pruebas ha sido el Galaxy SIII Mini, mientras que el Nexus 10 ha presentado los resultados más prometedores.

2.2.Comparando DYNUI e ImhotepImhotep es un framework de adaptación de interfaces de usuario orientado a desarrolladores diseñado y mantenido por la Universidad de Deusto. Su objetivo no es otro que el de ofrecer una herramienta sencilla para desarrolladores para facilitar el desarrollo de interfaces adaptables y más usables. Este framework permite a los desarrolladores diseñar aplicaciones sin implicarse directamente en el aspecto de la interfaz de usuario. Para ello, se provee al desarrollador de una serie de posibilidades en forma de directivas de preprocesador. Estas directivas se encargan principalmente de evaluar los perfiles del usuario y del dispositivo. La arquitectura de Imhotep se ilustra a continuación, en la Figura 1.

6


Figura 1. Arquitectura de Imhotep.

Las directivas de preprocesado definen el aspecto final del código fuente a generar, proveyendo condiciones para ciertas partes del propio código. El preprocesador de la arquitectura de Imhotep identifica estas directivas cuando empiezan por //# en los lenguajes de programación que permiten comentarios de línea que empiezan por //, como Java, C++ o C#, y por #// en lenguajes que soportan comentarios de línea que comienzan por #, como Pearl y Python. La Figura 2 ejemplifica una porción de código escrita por un desarrollador en Java. En esta porción se puede observar cómo se utilizan las sentencias IF, en cuyos encabezamientos se realizan las comprobaciones del dispositivo necesarias, y en cuyo cuerpo se hacen diferentes llamadas a diferentes métodos relacionados con la implementación de la interfaz de usuario. En tiempo de compilación, el preprocesador utilizará únicamente las llamadas al método que cumpla la condición en el encabezamiento de las sentencias IF.

Figura 2. Ejemplo de directivas de preprocesado en Imhotep.

En cuanto a las capacidades de usuario que se contemplan en Imhotep, el listado viene determinado por el esquema de la fuigura…

7


Figura 3. Capacidades de usuario contempladas en Imhotep.

2.2.1. Caso de uso: AssistedCityPara la comparación entre el sistema DYNUI e Imhotep se ha escogido un caso de uso ya desarrollado para la segunda opción. AssistedCity fue concebido como un demostrador de la capacidad de adaptación de la plataforma Imhotep. En este caso, el perfil de usuario y dispositivo viene dado por una serie de variables representadas en el documento de la Figura4.

Figura 4. Fichero de variables de usuario y dispositivo.

Por el contrario, en DYNUI los perfiles de usuario y dispositivo vienen determinados por la ontología. De este modo, los mismos perfiles serían representados de la forma indicada en la tabla…

8


Tabla 5. Perfil de usuario y dispositivo representados mediante la ontología de DYNUI.

La Figura 5 muestra la interfaz por defecto de la aplicación AssistedCity para un usuario sin discapacidades. Al ser el objetivo de la aplicación el guiado a través de la ciudad y el consumo de diversos puntos de interés (POI), la interfaz final se basa en una combinación de visualización de datos y realidad aumentada.

Figura 5. Interfaz por defecto de la aplicación AssistedCity.

A continuación se muestra a través de la Figura 6 las diferencias de adaptación entre ambas soluciones para usuarios y dispositivos con las características de la Figura 4. Fichero devariables de usuario y dispositivo.Figura 4 y la Tabla 5. En la parte izquierda se representa la adaptación resultante del uso de la plataforma Imhotep. Los parámetros descritos en la Figura4 para el usuario y el dispositivo son enviados al servidor de Imhotep. Éste se encarga de generar el código de la aplicación correspondiente y enviarlo de vuelta al dispositivo del usuario. Por el contrario, en la parte derecha de la imagen se puede contemplar la adaptación realizada por DYNUI, la cual se corresponde perfectamente con los detalles indicados en la ontología (descritos en la Tabla 5). Esta adaptación concuerda con estos parámetros, representando en mejor medida la especificación dada también en la Figura 4. Fichero devariables de usuario y dispositivo.Figura 4.

9


Figura 6. Interfaces generadas para AssistedCity por Imhotep (izquierda) y DYNUI (derecha).

En cuanto a los tiempos de respuesta y comportamiento de ambas soluciones, cabe destacar la problemática de la dependencia de Internet de Imhotep. A pesar de que se provee una caché para la adaptación, siempre corremos el riesgo de fallos en la red. La siguiente tabla muestra los tiempos medios utilizando la caché así como evitando su uso.

Tabla 6. Tiempos medios de respuesta de la plataforma Imhotep.

Por el contra, los tiempos medios de DYNUI se visualizan en la Tabla 7. Como se puede comprobar, el uso de la caché reduce el tiempo de respuesta del sistema a apenas 1 segundo, tiempo, mientras que la plataforma DYNUI necesita en torno a los 2 segundos para los dispositivos más lentos. Sin embargo, para nuevas adaptaciones el tiempo de respuesta de DYNUI no varía, mientras que para Imhotep los tiempos se disparan hasta los 15 segundos debido a la necesidad de recompilar todo el código fuente.

Tabla 7. Tiempos medios de respuesta de la plataforma DYNUI (abajo) frente a los tiempos de Imhotep (arriba).

2.3. Identificación de patrones y cambiosUno de los aspectos básicos de la plataforma DYNUI es su capacidad de identificar los patrones frecuentes de los usuarios, así como sus cambios, y adaptarse a ellos.

10


Para la evaluación de este módulo se han realizado dos tipos de pruebas:

Para ver su eficacia a la hora de descubrir patrones frecuentes, se ha diseñado un generador de datos donde se insertaban patrones frecuentes.

Para ver su rendimiento se ha contado con datos reales de usuarios reales, por una parte en el laboratorio de Mondragon Goi Eskola Politeknikoa, y por otra parte en un hogar.

En el primer caso, considerando los datos generados bajo el control, donde es más fácil determinar la eficacia del sistema, se puede afirmar que el algoritmo identificó el 100% de los patrones frecuentes. En el 86% de los casos fue capaz de la relación temporal entre acciones, y en el 67% de los casos las condiciones bajo los cuales ocurre el patrón.

Una vez validado la capacidad de encontrar patrones frecuente, se valido el rendimiento del sistema en un entorno real. Para la validación se han realizado diferentes testeos, sobre todo teniendo en cuenta el valor del parámetro “Confidence Level”, el cual determina lo que se exige para que un comportamiento sea identificado como frecuente. A continuación se muestran los resultados obtenidos en los diferentes testeos:

Se realizaron 3 diferentes testeos. Se identificaron patrones frecuentes, las relaciones temporales y las

condiciones. Se midió el tiempo que necesito el algoritmo para cada paso.

Tabla 8: Identificación de patrones

11

Trial 1 Trial 2 Trial 3

Confidence Level

Total Patterns Total Patterns Total Patterns

25% 8 (328 ms) 3 (5969 ms) 1 (200 ms)

50% 4 (141 ms) 1 (5422 ms) 1 (115 ms)

75% 1 (109 ms) 1 (718 ms) 1 (103 ms)

100 0 (35 ms) 0 (35 ms) 0 (35 ms)


Tabla 9: Patrones con relaciones temporales.

12


Confidence Level Total Patterns with Time Relations

Total Patterns with Time Relations

Total Patterns with Time Relations

25% 48 (86%)(844 ms)

43 (77%)(2071 ms)

No hay relaciones temporales

50% 18 (82%)(437 ms)

5 (71%)(1651 ms)


75% No hay relaciones temporales

5 (71%)(578 ms)


100 No hay relaciones temporales




Tabla 10: Patrones con condiciones

2.4.Evaluación de desarrolladoresDYNUI provee al desarrollador dos API. La primera de ellas, enfocada a la modificación del conocimiento de la ontología haciendo uso de los métodos correspondientes de OWL-API. La segunda, con el único objetivo de permitir una adaptación dinámica de la interfaz en cuestión. Para ello se han seleccionado a 5 programadores con conocimientos de Android y de semántica, a los cuales se les han presentado dos aplicaciones pre-desarrolladas con una serie de tareas por completar.

Para el primer caso, se ha utilizado una aplicación Java con las siguientes tareas:

Crear una clase. Crear una instancia de esa clase. Añadir una propiedad datatype a esa instancia. Añadir una propiedad de objeto a esa instancia. Crear una nueva regla SWRL.

La Figura 7 muestra parte de ese código:

13


Confidence Level Total Patterns with Conditions

Total Patterns with Conditions

Total Patterns with Conditions

25% 7 (70%)(500 ms)

6 (67%)(1015 ms)

No hay necesidad de condiciones

50% 2 (67%)(188 ms)

1 (50%)(1062 ms)


75% No hay necesidad de condiciones

1 (50%)(156 ms)


100 No hay necesidad de condiciones




Figura 7. Tarea de modicación del conocimiento de la ontología de DYNUI.

Por otro lado, para la adaptación dinámica de las interfaces se propone al usuario la modificación de los elementos listados en el siguiente trozo de código:

14


Figura 8. Adaptación de la interfaz en Android haciendo uso de la API de DYNUI.

Tras el uso de ambas API, los desarrolladores contestan al siguiente cuestionario:

15


Figura 9. Cuestionario al que son sometidos los desarrolladores participantes en la evaluación de las API de DYNUI.

La Tabla 6 y Tabla 7 muestran los resultados del cuestionario descrito anteriormente. En ellas podemos apreciar el gran nivel de aceptación de ambas API, y las propuestas realizadas por los desarrolladores en base a su experiencia personal.

Figura 10. Resultados del cuestionario (Parte I).

Figura 11. Resultado del cuestionario (Parte II).

3. Evaluación de usuariosPara la evaluación de usuarios se ha escogido a un número de 30 usuarios de distintas edades, experiencia tecnológica y discapacidad para una evaluación más exhaustiva de las posibles

16


carencias de la plataforma. Una vez realizada la prueba como usuarios, y en base a la adaptación resultante y la experiencia obtenida, se les presenta a los usuarios un cuestionario bajo el estándar SUS (System Usability Scale).

Las preguntas del SUS realizadas a los usuarios se pueden ver en detalle en la .

Figura 12. El cuestionario SUS.

El formato de respuestas para el cuestionario SUS viene determinado por una escala entre 1 y 5, siendo 1 el mayor negativo y 5 el mayor valor posible positivo. La siguiente figura muestra esta escala:

Figura 13. Formato SUS.

Para computar el resultado del cuestionario se han de aplicar una serie de reglas. A continuación se detalla el uso de las mismas:

Para las preguntas impares: se resta 1 a la puntuación dada. Para las preguntas pares: se resta de 5 la puntuación dada. Esto consigue una escala entre 0 y 4. Se suman los valores de cada respuesta del usuario en cuestión y se multiplica por 2.5,

convirtiendo el rango de valores en un número entre 0 y 100 en lugar de entre 0 y 40.

A continuación se muestra un ejemplo de respuesta del cuestionario SUS.

17


Figura 14. Ejemplo de cuestionario SUS completado por un usuario de ejemplo. Puntuación final = 22, Puntuación SUS = 22 * 2,5 = 55.

Además de las preguntas del SUS se han incluido también un conjunto de cuestiones para analizar los datos desde diferentes perspectivas. Estas preguntas segmentan a los usuarios de la siguiente forma:

Por rango de edad. Por nivel de experiencia tecnológica percibida por el propio usuario. Por nivel de discapacidad temporal o duradera percibida por el usuario, incluyendo

discapacidades visual y auditiva. Si el usuario tiene conocimientos de desarrollo.

A continuación se presentan los resultados obtenidos de la encuesta.

18


Figura 15. Resultados de la encuesta SUS.

Figura 16. Gráfico de respuestas SUS según el rango de edad.

19


Figura 17. Respuestas SUS según el nivel de experiencia tecnológica de los usuarios.

Figura 18. Respuestas SUS según la discapacidad apreciada por el usuario.

Para una mejor comprensión de los resultados a mostrar a continuación, las preguntas se han numerado de la siguiente forma:

20


Figura 19. Nomenclatura aplicada a las preguntas SUS para las siguientes tablas.

Tabla 11. Respuestas finales a las preguntas SUS.

21


Tabla 12. Respuestas a las preguntas adicionales.

22

· Web viewEvaluación del sistema Tabla de contenido 1.Introducción3 2.Evaluación técnica3...

Documents

Transcript of · Web viewEvaluación del sistema Tabla de contenido 1.Introducción3 2.Evaluación técnica3...