UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
La Universidad Católica de Loja
ESCUELA CIENCIAS DE LA COMPUTACIÓN
MODALIDAD PRESENCIAL
Desarrollo y adaptación de una capa de usuario final basada en web services para las versiones de moodle 1.9.x y 2.0.x
Autor:
Chamba Jiménez Esteban Yomairo
Directores:
Torres Días Juan Carlos
Abad Espinoza Marco Patricio
LOJA ECUADOR
2011
II
CERTIFICACIÓN
Ing. Torres Díaz Juan Carlos
DIRECTOR DE TESIS
CERTIFICA:
Haber dirigido y supervisado el desarrollo del presente proyecto de tesis previo a la obtención
del título de INGENIERÍA EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN, y una vez que éste
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, 05 de Diciembre del 2011
F
III
CERTIFICACIÓN
Ing. Abad Espinoza Marco Patricio
CO-DIRECTOR DE TESIS
CERTIFICA:
Haber dirigido y supervisado el desarrollo del presente proyecto de tesis previo a la obtención
del título de INGENIERÍA EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN, y una vez que éste
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, 05 de Diciembre del 2011
F
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.
F
Chamba Jiménez Esteban Yomairo
V
CESIÓN DE DERECHOS
Yo, Esteban Yomairo Chamba Jiménez, 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 declaro 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 F
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,
F
VI
AGRADECIMIENTO
Agradezco a todas las personas que estuvieron cerca brindándome su apoyo en la realización de este proyecto que ha enriquecido mis conocimientos. De manera especial a los ingenieros Juan Carlos Torres, y Patricio Abad, quienes con su experiencia y conocimiento, supieron ser una excelente guía para el éxito del proyecto.
Agradezco a mi familia por motivarme y darme aliento para seguir adelante, sin importar el esfuerzo que se tenga que realizar con el fin de alcanzar una nueva meta en la vida.
VII
DEDICATORIA
Esta nueva meta alcanzada la dedico especialmente a Dios, que nunca me ha dejado caminar solo, y sin su ayuda no hubiera sido posible alcanzarla.
A mis padres que ha sido siempre un ejemplo a seguir y por todo su apoyo, a mis hermanas, y a toda mi familia por su apoyo incondicional.
VIII
RESUMEN
Las plataformas de aprendizaje (e-learning) han contribuido con el mejoramiento de los procesos de enseñanza aprendizaje gracias al uso de internet. Una de estas plataformas de aprendizaje, que posee muchos usuarios a nivel mundial es Moodle, sin embargo, aunque cumple con los principios básicos para el proceso de enseñanza-aprendizaje en línea, deja mucho que desear en cuanto a las nuevas tendencias en la web, como es el tema de la web 2.0 y de las redes sociales.
IX
ÍNDICE
Tabla de contenido
ÍNDICE ... IX
Tabla de contenido ... IX
ÍNDICE DE ILUSTRACIONES ... XI
1 CAPÍTULO I: DEFINICIÓN DEL PROBLEMA Y ANÁLISIS INICIAL ... 1
1.1 INTRODUCCIÓN ... 2
1.1.1 Naturaleza Y Antecedentes ... 2
1.1.2 Diagnóstico ... 2
1.2 OBJETIVOS ... 3
1.2.1 Objetivo General ... 3
1.2.2 Objetivos Específicos ... 3
1.3 DESCRIPCIÓN DEL PROYECTO ... 4
1.4 ESTADO ACTUAL ... 5
1.5 PROPUESTA DE SOLUCIÓN ... 7
1.5.1 Servicios Web ... 7
1.5.2 Posibles Soluciones Para Implementación de Servicios Web en Moodle 1.9.x .... 8
1.5.3 Opción Seleccionada Para Implementación de Servicios Web en Moodle 1.9.x .. 9
1.5.4 Posibles Soluciones Para Implementación de Web Services en Moodle 2.0.x ... 11
1.5.5 Opción Seleccionada Para Implementación de Web Services en Moodle 2.0.x . 12 1.5.6 Gestión de Widgets ... 12
1.5.7 Desarrollo de Widgets ... 13
1.5.8 Herramienta Elegida Para Implementación de la Capa de Widgets ... 15
1.5.9 Capa de Widgets en Moodle ... 16
1.5.10 Integración de JPolite y Moodle ... 16
1.5.11 Aproximación visual de la capa de widgets ... 17
2 CAPÍTULO II: DESARROLLO DE LA SOLUCIÓN ... 18
2.1 METODOLOGÍA DE DESARROLLO ... 19
2.1.1 Definición de Metodología de Desarrollo (E. Leiva, 2006) ... 19
2.1.2 Programación Extrema (XP) (Pressman, 2006) ... 19
2.2 PLANIFICACIÓN ... 23
2.2.1 Historias de Usuario ... 23
2.2.2 Plan de Entregas e Iteraciones ... 24
X
2.2.4 Arquitectura ... 25
2.3 DISEÑO ... 31
2.3.1 Metáfora del Sistema ... 31
2.3.2 Modelo de Datos ... 31
2.3.3 Prototipos ... 37
2.3.4 Diagrama de Clases ... 45
2.4 DESARROLLO ... 65
2.4.1 Disponibilidad del cliente ... 65
2.4.2 Pruebas de unidad ... 65
2.4.3 Integración ... 65
2.5 PRUEBAS ... 67
2.5.1 Pruebas unitarias ... 67
2.5.2 Pruebas de aceptación o funcionales ... 67
3 CAPÍTULO III: PLAN DE PRUEBAS ... 68
3.1 Propósito ... 69
3.2 Alcance ... 69
3.2.1 Pruebas unitarias ... 69
3.2.2 Pruebas de aceptación o funcionales ... 69
3.3 Estrategia ... 70
3.4 Recursos ... 71
3.5 Cronograma ... 72
3.6 Resultados ... 72
3.7 Manual de Instalación del Sistema ... 73
3.8 Manual de Usuario del Sistema ... 73
4 DISCUSIÓN ... 74
5 CONCLUSIONES Y RECOMENDACIONES ... 77
5.1 Conclusiones y Recomendaciones... 78
5.1.1 Conclusiones ... 78
5.1.2 Recomendaciones ... 80
BIBLIOGRAFÍA ... 82
XI
ÍNDICE DE ILUSTRACIONES
Ilustración 1 Apariencia Tradicional de Moodle ... 5
Ilustración 2 Apariencia de GlesOne sobre Moodle ... 5
Ilustración 3 Aproximación de Apariencia de Widgets ... 17
Ilustración 4 Ciclo del Proyecto con XP (Fernandez, 2002) ... 20
Ilustración 5 Fases Metodología XP (Fernandez, 2002) ... 21
Ilustración 6 Fases XP (Adaptada al entorno del Proyecto) ... 22
Ilustración 7 Arquitectura General del Sistema ... 25
Ilustración 8 Arquitectura RSA y Moodle (Jaramillo E, 2010) ... 27
Ilustración 9 Arquitectura Propuesta (Nuevas capas sobre Moodle) ... 28
Ilustración 10 Relación entre capas ... 29
Ilustración 11 Modelo de Datos (Funcionalidades nativas de Moodle) ... 33
Ilustración 12 Modelo de datos (Red Social) (Jaramillo E, 2010) ... 36
Ilustración 13 Prototipo de Presentación Inicial ... 37
Ilustración 14 Prototipo de Presentación de Un Curso ... 39
Ilustración 15 Prototipo de Gestión de Amistades de la red social ... 42
1
1
CAPÍTULO I: DEFINICIÓN
2
1.1
INTRODUCCIÓN
1.1.1 Naturaleza Y Antecedentes
Desde la aparición de la Web 2.0, la cual ha dado un giro total al esquema tradicional de presentación de recursos en internet, las necesidades de los sistemas han cambiado mucho, al igual que han cambiado también las necesidades y exigencias de los usuarios de sistemas disponibles en internet, esto obliga a que sistemas anteriores se actualicen al nuevo esquema que plantea la Web 2.0 y a los nuevos sistemas a desarrollarse bajo estándares de la web moderna, esto con la finalidad de brindar un mejor servicio al usuario final y de tener una mejor aceptación de parte de los mismos.
Entre las propuestas de la Web 2.0 tenemos: permitir a las aplicaciones tener la capacidad de interactuar con otros sistemas diferentes, y tener ambientes personalizables dependiendo de las necesidades del usuario.
En los estudiantes de la UTPL el conocimiento sobre Web 2.0, y el uso de sistemas que basados en la web moderna y colaborativa es bastante amplio, sin embargo el entorno virtual de aprendizaje (basado en la plataforma e-learning Moodle) usado por los estudiantes no presenta las características suficientes para una perfecta compatibilidad con la web moderna.
Se considera sumamente necesario innovar, y actualizar el sistema para que cumpla con los requerimientos de la web moderna y así brindar un mejor servicio a los usuarios, presentando un ambiente más colaborativo y personalizable para aquellos quienes hagan uso de la plataforma Moodle.
1.1.2 Diagnóstico
Como respuesta a la necesidad de innovar y partir hacia un ambiente de web moderna, se ha considerado proveer a Moodle la capacidad de compartir sus recursos y contenidos con sistemas externos, razón por la que se incluye el concepto de Web Services; y para brindar a los usuarios una mejor experiencia de usuario a través de una capa de interfaces configurables, personalizables y dinámicas, se incluye en concepto de widgets.
3
1.2
OBJETIVOS
1.2.1 Objetivo General
Desarrollar y adaptar una capa de usuario final basada en Web Services, y desarrollar una capa de red social integrada con una capa visual de presentación dinámica, para las versiones de Moodle 1.9.x y 2.0.x.
1.2.2 Objetivos Específicos
Implementar una capa de Web Services sobre el núcleo de Moodle para que sus datos sean extraídos a través de éstos servicios.
Consumir los recursos de Moodle haciendo uso de la capa de Web Services.
Proveer a Moodle de una capa visual basada en widgets para brindar una presentación dinámica a los usuarios finales.
Proveer una capa de red social a las versiones 1.9x y 2.0x de Moodle, la cual funcione conjuntamente con una interfaz basada en widgets, y que brinde el servicio para una red social personal del usuario, y para una red social de cada curso de ese usuario.
4
1.3
DESCRIPCIÓN DEL PROYECTO
El presente proyecto nace de la necesidad de proveer a los usuarios del entorno virtual de aprendizaje de la UTPL nuevas características, de manera que cumpla con los requerimientos de la web moderna 2.0.
Este proyecto será implementado sobre las versiones estables de Moodle 1.9.x y Moodle 2.0.x, además en la versión 1.9.x será integrado con una versión que contiene una capa RSA (Red Social de Aprendizaje) sin uso de servicios web, del proyecto denominado GlesOne1 desarrollado en la UTPL (Universidad Técnica Particular de Loja).
Se requiere que el sistema tenga la capacidad de interactuar con otros sistemas poniendo a disponibilidad de sistemas externos sus contenidos y recursos por medio de Web Services, de esa manera se pueden desarrollar sistemas que hagan uso de los servicios web para presentar, procesar, agregar y modificar información de los usuarios de la plataforma Moodle y de sus cursos. Además se requiere brindar una presentación dinámica al usuario final, para lo cual se debe proveer una interfaz dinámica y personalizable a los usuarios.
La aplicación de la tecnología Ajax es lo que se requiere para brindar una mejor experiencia de usuario, Ajax es considerada la mejor opción debido a que está basada en estándares web. Haciendo uso de Ajax se construirá una capa visual para mejorar la presentación visual al usuario final por medio de la implementación de widgets configurables dentro del sistema tradicional de la plataforma Moodle.
Otro aspecto importante del proyecto, es el desarrollo e implementación de una capa de red social de aprendizaje sobre la plataforma Moodle. La misma que debe consumir recursos proveídos por los servicios web de Moodle que serán desarrollados e implementados en este mismo proyecto.
Para el desarrollo de las nuevas funcionalidades en Moodle, se ha elegido la metodología de desarrollo de software XP (Extreme Programming).
Los detalles de cada uno de los objetivos planteados en este proyecto se revisan en cada reunión con los encargados de revisión del proyecto en la Unidad de Virtualización de la UTPL.
5
1.4
ESTADO ACTUAL
Con lo que actualmente se cuenta para dar inicio al proyecto, es con las versiones necesarias de la plataforma Moodle2 (Moodle 1.9.x y Moodle 2.0.x), éste es el núcleo sobre el cual se agregarán los nuevos servicios.
En la siguiente imagen se muestra la pantalla de una versión estable de Moodle.
Además se cuenta con una versión de Moodle 1.9.x integrada con una capa de red social de aprendizaje (sin uso de servicios web) desarrollada en el proyecto GlesOne en la UTPL.
A continuación en la figura se muestra la pantalla de una versión de Moodle integrada con GlesOne.
2 MOODLE. [en línea]. <http://www.moodle.org/>[Citado en 15 de febrero del 2011]
Ilustración 1 Apariencia Tradicional de Moodle
6 De esta versión de Moodle que integra una capa de red social de aprendizaje, se usará su estructura de datos para la nueva red social de aprendizaje, basada en servicios web.
Como se puede observar en las figuras anteriores el contenido presentado tanto en la versión pura de Moodle como en la integrada con GlesOne está organizado en bloques, no permitiendo de esa manera ningún tipo de personalización por parte del usuario final.
En el caso de la versión Moodle 2.0.x se cuenta con la implementación de Web Services parcialmente funcional ya que a la fecha no es posible interactuar con aplicaciones externas desarrolladas por ejemplo en el lenguaje de programación Java y/o la plataforma de desarrollo .Net. Por defecto dicha opción de Web Services se encuentra desactivada, por lo que es necesario un proceso de activación y configuración.
7
1.5
PROPUESTA DE SOLUCIÓN
Para satisfacer las necesidades actualmente requeridas se propone:
Desarrollar e implementar una capa de servicios web sobre Moodle 1.9.x y Moodle 2.0.x.
Desarrollar e implementar una capa de gestión de widgets sobre Moodle 1.9.x y Moodle 2.0.x .
Desarrollara e implementar una capa de red social que consuma servicios web de moodle sobre Moodle 1.9.x y Moodle 2.0.x.
Implementar sobre Moodle 1.9.x y Moodle 2.0.x una presentación dinámica basada en widgets, donde el usuario tenga la capacidad de agregar y remover widgets con distintas funcionalidades cada uno, incluyendo la presentación de una red social consumida desde una capa de red social sobre Moodle.
Con el propósito de cumplir de la mejor manera con los objetivos propuestos en el proyecto, primeramente se presentan opciones de las tecnologías que pueden ser usadas en los casos propuestos para el desarrollo del proyecto, y luego se presenta las opciones elegidas de acuerdo a sus características.
En cuanto a la parte de mejoramiento de experiencia de usuario además se presenta una ilustración aproximada sobre cómo quedaría la capa de widgets implementada en el proyecto.
1.5.1 Servicios Web
Los Servicios Web (Web Services) son aplicaciones desarrolladas para brindar servicio a otras aplicaciones a través de la red. El concepto presentado por la W3C es el siguiente
URI uyas interfaces públicas y enlaces se definen y describen usando XML. Su definición puede ser descubierta por otros sistemas de software. Estos sistema pueden interactuar con servicio web de la forma prescrita por su definición, usando mensajes basados en XML a través de
3.
Un concepto importante que se debe conocer en cuanto a Web Services es el de XML, ya que es usado como un estándar para definir e implementar servicios web.
8 XML, es el fundamento básico sobre el cual se construyen los servicios web, provee un lenguaje para definición y procesamiento de datos. XML representa una familia de especificaciones relacionadas publicadas y mantenidas por el World Wide Web Consortium (W3C) y otros.
XML fue diseñado para superar las limitaciones de HTML, especialmente para un mejor soporte del manejo y creación de contenido dinámico. HTML está bien para trabajar con contenido estático, pero la web evoluciona hacia una plataforma de software activo, en la cual los datos tienen un significado asociado, y el contenido necesita ser generado y consumido dinámicamente. Usando XML se puede definir cualquier número de elementos que se asocien los datos con su significado, así que se describe los datos y qué hacen estos, usando uno o más elementos creados con un propósito (NewComer, 2002).
1.5.2 Posibles Soluciones Para Implementación de Servicios Web en Moodle 1.9.x
Para la implementación de un API que funcione como servicio web para la plataforma Moodle 1.9.x, es posible considerar varias posibilidades, estas son:
a) Usar el servicio XML-RPC
b) Usar OKTech (Open Knowledge Technologies) Web Services
c) WSPP (plugin de Web Services que hace uso de SOAP, y está basado en OKTech)
d) Crear desde cero un nuevo plugin de Web Service que se integre con Moodle.
XML-RPC Web Service API in Moodle.- Permite a un servidor o cliente externo conectarse con moodle y hacer solicitudes llamando a sus funciones, a la vez que obtiene datos de regreso desde el servidor moodle4.
Definición formal de XML-RPC (XML-Remote Procedure Calling).- Es una especificación, y una serie de implementaciones que permiten hacer llamadas a procedimientos a través de internet al software que se ejecuta en diferentes sistemas operativos y en entornos diferentes.
Un mensaje XML-RPC es una petición HTTP-POST, el cuerpo de esta petición es en XML. Un procedimiento se ejecuta sobre el servidor y devuelve el valor en formato XML5.
4 MOODLE. [En
9
OKTech (Open Knowledge Technologies) in Moodle.- Es un Web Service basado en SOAP, al igual que con el API XML-RPC, OKTech sirve para establecer una comunicación y compartir datos entre un servidor o cliente externo y el servidor de moodle6.
Definición formal de SOAP (Simple Object Access Protocol).- SOAP es un protocolo ligero para intercambio de información en sistemas descentralizados, de ambientes distribuidos.
SOAP es un protocolo basado en XML que consiste de tres partes:
SOAP envelope, es una capa que define un framework para describir lo que hay en el mensaje y cómo procesar esto, este mensaje es un documento XML.
SOAP encoding rules, un conjunto de reglas de codificación para expresar instancias de tipos de datos definidos por la aplicación.
SOAP RPC representation, es una convención para representar llamadas y respuestas a procedimientos remotos.
SOAP puede ser usado potencialmente en combinación con una variedad de otros protocolos, como HTTP o SMTP7.
WSPP (Patrick, 2007).- Existe una versión avanzada por así decirlo de OKTech, es un plugin con la implementación del Web Services sobre Moodle usando SOAP, el nombre
.
Crear desde cero un Nuevo Plugin.- Otra posibilidad es desarrollar un plugin desde cero, haciendo uso de alguna tecnología de Web services, e integrarlo a la plataforma Moodle.
1.5.3 Opción Seleccionada Para Implementación de Servicios Web en Moodle 1.9.x
Considerando las características que presentan cada una de las cuatro posibilidades identificadas, se ha seleccionado la opción que más se adapta a las necesidades del proyecto, ésta es el plugin WSPP (Patrick, 2007), sobre el cual se realizarán los ajustes,
5 [En línea].<http://www.xmlrpc.com/>[citado en 21 de febrero del 2011]
10 modificaciones, e implementación de nuevas funciones, de acuerdo a las necesidades propias del proyecto.
Dicho plugin incorpora las ventajas del uso de SOAP como servicio web, y el nivel de desarrollo es adecuado para iniciar a incorporar las funcionalidades faltantes requeridas en este proyecto.
Este plugin está desarrollado para trabajar bajo las características del protocolo SOAP, y el Web Services Description Lenguaje (WSDL), en español (Lenguaje de Descripción de Servicios Web).
Definición de WSDL.- WSDL está basado en la tecnología XML, define interfaces de servicios web, tipos de datos y mensajes, patrones de interacción, y asignación de protocolos (NewComer, 2002).
Debido a la estandarización de protocolos de comunicación y formatos de mensajes en la web, se hace cada vez más importante ser capaz de describir las comunicaciones de alguna manera estructurada. WSDL aborda esta necesidad mediante la definición de una gramática XML para describir los servicios de la red como colección de variables de comunicación capaces de intercambiar mensajes8.
En el A Anexo1_ClientWSPP.docx , se realiza un test del consumo de los Servicios Web de WSPP, usando el lenguaje de programación PHP.
8 W3C.
[En línea].<http://www.w3.org/TR/wsdl>[citado en 21 de febrero del 2011]
Anexo 1 Página
T C WSPP ... 91
U . 91
P R 93
11
1.5.4 Posibles Soluciones Para Implementación de Web Services en Moodle 2.0.x
En la versión 2.0.x de Moodle, se presentan algunas diferencias con la versión 1.9.x, por esta razón ha sido posible y necesario identificar por separado las opciones para implementación de Web Services en dicha versión, estas son:
a) Implementación nativa de Web Services
b) WSPP (plugin de Web Services que hace uso de SOAP, y está basado en OKTech)
c) Crear desde cero un nuevo plugin de Web Service que se integre con Moodle.
La nueva alternativa que tenemos con respecto a la versión anterior, es usar la implementación nativa de Web Services. A la fecha actual (febrero del 2011) esta funcionalidad está aún en una etapa de desarrollo, por lo que para usar adecuadamente los servicios implementados es necesaria la utilización del Framework
PHP Z W “
usadas desde PHP actualmente.
En el Anexo 2 Anexo2_WSMoodle20.docx , se realiza una descripción completa sobre los servicios web en Moodle 2.0.x, su arquitectura, y el procedimiento para la activación de dichos servicios.
Anexo 2 Página
W M 95
A I 95
R W S 96
A W S ... . 96
12
1.5.5 Opción Seleccionada Para Implementación de Web Services en Moodle 2.0.x
Considerando las características de cada opción disponible para la implementación de Web Services en Moodle 2.0.x, se ha determinado como la más adecuada para el uso en el presente proyecto, a la opción dos: WSPP (Patrick, 2007).
1.5.6 Gestión de Widgets
L os cuales son diseñados para una función
específica y para un rápido acceso a servicios de la Web 2.0 o contenido de internet (Kaar, 2007).
La W3Ci W W W C U
aplicación interactiva, con la única finalidad de mostrar y/o actualizar datos locales, o datos en la web, empaquetados de una forma que permiten una sola descarga e
1.5.6.1 Clasificación de los Widgets
Los widgets según (Burgos, 2009) pueden clasificarse en tres grupos:
Widgets para la Web.- Pueden publicarse en un blog, red social, u otra aplicación web, y permiten compartir información o promocionar contenido.
Widgets de escritorio.- Permiten recibir contenidos en el escritorio del ordenador, gracias a la conexión a internet.
Widgets para móviles.- Muestran tus contenidos favoritos en tu terminar móvil.
13
1.5.7 Desarrollo de Widgets
Los widgets son desarrollados usando estándares de tecnologías web, tales como HTML, CSS, JavaScript, y XML, estas tecnologías son exactamente las mismas usadas en el desarrollo Ajax, de modo que los widgets podrían considerarse como un tipo de aplicaciones Ajax.
Como podemos apreciar, el desarrollo de widgets usa los mismos estándares tradicionales para el desarrollo web, además se basa en la tecnología Ajax para la presentación de contenido dinámico y configurable desde una sola página. Se puede decir que el uso de widgets es una técnica para crear aplicaciones web interactivas.
La aparición de la Web 2.0 ha intensificado el uso de aplicaciones Ajax, y aplicaciones basadas en widgets, es por eso que se han desarrollado una serie de framework para
A
uso de widgets, a los mismos que se los puede usar como frameworks para manejo de widgets basados en Ajax.
1.5.7.1 Herramientas Para el Desarrollo de Widgets
Para la implementación de la capa de widgets se requiere hacer uso de la tecnología Ajax.
Para agilizar el desarrollo web con Ajax, se puede hacer uso de una serie de frameworks, los cuales incluyen opciones para trabajar con widgets, a continuación se presenta una lista de los frameworks más populares disponibles:
Dojo Yahoo UI Prototype Script.aculo.us Mootools jQuery
14 Prototype y Script.aculo.us, se ha creado Portal
Mootools, se ha creado iMoogle jQuery, se ha creado JPolite.
Dojoii, incorpora Dojo's Dijit and DojoX que proveen una completa colección de controles para interfaces de usuarios, dando poder para crear aplicaciones web altamente optimizadas para disponibilidad, usabilidad, internacionalización, accesibilidad, pero sobre todo brinda una increíble experiencia de usuario.
Con Dijit se pueden añadir widgets simples o interactivos, tales como imágenes de Flickr ó un resumen de anuncios en twitter.
Yahoo UIiii, provee clases para el manejo de widgets, sobre las cuales son construidos todos los widgets YUI 3, incorpora una serie de utilidades para los widgets, como: atributos básicos, métodos de representación, mejoramiento progresivo, estructura de marcado, nombres de clases y CSS, Eventos UI predeterminados.
Prototypeiv, es un framework JavaScript que tiene como objetivo facilitar el desarrollo de aplicaciones web dinámicas. Tiene características únicas, y fáciles de usar, basándose en la tecnología Ajax.
Script.aculo.usv, provee librerías javascript fáciles de usar para el desarrollo de interfaces de usuario.
Existe una clase desarrollada con los frameworks Prototype, y Script.aculo.us, conocida
P P C vi
portal web, sus principales funciones son:
add(widget, columnIndex): add a new widget . remove(widget): remove a new widget.
15
Mootoolsvii, es un framework JavaScript compacto, modular y orientado a objetos, diseñado para desarrolladores intermedios y avanzados de javascript.
Además existe un portal desarrollado en Mootools para el manejo de widgets, es open
M viii
iGoogle, y netvibes, usa una estructura json. Véase
JQueryix, es una librería JavaScript rápida y consistente, que simplifica el paso de documentos HTML, manejo de eventos, animaciones, e interacciones Ajax para un rápido desarrollo Web.
Haciendo uso de la librería JQuery, ha sido desarrollado un completo, e interesante Framework para el manejo de Widgets, este framework ha sido llamado JPolitex, es de libre distribución, y opensource, el mismo que gracias a sus características ha sido elegido para la implementación de una Capa de Widgets para Moodle.
1.5.8 Herramienta Elegida Para Implementación de la Capa de Widgets
Tomando en cuenta el avanzado nivel de desarrollo del framework JPolite como herramienta para manejo de widgets, ha sido considerado como la mejor opción a usar para la implementación de la capa de widgets en este proyecto.
En el Anexo 3 Anexo2_Jpolite.docx se da una completa descripción de dicho framework (sus características
16
Anexo 3 Página
JPolite(jQuery Portal Lite) .. 104
Características . 104
Tecnologías Usadas 104
A 104 - 106
1.5.9 Capa de Widgets en Moodle
En el caso de este proyecto se ha considerado el uso de widgets para la Web ya que permitirán compartir información y realizar actividades de diversos módulos del sistema web e-learning Moodle en varias pantallas individuales dentro del navegador, las mismas que pueden ser agrupados por el usuario de acuerdo a su conveniencia.
Para implementar una capa de widgets en Moodle, se ha considerado conveniente hacer uso del framework JPolite, éste ayuda a gestionar la presentación de distintos módulos por medio de widgets.
Se ha seleccionado el mencionado framework para presentar ciertos módulos PHP de moodle al usuario por medio de pantallas movibles dentro de la ventana del navegador, con lo cual la interfaz presentada al usuario final es mucho más configurable y dinámica.
1.5.10 Integración de JPolite y Moodle
Para integrar JPolite con el núcleo de moodle, es necesario incorporar el framework dentro de la carpeta de instalación de moodle.
C R“A ha
agregado el framework JPolite, y luego a toda la carpeta se la ha ubicado dentro de la carpeta de instalación de Moodle.
17
1.5.10.1Características de los widgets
Cada widget tiene un título.
Se puede agregar y eliminar cuando el usuario lo crea oportuno.
Capacidad de minimizar todo el contenido presentado dentro del widget. Es reubicable, o sea el usuario lo puede ubicar en el lugar que crea más adecuado dentro de la página.
Se puede maximizar para observar su contenido en la pantalla completa. Se puede refrescar/actualizar su contenido.
Se puede minimizar o maximizar todos los widgets a la vez.
1.5.11 Aproximación visual de la capa de widgets
En la siguiente figura se presenta una aproximación de la vista que tendrá Moodle luego de la implementación de una capa de widgets.
En la figura se presenta una interfaz dinámica, en la cual el usuario final tiene la capacidad de organizar la presentación de la página de presentación. Distintos tipos de recursos se presentan en pantallas pequeñas movibles dentro de la ventana principal del navegador.
18
2
CAPÍTULO II:
19
2.1
METODOLOGÍA DE DESARROLLO
Tal como se propuso en el anteproyecto, se ha seleccionado XP (Extreme Programming) como la metodología de desarrollo de software en este proyecto, esto considerando las ventajas de dicha metodología en relación al tiempo requerido para conclusión del proyecto, y a los requerimientos cambiantes.
2.1.1 Definición de Metodología de Desarrollo (E. Leiva, 2006)
Una metodología de desarrollo es una recopilación de técnicas y procedimientos estructurados en fases para la producción de productos software de manera eficaz, y englobando todo el ciclo de vida del mismo.
- Indica qué hacer, cuándo y quién debe hacerlo. - Determina las etapas y controles a aplicar.
2.1.2 Programación Extrema (XP) (Pressman, 2006)
La Programación Extrema utiliza un enfoque orientado a objetos como su paradigma de desarrollo preferido. La Programación Extrema abarca un conjunto de reglas y prácticas que ocurren en el contexto de cuatro actividades del marco de trabajo: planeación, diseño, codificación y pruebas.
XP es uno de los populares procesos ágiles. Ha demostrado ser exitoso en muchas compañías e industrias de diferentes tamaños alrededor del mundo.
El éxito de XP hace hincapié en la satisfacción del cliente. En lugar de entregar todo el proyecto completo en una fecha lejana en el futuro, en este proceso se entrega el software conforme la necesidad.9
Para lograr esto, XP plantea un ciclo de desarrollo representado en la siguiente figura:
9
20
En este ciclo representado gráficamente, encontramos:
- Historias de usuario.- Son equivalentes a los requisitos del sistema.
- Architectural spike.- Es una metáfora del sistema, o sea una descripción del proyecto que se logre comprender sin mayores explicaciones.
- Spike.- Representa las estimaciones de tiempo de desarrollo, hechas por el mismo desarrollador.
- Plan de entregas.- Es una clasificación de las historias de usuario, indicando cuales serán desarrolladas, y hasta qué fecha.
- Iteración.- Es cada nuevo conjunto de historias de usuario que se desarrolla, o todas aquellas funcionalidades nuevas.
- Pruebas de aceptación.- Pruebas que validan que las funcionalidades implementadas sean las correctas.
- Pequeñas entregas.- Presentación del avance de cada iteración al usuario.
Para una correcta implementación de la metodología XP en el desarrollo de un proyecto de software, es necesario identificar y ejecutar las tareas en cada una de las cuatro fases propuestas por la metodología ágil. Estas fases son:
1. Planificación. 2. Diseño. 3. Desarrollo. 4. Pruebas.
21 En la siguiente figura se muestran cada una de estas fases, y se desglosan con las respectivas actividades de cada una.
Para el desarrollo del presente proyecto se toma como base las fases propuestas por la metodología XP, sin embargo, considerando que el desarrollo del proyecto es dentro de un ambiente académico y con todo tipo de recursos limitados, no se lleva a pie de letra todas las actividades y teorías propuestas en cada una de estas fases. Así mismo se considera necesario incrementar algunas actividades que se consideran oportunas.
En la siguiente gráfica se ilustra la metodología de desarrollo XP adaptada al entorno del proyecto con todas las fases que se seguirá en el desarrollo del mismo.
El proceso de desarrollo se basa en cada una de éstas fases, que se las verá con detalle en las secciones siguientes.
22 El presente proyecto está basado en este modelo adaptado de las fases de la metodología XP, cada una de estas fases se detallan en las siguientes secciones, junto con la implementación de cada fase en el proyecto.
23
2.2
PLANIFICACIÓN
La metodología XP plantea la planificación como un diálogo continuo entre las partes involucradas en el proyecto, incluyendo al cliente, a los programadores y a los coordinadores o gerentes. (Joskowicz, 2008)
2.2.1 Historias de Usuario
E XP L actividad de planeación comienza creando una serie de historias (también llamadas historias de usuario) que describen características y las funcionalidades requeridas para el software que se construirá. Cada historia (similar a los casos de uso) la describe el cliente, y se coloca en una carta índice. El cliente asigna un valor (es decir, una prioridad) a la historia basándose en valores generales del
(Pressman, 2006)
Las historias de usuario en las metodologías ágiles (como lo es XP), son similares a los casos de uso que se utilizan en metodologías no ágiles, la diferencia es que las historias de usuario hacen la documentación más simple, más liviana y más rápida. Las historias de usuario conducen a pruebas de aceptación, en las cuales se verifica que las pruebas se han implementado correctamente.
L una o más pruebas de
aceptación se deben crear para verificar que las historias se han implementado correctamente.
La gran diferencia entre las historias de usuario y la tradicional especificación de requerimientos es el nivel de detalle.
Los desarrolladores estiman en cuánto tiempo la historia se podría implementar.
Las historias de usuario planteadas para el proceso de desarrollo de éste proyecto, se basan en los objetivos que se pretende alcanzar con el mismo.
24 En el Anexo4_Historias_Iniciales.docx, se presentan las historias de usuario obtenidas en para el desarrollo de este proyecto.
2.2.2 Plan de Entregas e Iteraciones
El plan de entregas ( Release Plan ) establece qué historias de usuario serán agrupadas para conformar una entrega, y el orden de las mismas. Este cronograma es el resultado de una reunión entre todos los actores del proyecto (cliente, desarrolladores, gerentes, etc.) XP J
P . El cronograma de entregas se realiza en base a las estimaciones de tiempos de desarrollo realizadas por los desarrolladores. Luego de algunas iteraciones es recomendable realizar nuevamente una reunión con los actores del proyecto para evaluar nuevamente el plan de entregas y ajustarlo si es necesario (Joskowicz, 2008)
El plan de entregas e iteraciones del presente proyecto se presenta en el Anexo 5 Anexo5_Entregas_e_Iteraciones.docx .
Anexo 4 Página
Historias de Usuario I . 108
Historias de Usuario: Compartición W S . 108
Historias de Usuario: Mejoramiento de la presentación al usuario final a
través de una interfaz . 117
Historias de usuario: Desarrollo de una capa de Red Social de
Aprendizaje (RSA) e integración dentro de una interfaz dinámica . 120
H A M .. 126
Anexo 5 Página
P 128
P 128
S I .. 132
T I 136
C I .. 139
Q I . 142
25
2.2.3 Reuniones
El objetivo de las reuniones diarias es mantener la comunicación entre el equipo, y compartir problemas y soluciones.
Durante el desarrollo de este proyecto las reuniones se han llevado a cabo concurrentemente, si bien no han sido diarias como lo recomienda XP, si han sido al menos dos veces por semana, en donde se comunican dificultades, o inquietudes. No se maneja ningún tipo de artefacto para estas reuniones.
2.2.4 Arquitectura
La metodología de desarrollo XP, no incluye una representación de la arquitectura del sistema en la fase de planificación debido a que se basa en la teoría de que va cambiando en cada iteración, sin embargo para el desarrollo de este proyecto se ha considerado conveniente establecer una arquitectura general del sistema, y una arquitectura de las nuevas capas que se implementarán sobre Moodle.
Arquitectura General del Sistema
En la siguiente figura se presenta la arquitectura general del sistema, o sea su estructura global sin hacer distinción entre las nuevas capas, con excepción de la capa de Web Services, la cual cambia la forma tradicional de comunicación:
26 En la arquitectura se pueden distinguir cuatro partes:
Presentación.- Parte de la aplicación con la que interactuará el usuario, se requiere del uso de Javascript y Ajax para presentar una interfaz dinámica y amigable.
Servicios Web.- Servicios que serán consumidos desde el cliente por medio de mensajes XML.
Servidor Web.- Servidor que aloja la aplicación web, en este caso las librerías de moodle, las cuales contienen la lógica de la aplicación y una comunicación para acceso a los datos, como lenguaje de programación se usa PHP.
Servidor de Base de Datos.- En este caso un servidor MySQL, que contiene los datos del sistema.
Más adelante se presentará la arquitectura de la implementación de las nuevas capas sobre Moodle.
Como ya se ha venido especificando en las secciones anteriores, la finalidad de este proyecto es implementar una capa de web services y una capa para presentar una interfaz dinámica al usurario final, la misma se realizará usando widgets sobre la plataforma Moodle, esto con el fin de volver a la plataforma más interactiva, colaborativa, y además brindar una mejor usabilidad.
Además otro requerimiento es agregar una capa con las funcionalidades de una red social, similar a la implementada en GlesOne, la cual no usa Servicios Web, a fin de crear un solo plugin integrando la capa de widgets con la capa RSA haciendo uso de Web Services.
27
Arquitectura Actual de RSA (Sin uso de Web Services)
Antes de presentar la arquitectura que tendría Moodle una vez añadida la capa de web services junto con la capa RSA y capa de widgets, se presentará primero la arquitectura de la capa RSA que se encuentra ya implementada sobre Moodle. Esto es importante, ya que representa parte de la metáfora del sistema.
La arquitectura presentada en la figura anterior es de la implementación de una capa de red social sobre moodle, accediendo directamente a los datos, sin uso de servicios web.
Arquitectura Propuesta (widgets, red social, web services)
En el siguiente esquema se presenta la arquitectura propuesta de implementación de las nuevas capas al núcleo de Moodle, las mismas que comprenden: capa de web services, capa RSA, capa de widgets.
28
Nuevas capas sobre Moodle: El N
representa todo el desarrollo e implementación del proyecto. En el cual se incluye
C C R“A C W “ .
Las nuevas capas implementadas se integran directamente con el núcleo de Moodle, y a través de sus librerías, se accede a la base de datos. La base de datos es una sola, en la cual se hace distinción entre la parte de la base de datos nativa de Moodle (identificada como DB-MOODLE), y la parte de la base de datos de la red social de aprendizaje (Identificada como DDB-RSA), la cual ha sido agregada a Moodle en un proyecto previo a éste, en el proyecto Glesone desarrollado en la UTPL, del cual éste proyecto también forma parte.
Capa de Widgets: Capa que brinda una presentación de interfaz dinámica al usuario final a través de pantallas movibles dentro del navegador, a las cuales el usuario las puede organizar a su conveniencia.
Capa RSA: Capa que implementa funcionalidades para presentar una Red Social de Aprendizaje, tanto personal, como de cada curso.
Capa de Web Services: Capa que brinda un servicio para proveer de un punto de comunicación adicional a la forma tradicional de comunicación de Moodle. Por medio de esta capa es posible comunicarse con las librerías de Moodle, ya sea desde una capa dentro de la misma plataforma, o desde una aplicación externa, los mensajes que se envían y reciben son archivos en formato XML.
29
Relación entre capas
Todas las capas creadas sobre Moodle tienen una relación directa entre ellas, en la siguiente figura se presenta gráficamente la relación entre las distintas capas.
Ilustración 10 Relación entre capas
Capa de Widgets Capa RSA.- Estas capas están relacionadas directamente debido a que desde la capa de widgets se hace el llamado a las funciones que gestionan los datos de la red social de aprendizaje obtenidos mediantes servicios web desde Moodle, estos datos se encuentran en las tablas creadas para implementación la red social en el proyecto Glesone.
Capa RSA Capa de Web Services.- La capa RSA se relaciona con la capa de web services para obtener mediante servicios web los datos correspondientes a la red social, en la capa RSA se gestionan estos datos obtenidos para dar una presentación en forma de red social.
31
2.3
DISEÑO
La metodología XP sugiere la realización de diseños simples y sencillos. Se debe procurar hacer todo lo menos complicado posible para conseguir un diseño fácilmente entendible y sencillo de implementar que además requerirá menos esfuerzo y tiempo para construirlo. Si se encuentra algo complejo se debe reemplazar con algo simple para evitar gastar tiempo tanto en el diseño como en la posterior codificación.
2.3.1 Metáfora del Sistema
Una metáfora es algo que todos entienden, sin necesidad de mayores explicaciones. La metodología XP sugiere utilizar este concepto como una manera sencilla de explicar el propósito del proyecto, y guiar la estructura y arquitectura del mismo. (Joskowicz, 2008)
No es un proceso tan simple, ya que se necesita un conocimiento profundo sobre el sistema para elegir una buena metáfora, y que todo el equipo la entienda.
La cualidad más importante es la capacidad de explicar el diseño del sistema a la gente nueva, sin tener que recurrir a extensos documentos.
En este proyecto, aunque dentro del equipo se tiene una visión clara sobre el propósito, contamos además con una arquitectura definida, que especifica de manera clara el propósito del proyecto.
Parte importante para proveer la metáfora del sistema en este proyecto, ha sido la implementación de una capa de red social sobre Moodle sin uso de servicios web, que anteriormente ya se había desarrollado. El desarrollo anterior de dicha capa sobre Moodle ha brindado importante ayuda para un mejor entendimiento en cuanto a la capa de red social con uso de servicios web que se desarrollará en este proyecto.
2.3.2 Modelo de Datos
32 Para mayor comprensión, se ha dividido la presentación del modelo de datos en dos partes:
Modelo de datos (Funcionalidades nativas de Moodle) Modelo de datos (Red Social)
Modelo de datos (Funcionalidades nativas de Moodle)
A continuación se describen cada una de las tablas del modelo de datos usadas para interactuar con algunos de los datos de Moodle.
Tablas Utilizadas
mdl_user: Tabla de la cual se extrae información de los usuarios relacionados con las distintas actividades.
mdl_modules: Contiene los módulos disponibles en Moodle, que pueden ser agregados a un curso, por ejemplo: assignments, forums, resources, quizzes, etc.
mdl_course: Registra información referente a los cursos disponibles en moodle.
mdl_course_categories: Registra distintas categorías creadas para clasificación de los cursos.
mdl_course_modules: Registra los módulos que han sido agregados a un curso en particular.
mdl_course_sections: Registra toda la información correspondiente a un curso, como anuncios, módulos, usuario, etc.
mdl_assignment: Se registra información sobre las tareas asignadas a un curso.
mdl_assignment_submissions: Registra información sobre archivos cargados por un estudiante en la tarea específica de un curso.
mdl_resource: Mantiene información sobre los recursos agregados en un curso.
mdl_quizz: Se registra información sobre los cuestionarios asignados a un curso.
mdl_forum: Se registra información sobre los foros asignados a un curso.
mdl_forum_discussions: Se registran todas las discusiones que tiene un foro.
33 El esquema del modelado de datos (Funcionalidades de Moodle) es presentado en la siguiente figura.
34
Modelo de datos (Red Social)
Como se mencionó anteriormente, para las funciones de Red Social, se usara el mismo modelo de datos usado en la implementación de la red social sin uso de servicios web de Glesone.
Tablas Utilizadas (Jaramillo E, 2010)
(Tablas de moodle utilizadas)
mdl_user: Tabla principal de la cual se extrae la información de los usuarios para presentarla en post y comentarios.
mdl_course: Se extrae información para determinar en qué cursos se encuentra matriculado un determinado usuario y hacer correspondencia con los post y comentarios que coloquen en cada uno de ellos.
mdl_message: Se almacenan los mensajes enviados entre los usuarios de la red.
mdl_log: Se registran todos los eventos que realiza el usuario desde que inicia sesión hasta que termina, de los cuales se toma los que permitirán definir el número de nuevos post que se han colocado desde el último acceso a cada curso. Estos números se muestran junto al nombre de cada curso en el bloque cursos.
mdl_message_contacts: Se usa para almacenar las relaciones de amistad entre los usuarios.
mdl_course_sections: En esta tabla se requiere crear un campo denominado id_usuario que permita establecer una relación entre los recursos y actividades colocadas por un profesor en un determinado curso. Esta modificación fue necesaria debido a que se cambió el esquema de anuncios a post-comentario.
(Tablas de Red Social)
mdl_rsa_post: En esta tabla se guarda el contenido de un post colocado por un usuario en la Red Social o en un curso.
35
mdl_rsa_invitaciones: Aquí se almacenan las solicitudes de amistad que se originan entre los usuarios. Una vez que la solicitud es a acepta, se crea un registro en la tabla mdl_message_contacts para establecer la relación de amistad entre los usuarios.
mdl_rsa_participantes_curso: Cuando un profesor desea que los post y comentarios de un estudiante no sean visualizados dentro de un curso, se crea en esta tabla un registro que mantiene bloqueado al estudiante.
mdl_rsa_actividad: Cada usuario puede realizar diferentes actividades dentro de la RSA como: comentar, postear en un muro, marcar una publicación que le guste, aceptar una solicitud de amistad. Todas estas actividades se registran en esta tabla y se presentan en el muro del usuario como actividad y también en el menú de notificaciones.
36
37
2.3.3 Prototipos
En esta fase se ha considerado además la presentación de algunos prototipos los cuales se basan en las recomendaciones de XP (simples y sencillos), esto con la finalidad de brindar una visión más clara de las necesidades del sistema.
Prototipo 1: Presentación Inicial
En este prototipo se ilustra la ventana de la presentación principal, con una interfaz dinámica. Cuando un usuario ingresa al sistema observa en la parte izquierda una pantalla pequeña que contiene la lista de cursos, y otra que contiene el perfil de usuario, el cual puede ser actualizado, y en la parte derecha aparece una ventana que contiene la Red Social del usuario, en la cual se puede agregar y eliminar anuncios y comentarios, seleccionar la opción Me gusta de los posts y comentarios. Además esta red social contiene un menú de notificaciones sobre las actividades realizadas en la red, un menú de solicitudes de amistad, y otro de los usuarios bloqueados.
En la pantalla que contiene los cursos se puede observar una relación hacia la pestaña
M C
38 dirigiremos hacia dicha pestaña, la cual cambiará en nombre con el del curso seleccionado, el contenido mostrado en esta pestaña es representado en el Prototipo 2.
Además se muestra las opciones de maximizar, minimizar y cerrar de las pantallas. La lista de widgets presentados en esta parte se describe a continuación:
Nombre de Widget Descripción Funcionalidades Lista de cursos En este widget se listan
todos los cursos en los que el usuario tiene un rol. Los cursos estarán clasificados por la categoría a la que pertenecen.
- Presentación de cursos del usuario.
- Enlace hacia una nueva presentación con el contenido del curso seleccionado.
Perfil de usuario Se presenta los datos personales del usuario. Con una opción para editar los mismos.
- Presentación de datos personales del usuario. - Actualización de datos
personales. Red social principal Se presenta un widget que
contiene una red social en la que se puede tener relación con los demás usuarios del sistema que estén entre los contactos.
- Visualización de post y comentarios propios y de los contactos de la red. - Capacidad de agregar posts
en la red, y comentarios a los posts propios y de los contactos.
- Capacidad de eliminar posts y comentarios propios. - Presentación de la opción
M
y comentario de la red social.
- Presentación de un menú de notificaciones sobre alguna acción en la red social.
- Presentación de menú de invitaciones a la red social. - Presentación de menú de
usuarios bloqueados. - Visualización del muro del
39
Prototipo 2: Presentación del Curso
En este prototipo se ilustra la presentación de un curso de Moodle en una interfaz de widgets. En cada widget dentro del curso actual, se deberá encontrar diferente tipo de información relacionada al curso, información sobre: anuncios de profesor, foros, participantes del curso, usuarios online, la red social del curso, recursos, cuestionarios, y tareas.
Cuando se ha ingresado a un curso es sumamente importante identificar el rol que posee el usuario en dicho curso, ya que algunas funcionalidades disponibles dentro de los widgets con información, se encuentran restringidas para usuarios con rol de estudiante, y solamente están disponibles para los usuarios que tienen un rol de profesor.
Las funcionalidades que están disponibles únicamente para profesores del curso son: - Agregar nuevo anuncio
- Agregar nuevo foro
- Agregar nueva discusión en un foro - Agregar nuevo recurso
40 - Agregar nueva tarea
- Agregar nuevo cuestionario - Borrar anuncio
- Borrar foro
- Borrar discusión de un foro - Borrar recurso
- Borrar tarea
- Borrar cuestionario
- Ver tareas subidas por los estudiantes
La lista de widgets presentados inicialmente en esta parte, se describen a continuación:
Nombre de Widget Descripción Funcionalidades Participantes Este widget contiene una
lista de los usuarios que tienen un rol en el curso, se clasifican de acuerdo al rol que poseen.
Se puede observar el perfil del usuario al ubicarse sobre la fotografía de éste, y se puede enviar mensajes privados a cualquiera de estos usuarios.
- Presentación de la lista de usuarios con rol en el curso. - Clasificación de los usuarios
de acuerdo a su rol.
- Vista del perfil de usuario de los participantes del curso.
- Posibilidad de enviar mensajes privados a cualquiera de los participantes listados. Anuncios Contiene una lista con los
anuncios que han sido colocados por el profesor en las secciones del curso. Si el usuario tiene rol de profesor, puede agregar uno nuevo.
- Presentación de anuncios colocados por el profesor en las secciones del curso. - Posibilidad de navegar por
cada anuncio
individualmente, o de mostrar todos a la vez. - Si el usuario tiene rol de
profesor en el curso tiene la posibilidad de agregar, editar, y eliminar los anuncios puestos por él mismo anuncio.
- Posibilidad de permitir comentarios en los anuncios agregados.
41 Cuestionarios Contiene la lista de
cuestionarios disponibles en el curso, con la información correspondiente a cada uno. Si el usuario tiene rol de profesor, puede agregar uno nuevo.
- Presentación de la lista de cuestionarios disponibles en el curso.
- Si el usuario tiene rol de profesor podrá eliminar, y agregar nuevos.
Red social del curso Se presenta un widget que contiene una red social para el curso en el que se encuentre, en la que se tiene relación con los demás participantes de ese curso.
- Visualización de post y comentarios propios y de los contactos de la red. - Capacidad de agregar posts
en la red, y comentarios a los posts propios y de los demás participantes. - Capacidad de eliminar posts
y comentarios propios. - Presentación de la opción
M a post
y comentario de la red social.
- Presentación de un menú de notificaciones sobre alguna acción en la red social.
- Presentación de menú de invitaciones a la red social. - Presentación de menú de
usuarios bloqueados.
Foros Contiene la lista de foros disponibles en el curso, con la información correspondiente a cada uno. Al ingresar a un foro dando clic sobre el nombre de éste, se tendrá disponibles las discusiones del mismo, en las que se puede hacer los respectivos comentarios. Si el usuario tiene rol de profesor, puede agregar un nuevo foro, o una nueva discusión.
- Presentación de la lista de foros disponibles en el curso.
- Presentación de la lista de discusiones de cada foro. - Si el usuario tiene rol de
profesor podrá eliminar, y agregar nuevos foros, y nuevas discusiones en los foros.
- Posibilidad de agregar posts en las discusiones de los foros.
Recursos Contiene la lista de recursos disponibles en el curso, con la información correspondiente a cada uno. Si el usuario tiene rol de profesor, puede agregar uno nuevo.
- Presentación de la lista de recursos disponibles en el curso.
42 Tareas Contiene la lista de tareas
disponibles en el curso, con la información correspondiente a cada uno. Si el usuario tiene rol de profesor, puede eliminar y agregar uno nuevo, y ver las tareas que han sido enviadas por cada estudiante.
- Presentación de la lista de tareas disponibles en el curso.
- Si el usuario tiene rol de profesor podrá eliminar, agregar nuevos, y ver las tareas que han sido enviadas por los estudiantes.
Usuarios en línea Se presenta la lista de usuarios conectados al sistema.
- Presentación de la lista de usuarios conectados al sistema.
- Posibilidad de enviar un mensaje privado al usuario conectado.
- Vista del perfil del usuario conectado.
Prototipo 3: Gestión de Amistades de la red social
43 Cuando el usuario hace clic sobre la A se presentará una nueva pantalla, en donde se encuentra una lista de widgets que contienen información sobre los contactos o amistades de la red social principal del usuario.
Estos widgets contienen información sobre los contactos o amistades, sobre los usuarios conectados, los mensajes recibidos por parte de otros usuarios, y la funcionalidad de buscar usuarios.
D B E
contactos, dando clic sobre el enlace con estos nombres, el contacto quedará bloqueado o eliminado.
En el widget con la funcionalidad de buscar usuarios, al ingresar los datos para buscar al usuario se deberá dar clic sobre el botón buscar, e inmediatamente presentar los resultados de la búsqueda en caso de haberse encontrado. Para los usuarios encontrados en una búsqueda existe la posibilidad de enviarle una solicitud de amistad
.
La lista de usuarios conectados muestra todos los usuarios que han ingresado al sistema en los últimos cinco minutos.
La lista de mensajes recibidos nos presenta los datos sobre quien ha enviado el
M
considerar para la presentación dicha lista de mensajes. La lista de mensajes se actualiza automáticamente cada 60 segundos.
La lista de widgets presentados en esta parte, se describen a continuación: Nombre de Widget Descripción Funcionalidades Contactos Este widget contiene la lista
de los contactos de la red social.
- Presentación de la lista de contactos de la red social. - Opción eliminar contacto. - Opción bloquear contacto. - Opción de enviar mensaje
privado al contacto.
- Vista de perfil de usuario al ubicarse sobre la fotografía del contacto.
Buscar Personas En este widget se presenta un campo desde donde se puede buscar un usuario en el sistema.
Se presentan todos los usuarios relacionados con la búsqueda, con las opciones de eliminar, bloquear, enviar
- Ingresar un dato para la búsqueda de usuarios. - Presentación de usuarios
relacionados con la búsqueda.
44 invitación, dependiendo de la
relación entre el usuario que realiza la búsqueda y el usuario encontrado.
encontrado es un contacto. - Presentar la opción enviar
invitación si el usuario encontrado no es un contacto.
Usuarios en línea Se presenta la lista de usuarios conectados al sistema.
- Presentación de la lista de usuarios conectados al sistema.
- Posibilidad de enviar un mensaje privado al usuario conectado.
- Vista del perfil del usuario conectado.
Mensajes recibidos Se presenta un widget que contiene una lista de mensajes recibidos, indicando el usuario remitente.
Se pude marcar la lista de mensajes como leídos para ya no mostrarlos en el widget.
- Lista de mensajes recibidos desde distintos usuarios. - Identificación del usuario
que ha enviado el mensaje. - Opción de marcar la lista de
mensajes como leídos, para ya no presentarlos en el widget.
45
2.3.4 Diagrama de Clases
Las principales clases desarrolladas en este proyecto son las siguientes: - ClassInitWS
- ClassTime
- ClassFuncionesPost - ClassNotifications - ClassAssignments - ClassContacts - ClassParticipants - ClassQuizzes - ClassSearch - ClassForms
Todas estas son las clases desarrolladas en php, para dar soporte a las funcionalidades requeridas por el sistema.
Estas clases son representadas en un diagrama de clases en la ilustración 16, en el cual se muestra las dependencias entre dichas clases, sin embargo php no es un lenguaje de programación con soporte completo para la programación orientada a objetos, por lo que generalmente a estas clases se las usa también desde otros archivos php que no están definidos como clases, sino que son archivos para ser presentados en el navegador web, y suelen tener parte de código php y parte de etiquetas html.
En la representación del diagrama de clases (Ilustración 16) se usa dos tipos de relaciones:
- Herencia y generalización . Permite que una clase hija herede todos los atributos y propiedades de la clase padre.
La representación de herencia en UML (Unified Model Language) es a través de una línea que termina en un triángulo sin relleno.
46
Ilustración 16 Diagrama de Clases
La clase MoodleWS, es una clase generada automáticamente mediante la librería wsdl2php.php, como complemento del plugin wspp, este proceso está descrito en el manual de instalación.
47
Clase ClassInitWS
Esta clase contiene las funcionalidades para establecer el valor de las variables necesarias para la comunicación con los servicios web, dichas variables son requeridas desde otras clases, razón por la que son heredas.
Funciones en ClassInitWS
get_usuario_ws(). Esta función obtiene la identificación del cliente del web service, la
cual debe ser enviada como parámetro en las funciones que realizan operaciones mediante servicios web.
get_token_ws(). Esta función obtiene la clave de sesión del cliente del web service, la
cual debe ser enviada como parámetro en las funciones que realizan operaciones mediante servicios web.
get_moodle_ws(). Esta función obtiene una variable inicializada como objeto de la
clase MoodleWS (generada automáticamente con la librería wsdl2php.php) de la capa de web services.
set_usuario_ws(new_user). Establece el valor pasado como parámetro a la variable
que contiene la identificación del cliente del web service.
set_token_ws(new_token). Establece el valor pasado como parámetro a la variable
que contiene la clave de sesión del cliente del web service.
set_moodle_ws(new_moodlews). Establece el valor pasado como parámetro al objeto
48
ClaseTime
Esta clase contiene las funcionalidades para dar un formato de presentación a las fechas.
Funciones en ClassTime
relativeTime(dt). Esta función transforma una fecha pasada como un entero, en una
fecha relativa.
relativeTime
Parametro Tipo Descripción Retorno
dt Entero Fecha, o time
representada en un valor entero.
Cadena, con una fecha relativa
converter_to_int_date (string_date). Esta función transforma una fecha pasada en
una cadena, a una fecha representada en un entero.
converter_to_int_date
Parametro Tipo Descripción Retorno
string_date Cadena Fecha,
representada en una cadena.
