Capa de Usuario Final Basada en Web Services PDF

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
Trabajo de fin de carrera previa a la obtención del

título de Ingeniero en Sistemas Informáticos y
Computación.
Autor:
Chamba Jiménez Esteban Yomairo
Directores:
Torres Días Juan Carlos
Abad Espinoza Marco Patricio
LOJA ECUADOR
2011
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
Ing. Torres Díaz Juan Carlos
II
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
Ing. Abad Espinoza Marco Patricio
III
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.
CI: 1104690621
IV
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,
V
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.
Esteban Y. Chamba J.
VI
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.
Esteban Y. Chamba J.
VII
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.
Se ha considerado sumamente importante la necesidad de incorporar las nuevas

tendencias de la web a la plataforma e-learning Moodle en sus versiones 1.9.x y 2.0.x,
con este objetivo se han desarrollado e implementado tres nuevas capas funcionales
sobre las versiones mencionadas de Moodle, estas capas son: capa de web services,
capa de widgets, y una capa de red social. Con esto se pretende integrar componentes
modernos y eficaces en los sistemas de aprendizaje en línea, particularmente en la
plataforma e-learning Moodle, y así lograr un mejor rendimiento tanto en el proceso
de enseñanza como en el proceso de aprendizaje.
VIII
Í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
2.2.3 Reuniones ............................................................................................................ 25
IX
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
OTRAS REFERENCIAS.......................................................................................................... 83
X
Í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
Ilustración 16 Diagrama de Clases .............................................................................................. 46
XI
1 CAPÍTULO I: DEFINICIÓN
DEL PROBLEMA Y ANÁLISIS
INICIAL
1
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.
Las redes sociales han sido un paso gigantesco en la web moderna, razón por la que se
incluye también el concepto de red social de aprendizaje.
2
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.
Integrar la capa visual con una capa de de red social usando servicios web
dentro de la plataforma Moodle.
3
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.
1
UTPL. GLESONE. [en línea].<http://www.glesone.org/>[Citado en 15 de febrero del 2011]
4
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.
Ilustración 1 Apariencia Tradicional 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.
Ilustración 2 Apariencia de GlesOne sobre Moodle
2
MOODLE. [en línea]. <http://www.moodle.org/>[Citado en 15 de febrero del 2011]
5
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.
En los casos de la versión pura de Moodle y la integrada con GlesOne, no se cuenta con
una implementación que permita acceder a los datos desde sistemas externos.
6
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.
3
W3C. [En línea]. <http://www.w3.org/TR/ws-arch/> [Citado en 15 de febrero del 2011]
7
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 línea].<http://docs.moodle.org/en/Development:Web_services_API#What_can_Moodle.27s_XML-
RPC_do.3F>[citado en 21 de febrero del 2011]
8
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]
6
MOODLE. [En línea].http://moodle.org/mod/data/view.php?d=13&rid=573>[citado en 21 de febrero del 2011]
7
W3C. [En línea].http://www.w3.org/TR/2000/NOTE-SOAP-20000508/>[citado en 21 de febrero del 2011]
9
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.
La tecnología a usar seleccionada ha sido el plugin WSPP (Patrick,

2007) para la implementación de Web Services sobre Moodle 1.9.x.
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.
Anexo 1 Página
T C WSPP ... 91
U . 91
P R 93
8
W3C. [En línea].<http://www.w3.org/TR/wsdl>[citado en 21 de febrero del 2011]
10
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
T C 101
11
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).
Se ha determinado usar la implementación del plugin WSPP (Patrick,

2007) en Moodle 2.0x, al igual que para la versión 1.9.x debido a la
posibilidad de reutilización de las nuevas funcionalidades que se
implementarán en el plugin, y teniendo en cuenta además que la
implementación nativa de Web Services en esta nueva versión está aún
en una etapa inicial de desarrollo y no presta los requerimientos
suficientes.
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.
12
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
En todos estos frameworks se presentan opciones para trabajar con widgets, sin
embargo existen algunos frameworks para los que se han creado extensiones
especiales para widgets, a continuación se mencionan algunos de dichos frameworks:
13
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.us v , 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.
serialize(): returns a parameters string for Ajax.Request
14
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.
La herramienta seleccionada para la implementación de Widgets ha sido

JPolite.
En el Anexo 3 Anexo2_Jpolite.docx se da una completa descripción de dicho

framework (sus características
15
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.
Los archivos del paquete JPolite se deben modificar de acuerdo a las necesidades
requeridas por el sistema, además se agregarán otros nuevos, para lograr las
funcionalidades requeridas.
16
1.5.10.1 Caracterí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.
Ilustración 3 Aproximación de Apariencia 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.
17
2 CAPÍTULO II:
DESARROLLO DE LA
SOLUCIÓN
18
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
WELL DON. Extreme Programming: A gentle Introduction: [en lÍnea] <http://www.extremeprogramming.org>
19
Ilustración 4 Ciclo del Proyecto con XP (Fernandez, 2002)
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.
20
En la siguiente figura se muestran cada una de estas fases, y se desglosan con las
respectivas actividades de cada una.
Ilustración 5 Fases Metodología XP (Fernandez, 2002)
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.
21
Ilustración 6 Fases XP (Adaptada al entorno del Proyecto)
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.
22
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.
Las historias de usuario se enfocan como procesos independientes en cada objetivo

que se pretende alcanzar, con el fin de abordar el problema con mayor sencillez.
23
En el Anexo4_Historias_Iniciales.docx, se presentan las historias de usuario obtenidas
en para el desarrollo de este proyecto.
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
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 5 Página
P 128
P 128
S I .. 132
T I 136
C I .. 139
Q I . 142
Sexta I
24
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:
Ilustración 7 Arquitectura General del Sistema
25
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.
Actualmente Glesone tiene definida una arquitectura de la red social que ha sido
implementada, ésta se detalla a continuación.
26
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.
Ilustración 8 Arquitectura RSA y Moodle (Jaramillo E, 2010)
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.
27
Ilustración 9 Arquitectura Propuesta (Nuevas capas sobre Moodle)
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.
28
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.
Capa de Widgets Capa de Web Services.- La capa de widgets además se relaciona

directamente con la capa de web services para obtener datos relacionados a los cursos
y a la información del usuario, estos datos se gestionan para ser presentados en los
widgets correspondientes.
29
Como se puede observar en la figura R , el resultado de
las otras dos capas (capa RSA, capa de Web Services), es presentado finalmente en la
Capa de Widgets, que es la vista que tendrá el usuario final.
30
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

En esta fase se ha realizado un análisis de la base de datos para definir las tablas que
se usaran en el desarrollo de este proyecto. No se ha considerado la creación de
nuevas tablas, sino que se usara algunas de las tablas de Moodle que ya están
definidas, esto para interactuar con los datos de la plataforma mediante servicios web.
Para las funciones de red social, se usaran las mismas tablas creadas para la
implementación de red social sin uso de web services en el proyecto Glesone.
31
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.
mdl_forum_posts: Registra todos los post correspondientes a una discusión, o sea los
comentarios hechos en la discusión de un foro.
32
El esquema del modelado de datos (Funcionalidades de Moodle) es presentado en la
siguiente figura.
Ilustración 11 Modelo de Datos (Funcionalidades nativas de Moodle)
33
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.
mdl_rsa_post_comentario: Esta tabla se relaciona directamente con la tabla

mdl_rsa_post y contiene los comentarios que los usuarios realizan sobre un post
determinado.
34
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.
El esquema del modelado de datos (Red Social) es presentado en la siguiente figura.
35
Ilustración 12 Modelo de datos (Red Social) (Jaramillo E, 2010)
36
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
Ilustración 13 Prototipo de 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
37
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 - Presentación de cursos del
todos los cursos en los que el usuario.
usuario tiene un rol. Los - Enlace hacia una nueva
cursos estarán clasificados presentación con el
por la categoría a la que contenido del curso
pertenecen. seleccionado.
Perfil de usuario Se presenta los datos - Presentación de datos

personales del usuario. Con personales del usuario.
una opción para editar los - Actualización de datos
mismos. personales.
Red social principal Se presenta un widget que - Visualización de post y
contiene una red social en la comentarios propios y de
que se puede tener relación los contactos de la red.
con los demás usuarios del - Capacidad de agregar posts
sistema que estén entre los en la red, y comentarios a
contactos. 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.
usuarios bloqueados.
- Visualización del muro del
usuario al dar clic sobre la
fotografía de un contacto.
38
Prototipo 2: Presentación del Curso
Ilustración 14 Prototipo de Presentación de Un 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
39
- 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:

Participantes Este widget contiene una - Presentación de la lista de
lista de los usuarios que usuarios con rol en el curso.
tienen un rol en el curso, se - Clasificación de los usuarios
clasifican de acuerdo al rol de acuerdo a su rol.
que poseen. - Vista del perfil de usuario
Se puede observar el perfil de los participantes del
del usuario al ubicarse sobre curso.
la fotografía de éste, y se - Posibilidad de enviar
puede enviar mensajes mensajes privados a
privados a cualquiera de cualquiera de los
estos usuarios. participantes listados.
Anuncios Contiene una lista con los - Presentación de anuncios
anuncios que han sido colocados por el profesor
colocados por el profesor en en las secciones del curso.
las secciones del curso. - Posibilidad de navegar por
Si el usuario tiene rol de cada anuncio
profesor, puede agregar uno individualmente, o de
nuevo. 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.
- Posibilidad de agregar
comentarios en los
anuncios que lo permiten.
40
Cuestionarios Contiene la lista de - Presentación de la lista de
cuestionarios disponibles en cuestionarios disponibles
el curso, con la información en el curso.
correspondiente a cada uno. - Si el usuario tiene rol de
Si el usuario tiene rol de profesor podrá eliminar, y
profesor, puede agregar uno agregar nuevos.
nuevo.
Red social del curso Se presenta un widget que - Visualización de post y
contiene una red social para comentarios propios y de
el curso en el que se los contactos de la red.
encuentre, en la que se tiene - Capacidad de agregar posts
relación con los demás en la red, y comentarios a
participantes de ese curso. 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.
invitaciones a la red social.
Foros Contiene la lista de foros - Presentación de la lista de

disponibles en el curso, con foros disponibles en el
la información curso.
correspondiente a cada uno. - Presentación de la lista de
Al ingresar a un foro dando discusiones de cada foro.
clic sobre el nombre de éste, - Si el usuario tiene rol de
se tendrá disponibles las profesor podrá eliminar, y
discusiones del mismo, en las agregar nuevos foros, y
que se puede hacer los nuevas discusiones en los
respectivos comentarios. foros.
Si el usuario tiene rol de - Posibilidad de agregar posts
profesor, puede agregar un en las discusiones de los
nuevo foro, o una nueva foros.
discusión.
Recursos Contiene la lista de recursos - Presentación de la lista de
disponibles en el curso, con recursos disponibles en el
Si el usuario tiene rol de profesor podrá eliminar, y
profesor, puede agregar uno agregar nuevos.
nuevo.
41
Tareas Contiene la lista de tareas - Presentación de la lista de
disponibles en el curso, con tareas disponibles en el
Si el usuario tiene rol de profesor podrá eliminar,
profesor, puede eliminar y agregar nuevos, y ver las
agregar uno nuevo, y ver las tareas que han sido
tareas que han sido enviadas enviadas por los
por cada estudiante. estudiantes.
Usuarios en línea Se presenta la lista de - Presentación de la lista de

usuarios conectados al usuarios conectados al
sistema. 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
Ilustración 15 Prototipo de Gestión de Amistades de la red social
42
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:

Contactos Este widget contiene la lista - Presentación de la lista de
de los contactos de la red contactos de la red social.
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 - Ingresar un dato para la
un campo desde donde se búsqueda de usuarios.
puede buscar un usuario en - Presentación de usuarios
el sistema. relacionados con la
Se presentan todos los búsqueda.
usuarios relacionados con la - Presentar la opción eliminar
búsqueda, con las opciones y bloquear si el usuario
de eliminar, bloquear, enviar
43
invitación, dependiendo de la encontrado es un contacto.
relación entre el usuario que - Presentar la opción enviar
realiza la búsqueda y el invitación si el usuario
usuario encontrado. encontrado no es un
contacto.
Usuarios en línea Se presenta la lista de - Presentación de la lista de
usuarios conectados al usuarios conectados al
sistema. sistema.
- Posibilidad de enviar un
mensaje privado al usuario
conectado.
- Vista del perfil del usuario
conectado.
Mensajes recibidos Se presenta un widget que - Lista de mensajes recibidos
contiene una lista de desde distintos usuarios.
mensajes recibidos, - Identificación del usuario
indicando el usuario que ha enviado el mensaje.
remitente. - Opción de marcar la lista de
Se pude marcar la lista de mensajes como leídos, para
mensajes como leídos para ya no presentarlos en el
ya no mostrarlos en el widget.
widget.
Los widgets presentados en cada uno de los prototipos son la configuración inicial o
por default de la presentación, ya que pueden ser agregados en cualquier lugar
agregándolos desde un menú de widgets, o arrastrándolos a las distintas columnas.
44
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.
- Dependencia . Se define cuando una clase usa a otra como

parámetro de sus operaciones
45
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.
Cada una de las otras clases representadas que son parte del desarrollo de este
proyecto, se describen en los siguientes enunciados, en los cuales se da un detalle
sobre las funciones contenidas en cada clase, y sobre los archivos de desarrollo php
relacionados a éstas.
46
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

que hace referencia a la clase MoodleWS.
47
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 Cadena, con una
representada en un fecha relativa
valor entero.
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
string_date Cadena Fecha, Cadena, con una
representada en fecha relativa
una cadena.
48
Clase ClassFuncionesPost
Esta clase contiene las funcionalidades para presentar los posts y comentarios
realizados por los usuarios en un formato de red social, contiene un conjunto de
funciones que son comunes para todos los archivos relacionados.
Funciones en ClassFuncionesPost
ver_post_usuario(estado_img,userid,nombrepostea,mensaje). Esta función sirve para

presentar los post dentro de un widget, los post pueden ser en la red social inicial, el
muro, la red social de un curso, o en un foro.
ver_post_usuario
estado_img Entero Valor 1 si el usuario Código html para
tiene una fotografía presentación de los
en su perfil, 0 si no posts
la tiene
user_id Entero Identificador del
usuario dueño del
post
nombrepostea Cadena Nombre y apellido
del usuario dueño
del post
mensaje Cadena Contenido del post
ver_comentario_usuario(estado_img,userid,nombrepostea,mensaje). Esta función

sirve para presentar los comentarios de un post, o a una discusión dentro de un
widget.
ver_comentario_usuario
tiene una fotografía presentación de
en su perfil, 0 si no comentarios
la tiene
user_id Entero Identificador del
usuario dueño del
comentario
del usuario dueño
49
del comentario
mensaje Cadena Contenido del
comentario
see_ad_teacher(estado_img,userid,nombrepostea,mensaje,isteacher,id_ad). Esta
función sirve para presentación de los anuncios en un curso.
see_ad_teacher
tiene una fotografía presentación de los
en su perfil, 0 si no anuncios que un
la tiene profesor hace en
user_id Entero Identificador del un curso
usuario dueño del
anuncio
(generalmente un
profesor del curso)
del usuario dueño
del anuncio
mensaje Cadena Contenido del
anuncio
Isteacher Booleano True si el usuario
actual tiene rol de
profesor, False si
no tiene rol de
profesor
id_ad Entero Identificador del
anuncio.
Esta
present_actions_in_post(date_of_post,postid,myid,ownerpost,rsatype='',courseid=1).
función es usada para presentar acciones a realizar con los posts de la red social,
acciones como: comentar, eliminar, like. Se usa esta función para los posts de la red
social principal, y de las redes sociales de cada curso.
present_actions_in_post
Parámetro Tipo Descripción Retorno
date_of_post Date Se envía como Código html para
parámetro la fecha presentación de las
en que se ha acciones que se
50
realizado el post, ya puede realizar con
que es parte de la cada post, las
presentación, junto cuales serán
con las acciones a distintas
realizar con el post. dependiendo del
postid Entero Identificador del usuario y su
post sobre el cual relación con el
se presentarán las post.
acciones.
my_id Entero Identificador del
usuario identificado
en el sistema
actualmente.
ownerpost Entero Identificador del
usuario propietario
del post que se
pasó como
segundo
parámetro.
rsa_type Cadena String indicando en
que tipo de red
social se está
realizando la
presentación:
puede ser: _main,
_course, _ad. Por
defecto es null, en
ese caso se asume
que el tipo es
_main.
course_id Entero Identificador del
curso en el que se
está realizando la
presentación. Sería
1 si la presentación
en en _main
viewCommentsToPostRSA(postid,my_id,courseid,rsatype,limit_inf_comm=0,seemore=true).
Esta función es usada para presentar los comentarios realizados en cada posts de la
red social, sea la red social principal, o de los cursos, y de los anuncios en los cursos.
viewCommentsToPostRSA
postid Entero Identificador del Código html para
51
post sobre el cual presentación de los
se presentarán las comentarios de
acciones. cada post en la red
my_id Entero Identificador del social, sea ésta la
usuario identificado red social inicial, o
en el sistema de cada curso, y
actualmente. para la
courseid Entero Identificador del presentación de los
curso en el que se comentarios en los
está realizando la anuncios que los
presentación. Sería permiten.
en en _main
rsa_type Cadena String indicando en
que tipo de red
social se está
realizando la
presentación:
puede ser: _main,
_course, _ad. Por
defecto es null, en
ese caso se asume
que el tipo es
_main.
limit_inf_comm Entero Indica desde donde
se iniciará la
presentación de los
comentarios. Valor
por defecto es 0, lo
que indica que se
iniciará la
presentación desde
el primero.
see_more Booleno Si es true indica
que se debería
mostrar la opción
ver más
comentarios. Por
defecto su valor es
true.
present_box_to_comment($postid, $my_id, $user_id,$courseid=1). Esta función es para

presentar un espacio en donde agregar nuevos comentarios a un post, es usada en la
52
red social inicial, en las de cada curso, y para agregar comentarios en los anuncios de
los cursos, cuando lo permiten.
present_box_to_comment
postid Entero Identificador del Código html para
post sobre el cual presentación de un
se presentarán las área en para
acciones. agregar
my_id Entero Identificador del comentarios a los
usuario identificado posts de la red
en el sistema social, sea ésta la
actualmente. red social inicial, o
user_id Entero Identificador del de cada curso, y
usuario propietario para agregar
del post que se comentarios en los
pasó como primer anuncios que los
parámetro. permiten.
courseid Entero Identificador del
curso en el que se
está realizando la
presentación. Sería
en en _main
Archivos de programación relacionados con ClassFuncionesPost
Los archivos de programación que hacen uso o que están relacionados con la clase
ClassFuncionesPost realizan distintas funcionalidades, que se describen a continuación
en la siguiente tabla:
Archivos de programación relacionados con la clase ClassFuncionesPost

Nombre del Archivo Descripción
new_post_main_rsa.php Contiene las funcionalidades para agregar
un nuevo post en la red social principal
del usuario identificado
main_rsa_data.php Contiene las funcionalidades para cargar
todos los datos de la red social inicial
cuando el usuario inicia sesión y se dirige
a la presentación en widgets
course_rsa_data.php Contiene las funcionalidades para cargar
los datos de la red social del curso que ha
seleccionado el usuario
wall_data.php Carga los datos del muro del usuario
53
seleccionado.
ads_in_course.php Presenta los anuncios hechos en las
secciones del curso seleccionado, en caso
de que el usuario tenga el rol de profesor,
se le permite además agregar anuncios y
modificarlos
comment_ajax.php Contiene las funcionalidades para cargar
un comentario, sea en la red social
principal, en la de un curso, o en el muro
de un usuario
more_comments.php Funcionalidades para presentar una cierta
cantidad de comentarios cada vez que se
hace referencia a este archivo, sea en la
red social inicial, en la de un curso, en el
muro de un usuario o en los anuncios que
permiten cometarios
morepost_incourse.php Contiene las funcionalidades para
presentar una cantidad limitada de posts
en la red social de un curso, y cada vez
que se llama a este archivo se presentan
más posts en caso de haberlos
new_ad_in_course.php Contiene las funcionalidades para que el
usuario coloque un nuevo anuncio en un
curso, solo en caso de tener el rol de
profesor
new_post_in_wall.php Contiene las funcionalidades para agregar
un nuevo post en el muro de un usuario
new_post_rsa_course.php Contiene funcionalidades para agregar un
nuevo post en la red social de un curso
especifico, que haya sido seleccionado
add_discussion.php Contiene las funcionalidades para agregar
un nuevo tema de discusión en un foro
del curso, solo en caso tener rol de
profesor del curso
more_post_todisc.php Contiene las funcionalidades para agregar
posts o comentarios en el tema de
discusión de un foro en el curso
seleccionado
54
Clase ClassNotifications
Esta clase contiene las funcionalidades para presentación de los menús de

notificaciones de actividad en la red social, notificación de solicitudes de amistad, y
notificaciones de usuarios bloqueados. Un conjunto de funciones aquí definidas, nos
permiten dicho objetivo.
Funciones en ClassNotifications
crear_listas_avisos(cadena_avisos,parametro,num_new_notif,rsatype=''). En esta
función se crea el menú que se va a presentar (notificaciones, solicitudes de amistad,
usuarios bloqueados), dependiendo de los parámetros obtenidos.
crear_listas_avisos
cadena_avisos Objeto Objeto con los datos que Código html para
contiene la notificación. presentación de los
Estos datos son obtenidos menús de
mediante servicios web notificaciones (de
parametro Entero Identificador del tipo de actividad en la red
menú que se va a social, invitaciones
presentar. de amistad,
0: Presentación de menú de usuarios
usuarios bloqueados bloqueados).
1: Presentación de menú de
solicitudes de amistad
actividad en la red social
(cuando existen no leídas)
actividad en la red social
(cuando no existen no
leídas).
4: Presentación de las
siguientes notificaciones de
actividad al dar clic sobre el
ícono ver más
notificaciones.
num_new_notif Entero Número de notificaciones
que se han obtenido
rsa_type Cadena Identifica el tipo de red
social en la que se realizará
la presentación, puede ser
55
get_notifications_data (courseid,userid,rsatype=''). Esta función obtiene un objeto
con la lista de datos para las notificaciones, este objeto es pasado a la función
crear_listas_avisos de esta misma clase.
get_notifications_data
courseid Entero Id del curso actualmente Objeto con los
seleccionado datos de las
notificaciones
userid Entero Id del usuario actualmente obtenidas.
identificado.
rsa_type Cadena Identifica el tipo de red

social en la que se realizará
la presentación, puede ser
Archivos de programación relacionados con ClassNotifications
Los archivos que hacen uso de la clase ClassNotifications realizan distintas funciones,
se describen a continuación:
Archivos de programación relacionados con la clase ClassNotifications

Present_main_rsa.php Presenta la red social principal. Usa la
clase ClassNotifications para presentar el
menú de la red social principal.
Present_course_rsa.php Presenta la red social de un curso. Usa la
clase indicada para presentar el menú de
la red social del curso seleccionado.
Present_wall.php Presenta el muro de la social de un
usuario. Usa la clase indicada para
presentar el menú de la red social
principal.
view_mores_notifications.php. Agrega un conjunto de notificaciones

anteriores en el menú de notificaciones,
de cualquiera de las redes sociales
(principal, de un curso).
56
Clase ClassAssignments
Esta clase gestiona la presentación de las tareas de un curso usando los datos
obtenidos mediantes servicios web.
Funciones en ClassAssignments
showAssignmentsInCourseToTeacher(assignments_in_course,fields). Esta función

gestiona la presentación de las tareas en un curso cuando el usuario tiene rol de
profesor.
showAssignmentsInCourseToTeacher
assignments_in_course Objeto Objeto que contiene los Código html para
datos sobre cada una de presentación de la
las tareas del curso. lista de tareas de
un curso cuando el
fields Array Array con los nombres de usuario tiene rol
los datos que se desean de profesor.
presentar del objeto
pasado como primer
parámetro.
showAssignmentsInCourseToStudent(assignments_in_course,fields). Esta función

gestiona la presentacion de las tareas en un curso, igual que la función anterior, la
diferencia es que gestiona la presentación cuando el usuario tiene rol de estudiante.
Los parámetros son comunes en ambas funciones, se describen a continuación.
showAssignmentsInCourseToStudent
assignments_in_course Objeto Objeto que contiene los Código html para
datos sobre cada una de presentación de la
las tareas del curso. lista de tareas de
un curso cuando el
fields Array Array con los nombres de usuario tiene rol
los datos que se desean de estudiante.
presentar del objeto
pasado como primer
parámetro.
57
showAssignmentsSubmissions(assignments_submission,fields). Gestiona la
presentación de los archivos que han sido subidos en una determinada tarea por parte
de un estudiante, se usa solamente cuando el usuario que ha iniciado sesión tiene rol
de profesor en el curso.
showAssignmentsSubmissions
assignments_submission Objeto Objeto con todos los Código html para
datos del recurso realizar la
cargado por el estudiante presentación de la
en la tarea lista de tareas
fields Array . Arreglo con los campos subidas por los
que se va a procesar del estudiantes. Sólo
objeto pasado como se presenta
primer parámetro cuando el usuario
tiene rol de
profesor.
Archivos de programación relacionados con ClassAssignments
Los archivos que hacen uso de las funciones de la clase realizan distintas
funcionalidades, las cuales se describen a continuación:
Archivos de programación relacionados con la clase ClassAssignments

add_assignment.php Contiene las funcionalidades para
presentar la opción de agregar una nueva
tarea en el curso en caso de que el
usuario tenga el rol del profesor,
presentando además un historial de las
tareas del curso, en caso de que el
usuario tenga rol de estudiante, entonces
solamente se presenta el historial de
tareas del curso.
Asignment_submissions.php Contiene las funcionalidades para
presentar las tareas cargadas por los
estudiantes, se pueden ver en caso de
que el usuario tenga rol de profesor.
58
Clase ClassContacts
En esta clase se gestiona la obtención de los contactos de un usuario mediante
servicios web y les da un formato de presentación. Contiene una sola función, que se
describe a continuación:
Funciones en ClassContacts
get_my_contacts(contact_list). Esta función gestiona la presentación de las los

contactos del usuario identificado.
get_my_contacts
contact_list Objeto Objeto con toda la Código html para
información de los realizar la
contactos del usuario presentación de la
lista de contactos
del usuario.
Archivos de programación relacionados con ClassContacts
A continuación los archivos que hacen uso de las funciones de esta clase:
Archivos de programación relacionados con la clase ClassContacts

ContactsList Contiene las funcionalidades para
presentar la lista de contactos del usuario
dentro del widget de contactos
59
Clase ClassParticipants
En esta clase se gestionan la obtención de los datos de los participantes de un curso
mediante servicios web, y les da un formato de presentación.
Funciones en ClassParticipants
get_participants(participants_list). Esta función gestiona la presentación de los

participantes de un curso.
get_participants
participants_list Objeto Objeto con toda la Código html para
participantes del curso. presentación de la
lista de
participantes del
curo.
Archivos de programación relacionados con ClassParticipants
Los archivos que hacen uso de las funciones de la clase son:
Archivos de programación relacionados con la clase ClassParticipants

participants_in_course_list.php En este archivo se realiza la presentación
de la lista de participantes del curso en un
widget, se identifica usuarios con rol de
profesor, y los usuarios con rol de
estudiante.
60
ClassQuizzes
En esta clase se gestiona la obtención y presentación de los datos referentes a los
cuestionarios de un curso, los datos son obtenidos mediante servicios web.
Funciones en ClassQuizzes
showQuizzesInCourse(quizzes_in_course,fields,isteacher). Esta función gestiona la

presentación de los cuestionarios de un curso.
showAssignmentsSubmissions
quizzes_in_course Objeto Objeto con toda la Código html para
cuestionarios del curso. presentación de la
fields Array Arreglo con todos los lista de
campos que se desean cuestionarios en
visualizar del objeto en el un curso.
primer parámetro de esta
función.
isteacher Boolean True significa que el
usuario tiene rol de
profesor en el curso, False
q tiene rol del estudiante.
Esto es importante ya que
la presentación es distinta
para ambos roles.
Archivos de programación relacionados con ClassQuizzes
Los archivos que hacen uso de las funciones de la clase se describen en la siguiente
tabla:
Archivos de programación relacionados con la clase ClassQuizzes

quizzes_incourse.php En este archivo se realiza la presentación
de la lista de cuestionarios del curso en
un widget, aquí se obtiene la lista de
cuestionarios, y el tipo de rol que tiene el
usuario.
61
Clase ClassSearch
En esta clase se gestiona la obtención y presentación de los datos de un usuario
buscado, los datos son obtenidos mediante servicios web.
Funciones en ClassSearch
get_search_user(searcher_user). Esta función gestiona la presentación del usuario

encontrado en una búsqueda.
get_search_user
searcher_user Objeto Objeto con la información Código html para
del usuario encontrado realizar la
según la búsqueda. presentación de la
lista de usuarios
obtenidos como
resultado de una
búsqueda.
Archivos de programación relacionados con ClassSearch
Los archivos que hacen uso de las funciones de la clase se presentan en la siguiente
tabla:
Archivos de programación relacionados con la clase ClassSearch

ViewSearchedUsers.php En este archivo se realiza la búsqueda del
usuario según un patrón de búsqueda, y
se obtiene el objeto con los datos del
usuario para luego realizar la
presentación.
62
ClassForms
En esta clase contiene funciones para gestionar la presentación de los formularios que
sirven para agregar un nuevo módulo en el curso, los datos de este formulario se
envían a través de los servicios web para actualizar las entradas en el curso.
Funciones en ClassForms
check_teacher_role(userid). Verifica el rol del usuario de acuerdo al id recibido como

parámetro, esto se requiere debido a que ciertas partes de los formularios se
presentan dependiendo del rol que tiene el usuario en el curso.
check_teacher_role
userid Entero Id del usuario Tipo: Entero.
actualmente identificado Devuelve el rol del
usuario
identificado con el
id obtenido como
parámetro.
get_add_assignment_form(). Gestiona la presentación y procesamiento de los datos

del formulario para agregar una nueva tarea en el curso.
get_add_resources_form(). Gestiona la presentación y procesamiento de los datos

del formulario para agregar un nuevo recurso en el curso.
get_add_quiz_form(). Gestiona la presentación y procesamiento de los datos del

formulario para agregar un nuevo cuestionario en el curso.
get_add_forum_form(). Gestiona la presentación y procesamiento de los datos del

formulario para agregar un nuevo foro en el curso.
Archivos de programación relacionados con ClassForms
Los archivos que hacen uso de las funciones de la clase se describen en la siguiente
tabla:
Archivos de programación relacionados con la clase ClassForms

Course_Resources.php En este archivo se realiza la presentación
de los recursos del curso, y se presenta
además el formulario para agregar un
63
recurso nuevo.
add_assignment.php En este archivo se realiza la presentación
de las tareas del curso, y se presenta
además el formulario para agregar una
tarea nueva.
quizzes_incourse.php En este archivo se realiza la presentación
de los cuestionarios del curso, y se
presenta además el formulario para
agregar un cuestionario nuevo.
Forums_List.php En este archivo se realiza la presentación
de los foros del curso, y se presenta
además el formulario para agregar un
foro nuevo.
64
2.4 DESARROLLO
La metodología XP plantea algunas reglas en la fase de desarrollo. Sin embargo como

ya se indicó anteriormente, en este proyecto no se ha implementado exactamente
todas las reglas planteadas por la metodología, tanto por las condiciones de la
naturaleza del proyecto, como por el ambiente académico en que se está
desarrollando. Una de las reglas que no ha sido posible seguir, es
únicamente existe un desarrollador.
2.4.1 Disponibilidad del cliente

Uno de los requerimientos de XP es tener al cliente disponible durante todo el
proyecto. No solamente como apoyo a los desarrolladores, sino formando parte del
grupo. El involucramiento del cliente es fundamental para que pueda desarrollarse un
proyecto con la metodología XP.
En la planificación del proyecto se definen las historias de usuario, con la información

que da el cliente, estas historias de usuario sin embargo son cortas y de alto nivel,
razón por la que no tienen los datos necesarios para el desarrollo del código. Este tipo
de detalles deben ser proporcionados por el cliente y discutidos con los
desarrolladores durante la etapa de desarrollo. No se requieren grandes documentos
de especificación de requerimientos, sino los detalles del desarrollo son
proporcionados por el cliente, cara a cara a los desarrolladores.
2.4.2 Pruebas de unidad

Es responsabilidad del desarrollador probar cada función que realiza para garantizar
que el trabajo se ha realizado correctamente. Sin embargo, a pesar de que el usuario
realiza las pruebas unitarias de las funciones que desarrolla, en la fase de pruebas se
realizan además pruebas automatizadas de cada una de las funciones para comprobar
que están respondiendo correctamente.
2.4.3 Integración
En la metodología Extreme Programming, los desarrolladores deben integrar el código
cada pocas horas, cuando sea posible10. En cualquier caso, nunca demorar los cambios
por más de un día.
10
WELL DON. Extreme Programming: A gentle Introduction: [en línea] http://www.extremeprogramming.org/
65
La integración continua ayuda a detectar problemas de compatibilidad
tempranamente.
En el desarrollo de este proyecto se sigue esta práctica de integración continua, para

así facilitar la integración de todo el desarrollo.
La especificación del desarrollo realizado en este proyecto, se encuentra en el Anexo 6

Anexo6_DocumentacionDesarrollo .
Anexo 6 Página
Documentación de desarrollo .. 147

Componentes desarrollados 147
Capa de 47
Capa
Capa de red s
66
2.5 PRUEBAS
L
de manera sistemática. Por tanto, se debe definir una plantilla para las pruebas del
software (un conjunto de pasos en que se puedan incluir técnicas y métodos especifico
(Pressman, 2006).
L
(Garzon Villar M. Luisa, 2004)
Uno de los pilares fundamentales de Extreme Programming es el proceso de pruebas.

XP anima a probar constantemente tanto como sea posible. Esto permite aumentar la
calidad de los sistemas reduciendo el número de errores no detectados y
disminuyendo el tiempo transcurrido entre la aparición de un error y su detección. (J.J.
Gutierrez)
Extreme Programming divide las pruebas en dos grupos (Beck, 1999): pruebas
unitarias, y pruebas de aceptación o funcionales.
2.5.1 Pruebas unitarias

Las pruebas unitarias constituyen el primer paso para detectar errores en el código,
pues se centran en la menor unidad de diseño del software; el modulo, por ejemplo,
un método de una clase o una clase. (Tuya Javier, 2007) .
Este tipo de pruebas verifican por separado cada porción de código, con el fin de
detectar errores, y corregirlos antes de continuar escribiendo mas código.
2.5.2 Pruebas de aceptación o funcionales

Estas pruebas se realizan para que el cliente certifique que el sistema es válido para él.
(Tuya Javier, 2007)
Estas pruebas se realizan en cada iteración, son pruebas sobre las funcionalidades del
sistema, y se verifican en base a las historias de usuario.
En el siguiente capítulo se detalla el plan de pruebas para éste proyecto.
67
3 CAPÍTULO III: PLAN DE
PRUEBAS
68
3.1 Propósito
Este plan de pruebas tiene el propósito de realizar una evaluación de las

funcionalidades del sistema, de manera que sean correctas y coincidan con los
resultados esperados del proyecto. Además son requeridas para brindar mayor
calidad al producto de este proyecto.
En este plan de pruebas se trata de cubrir los siguientes objetivos:
Identificar la información existente en el proyecto y los componentes que

deben ser testeados.
Presentar los principales requisitos a probar.
Definir las estrategias de prueba que deben emplearse.
Identificar los recursos necesarios que pueden requerirse.
Presentar los resultados de las pruebas.
3.2 Alcance
Las pruebas a realizarse en el sistema son las recomendadas por la metodología de

desarrollo que se ha seguido como referencia (Extreme Programming): Pruebas
unitarias, y pruebas de aceptación o funcionales.
3.2.1 Pruebas unitarias

Las pruebas unitarias se realizaran sobre cada una de las distintas funciones creadas
para los servicios web. Las pruebas se realizaran al final de la creación de cada función
para comprobar que cumple con su objetivo.
3.2.2 Pruebas de aceptación o funcionales

Estas pruebas se realizan en base a los requisitos funcionales del sistema, los mismos
que han sido definidos en las historias de usuario.
69
El objetivo de estas pruebas es identificar fallas funcionales del sistema, las cuales se
producirían al momento de que no se ha satisfecho el requerimiento del usuario de
acuerdo a las especificaciones previamente establecidas.
3.3 Estrategia
El plan de pruebas está dividido en dos partes:
Pruebas unitarias. Para las pruebas unitarias, se hará uso de una herramienta para
automatizar y agilizar el testeo, esta herramienta además debe hacer posible la
obtención de un reporte total de las funciones probadas con la herramienta, y de su
estado.
La herramienta elegida para realizar las pruebas unitarias de los servicios web ha sido
SOAP UI (SmartBear)11.
Esta herramienta nos ayuda a comprobar los resultados de cada función que se crea
como servicio web, brindándonos además el resultado del testeo funcional que nos
permite observar si la función está realizando las operaciones requeridas.
Pruebas de aceptación o funcionales. Este tipo de pruebas se basa en comprobar el

funcionamiento de las operaciones requeridas por el sistema, las mismas que se han
especificado en las historias de usuario. En base a estas historias de usuario se ha
desarrollado un documento de especificación de los casos de prueba para cada una de
las historias de usuario.
El documento de especificación de casos de prueba se presenta en el Anexo 7

Anexo7_EspecificacionCasosdePrueba.docx .
Anexo 7 Página
Especificación de casos de prueba 160
11
SmartBear SOFTWARE; [en línea] <http://www.soapui.org>. [citado en 18 de agosto del 2011]
70
3.4 Recursos
En la siguiente tabla se detalla los recursos necesarios para llevar a cabo la ejecución
de las pruebas.
Recursos Humanos Plan de Pruebas

Nombre Recurso Mínimo de Especificación de responsabilidades
recursos
recomendados
Jefe de Pruebas 1 Dirige el flujo de trabajo.
Responsabilidades:
o Adquirir recursos
o Gestionar informes
Diseñador de Pruebas 2 Identifica, prioriza e implementa casos de

prueba.
Responsabilidades:
o Generar plan de pruebas.
o Evaluar efectividad de las pruebas
realizadas.
Probador 2 Realizar las pruebas.
Responsabilidades:
o Realizar pruebas.
o Registrar los resultados.
Recursos Tecnológicos Plan de Pruebas

Recurso Mínimo de Nombre - Tipo
recursos
recomendados
Servidor 1 Apache/MySQL
Dominio 1 www.glesone.org
Herramienta: SOAP UI 1 Automatización de pruebas unitarias de

servicios web.
Responsabilidades:
o Automatizar pruebas
o Informe de resultados
71
3.5 Cronograma
En la siguiente tabla se especifica las fechas de ejecución de las pruebas,

correspondientes a cada iteración, y a la versión completa del sistema.
Cronograma Plan de Pruebas

Actividad Fecha Inicio Fecha Fin
Definición del plan de pruebas. feb-11-2011 feb-13-2011
Pruebas en iteración 1 mar-11-2011 mar-11-2011
Pruebas en iteración 2 abr-14-2011 abr-14-2011
Pruebas en iteración 3 may-13-2011 may-13-2011
Pruebas en iteración 4 jun-17-2011 jun-17-2011
Pruebas en iteración 5 jul-22-2011 jul-22-2011
Pruebas en iteración 6 ago-26-2011 ago-26-2011
Pruebas en la versión completa ago-29-2011 ago-29-2011
3.6 Resultados
Los resultados de la ejecución de pruebas unitarias de los servicios web usando la
herramienta SOAP UI, se presentan en el anexo 8
A R P UnitariasWS.docx ;
Anexo 8 Página
Resultado de pruebas unitarias de los servicios web 227

T R .. 230
Los resultados de la ejecución de las pruebas funcionales del sistema se encuentran en

el anexo A R P F .docx
Anexo 9 Página
Resultado de pruebas funcionales 234
72
3.7 Manual de Instalación del Sistema
En el manual de instalación, se presenta cada uno de los pasos para integrar las
distintas capas desarrolladas, con la plataforma Moodle, se especifican los detalles
tanto para la instalación den Moodle 1.9.x como en Moodle 2.0.x.
Este manual se adjunta en el A M Instalacion
Anexo 10 Página
Modificaciones en Moodle Para la Implementación de una Capa de Widgets, y una Capa de Red Social mediante
el uso de servicios web alojados en una Capa de Web Services . .
241
Modificaciones en Moodle 1.9.x y Moodle 2.0.x 41
Modificaciones únicamente en Moodle 2.0.x . .. . 44
Instalación del Plugin WSPP_UTPL Para el Uso de Servicios Web.. .. 45
Instalación de wspp_utpl en Moodle 1.9.x .. 45
Instalación de wspp_utpl en Moodle 2.0.x . 46
Configuración del plugin WSPP_UTPL para la adaptación al servidor Moodle sobre el cual se está
instalando (válido para Moodle 1.9.x y 2.0.x) . 246
Instalación de una Capa de Usuario Final Basada en Web Services 247
3.8 Manual de Usuario del Sistema

En el manual de usuario se presentan los resultados del sistema desarrollado en este
proyecto, y una guía para el uso adecuado del mismo.
Se adjunta el manual de usuario del sistema en el anexo 11

A 1_ManualUsuario.docx
Anexo 11 Página
M 250
P P I 51
M W 52
P A 52
Pantalla Curso 53
R S 56
73
4 DISCUSIÓN
74
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.
Se ha considerado sumamente importante la necesidad de incorporar las nuevas

tendencias de la web a la plataforma e-learning Moodle en sus versiones 1.9.x y 2.0.x,
con este objetivo se han desarrollado e implementado tres nuevas capas funcionales
sobre las versiones mencionadas de Moodle, estas capas son: capa de web services,
capa de widgets, y una capa de red social. Con esto se pretende integrar componentes
modernos y eficaces en los sistemas de aprendizaje en línea, particularmente en la
plataforma e-learning Moodle, y así lograr un mejor rendimiento tanto en el proceso
de enseñanza como en el proceso de aprendizaje.
En el inicio de este proyecto se realizó una evaluación de la plataforma Moodle en sus

versiones 1.9.x y 2.0.x para tener conocimiento del entorno en el que se desarrollarían
las nuevas funcionalidades, identificando estándares, diferencias entre cada una de las
versiones, componentes que se reutilizan en ambas versiones, y su arquitectura en
general.
Una vez familiarizado con la plataforma, se definió cuales serían los nuevos
componentes (capas) a incorporarse, estos fueron definidos con la ayuda del equipo
de virtualización de la UTPL, para los cuales se definió además su arquitectura,
integrada con la plataforma Moodle. Luego se estudió la forma en que se iniciaría el
desarrollo de cada uno de los componentes, esto se hizo investigando sobre
tecnologías disponibles que puedan reutilizarse y proyectos pasados que tengan
relación con éste. Se realizó un análisis por separado para cada una de las capas
implementadas, y se seleccionó la opción más conveniente de acuerdo con las
necesidades del proyecto.
En la capa de web services se seleccionó el uso de SOAP, ya que existe un plugin

adaptable a Moodle para este propósito, el mismo que fue incorporado en cada una
de las respectivas versiones de la plataforma, y al que se le agregaron los nuevos
servicios requeridos.
En la capa de widgets se hizo uso de la tecnología Ajax, considerando la presentación

dinámica que estos deben tener, de vista al usuario.
La red social fue desarrollada puramente en php (lenguaje en el que está desarrollado
Moodle), consumiendo los servicios de la capa de web services, y con referencias de la
red social desarrollada en un proyecto anterior, la cual no consume servicios web.
75
Otro aspecto importante a determinar en el proyecto, fue la selección de la
metodología de desarrollo, debido a la naturaleza del proyecto y su desarrollo en un
entorno académico, se consideró conveniente el uso de la metodología extreme
programming, sin embargo se realizó algunas adaptaciones a la misma considerando el
entrono de desarrollo, para que así el proyecto pueda cumplir con las fases y reglas
establecidas.
Las revisiones fueron continuas por el equipo de virtualización, y así mismo la

identificación de problemas en los aplicativos.
Además de las revisiones continuas, se revisó cada plan de entregas establecido, ya al

finalizar todas las fases de desarrollo del proyecto, se realizó las pruebas requeridas a
el proyecto completo.
Además se realizó pruebas del funcionamiento con grupos de estudiantes de la UTPL,

los mismos que luego de usar las funcionalidades de la aplicación, respondieron a un
conjunto de preguntas planteadas para medir la aceptación del sistema realizado en
este proyecto.
El aporte que brinda el proyecto está orientado a los procesos de educación

(enseñanza aprendizaje), dando una nueva visión sobre la educación en línea, en
donde a través de una red social, cada uno de los integrantes de los cursos se puede
compartir información, y no es el profesor el único que brinda esta información como
recurso para el conocimiento. La integración de diferentes elementos por medio de
widgets es otra característica importante, ya que brinda una mejor presentación y una
mejor organización de la información que requiere y necesita el usuario.
Además otro componente importante que brinda este proyecto como aporte a la
educación y a la tecnología, es el desarrollo de servicios para que los datos de una
plataforma de aprendizaje puedan ser consumidos desde cualquier otra aplicación.
Se presenta la incorporación de nuevas características orientadas al uso de la web 2.0,

sobre una popular plataforma e-learning como es Moodle.
Estas nuevas características hacen la plataforma más interactiva, y facilitan el proceso

de familiarización entre el usuario y el sistema, según resultados obtenidos en este
proyecto por medio de la evaluación de los mismos usuarios.
76
5 CONCLUSIONES Y
RECOMENDACIONES
77
5.1 Conclusiones y Recomendaciones
Una vez habiendo finalizado el presente proyecto, y en base a los conocimientos y

experiencias adquiridas, se presentan las siguientes conclusiones y recomendaciones.
5.1.1 Conclusiones
o La colaboración que tecnologías como Ajax han brindado al desarrollo de la

web 2.0 es impresionante, ya que brindan una excelente ayuda a los
desarrolladores de sistemas para transformar sistemas web estáticos a
sistemas web dinámicos e interactivos.
o El uso de la web 2.0 en la educación mejora la interacción entre los sistemas e-

learning y los alumnos, según el 100% de los usuarios que han probado el
producto final de este proyecto.
o La implementación de nuevas características sobre Moodle orientadas a la web

2.0, brindan un aporte significativo e innovador estilo de aprendizaje en línea
en la educación, según un 79% de los usuarios que han probado la plataforma
con las éstas nuevas funcionalidades.
o Las presentación de recursos educativos mediante una interfaz dinámica, como

la de éste proyecto, tienen un impacto positivo para la interacción usuario-
sistema, e incentiva el uso de los entornos virtuales de aprendizaje, según un
96% de los usuarios que han probado la plataforma.
o Una interfaz configurable por el usuario final brinda comodidad y sencillez a la

hora de interactuar con un sistema virtual de aprendizaje, según el 96% de los
usuarios, con lo se logra tener una mayor aceptación por parte de los mismos.
o Hoy en día pocas son las aplicaciones que funcionan aisladas, por esta razón es
una necesidad el hecho de poner los datos a disponibilidad de otras
78
aplicaciones y así intercambiar información, el 96% de los usuarios del sistema
de éste proyecto lo ratifican.
o Ofrecer información que sea accesible desde otras aplicaciones, e incorporar

otros elementos de la web 2.0, tal como se lo ha hecho en este proyecto,
promueve una mayor expansión del sistema e-learning, según la apreciación
del 96% de los usuarios.
o La implementación de una red social dentro de un entorno virtual de

aprendizaje brinda una mayor interactividad entre profesor y estudiante, lo
cual apoya al mejoramiento del proceso de aprendizaje, según la aprobación
del 42% de los usuarios que han calificado de excelente esta iniciativa, y el
58% que la han calificado como buena .
o Con el uso de una red social, y otras características de la web 2.0 dentro de un
entorno virtual de aprendizaje, se logra mayor participación del estudiante, en
relación con los entornos virtuales de aprendizaje clásicos, esto según una
evaluación realizada a los usuarios, en donde se presume que se incrementaría
una participación altamente activa de un 13% a un 67%.
o Este proyecto ha generado expectativas en los usuarios, por lo que se cree

conveniente darle continuidad, el 92% de los usuarios que lo han probado así lo
han considerado.
o La innovación es fundamental para el avance en la educación, se requiere de

una evolución de los sistemas de aprendizaje para brindar una mayor calidad
en cuanto al estilo de aprendizaje.
Las conclusiones han sido obtenidas en base a una evaluación realizadas a los usuarios
que han probado el sistema resultado de este proyecto, ver anexo 12.
79
5.1.2 Recomendaciones
Se pone a consideración las siguientes recomendaciones:
o Promover el uso del sistema entre la comunidad de estudiantes y profesionales

que hacen uso de los entornos virtuales de aprendizaje.
o Continuar la extensión del sistema, de manera que pueda brindar muchas más
funcionalidades en un futuro, y así lograr cada vez una mejor formación de
profesionales, por medio del uso de entornos virtuales de aprendizaje.
o Continuar con el desarrollo de más servicios que se puedan poner a disposición

de aplicaciones externas.
o Realizar desde aplicaciones externas (Distintas a Moodle) el consumo de los

servicios puestos a disponibilidad desde la plataforma de aprendizaje Moodle,
tanto para información del curso como de la red social, los mismos que ya han
sido usados en este proyecto desde la misma plataforma de aprendizaje
Moodle.
o Estudiar la posibilidad de implementación de una tecnología que realice la

comunicación iniciada desde el servidor, para ofrecer recursos a los clientes, y
así lograr una comunicación en tiempo real especialmente en la presentación
de la red social.
o Realizar extensiones que interactúen con sistemas más grandes, para así lograr
incentivar el uso masivo del sistema.
o No discontinuar la adaptación de las nuevas capas desarrolladas para Moodle

en versiones posteriores a la 1.9.x y 2.0.x, en caso de haber cambios en la
estructura de la plataforma.
80
TRABAJOS FUTUROS
Como líneas de continuación de este trabajo se propone lo siguiente:
Realizar la implementación de servicios, en donde la comunicación sea iniciada

por el servidor y así evitar una carga excesiva por parte de actualizaciones
constantes solicitadas por las aplicaciones cliente, especialmente para la
implementación de chat y red social.
Gestionar la presentación de cursos abiertos, integrados con los servicios
realizados en este proyecto.
Adaptación de la aplicación para dispositivos móviles.
Incorporación de un sistema de aulas virtuales, como una aplicación más, que
pueda agregarse o quitarse en un widget.
81
BIBLIOGRAFÍA
 Beck, K. (1999). Extreme Programming Explained.
 Burgos, E. (2009). Claves del nuevo marketing. Como sacarle partido a la Web 2.0.
Barcelona: Ediciones Gestión 2000.
 E. Leiva, J. P. (2006). Sistemas y Aplicaciones Informáticas. Madrid: EDITORIAL MAD,

S.L.
 Fernandez, G. (2002, 12 9). Universidad de Castilla-La Mancha. Retrieved 02 2011,

from http://www.info-
ab.uclm.es/asignaturas/42551/trabajosAnteriores/Presentacion-XP.pdf
 Garzon Villar M. Luisa, S. M. (2004). Informatica. Volumen II. Madrid: EDITORIAL MAD,
S.L.
 J.J. Gutierrez, M. E. Pruebas del sistema en programacion extrema.
 Jaramillo E, R. A. (2010). CREACIÓN DE UNA RED SOCIAL DE APRENDIZAJE (RSA) PARA

UN ENTORNO VIRTUAL DE APRENDIZAJE (EVA). Universidad Técnica Particular de Loja,
Unidad de Virtualización. Loja: UTPL.
 Joskowicz, J. (2008). Reglas y Prácticas en Extreme Programming.
 Kaar, C. (2007). An Introduction to Widgets with Particular Emphasis on Mobile

Widgets. Austria: University of Applied Sciences.
 NewComer, E. (2002). Understanding Web services: XML, WSDL, SOAP, and UDDI.
Indianapolis: PEARSON EDUCATION.
 Patrick, P. (2007). Premier Cycle. Retrieved febrero 2011, from http://cipcnet.insa-

lyon.fr/Members/ppollet/public/moodlews
 Pressman, R. S. (2006). INGENIERÍA DE SOFTWARE. UN ENFOQUE PRÁCTICO. México:

Edamsa.
 SmartBear. (n.d.). SmartBear Software. Retrieved agosto 11, 2011, from

http://www.soapui.org
 Sommerville, I. (2005). Ingeniería del Software. Madrid: PEARSON EDUCACIÓN.
 Tuya Javier, R. I. (2007). Tecnicas cuantitativas para la gestion en la ingenieria del

software. Gesbiblo, S. L.
82
OTRAS REFERENCIAS
i
W3C (WORLD WIDE WEB CONSORTIUM). Widget Requirements. [en línea].
<http://www.w3.org/TR/widgets-reqs/> [citado en 14 de marzo del 2011]
ii
DOJOTOOLKIT. Rich UI Widgets. [en línea]. <http://dojotoolkit.org/widgets> [citado
en 14 de marzo del 2011]
iii
YAHOO. YUI 3: Widget. [en línea]. <http://developer.yahoo.com/yui/3/widget/>
[citado en 14 de marzo del 2011]
iv
PROTOTYPEJS. Prototypejs Framework. [en línea]. <http://www.prototypejs.org>
v
SCRIPTACULOUS. script.aculo.us Framework. [en línea]. <http://script.aculo.us/>
vi
GROSJEAN Sébastien. Prototype Portal Class. [en línea].
<http://blog.xilinus.com/2007/8/26/prototype-portal-class>[citado en 14 de marzo del
2011]
vii
MOOTOOLS. Mootools Framework. [en línea]. <http://mootools.net/>[citado en 14
de marzo del 2011]
viii
NUNZIO FIORE, COSMOBILE , NETCOMM. iMoogle Portlet. [en línea].
http://www.moonkiki.com/moonkiki/imoogle/ [citado en 14 de marzo del 2011]
ix
JQUERY. jQuery Framework .[en línea].http://jquery.com. [citado en 14 de marzo del
2011].
x
. JPOLITE. A Lightweight Portal Framework based on jQuery . [en línea].
<http://code.google.com/p/jpolite2/> [citado en 14 de marzo del 2011].
83
ANEXO 1: TEST DE CLIENTE
WSPP
84
1.1.1 Test de Cliente WSPP
Para la creación de un cliente del plugin de Web Services se ha hecho uso de una
1
, la cual nos sirve para generar gran
parte del código del cliente.
Uso de wsdl2php
Para el correcto funcionamiento de wsdl2php es necesario realizar lo siguiente:
1. Ubicar el archivo wsdl2php.php en un directorio del cliente.

2. Desde la línea de comandos ejecutar:
php ./wsdl2php.php
http://direccionservidormoodle/wspp/wsdl_pp.php
2
En el caso dado que se esté en el cliente (como es este caso), se
debe tener en cuenta las rutas tanto del servidor como de los archivos del cliente al
momento de ejecutar el script desde la línea de comandos.
En este caso, en el que se está usando xampp bajo el sistema operativo Windows, se
ejecutaría de la siguiente manera:
Se abre la ventana de comando de Windows

Nos ubicamos en el directorio php dentro de la carpeta de instalación de
Ejecutamos el script. Tal como podemos verlo en la siguiente figura:

C:\xampp\php> php c:\xampp\htdocs\ClientMoodle\wsdl2php.php
http://sudireccionmoodle/wspp/wsdl_php.php
Si está trabajando desde Linux, sería:
$ php /opt/lampp/htdocs/ClientMoodle/wsdl2php.php
http://sudireccionmoodle/wspp/wsdl_php.php
1
Véase: [En línea].<http://www.urdalen.no/wsdl2php/manual.php>[citado en 21 de febrero del 2011]
2
Véase: [En línea].<http://www.apachefriends.org/es/xampp.html>[citado en 21 de febrero del 2011]
85
Con esto se crean dos s
útiles con archivos php que contienen las operaciones disponibles del servicio SOAP,
dentro del directorio clases encontramos un archivo muy importante llamado
M W“ las operaciones del servicio SOAP en forma de
métodos, para que sean usados por el cliente, por lo que necesariamente debe ser
importado en el cliente3 D
de los clientes para las diferentes funciones brindadas por el servicio.
En este punto ya podemos escribir nuestra parte del cliente php, en el cual podemos
obtener cualquiera de los servicios proporcionados por Moodle mediante SOAP.
El cliente que se presenta aquí es una simple muestra para obtener los usuarios de
moodle, a continuación se mencionan algunas partes importantes del código:
Importar la clase generada MoodleWS.php

require_once('classes/MoodleWS.php');
Autenticación con un usuario válido de moodle
$lr= $moodle->login("usuario","password");
M M W
cual nos devuelve un array con los usuarios desde el servido Moodle a través
del protocolo SOAP.
$users=$moodle->get_users($lr->client,$lr->sessionkey,NULL,NULL);
Bueno, una vez obtenidos los usuarios en una estructura de php, nos queda
únicamente presentarlos de la forma que querramos, y listo, así nos facilita las
Al final lo que hacemos es cerrar la sesión
$moodle->logout($lr->client,$lr->sessionkey);
Nota: En este caso se ha construido el cliente en PHP, pero como sabemos, al usar SOAP
podemos consumir los recursos desde cualquier otro lenguaje de programación con soporte
para SOAP, que son la mayoría, por ejem J P N
3
Véase: [En línea].<http://docs.moodle.org/en/Web_Services:OK_Tech_Web_Services>[citado en 21 de febrero del 2011]
86
Presentación de Resultados
En la siguiente figura se presentan algunos de los resultados presentados en el lado del

cliente desarrollado en el lenguaje de programación php, consumiendo algunas
funciones:
Ilustración 2 Datos presentados en el cliente (Aplicación Externa)
Los resultados presentados son algunos servicios obtenidos mediante Web Services
haciendo uso del plugin wspp.
87
ANEXO 2: WS Moodle 2.0
88
1.1.1 Web Services en Moodle 2.0.x
En moodle 2.0.x viene implementado un módulo de forma nativa para trabajar con Web
Services.
Este Web Service trabaja de la siguiente manera1:
El cliente envía un nombre de usuario y contraseña hacia el Web Service.

El Servidor retorna un token de sesión para la cuenta del usuario (la forma en que se lo
envía depende del protocolo).
El cliente llama a una función particular del servicio web incluyendo el token de sesión.
El servidor usa el token para verificar si la sesión del servicio web aún está activa.
El servidor llama a la función solicitada, ubicada en el archivo externallib.php dentro
del modulo relevante.
La función externa verifica que el actual usuario tiene la capacidad para realizar esa
operación.
La función externa llama a la función interna de moodle solicitada (usualmente en
lib.php)
La función interna puede devolver el resultado a la función externa.
La función externa devolverá el resultado al protocolo del servidor.
El servidor devuelve el resultado al cliente.
1.1.2 Arquitectura Interna

La arquitectura presentada en la siguiente gráfica representa la implementación de los
servicios web dentro del núcleo de moodle, podemos observar una capa de conexión
(Connectors), una de funciones externas (External), y una de funciones internas (Core). Con
esta arquitectura representada gráficamente se puede observar con facilidad que la capa
superficial de los servicios web (que es la que recibe las conexiones de los clientes) se
comunica con las funciones internas de moodle por medio de una capa intermedia que
contiene las llamadas funciones externas2.
1
Véase: [en línea]. http://docs.moodle.org/en/Development:Web_services#Web_services_technical_documentation>[citado
en 21 de febrero del 2011]
2
Véase: [en linea].<http://blogs.dfwikilabs.org/pigui/2009/04/27/moodle-20-web-services-architecture>[citado en 21 de
febrero del 2011]
89
3
Arquitectura Interna de Los SW en Moodle 2.0.x
Ilustración 1 Arquitectura Interna de Los SW en Moodle 2.0.x
1.1.3 Restricciones de los Web Services

Aún no se encuentra completamente implementada la parte de servicios web en moodle, una
limitación se puede observar en que no están disponibles todas las funciones de moodle para
que puedan ser consumidas por un cliente, sea mediante SOAP, RST o XML-RPC, y otra es que
los servicios no pueden ser consumidos directamente por clientes desarrollados en Java y/o en
la plataforma .Net.
La última limitación mencionada es debido a que no se tiene un XML o WSDL para el formateo
de los mensajes, sin embargo no hay mayores dificultades al desarrollar un cliente en el
lenguaje de programación PHP ya que dentro del núcleo de moodle se está haciendo uso de un
PHP Z cer una
comunicación transparente, ya que dicho framework el WSDL requerido por el cliente.
1.1.4 Activación de los Web Servicesi

Para activar el Servicio Web en moodle 2.0.x se necesitan hacer unas cuantas configuraciones,
dichas configuraciones las debe hacer el administrador del sistema.
En moodle 2.0.x se activa el servicio para un sistema externo específico, durante la

configuración ser generará un token como identificador del sistema externo, el cual deberá
usar dicho token para autenticarse frente al Web Service de moodle, eliminándose así la
necesidad de ingresar una clave de seguridad personal.
Véase: 3 [en linea]< http://blogs.dfwikilabs.org/pigui/2009/04/27/moodle-20-web-services-architecture>[citado en 21 de febrero

del 2011]
90
A continuación se describe el proceso para la activación y uso de los servicios web en la versión
2.0.x de moodle:
1.- Ingresamos con una cuenta de administrador. Nos dirigimos al panel de Ajustes >>
A “ C A H
Ilustración 2 Habilitación de servicios web
2.- Para poder usa los servicios web desde aplicaciones externas, además se deben
activar los protocolos que se van a utilizar para el servicio (SOAP, REST, XMLRPC, AMF, ...) de
acuerdo a la necesidad. Para ello desde el panel de Ajustes nos dirigimos a Administración del
Sitio >> Extensiones >> Servicios Web >> Administrar Protocolos, y habilitamos los que
necesitemos.
Ilustración 3 Habilitar protocolos para el servicio web
N D
esto es importante ya que pone a disponibilidad de cada usuario externo importante
documentación sobre el servicio, la cual es especialmente útil para desarrolladores de clientes
del servicio web.
3.- En moodle no viene un servicio web por defecto, por lo que es necesario crear uno
personalizado, es decir, seleccionar cual de las funciones del servicio web estándar estarán
disponibles a través de este servicio, para ello desde el panel de ajustes nos dirigimos a
91
Administración del Sitio >> Extensiones >> Servicios Web >> Administrar Protocolos, y damos
clic en Agregar. Nos aparecerá un formulario como el de la siguiente figura:
Ilustración 4 Agregar un servicio externo
E N
H Ú
queremos agregar manualmente los usuarios autorizados, y si está desmarcada quedarán
autorizados todos los usuarios con permisos apropiados. Luego seleccionamos el botón
A
Con esto nos lleva a una ubicación donde aparece una opción para agregar funciones al
servicio, como en la figura siguiente:
Ilustración 5 Agregar funciones al servicio
4.- El siguiente paso es añadir funciones al servicio, para que sean usadas por la
“ A
anterior. Esto nos llevará a una ubicación en donde podemos seleccionar las funciones que
tendrá disponibles nuestro servicio web. Seleccionamos las necesarias, ya damos clic al botón
A
Ilustración 6 Seleccionar funciones para el servicio
92
Entonces se mostrarán la lista de funciones del servicio, y frente a cada función el campo
R requieren los usuarios para ejecutar
esa función.
Los permisos que tienen los usuarios están definidos en el rol al cual están asignados.
Importante: Una capacidad que debe tener el usuario es la de usar algún protocolo del servicio
web (SOAP, REST, XMLRPC, AMF, ...), para ello en el rol asignado al usuario (es recomendable
crear uno nuevo a los existentes), debe estar permitido usar el protocolo.
Ilustración 7 Permiso para usar el protocolo del WS
Para revisar las capacidades que tiene el usuario, desde el panel Ajustes no dirigimos a
Administración del sitio >> Usuarios >> Compruebe los permisos del sistema. En este punto
nos aparece la lista de usuarios del sistema, seleccionamos el usuario del sistema externo que
M
aparece la lista de permisos de dicho usuario.
En dicha lista, uno de los principales permisos que debemos revisar, es el soporte para usar el
protocolo del servicio web, en la figura siguiente podemos ver que el usuario tiene permiso
para usar el protocolo SOAP:
Ilustración 8 Usuario con permiso para usar el protocolo SOAP
5.- Una vez hecho esto se crea el usuario del sistema externo. Para ello, desde el panel
de ajustes nos vamos a Administración de Sitio >> Usuarios >> Cuentas >> Agregar Usuario,
llenamos los datos necesarios y agregamos el usuario del sistema externo que consumirá los
servicios.
6.- Luego de esto debemos autorizar al usuario creado anteriormente para que pueda
acceder a los servicios. Para ello, desde el panel de Ajustes nos dirigimos a Administración del
Sitio >> Extensiones >> Servicios Externos.
En este punto nos aparecerá el servicio que habíamos creado anteriormente, en una
presentación similar a la que se puede observar en la siguiente figura:
93
Ilustración 9 Información de los servicios externos existentes
D U U
un lugar en donde seleccionaremos el usuario del sistema externo.
“ A
queda autorizado para usar las funciones correspondientes al servicio que tiene asignado.
Ilustración 10 Agregar usuario para uso del servicio
7.- El siguiente paso es la asignación del token. Dicho token será usado por el sistema
externo para autenticarse al momento que necesite hacer uso del servicio web de moodle.
Para este objetivo, desde el panel de ajustes nos dirigimos a Administración del Sitio >>
Extensiones >> Servicios Web >> Administración de Tokens.
E A
página en donde debemos seleccionar el nombre del usuario, y el servicio web que se podrán
comunicar, guardamos los cambios y nos genera un token para el usuario seleccionado, este
usuario lógicamente será el usuario del sistema externo, el cual usará el token para
autenticarse frente al servicio web.
Ilustración 11 Token generado para el usuario del sistema externo
94
1.1.5 Test de un Cliente
En moodle 2.0.x se presenta una importante funcionalidad para comprobar la correcta

configuración del módulo de Web Services. Esta funcionalidad consiste en la simulación de un
cliente del Web Service proporcionando todas las funcionalidades disponibles para dicho
clientes (el cliente registrado como usuario del sistema externo), verificando restricciones y
presentando resultados.
Para realizar esta prueba del cliente, desde el panel de Ajustes nos dirigimos a Administración
del Sitio >> Desarrollo >> Testeo del Cliente Web Service.
Esto nos lleva a una página en donde nos pide seleccionar tres parámetros, estos son:
Método de Autenticación.- Puede ser Simple (proporcionando un usuario y

contraseña), o usando el token generado.
Protocolo.- El protocolo que usa el Servicio Web (SOAP, REST, XML-RPC)
Función.- Una función ofrecida por moodle (El usuario del servicio debe tener los
privilegios para ejecutar dicha función seleccionada)
En la siguiente figura se muestra la página de solicitud de éstos parámetros:
Ilustración 12 Parámetros para testeo del WS
Con esto, si el Servicio Web está funcionando correctamente, entonces nos devuelve los datos
requeridos de la función solicitada, lo que significa que el cliente puede hacer uso sin ningún
problema de las funciones a las cuales tiene privilegios de acceso.
En el caso de fallar la autenticación (simple o token), seleccionar un protocolo no asociado al

usuario, o elegir una función de la cual no tiene privilegios, obtendremos entonces el error
correspondiente.
95
Una vez que se ha pasado esta prueba, es posible entonces crear un cliente real que consuma
los recursos ofrecidos por el servicio web. Como se dijo anteriormente, la versión de moodle
2.0.x actualmente no proporciona las funcionalidades del servicio web al cien por ciento, sin
embargo se pueden escribir los clientes usando el lenguaje PHP y la librería Zend para realizar
una comunicación transparente con el servicio de moodle.
No obstante, existe también la posibilidad de escribir funciones nuevas para el servicio web de
moodle (las que aún faltan), y de definir un archivo WSDL con los mensajes de cada función,
con lo que se podría escribir clientes también en otros lenguajes de comunicación como Java y
en la plataforma .Net.
96
ANEXO 3: JPOLITE
97
JPolite(jQuery Portal Lite)
JPolite es un framework para construcción de portales web, basado en jQuery y Blue

Trip CSS, con un conjunto de plugins jQuery integrados. Provee una base compacta y
potente para aplicaciones web basadas en AJAX. Está inspirado en Netvibesi (El portal
web personalizado).
JPolite es un framework OpenSource disponible para uso personal y/o comercial,

basado en licencias MIT y GPL, el desarrollador puede elegir la que mejor se adapte a
su conveniencia.
Características
Está diseñado para Aplicaciones Web Dinámicas a través de un uso intensivo de
Ajax.
Fácil de extender y personalizar, trae posibilidades prácticamente ilimitadas.
Está construido con un Estilo de Arquitectura REST, lo que significa que puede
integrarse con un servidor REST.
Se puede elegir entre diferentes temas o estilos, lo que lo hace más atractivo a
los usuarios finales.
Los desarrolladores pueden hacer uso de diversas tecnologías y frameworks del
lado del servidor para generar contenido para el portal.
Tecnologías Usadas
jQuery.- Probado con la versión 1.3.2.

jQuery UI.- Probado con la versión 1.7.2.
Navegadores.- Probado con: IE8 & IE7, Firefox 3.5, Chrome 2, Safari 4, Opera
10
Arquitecturaii
En la siguiente figura se presenta una vista general de la arquitectura de desarrollo
usada por JPolite.
98
Ilustración 1 Arquitectura de Desarrollo de JPolite
1. Single Page Application
JPolite es esencialmente una única página que interactúa con el servidor a través de
Ajax.
Capa XDO (XML Data Objects) .- Maneja las solicitudes a los recursos del
servidor, así como la presentación de los controles apropiados para cada uno de los
módulos. Proporciona una caché de datos local para mejorar el tiempo de respuesta al
usuario y para guardar las solicitudes duplicadas que se hace al servidor.
XDO está diseñado bajo el estilo de arquitectura REST que requiere

hipervínculos en la representación de los recursos con el fin de descubrir nuevos
recursos. El núcleo puede trabajar con varios conjuntos de recursos REST, siempre y
cuando se enlacen unos con otros. El desarrollador solamente debe trabajar en la
parte de personalización, definiendo dónde y cómo se van a presentar los datos.
2. Thin Server
Se puede hacer solicitudes a recursos dinámicos que se encuentren en un servidor de
PHP J P R
únicamente datos, sin HTML. Así el servidor no es responsable de la presentación de
los datos por lo que se puede hacer más liviano el trabajo del servidor, así la lógica
T “
3. Backend
Backend representa a los datos y/o recursos que hace uso el servidor, que pueden ser
bases de datos, archivos u otros servicios web.
99
Como se puede notar JPolite sigue el patrón de arquitectura de software MVC (Modelo
Vista Controlador). Según (Sommerville, 2005) E MVC
propuesto originalmente en la década de los 80 como una aproximación al diseño de
GUIs que permitió múltiples presentaciones de un objeto y estilos independientes de
interacción con cada una de éstas presentaciones . El marco MVC soporta la
presentación de datos de diferentes formas, e interacciones independientes con cada
una de éstas presentaciones. Cuando los datos se modifican a través de una de las
En la arquitectura de JPolite se ha representado el MVC de la siguiente manera:
B Modelo
“ P A Vista
T “ Controlador
100
ANEXO 4: HISTORIAS DE
USUARIO
101
Historias De Usuario Identificadas
Las historias de usuario para el presente proyecto han sido clasificadas en cuatro
partes para su mayor comprensión.
Historias de usuario: Compartición de contenidos usando Web Services.

(Moodle 1.9.x)
Historias de usuario: Presentación de una interfaz dinámica al usuario final.

(Moodle 1.9.x)
Historias de usuario: Desarrollo de una capa de Red Social de Aprendizaje (RSA)

e integración dentro de una interfaz dinámica. (Moodle 1.9.x)
Adaptación de todo el desarrollo en Moodle 1.9.x a Moodle 2.0.x.
Historias de Usuario: Compartición de contenidos usando Web Services.

Tradicionalmente, hasta la versión 1.9.x de moodle, no existía una
implementación incorporada para el uso de web services con el fin de
compartir contenido creado y/o generado desde la plataforma e-learning. En
la vesión de 2.0.x de moodle existe una implementación de dicho servicio, sin
embargo aún se encuentra en una fase inicial y además se lo debe adaptar y
configurar sobre la plataforma por lo que no se ha considerado usar dicha
implementación.
Lo que se requiere es consumir las funcionalidades de Moodle a través de

servicios Web, o sea que estén disponibles en formato XML, de modo que
puedan ser consumidos por cualquier aplicación.
Las Historias de usuario extraídas para este objetivo son:

Autenticación de un usuario de Moodle por medio de servicios web.
Presentación de los cursos correspondientes a un usuario, sea este
estudiante o profesor, identificando a que categoría pertenece cada
uno de los cursos.
102
Presentación de los participantes de cada curso correspondiente al
usuario identificado, identificando si es estudiante o profesor del
curso.
Presentación de los anuncios hechos por el profesor en un curso.
En caso de tener rol de profesor en el curso, permitirle agregar nuevos
anuncios, y editarlos.
Presentar una lista de tareas del curso, en caso que el usuario tenga rol
de profesor permitirle agregar nuevas tareas, y también permitirle ver
las tareas subidas por los estudiantes.
Presentar la lista de foros del curso, si el usuario es profesor permitirle
agregar nuevos foros y discusiones, si es estudiante solo permitirle
agregar comentarios a las discusiones.
Presentar una lista de los recursos disponibles en un curso.
Presentar una lista de cuestionarios disponibles en el curso.
Presentar una lista de los usuarios que se encuentran conectados en el
sistema.
Presentar una lista de los contactos de un usuario.
Permitir a hacer una búsqueda de los usuarios del sistema
Presentar los mensajes recibidos de un usuario.
Permitir enviar un mensaje privado a cualquiera de los contactos del
usuario, o a los participantes de un curso en el que participa.
103
Historia de Usuario
Historia: Autenticación de un usuario de Moodle por medio de servicios web
ID:1 Importancia: 600
Descripción:
Realizar la autenticación de un usuario de Moodle desde una interfaz distinta a la

tradicional de moodle, usando servicios web.
Observaciones: Usando servicios web. Uso de la librería wsdl2php para cliente php
Historia de Usuario
Historia: Presentación de los cursos correspondientes a un usuario, sea este
estudiante o profesor, identificando a que categoría pertenece cada uno de los cursos
Descripción:
Una vez que el usuario se ha autenticado, presentar una lista de todos los cursos en los
cuales el usuario tiene rol de estudiante o profesor. Los cursos se deben agrupar de
acuerdo a la categoría a la que pertenezcan.
Observaciones: Usando servicios web.
104
Historia de Usuario
Historia: Presentación de los participantes de cada curso correspondiente al usuario
identificado, identificando si es estudiante o profesor del curso
Descripción:
Para cada uno de los cursos del usuario, presentar los participantes de dicho curso,
clasificando los que tienen rol de profesor, y los que tienen rol de estudiante.
Historia de Usuario
Historia: Presentación de los anuncios hechos por el profesor en un curso
Descripción:
Para cada uno de los cursos del usuario, presentar los anuncios que ha hecho el
profesor.
105
Historia de Usuario
Historia: En caso de tener rol de profesor en el curso, permitirle agregar nuevos
anuncios, y editarlos
Descripción:
Identificar el rol que tiene el usuario en cada curso, y para los que tenga rol de
profesor, permitirle agregar nuevos comentarios, y además editar los existentes.
Historia de Usuario
Historia: Presentar una lista de tareas del curso, en caso que el usuario tenga rol
de profesor permitirle agregar nuevas tareas, y también permitirle ver las tareas
subidas por los estudiantes.
Descripción:
Identificar el rol del usuario en cada curso, si tiene rol de estudiante, únicamente
presentarle una lista de las tareas que ha colocado el profesor, y en caso de tener rol
de profesor, permitirle agregar nuevas tareas, y para cada tarea ver los recursos
subidos por los estudiantes.
106
Historia de Usuario
Historia: Presentar la lista de foros del curso, si el usuario es profesor permitirle
agregar nuevos foros y discusiones, si es estudiante solo permitirle agregar
comentarios a las discusiones.
Descripción:
Identificar el rol del usuario en cada curso, si tiene rol de estudiante, permitirle ver la
lista de foros, acceder a las discusiones del foro, y participar con comentarios en las
discusiones, en caso de que el usuario tenga rol de profesor, permitirle además
agregar nuevos foros en el curso, y nuevas discusiones para los foros del curso.
Además el usuario debe tener la opción de eliminar los comentarios que él haya
realizado en las discusiones.
Historia de Usuario
Historia: Presentar una lista de los recursos disponibles en un curso.
Descripción:
Presentar a los usuarios los recursos disponibles en cada uno de los cursos en los
cuales participa, tales como documentos, o enlaces hacia páginas web.
107
Historia de Usuario
Historia: Presentar una lista de cuestionarios disponibles en el curso.
Descripción:
Presentar a los usuarios los cuestionarios agregados en cada uno de los cursos en los
cuales participa.
Historia de Usuario
Historia: Presentar una lista de los usuarios que se encuentran conectados en el
sistema.
Descripción:
Presentar a cada usuario que ha ingresado al sistema, toda la lista de usuarios que se
encuentran conectados en ese momento al sistema.
108
Historia de Usuario
Historia: Presentar una lista de los contactos del usuario.
Descripción:
Presentar a cada usuario una lista con la información de otros usuarios, que están en la
lista de sus contactos.
Historia de Usuario
Historia: Permitir a hacer una búsqueda de los usuarios del sistema
Descripción:
Presentar a cada usuario identificado la posibilidad de buscar otro usuario del sistema
por medio de su nombre o apellido, en caso de encontrar resultados en la búsqueda
presentarlos al usuario, caso contrario presentar un mensaje indicando que no se
encontraron resultados.
109
Historia de Usuario
Historia: Presentar los mensajes recibidos de un usuario.
Descripción:
Presentar una lista con los mensajes que han sido enviados al usuario actualmente
identificado, presentando además el nombre del usuario del cual proviene el mensaje.
Historia de Usuario
Historia: Permitir enviar un mensaje privado a cualquiera de los contactos del
usuario, o a los participantes de un curso en el que participa
Descripción:
Dar la opción de que el usuario pueda enviar un mensaje privado, a cualquiera de sus
contactos, y a los participantes de un curso al cual pertenece.
110
Historias de Usuario: Mejoramiento de la presentación al usuario final a través de
una interfaz dinámica.
La presentación de contenido tradicionalmente en Moodle, es por medio de
bloques estáticos, razón por la que la apariencia de Moodle es estática y poco
personalizable a la interfaz del sistema.
Lo que se requiere es una presentación dinámica de la interface al usuario
final.
Las historias de usuario extraídas para éste propósito son:
Presentar el contenido en pantallas pequeñas que se puedan mover
sobre la ventana del navegador.
Fijar estas pantallas pequeñas a distintos bloques dentro de la página,
de manera que aparezcan ordenadamente.
Minimizar, maximizar, actualizar y cerrar las pantallas pequeñas con su
contenido.
Presentar un menú de con las pantallas movibles disponibles y que se
puedan agregar a la ventana inicial del navegador.
Presentar la información de Moode obtenida mediante Web Services,
en las pantallas movibles dentro del navegador.
Historia de Usuario
Historia: Presentar el contenido en pantallas pequeñas que se puedan mover
Descripción:
Crear una interfaz dinámica para presentación de distintos recursos de Moodle en

diferentes pantallas pequeñas dentro de la ventana principal del navegador.
Observaciones:
111
Historia de Usuario
Historia: Fijar estas pantallas pequeñas a distintos bloques dentro de la
página, de manera que aparezcan ordenadamente.
Descripción:
Las pantallas pequeñas movibles dentro de la ventana del navegador deben

aparecer ordenadas adecuadamente, de manera que no pueda haber una sobre
otra, sino que se acoplen a distintos bloques según los manipule el usuario.
Observaciones:
Historia de Usuario
Historia: Minimizar, maximizar, actualizar y cerrar las pantallas pequeñas con
su contenido
Descripción:
Las pantallas pequeñas movibles deben tener la capacidad de hacerse más

pequeñas para ocultar su contenido, de maximizarse para presentar en la
pantalla completa, y de cerrarse.
Observaciones:
112
Historia de Usuario
Historia: Presentar un menú de con las pantallas movibles disponibles y que
se puedan agregar a la ventana inicial del navegador
Descripción:
Las pantallas pequeñas movibles deben presentarse en una lista, de donde se

puedan agregar a la ventana del navegador.
Observaciones:
Historia de Usuario
Historia: Presentar la información de Moodle obtenida mediante Web
Services, en las pantallas movibles dentro del navegador
Descripción:
Dentro de las pantallas movibles presentar información que normalmente se

presenta en bloques en moodle, esta información debe ser la obtenida mediante
Web Services.
Observaciones:
113
Historias de usuario: Desarrollo de una capa de Red Social de Aprendizaje (RSA) e
integración dentro de una interfaz dinámica.
De manera similar a la red social de aprendizaje implementada actualmente sobre

Moodle en Glesone, se requiere el desarrollo e implementación de una capa de red
social que se integre con la presentación dinámica al usuario final y sea gestionada
mediante servicios web. Toda la gestión de RSA debe adaptarse a la interfaz dinámica
mediante pantallas configurables dentro de la pantalla principal del navegador.
Las historias de usuario extraídas para éste propósito son:
Presentar un espacio donde el usuario pueda agregar post, los cuales

se compartirán con todos sus contactos.
Presenta un listado de los post realizados del usuario, y también los
realizados por parte de sus contactos.
Permitir agregar comentarios en los posts de su red, ya sean de sus
contactos, o los suyos propios.
Permitir eliminar sea posts o comentarios que sean de propiedad del
usuario identificado.
Permitir ingresar al muro de los contactos de su red.
P M
esta opción el usuario dueño del post o comentario recibirá una
notificación que ha dicho usuario le ha gustado su anuncio.
Presentar una lista de notificaciones con las actividades que se ha
realizado relacionadas con su red social.
Presentar de los usuarios bloqueados.
Permitirle al usuario enviar invitaciones de amistad a otros usuarios del
sistema, y permitirle bloquearlos o desbloquearlos.
Presentar para cada curso un espacio donde se gestionen posts y
comentarios que sean accesibles solamente a los participantes del
curso.
114
Historia de Usuario
Historia: Presentar un espacio donde el usuario pueda agregar post, los cuales se
compartirán con todos sus contactos
ID: 20 Importancia: 600
Descripción:
Dar al usuario un espacio dentro de una pantalla de la interfaz dinámica la opción de

agregar posts o anuncios que quiera compartir con sus contactos del sistema.
Historia de Usuario
Historia: Presenta un listado de los post realizados del usuario, y también los
Descripción:
Presentar al usuario todos los posts realizados por sus contactos, y los suyos propios
dentro de la interfaz dinámica.
115
Historia de Usuario
Historia: Permitir agregar comentarios en los posts de su red, ya sean de sus
Descripción:
A cada post darle la opción de agregar comentario, podrán hacerlo los contactos del
dueño del post, y el propietario del post. Estos comentarios se guardaran relacionados
al post correspondiente para luego ser presentados juntos al mismo.
Historia de Usuario
Historia: Permitir eliminar sea posts o comentarios que sean de propiedad del usuario
identificado.
Descripción:
Si el usuario identificado es el dueño de cualquiera de los post o comentarios que

aparecen dentro de su red, éste entonces debe tener la opción de eliminarlos.
116
Historia de Usuario
Historia: Permitir ingresar al muro de los contactos de la red del usuario
Descripción:
Al momento de dar clic sobre la imagen del post de un usuario, se deberá mostrar el
muro del dueño del post, esto es todos los posts y comentarios relacionados con dicho
usuario.
Historia de Usuario
Historia: Presentar M
opción el usuario dueño del post o comentario recibirá una notificación que ha dicho
usuario le ha gustado su anuncio.
Descripción:
Todos los posts y comentarios deben tener la opción “Me gusta”, de esa manera
cuando alguien use esta opción se le avisará al usuario dueño del post o comentario,
que al usuario que usa esa opción le ha gustado uno de sus anuncios.
117
Historia de Usuario
Historia: Presentar una lista de notificaciones con las actividades que se ha realizado
relacionadas con su red social
Descripción:
Presentar al usuario identificado una lista con las notificaciones por movimientos en su
red social, por ejemplo alguien publicó en su muro, a alguien le gustó uno de sus
anuncios, o alguien comentó un post suyo.
Historia de Usuario
Historia: Presentar de los usuarios bloqueados.
Descripción:
Presentar al usuario identificado una lista con los usuarios que han sido bloqueados
por él mismo.
118
Historia de Usuario
Historia: Permitirle al usuario enviar invitaciones de amistad a otros usuarios del
sistema, y permitirle bloquearlos y eliminarlos.
Descripción:
Dar la opción de que el usuario pueda enviar invitaciones a otros usuarios que aún no
están entre sus contactos, si ya se encuentra entre sus contactos permitir bloquearlo, y
eliminarlo.
Historia de Usuario
Historia: Presentar para cada curso un espacio donde se gestionen posts y
comentarios que sean accesibles solamente a los participantes del curso.
Descripción:
Gestionar la presentación de post y comentarios dentro de un curso, cada curso tendrá

posts y comentarios relacionados a él, y los participantes de esta red serán los
participantes del curso sean estudiantes o profesores.
119
Historias de Usuario: Adaptación de todo el desarrollo a Moodle 2.0.x.
Debido a las diferencias existentes en las versiones de Moodle 1.9.x y Moodle 2.0.x, no
es posible adaptar transparentemente el código desarrollado a ambas versiones. Por
ello es necesario una vez que se termine de desarrollar todas las funcionales para la
versión 1.9.x, iniciar un proceso de adaptación a la versión 2.0.x de Moodle. Esto ha
sido considerado como una nueva historia de usuario.
Historia de Usuario
Historia: Adaptación del desarrollo a Moodle 2.0.x.
Descripción:
Cuando ya se encuentren completas todas las funcionalidades requeridas para la

versión 1.9.x de Moodle, entonces se requiere adaptar todo eso a la versión 2.0.x, lo
cual implica algunos cambios en el desarrollo.
Observaciones: Los principales cambios que se deben realizar es en la forma de

acceso a los datos, ya que algunas de las funciones para este objetivo presentes en
Moodle 1.9.x, están obsoletas en la nueva versión 2.0.x.
120
ANEXO 5: PLAN DE
ENTREGAS E ITERACIONES
121
Plan De Entregas E Iteraciones
Para el desarrollo del presente proyecto se ha considerado la ejecución de cuatro
iteraciones, cada una de las cuales contiene un conjunto de historias de usuario que
deberán ser desarrolladas durante la iteración correspondiente.
PRIMERA ITERACIÓN
Duración: 4 semanas Periodo: (feb-11-2011 - mar-11-2011)
Historias Comprendidas:
Historia de Usuario
Historia: Autenticación de un usuario de Moodle por medio de servicios web
Descripción:
Realizar la autenticación de un usuario de Moodle desde una interfaz distinta a la

tradicional de moodle, usando servicios web.
Observaciones: Usando servicios web. Uso de la librería wsdl2php para cliente php
122
Historia de Usuario
Historia: Presentación de los cursos correspondientes a un usuario, sea este
estudiante o profesor, identificando a que categoría pertenece cada uno de los cursos
Descripción:
Historia de Usuario
Historia: Presentación de los participantes de cada curso correspondiente al usuario
identificado, identificando si es estudiante o profesor del curso
Descripción:
123
Historia de Usuario
Historia: Presentación de los anuncios hechos por el profesor en un curso
Descripción:
Para cada uno de los cursos del usuario, presentar los anuncios que ha hecho el
profesor.
Historia de Usuario
Historia: En caso de tener rol de profesor en el curso, permitirle agregar nuevos
anuncios, y editarlos
Descripción:
Identificar el rol que tiene el usuario en cada curso, y para los que tenga rol de
profesor, permitirle agregar nuevos comentarios, y además editar los existentes.
124
Historia de Usuario
Historia: Presentar una lista de tareas del curso, en caso que el usuario tenga rol
de profesor permitirle agregar nuevas tareas, y también permitirle ver las tareas
subidas por los estudiantes.
Descripción:
Identificar el rol del usuario en cada curso, si tiene rol de estudiante, únicamente
presentarle una lista de las tareas que ha colocado el profesor, y en caso de tener rol
de profesor, permitirle agregar nuevas tareas, y para cada tarea ver los recursos
subidos por los estudiantes.
125
SEGUNDA ITERACIÓN
Duración: 4 semanas Periodo: (mar-14-2011 - abr-14-2011)
Historia de Usuario
Historia: Presentar la lista de foros del curso, si el usuario es profesor permitirle
agregar nuevos foros y discusiones, si es estudiante solo permitirle agregar
comentarios a las discusiones.
Descripción:
126
Historia de Usuario
Historia: Presentar una lista de los recursos disponibles en un curso.
Descripción:
Historia de Usuario
Historia: Presentar una lista de cuestionarios disponibles en el curso.
Descripción:
cuales participa.
127
Historia de Usuario
Historia: Presentar una lista de los usuarios que se encuentran conectados en el
sistema.
Descripción:
Historia de Usuario
Historia: Presentar una lista de los contactos de un usuario.
Descripción:
128
Historia de Usuario
Historia: Permitir a hacer una búsqueda de los usuarios del sistema
Descripción:
129
TERCERA ITERACIÓN
Duración: 4 semanas Periodo: (abr-15-2011 - may-13-2011)
Historia de Usuario
Historia: Presentar los mensajes recibidos de un usuario.
Descripción:
Historia de Usuario
Historia: Permitir enviar un mensaje privado a cualquiera de los contactos del
usuario, o a los participantes de un curso en el que participa
Descripción:
130
Historia de Usuario
Historia: Presentar el contenido en pantallas pequeñas que se puedan mover
Descripción:
Crear una interfaz dinámica para presentación de distintos recursos de moodle

en diferentes pantallas pequeñas dentro de la ventana principal del navegador.
Observaciones:
Historia de Usuario
Historia: Fijar estas pantallas pequeñas a distintos bloques dentro de la
página, de manera que aparezcan ordenadamente.
Descripción:
Las pantallas pequeñas movibles dentro de la ventana del navegador deben

aparecer ordenadas adecuadamente, de manera que no pueda haber una sobre
otra, sino que se acoplen a distintos bloques según los manipule el usuario.
Observaciones:
131
Historia de Usuario
Historia: Minimizar, maximizar, actualizar y cerrar las pantallas pequeñas con
su contenido
Descripción:
Las pantallas pequeñas movibles deben tener la capacidad de hacerse más

pequeñas para ocultar su contenido, de maximizarse para presentar en la
pantalla completa, y de cerrarse.
Observaciones:
Historia de Usuario
Historia: Presentar un menú de con las pantallas movibles disponibles y que
se puedan agregar a la ventana inicial del navegador
Descripción:
Las pantallas pequeñas movibles deben presentarse en una lista, de donde se

puedan agregar a la ventana del navegador.
Observaciones:
132
CUARTA ITERACIÓN
Duración: 4 semanas Periodo: (may-16-2011 - jun-17-2011)
Historia de Usuario
Historia: Presentar la información de Moode obtenida mediante Web Services, en
las pantallas movibles dentro del navegador
Descripción:
Dentro de las pantallas movibles presentar información que normalmente se presenta

en bloques en moodle, esta información debe ser la obtenida mediante Web Services.
Observaciones:
Historia de Usuario
Historia: Presentar un espacio donde el usuario pueda agregar post, los cuales se
compartirán con todos sus contactos
Descripción:

agregar posts o anuncios que quiere compartir con sus contactos del sistema.
133
Historia de Usuario
Historia: Presenta un listado de los post realizados del usuario, y también los
Descripción:
Como Probarlo: Usando servicios web.
Historia de Usuario
Historia: Permitir agregar comentarios en los posts de su red, ya sean de sus
Descripción:
134
Historia de Usuario
Historia: Permitir eliminar sea posts o comentarios que sean de propiedad del usuario
identificado.
Descripción:

Historia de Usuario
Historia: Permitir ingresar al muro de los contactos de su red
Descripción:
usuario.
135
QUINTA ITERACIÓN
Duración: 4 semanas Periodo: (jun-20-2011 - jul-22-2011)
Historia de Usuario
Historia: Presentar M
opción el usuario dueño del post o comentario recibirá una notificación que ha dicho
usuario le ha gustado su anuncio.
Descripción:
Todos los posts y comentarios deben tener la opción “Me gusta”, de esa manera
Historia de Usuario
Historia: Presentar una lista de notificaciones con las actividades que se ha realizado
relacionadas con su red social
Descripción:
red social, por ejemplo alguien publicó en su muro, a alguien le gustó uno de sus
anuncios, o alguien comentó un post suyo.
136
Historia de Usuario
Historia: Presentar de los usuarios bloqueados.
Descripción:
por él mismo.
137
SEXTA ITERACIÓN
Duración: 4 semanas Periodo: (jul-25-2011 - ago-26-2011)
Historia de Usuario
Historia: Permitirle al usuario enviar invitaciones de amistad a otros usuarios del
sistema, y permitirle bloquearlos y eliminarlos.
Descripción:
están entre sus contactos, si ya se encuentra entre sus contactos permitir bloquearlo,
y eliminarlo.
Historia de Usuario
Historia: Presentar para cada curso un espacio donde se gestionen posts y
comentarios que sean accesibles solamente a los participantes del curso.
Descripción:

138
Historia de Usuario
Historia: Adaptación del desarrollo a Moodle 2.0.x.
Descripción:

Observaciones: Los principales cambios que se deben realizar es en la forma de

acceso a los datos, ya que algunas de las funciones para este objetivo presentes en
Moodle 1.9.x, están obsoletas en la nueva versión 2.0.x.
139
ANEXO 6:
DOCUMENTACION DE
DESARROLLO
140
Documentación del Desarrollo
En este documento se especifica todo el proceso de desarrollo del sistema en este
proyecto.
Moodle.- Plataforma e-learning, sobre la cual se realiza la implementación de los

nuevos componentes desarrollados.
Lenguaje de Programación.- Se ha usado una combinación de PHP y JavaScript,

además del lenguaje de marcado XML, y hojas de estilo CSS.
PHP: Capa de servicios web, capa de red social.
JavaScript: Capa de widgets, capa de red social.
XML: Capa de servicios web.
CSS: Capa de widgets, capa de red social.
Componentes Desarrollados:
- Capa de servicios web

- Capa de widgets
- Capa de red social.
Capa de servicios web.- Como ya se había especificado en las secciones anteriores,

para el desarrollo de los servicios web se hace uso del plugin wspp a partir del cual se
.
Sobre el plugin wspp se han construido las nuevas funciones, y además se han usado
algunas ya implementadas en el mismo, dando el origen a la versión wspp_utpl.
En la siguiente tabla se especifican todas las funciones de la capa de Web services

usadas para el desarrollo de una capa de usuario final basada en Web Services.
Nombre Descripción Indicación

accept_noaccept_invitation En esta función se registra el Desarrollada
estado de una aceptación o no
aceptación de amistad de un
141
usuario.
add_assignment Para agregar una nueva tarea Usada de WSPP
(modulo tipo assignment),
luego sería agregado a un
curso específico.
add_assignment2 Para agregar un modulo a un Desarrollada
curso específico.
add_comment_in_rsa Realiza la operación de Desarrollada
registrar un nuevo comentario
a un post de la red social
add_forum Realiza la operación de agregar Usada de WSPP
un nuevo foro (modulo tipo
forum), luego seria agregado a
un curso especifico.
add_post_in_rsa Realiza las operaciones para Desarrollada
agregar un nuevo post en la
red social.
add_quiz_mod Realiza las operaciones para Desarrollada
agregar un cuestionario
(modulo tipo quiz), que luego
sería agregado a un curso.
add_resource_mod Realiza las operaciones para Desarrollada
agregar un nuevo recurso
(modulo tipo resource), que
luego sería agregado a un
curso.
add_section Realiza las operaciones para Desarrollada
colocar un anuncio en un curso
específico.
allow_comments Verifica si el anuncio de una Desarrollada
sección está con la opción de
permitir comentarios, en caso
de estarlo retorna el id del
post al que corresponde la
sección que contiene el
anuncio.
delete_ads_with_comments Elimina un anuncio con la Desarrollada
opción de agregar comentario
de una determinada sección de
un curso.
delete_comment_in_rsa Elimina comentarios realizados Desarrollada
a un post.
delete_mod_from_course_s Elimina un modulo que se Desarrollada
ection encuentra agregado a un
curso, ejm. Assignments,
resources, fórums, etc.
delete_post Elimina un post de la red Desarrollada
social.
edit_ad_insection Actualiza el contenido de un Desarrollada
anuncio en la sección de un
curso.
142
edit_assignments Edita el contenido del modulo Usada de WSPP
assignments.
edit_forums Actualiza el contenido de un Usada de WSPP
foro.
forum_add_discussion Agrega una discusión a un foro Desarrollada
de un determinado curso.
forum_add_reply Agrega un post a la discusión Usada de WSPP
de un foro.
forum_delete_discussion Elimina la discusión de un foro. Desarrollada
get_activitiesmuro Obtiene los posts del muro de Desarrollada
la red social de un usuario.
get_ads_in_course Obtiene los anuncios Desarrollada
realizados la sección de un
curso.
get_all_assignments Obtiene la lista de las tareas Desarrollada
(modulo assignment)
agregadas a un curso.
get_all_forums Obtiene la lista de foros Modificada de WSPP
(modulo forum) agregados a
un curso.
get_all_quizzes Obtiene la lista de Modificada de WSPP
cuestionarios (modulo quiz)
agregados a un curso.
get_assignment_submission Obtiene la lista de archivos Desarrollada
s subidos por un estudiante en
una tarea (assignment)
get_categories Obtiene las categorías en las Usada de WSPP
que se encuentran clasificados
los cursos.
get_comments_rsa Obtiene los comentarios Desarrollada
realizados a los posts de la red
social.
get_contacts Obtiene los contactos de un Desarrollada
usuario en el sistema.
get_forum_discussions Obtiene las discusiones Desarrollada
agregadas a un foro.
get_forum_posts Obtiene los posts agregados a Desarrollada
las discusiones de los foros.
get_forums_bycourse Obtiene los foros Desarrollada
pertenecientes a un curso
específico.
get_invitations Obtiene la lista de invitaciones Desarrollada
pendientes que tiene un
usuario.
get_messages Obtiene la lista de mensajes Desarrollada
obtenidos recibidos por un
usuario
get_more_users Realiza la búsqueda de Desarrollada
usuarios en el sistema.
get_my_courses_byuserna Obtiene la lista de cursos Usada de WSPP
me correspondientes a un usuario.
143
get_my_id Obtiene el id del usuario Usada de WSPP
identificado.
get_new_idsection Obtiene el id de una sección Desarrollada
que se encuentre vacía.
get_notifications Obtiene una lista de las Desarrollada
notificaciones de la red social
de un usuario, por comentarios
hechos en sus posts, o por que
otro usuario ha seleccionado la
M de alguno
de sus posts
get_number_new_notificati Obtiene el numero de las Desarrollada
ons nuevas notificaciones desde la
ultima revisión del usuario.
get_participants_in_course Obtiene una lista de los Desarrollada
participantes de un curso
específico.
get_posts_rsa Obtiene la lista de posts Desarrollada
realizadas en la red social
principal del usuario.
get_posts_rsa_course Obtiene la lista de posts en la Desarrollada
red social de un curso
determinado.
get_resources Obtiene la lista de recursos Desarrollada
(modulo resource) de un curso
especifico.
get_user_byid Obtiene todos los datos de un Usada de WSPP
usuario identificado por su id.
get_users_bycourse Obtiene la lista de usuarios de Usada de WSPP
un curso.
get_users_online Obtiene la lista de usuarios Desarrollada
conectados al sistema en los
últimos 5 minutos.
is_teacher_in_course Verifica si un usuario tiene rol Desarrollada
de profesor en un curso
específico.
login Realiza la autenticación de un Usada de WSPP
usuario.
logout Cierra la sesión de un usuario Usada de WSPP
en el sistema.
message_add_contact Agrega un nuevo usuario a la Desarrollada
lista de contactos.
message_block_contact Bloquea un usuario de la red Desarrollada
social.
message_move_toreaded Especifica que los mensajes Desarrollada
recibidos han sido leídos por
su destinatario.
message_remove_contact Elimina un contacto de la lista Desarrollada
de contactos de un usuario.
message_send Realiza el envió de un mensaje Desarrollada
privado a un usuario.
144
message_unblock_contact Desbloquea un usuario que ha Desarrollada
sido bloqueado anteriormente
en la red social.
register_activity Registra una actividad Desarrollada
realizada en la red social por el
usuario.
register_notification_log Agrega las acciones realizadas Desarrollada
al log en la base de datos.
remove_post_to_discussion Elimina el post de la discusión Desarrollada
de un foro.
update_section Actualiza el contenido de una Desarrollada
sección de un curso.
update_user Actualiza los datos de un Usada de WSPP
usuario, se usa para actualizar
el perfil del usuario
identificado.
Capa de Widgets.- Para la implementación de la capa de widgets, como se ha

mencionado en las secciones anteriores se hace uso de JPolite1, a este plugin se le han
realizado varias modificaciones para adecuarlo a la integración con Moodle, y a la
presentación de los recursos de Moodle obtenidos mediante servicios web.
Se considera como un nuevo plugin para gestión de widgets en Moodle. Los principales
archivos que conforman el plugin son:
- jquery.js: Es el framework de javascript en el cual se basan todas las funciones.

- jpolite.core.js: Es el núcleo de Jpolite se han realizado pequeños cambios para
la gestión de los widgets de la red social y de los datos del curso.
- modules.js: Contiene la referencia hacia los archivos que serán presentados en
el widget.
- jpolite.ext.js: Es un complemento del anterior. En este archivo se han agregado
varias funciones para la gestión de los widgets de moodle, las mismas se
muestran a continuación:
Nombre Descripción
see_more_notif Gestiona el envió de parámetros
indicando la ultima notificación vista, para
obtener las siguientes.
enable_disable_element Gestiona la activación y desactivación de
ciertos elementos de los formularios,
dependiendo de ciertas acciones.
selected_resource_type Muestra campos específicos en el
formulario de nuevo recurso,
dependiendo del tipo de recursos que se
1
TRILANCER. [en línea]<http://trilancer.wordpress.com/category/jpolite>
145
vaya a agregar.
delete_mod_from_course_section Gestiona el envío de los parámetros con
datos del nuevo modulo, eje. Resource,
fórum, etc.
load_widgets_in_selected_course Realiza la carga de los widgets
dependiendo del curso seleccionado.
close_widgets_unused_course Cierra los widgets del curso anterior, para
ubicar los del nuevo curso seleccionado.
change_language Obtiene y envía los parámetros para
cambiar el lenguaje de moodle.
deletePostDiscussion Obtiene y envía los datos del post de una
discusión, para que sea eliminado.
register_like Obtiene y envia los paramentros de la
accion like en la red social.
register_activity Gestiona el envía de los parámetros para
registrar una actividad en la red social.
updatemsg Actualiza el widget de mensajes recibidos
cada 60 segundos.
clear_readed_message Obtiene y envía los parámetros necesarios
para registrar como leídos los mensajes.
deleteContact Obtiene y envía los parámetros
requeridos de un contacto, para
eliminarlo.
addContact Obtiene y envía datos de solicitud de
Amistad.
addDiscussion Obtiene y envía parámetros para agregar
una nueva discusión en un foro.
deleteForumDiscussion Obtiene y envía parámetros para eliminar
foros de un curso.
addComenttoDiscussion Obtiene y envía los parámetros para
agregar un post en la discusión de un
curso.
send_msg Obtiene y envía los parámetros para un
mensaje privado.
blockUnblockContact Obtiene y envía parámetros para
desbloquear a un usuario de la red.
cargarCursoEnPestania Obtiene el nombre del curso actual, y lo
envía a una pestaña para que se visualice.
Se usan algunos plugines adicionales de jquery para la presentación de una interfaz

dinámica mendiante widgets, estos son:
- jqModal : para presentación de ventanas emergentes.

- Jquery-jeditable: para realizar actualización de datos dentro de los widgets.
- easyTooltip.js: para una elegante presentación de tooltips.
146
Capa de red social.- Para el desarrollo de la capa de red social, se han creado algunas
clases y archivos PHP, además de algunos archivos de javascript para gestionar la
presentación.
Archivos de javascript desarrollados para gestionar la presentación de una capa de

red social:
Nombre Descripción
funciones_anuncio_profesor.js Gestiona la presentación de los anuncios
realizados por el profesor en un curso.
funciones_navegar_por_anuncio.js Gestiona la presentación de los anuncios del
profesor en una forma de navegación por
cada uno de éstos anuncios.
funciones_post.js Gestiona la agregación de los nuevos posts y
comentarios tanto de la red social inicial, de
la red social del curso, y del muro.
funciones_post_muro.js Gestiona la presentación de los posts y
comentarios en el muro de un usuario.
funciones_post_rsa_curso.js Gestiona la presentación de los posts y
comentarios en la red social de un curso.
funciones_post_rsa_inicial.js Gestiona la presentación de los posts y
comentarios en la red social principal.
jquery.oembed.js Realiza la presentación de videos embebidos
en la red social, cuando se postea url de
videos.
rsa_menu.js Gestiona la presentación del menú que
muestra las notificaciones a un usuario.
Archivos PHP desarrollados para gestionar la presentación de una capa red social.
Nombre Descripción Tipo

Accept_noaccept_invitation.php Registra la acción de acepta Comunicación con WS
o no acepta invitación
ClassFuncionesPost.php Contiene funciones para Clase
realizar la presentación de
los posts y comentarios en
forma de red social.
ClassNotifications.php Contiene funciones para Clase
obtener las notificaciones
de un usuario y presentarlas
en un menú.
Present_ads_in_course.php Vista de anuncios hechos en Presentación en Widget
un curso.
Present_course_rsa.php Vista de la red social de un Presentación en Widget
curso.
Present_main_rsa.php Vista de la red social Presentación en Widget
principal.
Present_wall.php Vista del muro de un Presentación en Widget
147
usuario
Ads_in_course.php Obtiene todos los anuncios Comunicación con WS
que ser presentaran en un
curso
comment_ajax.php Registra la adición de un Comunicación con WS
nuevo comentario a un post
Course_rsa_data.php Obtiene todos los datos que Comunicación con WS
se presentarán en la red
social de un curso
Delete_comment.php Registra la eliminación de Comunicación con WS
un comentario de un post
Delete_update.php Registra la eliminación de Comunicación con WS
un post
Edit_ad_ofteacher.php Registra un cambio en el Comunicación con WS
anuncio de una sección.
Main_rsa_data.php Obtiene todos los datos que Comunicación con WS
se presentaran en la red
social principal
More_comments.php Presenta una lista de Comunicación con WS
nuevos comentarios, a
partir de los que ya están
visibles.
Moreposts_incourse.php Presenta una lista de posts Comunicación con WS
de un curso, a partir de los
que ya están visibles.
New_ad_in_course.php Registra la adición de un Comunicación con WS
nuevo anuncio en la sección
de un curso.
New_post_in_wall.php Registra la adición de un Comunicación con WS
nuevo post en el muro de
un usuario
New_post_main_rsa.php Registra la adición de un Comunicación con WS
nuevo post en la red social
principal del usuario.
New_post_rsa_course.php Registra la adición de un Comunicación con WS
nuevo post en la red social
de un curso.
register_activity.php Registra una acción en la Comunicación con WS
red social, como un like o un
nuevo comentario.
Register_log.php Agrega un log en la base de Comunicación con WS
datos sobre la actividad
realizada
View_more_notifications.php Obtiene una nueva lista de Comunicación con WS
notificaciones a partir de las
que ya se han mostrado.
View_ specific_post.php Obtiene el post específico Comunicación con WS
en el que se ha registrado
una actividad.
Wall_data.php Obtiene todos los datos que Comunicación con WS
se presentaran en el muro
148
de un usuario
Además se encuentra otro grupo de clases y archivos desarrollados en php, los cuales
contienen las funcionalidades para obtención de los servicios de Moodle, y los cuales son
presentados en la interfaz dinámica del sistema de este proyecto.
En la siguiente tabla se detalla cada una de estas clases y archivos:
Nombre Descripción Tipo

Assignments_submissions.php Obtiene las tareas subidas por Comunicación con WS
un estudiante.
ClassAssignments.php Contiene métodos para la Clase
presentación de los anuncios
de tareas puestos por el
profesor.
ClassContacts.php Contiene funciones para Clase
presentar la lista de contactos
del usuario
ClassCourse.php Contiene funciones para Clase
obtener los cursos separados
por categorías, y presentarlos
en una lista adecuadamente
clasificados
ClassForms.php Es una clase que contiene la Clase
definición de los formularios
requeridos para agregar
nuevos módulos en los cursos.
ClassParticipants.php Contiene funciones para Clase
obtener la lista de los
participantes del curso
ClassQuizzes.php Contiene funciones para Clase
presentar la lista de
cuestionarios abiertos en un
curso.
ClassSearch.php Contiene funciones para Clase
presentar los usuarios
encontrados como resultado
de una búsqueda
ClassTime.php Funciones para obtener Clase
formatos de presentación de
fecha
ContactsList.php Vista de la lista de contactos Presentación en Widget
de un usuario.
Course_Resourse.php Vista de los recursos Presentación en Widget
disponibles en un curso, y del
formulario para agregar uno
149
nuevo en caso que el usuario
sea el profesor del curso
Course_List.php Vista de los cursos de un Presentación en Widget
usuario.
Files_assignments_submissions.
php
Forums_List.php Vista de los foros disponibles Presentación en Widget
en un curso, y del formulario
para agregar uno nuevo en
caso que el usuario sea el
profesor del curso
Online_Users_List.php Vista de los usuarios Presentación en Widget
conectados en los últimos
minutos al sistema.
SearchUsers.php Vista de formulario para Presentación en Widget
buscar usuarios.
ViewSearchedUsers.php Obtiene la lista de usuarios Comunicación con WS
encontrados en una
búsqueda.
add_assignment.php Vista de la lista de las tareas Presentación en Widget
disponibles en el curso, y del
formulario para agregar una
nueva en caso que el usuario
sea el profesor del curso
add_contact.php Registra la adición de un Comunicación con WS
nuevo usuario a la lista de
contactos.
add_discussion.php Registra la adición de nueva Comunicación con WS
discusión para el foro de un
curso.
add_postto_discussion.php Registra la adición de un Comunicación con WS
nuevo post a la discusión de
un foro.
block_unblock_contact.php Registra la acción de bloquear Comunicación con WS
o desbloquear un usuario en la
red social.
clear_readed_messages.php Registra la lectura de los Comunicación con WS
mensajes recibidos de un
usuario.
delete_contact.php Registra la eliminación de un Comunicación con WS
contacto.
delete_forum_discussion.php Registra la eliminación de una Comunicación con WS
discusión en el foro de un
curso.
delete_mod_from_course_secti Registra la eliminación de un Comunicación con WS
on.php modulo de la sección de un
curso.
delete_post_ofdiscussion.php Registra la eliminación de un Comunicación con WS
post en la discusión de un
foro.
edit_user_profile.php Registra cambios en los datos Comunicación con WS
150
del usuario.
forums_data.php Obtiene todos los datos que se Comunicación con WS
presentarán como contenido
del foro.
message_send_contacts.php Registra un nuevo mensaje a Comunicación con WS
un usuario de la lista de
contactos.
Message_send_onlineusers.php Registra un nuevo mensaje a Comunicación con WS
usuarios conectados.
Message_send_partic.php Registra un nuevo mensaje a Comunicación con WS
participantes de un curso.
Messagestoread.php Vista de los mensajes Presentación en Widget
recibidos del usuario.
More_post_todisc.php Obtiene una nueva lista de
posts en la discusión de un
curso, a partir del último
mostrado
New_assignment.php Registra un nuevo modulo tipo Comunicación con WS
assignment en la sección de
un curso.
New_forum.php Registra un nuevo modulo tipo Comunicación con WS
forum en la sección de un
curso.
New_quiz.php Registra un nuevo modulo tipo Comunicación con WS
quiz en la sección de un curso.
New_resource.php Registra un nuevo modulo tipo Comunicación con WS
resource en la sección de un
curso.
Participants_in_course_list.php Vista de los participantes de Presentación en Widget
un curso
Present_forums.php Vista de los foros del curso Presentación en Widget
Quizzes_incourse.php Vista de los cuestionarios Presentación en Widget
abiertos en un curso
User_profile.php Vista del perfir de usuario. Presentación en Widget
También son requeridos otros archivos php necesarios, los cuales han sido desarrollados para
la presentación en la interfaz dinámica, se detallan en la siguiente tabla:
Nombre Descripción
course_name Obtiene el nombre el curso seleccionado para
ser presentado en una pestaña con los datos
del curso.
default_template Plantilla para los widgets.
index.php Página principal donde se presenta toda la
interfaz.
languageofmessages.php Obtiene en elementos html los strings del
151
lenguaje actual de moodle, para poder
consumirlos desde javascript.
menú.php Contiene los módulos disponibles a agregarse
como widgets en la interfaz.
152
ANEXO 7: ESPECIFICACION
DE CASOS DE PRUEBA
153
Especificación de Casos de Prueba
En este documento se detallan los casos de prueba, de acuerdo a las historias de

usuario obtenidas. Se cubre un conjunto de pruebas funcionales relacionadas a las
historias de usuario.
Por cada historia de usuario puede existir uno o más casos de prueba, dependiendo de
la necesidad del cliente que se trate de solventar.
La estructura para la especificación de cada uno de los casos de prueba, será la

siguiente:
Nombre de la Historia de usuario

o Descripción
o Nombre del caso de prueba
 Descripción
 Condiciones de ejecución
 Entrada
 Resultado esperado
 Evaluación de la prueba
La misma estructura tendrá cada uno de los casos de prueba pertenecientes a cada
una de las historias de usuario.
154
1. Historia 1:
Autenticación de un usuario de Moodle por medio de servicios web.
1.1 Descripción
El usuario para poder acceder al sistema, primeramente debe autenticarse en una
interfaz, se usara la misma interfaz para la autenticación tradicional de moodle, pero
además se realizar a otro tipo de autenticación, que es la correspondiente a los
servicios web.
1.2 Nombre del caso de prueba I

Autenticación incorrecta de un usuario por medio de servicios web.
1.2.1 Descripción
El usuario deberá intentar autenticarse en el sistema ingresando datos
erróneos, ya sea su nombre de usuario o su contraseña.
1.2.2 Condiciones de ejecución

Que el usuario haya sido agregado al sistema previamente por un
administrador.
Que el usuario conozca su nombre de usuario y su contraseña
1.2.3 Entrada
- Nombre de usuario
- Contraseña
(Uno o ambos datos deben ser erróneos)
1.2.4 Resultado esperado

Mensaje de error indicando que no se puede ingresar al sistema.
1.2.5 Evaluación de la prueba

Prueba satisfactoria
155
1.3 Nombre del caso de prueba II
Autenticación correcta de un usuario por medio de servicios web.
1.3.1 Descripción
El usuario deberá ingresar sus datos de autenticación correctos en el sistema,
para poder acceder.

Que el usuario haya sido agregado al sistema previamente por un
administrador.
Que el usuario conozca su nombre de usuario y su contraseña
1.3.3 Entrada
- Nombre de usuario
- Contraseña
Ingreso al sistema correcto.

156
2. Historia 2:
Presentación de los cursos correspondientes a un usuario, sea este estudiante o
profesor, identificando a que categoría pertenece cada uno de los cursos.
2.1 Descripción

Presentación de los cursos en los cuales el usuario identificado cumple un rol, sea de
profesor o de estudiante.
2.2.1 Descripción
Una vez que el usuario se ha identificado, se deberán presentar una pantalla
dentro del navegador, con la lista de cursos del usuario.

Que el usuario tenga rol de profesor o de estudiante en alguno de los cursos del
sistema.
2.2.3 Entrada
- Ingresar a la presentación dinámica del sistema.

La lista de cursos del usuario en una pantalla dentro del navegador web.

157
Presentación de cada uno de los cursos clasificados de acuerdo a la categoría a la que
pertenecen.
2.3.1 Descripción
dentro del navegador, con la lista de cursos del usuario, clasificados en la
categoría de cursos correspondiente.

Que el usuario tenga rol de profesor o de estudiante en alguno de los cursos del
sistema, y que estos cursos pertenezcan a una categoría específica.
2.3.3 Entrada

La lista de cursos del usuario en una pantalla dentro del navegador web,
clasificados de acuerdo a su categoría.

158
2.4 Nombre del caso de prueba III
Presentación de mensaje indicando que el usuario no tiene rol como profesor o como
estudiante en ninguno de los cursos.
2.4.1 Descripción
dentro del navegador, presentando el mensaje de que no está enrolado en
ningún curso actualmente.

Que el usuario no esté enrolado en ninguno de los cursos.
2.4.3 Entrada

Una pantalla dentro del navegador web, indicando que el usuario no tiene
cursos actualmente.

159
3. Historia 3:
Presentación de los participantes de cada curso correspondiente al usuario
identificado, identificando si es estudiante o profesor del curso.
3.1 Descripción

Presentación de una lista con los participantes del curso al ingresar a uno de los cursos
en los que el usuario tiene un rol de profesor o estudiante.
3.2.1 Descripción
Una vez que el usuario tiene disponible la lista de sus cursos, deberá poder
ingresar a cada uno de ellos, al dar clic sobre alguno se deberá presentar una
pantalla dentro del navegador, con la lista de los participantes del curso
seleccionado.

Que el curso tenga usuarios con rol de profesor y/o de estudiante.
3.2.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.

La lista de los participantes del curso seleccionado.

160
Presentación de una lista con los participantes del curso clasificados de acuerdo a su
rol, sea de profesor o estudiante.
3.3.1 Descripción
pantalla dentro del navegador, con la lista de los participantes del curso
seleccionado, en esta lista se deberá visualizar por separados los usuarios con
rol de profesor, y los usuarios con rol de estudiante.

Que el curso tenga usuarios con rol de profesor y/o de estudiante.
3.3.3 Entrada

La lista de los participantes del curso seleccionado, clasificados según el rol que
tienen en el curso.

161
Presentación de mensaje indicando que el curso no tiene usuarios con rol de profesor
y/o estudiante.
3.4.1 Descripción
Si el curso seleccionado no tiene participantes, sea con rol de profesor, o de
estudiantes, se deberá mostrar un mensaje indicando esto.

Que el curso tenga no tenga participantes, sea con rol de profesores, o de
estudiantes.
3.4.3 Entrada

Mensaje indicando que no existe dicho tipo de participantes en el curso.

162
4. Historia 4:
Presentación de los anuncios hechos por el profesor en un curso.
4.1 Descripción
Presentación de los anuncios que un usuario con rol de profesor ha colocado en el
curso.

Presentación del último de los anuncios del profesor en el curso, permitiendo al
usuario navegar además por todos los anteriores.
4.2.1 Descripción
pantalla dentro del navegador, con la lista de los anuncios que ha realizado el
profesor en el curso, inicialmente se presentará únicamente el último anuncio,
pero el usuario será capaz de navegar por todos los anuncios a través de unos
iconos que le permitan ir al siguiente y al anterior.

Que el curso tenga anuncios hechos por el profesor.
4.2.3 Entrada

Presentación del último anuncio en el curso, y poder navegar por los anteriores
por medio de iconos que permitan ir al siguiente y al anterior.

163
Presentación de mensaje indicando que no hay anuncios en el curso.
4.3.1 Descripción
Si aun no se han realizado anuncios en el curso por parte del profesor, entonces
el usuario debe obtener un mensaje indicando que no existen anuncios en ese
curso.

Que el curso no tenga anuncios.
4.3.3 Entrada

Presentación de mensaje indicando que no existen anuncios en el curso
seleccionado.

164
5. Historia 5:
En caso de tener rol de profesor en el curso, permitirle agregar nuevos anuncios, y
editarlos.
5.1 Descripción
Se debelara comprobar el tipo de rol que el usuario tiene en el curso, si tiene rol de
profesor permitirle agregar nuevos anuncios, y editarlos a los ya existentes.

Presentar la opción de agregar anuncio cuando el usuario tiene rol de profesor en el
curso.
5.2.1 Descripción
profesor en el curso, si este usuario tiene rol de profesor en este curso, se
deberá presentar además un área de texto donde podrá escribir un nuevo
anuncio y publicarlo en el curso.

Que el usuario identificado tenga rol de profesor en el curso seleccionado.
5.2.3 Entrada
- Mensaje del nuevo anuncio

Presentación del nuevo anuncio agregado en el curso.

165
Posibilidad de editar los anuncios de un curso, solo cuando el usuario tiene rol de
profesor en el curso.
5.3.1 Descripción
profesor en el curso, si este usuario tiene rol de profesor en el curso, se deberá
permitir la opción de editar alguno de los anuncios seleccionados al dar doble
clic sobre el mensaje del anuncio que quiere editar.

Que exista al menos un anuncio para que pueda se editado
5.3.3 Entrada
- Nuevo mensaje en el anuncio que ya existía.

Presentación del anuncio con el nuevo mensaje.

166
No permitir editar, ni agregar nuevos anuncios cuando el usuario no tenga rol de
profesor en el curso seleccionado.
5.4.1 Descripción
profesor en el curso, si este usuario no tiene rol de profesor en el curso, no se
deberá presentar la opción ni de agregar nuevo anuncio, ni de editar los
existentes.

Que el usuario identificado no tenga rol de profesor en el curso seleccionado.
Que exista al menos un anuncio para probar que no se permite editarlo.
5.4.3 Entrada

Presentación de los anuncios, sin la opción de editar, ni agregar uno nuevo.

167
6. Historia 6:
Presentar una lista de tareas del curso, en caso que el usuario tenga rol de profesor
permitirle agregar nuevas tareas, y también permitirle ver las tareas subidas por los
estudiantes.
6.1 Descripción
Se debelara comprobar el tipo de rol que el usuario tiene en el curso, si tiene rol de
profesor permitirle agregar nuevas tareas, y presentar las tareas existentes del curso,
si no tiene rol de profesor únicamente presentar las tareas existentes en el curso.

Presentar la opción de agregar tarea cuando el usuario tiene rol de profesor en el
curso.
6.2.1 Descripción
pantalla dentro del navegador, con la lista de los tareas que hay en el curso, si
este usuario tiene rol de profesor en este curso, se deberá presentar además
un formulario en donde podrá agregar datos para una nueva tarea.

6.2.3 Entrada
- Llenar los campos del formulario para la nueva tarea.

Presentación del la nueva tarea agregada en el curso.

168
Presentar mensaje de error al agregar tarea, cuando no se han enviado los datos
requeridos para la nueva tarea.
6.3.1 Descripción
Cuando el usuario con rol de profesor agrega una nueva tarea, existen datos
requeridos para esta nueva tarea, si al enviar la opción de agregar la nueva
tarea, no se han llenado todos estos datos requeridos, entonces aparecerá un
mensaje indicando que no se han llenado todos los datos necesarios.

Datos requeridos vacios.
6.3.3 Entrada
- Dejar en blando uno o varios de los datos requeridos del formulario
para la nueva tarea.

Presentación del mensaje indicando que no se ha agregado la tarea debido a
que los datos requeridos están vacíos.

169
Presentar las los archivos que los estudiantes han subido en las tareas, cuando el
usuario tiene rol de profesor.
6.4.1 Descripción
Cuando el usuario con rol de profesor da clic sobre alguna de las tareas, se
deberán presentar los archivos que el estudiante ha subido en esa tarea.

Que existan archivos subidos por los estudiantes en la tarea seleccionada.
6.4.3 Entrada
- Seleccionar alguna de las tareas del curso.

Presentación de los archivos que los estudiantes han subido para esa tarea.

170
No presentar la opción de agregar nuevas tareas, ni de ver los archivos subidos por los
estudiantes en las tareas cuando el usuario tiene rol de estudiante.
6.5.1 Descripción
Cuando el usuario identificado tiene rol de estudiante, solamente deberá tener
una lista con las tareas disponibles en el curso, no deberá tener la opción de
agregar nuevas tareas, ni de ver que archivos han sido subidos por los
estudiantes.

Que el usuario identificado tenga rol de estudiante en el curso seleccionado.
6.5.3 Entrada
- Seleccionar alguna de las tareas del curso sin permitirle ver los archivos
que los estudiantes han subido en esa tarea.

Presentación de la lista de tareas del curso, sin la opción de agregar una nueva,
ni de ver los archivos que los estudiantes han subido para la tarea seleccionada.

171
7. Historia 7:
Presentar la lista de foros del curso, si el usuario es profesor permitirle agregar nuevos
foros y discusiones, si es estudiante solo permitirle agregar comentarios a las
discusiones.
7.1 Descripción

Ver la lista de foros disponibles en el curso.
7.2.1 Descripción
pantalla dentro del navegador con la lista de los foros que hay en el curso, esta
lista será mostrada tanto a usuarios con rol de profesor, como a usuarios con
rol de estudiante.

Que el usuario identificado tenga rol de profesor o estudiante en el curso
seleccionado.
Que existan foros disponibles para ese curso seleccionado.
7.2.3 Entrada

Presentación del la lista de foros disponibles en el curso.

172
Ver la lista de discusiones de cada foro del curso.
7.3.1 Descripción
pantalla dentro del navegador con la lista de los foros que hay en el curso, esta
lista será mostrada tanto a usuarios con rol de profesor, como a usuarios con
rol de estudiante, al seleccionar alguno de esto foros, se deberán mostrar las
discusiones que hay para este foro.

seleccionado.
Que existan foros disponibles para ese curso seleccionado, y que el foro cuente
con discusiones.
7.3.3 Entrada
- Seleccionar uno de los foros del curso

Presentación del la lista de discusiones del foro seleccionado en el curso.

173
Agregar posts a los temas de discusión del foro.
7.4.1 Descripción
pantalla dentro del navegador con la lista de los foros que hay en el curso, al
seleccionar alguno de esto foros, se deberán mostrar las discusiones que hay
para este foro, cada discusión deberá tener la opción de comentar, para que los
usuarios sea con rol de profesor o de estudiante participen en la discusion.

seleccionado.
Que existan discusiones para el foro seleccionado.
7.4.3 Entrada
- Seleccionar uno de los foros del curso
- Seleccionar la opción comentar de una discusión del foro.

Agregación del nuevo comentario a la discusión del foro.

174
Agregar nuevo foro en el curso.
7.5.1 Descripción
pantalla dentro del navegador con la lista de los foros que hay en el curso, y si
el usuario tiene rol de profesor del curso, además se presentará un formulario
con datos para agregar un nuevo foro.

Que el usuario identificado tenga rol de profesor curso seleccionado.
7.5.3 Entrada
- Llenar los datos del formulario de nuevo foro

Agregación del nuevo foro al curso.

175
7.6 Nombre del caso de prueba IV
Agregar nueva discusión en el foro del curso.
7.6.1 Descripción
pantalla dentro del navegador con la lista de los foros que hay en el curso, al
dar clic sobre cualquiera de los foros se deberá presentar la lista de discusiones
de ese foro, y si el usuario tiene rol de profesor, además deberá presentarse la
opción de agregar una nueva discusión en el foro.

Que el usuario identificado tenga rol de profesor curso seleccionado.
7.6.3 Entrada
- Llenar seleccionar algún foro del curso.
- Llenar los datos del formulario de nueva discusión.

Agregación de una nueva discusión en el foro del curso.

176
7.7 Nombre del caso de prueba IV
Mensaje indicando que no existen foros disponibles en el curso.
7.7.1 Descripción
pantalla dentro del navegador con el mensaje de que no hay foros disponibles
para ese curso.

seleccionado.
Que no existan foros relacionados con el curso seleccionado.
7.7.3 Entrada

Mensaje indicando que no existen foros en el curso seleccionado.

177
8. Historia 8:
Presentar una lista de los recursos disponibles en un curso.
8.1 Descripción

Ver la lista de recursos disponibles en el curso.
8.2.1 Descripción
pantalla dentro del navegador con la lista de los recursos que hay en el curso,
tales como documentos o enlaces hacia páginas web, esta lista será mostrada
tanto a usuarios con rol de profesor, como a usuarios con rol de estudiante.

seleccionado.
Que existan recursos disponibles para ese curso seleccionado.
8.2.3 Entrada

Presentación del la lista de recursos disponibles en el curso.

178
Mensaje indicando que no existen recursos para el curso seleccionado.
8.3.1 Descripción
pantalla dentro del navegador con un mensaje indicando que no existen
recursos para el curso seleccionado.

seleccionado.
Que no existan recursos disponibles para ese curso seleccionado.
8.3.3 Entrada

Presentación mensaje indicando que no existen recursos para el curso
seleccionado.

179
9. Historia 9:
Presentar una lista de cuestionarios disponibles en el curso.
9.1 Descripción
cuales participa.

Presentar la lista de cuestionarios disponibles en el curso.
9.2.1 Descripción
pantalla dentro del navegador con la lista de los cuestionarios que hay en el
curso, esta lista será mostrada tanto a usuarios con rol de profesor, como a
usuarios con rol de estudiante.

seleccionado.
Que existan cuestionarios disponibles para ese curso seleccionado.
9.2.3 Entrada

Presentación del la lista de cuestionarios disponibles en el curso.

180
Mensaje indicando que no existen cuestionarios para el curso seleccionado.
9.3.1 Descripción
pantalla dentro del navegador con un mensaje indicando que no existen
cuestionarios para el curso seleccionado.

seleccionado.
Que no existan cuestionarios disponibles para ese curso seleccionado.
9.3.3 Entrada

Presentación mensaje indicando que no existen cuestionarios para el curso
seleccionado.

181
10. Historia 10:
Presentar una lista de los usuarios que se encuentran conectados en el sistema.
10.1 Descripción

Presentar la lista de usuarios conectados al sistema.
10.2.1 Descripción
Se deberá presentar una pantalla dentro del navegador con la lista de los
usuarios conectados en el sistema en ese momento.

Que existan otros usuarios conectados al sistema en ese momento.
10.2.3 Entrada
- Ingreso al sistema
Presentación del la lista de usuarios conectados al sistema.

182
Mensaje indicando que no existen otros usuarios conectados al sistema en ese
momento.
10.3.1 Descripción
Se deberá presentar una pantalla dentro del navegador con un mensaje
indicando que no existen otros usuarios conectados al sistema en ese
momento.

Que no existan otros usuarios conectados al sistema en ese momento.
10.3.3 Entrada
- Ingreso al sistema.

Presentación mensaje indicando que no existen usuarios conectados al sistema
en ese momento.

183
11. Historia 11:
Presentar una lista de los contactos del usuario.
11.1 Descripción

Presentar la lista de contactos del usuario identificado.
11.2.1 Descripción
Se deberá presentar una pantalla dentro del navegador con la lista de los
contactos del usuario identificado.

Que el usuario tenga una lista de contactos de otros usuarios del sistema.
11.2.3 Entrada
Presentación del la lista de contactos del usuario identificado.

184
Mensaje indicando que la lista de contactos del usuario identificado esta vacía.
11.3.1 Descripción
indicando que no tiene contactos en su lista.

Que no tenga agregado ningún contacto en su lista de contactos.
11.3.3 Entrada

Presentación mensaje indicando que la lista de contactos está vacía.

185
12. Historia 12:
Permitir a hacer una búsqueda de los usuarios del sistema.
12.1 Descripción

Buscar un usuario por su nombre o apellido.
12.2.1 Descripción
Se deberá presentar una pantalla dentro del navegador con un campo donde se
pueda ingresar el nombre o apellido de un usuario, e iniciar una búsqueda en el
sistema, al presionar el botón buscar.

Que existan coincidencias con el usuario buscado.
12.2.3 Entrada
- Ingreso de nombre o apellido del usuario que se está buscando.
Presentación del la lista de coincidencias con el usuario buscado.

186
Mensaje indicando que la no se han encontrado resultados en la búsqueda realizada.
12.3.1 Descripción
indicando que no hay coincidencias para la búsqueda realizada.

Que no haya coincidencias con el usuario buscado.
12.3.3 Entrada
- Ingreso de nombre o apellido del usuario que se está buscando.

Presentación mensaje indicando que no se han encontrado coincidencias con la
búsqueda.

187
13. Historia 13:
Presentar los mensajes recibidos de un usuario.
13.1 Descripción

Presentar los mensajes recibidos al usuario identificado.
13.2.1 Descripción
Se deberá presentar una pantalla dentro del navegador con un campo donde se
presente la lista de mensajes que el usuario ha recibido desde otros usuarios
del sistema, identificando cual ha sido el usuario que le ha enviado el mensaje.

Que existan mensajes pendientes por leer del usuario identificado.
13.2.3 Entrada
13.2.4Resultado esperado
Presentación del la lista mensajes pendientes por leer del usuario identificado.

188
Mensaje indicando que la no se han encontrado mensajes pendientes para el usuario
identificado.
13.3.1 Descripción
indicando que no hay mensajes pendientes.

Que no existan mensajes pendientes por leer del usuario identificado.
13.3.3 Entrada

Presentación mensaje indicando que no se han encontrado mensajes
pendientes.

189
14. Historia 14:
Permitir enviar un mensaje privado a cualquiera de los contactos del usuario, o a los
participantes de un curso en el que participa.
14.1 Descripción

Enviar mensaje privado a cualquiera de sus contactos.
14.2.1 Descripción
Se deberá presentar permitir la opción de enviar una mensaje privado a
cualquiera de los contactos, al seleccionarlo desde la lista de contactos,
aparecerá un área de texto donde se podrá escribir el mensaje, y un botón para
enviarlo al hacer clic sobre éste, y deberá aparecer la confirmación de que el
mensaje ha sido enviado, en caso de producirse un error aparecerá una alerta
con el mensaje de error.

Que existan usuarios en su lista de contactos.
14.2.3 Entrada
- Selección del contacto de su lista de contactos.
- Contenido del mensaje.

Mensaje de confirmación de que se ha enviado el mensaje, o alerta de error.

190
Enviar mensaje privado a cualquiera de los participantes de un curso en los que
también participa el usuario identificado.
14.3.1 Descripción
Se deberá presentar permitir la opción de enviar un mensaje privado a
cualquiera de los participantes de un curso, al seleccionarlo desde la lista de
participantes de un curso, aparecerá un área de texto donde se podrá escribir
el mensaje, y un botón para enviarlo al hacer clic sobre éste, y deberá aparecer
la confirmación de que el mensaje ha sido enviado, en caso de producirse un
error aparecerá una alerta con el mensaje de error.

Que existan usuarios en la lista de participantes del curso seleccionado.
14.3.3 Entrada
- Ingreso a un curso
- Selección del usuario de la lista de participantes del curso.
- Contenido del mensaje.

Mensaje de confirmación de que se ha enviado el mensaje, o alerta de error.

191
15. Historia 15:
Presentar el contenido en pantallas pequeñas que se puedan mover sobre la ventana
del navegador.
15.1 Descripción
Crear una interfaz dinámica para presentación de distintos recursos de Moodle en
diferentes pantallas pequeñas dentro de la ventana principal del navegador.

Verificar pantallas movibles.
15.2.1 Descripción
Luego de ingresar al sistema se deberá ingresar a una interfaz dinámica donde
se presentaran todos los servicios de moodle obtenidos mediantes servicios
web. Esta interfaz dinámica deberá presentar pantallas que se puedan ubicar
en distintos bloques dentro del navegador.

Haber ingresado al sistema en la presentación dinámica.
15.2.3 Entrada

Ventanas en el navegador que se puedan arrastrar hacia distintos bloques.

192
16. Historia 16:
Fijar estas pantallas pequeñas a distintos bloques dentro de la página, de manera que
aparezcan ordenadamente.
16.1 Descripción
Las pantallas dentro den navegados deberán adecuarse en distintos bloques,
permitiendo observar una o varias de las que se encuentren en cada bloque.

Verificar adaptación de las pantallas pequeñas dentro de los bloques.
16.2.1 Descripción
web. Esta interfaz dinámica deberá presentar pantallas que se puedan ubicar
en distintos bloques dentro del navegador, donde cada bloque puede contener
una o varias pantallas con distinta información.

Que exista más de una ventana pequeña dentro del navegador, para ajustarla a
los distintos bloques.
16.2.3 Entrada
- Movimiento de las pantallas pequeñas hacia otro bloque.

Agregar una o varias ventanas a los distintos bloques, permitiendo la
visualización de todas las ventanas en el bloque.

193
17. Historia 17:
Minimizar, maximizar, actualizar y cerrar las pantallas pequeñas con su contenido.
17.1 Descripción
Las pantallas pequeñas movibles deben tener la capacidad de hacerse más pequeñas
para ocultar su contenido, de maximizarse para presentar en la pantalla completa, y de
cerrarse.

Capacidad para minimizar, maximizar, actualizar y cerrar el contenido de las pantallas
pequeñas dentro del navegador.
17.2.1 Descripción
web. Esta interfaz dinámica deberá presentar una o varias pantallas pequeñas
dentro del navegador, con distintos contenidos, y cada una de estas pantallas
deberá tener la opción de minimizarse, maximizarse, cerrarse, y de actualizar su
contenido.

Que exista una o varias ventanas pequeñas dentro del navegador.
17.2.3 Entrada
- Seleccionar la opción minimizar/maximizar/actualizar/cerrar desde un
icono en la pantalla pequeña.

Ejecución de la acción seleccionada con la ventana pequeña que está dentro del
navegador:
Minimizar: Dejar visible únicamente el titulo de la ventana pequeña.
Maximizar: Hacer que la ventana pequeña ocupe el espacio completo dentro

del navegador.
194
Cerrar: Ocultar la pantalla pequeña de la lista de pantallas dentro del
navegador.

195
18. Historia 18:
Presentar un menú de con las pantallas movibles disponibles y que se puedan agregar
a la ventana inicial del navegador.
18.1 Descripción
Las pantallas pequeñas movibles deben presentarse en una lista, de donde se puedan
agregar a la ventana del navegador.

Presentación de un menú con la lista de pantallas pequeñas disponibles para agregarse
en la ventana principal del navegador.
18.2.1 Descripción
web. Esta interfaz dinámica deberá presentar una o varias pantallas pequeñas
dentro del navegador, y se presentará además una opción para desplegar una
ventana con la lista de todas las pantallas disponibles para agregarse en la
ventana principal del navegador.

“ M
.
18.2.3 Entrada
- Seleccionar M .

Aparición de una ventana con una lista de las ventanas pequeñas que se
pueden agregar en la ventana principal del navegador.

196
Agregar nueva ventana pequeña a la ventana principal del navegador.
18.3.1 Descripción
Cuando se haya seleccionad M
de la lista presentada por este menú se deberá poder agregar la ventana
pequeña a la a la ventana principal al dar clic sobre su nombre.

Haber abierto el menú con la lista de las pantallas pequeñas disponibles.
18.3.3 Entrada
- “ M
- Seleccionar una de las pantallas disponibles para agregase mostradas en
la lista presentada por el menú.

Aparición de la pantalla pequeña en la ventana principal del navegador.

197
19. Historia 19:
Presentar la información de Moodle obtenida mediante Web Services, en las pantallas
movibles dentro del navegador.
19.1 Descripción
Dentro de las pantallas movibles presentar información que normalmente se presenta
en bloques en moodle, esta información debe ser la obtenida mediante Web Services.

Presentar la información de Moodle obtenida mediante servicios web en las pantallas
19.2.1 Descripción
Las ventanas pequeñas que aparecerán dentro de la ventana principal del
navegador, deberán contener y gestionar la distinta información obtenida
mediante los servicios web de moodle, y se deberán realizar sobre estas las
operaciones necesarias para interactuar con moodle mediante los servicios
web.

Tener disponibles una o varias de las ventanas pequeñas dentro del navegador.
19.2.3 Entrada

Presentación en las ventanas pequeñas dentro del navegador, todas las
interacciones necesarias con moodle mediante servicios web.

198
20. Historia 20:
Presentar un espacio donde el usuario pueda agregar post, los cuales se compartirán
con todos sus contactos.
20.1 Descripción
agregar posts o anuncios que quiera compartir con sus contactos del sistema.

Agregar nuevo post.
20.2.1 Descripción
Luego de ingresar al sistema se deberá ingresar a una interfaz dinámica donde,
se presen se presentaran una o varias pantallas pequeñas dentro de la ventana
principal del navegador, una de estas pantallas pequeñas deberá contener un
espacio para que el usuario pueda realizar un post, el mismo que será
compartido con su lista de contactos.

Tener disponible la pantalla pequeña donde podrá realizar el post.
20.2.3 Entrada
- Contenido del post.

Agregación del nuevo post en una lista de post realizados.

199
Agregar un post vacio.
20.3.1 Descripción
Si el usuario intenta agregar un post vacio, deberá aparecer una alerte
indicando que el post debe poseer algún contenido.

Tener disponible la pantalla pequeña donde podrá realizar el post.
20.3.3 Entrada
- Contenido vacio del post.

Alerta indicando que el post no puede estar vacío.

200
21. Historia 21:
Presenta un listado de los post realizados del usuario, y también los realizados por
parte de sus contactos.
21.1 Descripción

Listado de post realizados por el usuario identificado.
21.2.1 Descripción
principal del navegador, una de estas pantallas pequeñas deberá contener la
lista de posts que ha realizado el usuario identificado actualmente.

21.2.3 Entrada

Una lista dentro de una ventana pequeña en el navegador, con todos los posts
que ha realizado el usuario identificado.

201
Listado de post realizados por los contactos del usuario identificado.
21.3.1 Descripción
principal del navegador, una de estas pantallas pequeñas deberá contener la
lista de posts que han realizado los contactos del usuario identificado.

21.3.3 Entrada

Una lista dentro de una ventana pequeña en el navegador, con todos los posts
que han realizado los contactos del usuario identificado.

202
22. Historia 22:
Permitir agregar comentarios en los posts de su red, ya sean de sus contactos, o los
suyos propios.
22.1 Descripción

Agregar comentarios a los posts propios del usuario y a los de sus contactos.
22.2.1 Descripción
Para cada post presentado en la lista de posts del usuario y de sus contactos
deberá existir la opción de agregar comentarios.

Tener disponible los posts realizados por el propio usuario, o por sus contactos.
22.2.3 Entrada
- Selección del post a comentar
- Contenido del comentario

Agregación del comentario realizado al correspondiente post.

203
Agregar comentario vacio a los posts propios del usuario y a los de sus contactos.
22.3.1 Descripción
Intentar agregar un post vacio en los posts del los contactos o a los propios del
usuario.

22.3.3 Entrada
- Selección del post a comentar
- Contenido vació del comentario

Alerta indicando que el comentario no puede estar vacío.

204
23. Historia 23:
Permitir eliminar sea posts o comentarios que sean de propiedad del usuario
identificado.
23.1 Descripción

Eliminar post.
23.2.1 Descripción
Para cada post presentado en la lista de posts del usuario y de sus contactos
deberá existir la opción de eliminar post, siempre y cuando el usuario
identificado sea el dueño del post.

23.2.3 Entrada
- Usuario identificado como dueño del post
- “ E

Eliminar el post junto con todos sus comentarios, y desaparecerlo de la lista.

205
Eliminar comentario.
23.3.1 Descripción
Para cada comentario presentado por cada uno de los posts del usuario y de
sus contactos deberá existir la opción de eliminar comentario, siempre y
cuando el usuario identificado sea el dueño del comentario a eliminar.

Tener disponible los comentarios de los posts realizados por el usuario.
23.3.3 Entrada
- Usuario identificado como dueño del comentario
- “ E comentario

Eliminar el comentario, y desaparecerlo de la lista de comentarios del post al
que pertenece.

206
24. Historia 24:
Permitir ingresar al muro de los contactos de la red del usuario.
24.1 Descripción
usuario.

Ingresar al muro de un usuario.
24.2.1 Descripción
El usuario debe tener la posibilidad de visitar el muro de sus contactos al
seleccionar la imagen de alguno de estos desde un post.

Tener disponible los posts realizados por el contactacto, al cual quiere visitar su
muro.
24.2.3 Entrada
- Seleccionar usuario al cual se va a realizar una visita a su muro.

Presentación de todos los posts y comentarios relacionados con el contacto al
que ha visitado.

207
25. Historia 25:
Presentar M
usuario dueño del post o comentario recibirá una notificación que ha dicho usuario le
ha gustado su anuncio.
25.1 Descripción
T M

D M .
25.2.1 Descripción
El usuario debe tener la posibilidad de seleccionar cualquiera de los posts o
M

Tener disponible los posts y comentarios realizados por sus contactos.
25.2.3 Entrada
- Seleccionar M .

Presentar mensaje que le ha gustado ese comentario.

208
Presentar notificación de que a un contacto le ha gustado una publicación del usuario
identificado.
25.3.1 Descripción
El usuario deberá tener un menú de notificaciones de a quienes les ha gustado
una publicación suya.

Q M .
25.3.3 Entrada
- Seleccionar el menú de notificaciones.

Presentar M
alguna de sus publicaciones.

209
26. Historia 26:
Presentar una lista de notificaciones con las actividades que se ha realizado
relacionadas con su red social.
26.1 Descripción
red social, por ejemplo, alguien aceptó una invitación suya de amistad, o alguien
comentó un post suyo.

Ver un menú de todas las notificaciones del usuario.
26.2.1 Descripción
Se le debe presentar al usuario un menú con las notificaciones que ha recibido
por alguna actividad en su red. Las actividades pueden ser que alguien comento
un post suyo, o que alguien acepto una solicitud de amistad suya.

Que se haya realizado alguna actividad en su red social.
26.2.3 Entrada
- Selección del menú de notificaciones

Presentar un menú con las notificaciones que ha recibió el usuario debido a
alguna acción realizada en su red.

210
27. Historia 27:
Presentar de los usuarios bloqueados.
27.1 Descripción
por él mismo.

Ver un menú de los usuarios bloqueados.
27.2.1 Descripción
Se le deberá presentar al usuario un menú con las lista de usuarios que han sido
bloqueados por él.

Tener al menos un usuario bloqueado.
27.2.3 Entrada
- Selección del menú de usuarios bloqueados

Presentación de un menú desplegable con todos los usuarios bloqueados.

211
Opción desbloquear de la lista del menú de usuarios bloqueados.
27.3.1 Descripción
Se le deberá presentar al usuario un menú con las lista de usuarios que han sido
bloqueados por él, y junto a cada usuario bloqueado la opción de
desbloquearlo.

Tener al menos un usuario bloqueado.
27.3.3 Entrada
- Selección del menú de usuarios bloqueados

Desbloqueo del usuario al elegir la opción desbloquear, y desaparecerlo de la
lista.

212
28. Historia 28:
Permitirle al usuario enviar invitaciones de amistad a otros usuarios del sistema, y
permitirle bloquearlos y eliminarlos.
28.1 Descripción
están entre sus contactos, si ya se encuentra entre sus contactos permitir bloquearlo, y
eliminarlo.

Enviar invitaciones de amistad.
28.2.1 Descripción
Se le deberá tener la opción de enviar solicitudes de amistad a usuarios que
aún no estén entre los contactos del usuario identificado, estas opciones se
presentarán al presentar un usuario como resultado de una búsqueda.

Que existan otros usuarios en el sistema.
Obtener resultados de una búsqueda de usuarios.
28.2.3 Entrada
- Seleccion rio.

Envió de la invitación de amistad, para agregarlo al usuario como contacto.

213
Opción bloquear un contacto.
28.3.1 Descripción
Se le deberá tener la opción de bloquear usuarios que estén entre los contactos
del usuario identificado, estas opciones se presentarán al presentar un usuario
como resultado de una búsqueda.

Que el usuario encontrado en la búsqueda sea un contacto del usuario

identificado.
28.3.3 Entrada
- “ B Contacto

Bloqueo del usuario que estaba como contacto.

214
Eliminar un contacto.
28.4.1 Descripción
Se le deberá tener la opción de eliminar contactos, esta opción se presentarán
al presentar un usuario como resultado de una búsqueda y éste sea contacto
del usuario identificado actualmente.

Que el usuario encontrado en la búsqueda sea un contacto del usuario

identificado.
28.4.3 Entrada
- “ Eliminar Contacto

Eliminar al usuario de la lista de contactos.

215
29. Historia 29:
Presentar para cada curso un espacio donde se gestionen posts y comentarios que
sean accesibles solamente a los participantes del curso.
29.1 Descripción

Presentación de posts y comentarios propios para cada curso.
29.2.1 Descripción
Se le deberá tener un espacio dentro de cada curso en donde se tenga una lista
de posts y comentarios que sean accesibles solamente a los participantes del
curso.

Haber ingresado a un curso.
Que existan posts y comentarios en el curso que se ha ingresado.
29.2.3Entrada
- Seleccionar un curso

Presentación de la lista de posts y comentarios hechos en el curso.

216
Opción de agregar posts y comentarios en red del curso.
29.3.1 Descripción
Además de tener un espacio dentro de cada curso en donde se tenga una lista
de posts y comentarios también se debe tener la opción de agregar mas posts y
comentarios por parte de los participantes del curso.

29.3.3 Entrada
- Contenido de anuncio

Agregar y presentar el nuevo post/comentario dentro de la lista de posts y
comentarios del curso.

217
Opción de eliminar posts y comentarios en red del curso.
29.4.1 Descripción
Se deberá tener la opción de eliminar los posts/comentarios, siempre que el
usuario sea el dueño del post/comentario.

29.4.3 Entrada
- “ E

Eliminar y desaparecer el post/comentario de la lista de posts y comentarios del
curso.

218
30. Historia 30:
Adaptación del desarrollo a Moodle 2.0.x.
30.1 Descripción

Funcionalidades desarrolladas para Moodle 1.9.x adaptadas a Moodle 2.0.x.
30.2.1 Descripción
Comprobar que todas las funcionalidades desarrolladas en Moodle 1.9.x
funcionen correctamente en Moodle 2.0.x.

Ingresar al sistema de Moodle, versión 2.0.x.
30.2.3 Entrada

Todas las funciones desarrolladas para Moodle 1.9.x funcionando
correctamente en Moodle 2.0.x.

219
ANEXO 8: RESULTADO DE
PRUEBAS UNITARIAS
220
Resultado de pruebas unitarias de los servicios web
Para realizar las pruebas unitarias de los servicios web se ha usado la herramienta
SOAP UI1, con dicha herramienta se han realizado las pruebas de cada función creada
de los servicios web, y además ha sido utilizada para obtener un reporte general del
estado de todas las funciones.
El total de funciones a probar son 63, las cuales han sido desarrolladas en su mayoría, y
algunas son parte del plugin para uso de servicios web en Moodle: Wspp2, el cual ha
sido usado en este proyecto.
En la siguiente imagen se muestra listadas las funciones a probar desde SOAP UI.
En el panel izquierdo se presenta la lista de funciones que se van a probar, y en el

panel derecho se presentarán los resultados de la prueba.
Para realizar la prueba de una determinada función, se debe seleccionarla dando doble
clic sobre el nombre de ésta, desde el panel derecho seleccionamos una aserción para
“OAP R s
respuesta del servicio web.
1
SmartBear SOFTWARE. [en línea] <http://www.soapui.org>. [citado en 18 de agosto del 2011]
2
PATRICK POLLET. ; [en línea] <http://cipcnet.insa-lyon.fr/Members/ppollet/public/moodlews> [citado
en 18 de agosto del 2011]
221
Una vez seleccionada la función a probar, y la aserción, entonces en el panel derecho
ejecutamos la prueba, dando clic sobre el botón ejecutar (icono color verde), en este
instante se ejecuta la prueba y nos presenta los resultados:
- Datos de salida (formato XML)

- Estado de la respuesta. (VALID o NO VALID)
Para realizar una prueba del uso de la herramienta, se muestra en la siguiente imagen
222
Con este proceso ha sido probada cada una de las 63 funciones que se usan, sin
embargo, considerando la cantidad de casos de prueba, en este documento se
presenta un reporte general del estado de los casos de prueba, realizado con la misma
herramienta.
Se selecciona el contenedor de todos los casos de prueba, y al dar clic sobre el botón
ejecutar (ícono color verde), se realizan cada uno de los casos de prueba
automáticamente, presentando en color verde el estado de los casos finalizados con
éxito, y en color rojo en los que se han presentado problemas.
En la siguiente imagen se presenta el resultado de la ejecución de todos los casos de

preuba:
223
A continuación se presenta el reporte general de los casos de prueba a cada una de las
funciones de los servicios web. Este reporte ha sido generado por la herramienta SOAP
UI.
Test Results
Summary
TestCases Failures Errors Success rate Time
63 0 0 100.00% 64.380
Projects
Project moodle_widgets
Name TestCases Erro Failures Time Host

rs (s)
moodle_widgets.Moodl 63 0 0 64.380
eWS
TestSuite moodle_widgets.MoodleWS
TestCase Status Time (s)

accept_noaccept_invitation TestCase Success 0.979
add_assignment TestCase Success 1.663
add_assignment2 TestCase Success 0.896
add_comment_in_rsa TestCase Success 1.057
add_forum TestCase Success 0.838
add_post_in_rsa TestCase Success 0.856
add_quiz_mod TestCase Success 0.877
add_resource_mod TestCase Success 0.882
add_section TestCase Success 1.078
allow_comments TestCase Success 1.597
delete_ads_with_comments TestCase Success 1.030
delete_comment_in_rsa TestCase Success 1.019
delete_mod_from_course_section Success 0.827
TestCase
224
delete_post TestCase Success 0.824
edit_ad_insection TestCase Success 0.867
edit_assignments TestCase Success 0.905
edit_forums TestCase Success 0.833
forum_add_discussion TestCase Success 0.862
forum_add_reply TestCase Success 0.890
forum_delete_discussion TestCase Success 1.076
get_activities TestCase Success 1.068
get_activitiesmuro TestCase Success 0.816
get_ads_in_course TestCase Success 0.801
get_all_assignments TestCase Success 0.813
get_all_forums TestCase Success 0.807
get_all_quizzes TestCase Success 0.818
get_assignment_submissions TestCase Success 1.042
get_categories TestCase Success 0.815
get_comments_rsa TestCase Success 0.900
get_contacts TestCase Success 0.858
get_forum_discussions TestCase Success 0.977
get_forum_posts TestCase Success 1.068
get_forums_bycourse TestCase Success 0.954
get_invitations TestCase Success 0.835
get_messages TestCase Success 0.894
get_more_users TestCase Success 0.847
get_my_courses_byusername TestCase Success 1.031
get_my_id TestCase Success 0.904
get_new_idsection TestCase Success 0.937
get_notifications TestCase Success 0.989
get_number_new_notifications Success 0.844
TestCase
get_participants_in_course TestCase Success 0.867
get_posts_rsa TestCase Success 0.856
get_posts_rsa_course TestCase Success 0.857
get_resources TestCase Success 0.923
get_user TestCase Success 0.823
get_user_byid TestCase Success 0.898
get_users_bycourse TestCase Success 1.333
get_users_online TestCase Success 1.733
is_teacher_in_course TestCase Success 1.216
login TestCase Success 2.095
logout TestCase Success 0.826
message_add_contact TestCase Success 1.190
message_block_contact TestCase Success 1.184
message_move_toreaded TestCase Success 1.251
message_remove_contact TestCase Success 1.215
message_send TestCase Success 1.216
message_unblock_contact TestCase Success 0.843
register_activity TestCase Success 1.193
225
register_notification_log TestCase Success 1.501
remove_post_to_discussion TestCase Success 1.147
update_section TestCase Success 0.876
update_user TestCase Success 1.463
226
ANEXO 9: RESULTADO DE
PRUEBAS UNITARIAS
227
Resultado de Pruebas Funcionales
A continuación se presenta una matriz que nos muestra el resultado de las pruebas de
aceptación o funcionales realizadas al sistema.
- Nombre del caso de prueba: Nombre para identificar el caso de prueba.

- Resultado: Prueba satisfactoria o Prueba Errónea
- Estado: Abierto o Cerrado
Nombre del caso de prueba Resultado Estado

Autenticación incorrecta de un Prueba Satisfactoria Cerrado
usuario por medio de servicios
web.
Autenticación correcta de un Prueba Satisfactoria Cerrado
usuario por medio de servicios
web
Presentación de los cursos en los Prueba Satisfactoria Cerrado
cuales el usuario identificado
cumple un rol, sea de profesor o
de estudiante.
Presentación de cada uno de los Prueba Satisfactoria Cerrado
cursos clasificados de acuerdo a
la categoría a la que pertenecen.
Presentación de mensaje Prueba Satisfactoria Cerrado

indicando que el usuario no
tiene rol como profesor o como
estudiante en ninguno de los
cursos.
Presentación de una lista con los Prueba Satisfactoria Cerrado

participantes del curso al
ingresar a uno de los cursos en
los que el usuario tiene un rol de
profesor o estudiante.
Presentación de una lista con los Prueba Satisfactoria Cerrado

participantes del curso
clasificados de acuerdo a su rol,
sea de profesor o estudiante.

indicando que el curso no tiene
228
usuarios con rol de profesor y/o
estudiante.
Presentación del último de los Prueba Satisfactoria Cerrado

anuncios del profesor en el
curso, permitiendo al usuario
navegar además por todos los
anteriores.
indicando que no hay anuncios
en el curso.
Presentar la opción de agregar Prueba Satisfactoria Cerrado

anuncio cuando el usuario tiene
rol de profesor en el curso.
Posibilidad de editar los Prueba Satisfactoria Cerrado
anuncios de un curso, solo
cuando el usuario tiene rol de
profesor en el curso.
No permitir editar, ni agregar Prueba Satisfactoria Cerrado

nuevos anuncios cuando el
usuario no tenga rol de profesor
en el curso seleccionado.
Presentar la opción de agregar Prueba Satisfactoria Cerrado

tarea cuando el usuario tiene rol
de profesor en el curso.
Presentar mensaje de error al Prueba Satisfactoria Cerrado

agregar tarea, cuando no se han
enviado los datos requeridos
para la nueva tarea.
Presentar las los archivos que los Prueba Satisfactoria Cerrado

estudiantes han subido en las
tareas, cuando el usuario tiene
rol de profesor.
No presentar la opción de Prueba Satisfactoria Cerrado

agregar nuevas tareas, ni de ver
los archivos subidos por los
estudiantes en las tareas cuando
el usuario tiene rol de
estudiante.
229
Ver la lista de foros disponibles Prueba Satisfactoria Cerrado
en el curso.
Ver la lista de discusiones de Prueba Satisfactoria Cerrado

cada foro del curso.
Agregar posts a los temas de Prueba Satisfactoria Cerrado

discusión del foro.
Agregar nuevo foro en el curso. Prueba Satisfactoria Cerrado
Agregar nueva discusión en el Prueba Satisfactoria Cerrado

foro del curso.
Mensaje indicando que no Prueba Satisfactoria Cerrado

existen foros disponibles en el
curso.
Ver la lista de recursos Prueba Satisfactoria Cerrado

disponibles en el curso.

existen recursos para el curso
seleccionado.
Presentar la lista de Prueba Satisfactoria Cerrado

cuestionarios disponibles en el
curso.

existen cuestionarios para el
curso seleccionado.
Presentar la lista de usuarios Prueba Satisfactoria Cerrado

conectados al sistema.

existen otros usuarios
conectados al sistema en ese
momento.
Presentar la lista de contactos Prueba Satisfactoria Cerrado
230
del usuario identificado.
Mensaje indicando que la lista Prueba Satisfactoria Cerrado

de contactos del usuario
identificado está vacía.
Buscar un usuario por su nombre Prueba Satisfactoria Cerrado

o apellido.
Mensaje indicando que la no se Prueba Satisfactoria Cerrado

han encontrado resultados en la
búsqueda realizada
Presentar los mensajes recibidos Prueba Satisfactoria Cerrado
al usuario identificado.
Mensaje indicando que la no se Prueba Satisfactoria Cerrado

han encontrado mensajes
pendientes para el usuario
identificado.
Enviar mensaje privado a Prueba Satisfactoria Cerrado
cualquiera de sus contactos.
Enviar mensaje privado a Prueba Satisfactoria Cerrado

cualquiera de los participantes
de un curso en los que también
participa el usuario identificado
Verificar pantallas movibles. Prueba Satisfactoria Cerrado
Verificar adaptación de las Prueba Satisfactoria Cerrado

pantallas pequeñas dentro de
los bloques.
Capacidad para minimizar, Prueba Satisfactoria Cerrado
maximizar, actualizar y cerrar el
contenido de las pantallas
pequeñas dentro del navegador
Presentación de un menú con la Prueba Satisfactoria Cerrado
lista de pantallas pequeñas
disponibles para agregarse en la
ventana principal del navegador.
Agregar nueva ventana pequeña Prueba Satisfactoria Cerrado

a la ventana principal del
navegador.
231
Presentar la información de Prueba Satisfactoria Cerrado
Moodle obtenida mediante
servicios web en las pantallas
Agregar nuevo post. Prueba Satisfactoria Cerrado
Agregar un post vacio. Prueba Satisfactoria Cerrado
Listado de post realizados por el Prueba Satisfactoria Cerrado

Cerrado Listado de post Prueba Satisfactoria Cerrado

realizados por los contactos del
Agregar comentarios a los posts Prueba Satisfactoria Cerrado

propios del usuario y a los de sus
contactos.
Agregar comentario vacio a los Prueba Satisfactoria Cerrado

posts propios del usuario y a los
de sus contactos.
Cerrado Eliminar post. Prueba Satisfactoria Cerrado
Eliminar comentario. Prueba Satisfactoria Cerrado
Ingresar al muro de un usuario. Prueba Satisfactoria Cerrado
D M Prueba Satisfactoria Cerrado

de los posts o comentarios de
los contactos.
Presentar notificación de que a Prueba Satisfactoria Cerrado

un contacto le ha gustado una
publicación del usuario
identificado.
Ver un menú de todas las Prueba Satisfactoria Cerrado

notificaciones del usuario.
Ver un menú de los usuarios Prueba Satisfactoria Cerrado

bloqueados.
Opción desbloquear de la lista Prueba Satisfactoria Cerrado
232
del menú de usuarios
bloqueados.
Enviar invitaciones de amistad. Prueba Satisfactoria Cerrado
Opción bloquear un contacto. Prueba Satisfactoria Cerrado
Eliminar un contacto. Prueba Satisfactoria Cerrado
Presentación de posts y Prueba Satisfactoria Cerrado

comentarios propios para cada
curso.
Opción de agregar posts y Prueba Satisfactoria Cerrado

comentarios en red del curso
Opción de eliminar posts y Prueba Satisfactoria Cerrado
comentarios en red del curso
Funcionalidades desarrolladas Prueba Satisfactoria Cerrado
para Moodle 1.9.x adaptadas a
Moodle 2.0.x.
233
ANEXO 10: MANUAL DE
INSTALACIÓN DEL SISTEMA
234
Modificaciones en Moodle Para la Implementación de una Capa de Widgets, y
una Capa de Red Social mediante el uso de servicios web alojados en una Capa
de Web Services
El desarrollo de las capas que serán implementadas, se han realizado para las versiones de
Moodle 1.9.x y 2.0.x, por tanto tener en cuenta las indicaciones de los cambios para cada
versión.
Modificaciones en Moodle 1.9.x y Moodle 2.0.x
1. Modificar el archivo: index.php del directorio raíz de Moodle
Para forzar el logueo
Agregar:
if(empty($USER->id)){
redirect($CFG->wwwroot.'/login/index.php');
}
Después de: require_once('config.php');
Para dirigirse a la presentación en widgets al ingresar al sistema

Reemplazar: $urltogo = $CFG->wwwroot.'/';
Por: $urltogo = $CFG->WIDGETS.'/';
Después del comentario: // no wantsurl stored or external - go to homepage
Y antes de: unset($SESSION->wantsurl);
2. Modificar el archivo: directorio_raíz/login/index.php
Para loguearse mediante servicios web
Agregar:
require_once($CFG->dirroot."/wspp/clients/classes/MoodleWS.php");
$moodle = new MoodleWS();
Después de: require('../config.php');
235
Agregar:
if($user && $frm->username!="guest"){//si se autentica bien con moodle, lo
autentico con el web service
$lr= $moodle->login($frm->username,$frm->password);
$_SESSION['usuario']=$lr->client;//paso las variables con SESSION
$_SESSION['clave_sesion']=$lr->sessionkey;
}
Después de: $user = authenticate_user_login($frm->username, $frm->password);
3. Modificar el archivo: directorio_raíz/login/logout.php
Para cerrar session de servicios web
Agregar:
require_once($CFG->dirroot."/wspp/clients/classes/MoodleWS.php");
$moodle = new MoodleWS();
Después de: require_once('../config.php');
Agregar:
$usuario=$_SESSION['usuario'];
$clave_session=$_SESSION['clave_sesion'];
$moodle->logout($usuario,$clave_session);
Antes de: require_logout();
4. Modificar el archivo: directorio_raíz/login/index_form.html
Para impedir el ingreso como invitado
Moodle 1.9 despues de: <?php if ($CFG->guestloginbutton) { ?>

Moodle 2.0 despues de: <?php if ($CFG->guestloginbutton and !isguestuser()) { ?>
Comentar desde: : M 2.0: línea 52 - M 1.9: línea 48

Hasta: </div> : M 2.0: línea 64 - M 1.9: línea 60
236
5. Modificar el archivo: directorio_raíz/course/lib.php
Para identificar al usuario que ha agregado un modulo o un anuncio en un curso

Agregar:
set_field("course_sections", "id_usuario", $USER->id, "id", $section->id);
Despues de :
if (set_field("course_sections", "sequence", $newsequence, "id", $section->id)) {
En la funcion:
add_mod_to_section($mod, $beforemod=NULL)
6. Modificar el archivo: directorio_raíz/mod/quiz/lib.php
En la función:
function quiz_add_instance ($quiz)
Agregar parámetro: $ws=false

function quiz_add_instance ($quiz, $ws=false) {
Dentro de la misma función agregar (solo lo resaltado en negrita):

if(!$ws){
$result = quiz_process_options($quiz);
if ($result && is_string($result)) {
return $result;
}
}
7. Modificar el archivo: directorio_raíz/config.php
Agregar después de: $CFG->admin = 'admin';
Las siguientes variables:
$CFG->IMG = $CFG->wwwroot.'/capa_rsa/RSA/IMG';
237
$CFG->IMG2 = $CFG->wwwroot.'/capa_rsa/user/pix.php';
$CFG->JS = $CFG->dirroot.'/capa_rsa/RSA/JS';
$CFG->CSS = $CFG->dirroot.'/capa_rsa/RSA/CSS';
$CFG->PHP = $CFG->dirroot.'/capa_rsa/RSA/PHP';
$CFG->SERVICIOS = $CFG->wwwroot.'/capa_rsa/widgetsRSA/services';
$CFG->WIDGETS_RSA = $CFG->wwwroot.'/capa_rsa/widgetsRSA/RSA';
$CFG->WIDGETS = $CFG->wwwroot.'/capa_rsa/widgetsRSA';
$CFG->limite_post_widgets ='5';
$CFG->limit_topost_incourse ='2';
$CFG->limit_old_notif_widgets ='3';
$CFG->limite_cursos='2';
$CFG->limite_consulta ='10';
$CFG->limite_com ='2';
$CFG->limite_com_dinamico ='2';
$CFG->limite_desbloquear='5';
$CFG->limite_invitaciones='5';
$CFG->limite_notificaciones='5';
$CFG->actividades='4';
$CFG->intervalo_dias='1';
$CFG->id_usuario_comun ='4182';
$CFG->id_admin ='2';
$CFG->rol_profesor ='3';
$CFG->tamano_maximo_post='144';
$CFG->tamano_maximo_comentarios='144';
___________________________________________________________________________
Modificaciones únicamente en Moodle 2.0.x
1. Modificar el archivo: directorio_raíz/mod/quiz/lib.php
En la función:
quiz_after_add_or_update
Comentar el bucle for:

Desde: for ($i = 0; $i <= $quiz->feedbackboundarycount; $i++) {
Hasta que cierra éste en: }
238
2. Modificar el archivo: directorio_raíz/mod/page/lib.php
En la función:
function page_add_instance($data, $mform)
Agregar parámetro: $ws=false

function page_add_instance($data, $mform, $ws=false) {
Dentro de la misma función agregar (solo lo resaltado en negrita):

if(!$ws){
$data->content = $data->page['text'];
$data->contentformat = $data->page['format'];
}
Instalación del Plugin WSPP_UTPL Para el Uso de Servicios Web
El plugin WSPP_UTPL, una versión mejorada del plugin WSPP para servicios web en moodle, el
mismo que contiene todos los servicios necesarios para la implementación de la capa de
widgets y de la capa de red social.
Nota: Tener en cuenta que los archivos proveidos en el plugin son diferentes para las versiones
de Moodle 1.9.x y 2.0.x.
Instalación de wspp_utpl en Moodle 1.9.x
A M
Descomprimmir el archivo M
dentro del directorio raiz de moodle.
C
E
require("$CFG->dirroot/wspp/admin/wspp.php"); justo antes del comentario:
// hidden scripts linked from elsewhere.
Ir al sitio de Administración de Moodle(Ingresar como administrador), y establecer las
opciones de administración en: /Administration/misc/OK Tech Webservice.
239
Nótese que la actualización de la base de datos se realiza después de la primera llamada
a los servicios web.
Instalación de wspp_utpl en Moodle 2.0.x
A M
D M
dentro del directorio raiz de moodle.
Copiar el contenido del directorio directorio
Ingresar como administrador, e ir a Notifications para instalar el plugin.

Las opciones de administración están en: /Administration/misc/OK Tech Webservice
(aka wspp).
En ese instante queda actualizada la base de datos.
Configuración del plugin WSPP_UTPL para la adaptación al servidor Moodle sobre el cual se
está instalando (válido para Moodle 1.9.x y 2.0.x)
E
comando:
php ../client_wspp_utplwsdl2php.php http://sumoodle/wspp/wsdl_pp.php
Por ejemplo si se está usando xampp, se puede copiar el directorio:

../htdocs/ y luego ejecutar el comando:
(en linux)
$ php /opt/lampp/htdocs/client_wspp_utpl/wsdl2php.php
http://sumoodle/wspp/wsdl_pp.php
(en windows)
c:\xampp\php>php c:\xampp\htdocs\client_wspp_utpl/wsdl2php.php
http://sumoodle/wspp/wsdl_pp.php
Reempla E
directorio classes contiene las referencias hacia las funciones de los servicios web.
A T
M W“
siguiente:
private function castTo($className,$res){
240
if (class_exists($className)) {
$aux= new $className();
foreach ($res as $key=>$value)
$aux->$key=$value;
return $aux;
} else
return $res;
}
Con esto estamos listos para usar el plugin wspp_utpl.
Instalación de una Capa de Usuario Final Basada en Web Services
Una vez que se han seguido todos los pasos anteriores, es posible realizar la instalación de una
capa de usuario final basada en web services, en la cual se presenta una interfaz basada en
widgets, y una red social dentro de la plataforma de aprendizaje Moodle.
Esta capa de usuario final tiene unas pocas diferencias para las versiones de Moodle 1.9.x y
2.0.x, por lo que se presenta una para cada versión.
D _M19 ó _M20 (dependiendo de la

versión de Moodle), y copiar el directorio capa_rsa con todo su
contenido hacia el directorio raíz de moodle.
A “QL
Moodle.
En Moodle 1.9.x
Copiar el archivo
En Moodle 2.0.x
C (con todo su contenido) hacia
I “ L L
Elegir un lenguaje para comprobar las cadenas

C C
241
E
plugin.
Con esto queda instalada la capa de usuario final, brindando una mejor usabilidad a Moodle.
Ahora nos dirigimos hacia la ubicación de nuestro servidor Moodle, ingresamos con nuestro
usuario y contraseña, y seremos dirigidos hacia la presentación de la capa de usuario final
basada en servicios web, con una interfaz basada en widgets, en donde además tenemos la
incorporación de una red social de aprendizaje.
La ventana principal de Moodle implementando la capa de usuario final se presenta en la

siguiente figura:
Ilustración 1 Ventana principal de Moodle implementando una capa de usuario final
242
ANEXO 11: MANUAL DE
USUARIO DEL SISTEMA
243
Manual de Usuario del Sistema
El sistema desarrollado forma parte de la plataforma educativa virtual Moodle 1, tal
como fue el objetivo del proyecto se ha realizado una presentación con una interfaz
dinámica basada en widgets, y todos los recursos usados en el sistema consumen los
servicios web de la misma plataforma.
El sistema se encuentra alojado en la siguiente dirección:

http://www.glesone.org/moodle_widgets Moodle 1.9
http://www.glesone.org/moodle20_widgets Moodle 2.0
El funcionamiento del sistema es igual para ambas versiones.
Pantalla de Ingreso
Ingresando desde un navegador web al enlace mostrado anteriormente, nos

encontraremos con la pantalla de ingreso, en la cual debemos ingresar los datos de
nombre de usuario y contraseña E
tal como se muestra en la siguiente imagen
Ilustración 1 Formulario de ingreso al sistema
1
MOODLE; [en linea] <http://moodle.org/>
244
Una vez que hemos ingresado con un usuario y una contraseña correctos, nos
dirigimos automáticamente a la presentación del sistema en una interface basada en
widgets.
El sistema hace diferencia entre usuarios con rol de profesor, y usuarios con rol de
estudiante para cada curso, la distinción del rol es únicamente dentro de cada curso.
Pantalla Principal (Inicio)
La pantalla principal luego del ingreso al sistema es mostrada en la siguiente figura:
Ilustración 2 Pantalla principal
En esta pantalla se presentan los siguientes widgets:
- Cursos: Lista de cursos en los que el usuario tiene rol de profesor o estudiante.
- Perfil de usuario: Perfil de usuario del usuario actualmente identificado.
- Red Social: Red social principal del usuario.
Por defecto se presenta de esa forma, sin embargo al ser una presentación en widgets
el usuario puede ordenar la presentación como mejor le parezca, incluso cerrar los
widgets aquí presentados y agregar otros que estén disponibles.
245
Menu de Widgets
En la pantalla principal se puede observar en la parte superior derecha un icono

llamado menú de widgets. Al dar clic sobre este ícono se despliega una pantalla que
contiene todos los widgets disponibles para agregarlos a la pantalla principal.
El menú desplegado es mostrado en la siguiente figura:
Ilustración 3 Menu de Widgets
Dando clic sobre alguno de los widgets listados, éste se agregará a la pantalla principal
en la columna indicada (por defecto se agregara a la columna 1).
Pantalla Amigos
En la presentación inicial además se puede observar una pestañ A a la cual

nos podemos dirigir dando clic sobre la misma, en esta se presentan algunos otros
widgets, tal como se muestra en la siguiente figura.
246
Ilustración 4 Pantalla Amigos
- Contactos: Contactos del usuario para su red social

- Buscar Persona: Espacio para buscar amigos para la red social.
- Usuarios Conectados: Usuarios conectados al sistema.
- Mensajes Recibidos: Mensajes privados que otros usuarios han enviado al
actual usuario.
Pantalla Curso
En esta pantalla se muestran los widgets con información de un curso, luego de que
haya sido seleccionado desde el C presentado en la pantalla inicial.
Al dar clic sobre alguno de los cursos del usuario desde el C

M C
pestaña, cambiara por el nombre del curso seleccionado.
En la figura siguiente se muestra el sistema cuando se ha ingresado a uno de los

cursos.
247
Ilustración 5 Pantalla Mi Curso (rol de estudiante)
- Usuarios Conectados: Usuarios conectados al sistema.

- Mensajes Recibidos: Mensajes privados que otros usuarios han enviado al
actual usuario.
- Red Social de Curso: Una red social para agregar posts y comentarios dentro de
un curso, como amigos de la red están los participantes del curso.
- Recursos: Los recursos que están disponibles en el curso.
- Participantes: Lista los participantes de ese curso, clasificándolos de acuerdo a
su rol de profesor o estudiante en el curso.
- Anuncios Profesor: Lista los anuncios que ha hecho un profesor en las secciones
del curso.
- Cuestionarios: Presenta los cuestionarios que están disponibles en el curso.
- Tareas: lista las tareas que existen para un curso
- Foros: Lista los foros del curso, se puede ingresar a estos para agregar
discusiones en el caso de tener rol de profesor, si únicamente tiene rol de
estudiante solo podrá agregar posts a las discusiones.
248
Cuando el usuario tiene rol de profesor en el curso, se presentarán unas opciones
adicionales, en donde el profesor puede agregar más módulos (como foros, tareas,
cuestionarios, recursos) en el curso.
En la siguiente figura se muestra a un usuario con rol de profesor dentro de un curso.
Ilustración 6 Pantalla Mi Curso (rol de profesor)
La diferencia está en los siguientes widgets.
- Cuestionarios
- Tareas
- Recursos
- Foros
En estos widgets se presenta al usuario (con rol de profesor) la opción de agregar uno
(módulo) nuevo, y de eliminarlo.
249
Red Social
Existen dos tipos de red social, una es la red social principal del usuario y es la que se
presenta al ingresar al sistema, y además existe una red social para cada curso.
Cada una de estas redes sociales se encuentra en un widget diferente, sin embargo las
funcionalidades que brindan son las mismas, por lo que únicamente se hará mención a
la red social principal.
El widget de la red social se muestra en la siguiente figura.
Ilustración 7 Red Social
El uso de la red social es bastante intuitiva, tiene las funcionalidades tradicionales de

una red social, como:
- Agregar nuevo post

- Agregar nuevo comentario
- Eliminar post y/o comentario (siempre y cuando sea el propietario)
250
- Menú de notificaciones: Actividad en la red social, solicitud de amistad,
- Agregar enlaces de video.
- Mostrar los siguientes comentarios.
251
ANEXO 12: ENCUESTA
SOBRE USO DEL SISTEMA
252
En este anexo se adjunta una encuesta realizada a usuarios que han probado el
sistema, en base a la cual se han tomado varias conclusiones respecto al proyecto.
¿Considera que el uso de la web 2.0 en la educación mejora la interacción entre los sistemas e-learning
con los alumnos?
SI 24 100%
NO 0 0%
¿Cree que la implementación de una red social sobre un entorno virtual de aprendizaje es un aporte
significativo e innovador en la educación de los estudiantes de la UTPL?
SI 19 79%
NO 5 21%
¿Cree que la presentación de recursos educativos, mediante una interfaz dinámica como la de Glesone
(versión widgets) incentiva el uso de los entornos virtuales de aprendizaje?
SI 23 96%
NO 1 4%
253
¿Considera importante y/o necesario que los recursos de un entorno virtual de aprendizaje estén
disponibles para uso de otras aplicaciones?
SI 23 96%
NO 1 4%
¿Cuál sería su calificación al proyecto Glesone (versión widgets) en cuanto a la mejora del proceso de
aprendizaje?
Excelente 10 42%
Buena 14 58%
Mala 0 0%
Regular 0 0%
Pésima 0 0%
¿Considera una interfaz configurable por el usuario brinda mayor comodidad y sencillez a la hora de
interactuar con un entorno virtual de aprendizaje?
SI 23 96%
NO 1 4%
254
Con la incorporación de elementos de la web 2.0 a un entorno virtual de aprendizaje, ¿cree que éste
tendría mayor probabilidad de extenderse a un uso masivo por parte de usuarios alrededor del mundo?
SI 23 96%
NO 1 4%
¿Cómo cree que es actualmente su participación en el entorno virtual de aprendizaje de la UTPL?
Altamente activa 3 13%
Medianamente activa 16 67%

Poco activa 5 21%
¿Cómo cree que sería su participación en el entorno virtual de aprendizaje de la UTPL, si se implementa
una nueva versión con las características incorporadas en este proyecto?
Altamente activa 16 67%
Medianamente activa 8 33%
Poco activa 0 0%
¿Considera oportuno darle continuidad a este proyecto, es decir que tiene bases para llegar a ser un
gran sistema?
SI 22 92%
NO 2 8%
¿Qué nuevos proyectos recomendaría como continuidad de éste? (Opcional)
Creación de un servidor para chat en tiempo real

Creación de espacios de chat y foros
Implementación de APIs de las herramientas de la web 2.0 orientadas a la educación,
incluyendo tutoriales ya sean en video o texto que personalmente puedo asegurar
tiene mucha información mucha más explicativa y demostrativa que un OCW
255
Proyectos de Incorporación de Recursos Educativos de Aprendizaje, para dispositivos
móviles.
Implementación de proyectos que permiten disponer de un dataset de OERs
expresados en lenguaje RDF.
Acceso móvil a la plataforma Así como avisos de tareas y evaluaciones al teléfono.
Recomendaciones Num. De usuarios

A Creación de servidor de chat en tiempo real 2
B Implementación de APIS orientadas a la educación 1
C Adaptación a plataformas móviles 2
D Creación de datasets de OERs expresados en lenguaje RDF 1
E Notificaciones al móvil 1
F Integracion de cursos OCW 1
2,5
1,5
0,5
0
A B C D E F
256
PAPER
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
Juan C. Torres1, Marco. P. Abad2, Esteban Y. Chamba .3
Resumen Las plataformas e-learning han sido

desarrolladas con el fin de mejorar los procesos de
7 Widgets Aplicaciones web livianas, los cuales son diseñados para
enseñanza-aprendizaje, cambiando el esquema tradicional, una función específica y para un rápido acceso a servicios
en donde estudiante y profesor deben ocupar un mismo 8 de la Web 2.0 o contenido de internet.
espacio físico al momento de intercambiar información, a un Red
Centro de Investigación Sísmica del Pacifico en Estados
esquema en donde se puede compartir un mismo curso con social
miles de usuarios conectados a través de una plataforma e-
learning desde distintos lugares geográficos.
INTRODUCCIÓN
Una de estas plataformas, que posee muchos usuarios a
nivel mundial es Moodle, sin embargo, aunque cumple con Desde la aparición de la Web 2.0, la cual ha dado
los principios básicos para el proceso de enseñanza- un giro total al esquema tradicional de presentación de
aprendizaje en línea, deja mucho que desear en cuanto a las recursos en internet, las necesidades de los sistemas han
nuevas tendencias en la web, como es el tema de la web 2.0 cambiado mucho, al igual que han cambiado también las
y de las redes sociales. necesidades y exigencias de los usuarios de sistemas
disponibles en internet, esto obliga a que sistemas anteriores
Se ha considerado sumamente importante la necesidad de se actualicen al nuevo esquema que plantea la Web 2.0 y a
incorporar las nuevas tendencias de la web a la plataforma los nuevos sistemas a desarrollarse bajo estándares de la web
e-learning Moodle en sus versiones 1.9.x y 2.0.x, con este moderna, esto con la finalidad de brindar un mejor servicio
objetivo se han desarrollado e implementado tres nuevas al usuario final y de tener una mejor aceptación de parte de
capas sobre las versiones mencionadas de Moodle, estas los mismos.
capas son: capa de web services, capa de widgets, y una
capa de red social. Con esto se pretende integrar Entre las propuestas de la Web 2.0 tenemos:
componentes modernos y eficaces en los sistemas de permitir a las aplicaciones tener la capacidad de interactuar
aprendizaje en línea, particularmente en la plataforma e- con otros sistemas diferentes, y tener ambientes
learning Moodle, y así lograr un mejor rendimiento tanto en personalizables dependiendo de las necesidades del usuario.
el proceso de enseñanza como en el proceso de aprendizaje. En los estudiantes de la UTPL el conocimiento sobre Web
2.0, y el uso de sistemas que basados en la web moderna y
TABLE I colaborativa es bastante amplio, sin embargo el entorno
TÉRMINOS CLAVE virtual de aprendizaje (basado en la plataforma e-learning
Nro Término Descripción. Moodle) usado por los estudiantes no presenta las
1 UTPL Universidad Técnica Particular de Loja características suficientes para una perfecta compatibilidad
2 XML
con la web moderna.
Es el fundamento básico sobre el cual se
construyen los servicios web, provee un
Se considera sumamente necesario innovar, y
lenguaje para definición y procesamiento de
actualizar el sistema para que cumpla con los requerimientos
datos
de la web moderna y así brindar un mejor servicio a los
3 AJAX Asíncrono entre JAVA y XML. usuarios, presentando un ambiente más colaborativo y
personalizable para aquellos quienes hagan uso de la
4 e-learning Aprendizaje electrónico. plataforma Moodle.
5 Moodle Plataforma e-learning.
Web Aplicaciones para brindar servicio a otras aplicaciones a

6 services través de la red.
1
Ing. Juan Carlos Torres., Universidad Técnica Particular de Loja, San Cayetano Alto, jctorres@utpl.edu.ec
2
Ing. Marco Paticio Abad. , Universidad Técnica Particular de Loja, San Cayetano Alto, mpabad@utpl.edu.ec
3
Esteban Yomairo. Chamba. , Universidad Técnica Particular de Loja, San Cayetano Alto, eychamba@utpl.edu.ec
DESCRIPCIÓN DE LA SOLUCIÓN
La implementación de las nuevas capas será sobre las
Como respuesta a la necesidad de innovar y partir
hacia un ambiente de web moderna, se ha considerado versiones estables de Moodle 1.9.x y Moodle 2.0.x.
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 Estado Actual
usuarios una mejor experiencia de usuario a través de una Con lo que actualmente se cuenta para dar inicio al
capa de interfaces configurables, personalizables y proyecto, es con las versiones necesarias de la plataforma
dinámicas, se incluye en concepto de widgets. Moodle (Moodle 1.9.x y Moodle 2.0.x), éste es el núcleo
sobre el cual se agregarán los nuevos servicios.
Las redes sociales han sido un paso gigantesco en la
web moderna, razón por la que se incluye también el Además se cuenta con una versión de Moodle 1.9
concepto de red social de aprendizaje. integrada con una capa de red social de aprendizaje (sin uso
de servicios web) desarrollada en el proyecto GlesOne en la
UTPL.
Objetivo General:
En la FIGURA. 1, se presenta la apariencia
Desarrollar y adaptar una capa de usuario final tradicional de una versión estable de Moodle.
basada en Web Services, y desarrollar una capa de red social
integrada con una capa visual de presentación dinámica, para FIGURA. 1
las versiones de Moodle 1.9.x y 2.0.x. APARIENCIA TRADICIONAL DE UNA VERSIÓN
ESTABLE DE MOODLE
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 En la FIGURA. 2, se presenta una versión de
Moodle 1.9, integrada con una capa de red social sin uso de
widgets para brindar una presentación dinámica a servicios web.
los usuarios finales.
FIGURA. 2
APARIENCIA TRADICIONAL DE UNA VERSIÓN
 Proveer de una capa de red social a las versiones ESTABLE DE MOODLE
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.
 Integrar la capa visual con una capa de de red social

usando servicios web dentro de la plataforma
Moodle.
Para satisfacer las mencionadas necesidades requeridas, se En el esquema de la FIGURA. 3, se elimina el concepto de
propone: programación en parejas, debido a que solamente se cuenta
 Desarrollar e implementar una capa de servicios con un desarrollador, y se incorpora la definición de una
arquitectura inicial que se considera necesaria para tener una
web sobre Moodle 1.9.x y Moodle 2.0.x.
visión clara del sistema.
 Desarrollar e implementar una capa de gestión de
widgets sobre Moodle 1.9.x y Moodle 2.0.x . La arquitectura de las nuevas capas implementadas
 Desarrollara e implementar una capa de red social sobre Moodle, se presentan en la FIGURA. 4. Esta es la
arquitectura propuesta y desarrollada de las nuevas capas
que consuma servicios web de moodle sobre sobre Moodle, con las cuales se incorpora las nuevas
tendencias de la web moderna a la plataforma e-learning,
Moodle 1.9.x y Moodle 2.0.x.
con el objetivo de obtener un mejor rendimiento en el
 Implementar sobre Moodle 1.9.x y Moodle 2.0.x proceso de enseñanza-aprendizaje.
una presentación dinámica basada en widgets,
donde el usuario tenga la capacidad de agregar y
remover widgets con distintas funcionalidades
FIGURA. 4
cada uno, incluyendo la presentación de una red NUEVAS CAPAS IMPLEMENTADAS SOBRE LA
social consumida desde una capa de red social PLATAFORMA E-LEARNING MOODLE (1.9.X Y 2.0.X)
sobre Moodle.
DESARROLLO DE LA SOLUCIÓN
Con el fin de llevar un proceso bien identificado, y
de garantizar la culminación del proyecto, se ha
seleccionado una metodología de desarrollo en base a las
necesidades y exigencias del mismo.
La metodología seleccionada ha sido Extremme

Programming (XP) o Programación Extrema. Sin embargo
debido a la naturaleza del proyecto no se ha seguido a pie de
letra todas las actividades y teorías propuestas en XP, si no
que se ha hecho una adaptación considerando el entorno del
proyecto.
Las nuevas capas implementadas se integran
directamente con el núcleo de Moodle, y a través de sus
Esta adaptación de la metodología XP para éste
librerías, se accede a la base de datos. La base de datos es
proyecto en particular, se muestra gráficamente en la
una sola, en la cual se hace distinción entre la parte de la
FIGURA. 3
base de datos nativa de Moodle (identificada como DB-
MOODLE), y la parte de la base de datos de la red social de
FIGURA. 3
FASES DE XP ADAPTADAS AL ENTORNO DEL
aprendizaje (Identificada como DDB-RSA), la cual ha sido
PROYECTO 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 Capa RSA – Capa de Web Services.- La capa RSA se
proveer de un punto de comunicación adicional a la forma relaciona con la capa de web services para obtener mediante
tradicional de comunicación de Moodle. Por medio de esta servicios web los datos correspondientes a la red social, en la
capa es posible comunicarse con las librerías de Moodle, ya capa RSA se gestionan estos datos obtenidos para dar una
sea desde una capa dentro de la misma plataforma, o desde presentación en forma de red social.
una aplicación externa, los mensajes que se envían y reciben
son archivos en formato XML. Capa de Widgets – Capa de Web Services.- La capa de
widgets además se relaciona directamente con la capa de
Como se observa en la FIGURA. 1, para el web services para obtener datos relacionados a los cursos y a
desarrollo de las nuevas capas se usa una combinación de la información del usuario, estos datos se gestionan para ser
lenguajes de programación, estilos, y lenguajes de marcado. presentados en los widgets correspondientes.
En la capa de Widgets, se usa php, javascript y css, en la
capa Rsa se usa php, en la capa de Web Services se usa php
y XML. En la FIGURA. 4, se presentó la arquitectura de las
nuevas capas implementadas sobre moodle, ahora en la
FIGURA. 6 se presenta la arquitectura general del sistema, o
En la FIGURA. 5. Se presenta las relaciones sea su estructura general, sin hacer distinción entre las
existentes entre las nuevas capas desarrolladas e nuevas capas, con excepción de la capa de Web Services, la
implementadas, identificando cómo interactúan éstas cual cambia la forma tradicional de comunicación
internamente.
No resulta difícil visualizar la estrecha relación

entre las tres capas, al final lo que se representa es el FIGURA. 6
ARQUITECTURA GENERAL DEL SISTEMA
consumo de servicios web, y la presentación en una capa de
widgets de todos estos datos consumidos.
FIGURA. 5
RELACIÓN ENTRE LAS NUEVAS CAPAS
IMPLEMENTADAS EN MOODLE
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
Capa de Widgets – Capa RSA.- Estas capas están dinámica y amigable.

relacionadas directamente debido a que desde la capa de  Servicios Web.- Servicios que serán consumidos
widgets se hace el llamado a las funciones que gestionan los
datos de la red social de aprendizaje obtenidos mediantes desde el cliente por medio de mensajes XML.
servicios web desde Moodle, estos datos se encuentran en  Servidor Web.- Servidor que aloja la aplicación
las tablas creadas para implementación la red social en el
proyecto Glesone. 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 - Perfil de Usuario: Perfil de usuario del usuario
lenguaje de programación se usa PHP. actualmente identificado
 Servidor de Base de Datos.- En este caso un - Red Social: Red social principal del usuário.
servidor MySQL, que contiene los datos del
sistema. Otra parte del sistema es la gestión de amistades de
la red social se presenta en otra pestaña dentro del sistema,
se muestra en la Figura. 8.
RESULTADOS
FIGURA. 8
PANTALLA AMIGOS
Al finalizar las fases de desarrollo de XP adaptadas
a este proyecto, tenemos como resultado las tres nuevas
capas desarrolladas, implementadas sobre las versiones de
Moodle 1.9.x y 2.0.x.
Estas versiones de moodle con las nuevas capas

desarrolladas, se encuentran en:
http://www.glesone.org/moodle_widgets para Moodle 1.9

http://www.glesone.org/moodle20_widgets para Moodle 2.0
Al ingresar al sistema, nos dirigimos la pantalla

principal, la cual tiene una apariencia basada en widgets,
como se muestra en la Figura. 7. En esta pantalla se presentan los siguientes widgets:
- Contactos: Contactos del usuario para su red social
- Buscar Persona: Espacio para buscar amigos para la
FIGURA. 7
PANTALLA PRINCIPAL red social.
- Usuarios Conectados: Usuarios conectados al
sistema.
- Mensajes Recibidos: Mensajes privados que otros

usuarios han enviado al actual usuario.
En la Figura. 9 se muestra la pantalla Mi Curso cuando el

usuario tiene rol de estudiante, aquí se presenta los widgets
con información de un curso, luego de que haya sido
seleccionado desde el widget “Cursos“ presentado en la
pantalla inicial.
Al dar clic sobre alguno de los cursos del usuario desde el
widget “Cursos”, seremos redirigidos automáticamente a la
Los widgets aquí encontrados pueden ser pestaña “Mi Curso”, en ese instante el nombre de la pestaña,
organizados de acuerdo a la conveniencia del usuario, cambiara por el nombre del curso seleccionado.
además se pueden eliminar y volver a obtenerlos por medio
de un menú de widgets.
En esta pantalla, se hace una distinción entre los
En esta pantalla se presentan los siguientes widgets: usuarios con rol de estudiante, y los usuarios con rol de
- Cursos: Lista de cursos en los que el usuario tiene profesor en el curso seleccionado, en cuanto a las
rol de profesor o estudiante. funcionalidades proveídas.
FIGURA. 9 La diferencia está en los siguientes widgets.
PANTALLA MI CURSO PARA USUARIO CON ROL DE - Cuestionarios
ESTUDIANTE
- Tareas
- Recursos
- Foros
En estos widgets se presenta al usuario (con rol de profesor)

la opción de agregar uno (módulo) nuevo, y de eliminarlo.
FIGURA. 10
PANTALLA MI CURSO PARA USUARIO CON ROL DE
PROFESOR

- Usuarios Conectados: Usuarios conectados al
sistema.
- Mensajes Recibidos: Mensajes privados que otros
usuarios han enviado al actual usuario.
- Red Social de Curso: Una red social para agregar
posts y comentarios dentro de un curso, como
amigos de la red están los participantes del curso.
- Recursos: Los recursos que están disponibles en el
curso.
- Participantes: Lista los participantes de ese curso, En cuanto a la parte de Red Social de Aprendizaje, existen
dos tipos de red social, una es la red social principal del
clasificándolos de acuerdo a su rol de profesor o
usuario y es la que se presenta al ingresar al sistema, y
estudiante en el curso. además existe una red social para cada curso.
- Anuncios Profesor: Lista los anuncios que ha hecho Cada una de estas redes sociales se encuentra en un widget
un profesor en las secciones del curso. diferente, sin embargo las funcionalidades que brindan son
- Cuestionarios: Presenta los cuestionarios que están las mismas, por lo que únicamente se hará mención a la red
disponibles en el curso. social principal.
El widget de la red social se muestra en la
- Tareas: lista las tareas que existen para un curso.
FIGURA. 11.
- Foros: Lista los foros del curso, se puede ingresar a
FIGURA. 11
estos para agregar discusiones en el caso de tener WIDGET RED SOCIAL
rol de profesor, si únicamente tiene rol de
estudiante solo podrá agregar posts a las
discusiones.
En la pantalla Mi Curso se presentan diferentes

funcionalidades dependiendo si el usuario tiene rol
de estudiante o profesor, en la FIGURA. 9 se
presentó la pantalla cuando el usuario tiene rol de
estudiante, en la FIGURA 10 se presenta cuando el
usuario tiene rol de profesor.
El uso de la red social es bastante intuitiva, tiene las según el 96% de los usuarios, con lo se logra tener
funcionalidades tradicionales de una red social, como:
una mayor aceptación por parte de los mismos.
- Agregar nuevo post
- Agregar nuevo comentario
- Eliminar post y/o comentario (siempre y cuando sea o Hoy en día pocas son las aplicaciones que
el propietario) funcionan aisladas, por esta razón es una necesidad
- Menú de notificaciones: Actividad en la red social, el hecho de poner los datos a disponibilidad de
solicitud de amistad, usuarios bloqueados.
otras aplicaciones y así intercambiar información,
- Agregar enlaces de video.
- Mostrar los siguientes comentarios. el 96% de los usuarios del sistema de éste proyecto
lo ratifican.
o Ofrecer información que sea accesible desde otras
CONCLUSIONES aplicaciones, e incorporar otros elementos de la
o La colaboración que tecnologías como Ajax han web 2.0, tal como se lo ha hecho en este proyecto,
brindado al desarrollo de la web 2.0 es promueve una mayor expansión del sistema e-
impresionante, ya que brindan una excelente ayuda learning, según la apreciación del 96% de los
a los desarrolladores de sistemas para transformar usuarios.
sistemas web estáticos a sistemas web dinámicos e
interactivos. o La implementación de una red social dentro de un
entorno virtual de aprendizaje brinda una mayor
o El uso de la web 2.0 en la educación mejora la interactividad entre profesor y estudiante, lo cual
interacción entre los sistemas e-learning y los apoya al mejoramiento del proceso de aprendizaje,
alumnos, según el 100% de los usuarios que han según la aprobación del 42% de los usuarios que
probado el producto final de este proyecto. han calificado de “excelente” esta iniciativa, y el
58% que la han calificado como “buena”.
o La implementación de nuevas características sobre
Moodle orientadas a la web 2.0, brindan un aporte
o Con el uso de una red social, y otras características
significativo e innovador estilo de aprendizaje en
de la web 2.0 dentro de un entorno virtual de
línea en la educación, según un 79% de los usuarios
aprendizaje, se logra mayor participación del
que han probado la plataforma.
estudiante, en relación con los entornos virtuales de
aprendizaje clásicos, esto según una evaluación
o Las presentación de recursos educativos mediante
realizada a los usuarios, en donde se presume que
una interfaz dinámica, como la de éste proyecto,
se incrementaría una participación altamente activa
tienen un impacto positivo para la interacción
de un 13% a un 67%.
usuario-sistema, e incentiva el uso de los entornos
virtuales de aprendizaje, según un 96% de los
o Este proyecto ha generado expectativas en los
usuarios que han probado la plataforma.
usuarios, por lo que se cree conveniente darle
continuidad, el 92% de los usuarios que lo han
o Una interfaz configurable por el usuario final
probado así lo han considerado.
brinda comodidad y sencillez a la hora de
interactuar con un sistema virtual de aprendizaje,
o La innovación es fundamental para el avance en la
educación, se requiere de una evolución de los
sistemas de aprendizaje para brindar una mayor
calidad en cuanto al estilo de aprendizaje.
REFERENCIAS
[1] Beck, K. (1999). Extreme Programming Explained.

[2] Burgos, E. (2009). Claves del nuevo marketing. Como sacarle
partido a la Web 2.0. Barcelona: Ediciones Gestión 2000.
[3] E. Leiva, J. P. (2006). Sistemas y Aplicaciones Informáticas.
Madrid: EDITORIAL MAD, S.L.
[4] Fernandez, G. (2002, 12 9). Universidad de Castilla-La Mancha.
Retrieved 02 2011, from http://www.info-
ab.uclm.es/asignaturas/42551/trabajosAnteriores/Presentacion-
XP.pdf.
[5] Garzon Villar M. Luisa, S. M. (2004). Informatica. Volumen II.
Madrid: EDITORIAL MAD, S.L.
[6] J.J. Gutierrez, M. E. Pruebas del sistema en programacion
extrema.
[7] Jaramillo E, R. A. (2010). CREACIÓN DE UNA RED SOCIAL
DE APRENDIZAJE (RSA) PARA UN ENTORNO VIRTUAL DE
APRENDIZAJE (EVA). Universidad Técnica Particular de Loja,
Unidad de Virtualización. Loja: UTPL.
[8] Joskowicz, J. (2008). Reglas y Prácticas en Extreme
Programming.
[9] Kaar, C. (2007). An Introduction to Widgets with Particular
Emphasis on Mobile Widgets. Austria: University of Applied
Sciences.
[10] NewComer, E. (2002). Understanding Web services: XML,
WSDL, SOAP, and UDDI. Indianapolis: PEARSON
EDUCATION.
[11] Pressman, R. S. (2006). INGENIERÍA DE SOFTWARE. UN
ENFOQUE PRÁCTICO. México: Edamsa.
[12] Sommerville, I. (2005). Ingeniería del Software. Madrid:
PEARSON EDUCACIÓN.
[13] Tuya Javier, R. I. (2007). Tecnicas cuantitativas para la gestion
en la ingenieria del software. Gesbiblo, S. L.

Capa de Usuario Final Basada en Web Services PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capa de Usuario Final Basada en Web Services PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

La Universidad Católica de Loja

ESCUELA CIENCIAS DE LA COMPUTACIÓN

Trabajo de fin de carrera previa a la obtención del

Ing. Torres Díaz Juan Carlos

Particular de Loja, autoriza su presentación para los fines legales pertinentes.

Loja, 05 de Diciembre del 2011

Ing. Torres Díaz Juan Carlos

Ing. Abad Espinoza Marco Patricio

Particular de Loja, autoriza su presentación para los fines legales pertinentes.

Loja, 05 de Diciembre del 2011

Ing. Abad Espinoza Marco Patricio

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.

Chamba Jiménez Esteban Yomairo

expresamente a la Universidad Técnica Particular de Loja y a sus representantes legales de

posibles reclamos o acciones legales.

Universidad Técnica Particular de Loja que su parte pertinente textualmente F

parte del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos

Chamba Jiménez Esteban Yomairo

Esta nueva meta alcanzada la dedico especialmente a Dios, que nunca me ha

Se ha considerado sumamente importante la necesidad de incorporar las nuevas

Ilustración 1 Apariencia Tradicional de Moodle ........................................................................... 5

1.1.1 Naturaleza Y Antecedentes

Se considera sumamente necesario innovar, y actualizar el sistema para que cumpla

1.2.1 Objetivo General

1.2.2 Objetivos Específicos

Consumir los recursos de Moodle haciendo uso de la capa de Web Services.

Se requiere que el sistema tenga la capacidad de interactuar con otros sistemas

La aplicación de la tecnología Ajax es lo que se requiere para brindar una mejor

Otro aspecto importante del proyecto, es el desarrollo e implementación de una capa

Para el desarrollo de las nuevas funcionalidades en Moodle, se ha elegido la

En la siguiente imagen se muestra la pantalla de una versión estable de Moodle.

Ilustración 1 Apariencia Tradicional de Moodle

A continuación en la figura se muestra la pantalla de una versión de Moodle integrada

Ilustración 2 Apariencia de GlesOne sobre Moodle

Como se puede observar en las figuras anteriores el contenido presentado tanto en la

En el caso de la versión Moodle 2.0.x se cuenta con la implementación de Web

Para satisfacer las necesidades actualmente requeridas se propone:

Desarrollar e implementar una capa de servicios web sobre Moodle 1.9.x y

Con el propósito de cumplir de la mejor manera con los objetivos propuestos en el

En cuanto a la parte de mejoramiento de experiencia de usuario además se presenta

1.5.1 Servicios Web

Un concepto importante que se debe conocer en cuanto a Web Services es el de XML,

1.5.2 Posibles Soluciones Para Implementación de Servicios Web en Moodle 1.9.x

a) Usar el servicio XML-RPC

XML-RPC Web Service API in Moodle.- Permite a un servidor o cliente externo

Definición formal de XML-RPC (XML-Remote Procedure Calling).- Es una especificación,

Un mensaje XML-RPC es una petición HTTP-POST, el cuerpo de esta petición es en

Definición formal de SOAP (Simple Object Access Protocol).- SOAP es un protocolo

SOAP es un protocolo basado en XML que consiste de tres partes:

SOAP encoding rules, un conjunto de reglas de codificación para expresar instancias de

SOAP RPC representation, es una convención para representar llamadas y respuestas a

1.5.3 Opción Seleccionada Para Implementación de Servicios Web en Moodle 1.9.x

Definición de WSDL.- WSDL está basado en la tecnología XML, define interfaces de

Debido a la estandarización de protocolos de comunicación y formatos de mensajes en

La tecnología a usar seleccionada ha sido el plugin WSPP (Patrick,

En el A Anexo1_ClientWSPP.docx , se realiza un test del consumo de los

En la versión 2.0.x de Moodle, se presentan algunas diferencias con la versión 1.9.x,

a) Implementación nativa de Web Services

La nueva alternativa que tenemos con respecto a la versión anterior, es usar la

En el Anexo 2 Anexo2_WSMoodle20.docx , se realiza una descripción completa sobre