solicitud de obras en digibepe - koha

INSTITUTO DE INFORMÁTICA IdeI

Facultad de Ciencias Exactas Físicas y Naturales

UNIVERSIDAD NACIONAL DE SAN JUAN

Meglioli 1156 – Rivadavia - San Juan – 5415 - Tel. +54 0264 4234129 Fax +54 0264 4265101

Ticket de solicitud de obras en Koha

Lic. Cristina Vera; Prog. Luis A. Olguin

{cvera;[email protected]}

Instituto de Informática

Facultad de Ciencias Exactas, Físicas y Naturales

Universidad Nacional de San Juan

Resumen

Las bibliotecas de la Universidad Nacional de San Juan se encuentran evaluando la aplicación del

software libre Koha con el objetivo de actualizar los sistemas de gestión bibliotecaria que poseen

y adecuarlos así a las nuevas realidades tecnológicas.

En particular la biblioteca “Max Planck” de la Facultad de Ingeniería posee instalada una aplicación

propietaria que le permite al operador del sistema realizar “pedidos de obras para préstamo”

desde el área de circulación al depósito, que se encuentra en otro piso del edificio, generando la

impresión de un “ticket de solicitud” que posibilita la búsqueda y envío del material al usuario.

La Biblioteca Popular Franklin de San Juan posee el mismo escenario en el área de préstamo, un

depósito de obras en un piso distinto al que el usuario realiza la solicitud. La reciente adhesión de

esta biblioteca al software de DIGIBEPE (CONABIP), que se basa en Koha, genera la misma

problemática: contar dentro de Koha con la posibilidad de generar e imprimir los “ticket de

solicitud de obras”.

En virtud de estas realidades, desde el Instituto de Informática se ha desarrollado una aplicación

utilizando lenguaje Perl que, agregada a la página de despliegue de resultados de una búsqueda

en Koha, permite al operador del sistema “solicitar la obra al depósito”, tal cual lo hacen ahora

con la aplicación propietaria.

El presente trabajo muestra los pasos de análisis, diseño e implementación realizados para

satisfacer este requerimiento de las bibliotecas sanjuaninas.

Palabras claves

MARC21, KOHA, DIGIBEPE, PERL, BIBLIOTECAS-AUTOMATIZACIÓN





1. Introducción La biblioteca “Max Planck” perteneciente a la Facultad de Ingeniería de la Universidad Nacional de San Juan (UNSJ), dispone actualmente de un sistema de gestión bibliotecaria (BOOK´s) desarrollado por el Instituto de Informática de la Facultad de Ciencias Exactas, Físicas y Naturales (IdeI) [1]. Actualmente esta biblioteca está evaluando el software libre KOHA [2] con el fin de reemplazar a BOOK´s como parte del plan de actualización tecnológica. Uno de los “módulos centrales” del sistema actual es el “Generador de Tickets de solicitud de Obras”, a cuenta que por su disposición física, la biblioteca tiene separadas las áreas de referencia (Plata baja del edificio) del “depósito de ejemplares” (Subsuelo del edificio). En la actualidad, KOHA no dispone de un módulo para “solicitud de obras en depósito” por lo que se requiere el análisis, diseño e implementación de esta funcionalidad entre las tareas a realizar antes de completar la migración de sistema.

2. Proceso de “Solicitud de Obras” para préstamo La solicitud de obras por parte de un usuario se puede resumir de la siguiente manera: En el “Área de recepción de solicitudes y consultas” se dispone de un mostrador de referencias desde el cual el bibliotecario, a solicitud de un usuario, consulta la disponibilidad de una obra mediante el software Wbardic [3] Una vez localizada la obra solicitada, si esta se encuentra con ejemplares para préstamo (al menos 1 ejemplar del título), el bibliotecario “cliquea” sobre el Botón “solicitar obra” del buscador y procede a completar el formulario de solicitud (“Nombre del usuario” y “Tipo de solicitud” (“sala” o “domicilio”)). Completados estos datos el bibliotecario confirma la solicitud y el sistema genera el “ticket de solicitud de obra” que se imprime en la impresora destinada para tal fin en el depósito de ejemplares. Este “ticket” contiene “Título de la obra”, “Autor”, “Signatura Topográfica” (ubicación de la obra en la estantería), “Nombre del usuario que solicita”, “Tipo de solicitud” (sala o domicilio). Los tres primeros datos del ticket son tomados de la base de datos catalográfica (LIBRI). No es necesario que el “usuario” sea socio de la biblioteca para realizar una solicitud.





Este ticket es derivado al responsable del “envío de ejemplares”, quien buscará en las estanterías el título solicitado y al encontrarlo lo envía por un montacargas hacia el área de “entrega de obras para préstamo” junto con el ticket que identifica al usuario que solicitó la obra. En caso de no encontrase el título solicitado, el ticket se sella con la leyenda “Verificar ubicación” a fin de indicar la anomalía y se envía el ticket hacia el área de “entrega de obras para préstamo”. Al recepcionar el ejemplar con el ticket de pedido, el encargado de préstamos entrega la obra al usuario quien decidirá si efectiviza la solicitud o no. En caso de confirmarse el préstamo, el encargado de préstamos realizará el procedimiento pautado para tal acción en el sistema.

Proceso de solicitud de obra para consulta/préstamo





3. Desarrollo del software solicitado El proceso de desarrollo de software, materia de estudio de la ingeniería de software, tiene como propósito “la producción eficaz y eficiente” de un producto que reúna las necesidades del “cliente”.

Requisitos nuevos

o modificados

Sistema nuevo

o modificadoProceso de Desarrollo

de Software

Requisitos nuevos

o modificados

Sistema nuevo

o modificadoProceso de Desarrollo

de Software

En nuestro caso, la biblioteca Max Planck solicita como “nuevo requisito” la inclusión de la funcionalidad “Solicitud de Obra” en el despliegue de resultados de búsqueda de una obra, dentro de las opciones de “Intranet de Koha”. Además solicita que como resultado de la aplicación de esta nueva funcionalidad, se obtenga un “ticket impreso” con un tamaño de formulario personalizado. Estas líneas anteriores son disparadoras de una serie de actividades para cumplimentar el desarrollo del software:

1 Especificación de requisitos: se declaran en forma completa cómo será el comportamiento del sistema. Acá encontramos los “casos de uso” que describen las interacciones que tendrán los usuarios con el sistema. 2 Diseño del sistema: se definen los componentes, módulos y datos del sistema para satisfacer los requisitos solicitados. En esta etapa utilizamos diagramas de UML que es un estándar para el análisis y diseño de sistemas.

3 Implementación: Resultado del análisis y diseño (+programación) se obtiene el nuevo software que, en nuestro caso, “mejorará” las prestaciones del actual sistema. En esta etapa debemos asegurarnos que el sistema sea operacional, es decir funcione de acuerdo a los requerimientos del análisis y que sea utilizado por los usuarios.





3.1 Especificación de requisitos: Cómo técnica de captura de requisitos utilizamos “diagramas de casos de uso” y “plantillas de casos de uso” para documentarlos. “Un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.” [4] Mostramos a continuación una versión abreviada de las plantillas de caso de uso generadas para este proyecto.

Diagrama de Caso de Uso – Generar Ticket

Nº Campo Descripción del campo

1 Nombre CU: Generar listado de obras

2 Actor Bibliotecario

3 Tipo de

Asociación

4 Descripción: El sistema deberá comportarse tal como se

describe en el siguiente caso de uso cuando alguien

genere el listado de obras.

5 Precond.: Existen obras registradas.

6 Flujo de

Eventos:

El bibliotecario solicita comenzar la búsqueda de la obra ingresando la opción de búsqueda (palabra clave a buscar). [Mientras existan obras]

Se calcula cantidad de ejemplares de la obra e incorpora al listado. [La cantidad de ejemplares es mayor a cero]Se habilita el link solicitud de obra. Se muestra el listado generado en pantalla.

7 Frecuencia de

Uso:

Diaria (tantas veces por día como se necesite

generar el listado).

Plantilla de Caso de Uso – Generar listado de obras





Plantilla de Caso de Uso – Generar Ticket

Nº Campo Descripción del campo

1 Nombre CU: Generar Ticket

2 Actor Bibliotecario

3 Tipo de

Asociación

4 Descripción: El sistema deberá comportarse tal como se

describe en el siguiente caso de uso cuando

alguien genere el ticket de préstamo.

5 Precond.: Exista disponibilidad de ejemplares de la obra a

solicitar

6 Flujo de

Eventos:

El bibliotecario solicita generar el ticket de préstamo. Se solicitan los siguientes datos para completar el ticket: nombre de usuario y tipo de solicitud (sala o domicilio). [El ticket no está completo] Se solicita se complete el ticket de forma adecuada. [El ticket está completo] Se imprime el ticket.

7 Frecuencia

de Uso:

Diaria (tantas veces por día como se necesite

generar el ticket).





3.2 El Diseño del sistema

Utilizando herramientas de diseño, se genera el diagrama de clases y los diagramas de secuencias

que se basan en los flujos de datos documentados en las plantillas de casos de uso.

“Diagrama de clases: es un diagrama de estructura estática que muestra el conjunto de clases importantes que forman

parte de un sistema, junto con las relaciones existentes entre estas clases.” [5]

“Diagrama de secuencia: es un tipo de diagrama usado para modelar interacción entre objetos en un sistema. Muestra

la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso” [6]

Diagrama de clases

Diagrama de Secuencia Generar Ticket





Diagrama de secuencia Generar listado de obras

Diagrama de Secuencia Generar ficha de obra





3.3 Implementación

La implementación del “Ticket de préstamo” se realizó en lenguaje de programación Perl

utilizando entre otros, el módulo HTML::Template [7] para separar diseño (HTML) de datos (los

generados por perl).

Módulos para Intranet y Opac en KOHA

El software Koha está compuesto por dos áreas:

Intranet: interfaz de administración que permite la gestión de los contenidos del sistema bibliotecario.

Opac: es la sigla de On line Public Access Catalog, es decir catálogo publico abierto. Esta área es accedida por los usuarios del sistema (lectores, investigadores, etc).

Ambas comparten la estructura de módulos que proveen el comportamiento. Nuestra implementación utiliza los módulos declarados en Intranet. Cgi-bin y htdocs del área Intranet

Dentro del área Intranet, se encuentran los directorios cgi-bin y htdocs. El primero almacena los scripts de perl. Mientras que htdocs, contiene un subdirectorio denominado intranet-tmpl, que contiene el juego de templates que generan la interfase de KOHA. Además, de manejar los diferentes idiomas, entre otros.





Directorios de la Intranet en Koha

Módulo Catálogo

El sistema KOHA se divide o se puede diagramar en un conjunto de módulos, donde cada uno se ocupa de la administración de un área en particular. Esta división se puede ver más claramente en la Intranet que ofrece un menú de opciones que responde a cada uno de éstos conformando el núcleo del sistema KOHA y que proveen herramientas para la gestión de todo el funcionamiento de la biblioteca. El módulo empleado para implementar la nueva funcionalidad es el de Catálogo. El mismo permite realizar las búsquedas en sus diferentes criterios sobre todas las obras bibliográficas que contenga la biblioteca, junto con la posibilidad de visualizarlas de tres formas distintas (ficha catalográfica, Formato MARC, Etiquetada).





Organización del módulo Catálogo

Búsquedas a través de la interfaz administrativa de Koha (sesión Intranet)

A partir de la interfaz administrativa, es posible iniciar la búsqueda de una obra, especificando un criterio (por ej. “Geología”). Resultado de esta consulta se obtiene una listado de obras que incluyen un asiento bibliográfico y la ubicación topográfica. En la columna ubicación, se muestra además la disponibilidad de ejemplares para cada obra. La presentación del “resultado de la consulta” es manejada por Koha utilizando la plantilla results.tmpl, sobre este template hemos realizado nuestra modificación para incluir la posibilidad de generar el ticket.

Cambios realizados a results.tmpl Se agregó un nuevo enlace (link) denominado “Solicitar obra” que permite el envío de los datos de la obra seleccionada hacia el código perl que genera el ticket (idei_ticket.pl). Se envían como parámetros título, autor y signatura topográfica de la obra. Las siguientes líneas de código reflejan esto:

<a class="imprimir" href="/cgi-bin/koha/catalogue/idei_ticket.pl?title=

&author= &itemcallnumber=">Solicitar obra!!! </a>





Cambios realizados a detail.tmpl Si al realizar la consulta, el resultado es “solo una obra”, Koha utiliza para el despliegue del resultado otro template llamado detail.tmpl. Se insertaron en esta plantilla las mismas líneas de código agregadas a results.tmpl para imitar la funcionalidad.





Ficha bibliográfica de la obra





El script l idei_ticket.pl

La nueva funcionalidad se implementa a partir del enlace “solicitar obra” añadido a la lista de resultado (o ficha bibliográfica). El script idei_ticket.pl se encarga de derivar las tareas entre los templates idei_ticket1.tmpl e idei_ticket2.tml, que permiten “completar los datos del solicitante de la obra” e “imprimir la solicitud de la obra”, respectivamente.





El template idei_ticket1.tmpl (Formulario de solicitud)

Esta plantilla despliega en la pantalla del operador del sistema el “formulario de solicitud”, que incluye los datos de la obra (Título, Autor, Signatura topográfica) y solicita los datos del usuario (Nombre y Apellido) y el posible destino del préstamo (sala o domicilio).

Formulario de solicitud de obra

Para avanzar en la generación del ticket, se valida como “obligatorio” el nombre del usuario solicitante.





Cartel de alerta

Figura 1 Código de idei_ticket1.tmpl





El template Idei_ticket2.tmpl (Impresión del ticket)

Mediante este plantilla se genera el ticket de solicitud que será derivado hacia la impresora habilitada para tal fin en el depósito de obras de la biblioteca.

Código idei_ticket1.tmpl

El template idei_ticket2.tmpl (Impresión del ticket)

Mediante este plantilla se genera el ticket de solicitud que será derivado hacia la impresora habilitada para tal fin en el depósito de obras de la biblioteca.





Código de idei_ticket2.tmpl

Ticket de impresión





4. Conclusiones

Cómo parte de las tareas de relevamiento de requerimientos realizados en las bibliotecas de la

Universidad Nacional de San Juan, surge este particular caso solicitado por la biblioteca Max

Planck. Las etapas de análisis, diseño e implementación de esta solución a la problemática

planteada nos permitió abordar el estudio del código fuente de Koha, el uso del lenguaje Perl, los

módulos asociados a Perl, en particular el Template::Html usado por Koha.

Si bien esta biblioteca aún no ha decidido su migración hacia Koha, el contar ya con una

herramienta como la mostrada permitirá incluirla como una “fortaleza del nuevo sistema” al

momento de una futura migración.

Dado que la biblioteca Popular Franklin de San Juan posee el mismo sistema que las bibliotecas de

la UNSJ y sabiendo que es intención de esta Institución migrar hacia DigiBepe (sistema Koha

utilizado por las bibliotecas populares), se hace inmediata la transferencia de este trabajo hacia

una de las más importantes bibliotecas populares sanjuaninas y hacia todas aquellas bibliotecas

del país que presenten un escenario de préstamos como el descripto.

5. Referencias

[1] Instituto de Infromática – FCEFyN http://www.idei-unsj.com.ar

[2] Sitio web desarrollo Koha http://www.koha.org

[3] Módulo de consulta Wbardic http://www.slideshare.net/laounsj/wbardic-para-sigebi

[4] Casos de Uso http://es.wikipedia.org/wiki/Caso_de_uso [5] Diagrama de Clases http://es.wikipedia.org/wiki/Diagrama_de_clases

[6] Diagrama de Secuencia http://es.wikipedia.org/wiki/Diagrama_de_secuencia

[7] HTML::Template http://search.cpan.org/~samtregar/HTML-Template-2.9/Template.pm

solicitud de obras en digibepe - koha

Documents

solicitud de obras

san juan meglioli

san juan resumen

san juan unsj

ticket de solicitud

naturales universidad

pedidos de obras

proceso de solicitud