UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
La Universidad Católica de Loja
MODALIDAD PRESENCIAL
ESCUELA DE CIENCIAS DE LA COMPUTACIÓN
SISTEMAS ADAPTATIVOS EN MOODLE:
INTERFAZ DE ADMINISTRACIÓN DE
RECOMENDACIONES ESTÁTICAS
Trabajo de fin de carrera previo a la obtención del título
de Ingeniero en Sistemas Informáticos y Computación
AUTOR:
Angamarca Guadalima Juan Pablo
DIRECTOR:
Ing. Alberca Prieto Greyson Paúl
CODIRECTOR:
Ing. López Vargas, Jorge Afranio
LOJA
–
ECUADOR
CERTIFICACIÓN
Ing. Greyson Alberca DIRECTOR DE TESIS
CERTIFICA:
Haber dirigido y supervisado el desarrollo del presente proyecto de tesis previo a la obtención del título de INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN, y una vez que este cumple con todas las exigencias y los requisitos legales establecidos por la Universidad Técnica Particular de Loja, autoriza su presentación para los fines legales pertinentes.
Loja, 25 de octubre de 2010
_____________________
AUTORÍA Y CESIÓN DE DERECHOS
YO, JUAN PABLO ANGAMARCA GUADALIMA. DECLARO SER EL AUTOR DEL PRESENTE TRABAJO, Y EXIMO EXPRESAMENTE A LA UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA Y A SUS REPRESENTANTES
LEGALES DE POSIBLES RECLAMOS O ACCIONES LEGALES.
ADICIONALMENTE DECLARO CONOCER Y ACEPTAR LA DISPOSICIÓN DEL ART. 67 DEL ESTATUTO ORGÁNICO DE LA UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA QUE EN SU PARTE PERTINENTE TEXTUALMENTE
DICE: “FORMAN PARTE DEL PATRIMONIO DE LA UNIVERSIDAD LA
PROPIEDAD INTELECTUAL DE INVESTIGACIONES, TRABAJOS CIENTÍFICOS O TÉCNICOS Y TESIS DE GRADO QUE SE REALICEN A TRAVÉS, O CON EL APOYO FINANCIERO, ACADÉMICO O INSTITUCIONAL (OPERATIVO) DE LA
UNIVERSIDAD”.
DEDICATORIA
A mis padres, que siempre han sido el apoyo necesario para salir adelante, ante todo y en todo momento.
A mis hermanos: compañeros de sangre en el pasado, presente y futuro del trajinar de la vida.
A mis abuelos: patriarcas y matriarcas de la familia que amo.
ÍNDICE DE CONTENIDOS
CERTIFICACIÓN ... ii
AUTORÍA Y CESIÓN DE DERECHOS ... iii
DEDICATORIA ... iv
ÍNDICE DE CONTENIDOS ... v
ÍNDICE DE ILUSTRACIONES ... viii
RESUMEN ... ix
INTRODUCCIÓN ... x
1. ESTADO DEL ARTE DE SISTEMAS DE ADMINISTRACIÓN DE RECOMENDACIONES ... 1
1.1 SISTEMAS RECOMENDADORES ... 1
1.2 TÉCNICAS DE LOS SISTEMAS RECOMENDADORES ... 2
1.2.1 Técnicas automáticas ... 2
1.2.2 Matching Conditions ... 4
1.3 SISTEMAS DE GESTIÓN DE APRENDIZAJE ... 5
1.3.1 Moodle ... 5
1.4 SISTEMAS RECOMENDADORES EN SISTEMAS DE GESTIÓN DEL APRENDIZAJE ... 6
1.4.1 Recomendaciones dentro de un sistema LMS ... 6
1.4.2 Elementos del modelo de recomendaciones ... 8
1.4.3 Estándares de usabilidad dentro de un sistema de recomendaciones ... 10
1.5 TRABAJOS RELACIONADOS ... 11
2. DEFINICIÓN DEL PROBLEMA ... 13
2.1 PLANTEAMIENTO DEL PROBLEMA ... 13
2.2 ESTADO ACTUAL ... 14
2.3 OBJETIVOS ... 15
2.4 JUSTIFICACIÓN ... 15
2.5 ESQUEMA DE LA SOLUCIÓN ... 15
2.5.1 Módulo de datos del sistema recomendador ... 16
2.5.2 Módulo de usuario ... 16
2.6 METODOLOGÍA ... 17
2.6.1 Desarrollo del modelo de datos ... 17
2.6.2 Metodología de programación extrema (XP) ... 17
2.6.3 Descripción del contexto de la solución ... 21
2.7 PLANTEAMIENTO DEL DISEÑO... 22
2.8 RESULTADOS ESPERADOS ... 23
3. ANÁLISIS Y DEFINICIÓN DE LA SOLUCIÓN... 24
3.1 REQUERIMIENTOS... 24
3.1.1 Requerimientos de la aplicación ... 24
3.1.2 Requerimientos no funcionales ... 25
3.2 COMPONENTES RELACIONADOS ... 26
3.2.1 Módulo de tutor ... 26
3.2.2 Modelado de usuario ... 26
3.3 ESCENARIOS ... 27
3.3.2 Escenario de interacción ... 27
4. DESARROLLO DE LA SOLUCIÓN ... 28
4.1 DESARROLLO DEL MODELO DE DATOS ... 28
4.1.1 Explicación de las tablas creadas en el modelo y la forma en que satisfacen los requerimientos propuestos para su desarrollo ... 28
4.1.2 Modelo obtenido ... 35
4.2 VISIÓN GENERAL DEL SISTEMA ... 36
4.2.1 Consideraciones de diseño ... 37
4.3 DESARROLLO DE MECANISMO DE AUTENTICACIÓN ... 39
4.4 DESARROLLO DEL SERVICIO WEB ... 40
4.4.1 Operaciones del servicio Web ... 40
4.5 DESARROLLO DE LAS INTERFACES ... 42
4.5.1 Menú lateral de funcionalidades ... 43
4.5.2 Listado de tipos de recomendación ... 43
4.5.3 Creación/Edición de tipos de recomendación ... 44
4.5.4 Listado de categorías de recomendación ... 46
4.5.5 Creación/Edición de tipos de categorías ... 46
4.5.6 Borrado de datos ... 47
4.6 INTEGRACIÓN CON MOODLE ... 47
4.7 CONSIDERACIONES DE LA PROGRAMACIÓN DE LA APLICACIÓN ... 48
4.7.1 Diseño visual ... 48
4.7.2 Prácticas de programación ... 49
4.8 PRUEBAS DE LA APLICACIÓN ... 49
5. DISCUSIÓN DE RESULTADOS ... 50
5.1 MODELO DE DATOS ... 50
5.2 SERVICIO WEB ... 50
5.3 INTERFAZ DE ADMINISTRACIÓN ... 50
5.4 INTEGRACIÓN CON MOODLE ... 51
5.5 PRUEBAS ... 51
5.6 TRABAJOS FUTUROS ... 52
6. CONCLUSIONES Y RECOMENDACIONES ... 53
6.1 CONCLUSIONES ... 53
6.2 RECOMENDACIONES ... 55
7. ANEXOS... 56
7.1 HISTORIAS DE USUARIO ... 56
7.2 DESARROLLO DE LA PLANEACIÓN DE LA ENTREGA. ... 60
7.3 PLANEACIÓN DE ITERACIONES ... 61
7.4 TARJETAS CRC ... 66
7.4.1 Clases que representan entidades dentro del contexto del negocio. ... 66
7.4.2 Clases utilitarias ... 68
7.5 CASOS DE PRUEBA ... 71
7.6 RESULTADO DE LAS PRUEBAS ... 77
7.6.1 Pruebas para caso de prueba CSPRB-001 ... 77
7.6.2 Pruebas para caso de prueba CSPRB-002 ... 77
7.6.3 Pruebas para caso de prueba CSPRB-003 ... 78
7.6.4 Pruebas para caso de prueba CSPRB-004 ... 78
7.6.5 Pruebas para caso de prueba CSPRB-005 ... 78
7.7 MANUAL DE USUARIO ... 80
7.7.1 Ingreso al sistema ... 80
7.7.2 Menú lateral ... 81
7.7.3 Revisar listado de tipos de recomendaciones ... 82
7.7.4 Crear un tipo de recomendación ... 83
7.7.5 Editar tipo de recomendación ... 88
7.7.6 Listado de categorías ... 88
7.7.7 Crear categoría ... 89
7.7.8 Edición de una categoría ... 90
7.7.9 Borrado de datos ... 90
7.7.10 Uso de ayuda ... 91
7.8 MANUAL DEL PROGRAMADOR ... 93
7.9 DEFINICIÓN WSDL DEL SERVICIO WEB IMPLEMENTADO ...104
7.10 IMPLEMENTACIÓN DEL SERVICIO WEB ...110
7.11 BLOQUE MOODLE ...114
7.12 CÓDIGO FUENTE (VISTAS PRINCIPALES) ...115
7.12.1 edit-type-rec.php ...115
7.12.2 edit-category.php ...135
7.12.3 require-login.php...138
7.12.4 confirm-delete.php ...139
ÍNDICE DE ILUSTRACIONES
Figura 1.1. Recomendaciones ofrecidas en el sitio web YouTube. ... 1
Figura 1.2. Proceso de las recomendacione. ... 7
Figura 2.1 Esquema de módulos del sistema recomendador... 13
Figura 2.2. Esquema del planteamiento del diseño de la aplicación. ... 23
Figura 4.1. Modelo para recomendaciones en escenarios de aprendizaje ... 28
Figura 4.2. Gráfica del modelo de datos diseñado para la solución, obtenido conjuntamente con los autores de los módulos de seguimiento de usuarios, módulo tutor y modelado de usuario. ... 36
Figura 4.3: Esquema del consumo del servicio Web implementado para la interfaz de administración de recomendaciones ... 42
Figura 4.4. Menú lateral de la aplicación. ... 43
Figura 4.5. Listado de tipos de recomendación. ... 44
Figura 4.6. Interfaz de creación/edición de recomendaciones. ... 45
Figura 4.7. Interfaz de listado de categorías. ... 46
Figura 4.8. Interfaz de creación/edición de categorías. ... 47
Figura 4.9. Diálogo de confirmación de eliminación de datos. ... 47
Figura 4.10. Bloque Moodle desarrollado ... 48
Figura 7.1. Autentificación solicitada al ingresar a cualquier página de la interfaz. ... 80
Figura 7.2. Bloque Moodle desde el que se puede ingresar a la interfaz de administración de recomendaciones. ... 81
Figura 7.3. Menú lateral de la aplicación. ... 82
Figura 7.4. Listado de tipos de recomendaciones existentes. ... 83
Figura 7.5. Interfaz de creación de tipos de recomendaciones (I) ... 84
Figura 7.6. Interfaz de creación de tipos de recomendaciones (II) ... 85
Figura 7.7. Interfaz de creación de tipos de recomendaciones (III) ... 86
Figura 7.8. Notificación de campos obligatorios no completados. ... 87
Figura 7.9. Visualización de un tipo de recomendación al ser creado. ... 87
Figura 7.10. Visualización de un tipo de recomendación al ser editado. ... 88
Figura 7.11. Listado de categorías. ... 89
Figura 7.12. Interfaz de creación de categorías ... 89
Figura 7.13. Visualización de una categoría luego de ser creada. ... 90
Figura 7.14. Acceso a la funcionalidad de borrado desde una página de listado. ... 91
Figura 7.15. Diálogo de confirmación de borrado de datos. ... 91
Figura 7.16. Notificación de borrado exitoso de datos. ... 91
RESUMEN
La Universidad Técnica Particular de Loja cuenta con un Entorno Virtual de Aprendizaje, basado en un sistema de gestión de aprendizaje (LMS, Learning Management System) denominado Moodle. En este Entorno, se encuentran registrados los cursos y sus estudiantes, y es un medio de interacción y contacto. El número de usuarios del Entorno Virtual es elevado en la actualidad, al igual que la cantidad de recursos que se ofrecen dentro de él. Para evitar un problema de sobrecarga de información, se puede implementar un sistema de recomendaciones que permita a los docentes ofrecer recursos relevantes a sus estudiantes. De acuerdo a los estereotipos de los valores de atributos de modelado de usuario, se pueden crear tipos de recomendaciones genéricos, a partir de los cuales un tutor o agente recomendador puede elaborar recomendaciones concretas para que sean ofrecidas a los estudiantes.
INTRODUCCIÓN
Los sistemas recomendadores se crearon con el fin de combatir el problema de sobrecarga de información al que se veían expuestos los usuarios de sistemas quienes tenían una gran cantidad de información a su disponibilidad. Estos sistemas se han utilizado en forma masiva en campos como el comercio electrónico y el entretenimiento en línea. Con la aparición de entornos virtuales de aprendizaje, se notó que en dichos sistemas también existía el problema de sobrecarga, al haber numerosos cursos, con muchos estudiantes participantes y recursos disponibles a ellos. Para ello, un sistema de recomendaciones aplicado a un entorno educativo virtual debe ofrecer recursos a los estudiantes de acuerdo a sus características particulares como niveles de conocimiento e interacción.
Esta tesis presenta el desarrollo de una interfaz de administración de recomendaciones, la cual forma parte de un sistema de recomendaciones completo que se integrará a Moodle. El proceso de desarrollo incluye:
El análisis correspondiente para la obtención de un modelo de recomendaciones. Este modelo debe dar cabida al almacenamiento de recomendaciones, tipos de recomendaciones, categorías de recomendaciones, técnicas de obtención y condiciones de aplicabilidad. Dicho modelo también contiene el modelado de usuario, del cual, la interfaz de administración de recomendaciones utiliza la información concerniente a los atributos del modelo de usuario. Este modelo se obtuvo en conjunto con los autores de los proyectos relacionados de: seguimiento de usuarios, módulo tutor y agente de modelado de usuarios.
Realización de actividades de programación acordes a una metodología de desarrollo, la cual en este caso es la metodología Extreme Programming (XP), que permite desarrollar software en iteraciones cortas y sin exceso de documentación.
Integración de la interfaz de administración con Moodle, usando sus mecanismos de autenticación, y un bloque que permita acceder a la interfaz.
Pruebas de aplicación con docentes para verificar su correcto funcionamiento.
1.
Estado del arte de sistemas de administración de recomendaciones
1.1 Sistemas recomendadores
Un sistema recomendador (SR) es un sistema cuyo propósito es ayudar a los usuarios a enfrentarse al problema de la sobrecarga de información, ofreciendo recomendaciones sobre objetos disponibles a ellos dentro del sistema, los cuales que resulten útiles y relevantes a dichos usuarios. Uno de los primeros sistemas recomendadores es el sistema TAPESTRY, desarrollado en Xerox PARC, en 1992 (Itmazi, 2005). Su propósito era ofrecer recomendaciones sobre e-mail y grupos de noticias de Internet, y soportaba dos técnicas de recomendación: filtrado colaborativo y filtrado basado en contenidos (Itmazi, 2005).
En las dos últimas décadas, se ha intensificado la investigación sobre sistemas recomendadores, y se han diversificado los campos en los que se utilizan. Actualmente, las principales aplicaciones de los SR son el comercio electrónico, entretenimiento en línea, redes sociales, videotecas y bibliotecas virtuales.
[image:12.612.138.472.535.673.2]Uno de los ejemplos de uso moderno de sistemas recomendadores es YouTube, sitio de video en línea. Desde el año 2009, se incorporó un sistema de recomendaciones, el cual recoge información sobre el comportamiento de los usuarios dentro del sitio, el tipo de contenido que los usuarios observan, y el contenido que han visto en el pasado, para ofrecer videos a los usuarios basándose en esos datos (Tartakoff, 2009).
1.2 Técnicas de los sistemas recomendadores
Los sistemas recomendadores realizan su trabajo de acuerdo a varias técnicas. Existen técnicas apoyadas por algoritmos automatizados, así como técnicas en las que un experto humano crea recomendaciones.
1.2.1 Técnicas automáticas
En cuanto a las técnicas automáticas, su forma de operación se clasifica en tres grupos (Candillier, Jack, & Fessant, 2009):
1.2.1.1 Filtrado colaborativo
En un proceso de filtrado colaborativo, el objetivo es predecir la clasificación que un usuario determinado va a dar a un cierto objeto disponible en el sistema. Se clasifica a los usuarios del sistema en grupos denominados vecindades o grupos de vecinos cercanos (Krishnakumar, 2007), y las recomendaciones se hacen tomando en cuenta las preferencias de usuarios similares dentro del sistema, lo cual los convierte en usuarios semejantes. Si un usuario está dentro de un grupo, a él o ella se le recomendará objetos similares a los que prefirieron sus vecinos cercanos. El usuario, para poder ser clasificado en un grupo de semejantes y para que pueda predecirse sus calificaciones sobre nuevos objetos (los cuales no conoce aún), debe estar activo en el sistema, lo cual significa que ya debe haber calificado objetos en el sistema. De la misma forma, para poder recomendar objetos, estos deben haber sido calificados previamente.
Enfoques del filtrado colaborativo. El filtrado colaborativo tiene tres enfoques: el filtrado basado en usuarios, en objetos y en un modelo.
El enfoque basado en usuarios realiza las predicciones en base a las calificaciones que han dado a los objetos sus vecinos cercanos, para lo cual se necesita una medida de semejanza entre ellos previamente definida, así como un método para combinar las calificaciones sobre el objeto de todos los vecinos del grupo.
calificaciones que ha dado el usuario a los objetos que están en la vecindad del objeto que se va a recomendar.
Cuando la base de usuarios y de objetos disponibles a ellos crece hasta llegar a tener grandes proporciones, la complejidad de los algoritmos presenta un serio problema al el rendimiento del sistema. El enfoque basado en modelos trata con este problema, al generar modelos de datos off-line para que las predicciones on-line se hagan de la forma más rápida posible. Existen varios tipos de modelos utilizados en este enfoque, por ejemplo, la agrupación de usuarios para predecir las calificaciones en base a las calificaciones de los miembros del grupo; modelos bayesianos y modelos basados en reglas de asociación. Cabe destacar que en modelos de agrupación probabilísticos un usuario puede pertenecer a varios grupos, en estos casos se aplican jerarquías de grupos para definir los resultados. Las agrupaciones pueden ser tanto de objetos como de usuarios, si se utilizan ambos tipos de agrupaciones, la calificación que se predice resulta ser la media de los miembros del grupo de objetos, entre los miembros del grupo de usuarios.
El concepto de similitud o semejanza es importante dentro del filtrado colaborativo. Para calcular la similitud, se utilizan varias medidas, como la correlación de Pearson, similitud Jaccard, similitud Manhattan, y coseno simple. Una explicación detallada de estos tipos de cálculo de similitud va más allá del alcance de la presente tesis, y puede ser revisada en (Candillier, Jack, & Fessant, 2009)
1.2.1.2 Filtrado basado en contenidos
videos asociados a contenido que se ha visto con anterioridad.
Bajo este enfoque se crea un modelo de usuario, el cual es aprendido automáticamente por un método de aprendizaje automático (algoritmo supervisado de aprendizaje) que lee las descripciones de los objetos y produce como salida opiniones de usuario sobre los objetos. Las preferencias son relaciones entre los usuarios y los objetos, y deben ser codificables para que se puedan procesar. Para aumentar las posibilidades de hacer buenas recomendaciones, se debe contar con descripciones bastante detalladas sobre los objetos, perfiles de usuario bien construidos, y métricas de semejanza entre preferencias. Debido al procesamiento que hace un filtrado basado en contenidos, se pueden dar recomendaciones sobre objetos que aún no han sido calificados dentro del sistema, a diferencia del filtrado colaborativo.
1.2.1.3 Filtrado híbrido
Se realiza aprovechando las características de ambos sistemas anteriores, realizando un filtrado colaborativo y luego uno basado en contenidos, y luego definiendo las recomendaciones mediante un esquema de votación (Candillier, Jack, & Fessant, 2009).
1.2.2 Matching Conditions
1.3 Sistemas de gestión de aprendizaje
Un sistema de gestión de aprendizaje, conocido también como LMS (siglas en inglés de
Learning Management System), es un sistema comúnmente basado en Web, cuya función es
entregar y administrar contenidos de apoyo al proceso de aprendizaje. El inicio de su uso se remonta a la década entre 1990 y 2000. Un LMS incluye un conjunto de funcionalidades, típicamente catálogos de cursos, listas de estudiantes, toma de evaluaciones, publicaciones de tareas, tareas, foros, y registro de actividades dentro del sistema. Los LMS poseen también interfaces para la administración del sitio, y administración de los cursos por parte de los profesores. Su diseño tiene como objetivo guiar a los estudiantes a través de un proceso simple para lograr los objetivos de evaluar y mantener competencias, participar en cursos, y desarrollar las actividades de aprendizaje que se definan en cada curso (Public Health Learning, 2009). Estos sistemas están disponibles tanto en versiones comerciales y versiones libres y de código abierto. Las características de los sistemas LMS modernos se han adaptado a las posibilidades que abre Internet y permiten inclusive crear grandes comunidades colaborativas en las que participan millares de personas (Mallon, Bersin, Howard, & O’Leonard, 2009).
1.3.1 Moodle
Moodle es un sistema LMS de software libre y código abierto. Este sistema puede ser desplegado sobre las principales plataformas de sistemas operativos existentes en la actualidad, y su uso es bastante extendido: hacia octubre del año 2009, es el sistema LMS de mayor penetración en el mercado de sistemas de gestión de aprendizaje (Davis, Carmean, & Wagner, 2009), sobre otros sistemas como Blackboard Course Management o TotalLMS, con un porcentaje de 20% de mercado frente a las demás alternativas juntas. Moodle posee varias funcionalidades concernientes a la administración de cursos (Moodle.org, 2010), las cuales se exponen a continuación:
Chats: Permite la comunicación en tiempo real mediante mensajes instantáneos entre usuarios conectados al sistema.
Encuestas: Encuestas que los usuarios del sistema pueden completar. El módulo de encuestas permite obtener reportes para los administradores y profesores, y retroalimentación por parte de los estudiantes de los cursos.
Foros: Los foros permiten la discusión de temas mediante el posteo de mensajes en la página del foro. Los foros en Moodle permiten determinar restricciones de acceso sobre quiénes ingresan y postean en ellos, así como moderar las respuestas y las publicaciones.
Glosarios: Consisten en listas de definiciones sobre los tópicos del curso, editadas por todos los participantes.
Cuestionarios: Permiten colocar cuestionarios con varios tipos de preguntas (selección múltiple, ensayo, verdadero/falso, emparejamiento, y otros).
Recursos: Permiten gestionar, almacenar y mostrar diferentes tipos de documentos electrónicos asociados al curso.
Moodle es el sistema de gestión de aprendizaje utilizado en la Universidad Técnica Particular de Loja, a partir del año 2006, conocido como Entorno Virtual de Aprendizaje, o EVA.
1.4 Sistemas recomendadores en sistemas de gestión del aprendizaje
1.4.1 Recomendaciones dentro de un sistema LMS
Una recomendación es una sugerencia que se ofrece a un estudiante con el fin de realizar una actividad que resulte útil y de apoyo a su proceso de aprendizaje, actividades que dentro de un LMS, pueden ser la participación en foros, obtención de recursos, realización de tareas, chats, revisión y participación en glosarios, y otras. El presente trabajo se enmarca en la recomendación de estos objetos de aprendizaje.
[image:18.612.111.504.425.657.2]El sistema administrador no pretende sustituir a los algoritmos que generan recomendaciones por el conocimiento de los profesores, más bien, trata de mejorar su interacción dentro del proceso. El objetivo de un sistema de gestión de recomendaciones es ofrecer al profesor herramientas para poder crear, diseñar, modificar, experimentar con las recomendaciones (Santos, Martín, Mazzone, & Boticario, 2009). La generación de recomendaciones mediante algoritmos de inteligencia artificial libera a los profesores de la carga que significaría el tener que crear las recomendaciones; sin embargo, pueden existir necesidades psicológico-educacionales que podrían no estar cubiertos por los algoritmos, cuya introducción se haga necesaria. Si los profesores disponen de una herramienta de administración para crear recomendaciones en forma personalizada desde cero, este problema puede resolverse de manera sencilla.
Figura 1.2.Proceso de las recomendaciones (Santos O. , Ampliando el apoyo ofrecido por las
Un sistema de administración de recomendaciones apoya al profesor para reconocer diferentes situaciones en el eLearning, y determinar las recomendaciones que se pueden dar en dichos casos (Santos). Debe proveer una interfaz funcional utilizando un modelo de recomendaciones y un modelo de usuario (modelo que contiene información sobre el estilo de aprendizaje y la interacción del usuario con el LMS). En la figura Figura 1.2, podemos ver un esquema sobre el proceso de las recomendaciones. La administración de recomendaciones estáticas corresponde a la sección del experto humano, la cual se contrasta contra la generación de recomendaciones por medio de algoritmos automáticos.
1.4.2 Elementos del modelo de recomendaciones
Un modelo para un sistema de recomendaciones debe contener la información necesaria, tal como preferencias, características de aprendizaje e historial de interacción de los usuarios, así como las similitudes entre usuarios y sus requerimientos de accesibilidad.
Santos y Boticario proponen un modelo basado en ciertos objetivos: el soporte a la creación de recomendaciones por parte del administrador del curso, información sobre las razones por las que se crea una recomendación, y retroalimentación por parte de los usuarios sobre el interés que generen en ellos las recomendaciones con el fin de mejorar el sistema.
Basándonos en el modelo propuesto por Santos y Boticario, los elementos del modelo consisten en categoría de la recomendación, técnica de obtención, origen de la recomendación, explicación de la oferta, restricciones temporales o de vencimiento, y las condiciones de
aplicabilidad. A continuación se explican dichos elementos.
Categoría: La categoría de una recomendación es el campo del proceso de aprendizaje al que se aplica la recomendación. Las recomendaciones enmarcadas en ciertas categorías pueden ser más útiles que las recomendaciones de otra categoría dependiendo de la situación actual del curso. Dentro de las categorías podemos citar:
Motivación: Mensaje que tiene como propósito motivar al estudiante frente a
demora en la realización de las tareas de clase.
Estilos de aprendizaje: Recomendaciones que se ofrecen para que el estudiante realice
actividades dentro del entorno, acordes a su estilo de aprendizaje particular, o bien para tomar un test de estilos de aprendizaje.
Conocimiento previo: Recomendaciones que se ofrecen tomando en cuenta los
aspectos del curso en los que el usuario tiene mayor dominio, para poner énfasis en las que no.
Colaboración: Recomendaciones orientadas a la interacción con los otros
participantes del curso.
Interés: Recomendaciones que permiten al usuario acceder a objetos de aprendizaje
referentes a los temas sobre los que más tiene interés dentro del curso.
Accesibilidad: Recomendaciones concernientes a la forma en el que usuario accede a
los contenidos dentro del entorno.
Técnica: Consiste en la técnica usada para crear la recomendación. Puede una de las técnicas expuestas anteriormente (filtrado colaborativo, basado en contenidos, mixto, matching conditions).
Origen: Determina si la recomendación fue generada por un algoritmo automatizado que ha determinado que las características del usuario son apropiadas para ofrecerle la recomendación, o por un tutor o administrador de recomendaciones.
Explicación: Ofrece información detallada en una forma comprensible por el estudiante del por qué se le ha ofrecido la recomendación.
Condiciones de aplicabilidad: Determinan cuándo una recomendación se debe o no
ofrecer a un estudiante de acuerdo a la evaluación de valores definidos. Dentro de este campo se encierran factores como el estilo de aprendizaje, el nivel de tecnología con la que el usuario es familiar, similitud entre estudiantes, rol dentro de la plataforma, nivel de colaboración, datos de interacción, nivel de conocimiento, datos de interacción, nivel de interés y recursos utilizados dentro del LMS.
hasta cuándo se ofrece una recomendación. Pueden estar dadas por fechas concretas, intervalos de tiempo o eventos.
1.4.3 Estándares de usabilidad dentro de un sistema de recomendaciones
En el trabajo “An Experimental Usability Test for different Destination Recommender
Systems”(Zins, Bauernfeind, Del Missierb, Venturinib, & Rumetshoferc, 2003), han llegado a la conclusión que dentro de un sistema recomendador existen tres factores para asegurar las satisfacción de los usuarios en el uso del sistema: estos tres factores consisten en facilidad de uso/aprendizaje, efectividad/obtención de resultados, y confiabilidad. Estos factores se han determinado mediante la evaluación de información objetiva (datos de interacción con el sistema como tiempo en realizar una tarea, número de veces que el usuario utiliza una funcionalidad, tasa de error) y subjetiva (retroalimentación mediante el uso de encuestas).
En lo concerniente al diseño, un sistema de recomendaciones debe poner énfasis en las siguientes áreas (Turnbull):
Proveer ayuda interactiva al usar, buscar, seleccionar y leer recomendaciones.
Hacer que la navegación en las recomendaciones sea natural, e impedir que el usuario se pierda o se abrume al utilizar el sistema.
Incluir notificaciones y recordatorios.
Diseñar un mecanismo de retroalimentación rápida si las recomendaciones se ofrecen en tiempo real.
Santos y Boticario añaden otros elementos a los ya explicados:
Escrutabilidad: El usuario debe poder indicar al sistema cuando una recomendación
ofrecida no le es de ayuda, ya sea porque no se ajusta al perfil del usuario o porque no se aplica a él.
Persuasividad: El sistema debe convencer a los usuarios para que lean las
ofertadas.
Satisfaccción: Hacer que el uso del sistema sea más sencillo con el tiempo y que las
recomendaciones se ofrezcan cuando son relevantes.
1.5 Trabajos relacionados
En el trabajo “Users’ experience with a recommender system in an open source standard-based learning management system” (Santos y Boticario, grupo de investigación aDeNu,
Departamento de Inteligencia Artificial de la escuela de Computación de la Universidad Nacional de Educación a Distancia, España), se explora la utilidad de los sistemas recomendadores dentro de los entornos educativos, así como su uso e integración con sistemas de gestión del aprendizaje (LMS). Santos y Boticario proponen un modelo de recomendaciones y la implementación de un sistema recomendador sobre la plataforma LMS dotLRN.
Montaner, López y Lluis de la Rosa, en Evaluation of Recommender System Through
Evaluated Users, presentan un trabajo concreto sobre simulación de usuarios para poder probar y
2.
Definición del problema
2.1 Planteamiento del problema
[image:24.612.119.525.315.545.2]Actualmente en la UTPL existe una gran demanda para las carreras que se ofrecen, por lo cual se ha dado un gran incremento en los estudiantes matriculados, debido a esto, a los tutores de cada curso les resulta difícil llevar una relación personalizada con cada estudiante, así mismo, dar aviso de las tareas propuestas y del material de apoyo compartido. Para mejorar dicha relación entre tutor-estudiante, se requiere integrar un sistema recomendador al entorno virtual Moodle.
Figura 2.1 Esquema de módulos del sistema recomendador.
En la figura Figura 2.1 Esquema de módulos del sistema recomendador.se puede observar los cinco módulos que conforman un sistema recomendador y cómo interactúan estos para poder llegar a la creación de una recomendación, la misma que es el elemento central que se muestra en la figura.
El módulo de Seguimiento de usuario brinda información estadística útil para la creación de modelos de usuario, esta información es utilizada por el Modelo de Usuario que contiene información de los usuarios como: datos personales, preferencias e intereses, y datos del entorno que sirven para definir las condiciones de aplicabilidad para el ingreso de recomendaciones. El módulo de Administración de recomendaciones se encarga de crear los diferentes tipos de recomendación que pueden existir, también de definir ciertas recomendaciones para lo cual necesita leer la información del modelo de usuario. El Módulo Tutor que es el que se encarga del ingreso de recomendaciones también leyendo la información guardada del modelo de usuario. Con las recomendaciones ingresadas, el Agente recomendador se encarga de ofertarlas a los estudiantes, la recomendación ofertada puede ser para: ciertas actividades que se tienen que cumplir, para mostrar tareas específicas a realizar, para indicar los sitios que tienen que visitar, para indicar los foros que tienen que responder o las lecturas que deben realizar, o para otras actividades más que se pueden realizar en el desarrollo del curso. La presente tesis trata sobre el desarrollo del módulo de administración de recomendaciones, cuyo desarrollo requiere el cumplimiento de ciertas actividades como la obtención de un modelo de recomendaciones y un modelo de usuario, así como la elaboración de una interfaz que permita crear tipos de recomendaciones para que sean usadas dentro del sistema.
2.2 Estado actual
2.3 Objetivos
Construir una interfaz de administración de recomendaciones estáticas que permita la creación, edición y eliminación de tipos de recomendaciones genéricos, con el fin de probar diferentes combinaciones de los factores que componen las recomendaciones, para que pueda ser usado dentro del Entorno Virtual de Aprendizaje de la UTPL.
Entender la estructura y funcionamiento de un sistema de recomendaciones.
Integrar la solución desarrollada a Moodle.
Desarrollar servicios Web que permitan recuperar datos del modelo de recomendaciones, con el fin de tener interoperabilidad con otros sistemas de información.
2.4 Justificación
Un sistema recomendador es apropiado para ser implementado dentro del LMS Moodle usado en la Universidad Técnica Particular de Loja como medio de apoyo al proceso de aprendizaje, ya que es factible la obtención de información necesaria para ello, tal como datos de interacción, seguimiento de usuarios, y estilos de aprendizaje, esto último gracias a la obtención de modelos de usuario. En un sistema de recomendaciones estáticas se debe contar con una interfaz de administración, en la que se creen tipos de recomendaciones por parte de un experto recomendador, para a partir de estos tipos crear recomendaciones específicas (de forma manual o mediante algoritmos), antes de ofrecerlas a los estudiantes; el trabajo expuesto en esta tesis tiene el fin de construir dicha interfaz.
2.5 Esquema de la solución
efecto.
La solución de interfaz de administración de recomendaciones estáticas está compuesta por los módulos que se describen a continuación.
2.5.1 Módulo de datos del sistema recomendador
Consiste en la base de datos contiene la información necesaria que va a ser utilizada por el sistema recomendador. Tiene dos componentes:
El modelo de recomendaciones, el cual contiene las recomendaciones y los tipos de
recomendaciones que se han creado dentro del sistema con todos los parámetros que los definen. Este modelo incluye también las categorías de recomendaciones, técnicas de obtención, restricciones de vencimiento y condiciones a las que se sujetan las recomendaciones.
El modelo de datos para la solución que se va a desarrollar se basa en el análisis que se ha realizado de los modelos propuestos por Santos y Boticario (1.4.2), unido a ello las necesidades particulares del entorno para el que se va a desarrollar la solución, es decir el entorno virtual de aprendizaje de la Universidad Técnica Particular de Loja.
El modelado de usuario, el cual consiste en información relacionada a las preferencias y
características particulares de los usuarios del LMS, tales como niveles de interacción, preferencias, entorno de usuario, y estilos de aprendizaje.
2.5.2 Módulo de usuario
Consiste en un conjunto de vistas que tienen las siguientes funciones:
Creación, edición y borrado de tipos de recomendaciones: Esta interfaz permite gestionar
Creación, edición y borrado de categorías de recomendaciones: Para crear categorías de recomendaciones a las que están asociados los tipos de recomendaciones.
2.6 Metodología
A continuación se describe la metodología utilizada en este trabajo para la obtención de la información y modelos que serán la base del desarrollo de la interfaz de administración de recomendaciones.
2.6.1 Desarrollo del modelo de datos
El modelo de datos se ha obtenido en reuniones con los desarrolladores de los proyectos relacionados (Módulo de Tutor, Seguimiento de usuario, Modelado de usuario). Se han identificado entidades y relaciones de acuerdo a los elementos de las recomendaciones (1.4.2), y se han traducido en un modelo de datos. Cabe destacar que para la interfaz de administración de recomendaciones se utilizan todos los datos del modelo de recomendaciones y una sección de los datos concernientes al modelado de usuario, concretamente los datos sobre modelos de usuarios, valores de atributos del modelo de usuario, estilos de aprendizaje y tipos de modelos. El proceso de desarrollo del modelo y la explicación de los elementos incluidos en él se presentan en la sección 4.1.
2.6.2 Metodología de programación extrema (XP)
Para desarrollar la solución, se usará la metodología de desarrollo de software Programación Extrema (XP Programming). Esta metodología consiste en un proceso de desarrollo ágil, basado en reglas simples. Sus fortalezas son el mejoramiento de la comunicación, simplicidad y retroalimentación. Permite que el software sea desarrollado de tal forma que las características se vayan implementando a medida que se necesitan, y los entregables se materialicen desde el primer día de desarrollo (Wells, 1999-2009).
2.6.2.1 Reglas de XP
La programación extrema se basa en un conjunto de reglas algo extenso, el cual puede consultarse en (Wells, 1999-2009). Para el desarrollo del presente proyecto de tesis se ha elegido un subconjunto de reglas que se ajustan al proceso de desarrollo que se va a realizar, y se expone a continuación:
Campo del proceso de desarrollo
Reglas
Planeación Obtención de historias de usuario
Planeación de entregas para tener un calendario de entrega.
Hacer entregas pequeñas y frecuentes.
Uso de iteraciones, que empiezan con una planeación de iteración.
Administración Medición de velocidad del proyecto.
Diseño Simplicidad
Uso de tarjetas CRC (Tarjetas Clase-Responsabilidad-Colaboración) (El desarrollo de las tarjetas CRC para esta tesis se encuentra en la sección 7.4)
Las funcionalidades no se añaden antes de tiempo.
Refactorización constante.
Codificación Disponibilidad constante del cliente
Codificación de acuerdo a estándares
Integración constante
2.6.2.2 Procesos de Extreme Programming
2.6.2.2.1 Historias de usuario
Las historias de usuario son descripciones cortas de las funcionalidades que el usuario describe que se necesitarán dentro el sistema. Estas historias deben ser claras, consistentes, cortas y sin términos técnicos; de la misma forma, no debe incluir absolutamente ninguna especificación de la forma de implementación, tal como algoritmos, lenguajes de programación, patrones de diseño, bases de datos y otros.
Las historias de usuario no deben ser demasiado generales o demasiado específicas, y se puede saber si su nivel de detalle es adecuado de acuerdo al tiempo que se estime su implementación: si se estima más de tres semanas, la historia abarca demasiada funcionalidad, y debe desglosarse. Si se estima una implementación de menos de una semana, la historia cubre un detalle muy pequeño, por lo que debe ser combinada con otras historias de usuario.
Las historias de usuario son la base para realizar las pruebas de aceptación en cada iteración. (Wells, 1999-2009)
Para el desarrollo del sistema de administración de recomendaciones se han diseñado un total de seis historias de usuario, cuyo planteamiento se encuentra detallado en la sección 7.1.
2.6.2.2.2 Planeación de la entrega
Se selecciona un conjunto de historias de usuario que permitan completar la iteración actual, y el tiempo ideal en el que se completará cada historia de usuario, con refactorización y pruebas incluidas. Las primeras historias de usuario en desarrollarse deben ser las más importantes para el proyecto. Este conjunto debe definir un sistema usable, susceptible a pruebas, y que tenga sentido en el contexto del negocio, de tal forma que pueda ser entregado y puesto a producción. La planeación se puede realizar por tiempo (cuántas historias de usuario se deben implementar hasta una fecha determinada) o por alcance (cuánto tiempo tarda implementar un conjunto de historias dado).
2.6.2.2.3 Planeación de la iteración
La planeación de la iteración marca el inicio de la iteración. Consiste en la asignación de tiempos y responsabilidades de las tareas de programación de la aplicación. Estas tareas se determinan a partir de las historias de usuario que el cliente eligió para la iteración actual. En esta planeación puede incluirse también las tareas de resolución de las pruebas de aceptación fallidas.
Una vez que se asignan las tareas, el responsable de cada tarea debe estimar el tiempo que tardará la implementación del problema asignado. Cada tarea de programación debe tener una duración de entre tres a un día. De estimarse un tiempo mayor, deben desglosarse; si se estima un tiempo menor, deben agruparse. Si se tiene demasiadas tareas para el tiempo total de la iteración, las tareas pueden ser postergadas. El equipo de desarrollo no debe empezar a preocuparse si empiezan a postergarse muchas tareas, si esos retrasos se provocan por el tiempo asignado a procesos adecuados de refactorización (depuración y optimización constante) y pruebas unitarias (pruebas que garantizan que el código construido funciona bien al ser llamado por otros módulos). Algo que de hecho puede causar retrasos es empezar a incluir tareas que no estaban planificadas dentro de la iteración, o tareas no incluidas en el tiempo de las tareas de programación. De la misma forma, no se deben cambiar las tareas y las estimaciones usando criterios optimistas, pues aquello puede causar problemas. (Wells, 1999-2009).
La planeación de iteraciones para el desarrollo de la interfaz de administración de recomendaciones se encuentra en la sección 7.3.
2.6.2.2.4 Pruebas de aceptación
Las pruebas de aceptación son pruebas con un enfoque de caja negra, es decir, representan un resultado esperado del sistema. Los clientes son los responsables de verificar la corrección y exactitud de las pruebas, y de establecer calificaciones para decidir cuáles son las pruebas fallidas de mayor importancia. Las pruebas de aceptación también se utilizan para detectar regresiones antes de poner en producción el sistema.
En las pruebas de aceptación también se pueden detectar errores (bugs). Si se encuentra uno de estos bugs, se debe generar una prueba de aceptación en estado fallido para evitar que dicho problema continúe dentro de sistema. El generar esta prueba antes de empezar procesos de depuración ayuda a los usuarios a definir en forma clara el problema y comunicarlo a los programadores, quienes al disponer de esta información pueden empezar a trabajar en la solución del problema, y prueban las soluciones desarrolladas mediante pruebas unitarias, las cuales se ejecutan una y otra vez hasta que el bug ha sido corregido. (Wells, 1999-2009). Los resultados de las pruebas para los casos de prueba en el desarrollo de esta tesis se encuentran en la sección 7.6.
2.6.2.2.5 Entrega
Se debe hacer entregas frecuentes del sistema a los clientes, idealmente cada semana o cada dos semanas, tiempo en el que se realizan pruebas para tener un producto funcional y listo (dentro del alcance de la iteración) para poner en producción. Las reuniones de planeación de entregas se usan para planear conjuntos de funcionalidad consistentes que puedan ser puestos a producción desde etapas tempranas del desarrollo del sistema. Debido a esto, es importante introducir las características más críticas en las etapas más tempranas, pues esto asegura contar con más tiempo para sus correcciones. (Wells, 1999-2009)
2.6.3 Descripción del contexto de la solución
El sistema administrador de recomendaciones se desarrollará bajo las siguientes condiciones:
integrará el modelo de recomendaciones.
Para utilizar las funciones necesarias para interactuar con Moodle, las vistas del sistema de administración de recomendaciones se desarrollarán en el lenguaje de programación PHP1.
2.7 Planteamiento del diseño
La solución consistirá en una aplicación web que interactúa con una base de datos propia al sistema recomendador, y la base de datos Moodle. Este sistema será utilizado por un docente con experiencia pedagógica (se requiere esta experiencia pues debe conocer, de acuerdo a los atributos de un modelo de usuario -tales como nivel de interacción, estilos de aprendizaje y niveles de interés- qué tipo de actividades resultan más adecuadas para apoyar con recomendaciones a las actividades de aprendizaje), para los fines de creación, edición y eliminación de tipos de recomendaciones. La solución tendrá como función gestionar (crear, editar, borrar) tipos de recomendaciones, y la interfaz de creación/edición expone los atributos del modelado de usuario para crear tipos de recomendaciones genéricos, los cuales se usarán por un tutor o agente inteligente para crear recomendaciones específicas, considerando la aplicabilidad que tengan estos tipos de recomendación a los casos particulares de los estudiantes.
1 PHP es el acrónimo del lenguaje PHP Hypertext Processor, lenguaje de programación ampliamente usado en el
Figura 2.2. Esquema del planteamiento del diseño de la aplicación.
2.8 Resultados esperados
Un sistema de administración de recomendaciones estáticas, que permita la gestión de tipos recomendaciones. Este sistema deberá poder manejar en su totalidad los elementos de las recomendaciones para crear los tipos con varias combinaciones de valores de atributos de modelo de usuario
Integración del sistema de administración de recomendaciones estáticas al Entorno Virtual de Aprendizaje EVA.
3.
Análisis y definición de la solución
3.1 Requerimientos
Los requerimientos para el desarrollo de la solución se definen de acuerdo a los elementos de las recomendaciones y a las necesidades UTPL dentro del entorno virtual, y de acuerdo al tipo de usuarios que van a utilizar la aplicación.
3.1.1 Requerimientos de la aplicación
3.1.1.1 Requerimientos funcionales
Los requerimientos funcionales indican los servicios que debe proporcionar el sistema, cómo debe reaccionar ante entradas particulares y cómo debe reaccionar ante situaciones particulares; también pueden declarar explícitamente lo que el sistema no debe hacer. (Somerville, 2005). Se lista a continuación un conjunto de requerimientos que el sistema debe cumplir en cuanto a su operación y comportamiento.
La interfaz de administración del sistema recomendador requiere autentificación de usuarios, esto se realizará mediante los mecanismos integrados de autentificación de Moodle.
El sistema interactúa con la base de datos del sistema recomendador y del entorno virtual para poder obtener datos sobre los estudiantes y las recomendaciones ofertadas: modelos de usuario, recomendaciones y sus condiciones, restricciones, técnicas de recomendación, acciones sobre objetos, datos del entorno, preferencias.
El sistema debe ofrecer una interfaz experta de construcción y edición de tipos de recomendaciones. La interfaz debe ofrecer las facilidades para especificar:
o Datos de tipos de recomendaciones como nombre, descripción, tipo de recurso del entorno virtual y categorías de recomendación asociadas.
se creen a partir de ese tipo de recomendación; esta información incluye un título de recomendación, explicación, texto, un enlace y restricciones de vencimiento.
o Restricciones de vencimiento.
o Condiciones, que contienen valores con los que se compararán los atributos de los modelos de usuario, para ofrecer la recomendación por medio de un tutor o agente recomendador cuando los valores del tipo de recomendación coincidan con los del modelo de usuario de algún estudiante
3.1.2 Requerimientos no funcionales
Los requerimientos no funcionales no se refieren directamente a las funciones que ofrece el sistema, sino a sus propiedades emergentes como la fiabilidad, el tiempo de respuesta (Somerville, 2005). Estos requerimientos no funcionales de clasifican en requerimientos del producto, organizacionales y externos; para este trabajo se ha determinado como necesarios únicamente requerimientos de producto.
3.1.2.1 Requerimientos del producto
Integridad de la información: El sistema debe tener un nivel aceptable con respecto a la
protección de la integridad de los datos que maneja.
Desempeño: La interfaz de administración del sistema recomendador no es un sistema de
misión crítica, por lo que su no se requiere que su desempeño se compare con altos estándares de rendimiento. Debe sin embargo, optimizarse su uso de recursos pues sería puesta a producción en un servidor no dedicado.
Confidencialidad de la información: La información que maneja el sistema de gestión de
3.2 Componentes relacionados
3.2.1 Módulo de tutor
El módulo tutor es un módulo que permite la creación de recomendaciones a un nivel menos detallado que el módulo de administración de recomendaciones. Este módulo está típicamente manejado por el profesor de cada curso, y crea recomendaciones que se ofrecen directamente a los estudiantes. Este módulo tutor para el sistema recomendador ha sido desarrollado en una tesis relacionada.
3.2.2 Modelado de usuario
Este módulo se encarga de recoger información sobre los estudiantes y definir modelos de usuario, cuyas características permiten asignar recomendaciones a los estudiantes mediante un agente recomendador. El modelado de usuario para el sistema recomendador ha sido realizado en una tesis relacionada.
A continuación se especifican las categorías de datos que componen el modelado de usuario:
Datos de entorno: Ayudan a definir el lugar geográfico del estudiante, así como el entorno computacional (hardware y software) que el estudiante utiliza para acceder al entorno virtual de aprendizaje. Dentro de esta categoría se incluye información de zona geográfica y de entorno de usuario (plataforma de acceso, ej. PC, dispositivo móvil).
Datos de interacción: Definen el grado de interés e interacción que los estudiantes tienen en su participación dentro del entorno virtual. Los atributos dentro de esta categoría son:
Nivel de interés: Grado de interés del estudiante en el curso en desarrollo, y nivel de interés en los recursos que se hacen disponibles en el entorno virtual.
3.3 Escenarios
Los escenarios consisten en el entorno en el que se desenvuelve la aplicación, tanto en los procesos de desarrollo y puesta a producción. También describen la forma en que el usuario va a interactuar con el sistema desarrollado.
3.3.1 Escenario de desarrollo y pruebas
Se realiza en un servidor de prueba del entorno EVA, en el cual se publica el sistema para su interacción con los datos de Moodle. En este sistema, un administrador experto podrá administrar crear, editar y eliminar tipos de recomendaciones. Este servidor de prueba tendrá disponible una copia de la base de datos del entorno virtual, y se integrará a esta base de datos el modelo del sistema de recomendaciones. Este servidor también tiene una copia del sistema Moodle, dentro del que se instalarán la interfaz de administración y el bloque de acceso.
3.3.2 Escenario de interacción
Un usuario administrador del sistema ingresa con credenciales apropiadas al sistema. El sistema le presentará una pantalla principal de administración, en la cual tendrá opciones como crear/editar/borrar tipos de recomendaciones, crear/editar/borrar categorías de recomendaciones, y obtener listados de los elementos antes mencionados.
Para crear un tipo de recomendación, el usuario administrador deberá ingresar a la interfaz de creación, en la cual podrá generar un nuevo tipo especificando los parámetros: descripción, tipo de recurso del entorno virtual que se va a utilizar, categorías asociadas, explicación, restricciones temporales y otros elementos. Las condiciones de aplicabilidad se dan estableciendo valores a los parámetros del modelado de usuario.
Para editar un tipo de recomendación, el usuario administrador sólo debe cambiar los valores establecidos en los parámetros de las recomendaciones.
4.
Desarrollo de la solución
En este capítulo se exponen los detalles del proceso de desarrollo de la solución. Se describirá la forma en que se ha logrado obtener el modelo de datos, las consideraciones que se ha tomado para el diseño del sistema, los requerimientos, la construcción de las interfaces de usuario, la integración con el entorno virtual de aprendizaje, consideraciones de programación y pruebas.
4.1 Desarrollo del modelo de datos
En la sección 2.6.1 se hace una descripción general de los elementos que conllevan a la creación del modelo de datos. En esta sección se van a detallar los factores y requerimientos que sirven como base y dan origen al modelo de datos.
4.1.1 Explicación de las tablas creadas en el modelo y la forma en que satisfacen los
requerimientos propuestos para su desarrollo
Es necesario desarrollar el modelo de datos de tal forma que satisfaga las necesidades planteadas por los elementos de las recomendaciones y los requerimientos de la universidad.
Se ha contado en un inicio con un esquema de un modelo de recomendaciones, propuesto por Santos y Boticario.
Figura 4.1. Modelo para recomendaciones en escenarios de aprendizaje (Santos & Boticario,
[image:39.612.110.505.499.687.2]management system, 2008)
Este modelo contiene los elementos de las recomendaciones, con las respectivas relaciones entre ellos. En base a este esquema, podemos ver que es necesario tener un modelo en el que se almacenen recomendaciones que se ajusten a varios factores, tales como categoría, técnica, origen, explicación, condiciones de aplicabilidad, restricciones de vencimiento, y un contexto de usuario.
Para poder definir condiciones de aplicabilidad de la recomendación, se debe tener en cuenta que es necesario definir atributos cuyo valor determine cuándo una recomendación es oportuna para un estudiante. Para ello, ha sido necesario desarrollar un modelado de usuario (llamados contexto de usuario en el esquema de Santos y Boticario), de tal forma que se puedan recoger y almacenar los datos de dichos modelos, y puedan servir como referencia para la oferta de recomendaciones. El trabajo de modelado de usuario sostiene que son necesarios, entre otros, los siguientes atributos para completar un modelo de usuario:
Resultados de estilos de aprendizaje: Esto es la asociación entre los estudiantes y el estilo de aprendizaje particular que posee el estudiante. El estilo de aprendizaje se llega a saber mediante la aplicación del test Felder y Silverman. Una vez que se determina el estilo de aprendizaje del usuario, se asocia al estudiante con dicho estilo y se registra la relación.
Niveles de interacción e interés: Con los datos de interacción del usuario obtenidos mediante el modelado de usuario, se puede establecer valores cualitativos para estos atributos.
Zona geográfica: Obtenido también mediante seguimiento de usuario, el valor de este atributo también es útil como condición de aplicabilidad para ofrecer una recomendación. Un ejemplo de la utilidad de este atributo es una recomendación que se ofrezca sugiriendo al estudiante su asistencia a un evento: será más relevante para las personas que se encuentren en la zona geográfica donde se va a llevar a cabo dicho evento.
el que el usuario accede con más frecuencia al entorno virtual, de tal forma que se le presenten recomendaciones cuyos cursos de acción sugeridos puedan llevarse a cabo con la ayuda de su dispositivo de acceso.
Los requerimientos de la Universidad con respecto al desarrollo del modelo son los siguientes:
Usar los datos existentes dentro de la base de datos del entorno virtual como referentes para la oferta de recomendaciones: Este requerimiento se satisface mediante el diseño del modelado de usuario y de la actividad realizada por el módulo de seguimiento de usuarios, los cuales aprovechan la información almacenada sobre el acceso e interacción de los estudiantes con el entorno virtual, datos que sirven para determinar la relevancia que tendrán las recomendaciones para los estudiantes.
Integrar el modelo de recomendaciones a la base de datos del entorno virtual: Dado que
las recomendaciones se asocian a los estudiantes, cursos y recursos, al igual que sus datos de modelo de usuario, es necesario integrar el modelo a la base de datos del entorno virtual. El diseño toma en cuenta este requerimiento y realiza las asociaciones respectivas.
Recomendar los tipos de recursos disponibles dentro del entorno virtual: El modelo de
recomendaciones incluye en la definición de datos de una recomendación o tipo de recomendación qué tipo de recurso del entorno virtual que se puede ofrecer.
El modelo completo de datos para el sistema recomendador consiste en un modelo de recomendaciones junto a un modelo de usuario. Para tener una explicación detallada del modelo de usuario, se debe revisar el trabajo exclusivamente hecho sobre él en el trabajo relacionado
“Modelado de Usuario” (sección 3.2.2). El modelo de recomendaciones se explica en detalle a continuación.
4.1.1.1 Tabla Recomendación
rec_id: Identificador único de cada recomendación creada dentro del sistema.
tec_id: Identificador de la técnica con la que va a ser creada la recomendación.
trc_id: Identificador del tipo de recomendación a partir del cual se va a derivar la recomendación
id_course: Identificador del curso en el que se ofrece la recomendación. En este campo se
va a almacenar el valor del campo id de la tupla correspondiente al curso en la tabla mdl_course
de la base de datos del entorno virtual.
id_user: Identificador del estudiante a quien se le ofrece la recomendación. En este campo se va a almacenar el valor del campo id de la tupla correspondiente al alumno en la tabla
mdl_user de la base de datos del entorno virtual.
rec_titulo: Texto que va a definir un título para la recomendación. Este título consistirá en
una denominación o descripción corta que se va a dar a la recomendación.
rec_explicación: Texto en el que se informa al alumno del por qué se le está ofreciendo
esta recomendación. Por ejemplo, una explicación para una recomendación en la que se ofrece al estudiante que visite un foro, lea las respuestas y deje sus aportes, podría ser, por ejemplo: “Esta
recomendación se le ha ofrecido porque interactuar con sus compañeros y exponer sus ideas sobre los temas de clase le ayudará a enriquecer el conocimiento adquirido”. Estas explicaciones
deberían ser coherentes con la información del modelo de usuario que tiene el estudiante en el curso, para que el estudiante sienta confianza hacia el sistema recomendador y sienta que el apoyo que le brinda es relevante.
rec_texto: Texto en el que el docente dará indicaciones o instrucciones adicionales al estudiante sobre la recomendación ofrecida a él.
rec_fecha_creacion: Fecha en que se crea (y se ofrece) la recomendación para el
estudiante.
rec_enlace: Campo que sirve para ingresar una dirección Web que puede contener un
recurso que el profesor sienta pertinente que revise el estudiante.
rec_tipo_recurso: Al ser las recomendaciones derivadas a partir de un tipo de
virtual. Estos tipos se listan en la explicación del campo trc_tipo_recurso, en la sección 4.1.1.2.
rec_id_recurso: Se almacena en este campo el campo id de la tupla correspondiente al
recurso que se esté ofreciendo en la recomendación. Estos recursos se encuentran en las tablas
mdl_assignment, mdl_forum, mdl_glossary, mdl_message, mdl_quiz, mdl_resource.upload no es
en sí un recurso que tenga un registro físico en la base de datos del entorno virtual, sino que alimenta la tabla mdl_resources.
Ya que el origen de la recomendación depende de la técnica usada, y únicamente estamos usando la técnica matching conditons para crear recomendaciones estáticas, no se define dentro del modelo.
4.1.1.2 Tabla Tipo_recomendación
Los tipos de recomendaciones son tipos predefinidos en base a los cuales se va a crear una recomendación. A continuación se explican los atributos escogidos para esta tabla:
trc_id: Identificador único del tipo de recomendación.
trc_nombre_tipo_rec: Nombre que se le otorga a un tipo de recomendación. Dicho
nombre debería explicar brevemente el propósito con el que se ha creado el tipo de recomendación.
trc_descripción_tipo_rec: Aquí se detalla los pormenores del tipo de recomendación que
se está creando, tales como el porqué de las combinaciones de valores de atributos de modelo de usuario que se definen, o el porqué de las restricciones de vencimiento establecidas.
trc_tipo_recurso: En este campo se almacena el identificador del recurso del entorno virtual que se está ofreciendo al estudiante. A continuación se listan los tipos de recursos que se van a ofrecer:
Identificador del recurso Recurso
assignment Tarea
glossary Glosario
message Mensajería
quiz Cuestionario
resource Recurso
upload Subir archivo
rec_título, rec_explicacion, rec_texto, rec_enlace: Al derivarse las recomendaciones de
los tipos de recomendación, estos campos sirven para definir una plantilla de recomendación. Los valores almacenados en estos campos servirán como valores por defecto (que podrán ser cambiados) para los campos de idéntico nombre en las recomendaciones.
4.1.1.3 Tabla Técnica
Esta tabla se ha definido para listar las técnicas mediante las cuales el sistema recomendador es capaz de generar recomendaciones. Por el momento sólo estará almacenado el registro de la técnica Matching conditions, pero cuando se cuente a futuro con un agente inteligente de oferta de recomendaciones, las técnicas que utilice (y posiblemente sus parámetros), serán almacenados en esta tabla.
tec_id: Identificador único de la técnica de generación de recomendaciones.
tec_nombre_técnica: Nombre de la técnica.
tc_descripción_tecnica: Descripción de la técnica.
4.1.1.4 Tabla Condiciones
En esta tabla se van a almacenar las condiciones bajo las cuales las recomendaciones basadas en un tipo de recomendación serán aplicables para un estudiante. Para esta tabla se definieron los siguientes campos:
rec_id: Recomendación que se ajusta a la condición actual.
id_atributo_modelo_usuario: Identificador del atributo del modelo de usuario que se
utiliza en la condición.
con_valor_condición: Valor que deberá tener el atributo de modelo de usuario para que
esta condición se cumpla y se ofrezca la recomendación.
id_course: Identificador del curso enel que se aplica la condición. El valor de este campo
es el campo id de un curso registrado en la tabla mdl_course de la base de datos del entorno virtual.
id_user: Identificador del estudiante al cual se le aplica la condición de la recomendación.
trc_id: Identificador del tipo de recomendación al cual se asocian estas condiciones.
4.1.1.5 Tabla restricciones_vencimiento
Esta tabla se almacenan las restricciones de vencimiento a las que se van a sujetar las recomendaciones.
rvc_id:Identificador único de la restricción de vencimiento.
rec_id: Identificador de la recomendación que se ajusta a estas restricciones de
vencimiento.
rvc_veces_a_mostrar: Una recomendación no puede mostrarse para siempre al
estudiante. En este campo se define un número de veces máximo que se puede mostrar la recomendación una vez que se ha realizado su oferta.
rvc_fecha_expiración: Los cursos dentro del entorno virtual de la Universidad tienen un
intervalo de tiempo en el que están activos, de la misma forma, las tareas o actividades que el profesor defina para que se realicen dentro del entorno tienen una fecha máxima de cumplimiento. Es por eso que, además de definir un número de veces que se va a mostrar la recomendación ofertada, se defina una fecha máxima hasta la que se va a mostrar.
ajustarán a la restricción de vencimiento.
4.1.1.6 Tabla Categoría
Las categorías son ámbitos de la actividad de enseñanza-aprendizaje en la cual va a influir la recomendación ofertada.
cat_id: Identificador único de la categoría de la recomendación.
cat_nombre_categoría: Nombre de la categoría.
cat_rec_descripción: Descripción del propósito de la categoría, o del propósito con el que ha definido.
4.1.2 Modelo obtenido
Figura 4.2. Gráfica del modelo de datos diseñado para la solución, obtenido conjuntamente con los autores de los módulos de seguimiento de usuarios, módulo tutor y modelado de usuario.
4.2 Visión general del sistema
