Índice de contenido. Proyecto final de carrera: Ivan Salazar Ruiz

Transcripción

1 Índice de contenido 1.- INTRODUCCION ANTECEDENTES/CONTEXTO Redes semanticas Web semantica y web Google, su política y sus apis DOCUMENTO OBJETIVOS DE PROYECTO (DOP): Objetivos: Alcance: Procesos: Alcance del proyecto: Diagrama de estructura de descomposición del trabajo (EDT): Método de Trabajo: Proceso Unificado de Desarrollo (PUD): Recursos Humanos: Recursos Materiales: Planificación temporal: Lista de entregas: Diagramas de Gantt: Plan de contingencia: Factibilidad: DESARROLLO DEL SISTEMA DE INFORMACIÓN (SI): Captura de requisitos: Caso de uso: Modelo de Dominio Analisis Caso de uso Obtener Traducción: Contrato Arquitectura del sistema: Eleccion tecnologica Php Perl Phyton Solucion tecnologica Perl: Apache Phpmyadmin Mysql Diseño Implementacion PRUEBAS Tipos de pruebas Proceso de implantación GESTION Primera iteración Segunda Iteración Tercera Iteración

2 6.4 Cuarta Iteración Quinta Iteración Comparativa Total MEJORAS FUTURAS CONCLUSIONES BIBLIOGRAFIA GLOSARIO DE TERMINOS...93 ANEXO 1 Encuestas Opiniones de usuarios. Lo bueno y lo mejorable para el futuro...97 ANEXO 2 Videopresentacion del proyecto

3 ÍNDICE DE FIGURAS Figura 2.1: Ejemplo de red semántica...6 Tabla 2.2. Muestra el numero de palabras, synsets y sentidos...9 Tabla 2.3. Muestra la información polisemica que contiene...9 Figura 2.4. Arquitectura global de la base de datos de EWN...10 Figura 2.5. Resultado obtenido por la interfaz de consulta al Wordnet en su versión actual Figura 2.6. Resultado obtenido por la interfaz de consulta al Visual Thesaurus...15 Figura 2.7. Representación de una consulta en la interfaz Treebolic...16 Figura 2.8: Resultado obtenido por la interfaz de consulta WEI...17 Figura 2.9. Muestra las APIs de google disponibles en Figura 3.1: Diagrama de estructura de descomposición del trabajo...30 Figura 3.2. Diagrama de Gantt que muestra la planificación temporal de la primera iteracion...36 Figura 3.3. Diagrama de Gantt que muestra la planificación temporal de la segunda iteracion. 37 Figura 3.4. Diagrama de Gantt que muestra la planificación temporal de la tercera iteracion...38 Figura 3.5. Diagrama de Gantt que muestra la planificación temporal de la cuarta iteracion...39 Figura 3.6. Diagrama de Gantt que muestra la planificación temporal de la quinta iteracion Figura 4.0. Modelo de dominio...46 Figura Arquitectura Cliente/Servidor...48 Figura 4.2. Diagrama de secuencia...58 Figura 4.3. Resultados de consultar un termino en el MCR...59 Figura 4.4. Muestra el lugar donde nos aparece la traducción proporcionada por el Google Translate...60 Figura 4.5. Muestra como tras pulsar el botón Take this la definición editada por nosotros aparece en el campo Gloss...60 Figura 4.6. Muestra el botón que tenemos que pulsar para guardar la definición ( Update variant )...61 Figura 4.7. Muestra el mensaje que nos indica que se ha guardado correctamente la definición..62 Figura 4.8. Muestra como la definición se ha guardado correctamente en el sistema...62 Figura 6.1. Comparativa de las horas estimadas en la planificación del análisis y las horas reales que hemos invertido en el análisis de la Iteración Figura 6.2. Comparativa de las horas estimadas en la planificación de la gestión y las horas reales que hemos invertido en la gestión en la Iteración Figura 6.3. Comparativa de las horas estimadas en la planificación de las reuniones y las horas reales que hemos invertido en las reuniones en la Iteración Figura 6.4. Comparativa de las horas estimadas en la planificación del análisis y las horas reales que hemos invertido en el análisis de la Iteración Figura 6.5. Comparativa de las horas estimadas en la planificación del desarrollo técnico y las horas reales que hemos invertido en el desarrollo técnico en la Iteración Figura 6.6. Comparativa de las horas estimadas en la planificación de las reuniones y las horas reales que hemos invertido en las reuniones en la Iteración Figura 6.7. Comparativa de las horas estimadas en la planificación del desarrollo técnico y las horas reales que hemos invertido en el desarrollo técnico de la Iteración Figura 6.8. Comparativa de las horas estimadas en la planificación de la formación y las reuniones y las horas reales que hemos invertido en esta Iteración Figura 6.9. Comparativa de las horas estimadas en la planificación del desarrollo técnico y las horas reales que hemos invertido en el desarrollo técnico en la Iteración

4 Figura Comparativa de las horas estimadas en la planificación de las reuniones y las horas reales que hemos invertido en las reuniones en la Iteración Figura Comparativa de las horas estimadas en la planificación de la gestión y las horas reales que hemos invertido en la gestión en la Iteración Figura Comparativa de las horas estimadas en la planificación del desarrollo técnico y las horas reales que hemos invertido en el desarrollo técnico en la Iteración Figura Comparativa de las horas estimadas en la planificación de las reuniones y la formación y las horas reales que hemos invertido en la Iteración Figura Comparativa de las horas estimadas en la planificación de la formación y de las reuniones y las horas reales que hemos invertido en Total...79 Figura Comparativa de las horas estimadas en la planificación de la elaboración de la memoria y de la presentación y las horas reales que hemos invertido en Total...80 Figura Comparativa de las horas estimadas en la planificación de la integración y de las pruebas y las horas reales que hemos invertido en Total...81 Figura Comparativa de las horas estimadas en la planificación del análisis y las horas reales que hemos invertido en Total...82 Figura Comparativa de las horas estimadas en la planificación de la implementacion y las horas reales que hemos invertido en Total...83 Para ver la videopresentación del proyecto fin de carrera pulsar en el siguiente enlace: 4

5 Para ver la videopresentación del proyecto fin de carrera pulsar en el siguiente enlace: INTRODUCCION Este proyecto de final de carrera se enmarca dentro del área de investigación de la Inteligencia Artificial, más concretamente, de la semántica en el Lenguaje Natural. El MCR (Multilingüal Central Repository) es un repositorio multilingüe compuesto por distintos WordNets (bases de datos léxicas ), enriquecido con relaciones semánticas y ontologías. Se pretende añadirle una nueva funcionalidad que nos permita realizar traducciones automáticas utilizando las APIs de google translate. Este proyecto tiene una doble finalidad. Por una parte tenemos el lado formativo, que me ha permitido aprender más en profundidad la utilización y las ventajas de un sistema operativo de libre distribución como linux y lenguajes orientados a la capa de presentación como son Java, JavaScript, PHP y PERL. Por otra parte, la investigación en el entorno Web me ha permitido comprobar la diversidad de opciones para desarrollar esta funcionalidad. Este proyecto de fin de carrera ha sido realizado bajo la supervisión de German Rigau Claramount (profesor del departamento de lenguajes y sistemas informáticos). 2.- ANTECEDENTES/CONTEXTO La aplicación Multilingüal Central Repository (MCR) se encuentra dentro del marco europeo del proyecto EuroWordNet (EWN) que surgió en 1994 como una iniciativa para cubrir una serie de necesidades de los usuarios para acceder a la información (sociedad de la información) en Europa. Para poder acceder al conocimiento existente en forma digital, este tendrá que estar preparado y organizado a fin de ser compartido y reutilizado. Debido a la gran cantidad de información existente, la tarea de preparación y organización del material implica un esfuerzo humano muy elevado, de ahí que se estén buscando soluciones que automaticen en la medida de lo posible los procesos. Además, el problema del acceso a la información disponible, especialmente en Internet, se ha acentuado con el aumento del número de lenguas presentes en el medio virtual: del uso casi exclusivo de la lengua inglesa se están abriendo camino otras lenguas. Para que los programas y las tareas de recuperación de información logren un porcentaje más alto de éxito tienen que dar cuenta de este nuevo ambiente multilingüe. En este ámbito se vio la necesidad de profundizar en dos lineas estrechamente relacionadas: La representación multilingüe y el tratamiento de la información. La búsqueda y la recuperación de información en un ambiente multiligüe. Cada idioma diseña su propio WordNet estructurándolo de la misma forma que el WordNet de Princeton en lo que se refiere a synsets (conjuntos de términos sinónimos) con relaciones semánticas básicas entre ellos. Cada WordNet representa un sistema único de lexicalización propio de cada idioma. Además, los WordNets están conectados con el Índice Inter-Lingual(ILI). Gracias a estas conexiones se puede, a partir de una palabra, consultar palabras similares en cualquier otro idioma. Además este índice proporciona acceso a una ontologia compartida compuesta por 63 5

6 distinciones semánticas. Esta ontología proporciona una categorización común para todos los idiomas, mientras las distinciones específicas de cada idioma quedan en cada WordNet. Actualmente existen instituciones y grupos de investigación que están desarrollando WordNets en otros idiomas (europeos y no europeos) usando la especificación de EuroWordNet. Concretamente, en el MCR se incluye el ingles y las lenguas que se hablan en el Estado español (español, euskera, gallego y catalán). Se pretende que estos WordNets sean compatibles con la especificaciones para seguir manteniendo la escalabilidad del proyecto, característica muy interesante ya que en un futuro se pretende que la información sea accesible a todos los seres humanos, independientemente de la lengua que utilicen para realizar las búsquedas. Por lo tanto, se podrán añadir a la base de datos y estar interconectadas con otros WordNets. 2.1 Redes semánticas La semántica léxica es un subcampo de la lingüística que estudia lo que denotan las palabras de una lengua (Pustejovsky, 1995). Las unidades léxicas son las palabras, que se pueden utilizar para denotar cosas en el mundo, o conceptos, así que la semántica léxica implica el significado de cada palabra individual. La semántica léxica es un área de la lingüística que cubre las teorías de la clasificación y la descomposición del significado de la palabra, las diferencias y las semejanzas en estructura semántica léxica entre diversos idiomas, y la relaciones de las mismas. En un grafo o red semántica los elementos semánticos se representan por nodos. Dos elementos semánticos entre los que se da la relación semántica que representa la red, estarán unidos mediante una línea, flecha o enlace o arista. En la figura 2.1 se puede ver un ejemplo de red semántica. En este caso, los nodos (animal, ave, mamifero,...) representan los elementos semánticos, mientras que las aristas representan las relaciones semánticas (tiene, puede, tipo_de, vuela, pone,...) Figura 2.1: Ejemplo de red semántica. 6

7 Existen diversos tipos de relaciones semánticas como la sinonimia/antonimia (relación entre sinónimos y antónimos), hiponimia,/hiperonimia (relación entre subordinados y superordinados), la meronimia/holonimia (relación entre subconjuntos y conjuntos globales), entre otras. Las redes semánticas han sido muy utilizadas en Inteligencia Artificial para representar el conocimiento. Una de las redes semánticas más conocidas es WordNet. WORDNET: Es una base de datos léxica de dominio general para el inglés que constituye actualmente uno de los recursos léxicos más utilizados en el área de PLN (Procesamiento de Lenguaje Natural). Wordnet (WN) fue creada por un grupo de psicólogos y lingüistas del Cognitive Science Laboratory de la Universidad de Princeton, como un intento de organizar la información léxica por significados, a diferencia de los diccionarios convencionales, donde esta información está organizada por la forma de las unidades léxicas. La popularidad de esta red semántica entre los investigadores que trabajan en recuperación y extracción de información, desambiguación semántica automática, búsqueda de respuestas, creación de resúmenes, etc. se debe, en primer lugar, a la información que proporciona y a su estructura sencilla; y, en segundo lugar, al hecho de ser de dominio público y gratuita. WN está estructurada como una red semántica cuyos nodos, denominados synsets (synonym sets, o conjuntos de sinónimos) constituyen su unidad básica de significado. Cada uno de ellos se compone de un conjunto de las lexicalizaciones que representan un sentido y se identifica mediante un offset (byte) y su correspondiente PoS (Part-of-Speech); que puede ser (n) para nombres, (v) para verbos, (a) para adjetivos y (r) para adverbios: #n car# #v do# #a blue# #r hard#1 La cifra que aparece después de la palabra indica el sentido que representa. Una palabra puede ser polisémica, esto es, tener varios significados. Por ejemplo: #n tree#1; representa la planta que se ramifica a través de un tallo leñoso #n tree#2; representa una estructura conceptual. También puede ser que varias palabras tengan el mismo significado, esto es, que sean sinónimas. En Wordnet están representados en el mismo synset: #n car#1, auto#1, automobile#1, machine#4, motorcar#1; representa el vehículo de cuatro ruedas. A partir de la versión 1.6 todos los synsets de WN incluyen una glosa que, a modo de las definiciones de diccionario, describe el concepto que de forma explícita está expresado por las 7

8 relaciones del synset. Por ejemplo: #n car#1; 4-wheeled motor vehicle; usually propelled by an internal combustion engine: he needs a car to get to work; Además de la información que pueden proporcionar los sinónimos (componentes del synset) y la glosa, cada synset se caracteriza y se define por las relaciones que este synset establece con los demás synsets. A continuación vamos a explicar algunas de las relaciones más importantes existentes en Wordnet. Hiperonimia: Es el término genérico usado para designar a una clase de instancias específicas. Y es un hyperónimo de X, si X es una clase de Y. Ejemplo: tree#n#1 HYPERONYM oak#n#2 Hiponimia: Es el término específico usado para designar el miembro de una clase, X es un hipónimo de Y, si X es una clase de Y. En el caso de los verbos se denomina Troponimia. Ejemplo: oak#n#2 HYPONYM tree#n#1 Antonimia: Es la relación que enlaza dos sentidos con significados opuestos. Ejemplo: love#n#1 ANTONYM_OF hate#n#1 hate#n#1 ANTONYM_OF love#n#1 Meronimia: Es la relación que se define como componente de, substancia de, o miembro de algo, X es merónimo de Y si X es parte de Y. Ejemplo: car#n#1 HAS_PART window#n#2 milk#n#1 HAS_SUBSTANCE protein#n#1 family#n#1 HAS_MEMBER child#n#2 Holonimia: Es la relación contraria a la meronimia, Y es holónimo de X si X es una parte de Y. Ejemplo: window#n#2 PART_OF car#n#1 protein#n#1 SUBSTANCE_OF milk#n#1 child#n#2 MEMBER_OF family#n#2 El conocimiento de Wordnet va aumentando en cada una de sus versiones según se van incluyendo nuevos synsets. Vamos a mostrar unas tablas que reflejan en que estado se encuentra el WordNet en su versión

9 POS Noun Verb Adjective Adverb Totals Unique string Synsets Total Word-Sense Pairs Tabla 2.2. Muestra el numero de palabras, synsets y sentidos POS Monosemous Polysemous Polysemous Words and Senses Words Senses Noun Verb Adjective Adverb Totals Tabla 2.3. Muestra la información polisemica que contiene EUROWORDNET: El éxito de WN impulsó la creación de wordnets para otros idiomas. El proyecto más destacado en esta línea es EuroWordNet2 (Vossen, 1998). EuroWordNet (EWN) es una extensión multilingüe de WN, compuesta por bases de datos léxicas para 8 idiomas (inglés, holandés, español, italiano, francés, alemán, checo y estonio) y un índice general de conceptos, InterLingual Index (Índice InterLingua), que permite conectar entre sí las unidades consideradas equivalentes en su significado en bases de datos de lenguas diferentes, permitiendo así pasar de términos de un idioma a términos de otro. Siguiendo las propuestas de EWN, empezaron a desarrollarse wordnets para idiomas como el catalán, euskera, portugués, griego, búlgaro, ruso y sueco. Global WordNet Organization3 actualmente coordina la creación de wordnets para otros idiomas, así como una conferencia bianual entorno a este tema. El punto de referencia para todos los wordnets locales fue WN1.5. En todos los wordnets se mantuvo la noción del synset y las relaciones semánticas básicas. Cada wordnet particular fue construido de forma separada con recursos disponibles para una lengua determinada. La conexión entre todos esos sistemas autónomos se hizo a través del Índice InterLingua (ILI, del inglés InterLingua Index). 9

10 Cada índice en el ILI es un synset con una etiqueta de categoría sintáctica, una glosa y la referencia a su origen. Los synsets de cada wordnet particular están enlazados a algún índice del ILI. De esta forma, EWN proporciona la posibilidad de ir de una lexicalización de un concepto en lengua L1 a otra lexicalización de ese mismo concepto en lengua L2. Figura 2.4. Arquitectura global de la base de datos de EWN. En la figura 2.4 se muestra un ejemplo de la arquitectura global de EWN. Se emplea el sentido drive para mostrar como se utilizan los diferentes tipos de enlaces de EWN. En este caso tenemos cuatro de los wordnets locales (ingles, holandés, italiano, español), para cada uno de ellos existe su correspondiente synset para el sentido que se está utilizando de ejemplo, en español sería conducir, en italiano guidare, en holandés rijden y en inglés drive. Estos synsets se relacionan con otros dentro de sus wordnets mediante enlaces dependientes del lenguaje (en la figura se identifican con el número romano III), por ejemplo, en el caso del español, conducir estaría conectado mediante este tipo de enlaces con transitar, cabalgar... Por otra parte cada uno de ellos tiene un enlace desde su lenguaje específico a su correspondiente registro del Indice Interlingüa (número II). De este modo, al estar los cuatro synsets conectados al mismo registro ILI, podemos saber que todos representan el mismo sentido. Además, existe otro tipo de enlace independiente del lenguaje (número I) desde este registro ILI a la información adicional que ofrecen las distintas ontologías sobre este sentido. Así, cada uno de los synsets de los cuatro wordnets del ejemplo, adquieren esas características representadas en Domain-Ontology y Top-Ontology, sin la necesidad de tener un 10

11 enlace a las mismas. PROYECTO MEANING: Representa uno de los proyectos más ambiciosos relacionados con EWN y WN. Su objetivos principal consiste en la adquisición automática del conocimiento lingüístico (en especial, del conocimiento semántico o conceptual) a partir de la Web y construcción de recursos léxicos multilingües que sirvan de soporte para una desambiguación semántica automática más eficiente, ya que los recursos léxicos existentes no proporcionan toda la información necesaria para poder desambiguar con éxito la semántica de los textos. Más concretamente, el proyecto se centró en los wordnets para 5 idiomas europeos: inglés, italiano, español, catalán y euskera. Se pretendía enriquecer su estructura con nueva información léxicosemántica extraída automáticamente de la web. Como resultado de este trabajo se generaron varios resultados: Conjunto de herramientas para la adquisición automática de conocimiento semántico a partir de grandes colecciones de textos disponibles en la web. Herramientas para el enriquecimiento automático de EWN con el conocimiento que una el nivel sintáctico con el semántico: aplicaciones para la adquisición de la terminología perteneciente a un dominio específico, la identificación y la extracción de sentidos nuevos y de agrupaciones de sentidos relacionados, la adquisición de etiquetas de dominio, de alternancias de diátesis, marcos de subcategorización, restricciones selectivas y de algunas relaciones léxico-semánticas específicas. Un sistema de desambiguación semántica automática para las lenguas incluidas en el proyecto basado en algoritmos de aprendizaje automático capaces de modelar el comportamiento de cada sentido a partir de textos semánticamente anotados y textos no anotados. El Repositorio Central Multilingüe (MCR), fue desarrollado como parte de este proyecto. Su principal objetivo fue el de mantener la compatibilidad entre los diferentes wordnets y poder exportar, de forma consistente, el conocimiento adquirido para un idioma en particular al resto. Además de construir el MCR, se desarrolló todo un conjunto de procesadores lingüísticos para cada una de las lenguas contempladas en el proyecto: identificadores de lengua, tokenizadores, etiquetadores de parte de oración y analizadors sintácticos. 11

12 MULTILINGÜAL CENTRAL REPOSITORY (MCR): El MCR (Multilingual Central Repository) e ell resultado de la fusión de distintos recursos (diversas versiones de WordNet (WN1.5, WN1.6, WN1.7, WN1.7.1, WN2.0, WN2.1, WN3.0), ontologías y bases del conocimiento) que se llevó a cabo en el proyecto MEANING. La versión final del Repositorio Central Multilingüe (MCR) está integrada por wordnets para cinco idiomas diferentes (inglés, italiano, español, catalán y euskera) y contiene relaciones semánticas únicas entre conceptos (ILI-records) (lo que supera en un orden de magnitud el número de relaciones incluido en WN1.6). El MCR está enriquecido también con propiedades semánticas extraídas de otras fuentes, como WordNet Domains6, Top Concept Ontology7 o SUMO8. Domain-Ontology o WordNet Domains es una ontología que utiliza alrededor de 200 etiquetas obtenidas de Dewey Decimal Classification9 para clasificar cada synset. TCO (Top Concept Ontology) es una ontología creada para codificar las relaciones léxicosemánticas de manera uniforme. SUMO (Suggested Upper Merged Ontology) es una de las ontología utilizadas en investigación y aplicaciones de búsqueda, lingüística y razonamiento. Para poder interactuar con el MCR se desarrolló WEI (Web Eurowordnet Interface) que es una interfaz web que permite realizar consultas al MCR. INTERFACES WEB: Para este proyecto además de lo mencionado anteriormente, hemos estudiado las interfaces Web disponibles actualmente para consultar Wordnets. WORDNET: Sin ir más lejos tenemos el ejemplo de WordNet11, que dispone de una interfaz on-line para poder consultar su base de datos. Esta web esta enteramente desarrollada en Perl y nos permite buscar una palabra en inglés y además nos permite seleccionar las opciones que queremos que nos muestre de dicha palabra. Entre las opciones tenemos la posibilidad de mostrar u ocultar los ejemplos o de mostrar u ocultar la definición. En la figura 2.5, podemos ver una imagen de dicha interfaz. En ella aparece el resultado obtenido tras indicarle que la palabra a buscar es bank, y dejando todos los valores de visualización por defecto, esto es, que nos muestre las glosas y los ejemplos. 12

13 F igura 2.5. Resultado obtenido por la interfaz de consulta al Wordnet en su versión actual 3.1. Esta interfaz nos permite una vez mostrada la solución, movernos por las distintas relaciones conectadas con la palabra que hemos buscado. Se podría decir que es un grafo dinámico donde podemos acceder a los distintos nodos. 13

14 VISUAL THESAURUS: Otro proyecto interesante es Visual Thesaurus12, producto creado por ThinkMap. Este producto se puede adquirir previo pago, aunque dispone de una demostración en la que se puede comprobar su funcionamiento. La interfaz es un applet de Java, por lo que se requiere de la máquina virtual para ser vista correctamente. Una vez que se carga, podemos comenzar la búsqueda. Esta interfaz es multilingüe, esto es, podemos realizar la búsqueda de palabras en distintos idiomas entre los que están el inglés, el holandés, el italiano, el francés, el alemán y el español. Una vez que realizamos la búsqueda, nos muestra un árbol con la palabra y sus relaciones. Es un árbol dinámico, esto es, nos permite seleccionar cualquiera de los nodos, mostrándonos entonces las relaciones del nuevo nodo. En la figura 2.6 se muestra el resultado en forma de árbol que proporciona la interfaz Visual Thesaurus cuando el término a buscar es bank y le pedimos que nos muestre los resultados en los idiomas inglés y español. 14

15 Figura 2.6. Resultado obtenido por la interfaz de consulta al Visual Thesaurus. TREEBOLIC: Treebolic13 es un applet de Java cuyo objetivo es mostrar una representación hiperbólica de los datos jerárquicos. Es un árbol dinámico que permite moverse a través de los distintos nodos. En este caso aunque se pueda visualizar en un navegador Web, hay que descargárselo previamente y tiene licencia GNU (General Public License). En la figura 2.7 podemos ver un ejemplo de la interfaz de consulta Treebolic. Como podemos ver, la búsqueda se ha hecho utilizando la palabra net. 15

16 Figura 2.7. Representación de una consulta en la interfaz Treebolic. 16

17 WEI (Web Eurowordnet Interface): WEI14 es una interfaz multilingüe creada dentro del proyecto Meaning, para poder acceder al Multilingual Central Repository (MCR). La parte del cliente está desarrollada en el lenguaje de programación Java, por lo que es necesario como precondición, tener instalada la máquina virtual de Java para su correcta visualización. La parte del servidor está desarrollada en el lenguaje de programación Perl. En la figura 2.8 podemos ver un ejemplo del resultado proporcionado por la interfaz de consulta WEI. Hemos preguntado por la palabra car y hemos dejado el resto de valores por defecto. Figura 2.8: Resultado obtenido por la interfaz de consulta WEI. 17

18 DEB (Dictionary Editor and Browser): DEB es un proyecto creado en la Universidad de Masaryk, en la República Checa. Dicho proyecto, esta implementado en Ruby y la comunicación Cliente/Servidor se realiza mediante JSON. JSON, acrónimo de JavaScript Object Notation, es un formato ligero para el intercambio de datos. JSON es un subconjunto de la notación literal de objetos de JavaScript que no requiere el uso de XML. Para poder utilizar el diccionario, es necesario descargarse la parte del cliente y se requiere como requisito tener instalado el navegador Mozilla Firefox. Dicha interfaz, además está conectado a un analizador morfológico Checo y a páginas Web como Google y Answers.com. También dispone de un sistema de información geográfica. También se permite la reimplementación de la red semántica con el editor llamado VisDic16. OTROS: Además de estos, existen interfaces desarrolladas para WordNet en otros lenguajes de programación. Todos ellos los podemos encontrar en la página de WordNet accediendo a la sección de Related Projects, en el apartado de Web Interfaces. Por ejemplo: Dictionary17 (WordNet 3.0 Interface) Grokitbetter18 (Visual representation of WordNet 2.1) Wordsworth 1.0 Vocabulary Wizard19 (a web interface for WordNet 2.0) Wordnet 3.0 Vocabulary Helper20 ( one-touch interface) Wordnet 3.0, a lexical database for the English language21 (Web interface) Entre paréntesis está el nombre que en la página de WordNet tienen los enlaces a estas páginas. Todos ellos permiten introducir una palabra y muestran las distintas relaciones que dicha palabra posee y permiten moverse por los distintos nodos. Nuestro objetivo será, basándonos en estos antecedentes, realizar una interfaz avanzada para el Multilingual Central Repository, pudiendo así en un futuro sustituir la interfaz actual desarrollada en Java por otra interfaz que no requiera Java, esto es, por una que no necesite cargar la máquina virtual de Java. 18

19 ASOCIACION MUNDIAL DEL WORDNET: La Asociación Mundial del WordNet es una organización pública, gratuita y sin ánimo de lucro que proporciona una plataforma para discutir, compartir y conectar wordnets para todos los idiomas del mundo. Los objetivos de la asociación son: 1. Establecer centros de distribución para la difusión de las publicaciones de la asociación y los materiales informativos: Para promover la cooperación y el intercambio de información los profesionales que usan los wordnets. Para proporcionar información sobre wordnets al público en general. 2. Promover la estandarización de las especificaciones de los wordnets para todos los idiomas del mundo, incluyendo: la estandarización de la Inter-Lingual-Índice (ILI) para la interconexión de los wordnets de diferentes idiomas, como un índice universal de significado el desarrollo de una representación común de los datos de los WordNets. 3. Para promover el desarrollo de los corpus etiquetados con sentidos en todos los idiomas vinculados. 4. Para promover el intercambio y la transferencia de datos, software y especificaciones. 5. Para promover el desarrollo de directrices y metodologías para la construcción de wordnets en nuevos idiomas 6. Para promover el desarrollo de criterios explícitos y definiciones para la verificación de las relaciones en todos los idiomas. 7. Para promover el desarrollo de la comprobación consistente, la comparación y evaluación de los módulos 8. Promover la investigación en la adecuación de los modelos psicológicos del léxicon mental Podemos ver en esta dirección todos los WordNet del mundo: ( wordnet_table.htm ) 19

20 2.2- Web semántica y web 3.0 Hemos introducido este apartado porque creemos que es importante destacar una serie de características que tendrá la web semántica y como se relaciona con el MCR. En un futuro herramientas como el MCR serán utilizadas por la web semántica para solucionar los diferentes problemas semánticos a los que nos enfrentamos y los problemas relacionados con el multilingüismo. Para ello es conveniente empezar hablando de la web actual (web 2.0) para entender mejor porque surge la necesidad de evolución de la actual Web a otra mas rica semanticamente hablando (web semántica y web 3.0) QUE ES LA WEB 2.0 Y PORQUE SURGE LA WEB 3.0 WEB 2.0 El termino Web 2.0 (2004 actualidad) está comúnmente asociado con aplicaciones web que facilitan el compartir información, la interoperabilidad, el diseño centrado en el usuario y la colaboración en la World Wide Web. Ejemplos de la Web 2.0 son las comunidades web, los servicios web, las aplicaciones Web, los servicios de red social, los servicios de alojamiento de videos, las wikis, blogs, mashups y folcsonomías. Ya no es un contenido estático en el que una persona expone y el resto leen, sino que hay mucha mas participación y por lo tanto mas enriquecimiento en la información a la que accedemos. Podemos discutir e intercambiar información en grupos interdisciplinares que enriquecen el conocimiento de todos los que participan. El hecho de que la Web 2.0 es cualitativamente diferente de las tecnologías web anteriores ha sido cuestionado por el creador de la World Wide Web Tim Berners-Lee, quien calificó al término como "tan sólo una jerga"- precisamente porque tenía la intención de que la Web incorporase estos valores en el primer lugar. Es decir, tecnológicamente no hubo cambios significativos, los cambios se produjeron en el uso que los usuarios empezaron a hacer de la Web. 20

21 De hecho, voy a exponer una serie de grandes logros obtenidos por la colaboración de la gente (facilitada gracias a la web 2.0). La Wikipedia es un gran logro ya que es una enciclopedia muy completa (tiene hasta mas termino que las enciclopedias físicas, no es de extrañar porque se van actualizando los términos según van surgiendo y no hay que esperar a nuevas ediciones como las enciclopedias físicas) y también ayuda a la extensión del conocimiento a diferentes idiomas (actualmente hay mas de 37 lenguas que tienen mas de artículos). Se ha conseguido el desarrollo de sistemas operativos/herramientas (Linux). En el ámbito del ocio virtual también se ha conseguido el desarrollo de videojuegos que dependen casi exclusivamente de la interactuación de diferentes personas de lugares muy diferentes del mundo (second life, world of warcraft). Democratización de la información a través de artículos escritos por los ciudadanos que no tienen que seguir ninguna linea editorial (oh my news). Lo curioso de este fenómeno, es que la gente no participa en estos proyectos para enriquecerse, sino que en la mayoría de los casos lo hace para socializarse, para que se les reconozca por su trabajo o por diversión. El fruto de la web 2.0 es que se fomenta la inteligencia colectiva y la inteligencia colaborativa que parten del principio de que cada persona sabe sobre algo, por tanto nadie tiene el conocimiento absoluto. Para ello resulta fundamental la inclusión y participación de los conocimientos de todas las personas. Dado que el acceso a Internet en todo el mundo ha crecido de un modo espectacular (en 2000 había 250 millones de usuarios ahora en 2011 la cifra se ha multiplicado por ocho llegando a los 1987 millones de usuarios) nos hemos encontrado el problema del desbordamiento de la información, hay un exceso de información. De este problema surge la Web Semántica. 21

22 WEB SEMANTICA Y WEB 3.0 Una definición de web semántica sería: La web semántica es la "Web de los datos". Se basa en la idea de añadir metadatos semánticos y ontológicos a la World Wide Web. Esas informaciones adicionales (que describen el contenido, el significado y la relación de los datos) se deben proporcionar de manera formal, para que así sea posible evaluarlas automáticamente por máquinas de procesamiento. El objetivo es mejorar Internet ampliando el intercambio de información entre los sistemas informáticos usando "agentes inteligentes". Agentes inteligentes son programas en las computadoras que intercambian información sin operadores humanos. El fin es lograr que las maquinas puedan entender y utilizar lo que la Web contiene. Los problemas que nos encontramos a la hora de desarrollar la web semántica es la dificultad de transformar toda la cantidad de información que hay en la red, a la que habría que darle significado para que fuera web semántica Se esta trabajando en soluciones para el problema de dar formato a los documentos, pero al ser inmensa la cantidad de documentos existentes, se esta trabajando en automatizar el proceso a través de software. También se pretende que la nueva información este dotada de estructura a través de odontologías, hacer los recursos procesables, es decir, procesables y reutilizables Componentes básicos RDF, SPARQL, OWL, ONTOLOGIAS Agentes inteligentes que se constituyen como entidades software para recoger procesar y filtrar la información Firmas digitales para garantizar la seguridad y por tanto la confianza ya que se podrían llegar (PP falta una a ) a hacer acciones como comprar un vuelo con nuestra tarjeta de crédito Dentro de todas las aplicaciones que pueden surgir cuando se desarrolle la web semántica, una que encontramos especialmente interesante, son los buscadores semánticos. Buscadores semánticos: interpretan frases en contextos a través de un lenguaje natural, nos facilita la jerarquización de los resultados y reconoce las palabras que se introducen en la búsqueda. Ventajas: encontramos resultados organizados mas afines que solucionan nuestros problemas. En el desarrollo de la Web Semántica y la Web 3.0, el MCR y los diferentes WordNets van a jugar un papel muy importante como herramienta imprescindible para el procesamiento del conocimiento en los diferentes idiomas. 22

23 El MCR, al ser un repositorio multilingüe formado por bases de datos léxicas escritas en diferentes idiomas y estructurados como redes semánticas, nos va a permitir en un futuro que la web recurra a estos repositorios para encontrar el significado semántico de nuestras búsquedas. De hecho, el MCR esta formado por diferentes idiomas relacionados entre si, por lo tanto, va a ser indiferente en que idioma hagamos la búsqueda. 2.3 Google, su política y sus apis En este apartado vamos a intentar explicar en que consiste básicamente la política de Google y el motivo que les lleva a proporcionar de forma gratuita a los usuarios de Internet la gran cantidad de aplicaciones de indudable calidad que han desarrollado. En un primer lugar vamos a hablar de las APIs, ya que en nuestro proyecto hemos utilizado la API de Google Transalte y creemos que son importantes (y parece ser que para Google también viendo la cantidad de APIs que tienen disponibles -ver figura 2.9-). Figura 2.9. Muestra las APIs de google disponibles en Una interfaz de programación de aplicaciones o API (del inglés Application Programming Interface) es el conjunto de funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción. Son usados generalmente en las bibliotecas. 23

24 Una interfaz de programación representa una interfaz de comunicación entre componentes de software. Se trata del conjunto de llamadas a ciertas bibliotecas que ofrecen acceso a ciertos servicios desde los procesos y representa un método para conseguir abstracción en la programación, generalmente (aunque no necesariamente) entre los niveles o capas inferiores y los superiores del software. Uno de los principales propósitos de una API consiste en proporcionar un conjunto de funciones de uso general, por ejemplo, para dibujar ventanas o iconos en la pantalla. De esta forma, los programadores se benefician de las ventajas de la API haciendo uso de su funcionalidad, evitándose el trabajo de programar todo desde el principio. Las APIs asimismo son abstractas: el software que proporciona una cierta API generalmente es llamado la implementación de esa API. Google también nos ofrece Google Apps. Por supuesto, como la mayoría de sus aplicaciones, completamente gratis; aunque también existe una versión de pago especialmente diseñada para clientes empresariales y grandes organizaciones multinacionales. Google Apps ofrece herramientas eficaces para la manipulación, gestión y personalización de utilidades para dominios o nombres de Internet. Es decir, Google Apps te permite gestionar el correo electrónico de tu dominio (a través de Gmail), mensajería instantánea entre miembros de tu organización o red (Google Talk), calendario en línea (Google Calendar), edición de Documentos también en línea (Google Docs) y creación de sitios web profesionales (Google Sites). Google Apps ofrece tres planes distintos de servicio, enfocados precisamente a tres principales tipos de clientes. Así mismo, dentro de cada plan se ofrecen diferentes escalas del servicio: Empresas y empleados. Estándar (Gratuita) y Premier ( de Pago). Centros Docentes y Estudiantes. Estándar (Gratuita), Premier (de Pago) y Educación (Sólo para instituciones estudiantiles sin ánimo de lucro). Organizaciones y Miembros. Mismos planes que la Edición de Centros Docentes y Estudiantiles. Tras conocer las aplicaciones que Google pone a disposición de los clientes la preguntas que nos surgen son como pueden mantener la viabilidad del negocio si las aplicaciones las ofrece de forma gratuita a los usuarios? como se ha convertido en una de las compañías mas poderosas e influyentes del siglo XXI? Una de las respuestas mas convincentes es que todo lo que Google ofrece gratis, en realidad, siempre lo paga alguien: el anunciante. Su creciente dominio de Internet se ha construido gracias a su negocio de publicidad contextual (Adsense y Adwords) que le permite vender anuncios cada vez que se realiza una búsqueda o se escribe un correo. Google detecta las palabras clave y las redirige hacia sus anuncios. Su bocado cada vez mayor del pastel publicitario amenaza con la ruina a miles de publicaciones (incluyendo las online) que deben ofrecer sus contenidos gratis a través de la Red para ser visibles y comprueban indefensos cómo es Google quien se beneficia principalmente de los mismos. 24

25 Se podría pensar que Google es una empresa dispuesta a regalar toda esta tecnología y hacerla libre y no se piensa en la persistente y silenciosa recolección de datos que Google realiza para captar nuestro perfil y poder ofrecérselo a los anunciantes. Vamos a explicar brevemente en que consiste el negocio de la publicidad contextual que utiliza Google AdSense permite a los webmasters unirse a este sistema para activar textos e imágenes publicitarias en sus páginas web y así obtener ingresos extras. Estos anuncios están administrados por Google y generan ingresos basándose en los clicks de los visitantes de la página y en las visualizaciones de la misma (impresiones). Google utiliza su tecnología de búsqueda para incrustar anuncios según el contenido de la página web que se está visitando, la localización geográfica del usuario (mediante la IP) y otros datos como historia de búsqueda previa en Google o las páginas visitadas por el usuario, sus cookies, duración de la sesión, sistema operativo, browser utilizado, etc. Google AdWords es un método para hacer publicidad patrocinada. Cuenta con numerosos clientes en sitios web de todo tipo y de todas partes del mundo. Son anuncios que se muestran de forma relevante en los resultados de la búsqueda del usuario. Google cobra al cliente por cada clic hecho sobre su anuncio. Además de en el buscador Google, AdWords también aparece en las webs patrocinadas por AdSense, si el contenido de las mismas se relaciona con el de la web del cliente, y en Gmail. AdWords es la principal fuente de facturación de Google y constituye un método de publicidad dinámico para el cliente, puesto que el costo será "un espejo" del tráfico ganado en la web gracias a Google. De hecho se ha llegado a hablar del ecosistema de Google. Suena a ecología pero, en realidad, es un eufemismo que quiere decir controlar el proceso de principio a fin. Google aspira a que los usuarios tengan su buscador como página de inicio cuando entran en Internet, ya sea desde el portátil, equipado con Chrome OS, o desde el móvil, a través de su sistema operativo Android. Una vez en la Red, navegarán con Chrome, verán vídeos en YouTube, chatearán con el Gmail o buscarán una calle con Google Maps. Y al hacer todo eso estarán dando una preciosa información a los anunciantes de los que vive Google, cuyo 97% de los ingresos viene de la publicidad. Si hacemos cuentas, en realidad Google solo gana unas cuantas fracciones de centimo por cada visitante que usa sus servicios, pero si tomamos en cuenta que google maneja millones de visitantes al dia (practicamente todo el planeta lo visita diariamente), entonces es claro ver el por que es una empresa tan grande y poderosa. --- preguntarle a german porque creen que ofrecen las APIs, yo después de todo lo expuesto anteriormente la única posibilidad que se me ocurre es para crear dependencia de sus productos, pero no se si poner eso o poner directamente que no se sabe porque las dan gratuitamente

26 26

27 3.- DOCUMENTO OBJETIVOS DE PROYECTO (DOP): Objetivos: El objetivo de este proyecto es añadir una nueva funcionalidad al MCR (Multilingüal Central Repository). La funcionalidad que tenemos que desarrollar tiene que ser capaz de obtener la definición en ingles que nos ofrece el MCR y tras hacer una consulta al Google Translate a través de su API, nos devuelva la definición en castellano para poder editarla (corrigiendo los errores que puede cometer el traductor automático) y guardarla correctamente en la base de datos. --- preguntar a german si pongo esto de la escalabilidad---se tiene que mantener la escalabilidad del proyecto, por lo tanto, se implementara permitiendo que en un futuro se pueda añadir la opción de traducirlo a los diferentes idiomas que tiene el MCR tan solo haciendo una pequeña modificación en el código del programa En cuanto a los objetivos personales que queremos obtener se encuentran los siguientes: El ser capaz de llevar -y aprender a gestionar- un proyecto de estas características de principio a fin, superando las dificultades que nos plantea el sacar adelante un proyecto de esta magnitud. El formarme en tecnologías que no conozco previamente de forma autónoma, llegando a desenvolvernos con soltura para poder utilizarlas en nuestro futuro profesional Alcance: Procesos: Podemos dividir los procesos en tres categorías: los procesos tácticos, los procesos operativos y los procesos formativos. Procesos operativos: Captura de requisitos Modelo de Casos de Uso 27

28 Análisis Diagrama de Secuencia del Sistema Diseño Diseño de la funcionalidad Elección tecnológica Implementación Modificación del MCR con la nueva funcionalidad Pruebas Instalación Elaboración de la Memoria Procesos tácticos: Planificación Realización del DOP Reuniones Ordinarias Extraordinarias Control Aprobación final del proyecto Procesos formativos: Maquinas Virtuales (Concretamente Oracle VM VirtualBox) Linux (Concretamente Ubuntu) MCR CGI Perl WordNet APIs MySQL PHPmyAdmin 28

29 Alcance del proyecto: Desarrollo de un programa en el lenguaje Perl que nos permita traducir las definiciones dadas por el MCR, para ello crearemos una interfaz sencilla e intuitiva en la cual con solo pulsar un botón, nos devolverá la definición con la opción de poder ser modificada y se nos ofrecerá la posibilidad de guardar esa definición correcta en la base de datos. Debemos integrar este nuevo programa en el código del MCR sin que se modifiquen el resto de funcionalidades que posee la aplicación. También es imprescindible que las interfaces sean muy sencillas e intuitivas ya que la aplicación esta pensada para el uso de un publico general, es decir, no tienen porque tener conocimientos informáticos. Como el MCR es una aplicación que esta en constante mejora, es decir, se están añadiendo nuevas funcionalidades constantemente, nuestro programa debe permitir mejoras por futuros desarrolladores. La traducción de la definición se realiza de ingles a castellano, queda fuera del alcance la traducción a otras lenguas pero se ha desarrollado el caso de uso teniendo en cuenta que en un futuro es probable que se requiera la traducción a otras lenguas y realizando un pequeño cambio se pueda introducir en la aplicación este cambio. El mantenimiento del sistema también queda fuera del alcance de este proyecto. 29

30 Diagrama de estructura de descomposición del trabajo (EDT): Figura 3.1: Diagrama de estructura de descomposición del trabajo. 30

31 3.3.- Método de Trabajo: Proceso Unificado de Desarrollo (PUD): Para desarrollar el proyecto he elegido el Proceso Unificado de Desarrollo de Software, que es uno de los métodos recomendados por la Ingeniería del Software. El Proceso Unificado de Desarrollo de Software se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y ser iterativo e incremental. Iterativo e Incremental El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio sólo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto. Dirigido por los casos de uso En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. el proceso dirigido por casos de uso es el rup. Centrado en la arquitectura El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. La analogía con la construcción es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc. Enfocado en los riesgos El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero 31

32 He elegido este modelo por las siguientes ventajas: Tolerable a cambios en los requerimientos. Los elementos son integrados progresivamente. Los riesgos son mitigados en etapas tempranas. Permite a la organización aprender e improvisar. Facilita la reutilización, ya que es fácil identificar partes comunes diseñadas o implementadas. Resuelta El un producto mas robusto, puesto que los errores se van corrigiendo en cada iteración. proceso puede ser improvisado y refinado en el desarrollo. Permite una arquitectura modular. La reuniones ordinarias con el director del proyecto se realizaran en las fechas señaladas por los hitos que nos hemos marcado previamente. En dichas reuniones comprobaremos que esta correctamente realizado el hito. En caso afirmativo se concretara la próxima reunión coincidente con el próximo hito, en caso negativo se replanificaran las fechas de los hitos siguientes intentado que se modifiquen lo menos posible y se concretara una nueva reunión extraordinaria para comprobar que se ha modificado correctamente los fallos encontrados en el anterior hito. También se mantendrá un contacto permanente vía correo electrónico para la resolución de las pequeñas dudas concretas que surgirán en el desarrollo de cada hito. El almacenamiento de los datos se realizara en mi ordenador personal. Por razones de seguridad también se almacenara en un ordenador personal y en la web a través de Google docs. 32

33 Recursos Humanos: El recurso principal en todo desarrollo de Ingeniería de Software es el tiempo que invierten los participantes. En este caso el alumno y el director de proyecto. El tiempo total estimado para la realización de este Proyecto Fin de Carrera es de 327 horas Recursos Materiales: Los recursos materiales para la realización del proyecto son un ordenador con un sistema operativo linux, en nuestro caso concretamente la distribución Ubuntu que la podemos obtener gratuitamente ( ) y nos ofrece las mismas prestaciones que otros sistemas operativos propietarios. La forma de instalación elegida ha sido la instalación de una maquina virtual (concretamente Oracle VM VirtualBox) que nos permite instalar diferentes sistemas operativos en una misma máquina. También es necesario un entorno de desarrollo integrado (IDE) en nuestro caso hemos elegido eclipse y hemos tenido que descargarnos el parche del lenguaje de programación Perl. Un editor de texto, concretamente OpenOffice y también utilizaremos el gantproject para la planificación temporal El lugar de trabajo elegido será la biblioteca de la universidad, en la que disponemos de conexión a Internet vía Wi-Fi. La ubicación elegida para las reuniones sera el despacho del director del proyecto. El resto de recursos materiales es el material de oficina como folios, bolígrafos, llave USB e impresora. 33

34 3.4.- Planificación temporal: La planificación temporal de nuestro proyecto consta de cuatro fases: Fase 0: Gestión del proyecto Desarrollo del Documento de Objetivos del Proyecto (DOP). Este es un documento vivo que se mejorara para adaptarse a la realidad del proyecto, realizaremos nuevas versiones que surgirán de las replanificaciones que vayamos realizando. Acordaremos los días de reunión con el director del proyecto, intentaremos que coincidan con los hitos que nos marcamos para el desarrollo del proyecto. Fase 1: Análisis del Entorno Nos familiarizaremos con la naturaleza del problema. Buscaremos información acerca de la aplicación MCR, tras tener identificado el problema y las expectativas que se pretenden satisfacer con la realización de este proyecto, se acordara con el director del proyecto la linea a seguir para la resolución del mismo. Para ello, se realizara un pequeño estudio mercado explorando las diferentes opciones existentes para la resolución del proyecto, desde el sistema operativo a utilizar a el lenguaje de programación necesario. Como nuestra funcionalidad se integrara en la aplicación MCR, muchos de estos aspectos estarán marcados por dicha aplicación. Fase 2: Desarrollo técnico. Captura de requisitos: Se utilizara el modelo de casos de usos para obtener la funcionalidad que debe cumplir nuestra aplicación. Análisis: Se analizaran detalladamente los requerimientos obtenidos en la captura de requisitos y se estructuraran para abordar correctamente el problema. Diseño: Realizaremos el modelado del sistema integrando todos los requisitos exigidos obtenidos de la captura de requisitos y el análisis. Elección tecnológica: Se realizara un pequeño estudio de mercado comparando las diferentes herramientas que tenemos a nuestro alcance. Elegiremos las herramientas que nos ofrezcan las mejores prestaciones para el desarrollo del proyecto. Implementación: Desarrollaremos el programa ciñéndonos al diseño realizado previamente. Pruebas: Se comprobara el correcto funcionamiento del programa de forma individual, prestando especial atención a los casos críticos. Tras esta primera comprobación realizaremos las pruebas de integración, es decir, comprobar que nuestro programa sigue funcionando como funcionaba individualmente y también comprobaremos que el resto de las funcionalidades del sistema siguen funcionando correctamente tras la integración de nuestro código. Fase 3: Cierre de la iteración Se comprobara que los entregables obtenidos cumplen con los especificado en los requisitos, se obtendrán conclusiones sobre como era el planteamiento inicial y lo obtenido finalmente y porque difieren dichos planteamientos con el fin de extraer posibles mejoras futuras. Se preparara la documentación necesaria de la iteración. 34

35 Lista de entregas: Al término de la iteración, se entregarán: La documentación necesaria relacionada con los aspectos de la memoria del proyecto La versión definitiva del programa desarrollado. Las nuevas versiones de todos los documentos que hayan sido modificados. 35

36 Diagramas de Gantt: --- preguntar a german si hago un gantt de todo el proyecto --- Primera iteración: DOP + Planificación +Gestión + Captura de requisitos Figura 3.2. Diagrama de Gantt que muestra la planificación temporal de la primera iteración. Estimación horas/tarea: Desarrollo del DOP 16h Captura de requisitos 9h Planificación 8h Gestión 10h Reuniones ordinarias 4h Reuniones extraordinarias 2h Horas Totales 49h 36

37 Segunda iteración: Captura de requisitos + Análisis del entorno + Formación (Api, Perl,CGI) + Pruebas Figura 3.3. Diagrama de Gantt que muestra la planificación temporal de la segunda iteración. Estimación horas/tarea: Captura de requisitos 8h Análisis del entorno 18h Formación 26h Elección tecnológica 12h Reuniones ordinarias 8h Reuniones extraordinarias 4h Pruebas 10h Horas Totales 86h 37

38 Tercera iteración: Instalación herramientas (MCR, Perl, Apache, Eclipse) + Formación + Pruebas Figura 3.4. Diagrama de Gantt que muestra la planificación temporal de la tercera iteración. Estimación horas/tarea: Instalación de herramientas y puesta a punto 12h Formación 20h Implementación 12h Reuniones ordinarias 5h Reuniones extraordinarias 2h Pruebas 3h Horas Totales 54h 38

39 Cuarta iteración: Diseño + Implementación primer prototipo + Pruebas + Formación Figura 3.5. Diagrama de Gantt que muestra la planificación temporal de la cuarta iteración. Estimación horas/tarea: Diseño 12h Implementación primer prototipo 21h Pruebas 4h Formación 16h Reuniones ordinarias 4h Reuniones extraordinarias 1h Horas Totales 58h 39

40 Quinta iteración: Implementación y refinamiento del primer prototipo + Integración del prototipo en la aplicación + Pruebas + Elaboración de la memoria + Elaboración de la presentación Figura 3.6. Diagrama de Gantt que muestra la planificación temporal de la quinta iteración. Estimación horas/tarea: Implementación y refinamiento 26h Integración en la aplicación 12h Pruebas 8h Elaboración de la memoria 55h Elaboración de la presentación 12h Formación 22h Reuniones ordinarias 8h Reuniones extraordinarias 5h Horas Totales 148h 40

41 Estimación de las Horas/Tarea Totales Desarrollo del DOP 16h Captura de requisitos 17h Análisis 24h Diseño 12h Implementación 83h Formación 84h Integración 12h Elección tecnológica 12h Pruebas 25h Elaboración de la memoria 55h Elaboración de la presentación 12h Reuniones ordinarias 29h Reuniones extraordinarias 14h Horas Totales 395h 41

42 3.5.- Plan de contingencia: A continuación se exponen una serie de riesgos que nos podemos encontrar en la realización del proyecto y que pueden afectar directamente en el éxito del mismo. Es importante tenerlos identificados previamente para poder abordarlos correctamente cuando nos encontremos ante alguno de ellos. Propondremos una serie de soluciones para cada riesgo identificado y en el peor de los casos en los que no haya solución, intentaremos minimizar el impacto del mismo. Riesgos formativos: No tener los conocimientos necesarios para abordar una parte del proyecto (Linux, Perl, Eclipse,...). Solución: Si después de intentar solucionar el problema de forma autónoma, ya sea consultando libros, manuales, foros, paginas web especializadas,etc..concertaremos una reunión con el director del proyecto que nos orientara en la solución del problema, evitando la perdida excesiva de tiempo. Riegos Operativos: Perdida de los archivos relacionados con el proyecto, ya sea tanto por errores de software, como por errores humanos. Solución: Realizaremos copias de seguridad diarias y semanales. En el peor de los casos solo perderemos un día de trabajo. Para ello utilizaremos otro ordenador, llaves UBS y también tendremos los documentos en la web utilizando la herramienta gratuita Google docs, que aparte de servir para la realizacion de copias de seguridad nos permite acceder a los documentos desde cualquier lugar con tan solo tener una maquina y conexión a Internet. La api de Google presente problemas (la eliminen o pase a ser de pago) Solución: Hemos localizado herramientas que nos ofrece la misma funcionalidad que la api de Google translate (Microsoft translator, Apertium que es código libre, api de Bing Translate) Riesgos tácticos: Demora en los plazos acordados para la consecución de los hitos Solución: Reservar unos días entre hitos para paliar esa demora y que no afecte al plazo final de entrega del proyecto. 42

43 3.6.- Factibilidad: Para comprobar si el proyecto es factible nos centraremos en los dos aspectos mas relevantes: Factibilidad operativa: Vistos los antecedentes con los que cuenta la aplicación y las diferentes funcionalidades añadidas, podemos deducir que nuestro proyecto es factible y de hecho disponemos de varias alternativas para la consecución del mismo. Por lo tanto, con la tecnología que disponemos actualmente podremos encontrar una solución. Factibilidad económica: El proyecto es factible económicamente, ya que utilizaremos software libre que nos proporciona las prestaciones adecuadas para la consecución de nuestros objetivos. También tenemos un ordenador personal, que en caso de que falle no nos supondría ningún problema porque la universidad posee un aula con ordenadores a disposición de los alumnos. Por lo tanto, tras lo expuesto anteriormente, concluimos que la realización del proyecto es factible. 43

44 44

45 4.- DESARROLLO DEL SISTEMA DE INFORMACIÓN (SI): Captura de requisitos: Caso de uso: Actores: Usuario Descripción: Esta funcionalidad permite al usuario, dada una definición, obtener la traducción de la misma. También permite al obtener la traducción, editar y guardar traducción correcta en el sistema Curso normal de los eventos: 1. El usuario accede a la pagina Web del MCR. 2. El usuario indica la palabra a buscar y marca los campos de los idiomas correspondientes. Pulsa el botón look up para obtener el resultado. 3. El sistema obtiene los resultados y se los muestra en la parte inferior de la pagina. El sistema también muestra un botón a la izquierda de las definiciones en la que se indica el idioma, pulsamos el botón que contiene las letras spa y un código. 4. El sistema muestra en otra pantalla la traducción obtenida en la sección Automaticaly translated glosses 5. El usuario tiene la opción de editar la traducción obtenida en el campo Translation y tras cambiarla pulsa el botón Take this. 6. El sistema mostrara la definición cambiada por el usuario en el campo Gloss. 7. El usuario tras comprobar que es la definición que el ha editado, pulsa el botón Update variant 8. El sistema guarda la traducción en la base de datos Flujos alternativos: 2.1 El usuario introduce incorrectamente la palabra o introduce una palabra que no esta en el sistema. 2.2 El sistema muestra el mensaje Not found 45

46 4.2.1 Modelo de Dominio --- preguntar a german como es el Modelo de dominio --- REALIZAR dibujo MODELO DE DOMINIO --- Figura 4.0. Modelo de dominio 46

47 4.2 Análisis Caso de uso Obtener Traducción: Contrato Nombre: obtener traducción Responsabilidades Muestra la traducción de la definición obtenida, permite editar la traducción y guardarla en el sistema Excepciones Precondiciones Existe la definición a traducir Postcondiciones La definición traducida y editada queda guardada en el sistema Salida 47

48 4.3.- Arquitectura del sistema: Nuestro sistema sigue una arquitectura cliente-servidor. Los clientes realizan la petición, dicha petición se procesa en el servidor y el servidor tras consultar la base de datos devuelve la respuesta al cliente. Figura Arquitectura Cliente/Servidor La arquitectura del sistema esta compuesta de tres capas: Capa de presentación: La capa de presentación gestiona la parte que se le mostrara al cliente. La parte que corresponde al formulario que debe rellenar el cliente esta desarrollada en java y la parte que procesa la respuesta esta implementada en Perl. Capa de negocio: La capa de negocio esta integramente desarrollada en Perl, en ella encontramos las funciones necesarias para analizara las peticiones de los usuarios y las llamadas necesarias a la base de datos para obtener la respuesta. Capa de datos: La capa de datos esta desarrollada en MySQL. Esta compuesta por múltiples tablas en las que se encuentra almacenada la información 48

49 Hemos optado por desarrollar la aplicación siguiendo una arquitectura en dos capas (capa de presentación y capa de gestión de datos), donde la capa de dominio esta dentro de la capa de presentación. Capa de presentación El modo en el que el usuario interactúa con la aplicación es mediante una interfaz web. Para poder mostrar la interfaz es necesario tener instalado un navegador web. En esta capa se gestionará toda la lógica de negocio con todas sus operaciones. Para el desarrollo de esta capa se ha utilizado el lenguaje de programación Perl y para probarla hemos instalado el servidor Apache. Para este proyecto se ha podido aprovechar gran parte de las funciones y de los programas previamente desarrollados. Capa de gestión de datos: Se ha decidido implementar la gestión de los datos sobre un sistema de gestión de base de datos (SGBD) relacional, multihilo y multiusuario, como es MySQL, el cual ha sido elegido por la propia naturaleza del proyecto, ya que el MCR esta desarrollado utilizando MySQL como SGBD. También ha sido necesario instalar el controlador adecuado DBI para MySQL con el objetivo de poder operar con los datos utilizando código Perl, lenguaje que al estar orientado a objetos favorece enormemente un diseño modular y estructurado 49

50 4.4.- Elección tecnológica Php PHP es un lenguaje interpretado de propósito general ampliamente usado y que está diseñado especialmente para desarrollo web y puede ser incrustado dentro de código HTML. Generalmente se ejecuta en un servidor web, tomando el código en PHP como su entrada y creando páginas web como salida. Puede ser desplegado en la mayoría de los servidores web y en casi todos los sistemas operativos y plataformas sin costo alguno. Ventajas Es un lenguaje multiplataforma. Completamente orientado a la web. Capacidad de conexión con la mayoría de los motores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL y PostgreSQL. Capacidad de expandir su potencial utilizando la enorme cantidad de módulos (llamados ext's o extensiones). Posee una amplia documentación en su página oficial ([2]), entre la cual se destaca que todas las funciones del sistema están explicadas y ejemplificadas en un único archivo de ayuda. Es libre, por lo que se presenta como una alternativa de fácil acceso para todos. PHP es Open Source, lo cual significa que el usuario no depende de una compañía específica para arreglar cosas que no funcionan, además no estás forzado a pagar actualizaciones anuales para tener una versión que funcione. Muchos de nosotros que hemos esperado que Allaire arregle algo apreciamos esto. Permite las técnicas de Programación Orientada a Objetos. 50

51 Biblioteca nativa de funciones sumamente amplia e incluida. No requiere definición de tipos de variables aunque sus variables se pueden evaluar también por el tipo que estén manejando en tiempo de ejecución. Tiene manejo de excepciones (desde PHP5). Rapidez. PHP generalmente es utilizado como modulo de Apache, lo que lo hace extremadamente veloz. Esta completamente escrito en C, así que se ejecuta rápidamente utilizando poca memoria. Puede interactuar con muchos motores de bases de datos tales como MySQL, MS SQL, Oracle, Informix, PostgreSQL, y otros muchos. Siempre podrás disponer de ODBC para situaciones que lo requieran. Ya existen IDE y debuger para PHP. Desventajas Si bien PHP no obliga a quien lo usa a seguir una determinada metodología a la hora de programar (muchos otros lenguajes tampoco lo hacen), aun estando dirigido a alguna en particular, el programador puede aplicar en su trabajo cualquier técnica de programación y/o desarrollo que le permita escribir código ordenado, estructurado y manejable. Un ejemplo de esto son los desarrollos que en PHP se han hecho del patrón de diseño Modelo Vista Controlador (o MVC), que permiten separar el tratamiento y acceso a los datos, la lógica de control y la interfaz de usuario en tres componentes independientes. La ofuscación de código es la única forma de ocultar los fuentes. El manejo de errores no es tan sofisticado como Cold Fusion o ASP Perl Perl (Practical Extraction y Report Language) es un lenguaje de propósito general, fue originalmente desarrollado para extraer informes de ficheros de texto y utilizar dicha información para preparar informes, dicho desarrollo motivado principalmente por el hecho de que no existía un lenguaje en ese momento que pudiera satisfacer sus necesidades. Sin embargo, actualmente ha evolucionado y se ha diseccionado hacia un enfoque diferente con el que se creó el lenguaje, siendo capaz de realizar labores de administración en cualquier sistema operativo, tales como administración de sistemas, desarrollo Web, programación en red, desarrollo de GUI(Graphical User Interface), así como otras aplicaciones prácticas. Este lenguaje debe gran parte de su popularidad a que se trata de un lenguaje pseudo-compilado que se distribuye de forma gratuita; un Script genérico de Perl puede ejecutarse en cualquier plataforma en la que tengamos un intérprete disponible. Además, con el crecimiento acelerado de sitios Web, se generó la necesidad de realizar programas CGI (Common Gateway Interface) el cual define un protocolo de comunicación entre un servidor Web y una aplicación externa para ofrecer contenido dinámico a las páginas Web; con lo que Perl se convirtió en la elección natural para aquellos desarrolladores que se encontraban familiarizados con este lenguaje. 51

52 Características Perl es un lenguaje visualizado para la manipulación de cadenas de caracteres, archivos y procesos. Esta manipulación se ve simplificada por el importante número de operadores a disposición del usuario. Para trabajar con Perl se requieren dos requerimientos básicos y fáciles de conseguir: Un editor de texto para poder escribir los programas Perl. El intérprete de Perl, que ejecute los programas realizados con Perl. Es una combinación de las características de los lenguajes más usados por los programadores de sistemas, como son los shell del sistema operativo UNIX, los utilidad (que incluye un lenguaje interpretado propio) awk para formateo y tratamiento de texto e incluso características de Pascal, aunque su potencia se basa en la similitud con las mejores características del lenguaje estructurado C. Es por esto que el lenguaje Perl se percibe habitualmente como un lenguaje intermedio entre los shell scripts y la programación en C. Esto debido a que los programas en Perl son una sucesión de instrucciones y son similares a los shell scripts porque no existe un procedimiento principal como la subrutina main en C. Sin embargo, se parece al lenguaje C en su sintaxis y en el número importante de funciones que permiten la manipulación de cadenas de caracteres y archivos. Por todo esto, Perl es un lenguaje muy utilizado en los dos campos siguientes: 1. La administración de sistemas operativos, ya que gracias a sus características, Perl es muy potente en la creación de pequeños programas que pueden ser usados como filtros para obtener información de ficheros, realizar búsquedas, entre otras cosas. Además, aunque Perl nació en un entorno Unix, hay versiones para casi todas las plataformas existentes. 2. La creación de formularios en la Web. Se ha usado desde los primeros días del Web para escribir scripts CGI (Common Gateway Interface), los cuales realizan el intercambio de información entre aplicaciones externas y servicios de información, es decir, se encargan de tratar y hacer llegar la información que el cliente WWW manda al servidor a través de un formulario. Es una de las "tres P s (Perl, Python y PHP), que son los lenguajes más populares para la creación de aplicaciones Web, y es un componente integral de la popular solución LAMP (Linux Apache MySQL Perl) para el desarrollo Web. Grandes proyectos escritos en Perl son Slash, IMDb y UseModWiki, un motor de Wikipedia. En otras palabras, muchos sitios Web con alto tráfico de usuarios. 52

53 Actualmente existen dos versiones que son las mas populares de Perl, la 4.3 y la 5.0 (aunque llevan muchos años trabajando en la versión 6), habiendo diferencias importantes entre una versión y otra, esto debido a que no son totalmente compatibles. La versión 5 de Perl es una reescritura en donde se añadieron características para soportar estructuras de datos complejas, y un modelo de programación orientado a objetos. Éstos incluyen referencias, paquetes y una ejecución de métodos basada en clases y la introducción de variables de ámbito léxico, que hizo más fácil escribir código robusto. Esto rompe en gran medida con la filosofía tradicional de Perl de una programación más parecida a los Shells de Unix que al modular lenguaje C, de modo que las librerías, por ejemplo para creación de CGI s, no funcionan de un método a otro. Además, el lenguaje Perl no es precompilado, pero aún así es más rápido que la mayoría de lenguajes interpretados. Esto se debe a que los programas en Perl son analizados, interpretados y compilados por el interprete perl antes de su ejecución. Esto quiere decir que no hace falta un fichero binario para poder ejecutar las instrucciones que hemos codificado usando este lenguaje, es decir, es interpretado, aunque el intérprete de Perl "compila" los programas antes de ejecutarlos. Por esta razón es que se dice que es un lenguaje pseudo compilado, o sea, una fusión entre compiladores e intérpretes. Existen varias características acerca de Perl que son importantes de destacar: 1.Es fácil de usar, aunque es difícil de aprender. Este lenguaje se desarrolló pensando en que el lenguaje fuera práctico (fácil de usar, eficiente, y completo) en lugar de pequeño, elegante y mínimo, además de que esta enfocado hacia un desarrollador que posee cierta cantidad de conocimientos sobre el lenguaje y no así hacia un estudiante que esta aprendiendo. 2. Existen muy pocas cosas que no se pueden hacer con este lenguaje, por lo que se le puede considerar como un lenguaje que no tiene fronteras. Con Perl se puede programar cualquier necesidad que se tenga, ya que existen librerías y módulos para casi cualquier cosa que se requiera, pero hay aplicaciones que requieren mucha rapidez en las cuales es mejor utilizar otros lenguajes que no sean interpretados. 3. Es rápido de crear, ya que no posee funciones que, aunque sean bastante interesantes, hagan disminuir la velocidad de desarrollo de una aplicación del lenguaje. 4. El lenguaje es feo, siendo esta una de las principales razones para su difícil aprendizaje, aunque esto se compensa con el poder de alcance del lenguaje. Es por esto que Larry Wall escogió el camello como el logotipo del lenguaje, ya que aunque es feo, siempre trabaja fuerte aún en condiciones complicadas. 5. Se puede utilizar en varios entornos, como puede ser Windows 95, OS/2, Linux, entre muchos otros, sin realizar cambios de código, siendo únicamente necesario la introducción del interprete Perl correspondiente a cada sistema operativo. 6. Tiene características que soportan una variedad de paradigmas de programación, como la estructural, funcional y la orientada a objetos. Al mismo tiempo, Perl no obliga a seguir ningún paradigma en particular, ni obliga al programador a elegir alguna de ellas. No 53

54 obstante, esta característica es solo accesible en la versión Tiene incorporado un poderoso sistema de procesamiento de texto y una enorme colección de módulos disponibles. 8. Ofrece una ayuda en línea desde la consola de comandos. 9. Se ejecuta desde la línea de comandos de una ventana del sistema operativo. 10. Es un lenguaje case-sensitive, lo cual hace referencia a la propiedad de un texto para presentarse en mayúsculas o en minúsculas Phyton Python es un lenguaje de programación de alto nivel cuya filosofía hace hincapié en una sintaxis muy limpia y que favorezca un código legible. Es un lenguaje interpretado, orientado a objetos de propósito general. Python permite mantener de forma sencilla interacción con el sistema operativo, y resulta muy adecuado para manipular archivos de texto. Está disponible en MS-Windows, GNU/Linux, Mac y cualquier entorno. Python es un lenguaje de scripts, sencillo pero potente. Esto significa que Python no genera ejecutables, si no que es Python el encargado de ejecutar nuestro código. Es por tanto un lenguaje interpretado, no compilado. Esto le dota de ventajas, pero también de algunos inconvenientes: Ventajas Desarrollo más rápido : Puedes escribir un programa, salvarlo y ejecutarlo. En un lenguaje compilado tienes que pasar por los pasos de compilar y ligar el software, lo cual puede ser un proceso lento. Multiplataforma : El mismo código funciona en cualquier arquitectura, la única condición es que disponga del intérprete del lenguaje. No es necesario compilar el código una vez para cada arquitectura. Los scripts en Python fácilmente pueden comunicarse con otras partes de una aplicación, usando una variedad de mecanismos para la integración. Actualmente, Phyton puede invocar bibliotecas en C y C++, puede integrarse con componentes en Java, puede comunicar sobre CORBA y.net, puede interactuar en la red con interfaces como SOAP, protocolo estándar que define como dos objetos en diferentes procesos puede comunicarse por medio del intercambio de datos en XML y XML-RPC. 54

55 Inconvenientes Lentitud : Los programas interpretados son más lentos que los compilados. Sin embargo los programas interpretados suelen ser cortos, en los que la diferencia es inapreciable Solución tecnológica Perl: Hemos elegido el lenguaje de programación Perl (Practical Extraction and Report Language) puesto que es uno de los lenguajes mas populares para el desarrollo de aplicaciones Web y en nuestro caso, las ventajas que tiene nos ofrece todas las prestaciones que necesitamos. VENTAJAS Es un lenguaje estable y robusto, lleva mucho tiempo en activo por lo que encontramos un numeroso numero de fuentes, librerías y documentación disponibles. También es muy rápido. Perl cuenta también con CPAN que es el acrónimo de Comprehensive Perl Archive Network. Es un enorme archivo de software escrito en Perl, así como de documentación sobre el mismo. Tiene presencia en la Web a través de su sitio y sus 236 espejos distribuidos por todo el mundo. Actualmente hay más de módulos empaquetados en más de paquetes, disponibles en CPAN, aportados por más de autores. Es una ventaja utilizar un lenguaje interpretativo como herramienta de desarrollo, tanto para aplicaciones web como para escritorio, por el hecho de ser un lenguaje script, lo cual implica que no requiere de un compilador y no se genera un código objeto, sino que se va interpretando línea por línea. Esto ofrece la funcionalidad de portabilidad de la aplicación debido a que no requiere una plataforma específica para implementar la aplicación, lo cual es una característica muy importante y deseada en toda aplicación web. No obstante, también tiene desventajas importantes, tales como la verificación de tipos como su velocidad de ejecución. Un segundo punto importante a recalcar es su facilidad de uso, tanto en lo referente a la obtención e instalación del mismo, como por las ventajas a nivel de programación que ofrece. Perl 5.0 es un lenguaje libre que solo requiere de un editor de texto y un intérprete fácil, el cual es fácil de instalar y de obtener, debido a que es un lenguaje no privativo. Además, ofrece la posibilidad de trabajar con expresiones regulares y otros tipos de objetos que no son comunes en lenguajes diferentes a los scripts. 55

56 El último punto a nombrar son las facilidades que presenta el lenguaje Perl 5.0 para la implementación de aplicaciones Web. Existe una gran diversidad de funcionalidades añadidas a la versión 5.0 para el manejo de programación en red, así como el fácil uso de las expresiones regulares, las cuales son muy utilizadas por los desarrolladores para validar páginas web a nivel de formularios y envío de peticiones HTTP GET por parte de los clientes en los navegadores Web, entre otras aplicaciones, que ofrece una mayor velocidad de respuesta y seguridad al momento del descifrado Apache El servidor HTTP Apache es un software (libre) servidor HTTP de código abierto para plataformas Unix (BSD, GNU/Linux, etc.), Windows, Macintosh,... El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la Apache Software Foundation. VENTAJAS Modular Código abierto Multiplataforma Extensible Gratuito Popular (fácil de conseguir ayuda/soporte) La arquitectura del servidor Apache es muy modular. El servidor consta de una sección core y diversos módulos que aportan mucha de la funcionalidad que podría considerarse básica para un servidor web. Algunos de estos módulos son: mod_php: Páginas dinámicas en PHP. mod_python: Páginas dinámicas en Python. mod_perl: Paginas dinámicas en Perl Nos sirve también a la hora de programar aplicaciones web para previsualizar y probar código mientras éste es desarrollado utilizando una versión local de Apache 56

57 4.5.3 Phpmyadmin PhpMyAdmin es una utilidad que nos sirve para inteactuar con una base de datos de forma muy sencilla y desde una interfaz web. Nos sirve por ejemplo para crear bases de datos, tablas, borrar o modificar dados, añadir registros, hacer copias de seguridad, etc. Es una aplicación tan útil que casi todos los hosting con MySQL disponen de ella Esta disponible en 62 idiomas y se encuentra disponible bajo la licencia GPL Mysql Es un sistema de gestión de base de datos relacional, multihilo y multiusuario con mas de seis millones de instalaciones. Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta licencia. Existen varias APIs que permiten, a aplicaciones escritas en diversos lenguajes de programación, acceder a las bases de datos MySQL, incluyendo C, C++, C#, Pascal, Delphi (via dbexpress), Eiffel, Smaltalk, Java (con una implementación nativa del driver de Java), Lisp, Perl, PHP, Phyton, Ruby, Gambas, REALbasic (Mac y Linux), (x)harbour (Eagle1), FreeBASIC, y Tcl ; cada uno de estos utiliza una Api específica. También existe una interfaz ODBC, llamada MyODBC que permite a cualquier lenguaje de programación que soporte ODBC comunicarse con las bases de datos MySQL. También se puede acceder desde el sistema SAP, lenguaje ABAP. MySQL es muy utilizado en aplicaciones web, como Drupal o phpbb, en plataformas (Linux/Windows-Apache-MySQL-PHP/Perl/Python), y por herramientas de seguimiento de errores como Bugzilla. Su popularidad como aplicación web está muy ligada a PHP, que a menudo aparece en combinación con MySQL. MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modificación. En aplicaciones web hay baja concurrencia en la modificación de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones. Sea cual sea el entorno en el que va a utilizar MySQL, es importante adelantar monitoreos sobre el desempeño para detectar y corregir errores tanto de SQL como de programación. 57

58 4.6.- Diseño Figura 4.2. Diagrama de secuencia. En la figura 4.2. se muestra el diagrama de secuencia de nuestra caso de uso, este diagrama modela la interacción entre los objetos en el sistema según UML (Unified Modeling Language Lenguaje Unificado de Modelado ) 58

59 4.7.- Implementación Vamos a explicar básicamente como se ha implementado la funcionalidad. Primeramente el usuario introduce una palabra en el MCR para que le devuelva las diferentes definiciones en los diferentes idiomas (todas las definiciones están en ingles pero en muchos casos falta la definición al castellano). El usuario comprueba que falta la definición al castellano y pulsa el botón que contiene las letras spa (esta rodeado en rojo en la siguiente captura de pantalla de la aplicación). Figura 4.3. Resultados de consultar un termino en el MCR Esta operación se conecta con Google translate a través de su API, el Google translate devuelve la traducción y se le muestra al usuario a través de la interfaz. 59

60 Figura 4.4. Muestra el lugar donde nos aparece la traducción proporcionada por el Google Translate El usuario comprueba que la traducción sea correcta. Si no es del todo correcta, el sistema permite al usuario editar la traducción obtenida. Tras modificar la traducción el usuario pulsa el botón Take this y la traducción correcta aparecerá en el campo Gloss como podemos ver en la siguiente captura. Figura 4.5. Muestra como tras pulsar el botón Take this la definición editada por nosotros aparece en el campo Gloss 60

61 El usuario tras comprobar que esa es la definición correcta que quiere guardar, pulsa el botón update variant y el sistema guarda la definición correcta en la base de datos (como podemos ver en las siguientes capturas de pantalla de la aplicación) Figura 4.6. Muestra el botón que tenemos que pulsar para guardar la definición ( Update variant ) Tras pulsar este botón nos saldrá la siguiente pantalla indicándonos que se ha guardado correctamente la definición en la base de datos. 61

62 Figura 4.7. Muestra el mensaje que nos indica que se ha guardado correctamente la definición. Finalmente, para comprobar que se ha utilizado correctamente volvemos a introducir el termino buscado anteriormente para ver si aparece la definición que hemos guardado. Figura 4.8. Muestra como la definición se ha guardado correctamente en el sistema. 62

63 --- Preguntar a German si especificar mas el pseudocodigo Preguntar a German si tengo que mandar también el archivo wei.editar.synset.perl y si lo tengo que mandar como lo añado, creo un nuevo punto llamado Anexo 3. Código del programa --Vamos a explicar en pseudocodigo el programa que hemos implementado. Si se quiere conocer al detalle el código del programa ver wei.editar..synset.perl Si la $lengua distinta de ingles imprimir el lenguaje es diferente de $lengua si existe la glosa %args= ( imprimir el texto a traducir es text = definición de la glosa: src = Lenguaje; dest = destino; ); $result = servicio_traductor (%args); Actualizar resultado en la base de datos: 63

64 64

65 5. PRUEBAS Acabada la fase de implementación del programa hemos realizado una serie de pruebas de software. Estas pruebas son un elemento crítico para garantizar la calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación. A través de estas pruebas, hemos logrado detectar la mayoría de errores que se pueden dar durante el uso de la aplicación. Gracias a estos errores, hemos procedido a una fase de depuración para corregirlos. 5.1 Tipos de pruebas Hemos realizado una serie de pruebas específicas que se dividen en los siguientes tipos: - Pruebas unitarias: Prueba de único comportamiento elemental. Son básicamente pruebas de caja blanca: 1. Interfaz 2. Condiciones limite 3. Caminos independientes 4. Caminos de tratamiento de errores Para realizar estas pruebas unitarias nos hemos centrado en que la página estuviera bien construida y en la accesibilidad de la página. Los pasos seguidos son los siguientes: 1º) Subimos la pagina al servidor local 2º) Intentamos acceder a la pagina en el servidor local. 3º) Si no conseguimos acceder a la pagina o si no se visualiza bien abrimos el archivo de errores de apache (error.log). - Pruebas de integración: Prueba de las interacciones entre componentes del sistema Hemos comprobado que al integrar nuestro código no interfiera en las demás funcionalidades del sistema. Para ello, hemos realizado las siguientes pruebas: 1) Introducir un termino correcto (que sabemos que estaba previamente en el sistema). El sistema nos debería de mostrar el resultado con los parámetros indicados en la consulta (relaciones, idiomas,...). 2) Introducimos un termino incorrecto (que sabemos que no esta en el sistema). El sistema nos debe de mostrar un mensaje (Not Found!!!). 3) No introducir ningún termino. El sistema nos vuelve a mostrar la pagina inicial. 65

66 - Pruebas de validación: Se centran en asegurar que se satisfacen los requisitos desde el punto de vista del usuario. Son básicamente pruebas de caja negra: 1. Funcionales 2. De rendimiento 3. De documentación 4. Transportabilidad, compatibilidad 5. Recuperación de errores Para asegurarnos de que la funcionalidad cumple con lo especificado, hemos realizado las siguientes pruebas: 1) Introducir una definición con muchos caracteres. El sistema responde correctamente mostrando la definición. 2) Editar la definición obtenida. Hemos comprobado que si el usuario al editar la definición borra toda la definición e intenta guardar la definición sin ninguna palabra en la base de datos, el sistema muestra el mensaje de error ( tiene que introducir alguna palabra ). - Pruebas del sistema: Prueba global del sistema como unidad de ejecución. Estas pruebas sirven para verificar que se han integrado adecuadamente todos los elementos del sistema y todos ellos de forma conjunta realizan las funciones apropiadas: 1. Pruebas de seguridad 2. Pruebas de rendimiento Para asegurarnos el correcto rendimiento del sistema, hemos realizado las siguientes pruebas: 1) Comprobar el tiempo de carga de la pagina. El tiempo de respuesta del sistema es muy parecido tras introducir la nueva funcionalidad. 2) Traducir simultáneamente varias definiciones por varios usuarios. El sistema muestra las definiciones correctamente. 3)Guardar diferentes definiciones por diferentes usuarios. El sistema las guarda correctamente en la base de datos. 5.2 Proceso de implantación Una vez comprobado el correcto funcionamiento de la aplicación en nuestra maquina pasaremos a la fase de implantación en el servidor. En el caso de que se nos presenten problemas veremos cual es la razón de dichos problemas y buscaremos soluciones para solventar los problemas surgidos. También comprobaremos el tiempo necesario de carga de la pagina y comprobaremos que este dentro de unos limites aceptables para el correcto funcionamiento de la aplicación. 66

67 6 GESTION Tras haber finalizado el proyecto, vamos a ver la diferencia entre las horas planificadas y las horas reales que hemos empleado. Estas gráficas nos serán de gran utilidad en un futuro para darnos cuenta de que generalmente las estimaciones en los proyectos (y mas concretamente en los proyectos informáticos) no se suelen ajustar a la realidad. Por lo tanto, en este apartado podemos ver en que tareas se ha producido mas demora y de ahí podremos sacar conclusiones para que en un futuro no nos vuelva a suceder 6.1 Primera iteración Primera iteración: DOP + Planificación +Gestión + Captura de requisitos Horas Estimadas Horas reales Desarrollo del DOP 12h 16h Captura de requisitos 7h 9h Planificación 7h 8h Gestión 8h 10h Reuniones ordinarias 4h 4h Reuniones extraordinarias 0h 2h Horas Totales 38h 49h Vamos a desglosar en las siguientes gráficas la tabla anterior. 67

68 [Iteracion 1] Analisis Horas estimadas 15 Horas reales Desarrollo del DOP Captura de requisitos Horas Totales Figura 6.1. Comparativa de las horas estimadas en la planificación del análisis y las horas reales que hemos invertido en el análisis de la Iteración 1. [Iteracion 1] Gestión Horas estimadas s To ta le io n Ho ra s G es t Pl an ific ac i on Horas reales Figura 6.2. Comparativa de las horas estimadas en la planificación de la gestión y las horas reales que hemos invertido en la gestión en la Iteración 1. 68

69 [Iteracion 1] Reuniones Horas estimadas Horas Totales Reuniones extraordinarias Reuniones ordinarias Horas reales Figura 6.3. Comparativa de las horas estimadas en la planificación de las reuniones y las horas reales que hemos invertido en las reuniones en la Iteración 1. Como observamos en las gráficas, la mayor desviación se produce en el desarrollo del DOP y en la captura de requisitos. Esta desviación se produjo porque para desarrollar estas tareas, tuvimos la necesidad de formarnos en algunos temas relacionados con el proyecto. Esta formación no la estimamos inicialmente por lo que nos conllevo un retraso. 6.2 Segunda Iteración Segunda iteración: Captura de requisitos + Análisis del entorno + Formación (Api, Perl,CGI) + Pruebas Captura de requisitos 6h 8h Análisis del entorno 10h 18h Formación 18h 26h Elección tecnológica 10h 12h Reuniones ordinarias 6h 8h Reuniones extraordinarias 0h 4h Pruebas 8h 10h Horas Totales 58h 86h 69

70 Vamos a desglosar en las siguientes gráficas la tabla anterior. [Iteración 2] Analisis Horas estimadas 15 Horas reales 10 5 Horas Totales Analisis del entorno Captura de requisitos 0 Figura 6.4. Comparativa de las horas estimadas en la planificación del análisis y las horas reales que hemos invertido en el análisis de la Iteración 2. [Iteración 2] Desarrollo Técnico Horas estimadas Horas reales 20 Horas Totales Pruebas Eleccion tecnologica 0 Formacion 10 Figura 6.5. Comparativa de las horas estimadas en la planificación del desarrollo técnico y las horas reales que hemos invertido en el desarrollo técnico en la Iteración 2. 70

71 [Iteración 2] Reuniones Horas estimadas Horas Totales Reuniones extraordinarias Reuniones ordinarias Horas reales Figura 6.6. Comparativa de las horas estimadas en la planificación de las reuniones y las horas reales que hemos invertido en las reuniones en la Iteración 2. Como observamos en las gráficas, la mayor desviación se produce en las horas que estimamos en la formación y el análisis del entorno. En un principio al no conocer exactamente a lo que nos estábamos enfrentado hicimos una estimación pensando que no iba a ser muy difícil formarnos y analizar el entorno. Finalmente comprobamos que necesitábamos bastantes mas horas del las previstas en formarnos (ya que necesitamos conocer herramientas que nunca habíamos utilizado) y también necesitamos mas horas en hacer un análisis del entorno exhaustivo. 71

72 6.3 Tercera Iteración Tercera iteración: Instalación herramientas (MCR, Perl, Apache, Eclipse) + Formación + Pruebas Estimación horas/tarea: Instalación de herramientas 14h y puesta a punto 12h Formación 25h 20h Implementación 10h 12h Reuniones ordinarias 5h 5h Reuniones extraordinarias 0h 2h Pruebas 3h 3h Horas Totales 57h 54h Vamos a desglosar en las siguientes gráficas la tabla anterior. [iteración 3] Desarrollo Tecnico Horas estimadas 15 Horas reales 10 5 Horas Totales Pruebas Implementación Instalacion de herramientas 0 Figura 6.7. Comparativa de las horas estimadas en la planificación del desarrollo técnico y las horas reales que hemos invertido en el desarrollo técnico de la Iteración 3. 72

73 [Iteración 3] Formación y Reuniones Horas estimadas 15 Horas reales 10 5 To ta le s H or as s ex tra or di na ria s es or di na ria R eu ni on es R eu ni on Fo rm ac io n 0 Figura 6.8. Comparativa de las horas estimadas en la planificación de la formación y las reuniones y las horas reales que hemos invertido en esta Iteración 3. Como observamos en las gráficas, en esta iteración hemos invertido unas pocas horas menos de las estimadas. Esto se ha producido debido a que el trabajo realizado en la iteración 1 y en la iteración 2 nos ha sido de gran ayuda y nos ha permitido tener que invertir menos horas en formación. 73

74 6.4 Cuarta Iteración Cuarta iteración: Diseño + Implementación primer prototipo + Pruebas + Formación Estimación horas/tarea: Diseño 10h 12h Implementación primer prototipo 24h 21h Pruebas 6h 4h Formación 12h 16h Reuniones ordinarias 4h 4h Reuniones extraordinarias 0h 1h Horas Totales 58h 56h Vamos a desglosar en las siguientes gráficas la tabla anterior. [Iteracion 4] Desarrollo técnico Horas estimadas 20 Horas reales To ta le s Ho ra s Pr ue ba s Di se ño Im pl em en ta ció n 0 Figura 6.9. Comparativa de las horas estimadas en la planificación del desarrollo técnico y las horas reales que hemos invertido en el desarrollo técnico en la Iteración 3. 74

75 [iteración 4] Formacion y Reuniones Horas estimadas Horas reales 10 5 To ta le s H or as s ex tra or di na ria s es or di na ria R eu ni on es R eu ni on Fo rm ac ió n 0 Figura Comparativa de las horas estimadas en la planificación de las reuniones y las horas reales que hemos invertido en las reuniones en la Iteración 4. Como observamos en las gráficas, las estimaciones que habíamos realizado se ajustan bastante a la realidad. Gracias a los conocimientos que hemos adquirido a lo largo de las tres primeras iteraciónes, nos ha sido mas fácil desarrollar esta iteración 4. 75

76 6.5 Quinta Iteración Quinta iteración: Implementación y refinamiento del primer prototipo + Integración del prototipo en la aplicación + Pruebas + Elaboración de la memoria + Elaboración de la presentación Estimación horas/tarea: Implementación y refinamiento 23h 26h Integración en la aplicación 10h 12h Pruebas 6h 8h Elaboración de la memoria 40h 55h Elaboración de la presentación 12h 12h Formación 19h 22h Reuniones ordinarias 8h 8h Reuniones extraordinarias 0h 5h Horas Totales 148h 118h Vamos a desglosar en las siguientes gráficas la tabla anterior. [iteración 5] Gestión Horas estimadas 40 Horas reales Elaboración de Elaboracion de la memoria la presentacion Horas Totales Figura Comparativa de las horas estimadas en la planificación de la gestión y las horas reales que hemos invertido en la gestión en la Iteración 5. 76

77 [iteracion 5] Desarrollo Técnico Horas estimadas 25 Horas reales s To ta le H or as P ru eb as In te gr ac ió n Im pl em en t ac ió n 0 Figura Comparativa de las horas estimadas en la planificación del desarrollo técnico y las horas reales que hemos invertido en el desarrollo técnico en la Iteración 5. [Iteración 5] Formación y Reuniones Horas estimadas 20 Horas reales Ho ra st ot ale s ao rd i na ria s s es ex tr es or di na ria Re un ion Re un ion Fo rm ac ion 0 Figura Comparativa de las horas estimadas en la planificación de las reuniones y la formación y las horas reales que hemos invertido en la Iteración 5. 77

78 Como observamos en las gráficas, las estimaciones que habíamos realizado se ajustan bastante a la realidad en cuanto al desarrollo técnico, la formación y las reuniones. El dato mas significativo es la mala estimación del tiempo que nos iba a llevar a la elaboración de la memoria, podemos ver una diferencia de 15 horas con respecto a lo estimado. 6.6 Comparativa Total Comparativa Total (el conjunto de las cinco iteraciones) Desarrollo del DOP 12h 16h Captura de requisitos 13h 17h Análisis 29h 24h Diseño 10h 12h Implementación 67h 83h Formación 72h 84h Integración 10h 12h Elección tecnológica 10h 12h Pruebas 23h 25h Elaboración de la memoria 40h 55h Elaboración de la presentación 12h 12h Reuniones ordinarias 29h 29h Reuniones extraordinarias 0h 14h Horas Totales 395h

79 [Total] Formacion y Reuniones Horas estimadas 60 Horas reales To ta le s Ho ra s Fo rm ac io n Re un io ne s Re un io n es or di na ria s ex tra or di na ria s 0 Figura Comparativa de las horas estimadas en la planificación de la formación y de las reuniones y las horas reales que hemos invertido en Total. 79

80 [Total] Elaboracion de la Memoria y la Presentación Horas estimadas 40 Horas reales Elaboracion de Elaboracion de la memoria la presentación Horas Totales Figura Comparativa de las horas estimadas en la planificación de la elaboración de la memoria y de la presentación y las horas reales que hemos invertido en Total. 80

81 [Total] Integración y Pruebas Horas estimadas 20 Horas reales Integración Pruebas Horas Totales Figura Comparativa de las horas estimadas en la planificación de la integración y de las pruebas y las horas reales que hemos invertido en Total. 81

82 [Total] Analisis Horas estimadas 30 Horas reales Desarrollo Captura de del DOP requisitos Analisis Horas Totales Figura Comparativa de las horas estimadas en la planificación del análisis y las horas reales que hemos invertido en Total. 82

83 [Total] Implementación Horas estimadas 50 Horas reales Implementación Eleccion tecnologica Horas Totales Figura Comparativa de las horas estimadas en la planificación de la implementación y las horas reales que hemos invertido en Total. Como conclusión general de la lectura de las gráficas totales, podemos ver que hemos sufrido casi un 20% de demora con respecto a la planificación inicial. Esta situación si la extrapolamos al mundo empresarial, puede suponer que el proyecto nos lleve a una perdida de dinero. Por lo tanto, nos hemos dado cuenta de la importancia de una buena planificación y gestión del proyecto. Para ello hemos utilizado herramientas que nos ayuda enormemente a la planificación temporal (como son los diagramas de Gantt). 83

84 84

85 7 MEJORAS FUTURAS --- preguntar a german si lo pongo en primera persona del singular o si lo dejo en primera persona del plural preguntar a german si esta bien el apartado o es demasiado extenso --Tras haber trabajado sobre la aplicación hemos observado que se pueden realizar una serie de mejoras. Tras una pequeña investigación hemos encontrado algunas herramientas muy interesantes que en un futuro seria conveniente que se integraran en el MCR. ): En primer lugar, una carencia que hemos detectado es que hay algunas definiciones que no tienen candidatos a variants (es decir, les falta la palabra a definir a pesar de tener la definición) de otras lenguas. La soluciones que hemos encontrado para solventar esta carencia de manera automática son: Utilizar la traducción automática de Google. Utilizar Wikipedia, en particular Babelnet Babelnet es una gran red multilingüe semántica con millones de los conceptos obtenidos a partir de: una integración de WordNet y Wikipedia sobre la base de un algoritmo de asignación automática las traducciones de los conceptos (es decir, las páginas de Wikipedia Inglés y synsets de WordNet) con base en los enlaces cruzados del lenguaje de Wikipedia y la salida de los sistemas de traducción automática. En segundo lugar, se puede incorporar una herramienta que nos sirve para enriquecer nuestros textos y en nuestro caso las definiciones que aporta el MCR. Estas herramientas identifican las palabras clave que encuentra en el texto y las asocia a la pagina concreta de la wikipedia en la que se explica el significado de esta palabra (la característica interesante es que te muestra la pagina concreta correspondiente al significado de esa palabra en el contexto que se encuentra en el texto, es decir, elimina la ambigüedad de determinados términos) Básicamente, Tagme es una herramienta que es capaz de identificar en el momento subcadenas significativas en el texto no estructurado (llamadas "spots") y las asocia a la correspondiente pagina de wikipedia de una manera rápida. Se pueden realizar pruebas automáticas de esta herramienta a través de su API REST. 85

86 Tagme asocia un atributo a cada anotación, llamado ρ (rho), que estima cual es la "bondad" (goodness) de la anotación con respecto a los temas del texto de entrada. De esto modo podemos implementar ρ para descartar las anotaciones que estén debajo de un determinado umbral Lo parámetros para enviar la petición son estos: Key -requerido- el código alfanumérico para acceder a este servicio. (dicho código nos lo proporcionaran tras ponernos en contacto con ellos de manera gratuita) lang -opcional- el idioma del texto que se va a anotar. En este momento solo están el ingles y el italiano. Text -requerido- el texto que se va a anotar, en la codificación UTF-8. Se recomienda utilizar POST si el texto es muy largo. Existen otras aplicaciones como wikify o freeling. WIKIFY lo que hace es que, ingresando al sistema Wikify un texto no estructurado, este sistema identifica los conceptos importantes de dicho documento, devolviendo como salida las palabras clave del documento y los vínculos hacia artículos de Wikipedia de estas palabras clave. Es decir, Wikify identifica las palabras clave de un documento y las wikifica. Para su funcionamiento, el sistema tiene dos funciones: extracción de palabras clave y desambiguación, las cuales hacen uso de Wikipedia. Extracción de Palabras Clave Las palabras clave son palabras o frases que son representativas del contenido del texto analizado. En el proceso de extracción de frases candidatas a ser palabras clave, se seleccionan todos los ngramas (conjunto de una o más palabras) que son válidos dentro de algún vocabulario, y se calcula su ranking, para lo cual se utilizaron tres métodos: Tf-idf, X2-independence test y Key-phraseness. Desambiguación del Sentido de las Palabras Se proponen dos diferentes métodos de desambiguación: a) un método basado en conocimiento, este tipo de métodos se caracterizan por utilizar diccionarios, b) un método basado en probabilidades, caracterizado por obtener información de cantidades grandes de datos. Aquí se utiliza la palabra sentido para especificar cada uno de los vínculos (artículos de Wikipedia) hacia donde puede dirigirse una sola frase o palabra. 86

87 El proceso completo del sistema está dividido en cuatro fases: a) Si el documento es hipertexto, el sistema separa las etiquetas HTML del cuerpo del texto. b) El sistema pasa al módulo de extracción de palabras clave, las cuales identifican y marcan las palabras importantes y frases en el texto, determinadas por la probabilidad de que sean seleccionadas como vínculos. c) El módulo de extracción de palabras claves pasa el texto seleccionado hacia el módulo de desambiguación del sentido de las palabras, donde se resuelve la ambigüedad de los vínculos y completa las anotaciones con la referencia al artículo de Wikipedia correcto, utiliza un clasificador cuyas entradas son las características de la frase, sus palabras circundantes y son comparadas con ejemplos de entrenamiento obtenidos de toda Wikipedia. d) El sistema reconstruye la estructura del hipertexto original, incluyendo las nuevas referencias a los vínculos en el texto. Este enfoque requiere un esfuerzo computacional considerable, la mayor precisión de esta metodología en la fase de extracción de palabras clave es de un % en precisión, 55.9% en recall; en el proceso de desambiguación se obtiene una precisión del 94.33%, recall de 70.34% FREELING es un programa informático gratuito de análisis lingüístico. Está desarrollado por el Centre de Tecnologies i Aplicacions del Llenguatge i la Parla (TALP) de la Universitat Politècnica de Catalunya (UPC). Permite múltiples funciones, como división en oraciones, lematización, etc., para español, catalán, gallego, italiano e inglés (posee diccionarios específicos para cada lengua), y funciona bajo sistema operativo Linux. Existe una demo online para probar la aplicación. Otra mejora podría ser la agilización de la traducción manual. Este proceso consistiria en la utilización de la colaboración voluntaria de los alumnos y profesores de otras universidades. Como hemos explicado anteriormente, el MCR tiene todas las definiciones en ingles pero no están en todos los idiomas. El caso de uso que hemos implementado es de gran utilidad para realizar la traducción del ingles al castellano facilitando enormemente la labor de inserción en el MCR de las nuevas definiciones. Pero este proceso se realiza termino a termino y sabiendo que el MCR tiene miles de términos y cinco idiomas (ingles, español, euskera, gallego y catalán) es muy grande el trabajo que supone la inserción una a una de todas las definiciones en todas las lenguas y en este momento solo realizan este trabajo las personas que están directamente relacionadas con el proyecto. Un posible formula consistiría en que cada vez que accedamos al correo que nos proporciona la universidad, nos apareciera una pantalla en la cual tuviéramos la opción de colaborar con el proyecto editando la traducción que se nos proporciona del termino en ingles y tras realizar los cambios pertinentes (en caso de que haya que cambiar algo) guardarla en el MCR. Los alumnos y profesores no tendrían la obligación de colaborar con el proyecto (se pondría un botón no quiero colaborar y se saltaría de esta pantalla). Pero viendo el desarrollo de otros proyectos que se realizan de forma colaborativa sin que sus participantes reciban nada a cambio (un claro ejemplo es Wikipedia), podemos estimar que puede haber un gran numero de alumnos y profesores que participen. 87

88 La desventaja que nos encontramos ante esta opción es que la traducción la realizarían personas ajenas al proyecto, por lo tanto cabe la posibilidad de que alguien introduzca definiciones incorrectas queriendo. Aunque es de suponer que una persona que colabora de forma voluntaria, no introducirá definiciones incorrectas a propósito (de hecho, en la wikipedia la gran mayoría de los artículos tienen una calidad alta -excepto temas muy concretos que provocan controversia en la población). 88

89 8 CONCLUSIONES --- preguntar a german si lo pongo en primera persona del singular o si lo dejo en primera persona del plural --En este apartado explicaremos las conclusiones que hemos obtenido tras la elaboración del proyecto, haciendo referencia a los objetivos que nos habíamos planteado inicialmente. En primer lugar, cabe destacar que se han cumplido los objetivos planteados en la planificación inicial. Objetivo: nueva funcionalidad al MCR que traduce Hemos logrado introducir la nueva funcionalidad en el MCR cumpliendo los requisitos que se nos especificaron inicialmente. Objetivo: aprender a gestionar un proyecto Hemos sido capaces de darnos cuenta de las dificultades que entraña llevar a cabo un proyecto informático de estas características. Hemos sufrido retrasos a lo largo de todo el desarrollo del proyecto respecto a la planificación inicial, este hecho nos ha servido para darnos cuenta de que la experiencia a la hora de planificar un proyecto nos ayudara a estimar con mayor precisión el tiempo necesario para la consecución de los hitos. También hemos llegado a la conclusión de la importancia de la gestión y planificación del proyecto y del uso de herramientas adecuadas. La utilización de programas de planificación temporales (Ganttproject) nos ha permitido llevar un control mas exhaustivo sobre el desarrollo del proyecto y se puede ver claramente si estamos cumpliendo los hitos marcados, o si tenemos que realizar una replanificacion o si necesitamos mas recursos para cumplir los plazos marcados. Objetivo: formación en tecnologías Por otra parte, los conceptos que hemos tratado en la practica, así como la gestión de la misma, nos será de gran utilidad para nuestro futuro profesional, ya que, hemos manejado el proyecto de principio a fin como se debería de tratar a nivel profesional. En ninguna asignatura de la carrera se ven todos los conceptos relacionados entre si como los hemos podido ver al realizar este proyecto. Otro aspecto importante que hemos de destacar, a pesar de haber sido una dificultad en un primer momento, es la necesidad de autoformación en las tecnologías que hemos tenido que utilizar. En un principio, la falta de conocimiento sobre determinadas tecnologías nos provocaba una cierta incertidumbre a la hora de desarrollar el proyecto, nos hacia dudar de si íbamos a ser capaces de lograr la consecución de los objetivos que nos habíamos planteado inicialmente. Pues bien, tras la realización del proyecto, unos de los aspectos mas relevantes y de los que mas hemos aprendido a sido el tener que ser capaces de solventar de forma autónoma la falta de formación en estas tecnologías (recurriendo a manuales, libros, paginas web especializadas, foros, etc...). Esto nos ha servido para obtener conocimientos relevantes para un ingeniero informático, como conocer otro sistema operativo que no sea Windows, funcionamiento de CGI, utilización y funcionamiento de las 89

90 APIs, utilización de otro lenguaje de programación distinto a Java o a Ada, conocimiento de conceptos desconocidos hasta el momento (odontologías, web semántica, web 3.0, procesamiento del lenguaje natural, redes semánticas,...) 90

91 9 BIBLIOGRAFIA Como configurar apache Instalar apache y php5 Tutorial de perl-cgi Ejemplo perl-cgi Todo lo relacionado con Perl, CGI, Tutoriales interesantes Perl-CGI Formulario Cgi en perl con html Introduccion perl cgi Ejemplos de creación de una aplicación web CGI con Perl

92 Formularios html Php y phpmyadmin (php) (phpmyadmin) definicion y caracteristicas Web Web semantica y web title=web_2_0_web_semantica_web_3_0&more=1&c=1&tb=1&pb= Definicion y caracteristicas web semantica ( aplicaciones semanticas y web

93 tratamiento multilingue de la informacion Las APIs de Google y su politica Herramientas relacionadas con las mejoras futuras Redes semanticas

94 preguntar a german si meto algo de lo del estado del arte --Estado del arte Traductor a traves de voz entrevista estado del arte TA Documento sobre el estado del arte comparando google, babelfish y bing (10p) 94

95 10 GLOSARIO DE TERMINOS AJAX: acrónimo de Asynchronous JavaScript And XML ( JavaScript asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). API: (del inglés Application Programming Interface - Interfaz de Programación de Aplicaciones) se trata del conjunto de llamadas a ciertas bibliotecas que ofrecen acceso a ciertos servicios desde los procesos y representa un método para conseguir abstracción en la programación. Applet (Java): es un pequeño programa que es utilizado en una página HTML, representado por una pequeña pantalla gráfica. Se puede cargar y ejecutar desde cualquier explorador que soporte Java. Aptana: entorno de desarrollo (ide) dirigido a aplicaciones web. Base de Conocimiento: Una Base de Conocimiento (o knowledgebase en inglés; KB, kb or Δ) es un tipo especial de base de datos para la gestión del conocimiento. Provee los medios para la recolección, organización y recuperación computarizada de conocimiento. CCS: las hojas de estilo en cascada (Cascading Style Sheets, CSS) son un lenguaje formal usado para definir la presentación de un documento estructurado escrito en HTML o XML (y por extensión en XHTML). CGI: Interfaz de entrada común (en inglés Common Gateway Interface, abreviado CGI) es una tecnología de la Web que permite a un cliente solicitar datos de un programa ejecutado en un servidor web. DBI: son las siglas en inglés de Database independent interface for Perl. DOM: el Document Object Model es una API para acceder, añadir y cambiar dinámicamente contenido estructurado en documentos HTML. Domain-Ontology : es una ontología que utiliza alrededor de 200 etiquetas obtenidas de Dewey Decimal Classification para clasificar cada synset. EBML: acrónimo de Extensible Binary Meta Language (Meta Lenguaje Binario Extendible), fue diseñado como una extensión binaria simplificada de XML, con el propósito de almacenar y manipular datos de forma jerárquica con campos de longitud variable. Eclipse: es un entorno de desarrollo integrado (IDE) de código abierto independiente de una plataforma para desarrollar lo que el proyecto llama Aplicaciones de Cliente Enriquecido o RIA. GNU: la licencia pública general de GNU o mas conocida por su nombre eninglés GNU General Public License o simplemente su acrónimo del inglés GNU GPL, es una licencia creada por la Free Software Foundation a mediados de los 80, y está orientada principalmente a proteger la libre distribución, modificación y uso de software 95

96 Google Translate: es un sistema de traducción automática gratuito proporcionado por Google Inc, basado en datos estadísticos para traducir texto, documentos y páginas web a otras lenguas. HTML: sigla de HyperText Markup Language (Lenguaje de Etiquetas de Hipertexto), es el lenguaje predominante para la construcción de páginas web. HTTP: el protocolo de transferencia de hipertexto (HTTP, HyperText Transfer Protocol) es el protocolo usado en cada transacción de la Web. HTTPS: es la versión segura del protocolo HTTP. IDE: (entorno de desarrollo integrado o en inglés Integrated Development Environment ) Un IDE es un entorno de programación que ha sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica GUI. Iframe: (inline frame o marco incorporado en inglés) es un elemento HTML que permite insertar o incrustar un documento HTML dentro de un documento HTML principal. JavaScript: es un lenguaje de programación, utilizado principalmente en páginas web. JSON: acrónimo de JavaScript Object Notation, es un formato ligero para el intercambio de datos. JSON es un subconjunto de la notación literal de objetos de JavaScript que no requiere el uso de XML. LAMP: la tecnología LAMP se consigue mediante la unión de Linux + Apache + MySql + PHP, Perl o Python. MCR: (Multilingual Central Repository) repositorio multilingüe compuesto por distintos WordNets, enriquecido con relaciones semánticas y ontologías. Perl: (Practical Extraction and Report Language) es un lenguaje de programación usado normalmente para la creación de páginas web. PHP: es un lenguaje de programación usado para la creación de páginas web. PHP es un acrónimo recursivo que significa PHP Hypertext Pre-processor (inicialmente PHP Tools, o, Personal Home Page Tools). RIA: Rich Internet Applications (Aplicaciones Ricas de Internet) es un tipo de aplicación donde no se producen recargas de página, ya que desde el principio se carga toda la aplicación y sólo se produce comunicación con el servidor cuando se necesitan datos externos como datos de una Base de Datos o de otros ficheros externos. 96

97 RPC: (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. Script: conjunto de instrucciones que perminten la automatización de tareas. SUMO (Suggested Upper Merged Ontology): es una de las ontología utilizadas en investigación y aplicaciones de búsqueda, lingüística y razonamiento. Top-Ontology o TCO (Top Concept Ontology): es una ontología creada para codificar las relaciones léxico-semánticas de manera uniforme. XHTML: acrónimo inglés de extensible Hypertext Markup Language (lenguaje extensible de marcado de hipertexto), es el lenguaje de marcado pensado para sustituir a HTML como estándar para las páginas web. XML: sigla en inglés de Extensible Markup Language (lenguaje de marcas extensible), es una manera de definir lenguajes para diferentes necesidades. XMLHttpRequest (XHR): es una interfaz empleada para realizar peticiones HTTP y HTTPS a servidores WEB. Para los datos transferidos se usa cualquier codificación basada en texto, incluyendo: texto plano, XML, JSON, HTML y codificaciones particulares específicas. XML-RPC: es un protocolo de llamada a procedimiento remoto que usa XML para codificar los datos y HTTP como protocolo de transmisión de mensajes. WEI: (Web Eurowordnet Interface) es una interfaz web que permite realizar consultas al MCR. WordNet: es una base de datos léxica de dominio general para el inglés. 97

98 98

99 ANEXO 1 Encuestas Opiniones de usuarios. Lo bueno y lo mejorable para el futuro Con el objetivo de conocer la opinión de personas ajenas al proyecto, hemos realizado una encuesta con una serie de preguntas que nos servirán para saber lo que puede ser bueno o mejorable en un futuro tras el análisis de los resultados. Hemos realizado la encuesta sobre una muestra de 65 personas con edades comprendidas entre los 16 y 70 años. Para ello hemos utilizado dos métodos: Encuestas físicas en el centro comercial La Bretxa de Donostia-San Sebastian Encuestas online a través de las herramientas que ofrecen algunas redes sociales (en este caso hemos utilizado Facebook) Finalmente, hemos juntado los resultados de las encuestas realizadas por los diferentes medios y los hemos representado en las siguientes gráficas. 1 HAS UTILIZADO TRADUCTORES ONLINE? 99

100 Has utilizado traductores online? Si No Has utlizado traductores online? Si No Como podemos observar en los gráficos, casi el 90% de las personas encuestadas ha utilizado traductores online. Este dato es muy significativo por dos cuestiones: Las personas necesitamos con mas frecuencia acceder a información que nos es relevante pero que esta escrita en otros idiomas. Hace años si queríamos acceder a información que no estaba en nuestro idioma, no nos quedaba mas remedio que aprender ese idioma y utilizar diccionarios 100

101 (generalmente bilingües) para conocer el significado de determinadas palabras que no conocíamos. Las consultas a estos diccionarios bilingües nos daban una definición sintáctica de la palabra, pero no semántica, es decir, depende del contexto en que nos aparecía esa palabra no conseguíamos obtener el significado que estábamos buscando. Otro problema añadido es que podíamos aprender un idioma para comunicarnos y obtener información en ese idioma, pero si la información estaba en otro idioma que no era nuestro idioma materno (o el aprendido) ya no podíamos acceder a esa información. Estando en un mundo multilingüe y multicultural, la información que podemos necesitar puede estar en muy diferentes idiomas, por lo tanto, los traductores online han desempeñado (y están desempeñando) una labor muy importante a la hora de extender el conocimiento. La segunda conclusión que podemos extraer de esta pregunta es que si casi el 90% de los encuestados ha utilizado traductores online, podemos extrapolar que para que la gente los utilice tienen que tener acceso a Internet, por lo tanto es de destacar el espectacular aumento del numero de usuario que ha experimentado Internet en esta ultima década. De hecho en España el porcentaje de personas que han utilizado Internet en el ultimo mes es del 67% (y de estos internautas el 69,2% accede a diario según datos del estudio la sociedad de la información en España 2010 realizado por la fundación telefónica). Un dato significativo de que esta tendencia va en aumento es que el 97% de los estudiantes vascos utiliza Internet según datos del instituto vasco de estadística(eustat). También es de destacar las 101

102 2 COMO VALORARIAS, DEL 1 (MUY MALA) AL 10 (MUY BUENA), EL NIVEL DE LA TRADUCCION OBTENIDA CUANDO UTILIZAS UN TRADUCTOR ONLINE? Como valorarias, del 1 (muy mala) al 10 (muy buena), el nivel de la traduccion obtenida cuando utilizas un traductor online?

103 Como valorarias, del 1 (muy mala) al 10 (muy buena), el nivel de la traduccion obtenida cuando utilizas un traductor online? Como vemos en los gráficos la nota media que le ponen los encuestados a los traductores online es de un 6,25. tras analizar detenidamente los resultados hemos sacado las siguientes conclusiones: A la mayoría de las personas encuestadas les satisface la traducción obtenida pero no les parece que tiene la suficiente calidad. Este dato es relevante, porque la necesidad de que la traducción que nos ofrece sea aceptable no nos sirve en muchos casos en los que necesitamos de mayor precisión. Esta necesidad se aprecia claramente en el mundo globalizado en el que nos encontramos. Muchas empresas necesiten firmar documentación en idiomas en los que no están familiarizados. De hecho, se gasta mucho tiempo y dinero para que las empresas puedan entenderse y lleguen a realizar acuerdos comerciales. Las instituciones publicas también gastan mucho dinero, por ejemplo, la unión europea que posee 23 lenguas oficiales se gasta cada año millones de euros en la traducción de documentos o en la interpretación de discursos. Otro aspecto importante a destacar es que el 90% del contenido de Internet esta escrito en solo 12 lenguas de las 7000 existen en todo el planeta (según datos de la UNESCO). Por lo tanto, es una necesidad que las traducciones sean de calidad para que el conocimiento este accesible independientemente de la lengua materna de las personas e independientemente del idioma del texto original. 103

104 3) TE PARECE MAS FIABLE LA TRADUCCIÓN REALIZADA POR OTRO USUARIO ("ESTILO WIKIPEDIA") O LA QUE REALIZA UN TRADUCTOR ONLINE? Te parece mas fiable la traducción realizada por otro usuario ("estilo wikipedia") o la que realiza un traductor online? Te parece mas fiable la traducción realizada por otro usuario ("estilo wikipedia") o la que realiza un traductor 60 online? Usuario Usuario Traductor Traductor Es interesante extraer las conclusiones de esta pregunta ligándola también a la pregunta anterior. En un primer lugar vemos como la mayoría de la gente se fía mas de una traducción proporcionada por otro usuario que la que nos ofrece los traductores online actuales. Es evidente que este dato este relacionado con la calidad de las traducciones online, como vemos en los datos extraídos de la encuesta, tan solo un 14% puntúa con mas de un 7 a los traductores onlines. Por lo tanto, no es de extrañar que la gente se fíe mas de las definiciones 104