UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
La Universidad Católica de Loja
ESCUELA CIENCIAS DE LA COMPUTACIÓN
MODALIDAD PRESENCIAL
Desarrollo y adaptación de una capa de usuario final basada en web services para las versiones de moodle 1.9.x y 2.0.x
Autor:
Chamba Jiménez Esteban Yomairo
Directores:
Torres Días Juan Carlos
Abad Espinoza Marco Patricio
LOJA に ECUADOR
2011
Trabajo de fin de carrera previa a la obtención del
título de Ingeniero en Sistemas Informáticos y
Computación.
II
CERTIFICACIÓN
Ing. Torres Díaz Juan Carlos
DIRECTOR DE TESIS
CERTIFICA:
Haber dirigido y supervisado el desarrollo del presente proyecto de tesis previo a la obtención
del título de INGENIERÍA EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN, y una vez que éste
cumple con todas las exigencias y los requisitos legales establecidos por la Universidad Técnica
Particular de Loja, autoriza su presentación para los fines legales pertinentes.
Loja, 05 de Diciembre del 2011
Fぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐ
Ing. Torres Díaz Juan Carlos
III
CERTIFICACIÓN
Ing. Abad Espinoza Marco Patricio
CO-DIRECTOR DE TESIS
CERTIFICA:
Haber dirigido y supervisado el desarrollo del presente proyecto de tesis previo a la obtención
del título de INGENIERÍA EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN, y una vez que éste
cumple con todas las exigencias y los requisitos legales establecidos por la Universidad Técnica
Particular de Loja, autoriza su presentación para los fines legales pertinentes.
Loja, 05 de Diciembre del 2011
Fぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐ
Ing. Abad Espinoza Marco Patricio
IV
AUTORÍA
El presente proyecto de tesis con cada una de sus observaciones, análisis, evaluaciones,
conclusiones y recomendaciones emitidas, es de absoluta responsabilidad del autor.
Además, es necesario indicar que la información de otros autores empleada en el presente
trabajo está debidamente especificada en fuentes de referencia y apartados bibliográficos.
Fぐぐぐぐぐぐぐくくくくくぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐく
Chamba Jiménez Esteban Yomairo
CI: 1104690621
V
CESIÓN DE DERECHOS
Yo, Esteban Yomairo Chamba Jiménez, declaro ser autor del presente trabajo y eximo
expresamente a la Universidad Técnica Particular de Loja y a sus representantes legales de
posibles reclamos o acciones legales.
Adicionalmente declaro conocer y aceptar la disposición del Art. 67 del Estatuto Orgánico de la
Universidad Técnica Particular de Loja que su parte pertinente textualmente SキIWぎ ざ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,
;I;SYマキIラ ラ キミゲデキデ┌Iキラミ;ノ ふラヮWヴ;デキ┗ラぶ SW ノ; ┌ミキ┗WヴゲキS;Sざく
Fくくくくぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐく
Chamba Jiménez Esteban Yomairo
VI
AGRADECIMIENTO
Agradezco a todas las personas que estuvieron cerca brindándome su apoyo en la realización
de este proyecto que ha enriquecido mis conocimientos. De manera especial a los ingenieros
Juan Carlos Torres, y Patricio Abad, quienes con su experiencia y conocimiento, supieron ser
una excelente guía para el éxito del proyecto.
Agradezco a mi familia por motivarme y darme aliento para seguir adelante, sin importar el
esfuerzo que se tenga que realizar con el fin de alcanzar una nueva meta en la vida.
Esteban Y. Chamba J.
VII
DEDICATORIA
Esta nueva meta alcanzada la dedico especialmente a Dios, que nunca me ha dejado caminar solo, y sin su ayuda no hubiera sido posible alcanzarla.
A mis padres que ha sido siempre un ejemplo a seguir y por todo su apoyo, a mis hermanas, y a toda mi familia por su apoyo incondicional.
Esteban Y. Chamba J.
VIII
RESUMEN
Las plataformas de aprendizaje (e-learning) han contribuido con el mejoramiento de
los procesos de enseñanza aprendizaje gracias al uso de internet. Una de estas
plataformas de aprendizaje, que posee muchos usuarios a nivel mundial es Moodle, sin
embargo, aunque cumple con los principios básicos para el proceso de enseñanza-
aprendizaje en línea, deja mucho que desear en cuanto a las nuevas tendencias en la
web, como es el tema de la web 2.0 y de las redes sociales.
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.
IX
ÍNDICE
Tabla de contenido
ÍNDICE ............................................................................................................................... IX
Tabla de contenido ............................................................................................................ IX
ÍNDICE DE ILUSTRACIONES ................................................................................................. XI
1 CAPÍTULO I: DEFINICIÓN DEL PROBLEMA Y ANÁLISIS INICIAL ......................................... 1
1.1 INTRODUCCIÓN .................................................................................................... 2
1.1.1 Naturaleza Y Antecedentes ................................................................................... 2
1.1.2 Diagnóstico ............................................................................................................ 2
1.2 OBJETIVOS ............................................................................................................ 3
1.2.1 Objetivo General ................................................................................................... 3
1.2.2 Objetivos Específicos ............................................................................................. 3
1.3 DESCRIPCIÓN DEL PROYECTO ................................................................................ 4
1.4 ESTADO ACTUAL ................................................................................................... 5
1.5 PROPUESTA DE SOLUCIÓN .................................................................................... 7
1.5.1 Servicios Web ........................................................................................................ 7
1.5.2 Posibles Soluciones Para Implementación de Servicios Web en Moodle 1.9.x .... 8
1.5.3 Opción Seleccionada Para Implementación de Servicios Web en Moodle 1.9.x .. 9
1.5.4 Posibles Soluciones Para Implementación de Web Services en Moodle 2.0.x ... 11
1.5.5 Opción Seleccionada Para Implementación de Web Services en Moodle 2.0.x . 12
1.5.6 Gestión de Widgets ............................................................................................. 12
1.5.7 Desarrollo de Widgets ......................................................................................... 13
1.5.8 Herramienta Elegida Para Implementación de la Capa de Widgets ................... 15
1.5.9 Capa de Widgets en Moodle ............................................................................... 16
1.5.10 Integración de JPolite y Moodle .......................................................................... 16
1.5.11 Aproximación visual de la capa de widgets ......................................................... 17
2 CAPÍTULO II: DESARROLLO DE LA SOLUCIÓN ............................................................... 18
2.1 METODOLOGÍA DE DESARROLLO ......................................................................... 19
2.1.1 Definición de Metodología de Desarrollo (E. Leiva, 2006) .................................. 19
2.1.2 Programación Extrema (XP) (Pressman, 2006) ................................................... 19
2.2 PLANIFICACIÓN ................................................................................................... 23
2.2.1 Historias de Usuario ............................................................................................ 23
2.2.2 Plan de Entregas e Iteraciones ............................................................................ 24
2.2.3 Reuniones ............................................................................................................ 25
X
2.2.4 Arquitectura ........................................................................................................ 25
2.3 DISEÑO ............................................................................................................... 31
2.3.1 Metáfora del Sistema .......................................................................................... 31
2.3.2 Modelo de Datos ................................................................................................. 31
2.3.3 Prototipos ............................................................................................................ 37
2.3.4 Diagrama de Clases ............................................................................................. 45
2.4 DESARROLLO ...................................................................................................... 65
2.4.1 Disponibilidad del cliente .................................................................................... 65
2.4.2 Pruebas de unidad ............................................................................................... 65
2.4.3 Integración .......................................................................................................... 65
2.5 PRUEBAS ............................................................................................................ 67
2.5.1 Pruebas unitarias ................................................................................................. 67
2.5.2 Pruebas de aceptación o funcionales .................................................................. 67
3 CAPÍTULO III: PLAN DE PRUEBAS ................................................................................. 68
3.1 Propósito ............................................................................................................ 69
3.2 Alcance ............................................................................................................... 69
3.2.1 Pruebas unitarias ................................................................................................. 69
3.2.2 Pruebas de aceptación o funcionales .................................................................. 69
3.3 Estrategia ........................................................................................................... 70
3.4 Recursos ............................................................................................................. 71
3.5 Cronograma ........................................................................................................ 72
3.6 Resultados .......................................................................................................... 72
3.7 Manual de Instalación del Sistema ...................................................................... 73
3.8 Manual de Usuario del Sistema ........................................................................... 73
4 DISCUSIÓN ................................................................................................................. 74
5 CONCLUSIONES Y RECOMENDACIONES ....................................................................... 77
5.1 Conclusiones y Recomendaciones........................................................................ 78
5.1.1 Conclusiones ........................................................................................................ 78
5.1.2 Recomendaciones ............................................................................................... 80
BIBLIOGRAFÍA .................................................................................................................... 82
OTRAS REFERENCIAS .......................................................................................................... 83
XI
ÍNDICE DE ILUSTRACIONES
Ilustración 1 Apariencia Tradicional de Moodle ........................................................................... 5
Ilustración 2 Apariencia de GlesOne sobre Moodle ...................................................................... 5
Ilustración 3 Aproximación de Apariencia de Widgets ............................................................... 17
Ilustración 4 Ciclo del Proyecto con XP (Fernandez, 2002) ......................................................... 20
Ilustración 5 Fases Metodología XP (Fernandez, 2002) .............................................................. 21
Ilustración 6 Fases XP (Adaptada al entorno del Proyecto) ........................................................ 22
Ilustración 7 Arquitectura General del Sistema .......................................................................... 25
Ilustración 8 Arquitectura RSA y Moodle (Jaramillo E, 2010) ..................................................... 27
Ilustración 9 Arquitectura Propuesta (Nuevas capas sobre Moodle) ......................................... 28
Ilustración 10 Relación entre capas ............................................................................................ 29
Ilustración 11 Modelo de Datos (Funcionalidades nativas de Moodle) ...................................... 33
Ilustración 12 Modelo de datos (Red Social) (Jaramillo E, 2010) ................................................ 36
Ilustración 13 Prototipo de Presentación Inicial ......................................................................... 37
Ilustración 14 Prototipo de Presentación de Un Curso ............................................................... 39
Ilustración 15 Prototipo de Gestión de Amistades de la red social ............................................ 42
Ilustración 16 Diagrama de Clases .............................................................................................. 46
1
1 CAPÍTULO I: DEFINICIÓN
DEL PROBLEMA Y ANÁLISIS
INICIAL
2
1.1 INTRODUCCIÓN
1.1.1 Naturaleza Y Antecedentes
Desde la aparición de la Web 2.0, la cual ha dado un giro total al esquema tradicional
de presentación de recursos en internet, las necesidades de los sistemas han cambiado
mucho, al igual que han cambiado también las necesidades y exigencias de los usuarios
de sistemas disponibles en internet, esto obliga a que sistemas anteriores se actualicen
al nuevo esquema que plantea la Web 2.0 y a los nuevos sistemas a desarrollarse bajo
estándares de la web moderna, esto con la finalidad de brindar un mejor servicio al
usuario final y de tener una mejor aceptación de parte de los mismos.
Entre las propuestas de la Web 2.0 tenemos: permitir a las aplicaciones tener la
capacidad de interactuar con otros sistemas diferentes, y tener ambientes
personalizables dependiendo de las necesidades del usuario.
En los estudiantes de la UTPL el conocimiento sobre Web 2.0, y el uso de sistemas que
basados en la web moderna y colaborativa es bastante amplio, sin embargo el entorno
virtual de aprendizaje (basado en la plataforma e-learning Moodle) usado por los
estudiantes no presenta las características suficientes para una perfecta
compatibilidad con la web moderna.
Se considera sumamente necesario innovar, y actualizar el sistema para que cumpla
con los requerimientos de la web moderna y así brindar un mejor servicio a los
usuarios, presentando un ambiente más colaborativo y personalizable para aquellos
quienes hagan uso de la plataforma Moodle.
1.1.2 Diagnóstico
Como respuesta a la necesidad de innovar y partir hacia un ambiente de web
moderna, se ha considerado proveer a Moodle la capacidad de compartir sus recursos
y contenidos con sistemas externos, razón por la que se incluye el concepto de Web
Services; y para brindar a los usuarios una mejor experiencia de usuario a través de
una capa de interfaces configurables, personalizables y dinámicas, se incluye en
concepto de widgets.
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.
3
1.2 OBJETIVOS
1.2.1 Objetivo General
Desarrollar y adaptar una capa de usuario final basada en Web Services, y desarrollar
una capa de red social integrada con una capa visual de presentación dinámica, para
las versiones de Moodle 1.9.x y 2.0.x.
1.2.2 Objetivos Específicos
Implementar una capa de Web Services sobre el núcleo de Moodle para que
sus datos sean extraídos a través de éstos servicios.
Consumir los recursos de Moodle haciendo uso de la capa de Web Services.
Proveer a Moodle de una capa visual basada en widgets para brindar una
presentación dinámica a los usuarios finales.
Proveer una capa de red social a las versiones 1.9x y 2.0x de Moodle, la cual
funcione conjuntamente con una interfaz basada en widgets, y que brinde el
servicio para una red social personal del usuario, y para una red social de cada
curso de ese usuario.
Integrar la capa visual con una capa de de red social usando servicios web
dentro de la plataforma Moodle.
4
1.3 DESCRIPCIÓN DEL PROYECTO
El presente proyecto nace de la necesidad de proveer a los usuarios del entorno virtual
de aprendizaje de la UTPL nuevas características, de manera que cumpla con los
requerimientos de la web moderna 2.0.
Este proyecto será implementado sobre las versiones estables de Moodle 1.9.x y
Moodle 2.0.x, además en la versión 1.9.x será integrado con una versión que contiene
una capa RSA (Red Social de Aprendizaje) sin uso de servicios web, del proyecto
denominado GlesOne1 desarrollado en la UTPL (Universidad Técnica Particular de
Loja).
Se requiere que el sistema tenga la capacidad de interactuar con otros sistemas
poniendo a disponibilidad de sistemas externos sus contenidos y recursos por medio
de Web Services, de esa manera se pueden desarrollar sistemas que hagan uso de los
servicios web para presentar, procesar, agregar y modificar información de los
usuarios de la plataforma Moodle y de sus cursos. Además se requiere brindar una
presentación dinámica al usuario final, para lo cual se debe proveer una interfaz
dinámica y personalizable a los usuarios.
La aplicación de la tecnología Ajax es lo que se requiere para brindar una mejor
experiencia de usuario, Ajax es considerada la mejor opción debido a que está basada
en estándares web. Haciendo uso de Ajax se construirá una capa visual para mejorar la
presentación visual al usuario final por medio de la implementación de widgets
configurables dentro del sistema tradicional de la plataforma Moodle.
Otro aspecto importante del proyecto, es el desarrollo e implementación de una capa
de red social de aprendizaje sobre la plataforma Moodle. La misma que debe consumir
recursos proveídos por los servicios web de Moodle que serán desarrollados e
implementados en este mismo proyecto.
Para el desarrollo de las nuevas funcionalidades en Moodle, se ha elegido la
metodología de desarrollo de software XP (Extreme Programming).
Los detalles de cada uno de los objetivos planteados en este proyecto se revisan en
cada reunión con los encargados de revisión del proyecto en la Unidad de
Virtualización de la UTPL.
1 UTPL. GLESONE. [en línea].<http://www.glesone.org/>[Citado en 15 de febrero del 2011]
5
1.4 ESTADO ACTUAL
Con lo que actualmente se cuenta para dar inicio al proyecto, es con las versiones
necesarias de la plataforma Moodle2 (Moodle 1.9.x y Moodle 2.0.x), éste es el núcleo
sobre el cual se agregarán los nuevos servicios.
En la siguiente imagen se muestra la pantalla de una versión estable de Moodle.
Además se cuenta con una versión de Moodle 1.9.x integrada con una capa de red
social de aprendizaje (sin uso de servicios web) desarrollada en el proyecto GlesOne en
la UTPL.
A continuación en la figura se muestra la pantalla de una versión de Moodle integrada
con GlesOne.
2 MOODLE. [en línea]. <http://www.moodle.org/>[Citado en 15 de febrero del 2011]
Ilustración 1 Apariencia Tradicional de Moodle
Ilustración 2 Apariencia de GlesOne sobre Moodle
6
De esta versión de Moodle que integra una capa de red social de aprendizaje, se usará
su estructura de datos para la nueva red social de aprendizaje, basada en servicios
web.
Como se puede observar en las figuras anteriores el contenido presentado tanto en la
versión pura de Moodle como en la integrada con GlesOne está organizado en
bloques, no permitiendo de esa manera ningún tipo de personalización por parte del
usuario final.
En el caso de la versión Moodle 2.0.x se cuenta con la implementación de Web
Services parcialmente funcional ya que a la fecha no es posible interactuar con
aplicaciones externas desarrolladas por ejemplo en el lenguaje de programación Java
y/o la plataforma de desarrollo .Net. Por defecto dicha opción de Web Services se
encuentra desactivada, por lo que es necesario un proceso de activación y
configuración.
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.
7
1.5 PROPUESTA DE SOLUCIÓN
Para satisfacer las necesidades actualmente requeridas se propone:
Desarrollar e implementar una capa de servicios web sobre Moodle 1.9.x y
Moodle 2.0.x.
Desarrollar e implementar una capa de gestión de widgets sobre Moodle 1.9.x
y Moodle 2.0.x .
Desarrollara e implementar una capa de red social que consuma servicios web
de moodle sobre Moodle 1.9.x y Moodle 2.0.x.
Implementar sobre Moodle 1.9.x y Moodle 2.0.x una presentación dinámica
basada en widgets, donde el usuario tenga la capacidad de agregar y remover
widgets con distintas funcionalidades cada uno, incluyendo la presentación de
una red social consumida desde una capa de red social sobre Moodle.
Con el propósito de cumplir de la mejor manera con los objetivos propuestos en el
proyecto, primeramente se presentan opciones de las tecnologías que pueden ser
usadas en los casos propuestos para el desarrollo del proyecto, y luego se presenta las
opciones elegidas de acuerdo a sus características.
En cuanto a la parte de mejoramiento de experiencia de usuario además se presenta
una ilustración aproximada sobre cómo quedaría la capa de widgets implementada en
el proyecto.
1.5.1 Servicios Web
Los Servicios Web (Web Services) son aplicaciones desarrolladas para brindar servicio a
otras aplicaciones a través de la red. El concepto presentado por la W3C es el siguiente
さWゲ ┌ミ ゲキゲデWマ; SW ゲラaデ┘;ヴW キSWミデキaキI;Sラ ヮラヴ ┌ミ; URIが Iuyas 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
ヮヴラデラIラノラゲ Wゲデ=ミS;ヴWゲ SW キミデWヴミWデざ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]
8
XML, es el fundamento básico sobre el cual se construyen los servicios web, provee un
lenguaje para definición y procesamiento de datos. XML representa una familia de
especificaciones relacionadas publicadas y mantenidas por el World Wide Web
Consortium (W3C) y otros.
XML fue diseñado para superar las limitaciones de HTML, especialmente para un mejor
soporte del manejo y creación de contenido dinámico. HTML está bien para trabajar
con contenido estático, pero la web evoluciona hacia una plataforma de software
activo, en la cual los datos tienen un significado asociado, y el contenido necesita ser
generado y consumido dinámicamente. さUsando XML se puede definir cualquier
número de elementos que se asocien los datos con su significado, así que se describe
los datos y qué hacen estos, usando uno o más elementos creados con un propósitoざ
(NewComer, 2002).
1.5.2 Posibles Soluciones Para Implementación de Servicios Web en Moodle 1.9.x
Para la implementación de un API que funcione como servicio web para la plataforma
Moodle 1.9.x, es posible considerar varias posibilidades, estas son:
a) Usar el servicio XML-RPC
b) Usar OKTech (Open Knowledge Technologies) Web Services
c) WSPP (plugin de Web Services que hace uso de SOAP, y está basado en
OKTech)
d) Crear desde cero un nuevo plugin de Web Service que se integre con Moodle.
XML-RPC Web Service API in Moodle.- Permite a un servidor o cliente externo
conectarse con moodle y hacer solicitudes llamando a sus funciones, a la vez que
obtiene datos de regreso desde el servidor moodle4.
Definición formal de XML-RPC (XML-Remote Procedure Calling).- Es una especificación,
y una serie de implementaciones que permiten hacer llamadas a procedimientos a
través de internet al software que se ejecuta en diferentes sistemas operativos y en
entornos diferentes.
Un mensaje XML-RPC es una petición HTTP-POST, el cuerpo de esta petición es en
XML. Un procedimiento se ejecuta sobre el servidor y devuelve el valor en formato
XML5.
4 MOODLE. [En 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]
9
OKTech (Open Knowledge Technologies) in Moodle.- Es un Web Service basado en
SOAP, al igual que con el API XML-RPC, OKTech sirve para establecer una comunicación
y compartir datos entre un servidor o cliente externo y el servidor de moodle6.
Definición formal de SOAP (Simple Object Access Protocol).- SOAP es un protocolo
ligero para intercambio de información en sistemas descentralizados, de ambientes
distribuidos.
SOAP es un protocolo basado en XML que consiste de tres partes:
SOAP envelope, es una capa que define un framework para describir lo que hay en el
mensaje y cómo procesar esto, este mensaje es un documento XML.
SOAP encoding rules, un conjunto de reglas de codificación para expresar instancias de
tipos de datos definidos por la aplicación.
SOAP RPC representation, es una convención para representar llamadas y respuestas a
procedimientos remotos.
SOAP puede ser usado potencialmente en combinación con una variedad de otros
protocolos, como HTTP o SMTP7.
WSPP (Patrick, 2007).- Existe una versión avanzada por así decirlo de OKTech, es un
plugin con la implementación del Web Services sobre Moodle usando SOAP, el nombre
SWノ ヮノ┌ェキミ Wゲ さ┘ゲヮヮざ.
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]
10
modificaciones, e implementación de nuevas funciones, de acuerdo a las necesidades
propias del proyecto.
Dicho plugin incorpora las ventajas del uso de SOAP como servicio web, y el nivel de
desarrollo es adecuado para iniciar a incorporar las funcionalidades faltantes
requeridas en este proyecto.
Este plugin está desarrollado para trabajar bajo las características del protocolo SOAP,
y el Web Services Description Lenguaje (WSDL), en español (Lenguaje de Descripción
de Servicios Web).
Definición de WSDL.- WSDL está basado en la tecnología XML, define interfaces de
servicios web, tipos de datos y mensajes, patrones de interacción, y asignación de
protocolos (NewComer, 2002).
Debido a la estandarización de protocolos de comunicación y formatos de mensajes en
la web, se hace cada vez más importante ser capaz de describir las comunicaciones de
alguna manera estructurada. WSDL aborda esta necesidad mediante la definición de
una gramática XML para describir los servicios de la red como colección de variables de
comunicación capaces de intercambiar mensajes8.
En el AミW┝ラ ヱ さAnexo1_ClientWSPP.docxざ, se realiza un test del consumo de los
Servicios Web de WSPP, usando el lenguaje de programación PHP.
8 W3C. [En línea].<http://www.w3.org/TR/wsdl>[citado en 21 de febrero del 2011]
Anexo 1 Página
TWゲデ SW CノキWミデW WSPP ぐぐぐぐぐぐぐぐぐぐくくくぐぐぐく... 91 Uゲラ SW ┘ゲSノヲヮエヮくぐぐぐくぐぐぐぐぐぐぐぐぐぐくくぐぐくぐ. 91 PヴWゲWミデ;Iキルミ SW RWゲ┌ノデ;Sラゲぐぐぐぐぐぐぐくぐぐくぐぐく 93
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.
11
1.5.4 Posibles Soluciones Para Implementación de Web Services en Moodle 2.0.x
En la versión 2.0.x de Moodle, se presentan algunas diferencias con la versión 1.9.x,
por esta razón ha sido posible y necesario identificar por separado las opciones para
implementación de Web Services en dicha versión, estas son:
a) Implementación nativa de Web Services
b) WSPP (plugin de Web Services que hace uso de SOAP, y está basado en
OKTech)
c) Crear desde cero un nuevo plugin de Web Service que se integre con Moodle.
La nueva alternativa que tenemos con respecto a la versión anterior, es usar la
implementación nativa de Web Services. A la fecha actual (febrero del 2011) esta
funcionalidad está aún en una etapa de desarrollo, por lo que para usar
adecuadamente los servicios implementados es necesaria la utilización del Framework
SW PHP さZWミSざが ヮラヴ ノラ マキゲマラ ケ┌W ノ;ゲ a┌ミIキラミ;ノキS;SWゲ SWノ WWH “Wヴ┗キIW ゲラノラ ヮ┌WSWミ ゲ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
WWH ゲWヴ┗キIWゲ Wミ MララSノW ヲくヰく┝ぐぐぐぐぐぐくぐぐぐくくく 95 Aヴケ┌キデWIデ┌ヴ; IミデWヴミ;くぐぐくぐぐぐぐぐぐぐぐぐぐくぐぐぐ 95 RWゲデヴキIIキラミWゲ SW ノラゲ WWH SWヴ┗キIWゲぐぐぐぐくぐぐぐぐく 96 AIデキ┗;Iキルミ SW ノラゲ WWH SWヴ┗キIWゲぐぐぐくくぐぐぐ...ぐぐ. 96 TWゲデ SW ┌ミ CノキWミデWぐぐぐぐぐぐぐぐぐくくぐぐぐぐぐくくくぐぐ 101
12
1.5.5 Opción Seleccionada Para Implementación de Web Services en Moodle 2.0.x
Considerando las características de cada opción disponible para la implementación de
Web Services en Moodle 2.0.x, se ha determinado como la más adecuada para el uso
en el presente proyecto, a la opción dos: WSPP (Patrick, 2007).
1.5.6 Gestión de Widgets
さLラゲ ┘キSェWデゲ ゲラミ ;ヮノキI;IキラミWゲ ┘WH ノキ┗キ;ミ;ゲが ノ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ラヴノS WキSW WWH Cラミゲラヴデキ┌マぶ SWaキミW ; ┌ミ ┘キSェWデ Iラマラぎ さUミ ┘キSェWデ Wゲ ┌ミ; 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
キミゲデ;ノ;Iキルミ ゲラHヴW ノ; マ=ケ┌キミ; SWノ ┌ゲ┌;ヴキラ ラ ┌ミ Sキゲヮラゲキデキ┗ラ マル┗キノざ
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.
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.
13
1.5.7 Desarrollo de Widgets
Los widgets son desarrollados usando estándares de tecnologías web, tales como
HTML, CSS, JavaScript, y XML, estas tecnologías son exactamente las mismas usadas en
el desarrollo Ajax, de modo que los widgets podrían considerarse como un tipo de
aplicaciones Ajax.
Como podemos apreciar, el desarrollo de widgets usa los mismos estándares
tradicionales para el desarrollo web, además se basa en la tecnología Ajax para la
presentación de contenido dinámico y configurable desde una sola página. Se puede
decir que el uso de widgets es una técnica para crear aplicaciones web interactivas.
La aparición de la Web 2.0 ha intensificado el uso de aplicaciones Ajax, y aplicaciones
basadas en widgets, es por eso que se han desarrollado una serie de framework para
Aテ;┝が ┞ ヮ;ヴ; ;ノェ┌ミラゲ SW SキIエラゲ aヴ;マW┘ラヴニゲ ゲW エ;ミ SWゲ;ヴヴラノノ;Sラ さヮラヴデ;ノWゲざ ケ┌W エ;IWミ 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:
14
Prototype y Script.aculo.us, se ha creado Portal
Mootools, se ha creado iMoogle
jQuery, se ha creado JPolite.
Dojoii, incorpora Dojo's Dijit and DojoX que proveen una completa colección de
controles para interfaces de usuarios, dando poder para crear aplicaciones web
altamente optimizadas para disponibilidad, usabilidad, internacionalización,
accesibilidad, pero sobre todo brinda una increíble experiencia de usuario.
Con Dijit se pueden añadir widgets simples o interactivos, tales como imágenes de
Flickr ó un resumen de anuncios en twitter.
Yahoo UIiii, provee clases para el manejo de widgets, sobre las cuales son construidos
todos los widgets YUI 3, incorpora una serie de utilidades para los widgets, como:
atributos básicos, métodos de representación, mejoramiento progresivo, estructura de
marcado, nombres de clases y CSS, Eventos UI predeterminados.
Prototypeiv, es un framework JavaScript que tiene como objetivo facilitar el desarrollo
de aplicaciones web dinámicas. Tiene características únicas, y fáciles de usar,
basándose en la tecnología Ajax.
Script.aculo.usv, provee librerías javascript fáciles de usar para el desarrollo de
interfaces de usuario.
Existe una clase desarrollada con los frameworks Prototype, y Script.aculo.us, conocida
Iラマラ さPヴラデラデ┞ヮW Pラヴデ;ノ Cノ;ゲゲviざが ノ; マキゲマ; ケ┌W ミラゲ ;┞┌S; ; ェWゲデキラミ;ヴ ┘キSェWデゲ Wミ ┌ミ 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
15
Mootoolsvii, es un framework JavaScript compacto, modular y orientado a objetos,
diseñado para desarrolladores intermedios y avanzados de javascript.
Además existe un portal desarrollado en Mootools para el manejo de widgets, es open
ゲラ┌ヴIW ┞ ヮ┌WSW ヮWヴゲラミ;ノキ┣;ヴゲWが ゲW ノW エ; SWミラマキミ;Sラ さキMララェノWviiiざが キミゲヮキヴ;Sラ Wミ iGoogle, y netvibes, usa una estructura json. Véase
JQueryix, es una librería JavaScript rápida y consistente, que simplifica el paso de
documentos HTML, manejo de eventos, animaciones, e interacciones Ajax para un
rápido desarrollo Web.
Haciendo uso de la librería JQuery, ha sido desarrollado un completo, e interesante
Framework para el manejo de Widgets, este framework ha sido llamado JPolitex, es de
libre distribución, y opensource, el mismo que gracias a sus características ha sido
elegido para la implementación de una Capa de Widgets para Moodle.
1.5.8 Herramienta Elegida Para Implementación de la Capa de Widgets
Tomando en cuenta el avanzado nivel de desarrollo del framework JPolite como
herramienta para manejo de widgets, ha sido considerado como la mejor opción a usar
para la implementación de la capa de widgets en este proyecto.
En el Anexo 3 さAnexo2_Jpolite.docxざ se da una completa descripción de dicho
framework (sus característicasが Wゲデ;Sラ SW SWゲ;ヴヴラノノラが ;ヴケ┌キデWIデ┌ヴ;がぐぶ
La herramienta seleccionada para la implementación de Widgets ha sido
JPolite.
16
Anexo 3 Página
JPolite(jQuery Portal Lite)ぐぐぐぐぐぐぐぐぐくぐぐぐぐ.. 104 Características ぐぐぐぐ.ぐぐぐぐぐぐぐぐぐぐくくぐぐぐぐぐく 104 Tecnologías Usadasぐぐぐぐぐぐぐくぐぐぐぐぐぐぐくくぐぐぐ 104 Aヴケ┌キデWIデ┌ヴ;ぐぐぐぐぐぐくくぐぐぐぐくぐぐぐぐぐぐぐぐぐぐぐ 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ラミ YゲデW ヮヴラヮルゲキデラ ゲW エ; IヴW;Sラ ┌ミ; I;ヴヮWデ; ノノ;マ;S; さ┘キSェWデゲR“Aざが Wミ ノ; I┌;ノ ゲW 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.
17
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.
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.
Ilustración 3 Aproximación de Apariencia de Widgets
18
2 CAPÍTULO II:
DESARROLLO DE LA
SOLUCIÓN
19
2.1 METODOLOGÍA DE DESARROLLO
Tal como se propuso en el anteproyecto, se ha seleccionado XP (Extreme
Programming) como la metodología de desarrollo de software en este proyecto, esto
considerando las ventajas de dicha metodología en relación al tiempo requerido para
conclusión del proyecto, y a los requerimientos cambiantes.
2.1.1 Definición de Metodología de Desarrollo (E. Leiva, 2006)
Una metodología de desarrollo es una recopilación de técnicas y procedimientos
estructurados en fases para la producción de productos software de manera eficaz, y
englobando todo el ciclo de vida del mismo.
- Indica qué hacer, cuándo y quién debe hacerlo.
- Determina las etapas y controles a aplicar.
2.1.2 Programación Extrema (XP) (Pressman, 2006)
La Programación Extrema utiliza un enfoque orientado a objetos como su paradigma
de desarrollo preferido. La Programación Extrema abarca un conjunto de reglas y
prácticas que ocurren en el contexto de cuatro actividades del marco de trabajo:
planeación, diseño, codificación y pruebas.
XP es uno de los populares procesos ágiles. Ha demostrado ser exitoso en muchas
compañías e industrias de diferentes tamaños alrededor del mundo.
El éxito de XP hace hincapié en la satisfacción del cliente. En lugar de entregar todo el
proyecto completo en una fecha lejana en el futuro, en este proceso se entrega el
software conforme la necesidad.9
Para lograr esto, XP plantea un ciclo de desarrollo representado en la siguiente figura:
9 WELL DON. Extreme Programming: A gentle Introduction: [en lÍnea] <http://www.extremeprogramming.org>
20
En este ciclo representado gráficamente, encontramos:
- Historias de usuario.- Son equivalentes a los requisitos del sistema.
- Architectural spike.- Es una metáfora del sistema, o sea una descripción del
proyecto que se logre comprender sin mayores explicaciones.
- Spike.- Representa las estimaciones de tiempo de desarrollo, hechas por el
mismo desarrollador.
- Plan de entregas.- Es una clasificación de las historias de usuario, indicando
cuales serán desarrolladas, y hasta qué fecha.
- Iteración.- Es cada nuevo conjunto de historias de usuario que se desarrolla, o
todas aquellas funcionalidades nuevas.
- Pruebas de aceptación.- Pruebas que validan que las funcionalidades
implementadas sean las correctas.
- Pequeñas entregas.- Presentación del avance de cada iteración al usuario.
Para una correcta implementación de la metodología XP en el desarrollo de un
proyecto de software, es necesario identificar y ejecutar las tareas en cada una de las
cuatro fases propuestas por la metodología ágil. Estas fases son:
1. Planificación.
2. Diseño.
3. Desarrollo.
4. Pruebas.
Ilustración 4 Ciclo del Proyecto con XP (Fernandez, 2002)
21
En la siguiente figura se muestran cada una de estas fases, y se desglosan con las
respectivas actividades de cada una.
Para el desarrollo del presente proyecto se toma como base las fases propuestas por la
metodología XP, sin embargo, considerando que el desarrollo del proyecto es dentro
de un ambiente académico y con todo tipo de recursos limitados, no se lleva a pie de
letra todas las actividades y teorías propuestas en cada una de estas fases. Así mismo
se considera necesario incrementar algunas actividades que se consideran oportunas.
En la siguiente gráfica se ilustra la metodología de desarrollo XP adaptada al entorno
del proyecto con todas las fases que se seguirá en el desarrollo del mismo.
El proceso de desarrollo se basa en cada una de éstas fases, que se las verá con detalle
en las secciones siguientes.
Ilustración 5 Fases Metodología XP (Fernandez, 2002)
22
El presente proyecto está basado en este modelo adaptado de las fases de la
metodología XP, cada una de estas fases se detallan en las siguientes secciones, junto
con la implementación de cada fase en el proyecto.
Ilustración 6 Fases XP (Adaptada al entorno del Proyecto)
23
2.2 PLANIFICACIÓN
La metodología XP plantea la planificación como un diálogo continuo entre las partes
involucradas en el proyecto, incluyendo al cliente, a los programadores y a los
coordinadores o gerentes. (Joskowicz, 2008)
2.2.1 Historias de Usuario
Eミ ノ; マWデラSラノラェケ; 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
ミWェラIキラ ヴWゲヮWIデラ ; ノ; I;ヴ;IデWヴケゲデキI; ラ a┌ミIキルミくざ (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;ゲ エキゲデラヴキ;ゲ SW ┌ゲ┌;ヴキラ IラミS┌IWミ ; ノ;ゲ さヮヴ┌WH;ゲ SW ;IWヮデ;Iキルミざが 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.
24
En el Anexo4_Historias_Iniciales.docx, se presentan las historias de usuario obtenidas
en para el desarrollo de este proyecto.
2.2.2 Plan de Entregas e Iteraciones
El plan de entregas (さRelease Planざ) establece qué historias de usuario serán
agrupadas para conformar una entrega, y el orden de las mismas. Este cronograma es
el resultado de una reunión entre todos los actores del proyecto (cliente,
desarrolladores, gerentes, etc.)く XP SWミラマキミ; ; Wゲデ; ヴW┌ミキルミ さJ┌Wェラ SW ヮノ;ミW;マキWミデラ ふさPノ;ミミキミェ ェ;マWざぶざ. El cronograma de entregas se realiza en base a las estimaciones de
tiempos de desarrollo realizadas por los desarrolladores. Luego de algunas iteraciones
es recomendable realizar nuevamente una reunión con los actores del proyecto para
evaluar nuevamente el plan de entregas y ajustarlo si es necesario (Joskowicz, 2008)
El plan de entregas e iteraciones del presente proyecto se presenta en el Anexo 5
さAnexo5_Entregas_e_Iteraciones.docxざ.
Anexo 4 Página
Historias de Usuario ISWミデキaキI;S;ゲぐぐくくぐぐぐくぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐ. 108 Historias de Usuario: Compartición SW IラミデWミキSラゲ ┌ゲ;ミSラ WWH SWヴ┗キIWゲ ぐぐ. 108 Historias de Usuario: Mejoramiento de la presentación al usuario final a través de una interfaz Sキミ=マキI;ぐぐぐぐぐぐぐくぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐ. 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キゲデラヴキ;ゲ SW ┌ゲ┌;ヴキラぎ AS;ヮデ;Iキルミ SWノ SWゲ;ヴヴラノノラ ; MララSノW ヲくヰく┝ぐぐぐぐぐぐ..ぐ 126
Anexo 5 Página
Pノ;ミ SW WミデヴWェ;ゲ W キデWヴ;IキラミWゲぐくくぐぐぐぐくぐぐぐぐぐくぐく 128 PヴキマWヴ; キデWヴ;Iキルミ ぐぐぐくぐぐぐぐぐぐぐぐぐぐぐぐくぐぐぐぐ 128 SWェ┌ミS; IデWヴ;Iキルミぐぐぐぐぐぐぐくぐぐぐぐぐぐぐぐぐぐぐくく.. 132 TWヴIWヴ; IデWヴ;Iキルミぐぐぐぐぐぐぐくぐぐくくぐぐぐぐぐぐぐくぐぐぐ 136 C┌;ヴデ; IデWヴ;Iキルミぐぐぐぐぐぐぐくぐぐぐぐぐぐぐぐぐぐぐぐぐ.. 139 Q┌キミデ; IデWヴ;Iキルミぐぐぐぐぐぐぐくぐぐぐぐぐぐぐぐぐぐぐぐぐく. 142 Sexta IデWヴ;Iキルミぐぐぐぐぐぐぐぐくぐぐぐぐぐぐぐぐぐぐぐぐぐくく ヱヴヴ
25
2.2.3 Reuniones
El objetivo de las reuniones diarias es mantener la comunicación entre el equipo, y
compartir problemas y soluciones.
Durante el desarrollo de este proyecto las reuniones se han llevado a cabo
concurrentemente, si bien no han sido diarias como lo recomienda XP, si han sido al
menos dos veces por semana, en donde se comunican dificultades, o inquietudes.
No se maneja ningún tipo de artefacto para estas reuniones.
2.2.4 Arquitectura
La metodología de desarrollo XP, no incluye una representación de la arquitectura del
sistema en la fase de planificación debido a que se basa en la teoría de que va
cambiando en cada iteración, sin embargo para el desarrollo de este proyecto se ha
considerado conveniente establecer una arquitectura general del sistema, y una
arquitectura de las nuevas capas que se implementarán sobre Moodle.
Arquitectura General del Sistema
En la siguiente figura se presenta la arquitectura general del sistema, o sea su
estructura global sin hacer distinción entre las nuevas capas, con excepción de la capa
de Web Services, la cual cambia la forma tradicional de comunicación:
Ilustración 7 Arquitectura General del Sistema
26
En la arquitectura se pueden distinguir cuatro partes:
Presentación.- Parte de la aplicación con la que interactuará el usuario, se
requiere del uso de Javascript y Ajax para presentar una interfaz dinámica y
amigable.
Servicios Web.- Servicios que serán consumidos desde el cliente por medio de
mensajes XML.
Servidor Web.- Servidor que aloja la aplicación web, en este caso las librerías de
moodle, las cuales contienen la lógica de la aplicación y una comunicación para
acceso a los datos, como lenguaje de programación se usa PHP.
Servidor de Base de Datos.- En este caso un servidor MySQL, que contiene los
datos del sistema.
Más adelante se presentará la arquitectura de la implementación de las nuevas capas
sobre Moodle.
Como ya se ha venido especificando en las secciones anteriores, la finalidad de este
proyecto es implementar una capa de web services y una capa para presentar una
interfaz dinámica al usurario final, la misma se realizará usando widgets sobre la
plataforma Moodle, esto con el fin de volver a la plataforma más interactiva,
colaborativa, y además brindar una mejor usabilidad.
Además otro requerimiento es agregar una capa con las funcionalidades de una red
social, similar a la implementada en GlesOne, la cual no usa Servicios Web, a fin de
crear un solo plugin integrando la capa de widgets con la capa RSA haciendo uso de
Web Services.
Actualmente Glesone tiene definida una arquitectura de la red social que ha sido
implementada, ésta se detalla a continuación.
27
Arquitectura Actual de RSA (Sin uso de Web Services)
Antes de presentar la arquitectura que tendría Moodle una vez añadida la capa de web
services junto con la capa RSA y capa de widgets, se presentará primero la arquitectura
de la capa RSA que se encuentra ya implementada sobre Moodle. Esto es importante,
ya que representa parte de la metáfora del sistema.
La arquitectura presentada en la figura anterior es de la implementación de una capa
de red social sobre moodle, accediendo directamente a los datos, sin uso de servicios
web.
Arquitectura Propuesta (widgets, red social, web services)
En el siguiente esquema se presenta la arquitectura propuesta de implementación de
las nuevas capas al núcleo de Moodle, las mismas que comprenden: capa de web
services, capa RSA, capa de widgets.
Ilustración 8 Arquitectura RSA y Moodle (Jaramillo E, 2010)
28
Nuevas capas sobre Moodle: El マ;ヴIラ SW さN┌W┗;ゲ I;ヮ;ゲ キマヮノWマWミデ;S;ゲざ SW Iラノラヴ ェヴキゲ representa todo el desarrollo e implementación del proyecto. En el cual se incluye
さC;ヮ; SW ┘キSェWデゲざが さC;ヮ; R“Aざが さC;ヮ; SW WWH “Wヴ┗キIWゲざ.
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.
Ilustración 9 Arquitectura Propuesta (Nuevas capas sobre Moodle)
29
Relación entre capas
Todas las capas creadas sobre Moodle tienen una relación directa entre ellas, en la
siguiente figura se presenta gráficamente la relación entre las distintas capas.
Ilustración 10 Relación entre capas
Capa de Widgets に Capa RSA.- Estas capas están relacionadas directamente debido a
que desde la capa de widgets se hace el llamado a las funciones que gestionan los
datos de la red social de aprendizaje obtenidos mediantes servicios web desde
Moodle, estos datos se encuentran en las tablas creadas para implementación la red
social en el proyecto Glesone.
Capa RSA に Capa de Web Services.- La capa RSA se relaciona con la capa de web
services para obtener mediante servicios web los datos correspondientes a la red
social, en la capa RSA se gestionan estos datos obtenidos para dar una presentación en
forma de red social.
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.
30
Como se puede observar en la figura ;ミデWヴキラヴ さRWノ;Iキルミ WミデヴW I;ヮ;ゲざ, 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.
31
2.3 DISEÑO
La metodología XP sugiere la realización de diseños simples y sencillos. Se debe
procurar hacer todo lo menos complicado posible para conseguir un diseño fácilmente
entendible y sencillo de implementar que además requerirá menos esfuerzo y tiempo
para construirlo. Si se encuentra algo complejo se debe reemplazar con algo simple
para evitar gastar tiempo tanto en el diseño como en la posterior codificación.
2.3.1 Metáfora del Sistema
Una metáfora es algo que todos entienden, sin necesidad de mayores explicaciones. La
metodología XP sugiere utilizar este concepto como una manera sencilla de explicar el
propósito del proyecto, y guiar la estructura y arquitectura del mismo. (Joskowicz,
2008)
No es un proceso tan simple, ya que se necesita un conocimiento profundo sobre el
sistema para elegir una buena metáfora, y que todo el equipo la entienda.
La cualidad más importante es la capacidad de explicar el diseño del sistema a la gente
nueva, sin tener que recurrir a extensos documentos.
En este proyecto, aunque dentro del equipo se tiene una visión clara sobre el
propósito, contamos además con una arquitectura definida, que especifica de manera
clara el propósito del proyecto.
Parte importante para proveer la metáfora del sistema en este proyecto, ha sido la
implementación de una capa de red social sobre Moodle sin uso de servicios web, que
anteriormente ya se había desarrollado. El desarrollo anterior de dicha capa sobre
Moodle ha brindado importante ayuda para un mejor entendimiento en cuanto a la
capa de red social con uso de servicios web que se desarrollará en este proyecto.
2.3.2 Modelo de Datos
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.
32
Para mayor comprensión, se ha dividido la presentación del modelo de datos en dos
partes:
Modelo de datos (Funcionalidades nativas de Moodle)
Modelo de datos (Red Social)
Modelo de datos (Funcionalidades nativas de Moodle)
A continuación se describen cada una de las tablas del modelo de datos usadas para
interactuar con algunos de los datos de Moodle.
Tablas Utilizadas
mdl_user: Tabla de la cual se extrae información de los usuarios relacionados con las
distintas actividades.
mdl_modules: Contiene los módulos disponibles en Moodle, que pueden ser
agregados a un curso, por ejemplo: assignments, forums, resources, quizzes, etc.
mdl_course: Registra información referente a los cursos disponibles en moodle.
mdl_course_categories: Registra distintas categorías creadas para clasificación de los
cursos.
mdl_course_modules: Registra los módulos que han sido agregados a un curso en
particular.
mdl_course_sections: Registra toda la información correspondiente a un curso, como
anuncios, módulos, usuario, etc.
mdl_assignment: Se registra información sobre las tareas asignadas a un curso.
mdl_assignment_submissions: Registra información sobre archivos cargados por un
estudiante en la tarea específica de un curso.
mdl_resource: Mantiene información sobre los recursos agregados en un curso.
mdl_quizz: Se registra información sobre los cuestionarios asignados a un curso.
mdl_forum: Se registra información sobre los foros asignados a un curso.
mdl_forum_discussions: Se registran todas las discusiones que tiene un foro.
mdl_forum_posts: Registra todos los post correspondientes a una discusión, o sea los
comentarios hechos en la discusión de un foro.
33
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)
34
Modelo de datos (Red Social)
Como se mencionó anteriormente, para las funciones de Red Social, se usara el mismo
modelo de datos usado en la implementación de la red social sin uso de servicios web
de Glesone.
Tablas Utilizadas (Jaramillo E, 2010)
(Tablas de moodle utilizadas)
mdl_user: Tabla principal de la cual se extrae la información de los usuarios para
presentarla en post y comentarios.
mdl_course: Se extrae información para determinar en qué cursos se encuentra
matriculado un determinado usuario y hacer correspondencia con los post y
comentarios que coloquen en cada uno de ellos.
mdl_message: Se almacenan los mensajes enviados entre los usuarios de la red.
mdl_log: Se registran todos los eventos que realiza el usuario desde que inicia sesión
hasta que termina, de los cuales se toma los que permitirán definir el número de
nuevos post que se han colocado desde el último acceso a cada curso. Estos números
se muestran junto al nombre de cada curso en el bloque cursos.
mdl_message_contacts: Se usa para almacenar las relaciones de amistad entre los
usuarios.
mdl_course_sections: En esta tabla se requiere crear un campo denominado
id_usuario que permita establecer una relación entre los recursos y actividades
colocadas por un profesor en un determinado curso. Esta modificación fue necesaria
debido a que se cambió el esquema de anuncios a post-comentario.
(Tablas de Red Social)
mdl_rsa_post: En esta tabla se guarda el contenido de un post colocado por un usuario
en la Red Social o en un curso.
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.
35
mdl_rsa_invitaciones: Aquí se almacenan las solicitudes de amistad que se originan
entre los usuarios. Una vez que la solicitud es a acepta, se crea un registro en la tabla
mdl_message_contacts para establecer la relación de amistad entre los usuarios.
mdl_rsa_participantes_curso: Cuando un profesor desea que los post y comentarios
de un estudiante no sean visualizados dentro de un curso, se crea en esta tabla un
registro que mantiene bloqueado al estudiante.
mdl_rsa_actividad: Cada usuario puede realizar diferentes actividades dentro de la
RSA como: comentar, postear en un muro, marcar una publicación que le guste,
aceptar una solicitud de amistad. Todas estas actividades se registran en esta tabla y se
presentan en el muro del usuario como actividad y también en el menú de
notificaciones.
El esquema del modelado de datos (Red Social) es presentado en la siguiente figura.
36
Ilustración 12 Modelo de datos (Red Social) (Jaramillo E, 2010)
37
2.3.3 Prototipos
En esta fase se ha considerado además la presentación de algunos prototipos los
cuales se basan en las recomendaciones de XP (simples y sencillos), esto con la
finalidad de brindar una visión más clara de las necesidades del sistema.
Prototipo 1: Presentación Inicial
En este prototipo se ilustra la ventana de la presentación principal, con una interfaz
dinámica. Cuando un usuario ingresa al sistema observa en la parte izquierda una
pantalla pequeña que contiene la lista de cursos, y otra que contiene el perfil de
usuario, el cual puede ser actualizado, y en la parte derecha aparece una ventana que
contiene la Red Social del usuario, en la cual se puede agregar y eliminar anuncios y
comentarios, seleccionar la opción さMe gustaざ de los posts y comentarios. Además
esta red social contiene un menú de notificaciones sobre las actividades realizadas en
la red, un menú de solicitudes de amistad, y otro de los usuarios bloqueados.
En la pantalla que contiene los cursos se puede observar una relación hacia la pestaña
さMキ C┌ヴゲラざが Wゲデラ キミSキI; ケ┌W ;ノ ゲWノWIIキラミ;ヴ ┌ミ I┌ヴゲラ S;ミSラ IノキI ゲラHヴW WゲデWが ミラゲ
Ilustración 13 Prototipo de Presentación Inicial
38
dirigiremos hacia dicha pestaña, la cual cambiará en nombre con el del curso
seleccionado, el contenido mostrado en esta pestaña es representado en el Prototipo
2.
Además se muestra las opciones de maximizar, minimizar y cerrar de las pantallas.
La lista de widgets presentados en esta parte se describe a continuación:
Nombre de Widget Descripción Funcionalidades
Lista de cursos En este widget se listan todos los cursos en los que el usuario tiene un rol. Los cursos estarán clasificados por la categoría a la que pertenecen.
- Presentación de cursos del usuario.
- Enlace hacia una nueva presentación con el contenido del curso seleccionado.
Perfil de usuario Se presenta los datos
personales del usuario. Con una opción para editar los mismos.
- Presentación de datos personales del usuario.
- Actualización de datos personales.
Red social principal Se presenta un widget que contiene una red social en la que se puede tener relación con los demás usuarios del sistema que estén entre los contactos.
- Visualización de post y comentarios propios y de los contactos de la red.
- Capacidad de agregar posts en la red, y comentarios a los posts propios y de los contactos.
- Capacidad de eliminar posts y comentarios propios.
- Presentación de la opción さMW ェ┌ゲデ;ざ ヮ;ヴ; I;S; ヮラゲデ y comentario de la red social.
- Presentación de un menú de notificaciones sobre alguna acción en la red social.
- Presentación de menú de invitaciones a la red social.
- Presentación de menú de usuarios bloqueados.
- Visualización del muro del usuario al dar clic sobre la fotografía de un contacto.
39
Prototipo 2: Presentación del Curso
En este prototipo se ilustra la presentación de un curso de Moodle en una interfaz de
widgets. En cada widget dentro del curso actual, se deberá encontrar diferente tipo de
información relacionada al curso, información sobre: anuncios de profesor, foros,
participantes del curso, usuarios online, la red social del curso, recursos, cuestionarios,
y tareas.
Cuando se ha ingresado a un curso es sumamente importante identificar el rol que
posee el usuario en dicho curso, ya que algunas funcionalidades disponibles dentro de
los widgets con información, se encuentran restringidas para usuarios con rol de
estudiante, y solamente están disponibles para los usuarios que tienen un rol de
profesor.
Las funcionalidades que están disponibles únicamente para profesores del curso son:
- Agregar nuevo anuncio
- Agregar nuevo foro
- Agregar nueva discusión en un foro
- Agregar nuevo recurso
Ilustración 14 Prototipo de Presentación de Un Curso
40
- Agregar nueva tarea
- Agregar nuevo cuestionario
- Borrar anuncio
- Borrar foro
- Borrar discusión de un foro
- Borrar recurso
- Borrar tarea
- Borrar cuestionario
- Ver tareas subidas por los estudiantes
La lista de widgets presentados inicialmente en esta parte, se describen a
continuación:
Nombre de Widget Descripción Funcionalidades
Participantes Este widget contiene una lista de los usuarios que tienen un rol en el curso, se clasifican de acuerdo al rol que poseen. Se puede observar el perfil del usuario al ubicarse sobre la fotografía de éste, y se puede enviar mensajes privados a cualquiera de estos usuarios.
- Presentación de la lista de usuarios con rol en el curso.
- Clasificación de los usuarios de acuerdo a su rol.
- Vista del perfil de usuario de los participantes del curso.
- Posibilidad de enviar mensajes privados a cualquiera de los participantes listados.
Anuncios Contiene una lista con los anuncios que han sido colocados por el profesor en las secciones del curso. Si el usuario tiene rol de profesor, puede agregar uno nuevo.
- Presentación de anuncios colocados por el profesor en las secciones del curso.
- Posibilidad de navegar por cada anuncio individualmente, o de mostrar todos a la vez.
- Si el usuario tiene rol de profesor en el curso tiene la posibilidad de agregar, editar, y eliminar los anuncios puestos por él mismo anuncio.
- Posibilidad de permitir comentarios en los anuncios agregados.
- Posibilidad de agregar comentarios en los anuncios que lo permiten.
41
Cuestionarios Contiene la lista de cuestionarios disponibles en el curso, con la información correspondiente a cada uno. Si el usuario tiene rol de profesor, puede agregar uno nuevo.
- Presentación de la lista de cuestionarios disponibles en el curso.
- Si el usuario tiene rol de profesor podrá eliminar, y agregar nuevos.
Red social del curso Se presenta un widget que contiene una red social para el curso en el que se encuentre, en la que se tiene relación con los demás participantes de ese curso.
- Visualización de post y comentarios propios y de los contactos de la red.
- Capacidad de agregar posts en la red, y comentarios a los posts propios y de los demás participantes.
- Capacidad de eliminar posts y comentarios propios.
- Presentación de la opción さMW ェ┌ゲデ;ざ ヮ;ヴ; I;Sa post y comentario de la red social.
- Presentación de un menú de notificaciones sobre alguna acción en la red social.
- Presentación de menú de invitaciones a la red social.
- Presentación de menú de usuarios bloqueados.
Foros Contiene la lista de foros
disponibles en el curso, con la información correspondiente a cada uno. Al ingresar a un foro dando clic sobre el nombre de éste, se tendrá disponibles las discusiones del mismo, en las que se puede hacer los respectivos comentarios. Si el usuario tiene rol de profesor, puede agregar un nuevo foro, o una nueva discusión.
- Presentación de la lista de foros disponibles en el curso.
- Presentación de la lista de discusiones de cada foro.
- Si el usuario tiene rol de profesor podrá eliminar, y agregar nuevos foros, y nuevas discusiones en los foros.
- Posibilidad de agregar posts en las discusiones de los foros.
Recursos Contiene la lista de recursos disponibles en el curso, con la información correspondiente a cada uno. Si el usuario tiene rol de profesor, puede agregar uno nuevo.
- Presentación de la lista de recursos disponibles en el curso.
- Si el usuario tiene rol de profesor podrá eliminar, y agregar nuevos.
42
Tareas Contiene la lista de tareas disponibles en el curso, con la información correspondiente a cada uno. Si el usuario tiene rol de profesor, puede eliminar y agregar uno nuevo, y ver las tareas que han sido enviadas por cada estudiante.
- Presentación de la lista de tareas disponibles en el curso.
- Si el usuario tiene rol de profesor podrá eliminar, agregar nuevos, y ver las tareas que han sido enviadas por los estudiantes.
Usuarios en línea Se presenta la lista de usuarios conectados al sistema.
- Presentación de la lista de usuarios conectados al sistema.
- Posibilidad de enviar un mensaje privado al usuario conectado.
- Vista del perfil del usuario conectado.
Prototipo 3: Gestión de Amistades de la red social
Ilustración 15 Prototipo de Gestión de Amistades de la red social
43
Cuando el usuario hace clic sobre la ヮWゲデ;モ; さ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.
DWゲSW ノ; ノキゲデ; SW Iラミデ;Iデラゲが ゲW ヮヴWゲWミデ;ミ ノ;ゲ a┌ミIキラミ;ノキS;SWゲ さBノラケ┌W;ヴざ ┞ さ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
S;ミSラ IノキI ゲラHヴW ┌ミ Wミノ;IW さWミ┗キ;ヴ キミ┗キデ;Iキルミざ.
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
マWミゲ;テWが ┞ Wミ ケ┌Y aWIエ;が S;ミSラ IノキI ゲラHヴW Wノ Hラデルミ さM;ヴI;ヴ Iラマラ ノWケSラゲざが ゲW SWテ;ヴ= SW considerar para la presentación dicha lista de mensajes. La lista de mensajes se
actualiza automáticamente cada 60 segundos.
La lista de widgets presentados en esta parte, se describen a continuación:
Nombre de Widget Descripción Funcionalidades
Contactos Este widget contiene la lista de los contactos de la red social.
- Presentación de la lista de contactos de la red social.
- Opción eliminar contacto.
- Opción bloquear contacto.
- Opción de enviar mensaje privado al contacto.
- Vista de perfil de usuario al ubicarse sobre la fotografía del contacto.
Buscar Personas En este widget se presenta un campo desde donde se puede buscar un usuario en el sistema. Se presentan todos los usuarios relacionados con la búsqueda, con las opciones de eliminar, bloquear, enviar
- Ingresar un dato para la búsqueda de usuarios.
- Presentación de usuarios relacionados con la búsqueda.
- Presentar la opción eliminar y bloquear si el usuario
44
invitación, dependiendo de la relación entre el usuario que realiza la búsqueda y el usuario encontrado.
encontrado es un contacto.
- Presentar la opción enviar invitación si el usuario encontrado no es un contacto.
Usuarios en línea Se presenta la lista de usuarios conectados al sistema.
- Presentación de la lista de usuarios conectados al sistema.
- Posibilidad de enviar un mensaje privado al usuario conectado.
- Vista del perfil del usuario conectado.
Mensajes recibidos Se presenta un widget que contiene una lista de mensajes recibidos, indicando el usuario remitente. Se pude marcar la lista de mensajes como leídos para ya no mostrarlos en el widget.
- Lista de mensajes recibidos desde distintos usuarios.
- Identificación del usuario que ha enviado el mensaje.
- Opción de marcar la lista de mensajes como leídos, para ya no presentarlos en el widget.
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.
45
2.3.4 Diagrama de Clases
Las principales clases desarrolladas en este proyecto son las siguientes:
- ClassInitWS
- ClassTime
- ClassFuncionesPost
- ClassNotifications
- ClassAssignments
- ClassContacts
- ClassParticipants
- ClassQuizzes
- ClassSearch
- ClassForms
Todas estas son las clases desarrolladas en php, para dar soporte a las funcionalidades
requeridas por el sistema.
Estas clases son representadas en un diagrama de clases en la ilustración 16, en el cual
se muestra las dependencias entre dichas clases, sin embargo php no es un lenguaje
de programación con soporte completo para la programación orientada a objetos, por
lo que generalmente a estas clases se las usa también desde otros archivos php que no
están definidos como clases, sino que son archivos para ser presentados en el
navegador web, y suelen tener parte de código php y parte de etiquetas html.
En la representación del diagrama de clases (Ilustración 16) se usa dos tipos de
relaciones:
- Herencia y generalización . Permite que una clase hija herede
todos los atributos y propiedades de la clase padre.
La representación de herencia en UML (Unified Model Language) es a través de
una línea que termina en un triángulo sin relleno.
- Dependencia . Se define cuando una clase usa a otra como
parámetro de sus operaciones
46
Ilustración 16 Diagrama de Clases
La clase MoodleWS, es una clase generada automáticamente mediante la librería
wsdl2php.php, como complemento del plugin wspp, este proceso está descrito en el
manual de instalación.
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.
47
Clase ClassInitWS
Esta clase contiene las funcionalidades para establecer el valor de las variables
necesarias para la comunicación con los servicios web, dichas variables son requeridas
desde otras clases, razón por la que son heredas.
Funciones en ClassInitWS
get_usuario_ws(). Esta función obtiene la identificación del cliente del web service, la
cual debe ser enviada como parámetro en las funciones que realizan operaciones
mediante servicios web.
get_token_ws(). Esta función obtiene la clave de sesión del cliente del web service, la
cual debe ser enviada como parámetro en las funciones que realizan operaciones
mediante servicios web.
get_moodle_ws(). Esta función obtiene una variable inicializada como objeto de la
clase MoodleWS (generada automáticamente con la librería wsdl2php.php) de la capa
de web services.
set_usuario_ws(new_user). Establece el valor pasado como parámetro a la variable
que contiene la identificación del cliente del web service.
set_token_ws(new_token). Establece el valor pasado como parámetro a la variable
que contiene la clave de sesión del cliente del web service.
set_moodle_ws(new_moodlews). Establece el valor pasado como parámetro al objeto
que hace referencia a la clase MoodleWS.
48
ClaseTime
Esta clase contiene las funcionalidades para dar un formato de presentación a las
fechas.
Funciones en ClassTime
relativeTime(dt). Esta función transforma una fecha pasada como un entero, en una
fecha relativa.
relativeTime
Parametro Tipo Descripción Retorno
dt Entero Fecha, o time representada en un valor entero.
Cadena, con una fecha relativa
converter_to_int_date (string_date). Esta función transforma una fecha pasada en
una cadena, a una fecha representada en un entero.
converter_to_int_date
Parametro Tipo Descripción Retorno
string_date Cadena Fecha, representada en una cadena.
Cadena, con una fecha relativa
49
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
Parametro Tipo Descripción Retorno
estado_img Entero Valor 1 si el usuario tiene una fotografía en su perfil, 0 si no la tiene
Código html para presentación de los posts
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
Parametro Tipo Descripción Retorno
estado_img Entero Valor 1 si el usuario tiene una fotografía en su perfil, 0 si no la tiene
Código html para presentación de comentarios
user_id Entero Identificador del usuario dueño del comentario
nombrepostea Cadena Nombre y apellido del usuario dueño
50
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
Parametro Tipo Descripción Retorno
estado_img Entero Valor 1 si el usuario tiene una fotografía en su perfil, 0 si no la tiene
Código html para presentación de los anuncios que un profesor hace en un curso user_id Entero Identificador del
usuario dueño del anuncio (generalmente un profesor del curso)
nombrepostea Cadena Nombre y apellido 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.
present_actions_in_post(date_of_post,postid,myid,ownerpost,rsatype='',courseid=1). Esta
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 parámetro la fecha en que se ha
Código html para presentación de las acciones que se
51
realizado el post, ya que es parte de la presentación, junto con las acciones a realizar con el post.
puede realizar con cada post, las cuales serán distintas dependiendo del usuario y su relación con el post.
postid Entero Identificador del post sobre el cual se presentarán las 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 Parámetro Tipo Descripción Retorno
postid Entero Identificador del Código html para
52
post sobre el cual se presentarán las acciones.
presentación de los comentarios de cada post en la red social, sea ésta la red social inicial, o de cada curso, y para la presentación de los comentarios en los anuncios que los permiten.
my_id Entero Identificador del usuario identificado en el sistema actualmente.
courseid Entero Identificador del curso en el que se está realizando la presentación. Sería 1 si la presentación 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
53
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 Parámetro Tipo Descripción Retorno
postid Entero Identificador del post sobre el cual se presentarán las acciones.
Código html para presentación de un área en para agregar comentarios a los posts de la red social, sea ésta la red social inicial, o de cada curso, y para agregar comentarios en los anuncios que los permiten.
my_id Entero Identificador del usuario identificado en el sistema actualmente.
user_id Entero Identificador del usuario propietario del post que se pasó como primer parámetro.
courseid Entero Identificador del curso en el que se está realizando la presentación. Sería 1 si la presentación 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
54
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
55
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
Parametro Tipo Descripción Retorno
cadena_avisos Objeto Objeto con los datos que contiene la notificación. Estos datos son obtenidos mediante servicios web
Código html para presentación de los menús de notificaciones (de actividad en la red social, invitaciones de amistad, usuarios bloqueados).
parametro Entero Identificador del tipo de menú que se va a presentar. 0: Presentación de menú de usuarios bloqueados 1: Presentación de menú de solicitudes de amistad 2: Presentación de menú de actividad en la red social (cuando existen no leídas) 3: Presentación de menú de 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
56
さぱマ;キミざが さぱIラ┌ヴゲWざがざぱ;Sざ
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
Parametro Tipo Descripción Retorno
courseid Entero Id del curso actualmente seleccionado
Objeto con los datos de las notificaciones obtenidas. userid Entero Id del usuario actualmente
identificado.
rsa_type Cadena Identifica el tipo de red social en la que se realizará la presentación, puede ser さぱマ;キミざが さぱIラ┌ヴゲWざがざぱ;Sざ
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
Nombre del Archivo Descripción
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).
57
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
Parametro Tipo Descripción Retorno
assignments_in_course Objeto Objeto que contiene los datos sobre cada una de las tareas del curso.
Código html para presentación de la lista de tareas de un curso cuando el usuario tiene rol de profesor.
fields Array Array con los nombres de los datos que se desean 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
Parametro Tipo Descripción Retorno
assignments_in_course Objeto Objeto que contiene los datos sobre cada una de las tareas del curso.
Código html para presentación de la lista de tareas de un curso cuando el usuario tiene rol de estudiante.
fields Array Array con los nombres de los datos que se desean presentar del objeto pasado como primer parámetro.
58
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
Parametro Tipo Descripción Retorno
assignments_submission Objeto Objeto con todos los datos del recurso cargado por el estudiante en la tarea
Código html para realizar la presentación de la lista de tareas subidas por los estudiantes. Sólo se presenta cuando el usuario tiene rol de profesor.
fields Array . Arreglo con los campos que se va a procesar del objeto pasado como primer parámetro
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
Nombre del Archivo Descripción
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.
59
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
Parametro Tipo Descripción Retorno
contact_list Objeto Objeto con toda la información de los contactos del usuario
Código html para realizar la 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
Nombre del Archivo Descripción
ContactsList Contiene las funcionalidades para presentar la lista de contactos del usuario dentro del widget de contactos
60
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
Parametro Tipo Descripción Retorno
participants_list Objeto Objeto con toda la información de los participantes del curso.
Código html para realizar la 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
Nombre del Archivo Descripción
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.
61
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
Parametro Tipo Descripción Retorno
quizzes_in_course Objeto Objeto con toda la información de los cuestionarios del curso.
Código html para realizar la presentación de la lista de cuestionarios en un curso.
fields Array Arreglo con todos los campos que se desean visualizar del objeto en el 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
Nombre del Archivo Descripción
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.
62
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
Parametro Tipo Descripción Retorno
searcher_user Objeto Objeto con la información del usuario encontrado según la búsqueda.
Código html para realizar la 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
Nombre del Archivo Descripción
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.
63
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
Parametro Tipo Descripción Retorno
userid Entero Id del usuario actualmente identificado
Tipo: Entero. 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
Nombre del Archivo Descripción
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
64
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.
65
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 Wノ さSWゲ;ヴヴラノノラ Wミ ヮ;ヴWテ;ゲざ SWHキSラ ; ケ┌W ú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/
66
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 ゲWヴ┗キIキラゲ ┘WH ぐぐぐぐぐぐぐぐぐぐぐぐぐぐ ヱ47 Capa SW ┘キSェWデゲ ぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐく ヱヵヱ Capa de red sラIキ;ノ ぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐく ヱヵン
67
2.5 PRUEBAS
さL; ヮヴ┌WH; Wゲ ┌ミ Iラミテ┌ミデラ SW ;Iデキ┗キS;SWゲ ケ┌W ゲW ヮノ;ミW;ミ Iラミ ;ミデキIキヮ;Iキルミ ┞ ゲW ヴW;ノキ┣;ミ 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
SWノ SキゲWモラ SW I;ゲラゲ SW ヮヴ┌WH;ぶ さ (Pressman, 2006).
さL;ゲ ヮヴ┌WH;ゲ SWノ ゲラaデ┘;ヴW ゲラミ ┌ミ Iラミテ┌ミデラ SW ;Iデキ┗キS;SWゲ ケ┌W ヮWヴマキデWミ ノノW┗;ヴ ; I;Hラ ┌ミ ヮノ;ミキaキI;Iキルミ ┞ ゲWェ┌キマキWミデラ ラヴSWミ;Sラ SW ノ;ゲ マキゲマ;ゲくざ (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.
68
3 CAPÍTULO III: PLAN DE
PRUEBAS
69
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.
70
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]
71
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 recursos recomendados
Especificación de responsabilidades
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 recursos recomendados
Nombre - Tipo
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
72
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ミW┝ラΒぱRWゲPヴ┌WH;ゲUnitariasWS.docxざ;
Anexo 8 Página
Resultado de pruebas unitarias de los servicios web ぐくくぐぐぐぐぐぐぐぐくく 227 TWゲデゲ RWゲ┌ノデゲ ぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐくぐぐぐぐぐぐぐぐぐぐ.. 230
Los resultados de la ejecución de las pruebas funcionales del sistema se encuentran en
el anexo Γ さAミW┝ラΓぱRWゲPヴ┌WH;ゲF┌ミIキラミ;ノWゲ.docxざく
Anexo 9 Página
Resultado de pruebas funcionales ぐくくぐぐぐくぐぐく 234
73
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ミW┝ラヱヰぱM;ミ┌;ノInstalacionくSラI┝ざ
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ミW┝ラヱ1_ManualUsuario.docxざ
Anexo 11 Página
M;ミ┌;ノ SW ┌ゲ┌;ヴキラ SWノ ゲキゲデWマ; ぐぐぐくくぐぐぐくぐぐく 250 P;ミデ;ノノ; PヴキミIキヮ;ノ ふIミキIキラぶ くくぐぐぐぐぐぐぐぐぐぐぐぐ ヲ51 MWミ┎ SW WキSェWデゲ ぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐ ヲ52 P;ミデ;ノノ; Aマキェラゲ ぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐ ヲ52 Pantalla Curso ぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐ ヲ53 RWS SラIキ;ノ ぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐく ヲ56
74
4 DISCUSIÓN
75
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.
76
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.
77
5 CONCLUSIONES Y
RECOMENDACIONES
78
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
79
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.
80
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.
81
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.
82
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.
83
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> [citado en 14 de marzo del 2011] v SCRIPTACULOUS. script.aculo.us Framework. [en línea]. <http://script.aculo.us/> [citado en 14 de marzo del 2011] 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].
84
ANEXO 1: TEST DE CLIENTE
WSPP
85
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
エWヴヴ;マキWミデ; SW ヮエヮ ノノ;マ;S; さ┘ゲSノヲヮエヮくヮエヮざ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
En el caso dado que se esté ┌ゲ;ミSラ さ┝;マヮヮざ2 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
Véase:
1 [En línea].<http://www.urdalen.no/wsdl2php/manual.php>[citado en 21 de febrero del 2011]
Véase: 2 [En línea].<http://www.apachefriends.org/es/xampp.html>[citado en 21 de febrero del 2011]
86
Con esto se crean dos SキヴWIデラヴキラゲぎ さデWゲデざ ┞ さIノ;ゲsWゲざが Wミ ノラゲ I┌;ノWゲ エ;┞ ┗;ヴキ;ゲ Iノ;ゲWゲ útiles con archivos php que contienen las operaciones disponibles del servicio SOAP,
dentro del directorio clases encontramos un archivo muy importante llamado
さMララSノWW“くヮエヮざが Wノ I┌;ノ ラHデキWミ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く DWミデヴラ SWノ SキヴWIデラヴキラ さデWゲデざ W┝キゲデWミ ;ノェ┌ミラゲ I;ゲラゲ SW ヮヴ┌WH; 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
Autenticación con un usuario válido de moodle
MWSキ;ミデW ┌ミ ラHテWデラ SW ノ; Iノ;ゲW MララSノWWゲ ノノ;マ;ヴ ; ノ; a┌ミIキルミ さェWデぱ┌ゲWヴゲざが ノ; cual nos devuelve un array con los usuarios desde el servido Moodle a través
del protocolo SOAP.
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
Iラゲ;ゲ さ┘ゲSノヲヮエヮざく
Al final lo que hacemos es cerrar la sesión
Véase: 3 [En línea].<http://docs.moodle.org/en/Web_Services:OK_Tech_Web_Services>[citado en 21 de febrero del 2011]
require_once('classes/MoodleWS.php');
$lr= $moodle->login("usuario","password");
$users=$moodle->get_users($lr->client,$lr->sessionkey,NULL,NULL);
$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エ┞デラミが ノ; ヮノ;デ;aラヴマ; くNWデが ぐ WミデヴW ラデヴラゲく
87
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:
Los resultados presentados son algunos servicios obtenidos mediante Web Services
haciendo uso del plugin wspp.
Ilustración 2 Datos presentados en el cliente (Aplicación Externa)
88
ANEXO 2: WS Moodle 2.0
89
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.
Véase: 1[en línea]. http://docs.moodle.org/en/Development:Web_services#Web_services_technical_documentation>[citado en 21 de febrero del 2011] Véase: 2 [en linea].<http://blogs.dfwikilabs.org/pigui/2009/04/27/moodle-20-web-services-architecture>[citado en 21 de febrero del 2011]
90
Arquitectura Interna de Los SW en Moodle 2.0.x3
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
aヴ;マW┘ラヴニ ヮ;ヴ; PHP ノノ;マ;Sラ さZWミSざが Wノ I┌;ノ HヴキミS; ノ;ゲ a┌ミIキラミ;ノキS;SWゲ ヮ;ヴ; エ;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]
Ilustración 1 Arquitectura Interna de Los SW en Moodle 2.0.x
91
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 >>
ASマキミキゲデヴ;Iキルミ SWノ “キデキラ бб C;ヴ;IデWヴケゲデキI;ゲ A┗;ミ┣;S;ゲが ┞ ゲWノWIIキラミ;マラゲ ノ; I;Iキノノ; さH;Hキノキデ;ヴ ゲWヴ┗キIキラゲ ┘WHざ ケ┌W ヮラヴ SWaWIデラ Wゲデ= SWゲエ;Hキノキデ;S;が ┞ ェ┌;ヴS;マラゲ ノラゲ I;マHキラゲく
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.
NルデWゲW Wミ ノ; aキェ┌ヴ; ;ミデWヴキラヴ ケ┌W Wゲデ= ゲWノWIIキラミ;S; ノ; I;Iキノノ; さDラI┌マWミデ;Iキルミ SW ゲWヴ┗キIキラゲざが 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
Ilustración 2 Habilitación de servicios web
Ilustración 3 Habilitar protocolos para el servicio web
92
Administración del Sitio >> Extensiones >> Servicios Web >> Administrar Protocolos, y damos
clic en Agregar. Nos aparecerá un formulario como el de la siguiente figura:
Eミ ノ; ヮ;ヴデW SW さNラマHヴWざ S;マラゲ Wノ ミラマHヴW WノWェキSラ ヮ;ヴ; Wノ ゲWヴ┗キIキラが ノラゲ エ;Hキノキデ;マラゲ マ;ヴI;ミSラ ノ; I;ゲキノノ; さH;Hキノキデ;Sラざが ┞ Wミ ノ; I;Iキノノ; さÚミキI;マWミデW ┌ゲ┌;ヴキラゲ ;┌デラヴキ┣;Sラゲざ SWHWヴWマラゲ マ;ヴI;ヴノ; ゲキ 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ェヴWェ;ヴ ゲWヴ┗キIキラざく
Con esto nos lleva a una ubicación donde aparece una opción para agregar funciones al
servicio, como en la figura siguiente:
4.- El siguiente paso es añadir funciones al servicio, para que sean usadas por la
;ヮノキI;Iキルミ W┝デWヴミ;く “Wェ┌キマラゲ Wノ ノキミニ さAェヴWェ;ヴ a┌ミIキラミWゲざ ケ┌W ゲW ヮ┌WSW ラHゲWヴ┗;ヴ Wミ ノ; 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ェヴWェ;ヴ a┌ミIキラミWゲざく
Ilustración 4 Agregar un servicio externo
Ilustración 5 Agregar funciones al servicio
Ilustración 6 Seleccionar funciones para el servicio
93
Entonces se mostrarán la lista de funciones del servicio, y frente a cada función el campo
さRWケ┌キヴWS I;ヮ;HキノキデキWゲざが ケ┌W キSWミデキaキI; ノラゲ ヮWヴマキゲラゲ ケ┌W 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.
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
┗; ; ┌ゲ;ヴ Wノ ゲWヴ┗キIキラが ┞ ヮヴWゲキラミ;マラゲ Wノ Hラデルミ さMラゲデヴ;ヴ ノラゲ ヮWヴマキゲラゲ SW WゲデW ┌ゲ┌;ヴキラざが ┞ ミラゲ 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:
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:
Ilustración 7 Permiso para usar el protocolo del WS
Ilustración 8 Usuario con permiso para usar el protocolo SOAP
94
DWゲSW Wノ I;マヮラ さUゲ┌;ヴキラゲざ エ;IWマラゲ IノキI Wミ Wノ Wミノ;IW さUゲ┌;ヴキラゲ ;┗;ミ┣;Sラゲざが ノラ I┌;ノ ミラゲ SキヴキェW ; un lugar en donde seleccionaremos el usuario del sistema externo.
“WノWIIキラミ;マラゲ Wノ ┌ゲ┌;ヴキラ IラヴヴWIデラが ┞ S;マラゲ IノキI Wミ Wノ Hラデルミ さAェヴWェ;ヴざが Iラミ ノラ ケ┌W Wノ ┌ゲ┌;ヴキラ queda autorizado para usar las funciones correspondientes al servicio que tiene asignado.
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ミ Yゲデ; ヮ=ェキミ; SW ;Sマキミキゲデヴ;Iキルミ SW デラニWミゲ エ;IWマラゲ IノキI ゲラHヴW さAモ;Sキヴざが Wゲデラ ミラゲ ノノW┗; ; ┌ミ; 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 9 Información de los servicios externos existentes
Ilustración 10 Agregar usuario para uso del servicio
Ilustración 11 Token generado para el usuario del sistema externo
95
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:
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.
Ilustración 12 Parámetros para testeo del WS
96
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.
97
ANEXO 3: JPOLITE
98
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.
99
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
;ヮノキI;IキラミWゲが I┌┞; ノルェキI; WゲデY SWゲ;ヴヴラノノ;S; Wミ PHPが J;┗;が P┞デエラが R;キノゲ ぐ I┌┞; ゲ;ノキS; ゲW;ミ ú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
ノノWェ; ; ゲWヴ マ=ゲ ゲキマヮノW ┞ マ=ゲ WミaラI;S;が ヮラヴ Wゲラ ゲW ノノ;マ; ;ノ ゲWヴ┗キSラヴ さTエキミ “Wヴ┗Wヴざく
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.
Ilustración 1 Arquitectura de Desarrollo de JPolite
100
Como se puede notar JPolite sigue el patrón de arquitectura de software MVC (Modelo
Vista Controlador). Según (Sommerville, 2005) さEノ マ;ヴIラ SW デヴ;H;テラ MVC a┌W 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
ヮヴWゲWミデ;IキラミWゲが Wノ ヴWゲデラゲ SW ノ;ゲ ヮヴWゲWミデ;IキラミWゲ ゲラミ ;Iデ┌;ノキ┣;S;ゲく ざ
En la arquitectura de JPolite se ha representado el MVC de la siguiente manera:
さB;IニWミSざ Iラマラ Wノ Modelo
さ“キミェノW P;ェW AヮヮノキI;デキラミざ Iラマラ Vista
さTエキミ “Wヴ┗Wヴざ Iラマラ Controlador
101
ANEXO 4: HISTORIAS DE
USUARIO
102
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.
103
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.
104
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
ID:2 Importancia: 600
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.
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
105
Historia de Usuario
Historia: Presentación de los participantes de cada curso correspondiente al usuario
identificado, identificando si es estudiante o profesor del curso
ID:3 Importancia: 600
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.
Observaciones: Usando servicios web.
Historia de Usuario
Historia: Presentación de los anuncios hechos por el profesor en un curso
ID:4 Importancia: 600
Descripción:
Para cada uno de los cursos del usuario, presentar los anuncios que ha hecho el
profesor.
Observaciones: Usando servicios web.
106
Historia de Usuario
Historia: En caso de tener rol de profesor en el curso, permitirle agregar nuevos
anuncios, y editarlos
ID:5 Importancia: 600
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.
Observaciones: Usando servicios web.
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.
ID:6 Importancia: 600
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.
Observaciones: Usando servicios web.
107
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.
ID:7 Importancia: 600
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.
Observaciones: Usando servicios web.
Historia de Usuario
Historia: Presentar una lista de los recursos disponibles en un curso.
ID:8 Importancia: 600
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.
Observaciones: Usando servicios web.
108
Historia de Usuario
Historia: Presentar una lista de cuestionarios disponibles en el curso.
ID:9 Importancia: 600
Descripción:
Presentar a los usuarios los cuestionarios agregados en cada uno de los cursos en los
cuales participa.
Observaciones: Usando servicios web.
Historia de Usuario
Historia: Presentar una lista de los usuarios que se encuentran conectados en el
sistema.
ID:10 Importancia: 600
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.
Observaciones: Usando servicios web.
109
Historia de Usuario
Historia: Presentar una lista de los contactos del usuario.
ID:11 Importancia: 600
Descripción:
Presentar a cada usuario una lista con la información de otros usuarios, que están en la
lista de sus contactos.
Observaciones: Usando servicios web.
Historia de Usuario
Historia: Permitir a hacer una búsqueda de los usuarios del sistema
ID:12 Importancia: 600
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.
Observaciones: Usando servicios web.
110
Historia de Usuario
Historia: Presentar los mensajes recibidos de un usuario.
ID:13 Importancia: 600
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.
Observaciones: Usando servicios web.
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
ID:14 Importancia: 600
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.
Observaciones: Usando servicios web.
111
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
sobre la ventana del navegador.
ID:15 Importancia: 600
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:
112
Historia de Usuario
Historia: Fijar estas pantallas pequeñas a distintos bloques dentro de la
página, de manera que aparezcan ordenadamente.
ID:16 Importancia: 600
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
ID:17 Importancia: 600
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:
113
Historia de Usuario
Historia: Presentar un menú de con las pantallas movibles disponibles y que
se puedan agregar a la ventana inicial del navegador
ID:18 Importancia: 600
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
ID:19 Importancia: 600
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:
114
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ヴWゲWミデ;ヴ ノ; ラヮIキルミ さMW ェ┌ゲデ;ざ ヮ;ヴ; ノラゲ ヮラゲデゲ ┞ IラマWミデ;ヴキラゲが ;ノ ┌ゲ;ヴ
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.
115
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.
Observaciones: Usando servicios web.
Historia de Usuario
Historia: Presenta un listado de los post realizados del usuario, y también los
realizados por parte de sus contactos.
ID: 21 Importancia: 600
Descripción:
Presentar al usuario todos los posts realizados por sus contactos, y los suyos propios
dentro de la interfaz dinámica.
Observaciones: Usando servicios web.
116
Historia de Usuario
Historia: Permitir agregar comentarios en los posts de su red, ya sean de sus
contactos, o los suyos propios.
ID: 22 Importancia: 600
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.
Observaciones: Usando servicios web.
Historia de Usuario
Historia: Permitir eliminar sea posts o comentarios que sean de propiedad del usuario
identificado.
ID: 23 Importancia: 600
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.
Observaciones: Usando servicios web.
117
Historia de Usuario
Historia: Permitir ingresar al muro de los contactos de la red del usuario
ID: 24 Importancia: 600
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.
Observaciones: Usando servicios web.
Historia de Usuario
Historia: Presentar ノ; ラヮIキルミ さMW ェ┌ゲデ;ざ ヮ;ヴ; ノラゲ ヮラゲデゲ ┞ IラマWミデ;ヴキラゲが ;ノ ┌ゲ;ヴ Wゲデ; opción el usuario dueño del post o comentario recibirá una notificación que ha dicho
usuario le ha gustado su anuncio.
ID: 25 Importancia: 600
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.
Observaciones: Usando servicios web.
118
Historia de Usuario
Historia: Presentar una lista de notificaciones con las actividades que se ha realizado
relacionadas con su red social
ID: 26 Importancia: 600
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.
Observaciones: Usando servicios web.
Historia de Usuario
Historia: Presentar de los usuarios bloqueados.
ID: 27 Importancia: 600
Descripción:
Presentar al usuario identificado una lista con los usuarios que han sido bloqueados
por él mismo.
Observaciones: Usando servicios web.
119
Historia de Usuario
Historia: Permitirle al usuario enviar invitaciones de amistad a otros usuarios del
sistema, y permitirle bloquearlos y eliminarlos.
ID: 28 Importancia: 600
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.
Observaciones: Usando servicios web.
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.
ID: 29 Importancia: 600
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.
Observaciones: Usando servicios web.
120
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.
ID: 30 Importancia: 600
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.
121
ANEXO 5: PLAN DE
ENTREGAS E ITERACIONES
122
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
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
123
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
ID:2 Importancia: 600
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.
Historia de Usuario
Historia: Presentación de los participantes de cada curso correspondiente al usuario
identificado, identificando si es estudiante o profesor del curso
ID:3 Importancia: 600
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.
Observaciones: Usando servicios web.
124
Historia de Usuario
Historia: Presentación de los anuncios hechos por el profesor en un curso
ID:4 Importancia: 600
Descripción:
Para cada uno de los cursos del usuario, presentar los anuncios que ha hecho el
profesor.
Observaciones: Usando servicios web.
Historia de Usuario
Historia: En caso de tener rol de profesor en el curso, permitirle agregar nuevos
anuncios, y editarlos
ID:5 Importancia: 600
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.
Observaciones: Usando servicios web.
125
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.
ID:6 Importancia: 600
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.
Observaciones: Usando servicios web.
126
SEGUNDA ITERACIÓN
Duración: 4 semanas Periodo: (mar-14-2011 - abr-14-2011)
Historias Comprendidas:
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.
ID:7 Importancia: 600
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.
Observaciones: Usando servicios web.
127
Historia de Usuario
Historia: Presentar una lista de los recursos disponibles en un curso.
ID:8 Importancia: 600
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.
Observaciones: Usando servicios web.
Historia de Usuario
Historia: Presentar una lista de cuestionarios disponibles en el curso.
ID:9 Importancia: 600
Descripción:
Presentar a los usuarios los cuestionarios agregados en cada uno de los cursos en los
cuales participa.
Observaciones: Usando servicios web.
128
Historia de Usuario
Historia: Presentar una lista de los usuarios que se encuentran conectados en el
sistema.
ID:10 Importancia: 600
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.
Observaciones: Usando servicios web.
Historia de Usuario
Historia: Presentar una lista de los contactos de un usuario.
ID:11 Importancia: 600
Descripción:
Presentar a cada usuario una lista con la información de otros usuarios, que están en la
lista de sus contactos.
Observaciones: Usando servicios web.
129
Historia de Usuario
Historia: Permitir a hacer una búsqueda de los usuarios del sistema
ID:12 Importancia: 600
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.
Observaciones: Usando servicios web.
130
TERCERA ITERACIÓN
Duración: 4 semanas Periodo: (abr-15-2011 - may-13-2011)
Historias Comprendidas:
Historia de Usuario
Historia: Presentar los mensajes recibidos de un usuario.
ID:13 Importancia: 600
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.
Observaciones: Usando servicios web.
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
ID:14 Importancia: 600
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.
Observaciones: Usando servicios web.
131
Historia de Usuario
Historia: Presentar el contenido en pantallas pequeñas que se puedan mover
sobre la ventana del navegador.
ID:15 Importancia: 600
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.
ID:16 Importancia: 600
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:
132
Historia de Usuario
Historia: Minimizar, maximizar, actualizar y cerrar las pantallas pequeñas con
su contenido
ID:17 Importancia: 600
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
ID:18 Importancia: 600
Descripción:
Las pantallas pequeñas movibles deben presentarse en una lista, de donde se
puedan agregar a la ventana del navegador.
Observaciones:
133
CUARTA ITERACIÓN
Duración: 4 semanas Periodo: (may-16-2011 - jun-17-2011)
Historias Comprendidas:
Historia de Usuario
Historia: Presentar la información de Moode obtenida mediante Web Services, en
las pantallas movibles dentro del navegador
ID:19 Importancia: 600
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
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 quiere compartir con sus contactos del sistema.
Observaciones: Usando servicios web.
134
Historia de Usuario
Historia: Presenta un listado de los post realizados del usuario, y también los
realizados por parte de sus contactos.
ID: 21 Importancia: 600
Descripción:
Presentar al usuario todos los posts realizados por sus contactos, y los suyos propios
dentro de la interfaz dinámica.
Como Probarlo: Usando servicios web.
Historia de Usuario
Historia: Permitir agregar comentarios en los posts de su red, ya sean de sus
contactos, o los suyos propios.
ID: 22 Importancia: 600
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.
Observaciones: Usando servicios web.
135
Historia de Usuario
Historia: Permitir eliminar sea posts o comentarios que sean de propiedad del usuario
identificado.
ID: 23 Importancia: 600
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.
Observaciones: Usando servicios web.
Historia de Usuario
Historia: Permitir ingresar al muro de los contactos de su red
ID: 24 Importancia: 600
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.
Observaciones: Usando servicios web.
136
QUINTA ITERACIÓN
Duración: 4 semanas Periodo: (jun-20-2011 - jul-22-2011)
Historias Comprendidas:
Historia de Usuario
Historia: Presentar ノ; ラヮIキルミ さMW ェ┌ゲデ;ざ ヮ;ヴ; ノラゲ ヮラゲデゲ ┞ IラマWミデ;ヴキラゲが ;ノ ┌ゲ;ヴ Wゲデ; opción el usuario dueño del post o comentario recibirá una notificación que ha dicho
usuario le ha gustado su anuncio.
ID: 25 Importancia: 600
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.
Observaciones: Usando servicios web.
Historia de Usuario
Historia: Presentar una lista de notificaciones con las actividades que se ha realizado
relacionadas con su red social
ID: 26 Importancia: 600
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.
Observaciones: Usando servicios web.
137
Historia de Usuario
Historia: Presentar de los usuarios bloqueados.
ID: 27 Importancia: 600
Descripción:
Presentar al usuario identificado una lista con los usuarios que han sido bloqueados
por él mismo.
Observaciones: Usando servicios web.
138
SEXTA ITERACIÓN
Duración: 4 semanas Periodo: (jul-25-2011 - ago-26-2011)
Historias Comprendidas:
Historia de Usuario
Historia: Permitirle al usuario enviar invitaciones de amistad a otros usuarios del
sistema, y permitirle bloquearlos y eliminarlos.
ID: 28 Importancia: 600
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.
Observaciones: Usando servicios web.
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.
ID: 29 Importancia: 600
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.
Observaciones: Usando servicios web.
139
Historia de Usuario
Historia: Adaptación del desarrollo a Moodle 2.0.x.
ID: 30 Importancia: 600
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.
140
ANEXO 6:
DOCUMENTACION DE
DESARROLLO
141
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
IヴW; ┌ミ; ミ┌W┗; ┗Wヴゲキルミ ノノ;マ;S; さ┘ゲヮヮぱ┌デヮノざ.
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 estado de una aceptación o no aceptación de amistad de un
Desarrollada
142
usuario.
add_assignment Para agregar una nueva tarea (modulo tipo assignment), luego sería agregado a un curso específico.
Usada de WSPP
add_assignment2 Para agregar un modulo a un curso específico.
Desarrollada
add_comment_in_rsa Realiza la operación de registrar un nuevo comentario a un post de la red social
Desarrollada
add_forum Realiza la operación de agregar un nuevo foro (modulo tipo forum), luego seria agregado a un curso especifico.
Usada de WSPP
add_post_in_rsa Realiza las operaciones para agregar un nuevo post en la red social.
Desarrollada
add_quiz_mod Realiza las operaciones para agregar un cuestionario (modulo tipo quiz), que luego sería agregado a un curso.
Desarrollada
add_resource_mod Realiza las operaciones para agregar un nuevo recurso (modulo tipo resource), que luego sería agregado a un curso.
Desarrollada
add_section Realiza las operaciones para colocar un anuncio en un curso específico.
Desarrollada
allow_comments Verifica si el anuncio de una 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.
Desarrollada
delete_ads_with_comments Elimina un anuncio con la opción de agregar comentario de una determinada sección de un curso.
Desarrollada
delete_comment_in_rsa Elimina comentarios realizados a un post.
Desarrollada
delete_mod_from_course_section
Elimina un modulo que se encuentra agregado a un curso, ejm. Assignments, resources, fórums, etc.
Desarrollada
delete_post Elimina un post de la red social.
Desarrollada
edit_ad_insection Actualiza el contenido de un anuncio en la sección de un curso.
Desarrollada
143
edit_assignments Edita el contenido del modulo assignments.
Usada de WSPP
edit_forums Actualiza el contenido de un foro.
Usada de WSPP
forum_add_discussion Agrega una discusión a un foro de un determinado curso.
Desarrollada
forum_add_reply Agrega un post a la discusión de un foro.
Usada de WSPP
forum_delete_discussion Elimina la discusión de un foro. Desarrollada
get_activitiesmuro Obtiene los posts del muro de la red social de un usuario.
Desarrollada
get_ads_in_course Obtiene los anuncios realizados la sección de un curso.
Desarrollada
get_all_assignments Obtiene la lista de las tareas (modulo assignment) agregadas a un curso.
Desarrollada
get_all_forums Obtiene la lista de foros (modulo forum) agregados a un curso.
Modificada de WSPP
get_all_quizzes Obtiene la lista de cuestionarios (modulo quiz) agregados a un curso.
Modificada de WSPP
get_assignment_submissions
Obtiene la lista de archivos subidos por un estudiante en una tarea (assignment)
Desarrollada
get_categories Obtiene las categorías en las que se encuentran clasificados los cursos.
Usada de WSPP
get_comments_rsa Obtiene los comentarios realizados a los posts de la red social.
Desarrollada
get_contacts Obtiene los contactos de un usuario en el sistema.
Desarrollada
get_forum_discussions Obtiene las discusiones agregadas a un foro.
Desarrollada
get_forum_posts Obtiene los posts agregados a las discusiones de los foros.
Desarrollada
get_forums_bycourse Obtiene los foros pertenecientes a un curso específico.
Desarrollada
get_invitations Obtiene la lista de invitaciones pendientes que tiene un usuario.
Desarrollada
get_messages Obtiene la lista de mensajes obtenidos recibidos por un usuario
Desarrollada
get_more_users Realiza la búsqueda de usuarios en el sistema.
Desarrollada
get_my_courses_byusername
Obtiene la lista de cursos correspondientes a un usuario.
Usada de WSPP
144
get_my_id Obtiene el id del usuario identificado.
Usada de WSPP
get_new_idsection Obtiene el id de una sección que se encuentre vacía.
Desarrollada
get_notifications Obtiene una lista de las notificaciones de la red social de un usuario, por comentarios hechos en sus posts, o por que otro usuario ha seleccionado la ラヮIキルミ さMW ェ┌ゲデ;ざ de alguno de sus posts
Desarrollada
get_number_new_notifications
Obtiene el numero de las nuevas notificaciones desde la ultima revisión del usuario.
Desarrollada
get_participants_in_course Obtiene una lista de los participantes de un curso específico.
Desarrollada
get_posts_rsa Obtiene la lista de posts realizadas en la red social principal del usuario.
Desarrollada
get_posts_rsa_course Obtiene la lista de posts en la red social de un curso determinado.
Desarrollada
get_resources Obtiene la lista de recursos (modulo resource) de un curso especifico.
Desarrollada
get_user_byid Obtiene todos los datos de un usuario identificado por su id.
Usada de WSPP
get_users_bycourse Obtiene la lista de usuarios de un curso.
Usada de WSPP
get_users_online Obtiene la lista de usuarios conectados al sistema en los últimos 5 minutos.
Desarrollada
is_teacher_in_course Verifica si un usuario tiene rol de profesor en un curso específico.
Desarrollada
login Realiza la autenticación de un usuario.
Usada de WSPP
logout Cierra la sesión de un usuario en el sistema.
Usada de WSPP
message_add_contact Agrega un nuevo usuario a la lista de contactos.
Desarrollada
message_block_contact Bloquea un usuario de la red social.
Desarrollada
message_move_toreaded Especifica que los mensajes recibidos han sido leídos por su destinatario.
Desarrollada
message_remove_contact Elimina un contacto de la lista de contactos de un usuario.
Desarrollada
message_send Realiza el envió de un mensaje privado a un usuario.
Desarrollada
145
message_unblock_contact Desbloquea un usuario que ha sido bloqueado anteriormente en la red social.
Desarrollada
register_activity Registra una actividad realizada en la red social por el usuario.
Desarrollada
register_notification_log Agrega las acciones realizadas al log en la base de datos.
Desarrollada
remove_post_to_discussion Elimina el post de la discusión de un foro.
Desarrollada
update_section Actualiza el contenido de una sección de un curso.
Desarrollada
update_user Actualiza los datos de un usuario, se usa para actualizar el perfil del usuario identificado.
Usada de WSPP
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>
146
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.
147
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 o no acepta invitación
Comunicación con WS
ClassFuncionesPost.php Contiene funciones para realizar la presentación de los posts y comentarios en forma de red social.
Clase
ClassNotifications.php Contiene funciones para obtener las notificaciones de un usuario y presentarlas en un menú.
Clase
Present_ads_in_course.php Vista de anuncios hechos en un curso.
Presentación en Widget
Present_course_rsa.php Vista de la red social de un curso.
Presentación en Widget
Present_main_rsa.php Vista de la red social principal.
Presentación en Widget
Present_wall.php Vista del muro de un Presentación en Widget
148
usuario Ads_in_course.php Obtiene todos los anuncios
que ser presentaran en un curso
Comunicación con WS
comment_ajax.php Registra la adición de un nuevo comentario a un post
Comunicación con WS
Course_rsa_data.php Obtiene todos los datos que se presentarán en la red social de un curso
Comunicación con WS
Delete_comment.php Registra la eliminación de un comentario de un post
Comunicación con WS
Delete_update.php Registra la eliminación de un post
Comunicación con WS
Edit_ad_ofteacher.php Registra un cambio en el anuncio de una sección.
Comunicación con WS
Main_rsa_data.php Obtiene todos los datos que se presentaran en la red social principal
Comunicación con WS
More_comments.php Presenta una lista de nuevos comentarios, a partir de los que ya están visibles.
Comunicación con WS
Moreposts_incourse.php Presenta una lista de posts de un curso, a partir de los que ya están visibles.
Comunicación con WS
New_ad_in_course.php Registra la adición de un nuevo anuncio en la sección de un curso.
Comunicación con WS
New_post_in_wall.php Registra la adición de un nuevo post en el muro de un usuario
Comunicación con WS
New_post_main_rsa.php Registra la adición de un nuevo post en la red social principal del usuario.
Comunicación con WS
New_post_rsa_course.php Registra la adición de un nuevo post en la red social de un curso.
Comunicación con WS
register_activity.php Registra una acción en la red social, como un like o un nuevo comentario.
Comunicación con WS
Register_log.php Agrega un log en la base de datos sobre la actividad realizada
Comunicación con WS
View_more_notifications.php Obtiene una nueva lista de notificaciones a partir de las que ya se han mostrado.
Comunicación con WS
View_ specific_post.php Obtiene el post específico en el que se ha registrado una actividad.
Comunicación con WS
Wall_data.php Obtiene todos los datos que se presentaran en el muro
Comunicación con WS
149
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 un estudiante.
Comunicación con WS
ClassAssignments.php Contiene métodos para la presentación de los anuncios de tareas puestos por el profesor.
Clase
ClassContacts.php Contiene funciones para presentar la lista de contactos del usuario
Clase
ClassCourse.php Contiene funciones para obtener los cursos separados por categorías, y presentarlos en una lista adecuadamente clasificados
Clase
ClassForms.php Es una clase que contiene la definición de los formularios requeridos para agregar nuevos módulos en los cursos.
Clase
ClassParticipants.php Contiene funciones para obtener la lista de los participantes del curso
Clase
ClassQuizzes.php Contiene funciones para presentar la lista de cuestionarios abiertos en un curso.
Clase
ClassSearch.php Contiene funciones para presentar los usuarios encontrados como resultado de una búsqueda
Clase
ClassTime.php Funciones para obtener formatos de presentación de fecha
Clase
ContactsList.php Vista de la lista de contactos de un usuario.
Presentación en Widget
Course_Resourse.php Vista de los recursos disponibles en un curso, y del formulario para agregar uno
Presentación en Widget
150
nuevo en caso que el usuario sea el profesor del curso
Course_List.php Vista de los cursos de un usuario.
Presentación en Widget
Files_assignments_submissions.php
Forums_List.php Vista de los foros disponibles en un curso, y del formulario para agregar uno nuevo en caso que el usuario sea el profesor del curso
Presentación en Widget
Online_Users_List.php Vista de los usuarios conectados en los últimos minutos al sistema.
Presentación en Widget
SearchUsers.php Vista de formulario para buscar usuarios.
Presentación en Widget
ViewSearchedUsers.php Obtiene la lista de usuarios encontrados en una búsqueda.
Comunicación con WS
add_assignment.php Vista de la lista de las tareas disponibles en el curso, y del formulario para agregar una nueva en caso que el usuario sea el profesor del curso
Presentación en Widget
add_contact.php Registra la adición de un nuevo usuario a la lista de contactos.
Comunicación con WS
add_discussion.php Registra la adición de nueva discusión para el foro de un curso.
Comunicación con WS
add_postto_discussion.php Registra la adición de un nuevo post a la discusión de un foro.
Comunicación con WS
block_unblock_contact.php Registra la acción de bloquear o desbloquear un usuario en la red social.
Comunicación con WS
clear_readed_messages.php Registra la lectura de los mensajes recibidos de un usuario.
Comunicación con WS
delete_contact.php Registra la eliminación de un contacto.
Comunicación con WS
delete_forum_discussion.php Registra la eliminación de una discusión en el foro de un curso.
Comunicación con WS
delete_mod_from_course_section.php
Registra la eliminación de un modulo de la sección de un curso.
Comunicación con WS
delete_post_ofdiscussion.php Registra la eliminación de un post en la discusión de un foro.
Comunicación con WS
edit_user_profile.php Registra cambios en los datos Comunicación con WS
151
del usuario. forums_data.php Obtiene todos los datos que se
presentarán como contenido del foro.
Comunicación con WS
message_send_contacts.php Registra un nuevo mensaje a un usuario de la lista de contactos.
Comunicación con WS
Message_send_onlineusers.php Registra un nuevo mensaje a un usuario de la lista de usuarios conectados.
Comunicación con WS
Message_send_partic.php Registra un nuevo mensaje a un usuario de la lista de participantes de un curso.
Comunicación con WS
Messagestoread.php Vista de los mensajes recibidos del usuario.
Presentación en Widget
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 assignment en la sección de un curso.
Comunicación con WS
New_forum.php Registra un nuevo modulo tipo forum en la sección de un curso.
Comunicación con WS
New_quiz.php Registra un nuevo modulo tipo quiz en la sección de un curso.
Comunicación con WS
New_resource.php Registra un nuevo modulo tipo resource en la sección de un curso.
Comunicación con WS
Participants_in_course_list.php Vista de los participantes de un curso
Presentación en Widget
Present_forums.php Vista de los foros del curso Presentación en Widget Quizzes_incourse.php Vista de los cuestionarios
abiertos en un curso Presentación en Widget
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
152
lenguaje actual de moodle, para poder consumirlos desde javascript.
menú.php Contiene los módulos disponibles a agregarse como widgets en la interfaz.
153
ANEXO 7: ESPECIFICACION
DE CASOS DE PRUEBA
154
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.
155
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
156
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.
1.3.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.3.3 Entrada
- Nombre de usuario
- Contraseña
1.3.4 Resultado esperado
Ingreso al sistema correcto.
1.3.5 Evaluación de la prueba
Prueba satisfactoria
157
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
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.
2.2 Nombre del caso de prueba I
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.
2.2.2 Condiciones de ejecución
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.
2.2.4 Resultado esperado
La lista de cursos del usuario en una pantalla dentro del navegador web.
2.2.5 Evaluación de la prueba
Prueba satisfactoria
158
2.3 Nombre del caso de prueba II
Presentación de cada uno de los cursos clasificados de acuerdo a la categoría a la que
pertenecen.
2.3.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, clasificados en la
categoría de cursos correspondiente.
2.3.2 Condiciones de ejecución
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
- Ingresar a la presentación dinámica del sistema.
2.3.4 Resultado esperado
La lista de cursos del usuario en una pantalla dentro del navegador web,
clasificados de acuerdo a su categoría.
2.3.5 Evaluación de la prueba
Prueba satisfactoria
159
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
Una vez que el usuario se ha identificado, se deberán presentar una pantalla
dentro del navegador, presentando el mensaje de que no está enrolado en
ningún curso actualmente.
2.4.2 Condiciones de ejecución
Que el usuario no esté enrolado en ninguno de los cursos.
2.4.3 Entrada
- Ingresar a la presentación dinámica del sistema.
2.4.4 Resultado esperado
Una pantalla dentro del navegador web, indicando que el usuario no tiene
cursos actualmente.
2.4.5 Evaluación de la prueba
Prueba satisfactoria
160
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
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.
3.2 Nombre del caso de prueba I
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.
3.2.2 Condiciones de ejecución
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.
3.2.4 Resultado esperado
La lista de los participantes del curso seleccionado.
3.2.5 Evaluación de la prueba
Prueba satisfactoria
161
3.3 Nombre del caso de prueba II
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
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, en esta lista se deberá visualizar por separados los usuarios con
rol de profesor, y los usuarios con rol de estudiante.
3.3.2 Condiciones de ejecución
Que el curso tenga usuarios con rol de profesor y/o de estudiante.
3.3.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
3.3.4 Resultado esperado
La lista de los participantes del curso seleccionado, clasificados según el rol que
tienen en el curso.
3.3.5 Evaluación de la prueba
Prueba satisfactoria
162
3.4 Nombre del caso de prueba III
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.
3.4.2 Condiciones de ejecución
Que el curso tenga no tenga participantes, sea con rol de profesores, o de
estudiantes.
3.4.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
3.4.4 Resultado esperado
Mensaje indicando que no existe dicho tipo de participantes en el curso.
3.4.5 Evaluación de la prueba
Prueba satisfactoria
163
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.
4.2 Nombre del caso de prueba I
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
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 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.
4.2.2 Condiciones de ejecución
Que el curso tenga anuncios hechos por el profesor.
4.2.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
4.2.4 Resultado esperado
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.
4.2.5 Evaluación de la prueba
Prueba satisfactoria
164
4.3 Nombre del caso de prueba II
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.
4.3.2 Condiciones de ejecución
Que el curso no tenga anuncios.
4.3.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
4.3.4 Resultado esperado
Presentación de mensaje indicando que no existen anuncios en el curso
seleccionado.
4.3.5 Evaluación de la prueba
Prueba satisfactoria
165
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.
5.2 Nombre del caso de prueba I
Presentar la opción de agregar anuncio cuando el usuario tiene rol de profesor en el
curso.
5.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 anuncios que ha realizado el
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.
5.2.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor en el curso seleccionado.
5.2.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
- Mensaje del nuevo anuncio
5.2.4 Resultado esperado
Presentación del nuevo anuncio agregado en el curso.
5.2.5 Evaluación de la prueba
Prueba satisfactoria
166
5.3 Nombre del caso de prueba II
Posibilidad de editar los anuncios de un curso, solo cuando el usuario tiene rol de
profesor en el curso.
5.3.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 anuncios que ha realizado el
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.
5.3.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor en el curso seleccionado.
Que exista al menos un anuncio para que pueda se editado
5.3.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
- Nuevo mensaje en el anuncio que ya existía.
5.3.4 Resultado esperado
Presentación del anuncio con el nuevo mensaje.
5.3.5 Evaluación de la prueba
Prueba satisfactoria
167
5.4 Nombre del caso de prueba III
No permitir editar, ni agregar nuevos anuncios cuando el usuario no tenga rol de
profesor en el curso seleccionado.
5.4.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 anuncios que ha realizado el
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.
5.4.2 Condiciones de ejecución
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
- Seleccionar un curso de la lista de cursos del usuario.
5.4.4 Resultado esperado
Presentación de los anuncios, sin la opción de editar, ni agregar uno nuevo.
5.4.5 Evaluación de la prueba
Prueba satisfactoria
168
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.
6.2 Nombre del caso de prueba I
Presentar la opción de agregar tarea cuando el usuario tiene rol de profesor en el
curso.
6.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 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.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor en el curso seleccionado.
6.2.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
- Llenar los campos del formulario para la nueva tarea.
6.2.4 Resultado esperado
Presentación del la nueva tarea agregada en el curso.
6.2.5 Evaluación de la prueba
Prueba satisfactoria
169
6.3 Nombre del caso de prueba II
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.
6.3.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor en el curso seleccionado.
Datos requeridos vacios.
6.3.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
- Dejar en blando uno o varios de los datos requeridos del formulario
para la nueva tarea.
6.3.4 Resultado esperado
Presentación del mensaje indicando que no se ha agregado la tarea debido a
que los datos requeridos están vacíos.
6.3.5 Evaluación de la prueba
Prueba satisfactoria
170
6.4 Nombre del caso de prueba III
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.
6.4.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor en el curso seleccionado.
Que existan archivos subidos por los estudiantes en la tarea seleccionada.
6.4.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
- Seleccionar alguna de las tareas del curso.
6.4.4 Resultado esperado
Presentación de los archivos que los estudiantes han subido para esa tarea.
6.4.5 Evaluación de la prueba
Prueba satisfactoria
171
6.5 Nombre del caso de prueba III
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.
6.5.2 Condiciones de ejecución
Que el usuario identificado tenga rol de estudiante en el curso seleccionado.
6.5.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
- Seleccionar alguna de las tareas del curso sin permitirle ver los archivos
que los estudiantes han subido en esa tarea.
6.5.4 Resultado esperado
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.
6.5.5 Evaluación de la prueba
Prueba satisfactoria
172
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
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.
7.2 Nombre del caso de prueba I
Ver la lista de foros disponibles en el curso.
7.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 foros que hay en el curso, esta
lista será mostrada tanto a usuarios con rol de profesor, como a usuarios con
rol de estudiante.
7.2.2 Condiciones de ejecución
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
- Seleccionar un curso de la lista de cursos del usuario.
7.2.4 Resultado esperado
Presentación del la lista de foros disponibles en el curso.
7.2.5 Evaluación de la prueba
Prueba satisfactoria
173
7.3 Nombre del caso de prueba II
Ver la lista de discusiones de cada foro del curso.
7.3.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 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.
7.3.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor o estudiante en el curso
seleccionado.
Que existan foros disponibles para ese curso seleccionado, y que el foro cuente
con discusiones.
7.3.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
- Seleccionar uno de los foros del curso
7.3.4 Resultado esperado
Presentación del la lista de discusiones del foro seleccionado en el curso.
7.3.5 Evaluación de la prueba
Prueba satisfactoria
174
7.4 Nombre del caso de prueba III
Agregar posts a los temas de discusión del foro.
7.4.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 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.
7.4.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor o estudiante en el curso
seleccionado.
Que existan discusiones para el foro seleccionado.
7.4.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
- Seleccionar uno de los foros del curso
- Seleccionar la opción comentar de una discusión del foro.
7.4.4 Resultado esperado
Agregación del nuevo comentario a la discusión del foro.
7.4.5 Evaluación de la prueba
Prueba satisfactoria
175
7.5 Nombre del caso de prueba III
Agregar nuevo foro en el curso.
7.5.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 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.
7.5.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor curso seleccionado.
7.5.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
- Llenar los datos del formulario de nuevo foro
7.5.4 Resultado esperado
Agregación del nuevo foro al curso.
7.5.5 Evaluación de la prueba
Prueba satisfactoria
176
7.6 Nombre del caso de prueba IV
Agregar nueva discusión en el foro del curso.
7.6.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 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.
7.6.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor curso seleccionado.
7.6.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
- Llenar seleccionar algún foro del curso.
- Llenar los datos del formulario de nueva discusión.
7.6.4 Resultado esperado
Agregación de una nueva discusión en el foro del curso.
7.6.5 Evaluación de la prueba
Prueba satisfactoria
177
7.7 Nombre del caso de prueba IV
Mensaje indicando que no existen foros disponibles en el curso.
7.7.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 el mensaje de que no hay foros disponibles
para ese curso.
7.7.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor o estudiante en el curso
seleccionado.
Que no existan foros relacionados con el curso seleccionado.
7.7.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
7.7.4 Resultado esperado
Mensaje indicando que no existen foros en el curso seleccionado.
7.7.5 Evaluación de la prueba
Prueba satisfactoria
178
8. Historia 8:
Presentar una lista de los recursos disponibles en un curso.
8.1 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.
8.2 Nombre del caso de prueba I
Ver la lista de recursos disponibles en el curso.
8.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 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.
8.2.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor o estudiante en el curso
seleccionado.
Que existan recursos disponibles para ese curso seleccionado.
8.2.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
8.2.4 Resultado esperado
Presentación del la lista de recursos disponibles en el curso.
8.2.5 Evaluación de la prueba
Prueba satisfactoria
179
8.3 Nombre del caso de prueba II
Mensaje indicando que no existen recursos para el curso seleccionado.
8.3.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 un mensaje indicando que no existen
recursos para el curso seleccionado.
8.3.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor o estudiante en el curso
seleccionado.
Que no existan recursos disponibles para ese curso seleccionado.
8.3.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
8.3.4 Resultado esperado
Presentación mensaje indicando que no existen recursos para el curso
seleccionado.
8.3.5 Evaluación de la prueba
Prueba satisfactoria
180
9. Historia 9:
Presentar una lista de cuestionarios disponibles en el curso.
9.1 Descripción
Presentar a los usuarios los cuestionarios agregados en cada uno de los cursos en los
cuales participa.
9.2 Nombre del caso de prueba I
Presentar la lista de cuestionarios disponibles en el curso.
9.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 cuestionarios que hay en el
curso, esta lista será mostrada tanto a usuarios con rol de profesor, como a
usuarios con rol de estudiante.
9.2.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor o estudiante en el curso
seleccionado.
Que existan cuestionarios disponibles para ese curso seleccionado.
9.2.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
9.2.4 Resultado esperado
Presentación del la lista de cuestionarios disponibles en el curso.
9.2.5 Evaluación de la prueba
Prueba satisfactoria
181
9.3 Nombre del caso de prueba II
Mensaje indicando que no existen cuestionarios para el curso seleccionado.
9.3.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 un mensaje indicando que no existen
cuestionarios para el curso seleccionado.
9.3.2 Condiciones de ejecución
Que el usuario identificado tenga rol de profesor o estudiante en el curso
seleccionado.
Que no existan cuestionarios disponibles para ese curso seleccionado.
9.3.3 Entrada
- Seleccionar un curso de la lista de cursos del usuario.
9.3.4 Resultado esperado
Presentación mensaje indicando que no existen cuestionarios para el curso
seleccionado.
9.3.5 Evaluación de la prueba
Prueba satisfactoria
182
10. Historia 10:
Presentar una lista de los usuarios que se encuentran conectados en el sistema.
10.1 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.
10.2 Nombre del caso de prueba I
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.
10.2.2 Condiciones de ejecución
Que existan otros usuarios conectados al sistema en ese momento.
10.2.3 Entrada
- Ingreso al sistema
10.2.4 Resultado esperado
Presentación del la lista de usuarios conectados al sistema.
10.2.5 Evaluación de la prueba
Prueba satisfactoria
183
10.3 Nombre del caso de prueba II
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.
10.3.2 Condiciones de ejecución
Que no existan otros usuarios conectados al sistema en ese momento.
10.3.3 Entrada
- Ingreso al sistema.
10.3.4 Resultado esperado
Presentación mensaje indicando que no existen usuarios conectados al sistema
en ese momento.
10.3.5 Evaluación de la prueba
Prueba satisfactoria
184
11. Historia 11:
Presentar una lista de los contactos del usuario.
11.1 Descripción
Presentar a cada usuario una lista con la información de otros usuarios, que están en la
lista de sus contactos.
11.2 Nombre del caso de prueba I
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.
11.2.2 Condiciones de ejecución
Que el usuario tenga una lista de contactos de otros usuarios del sistema.
11.2.3 Entrada
- Ingreso al sistema
11.2.4 Resultado esperado
Presentación del la lista de contactos del usuario identificado.
11.2.5 Evaluación de la prueba
Prueba satisfactoria
185
11.3 Nombre del caso de prueba II
Mensaje indicando que la lista de contactos del usuario identificado esta vacía.
11.3.1 Descripción
Se deberá presentar una pantalla dentro del navegador con un mensaje
indicando que no tiene contactos en su lista.
11.3.2 Condiciones de ejecución
Que no tenga agregado ningún contacto en su lista de contactos.
11.3.3 Entrada
- Ingreso al sistema.
11.3.4 Resultado esperado
Presentación mensaje indicando que la lista de contactos está vacía.
11.3.5 Evaluación de la prueba
Prueba satisfactoria
186
12. Historia 12:
Permitir a hacer una búsqueda de los usuarios del sistema.
12.1 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.
12.2 Nombre del caso de prueba I
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.
12.2.2 Condiciones de ejecución
Que existan coincidencias con el usuario buscado.
12.2.3 Entrada
- Ingreso al sistema
- Ingreso de nombre o apellido del usuario que se está buscando.
12.2.4 Resultado esperado
Presentación del la lista de coincidencias con el usuario buscado.
12.2.5 Evaluación de la prueba
Prueba satisfactoria
187
12.3 Nombre del caso de prueba II
Mensaje indicando que la no se han encontrado resultados en la búsqueda realizada.
12.3.1 Descripción
Se deberá presentar una pantalla dentro del navegador con un mensaje
indicando que no hay coincidencias para la búsqueda realizada.
12.3.2 Condiciones de ejecución
Que no haya coincidencias con el usuario buscado.
12.3.3 Entrada
- Ingreso al sistema.
- Ingreso de nombre o apellido del usuario que se está buscando.
12.3.4 Resultado esperado
Presentación mensaje indicando que no se han encontrado coincidencias con la
búsqueda.
12.3.5 Evaluación de la prueba
Prueba satisfactoria
188
13. Historia 13:
Presentar los mensajes recibidos de un usuario.
13.1 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.
13.2 Nombre del caso de prueba I
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.
13.2.2 Condiciones de ejecución
Que existan mensajes pendientes por leer del usuario identificado.
13.2.3 Entrada
- Ingreso al sistema
13.2.4 Resultado esperado
Presentación del la lista mensajes pendientes por leer del usuario identificado.
13.2.5 Evaluación de la prueba
Prueba satisfactoria
189
13.3 Nombre del caso de prueba II
Mensaje indicando que la no se han encontrado mensajes pendientes para el usuario
identificado.
13.3.1 Descripción
Se deberá presentar una pantalla dentro del navegador con un mensaje
indicando que no hay mensajes pendientes.
13.3.2 Condiciones de ejecución
Que no existan mensajes pendientes por leer del usuario identificado.
13.3.3 Entrada
- Ingreso al sistema.
13.3.4 Resultado esperado
Presentación mensaje indicando que no se han encontrado mensajes
pendientes.
13.3.5 Evaluación de la prueba
Prueba satisfactoria
190
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
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.
14.2 Nombre del caso de prueba I
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.
14.2.2 Condiciones de ejecución
Que existan usuarios en su lista de contactos.
14.2.3 Entrada
- Ingreso al sistema
- Selección del contacto de su lista de contactos.
- Contenido del mensaje.
14.2.4 Resultado esperado
Mensaje de confirmación de que se ha enviado el mensaje, o alerta de error.
14.2.5 Evaluación de la prueba
Prueba satisfactoria
191
14.3 Nombre del caso de prueba II
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.
14.3.2 Condiciones de ejecución
Que existan usuarios en la lista de participantes del curso seleccionado.
14.3.3 Entrada
- Ingreso al sistema
- Ingreso a un curso
- Selección del usuario de la lista de participantes del curso.
- Contenido del mensaje.
14.3.4 Resultado esperado
Mensaje de confirmación de que se ha enviado el mensaje, o alerta de error.
14.3.5 Evaluación de la prueba
Prueba satisfactoria
192
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.
15.2 Nombre del caso de prueba I
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.
15.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
15.2.3 Entrada
- Ingreso al sistema
15.2.4 Resultado esperado
Ventanas en el navegador que se puedan arrastrar hacia distintos bloques.
15.2.5 Evaluación de la prueba
Prueba satisfactoria
193
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.
16.2 Nombre del caso de prueba I
Verificar adaptación de las pantallas pequeñas dentro de los bloques.
16.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, donde cada bloque puede contener
una o varias pantallas con distinta información.
16.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Que exista más de una ventana pequeña dentro del navegador, para ajustarla a
los distintos bloques.
16.2.3 Entrada
- Ingreso al sistema
- Movimiento de las pantallas pequeñas hacia otro bloque.
16.2.4 Resultado esperado
Agregar una o varias ventanas a los distintos bloques, permitiendo la
visualización de todas las ventanas en el bloque.
16.2.5 Evaluación de la prueba
Prueba satisfactoria
194
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.
17.2 Nombre del caso de prueba I
Capacidad para minimizar, maximizar, actualizar y cerrar el contenido de las pantallas
pequeñas dentro del navegador.
17.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 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.
17.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Que exista una o varias ventanas pequeñas dentro del navegador.
17.2.3 Entrada
- Ingreso al sistema
- Seleccionar la opción minimizar/maximizar/actualizar/cerrar desde un
icono en la pantalla pequeña.
17.2.4 Resultado esperado
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.
195
Cerrar: Ocultar la pantalla pequeña de la lista de pantallas dentro del
navegador.
17.2.5 Evaluación de la prueba
Prueba satisfactoria
196
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.
18.2 Nombre del caso de prueba I
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
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 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.
18.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
“WノWIIキラミ;ヴ ┌ミ キIラミラ キSWミデキaキI;Sラ Iラマラ さMWミ┎ ヮ;ヴ; ;ェヴWェ;ヴ マ=ゲ ┗Wミデ;ミ;ゲ ヮWケ┌Wモ;ゲざ.
18.2.3 Entrada
- Ingreso al sistema
- Seleccionar さMWミ┎ ヮ;ヴ; ;ェヴWェ;ヴ マ=ゲ ┗Wミデ;ミ;ゲ ヮWケ┌Wモ;ゲざ.
18.2.4 Resultado esperado
Aparición de una ventana con una lista de las ventanas pequeñas que se
pueden agregar en la ventana principal del navegador.
18.2.5 Evaluación de la prueba
Prueba satisfactoria
197
18.3 Nombre del caso de prueba I
Agregar nueva ventana pequeña a la ventana principal del navegador.
18.3.1 Descripción
Cuando se haya seleccionadラ Wノ さMWミ┎ ヮ;ヴ; ;ェヴWェ;ヴ マ=ゲ ┗Wミデ;ミ;ゲ ヮWケ┌Wモ;ゲざが 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.
18.3.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Haber abierto el menú con la lista de las pantallas pequeñas disponibles.
18.3.3 Entrada
- Ingreso al sistema
- “WノWIIキラミ;ヴ さMWミ┎ ヮ;ヴ; ;ェヴWェ;ヴ マ=ゲ ┗Wミデ;ミ;ゲ ヮWケ┌Wモ;ゲざく - Seleccionar una de las pantallas disponibles para agregase mostradas en
la lista presentada por el menú.
18.3.4 Resultado esperado
Aparición de la pantalla pequeña en la ventana principal del navegador.
18.3.5 Evaluación de la prueba
Prueba satisfactoria
198
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.
19.2 Nombre del caso de prueba I
Presentar la información de Moodle obtenida mediante servicios web en las pantallas
pequeñas dentro del navegador.
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.
19.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Tener disponibles una o varias de las ventanas pequeñas dentro del navegador.
19.2.3 Entrada
- Ingreso al sistema
19.2.4 Resultado esperado
Presentación en las ventanas pequeñas dentro del navegador, todas las
interacciones necesarias con moodle mediante servicios web.
19.2.5 Evaluación de la prueba
Prueba satisfactoria
199
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
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.
20.2 Nombre del caso de prueba I
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.
20.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Tener disponible la pantalla pequeña donde podrá realizar el post.
20.2.3 Entrada
- Ingreso al sistema
- Contenido del post.
20.2.4 Resultado esperado
Agregación del nuevo post en una lista de post realizados.
20.2.5 Evaluación de la prueba
Prueba satisfactoria
200
20.3 Nombre del caso de prueba II
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.
20.3.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Tener disponible la pantalla pequeña donde podrá realizar el post.
20.3.3 Entrada
- Ingreso al sistema
- Contenido vacio del post.
20.3.4 Resultado esperado
Alerta indicando que el post no puede estar vacío.
20.3.5 Evaluación de la prueba
Prueba satisfactoria
201
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
Presentar al usuario todos los posts realizados por sus contactos, y los suyos propios
dentro de la interfaz dinámica.
21.2 Nombre del caso de prueba I
Listado de post realizados por el usuario identificado.
21.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 la
lista de posts que ha realizado el usuario identificado actualmente.
21.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
21.2.3 Entrada
- Ingreso al sistema
21.2.4 Resultado esperado
Una lista dentro de una ventana pequeña en el navegador, con todos los posts
que ha realizado el usuario identificado.
21.2.5 Evaluación de la prueba
Prueba satisfactoria
202
21.3 Nombre del caso de prueba II
Listado de post realizados por los contactos del usuario identificado.
21.3.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 la
lista de posts que han realizado los contactos del usuario identificado.
21.3.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
21.3.3 Entrada
- Ingreso al sistema
21.3.4 Resultado esperado
Una lista dentro de una ventana pequeña en el navegador, con todos los posts
que han realizado los contactos del usuario identificado.
21.3.5 Evaluación de la prueba
Prueba satisfactoria
203
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
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.
22.2 Nombre del caso de prueba I
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.
22.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Tener disponible los posts realizados por el propio usuario, o por sus contactos.
22.2.3 Entrada
- Ingreso al sistema
- Selección del post a comentar
- Contenido del comentario
22.2.4 Resultado esperado
Agregación del comentario realizado al correspondiente post.
22.2.5 Evaluación de la prueba
Prueba satisfactoria
204
22.3 Nombre del caso de prueba II
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.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Tener disponible los posts realizados por el propio usuario, o por sus contactos.
22.3.3 Entrada
- Ingreso al sistema
- Selección del post a comentar
- Contenido vació del comentario
22.3.4 Resultado esperado
Alerta indicando que el comentario no puede estar vacío.
22.3.5 Evaluación de la prueba
Prueba satisfactoria
205
23. Historia 23:
Permitir eliminar sea posts o comentarios que sean de propiedad del usuario
identificado.
23.1 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.
23.2 Nombre del caso de prueba I
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.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Tener disponible los posts realizados por el propio usuario, o por sus contactos.
23.2.3 Entrada
- Ingreso al sistema
- Usuario identificado como dueño del post
- “WノWIIキラミ;ヴ ノ; ラヮIキルミ さEノキマキミ;ヴざ ヮラゲデ
23.2.4 Resultado esperado
Eliminar el post junto con todos sus comentarios, y desaparecerlo de la lista.
23.2.5 Evaluación de la prueba
Prueba satisfactoria
206
23.3 Nombre del caso de prueba II
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.
23.3.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Tener disponible los comentarios de los posts realizados por el usuario.
23.3.3 Entrada
- Ingreso al sistema
- Usuario identificado como dueño del comentario
- “WノWIIキラミ;ヴ ノ; ラヮIキルミ さEノキマキミ;ヴざ comentario
23.3.4 Resultado esperado
Eliminar el comentario, y desaparecerlo de la lista de comentarios del post al
que pertenece.
23.3.5 Evaluación de la prueba
Prueba satisfactoria
207
24. Historia 24:
Permitir ingresar al muro de los contactos de la red del usuario.
24.1 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.
24.2 Nombre del caso de prueba I
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.
24.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Tener disponible los posts realizados por el contactacto, al cual quiere visitar su
muro.
24.2.3 Entrada
- Ingreso al sistema
- Seleccionar usuario al cual se va a realizar una visita a su muro.
24.2.4 Resultado esperado
Presentación de todos los posts y comentarios relacionados con el contacto al
que ha visitado.
24.2.5 Evaluación de la prueba
Prueba satisfactoria
208
25. Historia 25:
Presentar ノ; ラヮIキルミ さMW ェ┌ゲデ;ざ ヮ;ヴ; ノラゲ ヮラゲデゲ ┞ IラマWミデ;ヴキラゲが ;ノ ┌ゲ;ヴ Wゲデ; ラヮIキルミ Wノ 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ラSラゲ ノラゲ ヮラゲデゲ ┞ IラマWミデ;ヴキラゲ SWHWミ デWミWヴ ノ; ラヮIキルミ さMW ェ┌ゲデ;ざが SW Wゲ; マ;ミWヴ; 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.
25.2 Nombre del caso de prueba I
D;ヴ ┌ミ さMW ェ┌ゲデ;ざ ; I┌;ノケ┌キWヴ; SW ノラゲ ヮラゲデゲ ラ IラマWミデ;ヴキラゲ SW ノラゲ Iラミデ;Iデラゲ.
25.2.1 Descripción
El usuario debe tener la posibilidad de seleccionar cualquiera de los posts o
IラマWミデ;ヴキラゲ Iラマラ a;┗ラヴキデラゲ エ;IキWミSラ IノキI Wミ ノ; ラヮIキルミ さMW ェ┌ゲデ;ざく
25.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Tener disponible los posts y comentarios realizados por sus contactos.
25.2.3 Entrada
- Ingreso al sistema
- Seleccionar ノ; ラヮIキルミ さMW ェ┌ゲデ;ざ SWノ ヮラゲデ ラ IラマWミデ;ヴキラ.
25.2.4 Resultado esperado
Presentar mensaje que le ha gustado ese comentario.
25.2.5 Evaluación de la prueba
Prueba satisfactoria
209
25.3 Nombre del caso de prueba II
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.
25.3.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Q┌W ;ノェ┌キWミ エ;┞; エWIエラ ┌ミ さMW ェ┌ゲデ;ざ ; ;ノェ┌ミ; SW ゲ┌ゲ ヮ┌HノキI;IキラミWゲ.
25.3.3 Entrada
- Ingreso al sistema
- Seleccionar el menú de notificaciones.
25.3.4 Resultado esperado
Presentar ミラデキaキI;IキラミWゲ Iラミ Wノ ミラマHヴW SW ケ┌キWミ エ; エWIエラ ┌ミ さMW ェ┌ゲデ;ざ Wミ alguna de sus publicaciones.
25.3.5 Evaluación de la prueba
Prueba satisfactoria
210
26. Historia 26:
Presentar una lista de notificaciones con las actividades que se ha realizado
relacionadas con su red social.
26.1 Descripción
Presentar al usuario identificado una lista con las notificaciones por movimientos en su
red social, por ejemplo, alguien aceptó una invitación suya de amistad, o alguien
comentó un post suyo.
26.2 Nombre del caso de prueba I
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.
26.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Que se haya realizado alguna actividad en su red social.
26.2.3 Entrada
- Ingreso al sistema
- Selección del menú de notificaciones
26.2.4 Resultado esperado
Presentar un menú con las notificaciones que ha recibió el usuario debido a
alguna acción realizada en su red.
26.2.5 Evaluación de la prueba
Prueba satisfactoria
211
27. Historia 27:
Presentar de los usuarios bloqueados.
27.1 Descripción
Presentar al usuario identificado una lista con los usuarios que han sido bloqueados
por él mismo.
27.2 Nombre del caso de prueba I
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.
27.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Tener al menos un usuario bloqueado.
27.2.3 Entrada
- Ingreso al sistema
- Selección del menú de usuarios bloqueados
27.2.4 Resultado esperado
Presentación de un menú desplegable con todos los usuarios bloqueados.
27.2.5 Evaluación de la prueba
Prueba satisfactoria
212
27.3 Nombre del caso de prueba II
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.
27.3.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Tener al menos un usuario bloqueado.
27.3.3 Entrada
- Ingreso al sistema
- Selección del menú de usuarios bloqueados
27.3.4 Resultado esperado
Desbloqueo del usuario al elegir la opción desbloquear, y desaparecerlo de la
lista.
27.3.5 Evaluación de la prueba
Prueba satisfactoria
213
28. Historia 28:
Permitirle al usuario enviar invitaciones de amistad a otros usuarios del sistema, y
permitirle bloquearlos y eliminarlos.
28.1 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.
28.2 Nombre del caso de prueba I
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.
28.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Que existan otros usuarios en el sistema.
Obtener resultados de una búsqueda de usuarios.
28.2.3 Entrada
- Ingreso al sistema
- Seleccion;ヴ ノ; ラヮIキルミ さWミ┗キ;ヴ キミ┗キデ;Iキルミざ エ;Iキ; ラデヴラ ┌ゲ┌;rio.
28.2.4 Resultado esperado
Envió de la invitación de amistad, para agregarlo al usuario como contacto.
28.2.5 Evaluación de la prueba
Prueba satisfactoria
214
28.3 Nombre del caso de prueba II
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.
28.3.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Que el usuario encontrado en la búsqueda sea un contacto del usuario
identificado.
28.3.3 Entrada
- Ingreso al sistema
- “WノWIIキラミ;ヴ ノ; ラヮIキルミ さBノラケ┌W;ヴ Contactoざく
28.3.4 Resultado esperado
Bloqueo del usuario que estaba como contacto.
28.3.5 Evaluación de la prueba
Prueba satisfactoria
215
28.4 Nombre del caso de prueba II
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.
28.4.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Que el usuario encontrado en la búsqueda sea un contacto del usuario
identificado.
28.4.3 Entrada
- Ingreso al sistema
- “WノWIIキラミ;ヴ ノ; ラヮIキルミ さEliminar Contactoざく
28.4.4 Resultado esperado
Eliminar al usuario de la lista de contactos.
28.4.5 Evaluación de la prueba
Prueba satisfactoria
216
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
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.
29.2 Nombre del caso de prueba I
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.
29.2.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Haber ingresado a un curso.
Que existan posts y comentarios en el curso que se ha ingresado.
29.2.3 Entrada
- Ingreso al sistema
- Seleccionar un curso
29.2.4 Resultado esperado
Presentación de la lista de posts y comentarios hechos en el curso.
29.2.5 Evaluación de la prueba
Prueba satisfactoria
217
29.3 Nombre del caso de prueba II
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.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Haber ingresado a un curso.
29.3.3 Entrada
- Ingreso al sistema
- Seleccionar un curso
- Contenido de anuncio
29.3.4 Resultado esperado
Agregar y presentar el nuevo post/comentario dentro de la lista de posts y
comentarios del curso.
29.3.5 Evaluación de la prueba
Prueba satisfactoria
218
29.4 Nombre del caso de prueba II
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.2 Condiciones de ejecución
Haber ingresado al sistema en la presentación dinámica.
Haber ingresado a un curso.
29.4.3 Entrada
- Ingreso al sistema
- Seleccionar un curso
- “WノWIIキラミ;ヴ ノ; ラヮIキルミ さEノキマキミ;ヴざ ヮラゲデっIラマWミデ;ヴキラ
29.4.4 Resultado esperado
Eliminar y desaparecer el post/comentario de la lista de posts y comentarios del
curso.
29.4.5 Evaluación de la prueba
Prueba satisfactoria
219
30. Historia 30:
Adaptación del desarrollo a Moodle 2.0.x.
30.1 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.
30.2 Nombre del caso de prueba I
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.
30.2.2 Condiciones de ejecución
Ingresar al sistema de Moodle, versión 2.0.x.
30.2.3 Entrada
- Ingreso al sistema
30.2.4 Resultado esperado
Todas las funciones desarrolladas para Moodle 1.9.x funcionando
correctamente en Moodle 2.0.x.
30.2.5 Evaluación de la prueba
Prueba satisfactoria
220
ANEXO 8: RESULTADO DE
PRUEBAS UNITARIAS
221
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
ヴW;ノキ┣;ヴ ノ; ヮヴ┌WH;が Wゲ WゲデW I;ゲラ さ“OAP RWゲヮラミsWざ ヮ;ヴ; ┗WヴキaキI;ヴ Wノ Wゲデ;Sラ SW ノ; 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]
222
Una vez seleccionada la función a probar, y la aserción, entonces en el panel derecho
ゲW ゲラノキIキデ; ノラゲ さS;デラゲ SW Wミデヴ;S;ざ SW ノ; a┌ミIキルミが SWHWミ ゲWヴ ヮヴラヮラヴIキラミ;Sラゲが ┞ ノ┌Wェラ 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
ノ; ヮヴ┌WH; ヴW;ノキ┣;S; ; ノ; a┌ミIキルミ さノラェキミざく
223
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:
224
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 Errors
Failures Time (s)
Host
moodle_widgets.MoodleWS
63 0 0 64.380
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 TestCase
Success 0.827
225
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 TestCase
Success 0.844
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
226
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
227
ANEXO 9: RESULTADO DE
PRUEBAS UNITARIAS
228
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 usuario por medio de servicios web.
Prueba Satisfactoria Cerrado
Autenticación correcta de un usuario por medio de servicios web
Prueba Satisfactoria Cerrado
Presentación de los cursos en los cuales el usuario identificado cumple un rol, sea de profesor o de estudiante.
Prueba Satisfactoria Cerrado
Presentación de cada uno de los cursos clasificados de acuerdo a la categoría a la que pertenecen.
Prueba Satisfactoria Cerrado
Presentación de mensaje indicando que el usuario no tiene rol como profesor o como estudiante en ninguno de los cursos.
Prueba Satisfactoria Cerrado
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.
Prueba Satisfactoria Cerrado
Presentación de una lista con los participantes del curso clasificados de acuerdo a su rol, sea de profesor o estudiante.
Prueba Satisfactoria Cerrado
Presentación de mensaje indicando que el curso no tiene
Prueba Satisfactoria Cerrado
229
usuarios con rol de profesor y/o estudiante.
Presentación del último de los anuncios del profesor en el curso, permitiendo al usuario navegar además por todos los anteriores.
Prueba Satisfactoria Cerrado
Presentación de mensaje indicando que no hay anuncios en el curso.
Prueba Satisfactoria Cerrado
Presentar la opción de agregar anuncio cuando el usuario tiene rol de profesor en el curso.
Prueba Satisfactoria Cerrado
Posibilidad de editar los anuncios de un curso, solo cuando el usuario tiene rol de profesor en el curso.
Prueba Satisfactoria Cerrado
No permitir editar, ni agregar nuevos anuncios cuando el usuario no tenga rol de profesor en el curso seleccionado.
Prueba Satisfactoria Cerrado
Presentar la opción de agregar tarea cuando el usuario tiene rol de profesor en el curso.
Prueba Satisfactoria Cerrado
Presentar mensaje de error al agregar tarea, cuando no se han enviado los datos requeridos para la nueva tarea.
Prueba Satisfactoria Cerrado
Presentar las los archivos que los estudiantes han subido en las tareas, cuando el usuario tiene rol de profesor.
Prueba Satisfactoria Cerrado
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.
Prueba Satisfactoria Cerrado
230
Ver la lista de foros disponibles en el curso.
Prueba Satisfactoria Cerrado
Ver la lista de discusiones de cada foro del curso.
Prueba Satisfactoria Cerrado
Agregar posts a los temas de discusión del foro.
Prueba Satisfactoria Cerrado
Agregar nuevo foro en el curso.
Prueba Satisfactoria Cerrado
Agregar nueva discusión en el foro del curso.
Prueba Satisfactoria Cerrado
Mensaje indicando que no existen foros disponibles en el curso.
Prueba Satisfactoria Cerrado
Ver la lista de recursos disponibles en el curso.
Prueba Satisfactoria Cerrado
Mensaje indicando que no existen recursos para el curso seleccionado.
Prueba Satisfactoria Cerrado
Presentar la lista de cuestionarios disponibles en el curso.
Prueba Satisfactoria Cerrado
Mensaje indicando que no existen cuestionarios para el curso seleccionado.
Prueba Satisfactoria Cerrado
Presentar la lista de usuarios conectados al sistema.
Prueba Satisfactoria Cerrado
Mensaje indicando que no existen otros usuarios conectados al sistema en ese momento.
Prueba Satisfactoria Cerrado
Presentar la lista de contactos Prueba Satisfactoria Cerrado
231
del usuario identificado.
Mensaje indicando que la lista de contactos del usuario identificado está vacía.
Prueba Satisfactoria Cerrado
Buscar un usuario por su nombre o apellido.
Prueba Satisfactoria Cerrado
Mensaje indicando que la no se han encontrado resultados en la búsqueda realizada
Prueba Satisfactoria Cerrado
Presentar los mensajes recibidos al usuario identificado.
Prueba Satisfactoria Cerrado
Mensaje indicando que la no se han encontrado mensajes pendientes para el usuario identificado.
Prueba Satisfactoria Cerrado
Enviar mensaje privado a cualquiera de sus contactos.
Prueba Satisfactoria Cerrado
Enviar mensaje privado a cualquiera de los participantes de un curso en los que también participa el usuario identificado
Prueba Satisfactoria Cerrado
Verificar pantallas movibles.
Prueba Satisfactoria Cerrado
Verificar adaptación de las pantallas pequeñas dentro de los bloques.
Prueba Satisfactoria Cerrado
Capacidad para minimizar, maximizar, actualizar y cerrar el contenido de las pantallas pequeñas dentro del navegador
Prueba Satisfactoria Cerrado
Presentación de un menú con la lista de pantallas pequeñas disponibles para agregarse en la ventana principal del navegador.
Prueba Satisfactoria Cerrado
Agregar nueva ventana pequeña a la ventana principal del navegador.
Prueba Satisfactoria Cerrado
232
Presentar la información de Moodle obtenida mediante servicios web en las pantallas pequeñas dentro del navegador.
Prueba Satisfactoria Cerrado
Agregar nuevo post.
Prueba Satisfactoria Cerrado
Agregar un post vacio.
Prueba Satisfactoria Cerrado
Listado de post realizados por el usuario identificado.
Prueba Satisfactoria Cerrado
Cerrado Listado de post realizados por los contactos del usuario identificado.
Prueba Satisfactoria Cerrado
Agregar comentarios a los posts propios del usuario y a los de sus contactos.
Prueba Satisfactoria Cerrado
Agregar comentario vacio a los posts propios del usuario y a los de sus contactos.
Prueba Satisfactoria Cerrado
Cerrado Eliminar post.
Prueba Satisfactoria Cerrado
Eliminar comentario.
Prueba Satisfactoria Cerrado
Ingresar al muro de un usuario.
Prueba Satisfactoria Cerrado
D;ヴ ┌ミ さMW ェ┌ゲデ;ざ ; I┌;ノケ┌キWヴ; de los posts o comentarios de los contactos.
Prueba Satisfactoria Cerrado
Presentar notificación de que a un contacto le ha gustado una publicación del usuario identificado.
Prueba Satisfactoria Cerrado
Ver un menú de todas las notificaciones del usuario.
Prueba Satisfactoria Cerrado
Ver un menú de los usuarios bloqueados.
Prueba Satisfactoria Cerrado
Opción desbloquear de la lista Prueba Satisfactoria Cerrado
233
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 comentarios propios para cada curso.
Prueba Satisfactoria Cerrado
Opción de agregar posts y comentarios en red del curso
Prueba Satisfactoria Cerrado
Opción de eliminar posts y comentarios en red del curso
Prueba Satisfactoria Cerrado
Funcionalidades desarrolladas para Moodle 1.9.x adaptadas a Moodle 2.0.x.
Prueba Satisfactoria Cerrado
234
ANEXO 10: MANUAL DE
INSTALACIÓN DEL SISTEMA
235
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');
236
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: аSキ┗ Iノ;ゲゲЭざゲ┌HIラミデWミデ ェ┌Wゲデゲ┌Hざб : 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
237
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';
238
$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: }
239
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ゲWェ┌ヴ;ヴゲW ケ┌W ノ; W┝デWミゲキルミ さヮエヮゲラ;ヮざ WゲデY キミゲデ;ノ;S; Wミ Wノ ゲWヴ┗キSラヴ SW MララSノWく ズ Descomprimmir el archivo さ┘ゲヮヮぱ┌デヮノぱMヱΓく┣キヮざが ┞ Iラヮキ;ヴ デラS; ノ; I;ヴヮWデ; さ┘ゲヮヮざ
dentro del directorio raiz de moodle. ズ Cラヮキ;ヴ Wノ ;ヴIエキ┗ラ さっ┘ゲヮヮっノ;ミェっWミぱ┌デaΒっノラI;ノぱ┘ゲヮヮくヮエヮざ エ;Iキ;
さヴ;ケ┣ぱマララSノWっノ;ミェっWミぱ┌デaΒっざ ズ Cラヮキ;ヴ Wノ ;ヴIエキ┗ラ さっ┘ゲヮヮっノ;ミェっWゲぱ┌デaΒっノラI;ノぱ┘ゲヮヮくヮエヮざ エ;Iキ;
さヴ;ケ┣ぱマララSノWっノ;ミェっWゲぱ┌デaΒっざ ズ ESキデ;ヴ Wノ ;ヴIエキ┗ラ さヴ;ケ┣ぱマララSノWっ;SマキミっゲWデデキミェゲっマキゲIくヮエヮざが ;ェヴWェ;ミSラ ノ; ノケミW;ぎ
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.
240
ズ 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ゲWェ┌ヴ;ヴゲW ケ┌W ノ; W┝デWミゲキルミ さヮエヮゲラ;ヮざ WゲデY キミゲデ;ノ;S; Wミ Wノ ゲWヴ┗キSラヴ SW MララSノWく ズ DWゲIラマヮヴキママキヴ Wノ ;ヴIエキ┗ラ さ┘ゲヮヮぱ┌デヮノぱMヲヰく┣キヮざが ┞ Iラヮキ;ヴ デラS; ノ; I;ヴヮWデ; さ┘ゲヮヮざ
dentro del directorio raiz de moodle. ズ Copiar el contenido del directorio directorio さ┘ゲヮヮっノラI;ノっざ ふケ┌W Wゲ ┌ミ ゲ┌HSキヴWIデラヴキラ
デ;マHキYミ ノノ;マ;Sラ ┘ゲヮヮぶ SWミデヴラ SWぎ さヴ;ケ┣ぱマララSノWっノラI;ノっざ ズ 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ミ Wノ ゲWヴ┗キSラヴ キヴ ; さ┘ゲヮヮっIノキWミデぱ┘ゲヮヮぱ┌デヮノっ┘ゲSノヲヮエヮくヮエヮざ ヮ;ヴ; WテWI┌デ;ヴ Wノ ゲキェ┌キWミデW comando: php ../client_wspp_utplwsdl2php.php http://sumoodle/wspp/wsdl_pp.php
Por ejemplo si se está usando xampp, se puede copiar el directorio: さIノキWミデぱ┘ゲヮヮぱ┌デヮノっ┘ゲSノヲヮエヮくヮエヮざ SWミデヴラ SW ../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 Aノ WテWI┌デ;ヴ WゲデW Iラマ;ミSラが ゲW ェWミWヴ;ヴ=ミ Sラゲ SキヴWIデラヴキラゲが ┌ミラ ノノ;マ;Sラ さIノ;ゲゲWゲざが ┞ ラデヴラ ノノ;マ;Sラ さデWゲデゲざく
ズ Reempla┣;マラゲ Wノ SキヴWIデラヴキラ Iノ;ゲゲWゲ SW さ┘ゲヮヮっIノ;ゲゲWゲざ ┞ SW さ┘ゲヮヮっIノキWミデゲっIノ;ゲゲWゲざく Eノ directorio classes contiene las referencias hacia las funciones de los servicios web.
Aノェ┌ミ;ゲ ┗WIWゲ ゲ┌WノW S;ヴ ヮヴラHノWマ;ゲ ;ノ ェWミWヴ;ヴ ノ; a┌ミIキルミ さI;ゲデTラざ SWミデヴラ SW ノ; Iノ;ゲW さMララSノWW“ざが ゲキ ゲW S; WゲW I;ゲラが H;ゲデ; Iラミ ヴWWマヮノ;┣;ヴ SキIエ; a┌ミIキルミ Iラミ ノ; IラヴヴWIデ;が ケ┌W Wゲ ノ; siguiente: private function castTo($className,$res){
241
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.
ズ DWゲIラマヮヴキマキヴ Wノ ;ヴIエキ┗ラ さI;ヮ;ぱヴゲ;_M19く┣キヮざ ó さI;ヮ;ぱヴゲ;_M20く┣キヮざ (dependiendo de la versión de Moodle), y copiar el directorio さcapa_rsaざ SWゲIラマヮヴキマキSラ con todo su contenido hacia el directorio raíz de moodle.
ズ AェヴWェ;ヴ Wノ ゲIヴキヮデ “QL ケ┌W ゲW WミI┌Wミデヴ; Wミ さっI;ヮ;ぱヴゲ;っSHっざ ; ノ; H;ゲW SW S;デラゲ SW Moodle.
En Moodle 1.9.x
Ɣ Copiar el archivo さっI;ヮ;ぱヴゲ;っノラI;ノっェノWゲラミWっノ;ミェっWミっノラI;ノぱェノWゲラミWくヮエヮざ エ;Iキ; さヴ;ケ┣ぱマララSノWっノ;ミェっWミぱ┌デaΒっざ
Ɣ Cラヮキ;ヴ Wノ ;ヴIエキ┗ラ さっI;ヮ;ぱヴゲ;っノラI;ノっェノWゲラミWっノ;ミェっWゲっノラI;ノぱェノWゲラミWくヮエヮざ エ;Iキ; さヴ;ケ┣ぱマララSノWっノ;ミェっWゲぱ┌デaΒっざ
En Moodle 2.0.x
ズ Cラヮキ;ヴ Wノ SキヴWIデラヴキラ さっI;ヮ;ぱヴゲ;っノラI;ノっェノWゲラミWっざ (con todo su contenido) hacia さヴ;ケ┣ぱマララSノWっノラI;ノっざ
ズ IミェヴWゲ;ヴ ;ノ ゲキデキラ SW ;Sマキミキゲデヴ;Iキルミが SキヴキェキヴゲW ; さ“キデW ;Sマキミキゲデヴ;デキラミっL;ミェ┌;ェWっL;ミェ┌;ェW I┌ゲデラマキ┣;デキラミざ
ズ Elegir un lenguaje para comprobar las cadenas ズ CノキI Wミ Wノ Hラデルミ さCエWIニ ラ┌デ ゲデヴキミミェゲ キミデラ デヴ;ミゲノ;デラヴざ
242
ズ Eミ ノ; ノキゲデ; SW I;SWミ;ゲが ;ゲWェ┌ヴ;ヴゲW ケ┌W ;ヮ;ヴW┣I; さノラI;ノぱェノWゲラミWくヮエヮざが ゲWノWIIキラミ;ヴノ; ┞ ヮヴWゲキラミ;ヴ Wノ Hラデルミ さゲエラ┘ ゲデヴキミェゲざが Iラミ Wゲデラ ゲW ;Iデ┌;ノキ┣; ノ; I;SWミ; SWノ ノWミェ┌;テW SWノ 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
243
ANEXO 11: MANUAL DE USUARIO DEL SISTEMA
244
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ざが ノ┌Wェラ S;マラゲ IノキI ゲラHヴW Wノ Hラデルミ さEミデヴ;ヴざが tal como se muestra en la siguiente imagen
1 MOODLE; [en linea] <http://moodle.org/>
Ilustración 1 Formulario de ingreso al sistema
245
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.
246
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:
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.
Ilustración 3 Menu de Widgets
247
Ilustración 4 Pantalla Amigos
En esta pantalla se presentan los siguientes widgets:
- 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 ┘キSェWデ さC┌ヴゲラゲさ presentado en la pantalla inicial.
Al dar clic sobre alguno de los cursos del usuario desde el ┘キSェWデ さC┌ヴゲラゲざが ゲWヴWマラゲ ヴWSキヴキェキSラゲ ;┌デラマ=デキI;マWミデW ; ノ; ヮWゲデ;モ; さMキ C┌ヴゲラざが Wミ WゲW キミゲデ;ミデW Wノ ミラマHヴW SW ノ; 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.
248
En esta pantalla se presentan los siguientes widgets:
- 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.
Ilustración 5 Pantalla Mi Curso (rol de estudiante)
249
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.
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.
Ilustración 6 Pantalla Mi Curso (rol de profesor)
250
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.
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)
Ilustración 7 Red Social
251
- Menú de notificaciones: Actividad en la red social, solicitud de amistad,
usuarios bloqueados.
- Agregar enlaces de video.
- Mostrar los siguientes comentarios.
252
ANEXO 12: ENCUESTA
SOBRE USO DEL SISTEMA
253
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%
254
¿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%
255
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
256
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
0
0,5
1
1,5
2
2,5
A B C D E F
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
1 Ing. Juan Carlos Torres., Universidad Técnica Particular de Loja, San Cayetano Alto, [email protected] 2 Ing. Marco Paticio Abad. , Universidad Técnica Particular de Loja, San Cayetano Alto, [email protected] 3 Esteban Yomairo. Chamba. , Universidad Técnica Particular de Loja, San Cayetano Alto, [email protected]
Resumen Las plataformas e-learning han sido desarrolladas con el fin de mejorar los procesos de enseñanza-aprendizaje, cambiando el esquema tradicional, en donde estudiante y profesor deben ocupar un mismo espacio físico al momento de intercambiar información, a un esquema en donde se puede compartir un mismo curso con miles de usuarios conectados a través de una plataforma e-learning desde distintos lugares geográficos.
Una de estas plataformas, 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 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.
TABLE I TÉRMINOS CLAVE
Nro Término Descripción. 1 2 3 4 5 6
UTPL XML AJAX e-learning Moodle Web services
Universidad Técnica Particular de Loja Es el fundamento básico sobre el cual se construyen los servicios web, provee un lenguaje para definición y procesamiento de datos Asíncrono entre JAVA y XML. Aprendizaje electrónico. Plataforma e-learning. Aplicaciones para brindar servicio a otras aplicaciones a través de la red.
7 8
Widgets Red social
Aplicaciones web livianas, los 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.
Centro de Investigación Sísmica del Pacifico en Estados
INTRODUCCIÓN
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.
DESCRIPCIÓN DE LA SOLUCIÓN
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.
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.
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 de 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.
La implementación de las nuevas capas será sobre las
versiones estables de Moodle 1.9.x y Moodle 2.0.x.
Estado Actual
Con lo que actualmente se cuenta para dar inicio al proyecto, es con las versiones necesarias de la plataforma Moodle (Moodle 1.9.x y Moodle 2.0.x), éste es el núcleo sobre el cual se agregarán los nuevos servicios.
Además se cuenta con una versión de Moodle 1.9
integrada con una capa de red social de aprendizaje (sin uso de servicios web) desarrollada en el proyecto GlesOne en la UTPL.
En la FIGURA. 1, se presenta la apariencia
tradicional de una versión estable de Moodle.
FIGURA. 1 APARIENCIA TRADICIONAL DE UNA VERSIÓN
ESTABLE DE MOODLE
En la FIGURA. 2, se presenta una versión de
Moodle 1.9, integrada con una capa de red social sin uso de servicios web.
FIGURA. 2
APARIENCIA TRADICIONAL DE UNA VERSIÓN
ESTABLE DE MOODLE
Para satisfacer las mencionadas necesidades 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.
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.
Esta adaptación de la metodología XP para éste
proyecto en particular, se muestra gráficamente en la FIGURA. 3
FIGURA. 3
FASES DE XP ADAPTADAS AL ENTORNO DEL
PROYECTO
En el esquema de la FIGURA. 3, se elimina el concepto de programación en parejas, debido a que solamente se cuenta con un desarrollador, y se incorpora la definición de una arquitectura inicial que se considera necesaria para tener una visión clara del sistema.
La arquitectura de las nuevas capas implementadas
sobre Moodle, se presentan en la FIGURA. 4. Esta es la arquitectura propuesta y desarrollada de las nuevas capas sobre Moodle, con las cuales se incorpora las nuevas tendencias de la web moderna a la plataforma e-learning, con el objetivo de obtener un mejor rendimiento en el proceso de enseñanza-aprendizaje.
FIGURA. 4 NUEVAS CAPAS IMPLEMENTADAS SOBRE LA
PLATAFORMA E-LEARNING MOODLE (1.9.X Y 2.0.X)
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. Como se observa en la FIGURA. 1, para el desarrollo de las nuevas capas se usa una combinación de lenguajes de programación, estilos, y lenguajes de marcado. 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. 5. Se presenta las relaciones
existentes entre las nuevas capas desarrolladas e implementadas, identificando cómo interactúan éstas internamente.
No resulta difícil visualizar la estrecha relación
entre las tres capas, al final lo que se representa es el 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
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.
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 sea su estructura general, 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
FIGURA. 6 ARQUITECTURA GENERAL DEL SISTEMA
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.
RESULTADOS
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.
FIGURA. 7 PANTALLA PRINCIPAL
Los widgets aquí encontrados pueden ser
organizados de acuerdo a la conveniencia del usuario, además se pueden eliminar y volver a obtenerlos por medio de un menú de widgets.
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 usuário.
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.
FIGURA. 8 PANTALLA AMIGOS
En esta pantalla se presentan los siguientes widgets: - 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.
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 pestaña “Mi Curso”, en ese instante el nombre de la pestaña, cambiara por el nombre del curso seleccionado.
En esta pantalla, se hace una distinción entre los usuarios con rol de estudiante, y los usuarios con rol de profesor en el curso seleccionado, en cuanto a las funcionalidades proveídas.
FIGURA. 9 PANTALLA MI CURSO PARA USUARIO CON ROL DE
ESTUDIANTE
En esta pantalla se presentan los siguientes widgets: - 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.
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.
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.
FIGURA. 10 PANTALLA MI CURSO PARA USUARIO CON ROL DE
PROFESOR
En cuanto a la parte de Red Social de Aprendizaje, 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 FIGURA. 11.
FIGURA. 11
WIDGET 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) - Menú de notificaciones: Actividad en la red social,
solicitud de amistad, usuarios bloqueados. - Agregar enlaces de video. - Mostrar los siguientes comentarios.
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.
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 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.
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.