Título: Diseño e Implementación del Recuperador de Información para el SIGEP Trabajo de Diploma para optar por el título de
Ingeniero en Ciencias Informáticas Autor: Yusnier Matos Arias
Tutor: Ing. Javier López del Castillo Caymares
Mayo de 2008
Declaro ser autor de la presente tesis y reconozco a la Universidad de las Ciencias Informáticas los derechos patrimoniales de la misma, con carácter exclusivo.
Para que así conste firmo la presente a los ____ días del mes de ________ del año ________.
Yusnier Matos Arias Ing. Javier López del Castillo Caymares
______________ ______________
Firma del Autor Firma del Tutor
Graduado en el 2007 de la carrera Ingeniería en Ciencias Informáticas en la Universidad de las Ciencias Informáticas.
Luego de su graduación fue ubicado en la misma universidad como profesor de programación de la facultad 4.
Actualmente pertenece al proyecto SIGEP.
AGRADECIMIENTOS
Agradezco a todas las personas que de una forma u otra han hecho posible la realización de este trabajo.
En especial:
A Juan Carlos, por haber sido parte de la solución.
A Javier, por su paciencia, sus buenas ideas y sugerencias.
A Yisel, por su constante apoyo y su ayuda en la edición.
A Yanet Vega, por su ayuda incondicional.
A Arturo y Madelyn, por sus sugerencias siempre oportunas.
A Yuliesky y Dariel, por preocuparse siempre y ayudarme.
DEDICATORIA
A mi madre, por estar, por creer en mí y apoyarme en todo, por inspirarme con tan solo pensarla.
A mi padre, por confiar en mí y ayudarme, por darme la fuerza suficiente.
A mis hermanitas, Yuli y Lía.
A mi familia y a mis amigos.
Para contribuir a la solución de los problemas por los que atraviesa el Sistema Penitenciario Venezolano, se decidió crear el Sistema de Gestión Penitenciaria (SIGEP), el cual tiene como misión automatizar los procesos de la institución y garantizar la gestión rápida y segura de toda la información correspondiente a los internos y funcionarios.
El SIGEP está compuesto por módulos que agrupan funcionalidades estrechamente relacionadas entre sí, estos módulos a su vez, están agrupados a un nivel más alto, en Subsistemas, los cuales se corresponden con las principales áreas de la institución, tal es el caso de Control Penal, Seguridad y Custodia, Observación, Clasificación y Tratamiento, entre otros.
Estos subsistemas y módulos, necesitan constantemente recuperar información relacionada con los internos y funcionarios.
A partir de que estas necesidades se han identificado como necesidades comunes en varios de estos subsistemas o módulos, se decide desarrollar un componente encargado de recibir todas las peticiones de búsqueda o recuperación de información desde cualquier parte del sistema y devolverlas en una estructura que pueda ser procesada por los interesados.
PALABRAS CLAVE
SIGEP, Recuperación de Información.
Tabla de Contenido
DECLARACIÓN DE AUTORÍA ... III DATOS DE CONTACTO ... I
DEDICATORIA ... 3
RESUMEN ... 4
INTRODUCCIÓN ... 6
BUSCADORES... 8
Motores de búsqueda (Buscadores Automáticos o Arañas) ... 8
Directorios o Índices ... 10
Sistemas Mixtos (Buscador - Directorio) ... 10
Buscadores Empresariales... 10
Recuperador de Información ... 11
DESCRIPCIÓN DETALLADA DEL PROBLEMA ... 12
SOLUCIÓN DE SOFTWARE PROPUESTA ... 13
APORTE DE LA SOLUCIÓN, BENEFICIOS, RESULTADOS... 14
TÉCNICAS, MÉTODOS Y HERRAMIENTAS USADAS ... 15
Plataforma J2EE ... 15
Entorno de Desarrollo ... 15
Frameworks y Tecnologías Utilizados ... 15
Herramientas de modelado ... 17
Gestor de Bases de Datos Oracle ... 18
Pluggins Subclipse ... 18
INTEGRACIÓN CON LA ARQUITECTURA ... 19
Patrones Arquitectónicos utilizados: ... 19
FLUJO DE TRABAJO ... 23
DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA ... 26
DIAGRAMA DE CLASES DEL DISEÑO... 28
DESCRIPCIÓN DE LAS CLASES ... 32
MODELO FÍSICO DE DATOS. ... 34
CONCLUSIONES ... 35
RECOMENDACIONES ... 36
BIBLIOGRAFÍA ... 37
GLOSARIO ... 38
INTRODUCCIÓN
A principios del año 2005 se realizó un censo nacional de la situación judicial de la población penitenciaria venezolana. El censo demostró, entre otros aspectos, las necesidades que en materia de gestión, información, comunicación y apoyo a la toma de decisiones, tenía la Dirección General de Custodia y Rehabilitación del Recluso (DGCRR).
La DGCRR no contaba con aplicaciones informáticas para facilitar la gestión penitenciaria y por tanto, los expedientes de los privados de libertad se llevaban mayormente en papel, salvo algunas iniciativas aisladas que utilizaban hojas de cálculo para mantener alguna información. En general la información que se manejaba en los establecimientos penitenciarios se llevaba de manera manual, lo que imposibilitaba tomar decisiones en función de la realidad objetiva de cada centro y obstaculizaba la visión estratégica de la DGCRR.
Con el propósito de mantener una base de datos centralizada que maneje toda la información de los privados de libertad e incluya lo relativo al proceso penal y la ejecución de la pena, los datos personales y biométricos, el estado de salud, el expediente de tratamiento y otros datos relevantes para la gestión de los internos, se ha diseñado el Sistema de Gestión Penitenciaria (SIGEP), como una solución informática para gestionar la información operativa que se genera en los establecimientos penitenciarios.
Para que el sistema sea fácil de usar por los funcionarios, este ha sido diseñado de forma similar a un expediente penitenciario. Cada funcionario, en dependencia de su especialidad tendrá acceso a determinadas partes de este expediente, pero todos tienen en común que previamente deben ubicar al(a los) individuo(s) sobre el(los) que se desea trabajar.
Algunas funcionalidades, como el “Ingreso”, requieren que se busque si el individuo se encuentra registrado en el penal (búsqueda local) o si se encuentra registrado en el centro de datos (búsqueda remota). En función de estos resultados, se activarán mecanismos específicos durante el ingreso, propios de cada situación.
De igual manera otros módulos como el encargado del registro de visitantes, las novedades, estudio, trabajo, deporte, cultura entre otros, necesitan ubicar tanto a internos, como funcionarios o visitantes relacionados con algún proceso de gestión en particular. Por ejemplo, en el caso de las novedades, es necesario registrar los involucrados en un hecho y dado que los posibles involucrados ya han sido registrados en el sistema estos se ubican auxiliándose de criterios de búsqueda y son asociados a un hecho particular.
Los expedientes de los internos deben ser actualizados siempre que la situación lo requiera, ya sea para modificar los datos de su historia clínica, su situación jurídica o estado legal. Para llevar a cabo tal proceso primero se debe localizar dicho expediente y se hace buscando al interno y luego identificando la última actualización de su expediente. Para localizar al interno, se hace necesario, como en otros casos, una herramienta que permita buscarlo mediante determinados criterios (nombre, apellido, número de expediente, etc.), para luego, efectuar los cambios en el expediente del mismo.
El SIGEP mantiene un histórico con los datos de los internos contenidos en su expediente, de manera que pueda ser consultada y actualizada con cierta frecuencia. Para gestionar dicha información es necesario crear un Recuperador de Información capaz de obtenerla y procesarla para mostrar el resultado requerido
El sistema, por tanto, requiere hacer un uso intensivo de funcionalidades de búsqueda de
Individuos, los que pueden ser tanto privados de libertad, como funcionarios o visitantes. De aquí se plantea la necesidad de diseñar e implementar un componente reutilizable que ofrezca facilid ades de búsqueda local o remota, de individuos dentro del Sistema de Gestión Penitenciaria.
De ahí surge la necesidad de elaborar un diseño que permita posteriormente implementar una solución óptima en cuanto al tiempo de respuesta y facilidad de acceso a dicha funcionalidad.
Partiendo de lo anterior se puede plantear que el problema a resolver queda formulado a modo de interrogante de la siguiente manera:
¿Cómo diseñar e implementar el Recuperador de Información del SIGEP para obtener los resultados de forma correcta y eficiente?
Por tanto el objeto de estudio se enmarca en los procesos y estrategias de recuperación de información dentro de recuperadores de información empresariales, definiendo como campo de acción la estrategia de recuperación de información dentro del SIGEP.
El objetivo general de la investigación es el Desarrollo del Recuperador de Información (en lo adelante RI) para el Sistema de Gestión Penitenciaria, facilitando así la gestión de determinada búsqueda según las necesidades del usuario.
Para poder dar cumplimiento de una forma completa y exitosa a este objetivo, se ha decidido desarrollar las siguientes tareas:
Evaluar otros recuperadores de información existentes.
Identificar Patrones de Diseño, con el fin de lograr un diseño adecuado para la solución del problema.
Diseñar e implementar la solución.
Durante el proceso de diseño e implementación de la solución se utilizaron diferentes métodos, herramientas y tecnologías propuestas por la arquitectura base del SIGEP, con el propósito de obtener resultados más eficientes y además agilizar el trabajo. A continuación se mencionarán algunas de dichas herramientas y tecnologías usadas:
Ambiente de desarrollo o IDE Eclipse
Plataforma de desarrollo o Plataforma J2EE
Lenguaje de programación o Java
Frameworks
o Spring Framework o Hibernate Framework
API Criteria
Herramientas de modelado o Visual Paradigm Suite o Embarcadero EREstudio
Gestor de bases de datos
Oracle
Pluggins
o Spring IDE o Subeclipse
Buscadores
Los buscadores son herramientas o sistemas que agilizan y facilitan la obtención de información previamente almacenada en bases de datos o en algún soporte duro. Actualmente los más difundidos son los que realizan búsquedas a través de la Web, los cuales se clasifican según la estrategia que utilizan en: Motores de Búsqueda (Buscadores Automáticos), Buscadores basados en Directorios o Índices y Buscadores Híbridos o Mixtos. Existen otros que no trabajan precisamente sobre la Web, sino que se centran en un dominio mucho más pequeño, como son los Buscadores Empresariales y Recuperadores de Información. Éstos últimos se especializan generalmente en la búsqueda de recursos o personas de una institución e incluso dentro de la propia aplicación.
Motores de búsqueda (Buscadores Automáticos o Arañas)
Los Motores de Búsqueda, utilizan programas que simulan el funcionamiento de nuestros Navegadores ("Explorer" o "Netscape”), estos programas comúnmente denominados "Robots" o "Web- Crawlers" pueden estar escritos en varios lenguajes (Perl, C. etc.) pero su funcionamiento básico depende del protocolo HTTP (Hyper Text Transfer Protocol).
Cada vez que solicitamos una página en Internet, nuestro navegador (además de convertir el "nombre del sitio" a un nodo IP, envía información que es denominada "HEADERS", los cuáles son interpretados por el servidor de páginas.
Parte de la información enviada puede ser:
Qué navegador está solicitando la información (Esto tiene implicaciones para enviar formatos de HTML, e inclusive es la forma en que se distingue cuando la solicitud proviene de un aparato inalámbrico)
Si el navegador aceptará "cookies”.
Si el navegador puede desplegar fotografías JPEG, GIF o Java.
Una vez analizada la información recibida por el servidor de páginas, este envía sus respectivos
"HEADERS" con la información pertinente. Estos últimos también son de suma importancia ya que le indican al Navegador o "Web-Crawler", cómo está siendo enviada la información.
Gráficamente:
Figura 1 Intercambio de información entre servidor web y cliente.
De la misma manera que un cliente solicita una página de Internet y la muestra en la pantalla, un Robot ("Web-Crawler") simula esa solicitud, solo que en vez de mostrarla, guarda y clasifica toda la información que contiene la página en una base de datos. Mediante el uso de "Web -Crawlers"
compañías como Altavista y Google analizan cientos o miles de páginas por segundo, de manera que cuando se acude a uno de estos Motores de Búsqueda ellos ya han logrado detectar y clasificar una gran cantidad de Información mediante el uso de Robots.
El proceso de recopilación de una araña es el siguiente:
Figura 2. Proceso de recopilación de una Araña. (Spider)
Una araña visita tu página Web, entrando por el root, lee todo el contenido y crea una lista de lo que ha encontrado.
La información es indexada según los algoritmos internos usados por el buscador Esta información es llevada a una central donde se almacena.
Cuando alguien realiza una búsqueda, el sistema muestra todas las Webs que contienen la palabra o frase buscada.
El orden en que muestra los resultados depende de los algoritmos internos en los que se tiene en cuenta “la importancia” de una página Web.
Ejemplos de Spiders: Google, Hotbot, Lycos.
Directorios o Índices
Los Buscadores Basados en Directorios o Índices son catálogos que agrupan sus enlaces por categorías y utilizan tecnología barata, que es ampliamente usada por la cantidad de programas scripts en el mercado. Dado que no requieren muchos recursos de Informática están muy extendidos en la red. En cambio, se requiere más soporte humano y mantenimiento. Son motores buscadores completamente distintos a los spiders. En estos, los algoritmos son mucho más sencillos, presentando la información sobre las Webs registradas como una colección de directorios. No recorren las Webs ni almacenan sus contenidos. Solo registran algunos de los datos de las mismas, como el título y la descripción que se introduzcan a la hora de registrar los sitios.
Los resultados de la búsqueda, estarán determinados por la información que se haya suministrado al directorio cuando se registra la Web. En cambio, a diferencia de los motores, son revisadas por operadores humanos, y clasificadas según categorías, de forma que es más fácil encontrar páginas del tema de nuestro interés.
Su tecnología, es muy barata y sencilla. Tiene un coste de operación relativamente alto, pues tiene que ser operado por humanos práctica y exclusivamente.
Son apropiados para buscar categorías, más que informaciones específicas. Para visitar sitios de temática común. Es la tecnología que utilizan portales y buscadores de sectores especializados como economía, derecho, naturaleza, deportes, famosos, humanidades.
Ejemplos de directorios: Yahoo, Terra (Antiguo Olé). Ahora, ambos utilizan tecnología spider, y Yahoo conserva su directorio. Buscar Portal, es un directorio, y la mayoría de motores hispanos son directorios.
Sistemas Mixtos (Buscador - Directorio)
Son una mezcla entre buscadores y directorios. Una parte de la búsqueda se realiza de forma automática a través de un motor de búsqueda o spider, que se encarga de escanear la Web recopilando información, sin embargo, una gran parte del trabajo es realizada por un grupo de personas encargadas de elaborar los directorios. Estos presentan las Webs registradas en catálogos
sobre contenidos variados: informática, cultura, sociedad, que a su vez pueden dividirse en subsecciones.
Ejemplo de sistema mixto: Excite, Voila, Infoseek. Los motores en la actualidad, suelen tender hacia sistemas mixtos como ha ocurrido con Altavista.
Buscadores Empresariales
Este tipo de buscadores generalmente se implementa para realizar búsquedas de documentos en directorios o carpetas dentro de una institución. Su objetivo fundamental no es localizar la información y mostrarla, sino que su peso recae en la forma de mostrar dicha información, en asignarle una relevancia1 a un elemento encontrado. Pueden ser considerados como un directorio. Están basados en expresiones regulares y consultas SQL.
1Relevancia: en el contexto de un buscador, la relevancia indica el grado de importancia (o match) que tiene un documento en relación al (los) término(s) de la búsqueda realizada.
Recuperador de Información
Un Recuperador de Información es un sistema capaz de acceder a la información almacenada previamente en bases de datos y aplicar distintas funciones sobre los datos recuperados como parte del proceso de la solicitud que ha sido realizada por el usuario, para devolver, finalmente, el resultado deseado por el mismo.
La característica fundamental del Recuperador de Información es la definición bien explícita de lo que se desea buscar, es decir, toda la información está indexada en la base de datos, y organizada por tablas relacionadas entre sí, a las cuales se puede acceder mediante consultas SQL directamente o utilizando algún framework.
Este tipo de buscadores se centra, generalmente, en dominios que por definición son pequeños, como lo es el propio dominio de la aplicación, donde las estrategias de búsqueda pueden ser relativamente fáciles de definir dado que la información está presente en las bases de datos, pudiendo ser
correctamente recuperada con la utilización de la consulta adecuada.
Un ejemplo de este tipo de buscadores es el recuperador de información de EAS (Enterprise
Application Search) de IFS. Este, gracias a que es una parte integrada de las soluciones de IFS, ofrece resultados más exactos que una búsqueda genérica, elemento que tienen a su favor los
Recuperadores de Información por estar orientados a un dominio específico y bien definido.
DESCRIPCIÓN DETALLADA DEL PROBLEMA
El primer problema que se puede plantear, es el hecho de que para desarrollar otras funcionalidades dentro del SIGEP, la mayoría de las veces es necesario ubicar antes al individuo, tal es el caso del módulo de Ingreso, que requiere verificar primero la existencia de un individuo ya sea en el penal, o en el centro de datos.
En el caso del Egreso, es necesario asegurarse de la existencia del individuo en el penal.
En el módulo de Novedades, para registrar alguna nueva novedad, debe primero localizar a los implicados, los cuales pueden ser tanto internos como funcionarios o visitantes.
En el módulo de Armamentos, para la gestión de entrega de los mismos, se debe localizar al funcionario del penal implicado en dicha acción.
Por las características del Software, se ha hecho necesario extender las búsquedas no solo para internos, sino también para funcionarios o visitantes tanto institucionales como familiares, que se relacionan de alguna manera con internos o determinados procesos sobre los mismos.
Por la necesidad de llevar a cabo las funcionalidades planteadas anteriormente, se requiere un uso intensivo de funcionalidades de búsqueda para facilitar y poder realizar el trabajo en los demás módulos del SIGEP de forma satisfactoria, si se tiene en cuenta que la mayoría de los módulos requieren de funcionalidades de este tipo (búsqueda), se puede llegar a la conclusión de que es necesario implementar dicha funcionalidad de forma que pueda ser utilizada por los demás módulos de la aplicación, disminuyendo la repetición de código y contribuyendo con un mejor aprovechamiento del tiempo.
SOLUCIÓN DE SOFTWARE PROPUESTA
Habiendo hecho un estudio sobre algunos tipos de buscadores, y analizado no a un nivel muy profundo, sus estrategias de búsqueda, se infiere una problemática común dentro de esta esfera.
Generalmente, la principal problemática que se plantean los motores de búsqueda, buscadores empresariales, buscadores basados en directorios o catálogos, e inclusive, los recuperadores de información, es: ¿bajo qué criterios ordenar la información encontrada para mostrar las más relevantes en los primeros lugares?, para lo cual, diseñan e implementan poderosos algoritmos de ponderación . Sin embargo, la problemática anterior no está entre los objetivos o las necesidades fundamentales del RI del SIGEP. Para este último, lo principal no es cómo se ordenará la información para mostrar primero la más relevante, sino tener la información que cumpla con los criterios de búsqueda, y fundamentalmente con comportamientos que permitan realizar determinadas acciones sobre la misma.
El RI no se basa sólo en simples consultas donde se escogen los elementos que coinciden con un determinado criterio, sino que a veces, es necesario que cumpla con ciertos comportamientos muy específicos para dichos elementos.
Para conseguir que el RI ofrezca resultados adecuados, éste debe de ser adaptado a las necesidades de información del SIGEP, y a las características de su información. Por tanto, el RI debe de ser continuamente adaptado.
Partiendo de lo anterior, y teniendo en cuenta la necesidad de desarrollar un Recuperador de Información que brinde funcionalidades de búsqueda, se concluye que se hace necesaria la implementación de un módulo o componente reutilizable cuya funcionalidad fundamental es la Recuperación de Información almacenada en las bases de datos del SIGEP.
El Recuperador de Información, permitirá que los demás módulos de la aplicación se relacionen con él, enviándole los criterios de búsqueda además de otros parámetros necesarios para tomar decisiones en cuanto a la forma en que va a ser mostrada la información y recibiendo los resultados de la búsqueda en forma de listados. Este componente utilizará las bases de datos del SIGEP y se guiará por las pautas de la arquitectura base definida para el desarrollo de dicho sistema, utilizando las herramientas propuestas para la implementación del mismo así como frameworks y librerías usadas.
Figura 3 El Recuperador de Información expone sus funcionalidades mediante una fachada.
Aporte de la solución, beneficios, resultados
Con el diseño y la implementación del RI, como un componente reutilizable capaz de realizar búsquedas de personas dentro del penal, se da solución a las necesidades de funcionalidades de búsqueda de los diferentes módulos y subsistemas de la aplicación.
Se provee una herramienta reutilizable y extensible, que se adapta a las necesidades de información del SIGEP.
TÉCNICAS, MÉTODOS Y HERRAMIENTAS USADAS
Plataforma J2EE
J2EE (Java 2 Platform, Enterprise Edition) define un estándar para el desarrollo de aplicaciones empresariales multicapa. La plataforma J2EE simplifica las aplicaciones empresariales basándolas en componentes modulares estandarizados, proporcionando un conjunto completo de servicios a esos componentes, y manejando muchos detalles del comportamiento de las aplicaciones automáticamente, sin programación compleja.
La tecnología Java 2 Enterprise Edition (J2EE) proporciona una completa y potente plataforma orientada al desarrollo de aplicaciones corporativas distribuidas y a los servicios web. La misma integra un conjunto de APIs, frameworks y patrones de programación que permiten responder de una forma robusta y flexible a todas las demandas de este tipo de aplicaciones.
Entorno de Desarrollo
El Entorno de Desarrollo es donde se define cómo se va a desarrollar el Software, se define la plataforma, el lenguaje, herramientas y tecnologías que van a ser usadas. Existen Softwares que integran dichas herramientas y tecnologías y se le conoce como Entorno de Desarrollo Integrado (IDE).
Entorno de Desarrollo Integrado (IDE) Eclipse
Un Entorno de Desarrollo Integrado o en inglés Integrated Development Environment (IDE) es un programa compuesto por un conjunto de herramientas para un programador.
Puede dedicarse en exclusiva a un sólo lenguaje de programación o bien, poder utilizarse para varios.
Eclipse está escrito en Java y su principal uso es como IDE para Java, sin embargo, éste es un lenguaje neutral. El soporte para desarrollo en Java es proveído por un componente enchufado o pluggin, pero además están disponibles pluggins para otros lenguajes, como C/C++, Cobol, C#
(PIMENTEL and RIVERO 2007). En principio permite ejecutar un programa sobre cualquier plataforma.
Es una extensible plataforma de código abierto (open source) para desarrollar herramientas.
Lenguaje de Programación Java
Java es un lenguaje multiplataforma, orientado a objetos que proporciona una colección de clases rica para su uso en aplicaciones de red. Es un lenguaje robusto que fue diseñado para crear software altamente fiable. Se considera un lenguaje seguro dado que no accede a zonas delicadas de memoria o del sistema.
Frameworks y Tecnologías Utilizados
Un framework es una mini-arquitectura reutilizable que provee una estructura y un comportamiento genéricos para una familia de abstracciones de software, junto con un conjunto de metáforas que especifican sus colaboraciones y su uso dentro de un dominio dado. (KAISLER 2005)
Generalmente no es una aplicación completa, sino que carece de funcionalidades específicas de la aplicación, sin embargo, puede incluir un conocimiento considerable del dominio, embebido en su
especializar determinadas clases e invocar un simple método o procedimiento para determinadas funcionalidades, el resto del trabajo lo lleva a cabo el framework, invocando métodos o llamadas a clientes cuando sea necesario.
Spring Framework
Spring Framework es un framework de aplicación de código abierto que ayuda a hacer el desarrollo en JEE mucho más fácil. Ayuda a estructurar aplicaciones completas en una manera consistente y productiva para crear arquitecturas coherentes. (JOHNSON 2005)
Es el más popular y el más ambicioso de todos los framework de peso ligero. Es el único framework que interviene en todas las capas arquitectónicas de una aplicación JEE. Además está diseñado para facilitar una flexibilidad arquitectónica. (JOHNSON 2005)
Presenta varios módulos, de los cuales los principales son (JOHNSON 2005):
Contenedor de Inversión de Control.
Framework para la programación orientada a aspectos (AOP).
Abstracción de Acceso a Datos.
Simplificación de JSBC.
Administración de transacciones.
Framework Web MVC.
Simplificación para trabajar con JNDI, JTA y otros APIs de JEE.
Comunicación Remota de Peso Ligero (Lightweight remoting).
Soporte para servicio de mensajería de Java (Java Message Service, JMS).
Soporte para Java Management Extension (JMX):
Soporte para comprensivas estrategias de pruebas para desarrolladores de aplicación:
Hibernate Framework
Hibernate es un potente framework de mapeo objeto/relacional y servicio de consultas para Java. Es la solución ORM (Object-Relational Mapping) más popular en el mundo Java. Permite diseñar objetos persistentes que podrán incluir polimorfismo, relaciones, colecciones, y un gran número de tipos de datos. De una manera muy rápida y optimizada podremos generar BBDD en cualquiera de los entornos soportados: Oracle, DB2, MySQL, etcétera.
Sus principales características son: (BAUER-KING)
• Permite expresar consultas utilizando SQL nativo o consultas basadas en criterios.
• Soporta todos los sistemas gestores de bases de datos SQL y se integra de manera elegante y sin restricciones con los más populares servidores de aplicaciones J2EE y contenedores web, y por supuesto también puede utilizarse en aplicaciones de escritorio.
• Puede operar proporcionando persistencia de una manera transparente para el desarrollador.
• Soporta el paradigma de orientación a objetos de una manera natural: herencia, polimorfismo, composición y el framework de colecciones de Java.
• Soporte para modelos de objetos con una granularidad muy fina. Permite una gran variedad de mapeos para colecciones y objetos dependientes.
• Provee un sistema de caché de dos niveles y puede ser usado en un clúster. Permite inicialización perezosa (lazy) de objetos y colecciones.
• Proporciona el lenguaje HQL en cual provee una independencia del SQL de cada base de datos, tanto para el almacenamiento de objetos como para su recuperación.
• Presenta un potente mecanismo de transacciones de aplicación llegando incluso a permitir las interacciones largas (aquellas que requieren la interacción con el usuario durante su ejecución).
• Soporta los diversos tipos de generación de identificadores que proporcionan los sistemas gestores de bases de datos así como generación independiente de la base de datos, incluyendo identificadores asignados por la aplicación o claves compuestas.
API Criteria
Hibernate provee el API Criteria, que es una alternativa muy poderosa y elegante, bien adaptada para funcionalidades de búsqueda dinámica, donde deben ser generadas complejas consultas y donde son muy variadas las restricciones.
El API Criteria permite construir consultas programáticamente creando y combinando objetos en el orden correcto, convirtiendo de manera muy eficiente en código SQL, las restricciones, uniones, y proyecciones.
Características generales del API Criteria:
Usa un conjunto de objetos Java para construir consultas en vez de usar SQP puro.
Permite escribir consultas anidadas y estructuradas en lenguaje Java
Posibilita el chequeo de sintaxis en tiempo real
Soporta consultas basadas en ejemplos, es decir, construye consultas dado un objeto de ejemplo que contiene propiedades que se desean obtener.
Soporta métodos de agregación y conteo
Herramientas de modelado
ER/Studio
ER/Studio es una herramienta de modelado para diseñar bases de datos. Ayuda a descubrir, documentar y reutilizar los datos activos. Con un soporte de ida y vuelta de bases de datos, los arquitectos de datos tienen el poder para analizar las fuentes de datos existentes así como el diseño e implementación de bases de datos de alta calidad.
Esta herramienta ofrece las siguientes características: Ambiente de diseño orientado al modelo, soporte del ciclo de vida de bases de datos completas, administración del modelo empresarial, soporte para integración y almacenes de datos o data warehouse.
Visual Paradigm Suite
Visual Paradigm Suite es un conjunto de herramientas de modelado que permiten realizar el modelado dentro del proceso de desarrollo de software.
Una de las principales herramientas que posee es Visual Paradigm for UML Enterprise Edition, diseñada para un gran número de usuarios, incluyendo ingenieros de sistemas, analistas de sistemas, analistas de negocio, arquitectos de sistemas.
Presenta generación de código e ingeniería inversa del código. Permite generar los EJB y así mismo los descriptores de despliegue para varios servidores de aplicación. Distinto a muchas herramientas de modelado pueden extenderse sus diagramas hechos desde el Visio y de Rational Rose. Soporta la última versión de UML 2.0
Gestor de Bases de Datos Oracle
Es un sistema de gestión de bases de datos relacional (o RSBMS por el acrónimo en inglés de Relational Data Base Management System), fabricado por Oracle Corporation.
Se considera a Oracle como uno de los sistemas de bases de datos más completos, destacando su Soporte de retransacciones, Escalabilidad, Estabilidad, y sus funcionalidades multiplataforma.
Pluggins Subclipse
Subclipse es un pluggin para Eclipse que adiciona integración para el control de versiones (Subversion, específicamente), permitiendo operaciones de sincronización, actualización, entre otras.
Permite bloqueos a recursos para que otros usuarios no puedan modificarlo. Dispone de una vista de comparación entre el recurso local y el remoto en caso que exista conflicto entre sus respectivas versiones. Muestra una vista del historial de versiones de los recursos con un conjunto de atributos de las acciones realizadas sobre el recurso.
Spring IDE
Spring IDE es un pluggin que sirve como interfaz de usuario gráfica para la configuración de los archivos usados por Spring Framework. Permite el completamiento de etiquetas, valores de atributos y elementos en estos archivos de configuración.
INTEGRACIÓN CON LA ARQUITECTURA
Según el documento de IEEE (Std -1471-2000), la definición oficial de Arquitectura de Software es la siguiente: “La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución. (KAISER 2005) “.
Patrones Arquitectónicos utilizados:
N-CAPAS
La arquitectura base del SIGEP establece el uso del patrón arquitectónico n-capas, el cual consiste en separar la aplicación en varias capas y ubicar en cada una de ellas los componentes correspondientes según sus responsabilidades.
En el caso particular del SIGEP, se decidió utilizar tres capas (Figura 4):
Capa de presentación:
En la capa de presentación, residirán todos los componentes que tengan como responsabilidad manejar la lógica de presentación de la información que se gestiona.
Para el trabajo en esta capa se utiliza el módulo SpringMVC del framework Spring.
Capa de Lógica de Negocio:
En la capa de lógica de negocio residirán todas las entidades de dominio y los componentes encargados de manejar la lógica de negocio de los mismos.
Se decidió encapsular toda la lógica de negocio de cada una de las entidades en una clase que llevará por nombre [NombreEntidad]Manager. Por ejemplo, para la entidad Individuo, se creará una interfaz llamada IndividuoManager con la responsabilidad de manejar toda la lógica de la misma.
Capa de Acceso a Datos
En la capa de acceso a datos residirán todos los componentes encargados de manejar la lógica de persistencia y acceso a datos de la aplicación. Para cada entidad persistente se creará una interfaz llamada [NombreEntidad]DAO con los métodos necesarios.
Figura 4 Capas lógicas de la Arquitectura Base del SIGEP Modelo Vista Controlador
El objetivo fundamental del uso del patrón MVC es delegar en una clase controladora la responsabilidad de manejar el flujo de eventos y a su vez, delegar en las vistas, la responsabilidad de mostrar los datos del modelo.
El módulo SpringMVC, tal y como sugiere su nombre, implementa el patrón Modelo Vista Controlador, proporcionando interfaces y clases que pueden ser implementadas y heredadas para crear clases controladoras de eventos y responsables de decidir en qué elementos de la vista se mostraran los datos del modelo.
Patrones de Diseño Utilizados en la Arquitectura Base
La arquitectura base, impone el uso de dos patrones bien conocidos:
Fachada: Perteneciente al grupo de patrones estructurales de GoF.
DAO (Data Access Object) Perteneciente al grupo de patrones de integración de CORE.
Fachada:
El objetivo fundamental de la aplicación del patrón Fachada, es simplificar el acceso a un grupo de objetos relacionados, proporcionando un objeto de comunicación de alto nivel.
Una fachada, conoce qué componentes son responsables de qué peticiones y así, es capaz de delegarlas a los componentes apropiados.
En el Sistema se utilizará el patrón Fachada para exponer todas las funcionalidades de la capa de lógica de negocio que serán utilizadas por los componentes de la capa de presentación. Dicha fachada será utilizada como la única vía de comunicación entre las dos capas antes mencionadas. Los objetos pertenecientes a la capa de lógica de negocio, no tienen ninguna visibilidad hacia la fachada. Todos los componentes de la capa de presentación que necesiten los servicios de la capa de lógica de negocio, tendrán visibilidad directa hacia la fachada.
DAO (Data Access Object)
El objetivo fundamental del uso del patrón DAO es abstraer y encapsular el acceso a la fuente de datos. Un objeto DAO tiene la responsabilidad de establecer la conexión con la fuente y manejar la lógica de persistencia y acceso a la misma.
En el Sistema se utilizará el patrón DAO para encapsular toda la lógica de persistencia y acceso a datos de cada una de las entidades persistentes, creando para esto una interfaz que llevará por nombre [NombreEntidad]DAO, la cual permitirá acceder a los datos de forma abstracta.
Patrones utilizados en la implementación del buscador Builder Perteneciente al grupo de patrones de creación de GoF.
El objetivo fundamental del uso del patrón Builder es abstraer y encapsular la lógica de creación de un objeto complejo que debe ser creado a partir de sus partes.
La separación o independencia entre el proceso de construcción y la representación del producto fomenta la reutilización, puesto que permite que diferentes directores construyan variantes de un producto a partir del mismo conjunto de partes.
Se favorece el encapsulamiento y el control, puesto que cada constructor concreto contiene el código necesario para crear y ensamblar determinadas partes de un producto y además el constructor crea el producto paso a paso (parte a parte) bajo la supervisión del director, que al final recibe el producto completo, de manos del constructor.
En el RI, el patrón Builder fue utilizado en la creación de la consulta de búsqueda. En el mismo, determinadas clases se encargan de adicionar las restricciones según criterios por los que se debe filtrar la información. Estas clases son controladas por otras, llamadas “constructores de módulos”, que deciden, a qué clase (constructor de criterio) le corresponde construir cada parte de la consulta.
Herramientas y tecnologías usadas en la arquitectura
Además de las herramientas y tecnologías usadas durante el desarrollo del RI, expuestas en este documente, la Arquitectura Base para el desarrollo del SIGEP propone:
Herramientas
Web Tool Platform (WTP)
Hibernate Tools
AspectJ Development Tools (AJDT)
Contenedor Web o Apache Tomcat
Frameworks
o Acegi Security System o AspectJ
o JUnit o Ehcache
Tecnologías:
o Programación Orientada a Aspectos
FLUJO DE TRABAJO
Flujo de trabajo del Desarrollador del RI
Definir las interfaces de la fachada, el manager, y los DAOs.
Representar las relaciones entre la fachada, el manager y los DAOs en un diagrama de clases.
Declarar la interfaz de la fachada, el manager y los DAOs.
Identificar las estrategias de búsqueda.
Identificar los manejadores de la estrategia de búsqueda.
Identificar los constructores de criteria de cada manejador.
Representar las relaciones entre las estrategias, manejadoras y constructoras de criteria en un diagrama de clases.
Implementar y configurar en el xml de configuración, la fachada y el manager.
Implementar y configurar en el xml de configuración los DAOs.
Configurar en el xml de configuración las estrategias, manejadores y constructores de criteria.
Implementar las estrategias de búsqueda, los manejadores y los constructores de criteria.
Realizar pruebas unitarias.
Figura 5 Flujo de trabajo.
DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA
Para la implementación del Recuperador de Información (RI), se elaboró el diseño siguiendo la arquitectura base definida para el desarrollo del SIGEP teniendo en cuenta su división por capas.
El RI expone sus funcionalidades a través de una fachada que le permite al resto de los componentes del sistema, acceder a aquellas que resulten necesarias.
La fachada, expone métodos que le permiten a quien los invoca obtener los resultados correspondientes a la búsqueda de la información deseada, recibiendo como parámetros los criterios que deben tenerse en cuenta durante el proceso de recuperación. El objetivo de la utilización de la fachada es brindar una interfaz abstracta al resto de los módulos y subsistemas del SIGEP y garantizar el bajo acoplamiento al no requerir que los interesados en recuperar información, conozcan los componentes internos del buscador, dicho de otra manera, la fachada brinda una única vía de comunicación entre cualquier componente del sistema y el buscador.
El buscador posee un „manejador‟ de la lógica de recuperación, donde se validan y ejecutan operaciones relacionadas con los criterios de búsqueda en caso de ser necesario. Dicho manejador se nombra BusquedaCentralManager.
El manejador está relacionado con los DAOs los cuales son responsables del acceso a los datos, garantizando una abstracción total de la fuente de donde estos provienen y de la manera en que se obtienen.
Cada DAO, recibe como entrada un objeto command (BusquedaCommand), que encapsula varias de las entradas iniciales recibidas por la fachada, tales como: criterios de búsqueda, entidad de la que se requiere información, entre otras necesarias para la elaboración de la consulta. Una vez que el DAO crea la primera parte de la consulta, determina, mediante una de las propiedades del command, qué objeto será el encargado de desencadenar el proceso de construcción de las partes restantes de la misma. (Estrategia de Búsqueda).
La Estrategia de Búsqueda es una clase que implementa la interfaz SearchStrategy, cada implementación de dicha interfaz, está constituida por un conjunto de Constructores de Módulos, clases que implementan la interfaz ModuleBuilder, de las cuales selecciona las correspondientes a la obtención de determinadas partes de la consulta. Los Constructores de Módulos, a su vez, están constituidos por Especialistas o Estrategias (clases que implementan la interfaz CriteriaSpecialist), que ayudan a hacer más específicas las restricciones sobre los datos buscados y no necesariamente tienen que coincidir con los módulos de los subsistemas de la aplicación. Los especialistas, son los que realizan directamente el trabajo con los filtros, que representan propiedades de entidades, las cuales están mapeadas con campos de las tablas en la base de datos, en dichos especialistas se crean las restricciones de la consulta en construcción, siendo ellas, las que establecen relaciones (inner join o left join) con otras entidades cuando es necesario, además de determinar si el tipo de asociación entre los filtros es una conjunción (and) o una disyunción (or), funcionalidad indispensable para la correcta selección de los datos resultantes.
Los Constructores de Módulos se encargan de determinar qué especialista debe crear cada parte de la consulta según los criterios de búsqueda o los filtros por los que debe estar formada la misma.
Una vez que los especialistas y los constructores de módulos terminan de construir la parte de la consulta que le corresponde, la Estrategia de Búsqueda lleva a cabo el proceso de ensamblar y acoplar las partes, dando como resultado una consulta con los criterios y las restricciones apropiadas.
La consulta se construye usando el API de Criteria del Framework Hibernate.
Una vez creada la consulta, agregando y ensamblando las restricciones necesarias, se procede a agregar las proyecciones, que no son más que los campos o propiedades de los objetos buscados.
Esto último es responsabilidad del DAO.
Posterior a la ejecución de la consulta final, se verifica si es necesario realizar operaciones sobre los datos encontrados, en caso positivo se llevan a cabo dichas operaciones para devolver, finalmente, un listado con los objetos resultantes.
Diagrama de Clases del Diseño
Figura 7 Fachada de Búsqueda y Manager de Búsqueda
Figura 8 Relación del Manager de Búsqueda con los DAOs
Figura 9 Dependencia de los DAOs con las estrategias.
Figura 10 Estrategias de Búsqueda.
Figura 11 Constructores de Módulos
Figura 12 Especialistas
Figura 13 Dependencia de los especialistas con BusquedaCommand.
Figura 14 Dependencia de las especialidades con la clase útil de restricciones (CriteriaUtil).
Descripción de las clases
Fachada de Búsqueda
Nombre BusquedaFacade
Descripción Interfaz que expone las funcionalidades de búsqueda a otros componentes de la aplicación. Implementa el Patrón de Diseño Interface, definido en la arquitectura base del SIGEP.
Nombre BusquedaFacadeImpl
Descripción Clase que implementa las funcionalidades de la interfaz BusquedaFacade Patrón de Diseño Facade, definido en la arquitectura base del SIGEP.
Manager de Búsqueda
Nombre BusquedaCentralmanager
Descripción Interfaz que contiene las funcionalidades de negocio.
Nombre BusquedaCentralManagerImpl
Descripción Clase que implementa las funcionalidades de negocio de
BusquedaCentralManager.
DAOs.
Son los encargados del acceso a datos, es donde comienza la creación de la consulta y es donde finalmente se ejecuta la misma. Implementa el Patrón de Diseño de CORE denominado DAO, definido en la arquitectura base del SIGEP.
Nombre BusquedaIndividuoDAO
Descripción Interfaz que encapsula la implementación de la funcionalidad de acceso a los datos de Individuo.
Nombre BusquedaIndividuoDAOImpl
Descripción Implementa la interfaz BusquedaindividuoDAO y sus funcionalidades de acceso a datos.
Estrategia de Búsqueda
Nombre BusquedaStrategy
Descripción Interfaz del motor de búsqueda.
Nombre BusquedaStrategyImpl
Descripción Implementa la interfaz BusquedaStrategy, contiene las estrategias de búsqueda y de ellas decide cuál manejará.
Constructor de Módulo
Nombre ModuleBuilder
Descripción Interfaz que expone y abstrae funcionalidades dentro de la creación de la consulta de búsqueda. Implementa (en conjunto con las clases que implementan sus funcionalidades) el patrón de diseño Builder.
Especialista de Criteria
Nombre CriteriaSpecialist
Descripción Interfaz que expone y abstrae la funcionalidad de crear las restricciones a la consulta.
Modelo físico de datos.
Figura 15 Modelo físico de datos .
CONCLUSIONES
Con el resultado del trabajo se concibió, para el Sistema de Gestión Penitenciaria, el diseño y la implementación de un mecanismo de búsqueda común, guiado por las pautas de la arquitectura base del SIGEP, que da solución a las necesidades de recuperación de información de los diferentes módulos y subsistemas de la aplicación, cumpliéndose así, el objetivo general propuesto para este trabajo: Desarrollo del Recuperador de Información para el Sistema de Gestión Penitenciaria.
Para la creación del RI del SIGEP, fue necesario realizar un estudio general sobre Patrones de Diseño, profundizar en el uso de herramientas de acceso a datos además de investigar sobre la existencia de otros recuperadores de información.
Dado que el Recuperador de Información se usa actualmente en el SIGEP de forma satisfactoria, y sin dejar de pensar en variantes de diseño e implementación para mejorar esta herramienta, se concluye que la realización del mismo ha sido exitosa, por lo que tanto el objetivo general del trabajo como la realización de las tareas fundamentales para llevarlo a cabo de forma satisfactoria, han sido cumplidos.
RECOMENDACIONES Se recomienda:
Continuar con el desarrollo del Recuperador de Información.
Perfeccionar el diseño del Recuperador de Información haciendo uso de los Patrones de Diseños de GoF.
Perfeccionar la construcción de las consultas haciendo uso del API Criteria en conjunto con consultas HQL para lograr resultados más eficientes en cuanto al tiempo de respuesta.
Crear herramientas que faciliten el uso del Recuperador de Información y su integración con aplicaciones diversas de gestión.
BIBLIOGRAFÍA
Cómo funciona un motor de búsqueda. 2008]. Disponible en:
http://www.pisitoenmadrid.com/blog/2007/04/como-funciona-un-motor-de-busqueda/
Hibernate-Angel_Luis_Calvo_Ortega.pdf. 2008]. Disponible en:
http://ditec.um.es/ssdd/trabajos/0506/Hibernate-Angel_Luis_Calvo_Ortega.pdf
Java2 Platform, Enterprise Edition (J2EE). 2008]. Disponible en: http://java.sun.com/j2ee/overview.html Patrones de Diseño, Análisis y Diseño, Ingeniería de Software. 2008]. Disponible en:
http://www.ingenierosoftware.com/analisisydiseno/patrones-diseno.php
Tipos de buscadores - Comercio electrónico - ylos.com. 2008]. Disponible en:
http://www.ylos.com/spa/item/tipos.html
WebCrawlers: Motores de Búsqueda 2008]. Disponible en:
http://www.osmosislatina.com/aplicaciones/robots.htm
(BAUER-KING) BAUER, C. and G. KING. Hibernate in Action. p. 1932394-15-X (BAUER-KING 2006) ---. Manning Java Persistence with Hibernate. 2006. p.
(GoF) GOF. Design Patterns. p.
(JOHNSON 2005) JOHNSON, R. Professional Java Development with the Spring Framework. 2005.
672 p. 0764574833
(KAISLER 2005) KAISLER, S. H. Software Paradigm. p.
(WALLS- BREIDENBACH) WALLS, C. and R. BREIDENBACH. Spring in Action. p. 1-932394-35-4 (PIMENTEL and MARTÍNEZ 2007) PIMENTEL, L. A. and J. E. MARTÍNEZ. Documento de
Arquitectura. Habana, Universidad de las Ciencias Informáticas, 2007. p.
(PIMENTEL and RIVERO 2007) PIMENTEL, L. A. and I. P. RIVERO. ArBaWeb: ARQUITECTURA BASE PARA LA WEB. Habana, Universidad de las Ciencias Informáticas, 2007. p.
GLOSARIO
Recuperación de Información: En el contexto del documento se refiere a información almacenada en la base de datos (en este caso del SIGEP), la cual puede ser localizada mediante consultas SQL, vistas o funciones dentro del mismo gestor de Bases de Datos.
