PFC Alejandro Cuevas Candela

Universidad Politécnica de Madrid
Facultad de Informática
Trabajo de Fin de Carrera
Sistema de Identificación, Extracción y
Recuperación de Secuencias Genéticas
a partir de la Literatura Cientı́fica
AUTOR: Alejandro Cuevas Candela
TUTOR: Miguel Garcı́a Remesal
Marzo, 2011
A mi abuelo
Agradecimientos
A mi madre. Gracias por estar siempre ahı́, por ser como eres y por
enseñarme a ser como soy.
A mi familia: mi abuela, tı́os, tı́as, primos y primas. Sois la mejor
familia que se puede tener, ¡gracias por todo!
A mis amigos de siempre. En especial a Juan y a Pablo. Gracias
por todos los años que llevamos siendo amigos, y por todos los que nos
quedan!
A mi tutor, Miguel Garcı́a, y a Vı́ctor Maojo. Muchas gracias por
darme la oportunidad de realizar este proyecto, y por todo lo que he
aprendido durante mi estancia en el Grupo de Informática Biomédica (GIB).
A mis compañeros del GIB: Alberto, Ana, Alex2, Dani, David,
Diana1, Diana2, Guillermo, Luis, Martı́n, Nelly, Sergio, Stefano y Toni.
Gracias por hacer de este tiempo uno de mis mejores recuerdos.
A mis compañeros durante todos estos años en la FI, en especial a
Alberto, Ana, Andrés, Carmen, Daniel, Diana, Eva, Jesús, Jorge, Miguel,
Rubén y Tomás. ¡Gracias por todo este tiempo, sois los mejores!
A
mis
nuevos
compañeros en BrainSINS: @avc conti,
@FkieCarrero, @josek net, @Kayvan666, @luisdiazdeldedo, @LuMartin y
@Prueno. ¡Gracias por hacer del trabajo un placer!
A todos a los que deberı́ais aparecer aquı́ y por culpa de mi mala memoria
no estáis.
Índice de contenidos
1 Introducción
1
1.1
Planteamiento del Problema . . . . . . . . . . . . . . . . . . .
1
1.2
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.1
Formato de los Documentos . . . . . . . . . . . . . . .
3
1.2.2
Detección y Anotación de Secuencias . . . . . . . . . .
3
1.2.3
Creación de un Índice de Artı́culos y Secuencias . . .
4
Solución Propuesta . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3.1
Extracción del Texto de los Artı́culos . . . . . . . . . .
5
1.3.2
Reconocimiento de Secuencias . . . . . . . . . . . . . .
7
1.3.3
Filtrado de Secuencias . . . . . . . . . . . . . . . . . .
10
1.3.4
Anotación de Secuencias . . . . . . . . . . . . . . . . .
10
1.3.5
Generación de un Índice de Artı́culos y Secuencias . .
11
1.3
2 ESTADO DE LA CUESTIÓN
13
2.1
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2
Trabajos Previos Relacionados . . . . . . . . . . . . . . . . .
13
2.3
Fundamentos Teóricos . . . . . . . . . . . . . . . . . . . . . .
15
2.3.1
Recuperación de Información . . . . . . . . . . . . . .
15
2.3.1.1
Visión General de un Sistema Clásico de RI .
15
2.3.1.2
Creación del Índice de Documentos . . . . .
16
2.3.2
2.3.1.2.1
Estructura del Índice . . . . . . . .
17
2.3.1.2.2
Enfoques Más Importantes . . . . .
18
2.3.1.2.3
Evaluación de Sistemas de RI . . . .
19
Búsqueda en Textos Mediante Autómatas Finitos . . .
20
3 TECNOLOGÍAS,
EMPLEADOS
LENGUAJES
Y
ESTÁNDARES
23
i
3.1
UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1.1
24
Notación UML . . . . . . . . . . . . . . . . . . . . . .
3.1.1.0.4
Casos de Uso . . . . . . . . . . . . .
24
3.1.1.0.5
Diagrama de Casos de Uso . . . . .
25
3.1.1.0.6
Diagrama de Clases . . . . . . . . .
26
3.1.1.0.7
Diagrama de Interacción entre
Objetos . . . . . . . . . . . . . . . .
28
3.2
JAVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.3
PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.4
Apache PDFBox . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.5
XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.5.1
Parsers XML . . . . . . . . . . . . . . . . . . . . . . .
33
Bases de Datos Relacionales . . . . . . . . . . . . . . . . . . .
34
3.6.1
El Modelo Relacional . . . . . . . . . . . . . . . . . .
35
3.6.2
Modelado Entidad/Relación . . . . . . . . . . . . . . .
35
3.6.3
MySQL . . . . . . . . . . . . . . . . . . . . . . . . . .
36
GenBank y BioSQL . . . . . . . . . . . . . . . . . . . . . . .
37
3.7.1
GenBank . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.7.2
BioSQL . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.8
BLAST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.9
Servlets y Apache Tomcat . . . . . . . . . . . . . . . . . . . .
38
3.9.1
Servlets . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.9.2
Apache Tomcat . . . . . . . . . . . . . . . . . . . . . .
39
3.10 Lucene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.6
3.7
4 ANÁLISIS DEL SISTEMA
4.1
41
ESPECIFICACIÓN DE REQUISITOS SOFTWARE . . . . .
41
4.1.1
Introducción . . . . . . . . . . . . . . . . . . . . . . .
41
4.1.1.1
Propósito . . . . . . . . . . . . . . . . . . . .
41
4.1.1.2
Ámbito del sistema . . . . . . . . . . . . . .
41
4.1.1.3
Definiciones, acrónimos y abreviaturas . . . .
42
4.1.1.4
Referencias . . . . . . . . . . . . . . . . . . .
43
4.1.1.5
Visión General del Documento ERS . . . . .
43
Descripción General . . . . . . . . . . . . . . . . . . .
43
4.1.2.1
Perspectiva del Producto . . . . . . . . . . .
44
4.1.2.2
Funciones del producto . . . . . . . . . . . .
44
4.1.2
ii
4.1.3
4.1.2.3
Caracterı́sticas del usuario . . . . . . . . . .
45
4.1.2.4
Restricciones . . . . . . . . . . . . . . . . . .
46
4.1.2.5
Suposiciones y dependencias . . . . . . . . .
46
Requisitos Especı́ficos . . . . . . . . . . . . . . . . . .
47
4.1.3.1
. . . . . .
47
Interfaces de Comunicación . . . . .
48
Requisitos de Interfaces Externos
4.1.3.1.1
4.2
4.1.3.2
Requisitos Funcionales
. . . . . . . . . . . .
48
4.1.3.3
Requisitos de Rendimiento . . . . . . . . . .
50
4.1.3.4
Atributos del sistema . . . . . . . . . . . . .
50
CASOS DE USO DEL SISTEMA . . . . . . . . . . . . . . . .
51
4.2.1
Actores . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.2.1.1
Actores Principales . . . . . . . . . . . . . .
52
4.2.1.2
Actores de Apoyo . . . . . . . . . . . . . . .
52
4.2.2
Diagrama de Casos de Uso . . . . . . . . . . . . . . .
52
4.2.3
Casos de Uso . . . . . . . . . . . . . . . . . . . . . . .
54
4.2.3.1
Anotar Secuencias de Artı́culo . . . . . . . .
54
4.2.3.2
Extraer Secuencias del Texto . . . . . . . . .
55
4.2.3.3
Generar Índice . . . . . . . . . . . . . . . . .
55
4.2.3.4
Consultar Índice por Texto . . . . . . . . . .
56
4.2.3.5
Consultar Índice por Secuencias . . . . . . .
57
4.2.3.6
Consultar Índice por Texto y Secuencias . .
58
Diagramas de Secuencia del Sistema . . . . . . . . . .
58
4.2.4.1
Anotar Secuencias de Artı́culo . . . . . . . .
59
4.2.4.2
Generar Índice de Artı́culos y Secuencias . .
59
4.2.4.3
Consultar Índice por Texto . . . . . . . . . .
60
4.2.4.4
Consultar Índice por Secuencias . . . . . . .
60
4.2.4.5
Consultar Índice por Secuencias . . . . . . .
61
Contratos de las Operaciones del Sistema . . . . . . . . . . .
61
4.3.1
Contrato CO1: anotarArticulo . . . . . . . . . . . . .
61
4.3.2
Contrato CO2: recuperarSecuencias . . . . . . . . . .
62
4.3.3
Contrato CO3: detectarAlineamientos . . . . . . . . .
62
4.3.4
Contrato CO4: obtenerInformacion . . . . . . . . . . .
62
4.3.5
Contrato CO5: anotarArticulo . . . . . . . . . . . . .
63
4.3.6
Contrato CO6: generarIndice . . . . . . . . . . . . . .
63
4.3.7
Contrato CO6: crearIndice . . . . . . . . . . . . . . .
63
4.3.8
Contrato CO7: crearIndice . . . . . . . . . . . . . . .
64
4.2.4
4.3
iii
4.3.9
Contrato CO8: consultarPorTexto . . . . . . . . . . .
64
4.3.10 Contrato CO8: buscarTxt . . . . . . . . . . . . . . . .
64
4.3.11 Contrato CO9: obtenerInfoDoc . . . . . . . . . . . . .
65
4.3.12 Contrato C10: obtenerSecuencias . . . . . . . . . . . .
65
4.3.13 Contrato C11: consultarPorSecuencia . . . . . . . . .
65
4.3.14 Contrato C12: consultarTxtSeq . . . . . . . . . . . . .
66
5 DISEÑO E IMPLEMENTACIÓN DEL SISTEMA
67
5.1
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
5.2
Módulos del Sistema . . . . . . . . . . . . . . . . . . . . . . .
67
5.3
Mecanismo de Comunicación . . . . . . . . . . . . . . . . . .
70
5.4
Módulo Document . . . . . . . . . . . . . . . . . . . . . . . .
71
5.4.1
Diagramas de interacción entre objetos . . . . . . . . .
71
5.4.2
Diagrama de Clases . . . . . . . . . . . . . . . . . . .
72
5.4.3
Detalle de las clases más significativas . . . . . . . . .
73
5.5
5.6
5.7
5.8
5.9
Módulo Recognition
. . . . . . . . . . . . . . . . . . . . . . .
73
5.5.1
Diagramas de Interacción entre Objetos . . . . . . . .
75
5.5.2
Diagramas de Clases . . . . . . . . . . . . . . . . . . .
75
5.5.3
Detalle de las clases más significativas . . . . . . . . .
77
Módulo BLAST
. . . . . . . . . . . . . . . . . . . . . . . . .
77
5.6.1
Diagramas de Interacción entre Objetos . . . . . . . .
79
5.6.2
Diagrama de Clases . . . . . . . . . . . . . . . . . . .
79
5.6.3
Detalle de las Clases más significativas . . . . . . . . .
79
Módulo NCBI
. . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.7.1
Diagrama de Interacción entre Objetos . . . . . . . . .
81
5.7.2
Diagrama de Clases . . . . . . . . . . . . . . . . . . .
82
5.7.3
Detalle de las Clases más significativas . . . . . . . . .
83
Módulo ResultManagement . . . . . . . . . . . . . . . . . . .
84
5.8.1
Diagrama de Interacción entre Objetos . . . . . . . . .
84
5.8.2
Diagrama de Clases . . . . . . . . . . . . . . . . . . .
85
Módulo Index . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
5.9.1
86
Diagramas de Interacción entre Objetos . . . . . . . .
5.10 Diagrama de Clases
. . . . . . . . . . . . . . . . . . . . . . .
6 EVALUACIÓN DEL SISTEMA
6.1
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
87
89
89
6.2
6.3
Evaluación
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
6.2.1
Detección de Secuencias . . . . . . . . . . . . . . . . .
90
6.2.2
Anotación de secuencias . . . . . . . . . . . . . . . . .
92
Rendimiento
. . . . . . . . . . . . . . . . . . . . . . . . . . .
7 CONCLUSIONES Y LÍNEAS FUTURAS
7.1
7.2
95
Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
7.1.1
Tratamiento de PDF . . . . . . . . . . . . . . . . . . .
95
7.1.2
Detección de secuencias . . . . . . . . . . . . . . . . .
96
7.1.3
Anotación de Secuencias . . . . . . . . . . . . . . . . .
96
7.1.4
Generación de un Índice de Artı́culos y Secuencias . .
97
Lı́neas Futuras . . . . . . . . . . . . . . . . . . . . . . . . . .
98
7.2.1
98
Extracción Estructurada de Ficheros PDF . . . . . . .
7.2.1.1
Crear una herramienta de generación de
plantillas . . . . . . . . . . . . . . . . . . . .
98
Eliminar la necesidad de uso de plantillas . .
99
Detección de Secuencias . . . . . . . . . . . . . . . . .
99
7.2.1.2
7.2.2
7.2.2.1
7.2.3
7.2.4
Adaptar el sistema para reconocer otro tipo
de secuencias . . . . . . . . . . . . . . . . . .
99
Anotación de Secuencias . . . . . . . . . . . . . . . . . 100
7.2.3.1
Utilizar bases de datos más completas . . . . 100
7.2.3.2
Utilizar supercomputadores . . . . . . . . . . 100
Creación y Mantenimiento del ı́ndice de Artı́culos y
Secuencias . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.2.4.1
7.3
92
Automatizar el proceso de obtención de
artı́culos . . . . . . . . . . . . . . . . . . . . 100
Publicaciones Derivadas de Este Trabajo . . . . . . . . . . . . 101
7.3.1
A method for automatically extracting infectious
disease-related primers and probes from the literature 101
7.3.2
PubDNA Finder: a web database linking full-text
articles to sequences of nucleic acids . . . . . . . . . . 101
REFERENCIAS
103
A INSTALACIÓN DEL SISTEMA, MANUAL DE USUARIO
Y EJEMPLOS DE USO
109
A.1 Instalación del Sistema . . . . . . . . . . . . . . . . . . . . . . 109
A.1.1 Paso 1: Prerrequisitos . . . . . . . . . . . . . . . . . . 109
v
A.1.2 Paso 2: BLAST . . . . . . . . . . . . . . . . . . . . . . 110
A.1.3 Paso 3: GenBank . . . . . . . . . . . . . . . . . . . . . 110
A.1.4 Paso 4: instalar y configurar PrimerXTractor . . . . . 111
A.2 Ejecución del Sistema . . . . . . . . . . . . . . . . . . . . . . 112
A.2.1 Detección y extracción de secuencias . . . . . . . . . . 112
A.2.2 Generación del Índice de Artı́culos y Secuencias . . . . 112
A.3 Ejemplos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . 113
A.3.1 Detección y Anotación de Secuencias usando
PrimerXTractor . . . . . . . . . . . . . . . . . . . . . 113
A.3.2 Ejemplo de uso de PubDNA Finder: interfaz web para
el ı́ndice de artı́culos y secuencias . . . . . . . . . . . . 114
B DETALLES DEL SISTEMA
117
B.1 Detección y Filtrado de Secuencias . . . . . . . . . . . . . . . 117
B.1.1 Reconocedores . . . . . . . . . . . . . . . . . . . . . . 117
B.1.1.1
Ejemplos de Reconocimiento de Secuencias . 117
B.1.2 Reglas de Filtrado . . . . . . . . . . . . . . . . . . . . 119
B.2 Anotación de Secuencias . . . . . . . . . . . . . . . . . . . . . 121
B.2.1 Cálculo del Valor de Confianza de Nombres de
Organismo y Gen . . . . . . . . . . . . . . . . . . . . . 121
C ARTÍCULOS PUBLICADOS
vi
123
Lista de figuras
1.1
Fases del sistema . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Ejemplo de Árbol de Secciones . . . . . . . . . . . . . . . . .
6
2.1
Esquema de un sistema de RI clásico . . . . . . . . . . . . . .
16
2.2
Autómata para búsqueda exacta . . . . . . . . . . . . . . . .
20
2.3
Autómata para búsqueda aproximada, utilizando una
distancia de Hamming de una unidad . . . . . . . . . . . . .
21
3.1
Ejemplo de Diagrama de Casos de Uso . . . . . . . . . . . . .
26
3.2
Ejemplo de Diagrama de Clases de Diseño . . . . . . . . . . .
28
3.3
Ejemplo de diagrama de Interacción entre Objetos . . . . . .
29
3.4
Ejemplo de Diagrama E/R
. . . . . . . . . . . . . . . . . . .
36
4.1
Diagrama de casos de uso del sistema . . . . . . . . . . . . .
53
4.2
Diagrama de secuencia para el caso de uso “Anotar Secuencias
de Artı́culo” . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
Diagrama de secuencia para el caso de uso “Generar Índice
de artı́culos y secuencias” . . . . . . . . . . . . . . . . . . . .
59
Diagrama de secuencia para el caso de uso “Consultar ı́ndice
por texto” . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Diagrama de secuencia para el caso de uso “Consultar ı́ndice
por secuencias” . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Diagrama de secuencia para el caso de uso “Consultar ı́ndice
por texto y secuencias” . . . . . . . . . . . . . . . . . . . . .
61
5.1
Módulos del Sistema . . . . . . . . . . . . . . . . . . . . . . .
68
5.2
Diagrama de Interacción entre Objetos: establecimiento de la
comunicación en PrimerXTractor. . . . . . . . . . . . . . . . .
70
Comunicación del sistema: Diagrama de Clases. . . . . . . . .
71
4.3
4.4
4.5
4.6
5.3
vii
5.4
Diagrama de Interacción entre Objetos: procesamiento de un
documento . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
5.5
Diagrama de Clases: módulo Document . . . . . . . . . . . .
73
5.6
Detalle de las Clases: módulo Document . . . . . . . . . . . .
74
5.7
Diagrama de Interacción entre Objetos: reconocimiento de
secuencias en el módulo Recognizer . . . . . . . . . . . . . . .
76
Diagrama de Interacción entre Objetos: filtrado de secuencias
en el módulo Recognizer . . . . . . . . . . . . . . . . . . . . .
76
Diagrama de Clases: módulo Recognition
. . . . . . . . . . .
77
5.10 Detalle de las Clases: módulo Recognition . . . . . . . . . . .
78
5.11 Diagrama de Interacción entre Objetos: módulo BLAST . . .
80
5.12 Diagrama de Clases: módulo BLAST
. . . . . . . . . . . . .
80
5.13 Detalle de las Clases: módulo BLAST . . . . . . . . . . . . .
81
5.14 Diagrama de Interacción entre Objetos: módulo NCBI . . . .
82
5.15 Diagrama de Clases: módulo NCBI
. . . . . . . . . . . . . .
82
5.16 Detalle de las Clases: módulo NCBI . . . . . . . . . . . . . .
83
5.17 Diagrama de Interacción entre Objetos:
módulo
ResultManagement . . . . . . . . . . . . . . . . . . . . . . . .
84
5.18 Diagrama de Clases: módulo ResultManagement . . . . . . .
85
5.19 Diagrama de Interacción entre Objetos: creación del ı́ndice
en el módulo Index (1/2) . . . . . . . . . . . . . . . . . . . .
87
5.20 Diagrama de Interacción entre Objetos: creación del ı́ndice
en el módulo Index (2/2) . . . . . . . . . . . . . . . . . . . .
87
5.21 Diagrama de Clases: módulo Index . . . . . . . . . . . . . . .
88
6.1
Secuencias Detectadas vs Secuencias no Detectadas . . . . . .
90
6.2
Secuencias Detectadas vs Falsos Positivos . . . . . . . . . . .
91
6.3
Anotación de secuencias . . . . . . . . . . . . . . . . . . . . .
92
5.8
5.9
A.1 Interfaz web PubDNAFinder . . . . . . . . . . . . . . . . . . 115
B.1 Reconocimiento de Secuencias: Reconocedores . . . . . . . . . 119
B.2 Cálculo del Valor de Confianza: Función CS . . . . . . . . . . 122
viii
Capı́tulo 1
Introducción
1.1
Planteamiento del Problema
Las tecnologı́as moleculares se usan con frecuencia en la práctica clı́nica para
la identificación de microorganismos y detección de la presencia de factores
virulentos, resistencia a antibióticos e interacciones huesped-paciente (Bravo
et al., 2009). Por ejemplo, se han desarrollado numerosos ensayos sobre
ácidos nucleicos (Mothershed et al., 2006) utilizando hibridación o técnicas
de extensión de ADN que incluyen un amplio rango de tecnologı́as como
métodos de PCR (Ratcliff et al., 2007), secuenciación de genes y genomas
completos (Woo et al., 2008; Enright et al., 1999), Luminex (Pabbaraju
et al., 2008) y análisis de mircoarrays (Miller et al., 2009)
Existen un gran número de tecnologı́as que utilizan cadenas
relativamente cortas de bases conocidas como primers y probes. Los
primers – término inglés cuya traducción es cebador o disparador – son
utilizados para la amplificación de secuencias de ADN, actuando como
disparador del proceso de amplificación. Por otro lado, los probes –
cuyo significado en castellano es sonda – son secuencias utilizadas para
la detección de secuencias concretas que serán la cadena complementaria
al probe. Primers y probes son el principal componente de los sistemas
de detección basados en ácidos nucleicos y, por tanto, han sido objeto de
numerosos estudios. Además, se han desarrollado sistemas software para
el diseño de estas secuencias especı́ficas de primers y probes minimizando
la posible hibridación cruzada que puede ser observada, por ejemplo, como
oligonucleótidos en microarrays de cDNA (Li et al., 2001) o en secuencias
de primers que aplifican un segmento único de un gen especı́fico utilizando
una técnica conocida como (RT)-PCR, o para la identificación de un amplio
espectro de patógenos humanos (Huang et al., 2005)
Tanto primers como probes son secuencias de ácidos nucleicos y no
existe un estándar de representación de este tipo de cadenas en los artı́culos
cientı́ficos. En bastantes casos, estas secuencias se encuentran delimitadas
1
PROYECTO FIN DE CARRERA
por las expresiones 5’ y 3’, o simplemente introducidas por la expresión 5’.
No obstante, la relación de ocasiones en que estas secuencias se encuentran
delimitadas o introducidas respecto del total de ocurrencias en los artı́culos
no permite asumir esta representación. Lo que sı́ es común a este tipo de
secuencias es que están formadas por el mismo conjunto de sı́mbolos, que
puede observarse en la Tabla 1.1.
La literatura cientı́fica del área de la biologı́a es la principal fuente
de información sobre primers y probes para el diagnóstico y prescripción
de enfermedades infecciosas. Las secuencias de primers y probes que
aparecen en dicha literatura resultan de gran ayuda a la hora de afrontar la
laboriosa tarea del diseño de nuevas secuencias con esta funcionalidad para
la identificación de microorganismos y estudios de expresiones genéticas y
genotipados. Por esta razón, los investigadores recurren a la búsqueda de
esta información en la literatura existente.
Durante los últimos años, diferentes técnicas de minerı́a de textos,
extracción de información e ingenierı́a del conocimiento han probado su
utilidad para la extracción, análisis y visualización de información biológica
a partir de la literatura cientı́fica en el área de la investigación biomédica
(de la Calle et al., 2009; Hirschman et al., 2005; McDonald et al., 2005;
Rice et al., 2005; Tamames, 2005; Gonzalez-Diaz et al., 2009). A pesar de
que la minerı́a de textos aplicada a datos biológicos es un campo activo de
investigación, estas técnicas no han sido utilizadas todavı́a para la creación
de métodos y herramientas cuyo objetivo sea la extracción automática
de primers y probes a partir de artı́culos cientı́ficos. Esto supone que,
en la actualidad, los investigadores normalmente recurren a la revisión
de la literatura existente para obtener las secuencias de primers y probes
relevantes ante las tareas de detección e identificación de microorganismos
concretos, determinación de interacciones huésped-microbio o el diseño de
PCR y microarrays diagnósticos. Esta revisión necesaria de la literatura es
una tarea laboriosa que requiere de una considerable inversión de tiempo.
En la actualidad existen algunos repositorios de secuencias que incluyen
primers y/o probes. Si bien se hablará más en detalle de estos repositorios
en el capı́tulo 2, baste destacar en este momento que dichos repositorios son
mantenidos de forma manual y resultan incompletos e imprecisos.
En general, los artı́culos cientı́ficos son publicados en medios fı́sicos
y/o digitales. No siempre la versión digital de los artı́culos cientı́ficos en
cuestión se encuentra accesible de forma gratuita, y no siempre es posible
encontrar una versión HTML. Dado que el formato PDF ofrece muchas
ventajas respecto a la presentación de los documentos, este formato es el
más utilizado por los investigadores y debe ser considerado como entrada
para el sistema a desarrollar.
2
CAPÍTULO 1. INTRODUCCIÓN
1.2
Objetivos
El objetivo del presente Trabajo de Fin de Carrera es dar solución a los
problemas descritos anteriormente, implementando un sistema capaz de
identificar, extraer y anotar primers y probes presentes en la literatura
cientı́fica de una forma automatizada, ası́ como de la creación de un ı́ndice
que permita la recuperación tanto de documentos asociados a secuencias
como de las secuencias existentes en los documentos. A continuación se
detallan los objetivos expuestos con un mayor nivel de detalle.
1.2.1
Formato de los Documentos
La literatura cientı́fica disponible en formato digital cuenta con diferentes
formatos de representación para los artı́culos en función del uso que se espera
del mismo. En el caso de la visualización, los principales formatos son HTML
para la visualización a través de páginas web y PDF para la descarga y
almacenamiento de los documentos por parte de los investigadores. Por
el contrario, para el tratamiento automatizado de artı́culos, el formato
más usual es XML, ya que este formato permite una representación de la
información contenida en el artı́culo con un cierto nivel de estructuración.
El sistema deberá aceptar como entrada documentos en estos dos formatos
y, para el resto de casos, deberá aceptar también documentos en texto plano,
siendo responsabilidad del investigador la extracción del contenido textual
de los documentos que se encuentren en cualquier otro formato.
1.2.2
Detección y Anotación de Secuencias
Para un documento dado, el objetivo del sistema es la extracción de las
secuencias genéticas que se encuentren contenidas en el texto del mismo.
Para cada una de las secuencias extraı́das del texto del documento deberá
intentarse, además, la anotación automática de la misma. Esta anotación
consiste en facilitar, junto con la secuencia, información sobre el nombre del
organismo y el nombre del gen relacionados con ella.
La rutina efectuada por los investigadores para obtener la información
necesaria para anotar las secuencias relacionadas con microorganismos
consiste en utilizar la herramienta BLAST (Altschul et al., 1990; National
Center for Biotechnology Information, 2009a) para detectar alineamientos
entre la secuencia contenida en el artı́culo y una base de datos de secuencias
que ha de ser proporcionada. Una vez obtenidos los alineamientos, se
accede a la base de datos Nucleotide (Benson et al., 2010; National Center
for Biotechnology Information, 2009b) con la entrada que proporciona el
alineamiento, obteniendo ası́ el nombre de organismo y de gen. Dado que
BLAST recurre a heurı́sticas en su ejecución, los resultados ofrecidos no son
3
PROYECTO FIN DE CARRERA
exactos y se muestran acompañados de valores cuya interpretación es un
ı́ndice o factor de confianza respecto al resultado generado. Normalmente,
se consideran los primeros resultados ofrecidos por la herramienta BLAST,
siendo el investigador quien finalmente discrimina entre estos resultados para
obtener el más apropiado.
1.2.3
Creación de un Índice de Artı́culos y Secuencias
Sin necesidad de disponer de las secuencias anotadas, la simple tarea de
identificación de las secuencias dentro de la literatura cientı́fica obliga a los
investigadores a revisar numerosos artı́culos para la obtención de primers y
probes. Dado que por su incompletud recurrir a los repositorios existentes
en la actualidad no ofrece suficiente fiabilidad, se plantea el objetivo de crear
un repositorio a partir de una amplia colección de literatura cientı́fica, de
forma que se minimice el tiempo necesario en la revisión de artı́culos de
forma manual, ayudando ası́ en el proceso de búsqueda de primers y probes.
1.3
Solución Propuesta
Extracción
de texto
Extracción
de
secuencias
Filtrado de
secuencias
Documentos de entrada
Anotación
Secuencias anotadas
Figura 1.1: Fases del sistema
Para la consecución de los objetivos planteados respecto a la detección y
anotación de secuencias, se plantea un método automático cuya entrada
acepte los formatos de representación de documentos PDF, XML y texto
plano, y que permita la generación de un ı́ndice de artı́culos y secuencias.
4
CAPÍTULO 1. INTRODUCCIÓN
Este método se ha dividido en cuatro fases o etapas, tal y como se muestra
en la figura 1.1. A continuación se detalla en más detalle cada una de estas
etapas. Más adelante, se comentará la forma de generar el ı́ndice de artı́culos
y secuencias.
1.3.1
Extracción del Texto de los Artı́culos
Como ya se ha comentado el sistema debe aceptar los artı́culos cientı́ficos
a través de ficheros en formato PDF, XML o texto plano. Para que las
siguientes fases del sistema no dependan del formato del fichero de entrada,
se propone crear un formato de representación interno para cualquier
artı́culo de entrada. Este formato de representación deberá conservar
la estructura de secciones del documento de entrada, lo que supone la
generación de un árbol de secciones (AS).
El árbol de secciones es una estructura de datos que representa tanto
la estructura como el contenido del documento de entrada, manteniendo la
estructura jerárquica de la información textual que contiene. En el caso de
los artı́culos en formato XML el AS se puede obtener a través de la propia
estructura del documento de forma sencilla. Por el contrario, en los formatos
PDF y texto plano la obtención del AS no es trivial, resultando imposible
en el caso del texto plano. Para el formato PDF se ha desarrollado una
herramienta perteneciente al sistema que permite la generación de un AS
para los artı́culos de entrada.
Para la obtención automatizada del árbol de secciones de un artı́culo, el
sistema recurre a una plantilla en formato XML que contiene información
sobre la maquetación del artı́culo. De esta forma, se puede utilizar una
misma plantilla para todos los artı́culos que sigan un mismo esquema de
maquetación. Frecuentemente, una misma revista sigue un mismo esquema
de maquetación para todos los artı́culos que publica, y en ocasiones este
esquema es común a un conjunto de revistas de una misma editorial –e.g.
artı́culos de BioMed Central. En la figura 1.2 puede verse un ejemplo de AS
para un artı́culo de la revista BMC Virology Journal.
Como se puede observar en la figura 1.2 en el AS cada nodo se
corresponde con una sección del documento, y las relaciones jerárquicas
entre nodos representan subsecciones del documento. De esta forma, las
subsecciones de una sección cualquiera dentro del documento quedarán
representadas como un conjunto de nodos hijo de la sección padre. Cada
nodo está formado por una tupla de la forma < tipo, tı́tulo, texto >, cuyos
elementos se corresponden, respectivamente, con el tipo de la sección, su
tı́tulo, y el texto que contiene.
Las secciones de tipo tabla y figura son tratadas de una forma peculiar en
el AS. Dado que éstos elementos no están necesariamente contenidos dentro
de las secciones a las que realmente pertenecen en los artı́culos cientı́ficos, y, a
5
PROYECTO FIN DE CARRERA
Figura 1.2: Ejemplo de Árbol de Secciones
su vez, pueden estar referenciados desde diferentes partes del documento, la
ubicación de los nodos correspondientes a estos dos tipos de secciones se sitúa
como hijos del nodo raı́z. En relación a la extracción de texto de las tablas,
ésta se realiza de una forma particular. Debido a que es frecuente encontrar
6
CAPÍTULO 1. INTRODUCCIÓN
secuencias genéticas organizadas en tablas y que estas tablas almacenan la
información en celdas, no es suficiente una lectura lineal para garantizar
la correcta extracción de las secuencias. Por este motivo, la lectura de las
tablas se realiza extrayendo todo el contenido de las celdas y concatenando el
contenido de celdas sucesivas en una misma fila introduciendo un delimitador
artificial que asegura que de contener secuencias, éstas no se reconocerán
dentro de una única secuencia.
El nodo raı́z es un nodo artificial que no se corresponde, en realidad,
con ninguna sección del documento, pero su existencia permite finalizar la
estructura en forma de árbol haciendo que todos las secciones de máximo
nivel pertenecientes al documento estén contenidas en él. De esta forma,
igual que se puede entender el sub-árbol dependiente de un nodo como
la representación de la sección completa asociada a dicho nodo, el nodo
raı́z representa todo el documento. De hecho, realizando una búsqueda en
profundidad del árbol de secciones es posible recuperar todo el texto de
un artı́culo en el mismo orden en que este texto aparece en el documento
original.
1.3.2
Reconocimiento de Secuencias
En esta fase del proceso, es necesario identificar las cadenas de letras
que forman secuencias candidatas. Para la realización de esta tarea, se
han estudiado 40 artı́culos seleccionados por un panel de expertos como
muestra representativa1 de la diversidad de formatos de representación que
se emplean para la publicación de primers y probes.
Tanto primers como probes están formados por secuencias de un conjunto
de sı́mbolos concreto. En lo sucesivo, se nombrará a este conjunto como Σ,
y los sı́mbolos pertenecientes a ete conjunto se encuentran detallados en
la Tabla 1.1. Para nombrar a todas las posibles secuencias –no vacı́as– de
sı́mbolos de Σ se utilizará, a su vez, el término Σ+ . Es necesario destacar
que en los artı́culos, los sı́mbolos de Σ aparecen indiscriminadamente en
su representación como letras mayúsculas y minúsculas, por lo que no es
posible hacer distinción entre estos dos casos.
En cuanto a la representación de primers y probes en la literatura, se han
encontrado multitud de posibilidades. Es frecuente encontrar las secuencias
delimitadas o introducidas por términos concretos.
• Secuencias delimitadas: los delimitadores son generalmente los
términos 5’ y 3’. Siempre que uno de los delimitadores indica el
1
Los artı́culos seleccionados no forman parte del conjunto de pruebas y este conjunto
de pruebas no se encontraba disponible durante la implementación del sistema.
7
PROYECTO FIN DE CARRERA
Sı́mbolo
Nucleótidos
Permitidos
Nucleótidos
Complementarios
Significado
A
A
T
[A]denina
B
C|G|T
V
Cualquiera
excepto Adenina
C
C
G
[C]itosina
D
A|G|T
H
Cualquiera
excepto Citosina
G
G
C
Guanina
H
A|C|T
D
Cualquiera
excepto Guanina
K
G|T
M
[K]eto
M
A|C
K
A[M]ino
N
A|C|G|T
N
Cualquier
nucleótido
R
A|G
Y
[P]urina
S
C|G
S
Enlaces fuertes
T
T
A
[T]inina
V
A|C|G
B
Cualquiera
excepto Tinina
W
A|T
W
Enlaces débiles
Y
C|T
R
Pirimidina
Tabla 1.1: Tabla correspondiente a los sı́mbolos de Σ
comienzo de la secuencia, el otro indicará el final. En ocasiones no
aparece el sı́mbolo ’.
• Secuencias introducidas: tan sólo aparece el delimitador de comienzo
de la secuencia, esto es 5’ o 3’. En ocasiones se prescinde del sı́mbolo
’ y se sustituye por • Secuencias no delimitadas: no utilizan ninguna expresión ni para
delimitar ni para introducir la secuencia.
De forma independiente de si las secuencias se encuentran delimitadas,
no delimitadas o introducidas, es posible encontrar algunos caracteres entre
los sı́mbolos de la misma. Estos caracteres son el espacio y el guión. El
espacio se encuentra como separador de la secuencia, generalmente en grupos
8
CAPÍTULO 1. INTRODUCCIÓN
de un tamaño fijo, que en la mayorı́a de los casos es de tres sı́mbolos por
grupo. No obstante, también se utiliza el espacio para separar secuencias
largas de forma que éstas puedan ocupar varias lı́neas de texto. Para este
último uso también se utiliza el guión. Aunque estos son los casos más
generales de uso de los mencionados caracteres, lo cierto es que los casos en
los que es posible encontrar tanto espacios como guiones de forma arbitraria
en cualquier lugar de la secuencia no suponen un caso marginal y, por
lo tanto, esta arbitrariedad debe tenerse en cuenta como caso general de
representación, añadiendo a los caracteres mencionados el identificador de
fin de lı́nea.
Basándose en las representaciones descritas, el método propone la
creación de tres reconocedores diferentes. Estos tres reconocedores están
orientados a detectar diferentes representaciones de secuencias atendiendo a
la seguridad con la que se puede afirmar que cadena perteneciente a Σ+ es
realmente un primer o un probe. Los reconocedores y los tipos de secuencia
que reconocen son los siguientes:
• Reconocedor 1: reconoce secuencias delimitadas por alguno de los
siguientes pares de expresiones: 5’ . . . 3’, 3’ . . . 5’, 5 . . . 3, 3 . . . 5 o que
comienzan por las expresiones 5’, 5, 3’ o 3. Se permite la aparición de
los caracteres de espacio y fin de lı́nea, y pueden ocupar varias lı́neas.
• Reconocedor 2: reconoce las secuencias agrupadas en grupos de tres
sı́mbolos de Σ separados por espacios, a excepción del último grupo,
que tendrá, como máximo, un tamaño de 3 sı́mbolos. Pueden ocupar
más de una lı́nea.
• Reconocedor 3: reconoce todas las cadenas de Σ+ . Estas cadenas
pueden contener los caracteres de espacio y guión además de ocupar
varias lı́neas.
Los reconocedores están pensados para trabajar de forma conjunta en la
detección de secuencias. De esta forma, todas las cadenas que no hayan
sido reconocidas por el primer reconocedor pasarán automáticamente al
segundo y, en caso de tampoco ser reconocida ninguna cadena, al tercero. Sin
embargo, cuando un reconocedor reconoce una cadena como una secuencia
candidata, el texto ya leı́do correspondiente a dicha cadena no pasará a los
siguientes reconocedores. La razón para este funcionamiento en cascada de
los reconocedores se debe a que, sabiendo cual es el reconocedor utilizado
se puede tener una estimación inicial de la confianza de que la cadena
reconocida pueda ser, efectivamente, un primer o un probe.
Como resultado del proceso de reconocimiento, no se genera una única
cadena de sı́mbolos, sino una agrupación de cadenas –en lo sucesivo, tokens.
Cada token será una cadena perteneciente a Σ+ . La existencia de varios
9
PROYECTO FIN DE CARRERA
tokens es el resultado de eliminar los sı́mbolos de espacio y guión de la
secuencia reconocida. Es necesario conservar esta separación en tokens para
la siguiente etapa.
1.3.3
Filtrado de Secuencias
El objetivo de esta fase es el refinamiento de las secuencias, que a la
entrada de esta fase se encuentran en la forma de una lista de tokens.
Este refinamiento consiste en descartar falsos positivos, depurar secuencias
con ruido y dividir secuencias que han sido reconocidas conjuntamente. A
continuación se ofrece una explicación más detallada de cada uno de los
citados problemas a resolver en esta etapa.
Respecto a los falsos positivos detectados, esto se debe a la variedad
de sı́mbolos de Σ. Con dichos sı́mbolos, es posible formar palabras en
inglés, como por ejemplo standard, abstract o assay. Para poder identificar
estas palabras, se ha recurrido a un diccionario de palabras inglesas formada
exclusivamente por sı́mbolos de Σ, creada especı́ficamente para este sistema.
En lo referente a la incorporación de ruido en las secuencias, esto se
debe a que algunas de las palabras incluidas en la lista de términos ingleses
formados por sı́mbolos de Σ puede haber sido reconocida de forma conjunta
con la secuencia, al principio o al final de la misma, generando ası́ prefijos y/o
sufijos no deseados. Además, existen ciertas expresiones, como TAMRA-T
que aparecen en ocasiones de forma conjunta con las secuencias y que no
son palabras inglesas. Se han detectado los posibles términos que plantean
este problema y se han incluido en una lista especı́fica de afijos.
De forma similar a lo anteriormente descrito, las palabras o expresiones
que pueden aparecer de forma conjunta con las secuencias, pueden
encontrarse dentro de una única secuencia candidata. En este caso es
necesario dividir la secuencia candidata en dos fragmentos delimitados por
dicha palabra o expresión. Un ejemplo de este caso serı́a la secuencia
candidata formada por los siguientes tokens: “ACRSTGT”, “and” y
“CGRTTN”.
El método a implementar trata esta fase utilizando un sistema experto
(Harmon et al., 1985), realizando un proceso iterativo de refinamiento
recurriendo a una base de reglas que solucionan los problemas descritos, ası́
como al diccionario de palabras y a la lista de afijos. Las reglas especı́ficas
pueden consultarse en el Apéndice B.
1.3.4
Anotación de Secuencias
En esta última fase se recurre a bases de datos externas con el objetivo
de extraer información adicional sobre las secuencias. Estos recursos
son BLAST y Entrez Nucleotide. Si bien ambos recursos se encuentran
10
CAPÍTULO 1. INTRODUCCIÓN
disponibles a través de internet, se plantea su descarga y uso local por
motivos de rendimiento. La información adicional que se pretende recuperar
para cada secuencia son el nombre del organismo al que la secuencia
pertenece y el nombre del gen en que se encuentra la secuencia.
En primer lugar se ejecuta la herramienta BLAST sobre la base de datos
de microorganismos descargada en formato FASTA. Esta consulta devuelve
una serie de entradas relevantes, de las que se escogen las diez primeras –con
mejor puntuación. Para cada una de las diez entradas obtenidas utilizando
BLAST se recurre a la base de datos Nucleotide para obtener, si están
disponibles, los nombres del organismo y del gen asociados.
Una vez obtenidos los posibles nombres de organismo y de gen para cada
secuencia, se realiza una búsqueda del nombre de organismo y del gen en
el texto. Respecto al nombre de organismo, éste puede aparecer en el texto
bajo diferentes nombres –e.g. “Brucella Mellitensis” puede aparecer como
“B. Mellitensis”. Además, es necesario considerar resultados parciales –e.g.
simplemente “Brucella”. El nombre del gen, sin embargo, aparecerá con una
única expresión en el texto y no se permiten resultados parciales.
A cada nombre de organismo y a cada gen encontrados en el texto se les
asigna un valor de confianza, que será un valor de 0 a 100. El cálculo de este
valor depende de la localización en el texto del artı́culo del nombre del gen
respecto de la secuencia en cuestión, y de si se trata de un resultado parcial
en la búsqueda del término en el texto. En el caso de los genes, se asignará
un valor de 80 puntos si el gen se encuentra en el texto, y de 100 puntos
si, además, se encuentra en la misma sección que la secuencia. De forma
similar, se aplicará este sistema también a los nombres de organismo, salvo
que los 80 puntos asignados por aparecer en el texto sólo se otorgarán en
caso de que se encuentre un resultado completo en la búsqueda. La función
que calcula la puntuación exacta entre 0 y 80 dependiendo de la búsqueda
en el texto se detalla en el Apéndice B.
1.3.5
Generación de un Índice de Artı́culos y Secuencias
La generación del ı́ndice utiliza técnicas de recuperación de información
para relacionar un artı́culo con las secuencias que contiene. De esta
forma, introduciendo una consulta en forma de secuencia genética podrán
recuperarse los artı́culos relacionados, e introduciendo un artı́culo, se podrán
recuperar las secuencias del mismo de forma automática. Además, también
se incluirá en el indice el contenido textual del documento, añadiendo ası́
una mayor capacidad de búsquedas.
Para generar el ı́ndice se utilizarán las dos primeras fases descritas
anteriormente, es decir, la extracción del contenido textual de los
documentos y el reconocimiento y posterior refinamiento de las secuencias
contenidas en ellos. Para facilitar las tareas de consulta sobre el ı́ndice se
11
PROYECTO FIN DE CARRERA
creará un interfaz web.
Se permitirá buscar todos los artı́culos relacionados con un conjunto de
secuencias, ası́ como se podrán buscar todas las secuencias relacionadas con
los artı́culos que, a su vez, sean relevantes para una consulta determinada.
Además, se podrá realizar un último tipo de búsqueda similar a este último,
en el que además, se limitan las posibles secuencias a las especificadas en la
consulta.
Para conseguir este tipo de búsquedas se permite dividir la consulta en
dos partes, una para secuencias y otra referida al contenido de los artı́culos.
En la segunda parte se podrán especificar elementos del contenido textual
del documento o campos del mismo, como son el identificador, el tı́tulo o los
autores. Todas las consultas pueden ser formuladas utilizando la sintaxis de
consultas que se puede encontrar en el Apéndice A.
12
Capı́tulo 2
ESTADO DE LA
CUESTIÓN
2.1
Introducción
En este capı́tulo se describe el estado de la cuestión actual en relación al
Proyecto de Fin de Carrera. En primer lugar se muestran las herramientas
y recursos con funcionalidades similares más importantes que existen en la
actualidad. A continuación se presentan los fundamentos teóricos relevantes
utilizados en el este Trabajo.
2.2
Trabajos Previos Relacionados
Durante los últimos años, diversas técnicas como la minerı́a de textos,
extracción de información e ingenierı́a del conocimiento se han aplicado con
éxito para la extracción, análisis y visualización de información biológica a
partir de la literatura cientı́fica sobre investigación biomédica (de la Calle
et al., 2009; Hirschman et al., 2005; McDonald et al., 2005; Rice et al., 2005;
Tamames, 2005; Gonzalez-Diaz et al., 2009). A pesar de que las aplicaciones
estas técnicas sobre fuentes biológicas es un campo de investigación activo,
no han sido aplicadas aún para la creación de métodos y herramientas que
permitan la extracción de secuencias genéticas como primers y probes de
forma automatizada a partir de la literatura.
Este trabajo se ha realizado para satisfacer una demanda de los
investigadores de ciertas áreas de la Bioinformática. En cuanto a la detección
de secuencias en la literatura, no se ha encontrado ninguna herramienta
anterior que realice esta tarea en concreto. Hasta la actualidad, la mayorı́a
de enfoques orientados al reconocimiento de secuencias genéticas (Hyyro
et al., 2005; Tarhio et al., 1997; Cheng et al., 2003; Anvar et al., 2010) se
basan en la detección o alineamiento de los sı́mbolos de nucleótidos básicos
13
PROYECTO FIN DE CARRERA
–i.e. A, C, G y T –. Algunos sistemas, como Kangaroo (Betel et al., 2002)
trabaja sobre el mismo conjunto de sı́mbolos que el presente Proyecto de
Fin de Carrera, no obstante, su funcionamiento se basa en detectar patrones
sobre secuencias –ya detectadas– utilizando expresiones regulares a partir de
una fuente de datos estructurada que almacena dichas secuencias. Dadas las
diferencias en cuanto a ls funcionalidad ofrecida y la fuente de información,
no es realmente una posibilidad de comparación.
Respecto a la creación de un ı́ndice de secuencias del tipo primer y probe,
existen algunas alternativas en la actualidad. A continuación se destacan
las más importantes.
• Molecular Probe Data Base (Campi et al., 1997), disponible a
través del “Sequence Retrieval System” (LION bioscience AG, 2003).
Este repositirio contiene información sobre oligonucleótidos sintéticos
utilizados como primers y probes.
• PrimerBank (Spandidos et al., 2010; The Massachusetts General
Hospital, 2006), creado para recuperar información sobre primers para
humanos y ratones para el análisis de expresiones genéticas mediante
PCR y QPCR (VanGuilder et al., 2008).
• NCBI
Probe
Database
(National
Center for Biotechnology Information, 2009c) es un registro público
de reactivos de ácidos nucléicos diseñados para su uso en un amplio
rango de aplicaciones en la investigación biomédica.
• RTPrimerDB (Pattyn et al., 2003; Center for Medical Genetics, 2002)
y probeBase (Loy et al., 2007; University of Vienna. Department of
Microbial Ecology, 2003) son bases de datos de acceso gratuito que
contienen secuencias de primers y probes validadas empı́ricamente.
Todos los recursos de la lista anterior son, efectivamente, repositorios de
secuencias genéticas como primers y probes. No obstante, la actualización
de estos repositorios se realiza manualmente a través de las colaboraciones
de los diferentes investigadores, lo que hace que estos repositorios sean
incompletos y costosos de mantener. En último término los investigadores
están frecuentemente obligados a recurrir a la literatura para la obtención
de estas secuencias. La principal diferencia de estos repositorios respecto
al presente Trabajo de Fin de Carrera es, por tanto, que en este último las
secuencias son detectadas de forma automática y a partir de la literatura
cientı́fica, no requiriendo de la colaboración expresa de los investigadores más
allá de la publicación de sus artı́culos cientı́ficos, y permitiendo la detección
y mantenimiento de un gran volumen de secuencias a un bajo coste.
14
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
2.3
2.3.1
Fundamentos Teóricos
Recuperación de Información
La recuperación de información (en lo sucesivo, RI) es un campo que
permite obtener documentos –i.e. elementos con un contenido textual– a
partir de búsquedas o consultas textuales. En un principio se utilizaban
técnicas simples como búsquedas directas y métodos estadı́sticos puros,
pero tras la explosión de Internet ha sido un área de intenso estudio
dada la necesidad de recuperar páginas web a partir de consultas basadas
en palabras, refinándose cada vez más e incorporando nuevas técnicas y
algoritmos. Éstas técnicas van desde las orientadas al procesamiento de
lenguaje natural a la representación del conocimiento contenido en los
documentos mediante ontologı́as.
2.3.1.1
Visión General de un Sistema Clásico de RI
Para su funcionamiento, un sistema de RI necesita una colección de
documentos sobre los que poder realizar las búsquedas, y una consulta para
la que poder ofrecer resultados. Visto como una caja negra, a partir de
dicha colección y dicha consulta, el sistema de recuperación de información
devolverá un conjunto de documentos pertenecientes a la colección que son
relevantes para la consulta.
Los elementos tı́picos de un sistema clásico de RI son:
• Función de representación: transforma el contenido textual de
las consultas y los documentos en una representación interna.
Generalmente esta función elimina los elementos textuales que no
aportan información ni significado a los documentos.
• Índice: los documentos transformados se almacenan en el ı́ndice. El
ı́ndice debe de ser capaz de obtener los documentos a partir de los
términos contenidos en los mismos de forma eficiente.
• Función de comparación: esta función sirve para discernir qué
documentos son relevantes a una consulta y, además, permite asignar
un valor a dicha relevancia, de forma que sea posible realizar una
ordenación de los documentos resultado según su relevancia respecto
de la consulta proporcionada.
El funcionamiento tı́pico de un sistema de Recuperación de Información
consta de dos etapas. La primera etapa consiste en la creación del ı́ndice de
términos a partir de la colección de documentos. En esta etapa se almacena
ası́ el contenido de los documentos de forma que éstos sean recuperables
15
PROYECTO FIN DE CARRERA
Consulta
Resultados
Función de
Representación
Función de
Representación
Función de
Comparación
Índice
Colección de
Documentos
Figura 2.1: Esquema de un sistema de RI clásico
a partir de los términos que contienen, tras eliminar los términos no
significativos. La segunda etapa se inicia al ser proporcionada una consulta.
En primer lugar, esta consulta se transforma para eliminar de la misma los
términos que no aportan información. Entonces, se extraen los documentos
relevantes a la consulta realizada del ı́ndice. Debe tenerse en cuenta que la
colección inicial de documentos puede ser muy grande –e.g. en el caso de
Internet, la gran mayorı́a de páginas web son candidatas a ser indizadas – y
potencialmente, el conjunto de documentos que conforman el resultado de la
consulta puede, también, ser muy numeroso. Por lo tanto, es necesaria una
última fase de ordenación de dichos resultados, si bien esta ordenación suele
realizarse, por motivos de eficiencia, de forma conjunta con la extracción
de los documentos relevantes. En la figura 2.1 puede observarse el esquema
tı́pico de un sistema de RI.
2.3.1.2
Creación del Índice de Documentos
El contenido textual de un documento puede ser visto como una sucesión
de términos. El objetivo del ı́ndice es almacenar los documentos a través
del almacenamiento de los términos contenidos en ellos, manteniendo la
relación de pertenencia de términos y documentos. Dado que el objetivo del
ı́ndice será obtener documentos a partir de términos, suelen estructurarse
como una lista de términos asociando a cada término los documentos en los
que éste aparece. Además, es posible utilizar valores estadı́sticos –e.g. la
frecuencia con que un término aparece en un documento o en la colección–
para asignar pesos a estos términos, tanto de forma exclusiva –i.e. un valor
por término–, como relativa a los documentos –i.e. un valor para cada par
término-documento.
Dado que no todos los términos aportan la misma cantidad de
16
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
información sobre el documento, es posible reducir el tamaño del ı́ndice
no indizando todos los términos. Algunos términos, como las preposiciones,
pueden provocar que se extraigan demasiados documentos del ı́ndice como si
fueran relevantes, aumentando innecesariamente el conjunto de documentos
resultado. Para detectar qué términos no incluir en el ı́ndice, se suelen
utilizar listas de palabras con una alta frecuencia de uso y sin valor en
cuanto a la información que aportan al estar contenidas en un documento.
Como puede observarse, estas listas son dependientes del idioma, por lo
que será necesario conocer de antemano el idioma de cada documento de
la colección. También se pueden utilizar medidas como idf (proveniente del
inglés “inverse term frequency”) que mide la importancia de un término
en la colección, con el objetivo de detectar términos poco significativos y
descartarlos para su indización.
Por otro lado, para mejorar la concordancia de términos de la consulta
respecto a los términos del ı́ndice, es posible reducir los términos a sus
lexemas –i.e. proceso conocido como lematización– de forma que se mejora
la concordancia y se reduce el tamaño del ı́ndice.
2.3.1.2.1
Estructura del Índice
A continuación se indican las estructuras de datos más frecuentemente
utilizadas para la creación de los ı́ndices en los sistemas de RI. Como
se ha mencionado anteriormente, el ı́ndice debe permitir la obtención de
documentos a partir de términos, y dado que los sistemas de RI suelen
manejar grandes cantidades de datos, la eficiencia del proceso de extracción
de documentos a partir de términos utilizando el ı́ndice tiene un gran
impacto en la eficiencia del sistema de RI.
Árboles Trie: se trata de una estructura de árbol n-ario en la que
cada nodo representa un sı́mbolo de un término, de forma que si un sı́mbolo
sucede a otro en el término, entonces el nodo correspondiente al segundo
sı́mbolo será hijo del nodo correspondiente al primer sı́mbolo. Asociado a
cada nodo final de un término se encontrará almacenada una lista con los
identificadores de los documentos que lo contienen. La principal ventaja de
esta estructura de datos es que permite realizar las operaciones de inserción,
borrado y recuperación en un orden de complejidad dependiente sólo de
la longitud del término de entrada. Además, permite realizar con gran
eficiencia búsquedas de prefijos y búsquedas aproximadas.
Ficheros invertidos: los ficheros invertidos son en realidad, tres
estructuras de datos: (1) un diccionario, que contiene todos los términos del
ı́ndice, (2) un fichero de listas invertidas, que contiene, para cada término,
los documentos en los que este aparece y (3) un fichero de documentos, con
17
PROYECTO FIN DE CARRERA
todos los términos de cada documento. Para cada término del diccionario, se
asocia la posición en la lista invertida de términos, junto con más información
que pueda ser utilizada posteriormente, como diferentes pesos o medidas
relativas al término. Nótese que el hecho de almacenar los términos tal y
como aparecen en los documentos originales en el fichero de documentos, se
puede dotar posteriormente al sistema de RI con más funcionalidades que
las descritas hasta el momento, como pueden ser el uso de frases exactas
en las consultas, obligando a que dichas frases exactas aparezcan en los
documentos resultado con la misma sucesión de términos.
2.3.1.2.2
Enfoques Más Importantes
En este apartado se plantean los enfoques más significativos en el campo de
la RI. Los enfoques varı́an en cuanto a la representación de los documentos,
y su relación respecto a los términos que contienen.
Modelo Booleano : (Baeza-Yates et al., 2008; Salton et al., 1986;
Rijsbergen et al., 1979) este modelo se basa en representar cada documento
como un conjunto de términos, de forma que la Función de Comparación es
una función binaria equivalente a la función de pertenencia a un conjunto.
El nombre “Booleano” viene dado por la posibilidad de utilizar operadores
booleanos sobre los términos de las consultas, de forma que cada consulta
es un predicado que utiliza los operadores booleanos sobre el resultado
de aplicar la función de pertenencia de la teorı́a de conjuntos sobre cada
documento. Como se puede observar, este modelo carece de la posibilidad
de ordenar los resultados obtenidos a partir de la consulta, resultando, por lo
tanto, poco útil a dı́a de hoy. No obstante, por su simplicidad, este modelo
se utilizó con cierta frecuencia en el pasado.
Modelo Vectorial : (Salton et al., 1975) en este enfoque, se utilizan
todos los términos de la colección como ejes de coordenadas de un espacio
vectorial en el que los documentos se representan como vectores. Cada
coordenada concreta de un documento se calcula utilizando una relación
entre el documento y el término, como la frecuencia de aparición del término
en el documento, o el valor idf mencionado anteriormente. De esta forma,
es posible calcular la similitud de una consulta respecto de un documento
mediante una función distancia sobre el espacio vectorial, representando
la consulta a su vez como un vector del modelo. Normalmente, las
relaciones entre los términos de la consulta y los términos de la colección
utilizan métricas diferentes para el cálculo de las coordenadas, como la
frecuencia de aparición de los términos en la colección. Una de las distancias
más utilizadas es la utilización del ángulo entre los vectores consulta y
documento. Utilizando este modelo, no sólo se pueden determinar qué
18
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
documentos son relevantes a una consulta dada, lo que se puede hacer
fácilmente fijando un umbral de distancia, sino que se pueden comparar
las diferentes distancias para realizar una ordenación del conjunto de
documentos resultado.
Modelo Probabilı́stico : (Robertson, 1997; Sparck Jones et al., 1997)
dada una consulta q existe una probabilidad Pi de que un documento di ,
perteneciente a la colección D sea relevante para dicha consulta. Ésto
supone que existe un conjunto de documentos relevantes para cada consulta,
por lo que Pi indicará la probabilidad de que el documento di pertenezca
al conjunto de documentos relevantes para la consulta q. Conocer qué
documentos son relevantes para cada consulta, o lo que es lo mismo, cuales
son los conjuntos de documentos relevantes para cada consulta posible,
no es una tarea viable. Sin embargo, el enfoque de este modelo consiste
en estimar un conjunto inicial a partir de los términos de la consulta,
utilizando técnicas ya mencionadas –e.g. frecuencias de términos o idf – e ir
refinándolo progresivamente, mejorando la estimación de las probabilidades
de pertenencia de los documentos a los conjuntos asociados a las consultas.
2.3.1.2.3
Evaluación de Sistemas de RI
Saber cómo se comporta un sistema de RI es fundamental para poder
mejorarlo. Con este objetivo, se utilizan dos medidas fundamentales:
• Exhaustividad: esta medida refleja la cantidad de documentos
relevantes que se han seleccionado para el conjunto de documentos
resultado. Matemáticamente, viene definida por la expresión:
recall =
|documentos recuperados ∩ documentos relevantes|
|documentos relevantes|
• Precisión: la precisión mide la calidad de los resultados obtenidos, es
decir, cómo de relevantes son los documentos recuperados. Se calcula
utilizando la siguiente expresión:
precision =
|documentos recuperados ∩ documentos relevantes|
|documentos recuperados|
Estas dos medidas pueden relacionarse entre sı́ mediante una tercera,
llamada medida-F, que las relaciona:
F =2·
precision · recall
precision + recall
19
PROYECTO FIN DE CARRERA
2.3.2
Búsqueda en Textos Mediante Autómatas Finitos
La búsqueda en textos se refiere a encontrar la ocurrencia de un patrón en un
texto. Se pueden distinguir diferentes tipos de búsquedas en función de las
caracterı́sticas del patrón, y de la exactitud con la que se considere aceptar
una coincidencia del patrón en el texto. El uso de autómatas para esta
tarea permite realizar búsquedas tanto exactas como aproximadas de forma
sencilla y eficiente(Melichar et al., 2005). El funcionamiento general de estos
algoritmos supone la construcción de un autómata para cada secuencia de
búsqueda. Una vez construida la máquina de estados finitos, tan sólo se
requiere la alimentación de la misma con los términos del texto para que
éste detecte las ocurrencias del patrón buscado. Dicho patrón consistirá, en
este caso, en un término o secuencia de términos que deberán aparecer en
el texto. En el caso de secuencias de términos, se buscará la ocurrencia en
el texto de la misma secuencia exacta de términos.
Dados un alfabeto de sı́mbolos A, un texto T compuesto por la sucesión
de términos –i.e. sucesión ordenada de sı́mbolos de A– t1 , t2 , ..., tn y un
patrón P compuesto por los términos p1 , p2 , ..., ps , dependiendo de cómo se
defina la equivalencia de los términos ti y lso términos pi podremos distinguir
entre los siguientes tipos de búsqueda:
• Búsqueda exacta: La búsqueda exacta será satisfactoria cuando se
encuentre la secuencia exacta de términos pi que componen P en el
texto T . Dicho de otro modo, cuando P sea una subsecuencia de T .
El autómata correspondiente a este tipo de búsqueda puede observarse
en la figura 2.3
p1
p2
p3
pn
Figura 2.2: Autómata para búsqueda exacta
• Búsqueda aproximada: La búsqueda aproximada difiere de la
búsqueda exacta en que un término ti del texto T se reconocerá como
una ocurrencia del término pj del patrón P utilizando una función
de distancia. De esta forma, será necesario especificar qué función
de distancia se utilizará, ası́ como la distancia máxima hasta la cual
se considerará que el término ti es equivalente al término pj . Las
funciones distancias más comunes son:
– Distancia Hamming o Distancia-R: mide la distancia entre dos
términos t1 y t2 de sı́mbolos de un alfabeto A como el mı́nimo
20
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
número necesario de sustituciones –i.e. cambiar un sı́mbolo por
otro– que hay que realizar sobre t1 para obtener t2 . Puede
observarse un ejemplo del autómata generado para realizar
búsquedas aproximadas utilizando esta distancia en la figura ??
– Distancia de Levenshtein o Distancia-DIR: esta función calcula la
distancia entre t1 y t2 como el mı́nimo número de sustituciones,
borrados –i.e. eliminar un sı́mbolo de un término– e inserciones
–i.e. introducir un nuevo sı́mbolo en el término– necesarios para
obtener t2 a partir de t1 .
– Distancia generalizada de Levenshtein o Distancia-DIR T:
además de las operaciones permitidas en la distancia de
Levenshtein, esta función permite también el uso de la operación
trasposición –i.e.
intercambiar el orden de dos sı́mbolos
consecutivos.
p1
A - {p1}
p2
p3
A - {p2}
pn
A - {p3}
p2
p3
A - {pn-1}
p4
pn
Figura 2.3: Autómata para búsqueda aproximada, utilizando una distancia
de Hamming de una unidad
21
PROYECTO FIN DE CARRERA
22
Capı́tulo 3
TECNOLOGÍAS,
LENGUAJES Y
ESTÁNDARES
EMPLEADOS
3.1
UML
UML es acrónimo de Unified Modeling Language (Larman, 2002), cuyo
significado en español es Lenguaje de Modelado Unificado. Este lenguaje
es el más utilizado para la realización del diseño del sofware orientado a
objetos, por lo que ha sido elegido para su uso en el presente Proyecto de
Fin de Carrera.
El lenguaje UML nace de los esfuerzos de la empresa Rational Software
Corporation en los años 90 por unificar los diferentes esquemas de modelado
orientados a objetos existentes. Los dos esquemas más destacados de aquella
época eran el OMT (Object-modeling technique) y el Método Booch, creados
por Rumbaugh y Booch respectivamente. Rumbaugh, Booch y Jacobson
(creador del método de ingnierı́a de software orientado a objetos) trabajaron
conjuntamente en la especificación del lenguaje UML. Tras incorporar la
colaboración de empresas externas, UML se convirtió en 1997 en un estándar
del OMG (Object Management Group).
Una de las principales caracterı́sticas de UML es el Modelado Visual.
Éste consiste en la abstracción del sistema mediante una notación especı́fica,
principalmente gráfica. De esta forma, se puede plantear el sistema mediante
la representación de sus diferentes componentes y la interacción entre los
mismos. El modelado visual es a la ingenierı́a del software, por lo tanto, lo
que los planos son a la arquitectura. UML es, además, un método formal de
modelado, lo que supone una caracterı́stica fundamental desde el punto de
vista de la ingenierı́a del software. Utilizando la notación gráfica UML es
23
PROYECTO FIN DE CARRERA
posible definir de forma precisa y rigurosa el comportamiento de un sistema
software orientado a objetos de forma independiente del lenguaje concreto de
programación con el que se vaya a implementar el sistema con posterioridad,
además, se pueden realizar verificaciones y validaciones del comportamiento
del sistema sobre el diseño UML.
3.1.1
Notación UML
Si bien UML es un lenguaje de una gran expresividad y con numerosas
particularidades, en esta sección sólo se describirán aquellas herramientas
que el lenguaje proporciona y que han sido utilizados en el diseño de este
Proyecto de Fin de Carrera.
3.1.1.0.4
Casos de Uso
Un caso de uso recoge la funcionalidad ofrecida por el sistema hacia un
usuario concreto. Se trata de una técnica muy utilizada para la captura
de requisitos, ya que permite definir qué ofrecerá el sistema a cada tipo
de usuario. Para continuar con la exposición, son necesarias algunas
definiciones:
• Actor: entidad externa al sistema que tiene algún tipo de interacción
con el mismo. Puede tratarse del rol ejercido por parte de personas
–e.g. un usuario o un administrador – o de sistemas o dispositivos
–e.g. una cola de impresión o un sistema de validación de tarjetas de
crédito. Los actores de un sistema software pueden clasificarse dentro
de alguna de las siguientes categorı́as:
– Principal: actor cuyos objetivos quedan satisfechos a través del
caso de uso.
– De apoyo: actor que proporciona servicios al sistema.
– Pasivo: actor que sin interactuar directamente con el sistema, se
ve afectado por el caso de uso o afecta al mismo.
• Escenario: es la secuencia de acciones, desde el punto de vista de
la interacción entre el usuario y el sistema, que se lleva a cabo para
satisfacer el objetivo del caso de uso. Dependiendo de si se trata de
la secuencia de acciones esperada, o de una variante de la misma en
función de algún error o evento excepcional, el escenario será nombrado
como principal o alternativo, respectivamente.
En función del contexto en que se realice el caso de uso, éste puede
encontrarse definido bajo tres representaciones diferentes:
24
CAPÍTULO 3. TECNOLOGÍAS, LENGUAJES Y ESTÁNDARES EMPLEADOS
• Breve: se trata de un párrafo que resume el comportamiento normal
–i.e. escenario principal– de un caso de uso.
• Informal: agrupa varios párrafos escritos en lenguaje informal que
describen tanto el escenario principal como los escenarios alternativos
de un caso de uso.
• Completo: describe detalladamente y de forma estructurada todos
los posibles escenarios y actores del caso de uso, junto con otras
particularidades del mismo como las precondiciones y postcondiciones.
3.1.1.0.5
Diagrama de Casos de Uso
El diagrama de casos de uso es una notación gráfica que refleja todos los
actores y casos de uso del sistema, dando ası́ una visión general del mismo
desde el punto de vista de las funcionalidades que ofrece y sus dependencias
respecto de otros sistemas con los que interactúe. De cara a los conceptos
introducidos anteriormente esta notación asocia a los mismos los siguientes
elementos gráficos:
• Sistema: se representa mediante una caja que contiene los casos de
uso.
• Caso de uso: se representa mediante una elipse, cuyo contenido es el
nombre del caso de uso.
• Actor: se representa como una figura humana esquematizada. Debajo
de la misma se encuentra el nombre del actor.
Es necesario indicar que los casos de uso pueden encontrarse relacionados
entre sı́. Las posibles relaciones son:
• Inclusión:
se utiliza cuando varios casos de uso tienen un
comportamiento común, o se quiere simplificar algún caso de uso
dividiéndolo en otros casos de uso más pequeños. Se representa
mediante la expresión << include >>
• Extensión: se utiliza cuando un caso de uso proporciona una
funcionalidad adicional sobre otra ya existente. Se representa mediante
la expresión << extends >>
25
PROYECTO FIN DE CARRERA
Sistema
Añadir al
carrito
Realizar
Compra
usuario
Visa
Añadir stock
administrador
Figura 3.1: Ejemplo de Diagrama de Casos de Uso
3.1.1.0.6
Diagrama de Clases
Como ya se ha indicado, UML ha sido diseñado con objeto de proporcionar
soporte a las etapas de análisis y diseño en la ingenierı́a del software para el
paradigma de orientación a objetos. En este contexto se hace imprescindible
la representación de elementos propios de dicho paradigma, como son las
clases y objetos. El diagrama de clases del sistema está compuesto por
todas las clases que implementan el sistema, relacionadas entre sı́ mediante
relaciones. A continuación se detalla la notación gráfica de los citados
elementos:
Clases La notación gráfica para las clases consiste en una caja
separada en tres zonas verticales por dos lı́neas horizontales trasversales.
En la zona superior se indica el nombre de la clase, con letra cursiva en
caso de tratarse de una clase abstracta. En la zona central se indican los
atributos de la clase, uno por lı́nea, bajo el siguiente formato:
visibilidad nombre : tipo = valor inicial
donde la visibilidad se representa con el sı́mbolo ‘+’ si es privada, el sı́mbolo
‘-’ si es pública y el sı́mbolo ‘#’ si es protegida. En la última zona se
indicarán los métodos de la clase. Éstos siguen una sintaxis similar al caso
anterior:
visibilidad nombre (lista parametros) : tipo devuelto
26
CAPÍTULO 3. TECNOLOGÍAS, LENGUAJES Y ESTÁNDARES EMPLEADOS
En ocasiones, y dependiendo del elemento gráfico concreto en el que se esté
incluyendo la representación en notación gráfica de la clase, es posible que
no se quiera indicar algunas de las zonas, con el objetivo de facilitar la
comprensión gráfica del diagrama. En estos casos se dejará dicha zona en
blanco.
Objetos Los objetos se representan de forma idéntica a la clase de la
que son instancia, con la excepción de que el nombre del objeto se indica
delante del nombre de la clase, ambos separados por el sı́mbolo ‘:’. En
caso de que se quiera representar una instancia cualquiera de una clase,
sin necesidad de asignar un nombre a dicho objeto, no se escribirá ningún
nombre para el objeto, quedando por tanto simplemente el nombre de la
clase precedido del sı́mbolo ‘:’.
Relaciones Las diferentes
representaciones gráficas:
relaciones
tienen
las
siguientes
• Asociación: se representa mediante una lı́nea continua. Opcionalmente
se puede etiquetar con el nombre de la relación, la cardinalidad,
la dirección de la misma y los roles que desempeñan los elementos
relacionados.
• Agregación: se representa mediante una lı́nea continua con un rombo
de fondo negro en el extremo de la entidad de la que parte la
agregación. Opcionalmente se puede indicar la cardinalidad.
• Composición: se representa mediante una lı́nea continua con un rombo
de fondo blanco en el extremo de la entidad de la que parte la
agregación. Opcionalmente se puede indicar la cardinalidad.
• Dependencia: se representa mediante una flecha de trazo discontinuo.
• Dependencia: se representa mediante una lı́nea continua terminada en
un triángulo de fondo blanco en la entidad padre.
A continuación se muestra un ejemplo simplificado de diagrama de clases.
27
PROYECTO FIN DE CARRERA
Carrito
+ usuario
- realizarCompra()
- validar()
*
*
*
Producto
+ categoría
+ precio
+ stock
incrementarStock(n)
ProductoFisico
+ codigoBarras
FachadaVentas
1 + formaPago
- realizarPago()
Almacen
1 + proveedores
+ stock
- realizarPedido(prod, cant)
*
Viaje
+ codigoReserva
+ fechaSalida
+ fechaLlegada
- contratarSeguro()
Evento
+ codigoReserva
+ fecha
Figura 3.2: Ejemplo de Diagrama de Clases de Diseño
3.1.1.0.7
Diagrama de Interacción entre Objetos
En este apartado se describe un tipo concreto de diagrama de interacción
entre objetos en forma de diagrama de secuencia. En este diagrama se
representan las diferentes operaciones que se realizan dentro del sistema
para lograr un objetivo determinado, como puede ser un caso de uso. En
este tipo de diagramas se representan los mensajes intercambiados entre los
diferentes objetos mediante lı́neas horizontales, mientas que el eje vertical
representa el transcurso del tiempo. En este caso los objetos se definen
mediante una caja cuyo contenido sigue el siguiente formato:
nombre objeto : nombre clase
en el caso de que no se quiera indicar el nombre del objeto, o que éste no
sea relevante, puede ser omitido.
La traza temporal queda indicada mediante una lı́nea discontinua
vertical sobre la que se indica el tiempo de vida de los objetos mediante cajas
de fondo blanco. Los mensajes entre los diferentes objetos se representan
utilizando flechas dirigidas etiquetadas con el nombre y parámetros de la
operación.
A continuación se muestra un ejemplo de diagrama de interacción entre
objetos para una tienda de comercio electrónico simplificada.
28
CAPÍTULO 3. TECNOLOGÍAS, LENGUAJES Y ESTÁNDARES EMPLEADOS
:Usuario
:Interfaz
:Carrito
:Producto
añadirACarrito(cant)
añadirACarrito(p,cant)
validarStock(cant)
Figura 3.3: Ejemplo de diagrama de Interacción entre Objetos
3.2
JAVA
Java es un lenguaje de programación orientado a objetos (Bobadilla, 2003)
que surgió a mediados de la década de los 90 -i.e la primera versión surgió en
1995 - desarrollado por Sun Microsystems, hoy en dı́a empresa subsidiaria
de Oracle. Se trata de un lenguaje cuya sintaxis está inspirada en C y
C++, que se fundamenta en la orientación a objetos. Su caracterı́stica más
destacable es que es posible ejecutar el código en la Máquina Virtual Java
(JVM, JAVA Virtual Machine). Existen implementaciones de la JVM para
muchas arquitecturas y sistemas operativos, lo que hace que el lenguaje
de programación JAVA sea extremadamente portable. Las principales
caracterı́sticas de JAVA se detallan a continuación:
• Orientación a objetos: la orientación a objetos en JAVA es obligatoria
ya que todo elemento está contenido en una clase o interfaz. A pesar
de esta restricción, no es complicado utilizar un paradigma imperativo
a la hora de programar en JAVA, y permite una gran facilidad a la
hora de realizar un desarrollo orientado a objetos.
• Independencia de la plataforma: como se ha comentado, el hecho
de poderse compilar el código para ser ejecutado en una JVM,
permite su portabilidad a cualquier entorno para el cual exista
una implementación de dicha máquina virtual. No obstante, JAVA
también puede ser compilado para una arquitectura y sistema
operativo en concreto, ganando ası́ en eficiencia aunque perdiendo en
portabilidad. Uno de los slogans de JAVA para resaltar su flexibilidad
respecto a la plataforma de ejecución es write once, run anyware, cuyo
significado es escribir una vez, ejecutar en cualquier sitio.
• Robustez y fiabilidad: la gran popularidad de JAVA ha sido a la
vez causa y consecuencia de su fiabilidad, ya que a lo largo de la
29
PROYECTO FIN DE CARRERA
evolución del lenguaje se han incorporado incrementalmente revisiones
que incorporaban cambios demandados por los usuarios del lenguaje.
• Concurrencia: Java ofrece soporte para programas concurrentes
con más de un hilo de ejecución. En combinación con el hecho
de que un programa Java puede ser ejecutado sobre diferentes
sistemas operativos, hace que se puedan implementar programas
concurrentes de forma transparente a las llamadas particulares del
sistema operativo, facilitando ası́ dicha implementación.
• Distribución: Java permite la comunicación mediante sockets,
implementados como objetos en su API, entre diferentes componentes
de un mismo sistema. Dichos componentes pueden sincronizar su
ejecución fácilmente a través de una red de datos.
• Web: Java es muy utilizado como backend de aplicaciones web, gracias
a la posibilidad de implementar fácilmente páginas web dinámicas,
conocidas como Java Server Pages (JSP) o, directamente, Servlets –
i.e. código JAVA que genera como salida código HTML listo para ser
presentado por un servidor web.
• Seguridad: las caracterı́sticas de JAVA que permiten el desarrollo de
sistemas distribuidos y aplicaciones web, junto con la gran popularidad
del lenguaje, han requerido un esfuerzo considerable en cuanto a
seguridad. Gracias a la constante evolución del lenguaje, Java ofrece
un nivel de seguridad confiable.
• API: la API básica de Java incorpora una gran variedad de clases
jerarquizadas mediante los mecanismos de herencia –i.e. tanto
herencia simple como de interfaz– que proporciona el paradigma de
programación orientado a objetos. Estas clases ofrecen una gran
comodidad a la hora de implementar un sistema, ya que abstraen de
la necesidad de crear una enorme variedad de estructuras de datos y
mecanismos de comunicación.
Dadas las capacidades que ofrece Java, puede verse más como un
conjunto de tecnologı́as que como un simple lenguaje de programación.
Actualmente, Java es utilizado, entre otros propósitos, para desarrollar
aplicaciones para dispositivos móviles, como teléfonos o tablets, creación
de aplicaciones web, Applets –i.e programas con interfaz propio embebidos
en páginas web– además de las aplicaciones tradicionales que se ejecutan en
un entorno local. Además, el hecho de que se pueda utilizar tal variedad
de tecnologı́as en un entorno homogéneo permite un ahorro significativo de
esfuerzo a la hora de crear sistemas grandes y complejos que requieran del
uso de varias de ellas.
30
CAPÍTULO 3. TECNOLOGÍAS, LENGUAJES Y ESTÁNDARES EMPLEADOS
3.3
PDF
Las Siglas PDF son el acrónimo de Portable Document Format (Adobe
Systems Incorporated, 2008b, 2009, 2008a), cuyo significado en castellano
es Formato de Documento Portable. Se trata de un stándar abierto para el
intercambio de documentos, cuya principal caracterı́stica es que proporciona
una representación única para los documentos de forma independiente de la
plataforma en que éstos se visualicen.
PDF fue creado por Adobe en 1993, basándose en PostScript (PS), una
tecnologı́a previa desarrollada por la misma compañı́a. En sus comienzos,
tuvo dificultades de aceptación debido principalmente a que no ofrecı́a
soporte para hiperenlaces y a que el software necesario para generar y
visualizar los documentos PDF no era gratuito. A lo largo del tiempo se
fueron incorporando nuevas caracterı́sticas y funcionalidades, y se ofreció el
visor de forma gratuita. Poco a poco PDF fue ganando popularidad hasta
llegar a convertirse en un estándar de facto. En el año 2008, la versión 1.7
de PDF fue adoptada como estándar oficial bajo el nombre ISO 32000-1.
Como ya se ha mencionado, la principal caracterı́stica de PDF es
su independencia de la plataforma. Este aspecto supone que un mismo
documento se visualiza exactamente igual con independencia del sistema
operativo, software del visor, y hardware empleados. El resultado es el
mismo, además, en la versión digital visualizada que en el formato impreso.
Para conseguir esta particularidad, el formato incluye todos los elementos
necesarios para la visualización –i.e imágenes tanto vectoriales como en mapa
de bits, texto y fuentes no estándares– en el mismo fichero, además de
toda la información necesaria para producir la maquetación final basándose
en un mapa de coordenadas cartesianas para cada página del documento.
Como curiosidad, obsérvese que es posible generar una misma visualización
a partir de diferentes maquetaciones –e.g. una palabra puede representarse
indicando que dicha palabra se encuentra en una posición, o indicando las
posiciones de cada una de sus letras.
3.4
Apache PDFBox
Apache PDFBox (The Apache Software Foundation, 2011c) es una librerı́a
para Java distribuı́da bajo licencia Apache License 2.0 (The Apache Software
Foundation, 2011a) que permite la manipulación de PDFs. Junto con la
API para tratar los documentos, se incluyen algunas utilidades de lı́nea de
comandos que sirven, además de herramientas, como ejemplos de uso de la
librerı́a. Las funcionalidades que ofrece esta librerı́a son:
• Extracción de texto
31
PROYECTO FIN DE CARRERA
• Unión de documentos
• Cifrado y descifrado de documentos
• Integración con el motor de búsqueda Lucene
• Uso de formularios
• creación de documentos
• creación de imágenes a partir de páginas de PDF
• impresión de documentos
3.5
XML
XML proviene del inglés Extensible Markup Language (Bray et al., 2011),
cuyo significado es Lenguaje de Marcas Extensible. Se trata de un conjunto
de reglas para la codificación de documentos de forma que puedan ser
interpretados de forma automática –i.e. por sistemas software. A pesar
de que su concepción se orientó a la representación de documentos, su
expresividad y flexibilidad lo han llevado a ser utilizado, además, para la
representación estructurada de datos, especialmente en los servicios web.
Respecto a la sintaxis, las reglas que llevan a un documento XML a estar
bien formado son simples y están referidas a la estructura del documento.
Al no introducir reglas sobre la semántica de los elementos, se consigue
una gran flexibilidad a la hora de representar información. Un documento
XML es una sucesión de caracteres y éste documento puede contener la gran
mayorı́a de los caracteres Unicode. Existen, no obstante, algunos caracteres
especiales, con significado propio, cuyo uso permite generar la estructura
del documento. Estos caracteres son los sı́mbolos de “menor que”, “mayor
que”, “ampersand”, “comillas simples” y “comillas dobles”. Estos últimos
caracteres pueden representarse dentro del documento mediante secuencias
especiales que son, respectivamente <, >, &, 0 y ”.
Desde un punto de vista léxico-sintáctico, la estructura de los
documentos XML debe respetar las siguientes normas:
• Las letras minúsculas y las letras mayúsculas representan caracteres
diferentes, ası́ como se consideran caracteres pertenecientes al
documento el retorno de carro, fin de lı́nea y demás secuencias de
control.
• El contenido del documento puede ser estructurado mediante
etiquetas. Las etiquetas están delimitadas por los caracteres < y >
como en < Etiqueta >
32
CAPÍTULO 3. TECNOLOGÍAS, LENGUAJES Y ESTÁNDARES EMPLEADOS
• Las etiquetas pueden contener atributos nombrados, bajo la sintaxis
nombre = “valor”. Se pueden utilizar comillas simples en lugar de las
comillas dobles.
• Todas las etiquetas deben estar cerradas, y su cierre debe encontrarse
antes del cierre de cualquier otra etiqueta cuya apertura tenga lugar
en un lugar anterior del documento. Se representa el cierre de una
etiqueta mediante la sintaxis < /Etiqueta >. Si un elemento no tiene
ningún contenido, puede ser representado mediante una única etiqueta
de la forma < Etiqueta/ >.
• Un documento XML debe comenzar por una cabecera identificativa,
que además aporta cierta información sobre el documento, como por
ejemplo la codificación de caracteres empleada. Un ejemplo de esta
cabecera es <?xml version = ”1.0” encoding = ”U T F − 8”? >.
Las reglas anteriormente expuestas hacen que un documento esté bien
formado. No obstante, esto no significa que el documento sea válido
respecto a una determinada representación de los elementos. Para conseguir
este objetivo es posible especificar un DTD (Document Type Definition, o
Definición de Tipo de Documento) o XML Schema (Esquema XML). En
este documento se especifican las etiquetas permitidas y sus relaciones.
3.5.1
Parsers XML
Dado que un documento XML ofrece el acceso estructurado a la información
que contiene, es de interés detallar cómo se realiza realmente dicho acceso.
Un parser o analizador de un documento XML es una herramienta software
que permite la lectura, generación, manipulación y validación de documentos
XML. Los analizadores pueden ser agrupados en diferentes categorı́as en
función de cómo recorren el documento.
• DOM. (W3C) Acrónimo de Document Object Model, cuyo significado
es Modelo de Objeto de Documento. Este analizador mantiene una
representación del documento en forma de árbol de etiquetas. Su
principal ventaja es que ofrece una visión en forma de estructura
de datos del contenido del documento y puede resultar útil cuando
se requiere acceder a partes muy distantes del documento. Como
desventaja, para poder generar el árbol jerárquico es necesario procesar
por adelantado todo el documento, lo que puede suponer grandes
consumos de memoria en documentos grandes.
• SAX. (Megginson, 2011) Este tipo de analizador procesa el documento
leyendo la tira de caracteres que lo forma y generando eventos –e.g
se ha abierto o cerrado una etiqueta, se ha leı́do contenido, se ha
33
PROYECTO FIN DE CARRERA
leı́do un atributo con un nombre y un valor, etc. Capturando dichos
eventos es posible procesar el documento sin grandes consumos de
memoria, y además no es necesario realizar un gran procesamiento
para leer el texto del documento y crear los eventos, por lo que
es muy rápido. Es especialmente útil cuando se quieren procesar
grandes documentos de forma completa. Como inconveniente de este
tipo de analizadores, en ciertas ocasiones la interpretación no es la
misma en función de la zona del documento en que se encuentren
–e.g. puede quererse tratar de forma diferente el contenido de una
etiqueta cuyo nombre sea tı́tulo si se están procesando libros que si
se están procesando pelı́culas, información que habrá que almacenar
temporalmente desde etiquetas superiores. Este problema puede
requerir del mantenimiento de complejas estructuras de datos que,
al final, suponen una representación paralela de la estructura del
documento.
• STAX (Fry et al., 2011) En un intento de aunar las ventajas de DOM
y SAX evitando sus desventajas, se creó STAX. El funcionamiento es
similar a SAX en cuanto a que se procesa el contenido del documento
a partir de la sucesión de caracteres que lo compone, salvo que en el
caso de STAX, en lugar de generar siempre los mismos eventos, esta
lectura se hace mediante demanda. Ası́, sobre el ejemplo anterior,
el procedimiento encargado de leer los tı́tulos de pelı́culas no será el
mismo que el encargado de leer los tı́tulos de libros, y se les podrá dar
tratamientos diferenciados de forma sencilla, ya que la estructura del
documento queda implı́cita en su lectura. Este analizador tiene una
eficiencia cercana a la ofrecida por SAX y resulta de una comodidad
similar a la de DOM. No obstante, no es recomendable a la hora de
tratar con documentos con estructuras muy poco definidas o ambiguas.
3.6
Bases de Datos Relacionales
Una base de datos es un sistema sotware diseñado para la organización, el
almacenamiento y la recuperación de grandes cantidades de datos de forma
sencilla. Desde el punto de vista de la arquitectura de una base de datos, se
pueden distinguir tres niveles:
• Externo: este nivel define cómo se estructura la información desde un
punto de vista externo al sistema. Se pueden ofrecer diferentes formas
de ver la información a este nivel.
• Conceptual: en este nivel se proporcionan los mecanismos que
permiten relacionar las diferentes vistas del nivel externo con el modelo
implementado en el nivel interno. Si bien se abstrae de los detalles del
34
CAPÍTULO 3. TECNOLOGÍAS, LENGUAJES Y ESTÁNDARES EMPLEADOS
nivel interno, permite una visión homogénea respecto de las vistas
ofrecidas en el nivel externo.
• Interno: este nivel define el almacenamiento y procesamiento real de
la información a nivel fı́sico. Es en este nivel donde se focalizan los
esfuerzos relativos al rendimiento de la base de datos.
3.6.1
El Modelo Relacional
El modelo relacional (Codd, 1983) es el modelo predominante en la
actualidad y ha sido elegido para el almacenamiento de información en el
presente Trabajo de Fin de Carrera. La base de este modelo radica en
el almacenamiento tanto de datos como de sus relaciones. Una relación,
en este contexto, es una estructura en forma de tabla bidimensional que
relaciona diferentes entradas o tuplas de información –i.e. filas de la tabla–
con cada uno de los atributos o campos que describen dicha entrada –i.e.
columnas de la tabla. El modelo relacional tiene una base teórica basada
en la Teorı́a de Conjuntos y la Lógica de Primer Orden. Este fundamento
permite garantizar la integridad de los datos almacenados mediante este
paradigma.
3.6.2
Modelado Entidad/Relación
El modelo Entidad/Relación fue desarrollado por Peter Chen (Chen, 1976).
Se trata de una notación gráfica –i.e. diagrama Entidad/Relación, o
diagrama E/R– para la representación de los objetos del mundo real y sus
interdependencias. Tiene una amplia aceptación y aplicación en la ingenierı́a
informática, en concreto, en el diseño de bases de datos relacionales.
Los diferentes elementos que son utilizados en este modelo son los
siguientes:
• Entidad: son los conceptos, clases de objetos o abstracciones que
queremos representar. Por ejemplo, una entidad serı́a la entidad
“Producto”, mientras que los productos concretos serı́an instancias
de dicha entidad.
• Relación: crea una asociación entre dos o más entidades. El nombre de
la relación aporta un valor semántico a dicha asociación, por lo que los
nombres de las relaciones suelen ser formas verbales, como por ejemplo,
“usuario compra producto” o “usuario visita producto”, donde las
relaciones “compra” y “visita” asocian las entidades “producto” y
“usuario”. Al número de entidades que quedan vinculadas mediante
una relación se le denomina Grado de la Relación y a las cantidades
35
PROYECTO FIN DE CARRERA
máximas y mı́nimas de instancias de cada entidad que se permite que
aparezcan en la relación se la denomina Cardinalidad de la Relación
• Atributo: son las caracterı́sticas de interés correspondientes tanto a
entidades como a relaciones. Las instancias de las entidades y de
las relaciones deberán asignar un valor a cada uno de sus atributos.
Ejemplos de atributo serı́an, para la entidad Producto, los atributos
identificador y precio. En el caso del primero de estos atributos, dado
que puede ser utilizado para diferenciar una instancia de otra, lleva el
nombre de identificador, mientras que a los atributos que no poseen
esta cualidad, como el segundo atributo del ejemplo, se denominan
descriptores. Además, para cada atributo se puede definir también el
tipo y rango de valores que puede tomar.
Respecto a las normas de la notación se incluye un ejemplo de un sencillo
diagrama de entidad relación. Como puede observarse, las entidades se
representan dentro de Rectángulos, los atriutos dentro de elipses y las
relaciones dentro de rombos. Las cardinalidades de la relación se indican
junto a las mismas.
id
nombre
Usuario
Fecha
id
Compra
Producto
Precio
N:M
contraseña
Categoría
Figura 3.4: Ejemplo de Diagrama E/R
3.6.3
MySQL
MySQL (MySQL AB, 2006) es un Sistema Gestor de Bases de Datos
(SGBBDD) relacionales que permite la ejecución de múltiples instancias
en diferentes hilos de ejecución, además de ser multiusuario. Pero quizás la
caracterı́stica más importante es que se encuentran disponibles versiones con
licencia de uso gratuita, estando parte del código bajo la licencia GNU GPL
(Free Software Foundation, Inc., 2011). Dada su gran popularidad, y que
en numerosas ocasiones se utiliza junto con otras herramientas gratuitas,
MySQL forma parte del paquete de productos software conocido como
LAMP, nombre formado por las primeras letras de todos los productos que
agrupa –i.e Linux, Apache HTTP Server, MySQL y PHP. En el presente
36
CAPÍTULO 3. TECNOLOGÍAS, LENGUAJES Y ESTÁNDARES EMPLEADOS
Trabajo de Fin de Carrera, no obstante, MySQL es el único componente de
LAMP utilizado.
3.7
3.7.1
GenBank y BioSQL
GenBank
GenBank es una base de datos de secuencias genéticas anotadas mantenida
por los Institunos Nacionales de Salud (NIH, del inglés National Institutes
of Health).
Se trata de una base de datos de acceso público que
pretende mantener actualizada todas las secuencias que han sido publicadas
abiertamente. Si bien existen procedimientos para el envı́o de secuencias,
en último término, son los cientı́ficos quienes envı́an las nuevas secuencias,
por lo que no existe una homogeneidad absoluta respecto de su contenido.
Es posible descargar la base de datos completa ası́ como las actualizaciones
a partir de una fecha determinada. No obstante, la base de datos no se
encuentra en un formato relacional, lo que puede resultar perjudicial para
cierto tipo de necesidades, como es el caso del presente Trabajo de Fin
de Carrera. Para solventar a este inconveniente se ha recurrido al uso de
BioSQL, descrito en la próxima sub-sección.
3.7.2
BioSQL
BioSQL es un modelo relacional que agrupa secuencias, caracterı́sticas,
anotaciones, una taxonomı́a y ontologı́as sobre datos genéticos. Fue
concebida por Ewan Birney en 2001 como un modelo relacional de GenBank
y desde entonces este proyecto ha colaborado con los proyectos BioPerl,
BioPython, BioJava y BioRuby, que proporcionan acceso a BioSQL desde
los lenguajes de programación que forman sus nombres.
3.8
BLAST
BLAST es el acrónimo de Basic Local Alignment Search Tool. Como
herramienta, se trata de la implementación del algoritmo que lleva el
mismo nombre y que permite la búsqueda de secuencias o subsecuencias
de amonoácidos sobre una base de datos o librerı́a de secuencias. Es
una herramienta de gran uso en el campo de la bioinformática, ya que a
pesar de que los resultados obtenidos mediante su uso son menos precisos
que utilizando algoritmos anteriores –e.g. Smith-Waterman– su ejecución
es considerablemente más rápida, paliando el problema del alto consumo
de recursos en la tarea de búsqueda de alineamientos en secuencias de
37
PROYECTO FIN DE CARRERA
aminoácidos. Además, BLAST está pensada para poder ejecutarse en
arquitecturas paralelas, reduciendo sustancialmente el tiempo de ejecución.
BLAST fue concebido e implementado por Stephen Altschul, Warren
Gish, y David Lipman, pertenecientes al National Center for Biotechnology
Information (NCBI), y por Webb Miller de la Pennsylvania State University
y Gene Myers de la University of Arizona.
Dado que BLAST utiliza heurı́sticas, sus resultados no son siempre el
mejor alineamiento posible, pero han sido aceptados como suficientemente
buenos en la gran mayorı́a de ocasiones. Para mejorar su efectividad, en
función de los tipos concretos de búsquedas que se vayan a realizar, es posible
modificar el comportamiento del algoritmo ajustando diferentes parámetros.
En la actualidad, BLAST no es sólo una herramienta, sino un conjunto
de ellas. Las dos más utilizadas son:
• blastn: dada una secuencia de ADN, devuelve las secuencias más
similares existentes en una base de datos de secuencias genéticas
proporcionada por el usuario.
• blastp: dada una consulta sobre una proteı́na, se devuelven las
secuencias de proteı́nas más similares de la base de datos de proteı́nas
que el usuario especifique.
3.9
Servlets y Apache Tomcat
En esta sección se agrupan las tecnologı́as de Servlets junto con el contenedor
web Apache Tomcat. Esta agrupación se ha realizado debido a que dicho
contenedor ha sido utilizado en este Trabajo de Fin de Carrera para alojar
los servicios web ofrecidos.
3.9.1
Servlets
Un Servlet es un módulo JAVA utilizado en un servidor para extender
sus capacidades, siendo ası́ capaz de aprovechar, mediante el Servlet, toda
la potencia del lenguaje JAVA y sus posibilidades de comunicación. Los
Servlets se utilizan generalmente para la petición de operaciones a través
de un interfaz WEB, generando como resultado una página a través de un
descriptor de salida donde escriben el código HTML correspondiente a la
página resultado. Para la construcción de dicha página respuesta es posible
que el Servlet sea autosuficiente o que recurra a otros objetos –i.e. dichos
objetos podrı́an ser también Servlets– para satisfacer la petición. En este
último modelo es donde encaja el uso de los Servlets en el presente Trabajo
de Fin de Carrera, donde los Servlets han sido utilizados como parte del
38
CAPÍTULO 3. TECNOLOGÍAS, LENGUAJES Y ESTÁNDARES EMPLEADOS
interfaz web del sistema de búsquedas, actuando como un punto de acceso
al sistema.
3.9.2
Apache Tomcat
Apache Tomcat, también conocido como Jakarta Tomcat o simplemente
Tomcat, es un contenedor web de código libre desarrollado por la Apache
Software Fundation. Tomcat implementa los mecanismos necesarios para
procesar Servlets de JAVA y Java Server Pages (JSP), además de las
peticiones normales de HTTP.
3.10
Lucene
Lucene (The Apache Software Foundation, 2011b) es una librerı́a de
recuperación de información de código libre para JAVA, respaldada por la
Apache Software Fundation y con licencia Apache Software License. Fue
creada originalmente por Doug Cutting e incorporada a la Apache Software
Foundation en Septiembre de 2001.
Se trata de una potente librerı́a que permite incorporar capacidades
de búsqueda a cualquier aplicación (Hatcher et al., 2010). A pesar de su
aparente simplicidad, Lucene implementa internamente una interpretación
del Modelo Espacio-Vectorial (MEV) de una forma extraordinariamente
eficiente, lo que la ha llevado a gozar de una gran popularidad.
Las caracterı́sticas más destacables de Lucene son:
• Indización de alto rendimiento: Lucene es capaz de indexar
rápidamente con un bajo consumo de memoria, tanto de forma
completa como incremental, reduciendo el tamaño del ı́ndice a escalas
de una quinta a una tercera parte del tamaño del texto original.
• Algoritmos avanzados de búsqueda: en el paquete estándar de Lucen
se encuentran disponibles diversos algoritmos y funcionalidades de
búsqueda –e.g. búsqueda ranqueada, soporte para diversos tipos de
consultas, búsqueda por fechas, etc – cuya implementación tiene muy
en cuenta la eficiencia de los mismos.
• Multiplataforma: dado que Lucene ha sido escrito utilizando
el lenguaje de programación JAVA, aprovecha las caracterı́sticas
multiplataforma de este lenguaje.
39
PROYECTO FIN DE CARRERA
40
Capı́tulo 4
ANÁLISIS DEL SISTEMA
4.1
4.1.1
ESPECIFICACIÓN
SOFTWARE
DE
REQUISITOS
Introducción
Esta sección recoge la Especificación de Requisitos Software (ERS) del
sistema “Sistema para la extracción, anotación y recuperación de secuencias
genéticas presentes en la literatura cientı́fica” siguiendo el estándar “IEEE
830-1998 Recommended Practice for Software Requeriments Specifications”
(Software Engineering Standards Committee of the IEEE Computer Society)
A lo largo del diseño se harán numerosas referencias a los requisitos
establecidos en este capı́tulo. Para la correcta identificación de los mismos,
los requisitos serán numerados y se utilizará la siguiente expresión para
referirse a un requisito determinado cuyo número sea, por ejemplo, N:
REQ#N.
4.1.1.1
Propósito
Mediante la ERS se establecerá una lista que recogerá, de forma completa
y exhaustiva, los requisitos software –i.e. restricciones, funcionalidades y
caracterı́sticas que determinan el sistema final– que deberá satisfacer el
sistema. Dicha ERS está dirigida a todo aquel que quiera conocer las
caracterı́sticas del sistema, resultando especialmente útil a desarrolladores
que modifiquen yo amplı́en el mismo. Además, permitirá a los usuarios
conocer de forma detallada las funcionalidades del sistema.
4.1.1.2
Ámbito del sistema
El sistema “Sistema para la extracción, anotación y recuperación de
secuencias genéticas presentes en la literatura cientı́fica” ha sido planteado
41
PROYECTO FIN DE CARRERA
por expertos bioinformáticos con el objetivo de facilitar la tarea de
extracción y anotación de secuencias genéticas presentes en la literatura
cientı́fica. En la actualidad, dichos expertos suelen analizar manualmente
la literatura para la extracción de secuencias genéticas como en el caso,
por ejemplo, de las secuencias conocidas como cebadores y sondas. Dicha
extracción manual conlleva, además, el mantenimiento de los datos extraı́dos
de los diferentes artı́culos analizados.
El futuro sistema se encargará de la extracción automática de las
secuencias genéticas presentes en la literatura, además de su almacenamiento
en un ı́ndice que permitirá realizar búsquedas a partir no sólo de información
relativa a secuencias genéticas sino también a información propia del
documento.
4.1.1.3
Definiciones, acrónimos y abreviaturas
Definiciones
Término
Definición
Administrador
Actor que realiza las labores
de instalación,
actualización y
mantenimiento del sistema
Usuario
Actor que usa los servicios ofrecidos
por el sistema
Artı́culo
Documento cientı́fico publicado con
carácter divulgativo
Secuencia
Secuencia genética
Ínidce de artı́culos y secuencias
Estructura
de
almacenamiento
utilizada
por
un
sistema
de
recuperación de información que
permite la recuperación de documentos
formados por artı́culos cientı́ficos y sus
secuencias genéticas asociadas
Nucleotide
Base de datos del NCBI con
documentos referidos a secuencias
genéticas e información sobre las
mismas
Lucene
API para el desarrollo de sistemas de
recuperación de información
42
CAPÍTULO 4. ANÁLISIS DEL SISTEMA
Acrónimos
Acrónimo
Definición
API
Application Programming Interface
ERS
Especificación de Requisitos Software
IEEE
Institute of Electrical and Electronics Engineers
BLAST
Basic Local Aligment Tool
NCBI
National Center for Biotecnology Information
Abreviaturas
Abreviatura
Std
4.1.1.4
Definición
Stándar
Referencias
IEEE Recommended Practice for Software Requirements Specifications
(IEEE Std. 830-1998).
4.1.1.5
Visión General del Documento ERS
Este documento de ERS contiene, además de la introducción a la que esta
sección pertenece, dos secciones más: “Descripción General” y “Requisitos
Especı́ficos”.
El objetivo de la sección “Introducción” es proporcionar una visión
general del documento ERS y establecer la estructura del mismo y sus
relaciones con el sistema. La sección “Descripción General” proporciona un
acercamiento global al sistema, indicándose sus principales funcionalidades,
datos que maneja y factores que influyen en el desarrollo. La sección
“Requisitos especı́ficos” recoge de forma exhaustiva los requisitos que deberá
satisfacer el sistema, tanto funcionales como no funcionales.
4.1.2
Descripción General
Esta sección recoge una visión global del sistema, estableciendo ası́ el marco
o contexto que ubicará los requisitos expuestos más adelante. Se trata, por
tanto, de una aproximación de alto nivel al sistema.
43
PROYECTO FIN DE CARRERA
4.1.2.1
Perspectiva del Producto
El sistema “Sistema de Identificación, Extracción y Recuperación de
Secuencias Genéticas a partir de la Literatura Cientı́fica” se compone a
partir de un conjunto de subsistemas que interactúan entre sı́ y con otras
herramientas externas. Para la anotación de secuencias se utilizarán las
herramienta externa BLAST, la cual requiere a su vez de bases de datos de
secuencias genéticas en un formato especı́fico, y la base de datos Nucleotide
en formato relacional. Para la recuperación de secuencias a partir de la
literatura y para la consulta del ı́ndice de documentos, sin embargo, no se
ha identificado la necesidad de herramientas externas al sistema, si bien para
estos últimos casos se utilizará Lucene, que quedará integrado en el sistema
al ser utilizado a través de su API.
4.1.2.2
Funciones del producto
El sistema a desarrollar tiene por objeto (1)la extracción de secuencias
a partir de artı́culos cientı́ficos en varios formatos –i.e. PDF, PubMed
Central XML y texto plano– (2) permitir la anotación individual de los
mismos, (3) la generación de un ı́ndice masivo para PubMed Central y (4)
la realización de consultas sobre dicho ı́ndice. Se trata, por tanto, de un
conjunto de subsistemas cuyas funcionalidades especı́ficas quedan detalladas
a continuación:
Extracción automáticas de secuencias genéticas a partir de
artı́culos cientı́ficos
Esta funcionalidad será aplicable, en la primera versión del sistema, sólo a
aquellos artı́culos que se encuentren en formato PDF de las revistas BioMed
Central y Plos, en formato XML de PubMed Central y en texto plano.
El sistema deberá analizar el documento proporcionado por el usuario e
identificar en él las diferentes secuencias genéticas mencionadas. Además, el
sistema deberá identificar, dentro de las diferentes secciones del documento
(si el documento está estructurado en secciones o si el formato lo permite),
en qué sección o secciones han sido identificadas las secuencias.
Anotación automática de las secuencias extraı́das
El sistema deberá, para las secuencias genéticas identificadas en un
documento, anotar las mismas con los valores correspondientes al organismo
u organismos a los que ésta pertenezca. Dada la complejidad de esta
funcionalidad, y que la desambiguación de posibilidades deberá recaer
en un experto humano, el sistema anotará cada secuencia con diferentes
44
CAPÍTULO 4. ANÁLISIS DEL SISTEMA
posibilidades encontradas a las que asignará un valor de confianza.
Generación automática de un ı́ndice de documentos de PubMed
central que relacione los artı́culos cientı́ficos con las secuencias que
contienen
El sistema generará un ı́ndice a partir de una colección con todos los
documentos de PubMed Central. Además, todos los documentos serán
procesados para identificar las secuencias genéticas que contienen y se
almacenará la relación entre cada documento indizado con las secuencias
detectadas en él.
Consulta del ı́ndice de artı́culos y secuencias
El sistema permitirá diferentes tipos de consultas sobre el ı́ndice de artı́culos
y secuencias:
Búsqueda por texto: se recuperarán todos los documentos
relacionados con la consulta introducida por el usuario en el sentido clásico
de recuperación de información. Además, para cada documento recuperado,
se mostrarán las secuencias genéticas identificadas en el mismo.
Búsqueda por secuencia: se recuperarán todos los documentos en
los que se haya identificado alguna secuencia genética relacionada con la
consulta del usuario. Dichas secuencias concretas se mostrarán junto con el
documento.
Búsqueda por secuencia y texto: se recuperarán todos los
documentos relacionados con la consulta textual del usuario y que
contengan, además, secuencias relacionadas con la consulta de secuencia
realizada. Las secuencias relacionadas con esta última consulta se mostrarán
junto con los documentos
4.1.2.3
Caracterı́sticas del usuario
De cara al uso del sistema se han distinguido dos tipos de perfiles de usuario:
el administrador y los usuarios finales.
Administrador
La labor del administrador comienza con la instalación y configuración
del sistema. Para esta labor deberá facilitar al sistema los parámetros
45
PROYECTO FIN DE CARRERA
necesarios para el uso de las herramientas requeridas con las que el sistema
interactúa –i.e BLAST, con su base de datos de secuencias asociada, y
Nucleotide, en su formato relacional. También es tarea del administrador la
recopilación de los artı́culos de PubMed Central con los que el sistema creará
el ı́ndice de artı́culos y secuencias. Las tareas de mantenimiento son también
responsabilidad del administrador del sistema, esto incluye la actualización
de las herramientas y recursos utilizados por el sistema.
Debido a las tareas necesarias para el administrador del sistema, es
necesario que posea conocimientos sobre las herramientas que deberá
utilizar, incluyendo sistemas gestores de bases de datos.
Usuario final
El usuario final para el que el sistema está concebido son profesionales que
traten con artı́culos cientı́ficos prestando interés a las secuencias genéticas
contenidas en los mismos. El interfaz de uso del sistema en cuanto a la
extracción y anotación de secuencias genéticas requiere que dichos usuarios
sean capaces de tratar con ficheros estructurados de datos en formato XML,
mientras que el interfaz web para las consultas al ı́ndice de artı́culos y
secuencias no requiere ningún conocimiento particular.
4.1.2.4
Restricciones
Dependiendo del uso que se quiera dar al sistema se encontrarán más o
menos necesidades a la hora de poder interactuar con el mismo. Respecto
a la extracción y anotación de secuencias a partir de un artı́culo dado, será
necesario disponer de una JVM instalada, ya que el núcleo del sistema
se encuentra programado en JAVA. Para la anotación de secuencias será
necesario disponer de la herramienta BLAST junto con una base de datos de
secuencias para la misma, junto con la base de datos Nucleotide en formato
relacional. El administrador también necesitará una JVM para la generación
del ı́ndice de artı́culos y secuencias, a pesar que para las consultas realizadas
sobre la misma, a través del interfaz web, no será necesario más que un
navegador.
4.1.2.5
Suposiciones y dependencias
Susposiciones
Se supone que una vez establecidos, los requisitos del sistema serán
definitivos. Cualquier cambio en los mismos se realizará conforma a un
procedimiento controlado y documentado.
Se supone que el administrador proporcionará como colección de
46
CAPÍTULO 4. ANÁLISIS DEL SISTEMA
artı́culos cientı́ficos todos aquellos que componen PubMed Central, y que
actualizará dicha colección periódicamente para mantener ası́ el ı́ndice
actualizado.
Se supone que la base de datos que se utilizará conjuntamente con la
herramienta BLAST será consistente con la base de datos de Nucleotide en
formato relacional.
Dependencias
El sistema es un producto cerrado en cuanto a la implementación se refiere.
No obstante, el hecho de que utilice herramientas externas, como BLAST,
puede requerir que el sistema deba ser revisado en caso de utilizar futuras
versiones de dichas herramientas, con el objeto de garantizar su correcto
funcionamiento. Por otro lado, el hecho de que uno de los usos del
sistema sea la realización de consultas sobre un ı́ndice de artı́culos cientı́ficos
contenidos en PubMed Central requiere que dicho ı́ndice se encuentre
actualizado.
4.1.3
Requisitos Especı́ficos
En este apartado se identifican los diferentes requisitos funcionales que
deberá satisfacer el sistema. Todos los requisitos aquı́ expuestos son
esenciales, y permiten la trazabilidad de los mismos durante las diferentes
fases del ciclo de vida hasta las pruebas del sistema.
4.1.3.1
Requisitos de Interfaces Externos
En este apartado se establecen los requisitos que definen la comunicación
que todos los usuarios mantendrán con el sistema.
Interfaz de Usuario
Req#1: las consultas sobre el ı́ndice de secuencias se realizarán a
través de un interfaz web.
Req#2: la extracción de secuencias anotadas de un artı́culo se
realizará mediante lı́nea de comandos.
Req#3: la extracción de secuencias anotadas de un artı́culo se
mostrará al usuario mediante un archivo XML.
47
PROYECTO FIN DE CARRERA
Req#4: la generación del ı́ndice de artı́culos y secuencias se realizará
mediante lı́nea de comandos.
Interfaces Hardware
Req#5:
el sistema deberá funcionar en diferentes plataformas.
Interfaces Software
Req#6: el sistema deberá funcionar bajo diferentes sistemas
operativos. Al menos Windows y Linux.
Req#7: el sistema accederá a una base de datos en modelo relacional
de Nucleotide.
Req#8:
BLAST.
4.1.3.1.1
Interfaces de Comunicación
Re#q9:
HTTP.
4.1.3.2
el sistema utilizará mediante invocación la herramienta
el interfaz web del sistema requerirá el uso del protocolo
Requisitos Funcionales
Esta sección muestra aquellos requisitos que definen el comportamiento del
sistema en lo referente a su funcionalidad. Es decir, mediante los siguientes
requisitos es posible determinar todas las funcionalidades que el sistema
estará comprometido a satisfacer. Para una mejor comprensión de los
mismos, los requisitos pertenecientes a esta categorı́a se han dividido en
XXX subconjuntos en función de los objetivos del sistema que engloba las
funcionalidades que especifican.
Recuperación y Anotación de Secuencias
Req#10: el sistema permitirá tratar con documentos en formato PDF
para artı́culos originales de las revistas BioMed Central y PLOS.
Req#11: el sistema permitirá tratar con documentos en el formato
XML especı́fico de PubMed Central.
Req#12:
el sistema permitirá tratar con documentos en texto plano.
48
CAPÍTULO 4. ANÁLISIS DEL SISTEMA
Req#13: el sistema permitirá la extracción de las secuencias
encontradas en un artı́culo cientı́fico concreto que se encuentre en alguno
de los formatos aceptados.
Req#14: el sistema permitirá la anotación, además de la ercuperación
de secuencias, para un documento concreto. Se procporcionarán los
organismos y genes encontrados utilizando BLAST y la base de datos
Nucleotide, junto con un valor de confianza.
Req#15: en el caso de la anotación de secuencias en documentos cuyo
formato sea texto plano, se permitirá una menor fiabilidad de las anotaciones
indicadas.
Generación y Consulta de un Índice de Artı́culos y Secuencias
Req#16: el sistema permitirá la generación de un ı́ndice de artı́culos
y secuencias a partir de una colección de documentos en formato XML de
PubMed Central.
Req#17: el sistema permitirá consultar el ı́ndice mediante secuencias
genéticas completas o parciales. Las secuencias se podrán combinar
mediante los operadores lógicos AND y OR. Se deberán devolver las
secuencias relacionadas con la consulta junto con los identificadores
(PMCID) de los artı́culos a los que dichas secuencias pertenecen, y el
contexto en el que aparecen las secuencias.
Req#18: el sistema permitirá consultar el ı́ndice mediante texto libre.
Se devolverán los documentos mediante sus identificadores (PMCID) cuyo
contenido esté relacionado con la consulta, además de todas las secuencias
genéticas recuperadas a partir de dicho artı́culo, conjuntamente con el
contexto en el que aparecen en el texto. Al igual que en el requisito #req
14, se podrán combinar los términos de la consulta mediante los operadores
lógicos AND y OR.
Req#19: el sistema permitirá consultar el ı́ndice mediante secuencias
genéticas parciales o completas y texto libre. Se devolverán todos los
documentos relacionados con las secuencias y con el texto indicado. Sólo las
secuencias relacionadas con las secuencias de consulta se mostrarán, junto
con el contexto en el que aparecen. Cada consulta podrá contener cualquier
combinación de términos de búsqueda combinados mediante los operadores
AND y OR.
49
PROYECTO FIN DE CARRERA
4.1.3.3
Requisitos de Rendimiento
En este apartado se especifican los requisitos cuantificables que determinarán
si el funcionamiento del sistema es aceptable, desde el punto de vista del
tiempo de ejecución y el consumo de recursos.
Req#20: el sistema ejecutará en una máquina de perfil de usuario
normal, de gama alta.
Req#21: el tiempo que tarde el sistema en la extracción de secuencias
a partir de un artı́culo no debe hacer esperar al usuario.
Req#22: se permite que la anotación de secuencias tome un tiempo
más largo, del orden de minutos.
Req#23: se permite que la generación del ı́ndice de secuencias se
ejecute en background durante horas.
4.1.3.4
Atributos del sistema
Aquı́ se indican las restricciones impuestas por los estándares, plataformas
hardware y software, etc.
En esta sección se exponen los atributos de calidad del sistema. Debido a
los diferentes usos que se pueden dar al sistema y que existen diferentes tipos
de usuarios contemplados, será necesario garantizar que sólo los usuarios
autorizados tengan acceso a determinadas funcionalidades.
Seguridad
Todas las bases de datos utilizadas por el sistema sólo deben de poder ser
modificadas por el administrador. Para conseguir esta tarea, se han creado
usuarios especı́ficos en las mismas con permisos de modificación. Además,
el acceso a dichas bases de datos está restringido a la red local.
De forma similar, el ı́ndice de artı́culos y secuencias sólo puede ser
modificado por el administrador. Dado que el almacenamiento del ı́ndice
se realiza sobre el sistema de ficheros del servidor, será necesario iniciar
sesión en dicho servidor con un usuario que disponga de permisos para la
modificación de los archivos que componen el ı́ndice.
50
CAPÍTULO 4. ANÁLISIS DEL SISTEMA
Fiabilidad
En cuanto a la fiabilidad del sistema, es posible que falle en las
funcionalidades destinadas a la extracción y anotación de secuencias para
un artı́culo dado, pero dichos fallos no pueden en ningún caso provocar que
se detenga la extracción de secuencias de la colección de artı́culos durante el
proceso de generación del ı́ndice de artı́culos y secuencias. Además, ninguna
consulta a dicho ı́ndice puede provocar que el sistema deje de servir otras
peticiones de consulta.
Mantenimiento
Además de las tareas de mantenimiento especı́ficas del administrador en
lo referente a mantener actualizadas las bases de datos y la colección de
artı́culos que componen el ı́ndice de artı́culos y secuencias, el diseño del
sistema deberá permitir la fácil modificación del mismo para la inclusión de
otras funcionalidades futuras.
Portabilidad
El sistema deberá ser portable entre máquinas de diferentes plataformas
siempre que se encuentre disponible una implementación de la JVM y de la
herramienta BLAST.
4.2
CASOS DE USO DEL SISTEMA
Mediante los casos de uso se especifican los requisitos funcionales del sistema
desde el punto de vista de su uso por parte del usuario final. Se detallan las
operaciones que pueden realizar dichos usuarios y la respuesta del sistema
para satisfacerlas.
En primer lugar se describirán los actores del sistema, para más adelante
presentar de forma esquemática sus posibles interacciones con el sistema
(casos de uso). Por último, se detallará el comportamiento del sistema para
cada uno de los casos de uso presentados.
4.2.1
Actores
Además de los actores principales del sistema, que son el administrador y
el usuario final, existe un tipo especial de actores, denominados “de apoyo”
que a pesar de no ser humanos, proporcionan un servicio al sistema. Estos
actores de apoyo serán las herramientas BLAST, Nucleotide y el ı́ndice de
Lucene.
51
PROYECTO FIN DE CARRERA
4.2.1.1
Actores Principales
Administrador: El administrador será el encargado de instalar,
configurar y mantener el sistema. Para la instalación y configuración deberá
considerar la correcta instalación del software de apoyo necesario –e.g JRE,
servidor web, BLAST, Nucleotide, LUCENE. Respecto a la creación y
mantenimiento del ı́ndice de artı́culos, será el responsable de proporcionar
los ficheros XML que componen el ı́ndice, ası́ como de su actualización.
Usuario Final: Se entiende como usuario final al usuario que obtiene
servicios del sistema, ya sea para la recuperación y anotación de secuencias
a partir de un documento especı́fico, como para la consulta del ı́ndice de
artı́culos y secuencias.
4.2.1.2
Actores de Apoyo
BLAST: El servicio proporcionado por la herramienta BLAST sobre
la base de datos NT, será la identificación de información relativa a las
secuencias proporcionadas. En particular, se espera recuperar, para cada
secuencia proporcionada, la posición del alineamiento y el identificador del
documento que describe la secuencia genética en la que dicho alineamiento
ha sido detectado.
Nucleotide: La base de datos Nucleotide, en su formato relacional,
permite la obtención de información adicional sobre los alineamientos
identificados para las secuencias recuperadas en el contenido textual de
los artı́culos. Concretamente, se espera recuperar el nombre del organismo
vinculado al contenido genético detectado en todos los casos, y en caso de
existir información relativa a genes en la entrada, se obtendrán los nombres
de genes vinculados a la región especı́fica en la que se ha detectado un
alineamiento.
Índice de artı́culos y secuencias: El ı́ndice de artı́culos y secuencias
está compuesto por una capa software que permite la gestión de un ı́ndice
de Lucene –i.e creación, inserción, modificación y consulta.
4.2.2
Diagrama de Casos de Uso
El diagrama de casos de uso recoge de forma gráfica las interacciones entre
el sistema y los diferentes actores. Supone una gran herramienta para la
comprensión conceptual del funcionamiento global del sistema en lo que a
las relaciones con los actores se refiere, quedando ası́ una excelente impresión
52
CAPÍTULO 4. ANÁLISIS DEL SISTEMA
conceptual de los lı́mites del sistema. A continuación se presenta el diagrama
de casos de uso para el sistema.
Sistema
Anotar
Secuencias
de Artículo
BLAST
<<include>>
Extraer
Secuencias
de Texto
<<include>>
Administrador
Nucleotide
Generar
Índice
Consultar
índice por
texto y
secuencias
Consultar
índice por
texto y
secuencias
usuario
Consultar
índice por
texto y
secuencias
Figura 4.1: Diagrama de casos de uso del sistema
53
Índice de
artículos y
secuencias
PROYECTO FIN DE CARRERA
4.2.3
4.2.3.1
Casos de Uso
Anotar Secuencias de Artı́culo
Objetivo: Dado un artı́culo, obtener las secuencias contenidas en él
anotadas mediante valores de confianza con los posibles organismos y genes
de los que forma parte.
Nivel: Primario.
Tipo: Esencial.
Actor Principal: Usuario final.
Actores Secundarios: BLAST, Nucleotide
Precondiciones: –
Garantı́as de éxito: Se genera un fichero XML que contiene las
secuencias anotadas.
Referencias: Req#2, Req#3, Req#4, Req#7, Req#8, Req#10,
Req#11, Req#12, Req#13, Req#14, Req#15, Req#21, Req#22
Escenario principal:
1. El usuario invoca al sistema proporcionando un artı́culo cientı́fico,
indicando la ruta al fichero donde almacenar los resultados.
2. El sistema identifica las secuencias contenidas en el texto del artı́culo.
3. El sistema muestra por pantalla las secuencias detectadas.
4. El sistema utiliza BLAST para identificar alineamientos respecto a
cada secuencia detectada.
5. El sistema obtiene información adicional para los alineamientos
utilizando la base de datos Nucleotide en formato relacional.
6. El sistema anota las secuencias detectadas.
7. El sistema genera un documento XML con las secuencias anotadas en
la ruta especificada por el usuario.
Escenarios alternativos:
1. El formato del archivo proporcionado no es compatible.
1.1. Se muestra un error indicando el problema.
1.2. Se finaliza el caso de uso.
2. No se detecta ninguna secuencia.
54
CAPÍTULO 4. ANÁLISIS DEL SISTEMA
2.1. Se genera un fichero de resultados vacı́o.
2.2. Se finaliza el caso de uso.
3. BLAST no genera ningún resultado
3.1. El fichero de resultados no contendrá anotaciones.
3.2. Se finaliza el caso de uso.
4.2.3.2
Extraer Secuencias del Texto
Objetivo: a partir de un texto se extraen las secuencias genéticas
contenidas en él.
Nivel: Primario.
Tipo: Esencial.
Actor Principal: –
Actores Secundarios: –
Precondiciones: –
Garantı́as de éxito: Se devuelven las secuencias genéticas recuperadas.
Referencias: , Req#21, Req#22
Escenario principal:
1. El sistema recibe un texto.
2. El sistema identifica las secuencias contenidas en el texto.
3. El sistema devuelve todas las secuencias encontradas.
Escenarios alternativos: –
4.2.3.3
Generar Índice
Objetivo: Se genera un ı́ndice de artı́culos y secuencias que contiene el
texto de cada uno de los artı́culos junto con las secuencias contenidas en su
texto.
Nivel: Primario.
Tipo: Esencial.
Actor Principal: Administrador.
Actores Secundarios: Índice de artı́culos y secuencias
Precondiciones: Se ha proporcionado una colección de artı́culos en el
formato XML de PubMed Central.
Garantı́as de éxito: Se genera el ı́ndice de artı́culos y secuencias.
55
PROYECTO FIN DE CARRERA
Referencias: , Req#16, Req#23
Escenario principal:
1. El administrador invoca la herramienta de generación del ı́ndice
indicando la ruta al directorio que contiene los artı́culos en formato
XML de PubMed Central.
2. El sistema indiza los artı́culos, uno a uno.
3. El sistema finaliza indicando que la operación ha terminado
satisfactoriamente.
Escenarios alternativos:
2. Un artı́culo no se encuentra en el formato apropiado, o se produce un
error durante su lectura.
2.1. El sistema genera una referencia a dicho artı́culo en un fichero
de errores, y pasa al siguiente artı́culo.
4.2.3.4
Consultar Índice por Texto
Objetivo: Recuperar, para aquellos documentos cuyo contenido textual
esté relacionado con la consulta indicada, el identificador del documento,
un enlace al documento en PubMed Central, y las secuencias genéticas
recuperadas en dicho documento.
Nivel: Primario.
Tipo: Esencial.
Actor Principal: Usuario final.
Actores Secundarios: Índice de artı́culos y secuencias
Precondiciones: –
Garantı́as de éxito: Se devuelven los artı́culos y sus secuencias.
Referencias: , Req#18
Escenario principal:
1. El usuario envı́a una consulta al sistema, a través del interfaz web.
2. El sistema realiza la búsqueda para recuperar aquellos documentos
relacionados con la consulta, ordenados por relevancia respecto de la
consulta en orden decreciente.
3. El sistema extrae del ı́ndice, para cada documento recuperado, las
secuencias con tenidas en él y el identificador (PMCID) del documento.
56
CAPÍTULO 4. ANÁLISIS DEL SISTEMA
4. El sistema utilizará el PMCID del documento para generar el enlace
a PubMed Central.
5. El sistema muestra los datos.
Escenarios alternativos: –
4.2.3.5
Consultar Índice por Secuencias
Objetivo: Recuperar los documentos almacenados en el ı́ndice de artı́culos
y secuencias para los que se hayan detectado secuencias relacionadas con la
consulta especificada por el usuario.
Nivel: Primario.
Tipo: Esencial.
Actor Principal: Usuario final.
Actores Secundarios: Índice de artı́culos y secuencias
Precondiciones: –
Garantı́as de éxito: se devuelven los documentos que contienen alguna
secuencia relacionada con la consulta. Además, se mostrarán el enlace a
PubMed Central y todas las secuencias contenidas en el documento que
hayan provocado que el documento forme parte del conjunto de documentos
recuperados.
Referencias: Req#17
Escenario principal:
1. El usuario envı́a una consulta a través del interfaz web.
2. El sistema realiza la búsqueda para recuperar aquellos documentos
relacionados con la consulta, ordenados por relevancia respecto de
la consulta en orden decreciente. Sólo se busca en las secuencias
recuperadas a partir del documento.
3. El sistema extrae del ı́ndice, para cada documento recuperado, las
secuencias con tenidas en él y el identificador (PMCID) del documento.
4. El sistema utilizará el PMCID del documento para generar el enlace
a PubMed Central.
5. El sistema muestra los datos. En el caso de las secuencias genéticas,
muestra sólo las que encajan con la consulta.
Escenarios alternativos: –
57
PROYECTO FIN DE CARRERA
4.2.3.6
Consultar Índice por Texto y Secuencias
Objetivo: Recuperar los documentos almacenados en el ı́ndice de artı́culos
y secuencias para los que se hayan detectado secuencias relacionadas con la
consulta de secuencias especificada por el usuario, pero sólo para aquellos
documentos cuyo contenido textual esté relacionado con la consulta textual.
Nivel: Primario.
Tipo: Esencial.
Actor Principal: Usuario final.
Actores Secundarios: Índice de artı́culos y secuencias
Precondiciones: –
Garantı́as de éxito: Se devuelven los documentos que contienen
alguna secuencia relacionada con la consulta de secuencias, y cuyo texto
esté relacionado con la consulta textual. Se mostrarán el enlace a PubMed
Central y todas las secuencias contenidas en el documento que hayan
provocado que el documento forme parte del conjunto recuperado.
Referencias: Req#19
Escenario principal:
1. El usuario envı́a dos consultas: para la recuperación de secuencias y
otra para la recuperación de texto, a través del interfaz web.
2. El sistema realiza la búsqueda para recuperar aquellos documentos
relacionados con la consulta, ordenados por relevancia respecto de la
consulta en orden decreciente.
3. El sistema extrae del ı́ndice, para cada documento recuperado, las
secuencias con tenidas en él y el identificador (PMCID) del documento.
4. El sistema utilizará el PMCID del documento para generar el enlace
a PubMed Central.
5. El sistema muestra los datos. En el caso de las secuencias genéticas,
muestra sólo las que encajan con la consulta.
Escenarios alternativos: –
4.2.4
Diagramas de Secuencia del Sistema
Esta sección presenta los diagramas de secuencia del sistema, asociados a los
diferentes casos de uso. Nótese que en estos diagramas, el sistema es visto
como una caja negra, de forma que no se detallan las operaciones necesarias
para la consecución de los casos de uso desde una perspectiva interna, sino
que se muestran las interacciones necesarias entre el sistema y los diferentes
actores para la consecución de los diferentes casos de uso.
58
CAPÍTULO 4. ANÁLISIS DEL SISTEMA
4.2.4.1
Anotar Secuencias de Artı́culo
:Usuario
BLAST
:Sistema
Nucleotide
anotarArtículo(articulo)
recuperar secuencias(articulo)
detectarAlineamientos(sec)
obtenerInformacion(id)
[* más secuencias]
XML resultados
Figura 4.2: Diagrama de secuencia para el caso de uso “Anotar Secuencias
de Artı́culo”
4.2.4.2
Generar Índice de Artı́culos y Secuencias
:Administrador
:Sistema
Índice
generarIndice(ruta)
crearIndice()
añadirDocumento(doc)
[*más docuemntos]
Figura 4.3: Diagrama de secuencia para el caso de uso “Generar Índice de
artı́culos y secuencias”
59
PROYECTO FIN DE CARRERA
4.2.4.3
Consultar Índice por Texto
:Sistema
:Administrador
Índice
consultarPorTexto(query)
buscarTxt(query)
lista de documentos
obtenerInfoDoc(doc)
obtenerSecuencias(doc)
[*más documentos]
lista de docs y secuencias
Figura 4.4: Diagrama de secuencia para el caso de uso “Consultar ı́ndice
por texto”
4.2.4.4
Consultar Índice por Secuencias
:Administrador
:Sistema
Índice
consultarPorSecuencias(query)
buscarSeq(query)
lista de documentos
obtenerInfoDoc(doc)
obtenerSecuencias(doc)
[*más documentos]
lista de docs y secuencias
Figura 4.5: Diagrama de secuencia para el caso de uso “Consultar ı́ndice
por secuencias”
60
CAPÍTULO 4. ANÁLISIS DEL SISTEMA
4.2.4.5
Consultar Índice por Secuencias
:Administrador
Índice
:Sistema
consultarTxtSeq(query1, query2)
buscarTxt(query1)
buscarSeq(query2)
[*más documentos]
lista de documentos
obtenerInfoDoc(doc)
obtenerSecuencias(doc)
lista de docs y secuencias
Figura 4.6: Diagrama de secuencia para el caso de uso “Consultar ı́ndice
por texto y secuencias”
4.3
Contratos de las Operaciones del Sistema
A continuación se detalla la información referente a las operaciones del
sistema que aparecen en los diagramas de secuencia. Estas operaciones
muestran una visión general del comportamiento interno del sistema para
satisfacer los diferentes casos de uso.
4.3.1
Contrato CO1: anotarArticulo
Operación: anotarArticulo(articulo)
Responsabilidades: El sistema inicia el proceso para la extracción de
secuencias y anotación de las mismas a partir de un artı́culo.
Precondiciones: Ninguna.
PostCondiciones: El sistema creó un fichero XML cuyo contenido son
las secuencias anotadas presentes en articulo.
Referencias cruzadas: Caso de uso Extraer secuencias de Texto
Salidas: un fichero XML con las secuencias anotadas.
Excepciones: Si articulo no se encuentra en un formato apropiado, el
sistema mostrará un error.
61
PROYECTO FIN DE CARRERA
4.3.2
Contrato CO2: recuperarSecuencias
Operación: recuperarSecuencias(articulo)
Responsabilidades: El sistema identifica las secuencias genéticas
contenidas en el texto de articulo.
Precondiciones: Ninguna.
PostCondiciones: Se extrajeron las secuencias genéticas contenidas en
artı́culo junto con una referencia a las secciones donde fueron identificadas.
Referencias cruzadas: Caso de uso Extraer secuencias de Texto
Salidas: Una lista con las secuencias extraı́das.
Excepciones: Ninguna.
4.3.3
Contrato CO3: detectarAlineamientos
Operación: detectarAlineamientos(sec)
Responsabilidades: El sistema utiliza la herramienta BLAST para
identificar los mejores alineamientos de la secuencia sec con entradas de la
base de datos de secuencias.
Precondiciones: Ninguna.
PostCondiciones: El sistema encontró alineamientos para la secuencia
sec.
Referencias cruzadas: Caso de uso Extraer secuencias de Texto
Salidas: los identificadores de las entradas de la base de datos de
secuencias para los que la herramienta BLAST detectó un alineamiento,
conjuntamente con la posición dentro de la entrada donde se produjo el
alineamiento sec.
Excepciones: Ninguna.
4.3.4
Contrato CO4: obtenerInformacion
Operación: obtenerInformacion(id, pos)
Responsabilidades: El sistema obtiene de la base de datos Nucleotide
la información de organismo y genes asociados a un alineamiento producido
para un documento, y que está definido por un identificador id y una posición
dentro del documento pos
Precondiciones: Ninguna.
PostCondiciones: El sistema recuperó la información sobre organismo
y genes asociada al alineamiento.
Referencias cruzadas: Caso de uso Extraer secuencias de Texto
62
CAPÍTULO 4. ANÁLISIS DEL SISTEMA
Salidas: El nombre de organismo y una lista con los nombres de los
genes.
Excepciones: Ninguna.
4.3.5
Contrato CO5: anotarArticulo
Operación: anotarArticulo(articulo)
Responsabilidades: El sistema inicia el proceso para la extracción de
secuencias y anotación de las mismas a partir de un artı́culo.
Precondiciones: Ninguna.
PostCondiciones: El sistema creó un fichero XML cuyo contenido son
las secuencias anotadas presentes en articulo.
Referencias cruzadas: Caso de uso Extraer secuencias de Texto
Salidas: un fichero XML con las secuencias anotadas.
Excepciones: Si articulo no se encuentra en un formato apropiado, el
sistema mostrará un error.
4.3.6
Contrato CO6: generarIndice
Operación: generarIndice(ruta)
Responsabilidades: El sistema genera un ı́ndice de artı́culos y
secuencias para todos los artı́culos de PubMed Central.
Precondiciones: Se proporciona una ruta a un directorio que contiene
todos los artı́culos de PubMed Central.
PostCondiciones: Se creó el ı́ndice de artı́culos y secuencias.
Referencias cruzadas: Caso de uso Generar Índice
Salidas: un fichero XML con las secuencias anotadas.
Excepciones: Si articulo no se encuentra en un formato apropiado, el
sistema mostrará un error.
4.3.7
Contrato CO6: crearIndice
Operación: generarIndice()
Responsabilidades: El sistema genera un ı́ndice vacı́o utilizando la
API de Lucene.
Precondiciones: Ninguna.
PostCondiciones: se creó el ı́ndice vacı́o de artı́culos y secuencias.
Referencias cruzadas: Caso de uso Generar Índice
Salidas: Ninguna.
63
PROYECTO FIN DE CARRERA
Excepciones: Ninguna.
4.3.8
Contrato CO7: crearIndice
Operación: añadirDocumento(doc)
Responsabilidades: El sistema introduce el documento doc en el
ı́ndice.
Precondiciones: Ninguna.
PostCondiciones: se añadió el documento doc al ı́ndice de artı́culos y
secuencias junto con las secuencias detectadas en dicho documento.
Referencias cruzadas: Caso de uso Generar Índice
Salidas: Ninguna.
Excepciones: Ninguna.
4.3.9
Contrato CO8: consultarPorTexto
Operación: consultarPorTexto(query)
Responsabilidades: El sistema realizará una búsqueda utilizando la
consulta query en el ı́ndice.
Precondiciones: La consulta query es válida según la sintaxis de
consultas de Lucene.
PostCondiciones: Se recuperó una lista con los documentos relevantes
a la consulta, considerando sólo las secuencias contenidas en cada
documento, ordenada por relevancia.
Referencias cruzadas: Caso de uso Consultar Índice por Texto
Salidas: Lista de documentos almacenados en el ı́ndice ordenados por
relevancia respecto de la consulta query.
Excepciones: Si la consulta query no es válida según la sintaxis de
Lucene, se mostrará un error.
4.3.10
Contrato CO8: buscarTxt
Operación: buscarTxt(query)
Responsabilidades: el sistema busca la consulta query en el contenido
textual de los documentos del ı́ndice.
Precondiciones: Ninguna.
PostCondiciones: Se recuperó una lista con los identificadores de
documentos relevantes a la consulta, ordenada por relevancia.
Referencias cruzadas: Caso de uso Consultar Índice por Texto
64
CAPÍTULO 4. ANÁLISIS DEL SISTEMA
Salidas: Lista de identificadores documentos almacenados en el ı́ndice
ordenados por relevancia respecto de la consulta query.
Excepciones: Ninguna.
4.3.11
Contrato CO9: obtenerInfoDoc
Operación: obtenerInfoDoc(doc)
Responsabilidades: El sistema obtiene información sobre el tı́tulo y
el identificador de PubMed Central para el documento cuyo identificador
dentro del ı́ndice de artı́culos y secuencias es doc.
Precondiciones: Ninguna.
PostCondiciones: Se recuperaron el tı́tulo y el identificador de
PubMed Central del documento identificado como doc dentro del ı́ndice
de artı́culos y secuencias.
Referencias cruzadas: Casos de uso Consultar Índice por Texto,
Consultar Índice por Secuencias y Consultar Índice por Texto y Secuencias
Salidas: Tı́tulo e identificador de PubMed Central para el documento
cuyo identificador es doc en el ı́ndice de artı́culos y secuencias.
Excepciones: Ninguna.
4.3.12
Contrato C10: obtenerSecuencias
Operación: obtenerSecuencias(doc)
Responsabilidades:
El sistema obtiene información sobre las
secuencias genéticas asociadas para el documento cuyo identificador dentro
del ı́ndice de artı́culos y secuencias es doc.
Precondiciones: Ninguna.
PostCondiciones:
Se recuperaron las secuencias asociadas al
documento identificado como doc dentro del ı́ndice de artı́culos y secuencias.
Referencias cruzadas: Casos de uso Consultar Índice por Texto,
Consultar Índice por Secuencias y Consultar Índice por Texto y Secuencias
Salidas: Secuencias extraı́das por el sistema del documento cuyo
identificador es doc en el ı́ndice de artı́culos y secuencias.
Excepciones: Ninguna.
4.3.13
Contrato C11: consultarPorSecuencia
Operación: consultarPorSecuencia(query)
Responsabilidades: El sistema realizará una búsqueda utilizando la
consulta query en el ı́ndice.
65
PROYECTO FIN DE CARRERA
Precondiciones: La consulta query es válida según la sintaxis de
consultas de Lucene.
PostCondiciones: Se recuperó una lista con los documentos relevantes
a la consulta, considerando sólo las secuencias contenidas en cada
documento, ordenada por relevancia.
Referencias cruzadas: Caso de uso Consultar Índice por Secuencias
Salidas: Lista de documentos almacenados en el ı́ndice ordenados por
relevancia respecto de la consulta query, conjuntamente con las secuencias
genéticas contenidas en dicho documento que hayan provocado que dicho
documento fuese recuperado.
Excepciones: Si la consulta query no es válida según la sintaxis de
Lucene, se mostrará un error.
4.3.14
Contrato C12: consultarTxtSeq
Operación: consultarTxtSeq(query1, query2)
Responsabilidades: El sistema realizará una búsqueda utilizando la
consulta query1 sobre el contenido textual de los documentos y la consulta
query2 sobre las secuencias de los socumentos en el ı́ndice.
Precondiciones: Las consultas query1 y query2 son válidas según la
sintaxis de consultas de Lucene.
PostCondiciones: Se recuperó una lista con los documentos relevantes
simultáneamente a las consultas query1 y query2, considerando tanto el
contenido textual del documento para consulta query1 como las secuencias
asociadas a cada documento para la consulta query2, ordenada por
relevancia.
Referencias cruzadas: Caso de uso Consultar Índice por Texto y
Secuencias
Salidas: Lista de documentos almacenados en el ı́ndice ordenados por
relevancia respecto de la consulta query, conjuntamente con las secuencias
genéticas contenidas en dicho documento que hayan provocado que dicho
documento fuese recuperado.
Excepciones: Si alguna de las consultas query1 o query2 no son válidas
según la sintaxis de consultas de Lucene, se mostrará un error.
66
Capı́tulo 5
DISEÑO E
IMPLEMENTACIÓN DEL
SISTEMA
5.1
Introducción
En este capı́tulo se muestra el diseño y la implementación del sistema
utilizando los diagramas tı́picos de UML: diagramas de interacción entre
objetos y diagramas de clases. Por motivos de simplicidad, y dada la
particular estructura del sistema, éste se presentará separado en una serie
de módulos intercomunicados entre sı́ para cumplir con los objetivos del
sistema. En primer lugar, se discutirá esta estructuración en los diferentes
módulos describiendo las responsabilidades de los mismos y los mecanismos
de comunicación a utilizar para relacionarlos. Con este propósito se incluirá
un “Diagrama de Módulos” que si bien puede no corresponderse exactamente
con la notación de UML, se incluye con el objetivo de mejorar la comprensión
del sistema. A continuación, se detallará la estructura interna de cada uno
de los módulos explicando las clases más relevantes de cada uno. Con el
objetivo de facilitar la lectura y comprensión del diseño del sistema, se
omitirán algunas clases poco relevantes.
5.2
Módulos del Sistema
El diseño del sistema supone los siguientes módulos:
• Document: contendrá una representación del documento homogénea
de cara al resto del sistema.
Esta representación supone una
estructura en forma de árbol de secciones que representa un artı́culo
cientı́fico. Además, este módulo será el responsable de tratar con las
búsquedas de términos sobre el contenido textual del documento para
67
PROYECTO FIN DE CARRERA
la identificación de nombres de organismos y genes dados dentro del
mismo.
• Recognition: permitirá la detección de secuencias a partir de un texto
dado.
• BLAST: responsable de realizar la búsqueda de alineamientos
utilizando secuencias de ácidos nucleicos dadas y la herramienta
BLAST sobre la base de datos de secuencias especificada.
• NCBI: el módulo NCBI se responsabiliza de recuperar la información
detallada contenida en la base de datos “Nucleotide” a partir de las
entradas ofrecidas por la herramienta BLAST.
• ResultManager: se trata de un módulo de control que permite
organizar la información acumulada durante las diferentes fases del
proceso de reconocimiento y anotación de secuencias. Este módulo es
responsable de capturar los resultados generados durante las diferentes
fases y relacionarlos entre sı́ para ofrecer una salida coherente.
• Index: el módulo Index engloba las operaciones permitidas –i.e.
creación, mantenimiento y consulta– sobre el ı́ndice de artı́culos y
secuencias.
Document
Recognition
BLAST
NCBI
ResultManagement
Index
Figura 5.1: Módulos del Sistema
Como puede observarse en la figura ?? las dos lı́neas de ejecución
principales comparten los módulos Document y Recognition. La lı́nea
superior ofrece como resultado las secuencias anotadas para un documento
de entrada mientras que la lı́nea inferior permite la inclusión de un artı́culo
y las secuencias reconocidas en el contenido textual del mismo en el ı́ndice
de artı́culos y secuencias. Las consultas sobre dicho ı́ndice, que también son
casos de uso del sistema, utilizan exclusivamente el módulo Index.
La comunicación entre los módulos se ha realizado utilizando el “Patrón
Observador” (Larman, 2002). Utilizando este patrón y aplicándolo a la
estructuración en módulos mencionada, cada módulo permitirá, a través de
68
CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA
una clase que lo representa, que otros módulos se suscriban a ellos. De
esta forma, utilizando el mecanismo de subscripción, es posible hacer que
los módulos se observen –escuchen– unos a otros en el orden deseado. Si
bien algunas combinaciones en esta ordenación carecerı́an de sentido y el
sistema no funcionarı́a utilizándolas, este mecanismo permite una mayor
flexibilidad ofreciendo varias ventajas, no sólamente sobre el sistema actual
sino también sobre posibles evoluciones futuras. A continuación se describen
las principales ventajas:
• Inclusión de nuevas fases: debido al poco acoplamiento entre los
diferentes módulos, se puede colocar una fase intermedia que realice
operaciones adicionales sobre los resultados intermedios. Por ejemplo,
se podrı́a incorporar una nueva etapa de supervisión humana para
filtrar o mejorar dichos resultados intermedios.
• Reutilización: si bien existen dependencias entre fases, respetando las
restricciones sobre la entrada y salida de cada módulo, éste puede ser
reutilizado para otras tareas. Además, esta reutilización se puede dar
también sobre varios módulos sucesivos utilizándolos conjuntamente.
• Mantenimiento: la división en responsabilidades hace que sea más fácil
la localización y solución de posibles problemas de implementación del
sistema.
• Experimentación: si se desean probar nuevos enfoques para cualquiera
de las fases, sólo es necesario implementar este enfoque por separado
y realizar los experimentos utilizando la nueva composición. También
es posible realizar ejecuciones paralelas utilizando ramificaciones y ası́
poder contrastar resultados.
La figura 5.2 muestra un diagrama de secuencia que ilustra cómo se
realiza la creación y comunicación de los módulos a partir de un programa
principal que, en este caso, se corresponde con el caso de uso relativo a
la extracción y anotación de secuencias para un artı́culo dado en formato
PDF. Como puede observarse, el programa principal simplemente se encarga
de pedir la transformación del fichero de entrada en un objeto de la clase
:Document, para después crear y comunicar los diferentes módulos del
sistema. Una vez establecida la comunicación sólo será necesario iniciar
el proceso para que se lleve a cabo la ejecución. Los módulos irán generando
los eventos necesarios, que viajarán entre entre ellos a través de los canales
de comunicación establecidos, generándose en último término los resultados
deseados.
Como puede observarse en la figura (5.2) el concepto de módulo es una
abstracción de diseño sobre el modelo orientado a objetos que implementará
realmente el sistema. Para lograr esta abstracción, cada módulo contará
69
PROYECTO FIN DE CARRERA
:PrimerXtractor
doc:Document
rm:RecognitionManager
rfm:RuleFilteringManager
:PDFExtractor
bw:BlastWrapper
nw:NCBIWrapper
rm:ResultManager
create(path)
readWithTemplates(path)
create()
doc
create()
create()
create()
setDocument(doc)
create()
create(rm)
addListener(rm)
addListener(rfm)
addListener(bw)
addListener(nw)
addListener(rm)
flush()
Figura 5.2: Diagrama de Interacción entre Objetos: establecimiento de la
comunicación en PrimerXTractor.
con un objeto que desempeña el rol de representante, que son los objetos
visibles en el diagrama. Este representante se encargará en el momento de
su creación de crear a su vez los componentes –i.e. objetos– internos del
módulo necesarios para satisfacer las peticiones entrantes, que llegarán al
representante en forma de eventos provenientes de otros módulos. Además,
es este mismo objeto el encargado de gestionar las suscripciones que otros
módulos realicen sobre su módulo representado.
5.3
Mecanismo de Comunicación
Como ya ha sido mencionado, se ha utilizado un patrón observador para
realizar la comunicación entre los diferentes módulos. Cada representante
es una subclase de la superclase :Sender y, a la vez, implementa el interfaz
:Listener. Un objeto :Sender, o emisor, permite que se suscriban a él
cualquier número de objetos :Listener, redirigiendo a todos ellos los mensajes
o eventos salientes. A continuación se muestra utilizando un diagrama de
clases el diseño de este mecanismo utilizando únicamente las clases relevantes
para el mismo.
A partir del diagrama mostrado en la figura 5.3 puede observarse cómo
los representantes de los módulos se relacionan entre sı́ a través de la relación
existente entre la superclase :Sender y el interfaz :Listener. También se
observan ciertas dependencias directas entre algunas de las clases. Esto se
debe a que para la realización de determinadas operaciones simplifica la
70
CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA
Figura 5.3: Comunicación del sistema: Diagrama de Clases.
labor tener acceso directo entre módulos, en concreto, para indicar opciones
de configuración y realizar peticiones de operaciones adicionales sobre los
resultados generales de los mismos. Son estas dependencias las que hacen
que se trate de un sistema global conjunto con ventajas de flexibilidad en
lugar de varios sistemas completamente independientes.
5.4
Módulo Document
La principal misión de este módulo será permitir una representación
homogénea de los diferentes tipos de documentos que podrán ser utilizados
como entrada para el sistema. Atendiendo al planteamiento del problema, el
sistema deberá aceptar artı́culos cientı́ficos en formatos PDF y XML además
de en texto plano. Para los formatos PDF y XML, es necesario conservar la
estructuración jerárquica en secciones de los manuscritos. Además, este
módulo agrupa las clases necesarias para poder realizar las operaciones
necesarias sobre los documentos.
A
continuación
se
muestran
los
diagramas
de interacción correspondientes a las operaciones de envı́o del documento
y de búsqueda dentro del documento.
5.4.1
Diagramas de interacción entre objetos
A continuación se muestra el diagrama de interacción entre objetos para el
envı́o de documentos del sistema hacia módulos observadores. Por motivos
de simplicidad, se ha omitido el proceso de envı́o de mensajes ya descrito
en la sección anterior, de forma que los eventos llegan directamente al
71
PROYECTO FIN DE CARRERA
método onEvent del objeto destino. Los eventos mostrados en mayúsculas
se corresponden con mensajes de control.
:Document
flush()
:Section
:Row
w:Word
:Listener
onEvent( BEGIN DOCUMENT)
flush()
onEvent( BEGIN SECTION )
onEvent( BEGIN TITLE )
flush()
onEvent( BEGIN ROW )
flush()
onEvent( w )
[* más palabras]
onEvent( END ROW )
[* más filas del título]
onEvent( END TITLE )
onEvent( w )
onEvent( BEGIN CONTENT )
flush()
onEvent( BEGIN ROW )
flush()
onEvent( w )
[* más palabras]
onEvent( END ROW )
[* más secciones]
[* más filas del contenido]
onEvent( END DOCUMENT)
Figura 5.4: Diagrama de Interacción entre Objetos: procesamiento de un
documento
5.4.2
Diagrama de Clases
En esta sección se describen las clases más importantes del módulo
Document, presentadas en el diagrama de la figura 5.5. Un documento
está formado por una sucesión de secciones, que a su vez pueden contener
más secciones, formando una estructura de árbol. Cada sección contiene
un tı́tulo y un contenido, ambos formados por lı́neas de texto que, en
último término, están compuestas por palabras. Además, se dispone de
un sistema de búsqueda basado en autómatas finitos deterministas para
permitir realizar búsquedas en el texto contenido en el documento. Por
razones de flexibilidad, se ha decidido abstraer las operaciones necesarias del
buscador del documento en un interfaz, de forma que el buscador basado en
autómatas será una implementación de dicho interfaz.
72
CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA
Figura 5.5: Diagrama de Clases: módulo Document
5.4.3
Detalle de las clases más significativas
En este apartado se incluye la figura 5.6 que muestra las operaciones
y atributos de las clases más significativas de este módulo. Como se
puede observar, se incluyen los componentes estructurales necesarios en los
atributos de las clases para formar la estructura jerárquica del documento
explicada anteriormente. Además, Se incluyen operaciones de búsqueda
sobre el documento. Más en detalle sobre las operaciones de búsqueda, se
permite un modo de búsqueda inmediato y otro aplazado. La motivación de
incluir el modo aplazado se debe a motivos de eficiencia, ya que se permitirá
realizar un conjunto de búsqueda en una única iteración sobre el contenido
textual del documento.
5.5
Módulo Recognition
Este es el módulo encargado de la detección de secuencias. Una vez creada la
estructura de objetos y establecida la comunicación, el módulo quedará “a la
espera” de mensajes –de ahı́ que se nombren frecuentemente a estos mensajes
como eventos. De todos los mensajes posibles, el módulo sólo considerará los
mensajes que sean palabras para alimentar con ellos los detectores. También
se considerarán algunos mensajes de control, como los que indican cambios
de sección, ya que no es posible que una secuencia se encuentre contenida
entre dos secciones.
73
PROYECTO FIN DE CARRERA
Figura 5.6: Detalle de las Clases: módulo Document
Respecto a la comunicación, todos los mensajes que lleguen al módulo
serán a su vez retransmitidos a los observadores, junto con los mensajes
generados por el módulo de reconocimiento, aportando ası́ nuevo contenido
al flujo de eventos.
A nivel interno, el diseño de este módulo supone dos fases para la
detección de secuencias genéticas. En una primera fase se utilizarán una
serie de reconocedores en cascada para determinar palabras del texto que
forman secuencias genéticas. El uso de varios reconocedores en cascada
supondrá que cada reconocedor estará diseñado para reconocer secuencias
con diferentes niveles de confianza. El primer reconocedor será siempre el
más restrictivo mientras que el último será el más ambiguo, en el sentido
de que se tendrá menos seguridad de que la cadena de palabras de entrada
reconocida como una secuencia genética será efectivamente una secuencia
74
CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA
genética. En una segunda etapa se filtrarán las secuencias reconocidas
para rechazar aquellas que no sean secuencias genéticas, sino que estén
formadas por palabras del lenguaje natural. Además, durante este proceso
de filtrado se permitirá la modificación de las secuencias detectadas por
los reconocedores de la primera fase, ya que éstas pueden contener ruido o
ser la agrupación de varias secuencias. La implementación de esta última
fase se realizará mendiante un sistema experto que cuente con una base de
reglas heurı́sticas especı́ficas para el filtrado de las secuencias provenientes
de los tres recomendadores especı́ficos utilizados en la primera fase. Los
reconocedores y las reglas especı́ficas se encuentran detalladas en el Apéndice
B
Las dos fases internas de este módulo están comunicadas entre sı́
utilizando el mismo patrón que el resto del sistema. Se podrı́a haber dividido
este módulo en dos módulos más pequeños, pero dado que esta división es
conceptual, se ha decidido mantener ambas fases agrupadas dentro del marco
del mismo módulo por coherencia respecto a la funcionalidad.
5.5.1
Diagramas de Interacción entre Objetos
A continuación se muestran los diagramas de interacción correspondientes
a las dos fases explicadas con anterioridad. Estas dos fases se comunican
entre sı́ de forma de forma que el elemento “clean tokenns” que se envı́a a
sus objetos suscritos en la figura 5.7 será la entrada “event” de la figura 5.8.
Por motivos de simplicidad, las clases correspondientes a los
reconocedores concretos y las correspondientes a las reglas concretas que se
responsabilizarán, respectivamente, de las tareas de detección y filtrado de
las secuencias no aparecen en las figuras. Esto se debe a que dichas clases
se han abstraı́do en las respectivas superclases :Recognizer y :Rule. Esta
abstracción aporta mayor flexibilidad al sistema ya que se pueden utilizar
diferentes conjuntos de reconocedores y reglas para alterar el rendimiento.
Para un mayor nivel de detalle sobre los algoritmos de reconocimiento y
filtrado, se recomienda la lectura del Apéndice B
5.5.2
Diagramas de Clases
A
continuación
se
muestra
un
diagrama
de
clases
simplificado correspondiente al módulo Recognition. Nótese cómo no existe
una relación –acoplamiento– entre las clases correspondientes a las dos fases
descritas. Sobre este diseño, como ya ha sido señalado, faltarı́a incluir las
subclases correspondientes a los reconocedores y reglas especı́ficas.
En el diagrama pueden observarse también clases como :Token,
:DetectionEvent y :NucleotideChain. Estas clases sirven para utilizar
diferentes representaciones del texto de entrada con el objetivo de aportar
75
PROYECTO FIN DE CARRERA
:RecognitionManager
t:Token
:Recognizer
:Listener
onEvent(event)
[ event = BEGIN SECTION ]
resetAll()
resetAll()
[ event = Word ]
create(event)
onToken(t)
onToken(t)
generateSequence()
onDetected(tokens)
onEvent(clean_tokens)
Figura 5.7: Diagrama de Interacción entre Objetos: reconocimiento de
secuencias en el módulo Recognizer
:RuleFilteringManager
onEvent(event)
:Rule
:Listener
[ event = words ]
filter(words)
processFactBase()
addFact(fact)
removeFact(fact)
[* más hechos ]
onEvent(sequence)
Figura 5.8: Diagrama de Interacción entre Objetos: filtrado de secuencias
en el módulo Recognizer
funcionalidades concretas en función de las acciones necesarias a realizar
en cada etapa. :Token representa las palabras, sı́mbolos y eventos de
control que entran al módulo. Las secuencias detectadas forman una
lista de tokens y, tras el filtrado, se genera un objeto de la clase
:DetectionEvent que contendrá una secuencia representada en un objeto
de la clase :NucleotideChain.
76
CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA
Figura 5.9: Diagrama de Clases: módulo Recognition
5.5.3
Detalle de las clases más significativas
En la siguiente figura se pueden ver las cláses más significativas de este
módulo en detalle, mostrando tanto atributos como operaciones. Si bien las
clases que gestionan los algoritmos de reconocimiento y filtrado ya han sido
explicadas, respecto a las clases que representan las secuencias detectadas
debe notarse la diferencia entre :DetectionEvent y :NucleotideChain. La
primera contiene información adicional sobre la secuencia detectada, como
la sección en que fue detectada o el contexto –texto anterior y posterior
a la secuencia– en el que fue detectada, además del texto real –tal y como
aparece en el documento– que forma la secuencia. La clase NucleotideChain,
por el contrario, contiene información especı́fica de la secuencia permitiendo
operaciones sobre ella como la comparación de secuencias.
5.6
Módulo BLAST
La responsabilidad de este módulo es la ejecución del programa BLAST
sobre las secuencias detectadas en el módulo Recognition. Para ello, este
módulo permanece “a la escucha” de secuencias detectadas durante el
proceso de envı́o de documentos. Cada secuencia detectada es almacenada
temporalmente hasta que llegue el evento de control que indica que se
ha finalizado el envı́o del documento, momento en el cual se realiza la
ejecución de la herramienta BLAST para obtener alineamientos sobre todas
las secuencias detectadas en el documento.
La razón por la que se postpone la ejecución de BLAST es que se trata de
una herramienta que consume muchos recursos de la máquina y su ejecución
no es inmediata, sino que se mide en el orden de minutos 1 . Cada ejecución
1
TM
R
IntelCore
2 Quad Q6600 a 2.4 GHz con 2GB de memoria RAM
77
PROYECTO FIN DE CARRERA
Figura 5.10: Detalle de las Clases: módulo Recognition
de la herramienta supone la lectura de la base de datos de secuencias
establecida en las opciones de configuración del sistema, por lo que realizar
una ejecución por cada secuencia detectada en el momento de recibir dicha
secuencia supondrı́a un problema de rendimiento en el sistema inaceptable.
Las opciones de configuración del sistema se encuentran detalladas en el
Apéndice A
Dentro del módulo, y dado que es necesario recurrir a una aplicación
externa invocando su ejecución, el sistema debe adaptarse a las
caracterı́sticas de esta herramienta. Para ello, se genera un fichero de
entrada con las secuencias contenidas en el documento y se obtienen los
78
CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA
resultados de la ejecución de BLAST a través de un fichero de salida
en formato XML. Dicho fichero será parseado y los resultados obtenidos
enviados hacia las siguientes fases de ejecución utilizando el mecanismo de
comunicación descrito.
5.6.1
Diagramas de Interacción entre Objetos
En la figura 5.11 se muestra el diagrama de interacción entre objetos de este
módulo. Como puede observarse, la ejecución de la herramienta BLAST,
ejecutada a través de un objeto de la clase :BLASTExecution se realiza al
recibir el evento de control “END DOCUMENT”.
La comunicación con la herramienta BLAST se realiza mediante dos
ficheros de texto plano, utilizados para indicar la entrada y salida de la
herramienta. La ruta al fichero ejecutable de la herramienta BLAST y
la base de datos que utilizará la herramienta depende de la configuración
del sistema, mientras que los nombres de los ficheros de entrada y salida
se utilizarán añadiendo un sufijo al nombre del fichero que contendrá el
documento original.
El fichero de salida de la herramienta BLAST se encuentra en
formato XML, y la clase responsable de interpretar este fichero es
:BLASTResultParser. Un objeto de esta clase recibirá las secuencias de
entrada que se proporcionaron a la herramienta y devolverá como resultado
una tabla cuya clave serán las propias secuencias de entrada mientras que el
valor asociado será una lista de resultados. Cada uno de los resultados que
genera BLAST es, en realidad, una entrada para acceder a la base de datos de
Nucleotide, donde podrá obtenerse realmente la información necesaria para
anotar las secuencias. Este acceso a la información adicional se realizará en
la siguiente etapa del proceso, correspondiente al módulo NCBI.
5.6.2
Diagrama de Clases
En el diagrama de la figura 5.12 puede observarse la existencia de las clases
:BLASTEvent Y :BLASTResult. Estas clases tienen una responsabilidad
análoga a las ya mencionadas :DetectionEvent y :NucleotideChain.
5.6.3
Detalle de las Clases más significativas
En este apartado se muestra la figura 5.16 con las propiedades y métodos
de las clases que conforman este módulo.
79
PROYECTO FIN DE CARRERA
:BLASTWrapper
onEvent(event)
:BLASTExecution
:BLASTResultParser
:Listener
[ event = DetectionEvent ]
addSequence(event)
[ event = END DOCUMENT ]
searchBlast()
create(file_in, file_out)
run()
create(max_results)
parseDocument(file_out)
getResults()
results
onEvent(result)
[* más resultados ]
Figura 5.11: Diagrama de Interacción entre Objetos: módulo BLAST
Figura 5.12: Diagrama de Clases: módulo BLAST
5.7
Módulo NCBI
Una vez detectadas las secuencias y obtenidos los alineamientos de las
secuencias utilizando la herramienta BLAST, es necesario utilizar las
entradas de BLAST para poder ası́ acceder a la información contenida en
la base de datos de Nucleotide. Para realizar esta tarea, se ha utilizado
una versión local de la base de datos de GenBank utilizando BioSQL. No
obstante, de cara al diseño y la implementación del sistema, este recurso
será considerado únicamente como una base de datos relacional.
El objetivo de este módulo es obtener el nombre de organismo de las
80
CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA
Figura 5.13: Detalle de las Clases: módulo BLAST
entradas ofrecidas por la salida de BLAST, ası́ como los nombres de gen
correspondientes al alineamiento detectado. Los resultados proporcionados
por la herramienta BLAST contienen un identificador de GenBank, que
permite recuperar un documento contenido en la base de datos Nucleotide,
y una porción de secuencia dentro de ese documento, que queda determinada
por los valores superior e inferior que indican la posición en la que se
ha producido el alineamiento. El identificador, junto con los valores, son
utilizados para recuperar –cuando esté disponible– los nombres de gen. El
nombre de organismo tan sólo depende del identificador.
5.7.1
Diagrama de Interacción entre Objetos
En el diagrama de interacción de la figura 5.14 puede observarse cómo es
el funcionamiento general de este módulo ante la llegada de un evento. El
evento se espera que sea un objeto de la clase :BLASTResult y, en caso
contrario, al igual que el resto de módulos, simplemente se retransmite.
Ante un evento de dicha clase, se procede a la búsqueda inmediata de
la información contenida en la base de datos de Nucleotide sobre la entrada
especificada por el objeto que contiene el resultado de BLAST. En este caso
81
PROYECTO FIN DE CARRERA
no se posponen este tipo de acciones ya que se trata sı́mplemente de un
acceso a una base de datos relacional.
:NCBIDB
onEvent(event)
: NCBIQuery
: GenBankWrapper
r: NCBIResult
:Listener
[ event = BLASTResult ]
search(event)
create(event)
create()
shortQueryDev(gi, inf, sup)
data
create(data)
onEvent(r)
Figura 5.14: Diagrama de Interacción entre Objetos: módulo NCBI
5.7.2
Diagrama de Clases
Figura 5.15: Diagrama de Clases: módulo NCBI
En las explicaciones anteriores, respecto al modelo de comunicación, se habı́a
citado la clase :NCBIWrapper como representante del módulo actual. El
hecho de que esta clase no se encontrara recogida en la figura 5.14 se debe a
82
CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA
que la clase :NcbiDB es una subclase de dicho representante. Esta división
mediante el mecanismo de herencia se debe a la posibilidad de utilizar otros
mecanismos para el acceso a los datos de GenBank. Para poder modificar
el sistema en un futuro si fuese necesario, se ha propuesto este modelo de
forma que dichos cambios tengan un impacto mı́nimo sobre el sistema en
caso de realizarse.
5.7.3
Detalle de las Clases más significativas
La clase :NCBIQuery es similar, en cuanto a la información que maneja, a la
clase BLASTResult, no obstante, se ha decidido utilizar una clase diferente
por motivos de reusabilidad. Respecto a los resultados generados como
objetos de la clase :NCBIResult, en esta etapa simplemente contienen la
información recuperada por la base de datos Nucleotide, pero más adelante
permitirán ayudar en el proceso de búsqueda de los nombres de organismo
y nombres de gen en el texto del documento.
Figura 5.16: Detalle de las Clases: módulo NCBI
83
PROYECTO FIN DE CARRERA
5.8
Módulo ResultManagement
La última fase en el proceso de detección y anotación de secuencias consiste
en ordenar los resultados obtenidos parcialmente. Dado que el resto de
módulos anteriores han retransmitido todos los eventos de entrada además
de incorporar en el flujo de eventos los propios de cada uno de los respectivos
módulos, en esta última etapa se cuenta con toda la información necesaria
para finalizar la anotación de las secuencias detectadas y ordenar los
resultados para generar el fichero XML de salida.
5.8.1
Diagrama de Interacción entre Objetos
Como puede observarse en el diagrama de interacción, en este módulo se
utiliza el sistema de búsqueda ya mencionado anteriormente al describir la
clase :Document. Los resultados de acceder a la base de datos Nucleotide
ofrecen, en el mejor de los casos, diferentes alternativas de nombres de
organismo y nombre de gen posibles para cada secuencia detectada. Esto
se debe a que se eligieron en la fase correspondiente al módulo BLAST los
mejores resultados que ofrecı́a dicha herramienta.
:ResultManager
onEvent(event)
: SearchManager
: Document
[ event = NCBIResult ]
addNCBIResult(event)
addSearch(event)
addDelayedSearchTerm(term)
[* más términos ]
[ event = END NCBI ]
doSearch()
doSearch()
addResult(r)
[* más resultados ]
printResults()
Figura 5.17:
Diagrama
ResultManagement
de
Interacción
84
entre
Objetos:
módulo
CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA
Figura 5.18: Diagrama de Clases: módulo ResultManagement
5.8.2
Diagrama de Clases
Dado que las mostradas son las clases más relevantes, en este apartado
se muestran no sólo las relaciones entre las clases que forman el módulo,
sino también sus atributos y métodos. Respecto a la clase :SearchManager,
ésta es la responsable de alimentar al buscador del documento con los
términos necesarios para cada búsqueda. Como ya se indicó anteriormente,
los términos de búsqueda en cuanto a los nombres de organismo deberán
generarse para contemplar las formas más usuales de nombrar a un mismo
organismo.
5.9
Módulo Index
Este es el módulo asociado al subsistema de RI utilizado para las tareas
de creación del ı́ndice de artı́culos y secuencias ası́ como su recuperación.
Para el diseño de este módulo se cuenta con el apoyo de la librerı́a Lucene,
simplificando ası́ las tareas de creación, mantenimiento y consulta del ı́ndice.
Desde el punto de vista de las responsabilidades vinculadas a este
módulo, éstas son la de crear el ı́ndice y servir los resultados de las
consultas relacionadas con el mismo. Para la creación del ı́ndice es necesario
procesar todos los documentos con tenidos en PubMed Central. Dado
que dichos documentos se encuentran disponibles en formato XML, éste
ha sido el formato elegido para esta tarea. Si bien el módulo Index es
capaz de realizar su labor sı́mplemente recibiendo los eventos generados por
cualquier clase :Docuemnt, se ha elegido el formato XML ya que aporta
85
PROYECTO FIN DE CARRERA
más velocidad y precisión en la extracción del contenido textual de los
documentos conservando su estructura de secciones jerárquica.
En los diagramas mostrados en este capı́tulo, se ha utilizado una única
clase, nombrada como :Lucene, para representar el uso de la librerı́a del
mismo nombre. Se trata de una simplificación, ya que esta librerı́a ofrece
diferentes clases para el acceso a sus múltiples funcionalidades, pero dado
que el estudio de Lucene queda fuera el ámbito del presente Trabajo de Fin
de Carrera, se ha elegido esta representación con el objetivo de simplificar
la lectura y entendimiento de los diagramas. Por otro lado, se utilizará
también una segunda clase que representa un documento de Lucene. Para
evitar confusiones con la clase :Document del sistema, se nombrará a la clase
que representa los documentos de Lucene como :lucene.Document
5.9.1
Diagramas de Interacción entre Objetos
A continuación se muestran los diagramas de interacción entre objetos para
la creación del ı́ndice de artı́culos y secuencias. Por simplicidad y para
facilitar la interpretación de los mismos, el diagrama de interacción se
ha dividido en dos partes. La primera parte muestra el procesamiento
de los documentos XML extraı́dos de una base de datos para crear
añadir los diferentes campos que conformarán el documento de Lucene
al ı́ndice. Además, en esta primera parte se establece el mecanismo de
comunicación creando las suscripciones necesarias para recibir las secuencias
del documento en la propia clase :Indexer.
Las operaciones relacionadas con la API de LUCENE se han simplificado
al máximo. Por ejemplo, para añadir un campo a un documento de Lucene es
necesario crear un objeto para dicho campo y después añadirlo al documento.
Una vez más, por simplicidad, se han simplificado este tipo de mensajes
entre los objetos del sistema y la librerı́a Lucene. En el caso planteado en
el ejmeplo, utilizando un único mensaje –i.e. llamada a método– addField.
Como se ha indicado, los diagramas mostrados en esta sección se
corresponden exclusivamente con la creación del ı́ndice. Las consultas sobre
el ı́ndice no se muestran en diagramas debido a que se realizan directamente
sobre el ı́ndice generado, y se componen de consultas normales a dicho ı́ndice
utilizando la API provista.
Un último aspecto a destacar es que los artı́culos se extraen de una
base de datos. Esta base de datos ha sido generada independientemente a
partir de la colección de todos los artı́culos disponibles en PubMed Central.
Para el tratamiento de todos los manuscritos de forma secuencial se ha
decidido utilizar una estrategia basada en el mecanismo de herencia de
la programación orientada a objetos. Esta estrategia se explicará más
detalladamente con el diagrama de clases de este módulo.
86
CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA
:ChainExecution
: FullDatabaseXMLProcessor
i : Indexer
:lucene.Document
Document
rm:RecognitionManager
createIndex()
create()
create()
addXMLProcessor(i)
processFullDB()
processXML(id, xml)
create()
addField(pmcid)
addField(journal)
addField(title)
addField(authors)
addField(text)
create()
create()
addListener(rm)
addListener(this)
[* más documentos ]
flush()
Figura 5.19: Diagrama de Interacción entre Objetos: creación del ı́ndice en
el módulo Index (1/2)
:Indexer
onEvent(event)
: DetectionEvent
ld:lucene.Document
:Lucene
[ event = DetectionEvent ]
getDetectedElement()
[ event = END DOCUMENT ]
addField(sequences)
addField(sequences)
addDocument(ld)
processFullDB()
Figura 5.20: Diagrama de Interacción entre Objetos: creación del ı́ndice en
el módulo Index (2/2)
5.10
Diagrama de Clases
El principal aspecto a destacar del diagrama de clases es el ya citado
mecanismo general para el procesamiento secuencial de todos los artı́culos
contenidos en la base de datos. Para ello se hace uso de la clase
87
PROYECTO FIN DE CARRERA
Figura 5.21: Diagrama de Clases: módulo Index
:FullDatabaseXMLProcessor, que obtendrá de la base de datos el contenido
del fichero XML y el identificador PMCID de cada uno de los manuscritos e
invocará los métodos processXML y finishProcessing de todos los objetos
que sigan el interfaz :XMLProcessor que le hayan sido proporcionados.
De esta forma, cualquier objeto de una clase que implemente el interfaz
:XMLProcessor podrá procesar todos los documentos de la base de datos.
En este caso se trata de la clase Indexer, responsable de añadir al ı́ndice
de Lucene los documentos y sus secuencias estructurados en los siguientes
campos: (1) pmcid, (2) revista, (3) tı́tulo, (4) autores, (5) texto y
(6) secuencias.
88
Capı́tulo 6
EVALUACIÓN DEL
SISTEMA
6.1
Introducción
Este capı́tulo muestra los resultados de las pruebas realizadas para probar
el funcionamiento del sistema implementado. Para realizar las pruebas se
recurrió a un panel de expertos compuesto por tres biólogos moleculares
senior pertenecientes al Instituto de Salud Carlos III. Estos expertos crearon
un corpus de documentos para la realización de las pruebas compuesto de 297
artı́culos cientı́ficos publicados en (1) varias revistas de BMC –e.g. Virology
Journal, BMC Microbiology o BMC Molecular Biology– y (2) varias revistas
pertenecientes a PLoS –e.g. PLoS One, PLoS Negected Tropical Diseases o
PLoS Genetics. En total, entre los 297 artı́culos cientı́ficos que conforman
el courpus seleccionado para la evaluación del sistema, se encuentran 3999
secuencias genéticas del tipo primer o probe.
La selección de los artı́culos fue llevada a cavo por parte de los expertos
de forma manual. Los criterios para la selección de los artı́culos fue que
éstos contuviesen secuencias genéticas de tipo primers y probes. Se pidió
a los expertos que realizaran un análisis de los manuscritos del conjunto
de pruebas con objeto de identificar todas las secuencias de ADN válidas
contenidas en el texto de los artı́culos. Se les pidió, además, que especificaran
cuales de dichas secuencias de ADN se correspondı́a con secuencias del tipo
primers o probes. Tras el análisis, los expertos afirmaron que la cantidad
de secuencias genéticas no relacionadas con secuencias tipo primer o tipo
probe contenidas en los artı́culos seleccionados suponı́a menos del 2% de la
cantidad total de secuencias. Por esta razón, se ha supuesto que los artı́culos
cientı́ficos que recogen secuencias genéticas primers y probes raramente
contienen secuencias de ADN que no pertenezcan a dichos grupos.
89
PROYECTO FIN DE CARRERA
6.2
Evaluación
La forma de evaluar el sistema parte del corpus descrito en la introducción
de este capı́tulo y de la ayuda de los expertos mencionados. La evaluación
ha consistido en utilizar la implementación del sistema para la detección y
anotación de las secuencias contenidas en los manuscritos seleccionados, en
formato PDF, suministrando para cada manuscrito las secuencias detectadas
junto con su contexto –i.e. fragmentos del texto inmediatamente anterior
y posterior a la secuencia. Los resultados fueron interpretados y validados
manualmente por los expertos.
Por un lado, se han medido la precisión y exhaustividad de las secuencias
detectadas, atendiendo sólamente al hecho de reconocer correctamente las
secuencias genéticas. Sobre las secuencias detectadas, se ha revisado si las
anotaciones proporcionadas son correctas.
6.2.1
Detección de Secuencias
Del total de secuencias contenidas en el corpus de pruebas –3999– se
detectaron correctamente un total de 3830 secuencias. 169 secuencias no
fueron detectadas y se reconocieron 79 falsos positivos –i.e. palabra o
agrupación de palabras que no constituyen una secuencia genética. Esto
supone una exhaustividad –en inglés recall – del 95.77% y una precisión del
97.98%. La medida F, que relaciona precisión y exhaustividad, adquiere
un valor de 0.9686.
Figura 6.1: Secuencias Detectadas vs Secuencias no Detectadas
90
CAPÍTULO 6. EVALUACIÓN DEL SISTEMA
Figura 6.2: Secuencias Detectadas vs Falsos Positivos
Para el cálculo de los valores de exhaustividad y precisión se han utilizado
las siguientes fórmulas:
recall =
secuencias correctas
total secuencias
precision =
secuencias correctas
secuencias correctas + f alsos positivos
El significado de la medida de exhaustividad es la relación entre los
documentos recuperados correctamente respecto del total de secuencias que
contiene el conjunto de pruebas. Dicho de otro modo, muestra la cantidad
de secuencias bien detectadas. Se puede observar esta relación observando
la figura 6.1.
La precisión mide, por otro lado, la calidad de los resultados obtenidos
relacionando las secuencias bien detectadas respecto al total de secuencias
detectadas. En otras palabras, la exhaustividad representa cuántas de las
secuencias detectadas son realmente secuencias encontradas en los artı́culos.
Esta relación queda ilustrada en la figura 6.3
La medida-F muestra la relación entre las medias de precisión y de
exhaustividad.
F =2·
recall · precision
= 0.9686
recall + precision
91
PROYECTO FIN DE CARRERA
6.2.2
Anotación de secuencias
Para los datos de esta evaluación se han considerado las 3830 secuencias
correctamente detectadas, ya que los falsos positivos detectados no
produjeron resultados de alineamiento con ninguna secuencia existente al
utilizar la herramienta BLAST . En la detección del nombre de organismo
al que pertenecen estas secuencias, un total de 2936(76.66%) fueron
correctamente anotadas. 168(4.38%) fueron incorrectamente anotadas y
726(18.96%) fueron correctamente no anotadas. La razón de que sea
correcta la no anotación de estas últimas 726 secuencias se debe a que
se trata de secuencias genéticas de humano(671 secuencias) y de pollo(55
secuencias), mientras que la base de datos utilizada para la detección de
alineamientos con las secuencias detectadas sólo contenı́a información de
microorganismos.
De las 2936 secuencias correctamente anotadas respecto al nombre de
organismo, se encontró además información correcta sobre el nombre del
gen correspondiente para 1356(46.18%) secuencias.
Figura 6.3: Anotación de secuencias
6.3
Rendimiento
El proceso de anotación de secuencias requiere del uso de la herramienta
externa BLAST, y que esta herramienta consume una gran cantidad de
recursos, tanto de memoria como de computación. Si bien no existı́an
92
CAPÍTULO 6. EVALUACIÓN DEL SISTEMA
requisitos de rendimiento que necesiten ser evaluados, se ha realizado una
métrica de los tiempos miedos de ejecución tanto de la simple detección de
secuencias a partir de ficheros en formato PDF como de el proceso completo
de anotación, que supone, además del uso de la herramienta BLAST el acceso
a la base de datos Nucleotide. Con estas métricas, será posible determinar
mejoras de rendimiento en caso de modificación de los algoritmos internos
del sistema.
La máquina en la que se han ejecutado las pruebas cuenta con las
siguientes caracterı́sticas:
TM 2 Quad Q6600 a 2.4 GHz
R
• Procesador: IntelCore
• Memoria RAM: 2GB
• Sistema Operativo: Windows Vista Business 32 bits
Los tiempos de ejecución medios por artı́culo son de 397 milisegundos
para la detección de secuencias, de los cuales 322 milisegundos se invirtieron
en la extracción de los ficheros PDF y 75 en la anotación de secuencias. La
ejecución completa incluyendo la fase de anotación de las secuencias eleva el
tiempo de ejecución medio por artı́culo drásticamente hasta los 15 minutos.
93
PROYECTO FIN DE CARRERA
94
Capı́tulo 7
CONCLUSIONES Y
LÍNEAS FUTURAS
7.1
Conclusiones
El sistema desarrollado en este Proyecto de Fin de Carrera permite la
detección y anotación de secuencias genéticas en la literatura cientı́fica para
un manuscrito dado, aceptando varios formatos para dicho artı́culo, entre
ellos, PDF. Además, se han reutilizado las mismas técnicas de detección de
secuencias para crear un ı́ndice con todos los artı́culos de PubMed Central,
asociando a cada artı́culo las secuencias genéticas detectadas en él.
7.1.1
Tratamiento de PDF
Respecto al tratamiento de documentos PDF, se trata de un formato
raramente utilizado como fuente de información en la minerı́a de textos o la
extracción de información aplicadas al área de la biomedicina. Normalmente,
las herramientas de este área permiten como entrada texto plano o
estructurado utilizando lenguajes etiquetados como XML o HTML. Estas
restricciones son comprensibles, ya que es posible traducir el documento
PDF a dichos formatos utilizando herramientas externas. No obstante,
estas herramientas suelen ser caras y en general imprecisas, especialmente
cuando se trata de conservar la estructura de secciones y sub-secciones de
un documento maquetado en múltiples columnas.
En este Trabajo de Fin de Carrera se ha estudiado la posibilidad de
utilizar los documentos PDF como una entrada al sistema debido a que,
a raı́z del análisis del problema, los expertos consultados propusieron este
requisito de forma explı́cita argumentando que este formato es, de facto,
la forma de representación de documentos utilizada generalmente por los
investigadores.
La solución propuesta pasa por la creación de una plantilla para cada
95
PROYECTO FIN DE CARRERA
revista o grupo de revistas que compartan una misma maquetación. A
pesar de contar con el inconveniente del uso de la plantilla, los resultados
respecto a la calidad de la extracción del texto contenido en los documentos
son prometedores y, como se comentará en las lı́neas futuras, esta plantilla
podrı́a ser creada con facilidad utilizando una herramienta diseñada para
tal fin.
7.1.2
Detección de secuencias
La etapa principal del sistema es la detección de las secuencias genéticas de
tipo primer y probe contenidas en los manuscritos. El principal problema de
esta fase han sido la cantidad de sı́mbolos permitidos para la representación
de secuencias y la diversidad de formas de representación de las mismas en
los artı́culos. El método, además, se apoya en un diccionario de palabras
pertenecientes al idioma inglés compuestos por los sı́mbolos de nucleótidos
que forman las secuencias a reconocer, ası́ como en una lista de términos
técnicos formados también por estos sı́mbolos y que aparecen frecuentemente
junto a las secuencias.
El uso del diccionario de palabras formadas por sı́mbolos de nucleótidos
y la lista de términos especı́ficos supone una forma flexible de ampliación
del sistema en caso de resultar necesario ampliar dichos conjuntos. Esto se
debe a que dichos conjuntos se tratan como recursos externos al algoritmo
de filtrado de secuencias.
Dado que la creación de un algoritmo de detección que contemplara
todas las formas de representación posibles resultaba extraordinariamente
complicado, se recurrió al enfoque actual dividiendo el proceso en dos fases,
la primera centrada en la detección de cadenas de sı́mbolos candidatas a ser
una secuencia, y una última fase de refinamiento de las cadenas seleccionadas
por la fase anterior. Este enfoque permite una gran flexibilidad a la hora de
experimentar diferentes reconocedores y heurı́sticas de filtrado.
El método de detección de secuencias presenta unos altos valores de
precisión (97.98%) y exhaustividad (95.77%). Estos altos valores son la
clave del buen funcionamiento del sistema, ya que la etapa de detección
es la etapa en la que se basan tanto la anotación de secuencias como la
generación del ı́ndice de artı́culos y secuencias.
7.1.3
Anotación de Secuencias
El objetivo de esta etapa es el de anotar las secuencias detectadas con
posibles nombres de organismo y de gen, adiganando un valor de confianza a
cada anotación. Se trata de una etapa muy delicada del sistema en la que ha
sido requerido un gran esfuerzo en cuanto a adaptar el sistema para poder
acceder de la forma más eficiente posible a las bases de datos requeridas.
96
CAPÍTULO 7. CONCLUSIONES Y LÍNEAS FUTURAS
Por ejemplo, debido a motivos de rendimiento, se prefirió trabajar con una
copia local de la base de datos Nucleotide, en lugar de utilizar los servicios
web ofrecidos por el NCBI, dado que se requieren del orden de cientos de
consultas a dicha base de datos por cada artı́culo procesado y los tiempos de
ejecución utilizando servicios web resultaban inaceptables. Esta fase supone,
además, el uso de la herramienta BLAST, lo que obliga a una alta inversión
de recursos de computación. Es necesario destacar que, incluso tras las
optimizaciones de rendimiento realizadas, la ejecución de esta etapa eleva el
tiempo de ejecución medio por artı́culo a 15 minutos.
Los resultados obtenidos en las pruebas del sistema muestran que se ha
podido anotar correctamente las secuencias con el nombre del organismo
en un 83.29% de los casos. En el 15.45% de las ocasiones esta anotación
era simplemente imposible ya que las secuencias a anotar no pertenecı́an
a microorganismos, y las bases de datos utilizadas contenı́an información
exclusivamente de este tipo de organismos. Por lo tanto, se puede afirmar
que el método ha encontrado satisfactoriamente el nombre de organismo de
las secuencias en un alto porcentaje de las ocasiones. Respecto a los nombres
de gen, tan sólo se han podido encontrar en un 44.32% de las ocasiones en
las que se identificó el nombre de organismo. El hecho de que este porcentaje
de anotación con nombres de genes sea bajo se debe, según los expertos, a
que la información que se pretende recuperar puede no estar contenida en
las bases de datos e, incluso, no ser conocida todavı́a.
7.1.4
Generación de un Índice de Artı́culos y Secuencias
Utilizando las etapas ya descritas, se han reutilizado la etapa de extracción
del contenido textual de los documentos y la etapa de detección de secuencias
para asociar a cada artı́culo las secuencias contenidas en él. En el
momento de la creación del ı́ndice, la cantidad de artı́culos descargables
de PubMedCentral era de 176672. Dado que se disponı́a de una versión de
cada artı́culo en formato XML, se ha utilizado este formato de representación
dado que reduce los tiempos de ejecución respecto al tratamiento de artı́culos
en PDF.
El uso de la librerı́a Lucene ha permitido que tanto la creación del ı́ndice
como las consultas sobre el mismo se realicen de forma eficiente y rápida.
A pesar de ello, dada la gran cantidad de artı́culos, la creación del ı́ndice
supuso un tiempo de ejecución de, aproximadamente, 10 horas. No obstante,
las consultas al ı́ndice permiten realizar búsquedas en tiempo real a través
de la interfaz web del sistema.
97
PROYECTO FIN DE CARRERA
7.2
Lı́neas Futuras
A pesar de que el sistema es completamente funcional y se ha probado que
ofrece unos resultados muy prometedores, durante el desarrollo del mismo
se ha tomado nota de ideas que pueden mejorar la funcionalidad ofrecida,
tanto a nivel de mejora de los resultados como de rendimiento. Además,
algunos de los componentes del sistema, como ya se ha visto, son fácilmente
exportables para su uso en otros ámbitos, como es el caso de la extracción
estructurada del contenido de los artı́culos cientı́ficos en formato PDF. A
continuación se exponen las principales lı́neas de mejora del sistema y sus
componentes ofreciendo una estimación de la dificultad que suponen y, en
ocasiones, ideas concretas de aplicación.
7.2.1
Extracción Estructurada de Ficheros PDF
El principal inconveniente del método desarrollado en este Trabajo de Fin
de Carrera es la necesidad de utilizar una plantilla para cada conjunto
de documentos que compartan una maquetación. Si bien este enfoque ha
funcionado bien, la generación de las plantillas se ha realizado de forma
manual inspeccionando la estructura interna de los documentos, y esta
labor, si bien no es especialmente complicada, queda fuera del ámbito de
cuestiones de las que deberı́a responsabilizarse un investigador del área de
la biomedicina. Por lo tanto, y tomando como base el sistema actual, es
necesario proveer a dichos investigadores con las plantillas necesarias para
poder extraer el contenido de artı́culos en formato PDF.
Como posibles soluciones a este problema se plantean dos alternativas:
7.2.1.1
Crear una herramienta de generación de plantillas
Dificultad: media
esta herramienta facilitarı́a la generación de las plantillas hasta un punto tal
que el usuario esperado del sistema no tuviese problemas a la hora de generar
sus propias plantillas para la extracción de artı́culos con una maquetación
para la cual no dispusiera de una plantilla. Esta herramienta permitirı́a
visualizar un documento PDF y a través de una guı́a programada podrı́a
especificar de forma gráfica sobre el documento las diferentes secciones del
mismo. De esta forma la herramienta serı́a capaz de obtener la información
necesaria del documento para asignar los parámetros necesarios sobre el
formato del texto y su maquetación generando una plantilla especı́fica.
98
CAPÍTULO 7. CONCLUSIONES Y LÍNEAS FUTURAS
7.2.1.2
Eliminar la necesidad de uso de plantillas
Dificultad: muy alta
el método propuesto para llevar a cabo esta complicada labor, a grandes
rasgos, consiste en combinar técnicas gráficas con conocimiento lingüı́stico
y de estructura del documento. En una primera etapa, serı́a necesario
detectar las secciones de texto contiguas de forma gráfica utilizando para
ello las coordenadas de los elementos textuales dentro del documento. Una
vez identificadas las zonas, serı́a necesario ordenarlas entre sı́ utilizando
información relativa a la estructura del documento, utilizando heurı́sticas
como, por ejemplo, la conservación del tipo de letra. Considerando que este
tipo de heurı́sticas podrı́a no ser suficiente para determinar la ordenación
de las agrupaciones de texto, podrı́a resultar interesante utilizar técnicas de
análisis del lenguaje natural para introducir ası́ nuevas reglas que promuevan
que la continuación del texto forme oraciones correctas.
7.2.2
7.2.2.1
Detección de Secuencias
Adaptar el sistema para reconocer otro tipo de secuencias
Dificultad: media-alta
Los resultados obtenidos para el caso de esta etapa del sistema dejan poco
margen de mejora. No obstante, la detección de secuencias se ha desarrollado
especı́ficamente para la detección de primers y probes. Dado que este tipo
de secuencias son cadenas de nucleótidos, su aplicación directa a otros tipos
de secuencias, como por ejemplo las proteı́nas, supondrı́a la adaptación del
alfabeto de sı́mbolos, los reconocedores y las heurı́sticas de filtrado, pero
podrı́a conservarse el funcionamiento planteado separando la detección en
una fase de reconocimiento y otra de filtrado. La dificultad real de esta
adaptación dependerá de las caracterı́sticas concretas de las secuencias para
las que se quiera realizar.
Incluir una funcionalidad social para que la comunidad de usuarios
reporte falsos positivos
Dificultad: baja
Respecto al sistema actual, una posible mejora serı́a permitir que los usuarios
del ı́ndice de artı́culos y secuencias a través del interfaz web puedan reportar
las secuencias detectadas que en realidad no son secuencias genéticas –
i.e. falsos positivos. De esta forma, además de purgar las secuencias ya
detectadas, se puede generar una lista negra de secuencias que no deberı́an
reconocerse en lo sucesivo, mejorando ası́ el funcionamiento de la etapa de
99
PROYECTO FIN DE CARRERA
detección. Este enfoque, no obstante, requerirı́a de supervisión humana para
evitar posibles abusos del sistema de reporte de falsos positivos.
7.2.3
Anotación de Secuencias
Los dos problemas principales encontrados relativos a esta etapa son que
las bases de datos utilizadas sólo contenı́an información de microorganismos
y que esta etapa consume una gran cantidad de recursos de computación,
aumentando drásticamente el tiempo de computación.
7.2.3.1
Utilizar bases de datos más completas
Dificultad: baja
Para solucionar el primero de los problemas planteados, serı́a necesario
incorporar al sistema bases de datos más completas. La dificultad de esta
incorporación es relativamente baja, no obstante, es necesario considerar
que aumentar el tamaño de las bases de datos supone aumentar también el
tiempo de ejecución, especialmente al utilizar la herramienta BLAST.
7.2.3.2
Utilizar supercomputadores
Dificultad: media
Respecto al problema de tiempo de ejecución, un posible enfoque, de
dificultad media, aunque coste considerable, serı́a recurrir a su ejecución
en supercomputadores. A menor coste se podrı́a plantear la construcción
de un servicio responsable de esta etapa de la ejecución recurriendo a la
computación distribuı́da.
7.2.4
7.2.4.1
Creación y Mantenimiento del ı́ndice de Artı́culos y
Secuencias
Automatizar el proceso de obtención de artı́culos
Dificultad: media-baja
En esta primera implementación, se ha generado el ı́ndice desde cero a partir
de los documentos descargados de PubMed Central. Para la mantenibilidad
del sistema, serı́a necesario incorporar la funcionalidad de indizado
incremental sobre los nuevos artı́culos que se encuentren progresivamente
disponibles a través de PubMed Central. Una posible solución, de baja
dificultad, serı́a la descarga de actualizaciones periódicas de los nuevos
100
CAPÍTULO 7. CONCLUSIONES Y LÍNEAS FUTURAS
artı́culos para su inclusión en el ı́ndice, y con una dificultad intermedia,
podrı́a realizarse este proceso de forma completamente automática.
7.3
Publicaciones Derivadas de Este Trabajo
A raı́z de este Trabajo de Fin de Carrera, se han publicado dos artı́culos
cientı́ficos en las revistas BMC Bioinformatics y Bioinformatics. El primero
presenta el método expuesto en este Trabajo de Fin de Carrera para el
procesamiento de artı́culos en formato PDF, ası́ como la identificación,
extracción y anotación de las secuencias genéticas. En el segundo, se
presenta la aplicación PubDNA Finder, que puede ser consultada en la
URL http://servet.dia.fi.upm.es:8080/pubdnafinder. Esta aplicación web
es un interfaz de consulta al ı́ndice de artı́culos y secuencias que ha sido
generado en la implementación de este trabajo. A continuación se ofrecen
más detalles sobre los artı́culos y la importancia de las revistas en que han
sido publicados. Los artı́culos completos pueden consultarse en el apéndice
C.
7.3.1
A method for automatically extracting infectious
disease-related primers and probes from the literature
• Autores: Miguel Garcı́a-Remesal, Alejandro Cuevas, Victoria LópezAlonso, Guillermo López-Campos, Guillermo de la Calle, Diana de
la Iglesia, David Pérez-Rey, José Crespo, Fernando Martı́n-Sánchez y
Vı́ctor Maojo.
• Revista: BMC Bioinformatics 2010, 11:410
• Factor de Impacto: 3,428 (2009)
• Ranking: Cuarta (de ventinueve) en el área de “Mathematical and
Computational Biology”. Primer cuartil.
7.3.2
PubDNA Finder: a web database linking full-text
articles to sequences of nucleic acids
• Atutores: Miguel Garcı́a-Remesal, Alejandro Cuevas, David PérezRey, Luis Martı́n, Alberto Anguita, Diana de la Iglesia, Guillermo de
la Calle, José Crespo y Vı́ctor Maojo.
• Revista: Bioinformatics 2010, 26(21)2801-2802
• Factor de Impacto: 4,926 (2009)
101
PROYECTO FIN DE CARRERA
• Ranking: Segunda (de ventinueve) en el área de “Mathematical and
Computational Biology”. Primer cuartil y primer decil.
102
REFERENCIAS
Adobe Systems Incorporated .
Adobe Supplement to ISO 32000,
BaseVersion 1.7, ExtensionLevel 3. Adobe Systems Incorporated, 2008.
Adobe Systems Incorporated . Document Management – Portable Document
Format – Part 1: PDF 1.7. Adobe Systems Incorporated, 1 edition, 2008.
Adobe Systems Incorporated . Document Management – Portable Document
Format – Part 1: PDF 1.7. Adobe Systems Incorporated, 2009.
Altschul S. F, Gish W, Miller W, Myers E. W,, Lipman D. J. Basic local
alignment search tool. Journal of Molecular Biology 1990, 215(3):403–410.
Anvar S. Y, ’t Hoen P. A,, Tucker A. The identification of informative genes
from multiple datasets with increasing complexity. BMC bioinformatics
2010, 11:32.
Baeza-Yates R, Ribeiro-Neto B. Modern Information Retrieval. AddisonWesley Publishing Company, 2008.
Benson D. A, Karsch-Mizrachi I, Lipman D. J, Ostell J,, Sayers E. W.
Genbank. Nucleic acids research 2010, 38(Database issue):D46–51.
Betel D, Hogue C. W. Kangaroo–a pattern-matching program for biological
sequences. BMC bioinformatics 2002, 3:20.
Bobadilla J. JAVA a través de ejemplos. RAMA, 2003.
Bravo L. T, Procop G. W. Recent advances in diagnostic microbiology.
Seminars in hematology 2009, 46(3):248–258.
Bray T, Paoli J, Sperberg-McQueen , Maler E,, Yergeau F. Extensible
markup language (xml) 1.0 (fifth edition), 2011. URL http://www.w3.
org/TR/xml/.
Campi M. G, Castoldi M, Romano P, Thuroff E, Manniello M. A, Iannotta
B, Rondanina G, Ruzzon T,, Santi L. Molecular probe data base (mpdb).
Nucleic acids research 1997, 25(1):92–95.
103
PROYECTO FIN DE CARRERA
Center for Medical Genetics . Rtprimerdb, 2002. URL http://medgen.
ugent.be/rtprimerdb/.
Cheng L.-L, Cheung D. W,, Yiu S.-M. Approximate string matching in dna
sequences. Database Systems for Advanced Applications, International
Conference on 2003, 0:303.
Codd E. F. A relational model of data for large shared data banks. Commun.
ACM 1983, 26:64–69.
de la Calle G, Garcia-Remesal M, Chiesa S, de la Iglesia D,, Maojo V. Biri: a
new approach for automatically discovering and indexing available public
bioinformatics resources from the literature. BMC bioinformatics 2009,
10:320.
Enright M. C, Spratt B. G. Multilocus sequence typing.
microbiology 1999, 7(12):482–487.
Trends in
Free Software Foundation, Inc. . Gnu general public license, 2011. URL
http://www.gnu.org/licenses/gpl.html.
Fry C, Slominski A. The streaming api for xml (stax), 2011. URL http:
//stax.codehaus.org/Home.
Gonzalez-Diaz H, Perez-Montoto L. G, Duardo-Sanchez A, Paniagua
E, Vazquez-Prieto S, Vilas R, Dea-Ayuela M. A, Bolas-Fernandez F,
Munteanu C. R, Dorado J, Costas J,, Ubeira F. M. Generalized lattice
graphs for 2d-visualization of biological information. Journal of theoretical
biology 2009, 261(1):136–147.
Harmon P, King D. Expert systems : artificial intelligence in business. John
Wiley and Sons, 1985.
Hatcher E, Gospodnetic O,, McCandless M. Lucene in Action, Second
Edition: Covers Apache Lucene 3.0. Manning Publications Co., 2010.
Hirschman L, Yeh A, Blaschke C,, Valencia A. Overview of biocreative:
critical assessment of information extraction for biology.
BMC
bioinformatics 2005, 6 Suppl 1:S1.
Huang Y. C, Chang C. F, Chan C. H, Yeh T. J, Chang Y. C, Chen
C. C,, Kao C. Y. Integrated minimum-set primers and unique probe
design algorithms for differential detection on symptom-related pathogens.
Bioinformatics (Oxford, England) 2005, 21(24):4330–4337.
Hyyro H, Juhola M,, Vihinen M. On exact string matching of unique
oligonucleotides. Computers in biology and medicine 2005, 35(2):173–181.
104
REFERENCIAS
Larman C. UML y Patrones. Una introducción al análisis y diseño orientado
a objetos y al proceso unificado. Prentice Hall, 2002.
Li F, Stormo G. D. Selection of optimal dna oligos for gene expression
arrays. Bioinformatics (Oxford, England) 2001, 17(11):1067–1076.
LION bioscience AG . Sequence retrieval system, 2003. URL http://srs.
ebi.ac.uk/.
Loy A, Maixner F, Wagner M,, Horn M. probebase–an online resource for
rrna-targeted oligonucleotide probes: new features 2007. Nucleic acids
research 2007, 35(Database issue):D800–4.
McDonald R, Pereira F. Identifying gene and protein mentions in text using
conditional random fields. BMC bioinformatics 2005, 6 Suppl 1:S6.
Megginson D. The sax project, 2011. URL http://www.saxproject.org/.
Melichar B, Antos J, Holub J, Polcar T,, Voracek M. TEXT SEARCHING
ALGORITHMS. 2005.
Miller M. B, Tang Y. W. Basic concepts of microarrays and potential
applications in clinical microbiology. Clinical microbiology reviews 2009,
22(4):611–633.
Mothershed E. A, Whitney A. M. Nucleic acid-based methods for the
detection of bacterial pathogens: present and future considerations for the
clinical laboratory. Clinica chimica acta; international journal of clinical
chemistry 2006, 363(1-2):206–220.
MySQL AB . MySQL Administrator’s Guide and Language Reference (2nd
Edition). MySQL Press, 2006.
National Center for Biotechnology Information . Blast, 2009. URL http:
//blast.ncbi.nlm.nih.gov/Blast.cgi.
National Center for Biotechnology Information . Entrez nucleotide, 2009.
URL http://www.ncbi.nlm.nih.gov/nuccore.
National Center for Biotechnology Information . The ncbi probe database,
reagents for functional genomics, 2009. URL http://www.ncbi.nlm.nih.
gov/sites/entrez?db=probe.
Pabbaraju K, Tokaryk K. L, Wong S,, Fox J. D. Comparison of the luminex
xtag respiratory viral panel with in-house nucleic acid amplification
tests for diagnosis of respiratory virus infections. Journal of clinical
microbiology 2008, 46(9):3056–3062.
105
PROYECTO FIN DE CARRERA
Pattyn F, Speleman F, Paepe A. D,, Vandesompele J. Rtprimerdb: the
real-time pcr primer and probe database. Nucleic acids research 2003, 31
(1):122–123.
Ratcliff R. M, Chang G, Kok T,, Sloots T. P. Molecular diagnosis of medical
viruses. Current Issues in Molecular Biology 2007, 9(2):87–102.
Rice S. B, Nenadic G,, Stapley B. J. Mining protein function from text
using term-based support vector machines. BMC bioinformatics 2005, 6
Suppl 1:S22.
Rijsbergen , Van C. J. Information Retrieval. Butterworth-Heinemann,
1979.
Robertson S. E. The probability ranking principle in IR. Morgan Kaufmann
Publishers Inc., 1997.
Salton G, Wong A,, Yang C. S. A vector space model for automatic indexing.
Commun. ACM 1975, 18:613–620.
Salton G, McGill M. J. Introduction to Modern Information Retrieval.
McGraw-Hill, Inc., 1986.
Software Engineering Standards Committee of the IEEE Computer Society
. IEEE Recommended Practice for Software Requirements Specifications
(IEEE Standard 830-1998).
Spandidos A, Wang X, Wang H,, Seed B. Primerbank: a resource of
human and mouse pcr primer pairs for gene expression detection and
quantification. Nucleic acids research 2010, 38(Database issue):D792–9.
Sparck Jones K, Willett P. Readings in information retrieval. Morgan
Kaufmann Publishers Inc., 1997.
Tamames J. Text detective: a rule-based system for gene annotation in
biomedical texts. BMC bioinformatics 2005, 6 Suppl 1:S10.
Tarhio J, Peltola N. String matching in the dna alphabet. Software: Practice
and Experience 1997, 27(7):851–861.
The Apache Software Foundation . Apache license, version 2.0, 2011. URL
http://www.apache.org/licenses/LICENSE-2.0.html.
The Apache Software Foundation . Apache lucene, 2011. URL http://
lucene.apache.org/java/docs/index.html.
The Apache Software Foundation . Pdfbox, 2011. URL http://pdfbox.
apache.org/.
106
REFERENCIAS
The Massachusetts General Hospital . Primerbank, 2006. URL http://
pga.mgh.harvard.edu/primerbank/.
University of Vienna. Department of Microbial Ecology . probebase, 2003.
URL http://www.microbial-ecology.net/probebase/.
VanGuilder H. D, Vrana K. E,, Freeman W. M. Twenty-five years of
quantitative pcr for gene expression analysis. BioTechniques 2008, 44
(5):619–626.
W3C . Document object model (dom). URL http://www.w3.org/DOM/.
Woo P. C, Lau S. K, Teng J. L, Tse H,, Yuen K. Y. Then and now: use
of 16s rdna gene sequencing for bacterial identification and discovery of
novel bacteria in clinical microbiology laboratories. Clinical microbiology
and infection : the official publication of the European Society of Clinical
Microbiology and Infectious Diseases 2008, 14(10):908–934.
107
PROYECTO FIN DE CARRERA
108
Apéndice A
INSTALACIÓN DEL
SISTEMA, MANUAL DE
USUARIO Y EJEMPLOS
DE USO
A.1
Instalación del Sistema
En esta sección se detallan los pasos para la correcta instalación y
configuración del sistema para la detección y anotación de secuencias. En
primer lugar se indicarán los prerrequisitos necesarios para la instalación.
Después, se podrán encontrar indicaciones sobre cómo obtener e instalar las
herramientas y bases de datos externas necesarias para la correcta ejecución
del sistema y, por último, se ofrece una guı́a de configuración inicial del
sistema.
A.1.1
Paso 1: Prerrequisitos
Java Runtime Environment v1.6 o superior:
desde http://www.mysql.com/
MySQL Community Server v5.x:
http://www.mysql.com
se puede descargar
se puede descargar desde
ActivePerl Community Edition v5.8.8 o superior:
descargar desde http://www.activestate.com/activeperl/
109
se puede
PROYECTO FIN DE CARRERA
A.1.2
Paso 2: BLAST
BLAST: se
puede
ftp://ftp.ncbi.nlm.nih.gov/blast/executables/
obtener
desde
Base de Datos NT en formato BLAST: se puede descargar desde
el ftp ftp://ftp.ncbi.nlm.nih.gov/blast/db/. Es ncesesario descargar todos
los archivos con nombrado nt.*.tar.gz. Una vez descargados, extraer todos
los ficheros en un directorio, por ejemplo, d:/blastdb/nt. En lo sucesivo se
llamará a este directorio %BLASTDB%
A.1.3
Paso 3: GenBank
Cambios en la configuración de MySQL:
• En la pestaña “InnoDB Parameters”
– BufferPoolSize: 500 M
– Thread concurrency: 10
• En la pestaña “Advanced Networking”
– Max Packet Size: 20 M
• En la pestaña “Advanzed”
– Table Cache: 1520
Crear una nueva base de datos en MySQL con el nombre
deseado: por ejemplo, biosql
Descargar BioSQL: se puede descargar desde la página web
http://www.biosql.org/wiki/Main Page. Descargar y descomprimir. En
lo sucesivo se nombrará el directorio donde se haya descomprimido como
%BioSQL%.
Crear la estructura de la base de datos: esta operación se realiza
ejecutando el script biosqldb-mysql.sql. El comando para su ejecución es:
mysql -u root biosql < biosqldb-mysql.sql
Descargar e instalar BioPerl
de paquetes de ActivePerl
: para ello se puede utilizar el gestor
110
APÉNDICE A. INSTALACIÓN DEL SISTEMA, MANUAL DE USUARIO Y
EJEMPLOS DE USO
Descargar e instalar el módulo de conexión de MySQL para
Perl : para ello se puede utilizar el gestor de paquetes de ActivePerl
Cargar la taxonomı́a del NCBI en la base de datos : mediante
la ejecución del script load ncbi taxonomy.pl, contenido en la distribución
de BioPerl.
Descargar los ficheros de GenBank : estos ficheros se encuentran
accesibles en el sitio ftp://ftp.ncbi.nih.gov/genbank/.
Sólo han de
descargarse los ficheros cuyo nombrado se corresponda con el esquema
gbDIVX.seq.gz, donde X puede ser cualquier número y DIV una de las
siguientes divisiones: Acc, Aut, Bct, Con, Env, Est, Gss, Htc, Htg, Inv,
Pat, Phg, Pln, Pri, Rod, Sts, Syn, Tsa, Una, Vrl o Vrt.
Poblar la base de datos : mediante la ejecución del script
load seqdatabase.pl contenido en la distribución de BioPerl. Utilizar el
siguiente comando:
perl load seqdatabase.pl -dbname biosql -dbuser root
-driver mysql -lookup -safe -format genbank fich1 fich2
fich3...
donde fich1, fich2, fich3 están referidos a los ficheros descargados en el
paso anterior.
A.1.4
Paso 4: instalar y configurar PrimerXTractor
PrimerXTractor es el nombre dado al subsistema para la detección y
anotación de secuencias en artı́culos cientı́ficos. Para su instalación, es
necesario descomprimir el contenido del paquete. Tras la descompresión,
quedará la siguiente estructura de archivos:
• test/
• primerXtractor.jar -¿ executable jar
• bmc.xml
• plos.xml
• dictionary.txt
• list.txt
• System.properties
• README.txt
111
PROYECTO FIN DE CARRERA
Editando el contenido del fichero System.properties se configurará el
sistema.
• GenBank Database: este campo especifica la URL a la base de datos
MySQL que contiene los datos de GenBank.
• GenBank Database user: nombre de usuario de la base de datos.
• GenBank Database password: contraseña del usuario en la base de
datos.
• Blast Binary Path:
BLAST.
ruta al archivo ejecutable de la herramienta
• Blast Database: ruta a la base de datos en formato BLAST
(%BLASTDB%).
A.2
A.2.1
Ejecución del Sistema
Detección y extracción de secuencias
El jar contenido en el paquete de PrimerXTractor es ejecutable, la sintaxis
de ejecución es:
textttjava -jar primerXtractor.jar -i inputDocument -o resultPath [-t
template] [-reuseBR] [-reuseGR]
A continuación se explica el comportamiento según los argumentos
suministrados:
• inputDocument: ruta al artı́culo a procesar
• resultPath: ruta donde se desea dejar el fichero XML con los resultados
• template: indica la ruta a la plantilla a utilizar para procesar archivos
PDF. Sólo es necesario si la entrada es un archivo PDF.
• reseBR: (opcional) indica al sistema que guarde los resultados parciales
de BLAST para ejecuciones futuras.
• reuseGR: (opcional) indica al sistema que guarde los resultados
parciales de la base de datos de GenBank para ejecuciones futuras.
A.2.2
Generación del Índice de Artı́culos y Secuencias
El sistema cuenta con que los ficheros XML correspondientes a la colección
sobre la que se quiere generar el ı́ndice se encuentran en una base de
112
APÉNDICE A. INSTALACIÓN DEL SISTEMA, MANUAL DE USUARIO Y
EJEMPLOS DE USO
datos. Para generar esta base de datos se puede utilizar el jar ejecutable
DBPopulator. Una vez creada la base de datos el ı́ndice de articulos y
secuencias a partir de la base de datos simplemente es necesario ejecutar ej
jar ejecutable SequenceExtractor.
El ı́ndice cuenta con varios campos que pueden ser consultados utilizando
la sintaxis mencionada. Estos campos son:
• pmcid: identificador de PubMed Central
• title: tı́tulo
• authors: autores
• text: texto del documento.
búsqueda de texto libre.
Este es el campo por defecto en la
• sequences: secuencias.
Este es el único campo permitido en
la búsqueda de secuencias, está establecido por defecto y se ha
desabilitado la búsqueda por otros campos en estas consultas.
A.3
A.3.1
Ejemplos de Uso
Detección y Anotación
PrimerXTractor
de
Secuencias
usando
En el directorio test/ que puede observarse tras descomprimir el paquete
de PrimerXTractor, pueden encontrarse varios artı́culos en formatos PDF
y XML junto con resultados parciales ya generados. Para ejecutar los
siguientes ejemplos se debe abrir una consola y cambiar al directorio que
contiene el fichero primerXTractor.jar.
Ejemplo 1: Extracción y anotación de secuencias desde un artı́culo en
formato PDF para la revista Virology Journal del grupo BMC
java -jar primerXtractor.jar -i test/bmcTest1.pdf -o
results01.xml -t bmc.xml -reuseBR -reuseGR
Ejemplo 2: Extracción y anotación de secuencias desde un artı́culo en
formato PDF para la revista BMC Microbiology
java -jar primerXtractor.jar -i test/bmcTest2.pdf -o
results02.xml -t bmc.xml -reuseBR -reuseGR
113
PROYECTO FIN DE CARRERA
Ejemplo 3: Extracción y anotación de secuencias desde un artı́culo en
formato PDF para la revista PLoS One
java -jar primerXtractor.jar -i test/plosTest1.pdf -o
results03.xml -t plos.xml -reuseBR -reuseGR
Ejemplo 4: Extracción y anotación de secuencias desde un artı́culo en
formato PDF para la revista PLoS Genetics
java -jar primerXtractor.jar -i test/plosTest2.pdf -o
results04.xml -t plos.xml -reuseBR -reuseGR
Ejemplos 5, 6, 7 y 8: Extracción y anotación de secuencias desde un
artı́culo en formato XML para los mismos artı́culos que los anteriores cuatro
ejemplos
java -jar primerXtractor.jar -i test/bmcTest1.xml -o
results05.xml -reuseBR -reuseGR
java -jar primerXtractor.jar -i test/bmcTest2.xml -o
results06.xml -reuseBR -reuseGR
java -jar primerXtractor.jar -i test/plosTest1.xml -o
results07.xml -reuseBR -reuseGR
java -jar primerXtractor.jar -i test/plosTest2.xml -o
results08.xml -reuseBR -reuseGR
Ejemplos 9 y 10: Extracción y anotación de secuencias de dos
artı́culos en texto plano
java -jar primerXtractor.jar -i test/bmcTest2.txt -o
results09.xml -reuseBR -reuseGR
java -jar primerXtractor.jar -i test/plosTest1.txt -o
results10.xml -reuseBR -reuseGR
A.3.2
Ejemplo de uso de PubDNA Finder: interfaz web para
el ı́ndice de artı́culos y secuencias
PubDNAFinder es el interfaz web generado para las consultas sobre el ı́ndice
de los artı́culos de PubMed Central generado utilizando este sistema. Se
encuentra disponible en http://servet.dia.fi.upm.es:8080/pubdnafinder/.
Respecto a la realización de consultas sobre el ı́ndice utilizando el interfaz
web, en la siguiente sección se detalla un ejemplo de uso de consultas.
Para la realización de estas consultas se pueden utilizar los elementos de
la sintaxis de consultas de Lucene, que pueden encontrarse en la siguiente
url: http://lucene.apache.org/java/2 4 0/queryparsersyntax.html.
114
APÉNDICE A. INSTALACIÓN DEL SISTEMA, MANUAL DE USUARIO Y
EJEMPLOS DE USO
Figura A.1: Interfaz web PubDNAFinder
Los elementos de la figura A.1 se detallan a continuación:
1. En este campo se introducirán las secuencias, una por lı́nea, para las
que se desea realizar la búsqueda. El selector de operador indicará
si deben aparecer alguna de las secuencias o todas ellas en el mismo
artı́culos.
2. En este campo se introducirá el texto libre para el que se desea realizar
la busqueda.
115
PROYECTO FIN DE CARRERA
3. El botón de enviar comienza la búsqueda sobre el ı́ndice. El botón clear
fields deja los campos en blando y el botón Restablecer devuelve el
estado de las cajas de texto a su estado original en el que se encontraran
al cargar la página.
4. En esta zona se encuentran los resultados.
En función de si se rellenan ambas cajas de texto para artı́culos y para
texto, las búsquedas tendrán comportamientos diferentes. En el caso de
introducir sólo secuencias, el sistema recuperará todos los manuscritos que
las contengan, indicando las secuencias relevantes a la consulta en el área
de resultados. Si sólo se proporciona texto, el sistema devolverá todos los
artı́culos relevantes a la consulta textual e indicará todas las secencias que
éstos contentan. En el caso de incluir información sobre secuencias y también
texto a la hora de realizar la búsqueda, se recuperarán sólo los artı́culos
relevantes al texto y a las secuencias simultáneamente, mostrando en los
resultados sólamente las secuencias relevantes.
116
Apéndice B
DETALLES DEL SISTEMA
Por simplicidad, y para permitir una mejor comprensión global del
funcionamiento y desarrollo del sistema, se han omitido ciertos detalles en
el planteamiento de los mismos a lo largo de este Trabajo de Fin de Carrera,
remitiendo al lector a consultar este Anexo.
B.1
B.1.1
Detección y Filtrado de Secuencias
Reconocedores
A continuación se muestran una serie de ejemplos de reconocimiento de
secuencias, indicando, para cada una de ellas, el identificador de PubMed
(PMID) del artı́culo en que aparece, el reconocedor con que ha sido
reconocida la secuencia, el texto del artı́culo en el que aparece y la lista
de tokens generada. Más adelante puede observarse la figura B.1 con los
autómatas finitos asociados a cada uno de los diferentes reconocedores.
B.1.1.1
Ejemplos de Reconocimiento de Secuencias
Ejemplo 1
• Reconocedor: 1
• PMID: 19781080
• Texto: ...primers AA247 (5’-TGCCATTGCCAAAGAGAC-3’) and
pLQ510-rp1...
• Lista de Tokens: {“TGCCATTGCCAAAGAGAC”}
Ejemplo 2
• Reconocedor: 1
117
PROYECTO FIN DE CARRERA
• PMID: 19664269
• Texto:
...mecA
gene,
mecAR (5’-TTACTCATGCCATACATAAATGGATA- \n GACG-3’)
and mecAF...
• Lista de Tokens:
“GACG”}
{“TTACTCATGCCATACATAAATGGATA”,
Ejemplo 3
• Reconocedor: 2
• PMID: 19799780
• Texto: B-globin outside R @ CTC AAG TTC TCA GGA TCC A @
1st round PCR primer for Human Beta globin DNA
• Lista de Tokens: {“CTC”, “AAG”, “TTC”, “TCA”, “GGA”, “TCC”,
“A”}
Ejemplo 4
• Reconocedor: 2
• PMID: 18847469
• Texto: btherm @ GAT GTG CCG GGC TCC TGC ATG @ This
study
• Lista de Tokens: {“GAT”, “GTG”, “CCG”, “GGC”, “TCC”, “TGC”,
“ATG”}
Ejemplo 5
• Reconocedor: 3
• PMID: 19737401
• Texto: ..and 3’ AAGCT TGGTA CCTCA CTGCA \n GCAGA
GCGCT GAGGC CCAGC AGCAC. The resulting PCR...
• Lista de Tokens: {“AAGCT”, “TGGTA”, “CCTCA”, “CTGCA”,
“GCAGA”, “GCGCT”, “GAGGC”, “CCAGC”, “AGCAC”}
118
APÉNDICE B. DETALLES DEL SISTEMA
Ejemplo 6
• Reconocedor: 3
• PMID: 19149882
• Texto: 1 @ XAC0340 @ 432 @ gATACCCCATATgAATgCgAT
• Lista de Tokens: {“gATACCCCATATgAATgCgAT”}
Figura B.1: Reconocimiento de Secuencias: Reconocedores
B.1.2
Reglas de Filtrado
A continuación se muestran las reglas de filtrado en formato matemático y
explicadas en lenguaje natural.
119
PROYECTO FIN DE CARRERA
Regla 1:
X
long(sj ) < Lmin −→ borrar(s)
sj ∈s
SI la suma de las longitudes –i.e. número de sı́mbolos– de todos los tokens
sj de la secuencia s es menor que Lmin , ENTONCES borrar s.
Regla 2:
∃i|i = af ijo en cola(s) −→ borrar(s) ∧ insertar(s0 )
s0 = s1 , ..., si−1
SI se encuentra un elemento de la lista de afijos problemáticos al final
de la cadena s, ENTONCES se elimina s de la base de hechos Y se inserta
una nueva secuencia, s0 , resultado de eliminar el afijo problemático.
Regla 3:
∃i|i = af ijo en cabeza(s) −→ borrar(s) ∧ insertar(s0 )
s0 = si+1 , ..., sn
SI se encuentra un elemento de la lista de afijos problemáticos al
comienzo de la cadena s, ENTONCES se elimina s de la base de hechos Y
se inserta una nueva secuencia, s0 , resultado de eliminar el afijo problemático.
Regla 4:
∧sj ∈s −→ borrar(s)
SI todos los tokens de sj de s son palabras del diccionario de términos
ingleses pertenecientes a Σ+ , ENTONCES se elimina s de la base de
hechos.
Regla 5:
∃i, j|(i, j) = af ijo en secuencia(s) −→ borrar(s)∧insertar(s0 )∧insertar(s00 )
s0 = s1 , ..., si−1
s00 = sj+1 , ..., sn
SI se encuentra un elemento de la lista de afijos problemáticos dentro de
la cadena s, ENTONCES se elimina s de la base de hechos Y se insertan
dos nuevas secuencias, s0 y s00 , correspondientes a las secuencias anterior y
posterior al afijo.
120
APÉNDICE B. DETALLES DEL SISTEMA
Regla 6:
in dictionary(s1 ) ∧ long(s1 ) ≥ 3 −→ eliminar(s) ∧ insertar(s0 )
s0 = s2 , ..., sn
SI el primer token de s es una palabra del diccionario de términos ingleses
pertenecientes a Σ+ Y dicho token tiene una longitud mayor o igual a 3,
ENTONCES se elimina s de la base de hechos Y se inserta una nueva
secuencia, s0 , resultado de eliminar el primer token de s.
Regla 7:
in dictionary(sn ) ∧ long(sn ) ≥ 3 −→ eliminar(s) ∧ insertar(s0 )
s0 = s1 , ..., sn−1
SI el último token de s es una palabra del diccionario de términos ingleses
pertenecientes a Σ+ Y dicho token tiene una longitud mayor o igual a 3,
ENTONCES se elimina s de la base de hechos Y se inserta una nueva
secuencia, s0 , resultado de eliminar el último token de s.
Regla 8:
tam(s) ≥ 2 −→ concatenar(s)
SI s está compuesta por más de un token, ENTONCES concatenar
todos los tokens de s para generar una única secuencia.
B.2
B.2.1
Anotación de Secuencias
Cálculo del Valor de Confianza de Nombres de
Organismo y Gen
El valor de confianza para organismos y genes se calcula dependiendo de
la similitud del término o términos encontrados en el texto respecto a la
cadena buscada. En el caso de los genes, simplemente se podrá distinguir
entre si se encuentra en el texto o no, mientras que en el caso de los
nombres de organismo, esta similitud dependerá del número de palabras
que conforman el nombre del organismo encontradas en el texto. Además,
este valor dependerá, a su vez, de la coocurrencia de la aparición de la
secuencia genética y el nombre de organismo o gen en la misma sección.
El cálculo de la similitud del término encontrado respecto del texto
buscado viene dado por la siguiente expresión:
121
PROYECTO FIN DE CARRERA


 0
P
CSL (l) =
40 + L−1
j=L−l


80
si
40
2j
l=0
si 1 ≤ l ≤ L
si
l=L
donde
• L es la longitud, en número de palabras, del nombre del organismo
• l es la máxima longitud –i.e. número de palabras consecutivas– del
texto que encajan con el nombre buscado
La fórmula mostrada está diseñada para otorgar valores más altos, con
un máximo de 80, cuanto mayor sea el número de palabras encontradas para
un nombre de organismo. Además, tiene en cuenta que cuanto más largo es
un nombre de organismo, entendiendo la longitud como número de palabras,
más especı́fico es este organismo, y, por tanto, una aparición de este nombre
más generalista debe ser menos penalizada. A continuación se muestra una
gráfica para ilustrar este hecho, mostrando 9 instancias de la función CS
para nueve longitudes de nombre de organismo, desde 2 hasta diez palabras.
Figura B.2: Cálculo del Valor de Confianza: Función CS
122
Apéndice C
ARTÍCULOS
PUBLICADOS
123