Repositorio Institucional de Documentos

Repositorio de la Universidad de Zaragoza – Zaguan http://zaguan.unizar.es ! Proyecto Fin de Carrera AraSuite: Integración de las aplicaciones de TICO y AraWord. Autor Adrián Gómez Llorente Director Joaquín Ezpeleta Mateo Escuela de Ingeniería y Arquitectura (EINA) 2014 A mi tutor, Joaqu´ın Ezpeleta, por darme la oportunidad de participar en un gran proyecto y ser paciente ante una dedicaci´on que en algunos momentos fue dificil. A mis padres, por su dedicaci´on completa, su apoyo incondicional y por empujarme para llegar hasta aqu´ı. A mi familia, por rodearme con su apoyo y escuchar una y otra vez los entresijos de este proyecto. A mis amigos y compa˜neros, porque en esta vida hace falta tener humor para coger fuerzas. En especial a Jorge Pinto, por imprimir su creatividad en el logotipo de AraSuite. AraSuite: Integraci´on de las aplicaciones de TICO y AraWord RESUMEN Este proyecto fin de carrera (PFC) se ha realizado con la colaboraci´on de profesionales del Colegio P´ublico de Educaci´on Especial Alborada (C.P.E.E Alborada) y el Centro Aragon´es de Tecnolog´ıas para la Educaci´on (CATEDU). En este PFC se ha realizado el desarrollo de la aplicaci´on llamada AraSuite. Esta aplicaci´on es un conjunto de herramientas que trabajan de forma conjunta para hacer m´as f´acil el trabajo diario con personas que tienen graves trastornos en la expresi´on oral, de forma que su d´ıa a d´ıa se vea mejorado. El presente proyecto surge como soluci´on al problema existente en las aplicaciones TICO y AraWord en las que la informaci´on es gestionada de manera independiente por cada una de ellas, generando datos duplicados y un entorno de trabajo que no es efectivo, haciendo que ambas aplicaciones sean dif´ıciles de mantener. AraSuite parte de la situaci´on actual y crea un entorno que centraliza toda la gesti´on de la informaci´on, ofrece m´etodos de acceso a los datos y evoluciona la situaci´on actual hacia una suite de aplicaciones que se comportan como una ´unica herramienta facilitando el trabajo diario de profesores y tutores. Con la creaci´on de AraSuite se agrupa el desarrollo de las aplicaciones existentes TICO y AraWord bajo un mismo c´odigo. Adem´as, se define una arquitectura y unos flujos de desarrollo que facilitan la participaci´on de otros desarrolladores para a˜nadir nuevas funcionalidades, de esta manera, se pretende convertir a AraSuite en un referente entre las aplicaciones opensource que facilitan la interacci´on con personas con dificultades para la expresi´on oral. El resultado final obtenido es una aplicaci´on de c´odigo libre que actualmente, con casi 2500 descargas mensuales, es usada en el mundo entero por miles de personas. Los usuarios, valoran muy positivamente el uso de la herramienta destacando su facilidad de uso y el gran aporte que hace en el trabajo diario. Adem´as, gracias a la forma de trabajo definida y a la arquitectura aplicada, se ha agilizado la entrega de nuevas versiones de AraSuite que hacen que esta aplicaci´on est´e en continua evoluci´on. ´ Indice P´agina 1. Introducci´on 1 1.1. Ideageneral.............................. 1 1.1.1. Las herramientas TICO y AraWord . . . . . . . . . . . . 1 1.2. Objetivos ............................... 2 1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . 2 2. An´alisis 4 2.1. Terminolog´ıa ............................. 4 2.2. Requisitos............................... 4 2.3. Casosdeuso ............................. 5 2.4. Interfaz de acceso a los datos . . . . . . . . . . . . . . . . . . . . 5 2.5. Especificaci´on del plan de pruebas . . . . . . . . . . . . . . . . . 6 3. Dise˜no 8 3.1. Especificaci´on de casos de uso . . . . . . . . . . . . . . . . . . . . 8 3.2. Dise˜no de interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Dise˜no de la base de datos . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Dise˜no de la API de acceso a datos . . . . . . . . . . . . . . . . . 12 3.5. Arquitectura de directorios . . . . . . . . . . . . . . . . . . . . . 13 4. Desarrollo 15 4.1. Tecnolog´ıas empleadas . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Metodolog´ıa de desarrollo . . . . . . . . . . . . . . . . . . . . . . 16 4.3.1. Metodolog´ıa Scrum . . . . . . . . . . . . . . . . . . . . . . 17 4.3.2. Metodolog´ıa Extreme Programming . . . . . . . . . . . . 17 4.3.3. Elecci´on de la metodolog´ıa . . . . . . . . . . . . . . . . . 17 4.4. Interfaces del GalleryManager . . . . . . . . . . . . . . . . . . . . 18 4.5. Puntos destacados de la implementaci´on . . . . . . . . . . . . . . 18 4.5.1. Redise˜no de la interfaz de resultados de una b´usqueda . . 19 4.5.2. Localizaci´on de los archivos del GalleryManager . . . . . 20 4.5.3. Generaci´on y distribuci´on de versiones intermedias . . . . 20 4.5.4. Internacionalizaci´on de la aplicaci´on . . . . . . . . . . . . 21 4.5.5. Actualizaci´on autom´atica de pictogramas . . . . . . . . . 22 4.5.6. Creaci´on y distribuci´on de versiones finales con instalador 23 4.5.7. Mejora de la velocidad de importaci´on . . . . . . . . . . . 23 4.6. Ejecuci´on del plan de pruebas . . . . . . . . . . . . . . . . . . . . 25 i 4.6.1. Ejecuci´on de las pruebas unitarias . . . . . . . . . . . . . 25 4.6.2. Ejecuci´on de las pruebas de sistema . . . . . . . . . . . . 26 4.6.3. Ejecuci´on de las pruebas de aceptaci´on . . . . . . . . . . . 26 4.7. Definici´on del flujo de desarrollo . . . . . . . . . . . . . . . . . . 27 4.7.1. Estructura del repositorio . . . . . . . . . . . . . . . . . . 27 4.7.2. Flujos de trabajo . . . . . . . . . . . . . . . . . . . . . . . 28 4.8. Generador de versiones . . . . . . . . . . . . . . . . . . . . . . . . 28 5. Gesti´on del proyecto 30 5.1. Sprints de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . 30 6. Conclusiones y trabajo futuro 31 6.1. Trabajofuturo ............................ 31 A. Requisitos 34 A.1. Requisitos de TICO . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.2. Requisitos de AraWord . . . . . . . . . . . . . . . . . . . . . . . . 35 B. Casos de uso 36 B.1. Casos de uso de Usuario . . . . . . . . . . . . . . . . . . . . . . . 37 B.2. Casos de uso de Aplicaci´on . . . . . . . . . . . . . . . . . . . . . 38 B.3. Casos de uso de AraWord . . . . . . . . . . . . . . . . . . . . . . 39 C. Interfaces del GalleryManager 41 D. Especificacion casos de uso 48 D.1. Casos de uso de Usuario . . . . . . . . . . . . . . . . . . . . . . . 48 D.2. Casos de uso de Aplicaci´on . . . . . . . . . . . . . . . . . . . . . 51 D.3. Casos de uso de AraWord . . . . . . . . . . . . . . . . . . . . . . 51 E. M´etodos de acceso a BD 61 F. Detalles del plan de pruebas 65 F.1. Planificaci´on y ejecuci´on de las pruebas . . . . . . . . . . . . . . 65 F.1.1. Planificaci´on de las pruebas unitarias . . . . . . . . . . . . 65 F.1.2. Planificaci´on de las pruebas de sistema . . . . . . . . . . . 65 F.1.3. Planificaci´on de las pruebas de aceptaci´on del usuario . . 65 F.2. Identificaci´on de los puntos cr´ıticos de la aplicaci´on . . . . . . . . 66 G. Ejecuci´on de las pruebas de sistema 68 G.1. Punto cr´ıtico 1: La importaci´on de una base de datos . . . . . . . 68 G.2. Punto cr´ıtico 2: La exportaci´on de una b´usqueda . . . . . . . . . 69 G.3. Punto cr´ıtico 3: La actualizaci´on autom´atica de los pictogramas . 69 G.4. Punto cr´ıtico 4: B´usquedas en la BD con s´ımbolos extra˜nos y expresiones regulares . . . . . . . . . . . . . . . . . . . . . . . . . 70 G.5. Punto cr´ıtico 5: La ejecuci´on en los distintos sistemas operativos 71 H. Prototipos de interfaces 72 I. Diagrama de la base de datos 78 I.1. Tablas de la base de datos . . . . . . . . . . . . . . . . . . . . . . 78 ii I.2. Relaciones de la base de datos . . . . . . . . . . . . . . . . . . . . 79 J. Manual del desarrollador 80 J.1. Estructura del repositorio . . . . . . . . . . . . . . . . . . . . . . 80 J.2. Flujosdetrabajo........................... 80 J.3. Generaci´on de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . 81 K. Generador de versiones 82 K.1. An´alisis del generador de versiones . . . . . . . . . . . . . . . . . 82 K.1.1. Requisitos del generador de versiones . . . . . . . . . . . . 82 K.1.2. Arquitectura del generador de versiones . . . . . . . . . . 82 K.2. Dise˜no del generador de versiones . . . . . . . . . . . . . . . . . . 83 K.2.1. Estructura del generador de versiones . . . . . . . . . . . 83 K.2.2. Ejecuci´on del generador de versiones . . . . . . . . . . . . 84 K.2.3. Interfaz del generador de versiones . . . . . . . . . . . . . 85 K.3. Desarrollo del generador de versiones . . . . . . . . . . . . . . . . 87 K.3.1. Interfaces finales del generador de versiones . . . . . . . . 87 K.3.2. Despliegue del generador de versiones . . . . . . . . . . . 88 K.4. Conclusiones y trabajo futuro . . . . . . . . . . . . . . . . . . . . 89 L. Licencia GNU-GPL v2.0 91 iii ´ Indice de diagramas 2.1. Casos de uso general . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Diagrama de actividad Copiar pictograma portapapeles . . . . . 9 3.2. Diagrama de actividad Importar pictogramas . . . . . . . . . . . 10 3.3. Prototipo de la interfaz principal . . . . . . . . . . . . . . . . . . 11 3.4. Dise˜nodelaBD ........................... 12 3.5. API de acceso a datos . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6. Arquitectura de directorios . . . . . . . . . . . . . . . . . . . . . 14 4.1. Interfaz de exportaci´on de b´usqueda . . . . . . . . . . . . . . . . 19 4.2. Interfaz de Actualizar autom´aticamente pictogramas . . . . . . . 19 4.3. Gr´afica comparativa de la velocidad de importaci´on . . . . . . . 24 4.4. Gr´afica de descargas de AraSuite en Sourceforge . . . . . . . . . 26 4.5. Estructura del repositorio . . . . . . . . . . . . . . . . . . . . . . 29 5.1. An´alisis de desviaci´on de los sprints . . . . . . . . . . . . . . . . 30 B.1. Casos de uso general . . . . . . . . . . . . . . . . . . . . . . . . . 36 B.2. Casos de uso de Usuario . . . . . . . . . . . . . . . . . . . . . . . 37 B.3. Casos de uso de Aplicaci´on . . . . . . . . . . . . . . . . . . . . . 39 B.4. Casos de uso de AraWord . . . . . . . . . . . . . . . . . . . . . . 40 C.1. Interfaz principal . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 C.2. Interfaz de b´usqueda de im´agenes para editar . . . . . . . . . . . 42 C.3. Interfaz para editar los t´erminos de una imagen . . . . . . . . . . 44 C.4. Interfaz para a˜nadir una imagen . . . . . . . . . . . . . . . . . . 45 C.5. Interfaz de exportaci´on de b´usqueda . . . . . . . . . . . . . . . . 46 C.6. Interfaz de importaci´on de BD . . . . . . . . . . . . . . . . . . . 46 C.7. Interfaz de Actualizar autom´aticamente pictogramas . . . . . . . 47 D.1. Diagrama de actividad A˜nadir pictograma . . . . . . . . . . . . . 52 D.2. Diagrama de actividad Buscar pictogramas . . . . . . . . . . . . 53 D.3. Diagrama de actividad Eliminar pictograma . . . . . . . . . . . . 54 D.4. Diagrama de actividad Importar pictogramas . . . . . . . . . . . 55 D.5. Diagrama de actividad Modificar pictograma . . . . . . . . . . . 56 D.6. Diagrama de actividad Copiar pictograma . . . . . . . . . . . . . 57 D.7. Diagrama de actividad Importar pictogramas . . . . . . . . . . . 58 D.8. Diagrama de actividad Exportar pictogramas . . . . . . . . . . . 59 D.9. Diagrama de actividad Lanzar aplicaci´on GalleryManager . . . . 60 iv este proyecto a ofrecer una interfaz de m´etodos que permita a las aplicaciones gestionar los pictogramas y t´erminos de una manera interna. Esto ser´a especialmente ´util para AraWord, ya que es una aplicaci´on que necesita realizar b´usquedas en los pictogramas para convertir un t´ermino, o varios, en un pictograma mientras que el usuario escribe. El tercer grupo de requisitos lo formar´ıan aquellos que a˜naden nuevas funcionalidades o son m´as t´ecnicos, como la actualizaci´on autom´atica o mantener la velocidad de acceso a la informaci´on. 2.3. Casos de uso Tras un an´alisis de los requisitos del proyecto, de recoger impresiones del director del proyecto, y analizar las necesidades que ten´ıan los usuarios que hab´ıan estado usando TICO y AraWord, se han identificado varios casos de uso derivados de las operaciones con los pictogramas que AraSuite debe ofrecer al usuario y a otras aplicaciones. En el anexo B se puede ver un detalle de todos ellos. En la figura 2.1 se puede ver el diagrama de casos de uso general. En ´el se han identificado cuatro actores, Usuario, que representa a las personas que van a usar la aplicaci´on, por ejemplo un profesor, el usuario Aplicaci´on, que representa a las aplicaciones que necesitan acceder a la gesti´on de pictogramas, y TICO y AraWord que representan a las aplicaciones ya existentes y que hacen uso de los pictogramas. Usuario puede realizar todas las operaciones relacionadas con la gesti´on de pictogramas, pero para realizar cualquiera de ellas, es obligatorio que la aplicaci´on lance la ¨ Interfaz de administraci´on del GalleryManager”. Por otro lado, podemos ver que los actores TICO y AraWord tienen como casos de uso, ”Lanzar la interfaz de administraci´on del GalleryManager”, y adem´as, tiene un caso de uso que podr´ıamos definir como una operaci´on interna que permite realizar b´usquedas sobre la base de datos. 2.4. Interfaz de acceso a los datos Para analizar cu´al es la mejor opci´on a la hora de dise˜nar el interfaz de acceso a datos del GalleryManager que posteriormente utilizar´ıan TICO, AraWord u otras futuras herramientas, se realiz´o un estudio de los distintos m´etodos que se ejecutaban sobre la base de datos de pictogramas por parte de ambas aplicaciones para identificar aquellas necesidades que pudieran tener. Como podemos ver en el anexo E, TICO y AraWord tienen variados m´etodos de acceso a la base de datos (BD). Es por esta raz´on por la que se ha decidido que el GalleryManager se comporte, grosso modo, como un DAO (Data Access Object). 5 Figura 2.1: Casos de uso general De esta manera, el GalleryManager publicar´a m´etodos generales de acceso a la BD, abstrayendo a las aplicaciones que usen la librer´ıa de otras cosas como la conexi´on con la BD, drivers de acceso, etc. 2.5. Especificaci´on del plan de pruebas La especificaci´on de un plan de pruebas permite garantizar al desarrollador un cierto nivel de calidad de la aplicaci´on y asegura que en el futuro el desarrollo contendr´a menos errores debido a las bater´ıas de test. Por las caracter´ısticas de este proyecto se ha decidido que el plan de pruebas a realizar ser´a el siguiente: 6 Pruebas unitarias: Son las pruebas formales que garantizan que un m´etodo, dados unos par´ametros de entrada, tiene el comportamiento esperado. Pruebas de sistema: Son aquellas pruebas que garantizan el correcto funcionamiento de los puntos cr´ıticos identificados en el anexo F.2. Pruebas de aceptaci´on del usuario: Son las pruebas que se realizan en un entorno de funcionamiento controlado que garantizan que el software desarrollado es funcional en condiciones normales. En el anexo F se puede ver una explicaci´on ampliada de las pruebas a realizar y el momento de hacerlas. 7 3. Dise˜no En esta secci´on de la memoria se va a exponer la propuesta planteada para resolver todas las necesidades y requisitos que se identificaron en el apartado anterior. 3.1. Especificaci´on de casos de uso Antes de realizar el dise˜no de las interfaces se han tomado los casos de uso identificados en el anexo B, a partir de los cuales se ha realizado un estudio de las acciones que tiene que desempe˜nar cada usuario para hacer cada una de las operaciones. Para ello, se ha realizado una especificaci´on de los casos de uso mediante diagramas de actividad que servir´an para el posterior dise˜no de las interfaces finales que se realiza en la secci´on 3.2. A modo de ejemplos, a continuaci´on se detallan dos casos de uso. Cons´ultese el Anexo D para un desarrollo completo. Caso de uso: Copiar pictograma a portapapeles Definici´on: El usuario realizar´a una b´usqueda para encontrar el pictograma que desea copiar al portapapeles, posteriormente tendr´a que pulsar el bot´on de copiar y la imagen se enviar´a al portapapeles desde donde podr´a ser usada por otra aplicaci´on. V´ease la figura 3.1. Precondici´on: La versi´on de Java instalada en el sistema operativo debe soportar el copiado al portapapeles. Postcondici´on: La imagen estar´a disponible en el portapapeles. Interfaz que lo implementa: Interfaz de edici´on de un pictograma ya existente. Caso de uso: Actualizar pictogramas Definici´on: El usuario pulsar´a el bot´on de comprobar actualizaciones. En caso de no haber en el servidor de pictogramas ninguna versi´on posterior a 8 Figura 3.1: Diagrama de actividad Copiar pictograma portapapeles la instalada en el ordenador del usuario, se mostrar´a un di´alogo informando de que se tiene la ´ultima versi´on. En caso de que haya un nuevo paquete de pictogramas se mostrar´a informaci´on del mismo. Si el usuario decide actualizar se descargar´a el paquete, se descomprimir´a y se importar´an los pictogramas mostrando la interfaz de la figura C.6. Los detalles se muestran en el diagrama de la figura 3.2. Precondici´on: El ordenador debe tener acceso a Internet. Postcondici´on: Si hay una nueva versi´on de pictogramas se descargar´an, importar´an y sustituir´an a los que tengan el mismo nombre. En caso contrario no se producir´an cambios. Interfaz que lo implementa: Interfaz Actualizar pictogramas. 3.2. Dise˜no de interfaces Una de las funcionalidades que tiene que ofrecer AraSuite es una serie de interfaces de gesti´on que posteriormente se integrar´an en las distintas aplicaciones, como TICO y AraWord, y permitir´an al usuario acceder a las funcionalidades de los pictogramas. TICO y AraWord son proyectos que ya contienen, por duplicado, distintas 9 Figura 3.2: Diagrama de actividad Importar pictogramas interfaces que permiten realizar operaciones de gesti´on sobre los pictogramas. Adem´as estas herramientas ya est´an en producci´on y son muchos los usuarios que las utilizan, por lo tanto, se ha decidido que las nuevas interfaces del GalleryManager ser´an similares a las ya existentes en TICO y AraWord, de esta manera se mantendr´a la usabilidad actual. TICO, AraWord y otras posibles aplicaciones futuras tendr´an que lanzar las interfaces de gesti´on que ofrece el GalleryManager. Tras evaluar como ser´ıa la mejor forma de integrar estas interfaces en el resto de aplicaciones, se ha decidido que la mejor soluci´on es que el GalleryManager tenga una interfaz principal como la que se puede ver en la imagen de la figura 3.3. Esta interfaz ser´a el punto de acceso a partir de la cual el usuario podr´a navegar por el resto de interfaces de gesti´on de pictogramas. De esta manera se ha conseguido que en caso de a˜nadir una nueva funcionalidad de gesti´on de pictogramas al GalleryManager, el cambio ser´a transparente para el resto de aplicaciones ya que ´unicamente habr´a que a˜nadir la nueva opci´on a la interfaz principal. Y adem´as, aislamos el GalleryManager del resto de aplicaciones y podemos reaprovechar esta organizaci´on para dotar al GalleryManager de un sistema de interfaces que le permitan trabajar como una aplicaci´on independiente. 10 Figura 3.3: Prototipo de la interfaz principal Se han realizado prototipos de todas las interfaces de la aplicaci´on para cumplir las funcionalidades detectadas en el diagrama de casos de uso de la figura 2.1. Estos prototipos y una explicaci´on detallada de cada uno de ellos puede encontrarse en el anexo H. 3.3. Dise˜no de la base de datos Uno de los requisitos es que las velocidades de importaci´on y acceso a datos fueran mejores que las existentes. Por lo tanto es necesaria una remodelaci´on de la base de datos ya que hay operaciones de tipo join1que lastran las consultas a la base de datos. Por esta raz´on, se ha decidido plantear un dise˜no de la base de datos que evitara operaciones de “join” de tablas, para reducir de esta manera el coste de operaci´on en la base de datos y agilizar as´ı las b´usquedas. Antes de pasar a explicar el dise˜no de la base de datos que se ha desarrollado conviene explicar algunas consideraciones previas que se han tomado: Uso del ingl´es para la nomenclatura de las tablas y los atributos: As´ı se evitan posibles problemas de codificaci´on de caracteres. Uso de enteros auto-incrementados como primary keys:En aquellos casos en los que sea necesario establecer relaciones entre tablas, se usar´an enteros auto-incrementados como foreign keys aunque el contenido de las propias tablas pueda contener una primary key. A pesar de que esto introduce una clave que pudiera resultar innecesaria por existir una primary key natural, se ha decidido que los beneficios prevalecen frente a las contraindicaciones. Las razones que han ayudado a tomar esta decisi´on son: que se permite que las primary key naturales cambien de valor, 1Operaci´on que devuelve como resultado el producto cartesiano de dos o m´as tablas. Estas operaciones tienen un alto coste operacional. 11 el rendimiento es mayor dados los ´ındices m´as peque˜nos y las relaciones se entienden mejor. En el diagrama de la figura 3.4 se ve el dise˜no de la base de datos propuesto. Para m´as informaci´on sobre la BD se puede ver el anexo I. Figura 3.4: Dise˜no de la BD 3.4. Dise˜no de la API de acceso a datos Durante el an´alisis, en el apartado 2.4 y en el anexo E se han mostrarlo cuales son las necesidades de acceso a datos de TICO y AraWord. En funci´on de las necesidades tan diferentes de ambas aplicaciones me he decantado por ofrecer una soluci´on que fuera lo m´as generalista posible. Esta soluci´on se ha basado en ofrecer los siguientes m´etodos: query(): Ejecuta una consulta en la BD y devuelve el resultado en un cursor que se podr´a recorrer para hacer uso de los datos obtenidos. update(): Ejecuta una operaci´on para modificar un valor existente en la BD. prepareStatement(): Cachea una consulta en la BD para agilizar su posterior ejecuci´on. De esta manera el GalleryManager se comporta como un Data Access Object (DAO, Objeto de Acceso a Datos) suministrando una interfaz com´un de acceso a la BD a cualquier aplicaci´on. En el diagrama de la figura 3.5 se muestra soluci´on expuesta. Con esta soluci´on podemos garantizar que se mantiene el control sobre todas las operaciones realizadas sobre la base de datos. Adem´as, se controla el n´umero de conexiones abiertas contra la base de datos ya que el GalleryManager gestiona la creaci´on y ciclo de vida de las conexiones con la DB. De esta manera evitamos 12 Figura 3.5: API de acceso a datos que se abran m´ultiples conexiones y optimizamos los recursos, ya que abrir una conexi´on con la DB es una de las operaciones que mayor coste operacional tiene. Adem´as, como podemos ver en el diagrama de la figura 3.5, el API del GalleryManager tambi´en interact´ua con un fichero de configuraci´on. Este fichero contendr´a todos par´ametros de configuraci´on de la BD, como el directorio donde se encuentra, la localizaci´on de los pictogramas, la ´ultima fecha de actualizaci´on de pictogramas y la URL de actualizaci´on autom´atica. El fichero de configuraci´on tendr´a una estructura que contendr´a en cada l´ınea un par clave valor con la informaci´on necesaria. 3.5. Arquitectura de directorios Otro de los requisitos del proyecto es que las aplicaciones de TICO y AraWord se comporten como una ´unica suite compartiendo im´agenes y base de datos. Finalmente las aplicaciones se han organizado como se muestra en la imagen de la figura 3.6. De esta manera las aplicaciones est´an juntas bajo un mismo directorio y el usuario intuye la aplicaci´on como si fuera una ´unica suite y no varias aplicaciones sueltas. 13 Figura 3.6: Arquitectura de directorios 14 Posteriormente, se evolucion´o este sistema como se puede ver en el apartado 4.8 y se cre´o una aplicaci´on web llamada AraSuite Generator que ejecutaba estos build.xml para automatizar todo este proceso. El resultado de esta soluci´on era una web que permit´ıa al proyectante o al tutor generar una versi´on con un ´unico click, algo que fue vital de cara a probar nuevas funcionalidades, identificar errores y realizar un seguimiento del proyecto por parte del tutor, que se hac´ıa a menudo por la metodolog´ıa de desarrollo utilizada. 4.5.4. Internacionalizaci´on de la aplicaci´on Tanto TICO como AraWord son aplicaciones que est´an internacionalizadas. Sin embargo, al ser aplicaciones que se desarrollaron independientemente, cada una de ellas tiene sus idiomas y su sistema de internacionalizaci´on. El problema es que ambas aplicaciones hacen uso del GalleryManager y, por lo tanto, el GalleryManager debe estar preparado para adaptarse a la forma de internacionalizar de TICO o AraWord, ya que las interfaces que muestra tienen que estar en el idioma de la aplicaci´on padre. Dada esta situaci´on ten´ıamos varias dificultades que hab´ıa que resolver. C´omo hacer llegar al GalleryManager el idioma de la aplicaci´on que lo ejecuta El GalleryManager tiene una ´unica manera de invocar sus interfaces que es a trav´es de la invocaci´on del “frame” principal. A la hora de invocar este “frame” se pasa como par´ametro el idioma de la interfaz de la aplicaci´on padre y el GalleryManager guarda el idioma en un fichero de configuraci´on para que se use durante toda la ejecuci´on. A continuaci´on se muestra un extracto del c´odigo fuente para ver c´omo el GalleryManager recibe el idioma como par´ametro y lo guarda en el archivo de configuraci´on. public mainFrame( String language ) { // Save languge into configuration file . TConfiguration . setLanguage(language) ; // Load language for interface from configuration file TLanguage . initLanguage ( TConfiguration . getLanguage () ) ; // [...] } Y, a continuaci´on, se muestra c´omo se invoca el GalleryManager desde una aplicaci´on como TICO o AraWord. public void actionPerformed(java .awt. event . ActionEvent evt) { mainFrame f = new mainFrame(G. applicationLanguage ) ; f.setVisible(true); 21 f.pack(); } C´omo relacionar el idioma de la aplicaci´on padre y los idiomas del GalleryManager TICO y AraWord ten´ıan formas de identificar los idiomas que no eran est´andares, por ejemplo el Castellano se identificaba con la clave “Castellano”, el Ingl´es con la clave “Ingles”, etc. Por esta raz´on, y con intenci´on de estandarizarlo, se decidi´o que el GalleryManager identificar´ıa los idiomas usando el est´andar ISO 639-1 2. Para relacionar las claves de TICO con el GalleryManager se hizo un fichero lang.properties como el que se muestra a continuaci´on: CASTELLANO=e s INGLES=en FRANCES= f r PORTUGUES=p t PORTUGUES BRASIL=b r CATALAN=c a ITALIANO=i t As´ı, el GalleryManager al recibir “Castellano” buscar´ıa la clave en el fichero language.properties, que en este caso ser´ıa “es” y cargar´ıa el fichero de idiomas es.properties. Este sistema permite a˜nadir un idioma al GalleryManager de una forma sencilla ya que solo habr´ıa que introducir la nueva clave en el fichero language.properties, por ejemplo, “Euskera=eu” y a˜nadir el fichero eu.properties al directorio de idiomas del GalleryManager. 4.5.5. Actualizaci´on autom´atica de pictogramas Uno de los requisitos de AraSuite, era que tuviera implementada la actualizaci´on autom´atica de pictogramas. Esta actualizaci´on ha sido uno de los puntos importantes que se han afrontado durante el desarrollo del proyecto. Finalmente se ha optado por la soluci´on que se muestra en el diagrama de actividad de la figura 3.2. En resumen, esta soluci´on ha consistido en establecer en el archivo de configuraci´on de AraSuite el servidor donde encontrar´a la informaci´on sobre las nuevas actualizaciones. Cuando el usuario quiera realizar una actualizaci´on, AraSuite consultar´a un archivo remoto de informaci´on con una estructura como la que se muestra a continuaci´on: DOWNLOAD URL= h t t p s : //s3 .amazonaws .com/pictos .zip MD5= 01be832107feefebba5bf76275e8185a RELEASE DATE=04072013 2M´as informaci´on en: http://es.wikipedia.org/wiki/ISO_639-1 22 CHANGELOG=U s e u n d e r C r e a t i v e Commons BYNCSA license De este fichero obtendr´a principalmente, la fecha del paquete, y la URL de descarga. En caso de que se haya publicado un nuevo paquete y que el usuario quiera actualizar, lo descargar´a y comenzar con el proceso de importaci´on. De esta manera el sistema queda m´as configurable y nos permite mover los paquetes de pictogramas a otros servidores en caso de que se espere un gran n´umero de actualizaciones, y tan solo habr´ıa que cambiar la URL de descarga en el fichero remoto de informaci´on. 4.5.6. Creaci´on y distribuci´on de versiones finales con instalador Uno de los requisitos de AraSuite era generar instaladores de la aplicaci´on para los tres sistemas operativos predominantes, Windows, MacOS y Linux. Se buscaba un generador de instaladores que a partir del paquete creado por el generador de versiones, que se puede ver en el anexo K, creara 3 ejecutables para cada uno de los SO que hemos comentado anteriormente. En este momento se realiz´o un an´alisis de varias aplicaciones que permit´ıan generar los instaladores, tales como: IZPack, PackJacket o Install4J. Finalmente nos decantamos por usar Install4J ya que adem´as de generar el instalador, permite crear lanzadores de aplicaciones, incluir o excluir archivos para cada SO, genera desinstalador y permite poner splash screens e iconos configurables. Install4J adem´as tambi´en permite ser integrado con ANT de manera que en un futuro se podr´ıa automatizar toda la generaci´on de instaladores e integrarlo con un sistema de integraci´on continua que nos generar´ıa los instaladores a partir del c´odigo fuente, ante eventos como la creaci´on de un “TAG” en el repositorio, o en cada “commmit” en “trunk”. 4.5.7. Mejora de la velocidad de importaci´on Una de las necesidades de este proyecto es que la velocidad de acceso a los pictogramas fuera la misma o mejor que la existente hasta el momento, por esta raz´on, en este apartado se va a realizar un estudio de una de las partes de la aplicaci´on que mayor coste operacional tiene, la importaci´on de pictogramas a la base de datos. Esta importaci´on consiste recorrer e importar los datos de pictogramas que aparecen en un XML y copiar los pictogramas al directorio interno del GalleryManager. La operaci´on de trasladar las im´agenes al directorio del GalleryManager es una operaci´on de copia de ficheros. Por lo tanto las posibles reducciones que se puedan llevar a cabo en este apartado son bastante escasas. Es por eso por 23 lo que vamos a centrar nuestros esfuerzos en reducir el proceso de “parsing” e importaci´on de los datos de los pictogramas desde el XML a la base de datos. Muestra usada para la importaci´on En el estudio de la velocidad de importaci´on se han analizado los tiempos de ejecuci´on para el antiguo entorno usado en TICO y AraWord y para el nuevo entorno de AraSuite. Para ello se han realizado 10 ejecuciones usado una muestra de pictogramas de las siguientes caracter´ısticas: N´umero de pictogramas a importar: 1400 Espacio en disco de los pictogramas: 67MB T´erminos a insertar en la BD: 22.217 Resultados del an´alisis Figura 4.3: Gr´afica comparativa de la velocidad de importaci´on Los resultados obtenidos son un tiempo medio de ejecuci´on de 71 segundos para el caso del entorno ya existente y de 9,6 segundos para el caso del nuevo entorno de AraSuite. En la gr´afica de la figura 4.3 se pueden ver los tiempos m´ınimo, m´aximo y medio para cada uno de los entornos. Analizando los resultados obtenidos el tiempo medio de importaci´on de la nueva versi´on de AraSuite (9,6 segundos) presenta una mejora del 86 % frente a la versi´on de TICO (71 segundos). 24 4.6. Ejecuci´on del plan de pruebas En la secci´on 2.5 se ha definido el plan de pruebas que se iba a ejecutar de cara a garantizar la calidad del software desarrollado. En esta secci´on se explica cuando se han realizado las ejecuciones del plan de pruebas, los resultados obtenidos e informaci´on adicional sobre cada uno de ellos. 4.6.1. Ejecuci´on de las pruebas unitarias Durante el desarrollo de este proyecto se cre´o un entorno de pruebas unitarias que permitieron probar funciones complejas para garantizar que cualquier desarrollo posterior no modificara el resultado esperado. Esto, adem´as de garantizar el desarrollo realizado, tambi´en deb´ıa servir para establecer una base que permitiera tener pruebas unitarias en futuros desarrollos. A continuaci´on se explica c´omo se estructuraron y se ejecutaron las pruebas unitarias. Descripci´on de las pruebas unitarias Se han especificado ciertos patrones para ayudarnos a identificar en qu´e consiste cada una de las pruebas unitarias que se desarrollan. Para hacerlo lo m´as mantenible posible, se ha evitado a˜nadir JavaDoc explicativo a cada uno de los tests ya que si el test cambia tambi´en hay que cambiar el JavaDoc y podemos llegar a situaciones incongruentes. As´ı que para saber qu´e realiza cada prueba unitaria se usar´a el t´ıtulo de la misma de la siguiente manera: Nombre del m´etodo probado, precondici´on de la prueba y resultado esperado, usando un formato camelcase. Un ejemplo de t´ıtulo de una prueba unitaria ser´ıa: “escapeQueryWithSeveralRegexShouldReturnEscaped” esto identificar´ıa una prueba unitaria que har´ıa lo siguiente: Nombre del m´etodo probado: escapeQuery. Precondici´on: Se van a usar varias expresiones regulares Resultado esperado: Las queries correctamente escapadas. (Opcional) Entorno de ejecuci´on de pruebas Las pruebas unitarias se han desarrollado usando JUnit 4.0 ya que est´a completamente integrado tanto con el IDE (Eclipse) como con ANT y resulta muy 25 c´omodo para realizar test unitarios sobre c´odigo Java. La ejecuci´on se ha automatizado mediante un “target” de ANT para poder ejecutarlo durante la compilaci´on de la aplicaci´on y que un fallo en las pruebas unitarias haga que no se compile una versi´on. De esta manera garantizamos que todas las versiones distribuidas habr´an pasado satisfactoriamente las pruebas unitarias. Cada una de las ejecuciones de las pruebas unitarias dan como resultado un informe HTML que contiene informaci´on sobre los tests que se han pasado, el tiempo de ejecuci´on, y el resultado de cada uno de ellos. 4.6.2. Ejecuci´on de las pruebas de sistema En el anexo F se identificaron los puntos cr´ıticos de la aplicaci´on. Al finalizar el desarrollo se realizaron pruebas para confirmar que la aplicaci´on era estable en cualquiera de esos puntos cr´ıticos. El proceso y los resultados de las pruebas de sistema realizadas se encuentra en el anexo G. La ejecuci´on de las pruebas del sistema fue satisfactoria para todos los puntos cr´ıticos, sin embargo, la ejecuci´on de alguna de ellas sirvi´o para detectar puntos de mejora en el rendimiento de la aplicaci´on. Por ejemplo, las pruebas de exportaci´on de una b´usqueda detectaron que esta operaci´on se prolongaba durante mucho tiempo. Por esta raz´on se decidi´o modificar el algoritmo de exportaci´on para minimizar el tiempo de ejecuci´on. 4.6.3. Ejecuci´on de las pruebas de aceptaci´on Las pruebas de aceptaci´on tienen que garantizar que la aplicaci´on se comporta de manera estable en situaciones normales de ejecuci´on. Una vez que se tuvo una versi´on que se consideraba estable de la aplicaci´on se liber´o la versi´on AraSuite 1.0.0 para los 3 sistemas operativos y se puso al alcance de todos los usuarios en el portal de Sourceforge. Figura 4.4: Gr´afica de descargas de AraSuite en Sourceforge Tal y como se puede ver en la gr´afica extra´ıda de Sourceforge de la figura 4.4, AraSuite comenz´o teniendo 1120 descargas en el primer mes, creciendo 26 exponencialmente hasta las casi 4000 descargas actuales. Gracias a la activa participaci´on de los usuarios, se han ido recogiendo errores y sugerencias de mejora, que han sido incluidos por el equipo de desarrollo en nuevas versiones de AraSuite. Cabe destacar que ninguno de los errores encontrados desde la versi´on 1.0.0 se ha considerado un error cr´ıtico o bloqueante. En la mayor´ıa de los casos han sido errores menores que no influ´ıan de forma negativa en la estabilidad de la aplicaci´on. Por lo tanto, se considera que estas pruebas de aceptaci´on basadas en el feedback recibido por parte de los usuarios son suficientes para garantizar que la aplicaci´on es estable. 4.7. Definici´on del flujo de desarrollo En esta secci´on se definen todos los detalles relacionados con el desarrollo de nuevas funcionalidades o correcci´on de errores en AraSuite, veas´e el anexo J para informaci´on m´as detallada. 4.7.1. Estructura del repositorio AraWord y TICO son aplicaciones en continuo desarrollo donde varias personas est´an trabajando en nuevas funcionalidades o correcciones de errores. Uno de los problemas detectados en los repositorios de TICO y AraWord es que no hay un flujo de trabajo definido por lo que a lo largo del tiempo se ha llegado a una situaci´on de falta de organizaci´on en ambos repositorios que ni si quiera sigue las convenciones de uso de SVN. Con la creaci´on de AraSuite se ha creado un repositorio nuevo que sigue las normas de SVN y adem´as define flujos de trabajo claros que facilitan el desarrollo conjunto. A continuaci´on se muestra como queda organizado el repositorio de AraSuite: Trunk: Contiene la ´ultima versi´on estable de la aplicaci´on con las nuevas funcionalidades y correcciones realizadas. •AraWord: Contiene los ficheros de AraWord. •GalleryManager: Contiene los ficheros del GalleryManager. •TICO: Contiene los ficheros de TICO. •Utils: Contiene aplicaciones externas relacionadas con AraSuite. Arasaac2xml: Aplicaci´on que genera un XML con la informaci´on de Arasaac. ArasuiteVersioner: Aplicaci´on web que genera versiones de AraSuite. 27 Branches: Contiene los desarrollos de nuevas funcionalidades. Deben tener un nombre descriptivo de la funcionalidad realizada. Tags: Contiene cada una de las versiones liberadas de AraSuite. 4.7.2. Flujos de trabajo A la hora de trabajar en AraSuite deben seguirse los flujos de trabajo definidos a continuaci´on. Creaci´on de nuevas funcionalidades: Deben realizarse siempre bajo un branch con un nombre descriptivo (add-sound-to-cells, create-newawesome-functionality, etc.) Una vez terminadas y sincronizadas con trunk deben ser sometidas a varias pruebas de ejecuci´on que garanticen que la nueva funcionalidad no ha introducido errores en el c´odigo existente. Una vez terminado este proceso pueden ser mergeadas con trunk. Correcci´on de bugs: Se llevar´a un seguimiento de los bugs mediante los tickets de Sourceforge, a˜nadiendo una descripci´on detallada del problema, la criticidad del bug y la persona que lo corregir´a. Los bugs se corregir´an directamente en trunk puesto que debe tratarse de peque˜nas modificaciones que ´unicamente resuelven el problema detectado. Release de versiones de AraSuite: Cuando se considere que hay suficientes cambios se realizar´a un peque˜no periodo de pruebas sobre trunk, una vez finalizado y comprobado que todo funciona corr´ectamente se generar´a un nuevo tag. El tag se nombrar´a num´ericamente y de forma ascendente en tres niveles x.x.x, por ejemplo: 1.1.0, 2.2.0, etc. El primer valor indicar´a “major releases” de la aplicaci´on que incluir´an grandes cambios y funcionalidades. El segundo valor agrupar´a a peque˜nas funcionalidades o correcciones de bugs, mientras que el tercer valor servir´a para identificar peque˜nas releases liberadas con 1 o 2 bugs resueltos. Estos tags nunca ser´an modificados. En la imagen de la figura 4.5 puede verse de forma m´as descriptiva la organizaci´on del repositorio. 4.8. Generador de versiones Como se ha visto en el apartado 4.5.3 para probar una versi´on de AraSuite hac´ıa falta hacer un checkout de los tres repositorios TICO, AraWord y GalleryManager. Esto dificultaba mucho que cualquier persona que no estuviera directamente relacionada con el desarrollo pudiera realizar pruebas de nuevas funcionalidades o encontrar bugs en la versi´on de AraSuite. Entonces se decidi´o que facilitar la generaci´on de versiones de AraSuite pod´ıa ser cr´ıtico de cara a ir descubriendo nuevas funcionalidades que pudieran ser 28 Figura 4.5: Estructura del repositorio ´utiles, e identificar bugs de forma temprana gracias a distribuir versiones entre usuarios que testear´ıan la aplicaci´on. Por esta raz´on se decidi´o crear un generador de versiones con una usabilidad muy sencilla. Este generador de versiones est´a liberado en la url http://arasuitegenerator. adgomez.com. Para ver informaci´on detallada sobre el generador de versiones se puede ver el anexo K. 29 5. Gesti´on del proyecto La gesti´on del proyecto se vio muy influenciada por la situaci´on actual del proyectante, ya que en el momento de empezar el proyecto ya hab´ıa comenzado a trabajar en una empresa y por lo tanto el tiempo dedicado al proyecto estaba fuertemente influenciado por los problemas de agenda y las variaciones en las cargas de trabajo de la misma. 5.1. Sprints de desarrollo La organizaci´on del proyecto se ha visto influenciada principalmente por la disponibilidad del proyectante. Los periodos de trabajo, o sprints, se definieron en ciclos de 3 semanas, en la imagen de la figura 5.1 podemos ver el tiempo invertido en cada periodo y su desviaci´on. Figura 5.1: An´alisis de desviaci´on de los sprints 30