INDICErigau/teaching/EHU/PFCs/... · 2009. 7. 7. · Proyecto final de carrera: Maria Eguimendia La...

Proyecto final de carrera: Maria Eguimendia

INDICE

Introducción ................................................................................................................ pág. 3Antecedentes ............................................................................................................... pág. 4

Redes Semánticas ............................................................................................ pág. 4WordNet .......................................................................................................... pág. 4EuroWordNet .................................................................................................. pág. 9Proyecto Meaning ........................................................................................... pág. 9Multilingual Central Repository (MCR) ........................................................ pág. 10Interfaces Web ................................................................................................ pág. 11

WordNet .............................................................................................. pág. 11Thesaurus ............................................................................................ pág. 12Treebolic ............................................................................................. pág. 14Wei (Web Eurowordnet Interface) ...................................................... pág. 15Deb (Dictionary Editor and Browser) ................................................. pág. 16Otros .................................................................................................... pág. 17

Documento objetivos de proyecto (DOP) ................................................................... pág. 19Objetivos ......................................................................................................... pág. 19Alcance ........................................................................................................... pág. 19

Procesos .............................................................................................. pág. 19Alcance del proyecto ........................................................................... pág. 20EDT ..................................................................................................... pág. 21

Método de trabajo ........................................................................................... pág. 22Proceso unificado de desarrollo (PDU) .............................................. pág. 22 Recursos Humanos ............................................................................. pág. 22Recursos Materiales ............................................................................ pág. 23

Planificación temporal .................................................................................... pág. 23Fases .................................................................................................... pág. 23Lista de entregables ............................................................................. pág. 24Diagrama de Gantt .............................................................................. pág. 25

Plan de contingencia ....................................................................................... pág. 25Factibilidad ..................................................................................................... pág. 27

Arquitectura del sistema ............................................................................................. pág. 28WEI y MCR .................................................................................................... pág. 28Elección Tecnológica ...................................................................................... pág. 28

Google Web Toolkit (GWT) ............................................................... pág. 29Librerías Ajax - Dojo Toolkit ............................................................. pág. 30

1


PHP .................................................................................................... pág. 33Perl ..................................................................................................... pág. 36

Solución tecnológica ..................................................................................... pág. 37Perl ..................................................................................................... pág. 37Apache ............................................................................................... pág. 38PhpMyAdmin .................................................................................... pág. 39MySql ................................................................................................ pág. 40

Desarrollo del Sistema de Información ..................................................................... pág. 41Captura de requisitos ..................................................................................... pág. 41

Caso de uso ........................................................................................ pág. 41Modelo del dominio ........................................................................... pág. 42

Análisis .......................................................................................................... pág. 43Arquitectura ................................................................................................... pág. 46Diseño ............................................................................................................ pág. 47Implementación ............................................................................................. pág. 47

Pruebas ...................................................................................................................... pág. 52Pruebas unitarias ........................................................................................... pág. 52Pruebas de integración .................................................................................. pág. 53Proceso de implantación ............................................................................... pág. 53

Gestión ...................................................................................................................... pág. 54Conclusiones ............................................................................................................. pág. 57Bibliografía ............................................................................................................... pág. 58Glosario de términos ................................................................................................. pág. 60

2


1.- INTRODUCCIÓN:

Este proyecto de final de carrera se enmarca dentro del área de investigación de la Inteligencia Artificial, y 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, enriquecido con relaciones semánticas y ontologías.

Se pretende modificar la interfaz gráfica del MCR (Multilingüal Central Repository) de modo que no se requiera pre-instalar ningún componente adicional para poder ver la página en cualquier navegador.

Este proyecto tiene una doble finalidad. Por una parte tenemos el lado docente, que ha permitido aprender más en profundidad un sistema operativo como linux y lenguajes orientados a

la capa de presentación como son PHP y PERL. Y por otra parte, la investigación en el entorno

Web, ya que el proyecto nos ha permitido comprobar la diversidad de opciones para dicho

desarrollo.

Este proyecto de fin de carrera ha sido realizado bajo la supervisión de German Rigau (profesor del departamento de lenguajes y sistemas informáticos).

3


2.- ANTECEDENTES:

Antes de comenzar con el desarrollo del proyecto, debemos introducir algunos conceptos fundamentales, que nos situarán dentro del entorno de desarrollo.

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.

Existen diversos tipos de relaciones semánticas como la sinonimia, antonimia, hiponimia, hiperonimia, la meronimia, etc.

Una de las redes semánticas más conocidas es WordNet.

2.2.- WORDNET:

WordNet1 (Miller et al., 1990), 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.

1 Se puede consultar la base de datos completa en http://wordnet.princeton.edu/

4


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:

Los homónimos y los sentidos relacionados de las palabras polisémicas reciben el mismo tratamiento, a diferencia de los diccionarios convencionales, que suelen asignar a los homónimos entradas independientes, mientras que los sentidos relacionados de una palabra polisémica se agrupan bajo una misma entrada.

A partir de la versión 1.7 todos los synsets de WN incluyen una glosa que, a modo de las definiciones de diccionario, explicita el concepto que de forma implícita está expresado por el synset. 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 conjunto de variantes sinonímicas establece con los demás synsets.

Entre las relaciones semánticas contempladas en WN una de las más importantes, además de la sinonimia (implícita en la noción de synset), es la relación de hiponimia-hiperonimia. Esta relación de IS-A proporciona a los synsets nominales y verbales una estructura jerárquica. Cada concepto en los subsistemas de nombres y verbos está ligado a su hiperónimo, excepto los � unique beginners� que forman los nodos superiores de la jerarquía.

Otras relaciones que se pueden establecer entre synsets son:

1. Meronimia / Holonimia. Relación HAS_A en sus variantes parte, miembro y sustancia. Por ejemplo,

Noun � cake�Sense3. cake � (made from or based on a mixture of flour and sugar and eggs)Has part: crumb � (small piece of e.g. bread or cake)

5


Noun � cherry�Sense3. cherry � (fruit with a single hard stone)Part of: cherry, cherry tree � (any of numerous trees and shrubs producing a small fleshy round fruit with a single hard stone; many also produce a valuable hardwood)

2. Antonimia. Relación que se establece entre palabras opuestas, distinguiendo entre los antónimos directos:

Verb � love�Sense1Love � (have a great affection or liking for; � I love French food� ; � She loves her

boss and works hard for him� )Antonym of hate (Sense1) => hate, detest � (dislike intensely; feel antipathy or aversion towards; � I hate Mexican food� ; � She detests politicians� )

Y los antónimos indirectos, por ejemplo:

Adjective � humid�Sense1Humid � (containing or characterized by a great deal of water vapor; � humidair� ; � humid weather� )Indirect Antonym (VIA wet) øà dry � (free from liquid or moisture; lacking natural or normal moisture or depleted of water; or no longer wet; � dry land� ; � dry clothes� ; � a dry climate� ; � dry splintery boards� ; � a dry river bed� ; � the paint is dry� )

3. Implicación con la variante de Troponimia relaciones de causa-efecto, coexistencia e inclusión que afectan acciones. Las relaciones de implicación y troponimia se establecen entre verbos, por ejemplo:

Verb � goose-step�Sense1goose step � (march in a military fashion) => march, process � (march in a procession; � They processed into the dining room� )

4. Atributo - Valor. Relación entre los adjetivos calificativos y los nombres que expresan el atributo correspondiente. Por ejemplo:

6


Adjective � long�Sense1long (vs. short) � (primarily temporal sense; being or indicating a relatively great or greater than average duration or passage of time or a duration as specified; � a long life� ; � a long boring speech� ; � a long time� ; � a long friendship� ; � a long game� ; � long ago� ; � an hour long� ) => duration, length � (continuance in time; � the ceremony was of short duration� ; � he complained about the length of time required� )

5. Pertenece_a. Relación que une los adjetivos relacionales con los nombres correspondientes. Por ejemplo:

Adjective � fraternal�Sense1fraternal � (of or relating to a fraternity or society of usually men; � a fraternal order� )Pertains to noun brotherhood (Sense2) => brotherhood, fraternity, sodality � (people engaged in a particular occupation; � the medical fraternity� )

Como se puede apreciar, WN contempla relaciones tanto puramente semánticas, como relaciones de naturaleza morfológica. Así, los adjetivos denominales tienen enlaces a los nombres de los que derivan. De la misma manera, los adverbios están ligados con sus adjetivos base. Por ejemplo:

Adverb � beautifully�Sense1beautifully, attractively � (in a beautiful manner; � her face was beautifully made up� )Derived from adj beautiful (Sense1) => beautiful (vs. ugly) � (delighting the senses or exciting intellectual or emotional admiration; � a beautiful child� ; � beautiful country� ; � a beautiful painting� ; � a beautiful theory� ; � a beautiful party� )

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

7


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:active#a#1 ANTONYM_OF inactive#a#2inactive#a#2 ANTONYM_OF active#a#2

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#2milk#n#1 HAS_SUBSTANCE protein#n#1family#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#1protein#n#1 SUBSTANCE_OF milk#n#1child#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. En la tabla 2.1 se comparan el volumen de los synsets para cada categoría sintáctica en las distintas versiones de WordNet.

WordNet

PoS 1.5 1.6 1.7 1.7.1 2.0 2.1 3.0

NounVerbAdjetiveAdverb

6055711363132313243

6602512127179153575

7448812754185233612

7580413214214603629

7968913508185633664

8142613650188773664

8211513767181563621

Total Synset 91591 99642 109377 111223 115424 117597 117659

Tabla 2.1: Número de synsets en distintas versiones de WordNet

8


2.3.- 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 Organization� 3 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. EWN fue creado como un conjunto de módulos independientes.

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).

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.

2.4.- PROYECTO MEANING:

Meaning4 (Rigau et al., 2002) 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 WWW y construcción de recursos léxicos multilingües que sirvan de soporte para una

2 http://www.illc.uva.nl/EuroWordNet/3 http://www.globalwordnet.org/4 http://www.lsi.upc.es/~nlp/meaning/meaning.html

9


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 proponía enriquecer su estructura con nueva información léxico-semántica extraída automáticamente de la web. Como resultado de este trabajo se han generado 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.

2.5.- MULTILINGÜAL CENTRAL REPOSITORY (MCR):

El MCR5 (Multilingual Central Repository) (Atserias et al., 2004) es el resultado de la fusión de distintos recursos (diversas versiones de WordNet (WN1.5, WN1.6, WN1.7, WN1.7.1, WN2.0), ontologías y bases del conocimiento) que se llevó a cabo en el proyecto MEANING.

5 http://www.lsi.upc.es/~nlp/meaning/demo/demo.html

10


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 Domains, Top Concept Ontology6 o SUMO7.

Para poder interactuar con el MCR se desarrolló WEI8 (Web Eurowordnet Interface) que es una interfaz web que permite realizar consultas en este sistema.

2.6.- INTERFACES WEB:

Para este proyecto además de lo mencionado anteriormente, nos hemos centrado en interfaces Web relacionadas con Bases de Conocimiento.

2.6.1.- WORDNET:

Sin ir más lejos tenemos el ejemplo de WordNet, 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 con 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.2, podemos ver una imagen de dicha interfaz. En ella aparece el resultado obtenido trás indicarle que la palabra a buscar es car, y dejando todos los valores de visualización por defecto, esto es, que nos muestre las glosas y los ejemplos.

6 http://www.globalwordnet.org/gwa/ewn_to_bc/ewnTopOntology.htm7 http://suo.ieee.org/SUO/SUMO/index.html8 http://adimen.si.ehu.es/cgibin/wei5/public/wei.consult.perl

11


Figura 2.2: Resultado obtenido por la interfaz de consulta al Wordnet

Esta página es accesible desde: http://wordnet.princeton.edu/perl/webwn.

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 árbol dinámico donde podemos acceder a los distintos nodos, pero sin la representación en forma de árbol a la que estamos acostumbrados.

2.6.2.- THESAURUS:

Otro proyecto interesante es Thesaurus, producto creado por ThinkMap y accesible desde: http://www.visualthesaurus.com/.

Este producto se puede adquirir previo pago, aunque dispone de una demostración en la que se puede comprobar su funcionamiento.

12

http://wordnet.princeton.edu/perl/webwn

http://www.visualthesaurus.com/


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 pinchar en cualquiera de los nodos, mostrándonos entonces las relaciones del nuevo nodo.

En la figura 2.3 se muestra el resultado en forma de árbol que proporciona la interfaz Thesaurus cuando el término a buscar es car y le pedimos que nos muestre los resultados en los idiomas inglés y español.

Figura 2.3: Resultado obtenido por la interfaz de consulta al Thesaurus.

13


2.6.3.- TREEBOLIC:

Treebolic 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). Lo podemos encontrar aquí:http://treebolic.sourceforge.net/en/home.htm

Este proyecto esta basado en Wordnet.

En la figura 2.4 podemos ver un ejemplo de la interfaz de consulta Treebolic. Como podemos ver, la búsqueda se ha hecho utilizando la palabra net.

Figura 2.4: Representación de una consulta en la interfaz Treebolic.

14

http://treebolic.sourceforge.net/en/home.htm


2.6.4.- WEI (Web Eurowordnet Interface):

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.5 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.5: Resultado obtenido por la interfaz de consulta WEI.

15


Dicha interfaz es accesible desde: http://garraf.epsevg.upc.es/cgi-bin/wei4/public/wei.consult.perl

2.6.5.- DEB (Dictionary Editor and Browser):

Proyecto creado en la Universidad de Masaryk, en la República Checa, similar al Wordnet. 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.

Es una interfaz gráfica compuesta de varios idiomas entre los que encontramos el Inglés y el Checo.

En la figura 2.6 se muestra la arquitectura cliente/servidor que emplea.

Figura 2.6: Arquitectura cliente/servidor empleada por DEB.

En la figura 2.7 tenemos un ejemplo de la interfaz de consulta del DEB. Como podemos ver, permite seleccionar el diccionario por el cual queremos realizar la búsqueda.

16

http://garraf.epsevg.upc.es/cgi-bin/wei4/public/wei.consult.perl


Figura 2.7: Resultado obtenido por la interfaz de consulta DEB.

Dicha interfaz es accesible desde: http://deb.fi.muni.cz/index.php

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 VisDic.

2.6.6.- 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:

17

http://deb.fi.muni.cz/index.php


http://www.cozyenglish.com/dictionaryhttp://grokitbetter.com/http://nalanda.nitc.ac.in/reference/general/wordnet/wordnet.htmlhttp://www.golovchenko.org/cgi-bin/wnsearchhttp://poets.notredame.ac.jp/cgi-bin/wn

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 para el Multilingual Central Repository, pudiendo así en un futuro sustituir la interfaz actual desarrollada en Java por otra interfaz no Java, esto es, por una que no necesite cargar la máquina virtual de Java.

18

http://poets.notredame.ac.jp/cgi-bin/wn

http://www.golovchenko.org/cgi-bin/wnsearch

http://nalanda.nitc.ac.in/reference/general/wordnet/wordnet.html

http://grokitbetter.com/

http://www.cozyenglish.com/dictionary


3.- DOCUMENTO OBJETIVOS DE PROYECTO (DOP):

3.1.- Objetivos:

Con la realización de este proyecto se pretende modificar la interfaz actual del MCR (Multilingual Central Repository). Esto es necesario ya que para la correcta visualización de la interfaz actual se necesita la instalación de la JVM (Java Virtual Machine). Al modificar dicha interfaz, pretendemos que no haga falta instalar ningún tipo de componente para consultar el MCR.

Para interactuar con el MCR, se utiliza la interfaz WEI (Web EuroWordnet Interface) que permite realizar las consultas en este sistema. Lo que pretendemos hacer es modificar la parte de la interfaz que está realizada en Java, haciendo que funcione de otro modo, esto es con otro lenguaje de programación que no requiera instalar ningún componente para ser visualizado y que dicha parte se conecte como hasta ahora con la interfaz WEI, de modo que la nueva interfaz siga funcionando igual que la que existe actualmente.

Aunque existen versiones más modernas del MCR y del WEI, nosotros trabajaremoscon versiones anteriores.

3.2.- Alcance:

3.2.1.- Procesos:

Hay tres tipos de procesos: los procesos tácticos, los procesos operativos y los procesos formativos.

-Procesos operativos:

Captura de requisitosModelo de Casos de Uso

AnálisisDiagrama de Secuencia del Sistema

Diseño

19


Diseño de la capa de presentaciónImplementación

Modificación capa de presentaciónPruebas

Verificación de datosInstalaciónElaboración de la Memoria

-Procesos tácticos:

PlanificaciónRealización del DOPDiseño arquitectónico

ReunionesOrdinariasExtraordinarias

ControlAprobación final del proyecto

-Procesos formativos:

Linux (Sistema Ubuntu)MCRPhpMyAdminPHPPerlWordNetEuroWordNetMySql

3.2.2.- Alcance del proyecto:

− Se debe poder visualizar correctamente la interfaz sin la necesidad de cargar la máquina virtual de Java (JVM). Para ello se desarrollará con otro lenguaje de programación.

− Se debe poder visualizar correctamente el resultado de la consulta. Respetando lo desarrollado anteriormente y permitiéndonos las mismas opciones.

20


− Se comprobará que el resultado obtenido sea igual al proporcionado por el WEI actual, esto es, por la interfaz actual cuando las opciones seleccionadas sean las mismas. Ya que nuestro objetivo es realizar una interfaz que realice las mismas búsquedas obteniendo como es obvio los mismos resultados.

3.2.3.- Diagrama de estructura de descomposición del trabajo (EDT):

Captura de requ isitos

Aná lisis

Diseño

Im plem entación

Pruebas

Instalación

Modelo de casos de uso

Diagrama d e secuencia d el

sistema

Diseño d e la capa d e presentación

Mod ificación capa d e presentación

Verificación de datos

Elaboración de la m em oria

Proyecto

Procesos operativos

Plan ificación

Reuniones

Control

Aprobación final d el proyecto

Realización del DOP

Diseño arqu itectónico

Ord inarias

Extraordinarias

Procesos tácticos

Linux

MCR

PhpMyAdm in

PHP

Perl

WordN et EuroWordN et

MySql

Procesos form ativos

Figura 3.1: Diagrama de estructura de descomposición del trabajo.

21


3.3.- Método de Trabajo:

3.3.1.- Proceso Unificado de Desarrollo (PDU):

Para desarrollar un proyecto de este tipo es necesario seguir uno de los métodos de desarrollo de software que encontramos dentro del campo de la Ingeniería del Software. El método elegido para este proyecto es el Proceso Unificado de Desarrollo de Software (PDU).Este proceso se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y ser iterativo e incremental.

Los pasos a seguir son los siguientes: Identificar y especificar los casos de uso relevantes (captura de requerimientos). Realizar un análisis de ellos, crear un diseño, implementar el diseño mediante componentes, y realizar las pruebas necesarias para verificar que los componentes satisfacen los casos de uso. Si una iteración cumple con sus objetivos, el desarrollo continúa con la siguiente. Si no se deben revisar las decisiones previas y probar con un nuevo enfoque.

En cuanto a las reuniones con el director de proyecto, intentaremos efectuar una por cada fase del proyecto a las que denominaremos reuniones ordinarias. Si surgiese algún tipo de complicación y/o imprevisto se realizarán las llamadas reuniones extraordinarias. De todas formas habrá un contacto continuo vía correo electrónico con el director de proyecto.

Para acceder a cualquier tipo de información necesaria para la realización del proyecto dispondremos de una conexión a Internet vía Wifi.

El almacenamiento de los datos se realizará en el ordenador de la alumna. Para evitar posibles pérdidas se realizarán copias de seguridad de la información cada cierto tiempo.

3.3.2.- Recursos Humanos:

El principal recurso humano es el tiempo. La estimación del tiempo está en 350horas/persona.

22


3.3.3.- Recursos Materiales:

Para la realización de este proyecto, además del material de oficina como son los folios y los bolígrafos utilizaremos un ordenador con el software necesario. También dispondremos de libros e Internet para la búsqueda de información.

Para la realización de las reuniones, se acudirá al despacho del director de proyectos.

Se utilizará el sistema operativo Linux como base del proyecto, en nuestro caso el sistema Ubuntu, MySQL como gestor de bases de datos (SGBD), en nuestro caso phpMyAdmin y un lenguaje de programación distinto a Java para el desarrollo del mismo.

3.4.- Planificación temporal:

El proyecto dispondrá de una única iteración dividida en distintas fases.

3.4.1.- Fases:

Fase 0: Gestión del proyecto.

-Desarrollo del DOP: Se desarrollarán las versiones necesarias del documento de objetivos de proyecto (DOP).

-Selección de herramientas: Para cada proceso, donde sea necesario, se seleccionará el material (software, hardware, etc.) mas apropiado según las necesidades.

-Reuniones y documentos: Periódicamente se reunirán profesor y alumna para revisar las tareas y acordar las nuevas a desarrollar.

Fase1: Análisis del Entorno.

-La alumna se familiarizará con todo lo referente a lo que rodea el problema.

23


Fase2: Desarrollo técnico.

-Captura de requisitos: Se usará el modelo de casos de usos para obtener las funcionalidades que debe tener nuestra aplicación.

-Análisis: Se analizarán los aspectos que se describen en la captura de requisitos, refinándolos y estructurándolos.

-Diseño: Modelaremos el sistema y llegaremos a un acuerdo para encontrar su forma (y su arquitectura) para que soporte todos los requisitos exigidos.

-Implementación: Construiremos la aplicación con lo diseñado y acordado.

-Pruebas: Se testeará la herramienta para su correcto funcionamiento. Se mirarán por un lado sus módulos individualmente y, por otro, todo en su conjunto.

Fase3: Cierre de la iteración.

-Se gestionará todo lo necesario para la entrega del software y documentación. Una vez obtenidos los resultados de la iteración se compararán la idea inicial con el resultado final extrayendo conclusiones y posibles mejoras futuras.

3.4.2.- Lista de entregas:

Al término de la iteración, se entregarán:

-La memoria del proyecto-La versión definitiva de la interfaz-Las nuevas versiones de todos los ficheros que hayan sido modificados.

24


3.4.3.- Diagramas de Gantt:

Id. Nombre de tarea Comienzo Finjul 2007 ago 2007 sep 2007 oct 2007 nov 2007

9/9 21/1016/912/8 26/8 2/919/85/8 23/9 11/1129/7 30/91/7 8/7 4/117/10 28/1014/1015/7 18/11 25/1122/7

1 30/04/200802/07/2007GESTIÓN DEL PROYECTO

2 16/07/200702/07/2007Desarrollo del DOP

3 25/07/200716/07/2007Selección de herramientas

4 30/04/200802/07/2007Reuniones ordinarias

5 31/01/200802/07/2007ANÁLISIS DEL ENTORNO

6 31/01/200801/10/2007Búsqueda de información

7 31/12/200701/10/2007Formación

10 10/10/200701/10/2007Captura de requisitos

12 31/10/200722/10/2007Diseño

13 31/01/200801/11/2007Implementación

14 15/02/200801/02/2008Pruebas

15 30/04/200801/01/2008CIERRE DE LA ITERACIÓN

16 31/03/200817/03/2008Preparar los entregables

17 30/04/200801/01/2008Elaborar la memoria

18 15/04/200801/04/2008Instalación

9 15/02/200801/10/2007DESARROLLO TÉCNICO

11 19/10/200701/10/2007Análisis

8 28/09/200702/07/2007Elección tecnológica

dic 2007 ene 2008 feb 2008 mar 2008 abr 2008

2/12 9/12 16/12 23/12 30/12 6/1 13/1 20/1 27/1 3/2 10/2 17/2 24/2 2/3 9/3 16/3 23/3 30/3 6/4 13/4 20/4

Figura 3.2: Diagrama de Gantt en el que se muestra la planificación del proyecto.

Estimación horas/tarea:

Desarrollo del DOP --------------> 10hSelección de herramientas ------> 4hReuniones ordinarias ------------> 10hBúsqueda de información -------> 20hFormación ------------------------> 20hElección tecnológica -------------> 100hCaptura de requisitos -------------> 4hAnálisis ----------------------------> 4hDiseño -----------------------------> 4hImplementación -------------------> 100hPruebas -----------------------------> 10hPreparar entregables --------------> 2hElaborar memoria -----------------> 60hInstalación --------------------------> 2h

Total ====================> 350h

3.5.- Plan de contingencia:

A continuación se comentan una serie de riesgos o imprevistos que pudieran suceder a lo largo de la elaboración del proyecto y que afectarían directamente a la realización del

25


mismo. Junto a cada riesgo se ofrece una posible solución o posibles medidas de prevención para minimizar en lo posible los daños que se causarían.

Clasificaremos los riesgos en tres grandes grupos: formativos, operativos y tácticos.

Riesgos formativos:

Riesgo: Que surgan dudas sobre algún tema relacionado con el proyecto (MCR, Linux,

Perl) que puedan hacer perder un tiempo excesivo buscando información para solucionarlas.

Solución: Se concertará una reunión con el director del proyecto para intentar aclarar las

posibles dudas minimizando el impacto negativo en horas que pudiera surgir.

Riesgos operativos:

Riesgo: Problemas de manejo del software elegido (programas, lenguajes de

programación) debido al desconocimiento de las herramientas.

Solución: En el caso de tener problemas en este aspecto, recurriremos a libros, manuales

o información publicada en Internet que nos ayuden a comprender y manejar las aplicaciones elegidas para desarrollar el proyecto. En caso de no conseguir avances en este respecto, plantearemos la posibilidad de utilizar software alternativo.

Riesgo: Pérdida de archivos por errores software, problema muy importante ya que nos

podría hacer perder muchas horas de trabajo.

Solución: Realizaremos copias de seguridad o backups periódicamente. Todas las copias

de seguridad se almacenarán tanto en el disco duro como en un dispositivo externo (memoria USB o CD).

Riesgo: Problemas hardware que imposibiliten el hecho de trabajar con nuestro equipo.

Solución: Tenemos que tener previsto un segundo equipo con el software básico

instalado para poder seguir trabajando en él, mientras es reparado el primero.

Riesgos tácticos:

Riesgo: El director del proyecto o la alumna no pueden acudir a una reunión acordada

26


debido a algún imprevisto (reuniones de trabajo, enfermedad, etc.).

Solución: Se comunicará con la mayor brevedad posible la imposibilidad de acudir a

dicha reunión y se propondrá otra fecha para la realización de la misma.

Riesgo: Se prevee que los plazos establecidos van a sufrir ligeras desviaciones.

Solución: Hacer reuniones periódicas (o tratarlo en las reuniones acordadas) para

discutir la gestión del calendario con el fin de arreglar los ajustes que los contratiempos puedan haber causado a la planificación del proyecto.

3.6.- Factibilidad:

Para determinar si el proyecto es factible o no, vamos a estudiar la factibilidad desde el punto de vista técnico, económico y operacional.

Factibilidad técnica:

- Después de comprobar el sistema y los antecedentes, queda claro que existen varias alternativas que se pueden emplear para resolver adecuadamente el problema que se nos plantea. Esto es, que disponemos de la tecnología necesaria para llevar a cabo el proyecto.

Factibilidad económica:

- Intentaremos que el coste del proyecto sea cero, ya que siempre que podamos trabajaremos con software libre.

Factibilidad operacional:

- Para aquellos usuarios que esten acostumbrados a interactuar con la interfaz, dicho cambio no les supondrá ningún problema, ya que pretendemos que el sistema siga funcionando de la misma forma. Además intentaremos que el impacto visual sea el menor posible.

Por todo esto, podemos concluir que la realización de una nueva interfaz para el

MCR, desarrollada en otro lenguaje de programación distinto a Java, resulta factible.

27


4.- ARQUITECTURA DEL SISTEMA:

En este apartado, trataremos de explicar la arquitectura del sistema antes de comenzar con el

desarrollo del proyecto, las distintas opciones tecnológicas que intentamos utilizar para solucionar el problema que se nos planteaba y finalmente la información de la solución obtenida.

4.1.- WEI y MCR:

Nuestro sistema sigue una arquitectura cliente-servidor, donde los clientes realizan la

consulta. Dicha petición es procesada por el servidor, que devuelve un resultado al cliente.

La arquitectura está compuesta de tres capas:

La capa de presentación, aquello que se le mostrará al cliente está desarrollada en dos lenguajes de programación distintos. La parte que corresponde al formulario que el cliente debe cumplimentar es la que está desarrollada en Java, y la parte que procesa la respuesta está en Perl.

La capa de negocio está íntegramente desarrollada en Perl, en ella es donde encontramos las funciones necesarias para tratar las peticiones de los usuarios y las llamadas necesarias a la base de datos para obtener la respuesta.

La capa de datos está desarrollada en MySql. Está compuesta por múltiples tablas en las que se encuentra almacenada la información.

Para modificar la parte desarrollada en Java, existen distintas alternativas, entre las que se encuentran la de utilizar tecnología Ajax o utilizar lenguajes de scripts. Parte del tiempo invertido en este proyecto consistió en probar varias alternativas que trataremos de describir a continuación.

4.2.- Elección tecnológica:

Para llevar a cabo dicho proyecto, primeramente se investigó un poco sobre las distintas alternativas a Java, entre ellas se encontraban la posibilidad de utilizar la tecnología AJAX o utilizar algún otro lenguaje de programación como PHP o Perl.

28


Primeramente decidimos buscar alguna herramienta que permitiese traducir código Java a JavaScript. Encontramos dos herramientas capaces de realizar dicha tarea, GWT (Google Web Toolkit) y J2S (JavaToJavaScript).

4.2.1.- Google Web Toolkit:

GWT o Google Web Toolkit es un framework creado por Google que

permite ocultar la complejidad de varios aspectos de la tecnología AJAX. Es compatible con todos los navegadores lo cual es muy importante ya que los distintos navegadores necesitan de distinto código. El concepto de Google Web Toolkit es bastante sencillo, básicamente lo que se debe hacer es crear el código en Java usando cualquier entorno de desarrollo (IDE) de Java y el compilador lo traducirá a HTML y JavaScript.

GWT contiene los siguientes componentes:

• GWT Java-to-JavaScript Compiler: la función de este componente es

traducir el código desarrollado en Java al lenguaje JavaScript. Lo empleamos cuando usamos al GWT en modo web.

• Hosted Web Browser: este componente ejecuta la aplicación Java sin

traducirla a JavaScript, en modo host usando la máquina virtual de Java.

• JRE Emulation Library: contiene las librerías más importantes de las

Clases de Java: java.lang en donde se encuentran las clases fundamentales para poder programar en Java y un subconjunto de las clases del paquete java.util. Java.lang incluye, entre otras, la clase java.lang.object que es la clase fundamental de la que heredan o extienden todas las clases en Java. El resto de los paquetes no están soportados por GWT.

• GWT Web UI Class Library: contiene un conjunto de elementos de interfaz

de usuario que permite la creación de objetos tales como textos, cajas de texto, imágenes y botones.

29


Figura 4.1: Imagen de los 4 elementos que componen GWT.

J2S (JavaToJavaScript): Esta herramienta requiere del entorno de desarrollo

de Eclipse y básicamente la funcionalidad es la misma que la del GWT.

Esta solución no nos interesaba demasiado, ya que nuestro proyecto no estaba desarrollado en Java. Teníamos 2 opciones, o traducir el código del servidor a Java, o buscar otra forma de desarrollar nuestra interfaz. Optamos por la segunda opción.

Visto que los frameworks anteriores utilizaban tecnología AJAX, decidimos buscar librerías AJAX, que se ajustasen más a lo que estábamos queriendo desarrollar, esto es, que nos permitiesen trabajar con un servidor perl y que nos permitiese realizar una interfaz sin necesidad de instalar la máquina virtual de Java (JVM).

4.2.2.- Librerías Ajax � Dojo Toolkit:

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). Éstas se ejecutan en el cliente, es decir, en el navegador de los usuarios y mantiene una comunicación asíncrona con el servidor en segundo plano, esto es, solo se comunicará cuando necesite datos del servidor. De esta forma es posible realizar cambios sobre la misma página sin necesidad de recargarla. Esto significa aumentar la interactividad, velocidad y usabilidad en la misma.

30


AJAX es una combinación de tres tecnologías ya existentes:

XHTML (o HTML) y hojas de estilos en cascada (CSS) para el diseño que acompaña a la información.

Document Object Model (DOM) accedido con un lenguaje de scripting por parte del usuario, especialmente implementaciones ECMAScript como JavaScript y Jscript, para mostrar e interactuar dinámicamente con la información presentada.

El objeto XMLHttpRequest para intercambiar datos asincrónicamente con el servidor web. En algunos frameworks y en algunas situaciones concretas, se usa un objeto iframe en lugar del XMLHttpRequest para realizar dichos intercambios.

XML es el formato usado comúnmente para la transferencia de vuelta al servidor, aunque cualquier formato puede funcionar, incluyendo HTML preformateado, texto plano, JSON y hasta EBML.

Algunas de las librerías estaban desarrolladas para trabajar con un lenguaje de programación concreto en el servidor. Otras disponían de muy pocas funciones, lo que suponía tener que crear todas las funciones necesarias. Y por último, había un conjunto de ellas que no dependían de un lenguaje de programación concreto en el servidor y además disponían de muchas funciones. Entre estas se encuentran las librerías Open Rico, Dojo Toolkit y Yahoo User Interface (YUI). Decidimos probar con estas últimas.

Para probar dichas librerías, decidimos instalar un entorno de desarrollo (IDE) que nos facilitase la tarea de programar. Optamos por el IDE Aptana, que trae integrados varias librerías AJAX entre otros: jQuery, Dojo, Mochikit, Mootools, Rico, Yahoo UI, Scriptaculous, Prototype y AFLAX.

Además dicha IDE, puede ser agregado al entorno de desarrollo Eclipse, ya que existe un plug-in para ello.

La librería que seleccionamos fue Dojo Toolkit. Esta librería es de código

abierto y acepta PHP, Perl, ASP, JSP y ColdFusion como lenguajes de servidor. La comunicación cliente-servidor es una comunicación RPC y además el tipo de datos más utilizado es JSON y no XML.

31


Para realizar la comunicación asíncrona entre cliente y servidor, Dojo dispone de un paquete (dojo.io.bind) con la implementación de XMLHttpRequest, además de poder usarse con otros transportes como Iframes y una gran variedad de formatos de datos.

Actualmente, la documentación está solo disponible en inglés, por lo que resulta bastante complicado de entender para aquellos que no estén familiarizados con el tema o con el idioma. En mi caso, al no tener mucha experiencia en la tecnología AJAX, me resultó bastante complicado conseguir desarrollar una llamada cliente-servidor con dicha librería.

Una vez que leímos la documentación y siguiendo algún que otro tutorial, conseguimos desarrollar una interfaz, que seleccionando un dominio, nos mostraba el árbol de dominios.

En la figura 4.2 podemos ver un ejemplo de la interfaz desarrollada con Dojo Toolkit. En ella se muestra un árbol con los elementos que forman la ontología Domains.

Figura 4.2: Resultado de la interfaz de consulta utilizando Dojo Toolkit.

32


Como no conseguiamos progresar con Ajax y el número de horas invertidas iba subiendo dramáticamente, decidimos no utilizar Ajax para nuestra página Web y buscar alguna alternativa. Como alternativa a Ajax, teníamos los lenguaje de scripts como PHP o Perl. Primero, decidimos intentar escribir la interfaz en PHP.

4.2.3.- PHP:

PHP es un lenguaje de programación interpretado usado normalmente para la

creación de páginas web dinámicas. PHP es un acrónimo recursivo que significa

"PHP Hypertext Pre-processor" (inicialmente PHP Tools, o, Personal Home Page

Tools).

Cuando el cliente hace una petición al servidor para que le envíe una página web, el servidor ejecuta el intérprete de PHP. Éste procesa el script solicitado que generará el contenido de manera dinámica (por ejemplo obteniendo información de una base de datos). El resultado es enviado por el intérprete al servidor, quien a su vez se lo envía al cliente. Mediante extensiones es también posible la generación de archivos PDF, Flash, así como imágenes en diferentes formatos.

Puesto que habíamos adquirido algún conocimiento de PHP, decidimos optar por desarrollar la interfaz en PHP.

Una vez desarrollada la interfaz, hacía falta comunicar la interfaz con la parte del servidor, que estaba desarrollada en Perl.

En la figura 4.3, podemos ver el formulario desarrollado en PHP para realizar la consulta. En este caso se ha completado con la palabra car, dejando el resto de los valores por defecto.

33


Figura 4.3: Formulario de la interfaz de consulta desarrollado en PHP.

En la figura 4.4, podemos ver el resultado obtenido. En esta página, primeramente se procesa la consulta recogida del formulario para enviársela al servidor. Posteriormente se conecta al servidor Perl para obtener el resultado.

34


Figura 4.4: Resultado obtenido trás procesar el formulario en PHP.

En este momento es cuando comprobamos que la conexión entre PHP y Perl, si bien se puede realizar, no nos satisfacía del todo.

Para comunicar la interfaz desarrollada en PHP con la parte desarrollada en Perl, había que efectuar cambios o en el envío de los datos o en la recepción de los mismos.

Con la primera opción, esto es, cambios en el envío de datos, suponía crear una función que procesara los datos antes del envío, lo cual modificaba la forma de visualizar la interfaz, esto es, en lugar de visualizar todo en una única página, suponía visualizar en una página el formulario y después trás procesar los datos, mostrar en otra página el resultado.

Con la segunda opción, esto es, cambios en la recepción de los datos, suponía modificar parte del servidor, sin modificar la visualización de la interfaz. Puesto que el servidor estaba desarrollado en Perl y puesto que no queríamos modificar la visualización de la interfaz, optamos por esta segunda opción, y ya que debíamos trabajar con Perl, optamos por desarrollar también la interfaz en Perl.

35


4.2.4.- PERL:

Perl (Practical Extraction and Report Language) es un lenguaje de

programación. Se ha usado para escribir guiones (scripts) CGI. Es una de las "tres Pes" (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 para el desarrollo web.

Sin apenas conocimiento alguno del lenguaje, basándonos en lo que estaba desarrollado y con algún tutorial, comenzamos a desarrollar la interfaz. Si se podía hacer en Php se tenía que poder hacer en Perl. Finalmente, conseguimos desarrollar la interfaz en Perl y comunicar cliente y servidor.

En la figura 4.5 podemos ver un ejemplo de dicha interfaz, tras haber realizado la consulta con la palabra car y dejando el resto de valores por defecto.

Figura 4.5: Resultado de la interfaz de consulta desarrollada en Perl.

36


De esta forma, cumplíamos con el objetivo de desarrollar una interfaz, sin la necesidad de tener que cargar la máquina virtual de java (JVM).

4.3.- Solución tecnológica:

4.3.1.- PERL:

Perl (Practical Extraction and Report Language) es un lenguaje de

programación diseñado por Larry Wall creado en 1987. Perl toma características del C, del lenguaje interpretado shell (sh), AWK, sed, Lisp y, en un grado inferior, muchos otros lenguajes de programación.

Estructuralmente, Perl está basado en un estilo de bloques como los del C o AWK, y fue ampliamente adoptado por su destreza en el procesado de texto y no tener ninguna de las limitaciones de los otros lenguajes de script.

El 26 de octubre de 1995, se creó el Comprehensive Perl Archive Network

(CPAN). CPAN es una colección de sitios web que almacenan y distribuyen fuentes en Perl, binarios, documentación, scripts y módulos.

La estructura completa de Perl deriva ampliamente del lenguaje C. Perl es un lenguaje imperativo, con variables, expresiones, asignaciones, bloques de código delimitados por llaves, estructuras de control y subrutinas.

Perl también toma características de la programación shell. Todas las variables son marcadas con un signo precedente (sigil). Los sigil identifican inequívocamente los nombres de las variables, permitiendo a Perl tener una rica sintaxis. Notablemente, los sigil permiten interpolar variables directamente dentro de las cadenas de caracteres (strings). Como en los shell, Perl tiene muchas funciones integradas para tareas comunes, como y para acceder a los recursos del sistema.

Perl toma las listas del Lisp, hash (memoria asociativa) del AWK y expresiones regulares del sed. Todo esto simplifica y facilita todas las formas del análisis sintáctico, manejo de texto y tareas de gestión de datos.

37


En Perl 5, se añadieron características para soportar estructuras de datos complejas, funciones de primer orden (p. e. closures como valores) y un modelo de programación orientada 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 (junto con el pragma stric). Una característica principal introducida en Perl 5 fue la habilidad de empaquetar código reutilizable como módulos. Larry Wall indicó más adelante que "la intención del sistema de módulos de Perl 5 era apoyar el crecimiento de la cultura Perl en vez del núcleo de Perl".

Todas las versiones de Perl hacen el tipado automático de datos y la gestión de la memoria. El intérprete conoce el tipo y requerimientos de almacenamiento de cada objeto en el programa; reserva y libera espacio para ellos según sea necesario. Las conversiones legales de tipo se hacen de forma automática en tiempo de ejecución; las conversiones ilegales son consideradas errores fatales.

Perl tiene muchas y variadas aplicaciones, gracias a la disponibilidad de muchos módulos estándares y de terceras partes.

Se ha usado desde los primeros días del Web para escribir guiones (scripts) CGI. Es una de las "tres Pes" (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 para el desarrollo web.

Perl es software libre y está licenciado bajo la Licencia Artística y la GNU General Public License. Existen distribuciones disponibles para la mayoría de sistemas operativos. Está especialmente extendido en Unix y en sistemas similares, pero ha sido portado a las plataformas más modernas (y otras más obsoletas).

4.3.2.- Apache:

El servidor HTTP Apache es un software (libre) servidor HTTP de código

abierto para plataformas Unix (BSD, GNU/Linux, etc.), Windows, Macintosh y otras.

El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la Apache Software Foundation.

38


Ventajas:

Modular Open-source Multi-plataforma Extensible Popular (fácil conseguir ayuda/soporte) Gratuito

Módulos:

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.

El servidor de base puede ser extendido con la inclusión de módulos externos entre los cuales se encuentran:

mod_perl - Páginas dinámicas en Perl. mod_php - Páginas dinámicas en PHP.

4.3.3.- PhpMyAdmin:

PhpMyAdmin es una herramienta escrita en PHP con la intención de

manejar la administración de MySQL a través de páginas webs, utilizando Internet. Actualmente puede crear y eliminar Bases de Datos, crear, eliminar y alterar tablas, borrar, editar y añadir campos, ejecutar cualquier sentencia SQL, administrar claves en campos, administrar privilegios, exportar datos en varios formatos y está disponible en 50 idiomas. Se encuentra disponible bajo la licencia GPL.

39


4.3.4.- MySQL:

MySQL es un sistema de gestión de base de datos relacional, multihilo y

multiusuario.

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 (vía dbExpress), Eiffel, Smalltalk, Java (con una implementación nativa del driver de Java), Lisp, Perl, PHP, Python, Ruby, Gambas, REALbasix (Mac), FreeBASIC, y Tcl; cada uno de estos utiliza una API específica. También existe un interfaz ODBC, llamado MyODBC que permite a cualquier lenguaje de programación que soporte ODBC comunicarse con las bases de datos MySQL.

MySQL es muy utilizado en aplicaciones web como MediaWiki o Drupal, 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.

40


5.- DESARROLLO DEL SISTEMA DE INFORMACIÓN (SI):

5.1.- Captura de requisitos:

5.1.1.- Caso de uso:

Consultar interfaz MCR

Usuario

Actores: Usuario

Descripción: Esta funcionalidad permite al usuario consultar el significado de una palabra o definición contenida en cualquiera de los idiomas disponibles. A su vez, podrá seleccionar los idiomas en los que quiere que se le muestre el resultado y las opciones que quiere visualizar.

Curso normal de los eventos:

1.- El usuario accede a la página Web.2.- El usuario indica los parámetros de la búsqueda, introduciendo la palabra y seleccionando el resto de campos. Pulsa el botón Look up para obtener el resultado.3.- El sistema obtiene el resultado y se lo muestra en la parte inferior de la página.

Flujos alternativos:

1.-El usuario no introduce la palabra a buscar.2.- El sistema le mostrará la misma página, esto es, el formulario con la parte inferior en blanco.

1.- El usuario introduce mal una palabra o introduce una palabra que no se encuentra en la base de datos de ese idioma.2.- El sistema le mostrará Not found!!!

41


5.1.2.- Modelo del Dominio:

A continuación se muestra el conjunto de tablas utilizado para rellenar los datos que aparecen en el formulario. Dicho formulario será utilizado por el usuario para realizar la consulta.

No todos los datos que aparecen en el formulario han sido rellenados consultando la base de datos.

wei_languages

codelangcoloreditablenum

wei_relations_group

idnamecascade

wei_relations

idnamepropsinversegrupnote

1 *

Figura 5.1: Modelo del dominio

La tabla wei_languages es la que contiene la información referente a los

distintos idiomas. Para nuestro caso los atributos más importantes son code, lang y color.

Code: indica el código del idioma.Lang: indica el nombre del idiomaColor: indica el color por el que dicho idioma se representa.

Ejemplo: para el idioma English_1.6, este sería el valor de dichos atributos.Code: en16Lang: English_1.6Color: #0002D2 (color azul)

La tabla wei_relations_group es la que contiene la información referente a

los distintos grupos por los que se puede consultar, esto es Synonyms, Hyponyms,... Para nuestro caso los atributos más importantes son id y name.

Id: identifica de manera única a un grupo.Name: indica el nombre del grupo.

42


Ejemplo: para el grupo de relación de Hyponyms, este sería el valor de dichos atributos.

Id: 1Name: Hyponyms

La tabla wei_relations es la que contiene la información referente a las

relaciones por las que se puede consultar, esto es near_synonyms, has_hyponym,... Para nuestro caso los atributos más importantes son id, name, inverse y grup.

Id: identifica de manera única a una relación.Name: indica el nombre de la relación.Inverse: indica el nombre de la relación opuesta si es que la tiene.Grup: indica el grupo de relaciones al que pertenece.

Ejemplo: para la relación has_hyponym, este sería el valor de los distintos atributos.

Id: 12Name: has_hyponymInverse: has_hyperonymGrup: 1

5.2.- Análisis:

Usuario Sistema

Consulta al MCR

Consultar MCR (item, metode, pos, llengua, search, estructura, glos, csco, rels, full,

en16, en17, en15, spwn, e171, cawn, en20, bawn, ca15, itwn, sp15):

43


Parámetros:

item: aquí se introducirá el término a buscar, pudiendo ser una palabra (Word) ej: car, una definición (Variant) ej: car_1, un Synset ej: 02383458 ó un ILI ej: 02383458.

metode: habrá que seleccionar si lo que queremos buscar es Word, Variant, Synset o ILI. Por defecto buscará como Word.La principal diferencia entre Synset e ILI es que si ponemos ILI, este siempre buscará el término en English_1.6, mientras que Synset buscará en el idioma que le indiquemos.

pos: habrá que indicar si el término que deseamos buscar es un Nombre (Nouns), Adjetivo (Adjectives), Verbo (Verbs) o Adverbio (Adverbs). Por defecto buscará como Nouns.

llengua: aquí se le debe indicar el idioma al que pertenece el término que estamos buscando. Por defecto buscará en English_1.6.

search: aquí habrá que indicar el tipo de relación que queremos que nos muestre. Por defecto buscará near_synonym.

estructura: aquí se le debe indicar el idioma al que pertenece la relación que estamos buscando. Por defecto buscará en English_1.6.

glos: Mostrará la definición del término que hemos buscado. Seleccionado por defecto.

csco: Mostrará el porcentaje de cada definición.

rels: Mostrará las relaciones que tiene el término.

full: Mostrará, las tres anteriores (glos, csco y rels).

en16, en17, en15, spwn, e171, cawn, en20, bawn, ca15, itwn, sp15: con cada uno de ellos indicamos los idiomas que queremos que aparezcan en el resultado. El número de estos checkbox cambiará en función de la versión de Wei en la que nos encontremos, en este caso disponemos de once, de los cuales 2 vienen seleccionados por defecto, en16 y spwn.

44


Con el botón Look up, mandamos la información al servidor para que la procese, esto es, recargamos la página mostrando el resultado de la consulta.

Responsabilidades:

El sistema con los parámetros que ha obtenido desde el cliente, realizará las correspondientes consultas a la base de datos y devolverá los resultados obtenidos.

Salida:

Se muestran por pantalla los resultados de la consulta.

Precondiciones:

Existen valores por defecto, por lo que si el usuario no especifica otros, el sistema realizará la búsqueda con los valores por defecto.

Existen varias formas de indicar el término a buscar:

− Si es una palabra (Word) entonces se escribe la palabra. Ej: car

− Si es una definición (Variant) entonces se escribe la palabra seguida del número de definición que queremos que nos muestre. Ej: car_1 (1ª definición de la palabra car).

− Si es un Synset o un ILI entonces se escribe el identificador del término (un número). Ej: 02383458

Postcondiciones:

No se modifica ninguna tabla de la base de datos, ya que solo se realizan acciones SELECT.

45


5.3.- Arquitectura:

Hemos optado por una aplicación desarrollada siguiendo una arquitectura en dos capas (capa de dominio y capa de gestión de datos), donde la capa de presentación está dentro de la capa de dominio.

Capa de dominio:

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, como por ejemplo, Mozilla Firefox, donde ejecutar la aplicación perl.

En esta capa se gestionará toda la lógica de negocio con todas sus operaciones.

Para el desarrollo de esta capa se ha utilizado la tecnología PERL y para poder probarla

se ha necesitado instalar el servidor Apache-Tomcat.

En este proyecto se ha podido aprovechar gran parte de las funciones y de los scripts existentes, todos ellos desarrollados en Perl.

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 ha sido 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.

46


5.4.- Diseño:

Usuario

Interfaz Usuario / Servidor Gestor Base de Datos

Look up (item, metode, pos, search, ...)

Realizar consultas

Return resultado

Enviar resultado

Refrescar pantalla

Figura 5.2: Diagrama de secuencia

No se detallan las consultas que el servidor realiza a la base de datos porque nosotros nos hemos centrado principalmente en desarrollar la interfaz, esto es, en la llamada del usuario al servidor.

5.5.- Implementación:

Consultas a la base de datos:

Las consultas a la BD que realizamos para mostrar los datos en la interfaz son las siguientes:

1.- � SELECT * FROM wei_languages ORDER BY num�

Accede a la tabla donde están almacenados los distintos idiomas. Esta consulta la realizamos varias veces, ya que con ella debemos rellenar los select llengua y estructura y los checkbox correspondientes.

2.- � SELECT * FROM wei_relations_group ORDER BY id�� SELECT * FROM wei_relations WHERE grup='$id' ORDER BY name�

47


Con el primer select, obtenemos los distintos grupos de relaciones que existen. Estos aparecen en el select search como disabled, esto es, no serán seleccionables.

Con el segundo select, obtenemos las relaciones existentes para cada grupo. Estos son los que se pueden seleccionar.

Ficheros modificados:

Se ha creado un nuevo fichero, basado en el fichero wei.bottom.perl. Estos son los cambios que hemos incluído en el nuevo fichero respecto al existente wei.bottom.perl.

Se ha creado la función ejecucion: sub_ejecucion ()

Dicha función es la encargada de realizar las consultas antes mencionadas a la base de datos y de mostrar el formulario.

Se ha modificado la función entrada: sub_entrada ()

Con la interfaz en Java, los parámetros que se le enviaban, habían sido previamente tratados. Ahora, con la interfaz en Perl, los datos no han sido tratados antes de ser enviados,

por lo que hay que tratarlos. Esto es lo que se le ha añadido a la función entrada.

Además han sido modificados los siguientes ficheros:

cooking.pl (se han añadido algunas funciones)

- Tienen que ver con las Ontologías: (se han modificado algunos enlaces)

wei.mostrar.synset.perl wei.onto.perlwei.definitions.perl

- Los siguientes ficheros han dejado de ser útiles, puesto que son las que contenían la información de la interfaz desarrollada en Java.

wei.top.perlwei.consult.perl

48


Para comprobar el correcto funcionamiento de la interfaz se añadió una traza al fichero para visualizar el paso de parámetros. A continuación mostramos un ejemplo de lo que se obtiene. Para ello, vamos a preguntar en ambas interfaces por el sustantivo car, dejando el resto de valores por defecto.

Estas son las trazas que obtenemos con la interfaz actual desarrollada en Java:

QUERY_STRING item=car&metode=Word&pos=Nouns&llengua=English_1.6&search=near_synonym&estructura=English_1.6&glos=1&csco=0&rels=0&full=0&levin=0&llengues=11000000000

REQUEST_URI /cgi-bin/wei4/public/wei.bottom.perl?item=car&metode=Word&pos=Nouns&llengua=English_1.6&search=near_synonym&estructura=English_1.6&glos=1&csco=0&rels=0&full=0&levin=0&llengues=11000000000

Y el valor de $tornada es:

car|Word|Nouns|English_1.6|near_synonym|English_1.6|1|0|0|0|0|11000000000

Y estas son las trazas que se obtienen desde nuestra interfaz:

QUERY_STRING item=car&button1=Look_up&metode=Word&pos=Nouns&llengua=English_1.6&search=near_synonym&estructura=English_1.6&glos=Gloss&levin=1&en16=English_1.6&spwn=Spanish_1.6

REQUEST_URI /cgi-bin/wei4/public/wei.interfazconsulta.perl?item=car&button1=Look_up&metode=Word&pos=Nouns&llengua=English_1.6&search=near_synonym&estructura=English_1.6&glos=Gloss&levin=1&en16=English_1.6&spwn=Spanish_1.6

Y el valor de $tornada es:

car|Word|Nouns|English_1.6|near_synonym|English_1.6|1|0|0|0|1|11000000000

49


En la figura 5.3 se muestra el resultado obtenido por la interfaz de consulta desarrollada en Java.

Figura 5.3: Interfaz de consulta al MCR desarrollada en Java.

En la figura 5.4 se muestra el resultado obtenido por la interfaz desarrollada en Perl. Esto es, la nueva interfaz, creada para sustituir a la existente.

50


Figura 5.4: Interfaz de consulta al MCR desarrollada en Perl.

51


6.- PRUEBAS:

6.1.- Pruebas unitarias:

Teníamos que comprobar 2 aspectos:

- Que la página estuviese bien construida.

- Que la página fuese accesible.

Para ambos aspectos, estos son los pasos que seguimos:

- Subir la página al servidor local.

- Intentar acceder en el servidor local a la página.

- Si surgía algún error, entonces abrir el archivo de errores de apache e intentar solucionarlo.

Estos son los distintos errores y sus soluciones.

Errores de construcción: Soluciones

Syntax error atUnmatched right curly bracketBareword/String/Backslash found where operator expected

Comprobar el fichero, número de paréntesis, condicionales, &

DBD::mysql::st execute failed Añadir modulo DBI al fichero

Errores de accesibilidad: Soluciones

Malformed header from script Incluir la ruta donde esta instalado perl.

You don� t have permission Darle permisos de ejecución al fichero perl.

52


6.2.- Pruebas de integración:

Una vez comprobado que la interfaz estaba bien construida y era accesible, debíamos

unir la parte de la interfaz, con la parte de procesamiento de la consulta. Para comprobar el correcto funcionamiento de la interfaz, incluímos unas trazas en el fichero, las cuales nos mostraban el paso de parámetros.

Una vez comprobado que el paso de parámetros se realizaba correctamente, también realizamos consultas simultáneas en la interfaz Java y en nuestra interfaz para comprobar que ambos mostraban los mismos resultados.

Casos de prueba Descripción Resultado

Término correcto Introducimos correctamente un término existente.

Nos mostrará el resultado con todos los datos que le hayamos pedido como idiomas, relaciones, ...

Término vacío No introducimos ningún término

Nos volverá a mostrar la página inicial

Término incorrecto Introducimos un término que no existe en la base de datos o introducimos mal un término existente.

Nos mostrará Not Found!!!

Para comprobar el correcto funcionamiento de la interfaz, basta con realizar las mismas consultas en la interfaz actual y en nuestra interfaz y comprobar que los resultados obtenidos son correctos. De todas formas, añadimos unas trazas en el servidor, para poder comprobar el paso de parámetros del cliente al servidor, para poder así tratarlos de manera adecuada.

6.3.- Proceso de implantación:

Una vez finalizado el proyecto en nuestra máquina, queda la fase de implantación en el servidor. La versión disponible actualmente en el servidor, es distinta a la versión que hemos utilizado para desarrollar el proyecto, pero esto no debería suponer ningún problema. En el caso de que surgan problemas, habrá que ver la razón.

53


Una vez instalado en el servidor, realizaremos algunas pruebas, para comprobar su funcionamiento. De esta forma, aparte de comprobar la implementación de la interfaz, podremos comprobar el tiempo de carga de la página respecto a la actualmente existente. Puesto que no se requiere de la máquina virtual de Java, esperamos que el tiempo de carga sea inferior y los tiempos de respuesta sean bastante parecidos a los existentes.

54


7.- GESTIÓN:

Una vez finalizada la realización del proyecto, tenemos el número de horas reales empleadas para cada tarea del proyecto. A continuación vamos a ver las desviaciones producidas entre la planificación de horas realizada en el DOP y las horas reales.

Horas planificadas Horas reales

Desarrollo del DOP 10 12,75

Selección de herramientas 4 7,5

Reuniones ordinarias 10 24,5

Reuniones extraordinarias 0 13,75

Búsqueda de información 20 105,75

Formación 20 64

Elección tecnológica 100 156,75

Captura de requisitos 4 2,5

Análisis 4 2,5

Diseño 4 1,5

Implementación 100 73,25

Pruebas 10 5

Preparar los entregables 2 0,5

Elaborar memoria 60 66

Instalación 2 0

Horas Totales 350 536,25

En las figuras 7.1, 7.2, 7.3 y 7.4 se muestran a modo de gráficos las diferencias surgidas entre las horas pensadas y las horas invertidas en las distintas fases del proyecto.

55


Figura 7.1: Diferencias entre horas pensadas e invertidas en la gestión del proyecto.

Figura 7.2: Diferencias entre horas pensadas e invertidas en el análisis del entorno.

56

Desarrollo del DOPSelección de herramientas

Reuniones ordinariasReuniones extraordinarias

0

5

10

15

20

25

30

Gestión del proyecto

Horas PensadasHoras invertidas

Búsqueda de información Formación Elección tecnológica0

20

40

60

80

100

120

140

160

180

Análisis del entorno



Figura 7.3: Desviaciones entre las horas pensadas e invertidas en el desarrollo técnico.

Figura 7.4: desviaciones entre las horas pensadas e invertidas en el cierre de la iteración.

57

Preparar los entregables Elaborar memoria Instalación0

10

20

30

40

50

60

70

Cierre de iteración


Captura de requisitosAnálisis

DiseñoImplementación

Pruebas

0

20

40

60

80

100

120

Desarrollo técnico



En la figura 7.1 podemos ver que se produce una desviación en las horas invertidas en las reuniones. Esto se debe principalmente a las dificultades encontradas con las herramientas seleccionadas.

En la figura 7.2 podemos ver que es donde se produce la mayor desviación. Esto es debido a que hemos dedicado mucho tiempo a estudiar el funcionamiento de las herramientas seleccionadas, sin conseguir los resultados esperados,

En la figura 7.3 podemos ver que aunque se produce una desviación, el número de horas planificadas ha sido superior a las reales. Esto es debido principalmente a que una vez que dimos con la herramienta adecuada el desarrollo se realizó sin mayores problemas.

En la figura 7.4 podemos ver que la planificación se ha ajustado bastante a lo que realmente a sucedido.

58


8.- CONCLUSIONES:

Cuando decidí optar por este proyecto, sabía que no iba a resultar una tarea sencilla. Por un lado, lo que más me preocupaba era mi desconocimiento sobre el sistema operativo Linux y sobre los lenguajes de programación que se me proponían, pero por otro lado eso era también lo que más me motivaba.

Ahora, con otra perspectiva, he de decir que no me arrepiento para nada de la elección que en su día hice, ya que este proyecto me ha abierto los ojos de un mundo que antes era desconocido para mí.

Si bien es cierto, que gran parte de las tareas que se realizan en el proyecto las hemos ido abordando a lo largo de la carrera, hasta que no he realizado el proyecto fin de carrera, no he tenido la oportunidad de unificar todas ellas en un solo proyecto.

Además de eso, este proyecto me ha permitido adquirir nuevos conocimientos de los que carecía y que considero importantes para un Ingeniero Informático, como son el manejo de un sistema operativo distinto a Windows, como es Linux y el aprendizaje de lenguajes de programación distintos de Java, en este caso Php y Perl.

Resumiendo, este proyecto me ha dado la oportunidad de aprender mucho y también me ha hecho ver que siempre existen alternativas a tener en cuenta a la hora de realizar un proyecto.

59


9.- BIBLIOGRAFÍA:

Información sobre Perl:http://www.cse.unt.edu/~rada/CSCE5290/Lectures/Perl.Tutorial.ppthttp://flanagan.urg.es/perlhttp://www.desarrolloweb.com/articulos/http://es.wikipedia.org/wiki/Perl

Información sobre CGI's en Apache:http://quark.fe.up.pt/ApachES/manual-es/howto/cgi.html

Información sobre HTML y CSS:http://perlenespanol.baboonsoftware.com/tutoriales/html/desplegar_html.htmlhttp://www.librosweb.es/csshttp://www.desarrolloweb.com/articulos/186.phpJesús Bobadilla Sancho, Santiago Alonso Villaverde. HTML Dinámico a través de ejemplos.

ISBN: 8478973745. Ra-ma, Madrid, España, 1999.Jesús Bobadilla Sancho. HTML dinámico, ASP y JavaScript a través de ejemplos. ISBN:

8478973885. Ra-ma, Madrid, España, 1999.

WordNet:http://wordnet.princeton.edu/http://en.wikipedia.org/wiki/WordnetGeorge A. Miller, Richard Beckwith, Christiane Fellbaum, Derek Gross, Katherine Miller.

Introduction to WordNet: An On-line Lexical Database. 1993.

EuroWordNet:http://www.illc.uva.nl/EuroWordNet

Meaning: http://adimen.si.ehu.es/cgibin/wei5/public/wei.consult.perl

Php:http://es.wikipedia.org/wiki/.phpwww.pauta.us.es/pautadatos/publico/personal/pas/2166/1498/ php _ manual .pdf

Ajax:Edmond Woychowsky. Ajax: creating web pages with asynchronous JavaScript and XML.

60

http://www.pauta.us.es/pautadatos/publico/personal/pas/2166/1498/php_manual.pdf





http://es.wikipedia.org/wiki/.php

http://adimen.si.ehu.es/cgi-bin/wei5/public/wei.consult.perl

http://www.illc.uva.nl/EuroWordNet

http://en.wikipedia.org/wiki/Wordnet

http://wordnet.princeton.edu/

http://www.desarrolloweb.com/articulos/186.php

http://www.librosweb.es/css

http://perlenespanol.baboonsoftware.com/tutoriales

http://quark.fe.up.pt/ApachES/manual-es/howto/cgi.html

http://es.wikipedia.org/wiki/Perl

http://www.desarrolloweb.com/articulos/

http://flanagan.urg.es/perl

http://www.cse.unt.edu/~rada/CSCE5290/Lectures/Perl.Tutorial.ppt


ISBN: 0132272679. Prentice Hall, Upper Saddle River, New Jersey, 2007.Lee Babin. Beginning Ajax with PHP: from novice to professional. ISBN: 1590596676.

Apress, Berkeley, California, 2007.

Google Web Toolkit:http://es.wikipedia.org/wiki/GWThttp://esgooglewebtoolkit.blogspot.com/

Eclipse:http://www.eclipse.org/

Aptana:http://www.aptana.com/

Dojo Toolkit:http://en.wikipedia.org/wiki/Dojo_Toolkithttp://dojotoolkit.org/

Linux:http://es.wikipedia.org/wiki/Linux

Apache:http://es.wikipedia.org/wiki/Servidor_HTTP_Apache

PhpMyAdmin:http://www.phpmyadmin.net/home_page/index.phphttp://es.wikipedia.org/wiki/PhpMyAdmin

MySQL:http://es.wikipedia.org/wiki/MySQL

Otros:http://es.wikipedia.org/wiki

61

http://es.wikipedia.org/wiki

http://es.wikipedia.org/wiki/MySQL

http://es.wikipedia.org/wiki/PhpMyAdmin

http://www.phpmyadmin.net/home_page/index.php

http://es.wikipedia.org/wiki/Servidor_HTTP_Apache

http://es.wikipedia.org/wiki/Linux

http://dojotoolkit.org/

http://en.wikipedia.org/wiki/Dojo_Toolkit

http://www.aptana.com/

http://www.eclipse.org/

http://esgooglewebtoolkit.blogspot.com/

http://es.wikipedia.org/wiki/GWT


10.- GLOSARIO DE TÉRMINOS:

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.

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.

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

62


Software Foundation a mediados de los 80, y está orientada principalmente a proteger la libre distribución, modificación y uso de softw

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

63


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.

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.

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.

64

INDICErigau/teaching/EHU/PFCs/... · 2009. 7. 7. · Proyecto final de carrera: Maria Eguimendia La...

Documents

Transcript of INDICErigau/teaching/EHU/PFCs/... · 2009. 7. 7. · Proyecto final de carrera: Maria Eguimendia La...