API de servicios web orientados a accesibilidad

API de servicios web orientados a accesibilidad Sheila Plaza Estévez Nerea Ramírez Lamela Carmen Acosta Morales Directores: Raquel Hervás Ballesteros Gonzalo Rubén Mendez Pozo Trabajo de fin de grado del Grado en Ingeniería Informática Facultad de Informática Universidad Complutense de Madrid Curso 2015-2016 Documento maquetado con T EXiS v.1.0. API de servicios web orientados a accesibilidad Sheila Plaza Estévez Nerea Ramírez Lamela Carmen Acosta Morales Directores: Raquel Hervás Ballesteros Gonzalo Rubén Mendez Pozo Trabajo de fin de grado del Grado en Ingeniería Informática Facultad de Informática Universidad Complutense de Madrid Curso 2015-2016 Índice 1. Introducción 11 1.1. Motivación ............................ 11 1.2. Objetivo.............................. 12 1.3. Organización del proyecto . . . . . . . . . . . . . . . . . . . . 13 2. Introduction 15 2.1. Motivation............................. 15 2.2. Goals ............................... 16 2.3. Project management . . . . . . . . . . . . . . . . . . . . . . . 16 3. Estado de la Cuestión 19 3.1. API: Definiciones y tipos . . . . . . . . . . . . . . . . . . . . . 19 3.1.1. APIs de Servicio Web . . . . . . . . . . . . . . . . . . 20 3.1.2. API: Ejemplos . . . . . . . . . . . . . . . . . . . . . . 22 3.2. REST: Primeros conceptos . . . . . . . . . . . . . . . . . . . . 24 3.2.1. Principios REST . . . . . . . . . . . . . . . . . . . . . 25 3.2.2. Métodos en REST . . . . . . . . . . . . . . . . . . . . 27 3.3. Servicios de Accesibilidad . . . . . . . . . . . . . . . . . . . . 30 3.4. Análisis de APIs disponibles . . . . . . . . . . . . . . . . . . . 37 3.5. Conclusiones y elementos a utilizar . . . . . . . . . . . . . . . 41 4. Planteamiento del proyecto 43 5. Servicios 47 5.1. Aspectos comunes de los servicios utilizados . . . . . . . . . . 47 5.2. Servicio palabra sencilla . . . . . . . . . . . . . . . . . . . . . 52 5.3. Servicio sinónimos . . . . . . . . . . . . . . . . . . . . . . . . 54 5.4. Servicio convertir a pictograma . . . . . . . . . . . . . . . . . 57 5.5. Servicio antónimos . . . . . . . . . . . . . . . . . . . . . . . . 60 5.6. Servicio definiciones . . . . . . . . . . . . . . . . . . . . . . . 63 5.7. Servicio traducir a inglés . . . . . . . . . . . . . . . . . . . . . 66 5.8. Serviciolema ........................... 68 v vi Índice 5.9. Servicio convertir a palabra sencilla . . . . . . . . . . . . . . . 70 6. Desarrollo de la página Web de representación de la API 75 6.1. Página principal . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.2. Páginas secundarias . . . . . . . . . . . . . . . . . . . . . . . 77 7. Desarrollo de una aplicación de ejemplo de los servicios 83 7.1. Interfaz gráfica de la aplicación. . . . . . . . . . . . . . . . . . 84 7.2. Elementos de implementación del diseño . . . . . . . . . . . . 90 7.3. Implementación de la aplicación . . . . . . . . . . . . . . . . . 93 8. Conclusión del proyecto y trabajo futuro 99 8.1. Conclusión............................. 99 8.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 100 9. Project conclusions and future work 103 9.1. Conclusions............................103 9.2. Futurework............................104 10.Aportaciones individuales 107 10.1. Sheila Plaza Estévez . . . . . . . . . . . . . . . . . . . . . . . 107 10.2. Nerea Ramírez Lamela . . . . . . . . . . . . . . . . . . . . . . 110 10.3. Carmen Acosta Morales . . . . . . . . . . . . . . . . . . . . . 111 Bibliografía 115 Índice de figuras 3.1. Esquema de Servicios Web . . . . . . . . . . . . . . . . . . . . 22 3.2. Estructura básica de arquitectura REST . . . . . . . . . . . . 24 3.3. Estructura de Servicios Uniformes . . . . . . . . . . . . . . . 25 3.4. Estructura sin estado . . . . . . . . . . . . . . . . . . . . . . . 26 3.5. Estructura general de servicio REST . . . . . . . . . . . . . . 27 3.6. Diseño de API REST . . . . . . . . . . . . . . . . . . . . . . . 29 3.7. RESTvsSOAP.......................... 29 3.8. Ejemplo de resultado obtenido con pictotraductor . . . . . . . 32 3.9. Ejemplo de resultado en aplicación web de XText. . . . . . . 34 3.10. Ejemplo de resultado en AraTraductor. . . . . . . . . . . . . . 34 3.11. Resultado del editor predictivo de mensajes en pictogramas. . 35 3.12. Ejemplo de funcionalidad de la web NavegaFacil. . . . . . . . 36 3.13.GoogleInicio ........................... 37 3.14.GoogleEjemplo.......................... 38 3.15. Facebook Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . 39 3.16.FacebookInicio.......................... 40 3.17. Twitter inicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.18. Twitter Ejemplo. . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1. Diagrama explicativo del proyecto. . . . . . . . . . . . . . . . 45 5.1. Paquete con los servicios en Eclipse. . . . . . . . . . . . . . . 47 5.2. Archivoweb.xml ......................... 48 5.3. Archivo web.xml para URL completa . . . . . . . . . . . . . . 49 5.4. Uso de @PathParam . . . . . . . . . . . . . . . . . . . . . . . 50 5.5. Fragmento del archivo 5000_formas.TXT de la RAE. . . . . . 53 5.6. Diagrama explicativo del servicio palabras sencillas . . . . . . 54 5.7. Ejemplo de resultado de sinónimos en XML . . . . . . . . . . 55 5.8. Ejemplo de resultado de sinónimos en JSON . . . . . . . . . . 55 5.9. Ejemplo de consulta “compraría” en WordReferences. . . . . . 56 5.10. Diagrama explicativo del servicio sinonimos. . . . . . . . . . . 57 vii viii Índice de figuras 5.11. Ejemplo de consulta a “frase” con la frase “ropa de verano”. . 58 5.12. Ejemplo de consulta a “palabra” con la palabra “jugar”. . . . . 58 5.13. Diagrama explicativo del servicio pictograma. . . . . . . . . . 59 5.14. Resultado devuelto de la búsqueda de “comer” en hypatia. . . 60 5.15. Imagen de ejemplo de representación de antónimos en WordReference. ............................ 60 5.16. Llamada a antónimos en formato JSON de la palabra “subir”. 61 5.17. Llamada a antónimos en formato XML de la palabra “subir”. 61 5.18. Diagrama explicativo del servicio antónimos. . . . . . . . . . . 62 5.19. Ejemplo de la llamada a definición de WordReference con “niño”. 63 5.20. Etiquetas de interés del código de definición en WordReference. 64 5.21. Llamada a definición en formato JSON de la palabra “luz”. . . 65 5.22. Llamada a definición en formato XML de la palabra “luz”. . . 65 5.23. Diagrama explicativo del servicio definiciones. . . . . . . . . . 66 5.24. Ejemplo de traducción en XML . . . . . . . . . . . . . . . . . 67 5.25. Ejemplo de traducción JSON . . . . . . . . . . . . . . . . . . 67 5.26. Diagrama explicativo del servicio de traducción a Inglés. . . . 68 5.27. Ejemplo de llamada al servicio lema con la palabra “consumía” enXML............................... 69 5.28. Ejemplo de consulta a “Buscar palabra”. . . . . . . . . . . . . 69 5.29. Diagrama explicativo del servicio lema. . . . . . . . . . . . . . 70 5.30. Ejemplo de llamada de conversion con la palabra “Rebuscar” enXML............................... 72 5.31. Ejemplo de llamada de conversion con la palabra “Rebuscar” enXML............................... 72 5.32. Diagrama explicativo del servicio de conversión . . . . . . . . 73 6.1. Página inicial de la API . . . . . . . . . . . . . . . . . . . . . 76 6.2. Panel superior con feedback en el posicionamiento sobre Inicio. 77 6.3. Panel izquierdo con feedback en posicionamiento de servicio. . 78 6.4. Ejemplo de descripción del servicio “Comprobar palabra”. . . 79 6.5. Ejemplo de como llamar a las URLs de “Dificultad de palabra”. 79 6.6. Ejemplo de muestra de como llamar a las URLs de “Pictograma”. 79 6.7. Ejemplo de tabla de información. . . . . . . . . . . . . . . . . 80 6.8. Ejemplo de parámetros. . . . . . . . . . . . . . . . . . . . . . 80 6.9. Ejemplo de llamadas a las URLs. . . . . . . . . . . . . . . . . 81 7.1. Cabecera de la aplicación Android . . . . . . . . . . . . . . . 84 7.2. Texto de petición de palabra y el espacio para introducirla. . 85 7.3. Botones con los servicios disponibles. . . . . . . . . . . . . . . 85 7.4. Pantalla principal de la aplicación Android para tablet . . . . 86 7.5. Ejemplo de resultado de la palabra sencilla “perro” . . . . . . 87 Resumen Hoy en día vivimos en una sociedad en la que las tecnologías son accesibles para gran parte de la población y las cuales tienen como finalidad, entre otras cosas, facilitar la vida de las personas en la medida de lo posible. Este proyecto busca hacer uso de esas tecnologías para facilitar la accesibilidad a textos para cualquiera que pueda tener dificultades con ellos, en mayor o menor medida. La finalidad de nuestro proyecto no es crear la aplicación para el uso directo de las personas sino desarrollar los servicios, y el acceso a los mismos, que faciliten la implementación de estas aplicaciones. Aún así en este proyecto se crea una aplicación de ejemplo para Android, en la cual se hace uso de los servicios como muestra de un posible uso de los mismos. Para facilitar el acceso a estos servicios y la comprensión de los mismos, en este proyecto se crea también una API web en la cual quedan todos ellos explicados, como acceder a ellos, su descripción, ejemplos de llamadas y de resultados de las llamadas, en definitiva, todo lo que pueda ayudar a un desarrollador interesado en ellos a utilizarlos sin mayor problema. Las aplicaciones posibles de estos servicios son de lo mas extensas. Así, por ejemplo, en un dispositivo móvil, si un usuario está leyendo un libro y no entiende una palabra o le resulta bastante complicada, tan solo tendría que sacar el móvil, introducir la palabra en una aplicación que llamara a uno de nuestros servicios y obtener el resultado requerido de esa palabra, de forma rápida y cómoda. El proyecto queda dividido en tres partes: el desarrollo de los servicios de accesibilidad, la web de la API explicando cada uno de estos servicios y una aplicación Android de ejemplo de utilización. 5 Abstract Nowadays we live in a society in which technologies are accessible for most of the people. These technologies have as a goal, mostly, helping people. This project’s goal is to use those technologies to make texts more accesible for whoever may have difficulties with them. This project goal is not develop an aplication which makes the accesibility to texts easier, but to create the services that can help to develop those kind of aplications. However, we have developed and example aplication. To ease the access and undertanding of those services, this project creates an API that explains each one of them, as well as their description, examples, and everything a developer might need if he is interested in using them. There are plenty of possible aplications of these services. For example, if a user has a mobile device, and he or she is reading a book and there is a word that is not easy to understand, he or she would just have to take the device, introduce the word in the aplication that is using our services, and will have the result in a easy and fast way. This project is structured in three parts, the development of the accessibility services, the API explaining each one of these services, and an Android application as an example of how to use them. 7 8 ÍNDICE DE FIGURAS Palabras Clave REST API Accesibilidad Servicio web XML JSON ÍNDICE DE FIGURAS 9 Key workds REST API Accessibility Web services XML JSON Capítulo 1 Introducción 1.1. Motivación Desde hace ya tiempo el ser humano ha buscado medios de comunicación más allá de la palabra simplemente hablada, ya sea para comunicarse directamente con otras personas cercanas, para transmitir lo que piensa o para dar a conocer una verdad que cree que concierne a otros individuos. Hoy en día eso es cada vez más posible, ya que las comunicaciones alcanzan cada vez a más gente, siendo su impacto cada vez mayor. Sin embargo, no siempre un mensaje es accesible para todo el mundo, incluso cuando físicamente se puede acceder a él. Hay muchas limitaciones que no conciernen al campo de las comunicaciones a la hora de que un mensaje pueda llegar a un público. La más obvia puede resultar el idioma en el que se transmite, y por eso es la más tratada y la primera que se lleva a cabo siendo, posiblemente, también la más sencilla de tratar. Sin embargo, una a la que no se le presta tanta atención y que es igualmente limitante es la capacidad de comprensión de un idioma para las personas que lo comparten. Esto quiere decir que, dentro de una comunidad con un mismo lenguaje, hay personas que no son capaces de entender palabras complejas que a otras personas les pueden resultar comprensibles. Este escenario se puede dar en distintas situaciones: gente con problemas de aprendizaje con alguna discapacidad que limite el mismo. Pero eso no acaba ahí. A menudo no se trata de una limitación en el aprendizaje de la persona en si misma sino un problema con el texto a leer, ya que puede tener una complejidad de términos totalmente específica del texto tratado, en el cual una persona ajena a esa serie de términos puede encontrarse perdida ante el texto. Esta situación se puede dar con asuntos legales, textos científicos, conceptos tecnológicos... Siendo conscientes de esta necesidad, en la Facultad de Informática, a lo 11 12 Capítulo 1. Introducción largo de los años, se han ido realizando diferentes proyectos de gran utilidad social tales como simplificación de textos para facilitar su comprensión, traducción de textos a pictogramas para aquellas personas que no son capaces de leerlos, reconocimiento de la complejidad de las palabras dentro de un texto... Todos estos proyectos se han ido creando a lo largo de los años en distintos lenguajes, formatos y estilos. Nuestro proyecto surge de la necesidad de darle una utilidad social a esos proyectos, haciéndolos más unificados y accesibles, mediante una API web y una aplicación para Android a modo de ejemplo de uso de los recursos de la API. Finalmente cabe destacar que este proyecto se enmarca dentro de otro que recibe el nombre de: IDiLyCo: inclusión digital, lenguaje natural y comunicación. TIN2015-66655-R (MINECO/FEDER). , el cual está cofinanciado por el Ministerio de Economía y Competitividad y el Fondo Europeo de Desarrollo Regional (FEDER) dentro del Plan Nacional de I+D+i. El objetivo del proyecto, es facilitar la comunicación y el acceso a la información digital a colectivos que, por su diversidad funcional pueden encontrar problemas a la hora de utilizar el lenguaje para comunicarse o acceder a dicha información. IDiLyCo busca el desarrollo de soluciones tecnológicas que permitan de una manera sencilla y con gran capacidad de configuración, la inclusión digital de estas personas. Ofrece a los diseñadores o programadores de nuevas herramientas que deseen permitir la inclusión digital de personas con discapacidad, integrar en sus implementaciones los servicios desarrollados en este proyecto, ahorrando así un enorme coste en investigación y desarrollo de estas tecnologías accesibles . 1.2. Objetivo Nuestro objetivo, como acabamos de ver, es conseguir que los recursos de mejora de la comunicación estén unificados, completos y accesibles para todo aquel que quiera utilizarlos. Además aportaremos ejemplos de posibles utilizaciones de los mismos que puedan servir como ideas para potenciales interesados en estos recursos. Para ello, en este proyecto nos encargaremos de revisar los proyectos anteriores, corrigiendo fallos que pudieran tener y mejorando funcionalidades. Así mismo nos encargaremos de unificar todos estos proyectos, poniéndolos todos en un mismo lenguaje, así como en un mismo servidor y guardando la consistencia entre los diferentes servicios, tanto en la forma de entrada como 1.3. Organización del proyecto 13 en la de salida, teniendo dos formatos para la misma, XML y JSON. Además los pondremos todos en una API común para su mayor accesibilidad de cara a usuarios que puedan estar interesados en utilizarlos, así como ejemplos de utilización para que sea lo más claro posible. 1.3. Organización del proyecto Podría decirse que el proyecto está dividido en tres partes principales: servicios REST, la API de los mismos y un ejemplo Android de utilización de los mismos. Servicios: En la parte de servicios nos encargaremos de revisar servicios anteriores, hacerlos consistentes unos con otros tanto en lenguaje en el que estén implementados como en formato, corregir fallos y hacer comprobaciones de errores de los mismos. Además ampliaremos con nuevos servicios para hacerlos lo más completos posible. Para ello tendremos que analizar algunas páginas de interés como: páginas web de sinónimos y antónimos, ficheros de palabras más usadas para deducir la complejidad de las mismas, webs de definiciones y de traducciones al inglés... Todo esto tendrá como resultado un servidor con unos servicios funcionales y fácilmente accesibles que facilitarán el cumplimiento de nuestros objetivos. API:De cara a la parte de la API nos encargamos de que estos servicios resulten claramente representados y accesibles, aportando facilidad a la hora de ser utilizados, ya que la API proporcionará ejemplos de llamadas, así como ejemplos de resultados en ambos formatos, XML yJSON. La API dispondrá de un diseño sencillo, con una serie de descripciones clave para el entendimiento de la funcionalidad del servicio, así como los parámetros que necesita y lo que se espera obtener de él. Android: El ejemplo Andorid se encargará de mostrar, en una aplicación en Android, un ejemplo sencillo y conciso de como se les puede dar uso a nuestros servicios, a modo de posible idea para potenciales interesados. De este modo, al tener un ejemplo más real, más final y práctico, resulta mucho más tentador seguir tirando por ese campo, ves ya claramente con este ejemplo como se le puede sacar partido a los servicios, y como estos funcionan correctamente pudiendo probar las distintas funcionalidades en la aplicación. 3.1. API: Definiciones y tipos 21 habrá que tener estandarizado una serie de arquitecturas software válidas a utilizar en este determinado tipo de APIs. Para entender lo anteriormente mencionado hay que tener claros una serie de conceptos que son fundamentales para la comprensión de las APIs de servicios Web. Estos conceptos quedan brevemente definidos a continuación, centrándonos especialmente en REST y SOAP en el apartado 3.2. SOAP (Simple Object Access Protocol):es un protocolo estándar de comunicación entre distintos componentes software. Está basado en XML para la transmisión de sus mensajes, en los cuales quedan añadidos los parámetros de la petición. Aporta una gran ventaja y es que no requiere que los componentes software de los extremos de la comunicación corran en el mismo sistema operativo, ni siquiera que estén en el miso lenguaje de programación. Está normalmente asociado con HTTP como protocolo de transporte, aunque puede soportar otros. (Wikipedia (Marzo, 2016b)). XML (eXtensible Markup Language):es un lenguaje de marcado, como su nombre indica, diseñado para describir los datos transportados. Este lenguaje es autodresciptivo y el concepto de extensible hace referencia a que puedes crearte tus propios elementos (tags) y bloques de elementos. (Wikipedia (Abril, 2016)). XML-RPC (Remote Procedure Calls):como su nombre indica es un protocolo de llamada a procedimientos remotos. Utiliza HTTP como medio de transporte y XML como codificación y descripción de datos. Es un protocolo más antiguo que SOAP y resulta sencillo de utilizar y rápido en su ejecución. (Wikipedia (Mayo, 2016)). JSON-RPC: es similar a XML-RPC pero usa JSON en lugar de XML para transferencia de datos. (Wikipedia (Junio, 2016a)). REST (Representational State Transfer):se encarga de representar la transferencia de datos. Usa llamadas HTTP siendo así un simple mecanismo de solicitud y respuesta. (Wikipedia (Marzo, 2016a)). WSDL (Web Services Description Language):es un lenguaje de descripción de servicios web escrito en XML. Tanto mensajes como operaciones se describen de forma abstracta. Es recomendada por la W3C World Wide Web Consortium. (Wikipedia (Agosto, 2015)). Así mismo un servicio Web deberá tener un protocolo de transporte estándar, por lo que casi siempre utiliza HTTP y, por supuesto, realiza las comunicaciones en una red, generalmente a través de la Web. Deberá, también, presentar una descripción clara y detallada de la funcionalidad y el 22 Capítulo 3. Estado de la Cuestión modo de empleo del servicio que ofrece, para facilitar así su comprensión y utilización. En la figura 3.1 se muestra un esquema explicativo de los servicios web. Figura 3.1: Esquema de Servicios Web 3.1.2. API: Ejemplos En este apartado nos centraremos en las APIs más populares existentes en el mercado, describiéndolas con cierto detalle, aunque será en la sección 3.4 donde nos pararemos más detenidamente a analizar las que nos han servido más a nosotras y donde indicaremos los motivos que nos han llevado a descartar o asimilar en nuestra API el estilo y la funcionalidad de cada una de ellas. Google Maps: Es un servicio web ofrecido por Google con mapas desplazables e imágenes por satélite que permiten la localización geográfica de lugares, establecimientos, dispositivos, etc. En la página de Google Maps developers1tienes disponibles los diferentes tipos de API, así como las plataformas para las que está desarrollado. Así mismo te indica las limitaciones que presenta su uso en función de si lo realizas de manera estándar gratuita o premium de pago. Dispone de gran variedad de APIs de servicios web tales como conversión de direcciones en coordenadas, tiempo y distancia entre lugares, registro de zonas 1https://developers.google.com/maps/documentation/javascript/?hl=es 3.1. API: Definiciones y tipos 23 horarias, indicaciones entre direcciones... Además ofrece una serie de tutoriales para llevar a cabo distintas utilidades acordes con las funcionalidades ofrecidas por las APIs. Todo esto ha facilitado que estas APIs se puedan incrustar en distintos sitios web o dispositivos, pudiendo manipularlos para adaptarlos a las funcionalidades requeridas por tu servicio. Amazon S3 (Simple Storage Service)2: es un servicio web de almacenamiento en la nube por el que pagas por el espacio consumido y las peticiones realizadas. Resulta interesante que cuando intentas acceder a la API en español este te lo muestra en inglés de todas formas. Tiene el soporte sobre REST, teniendo algunos soportes limitados en SOAP también, pero no con las nuevas funcionalidades de Amazon S3. La API muestra una serie de descripciones de las diferentes operaciones que se pueden realizar sobre los distintos objetos. Dispone, al igual que Google, de numerosos ejemplos y descripciones de las distintas funcionalidades que se pueden realizar. También describe distintos códigos de error. Facebook3: es una red social, una de las más populares y extendidas en la actualidad, que permite compartir publicaciones, fotos, información, etc. Este sitio web tiene muchísimas posibilidades de negocio debido a que tiene un gran número de usuarios interaccionando con él. Esto hace que exista gran interés en desarrollo de funcionalidades que puedan, de algún modo, aprovechar este amplio publico. En este aspecto Facebook tiene una serie de servicios muy útiles para la captación de clientes así como para analizar el rendimiento de tu aplicación. Además dispone de herramientas de marketing que pueden facilitar la labor de extender el público interesado. Disponen de una documentación bien detallada de todos los servicios que ofrecen, así como la forma de acceder a ellos y ejemplos de utilización que resultan muy concisos. Twitter4: es igualmente una red social que permite compartir breves contenidos de texto con tus amigos o con el resto de usuarios. Al igual que Facebook, dispone de grandes posibilidades porque maneja gran número de usuarios. Tiene un servicio que permite a empresas añadir publicidad en Twitter lo que proporciona un amplio abanico de probabilidades ya que, al tener tantos usuarios, el impacto de esta publicidad es muy alto. Su servicio de publicidad lo tienen dividido en 3 niveles: Developer, Basic y Standard, teniendo distintos niveles de exposición para cada uno. También tienen servicios para dar acceso a la cadena global de datos en los Tweets, lo cual es muy conveniente para hacer 2https://aws.amazon.com/es/?nc2=h_lg 3https://developers.facebook.com/products/ 4https://dev.twitter.com/overview/documentation 24 Capítulo 3. Estado de la Cuestión estrategias de marketing. Como en las anteriores, Twitter dispone, además de lo ya mencionado, de un sistema de ejemplos de código con sus correspondientes resultados, facilitando así el manejo de las APIs 3.2. REST: Primeros conceptos Como veíamos en 3.1.1 REST (REpresentational State Transfer) es una arquitectura software que se encarga de representar la transferencia de datos. Cabe destacar que se apoya en el protocolo HTTP para la transferencia de información entre máquinas. Podría decirse que tiene un estilo derivado de otras arquitecturas basadas en redes, lo cual lleva a considerársela más bien como un conjunto de arquitecturas. Es principalmente usada para la construcción de servicios web, los cuales, estando basados en REST, reciben el nombre de “servicios RESTful”, en los cuales nos centraremos más adelante en esta sección. REST se encarga, básicamente, de tratar objetos como recursos que pueden ser creados y destruidos, teniendo para ello cuatro métodos básicos: put, delete, get y post, los cuales se encargan respectivamente de crear, leer, actualizar y borrar y nos centraremos más en ellos en el apartado 3.2.2. Está basado en el principio cliente-servidor, teniendo que tener las peticiones del cliente su estado totalmente representado. Supone una separación entre cliente y servidor, teniendo que encargarse cada parte de sus componentes. Es así una arquitectura multiplataforma lo cual es uno de los motivos que la hacen ideal para ser el estilo de arquitectura software usado en WWW (World Wide Web). En la figura 3.2 se muestra un esquema de la estructura básica de una arquitectura REST. Figura 3.2: Estructura básica de arquitectura REST Otro punto importante de la arquitectura REST es que es stateless, sin estado, lo cual no significa que no se sepa el estado del cliente si no que no es el servidor el que se encarga de almacenar este estado. Es responsabilidad del cliente pasar esta información, pudiendo así el servidor alojar distintos clientes en cualquier momento, sin estar vinculado a ninguno concretamente. Todo lo anteriormente descrito nos lleva a ver que, dadas las numerosas ventajas que aporta REST, los servicios RESTful estén a la orden del día. 3.2. REST: Primeros conceptos 25 Un servicio RESTful es básicamente un servicio web que está basado en la arquitectura REST para su funcionamiento. Esta centrado en recursos y el acceso a los mismos. Es fundamental que sea sencillo y rápido, por ello tienen una identificación de los mencionados recursos mediante URIs (Uniform Resource Identifiers) para un direccionamiento global. Además disponen de uniformidad de interfaces, lo cual se traduce en las cuatro métodos anteriormente vistos de REST (put, delete, get y post). 3.2.1. Principios REST Como hemos visto en la sección 3.2, REST es una arquitectura multiplataforma, sin estado, basada en HTTP y que resulta sencilla de manejar. En este apartado nos centraremos más en definir sus principios y dar una idea clara y concisa de la importancia que tienen cada uno de ellos. Los principios básicos de las arquitecturas REST son (Burke (Noviembre, 2009) y Wikipedia (Junio, 2016b)): Uniformidad de interfaces: esta uniformidad se consigue a través de lo que HTTP es conocido como verbos, que son los métodos REST ya mencionados (get, post, delete, put). Existen otros dos menos utilizados que serían head y options, pero en esto nos centraremos más en la sección 3.2.2. Esto facilita la interacción estándar de un cliente con sus recursos y con cualquier servidor HTTP sin configuraciones especiales. En la figura 3.3 se muestra un esquema de la uniformidad. Figura 3.3: Estructura de Servicios Uniformes Sin estado (stateless): los servicios REST, como ya hemos visto antes, son servicios que no registran el estado del cliente en el servidor, sino que es el mismo cliente el que transporta esa información consigo mismo, y están representados con las URIs. Esto, junto con la separación de interfaces entre cliente y servidor, hace que los servidores sean más sencillos y escalables, lo cual permite que puedan manejar un aumento considerable en el número de recursos sin que se vea afectado 26 Capítulo 3. Estado de la Cuestión el rendimiento. Esto es de vital importancia en la Web debido a su constante crecimiento. En la figura 3.4 se muestra un esquema del principio Stateless. Figura 3.4: Estructura sin estado Identificación de recursos: este supone un punto muy importante para el correcto funcionamiento de los servicios REST ya que hace posible hacer referencia a los distintos recursos de forma única. Esto se consigue a través de las URIs, las cuales proporcionan capacidad de direccionamiento. Esto quiere decir que a través de un URI se proporciona un identificador único a un determinado recurso al cual se podrá acceder en cualquier momento a través de este. 3.2. REST: Primeros conceptos 27 En la figura 3.5 se puede apreciar la estructura general de un servicio REST. Figura 3.5: Estructura general de servicio REST 3.2.2. Métodos en REST Una vez explicados los conceptos generales de REST y sus principios vamos a pasar a definir las cuatro métodos básicos en un sistema REST5. Estos coinciden con los verbos de HTTP y son: POST, GET, PUT y DELETE que hacen referencia a las operaciones conocidas como CRUD, respectivamente, create, read, update y delete. A continuación pasamos a hablar de ellos con más detalle. POST: es el método correspondiente a la operación create, y se encarga de crear un nuevo recurso. Estos nuevos recursos creados son subordinados, se crean a partir de un recurso padre. Si la creación tiene éxito se devolverá el estado 201 correspondiente a “Created” y en la cabecera de localización el link del nuevo recurso que contendrá la ID del mismo. Se pueden producir errores en la creación de recursos, puede ser que el recuso ya exista, en cuyo caso se devolvería el estado 409 correspondiente a “Conflict” o que no se encuentre el recurso en cuyo caso el estado es 404, “Not Found”. El método POST no es idempoten5http://www.restapitutorial.com/lessons/httpmethods.html 28 Capítulo 3. Estado de la Cuestión te, lo cual quiere decir que si aplicas varias veces la misma operación al mismo elemento no vas a obtener siempre el mismo resultado. GET: es el método correspondiente a la operación read, y se encarga de leer un recurso existente. Cuando se lee un recurso este no se modifica por lo que GET es considerado un método seguro. Es, además, idempotente, ya que siempre que realices GET sobre un mismo recurso el resultado será el mismo. Si la lectura del recurso se produce sin problemas se devuelve un estado 200 correspondiente con “Ok” y una representación del mismo en XML o JSON. Si por el contrario se produce algún error este puede ser debido a recurso no encontrado “Not Found” devolviendo un estado 404 o a una incorrecta petición del recurso “Bad Request” con un estado 400. Es importante tener en cuenta que se devuelve el estado del recurso, y que no se modifica, o debe modificar el estado del servidor. PUT: es el método correspondiente a la operación update, y se encarga de actualizar un recurso. Puede igualmente ser usado para la creación de un recurso, llevando a la duda de cuando usar PUT y cuando POST. PUT se usa para crear recursos cuando tienes toda la información del recurso que te quieres crear, por lo que no tendrías que crearte el recurso partiendo de un recurso padre como ocurre en POST. Al tratarse de un método que modifica un recurso se considera como no seguro. Sin embargo, a diferencia de POST, PUT si es un método idempotente, ya que siempre que aplicas PUT de la misma forma sobre un mismo recurso obtienes los mismos resultados. Si la actualización del recurso se ha realizado con éxito este devolverá un estado 200 “Ok” o 204 si el recurso no tiene ningún contenido “No Content”. Si por el contrario se produce un error devolverá 404. DELETE: es el método correspondiente a la operación delete y se encarga de borrar un determinado recurso. Se necesitará saber el identificador del recurso para poder realizar esta operación, ya que ha de ser realizada sobre el recurso concreto. Si la operación se realiza con éxito el recurso devolverá un estado 200 “OK ” o 204 “No Content”. La operación de DELETE es idempotente, ya que realizar la misma llamada de DELETE sobre el mismo recurso dará siempre el mismo resultado, la eliminación del mismo, que el recurso ya no exista. Existen objeciones al respecto de la idempotencia del método DELETE ya que, en ocasiones, si haces varias veces sobre el mismo recurso la operación de DELETE te puede devolver un estado de error 404 “Not Found”, pero en cualquier caso el resultado sigue siendo que el recurso no exista. DELETE es a su vez un método no seguro, ya que modifica el valor de un recurso, concretamente eliminándolo. 3.2. REST: Primeros conceptos 29 Además de los métodos anteriormente mencionados, que resultan los más comúnmente utilizados cuando se trata con servicios REST, existen también métodos como: HEAD, OPTIONS y PATCH, siendo HEAD y OPTIONS métodos seguros e idempotentes solo HEAD. Debido a que son raramente utilizados no nos centraremos en dar más información sobre ellos. En la imagen 3.6 podemos ver el diseño de una API REST. Figura 3.6: Diseño de API REST En la imagen 3.7 podemos ver un ilustración de las diferencias entre SOAP y REST. Figura 3.7: REST vs SOAP 30 Capítulo 3. Estado de la Cuestión 3.3. Servicios de Accesibilidad A continuación nos centraremos en el Estado de la Cuestión con respecto a los servicios de accesibilidad relacionados con los que vamos a realizar. Para ello haremos primero un repaso muy superficial de los servicios de accesibilidad que se encuentran hoy en día en el mercado, centrándonos posteriormente en aquellos orientados a facilitar palabras o textos. Lo primero que hemos de tener en cuenta en este apartado es el concepto de accesibilidad. Para ello citamos las definiciones que nos aporta la Real Academia Española en cuanto a accesibilidad y accesible: Accesibilidad: 1. f. Cualidad de accesible. Accesible: 1. adj. Que tiene acceso. 2. adj. De fácil acceso o trato. 3. adj. De fácil comprensión, inteligible. Real Academia Española Por otro lado tenemos la definición de la Wikipedia, más concisa y clara a la hora de entender el concepto de accesibilidad que nos atañe: La accesibilidad o accesibilidad universal es el grado en el que todas las personas pueden utilizar un objeto, visitar un lugar o acceder a un servicio, independientemente de sus capacidades técnicas, cognitivas o físicas. Es indispensable e imprescindible, ya que se trata de una condición necesaria para la participación de todas las personas independientemente de las posibles limitaciones funcionales que puedan tener. Wikipedia Teniendo en cuenta esta última definición el concepto de accesibilidad que queremos tratar aquí queda mucho más claro, y es el objetivo de que todas las personas puedan utilizar un objeto, independientemente de sus capacidades. Para ello hay que tener en cuenta, a la hora de tratar dicho objeto, las limitaciones que puede presentar el acceso al mismo para personas con distintos tipos de limitaciones. Nos limitaremos a tratar las funcionalidades que se encargan de mejorar la accesibilidad en internet. Hoy en día, dada la relevancia y el extendido uso de Internet y sus numerosas aplicaciones, la importancia de los servicios de accesibilidad es cada vez 3.4. Análisis de APIs disponibles 37 3.4. Análisis de APIs disponibles Para llevar a cabo nuestro proyecto hemos buscado APIs ya existentes para tomar ideas de las mismas, tanto en diseño y organización como en contenidos. Para ello hemos analizado las diferentes estructuras de las principales APIs del momento, captando lo que más nos gusta de cada una y descartando elementos que no nos terminaban de convencer. Las APIs en las que más nos centramos a la hora de buscar fueron las de Google Maps, Facebook y Twitter. A continuación pasaremos a ver las distintas apariencias de cada una de ellas y detallar sus pros y sus contras: Google Maps: la API de Google Maps10 presenta la opción de elegir la plataforma que deseas de entrada (Android, IOS o Web). Sin embargo la página principal de Google Maps es mucho más sencilla ya que solo te da a elegir entre las plataformas y una opción de ver el directorio de productos completo, sin ninguna imagen publicitaria que distraiga o lleve a confusión. Además los ejemplos, al igual que en Facebook, también están claramente explicados, siendo muy sencillo seguir el comportamiento y la funcionalidad del código, incluso en algunos ejemplos muestran un video con el resultado obtenido al realizar determinada operación. Por ello nos hemos basado en esta API para la página de inicio de la nuestra, sin hacer distinción entre plataformas. Podemos observar en 3.13 como la página principal es sencilla y concisa, sin elementos que distraigan de lo que se anda buscando. Figura 3.13: Google Inicio 10https://developers.google.com/maps/documentation/javascript/?hl=es 38 Capítulo 3. Estado de la Cuestión En la imagen 3.14 podemos ver un ejemplo bien detallado de la funcionalidad de login con su imagen correspondiente Figura 3.14: Google Ejemplo Facebook: La API de Facebook11, aunque muy intuitiva una vez que estás dentro, tiene una presentación inicial que puede ocasionar confusión de entrada ya que dispone de una serie de imágenes que te llevan más a pensar en una campaña publicitaria. Una vez que te sitúas en lo que andas buscando resulta bastante sencilla e intuitiva, con ejemplos bastante claros y una organización concisa. Además divide claramente las funcionalidades que desarrollan en tres grandes campos: IOS, Android y Web, lo cual resulta muy útil, ya que normalmente se buscará el código para una plataforma en concreto, no importando tanto el resto de ellas. El mayor problema con la API de Facebook es que dispone de muchos niveles de profundidad, llegando a ser complicado acceder a lo que estás buscando si no tienes claro donde está, lo cual consideramos que resulta engorroso y que puede llevar a los usuarios a buscar en otras APIs en las que resulte más fácil acceder a lo que buscan concretamente. Sin embargo en la imagen 3.15 podemos ver como presentan claridad en los ejemplos facilitando así el uso del código proporcionado. En la imagen 3.16 podemos ver como de entrada parece más una página de publicidad de Facebook y puede distraer nuestra atención de lo que se busca realmente. 11https://developers.facebook.com/products/ 3.4. Análisis de APIs disponibles 39 Figura 3.15: Facebook Ejemplo Twitter: Con la web de Twitter 12 pasa un poco lo mismo que con la de Facebook, el inicio resulta mas engorroso, mostrando más publicidad sobre el tema y centrándose menos en ir más directos. En ella muestran información poco relevante, como anuncios de conferencias, que hacen que al usuario le sea mas dificil concentrarse en el propósito principal de la API. Además ponen los enlaces a los servicios con el link en vez de poner un nombre más autoexplicativo, lo cual hace que la búsqueda resulte más complicada. Por otro lado a la hora de poner los ejemplos estos resultan muy claros y de fácil manejo, y además consta de una estructura lateral en la cual puedes ver en que elemento te encuentras y moverte por otros de forma sencilla lo cual facilita moverse por las distintas funcionalidades. Esta funcionalidad nos ha resultado muy interesante y útil por lo que hemos incorporado la idea en nuestra propia API. 12https://dev.twitter.com/overview/documentation 40 Capítulo 3. Estado de la Cuestión Figura 3.16: Facebook Inicio En 3.17 observamos el inicio sobrecargado explicado anteriormente. Figura 3.17: Twitter inicio. En la imagen 3.18 podemos ver como son explicados los pasos a seguir con claridad y precisión. 3.5. Conclusiones y elementos a utilizar 41 Figura 3.18: Twitter Ejemplo. 3.5. Conclusiones y elementos a utilizar De toda la información recopilada a través del análisis realizado en este capítulo, se han sacado en claro varias ideas para poder utilizar en el desarrollo del proyecto. En primer lugar se ha visto que para realizar una buena API, esta tiene que aportar un concepto claro de las funcionalidades que ofrece, para que el usuario que decida utilizarlas tenga un esquema claro de su funcionamiento y de cómo se puede acceder a ellas. Nuestra API va a ser de tipo de servicios Web, proporcionando acceso a su servicio mediante una dirección web en una red, utilizando el estándar REST. Este tipo de estándar, permite la transferencia de datos a través de peticiones HTTP, haciendo que la comunicación sea transparente y natural, permitiendo interactuar con otros sistemas de una forma sencilla. El diseño transparente lo consigue gracias a la utilización de métodos siendo los principales y más utilizados GET,POST, DELETE y PUSH. Por último, se han analizado distintos ejemplos de APIs, donde se ha conseguido obtener una visión de algunas de las cualidades que debería tener la API que vamos a generar. La página principal tiene que ser sencilla, concisa y no tener elementos adicionales con poca relevancia que pueda dis- 42 Capítulo 3. Estado de la Cuestión traer al usuario, para que le resulte fácil acceder a la información que busca concretamente. Otra idea, es hacer que los enlaces a los servicios tengan un nombre autoexplicativo para que resulte intuitivo y, de esta forma, facilite el movimiento por las distintas funcionalidades que ofrece la API. Capítulo 4 Planteamiento del proyecto Como hemos explicado en el capítulo 1, este proyecto tenía la finalidad inicial de agrupar los servicios de accesibilidad generados durante años anteriores en la Facultad de Informática, unificándolos y facilitando que pudieran ser usados por otros desarrolladores, así como ampliándolos con nuevos servicios en el caso de disponer del tiempo necesario. Se presentan finalmente ocho tipos de servicios, una aplicación web API y una aplicación Android. Los servicios desarrollados son los siguientes: Palabra sencilla: devuelve true en caso de que una palabra se considere sencilla y false en caso contrario. El criterio utilizado para considerar a una palabra sencilla o dificil viene dado por un archivo de la RAE . Consideramos una palabra sencilla si se encuentra dentro de este archivo. Se darán más detalles cuando pasemos a hablar sobre este servicio más adelante. Los resultados de este servicios están disponibles en JSON y XML. Sinónimos: devuelve todos los sinónimos de una palabra introducida en la URL mediante un parámetro. El formato del resultado puede ser XML o JSON. Convertir a pictograma: este servicio se encarga de, dada una palabra o frase, devolver el pictograma o la secuencia de pictogramas que las representan. Este tiene dos formatos distintos de URL en función de si se va a meter una sola palabra o una frase. Antónimos: devuelve todos los antónimos de una palabra introducida en la URL mediante un parámetro. El formato del resultado puede ser XML o JSON. Definiciones: se encarga de devolver todas las definiciones de las palabra buscada mostrando solo las acepciones, sin mostrar información 43 44 Capítulo 4. Planteamiento del proyecto adicional como coloquialismos, frase hechas con esa palabra o ejemplos del uso de esas palabras con la acepción mostrada en ese momento. El formato del resultado puede ser XML o JSON. Convertir a palabra sencilla: dada una palabra introducida como parámetro en la URL de este servicio, si aplicándosele el servicio “Palabra sencilla” este devuelve false se procede a buscar un sinónimo de la palabra que sea sencillo, el cual será el resultado devuelto. En el caso de que no se encuentre sinónimo sencillo o que la palabra inicial sea sencilla, se devolverla la palabra introducida en la URL. Traducir a inglés: este servicio devuelve las traducciones a inglés de una palabra introducida en la URL. Lema: este devuelve el origen y la categoría gramatical de la palabra buscada. Estos servicios han sido desarrollados en Java, como servicios REST. Se decidió una implementación REST ya que estos servicios están basados en estándares como HTML, URL, XML, JSON, etc., siendo estos los que se querían utilizar en nuestros servicios. Para el desarrollo de los servicios en Java se ha hecho uso de la librería JSoup para analizar las páginas web usadas en nuestro proyecto como herramientas. Algunos ejemplos de las mencionadas páginas y recursos usados son: Para la definición, sinónimos y antónimos: WordReference1 Para traducción: Span¡shD!ct2 Para palabras fáciles: 1000_formas.TXT3, archivo de texto aportado por la RAE de las 1000 palabras más utilizadas en la lengua española. Se verá más sobre este archivo más adelante. El análisis de las páginas web se hace sobre su código HTML. Para ello se debe estudiar la pagina, analizando como está desarrollada y como están etiquetados los resultados que devuelve para posteriormente coger los que nos interesen de la misma. Una vez creados los servicios, para facilitar el acceso a ellos se crea la web de la API donde se aporta toda la información sobre cada uno de los servicios, tanto descripciones como modos de uso y ejemplos. Gracias a esta 1http://www.wordreference.com/es/ 2http://www.spanishdict.com/traductor/ 3http://corpus.rae.es/frec/1000_formas.TXT 45 API estos servicios pueden ser utilizados tanto por un desarrollador para la implementación de una aplicación que los utilice como herramientas, como por un usuario que tan solo quiera hacer alguna consulta mediante la web. Nuestro proyecto además de los servicios ya descritos consta de una aplicación Android a modo de ejemplo. Esta aplicación está formada por una pantalla principal donde el usuario puede introducir la palabra a consultar y seleccionar el servicio que le quiera aplicar, estando estos representados en forma de botones en la aplicación. Tras la introducción de la palabra y la selección del servicio la aplicación pasará a la pantalla secundaria en la cual se mostrará el resultado de aplicar el servicio seleccionado a la palabra introducida, con un formato sencillo indicando con una pequeña frase que servicio está devolviendo seguido del resultado. En los próximos capítulos nos centraremos en hablar sobre los servicios desarrollados, la página web de representación de la API y una aplicación en android creada con el fin de mostrar un pequeño ejemplo del uso que se le puede dar a los servicios generados. En la imagen 4.1 se puede ver un diagrama sencillo del funcionamiento del proyecto. Figura 4.1: Diagrama explicativo del proyecto. 5.2. Servicio palabra sencilla 53 Figura 5.5: Fragmento del archivo 5000_formas.TXT de la RAE. A la hora de analizar el archivo “1000_Formas.TXT” no se tienen en cuenta mayúsculas y minúsculas, dando como resultado que la búsqueda de la palabra “Casa” sería lo mismo que la de “casa”. Se consideraron dos opciones a la hora de mostrar el resultado en este servicio: “Palabra sencilla” o “Palabra difícil”: resultaba mucho más claro ya que te da la información que le preguntas al servicio. “True” o “False”: resulta más fácil de tratar por otro desarrollador. Finalmente se optó por devolver true ofalse ya que el objetivo de los servicios es que puedan ser utilizados por otros desarrolladores y de esta forma se facilita el análisis, y por tanto el uso de los mismos. En la figura 5.6 se puede ver un diagrama explicativo de como funciona 54 Capítulo 5. Servicios este servicio. En este no queda especificado el formato xml o json para hacerlo genérico para ambos, ya que funcionan de forma similar. Figura 5.6: Diagrama explicativo del servicio palabras sencillas 5.3. Servicio sinónimos Servicio que muestra los sinónimos de la palabra introducida, obteniendo la información de la página de WordReference2gracias a una consulta previa. Si la palabra no tiene sinónimos o no existe este servicio devolverá un resultado vacío. Como hemos visto en el apartado 5.1 el que devuelva un resultado vacío en lugar de un mensaje del estilo de “Sinónimo no encontrado” se debe a que resulta más inmediato de tratar para terceros si no devuelve nada, dejando ya al criterio del que utilice el servicio que hacer con el resultado final cuando este te devuelva vacío. Una vez que se ha obtenido la información de la consulta a WordReference, se analiza el resultado del html devuelto y se obtienen los diferentes sinónimos proporcionados por esta y guardándose estos en un ArrayList para luego mostrarlo, dependiendo de la opción seleccionada, en XML o JSON. La estructura general del resultado, independientemente de si es en XML o en JSON, viene dada por el siguiente esquema: 2http://www.wordreference.com/sinonimos/ 5.3. Servicio sinónimos 55 Una etiqueta “sinonimos” seguido de la etiqueta “sinonimo” (una por cada entrada/acepción que aparezca de esta palabra). A continuación podemos ver la invocación del servicio de sinónimos con la palabra “buscar”, tanto con XML como con JSON. La llamada con XML sería: http://sesat.fdi.ucm.es:8080/servicios/rest/sinonimos/xml/confundir cuyo resultado se puede ver en la imagen 5.7 Figura 5.7: Ejemplo de resultado de sinónimos en XML Mientras que la llamada con JSON quedaría: http://sesat.fdi.ucm.es:8080/servicios/rest/sinonimos/json/confundir cuyo resultado se puede ver en la imagen 5.8 Figura 5.8: Ejemplo de resultado de sinónimos en JSON 56 Capítulo 5. Servicios Cabe destacar que uno de los motivos que nos llevo a utilizar la página de WordReferences como la que nos “proporciona” los sinónimos es que, cuando buscas una palabra de la cual ellos no tienen ninguna acepción, es decir, que no se encuentra en su sistema, buscan su lema y vuelven a realizar la consulta con este, siendo el resultado de la nueva, en el caso de que lo hubiera, lo que te muestran como resultado de la búsqueda final. Además, al ser WordReference una web bastante accedida y fiable, nos aseguramos de que nuestro contenido esté actualizado y accesible. Por ejemplo, si se busca “compraría” no encuentra directamente sinónimos de la palabra “compraría” sino que la lematiza para obtener el lema de la palabra, en este caso “comprar” y nos devuelve sinónimos de “comprar”. En la imagen 5.9 se puede ver el resultado de este ejemplo. Figura 5.9: Ejemplo de consulta “compraría” en WordReferences. Para terminar de aclarar este servicio en la figura 5.10 se muestra un diagrama explicativo de como funciona. En este no queda especificado el formato xml o json para hacerlo genérico para ambos, ya que funcionan de forma similar. 5.4. Servicio convertir a pictograma 57 Figura 5.10: Diagrama explicativo del servicio sinonimos. 5.4. Servicio convertir a pictograma Servicio encargado de devolver un pictograma correspondiente a la palabra o frase pasadas por parámetro. Este tiene dos variantes de las cuales se hablará a continuación y a las cuales se accede con las siguientes URL: http://sesat.fdi.ucm.es:8080/servicios/rest/pictograma/frase/ “fraseBuscada” http://sesat.fdi.ucm.es:8080/servicios/rest/pictograma/palabra/ “palabraBuscada” En las imágenes 5.11 y 5.12 se muestran dos ejemplos de resultados obtenidos al darle el valor de “ropa de verano” a “fraseBuscada” y de “jugar” a “palabraBuscada”, respectivamente. Este servicio está basado en el proyecto “Conversor de texto a pictogramas” (Alonso et al. (2013 -2014)). En este se realiza una llamada al servicio “hypatia” de la forma: hypatia.fdi.ucm.es:5223/PictoTraductorAplicationServer/api/TraduceFrase/“palabra” En esta consulta se devuelve un JSON con los objetos encontrados en la BBDD que hagan referencia a la palabra o frase representadas por “palabra”. 58 Capítulo 5. Servicios Figura 5.11: Ejemplo de consulta a “frase” con la frase “ropa de verano”. Figura 5.12: Ejemplo de consulta a “palabra” con la palabra “jugar”. En la imagen 5.14 podemos ver un ejemplo de resultado devuelto. En este se puede observar que, para una sola palabra introducida (“comer” en este caso), se devuelven distintos resultados con bastante información en cada uno de ellos. De esta información obtenida, en este proyecto solo se cogerá el “id_url”, siendo este el atributo que indica el nombre de la imagen alojada en el directorio del servidor de “hypatia”, el cual devolverá la imagen que se anda buscando. El acceso a este sería de la siguiente forma: http://hypatia.fdi.ucm.es/conversor/Pictos/“id_url” Si el servicio no encuentra la palabra en la BBDD, hace una nueva llamada pero esta vez, en vez de buscar la palabra introducida, buscaría el lema de 5.4. Servicio convertir a pictograma 59 la misma. Es decir, si se introduce “comiendo” y no encuentra un pictograma para “comiendo”, realizaría una nueva búsqueda con la palabra “comer”. En la imagen 5.13 podemos ver un diagrama explicativo de como funciona el servicio pictograma con la llamada a frase. La llamada a palabra funciona de manera similar por lo que el diagrama sirve para ambos casos. Figura 5.13: Diagrama explicativo del servicio pictograma. El tiempo consumido en la llamada al servicio “traduceFrase” del proyecto “Conversor de texto a pictogramas” (Alonso et al. (2013 -2014)) supone un inconveniente, ya que al hacer consultas a la BBDD tarda un tiempo excesivo en mostrar la información requerida, suponiendo esto un inconveniente a la hora de llevarlo a la aplicación Android. 60 Capítulo 5. Servicios Figura 5.14: Resultado devuelto de la búsqueda de “comer” en hypatia. 5.5. Servicio antónimos En este servicio, dada una palabra, se devuelve la lista de antónimos encontrados de la misma. De nuevo, como en sinónimos, se hace una consulta a la web de sinónimos de WordReference 3, ya que esta contiene, además de la lista de sinónimos, la lista de antónimos de la palabra introducida. En la imagen 5.15 se puede ver un ejemplo de como están estos representados en WordReference. Figura 5.15: Imagen de ejemplo de representación de antónimos en WordReference. Como se puede ver en la imagen WordReference no tiene una página dedicada para los antónimos como tiene para las definiciones o sinónimos, si no que, dentro de la de sinónimos introduce una lista de antónimos resaltados en rojo, la cual es utilizada para llevar a cabo este servicio. 3http://www.wordreference.com/sinonimos/ 5.5. Servicio antónimos 61 Funciona de una manera muy similar al de sinónimos, ya que hace una consulta a la misma página web y el resultado devuelto, en formato, es muy parecido, cambiando los nombres de las etiquetas. A continuación se ve un ejemplo de cada uno de los formatos de las llamadas. La llamada JSON sería: http://sesat.fdi.ucm.es:8080/servicios/rest/antonimos/json/subir El resultado de esta llamada se puede ver en la imagen 5.16 Figura 5.16: Llamada a antónimos en formato JSON de la palabra “subir”. La llamada XML sería: http://sesat.fdi.ucm.es:8080/servicios/rest/antonimos/xml/subir El resultado de esta llamada se puede ver en la imagen 5.17 Figura 5.17: Llamada a antónimos en formato XML de la palabra “subir”. Este servicio, además, consta de una función principal donde se desarrollan las partes mas importantes para poder hacer la petición a la pagina correspondiente y el análisis del contenido. En la implementación del servicio antónimos la primera acción que se realiza es conectar con la pagina mediante la URL. Se utiliza la función URLEncoder.enode para añadirle la palabra que el usuario escriba por la URL y tenerlo en UTF-8. Una vez establecida la conexión con la web, se procede al análisis de la pagina html con la librería anteriormente nombrada JSOUP. Esta librería se encarga de buscar los textos que van acompañados por una etiqueta, por 62 Capítulo 5. Servicios ello primero se busca la etiqueta div[class=trans clickable] ya que si esta no se encontrara dentro del código html, será porque no existiría ningún resultado para la consulta. Una vez encontrada la etiqueta, no se puede dar por hecho que esta sea la valida, por ello para la implementación de este servicio, primero se observó el cogido HTML y se descubrió que el resultado que se buscaba se encontraba dentro de la primera etiqueta que aparecía con nombre div[class=trans clickable]. Dentro de la etiqueta div[class=trans clickable] se encuentran varias etiquetas li por ello se recorren todas con for hasta el fin de la etiqueta div[class=trans clickable]. Cuando se recorren las etiquetas li se extrae el texto que las acompaña y se guarda en una variable, para luego separarla por resultados, y mostrarlas con su etiqueta xml o JSON correspondiente. Cada resultado esta separado por “,” por si un resultado esta compuesto por más de una palabra, que a la hora de darle etiqueta XML o JSON no se de una a cada palabra, y se muestre como dos o mas resultados en vez de como un único resultado como debería ser. En la figura 5.18 podemos ver un diagrama explicativo de como funciona este servicio. En este no queda especificado el formato xml o json para hacerlo genérico para ambos, ya que funcionan de forma similar. Figura 5.18: Diagrama explicativo del servicio antónimos. 5.8. Servicio lema 69 Figura 5.27: Ejemplo de llamada al servicio lema con la palabra “consumía” en XML. En la imagen 5.28 podemos ver un ejemplo de resultado devuelto al consultar en la página web de “Busca palabra” la palabra “consumía”. En ella se puede ver como se muestra el origen de la palabra, en este caso “consumir”, así como las categorías gramaticales a las que puede pertenecer. Figura 5.28: Ejemplo de consulta a “Buscar palabra”. 70 Capítulo 5. Servicios Este servicio resulta útil, no solo para aportar información de una palabra dada, si no como herramienta para otros servicios como puede ser pictograma, que no requieran una palabra exacta para su funcionamiento, pudiendo usar el origen de la misma para mayor simplificación del problema. En la imagen 5.29 se puede ver un diagrama de como funciona el servicio de lema. Figura 5.29: Diagrama explicativo del servicio lema. El desarrollo de este servicio se realizó en la etapa final del proyecto por lo que, por falta de tiempo, no está del todo comprobado y desarrollado, mostrando resultados no del todo correctos en el caso de JSON, y es por eso que no se ha incluido en la aplicación de ejemplo desarrollada en Android. 5.9. Servicio convertir a palabra sencilla El objetivo de este servicio es devolver una palabra sencilla que pertenezca a la lista de sinónimos de la palabra introducida por el usuario. Es decir, si se introduce una palabra difícil, este servicio buscará en la lista de sinónimos de la palabra introducida hasta dar con uno que al aplicarle el servicio “Palabra fácil” te devuelva true. Lo primero que se hace en este servicio es llamar al visto con anterioridad de palabras sencillas (llamado palabrasSencillas) con la forma: 5.9. Servicio convertir a palabra sencilla 71 http://localhost:8080/servicios/rest/palabras/xml/“palabraBuscada” que, como se ha visto antes, devuelve un booleano con true si es una palabra fácil, es decir, si se encuentra en el archivo 1000_formas.TXT y si no la encuentra devuelve false. Si al aplicarle a la palabra el servicio de palabrasSencillas se obtiene true, entonces el servicio conversión devuelve la misma palabra introducida. Si la palabra no se encuentra en el fichero quiere decir que es una palabra difícil, y hay que intentar buscar un sinónimo de esa palabra que sea sencillo. Para ello se realiza una consulta al servicio de sinónimos: http://localhost:8080/servicios/rest/sinonimos/xml/“palabraBuscada”. Posteriormente se analiza el xml que devuelve el servicio de sinónimos con el objetivo de quedarse sólo con un String con los sinónimos analizados separados por “,”, y buscar el primer sinónimo que sea una palabra sencilla dentro de esa lista, invocando nuevamente al servicio de palabrasSencillas. Si hay algún sinónimo que sea palabra sencilla, el servicio lo devolverá como resultado obtenido y, en caso contrario, devolverá la misma palabra sobre la que se ha realizado la consulta, la palabra inicial buscada por el usuario “palabraBuscada”. El hecho de separar los Strings por “,” se debe a que hay sinónimos compuestos, es decir, que contienen más de una palabra, por lo que si se hace la división por espacios se puede coger una de las palabras de ese sinónimo y devolverse como sinónimo fácil de la misma, sin necesidad de que este lo sea. A continuación se pasa a explicar un ejemplo que aclara esta situación. Supongamos que se hace la llamada: http://sesat.fdi.ucm.es:8080/servicios/rest/conversion/xml/comer el resultado obtenido analizado sin “,” era <conversion>de</conversion>, lo cual no es un sinónimo de la palabra “comer”. Esto ocurre porque “comer” tiene un sinónimo que es “Llenar de andorga” y al separar por espacios coge “de” como sinónimo de “comer”, sacado de tratar “llenar”, “de” y “andorga” como tres palabras distintas, siendo “de” la palabra sencilla resultante. Esto se soluciona separando los sinónimos por “,”, por lo que al hacerlo de este modo si se hace la llamada: http://sesat.fdi.ucm.es:8080/servicios/rest/conversion/xml/comer devuelve <conversion>comer</conversion>, ya que no encuentra una palabra fácil que sea sinónimo de “comer”. En las imágenes 5.30 y 5.31 se pueden ver los resultados obtenidos al realizar las llamadas respectivas en XML y JSON: http://sesat.fdi.ucm.es:8080/servicios/rest/conversion/xml/rebuscar 72 Capítulo 5. Servicios Figura 5.30: Ejemplo de llamada de conversion con la palabra “Rebuscar” en XML. http://sesat.fdi.ucm.es:8080/servicios/rest/conversion/json/rebuscar Figura 5.31: Ejemplo de llamada de conversion con la palabra “Rebuscar” en XML. Este servicio se creó, además de como servicio en si mismo, como herramienta para una demostración de funcionalidad en una aplicación Android de los servicios realizados. Así se mostraba, en una sola función, el resultado de aplicar varios de los servicios, obteniendo una utilidad fácilmente aplicable a un servicio de accesibilidad, el simplificado de palabras, y por extensión de textos. Para terminar de aclarar como funciona este servicio en la imagen 5.32 se muestra un diagrama de flujo en el que queda explicado como se procede en los distintos casos. En este no queda especificado el formato xml o json para hacerlo genérico para ambos, ya que funcionan de forma similar. 5.9. Servicio convertir a palabra sencilla 73 Figura 5.32: Diagrama explicativo del servicio de conversión Capítulo 6 Desarrollo de la página Web de representación de la API En esta sección se pasará a hablar del desarrollo de la página web que funciona como API de los servicios anteriormente explicados. En esta quedarán explicados y a disposición del público los servicios, así como se indicarán las URLs para acceder a ellos y un pequeño ejemplo de llamada y su resultado. Todos los servicios mencionados en el capítulo 5 tienen un apartado en la web cuya finalidad es explicar su funcionalidad y modo de uso. En cuanto al diseño de la web es directo y auto explicativo en sus elementos, es decir, cada funcionalidad de la web viene definida por una breve descripción que resume lo que realiza. Además posee una estructura minimalista, teniendo únicamente los elementos necesarios para que quede claro su funcionamiento y así poder acceder a los servicios ofrecidos. Esto queda explicado más implícitamente en las secciones que veremos a continuación. 6.1. Página principal Como se puede observar en la imagen 6.1 la pantalla inicial consta de un panel superior con el título de la web y el escudo de Informática, un panel debajo de este con un pequeño mensaje explicativo de la web y por último, siete iconos con el nombre de cada uno de los servicios que están desarrollados. Cada uno de esos siete iconos tiene un enlace al servicio que indica su nombre, por ejemplo Sinónimo te llevará a la API de sinónimos, en la cual queda detallado este servicio y la forma de invocarlo. Como se explicaba anteriormente, la página principal es minimalista, al disponer únicamente de los elementos necesarios para acceder a cada uno de los servicios. Cada uno de ellos se ha ido añadiendo a medida que se iba incorporando en el servidor. A continuación pasamos a describir brevemente cada uno de ellos. 75 76 Capítulo 6. Desarrollo de la página Web de representación de la API Figura 6.1: Página inicial de la API Dificultad de palabras: indicaciones de como utilizar el servicio que te devuelve si la palabra introducida es fácil o no devolviendo true o false respectivamente. Sinónimos: indicaciones de como utilizar el servicio que te devuelve los sinónimos encontrados de la palabra introducida. Antónimos: indicaciones de como utilizar el servicio que te devuelve los antónimos de la palabra introducida. Definición: indicaciones de como utilizar el servicio que te devuelve las definiciones de la palabra introducida. Traducción inglés: indicaciones de como utilizar el servicio que te devuelve las distintas traducciones de la palabra introducida. Pictogramas: indicaciones de como utilizar el servicio que te devuelve los pictogramas de la palabra o frase introducidas. Se entiende como 6.2. Páginas secundarias 77 pictograma una imagen que esta relacionado con el objeto al que se refiere. Conversión fácil: indicaciones de como utilizar el servicio que te devuelve un sinónimo fácil de la palabra introducida. Si esta fuera inicialmente fácil devolvería la palabra introducida. 6.2. Páginas secundarias Se entienden como páginas secundarias aquellas en las que quedan explicados cada uno de los servicios y las URL de acceso a los mismos, con sus ejemplos de utilización. A continuación pasaremos a describir los componentes que las forman y la funcionalidad y el estilo seguidos en cada uno de ellos. Panel superior: En este queda indicada la ruta en la que el usuario se encuentra en ese momento, es decir, si el usuario se encuentra en el servicio “Sinónimos” la ruta mostrada en el panel superior sería “Inicio /Sinónimos”, ya que la página principal o inicio es considerada la página padre. Además ambos elementos en la ruta son seleccionables, tanto “Inicio” como, en este caso, “Sinónimos”, llevando a la página principal en caso de “Inicio”. Además, a la izquierda del todo aparece el escudo de Informática como logo de la página web. En la imagen 6.2 se puede ver un ejemplo de lo anteriormente explicado. Figura 6.2: Panel superior con feedback en el posicionamiento sobre Inicio. Panel izquierdo: En él se pueden encontrar enlaces a todas las APIs de todos los servicios disponibles. Seleccionando cualquiera de ellos se accede a su API correspondiente en la cual se pasará a detallar el servicio. En este panel izquierdo, cuando se sitúa el cursor encima de alguno de los nombres de los servicios, el nombre cambia de color dándole así un feedback al usuario de que el elemento es seleccionable y que producirá una respuesta si se pincha sobre él. En la imagen 6.3 se puede ver el panel izquierdo y un ejemplo del feedback anteriormente mencionado. 78 Capítulo 6. Desarrollo de la página Web de representación de la API Figura 6.3: Panel izquierdo con feedback en posicionamiento de servicio. Cuerpo: En el cuerpo se encuentra toda la información necesaria referente al servicio del que se habla. Dado que el cuerpo esta dividido en varios elementos a su vez, se verá cada uno de estos por separado, según el orden en el que aparecen en la web. •Descripción: Lo primero que se muestra es un texto con la descripción de la funcionalidad del servicio, indicándose lo que este espera recibir como parámetro así como lo que devolverá como resultado. Este queda encabezado con el nombre del servicio al que describe. En la imagen 6.4 se puede ver un ejemplo de descripción del servicio “Comprobar palabra”. •Llamadas URLs: Tras la descripción anteriormente mencionada se muestran las distintas opciones de llamadas a la URL. Estas son similares para todos los servicios salvo el de pictogramas, dos versiones distintas de llamada a URL, una para devolver el mensaje en formato JSON y la otra en XML. En el caso de pictogramas hay también dos opciones, pero en este caso no hacen referencia al formato de salida, ya que es siempre una o varias imágenes, sino a si se va a introducir una palabra o una frase a convertir a pictograma. En las imágenes 6.5 y 6.6 podemos ver ejemplo de cada uno de los casos mencionados anteriormente. 7.1. Interfaz gráfica de la aplicación. 85 En la imagen 7.2 podemos ver el TextView y el EditText anteriormente mencionados. Figura 7.2: Texto de petición de palabra y el espacio para introducirla. •Varios Buttons que son los botones donde están representados los distintos servicios ofrecidos por la aplicación, todos ellos seleccionables y con una respuesta diferente. En la imagen 7.3 podemos apreciar la disposición de los mismos. Figura 7.3: Botones con los servicios disponibles. En la imagen 7.4 se puede observar el resultado al completo de la pantalla principal de la aplicación android, y con la cual interactuará el usuario. Pantalla secundaria: los resultados mostrados en esta pantalla dependen del servicio seleccionado en la pantalla principal, aunque el diseño gráfico seguido es similar en todos los casos, variando el mensaje y resultado mostrados. •Palabra fácil: esta pantalla tiene dos posibilidades de mensajes diferentes: 86 Capítulo 7. Desarrollo de una aplicación de ejemplo de los servicios Figura 7.4: Pantalla principal de la aplicación Android para tablet “La palabra palabraIntroducida si es una palabra sencilla” o “‘La palabra palabraIntroducida no es una palabra sencilla”. En la imagen 7.5 podemos ver un ejemplo de resultado obtenido. •Buscar sinónimos: en esta pantalla dependiendo de si se encuentran sinónimos de la palabra o no, se muestran los siguientes mensajes respectivamente: “Sinónimos de palabraIntroducida :todos los sinónimos mostrados en una lista” o “No existen sinónimos de palabraIntroducida”. En la imagen 7.6 se puede ver un ejemplo del resultado obtenido en este servicio. 7.1. Interfaz gráfica de la aplicación. 87 Figura 7.5: Ejemplo de resultado de la palabra sencilla “perro” Figura 7.6: Ejemplos de sinónimos obtenidos de casa •Buscar antónimos: en esta pantalla, dependiendo de si se encuentran antónimos de la palabra o no, se muestran los siguientes mensajes respectivamente: “Antónimos de palabraIntroducida :todos los antónimos mostrados en una lista” o “No existen antónimos de palabraIntroducida”. Dado que este servicio es similar al de sinónimos mostramos en este caso la pantalla en el caso de que no se encuentren antónimos en la figura 7.7 88 Capítulo 7. Desarrollo de una aplicación de ejemplo de los servicios Figura 7.7: Ejemplos de sinónimos obtenidos de “casa” •Buscar definición: en esta pantalla se muestran las definiciones encontradas para la palabra introducida. El mensaje mostrado en la pantalla es: “Definiciones de palabraIntroducida :todas las definiciones de la palabra devueltos por el servicio”. En la imagen 7.8 vemos un ejemplo de las definiciones obtenidas para gato. Figura 7.8: Ejemplos de definiciones obtenidas de “gato” •Convertir a fácil: en esta pantalla se muestra un sinónimo sencillo de la palabra introducida. Tiene dos posibilidades a la hora de mostrar el resultado, que muestre un sinónimo de la palabra que sea sencillo o que te muestre la misma palabra introducida en caso de no encontrar sinónimos sencillos. En la imagen 7.9 podemos ver un ejemplo de conversión de “hogar” a palabra sencilla. 7.1. Interfaz gráfica de la aplicación. 89 Figura 7.9: Ejemplo de conversión de “hogar” a palabra sencilla •Traducir a inglés: en esta pantalla se muestra la traducción de la palabra al inglés. El mensaje que aparece en la pantalla es el siguiente: “Traducciones de palabraIntroducida :todas las traducciones devueltas de la palabra devueltos por el servicio”. En la figura 7.10 podemos ver un ejemplo de traducción de casa. Figura 7.10: Ejemplo de traducción de “casa” al inglés •Buscar pictograma: en esta pantalla se muestra el pictograma correspondiente a la palabra introducida. En la imagen 7.11 podemos ver un ejemplo de resultado al introducir “casa” en la pantalla principal y pulsar el botón “Buscar Pictograma”. Cómo se puede ver en las fotografías de la pantalla secundaria al lado del nombre de la aplicación aparece una flecha, cuando el usuario hace clic en esta flecha, la aplicación vuelve a la pantalla inicial donde está la opción de introducir una palabra nueva y todos botones. 90 Capítulo 7. Desarrollo de una aplicación de ejemplo de los servicios Figura 7.11: Ejemplo de pictograma de “casa” 7.2. Elementos de implementación del diseño En cuanto a implementación en Android Studio hay dos partes importantes: la carpeta dónde se alojan los archivos los .java, en la cual se encuentra el código desarrollado para las funcionalidades de la aplicación. la carpeta en la que están los .xml, donde queda implementada la interfaz gráfica y todas sus propiedades. En esta sección se hablará del contenido de la carpeta con archivos .xml, dond ese trata la implementación del diseño, viéndose en 7.3 la de las funcionalidades. Cada clase .java va acompañada de su archivo .xml. En cuanto a diseño, en las dos primeras aplicaciones de prueba se utilizó un elemento llamado LinearLayout y luego, tras probar distintas opciones, se acabó usando en la aplicación de servicios el RelativeLayout. Dentro de estos Layouts, en la aplicación han sido utilizados los siguientes elementos: TextView: se usa este elemento para mostrar todos los textos de la aplicación. Hay uno implementado para la pantalla principal y otro para la secundaria. Este elemento tiene una propiedad que hace que el texto pueda ser editable, pero no queda habilitada en la aplicación ya que este elemento lo se usa únicamente para mostrar texto, sin querer que este pueda ser modificado. 7.2. Elementos de implementación del diseño 91 EditText: dado que se requiere que el usuario introduzca la palabra a tratar se ha de utilizar un elemento para ello, siendo este el EditText. En este el usuario introduce la palabra a procesar por el servicio y en la pantalla secundaria se muestra el resultado obtenido del proceso. Button: este elemento representa botones que pueden ser seleccionados por el usuario para realizar determinada acción. En la aplicación se usan los botones para representar cada uno de los distintos servicios ofrecidos. Dentro de algunos de estos elementos aparecen diferentes opciones. A continuación se detallan algunas de las que han sido utilizadas en la aplicación: android:layout_width / android:layout_height : Esta función sirve para dar medida al ancho y al largo del layout. Puede contener tres valores diferentes: •match_parent: El elemento añadido debe ser tan grande como el padre que lo contiene. •wrap_content: El elemento añadido toma el tamaño del texto que contiene. Se le pueden dar los valores con el número seguido de px. android:text: Es el texto que aparece en el elemento. Se puede definir de dos maneras: •Escribiendo directamente el texto •Definiendo una constante de la forma @string/nombreElegido. Más adelante se explicará que se hace con la constante definida como string más el nombre elegido. android:layout_alignParentTop: Esta función hace encajar el eje superior de este elemento con el eje superior del elemento padre. Esto sucede cuando se iguala a “True”. android:inputType: Sirve para especificar el tipo de contenido que va a tener el elemento. android:layout_below: Sirve para dar un id a nuestro elemento, y así poder utilizarlo desde el fichero .java. android:layout_centerHorizontal: Esto sirve para centrar el elemento hijo con el padre en el plano horizontal. Si se iguala a “True”, se centrará con el padre en caso contrario no lo hará. 92 Capítulo 7. Desarrollo de una aplicación de ejemplo de los servicios android:layout_marginTop: Sirve para especificar un espacio de rigor en la parte superior y que así los elementos no resulten estar inmediatamente unidos unos a otros, así como que el elemento no empiece directamente en la parte superior de la pantalla o inmediatamente después del elemento padre. android:onClick: Sirve para hacer una llamada a una función cuando un botón ha sido cliqueado. El nombre de esta función corresponde con el de la función en el .java encargada de ejecutar la funcionalidad asignada a dicho botón Existen muchos más parámetros que se han ido viendo a lo largo de las distintas pruebas realizadas con Android Studio, pero dado que no se ponen en práctica en esta aplicación no quedarán mencionados aquí. Una vez descritos los elementos utilizados en la aplicación y sus utilidades, pasamos a describir la implementación de los mismos, contemplando las comunicaciones entre la interfaz gráfica y el código principal. Empezaremos centrándonos en la clase MainActivity que hace de puente entre la interfaz gráfica y el programa principal. Esta clase contiene un método para cada uno de los servicios implementados, todos ellos con una forma similar a la que se observa en la imagen 7.12. Figura 7.12: Método de la clase MainActivity. En ese método se observa la linea de código: EditText editText = (EditText) findViewById(R.id.TxtPalabra); con esta línea obtenemos el elemento del EditText para almacenarlo en el string llamado “palabra”. Esto se realiza mediante la función String palabra = editText.getText().toString();. Una vez obtenida la información llamamos al intent: intent.putExtra("NombreDelServicio", palabra); startActivity(intent));. Para poder recibir la palabra de un EditText se tiene que tener declarado en el activity_main con el nombre de TxtPalabra. 7.3. Implementación de la aplicación 93 Para implementar los diferentes servicios también nos ha hecho falta declararnos los diferentes botones en el mismo activiy_main.xml. Como se puede observar en la figura, en la declaración del botón se tiene una función que se llama onCLick que cuando el usuario hace clic en un elemento (en este caso un botón) y la cual se iguala al nombre de la función que queremos que llame al producirse este clic, que es la que se encuentra en Main_Activiy.java. Al igual que se tiene un método para cada servicio también se tiene declarado un botón. Realmente este es el comienzo del programa puesto que aquí es donde se declara la interfaz y donde se llama a los primeros métodos. Además en esta clase se tiene el método OnCreate que es llamado cuando se crea la actividad por primera vez. 7.3. Implementación de la aplicación En esta sección se pasa a hablar de la implementación llevada a cabo para el desarrollo de las funcionalidades de la aplicación en si misma. En el elemento del tipo android:text: que se veía en la sección anterior se pueden definir constantes de la forma: @string/NombreConstante, donde “NombreConstante” es el nombre que recibe la constante y con el que se quiere identificar a la misma en el programa. En este contexto cabe mencionar que Android tiene un archivo llamado string.xml donde se declaran todas estas constantes, por lo que si se utiliza esta en varios lugares del programa y en algún momento se decide cambiar el valor de esta constante únicamente habrá que ir a este archivo y cambiarlo ahí, sin tener que modificar cada una de las apariciones de la misma. A continuación se hablará del archivo AndroidManifest.xml. Este es un archivo que todo proyecto Android tiene que tener para su correcto funcionamiento, el cual tiene que tener necesariamente ese nombre, y que se encarga de presentar la información necesaria sobre la aplicación antes de que pueda correr el código del programa. Este archivo está compuesto por tres partes: En la primera parte del archivo aparecen la versión, el nombre del proyecto y el nombre del paquete que se está utilizando en la aplicación. En la figura 7.13 se puede ver como quedan representados. La segunda parte son los permisos que se necesitan en la aplicación. En este caso se tienen añadidos permisos a Internet y el acceso al estado de la red (Network state). En la figura 7.14 se puede ver como quedan representados. 94 Capítulo 7. Desarrollo de una aplicación de ejemplo de los servicios Figura 7.13: Imagen de la versión, nombre de proyecto y nombre del paquete en AndroidManifest.xml Figura 7.14: Imagen de los permisos necesarios para la aplicación. La tercera parte está compuesta por las actividades de la aplicación. Puesto que esta aplicación dispone de dos actividades tan solo habrá que declararse esas dos activities. Además en esta tercera parte se incluyen algunas propiedades como la definición del icono (el que aparecerá en el dispositivo móvil cuando se instale la aplicación), el tema, y si se permite Backup. En la imagen 7.15 se puede ver como todo esto queda definido. Figura 7.15: Imagen de las actividades que componen la aplicación. En este proyecto las Activity extienden a AppCompatActivity para poder usar el ActionBar en la aplicación. Este ActionBar se usa para mostrar el nombre de la aplicación en la parte superior del dispositivo en la 8.2. Trabajo futuro 101 En cuanto al proyecto en sí se pueden aplicar en el futuro diversas mejoras y cambios que completen sus funcionalidades. Así, como se decía anteriormente, se pueden añadir nuevos servicios al servidor haciéndolo más completo. Por ejemplo, en la versión actual del servidor se tiene únicamente traducción a inglés, pudiendo ser esto en el futuro ampliado a mayor variedad de idiomas así como a frases, y no únicamente a palabras. Igualmente se podrían solventar y mejorar alguno de los servicios creados en el proyecto, como podría ser el de pictogramas, haciendo que las consultas se realicen a mayor velocidad, ya que la demora de estas solicitudes supone un problema a la hora de utilizar este servicio. También se podría desarrollar el servicio de lematización, ya que al ser añadido al final este no está del todo completo y resultaría de gran utilidad en aplicaciones futuras como puede ser devolver el infinitivo de un tiempo verbal complejo para facilitar la comprensión de un texto. En este contexto la API irá evolucionando con el desarrollo de los servicios, para mantener estos siempre accesibles y bien detallados. De cara a la aplicación Android, siendo ahora un diseño de ejemplo, podría seguir desarrollándose, ampliando así mismo los nuevos servicios que pudieran ir surgiendo, hasta ser una aplicación totalmente disponible para los usuarios, pasando de ser un ejemplo de uso de los servicios a una herramienta para la accesibilidad. Además la aplicación podría ser llevada a dispositivos con sistema operativo IOS para poner esta herramienta a disposición del mayor número de gente posible. Capítulo 9 Project conclusions and future work To conclude this project and have a more general and functional view of it we will now explain the conclisions that we have made of its implementation as well as the possible future work aplications. 9.1. Conclusions Once the project was finished we analized its evolution and its general aspects. At the begining the idea was to create an API of the accesibility services of previous years, making the access to them easier. The task of generating an accesibility service API has been made, though the API is not about the existing projects but about the services that we have been creating. This is how our initial project, the API, has been covered, and also the development of the services covered in the API. Moreover, while the project was evolving we realized that creating an aplication that shows how to use the services would help other developers to have some ideas of possible uses, and that is why we decided to develop the aplication. Our services are REST as we thought that it is more appropriate for being focused in the HTTP protocol and in the XMLs data processing and for not needing any aditional layer. With this kind of services GETs methods can be implemented, being this the one that we are more interested in, because all our services are GET requests based. Also our intention were returning two exit formats, XML and JSON, and REST gives support to both of them. At the begining we developed the services being more focused in the final user, processing the results as a self-explained messages, easy to understand for the ones that uses them. It wasn’t until the really advanced development 103 104 Capítulo 9. Project conclusions and future work of the service and the begining of the aplication that we realized that the services weren’t meant to be used for a final user but for a developer who would interpret the result and will return the clear, self-explained result to the final user. Because of this, the services results are focused in making it easier its parse to a future developer rather than to be self-explained, which is the work of the API, explaining the functions of each one of the services and what to expect from it. Both the API development and the Android aplication made us finally understand properly the services’s function. Also, as we were understanding better the concepts we were realizing the importance of the API to make easier the access to the services and to explain how they work and what to expect from them. After the information search we saw that accesibility services were specially useful in movile devices and tablets, being this more accesible at every moment. That is why we choosed focus our example’s aplication in an Android device. With regard to the Android’s application implementation it’s been used the elements that are supplied by the platform and the Material Design for the interface and the design. The developed technology in this project has as a goal helping other developers to implement accessibility functions, by using the created services and without having to code everything from zero. To sum up we can conclude that the accesibility services, though they are more developed everyday, still have a long way to go, and that’s why this project could have great aplications in the future, which will be seen in the next section. 9.2. Future work With the creation of the services, we have observed that accessibility’s field is much bigger than we thought at the begining, and that there are still many accessibility services that can be developed. That is why this project is not only facing the future as a tool for the development of an aplication, but it also has huge posibilities in regard of the posibility of being extended and being each day more complet, making the limitations of the languaje not be a limitation anymore. In regards to the project, improvements and changes can be made in the future to make its functionalities more complete. Also new services can be 9.2. Future work 105 added to the server in the future, making it more complete. For example, in the current version of the server we only have a translation to english, in the future this could be extended to other languajes aswell. It could be also fixed and improved some service already created in this project, as the pictograph one, making the request faster, being the time that the current service takes to return the image too long. Iin this context the API will be evolving with the developing of the services, so they are always going to be accessible and well described. Regarding the Android application, it could keep developing, adding the new services that can be make until it becomes an actual aplication for the users, becoming a useful tool instead of an example. accesibilidad. The application could also be implemented in IOS operating systems, making it accessible for more people. Capítulo 10 Aportaciones individuales 10.1. Sheila Plaza Estévez El comienzo del trabajo se centró en la búsqueda de información así como recursos que pudieran ser útiles para su desarrollo. Se estuvo investigando qué tipo de servicios serían más útiles para desarrollar en un futuro en una aplicación. Nuestros tutores nos sirvieron de gran ayuda en este comienzo, puesto que nuestros conocimientos sobre este tema eran bastante escasos, pero con su ayuda y la información recaudada de Internet y algunos libros, poco a poco pudimos ir teniendo la información necesaria para desarrollar el proyecto. Igualmente se debatió qué tipo de aplicación podría desarrollarse para servicios de accesibilidad y cuál sería la mejor plataforma para ello. Este proyecto ha sido desarrollado por tres persona, y una de ellas fuera del país durante el primer cuatrimestre, lo cual no fue ningún impedimento puesto que nos organizamos de tal forma que esa persona pudiera estar al día de todo lo que se hablaba en nuestra reuniones, tanto con los directores del proyecto como entre las dos que estábamos en Madrid, y en como avanzábamos, para que ella pudiese avanzar en paralelo. Para ello lo mejor fue utilizar un plan desde el comienzo y seguirlo durante todo el año para no perder el control del tiempo ni de las tareas. En este contexto se decidieron usar herramientas bastante útiles para la planificación de tareas así como para estar comunicadas: Trello, Google Drive, Skype y Whatssap. Trello ha sido utilizado para la planificación y asignación de tareas a los diferentes miembros del grupo. En Google Drive se abrieron dos carpetas, una carpeta con los componentes del grupo y los directores para poder compartir la información que se fuese teniendo además de subir todas las actas de las reuniones que se iban haciendo para que así la persona del extranjero pudiera saber de que se hablaban en las reuniones que ella estaba ausente. La segunda carpeta del Drive la realizamos sólo para los componentes del grupo donde 107 108 Capítulo 10. Aportaciones individuales a la vez se encontraban las diferentes carpetas de nuestros trabajos y las distintas actualizaciones de los mismos. Durante el primer periodo del proyecto mis tareas fueron recoger toda la información posible para poder desarrollar el trabajo y a la vez entender que son los servicios web rest, y como se usan. Mientras se buscaba información, como la búsqueda tenía una gran cantidad de resultados, decidimos empezar a escribir la memoria tal y como nuestros tutores nos habían recomendado puesto que si la dejábamos para el final luego no nos acordaríamos de muchas cosas. La búsqueda de la información nos llevó unos meses, mas o menos de septiembre a primeros de noviembre. Después de haber entendido lo que era un servicio web rest y como funcionaba procedimos a la realización mas inicial del proyecto. Desde noviembre hasta febrero estuve creando la primera versión de nuestra web API y creando algunos servicios web REST de prueba para ir entendiéndolos mejor y asentar conocimientos. Uno de los servicios de prueba, con varias mejoras, serviría más adelante, convirtiéndose en el servicio de palabra sencilla. Este primer cuatrimestre mi disponibilidad era bastante baja por lo que los avances por mi parte se veían a paso más lento. En una de las reuniones antes de comenzar con todos los servicios, decidimos cuales deberíamos desarrollar primero y cuales en un futuro si acabáramos a tiempo los primarios. Nuestros tutores pusieron a nuestra disposición algunos de los trabajos de fin de carrera de otros años que estaban relacionados con los servicios que nosotras queríamos hacer. En segundo cuatrimestre mi disponibilidad era bastante más elevada por lo que me dedique a desarrollar algunos servicios web REST para poder terminar lo ante posible la web y empezar con una aplicación de ejemplo. Al principio habíamos acordado que los servicios rest serían traducidos a java de otros proyectos escritos en PHP, Java, etc. Cuando me dispuse a traducir el servicio de sinónimos de un trabajo anterior en PHP a Java, me fue muy complicado, ya que yo no entiendo de PHP, por lo que antes de estar gastando tiempo en traducir pensé que sería más sencillo si empezaba a escribirlo desde cero, y así fue. Durante los primeros meses del segundo cuatrimestre me dediqué a desarrollar algunos servicios analizando el código html de una página web. Esto parecía complicado pero la librería JSOUP hizo que el análisis fuera más sencillo. Antes de comenzar con los servicios, estuve mirando que página se ajustaba más a las necesidades que estábamos buscando. Algunas de las candidatas eran: 10.1. Sheila Plaza Estévez 109 Sinonimos.com1 Sinonimos.org2 ElPaís3 La de ElPaís fue una de las páginas con las que empecé a trabajar puesto que en trabajos anteriores habían trabajado con ella. Pero buscando un poco más, me di cuenta que la página WordReferences4daban respuesta a casi todos los servicios que nosotras queriamos implentar, por ello decidí que esta seria la mejor, ya que una vez aprendiese a parsearla para un servicio podría parsearla para los demás. Para dar uso a nuestros servicios, pensamos que podríamos desarrollar una aplicación de ejemplo, algunas de las alternativas eran: Un ejemplo dentro de la página web. Una aplicación Java para ordenador. Una aplicación Android para móvil o tablet. Decidimos que la mejor opción sería Android puesto que hoy en día el móvil o la tablet es usado por la mayoría de las personas y el sistema operativo Android, según estudios realizados por un periódico, es usado en un 88% de los dispositivos. Otra de las razones por la que elegimos Android es porque mientras buscábamos información sobre cómo realizar servicios web rest, encontrábamos bastante sobre Android, y decidimos aprovechar este avance. Una vez decidido la plataforma que usamos para nuestra aplicación de ejemplo, comencé a investigar qué programa podría utilizar. Como ya contamos en capítulos anteriores, en un principio comencé con Eclipse, sin darme cuenta de que estaba obsoleto para android. Decidí utilizar Eclipse porque era un entorno que ya conocía. Viendo que con este programa no podía desarrollar, comencé con Android Studio. Una vez habituada a este entorno de desarrollo, comence con la implementación de toda nuestra aplicación Android, utilice un emulador de una Tablet Nexus 7. Para terminar con este apartado de mis aportaciones al trabajo, sólo añadir que en la memoria he aportado todo el desarrollo de Android, la parte de servicios que desarrolle en su comienzo, parte del resumen y conclusiones y posibles adaptaciones al futuro. 1http://www.sinonimos.com/ 2http://www.sinonimos.org/ 3http://servicios.elpais.com/diccionarios/sinonimos-antonimos/ 4http://www.wordreference.com/ 110 Capítulo 10. Aportaciones individuales 10.2. Nerea Ramírez Lamela Inicialmente, acordamos que nuestro proyecto se iba a desarrollar en JAVA, utilizando servicios rest. Decidimos que íbamos a realizar actas con los puntos tratados en cada reunión, y posteriormente subirlas a una carpeta compartida en el drive. El propósito de estas actas, era mantener informada a una de las integrantes del grupo, debido a que se iba a encontrar fuera durante el primer cuatrimestre y no iba a poder asistir a dichas reuniones. Esto no ha supuesto ningún problema ya que gracias a aplicaciones como Skype, drive como repositorio y whatsapp hemos estado constantemente en contacto. Para mejorar nuestra coordinación y organización creamos dos archivos donde en uno de ellos se escribían las tareas a realizar y en el otro las dudas que nos surgían y no conseguíamos resolver para preguntárselo a nuestros tutores en la próxima reunión. La primera toma de contacto con el proyecto, fue familiarizarse con la estructura y el funcionamiento de una API y con los servicios rest. Para ello, realizamos búsquedas en internet de APIS ya creadas, donde pudimos observar diferentes diseños y recopilamos ideas para la nuestra. En los cuatro primeros meses, mis tareas se basaron en la búsqueda de información, la creación del primer prototipo de la página web de la API, entender el funcionamiento del servidor proporcionado por nuestros tutores y el funcionamiento de los servicios rest. Para ello, me instale todas las herramientas necesarias para la generación de servicios rest, e investigue sobre todo lo relacionado con la tecnología que íbamos a tener que utilizar, ya que nuestros conocimientos en este ámbito eran bastante escasos. Conseguimos recopilar mucha información, por lo que siguiendo los consejos que nos habían dado y para que no se nos olvidarán detalles del progreso del proyecto, empezamos a escribir la memoria dejando plasmado toda la información recolectada. Gracias a la ayuda de nuestros tutores, consultas en Internet y libros, conseguimos obtener nociones básicas para poder empezar a realizar nuestros primeros ejemplos de servicios. Por ejemplo, el primer servicio que desarrolle, fue una agenda simple, realizando un servicio que hiciera una petición HTTP con el método GET. Una vez que estuvimos familiarizadas con las tecnologías, creamos el primer prototipo del servicio “palabra sencilla” del proyecto, generado con eclipse y utilizando como servidor local, “Tomcat”. A finales del cuatrimestre, nuestros tutores nos facilitaron un servidor de la universidad “http://sesat.fdi.ucm.es/”,