Converter y Fetcher

Tal como se describi´o en la Secci´on 3.4.1, el m´oduloConverter es el responsable de transformar los documentos obtenidos del repositorio en objetos que faciliten el acceso a los atributos, que ser´an utilizados para crear las entidades de tipo art´ıculo e investigador. De esta forma, se independiza a las etapas posteriores del procesamiento de bajo nivel de los datos.

Figura 4.8:Diagrama de clases para el modulo Converter

Para el repositorio objetivo, es necesario implementar un Converter capaz de procesar los do- cumentos en formato HTML obtenidos. Por cada tipo de documento se cuenta con una clase responsable de procesar el c´odigo HTML del mismo, para extraer los datos y hacerlos disponibles

4.3. INTERFAZ DE ACCESO A LOS DATOS 59 a quienes lo soliciten. Las clases implementadas son las que se muestran en la Figura 4.8, y los documentos HTML a procesar son los descriptos en la Secci´on 4.1.2. Las clases y los tipos de archivos se vinculan de la siguiente forma:

JournalConverter: Esta clase es la responsable de interpretar los documentos HTML que contienen los datos de un art´ıculo publicado en una revista de divulgaci´on cient´ıfica. Estos documentos se identifican por que su direcci´on URL, y su nombre en el sistema de archivos, termina en art id=<identificador de art´ıculo>

ConferenceConverter: Para los art´ıculos publicados en congresos y conferencias se im- plement´o esta clase, responsable de interpretar los documentos cuyo nombre termina en congr id=<identificador de art´ıculo>

BookConverter:Los art´ıculos del tipo cap´ıtulo de libro son procesados por esta clase que se encuentra asociada a los documentos que terminan con el sufijocapit id=<identificador de art´ıculo>

ResearcherConverter: Finalmente, los documentos cuyo nombre termina en datos academicos=yesson procesados por esta clase. En estos documentos se encuentra la informaci´on personal de un investigador.

La Figura 4.9 muestra dos segmentos de c´odigo HTML correspondientes a dos documentos obte- nidos del repositorio. El primero de ellos corresponde a los datos acad´emicos de un investigador, tal como se mostr´o en la Figura 4.1. Un documento de datos acad´emicos como este es procesa- do por la clase ResearcherConverter. Esta clase debe asociar las etiquetas HTML del tipo div, que contengan el atributo class=’titulo nombre’, al atributo name. Este atributo es accesible mediante el m´etodo getName provisto por la clase. De forma similar, los dem´as atributos se encuentran accesibles a trav´es de m´etodos del estilo get<nombre atributo>.

El segundo de los ejemplos de la Figura 4.9 muestra una parte de un art´ıculo de revista, con su correspondiente secci´on de c´odigo HTML. Este tipo de documentos es procesado por la clase JournalConverter del m´odulo Converter. En este caso la clase sabe que luego de una etiqueta de tipodiv, con el atributoclass=’contenido label’,siempre es sucedida por otra, con el atributo class=’contenido label info’, donde se encuentra el valor real del atributo.

El procesamiento de los documentos HTML se implement´o utilizando la biblioteca Jsoup5. Esta se encarga de procesar el c´odigo HTML de una p´agina y presenta una Application Program Interface (API) que permite navegar el documento y acceder a sus elementos.

El m´odulo Fetcher, como se mencionaba en la Secci´on 3.4.1, es el responsable de recorrer los datos obtenidos del repositorio objetivo e invocar la creaci´on de las clases definidas en el m´odulo Converter, de acuerdo al tipo de cada documento. En el caso de el repositorio del CONICET, este proceso es simple dado que la estructura de directorios creada, durante el proceso de obtenci´on

5

60 CAP´ITULO 4. IMPLEMENTACI ´ON

Figura 4.9:Ejemplo de atributos de los documentos, junto al c´odigo HTML correspondiente

(como se muestra en la Figura 4.7), agrupa los documentos de a un directorio por investigador. El proceso realizado por el Fetcher,implementado para este repositorio, consiste en recorrer los directorios creados durante la obtenci´on de datos y, para cada archivo del directorio, invocar la creaci´on de una de las clases del m´odulo Converter, de acuerdo a la asociaci´on entre clases y nombres de archivos descripta previamente. Al crear una instancia de alguna de estas clases se le env´ıa como par´ametro el archivo HTML que debe interpretar.

4.4.

Modelo de datos

Esta secci´on detalla los cambios realizados al modelo de datos, descripto en la Secci´on 3.2, para adaptarlo al repositorio del CONICET. La implementaci´on del modelo concreto para este repositorio respeta en gran medida el modelo abstracto definido previamente.

El primer cambio importante fue la separaci´on de la claseResearcher en dos subclases:LocalRe- searcher yForeignResearcher. La primera de ellas representa a los investigadores pertenecientes al CONICET, mientras que la segunda representa a aquellos investigadores ajenos a la insti- tuci´on. Esta diferenciaci´on es necesaria ya que el repositorio objetivo no cuenta con la misma informaci´on para estos dos tipos de investigadores. Aquellos investigadores que pertenecen a la instituci´on cuentan con una p´agina Web donde se encuentran todos sus datos acad´emicos y publicaciones, mientras que los que no pertenecen a la instituci´on tan solo aparecen nombrados en listas de autores de los art´ıculos.

De forma similar, el segundo cambio fue la separaci´on de la clase Name en tres subclases: FirstName,LastName yUnknown. Estas representan nombres de pila, apellidos y desconocidos.

4.4. MODELO DE DATOS 61 Los desconocidos son nombres, correspondientes a investigadores ajenos al CONICET, para los cuales no se puede determinar si son nombres de pila o apellidos. Esta soluci´on para identificar los tres tipos de nombres, se debe a la forma en que trabaja la herramienta Hibernate,utilizada para persistir las clases en la base de datos.

Finalmente, un cambio menor es la inclusi´on de un atributo identificador a todas las clases del modelo. Este identificador es utilizado por Hibernate, para identificar las diferentes instancias de las clases definidas en el modelo y poder vincularlas con las tuplas de la base de datos. Este aspecto se detallar´a en la siguiente secci´on.

Las nuevas clasesLocalResearcher,ForeignResearcher,FirstName,LastNameyUnknown, pueden observarse en el diagrama de la Figura 4.10. Las dem´as clases se mantuvieron sin mayores cambios de acuerdo al modelo propuesto previamente en la Secci´on 3.2.

Figura 4.10: Modelo de datos para el repositorio de CONICET