Universidad Central “Marta Abreu” de Las Villas
Facultad de Matemática-Física-Computación
Departamento de Computación
TRABAJO DE DIPLOMA
Sistema para la gestión de recursos para la herramienta TAC OmegaT
Autor: Pabel Ulacia Villavicencio
Tutor: MSc. Michel Artiles Egüe
Consultante: MSc. Manuel Llanes Abeijón
Santa Clara
2015
"Año 59 de la Revolución"
ii
El que suscribe, Pabel Ulacia Villavicencio, hago constar que el presente trabajo de diploma fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad de Ciencia de la Computación autorizando a que el mismo sea utilizado por la Institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos, ni publicados sin autorización de la Universidad.
Firma del Autor
Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.
Firma del Tutor Firma del Jefe de Departamento
donde se defiende el trabajo
Firma del Responsable de Información Científico-Técnica
i
PENSAMIENTO
“La humanidad avanza no sólo gracias a los potentes empujones de sus grandes hombres, sino también a los modestos impulsos de cada hombre responsable”
Graham Greene
ii
DEDICATORIA
A mis padres Maritza Villavicencio y Pablo Ulacia por ser los mejores padres del mundo, amigos y consejeros que siempre creyeron en mí y me ayudaron a alcanzar mis metas.
iii
AGRADECIMIENTOS
A mis padres que siempre me apoyaron en todo.
A mi hermano, mis tías, a mis abuelos, a mis primos.
A mis amigos de la universidad por apoyarnos mutuamente a lo largo de la carrera.
A mis tutores Michel y Llanes por prestarme su tiempo y dedicación.
A los profesores Yaimara Granados y Gálvez por dedicar un poco de su tiempo a supervisarme y atender mis dudas.
iv
RESUMEN
El presente trabajo da solución al problema de los especialistas en lenguas extranjeras de la Universidad Central “Marta Abreu” de las Villas de una herramienta de asistencia a la traducción con características que se adapten a sus necesidades, las que incluyen consulta de diccionarios en ambos sentidos del flujo de la traducción, ampliar la búsqueda de los diccionarios con palabras similares o relacionadas, y exportación e importación de términos de glosarios ,memorias de traducción, búsqueda de proyectos similares e importación de diccionarios. La solución consiste en un sistema que utiliza como base por parte del cliente la herramienta TAC OmegaT, se construyó una herramienta para la administración del sistema así como servicios web para la comunicación de las partes del sistema y el empleo de bibliotecas como Lucene para realizar búsquedas rápidas y precisas y Wordnet para extender las búsquedas en los diccionarios y un servidor ftp para la importación de los diccionarios. Como resultado se obtuvo un sistema que asiste a la traducción y además permite compartir los recursos desarrollados por diferentes especialistas para un uso compartido.
v
ABSTRACT
This paper provides a solution to the problem of foreign language specialists of the Central University "Marta Abreu" of Las Villas a tool to assist with the translation features that suit their needs, including consultation of dictionaries in both directions the flow of translation, expand the search for dictionaries with similar or related words, and export and import of terms of glossaries, translation memories, search for similar projects and importing dictionaries. The solution is a system using as a base by customer OmegaT CAT, a tool for system administration and web services for communication of the parties built system and the use of libraries such as Lucene for fast, accurate and searches for extending Wordnet search in dictionaries. As a result a system that assists the translation and allows sharing of resources developed by different specialists for shared use was obtained.
vi
TABLA DE CONTENIDOS PENSAMIENTO ...... i DEDICATORIA ...... ii AGRADECIMIENTOS ...... iii RESUMEN ...... iv ABSTRACT ...... v INTRODUCCIÓN ...... 1 Objetivo general ...... 3 Objetivos específicos ...... 3 Preguntas de Investigación ...... 4 Justificación de la investigación ...... 4 Capítulo 1. Tecnologías para la implementación del sistema ...... 6 1.1. La herramienta TAC OmegaT ...... 6 1.1.1. Memorias de traducción ...... 8 1.1.1.1. Memorias de traducción compartidas ...... 10 1.1.1.2. Formato común para las memorias de traducción ...... 10 1.1.1.3. Traslation Memory eXchange ...... 11 1.1.2. Glosarios ...... 11 1.1.3. Diccionarios ...... 12 1.2. Lucene ...... 12 1.2.1. Adquisición del contenido ...... 13 1.2.2. Análisis de Documents ...... 14 1.2.3. Indexación ...... 15 1.2.4. Consultas ...... 17 1.3. WordNet ...... 20 1.4. Servicios web ...... 20 1.4.1. Simple Object Access Protocol (SOAP) ...... 29 1.4.2. RESTful ...... 30 1.4.3. RESTful contra SOAP ...... 30 1.5. Conclusiones parciales ...... 33 Capítulo 2. Diseño e implementación del sistema ...... 35 2.1. Modelado del negocio ...... 35 2.2. Requisitos funcionales y no funcionales ...... 36 2.3. Casos de uso y actores ...... 38 2.3.1. Actores del sistema ...... 38 2.3.2. Casos de uso ...... 39 2.4. Arquitectura del sistema ...... 47 2.5. Principios de diseño ...... 48 2.6. Diagrama de clases ...... 49 2.7. Diagrama de Componentes ...... 56 2.8. Diagrama de despliegue ...... 57 2.9. Conclusiones parciales ...... 58 Capítulo 3. Pruebas del sistema ...... 59 3.1. Prueba de las respuestas de los servicios web ...... 59 3.1.1. Servicio compartirM ...... 59 3.1.2. Servicio compartirP ...... 60 3.2. Prueba de exportación ...... 62
vii
3.3. Prueba de importación de términos de glosarios ...... 63 3.4. Prueba de importación de diccionarios ...... 64 3.5. Pruebas de indexación de recursos ...... 64 3.6. Pruebas de eliminación de recursos ...... 65 3.7. Conclusiones parciales ...... 66 Conclusiones ...... 67 Recomendaciones ...... 67 Anexos ...... 68 Anexo 1. Características del lenguage TMX ...... 68 Anexo 2. Creación del archivo .TAB ...... 72 Anexo 3. Relaciones Semánticas en WordNet ...... 75 Referencias bibliográficas ...... 77
ÍNDICE DE IMÁGENES Ilustración 1 Arquitectura de los servicios web ...... 22 Ilustración 2 Arquitectura de WSDL 1.1 y 2.0 ...... 23 Ilustración 3 Arquitectura de UDDI ...... 25 Ilustración 4 Arquitectura de SOAP ...... 26 Ilustración 5 Casos de uso y actores ...... 38 Ilustración 6Arquitectura del Sistema ...... 48 Ilustración 7 Diagrama de clases ...... 49 Ilustración 8 Código de la preparación de las palabras para la búsqueda en diccionarios...... 51 Ilustración 9 Código de la preparación de las palabras para la búsqueda en diccionarios (continuación) ...... 52 Ilustración 10 Código del nuevo listener en la clase EditorTextArea3 ...... 52 Ilustración 11 Código de la búsqueda de memorias de traducción ...... 54 Ilustración 12 Código de la búsqueda de memorias de traducción (continuación) ...... 54 Ilustración 13 Código de la búsqueda de proyectos similares...... 55 Ilustración 14 Código de la búsqueda de proyectos similares (continuación) ...... 55 Ilustración 15 Código de la búsqueda de proyectos similares (continuación) ...... 55 Ilustración 16 Diagrama de Componentes ...... 56 Ilustración 17 Diagrama de despliegue ...... 57 Ilustración 18 Archivo compartidos.txt de los memorias de traducción compartidas ...... 59 Ilustración 19 Archivo de los proyectos compartidos ...... 60 Ilustración 20 Archivos de los términos de glosario compartidos ...... 60 Ilustración 21 Respuesta de la llamada al servicio web glosario ...... 61 Ilustración 22 Respuesta de la llamada al servicio web memoria ...... 61 Ilustración 23 Respuesta de la llamada al servicio web proyecto ...... 62 Ilustración 24 Mensaje de éxito de la aplicación cliente al exportar correctamente términos del glosario ..... 63
viii
Ilustración 25 Archivo compartidos.txt de los términos de glosario tras la exportación ...... 63 Ilustración 26 Aplicación tras la importación de nuevos términos de glosario ...... 64 Ilustración 27 Aplicación de administración tras indexar nuevos términos de glosario ...... 65 Ilustración 28 Respuesta del servicio web glosario tras las indexación de nuevos términos de glosario ...... 65 Ilustración 29 Aplicación de administración tras la eliminación del término de glosario señalado ...... 66 Ilustración 30 Configuración del archivo.TAB ...... 72 Ilustración 31 Ejemplo de configuración de un archivo .TAB ...... 72 Ilustración 32 Ejemplo de archivo .TAB con markup Pango ...... 73 Ilustración 33 Ejemplo de archivo .TAB con markup de HTML ...... 73 Ilustración 34Ejemplo de salida en una sola línea ...... 73 Ilustración 35Ejemplo de salida en varias líneas para un término ...... 73 Ilustración 36 Composición de un mensaje SOAP ...... 76
ÍNDICE DE TABLAS Tabla 1 Protocolos por capas de los servicios web ...... 23 Tabla 2 Comparación de REST y SOAP ...... 31 Tabla 3 Requisitos funcionales y no funcionales ...... 36 Tabla 4 Caso de uso: Insertar elementos al repositorio ...... 39 Tabla 5 Caso de uso: Eliminar elementos de repositorio ...... 40 Tabla 6 Caso de uso: Crear diccionarios ...... 42 Tabla 7 Caso de uso: Exportar recursos de traducción ...... 43 Tabla 8 Caso de uso: Importar recursos de traducción ...... 44 Tabla 9 Compartir recursos de traducción ...... 45 Tabla 10 Buscar recursos de traducción ...... 46 Tabla 11 Descripción del diagrama de despliegue ...... 57 Tabla 12 Ejemplos de markups ...... 74 INTRODUCCIÓN 1
INTRODUCCIÓN
El creciente desarrollo de las tecnologías de comunicaciones ha permitido que exista una cantidad inmensurable de información digital, la cual suele ser traducida en diferentes idiomas con el objetivo de su publicación y distribución en la web. El resultado de este proceso es un producto multilingüe al alcance de clientes de varios países.
Las actividades determinantes de la comunicación global multilingüe más significativas son: la elaboración de documentación técnica multilingüe (DTM), la localización de productos, la realización de campañas corporativas y publicitarias a escala mundial, la creación de diccionarios especializados y la comunicación oral. Estas actividades y las relaciones que establecen entre sí dan cuenta de su complejidad y de la necesidad de sincronizarlas.
Las exigencias y necesidades del mercado mundial se han visto cambiadas en la esfera de la Sociedad de la Información, donde se ha hecho completamente ineludible la adaptación de la capacidad técnica a las necesidades de la comunicación global, que precisa de la superación del uso del inglés como lengua franca incorporando otras lenguas determinantes en diferentes mercados a fin de eliminar las fronteras de la información.
La creciente producción de DTM no es solo producto de la necesidad de instituciones o empresas que desean estar presentes en todos los mercados mediante, por ejemplo, sitios web multilingües. En muchos casos responde a los requerimientos legislativos de grupos de mercados internacionales.
La Unión Europea, por ejemplo, exige desde hace varios años que todos los productos comercializados dentro del continente estén marcados con la etiqueta de certificación de calidad (CE) que corresponde al cumplimiento de la normativa estipulada para cada producto. Además de los requisitos de calidad impuestos, se obliga a que todos los productos que se introduzcan en un mercado europeo contengan sus especificaciones descriptivas y técnicas en el idioma del país en cuestión u otros idiomas de los países que componen la UE (MINCETUR, 2010).
Este nuevo panorama no sólo afecta a los países de la Unión Europea, sino también a otras comunidades económicas internacionales como los países integrantes del Tratado de Libre Comercio norteamericano (TLC) firmado por Estados Unidos, Canadá y México, o el del INTRODUCCIÓN 2
MERCOSUR, acordado entre los países del Cono Sur Americano (Argentina, Uruguay, Chile, Paraguay y Brasil), por citar algunos ejemplos.
Esto da como resultado que empresas e instituciones que pretenden llegar a mercados extranjeros, busquen estrategias y herramientas para la producción DTM de manera periódica. La producción de esta información se ve estrechamente relacionada con la aparición de nuevos productos por lo que el desarrollo de estas estrategias y herramientas es de vital importancia.
Como es de esperar el desarrollo de computación que va emparejado con las necesidades de los hombres permitió resolver este problema con el desarrollo de un nuevo grupo de herramientas conocidas como TAC por las siglas de Traducción Asistida por Computadoras. Las herramientas TAC ofrecen solución a la mayoría de los problemas con respecto a la traducción e interpretación, ya sea la lectura de una amplia gama de formatos de documentos, de archivos de diccionarios, la reutilización de traducciones para acelerar el proceso, estandarización de formatos, entre otros, haciéndalas casi indispensables para la producción de documentación multilingüe.
Existen muchas herramientas especializadas para la asistencia en la traducción tanto como privativas como de uso libre. En el mercado internacional resalta como las más utilizadas las herramientas de la empresa SDL International con las suites SDL Trados Studio con las versiones del 2009 y 2011. Existen otras alternativas a Trados en el mercado como son Wordfast que se ha convertido en uno de los competidores más eficaces de Trados, Transit desarrollada por STAR, Déjà Vu desarrollada por la empresa española Atril, MemoQ una de las herramientas surgidas recientemente. Existen otras pero estas son las más destacadas en el mercado (Sánchez, 2014).
Dentro del software libre existen herramientas TAC que se abren camino entre las privadas como son el caso de OmegaT que es probablemente la opción más extendida y utilizada por los traductores que buscan una alternativa gratuita a Trados; Across esta herramienta sigue una línea muy similar a Trados o MemoQ; Anaphraseus es una herramienta muy cómoda parecida a Wordfast Classic; Google Translator Toolkit a diferencia de las anteriores es online; Wordfast Anywhere, sigue la filosofía de Google Translator Toolkit, funciona online y combina funciones avanzadas de Wordfast Classic y Wordfast Pro (Sánchez, 2014). INTRODUCCIÓN 3
Los especialistas en Lenguas Extranjeras de la Universidad Central “Marta Abreu” de las Villas (UCLV), actualmente durante el proceso de traducción tienden a utilizar varios recursos computacionales como son: diccionarios generales y especializados del tema o área en la que se hace la traducción, traducciones propias o de otros especialistas de artículos sobre el mismo tema o área y otras informaciones disponibles en la red que apoyan su trabajo. Este uso simultáneo de múltiples fuentes de información hace su trabajo engorroso, consume recursos de forma ineficiente y sobrecargan el sistema operativo con múltiples ventanas y aplicaciones abiertas simultáneamente, además puede atrasar un trabajo la indisponibilidad de un medio como puede ser un diccionario especializado, o de una traducción como referencia.
Objetivo general
Incorporar nuevas funcionalidades a la herramienta TAC OmegaT integrando varios recursos computacionales que tributen a la asistencia de los profesionales de la carrera de Lengua Inglesa en la Universidad Central “Marta Abreu” de las Villas durante el proceso de traducción de documentos de diferentes idiomas.
Objetivos específicos
1. Crear diccionarios con la información recopilada por los especialistas de lengua inglesa para que sean usados por el software. 2. Implementar servicios web que permitan al software OmegaT realizar búsquedas de documentos traducidos que sean similares al que se está traduciendo, memorias de traducción y términos de glosarios con idiomas origen y destino iguales al del proyecto en traducción. 3. Desarrollar una aplicación desktop que permita controlar (agregar, eliminar) los recursos que conformarán el repositorio a utilizar por los servicios web. 4. Modificar la aplicación OmegaT para permitir la exportación e importación de sus recursos así como la consulta personalizada de diccionarios. INTRODUCCIÓN 4
Preguntas de Investigación
1. ¿Qué herramienta puede ser utilizada para la creación de los diccionarios a partir de la información recopilada por los especialistas, la integración con un software de implementado en JAVA? 2. ¿Qué herramientas se pueden utilizar para la implementación de las búsquedas de contenido similar al que se está traduciendo, así como para la consulta personalizada de diccionarios teniendo en cuenta las particularidades de OmegaT? 3. ¿Qué estándar de servicio web (SOAP o RESTful) será más factible utilizar para la implementación de las soluciones, partiendo de las características propias de OmegaT y los objetivos propuestos?
Justificación de la investigación
Las herramientas TAC están muy difundidas en el mundo de creación de documentación multilingüe, la mayoría de las herramientas son privativas y sus licencias de utilización son caras. Existen herramientas TAC gratis y de código abierto entre las que se encuentra OmegaT, cuyas bondades están abaladas por especialistas de la materia ya que incorpora la mayoría de las características que deben tener este tipo de herramienta. Por otra parte al personalizar y adaptar OmegaT a las necesidades de los especialistas de Lengua Inglesa de la UCLV añadiéndole nuevas funcionalidades permite entre otras cosas aumentar la eficiencia de los traductores que utilicen el software. Además esta adaptación de OmegaT enfocada a necesidades puntuales de especialistas de la UCLV, permite una mayor competitividad a los mismos, les ahorraría considerables sumas de dinero. Sin contar que constituye un paso más de avance para la informatización e independencia tecnológica de la UCLV.
Como consecuencia el proyecto está compuesto por cuatro capítulos; el primer capítulo describe los principales recursos utilizados por OmegaT, explica las ventajas y desventajas de la utilización de las memorias de traducción en el trabajo de los traductores, así como las ventajas del uso compartido de las memorias de traducción y, describe el lenguaje TMX como lenguaje estándar para las memorias de traducción, además se tratan los recursos glosarios, tanto los formatos utilizados, como su creación; y diccionarios. INTRODUCCIÓN 5
En el segundo capítulo se realiza un estudio de las posibles herramientas a utilizar para el desarrollo del sistema, entre las cuales destaca Lucene como herramienta de búsqueda e indexado, realizando una descripción de cada proceso junto las ventajas que permite, se realizan comparaciones de dos posibles arquitecturas de servicios web, así como de dos posibles servidores web para soportarlas.
En el tercer capítulo se propone una implementación del sistema, se define los requisitos funcionales y no funcionales del sistema, los actores y casos de uso del sistema y muestra la arquitectura del sistema en función de los mismos mediante los diagramas de clase, componentes y flujo.
En el cuarto capítulo se describen un grupo de pruebas realizadas al sistema con el fin de comprobar su correcto funcionamiento.
CAPÍTULO 1. Tecnologías para la implementación del sistema 6
Capítulo 1. Tecnologías para la implementación del sistema
Con el fin de dar solución a la problemática del proyecto es necesario la utilización de un conjunto de tecnologías útiles para el desarrollo del sistema como: herramienta TAC, búsquedas e indexación de texto, creación de servicios web, ftp y su despliegue; para ello en el capítulo se realiza un análisis de opciones de estas tecnologías, comparación de las mismas, y elección de las más favorables para el sistema a implementar. Por lo tanto, se exponen las características principales de OmegaT, se realiza un análisis de la biblioteca Lucene explicando en un orden lógico los pasos necesarios para la indexación y búsqueda, se realiza un análisis de las tecnologías SOAP y RESTful en cuanto a la ventajas e implementación de cada uno así como una comparación de las dos, en adelante se analizan los servidores web Glassfish y Tomcat, se detallan cada una de sus características y sus componentes, y se realiza una comparación entre los dos, luego se realiza una descripción del servidor ftp Svftpd de Linux y al final se exponen las tecnologías elegidas en cada parte del sistema.
1.1. La herramienta TAC OmegaT
OmegaT es una aplicación libre de memoria de traducción escrita en Java, se puede instalar en Windows, Mac y varias versiones de Linux. Entre sus principales ventajas se encuentra la compatibilidad con diferentes formatos de archivo de texto más empleados como: HTML, XML, XLIFF (XML Localization Interchange File Format), DOCX, texto ASCII (*.txt), texto codificado (*.UTF8), paquetes de recursos Java (*.properties), etc (Anica, 2014).
Cuenta con un poderoso motor de memorias de traducción, siendo el componente más importante de aplicación, cada vez que se entra a un nuevo segmento de la traducción busca y muestra memorias de traducciones exactas o aproximadas a la que se traduce. Dado a su compatibilidad con TMX (Translation Memory Exchange), el estándar de memorias de traducción, puede trabajar con memorias de traducción realizadas con otras aplicaciones y crear nuevas que a su vez puede ser utilizada por aplicaciones similares o de gestión de memorias de traducción (Flórez and Alcina, 2011).
Dentro de los atractivos de OmegaT cabe destacar la gestión terminológica, utiliza glosarios que contiene frases o palabras sueltas con su traducción y comentarios que hacen función de un pequeño diccionario, si existen coincidencias de alguno de estos términos, aparecerán en CAPÍTULO 1. Tecnologías para la implementación del sistema 7 la sección del glosario, además de los glosarios también utiliza diccionarios que pueden ser generales u ortográficos, para búsquedas más especializadas, las que realiza de manera automática para los segmentos del texto origen, mostrándose en el área de diccionarios.
OmegaT presenta muchas características que lo hacen peculiarmente cómodo para el aprendizaje rápido de su uso, pero además es muy útil a la hora de trabajar con idiomas tanto de derecha a izquierda como de derecha a izquierda, sin contar que posee diversos filtros que permiten realizar la segmentación de los textos en dependencia al lenguaje origen.
Diferente a otras herramientas TAC clásicas como WordfastClassic o las versiones de SDLTrados previas a Trados Studio, OmegaT no precisa del procesador de texto Microsoft Word, por el contrario crea un proyecto de traducción al que se le importan los documentos a traducir, así como los diccionarios y glosario.
Los proyectos de traducción están contenidos en un directorio con el nombre del proyecto, dentro se pueden encontrar seis subdirectorios, también pueden estar distribuidos fuera del directorio del proyecto, además de cuatro archivos:
Dictionary: Es el subdirectorio donde se almacenarán los diccionarios; cualquier diccionario que esté fuera de este directorio no será reconocido como tal. Glossary: Es el subdirectorio que contiene los glosarios del proyecto; cualquier archivo con formato de glosario mientras esté en esta carpeta será reconocido como tal, pero el glosario principal, será glossary este es el creado a partir de la aplicación. Omegat: Es el subdirectorio más importante contiene archivos que tienen información única del proyecto: o Project_save.tmx: existe al menos uno contiene las memorias de traducción con que trabaja la aplicación, por lo que es el más importante. o Project_save.tmx.
o Files_order: Contiene el orden en que se fueron agregando los documentos a traducir y este se mantiene. o Last_entry.properties: Contiene la información del último segmento en que trabajo, el proyecto al abrirse nuevamente comienza en este segmento. Source: Es el subdirectorio donde se almacenarán los archivos a traducir. Target: Es el subdirectorio donde se crearán los archivos ya traducidos con el mismo formato de los archivos a traducir. Tm: Este directorio puede contener cualquier número de memorias de traducción auxiliares es decir, archivos TMX. El contenido de las memorias de traducción en el subdirectorio tm sirve para generar sugerencias para el texto a traducir. Cualquier texto, ya traducido y almacenado en estos archivos, aparece entre las coincidencias parciales, si es lo suficientemente similar al texto que se está traduciendo. Omegat.project: Es el archivo que contiene la información de todos los subdirectorios del proyecto.
1.1.1. Memorias de traducción
Las memorias de traducción son almacenes compuesto por textos originales de una lengua origen alineados con su traducción en una o varias lenguas destino. Es básicamente un tipo especial de base datos.(PAULINE CASTIAU, Guohua, 2009, Odriozola et al., 1997).
Están alineados por unidades de traducción o segmentos. Las unidades de traducción que se almacenan junto con sus equivalentes se definen de forma variable siendo la segmentación tras un signo de puntuación que marca el final de la frase (., ?, !, :, ...) o un salto de párrafo las más frecuentes ofrecidas por defecto en el entorno de los sistemas de traducción asistida. CAPÍTULO 1. Tecnologías para la implementación del sistema 9
Una memoria de traducción (MT) es una base de datos lingüística que les permite a los traductores reutilizar traducciones ya existentes. Son herramientas de almacenamiento y acumulación de información que están en constante crecimiento. Le permiten al traductor identificar unidades de traducción (por lo general frases enteras) que ya han sido traducidas anteriormente para luego reutilizarlas, de manera que una misma frase nunca se traduce dos veces. (Gutiérrez, PAULINE CASTIAU, 2011)
La principal función de las MT es extraer sugerencias totales y parciales de una frase y concordancias para términos. A lo largo de la traducción, se buscan en la base de datos de las MT segmentos que coincidan al 100% y se muestran en la ventana de las MT. Las coincidencias parciales o segmento no exacto son llamados fuzzy match también son incluidos en la ventana de las MT, el grado de similitud puede es adaptable en todos los sistemas de MT.
El contenido de estos recursos lingüísticos paralelos es fundamental, pero también es crucial el motor de búsqueda que permite explorar una gran cantidad de texto e identificar patrones lingüísticos y terminológicos comunes. Por tanto, si el contenido de las memorias y si su sistema de indización ofrece buenos resultados, estas memorias se convierten en el mejor instrumento de trabajo del mediador lingüístico.
El almacén de MT va creciendo en función del volumen y frecuencia de alimentación de las memorias de traducción, las que se crean a medida que se valida la traducción de un segmento del texto a traducir en un entorno de traducción asistida. Otra de las técnicas utilizadas para generación de MT es la alineación de textos con sus traducciones, esta se lleva a cabo con herramientas conocidas como alineadores.
El uso de memorias de traducción es más útil en textos repetitivos como manuales técnicos o documentos con vocabulario especializado. También son útiles para hacer traducciones incrementales de documentos traducidos anteriormente. Si un traductor de memoria se usa de forma consistente durante un cierto tiempo puede ahorrar un trabajo considerable a los traductores. CAPÍTULO 1. Tecnologías para la implementación del sistema 10
1.1.1.1. Memorias de traducción compartidas
Una de las ventajas de las MT es la posibilidad de reutilización de las mismas por otros sistemas o usuarios por lo que no es de extrañar la existencia de usuarios que sistemas destinados a guardar MT de varios usuarios con el fin de compartir la información, como por ejemplo la Nube en Internet.
Las memorias pueden compartirse desde un archivo centralizado de memorias gestionado por uno de los proveedores del cliente. Cuando el proveedor 1 recibe un trabajo de traducción deberá descargar toda la memoria. Deberá realizar las labores de preprocesado necesarias y analizar el trabajo con la memoria que ha descargado. Cuando el proveedor 2 recibe un encargo de traducción, repite esta misma operación. Al finalizar los trabajos, es preciso incluir las unidades de memoria nuevas o cambiadas en la memoria principal. Esta tarea será responsabilidad exclusiva de uno de los proveedores en calidad de custodio de la memoria, o, si dispone de los recursos adecuados, del cliente. (Abaitua, 2001)
La principal ventaja del uso compartido de memorias de traducción es que permite a profesionales de la traducción especialistas en determinadas áreas tener acceso a información traducida de otras áreas. A pesar de ello herramientas como Trados y OmegaT están ideadas para el uso diario del traductor profesional y no para facilitar al usuario este tipo de práctica.
1.1.1.2. Formato común para las memorias de traducción
En la última década del siglo XX se fue expandiendo la idea de que la traducción automática no iba ser la herramienta definitiva para la comunicación entre todos los idiomas debido a obstáculos infranqueables del lenguaje natural para el procesamiento automático. Producto a ello comienzan a seguirse las investigaciones más avanzadas del tema en el momento en distintos campos, como la idea de TAC dando paso a la idea de las MT.
La gran cantidad de herramientas de MT dejó al descubierto el problema de la incompatibilidad de las MT en diferentes software por lo que si se comenzaba en uno no se podía cambiar a otro sin tener que comenzar desde cero. De la necesidad creciente de un método de intercambio de MT entre las diferentes aplicaciones surge TMX; producto del consorcio Lisa en 1998. CAPÍTULO 1. Tecnologías para la implementación del sistema 11
1.1.1.3. Traslation Memory eXchange
TMX (Gómez, 2001) es un lenguaje que cumple las especificaciones XML, cuyo propósito es proporcionar un estándar para el intercambio de TM. El único requerimiento es que la aplicación soporte este lenguaje, una vez exportada este lenguaje desde una aplicación puede ser importada por otra y utilizada. La mayoría de las aplicaciones más importantes del mercado admiten la importación y exportación de memorias TMX en distintos grados. Quizás gracias a sus disimiles características, ver Anexo 1.
1.1.2. Glosarios
La palabra proviene del latín glossarium, es un catálogo de palabras de una misma disciplina o de un campo de estudio que aparecen definidas, explicadas y comentadas. También se trata de un catálogo de palabras desusadas o del conjunto de comentarios y glosas sobre los textos de un autor. El término se utiliza para hacer referencia a un conjunto de breves anotaciones explicando la definición de palabras o frases. La mayoría de libros que tienen contenido específico como científico o religioso, poseen glosarios al final del mismo. Son similares a los diccionarios, la diferencia se encuentra en la cantidad de palabras o términos que soporta cada uno, mientras que los diccionarios son creados para almacenar un gran número de términos, los glosarios solo almacenan un pequeño número(Young, 1988).
En OmegaT un glosario puede ser definido desde un archivo con extensión txt, cada línea debe contener un trío con el formato, [palabra/frase] [TAB] [equivalente] [TAB] [comentarios (opcional)], en el caso de no escribir comentarios no es necesario el segundo TAB.
OmegaT es compatible con el formato CSV, en este caso la separación de los elementos del trío sería con comas y no con TAB, además los elementos deben encerrarse entre comillas dobles.
El archivo se puede codificar por medio del sistema de archivo predeterminado (se indica mediante la extensión .tab) o en UTF-8 (con la extensión .utf8). CAPÍTULO 1. Tecnologías para la implementación del sistema 12
Si bien los glosarios se pueden definir con cualquiera de los formatos y codificaciones, es preferible utilizar el primer formato puesto a que la tabulación separa muy bien visualmente los elementos del trío y la codificación Unicode (UTF-8).
Además de texto sin formato, OmegaT también es compatible con el formato TBX (Term Base eXchange), un estándar libre basado en XML para el intercambio estructurado de datos terminológicos que ha sido aprobado como un estándar internacional por LISA e ISO.
1.1.3. Diccionarios
Los diccionarios utilizados por OmegaT deben ser compatibles con la plataforma StarDict, una herramienta para la lectura de diccionarios disponible para múltiples plataformas como Windows, Linus, DSD y Mac.
La plataforma StarDict proporciona una gran variedad de herraminetas en su juego de herraminetas StarDict-Tools las que poseen un conjunto de utilidades para manipular diccionarios de StarDict y convertir de otros formatos de diccionarios electrónicos al formato de StarDict(Popov, 2006, Ding et al., 2011, Lertsuksakda et al., 2014).
Cada diccionario StarDict es creado a partir de un archivo .TAB (Anexo 2) que contiene la información del diccionario; este se puede obtener de tres formas diferentes:
Creando el archivo TAB desde cero. Convirtiendo un diccionario existente de StarDict de su archivo binario DICT a .TAB. Convirtiendo un diccionario existente de otro formato (dictd, Lingvo, MOVA, Babylon o DSL) a los archivos binarios de StarDict y luego estos convertirlos a .TAB.
1.2. Lucene
Lucene es una biblioteca de Recuperación de Información (RI) de gran rendimiento y escalable que añade a una aplicación la capacidad de búsqueda y RI. Es un proyecto maduro, libre y de código abierto implementado en Java como proyecto de la fundación de software Apache y bajo la licencia de la misma. En los últimos años ha alcanzado gran popularidad, convirtiéndose en la biblioteca de RI más difundida, empleándose tanto en aplicaciones web como aplicaciones de escritorio. Debido a este alcance puede encontrarse integrada mediante CAPÍTULO 1. Tecnologías para la implementación del sistema 13 puertos a otros lenguajes además de Java como son: C/C++, C#, Perl, Ruby, Phyton, PHP, etc (Liang et al., 2015, Entrup, 2015).
Dada su gran sencillez no son necesarios profundos conocimientos sobre cómo Lucene indexa la información a la hora de la utilización pero al menos es necesario conocer los pasos que realiza cualquier sistema de RI a la hora de realizar el proceso de indexación, búsqueda y recuperación de la información. Sin tener en cuenta las particularidades de la interfaz del usuario o cualquier otro componente que pueda estar en el software a desarrollar, se pueden definir 7 etapas en todo el proceso: Adquisición del Contenido, Creación del objeto Document, Indexación del objeto Document, Construcción de la Consulta, Ejecución de la Consulta y Obtención de los Resultados; de estas la primera no es realizada por Lucene.
1.2.1. Adquisición del contenido
La adquisición del contenido es el primer paso en el proceso de indexación de la información, es a menudo realizado por crawler (rastreador) o spider, sin los cuales el proceso sería complicado, engorroso y desordenado.
Por lo general se desea adquirir información contenida en ficheros que pueden estar en un directorio específico en el sistema de ficheros, base de datos, en una red local, en la web o pequeñas partes de cada uno dispersa en todos estos sitios. Para tener acceso a algunos de estos lugares es necesario tener privilegios especiales de administración, además es necesario adquirir documentos a los que se le realizan cambios, o se añaden en cuanto estén disponibles.
Lucene como biblioteca de búsqueda no posee esta funcionalidad, por lo que debe implementarse en una parte diferente de la aplicación o por separado. Para esto existen diferentes crawler con código abierto:
Nutch: Es un crawler Web de código abierto escrito en Java, está basado en Lucene y a su vez es parte del proyecto Lucene de la Apache Software Foundation. Mediante su uso se pueden encontrar hipervínculos de páginas web de forma automatizada, reduciendo el trabajo de mantenimiento. Guarda una copia de las páginas visitadas para visitar otras, esta copia es utilizada por otras herramientas. (Wu, 2015, Frampton, 2015, Mcgibbney, 2015). CAPÍTULO 1. Tecnologías para la implementación del sistema 14
Heritrix: Heritrix es un crawler de ficheros web a través de internet. Su licencia es de código abierto y está escrito completamente en JAVA. Su interfaz de configuración es accesible usando un navegador web, haciéndolo muy versátil y cómodo de usar, aunque también puede ser lanzando desde línea de comandos. Heritrix fue desarrollado conjuntamente por "Internet Archive" y "Nordic National Libraries" a principios de 2003. La primera versión fue publicada en enero de 2004 y ha sido continuamente actualizado por los miembros de "Internet Archive" y terceras partes (Erik Hatcher, 2009, Mohr et al., 2004, Guohua, 2009).
Apache Droids: Es un proyecto de la Apache Software Fundation, que se dedica a la creación de un framework para la definición de web crawlers. Estos robots para la búsqueda de información en línea se construyen por medio de elementos genéricos tales como(Tittle, 2011, Jackson, 2012): 1. Colas. 2. Protocolos. 3. Analizadores sintácticos (Apache Tika). 4. Handlers. Aperture: (http://aperture.sourceforce.net): Aperture es un framework de Java para la extracción y consulta de contenido de texto completo y metadatos de los diversos sistemas de información como: sistemas de archivos, sitios web, buzones de correo; y formatos de archivos como documentos e imágenes que utilizan estos sistemas(Erik Hatcher, 2009).
Si la aplicación se encargará de buscar información dispersa es natural utilizar alguno de los crawlers existentes, pero si la información a buscar se encuentra en un solo lugar es muy fácil crear tu propio crawlers.(Erik Hatcher, 2009)
1.2.2. Análisis de Documentos
Antes de la indexación el texto es dividido en unidades menores llamadas tokens. Cada token corresponde a una palabra del lenguaje natural, esta tiene que tener un significado con un peso, o sea: artículos, conjunciones, preposiciones, pronombres, etc; no se añaden como tokens, estas palabras sin significado son llamadas stop words. En este paso se decide que token utilizar en la indexación. Puede parecer simple pero no lo es, en muchos casos hay CAPÍTULO 1. Tecnologías para la implementación del sistema 15 palabras compuestas o derivadas de otras, hay palabras en plural y singular, palabras que pueden tener errores ortográficos; cuando suceden estas cosas aparecen muchas preguntas de cómo se debe dividirse el texto, que token utilizar, mantener la independencia en algunos o llevarlos a un punto en común.
Lucene provee analizadores que permitirá tener un fino control sobre el proceso. Es muy fácil crear un analizador propio o combinar los tokenizadores de Lucene y los filtros de tokens para personalizar la creación de las fichas(D. Vadim Paz Madrid Gorelow, 2007). Para ello cuenta con varios analizadores léxicos que dan características diferentes a los campos:
ANALIZED: divide el valor del campo en diferentes tokens, para ello es posible utilizar cuatro de sus opciones: 1. WhitespaceAnalyzer: Separa el valor del campo en diferentes tokens antes de guardarlo. 2. SimpleAnalyzer: Separa el valor del campo en diferentes tokens además separa las cadenas con caracteres especiales (@, -, &, etc) en tokens y elimina los caracteres especiales antes de guardarlo. 3. StopAnalyzer: Realiza las funciones de los dos anteriores pero además elimina las llamadas stopwords (artículos, conjunciones, preposiciones, etc) antes de guardar el valor del campo. 4. StandarAnalyzer: Es el analizador más avanzado realiza las funciones de los tres anteriores pero detecta cuando se encuentra frente a nombres de compañías, correos electrónicos, páginas web, etc y los mantiene como un solo token. NOT_ANALIZED: A diferencia de ANALYZER toma el valor de la cadena como un solo token. TOKENIZER: Divide el valor de la cadena en diferentes tokens. NOT_TOKENIZER: Toma el valor de la cadena como un solo token.
1.2.3. Indexación
En la indexación los Documents son añadidos a un índice que tiene como base estructuras de datos que permiten el rápido acceso a la información contenida por ellas. Como ya se mencionó anteriormente no es necesario tener conocimientos profundos de cómo se crean, CAPÍTULO 1. Tecnologías para la implementación del sistema 16 pero hay que tener presente que existen dos tipos fundamentales de índices: Índice invertido y Patricia Tree (PAT).
Los índices invertidos son conjunto de documents, donde a cada documento es asignada una lista de palabras claves o atributos, con un peso de relevancia que se le asocia opcionalmente a cada palabra clave (atributo). Un fichero invertido es una lista ordenada (o índice) de palabras claves (atributos), donde cada palabra clave tiene enlaces a los documents que contienen esa palabra clave.
Construir y mantener un índice invertido es relativamente barato. En principio, puede construirse un índice invertido para un texto de n caracteres en un tiempo O(n). El mayor problema que se presenta en la práctica a la hora de construir un índice invertido es que la RAM se termine antes de poder procesar todo el texto. En este caso, cada vez que la RAM se agota, se graba en disco un índice parcial y se libera la memoria. Al final, se realiza una merge de los índices parciales. La mezcla consiste en combinar los vocabularios ordenados. Si aparece el mismo término en ambos índices se mezclan sus listas de ocurrencias. Esta mezcla no requiere demasiada memoria (se trata de un proceso secuencial) y resulta relativamente rápido en I/O. Este método se adapta fácilmente para actualizar el índice.
Los ficheros invertidos utilizan pueden utilizar como estructuras de datos:
Arreglos ordenados. Árboles (B-trees, tries). Tablas Hash. Combinación de las tres.
Las principales ventajas:
Son utilizados por la mayoría de los sistemas de bibliotecas comerciales. El uso de los ficheros invertidos mejora la eficiencia de la búsqueda por varios órdenes de magnitud (una necesidad para ficheros de textos muy grandes).
Las principales desventajas:
La penalidad por la eficiencia es la necesidad de almacenar una estructura de datos que consume del 10% al 100% o más del tamaño del texto en sí. CAPÍTULO 1. Tecnologías para la implementación del sistema 17
Es necesario actualizar el índice cuando el conjunto de datos cambia.
Restricciones de estos índices:
Un vocabulario controlado correspondiente a la colección de palabras claves que serán indexadas. Palabras en el texto que no estén en el vocabulario no serán indexadas, y por tanto no serán buscadas.
Una lista de palabras gramaticales (stopwords) que por razones de volumen o precisión, no serán incluidas en el índice, y por tanto no serán buscadas.
Un conjunto de reglas que decide el comienzo de una palabra o parte de un texto que es indexable. Estas reglas están relacionadas con el tratamiento de espacios, marcas de puntuación o algunos prefijos estándares, y pueden tener un impacto significativo en qué términos son indexados.
Una lista de secuencia de caracteres a ser indexadas (o no indexadas). En grandes bases de datos textuales, no todas las secuencias de caracteres son indexadas.
Lucene utiliza un índice invertido y provee todo lo necesario para la realización de esta operación a través de una API sorprendentemente simple. Debe entenderse que hacer un índice es indispensable antes de realizar cualquier búsqueda.
1.2.4. Consultas
La búsqueda es el proceso de mirar palabras en el índice para encontrar documents y una vez diseñado un sistema para resolver consultas sobre una colección de datos es necesario establecer parámetros para la evaluación del sistema con determinadas consultas. Esto es útil para las consultas ranqueadas donde la posición del resultado es fundamental en la calidad del resultado de la búsqueda.
Existen ciertos parámetros y técnicas estandarizadas para evaluar la eficiencia de un sistema de búsqueda como son: precisión y recall. La precisión se define como la cantidad de documentos relevantes recuperados sobre el total de documentos recuperados.(Saubiedet). El recall se define como la cantidad de documentos relevantes recuperados sobre el total de documentos relevantes.(Saubiedet). CAPÍTULO 1. Tecnologías para la implementación del sistema 18
Otro método muy utilizado consiste en medir la precisión para un cierto número de documentos recuperados fijo, este método es muy usado en buscadores web midiendo por ejemplo la precisión para los primeros “n” resultados. A este método se lo llama precisión fija.(Saubiedet)
Para la búsqueda se deben considerar varios factores, ya se la velocidad, el procesamiento de textos largos, que se había tenido en cuenta a la hora de crear el índice; pero existe otros factores como son: el soporte para una o varias consultas, consultas de frases, comodines, consultas borrosas, etc.
El primer paso hacia la búsqueda es la construcción de la consulta. Este paso consiste en convertir la cadena que el usuario pasa por la interfaz en una consulta (Query), para esto Lucene posee un poderoso paquete llamado QueryParse, el resultado de esta conversión es un objeto de la clase Query.
La creación de los objetos Query puede ser muy fácil o muy difícil, esto es producto a la complejidad de la consulta; podemos encontrarnos consultas con operadores booleanos, consultas de frases, consultas con comodines, etc. Si la aplicación tiene restricciones por usuarios o sea no todos los usuarios tienen privilegios sobre la misma cantidad de archivos entonces es necesario realizar un filtro a la consulta.
A menudo el paquete por defecto de Lucene es suficiente para crear una Query, pero puede utilizar el QueryParse y añadirle una nueva lógica para refinar el objeto de consulta, esto lleva la consulta más lejos. En muchas ocasiones el usuario necesita que algunos resultados resalten más que otros por cual es necesario modificar la consulta para resaltar los resultados, esto también puede hacerse en el proceso de indexación, pero no está de más hacerlo aquí por dos razones: en el proceso de indexación pudo no realizarse esta acción, las consultas pueden variar y lo que para algunos representaba los resultados más importantes para otros no lo son.
Lucene presenta varias formas de consultas, todas con un alcance diferente y entre las cuales están:
TermQuery: Similar a QueryParse pero se utiliza principalmente para campos con valores específicos que se pueden tomar como identificadores. CAPÍTULO 1. Tecnologías para la implementación del sistema 19
BooleanQuery: Es una consulta muy útil permite unificar los resultados de distintos tipos de consultas en una sola, aprovechando esta posibilidad se puede agregar varias restricciones a una búsqueda. MoreLikeThis: Compara los vectores de los documents de consultas anteriores para buscar coincidencias de vectores similares.
Lucene puede expandir sus consultas utilizando el su biblioteca lucene-wordnet en la que puede utilizar la función expand de la clase SynExpand.
Lucene utiliza un modelo de representación de los objetos denominado “Modelo de espacio vectorial” el cual permite entre otras cosas que los documentos se ordenen según el grado de similitud, teniendo en cuenta también los documentos que parcialmente emparejan con la consulta.
Los documentos dj y la consulta se representan como vectores t-dimensionales, siendo t el número de términos diferentes en el conjunto de documentos. El modelo vectorial propone evaluar el grado de similitud entre el documento dj y la consulta q como la correlación entre sus vectores. Esta correlación puede ser cuantificada, por ejemplo, como el coseno del ángulo entre los dos vectores, este es uno de los más utilizados.
El modelo vectorial tiene una desventaja, por lo menos teóricamente, al asumir que los términos índice son independientes, aunque en la práctica el asumir esta dependencia puede ser una desventaja. Debido a la localidad de muchas dependencias entre términos, su aplicación indiscriminada a todos los documentos de la colección puede repercutir negativamente en el performance total. Sin embargo, aún con su simplicidad y defectos es considerado mejor o tan bueno como alternativas más sofisticadas haciéndolo el modelo más popular de RI y Lucene lo utiliza para la representación de los documentos y sus tokens lingüísticos.
Algunos modelos alternativos de recuperación de información son:
Booleano y sus extensiones: Booleano Extendido, Conjuntos Difusos. Extensiones al modelo Vectorial: Vectorial generalizado, LSI (Latent Semantic Indexing), Redes neuronales. Probabilístico y sus extensiones: Redes Bayesianas, Redes de Inferencia Bayesiana. CAPÍTULO 1. Tecnologías para la implementación del sistema 20
2.1.7 Obtención de los resultados
Una vez obtenida una lista ordenada provisional de documentos que coinciden con la consulta es una buena política mostrar los resultados al usuarios de una forma lo más natural posible, brindándole posibilidades de seguimiento como hacer clic a la siguiente página, refinado de la búsqueda, la búsqueda de documentos similares a alguno de los obtenidos; la idea es no permitir que el usuario se encuentre con callejón sin salida.
El núcleo de Lucene no ofrece componentes para presentar plenamente los resultados, pero la Sandbox contiene el highlighter (resaltador) package, para la producción de resúmenes dinámicos y resaltado exitoso.
1.3. WordNet
Wordnet es una base de datos léxica del idioma inglés. Agrupa palabras en inglés en conjuntos de sinónimos llamados synsets, proporcionando definiciones cortas y generales, almacena las relaciones semánticas entre los conjuntos de sinónimos. Su propósito es doble: producir una combinación de diccionario cuyo uso sea más intuitivo, y soportar el análisis automático de texto y a aplicaciones de inteligencia artificial(Miller et al., 1990, Miller, 1995, Fellbaum, 1998). La mayoría de los synsets están conectados a otros synsets mediante numerosas relaciones semánticas, estas varían basándose en el tipo de palabra, ver Anexo 3. Las bases de datos y las licencias del software se han liberado bajo una licencia BSD y pueden ser descargadas y usadas libremente.
1.4. Servicios web
Actualmente en el desarrollo de software existe la tendencia de un diseño modular. Las aplicaciones con este diseño se componen de una serie de componentes reutilizables que se pueden encontrar distribuidos por toda la red. La principal ventaja de un diseño de este tipo es que el mantenimiento y expansión de una aplicación es mucho más simple que si la aplicación fuese centralizada, además que las afectaciones a los usuarios que utilizan la aplicación serían solo para aquellos que utilicen este módulo. CAPÍTULO 1. Tecnologías para la implementación del sistema 21
Uno de estos componentes con que puede contar una aplicación es el Servicio Web. Un Servicio Web es un componente al que podemos acceder mediante protocolos Web estándar, utilizando XML para el intercambio de información.
Los Servicios Web pueden ser referidos como una colección de procedimientos a los que se pueden llamar desde cualquier lugar de la red, la principal ventaja de su utilización es que pueden llamarse independientemente del lenguaje en que se desarrolle el servicio internamente o la plataforma y lenguaje en la aplicación debido a que los vendedores han admitido estándares comunes de Servicios Web.
El W3C (World Wide Web Consortium) define un Servicio Web como un sistema software diseñado para soportar interacciones máquina a máquina a través de la red. Dicho de otro modo, los servicios Web proporcionan una forma estándar de interoperar entre aplicaciones software que se ejecutan en diferentes plataformas. Por lo tanto, su principal característica su gran interoperabilidad y extensibilidad así como por proporcionar información fácilmente procesable por las máquinas gracias al uso de XML.
Características de un componente como Servicio Web:
Implementa los métodos de una interfaz descrita mediante un WSDL. Estos se implementan utilizando un EJB de sesión de tipo Stateless/Singleton o bien un componente web JAX-WS. Puede tener publicada su interfaz en uno o más registros durante su despliegue. La implementación de un Servicio Web utiliza solamente la funcionalidad descrita por su especificación, puede desplegarse en cualquier servidor de aplicaciones que cumple con las especificaciones Java EE. Los servicios requeridos en tiempo de ejecución (run-time), tales como atributos de seguridad, se separan de la implementación del servicio, para ello se utilizarán herramientas que definen estos requerimientos en el ensamblado o despliegue. Un contenedor que actúa como mediador para acceder al servicio. CAPÍTULO 1. Tecnologías para la implementación del sistema 22
La especificación de Java EE para servicios Web define una serie de relaciones arquitectónicas requeridas para dichos servicios. Se trata de relaciones lógicas que no imponen requerimiento para el proveedor del contenedor sobre como estructurar los contenedores y los procesos. Como añadido para la plataforma Java EE se incluye un componente port que depende de la funcionalidad de contenedor proporcionada por los contenedores web y EJB, y del transporte SOAP/HTTP.
Ilustración 1 Arquitectura de los servicios web
Los Servicios Web para Java EE requieren un componente Port que pueda ser referido desde el cliente, así como desde los contenedores Web y EJB. No se requiere que haya un port accesible desde un contenedor applets.
Los Servicios para Java EE pueden implementarse de dos formas:
Como una clase Java que se ejecuta en un contenedor Web. Como un EJB de sesión Stateless o Singleton en un contenedor EJB.
Acompañados de estas características existen una serie de protocolos organizados por capas. CAPÍTULO 1. Tecnologías para la implementación del sistema 23
Tabla 1 Protocolos por capas de los servicios web
Capa Descripción
Transporte de Servicios Se encarga de transportar los mensajes entre aplicaciones. Normalmente se utiliza el protocolo HTTP, aunque los Servicios Web pueden viajar utilizando protocolos de transferencia de hipertexto como: SMTP, FTP o BEEP.
Mensajería XML Se encarga de codificar los mensajes en XML de forma que puedan ser entendidos por cualquier aplicación. Puede implementar protocolos XML-RPC o SOAP.
Descripción de servicios Se encarga de definir la interfaz pública de un determinado servicio, para ello utiliza WSDL.
Localización de Servicios Se encarga del registro centralizado de servicios, permitiendo que estos sean anunciados y localizados, para ello utiliza el protocolo UDDI.
WSDL (Web Services Description Language o Lenguaje de Descripción de Servicios Web) es un lenguaje basado en XML utilizado para describir la funcionalidad que proporciona un Servicio Web. Proporciona un descripción entendible por la máquina (machine readable) de la interfaz del Servicio Web, indicando cómo se debe llamar el servicio, que parámetros espera, y que estructuras de datos devuelve.
Ilustración 2 Arquitectura de WSDL 1.1 y 2.0 CAPÍTULO 1. Tecnologías para la implementación del sistema 24
WSDL describe un servicio utilizando varios elementos que pueden clasificarse en abstractos o concretos.
La parte abstracta describe las operaciones y mensajes con detalle (¿qué hace el servicio?). Se puede ver como la interfaz o una clase abstracta en el mundo de Java. Cuenta con dos componentes principales: o Las operaciones que forman la definición de la interfaz. o Los tipos de datos para los parámetros de entrada, salida y error, de las operaciones. La parte concreta describe el cómo y dónde del servicio. Se puede ver como la implementación de la parte abstracta en el mundo de Java, aunque solamente describe dónde se encuentra dicho implementación para utilizarse. Cuenta con dos componentes principales: o Información de enlazado (binding) sobre el protocolo a utilizar. o La dirección en donde localizar el servicio.
UDDI (Universal Description, Descovery and Integration) nos permite localizar Servicios Web, para lo que define una especificación para construir un directorio distribuido de Servicios Web donde los datos se almacenan en un XML. Además almacenan información sobre las organizaciones que proveen el servicio, el estado en que se encuentran y la forma de uso. Por lo que tenemos tres tipos de información relacionados entre sí:
Páginas blancas: Datos de las Organizaciones (dirección, información de contacto, etc). Páginas amarillas: Clasificación de las Organizaciones (según tipo de industria, zona geográfica, etc). CAPÍTULO 1. Tecnologías para la implementación del sistema 25
Páginas verdes: Información técnica sobre los servicios que se ofrecen así como las instrucciones de utilización.
Ilustración 3 Arquitectura de UDDI UDDI define también una API para trabajar con dicho registro, que nos permitirá buscar datos almacenados en él, y publicar datos nuevos.
Dentro de los estilos de arquitectura de Servicios Web pueden resaltarse tres:
RPC (Remote Procedure Call o Llamadas de procedimiento remoto): Los Servicios Web basados en RPC presentan una interfaz de llamada a procedimientos y funciones distribuidas, lo cual es familiar a muchos desarrolladores. Su unidad básica es la Operación WSDL (Web Services Description Language o Lenguaje de Descripción de Servicios Web).
Es considerada por algunos como la primera generación de Servicios Web por y las primeras herramientas para servicios web estaban centradas en su idea. A pesar de ello ha sido criticada por no ser débilmente aclopado, muchos especialistas creen que este estilo debe desaparecer.
SOA (Services Oriented Arquitectura o Arquitectura Orientada a Servicios): Los Servicios Web pueden también ser implementados siguiendo los conceptos de la CAPÍTULO 1. Tecnologías para la implementación del sistema 26 arquitectura SOA, donde la unidad básica de comunicación es el mensaje, más que la operación. Esto es típicamente referenciado como servicios orientados a mensajes.
Los Servicios Web basados en SOA son soportados por la mayor parte de desarrolladores de software y analistas. Al contrario que los Servicios Web basados en RPC, este estilo es débilmente acoplado, lo cual es preferible ya que se centra en el “contrato” proporcionado por el documento WSDL, más que en los detalles de implementación subyacentes.
Ilustración 4 Arquitectura de SOAP El proveedor del servicio define la descripción abstracta de dicho servicio utilizando WSDL. Luego se crea el servicio en concreto a partir de la definición abstracta del servicio, produciendo así una descripción concreta del servicio WSDL, la que va a publicarse en un servicio de registro como por ejemplo UDDI. Un cliente de un servicio puede utilizar un servicio de registro para localizar una descripción de un servicio, a partir de la cual podrá seleccionar y utilizar una implementación concreta de dicho servicio. CAPÍTULO 1. Tecnologías para la implementación del sistema 27
La descripción abstracta se define en un documento WSDL como un PortType. Una instancia concreta de un servicio se define mediante un elemento port de un WSDL (consistente a su vez en una combinación de un PortType, un binding de codificación y transporte, más una dirección). N conjunto de ports definen un elemento service de un WSDL.
REST (REpresentation State Transfer o Transferencia de Estado de REpresentación): Es un estilo de arquitectura de software para sistemas hipermedias distribuidos como la Web. Los Servicios Web basados en REST intentan emular al protocolo HTTP o protocolos similares mediante la restricción de establecer la interfaz a un conjunto conocido de operaciones estándar (por ejemplo GET, PUT,…). Por tanto, este estilo se centra más en interactuar con recursos con estado, que con mensajes y operaciones.
En realidad, REST se refiere estrictamente a una colección de principios para el diseño de arquitecturas en red. Estos principios resumen como los recursos son definidos y diseccionados. El término frecuentemente es utilizado en el sentido de describir a cualquier interfaz que transmite datos específicos de un domino sobre HTTP sin una capa adicional, como hace SOAP.
El término REST fue introducido por primera vez por Roy Fielding (Uno de los principales autores de la especificación de HTTP) en su Tesis Doctoral en el 2000, en ese momento no se prestó mucha atención en él.
Aunque REST no es un estándar, está basado en basado en estándares:
HTTP.
URL.
XML, HTML, GIF, JPEG, etc.
Text/xml, text/html, etc.
REST tiene cuatro objetivos en su arquitectura: CAPÍTULO 1. Tecnologías para la implementación del sistema 28
Escalabilidad de la interacción de los componentes: la web ha crecido exponencialmente sin degradar su rendimiento, esto se ve con la variedad de clientes que pueden acceder a través de la Web.
Generalidad de interfaces: Con el protocolo HTTP, cualquier cliente puede interactuar con cualquier servido sin ninguna configuración especial.
Puesta en funcionamiento independiente: los clientes y servidores pueden ser puestos en funcionamiento durante años, por lo que clientes actuales son capaces de entenderse mediante el uso de cabeceras creadas con HTTP y las URIs, además de la habilidad de crear nuevos métodos y tipos de contenidos.
Compatibilidad con componentes intermedios: La compatibilidad con proxys, las caches, los firewalls, los Gateway, permiten reducirla la latencia de interacción, reforzar la seguridad y encapsular otros sistemas.
Estos objetivos son cumplidos aplicando tres restricciones:
Identificación y manipulación de recursos a través de representaciones: Esto se consigue con el uso de URIs, para lo que se utiliza el protocolo HTTP. Los recursos son los objetos lógicos a los que se le envían mensajes, estos no pueden ser accedidos o modificados de forma directa. Internamente el estado de un recurso puede ser cualquier elemento desde una base de datos relacional hasta un archivo de texto.
Mensajes autodescriptivos: REST considera que los mensajes HTTP deberían ser lo más descriptivo posible, de forma que lo intermediarios puedan interpretar los mensajes e interpretar los servicios en nombre de los usuarios. HTTP es un protocolo sin estado y es posible interpretar cada mensaje sin ningún conocimiento de los mensajes precedentes.
Hipermedia como mecanismo del estado de la aplicación: REST considera que el estado actual de una aplicación web debería ser capturado en uno o más documentos de hipertexto, residiendo en el cliente y el servidor. CAPÍTULO 1. Tecnologías para la implementación del sistema 29
Los Servicios Web pueden implementarse de varias formas a nivel técnico, dentro de los grandes Servicios Web podemos destacar dos: SOAP y RESTful.
1.4.1. Simple Object Access Protocol (SOAP)
SOAP es un protocolo derivado de XML que suministra un mecanismo simple y ligero para intercambiar información estructurada entre máquinas en un ambiente descentralizado y distribuido, siguiendo la arquitectura SOA.
SOAP no define la semántica de la aplicación, como modelo de programación, el define un mecanismo simple para expresar la semántica de la aplicación suministrando un modelo de paquete modular y mecanismos de codificación para codificar datos con estos módulos. Esto permite que sea utilizado por una gran variedad de sistemas que extienden de los sistemas de mensajes RPC(Lippert and Govindarajulu, 2015, Casey Kochmer, 2002, Goncalves, 2010, F.Darwin, 2014).
SOAP está compuesto por tres partes:
El sobre: Define todo un framework que define ¿que está en el mensaje?, ¿quién debe lidiar con ello?, si es obligatorio o no. Las reglas de codificación: Definen el mecanismo de publicación para el intercambio de tipos de datos definidos por la aplicación. SOAP RPC: Define una convención que puede ser utilizada para la representación de llamadas a procedimientos remotos y sus respuestas.
Los mensajes SOAP van fundamentalmente en un solo sentido, transmisiones desde un emisor a un receptor, estas a menudo se combinan para implementar patrones como repetición. Cuando una aplicación SOAP recibe un mensaje, para procesarlo se debe seguir una serie de acciones:
1. Identificar todas las partes del mensaje SOAP destinado a tal Aplicación. 2. Verificar que todas las partes obligatorias identificadas en el paso 1 se apoyan en la solicitud de este mensaje y procesarlos. Si no es el caso entonces descartar el mensaje. Se puede ignorar partes opcionales identificadas en el paso 1 sin afectar el resultado del procesamiento. CAPÍTULO 1. Tecnologías para la implementación del sistema 30
3. Si la aplicación no es el destino final del mensaje, se debe remover todas las partes identificadas en el paso 1 antes de enviar el mensaje.
Los mensajes de SOAP en cambio están constituido por elementos, ver Anexo 4
1.4.2. RESTful
RESTful es un Servicio Web basado en la arquitectura REST por lo que posee todas sus características. Está centrado en el protocolo de transporte HTTP, considera cada pieza de información un recurso y estos se abordan mediante identificadores uniforme de recursos (URI), que son enlaces en la Web. Para interactuar sobre los recursos existen funciones muy simples pero muy bien definidas. La misma arquitectura REST hace de los Servicios Web RESTful simples, ligeros y de alto rendimiento(Roman et al., 2015, Goncalves, 2010, Leonard Richardson, 2007, F.Darwin, 2014).
Los recursos que juegan un papel central en la arquitectura REST es cualquier cosa que el cliente quiera hacer referencia o interactuar (un libro, un resultado de una búsqueda, una tabla de contenidos, etc.), estos pueden almacenarse en cualquier lugar al que pueda dirigirse (una base de datos, un archivo, etc), son identificados por una URI.
Un recurso puede ser representado por diferentes formatos de datos (texto, JSON, XML, documento PDF, JPG, etc.), esta representación no es más que cualquier información útil del estado del recurso(Marset, 2006-07).
Para elegir entre las diferentes representaciones que se pueden hacer de un recurso para un recurso existen dos alternativas:
Crear una URI por cada representación posible. Crear una única URI para todas las representaciones y confiar en el mecanismo llamado content negotiation.
La web se compone de recursos vinculados entre sí y se puede acceder a ellos utilizando funciones de HTTP.
1.4.3. RESTful contra SOAP
El principal beneficio de SOAP recae en ser fuertemente acoplado, lo que permite poder ser testado y depurado antes de poner en marcha la aplicación, en cambio las ventajas de CAPÍTULO 1. Tecnologías para la implementación del sistema 31 aproximación de la aproximación basada en REST recaen en la potencial escalabilidad de este tipo de sistemas, así como el acceso con escaso consumo de recursos a sus operaciones debido al limitado número de operaciones y el esquema de direccionamiento unificado.
Tabla 2 Comparación de REST y SOAP
REST SOAP Características Las operaciones se definen en Las operaciones son definidas como los mensajes. puertos WSDL. Una dirección única para cada Dirección única para todas las instancia del proceso. operaciones. Cada objeto soporta las Múltiple instancias del proceso operaciones estándares comparten la misma operación. definidas. Componentes fuertemente Componentes débilmente acoplados. acoplados. Ventajas Bajo consumo de recursos. Fácil (generalmente) de utilizar. declaradas Las instancias del proceso son La depuración es posible. creadas explícitamente. Las operaciones complejas pueden El cliente no necesita ser escondidas detrás de una fachada. información de enrutamiento a Envolver APIs existentes es sencillo partir de la URI inicial. Incrementa la privacidad. Los clientes pueden tener una Herramientas de desarrollo. interfaz “listener” (escuchadora) genérica para las notificaciones. Generalmente fácil de construir y adoptar. Posibles Gran número de objetos. Los clientes necesitan saber las desventajas Manejar el espacio de nombres operaciones y su semántica antes del (URIs) puede ser engorroso. uso. La descripción Los clientes necesitan puertos sintáctica/semántica muy dedicados para diferentes tipos de informal (orientada al usuario). notificaciones. Pocas herramientas de Las instancias del proceso son desarrollo. creadas implícitamente. Una comparación para decidir cuál es el mejor no es posible puesto que ambos tienen sus puntos fuertes y débiles, solamente cabe destacar donde es mejor utilizar cada uno aprovechando sus ventajas.
Un servicio basado en RESTful es aplicable cuando: CAPÍTULO 1. Tecnologías para la implementación del sistema 32
El servicio Web no tiene estado. Una buena comprobación de esto consistiría en considerar si la interacción puede sobrevivir a un reinicio del servidor. Una infraestructura de caching puede mejorar el rendimiento. Si los datos que el servicio Web devuelve no son dinámicamente generados y pueden ser cacheados, entonces la infraestructura de caching que los servidores Web y los intermediarios proporcionan, pueden incrementar el rendimiento (Marset, 2006-07, Leonard Richardson, 2007 ). Tanto el productor como el consumidor del servicio conocen el contexto y contenido que va a ser comunicado. Ya que REST no posee todavía un modo estándar y formal de describir la interfaz de los servicios Web, ambas partes deben estar de acuerdo en el modo de intercambiar de información (Marset, 2006-07, Leonard Richardson, 2007). El ancho de banda es importante y necesita ser limitado. REST es particularmente útil en dispositivos con escasos recursos como PDAs o teléfonos móviles, donde la sobrecarga de las cabeceras y capas adicionales de los elementos SOAP debe ser restringida (Marset, 2006-07, Leonard Richardson, 2007).
La distribución de Servicios Web o la agregación con sitios Web existentes puede ser fácilmente desarrollada mediante REST. Los desarrolladores pueden utilizar tecnologías como AJAX y toolkits como DWR (Direct Web Remoting) para consumir el servicio en sus aplicaciones Web (Marset, 2006-07, Leonard Richardson, 2007).
Mientras que un servicio basado en SOAP es útil cuando:
Se establece un contrato formal para la descripción de la interfaz que el servicio ofrece. El lenguaje de Descripción de Servicios Web, como ya sabemos, permite describir con detalles el servicio Web (Marset, 2006-07, Francisco Curbera, 2002). La arquitectura debe abordar requerimientos complejos no funcionales. Muchas especificaciones de servicios Web abordan tales requisitos y establecen un vocabulario común para ellos. Algunos ejemplos incluyen transacciones, seguridad, direccionamiento, etc. La mayoría de aplicaciones del mundo real se comportan por CAPÍTULO 1. Tecnologías para la implementación del sistema 33
encima de las operaciones CRUD y requieren mantener información contextual y el estado conversacional. Con la aproximación REST, abordar este tipo de arquitecturas resulta más complicado (Marset, 2006-07, Francisco Curbera, 2002). La arquitectura necesita manejar procesado asíncrono e invocación. En estos casos, la infraestructura proporcionada por estándares como WSRM y APIs como JAX-WS junto con la asincronía por el lado del cliente nos permitirán el soporte de estas características (Marset, 2006-07).
1.5. Conclusiones parciales
Se determinó un conjunto de herramientas que permiten realizar una implementación del sistema propuesto, a partir de la interacción entre ellas. Ya que:
StarDict posee un grupo de herramientas que proveen todas las facilidades necesarias para crear diccionarios compatibles con su plataforma y por lo tanto compatible con OmegaT, además sus herramienta se utilizan a través de la consola de comandos permitiendo su integración a una aplicación con las opciones de creación o manipulación de diccionarios haciendo de esta herramienta ideal. Lucene es un biblioteca con muchas facilidades para realizar búsquedas de información a partir de la información previamente indexada de documentos de diferentes formatos, la información en sus índices puede ser clasificada, organizada y optimizada permitiendo que las búsquedas sean muy rápidas, las cuales pueden mejorar con la utilización de otras bibliotecas de apoyo como el caso de Tika. Todo esto convierte a Lucene en prácticamente la mejor opción a considerar para el proceso de recuperación de información. La interface de aplicación de StarDict muestra varias palabras similares a la palabra consultada, pero no es el caso cuando se realiza por las funciones de consulta de diccionarios de OmegaT que solo muestra la información de la palabra en cuestión si se encuentra en los diccionarios, por lo que el empleo de la biblioteca Wordnet puede ser muy útil para expandir la consulta de los mismos es muy importante por sus bases de datos y funciones para encontrar palabras similares y sinónimos. Por otra parte como se quiere implementar un sistema simple y que puede ser ampliado o cambiado a lo largo del tiempo, y además será emplazado sobre un CAPÍTULO 1. Tecnologías para la implementación del sistema 34 hardware que puede tener o no muchos recursos, por lo que un servicio web RESTful es el más conveniente para un sistema con estas características. CAPÍTULO 2. Diseño e implementación de sistema 35
Capítulo 2. Diseño e implementación del sistema
En el siguiente capítulo se realiza una descripción de los requisitos y diseño del sistema, en un primer momento se realiza una modelación del negocio y se describen los requisitos funcionales y no funcionales del sistema, luego se mencionan y describen los actores y casos de uso del sistema, en adelante se detalla la arquitectura del sistema, así como el diagrama de clases mostrándose la relación entre las clases del sistema lo que da una clara visión de cómo funciona, a continuación se muestran y explican los componentes utilizados por el sistema y por último se describe el diagrama de despliegue, para mostrar claramente la disposición de los recursos externos consumidos por el sistema.
2.1. Modelado del negocio
En la facultad de Humanidades de la Universidad Central “Marta Abreu” de las Villas. Los profesionales de las lenguas extranjeras como parte de su trabajo realizan traducciones de documentos.
Durante la traducción es necesario la utilización de todos los recursos disponibles con el objetivo de ganar en rapidez y exactitud del resultado final, por lo que se implementar un método de trabajo cooperativo orientado a la exportación e importación de los recursos utilizados por una aplicación cliente por parte del traductor, así como a la creación y explotación de algunos recursos (diccionarios).
Durante la traducción el usuario tendrá la opción de exportar los recursos de su proyecto de traducción así como importar los recursos de otros proyectos, a través de diferentes filtros (diccionarios, glosarios y memorias de traducción con el flujo de traducción igual al del proyecto actual y memorias de traducción de proyectos similares).
Durante la traducción la aplicación cliente consultará diccionarios brindándole al usuario información de las palabras del documento origen y de las palabras de su traducción de forma automática a medida que avanza la misma, en el caso de idioma inglés la consulta de las palabras del documento origen o destino se ampliará utilizando palabras con significados similares (pretty=>beautifull, nice, cute; house=> home, houseful, hostel, homestead, household). CAPÍTULO 2. Diseño e implementación de sistema 36
Es necesario contar con una aplicación de administración para la creación de los diccionarios así como el mantenimiento del repositorio donde estarán los recursos compartidos, de la cual se encargará un administrador.
2.2. Requisitos funcionales y no funcionales
Tabla 3 Requisitos funcionales y no funcionales
Requisitos funcionales Descripción
Exportar recursos del El sistema debe permitir al traductor exportar los recursos proyecto de traducción de un proyecto desde la aplicación cliente:
Memorias de traducción (solas). Memorias de traducción (vinculadas a un documento o sea las memorias de un proyecto terminado). Términos del glosario local.
Importar recursos El sistema debe permitir importar recursos compartidos e incorporarlos al proyecto actual:
Memorias de traducción con el mismo flujo de traducción que el proyecto. Memorias de traducción de proyectos similares al actual. Términos de glosarios con el mismo flujo de traducción. Diccionarios con el mismo flujo de traducción.
Consultar diccionarios de El sistema debe ser capaz de consultar diccionarios de forma automática forma automática a medida que avanza la traducción, la consulta debe ser en ambos sentidos de la traducción CAPÍTULO 2. Diseño e implementación de sistema 37
(documento origen y documento de la traducción en curso), además la consulta debe expandirse con términos de significados similares en el caso del idioma inglés.
Creación de diccionario El sistema debe contar con una herramienta de administración la cual dentro de las funcionalidades permita la creación de diccionarios y la copia de los mismos a un repositorio para su descarga.
Mantenimiento del El sistema debe contar con una aplicación de repositorio de los administración, con las funcionalidades necesarias para recursos. administrar los recursos que se compartirán en un repositorio:
Vaciar repositorio Adicionar elementos al repositorio. Eliminar elementos del repositorio.
Requisitos no funcionales Descripción
Usabilidad El sistema debe funcionar correctamente tanto la aplicación cliente como la de administración, asi como los servicios que las comunican.
Ayuda y documentación El sistema debe brindar manuales de usuario que documenten la forma de utilización de las funcionalidades.
Diseño e implementación Se utilizará un servidor web Glassfish. La herramienta CASE Visual Paradigm para la modelación y documentación.
Disponibilidad Los servicios del sistema deben poder utilizarse en cualquier momento del año y a cualquier hora. CAPÍTULO 2. Diseño e implementación de sistema 38
Seguridad Debe existir una política de administración en el servidor donde estarán los repositorios y los servicios.
Portabilidad La aplicación cliente debe estar desarrollada con un código portable de manera que pueda ser utilizada en cualquier sistema operativo.
2.3. Casos de uso y actores
Ilustración 5 Casos de uso y actores
2.3.1. Actores del sistema
Traductor: Puede ser uno o más usuarios que utilicen la aplicación cliente, es el más beneficiado del sistema. Administrador: Es el actor encargado de la administración de los recursos compartidos así como del mantenimiento de los repositorios, la creación de los diccionarios y el despliegue de los servicios del sistema. Puede ser una sola persona o puede ser un grupo de personas especializadas en las lenguas extranjeras para la validación de los recursos de los repositorios y la creación de los diccionarios y otra para la administración del servidor así como para el despliegue de los servicios. CAPÍTULO 2. Diseño e implementación de sistema 39
OmegaTAplicacionWeb: Es un actor externo (Servicio Web) que se presenta como un actor intermedio que interviene las solicitudes de casos de uso del traductor y las ejecuta.
2.3.2. Casos de uso
Tabla 4 Caso de uso: Insertar elementos al repositorio
Caso de uso: Insertar elementos al repositorio
Precondiciones _
Secuencia normal Paso Acción
1 El cliente selecciona la opción de editar/insertar/….
2 El cliente selecciona el archivo a editar.
3 El sistema obtiene la información del archivo y la representa en el panel de edición.
4 El usuario modifica la información hasta quedar satisfecho.
5 El usuario selecciona la opción de índice/adicionar elemento/….
6 El sistema divide la información en elementos.
7 El sistema verifica que no existe el elemento en el índice.
8 El sistema inserta el elemento.
9 El sistema lee la información almacenada de los flujos de traducción.
10 El sistema verifica que el flujo de traducción del elemento no esté almacenado CAPÍTULO 2. Diseño e implementación de sistema 40
11 El sistema guarda el flujo de traducción del elemento.
12 El sistema repite los pasos 7-11 hasta que no existan más elementos para insertar.
13 El sistema muestra en el panel de salida los elementos insertados.
Postcondición Se insertan los elementos no repetidos del índice y de existir nuevos flujos de traducción son almacenados.
Excepciones Paso Acción
6 Si el usuario borra algún marcador.
E.1 El sistema muestra en el panel de salida un mensaje de error.
E.2 El usuario pone los marcadores eliminados.
E.3 El usuario selecciona la opción de índice/adicionar elemento/….
Comentarios Los marcadores son colocados por el sistema para diferenciar las diferentes partes de la información así como donde termina un elemento, así como las partes de los mismos (metadatos).
Tabla 5 Caso de uso: Eliminar elementos de repositorio
Caso de uso: Eliminar elementos del repositorio
Precondiciones _
Secuencia normal Paso Acción CAPÍTULO 2. Diseño e implementación de sistema 41
1 El usuario selecciona la opción de editar/eliminar/….
2 El sistema muestra al usuario opciones de flujo de traducción de elementos que se han insertado anteriormente.
3 El usuario selecciona el flujo de traducción de los elementos que desea eliminar.
4 El sistema busca y muestra en el panel de edición la información de los elementos que coinciden con el flujo de la traducción seleccionado.
5 El usuario selecciona el elemento a eliminar.
6 El usuario selecciona la opción índice/eliminar elemento/….
7 El sistema elimina el elemento seleccionado del repositorio.
8 El usuario repite los pasos 5 y 6 hasta quedar satisfecho.
Postcondición Se eliminan del índice todos los elementos seleccionados por el usuario.
Excepciones Paso Acción
_ _
Comentarios _
CAPÍTULO 2. Diseño e implementación de sistema 42
Tabla 6 Caso de uso: Crear diccionarios
Caso de uso: Crear diccionarios
Precondiciones _
Secuencia normal Paso Acción
1 El usuario selecciona la opción diccionarios/crear diccionarios.
2 El usuario selecciona la opción diccionarios/crear diccionarios.
3 El sistema crea un diccionario en el directorio del diccionario, y hace una copia en el directorio del servicio FTP.
4 El sistema muestra en el panel de salida un mensaje con información general de la composición del diccionario.
Postcondición Se crea un nuevo diccionario y se crea una copia en el directorio del servicio FTP.
Excepciones Paso Acción
3 Si el archivo escogido por el usuario estaba mal configurado.
E.1 El sistema muestra un mensaje en el panel de salida detallando los errores de configuración.
E.2 Se cancela el caos de uso.
Comentarios _
CAPÍTULO 2. Diseño e implementación de sistema 43
Tabla 7 Caso de uso: Exportar recursos de traducción
Caso de uso: Exportar recursos de traducción
Precondiciones Debe existir un proyecto abierto.
Secuencia normal Paso Acción
1 El usuario selecciona de las opciones de compartir la del recurso que desea compartir.
2 El sistema obtiene la información del recurso a exportar.
3 El sistema obtiene la información del flujo de traducción del proyecto abierto.
4 El sistema llama al servicio encargado de compartir el recurso seleccionado.
5 El sistema muestra un mensaje al usuario notificando que el recurso fue compartido.
Postcondición El recurso seleccionado por el usuario es enviado al servidor para su validación e inserción al índice que conforma el repositorio.
Excepciones Paso Acción
2 Si no existe la información del recurso a exportar.
E.1 El sistema muestra un mensaje de error.
E.2 El caso de uso se cancela.
4 Si el sistema no puede contactar al servicio.
E.3 El sistema muestra un mensaje de error. CAPÍTULO 2. Diseño e implementación de sistema 44
E.4 El caso de uso se cancela.
Comentarios En el caso de exportar glosarios se verifica el contenido del archivo glossary.txt, si se exportan memorias de traducción se verifica que exista al menos una y en el caso de los proyectos se verifica tanto de que existan un archivo para traducir como las memorias de traducción correspondientes a sus traducción.
Que el sistema no pueda contactar al servicio, puede ser producto de un IP incorrecto o de que el servicio no esté desplegado.
Tabla 8 Caso de uso: Importar recursos de traducción
Caso de uso: Importar recursos de traducción
Precondiciones Debe existir un proyecto abierto.
Secuencia normal Paso Acción
1 El usuario selecciona de las opciones de importar la del recurso que desea importar.
2 El sistema obtiene la información del flujo de traducción del proyecto abierto y cualquier otra información necesaria según el recurso a importar.
3 El sistema llama al servicio encargado de compartir el recurso seleccionado.
4 El sistema inserta los nuevos recursos sin insertar recursos repetidos.
5 El sistema muestra un mensaje al usuario notificando que se importaron nuevos recursos. CAPÍTULO 2. Diseño e implementación de sistema 45
Postcondición Se importan nuevos recursos de tipo seleccionado por el usuario al proyecto.
Excepciones Paso Acción
2 Si no existe la información del recurso a importar.
E.1 El sistema muestra un mensaje de error.
E.2 El caso de uso se cancela.
4 Si el sistema no puede contactar al servicio.
E.3 El sistema muestra un mensaje de error.
E.4 El caso de uso se cancela.
Comentarios Solamente la opción de importar proyecto requiere información extra al flujo de traducción, requiere que exista un documento para traducir.
Que el sistema no pueda contactar al servicio, puede ser producto de un IP incorrecto o de que el servicio no esté desplegado.
Tabla 9 Compartir recursos de traducción
Caso de uso: Compartir recursos de traducción
Precondiciones Debe existir una solicitud del servicio.
Secuencia normal Paso Acción
1 El sistema captura la solicitud del servicio y los parámetros de entrada. CAPÍTULO 2. Diseño e implementación de sistema 46
2 El sistema divide los parámetros de entrada y conforma la información a compartir.
3 El sistema lee el contenido del archivo donde se guarda la información compartida.
4 El sistema sobrescribe la información del archivo con la información existente y la nueva información.
5 El sistema envía un mensaje de éxito al solicitante del servicio.
Postcondición Se escribe nueva información en el archivo que contiene la información sin procesar de los recursos de traducción.
Excepciones Paso Acción
_ _
Comentarios _
Tabla 10 Buscar recursos de traducción
Caso de uso: Buscar recursos de traducción
Precondiciones Debe existir una solicitud del servicio.
Secuencia normal Paso Acción
1 El sistema captura la solicitud del servicio y los parámetros de entrada.
2 El sistema divide los parámetros de entrada y conforma la consulta de búsqueda. CAPÍTULO 2. Diseño e implementación de sistema 47
3 El sistema ejecuta la consulta de búsqueda.
4 El sistema captura el resultado de la búsqueda.
5 El sistema conforma la respuesta de la solicitud a partir de los resultados de la búsqueda.
6 El sistema envía un mensaje de con la respuesta que conformó al solicitante del sevicio.
Postcondición Se escribe nueva información en el archivo que contiene la información sin procesar de los recursos de traducción.
Excepciones Paso Acción
_ _
Comentarios La respuesta conformada puede ser de “no” en el caso de que no se encontrara ningún resultado en la búsqueda, o la información con la configuración con que escribirá en el archivo utilizado por la aplicación cliente.
2.4. Arquitectura del sistema
El sistema está formado por una aplicación cliente (OmegaT), una aplicación de administración (SistemaDIndexado), un servicio web que transfiere la información desde el cliente al servidor y viceversa y un servidor de FTP, la información enviada desde la aplicación cliente a través del servicio web correspondiente al recurso es almacenada en archivos .txt según el recurso, esta información es utilizada por la aplicación de administración e indexada, los archivos que forman el índice son utilizados por el servicio web para la importación de recursos cuando lo solicita la aplicación cliente y la información de la importación es almacenada en el archivo que correspondiente en el proyecto. La aplicación de administración crea los archivos de los diccionarios y estos son copiados en un directorio especial del servidor FTP a los que la aplicación cliente puede acceder para la CAPÍTULO 2. Diseño e implementación de sistema 48 importación de los mismo, cuando sucede los archivos son almacenados en el directorio de los diccionarios del proyecto.
Ilustración 6Arquitectura del Sistema
2.5. Principios de diseño
La aplicación cliente ya contaba con una serie de principios de diseños a los cuales se adaptaron las modificaciones realizadas en la aplicación, en el caso de los patrones utilizados en la construcción, se pueden destacar los patrones Abstract Factory y Singleton, dentro de los patrones estructurales se utilizan, el patrón Adapter y Composite y dentro de los patrones de comportamiento se utilizan el patrón Interface.
El patrón Factory usualmente utilizado para separar la clase que crea los objetos de la jerarquía de objetos a instanciar, es muy utilizado en toda la aplicación cliente, es utilizado en las modificaciones realizadas a la aplicación a la hora de trabajar con las clases clientes en cada uno de los servicios y la clase Factory que los instancia.
El patrón Singleton es utilizado cuando se trabaja con clases que solo pueden tener una instancia, en el caso de la aplicación es utilizada en clases que solo se instancian en el momento del despliegue de la aplicación o cuando se carga un proyecto. CAPÍTULO 2. Diseño e implementación de sistema 49
El patrón Adapter es ampliamente utilizado para modificar clases utilizadas por Java como elementos que forman parte de la interface como es el caso de los jTextArea.
El patrón Composite se utiliza para diseñar clases que agrupan objetos complejos y a su vez están formados por objetos complejos y/o simples, es utilizado principalmente en la composición del menú principal.
2.6. Diagrama de clases
Ilustración 7 Diagrama de clases El diagrama de clases muestra el conjunto de clases, interfaces y colaboraciones así como las relaciones entre estas, presentes en la solución computacional del proyecto. Cubre la vista del diseño estático del sistema.El sistema cuenta con tres elementos principales, la aplicación cliente, la aplicación de administración y los servicios web. CAPÍTULO 2. Diseño e implementación de sistema 50
En la aplicación cliente se crearon ocho clases que juegan el papel de clases clientes para los servicios web que ofrece el sistema y el servicio de FTP, además de la clase que las instancian.
Las clases ClienteCompartirTG, ClienteCompartirM, ClienteCompartirP, son las encargadas de llamar los servicios web para compartir los recursos del proyecto para ello, utilizan dos parámetros String como entrada, el primero contiene la información del recurso estructurada de forma que una vez llega al servicio se puede dividir por términos lógicos en dependencia del tipo de recurso que se exporta, y el segundo determina la configuración de la red(dirección IP) donde se encuentra el servicio a llamar. Están sujetas a excepciones que controlan que el servicio se encuentre en funcionamiento (UniformInterfaceException) y que la configuración de la dirección IP sea correcta (ClientHandlerException). Las clases poseen tres métodos, un constructor, el método para llamar al servicio, y un método para cerrar la conexión con el servicio.
Las clases ClienteRecursoGlosarios, ClienteRecursoMemorias, ClienteRecursoProyectos, son las encargadas de llamar los servicios web para importar los recursos del proyecto, para ello las dos primeras utilizan como parámetros dos String, el primero contiene el flujo de la traducción del proyecto actual, y el segundo determina la configuración de la red (dirección IP) donde se encuentra el servicio a llamar; en el caso de la tercera el primer parámetro además del flujo de la traducción contiene la información de los archivos que fueron importados para su traducción, estructurados de manera que una vez llegado al servicio se puedan dividir ambas informaciones. Están sujetas a excepciones que controlan que el servicio se encuentre en funcionamiento (UniformInterfaceException y que la configuración de la dirección IP sea correcta (ClientHandlerException).
La clase ClienteFtp es la encargada de copiar los archivos del servidor FTP hacia el directorio de Dictionary del proyecto, en su instanciación requiere la dirección IP del servidor de FTP y para la copia de los archivos utiliza como parámetro un String que contiene la información del flujo de la traducción, y a partir de este construirá los nombres de los archivos a copiar.
La clase ObjectFactoryCompartir es la encargada de la instanciación de las clases mencionadas. CAPÍTULO 2. Diseño e implementación de sistema 51
La clase Core es una de las más importantes de la aplicación cliente inicializa y controla la mayoría de los elementos más importantes de la aplicación, como los jPanel de edición, la clase main, a través de esta clase y de las clases que utiliza se puede acceder a la información de los proyectos, tanto directorios que utiliza, como la información de los documentos a traducir, la traducción en curso. En el proyecto se utiliza muchas veces para llamar la clase Project que contiene la clase ProjectProperties.
La clase ProjectProperties contiene la información de todos los directorios y archivos del proyecto actual, así como la información del flujo de traducción y clases en que son separados los textos de los archivos a traducir para su presentación en el área de edición.
La clase RealProyect implementa la interface IProyect, esta clase se encarga de controlar todos los cambios dinámicos que se realizan al proyecto en el proceso de la traducción, así como también la compilación y las salvas de los cambios.
La clase DictionariesTextArea extiende de clases que extienden de la clase jTextPane de java, este panel es el encargado de mostrar la información de las consultas positivas de los diccionarios (consultas de las que se encontró el elemento en uno o varios diccionarios). En la aplicación original solo se mostraba consultas a partir de las palabras del texto origen, esta clase fue modificada en los método que mediaban esta función para que consultara también las palabras del texto traducido y nuevas palabras buscadas de sinónimos de las palabras del texto origen si está en inglés utilizando la biblioteca RitaWordNet como forma de aumentar las posibilidades de una consulta exitosa.
Ilustración 8 Código de la preparación de las palabras para la búsqueda en diccionarios CAPÍTULO 2. Diseño e implementación de sistema 52
Ilustración 9 Código de la preparación de las palabras para la búsqueda en diccionarios (continuación) El método DictionaryEntriesSearchThread es el encargado de obtener las palabras que se buscaran en el diccionarios, en las líneas 283 y 302 se verifica que el idioma origen o destino correspondan al inglés para expandir la lista de palabras a buscar utilizando Wordnet, lo que amplía la búsqueda de palabras en los diccionarios.
En caso de que uno de los idiomas origen o destino pertenezcan al inglés, se obtiene el segmento del texto origen o el segmento del texto de la traducción y se separa por palabras, cada una de las palabras obtenidas se le busca el diccionario Wordnet en cuales categorías gramaticales se puede encontrar el término, si se encuentra en alguna, se busca los cinco primeros sinónimos de la palabra en esa categoría y se adiciona a la lista de las palabras a buscar en los diccionarios.
La clase DictionariesManeger es la clase que se encarga de realizar la búsqueda de los diccionarios, la información obtenida es utilizada por la clase DictionariesTextArea.
La clase EditorTextArea3 es una clase que hereda de clases que heredan de la clase jTextPane de java, en este panel se realiza la edición y una serie de operaciones para salvar las propiedades de la traducción, en el sistema se modificó la clase para refrescar el panel de los diccionarios cada vez que se presionara la tecla espacio y de esa forma obtener la información de la última palabra escrita en los diccionarios.
Ilustración 10 Código del nuevo listener en la clase EditorTextArea3 CAPÍTULO 2. Diseño e implementación de sistema 53
La clase MainWindowMenu contiene la información del menú principal, tanto sus componentes y algunas de sus propiedades como los listener para sus eventos. Esta clase fue modificada para agregar nuevos submenú al original, los cuales solo se activan cuando se abre un proyecto.
La clase MainWindowMenuHandler contiene los actionPerformed que los listener de los submenús utilizarán, la clase original fue modificada para agregar nuevos listener que utilizan los nuevos submenú del sistema.
La aplicación de administración cuenta con quince clases además de la clase NewFrame (frame principal).
Las clases IndiceVacioG, IndiceVacioMt e IndiceVacioP sirven para crear un nuevo índice de Lucene vacío, en el caso de que exista un índice en la dirección con elementos lo vacía, los índices poseen una dirección estática ya que serán utilizados por otras aplicaciones.
Las clases InsertarTG, InsertarM e InsertarP son utilizadas para la incepción de los elementos en sus respectivos índices.
Las clases EliminarTG, EliminarM y EliminarP son utilizadas para la eliminación uno a uno de elementos de los índices.
Las clases ExistenTG, ExistenM y ExistenP son utilizadas para verificar la existencia de un elemento en los índices, son empleadas en el momento de la incepción para evitar elementos repetidos en el índice.
Las clases ListarTG, ListarM, ListarP son utilizadas para buscar los elementos que se desean eliminar del índice.
El servicio web cuenta con seis clases que juegan el papel de los recursos RESTful del mismo.
Las clases CompartirM, CompartirP, CompartirTG son los recursos utilizados por la aplicación cliente la información que obtienen son guardados en un archivo .txt de forma que se pueda revisar, validar e indexar la información con la aplicación de administración. Los archivos guardan la información con un formato determinado para separar los recursos, en el caso de los términos de los glosarios y las memorias de traducción el archivo comienza con la cantidad de recursos que tiene almacenados y abajo los recursos separados por cambios de CAPÍTULO 2. Diseño e implementación de sistema 54 línea, en el caso de los proyectos el archivo comienza con la cantidad de proyectos almacenados, debajo la información de cada proyecto con la disposición, textos del proyecto, cantidad de memorias de traducción y las memorias de traducción.
Las clases RecursoGlosarios2, RecursoMemorias2 y RecursoProyectos4 son los recursos utilizados por la aplicación cliente para importar los recursos que se encuentran en el índice de Lucene, para ello utilizan las funciones de búsqueda que ofrece la biblioteca de Lucene para encontrar la información que puede ser útil en el proyecto.
Ilustración 11 Código de la búsqueda de memorias de traducción
Ilustración 12 Código de la búsqueda de memorias de traducción (continuación) En el caso de la búsqueda de memorias de traducción similares se utilizan Querys para buscar recursos donde el idioma origen o destino pertenezcan al flujo de la traducción del proyecto, luego estas Querys se unen en una Query booleana para obtener como resultado la convergencia de las búsquedas, una vez que se obtienen los Document del índice se recupera la información contenida en ellos y se estructura para la respuesta.
Mismo sucede en el caso de las búsquedas de los términos de los glosarios, solamente cambia la disposición de la estructura del resultado, la cual se muestra con la estructura de los elementos de OmegaT. CAPÍTULO 2. Diseño e implementación de sistema 55
Ilustración 13 Código de la búsqueda de proyectos similares
Ilustración 14 Código de la búsqueda de proyectos similares (continuación)
Ilustración 15 Código de la búsqueda de proyectos similares (continuación) CAPÍTULO 2. Diseño e implementación de sistema 56
En el caso de la búsqueda de proyectos similares primero se crean Querys para la búsqueda de recursos con el idioma de origen y destino coincidan con los del flujo de traducción del proyecto y el texto de a traducir lo más parecido posible al texto del o textos del proyecto, en caso existir al menos una coincidencia se rankea el resultado y se obtiene el identificador del primer Document de la lista de resultados. Luego se crea un Query del tipo MoreLikeThis para buscar los Documents similares al obtenido en la primera consulta, el como resultado se obtiene una consulta más flexible, se configura la consulta para recepcionar solamente los primeros veinte resultados. Como en el caso de las memorias de traducción y los glosarios es la información recuperada se estructura para enviar como respuesta final.
2.7. Diagrama de Componentes
El Diagrama de Componentes muestra diferentes módulos y componentes que se emplean en la solución que se propone, así como las relaciones de dependencia que existen entre estos componentes.
Ilustración 16 Diagrama de Componentes CAPÍTULO 2. Diseño e implementación de sistema 57
El componente principal de la aplicación es el grupo de bibliotecas utilizadas en las aplicaciones cliente y servidor y los servicios web, entre las más importantes se pueden destacar las bibliotecas de Lucene utilizadas para la indexación y búsqueda de la información así como para la tokenización y análisis sintáctico de textos de diferentes idiomas.
2.8. Diagrama de despliegue
El Diagrama de Despliegue describe la configuración de la red física y el hardware necesario para que el sistema pueda ser desplegado y se ejecute.
Ilustración 17 Diagrama de despliegue
Tabla 11 Descripción del diagrama de despliegue
Nombre del dispositivo Descripción de las capacidades que ofrece al sistema el dispositivo
Servidor web Funciona como servidor web y como servidor ftp. Provee al sistema la posibilidad de exportación e importación de Servidor ftp recursos.
Node Accede a los servicios del sistema en el servidor de forma remota. Es cualquier dispositivo que posea la aplicación cliente OmegaT.
CAPÍTULO 2. Diseño e implementación de sistema 58
2.9. Conclusiones parciales
Se implementó un sistema compuesto por cuatro componentes principales, una aplicación cliente, una aplicación de administración, un servicio web y un servidor ftp, a través de la interrelación de los componentes y recursos que utilizan el sistema se logra cumplir los requisitos funcionales del sistema. La aplicación cliente es una herramienta TAC a la que se le incorporaron funcionalidades y se personalizaron algunas de sus funciones para su incorporación al sistema, la aplicación de administración fue implementada para el manejo de los recursos del servidor, los servicios web fueron implementados con el estándar RESTful y tienen la función de conectar los recursos de la aplicación cliente con el servidor y realizar búsquedas de los recursos del servidor para la aplicación cliente, el servidor ftp permite la descarga de los archivos que contiene. El sistema está concebido de forma sencilla y ligera para ser utilizado por un hardware de bajos recursos.
CAPÍTULO 3. Pruebas del sistema 59
Capítulo 3. Pruebas del sistema
Antes del uso del sistema es necesario la realización de una serie de pruebas de caja negra para verificar la fiabilidad del mismo. El capítulo describe las principales pruebas realizadas con el objetivo de encontrar errores o comportamientos no deseados, determinando la calidad del sistema.
3.1. Prueba de las respuestas de los servicios web
Esta prueba tiene como objetivo verificar que las respuestas de los servicios web ante su llamado sean correctas verificando un posible caso donde no se muestren recursos que si existen.
Como precondición se indexan recursos en sus respectivos índices para después realizar consultas a los mismos mediante los servicios web, además en el caso de los servicios web que se encargan de la exportación, se verifica el archivo de salida buscando que los marcadores y la información sean correcta.
3.1.1. Servicio compartirM
Se llamó al servicio se le pasaron como parámetro tres memorias de traducción sencillas con un flujo de traducción de inglés-español con la configuración EN-US
Ilustración 18Archivo compartidos.txt de los memorias de traducción compartidas CAPÍTULO 3. Pruebas del sistema 60
3.1.2. Servicio compartirP
Se llamó al servicio se le pasaron como parámetro un proyecto de traducción sencillo con un flujo de traducción de inglés-español con la configuración texto origen
Ilustración 19Archivo de los proyectos compartidos 4.1.1 Servicio compartirTG
Se llamó al servicio se le pasaron como parámetro tres términos sencillos con un flujo de traducción de inglés-español con la configuración EN-US
Ilustración 20 Archivos de los términos de glosario compartidos
4.1.2 Servicio glosario CAPÍTULO 3. Pruebas del sistema 61
Para verificar el correcto funcionamiento de este servicio solo es necesario llamarlo pasando como parámetros el flujo de traducción del que se necesita términos en el formato lengua origen
Ilustración 21Respuesta de la llamada al servicio web glosario 4.1.3 Servicio memoria
Este servicio trabaja de manera similar al servicio glosario y los parámetros a pasarle son iguales.
Ilustración 22Respuesta de la llamada al servicio web memoria CAPÍTULO 3. Pruebas del sistema 62
4.1.4 Servicio proyecto
El servicio proyecto es diferente en cuanto a los parámetros en comparación con los servicio de su tipo anteriores los parámetros necesarios tienen un formato texto origen
Ilustración 23 Respuesta de la llamada al servicio web proyecto
3.2. Prueba de exportación
La prueba de exportación pone en evidencia la conexión con el servicio correspondiente al recurso a exportar así como verifica que todos los posibles errores por parte del sistema en cuanto a la conexión han sido tratados correctamente primeramente se tradujeron tres documentos con lengua origen inglés y lengua destino español. Debido a que esta funcionalidad solo muestra mensajes de errores y éxito la eficiencia de la funcionalidad se comprueba si la información se exporta correctamente en el archivo del servidor, y en el caso de que no está desplegado el servicio correspondiente o no exista conexión con la red se muestren los mensajes de errores correspondientes. CAPÍTULO 3. Pruebas del sistema 63
Ilustración 24Mensaje de éxito de la aplicación cliente al exportar correctamente términos del glosario
Ilustración 25Archivo compartidos.txt de los términos de glosario tras la exportación
3.3. Prueba de importación de términos de glosarios
Para la prueba de exportación se creó un nuevo proyecto y se importaron los recursos exportados en la prueba anterior. Se valida la importación cuando aparecen los recursos en el panel del recurso correspondiente, para ello en el proyecto creado se utilizó un texto semejante al exportado en la prueba anterior, en caso de que los textos no sean similares simplemente se comprueba los archivos hacia donde debe copiarse la nueva información. CAPÍTULO 3. Pruebas del sistema 64
Ilustración 26Aplicación tras la importación de nuevos términos de glosario
3.4. Prueba de importación de diccionarios
Esta prueba verifica la conexión con el servidor ftp donde se encuentran los diccionarios creados por el administrador del sistema. Para la prueba se crearon cuatros diccionarios en una prueba que se describirá posteriormente y estos se importaron. El resultado de la importación debe mostrarse inmediatamente que aparece el mensaje de éxito de la misma, si existen palabras del proyecto en los diccionarios importados estas son mostradas en el panel de los diccionarios.
3.5. Pruebas de indexación de recursos
En esta prueba se indexó información exportada con anterioridad y la aplicación muestra cuales fueron los recursos indexados, depende de que no existan en el índice. La otra forma de comprobar la correcta indexación es buscando los recursos indexados con los servicios de importación en caso de que se indexen correctamente estos aparecerán entre los resultados. CAPÍTULO 3. Pruebas del sistema 65
Ilustración 27Aplicación de administración tras indexar nuevos términos de glosario
Ilustración 28Respuesta del servicio web glosario tras las indexación de nuevos términos de glosario
3.6. Pruebas de eliminación de recursos
En esta prueba se eliminó la información importada con anterioridad la forma más rápida de verificar la eliminación es utilizando la funcionalidad de eliminar, una vez eliminado el recurso no debe aparecer dentro de la lista de los recursos disponibles para eliminar. CAPÍTULO 3. Pruebas del sistema 66
Ilustración 29Aplicación de administración tras la eliminación del término de glosario señalado
3.7. Conclusiones parciales
Se realizaron un grupo de pruebas con la finalidad de comprobar la fiabilidad de los métodos implementados en el sistema así como para comprobar la correcta interrelación entre los compontes, aplicaciones y servicios del sistema como son la conectividad de los servicios web y la aplicación cliente, los archivos generados por los servicios web y su configuración para el uso por la aplicación de administración y los archivos generados por la aplicación de administración, los cambios que esta le puede hacer y su uso por parte de los servicios web.
Las pruebas realizadas tuvieron resultados positivos demostrando la fiabilidad del sistema. CONCLUSIONES Y RECOMENDACIONES 67
Conclusiones
Como resultado del proyecto se desarrolló un sistema que mejora el entorno de profesionales de las lenguas extranjeras de la facultad de Humanidades para la traducción, dándole complimiento a los objetivos concebidos al inicio del proyecto.
Primero que nada se creó una aplicación de administración que permite el control y mantenimiento de índices que conforman los repositorios del sistema además permite la creación de diccionarios mediante información con un formato dado, y dispone de la facilidades para el despliegue y detención del servidor web utilizado, evitando la complejidad del manejo del mismo a un usuario no especializado.
Se implementaron servicios web para la exportación e importación de los recursos utilizados por la herramienta TAC OmegaT.
Se implementaron nuevas funcionalidades a la aplicación cliente OmegaT con el objetivo de poner en uso funciones de exportación e importación de sus recursos, además se amplió la búsqueda de las palabras en diccionarios para el idioma inglés, buscando no solo las palabras del texto sino también palabras con significados similares, y se incorporó a la búsqueda palabras de la traducción en tiempo real. Recomendaciones
Para la mejorar la calidad del sistema en futuras versiones es recomendable realizar una serie de cambios en la arquitectura del sistema así como sus funcionalidades e interface.
1. La aplicación de administración podría implementarse como una aplicación web lo que permitiría la administración de los recursos desde cualquier lugar o sistema operativo. 2. Los cambios realizados en la aplicación cliente pueden implementarse en un plugin dando la posibilidad de utilizar versiones más avanzadas de la aplicación cliente. 3. La información compartida puede guardarse utilizando bases de datos relacionales. 4. En un futuro se pueden incorporar las próximas bibliotecas de RitaWordNet para la expansión de la consulta diccionarios para otros idiomas. Anexos 68
Anexos
Anexo 1. Características del lenguage TMX
Como el lenguaje XML utiliza los estándares ISO para fechas, códigos de idiomas y códigos de país. Todos sus elementos se escriben en minúsculas, para evitar disfunciones a causa de la distinción que hace XML entre mayúsculas y minúsculas. El formato en que se escriben debe ser Unicode: UCS-2, UTF-8 o ISO-646.
Para los ficheros de 7 bites, los caracteres no ASCII se deben representar en hexadecimal, como á para "á". Se admiten, sin embargo, unas pocas entidades de caracteres: < para "<", > para ">", & para "&", o " para las comillas dobles.
Todo esto debe quedar especificado de alguna manera en el fichero, lo que se hace con la Declaración XML, que es , seguida de una declaración DOCTYPE, que será , si es que se desea que el documento se valide contra el DTD propio de TMX. Estas dos declaraciones deberán aparecer en las dos primeras líneas de cualquier fichero TMX. Una memoria de traducción siempre deberá comenzar con una etiqueta que lo marque como tmx, y que además advierta de la versión del lenguaje que se está utilizando; así, normalmente se abrirá la TM con
Como suele ocurrir, el
Header: Brinda información sobre el conjunto del fichero TMX, la cual puede ser de varios tipos:
1. Contextual: Creationtool (Obligatorio): Especifica el programa con que se ha creado, por lo general es creado por distintas utilidades, las cuales deben especificarse en el atributo. Creationtoolversion (Obligatorio): Especifica la versión del programa con que se ha creado el fichero TMX. Anexos 69
Creationdate (Opcional): Marca la fecha de creación del fichero TMX. Su formato debe ser el siguiente: AAAAMMDDThhmmssZ, donde AAAA es el año en cuatro cifras, MM el mes en dos cifras, DD el día en dos cifras, hh la hora, mm los minutos y ss los segundos, todo en dos cifras (esto es, añadiendo un "0" a la izquierda si es preciso). T es la propia letra T, que sirve para marcar el comienzo de la parte "tiempo" y el final de la parte "fecha"; y Z es la propia letra Z, y advierte de que el tiempo se da en UTC (Tiempo Universal Coordinado, o sea, la hora en Greenwich: dos horas menos que en España en invierno, y una hora menos en verano). Un ejemplo puede ser "20010504T164220Z". Creationid (Opcional): Aquí se marca el usuario que ha creado el fichero TMX. Adminlang (Obligatorio): Se especifica el código de la lengua en que están redactados las notas (elementos
transit, plaintext, xml, html, winres, entre otros que se pueden consultar en la página web de lisa http://www.lisa.org/tmx/tmxnotes.htm. Segtype (Obligatorio): Especifica el tipo de segmentación con que se va aplicar a las unidades de traducción, puede tomar valores: phrase, paragraph, block o sentence. 3. Comentarios:
elemento
Body: Como bien lo dice el nombre del atributo es el cuerpo del documento TMX, contendrá toda la información de la MT, contiene únicamente elementos
Tanto los TUs como los TUVs tienen un buen número de atributos opcionales, que dan información sobre esa unidad de traducción en concreto. Algunos de estos atributos ya mencionados, como o-encoding, datatype, creationtool, creationversion, creationdate, creationid, changedate, changeid, segtype, o-tmf y srclang. Esta información puede ser relevante en caso de que nuestra Memoria de Traducción haya sido realizada en distintos momentos y por distintos programas, y hayamos ido acumulando en ella el resultado de trabajos diversos. Además existen otros atributos que contienen información relevante a la hora de controlar el formato del texto origen y sus traducciones y el mantenimiento de las MT (Abaitua, 2001).
Usagecount: Contiene la información de la cantidad de veces que accedió a un elemento
será la única forma de organizar las frases una vez creada la MT, producto a que estas en si no tienen en cuenta la noción del orden.
Junto al texto dentro del elemento
Anexo 2. Creación del archivo .TAB
El archivo .TAB se obtiene de un archivo de texto plano codificado en UTF-8; contiene toda la información. Cada entrada en el diccionario está separada por una línea nueva y cada clave está separada de su definición por un tabulador de la manera:
Ilustración 30 Configuración del archivo.TAB Las definiciones pueden ser texto plano o pueden utilizar el markup Pango, que es muy parecido al markup de HTML, para dar formateo (cursivo, negrita, colores, etc) al texto; las claves no pueden tener formateo de manera una manera similar a esta:
Ilustración 31. Ejemplo de configuración de un archivo .TAB Anexos 73
Utilizando markup Pango la configuración quedaría de esta forma que es muy parecida al markup de HTML:
Ilustración 32 Ejemplo de archivo .TAB con markup Pango
Ilustración 33 Ejemplo de archivo .TAB con markup de HTML
Las líneas pueden separarse para dividir las definiciones utilizando '''\n''' para el makup Pango y '''
''' el markup de HTML, el resultado puede ser algo como esto:
Ilustración 34Ejemplo de salida en una sola línea
Ilustración 35Ejemplo de salida en varias líneas para un término Anexos 74
En el caso de que se planifique la utilización del diccionario para StarDict es aconsejable es uso de markup Pango y en el caso de que se utilice GoldenDict es aconsejable utilizar markup de HTML. Tabla 12 Ejemplos de markups
El archivo .TAB puede ser obtenido a través de la utilización de una o varias herraminetas de StarDict-Tools para el trabajo con diccionarios de otros formatos o del propio formato de StarDict como puede ser el caso de: babylon: Convierte el archivo fuente de un diccionario Babylon a un diccionario StarDict. bgl2txt: Convierte un archivo .bgl de un diccionario Babylon a texto plano. dsl2dict: Convierte un diccionario Lingvo a un diccionario StarDict. kingsoft: Convierte un diccionario Kingsoft a StarDict. mova: Convierte del formato MOVA al formato StarDict. oxford: Convierte un archivo de texto plano de un diccionario Oxford a uno de StarDict. stardict2txt: Convierte de StarDict a archivo.TAB.
1.1.1 Herramienta tabfile para crear el diccionario
Los diccionarios se pueden crear a partir de la herramienta tabfile de StarDict-tools, a partir de un archivo de texto plano con extensión .TAB obtiene tres archivos que componen el diccionario: .ifo es un archivo de texto plano que con tiene la información general del diccionario; .dict.dz contiene el contenido comprimido del diccionario y .idx es el archivo de índice para búsquedas rápidas y ordenamiento del diccionario. Referencias bibliográficas 75
Anexo 3. Relaciones Semánticas en WordNet
Sustantivos o Hiperonimia: Y es un hiperónimo de X si cada X es (del tipo de) un Y o sea si X es una clase de Y. o Hiponimia: Y es un hipónimo de X si cada Y es (del tipo de) un X. Si Y es un hipónimo de X, entonces X es un hiperónimo de Y. o Términos coordinados: Y es un término combinado de X, si X y Y comparten un hiperónimo y viceversa. o Holonimia: Y es un holónimo de X si X es parte de Y. o Meronimia: Y es merónimo de X si Y es una parte de X. Si Y es merónimo de X, entonces X es holónimo de Y. Verbos o Hiperonimia: El verbo Y es hiperónimo del verbo X si la actividad de X es (del tipo de) un Y. o Troponimia: El verbo Y es un tropónimo del verbo X si la actividad expresada por Y está realizando X de alguna manera. o Consecuencia lógica: El verbo Y es consecuencia lógica de X si haciendo X se debe estar haciendo Y o Términos coordinados: Dos verbos son términos coordinados si ambos comparten un hiperónimo común. Adjetivos o Sustantivos relacionados. o Similar a. o Participios de verbos. Adverbios o La raíz de los adjetivos.
A pesar de que las relaciones semánticas se aplican a todos los miembros de un synset porque comparten significado, no significa que todos sean mutuamente sinónimos, pueden existir palabras conectadas a otras relaciones léxicas como antónimos. Referencias bibliográficas 76
Anexo 4. Elementos de los mensajes de SOAP
Por lo general, los mensajes SOAP se utilizan para la conexión a servicios e invocación de métodos remotos, aunque pueden utilizarse de otras formas. Se pueden distinguir dos tipos de mensajes según el contenido:
Orientados al documento: Contienen cualquier contenido que se quiera enviar entre aplicaciones. Orientados a RPC: Estos sirven para invocar procedimientos de forma remota, desde un punto de vista no son más que un tipo en concreto de los mensajes orientados al documento solo que en este caso la información que contiene es la necesaria para invocar un procedimiento remoto.
Dentro del mensaje SOAP se encuentran los siguientes elementos:
Ilustración 36 Composición de un mensaje SOAP
Un sobre (Envelope), que describe el mensaje, a quien va dirigido, y cómo debe ser procesado. El sobre incluye las definiciones de tipos que se usarán en el documento. Contiene una cabecera de forma opcional, y el cuerpo del mensaje. Una cabecera (Header) opcional, donde podemos incluir información sobre el mensaje. Por ejemplo, podemos especificar si el mensaje es obligatorio (debe ser Referencias bibliográficas 77
entendido de forma obligatoria por el destinatario), e indicar los actores (lugares por donde ha pasado el mensaje). El cuerpo del mensaje (Body), que contiene el mensaje en sí. En el caso de los mensajes RPC se define una convención sobre cómo debe ser este contenido, en el que se especificará el método al que se invoca y los valores que se pasan como parámetros. Puede contener un error de forma opcional. Un error (Fault) en el cuerpo del mensaje de forma opcional. Nos servirá para indicar en una respuesta SOAP que ha habido un error en el procesamiento del mensaje de petición que mandamos. El anexo (Attachment), puede contener cualquier tipo de contenido (incluido el XML). De esta forma podremos enviar cualquier tipo de contenido junto a un mensaje SOAP.
Referencias bibliográficas
2015. Ubuntu Documentation [Online]. Available: https://help.ubuntu.com/community/vsftpd. ABAITUA, J. Memorias de traducción en TMX compartidas por Internet. Tradumática, 2001. ANICA, V. N. 2014. Free CAT tools as an alternative to commercial software: OmegaT. CASEY KOCHMER, E. F. 2002. JSP™ and XML Integrating XML and Web Services in Your JSP™ Application, Addison Wesley. CHRIS A. MATTMANN, J. L. Z. 2012. Tika in Action, Manning Publication Co. D. VADIM PAZ MADRID GORELOW, D. D. Á. F. Z., DR. D. CARLOS G. FIGUEROLA, DR. D. JOSÉ LUIS ALONSO BERROCAL. 2007. Librerías Lucene y dotLucene para Recuperación de Información. Estudio y desarrollo de casos prácticos. Informe Técnico, Universidad de Salamanca. DING, H., QUAN, L. & QI, H. The Chinese-English bilingual sentence alignment based on length. Asian Language Processing (IALP), 2011 International Conference on, 2011. IEEE, 201-204. ENTRUP, B. 2015. (German) Language Processing for Lucene. Natural Language Processing and Information Systems. Springer. ERIK HATCHER, O. G., MICHEAEL MCCANDLESS 2009. Lucene in Action. Referencias bibliográficas 78
F.DARWIN, I. 2014. Java Cookbook, O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472., O’Reilly Media. FELLBAUM, C. 1998. WordNet, Wiley Online Library. FLÓREZ, S. & ALCINA, A. 2011. Catálogo de software libre para la traducción. Tradumàtica: traducció i tecnologies de la informació i la comunicació, 57-73. GÓMEZ, J. 2001. Una guía al TMX. Tradumática, 11. GONCALVES, A. 2010. Beginning Java EE 7, Apress. GUOHUA, B. K. G. 2009. STUDY AND APPLICATION OF VERTICAL SEARCH ENGINE BASED ON LUCENE AND HERITRIX [J]. Computer Applications and Software, 1, 078. GUTIÉRREZ, J. D. Las memorias de traducción [Online]. HEFFELFINGER, D. R. 2014. Java EE 7 with GlassFish 4 Application Server. A practical guide to install and configure the GlassFish 4 application server and develop Java EE 7 applications to be deployed to this server, Livery Place 35 Livery Street Birmingham B3 2PB, UK., Packt Publishing Ltd. JACKSON, A. N. 2012. Formats over time: Exploring UK web history. arXiv preprint arXiv:1210.1714. LEONARD RICHARDSON, S. R. 2007. O'Reily RESTful Web Services, 1005 Gravenstein Highway North, Sebastopol O’Reilly Media, Inc. LERTSUKSAKDA, R., NETISOPAKUL, P. & PASUPA, K. Thai sentiment terms construction using the Hourglass of Emotions. Knowledge and Smart Technology (KST), 2014 6th International Conference on, 2014. IEEE, 46-50. LIANG, Y., CHANG, D., HUANG, Y., HU, S., SONG, R. & SUN, D. 2015. Exploration and Fulfillment of Search Engine in Economic Model Resource Platform Subsystem Based on Lucene Search Engine. LISS 2013. Springer. LIPPERT, S. K. & GOVINDARAJULU, C. 2015. Technological, organizational, and environmental antecedents to web services adoption. Communications of the IIMA, 6, 14. M.KOPF, M. 2004. Linux fucus.org [Online]. Available: http://www.linuxfocus.org/English/July2004/article341.shtml. MANCHADO, D. S. 2010. Estudio del servidor de aplicaciones Glassfish y de las aplicaciones J2EE. Universidad Autónoma de Barcelona. MARSET, R. N. 2006-07. REST vs Web Services. MILLER, G. A. 1995. WordNet: a lexical database for English. Communications of the ACM, 38, 39-41. Referencias bibliográficas 79
MILLER, G. A., BECKWITH, R., FELLBAUM, C., GROSS, D. & MILLER, K. J. 1990. Introduction to wordnet: An on-line lexical database*. International journal of lexicography, 3, 235-244. MINCETUR 2010. Guía de requesitos sanitarios y fitosanitarios para exportar alimentos a la Unión Europea. In: MINISTERIO DE COMERCIO EXTERIOR Y TURISMO, C. D. P. P. L. E. Y. E. T. (ed.). MOHR, G., STACK, M., RNITOVIC, I., AVERY, D. & KIMPTON, M. Introduction to heritrix. 4th International Web Archiving Workshop, 2004. ODRIOZOLA, J. K. A., RUBIO, A. C. & UNANUE, R. M. 1997. Segmentación de corpus paralelos para memorias de traducción. PAULINE CASTIAU, O. H., ELENA VELASCO QUINTANA. Herramientas de traducción asistida por ordenador: Las memorias de traducción. 2011. POPOV, D. 2006. Learning Foreign Languages with jVLT and StarDict. Tux Magazine, 19- 22. RODRÍGUEZ, J. A. 2004. La estructura de los documentos en el ámbito de recuperación de informacion: propuestas para su compresión, indexación y recuperacion. Doctoral, Universidad de Valladolid. ROMAN, D., KOPECKÝ, J., VITVAR, T., DOMINGUE, J. & FENSEL, D. 2015. WSMO- Lite and hRESTS: Lightweight semantic annotations for Web services and RESTful APIs. Web Semantics: Science, Services and Agents on the World Wide Web, 31, 39- 58. SÁNCHEZ, R. L. 2014. Guía Básica de software para traductores, Locked Bag 58, North Ryde, NSW 1670, USA. SAUBIEDET, J. Indices y Resolucion de Consultas. Técnicas para indexar y resolver consultas sobre distintas colecciones de datos., Universidad de Buenos Aires. TITTLE, D. 2011. The Wonders of Modern Search Technology. YOUNG, H. 1988. Glosario ALA de bibliotecología y ciencias de la información.