UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica De Loja

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja

ÁREA TÉCNICA

TITULACIÓN DE INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN

Implementación de Twitter y Facebook como herramienta de socialización y discusión de temas en el Entorno Virtual de Aprendizaje Moodle

TRABAJO DE FIN DE TITULACIÓN

AUTOR: Torres Rosales, Diego Ronald DIRECTOR: Torres Díaz, Juan Carlos, Ing.

LOJA – ECUADOR

2014

APROBACIÓN DEL DIRECTOR DEL TRABAJO DE FIN DE TITULACIÓN

Ingeniero.

Juan Carlos Torres Díaz.

DOCENTE DE LA TITULACIÓN

De mi consideración:

El presente trabajo de fin de titulación: Implementación de Twitter y Facebook como herramienta de socialización y discusión de temas en el Entorno Virtual de Aprendizaje Moodle realizado por Torres Rosales Diego Ronald, ha sido orientado y revisado durante su ejecución, por se aprueba la presentación del mismo.

Loja, octubre de 2014

f)......

DECLARACIÓN DE AUTORÍA Y CESIÓN DE DERECHOS

“Yo Torres Rosales, Diego Ronald declaro ser autor (a) del presente trabajo de fin de titulación: Implementación de Twitter y Facebook como herramienta de socialización y discusión de temas en el Entorno Virtual de Aprendizaje Moodle, de la Titulación de Ingeniero en Sistemas Informáticos y Computación, siendo Juan Carlos Torres Díaz director 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. Además certifico que las ideas, conceptos, procedimientos y resultados vertidos en el presente tranajo investigativo, son de mi exclusiva responsabilidad.

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: Torres Rosales, Diego Ronald Cédula: 1104789878

iii

DEDICATORIA

Dedico este trabajo principalmente a Dios, por permitirme el haber llegado a este momento tan importante de mi vida profesional. A mis padres Ramiro y Enith, mis hermanos Tyron y Abigail, que son el pilar fundamental de mi vida. A mi abuelito Monfilio que aunque ya no estés a mi lado, siempre te llevo en mi corazón. A mi gran familia por demostrarme siempre su cariño y apoyo incondicional. A todos mis amigos que han estado en todo momento a mi lado.

AGRADECIMIENTO

En primer lugar doy infinitamente gracias a Dios, por brindarme la vida y colmarme de bendiciones y sabiduría suficiente para culminar mi carrera universitaria.

Mi más sincero agradecimiento, reconocimiento y cariño a mis padres, por todo el esfuerzo, amor y comprensión que demostraron todos estos años. Gracias a ustedes he llegado a donde estoy.

A mis hermanos por estar siempre presentes conmigo, en los que he podido confiar y apoyarme para seguir adelante.

A toda mi familia, que han sido pilares fundamentales de mi vida, y que con su apoyo y cariño he podido dar este paso tan importante en mi vida profesional.

Gracias a todos mis amigos por ser parte de mi vida, nombrarlos sería muy extenso y podría cometer algún olvido injusto, por ello ¡Gracias amigos, por siempre estar ahí!

Gracias a todos mis profesores quienes supieron impartir sus conocimientos y experiencias profesionales conmigo.

Infinitas gracias Ing. Juan Carlos Torres, por su paciencia, dedicación, motivación, conocimientos y aliento incondicional en el desarrollo de este trabajo.

ÍNDICE DE CONTENIDOS

APROBACIÓN DEL DIRECTOR DEL TRABAJO DE FIN DE TITULACIÓN ...... ii

DECLARACIÓN DE AUTORÍA Y CESIÓN DE DERECHOS ...... iii

DEDICATORIA ...... iv

AGRADECIMIENTO ...... v

ÍNDICE DE CONTENIDOS ...... vi

LISTA DE FIGURAS ...... x

LISTA DE TABLAS ...... xii

LISTA DE CÓDIGOS ...... xiii

RESUMEN ...... 1

ABSTRACT ...... 2

INTRODUCCIÓN ...... 3

CAPÍTULO 1: ESTADO DEL ARTE ...... 5

1.1. Introducción...... 6

1.2. Aprendizaje...... 6

1.2.1. Teorías del Aprendizaje...... 6

1.2.2. Aprendizaje colaborativo ...... 8

1.3. Estrategias didácticas en entornos virtuales de aprendizaje...... 9

1.3.1. Técnica SQA...... 11

1.3.2. Técnica Q3...... 13

1.4. Redes sociales en Entornos Virtuales de Aprendizaje...... 15

1.4.1. Estadísticas de uso de internet y redes sociales en Ecuador ...... 16

1.4.2. Uso de redes sociales como entornos educativos ...... 18

1.5. Herramientas de socialización y discusión...... 19

1.5.1. Twitter...... 19

1.5.2. Facebook...... 20

CAPÍTULO 2: ESTADO ACTUAL DEL EVA Y DISEÑO DE LA SOLUCIÓN ...... 22

2.1. Estado actual del EVA ...... 23

2.2. Diseño de la solución...... 24

2.1.1. Plugin de actividad con integración de Twitter como herramienta de socialización y discusión: Twitter Integration...... 24

2.1.1.1. Identificación de usuarios...... 26

2.1.1.2. Requisitos ...... 26

2.1.2. Plugin de actividad con integración de Facebook como herramienta de socialización y discusión: Facebook Integration...... 27

2.1.2.1. Identificación de usuarios...... 28

2.1.2.2. Requisitos ...... 28

CAPÍTULO 3: DESARROLLO DE LA SOLUCIÓN ...... 29

3.1. Introducción...... 30

3.2. Desarrollo de la herramienta de socialización y discusión...... 30

3.2.1. Fase I: Planificación...... 30

3.2.1.1. Historias de usuario...... 30

3.2.1.2. Iteraciones...... 31

3.2.1.3. Plan de pruebas...... 32

3.2.2. Fase II: Diseño...... 32

3.2.2.1. Arquitectura de la solución...... 32

3.2.2.2. REST API de Twitter...... 33

3.2.2.3. Graph API de Facebook ...... 48

3.2.3. Fase III: Implementación...... 53

3.2.3.1. Modelo de datos...... 53

3.2.3.2. Definición de interfaces de usuario...... 69

3.2.3.3. Diagrama de componentes...... 78

3.2.4. Fase IV: Pruebas...... 85

3.2.4.1. Pruebas de integridad de datos ...... 85

3.2.4.2. Pruebas de funcionamiento ...... 85

CONCLUSIONES ...... 86

RECOMENDACIONES ...... 87

vii

BIBLIOGRAFÍA ...... 88

ANEXOS ...... 93

ANEXO A: HISTORIAS DE USUARIO ...... 94

4.1.1. Iteración 1: Desarrollo del plugin Twitter Integration...... 94

4.1.2. Iteración 2: Desarrollo del plugin Facebook Integration...... 100

ANEXO B: MOODLE SISTEMA DE GESTIÓN DE APRENDIZAJE ...... 107

5.1.1. Moodle...... 107

5.1.2. Entorno técnico...... 108

5.1.3. Estructura de directorios...... 110

5.1.4. Estructura básica de un sitio Moodle ...... 114

ANEXO C: MOODLE DEVELOPERS ...... 118

6.1.1. Roles y permisos ...... 118

6.1.2. Guía de estilo para desarrolladores ...... 119

6.1.2.1. Reglas generales...... 119

6.1.2.2. Estilos de código...... 120

6.1.2.3. Estructuras de las base de datos...... 124

6.1.2.4. Normas de Seguridad...... 125

6.1.2.5. Estilos de la interfaz...... 127

6.1.3. Librerías (APIs) para el desarrollo de plugins...... 128

6.1.3.1. Access API (access)...... 129

6.1.3.2. Data manipulation API (dml)...... 131

6.1.3.3. Form API (form)...... 136

6.1.3.4. Page API (page)...... 139

6.1.3.5. String API (string)...... 140

6.1.3.6. Rating API (rating) ...... 141

6.1.3.7. Moodlelib API (core)...... 143

6.1.4. Estructura de un plugin actividad...... 143

6.1.4.1. Directorio Backup ...... 144

viii

6.1.4.2. Directorio DB ...... 144

6.1.4.3. Directorio Lang ...... 149

6.1.4.4. Directorio Pix ...... 150

6.1.4.5. lib.php ...... 150

6.1.4.6. mod_form.php ...... 151

6.1.4.7. index.php ...... 152

6.1.4.8. view.php ...... 153

6.1.4.9. version.php ...... 154

ANEXO D: MANUAL DE INSTALACIÓN ...... 155

7.1.1. Plugin de actividad Twitter Integration ...... 155

7.1.1.1. Registro de aplicación en Twitter Developers ...... 155

7.1.1.2. Instalación y configuración de plugin Twitter Integration ...... 157

7.1.2. Plugin de actividad Facebook Integration ...... 161

7.1.2.1. Registro de aplicación en Facebook Developers ...... 161

7.1.2.2. Instalación y configuración de plugin Facebook Integration ...... 163

ANEXO E: PRUEBAS ...... 166

8.1.1. Introducción ...... 166

8.1.2. Pruebas de integridad de datos ...... 166

8.1.3. Pruebas de funcionamiento ...... 167

8.1.3.1. Instalación, actualización y desinstalación de plugins ...... 170

8.1.3.2. Plugin Twitter Integration ...... 171

8.1.3.3. Plugin Facebook Integration ...... 172

LISTA DE FIGURAS

Figura 1. Razones de uso de Internet ...... 16 Figura 2. Frecuencia de uso de Internet - Nacional ...... 17 Figura 3. Redes sociales en Ecuador, período Mayo-2013 / Mayo-2014 ...... 17 Figura 4. Uso de facebook por sexo de los fans - edad (Febrero – Julio 2014) ...... 18 Figura 5. Sitios Moodle registrador por versión ...... 32 Figura 6. Arquitectura de la solución ...... 33 Figura 7. Modelo de datos Iteración 1 con Moodle v.1.9.19 ...... 53 Figura 8. Modelo de datos Iteración 1 con Moodle v.2.6 ...... 58 Figura 9. Modelo de datos Iteración 2 con Moodle versión 1.9.19...... 62 Figura 10. Modelo de datos Iteración 2 con Moodle versión 2.6 ...... 66 Figura 11. Crear / modificar instancia Twitter Integration ...... 71 Figura 12. Listado de instancias Twitter Integration ...... 71 Figura 13. Instancia del plugin Twitter Integration ...... 73 Figura 14. Visualizar calificación interacción Twitter Integration ...... 74 Figura 15. Crear/modificar instancia Facebook Integration ...... 75 Figura 16. Listado de instancias Facebook Integration ...... 76 Figura 17. Instancia del plugin Facebook Integration ...... 77 Figura 18. Visualizar calificación interacción Facebook Integration ...... 77 Figura 19. Diagrama de componentes Iteración 1 con Moodle versión 1.9.19 ...... 78 Figura 20. Diagrama de componentes Iteración 1 con Moodle versión 2.6 ...... 81 Figura 21. Diagrama de componentes Iteración 2 con Moodle versión 1.9.19 ...... 82 Figura 22. Diagrama de componentes Iteración 2 con Moodle versión 2.6 ...... 84 Figura 23. Plataforma LAMP (Linux), WAMP (Windows), MAMP (Mac OS) ...... 109 Figura 24. Estructura de directorios Moodle v1.9 ...... 111 Figura 25. Estructura de directorios Moodle v2.6 Fuente: Autor ...... 112 Figura 26. Estructura básica de Moodle ...... 114 Figura 27. Estructura de archivos plugin certificate ...... 143 Figura 28. Crear nueva aplicación en Twitter ...... 155 Figura 29. Cambiar permisos de la aplicación...... 156 Figura 30. API key y API secret de aplicación ...... 156 Figura 31. Access tokens de la aplicación ...... 157 Figura 32. Comprobación de „plugins‟ ...... 158 Figura 33. Instalación de plugin Twitter Integration ...... 158 Figura 34. Campos de perfil de usuario - Moodle ...... 159

Figura 35. Creando un nuevo campo de perfil “Entrada de texto” ...... 160 Figura 36. Fichero config.php Twiter Integration ...... 161 Figura 37. Crear nueva aplicación en Facebook ...... 162 Figura 38. Agregar una plataforma Website ...... 163 Figura 39. Comprobación de „plugins‟ ...... 164 Figura 40. Fichero config.php Facebook Integration ...... 165 Figura 41. Prueba de instalación, actualización y desinstalación de plugins...... 170 Figura 42. Pruebas de funcionamiento P001, P002, P003 ...... 171 Figura 43. Pruebas de funcionamiento P004, P005, P006, P007, P008 ...... 171 Figura 44. Pruebas de funcionamiento P009, P010, P011 ...... 172 Figura 45. Pruebas de funcionamiento P012, P013, P014, P015, P016 ...... 172

LISTA DE TABLAS

Tabla 1. Ejemplo técnica SQA: Metodología RUP ...... 12 Tabla 2. Ejemplo técnica Q3 ...... 14 Tabla 3. Ejemplo técnica SQA: Metodología RUP ...... 25 Tabla 4. Historias de usuario ...... 31 Tabla 5. Parámetros del recurso POST statuses/update ...... 34 Tabla 6. Parámetros del recurso GET statuses/show:id ...... 38 Tabla 7. Parámetros del recurso GET statuses/show:id ...... 42 Tabla 8. Operadores de consulta ...... 43 Tabla 9. Interfaces de usuario plugin Twitter Integration ...... 69 Tabla 10. Interfaces de usuario plugin Facebook Integration ...... 74 Tabla 11. Historia de usuario 1: Crear nueva instancia del plugin Twitter Integration ...... 94 Tabla 12. Historia de usuario 2: Editar configuración de instancia del plugin Twitter Integration ...... 94 Tabla 13. Historia de usuario 3: Eliminar instancia del plugin Twitter Integration ...... 95 Tabla 14. Historia de usuario 4: Listar las interacciones en la instancia ...... 96 Tabla 15. Historia de usuario 5: Asignar calificaciones a las interacciones ...... 96 Tabla 16. Historia de usuario 6: Visualizar una calificación ...... 97 Tabla 17. Historia de usuario 7: Componer un nuevo tweet ...... 98 Tabla 18. Historia de usuario 8: Listar los hashtags utilizados ...... 98 Tabla 19. Historia de usuario 9: Crear nueva instancia del plugin Facebook Integration .... 100 Tabla 20. Historia de usuario 10: Editar configuración de instancia del plugin Facebook Integration ...... 100 Tabla 21. Historia de usuario 11: Eliminar instancia del plugin Facebook Integration ...... 101 Tabla 22. Historia de usuario 12: Listar las interacciones en la instancia Facebook Integration ...... 102 Tabla 23. Historia de usuario 13: Asignar calificaciones a las interacciones ...... 102 Tabla 24. Historia de usuario 14: Visualizar una calificación ...... 103 Tabla 25. Historia de usuario 15: Componer un nuevo post ...... 103 Tabla 26. Historia de usuario 16: Instalación de plugins ...... 104 Tabla 27. Historia de usuario 17: Actualización de plugins ...... 105 Tabla 28. Historia de usuario 18: Desinstalación de plugins ...... 105 Tabla 29. Especificación pruebas de funcionamiento...... 168

xii

LISTA DE CÓDIGOS

Código 1. Ejemplo de solicitud recurso POST statuses/update ...... 37 Código 2. Ejemplo de solicitud recurso GET statuses/show/:id ...... 41 Código 3. Ejemplo de solicitud recurso GET search/tweets ...... 48 Código 4. Ejemplo solicitud HTTP GET de Graph API ...... 50 Código 5. Ejemplo solicitud HTTP GET de Graph API con parámetros ...... 51 Código 6. Ejemplo solicitud para publicar con HTTP POST de Graph API ...... 52 Código 7. Eliminar nodos con DELETE de Graph API ...... 52 Código 8. Ejemplo de nombres de variables correctos e incorrectos ...... 121 Código 9. Ejemplo de código correcto sin sangrado en el nivel principal ...... 121 Código 10. Ejemplo de código incorrecto con sangrado en el nivel principal ...... 121 Código 11. Ejemplo de definición de una constante ...... 121 Código 12. Ejemplo de función definida correctamente ...... 122 Código 13. Ejemplo correcto de bloque de código ...... 122 Código 14. Ejemplo de definición de cadenas ...... 122 Código 15. Ejemplo de comentarios de línea y de párrafo ...... 123 Código 16. Ejemplo de uso de espacios ...... 123 Código 17. Ejemplo de uso de clone() ...... 124 Código 18. Ejemplo de definición de capacidades ...... 129 Código 19. Nombre de capacidad en el archivo de idioma del plugin ...... 130 Código 20. Obtención de instancia mediante ID de objeto ...... 130 Código 21. Obtención de instancia mediante ID de contexto ...... 130 Código 22. Ejemplo función has_capability() ...... 131 Código 23. Ejemplo función require_capability() ...... 131 Código 24. Ejemplo función require_login () ...... 131 Código 25. Importar objeto global $DB ...... 132 Código 26. Sentencia get_record() ...... 132 Código 27. Sentencia get_record_sql() con el nombre de la tabla entre llaves ...... 132 Código 28. Sentencia get_record() con parámetros en matrices ...... 132 Código 29. Sentencia get_record_sql() con $params...... 133 Código 30. Sentencias para obtener un solo registro ...... 133 Código 31. Sentencias para obtener varios registros ...... 134 Código 32. Sentencias para obtener datos llave/valor en un array asociativo ...... 134 Código 33. Sentencias para comprobar si existe un registro ...... 135 Código 34. Sentencias para eliminar registros ...... 135

xiii

Código 35. Sentencias para ingresar registros...... 135 Código 36. Sentencias para actualizar registros ...... 136 Código 37. Crear clase para un formulario ...... 137 Código 38. Crear instancia de formulario ...... 138 Código 39. Configuración de página mediante Page API ...... 139 Código 40. Cadena de texto ...... 140 Código 41. Función get_string() ...... 141 Código 42. Funciones de rating_manager ...... 142 Código 43. Ejemplo de fichero access.php ...... 145 Código 44. Ejemplo de fichero install.xml ...... 147 Código 45. Ejemplo de fichero upgrade.php ...... 149 Código 46. Fichero que contiene cadenas de texto del plugin ...... 149 Código 47. Fichero que contiene cadenas de texto del plugin ...... 150 Código 48. Función get_string() ...... 150 Código 49. Funciones básicas de lip.php ...... 151 Código 50. Fichero mod_form.php del plugin certificate ...... 152 Código 51. Fichero view.php ...... 154

xiv

RESUMEN

En el presente trabajo se presenta los resultados obtenidos del desarrollo de una herramienta de socialización y discusión de temas en un entorno virtual de aprendizaje Moodle, utilizando redes sociales e implementando estrategias didácticas que resalten los aspectos y beneficios del aprendizaje colaborativo y social. La herramienta desarrollada son dos plugin para Moodle que permite combinar las funcionalidades típicas de una red social en un entorno virtual. Los plugins le agrega a Moodle la capacidad de presentar los tweets (Twitter) y post (Facebook) que los estudiantes y profesores envíen referente a un tema, que previamente debe estar especificado en una actividad dentro de un curso.

PALABRAS CLAVES: red, social, entorno, aprendizaje, virtual, moodle, plugin, twitter, facebook

ABSTRACT

This paper presents the results of the development of a tool for socialization and discussion of topics in a virtual learning environment Moodle, using social networks and implementing teaching strategies that emphasize the aspects and benefits of collaborative and social learning. The tool developed is two plugins for Moodle that combines the functionality of a typical social network in a virtual environment. The Moodle plugin adds the ability to present the tweets (Twitter) and post (Facebook) that students and teachers sent concerning a subject which must be previously specified in an activity within a course.

KEYWORDS: network, social, environment, learning, virtual, moodle, plugin, twitter, facebook

INTRODUCCIÓN

El avance y surgimiento de nuevas tecnologías web 2.0 y especialmente de redes sociales han permitido la interacción y comunicación entre las personas, generando un intercambio de información en donde los usuarios son los actores principales de su desarrollo.

El uso exponencial de las redes sociales se debe a la posibilidad que tienen las personas para comunicarse y compartir información en un ambiente en el que se sienten cómodos.

La utilización de redes sociales en un entorno virtual de aprendizaje está sustentado en las teorías del aprendizaje socio-constructivismo y conectivismo, que se fundamentan en la interacción entre profesores y estudiantes para la generación de nuevos contenidos (socio- constructivismo) a través de medios sociales abiertos (conectivismo). Esta relación entre pares (nodos) se viene implementando de distintas formas y a través de diferentes medios sociales. Las estrategias didácticas que se pueden aplicar varían y dependen de la metodología que se aplique

La aplicación de redes sociales en entornos virtuales de aprendizaje incluyendo estrategias didácticas, como la SQA1, pretende potencializar su uso con el propósito de generar un ambiente de aprendizaje colaborativo-social, en donde se fundamente el esfuerzo conjunto y la interacción de todos los participantes, en busca de generar nuevos conocimientos.

Este trabajo describe el desarrollo de una herramienta de socialización y discusión de temas en un entorno virtual de aprendizaje Moodle, utilizando redes sociales e implementando estrategias didácticas que resalten los aspectos y beneficios del aprendizaje colaborativo y social.

Descripción del proyecto

El presente proyecto pretende potencializar el uso de las redes sociales dentro de un Entorno Virtual de Aprendizaje (EVA), incluyendo además estrategias didácticas, con el propósito de generar un ambiente de aprendizaje colaborativo-social. Por ello, el desarrollo del proyecto se basa en el actual Entorno Virtual de Aprendizaje de la UTPL, implementado en la plataforma Moodle.

En primer lugar se realizó un profundo estudio de la plataforma Moodle, tanto en sus funciones generales, entorno técnico, estructura y funcionamiento (ANEXO B: MOODLE

1 Técnica SQA: Estrategia de enseñanza-aprendizaje que permite incorporar nuevos conocimientos en las estructuras de conocimiento de los estudiantes. 3

SISTEMA DE GESTIÓN DE APRENDIZAJE) como en su capacidad de incrementar funcionalidades a través de la utilización de sus diferentes API‟s2 (ANEXO C: MOODLE DEVELOPERS). Dado que se pretende utilizar redes sociales como herramientas dentro del EVA, se llevó a cabo una investigación sobre las respectivas API‟s de las redes sociales Twitter y Facebook, que serán utilizadas conjuntamente con las API‟s de Moodle para el desarrollo del presente proyecto. Dado que Moodle está implementado con el lenguaje de programación PHP, se decidió desarrollar los nuevos plugins sobre este mismo lenguaje y cumpliendo con las normas establecidas de desarrollo de Moodle.

Objetivo General.

 Utilizar las redes sociales Twitter y Facebook como herramienta de socialización y discusión de temas en el Entorno Virtual de Aprendizaje Moodle.

Objetivos Específicos.

 Diseñar y desarrollar un componente para la plataforma Moodle que permita interactuar entre el EVA y la red social Twitter.  Diseñar y desarrollar un componente para la plataforma Moodle que permita la interacción entre el EVA y la red social Facebook.  Incorporar una pasarela entre Moodle-Twitter y Moodle-Facebook que permita calificar las interacciones que se realicen dentro de un curso.

Resultados Esperados.

 Plugins de actividades para Moodle versión 1.9 y 2.6

Este trabajo se presenta en tres capítulos diseñados para el desarrollo de la herramienta de socialización y discusión de temas. En el primer capítulo se describe el Estado del Arte como una introducción a los conceptos relacionados con el aprendizaje colaborativo, estrategias didácticas y el uso de redes sociales en entornos virtuales de aprendizaje. En el segundo capítulo se detalla el Estado Actual del Entorno Virtual de Aprendizaje de la UTPL, y se presenta el diseño de la solución propuesto. El tercer capítulo describe el desarrollo e implementación de la solución y su integración en la plataforma Moodle. Finalmente se recogen las conclusiones y recomendaciones.

2 API: Acrónimo en inglés de Application Programming Interface, y traducido al español como Interfaz de programación de aplicaciones 4

CAPÍTULO 1: ESTADO DEL ARTE

1.1. Introducción.

En este apartado revisaremos una serie de conceptos teóricos relacionados con las estrategias didácticas para el proceso de enseñanza-aprendizaje y la implementación de redes sociales en la educación superior. En primer lugar se describirá brevemente el concepto de aprendizaje, sus teorías, y más específicamente el aprendizaje colaborativo. A continuación se procederá a definir algunas estrategias didácticas usadas para la enseñanza en entornos virtuales, o plataformas de enseñanza virtual. Y por último se describirá el uso y la influencia de las redes sociales como entornos virtuales de aprendizaje.

1.2. Aprendizaje.

Según el diccionario enciclopédico Reader's Digest la palabra aprender proviene del latín apprehendère: de ad, a, y pprehendère, percibir, y se define como “adquirir conocimientos por medio del estudio o experiencia, conjeturar; tomar algo en la memoria” (READER'S DIGEST, 1972)

Según (Shuell, 1990) el aprendizaje “es un cambio perdurable en la conducta o en la capacidad de comportarse de una determinada manera, la cual resulta de la práctica o de alguna otra forma de experiencia”

1.2.1. Teorías del Aprendizaje.

Según Peggy Ertmer y Timothy Newby (Ertmer & Newby, 1993) las teorías del aprendizaje son “una fuente de estrategias, tácticas y técnicas de instrucción verificadas”. Debido a esto el conocimiento de este tipo de estrategias es fundamental para determinar cuál técnica o estrategia corresponde mejor en un determinado contexto. Saber determinar cuándo y por qué se emplea cada una es altamente importante. Las teorías del aprendizaje más ampliamente difundidas son: conductismo, cognitivismo y constructivismo.

Según el conductismo, el aprendizaje es un cambio de comportamientos que se basa en la adquisición de conocimientos, que el experto transmite de la forma más clara y directa posible, utilizando sistemas de reforzamiento positivo y negativo, para que el receptor los asimile, mostrándolos en conductas reales (Koyanagi, 1999). El aprendizaje se logra medir cuando existe una respuesta adecuada luego de que el experto instructor transmite la presentación de un estímulo ambiental específico. En el contexto de esta teoría la memoria

no es tomada en cuenta, es decir, el olvido de un tema en particular se atribuye a falta de uso de una respuesta (Ertmer & Newby, 1993).

El cognitivismo se centra en la percepción, el pensamiento y la memoria humana, por lo que a menudo toma un modelo de procesamiento de información como si fuera computadora. El aprendizaje es visto como un proceso de entradas, administradas en la memoria a corto plazo, y se codifica para una recuperación a largo plazo. En este contexto se considera a los estudiantes como procesadores activos de información, teniendo en cuenta el conocimiento y bagaje previos que éstos disponen (Gros, 1995). En los modelos cognitivos de aprendizaje, el conocimiento depende de la interacción entre la información presentada al sujeto y los conocimientos previos que éste posee. El énfasis de esta teoría reside en enfatizar procesos cognitivos más complejos, tales como: el pensamiento, la solución de problemas, el lenguaje, la formación de conceptos y el procesamiento de la información (Ertmer & Newby, 1993)

El constructivismo educativo propone un paradigma en donde el proceso de enseñanza se percibe y se lleva a cabo como un proceso dinámico, participativo e interactivo del sujeto, es decir, sugiere que los aprendices crean conocimiento mientras tratan de comprender sus experiencias. En otras palabras, el conocimiento es una función de cómo el individuo crea significados a partir de sus propias experiencias (Ertmer & Newby, 1993).

La limitación central de estas tres teorías (Siemens, 2005), se basa en que el aprendizaje se produce en el interior de la persona; no toma en cuenta el conocimiento y el aprendizaje que se genera y es manipulado por la tecnología. El aprendizaje puede residir fuera de la persona, es decir, dentro de medios electrónicos o digitales, dentro de una base de datos o inclusive en una organización, es así que propone la teoría del conectivismo, impulsado por el aprendizaje definido en un contexto de conectar diversas fuentes de información.

Las teorías del conductismo, cognitivismo y constructivismo han sido desarrolladas en un momento en el que la tecnología no afectaba al aprendizaje, es decir, en las últimas décadas, las Tecnologías de la Información y Comunicación (TIC) han revolucionado nuestro diario vivir, han cambiado nuestra manera de comunicarnos, de socializar, de trabajar, incluyendo el aprendizaje.

La teoría del conectivismo tiene como sustento la interacción a través de diferentes medios sociales abiertos, donde los estudiantes y los profesores utilicen blogs, wikis y comunidades de aprendizaje para crear y construir conocimiento. El aprendizaje es un proceso de conectar nodos especializados o fuentes de información (Siemens, 2005).

Entre los principios importantes de la teoría del conectivismo están los siguientes (Siemens, 2005):

 El aprendizaje y el conocimiento descansa en la diversidad de opiniones.  El aprendizaje es un proceso de conectar nodos especializados o fuentes de información.  El aprendizaje puede residir en dispositivos no humanos.  El aprendizaje es más importante que lo que se conoce en la actualidad.  Cultivar y mantener las conexiones es necesaria para facilitar el aprendizaje continuo.  Capacidad de ver conexiones entre campos, ideas y conceptos es una habilidad básica.  La toma de decisiones es en sí mismo un proceso de aprendizaje.

Por lo tanto el conectivismo propicia un ambiente de aprendizaje donde las contribuciones y el conocimiento que generan los participantes, ya sea en forma de tweets, publicaciones en grupos de facebook, blogs, wiki, videos, etc., son indexadas por los profesores u organizadores y compartidas con todos los participantes, todo unido entre sí para crear un curso de red.

Según Marianela Falcón Villaverde (Falcón-Villaverde, 2013) los modelos cognitivo- conductista del aprendizaje surgieron en un entorno tecnológico desde la comunicación restringida a la pre-Web; el socio-constructivismo floreció en una Web 1.0, en un contexto tecnológico de muchos-a-muchos; y el conectivismo es, al menos parcialmente, un producto de la red, el mundo de la Web 2.0.

1.2.2. Aprendizaje colaborativo

El aprendizaje colaborativo según (Johnson, Johnson, Holubec, & Roy, 1993) “es el uso instruccional de pequeños grupos de tal forma que los estudiantes trabajen juntos para maximizar su propio aprendizaje y el de los demás”.

El aprendizaje colaborativo es un sistema de interacciones en el que, a partir del trabajo conjunto y la formulación de un objetivo específico, se genera una construcción social del conocimiento (Guitert & Giménez, 2000).

La construcción social del conocimiento es un proceso de tres etapas (Rebollo, 2007):

1. Creación de nuevos conocimientos, es colectiva 8

2. Socialización y desarrollo, supone aproximarse a conocimientos acumulados 3. El aprendizaje se apoya en el esfuerzo conjunto y la interacción con otros

El desarrollo de nuevas tecnologías y su utilización en procesos educativos proporcionan ventajas significativas al proceso de aprendizaje colaborativo:

 Estimulan la comunicación interpersonal  Facilitan el trabajo colaborativo  Posibilita el seguimiento del progreso  Acceso a información y contenidos de aprendizaje  Permite la evaluación a los participantes

1.3. Estrategias didácticas en entornos virtuales de aprendizaje.

Entre los grandes cambios que establecen los avances de las Tecnologías de la Información, podemos señalar sobre todo, que la Web se ha convertido en un recurso de apoyo, de extensión o de sustitución a los esquemas tradicionales de enseñanza o aprendizaje. Muchos establecimientos de educación superior han optado por impartir una parte de la instrucción académica de manera presencial y otra parte en la Web, y algunos establecimientos llevan a cabo todo el proceso de aprendizaje en la web; ambas modalidades a través de plataformas educativas, más comúnmente denominados Entornos Virtuales de Aprendizaje (EVA).

Según el Dr. Rafael Bello Díaz (Bello Díaz, 2005) un Entorno Virtual de Aprendizaje es una “aula sin paredes” cuyo mejor exponente actual es la red Internet, no es presencial, sino representacional, no es proximal, sino distal, no es sincrónico, sino asíncrono, y no se basa en recintos espaciales con interior, frontera y exterior, sino que depende de redes electrónicas cuyos nodos de interacción pueden estar diseminados por diversos países.

Las características básicas e imprescindibles que cualquier plataforma EVA debería tener, son las siguientes (Boneu, 2007):

 Interactividad: Conseguir que la persona que está usando la plataforma tenga conciencia de que es el protagonista de su formación.  Flexibilidad: Conjunto de funcionalidades que permiten que el sistema de e-learning tenga una adaptación fácil en la organización donde se quiere implantar, en relación a la estructura institucional, los planes de estudio de la institución y, por último, a los contenidos y modelos pedagógicos de la organización.

 Escalabilidad: Capacidad de la plataforma de funcionar igualmente con un número pequeño o grande de usuarios.  Estandarización: Capacidad de utilizar cursos realizados por terceros; de esta forma, los cursos están disponibles para la organización que los ha creado y para otras que cumplen con el estándar

Además de las características básicas enumeradas, existen otras características generales de las plataformas de e-learning, las cuáles igualmente deben ser valoradas (Belloch Ortí):

 Características técnicas

o Tipo de licencia: Propietaria, gratuita y/o código abierto. o Idioma: Disponibilidad de un soporte para la internacionalización. o Sistema operativo y tecnología empleada: Compatibilidad con el sistema de la organización. o Documentación: Apoyo sobre la propia plataforma dirigida a los diferentes usuarios de la misma. o Comunidad de usuario: La plataforma debe contar con el apoyo de comunidades dinámicas de usuarios y técnicos.

 Características pedagógicas: Disponer de herramientas y recursos que permitan realizar tareas de:

o Realizar tareas de gestión y administración. o Facilitar la comunicación e interacción entre los usuarios. o El desarrollo e implementación de contenidos. o La creación de actividades interactivas. o La implementación de estrategias colaborativas. o La evaluación y el seguimiento de los estudiantes. o Que cada estudiante pueda personalizar el entorno adaptándolo a sus necesidades y características.

El modelo de aprendizaje que propone un Entorno Virtual de Aprendizaje es de manera colaborativo, en donde el conocimiento es generado entre todos los participantes y en donde el rol del profesor se modifica, de solo ser un transmisor de conocimiento a los alumnos, a ser un facilitador en la construcción del propio conocimiento de estos.

Las estrategias didácticas se definen como las tareas y actividades que pone en marcha el docente de forma sistemática para lograr unos determinados objetivos de aprendizaje en los estudiantes (Rodríguez & García, 2007).

Didáctica se define como la técnica que se emplea para manejar, de la manera más eficiente y sistemática, el proceso de enseñanza-aprendizaje (De la Torre, 2005)

Las estrategias didácticas contemplan las estrategias de aprendizaje las cuáles son un conjunto de habilidades que un estudiante adquiere para aprender, y las estrategias de enseñanza que son todas aquellas ayudas planteadas por el docente para hacer posible el aprendizaje de sus alumnos (Díaz & Hérnandez, 1999).

A continuación se aprecia una selección de estrategias didácticas aplicables a entornos virtuales de aprendizaje (Delgado & Solano, 2009):

 Glosarios colaborativos: En lugar de que el facilitador realice un glosario solo, inste a sus estudiantes a que lo vayan construyendo a medida que encuentran términos desconocidos.  Subgrupos de discusión: Dividir el grupo en subgrupos de 4 ó 5 personas, y se les propone un tema que debe ser analizado desde diferentes perspectivas. Luego exponer sus conclusiones en foros  Recuperación de información y juego de roles: Consiste en asignar al estudiante la investigación y análisis de un determinado tema y abrir un espacio con la herramienta taller para que cada estudiante exponga su trabajo ante los demás compañeros  Lluvia de ideas: Se puede utilizar para la apertura de foros de diagnóstico o introducción de un tema en particular  Portafolio: Utilizando la herramienta WIKI cada alumno dispondrá de un espacio de acceso personal y en torno a la resolución de actividades generales irán creando nuevas páginas en su wikicuaderno personal.

1.3.1. Técnica SQA.

La técnica SQA, desarrollada por Donna (Ogle, 1986) es una estrategia que permite motivar a los alumnos a construir sentido (Marzano & Pickering, 2005), primero ahondando en los conocimientos previos que posee el estudiante, para después, exponer cuáles son los conocimientos que desea adquirir, y finalmente, para comprobar que la información recibida

ha generado conocimientos y ha solventado las necesidades de aprendizaje (Pimienta, 2012).

Entre las principales ventajas al usar esta técnica, destacan las siguientes (Pinto de Beleño, 2010):

 Ayuda a integrar el conocimiento previo al nuevo.  Motiva al desarrollo conceptual.  Apoya el aprendizaje colaborativo.  Hace posible que el aprendizaje sea significativo.  Desarrolla habilidades de lectura crítica.  Enriquece la lectura, la escritura y el pensamiento.  Promueve la metacognición (mejorar las actividades y las tareas intelectuales que uno lleva a cabo usando la reflexión para orientarlas).  Permite el uso de la “tecnología” para buscar y usar información.  Promueve una autoestima positiva porque se vuelven expertos/as acerca de lo que han aprendido.

Consta de tres etapas:

1. Lo que sé: Son los organizadores previos, lo que el estudiante conoce acerca del tema. 2. Lo que quiero saber: Dudas e inquietudes que el estudiante tiene sobre el tema. 3. Lo que aprendí: Permite verificar el aprendizaje obtenido.

Se puede apreciar mejor la definición de la técnica SQA con el siguiente ejemplo sobre la metodología de desarrollo RUP:

Tabla 1. Ejemplo técnica SQA: Metodología RUP Que sé Lo que Quiero saber Lo que Aprendí  RUP es desarrollado  ¿Cuáles son las  Mantiene un flujo de por la empresa disciplinas que trabajo del proceso y de Rational Software involucra y sus soporte del proyecto.  RUP es una respectivas etapas?  Etapas del flujo de metodología de  ¿Cuáles son las proceso: Modelado de desarrollo de software fases del ciclo de negocio, Requisitos,  Se caracteriza por ser vida? Análisis y Diseño, iterativo e incremental  ¿Cuáles son los Implementación,

principios de Pruebas, Despliegue desarrollo?  Etapas del flujo de  ¿Cuáles artefactos proceso: Gestión del incluye? cambio y configuraciones, Gestión del proyecto, Entorno  Las fases que componen RUP son: Inicio, Elaboración, Construcción y Cierre  Principios: Adaptar al proceso, Equilibrar prioridades, Demostrar valor iterativamente, Colaboración entre equipos, Elevar el nivel de abstracción, Enfocarse en la calidad  Artefactos: Documento de visión, Especificación de requerimientos, Diagramas de caso de uso, Diagrama de clases, Modelo E-R, Diagramas de secuencia, de estados, de colaboración; Modelo de dominio, Mapa de comportamiento nivel HW Fuente: Autor

1.3.2. Técnica Q3.

Es una estrategia que nos permite descubrir las relaciones de las partes de un todo, entorno o tema a partir de un razonamiento crítico, creativo e hipotético (Silverman, 2006).

1. Que veo: Es lo que el estudiante observa, conoce o reconoce del tema. 2. Que no veo: Es aquello que explícitamente no está en el tema, pero que puede estar incluido. 3. Que infiero: Lo que el estudiante deduce de un tema.

Mediante el uso de esta técnica se pueden apreciar algunas ventajas:

 Desarrolla la creatividad.  Aplica un razonamiento analítico, hipotético y deductivo.  Presentar una actitud crítica ante lo que se le presenta.

En el siguiente ejemplo (Pimienta, 2008), se puede demostrar cómo funciona la técnica Q3, se debe leer el contenido del texto expuesto y proceder a escribir los resultados:

HALLOWEN: “La noche de brujas”

Esta costumbre va más lejos de una simple fiesta de disfraces, de fabricar calaveras con una caja de zapatos y una vela adentro. Es una de las máximas celebraciones al dios de la muerte en todo el mundo. Esta costumbre tiene su origen en los Celtas, pueblo europeo anterior al cristianismo, cuyos sacerdotes llamados druidas, alababan y servían a la muerte. El día 31 de octubre celebran el festival de Samhait o “Señor de los muertos”. Creían que Samhait permitía a las almas de los difuntos regresar a sus casas esa noche. Los sacerdotes druidas ascendían a lo más alto de las colinas para encender grandes fogatas. Se vestían con disfraces de pieles y cabezas de animales; ofrecían sacrificios quemando a seres humanos, animales y cosechas, usando los restos para predecir la suerte del año por empezar. Las víctimas humanas que sacrificaban los druidas al dios de la muerte, eran vírgenes o niñas que ofrecían las familias celtas. Los druidas pasaban por las casas solicitando víctimas; si los familiares accedían a la entrega, los sacerdotes dejaban una fruta con una vela en su interior, la cual prevenía la entrada de los demonios en la casa durante la noche y evitaban, así, la muerte de los que allí vivían. Si la familia se negaba, entonces la puerta de la casa se marcaba y Satán podría entrar a destrozarlos.

Tabla 2. Ejemplo técnica Q3 Qué veo Qué no veo Qué infiero  Proviene o tiene su  La relación de esta  Actualmente está origen en los celtas. celebración con celebración se basa en  Los sacerdotes que nuestras tradiciones. el consumismo. celebraban se  Vínculos con las  La celebración ha

llamaban druidas. religiones actuales. perdurado debido a la  Veneraban a Samhait.  La difusión del difusión de los medios significado de de comunicación. Halloween en la sociedad. Fuente: (Pimienta, 2008)

1.4. Redes sociales en Entornos Virtuales de Aprendizaje.

La web 2.0 se debe de considerar como un espacio destinado al cambio de modelo en los procesos de aprendizaje (Esteve, 2009). En donde el proceso de aprendizaje es el resultado de la interacción y colaboración entre las personas, en donde el alumno es el actor principal de su propio aprendizaje (Michavila & Parejo, 2008). El profesor cambia su rol y centra su trabajo en desarrollar ambientes propicios para que los alumnos lleven a cabo los aprendizajes colaborativos (Ayerdi, Pérez, & Mendiguren, 2011).

La web 2.0 se puede definir como un conjunto de tecnologías destinada para la creación social del conocimiento, incorporando tres características esenciales: tecnología, conocimientos y usuarios (Freire, 2007). Se caracteriza además por buscar y generar un ambiente de creación colectiva de contenidos, el establecimiento de recursos compartidos y el control de la calidad de forma colaborativa entre todos los participantes (Ribes, 2007).

La creciente y gran popularidad de las redes sociales está cambiando la manera en que la sociedad y su ritmo cotidiano se desenvuelven. La educación no se escapa de esta tendencia y se convierte en una necesidad el investigar sus potencialidades aplicados al mundo académico universitario (Ayerdi, Pérez, & Mendiguren, 2011).

Como menciona Herrera (2013) las redes sociales se han convertido en un medio por el cual los estudiantes interactúan, se comunican y no sólo comparten fotografías, videos, enlaces, etc., sino que además son utilizadas para coordinar tareas, trabajos compartir documentos y materiales de investigación destinados a las actividades diarias de un estudiante universitario.

En este contexto José Luis Orihuela (Orihuela, 2009) menciona algunas ventajas con el uso de las redes sociales:

 Permiten generar nuevas sinergias entre los miembros de una comunidad educativa.

 Facilitan la circulación de información, la organización de eventos, el compartir recursos.  Proyectan y consolidan las relaciones interpersonales una vez que se han terminado los estudios.

Juan José de Haro (Haro, 2009) atribuye tres ventajas adicionales al uso de las redes sociales en el ámbito docente:

 Minimizan la necesidad de formación porque todos usan el mismo recurso.  Favorecen la comunicación con los alumnos de manera bidireccional, ya que el profesorado y alumnado se encuentran en un mismo espacio.  Su carácter generalista posibilita el uso universal de las mismas.

1.4.1. Estadísticas de uso de internet y redes sociales en Ecuador

En Ecuador, en el año 2012 el 36% de las personas usan internet como fuente de información, mientras el 28,2% lo utiliza como canal de comunicación.

Figura 1. Razones de uso de Internet Fuente: (Encuesta Nacional de Empleo Desempleo y Subempleo - ENEMDUR, 2012)

El 59,8% de las personas que usa Internet lo hacen por lo menos una vez al día, seguidos de los que por lo menos lo utilizan una vez a la semana con el 35,3%.

Figura 2. Frecuencia de uso de Internet - Nacional Fuente: (Encuesta Nacional de Empleo Desempleo y Subempleo - ENEMDUR, 2012)

Las redes sociales más utilizadas en Ecuador, en el período comprendido entre Mayo-2013 / Mayo-2014 son Facebook y Twitter.

Figura 3. Redes sociales en Ecuador, período Mayo-2013 / Mayo-2014 Fuente: (StatCounter, 2014)

En el período Febrero – Julio 2014 se puede apreciar las siguientes estadísticas de uso de Facebook en Ecuador:

 Los usuarios de Facebook mayores de 18 años representan el 78.3% del total, en comparación con el 77.9% del periodo anterior  El grupo de edad más numeroso actualmente es 18-24, seguido por los usuarios que se encuentran en el rango de 25-34.

 El segmento de Edad/Sexo más popular es Hombres 18-24 con 19.2% de cuota mercado  El segmento Edad/Sexo con el crecimiento mayor ha sido Mujeres 45-54 con un 7.5%  El segmento demográfico Edad con mayor crecimiento en los últimos 6 meses ha sido 45-54 con un incremento del 6.1%

Figura 4. Uso de facebook por sexo de los fans - edad (Febrero – Julio 2014) Fuente: (All In One Social, 2014)

1.4.2. Uso de redes sociales como entornos educativos

Existen algunos estudios y experiencias resultantes de la utilización de redes sociales como entornos educativos. Podemos citar a Adán Griego (2011) con su ponencia titulada “Facebook como aula virtual alternativa”, en donde se utilizan las imágenes con texto como presentaciones para impartir una clase y generar aprendizaje. De entre las ventajas de utilizar Facebook como aula virtual se mencionan los siguientes:

 Facebook posee un número elevado de usuarios activos.  Facebook es un espacio conocido por los alumnos, por tanto la curva de aprendizaje es casi nula.  Posee un atractivo visual.  La posibilidad que ofrece Facebook para conformar grupo de usuarios.

Entre las desventajas resultantes de esta propuesta se destacan las siguientes:

 Explicar el nuevo uso de Facebook, como herramienta que permite la interacción y la generación de conocimientos entre los alumnos.  Privacidad entre los alumnos y los profesores.  Cambios constantes en Facebook.

Stephen (Downes, 2011) plantea una propuesta que analiza los beneficios, los riegos y las desventajas de las redes sociales como entornos educativos. La propuesta se titula “Social Network Technologies for Learning”. En este trabajo se propone el uso de redes sociales en la educación en donde la interacción no se limite entre el docente y el alumno, sino que señala la participación de otros sectores extraescolares.

Alfonso (Quezada Viay, 2011) también expone una propuesta para la utilización de redes sociales en la educación, haciendo énfasis en aprovechar la posibilidad de crear grupos en Facebook y utilizarlo como aula virtual.

El uso de las redes sociales entre los alumnos para interactuar y generar acuerdos sobre actividades escolares, demuestra que no existe una “línea de separación” entre los procesos de socialización y las actividades escolares, puesto que el proceso educativo es, por naturaleza un proceso comunicativo y de socialización (Herrera, 2013)

1.5. Herramientas de socialización y discusión.

En este apartado revisaremos las principales características de las plataformas Twitter y Facebook, las cuáles serán utilizadas como herramientas para la socialización y discusión de temas dentro de un curso, para que luego puedan ser indexados y abiertos desde la plataforma Moodle para la valoración y calificación por parte del docente.

1.5.1. Twitter

Twitter es una red social online y servicio de microblogging que permite a los usuarios enviar y leer tweets, los cuáles son mensajes de texto con una longitud máxima de 140 caracteres.

Twitter fue creada por Jack Dorsey, Evan Williams, Biz Stone and Noah Glass en Marzo de 2006, y el sitio web funcional fue lanzado en Julio de 2006.

Entre los conceptos básicos, podemos citar los siguientes:

 Tweet: Cada Tweet debe contener máximo 140 caracteres, puede contener fotos o videos, además de enlaces de noticias, blogs, sitios web y aplicaciones. 19

 Nombre de usuario: Un @nombre de usuario en una identidad única en Twitter, por la cual se pueden realizar menciones o enviar mensajes.  #Etiqueta: Una etiqueta o hashtag es cualquier palabra o frase precedida por el símbolo #. Este símbolo convierte a la palabra en un enlace, a través del cual es más fácil encontrar y seguir una conversación sobre ese tema.  Responder: Se pueden establecer conversaciones con otras personas al contestar sus Tweets.  Retweet: Hacer un retweet significa compartir el Tweet de otra persona a todos los seguidores que se posee en una cuenta propia.  Favorito: Marcar un Tweet como favorito es indicar y señalar que dicho Tweet posee algo especial, por lo que agrada y gusta  Mensaje privado: Un mensaje privado (también llamado DM o mensaje directo) es un Tweet privado entre dos personas que se siguen mutuamente.

1.5.2. Facebook.

Facebook es considerada como el sitio web de redes sociales más popular en el mundo. Facebook fue creado por Mark Zuckerberg y fundado junto a Eduardo Saverin, Chris Hughes y Dustin Moskovitz en Febrero del 2004

Facebook es un servicio que permite conectar a las personas en internet. Mantenerse en contacto con sus amigos y compartir con ellos mediante la Web.

Entre los servicios que ofrece, destacan los siguientes:

 Biografía: Tiene como objetivo agilizar y optimizar el paseo de los usuarios por los perfiles de todos los contactos, contiene publicaciones, actualizaciones de estado, comentarios, fotos, etc.  Lista de amigos: El usuario puede agregar a cualquier persona que conozca y esté registrada, siempre que acepte su invitación  Grupos: Tiene como objetivo reunir personas con intereses comunes. En los grupos se pueden añadir fotos, vídeos, mensajes, etc.  Páginas: Las páginas, se crean con fines específicos y a diferencia de los grupos no contienen foros de discusión, ya que están encaminadas hacia marcas o personajes específicos

 Me gusta: Se caracteriza por un pequeño ícono en forma de una mano con el dedo pulgar hacia arriba. Permite valorar si el contenido es del agrado del usuario actual en la red social

CAPÍTULO 2: ESTADO ACTUAL DEL EVA Y DISEÑO DE LA SOLUCIÓN

2.1. Estado actual del EVA

La Universidad Técnica Particular de Loja utiliza activamente la plataforma de enseñanza virtual Moodle, denominada Entorno Virtual de Aprendizaje (EVA), tanto para brindar formación académica a distancia (e-learning), como para reforzar su actividad presencial en un ambiente colaborativo y online (b-learning). Dentro del EVA se utilizan de manera intensiva los recursos integrados en Moodle, tales como, foros, exámenes, lecciones, tareas, glosarios, etc.; con el objetivo de generar conocimiento y aprendizaje en un ambiente colaborativo online.

La plataforma Moodle permite crear cursos en los formatos de temas y semanas, en ambos casos el EVA de la Universidad Técnica Particular de Loja presenta un modelo de microbloging, conocido como Moodle-glesone (Torres-Diaz, Jara, & Valdiviezo, 2013) que posibilita una interacción más fluida entre los estudiantes y los profesores, ya que permite brindar comentarios sobre algún tema que el profesor haya posteado. Sin embargo estas interacciones son solamente presentadas en el EVA y el modelo glesone no está posibilitado para realizar una conexión a través de medios sociales abiertos.

Se ha observado además una carencia de incluir estrategias didácticas, como la técnica SQA, mediante la interacción a través de medios sociales abiertos, a manera de mensajes en Twitter o post en Facebook; que luego puedan ser indexados en el sitio EVA para su posterior valoración, que a día de hoy no está cubierta por ningún módulo existente.

La asociación de los términos medios sociales abiertos y Entorno Virtual de Aprendizaje, generan un nuevo paradigma en el cual se debe encontrar el espacio necesario para para que los profesores y alumnos interactúen de manera informal en un ambiente de aprendizaje formal (Torres-Diaz, Jara, & Valdiviezo, 2013).

“Las redes sociales y el aprendizaje suponen el rompimiento de distintos paradigmas, uno de ellos quizá el más controversial es la mezcla de aprendizaje formal e informal en un mismo ambiente y con los mismos objetivos. La relación entre aprendizaje significativo e informal tiende a ser significativa debido a que al ser un conocimiento que se asocia a experiencias de vida, este pasa a formar parte de la estructura de conocimientos, aportando un sentido para el aprendiz.” (Torres-Diaz, 2012).

El aprendizaje informal se centra en la educación recibida fuera de las instituciones educativas tradicionales, en los conocimientos adquiridos de las experiencias vividas en el día a día (Marsick & Watkins, 1990). Cualquier forma de aprendizaje en donde el proceso no está determinado por alguna organización (Day, 1998). 23

El aprendizaje informal también se puede establecer cuando una persona interactúa en alguna actividad sin que exista un proceso definido y directo de enseñanza sino más bien el proceso de aprendizaje es espontáneo o autodirigido (Asensio & Pol, 2002).

John Falk y Lynn Dierking prefieren el término “aprendizaje de libre elección” (Falk & Dierking, 1992) debido a que la misma persona elige la mejor ruta para su aprendizaje, controlada por su motivación, voluntad e interés propio (Willard, 1993).

Un aspecto importante sobre el aprendizaje informal es el aprendizaje social (Rotter, 1954), el cual detalla que una persona dentro de una comunidad siempre tiende a aprender e imitar aquellos comportamientos que a su parecer sean de más beneficio para sus propósitos.

Como señala Rebeca Mejía (Mejía, 2005) muchos de los contenidos que se obtienen en un ambiente formal pasa muy pronto al “olvido” y además muy poco de ese aprendizaje es validado como importante y de soporte para el desempeño en el trabajo y en la vida (Valdés Sagüés, 1999). Es importante en este contexto que las estrategias de enseñanza “puedan ser retroalimentadas por el estudio de procesos naturales-culturales de aprendizaje”, apoyadas por el estudio del aprendizaje informal.

Según la teoría del conectivismo, revisada anteriormente, el aprendizaje está integrado con tecnologías de medios sociales abiertos. En este sentido se define un modelo de aprendizaje colaborativo social (Torres-Diaz, 2012) en el cual al integrarse las funcionalidades de una red social y un entorno virtual de aprendizaje, se debe hacer un cambio en la metodología a aplicar “contemplando actividades que utilicen y refuercen el uso de una red social como plataforma de intercambio de mensajes” (Torres-Diaz, 2012)

2.2. Diseño de la solución.

2.1.1. Plugin de actividad con integración de Twitter como herramienta de socialización y discusión: Twitter Integration.

El profesor de una asignatura podrá agregar una nueva actividad a su curso en el EVA, y configurarlo añadiendo la información básica de la actividad, adicionando un elemento clave: #hashtag o etiqueta, para que los tweets que los estudiantes envíen desde fuera de la plataforma propia del EVA, puedan ser indexados y puedan ser considerados dentro de la valoración y calificación que el docente emitirá. En esta etiqueta el profesor deberá incluir información sobre la estrategia didáctica que esté utilizando, por ejemplo:

Si utiliza la técnica SQA, el profesor deberá agregar tres actividades, ya que la técnica está conformada por tres partes. En primer lugar una actividad que refleje los conocimientos que el estudiante posee referente al tema que se esté tratando; en este caso la etiqueta deberá incluir la frase #LoQueSe.

La segunda actividad reflejará lo que el estudiante desea aprender acerca del tema en cuestión, en este caso la etiqueta contará con la frase #LoQueQuieroSaber

Por último, la tercera actividad permitirá verificar el aprendizaje que el estudiante ha obtenido, a través del conocimiento generado dentro de la asignatura, por ello la etiqueta incluirá la frase: #LoQueAprendi.

Podemos utilizar el ejemplo desarrollado en el capítulo anterior para ilustrar más detalladamente como se usará el plugin:

Tabla 3. Ejemplo técnica SQA: Metodología RUP Lo que sé Lo que sé en Twitter  RUP es desarrollado por la empresa #loquese #metrupUTPL #rup es Rational Software desarrollado por Rational Software  RUP es una metodología de #loquese #metrupUTPL #rup es una desarrollo de software metodología de desarrollo de software  Se caracteriza por ser iterativo e #loquese #metrupUTPL #rup es iterativo incremental e incremental Lo que quiero saber Lo que quiero saber en Twitter  ¿Cuáles son las disciplinas que #lqqs #metrupUTPL #RUP ¿Cuáles son involucra y sus respectivas etapas? las disciplinas que involucra y sus respectivas etapas?  ¿Cuáles son las fases del ciclo de #lqqs #metrupUTPL #RUP ¿Cuáles son vida? las fases del ciclo de vida? Lo que aprendí Lo que aprendí en Twitter  Mantiene un flujo de trabajo del #lqa #metrupUTPL #RUP mantiene un proceso y de soporte del proyecto. flujo de trabajo del proceso y de soporte del proyecto.  Las fases que componen RUP son: #lqa #metrupUTPL Las fases que Inicio, Elaboración, Construcción y componen #RUP son: Inicio, Elaboración, Cierre Construcción y Cierre Fuente: Autor

Ingresando a la actividad, el estudiante encontrará un espacio para poder enviar el tweet correspondiente desde el propio sitio Moodle, el uso del hashtag es opcional en este contexto. En cambio si prefiere utilizar cualquier otra aplicación que le permita enviar tweets, obligatoriamente deberá, en primer lugar modificar su perfil en la plataforma Moodle para incluir su @nombre de usuario en Twitter, y segundo el uso obligatorio del hashtag al momento de componer el Tweet.

El profesor, ingresando a la actividad, constatará todas las interacciones que los estudiantes han realizado hasta el momento, con la opción de valorarlas e incluir una nota que previamente deberá estar habilitada en la configuración de la actividad.

El estudiante, ingresando a la actividad en Moodle, podrá consultar todas las interacciones que se hayan desarrollado hasta el momento, al igual que podrá visualizar la calificación en caso de que el profesor la haya establecido.

2.1.1.1. Identificación de usuarios.

A continuación se describen los tres tipos de usuario que interactúan con el plugin Twitter Integration

 Administradores: El administrador podrá instalar y desinstalar el plugin de la plataforma Moodle. Cuenta además con las funcionalidades de los usuarios Alumno y Profesor.  Profesor: El profesor de un curso podrá añadir la actividad del plugin Twitter Integration, al curso respectivo y configurarlo a su medida. Podrá componer un nuevo tweet, revisar todas las interacciones en la actividad, revisar los hashtags empleados, establecer y visualizar calificaciones a las interacciones.  Alumno: El alumno podrá componer un nuevo tweet, revisar todas las interacciones en la actividad, revisar los hashtags utilizados y visualizar la calificación en caso de que el profesor la haya establecido.

2.1.1.2. Requisitos

Los requisitos listados a continuación son la base del desarrollo del proyecto, ya que indican la forma y funcionalidad del plugin Twitter Integration.

 Permitir al profesor o administrador crear una nueva actividad del plugin Twitter Integration.  El profesor o administrador podrán configurar la actividad dentro del curso.

 Permitir al profesor o administrador eliminar una actividad del plugin Twitter Integration.  Desarrollar un espacio desde donde se pueda componer un nuevo tweet hacia la plataforma Twitter. Cualquier usuario registrado tiene permitido realizar esta acción.  Los usuarios registrados podrán visualizar las interacciones dentro de la actividad, es decir, los tweets que han sido indexados por el plugin.  Permitir al profesor o administrador emitir una calificación hacia determinada interacción (tweet).  Los usuarios profesor y administrador podrán visualizar la calificación de cualquier interacción dentro de la actividad.  Un alumno podrá visualizar la calificación obtenida de su interacción, siempre y cuando ésta haya sido establecida previamente.  Desarrollar un espacio en donde se visualice los hashtag que se han utilizado dentro de la actividad.

2.1.2. Plugin de actividad con integración de Facebook como herramienta de socialización y discusión: Facebook Integration.

Para usar este módulo, previamente se deberá establecer un grupo en la plataforma Facebook, donde los participantes sean el(los) profesor(es) y los estudiantes del curso en el cuál se va a introducir una nueva actividad del módulo

Una vez establecido el grupo en Facebook, el profesor podrá agregar una nueva actividad a su curso, y configurarlo añadiendo la información necesaria de la misma. La descripción de la actividad se publicará en el grupo de Facebook como un nuevo post.

El profesor y estudiante, tendrán un espacio en donde puedan publicar un nuevo post, el cuál se enviará al grupo de Facebook como un comentario a la publicación, que previamente ha sido creado al momento de agregar una nueva actividad..

Todos los post que se han enviado desde la plataforma Moodle, podrán ser visualizados conjuntamente con su calificación, en caso de que el profesor la establezca.

Los post tendrán que ser únicamente enviados desde el espacio destinado en la plataforma Moodle, si son enviados desde algún sitio externo no serán visualizados en la actividad.

2.1.2.1. Identificación de usuarios.

A continuación se describen los tres tipos de usuario que interactúan con el plugin Facebook Integration

 Administradores: El administrador podrá instalar y desinstalar el plugin de la plataforma Moodle. Cuenta además con las funcionalidades de los usuarios Alumno y Profesor.  Profesor: El profesor de un curso podrá añadir la actividad del plugin Facebook Integration, al curso respectivo y configurarlo a su medida. Podrá componer un nuevo post, revisar todas las interacciones en la actividad, establecer y visualizar calificaciones a las interacciones.  Alumno: El alumno podrá componer un nuevo post, revisar todas las interacciones en la actividad y visualizar la calificación en caso de que el profesor la haya establecido.

2.1.2.2. Requisitos

Los requisitos proporcionados para el desarrollo del plugin Facebook Integration, se listan a continuación:

 Permitir al profesor o administrador crear una nueva actividad del plugin Facebook Integration.  El profesor o administrador podrán configurar la actividad dentro del curso.  Permitir al profesor o administrador eliminar una actividad del plugin Facebook Integration.  Desarrollar un espacio desde donde se pueda componer un nuevo post hacia la plataforma Facebook. Cualquier usuario registrado tiene permitido realizar esta acción.  Los usuarios registrados podrán visualizar las interacciones dentro de la actividad, es decir, los post que han sido enviados desde la plataforma Moodle.  Permitir al profesor o administrador emitir una calificación hacia determinada interacción o post.  Los usuarios profesor y administrador podrán visualizar la calificación de cualquier interacción dentro de la actividad.  Un alumno podrá visualizar la calificación obtenida de su interacción, siempre y cuando ésta haya sido establecida previamente.

CAPÍTULO 3: DESARROLLO DE LA SOLUCIÓN

3.1. Introducción.

En este capítulo se brindará información sobre el tema del desarrollo e implementación de cada uno de los plugins y su integración en la plataforma Moodle. Todo el desarrollo de los plugins se basa en las fases propuestas por la metodología XP3

La primera fase de la metodología se refiere a la planificación del proyecto y es en donde se presentan los requisitos de software necesarios para el desarrollo e implementación de los plugins en la plataforma Moodle, se determinan las iteraciones y seguidamente se define un plan de pruebas para verificar el cumplimiento de los requisitos planteados.

En la segunda fase de la metodología se propone un diseño de la arquitectura a implementar, así como de las API‟s que van a ser utilizadas para el desarrollo de los plugins.

En la tercera fase de la metodología se presenta la implementación en sí de los componentes definidos en la segunda fase. Se muestra la integración de las API‟s de Facebook y Twitter con las API‟s de la plataforma Moodle. Se presenta el modelo de datos utilizado, la definición de interfaces y el diagrama de componentes correspondientes para cada plugin desarrollado.

Al final del capítulo se presenta la fase de pruebas, utilizada para verificar el correcto funcionamiento de los componentes desarrollados.

3.2. Desarrollo de la herramienta de socialización y discusión.

3.2.1. Fase I: Planificación.

3.2.1.1. Historias de usuario.

Las historias de usuario son la técnica utilizada en XP para especificar los requisitos de software. Se pueden definir como pequeños textos en los que el cliente describe una actividad que realizará el sistema. La composición de los mismos se desarrolla bajo los términos del cliente, no del desarrollador, de forma que sea clara y sencilla, sin profundizar en detalles (Echeverry & Delgado, 2007).

El modelo propuesto para desarrollar las historias de usuario es el siguiente:

3 XP: Programación extrema o eXtreme Programming, es una metodología de desarrollo de software formulada por Kent Beck (1999) 30

Tabla 4. Historias de usuario Historia de Usuario Número: Nombre Historia de Usuario:

Modificación (o extensión) de Historia de Usuario (Nro. y Nombre):

Usuario: Iteración Asignada:

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

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

Descripción:

Observaciones:

Fuente: (Canós, Letelier, & Penadés, 2005)

3.2.1.2. Iteraciones.

El desarrollo del proyecto se dividirá en dos iteraciones o etapas, para facilitar su realización. Para cada iteración se define un conjunto de historias de usuario que se van a implementar. Las iteraciones se describen a continuación:

 Iteración 1: Desarrollo del plugin Twitter Integration.  Iteración 2: Desarrollo del plugin Facebook Integration.

Por cada iteración se desarrollarás dos plugins diferentes: uno para la versión de Moodle 1.9 y otro para la versión 2.6. Se generará la documentación técnica, esquemas y diagramas correspondientes a cada versión de Moodle en determinada iteración.

Se desarrollara para las versiones 1.9 y 2.6 de Moodle ya que hasta el momento, son las distribuciones con más usuarios registrados de la plataforma.

Figura 5. Sitios Moodle registrador por versión Fuente: (Moodle, 2014)

Al final de cada iteración se obtiene como resultado la entrega de los plugins correspondientes, los cuáles deben haber superado las pruebas de aceptación para verificar el cumplimiento de los requisitos. Las historias de usuario pueden ser apreciadas en el ANEXO A: HISTORIAS DE USUARIO.

3.2.1.3. Plan de pruebas.

El objetivo primordial del plan de pruebas es verificar el cumplimiento de los requisitos planteados. Cuando el desarrollo de los componentes ha finalizado, se prosigue a realizar las pruebas de Integridad de datos, y funcionamiento de los componentes. La ejecución de estas pruebas permite verificar que cada componente funcione correctamente y cumpla con los requisitos planteados. (ANEXO E: PRUEBAS).

3.2.2. Fase II: Diseño.

En la fase de diseño se debe procurar diseños simples y sencillos para facilitar el desarrollo.

3.2.2.1. Arquitectura de la solución

La arquitectura de la solución nos permite definir la forma en la cual los elementos del sistema trabajan en conjunto. Nuestra arquitectura debe ser capaz de mantener las características propias de la plataforma Moodle.

La figura ilustra de manera clara los componentes de los cuales estará compuesta la arquitectura de la solución:

Figura 6. Arquitectura de la solución Fuente: Autor

Mediante el uso de esta arquitectura de tres capas se simplifica la comprensión y organización del desarrollo del plugin. La ventaja primordial de este patrón de arquitectura es que como el desarrollo del plugin se lo realiza en varios niveles cuando exista algún error o la necesidad de un cambio obligatorio, solo es necesario cambiar el nivel en cuestión.

La primera capa representa a los ordenadores de los usuarios, donde éstos podrán interactuar con la interfaz web de Moodle. El plugin desarrollado interactúa con el usuario y viceversa, muestra el sistema al usuario, le presenta la información y obtiene la información del usuario en un mínimo de proceso.

En la capa de negocio residen las funciones que se ejecutan. Se reciben las peticiones del usuario, se procesa la información y se envían las respuestas tras el proceso.

La capa de datos es la encargada de almacenar los datos del sistema y de los usuarios de Moodle. Esta capa también involucra las invocaciones a la REST API de Twitter (Twitter Inc., 2014), y a la Graph API de Facebook (Facebook Inc., 2014) de donde se extraerá información acerca de las interacciones que tengan los usuarios con Moodle.

3.2.2.2. REST API de Twitter

La REST API de Twitter será utilizada para extraer los tweets correspondientes a un alumno dentro de una instancia creada del plugin Twitter Integration dentro un curso.

Para utilizar la API y el contenido que almacena Twitter es necesario, en primer lugar, conocer y cumplir sus reglas de desarrollador, conocidas como “Developer Rules of the Road” (https://dev.twitter.com/terms/api-terms), que entre sus puntos más relevantes se mencionan los siguientes: 33

 La API de Twitter y su contenido se puede utilizar para buscar, visualizar, analizar, recuperar, ver y enviar información hacia o en Twitter.  No sorprender a los usuarios, y siempre pedir su autorización  No crear o distribuir correo no deseado.  Respetar la privacidad del usuario.  No facilitar o fomentar la publicación de información privada o confidencial  No guardar las contraseñas de Twitter.  No almacenar contenido de Twitter no público.  Los usuarios deben iniciar sesión en Twitter a través del protocolo OAuth. Los usuarios finales sin una cuenta de Twitter deben tener la oportunidad de crear una nueva cuenta de Twitter.  Mostrar claramente la identidad del usuario que ha iniciado sesión.

Los recursos a utilizarse de la REST API v1.1, son los siguientes:

3.2.2.2.1. POST statuses/update

Actualiza el estado actual del usuario que se autentica publicando un nuevo tweet. Cada vez que se desea actualizar un estado, el texto actualizado se compara con los últimos tweets del usuario para evitar que sean duplicados, cualquier intento que resultaría en duplicación se bloqueará, devolverá un error 403

 URL del recurso https://api.twitter.com/1.1/statuses/update.json

 Rate Limit

Si bien el límite de tasa no está controlado por la API, un usuario está limitado en el número de tweets que puede crear a la vez. Si el número de actualizaciones enviados por el usuario sobrepasa el límite de intensidad permitido, este método devolverá un error HTTP 403.

 Parámetros

Tabla 5. Parámetros del recurso POST statuses/update status El texto de actualización del estado, hasta 140 caracteres. Si requerido incluye una URL, debe ser codificar (URL encode) in_reply_to_status_id El ID de un estado existente al cual la actualización es en optional respuesta.

lat Se refiere a la latitud del lugar donde es redactado el tweet. Este optional parámetro será ignorado si no es dentro del rango de -90.0 a +90.0. Será ignorado también si no posee un parámetro long. Ejemplo: 37.7821120598956 long Se refiere la longitud del lugar donde es redactado el tweet. Los optional rangos válidos para la longitud son -180,0-180,0. Este parámetro se ignora si está fuera de rango, si no es un número, si geo_enabled está desactivado, o si no existe un parámetro lat correspondiente. Ejemplo: -122.400612831116 place_id Un lugar en el mundo. Estos identificadores se pueden recuperar optional del recurso GET geo/reverse_geocode (https://dev.twitter.com/docs/api/1/get/geo/reverse_geocode). Ejemplo: df51dec6f4ee2b2c display_coordinates Se muestra un pin o marcador en las coordenadas exactas desde optional donde un tweet ha sido enviado. Ejemplo: true trim_user Cuando se establece en true, t o 1, cada tweet devuelto en un optional timeline incluirá un objeto de usuario que incluye un ID numérico sólo de los autores de estado. Ejemplo: true Fuente: (Twitter Inc., 2014)

 Ejemplo de solicitud

POST https://api.twitter.com/1.1/statuses/update.json

status=Maybe%20he%27ll%20finally%20find%20his%20keys.%20%23peterfal POST Data k

{ "coordinates": null, "favorited": false, "created_at": "Wed Sep 05 00:37:15 +0000 2012", "truncated": false, "id_str": "243145735212777472", "entities": { "urls": [

], "hashtags": [ { "text": "peterfalk", "indices": [ 35, 45 ] } ], "user_mentions": [

] }, "in_reply_to_user_id_str": null, "text": "Maybe he'll finally find his keys. #peterfalk", "contributors": null, "retweet_count": 0, "id": 243145735212777472, "in_reply_to_status_id_str": null, "geo": null, "retweeted": false, "in_reply_to_user_id": null, "place": null, "user": { "name": "Jason Costa", "profile_sidebar_border_color": "86A4A6", "profile_sidebar_fill_color": "A0C5C7", "profile_background_tile": false, "profile_image_url": "http://a0.twimg.com/profile_images/1751674923/new_york_beard_norm al.jpg", "created_at": "Wed May 28 00:20:15 +0000 2008", "location": "", "is_translator": true, "follow_request_sent": false, "id_str": "14927800", "profile_link_color": "FF3300", "entities": { "url": { "urls": [ { "expanded_url": "http://www.jasoncosta.blogspot.com/", "url": "http://t.co/YCA3ZKY",

"indices": [ 0, 19 ], "display_url": "jason-costa.blogspot.com" } ] }, "description": { "urls": [

] } }, "default_profile": false, "contributors_enabled": false, "url": "http://t.co/YCA3ZKY", "favourites_count": 883, "utc_offset": -28800, "id": 14927800, "profile_image_url_https": "https://si0.twimg.com/profile_images/1751674923/new_york_beard_no rmal.jpg", "profile_use_background_image": true, "listed_count": 150, "profile_text_color": "333333", "protected": false, "lang": "en", "followers_count": 8760, "time_zone": "Pacific Time (US & Canada)", "profile_background_image_url_https": "https://si0.twimg.com/images/themes/theme6/bg.gif", "verified": false, "profile_background_color": "709397", "notifications": false, "description": "Platform at Twitter", "geo_enabled": true, "statuses_count": 5532, "default_profile_image": false, "friends_count": 166, "profile_background_image_url": "http://a0.twimg.com/images/themes/theme6/bg.gif", "show_all_inline_media": true, "screen_name": "jasoncosta", "following": false }, "source": "My Shiny App", "in_reply_to_screen_name": null, "in_reply_to_status_id": null }

Código 1. Ejemplo de solicitud recurso POST statuses/update Fuente: (Twitter Inc., 2014)

3.2.2.2.2. GET statuses/show/:id

Devuelve un solo tweet, especificado por el parámetro id. El autor del tweet también se integrará en el tweet.

 URL del recurso https://api.twitter.com/1.1/statuses/show.json

 Rate Limit

Solicitud por ventana: 180 Solicitud por ventana (aplicación): 180

 Parámetros

Tabla 6. Parámetros del recurso GET statuses/show:id id El ID numérico del tweet deseado requerido Ejemplo: 123 trim_user Cuando se establece en true, t o 1, cada tweet devuelto en un optional timeline incluirá un objeto de usuario que incluye solo el ID numérico de los autores de estado. Se debe omitir este parámetro para recibir el objeto de usuario completo. Ejemplo: true include_my_retweet Cualquier tweet devuelto que ha sido retwitteado por el usuario optional autenticado incluirá un nodo adicional current_user_retweet, conteniendo el ID original del status que ha sido retwitteado. Ejemplo: true include_entities El nodo entities puede ser excluido cuando este parámetro sea optional establecido en false. Ejemplo: false place_id Un lugar en el mundo. Estos identificadores se pueden recuperar optional del recurso GET geo/reverse_geocode (https://dev.twitter.com/docs/api/1/get/geo/reverse_geocode). Ejemplo: df51dec6f4ee2b2c display_coordinates Se muestra un pin o marcador en las coordenadas exactas desde optional donde un tweet ha sido enviado. Ejemplo: true trim_user Cuando se establece en true, t o 1, cada tweet devuelto en un 38

optional timeline incluirá un objeto de usuario que incluye un ID numérico sólo de los autores de estado. Ejemplo: true Fuente: (Twitter Inc., 2014)

 Ejemplo de solicitud

GET https://api.twitter.com/1.1/statuses/show.json?id=210462857140252672

{ "coordinates": null, "favorited": false, "truncated": false, "created_at": "Wed Jun 06 20:07:10 +0000 2012", "id_str": "210462857140252672", "entities": { "urls": [ { "expanded_url": "https://dev.twitter.com/terms/display- guidelines", "url": "https://t.co/Ed4omjYs", "indices": [ 76, 97 ], "display_url": "dev.twitter.com/terms/display-\u2026" } ], "hashtags": [ { "text": "Twitterbird", "indices": [ 19, 31 ] } ], "user_mentions": [

] }, "in_reply_to_user_id_str": null, "contributors": [ 14927800 ], "text": "Along with our new #Twitterbird, we've also updated our Display Guidelines: https://t.co/Ed4omjYs ^JC", "retweet_count": 66, "in_reply_to_status_id_str": null, "id": 210462857140252672, "geo": null, "retweeted": true, "possibly_sensitive": false, "in_reply_to_user_id": null, "place": null, "user": { "profile_sidebar_fill_color": "DDEEF6", "profile_sidebar_border_color": "C0DEED", "profile_background_tile": false, "name": "Twitter API", "profile_image_url": "http://a0.twimg.com/profile_images/2284174872/7df3h38zabcvjylnyfe 3_normal.png", "created_at": "Wed May 23 06:01:13 +0000 2007", "location": "San Francisco, CA", "follow_request_sent": false, "profile_link_color": "0084B4", "is_translator": false, "id_str": "6253282", 40

"entities": { "url": { "urls": [ { "expanded_url": null, "url": "http://dev.twitter.com", "indices": [ 0, 22 ] } ] }, "description": { "urls": [

] } }, "default_profile": true, "contributors_enabled": true, "favourites_count": 24, "url": "http://dev.twitter.com", "profile_image_url_https": "https://si0.twimg.com/profile_images/2284174872/7df3h38zabcvjylny fe3_normal.png", "utc_offset": -28800, "id": 6253282, "profile_use_background_image": true, "listed_count": 10774, "profile_text_color": "333333", "lang": "en", "followers_count": 1212963, "protected": false, "notifications": null, "profile_background_image_url_https": "https://si0.twimg.com/images/themes/theme1/bg.png", "profile_background_color": "C0DEED", "verified": true, "geo_enabled": true, "time_zone": "Pacific Time (US & Canada)", "description": "The Real Twitter API. I tweet about API changes, service issues and happily answer questions about Twitter and our API. Don't get an answer? It's on my website.", "default_profile_image": false, "profile_background_image_url": "http://a0.twimg.com/images/themes/theme1/bg.png", "statuses_count": 3333, "friends_count": 31, "following": true, "show_all_inline_media": false, "screen_name": "twitterapi" }, "in_reply_to_screen_name": null, "source": "web", "in_reply_to_status_id": null }

Código 2. Ejemplo de solicitud recurso GET statuses/show/:id Fuente: (Twitter Inc., 2014) 41

3.2.2.2.3. GET search/tweets

Devuelve una colección de tweets relevantes que coinciden con una búsqueda especificada.

 URL del recurso https://api.twitter.com/1.1/search/tweets.json

 Rate Limit

Solicitud por ventana: 180 Solicitud por ventana (aplicación): 450

 Parámetros

Tabla 7. Parámetros del recurso GET statuses/show:id q Consulta de búsqueda de 1000 caracteres como máximo, con requerido URL codificada y UTF-8. Las consultas pueden, además, estar limitadas por la complejidad. Ejemplo: @noradio geocode Devuelve los tweets de los usuarios ubicados en un radio de una optional determinada latitud/longitud. La ubicación está tomando datos preferencialmente desde la API de geoetiquetado. En el valor del parámetro se especifica "latitud, longitud y radio", en donde las unidades de radio deben ser especificadas en "mi" (millas) o "km" (kilómetros). Ejemplo: 37.781157,-122.398720,1mi lang Restringe tweets al lenguaje dado, determinado por un código optional ISO 639-1. Ejemplo: eu locale Parámetro para especificar el idioma de la consulta que se va a optional enviar (sólo ja es actualmente efectiva). Esto está pensado los consumidores específicos del lenguaje, y el valor por defecto debería funcionar en la mayoría de los casos. Ejemplo: ja result_type Especifica qué tipo de resultados de búsqueda se prefiere recibir. optional El valor predeterminado actual es "mixed". Los valores válidos son:  mixed: Incluye resultados tanto populares y en tiempo real 42

en la respuesta  recent: Devuelve solo los resultados recientes en la respuesta  popular: Devuelve solo los resultados más populares count Número de tweets que desea retornar por página, máximo 100, optional por defecto 15. Ejemplo: 100 until Retorna tweets generados antes de la fecha dada. La fecha debe optional tener el formato AAAA-MM-DD Ejemplo: 2012-09-01 since_id Devuelve resultados con un ID mayor que (es decir, más reciente optional que) el ID especificado. Hay límites a la cantidad de tweets que se puede acceder a través de la API. Ejemplo: 12345 max_id Devuelve resultados con un ID menor que o igual que el ID optional especificado. Ejemplo: 54321 include_entities El nodo entities puede ser excluido si el parámetro se establece optional en false Ejemplo: false callback Si se proporciona, la respuesta será utilizar el formato JSONP optional con una callback del nombre dado. Ejemplo: processTweets Fuente: (Twitter Inc., 2014)

 Operadores de consulta

Tabla 8. Operadores de consulta Operador Descripción viendo ahora Busca tweets que contengan tanto “viendo” y “ahora”. Este es el operador por defecto “hora feliz” Retorna tweets que contengan exactamente la frase “hora feliz” amor OR odio Busca tweets que contengan la palabra “amor” u “odio”, o ambos. cerveza –raiz Busca tweets que contengan la palabra “cerveza” pero no “raiz” #haiku Búsqueda de tweets que contengan el hashtag “haiku” from:alexiskold Busca tweets enviados desde la cuenta “alexiskold”

to:techcrunch Busca tweets dirigidos hacia la cuenta “techcrunch” @mashable Busca tweets que contengan una referencia hacia la cuenta “@mashable”. superheroe since:2010- Busca tweets que contienen la palabra “superheroe” y que han 12-27 sido enviados desde la fecha “2010-12-27” (año-mes-día). ftw until:2010-12-27 Busca tweets que contienen “ftw” y enviados antes de la fecha “2010-12-27” movie –scary :) Busca tweets que contienen “movie” pero no “scary”, y con una actitud positiva vuelo :( Contiene “vuelo” y una actitud negativa trafico ? Busca tweets de “trafico” y realizando una pregunta gracioso filter:links Buscar tweet que contengan “gracioso” y referencia a una URL noticias Contiene “noticias” y enviado vía TwitterFeed. source:twitterfeed Fuente: (Twitter Inc., 2014)

Antes de realizar una solicitud de búsqueda, se debe asegurar que las consultas estén codificadas (URL encode). Por ejemplo:

Consulta Consulta codificada #haiku #feliz %23haiku+%23feliz “hora feliz” :) %22hora%20feliz%22%20%3A%29

 Ejemplo de solicitud

https://api.twitter.com/1.1/search/tweets.json?q=%23freebandnames&since_id=240 GET 12619984051000&max_id=250126199840518145&result_type=mixed&count=2

{ "statuses": [ { "coordinates": null, "favorited": false, "truncated": false, "created_at": "Mon Sep 24 03:35:21 +0000 2012", "id_str": "250075927172759552", "entities": { "urls": [

], "hashtags": [ { "text": "freebandnames", "indices": [ 20, 34 ] } ], "user_mentions": [

] }, "in_reply_to_user_id_str": null, "contributors": null, "text": "Aggressive Ponytail #freebandnames", "metadata": { "iso_language_code": "en", "result_type": "recent" }, "retweet_count": 0, "in_reply_to_status_id_str": null, "id": 250075927172759552, "geo": null, "retweeted": false, "in_reply_to_user_id": null, "place": null, "user": { "profile_sidebar_fill_color": "DDEEF6", "profile_sidebar_border_color": "C0DEED", "profile_background_tile": false, "name": "Sean Cummings", "profile_image_url": "http://a0.twimg.com/profile_images/2359746665/1v6zfgqo8g0d3mk7ii5 s_normal.jpeg", "created_at": "Mon Apr 26 06:01:55 +0000 2010", "location": "LA, CA", "follow_request_sent": null, "profile_link_color": "0084B4", "is_translator": false, "id_str": "137238150", "entities": { "url": { "urls": [ { "expanded_url": null, "url": "", "indices": [ 45

0, 0 ] } ] }, "description": { "urls": [

] } }, "default_profile": true, "contributors_enabled": false, "favourites_count": 0, "url": null, "profile_image_url_https": "https://si0.twimg.com/profile_images/2359746665/1v6zfgqo8g0d3mk7i i5s_normal.jpeg", "utc_offset": -28800, "id": 137238150, "profile_use_background_image": true, "listed_count": 2, "profile_text_color": "333333", "lang": "en", "followers_count": 70, "protected": false, "notifications": null, "profile_background_image_url_https": "https://si0.twimg.com/images/themes/theme1/bg.png", "profile_background_color": "C0DEED", "verified": false, "geo_enabled": true, "time_zone": "Pacific Time (US & Canada)", "description": "Born 330 Live 310", "default_profile_image": false, "profile_background_image_url": "http://a0.twimg.com/images/themes/theme1/bg.png", "statuses_count": 579, "friends_count": 110, "following": null, "show_all_inline_media": false, "screen_name": "sean_cummings" }, "in_reply_to_screen_name": null, "source": "Twitter for Mac", "in_reply_to_status_id": null }, { "coordinates": null, "favorited": false, "truncated": false, "created_at": "Fri Sep 21 23:40:54 +0000 2012", "id_str": "249292149810667520", "entities": { "urls": [

], 46

"hashtags": [ { "text": "FreeBandNames", "indices": [ 20, 34 ] } ], "user_mentions": [

] }, "in_reply_to_user_id_str": null, "contributors": null, "text": "Thee Namaste Nerdz. #FreeBandNames", "metadata": { "iso_language_code": "pl", "result_type": "recent" }, "retweet_count": 0, "in_reply_to_status_id_str": null, "id": 249292149810667520, "geo": null, "retweeted": false, "in_reply_to_user_id": null, "place": null, "user": { "profile_sidebar_fill_color": "DDFFCC", "profile_sidebar_border_color": "BDDCAD", "profile_background_tile": true, "name": "Chaz Martenstein", "profile_image_url": "http://a0.twimg.com/profile_images/447958234/Lichtenstein_normal. jpg", "created_at": "Tue Apr 07 19:05:07 +0000 2009", "location": "Durham, NC", "follow_request_sent": null, "profile_link_color": "0084B4", "is_translator": false, "id_str": "29516238", "entities": { "url": { "urls": [ { "expanded_url": null, "url": "http://bullcityrecords.com/wnng/", "indices": [ 0, 32 ] } ] }, "description": { "urls": [

] } }, 47

"default_profile": false, "contributors_enabled": false, "favourites_count": 8, "url": "http://bullcityrecords.com/wnng/", "profile_image_url_https": "https://si0.twimg.com/profile_images/447958234/Lichtenstein_norma l.jpg", "utc_offset": -18000, "id": 29516238, "profile_use_background_image": true, "listed_count": 118, "profile_text_color": "333333", "lang": "en", "followers_count": 2052, "protected": false, "notifications": null, "profile_background_image_url_https": "https://si0.twimg.com/profile_background_images/9423277/backgroun d_tile.bmp", "profile_background_color": "9AE4E8", "verified": false, "geo_enabled": false, "time_zone": "Eastern Time (US & Canada)", "description": "You will come to Durham, North Carolina. I will sell you some records then, here in Durham, North Carolina. Fun will happen.", "default_profile_image": false, "profile_background_image_url": "http://a0.twimg.com/profile_background_images/9423277/background_ tile.bmp", "statuses_count": 7579, "friends_count": 348, "following": null, "show_all_inline_media": true, "screen_name": "bullcityrecords" }, "in_reply_to_screen_name": null, "source": "web", "in_reply_to_status_id": null } }

Código 3. Ejemplo de solicitud recurso GET search/tweets Fuente: (Twitter Inc., 2014)

3.2.2.3. Graph API de Facebook

La Graph API es la principal manera de obtener los datos que entran y salen del gráfico social de Facebook (graph). Es una API basada en HTTP que se puede utilizar para consultar datos, publicar nuevos post, subir fotos y una variedad de otras tareas que una aplicación podría necesitar.

El nombre de Graph API nace de la idea de mantener un “gráfico social”, una representación de la información que contiene Facebook compuesto por:

 nodes: Básicamente “cosas” como un usuario, una foto, una página, o un comentario.  edges: Las conexiones entre esas “cosas” como fotos de una página, o comentarios de una foto.  fields: Información referente a esas “cosas”, tales como el cumpleaños de un usuario, o el nombre de una página o grupo.

Para utilizar la Graph API de Facebook es necesario conocer y regirse a su Política de la Plataforma (https://developers.facebook.com/policy/) Sus puntos más importantes se detallan a continuación:

 No debes confundir, decepcionar, defraudar, engañar, sorprender ni enviar spam a ninguna persona.  Obtener el consentimiento de las personas antes de publicar contenido en su nombre.  Proteger la información que reciba de Facebook contra el acceso o el uso no autorizados.  Mostrar únicamente los datos que se hayan obtenido desde un identificador de acceso de un usuario en los dispositivos asociados con ese identificador.  No transmitir, solicitar o recopilar nombres de usuario ni contraseñas de Facebook.  Mantener los identificadores de usuario de Facebook bajo total control.  No colocar datos de Facebook en directorios o motores de búsqueda ni incluir una función de búsqueda en la web en Facebook.

Hay un límite para cada recurso multiplicado por usuarios activos mensuales de una aplicación. Cuando la aplicación utiliza más recursos permitidos se lanza un error, código: 4. (https://developers.facebook.com/docs/reference/ads-api/api-rate-limiting)

Los recursos a utilizarse de la Graph API v2.0, son los siguientes:

3.2.2.3.1. Lectura

Todos los nodos y las conexiones de la Graph API se pueden leer simplemente con una solicitud HTTP GET a la variable relevante. Por ejemplo, si desea recuperar la información sobre el usuario actual, se debería realizar una solicitud HTTP GET como la siguiente:

/* hacer la llamada a la API */ $request = new FacebookRequest( $session, 'GET', '/me' ); $response = $request->execute(); $graphObject = $response->getGraphObject(); /* manejar el resultado */

Código 4. Ejemplo solicitud HTTP GET de Graph API Fuente: (Facebook Inc., 2014)

La mayoría de las llamadas a la API deben estar firmadas con un token de acceso. Se puede determinar que tokens de acceso se necesitan para el nodo o la conexión que desea leer en el siguiente enlace: https://developers.facebook.com/docs/graph-api/reference/v2.0

Por defecto, no todas los campos de un node o edge se devuelven cuando se hace una consulta. Se puede elegir los fields o edges que desea obtener con los "campos" de los parámetros de la consulta. Esto es realmente útil para hacer las llamadas a la API más eficientes y rápidas. Por ejemplo, la siguiente llamada a la Graph API solamente retorna el id, nombre y foto del perfil de Ben:

/* llamada a la API */ GET graph.facebook.com /bgolub? fields=id,name,picture

/* resultado de la llamada */ { "id": "15500414", "name": "Benjamin Golub", "picture": { "data": { "is_silhouette": false, "url": "https://fbcdn-profile-a.akamaihd.net/hprofile- ak-frc3/t1.0- 1/p50x50/10171120_10100117932459356_7608544602085648503 _t.jpg" } } }

Código 5. Ejemplo solicitud HTTP GET de Graph API con parámetros Fuente: (Facebook Inc., 2014)

3.2.2.3.2. Publicar

La mayoría de los nodos de la Graph API tienen enlaces (edges) que se pueden publicar, por ejemplo: /{user-id}/feeds o /{album-id}/photos. Todas las publicaciones de la Graph API se realizan simplemente con una solicitud HTTP POST al enlace o edge correspondiente con todos los parámetros necesarios incluidos. Por ejemplo, si se desea publicar un mensaje en nombre de alguien, Se debe realizar una solicitud HTTP POST de la siguiente manera:

POST graph.facebook.com /{user-id}/feed? message={message}& access_token={access-token}

$description ) ); $response = $request->execute(); $graphObject = $response->getGraphObject(); ?>

Código 6. Ejemplo solicitud para publicar con HTTP POST de Graph API Fuente: (Facebook Inc., 2014)

3.2.2.3.3. Actualizar

La actualización de un post no se puede realizar mediante la Graph API de Facebook, así como lo menciona su documentación oficial (https://developers.facebook.com/docs/graph- api/reference/v2.0/post#updating).

3.2.2.3.4. Eliminar

Se pueden eliminar nodos realizando una solicitud DELETE.

/* eliminar nodo utilizando HTTP DELETE */ DELETE graph.facebook.com /{node-id}? access_token={access-token}

execute(); $graphObject = $response->getGraphObject(); ?>

Código 7. Eliminar nodos con DELETE de Graph API Fuente: (Facebook Inc., 2014)

3.2.3. Fase III: Implementación.

3.2.3.1. Modelo de datos.

El modelo de datos nos permite describir las estructuras de datos de la base, el tipo de los datos que hay en la base y la forma en que se relacionan. Describiremos el modelo de datos de los plugins mediante el diagrama de Entidad-Relación. A partir de él detallaremos las entidades, relaciones y atributos que lo componen.

3.2.3.1.1. Iteración 1 con Moodle versión 1.9.19

La siguiente figura permite visualizar el modelo de datos correspondiente al plugin Twitter Integration para la plataforma Moodle versión 1.9.19, con todas las entidades que intervienen para el cumplimiento de nuestro objetivo.

Figura 7. Modelo de datos Iteración 1 con Moodle v.1.9.19 Fuente: Autor 53

Entidades

 twitterintegration: La entidad twitterintegration almacena la información referente a cada instancia del plugin. Cada vez que el profesor añada una nueva actividad de Twitter Integration a uno de sus cursos, se insertará un nuevo registro en esta tabla.  twitterintegration_activity: La tabla twitterintegration_activity contiene la información de cada interacción que se realiza dentro de una instancia. Cuando un usuario compone un nuevo tweet desde la plataforma Moodle se insertará un nuevo registro en esta tabla, a su vez, si un usuario utiliza cualquier aplicación externa a Moodle para registrar su actividad, el plugin tiene la capacidad de indexarlo e insertarlo como un nuevo registro en esta tabla.  twitterintegration_ratings: En esta entidad se almacena la valoración de cada una de las interacciones que los usuarios han realizado dentro de una instancia, si la configuración así lo permite.  course: Esta es una tabla del sistema que guarda la información relativa a cada curso que existe en la plataforma.  user: Esta entidad también pertenece al sistema, y guarda la información personal de cada usuario registrado en la plataforma.  user_info: En esta entidad, que pertenece al sistema, se almacena y establece la estructura del campo que debe ser creado por el administrador del sitio Moodle, para que los usuarios puedan utilizar su username de Twitter y por lo tanto utilizar cualquier aplicación externa de Moodle para registrar su participación dentro de una instancia.  user_info_data: En esta entidad se almacena los nombres de usuario de cada participante de un curso de la plataforma, que previamente debe estar estructurado y registrado en la tabla user_info.  grade_items: Entidad perteneciente al sistema y que mantiene información sobre los elementos calificables.  grade_grades: Esta tabla mantiene las calificaciones individuales para cada usuario y cada elemento calificable.

Relaciones

 Relación twitterintegration-twitterintegration_activity: Cada instancia del plugin Twitter Integration puede poseer varias interacciones. Cada interacción solo puede pertenecer a una instancia.  Relación twitterintegration_activity-twitterintegration_ratings: Cada interacción dentro de una instancia puede tener una o varias calificaciones otorgadas por uno o varios usuarios con los permisos respectivos.  Relación user-twitterintegration_activity: Cada usuario registrado del sistema puede tener una o varias interacciones dentro de una instancia.

Atributos

 Entidad twitterintegration: o id: Identificador de la instancia y clave primaria de la entidad. Se trata de un entero de 10 dígitos. o course: Identificador del curso en el que se encuentra la instancia. Es un entero de 10 dígitos. o name: Nombre que se le da a la instancia. Es una cadena de caracteres con una longitud máxima de 255. o hashtag: Campo requerido para almacenar la etiqueta de la instancia, mediante la cual se realiza una búsqueda externa de tweets. Es un cadena de caracteres con una longitud máxima de 50. o description: Descripción general de la instancia. Es una cadena de texto. o descriptionformat: Formato del campo description. Es un entero. o assessed: Comprueba si la actividad es calificable: 1 = true 0 = false. Es un entero. o scale: Determina cuál es la escala utilizada para calificar. o timedue: Fecha en la que la actividad ya no estará habilitada. Es un entero o timeavailable: Fecha en la que la actividad se encontrará habilitada. Es un entero. o timecreated: Fecha de creación de la instancia. Es un entero. o timemodified: Fecha de modificación de la instancia. Es un entero.

o tweet_id: Almacena el campo id de un tweet que ha sido creado con el plugin, como indexado por el mismo. Es un entero. o since_id: Almacena una variación del campo id de un tweet, el cuál es enviado como parámetro para indexar tweets creados fuera de la plataforma Moodle. Es un entero. o twitter_user_id: Almacena el id de los usuarios de Twitter que interactúan con la instancia. Es un entero. o twitter_screen_name: Almacena los nombres de usuario de Twitter de los participantes que interactúan con la instancia. Es una cadena de 15 caracteres. o user_id: Almacena los id de los usuarios registrados en Moodle que participan dentro de la instancia. Es un entero. o user_name: Almacena los nombres de usuarios de los participantes que interactúan con la instancia. Es una cadena de 30 caracteres.

 Entidad twitterintegration_ratings: o id: Identificador de la calificación y clave primaria de la entidad. Es un entero. o userid: Identificador del usuario que ha calificado la interacción dentro de la instancia. Es un entero. o activityid: Identificador de cada interacción realizada dentro de la instancia. Es un entero. o datetime: Fecha en la que se estableció la calificación. Es un entero. o rating: Valor numérico que representa la calificación otorgada por un usuario con los permisos correspondientes.

 Entidad user: La entidad user no pertenece al plugin Twitter Integration, sino a la base de datos de Moodle. Se la incluye en el esquema porque se relaciona con las tablas twitterintegration_activity y twitterintegration_ratings por medio de su campo id.

 Entidad user_info_data: La entidad user_info_data también pertenece a la base de datos Moodle, sin embargo se la incluye en el esquema por tener vital importancia para realizar la búsqueda externa de tweets, y de manera natural por estar relacionada con la tabla user.

 Entidad user_info: Se incluye la entidad en el esquema por tener información sobre la estructura del campo utilizado en la tabla user_info_data. 56

 Entidad course: La entidad no pertenece al plugin Twitter Integration, se la incluye en el esquema por estar relacionada con la tabla twitterintegration por medio de su campo id.

 Entidad grade_items: Se incluye la entidad grade_items por estar relacionada con la tabla twitterintegration_ratings.

 Entidad grade_grades: La entidad no pertenece al plugin Twitter Integration, sin embargo se la incluye en el esquema por su relación con la tabla grade_items y por consiguiente con la tabla twitterintegration_ratings.

3.2.3.1.2. Iteración 1 con Moodle versión 2.6.

La siguiente figura permite visualizar el modelo de datos correspondiente al plugin Twitter Integration para la plataforma Moodle versión 2.6, con todas las entidades que intervienen para el cumplimiento de nuestro objetivo.

Figura 8. Modelo de datos Iteración 1 con Moodle v.2.6 Fuente: Autor

Entidades

 rating: Esta es una entidad del sistema en donde se almacena la valoración de cada una de las interacciones que los usuarios han realizado dentro de una instancia, si la configuración así lo permite, además de algunos campos específicos establecidos por Moodle.  course: Esta es una tabla del sistema que guarda la información relativa a cada curso que existe en la plataforma.  user: Esta entidad también pertenece al sistema, y guarda la información personal de cada usuario registrado en la plataforma.  user_info: En esta entidad, que pertenece al sistema, se almacena y establece la estructura del campo que debe ser creado por el administrador del sitio Moodle, para que los usuarios puedan utilizar su username de Twitter y por lo tanto utilizar cualquier aplicación externa de Moodle para registrar su participación dentro de una instancia.  user_info_data: En esta entidad se almacena los nombres de usuario de cada participante de un curso de la plataforma, que previamente debe estar estructurado y registrado en la tabla user_info.  grade_items: Entidad perteneciente al sistema y que mantiene información sobre los elementos calificables.  grade_grades: Esta tabla mantiene las calificaciones individuales para cada usuario y cada elemento calificable.

Relaciones

 Relación course-twitterintegration: Cada curso del sistema puede configurar las instancias del plugin Twitter Integration que un profesor o administrador desee. Cada una de estas instancias sólo pertenece a un curso concreto.  Relación twitterintegration-twitterintegration_activity: Cada instancia del plugin Twitter Integration puede poseer varias interacciones. Cada interacción solo puede pertenecer a una instancia.  Relación twitterintegration_activity- ratings: Cada interacción dentro de una instancia puede tener una o varias calificaciones otorgadas por uno o varios usuarios con los permisos respectivos.  Relación user-twitterintegration_activity: Cada usuario registrado del sistema puede tener una o varias interacciones dentro de una instancia.

Atributos

 Entidad twitterintegration: o id: Identificador de la instancia y clave primaria de la entidad. Se trata de un entero de 10 dígitos. o course: Identificador del curso en el que se encuentra la instancia. Es un entero de 10 dígitos. o name: Nombre que se le da a la instancia. Es una cadena de caracteres con una longitud máxima de 255. o hashtag: Campo requerido para almacenar la etiqueta de la instancia, mediante la cual se realiza una búsqueda externa de tweets. Es un cadena de caracteres con una longitud máxima de 50. o intro: Descripción general de la instancia. Es una cadena de texto. o introformat: Formato del campo intro. Es un entero. o assessed: Comprueba si la actividad es calificable: 1 = true 0 = false. Es un entero. o assesstimestart: Fecha que indica desde cuando está habilitada la calificación de la interacción. Es un entero. o assesstimefinish: Fecha en la que las interacciones dentro de la actividad ya no podrán ser calificadas. Es un entero. o scale: Determina cuál es la escala utilizada para calificar. Es un entero. o timedue: Fecha en la que la actividad ya no estará habilitada. Es un entero. o timeavailable: Fecha en la que la actividad se encontrará habilitada. Es un entero. o timecreated: Fecha de creación de la instancia. Es un entero. o timemodified: Fecha de modificación de la instancia. Es un entero.

o since_id: Almacena una variación del campo id de un tweet, el cuál es enviado como parámetro para indexar tweets creados fuera de la plataforma Moodle. Es un entero. o created: Fecha de creación de la interacción. Es un entero. o twitter_user_id: Almacena el id de los usuarios de Twitter que interactúan con la instancia. Es un entero. o twitter_screen_name: Almacena los nombres de usuario de Twitter de los participantes que interactúan con la instancia. Es una cadena de 15 caracteres. o userid: Almacena los id de los usuarios registrados en Moodle que participan dentro de la instancia. Es un entero. o username: Almacena los nombres de usuarios de los participantes que interactúan con la instancia. Es una cadena de 30 caracteres.

 Entidad user_info: Se incluye la entidad en el esquema por tener información sobre la estructura del campo utilizado en la tabla user_info_data.

 Entidad course: La entidad no pertenece al plugin Twitter Integration, se la incluye en el esquema por estar relacionada con la tabla twitterintegration por medio de su campo id.  Entidad rating: La entidad no pertenece al plugin Twitter Integration, sino a la base de datos de Moodle. Se la incluye en el esquema porque se relaciona con la tabla twitterintegration_activity, ya que almacena los datos de las calificaciones que se establecen sobre las interacciones dentro de una instancia.

 Entidad grade_items: Se incluye la entidad grade_items por estar relacionada con la tabla ratings. 61

3.2.3.1.3. Iteración 2 con Moodle versión 1.9.19

La siguiente figura permite visualizar el modelo de datos correspondiente al plugin Facebook Integration para la plataforma Moodle versión 1.9.19.

Figura 9. Modelo de datos Iteración 2 con Moodle versión 1.9.19 Fuente: Autor

Entidades

 facebookintegration: La entidad facebookintegration almacena la información referente a cada instancia del plugin. Cuando el profesor añada una nueva actividad de Facebook Integration a uno de sus cursos, se insertará un nuevo registro en esta tabla.  facebookintegration_activity: La tabla facebookintegration_activity contiene la información de cada interacción que se realiza dentro de una instancia. Cuando un usuario escribe un nuevo post desde la plataforma Moodle se insertará un nuevo registro en esta tabla.  facebookintegration_ratings: En esta entidad se almacena la valoración de cada una de las interacciones que los usuarios han realizado dentro de una instancia, si la configuración así lo permite y siguiendo los parámetros establecidos.  course: Esta es una tabla del sistema que guarda la información relativa a cada curso que existe en la plataforma.  user: Esta entidad también pertenece al sistema, y guarda la información personal de cada usuario registrado en la plataforma.  grade_items: Entidad perteneciente al sistema y que mantiene información sobre los elementos calificables.  grade_grades: Esta tabla mantiene las calificaciones individuales para cada usuario y cada elemento calificable.

Relaciones

 Relación course-facebookintegration: Cada curso del sistema puede añadir y configurar las instancias del plugin Facebook Integration que un profesor o administrador desee. Cada una de estas instancias sólo pertenece a un curso concreto.  Relación facebookintegration-facebookintegration_activity: Cada instancia del plugin Facebook Integration puede poseer varias interacciones. Cada interacción solo puede pertenecer a una instancia.  Relación facebookintegration_activity-facebookintegration_ratings: Cada interacción dentro de una instancia puede tener una o varias calificaciones otorgadas por uno o varios usuarios con los permisos respectivos.  Relación user-facebookintegration_activity: Cada usuario registrado del sistema puede tener una o varias interacciones dentro de una instancia.

Atributos

 Entidad twitterintegration_activity: o id: Identificador de la interacción y clave primaria de la entidad. Es un entero. Es un entero de 10 dígitos. o id_instance: Identificador de la instancia en la que se encuentra la interacción. Es un entero de 10 dígitos. o post_id: Almacena el campo id de un post que ha sido creado con el plugin. Es un entero. o facebook_user_id: Almacena el id de los usuarios de Facebook que interactúan con la instancia. Es un entero. o user_id: Almacena los id de los usuarios registrados en Moodle que participan dentro de la instancia. Es un entero.

 Entidad facebookintegration_ratings: o id: Identificador de la calificación y clave primaria de la entidad. Es un entero. o userid: Identificador del usuario que ha calificado la interacción dentro de la instancia. Es un entero.

o activityid: Identificador de cada interacción realizada dentro de la instancia. Es un entero. o datetime: Fecha en la que se estableció la calificación. Es un entero. o rating: Valor numérico que representa la calificación otorgada por un usuario con los permisos correspondientes.

 Entidad user: La entidad user pertenece a la base de datos de Moodle. Se la incluye en el esquema porque se relaciona con las tablas facebookintegration_activity y facebookintegration_ratings por medio de su campo id.

 Entidad course: La entidad no pertenece al plugin Facebook Integration, se la incluye en el esquema por estar relacionada con la tabla facebookintegration por medio de su campo id.

 Entidad grade_items: Se incluye la entidad grade_items por estar relacionada con la tabla facebookintegration_ratings.

 Entidad grade_grades: La entidad no pertenece al plugin Facebook Integration, sin embargo se la incluye en el esquema por su relación con la tabla grade_items y por consiguiente con la tabla facebookintegration_ratings.

3.2.3.1.4. Iteración 2 con Moodle versión 2.6

En la siguiente figura se aprecia el modelo de datos correspondiente al plugin Facebook Integration para Moodle versión 2.6

Figura 10. Modelo de datos Iteración 2 con Moodle versión 2.6 Fuente: Autor

Entidades

 facebookintegration: La entidad facebookintegration almacena la información referente a cada instancia del plugin. Cada vez que el profesor añada una nueva actividad de Facebook Integration a uno de sus cursos, se insertará un nuevo registro en esta tabla.  facebookintegration_activity: La tabla facebookintegration_activity contiene la información de cada interacción que se realiza dentro de una instancia. Cuando un

usuario escribe un nuevo post desde la plataforma Moodle se insertará un nuevo registro en esta tabla.  rating: Esta es una entidad del sistema en donde se almacena la valoración de cada una de las interacciones que los usuarios han realizado dentro de una instancia, si la configuración así lo permite, además de algunos campos específicos establecidos por Moodle.  course: Esta es una tabla del sistema que guarda la información relativa a cada curso que existe en la plataforma.  user: Esta entidad también pertenece al sistema, y guarda la información personal de cada usuario registrado en la plataforma.  grade_items: Entidad perteneciente al sistema y que mantiene información sobre los elementos calificables.  grade_grades: Esta tabla mantiene las calificaciones individuales para cada usuario y cada elemento calificable.

Relaciones

 Relación course-facebookintegration: Cada curso del sistema puede configurar las instancias del plugin Facebook Integration que un profesor o administrador desee. Cada una de estas instancias sólo pertenece a un curso concreto.  Relación facebookintegration-facebookintegration_activity: Cada instancia del plugin Facebook Integration puede poseer varias interacciones. Cada interacción solo puede pertenecer a una instancia.  Relación facebookintegration_activity-rating: Cada interacción dentro de una instancia puede tener una o varias calificaciones otorgadas por uno o varios usuarios con los permisos respectivos.  Relación user-facebookintegration_activity: Cada usuario registrado del sistema puede tener una o varias interacciones dentro de una instancia.

Atributos

 Entidad facebookintegration: o id: Identificador de la instancia y clave primaria de la entidad. Se trata de un entero de 10 dígitos. o course: Identificador del curso en el que se encuentra la instancia. Es un entero de 10 dígitos.

o name: Nombre que se le da a la instancia. Es una cadena de caracteres con una longitud máxima de 255. o intro: Descripción general de la instancia. Es una cadena de texto. o introformat: Formato del campo intro. Es un entero. o groupid: Identificador del grupo de Facebook en el cuál se van a ingresar los nuevos posts. o postid: Identificado del post publicado en el grupo de Facebook. o assessed: Comprueba si la actividad es calificable: 1 = true 0 = false. Es un entero. o assesstimestart: Fecha que indica desde cuando está habilitada la calificación de la interacción. Es un entero. o assesstimefinish: Fecha en la que las interacciones dentro de la actividad ya no podrán ser calificadas. Es un entero. o scale: Determina cuál es la escala utilizada para calificar. Es un entero. o timecreated: Fecha de creación de la instancia. Es un entero. o timemodified: Fecha de modificación de la instancia. Es un entero.

 Entidad facebookintegration_activity: o id: Identificador de la interacción y clave primaria de la entidad. Es un entero. Es un entero de 10 dígitos. o id_instance: Identificador de la instancia en la que se encuentra la interacción. Es un entero de 10 dígitos. o post_id: Almacena el campo id de un post que ha sido creado y publicado con el plugin. Es un entero. o created: Fecha de creación de la interacción. Es un entero. o facebook_user_id: Almacena el id de los usuarios de Facebook que interactúan con la instancia. Es un entero. o userid: Almacena los id de los usuarios registrados en Moodle que participan dentro de la instancia. Es un entero.

 Entidad user: La entidad user no pertenece al plugin Facebook Integration, sino a la base de datos de Moodle. Se la incluye en el esquema porque se relaciona con las tablas facebookintegration_activity y facebookintegration_ratings por medio de su campo id.

 Entidad course: La entidad pertenece a la base de datos de Moodle, y se la incluye en el esquema por estar relacionada con la tabla facebookintegration por medio de su campo id.

 Entidad rating: La entidad no pertenece al plugin Facebook Integration, sino a la base de datos de Moodle. Se la incluye en el esquema porque se relaciona con la tabla facebookintegration_activity, ya que almacena los datos de las calificaciones que se establecen sobre las interacciones dentro de una instancia.

 Entidad grade_items: Se incluye la entidad grade_items por estar relacionada con la tabla rating.

3.2.3.2. Definición de interfaces de usuario.

Las principales interfaces que podemos encontrar en la aplicación son los siguientes:

 Listados: Son las listas donde se muestran los diferentes datos de una consulta a la base de datos  Formularios de datos: Pantallas con una serie de campos para ingresar datos.

3.2.3.2.1. Iteración 1

Las interfaces con las que contará el plugin Twitter Integration son las siguientes:

Tabla 9. Interfaces de usuario plugin Twitter Integration Listado Formulario Crear/modificar instancias X Listado de instancias X Visualizar las interacciones X Listar los hashtags X Componer un tweet X Visualizar la calificación X Fuente: Autor

A continuación se detallan estas interfaces de usuario. 69

 Crear/modificar instancias

Mediante el formulario que aparece en la imagen inferior, el usuario podrá introducir los campos necesarios para crear o modificar una instancia del plugin Twitter Integration.

o General: En esta sección introduciremos el nombre que le daremos a la instancia, el hashtag requerido y una descripción. o Disponibilidad: Aquí debemos indicar desde que fecha y hasta cuándo estará disponible la instancia. o Calificación: Este parámetro controla la categoría en la que las calificaciones de la instancia están ubicadas en el libro de calificaciones. o Calificaciones: En esta sección debemos seleccionar en primer lugar el tipo de calificación que se desea implementar de entre los siguientes: . Promedio de calificaciones: La media de todas las calificaciones. . Número de calificaciones: El número de elementos calificados se convierte en la nota final. . Máxima calificación: La calificación más alta se convierte en la nota final. . Mínima calificación: La calificación más baja se convierte en la nota final. . Suma de calificaciones: Todas las calificaciones se suman. En segundo lugar debemos establecer cuál será el valor de la escala a utilizar (1-100). Y por último elegir si se desea limitar las calificaciones a los elementos con fechas en un determinado rango (función solo disponible desde la versión 2.3). o Ajustes comunes del módulo: Este bloque es común a todos los módulos de Moodle. Aquí podremos seleccionar si queremos que el módulo aparezca visible o no para los alumnos, asignarle un campo ID específico, o seleccionar algún modo de grupo.

Figura 11. Crear / modificar instancia Twitter Integration Fuente: Autor.

 Listado de instancias.

En este listado el usuario podrá ver las instancias que ha configurado dentro de un curso. Haciendo clic sobre uno de ellos le llevará a la página principal de la instancia.

Figura 12. Listado de instancias Twitter Integration Fuente: Autor

 Visualizar las interacciones

A manera de listado el usuario podrá visualizar las interacciones realizadas hasta el momento en la instancia, ordenados por fecha (Figura 13-c).

 Listar los hashtags

Ingresando a la instancia, el usuario podrá visualizar a manera de nube de etiquetas todos los hashtags que se han empleado en la instancia (Figura 13-b).

 Componer un tweet

Mediante el cuadro de texto que aparece en la Figura 13-a, el usuario tendrá la capacidad de componer un nuevo tweet, primero deberá iniciar sesión con sus credenciales de Twitter y luego estará habilitado para componer y publicar el respectivo tweet.

 Visualizar la calificación

Si el parámetro de calificación está configurado en la instancia, y si un usuario con los permisos necesarios para calificar (profesor, administrador) ha establecido la misma, el estudiante podrá visualizar su nota en la parte inferior de su interacción (Figura 13-d). Adicionalmente podrá hacer clic en la misma y visualizará que usuario ha brindado la calificación, y la fecha en que la ha establecido (Figura 14).

Figura 13. Instancia del plugin Twitter Integration Fuente: Autor

Figura 14. Visualizar calificación interacción Twitter Integration Fuente: Autor

3.2.3.2.2. Iteración 2

Las interfaces con las que contará el plugin Facebook Integration son las siguientes:

Tabla 10. Interfaces de usuario plugin Facebook Integration Listado Formulario Crear/modificar instancias X Listado de instancias X Visualizar las interacciones X Componer un post X Visualizar la calificación X Fuente: Autor

A continuación se detallan estas interfaces de usuario.

 Crear/modificar instancias

Mediante el formulario que aparece en la imagen inferior, el usuario podrá introducir los campos necesarios para crear o modificar una instancia del plugin Facebook Integration.

o General: En esta sección introduciremos el nombre que le daremos a la instancia, el hashtag requerido y una descripción. o Grupo de Facebook: En este apartado seleccionaremos el grupo de Facebook, en el cuál se publicará la actividad y las respectivas interacciones dentro de la misma o Calificación: En esta sección debemos seleccionar en primer lugar el tipo de calificación que se desea implementar de entre los siguientes: . Promedio de calificaciones: La media de todas las calificaciones.

. Número de calificaciones: El número de elementos calificados se convierte en la nota final. . Máxima calificación: La calificación más alta se convierte en la nota final. . Mínima calificación: La calificación más baja se convierte en la nota final. . Suma de calificaciones: Todas las calificaciones se suman. En segundo lugar debemos establecer cuál será el valor de la escala a utilizar (1-100). Y por último elegir si se desea limitar las calificaciones a los elementos con fechas en un determinado rango (función solo disponible desde la versión 2.3). o Ajustes comunes del módulo: Este bloque es común a todos los módulos de Moodle. Aquí podremos seleccionar si queremos que el módulo aparezca visible o no para los alumnos. Asignarle un campo ID específico, o seleccionar algún modo de grupo.

Figura 15. Crear/modificar instancia Facebook Integration Fuente: Autor

 Listado de instancias.

En este listado el usuario podrá ver las instancias que están creadas y configuradas dentro de un curso. Haciendo clic sobre uno de ellos le llevará a la página principal de la instancia.

Figura 16. Listado de instancias Facebook Integration Fuente: Autor

 Visualizar las interacciones

A manera de listado el usuario podrá visualizar las interacciones realizadas hasta el momento en la instancia, ordenados por fecha (Figura 17Figura 13-b).

 Componer un post

Mediante el cuadro de texto que aparece en la Figura 17-a, el usuario tendrá la capacidad de componer un nuevo post, primero deberá iniciar sesión en Facebook y luego estará habilitado para componer y publicar el respectivo post.

 Visualizar la calificación

Si el parámetro de calificación está configurado en la instancia, y si un usuario con los permisos necesarios para calificar (profesor, administrador) ha establecido la misma, el estudiante podrá visualizar su nota en la parte inferior de su interacción (Figura 17-c). Adicionalmente podrá hacer clic en la misma y visualizará que usuario ha brindado la calificación, y la fecha en que la ha establecido (Figura 14).

Figura 17. Instancia del plugin Facebook Integration Fuente: Autor

Figura 18. Visualizar calificación interacción Facebook Integration Fuente: Autor 77

3.2.3.3. Diagrama de componentes.

El diagrama de componentes visualiza de forma directa los directorios y ficheros que componen los plugins Twitter Integration y Facebook Integration, en sus respectivas versiones.

3.2.3.3.1. Iteración 1 con Moodle versión 1.9.19

Figura 19. Diagrama de componentes Iteración 1 con Moodle versión 1.9.19 Fuente: Autor

 Twitter Integration: Directorio que contiene todos los ficheros y carpetas del plugin. o index.php: Este fichero es el encargado de listar todas las instancias creadas del plugin. o lib.php: Contiene una serie de funciones necesarias para el plugin, además de invocaciones a la diversas API‟s propias de Moodle. o icon.gif: Icono gráfico del módulo. o mod_form.php: Este fichero es utilizado cuando se crea o edita alguna instancia del plugin. o rate.php: Contiene las funciones esenciales para calificar una interacción dentro de la instancia.

o rate_ajax.js: Fichero con funciones codificadas en lenguaje javascript para la función de calificar una interacción. o report.php: Contiene funciones para visualizar la calificación otorgada a una interacción. o styles.php: Hoja de estilos CSS. o versión.php: Contiene el número de versión actual del plugin. o view.php: Página de visualización principal del plugin. o db: Directorio que contiene los ficheros relacionados con la base de datos. . access.php: Contiene todas las capacidades o permisos que utiliza el plugin. . install.xml: Declaración de las tablas de la base de datos. . upgrade.php: Instrucciones de actualización de la base de datos. o js: Directorio que contiene los ficheros javascript relacionados con la creación de un nuevo tweet. . jquery-2.0.3.min.js: Librería javascript. . limitnewtweet.min.js: Fichero utilizado para realizar el límite de cada tweet (140 caracteres). o lang: Directorio que contiene los ficheros de cadenas de idioma y de ayuda. Habrá una carpeta por cada idioma soportado por el plugin. . en_utf8: Directorio que contiene los archivos de ayuda y las cadenas de idioma en inglés  twitterintegration.php: Cadenas de idioma del plugin en inglés.  help: Directorio que contiene los ficheros de ayuda del plugin en inglés. . es_utf8: Directorio que contiene los archivos de ayuda y las cadenas de idioma en español.  twitterintegration.php: Cadenas de idioma del plugin en español.  help: Directorio que contiene los ficheros de ayuda del plugin en español. o twitter: Directorio que contiene los ficheros correspondientes para la conexión con la plataforma Twitter. . callback.php: Luego de la autorización por parte del usuario en Twitter, esta URL es llamada con el parámtero oauth_token.

. config: Este fichero define las variables necesarias para conectarse a la REST Api de Twitter. . logout.php: Funciones para realizar un cierre de sesión de Twitter, más no de la plataforma Moodle. . newtweet.php: Fichero que contiene las funciones para realizar el envío de un nuevo tweet desde la plataforma Moodle hacia Twitter. . OAuth.php: Librería escrita en PHP para trabajar con OAuth API de Twitter. . twitteroauth.php: Librería PHP de TwitterOauth. . tweet-actions.png: Íconos de acciones de Twitter (retweet, responder, favorito). . twitter-bird-light.png: Ícono gráfico de Twitter.

3.2.3.3.2. Iteración 1 con Moodle versión 2.6

Figura 20. Diagrama de componentes Iteración 1 con Moodle versión 2.6 Fuente: Autor

Las principales diferencias entre el diagrama de componentes de la Iteración 1 (Twitter Integration) con Moodle versión 1.9.19 y Moodle versión 2.6 son las siguientes:

 Directorio pix: En este nuevo directorio se incluyen los íconos gráficos del plugin.  Los ficheros con las funciones de calificar y visualizar la valoración de una interacción son desarrollados por Moodle, y llamados mediante su respectiva API en el fichero lib.php.  Las cadenas de idioma y de ayuda del plugin se encuentran es un mismo fichero: twitterintegration.php. Se mantiene la estructura de un directorio para cada idioma soportado por el plugin.

3.2.3.3.3. Iteración 2 con Moodle versión 1.9.19

Figura 21. Diagrama de componentes Iteración 2 con Moodle versión 1.9.19 Fuente: Autor

 Facebook Integration: Directorio que contiene todos los ficheros y carpetas del plugin. o index.php: Este fichero es el encargado de listar todas las instancias creadas del plugin. o lib.php: Contiene una serie de funciones necesarias para el plugin, además de invocaciones a las librerías propias de Moodle. o icon.gif: Icono gráfico del módulo. o mod_form.php: Este fichero es utilizado cuando se crea o edita alguna instancia del plugin. o rate.php: Contiene las funciones esenciales para calificar una interacción dentro de la instancia. o rate_ajax.js: Fichero con funciones codificadas en lenguaje javascript para la función de calificar una interacción.

o report.php: Contiene funciones para visualizar la calificación otorgada a una interacción. o styles.php: Hoja de estilos CSS. o versión.php: Contiene el número de versión actual del plugin. o view.php: Página de visualización principal del plugin. o db: Directorio que contiene los ficheros relacionados con la base de datos. . access.php: Contiene todas las capacidades o permisos que utiliza el plugin. . install.xml: Declaración de las tablas de la base de datos. . upgrade.php: Instrucciones de actualización de la base de datos. o lang: Directorio que contiene los ficheros de cadenas de idioma y de ayuda. Habrá una carpeta por cada idioma soportado por el plugin. . en_utf8: Directorio que contiene los archivos de ayuda y las cadenas de idioma en inglés  facebookintegration.php: Cadenas de idioma del plugin en inglés.  help: Directorio que contiene los ficheros de ayuda del plugin en inglés. . es_utf8: Directorio que contiene los archivos de ayuda y las cadenas de idioma en español.  facebookintegration.php: Cadenas de idioma del plugin en español.  help: Directorio que contiene los ficheros de ayuda del plugin en español. o facebook: Directorio que contiene los ficheros correspondientes para la conexión con la plataforma Facebook. . facebook-php-sdk-v4: Este repositorio contiene el SDK PHP de código abierto que le permite acceder a la plataforma Facebook desde la aplicación PHP. . config: Este fichero define las variables necesarias para conectarse a la Graph API de Facebook. . logout.php: Cierre de sesión segura de la plataforma Facebook, más no de la plataforma de Moodle. . newpost.php: Fichero que contiene las funciones para realizar el envío de un nuevo post desde la plataforma Moodle hacia Facebook. . facebook-icon.png: Ícono gráfico de Facebook. 83

3.2.3.3.4. Iteración 2 con Moodle versión 2.6

Figura 22. Diagrama de componentes Iteración 2 con Moodle versión 2.6 Fuente: Autor

Dentro de las diferencias que se aprecian entre los diagramas de componentes de la Iteración 2 (Facebook Integration) con Moodle versión 1.9.19 y Moodle versión 2.6 son las siguientes:

 Directorio pix: En este nuevo directorio se incluyen el ícono gráfico del plugin, y cualquier otro gráfico que se utilice dentro del plugin.  Los ficheros con las funciones de calificar y visualizar la valoración de una interacción son desarrollados por Moodle, y llamados mediante su respectiva API en el fichero lib.php.  Las cadenas de idioma y de ayuda del plugin se encuentran es un mismo fichero: twitterintegration.php. Se mantiene la estructura de un directorio para cada idioma soportado por el plugin.

3.2.4. Fase IV: Pruebas.

Cuando el desarrollo de los componentes ha finalizado, se prosigue a realizar la correcta verificación de las pruebas de Integridad de datos y pruebas de funcionamiento de los componentes. La ejecución de estas pruebas permite verificar que cada componente funcione correctamente y cumpla con los requisitos planteados.

3.2.4.1. Pruebas de integridad de datos

Las pruebas de integridad de datos, buscan comprobar que el acceso y manipulación de los datos generados, son correctos y sus resultados están de acuerdo a los datos de prueba utilizados.

Para ello, se invoca cada método y proceso de acceso a la base de datos, con datos válidos e inválidos. Luego se procede a inspeccionar la base de datos para asegurar que los datos han sido cargados y manipulados como se pretendía.

3.2.4.2. Pruebas de funcionamiento

Las pruebas de funcionamiento se basan en las historias de usuario y tienen como objetivo verificar la apropiada aceptación de datos, procesamiento y recuperación. Este tipo de pruebas están basadas en la verificación de la aplicación (y sus procesos internos) mediante la interacción con la aplicación a través de la interfaz gráfica y analizar los resultados obtenidos.

Las pruebas de integridad de datos y de funcionamiento de los componentes, conjuntamente con sus respectivos resultados se pueden apreciar en el ANEXO E: PRUEBAS.

CONCLUSIONES

Una vez culminado el proyecto, utilizando las redes sociales Twitter y Facebook como herramientas de socialización y discusión de temas en el EVA sobre la plataforma Moodle, se puntualizan las siguientes conclusiones:

 Este trabajo de fin de titulación contempla la recopilación de todos los elementos que un desarrollador debe tener en consideración para crear un nuevo componente para la plataforma Moodle; partiendo desde los requerimientos básicos de instalación de Moodle hasta la exploración de todos los recursos, reglas y recomendaciones para desarrollar nuevos componentes.

 A través del uso de las API‟s de Twitter (REST) y Facebook (Graph), y su complemento con la API de Moodle, se ha logrado desarrollar los componentes que permiten la interacción entre medios sociales abiertos y la plataforma educativa Moodle, presentando los “tweets” y los “posts” que los estudiantes y profesores envíen a Twitter y Facebook, en la plataforma Moodle.

 Mediante la Rating API de Moodle los componentes desarrollados poseen la capacidad de brindar una calificación a las interacciones desarrolladas en un curso Moodle.

 Cuando se utilizan los recursos de la REST API de Twitter, se debe tener especial cuidado para no sobrepasar los “límites de tasa” y además utilizar mecanismos para mantener los datos presentados en pantalla.

 El desarrollo de los componentes, fue diseñado y creado cumpliendo todos los aspectos de “Moodle Developers” permitiendo un acoplamiento total con las versiones estables de Moodle (a excepción de ciertas versiones), lo que garantiza su adaptabilidad y aplicabilidad.

 Se propone además la implementación de las estrategias didácticas SQA y Q3 conjuntamente con los plugins desarrollados en este trabajo.

RECOMENDACIONES

 Desarrollar proyectos de investigación implementando los componentes desarrollados en el Entorno Virtual de Aprendizaje de la UTPL.

 Capacitar a los docentes en estrategias didácticas aplicables a los plugins desarrollados.

 Los componentes desarrollados pueden ser compartidos con la comunidad de Moodle, permitiendo que muchos sitos que trabajen sobre esta plataforma, puedan incorporar estos nuevos plugins a sus actividades dentro del proceso de enseñanza- aprendizaje. Además puedan ser revisados y mejorados con ideas de personas dedicadas a la mejora sustancial de entornos virtuales de aprendizaje

 Utilizar el editor XMLDB de la plataforma Moodle para realizar el archivo install.xml, el cuál especifica como Moodle debe configurar la base de datos y las tablas respectivas del nuevo plugin.

 Activar los mensajes de depuración para diagnosticar problemas en el desarrollo de nuevos plugins y en general detectar problemas en todo el sitio Moodle.

 Explorar la API de Twitter utilizando la consola desarrollada por Apigee (https://dev.twitter.com/console). Facebook posee su Graph API Explorer que permite también examinar su API (https://developers.facebook.com/tools/explorer).

 Revisar continuamente el desarrollo y las actualizaciones de las API‟s de Twitter y Facebook, así como de la API de Moodle para asegurar el continuo y correcto funcionamiento de los componentes desarrollados.

 Desarrollar los componentes con el lenguaje PHP y cumplir con todas las reglas y recomendaciones de “Moodle Developers”.

BIBLIOGRAFÍA

Letelier, P., & Penadés, C. (Junio de 2006). Departamento de Sistemas Informáticos y Computación (DSIC),. Recuperado el Enero de 2011, de Universidad Politécnica de Valencia (UPV): http://www.cyta.com.ar/ta0502/v5n2a1.htm

Apache Friends. (s.f.). About the XAMPP project. Recuperado el 23 de Marzo de 2014, de https://www.apachefriends.org/about.html

Asensio, M., & Pol, E. (2002). Nuevos escenarios en educación: aprendizaje informal sobre el patrimonio, los museos y la ciudad. Buenos Aires: AIQUE.

Avgeriou, P., Papasalourus, A., & Retalis, S. (2001). Web-Based Learning Environments: Issues, Trends, Challenges. Proceedings of the 1 st IOSTE Symposium in Southern Europe, Science and Technology Education.

Ayerdi, K. M., Pérez, J. Á., & Mendiguren, T. (2011). La implementación de las redes sociales en la enseñanza superior universitaria. Tejuelo, 137-155.

Bello Díaz, R. (2005). Educación Virtual: Aulas sin Paredes. Recuperado el 24 de Febrero de Marzo, de http://www.educar.org/articulos/educacionvirtual.asp

Belloch Ortí, C. (s.f.). Entornos Virtuales de Aprendizaje. Recuperado el 23 de Febrero de 2014, de http://moodle2.unid.edu.mx/dts_cursos_mdl/pos/ED/AV/AM/07/Entornos.pdf

Boneu, J. (2007). Plataformas abiertas de e-learning para el soporte de contenidos educativos abiertos. Recuperado el 23 de Febrero de 2014, de http://www.uoc.edu/rusc/4/1/dt/esp/boneu.pdf

Bustos González, A. (2005). Estrategias didácticas para el uso de las TIC's en la docencia universitaria presencial. Recuperado el 21 de Febrero de 2014, de http://agora.ucv.cl/manual/manual.pdf

Calzadilla, M. (2000). Aprendizaje Colaborativo y Tecnologías de la Información y Comunicación. OEI-Revista Iberoamericana de Educación.

Canós, J., Letelier, P., & Penadés, M. (2005). Métodologías ágiles para el desarrollo de software.

Cormier, D. (08 de Diciembre de 2010). What is a MOOC? Recuperado el 21 de Febrero de 2014, de YouTube: https://www.youtube.com/watch?v=eW3gMGqcZQc

Couros, A. (2008). EC&I 831: Social Media & Open Education. Recuperado el 21 de Febrero de 2013, de http://eci831.ca/

Day, N. (1998). Informal learning. Workforce,.

De la Torre, F. (2005). 12 lecciones de pedagogía, educación y didáctica. Mexico: Alfaomega.

Díaz-Antón, G. (2010). Hacia una ontología sobre LMS. Laboratorio de Investigación en Sistemas de Información. Venezuela: Universidad Simón Bolívar.

Downes, S. (2011). Social Network Technologies for Learning. Recuperado el 21 de Julio de 2014, de Stephen's Web: http://www.downes.ca/presentation/283

Downes, S., & Siemens , G. (2008). Connectivism and Connective Knowledge. Recuperado el 20 de Febrero de 2014, de http://cckno8.wordpress.com/

Drechsler, M. (2011). Moodle structural overview. Recuperado el 24 de Marzo de 2014, de http://www.slideshare.net/mark.drechsler/moodle-structural-overview

Echeverry, L., & Delgado, L. (2007). Caso práctico de la metodología ágil XP al desarrollo de software.

Ertmer, P., & Newby, T. J. (1993). Behaviorism, Cognitivism, Constructivism: Comparing Critical Features from an Instructional Design Perspective. Performance Improvement Quarterly, 50-72.

Esteve, F. (2009). Bolonia y las TIC: de la docencia 1.0 al aprendizaje 2.0. La Cuestión Universitaria, 55-68.

Facebook Inc. (s.f.). Graph API. Recuperado el 15 de Marzo de 2014, de https://developers.facebook.com/docs/graph-api

Falcón-Villaverde, M. (2013). La educación a distancia y su relación con las nuevas tecnologías de la información y las comunicaciones. Recuperado el 23 de Febrero de 2014, de http://www.medisur.sld.cu/index.php/medisur/article/view/2418

Falk, J., & Dierking, L. (1992). The museum experience. Washington DC: Whalesback books.

Freire, J. (2007). Los retos y oportunidades de la Web 2.0 para las universidades. La gran guía de los blogs.

Griego, A. (2011). Facebook como aula virtual alternativa. Recuperado el 21 de Julio de 2014, de http://vimeo.com/35742799

Gros, B. (1995). Teorías cognitivas de enseñanza y aprendizaje. Barcelona: EUB.

Guitert, M., & Giménez, F. (2000). El trabajo cooperativo en entornos virtuales de aprendizaje. Aprender en la virtualidad, 113-134.

Haro, J. (2009). Las redes sociales aplicadas a la práctica docente. Didáctica, Innovación y Multimedia.

Herrera, M. Á. (2013). Las Redes sociales como entornos académicos en la enseñanza universitaria. Revista Iberoamericana para la Investigación y el Desarrollo Educativo.

Hunt, T. (2012). The Architecture of Open Source Applications. Recuperado el 16 de Abril de 2014, de http://aosabook.org/en/moodle.html

Johnson, D., Johnson, R., Holubec, E., & Roy, P. (1993). Circles of learning.

Kaplan-Leiserson. (2010). American Society for Training and Development, Glosay.

Koyanagi, M. (1999). Putting courses online: Theory and Practice. Chapel Hill: University of North Carolina.

Luján, S. (2012). ¿Qué son los MOOCs? Recuperado el 21 de Febrero de 2014, de http://desarrolloweb.dlsi.ua.es/cursos/2012/que-son-los-moocs

Marsick, V., & Watkins, K. (1990). Informal and incidental learning in the workplace. London: Routledge.

Mejía, R. (2005). Tendencias actuales en la investigación del aprendizaje informal. Revista Electrónica Sinéctica.

Michavila, F., & Parejo, J. (2008). Políticas de participación estudiantil en el Proceso de Bolonia. Revista de Educación, 85-118.

Moodle. (2008). Manual de Estilo de Código - Moodle Docs. Recuperado el 23 de Marzo de 2014, de http://docs.moodle.org/all/es/Manual_de_Estilo_de_C%C3%B3digo

Moodle. (2009). Manual de estilo de interfaz - Moodle Docs. Recuperado el 23 de Febrero de 2014, de http://docs.moodle.org/all/es/Manual_de_estilo_de_la_interfaz

Moodle. (2011). Hardening new Roles system. Recuperado el 24 de Marzo de 2014, de http://docs.moodle.org/dev/Hardening_new_Roles_system

Moodle. (2014). About Moodle. Recuperado el 22 de Febrero de 2014, de http://docs.moodle.org/26/en/About_Moodle

Moodle. (23 de Abril de 2014). Actividades - Moodle Docs. Recuperado el 24 de Abril de 2014, de http://docs.moodle.org/all/es/Actividades

Moodle. (2014). Activity modules - Moodle Docs. Recuperado el 24 de Marzo de 2014, de http://docs.moodle.org/dev/Activity_modules

Moodle. (23 de Marzo de 2014). Bloques - Moodle Docs. Recuperado el 24 de Abril de 2014, de http://docs.moodle.org/all/es/Bloques

Moodle. (2014). Coding style - Moodle Docs. Recuperado el 24 de Marzo de 2014, de http://docs.moodle.org/dev/Coding_style

Moodle. (2014). Core APIs - Moodle Docs. Recuperado el 24 de Febrero de 2014, de http://docs.moodle.org/dev/Core_APIs

Moodle. (2014). lib/formslib.php Form Definition - Moodle Docs. Recuperado el 24 de Marzo de 2014, de http://docs.moodle.org/dev/lib/formslib.php_Form_Definition

Moodle. (27 de Marzo de 2014). Recursos - MoodleDocs. Recuperado el 24 de Abril de 2014, de http://docs.moodle.org/all/es/Recursos

Nisan, N., & Schocken, S. (2005). From NAND to Tetris. Recuperado el 21 de Febrero de 2014, de http://nand2tetris.org/

Orihuela, J. (2009). Redes sociales y educación. Recuperado el 21 de Julio de 2014, de http://www.ecuaderno.com/2009/03/10/redes-sociales-y-educacion/

Pimienta, J. (2008). Constructivismo: Estrategias para aprender a aprender. Pearson Educación de México.

Quezada Viay, A. (2011). Uso educativo de redes sociales. Recuperado el 21 de Julio de 2014, de http://www.slideshare.net/AlfonsoQuezadaViay/uso-educativo-facebook

Rebollo, M. (2007). Aprendizaje colaborativo a traves de las TIC. Recuperado el 23 de Mayo de 2014, de http://www.slideshare.net/mrebollo/aprendizaje-colaborativo-a-travs-de- las-tic

Reynoso, C. (2004). Metodos Agiles en Desarrollo de Software, Introducción a la Arquitectura de Software. Universidad de Buenos Aires.

Ribes, X. (2007). La web 2.0. El valor de los metadatos y de la inteligencia colectiva. TELOS Cuadernos de Comunicación e Innovación.

Rotter, J. (1954). Social learning and clinical psychology. New York: Prentice-Hall.

Shuell, T. (1990). Phases of meaningful learning. Review of Educational Research, 531-547.

Siemens, G. (2005). Connectivism: A Learning Theory for the Digital Age. Recuperado el 21 de Febrero de 2014, de http://www.elearnspace.org/Articles/connectivism.htm

Thrun , S., & Norvig, P. (2011). Introduction to Artificial Intelligence. Recuperado el 21 de Febrero de 2013, de https://www.udacity.com/course/cs271

Torres-Diaz, J. (2012). Evolución de los Entornos Virtuales de Aprendizaje: las redes sociales de aprendizaje. Terceras Jornadas Internacionales sobre Campus Virtuales. Oviedo, España.

Torres-Diaz, J., Jara, D. I., & Valdiviezo, P. (2013). Integración de redes sociales y entornos virtuales de aprendizaje. RED, Revista de Educación a Distancia.

Twitter Inc. (s.f.). REST API v1.1 Resources. Recuperado el 15 de Marzo de 2014, de https://dev.twitter.com/docs/api/1.1

Valdés Sagüés, M. (1999). La difusión cultural en el museo: servicios destinados al gran público. Gijón: Trea.

Wiley, D. (2005). Introduction to Open Education. Recuperado el 21 de Febrero de 2014, de http://ocw.usu.edu/instructional-technology-learning-sciences/introduction-to-open- education/index.html

Willard, B. (1993). Museums as center of learning. Teacher, 94(4).

ANEXOS

ANEXO A: HISTORIAS DE USUARIO

4.1.1. Iteración 1: Desarrollo del plugin Twitter Integration.

Historia de usuario 1: Crear nueva instancia del plugin Twitter Integration

Tabla 11. Historia de usuario 1: Crear nueva instancia del plugin Twitter Integration Historia de Usuario Número: 1 Nombre: Crear nueva instancia del plugin Twitter Integration

Usuario: Profesor – Administrador Iteración Asignada: 1

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

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

Descripción:

Un usuario con rol de profesor o administrador, podrá seleccionar el plugin de actividad Twitter Integration para añadirlo a un curso.

Para esto, primeramente el usuario deberá haber iniciado sesión en Moodle, ingresar al curso en el cual se desea crear la instancia del plugin, hacer clic en Activar Edición, seleccionar el plugin Twitter Integration, llenar el formulario para la configuración de la instancia, presionar el botón Guardar cambios, y por último clic en Desactivar edición.

Observaciones:

Fuente: Autor

Historia de usuario 2: Editar configuración de instancia del plugin Twitter Integration

Tabla 12. Historia de usuario 2: Editar configuración de instancia del plugin Twitter Integration Historia de Usuario Número: 2 Nombre: Editar configuración de instancia del plugin Twitter Integration

Usuario: Profesor – Administrador Iteración Asignada: 1

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

Riesgo en Desarrollo: Alto Puntos Reales: 5

(Alto / Medio / Bajo)

Descripción:

Un usuario con rol de profesor o administrador, podrá configurar una instancia del plugin de actividad Twitter Integration.

Primeramente el usuario deberá haber iniciado sesión en Moodle, ingresar al curso en el cual está creada la instancia del plugin, presionar el botón Activar edición, hacer clic en el enlace Editar, configurar los campos requeridos en el formulario, presionar el botón Guardar cambios, y finalmente clic en Desactivar edición.

Observaciones:

Fuente: Autor

Historia de usuario 3: Eliminar instancia del plugin Twitter Integration

Tabla 13. Historia de usuario 3: Eliminar instancia del plugin Twitter Integration Historia de Usuario Número: 3 Nombre: Eliminar instancia del plugin Twitter Integration

Usuario: Profesor – Administrador Iteración Asignada: 1

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

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

Descripción:

Un usuario con rol de profesor o administrador, podrá eliminar una instancia del plugin de actividad Twitter Integration en cualquier momento que lo desee.

El usuario deberá haber iniciado sesión en Moodle, ingresar al curso en el cual está creada la instancia del plugin, presionar el botón Activar edición, hacer clic en el enlace Eliminar, confirmar que se desea eliminar la instancia, y por último Desactivar edición.

Observaciones:

Fuente: Autor

Historia de usuario 4: Listar las interacciones en la instancia

Tabla 14. Historia de usuario 4: Listar las interacciones en la instancia Historia de Usuario Número: 4 Nombre: Listar las interacciones en la instancia

Usuario: Profesor – Administrador - Alumno Iteración Asignada: 1

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

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

Descripción:

Un usuario identificado con rol de profesor, administrador o alumno, podrá visualizar a manera de listado todas las interacciones (tweets) pertenecientes a la instancia, en un curso determinado.

El usuario primeramente deberá haber iniciado sesión en Moodle, ingresar al curso en el cual está creada la instancia del plugin, seleccionar la instancia determinada y podrá observar las interacciones en una lista ordenada por fecha.

Observaciones:

Las interacciones deberán poseer las funciones básicas de un tweet, es decir: Responder, Retweet, Favorito

Fuente: Autor

Historia de usuario 5: Asignar calificaciones a las interacciones

Tabla 15. Historia de usuario 5: Asignar calificaciones a las interacciones Historia de Usuario Número: 5 Nombre: Asignar calificaciones a las interacciones

Usuario: Profesor – Administrador Iteración Asignada: 1

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

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

Descripción:

Un usuario con rol de profesor o administrador, podrá asignar una calificación a determinada interacción dentro de una instancia.

Primeramente el usuario debe haber iniciado sesión en Moodle, ingresar al curso en el cual está creada la instancia del plugin, seleccionar la instancia determinada, y por cada interacción determinar una calificación.

Observaciones:

Para asignar una calificación, la instancia previamente debe estar configurada para realizar esta función.

Fuente: Autor

Historia de usuario 6: Visualizar la calificación brindada a una interacción

Tabla 16. Historia de usuario 6: Visualizar una calificación Historia de Usuario Número: 6 Nombre: Visualizar una calificación

Usuario: Profesor – Administrador – Alumno Iteración Asignada: 1

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

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

Descripción:

Un usuario identificado con rol de profesor, administrador podrá visualizar las calificaciones brindadas a las interacciones. Un usuario alumno sólo podrá visualizar la calificación de su interacción.

El usuario debe haber iniciado sesión en Moodle, ingresar al curso en el cual está creada la instancia del plugin, seleccionar la instancia determinada, y podrá visualizar la calificación de la interacción

Observaciones:

Para visualizar la calificación, previamente debe estar determinada y la instancia configurada para calificar.

Fuente: Autor

Historia de usuario 7: Componer un nuevo tweet

Tabla 17. Historia de usuario 7: Componer un nuevo tweet Historia de Usuario Número: 7 Nombre: Componer un nuevo tweet

Usuario: Profesor – Administrador – Alumno Iteración Asignada: 1

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

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

Descripción:

Un usuario identificado con rol de profesor, administrador o alumno, podrá componer y enviar un nuevo tweet desde la plataforma Moodle hacia Twitter.

El usuario debe haber iniciado sesión en Moodle, ingresar al curso en el cual está creada la instancia del plugin, seleccionar la instancia determinada, iniciar sesión con sus credenciales en Twitter, automáticamente autorizada la aplicación se redirige hacia la instancia del plugin, donde podrá componer y publicar un nuevo tweet.

Observaciones:

Para iniciar sesión en Twitter, debe presionar el botón Iniciar sesión, ingresar sus credenciales y autorizar a la aplicación.

Fuente: Autor

Historia de usuario 8: Listar los hashtags utilizados

Tabla 18. Historia de usuario 8: Listar los hashtags utilizados Historia de Usuario Número: 8 Nombre: Listar los hashtags utilizados

Usuario: Profesor – Administrador – Alumno Iteración Asignada: 1

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

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

Descripción:

Un usuario identificado con rol de profesor, administrador o alumno, podrá visualizar, a manera de nube de etiquetas, un listado de los hashtags utilizados en la instancia, diferentes al configurado obligatoriamente.

El usuario debe haber iniciado sesión en Moodle, ingresar al curso en el cual está creada la instancia del plugin, seleccionar la instancia, y podrá observar la nube de etiquetas con los hashtags utilizados dentro de la instancia.

Observaciones:

Fuente: Autor

4.1.2. Iteración 2: Desarrollo del plugin Facebook Integration.

Historia de usuario 9: Crear nueva instancia del plugin Facebook Integration

Tabla 19. Historia de usuario 9: Crear nueva instancia del plugin Facebook Integration Historia de Usuario Número: 9 Nombre: Crear nueva instancia del plugin

Usuario: Profesor – Administrador Iteración Asignada: 2

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

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

Descripción:

Un usuario con rol de profesor o administrador, podrá seleccionar el plugin de actividad Facebook Integration para añadirlo a un curso.

El usuario primeramente deberá haber iniciado sesión en Moodle, ingresar al curso en el cual se desea crear la instancia del plugin, hacer clic en Activar Edición, seleccionar el plugin Facebook Integration, completar el formulario para la configuración de la instancia, presionar el botón Guardar cambios, y por último clic en Desactivar edición.

Observaciones:

Primeramente debe estar creado un grupo en la plataforma Facebook, requisito indispensable para este plugin

Fuente: Autor

Historia de usuario 10: Editar configuración de instancia del plugin Facebook Integration

Tabla 20. Historia de usuario 10: Editar configuración de instancia del plugin Facebook Integration Historia de Usuario Número: 10 Nombre: Editar configuración de instancia del plugin Facebook Integration

Usuario: Profesor – Administrador Iteración Asignada: 2

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

100

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

Descripción:

Un usuario identificado con rol de profesor o administrador, podrá configurar una instancia del plugin de actividad Facebook Integration.

El usuario deberá haber iniciado sesión en Moodle, ingresar al curso en el cual está creada la instancia del plugin, presionar el botón Activar edición, hacer clic en el enlace Editar, configurar los campos requeridos en el formulario, presionar el botón Guardar cambios, y finalmente clic en Desactivar edición.

Observaciones:

Fuente: Autor

Historia de usuario 11: Eliminar instancia del plugin Facebook Integration

Tabla 21. Historia de usuario 11: Eliminar instancia del plugin Facebook Integration Historia de Usuario Número: 11 Nombre: Eliminar instancia del plugin Facebook Integration

Usuario: Profesor – Administrador Iteración Asignada: 2

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

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

Descripción:

Un usuario con rol de profesor o administrador, podrá eliminar una instancia del plugin de actividad Facebook Integration en cualquier momento que lo desee.

Observaciones:

Se elimina todas las interacciones de la base de datos de Moodle, los post publicados por este plugin se mantienen en el grupo de la plataforma Facebook.

Fuente: Autor 101

Historia de usuario 12: Listar las interacciones en la instancia Facebook Integration

Tabla 22. Historia de usuario 12: Listar las interacciones en la instancia Facebook Integration Historia de Usuario Número: 12 Nombre: Listar las interacciones en la instancia Facebook Integration

Usuario: Profesor – Administrador - Alumno Iteración Asignada: 2

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

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

Descripción:

Un usuario identificado con rol de profesor, administrador o alumno, podrá visualizar a manera de listado todas las interacciones (posts) pertenecientes a la instancia, en un curso determinado.

Observaciones:

Fuente: Autor

Historia de usuario 13: Asignar calificaciones a las interacciones

Tabla 23. Historia de usuario 13: Asignar calificaciones a las interacciones Historia de Usuario Número: 13 Nombre: Asignar calificaciones a las interacciones

Usuario: Profesor – Administrador Iteración Asignada: 2

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

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

Descripción:

Un usuario con rol de profesor o administrador, podrá asignar una calificación a determinada interacción dentro de una instancia.

102

Primeramente el usuario debe haber iniciado sesión en Moodle, ingresar al curso en el cual está creada la instancia del plugin Facebook Integration, seleccionar la instancia determinada, y por cada interacción determinar una calificación.

Observaciones:

Para asignar una calificación, la instancia previamente debe estar configurada para realizar esta función.

Fuente: Autor

Historia de usuario 14: Visualizar la calificación brindada a una interacción

Tabla 24. Historia de usuario 14: Visualizar una calificación Historia de Usuario Número: 14 Nombre: Visualizar una calificación

Usuario: Profesor – Administrador – Alumno Iteración Asignada: 1

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

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

Descripción:

Observaciones:

Para visualizar la calificación, previamente debe estar determinada y la instancia configurada para calificar.

Fuente: Autor

Historia de usuario 15: Componer un nuevo post

Tabla 25. Historia de usuario 15: Componer un nuevo post Historia de Usuario Número: 15 Nombre: Componer un nuevo post

103

Usuario: Profesor – Administrador – Alumno Iteración Asignada: 2

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

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

Descripción:

Un usuario identificado con rol de profesor, administrador o alumno, podrá componer y enviar un nuevo post desde la plataforma Moodle hacia Facebook.

El usuario debe haber iniciado sesión en Moodle, ingresar al curso en el cual está creada la instancia del plugin, seleccionar la instancia determinada, iniciar sesión con sus credenciales en Facebook, automáticamente autorizada la aplicación se redirige hacia la instancia del plugin, donde podrá componer y publicar un nuevo post.

Observaciones:

Para iniciar sesión en Facebook, debe presionar el botón Iniciar sesión, ingresar sus credenciales y autorizar a la aplicación.

Fuente: Autor

Historia de usuario 16: Instalación de plugins

Tabla 26. Historia de usuario 16: Instalación de plugins Historia de Usuario Número: 16 Nombre: Instalación de plugins

Usuario: Administrador Iteración Asignada: 1 - 2

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

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

Descripción:

Un usuario con rol de administrador será el encargado de instalar en la plataforma de enseñanza virtual Moodle los plugins de actividad Twitter Integration y Facebook Integration.

104

Observaciones:

Fuente: Autor

Historia de usuario 17: Actualización de plugins

Tabla 27. Historia de usuario 17: Actualización de plugins Historia de Usuario Número: 17 Nombre: Actualización de plugins

Usuario: Administrador Iteración Asignada: 1 - 2

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

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

Descripción:

Un usuario con rol de administrador se encargará de realizar las modificaciones necesarias en los plugins de actividad Twitter Integration y Facebook Integration, y de llevar a cabo la actualización en Moodle.

Observaciones:

Fuente: Autor

Historia de usuario 18: Desinstalación de plugins

Tabla 28. Historia de usuario 18: Desinstalación de plugins Historia de Usuario Número: 18 Nombre: Desinstalación de plugins

Usuario: Administrador Iteración Asignada: 1 - 2

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

Riesgo en Desarrollo: Alto Puntos Reales: 5

105

(Alto / Medio / Bajo)

Descripción:

El administrador de Moodle llevará a cabo la tarea de desinstalar los plugins Twitter Integration y Facebook Integration del sistema

Observaciones:

Fuente: Autor

106

ANEXO B: MOODLE SISTEMA DE GESTIÓN DE APRENDIZAJE En este apartado revisaremos los conceptos más importantes relacionados con la arquitectura Moodle. Primeramente se describirá las características de Moodle. Luego revisaremos su entorno técnico, haciendo énfasis en los requisitos de sistema operativo, base de datos y servidor web. Posteriormente revisaremos el contenido de la estructura de directorios. A continuación se procederá a describir la estructura básica de un sitio Moodle, señalando con importancia los principales módulos que se pueden desarrollar para Moodle (actividades, recursos y bloques).

5.1.1. Moodle.

Moodle (acrónimo de Modular Object-Oriented Dynamic Learning Enviroment o Entorno de Aprendizaje Dinámico Orientado a Objetos y Modular) es una plataforma de aprendizaje diseñado para proporcionar a los educadores, administradores y estudiantes un solo sistema robusto, seguro e integrado para crear ambientes de aprendizaje personalizados (Moodle, 2014). La plataforma Moodle se puede considerar como un Sistema de Gestión de Aprendizaje

Un Sistema de Gestión de Aprendizaje (LMS por sus siglas en inglés) es un software basado en un servidor Web que provee módulos para administrar, distribuir y controlar las actividades de enseñanza-aprendizaje, simplificando de manera significativa estas tareas. El término LMS es el resultado de la evolución de los conceptos Content Management System (CMS) y de Learning Technology System (LTS) (Díaz-Antón, 2010).

Se distinguen como grupos funcionales de los sistemas de aprendizaje: gestión de cursos, gestión de clases, herramientas de comunicación, herramientas para los estudiantes, gestión del contenido, herramientas de evaluación y gestión de la institución educativa (Avgeriou, Papasalourus, & Retalis, 2001).

Los módulos de un LMS permiten, entre otras, crear cursos, configurar cursos, matricular alumnos, registrar profesores, llevar informes de progreso y calificaciones de los alumnos. Los LMS además facilitan el aprendizaje colaborativo conectivista, utilizando diferentes recursos y estrategias elaboradas, como pueden ser los foros, las videoconferencias, los chats, etc.

Moodle es un EVA que se ha convertido en un estándar gracias a su gran difusión y aceptación (Torres-Diaz, Jara, & Valdiviezo, 2013) y ya que se encuentra dentro de la categoría de LMS, puede ser utilizado tanto para desarrollar cursos totalmente online acorde 107

a la metodología del e-learning, que según la American Society of Training and Development (Kaplan-Leiserson, 2010) se define como el “término que cubre un amplio grupo de aplicaciones y procesos, tales como aprendizaje basado en Web, aprendizaje basado en computadora, aulas virtuales y colaboración digital. Incluye entrega de contenidos vía Internet, intranet/extranet, audio y videograbaciones, transmisiones vía satélite, TV interactiva, CD-ROM y más”. Como para desarrollar una modalidad de enseñanza basada en el b-learning, es decir, un modelo de aprendizaje que incluya tanto formación presencial como online (e-learning).

Entre las principales características de la plataforma Moodle, destacan las siguientes:

 Diseño modular que permita gran flexibilidad para agregar y suprimir funcionalidades.  Se ejecuta sin necesidad de cambios en el sistema operativo.  Soporta las principales marcas de manejadores de base de datos.  Interfaz de navegación sencilla, ligera, eficiente y compatible.  Sistema de calificaciones flexible, incorporando la posibilidad de evaluación por competencias.  Interoperabilidad: Autenticación, matriculación, contenido y utilización de la tecnología XML.

5.1.2. Entorno técnico.

La palabra Moodle es un acrónimo de Modular Object-Oriented Dynamic Learning Environment (Entorno de Aprendizaje Dinámico Orientado a Objetos y Modular) lo que resulta fundamentalmente útil para desarrolladores y teóricos de la educación.

Moodle está principalmente desarrollado en Linux usando Apache, MySQL y PHP (plataforma conocida comúnmente como LAMP). Adicionalmente también está analizado y verificado su correcto funcionamiento en Windows y Mac OS. Soporte para bases de datos PostgreSQL, Oracle y Microsoft SQL Server también está disponible.

108

Moodle

Base de datos: MySQL, Lenguaje de Servidor Web: Apache, PostgreSQL, Oracle, Programación: PHP IIS Microsoft SQL Server

Sistema Operativo: Linux, Windows, Mac OS

Figura 23. Plataforma LAMP (Linux), WAMP (Windows), MAMP (Mac OS) Fuente: Autor

Los requerimientos básicos para Moodle son los siguientes:

Moodle v1.9.x.

Hardware

 Espacio en disco: 160MB libres. Se necesitará más espacio libre para almacenar los materiales de enseñanza.  Memoria: 256MB (mínimo), 1GB (recomendado).

Software

 Moodle requiere un entorno de servidor web y se ejecutará en Apache e IIS fácilmente. Moodle debe funcionar en cualquier entorno de servidor que soporte PHP.  Moodle está escrito en el lenguaje de programación PHP. En la actualidad, Moodle v1.9.x requiere un mínimo de PHP v4.3.0 para funcionar.  Moodle usará MySQL, Microsoft SQL Server, PostgreSQL u Oracle como base de datos.

Moodle v2.6.

Hardware

 Espacio en disco: 160MB libre, además de todo lo que necesita para guardar sus materiales. 5GB es probablemente un mínimo realista.

109

 Backups: Recomendado el mismo espacio requerido anteriormente. Se recomienda una ubicación remota de preferencia.  Memoria: 256MB (mínimo), 1GB altamente recomendado.

Software

 Sistemas operativos como Linux y Windows son las opciones más comunes y con mayor soporte de usuarios. Moodle es probado regularmente con Debian, Ubuntu, CentOS, RedHat, Windows 7/XP y Mac OS X.  Servidor web principalmente Apache. No totalmente probado o compatible, pero debería funcionar en IIS, lightttpd, nginx, cherokee, zeus y LiteSpeed.  La versión mínima requerida de PHP es 5.3.3  MySQL y PostgreSQL son las bases de datos principales de desarrollo. MS SQL Server es apoyado totalmente, aunque la documentación y ayuda en línea no sea tan completa como MySQL/PostgreSQL. Oracle no es totalmente compatible, por lo tanto no se recomienda. o MySQL – versión mínima 5.1.33 versión mínima. o MariaDB - versión mínima 5.3.5. o PostgreSQL - versión mínima 8.3. o MSSQL - versión mínima 9.0. o Oracle - versión mínima 10.2 (no recomendado)  Ghostscript debe estar instalado para anotaciones pdf en asignaciones para trabajar.

5.1.3. Estructura de directorios.

Una instalación de Moodle se compone de tres partes (Hunt, 2012):

Código

El código de Moodle generalmente se ubica en una carpeta como /var/www/moodle o ~/htdocs/moodle. Esto no puede ser escribible por el servidor.

La siguiente captura de pantalla es un listado de los directorios de una instalación de Moodle 1.9.

110

Figura 24. Estructura de directorios Moodle v1.9 Fuente: Autor

En la siguiente captura de pantalla se aprecia un listado de los directorios de una instalación de Moodle 2.6.

111

Figura 25. Estructura de directorios Moodle v2.6 Fuente: Autor

A continuación describiremos la estructuración de las carpetas de Moodle, remarcando los directorios más importantes de ambas versiones.

 admin: Contiene los ficheros PHP, los cuales se encargan de controlar la interfaz de los usuarios administradores. Contiene además un archivo cron.php encargado de realizar tareas de mantenimiento del sistema.  auth: Desde aquí se controla la creación de usuarios y su acceso al sistema.  backup: Este directorio contiene las funciones para realizar copias de seguridad del núcleo del sistema: guardar, restaurar e importar cursos.  blocks: Contiene todos los bloques de moodle que se muestran a izquierda y derecha de la página. Son uno de los tipos más simples de módulos que se pueden realizar, y suelen funcionar a través de las versiones de Moodle sin apenas alguna modificación.  course: En este directorio se pueden cambiar la disposición de los elementos de los cursos e informes.

112

 enrol: En esta carpeta se incluyen todos los módulos de matriculación de Moodle. Contienen funciones de creación y administración de matriculaciones a un nivel de curso.  files: Desde este directorio Moodle realiza la incorporación de archivos a un curso. Permite subida de archivos, control de acceso y visualización de archivos. Desde Moodle 2.0 se pueden utilizar repositorios externos tales como: Alfresco, Google Docs, Dropbox.  filter: Los filtros de Moodle son una característica que permite la búsqueda y reemplazo basada en expresiones de testo y expresiones regulares.  lang: En esta carpeta se almacenan las cadenas de texto de idioma y localización de Moodle. Estos archivos son los que permiten la personalización del idioma de la plataforma.  lib: La carpeta lib almacena las librerías de funciones del núcleo del sistema de Moodle. Al momento de desarrollar plugins se utilizan funciones definidas en esta carpeta.  mod: En esta carpeta se almacenan los módulos o plugins de Moodle. Ya sean propios de la plataforma (tareas, wiki, lección, foro) o desarrollados. Cada plugin tiene su propia carpeta.  my: En esta carpeta se proporciona la lista de cursos en los que participa un usuario.  theme: La carpeta theme almacena todos los temas de Moodle y cualquier tema personalizado instalado en la plataforma. Cada tema tiene su propia carpeta.

Base de datos.

Las tablas de una base de datos de Moodle consta de aproximadamente doscientas tablas relacionadas. Moodle agrega un prefijo a todos los nombres de la tabla, por lo general mdl_; de esta manera está asegurado que se puede compartir una base de datos con otras aplicaciones, si se desea.

Datos de Moodle.

Se trata de una carpeta, conocida como moodledata, en la que Moodle almacena todos los archivos subidos y generados en la plataforma, así como algunos datos de sesión de los usuarios logueados. Esta carpeta tiene que ser escribible por el servidor web. Por razones de seguridad, la carpeta debe estar fuera de la raíz del servidor web.

La información de configuración de estas tres partes se almacena en un archivo llamado config.php en la raíz de la carpeta moodle cuando se ha instalado Moodle. 113

5.1.4. Estructura básica de un sitio Moodle

Un sitio Moodle está compuesto por: categorías, cursos, temas y actividades.

Sitio Moodle

Categoría 1 Categoría 2

Curso A Curso B

Semana 1 Semana 2 Semana 1

Actividad 1 Recurso 1 Bloque Recurso Actividad

Figura 26. Estructura básica de Moodle Fuente: Autor

 Categorías: Las categorías se definen como una colección de cursos. Sirven para organizarlos de manera que sean más fácilmente localizables por el alumno en la pantalla inicial de la plataforma.  Cursos: Los cursos son los espacios donde un profesor imparte materiales de aprendizaje para los alumnos. Son creados por el administrador del sitio.  Semanas o temas: Es la manera como un curso es organizado. Tras la creación del curso, los inscritos en el mismo podrán aprecias una serie de bloques que representan las semanas del curso o temas, según el formato que se haya establecido.  Actividades: Básicamente una actividad es algo que un alumno hará que interactúe con otros alumnos o con el profesor.  Recursos: Para profundizar en el aprendizaje, un profesor podrá incluir algún tipo de recurso adicional, como un archivo o enlace.

114

 Bloques: Los bloques son contenedores que se sitúan a los lados del sitio e implementan funciones extra fuera de las actividades y recursos.

A continuación revisaremos las actividades, recursos y bloques que componen el paquete estándar de instalación de Moodle.

Actividades

Las actividades que vienen instaladas por defecto en una instalación de Moodle 2.x son las siguientes (Moodle, 2014):

 Base de datos: Permite a los participantes crear, mantener y buscar dentro de un banco de entradas de registros.  Chat: Permite a los participantes tener una discusión sincrónica en tiempo real  Consulta: Un profesor realiza una pregunta y especifica una variedad de respuestas de opción múltiple.  Cuestionarios: Permite a un profesor diseñar y estructurar exámenes.  Encuesta predefinida: Función básica de una encuesta estándar, ayuda a los profesores a conocer sus alumnos y reflexionar sobre su enseñanza.  Foro: Permite a los participantes mantener discusiones asíncronas.  Glosario: Permite mantener un lista de definiciones, semejante a un diccionario.  Herramienta externa: Permite a los participantes interactuar con recursos y actividades de enseñanza compatibles con LTI en otros sitios web.  Lección: Proporciona contenido en forma flexible, no tan estructurado como un cuestionario.  Retroalimentación: Crear y conducir sondeos para colectar retroalimentación.  SCORM: Permite que se incluyan paquetes SCORM como contenido del curso.  Taller: Habilita la participación y evaluación por pares.  Tareas: Permite a los profesores asignar calificaciones y realizar comentarios sobre archivos subidos y tareas creadas en línea y fuera de línea.  Wiki: Colección de páginas donde todos pueden editar o añadir más páginas.

Recursos

Moodle permita agregar varios tipos de recursos adicionales, que sirven para complementar la enseñanza-aprendizaje. En el modo edición, un profesor puede añadir recursos a través de un menú desplegable. Los recursos aparecen como un simple enlace con un icono delante que representa el tipo de recurso (Moodle, 2014).

115

 Recurso archivo: Una imagen, un documento PDF, una hoja de cálculo, un archivo de sonido, un archivo de video.  Recurso carpeta: Las carpetas ayudan a organizar los ficheros. Las carpetas pueden contener otras carpetas.  Paquete de contenido IMS: Añade material estadístico desde otros recursos en el formato IMS estándar  Etiqueta: Que pueden ser unas pocas palabras o una imagen para separar recursos y actividades en un tema o una lección aunque también pueden ser descripciones largas o instrucciones para las actividades.  Página: El alumno ve una página navegable y simple que el profesor crea con un robusto editor de html.  Recurso URL: Puede enviar al alumno a cualquier lugar a través del navegador. Flickr, Youtube, Wikipedia o esta página de Moodle Docs son ejemplos perfectos.  Módulo libro: Recursos multi-página con aspecto similar a un libro.

Bloques

Los bloques son utilizados en Moodle para modificar el entorno que envuelve un curso, según las necesidades de los alumnos o profesores. Existen varios tipos de bloques con funciones específicas, tales como: informar, controlar, gestionar, etc. A continuación se enumeran los principales bloques que consta una instalación por defecto de Moodle (Moodle, 2014):

 Bloque de actividad reciente  Bloque de actividades  Bloque de actividades sociales  Bloque de administración (nuevo nombre del bloque de configuraciones)  Bloque de aprendices  Bloque de auto finalización  Bloque de buscador de comunidad  Bloque de búsqueda en foros  Bloque del calendario  Bloque de canales RSS remotos  Bloque de comentarios  Bloque de cursos

116

 Bloque de entrada aleatoria del glosario  Bloque de entradas de blog recientes  Bloque de enlaces de sección  Bloque de eventos próximos  Bloque de Flickr  Bloque de gente  Bloque HTML  Bloque de ingreso  Bloque de marcadores para Admin  Bloque del menú del blog  Bloque de marcas (tags) del blog  Bloque de menú principal  Bloque de mensajes  Bloque de mis últimas insignias (nuevo en 2.5)  Bloque de mis archivos privados  Bloque de navegación  Bloque de status de finalización del curso  Bloque de vista general del curso  Bloque de resumen del curso/sitio  Bloque de retroalimentación  Bloque de últimas noticias  Bloque de usuario ingresado  Bloque de servidores de red  Bloque de usuarios en línea  Bloque de resultados de examen  Bloque de marcas (tags)  Bloque de Youtube

117

ANEXO C: MOODLE DEVELOPERS

6.1.1. Roles y permisos

Los roles de usuario y el control de acceso son importantes términos para el desarrollo de plugins. Moodle es un sistema muy robusto y riguroso en el tema de seguridad con los usuarios y el acceso a los datos. Aunque es posible permitir el acceso al contenido de un curso a cualquier visitante sin necesidad de autenticarse, a estos usuarios no se les está permitido hacer mayores cosas en el sistema.

Para acceder a la plataforma, un usuario introduce su nombre de usuario y contraseña. Si son correctos se le permite el acceso. Moodle utiliza cookies en la sesión actual para ayudar a identificar al usuario durante toda su visita al sitio.

Un rol es una colección de permisos definida para todo el sistema, que puede ser asignado a usuarios específicos en contextos específicos. La combinación de roles y contexto definen la capacidad o habilidad de un usuario específico para hacer algo en alguna página del sitio.

Para gestionar los roles y sus capacidades, un administrador se debe dirigir a: Administración del Sitio > Usuarios > Permisos > Definir roles. Este es el lugar que sirve para añadir funciones personalizadas o modificar las funciones existentes.

Los roles estándar del sistema son:

 Administrador: Un administrador gestiona todo el sitio Moodle. El rol administrador ocupa el más alto nivel, en lo que a privilegios de usuario se refiere.  Manáger: Los usuarios identificados con este rol, pueden acceder a los cursos y modificarlos, al igual que realizar algunas tareas a nivel administrativo. Este rol ha sido introducido desde Moodle 2.0 que tiene muchas, pero no todas las capacidades del administrador.  Creador de cursos: Puede crear cursos en el sistema, además, los privilegios de Moodle le permiten asignar profesores y actuar como un profesor sin privilegios de edición.  Profesor: Un profesor tiene el privilegio de administrar un curso, puede desarrollar y actualizar su contenido, cambiar actividades y calificar a los estudiantes.  Profesor no editor: Puede ver y calificar las actividades de los estudiantes, pero no puede modificar o eliminar contenidos, actividades o recursos.

118

 Estudiante: Los usuarios identificados con este rol pueden participar en actividades y ver recursos del curso, y ver sus propias calificaciones.  Invitado: Las personas que visitan al sitio pueden acceder como invitados y entrar a cualquier curso que permita el acceso a los invitados. Este rol solamente podrá leer el contenido de un curso y no puede dejar ninguna publicación.  Usuario autenticado: Todo usuario que haya iniciado sesión en el sistema, automáticamente se le asigna este rol. Estos usuarios tienen permiso para editar su propio perfil, mandar mensajes, escribir en el blog. Según el contexto en que se encuentre se le asignarán roles adicionales, por ejemplo, estudiante en un curso.

6.1.2. Guía de estilo para desarrolladores

Esta sección describe guías de estilo para desarrolladores que trabajan con código de Moodle (Moodle, 2014).

6.1.2.1. Reglas generales.

Este apartado se basa en las „Reglas Generales‛ que propone Moodle para sus desarrolladores (Moodle, 2008).

 Todos los archivos de código deben utilizar la extensión .php.

 Todas las plantillas deben utilizar la extensión .html.

 Todos los archivos de texto deben utilizar el formato de texto Unix.

 Todas las etiquetas PHP deben ser 'completas', como , no 'reducidas', como .

 Todos los avisos de copyright deben ser mantenidos.

 Todos los archivos deben incluir el archivo principal config.php.

 Cualquier otro include/require debe utilizar una ruta absoluta que comience por $CFG->dirroot o $CFG->libdir, nunca relativos, ya que estos en algunas ocasiones funcionan de forma extraña en PHP.

 Cada archivo debe comprobar que el usuario está autenticado correctamente, utilizando las funciones require_login(), require_capability() y has_capability().

 Todos los accesos a la base de datos deben utilizar las funciones definidas en lib/datalib.php cuando sea posible, ya que esto permite la compatibilidad con un gran número de bases de datos y prácticamente todo es posible utilizando estas 119

funciones. La inclusión de código SQL queda restringida a funciones específicas de nuestro código (normalmente en el archivo lib.php. Además debemos comprobar que funciona en cualquier plataforma y debe estar claramente comentado.

 No se deben crear o utilizar variables globales distintas de las estándar $CFG, $SESSION, $THEME, $SITE, $COURSE y $USER.

 Todas las variables deben ser inicializadas o, al menos, comprobada su existencia utilizando isset() o empty() antes de ser utilizadas.

 Todas las cadenas deben ser traducibles.

 Todos los errores deben ser visualizados utilizando la función print_error() para maximizar la traducción y ayudar a los usuarios.

 La información que llega desde el navegador (enviada con los métodos GET o POST) automáticamente tiene las "magic_quotes" aplicadas (sin importar la configuración de PHP) por lo que podemos insertarla con total seguridad en la base de datos. El resto de la información (obtenida desde los archivos, o desde la base de datos) debe ser escapada con la función addslashes() antes de insertarla en la base de datos.

 Todos los textos dentro de Moodle, especialmente aquellos que han sido introducidos por los usuarios, deben ser mostrados utilizando la función format_text(). Esto asegura que el texto es filtrado y limpiado correctamente.

 Las acciones de los usuarios deben ser grabadas utilizando la función add_to_log(). Estos registros son utilizados para la generación de los "Informes de Actividad" y los registros.

 Al generar enlaces HTML, deben hacerse siempre relativos a la raíz del sitio Moodle, por ejemplo, enlace a $CFG->wwwroot/mod/blonk/view.php?id=99 en lugar de únicamente view.php?id=99. Gracias a esto el código funcionará aunque sea llamado por un script que se encuentre en otra carpeta diferente.

6.1.2.2. Estilos de código.

 Utilice un sangrado de texto de 4 espacios sin caracteres de tabulación.  Los nombres de las variables tienen que ser siempre fáciles de leer, procurando que sean palabras en minúsculas con significado en inglés. Si realmente necesita más de una palabra, póngalas juntas.  Se debe utilizar nombres en plural para las matrices de objetos.

120

BIEN: $quiz BIEN: $errorstring BIEN: $assignments (for an array of objects) BIEN: $i (but only in little loops)

MAL: $Quiz MAL: $aReallyLongVariableNameWithoutAGoodReason MAL: $error_string

Código 8. Ejemplo de nombres de variables correctos e incorrectos Fuente: (Moodle, 2008)

 No sangrar el nivel principal del script.

10 ) { call_some_error ( $a ) ; } else { do_something_with ( $a ) ; }

Código 9. Ejemplo de código correcto sin sangrado en el nivel principal Fuente: (Moodle, 2014)

10 ) { call_some_error ( $a ) ; } else { do_something_with ( $a ) ; }

Código 10. Ejemplo de código incorrecto con sangrado en el nivel principal Fuente: (Moodle, 2014)

 Las constantes tienen que definirse siempre en mayúsculas, y empezar siempre por el nombre del módulo al que pertenecen. Deberían tener las palabras separadas por guiones bajos.

define("FORUM_MODE_FLATOLDEST", 1);

Código 11. Ejemplo de definición de una constante Fuente: (Moodle, 2008)

121

 Los nombres de las funciones tienen que ser palabras sencillas en minúsculas y en inglés, y empezar con el nombre del plugin al que pertenecen para evitar conflictos entre plugins. Las palabras deberían separarse por guiones bajos. Los parámetros, si es posible, tendrán valores por defecto. Compruebe que no haya espacio entre el nombre de la función y los paréntesis.

function forum_set_display_mode($mode=0) { global $USER, $CFG;

if ($mode) { $USER->mode = $mode; } else if (empty($USER->mode)) { $USER->mode = $CFG->forum_displaymode; } }

Código 12. Ejemplo de función definida correctamente Fuente: (Moodle, 2008)

 Los bloques de código siempre deben estar encerrados por llaves (incluso si solo constan de una línea).

if ($quiz->attempts) { if ($numattempts > $quiz->attempts) { error($strtoomanyattempts, "view.php?id=$cm->id"); } }

Código 13. Ejemplo correcto de bloque de código Fuente: (Moodle, 2008)

 Las cadenas tienen que ser definidas utilizando comillas simples siempre que sea posible, para obtener un mejor rendimiento.

$var = 'some text without any variables'; $var = "with special characters like a new line \n"; $var = 'a very, very long string with a '.$single.' variable'; $var = "some $text with $many variables $within it";

Código 14. Ejemplo de definición de cadenas Fuente: (Moodle, 2008)

 Los comentarios deben ser añadidos de forma que resulten prácticos, para explicar el flujo del código y el propósito de las funciones y variables.  Cada función (y cada clase) debería utilizar el popular formato phpDoc.

122

 Los comentarios en línea deberían utilizar los caracteres //, alineados con cuidado por encima de las líneas de código que comenta.

/** * The description should be first, with asterisks laid out * exactly like this example. If you want to refer to a another * function, do it like this: {@link clean_param()}. Then, * add descriptions for each parameter as follows. * * @param int $postid The type is followed by the variable name * @param array $ratings * @return mixed */ function forum_get_ratings_mean($postid, $ratings=NULL) { if (!$ratings) { $ratings = array(); // Initialize the empty array if ($rates = get_records("forum_ratings")) { // Process each rating in turn foreach ($rates as $rate) { ....etc

Código 15. Ejemplo de comentarios de línea y de párrafo Fuente: (Moodle, 2008)

 El espacio en blanco se puede utilizar con bastante libertad - no se preocupe por separar las cosas un poco para ganar en claridad. Generalmente, debería haber un espacio entre llaves y líneas normales y ninguno entre llaves y variables o funciones:

foreach ($objects as $key => $thing) { process($thing); }

if ($x == $y) { $a = $b; } else if ($x == $z) { $a = $c; } else { $a = $d; }

Código 16. Ejemplo de uso de espacios Fuente: (Moodle, 2008)

 Cuando esté realizando una copia de un objeto, se utiliza siempre la función clone() originalmente sólo disponible en php5 (en caso contrario simplemente tendrá una referencia al primer objeto). Moodle garantiza que este método funcionará también 123

bajo php4. Si lo que se quiere copiar no es un objeto, pero puede contener objetos (p. ej. un array de objetos) utilizaremos la función fullclone() en su lugar

MAL: $b = $a; BIEN: $b = clone($a);

Código 17. Ejemplo de uso de clone() Fuente: (Moodle, 2008)

6.1.2.3. Estructuras de las base de datos.

 Cada tabla debe tener un campo autonumérico id (INT10) como clave primaria.  La tabla principal que contiene instancias de cada módulo debe tener el mismo nombre que el módulo y contener, por lo menos, los siguientes campos: o id: clave primaria. o course: identificador del curso al que pertenece. o name: nombre completo de la instancia.  El resto de las tablas asociadas con un plugin que contiene información sobre cualquier otra cosa (p. ej. ratings), deberían ser llamadas plugin_ratings.  Los nombres de las tablas y de los campos tienen que evitar el uso de palabras reservadas por las bases de datos.  Los nombres de los campos (columnas) deberían ser sencillos y cortos, siguiendo las mismas reglas que los nombres de las variables.  Cuando sea posible, las columnas que contengan una referencia al campo id de otra tabla (p. ej. modulo) debería ser llamado moduloid o algún otro nombre que mantenga la referencia entre el nombre de la tabla y el campo id.  Los campos booleanos serán implementados como enteros cortos (por ejemplo, INT4) con los valores 0 o 1, para permitir la futura expansión de los valores si fuera necesario.  La mayoría de las tablas tienen que tener un campo timemodified (INT10) que será actualizado con la fecha actual (timestamp de UNIX) obtenida con la función time() de PHP.  Se debe definir siempre un valor por defecto para cada campo  Cada tabla debe comenzar con el prefijo de la base de datos ($CFG->prefix). En muchos casos esto es gestionado automáticamente.  Para garantizar la compatibilidad entre bases de datos, se deben seguir las reglas siguientes sobre el uso del comando AS (solo si necesitamos alias en tablas/campos, por supuesto):

124

o No debemos utilizar el comando AS para alias de tablas. o Utilizaremos el comando AS para alias de campos (columnas).  Nunca cree UNIQUE KEYs (restricciones) para nada. En su lugar utilice UNIQUE INDEXes. En el futuro, si se decide añadir integridad referencial a Moodle y si se necesitan UNIQUE KEYs, serán utilizadas, pero no por ahora. Por favor, fíjese que el Editor XMLDB permite especificar tanto restricciones UNIQUE y FOREIGN (y eso es bueno, teniendo el XML bien definido), pero solo los índices subyacentes serán realmente generados en la DB.  El uso de UNIQUE KEYs creadas en el Editor XMLDB (punto anterior) solo debe ser definido si el campo/campos van a ser el objetivo para alguna FOREIGN KEY (a nivel de editor). En caso contrario, las crearemos como UNIQUE INDEXes.  Las tablas asociadas con un bloque deben seguir las siguientes convenciones en sus nombres: $CFG->prefix + block_ + nombre del bloque + añadidos. Por ejemplo, asumiendo que $CFG->prefix es 'mdl_', todas las tablas para el bloque "rss_client" deberán empezar por 'mdl_block_rss_client' (siendo posible añadir más palabras al final, p.ej. 'mdl_block_rss_client_anothertable').  Nunca realice cambios a la base de datos en ramas estables. Si hacemos eso, entonces los sitios actualizando de una versión estable a la siguiente pueden encontrarse con cambios por duplicado, lo cual puede producir errores serios.  Cuando haga referencia a una variable entera en consultas SQL, no entrecomille el valor; p. ej. get_records_select('question', "category=$catid") es correcto. get_records_select('question', "category='$catid'") es incorrecto. Ese uso oculta posibles errores cuando $catid está sin definir.

6.1.2.4. Normas de Seguridad.

Las siguientes reglas son normas de seguridad que se debe tomar en cuenta al momento de desarrollar algún plugin para Moodle, remarcando especialmente en mantener la seguridad de la información obtenida del usuario a través de formularios y parámetros en la URL, para poder mantener la integridad de los datos manejados por el plugin.

 No se base en register_globals. Cada variable debe ser correctamente inicializada en cada fichero de código. Debe ser obvia la procedencia de cada variable.  Debemos inicializar todos los arrays y objetos aunque estén vacíos. $a = array() o $obj = new stdClass().  No debemos utilizar la función optional_variable(). En su lugar, utilizaremos la función optional_param(). 125

 Seleccionaremos la opción PARAM_XXXX apropiada al tipo de parámetro que esperamos. Para comprobar y definir un valor opcional para una variable, utilizaremos la función set_default().  No utilizaremos la función require_variable(). En su lugar, utilizaremos la función required_param().  Seleccionaremos la opción PARAM_XXXX apropiada al tipo de parámetro que esperamos.  Utilizaremos data_submitted(), con cuidado. La información todavía debe ser limpiada antes de utilizarla.  No debemos utilizar $_GET, $_POST o $_REQUEST. En su lugar, utilizaremos las funciones required_param() u optional_param() apropiadas.  No debemos comprobar las acciones con código como: if (isset($_GET['algo'])). Utilizaremos, por ejemplo, $algo = optional_param( algo, -1, PARAM_INT ) y entonces compruebaremos que está dentro de los valores esperados, por ejemplo, if ($something>=0) {....  Cuando sea posible agruparemos todas las llamadas a required_param(), optional_param() y el resto de inicialización de variables en el principio de cada fichero (o función) para que sea fácilmente localizable.  Utilizaremos el mecanismo sesskey para proteger el envío de formularios de ataques. Un ejemplo de uso: cuando el formulario es generado, incluiremos . Cuando el formulario es procesado, comprobaremos if (!confirm_sesskey()) {error('Bad Session Key');}.  Todos los nombres de ficheros deben ser limpiados de caracteres extraños utilizando la función clean_filename(), si esto no ha sido realizado con el uso de las funciones required_param() y optional_param() con anterioridad.  Cualquier información leída desde la base de datos debe tener la función addslashes() aplicada antes de volver a enviar la información a la base de datos. Un objeto completo puede ser procesado con la función addslashes_object().  No debemos utilizar información obtenida de $_SERVER si podemos evitarlo. Presenta algunos problemas de portabilidad.  Si no ha sido realizado en ningún otro lugar, debemos asegurarnos de que la información enviada a la base de datos ha sido filtrada mediante la función clean_param() utilizando la opción PARAM_XXXX apropiada.

126

 Si escribimos código SQL, nos aseguraremos completamente de que es correcto. En particular, compruebaremos la falta de comillas en las variables utilizadas. Es un punto de entrada para ataques de tipo SQL injection.  Comprobaremos toda la información (especialmente la que es enviada a la base de datos) en cada archivo que es utilizada. Nunca debemos confiar en que otro código estará haciendo ese trabajo.  Los bloques de código que se incluyan deben presentar una estructura PHP correcta (por ejemplo, con una declaración de una clase, de funciones, etc.) Los bloques de código lineales suelen tender a utilizar variables sin inicializar (y son menos legibles).  Si necesitamos usar shell_exec() (o cualquier otra función que invoque un shell), nos aseguraremos de que se han limpiado los parámetros anteriormente con escapeshellcmd()/escapeshellarg() (de lo contrario abrimos la puerta a ataques de inyección de shell).

6.1.2.5. Estilos de la interfaz.

En esta sección se describen algunas directrices útiles al momento de desarrollar un nuevo plugin, para que sea totalmente compatible con el estilo global de Moodle (Moodle, 2009).

 Simplicidad: Se debe usar el mínimo de interfaz necesario para obtener un trabajo terminado.  Páginas estándar: Existen ficheros obligatorios que deben ser creados específicamente en el desarrollo de plugins de tipo actividad como de tipo bloques. Para los plugins de actividad, los ficheros se detallan en la sección Estructura de un plugin actividad.  Debe existir un script por función o página principal.  Plantilla de página: o Se debe imprimir las cabeceras con print_heading, usar los hooks CSS para IDs y Clases. o Se debe imprimir las cajas alrededor del texto usando print_simple_box, use los hooks CSS para IDs y Clases.  Plantilla de formulario: o Mostrar las opciones más importantes en la parte superior. o Cada entrada debe tener una etiqueta y, si es necesario, un archivo de ayuda. o Si hay más de 10 opciones, desglóselas en los parámetros necesarios y opcionales, extra o avanzados. 127

 Manejo de tablas: o Use la función print_table cuando sea posible.  Herramientas de navegación estándar: o Todas las páginas deberían llamar a print_header, y suministrar una ruta de navegación estándar que apareciera allí. Donde sea posible, debería verse como: COURSE >> INDEX >> INSTANCE >> SUBPAGES... o Las páginas incluidas en módulos de actividad deberían llamar a navmenu() para generar el menú de navegación apropiado.  Direcciones URL: o Las direcciones URL deben ser lo más cortas posible. o No usar subrayado en nombres de parámetros o nombres de archivos. o Nunca se debe usar dos palabras cuando una sea suficiente.  Botones o enlaces: El Web Accelerator de Google proporciona algunas sugerencias o Las acciones que puedan modificar el estado de Moodle (archivos de datos, base de datos, información de sesión) deben ser llevadas a cabo por medio de botones. o Como mínimo, tales acciones -que son implementadas como enlaces- deben remitir a una página de confirmación que sí utilice botones.  Denominación HTML y CSS: o Es importante que el plugin desarrollado produzca estrictamente código HTML5 bien formado (preferiblemente compatible con XHTML 1.1), que cumpla con todas las directrices de accesibilidad comunes (W3C WAG 2.0, ARIA). o CSS se debe utilizar solamente para el diseño.  Enlaces a archivos de ayuda: o Los botones de ayuda deben estar a la derecha del objeto (excepcionalmente pueden estar a la izquierda, si el objeto está alineado a la derecha).

6.1.3. Librerías (APIs) para el desarrollo de plugins.

La API de Moodle es un conjunto de funciones y procedimientos que facilitan la labor del desarrollador, haciendo uso de su funcionalidad, evitándose el trabajo de programar todo desde el principio.

La mayoría de las librerías se encuentran el directorio lib. La nomenclatura usual sigue la convención [función]lib.php, por ejemplo: accesslib.php, datalib.php.

128

En este apartado se enumerarán algunas de las librerías generales más utilizadas y las más básicas para el desarrollo de plugins de Moodle (Moodle, 2014). Cabe resaltar que se han implementado varios cambios en la funcionalidad de las librerías desde la versión 1.9 hacia la 2.0, por lo que las librerías que a continuación se describirán están desarrolladas en versiones de Moodle 2.0 y posteriores. Para la revisión de librerías para una versión de Moodle anterior a la 2.0 se deberá revisar el siguiente enlace: http://docs.moodle.org/dev/Deprecated_functions_in_2.0

6.1.3.1. Access API (access).

Esta librería describe las funciones para que el sistema de Moodle pueda determinar qué acciones se permiten que el usuario actual pueda realizar, ya que Moodle utiliza un modelo de control de acceso basado en roles.

Los nuevos parámetros y funcionalidades descritos a continuación, están desarrolladas y tienen soporte desde la versión Moodle 2.2

6.1.3.1.1. Definir capacidades de plugins

Las nuevas capacidades son definidas por el array $capabilities dentro del fichero db/access.php. El nombre de la capacidad o habilidad está determinado y consiste en "plugintype/pluginname:capabilityname".

$capabilities = array( 'mod/folder:managefiles' => array( 'riskbitmask' => RISK_SPAM, 'captype' => 'write', 'contextlevel' => CONTEXT_MODULE, 'archetypes' => array( 'editingteacher' => CAP_ALLOW ) ), );

Código 18. Ejemplo de definición de capacidades Fuente: (Moodle, 2014)

El significado de las claves del array, son las siguientes:

 riskbitmask: Riesgos asociados explicados en “Nuevo sistema de roles” (Moodle, 2011).

129

 captype: Tipo de capacidad de escritura o lectura. Por cuestiones de seguridad el sistema previene todas las capacidades de lectura para cuentas de invitado y usuarios que no han iniciado sesión.  contextlevel: Contexto del plugin  archetypes: Especifica los valores predeterminados para roles con arquetipos estándar, este se utiliza en las instalaciones, actualizaciones y al restablecer funciones.  clonepermissionsfrom: Al agregar una nueva capacidad, se puede permitir a Moodle copiar los permisos para cada rol de la configuración actual desde otra capacidad.

Los nombres de las capacidades se definen en los archivos de idioma del plugin, el nombre de la cadena consiste en "pluginname:capabilityname":

$string['folder:managefiles'] = 'Manage files in folder module';

Código 19. Nombre de capacidad en el archivo de idioma del plugin Fuente: (Moodle, 2014)

6.1.3.1.2. Obtener contexto

 Obtención mediante ID de objeto:

$systemcontext = context_system::instance(); $usercontext = context_user::instance($user->id); $categorycontext = context_coursecat::instance($category->id); $coursecontext = context_course::instance($course->id); $contextmodule = context_module::instance($cm->id);

Código 20. Obtención de instancia mediante ID de objeto Fuente: (Moodle, 2014)

 Obtención mediante ID de contexto:

$context = context::instance_by_id($contextid);

Código 21. Obtención de instancia mediante ID de contexto Fuente: (Moodle, 2014)

6.1.3.1.3. has_capability()

Esta función devolverá true si un usuario $userid, por defecto el usuario que esté accediendo al módulo, tiene la capacidad $capability en el contexto $context.

130

function has_capability($capability, context $context, $user = null, $doanything = true)

Código 22. Ejemplo función has_capability() Fuente: (Moodle, 2014)

6.1.3.1.4. require_capability()

Esta función comprueba que el usuario tiene cierta capacidad.

function require_capability($capability, $context = null, $userid = null, $doanything = true, $errormessage = 'nopermissions', $stringfile = '')

Código 23. Ejemplo función require_capability() Fuente: (Moodle, 2014)

6.1.3.1.5. require_login()

Cada script de un plugin debe incluir require_login() o require_course_login() después de configurar PAGE->url.

function require_login($courseorid = NULL, $autologinguest = true, $cm = NULL, $setwantsurltome = true, $preventredirect = false)

Código 24. Ejemplo función require_login () Fuente: (Moodle, 2014)

La función require_login() realiza las siguientes acciones:

 Verifica que el usuario se registra antes de acceder a cualquier curso o actividad.  Acceso a los registros de los cursos (logs)  Verificar que el usuario está matriculado o tiene capacidad "moodle/course:view 'o algún plugin de matrícula le da el acceso para invitado temporal.  Verificar el acceso a los cursos y actividades ocultas.

6.1.3.2. Data manipulation API (dml).

Este apartado describe las funciones disponibles para el acceso a la base de datos de Moodle. Se debe utilizar estas funciones exclusivamente con el fin de recuperar o modificar el contenido de la base de datos ya que estas funciones proporcionan un alto nivel de abstracción y garantizan que la manipulación de base de datos funcionará contra diferentes Sistemas de Gestión de Base de Datos Relacionales (SGBDR). 131

Estas funciones están disponibles desde la versión Moodle 2.0, para versiones anteriores de Moodle el siguiente enlace contiene información referente acerca de la librería: http://docs.moodle.org/dev/DB_layer_2.0_migration_docs

 En primer lugar se debe importar el objeto global $DB, ya que todas las llamadas a las funciones dentro de este apartado son métodos públicos del objeto:

global $DB;

Código 25. Importar objeto global $DB Fuente: (Moodle, 2014)

 El objeto global $DB es una instancia de la clase moodle_database, que se define en moodle_database.php  Todos los parámetros de la $tabla en las funciones están destinados a ser el nombre de la tabla y sin prefijos.

$user = $DB->get_record('user', array('id'=>'1'));

Código 26. Sentencia get_record() Fuente: (Moodle, 2014)

 Cuando se utiliza las funciones xxx_sql(), los nombres de la tabla deben estar encerrados entre llaves.

$user = $DB->get_record_sql('SELECT * FROM {user} WHERE id = ?', array(1));

Código 27. Sentencia get_record_sql() con el nombre de la tabla entre llaves Fuente: (Moodle, 2014)

 Todas los $parámetros en las funciones son elementos de matrices de tipo nombredecampo=>valordelcampo.

$user = $DB->get_record('user', array('firstname'=>'Martin', 'lastname'=>'Dougiamas'));

Código 28. Sentencia get_record() con parámetros en matrices Fuente: (Moodle, 2014)

132

 Todos los $params en las funciones son conjuntos de valores que se utilizan para rellenar los marcadores de posición de los comandos SQL. Tanto el signo de interrogación y espacios reservados con nombre pueden ser utilizados.

/// Marcadores de posición del signo de interrogación: $DB->get_record_sql('SELECT * FROM {user} WHERE firstname = ? AND lastname = ?', array('Martin', 'Dougiamas'));

/// Marcadores de posición con nombre: $DB->get_record_sql('SELECT * FROM {user} WHERE firstname = :firstname AND lastname = :lastname', array('firstname'=>'Martin', 'lastname'=>'Dougiamas'));

Código 29. Sentencia get_record_sql() con $params Fuente: (Moodle, 2014)

6.1.3.2.1. Obtener un solo registro

//Obtener un solo registro donde todas las condiciones dadas se encontraron: $DB->get_record($table, array $conditions, $fields='*');

//Obtener un solo registro que coincide con una cláusula WHERE particular: $DB->get_record_select($table, $select, array $params=null, $fields='*');

//Obtener un solo registro utilizando una sentencia SQL: $DB->get_record_sql($sql, array $params=null);

Código 30. Sentencias para obtener un solo registro Fuente: (Moodle, 2014)

6.1.3.2.2. Obtener varios registros

Cada uno de los métodos siguientes devuelve una matriz de objetos. La matriz devuelta siempre se indexa por la primera columna de los campos devueltos, por tal motivo, se debe asegurar que la consulta incluya una columna id como el primer campo.

133

//Obtener un array de registros donde todas las condiciones dadas se cumplen: $DB->get_records($table, array $conditions=null, $sort='', $fields='*', $limitfrom=0, $limitnum=0);

//Obtener un array de registros que coinciden con una cláusula WHERE particular: $DB->get_records_select($table, $select, array $params=null, $sort='', $fields='*', $limitfrom=0, $limitnum=0);

//Obtner un array de registros utilizando una sentencia SQL: $DB->get_records_sql($sql, array $params=null, $limitfrom=0, $limitnum=0);

//Obtener un array de registros donde un campo coincide con una lista de valores: $DB->get_records_list($table, $field, array $values, $sort='', $fields='*', $limitfrom='', $limitnum='');

Código 31. Sentencias para obtener varios registros Fuente: (Moodle, 2014)

6.1.3.2.3. Obtener datos llave/valor en un array asociativo

//Obtener las dos primeras columnas como un array asociativo donde todas las condiciones dadas se encontraron: $DB->get_records_menu($table, array $conditions=null, $sort='', $fields='*', $limitfrom=0, $limitnum=0);

//Obtener las dos primeras columnas como un array asociativo que coinciden con una cláusula WHERE particular: $DB->get_records_select_menu($table, $select, array $params=null, $sort='', $fields='*', $limitfrom=0, $limitnum=0);

//Obtener las dos primeras columnas como un array asociativo utilizando una sentencia SQL: $DB->get_records_sql_menu($sql, array $params=null, $limitfrom=0, $limitnum=0);

Código 32. Sentencias para obtener datos llave/valor en un array asociativo Fuente: (Moodle, 2014)

134

6.1.3.2.4. Comprobar si existe un registro

//Verificar si existe un registro en una tabla en la que todas las condiciones dadas se encontraron: $DB->record_exists($table, array $conditions=null);

//Verificar si existe un registro en una tabla que coincide con una cláusula WHERE particular: $DB->record_exists_select($table, $select, array $params=null);

//Verificar si existe un registro en una tabla utilizando una sentencia SQL: $DB->record_exists_sql($sql, array $params=null);

Código 33. Sentencias para comprobar si existe un registro Fuente: (Moodle, 2014)

6.1.3.2.5. Eliminar registros

//Eliminar los registros de una tabla en la que todas las condiciones dadas se encontraron: $DB->delete_records($table, array $conditions=null);

// Eliminar los registros de una tabla que coincide con una cláusula WHERE particular: $DB->delete_records_select($table, $select, array $params=null);

Código 34. Sentencias para eliminar registros Fuente: (Moodle, 2014)

6.1.3.2.6. Insertar registros

//Insertar un registro en una tabla y volver al campo "id" si es necesario: $DB->insert_record($table, $dataobject, $returnid=true, $bulk=false);

Código 35. Sentencias para ingresar registros Fuente: (Moodle, 2014)

135

6.1.3.2.7. Actualizar registros

//Actualizar un registro en una tabla: $DB->update_record($table, $dataobject, $bulk=false); //@param $table La table que se va a actualizar. //@param $dataobject Objeto que contiene nombrecampo=>valorcampo. // Debe tener una entrada “id”. // @param $bulk true significa actualizaciones repetidas esperadas // @return bool true // @throws dml_exception si se produce un error

//Actualizar un registro en una tabla con una sentencia SQL: $DB->execute($sql, array $parms=null); //Debe ser utilizado sólo cuando no existe ningún otro método adecuado.

Código 36. Sentencias para actualizar registros Fuente: (Moodle, 2014)

6.1.3.3. Form API (form).

La API Form está diseñada para crear formularios web en Moodle, admite todos los elementos HTML.

Para crear un formulario en Moodle, se debe crear una clase que es extensión de la clase moodleform e invalidar la definición para incluir elementos de formulario.

136

//moodleform está definida en formslib.php require_once("$CFG->libdir/formslib.php");

class simplehtml_form extends moodleform { public function definition() { global $CFG;

$mform = $this->_form; // No olvidar el guíon bajo

//Agregar elementos al formulario $mform->addElement('text', 'email', get_string('email')); //Establecer tipo de elemento $mform->setType('email', PARAM_NOTAGS); //Valor por defecto $mform->setDefault('email', 'Please enter email'); }

//Validaciones personalizadas deben agregarse aquí function validation($data, $files) { return array(); } }

Código 37. Crear clase para un formulario Fuente: (Moodle, 2014)

137

Luego se debe crear una instancia del formulario.

//incluir simplehtml_form.php require_once('PATH_TO/simplehtml_form.php');

//Instanciar simplehtml_form $mform = new simplehtml_form();

// Procesamiento y visualización del formulario if ($mform->is_cancelled()) { //Operaciones para manejar la cancelación del formulario } else if ($fromform = $mform->get_data()) { //Se procesa datos válidos. //$mform->get_data() ratorna datos ingresados en el form. } else { //El formulario ha sido enviado pero los datos no han sido //validados, el formulario volverá a visualizarse

//Establecer valor por defecto $mform->set_data($toform); //Visualizar el formulario $mform->display(); }

Código 38. Crear instancia de formulario Fuente: (Moodle, 2014)

Los elementos básicos utilizados en la creación de formularios, son los que se aprecian a continuación (Moodle, 2014):

 button  checkbox  radio  select  multi-select  password  hidden  html  static.  text  textarea

138

6.1.3.4. Page API (page).

La Page API es considerada como una parte integral de cualquier página de Moodle. Permite al desarrollador establecer las cosas de la manera que la considere. A través de la API se puede configurar cosas las cabeceras de la página, el título, archivos requeridos CSS o JavaScript, etc.

El siguiente ejemplo se puede apreciar cómo se configura una página básica para su uso dentro de un plugin de actividad.

//Archivo: /mod/mymodulename/view.php require_once('../../config.php'); $cmid = required_param('id', PARAM_INT); $cm = get_coursemodule_from_id('mymodulename', $cmid, 0, false, MUST_EXIST); $course = $DB->get_record('course', array('id' => $cm->course), '*', MUST_EXIST);

require_login($course, true, $cm); $PAGE->set_url('/mod/mymodulename/view.php', array('id' => $cm- >id)); $PAGE->set_title('My modules page title'); $PAGE->set_heading('My modules page heading');

//El resto de código seguiría aquí.

Código 39. Configuración de página mediante Page API Fuente: (Moodle, 2014)

La Page API está estrechamente relacionada con algunas otras API‟s, las cuáles se debe tomar también en consideración

6.1.3.4.1. Output API

La Output API permite la visualización de las cosas u objetos que la Page API configura. Es a través de la Output API que el contenido es producido, y gran parte de la información que se configura a través de la página se utiliza para personalizar lo que se produce

139

6.1.3.4.2. Page requirements API

Es parte esencial de Page API, aunque se la menciona en diferente parte por la importancia que posee, ya que permite al desarrollador incluir CSS adicional y recursos JavaScript dentro de la página.

6.1.3.4.3. Navigation API

La API de navegación es parte integral de la Page API y de la Output API y se utiliza para reconocer el contexto del contenido que se muestra y asegurar que los bloques y la estructura de navegación sean los correctos para el contexto en particular.

 $PAGE->context describe inmediatamente a la naturaleza de la página que el usuario está viendo.  $PAGE->course es el curso que el usuario está viendo.  $PAGE->cm es la instancia de módulo del curso.  $PAGE->url es usado para que coincida con el elemento de navegación activa.

6.1.3.5. String API (string).

La String API determina la manera de obtener las cadenas de texto de lenguaje que se utilizan en la interfaz de usuario. Administra temas de internacionalización y utiliza una serie de ajustes y variables de entorno para presentar el mejor texto para cada usuario.

Cuando sea necesario para buscar una cadena o punto de un archivo de ayuda, se requieren dos elementos básicos de la información.

 Nombre del archivo de idioma del plugin en el que se puede encontrar.  Nombre de la cadena (o la ayuda en nombre de archivo). Por ejemplo, get_string('editingquiz', 'quiz') devuelve "Editando “quiz” en el idioma actual.

La función más utilizada de esta API es: get_string(), que devuelve una cadena localizada para el usuario actual.

Primeramente la cadena deberá estar definida en el archivo correspondiente del plugin:

$string['plugintitle'] = 'Título del plugin';

Código 40. Cadena de texto Fuente: (Moodle, 2014)

140

Si se desea mostrar esta cadena en el lenguaje del contexto del usuario actual, se utiliza esta función:

echo get_string('module_pluginlangfilename', 'plugintitle'); //Se visualizará como salida la cadena “Título del plugin”

Código 41. Función get_string() Fuente: (Moodle, 2014)

6.1.3.6. Rating API (rating)

La API de calificaciones proporciona la capacidad de agregar, actualizar y eliminar calificaciones, así como de acceso a la recopilación de las mismas, consideradas para el cálculo final de la nota.

Está librería está implementada desde la versión 2.3 de Moodle.

La clase rating_manager, especificada en rating/lib.php, es el principal acceso a las funciones de la Rating API. Estas son algunas de ellas:

 get_ratings(): Agregar calificaciones a un array de items.  get_user_grades(): Devuelve una matriz de calificaciones, calculadas por el tipo de agregación configurada para los ítems.  delete_ratings(): Función usada para borrar calificaciones.

El código siguiente es un ejemplo de cómo utilizar la clase rating_manager (versión modificada tomada desde el plugin foro)

141

require_once($CFG->dirroot.'/rating/lib.php'); //incluir librería if ($forum->assessed != RATING_AGGREGATE_NONE) { //get_ratings() $ratingoptions = new stdClass; $ratingoptions->context = $modcontext; $ratingoptions->component = 'mod_forum'; $ratingoptions->ratingarea = 'post'; $ratingoptions->items = $posts; //el array de items $ratingoptions->aggregate = $forum->assessed; $ratingoptions->scaleid = $forum->scale; $ratingoptions->userid = $USER->id; if ($forum->type == 'single' or !$discussion->id) { $ratingoptions->returnurl = "$CFG- >wwwroot/mod/forum/view.php?id=$cm->id"; } else { $ratingoptions->returnurl = "$CFG- >wwwroot/mod/forum/discuss.php?d=$discussion->id"; } $ratingoptions->assesstimestart = $forum->assesstimestart; $ratingoptions->assesstimefinish = $forum->assesstimefinish; $rm = new rating_manager(); $posts = $rm->get_ratings($ratingoptions); } //get_user_grades() $ratingoptions = new stdClass; $ratingoptions->component = 'mod_forum'; $ratingoptions->ratingarea = 'post'; $ratingoptions->modulename = 'forum'; $ratingoptions->moduleid = $forum->id; $ratingoptions->userid = $userid; $ratingoptions->aggregationmethod = $forum->assessed; $ratingoptions->scaleid = $forum->scale; $ratingoptions->itemtable = 'forum_posts'; $ratingoptions->itemtableusercolumn = 'userid'; $rm = new rating_manager(); return $rm->get_user_grades($ratingoptions); //delete_ratings() $delopt = new stdClass; $delopt->contextid = $context->id; $delopt->component = 'mod_forum'; $delopt->ratingarea = 'post'; $delopt->itemid = $post->id; $rm = new rating_manager(); $rm->delete_ratings($delopt);

Código 42. Funciones de rating_manager Fuente: (Moodle, 2014) 142

6.1.3.7. Moodlelib API (core).

La API Moodlelib es un repositorio central de diversas funciones de Moodle para fines generales. Funciones que tienen la capacidad de manejar peticiones de parámetros, configuraciones, preferencias de usuario, inicios de sesión, plugins, etc.

6.1.4. Estructura de un plugin actividad.

Cada plugin está en un subdirectorio o carpeta separada, identificada con el nombre del plugin, que a su vez se incluye dentro de la carpeta /mod; y consiste en una serie de "archivos obligatorios” y cualquier otro archivo que el desarrollador va a utilizar. En la siguiente imagen se aprecia un ejemplo de la estructura de archivos del plugin certificate de Moodle.

Figura 27. Estructura de archivos plugin certificate Fuente: (Moodle, 2014)

143

Este ejemplo está desarrollado para Moodle versión 2.0 en adelante, para versiones posteriores se puede apreciar una completa documentación en el siguiente enlace: http://docs.moodle.org/dev/NEWMODULE_Documentation

A continuación vamos a revisar los principales y cruciales archivos que son más utilizados e importantes, los cuales se utilizan para instalar el plugin y luego integrarlo con la plataforma Moodle. Cada archivo tiene una funcionalidad particular.

6.1.4.1. Directorio Backup

En este directorio se encuentran los archivos que definen cómo el plugin se va a comportar cuando se realiza una copia de seguridad del curso o restauración. Se determinan los datos que se requieren ser guardados en una copia de seguridad y cómo luego restaurar esta información desde el backup de Moodle

6.1.4.2. Directorio DB

6.1.4.2.1. access.php

El fichero access.php define las capacidades que el plugin creará a usuarios específicos en función a los roles. Si se agregan nuevas capacidades a este fichero después que el plugin ha sido instalado, se debe aumentar el número de versión del plugin a través del fichero versión.php para que las nuevas capacidades sean instaladas.

El siguiente código es un ejemplo de cómo definir una capacidad para el plugin certificate en el fichero access.php

144

$capabilities = array(

'mod/certificate:addinstance' => array( 'riskbitmask' => RISK_XSS, 'captype' => 'write', 'contextlevel' => CONTEXT_COURSE, 'archetypes' => array( 'editingteacher' => CAP_ALLOW, 'manager' => CAP_ALLOW ), 'clonepermissionsfrom' => 'moodle/course:manageactivities' ), );

Código 43. Ejemplo de fichero access.php Fuente: (Moodle, 2014)

6.1.4.2.2. install.xml

Este fichero es utilizado en la instalación del plugin. Define las tablas de las bases de datos con sus respectivos campos que el nuevo plugin va a crear.

En Moodle existe el XMLDB_editor, donde se puede crear el archivo XML de una forma más sencilla

145

Código 44. Ejemplo de fichero install.xml Fuente: (Moodle, 2014) 147

En el ejemplo anterior se pueda apreciar la estructura de las tablas certificate y certificate_issues. Cada tabla, campo y llave están formando listas doblemente enlazadas mediante los campos NEXT y PREVIOUS, esto es creado automáticamente por el XMLDB_editor.

La primera tabla obligatoriamente debe llevar el mismo nombre del plugin, así como los campos id, course y name

6.1.4.2.3. upgrade.php

Este fichero mantiene un registro de los cambios que es necesario realizar entre distintas versiones del plugin. Después de crear un plugin y utilizarlo de forma intensiva es posible que se requieran de nuevas funcionalidades.

Por ejemplo, se plantea incrementar las funciones del plugin certificate, por lo que se requiere de dos nuevos campos: showcode y code, que se agregaran en las tablas certificate y certificate_issues respectivamente. Para realizar esta actualización se necesita realizar tres cosas:

 Añadir las nuevas columnas en el archivo install.xml, para que los nuevos usuarios que instalen el plugin después de este punto se les cree la nueva estructura de las tablas. Se lo puede realizar a través del editor XMLDB  Añadir las instrucciones necesarias en el fichero upgrade.php.  Actualizar el número de versión en el fichero version.php.

148

function xmldb_certificate_upgrade($oldversion=0) { if ($oldversion < 2012091800) { // Añadir nuevos campos a certificate. $table = new xmldb_table('certificate'); $field = new xmldb_field('showcode'); $field->set_attributes(XMLDB_TYPE_INTEGER, '1', XMLDB_UNSIGNED, XMLDB_NOTNULL, null, '0', 'savecert'); if (!$dbman->field_exists($table, $field)) { $dbman->add_field($table, $field); } // Añadir nuevos camps a certificate_issues. $table = new xmldb_table('certificate_issues'); $field = new xmldb_field('code'); $field->set_attributes(XMLDB_TYPE_CHAR, '50', null, null, null, null, 'certificateid'); if (!$dbman->field_exists($table, $field)) { $dbman->add_field($table, $field); }

// Punto de restauración. upgrade_mod_savepoint(true, 2012091800, 'certificate'); } }

Código 45. Ejemplo de fichero upgrade.php Fuente: (Moodle, 2014)

6.1.4.3. Directorio Lang

En este directorio se almacenan todas la cadenas de texto que se van a utilizar en el plugin. Cada idioma que soporte el plugin tiene una carpeta específica.

Si se desea dar soporte en idioma inglés del plugin se debe crear una carpeta denomina en, que contiene un fichero con el nombre del plugin .php que contendrá todas las cadenas de texto del plugin. Por ejemplo el plugin certificate tiene un ajuste llamado “User preferences”, para usar el marcador de posición, la cadena de texto deberá estar definida en el fichero certificate.php dentro de la carpeta es. El formato es el siguiente:

$string['pluginname'] = Certificate; $string['userpreferences'] = 'User preferences';

Código 46. Fichero que contiene cadenas de texto del plugin Fuente: (Moodle, 2014)

149

Si se planea dar soporte en idioma español, entonces se deberá crear un directorio es, con el fichero certificate.php que contendrá las definiciones de las cadenas de texto en idioma español

$string['pluginname'] = Certificado; $string['userpreferences'] = 'Preferencias de usuario';

Código 47. Fichero que contiene cadenas de texto del plugin Fuente: (Moodle, 2014)

Para utilizar la cadena "User preferences" se utiliza la función get_string de Moodle, que obtendrá la cadena apropiada dependiendo del lenguaje en el que sea utilizado.

get_string('userpreferences', 'certificate'); // Dependiendo del lenguaje presentará en pantalla: // es: Preferencias de usuario // en: User preferences

Código 48. Función get_string() Fuente: (Moodle, 2014)

6.1.4.4. Directorio Pix

En esta carpeta se almacena el ícono que identifique al plugin, el nombre del archivo debe ser icon.gif y con una resolución de 16*16 px. En esta carpeta se pueden almacenar también cualquier otra imagen que se pretenda utilizar.

6.1.4.5. lib.php lib.php es el fichero en donde se desarrollan todas las funciones del plugin que se va a desarrollar, en este fichero se implementa toda la funcionalidad del plugin.

 Las funciones deben nombrarse de la siguiente manera: nombremodulo_nombrefuncion().  Las variables globales deberán nombrarse de la siguiente manera: $NOMBREMODULO_NOMBREVARIABLE.

Las funciones básicas que se deben implementar en este fichero son los siguientes (la lista completa de funciones se encuentra en: http://docs.moodle.org/dev/NEWMODULE_Documentation#lib.php):

150

function certificate_add_instance($certificate); function certificate_update_instance($certificate); function certificate_delete_instance($id);

Código 49. Funciones básicas de lip.php Fuente: (Moodle, 2014)

6.1.4.5.1. _add_instance($nombreplugin)

Esta función recibe como parámetro un objeto que es enviado al momento de crear una nueva instancia del plugin, a través del mod_form.php. En esta función se puede tomar los datos y administrarlos, para luego insertarlos en la base de datos si se lo desea.

6.1.4.5.2. _update_instance($nombreplugin)

Cada vez que se actualiza una instancia, se envía un objeto con variables desde el archivo mod_form.php. El id de la instancia que se desea editar se envía como un atributo de la instancia y se puede usar para editar los valores y volverlos a insertar en la base de datos.

6.1.4.5.3. _delete_instance($id)

Esta función recibe como parámetro el id de la instancia que se desea eliminar, para poder borrar todos los registros de las tablas de la base de datos asociados con ese id

6.1.4.6. mod_form.php

Este fichero es utilizado para crear/editar una instancia del plugin. Contiene los elementos que se mostrarán en el formulario. La clase dentro del archivo debe ser llamada mod_ _mod_form.

151

if (!defined('MOODLE_INTERNAL')) { die('Direct access to this script is forbidden.'); /// Esto debe ser incluído desde una página Moodle }

require_once($CFG->dirroot.'/course/moodleform_mod.php'); require_once($CFG->dirroot.'/mod/certificate/lib.php');

class mod_certificate_mod_form extends moodleform_mod {

function definition() { global $CFG, $DB, $OUTPUT;

$mform =& $this->_form;

$mform->addElement('text', 'name', get_string('certificatename', 'certificate'), array('size'=>'64')); $mform->setType('name', PARAM_TEXT); $mform->addRule('name', null, 'required', null, 'client');

$ynoptions = array(0 => get_string('no'), 1 => get_string('yes')); $mform->addElement('select', 'usecode', get_string('usecode', 'certificate'), $ynoptions); $mform->setDefault('usecode', 0); $mform->addHelpButton('usecode', 'usecode', 'certificate');

$this->standard_coursemodule_elements();

$this->add_action_buttons(); } }

Código 50. Fichero mod_form.php del plugin certificate Fuente: (Moodle, 2014)

6.1.4.7. index.php

Esta página es usada por Moodle para listar todas las instancias del plugin que corresponden a determinado curso.

152

Normalmente se muestran en formato tabular con una fila por cada instancia de la actividad y con una columna para el campo name

6.1.4.8. view.php

El fichero view.php es en donde se define el contenido que se mostrará de la instancia a cada usuario.

A continuación se presenta un ejemplo con el código mínimo que debería tener este fichero.

$id = optional_param('id', 0, PARAM_INT); $a = optional_param('a', 0, PARAM_INT); if ($id) { if (! $cm = get_record("course_modules", "id", $id)) { error("Course Module ID was incorrect"); } if (! $course = get_record("course", "id", $cm->course)) { error("Course is misconfigured"); } if (! $nombreplugin = get_record("nombreplugin", "id", $cm- >instance)) { error("Course module is incorrect"); } } else { if (! $nombreplugin = get_record("nombreplugin", "id", $a)) { error("Course module is incorrect"); } if (! $course = get_record("course", "id", $nombreplugin - >course)) { error("Course is misconfigured"); } if (! $cm = get_coursemodule_from_instance("nombreplugin ", $nombreplugin ->id, $course->id)) { error("Course Module ID was incorrect"); } } require_login($course->id); add_to_log($course->id, " nombreplugin ", "view", "view.php?id=$cm- >id", "$nombreplugin ->id");

153

if ($course->category) { $navigation = "id\">$course->shortname ->"; } else { $navigation = ''; }

$strnombreplugins = get_string("modulenameplural", " nombreplugin "); $strnombreplugin = get_string("modulename", " nombreplugin ");

/// Imprime la cabecera de la página print_header("$course->shortname: $ nombreplugin ->name", "$course- >fullname", "$navigation id>$strnombreplugins ->$ nombreplugin ->name","", "", true, update_module_button($cm->id, $course->id,$strnombreplugin), navmenu($course, $cm));

/// Parte principal de la página /// Aquí debe ir el código del desarrollador

/// Imprime el pie de página print_footer($course); ?>

Código 51. Fichero view.php Fuente: (Moodle, 2014)

6.1.4.9. version.php

El archivo version.php mantiene un registro de la versión del plugin, además de otros atributos, como la versión de Moodle que requiere para su correcto funcionamiento.

Al momento de modificar las tablas de la base de datos, a través de db/upgrade.php, Moodle compara la versión actual con la versión anterior. Si la versión actual es posterior a la previa, Moodle realiza los cambios necesarios y actualiza a la nueva versión.

154

ANEXO D: MANUAL DE INSTALACIÓN En este apartado se presenta un Manual de Instalación y configuración para cada uno de los plugins desarrollados, la versión escogida de la plataforma Moodle para la instalación es la número 2.6.4.

7.1.1. Plugin de actividad Twitter Integration

7.1.1.1. Registro de aplicación en Twitter Developers

Para poder utilizar la API de Twitter y crear una aplicación, se requiere registrar una cuenta de desarrollador en el sitio Twitter Developers. Para ello se debe dirigir a la dirección: https://dev.twitter.com/ e iniciar sesión con el usuario y contraseña de una cuenta de Twitter (sino la posee, se deberá registrar una nueva cuenta en la dirección: https://twitter.com/signup).

Una vez iniciado sesión en Twitter Developers, dirigirse a la dirección: https://apps.twitter.com/ y hacer clic en el botón “Create New App”. Completamos el formulario con los datos de la aplicación (Callback URL lo dejamos en blanco) y aceptar las “Reglas del Desarrollador”.

Figura 28. Crear nueva aplicación en Twitter Fuente: Twitter Developers - https://apps.twitter.com/app/new 155

Para la correcta integración del plugin con la API de Twitter, se requiere cambiar el nivel de acceso de la aplicación cambiando los permisos, para ello dirigirse a la pestaña “Permissions”, y seleccionar el acceso “Read and Write”:

Figura 29. Cambiar permisos de la aplicación Fuente: Twitter Developers

Actualizados los permisos, dirigirse a la pestaña “API Keys” para obtener las claves o tokens necesarios para la comunicación con la aplicación. En primer lugar guardar la API key y la API secret:

Figura 30. API key y API secret de aplicación Fuente: Twitter Developers

156

Seguidamente hacer clic sobre el botón “Create my access token”, y se generarán los tokens necesarios. Al igual que las API keys, es recomendable guardar estos access tokens.

Figura 31. Access tokens de la aplicación Fuente: Twitter Developers

7.1.1.2. Instalación y configuración de plugin Twitter Integration

Para instalar el plugin Twitter Integration, se debe descomprimir el archivo twitterintegration.zip y colocar la carpeta que contiene en el directorio donde se encuentran los plugins de Moodle, es decir dentro de la carpeta “mod”. Una vez colocada la carpeta en el directorio correspondiente, ingresar a la página de Moodle como administrador, y agregar en la barra de direcciones la palabra “admin”, y Moodle reconocerá el nuevo plugin que está listo para instalarse (Figura 32).

157

Figura 32. Comprobación de „plugins‟ Fuente: Autor

Hacer clic en “Actualizar base de datos Moodle ahora” para proceder a realizar la instalación del plugin, creándose las tablas necesarias en la base de datos.

Figura 33. Instalación de plugin Twitter Integration Fuente: Autor

158

7.1.1.2.1. Configuración de Moodle.

Con la finalidad de que el plugin realice una búsqueda de los tweets enviados por los estudiantes desde fuera de Moodle usando un hashtag específico y determinado en la actividad, la plataforma deberá ser configurada para agregar un nuevo campo en los perfiles de usuario de los estudiantes. Para ello se debe dirigir a: Administración del sitio > Usuario > Cuentas > Campos de perfil de usuario y seleccionar de la lista disponible: “Entrada de texto”

Figura 34. Campos de perfil de usuario - Moodle Fuente: Autor

Proceder a completar el formulario, con los datos mostrados a continuación:

 Nombre corto: twitterusername  Nombre: Twitter Username  Descripción del campo: Opcional  ¿Es este campo necesario?: Opcional  ¿Está este campo bloqueado?: No  ¿Deberían ser únicos los datos?: Sí  ¿Mostrar página al inscribirse?: Opcional  ¿Quién puede ver este campo?: Opcional  Categoría: Seleccionar alguna si es que se tiene configurada esta sección

159

 Valor por defecto: Vacío  Mostrar tamaño: 30  Longitud máxima: 15 (longitud de un nombre de usuario de Twitter)  ¿Es éste un campo de contraseña?: No  Enlace: http://twitter.com/$$ (no disponible en versiones inferiores a 2.0)

Figura 35. Creando un nuevo campo de perfil “Entrada de texto” Fuente: Autor

De esta manera, el perfil de usuario de los participantes que se encuentren inscritos contará con un nuevo campo de usuario, llamado Twitter Username. Una vez actualizada la información del participante, incluyendo su nombre de usuario de Twitter, estará posibilitado para enviar tweets desde cualquier plataforma externa a Moodle.

160

7.1.1.2.2. Configuración de plugin Twitter Integration

Para que el plugin Twitter Integration funcione correctamente y realice la comunicación con la REST API de Twitter, requiere las API keys y los access tokens de la aplicación obtenidos en la sección 7.1.1.1 (Registro de aplicación en Twitter Developers).

Para ello se debe dirigir a la carpeta del plugin Twitter Integration, ubicada dentro del directorio mod; seleccionar y abrir la carpeta twitter, y con cualquier editor que permita modificar el contenido de un archivo PHP, abrir el fichero config.php; este fichero contiene la definición de contantes utilizadas para la correcta comunicación con la aplicación registrada en Twitter y a su vez con la REST API. Se debe completar la información con las API keys y los access tokens:

Figura 36. Fichero config.php Twiter Integration Fuente: Autor

7.1.2. Plugin de actividad Facebook Integration

7.1.2.1. Registro de aplicación en Facebook Developers

Para poder utilizar la API de Facebook se debe crear una aplicación en el sitio de Facebook Developers. Para ello se debe dirigir a la dirección: https://developers.facebook.com/ e iniciar sesión con la cuenta de usuario de Facebook.

Una vez iniciado sesión en Facebook Developers, dirigirse a la pestaña “Apps” y hacer clic en el enlace “Create a New App”. Completamos el formulario con los datos de la aplicación y clic en “Create App”.

161

Figura 37. Crear nueva aplicación en Facebook Fuente: Facebook Developers

Se tendrá que resolver un captcha que Facebook implementa como un chequeo de seguridad y la aplicación estará creada. Para el correcto funcionamiento del plugin Facebook Integration, se debe agregar una plataforma sobre la cual va a trabajar nuestra aplicación, para ello se debe dirigir a Settings > Add Platform > seleccionar Website y llenar el cuadro de texto donde se indique la URL del sitio Moodle en donde está instalado el plugin Facebook Integration.

162

Figura 38. Agregar una plataforma Website Fuente: Facebook Developers

7.1.2.2. Instalación y configuración de plugin Facebook Integration

Para instalar el plugin Facebook Integration, se debe descomprimir el archivo facebookintegration.zip y colocar la carpeta que contiene en el directorio donde se encuentran los plugins de Moodle (directorio “mod”). Una vez colocada la carpeta en el directorio correspondiente, ingresar a la página de Moodle como administrador, y agregar en la barra de direcciones la palabra “admin”, y Moodle reconocerá el nuevo plugin que está listo para instalarse.

163

Figura 39. Comprobación de „plugins‟ Fuente: Autor

Hacer clic en “Actualizar base de datos Moodle ahora” para proceder a realizar la instalación del plugin, creándose las tablas necesarias en la base de datos.

7.1.2.2.1. Configuración de plugin Facebook Integration

Para que el plugin Facebook Integration funcione correctamente y realice la comunicación con la Graph API de Facebook, requiere la APP ID y la APP Secret de la aplicación obtenida en la sección 7.1.2.1 (Registro de aplicación en Facebook Developers). 164

Para ello se debe dirigir a la carpeta del plugin Facebook Integration, ubicada dentro del directorio mod; seleccionar y abrir la carpeta facebook, y con cualquier editor que permita modificar el contenido de un archivo PHP, abrir el fichero config.php; este fichero contiene la definición de contantes utilizadas para la correcta comunicación con la aplicación registrada en Facebook y a su vez con la Graph API. Se debe completar la información con la APP ID y la APP Secret

Figura 40. Fichero config.php Facebook Integration Fuente: Autor

165

ANEXO E: PRUEBAS

8.1.1. Introducción

En este apartado se describe el desarrollo de las pruebas de Integridad de datos, y funcionamiento de los componentes. La ejecución de estas pruebas permitió verificar que cada componente funcione correctamente y cumpla con los requisitos planteados.

A continuación se detallan los resultados obtenidos de las pruebas realizadas.

8.1.2. Pruebas de integridad de datos

Las pruebas de integridad de datos buscan como objetivo comprobar que el acceso manipulación y control de los datos generados son correctos y sus resultados están de acuerdo a los datos de prueba utilizados

Para el desarrollo de esta prueba se utilizó funciones de MySQL para la recuperación, manipulación y almacenamiento de los datos. Luego las tablas involucradas fueron inspeccionadas para verificar que los datos han sido cargados correctamente y que todos los eventos de la base de datos ocurren apropiadamente.

Los métodos de manera generalizada y que son utilizados en el funcionamiento de los componentes: Twitter Integration y Facebook Integration son:

 add_instance(): Inserta en la base de datos una nueva instancia de los componentes.  update_instance(): Este método se utiliza para actualizar la información referente a una instancia.  delete_instance(): Este método elimina una instancia de los componentes.  insert_record(): De manera general esté método se utiliza para insertar objetos en la base de datos. En particular para insertar los datos relevantes de las interacciones generadas dentro de una instancia.  delete_activity(): Este método utilizamos para eliminar las interacciones que se crean dentro de una instancia.  activity_not_found(): Cuando una actividad ha sido eliminada desde fuera de la plataforma Moodle, esté método se encarga de eliminarla de la base de datos.  return_activity(): Este método se utiliza para retornar un arreglo que contiene las interacciones que se han realizado dentro de una instancia. 166

 save_external_tweets()-twitterintegration: Método utilizado para almacenar en la base de datos información relevante de los tweets generados desde fuera de la plataforma Moodle, y que son indexados mediante un hashtag determinado.  print_rating_menu(): Presenta una lista desplegable que contiene la escala con la que se puede calificar la interacción.  print_ratings(): Este método se utiliza para presentar la calificación brindada a una interacción (si ésta ha sido establecida) conjuntamente con un enlace hacia una nueva ventana que contiene más información acerca de la calificación.  get_ratings_mean(): Obtiene la calificación “promedio” de una interacción.  get_ratings_max(): Método utilizado para obtener la calificación más “alta” de una interacción.  get_ratings_min(): Se utiliza este método para obtener la calificación más “baja” de una interacción.  get_ratings_sum(): Obtiene la sumatoria total de la calificación brindada a una interacción.  get_ratings(): Devuelve una lista de las calificaciones otorgadas a una interacción en particular en una instancia.  get_user_grades(): Retorna la calificación de un usuario en particular o de todos los usuarios.  update_grades(): Actualiza las calificaciones, al ejecutarse el evento “grade_updated”.  grade_item_update(): Este método crea o actualiza un elemento de calificación para una instancia de los componentes.  grade_item_delete(): Elimina el elemento de calificación de una instancia de los componentes.

Del desarrollo de estas pruebas concluimos que las operaciones de manipulación, recuperación y almacenamiento de los datos utilizados por los componentes Twitter y Facebook Integration son correctas y no existen corrupciones ni pérdida de los mismos.

8.1.3. Pruebas de funcionamiento

Las pruebas de funcionamiento se basan en las historias de usuario. Por cada historia se plantea un objetivo, el cuál debe ser cumplido satisfactoriamente para asegurar que la aplicación funciona correctamente (Tabla 29).

167

Los objetivos de esta prueba son: verificar la apropiada aceptación de los datos, procesamiento y recuperación mediante la interacción con la aplicación a través de su interfaz gráfica.

Los requisitos necesarios que se utilizaron para desarrollar esta prueba se detallan a continuación:

 Plataforma Moodle versiones: 1.9, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7  Servidor Apache versión 2.4.10  Servidor MySQL versión 5.6.20  PHP versión 5.5.15

Tabla 29. Especificación pruebas de funcionamiento Código de Historia de usuario Objetivo prueba P001 1. Crear nueva instancia del plugin Comprobar que un usuario administrador o Twitter Integration profesor puede crear correctamente una instancia del plugin. P002 2. Editar configuración de instancia Probar que un administrador o profesor del plugin Twitter Integration puede ver el formulario para configurar una instancia y editarlo correctamente. P003 3. Eliminar instancia del plugin Comprobar que un profesor o administrador Twitter Integration puede eliminar correctamente el plugin. P004 4. Listar las interacciones en la Verificar que un usuario con rol de profesor, instancia del plugin Twitter administrador o alumno pueden visualizar Integration correctamente todas las interacciones realizadas en la instancia. Las interacciones además deben tener las acciones básicas que poseen todos los tweets (RT, Responder, FAV). P005 5. Asignar calificaciones a las Probar que un usuario profesor o interacciones de una instancia administrador puede asignar una calificación del plugin Twitter Integration correctamente a una interacción de una instancia. P006 6. Componer un nuevo tweet Verificar que un profesor, administrador o alumno pueden, en primer lugar iniciar sesión en Twitter y autorizar a la aplicación, para luego poder componer y enviar un nuevo tweet a la plataforma

168

P007 7. Listar los hashtags utilizados Comprobar que un usuario con rol de dentro de una instancia profesor, administrador o alumno, puede visualizar los hashtags utilizados dentro de la instancia, a manera de nube de etiquetas. P008 8. Visualizar la calificación otorgada Comprobar que un usuario con los roles a una interacción. necesarios puede ver la calificación de una o de todas las interacciones. P009 9. Crear nueva instancia del plugin Verificar que un usuario con rol de Facebook Integration. administrador o profesor puede crear una nueva instancia del plugin Facebook Integration. P010 10. Editar configuración de instancia Comprobar que un usuario con rol de del plugin Facebook Integration. profesor o administrador puede visualizar correctamente el formulario de edición de instancia y configurarlo satisfactoriamente. P011 11. Eliminar instancia del plugin Probar que un usuario administrador o Facebook Integration. profesor pueden eliminar satisfactoriamente una instancia del plugin Facebook Integration. P012 12. Listar las interacciones de la Verificar que un usuario con rol de profesor, instancia del plugin Facebook administrador o alumno, puede visualizar Integration. correctamente todas las interacciones (posts) realizadas dentro de la instancia. P013 13. Asignar calificaciones a las Comprobar que un usuario profesor o interacciones de una instancia administrador puede asignar calificaciones a del plugin Facebook Integration. las interacciones de una instancia correctamente. P014 14. Visualizar la calificación otorgada Comprobar que un usuario con los roles a una interacción. necesarios puede ver la calificación de una o de todas las interacciones. P015 15. Componer un nuevo post. Verificar que un usuario profesor, administrador o alumno, puedan en primer lugar iniciar sesión en Facebook y autorizar a la aplicación, para poder redactar y publicar un post dentro del grupo establecido en Facebook P016 16. Instalación de plugins. Comprobar que un administrador puede satisfactoriamente instalar los plugins Twitter Integration y Facebook Integration en la

169

plataforma Moodle, usando la versión correcta de cada plugin y para cada plataforma. P017 17. Actualización de plugins. Probar que un administrador puede realizar la actualización de los plugins Twitter Integration y Facebook Integration correctamente. P018 18. Desinstalación de plugins. Verificar que un administrador puede llevar a cabo la tarea de desinstalar los plugins Twitter Integration y Facebook Integration de la plataforma Moodle satisfactoriamente Fuente: Autor

8.1.3.1. Instalación, actualización y desinstalación de plugins

100% 90% 80% 70% 60% 50% P016 40% P017 30% P018 20% 10% 0%

Figura 41. Prueba de instalación, actualización y desinstalación de plugins. Fuente: Autor

La Figura 41 demuestra que los plugins Twitter Integration y Facebook Integration desarrollados en el presente proyecto, son instalables, actualizables y fáciles de desinstalar al 100% en las diferentes versiones de Moodle en los que han sido puesto a prueba los plugins. A continuación se describen las demás pruebas especificadas en la Tabla 29.

170

8.1.3.2. Plugin Twitter Integration

100% 90% 80% 70% 60% P001 50% P002 40% P003 30% 20% 10% 0% Moodle Moodle Moodle Moodle Moodle Moodle Moodle Moodle Moodle 1.9 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7

Figura 42. Pruebas de funcionamiento P001, P002, P003 Fuente: Autor

La Figura 42 presenta que el plugin Twitter Integration cumple con los objetivos de creación, modificación y eliminación de instancias al 100% en las versiones de Moodle 1.9, 2.3, 2.4, 2.5, 2.6, 2.7. En las versiones 2.0, 2.1 y 2.2 no fue posible el cumplimiento de las pruebas, por lo tanto se descartan estas versiones para las futuras pruebas.

100% 90% 80% 70% P004 60% P005 50% P006 40% P007 30% P008 20% 10% 0% Moodle 1.9 Moodle 2.3 Moodle 2.4 Moodle 2.5 Moodle 2.6 Moodle 2.7

Figura 43. Pruebas de funcionamiento P004, P005, P006, P007, P008 Fuente: Autor

La Figura 43 demuestra que las pruebas realizadas en las versiones de Moodle 1.9, 2.3, 2.4, 2.5, 2.6 y 2.7 son satisfactorias al 100%. 171

8.1.3.3. Plugin Facebook Integration

100% 90% 80% 70% 60% P009 50% P010 40% P011 30% 20% 10% 0% Moodle Moodle Moodle Moodle Moodle Moodle Moodle Moodle Moodle 1.9 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7

Figura 44. Pruebas de funcionamiento P009, P010, P011 Fuente: Autor

La Figura 44 demuestra que las prueba realizadas en las versiones de Moodle 2.0, 2.1, y 2.2 son totalmente insatisfactorias, por lo tanto se descartan estas versiones para las siguientes pruebas. Para las versiones 1.9, 2.3, 2.4, 2.5, 2.6, 2.7 las pruebas son totalmente satisfactorias.

100% 90% 80% 70% P012 60% P013 50% P014 40% 30% P015 20% 10% 0% Moodle 1.9 Moodle 2.3 Moodle 2.4 Moodle 2.5 Moodle 2.6 Moodle 2.7

Figura 45. Pruebas de funcionamiento P012, P013, P014, P015, P016 Fuente: Autor

La Figura 45 presenta que las pruebas realizadas en las versiones de Moodle 1.9, 2.3, 2.4, 2.5, 2.6 y 2.7 son satisfactorias al 100%. 172