Memoria 54577

UNIVERSIDAD ALFONSO X EL SABIO
ESCUELA POLITCNICA SUPERIOR

INGENIERA INFORMTICA
PROYECTO FIN DE CARRERA

Aplicacin Android para interactuar con Moodle a travs de servicios web
Abel Fernndez Alfonso Octubre 2010
UNIVERSIDAD ALFONSO X EL SABIO

ESCUELA POLITCNICA SUPERIOR
INGENIERA INFORMTICA
Aplicacin Android para interactuar con Moodle a travs de servicios web

ALUMNO: ABEL FERNNDEZ ALFONSO N.P.: 54577 TUTOR ACADMICO: ISRAEL HERRAIZ FECHA DE PRESENTACIN: OCTUBRE 2010 BREVE DESCRIPCIN: Aplicacin Android que permite consumir las funciones de Moodle a travs de servicios web. Este proyecto es pionero en esta materia, ya que tanto los servicios web de Moodle como las herramientas para poder consumir dichos servicios desde Android estn en los primeros pasos de desarrollo. Esto implica que la documentacin es excasa o inexistente, teniendo que recurrir a tcnicas de ingeniera inversa para poder obtener el funcionamiento de ambas cosas.
FIRMA DEL DIRECTOR DEL PROYECTO
FIRMA DEL ALUMNO
Tabla de contenidos
1. Introduccin...................................................................................................................6 1.1 Antecedentes......................................................................................................7 1.2 Por qu?............................................................................................................7 1.3 Estudio de alternativas.......................................................................................8 1.4 Qu es Android?...............................................................................................9 1.4.1 Caractersticas.............................................................................................9 1.4.2 Arquitectura de Android...........................................................................10 1.4.3 Notas sobre Android.................................................................................11 2. Servicios Web En Android...........................................................................................13 2.1 Por qu REST?....................................................................................................13 2.2 Problemas encontrados.........................................................................................14 3. Organizacin Del Proyecto..........................................................................................16 4. Ingeniera De Software................................................................................................19 1. ESPECIFICACIN DE REQUISITOS..................................................................19 Introduccin...........................................................................................................19 1. Introduccin...................................................................................................19 2. Convenciones del documento........................................................................19 3. Destinatarios y sugerencias de lectura...........................................................20 4. Alcance del proyecto.....................................................................................20 5. Referencias....................................................................................................20 Descripcin general................................................................................................21 1. Perspectiva del producto................................................................................21 2. Caractersticas del producto..........................................................................22 3. Clases de usuario y caracterstica..................................................................23 4. Entorno de funcionamiento...........................................................................26 5. Diseo y aplicacin de RESTricciones.........................................................27 6. Documentos del usuario................................................................................27 7. Dependencias.................................................................................................27 Caractersticas del sistema.....................................................................................28 Caractersticas de interfaz externa..........................................................................31 1. Interfaz de usuario.........................................................................................31 2. Interfaces hardware.......................................................................................32 3. Interfaz de software.......................................................................................34 4. Interfaz de comunicaciones...........................................................................35 2. CASOS DE USO....................................................................................................37 1. Tablas de casos de uso........................................................................................37 1. Tabla caso de uso general..............................................................................37 2. Tabla caso de uso de listar usuarios por id....................................................38 3. Tabla caso de uso de editar usuarios..............................................................39 4. Tabla caso de uso borrar usuarios..................................................................40 5. Tabla caso de uso crear usuario.....................................................................40 2. Diagramas casos de uso.....................................................................................41 1. Diagrama caso de uso general.......................................................................42 2. Diagrama caso de uso de listar usuarios por id.............................................42 3. Diagrama caso de uso editar usuarios...........................................................43 4. Diagrama caso de uso borrar usuarios...........................................................43 5. Diagrama caso de uso crear usuario..............................................................44 3. DIAGRAMAS DE COLABORACIN.................................................................45
1. Diagrama de clases general................................................................................45 2. Diagrama de clases listar usuarios por id...........................................................47 3. Diagrama de clases editar/borrar usuario...........................................................48 4. Diagrama de clases crear usuario.......................................................................49 5. Diagrama de clases llamada a un web service...................................................51 6. Diagrama de clases comprobar pantalla.............................................................52 7. Diagrama de clases pantalla inicial....................................................................52 8. Diagrama de clases modificar preferencias........................................................53 4. DIAGRAMA DE SECUENCIA.............................................................................54 1. Diagrama de secuencia de listar usuarios por id................................................54 2. Diagrama de secuencia de editar usuarios..........................................................55 3. Diagrama de secuencia de crear usuarios...........................................................55 5. Ejemplos De Funcionamiento.....................................................................................57 5.1 Pantalla de bienvenida..........................................................................................57 5.2 Lista de usuarios...................................................................................................57 5.3 Crear nuevos usuarios...........................................................................................59 5.4 Editar un usuario...................................................................................................60 5.5 Eliminacin usuario..............................................................................................60 5.6 Preferencia de usuario...........................................................................................61 6. Futuro Del Proyecto.....................................................................................................63 7. Bibliografa y referencias............................................................................................64 ANEXO I - Documentacin Web Services......................................................................65 Moodle_group_create_groups....................................................................................65 Moodle_group_add_groupmembers...........................................................................67 Moodle_group_delete_groupmembers.......................................................................69 Moodle_group_delete_groups....................................................................................70 Moodle_group_get_course_groups.............................................................................72 Moodle_group_get_groupmembers............................................................................73 Moodle_group_get_groups.........................................................................................75 Moodle_user_create_users..........................................................................................77 Moodle_user_delete_users..........................................................................................80 Moodle_user_update_users.........................................................................................81 Moodle_user_get_users_by_id...................................................................................84 ANEXO II - Funcionamiento De Los Web Services.......................................................88 1. Consumir un webservices.......................................................................................88 2. Almacenar resultados de un webService.................................................................92 ANEXO III Tecnologas Utilizadas..............................................................................98 1. REST.......................................................................................................................98 1.1 Qu es un servicio web?.................................................................................98 1.2 Por qu utilizar REST?...................................................................................98 1.3 Conclusiones..................................................................................................100 2. Token.....................................................................................................................101 2.1 Qu es un token de seguridad?.....................................................................101 2.2 Por qu utilizar token de seguridad?............................................................101 2.2 Conclusiones..................................................................................................104 3. SVN (Subversion).................................................................................................104 3.1 Qu es SVN?................................................................................................104 3.2 Por qu utilizamos SVN?.............................................................................105 3.3 Conclusiones..................................................................................................106
UAX Andriod Moodle
Memoria
1. Introduccin
El proyecto de implementar los servicios web que ofrece Moodle desde Android, es un proyecto de software libre que consiste en poder utilizar y consumir todas las funciones que proporciona Moodle desde un terminal mvil, con los nicos requisitos de tener un Sistema Operativo (SO) basado en Android, con una versin igual o superior a la 1,6 y disponer de acceso a internet, ya sea mediante cobertura wifi o a partir de la cobertura 3G que proporciona el operador telefnico. El principal reto de este proyecto, era dar los primeros pasos en este mundo de los web services en Moodle, ya que estos estn en una versin muy inicial de su desarrollo y todava no hay nada de documentacin sobre este tema. Tmese como ejemplo de la situacin en la que se encuentran el desarrollo de servicios web, que para poder trabajar con estas funciones, ha sido necesario conectarse a la rama de desarrollo y descargarse la ltima versin publicada, es decir, lo que estaban cocinando los desarrolladores de Moodle. Una vez se solvento el principal escoyo de este proyecto, el desarrollo de funcionalidades es ms sencillo, puesto que la estructura modular del proyecto, hace que resulte sencillo poder aadir nuevas funciones o mejorar las ya existentes. Las funciones que se han desarrollado estn orientadas a la gestin de datos personales de los usuarios que existen en Moodle: Listar usuarios existentes en Moodle, filtrando por el id de usuario. Creacin de nuevos usuarios en el portal de enseanza Moodle. Edicin de usuarios existentes, para realizar la edicin de un usuario existente en Moodle, es necesario realizar un listado de los usuarios introduciendo su id. Eliminacin de usuarios, para realizar esta funcin es necesario, como en el caso anterior, realizar un listado de usuarios. La aplicacin tambin permite introducir y modificar el token de usuario, con lo cual, se podr cambiar siempre que lo desee el usuario. Tambin se podr cambiar el host donde se ubica Moodle, estas dos funciones permiten al usuario poder conectarse a diversos portales de Moodle desde su telfono mvil.
UAX Andriod Moodle

1.1 Antecedentes
Memoria
Moodle es una plataforma web para la creacin de cursos y entornos de aprendizaje online que se distribuye como Software Libre (Open Source). Actualmente, Moodle se est convirtiendo en el sistema nmero 1 en el Mundo para la gestin de cursos (Learning Management System - LMS) que ayuda a las organizaciones a crear comunidades de aprendizaje constructivista en lnea. Por estos motivos y debido la necesidad de mejorar el portal de la UAX, es necesario apostar fuerte por Moodle, ya que permite un control mucho ms sencillo de las asignaturas, tanto para alumnos como para profesores. Con este proyecto, se pretende facilitar y familiarizar el uso de la herramienta a todos los usuarios de la aplicacin. Con el objetivo de sentar las bases de un proyecto que permita una utilizacin completa del portal de Moodle desde un telfono mvil.
1.2 Por qu?
Como se ha mencionado en los antecedentes, la plataforma Moodle se est convirtiendo en el sistema nmero 1 en el Mundo para la gestin de cursos. Debido a este rpido crecimiento y la necesidad de actualizar el portal de enseanza de la universidad, es necesario optar por esta herramienta tan flexible como es Moodle, que permite: Adaptar el ritmo de aprendizaje al alumno Brinda diferentes herramientas para la gestin de contenidos de los cursos Prdida de la timidez por parte del alumno Reduccin de costos por curso Flexibilidad en los horarios
Todos estos motivos, unidos al auge de los telfonos mviles que cada vez son ms utilizadas y estn ms aceptadas por la sociedad hacen que este proyecto tome un especial inters ya que trata tecnologas que estn en pleno desarrollo y estn formando las bases de un futuro muy cercano. El mercado de las aplicaciones mviles est todava en la prehistoria. Como en su da pasara con la televisin o despus con Internet, el uso inteligente del mvil cambiar la forma de aprender, comprar y divertirse de los usuarios, dijo Alonso-Cuevillas [Ref1]. En el futuro, est previsto que el gasto en publicidad mvil alcance los 4,5 millones de euros en 2014; los servicios de geo posicionamiento, que generarn unos ingresos de ms de 10.000 millones de euros en 2012; el uso 7
UAX Andriod Moodle
Memoria
de las redes sociales o el mercado de aplicaciones corporativas que gestionan los procesos internos de negocio. As, el mvil ir ganando terreno al ordenador como soporte.
1.3 Estudio de alternativas
La eleccin de Android como SO para el desarrollo de la aplicacin que consume los servicios web de Moodle era uno de los requisitos iniciales, por lo tanto en cuanto a las alternativas que podemos barajar para el desarrollo de este proyecto, se centran en la eleccin del protocolo de comunicacin que vamos a utilizar para consumir las funciones que ofrece Moodle. Entre las alternativas que ofrece Moodle para poder consumir las funciones son XML-RPC, SOAP y REST. XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para codificar los datos y HTTP como protocolo de transmisin de mensajes. Es un protocolo muy simple ya que solo define unos cuantos tipos de datos y comandos tiles, adems de una descripcin completa de corta extensin. La simplicidad del XMLRPC est en contraste con la mayora de protocolos RPC que tiene una documentacin extensa y requiere considerable soporte de software para su uso. Fue creado por Dave Winer de la empresa UserLand Software en asociacin con Microsoft en el ao 1998. Al considerar Microsoft que era muy simple decidi aadirle funcionalidades, tras las cuales, despus de varias etapas de desarrollo, el estndar dej de ser sencillo y se convirti en lo que es actualmente conocido como SOAP. Una diferencia fundamental es que en los procedimientos en SOAP los parmetros tienen nombre y no interesan su orden, no siendo as en XML-RPC. SOAP (siglas de Simple Object Access Protocol) es un protocolo estndar que define cmo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Este protocolo deriva de un protocolo creado por David Winer en 1998, llamado XML-RPC. SOAP fue creado por Microsoft, IBM y otros y est actualmente bajo el auspicio de la W3C. Es uno de los protocolos utilizados en los servicios Web. REST es una tcnica de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web. El trmino se origin en el ao 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificacin del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo. 8
UAX Andriod Moodle
Memoria
Si bien el trmino REST se refera originalmente a un conjunto de principios de arquitectura descritos ms abajo, en la actualidad se usa en el sentido ms amplio para describir cualquier interfaz web simple que utiliza XML y HTTP, sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes como el protocolo de servicios web SOAP. Es posible disear sistemas de servicios web de acuerdo con el estilo arquitectural REST de Fielding y tambin es posible disear interfaces XMLHTTP de acuerdo con el estilo de llamada a procedimiento remoto pero sin usar SOAP. Estos dos usos diferentes del trmino REST causan cierta confusin en las discusiones tcnicas, aunque RPC no es un ejemplo de REST.
1.4 Qu es Android?
Android en un Sistema Operativo adems de una plataforma de Software basada en el ncleo de Linux. Diseada en un principio para dispositivos mviles, Android permite controlar dispositivos por medio de bibliotecas desarrolladlas o adaptados por Google mediante el lenguaje de programacin JAVA. Android es una plataforma de cdigo abierto. Esto quiere decir, que cualquier desarrollador puede crear y desarrollar aplicaciones escritas con lenguaje C u otros lenguajes y compilarlas a cdigo nativo de ARM (API de Android). Inicialmente, Android fue desarrollada por Google Inc. aunque poco despus se uni Open Handset Alliance, un consorcio de 48 compaas de Hardware, Software y telecomunicaciones, las cuales llegaron a un acuerdo para promocionar los estndares de cdigos abiertos para dispositivos mviles. Google sin embargo, ha sido quien ha publicado la mayora del cdigo fuente de Android bajo la licencia de Software Apache, una licencia de software libre y de cdigo abierto a cualquier desarrollador. [Ref2]
1.4.1 Caractersticas
Framework de aplicaciones: permite el reemplazo y la reutilizacin de los componentes. Navegador integrado: basado en el motor open Source Webkit. SQlite: base de datos para almacenamiento estructurado que se integra directamente con las aplicaciones. 9
UAX Andriod Moodle
Memoria
Multimedia: Soporte para medios con formatos comunes de audio, video e imgenes planas (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF).
Mquina virtual Dalvik: Base de llamadas de instancias muy similar a JAVA. Telefona GSM: dependiente del terminal. Bluetooth, EDGE, 3g y Wifi: dependiente del terminal. Cmara, GPS, brjula y acelermetro: Dependiente del terminal Pantalla Tctil.
1.4.2 Arquitectura de Android
La arquitectura interna de la plataforma Android, est bsicamente formada por 4 componentes:
APLICACIONES: Todas las aplicaciones creadas con la plataforma Android, incluirn como base
1 Imgen extrada de HTTP://www2.configurarequipos.com/imgdocumentos/android/android-aplicaciones.jpg
10
UAX Andriod Moodle
Memoria
un cliente de email (correo electrnico), calendario, programa de SMS, mapas, navegador, contactos, y algunos otros servicios mnimos. Todas ellas escritas en el lenguaje de programacin JAVA. FRAMEWORK DE APLICACIONES: Todos los desarrolladores de aplicaciones Android, tienen acceso total al cdigo fuente usado en las aplicaciones base. Esto ha sido diseado de esta forma, para que no se generen cientos de componentes de aplicaciones distintas, que respondan a la misma accin, dando la posibilidad de que los programas sean modificados o reemplazados por cualquier usuario sin tener que empezar a programar sus aplicaciones desde el principio. LIBRERIAS: Android incluye en su base de datos un set de bibliotecas C/C++, que son expuestas a todos los desarrolladores a travs del framework de las aplicaciones Android System C library, bibliotecas de medios, bibliotecas de grficos, 3D, SQlite, etc. RUNTIME DE ANDROID: Android incorpora un set de bibliotecas que aportan la mayor parte de las funcionalidades disponibles en las bibliotecas base del lenguaje de programacin JAVA. La Mquina Virtual est basada en registros, y corre clases compiladas por el compilador de JAVA que anteriormente han sido transformadas al formato .dex (Dalvik Executable) por la herramienta ''dx''.
1.4.3 Notas sobre Android
Android podra ser una competencia directa a los sistemas operativos mviles como Windows Mobile, Symbian, iPhone OS 3.0, etc. aunque tambin podra aminorizar o reducir la situacin actual de Microsoft y sus Sistemas Operativos Windows. Por qu digo esto? HP Inc. uno de los gigantes en la fabricacin y desarrollo de Ordenadores ms importantes del mundo, ha declarado que se estn planteando la implantacin del Sistema Operativo Android en Ultraporttiles o Netbooks, adems, se habla de que pronto podremos ver un PC de sobremesa con Android de manos de HP. La posibilidad de que esto ocurra, depende de los resultados que obtengan en las pruebas de rendimiento y pRESTaciones de Android en estos equipos.
11
UAX Andriod Moodle
Memoria
2 Imgen extrada de HTTP://www2.configurarequipos.com/imgdocumentos/android/htc-magic-vodafone.jpg
12
UAX Andriod Moodle
Memoria
2. Servicios Web En Android

Un servicio web es un conjunto de protocolos y estndares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programacin diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopcin de estndares abiertos. Las organizaciones OASIS y W3C son los comits responsables de la arquitectura y reglamentacin de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WSI, encargado de desarrollar diversos perfiles para definir de manera ms exhaustiva estos estndares. Un web service en Android es muy similar a la implementacin de cualquier otro web service desde JAVA, ya que las herramientas que se utilizan en Android son muy similares a las de JAVA. Pero la implementacin de web services en Android tiene ciertas limitaciones, porque las clases compiladas que se utilizan en JAVA para consumir las diferentes funciones estn compiladas para la mquina virtual de JAVA y puede que no funcionen para la mquina virtual de Android (Dalvik).
2.1 Por qu REST?

En este punto justificaremos la eleccin del protocolo REST para la comunicacin con las funciones que proporciona el Moodle.
3 Imgen extrada de HTTP://dotnetslackers.com/Community/blogs/xun/REST.jpg
13
UAX Andriod Moodle Ventajas de REST:
Memoria
Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la informacin necesaria para comprender la peticin. Como resultado, ni el cliente ni el servidor necesitan recordar ningn estado de las comunicaciones entre mensajes. Sin embargo, en la prctica, muchas aplicaciones basadas en HTTP utilizan cookies y otros mecanismos para mantener el estado de la sesin (algunas de estas prcticas, como la reescritura de URLs, no son permitidas por REST) Un conjunto de operaciones bien definidas que se aplican a todos los recursos de informacin: HTTP en s define un conjunto pequeo de operaciones, las ms importantes son POST, GET, PUT y DELETE. Con frecuencia estas operaciones se equiparan a las operaciones CRUD que se requieren para la persistencia de datos, aunque POST no encaja exactamente en este esquema. Una sintaxis universal para identificar los recursos. En un sistema REST, cada recurso es direccionable nicamente a travs de su URI. El uso de hipermedios, tanto para la informacin de la aplicacin como para las transiciones de estado de la aplicacin: la representacin de este estado en un sistema REST son tpicamente HTML o XML. Como resultado de esto, es posible navegar de un recurso REST a muchos otros, simplemente siguiendo enlaces sin requerir el uso de registros u otra infraestructura adicional.
2.2 Problemas encontrados

Uno de los principales problemas que nos hemos encontrado a la hora de realizar la implementacin de las funciones que consuman las funciones de Moodle es la escasa o inexistente documentacin sobre este tema. Esta falta de documentacin es debido a que el desarrollo de los web services se encuentra en un estado muy inicial. Un ejemplo de este temprano desarrollo es que la versin de Moodle que hemos utilizado para el desarrollo de la aplicacin Moodle es la versin en desarrollo directamente, ya que todava no se ha publicado ninguna versin oficial que soporten los web services, un ejemplo de esto es que el web service para eliminar un usuario, todava no funciona de manera correcta y no elimina el usuario que se ha seleccionado.
14
UAX Andriod Moodle
Memoria
Otro problema que ha surgido durante el desarrollo, es que las clases compiladas para poder
consumir los web services o para des-serializar los resultados que devuelve el Moodle no funcionan para la mquina virtual de Android (Dalvik). La solucin para este problema ha sido descargarse las clases JAVA de los paquetes que necesitbamos e incluirlas en los proyectos para poder volver a compilarlas y hacer que funcionen en la mquina virtual de Android.
4 Imgen extrada de HTTP://www.w3.org/2005/Talks/1114-hh-ecows/web_service1.png
15
UAX Andriod Moodle
Memoria
3. Organizacin Del Proyecto

Una de las partes ms importantes de cualquier proyecto es la organizacin, ya que hay que llevar un control de todos los cambios que se realizan, del punto en el que se encuentra el desarrollo del proyecto, un histrico con todas las versiones que hemos liberado... Como este es proyecto de software libre y tiene como finalidad formar las bases de un gran proyecto que consuma las funciones de Moodle mediante servicios web, el software que se ha elegido para poder llevar la organizacin de este proyecto es mediante la herramienta Google Code. Google Code entre sus numerosas bondades, destaca es que es abierta para cualquier persona, es decir el cdigo de este proyecto es accesible para cualquier persona de la red que est interesada en este tema. Google Code es una web de la compaa Google que permite llevar a cabo un control de software de los desarrollos software. La web contiene cdigo-fuente abierto y una lista de servicios que soportan la API pblica del Google. Adems de estas funciones, se eligi Google Code como herramienta, porque permita llevar un control de versiones, ya que Google Code tambin es un proyecto de hospedaje de desarrollo de software que suministra sistema de control de versin usando Subversion, sistema de "Issue", un wiki para documentacin y 100MB para download. Este servicio no necesita de la aprobacin de los proyectos por el Google. Google code ofrece a los desarrolladores diferentes reas en las que alojar cdigo, manuales y documentacin de su software. En la ventana de bienvenida de Moodle, podremos encontrar una pequea descripcin del proyecto que estamos consultando:
16
UAX Andriod Moodle
Memoria
En la imagen anterior se pueden observar las diferentes pestaas que tienen Downloads, Wiki, Issues, Source y Administer. Como este proyecto golpe code se ha utilizado como una herramienta para gestionar el control de versiones de la aplicacin, la parte que ms he utilizado ha sido Source, ya que me ha permitido almacenar todos los avances con el cdigo que he ido realizando, y si en algn momento me equivocaba o quera volver a algn estado anterior, slo tena que sustituir por el ms reciente. Adems, eclipse, con sus plugins de svn, como subversion, permiten llevar un excelente control de versiones de la aplicacin.
17
UAX Andriod Moodle
Memoria
Subversion es un sistema de control de versiones diseado especficamente para reemplazar al popular CVS, el cual posee varias deficiencias. Es software libre bajo una licencia de tipo Apache/BSD y se le conoce tambin como svn por ser el nombre de la herramienta utilizada en la lnea de comandos. Una caracterstica importante de Subversion es que, a diferencia de CVS, los archivos versionados no tienen cada uno un nmero de revisin independiente, en cambio, todo el repositorio tiene un nico nmero de versin que identifica un estado comn de todos los archivos del repositorio en un instante determinado. Subversion puede acceder al repositorio a travs de redes, lo que le permite ser usado por personas que se encuentran en distintos ordenadores. A cierto nivel, la posibilidad de que varias personas puedan modificar y administrar el mismo conjunto de datos desde sus respectivas ubicaciones fomenta la colaboracin. Se puede progresar ms rpidamente sin un nico conducto por el cual deban pasar todas las modificaciones. Y puesto que el trabajo se encuentra bajo el control de versiones, no hay razn para temer por que la calidad del mismo vaya a verse afectada si se ha hecho un cambio incorrecto a los datos, simplemente deshaga ese cambio. El proyecto se puede encontrar en esta direccin HTTP://code.google.com/p/moodleuax/.
18
UAX Andriod Moodle
Memoria
4. Ingeniera De Software
1. ESPECIFICACIN DE REQUISITOS
Introduccin 1. Introduccin
Esta especificacin de requisitos es una primera versin de la aplicacin que permite conectarse de manera remota desde terminales Android con cualquier portal de Moodle. El portal de Moodle debe ser una versin superior a la 1,9. Puesto que versiones anteriores no tienen implementado la funcionalidad de los servicios web. Este documento pretende analizar y detallar todas las especificaciones de requisitos que se ponen en prctica en la aplicacin desarrollada. Por lo tanto lo que se pretende analizar son las funciones de listas usuarios por id, crear un nuevo usuario, editar un usuario ya existente o eliminar un usuario ya existente. As mismo, tambin se permite la posibilidad al usuario de poder cambiar la ubicacin de Moodle y del token con el que se conecta al Moodle.
2. Convenciones del documento
Las convenciones que se han seguido para desarrollar tanto el documento como la aplicacin son por un lado, las convenciones que marca JAVA para el desarrollo de aplicaciones en JAVA, ya que aunque es un producto Android, se programa en JAVA y para la realizacin de este documento se ha intentado seguir las convenciones de UML. Los motivos por los que se siguen las Code Convitions en JAVA son los siguientes: No dedicarnos el 80% del tiempo de vida del Sofware en darle mantenimiento. Rara vez el Software es mantenido por la misma persona que lo creo. Las Code Convitions mejoran la lectura de las lneas de cdigo. Muchas veces el producto se vende con el cdigo fuente y el seguir las Code Convitions le dan un valor agregado al producto. Los motivos por los que se ha utilizado Code Convitions para la especificacin de requisitos son muy similares a los que se han detallado para el desarrollo en JAVA. 19
UAX Andriod Moodle

[Ref3]: HTTP://www.oracle.com/technetwork/JAVA/codeconvtoc-136057.html
Memoria
3. Destinatarios y sugerencias de lectura
Este documento est destinado a desarrolladores que se planteen la idea de poder ampliar el desarrollo de los servicios web para la utilizacin de Moodle, ya que en este proyecto, lo que se pretenda era la idea de aprender a consumir los servicios web que brindaba Moodle. Para todo aquel usuario que est interesado es poder continuar con este proyecto, las lecturas obligatorias son los puntos 3 (Clases de usuario y caractersticas) y 4 (Entorno de funcionamiento) de 2. Descripcin general. En estos puntos se describe y se explica lo que realizan las clases del programa. Tambin es recomendable la lectura del punto 3. Caractersticas del sistema, pues en l, como su ttulo indica, se describen las caractersticas del sistema.
4. Alcance del proyecto
Como se ha comentado en el punto anterior, el principal objetivo de este proyecto era iniciarse en el mundo de la comunicacin va servicios web entre Android y Moodle. Esta parte ha tenido bastante dificultad por varios motivos, el principal motivo es que los servicios web que Moodle proporciona estn en una fase inicial de su desarrollo. Esto tiene varias desventajas, la principal desventaja es que la documentacin de cmo utilizar estos web services es inexistente, tambin como son servicios experimentales, no funcionan como deberan funcionar, hay algunos errores. Otro de los problemas a los que nos hemos tenido que enfrentar es a como consumir los web services desde Android. En esta ocasin los problemas se han multiplicado, porque adems de que no sabamos cmo poder consumir un web service, las clases compiladas para la mquina virtual de JAVA, no funcionaban para la mquina virtual de Android. Por todo lo dicho anteriormente, este proyecto es el primer paso para poder desarrollar una aplicacin completa, que permita tanto a alumnos como a profesores, poder hacer un uso completo de la herramienta Moodle desde cualquier lugar. El nico requisito es tener un telfono con Android y la posibilidad de tener conexin con internet, ya sea tarifa de datos o mediante cobertura Wi-fi.
5. Referencias
A continuacin se mostrar las referencias que nombramos o hemos utilizado para la construccin tanto de este documento, como para el desarrollo de la aplicacin. 1. Convenciones JAVA para el desarrollo y mantenimiento de la aplicacin 20
UAX Andriod Moodle HTTP://www.oracle.com/technetwork/JAVA/codeconvtoc-136057.html
Memoria
2. Api para la puesta en marcha del entorno de desarrollo y lugar de referencia para comenzar el desarrollo en Android: HTTP://developer.android.com/index.html 3. Api de JAVA: HTTP://download.oracle.com/JAVAse/1.5.0/docs/api/ 4. Des-serializacin de objetos: HTTP://xstream.codehaus.org/ 5. Documentacin y descarga de la aplicacin Moodle: HTTP://Moodle.org/
Descripcin general 1. Perspectiva del producto
Esta aplicacin es el primer paso de un gran proyecto. Decimos que es el primer paso, porque en esta aplicacin se describe cmo se pueden consumir los servicios web que proporciona Moodle desde Android. A partir de este proyecto, ya se podrn desarrollar con mayor facilidad el RESTo de servicios que proporcione Android. Este proyecto ha sido desarrollado de forma modular, de manera que sea muy sencillo la implementacin de un nuevo servicio web. Se ha intentado mantener la misma estructura de datos que tiene Moodle, para facilitarla implementacin de las funciones a los futuros desarrolladores.
21
UAX Andriod Moodle

2. Caractersticas del producto
Memoria
La principal caracterstica de esta aplicacin es que permite consumir mediante web service las funciones que proporciona Moodle. Esta parte era la ms difcil y costosa de este proyecto, como ya se ha mencionado en los puntos anteriores, la documentacin para utilizar dichos web services era escasa o inexistente. Una prueba ms de que estamos en los albores de la comunicacin utilizando servicios web de funciones de Moodle, es que la versin de Moodle que hemos utilizado para implementar los web services es una versin beta de desarrollo. Adems de iniciar la comunicacin mediante servicios web, esta aplicacin permite al usuario realizar varias funciones de Moodle. Las funciones que permite utilizar son las siguientes: 1. Permite listar usuarios existentes en Moodle introduciendo su id. 2. Crear nuevos usuarios en Moodle 3. Editar usuarios existentes ya en Moodle, para ello es necesario hacer un listado previo de los usuarios. 4. Eliminar un usuario existente en Android. 5. Cambiar el token de usuario. 6. Cambiar la direccin donde se encuentra ubicado el Moodle. En el siguiente diagrama de paquetes, podemos observar cmo se relacionan las clases desde una visin superior.
22
UAX Andriod Moodle
Memoria
3. Clases de usuario y caracterstica
Las clases de usuario se han dividido en tres paquetes de clases, cada clase se dedica a una cosa especfica. Un paquete tendr las clases que se encargan de obtener los datos de la pantalla, comprobar que el usuario introduce los datos correctos para poder enviarlos al servidor de Moodle, de formar el modelo de datos... Como se puede comprobar se ha intentado seguir un modelo de capas de negocio. Se ha optado por este modelo para poder llevar a cabo el desarrollo en varios niveles. Por ello, los tres paquetes de clases que se han definido son las siguientes:
23
UAX Andriod Moodle conv.android.Moodle (capa de negocio)
Memoria
Este paquete es donde se encuentran las clases que se encargan de obtener los datos que el usuario introduce por pantalla, comprobar que los datos son correctos, realizar las llamadas a los web services...
fac.android.Moodle (capa de datos) Aqu se alojan las clases que se utilizan para almacenar los datos, la clase de datos de usuario, de error... con todos los setters y los getters
uax.android.Moodle (capa de presentacin) Se encuentran las clases que se encargan de mostrar por pantalla los datos y recogerlos y pasarlos a las otras clases.
24
UAX Andriod Moodle Dentro de cada uno de los paquetes se encuentran las siguientes clases: conv.android.Moodle CallWebService.JAVA
Memoria
Se encarga de realizar la comunicacin con el servidor de Moodle. Recibe los datos necesarios para poder llamar a la operacin que se quiere consumir y una vez realizada la llamada, permanece a la espera para recoger el mensaje y devolverlo. CheckScreen.JAVA Esta clase se encarga de comprobar que los datos que el usuario ha introducido por pantalla son correctos y los acepta las funciones de Moodle que se quieren consumir. ErrorConverter.JAVA Cuando alguna funcin de Moodle que se quiere consumir devuelve como respuesta un error, esta clase se encarga de obtener el mensaje de error que se producido y lo devuelve. MyUserConverter.JAVA Esta funcin se encarga de des-serializar el XML que devuelve el Moodle cuando realizamos la consumicin de una funcin que devuelve un usuario como respuesta. Una vez des-serializado el objeto, este objeto se podr utilizar en toda la aplicacin. ScreenMoodle.JAVA Recoge todos los datos que el usuario ha introducido por pantalla y lo formatea de manera correcta para poder pasarlos como parmetros a las funciones de Moodle. fac.android.Moodle En esta clase se encuentran alojadas todas las clases para poder formar el modelo de datos de la aplicacin. uax.android.Moodle AndroidSplash.JAVA Esta clase se encarga de mostrar la pantalla de bienvenida a la aplicacin,
25
UAX Andriod Moodle Preferences.JAVA
Memoria
Se encarga de mostrar los datos de los usuarios, estos datos por el momento sern el token de usuario y el host donde se encuentra ubicado Moodle. UserCreate.JAVA Esta clase se encarga de mostrar la ventana de creacin de usuarios. Tambin se encargar de obtener todos los datos que el usuario introduce por pantalla y pasrselos a la clase que se encarga de llamar a los web services y en caso de producirse un error, lo mostrar por pantalla. UserEdit.JAVA Esta clase es la encargada de mostrar el usuario seleccionado por la persona que est manejando la aplicacin. Adems esta clase tambin se encarga de recoger los datos que el usuario introduce por pantalla para realizar la modificacin. Tambin se encarga de pasar los datos a la clase que se encarga de llamar a los web services y en caso de producirse un error, lo mostrar por pantalla. UserMenu.JAVA Esta clase se encarga de mostrar la pantalla que permite al usuario poder realizar la bsqueda de usuarios por id. Tambin mostrar la lista de usuarios que se obtiene despus de una consulta. A partir de esta clase podemos navegar al RESTo de clases que forman la aplicacin.
4. Entorno de funcionamiento
El entorno de funcionamiento de esta aplicacin est bastante claro y definido, como es una aplicacin desarrollada para Android, esta aplicacin tendr como entorno de funcionamiento el SO Android. Android es una variante de Linux orientada a dispositivos mviles. Es desarrollado por la Open Handset Alliance, que aglutina a fabricantes de software y hardware, entre los que destacan Google, T-Mobile, HTC, Qualcomm y Motorola entre otros.
26
UAX Andriod Moodle
Memoria
Para poder utilizar esta herramienta, es necesario tener una cuenta de Moodle y que la versin de Moodle sea la 2.0 o superior, porque a partir de esa versin es cuando se comienza a desarrollar los servicios web. La aplicacin ha sido desarrollada para la versin 1.6 del Sistema Operativo Android, por lo tanto este software es compatible con las versiones superiores de Android.
5. Diseo y aplicacin de RESTricciones
Este es un proyecto de software libre que se encuentra ubicado en un repositorio svn de google, que es accesible a cualquier desarrollador. Por lo tanto las nicas RESTricciones a la hora de desarrollar, que tiene esta aplicacin son las impuestas por las limitaciones de los servicios web que han sido desarrollados para la herramienta de Moodle.
6. Documentos del usuario
Como documentos de usuario que se entregarn en esta documentacin se podrn obtener en los anexos. Entre ellos se puede ver un manual de usuario, en el que se podr obtener un primer contacto con la aplicacin. Adems en el RESTo de anexos se podr obtener una documentacin ampliada sobre las tecnologas que se han utilizado para el desarrollo de la aplicacin.
7. Dependencias
Como se puede observar, este proyecto depende totalmente de las funciones que Moodle ofrezca como servicio web. Actualmente la versin de Moodle que ofrece los servicios web es una versin
5 Imgen extrada de HTTP://www.celularis.com/wp-content/uploads/2008/09/android_logo.jpg
27
UAX Andriod Moodle de desarrollo, por lo tanto es una versin en fase beta en la que se pueden encontrar fallos. Tambin tenemos la dependencia del api de Android y de las funciones que pueda ofrecer.
Caractersticas del sistema
Memoria
En este punto se mostrarn las caractersticas principales del sistema, as como los principales servicios que puede ofrecer este producto. RPU001 Descripcin Transacciones seguras Todo intercambio de datos que se realiza entre la aplicacin y el sistema deber ser seguro y estar protegido contra posibles ataques, de manera que un usuario no autorizado no pueda acceder al sistema ni interceptar datos que se enven del sistema a la aplicacin y viceversa ALTA
Prioridad
Secuencia de respuesta Requisitos funcionales -
RPU002 Descripcin
Listado de usuarios por ID La aplicacin permite consultar los datos de los usuarios, en concreto, nombre, apellidos, direccin, correo electrnico Esto se realiza mediante una bsqueda de usuarios introduciendo su id. ALTA 1. Usuario introduce los id que quiere buscar 2. Si los ids existen en Moodle, se muestra una lista con los usuarios que se han buscado. 3. Si no existen, no se muestran en la lista. 4. Si no existiera ninguno de los usuarios, no se mostrara ninguna lista. 5. Si se produce algn error a la hora de consumir algn servicio, se mostrar por pantalla.
Prioridad Secuencia de respuesta
Requisitos funcionales REQ-1. El usuario debe tener una cuenta en Moodle y debe conocer su token. REQ-2. El usuario debe conocer el host donde se encuentra ubicada la aplicacin de Moodle. REQ-3. Previamente, debe introducir en las preferencias el token de Moodle y el host donde se encuentra ubicada la aplicacin de Moodle.
RPU003
Editar usuarios 28
UAX Andriod Moodle Descripcin Prioridad Secuencia de respuesta La aplicacin permite realizar la modificacin de los datos de los usuarios. En concreto, nombre, apellidos y correo electrnico. ALTA
Memoria
1. El usuario debe realizar un listado de usuarios por id 2. Seleccionar el usuario que se quiera modificar de la lista que se ha devuelto anteriormente 3. Modificar los campos que se desee 4. Enviar la informacin al Moodle 5. Si los datos son correctos se volver a la pantalla inicial 6. Si se produce algn error, se mostrar en la pantalla de edicin
Requisitos funcionales REQ-1. El usuario debe tener una cuenta en Moodle y debe conocer su token. REQ-2. El usuario debe conocer el host donde se encuentra ubicada la aplicacin de Moodle. REQ-3. Previamente, debe introducir en las preferencias el token de Moodle y el host donde se encuentra ubicada la aplicacin de Moodle. REQ-4. Se debe realizar un listado de usuarios por id, y que esa funcin devuelva datos correctos REQ-5. El usuario que se quiere editar debe existir en Moodle
RPU004 Descripcin Prioridad Secuencia de respuesta
Borrar usuarios La aplicacin permite realizar la eliminacin de un usuario existente en Moodle. ALTA 1. El usuario debe realizar un listado de usuarios por id 2. Seleccionar el usuario que se quiera eliminar de la lista que se ha devuelto anteriormente 3. Borrar el usuario 4. Enviar la informacin al Moodle 5. Si los datos son correctos se volver a la pantalla inicial 6. Si se produce algn error, se mostrar en la pantalla de borrado
Requisitos funcionales REQ-1. El usuario debe tener una cuenta en Moodle y debe conocer su token. REQ-2. El usuario debe conocer el host donde se encuentra ubicada la aplicacin de Moodle. REQ-3. Previamente, debe introducir en las preferencias el token de Moodle y el host donde se encuentra ubicada la aplicacin de Moodle. REQ-4. Se debe realizar un listado de usuarios por id, y que esa funcin devuelva datos correctos REQ-5. El usuario que se quiere eliminar debe existir en Moodle
29
UAX Andriod Moodle
Memoria
RPU005 Descripcin
Crear Usuarios La aplicacin permitir la creacin de nuevos usuarios en el Moodle. Para la creacin de un usuario se deben introducir los datos bsicos, nombre, apellidos, correo electrnico y contrasea ALTA 1. Rellenar todos los campos para la creacin de un usuario (nombre, apellidos, correo electrnico y contrasea) 2. Enviar la informacin a Moodle 3. Si los datos son correctos la aplicacin ir a la pantalla principal. 4. Si se produce algn error se mostrar por pantalla.
Requisitos funcionales REQ-1. El usuario debe tener una cuenta en Moodle y debe conocer su token. REQ-2. El usuario debe conocer el host donde se encuentra ubicada la aplicacin de Moodle. REQ-3. Previamente, debe introducir en las preferencias el token de Moodle y el host donde se encuentra ubicada la aplicacin de Moodle. REQ-4. El usuario no debe existir previamente en Moodle
RPU005 Descripcin
Introducir/Editar token usuario La aplicacin les dar la oportunidad a los usuarios de poder introducir o modificar el token de usuario, esto permite que varios usuarios se conecten a su cuenta utilizando la misma aplicacin. ALTA 1. Introducir el token de usuario 2. Guardar el token de usuario en la aplicacin
Requisitos funcionales REQ-1. El usuario debe tener una cuenta en Moodle y debe conocer su token.
RPU005 Descripcin
Introducir/Editar host de Moodle La aplicacin permitir poder conectarse a diversos Moodle, Para ello slo ser necesario cambiar el host al que se est conectando la aplicacin. ALTA 1. Introducir host donde se ubica el Moodle 2. Guardar el nuevo host.
Requisitos funcionales REQ-1. El usuario debe conocer el host donde se encuentra ubicada la aplicacin de Moodle.
30
UAX Andriod Moodle

Caractersticas de interfaz externa 1. Interfaz de usuario
Memoria
Una de las cosas ms interesantes que tiene Android (bajo mi punto de vista, claro est), es la creacin de interfaces de usuario. Android nos ofrece la posibilidad de crear la fachada de la aplicacin mediante ficheros XML. De esta forma, nos podemos concentrar en el aspecto funcional de la aplicacin (cdigo JAVA) o puramente esttico (XML). Tambin podramos generar la interfaz mediante cdigo JAVA, pero queda mucho ms esttico y ordenado usando lo que Android nos ofrece. Una aplicacin recin creada, contendr las carpetas drawable, layout y values. Nos vamos a centrar en la carpeta layout. Si nos aventuramos y vemos que contiene esta carpeta, podemos ver que Eclipse nos ha generado un fichero main.XML. Este fichero contiene una vista simple, un contenedor (Layout) y una vista (View) simple que contiene una cadena de texto tipo Hola Mundo. Esta vista se mostrar en la pantalla en cuanto arranquemos la aplicacin.
<?XML version=1.0 encoding=utf-8?> <LinearLayout XMLns:android=HTTP://schemas.android.com/apk/res/android android:orientation=vertical android:layout_width=fill_parent android:layout_height=fill_parent > <TextView android:layout_width=fill_parent android:layout_height=wrap_content android:text=@string/hello /> </LinearLayout>
Esta es la forma de cualquier vista en Android. Tendremos un rbol de Layouts y de Widgets anidados con tags propios y multitud de atributos, de esta forma se usa toda la potencia de XML. A continuacin mostramos varios ejemplos de interfaz grfica en Android:
31
UAX Andriod Moodle
Memoria
[Ref4]
2. Interfaces hardware
Esta es una aplicacin desarrollada para el sistema operativo mvil Android. Por lo tanto cualquier dispositivo que tenga instalado Android podr hacer uso de esta herramienta, las nicas limitaciones que tenemos es que necesitamos tener acceso a internet, ya sea mediante la red 3G de nuestro operador telefnico o mediante un red wifi. No obstante, a continuacin mostraremos las especificaciones hardware de varios telfonos mviles que tienen como sistema operativo Android. El telfono que analizaremos ser el Samsung I5700 Galaxy Spica, porque ha sido el telfono utilizado para realizar las pruebas. Samsung I5700 Galaxy Spica
6 Imagen extrada de HTTP://developer.android.com/resources/tutorials/views/index.html
32
UAX Andriod Moodle
Memoria
Plataforma
Chrome-Lite MIDP 2.0, CLDC 1.1 (JSR 30, JSR 37, JSR 75, JSR 118, JSR 120, JAVA JSR 135, JSR 139, JSR 184, JSR 185) Valor SAR 0,595 Peso 124gr. Tamao y Dimensiones Dimensiones 115 x 57 x 13,2mm (AlXAnXProf) Resolucin 3,2" Pantalla Externa Tamao 3,2" Tiempo en 2,5G: hasta 710min, 3G: conversacin hasta 410min Batera Estndar 2,5G: hasta 650h, 3G: hasta Standby 580h Interfaz de usuario Dispositivos de entrada pantalla totalmente tctil Resolucin de la cmara 3megapxeles Cmara Autoenfoque S Brillo Auto Reproductor de vdeo 3GP / MP4 Vdeo Grabador de vdeo 3GP (MPEG4 + AMR-nb) Flujo de vdeo S Msica y Sonido Reproductor de msica MP3 / AMR / AAC / AAC+ / e-AAC+ Politonos S Tonos MP3 S DRM OMA DRM v1.0 FL 33
Sistema Operativo Browser
Android
UAX Andriod Moodle Discoteca Personalizada S Entretenimiento y Personalizacin Trabajo y oficina Fondo incorporado S
Memoria
Modalidad de desconexin S SMS / EMS / MMS S Entrada predictiva de S texto T9 Mensajes E-mail S vCard / vCalendar S Mensajes al instante Google Talk (MSN de bolsillo) Bluetooth V.2.1 USB V.2.0 Conectividad Navegador HTML Chrome-Lite WIFI 802.11b/g Memoria de usuario 200MB SMS Up to available memory Memoria Agenda de contactos Up to available memory Memoria externa MicroSD Calendario S Reloj S Gestin de informacin Alarma S personal Calculadora S Bloc de notas S Altavoz S Identificacin de la S persona que llama (vdeo) Funciones de llamada Llamadas en grupo S Nmeros marcados / llamadas perdidas / S llamadas recibidas PRESTaciones Especiales Pantalla tctil pantalla totalmente tctil [Ref5]
3. Interfaz de software
En este punto analizaremos las conexiones entre esta aplicacin y el RESTo de componentes del sistema, como puede ser la plataforma Moodle o las herramientas utilizadas para poder tratar la informacin de los usuarios. En primer lugar vamos a destacar que para poder consumir las funciones que nos ofrece Moodle 34
UAX Andriod Moodle
Memoria
hemos tenido que implementar las funciones mediante servicios web. Moodle ofrece tres opciones para utilizar los servicios web, XML-RPC, SOAP o REST. Nosotros para desarrollar la aplicacin hemos optado por utilizar la tecnologa REST de los web services, REST es una tcnica de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web. Una vez que realizamos una llamada correcta a una funcin de Moodle, esta nos devuelve una serie de datos que tenemos que interpretar. Interpretar estos datos es des-serializar la respuesta que nos devuelve Moodle y convertirlo en un objeto que pueda ser utilizado por el RESTo de la aplicacin. Para poder des-serializar el objeto hemos optado por utilizar Xstream, que nos permite tener las siguientes ventajas: Persistencia basada en XML, o sea texto plano: legible y editable. No hace falta modificar tus objetos a serializar (ni siquiera tienen que implementar JAVA.io.Serializable) No requiere mapeos (como otros motores de persistencia basado en XML, como Castor) Si recompilas tu objeto a escribir, o incluso si modificas sus atributos, el XML grabado seguir siendo vlido (aunque puedes perder informacin si cambias el nombre de un atributo, siempre puedes editar el XML!) Controla referencias circulares. Es decir, es posible serializar un objeto con un atributo que es una referencia a s mismo. Se puede encontrar mucha ms informacin ampliada sobre las tecnologas utilizadas en este proyecto en el anexo Tecnologas utilizadas.
4. Interfaz de comunicaciones
Como ya hemos comentado en los puntos anteriores, la comunicacin a travs de internet es un requisito para poder utilizar la aplicacin, ya que esta aplicacin se basa en los servicios web que ofrece Moodle. Un servicio web (en ingls, Web service) es un conjunto de protocolos y estndares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programacin diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios
35
UAX Andriod Moodle
Memoria
web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopcin de estndares abiertos. Las organizaciones OASIS y W3C son los comits responsables de la arquitectura y reglamentacin de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WSI, encargado de desarrollar diversos perfiles para definir de manera ms exhaustiva estos estndares.
36
UAX Andriod Moodle
Memoria
2. CASOS DE USO
El Lenguaje de Modelado Unificado define una notacin grfica para representar casos de uso llamada modelo de casos de uso. UML no define estndares para que el formato escrito describa los casos de uso, y as mucha gente no entiende que esta notacin grfica define la naturaleza de un caso de uso; sin embargo una notacin grfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos estn relacionados, los casos de uso son mucho ms detallados que los diagramas de casos de uso.
1. Tablas de casos de uso
En primer lugar mostraremos las tablas de los casos de uso que hemos diseado, para que una vez mostradas todos los posibles valores y casusticas que se pueden dar en la aplicacin, mostrar los diagramas para ver los casos de uso de una manera ms clara.
1. Tabla caso de uso general
Nombre Actor principal Actor secundario Objetivo en contexto Precondiciones
Caso de uso general Usuario Moodle Mostrar una visin global de todas las acciones que se pueden realizar mediante esta aplicacin El usuario debe tener una cuenta en Moodle, adems debe poder conectarse a la red, ya sea mediante cobertura Wi-fi o mediante la red 3G del proveedor telefnico Cuando se comience a utilizarse este caso de uso, comenzaremos a utilizar la aplicacin 1. El usuario podr realizar la accin de listar usuarios por Id, esta accin es primordial para poder editar o borrar usuarios 2. El usuario podr crear nuevos usuarios 3. Podr editar/borrar usuarios ya existentes en Moodle 4. Podr cambiar el token y el host de Moodle 5. Como se puede observar, tanto listar, como crear, editar o borrar, tambin tienen una relacin con Moodle, ya que son funciones que consumimos mediante un web service En el caso de que el usuario introduzca datos no vlidos 37
Disparadores Escenario
Excepciones
UAX Andriod Moodle
Memoria en la aplicacin se mostrar el mensaje de error comunicando al usuario que se ha producido una excepcin. Tambin se mostrarn las excepciones que devuelva Moodle, para tener informado al usuario en todo momento.
Prioridad Disponibilidad Frecuencia de uso Canal para el actor principal Canal para los actores secundarios Aspectos pendientes
Imprescindible Fase inicial Habitual HTTP HTTP Implementar todas las funciones que proporcione Moodle a travs de servicios web
2. Tabla caso de uso de listar usuarios por id
Listar usuarios por id Usuario Moodle Listar todos los usuarios de Moodle utilizando como discriminador el id de usuario La persona que realiza la bsqueda debe estar dada de alta en Moodle, y debe haber configurado la aplicacin con el token correcto y el host donde se encuentra ubicado la aplicacin de Moodle Este caso de uso, se muestra como primera pantalla operativa de la aplicacin, a partir de esta pantalla, podremos editar o borrar los usuarios que hemos listado 1. Se introducen los ids de los usuarios que se quieren buscar 2. Se lanza el web service con los parmetros especficos 3. Se recoge la respuesta y se muestra por pantalla. Si se introduce un dato que no es correcto para realizar la bsqueda, dicha operacin no se realiza Si la consulta no devuelve ningn usuario, se indicar que la lista est vaca
Disparadores
Escenario
Excepciones
Prioridad Disponibilidad Frecuencia de uso
Imprescindible Fase inicial Habitual 38
UAX Andriod Moodle Canal para el actor principal Canal para los actores secundarios Aspectos pendientes HTTP HTTP
Memoria
Mejorar el cuadro de bsqueda, para hacerlo ms intuitivo a los usuarios de la aplicacin. Permitir buscar entre rangos de usuarios.
3. Tabla caso de uso de editar usuarios
Editar usuarios Usuario Moodle Editar los datos de un usuario existente en Moodle La persona que realiza la bsqueda debe estar dada de alta en Moodle, y debe haber configurado la aplicacin con el token correcto y el host donde se encuentra ubicada la aplicacin de Moodle. Adems debe haber realizado un listado de usuarios por id y debe haber seleccionado alguno de la lista. Este caso de uso se muestra despus de seleccionar un usuario en el caso de uso de listar usuarios por id 1. 2. 3. 4. 5. Se debe realizar un listado de usuarios Seleccionar el usuario que queremos editar Editar los datos Enviar los datos editados Volver a la pantalla principal Si los datos que se introducen no son correctos se mostrar por pantalla Si se produce un error en la comunicacin con los servicios web, se mostrar por pantalla
Excepciones
Imprescindible Fase inicial Habitual HTTP HTTP Por ahora la funcin de editar de Moodle no permite editar todos los datos del usuario, cuando sea posible, adaptar esta funcin para poder editar todos los datos que se muestran por pantalla. 39
UAX Andriod Moodle
Memoria
4. Tabla caso de uso borrar usuarios
Borrar usuarios Usuario Moodle Borrar un usuario existente en Moodle La persona que realiza la bsqueda debe estar dada de alta en Moodle, y debe haber configurado la aplicacin con el token correcto y el host donde se encuentra ubicada la aplicacin de Moodle. Adems debe haber realizado un listado de usuarios por id y debe haber seleccionado alguno de la lista. Este caso de uso se muestra despus de seleccionar un usuario en el caso de uso de listar usuarios por id 1. Se debe realizar un listado de usuarios 2. Seleccionar el usuario que queremos borrar 3. Eliminar usuario Si se produce un error en la comunicacin con los servicios web, se mostrar por pantalla
Excepciones Prioridad Disponibilidad Frecuencia de uso Canal para el actor principal Canal para los actores secundarios Aspectos pendientes
5. Tabla caso de uso crear usuario
Imprescindible Fase inicial Habitual HTTP HTTP -
Crear usuario Usuario Moodle Crear un usuario nuevo en Moodle La persona que va a crear ese nuevo usuario en Moodle debe estar dada de alta en Moodle, y debe haber configurado la aplicacin con el token correcto y el host donde se encuentra ubicada la aplicacin de Moodle. 40
UAX Andriod Moodle Disparadores Escenario
Memoria Este caso se muestra, cuando seleccionamos en las opciones de men Crear Usuario 1. Rellenar los datos para un nuevo usuario 2. Comprobar que son correctos 3. Realizar la llamada a la funcin de Moodle correspondiente 4. Dar de alta en Moodle Si alguno de los datos que hemos rellenado no es correcto, mostraremos un mensaje por pantalla Si se produce algn error en el alta de las personas se mostrar un mensaje
Excepciones
Imprescindible Fase inicial Habitual HTTP HTTP Ahora mismo, las funciones que Moodle proporciona para crear un usuario a travs de un servicio web, no crean un usuario con todos los datos completos. Un aspecto pendiente, sera adaptarse a Moodle cuando saque la nueva versin de esta funcin.
En este apartado, se mostrar primero un diagrama de casos de uso general. En este diagrama se mostrar una visin global del proyecto. Mientras que se desglosar en diagramas de casos de uso ms especficos aquellas operaciones que tengan un poco ms de detalle.
2. Diagramas casos de uso
En este apartado mostraremos de manera visual la informacin que contienen las tablas de los casos de uso, con ello pretendemos ofrecer una visin diferente, ms esquemtica al lector que ayude a comprender los diferentes casos de uso.
41
UAX Andriod Moodle

1. Diagrama caso de uso general
Memoria
En este diagrama se muestra todas las posibles operaciones que puede realizar un usuario. El usuario puede listar los usuarios introduciendo un id, puede crear un usuario nuevo, editar o eliminar un usuario ya existente. Para poder editar o eliminar un usuario existente, es necesario poder hacer un listado por id de los usuarios. Adems tambin el usuario debe introducir el token y el host para poder consumir los servicios web que se ofrece a travs de Moodle.
2. Diagrama caso de uso de listar usuarios por id
Se muestra con ms detalle las operaciones con las que interacciona el usuario para poder realizar el listado de los usuarios.
42
UAX Andriod Moodle
Memoria
3. Diagrama caso de uso editar usuarios
Se muestra ms en detalle el caso de uso para editar un usuario, para poder editar un usuario, es necesario seleccionar un usuario de manera previa.
4. Diagrama caso de uso borrar usuarios
Se muestra ms en detalle el caso de uso para borrar un usuario, para poder borrar un usuario, es necesario seleccionar un usuario de manera previa. 43
UAX Andriod Moodle
Memoria
5. Diagrama caso de uso crear usuario
Se muestra ms en detalle el caso de uso para crear un nuevo usuario, para crear un nuevo usuario no es necesario realizar un listado previo, ya que lo que vamos a hacer es crear un nuevo usuario.
Para las operaciones de eliminar un usuario, cambiar token y host, no se han especificado de manera ms detallada los casos de uso porque son muy simples y con un nico caso de uso sera suficiente. 44
UAX Andriod Moodle
Memoria
3. DIAGRAMAS DE COLABORACIN
Un diagrama de colaboracin es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. Muestra cmo las instancias especficas de las clases trabajan juntas para conseguir un objetivo comn. Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementacin es llamada "enlace". En este apartado intentaremos mostrar cada uno de los diagramas de clase de los diferentes casos de uso que se pueden dar en la aplicacin y explicaremos con detalle las cosas ms importantes.
1. Diagrama de clases general
En este diagrama de clases se muestra una visin completa de la aplicacin, de todas las clases que forman parte de los paquetes. En primer lugar se puede observar que las clases principales de las que se compone la aplicacin Aserena, UserCreate y UserEdit, heredan de ListActivity o Activity (dependiendo del caso). Esto es debido a que son las clases que se encargan de mostrar por pantalla y recoger los datos de los usuarios y de la aplicacin. En esta ocasin no vamos a resaltar nada ms ya que este diagrama es para tener una visin global de la aplicacin. En los siguientes diagramas, comentaremos con ms detalle cada una de las clases.
45
UAX Andriod Moodle
Memoria
46
UAX Andriod Moodle

2. Diagrama de clases listar usuarios por id
Memoria
UserMenu es una clase que extiende la funcionalidad de ListActivity, puesto que muestra la lista de los usuarios que hemos buscado introduciendo el id de los usuarios. UserMenu tiene tres relaciones de dependencia, CallWebService, MyUserConverter y Xstream. Estas clases son las que nos proporcionan la funcionalidad de poder consumir las funciones de Moodle mediante servicios web (CallWebService), y para des-serializar la respuesta que nos devuelve la funcin de Moodle. La clase Preferences es la que nos permite editar las preferencias de usuario (Token y host donde se aloja Moodle). OrderAdapter es la clase que nos permite almacenar la lista de usuarios y por ltimo la clase ErrorException, que nos permite mostrar los errores que se puedan producir.
47
UAX Andriod Moodle

3. Diagrama de clases editar/borrar usuario
Memoria
48
UAX Andriod Moodle
Memoria
UserEdit es la clase que se encarga tanto de editar los usuarios como de borrarlos. Esta clase extiende la clase Activity de Android. Esta clase tiene tres relaciones de dependencia, CallWebService, MyUserConverter y Xstream. Estas clases son las que nos proporcionan la funcionalidad de poder consumir las funciones de Moodle mediante servicios web (CallWebService), y para des-serializar la respuesta que nos devuelve la funcin de Moodle en caso de producirse un error, porque si la funcin se ejecuta de manera correcta, la respuesta vuelve vaca. Tiene una relacin de asociacin de UserSinglenton, porque cuando seleccionamos un usuario de la lista, creamos una nueva instancia mediante esta clase singlenton para utilizarla durante la edicin o la eliminacin de dicho usuario.
4. Diagrama de clases crear usuario
La clase UserCreate extiende la clase Activity de Android. Como se puede observar en el diagrama de clases, tiene una relacin de asociacin con la clase ErrorException, esta clase nos sirve para controlar las excepciones y los errores que se puedan producir. Adems tiene una relacin de asociacin con UserSinglenton y con CheckScreen, ests funciones nos permiten crear el objeto usuario que ser el que enviaremos a la funcin de Moodle para dar de alta los usuarios. Mientras que la funcin CheckScreen es para comprobar los datos que se introducen por pantalla. La clase CallWebService es para llamar a la funcin mediante un servicio web de Moodle.
49
UAX Andriod Moodle
Memoria
50
UAX Andriod Moodle

5. Diagrama de clases llamada a un web service
Memoria
La clase web service tiene una relacin de dependencia con las clases que pueden consumir funciones de Moodle, con UserEdit, UserMenu, UserCreate. Tambin tiene ErrorException para los errores que se puedan producir en la llamada a los web services.
51
UAX Andriod Moodle

6. Diagrama de clases comprobar pantalla
Memoria
La clase CheckScreen es la que se encarga de comprobar que los datos que el usuario ha insertado por pantalla son correctos. Se relaciona con las clases UserSingleton ya que crea un nuevo objeto usuario para comprobar que es correcto la informacin de usuario.
7. Diagrama de clases pantalla inicial
52
UAX Andriod Moodle
Memoria
AndroidSplash es la clase que se encarga de mostrar la pantalla de inicio en la aplicacin. Esta clase extiende de la clase Activity de Android. Se encarga de mostrar la pantalla inicial y de llamar a la primera pantalla funcional de la aplicacin.
8. Diagrama de clases modificar preferencias
La clase Preferences extiende la clase PreferenceActivity de Android. Esta clase permite definir una serie de preferencias de usuario y almacenarlas en la aplicacin. En nuestro caso, las preferencias que almacenar sern el token del usuario y el host donde se encuentra Moodle.
53
UAX Andriod Moodle
Memoria
4. DIAGRAMA DE SECUENCIA
En este apartado vamos a detallar los diagramas de secuencia de algunas operaciones que se realiza en la aplicacin, como pueden ser la de lista los usuarios, editar un usuario o crear un usuario nuevo. Un diagrama de secuencia muestra la interaccin de un conjunto de objetos en una aplicacin a travs del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementacin del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos.
1. Diagrama de secuencia de listar usuarios por id
Se puede observar que la clase de UserMenu crea un OrderAdapter que es el que se encarga de recoger los datos de la pantalla y luego una vez realizadas todas las operaciones con el Moodle, los mostrar por pantalla.
54
UAX Andriod Moodle

2. Diagrama de secuencia de editar usuarios
Memoria
Como observamos para editar usuarios la secuencia de pasos que seguimos es la misma, llamaramos a un mtodo para recoger los datos que el usuario ha introducido por pantalla para luego mandarlos a la funcin de Moodle correspondiente. Este diagrama es casi idntico a eliminar usuarios, ya que las clases que utiliza son las mismas.
3. Diagrama de secuencia de crear usuarios
Como observamos a continuacin el diagrama de secuencia crear un nuevo usuario es muy similar a las dos anteriores, la nica diferencia se encuentra en que en esta iteracin no es necesario convertir el objeto MyUserConverter, ya que lo que hacemos es formar el mensaje necesario para pasrselo como parmetro a la funcin correspondiente de Moodle.
55
UAX Andriod Moodle
Memoria
56
UAX Andriod Moodle
Memoria
5. Ejemplos De Funcionamiento
En este punto daremos al lector una visin prctica de todo lo expuesto hasta este momento. En este apartado iremos haciendo un recorrido por las diferentes pantallas que tiene la aplicacin y haremos un breve resumen con las funcionalidades ms importantes. Cabe destacar que el objetivo de este proyecto ha sido el desarrollar la comunicacin mediante servicios web de Android con Moodle, dejando en un segundo lugar, pero no menos importante la implementacin de algn servicio actualmente disponible desde Moodle.
5.1 Pantalla de bienvenida

La funcionalidad de esta pantalla es meramente decorativa, sirve como nexo de unin entre el Sistema Operativo Android y la aplicacin.
5.2 Lista de usuarios

Esta pantalla es la pantalla principal de la aplicacin, la denomino as, porque desde esta pantalla se puede acceder a todas las funciones disponibles en la actualidad. Como se observa en la imagen, en la parte superior hay un cuadro de texto, en el cual 57
UAX Andriod Moodle separar los ids por comas.
Memoria
introduciremos los ids de los usuarios que queramos buscar, para buscar varios usuarios hay que
Si nuestra bsqueda obtiene resultados, se mostrar una lista con todos los usuarios. Dicha lista ha sido preparada, para que en un futuro, cuando el desarrollo de las funciones de Moodle lo permita, poder mostrar la fotografa de los usuarios. Si seleccionamos algn usuario, podremos ir al men de edicin de usuarios individuales. Tambin la pantalla principal, brinda la posibilidad a los usuarios de poder crear nuevos Usuarios o acceder a la pantalla de preferencias.
58
UAX Andriod Moodle
Memoria
5.3 Crear nuevos usuarios

Se mostrarn los campos necesarios para poder crear un nuevo usuario, como se ha dicho anteriormente, la versin de Moodle con las que estamos trabajando es una versin en desarrollo, por lo tanto, la funcionalidad no es completa. Es por ello que el nmero de campos para crear un usuario, de momento no es completo.
59
UAX Andriod Moodle
Memoria
Para crear un usuario nuevo, hay que rellenar todos los campos que se piden, ya que todos son obligatorios y pulsar el botn crear, si el usuario se crea de manera correcta, se volver a la pantalla de listar usuarios, por el contrario, si se produce algn error, se mostrar en esta pantalla.
5.4 Editar un usuario

Para editar un usuario existente en Moodle, es necesario realizar un listado de usuarios anteriormente, para poder editar un usuario, previamente lo tenemos que buscar, una vez que lo hemos buscado lo debemos seleccionar. Una vez seleccionado estamos en la ventana de edicin de los usuarios.
En esta ventana se mostrarn todos los datos de los usuarios seleccionados, adems se podr realizar la edicin del usuario. Como en el caso de Crear un usuario, se modificarn los campos necesarios y se enviar mediante web service, si todo va bien, se volver a la pantalla principal, mientras que si ocurre algn error se mostrar en esta pantalla.
5.5 Eliminacin usuario

En este caso, como en el anterior, es necesario seleccionar previamente el usuario que queremos eliminar y para seleccionarlo, tenemos que realizar un bsqueda por id. Una vez tengamos claro el usuario que queremos eliminar, nicamente debemos seleccionar la opcin de borrar del men. Como en el RESTo de ocasiones, si la operacin es correcta se vuelve a la pantalla principal y si ocurre algn error, se mostrara en esta pantalla. 60
UAX Andriod Moodle
Memoria
5.6 Preferencia de usuario

Por ltimo, mostraremos la pantalla que permite a los usuarios modificar tanto el Token con el que se conectan a Moodle, como el lugar (host), donde Moodle se encuentra ubicado.
El funcionamiento de la pgina es muy sencillo, se pulsara sobre la opcin que se quiere edita y a 61
UAX Andriod Moodle
Memoria
continuacin se editara. El sistema guarda automticamente las preferencias en un XML. Esto permite que el usuario pueda cambiar de portal de Moodle o que con esta aplicacin pueda consultar el portal ms de un usuario.
62
UAX Andriod Moodle
Memoria
6. Futuro Del Proyecto

El objetivo principal de este proyecto era dar el primer paso en esta parte de los portales de enseanza Moodle, la comunicacin desde Android utilizando Web Services. Decimos que hemos dado el primer paso, porque hasta la fecha la documentacin o proyectos de similares caractersticas eran nulos o muy escasos, de manera que este proyecto es el pionero. Una de las pruebas ms fehacientes de que es el primer paso, es que la versin que se ha tomado como base de Moodle, para poder desarrollar los web services desde Android, es una versin en desarrollo, el cdigo se ha obtenido directamente de la rama donde los desarrolladores de Moodle suben su cdigo a diario. Adems de no existir documentacin para consumir los web services de Moodle, otro problema al que nos hemos enfrentado, ha sido que las clases JAVA compiladas para poder consumir web services, no funcionaban para la mquina virtual de Android (Dalvik). Afortunadamente ambos problemas fueron solventados de manera exitosa, permitiendo avanzar el proyecto. Gracias a que el proyecto ha sido diseado siguiendo una implementacin en capas (Capa de datos, capa de negocio y capa de presentacin) el aadir nuevas funcionalidades a esta aplicacin es una labor sencilla (dentro de lo que cabe). Adems esta la arquitectura de tres capas elegida favorece la modularidad, por lo tanto hace ms sencillo la implementacin de los nuevos servicios conforme Moodle los vaya liberando. La aplicacin continuar siendo desarrollada en la comunidad alojada en Google Code. Por todas las posibilidades de mejora y por todos los motivos que se han expuesto al principio, hacen pensar, que el futuro de este proyecto puede ser muy bueno, pudiendo llegar a formar parte de los terminales Android de los alumnos de la UAX o porque no, de cualquier persona que desee consultar su curso en cualquier lugar del mundo.
63
UAX Andriod Moodle
Memoria
7. Bibliografa y referencias
Android Application Development: Programming with the Google SDK; Rick Rogers, John Lombardo, Zigurd Mednieks, Blake Meike. O'Reilly Media, Inc. (ISBN-13: 978-0596521479)
[Ref1]- http://www.muymovil.com/2010/09/21/el-auge-de-las-aplicaciones-moviles-unaoportunidad-para-mobivery [Ref2]- http://www.configurarequipos.com/doc1107.html [Ref3]- http://www.oracle.com/technetwork/java/codeconvtoc-136057.html [Ref4]- http://developer.android.com/resources/tutorials/views/index.html [Ref5]- http://www.smart-gsm.com/moviles/samsung-i5700-galaxy-lite [Ref6]- http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r52944.PPT [Ref7]- http://www.albertodevega.es/index.php?blog=1&title=web-services-vsrest&more=1&c=1&tb=1&pb=1 [Ref8]- http://es.wikipedia.org/wiki/Token_de_seguridad [Ref9]- http://www.prise.es/blog/?cat=11 [Ref10]- http://es.wikipedia.org/wiki/Subversion
64
UAX Andriod Moodle
Memoria
ANEXO I - Documentacin Web Services

Documentacin de los Web Services disponibles en Moodle. Este anexo se intenta que sea como un manual que ayude a cualquier persona que intente consumir los servicios web de Moodle, porque hasta la fecha Moodle no ha liberado ningn manual con la documentacin de los parmetros de entrada y salida de sus funciones y este manual ha sido obtenido utilizando tcnicas de ingeniera inversa. Para utilizar un Web Service de Moodle existen tres protocolos diferentes, XML-RPC protocol, SOAP protocol y REST protocol. Cada uno de estos tres protocolos tiene dos maneras de autenticar a los usuarios. Por autenticacin simple o por token. En el documento tcnico Tecnologas utilizadas, se podr encontrar una descripcin ms extensa de en qu consiste el protocolo de comunicacin REST. En este manual nos vamos a centrar en el protocolo REST, porque es el que implementamos en la aplicacin. Adems de nicamente explicar el protocolo REST, vamos a hacer los mismo con la manera de autenticacin, como hemos utilizado la autenticacin mediante token, la manera que explicamos para consumir cada uno de los webservices es utilizando un token (que es nico para cada usuario) y a travs del protocolo REST. De la misma manera que para REST, en el documento Tecnologas utilizadas, se ampla la documentacin de la autenticacin utilizando token.
Moodle_group_create_groups
Este servicio web permite la creacin de un nuevo grupo en Moodle. Para crear un nuevo grupo es necesario pasar al web service una serie de parmetros de entrada. Estos parmetros son token, courseid, name, description, enrolmentkey. Token: permite la autenticacin del usuario en el servicio y comprobar que el usuario que est consumiendo el servicio tiene privilegios para ellos. Courseid: identificador del curso en el cual queremos crear el grupo name: nombre del grupo que vamos a crear, debe ser nico. Enrolmentkey: frase secreta para inscribirse en un grupo.
Para consumir este web services, Moodle da la posibilidad de utiliza tres protocolos diferentes, como para esta aplicacin hemos seleccionado el protocolo REST y la manera de autenticacin mediante token, pasamos a explicar ms en detalle dichas conceptos., nicamente debemos pasar al web service como entrada el token del usuario y una matriz con el usuario/s que queremos 65
UAX Andriod Moodle datos pertenecientes al usuario (id, username, firstname...).
Memoria
consultar. Si todo funciona bien, el web service nos devolver una lista de objetos con todos los
En caso de producirse un error (el usuario no tiene los suficientes permisos para consumir este web service, no existe este usuario en la base de datos, no hay usuarios con los ids que se han pasado como parmetros), el web service devolver una estructura con el siguiente error: Invalid
value detected, execution can not continue. parameter
Los parmetros de entrada que hemos descrito anteriormente, se pasan al web service en forma de un array de elementos. A continuacin se describe la entrada del web service con los diferentes protocolos: Parmetros de entrada
Parmetro obligatorio Estructura general
Courseid, name, description, enrolmentkey

list of ( int //user ID
)//List of group object. A group has a courseid, a name, a description and an enrolment key. list of ( object { courseid int name string //id of course //multilang compatible name, course unique //group description text //group enrol secret phrase
description string enrolmentkey string } )
REST (post parameters)
userids[0]= int groups[0][courseid]= int groups[0][name]= string groups[0][description]= string groups[0][enrolmentkey]= string
Respuesta
Una lista de objetos. Un grupo tiene un id, courseid, un nombre, y un enrolmentkey
Estructura general
//List of group object. A group has an id, a courseid, a name, a description and an
66
UAX Andriod Moodle

enrolment key. list of ( object { id int //group record id //id of course //multilang compatible name, course unique //group description text //group enrol secret phrase
Memoria
courseid int name string
<?XML version="1.0" encoding="UTF-8" ?> <RESPONSE> <MULTIPLE> <SINGLE> <KEY name="id"> <VALUE>int</VALUE> </KEY> <KEY name="courseid"> <VALUE>int</VALUE> </KEY> <KEY name="name"> <VALUE>string</VALUE> </KEY> <KEY name="description"> <VALUE>string</VALUE> </KEY> <KEY name="enrolmentkey"> <VALUE>string</VALUE> </KEY> </SINGLE> </MULTIPLE> </RESPONSE>
Mensaje de error
<?XML version="1.0" encoding="UTF-8"?> <EXCEPTION class="invalid_parameter_exception"> <MESSAGE>Invalid parameter value detected, execution can not continue.</MESSAGE> <DEBUGINFO></DEBUGINFO> </EXCEPTION>
Moodle_group_add_groupmembers
Web service diseado para implementar la funcionalidad de poder aadir nuevos miembros al 67
UAX Andriod Moodle
Memoria
grupo. Ese grupo puede ser uno creado mediante una va normal o utilizando el web service especificado anteriormente. Para aadir nuevos miembros al grupo es necesario pasar al web service una serie de parmetros de entrada. Estos parmetros son token, userid, groupid. Token: permite la autenticacin del usuario en el servicio y comprobar que el usuario que est consumiendo el servicio tiene privilegios para ellos. userid: es un array de elementos que contiene todos los identificadores de los usuarios que queramos aadir a los grupos groupid: array de elementos que contiene todos los grupos a los que queramos aadirle los usuarios que hemos especificado en el array userid. Para consumir este web services, Moodle da la posibilidad de utilizar tres protocolos diferentes, como para esta aplicacin hemos seleccionado el protocolo REST y la manera de autenticacin mediante token, pasamos a explicar ms en detalle dichos conceptos. nicamente debemos pasar al web service como entrada el token del usuario y una matriz con el usuario/s que queremos consultar. Si todo funciona bien, el web service nos devolver una lista de objetos con todos los datos pertenecientes al usuario (id, username, firstname...). En caso de producirse un error (el usuario no tiene los suficientes permisos para consumir este web service, no existe este usuario en la base de datos, no hay usuarios con los ids que se han pasado como parmetros), el web service devolver una estructura con el siguiente error: Invalid
Los parmetros de entrada que hemos descrito anteriormente, se pasan al web service en forma de un array de elementos. A continuacin se describe la entrada del web service con los diferentes protocolos: Parmetros de entrada members
list of ( int //user ID
)list of ( object { groupid int userid int } ) //group record id //user id
members[0][groupid]= int
68
UAX Andriod Moodle

members[0][userid]= int
Memoria
Respuesta
Este web service no devuelve ninguna respuesta en el caso de que la accin se produzca de manera correcta. Si se produce algn error durante la ejecucin, devolver un mensaje de error. Mensaje de error
Moodle_group_delete_groupmembers
Web service diseado para implemetar la funcionalidad de poder eliminar miembros existentes en un grupo. Para eliminar usuarios de un grupo, es necesario que tanto el grupo como los usuarios existan. Para eliminar miembros de un grupo es necesario pasar al web service una serie de parmetros de entrada. Estos parmetros son token, userid, groupid. Token: permite la autenticacin del usuario en el servicio y comprobar que el usuario que est consumiendo el servicio tiene privilegios para ellos. userid: es un array de elementos que contiene todos los identificadores de los usuarios que queramos eliminar de los grupos groupid: array de elementos que contiene todos los grupos a los que queramos eliminar los usuarios que hemos especificado en el array userid. Para consumir este web services, Moodle da la posibilidad de utilizar tres protocolos diferentes, como para esta aplicacin hemos seleccionado el protocolo REST y la manera de autenticacin mediante token, pasamos a explicar ms en detalle dichos conceptos. nicamente debemos pasar al web service como entrada el token del usuario y una matriz con el usuario/s que queremos consultar. Si todo funciona bien, el web service nos devolver una lista de objetos con todos los datos pertenecientes al usuario (id, username, firstname...). En caso de producirse un error (el usuario no tiene los suficientes permisos para consumir este web service, no existe este usuario en la base de datos, no hay usuarios con los ids que se han pasado 69
UAX Andriod Moodle como parmetros), el web service devolver una estructura con el siguiente error: Invalid
value detected, execution can not continue.
Memoria
parameter
Los parmetros de entrada que hemos descrito anteriormente, se pasan al web service en forma de un array de elementos. A continuacin se describe la entrada del web service con los diferentes protocolos: Parmetros de entrada members
list of ( object { groupid int userid int } ) //group record id //user id
members[0][groupid]= int members[0][userid]= int
Respuesta
Moodle_group_delete_groups
Web service diseado para implemetar la funcionalidad de poder eliminar grupos que ya han sido creados con anterioridad. Para eliminar un grupo, es necesario que el grupo exista. Para eliminar un grupo es necesario pasar al web service una serie de parmetros de entrada. Estos parmetros son token, groupid. Token: permite la autenticacin del usuario en el servicio y comprobar que el usuario que 70
UAX Andriod Moodle est consumiendo el servicio tiene privilegios para ellos.
Memoria
groupid: array de elementos que contiene todos los grupos a los que queramos eliminar.
Para consumir este web services, Moodle da la posibilidad de utilizar tres protocolos diferentes, como para esta aplicacin hemos seleccionado el protocolo REST y la manera de autenticacin mediante token, pasamos a explicar ms en detalle dichos conceptos. nicamente debemos pasar al web service como entrada el token del usuario y una matriz con el usuario/s que queremos consultar. Si todo funciona bien, el web service nos devolver una lista de objetos con todos los datos pertenecientes al usuario (id, username, firstname...). En caso de producirse un error (el usuario no tiene los suficientes permisos para consumir este web service, no existe este usuario en la base de datos, no hay usuarios con los ids que se han pasado como parmetros), el web service devolver una estructura con el siguiente error: Invalid
Los parmetros de entrada que hemos descrito anteriormente, se pasan al web service en forma de un array de elementos. A continuacin se describe la entrada del web service con los diferentes protocolos: Parmetros de entrada groupids
list of ( int ) //Group ID
groupids[0]= int
Respuesta
71
UAX Andriod Moodle
Memoria
Moodle_group_get_course_groups
Web service diseado para implemetar la funcionalidad para devolver todos los grupos de un curso. Estos grupos, como hemos explicado anteriormente, han tenido que ser creados y asignados utilizando la herramienta Moodle va web o va web services, como hemos explicado en los puntos anteriores. Para obtener todos los grupos de un determinado curso es necesario pasar al web service una serie de parmetros de entrada. Estos parmetros son token, courseid. Token: permite la autenticacin del usuario en el servicio y comprobar que el usuario que est consumiendo el servicio tiene privilegios para ellos. Courseid: el identificador del curso del cual queremos obtener todos los grupos que tiene asignado. Para consumir este web services, Moodle da la posibilidad de utilizar tres protocolos diferentes, como para esta aplicacin hemos seleccionado el protocolo REST y la manera de autenticacin mediante token, pasamos a explicar ms en detalle dichos conceptos. nicamente debemos pasar al web service como entrada el token del usuario y una matriz con el usuario/s que queremos consultar. Si todo funciona bien, el web service nos devolver una lista de objetos con todos los datos pertenecientes al usuario (id, username, firstname...). En caso de producirse un error (el usuario no tiene los suficientes permisos para consumir este web service, no existe este usuario en la base de datos, no hay usuarios con los ids que se han pasado como parmetros), el web service devolver una estructura con el siguiente error: Invalid
Los parmetros de entrada que hemos descrito anteriormente, se pasan al web service en forma de un array de elementos. A continuacin se describe la entrada del web service con los diferentes protocolos: Parmetros de entrada courseid
int //id of course
courseid= int
72
UAX Andriod Moodle Respuesta
Memoria
Estructura general
list of ( object { id int //group record id //id of course //multilang compatible name, course unique //group description text //group enrol secret phrase
<?XML version="1.0" encoding="UTF-8" ?> <RESPONSE> <MULTIPLE> <SINGLE> <KEY name="id"> <VALUE>int</VALUE> </KEY> <KEY name="courseid"> <VALUE>int</VALUE> </KEY> <KEY name="name"> <VALUE>string</VALUE> </KEY> <KEY name="description"> <VALUE>string</VALUE> </KEY> <KEY name="enrolmentkey"> <VALUE>string</VALUE> </KEY> </SINGLE> </MULTIPLE> </RESPONSE>
Mensaje de error
Moodle_group_get_groupmembers
Web service diseado para implemetar la funcionalidad de devolver todos los miembros del grupo que pasemos por parmetros. Tanto los usuarios como los grupos han tenido que ser creados 73
UAX Andriod Moodle serie de parmetros de entrada. Estos parmetros son token, groupid.
Memoria
anteriormente. Para obtener todos los miembros de un grupo es necesario pasar al web service una
Token: permite la autenticacin del usuario en el servicio y comprobar que el usuario que est consumiendo el servicio tiene privilegios para ellos.
groupid: array de elementos que contiene todos los grupos de los cuales queramos obtener los miembros que pertenecen a esos grupos.
list of ( int ) //Group ID
groupids[0]= int
Respuesta
Estructura general
list of ( object {
74
UAX Andriod Moodle

groupid int //group record id userids list of ( int )} ) //user id
Memoria
<?XML version="1.0" encoding="UTF-8" ?> <RESPONSE> <MULTIPLE> <SINGLE> <KEY name="groupid"> <VALUE>int</VALUE> </KEY> <KEY name="userids"> <MULTIPLE> <VALUE>int</VALUE> </MULTIPLE> </KEY> </SINGLE> </MULTIPLE> </RESPONSE>
Mensaje de error
Moodle_group_get_groups
Web service diseado para implemetar la funcionalidad de obtener todos los detalles para un determinado grupo que pasemos por parmetros de entrada a este web service. Ese grupo puede ser uno creado mediante una va normal o utilizando el web service especificado anteriormente. Para recuperar todos los detalles del grupo es necesario pasar al web service una serie de parmetros de entrada. Estos parmetros son token, groupid. Token: permite la autenticacin del usuario en el servicio y comprobar que el usuario que est consumiendo el servicio tiene privilegios para ellos. groupid: array de elementos que contiene todos los grupos a los que queramos de los cuales obtener la lista de detalles. Para consumir este web services, Moodle da la posibilidad de utilizar tres protocolos diferentes, como para esta aplicacin hemos seleccionado el protocolo REST y la manera de autenticacin 75
UAX Andriod Moodle
Memoria
mediante token, pasamos a explicar ms en detalle dichos conceptos. nicamente debemos pasar al web service como entrada el token del usuario y una matriz con el usuario/s que queremos consultar. Si todo funciona bien, el web service nos devolver una lista de objetos con todos los datos pertenecientes al usuario (id, username, firstname...). En caso de producirse un error (el usuario no tiene los suficientes permisos para consumir este web service, no existe este usuario en la base de datos, no hay usuarios con los ids que se han pasado como parmetros), el web service devolver una estructura con el siguiente error: Invalid
//List of group id. A group id is an integer. list of ( int ) //Group ID
groupids[0]= int
Respuesta
Estructura general
list of ( object { id int //group record id //id of course //multilang compatible name, course unique //group description text //group enrol secret phrase
<?XML version="1.0" encoding="UTF-8" ?> <RESPONSE> <MULTIPLE> <SINGLE> <KEY name="id">
76
UAX Andriod Moodle

<VALUE>int</VALUE> </KEY> <KEY name="courseid"> <VALUE>int</VALUE> </KEY> <KEY name="name"> <VALUE>string</VALUE> </KEY> <KEY name="description"> <VALUE>string</VALUE> </KEY> <KEY name="enrolmentkey"> <VALUE>string</VALUE> </KEY> </SINGLE> </MULTIPLE> </RESPONSE>
Memoria
Mensaje de error <?XML version="1.0" encoding="UTF-8"?> REST (post <EXCEPTION class="invalid_parameter_exception"> parameters)
<MESSAGE>Invalid parameter value detected, execution can not continue.</MESSAGE> <DEBUGINFO></DEBUGINFO> </EXCEPTION>
Moodle_user_create_users
Web service diseado para implemetar la funcionalidad de crear nuevos usuarios en la plataforma de enseanza Moodle. Para poder crear estos usuarios no deben existir previamente en la base de datos para poder darlos de alta de manera correcta. Para poder crear nuevos usuarios es necesario pasar al web service una serie de parmetros de entrada. Estos parmetros son token, username, password, firstname, lastname, email, customfieldtype, customfieldvalue. Token: permite la autenticacin del usuario en el servicio y comprobar que el usuario que est consumiendo el servicio tiene privilegios para ellos. Username: nombre de usuario que se quiera dar de alta. Password: password para el usuario que estemos dando de alta. El password debe cumplir con los requisitos de seguridad de Moodle. Firstname: primer apellido del usuario que estemos dando de alta lastname: segundo apellido del usuario que estemos dando de alta. Email: correo electrnico de la persona que estemos dando de alta. Debe ser un correo 77
UAX Andriod Moodle vlido y activo.
Memoria
Customfieldtype: nombre del campo que queramos rellenar para el perfil del usuario. customfieldvalue: valor del campo que hemos definido en el customfieldtype.
Los parmetros de entrada que hemos descrito anteriormente, se pasan al web service en forma de un array de elementos. A continuacin se describe la entrada del web service con los diferentes protocolos: Parmetros de entrada users
list of ( object { username string password string firstname string lastname string email string auth string //Username policy is defined in Moodle security config //Plain text password consisting of any characters //The first name(s) of the user //The family name of the user //A valid and unique email address Default to "manual" //Auth plugins include manual, ldap, imap, etc Default to "" //An arbitrary ID code number perhaps from the Default to "0" //Email is blocked: 1 is blocked and 0 otherwise
idnumber string institution emailstop double lang string theme string
Default to "en" //Language code such as "en", must exist on server Optional //Theme name such as "standard", must exist on server Optional //Timezone code such as Australia/Perth, or 99 for default Optional //Mail format code is 0 for plain text, 1 for HTML etc Optional //User profile description, no HTML
timezone string mailformat int
description string city string
Optional //Home city of the user Optional //Home country code of the user, such as AU or CZ
country string
78
UAX Andriod Moodle

preferences list of ( object { type string value string } )customfields list of ( object { type string value string } )} //The name of the custom field //The value of the custom field //The name of the preference //The value of the preference Optional //User preferences
Memoria
Optional //User custom fields (also known as user profil fields)
users[0][username]= string users[0][password]= string users[0][firstname]= string users[0][lastname]= string users[0][email]= string users[0][auth]= string users[0][idnumber]= string users[0][emailstop]= double users[0][lang]= string users[0][theme]= string users[0][timezone]= string users[0][mailformat]= int users[0][description]= string users[0][city]= string users[0][country]= string users[0][preferences][0][type]= string users[0][preferences][0][value]= string users[0][customfields][0][type]= string users[0][customfields][0][value]= string
Respuesta
Estructura general
list of ( object { id int //user id //user name
username string } )
<?XML version="1.0" encoding="UTF-8" ?> <RESPONSE> <MULTIPLE> <SINGLE> <KEY name="id">
79
UAX Andriod Moodle

<VALUE>int</VALUE> </KEY> <KEY name="username"> <VALUE>string</VALUE> </KEY> </SINGLE> </MULTIPLE> </RESPONSE>
Memoria
Mensaje de error
Moodle_user_delete_users
Web service diseado para implemetar la funcionalidad de eliminar un usuario existente. Para eliminar un usuario, este usuario debe existir, es decir, ha tenido que ser creado con anterioridad. Para eliminar un usuario es necesario pasar al web service una serie de parmetros de entrada. Estos parmetros son token, userid. Token: permite la autenticacin del usuario en el servicio y comprobar que el usuario que est consumiendo el servicio tiene privilegios para ellos. userid: es un array de elementos que contiene todos los identificadores de los usuarios que queramos eliminar Para consumir este web services, Moodle da la posibilidad de utilizar tres protocolos diferentes, como para esta aplicacin hemos seleccionado el protocolo REST y la manera de autenticacin mediante token, pasamos a explicar ms en detalle dichos conceptos. nicamente debemos pasar al web service como entrada el token del usuario y una matriz con el usuario/s que queremos consultar. Si todo funciona bien, el web service nos devolver una lista de objetos con todos los datos pertenecientes al usuario (id, username, firstname...). En caso de producirse un error (el usuario no tiene los suficientes permisos para consumir este web service, no existe este usuario en la base de datos, no hay usuarios con los ids que se han pasado como parmetros), el web service devolver una estructura con el siguiente error: Invalid
Los parmetros de entrada que hemos descrito anteriormente, se pasan al web service en forma de 80
UAX Andriod Moodle un array de elementos. A continuacin se describe la entrada del web service con los diferentes protocolos: Parmetros de entrada userids
list of ( int ) //user ID
Memoria
userids[0]= int
Respuesta
Moodle_user_update_users
Web service diseado para implemetar la funcionalidad de actualizar los detalles o datos de un usuario existente. Este usuario debe existir previamente para poder realizar la modificacin de los datos. Estos parmetros son token, id, username, password, firstname, lastname, email, customfieldtype, customfieldvalue. Token: permite la autenticacin del usuario en el servicio y comprobar que el usuario que est consumiendo el servicio tiene privilegios para ellos. Id: identificador del usuario que queramos actualizar los datos. Username: nombre de usuario que se quiera modificar Password: password para el usuario que estemos modificando El password debe cumplir con los requisitos de seguridad de Moodle. 81
UAX Andriod Moodle Firstname: primer apellido del usuario que estemos modificando lastname: segundo apellido del usuario que estemos modificando.
Memoria
Email: correo electrnico de la persona que estemos modificando. Debe ser un correo vlido y activo.
Customfieldtype: nombre del campo que queramos rellenar para el perfil del usuario. customfieldvalue: valor del campo que hemos definido en el customfieldtype.
Los parmetros de entrada que hemos descrito anteriormente, se pasan al web service en forma de un array de elementos. A continuacin se describe la entrada del web service con los diferentes protocolos: Parmetros de entrada users
list of ( object { id double //ID of the user Optional //Username policy is defined in Moodle security config Optional //Plain text password consisting of any characters Optional //The first name(s) of the user Optional //The family name of the user
username string password string firstname string lastname string email string auth string
Optional //A valid and unique email address Optional //Auth plugins include manual, ldap, imap, etc Optional //An arbitrary ID code number perhaps from the institution Optional //Email is blocked: 1 is blocked and 0 otherwise
idnumber string emailstop double lang string theme string
Optional //Language code such as "en", must exist on server Optional //Theme name such as "standard", must exist on server Optional //Timezone code such as Australia/Perth, or 99 for default
timezone string
82
UAX Andriod Moodle

mailformat int description string city string Optional //User profile description, no HTML
Memoria
Optional //Mail format code is 0 for plain text, 1 for HTML etc
Optional //Home city of the user Optional //Home country code of the user, such as AU or CZ Optional //User custom fields (also known as user profil fields)
country string customfields list of ( object { type string value string } )preferences list of ( object { type string value string } )} )
//The name of the custom field //The value of the custom field
Optional //User preferences
//The name of the preference //The value of the preference
users[0][id]= double users[0][username]= string users[0][password]= string users[0][firstname]= string users[0][lastname]= string users[0][email]= string users[0][auth]= string users[0][idnumber]= string users[0][emailstop]= double users[0][lang]= string users[0][theme]= string users[0][timezone]= string users[0][mailformat]= int users[0][description]= string users[0][city]= string users[0][country]= string users[0][customfields][0][type]= string users[0][customfields][0][value]= string users[0][preferences][0][type]= string users[0][preferences][0][value]= string
Respuesta
<?XML version="1.0" encoding="UTF-8"?> <EXCEPTION class="invalid_parameter_exception">
83
UAX Andriod Moodle

Memoria
Moodle_user_get_users_by_id
Este servicio web se puede utilizar para realizar una bsqueda o listado de los usuarios. Para realizar la bsqueda es necesario pasar como parmetro el id del usuario/s que se quiere consultar. El web service slo acepta matrices como parmetros. Para consumir este web services, Moodle da la posibilidad de utilizar tres protocolos diferentes, como para esta aplicacin hemos seleccionado el protocolo REST y la manera de autenticacin mediante token, pasamos a explicar ms en detalle dichos conceptos. nicamente debemos pasar al web service como entrada el token del usuario y una matriz con el usuario/s que queremos consultar. Si todo funciona bien, el web service nos devolver una lista de objetos con todos los datos pertenecientes al usuario (id, username, firstname...). En caso de producirse un error (el usuario no tiene los suficientes permisos para consumir este web service, no existe este usuario en la base de datos, no hay usuarios con los ids que se han pasado como parmetros), el web service devolver una estructura con el siguiente error: Invalid
A continuacin se muestra detalladamente los parmetros de entrada para el webservices, as como la estructura que devolver en caso de producirse una consulta de manera exitosa, as como los mensajes de error. Parmetros de entrada userids
list of ( int ) //user ID
userids[0]= int
Respuesta
84
UAX Andriod Moodle Estructura general

list of ( object { id double //ID of the user //Username policy is defined in Moodle security config //The first name(s) of the user //The family name of the user //An email address - allow email as root@localhost //Auth plugins include manual, ldap, imap, etc //Active user: 1 if confirmed, 0 otherwise
Memoria
username string firstname string lastname string email string auth string
confirmed double idnumber string emailstop double lang string theme string timezone string mailformat int
//An arbitrary ID code number perhaps from the institution //Email is blocked: 1 is blocked and 0 otherwise
//Language code such as "en", must exist on server //Theme name such as "standard", must exist on server //Timezone code such as Australia/Perth, or 99 for default //Mail format code is 0 for plain text, 1 for HTML etc //User profile description, as HTML
description string city string country string customfields list of ( object { type string value string } )} )
//Home city of the user //Home country code of the user, such as AU or CZ Optional //User custom fields (also known as user profil fields)
//The name of the custom field //The value of the custom field
<?XML version="1.0" encoding="UTF-8" ?> <RESPONSE> <MULTIPLE> <SINGLE> <KEY name="id"> <VALUE>double</VALUE> </KEY> <KEY name="username"> <VALUE>string</VALUE> </KEY> <KEY name="firstname"> <VALUE>string</VALUE> </KEY> <KEY name="lastname"> <VALUE>string</VALUE> </KEY> <KEY name="email"> <VALUE>string</VALUE> </KEY> <KEY name="auth"> <VALUE>string</VALUE> </KEY> <KEY name="confirmed">
85
UAX Andriod Moodle

<VALUE>double</VALUE> </KEY> <KEY name="idnumber"> <VALUE>string</VALUE> </KEY> <KEY name="emailstop"> <VALUE>double</VALUE> </KEY> <KEY name="lang"> <VALUE>string</VALUE> </KEY> <KEY name="theme"> <VALUE>string</VALUE> </KEY> <KEY name="timezone"> <VALUE>string</VALUE> </KEY> <KEY name="mailformat"> <VALUE>int</VALUE> </KEY> <KEY name="description"> <VALUE>string</VALUE> </KEY> <KEY name="city"> <VALUE>string</VALUE> </KEY> <KEY name="country"> <VALUE>string</VALUE> </KEY> <KEY name="customfields"> <MULTIPLE> <SINGLE> <KEY name="type"> <VALUE>string</VALUE> </KEY> <KEY name="value"> <VALUE>string</VALUE> </KEY> </SINGLE> </MULTIPLE> </KEY> </SINGLE> </MULTIPLE> </RESPONSE>
Memoria
Mensaje de error REST (post <?XML parameters)
version="1.0" encoding="UTF-8"?>
<EXCEPTION class="invalid_parameter_exception">
86
UAX Andriod Moodle

Memoria
87
UAX Andriod Moodle
Memoria
ANEXO II - Funcionamiento De Los Web Services

Como se puede comprobar, este proyecto gira entorno a los web services, por eso en este documento se intentar explicar de la manera ms fcil y sencilla posible como consumir los servicios web que ofrece Moodle. Una vez que logramos consumir de la manera correcta los web services, tenemos que lograr des-serializar los resultados que nos devuelven los mtodos que invoquemos para poder utilizar los objetos en el RESTo de la aplicacin. Para consumir los web services, se pueden optar por varios protocolos, en este proyecto se ha optado por utilizar el servicio REST (este servicio es explicado en el manual Tecnologas utilizadas). Una vez invocado de manera correcta el web service, este nos devuelve un XML con una determinada estructura. En este XML estn todos los datos que ha devuelto como resultado de la operacin que hemos consumido. Para poder utilizar los datos en el RESTo de la aplicacin debemos des-serializarlos y pasarlos de XML a objetos, con este paso, conseguiremos tener los datos en una estructura que nos permite de manera sencilla acceder a ellos en el conjunto de la aplicacin. El estndar que se ha empleado para realizar la des-serializacin de los datos es Xstream (este estndar tambin es explicado en el manual Tecnologas utilizadas). A continuacin se explicar la manera correcta de consumir un web service de Moodle y los pasos necesarios para des-serializar un XML.
1. Consumir un webservices
Como hemos dicho anteriormente, para consumir uno de los servicios web que Moodle nos ofrece, optamos por utilizar el protocolo REST. Para poder consumir de manera correcta un web service de Moodle sera necesario aadir a la url que vamos a formar los parmetros oportunos para lograr consumir el web service de manera satisfactoria. Una vez aadidos ya podramos invocar la funcin seleccionada. Para guiarnos en la explicacin vamos a tomar como ejemplo el web service de Moodle_user_get_user_by_id. La eleccin de este web services es debido a que es uno de los ms sencillos de consumir. En primer lugar para poder comprobar que los web services funcionan de manera correcta, Moodle proporciona una herramienta para testear el servicio y ver que tenemos configurado todo lo necesario para poder consumirlos desde una aplicacin externa. Esta pequea aplicacin que nos permite utilizar Moodle es de gran ayuda, ya que permite ver que 88
UAX Andriod Moodle
Memoria
datos y en que formato va a devolver los web services los resultados del mtodo utilizado. Tambin permite probar los web services y ver que parmetros son necesarios para su correcta consumicin. En la siguiente imagen se muestra la ventana para testear el servicio web que vamos a utilizar en este manual. Como se puede observar, tiene varios combos, los cuales permite elegir entre las diferentes opciones que nos permiten utilizar, en la imagen se muestra que vamos a consumir el web service utilizando una autenticacin mediante token de seguridad, que nos permite mantener la seguridad del portal de manera muy sencilla. Tambin nos muestra que el protocolo de comunicacin que hemos seleccionado es REST, del cual hablamos ms en profundidad en el manual de Tecnologas utilizadas. Y por ltimo vemos que hemos seleccionado la funcin de get_user_by_id.
Una vez seleccionados todos los parmetros, pincharemos sobre el botn Seleccionar, el cual nos llevar a la venta de introducir los parmetros de entrada as como el token de seguridad. Esto se puede comprobar en la siguiente captura de pantalla. Una vez rellenados los datos oportunos, seleccionaramos el botn Execute y esto nos devolvera la informacin oportuna, dependiendo de los parmetros que hemos seleccionado en la entrada. Una vez explicado como testear los web services con la herramienta que nos brinda el portal
89
UAX Andriod Moodle Moodle, continuaremos con la explicacin del cdigo.
Memoria
Como hemos dicho anteriormente, para poder consumir un web service es necesario que el usuario exista en la base de datos de Moodle y que adems tenga asociado un token. Sin esto es imposible ejecutar un web service, ya que carece del mtodo de autenticacin. Este token lo introducir el usuario de manera manual en el sistema, en futuras versiones de la aplicacin, ser el sistema el que lo obtenga de manera automtica. Una vez tenemos el token, debemos sabes que funcin de las que Moodle dispone actualmente, es la que queremos consumir. En nuestro caso, ser "Moodle_user_get_users_by_id". Para saber cmo tenemos que formar la cadena para pasarle los parmetros de entrada a la funcin de Moodle, tenemos que usar el programa Wiresharck, que nos permite capturar todos los paquetes que viajan por la red. Primero debemos abrir con permisos de administrar el wiresharck. Una vez tenemos abierto el programa, le indicamos que interfaz queremos capturar trfico:
90
UAX Andriod Moodle
Memoria
Una vez que tenemos abierto el programa y estamos capturando todo el trfico que pasa por la interfaz lo de nuestra tarjeta de red, tenemos que ejecutar un web service desde la pgina de pruebas de Moodle y ver que parmetros le pasa a la funcin.
En la imagen se puede observar que se ha capturado la llamada a la funcin de Moodle_user_get_users_by_id con todos los parmetros de entrada. Esa lnea la mostrmos a continuacin para mayor claridad:
[truncated] authmethod=token&function=Moodle_user_get_users_by_id&protocol=REST&sesskey=GxZxn28SeC&_qf__Moodle_use r_get_users_by_id_form=1&token=4ae93a61942f8a07e5f738281807819a&userids%5B0%5D=1&userids %5B1%5D=&userids%5B2%5D=&userids%5B3%
Ahora, slo nos quedara formar en cdigo JAVA esa llamada para poder consumir el servicio web que necesitemos. Esto se lo indicamos en dos variables:
// This token must be created by the user in the Web Services plugin private static String token = "4ae93a61942f8a07e5f738281807819a";
private static String MoodleWebService = "Moodle_user_get_users_by_id";
Una vez tengamos esto claro, pasaremos a la creacin de un cliente basado en REST, que nos permita consumir las funciones de Moodle. 91
UAX Andriod Moodle

Client client = Client.create();
Memoria
Una vez creado el cliente, debemos crear un recurso web, con la localizacin del servidor que Moodle pone a nuestra disposicin. Para crear dicho servicio web lo realizamos de la siguiente manera:
WebResource webResource = client.resource("HTTP://localhost/Moodle/webservice/REST/server.php");
Una vez establecido el cliente para consumir la funcin y la ubicacin del servidor donde est ubicada dicha funcin, es necesario pasar por parmetros los datos necesarios para hacer funcionar dicho web service. Esto se realiza mediante un multivaluemap, en el cual le indicamos, tanto el token (para logarnos en la aplicacin), la funcin que queremos consumir y los parmetros de entrada para dicha funcin.
MultivaluedMap<String, String> urlParams = new MultivaluedMapImpl(); urlParams.add("wstoken", token); urlParams.add("wsfunction", MoodleWebService); MultivaluedMap<String, String> formData = new MultivaluedMapImpl(); formData.add("userids[0]","1"); formData.add("userids[1]","2");
Una vez logrado esto, ya tenemos la url formada para poder consumir la funcin de Moodle que deseemos, lo nico que tenemos que hacer ahora es lanzar dicha url, indicando el protocolo y esperar los resultados.
ClientResponse response = webResource.queryParams(urlParams).type("application/x-www-formurlencoded").post(ClientResponse.class, formData);
Una vez que hemos obtenido los resultados, debemos des-serializar los datos para convertirlos en un objeto JAVA, que nos resulte vlido para operar con los datos en los diferentes puntos de la aplicacin.
2. Almacenar resultados de un webService

Como hemos explicado en el primer apartado, una vez que hemos consumido de manera correcta el webService, es necesario des-serializar los resultados. Para ello, utilizaremos la librera Xstream, la cual nos permite de manera muy sencilla pasar a objetos el XML que nos devuelven las funciones de Moodle. Para seguir con la misma estructura del primer apartado, primero explicaremos de manera breve, el resultado de testear los webservices utilizando la herramienta de Moodle. 92
UAX Andriod Moodle parmetros y el token de seguridad.
Memoria
En el apartado anterior nos quedamos en el paso de ejecutar la funcin una vez introducidos los
Si todo est correcto, la herramienta de Moodle, nos debera mostrar otra pantalla, dnde veramos el resultado de la funcin con los parmetros que hemos introducido. La siguiente captura de pantalla muestra un ejemplo de resultado:
Como vemos en la captura de pantalla, nos muestra toda la informacin relacionada con el usuario que queremos consultar, en este caso, nicamente hemos introducido por parmetros un usuario, as que slo nos sacar uno. Si en lugar de uno introducimos ms usuarios, nos devolvera un XML con la lista de los datos de los usuarios. Ms adelante explicaremos como des-serializamos dicha lista y la convertimos en un objeto JAVA, que sea vlido para operar con ella durante el RESTo de la aplicacin. Si en lugar de ser una ejecucin correcta, se produce cualquier error, la aplicacin nos devolvera el siguiente mensaje:
93
UAX Andriod Moodle
Memoria
Como se observa en la imagen, vemos que ha devuelto un XML con el error y una breve
descripcin. El error ha sido provocado, ya que se ha invocado la funcin sin introducir ningn parmetro de entrada. Una vez explicado esto, pasamos a detallar como se ha implementado en JAVA todo lo que hemos probado en la aplicacin de Moodle. En el apartado anterior nos quedamos esperando la respuesta que nos devolva el webService que hemos consumido. Para ello debemos declarar un string donde almacenamos dicha respuesta y que luego nos servir para des-serializarlo.
String XML = response.getEntity(String.class); XStream xstream = new XStream(new DomDriver()); xstream.registerConverter(new UserConverter());
xstream.alias("RESPONSE",User.class);
Como podemos observar, almacenamos la respuesta en el string XML y luego nos creamos una nueva instancia del api Xstream, adems a la nueva instancia le decimos el nombre del objeto al cual queremos des-serializar el XML y el nodo padre del XML que vamos a intentar transformar. Una vez declarado todo lo anterior, slo nos queda ir recorriendo todos los nodos del XML y obteniendo los valores para las diferentes etiquetas. Eso lo realizamos de la siguiente manera:
User user = null; ArrayList<User> listUser = new ArrayList<User>(); reader.moveDown(); // we are in MULTIPLE while(reader.hasMoreChildren()){ user = new User();
94
UAX Andriod Moodle

reader.moveDown(); // SINGLE reader.moveDown(); // First KEY reader.moveDown(); // VALUE tag user.setId(reader.getValue().toString()); siguiente(reader);
Memoria
//USERNAME // Second KEY. Have a look at the method hasMoreChildren() user.setName(reader.getValue()); siguiente(reader); //FIRSTNAME user.setFirstName(reader.getValue()); siguiente(reader); //LASTNAME user.setLastName(reader.getValue()); siguiente(reader); //email user.setEmail(reader.getValue()); siguiente(reader); //auth user.setAuth(reader.getValue()); siguiente(reader); //confirmed user.setConfirmed(Boolean.parseBoolean(reader.getValue())); siguiente(reader); //idnumber user.setIdNumber(reader.getValue()); siguiente(reader); //emailstop user.setEmailStop(Boolean.parseBoolean(reader.getValue())); siguiente(reader); //lang user.setLang(reader.getValue()); siguiente(reader); //theme user.setTheme(reader.getValue()); siguiente(reader); //timezone user.setTimeZone(reader.getValue()); siguiente(reader); //mailformat user.setMailFormat(Boolean.parseBoolean(reader.getValue())); siguiente(reader); //description
95
UAX Andriod Moodle

user.setDescription(reader.getValue()); siguiente(reader); //city user.setCity(reader.getValue()); siguiente(reader); //country user.setCountry(reader.getValue()); siguiente(reader); //customfields user.setCustomFields(reader.getValue()); reader.moveUp(); reader.moveUp(); reader.moveUp(); listUser.add(user); }
Memoria
return listUser;
Como se puede observar en el cdigo de JAVA, lo que devuelve la funcin que se encarga de la desserializacin es un ArrayList de objetos User, esto es debido a que en el XML puede haber ms de un usuario. Para recorrer el XML, tenemos que ir accediendo a cada nodo de manera individual, para ello debamos ir avanzando en el rbol del XML y obteniendo todos los valores de los nodos hojas. Esto ser realizaba de la siguiente manera:
public void siguiente(HierarchicalStreamReader reader){ reader.moveUp(); reader.moveUp(); reader.moveDown(); reader.moveDown();
Como se puede ver en la funcin, se le pasaba el reader, que es la posicin dnde nos encontrbamos y mediante ese reader nos podamos desplazar a las siguientes posiciones. Todo ello da como resultado un arrayList con la lista de los datos de los usuarios que queramos consultar:
96
UAX Andriod Moodle
Memoria
97
UAX Andriod Moodle
Memoria
ANEXO III Tecnologas Utilizadas

En este documento se explicar de una manera ms tcnica y ampliada las tecnologas que se han empleado para la construccin y desarrollo de la aplicacin. Para la construccin de esta aplicacin, se han utilizado varas tecnologas, como servicios web, protocolos de autenticacin. Tambin para llevar un control de versiones durante la construccin se ha utilizado el svn que proporciona google (googlecode). Sin ms prembulos pasamos a detallar cada una de las tecnologas aplicadas.
1. REST
Antes de explicar y detallar el protocolo REST, vamos a hablar un poco de qu es un servicio web?. Ya que REST es un protocolo de comunicacin que se basa a partir de los web services (servicios web). En la actualidad son muy utilizados gracias a su simplicidad ya que hacen muy modulables e independientes las aplicaciones.
1.1 Qu es un servicio web?
El consorcio W3C define los Servicios Web como sistemas software diseados para soportar una interaccin interoperable maquina a mquina sobre una red. Los Servicios Web suelen ser APIs Web que pueden ser accedidas dentro de una red (principalmente Internet) y son ejecutados en el sistema que los aloja. [Ref6] La definicin de Servicios Web propuesta alberga muchos tipos diferentes de sistemas, pero el caso comn de uso se refiere a clientes y servidores que se comunican mediante mensajes XML que siguen el estndar SOAP.
En los ltimos aos se ha popularizado un estilo de arquitectura Software conocido como REST (Representational State Transfer). Este nuevo estilo ha supuesto una nueva opcin de estilo de uso de los Servicios Web.
1.2 Por qu utilizar REST?
Una de las dudas tpicas a la hora de integrar dos subsistemas heterogneos es si usar web services o REST. Evidentemente, si los dos subsistemas estuvieran desarrollados con el mismo lenguaje de programacin, la integracin obvia sera aprovechar lo que nos facilitase ese lenguaje, como puede ser RMI o .NET Remoting por citar slo dos ejemplos. 98
UAX Andriod Moodle
Memoria
Pero a lo que iba. Resulta que tenemos que integrar dos mdulos que estn desarrollados en dos entornos diferentes; o a lo mejor el requisito es que se comuniquen por internet, aunque compartan lenguaje de programacin. En estos casos, hay que estudiar si es mejor realizar esta integracin mediante web services o con llamadas REST. Vamos a ver las ventajas y desventajas de hacerlo de una manera o de otra. Los web services tienen como principal ventaja que cualquier entorno de desarrollo (Eclipse, Netbeans, Visual Studio, etc.), dispone de herramientas para generar un cliente a partir de un WSDL o exponer los mtodos de una clase como servicios web. No obstante, es muy recomendable hacer una prueba de concepto antes de decidirse porque si el cliente y el servidor de servicios web no estn basados en las mismas bibliotecas, podemos tener problemas de compatibilidad. Como ejemplo, si tenemos un cliente .NET en una PDA y un servicio web en J2EE (que use las bibliotecas Axis, por ejemplo), es posible que si tenemos un dato de tipo timestamp, el valor sea diferente en la parte JAVA y en la parte .NET. Esto es debido a que en JAVA se usa el formato UNIX (segundos transcurridos desde la medianoche UTC del 1 de Enero del ao 1970), mientras que en .NET esta cifra son el nmero de intervalos de 100 nanosegundos transcurridos desde las 12:00 AM del 1 de Enero del ao 1. Otros problemas de compatibilidad pueden ser que el valor por defecto de las variables no inicializadas sea null en un lado y otros en la otra parte (0 para valores numricos, "" para strings, etc.). Pero quiz lo ms fcil de detectar sea la compatibilidad a la hora de encapsular ficheros dentro de un web service: ya que hay varios mecanismos (SwA - SOAP with Attachments, DIME o MTOM), es posible que si las bibliotecas son distintas en cliente y servidor, no exista una manera compatible de transferir un fichero, teniendo que recurrir a soluciones de contingencia como montar un servicio intermedio (desarrollado con el mismo lenguaje de programacin y bibliotecas que el servidor de servicios web) que reciba el fichero como parte de un form-multipart y que luego lo encapsule de forma compatible para el destinatario final (el servicio web). Por otro lado, los web services nos proporcionan otras ventajas como el tipado fuerte (en el WSDL est definido de qu tipo son las variables, incluso en el caso de objetos complejos) o los estndares WS-*: WS-I BasicProfile, WS-Security,WS-Addressing, WS-RM o WS-Policy. Eso s, si los vais a utilizar, es mejor asegurarse de la compatibilidad entre bibliotecas si son distintas en cliente y servidor. En el caso de utilizar REST, perdemos lo del tipado fuerte y los mecanismos estndares WS-* mencionados anteriormente, pero ganamos universalidad: muchos dispositivos programables son capaces de hacer peticiones HTTP. Eso significa que podemos integrar una aplicacin desarrollada en J2ME con nuestro servidor sin necesidad de que soporte la JSR para web services, por ejemplo. 99
UAX Andriod Moodle
Memoria
Hasta hace poco, no haba manera de generar clientes de manera automtica para hacer invocaciones REST. Afortunadamente, descubr que exista la libreraJersey del proyecto GlassFish, que permite desarrollar tanto servicios de servidor basados en REST (simplemente con etiquetas en los lugares oportunos) como clientes que los consuman de manera automtica. Esto es debido a que los servicios generados con esta librera despliegan un descriptor WADL muy similar al WSDL de los web services tradicionales, por lo que luego se puede partir de ah para generar los clientes correspondientes. [Ref7] Para subir o bajar ficheros si optamos por esta modalidad, basta con utilizar comunicaciones HTTP estndar como POST (con un form-multipart, por ejemplo) o GET (una simple peticin a la URL de un fichero); ambos mecanismos son sencillos de implementar y hay muchos ejemplos en internet en casi cualquier lenguaje de programacin. As que, como veis, elegir uno u otro mtodo de integracin requiere una breve pausa para reflexionar y hacer las pruebas oportunas para asegurarnos de que no va a haber problemas de incompatibilidad que nos puedan dar sorpresas en medio del desarrollo. Dedicarle unas jornadas a estas pruebas puede ahorrarnos semanas enteras de problemas cuando el proyecto ya est lanzado.
1.3 Conclusiones
Una vez que hemos visto todas las bondades que tiene consumir servicios web y utilizar protocolos REST, vamos a dar la opinin personal de utilizar estas dos herramientas. En general, yo veo muy interesante consumir funciones mediante servicios web ya que proporcionan muchas ventajas. Las principales ventajas que yo encuentro son las siguientes: 1. Proporcionan interoperabilidad entre aplicaciones software. Como es nuestro caso, que podemos consumir funciones escritas en php utilizando JAVA (Android). Todo esto de manera independiente de la plataforma instalada, de las dependencias de las aplicaciones que consumimos... nicamente tenemos que conocer los parmetros que necesitan de entrada las funciones que queremos consumir y listo, a esperar respuesta. 2. Los estndares de web service estn basados en texto, es decir, es muy fcil acceder a su contenido y entender su funcionamiento. 3. Al basarse en el protocolo de comunicacin HTTP, aprovechan los sistemas de seguridad que este utiliza, como pueden ser firewall. Todo ello sin cambiar reglas de filtrado. Algunas de las desventajas que tienen los web services, es que carecen de documentacin. Como ha sido el caso de este proyecto, en el que las funciones y la manera de consumirlas, estn escasa o 100
UAX Andriod Moodle nulamente documentadas.
Memoria
2. Token
Como hemos mencionado anteriormente, el sistema que hemos utilizado para autenticar a los usuarios en la aplicacin y poder consumir las funciones es mediante token. Una de las razones de porque hemos utilizado este sistemas es porque, el token es identificativo de cada usuario, lo proporciona Moodle de manera automtica y porque facilita mucho el control de la seguridad y que un usuario no identificado con fines malvados, acceda al sistema. Como en el apartado de REST, pasamos a introducir un poco que es la seguridad antes de adentrarnos en los token.
2.1 Qu es un token de seguridad?
Un token de seguridad (tambin token de autenticacin o token criptogrfico) es un dispositivo electrnico que se le da a un usuario autorizado de un servicio computarizado para facilitar el proceso de autenticacin. Los tokens electrnicos tienen un tamao pequeo que permiten ser cmodamente llevados en el bolsillo o la cartera y son normalmente diseados para atarlos a un llavero. Los tokens electrnicos se usan para almacenar claves criptogrficas como firmas digitales o datos biomtricos, como las huellas digitales. Algunos diseos se hacen a prueba de alteraciones, otro pueden incluir teclados para la entrada de un PIN. Existe ms de una clase de token. Estn los bien conocidos generadores de contraseas dinmicas "OTP" y la que comnmente denominamos tokens USB, los cuales no solo permiten almacenar contraseas y certificados, sino que permiten llevar la identidad digital de la persona. [Ref8]
2.2 Por qu utilizar token de seguridad?
El consumo de los servicios a travs de un sistema de informacin con frecuencia requiere utilizar formatos token de seguridad. Los proveedores de servicios y los consumidores estn repartidos en diferentes dominios de seguridad utilizando diferentes tipos de token o diferentes tecnologas de implementacin que no dan soporte a un conjunto comn de formatos token. Los servicios web que utilizan SOAP para el envo de mensajes han tenido la suerte de contar con la especificacin Web Services Security (WS-SEC), la cual les permite incluir tokens de seguridad en la cabecera SOAP. 101
UAX Andriod Moodle
Memoria
Mensaje SOAP con WS-SEC

7 Imgen extrada de http://www.prise.es/blog/wp-content/uploads/2009/12/wssec-soap.png
Los token de seguridad ms comn en WS-SEC son: Nombre de usuario: token donde se incluye el nombre de usuario y la contrasea, para poder autenticar al usuario. Certificados digitales: token donde se incluye el certificado digital del usuario. Aserciones SAML: token donde se incluye una asercin SAML que incluye informacin sobre el usuario. De esta forma, se pueden proteger servicios web clsicos sin ningn problema de interoperabilidad, ya que existen numerosas implementaciones de WS-SEC para casi cualquier tipo de lenguaje de programacin. Para el caso de un escenario donde tenemos servicios web tipo REST, nos encontramos con un gran problema ya que el estndar WS-SEC no puede ser aplicado, ya que al usar peticiones HTTP estndares no exista forma de incluir dichos token de seguridad sin modificar los parmetros de cada peticin, y no existe ningn estndar que cubra la necesidad de enviar tokens de seguridad en dicho escenario. Aunque el token de nombre de usuario (o Username Token) de WS-SEC podra mapearse sin muchos problemas al uso de HTTP Auth, si es cierto que no existe ninguna solucin si nuestra arquitectura utiliza tokens basados en certificados digitales o aserciones SAML. Afortunadamente, la semana pasada se public un draft a travs de la IETF para la autenticacin HTTP basada en tokens. Este draft busca dar una solucin a la autenticacin a travs de tokens de OAuth, pero ofrece un modelo genrico que puede ser aprovechado por otro tipo de tokens ms clsicos como los comentados ms arriba. As, basndonos en dicho draft, una forma de proteger nuestros servicios web tipo REST utilizando certificados digitales quedara tal como describe el siguiente ejemplo: 102
UAX Andriod Moodle

GET /resource/1 HTTP/1.1 Host: example.com Authorization: Token token=h480djs93hd8yZT4=, class=x509, method=rsassa-pkcs1-v1.5-sha-256, nonce=dj83hs9s, timestamp=137134190, auth=djosJKDKJSD8743243/jdk33klY=
Memoria
Donde, token: es el certificado digital del usuario en base 64. class: indica el tipo de token, en este caso si es x509 significa que es un certificado digital. method: su valor ser siempre rsassa-pkcs1-v1.5-sha-256, ya que de esta forma incluiremos un resumen o hash del mensaje enviado a travs de la clave privada del usuario, tal como especifica dicho draft. nonce: es una cadena aleatoria. timestamp: es el timestamp del cliente cuando gener dicha peticin. auth: es el resumen o hash calculado usando la clave privada del usuario. Para el caso de querer proteger el servicio web tipo REST utilizando aserciones SAML, tendramos una peticin de este estilo:
GET /resource/1 HTTP/1.1 Host: example.com Authorization: Token token=h480djs93hd8yZT4=, class=samlv2.0, method=none
Donde, token: es la asercin SAML del usuario. class: indica el tipo de token, en este caso si es samlv2.0 significa que es una asercin SAML. method: su valor ser siempre none. En este caso, no nos hemos detenido en si la asercin SAML es key-of-holder or sender-voucher, ya que podramos cambiar el method al disponer el cliente acceso directo al par de claves privadas y pblicas del usuario.
103
UAX Andriod Moodle [Ref9]

2.2 Conclusiones
Memoria
En esta parte del documento, se ha intentado mostrar las ventajas de la autenticacin de tokens. Por ltimo, vamos a mostrar la estructura tpica en la comunicacin mediante token, utilizando un diagrama de secuencia.
3. SVN (Subversion)
SVN es un sistema que nos permite llevar el control de lo que hemos construido. Esta herramienta es fundamental a la hora de trabajar en equipo para evitar pisar el trabajo que ha realizado otro compaero. Las ventajas y las posibilidades de utilizar un sistema de control de versiones son inmensas. A continuacin procedemos a explicar en qu consiste un sistema de control de versiones SVN.
3.1 Qu es SVN?
Subversion es un sistema de control de versiones diseado especficamente para reemplazar al popular CVS, el cual posee varias deficiencias. Es software libre bajo una licencia de tipo Apache/BSD y se le conoce tambin como svn por ser el nombre de la herramienta utilizada en la lnea de comandos. Una caracterstica importante de Subversion es que, a diferencia de CVS, los archivos versionados no tienen cada uno un nmero de revisin independiente, en cambio, todo el repositorio tiene un nico nmero de versin que identifica un estado comn de todos los archivos del repositorio en un instante determinado. 104
UAX Andriod Moodle
Memoria
Subversion puede acceder al repositorio a travs de redes, lo que le permite ser usado por personas que se encuentran en distintos ordenadores. A cierto nivel, la posibilidad de que varias personas puedan modificar y administrar el mismo conjunto de datos desde sus respectivas ubicaciones fomenta la colaboracin. Se puede progresar ms rpidamente sin un nico conducto por el cual deban pasar todas las modificaciones. Y puesto que el trabajo se encuentra bajo el control de versiones, no hay razn para temer por que la calidad del mismo vaya a verse afectada si se ha hecho un cambio incorrecto a los datos, simplemente deshaga ese cambio. [Ref10]
3.2 Por qu utilizamos SVN?
Uno de los principales motivos por los que hemos decidi utilizar SVN, es porque existen muchas plataformas gratuitas que se integran a la perfeccin con eclipse y permiten montar y gestionar el control de versiones. En nuestro caso, eclipse, que es la plataforma de desarrollo elegida, permite la posibilidad de instalar el plugin de svn, el cual facilita mucho las cosas y realiza de manera casi automtica el control de versiones. En la siguiente figura mostramos eclipse con el plugin svn, en la que se puede ver la integracin con el entorno de desarrollo.
Adems de todo esto, SVN dispone de las siguientes ventajas: Se sigue la historia de los archivos y directorios a travs de copias y renombrados.
105
UAX Andriod Moodle Las modificaciones (incluyendo cambios a varios archivos) son atmicas.
Memoria
La creacin de ramas y etiquetas es una operacin ms eficiente. Tiene costo de complejidad constante (O(1)) y no lineal (O(n)) como en CVS. Se envan slo las diferencias en ambas direcciones (en CVS siempre se envan al servidor archivos completos). Puede ser servido mediante Apache, sobre WebDAV/DeltaV. Esto permite que clientes WebDAV utilicen Subversion de forma transparente. Maneja eficientemente archivos binarios (a diferencia de CVS que los trata internamente como si fueran de texto). Permite selectivamente el bloqueo de archivos. Se usa en archivos binarios que, al no poder fusionarse fcilmente, conviene que no sean editados por ms de una persona a la vez. Cuando se usa integrado a Apache permite utilizar todas las opciones que este servidor provee a la hora de autentificar archivos (SQL, LDAP, PAM, etc.).
3.3 Conclusiones
Como hemos mencionado anteriormente, en la actualidad un equipo de desarrollo de software necesita una herramienta para llevar el control de versiones. SVN permite realizar este control de versiones y adems existen herramientas gratuitas para dicha actividad. Teniendo en cuenta todo esto, la eleccin de este sistema era muy fcil, por todas las ventajas que dispone y lo fcil que es implementarlo. Por ltimo mostramos una captura de pantalla donde se puede ver la estructura del svn en googleCode.
106
UAX Andriod Moodle
Memoria
107

Memoria 54577

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Memoria 54577

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD ALFONSO X EL SABIO

ESCUELA POLITCNICA SUPERIOR

PROYECTO FIN DE CARRERA

Abel Fernndez Alfonso Octubre 2010

UNIVERSIDAD ALFONSO X EL SABIO

Aplicacin Android para interactuar con Moodle a travs de servicios web

FIRMA DEL DIRECTOR DEL PROYECTO

FIRMA DEL ALUMNO

UAX Andriod Moodle

UAX Andriod Moodle

UAX Andriod Moodle

UAX Andriod Moodle

UAX Andriod Moodle

1.4.2 Arquitectura de Android

La arquitectura interna de la plataforma Android, est bsicamente formada por 4 componentes:

UAX Andriod Moodle

1.4.3 Notas sobre Android

UAX Andriod Moodle

2 Imgen extrada de HTTP://www2.configurarequipos.com/imgdocumentos/android/htc-magic-vodafone.jpg

UAX Andriod Moodle

2. Servicios Web En Android

2.1 Por qu REST?

3 Imgen extrada de HTTP://dotnetslackers.com/Community/blogs/xun/REST.jpg

UAX Andriod Moodle Ventajas de REST:

2.2 Problemas encontrados

UAX Andriod Moodle

4 Imgen extrada de HTTP://www.w3.org/2005/Talks/1114-hh-ecows/web_service1.png

UAX Andriod Moodle

3. Organizacin Del Proyecto

UAX Andriod Moodle

UAX Andriod Moodle

UAX Andriod Moodle

UAX Andriod Moodle

3. Destinatarios y sugerencias de lectura

UAX Andriod Moodle HTTP://www.oracle.com/technetwork/JAVA/codeconvtoc-136057.html

UAX Andriod Moodle

UAX Andriod Moodle

3. Clases de usuario y caracterstica

UAX Andriod Moodle conv.android.Moodle (capa de negocio)

UAX Andriod Moodle Preferences.JAVA

UAX Andriod Moodle

Secuencia de respuesta Requisitos funcionales -

Prioridad Secuencia de respuesta

RPU004 Descripcin Prioridad Secuencia de respuesta

UAX Andriod Moodle

Prioridad Secuencia de respuesta

Prioridad Secuencia de respuesta

Prioridad Secuencia de respuesta

UAX Andriod Moodle

UAX Andriod Moodle

6 Imagen extrada de HTTP://developer.android.com/resources/tutorials/views/index.html

UAX Andriod Moodle

Sistema Operativo Browser

UAX Andriod Moodle

UAX Andriod Moodle

UAX Andriod Moodle

Nombre Actor principal Actor secundario Objetivo en contexto Precondiciones

UAX Andriod Moodle

2. Tabla caso de uso de listar usuarios por id

Nombre Actor principal Actor secundario Objetivo en contexto Precondiciones

Prioridad Disponibilidad Frecuencia de uso

Imprescindible Fase inicial Habitual 38

3. Tabla caso de uso de editar usuarios