Mecanismos de Integración y Prueba de Herramientas Automáticas

Escuela Politécnica Superior
Universidad Autónoma de Madrid
Madrid, España
Mecanismos de Integración y Prueba de Herramientas Automáticas de
Evaluación de Calidad de Cursos Adaptativos.
Autor: Javier Bravo Agapito
Director: Alvaro Ortigosa
TRABAJO DE INICIACIÓN A LA INVESTIGACIÓN
Septiembre 2006
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Resumen
Los Sistemas Adaptativos en general y en especial los
orientados a la Enseñanza necesitan ser evaluados para conocer
el grado de su efectividad en la adaptación. Las herramientas de
evaluación son las encargadas de valorar la efectividad. En
concreto, las herramientas de evaluación basadas en el análisis
de los logs son las más usadas en la actualidad y utilizan
técnicas de Data Mining para detectar posibles fallos de
adaptación. Un importante desafío es valorar la efectividad de
estas herramientas de evaluación, es decir, hacer evaluación
sobre la evaluación. Se propone en este estudio tanto una
arquitectura como una herramienta de simulación de logs para
abordar este reto.
Javier Bravo Agapito
ii
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Agradecimientos
Este trabajo no hubiera sido posible sin el apoyo de mis padres, Gonzalo
y Nines, mis hermanos, Cristina, Carlos y Jorge, y por supuesto de mi
director Alvaro Ortigosa.
Este proyecto además ha sido parcialmente subvencionado por el MEC,
TIN2004-03140.
Javier Bravo Agapito
iii
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Tabla de Contenidos
Resumen..................................................................................................................................
.........ii
Agradecimientos...........................................................................................................................iii
Tabla de Contenidos......................................................................................................................iv
Índice de Figuras............................................................................................................................vi
Introducción....................................................................................................................................1
Estado de la cuestión......................................................................................................................4
1. La evaluación empírica........................................................................................................5
2. Evaluación por capas.........................................................................................................12
Objetivos y Metodología..............................................................................................................14
1. Objetivos................................................................................................................................14
2. Metodología..........................................................................................................................15
Arquitectura del sistema de evaluación...................................................................................17
Simulog: Sistema de Simulación de Usuarios..........................................................................22
1. Arquitectura.........................................................................................................................23
2. Entradas de simulación.....................................................................................................24
2.1. Descripción del curso.............................................................................................................24
2.2. Perfil del estudiante................................................................................................................24
2.3. Anomalías.................................................................................................................................26
3. Ontología de Anomalías.....................................................................................................27
4. Motor de simulación...........................................................................................................31
4.1. Generación de perfiles............................................................................................................31
4.2. Generación de modelos de usuario......................................................................................35
Conclusiones y Trabajo Futuro...................................................................................................38
Referencias Bibliográficas...........................................................................................................42
Javier Bravo Agapito
iv
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Apéndice..................................................................................................................................
.......46
I - Paper(s).................................................................................................................................47
II - Ejemplo de simulación.....................................................................................................62
III - Ontología...........................................................................................................................63
i - Fichero Ontologia.rdfs..............................................................................................................63
ii - Fichero Ontologia.rdf...............................................................................................................68
IV - Tabla de la distribución Normal(0,1)............................................................................75
Javier Bravo Agapito
v
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Índice de Figuras
Capítulo 4
Figura 1 Arquitectura de un sistema AEH................................................................................18
Figura 2 Arquitectura de un sistema AEH con evaluación....................................................19
Figura 3 Contexto de la herramienta de simulación..............................................................20
Capítulo 5
Figura 1 Arquitectura de Simulog..............................................................................................23
Figura 2 Simulog y el editor de atributos.................................................................................25
Figura 3 Simulog y el editor de anomalías...............................................................................26
Figura 4 Jerarquía de clases........................................................................................................27
Figura 5 Slots de la clase Criterion............................................................................................28
Figura 6 Ejemplo de instancia de la clase Criterion...............................................................29
Figura 7 Slots de la clase Property.............................................................................................30
Figura 8 Ejemplo de instancia de la clase Property................................................................30
Figura 9 Ejemplo de anomalía....................................................................................................31
Figura 10 Traslación de una N(5,2) a N(3.66, 2).......................................................................34
Javier Bravo Agapito
vi
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
CAPÍTULO 1
Introducción
Los Sistemas Hipermedia Adaptativos (Adaptive Hypermedia Systems – AHS) son sistemas que
proporcionan el acceso a contenidos a través de la Web, utilizando un modelo de usuario para
personalizar los contenidos mostrados a cada usuario. En los últimos años estos sistemas han
experimentado una gran proliferación debido fundamentalmente a la aparición de nuevas
tecnologías como por ejemplo lenguajes de programación específicos para aplicaciones Web (Java,
C#, PHP), nuevos dispositivos (PDAs, Smartphones) y protocolos de comunicación (SMS,
Bluetooth) [1]. En particular, los Sistemas Hipermedia Adaptativos orientados a la Enseñanza
(Adaptive Educational Hypermedia – AEH) utilizan un modelo de estudiante y, en base a unas
reglas de adaptación, consiguen personalizar el contenido de los cursos ofrecidos de acuerdo con
las características o aptitudes de cada estudiante. Las reglas de adaptación determinan que el
sistema muestre los contenidos adecuados para cada perfil, por ejemplo la regla destinada a los
usuarios con perfil secuencial causará que los contenidos se muestren de forma secuencial, es
decir, quitando al usuario la posibilidad de seleccionar la actividad que desee. En particular,
Paredes y Rodríguez [2] proponen modificar los tipos de reglas para adecuarlas al perfil del
estudiante, por ejemplo respecto a los usuarios secuenciales se sugiere cambiar las reglas de tipo
ANY (regla que permite a los usuarios elegir la siguiente actividad) por las de tipo AND (regla que
obliga a los usuarios a seguir una secuencia de actividades), y de esta manera cada actividad se le
presentará al estudiante de forma ordenada y sin posibilidad de que éste pueda elegir las
actividades que desea realizar.
Javier Bravo Agapito
1
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Actualmente estos sistemas son ampliamente aceptados por los usuarios, sin embargo, dicha
aceptación no es suficiente para valorar la efectividad de estos sistemas, sino que es necesario el
uso de técnicas de evaluación empírica. Contrario a lo que cabría esperar, el uso de estas técnicas
no es una práctica común como demuestra el estudio realizado por Chin (2001) [3], en el que se
expone que tan sólo un tercio de los sistemas adaptativos publicados en la revista UMUAI utilizan
algún tipo de evaluación. Además la evaluación de AHS es una tarea difícil y no exenta de
complejidad como muestran muchos estudios (Weibelzahl et al. [4], Missier et al. [5], Markham et
al. [6] y Lavie et al. [7], entre otros). Esto también es verdad en el caso de los AEH y en particular,
evaluar si un AEH está tomando las decisiones correctas en la adaptación para un determinado
estudiante es una tarea compleja, que puede ser mejorada si se usan herramientas automáticas.
Por ejemplo, una herramienta de evaluación puede ayudar a identificar posibles fallos en las
reglas de adaptación de un curso e incluso sugerir posibles correcciones orientadas a mejorar
dichas reglas [8]. En concreto, las herramientas de evaluación en las que se centra este estudio son
las que están basadas en el análisis de logs. Estas herramientas utilizan técnicas y métodos de Data
Mining [9] con el objetivo de encontrar comportamientos o patrones de comportamiento
anómalos de los estudiantes, es decir, comportamientos que pueden indicar problemas en la
adaptación. A estos patrones de comportamiento los denominaremos en adelante anomalías.
Un importante reto consiste en evaluar o valorar la efectividad de dichas herramientas. En este
sentido el problema consiste en comprobar si la herramienta de evaluación es capaz de detectar
las anomalías contenidas en los ficheros de logs. Para conseguir alcanzar este objetivo nos
encontramos ante dos problemas: necesitamos un amplio conjunto de logs de distintos
estudiantes y necesitamos además analizar de forma manual los logs. Es necesario un amplio
conjunto de datos porque satisface un doble objetivo: las técnicas utilizadas en Data Mining
requieren grandes volúmenes de datos, pues de otra forma las inferencias sobre los datos serían
erróneas, y obtener un amplio conjunto de interacciones de los estudiantes con el sistema, pues
de otra forma las conclusiones extraídas no podrían ser extrapolables a la población de
estudiantes. Además con el propósito de analizar los resultados obtenidos por la herramienta de
evaluación es necesario también realizar un análisis manual, por parte del evaluador o de otra
persona, que garantice que la herramienta detecta todas las anomalías existentes en los logs y
además que las anomalías detectadas son en verdad comportamientos o situaciones anómalas de
los estudiantes.
Javier Bravo Agapito
2
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Debido a que conseguir y evaluar un amplio conjunto de logs es una tarea compleja y costosa,
se propone en este trabajo el uso de métodos de simulación. En concreto, se propone usar una
herramienta para simular el comportamiento de los estudiantes mediante generación de ficheros
logs, que produciría ficheros similares a los que se obtendrían de la interacción de los estudiantes
con el sistema AEH. Por ejemplo, se podrían generar ficheros logs con anomalías, y comprobar si
la herramienta de evaluación mediante el análisis de estos ficheros es capaz de detectar estas
anomalías. Por tanto, el evaluador o diseñador del curso tiene el control de los datos que se
introducen en la herramienta de evaluación y puede de esta forma anticipar la salida esperada de
la herramienta de evaluación. La herramienta que se desarrolló para implementar esta
simulación es Simulog (Simulation of User Logs).
Javier Bravo Agapito
3
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
CAPÍTULO 2
Estado de la cuestión
El crecimiento que han experimentado en los últimos años los sistemas hipermedia
adaptativos ha sido debido principalmente a dos factores: la aparición de nuevas tecnologías y la
progresiva asimilación de los usuarios respecto a estos sistemas. En primer lugar, la aparición de
nuevas tecnologías ha hecho posible la expansión de estos sistemas tanto en el ámbito académico
como en otros ámbitos. Y en segundo lugar, hay un grado de asimilación de estos sistemas cada
vez mayor por parte de los usuarios, como demuestra la evolución que han experimentado los
sistemas adaptativos orientados a la enseñanza. Son ejemplos de estos sistemas TANGOW [10],
AHA! [11], INTERBOOK [12], WHURLE [13], NETCOACH [14], etc.
Sin embargo, es ampliamente aceptado que la evaluación de la efectividad de estos sistemas o
no se realiza de forma adecuada, o no se realiza en absoluto. Un estudio realizado por Chin [3]
muestra que tan sólo un tercio de de los artículos de sistemas adaptativos publicados en la revista
UMUAI contienen algún tipo de evaluación. Además este porcentaje es incluso menor, ya que
varios presentan en la evaluación sólo resultados preliminares; otros ni siquiera utilizan grupos
de control; y algunos no incluyen suficientes participantes para producir resultados estadísticos
significativos. Finalmente Chin concluye que alrededor de un cuarto de los artículos contenidos
en la revista UMUAI1 presentan evaluaciones empíricas significativas. Otro estudio realizado por
1 La revista UMUAI (User Modeling and User-Adapted Interaction) ha sido publicada desde 1991, y basada
en el factor de impacto ISI es una de las revistas más importantes en los últimos años. Las últimas
investigaciones sobre sistemas adaptativos se pueden encontrar en esta revista.
Javier Bravo Agapito
4
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Weibelzahl [15], presenta resultados similares, ya que sólo 14 de los 43 artículos analizados en el
período 1997-1999 en UMUAI incluyen el uso de análisis estadísticos. No obstante, actualmente
las perspectivas sobre la evaluación empírica son mejores, ya que los artículos de UMUAI que
incluyen evaluaciones empíricas en el período 1997-2001 son el casi el doble que los artículos de
cuatro años anteriores a dicho período. Además en los últimos años (2001-2005) se ha producido
un incremento en el uso de la evaluación en los sistemas adaptativos, como demuestran los
Workshops sobre evaluación empírica en 2001([16]), 2003([17]), 2004([18]), 2005([19]), y 2006([20])
en los que se pueden encontrar métodos y técnicas de evaluación. Los principales estudios sobre
las metodologías de evaluación se dividen en dos vertientes: la evaluación empírica, y la
evaluación por capas. Mientras la primera vertiente propone las correctas metodologías que se
necesitan para realizar la evaluación empírica, la segunda básicamente expone la forma en la que
debe ser llevada a cabo la evaluación de sistemas adaptativos y la correcta interpretación de los
resultados.
1. La evaluación empírica
La evaluación empírica se refiere a la validación de una teoría mediante la realización de
experimentos controlados, por eso también es conocida como experimento controlado. Existen dos
tipos de elementos que integran la evaluación empírica: las variables independientes y las
variables dependientes. Las variables independientes son factores que están bajo el control del
investigador, y se denominan así porque el investigador puede variar sus valores de forma
independiente a otras variables. Mientras que en las variables dependientes sus valores varían en
función de otras variables. Dicho de otro modo, las variables dependientes son las variables de
estudio, ya que el investigador no tiene control sobre estas variables y por esta razón el
investigador realiza las hipótesis de partida sobre éstas. Las variables independientes pueden ser
entendidas como los factores que hacen variar a las variables dependientes.
Debido a la complejidad que supone realizar una evaluación Keppel et al. [21] propone una
serie de pasos a seguir para conseguir resultados significativos. En concreto, propone seguir diez
líneas maestras, que pueden ser resumidas en:
Javier Bravo Agapito
5
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
i) Identificación de los aspectos y cuestiones de interés.
ii) Revisar las teorías e investigaciones relevantes.
iii) Desarrollar hipótesis de investigación como propósito del estudio.
iv) Identificación las variables independientes y dependientes.
En este apartado Whiteside et al. [22] propone una tabla de atributos que permiten medir la
usabilidad del sistema. Con el objetivo de elaborar una lista de posibles variables
dependientes, se proponen tres listas de usabilidad para la creación o selección de nuevas
variables o atributos.
•
Lista 1: Formas de medir
1- Benchmarking: preguntar al usuario sobre la realización de una tarea específica.
2- Monitorización del usuario durante el uso del sistema (logging).
3- Cuestionarios.
4- Entrevista al usuario.
5- Inspección de usuarios.
6- Preguntar al usuario por incidencias críticas revelando éxitos y fallos.
En el contexto de esta investigación tanto el benchmarking, los cuestionarios como las
preguntas al usuario sobre los éxitos y fallos son medidas subjetivas, ya que dependen de
la respuesta del usuario y por tanto es difícil determinar la veracidad o precisión de estas
respuestas. Por esta razón, las medidas anteriores sólo podrían ser usadas como
complemento a otras medidas. La entrevista a los usuarios tiene también un grado de
subjetividad muy alto y tampoco es fácil determinar la veracidad de las respuestas de los
usuarios. Además requiere un alto gasto de recursos, en concreto los relacionados con el
tiempo y los recursos humanos. Respecto a la inspección de usuarios sólo se puede
realizar con un número reducido de usuarios, y en el contexto de este trabajo se necesita
una ingente cantidad de datos, lo que significa que se necesita un alto número de usuarios.
Por otro lado, no resulta posible entrevistar a usuarios que accedan de forma remota al
sistema. Por tanto, esta forma de medición es imposible de realizar en el ámbito de este
estudio. Por último, la monitorización de los usuarios durante el uso del sistema o en otras
palabras, logging, tiene un gasto en tiempo y recursos humanos muy inferior al resto de
las formas de medición y además no depende la veracidad de las respuestas de los
Javier Bravo Agapito
6
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
usuarios. Con lo cual, este último método de medición resulta el más adecuado para el
desarrollo de esta investigación.
•
Lista 2: Criterios de medida
Los criterios de medida corresponden a las variables dependientes, y son los siguientes:
1- Tiempo en completar una tarea.
2- Porcentaje de tarea completada.
3- Porcentaje de tarea completada por unidad de tiempo (speed metric).
4- Ratio de éxitos a fallos.
5- Tiempo empleado en errores.
6- Porcentaje de número de errores.
7- Porcentaje de número de competidores que son mejores que un nivel
establecido.
8- Número de comandos usados.
9- Frecuencia de uso de la ayuda y la documentación.
10- Tiempo empleado en el uso de la ayuda.
11- Porcentaje de comentarios favorables/desfavorables.
12- Número de repeticiones en comandos fallados.
13- Número de éxitos y fallos en las ejecuciones.
14- Número de veces que la interfaz engaña al usuario.
15- Número de buenas y malas características recalcadas por los usuarios.
16- Número de comandos disponibles no utilizados.
17- Número de comportamientos regresivos.
18- Número de usuarios que prefieren tu sistema.
19- Número de veces que los usuarios necesitan trabajar en un problema.
20- Número de veces que el usuario es interrumpido desde una tarea.
21- Número de veces que el usuario pierde el control del sistema.
22- Número de veces que el usuario expresa satisfacción o frustración.
Esta lista es la base utilizada en este trabajo para establecer los criterios de
clasificación de las anomalías, es decir, la ontología de anomalías fue creada a partir de
los elementos de esta lista.
Javier Bravo Agapito
7
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
•
Lista 3: Formas de establecer niveles con respecto a:
1- Un sistema existente o una versión previa.
2- Sistemas competitivos.
3- Realizar una tarea sin el uso de un sistema informático.
4- Una escala absoluta.
5- Tu propio prototipo
6- El rendimiento inicial del usuario.
7- Cada componente del sistema.
8- Sucesivas divisiones de las diferencias entre el mejor y el peor valor observado
en los test a los usuarios.
En el caso de los sistemas AEH es importante destacar la categoría de sistemas
competitivos, ya que se puede medir en rendimiento entre un sistema con adaptación y
otro sin adaptación. Por ejemplo, Muñoz y Ortigosa [23] realizan un estudio sobre el
efecto que produce la adaptación en los contenidos en un grupo de estudiantes de
primero de Secundaria utilizando el sistema de cursos adaptativos TANGOW [10]. Otro
aspecto de igual relevancia que el anterior es la posibilidad de medir el rendimiento
inicial del estudiante mediante tests iniciales. Por ejemplo, el sistema NetCoach [14]
ofrece como posibilidad a los estudiantes la realización de un test previo a cada lección.
Estas tres listas permiten una elección adecuada de las variables dependientes. Las
listas primera y tercera sirven de filtro para la segunda, ya que no todos los atributos
serán de utilidad en un estudio determinado. No obstante, es frecuente que sea necesario
añadir alguna variable más que no esté incluida en la lista, o incluso sea difícil la selección
de los atributos. Por este motivo los autores proponen una lista adicional de preguntas
que sirven de ayuda en la selección o creación de nuevos atributos.
•
Lista 4: Precauciones sobre las especificaciones de usabilidad
*
¿Se puede medir cada atributo en la práctica?
*
¿El criterio para seleccionar a los usuarios está claramente especificado?
*
¿Hay recursos para medir todos los atributos?
Javier Bravo Agapito
8
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
*
¿Están todos los miembros de acuerdo con la inclusión de cada atributo?
*
¿En qué cuantía los atributos capturan la usabilidad del sistema?
v) Selección de sujetos.
Esta fase es la más importante, ya que una inadecuada selección de sujetos repercutirá en las
conclusiones finales de la investigación. De hecho, los algoritmos utilizados en la evaluación
reciben como entrada los datos procedentes de los sujetos o usuarios. Sin embargo, el cuello de
botella reside en la obtención de dichos datos. Y por tanto, en la selección de los sujetos, ya
que en muchas ocasiones resulta imposible conseguir la participación de todos los individuos
de una población2. Es por este motivo por el que se emplean técnicas de muestreo estadístico [24]
con el fin de conseguir una selección de individuos representativos de la población. A esta
selección se le denomina en términos estadísticos muestra3. Además uno de los principios
básicos en el diseño experimental (siguiente fase) es el principio de aleatorización, ya que
previene la existencia de sesgos, evita la dependencia entre observaciones, y confirma la
validez de los procedimientos estadísticos más comunes. De esta forma es posible extrapolar a
partir de una muestra los datos de una población. Es necesario destacar, que dicha muestra
debe ser representativa, pues de otra forma la extrapolación conducirá a resultados sesgados.
En la disciplina de la estadística inferencial se pueden encontrar distintos tipos de muestreos
estadísticos, sin embargo el más utilizado en la evaluación empírica, dada su simplicidad y su
gran rendimiento, es el muestreo aleatorio simple. En este tipo de muestreo la muestra se
obtiene a partir de la selección aleatoria de las unidades muestrales. No obstante, no hay que
olvidar que otros tipos de muestreos son posibles como el muestreo estratificado4, muestreo
sistemático5, y muestreo por conglomerados6, que producen resultados de igual o superior
magnitud que el muestreo aleatorio simple.
2 Se entiende por población en términos estadísticos a la colección de elementos sobre los que se desea
hacer una inferencia.
3 Una muestra es una colección de unidades muestrales seleccionadas de uno o varios marcos. Se entiende
por marco, en sentido estricto, a la lista de unidades de las que se puede extraer una muestra.
4 El muestreo estratificado divide a la población en estratos homogéneos, y la muestra se obtiene a partir
de sorteos aleatorios en dichos estratos.
5 El muestreo sistemático agrupa a la población en n zonas de tamaño k. La muestra se extrae
seleccionando una unidad de la primera zona, y las siguientes unidades seleccionadas son aquellas que
ocupan la misma posición que la primera unidad pero en las n-1 zonas restantes.
6 El muestreo por conglomerados divide a la población en conglomerados, de modo que no exista
solapamiento entre ellos. En un conglomerado los elementos son muy similares entre sí, sin embargo los
conglomerados son muy distintos entre ellos. La muestra se obtiene a partir de la selección aleatoria de
los conglomerados.
Javier Bravo Agapito
9
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
En el ámbito de esta investigación no es necesario, en principio, hacer una selección de
sujetos, ya que se realizará una evaluación de todas las interacciones disponibles de los
usuarios con el sistema.
vi) Diseño del experimento.
Esta fase consiste en asignar los diferentes sujetos a grupos de estudio. Generalmente se suelen
usar dos grupos de estudio, el grupo experimental y el grupo de control. El grupo experimental
está formado por los sujetos a los que se les somete al tratamiento, mientras que el grupo de
control no recibe ningún tratamiento. Por ejemplo, en un sistema adaptativo el grupo
experimental está formado por los sujetos que interactúan con el sistema con la adaptación
activada, mientras que el grupo de control no recibe ningún tipo de adaptación por parte del
sistema. En la literatura se pueden encontrar ejemplos de utilización de esta técnica como
Myers et al. [1], que realizan una evaluación sobre la inclusión de dispositivos portátiles, como
las PDAs,
en las aulas educativas.
Otro ejemplo de utilización de grupos de control y
experimentales es el que describe Staff [25], en el que propone un sistema de evaluación de un
curso adaptativo de hipertexto (HyperContext), en el cual se presenta a los usuarios links
adaptados a su nivel de conocimiento.
Cuando dos o más variables independientes son manipuladas al mismo tiempo el diseño del
experimento recibe el nombre de experimento factorial o diseño factorial. La idea básica de los
diseños factoriales es cruzar las variables independientes con las dependientes, de forma que se
consigan todas las combinaciones posibles (ver Peña [26] para mayor información). Por
ejemplo, Müller et al. [27] realizan una simulación de una terminal de aeropuerto en la que el
usuario es guiado mediante un sistema de asistencia vía móvil por la voz. En esta situación se
manipulan dos variables independientes: la navegación en el sistema (variable navigation), y la
presión que recibe el usuario por las sucesivas indicaciones (variable time pressure).
vii) Uso de estadísticos descriptivos para describir los datos.
Los estadísticos descriptivos como la media, mediana, varianza, desviación típica, etc. son
utilizados como análisis inicial de los datos. Estas medidas no se utilizan para realizar
inferencias del conjunto de datos, sino que con éstas se consigue un resumen del conjunto de
datos.
Javier Bravo Agapito
10
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
viii) Utilización de la estadística basada en la inferencia para evaluar las hipótesis.
Estos estadísticos se utilizan para hacer inferencias sobre la población y asignar, por tanto un
nivel de significación para el experimento. En la estadística inferencial el investigador debe
definir la hipótesis de investigación, hipótesis nula7, la hipótesis alternativa8 y el nivel de
significación. Este nivel asigna un valor a partir del cual hay que rechazar la hipótesis nula, es
decir, este valor es la probabilidad de rechazar la hipótesis nula cuando de hecho es correcta.
Los valores que más se utilizan como nivel de significación son 0,05 y 0,01. Dicho en otras
palabras, si la probabilidad p es menor que 0,05 entonces se puede rechazar la hipótesis nula
en este nivel de significación y se puede afirmar que las medias son significativamente
diferentes; sin embargo si la p es menor que 0,01 se puede afirmar que las diferencias entre las
medias son muy significativas. Uno de los procedimientos más utilizados en la estadística
inferencial es el Análisis de la Varianza, también conocido como ADEVA o ANOVA. Este
procedimiento creado por R. A. Fisher en 1925 permite descomponer la variabilidad de un
experimento en componentes independientes que puedan asignarse a causas distintas [26].
Para realizar este contraste se utiliza el test de la F, por ejemplo Müller el al. [27] y Brunstein et
al. [28] utilizan este tipo de contraste. Otro de los test que se utilizan es el test de la t, que es
algebráicamente equivalente al test anterior. Por ejemplo, los trabajos de Martin y Mitrovic
[29], y Kumar [30] utilizan este tipo de test.
ix) Obtención de conclusiones a cerca la hipótesis.
En el contexto de este trabajo, las conclusiones se obtienen a partir de inferencias sobre los
datos que indiquen posibles cambios en las reglas de adaptación.
x) Preparar un documento formal para su posterior publicación o presentación.
En esta fase es importante que estén especificados en el documento los siguientes puntos:
•
El número de participantes y la fuente de los datos.
•
Las variables independientes y dependientes utilizadas en el estudio.
•
El método de análisis utilizado.
•
Los datos utilizados en el análisis deberían aparecer en un apéndice.
7 La hipótesis nula o también conocida como h0 suele ser del tipo de si las medias entre dos poblaciones
son iguales, o bien si la diferencia entre las medias es significativamente igual a cero.
8 La hipótesis alternativa o también conocida como h1 es la hipótesis que se acepta en caso de rechazar la
hipótesis nula. Puede ser de dos tipos, uno es contrastar si las diferencias entre las medias de las
poblaciones son estadísticamente distintas de 0 (contraste de dos colas), y el otro tipo consiste en
contrastar si la media de una población es estadísticamente mayor o menor de la otra población
(contraste de una cola).
Javier Bravo Agapito
11
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
•
Exponer también los resultados que no son significativos.
•
Exponer el nivel de significación utilizado y el poder9 del test.
2. Evaluación por capas
Esta otra alternativa de evaluación, propuesta por Paramythis y Weibelzahl [31], está basada en
la idea de que la adaptación se puede descomponer en capas o etapas con el objetivo de poder
realizar la evaluación de cada una ellas por separado. Por tanto, la evaluación por capas o niveles
propone un modelo de descomposición basado en las propiedades comunes de algunas de las
arquitecturas y modelos existentes, como por ejemplo AHAM [32] y Munich Reference Model [33].
Esta propuesta divide al sistema en modelos y etapas.
Los modelos están divididos en grupos de modelos. El primero de ellos, es el grupo de modelos
estáticos, que incluye a modelos como el modelo del sistema, modelo de tareas, modelo de
aplicación, etc. Estos modelos son usados para interpretar los datos. El segundo grupo es el de los
modelos dinámicos, como por ejemplo el modelo de usuario, modelo de contexto, etc. Este grupo
se utiliza para adquirir y añadir nuevos conocimientos. El último grupo está formado por la teoría
adaptativa, la cual sustenta las adaptaciones en el sistema.
Las etapas propuestas son las siguientes:
a) Recogida de datos
La obtención de datos se realiza fundamentalmente a partir de las interacciones del usuario
con el sistema, aunque otra fuente de obtención de datos podría ser la utilización de sensores.
La evaluación en esta fase consiste en utilizar medidas técnicas para determinar parámetros
como la fiabilidad, validez, precisión, latencia, etc.
En el contexto de este trabajo, esta fase se realiza de forma automática debido a que se utilizan
mecanismos de simulación para la obtención de los datos de los usuarios. Como consecuencia
no es necesario hacer la evaluación de estos datos, ya que se generan de forma automática.
9 El poder de un test o contraste en términos estadísticos es la probabilidad de rechazar la hipótesis nula
cuando de hecho es falsa. Dicho de otro modo, es lo contrario del error de tipo II (ß). Este error es la
probabilidad de aceptar la hipótesis nula cuando de hecho es falsa. Por tanto, el poder es igual a 1- ß.
Javier Bravo Agapito
12
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
b) Interpretación de los datos recogidos
La siguiente fase, después de realizar la recogida de datos, consiste en interpretar los datos
obtenidos de la fase anterior, es decir, asignar la semántica a los datos en el sistema. Los
problemas potenciales que se presentan en esta fase son: hacer suposiciones en la
interpretación y utilizar algún nivel de inferencia.
Al contrario que la fase anterior, en el contexto de este estudio, es necesario realizar la
interpretación mediante el uso de mecanismos de inferencia (Data Mining) de los datos
simulados, ya que es la parte fundamental de la evaluación que se propone en este trabajo (ver
Capítulo 4: Arquitectura del sistema de evaluación).
c) Modelado del estado actual del “mundo”
Esta etapa en el modelo de descomposición se refiere a la extracción de nuevos conocimientos
sobre el usuario como consecuencia de las inferencias producidas en la fase anterior. Por
tanto, se trata de una segunda fase de inferencia. Este nuevo conocimiento se añade a los
modelos dinámicos. Sin embargo en el ámbito de los sistemas AEH en muchas ocasiones no
existe este segundo nivel de inferencia. La evaluación en esta etapa consiste en validar las
interpretaciones o inferencias.
d) Decisiones sobre la adaptación
Esta fase consiste en elegir las decisiones de adaptación necesarias para el sistema. La
evaluación en esta fase tiene como objetivo determinar si estas decisiones son adecuadas, es
decir, si son necesarias, apropiadas o subjetivamente aceptadas por el usuario.
En el dominio de esta investigación las decisiones de adaptación se realizan mediante el
análisis de las reglas de adaptación.
e) Aplicación de la adaptación
El objetivo de la última reside en introducir las decisiones de adaptación en el sistema. La
evaluación en esta fase depende del efecto de la adaptación, por eso es conveniente utilizar
criterios de evaluación relacionados con la usabilidad del sistema.
Javier Bravo Agapito
13
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
CAPÍTULO 3
Objetivos y Metodología
1. Objetivos
El objetivo final de esta línea de investigación es desarrollar métodos y herramientas que
permitan valorar la efectividad de las distintas adaptaciones con el fin de detectar problemas o
posibilidades de mejora en las reglas de adaptación y los contenidos. Estos problemas en las reglas
y contenidos pueden ser detectados a través de comportamientos o resultados no esperados en la
interacción de los estudiantes con el sistema. Por tanto, los objetivos inmediatos de este Trabajo
de Iniciación a la Investigación son dos:
•
Integrar las herramientas de evaluación en la arquitectura de los Sistemas Hipermedia
Adaptativos.
•
Proveer al diseñador del curso de una herramienta que le permita comprobar si los
resultados devueltos por la herramienta de evaluación son correctos. En este contexto,
correctos significa que la herramienta de evaluación ha sido capaz de detectar todas las
anomalías existentes en los ficheros logs. Para conseguir este doble objetivo se propone:
*
Usar técnicas y herramientas de simulación para realizar este test sobre la herramienta
de evaluación.
Javier Bravo Agapito
14
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
*
Proveer al sistema de una clasificación de anomalías o patrones de comportamientos
anómalos. Con esta clasificación es posible especificar los patrones de comportamientos
anómalos que se desean generar.
2. Metodología
Las pautas metodológicas que se han seguido en la realización de este trabajo son las
siguientes:
1) Análisis de las distintas técnicas de simulación.
Esta tarea incluyó un análisis preliminar de las distintas técnicas de simulación de perfiles
y comportamientos de los usuarios en el ámbito del e-learning.
2) Determinación de los perfiles de los usuarios.
Este punto consistió en determinar los distintos perfiles posibles de los usuarios o
estudiantes. Como resultado final de esta fase y debido a la gran diversidad existente de
estudios sobre perfiles de usuarios, se decidió utilizar los perfiles del modelo propuesto
por Felder-Silverman [34] para el primer prototipo.
3) Diseño de la simulación de perfiles y comportamientos.
El objetivo de esta fase residió en hallar un método para simular los distintos perfiles de
los usuarios. Durante el diseño se determinó utilizar como referencia algunas de las
dimensiones del modelo de Felder-Silverman con el objetivo de poder realizar un
prototipo inicial de simulación.
4) Implementación de las herramientas de simulación.
Durante esta fase se implementaron un dos prototipos de simulación de perfiles. El
primero bajo la premisa de utilizar unas dimensiones o atributos de los usuarios por
defecto, y el segundo es capaz de extraer los perfiles de los estudiantes de la descripción
del curso.
5) Diseño de una clasificación de anomalías
Esta fase consistió en realizar una búsqueda sobre trabajos que incluyeran alguna
taxonomía de anomalías. Debido a que en el contexto de este trabajo (e-learning) es
importante la independencia de la herramienta con respecto a los sistemas AEH, se
decidió crear una ontología de anomalías tomando como base las indicaciones de
Whiteside [22]. La herramienta utilizada para la creación de dicha ontología es el editor de
Javier Bravo Agapito
15
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
ontologías Protégé.
6) Incorporación de la herramienta de evaluación en una arquitectura de evaluación.
El resultado de esta fase es la propuesta de una arquitectura de evaluación, en la que se
muestra la utilidad de usar la herramienta de la fase anterior en un sistema de evaluación
de cursos adaptativos orientados a la enseñanza.
7) Publicación y presentación de resultados.
Como resultado final de esta investigación se ha publicado un artículo en el workshop
“User-Centred Design and Evaluation of Adaptive Systems” dentro del congreso “Adaptive
Hypermedia 2006”. Además se ha realizado otro artículo, publicado en los proceedings del
“Simposio Internacional de Informática Educativa (SIIE 2006)”. Dichos artículos han sido
incluidos en el apéndice.
Javier Bravo Agapito
16
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
CAPÍTULO 4
Arquitectura del sistema de evaluación
Los sistemas AEH están formados por un motor de adaptación que, en base a una descripción
general del curso y los perfiles de los estudiantes, es capaz de generar un curso personalizado
para cada uno de ellos. Dicho de otro modo, el motor de adaptación adapta la estructura y los
contenidos del curso al perfil de cada estudiante, como por ejemplo la adaptación puede depender
del nivel de conocimiento de cada estudiante. Esta adaptación es posible debido a que la
descripción del curso incluye los contenidos educativos y las reglas de adaptación. Dichas reglas
indican al motor de adaptación cómo debe seleccionar y combinar los contenidos para adaptarse
a las características y comportamientos de los estudiantes durante su interacción con el sistema.
Las dimensiones de los estudiantes contienen información relativa a atributos relevantes, como
por ejemplo el nivel de conocimiento previo y el estilo de aprendizaje preferido.
Estas
componentes forman lo que se denomina un sistema AEH que puede observarse en la figura 1.
Esta figura muestra como el sistema AEH toma los datos de los estudiantes y la descripción del
curso adaptativo, incluyendo las reglas de adaptación, y en base a eso genera de forma dinámica
una página web que se muestra a los estudiantes. Las interacciones de los estudiantes con el
sistema provocarán actualizaciones en los modelos de usuario de los estudiantes y eventualmente
nuevas partes del curso irán siendo presentadas.
En este contexto, el problema de evaluación de las reglas de adaptación consiste en determinar
si dichas reglas generan el contenido apropiado para cada tipo de estudiante. Como se muestra en
Javier Bravo Agapito
17
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
la figura 2, la herramienta de evaluación puede tomar información sobre los modelos de usuario
Figura 1 Arquitectura de un sistema AEH
- MdU10 y la descripción del curso (contenido + reglas) y analizar los logs en busca de patrones
recurrentes de comportamiento que parezcan apartarse del comportamiento esperado o deseable
de los estudiantes. Estas pautas de comportamientos pueden indicar potenciales errores en las
reglas de adaptación. A estos comportamientos que se apartan de lo esperado o que indican la
posible existencia de problemas en la adaptación se les denomina en este estudio anomalías. Una
vez que las anomalías son detectadas por la herramienta de evaluación, se le presentan al usuario
evaluador. Este usuario es la persona encargada de analizar el funcionamiento del sistema AEH y,
más concretamente de analizar si las anomalías encontradas por la herramienta de evaluación
conducen a realizar cambios en la estructura del curso (reglas de adaptación) o en los contenidos.
El usuario evaluador puede ser el propio diseñador del curso, o bien una persona únicamente
dedicada a analizar la calidad del sistema. Por tanto, en la arquitectura propuesta se propone
incorporar la componente destinada a realizar la evaluación, ya que se considera un elemento
fundamental en la mejora de la calidad de los sistemas AEH.
10 Un modelo de usuario está formado por el perfil y los logs de la interacción del usuario con el sistema.
Además hay que indicar, que un perfil está formado por una o varias características o dimensiones.
Javier Bravo Agapito
18
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Figura 2 Arquitectura de un sistema AEH con evaluación
Como se ha expuesto en el párrafo anterior el evaluador es la persona encargada de analizar
los resultados de la herramienta de evaluación, es decir, las anomalías detectadas por dicha
herramienta. Sin embargo, uno de los problemas a los que se enfrenta el evaluador es valorar si
los resultados obtenidos en la evaluación son consistentes. Por tanto, el evaluador se enfrenta a
dos preguntas:
☑ ¿Las anomalías informadas por la herramienta de evaluación están realmente presentes en
los logs analizados?
☑ ¿Todas las anomalías encontradas por la herramienta de evaluación constituyen el total de
anomalías reales existentes en los ficheros logs analizados, o por el contrario existe alguna
anomalía que la herramienta no haya sido capaz de detectar?
La primera pregunta se puede resolver haciendo que la herramienta de evaluación muestre los
perfiles de los usuarios que presentan las anomalías detectadas. La función del evaluador es
Javier Bravo Agapito
19
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
decidir si los modelos de usuario mostrados por la herramienta contienen las anomalías
detectadas y si conducen a revisar el diseño del curso. La respuesta a la segunda pregunta es más
complicada, ya que asegurar que la herramienta de evaluación es capaz de encontrar todas las
anomalías existentes requeriría disponer de un amplio conjunto de perfiles y en consecuencia
disponer de un amplio número de estudiantes. Además estos perfiles tendrían que ser revisados
manualmente por el evaluador, uno a uno, para contrastar si son los mismos que muestra la
herramienta.
Figura 3 Contexto de la herramienta de simulación
Por esta razón, en este estudio se propone una forma de generar de forma automática los
modelos de usuario mediante el uso de técnicas de simulación. La herramienta que realiza esta
función es Simulog (Simulación de Usuarios a través de Logs) cuya descripción se encuentra en el
siguiente capítulo. La figura 3 muestra la arquitectura de simulación en la que el evaluador
especifica las anomalías a generar (representadas por las letras AT) y las características o
atributos de los estudiantes simulados (representados por PE). Simulog utiliza estos parámetros
de entrada junto con la descripción del curso (reglas de adaptación) para generar los modelos de
usuario (MdU) solicitados (perfil + logs). Por tanto, los modelos de usuario generados contendrán
en su interior las anomalías solicitadas (representadas por AT). Siguiendo con el diagrama de la
Javier Bravo Agapito
20
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
figura citada, la herramienta de evaluación toma los modelos de usuario generados en la fase
anterior con el objetivo de encontrar anomalías. Por último, el evaluador recibe los resultados de
la herramienta de evaluación, es decir, las anomalías detectadas (representadas por AD) y las
compara con las que solicitó como parámetros en la generación. De esta forma, si son las mismas
anomalías generadas que las detectadas, el evaluador puede concluir que la herramienta de
evaluación funciona de forma correcta.
Javier Bravo Agapito
21
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
CAPÍTULO 5
Simulog: Sistema de Simulación de Usuarios
Simulog es un sistema cuyo objetivo es validar métodos y herramientas de evaluación de
sistemas AEH basados en análisis de logs. La idea es generar ficheros de logs de una manera
controlada para que puedan ser usados como datos de entrada en la herramienta de evaluación
(ver figura 3). De esta forma es fácil comprobar si la herramienta de evaluación es capaz de
detectar las mismas anomalías que han sido generadas en la simulación.
Originalmente, Simulog fue diseñado buscando la mayor independencia posible tanto de la
herramienta de evaluación a validar como del sistema adaptativo. Debido a este motivo se buscó
la máxima generalidad en la definición de sus entradas. Por eso el diseño original preveía utilizar
el estándar de SCORM [35] para la descripción de cursos adaptativos orientados a la enseñanza y
ontologías para describir las anomalías. El primero sirve para describir un curso adaptativo en
formato XML de forma generalizada y de esta manera conseguir que la descripción del curso sea
independiente de la herramienta de evaluación y del sistema adaptativo. En particular, SCORM
1.3.1 describe un curso mediante unidades de aprendizaje y reglas. Las reglas pueden ser modos
de secuencias de control y cláusulas if-then [36]. La decisión de cúal es el siguiente nodo a mostrar
es tomada por el Sistema Gestor de Aprendizaje (Learning Management System - LMS) o el
sistema adaptativo. Sin embargo, el prototipo actual sólo soporta el formato de descripción de
cursos adaptativos existente en TANGOW.
Javier Bravo Agapito
22
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Figura 1 Arquitectura de Simulog
1. Arquitectura
Simulog está dividido en dos partes claramente diferenciadas: el procesamiento de las entradas
de simulación y el motor de simulación. El funcionamiento de Simulog es el siguiente: el
evaluador introduce los parámetros de simulación deseados (usando el editor de atributos y el de
anomalías), la herramienta recibe estos parámetros, el núcleo de simulación los procesa y produce
la simulación deseada consultando la descripción del curso adaptativo, que es traducida en
ficheros de modelos de usuario, perfiles y logs de usuario (ver figura 1).
Javier Bravo Agapito
23
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
2. Entradas de simulación
Los parámetros de entrada que necesita Simulog para realizar la simulación de modelos de
usuario son: la descripción del curso, los atributos o dimensiones del estudiante y las anomalías.
2.1. Descripción del curso
Simulog necesita conocer la estructura del curso, a partir de la cual se van a simular los logs de
los estudiantes. El prototipo actual sólo admite cursos del sistema TANGOW, es decir, descripción
de cursos adaptativos con el formato TANGOW. Aunque se planea en el futuro ser capaz de leer el
formato SCORM.
2.2. Perfil del estudiante
Simulog permite que el evaluador defina los atributos o características de los usuarios que se
desean simular, es decir, permite al evaluador definir los perfiles de los estudiantes que se desean
simular. A estas características o atributos de los usuarios se los denomina en este estudio
“dimensiones” (una o más dimensiones forman un perfil). Por ejemplo, en la figura 2 puede
observarse que las dimensiones, automáticamente extraídas de la descripción del curso, que
definen el perfil del estudiante son: secuencial/global, visual/verbal y conocimiento previo. El
núcleo principal de esta simulación es que los distintos perfiles determinarán la forma en la que
los estudiantes responderán los ejercicios o, la probabilidad de abandonar una actividad antes de
completarla o, la probabilidad de que un estudiante se pierda en el curso o, la tendencia de un
estudiante a consultar el índice, etc. Dicho de otro modo, un modelo de probabilidad es el que
determina que se produzca alguna de las situaciones anteriores. Además este modelo de
probabilidad depende del tipo de perfil, es decir, los valores de las dimensiones, determinadas por
las proporciones definidas por el evaluador, de un determinado perfil son parámetros para este
modelo de probabilidad así como el tipo de adaptación existente en el sistema. En el ejemplo de la
figura 2 puede verse como las proporciones para las dimensiones son 20%, 75% y 70%. Esto quiere
decir, que el sistema generará más perfiles con aprendizaje global que con aprendizaje de forma
secuencial, ya que se le indicó al sistema que el 20% fueran secuenciales y el 80% globales. Además
los perfiles generados tienen que ser mayoritariamente visuales, ya que se le especificó al sistema
que el 75% de los perfiles fueran visuales y el 25% verbales. Y por último, estos perfiles tendrán en
promedio un nivel de conocimiento previo de 7 sobre 10, ya que el evaluador definió que la
Javier Bravo Agapito
24
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
proporción del parámetro conocimiento previo fuera de 70%. En resumen, en este ejemplo el
sistema generará mayoritariamente perfiles de estudiantes que aprendan mejor de una forma
global, que además tengan una memoria visual mayor que la verbal y que su conocimiento previo
sobre los temas del curso sea de 7 sobre 10 en media. Por tanto, si la adaptación de los contenidos
del curso fuera para usuarios globales, el modelo de probabilidad, por ejemplo, asignará mayor
probabilidad de éxito en los ejercicios realizados por los estudiantes simulados con el perfil
anterior. Si por el contrario los contenidos mostrados estuvieran adaptados a una forma de
aprendizaje secuencial, el modelo de probabilidad, por ejemplo, asignará una probabilidad muy
pequeña de éxito en los ejercicios realizados por los anteriores estudiantes simulados.
Además, una característica adicional de Simulog es la capacidad de extraer de forma
automática los tipos de dimensiones de la estructura del curso. De esta forma el evaluador sólo
necesita especificar las proporciones de estas dimensiones en los estudiantes y el
comportamiento a simular.
Figura 2 Simulog y el editor de atributos
Javier Bravo Agapito
25
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Otra característica destacable de la herramienta es la posibilidad de que el evaluador pueda
modificar los valores de los atributos de una dimensión, es decir, Simulog proporciona un editor
de dimensiones o atributos (ver parte inferior de la figura 2) que permite modificar los atributos o
parámetros que describen las dimensiones: name, description y scale. Éstos son los atributos que
describen una dimensión. Por ejemplo, en la figura citada la dimensión visual/verbal está definida
por un parámetro name con valor “Visual/Verbal”, que es el identificador de la dimensión, un
parámetro description con el valor “Mide la forma en la que los estudiantes aprenden”, que
proporciona una descripción de la dimensión (es un parámetro opcional), y un parámetro scale
cuyo valor es de 0 a 10, que define la escala en la que se mide la dimensión.
2.3. Anomalías
Simulog genera ficheros de logs que contienen síntomas de potenciales problemas en el
funcionamiento de un
sistema adaptativo. Estos síntomas se denominan en este trabajo
anomalías, es decir, comportamientos anómalos o no esperados por parte de los estudiantes. Un
ejemplo de anomalía puede ser: los usuarios que obtienen un determinado valor en la dimensión 1
tienen problemas con los ejercicios de la actividad A. La herramienta que se presenta en este
trabajo de investigación proporciona al evaluador un editor de anomalías con el que se pueden
añadir nuevas instancias o modificar otras instancias de la ontología (ver figura 3). En la siguiente
figura se puede ver como el evaluador ha formado la siguiente anomalía: “los estudiantes que
tienen el valor menor que 2 en la dimensión 3 acuden al índice con una frequencia mayor que 10
en las actividades 2 y 3”.
Figura 3 Simulog y el editor de anomalías
Javier Bravo Agapito
26
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
3. Ontología de Anomalías
Una ontología proporciona a Simulog una forma general de definir anomalías, ya que uno de
los objetivos de esta herramienta es la independencia tanto de la herramienta de evaluación como
del propio sistema adaptativo. Las ontologías, uno de los conceptos más utilizados en la Web
Semántica, son especificaciones de conceptualizaciones [37]. En este sentido, la ontología
propuesta es también útil fuera del contexto de la herramienta de simulación. El concepto de
ontología está relacionado con la posibilidad de obtener un vocabulario común y
consecuentemente reusar y compartir este conocimiento.
Simulog utiliza la ontología de anomalías para representar comportamientos anómalos o no
esperados por parte de los estudiantes. Esta ontología tiene como función establecer una
clasificación de estos comportamientos o situaciones anómalas por parte de los estudiantes que
deberían ser detectadas en los sistemas AEH.
Figura 4 Jerarquía de clases
Javier Bravo Agapito
27
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Si bien al principio la meta fue crear un vocabulario común de anomalías para Simulog, ahora
el objetivo es proporcionar un vocabulario común de anomalías para cualquier herramienta. Hay
que señalar que esta ontología fue creada desde cero siguiendo las directrices propuestas en la
guía de Noy et al. [38] y usando el editor de ontologías Protégé. Además la ontología utiliza los
estándares del W3C: RDF y RDFS. La ontología está compuesta por seis clases: Activity, Anomaly,
Criterion, Dimension, Property y Concept (ver figura 4). Las clases Dimension y Activity representan
conceptos que deben ser mapeados con el Modelo de Usuario y la estructura del curso
respectivamente. La clase Activity contiene las actividades que el investigador desea controlar o
analizar. Por ejemplo, en la ontología hay actividades definidas por defecto de la forma activity 1,
activity 2, activity 3, etc. Estas actividades son mapeadas por el investigador con la estructura del
curso (escrita en formato TANGOW).
La clase Dimension contiene a su vez las dimensiones que desea analizar el evaluador y está
relacionada con el Modelo de Usuario. Estas dimensiones son definidas en la ontología como
dimension 1, dimension 2, dimension 3, etc. Deben ser mapeadas también por el evaluador con las
características definidas en el Modelo de Usuario.
Figura 5 Slots de la clase Criterion
Javier Bravo Agapito
28
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Las clases Criterion y Property están estrechamente relacionadas con la clase Anomaly, pues
definen los criterios de clasificación de las anomalías y sus propiedades. En concreto, la clase
Criterion es la que proporciona la forma de clasificación de las anomalías. Este criterio de
clasificación sigue las líneas propuestas por Whiteside [22]. Cada criterio está compuesto por uno
o más conceptos y un identificador (ver figura 5). Por ejemplo, una instancia de Criterion es:
“estudiantes que tienen en la dimensión 1 un valor mayor que 2” (ver figura 6). Como se puede
observar en este ejemplo esta instancia está compuesta por su identificador y un concepto de la
instancia de la clase Concept. Si volvemos a la figura 4 donde se expone la jerarquía de clases
observaremos que la clase Criterion está compuesta por dos subclases: Simple y Complex. La
diferencia entre las dos es que las instancias de la clase Simple sólo pueden tener un concepto,
mientras que las de la otra clase, Complex, pueden tener uno o más. La clase Property contiene los
tipos de operadores que son necesarios para definir un concepto. De hecho, un concepto puede
estar formado por una instancia de la clase Activity, Dimension o Concept. La definición de la clase
Figura 6 Ejemplo de instancia de la clase Criterion
Property puede verse en la figura 7 en la que se muestra que dicha clase está compuesta por un
identificador y un nombre. Un ejemplo de propiedad es el mostrado en la figura 8.
Javier Bravo Agapito
29
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Figura 7 Slots de la clase Property
Una anomalía está formada por un sujeto, predicado, valor y un identificador. El sujeto puede
ser uno o más criterios, es decir, instancias de la clase Criterion. El predicado está compuesto por
un criterio y una propiedad (instancia de la clase Property). Finalmente el valor es una cantidad
por la que la propiedad es comparada. Por ejemplo la siguiente anomalía puede ser creada: “los
estudiantes con valor menor que -5 en la dimensión 2 y valor mayor que 2 en la dimensión 1
tienen un porcentaje de fallos en la actividad 1 mayor que el 70%”. En este ejemplo el sujeto es
Figura 8 Ejemplo de instancia de la clase Property
“estudiantes con valor en la dimensión 2 menor que -5 y con valor en la dimensión 1 mayor que
2”. El sujeto es múltiple y está formado por dos instancias de la clase Dimension_Criterion. El
predicado es “porcentaje de fallos en la actividad 1 mayores que” y es generado por dos
Javier Bravo Agapito
30
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
instancias, una perteneciente a la clase Failure_Criterion y la otra de la clase Property. Finalmente el
valor de comparación es 70. La figura 9 ilustra esta explicación.
Figura 9 Ejemplo de anomalía
4. Motor de simulación
En el motor de simulación se realiza una doble función: generación de estudiantes con la
proporción de dimensiones solicitada y la generación de modelos de usuario (perfiles + logs de
usuario).
4.1. Generación de perfiles
En la simulación de perfiles es importante que se cumplan dos propiedades ampliamente
conocidas en el ámbito de la estadística: representatividad y aleatoriedad, o en otro caso no sería
posible extrapolar los resultados de la simulación de estudiantes. La representatividad es una
propiedad que mide el grado por el que una muestra representa a la población, es decir, mide
como es de buena la extrapolación de resultados a partir de esta muestra. La otra medida,
aleatoriedad, se refiere a la forma en la que las unidades muestrales son seleccionadas, es decir,
garantiza que no haya efectos externos o condicionantes que afecten a la selección de la muestra.
Entonces, ¿de qué manera se puede hacer la simulación de dimensiones de forma aleatoria y sin
perder representatividad?
Javier Bravo Agapito
31
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
La respuesta a esta pregunta a primera vista podría ser sencilla, pues la mayoría de estudios
realizados en la AEH utilizan la distribución U(0,1)11 como medio de generación aleatoria. Sin
embargo, si la escala de una de las dimensiones a generar fuera de 0 a 10 habría que aplicar la
siguiente fórmula de transformación:
U a , b =a U 0,1⋅ b−a  (1)
y en particular para el intervalo de 0 a 10 la fórmula sería:
U 0,10=U 0,1⋅10 (2)
No obstante este método tiene un grave problema, ya que aunque sí que es verdad que se
obtiene aleatoriedad en la muestra, ésta no es representativa de la población de individuos. Por
tanto, es necesario buscar otra distribución que cumpla estas dos propiedades. La distribución que
cumple estas dos propiedades es la distribución de Gauss o también conocida como distribución
Normal. Esta distribución es muy utilizada en otros campos como la Sociología, debido a que
produce resultados muy próximos a los reales. De hecho, muchos parámetros relacionados con la
Naturaleza se distribuyen como una Normal [39] [40], por ejemplo la longitud de un brazo, altura
de un individuo, etc. Veamos ahora el método para generar números aleatorios que sigan una
distribución Normal con media µ y desviación típica σ. En primer lugar, supongamos que
queremos generar un porcentaje p de una dimensión y 1-p de la segunda dimensión. Por ejemplo,
si quisiéramos generar que el 75% de los estudiantes sean visuales y el 25% visuales p (porcentaje
o probabilidad) tendría el valor de 0,75 y 1-p sería igual a 0,25. Además, es bien conocido que si X
es una variable aleatoria con distribución N(µ,σ) se cumple la siguiente relación:
P  X x 1 =p (3)
Tenemos entonces que
∣µ− x1∣
es el número de unidades que habría que desplazar la media
de la Normal para conseguir generar elementos de forma que el porcentaje en media de la
primera dimensión sea p. A partir de ahora denominaremos a esta distancia
el caso de que
d1 . Por tanto, en
µ  x1 , o en otras palabras, si p 0,5 , entonces habrá que desplazar la
11 En la distribución Uniforme U(a,b) todos los elementos pertenecientes al intervalo (a,b) tienen la misma
probabilidad de ser seleccionados. En este caso el intervalo es de 0 a 1.
Javier Bravo Agapito
32
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
media hacia la izquierda
d1 unidades, o por el contrario si
deberemos desplazar la media hacia la derecha
el valor de
p 0,5 o bien
µ  x1
d1 unidades. Entonces necesitamos encontrar
x 1 , y para ello necesitamos usar las tablas de la Normal (ver Donald B. Owen [41]).
El proceso para hallar el valor de x 1 consiste en transformar la variable X, distribuida como
una N(µ,σ), a una normal tipificada, N(0,1), y obtener una nueva variable Z distribuida como una
N(0,1). Sabemos que la variable Z es igual a
Z=
X −µ
, con lo que reescribiendo la fórmula (3)
σ
queda lo siguiente:
PX 
x1 −µ
=p (4)
σ
Ahora ya podemos utilizar las tablas de la N(0,1) para encontrar el valor de
z1
12
y
consecuentemente el valor de x 1 . Por ejemplo, para un valor de p igual a 0,75 se obtiene que
z 1 es igual a 0,67, y por tanto si la distribución fuera N(5,2) el valor de x 1 , aplicando (5),
sería igual a 0,67·2+5 = 6,34. Con lo que deberíamos mover la media 6,34-5 = 1,34 unidades hacia la
izquierda, y de esta forma la nueva media sería igual a 3,66. La figura 6.10 ilustra de forma gráfica
lo explicado en este párrafo.
12 El valor de z1 es igual a (x1- µ)/ σ.
Javier Bravo Agapito
33
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Figura 10 Traslación de una N(5,2) a N(3.66, 2)
Cabe destacar que para este ejemplo se decidió utilizar la distribución Normal con media 5 y
desviación típica 2 porque es la que concentra mayor número de valores entre 0 y 10, que es la
escala utilizada en la dimensión Visual/Verbal. Además una vez encontrada la nueva media, µ'
que es igual a µ-d1 o d1- µ dependiendo del caso, hay que redimensionar los valores de N(0,1) a
la N(µ,2) mediante la fórmula siguiente13:
“Sean dos variables aleatorias X y Z, de forma que X se distribuye mediante una Normal con media µ y
desviación típica σ, y Z se distribuye mediante una Normal con media 0 y desviación típica 1”, entonces se
verifica que:
13 Si una variable aletoria X se distribuye mediante una distribución Normal, entonces cualquier función
lineal de X también se distribuirá como una Normal. (ver teorema en [39], p.253-255).
Javier Bravo Agapito
34
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
X =Z⋅σ µ (5)
Finalmente, aplicando este método para cada una de las dimensiones o características del
estudiante generaremos el porcentaje de dimensiones buscadas.
4.2. Generación de modelos de usuario
Una vez que la fase anterior de generación de características14 o dimensiones de los
estudiantes ha concluido, sólo queda generar los ficheros de logs, pues los perfiles ya han sido
generados en la fase anterior. La generación de estos ficheros se consigue aplicando un modelo de
probabilidad dependiente del tipo de perfil. En otras palabras, los valores generados en las
dimensiones de un estudiante (perfil de un estudiante) condicionan que éste responda de forma
correcta a una determinada cuestión, o que abandone la actividad antes de ser acabada, o que el
sistema ajuste de manera adecuada el nivel de adaptación del estudiante.
La estructura de los ficheros de logs está compuesta por un modelo de usuario (user-model),
logs de las actividades (log-activity) y actualizaciones del modelo de usuario (log-update). El
siguiente esquema ilustra la estructura de un fichero log:
<log-root>
<user-model>
<dimension name=” ” value=” ” />
</user-model>
<log-activity>
<log activity=” ” score=” ” action=” ” porcent=” ” timestamp=” “ />
</log-activity>
<log-update>
<update name=” “ value=” “ />
</log-update>
</log-root>
La estructura anterior refleja que un fichero de log está dividido en tres partes claramente
diferenciadas.
14 Las características o aptitudes de un estudiante están determinadas por los valores de cada dimensión.
Javier Bravo Agapito
35
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
La primera parte, user-model, está compuesta por tantos elementos dimension como atributos
tenga el modelo de usuario. Este modelo, a su vez, está compuesto por las dimensiones existentes
en la descripción del curso y los atributos estáticos del estudiante, como su nombre, edad, etc.
Cada elemento dimension está formado por el par name, value los cuales definen el identificador de
la dimensión y el valor que tiene asignado dicha dimensión respectivamente.
La parte central, log-activity, está compuesta por tantos elementos log como interacciones
tenga el usuario con el sistema. Los parámetros que forman un elemento log son:
•
activity: representa la actividad en la que se encuentra el estudiante.
•
score: indica el grado de éxito que lleva el estudiante.
•
porcent: representa el grado de completitud de una actividad.
•
timestamp: muestra el tiempo absoluto de la máquina.
•
action: variable que indica el tipo de comportamiento del estudiante. Puede tomar los
siguientes valores:
*
START: inicio de actividad.
*
FINISHED: actividad principal terminada.
*
END-ACTIVITY: actividad secundaria terminada.
*
LEAVE-ACTIVITY: abandono de la actividad secundaria antes de ser completada.
*
NOT-FINISHED: actividad principal no completada.
*
GO-INDEX: adandono temporal de la actividad para consultar la ayuda o el índice.
La última parte de los ficheros de logs es la relacionada con las actualizaciones del modelo de
usuario (log-update). Los parámetros que componen esta parte no están fijados a priori, ya que
dependen de si ha habido algún cambio en el modelo de usuario. Por tanto, los parámetros que
compondrán esta tercera parte serán las dimensiones del modelo de usuario que hayan
actualizado su valor. Esta parte está compuesta por tantos elementos update como actualizaciones
haya en el modelo de usuario, de esta forma se pueden almacenar los cambios que haya en el
modelo de usuario mientras un estudiante interactúa con el sistema.
Javier Bravo Agapito
36
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Un ejemplo más extenso de los logs generados se puede encontrar en el apéndice.
Javier Bravo Agapito
37
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
CAPÍTULO 6
Conclusiones y Trabajo Futuro
Este trabajo propone una forma práctica y económica para evaluar las herramientas de
evaluación de sistemas AEH basadas en el análisis de logs, es decir, su objetivo consiste en realizar
evaluación sobre la evaluación. Con este objetivo se presenta Simulog, una herramienta diseñada
para implementar este enfoque.
Además se ha propuesto también una arquitectura que incluye a la propia herramienta de
evaluación. La arquitectura propuesta constituye un paso adelante para mostrar que la evaluación
es una parte muy importante que no hay que descuidar en la creación y mantenimiento de un
sistema adaptativo. De hecho, la evaluación automática es más interesante que la evaluación
manual, por eso en la arquitectura presentada se incluye una herramienta de evaluación semiautomática basada en la utilización de técnicas de Data Mining. La razón por la cual esta
herramienta no es completamente automática es porque los evaluadores prefieren tener un cierto
control sobre las evaluaciones realizadas, por eso la herramienta devuelve los resultados al
evaluador en vez de introducir las mejoras de manera automática en el curso adaptativo. Cabe
destacar, que en este trabajo se expone realizar la evaluación sobre las reglas de adaptación y
sobre los contenidos, pues una evaluación de tipo global no conduciría a solucionar los problemas
detectados en el diseño del curso. Además, tanto el contenido como las reglas de adaptación son
dos de las partes más importantes para detectar si la adaptación produce los resultados esperados.
Dicho de otro modo, si conseguimos analizar las reglas de adaptación y los contenidos podremos
Javier Bravo Agapito
38
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
comprobar si es útil la adaptación. Por tanto, en este trabajo se propone una forma de valorar si es
útil la adaptación desde la creación y uso de un curso adaptativo hasta su mantenimiento.
Junto a esta arquitectura o forma de introducir una herramienta de evaluación en la
arquitectura de un sistema AEH se presenta además una herramienta de simulación. Es un hecho,
que existe la necesidad de valorar la efectividad de los resultados obtenidos de una herramienta
de evaluación. Con el objetivo de absorber esta necesidad se presenta Simulog, una herramienta
capaz de simular los comportamientos de los estudiantes a través de la generación automática de
modelos de usuario. Por tanto, como se dijo en el párrafo anterior con esta herramienta se
consigue “rizar el rizo”, es decir, hacer evaluación sobre la evaluación. Sin embargo, Simulog no
fue diseñada para realizar una simulación exhaustiva de los comportamientos de los estudiantes,
sino para realizar la simulación de determinados tipos de comportamientos no esperados o
alejados del comportamiento de la mayoría de estudiantes. Además, Simulog proporciona una
ingente cantidad de logs, tantos como desee el evaluador, necesarios para la utilización de
técnicas de Data Mining. La conclusión final es que Simulog es una herramienta muy útil para
valorar la efectividad de las herramientas de evaluación, ya que produce una gran cantidad de
datos y permite ahorrar tanto en tiempo como en recursos humanos. Sin embargo, no hay que
olvidar que los casos simulados son aproximados a los reales, y consecuentemente hacer
inferencia sobre estos datos puede producir sesgos en los resultados. Por tanto y debido a que no
se han contrastado los resultados obtenidos por la herramienta con usuarios reales, los datos
proporcionados por Simulog sólo deben ser utilizados para medir la efectividad de la herramienta
de evaluación.
El trabajo futuro incluye realizar las siguientes tareas:
•
Probar que los resultados simulados por la herramienta son similares a los que generarían
usuarios reales. Esta tarea es de suma importancia, ya que de alguna forma permite validar
los resultados obtenidos en la simulación. Aunque, no hay que olvidar que el objetivo de
Simulog no es simular con exactitud los comportamientos de los usuarios sino simular
comportamientos anormales de los estudiantes para poder validar la herramienta de
evaluación.
Javier Bravo Agapito
39
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
•
Probar Simulog con los diseñadores de los cursos, es decir, comprobar si las anomalías que se
describen en la ontología son suficientes para detectar patrones de comportamientos
anómalos. Esta tarea constituye un paso fundamental para establecer y estabilizar la
ontología de anomalías, pues sin el “feedback” de los usuarios de Simulog, los evaluadores o
diseñadores de cursos, no nos sería posible determinar de forma aproximada el grado de
utilidad o de aceptación que tiene esta herramienta.
Además el trabajo futuro incluye, entre otros aspectos, añadir nuevas posibilidades a la
herramienta de simulación como:
•
Añadir la capacidad de poder generar dimensiones con otro tipo de distribuciones como la
T-Student o la F-Snedecor. Por ejemplo, la distribución T de Student se utiliza para estimar
la media de una población distribuida mediante una Normal cuando el tamaño de muestra
es pequeño, es decir, permitiría a la herramienta simular con mayor exactitud muestras de
estudiantes pequeñas, de tamaño menor que 30. Respecto a la utilización de la F de
Snedecor, como se trata de una distribución asimétrica, se podría utilizar para simular tipos
de estudiantes que tengan un perfil predominante frente a los otros tipos de perfiles.
•
Transformar la ontología al formato OWL (Web Ontology Language), ya que actualmente se
encuentra en el formato RDF, con el objetivo de poder hacer inferencias sobre ella. También
se plantea utilizar F-logic para este objetivo. Aunque sí que es posible hacer inferencia con
RDF, esta inferencia es muy limitada y por tanto, si deseamos hacer inferencias más
complejas nos veremos obligados a utilizar OWL, y en concreto OWL Lite o OWL DL. Con este
tipo de inferencias sobre la ontología se pueden obtener relaciones, entre elementos de la
ontología, que no están expresamente en la ontología. Otra alternativa es utilizar F-logic, el
cual es un lenguaje orientado a objetos y tiene las propiedades de herencia, polimorfismo,
encapsulación y métodos para realizar consultas o “queries”.
•
Crear una ontología de descripción de cursos adaptativos, ya que actualmente el formato
SCORM es la única garantía de independencia de descripción de un curso adaptativo, ya que
proporciona una forma estándar de descripción de un curso adaptativo. Sin embargo, la
complejidad de crear una API para leer y entender dicho formato, la evolución que han
tenido los sistemas adaptativos en los últimos años y la posibilidad de ampliación de dicha
descripción hacen que tengamos que buscar otra manera de describir un curso adaptativo
Javier Bravo Agapito
40
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
de una forma universal o mayoritariamente aceptada, de forma que la estructura de un
curso sea más flexible y no esté prefijada. La alternativa que se ha pensado en este trabajo
de iniciación a la investigación es la utilización de una ontología de descripción de cursos
adaptativos cuyo objetivo reside en crear un vocabulario común para la descripción de un
curso adaptativo de cualquier ámbito.
Javier Bravo Agapito
41
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
Referencias Bibliográficas
[1]
Chen, F.; Myers, B.; Yaron, D.. Tech. Report - "Using Handheld Devices for Tests in
Classes", CMU-CS-00-152, Carnegie Mellon University School of Computer Science,
and Tech. Rep. CMU-HCII-00-101, Human Computer Interaction Institute. Human
Computer Interaction Institute. www.cs.cmu.edu/pebbles/papers/CMU-CS-00152.pdf . July, 2000.
[2]
Paredes, P. and Rodriguez, P. "A Mixed Approach to Modelling Learning Styles in
Adaptive Educational Hypermedia". En Advanced Technology for Learning, págs 210215. 2004.
[3]
Chin, D. "Empirical Evaluation of User Models and User-Adapted Systems". En
User Modeling and User-Adapted Interaction, págs 181-194. July, 2001.
[4]
Weibelzahl, S.; Weber, G. "Advantages, opportunities, and limits of empirical
evaluations: Evaluating Adaptive Systems". En Künstliche Intelligenz, págs 17-20.
2002.
[5]
Del Missier, F. and Ricci, F. "Understanding Recommender Systems: Experimental
Evaluation Challenges". En User Modeling: Workshop of EEAS, págs 31-40. June, 2003.
[6]
Markham, S.; Ceddia, J.; Sheard, J.; Burvill, C.; Weir, J.; Field, B.; Sterling, L. and
Stern, L. "Applying Agent Technology to Evaluation Tasks in E-Learning
Environments". En Exploring Educational Technologies - from Strategy to Implementation.
July, 2003.
[7]
Lavie, T.; Meyer, J.; Beugler, K.; Coughlin, J. "The Evaluation of In-Vehicle Adaptive
Systems". En User Modeling: Workshop on the EAS, págs 9-18. July, 2005.
[8]
Ortigosa, A. and Carro, R. M. "The Continuous Empirical Evaluation Approach:
Evaluating Adaptive Web-Based Courses". En User Modeling 2003, págs 163-167.
June, 2003.
[9]
Han, Jiawei. Data Minning concepts and techniques. San Francisco, California: Morgan
Kaufmann, 2001.
[10]
Carro, R.M.; Pulido, E. and Rodríguez, P. "Dynamic Generation of Adaptive
Internet-Based Courses". En Journal of Network and Computer Applications, págs 249257. 1999.
[11]
de Bra, P.; Aerts, A.; Berden, B.; de Lange, B.; Rosseau, T.; Santic, T.; Smits, D. and
Stash, N. "AHA! the Adaptive Hypermedia Architecture". En Proceedings of the
Fourteenth ACM Conference on Hypertext and Hypermedia, págs 81-84. August, 2003.
[12]
Brusilovsky, P.; Eklund, J. and Schwarz, E. "Web-Based Education for all: A tool for
Javier Bravo Agapito
42
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
developing adaptive courseware". En Proceedings of 7th Intl World Wide Web
Conference, págs 291-300. April, 1998.
[13]
Moore, A.; Brailsford, T.J. and Stewart, C. "Personally tailored teaching in
WHURLE using conditional transclusion". En Proceedings of the Twelfth ACM
Conference on Hypertext and Hypermedia, págs 163-164. August, 2001.
[14]
Weber, G.; Kuhl, H. and Weibelzahl, S. "Developing Adaptive Internet Based
Courses with the Authoring System NetCoach". En Hypermedia: Openness, Structural
Awareness, and Adaptivity, págs 226-238. July, 2001.
[15]
Weibelzahl, S. Evaluation of Adaptive Systems. Tesis doctoral. University of Trier,
Germany. October, 2002.
[16]
Weibelzahl, S.; Chin, D. and Weber, G. Proceedings of First Workshop on Empirical
Evaluations of Adaptive Systems. July, 2001.
[17]
Weibelzahl, S. and Paramythis, A. Proceedings of Second Workshop on Empirical
Evaluation of Adaptive Systems. June, 2003.
[18]
Weibelzahl, S. and Paramythis, A. Proceedings of Third Workshop on Empirical
Evaluation of Adaptive Systems. August, 2004.
[19]
Weibelzahl, S.; Paramythis, A. and Masthoff, J. Proceedings of Fourth Workshop on
Empirical Evaluation of Adaptive Systems. July, 2005.
[20]
Weibelzahl, S. and Cristea, A. Proceedings of Fifth Workshop on User-Centred Design
and Evaluation of Adaptive Systems. June, 2006.
[21]
Keppel, G.; Saufley, W.; and Tokunaga, H. Introduction to Design and Analysis: A
Student's Handbook, 2nd ed. New York: W.H. Freeman and Co., 2000.
[22]
Whiteside, J.. Usability Engineering: Our Experience and Evolution. M. Helander (Ed.)
New York: North-Holland, 1988.
[23]
Muñoz, F. and Ortigosa, A. "Using Adaptive Hypermedia to Support Diversity in
Secundary Schools". En ICALT2006: Proceedings of the 6th IEEE International Conference
on Advanced Learning Technologies, págs 1055-1059. July, 2006.
[24]
Pérez López, César. Técnicas de Muestreo Estadístico: Guía Práctica y Aplicaciones. Ed.
RA-MA, 1999.
[25]
Staff, C. "Evaluating a General-Purpose Adaptive Hypertext System". En AH2004:
Workshop Proceedings of EEAS, págs 211-220. August, 2004.
[26]
Peña Sánchez de Rivera, Daniel. Estadística Modelos y métodos: Modelos Lineales y
Series Temporales. Alianza Editorial, 1992.
[27]
Müller, C.; Grossmann-Hutter, B.; Jameson, A.; Rummer, R. and Wittig, F.
Javier Bravo Agapito
43
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
"Recognizing time pressure and cognitive load on the basis of speech". En
Proceedings of User Modeling 2001 (LNCS, 2109), págs 24-33. July, 2001.
[28]
Brunstein, A.; Jaqueline, W.; Naumann, A.; Krems, J.F. "Learning grammar with
adaptive hypertexts: Reading or searching?". En Proceedings of Adaptive Hypermedia
and Adaptive Web Systems (LNCS, 2347), págs 372-375. May, 2002.
[29]
Martin, B and Mitrovic, T. "WETAS: a web-based authoring system for constraintbased ITS". En Adaptive Hypermedia and Adaptive Web-Based Systems (LNCS, 2347), págs
296-305. May, 2002.
[30]
Kumar A. "Evaluating Adaptive Generation of Problems in Programming Tutors Two Studies". En AH2006: Workshop Proceedings of User-Centred Design and Evaluation of
Adaptive Systems (Lecture Notes in Learning and Teaching), págs 450-459. June, 2006.
[31]
Paramythis, A. and Weibelzahl, S. "A Decomposition Model for the Layered
Evaluation of Interactive Adaptive Systems". En UM2005: Proceedings of the
International Conference on User Modeling (LNCS, 3538), págs 438-442. July, 2005.
[32]
de Bra, P.; Houben, G.J. and Wu, H. "AHAM: A Dexter-based reference model for
adaptive hypermedia". En Proceedings of the ACM Conference on Hypertext and
Hypermedia, págs 147-156. February, 1999.
[33]
Koch, N.; Wirsing, M. "The Munich Reference Model for Adaptive Hypermedia
applications". En AH2002: Proceedings of the Second International Conference on Adaptive
Hypermedia and Adaptive Web Based Systems (LNCS, 2347), págs 213-222. May, 2002.
[34]
Felder, R. M. and Silverman, L. K. Learning Styles and Teaching Styles in Engineering
Education. Engineering Education, 1988.
[35]
Dodds, Philip. SCORM Content Agregation Model. 2004.
[36]
Dodds, Philip. SCORM Sequencing and Navigation. 2004.
[37]
Gruber, T. "A translation approach to portable ontology specifications". En
Knowledge Acquisition, págs 199-220. 1993.
[38]
Noy, N. and McGuinness, D. "Ontology Development 101: A Guide to Creating
Your First Ontology". En http://protege.stanford.edu/publications/ontology_
development/ontology101.html. Stanford Knowledge Systems Laboratory. March,
2001.
[39]
DeGroot, Morris H. Probability and Statistics. Addison-Wesley Publishing Company,
1986.
[40]
García Ferrando, Manuel. Socioestadística: Aplicación de la Estadística en Sociología.
Alianza Editorial, 1995.
Javier Bravo Agapito
44
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
[41]
Owen, Donald B. Handbook of Statistical Tables. Addison-Wesley Publishing
Company, 1962.
Otra referencia bibliográfica utilizada durante la realización de este trabajo ha sido:
Gena, C. "Methods and Techniques for the Evaluation of User-Adaptive
Systems". En The Knowledge Engineering Review, págs 1-37. 2005.
Javier Bravo Agapito
45
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
APÉNDICE
I - Paper(s)
II - Ejemplo de simulación
III - Ontología
i - Fichero Ontologia.rdfs
ii - Fichero Ontologia.rdf
IV - Tabla de la distribución Normal(0,1)
Javier Bravo Agapito
46
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
I - Paper(s)
Javier Bravo Agapito
47
Validating the Evaluation of Adaptive Systems
by User Profile Simulation
Javier Bravo and Alvaro Ortigosa
Escuela Politécnica Superior, Universidad Autónoma de Madrid, Spain
{javier.bravo, alvaro.ortigosa}@uam.es ??
Abstract. Availability of automated tools and methods to evaluate
adaptive systems is a fundamental requirement to promote a wider adoption of these systems. An obstacle in this direction is the difficulty of
validating any automatic tool created to help on the evaluation of adaptive systems. In this work a simulation-based technique is proposed as an
economic way for testing evaluation tools based on log analysis. Simulog,
a tool that implements this simulation technique, is also presented.
1
Introduction
Evaluation of adaptive hypermedia systems is a difficult task, as it is shown
by many studies (Weibelzahl et al. [1], Missier et al. [2], Markham et al. [3],
and Lavie et al. [4], among others). This is also true when considering Adaptive
Educational Hypermedia (AEH). Particularly, evaluating if an AEH system is
making good adaptation decisions for a given student profile is a complex task,
which can be improved by using automatic tool support. For example, an evaluation tool can help to identify possible failures in the adaptation rules for a
course, and even it can suggest corrections oriented to improve these rules [5].
On this way, an automatic tool would allow the course designer to save time,
since it does not require a manual analysis of the data. Besides, this tool may
support a continuous evaluation of the adaptation effectiveness, not limited to
a fixed frame of time [6].
We are specially interested in evaluation tools based on analysis of user log
files. These tools, by using techniques and methods from Data Mining, can search
through the records of users actions, looking for unexpected behavioral patterns.
In this way unusual patterns, called anomalies on this work, can hint about
possible failures in the adaptation rules. For example, a simple anomaly can be
a number of students failing to pass the test associated with a given educational
activity. This situation can suggest that there is a problem with the adaptation
rules applied to this group of students.
A possible drawback of using this type of evaluation tools is that they need
to be validated. In this sense, the main problem is to check if the tool is able to
find the anomalies contained in a set of log files. If the tool is based on statistical
??
This project has been partially funded by the MEC, Spain (TIN2004-03140).
methods for searching anomalies, a significant number of students exhibiting the
unusual behavior should be processed before detecting a potential problem. This
produces two difficulties: a large set of student logs is needed to test the tool
and, still worse, the logs should be manually analyzed in order to contrast the
results achieved by the tool.
A more practical alternative would be using simulation methods. Specifically,
we propose to use a tool to simulate the behavior of students by generating logs
which are similar to the logs produced by real students using the AEH system.
For example, it is possible to generate data containing an anomaly, consequence
of a hypothetical problem in the AEH system decisions. Then, the evaluation tool
can be fed with the generated data and to test if it is able to find the anomaly
in the data and suggest possible causes. In this way, the evaluator has control
about the data provided to the evaluation tool and can anticipate the expected
output from it. In this work we present a tool, named Simulog (Simulation of
User Logs), designed to simulate user behaviors represented as log files.
2
Tool Proposal: Simulog
Figure 1 shows the context of Simulog. The tool was designed with the intention
that it could be used to test any evaluation tool based on log analysis. In this
way, both its inputs and output were designed for maximum generality.
Fig. 1. Architectural context for the evaluation and simulation tools
2.1
Inputs
Simulog simulates student behavior according to certain parameters. It receives
the course description, the user attributes, and the anomalies. The user at-
tributes define the profile of the simulated students. For example, it can be
specified that 20% of the students represented through the logs are textual learners, while 80% are visual learners, and that the average knowledge level of the
students is 7 out of 10. Next subsection explains how statistical methods are
used to generate user profiles according to these distributions.
The structure of course is described using the SCORM standard. Using the
XML-based SCORM specification, the course description is independent of the
target evaluation tool and adaptive system.
An important issue is to be able to specify the anomalies using an abstract
notation. With this goal, the adopted solution is to use ontologies. Ontology is
a formal concept of the Semantic Web field [7,8] that provides a shared common
knowledge with the possibility of making inference about this knowledge. In that
way, an ontology of anomalies was created in order to support the specification
of anomalies, that is, the unusual patterns that will included in the log files and
that are supposed to be detected by the evaluation tool.
Anomalies are classified in two groups (see figure 2): quantitative and qualitative. Quantitative anomalies reference to measurable situations by means of the
criteria of measurement presented by Whiteside (1988) [9]. The second group,
qualitative anomalies, makes reference to non-measurable criteria, as for example
the situation when student get lost navigating through the course.
Fig. 2. Classes of the ontology of anomalies
2.2
Simulation engine
The engine has a double function: generating the user models (that is, the set of
attributes describing the features of a given student) and generating the log files.
Together both of them constitute the user profile. The engine generates the sample with the proportions of attributes (described in the previous section) using
the Normal distribution. Two conditions are fulfilled in this distribution: representativeness and randomness; without these conditions the simulation would
not generate reliable data. Besides, the Normal distribution is used in techniques
of people simulation, because it produces results next to the real ones. In fact,
many parameters of the nature are distributed following a Normal distribution,
like for example the length of an arm, height of an individual, etc. [10].
In order to generate the correct proportion of users, some calculations have
to be done. For example, if regarding the visual-verbal dimension the goal is to
generate 75% of students with visual preferences and 25% with textual preferences, the random numbers must be generated following a Normal distribution1
with µ = 3.66 and σ = 2. Applying this method for each user model dimension
it is possible to generate a set of profiles containing the distribution of students
features specified by the Simulog user.
The simulated actions are also generated using a probabilistic model. For
example, the probability of success on a question, of leaving an activity before
completion, etc., is conditional to the criteria selected by the tool user.
2.3
Generation of Log Files
The structure of log files is composed by a user model, logs of activities, and
logs of updates. Figure 3 shows an example of a partial log file. The user model
stores the information about the student, in the form <attribute,value>. The
logs of updates store, in similar format, every actualization of the user model.
<log-root>
<user-model>
. . .
</user-model>
<log-activity>
<log activity="activity 1" score="0.0"
action="START-ACTIVITY" timestamp="2006-03-26T09:52:00"/>
<log activity="activity 1-1" score="0.3"
action="START-ACTIVITY" timestamp="2006-03-26T09:54:15"/>
<log activity="activity 1-1" score="0.5"
action="END-ACTIVITY" timestamp="2006-03-26T10:02:55"/>
</log-activity>
<log-update>
. . .
</log-update>
</log-root>
Fig. 3. Example of a partial log file
3
Related Work
This work presents a novel approach for simulating user behavior by generating
log files. This approach and the resulting tool can be used to validate tools
1
The statistical explanation of this result can be found in [10, p.253-255].
and methods reported in other works as, for example, Börner (2001) [11] and
Brusilovsky et al. (2001) [12]. Regarding similar uses of ontologies, Stetson et al.
used them for describing anomalies in the Medicine area [13].
4
Conclusions and Future Work
This paper proposes a practical way for testing evaluation tools designed for
evaluating AEH systems. Simulog, a simulation tool developed to implement this
approach, is also presented. However, there still remains much work to be done,
mainly regarding the use of Simulog for testing real evaluation tools. Planed
future work also includes adding new features to the simulation tool, such as the
capability of generating profiles using other types of well known distributions, like
T-Student or F-Snedecor. Besides, it would be desirable to define the ontology
using OWL (Web Ontology Language) or F-logic (the current version is in RDF).
Finally, we plan to create an ontology for adaptive course description.
References
1. S. Weibelzahl and G. Weber. Advantages, opportunities, and limits of empirical
evaluations: Evaluating adaptive systems. Künstliche Intelligenz, 3/02:17–20, 2002.
2. F. Del Missier and F. Ricci. Understanding recommender systems: Experimental
evaluation challenges. User Modeling: Workshop of EEAS, pages 31–40, June 2003.
3. S. Markham, J. Ceddia, J. Sheard, C. Burvill, J. Weir, B. Field, L. Sterling, and
L. Stern. Applying agent technology to evaluation tasks in e-learning environments.
Exploring Educational Technologies - from Strategy to Implementation, 2003.
4. T. Lavie, J. Meyer, K. Beugler, and J. F. Coughlin. The evaluation of in-vehicle
adaptive systems. User Modeling: Workshop on the EAS, pages 9–18, July 2005.
5. A. Ortigosa and R. M. Carro. The continuous empirical evaluation approach:
Evaluating adaptive web-based courses. User Modeling 2003 (Lecture Notes in
Computer Science, Volume 2702 / 2003), pages 163–167, June 2003.
6. A. Ortigosa and R. M. Carro. Continuous evaluation of adaptive web/based
courses. volume 4. IEEE Computer Society Learning Technology Task Force, 2002.
7. N. Noy and D. McGuinness. Ontology development 101: A guide to creating your
first ontology. March 2001.
8. T. Berners-Lee, J. Hendler, and O. Lassila. The semantic web: A new form of
web content that is meaningful to computers will unleash a revolution of new
possibilities. Scientific American, May 2001.
9. J. Whiteside. Usability Engineering: Our Experience and Evolution. M. Helander
(Ed.) New York: North-Holland, 1988.
10. M.H. DeGroot. Probability and Statistics. Addison-Wesley Ed., 1986.
11. K. Börner. Adaptation and evaluation of 3-dimensional collaborative information
visualizations. User Modeling: Workshop Proc. of EEAS, pages 33–40, July 2001.
12. P. Brusilovsky, C. Karagiannidis, and D. Sampson. The benefits of layered evaluation of adaptive applications and services. User Modeling: Workshop Proc. of
EEAS, pages 1–8, July 2001.
13. P. Stetson, L. McKnight, S. Bakken, C. Curran, T. Kubose, and J. Cimino. Development of an ontology to model medical errors, information needs, and the clinical
communication space. Proc AMIA Symp, 2001.
Integración y Prueba de Herramientas de
Evaluación en un Entorno Hipermedia
Adaptativo
Javier Bravo and Alvaro Ortigosa
Escuela Politécnica Superior, Universidad Autónoma de Madrid, Spain
{javier.bravo, alvaro.ortigosa}@uam.es
Resumen Los Sistemas Hipermedia Adaptativos, y en especial aquellos
orientados a la educación, han conseguido una amplia aceptación hoy en
dı́a. Sin embargo un problema pendiente de estos sistemas es la falta
de métodos eficientes para evaluar su funcionamiento y en especial sus
decisiones de adaptación. En este sentido, la utilización de herramientas
automáticas de evaluación puede ser de gran ayuda. Por este motivo, en
este artı́culo se propone una arquitectura para incorporar herramientas
de evaluación automática en el contexto de un Sistema Hipermedia Adaptativo orientado a la Educación. Además, se describe un método basado
en simulación que puede ser utilizado para validar estas herramientas
de evaluación, y se presenta una herramienta, Simulog, que implementa
dicho método.
1.
Introducción
Los Sistemas Hipermedia Adaptativos (Adaptive Hypermedia Systems - AHS)
son sistemas de acceso a contenidos a través de la Web que, basados en un modelo del usuario, pueden personalizar los contenidos mostrados a cada usuario.
Estos sistemas han experimentado en los últimos años un gran desarrollo, debido fundamentalmente a la aparición y el establecimiento de nuevas tecnologı́as,
como por ejemplo lenguajes de programación especı́ficos para aplicaciones Web,
nuevos dispositivos y protocolos de comunicación [1]. En particular, los Sistemas Hipermedia Adaptativos orientados la Enseñanza (Adaptive Educational
Hypermedia - AEH) utilizan un modelo del estudiante para, en base a reglas de
adaptación, personalizar de acuerdo al perfil del estudiante la estructura y contenido de los cursos ofrecidos. Ejemplos exitosos de este tipo de sistemas, como
Interbook [2], AHA [3], TANGOW [4] y WHURLE [5] entre otros, muestran que
los sistemas AEH son ampliamente aceptados por los usuarios.
Sin embargo, dicha aceptación no es suficiente para valorar la efectividad de
estos sistemas, sino que es necesario el uso de técnicas de evaluación empı́rica.
Contrario a lo que cabrı́a esperar, el uso de estas técnicas no es una práctica
habitual en la evaluación de estos sistemas. De hecho, un estudio realizado por
Chin (2002)[6], ampliamente citado, refleja esta situación. En este estudio, se
analizan los sistemas adaptativos publicados en la revista UMUAI, mostrando
que tan sólo un cuarto de los analizados incluyen algún tipo de evaluación. No
obstante, esta tendencia está cambiando en los últimos años, como lo demuestra,
por ejemplo, la serie de workshops organizados sobre el tema [7,8,9,10], donde
se han presentado numerosos métodos y técnicas de evaluación empı́rica.
En general, la evaluación de sistemas adaptativos es una tarea compleja
[11][12][13][14]. Entre otras cosas, es muy difı́cil valorar si un sistema AEH
está tomando las decisiones de adaptación correctas para un perfil de estudiante
determinado, es decir, si las reglas de adaptación son adecuadas para ese perfil.
Sin embargo, esta dificultad puede ser disminuida mediante el uso de herramientas automáticas de evaluación.
Las herramientas automáticas de evaluación pueden ayudar, por ejemplo, a
identificar posibles fallos en las reglas de adaptación de un sistema AEH e incluso
pueden sugerir correcciones encaminadas a mejorar estas reglas. En este sentido,
el uso de este tipo de herramientas evita que el diseñador del curso haga un
análisis manual de los datos y, por tanto, le permite ahorrar tiempo y esfuerzo
[15].
En este trabajo se propone un modelo de evaluación automática basado en
el uso de herramientas capaces de, a través del análisis de los ficheros logs de
los usuarios, evaluar las reglas y los criterios de adaptación de un sistema AEH
o de un curso adaptativo. Dichas herramientas pueden ser capaces de encontrar, mediante el uso de técnicas usadas en la Minerı́a de Datos, patrones de
comportamiento no esperados. Un ejemplo de estos patrones de comportamiento inesperados, denominados anomalı́as, puede ser que un elevado número de
estudiantes fallen en un test asociado a una actividad educativa concreta. Este
tipo de anomalı́as en los logs puede indicar que existe un problema con las reglas
de adaptación asociadas a ese grupo de estudiantes.
Si bien este tipo de herramienta automática de evaluación puede permitir encontrar problemas que de otra forma serı́a muy difı́cil descubrir, un inconveniente
asociado con su uso es que son de difı́cil validación. Es decir, el problema principal consiste en comprobar si la herramienta es capaz de encontrar las anomalı́as
contenidas en un conjunto de ficheros logs. Tanto el análisis como la obtención
de los logs plantean dos dificultades: por un lado, se necesita un amplio conjunto de logs (difı́ciles de conseguir en muchas ocasiones) para determinar si las
anomalı́as encontradas responden al patrón de comportamiento de un número
significativo de estudiantes; por otro lado, debe hacerse el análisis de los logs de
forma manual para contrastar los resultados proporcionados por la herramienta
de evaluación.
Una posible alternativa, planteada en este trabajo, es utilizar métodos de simulación con el objetivo de solventar estas dos dificultades. Por tanto, se propone
usar una herramienta capaz de simular los comportamientos de los estudiantes,
es decir, capaz de generar ficheros logs producidos por una supuesta interacción
de estudiantes con el sistema AEH. Hay que destacar que esta simulación es
una aproximación a lo que producirı́an usuarios reales, pero es una manera muy
rápida de generar determinados tipos de patrones de comportamiento. Consecuentemente, es muy fácil comprobar si la herramienta de evaluación funciona
de forma correcta, ya que es posible usar logs simulados, conteniendo anomalı́as
conocidas, para comprobar si la herramienta de evaluación es capaz de detectar
dichas anomalı́as.
En este trabajo se presenta una propuesta de arquitectura para incorporar
una herramienta automática de evaluación en el contexto de un sistema AEH.
Dicha arquitectura prevé, entre otras cosas, la utilización de una herramienta
de simulación para comprobar el correcto funcionamiento de la herramienta de
evaluación en ese contexto. Con este fin, también se presenta un modelo de
simulación y una herramienta (Simulog) que implementa dicho modelo.
2.
Arquitectura Funcional de Simulog
Tı́picamente los sistemas AEH están formados por un motor de adaptación
que, en base a una descripción general del curso y al perfil de los estudiantes,
es capaz de generar un curso personalizado para cada uno de ellos. Con este fin,
la descripción del curso contiene, además de los contenidos educativos, reglas
de adaptación o algún mecanismo similar de razonamiento. Estas reglas indican
cómo los contenidos deben ser seleccionados y combinados para adaptarse a las
caracterı́sticas y comportamiento (durante la interacción con el sistema) de cada
estudiante. El perfil del estudiante, por su parte, contiene información relativa
a atributos relevantes del estudiante (como por ejemplo nivel de conocimientos
previos y estilo de aprendizaje preferido), ası́ como un registro de las actividades
desarrolladas por el estudiante en el curso (por ejemplo, actividades educativas que ha realizado y resultados obtenidos en las pruebas). Esto es lo que se
denomina sistema AEH en la mitad superior de la figura 1. En esta figura se
muestra cómo el sistema AEH toma los datos del estudiante y la descripción del
curso adaptativo, incluyendo las reglas de adaptación, y en base a eso genera de
forma dinámica una página web que se presenta al estudiante (en la figura están
indicadas con la letra W). Las acciones del usuario provocarán la actualización
del perfil del estudiante y eventualmente nuevas partes del curso irán siendo
presentadas.
En este contexto, el problema de evaluación de las reglas de adaptación consiste en examinar si dichas reglas generan el contenido apropiado para cada tipo
de estudiante. Ası́, una herramienta de evaluación puede tomar la información
sobre los perfiles (caracterı́sticas y log de la interacción con el sistema de cada
estudiante) y la descripción del curso (contenido y reglas) y analizar los logs en
busca de patrones recurrentes de comportamiento que parezcan apartarse del
comportamiento esperable o deseable de los estudiantes o parezcan indicar potenciales errores en las reglas de adaptación. Estos tipos de patrones son los que
se denominan anomalı́as. Una vez que las anomalı́as son detectadas, la herramienta de evaluación se las presenta al usuario evaluador. Este usuario evaluador
es la persona encargada de analizar el funcionamiento del sistema AEH y, en este
caso, de analizar si las anomalı́as encontradas por la herramienta de evaluación
deben conducir a eventuales modificaciones en el diseño del curso. El evaluador
puede ser el propio diseñador del curso, o bien una persona únicamente dedica-
Figura 1. Arquitectura funcional de la herramienta de evaluación
da a analizar la calidad del sistema. Aquı́ se propone incorporar la componente
destinada a la evaluación como parte integral del AEH, ya que se considera un
elemento fundamental para mejorar la calidad de los sistemas AEH.
Un problema del enfoque propuesto en las lı́neas anteriores es que resulta
muy difı́cil valorar los resultados obtenidos en la evaluación. La validación de la
herramienta de evaluación puede ser dividida en dos partes:
a. comprobar que las anomalı́as reportadas por la herramienta realmente están
presentes en los logs analizados. Para ello, basta con requerir de la herra-
mienta que muestre los perfiles de los usuarios que presentan la anomalı́a
detectada. Es función del evaluador decidir si la anomalı́a está realmente
presente y si es necesario revisar el diseño del curso, en consecuencia.
b. comprobar que no existan anomalı́as en los logs que la herramienta no es
capaz de detectar e informar.
Esta segunda parte es más complicada, porque asegurar que la herramienta es
capaz de encontrar todas las anomalı́as posibles requerirı́a disponer de un amplio
conjunto de perfiles, es decir, disponer información sobre la interacción con el
curso de un gran número de estudiantes. Además, dichos perfiles deberı́an ser
analizados manualmente por el evaluador, para poder contrastar los resultados
producidos por la herramienta.
Por este motivo, en este trabajo se propone una forma de generar los perfiles
aplicando técnicas de simulación. Este método ha sido implementado a través
de la herramienta Simulog (Simulación de Usuarios a través de Logs). El evaluador especifica en Simulog las anomalı́as a generar en los logs (representadas
en la figura por la letra A) y las caracterı́sticas o atributos de los estudiantes
simulados (representados por UM). Simulog utiliza estos parámetros de entrada para generar los perfiles solicitados, ayudándose de la descripción del curso
(reglas de adaptación). Hay que indicar que los perfiles generados contienen en
su interior las anomalı́as solicitadas por el evaluador. Siguiendo con el diagrama
de la parte inferior de la figura 1, la herramienta de evaluación toma los perfiles
generados en la fase anterior con el objetivo de encontrar anomalı́as. Por último,
el evaluador recibe las anomalı́as (representadas en la figura por AG ) detectadas
por la herramienta de evaluación, y comprueba si estas anomalı́as son las mismas
que habı́a generado a través de la herramienta de simulación. De esta forma, es
posible verificar si la herramienta de evaluación funciona de forma correcta.
3.
Componentes de Simulog
Tal como se describió en el apartado anterior, el objetivo de Simulog es validar
herramientas o métodos de evaluación basados en análisis de logs. Para ello se
generan ficheros de logs de una manera controlada, para que puedan ser usados
como datos de entrada de la herramienta de evaluación.
Simulog fue diseñando buscando la mayor independencia posible tanto de la
herramienta de evaluación a validar, como del sistema AEH en sı́. Para ello, se
ha buscado definir las entradas y salidas de Simulog de forma genérica.
3.1.
Entradas en la Simulación
La estructura del curso es el primer parámetro necesario para la simulación
y para su descripción se ha elegido el formato estándar SCORM. El segundo
parámetro que recibe la herramienta es la especificación de los atributos del
grupo de estudiantes a simular.
Figura 2. Vista de Simulog
Como se puede observar en la figura 2, Simulog proporciona al evaluador la
posibilidad de definir el perfil de los estudiantes a simular estableciendo porcentajes estadı́sticos que tienen que cumplir los perfiles generados. Por ejemplo, la
figura 2 muestra que se deben simular los perfiles de estudiantes de tal forma que
un 20 % tenga un estilo secuencial de aprendizaje, mientras que el 80 % restante
será global; además, estos estudiantes tienen que tener aptitudes visuales en un
75 % y un 25 % de verbales, y además deben tener un conocimiento previo de 7
sobre 10 (70 %) en promedio.
El último parámetro son las anomalı́as, es decir, aquellas situaciones en las
que los estudiantes comenten más fallos de lo que cabrı́a esperar. Se puede observar en la figura 2 que Simulog proporciona un editor de anomalı́as, dependiente
de una ontologı́a de anomalı́as.
3.2.
Generación de Perfiles
El núcleo de la herramienta es el motor de simulación, cuya función es la de
generar Perfiles de Usuario (Modelos de Usuario + Logs). Un paso previo a la
simulación es generar una muestra de los atributos de los estudiantes. Esta muestra está constituida por números aleatorios que siguen una distribución Normal
de parámetros µ y σ. El valor de estos parámetros depende de la proporción
de las dimensiones. Por ejemplo, si se quisieran generar usuarios con el 75 % de
aptitudes visuales y 25 % de verbales, los parámetros serı́an µ = 3,66 y σ = 2
[16]. Después, estos atributos generados son los que determinarán mediante un
modelo probabilı́stico si el estudiante abandona una determinada actividad antes
de terminarla, si se obtiene éxito en una determinada cuestión, etc. Por tanto,
los atributos del usuario condicionan los valores de la probabilidad dada por el
modelo probabilı́stico.
<log-root>
<user-model>
<dimension name="sequential" value="2.5" />
<dimension name="global" value="8.7" />
<dimension name="prevKnowledge" value="6.5" />
</user-model>
<log-activity>
. . .
<log activity="activity 1-2" score="0.5"
action="START-ACTIVITY" timestamp="2006-03-26T10:03:04"/>
<log activity="activity 1-2" score="0.7"
action="END-ACTIVITY" timestamp="2006-03-26T10:14:53"/>
<log activity="activity 1" score="0.7"
action="END-ACTIVITY" timestamp="2006-03-26T10:15:05"/>
</log-activity>
<log-update />
</log-root>
Figura 3. Ejemplo de la estructura de un Perfil de Usuario
La salida producida por el motor de simulación son los Perfiles de Usuarios
simulados, representados en los ficheros de logs. Éstos están constituidos por:
lista de atributos de cada usuario, logs de las actividades, logs de las actualizaciones del Modelo de Usuario. En la figura no. 3 se puede observar un ejemplo
del formato de salida de los logs.
4.
Trabajo Relacionado
Este trabajo presenta un enfoque novedoso para simular los comportamientos
de los usuarios mediante la generación de ficheros de logs. Sin embargo, pueden
encontrarse otros desarrollos sobre simulación de usuarios, pero su objetivo difiere claramente al presentado aquı́. Por ejemplo, Castillo et al. [17] propone
simular estudiantes mediante el uso de redes bayesianas. El planteamiento que
se propone en este estudio puede utilizarse para valorar la efectividad de métodos
y herramientas de evaluación como las propuestas por Börner [18], Brusilovsky
[19], Markham [13], Staff [20] y Sosnovsky(2005) [21].
5.
Conclusiones y Trabajo Futuro
En este artı́culo se propone una arquitectura para incorporar herramientas
de evaluación empı́rica en el contexto de un sistema AEH. Ası́ mismo, se propone
una forma económica para ayudar en la validación de este tipo de herramientas
o métodos de evaluación. En este sentido se presenta Simulog, una herramienta
de simulación de Perfiles de Usuarios.
Estas herramientas constituyen valiosas aportaciones al desarrollo y mantenimiento de sistemas AEH. Sin embargo, tienen limitaciones y aún queda mucho
trabajo por hacer. En particular, el trabajo futuro incluye un mayor desarrollo de la ontologı́a de anomalı́as actualmente en uso, ası́ como la creación de
una ontologı́a de descripción de cursos, que pueda emplearse como alternativa
al formato SCORM.
Agradecimientos
Este proyecto ha sido parcialmente subvencionado por el Ministerio de Educación y Ciencia, TIN2004-03140.
Referencias
1. F. Chen, B. Myers, and D. Yaron. Using Handheld Devices for Tests in Classes.
Technical report, CMU-CS-00-152, Carnegie Mellon University School of Computer Science, and Tech. Rep. CMU-HCII-00-101, Human Computer Interaction
Institute, July 2000. www.cs.cmu.edu/ pebbles/papers/CMU-CS-00-152.pdf.
2. P. Brusilovsky, J. Eklund, and E. Schwarz. Web-based education for all: A tool for
developing adaptive courseware. Proc. of 7th Intl World Wide Web Conference,
pages 291–300, 1998.
3. P. De Bra, A. Aerts, B. Berden, B. De Lange, B. Rosseau, T. Santic, D. Smits, and
N. Stash. AHA! The Adaptive Hypermedia Architecture. Proc. of the fourteenth
ACM conference on Hypertext and Hypermedia, pages 81–84, 2003.
4. R.M. Carro, E. Pulido, and P. Rodriguez. Dynamic generation of adaptive Internetbased courses. Journal of Network and Computer Applications, 22:249–257, 1999.
5. A. Moore, T.J. Brailsford, and C.D. Stewart. Personally tailored teaching in
WHURLE using conditional transclusion. Proceedings of the Twelfth ACM conference on Hypertext and Hypermedia, 2001.
6. D. Chin. Empirical Evaluation of User Models and User-Adapted Systems. User
Modeling and User-Adapted Interaction, 11:181–194, 2001.
7. S. Weibelzahl, D. Chin, and G. Weber. First Workshop on Empirical Evaluations
of Adaptive Systems. In UM2001: First Workshop on Empirical Evaluations of
Adaptive Systems. Springer Verlag, July 2001.
8. S. Weibelzahl and A. Paramythis. Second Workshop on Empirical Evaluation
of Adaptive Systems. In UM2003: Second Workshop on Empirical Evaluation of
Adaptive Systems. Pittsburgh, Johnstown, USA, Springer Verlag, June 2003.
9. S. Weibelzahl and A. Paramythis. Third Workshop on Empirical Evaluation of
Adaptive Systems. In AH2004: Workshop Proceedings - Part I. Eindhoven University of Technology, The Netherlands, Springer Verlag, August 2004.
10. S. Weibelzahl, A. Paramythis, and J. Masthoff. Fourth Workshop on Empirical
Evaluation of Adaptive Systems. In UM2005: Fourth Workshop on Empirical Evaluation of Adaptive Systems. Springer Verlag, July 2005.
11. S. Weibelzahl and G. Weber. Advantages, Opportunities, and Limits of Empirical
Evaluations: Evaluating Adaptive Systems. Künstliche Intelligenz, 3/02:17–20,
2002.
12. F. Del Missier and F. Ricci. Understanding Recommender Systems: Experimental
Evaluation Challenges. User Modeling: Workshop of EEAS, pages 31–40, June
2003.
13. S. Markham, J. Ceddia, J. Sheard, C. Burvill, J. Weir, B. Field, L. Sterling, and
L. Stern. Applying Agent Technology to Evaluation Tasks in E-Learning Environments. Exploring Educational Technologies - from Strategy to Implementation,
2003.
14. T. Lavie, J. Meyer, K. Beugler, and J.F. Coughlin. The Evaluation of In-Vehicle
Adaptive Systems. User Modeling: Workshop on the EAS, pages 9–18, July 2005.
15. A. Ortigosa and R. M. Carro. The Continuous Empirical Evaluation Approach:
Evaluating Adaptive Web-Based Courses. User Modeling 2003 (Lecture Notes in
Computer Science, Volume 2702 / 2003), pages 163–167, June 2003.
16. J. Bravo and A. Ortigosa. Validating the Evaluation of Adaptive Systems by User
Profile Simulation. AH2006: Workshop on User-Centred Design and Evaluation of
Adaptive Systems, June 2006.
17. G. Castillo, J. Gama, and A. Breda. Adaptive Bayes for a Student Modeling
Prediction Task Based on Learning Styles. User Modeling 2003, June 2003.
18. K. Börner. Adaptation and Evaluation of 3-Dimensional Collaborative Information
Visualizations. User Modeling: Workshop Proc. of EEAS, pages 33–40, July 2001.
19. P. Brusilovsky, C. Karagiannidis, and D. Sampson. The Benefits of Layered Evaluation of Adaptive Applications and Services. User Modeling: Workshop Proc. of
EEAS, pages 1–8, July 2001.
20. C. Staff. Evaluating a General-Purpose Adaptive Hypertext System. AH2004:
Workshop Proceedings of EEAS, pages 211–220, August 2004.
21. S. Sosnovsky and P. Brusilovsky. Layered Evaluation of Topic-Based Adaptation
to Student Knowledge. User Modeling 2005: Fourth Workshop on the Evaluation
of Adaptive Systems, pages 47–56, July 2005.
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
II - Ejemplo de simulación
<log-root>
<user-model>
<dimension name=”nombre ” value=” Estudiante_1” />
<dimension name=”edad ” value=”12” />
<dimension name=”lenguaje” value=”spanish” />
<dimension name=”nivel” value=” bajo” />
<dimension name=”sequential” value=” 2.7” />
<dimension name=”global” value=”6.3” />
<dimension name=”visual” value=”8,2” />
<dimension name=”verbal” value=”1,8” />
<dimension name=”previous-knowledge” value=”6,4” />
</user-model>
<log-activity>
<log activity=” activity_1” score=”0.0” action=”START” timestamp=”2006-07-03T09:52:12“ />
<log activity=” activity_1t” score=”0.0” action=”START” timestamp=”2006-07-03T09:53:01“ />
<log activity=” activity_1t” score=”0.0” action=”END-ACTIVITY”
timestamp=”2006-07-03T10:10:23“ />
<log activity=” activity_1e” score=”0.0” action=”START” timestamp=”2006-07-03T10:10:40“ />
<log activity=” activity_1e” score=”1.0” action=”END-ACTIVITY”
timestamp=”2006-07-03T10:17:20“ />
<log activity=” activity_1” score=”0.0” action=”FINISHED”
timestamp=”2006-07-03T10:17:25“ />
<log activity=” activity_2” score=”1.0” action=”START” timestamp=”2006-07-03T10:20:00“ />
<log activity=” activity_2t” score=”1.0” action=”START” timestamp=”2006-07-03T10:20:20“ />
<log activity=” activity_2t” score=”1.0” action=”END-ACTIVITY”
timestamp=”2006-07-03T10:26:05“ />
<log activity=” activity_2e” score=”1.0” action=”START” timestamp=”2006-07-03T10:26:13“ />
<log activity=” activity_2e” score=”0.8” action=”END-ACTIVITY”
timestamp=”2006-07-03T10:31:04“ />
<log activity=” activity_2” score=”1.0” action=”FINISHED”
timestamp=”2006-07-03T10:20:00“ />
<log activity=” activity_3” score=”0.8” action=”START” timestamp=”2006-07-03T10:32:03“ />
<log activity=” activity_3t” score=”0.8” action=”START” timestamp=”2006-07-03T10:32:03“ />
<log activity=” activity_3t” score=”0.8” action=”END-ACTIVITY”
timestamp=”2006-07-03T10:42:56“ />
<log activity=” activity_3e” score=”0.8” action=”START” timestamp=”2006-07-03T10:43:05“ />
<log activity=” activity_3e” score=”0.8” action=”LEAVE-ACTIVITY”
timestamp=”2006-07-03T10:45:34“ />
<log activity=” activity_3” score=”0.8” action=”NOT-FINISHED”
timestamp=”2006-07-03T10:45:44“ />
</log-activity>
<log-update>
<update name=” “ value=” “ />
</log-update>
</log-root>
Javier Bravo Agapito
62
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
III - Ontología
i - Fichero Ontologia.rdfs
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rdf:RDF [
<!ENTITY rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY a 'http://protege.stanford.edu/system#'>
<!ENTITY simulo 'http://tangow.ii.uam.es/simulo#'>
<!ENTITY rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
]>
<rdf:RDF xmlns:rdf="&rdf;"
xmlns:a="&a;"
xmlns:simulo="&simulo;"
xmlns:rdfs="&rdfs;">
<rdfs:Class rdf:about="&simulo;Activity"
rdfs:label="Activity">
<rdfs:subClassOf rdf:resource="&rdfs;Resource"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Activity_Failures"
rdfs:label="Activity_Failures">
<rdfs:subClassOf rdf:resource="&simulo;Cualitative"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Anomaly"
a:role="abstract"
rdfs:label="Anomaly">
<rdfs:subClassOf rdf:resource="&rdfs;Resource"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Complex"
a:role="abstract"
rdfs:label="Complex">
<rdfs:subClassOf rdf:resource="&simulo;Criterion"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Concept"
rdfs:label="Concept">
<rdfs:subClassOf rdf:resource="&rdfs;Resource"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Criterion"
a:role="abstract"
rdfs:label="Criterion">
<rdfs:subClassOf rdf:resource="&rdfs;Resource"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Cualitative"
a:role="abstract"
rdfs:label="Cualitative">
<rdfs:subClassOf rdf:resource="&simulo;Anomaly"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Cuantitative"
Javier Bravo Agapito
63
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
a:role="abstract"
rdfs:label="Cuantitative">
<rdfs:subClassOf rdf:resource="&simulo;Anomaly"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Dimension"
rdfs:label="Dimension">
<rdfs:subClassOf rdf:resource="&rdfs;Resource"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Dimension_Criterion"
rdfs:label="Dimension_Criterion">
<rdfs:subClassOf rdf:resource="&simulo;Complex"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Equality"
rdfs:label="Equality">
<rdfs:subClassOf rdf:resource="&simulo;Property"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Failure_Criterion"
rdfs:label="Failure_Criterion">
<rdfs:subClassOf rdf:resource="&simulo;Complex"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Frequency"
a:role="abstract"
rdfs:label="Frequency">
<rdfs:subClassOf rdf:resource="&simulo;Cuantitative"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Frequency_Criterion"
rdfs:label="Frequency_Criterion">
<rdfs:subClassOf rdf:resource="&simulo;Simple"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Frequency_of_Errors"
rdfs:label="Frequency_of_Errors">
<rdfs:subClassOf rdf:resource="&simulo;Frequency"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Frequency_of_Queries"
rdfs:label="Frequency_of_Queries">
<rdfs:subClassOf rdf:resource="&simulo;Frequency"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Inequality"
rdfs:label="Inequality">
<rdfs:subClassOf rdf:resource="&simulo;Property"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Percentage"
a:role="abstract"
rdfs:label="Percentage">
<rdfs:subClassOf rdf:resource="&simulo;Cuantitative"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Percentage_Criterion"
rdfs:label="Percentage_Criterion">
<rdfs:subClassOf rdf:resource="&simulo;Simple"/>
</rdfs:Class>
Javier Bravo Agapito
64
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
<rdfs:Class rdf:about="&simulo;Percentage_in_Activities"
rdfs:label="Percentage_in_Activities">
<rdfs:subClassOf rdf:resource="&simulo;Percentage"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Percentage_of_Comments"
rdfs:label="Percentage_of_Comments">
<rdfs:subClassOf rdf:resource="&simulo;Percentage"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Percentage_of_Errors"
rdfs:label="Percentage_of_Errors">
<rdfs:subClassOf rdf:resource="&simulo;Percentage"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Property"
a:role="abstract"
rdfs:label="Property">
<rdfs:subClassOf rdf:resource="&rdfs;Resource"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Simple"
a:role="abstract"
rdfs:label="Simple">
<rdfs:subClassOf rdf:resource="&simulo;Criterion"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Time"
a:role="abstract"
rdfs:label="Time">
<rdfs:subClassOf rdf:resource="&simulo;Cuantitative"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Time_Criterion"
rdfs:label="Time_Criterion">
<rdfs:subClassOf rdf:resource="&simulo;Simple"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Time_in_Activities"
rdfs:label="Time_in_Activities">
<rdfs:subClassOf rdf:resource="&simulo;Time"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Time_in_Errors"
rdfs:label="Time_in_Errors">
<rdfs:subClassOf rdf:resource="&simulo;Time"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Time_in_Queries"
rdfs:label="Time_in_Queries">
<rdfs:subClassOf rdf:resource="&simulo;Time"/>
</rdfs:Class>
<rdfs:Class rdf:about="&simulo;Undeterminated"
rdfs:label="Undeterminated">
<rdfs:subClassOf rdf:resource="&simulo;Property"/>
</rdfs:Class>
<rdf:Property rdf:about="&simulo;complement"
rdfs:label="complement">
<rdfs:range rdf:resource="&simulo;Activity"/>
Javier Bravo Agapito
65
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
<rdfs:domain rdf:resource="&simulo;Cuantitative"/>
</rdf:Property>
<rdf:Property rdf:about="&simulo;concept"
rdfs:label="concept">
<a:allowedClasses rdf:resource="&simulo;Activity"/>
<rdfs:domain rdf:resource="&simulo;Complex"/>
<a:allowedClasses rdf:resource="&simulo;Concept"/>
<a:allowedClasses rdf:resource="&simulo;Dimension"/>
<rdfs:range rdf:resource="&rdfs;Resource"/>
</rdf:Property>
<rdf:Property rdf:about="&simulo;criterion"
rdfs:label="criterion">
<rdfs:domain rdf:resource="&simulo;Anomaly"/>
<rdfs:range rdf:resource="&simulo;Criterion"/>
</rdf:Property>
<rdf:Property rdf:about="&simulo;id"
a:maxCardinality="1"
a:minCardinality="1"
rdfs:label="id">
<rdfs:domain rdf:resource="&simulo;Activity"/>
<rdfs:domain rdf:resource="&simulo;Anomaly"/>
<rdfs:domain rdf:resource="&simulo;Concept"/>
<rdfs:domain rdf:resource="&simulo;Criterion"/>
<rdfs:domain rdf:resource="&simulo;Dimension"/>
<rdfs:domain rdf:resource="&simulo;Property"/>
<rdfs:range rdf:resource="&rdfs;Literal"/>
</rdf:Property>
<rdf:Property rdf:about="&simulo;name"
a:maxCardinality="1"
rdfs:label="name">
<rdfs:domain rdf:resource="&simulo;Activity"/>
<rdfs:domain rdf:resource="&simulo;Dimension"/>
<rdfs:domain rdf:resource="&simulo;Property"/>
<rdfs:domain rdf:resource="&simulo;Simple"/>
<rdfs:range rdf:resource="&rdfs;Literal"/>
</rdf:Property>
<rdf:Property rdf:about="&simulo;property"
a:maxCardinality="1"
rdfs:label="property">
<rdfs:domain rdf:resource="&simulo;Anomaly"/>
<rdfs:domain rdf:resource="&simulo;Concept"/>
<rdfs:range rdf:resource="&simulo;Property"/>
</rdf:Property>
<rdf:Property rdf:about="&simulo;subject"
a:maxCardinality="1"
rdfs:label="subject">
<rdfs:domain rdf:resource="&simulo;Concept"/>
<a:allowedClasses rdf:resource="&simulo;Dimension"/>
<a:allowedClasses rdf:resource="&simulo;Dimension_Criterion"/>
<rdfs:range rdf:resource="&rdfs;Resource"/>
Javier Bravo Agapito
66
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
</rdf:Property>
<rdf:Property rdf:about="&simulo;subject_anomaly"
rdfs:label="subject_anomaly">
<rdfs:domain rdf:resource="&simulo;Anomaly"/>
<rdfs:range rdf:resource="&simulo;Criterion"/>
</rdf:Property>
<rdf:Property rdf:about="&simulo;value"
a:maxCardinality="1"
a:range="float"
rdfs:label="value">
<rdfs:domain rdf:resource="&simulo;Anomaly"/>
<rdfs:domain rdf:resource="&simulo;Concept"/>
<rdfs:range rdf:resource="&rdfs;Literal"/>
</rdf:Property>
</rdf:RDF>
Javier Bravo Agapito
67
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
ii - Fichero Ontologia.rdf
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rdf:RDF [
<!ENTITY rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY simulo 'http://tangow.ii.uam.es/simulo#'>
<!ENTITY rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
]>
<rdf:RDF xmlns:rdf="&rdf;"
xmlns:simulo="&simulo;"
xmlns:rdfs="&rdfs;">
<simulo:Frequency_of_Queries rdf:about="&simulo;anomalias2_Instance_10017"
simulo:id="A2010202"
simulo:value="25.0">
<rdfs:label>Dimension 3 less than 2.0 have Frequency of index use
greater than 25.0 in {Activity 3, Activity 2}</rdfs:label>
<simulo:subject_anomaly rdf:resource="&simulo;anomalias2_Instance_10018"/>
<simulo:complement rdf:resource="&simulo;anomalias_Instance_14"/>
<simulo:complement rdf:resource="&simulo;anomalias_Instance_15"/>
<simulo:property rdf:resource="&simulo;anomalias_Instance_33"/>
<simulo:criterion rdf:resource="&simulo;anomalias_Instance_9"/>
</simulo:Frequency_of_Queries>
<simulo:Dimension_Criterion rdf:about="&simulo;anomalias-2_Instance_10018"
simulo:id="Dc3"
rdfs:label="Dimension 3 less than 2.0">
<simulo:concept rdf:resource="&simulo;ontanomalies_Instance_5"/>
</simulo:Dimension_Criterion>
<simulo:Time_Criterion rdf:about="&simulo;anomalias_Instance_0"
simulo:id="C301"
simulo:name="Time to complete a activity"
rdfs:label="Time to complete a activity"/>
<simulo:Time_Criterion rdf:about="&simulo;anomalias_Instance_1"
simulo:id="C302"
simulo:name="Time spent in errors"
rdfs:label="Time spent in errors"/>
<simulo:Failure_Criterion rdf:about="&simulo;anomalias_Instance_10000"
simulo:id="C405"
rdfs:label="Failures in {Activity 3, Activity 2}">
<simulo:concept rdf:resource="&simulo;anomalias_Instance_14"/>
<simulo:concept rdf:resource="&simulo;anomalias_Instance_15"/>
</simulo:Failure_Criterion>
<simulo:Dimension_Criterion rdf:about="&simulo;anomalias_Instance_10003"
simulo:id="Dc1"
rdfs:label="Dimension 1 greater than 2.0">
<simulo:concept rdf:resource="&simulo;ontanomalies_Instance_3"/>
</simulo:Dimension_Criterion>
<simulo:Dimension rdf:about="&simulo;anomalias_Instance_10004"
simulo:id="Dim6"
Javier Bravo Agapito
68
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
simulo:name="Dimension 1"
rdfs:label="Dimension 1"/>
<simulo:Dimension rdf:about="&simulo;anomalias_Instance_10005"
simulo:id="Dim7"
simulo:name="Dimension 2"
rdfs:label="Dimension 2"/>
<simulo:Dimension rdf:about="&simulo;anomalias_Instance_10006"
simulo:id="Dim8"
simulo:name="Dimension 3"
rdfs:label="Dimension 3"/>
<simulo:Dimension_Criterion rdf:about="&simulo;anomalias_Instance_10007"
simulo:id="Dc2"
rdfs:label="Dimension 2 less than -5.0">
<simulo:concept rdf:resource="&simulo;ontanomalies_Instance_4"/>
</simulo:Dimension_Criterion>
<simulo:Undeterminated rdf:about="&simulo;anomalias_Instance_10011"
simulo:id="Pr301"
simulo:name="All"
rdfs:label="All"/>
<simulo:Dimension_Criterion rdf:about="&simulo;anomalias_Instance_10012"
simulo:id="Dc0"
rdfs:label=" All ">
<simulo:concept rdf:resource="&simulo;ontanomalies_Instance_2"/>
</simulo:Dimension_Criterion>
<simulo:Activity_Failures rdf:about="&simulo;anomalias_Instance_10013"
simulo:id="A10103"
simulo:value="70.0">
<rdfs:label>{Dimension 2 less than -5.0, Dimension 1 greater than
2.0} have Failures in Activity 1 greater than 70.0</rdfs:label>
<simulo:subject_anomaly
rdf:resource="&simulo;anomalias_Instance_10003"/>
<simulo:subject_anomaly
rdf:resource="&simulo;anomalias_Instance_10007"/>
<simulo:property rdf:resource="&simulo;anomalias_Instance_33"/>
<simulo:criterion rdf:resource="&simulo;anomalias_Instance_37"/>
</simulo:Activity_Failures>
<simulo:Percentage_Criterion rdf:about="&simulo;anomalias_Instance_11"
simulo:id="C206"
simulo:name="Percentage of successes"
rdfs:label="Percentage of successes"/>
<simulo:Frequency_Criterion rdf:about="&simulo;anomalias_Instance_12"
simulo:id="C102"
simulo:name="Frequency between errors"
rdfs:label="Frequency between errors"/>
<simulo:Activity rdf:about="&simulo;anomalias_Instance_13"
simulo:id="A1"
simulo:name="Activity 1"
rdfs:label="Activity 1"/>
<simulo:Activity rdf:about="&simulo;anomalias_Instance_14"
simulo:id="A2"
Javier Bravo Agapito
69
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
simulo:name="Activity 2"
rdfs:label="Activity 2"/>
<simulo:Activity rdf:about="&simulo;anomalias_Instance_15"
simulo:id="A3"
simulo:name="Activity 3"
rdfs:label="Activity 3"/>
<simulo:Activity rdf:about="&simulo;anomalias_Instance_16"
simulo:id="A4"
simulo:name="Activity 4"
rdfs:label="Activity 4"/>
<simulo:Activity rdf:about="&simulo;anomalias_Instance_17"
simulo:id="A5"
simulo:name="Activity 5"
rdfs:label="Activity 5"/>
<simulo:Dimension rdf:about="&simulo;anomalias_Instance_18"
simulo:id="Dim1"
simulo:name="Sequential/Global"
rdfs:label="Sequential/Global"/>
<simulo:Dimension rdf:about="&simulo;anomalias_Instance_19"
simulo:id="Dim2"
simulo:name="Inductive/Deductive"
rdfs:label="Inductive/Deductive"/>
<simulo:Time_Criterion rdf:about="&simulo;anomalias_Instance_2"
simulo:id="C303"
simulo:name="Time spent to consult the index"
rdfs:label="Time spent to consult the index"/>
<simulo:Dimension rdf:about="&simulo;anomalias_Instance_20"
simulo:id="Dim3"
simulo:name="Intuitive/Sensing"
rdfs:label="Intuitive/Sensing"/>
<simulo:Dimension rdf:about="&simulo;anomalias_Instance_21"
simulo:id="Dim4"
simulo:name="Visual/Verbal"
rdfs:label="Visual/Verbal"/>
<simulo:Dimension rdf:about="&simulo;anomalias_Instance_22"
simulo:id="Dim5"
simulo:name="Active/Reflective"
rdfs:label="Active/Reflective"/>
<simulo:Activity_Failures rdf:about="&simulo;anomalias_Instance_28"
simulo:id="A10101"
simulo:value="50.0"
rdfs:label=" All have Failures in Activity 1 greater than 50.0">
<simulo:subject_anomaly
rdf:resource="&simulo;anomalias_Instance_10012"/>
<simulo:property rdf:resource="&simulo;anomalias_Instance_33"/>
<simulo:criterion rdf:resource="&simulo;anomalias_Instance_37"/>
</simulo:Activity_Failures>
<simulo:Inequality rdf:about="&simulo;anomalias_Instance_32"
simulo:id="Pr201"
simulo:name="less than"
Javier Bravo Agapito
70
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
rdfs:label="less than"/>
<simulo:Inequality rdf:about="&simulo;anomalias_Instance_33"
simulo:id="Pr202"
simulo:name="greater than"
rdfs:label="greater than"/>
<simulo:Equality rdf:about="&simulo;anomalias_Instance_34"
simulo:id="Pr101"
simulo:name="Equal"
rdfs:label="Equal"/>
<simulo:Failure_Criterion rdf:about="&simulo;anomalias_Instance_37"
simulo:id="C401"
rdfs:label="Failures in Activity 1">
<simulo:concept rdf:resource="&simulo;anomalias_Instance_13"/>
</simulo:Failure_Criterion>
<simulo:Failure_Criterion rdf:about="&simulo;anomalias_Instance_38"
simulo:id="C405"
rdfs:label="Failures in Activity 5">
<simulo:concept rdf:resource="&simulo;anomalias_Instance_17"/>
</simulo:Failure_Criterion>
<simulo:Failure_Criterion rdf:about="&simulo;anomalias_Instance_39"
simulo:id="C404"
rdfs:label="Failures in Activity 4">
<simulo:concept rdf:resource="&simulo;anomalias_Instance_16"/>
</simulo:Failure_Criterion>
<simulo:Percentage_Criterion rdf:about="&simulo;anomalias_Instance_4"
simulo:id="C201"
simulo:name="Percentage of activity completed"
rdfs:label="Percentage of activity completed"/>
<simulo:Failure_Criterion rdf:about="&simulo;anomalias_Instance_40"
simulo:id="C403"
rdfs:label="Failures in Activity 3">
<simulo:concept rdf:resource="&simulo;anomalias_Instance_15"/>
</simulo:Failure_Criterion>
<simulo:Failure_Criterion rdf:about="&simulo;anomalias_Instance_41"
simulo:id="C402"
rdfs:label="Failures in Activity 2">
<simulo:concept rdf:resource="&simulo;anomalias_Instance_14"/>
</simulo:Failure_Criterion>
<simulo:Activity_Failures rdf:about="&simulo;anomalias_Instance_42"
simulo:id="A10102"
simulo:value="20.0"
rdfs:label=" All have Failures in Activity 2 less than 20.0">
<simulo:subject_anomaly
rdf:resource="&simulo;anomalias_Instance_10012"/>
<simulo:property rdf:resource="&simulo;anomalias_Instance_32"/>
<simulo:criterion rdf:resource="&simulo;anomalias_Instance_41"/>
</simulo:Activity_Failures>
<simulo:Frequency_of_Errors rdf:about="&simulo;anomalias_Instance_44"
simulo:id="A2010101"
simulo:value="25.0"
Javier Bravo Agapito
71
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
rdfs:label=" have Frequency between errors Equal 25.0 in ">
<simulo:criterion rdf:resource="&simulo;anomalias_Instance_12"/>
<simulo:property rdf:resource="&simulo;anomalias_Instance_34"/>
</simulo:Frequency_of_Errors>
<simulo:Frequency_of_Errors rdf:about="&simulo;anomalias_Instance_45"
simulo:id="A2010102"
simulo:value="10.0"
rdfs:label=" have Frequency between errors greater than 10.0 in ">
<simulo:criterion rdf:resource="&simulo;anomalias_Instance_12"/>
<simulo:property rdf:resource="&simulo;anomalias_Instance_33"/>
</simulo:Frequency_of_Errors>
<simulo:Frequency_of_Queries rdf:about="&simulo;anomalias_Instance_46"
simulo:id="A2010201"
simulo:value="80.0"
rdfs:label=" All have Frequency of index use Equal 80.0 in ">
<simulo:subject_anomaly
rdf:resource="&simulo;anomalias_Instance_10012"/>
<simulo:property rdf:resource="&simulo;anomalias_Instance_34"/>
<simulo:criterion rdf:resource="&simulo;anomalias_Instance_9"/>
</simulo:Frequency_of_Queries>
<simulo:Percentage_of_Comments rdf:about="&simulo;anomalias_Instance_48"
simulo:id="A2020201"
simulo:value="20.0"
rdfs:label=" have Percentage of comments greater than 20.0 in ">
<simulo:property rdf:resource="&simulo;anomalias_Instance_33"/>
<simulo:criterion rdf:resource="&simulo;anomalias_Instance_49"/>
</simulo:Percentage_of_Comments>
<simulo:Percentage_Criterion rdf:about="&simulo;anomalias_Instance_49"
simulo:id="C207"
simulo:name="Percentage of comments"
rdfs:label="Percentage of comments"/>
<simulo:Percentage_Criterion rdf:about="&simulo;anomalias_Instance_5"
simulo:id="C202"
simulo:name="Percentage of activity completed per unit time"
rdfs:label="Percentage of activity completed per unit time"/>
<simulo:Percentage_of_Errors rdf:about="&simulo;anomalias_Instance_50"
simulo:id="A2020301"
simulo:value="75.0"
rdfs:label=" have Percentage of errors Equal 75.0 in ">
<simulo:property rdf:resource="&simulo;anomalias_Instance_34"/>
<simulo:criterion rdf:resource="&simulo;anomalias_Instance_6"/>
</simulo:Percentage_of_Errors>
<simulo:Time_in_Errors rdf:about="&simulo;anomalias_Instance_51"
simulo:id="A2030201"
simulo:value="20.0"
rdfs:label=" have Time spent in errors greater than 20.0 in ">
<simulo:criterion rdf:resource="&simulo;anomalias_Instance_1"/>
<simulo:property rdf:resource="&simulo;anomalias_Instance_33"/>
</simulo:Time_in_Errors>
<simulo:Time_in_Activities rdf:about="&simulo;anomalias_Instance_52"
Javier Bravo Agapito
72
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
simulo:id="A2030101"
simulo:value="50.0"
rdfs:label=" have Time to complete a activity less than 50.0 in ">
<simulo:criterion rdf:resource="&simulo;anomalias_Instance_0"/>
<simulo:property rdf:resource="&simulo;anomalias_Instance_32"/>
</simulo:Time_in_Activities>
<simulo:Time_in_Queries rdf:about="&simulo;anomalias_Instance_53"
simulo:id="A2030301"
simulo:value="40.0"
rdfs:label=" have Time spent to consult the index greater than 40.0
in ">
<simulo:criterion rdf:resource="&simulo;anomalias_Instance_2"/>
<simulo:property rdf:resource="&simulo;anomalias_Instance_33"/>
</simulo:Time_in_Queries>
<simulo:Percentage_in_Activities rdf:about="&simulo;anomalias_Instance_55"
simulo:id="A2010101"
simulo:value="80.0"
rdfs:label=" have Percentage of activity completed less than 80.0
in ">
<simulo:property rdf:resource="&simulo;anomalias_Instance_32"/>
<simulo:criterion rdf:resource="&simulo;anomalias_Instance_4"/>
</simulo:Percentage_in_Activities>
<simulo:Percentage_Criterion rdf:about="&simulo;anomalias_Instance_6"
simulo:id="C203"
simulo:name="Percentage of errors"
rdfs:label="Percentage of errors"/>
<simulo:Percentage_Criterion rdf:about="&simulo;anomalias_Instance_7"
simulo:id="C204"
simulo:name="Percentage of competitors better than"
rdfs:label="Percentage of competitors better than"/>
<simulo:Percentage_Criterion rdf:about="&simulo;anomalias_Instance_8"
simulo:id="C205"
simulo:name="Percentage of favorable/unfavorable user comments"
rdfs:label="Percentage of favorable/unfavorable user comments"/>
<simulo:Frequency_Criterion rdf:about="&simulo;anomalias_Instance_9"
simulo:id="C101"
simulo:name="Frequency of index use"
rdfs:label="Frequency of index use"/>
<simulo:Concept rdf:about="&simulo;ontanomalies_Instance_2"
simulo:id="Cp0"
rdfs:label=" All ">
<simulo:property rdf:resource="&simulo;anomalias_Instance_10011"/>
</simulo:Concept>
<simulo:Concept rdf:about="&simulo;ontanomalies_Instance_3"
simulo:id="Cp1"
simulo:value="2.0"
rdfs:label="Dimension 1 greater than 2.0">
<simulo:subject rdf:resource="&simulo;anomalias_Instance_10004"/>
<simulo:property rdf:resource="&simulo;anomalias_Instance_33"/>
</simulo:Concept>
Javier Bravo Agapito
73
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
<simulo:Concept rdf:about="&simulo;ontanomalies_Instance_4"
simulo:id="Cp2"
simulo:value="-5.0"
rdfs:label="Dimension 2 less than -5.0">
<simulo:subject rdf:resource="&simulo;anomalias_Instance_10005"/>
<simulo:property rdf:resource="&simulo;anomalias_Instance_32"/>
</simulo:Concept>
<simulo:Concept rdf:about="&simulo;ontanomalies_Instance_5"
simulo:id="Cp3"
simulo:value="2.0"
rdfs:label="Dimension 3 less than 2.0">
<simulo:subject rdf:resource="&simulo;anomalias_Instance_10006"/>
<simulo:property rdf:resource="&simulo;anomalias_Instance_32"/>
</simulo:Concept>
</rdf:RDF>
Javier Bravo Agapito
74
Mecanismos de Integración y Prueba de Herramientas Automáticas de Evaluación
IV - Tabla de la distribución Normal(0,1)
Javier Bravo Agapito
75