La Universidad Católica de Loja - DSPACEdspace.utpl.edu.ec/bitstream/123456789/1009/3/UTPL_Chamba_Jim… · aprendizaje en línea, deja mucho que desear en cuanto a las nuevas tendencias

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ぐぐぐぐぐぐぐくくくくくぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐく


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くくくくぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐく


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:


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:


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


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


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



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



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.


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.


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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].

http://www.w3.org/TR/widgets-reqs/

http://dojotoolkit.org/widgets

http://developer.yahoo.com/yui/3/widget/

http://www.prototypejs.org/

http://mootools.net/

http://www.moonkiki.com/moonkiki/imoogle/

http://jquery.com/

http://code.google.com/p/jpolite2/

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


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.

http://www.netvibes.com/

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


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


Descripción:

Para cada uno de los cursos del usuario, presentar los participantes de dicho curso,

clasificando los que tienen rol de profesor, y los que tienen rol de estudiante.


Historia de Usuario

Historia: Presentación de los anuncios hechos por el profesor en un curso


Descripción:

Para cada uno de los cursos del usuario, presentar los anuncios que ha hecho el

profesor.


106

Historia de Usuario

Historia: En caso de tener rol de profesor en el curso, permitirle agregar nuevos

anuncios, y editarlos


Descripción:

Identificar el rol que tiene el usuario en cada curso, y para los que tenga rol de

profesor, permitirle agregar nuevos comentarios, y además editar los existentes.


Historia de Usuario

Historia: Presentar una lista de tareas del curso, en caso que el usuario tenga rol

de profesor permitirle agregar nuevas tareas, y también permitirle ver las tareas

subidas por los estudiantes.


Descripción:

Identificar el rol del usuario en cada curso, si tiene rol de estudiante, únicamente

presentarle una lista de las tareas que ha colocado el profesor, y en caso de tener rol

de profesor, permitirle agregar nuevas tareas, y para cada tarea ver los recursos

subidos por los estudiantes.


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.


Descripción:

Identificar el rol del usuario en cada curso, si tiene rol de estudiante, permitirle ver la

lista de foros, acceder a las discusiones del foro, y participar con comentarios en las

discusiones, en caso de que el usuario tenga rol de profesor, permitirle además

agregar nuevos foros en el curso, y nuevas discusiones para los foros del curso.

Además el usuario debe tener la opción de eliminar los comentarios que él haya

realizado en las discusiones.


Historia de Usuario

Historia: Presentar una lista de los recursos disponibles en un curso.


Descripción:

Presentar a los usuarios los recursos disponibles en cada uno de los cursos en los

cuales participa, tales como documentos, o enlaces hacia páginas web.


108

Historia de Usuario

Historia: Presentar una lista de cuestionarios disponibles en el curso.


Descripción:

Presentar a los usuarios los cuestionarios agregados en cada uno de los cursos en los

cuales participa.


Historia de Usuario

Historia: Presentar una lista de los usuarios que se encuentran conectados en el

sistema.


Descripción:

Presentar a cada usuario que ha ingresado al sistema, toda la lista de usuarios que se

encuentran conectados en ese momento al sistema.


109

Historia de Usuario

Historia: Presentar una lista de los contactos del usuario.


Descripción:

Presentar a cada usuario una lista con la información de otros usuarios, que están en la

lista de sus contactos.


Historia de Usuario

Historia: Permitir a hacer una búsqueda de los usuarios del sistema


Descripción:

Presentar a cada usuario identificado la posibilidad de buscar otro usuario del sistema

por medio de su nombre o apellido, en caso de encontrar resultados en la búsqueda

presentarlos al usuario, caso contrario presentar un mensaje indicando que no se

encontraron resultados.


110

Historia de Usuario

Historia: Presentar los mensajes recibidos de un usuario.


Descripción:

Presentar una lista con los mensajes que han sido enviados al usuario actualmente

identificado, presentando además el nombre del usuario del cual proviene el mensaje.


Historia de Usuario

Historia: Permitir enviar un mensaje privado a cualquiera de los contactos del

usuario, o a los participantes de un curso en el que participa


Descripción:

Dar la opción de que el usuario pueda enviar un mensaje privado, a cualquiera de sus

contactos, y a los participantes de un curso al cual pertenece.


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



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.


Descripción:

Las pantallas pequeñas movibles dentro de la ventana del navegador deben

aparecer ordenadas adecuadamente, de manera que no pueda haber una sobre

otra, sino que se acoplen a distintos bloques según los manipule el usuario.

Observaciones:

Historia de Usuario

Historia: Minimizar, maximizar, actualizar y cerrar las pantallas pequeñas con

su contenido


Descripción:

Las pantallas pequeñas movibles deben tener la capacidad de hacerse más

pequeñas para ocultar su contenido, de maximizarse para presentar en la

pantalla completa, y de cerrarse.

Observaciones:

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


Descripción:

Las pantallas pequeñas movibles deben presentarse en una lista, de donde se

puedan agregar a la ventana del navegador.

Observaciones:

Historia de Usuario

Historia: Presentar la información de Moodle obtenida mediante Web

Services, en las pantallas movibles dentro del navegador


Descripción:

Dentro de las pantallas movibles presentar información que normalmente se

presenta en bloques en moodle, esta información debe ser la obtenida mediante

Web Services.

Observaciones:

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.


Historia de Usuario

Historia: Presenta un listado de los post realizados del usuario, y también los



Descripción:

Presentar al usuario todos los posts realizados por sus contactos, y los suyos propios

dentro de la interfaz dinámica.


116

Historia de Usuario

Historia: Permitir agregar comentarios en los posts de su red, ya sean de sus



Descripción:

A cada post darle la opción de agregar comentario, podrán hacerlo los contactos del

dueño del post, y el propietario del post. Estos comentarios se guardaran relacionados

al post correspondiente para luego ser presentados juntos al mismo.


Historia de Usuario

Historia: Permitir eliminar sea posts o comentarios que sean de propiedad del usuario

identificado.


Descripción:

Si el usuario identificado es el dueño de cualquiera de los post o comentarios que

aparecen dentro de su red, éste entonces debe tener la opción de eliminarlos.


117

Historia de Usuario

Historia: Permitir ingresar al muro de los contactos de la red del usuario


Descripción:

Al momento de dar clic sobre la imagen del post de un usuario, se deberá mostrar el

muro del dueño del post, esto es todos los posts y comentarios relacionados con dicho

usuario.


Historia de Usuario

Historia: Presentar ﾉ; ﾗヮ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.


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.


118

Historia de Usuario

Historia: Presentar una lista de notificaciones con las actividades que se ha realizado

relacionadas con su red social


Descripción:

Presentar al usuario identificado una lista con las notificaciones por movimientos en su

red social, por ejemplo alguien publicó en su muro, a alguien le gustó uno de sus

anuncios, o alguien comentó un post suyo.


Historia de Usuario

Historia: Presentar de los usuarios bloqueados.


Descripción:

Presentar al usuario identificado una lista con los usuarios que han sido bloqueados

por él mismo.


119

Historia de Usuario

Historia: Permitirle al usuario enviar invitaciones de amistad a otros usuarios del

sistema, y permitirle bloquearlos y eliminarlos.


Descripción:

Dar la opción de que el usuario pueda enviar invitaciones a otros usuarios que aún no

están entre sus contactos, si ya se encuentra entre sus contactos permitir bloquearlo, y

eliminarlo.


Historia de Usuario

Historia: Presentar para cada curso un espacio donde se gestionen posts y

comentarios que sean accesibles solamente a los participantes del curso.


Descripción:

Gestionar la presentación de post y comentarios dentro de un curso, cada curso tendrá

posts y comentarios relacionados a él, y los participantes de esta red serán los

participantes del curso sean estudiantes o profesores.


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.


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


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


Descripción:





Historia de Usuario

Historia: Presentación de los participantes de cada curso correspondiente al usuario

identificado, identificando si es estudiante o profesor del curso


Descripción:




124

Historia de Usuario

Historia: Presentación de los anuncios hechos por el profesor en un curso


Descripción:

Para cada uno de los cursos del usuario, presentar los anuncios que ha hecho el

profesor.


Historia de Usuario

Historia: En caso de tener rol de profesor en el curso, permitirle agregar nuevos

anuncios, y editarlos


Descripción:

Identificar el rol que tiene el usuario en cada curso, y para los que tenga rol de

profesor, permitirle agregar nuevos comentarios, y además editar los existentes.


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.


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.


126

SEGUNDA ITERACIÓN

Duración: 4 semanas Periodo: (mar-14-2011 - abr-14-2011)


Historia de Usuario

Historia: Presentar la lista de foros del curso, si el usuario es profesor permitirle

agregar nuevos foros y discusiones, si es estudiante solo permitirle agregar

comentarios a las discusiones.


Descripción:








127

Historia de Usuario

Historia: Presentar una lista de los recursos disponibles en un curso.


Descripción:




Historia de Usuario

Historia: Presentar una lista de cuestionarios disponibles en el curso.


Descripción:


cuales participa.


128

Historia de Usuario

Historia: Presentar una lista de los usuarios que se encuentran conectados en el

sistema.


Descripción:




Historia de Usuario

Historia: Presentar una lista de los contactos de un usuario.


Descripción:




129

Historia de Usuario

Historia: Permitir a hacer una búsqueda de los usuarios del sistema


Descripción:






130

TERCERA ITERACIÓN

Duración: 4 semanas Periodo: (abr-15-2011 - may-13-2011)


Historia de Usuario

Historia: Presentar los mensajes recibidos de un usuario.


Descripción:




Historia de Usuario

Historia: Permitir enviar un mensaje privado a cualquiera de los contactos del

usuario, o a los participantes de un curso en el que participa


Descripción:




131

Historia de Usuario

Historia: Presentar el contenido en pantallas pequeñas que se puedan mover



Descripción:

Crear una interfaz dinámica para presentación de distintos recursos de moodle

en diferentes pantallas pequeñas dentro de la ventana principal del navegador.

Observaciones:

Historia de Usuario

Historia: Fijar estas pantallas pequeñas a distintos bloques dentro de la

página, de manera que aparezcan ordenadamente.


Descripción:

Las pantallas pequeñas movibles dentro de la ventana del navegador deben

aparecer ordenadas adecuadamente, de manera que no pueda haber una sobre

otra, sino que se acoplen a distintos bloques según los manipule el usuario.

Observaciones:

132

Historia de Usuario

Historia: Minimizar, maximizar, actualizar y cerrar las pantallas pequeñas con

su contenido


Descripción:

Las pantallas pequeñas movibles deben tener la capacidad de hacerse más

pequeñas para ocultar su contenido, de maximizarse para presentar en la

pantalla completa, y de cerrarse.

Observaciones:

Historia de Usuario

Historia: Presentar un menú de con las pantallas movibles disponibles y que

se puedan agregar a la ventana inicial del navegador


Descripción:

Las pantallas pequeñas movibles deben presentarse en una lista, de donde se

puedan agregar a la ventana del navegador.

Observaciones:

133

CUARTA ITERACIÓN

Duración: 4 semanas Periodo: (may-16-2011 - jun-17-2011)


Historia de Usuario

Historia: Presentar la información de Moode obtenida mediante Web Services, en

las pantallas movibles dentro del navegador


Descripción:

Dentro de las pantallas movibles presentar información que normalmente se presenta

en bloques en moodle, esta información debe ser la obtenida mediante Web Services.

Observaciones:

Historia de Usuario

Historia: Presentar un espacio donde el usuario pueda agregar post, los cuales se

compartirán con todos sus contactos


Descripción:


agregar posts o anuncios que quiere compartir con sus contactos del sistema.


134

Historia de Usuario

Historia: Presenta un listado de los post realizados del usuario, y también los



Descripción:



Como Probarlo: Usando servicios web.

Historia de Usuario

Historia: Permitir agregar comentarios en los posts de su red, ya sean de sus



Descripción:





135

Historia de Usuario

Historia: Permitir eliminar sea posts o comentarios que sean de propiedad del usuario

identificado.


Descripción:




Historia de Usuario

Historia: Permitir ingresar al muro de los contactos de su red


Descripción:



usuario.


136

QUINTA ITERACIÓN

Duración: 4 semanas Periodo: (jun-20-2011 - jul-22-2011)


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.


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,



Historia de Usuario

Historia: Presentar una lista de notificaciones con las actividades que se ha realizado

relacionadas con su red social


Descripción:


red social, por ejemplo alguien publicó en su muro, a alguien le gustó uno de sus

anuncios, o alguien comentó un post suyo.


137

Historia de Usuario

Historia: Presentar de los usuarios bloqueados.


Descripción:


por él mismo.


138

SEXTA ITERACIÓN

Duración: 4 semanas Periodo: (jul-25-2011 - ago-26-2011)


Historia de Usuario

Historia: Permitirle al usuario enviar invitaciones de amistad a otros usuarios del

sistema, y permitirle bloquearlos y eliminarlos.


Descripción:


están entre sus contactos, si ya se encuentra entre sus contactos permitir bloquearlo,

y eliminarlo.


Historia de Usuario

Historia: Presentar para cada curso un espacio donde se gestionen posts y

comentarios que sean accesibles solamente a los participantes del curso.


Descripción:





139

Historia de Usuario

Historia: Adaptación del desarrollo a Moodle 2.0.x.


Descripción:




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

acceso a los datos, ya que algunas de las funciones para este objetivo presentes en

Moodle 1.9.x, están obsoletas en la nueva versión 2.0.x.

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.


Present_main_rsa.php Vista de la red social principal.


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


comment_ajax.php Registra la adición de un nuevo comentario a un post


Course_rsa_data.php Obtiene todos los datos que se presentarán en la red social de un curso


Delete_comment.php Registra la eliminación de un comentario de un post


Delete_update.php Registra la eliminación de un post


Edit_ad_ofteacher.php Registra un cambio en el anuncio de una sección.


Main_rsa_data.php Obtiene todos los datos que se presentaran en la red social principal


More_comments.php Presenta una lista de nuevos comentarios, a partir de los que ya están visibles.


Moreposts_incourse.php Presenta una lista de posts de un curso, a partir de los que ya están visibles.


New_ad_in_course.php Registra la adición de un nuevo anuncio en la sección de un curso.


New_post_in_wall.php Registra la adición de un nuevo post en el muro de un usuario


New_post_main_rsa.php Registra la adición de un nuevo post en la red social principal del usuario.


New_post_rsa_course.php Registra la adición de un nuevo post en la red social de un curso.


register_activity.php Registra una acción en la red social, como un like o un nuevo comentario.


Register_log.php Agrega un log en la base de datos sobre la actividad realizada


View_more_notifications.php Obtiene una nueva lista de notificaciones a partir de las que ya se han mostrado.


View_ specific_post.php Obtiene el post específico en el que se ha registrado una actividad.


Wall_data.php Obtiene todos los datos que se presentaran en el muro


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.


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.


Course_Resourse.php Vista de los recursos disponibles en un curso, y del formulario para agregar uno


150

nuevo en caso que el usuario sea el profesor del curso

Course_List.php Vista de los cursos de un usuario.


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


Online_Users_List.php Vista de los usuarios conectados en los últimos minutos al sistema.


SearchUsers.php Vista de formulario para buscar usuarios.


ViewSearchedUsers.php Obtiene la lista de usuarios encontrados en una búsqueda.


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


add_contact.php Registra la adición de un nuevo usuario a la lista de contactos.


add_discussion.php Registra la adición de nueva discusión para el foro de un curso.


add_postto_discussion.php Registra la adición de un nuevo post a la discusión de un foro.


block_unblock_contact.php Registra la acción de bloquear o desbloquear un usuario en la red social.


clear_readed_messages.php Registra la lectura de los mensajes recibidos de un usuario.


delete_contact.php Registra la eliminación de un contacto.


delete_forum_discussion.php Registra la eliminación de una discusión en el foro de un curso.


delete_mod_from_course_section.php

Registra la eliminación de un modulo de la sección de un curso.


delete_post_ofdiscussion.php Registra la eliminación de un post en la discusión de un foro.


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.


message_send_contacts.php Registra un nuevo mensaje a un usuario de la lista de contactos.


Message_send_onlineusers.php Registra un nuevo mensaje a un usuario de la lista de usuarios conectados.


Message_send_partic.php Registra un nuevo mensaje a un usuario de la lista de participantes de un curso.


Messagestoread.php Vista de los mensajes recibidos del usuario.


More_post_todisc.php Obtiene una nueva lista de posts en la discusión de un curso, a partir del último mostrado

New_assignment.php Registra un nuevo modulo tipo assignment en la sección de un curso.


New_forum.php Registra un nuevo modulo tipo forum en la sección de un curso.


New_quiz.php Registra un nuevo modulo tipo quiz en la sección de un curso.


New_resource.php Registra un nuevo modulo tipo resource en la sección de un curso.


Participants_in_course_list.php Vista de los participantes de un curso


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.


Que el usuario haya sido agregado al sistema previamente por un

administrador.

Que el usuario conozca su nombre de usuario y su contraseña

1.3.3 Entrada

- Nombre de usuario

- Contraseña


Ingreso al sistema correcto.



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





Presentación de los cursos en los cuales el usuario identificado cumple un rol, sea de

profesor o de estudiante.

2.2.1 Descripción

Una vez que el usuario se ha identificado, se deberán presentar una pantalla

dentro del navegador, con la lista de cursos del usuario.


Que el usuario tenga rol de profesor o de estudiante en alguno de los cursos del

sistema.

2.2.3 Entrada

- Ingresar a la presentación dinámica del sistema.


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



158


Presentación de cada uno de los cursos clasificados de acuerdo a la categoría a la que

pertenecen.

2.3.1 Descripción


dentro del navegador, con la lista de cursos del usuario, clasificados en la

categoría de cursos correspondiente.


Que el usuario tenga rol de profesor o de estudiante en alguno de los cursos del

sistema, y que estos cursos pertenezcan a una categoría específica.

2.3.3 Entrada



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

clasificados de acuerdo a su categoría.



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


dentro del navegador, presentando el mensaje de que no está enrolado en

ningún curso actualmente.


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

2.4.3 Entrada



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

cursos actualmente.



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




Presentación de una lista con los participantes del curso al ingresar a uno de los cursos

en los que el usuario tiene un rol de profesor o estudiante.

3.2.1 Descripción

Una vez que el usuario tiene disponible la lista de sus cursos, deberá poder

ingresar a cada uno de ellos, al dar clic sobre alguno se deberá presentar una

pantalla dentro del navegador, con la lista de los participantes del curso

seleccionado.


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

3.2.3 Entrada

- Seleccionar un curso de la lista de cursos del usuario.


La lista de los participantes del curso seleccionado.



161


Presentación de una lista con los participantes del curso clasificados de acuerdo a su

rol, sea de profesor o estudiante.

3.3.1 Descripción



pantalla dentro del navegador, con la lista de los participantes del curso

seleccionado, en esta lista se deberá visualizar por separados los usuarios con

rol de profesor, y los usuarios con rol de estudiante.


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

3.3.3 Entrada



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

tienen en el curso.



162


Presentación de mensaje indicando que el curso no tiene usuarios con rol de profesor

y/o estudiante.

3.4.1 Descripción

Si el curso seleccionado no tiene participantes, sea con rol de profesor, o de

estudiantes, se deberá mostrar un mensaje indicando esto.


Que el curso tenga no tenga participantes, sea con rol de profesores, o de

estudiantes.

3.4.3 Entrada



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



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.


Presentación del último de los anuncios del profesor en el curso, permitiendo al

usuario navegar además por todos los anteriores.

4.2.1 Descripción



pantalla dentro del navegador, con la lista de los anuncios que ha realizado el

profesor en el curso, inicialmente se presentará únicamente el último anuncio,

pero el usuario será capaz de navegar por todos los anuncios a través de unos

iconos que le permitan ir al siguiente y al anterior.


Que el curso tenga anuncios hechos por el profesor.

4.2.3 Entrada



Presentación del último anuncio en el curso, y poder navegar por los anteriores

por medio de iconos que permitan ir al siguiente y al anterior.



164


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

4.3.1 Descripción

Si aun no se han realizado anuncios en el curso por parte del profesor, entonces

el usuario debe obtener un mensaje indicando que no existen anuncios en ese

curso.


Que el curso no tenga anuncios.

4.3.3 Entrada



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

seleccionado.



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.


Presentar la opción de agregar anuncio cuando el usuario tiene rol de profesor en el

curso.

5.2.1 Descripción




profesor en el curso, si este usuario tiene rol de profesor en este curso, se

deberá presentar además un área de texto donde podrá escribir un nuevo

anuncio y publicarlo en el curso.


Que el usuario identificado tenga rol de profesor en el curso seleccionado.

5.2.3 Entrada


- Mensaje del nuevo anuncio


Presentación del nuevo anuncio agregado en el curso.



166


Posibilidad de editar los anuncios de un curso, solo cuando el usuario tiene rol de

profesor en el curso.

5.3.1 Descripción




profesor en el curso, si este usuario tiene rol de profesor en el curso, se deberá

permitir la opción de editar alguno de los anuncios seleccionados al dar doble

clic sobre el mensaje del anuncio que quiere editar.



Que exista al menos un anuncio para que pueda se editado

5.3.3 Entrada


- Nuevo mensaje en el anuncio que ya existía.


Presentación del anuncio con el nuevo mensaje.



167


No permitir editar, ni agregar nuevos anuncios cuando el usuario no tenga rol de

profesor en el curso seleccionado.

5.4.1 Descripción




profesor en el curso, si este usuario no tiene rol de profesor en el curso, no se

deberá presentar la opción ni de agregar nuevo anuncio, ni de editar los

existentes.


Que el usuario identificado no tenga rol de profesor en el curso seleccionado.

Que exista al menos un anuncio para probar que no se permite editarlo.

5.4.3 Entrada



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



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.


Presentar la opción de agregar tarea cuando el usuario tiene rol de profesor en el

curso.

6.2.1 Descripción



pantalla dentro del navegador, con la lista de los tareas que hay en el curso, si

este usuario tiene rol de profesor en este curso, se deberá presentar además

un formulario en donde podrá agregar datos para una nueva tarea.



6.2.3 Entrada


- Llenar los campos del formulario para la nueva tarea.


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



169


Presentar mensaje de error al agregar tarea, cuando no se han enviado los datos

requeridos para la nueva tarea.

6.3.1 Descripción

Cuando el usuario con rol de profesor agrega una nueva tarea, existen datos

requeridos para esta nueva tarea, si al enviar la opción de agregar la nueva

tarea, no se han llenado todos estos datos requeridos, entonces aparecerá un

mensaje indicando que no se han llenado todos los datos necesarios.



Datos requeridos vacios.

6.3.3 Entrada


- Dejar en blando uno o varios de los datos requeridos del formulario

para la nueva tarea.


Presentación del mensaje indicando que no se ha agregado la tarea debido a

que los datos requeridos están vacíos.



170


Presentar las los archivos que los estudiantes han subido en las tareas, cuando el

usuario tiene rol de profesor.

6.4.1 Descripción

Cuando el usuario con rol de profesor da clic sobre alguna de las tareas, se

deberán presentar los archivos que el estudiante ha subido en esa tarea.



Que existan archivos subidos por los estudiantes en la tarea seleccionada.

6.4.3 Entrada


- Seleccionar alguna de las tareas del curso.


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



171


No presentar la opción de agregar nuevas tareas, ni de ver los archivos subidos por los

estudiantes en las tareas cuando el usuario tiene rol de estudiante.

6.5.1 Descripción

Cuando el usuario identificado tiene rol de estudiante, solamente deberá tener

una lista con las tareas disponibles en el curso, no deberá tener la opción de

agregar nuevas tareas, ni de ver que archivos han sido subidos por los

estudiantes.


Que el usuario identificado tenga rol de estudiante en el curso seleccionado.

6.5.3 Entrada


- Seleccionar alguna de las tareas del curso sin permitirle ver los archivos

que los estudiantes han subido en esa tarea.


Presentación de la lista de tareas del curso, sin la opción de agregar una nueva,

ni de ver los archivos que los estudiantes han subido para la tarea seleccionada.



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








Ver la lista de foros disponibles en el curso.

7.2.1 Descripción



pantalla dentro del navegador con la lista de los foros que hay en el curso, esta

lista será mostrada tanto a usuarios con rol de profesor, como a usuarios con

rol de estudiante.


Que el usuario identificado tenga rol de profesor o estudiante en el curso

seleccionado.

Que existan foros disponibles para ese curso seleccionado.

7.2.3 Entrada



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



173


Ver la lista de discusiones de cada foro del curso.

7.3.1 Descripción



pantalla dentro del navegador con la lista de los foros que hay en el curso, esta

lista será mostrada tanto a usuarios con rol de profesor, como a usuarios con

rol de estudiante, al seleccionar alguno de esto foros, se deberán mostrar las

discusiones que hay para este foro.



seleccionado.

Que existan foros disponibles para ese curso seleccionado, y que el foro cuente

con discusiones.

7.3.3 Entrada


- Seleccionar uno de los foros del curso


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



174


Agregar posts a los temas de discusión del foro.

7.4.1 Descripción



pantalla dentro del navegador con la lista de los foros que hay en el curso, al

seleccionar alguno de esto foros, se deberán mostrar las discusiones que hay

para este foro, cada discusión deberá tener la opción de comentar, para que los

usuarios sea con rol de profesor o de estudiante participen en la discusion.



seleccionado.

Que existan discusiones para el foro seleccionado.

7.4.3 Entrada


- Seleccionar uno de los foros del curso

- Seleccionar la opción comentar de una discusión del foro.


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



175


Agregar nuevo foro en el curso.

7.5.1 Descripción



pantalla dentro del navegador con la lista de los foros que hay en el curso, y si

el usuario tiene rol de profesor del curso, además se presentará un formulario

con datos para agregar un nuevo foro.


Que el usuario identificado tenga rol de profesor curso seleccionado.

7.5.3 Entrada


- Llenar los datos del formulario de nuevo foro


Agregación del nuevo foro al curso.



176

7.6 Nombre del caso de prueba IV

Agregar nueva discusión en el foro del curso.

7.6.1 Descripción



pantalla dentro del navegador con la lista de los foros que hay en el curso, al

dar clic sobre cualquiera de los foros se deberá presentar la lista de discusiones

de ese foro, y si el usuario tiene rol de profesor, además deberá presentarse la

opción de agregar una nueva discusión en el foro.


Que el usuario identificado tenga rol de profesor curso seleccionado.

7.6.3 Entrada


- Llenar seleccionar algún foro del curso.

- Llenar los datos del formulario de nueva discusión.


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



177

7.7 Nombre del caso de prueba IV

Mensaje indicando que no existen foros disponibles en el curso.

7.7.1 Descripción



pantalla dentro del navegador con el mensaje de que no hay foros disponibles

para ese curso.



seleccionado.

Que no existan foros relacionados con el curso seleccionado.

7.7.3 Entrada



Mensaje indicando que no existen foros en el curso seleccionado.



178

8. Historia 8:

Presentar una lista de los recursos disponibles en un curso.

8.1 Descripción




Ver la lista de recursos disponibles en el curso.

8.2.1 Descripción



pantalla dentro del navegador con la lista de los recursos que hay en el curso,

tales como documentos o enlaces hacia páginas web, esta lista será mostrada

tanto a usuarios con rol de profesor, como a usuarios con rol de estudiante.



seleccionado.

Que existan recursos disponibles para ese curso seleccionado.

8.2.3 Entrada



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



179


Mensaje indicando que no existen recursos para el curso seleccionado.

8.3.1 Descripción



pantalla dentro del navegador con un mensaje indicando que no existen

recursos para el curso seleccionado.



seleccionado.

Que no existan recursos disponibles para ese curso seleccionado.

8.3.3 Entrada



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

seleccionado.



180

9. Historia 9:

Presentar una lista de cuestionarios disponibles en el curso.

9.1 Descripción


cuales participa.


Presentar la lista de cuestionarios disponibles en el curso.

9.2.1 Descripción



pantalla dentro del navegador con la lista de los cuestionarios que hay en el

curso, esta lista será mostrada tanto a usuarios con rol de profesor, como a

usuarios con rol de estudiante.



seleccionado.

Que existan cuestionarios disponibles para ese curso seleccionado.

9.2.3 Entrada



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



181


Mensaje indicando que no existen cuestionarios para el curso seleccionado.

9.3.1 Descripción



pantalla dentro del navegador con un mensaje indicando que no existen

cuestionarios para el curso seleccionado.



seleccionado.

Que no existan cuestionarios disponibles para ese curso seleccionado.

9.3.3 Entrada



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

seleccionado.



182

10. Historia 10:

Presentar una lista de los usuarios que se encuentran conectados en el sistema.

10.1 Descripción




Presentar la lista de usuarios conectados al sistema.

10.2.1 Descripción

Se deberá presentar una pantalla dentro del navegador con la lista de los

usuarios conectados en el sistema en ese momento.


Que existan otros usuarios conectados al sistema en ese momento.

10.2.3 Entrada

- Ingreso al sistema


Presentación del la lista de usuarios conectados al sistema.



183


Mensaje indicando que no existen otros usuarios conectados al sistema en ese

momento.

10.3.1 Descripción

Se deberá presentar una pantalla dentro del navegador con un mensaje

indicando que no existen otros usuarios conectados al sistema en ese

momento.


Que no existan otros usuarios conectados al sistema en ese momento.

10.3.3 Entrada

- Ingreso al sistema.


Presentación mensaje indicando que no existen usuarios conectados al sistema

en ese momento.



184

11. Historia 11:

Presentar una lista de los contactos del usuario.

11.1 Descripción




Presentar la lista de contactos del usuario identificado.

11.2.1 Descripción

Se deberá presentar una pantalla dentro del navegador con la lista de los

contactos del usuario identificado.


Que el usuario tenga una lista de contactos de otros usuarios del sistema.

11.2.3 Entrada



Presentación del la lista de contactos del usuario identificado.



185


Mensaje indicando que la lista de contactos del usuario identificado esta vacía.

11.3.1 Descripción


indicando que no tiene contactos en su lista.


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

11.3.3 Entrada



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



186

12. Historia 12:

Permitir a hacer una búsqueda de los usuarios del sistema.

12.1 Descripción






Buscar un usuario por su nombre o apellido.

12.2.1 Descripción

Se deberá presentar una pantalla dentro del navegador con un campo donde se

pueda ingresar el nombre o apellido de un usuario, e iniciar una búsqueda en el

sistema, al presionar el botón buscar.


Que existan coincidencias con el usuario buscado.

12.2.3 Entrada


- Ingreso de nombre o apellido del usuario que se está buscando.


Presentación del la lista de coincidencias con el usuario buscado.



187


Mensaje indicando que la no se han encontrado resultados en la búsqueda realizada.

12.3.1 Descripción


indicando que no hay coincidencias para la búsqueda realizada.


Que no haya coincidencias con el usuario buscado.

12.3.3 Entrada


- Ingreso de nombre o apellido del usuario que se está buscando.


Presentación mensaje indicando que no se han encontrado coincidencias con la

búsqueda.



188

13. Historia 13:

Presentar los mensajes recibidos de un usuario.

13.1 Descripción




Presentar los mensajes recibidos al usuario identificado.

13.2.1 Descripción

Se deberá presentar una pantalla dentro del navegador con un campo donde se

presente la lista de mensajes que el usuario ha recibido desde otros usuarios

del sistema, identificando cual ha sido el usuario que le ha enviado el mensaje.


Que existan mensajes pendientes por leer del usuario identificado.

13.2.3 Entrada



Presentación del la lista mensajes pendientes por leer del usuario identificado.



189


Mensaje indicando que la no se han encontrado mensajes pendientes para el usuario

identificado.

13.3.1 Descripción


indicando que no hay mensajes pendientes.


Que no existan mensajes pendientes por leer del usuario identificado.

13.3.3 Entrada



Presentación mensaje indicando que no se han encontrado mensajes

pendientes.



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




Enviar mensaje privado a cualquiera de sus contactos.

14.2.1 Descripción

Se deberá presentar permitir la opción de enviar una mensaje privado a

cualquiera de los contactos, al seleccionarlo desde la lista de contactos,

aparecerá un área de texto donde se podrá escribir el mensaje, y un botón para

enviarlo al hacer clic sobre éste, y deberá aparecer la confirmación de que el

mensaje ha sido enviado, en caso de producirse un error aparecerá una alerta

con el mensaje de error.


Que existan usuarios en su lista de contactos.

14.2.3 Entrada


- Selección del contacto de su lista de contactos.

- Contenido del mensaje.


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



191


Enviar mensaje privado a cualquiera de los participantes de un curso en los que

también participa el usuario identificado.

14.3.1 Descripción

Se deberá presentar permitir la opción de enviar un mensaje privado a

cualquiera de los participantes de un curso, al seleccionarlo desde la lista de

participantes de un curso, aparecerá un área de texto donde se podrá escribir

el mensaje, y un botón para enviarlo al hacer clic sobre éste, y deberá aparecer

la confirmación de que el mensaje ha sido enviado, en caso de producirse un

error aparecerá una alerta con el mensaje de error.


Que existan usuarios en la lista de participantes del curso seleccionado.

14.3.3 Entrada


- Ingreso a un curso

- Selección del usuario de la lista de participantes del curso.

- Contenido del mensaje.


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



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.


Verificar pantallas movibles.

15.2.1 Descripción

Luego de ingresar al sistema se deberá ingresar a una interfaz dinámica donde

se presentaran todos los servicios de moodle obtenidos mediantes servicios

web. Esta interfaz dinámica deberá presentar pantallas que se puedan ubicar

en distintos bloques dentro del navegador.


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

15.2.3 Entrada



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



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.


Verificar adaptación de las pantallas pequeñas dentro de los bloques.

16.2.1 Descripción



web. Esta interfaz dinámica deberá presentar pantallas que se puedan ubicar

en distintos bloques dentro del navegador, donde cada bloque puede contener

una o varias pantallas con distinta información.



Que exista más de una ventana pequeña dentro del navegador, para ajustarla a

los distintos bloques.

16.2.3 Entrada


- Movimiento de las pantallas pequeñas hacia otro bloque.


Agregar una o varias ventanas a los distintos bloques, permitiendo la

visualización de todas las ventanas en el bloque.



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.


Capacidad para minimizar, maximizar, actualizar y cerrar el contenido de las pantallas

pequeñas dentro del navegador.

17.2.1 Descripción



web. Esta interfaz dinámica deberá presentar una o varias pantallas pequeñas

dentro del navegador, con distintos contenidos, y cada una de estas pantallas

deberá tener la opción de minimizarse, maximizarse, cerrarse, y de actualizar su

contenido.



Que exista una o varias ventanas pequeñas dentro del navegador.

17.2.3 Entrada


- Seleccionar la opción minimizar/maximizar/actualizar/cerrar desde un

icono en la pantalla pequeña.


Ejecución de la acción seleccionada con la ventana pequeña que está dentro del

navegador:

Minimizar: Dejar visible únicamente el titulo de la ventana pequeña.

Maximizar: Hacer que la ventana pequeña ocupe el espacio completo dentro

del navegador.

195

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

navegador.



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.


Presentación de un menú con la lista de pantallas pequeñas disponibles para agregarse

en la ventana principal del navegador.

18.2.1 Descripción



web. Esta interfaz dinámica deberá presentar una o varias pantallas pequeñas

dentro del navegador, y se presentará además una opción para desplegar una

ventana con la lista de todas las pantallas disponibles para agregarse en la

ventana principal del navegador.



“WﾉWIIｷﾗﾐ;ヴ ┌ﾐｷIﾗﾐﾗｷSWﾐデｷaｷI;Sﾗ IﾗﾏﾗさMWﾐ┎ ヮ;ヴ; ;ｪヴWｪ;ヴﾏ=ゲ ┗Wﾐデ;ﾐ;ゲヮWケ┌Wﾓ;ゲざ.

18.2.3 Entrada


- Seleccionar さMWﾐ┎ ヮ;ヴ; ;ｪヴWｪ;ヴﾏ=ゲ ┗Wﾐデ;ﾐ;ゲヮWケ┌Wﾓ;ゲざ.


Aparición de una ventana con una lista de las ventanas pequeñas que se

pueden agregar en la ventana principal del navegador.



197


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.



Haber abierto el menú con la lista de las pantallas pequeñas disponibles.

18.3.3 Entrada


- “WﾉWIIｷﾗﾐ;ヴさMWﾐ┎ ヮ;ヴ; ;ｪヴWｪ;ヴﾏ=ゲ ┗Wﾐデ;ﾐ;ゲヮWケ┌Wﾓ;ゲざく - Seleccionar una de las pantallas disponibles para agregase mostradas en

la lista presentada por el menú.


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



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.


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.



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

19.2.3 Entrada



Presentación en las ventanas pequeñas dentro del navegador, todas las

interacciones necesarias con moodle mediante servicios web.



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


agregar posts o anuncios que quiera compartir con sus contactos del sistema.


Agregar nuevo post.

20.2.1 Descripción

Luego de ingresar al sistema se deberá ingresar a una interfaz dinámica donde,

se presen se presentaran una o varias pantallas pequeñas dentro de la ventana

principal del navegador, una de estas pantallas pequeñas deberá contener un

espacio para que el usuario pueda realizar un post, el mismo que será

compartido con su lista de contactos.



Tener disponible la pantalla pequeña donde podrá realizar el post.

20.2.3 Entrada


- Contenido del post.


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



200


Agregar un post vacio.

20.3.1 Descripción

Si el usuario intenta agregar un post vacio, deberá aparecer una alerte

indicando que el post debe poseer algún contenido.



Tener disponible la pantalla pequeña donde podrá realizar el post.

20.3.3 Entrada


- Contenido vacio del post.


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



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




Listado de post realizados por el usuario identificado.

21.2.1 Descripción



principal del navegador, una de estas pantallas pequeñas deberá contener la

lista de posts que ha realizado el usuario identificado actualmente.



21.2.3 Entrada



Una lista dentro de una ventana pequeña en el navegador, con todos los posts

que ha realizado el usuario identificado.



202


Listado de post realizados por los contactos del usuario identificado.

21.3.1 Descripción



principal del navegador, una de estas pantallas pequeñas deberá contener la

lista de posts que han realizado los contactos del usuario identificado.



21.3.3 Entrada



Una lista dentro de una ventana pequeña en el navegador, con todos los posts

que han realizado los contactos del usuario identificado.



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





Agregar comentarios a los posts propios del usuario y a los de sus contactos.

22.2.1 Descripción

Para cada post presentado en la lista de posts del usuario y de sus contactos

deberá existir la opción de agregar comentarios.



Tener disponible los posts realizados por el propio usuario, o por sus contactos.

22.2.3 Entrada


- Selección del post a comentar

- Contenido del comentario


Agregación del comentario realizado al correspondiente post.



204


Agregar comentario vacio a los posts propios del usuario y a los de sus contactos.

22.3.1 Descripción

Intentar agregar un post vacio en los posts del los contactos o a los propios del

usuario.




22.3.3 Entrada


- Selección del post a comentar

- Contenido vació del comentario


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



205

23. Historia 23:

Permitir eliminar sea posts o comentarios que sean de propiedad del usuario

identificado.

23.1 Descripción




Eliminar post.

23.2.1 Descripción

Para cada post presentado en la lista de posts del usuario y de sus contactos

deberá existir la opción de eliminar post, siempre y cuando el usuario

identificado sea el dueño del post.




23.2.3 Entrada


- Usuario identificado como dueño del post

- “WﾉWIIｷﾗﾐ;ヴﾉ; ﾗヮIｷﾙﾐさEﾉｷﾏｷﾐ;ヴざヮﾗゲデ


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



206


Eliminar comentario.

23.3.1 Descripción

Para cada comentario presentado por cada uno de los posts del usuario y de

sus contactos deberá existir la opción de eliminar comentario, siempre y

cuando el usuario identificado sea el dueño del comentario a eliminar.



Tener disponible los comentarios de los posts realizados por el usuario.

23.3.3 Entrada


- Usuario identificado como dueño del comentario

- “WﾉWIIｷﾗﾐ;ヴﾉ; ﾗヮIｷﾙﾐさEﾉｷﾏｷﾐ;ヴざ comentario


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

que pertenece.



207

24. Historia 24:

Permitir ingresar al muro de los contactos de la red del usuario.

24.1 Descripción



usuario.


Ingresar al muro de un usuario.

24.2.1 Descripción

El usuario debe tener la posibilidad de visitar el muro de sus contactos al

seleccionar la imagen de alguno de estos desde un post.



Tener disponible los posts realizados por el contactacto, al cual quiere visitar su

muro.

24.2.3 Entrada


- Seleccionar usuario al cual se va a realizar una visita a su muro.


Presentación de todos los posts y comentarios relacionados con el contacto al

que ha visitado.



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,



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 ｪ┌ゲデ;ざく



Tener disponible los posts y comentarios realizados por sus contactos.

25.2.3 Entrada


- Seleccionar ﾉ; ﾗヮIｷﾙﾐさMW ｪ┌ゲデ;ざ SWﾉヮﾗゲデﾗ IﾗﾏWﾐデ;ヴｷﾗ.


Presentar mensaje que le ha gustado ese comentario.



209


Presentar notificación de que a un contacto le ha gustado una publicación del usuario

identificado.

25.3.1 Descripción

El usuario deberá tener un menú de notificaciones de a quienes les ha gustado

una publicación suya.



Q┌W ;ﾉｪ┌ｷWﾐｴ;┞; ｴWIｴﾗ ┌ﾐさMW ｪ┌ゲデ;ざ ; ;ﾉｪ┌ﾐ; SW ゲ┌ゲヮ┌HﾉｷI;IｷﾗﾐWゲ.

25.3.3 Entrada


- Seleccionar el menú de notificaciones.


Presentar ﾐﾗデｷaｷI;IｷﾗﾐWゲ Iﾗﾐ WﾉﾐﾗﾏHヴW SW ケ┌ｷWﾐｴ; ｴWIｴﾗ ┌ﾐさMW ｪ┌ゲデ;ざ Wﾐ alguna de sus publicaciones.



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


red social, por ejemplo, alguien aceptó una invitación suya de amistad, o alguien

comentó un post suyo.


Ver un menú de todas las notificaciones del usuario.

26.2.1 Descripción

Se le debe presentar al usuario un menú con las notificaciones que ha recibido

por alguna actividad en su red. Las actividades pueden ser que alguien comento

un post suyo, o que alguien acepto una solicitud de amistad suya.



Que se haya realizado alguna actividad en su red social.

26.2.3 Entrada


- Selección del menú de notificaciones


Presentar un menú con las notificaciones que ha recibió el usuario debido a

alguna acción realizada en su red.



211

27. Historia 27:

Presentar de los usuarios bloqueados.

27.1 Descripción


por él mismo.


Ver un menú de los usuarios bloqueados.

27.2.1 Descripción

Se le deberá presentar al usuario un menú con las lista de usuarios que han sido

bloqueados por él.



Tener al menos un usuario bloqueado.

27.2.3 Entrada


- Selección del menú de usuarios bloqueados


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



212


Opción desbloquear de la lista del menú de usuarios bloqueados.

27.3.1 Descripción

Se le deberá presentar al usuario un menú con las lista de usuarios que han sido

bloqueados por él, y junto a cada usuario bloqueado la opción de

desbloquearlo.



Tener al menos un usuario bloqueado.

27.3.3 Entrada


- Selección del menú de usuarios bloqueados


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

lista.



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


están entre sus contactos, si ya se encuentra entre sus contactos permitir bloquearlo, y

eliminarlo.


Enviar invitaciones de amistad.

28.2.1 Descripción

Se le deberá tener la opción de enviar solicitudes de amistad a usuarios que

aún no estén entre los contactos del usuario identificado, estas opciones se

presentarán al presentar un usuario como resultado de una búsqueda.



Que existan otros usuarios en el sistema.

Obtener resultados de una búsqueda de usuarios.

28.2.3 Entrada


- Seleccion;ヴﾉ; ﾗヮIｷﾙﾐさWﾐ┗ｷ;ヴｷﾐ┗ｷデ;Iｷﾙﾐざｴ;Iｷ; ﾗデヴﾗ ┌ゲ┌;rio.


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



214


Opción bloquear un contacto.

28.3.1 Descripción

Se le deberá tener la opción de bloquear usuarios que estén entre los contactos

del usuario identificado, estas opciones se presentarán al presentar un usuario

como resultado de una búsqueda.



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

identificado.

28.3.3 Entrada


- “WﾉWIIｷﾗﾐ;ヴﾉ; ﾗヮIｷﾙﾐさBﾉﾗケ┌W;ヴ Contactoざく


Bloqueo del usuario que estaba como contacto.



215


Eliminar un contacto.

28.4.1 Descripción

Se le deberá tener la opción de eliminar contactos, esta opción se presentarán

al presentar un usuario como resultado de una búsqueda y éste sea contacto

del usuario identificado actualmente.



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

identificado.

28.4.3 Entrada


- “WﾉWIIｷﾗﾐ;ヴﾉ; ﾗヮIｷﾙﾐさEliminar Contactoざく


Eliminar al usuario de la lista de contactos.



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





Presentación de posts y comentarios propios para cada curso.

29.2.1 Descripción

Se le deberá tener un espacio dentro de cada curso en donde se tenga una lista

de posts y comentarios que sean accesibles solamente a los participantes del

curso.



Haber ingresado a un curso.

Que existan posts y comentarios en el curso que se ha ingresado.

29.2.3 Entrada


- Seleccionar un curso


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



217


Opción de agregar posts y comentarios en red del curso.

29.3.1 Descripción

Además de tener un espacio dentro de cada curso en donde se tenga una lista

de posts y comentarios también se debe tener la opción de agregar mas posts y

comentarios por parte de los participantes del curso.




29.3.3 Entrada



- Contenido de anuncio


Agregar y presentar el nuevo post/comentario dentro de la lista de posts y

comentarios del curso.



218


Opción de eliminar posts y comentarios en red del curso.

29.4.1 Descripción

Se deberá tener la opción de eliminar los posts/comentarios, siempre que el

usuario sea el dueño del post/comentario.




29.4.3 Entrada



- “WﾉWIIｷﾗﾐ;ヴﾉ; ﾗヮIｷﾙﾐさEﾉｷﾏｷﾐ;ヴざヮﾗゲデっIﾗﾏWﾐデ;ヴｷﾗ


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

curso.



219

30. Historia 30:

Adaptación del desarrollo a Moodle 2.0.x.

30.1 Descripción





Funcionalidades desarrolladas para Moodle 1.9.x adaptadas a Moodle 2.0.x.

30.2.1 Descripción

Comprobar que todas las funcionalidades desarrolladas en Moodle 1.9.x

funcionen correctamente en Moodle 2.0.x.


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

30.2.3 Entrada



Todas las funciones desarrolladas para Moodle 1.9.x funcionando

correctamente en Moodle 2.0.x.



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


Presentación de los cursos en los cuales el usuario identificado cumple un rol, sea de profesor o de estudiante.


Presentación de cada uno de los cursos clasificados de acuerdo a la categoría a la que pertenecen.


Presentación de mensaje indicando que el usuario no tiene rol como profesor o como estudiante en ninguno de los cursos.


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.


Presentación de una lista con los participantes del curso clasificados de acuerdo a su rol, sea de profesor o estudiante.


Presentación de mensaje indicando que el curso no tiene


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.


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


Presentar la opción de agregar anuncio cuando el usuario tiene rol de profesor en el curso.


Posibilidad de editar los anuncios de un curso, solo cuando el usuario tiene rol de profesor en el curso.


No permitir editar, ni agregar nuevos anuncios cuando el usuario no tenga rol de profesor en el curso seleccionado.


Presentar la opción de agregar tarea cuando el usuario tiene rol de profesor en el curso.


Presentar mensaje de error al agregar tarea, cuando no se han enviado los datos requeridos para la nueva tarea.


Presentar las los archivos que los estudiantes han subido en las tareas, cuando el usuario tiene rol de profesor.


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.


230

Ver la lista de foros disponibles en el curso.


Ver la lista de discusiones de cada foro del curso.


Agregar posts a los temas de discusión del foro.


Agregar nuevo foro en el curso.


Agregar nueva discusión en el foro del curso.


Mensaje indicando que no existen foros disponibles en el curso.


Ver la lista de recursos disponibles en el curso.


Mensaje indicando que no existen recursos para el curso seleccionado.


Presentar la lista de cuestionarios disponibles en el curso.


Mensaje indicando que no existen cuestionarios para el curso seleccionado.


Presentar la lista de usuarios conectados al sistema.


Mensaje indicando que no existen otros usuarios conectados al sistema en ese momento.


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.


Buscar un usuario por su nombre o apellido.


Mensaje indicando que la no se han encontrado resultados en la búsqueda realizada


Presentar los mensajes recibidos al usuario identificado.


Mensaje indicando que la no se han encontrado mensajes pendientes para el usuario identificado.


Enviar mensaje privado a cualquiera de sus contactos.


Enviar mensaje privado a cualquiera de los participantes de un curso en los que también participa el usuario identificado


Verificar pantallas movibles.


Verificar adaptación de las pantallas pequeñas dentro de los bloques.


Capacidad para minimizar, maximizar, actualizar y cerrar el contenido de las pantallas pequeñas dentro del navegador


Presentación de un menú con la lista de pantallas pequeñas disponibles para agregarse en la ventana principal del navegador.


Agregar nueva ventana pequeña a la ventana principal del navegador.


232

Presentar la información de Moodle obtenida mediante servicios web en las pantallas pequeñas dentro del navegador.


Agregar nuevo post.


Agregar un post vacio.


Listado de post realizados por el usuario identificado.


Cerrado Listado de post realizados por los contactos del usuario identificado.


Agregar comentarios a los posts propios del usuario y a los de sus contactos.


Agregar comentario vacio a los posts propios del usuario y a los de sus contactos.


Cerrado Eliminar post.


Eliminar comentario.


Ingresar al muro de un usuario.


D;ヴ ┌ﾐさMW ｪ┌ゲデ;ざ ; I┌;ﾉケ┌ｷWヴ; de los posts o comentarios de los contactos.


Presentar notificación de que a un contacto le ha gustado una publicación del usuario identificado.


Ver un menú de todas las notificaciones del usuario.


Ver un menú de los usuarios bloqueados.


Opción desbloquear de la lista Prueba Satisfactoria Cerrado

233

del menú de usuarios bloqueados. Enviar invitaciones de amistad.


Opción bloquear un contacto.


Eliminar un contacto.


Presentación de posts y comentarios propios para cada curso.


Opción de agregar posts y comentarios en red del curso


Opción de eliminar posts y comentarios en red del curso


Funcionalidades desarrolladas para Moodle 1.9.x adaptadas a Moodle 2.0.x.


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){

http://sumoodle/wspp/wsdl_pp.php









































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


- 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


- 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.


- 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.

http://www.glesone.org/moodle_widgets

http://www.glesone.org/moodle20_widgets

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.

Documents

La Universidad Católica de Loja - DSPACEdspace.utpl.edu.ec/bitstream/123456789/1009/3/UTPL_Chamba_Jim… · aprendizaje en línea, deja mucho que desear en cuanto a las nuevas tendencias