Índice de contenido
1.- INTRODUCCION...5
2.- ANTECEDENTES/CONTEXTO...5
2.1 Redes semanticas...6
2.2- Web semantica y web 3.0...20
2.3 Google, su política y sus apis...23
3.- DOCUMENTO OBJETIVOS DE PROYECTO (DOP):...26
3.1.- Objetivos:...26
3.2.- Alcance:...26
3.2.1.- Procesos:...26
3.2.2.- Alcance del proyecto:...28
3.2.3.- Diagrama de estructura de descomposición del trabajo (EDT):...29
3.3.- Método de Trabajo:...30
3.3.1.- Proceso Unificado de Desarrollo (PUD):...30
3.3.2.- Recursos Humanos:...32 3.3.3.- Recursos Materiales:...32 3.4.- Planificación temporal:...33 3.4.2.- Lista de entregas:...34 3.4.3.- Diagramas de Gantt:...35 3.5.- Plan de contingencia:...41 3.6.- Factibilidad:...42
4.- DESARROLLO DEL SISTEMA DE INFORMACIÓN (SI):...43
4.1.- Captura de requisitos:...43
4.1.1.- Caso de uso:...43
4.2.1 Modelo de Dominio...44
4.2 Analisis...45
4.2.1.- Caso de uso Obtener Traducción:...45
4.2.2.- Contrato...45
4.3.- Arquitectura del sistema:...46
4.4.- Eleccion tecnologica...48 4.4.1.- Php...48 4.4.2.- Perl...49 4.4.3.- Phyton...52 4.5.- Solucion tecnologica...53 4.5.1.- Perl:...53 4.5.2.- Apache...54 4.5.3 Phpmyadmin...55 4.5.4 Mysql...55 4.6.- Diseño...56 4.7.- Implementacion...57 5. PRUEBAS...63 5.1 Tipos de pruebas...63 5.2 Proceso de implantación...64 6 GESTION...65 6.1 Primera iteración...65 6.2 Segunda Iteración...67 6.3 Tercera Iteración...70
6.4 Cuarta Iteración...72 6.5 Quinta Iteración...74 6.6 Comparativa Total...76 7 MEJORAS FUTURAS...83 8 CONCLUSIONES...87 9 BIBLIOGRAFIA...89 10 GLOSARIO DE TERMINOS...93
ANEXO 1 Encuestas Opiniones de usuarios. Lo bueno y lo mejorable para el futuro...97
Í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 3.1.. 13
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 2011...23
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.. . .40
Figura 4.0. Modelo de dominio...46
Figura. 4.1. 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 1...68
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
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...69
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...70
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
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...71
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
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...73
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
Figura 6.10. 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...75 Figura 6.11. 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 Figura 6.12. 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...77 Figura 6.13. 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 Figura 6.14. 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 6.15. 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 6.16. 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 6.17. Comparativa de las horas estimadas en la planificación del análisis y las horas reales que hemos invertido en Total...82 Figura 6.18. 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: http://www.youtube.com/watch?v=0bS2PGKSwqY
1.- 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
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,...)
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:
02383458#n car#1
01173875#v do#2 00669611#a blue#4 00088530#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:
09396070#n tree#1; representa la planta que se ramifica a través de un tallo leñoso. 10025462#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:
02383458#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
relaciones del synset. Por ejemplo:
02383458#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
POS Unique string Synsets Total Word-Sense Pairs Noun 117798 82115 146312 Verb 11529 13767 25047 Adjective 21479 18156 30002 Adverb 4481 3621 5580 Totals 155287 117659 206941
Tabla 2.2. Muestra el numero de palabras, synsets y sentidos
POS Monosemous Polysemous Polysemous Words and Senses Words Senses
Noun 101863 15935 44449
Verb 6277 5252 18770
Adjective 16503 4976 14399
Adverb 3748 733 1832
Totals 128391 26896 79450
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
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
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,
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 1.642.389 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 466.972 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
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.
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.
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.
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.
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.
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: (http://www.globalwordnet.org/gwa/ wordnet_table.htm )
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.
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 100000 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.
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.
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 2011.
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.
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
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
---3.- DOCUMENTO OBJETIVOS DE PROYECTO (DOP):
3.1.- 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.
3.2.- Alcance:
3.2.1.- 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
○ 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
3.2.2.- 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.
3.2.3.- Diagrama de estructura de descomposición del trabajo (EDT):
3.3.- Método de Trabajo:
3.3.1.- 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
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 un producto mas robusto, puesto que los errores se van corrigiendo en cada iteración. •El 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.
3.3.2.- 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.
3.3.3.- 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 (http://www.ubuntu.com/ ) 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.
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.
3.4.2.- 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.
3.4.3.- 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
• 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
• 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
• 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
• 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
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
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
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.
4.- DESARROLLO DEL SISTEMA DE INFORMACIÓN (SI):
4.1.- Captura de requisitos:
4.1.1.- 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.
4.2.1 Modelo de Dominio
--- preguntar a german como es el Modelo de dominio --- REALIZAR dibujo MODELO DE DOMINIO
4.2 Análisis
4.2.1.- Caso de uso Obtener Traducción:
4.2.2.- 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
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. 4.1. 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
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
4.4.- Elección tecnológica
4.4.1.- 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
• 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.
4.4.2.- 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.
