UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad ...dspace.utpl.edu.ec/bitstream/123456789/1886/3... · Escuela de Ciencias de la Computación Tesis: Sistemas Adaptativos en

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

2010

Escuela de Ciencias de la Computación

Tesis: Sistemas Adaptativos en Moodle: Interfaz de administración de

recomendaciones estáticas

ii

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

_____________________





iii

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”.

.....................................................

F) AUTOR




iv

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.

Juan Pablo




v

Í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.1 Escenario de desarrollo y pruebas ........................................................................................................ 27




vi

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.6.6 Pruebas para caso de prueba CSPRB-006 ............................................................................................. 79




vii

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

8. BIBLIOGRAFÍA ...................................................................................................................................... 142




viii

Í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

Figura 7.17. Uso de los botones de ayuda. ................................................................................... 92




ix

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.

En el presente trabajo se trata el desarrollo de una interfaz Web de administración de

recomendaciones, el cual forma parte de la implementación de un sistema de recomendaciones

completo integrado a Moodle. Se incluye el estudio de los elementos de las recomendaciones, la

creación de un modelo de datos para el sistema recomendador, el proceso y documentación del

desarrollo, la creación de un servicio Web para recuperar información del modelo de datos, la

integración de la aplicación con Moodle y las pruebas con usuarios que se realizaron para

verificar el funcionamiento de la aplicación.




x

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.

Desarrollo de un servicio Web que permite consumir los datos del modelo de

recomendaciones y de los atributos del modelado de usuario.




xi

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.

Los resultados obtenidos al final del proceso son una interfaz que permite la gestión de

tipos de recomendaciones y categorías de recomendaciones, un modelo de recomendaciones y un

servicio Web que la misma interfaz utiliza para recuperar datos desde el modelo de

recomendaciones.




1

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.

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).

Figura 1.1. Recomendaciones ofrecidas en el sitio web YouTube.




2

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.

El enfoque basado en objetos toma en cuenta una medida de similitud entre objetos que

forman vecindarios. La calificación que un usuario le dé a un objeto se predice considerando las




3

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

Se basa en la semántica o descripciones de los objetos que han preferido los usuarios para

recomendarlos a otros usuarios que hayan preferido objetos con los mismos atributos. En este

tipo de filtrado, se crea un perfil de usuario en el que se describe los objetos que se pueden

recomendar, los objetos de los que gusta el usuario y cómo comparar los objetos a recomendar

contra el perfil de usuario. Estos perfiles pueden crearse simplemente a partir de la información

que ido construyendo el usuario sobre sus preferencias sobre los objetos, o bien puede solicitarse

esta información en forma explícita. En la Figura 1.1 (recomendaciones del sitio Web YouTube)

se puede apreciar un ejemplo de este enfoque, pues los videos que se ofrecen al usuario son




4

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

La técnica Matching Conditions (satisfacción de condiciones) es la técnica que se usa para

crear recomendaciones estáticas. A diferencia de las técnicas antes mencionadas, donde se utiliza

algoritmos o agentes automáticos, emplear esta técnica de generación consisten en que un tutor o

administrador de recomendaciones analice el modelo de usuario de un estudiante y cree

recomendaciones personalizadas que se ajusten al contexto del usuario, o bien crear tipos de

recomendaciones genéricos para situaciones definidas, considerando las condiciones a las que se

tendría que ajustar un estudiante para recibir una recomendación del tipo creado. De la misma

forma, un agente recomendador puede usar esta técnica, comparando las recomendaciones

ofrecidas a un usuario y ofreciéndolas a otros usuarios que se ajusten a condiciones similares.




5

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:

Tareas: Esta funcionalidad permite que los profesores coloquen información sobre tareas

que deben realizar los estudiantes como parte de los procesos de aprendizaje dentro del

curso. Las tareas pueden ser subidas al LMS, y Moodle ofrece mecanismos de

calificación, notificaciones y retroalimentación.




6

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

La aplicación de sistemas recomendadores al campo de eLearning, y es de hecho

deseable, puesto que un sistema eLearning puede enfrentarse al problema de sobrecarga de

información, dado que puede contener miles de cursos y recursos disponibles dentro de él. En su

tesis doctoral del año 2005, Jamil Itmazi sostiene que aún en ese tiempo no existen sistemas LMS

que incluyan sistemas de recomendaciones completos, situación que persiste hasta la actualidad

(en la investigación realizada no se ha podido encontrar sistemas recomendadores completos

integrados a sistemas de gestión del aprendizaje).




7

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.

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

plataformas de e-learning mediante un servicio de recomendaciones, 2009).




8

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

situaciones frustrantes que puedan surgir dentro del desarrollo de las actividades de

enseñanza-aprendizaje dentro del curso, tales como dificultades de comprensión, o




9

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.

Restricciones temporales o de vencimiento: Dentro de este apartado se define cuándo y




10

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

recomendaciones ofrecidas y realicen las acciones recomendadas. Para lograr esto, es

importante proveer de explicaciones claras y de alto nivel sobre las recomendaciones




11

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

validar recomendaciones. Se desarrolla un procedimiento de descubrimiento de perfiles de

usuario, en que se simulan usuarios basados en una lista de evaluaciones de objetos, evaluaciones

realizadas por usuarios reales (no hay información ficticia). Además, se simula interacciones

entre estos usuarios. En este trabajo, se toman perfiles de usuario reales a partir de los cuales se

crean perfiles artificiales mediante la lectura de las preferencias, y luego se hacen

recomendaciones en base a la información de los perfiles artificiales. Si la recomendación arroja

un objeto incluido en la lista de objetos que posee el perfil real, ese objeto se considera

descubierto, caso contrario se rechaza. Las recomendaciones se hacen en ciclos que simulan días

reales. Cuando las simulaciones arrojan objetos acertados, se hacen recomendaciones a los

usuarios reales. Las simulaciones permiten obtener métricas de precisión, diversidad y retención.

La simulación de la colaboración se realiza creando listas de contactos, dichos contactos se

generan comparando los perfiles de usuario para hallar sus semejanzas. Las recomendaciones se

realizan de acuerdo a sus perfiles y los de sus contactos, y cada recomendación se evalúa

comparando los perfiles artificiales con los reales. Luego, antes de clasificar las recomendaciones




12

como válidas o no, se juzga la colaboración de los contactos para adaptar las listas de acuerdo a

los resultados más recientes. La simulación se realiza hasta agotar las variables y se entonces se

obtienen métricas y se presentan resultados.




13

2. Definición del problema

2.1 Planteamiento del problema

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.




14

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

Actualmente el LMS utilizado en la Universidad Técnica Particular de Loja (Moodle) no

cuenta con un sistema de recomendaciones. Dada su implementación, es necesario contar con un

sistema de administración de recomendaciones que permita a los un experto recomendador crear,

modelar y llevar registro de los tipos de recomendaciones que se creen dentro del sistema. Este

sistema debe permitir crear tipos de recomendaciones, explotando todas las características de los

modelos de usuario de los estudiantes, para que estos tipos de recomendaciones se usen en la

generación de recomendaciones específicas para los estudiantes, dado que cumplan con las

restricciones y características definidas en los tipos de recomendaciones, es decir, que se

establezcan las condiciones sobre las que se ofrecerá la recomendación; y la técnica con la que se

va a generar.




15

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

Para poder llevar a cabo el desarrollo de la solución, se tiene en cuenta varios aspectos. Se

debe desarrollar un modelo de datos preparado para guardar información sobre las

recomendaciones y los datos que permitan generarlas y ofrecerlas, y considerar que será diseñada

para usuarios que interactúan y aprovechan estos datos a través de interfaces diseñadas para el




16

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

tipos de recomendaciones dando valores a los parámetros que los definen, considerando

los factores apropiados de los modelos de usuario para luego, a partir de estos tipos, crear

recomendaciones específicas. En esta interfaz, al tratarse de recomendaciones estáticas, el

conocimiento de un experto se refleja al crear los tipos de recomendaciones mediante la

técnica Matching conditions.




17

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).

El desarrollo de los procesos de programación extrema puede encontrarse en los anexos

de este trabajo.




18

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

Pruebas Creación de pruebas al encontrar errores.




19

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).

Las planeaciones de entrega se usan para poder definir las planeaciones de iteración.

(Wells, 1999-2009)




20

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 historias de usuario obtenidas al iniciar la iteración se convierten ahora en las pruebas

de aceptación. Para cada historia de usuario se debe crear un caso de prueba (los casos de prueba

para el desarrollo de la interfaz de administración de recomendaciones se encuentra en la sección

7.5). En dichas pruebas los clientes determinan si las funcionalidades implementadas satisfacen

las historias de usuario creadas. Cada historia de usuario puede tener una o más pruebas de

aceptación, y no se considera completa hasta que haya pasado satisfactoriamente todas las

pruebas y se asegure que la funcionalidad está trabajando en forma completa.




21

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:

Dado que existe una base de datos de LMS (Moodle), se tomará una copia de esta base de

datos para poder recoger los datos de los usuarios del sistema, y a esta base de datos se




22

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

desarrollo de aplicaciones Web.




23

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.

Un servicio Web que permita recuperar información sobre el modelo de recomendaciones,

para que pueda ser usado desde otras aplicaciones, asegurando la interoperabilidad.




24

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.

o Información que sirva como plantilla para todas las recomendaciones que




25

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

recomendaciones no es críticamente sensible, sin embargo debe cumplir con un nivel

aceptable de protección de información.




26

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.

Nivel de interacción: Nivel de interacción de los estudiantes con el entorno virtual.




27

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.

La edición y creación de categorías de recomendaciones son las otras tareas que se

realizan en el sistema, utilizando una interfaz que permite el ingreso de datos y su

almacenamiento en la base.




28

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,

Users’ experience with a recommender system in an open source standard-based learning




29

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.

Entorno de usuario: Este atributo determina el entorno de hardware y software en




30

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

La tabla Recomendación contiene los datos sobre las recomendaciones concretas que se

ofrezcan dentro del sistema. Se ha definido un número de atributos cuya razón de ser y utilidad se

va a explicar a continuación.




31

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

recomendación, en este campo se almacenan identificadores de tipos de recursos del entorno




32

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

forum Foro




33

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:

con_id: Identificador único de la condición.




34

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 en el 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.

trc_id: Identificador del tipo de recomendación que se asocia a esta restricción de

vencimiento. De esta forma las recomendaciones creadas bajo dicho tipo de recomendación se




35

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

El modelo de recomendaciones creado se muestra a continuación, junto con algunas tablas

del modelo de usuario que se usan dentro del sistema de administración de recomendaciones. Las

tablas pertenecientes al modelo de recomendaciones tienen el prefijo mdl_sr_ y las tablas

pertenecientes al modelado de usuario tienen el prefijo mdl_mu_.




36

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

El sistema de administración de recomendaciones consta de varias funcionalidades. La

funcionalidad principal del sistema consiste en la gestión (creación, edición, borrado) de tipos de

recomendaciones. Estos tipos de recomendaciones explotan los atributos de los modelos de

usuario. El sistema también provee de capacidad de gestionar categorías de recomendaciones.




37

4.2.1 Consideraciones de diseño

En la sección de consideraciones de diseño, van a listarse las consideraciones que se

deben tomar antes de desarrollar una solución completa, así como los problemas que se deben

resolver.

4.2.1.1 Prerrequisitos y dependencias

4.2.1.1.1 Herramientas de desarrollo

Para el desarrollo del sistema de administración de recomendaciones se va a hacer uso de

las herramientas:

Lenguaje de programación PHP (PHP Hypertext Processor), versión 5

Servidor Web Apache2.

Sistema de gestión de base de datos MySQL3

Herramientas de desarrollo: IDE Zend Studio 7, MySQL Administration Tools, Toad.

Sistema operativo: Las herramientas utilizadas para el desarrollo son independientes de la

plataforma, por lo que pueden usarse plataformas Linux4 o Windows

5.

4.2.1.1.2 Características del usuario final

El usuario final es una persona con conocimientos suficientes de operación de

computadores. Estos conocimientos deben incluir la capacidad de usar un navegador Web e

interfaces de aplicaciones en general.

2 Apache es un software servidor de páginas Web, software que se utiliza para montar sitios Web sobre una

diversidad de servidores. 3 MySQL es un sistema de gestión de base de datos (SGBD) ampliamente usado en la actualidad, especialmente en

entornos Web. Una de sus principales ventajas es ser software libre y de código abierto, lo cual permite su uso sin

pago de licencias, y con acceso al código fuente del programa. 4 Sistema operativo ampliamente utilizado en servidores, es software libre y de código abierto. Junto a PHP, MySQL

y Apache, forma un paquete de software denominado LAMP (iniciales), ampliamente utilizado para despliegue de

aplicaciones Web. 5 Microsoft Windows © es un sistema operativo desarrollado por la compañía estadounidense Microsoft, utilizando

tanto en servidores como computadores personales.




38

4.2.1.1.3 Restricciones generales

No existen restricciones mayores dentro de los campos de entorno de hardware y

software, entornos de usuario final, disponibilidad o volatilidad de los recursos, y requisitos de

interoperabilidad.

4.2.1.1.4 Comunicaciones de red, repositorios de datos, memoria, desempeño

La aplicación debe optimizar sus comunicaciones con la base de datos, carga de

procesamiento y cantidad de memoria utilizada debido a que es posible que sea puesta a

producción en servidores que proporcionan recursos a otras aplicaciones utilizadas por la

Universidad.

4.2.1.1.5 Metas y guías

Las metas del diseño del sistema son las siguientes:

Crear un sistema que sea eficaz en su propósito.

Mantener el diseño simple, y de ser posible expansible y escalable: El sistema

desarrollado podría ser utilizado, modificado y expandido en proyectos posteriores.

Optimizar el uso de recursos: Debido a las razones expuestas en la sección de

restricciones 4.2.1.1.4.

Proveer una experiencia de usuario satisfactoria.

4.2.1.1.6 Métodos de desarrollo

El desarrollo de este sistema se apegará a la metodología de programación extrema (XP),

debido a que es una metodología de desarrollo rápido, y sin mayores complicaciones en la

generación de documentación y los procesos que se deben cumplir durante el desarrollo de la

aplicación.

4.2.1.1.7 Librerías

Se usarán las librerías de funcionalidad que provee Moodle para presentación, manejo de




39

autenticación de usuarios, e interacción con la base de datos.

4.2.1.1.8 Arquitectura del sistema

En esta sección se expone a alto nivel las funcionalidades y responsabilidades de cada

componente del sistema, para dar una idea general de cómo funciona el sistema para cumplir con

las funciones que se desean implementar.

Módulo de creación/edición/borrado de tipos de recomendaciones: Este módulo permite

gestionar tipos de recomendaciones editando todos los parámetros disponibles para su

definición.

Módulo de creación/edición/borrado de categorías de recomendaciones: Este módulo

permite gestionar categorías de recomendaciones editando los parámetros disponibles

para su definición.

Listados: Se presentan listados de recomendaciones, tipos de recomendaciones y

categorías de recomendaciones.

4.2.1.1.9 Políticas y tácticas

Las pruebas de funcionalidad de la aplicación se realizarán al terminar cada iteración del

desarrollo del sistema, para asegurar que el sistema cumpla con los requerimientos para

los cuales se está construyendo.

4.3 Desarrollo de mecanismo de autenticación

Para ingresar a la interfaz de administración se requiere que el usuario se autentifique.

Dicha autenticación se realiza con los mecanismos integrados de Moodle (el usuario debe tener

un nombre de usuario y contraseña válidos dentro del entorno virtual), y además, es necesario

que el usuario tenga un rol de administrador de recomendaciones. La asignación de roles es tarea

del administrador del entorno virtual.

El siguiente código, incluido en todas las páginas del sistema, asegura que los usuarios

que ingresen se autentifiquen como usuarios del entorno virtual de aprendizaje y que tengan

asignado el rol de administradores de recomendaciones.




40

<?php

require ("../config.php");

global $CFG, $USER, $COURSE;

if ($CFG->forcelogin) {

require_login ();

}

// Verificar el rol del usuario actual

if (! (record_exists ( 'role_assignments', 'roleid', 24, 'userid', $USER -> id

))) {

include ('./error.php');

exit;

}?>

4.4 Desarrollo del servicio Web

Un servicio Web es una interfaz de aplicación de programaciones que se ejecuta en un

servidor y puede ser utilizada por aplicaciones cliente, para proveer información mediante el uso

de protocolos abiertos. En el desarrollo de esta tesis, se ha creado un servicio Web de

administración de recomendaciones, el cual provee información sobre tipos de recomendaciones,

categorías de recomendaciones y valores de atributos de modelo de usuario. El servicio Web

implementado permite que la aplicación tenga una arquitectura orientada a servicios, lo cual

significa que la comunicación entre la aplicación y el servicio hace uso de mensajes. Dicho

servicio se ha desarrollado con en el framework de servicios web para PHP NuSOAP

(http://sourceforge.net/projects/nusoap/), el cual permite implementar y consumir servicios web

basados en el protocolo SOAP (Simple Object Access Protocol).

4.4.1 Operaciones del servicio Web

El servicio Web expone información tanto del modelo de recomendaciones como del

modelo de usuario. Dados los requerimientos de información que debe manejar la interfaz de

administración de recomendaciones, se han definido las siguientes operaciones dentro del

servicio Web desarrollado:

GetTiposRecomendacion: Se utiliza para obtener todos los tipos de

http://sourceforge.net/projects/nusoap/




41

recomendación existentes dentro del modelo del sistema recomendador.

GetTipoRecomendacion: Se utiliza para recuperar un tipo de recomendación en

particular.

GetRestricVencDeTipoRecomendacion: Para obtener un conjunto de

restricciones de vencimiento asociadas a un tipo de recomendación.

GetCategoriasAsociadasATipoRecomendacion: Para obtener las categorías que

se asocian a un tipo de recomendación.

GetCategoria: Obtener una categoría de tipos de recomendaciones.

GetCategorias: Obtener todas las categorías de recomendaciones existentes

dentro del sistema.

GetCondicionDeTipoRec: Obtener las condiciones asociadas a un tipo de

recomendación.

GetValoresEstereotiposAtribModeloUsuario: Datos recuperados desde el

modelo de usuario que indican los valores que puede tomar un atributo de modelo

de usuario.

Al ser un servicio Web basado en SOAP, cuenta con un archivo WSDL (Web Services

Description Language), el cual describe las operaciones disponibles del servicio. También, los

datos que se obtienen del servicio Web están definidos mediante el lenguaje XML6, el cual es

elemento primordial de los servicios Web basados en SOAP.

La aplicación de administración de recomendaciones consume las operaciones del

servicio creado para todas las operaciones en las que es necesario obtener datos desde el modelo

del sistema recomendador. Los mensajes XML se reciben y se les da tratamiento adecuado para

que sean presentados en las vistas como información legible.

El servicio Web implementado permite que toda la información disponible dentro del

6 XML, (eXtensible Markup Language), es un estándar abierto que define un conjunto de reglas para codificar

documentos en formatos legibles por computador. Sus principales objetivo son la simplicidad y generalidad de

representación de información, y la interoperabilidad y uso sobre Internet de la información.




42

modelo de recomendaciones esté disponible para otras aplicaciones, de tal forma se asegura la

interoperabilidad, al ofrecer la información con un mecanismo ampliamente usado y aceptado.

La definición WSDL del servicio y la implementación del servicio se pueden encontrar en

los anexos 7.8 y 7.10.

Figura 4.3: Esquema del consumo del servicio Web implementado para la interfaz de

administración de recomendaciones

4.5 Desarrollo de las interfaces

Las interfaces de la aplicación se desarrollan con el lenguaje PHP, HTML7 (Hypertext

7 HTML, o Hypertext Markup Language, es el lenguaje predominante para el desarrollo de páginas Web.




43

Markup Language), Javascript8 (funciones de validación y navegación), y CSS (Cascade Style

Sheets, hojas de estilo en cascada), para aplicar estilos estandarizados a las interfaces. Para poder

satisfacer los requerimientos expuestos en la sección 3.1, se van a desarrollar las siguientes

interfaces de la aplicación:

Menú lateral de funcionalidades

Listado de tipos de recomendación

Creación/edición de tipos de recomendación

Listado de categorías de recomendaciones

Creación /edición de categorías de recomendaciones

Borrado de datos.

4.5.1 Menú lateral de funcionalidades

Este menú contiene acceso a las funcionalidades que se han desarrollado en todo el sistema.

Este menú se puede encontrar en todas las interfaces de la aplicación.

Figura 4.4. Menú lateral de la aplicación.

4.5.2 Listado de tipos de recomendación

Esta interfaz tiene como funcionalidad poder listar todos los tipos de recomendaciones

8 Lenguaje utilizado en desarrollo de aplicaciones Web para validación de datos, despliegue de contenidos y manejo

de información. A diferencia de PHP, este lenguaje no se ejecuta en el servidor, sino en el navegador.




44

que se creen dentro del sistema. Provee de facilidades para realizar acciones de creación, edición,

visualización y borrado de los tipos de recomendación.

Figura 4.5. Listado de tipos de recomendación.

4.5.3 Creación/Edición de tipos de recomendación

Es una de las dos principales interfaces de la aplicación. Provee las facilidades para

ingresar todos los campos de un tipo de recomendación, una plantilla de recomendación,

condiciones de aplicabilidad y restricciones de vencimiento.




45

Figura 4.6. Interfaz de creación/edición de recomendaciones.

En esta interfaz se refleja el trabajo hecho en el modelo de recomendaciones. Se puede




46

observar que en ella, se introducen los datos para alimentar las tablas de tipos de

recomendaciones, condiciones de aplicabilidad, restricciones de vencimiento, y se recuperan

datos desde el modelado de usuario: estilos de aprendizaje, zona geográfica, plataforma, niveles

de interés en recursos y curso, y niveles de interacción.

4.5.4 Listado de categorías de recomendación

Consiste en un listado de las categorías de recomendaciones que se crean dentro del

sistema. Esta interfaz provee las facilidades necesarias para crear, visualizar, editar y eliminar

categorías de recomendaciones.

Figura 4.7. Interfaz de listado de categorías.

4.5.5 Creación/Edición de tipos de categorías

Esta interfaz permite tanto la creación como la edición de tipos de categorías.




47

Figura 4.8. Interfaz de creación/edición de categorías.

4.5.6 Borrado de datos

Las interfaces de listados permiten acceder a una funcionalidad de borrado de datos. Se ha

desarrollado una interfaz genérica para utilizarse tanto con categorías o tipos de

recomendaciones. Esta interfaz solicita que se confirme la operación para evitar que se eliminen

datos por equivocación.

Figura 4.9. Diálogo de confirmación de eliminación de datos.

4.6 Integración con Moodle

La integración del sistema con Moodle se realiza mediante la programación de un bloque

Moodle, el cual permite que los usuarios accedan desde el entorno virtual de aprendizaje a la




48

aplicación de interfaz de administración de recomendaciones. Este bloque puede colocarse tanto

en las páginas principales de los usuarios como en los cursos a los que tengan acceso.

El bloque desarrollado cumple con la función de verificar el rol del usuario actual, de

manera idéntica a los mecanismos de la aplicación, de tal forma que no se permite el acceso a la

aplicación sin los requisitos de acceso necesarios (autenticación dentro de Moodle, rol de

administrador de recomendaciones)

La programación de este bloque resulta en una pequeña pieza de software que debe ser

agregada a las páginas de Moodle a las que tenga acceso un usuario administrador de

recomendaciones.

Figura 4.10. Bloque Moodle desarrollado

4.7 Consideraciones de la programación de la aplicación

En esta sección de la tesis se detallan consideraciones sobre el diseño y programación de

la aplicación.

4.7.1 Diseño visual

Las interfaces de la aplicación han sido programadas con un estilo visual coherente. Para

poder lograr esto, se ha utilizado hojas de estilos en cascada (CSS), con apego a los atributos

estándar de CSS9.

9 CSS (Cascade Style Sheet) es un lenguaje que permite separar el contenido de un documento escrito en un lenguaje

de marcas (como HTML) de sus detalles de presentación.




49

4.7.2 Prácticas de programación

Gracias a la utilización del lenguaje PHP, HTML y Javascript, se ha logrado diseñar con

soltura las vistas de la aplicación. Se ha tomado en cuenta buenas prácticas de programación y de

seguridad, tales como añadir secuencias de escape en los campos de texto, analizar entradas de

usuario para evitar inyección SQL10

, no utilizar características no estándares de los lenguajes,

caso que ocurren con frecuencia con los lenguajes HTML y Javascript, y los atributos de las hojas

de estilo en cascada.

4.8 Pruebas de la aplicación

Se ha definido, con el uso de la metodología de programación XP, casos de prueba

necesarios para poder verificar que las interfaces funcionen en la forma que se espera que

funcionen, y que resultan manejables por parte de los usuarios. Los casos de prueba definidos

para la aplicación y los resultados de la ejecución de las pruebas de detallan en las secciones 7.5

y 7.6, respectivamente.

10

SQL (Standard Query Language) es un lenguaje estandarizado para manejar los datos de una base de datos.

Inyección SQL es una técnica de ataque a aplicaciones que consiste en insertar comandos SQL dentro de datos que

ingresan a la aplicación, con el fin de robar información o dañar la base de datos.




50

5. Discusión de resultados

El trabajo resultante ha sido el producto de varias actividades. En primer lugar, realizando

un análisis de los elementos de las recomendaciones, se obtuvo un modelo de datos para albergar

la información de recomendaciones y tipos de recomendaciones. El siguiente paso fue desarrollar

una interfaz que permita realizar la administración de recomendaciones. Esta interfaz se

construyó cumpliendo con los requerimientos del diseño del modelo y los requerimientos UTPL.

La parte final de la implementación fue la integración de la interfaz a Moodle, lo cual se realizó

mediante la programación de un bloque Moodle.

5.1 Modelo de datos

El modelo de datos resultante consiste en una base de datos diseñada para albergar tanto el

modelo de recomendaciones como el modelado de usuario. El esquema de dicho modelo de datos

obtenido se encuentra la sección 4.1.2.

5.2 Servicio Web

Se implementó un servicio Web, del cual hace uso la interfaz de administración de

recomendaciones para recuperar información del modelo de recomendaciones: tipos de

recomendaciones, categorías de recomendaciones, restricciones de vencimiento y valores de

atributos de modelo de usuario. Las operaciones del servicio Web permiten que la información

esté disponible tanto para la interfaz de administración como para otras aplicaciones que la

requieran.

5.3 Interfaz de administración

La interfaz de administración resultante es un conjunto de vistas que permiten administrar

los tipos de recomendación. Permiten ingresar tipos de recomendaciones seleccionando los

parámetros que son necesarios para definirlas tales como nombre, descripción, tipo de recurso

Moodle, restricciones de vencimiento, condiciones de aplicabilidad. Los tipos de

recomendaciones pueden ser editados en su totalidad. De la misma forma, pueden crearse y




51

editarse las categorías de recomendaciones, y pueden revisarse listados tanto de tipos de

recomendaciones como de categorías de recomendaciones. La interfaz de administración podrá

ser utilizada por profesores con sus credenciales actuales de Moodle, o bien pueden crearse

nuevos usuarios bajo un rol Moodle, comentado más adelante. La información guardada por la

interfaz de administración podrá ser leída por un módulo tutor o un agente recomendador.

5.4 Integración con Moodle

La interfaz de administración de recomendaciones está integrada con Moodle de las

siguientes formas:

Se usa el mecanismo de autenticación de Moodle para iniciar sesión y acceder al sistema.

El sistema exige que el usuario que vaya a utilizar la aplicación tenga asignado el rol de

administración de recomendaciones, rol que para el caso de la aplicación creada, se ha

definido en la administración de Moodle.

El sistema se accede desde un bloque Moodle que se puede agregar en cualquier curso.

La programación de las interfaces utiliza funciones que provee Moodle para recuperación

de datos.

La integración con Moodle no ha resultado en mayores problemas, a excepción de la

agregación de bloques Moodle, paso en el que se debe tener cuidado para evitar estropear la

estructura de bloques existentes.

5.5 Pruebas

Las pruebas se realizaron con docentes de la Universidad, usando una copia de la base de

datos del entorno virtual de aprendizaje, por lo que las pruebas del sistema se realizaron en un

entorno muy similar al entorno en que se tendría que desenvolver el sistema en tiempo de

producción.

Los docentes que colaboraron para la realización de las pruebas indicaron que el sistema

es bastante útil para su propósito, y que es sencillo de manejar y entender.




52

5.6 Trabajos futuros

Si bien hasta el momento se ha completado el alcance del trabajo de esta tesis y se han

cumplido los objetivos, se pueden proponer a continuación las siguientes tareas para

complementar el trabajo realizado:

Realizar un mayor desglose en la interfaz para seleccionar la condición de zona

geográfica. Si bien en el trabajo de modelado de usuario se presenta este desglose, no se

ha presentado la forma de implementarlo dentro del modelo de datos.

Mejorar las características de navegabilidad de las interfaces de listado, para que hayan

capacidades de paginación y evitar cargas de datos muy elevadas al momento de abrir las

páginas.

Integrar las interfaces del módulo de modelado de usuario con las de la interfaz de

administración de recomendaciones para tener acceso a los datos de modelos de usuario

en una mejor manera.




53

6. Conclusiones y recomendaciones

6.1 Conclusiones

Al término del trabajo realizado en esta tesis, se extraen las siguientes conclusiones:

En el modelo de recomendaciones desarrollado para el sistema, fue

necesario incluir información sobre las recomendaciones, tipos de

recomendaciones, categorías, técnicas, restricciones y condiciones;

adicionalmente a ello fue necesario incluir información de modelado de

usuario, la cual permite determinar cuándo las recomendaciones son

aplicables a los estudiantes.

La interfaz de administración desarrollada permite crear tipos de

recomendaciones con valores definidos para los atributos del modelo de

usuario, lo cual permitirá ofrecer los recursos disponibles dentro del

entorno virtual mediante recomendaciones creadas a partir de dichos

tipos.

La selección de los tipos de actividades: tareas, foros, glosarios, mensajería,

cuestionario, subir archivo y recurso, se realizó por que son los más utilizados dentro

del entorno virtual, por consiguiente con los que están más familiarizados tanto

estudiantes como profesores.

La integración de la interfaz con Moodle es necesaria para que el

sistema pueda ser accedido con facilidad desde el Entorno Virtual de

Aprendizaje. La integración no sólo contempla un fácil acceso y uso,

sino también un ambiente familiar de trabajo, es decir, similar a las

interfaces propias del EVA.

El desarrollo de servicios Web permite el acceso a la información del

modelo de recomendaciones en una forma estandarizada. De tal forma es

sencillo, tanto para la interfaz de administración de recomendaciones

como para otras aplicaciones, el acceso a dicha información.

Un sistema de recomendaciones involucra la acción de varios módulos:




54

un módulo de administración de recomendaciones para establecer tipos

genéricos predeterminados de recomendaciones, un módulo de modelado de

usuario para determinar la pertinencia de la oferta de

recomendaciones, y un módulo de tutor para ofrecer las recomendaciones

por parte de los docentes a los alumnos. Adicionalmente, un módulo de

seguimiento de usuarios permite obtener información valiosa sobre las

interacciones de los estudiantes con el Entorno Virtual.




55

6.2 Recomendaciones

Se debe entender muy bien el funcionamiento y estructura de un sistema de

recomendaciones para poder generar un modelo de datos y construir el sistema. Los

modelos aportados por los autores Santos y Boticario fueron de gran utilidad para

desarrollar el modelo de datos para la interfaz de administración de recomendaciones.

Es necesario realizar más trabajos investigación para proveer de mayor información

sobre desarrollo de aplicaciones integradas a Moodle.

Para formar un sistema de recomendaciones completo deben integrarse los diferentes

módulos desarrollados (Seguimiento de usuario, Módulo Tutor, Modelado de usuario,

Interfaz de administración), así como crear un agente de recomendaciones, el cual se

encarga de ofrecer las recomendaciones a los estudiantes de acuerdo a los valores de

sus modelos de usuario y las recomendaciones que se ajusten a ellos.

Diseñar interfaces de usuario amigables para que personas con diferentes niveles de

conocimiento puedan utilizar aplicaciones sin mayores problemas. Tener en cuenta

aspectos como navegabilidad, usabilidad, aspecto visual, familiarización con entornos

manejados con anterioridad.

Debe realizarse un proceso de pruebas de la aplicación, el cual es útil para verificar el

funcionamiento del sistema y la impresión que tienen los usuarios sobre el mismo.

Si los datos del sistema recomendador deben estar disponibles para múltiples

aplicaciones sobre diferentes tipos de plataformas, es conveniente implementar un

mecanismo estandarizado y de alta accesibilidad para poder recuperarlos, tal es el caso

de los servicios Web.

Explorar las posibilidades del uso de más tipos de actividades dentro del entorno virtual

para poder ofrecer dichas actividades dentro de las recomendaciones.




56

7. Anexos

7.1 Historias de Usuario

En la sección 2.6.2.2.1 se ha explicado la utilidad y función de las historias de usuario

dentro de la aplicación de la metodología XP. Con el fin de satisfacer los requerimientos y

delinear las funcionalidades necesarias para el sistema, se han diseñado las historias de usuario

que se presentan en este anexo.

Historia de Usuario

Número: 1 Nombre: Ingreso al sistema

Usuario: Administrador de recomendaciones

Modificación de Historia Número: 1 Iteración Asignada: 1

Prioridad en Negocio (Alta / Media / Baja): Alta Puntos Estimados: 1

Riesgo en Desarrollo: (Alto / Medio / Bajo): Bajo Puntos Reales: 1

Descripción: El usuario ingresa a la página principal del sistema, donde es requerido que se

autentifique como usuario registrado en la plataforma Moodle.

Observaciones: Todas las páginas del sistema de administración de recomendaciones deben

estar protegidas con autenticación de usuarios.




57

Historia de Usuario

Número: 2 Nombre: Consultar categorías de recomendaciones en el sistema




Riesgo en Desarrollo: (Alto / Medio / Bajo): Medio Puntos Reales: 1

Descripción: El usuario ingresa a una lista que contiene las categorías de recomendación

creadas dentro del sistema. En esta lista podrá elegir opciones como creación, edición,

visualización y eliminación de categorías de recomendaciones.

Observaciones: No hay observaciones

Historia de Usuario

Número: 3 Nombre: Crear y editar categorías de recomendaciones





Descripción: El usuario dispone de una interfaz en la que puede ingresar el nombre y la

descripción de una categoría de recomendaciones, para posteriormente guardarla en el

sistema. Si se trata de edición, selecciona la categoría desde la lista de categorías, y se le




58

presenta los valores actuales, los cuales puede cambiar y guardar.

Observaciones: No hay observaciones.

Historia de Usuario

Número: 4 Nombre: Consultar tipos de recomendaciones en el sistema





Descripción: El usuario ingresa a una lista que contiene los tipos de recomendación creados

dentro del sistema. En esta lista podrá elegir opciones como creación, edición, y eliminación

de tipos de recomendaciones.


Historia de Usuario

Número: 5 Nombre: Crear y editar tipos de recomendación








59

Descripción: El usuario dispone de una interfaz en la que puede ingresar el nombre y la

descripción de un tipo de recomendaciones, así como una o más categorías de recomendación

a la que sujeta dicho tipo. También debe poder ingresar datos para crear una “plantilla de

recomendación”. Estos datos se utilizarán para rellenar como valores por defecto al momento

de crear una recomendación a partir de un tipo de recomendación; dichos datos consisten en

un título, texto, explicación, y un enlace. En esta interfaz también debe permitir ingresar

valores para las condiciones (estilo de aprendizaje, ubicación geográfica, plataforma, nivel de

interacción, nivel de interés en el curso, nivel de interés en recursos) y restricciones de

vencimiento (número de veces a mostrar, fecha límite de oferta) a las que se sujetará ofrecer

una recomendación de este tipo. Una vez que se ingrese toda la información, debe permitir

guardarla, y a continuación presentar el cómo se guardó la recomendación. Si se trata de

edición, se le presentarán los valores actuales, los cuales puede cambiar y guardar.


Historia de Usuario

Número: 6 Nombre: Borrado de datos

Usuario: Administrador de recomendaciones.

Modificación de Historia Número: 1 Iteración Asignada:

Prioridad en Negocio (Alta / Media / Baja): Puntos Estimados:

Riesgo en Desarrollo: (Alto / Medio / Bajo): Puntos Reales:

Descripción: En las listas de datos existentes en el sistema, existe la opción de borrado. Al

seleccionar esta opción, el usuario debe confirmar que desea eliminar los datos. Si se cancela

el borrado, debe ser llevado de vuelta a la lista.




60


7.2 Desarrollo de la planeación de la entrega.

En la sección 2.6.2.2.2 se explica cómo se realiza un proceso de planeación de entrega en

el marco de la aplicación de la metodología de desarrollo XP. Se presentan a continuación las

tareas que se han asignado para realizar y que deben concluir con dos entregas:

Primera entrega: Para la primera entrega, se van a desarrollar las siguientes

funcionalidades del sistema:

Autenticación de usuarios

Creación de estilos CSS para estandarizar la apariencia de la aplicación.

Aseguramiento de la aplicación mediante el desarrollo de mecanismos para evitar

inyección SQL.

Interfaces de administración de categorías de recomendaciones.

Segunda entrega

Desarrollo de interfaces de administración de tipos de recomendaciones.

Desarrollo de interfaz de edición y listado de recomendaciones.

Desarrollo de métodos de borrado de datos.




61

7.3 Planeación de Iteraciones

Una planeación de iteraciones se diseña para entregar versiones funcionales del sistema en

períodos cortos de tiempo. Para el desarrollo de la interfaz de administración de recomendaciones

se ha establecido dos iteraciones, la primera concerniente a aspectos de integración con Moodle,

estilos visuales y categorías de recomendaciones; y la segunda con creación de tipos de

recomendaciones y el resto de operaciones de edición y borrado de datos.

Tareas de la iteración 1

Tarea

Número tarea: 1 Número historia: 1

Nombre tarea: Creación de un mecanismo de autenticación, y menú lateral de la aplicación.

Tipo de tarea : Desarrollo Puntos estimados: 1

Fecha inicio: 2010/07/29 Fecha fin: 2010/07/30

Programador responsable: Juan Pablo Angamarca G.

Descripción:

Crear un script que pueda ser incluido en todas las vistas de usuario para que se haga

indispensable un inicio de sesión dentro del entorno EVA.

Crear un menú lateral que permita acceder a todas las funcionalidades del sistema.

Tarea


Nombre tarea: Creación de una interfaz de listado de categorías de recomendaciones.






62

Programador responsable:

Descripción:

Diseñar una interfaz de listado de categorías de recomendaciones.

Crear estilos CSS para aplicarlo en forma estándar en todas las vistas.

Tarea


Nombre tarea: Creación de una interfaz de creación y edición de categorías de

recomendaciones.




Descripción:

Crear una interfaz para crear y editar categorías de recomendaciones. La página debe

controlar que los datos ingresados sean válidos de acuerdo a los tipos de datos de la

página.

Crear un mecanismo para asegurar que los datos en los requests11

a la página no sean

vulnerables a inyección SQL, para aplicar dicho mecanismo a esta página y a todas las

que utilicen parámetros en los requests.

Crear estilos CSS para estandarizar la apariencia de las páginas de creación y edición de

datos.

11

Acción que se realiza sobre un recurso Web.




63

Tarea


Nombre tarea: Creación de una interfaz de listado de tipos de recomendaciones.




Descripción:

Crear una interfaz para listar los tipos de recomendaciones que se creen dentro del

sistema. Debe utilizar los estilos CSS estándar de la aplicación.

Iteración 2

Tarea


Nombre tarea: Creación de una interfaz de creación y edición de tipos de recomendación




Descripción:




64

Crear una interfaz que permita crear y editar tipos de recomendación. Los campos que se

ingresarán/editarán serán los siguientes:

o Nombre del tipo de recomendación

o Descripción del tipo de recomendación

o Categorías asociadas al tipo de recomendación

o Actividad del entorno virtual que se va a utilizar en la recomendación. Este listado

se limita por ahora a Tarea, Foro, Glosario, Mensajería, Cuestionario, Recurso,

Subir archivo.

o Título de recomendación

o Explicación de recomendación

o Texto de la recomendación

o Enlace (dirección Web)

o Restricciones de vencimiento (fecha de vencimiento, número de veces a mostrar

antes de vencer)

o Condiciones: Estilo de aprendizaje, Zona geográfica (lista de centros

universitarios), Plataforma, Nivel de Interés en el curso, Nivel de interacción.

Esta interfaz debe usar los estilos CSS estándar de la aplicación.

Tarea


Nombre tarea: Borrado de entidades de datos







65

Descripción:

Creación de una página estándar de confirmación y ejecución del borrado de datos de la

aplicación. De acuerdo al tipo de entidad que se realice el borrado, esta página debe

redireccionar al listado de entidades de dicho tipo.




66

7.4 Tarjetas CRC

Las reglas de XP (sección 2.6.2.1) establecen que deben usarse tarjetas CRC (Clase –

Responsabilidad - Colaboración) con el fin de identificar las clases que van a ser usadas dentro

del diseño del software, las responsabilidades (funciones) que van a cumplir dentro del sistema y

las clases que colaboran con ellas, con el fin de apreciar la interacción entre las entidades que

trabajan en la solución del problema (Wells, 1999-2009). Dentro del proceso de desarrollo del

sistema de administración de recomendaciones, se han identificado clases utilitarias y clases que

representan entidades dentro del contexto del negocio. Esta sección contiene las tarjetas

diseñadas para las clases identificadas.

7.4.1 Clases que representan entidades dentro del contexto del negocio.

Recomendación

Descripción: Representación en la base de datos de la entidad Recomendación del modelo de

datos

Responsabilidades Colaboradores

Servir de contenedor de los datos de una recomendación para su

guardado y recuperación en la base de datos

DataUtils

Categoría

Descripción: Representación en la base de datos de la entidad Categoría del modelo de datos





67

Servir de contenedor de los datos de una categoría de

recomendaciones para su guardado y recuperación en la base de

datos

DataUtils

RestricciónVencimiento

Descripción: Representación en la base de datos de la entidad Restricción_Vencimiento del

modelo de datos


Servir de contenedor de los datos de las restricciones de vencimiento

asociadas a una recomendación o tipo de recomendación para su

guardado y recuperación en la base de datos

DataUtils

TipoRecomendacion

Descripción: Representación en la base de datos de la entidad Tipo_recomendación del modelo

de datos


Servir de contenedor de los datos de un tipo de recomendación para

su guardado y recuperación en la base de datos

DataUtils

Condicion




68

Descripción: Representación en la base de datos de la entidad Condición del modelo de datos


Servir de contenedor de los datos de una condición de aplicabilidad

de una recomendación o tipo de recomendación para su guardado y

recuperación en la base de datos

DataUtils

CategTipoRec

Descripción: Representación en la base de datos de la relación entre las entidades Categoría y

Tipo de recomendación del modelo de datos


Servir de contenedor de los datos de la asociaciones de tipos de

recomendación y categorías para su guardado y recuperación en la

base de datos

DataUtils

7.4.2 Clases utilitarias

DataUtils

Descripción: Esta clase provee utilidades de manejo CRUD12

de datos.


12

CRUD, acrónimo de Create, Read, Update, Delete (Crear, leer, actualizar, borrar); son operaciones básicas sobre

los datos de una base de datos.




69

Insertar registros en la base de datos Recomendacion

Actualizar registros en la base de datos TipoRecomendacion

Borrar registros en la base de datos. Categoria

Obtener registros desde la base de datos RestriccionVencimiento

Procesar los datos para evitar que las entradas de usuario provoquen

funcionamiento indebido de la aplicación, tal como la apertura para

ataques de inyección SQL o inserción de código HTML en las

páginas del sistema.

Condicion

Utils

Descripción: Proporcionar diferentes utilidades al sistema


Establecer el tipo de acción que realiza un

formulario de datos (inserción o actualización)

DataUtils

Procesamiento de direcciones Web para su

correcta presentación.

Validación de parámetros de requests para

evitar la apertura a ataques de inyección SQL.

Obtener registros desde la base de datos




70

PresentationUtils

Descripción: Proveer funciones estándares de presentación de mensajes dentro del sistema.


Presentar mensajes de error. Recomendacion

Presentar mensajes de advertencia. TipoRecomendacion




71

7.5 Casos de prueba

Los casos de prueba se diseñan para verificar que las historias de usuario se pueden

ejecutar con las funcionalidades desarrolladas. Se ha desarrollado un caso de prueba por cada

historia de usuario propuesta, para hacer que los usuarios sigan las instrucciones indicadas y

efectuar las correcciones al sistema necesarias.

CASO DE PRUEBA

Identificador CSPRB-001

Historia de

Usuario

Ingreso al sistema

Descripción Este caso de prueba sirve para verificar que la entrada al

sistema exige autentificación.

Prioridad Alta

Requisitos Que el sistema esté ejecutándose.

Que al usuario se le haya asignado el rol de

administración de recomendaciones dentro de

Moodle.

Acciones El administrador de recomendaciones ingresa a la

página principal de la interfaz de administración de

recomendaciones, ya sea desde el enlace que se le

presentará dentro del entorno Moodle, o accediendo

directamente a alguna de las páginas que

conforman el sistema. Si no hay una sesión iniciada

como usuario Moodle, la pantalla estándar de inicio

de sesión de Moodle deberá aparecer.

Resultado

esperado

Una vez ingresadas las credenciales de usuario

Moodle, el sistema debe llevar al usuario a la

página solicitada.




72

CASO DE PRUEBA


Historia de

Usuario

Consultar categorías de recomendaciones en el sistema

Descripción Este caso de prueba verifica que la interfaz de listado de

categorías de recomendaciones está disponible y puede

utilizarse.

Prioridad Alta

Requisitos El usuario debe haber ingresado al sistema con su nombre

de usuario y contraseña.

Acciones En el menú lateral, debe hacer clic en el enlace

“Listado”, en la sección Categorías de

recomendaciones.

Resultado

esperado

El usuario debe encontrar la lista de categorías de

recomendaciones del sistema una vez que ha

realizado las acciones descritas, y debe encontrar

enlaces para ver, editar y borrar por cada categoría

de recomendación. También debe ser capaz de

acceder a la interfaz de creación de categorías de

recomendaciones desde el botón Crear categoría.

CASO DE PRUEBA


Historia de

Usuario

Crear y editar categorías de recomendaciones

Descripción Este caso de prueba verifica que la interfaz de creación y

edición de categorías de recomendaciones está disponible y

puede utilizarse.

Prioridad Alta




73

Requisitos El usuario debe haber ingresado al sistema, y debe estar

ubicado en la interfaz de listado de categorías de

recomendaciones.

Acciones El usuario hace clic en el botón Crear categoría o

en el enlace Editar en la lista de categorías. Será

llevado a una página donde podrá ingresar o editar

los valores necesarios para crear una nueva

categoría de recomendaciones o modificar una ya

existente. Los valores que puede editar son Nombre

de la categoría y Descripción de la categoría

(ambos obligatorios). Luego de terminar de

ingresar o modificar los campos, debe hacer clic en

el botón Guardar. Si no se han ingresado los

campos obligatorios, se le presentará un mensaje

indicándole que debe completarlos.

Resultado

esperado

Una vez ingresados los valores necesarios, al hacer

clic en el botón Guardar se mostrará una página que

indicará al usuario la nueva categoría, o el estado la

categoría editada.

CASO DE PRUEBA


Historia de

Usuario

Consultar tipos de recomendaciones en el sistema

Descripción Este caso de prueba verifica que la interfaz de listado de

tipos de categorías de recomendaciones está disponible y

puede utilizarse.

Prioridad Alta

Requisitos El usuario debe haber ingresado al sistema.




74

Acciones En el menú lateral, debe hacer clic en el enlace

“Listado”, en la sección Tipos de recomendaciones.

Resultado

esperado

El usuario debe encontrar la lista de tipos de

recomendaciones una vez que ha realizado las

acciones descritas. Para cada tipo listado, deben

existir enlaces para ver detalle, editar y borrar.

CASO DE PRUEBA


Historia de

Usuario

Crear y editar tipos de recomendaciones

Descripción Este caso de prueba verifica que la interfaz de creación y

edición de tipos de recomendaciones está disponible y

puede utilizarse.

Prioridad Alta

Requisitos El usuario debe haber ingresado al sistema con su nombre

de usuario y contraseña, y debe estar ubicado en la interfaz

de listado de tipos de recomendaciones.

Acciones El usuario hace clic en el botón Crear tipo de

recomendación o en el enlace Editar en la lista de

categorías. Será llevado a una página donde podrá

ingresar o editar los valores necesarios para crear

un nuevo tipo de recomendación o modificar uno

ya existente. Los valores que se podrán editar en

los campos del formulario están divididos en

secciones:

o Tipo de recomendación: Nombre del tipo

(obligatorio), Descripción del tipo,

Actividad del entorno virtual, Categorías de




75

recomendación asociadas (obligatorio).

o Plantilla de recomendación: Título

(obligatorio), Explicación, Texto de la

recomendación (obligatorio), Enlace.

o Restricciones de vencimiento: Fecha de

vencimiento, veces a mostrar (debe

completarse por lo menos uno de los dos).

o Condiciones: Estilo de aprendizaje, Zona

geográfica, Plataforma, Nivel de interés en

el curso, nivel de interés en recursos, Nivel

de interacción.

Luego de terminar de ingresar o modificar los

campos, el usuario debe hacer clic en el botón

Guardar. Si no se ingresaron todos los campos

necesarios, se presentará un mensaje indicándole a

usuario que los ingrese.

Resultado

esperado

Una vez ingresados todos los valores necesarios en

los campos y se haya hecho clic en el botón

Guardar, se mostrará una página que indicará al

usuario el nuevo tipo de recomendación o el estado

del tipo editado.

CASO DE PRUEBA


Historia de

Usuario

Borrado de datos

Descripción Este caso de prueba verifica que la funciona

correctamente las facilidades para borrar datos dentro de




76

la aplicación.

Prioridad Alta

Requisitos El usuario debe haber ingresado al sistema, y debe estar

ubicado en cualquiera de los listados (recomendaciones,

tipos de recomendaciones, categorías de

recomendaciones).

Acciones En cualquiera de los listados de datos, el usuario

puede hacer clic en los enlaces “Borrar”. Al

hacer clic en dicho enlace, se le redireccionará a

una página que le pedirá confirmación para

borrar los datos.

Resultado

esperado

Al hacer clic en el botón Sí, el usuario será

redireccionado al listado y se le presentará un

mensaje informándole que los datos han sido

borrados satisfactoriamente. Si hace clic en no,

volverá al listado.




77

7.6 Resultado de las pruebas

Se ha llevado los casos de prueba propuestos para que sean desarrollados por usuarios.

Los usuarios han expresado que las interfaces son navegables y sencillas, habiendo sólo

observaciones en cuanto a las descripciones y textos de ayuda. En esta sección se presenta, por

cada caso de prueba, la ejecución de los mismos y los resultados obtenidos.

7.6.1 Pruebas para caso de prueba CSPRB-001

Encargado de realizar la prueba:

Ing. Guido Riofrío

Caso de prueba:

CSPRB-001

Observaciones:

Ninguna novedad

Acciones: No es necesario realizar ninguna acción.


Ing. Marta Agila

Caso de prueba:

CSPRB-001

Observaciones:

Ninguna novedad




Ing. Guido Riofrío

Caso de prueba:

CSPRB-002

Observaciones:

No hay observaciones.



Ing. Marta Agila

Caso de prueba:

CSPRB-002

Observaciones:





78




Ing. Guido Riofrío

Caso de prueba:

CSPRB-003

Observaciones:




Ing. Marta Agila

Caso de prueba:

CSPRB-003

Observaciones:





Ing. Guido Riofrío

Caso de prueba:

CSPRB-004

Observaciones:




Ing. Marta Agila

Caso de prueba:

CSPRB-004

Observaciones:







79


Ing. Guido Riofrío

Caso de prueba:

CSPRB-005

Observaciones:




Ing. Marta Agila

Caso de prueba:

CSPRB-005

Observaciones:

Ha indicado que hace falta documentar más la interfaz, problema que se ha

solucionado incorporando botones de ayuda.




Ing. Guido Riofrío

Caso de prueba:

CSPRB-006

Observaciones:




Ing. Marta Agila

Caso de prueba:

CSPRB-006

Observaciones:






80

7.7 Manual de usuario

El manual de usuario es un documento que detalla la forma de uso de las funcionalidades

del sistema. Esta sección presenta dicha información, con instrucciones sencillas y gráficos de

apoyo como medio de ilustración.

7.7.1 Ingreso al sistema

El ingreso al sistema se puede realizar de varias formas:

Ingresando a la URL base del sistema, http://[Dirección_del_servidor_del_entorno

virtual]/admin-recom. Debe consultar la dirección del servidor al administrador del

entorno virtual. Acceder a esta página redireccionará a la página de inicio de sesión del

entorno virtual. Es requerido que el usuario provea un nombre de usuario y contraseña

válidos con los que ingresan al entorno virtual. El administrador del entorno virtual debe

haberle asignado al usuario el rol de administrador de recomendaciones.

Figura 7.1. Autentificación solicitada al ingresar a cualquier página de la interfaz.




81

Dentro del entorno virtual, puede accederse a la interfaz utilizando el bloque Moodle

programado para el efecto, desde la página principal del usuario.

Figura 7.2. Bloque Moodle desde el que se puede ingresar a la interfaz de administración de

recomendaciones.

Las páginas de la interfaz de administración recomendaciones pueden guardarse como

marcadores o bookmarks, puede accederse directamente a ellas si es que la sesión ha sido

iniciada, caso contrario, se redireccionará primero a la página mostrada en a).

7.7.2 Menú lateral

Contiene los enlaces a las funcionalidades de la aplicación. Contiene secciones y nombres

autodescriptivos.




82

Figura 7.3. Menú lateral de la aplicación.

7.7.3 Revisar listado de tipos de recomendaciones

Una vez dentro del sistema, hacer clic en el enlace Listado, de la sección Tipos de

recomendaciones. Allí se listan los tipos creados, y se puede seleccionar opciones para crear,

visualizar, editar y borrar recomendaciones.




83

Figura 7.4. Listado de tipos de recomendaciones existentes.

7.7.4 Crear un tipo de recomendación

Para crear un tipo de recomendación, se hace clic en el botón “Crear tipo”, ubicado en el

listado de tipos de recomendación, o bien hacer clic en el enlace “Crear tipo”, en el menú lateral.

Se abrirá una página en la que el usuario podrá crear una nueva recomendación, ingresando

valores para los campos solicitados. La interfaz indica los campos que son obligatorios, y para

campos grandes de texto, la cantidad de caracteres que se puede ingresar.

Campos para crear un tipo de recomendación

Nombre del tipo de recomendación: Indica el nombre del tipo de recomendación

que se va a crear-

Descripción del tipo: Una breve descripción del tipo de recomendación, que

puede ser de hasta 500 caracteres.

Actividad del entorno virtual: Debe seleccionarse aquí una de las diferentes

actividades disponibles para realizar en el entorno virtual. Actualmente pueden

escogerse las siguientes: Tarea, Foro, Glosario, Mensajería, Cuestionario, Recurso,

Subir archivo.




84

Categorías asociadas: Se selecciona aquí la categoría a la que se asocia el tipo de

recomendación. Estos tipos se pueden administrar desde la sección de

administración de categorías de recomendaciones.

Figura 7.5. Interfaz de creación de tipos de recomendaciones (I)

A continuación se encuentra la sección de Plantilla de recomendación. En esta sección se

coloca información para que sirva de plantilla a las recomendaciones que se creen basándose en

el tipo de recomendación que se está creando actualmente.

Título de la recomendación: Un título que describe a breves rasgos la

recomendación.

Explicación: Texto con el que se informa al estudiante las razones del por qué se

le ofrece la recomendación




85

Texto de la recomendación: Texto detallado en el que se ofrecen instrucciones y

comentarios sobre la recomendación.

Enlace: Un cuadro de texto para ingresar un enlace Web. Este enlace puede ser

probado presionando la tecla Tabulación y luego haciendo clic en el enlace

“Probar” que se encuentra junto al cuadro de texto.

Figura 7.6. Interfaz de creación de tipos de recomendaciones (II)

A continuación se encuentran las secciones de restricciones de vencimiento y condiciones.

Restricciones de vencimiento: Se debe llenar por lo menos uno de los dos campos:

o Vence en: Especificar hasta qué fecha se puede mostrar una recomendación

creada a partir el tipo actual.

o Vencer al mostrarse el siguiente número de veces: Una recomendación creada

a partir del tipo actual puede mostrarse hasta el número de veces que se

especifique aquí.




86

Condiciones: Las recomendaciones creadas a partir de este tipo de recomendación se

ofertarán a los estudiantes al coincidir los valores de sus atributos de modelo de usuario

con los valores especificados aquí. Las condiciones para las que se debe especificar

valores son Estilo de aprendizaje, Zona geográfica, Plataforma, Nivel de interés en el

curso, Nivel de interés en recursos, Nivel de Interacción.

Figura 7.7. Interfaz de creación de tipos de recomendaciones (III)

Al terminar de definir el tipo de recomendación, completando por lo menos todos los

campos obligatorios, el usuario podrá hacer clic en el botón Guardar para que el tipo creado se

guarde, o clic en el botón Cancelar para salir de la página y descartar cualquier cambio ingresado.

Si no se completa alguno de los campos obligatorios, la aplicación avisará de ello luego de hacer

clic en el botón Guardar y no permitirá que se guarden los cambios hasta que se hayan

completado dichos campos.




87

Figura 7.8. Notificación de campos obligatorios no completados.

Una vez completados los campos, se guardarán y se informará al usuario, y se mostrará el

tipo de recomendación creado.

Figura 7.9. Visualización de un tipo de recomendación al ser creado.




88

7.7.5 Editar tipo de recomendación

Para editar un tipo de recomendación, el usuario debe ubicarse en el listado de tipos de

recomendaciones y hacer clic en el enlace Editar del tipo recomendación correspondiente, o bien

hacer clic en el botón Editar en su página de visualización. A continuación de ello se le presentará

la interfaz de edición, que es idéntica a la de creación, donde tendrá que modificar los campos

que considere necesarios y hacer clic en el botón Guardar, y si desea descartar los cambios, hacer

clic en el botón Cancelar. De la misma forma, si existen campos obligatorios incompletos, se

alertará para que sean completados. Una vez terminado el proceso de edición, se informará de

que los cambios se han guardado exitosamente.

Figura 7.10. Visualización de un tipo de recomendación al ser editado.

7.7.6 Listado de categorías

Para revisar todas las categorías creadas, el usuario debe hacer clic en el enlace Listado,

de la sección Categorías de recomendaciones en el menú lateral de la aplicación. Desde este

listado, podrá revisar todos los tipos creados, así como acceder a las funcionalidades de




89

visualización, edición, creación y borrado de categorías.

Figura 7.11. Listado de categorías.

7.7.7 Crear categoría

Para crear una categoría de recomendaciones, el usuario debe hacer clic en el enlace

“Crear categoría” del menú lateral, o bien hacer clic en el botón “Crear categoría” del listado de

categorías. Se presentará una interfaz donde deberá ingresar el nombre de la categoría y su

descripción. Ambos campos son obligatorios y deberán ser completados, si faltara uno de ellos, la

aplicación informará al usuario.

Figura 7.12. Interfaz de creación de categorías




90

Una vez creado el tipo, se mostrará la categoría creada, y se informará que los datos han

sido creados con éxito.

Figura 7.13. Visualización de una categoría luego de ser creada.

7.7.8 Edición de una categoría

Para editar una categoría, se debe hacer clic en el enlace Editar de la categoría

correspondiente en el listado, o hacer clic en el botón Editar de su la página de visualización. Se

presentará una interfaz de idéntico funcionamiento a la de creación de categorías.

7.7.9 Borrado de datos

Para borrar ya sea tipos de recomendación o categorías de recomendaciones, se debe

acceder a la página de listado y hacer clic en el enlace Borrar. Se presentará una página de

confirmación de eliminación, en la cual el usuario puede confirmar que desea borrar los datos, o

cancelar la operación.




91

Figura 7.14. Acceso a la funcionalidad de borrado desde una página de listado.

Figura 7.15. Diálogo de confirmación de borrado de datos.

Si se borran los datos, se regresará a listado y se informará que los datos se han borrado

con éxito.

Figura 7.16. Notificación de borrado exitoso de datos.

7.7.10 Uso de ayuda

Los campos de los formularios de datos cuentan con un botón de ayuda. El botón de




92

ayuda consiste en un pequeño icono (círculo amarillo con un signo de interrogación). Al hacer

clic en dicho botón, aparecerá una ventana emergente (pop-up), con una descripción del campo y

sobre los valores que debería ingresar.

Figura 7.17. Uso de los botones de ayuda.




93

7.8 Manual del programador

Sistema de Administración de Recomendaciones

Generado por phpDocumentor v1.4.1 http://www.phpdoc.org

http://pear.php.net/package/PhpDocumentor

http://www.sourceforge.net/projects/phpdocu

Paquete admin-recom

admin-recom.constants.php

Paquete admin-recom

Autor: Juan Pablo Angamarca

Versión 1.0

ADVERTENCIA_REQUERIDOS_NOVALIDOS = 'Existen campos obligatorios que no han

sido completados, o

campos para los que se han ingresado valores no válidos.' [línea 67]

Mensaje para indicar que no se han completado todos los campos obligatorios.

CREATE = 'create' [línea 12]

Variable que le indica a un formulario de edición de datos que los datos que se están

editando deben guardarse como una tupla nueva.

DATOS_BORRADOS_EXITO = 'Datos borrados exitosamente.' [línea 51]

Mensaje para indicar que el borrado de datos se realizó con éxito.

DATOS_CREADOS_EXITO = 'Datos ingresados exitosamente.' [línea 55]

Mensaje para indicar que la creación de datos se realizó con éxito.

DATOS_EDITADOS_EXITO = 'Datos actualizados exitosamente.' [línea 47]

Mensaje para indicar que la edición de datos se realizó con éxito.

http://www.phpdoc.org/

http://pear.php.net/package/PhpDocumentor

http://www.sourceforge.net/projects/phpdocu




94

DEBE_SER_NUMERO = 'El valor ingresado debe ser numérico.' [línea 33]

Mensaje para indicar que el valor que se debe ingresar debe ser numérico.

EDIT = 'edit' [línea 17]

Variable que le indica a un formulario de edición de datos que los datos que se están

editando se actualizan a una tupla indicada.

ERROR_ACTUALIZAR = 'Error al actualizar los datos. Puede tratarse de un problema con la

conexión al servidor. Inténtelo más tarde o contacte al administrador.' [línea 63]

Mensaje para indicar que ocurrió un error al actualizar los datos.

ERROR_GUARDAR = 'Error al guardar los datos. Puede tratarse de un problema con la

conexión al servidor.

Inténtelo más tarde o contacte al administrador.' [línea 59]

Mensaje para indicar que ocurrió un error al guardar los datos.

ERROR_NO_DATA_FOUND = 'No se pudo completar la operación para los datos solicitados.

Es probable que no existan, que exista un fallo de conexión o que se haya hecho un pedido

incorrecto a la aplicación.' [línea 21]

Mensaje de error de datos no encontrados.

ESPECIFIQUE_CONDICIONES = 'Debe especificar por lo menos una condición para la

recomendación.' [línea 42]

Mensaje para indicar que se deben especificar condiciones para el tipo de recomendación.

ESPECIFIQUE_RESTRICCION_VENCIMIENTO = 'Debe especificar una fecha de

vencimiento o bien un número

de veces a mostrar.' [línea 38]

Mensaje para indicar que se debe especificar una restricción de vencimiento.




95

REQUERIDO = 'Campo obligatorio' [línea 25]

Mensaje para indicar un campo obligatorio.

SELECCIONEOPCION = 'Seleccionar por lo menos una opción' [línea 29]

Mensaje para indicar que se debe seleccionar por lo menos una opción.

WSDL = "{{$CFG->wwwroot}/admin-recom/webservice/server.php?wsdl" [línea 71]

Constante que indica la ubicación de la definición WSDL del servicio Web.

Clase PresentationUtils

[línea 7]

Clase que provee utilidades para presentación de elementos en las páginas.

Paquete admin-recom

Autor: Juan Pablo Angamarca G.

void function PresentationUtils::backButton() [línea 57]

Presenta un botón que permite regresar a la página anterior, de la misma forma que el

botón Back del navegador. Esta función no puede ser llamada dentro de un elemento

<form>.

void function PresentationUtils::printErrorHeader($errorText) [línea 45]

Parámetros de la función:

$errorText $errorText Texto del error.

Imprimir un mensaje de error. Se presenta un icono que consiste en un círculo rojo con una

línea horizontal blanca en el centro, y junto al icono un texto que describe la advertencia.

void function PresentationUtils::printHeader($headerText) [línea 21]


$headerText $headerText Texto de la cabecera.

Imprimir una cabecera.




96

void function PresentationUtils::printInfoMessage($infoText) [línea 68]


$infoText $infoText Texto informativo.

Imprimir un mensaje informativo. Consiste en un icono de una bombilla azul, y junto a

dicho icono, un texto informativo.

void function PresentationUtils::printWarningHeader($warningText) [línea 32]


$warningText $warningText Texto de la advertencia.

Imprimir un mensaje de advertencia. Se presenta un icono que consiste en un triángulo

amarillo con un signo de interrogación en el centro, y junto al icono, un texto que describe

la advertencia.

Clase Utils

[línea 9]

Paquete admin-recom


void function Utils::lastId($idField, $table) [línea 66]


$idField $idField Nombre del PK

$table $table Nombre de la tabla

Devolver el último id insertado en la tabla $table

string function Utils::prepareURI($uriToPrepare) [línea 83]


$uriToPrepare $uriToPrepare URI para preparar.

Preparar una URI para que tenga el prefijo http:// y el render del atributo href sea correcto

en los enlaces que se utilice.




97

void function Utils::printHelpButton($title, $text) [línea 126]


$title $title Título del botón.

$text $text Texto que va a aparecer como ayuda.

Imprimir un botón de ayuda estándar Moodle.

void function Utils::sanitizeString($string) [línea 116]


$string $string Cadena a procesar.

Procesar una cadena para que no pueda ser usada para ataques de inyección SQL.

void function Utils::setFormActionType($action, $_get, $_post, $getKey, $postKey, $_GET,

$_POST) [línea 53]


$_get $_GET

$_post $_POST

$action $action String que se debe pasar por referencia para setear la acción

$getKey $getKey Key del id de la tupla (page.php?keyid=x)

$postKey $postKey Key del id de la tupla (< input name="postKey" type="hidden"

value="< ? php echo tupla->id;? >">)

$_get

$_post

string function Utils::validateIntParamOnGET($intToValidate) [línea 99]


$intToValidate $intToValidate Parámetro a validar

Función para validar parámetros GET como enteros, de preferencia positivos. Esta función

devolverá el valor entero para cualquier valor positivo o negativo, y -1 para valores que no




98

sean números enteros válidos.

void function Utils::verifyRequiredDataForDisplayExists($tablerow, $getPostParams, $keyId,

$table, $queryField,

[$orderBy = ''], $_GET) [línea 26]


$getPostParams $_GET o $_POST, sea cual tenga el id de los datos buscados.

$tablerow $tablerow Fila de datos que debe pasarse por referencia. Si los dato con id

$keyId

existe en la tabla $table, se almacenarán en esta variable.

$keyId $keyId key de $getPostParams en donde está el id solicitado.

$table $table Tabla en la que se buscan los datos

$queryField $queryField Nombre del campo id de la tabla

$orderBy $orderBy Ordenar $tablerow de acuerdo a este parámetro.

$getPostParams

Verificar que los datos que se van a mostrar existan. Si no existen para

mostrar/editar/borrar la ejecución del script actual se detiene con una llamada al método

exit().

Paquete admin-recom.blckadminrecom

Clase block_blckadminrecom

[línea 8]

Bloque que facilita el ingreso a la interfaz de administración de recomendaciones desde

Moodle.

Paquete admin-recom.blckadminrecom


array function block_blckadminrecom::aplicable_formats() [línea 65]

Función que devuelve los formatos aplicables al bloque.




99

string function block_blckadminrecom::get_content() [línea 23]

Función que define el contenido del bloque. Incluye procesos de autenticación.

void function block_blckadminrecom::init() [línea 13]

Función de inicialización del bloque Moodle.

boolean function block_blckadminrecom::instance_allow_config() [línea 57]

Establecer si el bloque puede ser configurado o no.

boolean function block_blckadminrecom::instance_allow_multiple() [línea 49]

Establecer si pueden o no existir múltiples instancias del bloque.

Clase DataUtils

[línea 14]

Paquete admin-recom.classesdb


boolean function DataUtils::autoCommitFalse() [línea 232]

MySQL SET AUTOCOMMIT = 0

boolean function DataUtils::beginTransaction() [línea 241]

MySQL START TRANSACTION WITH CONSISTENT SNAPSHOT Las tablas deben

tener motor InnoDB.

boolean function DataUtils::commit() [línea 249]

SQL COMMIT

void function DataUtils::delete($tablename, $pkname, $idDelete, $rowsDeleted) [línea 211]





100

$tablename $tablename Nombre de la tabla (debe pasarse completo, con el prefijo

incluido)

$pkname $pkname Nombre del campo pk

$idDelete $idDelete id de la tupla a borrar

$rowsDeleted $rowsDeleted Pasar por referencia para obtener el número de filas borradas

[referirse a la documentación de la función mysql_affected_rows para ver las

particularidades

de este valor de retorno]. Pasar NULL si no se necesita ese valor.

Borrar una tupla de una tabla de la base de datos.

mixed function DataUtils::getCondicion($recid, $codigoAtributo) [línea 268]


$recid $recid Id de la recomendación

$codigoAtributo $codigoAtributo Código del atributo del modelo de usuario.

Obtener una condición de una recomendación.

mixed function DataUtils::getCondicionTipoRec($trecid, $codigoAtributo) [línea 284]


$trecid $trecid Id del tipo de recomendación

$codigoAtributo $codigoAtributo Código del atributo del modelo de usuario.

Obtener una condición de un tipo de recomendación.

void function DataUtils::insert($entity, $fulltablename, [$idinserted = null]) [línea 67]


$entity $entity Objeto de datos. La clave primaria debe ser siempre el primer campo del

objeto.

Sus campos deben tener exactamente los mismos nombres, case y número que columnas

que

la tabla de la base de datos




101

$tablename $fulltablename Nombre de la tabla (debe pasarse completo, con el prefijo

incluido)

$idinserted $idinserted Pasar por referencia si se necesita conocer el último id insertado,

pasar null si no se lo necesita.

Insertar una nueva tupla en una tabla en la base de datos.

boolean function DataUtils::rollback() [línea 257]

SQL ROLLBACK

void function DataUtils::sqlIUString($field) [línea 30]


$field $field

SQL INSERT o UPDATE

void function DataUtils::update($entity, $tablename, $rowsAffected) [línea 110]


$entity $entity Objeto de datos. La clave primaria debe ser siempre el primer campo del

objeto.

Sus campos deben tener exactamente los mismos nombres, case y número que columnas

que

la tabla de la base de datos

$tablename $tablename Nombre de la tabla (debe pasarse completo, con el prefijo

incluido)

$rowsAffected $rowsAffected Pasar por referencia para saber el número de columnas

modificadas: el valor de que devuelve la función mysql_affected_rows() [referirse a la

documentación de esta función para ver las particularidades de este valor de retorno].

Pasar NULL si no se necesita ese valor.

Actualizar una tupla de una tabla en la base de datos.




102

boolean function DataUtils::updateFields($entity, $tablename, $fieldlist, $rowsAffected) [línea

161]


$dataobject $entity Objeto de datos. La clave primaria debe ser siempre el primer campo

del objeto. Sus campos deben tener exactamente los mismos nombres, case y número que

columnas que la tabla de la base de datos

$tableName $tablename Nombre completo de la tabla

$fieldlist $fieldlist Lista de campos, separados por comas

$rowsaffected $rowsAffected Pasar por referencia si se necesita, caso contrario pasar

null, condiciones de retorno son las de mysql_affected_rows

Actualizar ciertos campos de una tupla de una tabla en la base de datos.

Paquete admin-recom.webservice

server.php

Definición de las operaciones del servicio Web.

Paquete admin-recom.webservice


string function GetCategoria($catid) [línea 122]


$catid $catid Id de la categoría.

Operación del servicio Web que devuelve una categoría

de recomendaciones.

string function GetCategorias() [línea 139]

Operación del servicio Web que devuelve todas las categorías

existentes dentro de la base de datos del sistema recomendador.

string function GetCategoriasAsociadasATipoRecomendacion($trecid) [línea 91]





103

$trecid $trecid Id del tipo de recomendación.

Operación del servicio Web que devuelve las categorías asociadas a un tipo de

recomendación.

string function GetCondicionDeTipoRec($trecid, $codigoAtributo) [línea 163]



$codigoAtributo $codigoAtributo Código correspondiente al atributo de modelo de usuario.

Obtener una condición de un tipo de recomendación.

string function GetRestricVencDeTipoRecomendacion($trecid) [línea 73]



Operación del servicio Web que devuelve la tupla de restricciones de vencimiento de

un tipo de recomendación.

string function GetTipoRecomendacion($trecid) [línea 55]



Operación del servicio Web que devuelve un tipo de recomendación.

string function GetTiposRecomendacion() [línea 32]

Operación del servicio Web que devuelve los tipos de recomendación existentes en la base

de datos del sistema recomendador.

string function GetValoresEstereotiposAtribModeloUsuario($atributo) [línea 186]


$atributo $atributo Nombre del atributo

Operación del servicio Web que recupera los estereotipos de valores para los atributos del

modelo de usuario.




104

7.9 Definición WSDL del servicio Web implementado

WSDL es el lenguaje de descripción de servicios Web basados en SOAP, por lo que para

el consumo de dichos servicios es imprescindible contar con la definición WSDL de los mismos.

A continuación se presenta dicha definición para el servicio creado para su consumo por parte de

la interfaz de administración de recomendaciones y de otras aplicaciones.

<definitions

targetNamespace="http://localhost/eva19/admin-

recom/webservice/adrecwebservice">

<types>

<xsd:schema

targetNamespace="http://localhost/eva19/admin-

recom/webservice/adrecwebservice">

<xsd:import

namespace="http://schemas.xmlsoap.org/soap/encoding/" />

<xsd:import namespace="http://schemas.xmlsoap.org/wsdl/" />

</xsd:schema>

</types>

<message name="GetTiposRecomendacionRequest" />

<message name="GetTiposRecomendacionResponse">

<part name="return" type="xsd:string" />

</message>

<message name="GetTipoRecomendacionRequest">

<part name="trecid" type="xsd:string" />

</message>

<message name="GetTipoRecomendacionResponse">


</message>

<message name="GetRestricVencDeTipoRecomendacionRequest">


</message>

<message name="GetRestricVencDeTipoRecomendacionResponse">


</message>

<message name="GetCategoriasAsociadasATipoRecomendacionRequest">


</message>

<message name="GetCategoriasAsociadasATipoRecomendacionResponse">


</message>

<message name="GetCategoriaRequest">

<part name="catid" type="xsd:string" />

</message>

<message name="GetCategoriaResponse">


</message>

<message name="GetCategoriasRequest" />

<message name="GetCategoriasResponse">


</message>




105

<message name="GetCondicionDeTipoRecRequest">


<part name="$codigoAtributo" type="xsd:string" />

</message>

<message name="GetCondicionDeTipoRecResponse">


</message>

<message name="GetValoresEstereotiposAtribModeloUsuarioRequest">

<part name="atributo" type="xsd:string" />

</message>

<message name="GetValoresEstereotiposAtribModeloUsuarioResponse">


</message>

<portType name="AdminRecomWebServicePortType">

<operation name="GetTiposRecomendacion">

<input message="tns:GetTiposRecomendacionRequest" />

<output message="tns:GetTiposRecomendacionResponse" />

</operation>

<operation name="GetTipoRecomendacion">

<input message="tns:GetTipoRecomendacionRequest" />

<output message="tns:GetTipoRecomendacionResponse" />

</operation>

<operation name="GetRestricVencDeTipoRecomendacion">

<input

message="tns:GetRestricVencDeTipoRecomendacionRequest" />

<output

message="tns:GetRestricVencDeTipoRecomendacionResponse" />

</operation>

<operation name="GetCategoriasAsociadasATipoRecomendacion">

<input

message="tns:GetCategoriasAsociadasATipoRecomendacionRequest" />

<output

message="tns:GetCategoriasAsociadasATipoRecomendacionResponse" />

</operation>

<operation name="GetCategoria">

<input message="tns:GetCategoriaRequest" />

<output message="tns:GetCategoriaResponse" />

</operation>

<operation name="GetCategorias">

<input message="tns:GetCategoriasRequest" />

<output message="tns:GetCategoriasResponse" />

</operation>

<operation name="GetCondicionDeTipoRec">

<input message="tns:GetCondicionDeTipoRecRequest" />

<output message="tns:GetCondicionDeTipoRecResponse" />

</operation>

<operation name="GetValoresEstereotiposAtribModeloUsuario">

<input

message="tns:GetValoresEstereotiposAtribModeloUsuarioRequest" />

<output

message="tns:GetValoresEstereotiposAtribModeloUsuarioResponse" />

</operation>

</portType>

<binding name="AdminRecomWebServiceBinding"

type="tns:AdminRecomWebServicePortType">

<soap:binding style="rpc"




106

transport="http://schemas.xmlsoap.org/soap/http" />

<operation name="GetTiposRecomendacion">

<soap:operation

soapAction="http://localhost/eva19/admin-

recom/webservice/server.php/GetTiposRecomendacion"

style="rpc" />

<input>

<soap:body use="encoded"

namespace="http://localhost/eva19/admin-

recom/webservice/adrecwebservice"

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />

</input>

<output>





</output>

</operation>

<operation name="GetTipoRecomendacion">

<soap:operation


recom/webservice/server.php/GetTipoRecomendacion"

style="rpc" />

<input>





</input>

<output>





</output>

</operation>

<operation name="GetRestricVencDeTipoRecomendacion">

<soap:operation


recom/webservice/server.php/GetRestricVencDeTipoRecomendacion"

style="rpc" />

<input>





</input>

<output>





107




</output>

</operation>

<operation name="GetCategoriasAsociadasATipoRecomendacion">

<soap:operation


recom/webservice/server.php/GetCategoriasAsociadasATipoRecomendacion"

style="rpc" />

<input>





</input>

<output>





</output>

</operation>

<operation name="GetCategoria">

<soap:operation


recom/webservice/server.php/GetCategoria"

style="rpc" />

<input>





</input>

<output>





</output>

</operation>

<operation name="GetCategorias">

<soap:operation


recom/webservice/server.php/GetCategorias"

style="rpc" />

<input>







108


</input>

<output>





</output>

</operation>

<operation name="GetCondicionDeTipoRec">

<soap:operation


recom/webservice/server.php/GetCondicionDeTipoRec"

style="rpc" />

<input>





</input>

<output>





</output>

</operation>

<operation name="GetValoresEstereotiposAtribModeloUsuario">

<soap:operation


recom/webservice/server.php/GetValoresEstereotiposAtribModeloUsuario"

style="rpc" />

<input>





</input>

<output>





</output>

</operation>

</binding>

<service name="AdminRecomWebService">

<port name="AdminRecomWebServicePort"

binding="tns:AdminRecomWebServiceBinding">

<soap:address




109

location="http://localhost/eva19/admin-

recom/webservice/server.php" />

</port>

</service>

</definitions>




110

7.10 Implementación del servicio Web

En este anexo se presenta la implementación del servicio Web en el lenguaje PHP,

haciendo uso de la librería de servicios Web NuSOAP.

<?php

require ('../utils.php');

require_once ("lib/nusoap.php");

require_once('../../config.php');

require_once('../../lib/dmllib.php');

$ns = "$CFG->wwwroot/admin-recom/webservice/adrecwebservice";

$server = new soap_server ();

$server->configureWSDL ( 'AdminRecomWebService', $ns );

$server->wsdl->schemaTargetNamespace = $ns;

$server->register ( 'GetTiposRecomendacion', array (), array ('return' =>

'xsd:string' ), $ns );

$server->register ( 'GetTipoRecomendacion', array ('trecid' => 'xsd:string' ),

array ('return' => 'xsd:string' ), $ns );

$server->register ( 'GetRestricVencDeTipoRecomendacion', array ('trecid' =>

'xsd:string' ), array ('return' => 'xsd:string' ), $ns );

$server->register ( 'GetCategoriasAsociadasATipoRecomendacion', array

('trecid' => 'xsd:string' ), array ('return' => 'xsd:string' ), $ns );

$server->register ( 'GetCategoria', array ('catid' => 'xsd:string' ), array

('return' => 'xsd:string' ), $ns );

$server->register ( 'GetCategorias', array (), array ('return' => 'xsd:string'

), $ns );

$server->register ( 'GetCondicionDeTipoRec', array ('trecid' => 'xsd:string',

'$codigoAtributo' => 'xsd:string' ), array ('return' => 'xsd:string' ), $ns );

$server->register ( 'GetValoresEstereotiposAtribModeloUsuario', array

('atributo' => 'xsd:string' ), array ('return' => 'xsd:string' ), $ns );

function GetTiposRecomendacion() {

$queryTiposRecomendaciones = get_records ( 'sr_tipo_recomendacion', '',

'', 'trc_nombre_tipo_rec' );

$xmlreturn = '<?xml version="1.0" encoding="utf-8"?><tipos-

recomendacion>';

foreach ( $queryTiposRecomendaciones as $idTipoRec => $filaTipoRec ) {

$xmlreturn = $xmlreturn . '<tipo-recomendacion>';

foreach ( $filaTipoRec as $arraykey => $arrayvalue ) {

$xmlreturn = $xmlreturn .

"<$arraykey>$arrayvalue</$arraykey>";

}

$xmlreturn = $xmlreturn . '</tipo-recomendacion>';

}




111

$xmlreturn = $xmlreturn . '</tipos-recomendacion>';

return new soapval ( 'return', 'xsd:string', $xmlreturn );

}

function GetTipoRecomendacion($trecid) {

$tiporec = get_record ( 'sr_tipo_recomendacion', 'trc_id', $trecid );

$xmlreturn = '<?xml version="1.0" encoding="utf-8"?><tipo-

recomendacion>';

foreach ($tiporec as $fieldname => $fieldvalue) {

$xmlreturn = $xmlreturn . "<$fieldname>$fieldvalue</$fieldname>";

}

$xmlreturn = $xmlreturn . '</tipo-recomendacion>';


}

function GetRestricVencDeTipoRecomendacion($trecid) {

$rvenc = get_record ( 'sr_restricciones_vencimiento', 'trc_id', $trecid

);

$xmlreturn = '<?xml version="1.0" encoding="utf-8"?><restriccion-

vencimiento>';

foreach ($rvenc as $fieldname => $fieldvalue) {


}

$xmlreturn = $xmlreturn . '</restriccion-vencimiento>';


}

function GetCategoriasAsociadasATipoRecomendacion($trecid) {

$utils = new Utils ();

$xmlreturn = '<?xml version="1.0" encoding="utf-8"?><categorias>';

if (($utils->validateIntParamOnGET ( $trecid )) != - 1) {

$sql = "SELECT cat.cat_id, cat.cat_nombre_categoria FROM

(mdl_sr_categoria cat

INNER JOIN mdl_sr_categ_tipo_rec ctr ON (cat.cat_id =

ctr.cat_id))

INNER JOIN mdl_sr_tipo_recomendacion trec ON (trec.trc_id =

ctr.trc_id)

WHERE (ctr.trc_id = {$trecid}) ORDER BY

cat.cat_nombre_categoria";

$queryCtgs = get_records_sql ( $sql );

foreach ( $queryCtgs as $idCat => $filaCat ) {

$xmlreturn = $xmlreturn . '<categoria>';

foreach ($filaCat as $fieldname => $fieldvalue) {


"<$fieldname>$fieldvalue</$fieldname>";

}

$xmlreturn = $xmlreturn . '</categoria>';




112

}

}

$xmlreturn = $xmlreturn . '</categorias>';


}

function GetCategoria($catid) {

$categoria = get_record ( 'sr_categoria', 'cat_id', $catid );

$xmlreturn = '<?xml version="1.0" encoding="utf-8"?><categoria>';

foreach ( $categoria as $fieldname => $fieldvalue ) {


}



}

function GetCategorias() {

$queryCategorias = get_records ( 'sr_categoria', '', '',

'cat_nombre_categoria' );

$xmlreturn = '<?xml version="1.0" encoding="utf-8"?><categorias>';

foreach ( $queryCategorias as $idCat => $filaCat ) {

$xmlreturn = $xmlreturn . '<categoria>';

foreach ( $filaCat as $fieldname => $fieldvalue ) {



}


}

$xmlreturn = $xmlreturn . '</categorias>';


}

function GetCondicionDeTipoRec($trecid, $codigoAtributo) {

$xmlreturn = '<?xml version="1.0" encoding="utf-8"?><condicion>';

$sql = "SELECT srcon.*

FROM mdl_sr_condiciones srcon INNER JOIN

mdl_mu_atributos_modelo_usuario amu

ON (srcon.amu_id_atributo_modelo_usuario =

amu.amu_id_atributo_modelo_usuario)

WHERE (srcon.trc_id = $trecid) AND (amu.amu_codigo =

'$codigoAtributo')";

$condicion = get_record_sql ( $sql );

foreach ($condicion as $fieldname => $fieldvalue) {


}

$xmlreturn = $xmlreturn . '</condicion>';




113


}

function GetValoresEstereotiposAtribModeloUsuario($atributo) {

$records = get_records('mu_valores_estereotipos', 'ves_atributo_mu',

$atributo);

$xmlreturn = '<?xml version="1.0" encoding="utf-8"?><estereotipos>';

foreach ($records as $idxrow => $row) {

$xmlreturn = $xmlreturn . '<estereotipo>';

foreach ($row as $fieldname => $fieldvalue) {



}

$xmlreturn = $xmlreturn . '</estereotipo>';

}

$xmlreturn = $xmlreturn . '</estereotipos>';


}

$server->service ( $HTTP_RAW_POST_DATA );

?>




114

7.11 Bloque Moodle

Código fuente del bloque desarrollado que provee integración de la interfaz de

administración de recomendaciones con el Entorno Virtual de Aprendizaje.

<?php

class block_blckadminrecom extends block_base {

function init() {

$this->title = 'Administración de recomendaciones';

$this->version = 2010082800;

}

function get_content() {

global $CFG, $COURSE, $USER;

if ($this->content != NULL) {

return $this->content;

}

$this->content = new StdClass ();

if (record_exists ( 'role_assignments', 'roleid', 24, 'userid',

$USER->id )) {

$this->content = '';

$this->content->text = '<a style="font-size:10pt" href="' .

$CFG->wwwroot . '/admin-recom/" target="_blank">Administración de

recomendaciones</a>';

}

return $this->content;

}

function instance_allow_multiple() {

return true;

}

function instance_allow_config() {

return false;

}

function aplicable_formats () {

return array ('all' => true, 'course-view' => true, 'mod' => true,

'my' => true);

}

}

?>




115

7.12 Código fuente (vistas principales)

Esta sección contiene el código fuente de las principales vistas desarrolladas dentro de la

aplicación, las cuales consisten en código PHP, HTML y Javascript.

7.12.1 edit-type-rec.php

Archivo de código fuente que contiene el código para editar tipos de recomendación.

<?php

// Variables, requires y sets

require ('./require-login.php');

require ('./utils.php');

require ('./classesdb/data-utils.php');

require ('./presentation-utils.php');

require ('./webservice/lib/nusoap.php');

global $CFG, $MOODLE_MODULES, $ESCALA, $ESTILOS_APRENDIZAJE, $INFO_TABLES;

$utils = new Utils ();

// Setear la acción actual

$action = '';

$utils->setFormActionType ( &$action, $_GET, $_POST, "trecid", "txtTrecId" );

// Variables de validación

$noNombreTipo = false;

$noTextoRecomendacion = false;

$noTitulo = false;

$noCategorias = false;

$noRestriccionVencimiento = false;

$vecesNoEsUnNumero = false;

$fechaNoValida = false;

// Variables de datos

$tRecEditActual = new TipoRecomendacion ();

$rVenc = new RestriccionVencimiento ();

$condEstApr = new Condicion ();

$condIntCur = new Condicion ();

$condIntRec = new Condicion ();

$condNivInt = new Condicion ();

$condZonGeo = new Condicion ();

$condEntUsu = new Condicion ();

$fechaExpiracionArray = array ();

$categoriasAsociadas = array ();

// Variables utilitarias




116

$showErrorSave = false;

$showWarningIncompleteOrNotValidData = false;

$dataUtils = new DataUtils ();

$presUtils = new PresentationUtils ();

if ($_SERVER ["REQUEST_METHOD"] == "POST") {

if (array_key_exists ( "cancelar", $_POST )) {

header ( 'Location: list-type-rec.php' );

exit ();

} else {

// En autopost cargar los valores en el form

$tRecEditActual->trc_id = intval ( $_POST ["txtTrecId"] );

$tRecEditActual->rec_enlace = substr ( $utils->sanitizeString (

$_POST ["enlaceWeb"] ), 0, 500 );

if ($tRecEditActual->rec_enlace != '') {

$tRecEditActual->rec_enlace = $utils->prepareURI (

$tRecEditActual->rec_enlace );

}

$tRecEditActual->rec_explicacion = substr ( $utils->sanitizeString

( $_POST ["explicacionRec"] ), 0, 500 );

$tRecEditActual->trc_fecha_creacion = $_POST ["fechaCreacion"];

$tRecEditActual->rec_texto = substr ( $utils->sanitizeString (

$_POST ["textoRec"] ), 0, 500 );

$tRecEditActual->rec_titulo = substr ( $utils->sanitizeString (

$_POST ["tituloRec"] ), 0, 100 );

$tRecEditActual->tec_id = 1;

$tRecEditActual->trc_descripcion_tipo_rec = substr ( $utils-

>sanitizeString ( $_POST ["descTipo"] ), 0, 500 );

$tRecEditActual->trc_nombre_tipo_rec = substr ( $utils-

>sanitizeString ( $_POST ["nombreTipo"] ), 0, 100 );

$tRecEditActual->trc_tipo_recurso = $_POST ["moduloMoodle"];

$rVenc->rvc_id = intval ( $_POST ["txtRvcId"] );

$rVenc->rvc_fecha_expiracion = $_POST ["fechaVencimiento"];

$rVenc->rvc_veces_a_mostrar = $_POST ["venceEnNVeces"];

$rVenc->trc_id = intval ( $_POST ["txtTrecId"] );

$condEstApr->con_valor_condicion = $_POST ['estiloAprendizaje'];

$condEstApr->con_id = $_POST ['idCondEstApr'];

$condIntCur->con_valor_condicion = $_POST ['nivelInteresCurso'];

$condIntCur->con_id = $_POST ['idCondIntCur'];

$condIntRec->con_valor_condicion = $_POST

['nivelInteresRecursos'];

$condIntRec->con_id = $_POST ['idCondIntRec'];

$condNivInt->con_valor_condicion = $_POST ['nivelInteraccion'];

$condNivInt->con_id = $_POST ['idCondNivInt'];

$condZonGeo->con_valor_condicion = $_POST ['zonGeografica'];

$condZonGeo->con_id = $_POST ['idCondZonGeo'];

$condEntUsu->con_valor_condicion = $_POST ['entUsuario'];

$condEntUsu->con_id = $_POST ['idCondEntUsu'];

foreach ( $_POST ["catsAsociadas"] as $key => $value ) {

$categoriasAsociadas [$value] = $value;




117

}

// Verificar los campos requeridos, validación de datos

$noNombreTipo = (empty ( $tRecEditActual->trc_nombre_tipo_rec )) ?

true : false;

$noCategorias = (count ( $_POST ['catsAsociadas'] ) < 1) ? true :

false;

$noTextoRecomendacion = (empty ( $tRecEditActual->rec_texto )) ?

true : false;

$noTitulo = (empty ( $tRecEditActual->rec_titulo )) ? true :

false;

$fechaExpiracionArray = explode ( "-", $rVenc-

>rvc_fecha_expiracion );

$fechaNoValida = ((( int ) $fechaExpiracionArray [0]) == 0) || (((

int ) $fechaExpiracionArray [1]) == 0) || ((( int ) $fechaExpiracionArray [2])

== 0);

$vecesNoEsUnNumero = ((( int ) $rVenc->rvc_veces_a_mostrar) == 0)

? true : false;

$noRestriccionVencimiento = $fechaNoValida && $vecesNoEsUnNumero;

if (! $noNombreTipo && ! $noCategorias && ! $noTitulo && !

$noTextoRecomendacion && ! $noRestriccionVencimiento) {

if ($fechaNoValida) {

$rVenc->rvc_fecha_expiracion = NULL;

}

// Todos los requeridos están completos y los valores son

válidos, guardar.

if ($action == EDIT) {

//Al editar, comprobación de preexistencia de

condiciones

$condEstAprPresente = ( bool ) $_POST

["condEstAprPresente"];

$condIntCurPresente = ( bool ) $_POST

["condIntCurPresente"];

$condIntRecPresente = ( bool ) $_POST

["condIntRecPresente"];

$condNivIntPresente = ( bool ) $_POST

["condNivIntPresente"];

$condZonGeoPresente = ( bool ) $_POST

["condZonGeoPresente"];

$condEntUsuPresente = ( bool ) $_POST

["condEntUsuPresente"];

$noRollback = true;

$noRollback = $noRollback && ( bool ) ($dataUtils-

>beginTransaction ());


>autoCommitFalse ());

// Actualizar tipo de recomendación




118


>update ( $tRecEditActual, 'mdl_' . $INFO_TABLES ["trecid"] ["table"], NULL

));

// Actualizar restricciones de vencimiento


>update ( $rVenc, 'mdl_' . $INFO_TABLES ["rvid"] ["table"], NULL ));

// Actualizar condiciones

function updateCondicion($condicionPresente,

$condicion, $codigoAtributoModeloUsuario, $trcId, $noRollback) {


if (! $condicionPresente && (strval (

$condicion->con_valor_condicion ) != '0')) {

$condicion->trc_id = $trcId;

$queryAtribModUs = get_record (

'mu_atributos_modelo_usuario', 'amu_codigo', $codigoAtributoModeloUsuario );

if ((( bool ) $queryAtribModUs) == false)

{

$noRollback = false;

}

$condicion->amu_id_atributo_modelo_usuario

= intval ( $queryAtribModUs->amu_id_atributo_modelo_usuario );

$noRollback = $noRollback && ( bool )

($dataUtils->insert ( $condicion, 'mdl_sr_condiciones', NULL ));

} else if ($condicionPresente && (strval (

$condicion->con_valor_condicion ) == '0')) {


($dataUtils->delete ( 'mdl_sr_condiciones', 'con_id', $condicion->con_id, NULL

));

} else if ($condicionPresente && (strval (

$condicion->con_valor_condicion ) != '0')) {


($dataUtils->updateFields ( $condicion, 'mdl_sr_condiciones',

'con_valor_condicion', NULL ));

}

}

updateCondicion ( $condEntUsuPresente, $condEntUsu,

'ENT_USU', $tRecEditActual->trc_id, &$noRollback );

updateCondicion ( $condEstAprPresente, $condEstApr,

'EST_APR', $tRecEditActual->trc_id, &$noRollback );

updateCondicion ( $condIntCurPresente, $condIntCur,

'INT_CUR', $tRecEditActual->trc_id, &$noRollback );

updateCondicion ( $condIntRecPresente, $condIntRec,

'INT_REC', $tRecEditActual->trc_id, &$noRollback );

updateCondicion ( $condNivIntPresente, $condNivInt,

'NIV_INT', $tRecEditActual->trc_id, &$noRollback );

updateCondicion ( $condZonGeoPresente, $condZonGeo,

'ZON_GEO', $tRecEditActual->trc_id, &$noRollback );




119

$queryCatsActuales = get_records (

'sr_categ_tipo_rec', 'trc_id', $tRecEditActual->trc_id );

$catsActuales = array ();

foreach ( $queryCatsActuales as $ctrid => $row ) {

$catsActuales [$ctrid] = $row->cat_id;

}

// Buscar en el array de categorías asociadas que se

han editado. Si alguna

// de ellas no está en las categorías originales,

agregarla.

foreach ( $categoriasAsociadas as $key => $catId ) {

if (! array_search ( $catId, $catsActuales )) {

$catTipo = new CategTipoRec ();

$catTipo->cat_id = $catId;

$catTipo->trc_id = $tRecEditActual-

>trc_id;

$noRollback = $noRollback && (( bool )

$dataUtils->insert ( $catTipo, 'mdl_sr_categ_tipo_rec', NULL ));

}

}

// Buscar en el array de categorías originales. Si

alguna de ellas no está

// en las categorías editadas, borrarla.

foreach ( $catsActuales as $ctrid => $catId ) {

if (! array_search ( $catId,

$categoriasAsociadas )) {

$noRollback = $noRollback && (( bool )

$dataUtils->delete ( 'mdl_sr_categ_tipo_rec', 'ctr_id', $ctrid, NULL ));

}

}

if ($noRollback == false) {

$dataUtils->rollback ();

$showErrorSave = true;

} else {

if ($dataUtils->commit () == false) {


} else {

header ( "Location: view-type-

rec.php?trecid=$tRecEditActual->trc_id&edited=y" );

exit ();

}

}

} else if ($action == CREATE) {

$noRollback = true;

$noRollback = $noRollback && ($dataUtils-

>beginTransaction ());

$noRollback = $noRollback && ($dataUtils-

>autoCommitFalse ());

$newTrcId = 0;

// Insert tipo de recomendación




120

$noRollback = $noRollback && ($dataUtils->insert (

$tRecEditActual, 'mdl_' . $INFO_TABLES ["trecid"] ["table"], &$newTrcId ));

// Insert restricciones de vencimiento

if (empty ( $rVenc->rvc_veces_a_mostrar )) {

$rVenc->rvc_veces_a_mostrar = NULL;

}

if (empty ( $rVenc->rvc_fecha_expiracion )) {

$rVenc->rvc_fecha_expiracion = NULL;

}

$rVenc->trc_id = $newTrcId;

$noRollback = $noRollback && ($dataUtils->insert (

$rVenc, 'mdl_' . $INFO_TABLES ["rvid"] ["table"], NULL ));

// Insertar asociaciones tipo-categoría

foreach ( $categoriasAsociadas as $key => $idCat ) {

$catTipoRec = new CategTipoRec ();

$catTipoRec->cat_id = $idCat;

$catTipoRec->trc_id = $newTrcId;

$noRollback = $noRollback && ($dataUtils->insert

( $catTipoRec, 'mdl_sr_categ_tipo_rec', NULL ));

}

// Insertar condiciones

function insertarCondicionTipoRec($condicion,

$codigoAtributoModeloUsuario, $trcId, $noRollback) {

if (strval ( $condicion->con_valor_condicion )

!= '0') {

$condicion->trc_id = $trcId;

$queryAtribModUs = get_record (

'mu_atributos_modelo_usuario', 'amu_codigo', $codigoAtributoModeloUsuario );

if ($queryAtribModUs == false) {

$noRollback = false;

return;

}


$condicion->amu_id_atributo_modelo_usuario

= intval ( $queryAtribModUs->amu_id_atributo_modelo_usuario );


($dataUtils->insert ( $condicion, 'mdl_sr_condiciones', NULL ));

}

}

insertarCondicionTipoRec ( $condEntUsu, 'ENT_USU',

$newTrcId, &$noRollback );

insertarCondicionTipoRec ( $condEstApr, 'EST_APR',


insertarCondicionTipoRec ( $condIntCur, 'INT_CUR',


insertarCondicionTipoRec ( $condIntRec, 'INT_REC',





121

insertarCondicionTipoRec ( $condNivInt, 'NIV_INT',


insertarCondicionTipoRec ( $condZonGeo, 'ZON_GEO',


if ($noRollback == false) {

$dataUtils->rollback ();


} else {

if ($dataUtils->commit () == false) {


} else {

header ( "Location: view-type-

rec.php?trecid=$newTrcId&created=y" );

exit ();

}

}

}

} else {

$showWarningIncompleteOrNotValidData = true;

}

}

}

if ($_SERVER ["REQUEST_METHOD"] == "GET") {

if (isset ( $_GET ["trecid"] ) && (($utils->validateIntParamOnGET (

$_GET ["trecid"] )) != - 1)) {

$id = $_GET ["trecid"];

// Cargar datos para edición.

// Cargar tipo de recomendación

$queryTrec = get_record ( 'sr_tipo_recomendacion', 'trc_id', $id

);

$tRecEditActual->rec_enlace = $queryTrec->rec_enlace;

$tRecEditActual->rec_explicacion = $queryTrec->rec_explicacion;

$tRecEditActual->trc_fecha_creacion = $queryTrec-

>trc_fecha_creacion;

$tRecEditActual->rec_texto = $queryTrec->rec_texto;

$tRecEditActual->rec_titulo = $queryTrec->rec_titulo;

$tRecEditActual->tec_id = $queryTrec->tec_id;

$tRecEditActual->trc_descripcion_tipo_rec = $queryTrec-

>trc_descripcion_tipo_rec;

$tRecEditActual->trc_id = $queryTrec->trc_id;

$tRecEditActual->trc_nombre_tipo_rec = $queryTrec-

>trc_nombre_tipo_rec;

$tRecEditActual->trc_tipo_recurso = $queryTrec->trc_tipo_recurso;

// Cargar restricciones de vencimiento

$queryRVenc = get_record ( 'sr_restricciones_vencimiento',

'trc_id', $tRecEditActual->trc_id );

$rVenc->rec_id = NULL;

$rVenc->rvc_fecha_expiracion = $queryRVenc->rvc_fecha_expiracion;

$rVenc->rvc_id = $queryRVenc->rvc_id;

$rVenc->rvc_veces_a_mostrar = $queryRVenc->rvc_veces_a_mostrar;

$rVenc->trc_id = $queryRVenc->trc_id;




122

$fechaExpiracionArray = explode ( '-', $rVenc-

>rvc_fecha_expiracion );

// Cargar condiciones

$condEstApr = $dataUtils->getCondicionTipoRec ( $tRecEditActual-

>trc_id, 'EST_APR' );

$condEstAprPresente = ( bool ) $condEstApr;

$condIntCur = $dataUtils->getCondicionTipoRec ( $tRecEditActual-

>trc_id, 'INT_CUR' );

$condIntCurPresente = ( bool ) $condIntCur;

$condIntRec = $dataUtils->getCondicionTipoRec ( $tRecEditActual-

>trc_id, 'INT_REC' );

$condIntRecPresente = ( bool ) $condIntRec;

$condNivInt = $dataUtils->getCondicionTipoRec ( $tRecEditActual-

>trc_id, 'NIV_INT' );

$condNivIntPresente = ( bool ) $condNivInt;

$condZonGeo = $dataUtils->getCondicionTipoRec ( $tRecEditActual-

>trc_id, 'ZON_GEO' );

$condZonGeoPresente = ( bool ) $condZonGeo;

$condEntUsu = $dataUtils->getCondicionTipoRec ( $tRecEditActual-

>trc_id, 'ENT_USU' );

$condEntUsuPresente = ( bool ) $condEntUsu;

$sql = "SELECT cat_id from mdl_sr_categ_tipo_rec where trc_id =

$tRecEditActual->trc_id";

$queryCtgs = get_records_sql ( $sql );

foreach ( $queryCtgs as $key => $idCatRow ) {

$categoriasAsociadas [$idCatRow->cat_id] = $idCatRow-

>cat_id; //cat_nombre_categoria;

}

}

}

?>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<link rel=StyleSheet href="./css/styles.css" type="text/css" />

<script language="javascript" src="./js/utils.js"

type="text/javascript"></script>

<title> <?php


echo 'Editar tipo de recomendación';

} else {

echo 'Crear tipo de recomendación';

}

?> </title>

</head>

<body>

<?php

include ('header.php')?>




123

<table width="100%" cellpadding="10">

<tbody class="tbody-content">

<tr>

<td width="20%"><?php

include ('left.php');

?></td>

<td width="80%">

<?php

//// Cuerpo de la página.

if ($showErrorSave) {

$presUtils->printErrorHeader ( ERROR_GUARDAR );

}

if ($showWarningIncompleteOrNotValidData) {

$presUtils->printErrorHeader ( ADVERTENCIA_REQUERIDOS_NOVALIDOS );

}

?>

<form name="frmEditTypeRec" action="edit-type-rec.php" method="post">

<div id="editCategoriaDiv" class="standard-border">

<div class="standard-header"><span class="standard-header-

text">

<?php

echo (($action == EDIT) ? 'Editar ' : 'Crear ') . 'tipo de recomendación';

?>

</span></div>

<input type="hidden" name="txtTrecId"

value="<?php

echo $tRecEditActual->trc_id;

?>" />

<table>


<tr>

<td>

<p class="required" style="text-align:

right">* Campos

obligatorios.</p>

<p class="underlined-label">Datos del tipo

de recomendación</p>

<table class="highlight-row">


<tr>

<td>

<p class="input-

label">Nombre del tipo: <span class="required">*</span></p>

</td>

<td><input size="80px"

name="nombreTipo" type="text"

maxlength="100"

value="<?php

echo

$tRecEditActual->trc_nombre_tipo_rec;

?>" /> <span

class="required"><?php




124

if ($noNombreTipo)

{

echo

REQUERIDO;

}

?>

</span></td>

</tr>

<tr>

<td>

<p class="input-

label">Descripción del tipo</p>

</td>

<td><textarea

name="descTipo" cols="65" rows="7"

onKeyDown="textCounter(document.frmEditTypeRec.descTipo,

document.frmEditTypeRec.countDesc, 500)"

onKeyUp="textCounter(document.frmEditTypeRec.descTipo,

document.frmEditTypeRec.countDesc, 500)"><?php

echo

$tRecEditActual->trc_descripcion_tipo_rec;

?></textarea> <br>

<span class="small-text">

<?php

echo

CARACTERES_RESTANTES;

?> </span> <input

style="border: none;" readonly="readonly"

type="text"

id="countDesc" value="500" />

<?php

$utils-

>printHelpButton ( 'Descripción del tipo', 'Información del propósito por el

que se crea este tipo de recomendación.' );

?>

</td>

</tr>

<tr>

<td>

<p class="input-

label">Actividad del entorno virtual:</p>

</td>

<td>

<?php

choose_from_menu ( $MOODLE_MODULES, 'moduloMoodle',

$tRecEditActual->trc_tipo_recurso, NOSELECTION, '', NULL );

$utils->printHelpButton ( 'Actividad del entorno virtual',

'Seleccione el tipo de actividad que se va a realizar dentro del entorno

virtual con esta recomendación. Para tipos de recomendaciones en las que no se

incluya un recurso o funcionalidad del entorno virtual, deje este campo en

blanco.' );




125

?>

</td>

</tr>

<tr>

<td>

<p class="input-

label">Categorías asociadas: <span

class="required">*</span></p>

</td>

<td>

<?php

// Obtener todas las categorías y marcar las que tiene

asociado el tipo de recomendación.

if (($_SERVER ["REQUEST_METHOD"] == 'POST') &&

$noCategorias) {

echo '<span class="required">' . SELECCIONEOPCION .

'</span><br>';

}

$queryCatDisp = get_records ( 'sr_categoria', '', '',

'cat_nombre_categoria' );

foreach ( $queryCatDisp as $idcat => $filaCat ) {

echo '<input type="checkbox" name="catsAsociadas[]"

value="' . $idcat . '" ' . (array_search ( $idcat, $categoriasAsociadas ) ?

'checked="checked">' : '>') . '<span class="normal-text">' . $filaCat-

>cat_nombre_categoria . '</span></input><br />';

}

echo '<br>';

$utils->printHelpButton ( 'Categorías asociadas', 'Una

recomendación puede tener más una o más categorías o campos del proceso de

aprendizaje que se relacionen a ella. Para gestionar las categorías de

recomendaciones dentro del sistema, debe utilizar las funcionalidades de la

sección Categorías de recomendaciones, en el menú lateral de la aplicación.'

);

?>

</td>

</tr>

<tr>

<td><span class="input-

label">Fecha de creación:</span></td>

<td><input type="text"

readonly="readonly" name="fechaCreacion"

border=""

value="

<?php

if ($action == CREATE) {

echo date ( "Y-m-d" );

} else {

echo $tRecEditActual->trc_fecha_creacion;

}




126

?>" /></td>

</tr>

</tbody>

</table>

<p class="underlined-label">Plantilla de

recomendación</p>



<tr>

<td>

<p class="input-

label">Título: <span class="required">*</span></p>

</td>


name="tituloRec" type="text"

maxlength="100"

value="<?php

echo

$tRecEditActual->rec_titulo;

?>" /><span

class="required"> <?php

if ($noTitulo) {

echo

REQUERIDO;

}

?></span>

<?php

$utils-

>printHelpButton ( 'Título', 'Un título genérico para las recomendaciones que

se creen a partir de este tipo de recomendación' );

?>

</td>

</tr>

<tr>

<td>

<p class="input-

label">Texto de la recomendación: <span

class="required">*</span></p>

</td>

<td><textarea

name="textoRec" cols="65" rows="7"

onKeyDown="textCounter(document.frmEditTypeRec.textoRec,

document.frmEditTypeRec.countText, 500)"

onKeyUp="textCounter(document.frmEditTypeRec.textoRec,

document.frmEditTypeRec.countText, 500)"><?php

echo

$tRecEditActual->rec_texto;




127

?></textarea> <span

class="required"><?php

if

($noTextoRecomendacion) {

echo

REQUERIDO;

}

?></span><br>


<?php

echo


?> </span> <input


type="text"

id="countText" value="500" />

<?php

$utils-

>printHelpButton ( 'Texto de la recomendación', 'Texto en el que se debe dar

indicaciones, instrucciones, u otro tipo de información acerca de la

recomendación que se está ofertando.' );

?></td>

</tr>

<tr>

<td>

<p class="input-

label">Explicación:</p>

</td>

<td><textarea

name="explicacionRec" cols="65" rows="7"

onKeyDown="textCounter(document.frmEditTypeRec.explicacionRec,

document.frmEditTypeRec.countExp, 500)"

onKeyUp="textCounter(document.frmEditTypeRec.explicacionRec,

document.frmEditTypeRec.countExp, 500)"><?php

echo

$tRecEditActual->rec_explicacion;

?></textarea><br>


<?php

echo


?> </span> <input


type="text"

width="15" id="countExp" value="500" />

<?php

$utils-

>printHelpButton ( 'Explicación', 'Texto para informar al estudiante del por

qué se le está ofreciendo esta recomendación.' );

?></td>

</tr>




128

<tr>

<td>

<p class="input-

label">Enlace:</p>

</td>


name="enlaceWeb" type="text" size="40"

maxlength="200"

value="<?php

echo

$tRecEditActual->rec_enlace;

?>"

onblur="outputLinkProbe(this.value)" /> <a id="linkprober"

target="_blank"

href="<?php

/*if ($action ==

EDIT) {

echo

$tRecEditActual->rec_enlace;

} else {*/

echo (empty (

$tRecEditActual->rec_enlace )) ? 'http://' : $tRecEditActual->rec_enlace;

/*}*/

?>"><span

class="hyperlinks">Probar enlace</span></a>

<?php

$utils-

>printHelpButton ( 'Enlace', "Opcionalmente se puede ingresar un enlace

(dirección Web) con algún recurso que se requiera que el estudiante visite.

Para probar la dirección ingresada, haga clic en el enlace \"Probar enlace\"

junto al cuadro de texto." );

?></td>

</tr>

</tbody>

</table>

<p class="underlined-label">Restricciones

de vencimiento</p>

<p class="descriptions"><span

class="required">*</span> Puede

completar el valor cualquiera de los dos

valores. El valor que se

complete será el que defina cuándo vence

la recomendación. Si

completa los dos, la recomendación vencerá

al primero que se

cumpla.</p><?php

if (($_SERVER ["REQUEST_METHOD"] == "POST") &&

$noRestriccionVencimiento) {

echo '<p class="required">' .

ESPECIFIQUE_RESTRICCION_VENCIMIENTO . '</p>';

}

?>




129

<input type="hidden"

value="<?php

echo $rVenc->rvc_id;

?>"

name="txtRvcId">


<tbody>

<tr>


label">Vence en:</span></td>

<td>

<?php

require_once ("tc_calendar.php");

$myCalendar = new tc_calendar ( "fechaVencimiento", true );

$myCalendar->setDate ( $fechaExpiracionArray [2],

$fechaExpiracionArray [1], $fechaExpiracionArray [0] );

$myCalendar->setIcon ( "images/iconCalendar.gif" );

$myCalendar->writeScript ();

?>

</td>

<td><input type="hidden"

name="rvcId"

value="<?php

echo $rVenc->rvc_id;

?>" /></td>

</tr>

<tr>


label">Vence al mostrarse el siguiente

número de

veces:</span></td>

<td><input

name="venceEnNVeces" type="text" size="40"

maxlength="100"

value="<?php

echo $rVenc-

>rvc_veces_a_mostrar;

?>" /> <span

class="validation-error">

<?php

if ((! empty ( $rVenc->rvc_veces_a_mostrar ) &&

$vecesNoEsUnNumero)) {

echo DEBE_SER_NUMERO;

}

?> </span></td>

</tr>

</tbody>

</table>

<p class="underlined-

label">Condiciones</p>

<input type="hidden"

value="<?php

echo $condEstAprPresente;




130

?>"

name="condEstAprPresente"> <input

type="hidden"

value="<?php

echo $condIntCurPresente;

?>"

name="condIntCurPresente"> <input

type="hidden"

value="<?php

echo $condIntRecPresente;

?>"

name="condIntRecPresente"> <input

type="hidden"

value="<?php

echo $condNivIntPresente;

?>"

name="condNivIntPresente"> <input

type="hidden"

value="<?php

echo $condZonGeoPresente;

?>"

name="condZonGeoPresente"> <input

type="hidden"

value="<?php

echo $condEntUsuPresente;

?>"

name="condEntUsuPresente">



<tr>


label">Estilo de aprendizaje:</span></td>

<td> <?php

choose_from_menu (

$ESTILOS_APRENDIZAJE, 'estiloAprendizaje', $condEstApr->con_valor_condicion,

NOSELECTION );

?>

<?php

$utils->printHelpButton (

'Estilo de aprendizaje', 'Debe seleccionar aquí un estilo de aprendizaje para

el cual se va a aplicar este tipo de recomendación. La información sobre los

estilos de aprendizaje de los estudiantes puede encontrarse en el módulo de

modelado de usuario.' );

?></td>


name="idCondEstApr"

value="<?php


echo $condEstApr-

>con_id;

}

?>" /></td>

</tr>

<tr>




131


label">Zona Geográfica (centro):</span></td>

<td>

<?php

$displayCentros = array ();

$queryCentros = execute_sql (

"SELECT DISTINCT(centro) AS centro FROM mdl_enrol_utpl order by centro", false

);

$queryCentros = get_records_sql

( 'SELECT DISTINCT(centro) AS centro FROM mdl_enrol_utpl ORDER BY centro' );

$displayCentros ["todos"] =

"Todos";

foreach ( $queryCentros as $id

=> $row ) {

$displayCentros [$row-

>centro] = $row->centro;

}

choose_from_menu (

$displayCentros, 'zonGeografica', $condZonGeo->con_valor_condicion,

NOSELECTION, '', NULL );

?><input type="hidden"

name="idCondZonGeo"

value="<?php


echo $condZonGeo-

>con_id;

}

?>" />

<?php

$utils->printHelpButton ( 'Zona

Geográfica', 'Ubicación de los estudiantes para los cuales se ofertará esta

recomendación. Este atributo tiene relevancia cuando por ejemplo, se

recomienda asistencia a un evento, la recomendación podría tener mucha más

relevancia para los estudiantes en el mismo lugar o uno cercano al del evento.

Los datos de ubicaciones geográficas de los estudiantes pueden encontrarse en

el módulo de modelado de usuario.' );

?>

</td>

</tr>

<tr>


label">Plataforma:</span></td>

<td>

<?php

$plataformas = array ("PC" =>

"PC", "Dispositivo móvil" => "Dispositivo móvil" );

choose_from_menu (

$plataformas, 'entUsuario', $condEntUsu->con_valor_condicion, NOSELECTION, '',

NULL );




132

?> <input type="hidden"

name="idCondEntUsu"

value="<?php


echo $condEntUsu-

>con_id;

}

?>" />

<?php

$utils-

>printHelpButton ( 'Plataforma', 'Seleccione un valor cuando el tipo de

dispositivo con el que el estudante accede al entorno virtual es relevante

para el tipo de recomendación que se va a ofertar. Los datos de plataforma

pueden encontrarse en el módulo de modelado de usuario.' );

?>

</td>

</tr>

<tr>

<td>

<p class="input-

label">Nivel de interés en el curso:</p>

</td>

<td

id="cellNivelInteresCurso">

<?php

$client = new nusoap_client ( WSDL, true );

$atributosInteresCurso = $client->call (

'GetValoresEstereotiposAtribModeloUsuario', array ('atributo' => 'Nivel de

Interes en el Curso' ) );

$xmlstringInteresCurso = <<<XML

$atributosInteresCurso

XML;

$listaInteresCurso = simplexml_load_string (

$xmlstringInteresCurso );

$escalaInteres = array ();

foreach ( $listaInteresCurso as $rowidx => $row ) {

$value = $row->ves_valor_estereotipo . '';

$escalaInteres [$value] = $value;

}

choose_from_menu ( $escalaInteres, 'nivelInteresCurso',

$condIntCur->con_valor_condicion, NOSELECTION );

//choose_from_menu ( $ESCALA, 'nivelInteresCurso',

$condIntCur->con_valor_condicion, NOSELECTION );

$utils->printHelpButton ( 'Nivel de interés en el curso',

'Seleccione un valor cuando el nivel de interés en el curso que tiene el

estudiante es relevante para el tipo de recomendación que se va a ofertar.' );

?>

</td>


name="idCondIntCur"




133

value="<?php


echo $condIntCur-

>con_id;

}

?>" /></td>

</tr>

<tr>

<td>

<p class="input-

label">Nivel de interés en recursos:</p>

</td>

<td

id="cellNivelInteresRecursos"><?php

$client = new

nusoap_client ( WSDL, true );

$atributosWS = $client-

>call ( 'GetValoresEstereotiposAtribModeloUsuario', array ('atributo' =>

'Nivel de Interes en Recursos' ) );

$xmlstring = <<<XML

$atributosWS

XML;

$listaWS =

simplexml_load_string ( $xmlstring );

$escalaRecursos = array

();

foreach ( $listaWS as

$rowidx => $row ) {

$value = $row-

>ves_valor_estereotipo . '';

$escalaRecursos

[$value] = $value;

}

choose_from_menu (

$escalaRecursos, 'nivelInteresRecursos', $condIntRec->con_valor_condicion,

NOSELECTION );


'Nivel de interés en recursos', 'Seleccione un valor cuando el nivel de

interés en recursos que tiene el estudiante es relevante para el tipo de

recomendación que se va a ofertar.' );

?></td>


name="idCondIntRec"

value="<?php


echo $condIntRec-

>con_id;

}

?>" /></td>

</tr>

<tr>




134

<td>

<p class="input-

label">Nivel de interacción:</p>

</td>

<td

id="cellNivelInteraccion"><?php

$client = new

nusoap_client ( WSDL, true );

$atributosWS = $client-

>call ( 'GetValoresEstereotiposAtribModeloUsuario', array ('atributo' =>

'Nivel de Interaccion' ) );

$xmlstring = <<<XML

$atributosWS

XML;

$listaWS =

simplexml_load_string ( $xmlstring );

$escalaInteraccion =

array ();

foreach ( $listaWS as

$rowidx => $row ) {

$value = $row-

>ves_valor_estereotipo . '';

$escalaInteraccion

[$value] = $value;

}

choose_from_menu (

$escalaInteraccion, 'nivelInteraccion', $condNivInt->con_valor_condicion,

NOSELECTION );


'Nivel de interacción en el curso', 'Seleccione un valor cuando el nivel de

interacción en el curso que tiene el estudiante es relevante para el tipo de

recomendación que se va a ofertar.' );

?></td>


name="idCondNivInt"

value="<?php


echo $condNivInt-

>con_id;

}

?>" /></td>

</tr>

</tbody>

</table>

</td>

</tr>

</tbody>

</table>

</div>

<br>

<input name="guardar" type="submit" value="Guardar"> <input

name="cancelar" type="submit" value="Cancelar"></form>




135

</td>

</tr>

</tbody>

</table>

</body>

</html>

7.12.2 edit-category.php

Archivo de código fuente para editar categorías.

<?php require ('./require-login.php'); require ('./admin-recom-constants.php'); require ('./presentation-utils.php'); require ('./classesdb/data-utils.php'); require ('./utils.php'); global $CFG; $showSaveWarning = false; $showRequiredWarning = false; $presUtils = new PresentationUtils (); $catEditActual = new Categoria (); // Setear la acción actual $action = ''; $utils = new Utils (); $utils->setFormActionType ( &$action, $_GET, $_POST, 'catid', 'txtCatId' ); $noNombre = false; $noDescripcion = false; if ($_SERVER ["REQUEST_METHOD"] == "POST") { if (array_key_exists ( "cancelar", $_POST )) { header ( 'Location: list-categories.php' ); exit (); } else { // Autopost para setear los valores de los controles en el form. $catEditActual->cat_nombre_categoria = $_POST ["nombreCategoria"]; $catEditActual->cat_rec_descripcion = $_POST ["descCategoria"]; $catEditActual->cat_id = $_POST ["txtCatId"]; $noNombre = empty ( $catEditActual->cat_nombre_categoria ); $noDescripcion = empty ( $catEditActual->cat_rec_descripcion ); if ($noNombre || $noDescripcion) { $showRequiredWarning = true; } else if ($action == EDIT) { $idUpdate = (empty ( $_GET ["catid"] )) ? $_POST ["txtCatId"] : $_GET ["catid"];




136

$sql = "UPDATE {$CFG->prefix}sr_categoria " . "SET cat_nombre_categoria = '" . $_POST ["nombreCategoria"] . "', " . "cat_rec_descripcion = '" . $_POST ["descCategoria"] . "' " . "WHERE cat_id = " . $idUpdate; $success = execute_sql ( $sql, false ); if ($success) { header ( "Location: view-category.php?catid={$_POST["txtCatId"]}&edited=y" ); exit (); } else { $showSaveWarning = true; } } else if ($action == CREATE) { $dataUtils = new DataUtils (); $newCatId = 0; $success = $dataUtils->insert ( $catEditActual, 'mdl_sr_categoria', &$newCatId ); if ($success) { header ( "Location: view-category.php?catid=$newCatId&created=y" ); exit (); } else { $showSaveWarning = true; } } } } if ($_SERVER ["REQUEST_METHOD"] == "GET") { // Al editar sólo se llega por GET if (array_key_exists ( "catid", $_GET )) { $query = get_records ( 'sr_categoria', 'cat_id', $_GET ["catid"], 'cat_nombre_categoria' ); $rowCategoria = $query ["{$_GET["catid"]}"]; $catEditActual->cat_nombre_categoria = $rowCategoria->cat_nombre_categoria; $catEditActual->cat_rec_descripcion = $rowCategoria->cat_rec_descripcion; $catEditActual->cat_id = $rowCategoria->cat_id; } } ?> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <link rel=StyleSheet href="./css/styles.css" type="text/css" /> <title>Editar categoría</title> </head>




137

<body> <?php include ('header.php')?> <table width="100%" cellpadding="10"> <tbody class="tbody-content"> <tr> <td width="20%"><?php include ('left.php'); ?></td> <td width="80%"> <?php if ($showSaveWarning) { $presUtils->printWarningHeader ( ERROR_GUARDAR ); } else if ($showRequiredWarning) { $presUtils->printWarningHeader ( ADVERTENCIA_REQUERIDOS_NOVALIDOS ); } ?> <form name="editCategoriaForm" method="post" action="edit-category.php"> <div id="editCategoriaDiv" class="standard-border"> <?php $presUtils->printHeader ( (($action == EDIT) ? 'Editar ' : 'Crear ') . 'categoría' ); ?> <input type="hidden" name="txtCatId" value="<?php echo $catEditActual->cat_id; ?>" /> <table class="highlight-row"> <tbody class="tbody-content"> <tr> <p class="required" style="text-align:right"> * Campos obligatorios.</p> <p class="underlined-label">Datos de la categoría</p> <td> <p class="input-label">Nombre de la categoría: <span class="required">*</span></p> </td> <td><input name="nombreCategoria" type="text" maxlength="100" value="<?php echo $catEditActual->cat_nombre_categoria; ?>" /> <span class="required"><?php




138

if ($noNombre) { echo REQUERIDO; } ?> </span></td> </tr> <tr> <td> <p class="input-label">Descripción de la categoría: <span class="required">*</span></p> </td> <td><textarea name="descCategoria" cols="65" rows="7"><?php echo $catEditActual->cat_rec_descripcion; ?></textarea><span class="required"><?php if ($noDescripcion) { echo REQUERIDO; } ?> </span></td> </tr> </tbody> </table> </div> <input name="guardar" type="submit" value="Guardar"> <input name="cancelar" type="submit" value="Cancelar"></form> </td> </tr> </tbody> </table> </body> </html>

7.12.3 require-login.php

Archivo de código fuente que controla inicio de sesión y autenticación de rol de

administrador de recomendaciones.

<?php require ("../config.php"); global $CFG, $USER, $COURSE; if ($CFG->forcelogin) { require_login (); }




139

// Verificar el rol del usuario actual if (! (record_exists ( 'role_assignments', 'roleid', 24, 'userid', $USER -> id ))) { include ('./error.php'); exit; } ?>

7.12.4 confirm-delete.php

Archivo de código fuente para borrar datos.

<?php require ('./require-login.php'); require ('./utils.php'); $showIncorrectRequestWarning = false; $showAlertDataNotDeleted = false; if ($_SERVER ["REQUEST_METHOD"] == 'GET') { global $TABLES_KEYS, $INFO_TABLES; $utils = new Utils (); // Verificar que el request sea correcto if (isset ( $_GET ["id"] ) && (($utils->validateIntParamOnGET ( $_GET ["id"] )) != - 1) && isset ( $_GET ["type"] ) && array_search ( $_GET ["type"], $TABLES_KEYS )) { $showIncorrectRequestWarning = false; } else { $showIncorrectRequestWarning = true; } } else if ($_SERVER ["REQUEST_METHOD"] == 'POST') { $type = $_POST ["type"]; $returnTo = $INFO_TABLES [$type] ["listview"]; if (array_key_exists ( "borrar", $_POST )) { include ('./classesdb/data-utils.php'); $id = $_POST ["id"]; $dataUtils = new DataUtils (); $noRollback = true; $noRollback = $noRollback && $dataUtils->beginTransaction (); $noRollback = $noRollback && $dataUtils->autoCommitFalse (); $rowCount = 0; $noRollback = $noRollback && $dataUtils->delete ( 'mdl_' . $INFO_TABLES [$type] ["table"], $INFO_TABLES [$type] ["pk"], $id, &$rowCount ); if (($noRollback == false) || ($rowCount < 1)) { $dataUtils->rollback (); $showAlertDataNotDeleted = true; } else {




140

if ($dataUtils->commit () == false) { $dataUtils->rollback (); $showAlertDataNotDeleted = true; } else { echo ("<script>location.href = '$returnTo?deleted=y';</script>"); exit (); } } } else { echo ("<script>location.href = '$returnTo';</script>"); exit (); } } ?> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <link rel=StyleSheet href="./css/styles.css" type="text/css" /> <title>Confirmar borrado de datos</title> </head> <body> <?php include ('header.php'); ?> <table width="100%" cellpadding="10"> <tbody class="tbody-content"> <tr> <td width="20%"><?php include ('left.php'); ?></td> <td width="80%"> <form action="confirm-delete.php" method="post" name="confim-delete"> <div id="viewRecDiv" class="standard-border"> <?php require ('./presentation-utils.php'); $presUtils = new PresentationUtils (); $presUtils->printHeader ( 'Confirmación de borrado de datos' ); if (($_SERVER ["REQUEST_METHOD"] == 'GET') && $showIncorrectRequestWarning) { $presUtils->printWarningHeader ( ERROR_NO_DATA_FOUND ); $presUtils->backButton (); exit (); } else if (($_SERVER ["REQUEST_METHOD"] == 'POST') && $showAlertDataNotDeleted) { $presUtils->printErrorHeader ( ERROR_NO_DATA_FOUND ); $presUtils->backButton (); exit (); }




141

?> <p><span class="critical-question"> ¿Está seguro de que desea borrar los datos? Esta operación no se puede deshacer.</span> <input type="hidden" name="id" value="<?php echo ($_SERVER ["REQUEST_METHOD"] == 'POST') ? $_POST ["id"] : $_GET ["id"]; ?>" /> <input type="hidden" name="type" value="<?php echo ($_SERVER ["REQUEST_METHOD"] == 'POST') ? $_POST ["type"] : $_GET ["type"]; ?>" /> <input name="borrar" type="submit" value="Sí"/> <input name="cancelar" type="submit" value="No"/> </p> </div> </form> </td> </tr> </tbody> </table> </body>

</html>




142

8. Bibliografía

Public Health Learning. (2009). Recuperado el 12 de Julio de 2010, de LMS Overview:

http://www.publichealthlearning.com/Online_Help_Guides/Closed/Learner_User_Manual

/LMS%20User%20Manual/!SSL!%5CWebHelp/Learner/LMS_Overview.htm

Candillier, L., Jack, K., & Fessant, F. (2009). State of the Art - Recommender Systems.

Francia: IGI Global.

Davis, B., Carmean, C., & Wagner, E. (15 de Octubre de 2009). Moodle Moves To The

Front of the LMS Adoption Pack. Recuperado el 2009, de Learning Solutions Magazine:

http://www.learningsolutionsmag.com/articles/111/

Itmazi, J. (2005). Sistema flexible de gestión de eLearning para soportar el aprendizaje en

las Universidades Tradicionales y Abiertas. Granada, España.

Krishnakumar, A. (2007). Recoo: A Recommendation System for Youtube RSS Feeds.

Santa Cruz, California, Estados Unidos.

Mallon, D., Bersin, J., Howard, C., & O’Leonard, K. (2009). WSI LMS: Learning Media

System. Recuperado el 25 de Julio de 2010, de

http://www.wsilms.com/Portals/0/WSILMS_Data_Files/LMS_Market_Overview_Bersin.

pdf

Moodle.org. (2010). Moodle.org. Recuperado el 2009, de

http://docs.moodle.org/en/Features

Santos, O. (2009). Ampliando el apoyo ofrecido por las plataformas de e-learning

mediante un servicio de recomendaciones. Granada, España.

Santos, O. C., Martín, L., Mazzone, E., & Boticario, J. (2009). Management of

recommendations for accessible eLearning platforms: is it a need for learning

management system users? Madrid, España.

Santos, O., & Boticario, J. (2008). Users’ experience with a recommender system in an

open source standard-based learning management system. (a. R. UNED, Ed.) Madrid,

España.

Somerville, I. (2005). Ingeniería del Software. Pearson Addison-Wesley.




143

Tartakoff, J. (20 de Agosto de 2009). Moodle Moves To the Front of the LMS Adoption

Pack. Recuperado el 2009, de http://paidcontent.org/article/419-youtube-tries-to-get-

visitors-to-watch-more-clips-new-recommendation-sy/

Turnbull, D. (s.f.). Interacting with Recommender Systems. Recuperado el 2010, de

http://www.ischool.utexas.edu/~donturn/papers/chi99/chi99.html

Wells, D. (1999-2009). The Rules of Extreme Programming. Obtenido de The Rules of

Extreme Programming: http://www.extremeprogramming.org/rules.html

Zins, A. H., Bauernfeind, U., Del Missierb, F., Venturinib, A., & Rumetshoferc, H. (2003).

An Experimental Usability Test for different Destination Recommender Systems. Viena,

Austria.

Sistemas Adaptativos en Moodle:

Interfaz de administración de recomendaciones estáticas

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 ) 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.

En el presente trabajo se trata el desarrollo de una

interfaz Web de administración de recomendaciones,

el cual forma parte de la implementación de un

sistema de recomendaciones completo integrado a

Moodle. Se incluye el estudio de los elementos de las

recomendaciones, la creación de un modelo de datos

para el sistema recomendador, el proceso y

documentación del desarrollo, la creación de un

servicio Web para recuperar información del modelo

de datos, la integración de la aplicación con Moodle y

las pruebas con usuarios que se realizaron para

verificar el funcionamiento de la aplicación.

Palabras Clave: Sistemas recomendadores,

administración de recomendaciones, Moodle,

modelado de usuario, servicios Web.

1. 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.

Desarrollo de un servicio Web que permite

consumir los datos del modelo de

recomendaciones y de los atributos del

modelado de usuario.

Integración de la interfaz de administración

con Moodle, usando sus mecanismos de

Juan Pablo Angamarca G.

Escuela de Ciencias de la

Computación

Universidad Técnica Particular

de Loja

Ing. Jorge López

Instituto de Investigación en

Ingeniería y Ciencias de la

Computación

Universidad Técnica Particular de

Loja


Instituto de Investigación en

Ingeniería y Ciencias de la

Computación

Universidad Técnica Particular de

Loja

autenticación, y un bloque que permita

acceder a la interfaz.

Pruebas de aplicación con docentes para

verificar su correcto funcionamiento.

Los resultados obtenidos al final del proceso son una

interfaz que permite la gestión de tipos de

recomendaciones y categorías de recomendaciones, un

modelo de recomendaciones y un servicio Web que la

misma interfaz utiliza para recuperar datos desde el

modelo de recomendaciones.

2. ESTADO DEL ARTE

2.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); dichas

técnicas se explican en capítulos posteriores.

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.

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).

2.2. LMS y Recomendaciones dentro de un LMS

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. 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.

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. 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.

2.3. Elementos de las 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 dentro de

situaciones frustrantes que puedan surgir dentro

del desarrollo de las actividades de enseñanza-

aprendizaje dentro del curso, tales como

dificultades de comprensión, o 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.

Restricciones temporales o de vencimiento: Dentro

de este apartado se define cuándo y hasta cuándo se

ofrece una recomendación. Pueden estar dadas por

fechas concretas, intervalos de tiempo o eventos.

3. DEFINICIÓN DEL PROBLEMA

3.1. Planteamiento del problema

Dentro de un entorno LMS, se puede

manejar una cantidad inmensa de cursos y

recursos. Sin un sistema de

recomendaciones, es probable que los

usuarios del LMS tengan que enfrentarse al

problema de sobrecarga de información,

muy común en los entornos de Internet, y

no puedan realizar sus actividades en forma

adecuada al no tener un medio de apoyo

para discernir entre los recursos que le

serán de utilidad y los que no.

3.2. Estado actual

Actualmente el LMS utilizado en la

Universidad Técnica Particular de Loja

(Moodle) no cuenta con un sistema de

recomendaciones. Dada su implementación,

es necesario contar con un sistema de

administración de recomendaciones que

permita a los un experto recomendador

crear, modelar y llevar registro de los tipos

de recomendaciones que se creen dentro del

sistema. Este sistema debe permitir crear

tipos de recomendaciones, explotando todas

las características de los modelos de

usuario de los estudiantes, para que estos

tipos de recomendaciones se usen en la

generación de recomendaciones específicas

para los estudiantes, dado que cumplan con

las restricciones y características definidas

en los tipos de recomendaciones, es decir,

que se establezcan las condiciones sobre las

que se ofrecerá la recomendación; y la

técnica con la que se va a generar. Debe

permitir también editar y cambiar

parámetros de las recomendaciones creadas

y ya ofrecidas a los estudiantes.

3.3. Objetivos

Construir una interfaz de


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.

3.4. Esquema de la solución

3.4.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 además las

categorías de recomendaciones, tipos de

recomendaciones, técnicas de obtención,

restricciones de vencimiento y condiciones a

las que se sujetan las recomendaciones y

tipos de 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 EVA UTPL.

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. El modelado de usuario para el

sistema de recomendaciones del cual es parte

este trabajo ha sido realizado por el autor del

proyecto relacionado “Agente de Modelado

de Usuarios”.

Figura 1.Modelo de datos del sistema recomendador.

3.4.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 tipos de

recomendaciones dando valores a los

parámetros que los definen,

considerando los factores apropiados

de los modelos de usuario para luego,

a partir de estos tipos, crear

recomendaciones apropiadas. En esta

interfaz, al tratarse de

recomendaciones estáticas, el

conocimiento de un experto se refleja

al crear los tipos de recomendaciones

mediante la técnica Matching

conditions.

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.

4. ANÁLISIS Y DEFINICIÓN DE LA

SOLUCIÓN

4.1. Requerimientos

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 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.

o Información que sirva como plantilla

para todas las recomendaciones que 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.

4.2. Componentes relacionados

4.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 por el autor del trabajo

relacionado “Módulo tutor de ingreso de

recomendaciones”

4.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.

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) y nivel

de interacción (nivel de interacción de

los estudiantes con el entorno virtual)

Fig.2. Esquema de la solución

5. DESARROLLO DE LA SOLUCIÓN

Para la aplicación de interfaz de administración se

requiere que para ingresar, se exija a los usuarios

autenticación. Dicha autenticación se realiza con los

mecanismos integrados de Moodle para verificar que

al ingresar se provea un nombre de usuario y

contraseña válidos, y que el usuario tenga un rol de

administrador de recomendaciones dentro del sistema.

5.1. Desarrollo del servicio Web

En el desarrollo de esta tesis, se ha creado un servicio

Web de administración de recomendaciones, el cual

provee información sobre tipos de recomendaciones,

categorías de recomendaciones y valores de atributos

de modelo de usuario. El servicio Web implementado

permite que la aplicación tenga una arquitectura

orientada a servicios, lo cual significa que la

comunicación entre la aplicación y el servicio hace

uso de mensajes. Dicho servicio se ha desarrollado con

en el framework de servicios web para PHP NuSOAP,

el cual permite implementar y consumir servicios web

basados en el protocolo SOAP (Simple Object Access

Protocol).

5.1.1. Operaciones del servicio Web

El servicio Web expone información tanto del modelo

de recomendaciones como del modelo de usuario.

Dados los requerimientos de información que debe

manejar la interfaz de administración de

recomendaciones, se han definido las siguientes

operaciones dentro del servicio Web desarrollado:

GetTiposRecomendacion: Se utiliza para

obtener todos los tipos de recomendación

existentes dentro del modelo del sistema

recomendador.

GetTipoRecomendacion: Se utiliza para

recuperar un tipo de recomendación en

particular.

GetRestricVencDeTipoRecomendacion: Para

obtener un conjunto de restricciones de

vencimiento asociadas a un tipo de

recomendación.

GetCategoriasAsociadasATipoRecomendaci

on: Para obtener las categorías que se

asocian a un tipo de recomendación.

GetCategoria: Obtener una categoría de

tipos de recomendaciones.

GetCategorias: Obtener todas las categorías

de recomendaciones existentes dentro del

sistema.

GetCondicionDeTipoRec: Obtener las

condiciones asociadas a un tipo de

recomendación.

GetValoresEstereotiposAtribModeloUsuario

: Datos recuperados desde el modelo de

usuario que indican los valores que puede

tomar un atributo de modelo de usuario.

Figura 3. Esquema del consumo del servicio Web

implementado para la interfaz de administración de

recomendaciones

Al ser un servicio Web basado en SOAP, cuenta con

un archivo WSDL (Web Services Description

Language), el cual describe las operaciones

disponibles del servicio. También, los datos que se

obtienen del servicio Web están definidos mediante el

lenguaje XML , el cual es elemento primordial de los

servicios Web basados en SOAP.

La aplicación de administración de recomendaciones

consume las operaciones del servicio creado para

todas las operaciones en las que es necesario obtener

datos desde el modelo del sistema recomendador. Los

mensajes XML se reciben y se les da tratamiento

adecuado para que sean presentados en las vistas como

información legible.

El servicio Web implementado permite que toda la

información disponible dentro del modelo de

recomendaciones esté disponible para otras

aplicaciones, de tal forma se asegura la

interoperabilidad, al ofrecer la información con un

mecanismo ampliamente usado y aceptado.

5.2. Desarrollo de las interfaces

Las interfaces de la aplicación se desarrollan con el

lenguaje PHP, HTML (Hypertext Markup Language),

Javascript (funciones de validación y navegación), y

CSS (Cascade Style Sheets, hojas de estilo en

cascada), para aplicar estilos estandarizados a las

interfaces. Para poder satisfacer los requerimientos

expuestos, se van a desarrollar las siguientes interfaces

de la aplicación:

• Menú lateral de funcionalidades

• Listado de tipos de recomendación

• Creación/edición de tipos de recomendación

• Listado de categorías de recomendaciones

• Creación /edición de categorías de

recomendaciones

• Borrado de datos.

5.2.1. Menú lateral de funcionalidades

Este menú contiene acceso a las funcionalidades que

se han desarrollado en todo el sistema. Este menú se

puede encontrar de forma constante en todas las

interfaces de la aplicación.

5.2.2. Listado de tipos de recomendación

Esta interfaz tiene como funcionalidad poder listar

todos los tipos de recomendaciones que se creen

dentro del sistema. Provee de facilidades para realizar

acciones de creación, visualización y borrado de los

tipos de recomendación.

5.2.3. Creación/Edición de tipos de

recomendación

Es una de las dos principales interfaces de la

aplicación. Provee las facilidades para ingresar todos

los campos de un tipo de recomendación, una plantilla

de recomendación, condiciones de aplicabilidad y

restricciones de vencimiento.

Fig. 4. Interfaz de creación/edición de tipos de

recomendaciones.

En esta interfaz se refleja el trabajo hecho en el

modelo de recomendaciones. Se puede observar que

en ella, se introducen los datos para alimentar las

tablas de tipos de recomendaciones, condiciones de

aplicabilidad, restricciones de vencimiento, y se

recuperan datos del modelado de usuario como estilos

de aprendizaje, zona geográfica, plataforma, niveles de

interés en recursos y curso, y niveles de interacción.

5.2.4. Listado de categorías de

recomendación

Consiste en un listado de las categorías de

recomendaciones que se crean dentro del sistema. Esta

interfaz provee las facilidades necesarias para crear,

visualizar, editar y eliminar categorías de

recomendaciones.

5.2.5. Creación/Edición de tipos de

recomendaciones

La segunda interfaz principal del sistema, esta interfaz

permite tanto la creación como la edición de tipos de

categorías.

5.2.6. Borrado de datos

Todas las interfaces de listados permiten borrar

los datos creados. Se ha desarrollado una interfaz

genérica para utilizarse contra categorías o tipos de

recomendaciones. Esta interfaz solicita que se

confirme la operación para evitar que se eliminen

datos por equivocación.

5.3. Integración con Moodle

La integración del sistema con Moodle se realiza

mediante la programación de un bloque Moodle, el

cual permite que los usuarios accedan desde el entorno

virtual de aprendizaje a la aplicación de interfaz de

administración de recomendaciones. Este bloque

puede colocarse tanto en las páginas principales de los

usuarios como en los cursos a los que tengan acceso.

Este bloque cumple con la función de verificar el rol

del usuario actual, de manera idéntica a los

mecanismos de la aplicación, de tal forma que no da

acceso a la aplicación sin los requisitos de acceso

necesarios (rol de administrador de recomendaciones).

5.4. Consideraciones de la programación de la

aplicación

5.4.1. Diseño visual

Las interfaces de la aplicación han sido programadas

con un estilo visual coherente. Para poder lograr esto,

se ha utilizado hojas de estilos en cascada (CSS), con

apego a los atributos estándar de CSS.

5.4.2. Prácticas de programación

Gracias a la utilización del lenguaje PHP, HTML y

Javascript, se ha logrado diseñar con soltura las vistas

de la aplicación. Se ha tomado en cuenta buenas

prácticas de programación y de seguridad, tales como

añadir secuencias de escape en los campos de texto,

analizar entradas de usuario para evitar inyección

SQL, no utilizar características no estándares de los

lenguajes, caso que ocurren con frecuencia con los

lenguajes HTML y Javascript, y los atributos de las

hojas de estilo en cascada.

5.4.3. Pruebas de la aplicación

Se ha definido, con el uso de la metodología de

programación XP, casos de prueba necesarios

para poder verificar que las interfaces funcionen

en la forma que se espera que funcionen, y que

resultan manejables por parte de los usuarios.

6. CONCLUSIONES

En el modelo de recomendaciones

desarrollado para el sistema, fue

necesario incluir información sobre las

recomendaciones, tipos de

recomendaciones, categorías, técnicas,

restricciones y condiciones;

adicionalmente a ello fue necesario incluir

información de modelado de

usuario, la cual permite determinar cuándo

las recomendaciones son

aplicables a los estudiantes.

La interfaz de administración desarrollada

permite crear tipos de

recomendaciones con valores definidos para

los atributos del modelo de

usuario, lo cual permitirá ofrecer los

recursos disponibles dentro del

entorno virtual mediante recomendaciones

creadas a partir de dichos

tipos.

La selección de los tipos de actividades:

tareas, foros, glosarios, mensajería,

cuestionario, subir archivo y recurso, se

realizó por que son los más utilizados dentro

del entorno virtual, por consiguiente con los

que están más familiarizados tanto

estudiantes como profesores.

La integración de la interfaz con Moodle es

necesaria para que el

sistema pueda ser accedido con facilidad

desde el Entorno Virtual de

Aprendizaje. La integración no sólo

contempla un fácil acceso y uso,

sino también un ambiente familiar de

trabajo, es decir, similar a las

interfaces propias del EVA.

El desarrollo de servicios Web permite el

acceso a la información del

modelo de recomendaciones en una forma

estandarizada. De tal forma es

sencillo, tanto para la interfaz de


como para otras aplicaciones, el acceso a

dicha información.

Un sistema de recomendaciones involucra la

acción de varios módulos:

un módulo de administración de

recomendaciones para establecer tipos

genéricos predeterminados de

recomendaciones, un módulo de modelado

de

usuario para determinar la pertinencia de la

oferta de

recomendaciones, y un módulo de tutor para

ofrecer las recomendaciones

por parte de los docentes a los alumnos.

Adicionalmente, un módulo de

seguimiento de usuarios permite obtener

información valiosa sobre las

interacciones de los estudiantes con el

Entorno Virtual.

7. RECOMENDACIONES

Se debe entender muy bien el

funcionamiento y estructura de un

sistema de recomendaciones para poder

generar un modelo de datos y construir el

sistema. Los modelos aportados por los

autores Santos y Boticario fueron de gran

utilidad para desarrollar el modelo de

datos para la interfaz de administración

de recomendaciones.

Es necesario realizar más trabajos

investigación para proveer de mayor

información sobre desarrollo de

aplicaciones integradas a Moodle.

Para formar un sistema de

recomendaciones completo deben

integrarse los diferentes módulos

desarrollados (Seguimiento de usuario,

Módulo Tutor, Modelado de usuario,

Interfaz de administración), así como

crear un agente de recomendaciones, el

cual se encarga de ofrecer las

recomendaciones a los estudiantes de

acuerdo a los valores de sus modelos de

usuario y las recomendaciones que se

ajusten a ellos.

Diseñar interfaces de usuario amigables

para que personas con diferentes niveles

de conocimiento puedan utilizar

aplicaciones sin mayores problemas.

Tener en cuenta aspectos como

navegabilidad, usabilidad, aspecto visual,

familiarización con entornos manejados

con anterioridad.

Debe realizarse un proceso de pruebas de

la aplicación, el cual es útil para verificar

el funcionamiento del sistema y la

impresión que tienen los usuarios sobre el

mismo.

Si los datos del sistema recomendador

deben estar disponibles para múltiples

aplicaciones sobre diferentes tipos de

plataformas, es conveniente implementar

un mecanismo estandarizado y de alta

accesibilidad para poder recuperarlos, tal

es el caso de los servicios Web.

Explorar las posibilidades del uso de más

tipos de actividades dentro del entorno

virtual para poder ofrecer dichas

actividades dentro de las

recomendaciones.

8. BIBLIOGRAFÍA

• Candillier, L., Jack, K., & Fessant, F. (2009).

State of the Art - Recommender Systems. Francia:

IGI Global.

• Davis, B., Carmean, C., & Wagner, E. (15 de

Octubre de 2009). Moodle Moves To The Front of

the LMS Adoption Pack. Recuperado el 2009, de

Learning Solutions Magazine:

http://www.learningsolutionsmag.com/articles/111

• Itmazi, J. (2005). Sistema flexible de gestión

de eLearning para soportar el aprendizaje en las

Universidades Tradicionales y Abiertas. Granada,

España.

• Krishnakumar, A. (2007). Recoo: A

Recommendation System for Youtube RSS Feeds.

Santa Cruz, California, Estados Unidos.

• Moodle.org. (2010). Moodle.org.

Recuperado el 2009, de

http://docs.moodle.org/en/Features

• Santos, O. (2009). Ampliando el apoyo

ofrecido por las plataformas de e-learning

mediante un servicio de recomendaciones.

Granada, España.

• Santos, O. C., Martín, L., Mazzone, E., &

Boticario, J. (2009). Management of

recommendations for accessible eLearning

platforms: is it a need for learning management

system users? Madrid, España.

• Santos, O., & Boticario, J. (s.f.). Users’

experience with a recommender system in an open

source standard-based learning management

system. (a. R. UNED, Ed.) Madrid, España.

• Somerville, I. (2005). Ingeniería del

Software, Pearson Addison-Wesley.

• Tartakoff, J. (20 de Agosto de 2009).

Moodle Moves To the Front of the LMS Adoption

Pack. Recuperado el 2009, de

http://paidcontent.org/article/419-youtube-tries-to-

get-visitors-to-watch-more-clips-new-

recommendation-sy/

• Turnbull, D. (s.f.). Interacting with

Recommender Systems. Recuperado el 2010, de

http://www.ischool.utexas.edu/~donturn/papers/ch

i99/chi99.html

• Wells, D. (1999-2009). The Rules of

Extreme Programming. Obtenido de The Rules of

Extreme Programming:

http://www.extremeprogramming.org/rules.html

• Zins, A. H., Bauernfeind, U., Del Missierb,

F., Venturinib, A., & Rumetshoferc, H. (2003). An

Experimental Usability Test for different

Destination Recommender Systems. Viena,

Austria.

Public Health Learning. (2010). Recuperado

el 12 de Julio de 2010, de LMS Overview:

http://www.publichealthlearning.com/Online_Help

_Guides/Closed/Learner_User_Manual/LMS%20

User%20Manual/!SSL!%5CWebHelp/Learner/LM

S_Overview.htm

Documents

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad ...dspace.utpl.edu.ec/bitstream/123456789/1886/3... · Escuela de Ciencias de la Computación Tesis: Sistemas Adaptativos en