Repositorio Institucional de Documentos

Proyecto Fin de Carrera AraW 2ord : una herramienta basada en tecnolog´ıas Web para la escritura simult´anea de texto y pictogramas Aar´on Torrijos Bernal Director: Francisco Javier Fabra Caro Ingenier´ıa Inform´atica Departamento de Inform´atica e Ingenier´ıa de Sistemas Escuela de Ingenier´ıa y Arquitectura Universidad de Zaragoza Noviembre 2013 AraW 2ord: una herramienta basada en tecnolog´ıas web para la escritura simult´anea de texto y pictogramas RESUMEN Los sistemas alternativos de comunicaci´on surgen como complemento al lenguaje oral para ayudar a personas que padecen trastornos severos en el habla, bien de forma directa o bien de forma indirecta (lesiones o problemas neuronales, cognitivos, autismo, etc.). Estos sistemas facilitan la expresi´on sin utilizar la palabra, mediante la utilizaci´on de otros recursos. En este contexto surge la herramienta AraWord, que permite la escritura simult´anea de texto y pictogramas. Los pictogramas representan, de forma clara y sencilla, los conceptos m´as habituales para la comunicaci´on cotidiana. AraWord es una herramienta open-source desarrollada por profesores y alumnos del Departamento de Inform´atica de la Universidad de Zaragoza, y que en la actualidad cuenta con una amplia comunidad de usuarios a nivel internacional. AraWord se ofrece como un software de escritorio y en la actualidad no dispone de una interfaz orientada a servicios que pueda facilitar la integraci´on de sus capacidades en entornos Web o dispositivos m´oviles. En este proyecto se ha realizado el desarrollo de una versi´on Web de AraWord que expone todas las funcionalidades de la herramienta mediante servicios Web. La finalidad ha sido doble: por una parte, los servicios publicados pueden reutilizarse para desarrollar aplicaciones de prop´osito espec´ıfico tanto para ordenadores de escritorio como para dispositivos m´oviles; por otra parte, se ha desarrollado una aplicaci´on Web como caso de aplicaci´on de estos servicios, llamada AraW 2ord, accesible mediante cualquier dispositivo a trav´es de un navegador. III IV Glosario ARASAAC Portal Aragon´es de la Comunicaci´on Aumentativa y Alternativa AJAX Asynchronous JavaScript and XML BLOB Binary Large Objects CA Comunicaci´on Aumentativa CAA Comunicaci´on Aumentativa y Alternativa CATEDU Centro Aragon´es de Tecnolog´ıas para la Educaci´on CORS Cross-origin resource sharing CSS Cascading Style Sheets HTML HyperText Markup Language HTTP Hypertext Transfer Protocol LSE Lengua de Signos Espa˜nola MEP Message Exchange Patterns REST Representational State Transfer SAAC Sistemas Aumentativos y Alternativos de Comunicaci´on SOA Service-Oriented Architecture SOAP Simple Object Access Protocol SPC Sistema Pictogr´afico de Comunicaci´on TIC Tecnolog´ıas de la Informaci´on y Comunicaci´on WSDL Web Services Description Language XML eXtensible Markup Language V VI ´ Indice 1. Introducci´on 1 1.1. Motivaci´on.................................... 1 1.2. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Contenidos y alcance del documento . . . . . . . . . . . . . . . . . . . . . 3 2. Conceptos previos 5 2.1. La comunicaci´on Aumentativa y Alternativa . . . . . . . . . . . . . . . . . 5 2.2. Sistemas Aumentativos y Alternativos de Comunicaci´on(SAAC)............................. 6 2.3. ARASAAC ................................... 6 2.4. Concepto de pictograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. AraWord..................................... 9 2.5.1. Concepto de pictograma en AraWord . . . . . . . . . . . . . . . . . 9 2.5.2. La comunicaci´on en AraWord . . . . . . . . . . . . . . . . . . . . . 10 2.5.3. Puntos fuertes y d´ebiles de AraWord . . . . . . . . . . . . . . . . . 11 3. Proceso de an´alisis y desarrollo 13 3.1. Dedicaci´on y distribuci´on temporal de tareas . . . . . . . . . . . . . . . . . 14 3.2. An´alisis del problema: Dise˜no de la soluci´on . . . . . . . . . . . . . . . . . 14 3.2.1. An´alisis de Requisitos y Casos de Uso . . . . . . . . . . . . . . . . . 14 3.2.2. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.3. Interfaz de servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.4. BasedeDatos.............................. 18 3.2.5. Modelo de proceso de desarrollo . . . . . . . . . . . . . . . . . . . . 19 3.3. Implementaci´on: Desarrollo de la soluci´on . . . . . . . . . . . . . . . . . . . 19 3.3.1. Arquitecura del sistema y Funcionamiento . . . . . . . . . . . . . . 19 3.3.2. Implementaci´on............................. 20 3.3.3. Modelodecapas ............................ 26 3.3.4. Visi´on global de de interacci´on con el sistema . . . . . . . . . . . . 28 4. Resultados obtenidos 29 4.1. InterfazdeServicios .............................. 29 4.2. Aplicaci´on AraW 2ord ............................. 31 VII ´ INDICE 5. Conclusiones y trabajo futuro 33 5.1. Conclusiones................................... 33 5.2. Limitaciones................................... 34 5.3. Trabajofuturo ................................. 35 5.4. Valoraci´onpersonal............................... 36 A. Evoluci´on orientada a servicios 41 A.1. Diferencias entre aplicaciones de Escritorio y aplicaciones Web . . . . . . . 41 A.2. Orientaci´on a Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 A.3. Motor de los Servicios Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 B. Distribuci´on temporal del proceso 47 B.1.ModeloIncremental............................... 47 B.2. Distribuci´on Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 B.2.1.Trabajoprevio ............................. 48 B.2.2. An´alisis del problema y dise˜no de la soluci´on . . . . . . . . . . . . . 48 B.2.3. Desarrollo de la soluci´on . . . . . . . . . . . . . . . . . . . . . . . . 48 B.2.4. Verificaci´on de la soluci´on . . . . . . . . . . . . . . . . . . . . . . . 49 B.2.5. Elaboraci´on de documentaci´on . . . . . . . . . . . . . . . . . . . . . 49 C. Descripci´on detallada del proceso de desarrollo 51 C.1. An´alisis de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 C.1.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . 51 C.1.2. Requisitos No Funcionales . . . . . . . . . . . . . . . . . . . . . . . 52 C.2.Casosdeuso................................... 52 C.3. Dise˜no de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 C.3.1. Dise˜no de la Interfaz de Servicios . . . . . . . . . . . . . . . . . . . 53 C.3.2. Dise˜no de la base de datos . . . . . . . . . . . . . . . . . . . . . . . 54 C.3.3. Dise˜no de la Aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . . . 55 C.3.4.ServidorWeb .............................. 56 C.4. Herramientas Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 C.5.Pruebas ..................................... 58 D. Servicios Web Desarrollados 61 E. Manual de usuario 77 E.1.Manualdeusuario ............................... 77 E.1.1. P´agina principal de la aplicaci´on . . . . . . . . . . . . . . . . . . . 77 E.1.2. Registro o identificaci´on de usuarios . . . . . . . . . . . . . . . . . . 78 E.1.3. Registro de nuevo usuario . . . . . . . . . . . . . . . . . . . . . . . 79 E.1.4. Opciones para usuarios registrados . . . . . . . . . . . . . . . . . . 79 E.1.5. Edici´ondetexto ............................ 81 E.2.StoryBoard ................................... 83 VIII ´ Indice de figuras 2.1. Pictograma que representa el concepto de ’perro’ . . . . . . . . . . . . . . 7 2.2. Pictogramas asociados a las palabras simples . . . . . . . . . . . . . . . . . 8 2.3. Pictograma asociado a la palabra compuesta . . . . . . . . . . . . . . . . . 8 2.4. Pictograma que representa el concepto de ’perro’ en AraWord . . . . . . . 9 2.5. Ejemplo de texto escrito en AraWord . . . . . . . . . . . . . . . . . . . . . 10 3.1. DiagramadeGantt............................... 14 3.2. Diagrama general de Casos de Uso de AraW 2ord .............. 16 3.3. Arquitectura AraW 2ord ............................ 17 3.4. ServicioWeb .................................. 17 3.5. Arquitectura detallada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6. AraW 2ord usuarioinvitado .......................... 23 3.7. AraW 2ord usuarioregistrado ......................... 24 3.8. Modelodetrescapas.............................. 26 3.9. Proceso de interacci´on en AraW 2ord ..................... 28 4.1. InterfazdeServicios .............................. 29 4.2. WSDL del paquete UserTasks . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3. AraW 2ord .................................... 31 A.1.CapasdelmodeloSOA............................. 43 A.2.ApacheAxis2 .................................. 45 B.1.ModeloIncremental............................... 47 B.2. Dedicaci´on de tareas en porcentaje . . . . . . . . . . . . . . . . . . . . . . 50 C.1. Diagrama de Casos de Uso de AraW 2ord ................... 52 C.2.Diagramadepaquetes ............................. 53 C.3. Base de Datos de AraW ord2.......................... 55 C.4. Diagrama de paquetes de la Aplicaci´on AraW ord2.............. 56 C.5.PruebasconSoapUI .............................. 59 C.6. Pruebas de integraci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 E.1. P´agina de inicio de AraW 2ord ......................... 77 E.2.Ventanadelogin ................................ 78 E.3. Ventana de registro de usuarios . . . . . . . . . . . . . . . . . . . . . . . . 79 E.4. Pantalla de inicio para usuario registrados . . . . . . . . . . . . . . . . . . 79 E.5. Cambio de preferencias de un usuario . . . . . . . . . . . . . . . . . . . . . 80 IX 2. Conceptos previos 2.2. Sistemas Aumentativos y Alternativos de Comunicaci´on (SAAC) Para dar soporte a la CAA surgen los Sistemas de Comunicaci´on Aumentativa y Alternativa o SAAC. ´ Estos, son formas de expresi´on distintas al lenguaje hablado, que tienen como objetivo aumentar (aumentativos) y/o compensar (alternativos) las dificultades de comunicaci´on y lenguaje de personas con discapacidad. Los SAAC se clasifican en: No asistidos: Tambi´en conocidos como SAAC sin ayuda, son aquellos en los que no es necesaria la utilizaci´on de ning´un aparato o material. Los c´odigos utilizados no necesitan de ning´un elemento externo al propio emisor. El ejemplo m´as caracter´ıstico ser´ıa el lenguaje de signos. Asistidos: Los SAAC asistidos o con ayuda se caracterizan porque los c´odigos que utilizan requieren un dispositivo externo. Ejemplos de estos sistemas ser´ıan los comunicadores electr´onicos, los tableros de comunicaci´on, etc. En este proyecto se aborda el desarrollo de un SAAC asistido, por ello ser´an ´estos sistemas en los que centraremos nuestra atenci´on. Existen m´ultiples productos de apoyo a la comunicaci´on adaptados seg´un las discapacidades presentes en las personas. Algunos cuentan con comunicadores de habla artificiales, otros incluyen salida de voz y la mayor´ıa utilizan materiales visuales. Los recursos visuales pueden ser de diversos tipos, desde letras y palabras hasta fotograf´ıas, dibujos, pictogramas, etc. Los sistemas pictogr´aficos constituyen el recurso m´as extendido en personas que todav´ıa no est´an alfabetizadas debido a la temprana edad o a alguna discapacidad. ´ Estos permiten un nivel de comunicaci´on muy b´asico que se adapta bastante bien a personas con niveles cognitivos bajos. Los sistemas pictogr´aficos m´as utilizados en la actualidad son el SPC1y el sistema pictogr´afico de ARASAAC2 2.3. ARASAAC ARASAAC[5] es el Portal Aragon´es de la Comunicaci´on Aumentativa y Alternativa. Este proyecto forma parte del Plan de Actuaciones del Centro Aragon´es de Tecnolog´ıas para la Educaci´on (CATEDU). En ARASAAC se ofrecen recursos gr´aficos y materiales para ayudar a personas con trastornos severos en el habla. Todos los materiales se ofrecen bajo una licencia Creative Commons. 1Sistema Pictogr´afico de Comunicaci´on creado por Roxana Mayer en 1981 bajo licencia de tipo comercial 2Sistema pictogr´afico creado por el Centro Aragon´es de Tecnolog´ıas para la Educaci´on, profesionales del CPEE Alborada y Sergio Palao en 2008. Est´an accesibles bajo licencia Creative Commons en http: //www.catedu.es/arasaac/descargas.php 6 2. Conceptos previos Actualmente disponen de cinco cat´alogos con pictogramas en color y blanco y nego, fotograf´ıas, v´ıdeos y fotograf´ıas en color en LSE3. Adem´as cuenta con m´as de 13.000 pictogramas y ´estos siguen aumentando. ARASAAC cuenta con una amplia comunidad y est´a presente en las principales redes sociales. En este proyecto se utilizan los recursos pictogr´aficos elaborados por ARASAAC y el CPEE Alborada. Dado que este sistema est´a muy difundido, y dado el car´acter altruista del mismo, en este proyecto se decide usar dichos pictogramas, am´en de que ´estos mismos han sido los utilizados por los proyectos precursores. 2.4. Concepto de pictograma Un pictograma es un signo que representa esquem´aticamente un s´ımbolo, un objeto real o una figura. Se trata de un diagrama que mediante im´agenes o s´ımbolos permite mostrar la realidad de forma que sea f´acilmente comprensible y siguiendo un est´andar. Los pictogramas pueden ser utilizados como sistemas aumentativos o alternativos para representar una realidad concreta (ej: animal,persona), una realidad abstracta (ej: un sentimiento), una acci´on (ej: mirar) e incluso un elemento gramatical (ej: adjetivos, conjunciones). Figura 2.1: Pictograma que representa el concepto de ’perro’ Como se puede apreciar en la figura anterior, la realidad ’perro’ es f´acilmente comprensible mediante la imagen que representa dicha realidad. No obstante, existen palabras o grupos de palabras que puede representar realidades diferentes dependiendo de como est´en agrupadas. ´ Este es el caso de las palabras compuestas4. Ejemplos de palabras compuestas son: centro comercial, cabina de tel´efono, cepillo de dientes, etc. A continuaci´on se muestra un ejemplo de este tipo de palabras: 3Lengua de Signos Espa˜nola 4Se dice que una palabra es compuesta si dos o m´as palabras se asocian con un ´unico pictograma 7 2. Conceptos previos Pictogramas asociados a las palabras: cepillo, de, dientes: Figura 2.2: Pictogramas asociados a las palabras simples Pictograma asociado a la realidad: cepillo de dientes: Figura 2.3: Pictograma asociado a la palabra compuesta Cuando se produzca una combinaci´on de palabras compuestas como la descrita en la Figura 2.2 el resultado deber´ıa ser un ´unico pictograma (Figura 2.3) Con el pictograma se identifica la realidad representada f´acilmente pero en el proceso de aprendizaje es necesaria m´as informaci´on. Por ejemplo, es importante saber que tipo de palabra estamos visualizando (verbo, nombre com´un,etc.) y adem´as puede ser interesante el poder ver la palabra que da nombre a la realidad representada. Por estas razones, en AraWord[1] se extendi´o el concepto de pictograma. 8 2. Conceptos previos 2.5. AraWord AraWord[1] es un SAAC asistido que utiliza recursos pictogr´aficos para llevar a cabo la comunicaci´on. Consiste en un procesador de textos que permite la escritura simult´anea de texto y pictogramas, facilitando la elaboraci´on de materiales y adaptaci´on de textos para las personas que presentan dificultades en el ´ambito de la comunicaci´on funcional. AraWord se ejecuta como una aplicaci´on de escritorio y para su funcionamiento incorpora una Base de Datos con Pictogramas elaborados por ARASAAC. Actualmente esta Base de Datos cuenta con m´as de 13000 pictogramas en siete idiomas diferentes. Para la edici´on de texto, AraWord cuenta con m´ultiples opciones; se puede editar texto de la forma habitual, mediante la introducci´on de caracteres o tambi´en se da la posibilidad de copiar un texto externo al editor de textos y ver su representaci´on pictogr´afica. Permite la identificaci´on de palabras compuestas, as´ı como la composici´on o descomposici´on manual para formar uno o varios pictogramas respectivamente. 2.5.1. Concepto de pictograma en AraWord En AraWord[1] el concepto de pictograma evolucion´o para adecuarse a los requisitos pedidos por el CPEE Alborada. Un pictograma no s´olo consta del signo o dibujo sino que tambi´en se almacenaba informaci´on del tipo de palabra as´ı como la propia palabra. Figura 2.4: Pictograma que representa el concepto de ’perro’ en AraWord El concepto ’perro’ es m´as completo, adem´as de la representaci´on gr´afica se muestra 9 2. Conceptos previos la palabra que da nombre a la realidad representada y se da informaci´on acerca del tipo de palabra. El tipo de palabra queda definido mediante un c´odigo de color. (ej: borde amarillo representa un nombre com´un). En AraWord un t´ermino puede tener asociados varios pictogramas, lo que significa, que una misma realidad puede tener varias im´agenes disponibles, el usuario puede elegir la que m´as se adecue al contexto en el que se encuentre (ej. diferentes im´agenes para la realidad ’perro’). As´ı mismo, un pictograma puede tener asociado varios t´erminos, esto es, diferentes realidades pueden representarse con la misma imagen (ej. varias razas de perros representados con la misma imagen). 2.5.2. La comunicaci´on en AraWord AraWord est´a disponible para varios Sistemas Operativos (Windows, Linux, MacOS). Para poder utilizarlo, hay que descargarse el software correspondiente de acuerdo con nuestro sistema operativo. Es un software que funciona para entornos de escritorio y tras unos sencillos pasos podemos instalar la aplicaci´on. Al instalar la aplicaci´on, ´esta instala la base de datos con los pictogramas en nuestro equipo. La comunicaci´on con AraWord est´a basada en una hoja en blanco en la cual el logopeda o el alumno escriben texto y como respuesta a esa escritura se obtiene el pictograma asociado. Figura 2.5: Ejemplo de texto escrito en AraWord 10 2. Conceptos previos 2.5.3. Puntos fuertes y d´ebiles de AraWord AraWord ha tenido un alto nivel de aceptaci´on convirti´endose en un proyecto de ´ambito internacional. Lo avalan las m´as de 900 descargas semanales que se realizan a trav´es Sourceforge de Arasuite, donde AraWord est´a integrado. Por otra parte, el hecho de que AraWord solamente est´e disponible como aplicaci´on de escritorio limita su evoluci´on y expansi´on. En la actualidad, gran parte de las aplicaciones est´an siendo orientadas hacia la Web. Tambi´en cada vez son m´as los dispositivos nuevos que surgen con conexi´on a Internet, desde tablets o smartphones hasta peque˜nos miniordenadores como por ejemplo la Raspberry5. A pesar de la variedad de los sistemas operativos de estos dispositivos, en todos ellos se ofrece conectividad a Internet. Con el desarrollo de una interfaz de los servicios ofrecidos en AraWord se va a poder extender AraWord a la Web y va a poder ser ofrecido en muchos m´as dispositivos. 5Es una computadora completa en un s´olo circuito. Tambi´en conocidos como ordenadores de placa reducida(Single Board Computer o SBC) 11 12 Cap´ıtulo 3 Proceso de an´alisis y desarrollo En este cap´ıtulo se presenta el an´alisis del problema a resolver. El problema reside en la realizaci´on de AraWord para poder ser ejecutado en un entorno Web. Se realizar´a un an´alisis de los requisitos, un an´alisis tecnol´ogico de la soluci´on y posteriormente se realizar´a la implementaci´on del mismo. Para ello, se explicar´an cada una de las fases en las que se ha dividido el proyecto y se abordar´an las posibles dudas y problemas que surgieron, as´ı como las soluciones y decisiones tomadas y el porqu´e de las mismas. 13 3. Proceso de an´alisis y desarrollo 3.1. Dedicaci´on y distribuci´on temporal de tareas Este PFC comienza a finales de enero de 2013 y finaliza a principios de noviembre de 2013 Durante este periodo se pueden distinguir varias etapas. La Figura 3.1 muestra la distribuci´on de tiempos mediante un diagrama de Gantt. Figura 3.1: Diagrama de Gantt Se pueden distinguir varias fases durante la realizaci´on del proyecto, las cuales son: Trabajo previo al desarrollo de la aplicaci´on: En esta fase se hace una primera toma de contacto con lo que es la CAA y los SAACs. Se realiza la lectura de varios documentos relacionados con este tema. Se realiza un an´alisis del proyecto previo “AraWord[1]: Un procesador de textos para comunicaci´on aumentativa y adaptativa” realizado por Joaqu´ın P´erez. An´alisis del problema y dise˜no de la soluci´on: En esta segunda fase se realiza el an´alisis del problema y se realiza el dise˜no de la soluci´on. Desarrollo de la soluci´on: Implementaci´on de la soluci´on dise˜nada. Verificaci´on de la soluci´on: Etapa en la que se realiza la verificaci´on de la soluci´on desarrollada. 3.2. An´alisis del problema: Dise˜no de la soluci´on 3.2.1. An´alisis de Requisitos y Casos de Uso La primera etapa del dise˜no de la soluci´on pasa por la toma de requisitos. Para ello, se elaboran reuniones con el director de proyecto y con Joaqu´ın Ezpeleta (director de proyectos previos a este y poseedor de gran conocimiento en el ´ambito de la comunicaci´on 14 3. Proceso de an´alisis y desarrollo aumentativa y alternativa). En dichas reuniones se establecen los objetivos y funcionalidades que debe cumplir la aplicaci´on. A continuaci´on de muestran de forma resumida los requisitos funcionales y no funcionales cuya descripci´on puede encontrase de forma m´as detallada en el anexo C. Requisitos Funcionales RF-1 La aplicaci´on podr´a ser utilizada en dos modos distintos: usuario invitado y usuario registrado RF-2 La aplicaci´on permitir´a la edici´on sencilla de texto con pictogramas asociados. RF-3 La aplicaci´on permitir´a el registro de usuarios. RF-4 Para un usuario registrado se podr´a configurar el n´umero de im´agenes por l´ınea, tama˜no de letra, posici´on del texto, color del texto, el tama˜no de la imagen, etc. RF-5 Se permitir´a la carga de im´agenes propias para un usuario registrado RF-6 Se permitir´a editar/eliminar los pictogramas propios de usuarios registrados RF-7 Se permitir´a cambiar la imagen de un pictograma RF-8 Existir´an dos modos de edici´on de texto: inserci´on y edici´on. Requisitos No Funcionales RNF-1 La aplicaci´on deber´a funcionar correctamente en navegadores actuales que soporten HTML5, JavaScript y CSS3 RNF-2 La ejecuci´on de la aplicaci´on deber´a ser independiente de la plataforma RNF-3 El dise˜no de la aplicaci´on est´a pensado para una resoluci´on m´axima de 960 p´ıxeles de anchura. RNF-4 Con resoluciones inferiores a 960 p´ıxeles de anchura la interfaz se ajustar´a al tama˜no de la pantalla del dispositivo RNF-5 La sesi´on de un usuario permanecer´a vigente hasta que se cierre el navegador o se cierre la sesi´on. RNF-6 Solamente ser´an v´alidos los caracteres pertenecientes al conjunto {a−z|A− Z|0−9}para la introducci´on de texto. RNF-7 La aplicaci´on estar´a liberada bajo una licencia GNU General Public License 15 3. Proceso de an´alisis y desarrollo Servicio Web de edici´on de preferencias: Permite cambiar las preferencias descritas en el an´alisis para el usuario que se ha identificado. Servicio Web de gesti´on de im´agenes propias: La gesti´on de im´agenes propias implica tres operaciones: Listado de im´agenes: Muestra las im´agenes propias del usuario identificado en la aplicaci´on Edici´on de im´agenes: Se permite cambiar el nombre. Eliminar im´agenes: Se permite borrar una imagen propia. Servicio Web de alta de usuario: Permite dar de alta a un usuario en la aplicaci´on a partir de su nombre, apellidos, email y contrase˜na. Para identificarse en la aplicaci´on posteriormente su usuario ser´a su email y su contrase˜na la misma que uso para el registro. Servicio Web de verificaci´on de usuario existente: Comprueba que el nombre de usuario y la contrase˜na introducida existen en la aplicaci´on y carga su perfil. Base de Datos Como se habl´o en la secci´on de dise˜no, para la Base de Datos se usa MySQL en su versi´on 5.5.32, que se trata de un gestor de bases de datos relacional, multihilo y multiusuario. Se crea la base de datos en el servidor Alkaid donde tambi´en residir´a AraW 2ord. Se mantienen las tablas presentes en AraWord y adem´as se a˜naden otras nuevas que son necesarias. En el anexo C se describe de forma m´as detalla la base de datos y las tablas que la componen. Interfaz Para la realizaci´on de la interfaz se ha utilizado HTML11 y CSS12. Puesto que la aplicaci´on debe funcionar correctamente en cualquier navegador y en cualquier resoluci´on de pantalla se ha optado por usar un grid responsive. Un grid es b´asicamente una hoja de estilos css. Hay infinidad de sistemas grid disponibles y la mayor´ıa de ellos son gratuitos. Por su popularidad y versatilidad nos 11HyperText Markup Language 12Cascading Style Sheets 22 3. Proceso de an´alisis y desarrollo hemos decantado por usar bootstrap13. Bootstrap es el framework front-end desarrollado y liberado por Twitter. Implementa los nuevos est´andares (HTML5 + CSS3) y funciona en cualquier navegador (IE 7/8/9, Firefox, Chrome, Safari, ...). Este sistema est´a compuesto por 12 columnas con un ancho total de 960 pixeles. Adem´as si no se es muy h´abil con la maquetaci´on css es una buena opci´on para realizar un dise˜no bastante aceptable. Tambi´en es responsive, lo que significa que se adapta a cualquier resoluci´on de pantalla. El dise˜no de la interfaz es sencillo, intuitivo y minimalista. Dado que ´este es un software que usar´a gente con discapacidades ps´ıquicas y f´ısicas se ha realizado el dise˜no teniendo esto en mente. La aplicaci´on consta de un men´u con las opciones presentadas con pictogramas como botones. Se muestra el logo de AraWord cuya funcionalidad es presentar la p´agina principal y un bot´on para entrar en la aplicaci´on. La figura 3.6 refleja esta descripci´on. Figura 3.6: AraW 2ord usuario invitado Una vez registrado aparecen tres opciones m´as, una para configurar las preferencias de usuario, otra para la gesti´on de pictogramas y una ´ultima para cerrar la sesi´on. 13http://getbootstrap.com/2.3.2/ 23 3. Proceso de an´alisis y desarrollo Figura 3.7: AraW 2ord usuario registrado En ambos modos (invitado o registrado) se presenta el cuadro de texto de edici´on d´onde el usuario debe procesar el texto. La interfaz HTML se gestiona a trav´es de c´odigo JavaScript14 y jQuery15. Cada car´acter que un usuario introduce en el cuadro de texto de la p´agina principal se captura mediante un evento de teclado (keyup) y se procesa. La introducci´on de ciertos caracteres especiales produce una llamada AJAX16 a la Interfaz de Servicios. Las peticiones Ajax son ejecutadas por c´odigo JavaScript, el cual env´ıa una petici´on a una URL. La URL a la cual se env´ıa la petici´on es aquella en la que est´an publicados los Servicios. Tambi´en es necesario comunicar la operaci´on que queremos ejecutar y proporcionarle los par´ametros necesarios para su ejecuci´on en el servidor. Para saber a qu´e m´etodo queremos hacer referencia y qu´e par´ametros hemos de proporcionar se disponen de los ficheros de descripci´on de los Servicios Web o WSDL. En ellos, se describe la interfaz p´ublica de los Servicios Web que contiene informaci´on del protocolo de comunicaci´on y de los formatos de los mensajes a enviar. El renderizado de los pictogramas en HTML se realiza una vez obtenida la respuesta del servidor. Para ello, se crea una tabla din´amica en HTML en la que se a˜naden los pictogramas (creados de forma din´amica con jQuery). Funcionalidad de la Interfaz Para dar funcionalidad al procesador de textos se debe poder ir tecleando palabras y que los pictogramas aparezcan de forma din´amica. Para conseguir esto se dispone de algu14Lenguaje de programaci´on interpretado, dialecto del est´andar ECMAScript. Se define como orientado a objetos,3 basado en prototipos, imperativo, d´ebilmente tipado y din´amico. 15 Biblioteca de JavaScript, creada inicialmente por John Resig, que permite simplificar la manera de interactuar con los documentos HTML 16Asynchronous JavaScript and XML 24 3. Proceso de an´alisis y desarrollo nas teclas especiales como el espacio (separador de palabras) y el backspace (para borrar caracteres). Las dem´as letras quedan disponibles para la introducci´on de texto, aunque no se permite poder usar todos los caracteres sino que se limita al subconjunto {a-z|A-Z|0-9}. La unidad m´ınima de b´usqueda se establece en una palabra. Se barajan dos opciones, hacer el tratamiento a nivel de car´acter o de palabra y tras estudiar ambas opciones y medir sus rendimientos se decide que la unidad m´ınima de b´usqueda sea una palabra. El tratamiento a nivel de car´acter resulta muy costoso debido a la elevada cantidad de peticiones a los servicios Web. Para el borrado se establece un time-out que dura hasta que se pulsa un car´acter de edici´on {a-z|A-Z|0-9}o hasta que pasa un determinado tiempo. Con este time-out conseguimos realizar menos peticiones a los servicios Web lo que se traduce en un mejor tiempo de respuesta. Palabras compuestas Una palabra se dice que es compuesta si un ´unico pictograma se corresponde con m´as de una palabra simple (ej: cepillo de dientes, centro comercial, patatas fritas, etc.). Para encontrar este tipo de palabras es necesario comprobar si con las n-1 o n+1 palabras es posible formar una compuesta. Si estamos en modo edici´on normal, es decir con el cursor al final del texto s´olo ser´a necesario la comprobaci´on con las n-1 palabras anteriores. En el caso que estemos editando una palabra en mitad del texto, ya sea a˜nadiendo nuevos caracteres o elimin´andolos ser´a necesario comprobar las n-1 y n+1 palabras. Esto supone realizar m´as peticiones al servicio web de b´usqueda con la implicaci´on de un mayor retardo. Despu´es de varias pruebas, se asumi´o que el retardo obtenido en palabras compuestas con n=3 era asumible. Arquitectura de despliegue: Servidor Web Para poder tener la aplicaci´on disponible y accesible al resto de mundo, es necesario desplegarla en un servidor Web. Se desarroll´o un entorno en un servidor en el que se instal´o un Tomcat17 para desplegar los servicios Web y un MySQL para la gesti´on de la base de datos. Tomcat es un servidor Web con soporte de servlets18 y JSPs19 (m´etodos de creaci´on de p´aginas Web din´amicas usando el lenguaje Java). A pesar de que Tomcat no es un servidor de aplicaciones como JBoss20, es suficiente para nuestro prop´osito y m´as sencillo de configurar. 17http://tomcat.apache.org/ 18Los servlets son objetos que corren dentro y fuera del contexto de un contenedor de servlets 19Java Server Pages 20http://www.jboss.org/ 25 3. Proceso de an´alisis y desarrollo La jerarqu´ıa de directorios de Tomcat incluye un directorio llamado webapps que contiene las aplicaciones Web. Es en ´este directorio donde se deben alojar los Servicios Web para tenerlos publicados al resto del mundo y es aqu´ı tambi´en donde se aloja la aplicaci´on AraW 2ord. 3.3.3. Modelo de capas Definidos Interfaz, Servicios Web y Base de Datos, podemos ver el sistema como un modelo de capas, en el que la Interfaz HTML es la capa de presentaci´on, los Servicios Web constituyen la capa de negocio y la Base de Datos y los pictogramas se corresponden con el modelo de datos. La figura 3.8 muestra esta situaci´on: Figura 3.8: Modelo de tres capas En la capa de presentaci´on el usuario visualiza la aplicaci´on, AraW 2ord. Cuando el usuario interacciona con la aplicaci´on ya sea introduciendo una palabra, identific´andose, 26 3. Proceso de an´alisis y desarrollo etc. se realiza una petici´on HTTP21 mediante AJAX22 a la capa de negocio. La capa de negocio est´a formada por el Interfaz de Servicios, el cual procesa la petici´on y accede a la capa de datos. Para el acceso a la capa de datos se conecta el Interfaz de Servicios con MySql usando JDBC23. 21Hypertext Transfer Protocol. Protocolo usado en cada transacci´on de la World Wide Web 22 Asynchronous JavaScript And XML 23JDBC es un API de Java para acceder a manejadores de bases de datos 27 3. Proceso de an´alisis y desarrollo 3.3.4. Visi´on global de de interacci´on con el sistema En la figura 3.9 se muestra el proceso llevado a cabo desde que el usuario realiza una acci´on hasta que visualiza el cambio que se ha producido Figura 3.9: Proceso de interacci´on en AraW 2ord El proceso es el siguiente: 1. El usuario mediante el navegador accede a la url de AraW 2ord y se muestra la aplicaci´on. 2. Ante un cambio (introducci´on de una palabra, identificaci´on, etc.) se llama a una funci´on del Controlador JavaScript. 3. El Controlador realiza una petici´on AJAX mediante jQuery al Interfaz de Servicios. 4. El Interfaz de Servicios opera con la Base de Datos. 5. Se devuelven los datos de Base de Datos al Interfaz de Servicios. 6. Si la operaci´on lo requiere (ej. b´usqueda de palabra) se accede al Servidor de Pictogramas para recuperar la imagen que corresponda. 7. El Interfaz de Servicios tras procesar la petici´on devuelve el resultado al Controlador. 8. El Controlador presenta los datos en el Interfaz HTML. 9. Finalmente, el usuario puede ver el cambio que ha producido su acci´on. 28 Cap´ıtulo 4 Resultados obtenidos A continuaci´on se describe brevemente el resultado obtenido del desarrollo de la Interfaz de Servicios y de la aplicaci´on. 4.1. Interfaz de Servicios Como resultado de la implementaci´on del Interfaz de Servicios, el resultado es la publicaci´on de dichos servicios de forma p´ublica y gratuita, de manera que est´en accesibles al resto de desarrolladores. En la siguienre url quedan publicados los Servicios Web: http://alkaid.cps.unizar.es:8090/arawordWebServices/services/listServices Se puede ver que est´an distribuidos por paquetes y accediendo a uno de esos paquetes podemos ver el WSDL1en el que se definen las operaciones disponibles. En la figura 4.1 se muestran los servicios disponibles y en la figura 4.2 un ejemplo de WSDL. Figura 4.1: Interfaz de Servicios 1Web Services Description Language, un formato XML que se utiliza para describir servicios Web 29 4. Resultados obtenidos Figura 4.2: WSDL del paquete UserTasks 30 4. Resultados obtenidos 4.2. Aplicaci´on AraW 2ord La aplicaci´on est´a disponible en la url mostrada a continuaci´on: http://alkaid.cps.unizar.es:8090/arawordapp/ La figura 4.3 muestra el resultado de la aplicaci´on en funcionamiento. Como se aprecia se ejecuta en un navegador Web y el men´u principal est´a formado por dos o cuatro pictogramas, dependiendo si estamos identificados o no en la aplicaci´on. Figura 4.3: AraW 2ord Vamos a dar una breve descripci´on de los contenidos representados en la imagen: 1 - Logo de AraWord (lleva a la home, que es la pantalla mostrada) 2 - Permite la modificaci´on de par´ametros como el tama˜no de letra (10), el tama˜no de imagen (9), etc. 3 - Gesti´on de pictogramas propios 4 - Logout. Cierra la sesi´on actual 5 - Cuadro de introducci´on de texto 6 - Validaci´on de la frase. Si no ha ocurrido ning´un problema aparece la opci´on de mandar la frase por correo electr´onico o de imprimirla (8) 7 - Borra la frase actual (resetea el cuadro de texto y borra todos los pictogramas) 31 38 Bibliograf´ıa [1] Ezpeleta Mateo, Joaqu´ ın yP´ erez Marco, Joaqu´ ın AraWord : un procesador de textos para comunicaci´on aumentativa y adaptativa, 2011 [2] Ezpeleta Mateo, Joaqu´ ın yPalacio Juli´ an, Carolina,TICO e 1.0: mejora y extensi´on de la aplicaci´on TICO para su primera distribuci´on estable, 2010 [3] Ezpeleta Mateo, Joaqu´ ın,Marco Rubio, Javier yTICO4Android: Implementaci´on de TICO para dispositivos m´oviles basados en Android, 2013 [4] Baldassarri Santa Luc´ ıa, Sandra yFerrer Domingo, Eduardo,Garc´ ıa Azpiroz, Marta,Creaci´on de herramientas software de apoyo a la comunicaci´on alternativa y aumentativa, 2012 [5] ARASAAC,Portal Aragon´ es de la Comunicaci´ on Aumentativa y Alternativa,http://www.catedu.es/arasaac/ [6] Taller de Servicios Web y SOA,M´aster de Bases de Datos e Internet, Curso 2011/2012 [7] Proyecto TICO,http://www.proyectotico.es/wiki/index.php/AraWord 39 40 Anexo A. Evoluci´on orientada a servicios En este anexo se describe el proceso necesario que supone el cambio de una aplicaci´on de escritorio a una aplicaci´on Web basada en una filosof´ıa orientada a servicios. Para ello, se analizan las principales diferencias entre plataformas en las que se ejecutan y posteriormente se describen los aspectos b´asicos a tener en cuenta y las decisiones que se deben tomar. A.1. Diferencias entre aplicaciones de Escritorio y aplicaciones Web Para tener claro que aspectos se deben implementar y qu´e es necesario cambiar hay que tener en cuenta las principales diferencias entre el desarrollo de aplicaciones de escritorio y aplicaciones Web. As´ı mismo tambi´en conviene realizar una comparativa de ventajas y desventajas que influyen para realizar una aplicaci´on Web o no. Una aplicaci´on de Escritorio es aquella que est´a instalada en el equipo del usuario y es ejecutada directamente por el sistema operativo. Su rendimiento depende de los elementos hardware del equipo como son memorias RAM, discos duros, etc. Las principales ventajas y desventajas son: Ventajas Desventajas Su ejecuci´on no requiere comunicaci´on con el exterior Acceso limitado al equipo donde est´an instaladas El tiempo de respuesta es muy r´apido Dependen del SO1del equipo Suelen ser bastante seguras Requieren instalaci´on y actualizaci´on personalizada 41 A. Evoluci´on orientada a servicios Una aplicaci´on Web est´a instalada en un Servidor y su ejecuci´on requiere disponer de un navegador Web y conexi´on a Internet. Las principales ventajas y desventajas son: Ventajas Desventajas Portabilidad: se ejecutan desde cualquier dispositivo Es necesaria una conexi´on a Internet Id´oneas para aplicaciones multiusuario Dependencia de una buena conexi´on a Internet Suelen ser aplicaciones ligeras El Servidor debe tener las prestaciones necesarias Consumen pocos recursos del equipo Tiempos de respuesta m´as lentos F´aciles de actualizar y mantener Compatibilidad con diferentes tipos de navegadores Independientes del SO Una vez analizadas las principales diferencias podemos hacernos a la idea de los componentes necesarios para el desarrollo de una aplicaci´on Web: Dispositivo con conexi´on a Internet Servidor donde alojar la aplicaci´on A.2. Orientaci´on a Servicios La arquitectura orientada a servicios o SOA2es un software de dise˜no y un patr´on de dise˜no software basado en piezas discretas de software para proporcionar funcionalidad como servicios a otras aplicaciones. Un servicio es una unidad aut´onoma de funcionalidad con una interfaz estable y p´ublica que puede ser invocado por un cliente. La idea para lograr esto consiste en desarrollar una serie de m´odulos o paquetes que estar´an alojados en el Servidor y accesibles mediante una interfaz p´ublica. En la figura A.1 se pueden diferenciar las distintas capas que componen el modelo SOA. 2Service-oriented architecture 42 A. Evoluci´on orientada a servicios Figura A.1: Capas del modelo SOA Para desarrollar la capa de Servicios actualmente existen dos arquitecturas: SOAP3y REST4. SOAP es un protocolo est´andar que define c´omo dos objetos en diferentes procesos pueden comunicarse por medio de intercambios de datos en XML. Las operaciones se definen como puertos WSDL5. Estos ficheros describen todas las funciones de la interfaz as´ı como el tipo de datos de entrada y de salida. REST no est´a considerado como una arquitectura propiamente dicha. Es un estilo de arquitectura software que se centra en el uso de est´andares para la transmisi´on de datos sin necesidad de contar con una capa adicional. Las operaciones se solicitan mediante GET, POST, PUT y DELETE lo que supone que no es necesaria ninguna implementaci´on especial para consumir estos servicios. En REST los servicios no publican un conjunto de m´etodos sino que lo que se publican son recursos. Un recurso se puede considerar como una entidad que representa un concepto de negocio que puede ser accedido p´ublicamente. Para este proyecto hemos elegido SOAP ya que es un est´andar y es una arquitectura estable, aunque REST cada vez cobra m´as fuerza ya que se basa en los principios que hicieron posible la Web. 3Simple Object Access Protocol 4Representational State Transfer 5Web Services Description Language 43 A. Evoluci´on orientada a servicios A.3. Motor de los Servicios Web El motor usado para el desarrollo de los servicios Web ha sido Apache Axis26. Axis2 proporciona un completo modelo de objetos y una arquitectura modular que facilita la tarea de a˜nadir funcionalidad y dar soporte a nuevos servicios Web. Las principales caracter´ısticas de Axis2 son: Axis2 soporta SOAP 1.1 y SOAP 1.2 y adem´as integra soporte para REST. Velocidad Uso reducido de memoria Despliegue instant´aneo Servicios web as´ıncronos Soporte de MEP7 Flexibilidad Estabilidad Despliegue orientado a componentes Framework de transporte Soporte de WSDL Agregados Composici´on y extensibilidad La figura A.2 muestra el motor Apache Axis2 desplegado en el Servidor Tomcat: 6http://axis.apache.org/axis2/java/core/ 7Message Exchange Patterns 44 A. Evoluci´on orientada a servicios Figura A.2: Apache Axis2 Con el Interfaz de Servicios correctamente publicado y desplegado en nuestro Servidor Web ya disponemos de la l´ogica de negocio para nuestra aplicaci´on. La Interfaz de la aplicaci´on Web residir´a en los diversos clientes HTML desplegados en el Servidor Web, con lo que nuestra aplicaci´on queda accesible al resto del mundo. 45 A. Evoluci´on orientada a servicios 46 Anexo B. Distribuci´on temporal del proceso B.1. Modelo Incremental Para la realizaci´on de este proyecto se ha elegido un modelo de proceso incremental. ´ Este combina elementos del Modelo Lineal Secuencial con la filosof´ıa interactiva de Construcci´on de Prototipos. Como se muestra en la Figura B.1, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado n´ucleo. Figura B.1: Modelo Incremental Como primer incremento podemos definir el primer prototipo de la aplicaci´on compuesto por un cliente sencillo HTML con un cuadro texto y el servicio Web de b´usqueda de palabras. A partir de ah´ı, se van definiendo los dem´as incrementos hasta desarrollar el sistema completo. 47 C. Descripci´on detallada del proceso de desarrollo org.apache.commons.codec.binary.Base64: Biblioteca para codificar y decodificar im´agenes en base 64. mysql-connector-java-5.1.23: Driver JDBC de Java para MySQL. C.3.2. Dise˜no de la base de datos Para el dise˜no de la base de datos se ha partido del modelo existente en AraWord[1] y se ha extendido. En AraWord la base de datos consta de tres tablas y est´an gestionadas con sQLite. A diferencia de los sistema de gesti´on de bases de datos cliente-servidor, el motor de SQLite no es un proceso independiente con el que el programa principal se comunica. En este proyecto se ha optado por tener un servidor de bases de datos MySQL versi´on 5.5.32 dado que la base de datos no se integra con el programa sino que se acceder´a a ella por medio de los servicios web. Adem´as se han a˜nadido m´as tablas, las cuales se definen a continuaci´on: main: Tabla presente en AraWord[1]. Esta tabla est´a formada por 5-tuplas que contienen toda la informaci´on referente a un pictograma. Las tuplas est´an formadas por estos 5 t´erminos: word: Nombre del concepto idL: Clave del lenguaje de la palabra idT: Clave del tipo de la palabra name: Nombre normalizado de la imagen guardado en el servidor de pictogramas nameNN: Nombre no normalizado de la imagen. No utilizado, se mantiene por compatibilidad con TICO. language: Tabla presente en AraWord. Contiene los pares (id, lenguaje). type: Tabla presente en AraWord. Contiene los pares (id, tipo de palabra). main for user: Esta tabla es nueva. Se ha a˜nadido para guardar las im´agenes propias de cada usuario. Consta de 6-tuplas con los valores [word, idL, idT, name, nameNN, idUser]. Los primeros cinco valores son los mismos que los definidos en la tabla main y el ´ultimo valor hace referencia al usuario que posee dicho pictograma. encoded images bytes: Tabla nueva. Guarda la codificaci´on de las im´agenes contenidas en la tabla main for user. users: Tabla que contiene la informaci´on y las preferencias de un usuario. verbs: Tabla que contiene los verbos en espa˜nol. Contiene los pares (verbo, forma verbal). track: Tabla nueva. Tabla que guarda el registro de las frases. Se utilizar´a en un futuro para poder sacar estad´ısticas de im´agenes m´as usadas, etc. 54 C. Descripci´on detallada del proceso de desarrollo track info: Tabla nueva. Describe la informaci´on presente en la tabla track. releases: Tabla nueva. Permite gestionar versiones de la base de datos. No usada en esta versi´on. application: Tabla que contiene datos referentes a la versi´on actual de la aplicaci´on. Las tablas application y releases no se usan en esta versi´on, pero se plantean para poder utilizarlas en un futuro si se extiende a TICO la orientaci´on a Servicios. A continuaci´on se muestra el diagrama de la base de datos: Figura C.3: Base de Datos de AraW ord2 C.3.3. Dise˜no de la Aplicaci´on En la figura C.4 puede apreciarse la divisi´on en subsistemas de los diferentes modulos que componen la aplicaci´on. El dise˜no de la aplicaci´on se ha realizado con tecnolog´ıas Web utilizando HTML, CSS y JavaScript. 55 C. Descripci´on detallada del proceso de desarrollo Figura C.4: Diagrama de paquetes de la Aplicaci´on AraW ord2 La aplicaci´on se compone de una Interfaz HTML y de una Interfaz JavaScript: Interfaz HTML: Contiene todos los ficheros que conforman la aplicaci´on. Estos forman la interfaz con la que el usuario interacciona. Consta de los siguientes ficheros: •Ficheros HTML: index.html, Login.html, myData.html, myPictograms.html, newUser.html, pinta frase.html. •Hojas de estilo CSS: bootstrap.css, bootstrap-responsive.css, smallDevices.css Interfaz JavaScript: Contiene todos los m´etodos para realizar las invocaciones a la Interfaz de Servicios y el modelo de clases que se presenta en la Interfaz HTML. •webservices.functions.js: Funciones para realizar la invocaci´on al API de Servicios. •utils2.js: Modelo de Objetos y funciones para gestionar la Interfaz HTML. C.3.4. Servidor Web El servidor Web utilizado para realizar el despliegue de la Interfaz de Servicios y de la aplicaci´on AraW 2ord ha sido Apache Tomcat en su versi´on 7.0.40. Apache Tomcat no es una servidor de aplicaciones sino un contenedor de servlets desarrollado en Apache Software Foundation1. Tomcat es un Servidor Web con soporte de servlets o JSPs. Una vez instalado, podemos diferenciar la siguiente jerarqu´ıa de ficheros: bin - arranque, cierre, y otros scripts y ejecutables. 1http://www.apache.org/ 56 C. Descripci´on detallada del proceso de desarrollo common - clases comunes que pueden utilizar Catalina y las aplicaciones web. conf - ficheros XML y los correspondientes DTD para la configuraci´on de Tomcat. logs - logs de Catalina y de las aplicaciones. server - clases utilizadas solamente por Catalina. shared - clases compartidas por todas las aplicaciones web. webapps - directorio que contiene las aplicaciones web. work - almacenamiento temporal de ficheros y directorios. Configuraci´on de Tomcat Para la instalaci´on de Tomcat se habilita el puerto 8090 en el servidor Alkaid del DIIS. Para realizar la configuraci´on se modifica el fichero server.xml contenido en la carpeta conf y se confira el puerto del servidor, el puerto del conector y el conector AJP2. Para arrancar y parar el servidor se proporcionar dos scripts, startup.sh y shutdown.sh, contenidos en la carpeta bin. Despliegue en Tomcat Para realizar el despliegue de los servicios Web en Apache Tomcat ser crea un fichero WAR3que contiene todos los m´etodos disponibles y se coloca en la carpeta webapps. C.4. Herramientas Utilizadas Durante la realizaci´on de este proyecto se han utilizado diferentes herramientas y tecnolog´ıas para el desarrollo del software y tareas de documentaci´on. A continuaci´on listamos dichas herramientas y su prop´osito. Sistemas operativos •Windows 7 •Ubuntu GNU/Linux 12.04 •Android 4.0.4 Prop´osito general •Google Chrome 29.0.1547.57 m An´alisis y dise˜no •Dia Diagrams 0.97.2: Generador de diagramas 2Conector que se comunica con un conector Web usando el protocolo AJP 3Web Applicaction Archive 57 C. Descripci´on detallada del proceso de desarrollo •Google Calendar: Planificaci´on de reuniones •Drive Document: Elaboraci´on de actas Desarrollo y pruebas •Eclipse 3.7: Entorno de desarrollo de los servicios web y conexi´on con base de datos. •Apache Axis 2: Motor y contenedor de servicios web. •SoapUI 4.5.1: Aplicaci´on de licencia libre para testear servicios web para arquitecturas orientadas a servicios (SOA). •Java SDK 1.6.0 33: M´aquina virtual Java •Notepad++ 6.1.5: Entorno de desarrollo para la vista (HTML+Javascript) •WinSCP 5.1.5: cliente SFTP gr´afico para Windows que emplea SSH. •PuTTY: es un cliente SSH, Telnet, rlogin, y TCP raw con licencia libre •MySQL Query Browser 1.1.20: Servidor de bases de datos •Apache Tomcat 7.0.4: servidor web con soporte de servlets y JSPs (usado como servidor de aplicaciones web) •Servidor HTTP Apache: servidor web HTTP de c´odigo abierto (usado como contenedor de recursos para almacenar los pictogramas) •OpenShift Documentaci´on •TeXstudio 2.5.2 : Suite para compilar y editar con Latex (usado para la elaboraci´on de la memoria y los anexos) •Dia Diagrams 0.97.2: Generador de diagramas •Microsoft Office Project: Herramienta para los diagramas de Gantt C.5. Pruebas El objetivo de las pruebas es verificar y validar el software, descubrir defectos que no han podido ser detectados con anterioridad y encontrar otros con poco esfuerzo y una alta probabilidad. A lo largo del desarrollo del software se han ido haciendo tests y pruebas, las cuales podemos clasificarlas en: pruebas unitarias, pruebas de integraci´on y pruebas de sistema y usuario. 58 C. Descripci´on detallada del proceso de desarrollo Pruebas unitarias Estas pruebas se han llevado a cabo despu´es de la realizaci´on de cada m´odulo, ya que dichas pruebas permiten probar un m´odulo software de manera independiente. Las ventajas de este tipo de pruebas son que se suelen formar con un bloque de c´odigo muy b´asico y relativamente peque˜no y con ellas se pueden detectar c´alculos incorrectos, estructuras de datos incorrectas, controles de flujo incorrectos, etc. Para comprobar el correcto funcionamiento de los servicios web se ha usado un software llamado SoapUI4que te permite crear un proyecto con los servicios web publicados. Una vez definimos los proyectos a partir de los WSDL se definieron varios documentos XML de prueba para testar los servicios web. La figura C.5 muestra una ejecuci´on en soapUI. En verde se muestran las operaciones disponibles, en azul la petici´on al servicio Web y en rojo la respuesta del servicio Web. Figura C.5: Pruebas con SoapUI Pruebas de integraci´on Una vez superadas las pruebas unitarias se han realizado pruebas de integraci´on, la cuales verifican el correcto ensamblaje de los diferentes m´odulos. Estas pruebas aseguran que los componentes interact´uan correctamente. Dichas pruebas se han llevado a cabo de manera incremental cada vez que se finalizaba un subsistema. Para la realizaci´on de estas pruebas se han dise˜nado clientes HTML sencillos que testan cada uno de los servicios Web. En ellos se comprueba que la integraci´on del servicio Web con el cliente HTML y con la Base de Datos funciona de forma correcta. 4http://www.soapui.org/ 59 C. Descripci´on detallada del proceso de desarrollo La figura C.6 muestra un ejemplo de un cliente HTML para testar el servicio Web de listado de im´agenes propias de usuario. Figura C.6: Pruebas de integraci´on Pruebas de sistema y usuario Estas pruebas tiene como finalidad comprobar la integraci´on del sistema visto desde el punto de vista global y suelen estar basadas en las especificaciones t´ecnicas. Una vez finalizada la aplicaci´on se han realizado pruebas de posibles casos reales y tambi´en pruebas at´ıpicas para estudiar el rendimiento. Se han realizado diferentes pruebas con el comportamiento de la detecci´on de las palabras compuestas ya que ello implica realizar bastantes llamadas a los servicios web y esto es bastante costoso. Se ha observado que con palabras compuestas de m´as de 3 palabras el servicio web tarda bastante en darnos el pictograma asociado y puede ser molesto para el usuario. Entre las pruebas de carga podemos destacar la carga de una imagen muy grande, ya que el sistema tiene que redimensionar la imagen para guardarla en Base de Datos. Se observa que con im´agenes mayores de 5MBytes el tiempo que tarde es bastante alto. Otras pruebas de carga y de usuario han consistido en la comprobaci´on del funcionamiento del software cuando varios usuarios ejecutan la aplicaci´on a la vez. 60 Anexo D. Servicios Web Desarrollados El presente documento tiene la finalidad de describir los servicios Web publicados. login La funci´on login permite al usuario realizar la autenticaci´on en la aplicaci´on y genera una nueva sesi´on. A continuaci´on se detallan la estructura y los campos de los mensajes de petici´on y respuesta. Servicio Wsdl: http://alkaid.cps.unizar.es:8090/arawordWebServices/services/UserTasks?wsdl Operaci´on login Descripci´on La operaci´on realiza la autenticaci´on en la aplicaci´on Tipo/Versi´on SOAP v1.1 y v1.2 Devuelve loginResponse Par´ametro Tipo Input/Output Descripci´on mail XML STRING Input/- Correo electr´onico del usuario que lo identifica de forma un´ıvoca password XML STRING Input/- Password asociado al mail Ejemplo de petici´on XML <soapenv:Envelope xmlns : soapenv =" http :// schemas . xmlsoap . org / soap / envelope /" xmlns : user =" http :// users . org "> <soapenv:Header/> <soapenv:Body> <user:login > <user:mail>a</ user:mail> <user:password >a</ user:password > </ user:login > </ soapenv:Body> </ soapenv:Envelope > 61 D. Servicios Web Desarrollados loginResponse Par´ametro Tipo Input/Output Descripci´on description XML STRING -/Output Descripci´on de c´omo ha ido la operaci´on status XML STRING -/Output Ver C´odigos de error idUser XML STRING -/Output id del usuario error error -/Output Nodo de error error Nodo de error Par´ametro Tipo Input/Output Descripci´on code XML INT -/Output Ver C´odigos de error description XML STRING -/Output Descripci´on del error service XML STRING -/Output Servicio que provoca el error operation XML STRING -/Output Operaci´on que provoca el error Ejemplo de respuesta XML <soapenv:Envelope xmlns : soapenv =" http :// schemas . xmlsoap . org /soap / envelope /" > <soapenv:Body> <ns:loginResponse xmlns : ns =" http :// users . org "> <ns:return xsi: type =" ax21 : LoginResponse " xmlns : ax21 ="http :// general . org / xsd " xmlns : xsi =" http :// www.w3. org /2001/ XMLSchema - instance " > <ax21:description>User found successfully </ ax21:description> <ax21:error xsi: type =" ax21 : ErrorWS " > <ax21:code>150 </ ax21:code> <ax21:description> Execution OK </ ax21:description> <ax21:operation >login </ ax21:operation > <ax21:service> UserTasks </ ax21:service> </ ax21:error > <ax21:status>OK </ ax21:status> <ax21:applicationLanguage>0</ ax21:applicationLanguage> <ax21:documentLanguage>0</ ax21:documentLanguage> <ax21:email >a</ax21:email > <ax21:fontColor># ff0000 </ ax21:fontColor > <ax21:fontSize >16 </ ax21:fontSize > <ax21:fontStyle>Calibri </ ax21:fontStyle > <ax21:idUser>03 fcc072 -efc4 -11 e2 - a177 -0011 d8f42c0a </ ax21: idUser> <ax21:maxNumCompounds >5</ ax21:maxNumCompounds > <ax21:menuType >text </ ax21:menuType > 62 D. Servicios Web Desarrollados <ax21:name>a</ ax21:name> <ax21:numPictosByRow>3</ ax21:numPictosByRow> <ax21:pictoSize >100 </ ax21:pictoSize > <ax21:positionText>up </ ax21:positionText> <ax21:refreshTime>1</ ax21:refreshTime> <ax21:showFont >yes </ ax21:showFont > <ax21:surname>a</ ax21:surname> </ns:return> </ns:loginResponse > </ soapenv:Body> </ soapenv:Envelope > registerNewUser La funci´on registerNewUser permite al usuario registrarse en la aplicaci´on de forma que en los sucesivos accesos puede autenticarse y recuperar su perfil. A continuaci´on se detallan la estructura y los campos de los mensajes de petici´on y respuesta de la funci´on registerNewUser. Servicio Wsdl: http://alkaid.cps.unizar.es:8090/arawordWebServices/services/UserTasks?wsdl Operaci´on registerNewUser Descripci´on La operaci´on registerNewUser registra un nuevo usuario en la base de datos que se identifica de forma un´ıvoca por el mail Tipo/Versi´on SOAP v1.1 y v1.2 Devuelve registerNewUserResponse Par´ametro Tipo Input/Output Descripci´on name XML STRING Input/- Nombre del usuario surname XML STRING Input/- Apellidos del usuario mail XML STRING Input/- Correo electr´onico del usuario que lo identifica de forma un´ıvoca password XML STRING Input/- Password asociado al mail Ejemplo de petici´on XML <soapenv:Envelope xmlns : soapenv =" http :// schemas . xmlsoap . org / soap / envelope /" xmlns : user =" http :// users . org " > <soapenv:Header/> <soapenv:Body> <user:registerNewUser > <user:name> Aaron </ user:name> <user:surname> Torrijos </ user:surname> <user:mail> aaron . torri@gmail . com </ user:mail> <user:password > passwordAaron </ user:password > </ user:registerNewUser > </ soapenv:Body> </ soapenv:Envelope > 63 D. Servicios Web Desarrollados Ejemplo de petici´on XML <soapenv:Envelope xmlns : soapenv =" http :// schemas . xmlsoap . org /soap / envelope /" xmlns : user =" http :// users . org " > <soapenv:Header/> <soapenv:Body> <user:searchPictoForUser > <user:word>abeja </ user:word> <user:idUser></ user:idUser> <user:language >0</ user:language > </ user:searchPictoForUser > </ soapenv:Body> </ soapenv:Envelope > searchPictoForUserForUserResponse Par´ametro Tipo Input/Output Descripci´on pictos pictos -/Output Lista que contiene las im´agenes encontradas description XML STRING -/Output Descripci´on de c´omo ha ido la operaci´on status XML STRING -/Output ver C´odigos de error error error -/Output Nodo de error pictos Lista que contiene las im´agenes encontradas Par´ametro Tipo Input/Output Descripci´on url XML STRING -/Output url de la imagen. En caso que sea una imagen propia se muestra la codificaci´on en base64 type XML STRING -/Output Tipo de palabra de la imagen wordType XML STRING -/Output [WEB,USER] dependiendo de si la imagen es propia del usuario o no Ejemplo de respuesta XML <soapenv:Envelope xmlns : soapenv =" http :// schemas . xmlsoap . org /soap / envelope /" > <soapenv:Body> <ns:searchPictoForUserResponse xmlns : ns =" http :// users . org "> <ns:return xsi: type ="ax21:SearchPictoForUserResponse" xmlns : ax21=" http :// general . org /xsd " xmlns : xsi =" http :// www .w3. org /2001/ XMLSchema - instance " > <ax21:description>Found 2 images for user </ ax21:description> <ax21:error xsi: type =" ax21 : ErrorWS " > <ax21:code>150 </ ax21:code> <ax21:description> Execution OK </ ax21:description> <ax21:operation > searchPictoForUser </ ax21:operation > <ax21:service> UserTasks </ ax21:service> </ ax21:error > 70 D. Servicios Web Desarrollados <ax21:status>OK </ ax21:status> <ax21:pictos xsi: type="ax21:PictoArrayView"> <ax21:pvList> <ax21:type>WEB </ ax21:type> <ax21:url > http :// www . gidhe . es / pictostorrijos /2/2239. png </ ax21:url> <ax21:wordType >0</ ax21:wordType > </ ax21:pvList> <ax21:pvList> <ax21:type>WEB </ ax21:type> <ax21:url > http :// www . gidhe . es / pictostorrijos /2/24823. png </ ax21:url > <ax21:wordType >0</ ax21:wordType > </ ax21:pvList> </ ax21:pictos> <ax21:possibleCompound>false </ax21:possibleCompound> <ax21:possibleCompoundFromBegin>false </ax21: possibleCompoundFromBegin> <ax21:possibleCompoundFromEnd>false </ ax21: possibleCompoundFromEnd> <ax21:possibleCompoundFromMiddle>false </ ax21: possibleCompoundFromMiddle> <ax21:type>0</ ax21:type> </ns:return> </ns:searchPictoForUserResponse> </ soapenv:Body> </ soapenv:Envelope > 71 D. Servicios Web Desarrollados savePreferences La operaci´on savePreferences permite al usuario modificar los siguientes par´ametros: node pictogramas por l´ınea, tama˜no de la fuente, posici´on del texto, color del texto, mostrar el texto, node compuestas, tama˜no de im´agenes, estilo de la fuente, lenguaje del documento, lenguaje de la aplicaci´on, tipo de menu, tiempo de refresco, mostrar borde. A continuaci´on se detallan la estructura y los campos de los mensajes de petici´on y respuesta de la funci´on savePreferences. Servicio Wsdl: http://alkaid.cps.unizar.es:8090/arawordWebServices/services/UserTasks?wsdl Operaci´on savePreferences Descripci´on La operaci´on savePreferences permite al usuario modificar las preferencias Tipo/Versi´on SOAP v1.1 y v1.2 Devuelve savePreferencesResponse Par´ametro Tipo Input/Output Descripci´on idUser XML STRING Input/- identificador del usuario numPictosByRow XML STRING Input/- N´umero de pictogramas a mostrar por l´ınea fontSize XML STRING Input/- Tama˜no de la fuente textPosition XML STRING Input/- Posici´on del texto (encima o debajo de la imagen) fontColor XML STRING Input/- Color de la fuente showText XML STRING Input/- Mostrar el texto o no maxNumCompounds XML STRING Input/- M´aximo n´umero de palabras que forman una compuesta pictoSize XML STRING Input/- Tama˜no del pictograma fontStyle XML STRING Input/- Estilo de la fuente documentLanguage XML STRING Input/- Idioma del documento applicationLanguage XML STRING Input/- Idioma de la aplicaci´on menuType XML STRING Input/- Tipo de menu (texto o pictogramas) refreshTime XML STRING Input/- Tiempo de refresco de los pictogramas borderColor XML STRING Input/- Mostrar si o no el borde del pictograma Ejemplo de petici´on XML <soapenv:Envelope xmlns : soapenv =" http :// schemas . xmlsoap . org /soap / envelope /" xmlns : user =" http :// users . org " > <soapenv:Header/> <soapenv:Body> <user:savePreferences > <user:idUser>03 fcc072 -efc4 -11 e2 - a177 -0011 d8f42c0a </ user:idUser> <user:numPictosRow>4</ user:numPictosRow> <user:fontSize >16 </ user:fontSize > <user:textPosition>up </ user:textPosition> <user:fontColor ># ff0000 </ user:fontColor > <user:showText >yes </ user:showText > <user:maxNumCompounds >3</ user:maxNumCompounds> <user:pictoSize >100 </ user:pictoSize > <user:fontStyle >Calibri </ user:fontStyle > <user:documentLanguage>0</ user:documentLanguage> <user:applicationLanguage>0</ user:applicationLanguage> <user:menuType >picto </ user:menuType > <user:refreshTime>3</ user:refreshTime> </ user:savePreferences > </ soapenv:Body> </ soapenv:Envelope > 72 D. Servicios Web Desarrollados savePreferencesResponse Par´ametro Tipo Input/Output Descripci´on description XML STRING -/Output Descripci´on de c´omo ha ido la operaci´on status XML STRING -/Output Ver C´odigos de error error error -/Output Nodo de error Ejemplo de respuesta XML <soapenv:Envelope xmlns : soapenv =" http :// schemas . xmlsoap . org / soap / envelope /" > <soapenv:Body> <ns:savePreferencesResponse xmlns : ns =" http :// users . org " > <ns:return xsi :type =" ax21 : SavePreferencesResponse " xmlns : ax21 =" http :// general . org /xsd " xmlns : xsi =" http :// www .w3. org /2001/ XMLSchema - instance " > <ax21:description> Preferences changed successfully for user 03 fcc072 -efc4 -11 e2 -a177 -0011 d8f42c0a </ ax21:description> <ax21:error xsi : type =" ax21 : ErrorWS " > <ax21:code>150 </ ax21:code> <ax21:description> Execution OK </ ax21:description> <ax21:operation >savePreferences </ax21:operation > <ax21:service>UserTasks </ ax21:service> </ ax21:error > <ax21:status>OK </ ax21:status> </ns:return> </ns:savePreferencesResponse> </ soapenv:Body> </ soapenv:Envelope > editPicto La funci´on editPicto permite al usuario cambiar el nombre de las im´agenes pertenecientes a su colecci´on. A continuaci´on se detallan la estructura y los campos de los mensajes de petici´on y respuesta de la funci´on editPicto. Servicio Wsdl: http://alkaid.cps.unizar.es:8090/arawordWebServices/services/UserTasks?wsdl Operaci´on editPicto Descripci´on La operaci´on editPicto permite al usuario cambiar el nombre de sus im´agenes Tipo/Versi´on SOAP v1.1 y v1.2 Devuelve editPictoResponse Par´ametro Tipo Input/Output Descripci´on idUser XML STRING Input/- identificador del usuario idName XML STRING Input/- identificador de la imagen newWord XML STRING Input/- Nuevo nombre del pictograma 73 D. Servicios Web Desarrollados Ejemplo de petici´on XML <soapenv:Envelope xmlns : soapenv =" http :// schemas . xmlsoap . org /soap / envelope /" xmlns : user =" http :// users . org " > <soapenv:Header/> <soapenv:Body> <user:editPicto > <user:newWord>datos </user:newWord> <user:idName> misDatos . png </ user:idName> <user:idUser>03 fcc072 -efc4 -11 e2 - a177 -0011 d8f42c0a </ user:idUser> </ user:editPicto > </ soapenv:Body> </ soapenv:Envelope > editPictoResponse Par´ametro Tipo Input/Output Descripci´on description XML STRING -/Output Descripci´on de c´omo ha ido la operaci´on status XML STRING -/Output Ver C´odigos de error error error -/Output Nodo de error Ejemplo de respuesta XML <soapenv:Envelope xmlns : soapenv =" http :// schemas . xmlsoap . org /soap / envelope /" > <soapenv:Body> <ns:editPictoResponse xmlns : ns =" http :// users . org "> <ns:return xsi: type ="ax21:EditResponse" xmlns : ax21 =" http :// general . org / xsd " xmlns : xsi =" http :// www.w3. org /2001/ XMLSchema - instance " > <ax21:description>Picto edited successfully for user 03 fcc072 -efc4 -11 e2 - a177 -0011 d8f42c0a </ ax21:description> <ax21:error xsi: type =" ax21 : ErrorWS " > <ax21:code>150 </ ax21:code> <ax21:description> Execution OK </ ax21:description> <ax21:operation >editPicto </ ax21:operation > <ax21:service> UserTasks </ ax21:service> </ ax21:error > <ax21:status>OK </ ax21:status> </ns:return> </ns:editPictoResponse> </ soapenv:Body> </ soapenv:Envelope > 74 D. Servicios Web Desarrollados C´odigos de Error Status Descripci´on OK La operaci´on ha finalizado correctamente FAIL Error en la operaci´on ERROR Error grave 100-199 C´odigos OK 100 Inserci´on en BD OK 101 Borrado en BD OK 150 Ejecuci´on OK 200-299 C´odigos ERROR 200 Error insertando en BD 201 Error eliminando en BD 250 Ejecuci´on ERROR (Unexpected error) 251 Error al cerrar la conexi´on con BD 300-399 C´odigos FAIL 300 Datos replicados en BD 301 Datos no presentes en BD 302 Datos no encontrados en BD 75 D. Servicios Web Desarrollados 76 Anexo E. Manual de usuario En este anexo se presenta el manual de usuario de la aplicaci´on AraW 2ord. Dado que se trata de una aplicaci´on Web y no se requiere la instalaci´on de ning´un software adicional, simplemente se describen de forma detallada las operaciones que se pueden realizar. Tambi´en se proporciona un storyboard1que proporciona una visi´on global de las tareas que se pueden ejecutar. E.1. Manual de usuario E.1.1. P´agina principal de la aplicaci´on La figura E.1 muestra la p´agina principal de la aplicaci´on AraW 2ord, la cual est´a accesible mediante la url http://alkaid.cps.unizar.es:8090/arawordapp/. En esta pantalla se permite la edici´on de texto y se da acceso para entrar en la aplicaci´on si se posee una cuenta de usuario o de crear una cuenta nueva. En todas las opciones se muestra el logo de AraWord que proporciona un enlace con la p´agina principal, es decir, la p´agina de edici´on de texto. Figura E.1: P´agina de inicio de AraW 2ord 1Conjunto de ilustraciones mostradas en secuencia con el objetivo de servir de gu´ıa para entender un proceso 77 E. Manual de usuario E.1.2. Registro o identificaci´on de usuarios La figura E.2 muestra la ventana de identificaci´on de usuarios y proporciona un enlace para realizar el registro de nuevos usuarios. Para la identificaci´on es necesario introducir el email y la contrase˜na correctamente. Figura E.2: Ventana de login 78 E. Manual de usuario E.1.3. Registro de nuevo usuario La figura E.3 muestra la ventana para el registro de nuevos usuarios. Para el registro de un usuario nuevo se debe proporcionar nombre, apellidos, email y contrase˜na. Figura E.3: Ventana de registro de usuarios E.1.4. Opciones para usuarios registrados Una vez que se accede a la aplicaci´on como un usuario registrado aparecen unos men´us adicionales. La figura E.4 muestra la pantalla de inicio de un usuario registrado. Los men´us de izquierda a derecha son: pantalla de inicio, gesti´on de preferencias, gesti´on de pictogramas y cierre de sesi´on. Figura E.4: Pantalla de inicio para usuario registrados 79