Repositorio Institucional de Documentos

Proyecto Fin de Carrera Ingenier´ıa Inform´atica Junio de 2011 AraWord: Un procesador de textos para comunicaci´on aumentativa y adaptativa Joaqu´ın P´erez Marco Director: Dr. Joaqu´ın Ezpeleta Mateo Departamento de Informática e Ingeniería de Sistemas Agradecimientos A mi director Joaqu´ın Ezpeleta, por confiar en m´ı para este proyecto, implic´andose en ´este desde el primer momento. A Jos´e Manuel Marcos y C´esar Canal´ıs, profesores del CPEE Alborada, y David Romero de ARASAAC, por su amabilidad y ayuda a lo largo del proyecto. Y por supuesto, a mis compa˜neros de clase, amigos, familia, y en general a todas aquellas personas que me han apoyado durante estos meses de trabajo. AraWord: Un procesador de textos para comunicaci´on aumentativa y adaptativa Resumen Existen personas que por diversas lesiones padecen graves trastornos en el habla lo que les limita a la hora de comunicarse con el entorno que les rodea. Para facilitarles la expresi´on sin utilizar la palabra hablada surgen los llamados sistemas aumentativos y alternativos de comunicaci´on que complementan o sustituyen el lenguaje oral. Muchos de ellos recurren al uso de pictogramas que representen, de forma clara y sencilla, los conceptos m´as empleados en la comunicaci´on cotidiana. Este proyecto fin de carrera tiene por objetivo el desarrollo de un procesador de textos, para el ´ambito de la comunicaci´on aumentativa y alternativa, que permita la escritura simult´anea con texto y pictogramas. El procesador incluye algunas de las funcionalidades m´as habituales de este tipo de herramientas (creaci´on, apertura y guardado de documentos, posibilidad de exportar a PDF y archivos de imagen; cortar, copiar y pegar textos, b´usqueda de palabras en el documento, ayuda al manejo de la aplicaci´on, etc), as´ı como las espec´ıficas para el trabajo con el conjunto de pictogramas del Portal Aragon´es de la Comunicaci´on Aumentativa y Alternativa ARASAAC. La interfaz del programa, as´ı como la base de datos con la que trabaja, est´a traducida a ocho idiomas diferentes (castellano, ingl´es, franc´es, alem´an, italiano, catal´an, portugu´es, portugu´es brasile˜no). Es f´acilmente ampliable seg´un las necesidades que surjan en distintos centros educativos. Se distribuye como software libre bajo licencia GPL, y est´a programado en Java, lo que permite su ejecuci´on en distintos sistemas operativos y plataformas (Windows, Linux, Mac...). La aplicaci´on ha sido probada por profesores del CPEE Alborada de Zaragoza, lo que permite garantizar que se ajusta a las necesidades de ´estos desde el primer momento. Pr´oximamente se empezar´a a utilizar en diversos colegios y asociaciones dedicadas a personas con necesidades especiales, y en la docencia de asignaturas universitarias relacionadas con la educaci´on especial. Adem´as, se ha empezado a utilizar en la radio p´ublica aragonesa (Arag´on Radio 2) para generar los titulares de las noticias adaptadas a estas personas con necesidades especiales. ´ Indice general 1. Introducci´on 1 1.1. Motivaci´on ..................................... 1 1.2. Trabajo previo relacionado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3. Objetivosdelproyecto............................... 2 1.4. Contenido y alcance del documento . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conceptos previos 5 2.1. Educaci´onespecial ................................. 5 2.2. Pictograma ..................................... 5 2.3. Sistema de comunicaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Sistemas alternativos y aumentativos de comunicaci´on (SAACs) . . . . . . . 7 3. Proceso de desarrollo 9 3.1. Trabajoprevio ................................... 9 3.2. Definici´on de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Preparaci´on del entorno de trabajo . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Primerosbocetos .................................. 10 3.5. Introducci´on de funcionalidad b´asica . . . . . . . . . . . . . . . . . . . . . . . 12 3.6. Mejora del rendimiento general, y extensi´on de funcionalidades . . . . . . . . 15 3.7. Integraci´on con el resto de aplicaciones de ARASAAC: Tico y AraPicto . . . 16 3.8. Reconocimiento de formas verbales conjugadas en castellano . . . . . . . . . . 16 3.9. Primera versi´on estable. Reuni´on y posteriores modificaciones . . . . . . . . . 17 3.10. Cambio en la base de datos. Gestor de recursos com´un . . . . . . . . . . . . . 17 3.11. ´ Ultimosretoques .................................. 17 4. Conclusiones y trabajo futuro 19 i ii ´ INDICE GENERAL 4.1. Resultadosobtenidos................................ 19 4.2. Problemasencontrados............................... 19 4.3. L´ıneasfuturas.................................... 20 4.4. Valoraci´onpersonal ................................ 20 Cap´ıtulo 1 Introducci´on En el primer cap´ıtulo de esta memoria se va a introducir el Proyecto Fin de Carrera (PFC), exponiendo en primer lugar la motivaci´on para llevarlo a cabo, as´ı como los objetivos que se buscaban con su realizaci´on. Se explicar´a adem´as el trabajo previo en el que se basa y por ´ultimo el contenido y alcance de este documento. 1.1. Motivaci´on A la hora de buscar un proyecto fin de carrera lo que ped´ıa era poder aprovechar los conocimientos adquiridos en algo ´util para otras personas. No quer´ıa que quedase exclusivamente en el ´ambito universitario o investigador y por eso al ver la propuesta de este proyecto, un trabajo que ten´ıa una repercusi´on social directa, lo solicit´e inmediatamente. Se trataba de desarrollar un nuevo software para su uso en un colegio p´ublico de educaci´on especial, cuyos alumnos son j´ovenes que presentan distintas discapacidades f´ısicas o ps´ıquicas, y este software les facilita herramientas para aumentar su capacidad de comunicaci´on con su entorno. Por otra parte no se trataba de ampliar un proyecto ya existente (como pudiera ser TICO 1 ) sino de realizar un programa nuevo, lo cual puede ser complejo, pero que desde mi punto de vista considero mucho m´as interesante. Permite ser extremadamente creativo a la hora de desarrollar soluciones para los problemas que se van presentando, y no est´as muy ligado a decisiones (de an´alisis, dise˜no, implementaci´on u otras) tomadas por otras personas, con las que podr´ıas no estar de acuerdo. 1.2. Trabajo previo relacionado Desde hace varios a˜nos, miembros del Departamento de Inform´atica e Ingenier´ıa de Sistemas 2 (DIIS) vienen colaborando con el grupo de investigaci´on Tecnodiscap 3 . En esta colaboraci´on se desarrollan materiales hardware ysoftware que sirvan de apoyo en las tareas 1http://www.proyectotico.es 2http://diis.unizar.es 3http://tecnodiscap.unizar.es 1 2 Introducci´on formativas que el Colegio P´ublico de Educaci´on Especial Alborada 4 (CPEE Alborada) lleva a cabo con personas que tienen diversas discapacidades f´ısicas y/o ps´ıquicas. Este centro ya dispone de un programa similar al realizado en este proyecto, llamado Escribir con S´ımbolos5. Pese a ser muy completo, tiene una serie de deficiencias. 1. Es de pago (cuesta 80$ por licencia, para un ´unico ordenador), lo cual imposibilita su uso en centros con escasos recursos econ´omicos, o por particulares en similar situaci´on. 2. Es un programa demasiado complejo, muy poco adaptado al uso que se le da en el colegio, y ello provoca que su curva de aprendizaje sea excesiva para la funci´on que debe cumplir. 3. Es poco flexible a la hora de integrar los pictogramas de ARASAAC, que es el est´andar de facto en Arag´on y otras muchas Comunidades Aut´onomas e incluso pa´ıses. 4. Los usuarios especializados de Arag´on est´an acostumbrados a manejar los pictogramas junto con su categorizaci´on para b´usquedas, inserci´on en documentos/proyectos TICO, etc. Integrar todo este conocimiento en Escribir Con S´ımbolos es una tarea muy costosa (se dispone de m´as de 6000 pictogramas y 40000 t´erminos). Adem´as, est´an en varios idiomas y poseen informaci´on adicional sobre el tipo de palabra que es (nombre, adjetivo, verbo, etc.) que no podr´ıamos aprovechar. 5. Por ´ultimo, Escribir Con S´ımbolos no permite el uso de formas verbales conjugadas (salvo pasado simple) lo cual es una caracter´ıstica muy demandada por los usuarios. AraWord s´ı permite el uso de formas verbales simples y compuestas en castellano, en todos los tiempos y modos. El presente PFC parte del concepto de dicho software, aunque adecu´andolo a las necesidades reales del centro. Se ha desarrollado a tiempo parcial durante los meses de septiembre de 2010 a junio de 2011 en el Departamento de Inform´atica e Ingenier´ıa de Sistemas del Centro Polit´ecnico Superior de la Universidad de Zaragoza. 1.3. Objetivos del proyecto Este proyecto fin de carrera tiene por objetivo el desarrollo de un procesador de textos en el ´ambito de la comunicaci´on aumentativa y alternativa, que permita la escritura de texto y sus pictogramas asociados. Entre otras, las funcionalidades que debe tener son las siguientes: 1. Gratuidad absoluta tanto del software como de los pictogramas a utilizar. 2. Creaci´on, apertura y guardado de documentos. 3. Posibilidad de exportar a PDF y archivos de imagen. 4. Cortar, copiar y pegar textos en el propio programa o desde/hacia aplicaciones externas (navegadores, suites ofim´aticas, etc). 4http://centros6.pntic.mec.es/cpee.alborada 5http://www.widgit.com/international/spanish/rebus-only.htm Contenido y alcance del documento 3 Figura 1.1: Ejemplo de documento de Escribir con S´ımbolos 2000 5. Aquellas espec´ıficas para el trabajo con el conjunto de pictogramas del Portal Aragon´es de la Comunicaci´on Aumentativa y Alternativa ARASAAC (marcos de palabras coloreados, uso de la BBDD de im´agenes de dicho portal, etc.). 6. Flexibilidad para integrar dichos pictogramas, as´ı como insertar nuevos seg´un las necesidades del usuario. Uso de la informaci´on extendida de tipo de concepto: nombre, adjetivo, etc. as´ı como manejo autom´atico de formas verbales conjugadas, palabras compuestas... 1.4. Contenido y alcance del documento Este documento se estructura en dos partes: una memoria que resume el trabajo realizado y algunos anexos con documentaci´on t´ecnica m´as detallada del mismo. La memoria est´a dividida en una serie de cap´ıtulos siendo el primero de ellos la presente introducci´on. El cap´ıtulo 2 explica una serie de conceptos del ´ambito de la educaci´on especial necesarios para comprender el resto de la memoria. El cap´ıtulo 3 est´a dedicado a describir el proceso de desarrollo de los objetivos del proyecto. En el ´ultimo cap´ıtulo se recogen las conclusiones del PFC desde el punto de vista del cumplimiento de los objetivos y los diversos problemas encontrados. Tambi´en se detalla el posible trabajo que surge como continuaci´on de este proyecto y se incluye una valoraci´on personal del desarrollo de este PFC. Acompa˜nando a la memoria se adjuntan algunos anexos que explican con m´as detalle los resultados del proyecto y el camino seguido para obtenerlos: 1. Anexo ??: Recoge el desarrollo detallado del software. 2. Anexo ??: Recoge la distribuci´on temporal del proyecto. 3. Anexo ??: Recoge el manual de usuario de la aplicaci´on. 4. Anexo ??: Recoge la licencia bajo la que se distribuye el software realizado. Primeros bocetos 11 Figura 3.1: Web de PangoScrum adecuadamente, para luego ir a˜nadi´endole cada vez m´as funcionalidades y refinando el c´odigo (una aproximaci´on al desarrollo de software bastante frecuente) hasta quedar satisfechos con el resultado. La primera soluci´on fue considerar una l´ınea de texto entera en un campo de texto, pero el alineamiento de las im´agenes con las palabras era muy complicado y se generaban otros problemas derivados, por lo que sustituimos esa idea con la de que un campo de texto es una palabra. As´ı, llegamos a la estructura fundamental que ha permanecido constante hasta el final del proyecto: los elementos (unidad m´ınima de tratamiento) del programa son las palabras. Casi todo el espacio de la ventana principal del programa est´a ocupado por un JTextPane en el que insertamos componentes (paneles) separados por uno o m´as separadores (espacios en blanco, tabuladores, saltos de l´ınea). Cada uno de estos componentes almacena una sola palabra, estando compuestos por un JPanel con dos elementos: una imagen en la parte superior (una JLabel con icono) y un campo de texto en la parte inferior (un JTextField). Tanto este JPanel como el JTextField tienen su funcionalidad por defecto muy ampliada (mecanismo de extensi´on de clases de Java), incluyendo una serie de atributos para cada uno de ellos, y manejadores de eventos interesantes (teclado, rat´on, y foco). Tras ello, hab´ıa que pensar c´omo resolver el problema de encontrar la imagen apropiada a una palabra concreta, y se decidi´o emplear una base de datos SQL sencilla. Con el driver JDBC y SQLite 3.x, fue bastante simple volcar los datos desde un archivo de texto generado por ARASAAC y tener un primer boceto sencillo que mostraba palabras y sus im´agenes asociadas, cada una en un panel, todas ellas insertadas adecuadamente en la zona de escritura principal. 12 Proceso de desarrollo 3.5. Introducci´on de funcionalidad b´asica Despu´es de obtener el visto bueno y algunas sugerencias de los profesores del colegio, empez´o la fase de creaci´on de funciones b´asicas. Primeramente, se cre´o una barra de men´u sencilla, con muy pocas opciones (crear archivo nuevo, abrir y guardar ficheros en texto plano, importar la base de datos a partir del archivo de texto, mostrar ayuda del programa). Todas esas opciones a su nivel m´as b´asico. Tambi´en se incluy´o una funci´on de exportar a PDF (con una librer´ıa de c´odigo abierto, gratuita, iTextPDF), de funcionalidad muy limitada, cuya mejora se dej´o para m´as adelante. Lo siguiente a realizar fue algo elemental: poder ir tecleando nuestro texto, cre´andose los elementos necesarios din´amicamente y cargando las im´agenes adecuadas para cada palabra. Aqu´ı incluimos un event listener de teclado. Fundamentalmente, filtramos caracteres no deseados y vamos escribiendo caracteres. Las teclas especiales, como el espacio, el tabulador o el salto de l´ınea, marcan el final de una palabra, la creaci´on de una nueva y dem´as ajustes. El backspace y la tecla Supr podr´ıan provocar el borrado de un separador, juntando dos palabras en una, con sus acciones asociadas. . . Es posiblemente una de las partes m´as duras del proyecto, debido a la gran cantidad de casos particulares (primer elemento, ´ultimo, partir a mitad de una palabra, etc.) y requiri´o una considerable cantidad de depuraci´on y pruebas, sobre todo en esta fase (y detalles puntuales, a lo largo del resto de proyecto). Una vez lograda una versi´on primitiva de procesador de textos ya relativamente funcional, pasamos a un requisito pedido desde el colegio Alborada y que se intu´ıa problem´atico: las palabras compuestas. En efecto, cepillo de dientes son tres palabras, pero corresponden a un ´unico concepto y por tanto, a una ´unica imagen. Tras analizar detenidamente el problema, la soluci´on pas´o por comprobar tras cada pulsaci´on de tecla (editando el texto del documento) si ser´ıa posible formar una palabra compuesta con las n, n-1, n-2, . . . 1 palabras anteriores y posteriores a la actualmente editada. Esto requiere comprobar bastantes cosas. Que no estamos demasiado cerca del principio o final del texto, en cuyo caso hay algunas combinaciones que no son posibles, que hay una adecuada alternancia de elementos y separadores y que estos son del tipo correcto (por decisi´on de dise˜no, solamente combinaciones tipo ([elemento] [espacio en blanco])* [elementoActivo] ([espacio en blanco] [elemento])* son v´alidas), y que esa palabra compuesta existe en nuestra base de datos (en la mayor parte de ocasiones, no ser´a as´ı, por ejemplo muy contento de no corresponde a ninguna palabra compuesta razonable). Veamos un ejemplo. Con n=3 (la llamada ventana de comprobaci´on de palabras compuestas), si tenemos la siguiente frase: Yo como carne y fruta, borramos carne e insertamos en su lugar patatas fritas (palabra compuesta que tiene un pictograma asociado) el programa comprueba, por este orden: como patatas fritas, patatas fritas y, fritas y fruta, patatas fritas. Aqu´ı deja de comprobar, pues encuentra un resultado satisfactorio. Como se puede apreciar, siempre se intenta encontrar la palabra compuesta m´as larga posible (hipot´eticamente, podr´ıan existir varias posibilidades de palabra compuesta a la vez, aunque de momento no se ha dado tal caso). Como esta tarea es relativamente compleja y sobre todo, hay que ejecutarla muy a menudo, la longitud m´axima de las palabras compuestas que comprobaremos tiene que ser baja (hasta 3 elementos, no da problemas de rendimiento en cualquier computador moderno). Si lo subimos, el programa funciona igual pero se notan m´as los saltos y peque˜no retardo al redibujar. En Introducci´on de funcionalidad b´asica 13 cualquier caso, se incluy´o una funci´on de b´usqueda manual de palabras compuestas, para las escasas situaciones en las que una palabra compuesta tiene 4, 5 o m´as palabras en su interior, y que se puedan juntar de igual modo. Tras ello, hubo que rehacer el m´etodo de partir palabras con espacio en blanco, Supr, backspace y dem´as, llegando a soluciones de compromiso en ciertos casos por rendimiento. En general, se ha intentado agilizar el caso m´as frecuente, dejando siempre la posibilidad manual de buscar palabras compuestas en caso de que el programa no las convierta autom´aticamente bien (pasa en casos muy concretos). Adem´as, en este momento tambi´en se llev´o a cabo una fuerte reestructuraci´on, limpieza y depurado del c´odigo del programa, dividiendo en distintos m´odulos y ficheros lo que antes estaba en uno o dos solamente. Ahora llega el turno de una funci´on muy b´asica tambi´en en un procesador de textos: cortar, copiar y pegar. Para ello hay que incluir un event listener de rat´on. Se realiza una primera versi´on sencilla de selecci´on de elementos, con variables booleanas de estado de la selecci´on y una zona para elementos en portapapeles, por hacer un s´ımil con Word. Pero su depurado es dif´ıcil, y no contempla todos los casos posibles, con lo que se decide pasar el control a una m´aquina de estados adecuada, representada a continuaci´on: Figura 3.2: M´aquina de estados para Cortar, Copiar y Pegar (versi´on 1) Como el sistema Ctrl+clic no termina de convencer, se intenta realizar el de arrastrado de componentes, con lo que hay que a˜nadir otro event listener para la acci´on de arrastre del rat´on. Es evidente que la m´aquina de estados se puede simplificar bastante, y se deja as´ı: Se realizan algunas mejoras menores (eliminar la selecci´on texto interna de los JTextField que impide al sistema de seleccionar elementos funcionar correctamente al hacer drag sobre un JTextField; posibilidad de suprimir directamente los elementos seleccionados con la tecla Supr; imposibilidad de cortar TODOS los elementos del texto (perder´ıamos un lugar donde pegarlos: peque˜na limitaci´on del programa); inclusi´on de un nuevo men´u Edici´on con Cortar, Copiar, Pegar y otros comandos explicados a continuaci´on). 14 Proceso de desarrollo Figura 3.3: M´aquina de estados para Cortar, Copiar y Pegar (versi´on 2) Siguiendo con funciones del men´u de Edici´on, le toca el turno a la b´usqueda de texto, la cual se implement´o sin mucha dificultad (salvo el tema de centrar el foco en el elemento apropiado). Memoriza la ´ultima posici´on en la que has buscado, para poder implementar la funci´on buscar siguiente de cualquier programa de tratamiento de textos (si no fuera as´ı, s´olo podr´ıas buscar la primera ocurrencia de una subcadena en el texto completo). No localiza varias ocurrencias de una subcadena en la misma palabra (mejora innecesaria dado el contexto de la aplicaci´on). Por la misma raz´on, no se implement´o la funci´on Reemplazar, dado que se consider´o innecesario en el entorno de uso del programa. No obstante, es muy sencilla de realizar en caso de verla ´util. Deshacer la ´ultima acci´on realizada requiri´o un poco m´as de tiempo. Tras varios intentos y pruebas, se lleg´o a un dise˜no adecuado, en el cual tenemos varias listas de elementos: la principal, que por comodidad se mantuvo con el mismo nombre, y un conjunto deshacer de listas de elementos, con fotograf´ıas del estado (y elementos) del programa en la modificaci´on realizada 1, 2, . . . , N pasos antes. Por defecto N (ventana de deshacer) es 5, par´ametro ajustable por el usuario (como siempre, incrementarlo aumenta tama˜no de la ventana de deshacer, memoria necesaria y tiempo de CPU invertido en manejo de la funcionalidad, y viceversa). Al realizar alguna modificaci´on de inter´es en los datos del documento, se copia antes un estado de los datos (copia de la lista de elementos a la primera posici´on de las listas viejas) y se realiza la modificaci´on, borrando la ´ultima de la lista en caso de que superemos el tama˜no de la ventana de deshacer (caso habitual). Al dar la orden de deshacer, simplemente pasamos a la lista anterior a la actual (1, 2, 3. . . ) guardando la modificaci´on realizada en el conjunto de listas rehacer. Se llev´o a cabo una nueva reestructuraci´on del c´odigo fuente en m´odulos manejables y con funciones relacionadas entre s´ı, as´ı como una incorporaci´on al men´u Edici´on de la funci´on buscar y deshacer, y algunas mejoras menores del programa en general. La funci´on Rehacer se a˜nadi´o sin ninguna dificultad, tan s´olo teniendo en cuenta que cada cierto tiempo el programa se encargue de efectuar limpieza del conjunto de listas rehacer, ya que durante el funcionamiento normal de la aplicaci´on no se van limpiando autom´aticamente. Mejora del rendimiento general, y extensi´on de funcionalidades 15 Se realiz´o un cuadro de preferencias generales del programa, as´ı como la funcionalidad de ocultar o mostrar la imagen asociada a un determinado pictograma. Posteriormente, se incorporaron las caracter´ısticas multiidioma de la interfaz (espa˜nol e ingl´es en un principio) mediante el uso de ficheros de lenguaje (situados en /lang) y algunos trozos de c´odigo de TICO (para manejo de ResourceBundle). Las preferencias del programa se guardan en un fichero XML situado en /conf, y se cargan y guardan mediante algunas funciones recicladas tambi´en de TICO. 3.6. Mejora del rendimiento general, y extensi´on de funcionalidades Llegados a este punto, el programa empieza a ser perfectamente utilizable en un entorno real. No obstante, al ejecutarlo en un PC menos potente que aquel en el que se desarroll´o hasta ahora (un Quad Core a 2.4 GHz con 4GB de RAM) la velocidad de respuesta era excesivamente lenta, hasta el punto de ser molesto para el usuario. Debido a que esto es totalmente inaceptable, hubo que revisar qu´e pod´ıa provocar tal falta de rendimiento. Fue f´acil encontrar una de las causas del problema: el sistema de Deshacer y Rehacer. Copiar todos los elementos del texto tras cada modificaci´on es extremadamente lento, ya que los objetos deben serializarse, incluso dejando aparte consideraciones de uso excesivo de memoria del sistema. Para solucionarlo se decidi´o redise˜nar completamente el c´odigo de dichas funciones, guardando el texto del documento como String, clase elemental con un rendimiento muy superior. Ello increment´o el rendimiento notablemente, con una ventaja a˜nadida no prevista, y es que el c´odigo es mucho m´as sencillo, legible, mantenible y extensible, am´en de menos proclive a errores. Este cambio funcion´o tan bien que se decidi´o extender a las funciones de Cortar, Copiar y Pegar, con excelentes resultados (aunque menos notables debido a la menor frecuencia de la operaci´on). Adem´as, permiti´o implementar otro requisito de la aplicaci´on, y es poder copiar y pegar texto directamente desde o hacia otras aplicaciones (navegadores web, otros procesadores de textos, etc´etera). Faltaba incluir una caracter´ıstica muy demandada por el CPEE Alborada, y es la utilizaci´on de informaci´on extendida de las palabras de la base de datos acerca de su tipo sint´actico (nombre com´un, nombre propio, verbo, adjetivo. . . ) con distintos c´odigos de color (estandarizados por el Sistema Pictogr´afico de Comunicaci´on, SPC) colocados a modo de marco sobre cada palabra del texto. Debido al uso de un JPanel para almacenar cada palabra y el hecho de que tengan un marco (border) asociado totalmente personalizable, fue muy sencillo de incorporar, requiriendo tan s´olo un sencillo cambio en la estructura de la BD interna. Se adecent´o un poco la interfaz de usuario, agrupando funciones similares en submen´us y eliminando algunas caracter´ısticas obsoletas. Tambi´en se adopt´o el formato XML para los documentos AraWord, de forma que se pueden guardar caracter´ısticas espec´ıficas del documento (idioma, tipo y tama˜no de la fuente, tama˜no im´agenes, etc.) Esto es necesario porque un mismo educador puede tener a su cargo a alumnos con necesidades visuales muy diferentes, e incluso en diferentes idiomas, y facilita enormemente su tarea. Por ´ultimo, en este momento se inici´o la elaboraci´on formal de la memoria (para organizar 16 Proceso de desarrollo adecuadamente lo que hasta ahora eran conjuntos de anotaciones sueltas), tarea que continu´o en paralelo con el desarrollo del c´odigo hasta el final del proyecto. Figura 3.4: Una muestra de Araword ejecut´andose 3.7. Integraci´on con el resto de aplicaciones de ARASAAC: Tico y AraPicto Para poder utilizar una base de datos y una carpeta de pictogramas com´un para las tres aplicaciones, se tuvo que redise˜nar la parte de base de datos de la aplicaci´on, para incluir las funciones desarrolladas por Adri´an G´omez (del PFC AraPicto), al que desde aqu´ı quiero agradecer su ayuda y paciencia conmigo. El problema es que es una base de datos relativamente compleja, y ralentizaba la b´usqueda de las im´agenes (que en AraWord es un asunto cr´ıtico para un manejo de usuario confortable, y en AraPicto no es tan relevante). Tras probar varias soluciones, hallamos la adecuada: una vista espec´ıfica para AraWord de las tablas reales de la base de datos. De este modo, manteniendo las tablas que se usan en el resto de aplicaciones, podemos mantener unos tiempos de acceso razonables a im´agenes de la base de datos. 3.8. Reconocimiento de formas verbales conjugadas en castellano Hasta ahora, s´olo era posible reconocer los verbos en infinitivo, con lo que para escribir por ejemplo yo como patatas y mantener los iconos, hay que escribir yo comer patatas. Este es un problema cl´asico en este tipo de software, y se pudo resolver gracias a la obtenci´on de un listado de verbos en castellano con todas sus formas verbales asociadas, tanto simples como compuestas. Una vez logrado eso, crear una base de datos que contuviese listas de formas verbales con su verbo en infinitivo asociado e incorporar dicha informaci´on a la aplicaci´on fue trivial. Primera versi´on estable. Reuni´on y posteriores modificaciones 17 3.9. Primera versi´on estable. Reuni´on y posteriores modificaciones Tras una reuni´on con los responsables de ARASAAC y el CPEE Alborada, se elabor´o una lista de detalles a mejorar o personalizar, entre ellos, detecci´on autom´atica del ´ultimo pictograma usado para una palabra dada, posibilidad de asignar texto libre a un pictograma (por ejemplo, sustituir la palabra ni˜no por Antonio sin perder la imagen asociada), mejorar la calidad de las im´agenes exportadas, posibilidad de elegir entre diferentes listas de palabras (conjunto de pictogramas de ARASAAC, o de lengua de signos espa˜nola, etc), cambio del color del texto, as´ı como poder ponerlo en la parte superior o inferior del pictograma. Se corrigieron tambi´en problemas con s´ımbolos de puntuaci´on. Tambi´en se reorganizaron las funciones de los men´us para que fuesen m´as intuitivas para usuarios acostumbrados a manejar otros procesadores de texto convencional como Microsoft Word. 3.10. Cambio en la base de datos. Gestor de recursos com´un La base de datos com´un que se ven´ıa utilizando hasta ahora, aunque funcional, presentaba un tiempo de importaci´on de im´agenes bastante alto debido a su complejidad interna. Tras una reuni´on decidimos que buena parte de su complejidad era innecesaria y se pas´o a una versi´on simplificada, con dos tablas auxiliares de idioma y tipo de palabra, y una tabla principal con palabra, c´odigo de lenguaje, c´odigo de tipo, nombre del fichero y un campo m´as con el nombre del fichero no normalizado, que se mantuvo por retrocompatibilidad con TICO, aunque podr´ıa desaparecer en un futuro pr´oximo. De este modo, el tiempo de importaci´on de im´agenes se redujo muy apreciablemente (de cuatro minutos a menos de uno, para id´enticos par´ametros como tama˜no de base de datos y velocidad de la m´aquina) y el tiempo de respuesta al usuario durante el manejo normal de la aplicaci´on, tambi´en en menor medida. Para gestionar las operaciones de importaci´on, exportaci´on, agregaci´on y eliminaci´on de im´agenes, se cre´o una peque˜na aplicaci´on aparte (llamada ResourceManager) con las opciones m´ınimas y necesarias. Es bastante funcional, aunque queda pendiente para futuros PFCs ampliarla, dotarle de una interfaz mejor, mejorar la eficiencia de la operaci´on de exportar base de datos, etc. 3.11. ´ Ultimos retoques Se corrigieron diversos errores y peque˜nos fallos detectados durante pruebas, ninguno realmente grave, pero s´ı en mayor o menor medida molestos. Tambi´en se realizaron las traducciones de la interfaz al resto de idiomas (hasta ahora, s´olo estaba en espa˜nol e ingl´es) gracias a la red de colaboradores de ARASAAC. Cap´ıtulo 4 Conclusiones y trabajo futuro En este ´ultimo cap´ıtulo de la memoria se hace un balance de los resultados obtenidos y se recoge una reflexi´on sobre el cumplimiento de los objetivos inicialmente planteados para este PFC. Se detallan los principales problemas encontrados durante su desarrollo y se describen las l´ıneas de posible trabajo futuro sobre AraWord. Por ´ultimo se hace una valoraci´on personal del trabajo realizado. 4.1. Resultados obtenidos Con la finalizaci´on de este PFC se ha obtenido una primera versi´on de AraWord lo suficientemente estable para ser distribuida con garant´ıas de tener un buen funcionamiento. Los objetivos que se plantearon inicialmente se han cubierto para la mayor´ıa de usuarios de la aplicaci´on y han sido ampliados y refinados con el fin de dotarla de las funcionalidades necesarias que fueron surgiendo a lo largo del proceso de desarrollo, con algunos detalles por depurar que sirven como punto de partida para futuras ampliaciones del software. La aplicaci´on, que ha estado en permanente fase de pruebas, actualmente se est´a utilizando con los alumnos y monitores del CPEE Alborada. Asimismo los profesionales del colegio la han puesto en conocimiento de profesores y educadores de otros centros educativos espa˜noles y europeos que es posible que comiencen pr´oximamente a utilizarla. Adem´as, se ha empezado a utilizar en la radio p´ublica aragonesa (Arag´on Radio 2 1 ) para generar los titulares de las noticias adaptadas a estas personas con necesidades especiales. 4.2. Problemas encontrados En general, a lo largo del desarrollo de este PFC no ha habido demasiados problemas graves que hayan supuesto un riesgo real a la hora de cumplir plazos de proyecto, y los pocos que ha podido haber son de ´ındole humano. No obstante, algunos aspectos t´ecnicos s´ı que tuvieron una dificultad extra no prevista y merecen ser se˜nalados aqu´ı. Uno de esas tareas que result´o ser m´as costosa de lo que parec´ıa inicialmente fue probar la 1http://www.aragonradio2.com/catedu/arasaac 19 20 Conclusiones y trabajo futuro aplicaci´on en distintos sistemas operativos para garantizar que funcionaba correctamente y de la misma forma en todos ellos. La mayor´ıa de los problemas se encontraron en el sistema operativo Linux. La ejecuci´on de AraWord en este sistema provocaba una serie de fallos (mayoritariamente gr´aficos) que finalmente fueron solventados. Otra dificultad a se˜nalar durante el desarrollo de este proyecto ha sido la atenci´on permanente de las distintas sugerencias realizadas por parte de los profesores del CPEE Alborada. Esto ha favorecido enormemente la correcci´on de errores y al enriquecimiento de la aplicaci´on con las nuevas ideas que se plantean con el uso del software. Sin embargo, en muchas ocasiones, la atenci´on ´agil y el estudio de estas ideas ha requerido un esfuerzo adicional para hacerlo compatible con el trabajo ya planificado. Como dato orientativo, en la fase final de desarrollo del software se intercambiaron m´as de 140 correos electr´onicos con sugerencias, mejoras e indicaciones. 4.3. L´ıneas futuras Puede decirse que la versi´on actual de AraWord cubre casi todas las funcionalidades b´asicas necesarias para la elaboraci´on de textos con pictogramas asociados, asegurando un correcto funcionamiento. Sin embargo, como en la mayor´ıa de las aplicaciones software, se presentan una buena cantidad de posibilidades de mejora. Algunas de ellas no se han podido realizar por falta de tiempo, la mayor´ıa por exceder con creces el objetivo del proyecto siendo como es una versi´on inicial, y todas van encaminadas a dotar al programa de ciertas caracter´ısticas adicionales. Este posible trabajo futuro que surge como continuaci´on de este PFC queda resumido en los siguientes puntos: •Lectura del texto con voz sintetizada: Una funcionalidad muy interesante que no fue implementada por falta de tiempo, muy sencilla de realizar (dado que existe una librer´ıa de lectura de textos con voz sintetizada, con licencia de software libre, desarrollada por el grupo de trabajo de Eduardo Lleida, profesor del DIEC en el CPS, y que ya ha sido utilizada con ´exito en otros proyectos). •Portabilidad a dispositivos m´oviles: Debido al auge de dispositivos m´oviles cada vez m´as potentes y asequibles (y de c´odigo abierto, compatibles con Java, como Android) podr´ıa estudiarse la posibilidad de crear una versi´on ligera de este procesador de textos para dispositivos m´oviles. •Detalles pendientes de la aplicaci´on: Falta mejorar el gestor de recursos, particularmente el tiempo de la operaci´on de exportar la base de datos, as´ı como pulir del todo la opci´on Exportar a PDF, ya que la librer´ıa que se encarga de ello es bastante compleja y dif´ıcil de usar y por ello, dicha funcionalidad no est´a todo lo desarrollada que deber´ıa. 4.4. Valoraci´on personal Respecto al trabajo realizado, me siento muy satisfecho con los resultados conseguidos. Los objetivos planteados inicialmente se han cubierto y actualmente la aplicaci´on se est´a usando, que es la mejor garant´ıa de haber hecho un trabajo ´util. Esto no habr´ıa sido posible sin el