Implementación de una red social de aprendizaje global sobre la plataforma GLESONE

i

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

La Universidad Católica de Loja

MODALIDAD PRESENCIAL

Escuela de Ciencias de la Computación

IMPLEMENTACIÓN DE UNA RED SOCIAL DE APRENDIZAJE GLOBAL SOBRE LA

PLATAFORMA GLESONE

Tesis previa a la obtención del título de Ingeniero en Sistemas Informáticos y Computación

Autor:

Luis Eduardo Ríos Castillo

Directores:

Ing. Juan Carlos Torres

Ing. Armando Augusto Cabrera

ii

CERTIFICACIÓN

Ing. Juan Carlos Torres

DIRECTOR DE TESIS

CERTIFICA:

Haber dirigido y supervisado el desarrollo del presente proyecto de tesis previo a la obtención del título de INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN, y una vez que este cumple con todas las exigencias y los requisitos legales establecidos por la Universidad Técnica Particular de Loja, autoriza su presentación para los fines legales pertinentes.

Loja, Octubre del 2011

...

iii

CERTIFICACIÓN

Ing. Armando Augusto Cabrera

DIRECTOR DE TESIS

CERTIFICA:

Haber dirigido y supervisado el desarrollo del presente proyecto de tesis previo a la obtención del título de INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN, y una vez que este cumple con todas las exigencias y los requisitos legales establecidos por la Universidad Técnica Particular de Loja, autoriza su presentación para los fines legales pertinentes.

Loja, Octubre del 2011

...

iv

AUTORÍA

El presente proyecto de tesis con cada una de sus observaciones, análisis, evaluaciones, conclusiones y recomendaciones emitidas, es de absoluta responsabilidad del autor.

Además, es necesario indicar que la información de otros autores empleada en el presente trabajo está debidamente especificada en fuentes de referencia y apartados bibliográficos.

...

v

CESIÓN DE DERECHOS

Yo, Luis Eduardo Ríos Castillo, declaro ser autor del presente trabajo y eximo expresamente a la Universidad Técnica Particular de Loja y a sus representantes legales de posibles reclamos o acciones legales.

Adicionalmente conocer y aceptar la disposición del Art. 67 del Estatuto Orgánico de la Universidad Técnica Particular de Loja que 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”.

...

vi

DEDICATORIA

vii

AGRADECIMIENTO

Agradezco a Dios por haberme permitido llegar hasta esta etapa de mi vida y luchar por la superación constante, por llenarme de su fuerza y sabiduría ya que sin el nada de esto sería posible.

Agradezco también a mis padres, en especial a mi madre que es la que desde niño ha venido inculcando en mí el deseo de superación, llenándome de su amor, cariño y comprensión. Agradezco a mis amigos y a todas y cada una de las personas que de forma indirecta me dieron palabras de aliento para seguir adelante y luchar por este sueño, en especial al Ing. Rodrigo López por brindarme todas las facilidades para el desarrollo de este proyecto, a mis hermanos que siempre han estado presentes cuando los he necesitado y me han brindado su ayuda incondicionalmente.

Al ingeniero Juan Carlos Torres que ha sabido guiarme en el proceso de elaboración de esta tesis, ya que él ha cumplido con profesionalismo su papel de director.

viii

Índice de Contenidos

CERTIFICACIÓN ... ii

CERTIFICACIÓN ... iii

AUTORÍA... iv

CESIÓN DE DERECHOS... v

DEDICATORIA ... vi

AGRADECIMIENTO ... vii

RESUMEN ... 1

INTRODUCCIÓN ... 2

1. ESTADO DEL ARTE ... 3

1.1. Introducción ... 3

1.2. Entornos Virtuales de Aprendizaje (EVA) ... 4

1.2.1. Componentes de un Entorno Virtual de Aprendizaje ... 5

1.2.2. Ventajas de usar un Entorno Virtual de Aprendizaje ... 6

1.3. Sistema de gestión de Aprendizaje (LMS) ... 7

1.3.1. Moodle ... 7

1.4. Redes Sociales ... 9

1.4.1. GlesOne ... 11

1.4.2. Impacto de las redes Sociales ... 11

1.4.3. Ventajas y desventajas de las redes sociales ... 12

1.5. API’s ... 13

1.5.1. Para qué una API? ... 14

1.5.2. Ejemplos de API’s ... 14

2. DEFINICIÓN DEL PROBLEMA Y ANÁLISIS DE LA SOLUCIÓN ... 16

2.1. Introducción ... 16

2.2. Estado actual ... 16

2.3. Planteamiento del Problema ... 17

2.4. Justificación ... 18

2.5. Objetivos ... 19

2.5.1. Objetivo General ... 19

ix

2.6. Resultados esperados ... 19

2.7. Actividades: ... 20

2.8. Descripción de la Solución. ... 20

2.9. Componentes de la Solución ... 21

2.9.1. Adaptación del Plugin de Autenticación en Red ... 22

2.9.2. Plugin de Red Social ... 22

2.9.3. API ... 22

2.9.4. Plugin formato temas semanas RSA ... 22

2.10. Requisitos ... 23

2.11. Metodología de investigación ... 23

2.12. Metodología de desarrollo ... 24

2.13. Ventajas de la Solución ... 25

3. DESARROLLO DE LA SOLUCIÓN SIGUIENDO LA METODOLOGÍA XP ... 26

3.1. Introducción ... 26

3.2. Programación Extrema (XP) ... 27

3.3. FASE I: Planificación ... 27

3.3.1. Historias de Usuario ... 27

3.3.2. Planificación de las iteraciones ... 28

3.3.3. Planificación de las Pruebas ... 29

3.4. FASE II: DESARROLLO ... 29

3.4.1. Tarjetas Clase - Responsabilidad – Colaborador (CRC) ... 29

3.4.2. Arquitectura de la solución ... 30

3.4.3. Componentes de la Arquitectura ... 30

3.4.4. Diagrama de Clases ... 35

3.4.5. Diagrama de secuencia ... 36

3.4.6. Modelo de datos ... 37

3.5. FASE III: Implementación ... 41

3.5.1. Adaptación del Plugin de Autenticación MNet para la red Central ... 41

3.5.2. Desarrollo de la Capa de Interoperatibilidad para la Red Social Central (API) .. 43

3.5.3. Desarrollo del plugin de red Social para Moodle ... 50

x

3.6. FASE IV: Pruebas ... 59

4. INFORME PLAN DE PRUEBAS ... 60

4.1. Introducción ... 60

4.2. Pruebas de integridad de datos ... 60

4.3. Pruebas de funcionamiento ... 61

4.3.1. COMPONENTE: Plugin Capa RSA ... 63

4.3.2. COMPONENTE: Plugin de Autenticación en Red ... 68

4.3.3. COMPONENTE: API para la red central. ... 71

4.3.4. COMPONENTE: Formato temas/semanas RSA ... 75

4.4. Pruebas de aceptación del usuario ... 77

DISCUSIÓN ... 82

Resultados del plugin Capa de Red Social ... 82

Resultados Interoperatibilidad entre sitios Moodle ... 83

CONCLUSIONES ... 84

RECOMENDACIONES ... 85

TRABAJOS FUTUROS ... 86

BIBLIOGRAFÍA ... 87

ANEXOS ... 90

A. ANEXO A HISTORIAS DE USUARIO ... 91

Iteración 1: Navegar de manera automática por la red central ... 91

Iteración 2: Desarrollo de un plugin del esquema RSA para Moodle ... 93

Iteración 3: Desarrollo y Consumo de la API de la Red Central ... 95

Iteración 4: Desarrollo de un nuevo formato de temas/semanas RSA ... 101

B. ANEXO B PLAN DE PRUEBAS INICIAL... 103

1 Introducción ... 103

1.1 Propósito ... 103

1.2 Alcance ... 103

1.3 Audiencia ... 104

1.4 Referencias ... 104

2 Objetivo y factores que motivan las pruebas ... 104

xi

3 Identificación del sistema a probar ... 105

4 Estrategia de pruebas ... 106

4.1 Tipos de pruebas ... 107

4.1.1 Pruebas de integridad de datos ... 107

4.1.2 Pruebas de funcionamiento ... 107

4.1.3 Pruebas de aceptación del usuario ... 108

4.2 Metodología ... 109

4.2.1. Encuestas ... 109

4.3 Herramientas a utilizar ... 116

5 Recursos ... 116

5.1 Recursos humanos ... 116

5.2 Recursos tecnológicos ... 117

6 Responsabilidades... 118

7 Entregables ... 118

7.1 Informe de pruebas ... 118

8 Riesgos ... 118

9 Glosario ... 119

C. ANEXO C TARJETAS CRC (CLASE RESPONSABILIDAD COLABORADOR) ... 120

D. ANEXO D ESTRUCTURA DEL MODELO DE DATOS ... 123

E. ANEXO E CONFIGURACIÓN DE LA RED MOODLE, EN LA RED CENTRAL ... 129

F. ANEXO F WSDL PARA EL CONSUMO DE LA API ... 143

G. ANEXO G SCRIPT DE LA BASE DE DATOS PARA EL PLUGIN CAPA RSA ... 156

H. ANEXO H PLUGIN DE INSTALACION DE LA CAPA RSA ... 160

I. ANEXO I PROTOTIPOS DE PANTALLA DEL FORMATO TEMAS/SEMANAS RSA ... 162

xii

Índice de Figuras

Figura 2-1: Situación actual de GLESONE ... 17

Figura 2-2: Comunicación entre entornos virtuales por medio de una capa de servicios ... 21

Figura 2-3: Componentes de la solución ... 21

Figura 3-1: Propuesta de solución ... 30

Figura 3-2: Componentes de la Arquitectura de la Red Global ... 31

Figura 3-3: Separación de los servicios en 3 capas (Alier, A proposal of interoperability architecture for Moodle, 2008) ... 34

Figura 3-4: Diagrama de clases ... 36

Figura 3-5: Diagramas de secuencia consumo de la API ... 36

Figura 3-6: Diagramas de secuencia establecimiento de curso ... 37

Figura 3-7: Modelo de datos del proyecto ... 38

Figura 3-8: Proceso de Autenticación entre sitios Moodle ... 42

Figura 3-9: Comunicación entre sitios iguales. ... 43

Figura 3-10: A web oriented framework for dynamic e-learning systems(Zhengfang & Zheng, 2007) ... 44

Figura 3-11: Esquema de las peticiones SOAP ... 45

Figura 3-12: Esquema de una función de la API ... 46

Figura 3-13: Estructura XML de un tipo de dato. ... 48

Figura 3-14: Estructura de un mensaje XML ... 48

Figura 3-15: Estructura de una operación o función XML. ... 49

Figura 3-16: Tipo de llamado o de operación que utiliza o escucha el servidor ... 49

Figura 3-17: Esquema del funcionamiento de los web services para red central ... 50

Figura 3-18: Captura de Pantalla sitio GLESONE.org ... 53

Figura 3-19: Sentencia SQL para extraer los post y colocar en los div... 55

Figura 3-20: Vista del nuevo formato de curso Semanas RSA ... 57

Figura 3-21: Vista del curso con formato Semanas RSA, perfil profesor ... 58

xiii

Figura 4-1Ingreso al sistema ... 62

Figura 4-2 Encuesta capa RSA para Moodle ... 63

Figura 4-3: Instalación de la capa RSA en varios sitios Moodle. ... 65

Figura 4-4: Nivel de aceptación de la capa RSA en Moodle V1.8.x. ... 65

Figura 4-5: Nivel de aceptación de la capa RSA en Moodle V1.9.x. ... 66

Figura 4-6: Instalación del plugin ... 67

Figura 4-7: Desinstalación del plugin ... 68

Figura 4-8: Encuesta Interoperatibilidad del sitio ... 69

Figura 4-9: Configuración del sitio ... 70

Figura 4-10: Navegación entre sitios ... 71

Figura 4-11: Encuesta API para la red central ... 72

Figura 4-12: Autenticación para consumo de la API ... 73

Figura 4-13: Conexión con la red central ... 74

Figura 4-14: Mensajes de error en el consumo de la API ... 75

Figura 4-15: Encuesta Usuario solo estudiante ... 76

Figura 4-16: Encuesta Usuario solo profesor ... 77

Figura 4-17: Encuesta Usuario percepción del formato ... 78

Figura 4-18: Nivel de Aceptación por componentes ... 81

Figura D-1: Tabla course_sections ... 123

Figura D-2: Tabla rsa_actividad ... 123

Figura D-3: Tabla rsa_invitaciones ... 124

Figura D-4: Tabla rsa_participantes_curso ... 124

Figura D-5: Tabla rsa_post ... 124

Figura D-6: Tabla rsa_post_comentario ... 125

Figura D-7: Tabla course ... 126

Figura D-8: Tabla course_sections ... 127

Figura D-9: Tabla webservices_sessions ... 127

Figura D-10: Tabla user ... 128

Figura E-1: Pantalla entorno de un sitio Moodle ... 130

Figura E-2: Pantalla como habilitar el modo depuración de Moodle ... 131

Figura E-3: Clave pública de un servidor Moodle ... 132

xiv

Figura E-5: Como habilitar modo hub a Moodle ... 133

Figura E-6: Enlace de All hosts, modo hub ... 133

Figura E-7: Habilitación de servicios ... 134

Figura E-8: Habilitación de la autenticación en red de Moodle ... 135

Figura E-9: Añadir automáticamente usuarios remotos ... 135

Figura E-10: Clave pública del sitio Moodle ... 135

Figura E-11: Agregar url de la red central en el cliente externo Moodle ... 136

Figura E-12: Visualización del host de la red central en el cliente ... 136

Figura E-13: Autenticación de la red Moodle ... 137

Figura E-14: Revisión de la clave pública del host central ... 137

Figura E-15: Habilitación de los servicios ... 138

Figura E-16: Bloque de navegación Roles ... 138

Figura E-17: Pantalla asignación de permisos a los roles de usuario. ... 139

Figura E-18: Selección de bloques instalados ... 140

Figura E-19: Pantalla del sitio Glesone, habilitado el bloque de networks servers ... 140

Figura E-20: Matriculación en red ... 141

Figura E-21: Habilitación de matrículas remotas ... 141

Figura E-22: Habilitación de los servicios matriculación en red ... 142

Figura I-1: Prototipo del nuevo formato de curso V1 ... 162

Figura I-2: Prototipo del nuevo formato de curso V2 ... 163

Figura I-3: Prototipo del nuevo formato de curso V3 ... 163

Figura I-4: Hipervínculo sin RSA ... 164

Figura I-5: Hipervínculo con RSA ... 164

Figura I-6: Prototipo del nuevo formato de curso V4 (Sin RSA) ... 165

Figura I-7: Prototipo del nuevo formato de curso V4 (Con RSA) ... 165

Figura I-8: Inserción del post dentro de la sección ... 165

Figura I-9: Nuevo formato de curso ... 166

Figura J-1: Bloque de navegación del sitio ... 167

Figura J-2: Categorías de cuso ... 167

Figura J-3: Visualización de los cursos dentro de la categoría ... 168

Figura J-4: Creación de un curso, nombre del curso ... 168

xv

Figura J-6: Asignación de roles en el curso ... 169

Figura J-7: Sección 0 del curso, Generalidades ... 170

Figura J-8: Sección 1N del curso, permitir comentarios ... 170

Figura J-9: Confirmación de habilitar comentarios. ... 171

Figura J-10: Inserción del post con opción denegar comentar al estudiante ... 171

Figura J-11: Cuadro de confirmación denegar comentario al tema. ... 171

Figura J-12: Pantalla una vez negados los comentarios ... 172

xvi

Índice de Tablas

Tabla 3-1: Modelo propuesto para una historia de usuario (Canos, Leiter & Penadés, 2005)... 28

Tabla 3-2: Modelo de tarjeta CRC (Reynoso Billy) ... 29

Tabla 3-3: Formato del plugin capa RSA ... 52

Tabla 4-1 Ingreso al sistema... 62

Tabla 4-2 Encuesta capa RSA para Moodle ... 63

Tabla 4-3: Instalación de la capa RSA en varios sitios Moodle. ... 64

Tabla 4-4: Instalación del plugin ... 66

Tabla 4-5: Desinstalación del plugin ... 67

Tabla 4-6: Encuesta Interoperatibilidad del sitio ... 68

Tabla 4-7: Configuración del sitio ... 69

Tabla 4-8: Navegación entre sitios ... 70

Tabla 4-9: Encuesta API para la red central ... 71

Tabla 4-10: Autenticación para consumo de la API ... 72

Tabla 4-11: Conexión con la red central ... 73

Tabla 4-12: Mensajes de error en el consumo de la API ... 74

Tabla 4-13: Encuesta Usuario solo estudiantes ... 75

Tabla 4-14: Encuesta Usuario solo profesor ... 76

Tabla 4-15: Encuesta Usuario percepción del formato... 78

Tabla 4-16: Rangos de Aceptación ... 79

Tabla 4-17: Nivel de Aceptación por componentes ... 80

Tabla A-1: Historia de Usuario 1, Ingresar automáticamente a la red central ... 91

Tabla A-2: Tarea 1 para la historia de usuario 1 ... 92

Tabla A-3: Tarea 2 para la historia de usuario 1 ... 92

Tabla A-4: Tarea 3 para la historia de usuario 1 ... 93

Tabla A-5: Tarea 4 para la historia de usuario 1 ... 93

Tabla A-6: Historia de usuario 2, Construir una capa RSA de GLESONE para Moodle por medio de un plugin ... 94

Tabla A-7: Tarea 1 para la historia de usuario 2 ... 94

xvii

Tabla A-9: Tarea 3 para la historia de usuario 2 ... 95

Tabla A-10: Historia de usuario 3, establecer conexión para consumir la API ... 96

Tabla A-11: Tarea 1 para la historia de usuario 3 ... 96

Tabla A-12: Tarea 2 para la historia de usuario 3 ... 97

Tabla A-13: Tarea 3 para la historia de usuario 3 ... 97

Tabla A-14: Tarea 4 para la historia de usuario 3 ... 98

Tabla A-15: Historia de usuario 4, consumir la API ... 98

Tabla A-16: Tarea 1 para la historia de usuario 4 ... 99

Tabla A-17: Tarea 2 para la historia de usuario 4 ... 99

Tabla A-18: Tarea 3 para la historia de usuario 4 ... 100

Tabla A-19: Tarea 4 para la historia de usuario 4 ... 100

Tabla A-20: Tarea 5 para la historia de usuario 4 ... 101

Tabla A-21: Historia de usuario 5, guardar datos de la sesión ... 101

Tabla A-22: Historia de usuario 6, desarrollar nuevo formato de temas/semanas RSA ... 102

Tabla A-23: Historia de usuario 7, Guardar los datos del nuevo formato temas/semanas RSA ... 102

Tabla 4-1: Pruebas de integridad datos ... 107

Tabla 4-2: Pruebas de funcionamiento ... 108

Tabla 4-3: Encuesta usuario Estudiante/Profesor ... 110

Tabla 4-4: Encuesta, apreciación del proyecto ... 112

Tabla 4-5: Encuesta técnica. ... 114

Tabla 4-6: Herramientas a utilizar ... 116

Tabla 5-1: Recursos Humanos ... 116

Tabla 5-2: Recurso tecnológico ... 117

Tabla 6-1: Responsabilidades ... 118

Tabla C-1: Tarjeta CRC Formato ... 120

Tabla C-2: Tarjeta CRC Sesión ... 120

Tabla C-3: Tarjeta CRC WEB SERVICE ... 120

Tabla C-4: Tarjeta CRC Post ... 121

Tabla C-5: Tarjeta CRC Actividad ... 121

Tabla C-6: Tarjeta CRC Invitacion ... 121

xviii

1

RESUMEN

El presente proyecto inicia analizando el estado actual del proyecto GLESONE desarrollado en el departamento de Virtualización de la UTPL, a la par, se abordan conceptos básicos que se aplicarán de manera que se pueda tener una idea clara de sus objetivos.

Seguidamente identificamos los requerimientos. De manera general se resume en los siguientes ítems:

• Adaptación de un plugin de autenticación para Moodle.

• Desarrollo de una API para la interconexión entre redes sociales tipo GLESONE.

• Generación del plugin de red social para Moodle que actualmente no se encuentra como tal.

• Desarrollo y adaptación del formato de temas y semanas en los cursos de Moodle a un esquema de red social.

Una vez identificados los requerimientos se procederá a elaborar la solución para cada uno de ellos; finalmente se procederá a validar los resultados mediante un plan de pruebas que se elaborará para el efecto; dicho plan, permitirá evidenciar que se logró cumplir con los objetivos plateados, obteniendo resultados favorables y una herramienta que sin lugar a duda ayudara de manera significativa en la mejora del modelo enseñanza-aprendizaje

2

INTRODUCCIÓN

En los últimos años, la Universidad Técnica Particular de Loja (UTPL) a través de su unidad de Virtualización, ha venido trabajando en un proyecto que pretende unir a varias redes tipo GLESONE reunidos mediante una sola red Central con características de red social, pretendiendo mejorar la comunicación y apoyar con ello el proceso de enseñanza-aprendizaje, gestionando e impartiendo cursos, con las ventajas que ofrecen actualmente las redes sociales.

3

1.

ESTADO DEL ARTE

1.1. Introducción

La educación enfrenta un reto constante, tratando de dar respuesta a las nuevas necesidades que surgen en esta sociedad moderna, en donde la tecnología de la comunicación y la información están configurando nuevos escenarios y entornos de aprendizaje.

La educación de manera virtual crece rápidamente, debido a que son cada vez más las herramientas digitales, tanto de producción, transporte como de comunicación de contenidos. Es por ello que la educación presencial también se ve obligada a incorporar cada vez más esas tecnologías, especialmente en los niveles medio y superior. Esta situación exige a los docentes la adquisición de nuevas competencias, y la adecuación de las formas tradicionales de enseñanza a las nuevas modalidades de enseñanza-aprendizaje.

Sin embargo, a pesar de que los nuevos espacios de aprendizaje, entornos virtuales y redes sociales, facilitan la intercomunicación entre los actores del proceso de enseñanza-aprendizaje, no garantizan una apropiación de los métodos de las pedagogías innovadoras, por lo que cada usuario debe ser partícipe activo de su propia auto-formación.

4

1.2. Entornos Virtuales de Aprendizaje (EVA)

(Avila & Bosco, 2001), plantean que “un Entorno Virtual de Aprendizaje (EVA), es un espacio virtual, donde los medios tecnológicos como el Internet, la multimedia, y la

televisión interactiva entre otros, se han potencializado, sobrepasando al entorno de

enseñanza tradicional, favoreciendo al enriquecimiento del conocimiento y a la

apropiación de contenidos, experiencias y procesos dogmáticos”. En resumen los EVA,

están conformados por el espacio en sí, estudiantes, profesor/tutor, contenidos educativos, la evaluación y los medios de información y comunicación.

Según (Alberto, 2009), un EVA “es todo espacio virtual con interacciones asincrónicas y/o sincrónicas, planificado a partir de un diseño instruccional basado en las

necesidades e intereses de la audiencia, siendo flexible y adaptable en todos sus

aspectos, el cual busca facilitar la gestión y el logro del aprendizaje de un tema en un

área común, mediante alguna de las plataformas adecuadas que nos proveen las

TIC, propiciando la participación de todos los involucrados para que conformen una red

modelada por los principios del trabajo y el aprendizaje colaborativo, todo esto durante

un período de tiempo específico”.

En el concepto planteado en el párrafo anterior se habla de las TIC, pues no olvidemos que estas facilitan el flujo digital entre profesores/tutores y estudiantes que trabajan en áreas comunes (Herrera, 2001), permitiendo mejorar la colaboración e intercambio para fortalecer los resultados del trabajo académico e incrementar los niveles de producción, productividad y competitividad.

5

Los EVA no se ajustan a la educación formal/tradicional, ni tampoco a una modalidad educativa en particular, más bien, son espacios en donde se crean las condiciones para que el estudiante se apropie de nuevos conocimientos, de nuevas experiencias, de nuevos elementos que le generen procesos de análisis, reflexión y apropiación. Se denominan virtuales porque no se llevan a cabo en un lugar predeterminado (es decir en un lugar físico determinado, como un salón de clases), sino que el elemento distancia está presente.

Dentro de este mismo ámbito cabe señalar que muchas instituciones educativas de nivel superior han venido incorporando carreras y cursos en modalidad total o parcialmente no presenciales, con uso intensivo de herramientas de la web 2.0, tecnologías de la comunicación, de la información, y entornos virtuales de aprendizaje.

Los EVA, no se gestionan por si solos, no se dan de manera automática, tampoco surgen como generación espontánea, ni son tampoco resultado de las Nuevas Tecnologías. Cuando se diseñan ambientes de aprendizaje se debe tomar en cuenta la necesidad de tratar de modificar día a día las actitudes, ideas y mecanismos tradicionales entre docentes y estudiantes, esto implica la modificación de la imagen de autoridad y del saber hasta las formas de uso de los medios y de las tecnologías.

Aun cuando hemos hablado de la importancia del estudio independiente, el docente continúa conservando un rol importante en la planeación, en la dinámica de trabajo, en el diseño instruccional y en las estrategias de aprendizaje con miras a la construcción del conocimiento.

1.2.1.

6

Entorno Virtual de Aprendizaje, han de estar presentes ciertos componentes que se definen desde una óptica interdisciplinar.

• Funciones pedagógicas (todas aquellas actividades de aprendizaje, situaciones de enseñanza, materiales de aprendizaje, apoyo y autorización, evaluación, entre otros).

• Tecnología apropiada (se debe tratar que las herramientas seleccionadas estén vinculadas con el modelo pedagógico).

• Organización social de la educación (espacio, calendario y comunidad).

1.2.2.

Una de las grandes ventajas que ofrecen los EVA, es que los usuarios identificados (profesores/tutores, alumnos y administradores) pueden comunicarse entre sí en cualquier momento, enviar los trabajos y recibir los resultados de sus ejercicios.

Cabe destacar, además, que para entablar estas comunicaciones no es necesario coincidir en tiempo y espacio con el interlocutor o los interlocutores seleccionados.

En términos generales, un EVA, establece un espacio de comunicación total entre todos y cada uno de los usuarios, potenciando el aprendizaje, la cooperación, la creación de nuevas iniciativas, etc., con resultados altamente positivos.

7

1.3. Sistema de gestión de Aprendizaje (LMS)

Al hablar de un LMS estamos refiriéndonos a toda una herramienta software, que permite agilizar el proceso de enseñanza aprendizaje dentro del modelo educativo. Mediante un LMS se puede: administrar, gestionar e impartir cursos por medio del internet, llegando de esta forma hacia el estudiante donde sea que este se encuentre. Ya desde el punto de vista universitario se considera un LMS, como una parte importante dentro de la educación a distancia ya que como se mencionó, permite a los docentes automatizar la administración de los cursos que se imparten a los estudiantes.

(Bersin, Howard, O’Leonard, & Mallon, 2009), afirman que, “un LMS acelera todo el proceso de enseñanza-aprendizaje en las instituciones educativas ya que a través de

ellos se puede identificar aspectos de cara a cada estudiante como sus puntos fuertes y

débiles, definiendo modelos de usuario que permiten adaptar el sistema a las

necesidades de aprendizaje de cada uno de estos”.

1.3.1.

La plataforma Moodle es un ejemplo claro de LMS, ya que es un herramienta diseñada para dar sustento a la educación y en cierto aspecto se orienta al aprendizaje colaborativo, esta plataforma presenta muchas características que sirven de apoyo para el aprendizaje de los estudiantes, entre estas características tenemos, foros, uso de recursos compartidos, chat, etc. A través de Moodle se puede gestionar gran cantidad de estudiantes en cada curso por parte del tutor, lo mismo que sirve de gran apoyo a los docentes de la universidad.

1.3.1.1.

8

La Navegación es accesible, confiable y estable.

En cuanto a la comunicación asíncrona, de uno a uno y de uno a muchos la plataforma ofrece un recurso (foro) de comunicación durante el desarrollo del curso. De la misma manera la plataforma ofrece recursos de comunicación síncrona (chat).

En el foro de discusión y el tablón de mensajes se puede usar lenguaje HTML1 _{lo cual hace más atractivos los mensajes que} pueden publicar los tutores on-line y alumnos.

El acceso a los contenidos así como a los recursos es fácil, rápido y muy intuitivo.

Los tres pilares fundamentales de la plataforma Moodle son: el aula virtual, el tutor y el estudiante, pero se puede destacar como el motor de todo este modelo al tutor, ya que este es quien se encarga de coleccionar la información idónea para propiciar el proceso de enseñanza aprendizaje guiando a todos y cada uno de sus estudiantes.

1.3.1.2.

En el artículo publicado (Moodle, Ejemplos de E-learning, 2010), se afirma que a pesar que Moodle es una herramienta destinada a la educación a distancia, muchas instituciones educativas como universidades lo usan como complemento en las clases que imparten con la modalidad de presencial

- Permite distribuir materiales de aprendizaje, crear y gestionar foros y anuncios, realizar cuestionarios a los estudiantes, evaluar tareas, integrar recursos de Internet, crear glosarios y diccionarios o gestionar el tiempo a través de un calendario global de distintas asignaturas.

1

9

- Como herramientas de comunicación permite la mensajería instantánea o la tutoría electrónica en privado o en grupo.

- Es de código abierto, del cual se puede editar el código fuente; es decir, se puede cambiar parte del funcionamiento del sistema, realizar aportes que logren mejorar las versiones presentadas, esto brinda la oportunidad de adaptar el campus a las necesidades que presenta la universidad realizando actualizaciones constantemente.

1.4. Redes Sociales

Al hablar de redes sociales estamos hablando de sitios web que ofrecen servicios, principalmente de comunicación, para estar en contacto con todos los usuarios de la red.

Las redes sociales en Internet posibilitan interactuar con otras personas aunque no las conozcamos, se trata de un sistema abierto y que se va construyendo con lo que cada usuario de la red va aportando, cada nuevo miembro que ingresa transforma de cierta manera la red social. Una red social, no es lo mismo si uno de sus miembros se vuelve pasivo o deja de ser parte de la misma, la clave del éxito de una red social es la interacción constante de sus miembros.

Estar inmerso en una red social implica, encontrar en ella personas con quienes compartir nuestros intereses, gustos, disgustos, preocupaciones o necesidades y aunque no sucediera más que eso y no pasara de allí, el hecho mismo de compartir simples intereses comunes ya es mucho, porque rompe el estado en solitario al que suele estar sujeto la gran mayoría de personas, lo cual suele manifestarse con una baja autoestima y adversas capacidad para relacionarse en sociedad.

10

cuando un usuario se conecta no busca crear redes o hacer que esta red sea más grande, lo que el busca es comunicarse con las personas que ya forman parte de su entorno social.

Dentro de las redes sociales, para darnos a conocer manejamos un perfil (gustos, edad, lugar,…etc.), (Suden, 2003), que ayuda a determinar a los demás usuarios de la red social si esa persona comparte gustos similares, y si lo hace puede formar parte de nuestra red personal de amigos, aunque amigos no en el sentido literal de la palabra, no olvidemos que la razón por las que las personas se agregan y se conectan son variadas (Boyd, 2006)

Por otra parte yendo más allá, de los perfiles, amigos, comentarios, etc.; existen varios sitios con el concepto de red social y en cierta forma todos son diferentes, variando mucho en sus características en sí, mientras unos se especializan más en el compartir fotos, videos otros se han orientado más en sitios de mensajería instantáneas ejemplo de ello están:

- Facebook, herramienta social que conecta personas con amigos y otras personas que trabajan, estudian y viven alrededor de ellos (Zuckerberg, 2004).

- MySpace, es el principal destino de entretenimiento social impulsado por la pasión de los aficionados. Música, cine, famosos, televisión y juegos hechos sociales (Anderson & DeWolfe, 2003)

- Twitter, es una red de información de tiempo real. Millones de personas, organizaciones y empresas lo utilizan para descubrir y compartir la información (Twitter, 2006). Simplemente se buscan cuentas relevantes y se sigue las conversaciones.

11

1.4.1.

Se trata de una plataforma Moodle, sobre la cual se desarrolló una capa de red social, que pretende integrar a usuarios de plataformas de aprendizaje virtual sobre Moodle que están dispersos por todo el mundo, permitiendo la interacción entre cada uno de estos a través de una red global de aprendizaje social. Se basa en la premisa de que el conocimiento n el siglo XXI se crea en un espíritu de colaboración, social y global (UTPL, 2010).

Las plataformas virtuales que forman parte integral de GlesOne tienen características únicas. Por ejemplo, la interfaz de usuario tiene el aspecto de red social y las estructuras de su marco metodológico sobre la colaboración y la interacción propias de los EVA.

1.4.2.

Sin lugar a duda las redes sociales han tenido un gran impacto dentro de la sociedad, y han hecho cambiar nuestro modo de vida, vemos que cada día aparecen nuevas herramientas que facilitan la vida de nosotros los usuarios, todo esto altera los hábitos de vida de la sociedad como la conocemos. De la misma forma que algunos crecimos en su tiempo, influenciados por el auge de la informática o los videojuegos, los jóvenes de hoy en día, están haciendo lo propio con esta nueva era de Internet y de las herramientas web 2.0, han nacido con la Red, están creciendo con la Red y están viviendo con la Red.

Según estudios llevados a cabo por él (Pew Reseach Center, 2010), el 55% de los jóvenes estadounidenses (entre 12 y 17 años) que hacen uso de Internet, utilizan Redes Sociales y tienen su perfil propio. Por si fuera poco, el 48% de ellos asegura visitar estas páginas todos los días, cifras significativas y hay que considerar que estas seguirán creciendo conforme pase el tiempo.

12

comunicación empresarial, la creatividad, la participación, la gestión del conocimiento,… múltiples procesos de negocio pueden salir beneficiados gracias a su utilización.

“Las redes sociales no son una moda juvenil o algo pasajero, están cambiando nuestra realidad social y económica así como el mundo laboral más de lo que lo

ha hecho Internet desde sus orígenes” (Porrúa García, 2009).

Solo resta decir que si las redes sociales están allí, usémoslas pero con acierto, y obtendremos sin lugar a duda beneficios de ello.

1.4.3.

1.4.3.1.

Es una gran fuente de información, donde se puede obtener noticias del momento más fácilmente, puedes comunicarte con personas alrededor del mundo con una solo clic, permite conocer personas e interactuar con estas, se puede obtener información interesante, expresar nuestros pensamientos y sentimientos; también es posible conseguir trabajos y hacer publicidad de un nuevo producto o empresa.

1.4.3.2.

13 1.5. API’s

Una interfaz de programación de aplicaciones o más comúnmente llamada API, es el conjunto de funciones y procedimientos que ofrece cierta librería mediante una interfaz con la cual el programador puede acceder a dichas funciones y procedimientos (Zerbts, 2004.)

(Wikipedia, 2008), define una API como “una interfaz de comunicación entre componentes de software. Se trata del conjunto de llamadas a ciertas bibliotecas que

ofrecen acceso a ciertos servicios. Uno de los principales propósitos de una API consiste

en proporcionar un conjunto de funciones de uso general. De esta forma, los

programadores se benefician de las ventajas de la API haciendo uso de su funcionalidad, evitándose el trabajo de programar todo desde el principio”.

Para que este concepto sea entendido de mejor manera se tratara de dar un concepto con palabras no técnicas, entonces una API se trata de pre-programar un sistema que consiste en una serie librerías (funciones) que serán ejecutadas en otra aplicación. Esta lista de funciones, se publican en la documentación de la API. De forma que cuando un programador externo quiere que en su programa se muestre la información que nosotros tenemos disponible, solo ha de hacer una llamada a determina función que ya le fue proporcionada.

Es una forma de dar un acceso restringido a la información de nuestra aplicación sin dejar que el programador externo acceda a tu código, solo puede usar y ejecutar aquellas cosas que nosotros hayamos diseñado y permitido.

Ya volviendo al formalismo, se puede decir que una de las funciones centrales de una API es la de ofrecer un grupo de funciones o métodos que nos permiten utilizar servicios, dentro de alguna aplicación web que estuviésemos desarrollando.

14

1.5.1.

Principalmente para solucionar gran parte de las necesidades o requerimientos de los desarrolladores que cuentan con algún proyecto web, ya sea como herramienta propia de negocio o como medio de difusión.

Las API’s no solamente se observan mediante interacciones entre diferentes sitios web, sino que también se incorporan en aplicaciones, programas y widgets de escritorio, otorgando el acceso a los datos provistos por una aplicación central.

La API puede utilizarse con cualquier plataforma y lenguaje de programación que esté utilizando, ya que utiliza las normas internacionales: WSDL, SOAP y XML:

• Un archivo WSDL describe la API de forma convencional

• SOAP es el protocolo de transmisión de mensajes entre la aplicación externa y la API.

• Los datos intercambiados están en formato XML.

Si no existiera la API, y se quisiera hacer uso de algún recurso de un sitio web que ofrezca servicios, sería necesario logearse sobre la base de datos del sitio, obtener la información de un usuario sobre dicha base de datos, obtener el dato que requerido en el lenguaje de programación requerido, y capturarlo. Lo cual por supuesto supone un mayor esfuerzo y un terrible riesgo de seguridad para el sitio que quiera ofrecer servicios web.

1.5.2.

Ahora serán mencionados algunos ejemplos de API's para ilustrar mejor la explicación (Gonzales, 2008):

15

interesante para cualquier medio de comunicación encargado de producir videos, ya que le permite no tener que invertir dinero en hosting.

2. API Win 32: permite que una aplicación determinada corra en Windows. Entre sus funciones específicas se encuentran, entre otras: comunicación entre procesos, depuración de errores o manejo de energía.

16

2.

DEFINICIÓN DEL PROBLEMA Y ANÁLISIS DE LA SOLUCIÓN

2.1. Introducción

En este capítulo se muestra la situación actual del proyecto GLESONE, que es llevado a cabo por la Unidad de Virtualización de la Universidad Técnica Particular de Loja (UTPL), proyecto que pretende mejorar el proceso de enseñanza-aprendizaje, compartiendo el conocimiento a través de una red social que agilice y mejore la comunicación entre usuarios de diferentes entornos virtuales de aprendizaje que contengan una capa de red social como GLESONE. Así mismo se determinará el problema específico, su alcance y las fases que lo componen. Estamos seguros que esta herramienta permitirá a todos aumentar las posibilidades del aprendizaje colaborativo.

Se analiza brevemente como participan los usuarios en el desarrollo de un curso, también se establecen los objetivos, los resultados esperados y la justificación del trabajo que se está realizando. Para el análisis del problema, primeramente se hace un planteamiento de la situación actual del proyecto. Seguidamente se hace la definición de la solución con la cual se pueda satisfacer todos los requerimientos planteados.

Finalmente para terminar el capítulo se presentan las ventajas de aplicar la solución definida y se plantea un escenario de trabajo sobre el cual se va a llevar a cabo el desarrollo del proyecto.

2.2. Estado actual

17

En este mismo espacio se plantean actividades por parte del tutor y son presentadas en forma general a todos los usuarios que participan en la red social (cursos), las mismas que pueden ser revisadas cuando un usuario ingresa.

Todo usuario tiene acceso a su muro personal por lo que este puede comentar su estado cuando lo desee, además también tiene acceso a cada una de las redes sociales (cursos), en los que se encuentra enrolado, en el que de manera específica puede solicitar accesoria y compartir sus estados con los demás usuarios que toman el mismo curso, permitiendo tener una especie de asesoría mucho más explícita por usuarios que comparten una misma temática e intereses similares, así mismo dentro de la red social(curso) puede buscar nuevas actividades planteadas o revisar los recursos que el tutor ha compartido.

2.3. Planteamiento del Problema

El proyecto pretende llegar a reunir varias redes tipo GLESONE a través de una red centralizada permitiendo que sus usuarios sean capaces de compartir sus inquietudes, necesidades y principalmente conocimiento.

Actualmente no es posible que los usuarios puedan crear sus propias redes sociales con contactos de otras redes tipo GLESONE y compartan sus experiencias, inquietudes e intereses, haciendo que tengan que manejar diferentes cuentas en diferentes sitios. El no contar con una capa de intercomunicación limita a los usuarios de GLESONE para que puedan comunicarse entre sí, ésta situación se ve reflejada en la Figura 2-1

18 2.4. Justificación

El presente proyecto se lo realiza considerando las necesidades que surgieron con el desarrollo y creación de este nuevo entorno de aprendizaje con capa de red social, permitiendo a los usuarios mayor flexibilidad para intercambiar información.

El proyecto consiste en el desarrollo y adaptación de una plataforma que permita montar una red social que integre a los usuarios de Entornos Virtuales de Aprendizaje (EVA). Esto permitirá que los miembros de instituciones educativas de todo el mundo puedan crear redes sociales en función de sus necesidades de aprendizaje, con estudiantes de otras instituciones.

Para el efecto, es vital desarrollar una plataforma Central que integrara a dichos usuarios, así mismo, es necesario el desarrollo de un API sobre tal plataforma, que permita que otros EVA accedan a la red social Central y finalmente un plugin que amplíe las capacidades de estos, para conectarse con dicha red y trabajar de esta manera en un ambiente social. Esto último, está basado en el desarrollo ya existente del proyecto www.glesone.org el mismo que cuenta ya con un esquema social.

19 2.5. Objetivos

2.5.1.

- Desarrollar una capa de intercomunicación y una API que permita establecer un túnel de comunicación entre varias redes tipo GLESONE mediante la red central.

2.5.2.

- Desarrollar una capa de red social, basada en los principios de GlesOne, para que nuevos entornos virtuales de aprendizaje puedan acoplarla según sus necesidades.

- Implementar una API que permita intercomunicar a entornos virtuales de aprendizaje, con la red central.

- Desarrollar un nuevo formato de temas y semanas para GlesOne, tomando como principio el esquema social.

- Lograr que los usuarios de un entorno virtual de aprendizaje (Moodle), puedan iniciar sesión en la red central GlesOne, sin necesidad de registrarse nuevamente sobre dicha red.

2.6. Resultados esperados

- Que el plugin desarrollado, denominado “capa RSA”, pueda ser instalado en cualquier entorno virtual de aprendizaje, que posea características similares, a la plataforma sobre la que fue desarrollado GlesOne.

- Que a través de la API, los nuevos sitios con esquema social, puedan estar comunicados e informados de las constantes actividades que sobre la red central son llevados a cabo.

20

- Que los usuarios de otras redes sociales (entornos virtuales de aprendizaje), logren comunicarse con la red central sin necesidad de registrarse nuevamente en el sitio.

2.7. Actividades:

- Estudiar la arquitectura de un entorno virtual de aprendizaje - Adaptar el plugin de Autenticación en Red en la red central - Desarrollar un plugin de red social para la plataforma Moodle - Conocer la estructura y funcionamiento de una API

- Adaptar, desarrollar e implementar una API que permita ofrecer servicios a la red central.

- Adaptar del esquema de temas y semanas de Moodle a un esquema de red social combinado.

2.8. Descripción de la Solución.

Se pretende dar solución a la problemática planteada mediante la instalación de un plugin que permita la interacción automática entre usuarios de sitios Moodle, permitiendo que usuarios debidamente registrados en una red GLESONE, puedan iniciar sesión en la red social central sin tener que registrarse nuevamente, por ejemplo, el usuario “jperez”, con cuenta en su red local, podrá automáticamente iniciar sesión en la red social central con su mismo nombre de usuario y password, así mismo este plugin registrara a todos los nuevos usuarios en la base de datos como si fuera propio del sitio de la red social central.

21

Figura 2-2: Comunicación entre entornos virtuales por medio de una capa de servicios

Lo que la Figura 2-2, representa es, que todas las redes sociales tipo GLESONE, por medio de esta nueva red social central, que posee una capa de interoperatibilidad, los usuarios podrán formar redes sociales con otros de cualquier red social tipo GLESONE.

2.9. Componentes de la Solución

La Figura 2-3, ilustra de manera clara, los componentes de los cuales estará compuesta la solución:

22

2.9.1.

Adaptación del Plugin de Autenticación en Red

Este plugin permitirá comunicarse de manera automática con cualquier otro sitio similar que haya activado la autenticación en red; esto es posible gracias a que llaves públicas son compartidas entre los sitios.

2.9.2.

Plugin de Red Social

Al momento el esquema de red social se encuentra implementada dentro de la red Central Moodle, pero al no encontrarse identificado en una única capa no se puede compartir con la comunidad Moodle, por lo que será extraída en un solo paquete; para formar un plugin y poder compartirlo con los demás sitios.

2.9.3.

API

Esta capa permitirá ofrecer servicios a los demás sitios y de esta forma establecer un túnel de comunicación directa con la red central.

2.9.3.1.

Al hablar de un servicio Web, estamos hablando de un sistema de software desarrollado para apoyar la interacción entre plataformas sobre la red. Tiene una interfaz descrita en un formato procesable por la máquina (específicamente WSDL). Otros sistemas interactúan con el servicio Web de una manera prescrita por su descripción usando mensajes SOAP, típicamente transmitido a través de HTTP con una serialización2 _{XML. (W3C, Booth, & Haas, 2004)}

2.9.4.

Plugin formato temas semanas RSA

Este estilo único de formato propio del esquema social facilitará al tutor, dar tutorías por temas y semanas con un formato único de red social.

2

23 2.10. Requisitos

Los requisitos que se listan a continuación son la base para el desarrollo del proyecto los mismos fueron planteados según las necesidades que se requería satisfacer con el desarrollo del proyecto.

- Permitir que usuarios externos Moodle, puedan acceder de manera automática a la red Central.

- Permitir que un cliente pueda logearse para consumir información a través de la API desde la red central, con solo un username y password.

- Por cuestiones de seguridad validar la sesión del cliente, al momento de realizar el consumo de las funciones que conforman las API.

- Implementar las diferentes funciones que puede consumir un cliente.

- Desarrollar una capa de red social que se pueda compartir con la comunidad Moodle

- Desarrollar e implementar un plugin de instalación para la capa de RSA para libre distribución.

- Desarrollar e implementar un nuevo formato de temas y semanas combinado con red social.

2.11. Metodología de investigación

24 2.12. Metodología de desarrollo

La metodología de desarrollo a llevar cabo para el desarrollo del presente proyecto será la Programación Extrema (XP) (Arboleda Jimenez, 2005), se la ha seleccionado, debido a que es una metodología que nos permite un desarrollo ágil, además al tratarse de un proyecto pequeño, no requiere una rigurosa documentación ni tampoco un estricto control de cambios, además esta metodología favorece situaciones de colaboración e intervención constante de los involucrados para asegurar, cumplir e incluso mejorar sus expectativas con entregas rápidas.

2.12.1.

Este tipo de metodologías como la XP, el principio fundalmental es el construir un producto software que funcione, antes que escribir en si documentación exhaustiva. Permitiendo de esta forma, capacidad de respuesta inmediata ante un cambio, ya que es más importante hacer efectivo el cambio que documentar un seguimiento estricto de un plan de cambios.

En este tipo de metodologías, los individuos y las interacciones entre ellos son más importantes que las herramientas y los procesos empleados, donde además la colaboración con el cliente juega un papel muy importante y esta debe prevalecer sobre la negociación de contratos (Figueroa, Solis, & Cabrera, 2008).

25 2.13. Ventajas de la Solución

Una vez desarrollado el proyecto, las ventajas que se podrán obtener serán las siguientes:

- Se formará una red central donde convergerán, todos los sitios sociales tipo GLESONE.

- Se estableceran redes sociales con usuarios de diferentes redes indistintamente del lugar donde se encuentren.

- Sitios Moodle que posean características similares como versión, sobre la que fue desarrolla GLESONE, podrán comunicarse entre sí e intercambiar de manera automática recursos y usuarios.

- Se presentaran los cursos impartidos dentro de la red GLESONE, en un esquema diferente tipo red social.

- Al contar con una capa de red social claramente identificada, esta podrá ser compartida con la comunidad Moodle, pudiendo ser está adaptada de acuerdo a las necesidades de cada institución.

26

3.

DESARROLLO DE LA SOLUCIÓN SIGUIENDO LA METODOLOGÍA XP

En los últimos años el número de instituciones que tienen como fin la educación y que confían en Moodle como su plataforma de enseñanza-aprendizaje ha aumentado de manera significativa. Es por ello que se ha elegido Moodle para cumplir con este propósito de seguir en la mejora continua del proceso de enseñanza-aprendizaje y se ha implementado una nueva capa de red social y se le ha denominado GLESONE, manteniendo los principios pedagógicos de Moodle.

En este capítulo se hace efectivo el desarrollo e implementación de cada uno de los componentes identificados en la propuesta de la solución, así como de su integración con el sitio GLESONE, desarrollado sobre la plataforma Moodle. Todo el desarrollo de cada uno de los componentes se basa, en las fases propuestas por la metodología XP, la misma que presenta ciertos elementos y características que nos ayudarán en el proceso de desarrollo.

En la primera fase de la metodología se presenta todos los pasos a seguir para la especificación de los requisitos de software necesarios para la implementación de los componentes y para realizar el diseño. Seguidamente se define un plan de pruebas que ayudará a verificar el funcionamiento

27 3.2. Programación Extrema (XP)

Tras la elección de la metodología a llevar a cabo, a lo largo del desarrollo del proyecto, y una vez elegido este, se procede a identificar las fases que conforman la metodología XP, en un ejemplo de desarrollo de software, utilizando la metodología XP, publicado por (Ruiz & Vergara, 2004), se afirma que son tres las fases a seguir durante todo el proceso de desarrollo, ya que este considera que la fase de planificación y de desarrollo pueden ser abarcadas en una sola fase llamada Planeación; pero para este propósito serán abordadas las cuatro fases por separado, estas se detallan a continuación.

3.3. FASE I: Planificación

En esta fase, se empieza por establecer un diálogo continuo con el director del proyecto, Ing. Juan Carlos Torres, y con todos aquellos que de forma directa o indirecta también se encuentran ligados a este, por supuesto siguiendo ciertas reglas con el fin de que todos se sientan realmente partícipes activos de las decisiones tomadas durante el ciclo de vida del proyecto.

La planificación como tal se realiza por etapas, definiendo en estas diferentes iteraciones, planteando entregables por cada nueva versión del producto. (Letelier & Penadés, 2003), en base a su experiencia afirman que: “es aconsejable hacer efectivas muchas entregas y tan frecuentes como sea posible, de tal forma que cuando ocurra un

error este sea detectado lo más antes posible y en etapas tempranas”.

3.3.1.

Las historias de usuario, ayudan a especificar los requisitos del sistema, se puede decir que tienen el mismo propósito que los casos de uso en RUP según (Joscowicz, 2008).

28

desarrollador concreta y detalla lo que tiene que hacer para cumplir con cada una de las historias de usuario.

Analizando los requerimientos en la sección anterior para la implementación de los complementos que posteriormente serán integrados a GLESONE, se ha recopilado las historias de usuario evaluando el tiempo de duración de cada una para definir los entregables.

Tabla 3-1: Modelo propuesto para una historia de usuario (Canos, Leiter & Penadés, 2005)

En esta fase se definen algunas historias de usuario, para el sistema como la que se muestra en la Tabla 3-1, esto para empezar, pero posteriormente, estas pueden cambiar a lo largo del desarrollo del proyecto a medida que cambian los requisitos del sistema. Las historias de usuario se dividen en tareas, pueden tener una o varias por cada iteración y cada tarea presenta un prototipo según la función que esté desempeñando.

3.3.2.

29

3.3.3.

El objetivo de establecer un plan de pruebas, es validar que el desarrollo del proyecto, cumpla con los requisitos planteados. En el plan de pruebas se hace una descripción de las pruebas de software que se deben realizar para verificar el correcto funcionamiento de la implementación desarrollada (ANEXO B PLAN DE PRUEBAS INICIAL).

3.4. FASE II: DESARROLLO

En esta fase, la metodología XP sugiere que, hay que conseguir diseños simples y sencillos. Además se debe procurar hacer todo lo menos complicado posible, para conseguir un diseño fácilmente entendible e implementable que a la larga costará menos tiempo y esfuerzo desarrollar.

3.4.1.

Estas tarjetas se dividen en tres secciones, que contienen: la información del nombre de la clase, sus responsabilidades y sus colaboradores. En la siguiente Tabla 3-2, se muestra cómo se distribuye esta información.

Tabla 3-2: Modelo de tarjeta CRC (Reynoso Billy)

(Rubin, 1998), afirma que, “las tarjetas CRC son una técnica de modelado orientado a objetos que permite identificar las clases participantes”, cada una

compuesta por, el nombre de la clase y sus respectivas responsabilidades

30

que ayudan a que cada acción de las responsabilidades se puedan ejecutar); tal como se muestra en la Tabla 3-2.

Con la ayuda de las CRC se pueden identificar de mejor manera las clases que intervienen en el desarrollo del componente API y formato RSA (ANEXO C TARJETAS CRC (CLASE RESPONSABILIDAD COLABORADOR)).

3.4.2.

El principal objetivo al momento de definir una arquitectura es que, esta sea capaz de conservar las características propias de la plataforma Moodle, así mismo su funcionamiento también deberá ser modular de manera que cada uno de los componentes desarrollados mantenga su propio funcionamiento y de esta manera pueda ser compartido con la comunidad Moodle.

Figura 3-1: Propuesta de solución

3.4.3.

31

si se tratasen de usuarios nativos, así mismo a través de la API los usuarios de redes externas podrán estar al tanto de las constantes actividades que son llevadas a cabo dentro de la red central. Por medio de la API un cliente externo, puede hacer uso de los recursos almacenados y de los datos en general.

Figura 3-2: Componentes de la Arquitectura de la Red Global

3.4.3.1.

Para conservar el mismo esquema de presentación de página de Moodle, los componentes que requieren el diseño de interfaz, serán escritas en lenguaje HTML y PHP3_.

3.4.3.2.

Básicamente todas las páginas web que conforman los componentes y que requieren desarrollo, como la API y el nuevo formato de temas/semanas RSA, serán desarrolladas en PHP conjuntamente con lenguaje Java Script.

3_{PHP, lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web}

32

3.4.3.2.1. API para la Red Social Central

3.4.3.2.1.1. Requisitos

Antes de definir la arquitectura y garantizar la interoperabilidad de la capa de interconexión, es necesario tener en cuenta algunos requisitos (Castro, Ferran, & Piguillem, 2008).

La nueva capa debe y tiene que ser asequible desde cualquier sistema de conexión, tanto actual como futura. La estructura de la API no debe ser fija sino cambiante esto para que se adapte a futuras versiones.

Las funciones que conforman la API deben ser extensibles para que en el futuro se puedan definir más y a medida. Los servicios deben adaptarse al sistema de privilegios de Moodle para garantizar la seguridad.

Pese a que el punto de acceso a la API será único y otorgará acceso a todas las partes sistema donde se tengan privilegios, debe existir un medio para especificar qué partes de la API son esenciales para las aplicaciones clientes. Así, será posible optimizar las conexiones incluyendo sólo aquellas funcionalidades que se necesiten.

3.4.3.2.1.2. Componentes de la API

La arquitectura está pensada para que los conectores se usen independientemente de las funciones de la API que sean requeridas (Alier, Casany, & Casado, Moodle DF Webservices, 2008).

33

• Conector (Connect): Este primer elemento es el encargado de establecer la primera conexión con la red central y proporciona herramientas para autenticarse en el sistema (login, logout) y especificar qué servicios de la API se necesitan. En el caso de conexiones remotas como SOAP, la dirección de “connect” será la entrada pública al sistema que nos proporcionará una sesión para usar la API.

• Entrada/Salida (InOut): Este en cambio se encarga de ofrecer al cliente la API unificada con los servicios requeridos y filtrar según los privilegios del usuario autenticado. El acceso a este componente requiere que el usuario esté autenticado y, por tanto, en el caso de las conexiones remotas será necesario usar el componente “connect” antes.

Como es de suponer, el hecho de pasar por “connect” para conseguir una sesión temporal válida no se aplica en el caso del conector director PHP, donde la propia sesión de Moodle permanente en el navegador web ya es suficiente.

Las librerías que contienen los servicios de la API deben definirse de forma que a los conectores les sea posible ofrecerlas a los clientes. Por éste motivo es necesario que cada librería disponga de una función especial, llamada de forma genérica función “info” (información), que sirva de índice para general una definición de operaciones y estructuras (el WSDL en el caso de SOAP y una estructura de datos en el de PHP).

34

Figura 3-3: Separación de los servicios en 3 capas (Alier, A proposal of interoperability architecture for Moodle, 2008)

• Service Layer (Capa de servicios): Son aquellas librerías que conforman la API. Todas ellas disponen de su propia función “info”. Las librerías pueden estar agrupadas en paquetes de servicios que pueden ampliarse.

Integration Layer (Capa de integración): esta capa, representa la inclusión única de la API. Se divide sólo en dos partes:

• Una para las funciones de login, logout y petición de servicio.

• Otra que unifica los servicios requeridos para que los conectores puedan ofrecerlos.

También es el responsable de unir todos los índices de funciones y estructuras que les devuelven los servicios (con las funciones “info”) y combinarlos en una macro-estructura

35

sistema. Cada conector es capaz de interpretar la macro-estructura que le devuelve la capa de integración y ofrecerla al cliente.

3.4.3.3.

La base de datos a utilizar es la de GLESONE que está desarrollado sobre la plataforma Moodle, conjuntamente relacionada con las tablas del esquema social y la tabla utilizada para el manejo de sesiones para el consumo de la API.

3.4.4.

36

Figura 3-4: Diagrama de clases

3.4.5.

A continuación la Figura 3-5 y la Figura 3-6, describen el proceso que se tuvo que seguir para dar solución a la problemática planteada anteriormente.

37

Figura 3-6: Diagramas de secuencia establecimiento de curso

3.4.6.

Una vez que se ha identificado y definido la arquitectura de la solución, se procede con el diseño del modelo de datos en el que se almacenará la información del manejo de las sesiones para el consumo de la API, y la inserción de los post en el nuevo esquema de temas/semanas con red social.

Seguidamente se realiza una definición de la información que será registrada en el modelo de datos y de la relación entre las entidades que conforman el modelo. Se describe la relación que tienen las entidades de la API con las de Moodle. Se presenta el modelo de datos desarrollado donde se pueden observar las entidades que lo conforman para finalmente hacer una descripción detallada de las mismas con cada uno sus atributos.

3.4.6.1.

En el modelo de datos se definen las entidades donde se guardan las sesiones de usuarios que consumen la API, así como también las que intervienen para que todo el proceso funcione de manera óptima como las tablas del esquema de red social.

38

Figura 3-7: Modelo de datos del proyecto4

En la Figura 3-7, se muestra el modelo de datos con todas las entidades que intervienen para el cumplimiento de este objetivo. Las entidades de color amarillo son las entidades de propias de la plataforma Moodle, las de color gris son las que fueron creadas propiamente para el funcionamiento del esquema social, y la tabla de color celeste es la que guarda las diferentes sesiones para el consumo de la API. La utilización de diferentes colores tiene como finalidad, que se pueda comprender de mejor manera cómo interactúan estas entre sí.

4_{El modelo de datos representa, todas la tablas que intervinieron en el proceso de desarrollo del}

39

3.4.6.2.

A continuación se realiza una descripción general de cada una de las tablas del modelo de datos, para visualizar de manera completa la estructura de una de las tablas del modelo de datos ver (ANEXO D ESTRUCTURA DEL MODELO DE DATOS)

3.4.6.2.1. Tabla para el manejo de sesiones de la API

mdl_webservices_sessions

En esta tabla se almacena toda la información relacionada con la sesión del cliente, como el id de usuario, id de sesión, clave de sesión, inicio y fin de sesión así como la dirección IP de dónde provino la sesión.

3.4.6.2.2. Tablas de la red social

mdl_rsa_participantes_curso

Esta tabla contiene toda la información relaciona con los usuarios que participan dentro de un curso, como su id de usuario, id de curso en el que es participante, id de profesor y el estado del mismo dentro del curso (bloqueado/activo).

mdl_rsa_actividad

Esta tabla almacena información relaciona con la actividad que cada usuario realiza es decir si este posteo, comento, si le gusto o no el comentario de alguien.

mdl_rsa_invitaciones