UNIVERSIDAD NACIONAL DE TRUJILLO

FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS

ESCUELA ACADEMICO PROFESIONAL DE INFORMTICA

SOFTWARE MULTIPLATAFORMA PARA CONTROLAR EL

PRSTAMO DE MATERIALES BIBLIOGRFICOS EN LAS
BIBLIOTECAS DE LA UNIVERSIDAD NACIONAL DE TRUJILLO

Tesis para Obtencin de Ttulo de Ingeniero Informtico

Autores

Burgos Urquizo, Royer

Chomba Valverde, Juan Carlos
Asesor

Ing. Carlos Castillo Diestra

24 de Setiembre de 2013
Trujillo, La Libertad

INDICE
1.

INTRODUCCIN ............................................................................................................ 1
1.1. Realidad Problemtica ................................................................................................ 1
1.2. Hiptesis ..................................................................................................................... 1
1.3. Objetivo General......................................................................................................... 2
1.4. Objetivos Especficos ................................................................................................. 2

2.

MATERIALES Y MTODOS ........................................................................................ 3

2.1. Enfoque. ...................................................................................................................... 3
2.2. Tipo de Investigacin ................................................................................................. 3
2.3. Poblacin y Muestra. .................................................................................................. 3
2.4. Instrumentos. .............................................................................................................. 4
2.5. Procedimientos. .......................................................................................................... 5
2.6. Mtodos y Procedimientos para la Recoleccin de Datos. ......................................... 5
2.7. Anlisis Estadstico de Datos ..................................................................................... 5
2.8. Metodologa De Desarrollo del Software ................................................................... 6

3.

2.8.1.

Anlisis de Requerimientos............................................................................ 6

2.8.2.

Diseo del Sistema Solucin .......................................................................... 6

2.8.3.

Implementacin del Sistema. ......................................................................... 7

2.8.4.

Pruebas. .......................................................................................................... 7

2.8.5.

Despliegue del Sistema .................................................................................. 7

Resultados ......................................................................................................................... 8
3.1. Marco Terico ............................................................................................................ 8
3.1.1.

Conceptos Bsicos. ........................................................................................ 8

3.1.2.

Conceptos de Software ................................................................................. 10

3.2. Desarrollo de la Investigacin. ................................................................................. 23

3.2.1.

Requerimientos del Software ....................................................................... 23

3.2.2.

Diseo del Software ..................................................................................... 28

4.

Conclusiones .................................................................................................................... 31

5.

Referencia Bibliogrfica................................................................................................. 32

INDICE DE FIGURAS
Figure 1: Estructura basica de una Libreria................................................................... 12
Figure 2: Arquitectura por Capas .................................................................................. 15
Figure 3: Factory Pattern .............................................................................................. 19
Figure 4: Template Method Pattern ............................................................................... 20
Figure 5: Composite Pattern.......................................................................................... 21
Figure 7: The facade Design Pattern.............................................................................. 23
Figure 8: Arquitectura y Componentes de la Aplicacion ................................................. 33
Figure 9: Modelo del Dominio ....................................................................................... 34
Figure 10: Entidad Prestamo......................................................................................... 34
Figure 11: Algoritmo de Prestamo ................................................................................. 35

INDICE DE TABLAS
Table 3: Caso de Uso Registrar Usuario ......................................................................... 30
Table 3: Caso de Uso - Registrar Libro .............................................................................. 30
Table 3: Caso de Uso - Prestar Libro ................................................................................. 31
Table 4: Caso de Uso - Retornar Libro .............................................................................. 31
Table 5: Caso de Uso - Renovar Libro ............................................................................... 32
Table 6: Caso de Uso - Reclamar Libro ............................................................................. 32

1. INTRODUCCIN
1.1. Realidad Problemtica
Las Bibliotecas de la Universidad Nacional de Trujillo poseen un sistema muy antiguo
que es prcticamente obsoleto ya que el prstamo de materiales se realiza de manera
manual, es decir el usuario tiene que llenar una pequea ficha en la cual anota el nombre
del material bibliogrfico, su cdigo o identificador, el nombre del alumno, el tipo de
uso (sala o domicilio), luego entrega la ficha al bibliotecario junto con su carnet y este
le entrega el material solicitado. Este proceso manual consume mucho tiempo, es muy
propenso a errores y requiere de mucho esfuerzo y disciplina por parte del bibliotecario.

Adems, debido al poco presupuesto que posee la universidad no se ha optado por

comprar un software propietario debido a su elevado costo y la infraestructura
tecnolgica que demanda para su implementacin, optando finalmente por seguir
realizando este proceso manualmente.

Problema.
Cmo controlar los materiales bibliogrficos en las bibliotecas de la universidad
nacional de Trujillo?
1.2. Hiptesis
La hiptesis planteada fue la siguiente:
El Desarrollo de un software multiplataforma permitir controlar el prstamo de
materiales bibliogrficos.

Variable Independiente : Desarrollo de un software multiplataforma

Indicadores: Usabilidad, Confiabilidad

Variable Dependiente : Controlar el prstamo de recursos bibliogrficos

Indicadores: Satisfaccin del usuario, Desempeo del Personal

1.3. Objetivo General

El objetivo general de este trabajo es:

Desarrollar un software multiplataforma para controlar el prstamo de

materiales bibliogrficos.

1.4. Objetivos Especficos

Los Objetivos especficos de este trabajo son:

Analizar el problema mediante tcnicas de gestin de requerimientos.

Disear el sistema mediante el uso del lenguaje de modelado UML y patrones

de diseo.

Desarrollar el sistema usando una arquitectura por capas y orientada a

servicios.

Realizar pruebas de casos de uso.

Simular el prstamo de materiales bibliogrficos utilizando el software

desarrollado en un ambiente controlado.

2. MATERIALES Y MTODOS
2.1. Enfoque.
El enfoque que tendr el desarrollo del software ser predominantemente cualitativo
debido a la cualidad de software que se desarroll y predominante cuantitativo debido a
que los usuarios y el personal de la biblioteca calificaran la utilidad que tuvo este
software.

Los niveles de investigacin que se llevaran a cabo en este trabajo sern:

-

Exploratorio: Porque permitir sondear el problema en un contexto muy

particular.

Descriptivo: Porque permitir comparar entre dos o ms fenmenos, situaciones

y estructuras, es decir permitir predicciones rudimentarias y de medicin
precisa

2.2. Tipo de Investigacin

Por tratarse del desarroll de un software dirigido a solucionar un problema se llevara a
cabo una investigacin de campo del proceso a automatizar, es decir la observacin
directa del proceso, la recopilacin de informacin y anlisis del material bibliogrfico.
Por tanto, la investigacin del presente proyecto es de tipo bibliogrfica y documental.
2.3. Poblacin y Muestra.
La poblacin que se va a considerar en la presente investigacin ser la totalidad del
personal que actualmente labora en la biblioteca de la Facultad de Ciencias Fsicas y
Matemticas y quienes hacen uso de este servicio de prstamo de materiales
bibliogrficos como son los estudiante de la escuela de Ingeniera Informtica, Fsica y
Matemtica.
.

Para la obtencin del tamao de muestra a dicha poblacin se aplicara la siguiente

formula:

Dnde:
n = Tamao de la muestra =?
N = Tamao de la poblacin = 1500
e = Error mximo admisible = 0.1

Por lo tanto, se proceder a aplicar las encuestas a 94 estudiantes, adems se incluyen a

la totalidad de bibliotecarios, en vista que no es un nmero muy alto de encuestados, as
se lograr tener una idea ms clara de la opinin de los estudiantes de la escuela de
Ingeniera Informtica, Fsica y Matemtica.

2.4. Instrumentos.
Para la recoleccin de datos se usar:

Una grabadora de voz convencional.

Notas de Apunte (Lpiz y Borrador)

Formato de Entrevistas.

Para la prueba del software, se usar:

Impresora blanco-negro Laser HP1010

Lector de cdigos de barra estndar

Una computadora porttil marca Toshiba A500, procesador Core 2 Do

T850@2.16 GHz, 2167 MHz, 2procesadores, 4,00 GB de RAM

2.5. Procedimientos.
A continuacin se describe la secuencia de pasos que se utilizar para desarrollar la
presente investigacin:

1. Recoleccin, Procesamiento y Anlisis de la Informacin.

2. Elaboracin de la Realidad problemtica y Formulacin de Hiptesis.
3. Elaboracin del software para experimentacin.
4. Contrastacin de Hiptesis y Evaluacin de Resultados.
5. Documentacin del informe.
2.6. Mtodos y Procedimientos para la Recoleccin de Datos.
La recoleccin de informacin se realizar mediante observacin directa del
funcionamiento de la biblioteca y conversaciones con el personal administrativo, para
as determinar el problema que queremos solucionar
2.7. Anlisis Estadstico de Datos
El anlisis de la informacin consistir en la interpretacin y procesamiento de los datos
recolectados, es decir, las entrevistas. Las cuales despus de ser procesados servirn
para dar solucin al problema planteado. Esta etapa incluye:

1. Revisin y Codificacin de la Informacin

2. Categorizacin y Tabulacin de la Informacin

Tabulacin Manual

3. Anlisis de los datos

La presentacin de los datos se lo har a travs de los datos, cuadros para

analizarlos e interpretarlos.

4. Interpretacin de los Resultados

Describir los resultados

Redactar una sntesis general de los resultados

2.8. Metodologa De Desarrollo del Software

Para el presente proyecto utilizaremos la metodologa de desarrollo de software llamada
Modelo en Cascada (Waterfall Model) propuesta por primera vez por Winston W.
Royce en el ao 1970, esta metodologa incluye las siguientes fases:
2.8.1. Anlisis de Requerimientos.
Durante esta fase se analizan las necesidades de los usuarios finales del software para
determinar qu objetivos cumplir. De esta fase surge documentacin que contiene la
especificacin completa de lo que debe hacer el sistema a un alto nivel de atraccin. En
esta fase se llevan a cabo tcnicas de recopilacin de requerimientos tales como
entrevistas, reuniones de requerimientos con los usuarios y equipo de desarrollo;
adems se definen las caractersticas del sistema en un documento Visin y
requerimientos funcionales en un modelo de casos de uso; adems se definen atributos
del sistema o requerimientos no funcionales del sistema tales como performance,
seguridad, flexibilidad.
2.8.2. Diseo del Sistema Solucin
Si la primera fase se complet con xito y se ha establecido un plan bien pensado para
el desarrollo de software, el siguiente paso consiste en formular el diseo bsico del
software. Como resultado surge el SDD (Documento de Diseo del Software), que
contiene la descripcin de la estructura relacional global del sistema y la especificacin
de lo que debe hacer cada una de sus partes, as como la manera en que se combinan
unas con otras.

Despus de que el diseo bsico se apruebe, a continuacin, se elabora un diseo

tcnico ms elaborado, es decir se disean los algoritmos necesarios para el
cumplimiento de los requerimientos del usuario as como tambin los anlisis
necesarios para saber que herramientas usar en la etapa de codificacin.
2.8.3. Implementacin del Sistema.
En esta fase, se implementa el cdigo fuente del sistema basado en los modelos creados
previamente en la fase de diseo, haciendo uso de prototipos as como pruebas y
ensayos para corregir errores. Dependiendo del lenguaje de programacin se crean
bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la
programacin sea un proceso mucho ms rpido. As mismo, se usan diferentes tcnicas
y patrones de diseo que permiten que el sistema sea escalable y flexible.
2.8.4. Pruebas.
En esta fase, Los elementos (mdulos) ya programados se ensamblan para componer el
sistema y se comprueba que funciona correctamente y que cumple los requisitos, antes
de ser entregado al usuario final. En esta etapa se utilizan los casos de uso previamente
desarrollados para comprobarlos mediante el uso de casos de prueba; Adems, se
realizan pruebas de seguridad y performance.
2.8.5. Despliegue del Sistema
Es la fase el software obtenido se pone en produccin. Se implantan los niveles software
y hardware que componen el proyecto. En esta etapa el usuario final ejecuta el sistema,
para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que
el sistema no falle. Es una de las fases finales del proyecto.

3. Resultados
En este punto se centra el desarrollo y ejecucin del plan de trabajo de graduacin, se
describe el marco terico y el desarrollo del software segn la metodologa trabajo
descrito anteriormente.
3.1. Marco Terico
En los siguientes puntos se hace referencia a los conceptos empleados para el desarrollo
de la tesis; cada concepto es descrito de forma breve ya que cada uno de ellos tiene
amplia documentacin y ello est fuera del alcanc del presente trabajo.
3.1.1. Conceptos Bsicos.
Organizacin de una Librera.
La Figura 1 muestra la organizacin funcional tpica de la biblioteca. Este tipo
tradicional de organizacin funcional ofrece distintos departamentos de catalogacin,
circulacin y referencia. A veces, la circulacin y los departamentos de referencia se
combinan en un solo departamento, porque no hay personal suficiente para cubrir los
horarios de los dos departamentos separados. Sin embargo, en la gran biblioteca, es
probable que haya un departamento de adquisiciones con el fin de hacer la seleccin y
adquisicin de materiales. [2]

Figura 1. Estructura bsica de una Librera

Funcionamiento de una Librera.

Las bibliotecas reflejan la diversidad y el carcter de las comunidades a las que sirven.
Excelencia en el servicio de la biblioteca no es una simple cuestin de nmeros. Se
encuentra en el ajuste entre las funciones de la biblioteca y las necesidades y
expectativas de la comunidad a la que sirve.
a. Catalogacin.
Catalogar consiste en describir un documento en sus partes esenciales con el fin
de identificar entre el resto del fondo bibliotecario y de conocer su ubicacin en
la Biblioteca. Se realiza para identificar un documento y recuperarlo. El objetivo
de la catalogacin es identificar los documentos de forma unvoca (Descripcin
bibliogrfica) y agrupar la informacin para poder recuperar los documentos
siguiendo los distintos criterios de seleccin (Normalizacin de punto de acceso)
El Registro Bibliogrfico es conocido tambin como Asiento y consta de las
siguientes

partes:

encabezamiento,

cuerpo

de

registro,

registros

de

encabezamientos secundarios, signatura, nmero de registro. [2]

b. Clasificacin.
Clasificar es agrupar los materiales por su contenido con la finalidad de facilitar
su situacin y su bsqueda. La clasificacin es una tcnica que permite al
bibliotecario organizar los materiales de su biblioteca de acuerdo con el tema a
que stos se refieren. A la hora de clasificar se pueden utilizar distintos
instrumentos, que se agrupan en: sistemas de clasificacin, listas de
encabezamientos de materias. La diferencia entre ambos se encuentra en el
lenguaje que utilizan. Mientras que los sistemas de clasificacin tienen un
lenguaje simblico (notacin), las listas de encabezamiento emplean un lenguaje
natural normalizado. Adems, los sistemas de clasificacin se utilizan en
bibliotecas no solo para obtener un orden fsico de los materiales, sino tambin
intelectual. [2]

c. Servicio de Circulacin.
Prestar materiales de la biblioteca a los usuarios de la biblioteca. [2]

d. Servicio de Referencia.
Prestar asistencia completa a los lectores en el uso de la biblioteca y su
contenido. [2]

e. Seleccin.
Traer valiosas sugerencias para aumentar el material de la biblioteca. [2]

f. Adquisicin.
Adquirir los libros seleccionados por compra, donacin o intercambio. [2]
3.1.2. Conceptos de Software
Arquitectura de Software.
La arquitectura de software palabra denota intuitivamente las estructuras de alto nivel de
un sistema de software. Se puede definir como el conjunto de estructuras necesarias
para razonar sobre el sistema de software, que comprenden los elementos de software,
las relaciones entre ellos, y las propiedades de ambos elementos y relaciones. [7]

La arquitectura de software trmino tambin denota el conjunto de las prcticas

utilizadas para seleccionar, definir y disear una arquitectura de software. [7]
Por ltimo, el trmino denota a menudo la documentacin de la "arquitectura de
software" del sistema. Documentar la arquitectura de software facilita la comunicacin
entre las partes interesadas, capta primeras decisiones sobre el diseo de alto nivel, y
permite la reutilizacin de componentes de diseo entre los proyectos. [8]
Arquitectura por Capas.
Los programas de software incluyen el diseo y el cdigo para llevar a cabo diferentes
tipos de tareas. Aceptan la entrada del usuario, llevar a cabo la lgica de negocio, bases
de datos de acceso, comunicarse a travs de redes, mostrar informacin a los usuarios, y

10

as sucesivamente. As que el cdigo involucrado en cada funcin de programa puede

ser sustancial.
En un programa orientado a objetos de interfaz de usuario, bases de datos, y otros
cdigos apoyo consigue a menudo escriben directamente en los objetos de negocio.
Lgica de negocio adicional est incrustado en el comportamiento de widgets de
interfaz de usuario y secuencias de comandos de base de datos. Esto sucede debido a
que es la forma ms fcil de hacer que las cosas funcionen, en el corto plazo. [9]

Figura 2. Arquitectura por Capas.

1. Interfaz de Usuario (o Capa de Presentacin)

Responsable para mostrar informacin al usuario y la interpretacin de los
comandos del usuario. El actor externo puede ser a veces otro sistema de
computadora en lugar de un usuario humano. [9]
2. Capa de Aplicacin.

11

Define los trabajos que el software tiene que hacer y dirige los objetos de
dominio expresivo de solucionar los problemas. Las tareas de esta capa es
responsable son significativos para el negocio o necesarios para la interaccin
con las capas de la aplicacin de otros sistemas.
Esta capa se mantiene delgada. No contiene normas empresariales o
conocimientos, pero slo coordina las tareas de trabajo y delegados a las
colaboraciones de los objetos de dominio en la siguiente capa. No tiene estado
que refleja la situacin de negocios, pero puede tener estado que refleje el
progreso de una tarea para el usuario o el programa. [9]
3. Capa de Dominio (o Capa de Modelo).
Responsable para representar conceptos de la empresa, la informacin sobre la
situacin del negocio y reglas de negocio. Estado que refleja la situacin de
negocios se controla y se utiliza aqu, a pesar de que los detalles tcnicos de
almacenamiento que se delegan en la infraestructura. Esta capa es el corazn
del software empresarial. [9]
4. Capa de Infraestructura.
Proporciona capacidades tcnicas genricas que apoyan las capas superiores: el
envo de mensajes de la aplicacin, la persistencia del dominio, los widgets de
dibujo para la interfaz de usuario, etc. La capa de infraestructura tambin puede
admitir el patrn de las interacciones entre las cuatro capas a travs de un
marco arquitectnico. [9]
Software Multiplataforma Basada en Servicios.
La industria del desarrollo de software se encuentra actualmente en un estado de
transicin hacia un nuevo paradigma de programacin: la llamada Arquitectura
Orientada a Servicios (SOA, por sus siglas en ingls).
a. Servicio Web.
Un servicio web (en ingls, Web Service o Web services) es una tecnologa que
utiliza un conjunto de protocolos y estndares que sirven para intercambiar

12

datos entre distintas aplicaciones de software desarrolladas en lenguajes de

programacin diferentes, y ejecutadas sobre cualquier plataforma, pueden
utilizar los servicios web para intercambiar datos en redes de ordenadores como
Internet. La interoperabilidad se consigue mediante la adopcin de estndares
abiertos. Las organizaciones OASIS y W3C son los comits responsables de la
arquitectura y reglamentacin de los servicios Web. Para mejorar la
interoperabilidad entre distintas implementaciones de servicios Web se ha
creado el organismo WS-I, encargado de desarrollar diversos perfiles para
definir de manera ms exhaustiva estos estndares. Es una mquina que atiende
las peticiones de los clientes web y les enva los recursos solicitados. [10]
b. Protocolo HTTP.
El HTTP que significa Hyper Text Transfer Protocol se compone de 2
mensajes, el primer mensaje es originado por el cliente y es el requerimiento
inicial de la comunicacin. Este requerimiento llamado Request est dividido
en una cabecera y un mensaje de texto. En la cabecera el cliente enva
informacin de la pgina solicitada al servidor y de la aplicacin cliente que
estamos utilizando en el User-Agent, entre otras cosas, como as tambin los
datos de la plataforma en la cual se encuentra corriendo la aplicacin cliente.
c. Protocolo SOAP
Es un protocolo estndar que define cmo dos objetos en diferentes procesos
pueden comunicarse por medio de intercambio de datos XML. Este protocolo
deriva de un protocolo creado por David Winer en 1998, llamado XML-RPC.
SOAP fue creado por Microsoft, IBM y otros. Est actualmente bajo el auspicio
de la W3C. Es uno de los protocolos utilizados en los servicios Web. [10]
d. WSDL
WSDL describe la interfaz pblica a los servicios Web. Est basado en XML y
describe la forma de comunicacin, es decir, los requisitos del protocolo y los
formatos de los mensajes necesarios para interactuar con los servicios listados
en su catlogo. Las operaciones y mensajes que soporta se describen en

13

abstracto y se ligan despus al protocolo concreto de red y al formato del

mensaje.
As, WSDL se usa a menudo en combinacin con SOAP y XML Schema. Un
programa cliente que se conecta a un servicio web puede leer el WSDL para
determinar qu funciones estn disponibles en el servidor. Los tipos de datos
especiales se incluyen en el archivo WSDL en forma de XML Schema. El
cliente puede usar SOAP para hacer la llamada a una de las funciones listadas
en el WSDL. El WSDL nos permite tener una descripcin de un servicio web.
Especifica la interfaz abstracta a travs de la cual un cliente puede acceder al
servicio y los detalles de cmo se debe utilizar.
Patrones de Diseo de Software.
En la ingeniera de software, un patrn de diseo es una solucin reutilizable general a
un problema que ocurre comnmente en un contexto determinado en el diseo de
software. Un patrn de diseo no es un diseo de acabado que se puede transformar
directamente en cdigo de mquina. Es una descripcin o una plantilla para la forma de
resolver un problema que se puede utilizar en muchas situaciones diferentes. Los
patrones formalizaron las mejores prcticas que el propio programador debe
implementar en la aplicacin. [11]

Patrones de diseo orientado a objetos suelen mostrar las relaciones e interacciones

entre clases u objetos, sin especificar las clases de aplicaciones finales o los objetos que
estn involucrados. Los patrones que implican la orientacin a objetos o, ms
generalmente estado mutable, no son aplicables en lenguajes de programacin
funcional. [11]
Los patrones de diseo residen en el dominio de los mdulos y las interconexiones. En
un nivel superior hay patrones arquitectnicos que son ms grandes en el mbito de
aplicacin, por lo general se describe un patrn general seguido de un sistema completo.
[11]

14

Patrones para la Capa de Dominio

a. Factory Method Pattern
El patrn Factory Method pertenece al grupo creacional de la Banda de los
Cuatro patrones de diseo y se ocupa de la cuestin de la creacin de objetos sin
especificar la clase exacta del objeto que se crear. [12].
Propsito.
El objetivo principal del patrn Factory es ocultar la complejidad de la creacin
de objetos. Adems, el cliente normalmente no especifica una clase particular
que se crear. En cambio, el cliente va a codificar en contra de una interfaz o
clase abstracta y dejar la responsabilidad de la clase Factory para crear el tipo
concreto. Normalmente, una clase Factory tiene un mtodo esttico que
devuelve una clase abstracta o interfaz. El cliente por lo general, aunque no
siempre, suministra algn tipo de informacin, la clase usa la informacin
suministrada por el determina qu subclase para crear y volver. [12]

Notacin UML

Figura 3. Factory Pattern

15

La clase Client obtiene una implementacin de IProduct travs de una

llamada a la clase Factory. El Client pasa un poco de informacin sobre el
tipo de subclase, pero no tiene idea de cmo crearlo.

La clase Factory se encarga de crear la subclase correcta basada en la

informacin suministrada a travs de un parmetro.

El IProduct es la interfaz que referencias Client en su rutina de cdigo y que

es implementado por las clases ConcreteProductA y ConcreteProductB.

ConcreteProductA and ConcreteProductBare the subclass implementations

of IProduct

b. Template Method Pattern.

El patrn Template Method pertenece al grupo de los patrones de
comportamiento de la Banda de los Cuatro y se aplica cuando se define el
esqueleto de un algoritmo, pero algunos pasos difieren en cada subclase. [12]

Propsito.
El mtodo plantilla define la estructura del esqueleto de un algoritmo, pero
difiere ciertos pasos y detalles de las subclases. La estructura y el flujo del
algoritmo permanecen estticos, pero los detalles de los pasos se difieren a las
subclases. [12]

Notacin UML

Figura 4. Template Method Pattern

16

El AbstractClass define un flujo de trabajo de proceso de esqueleto con

pasos abstractos que ConcreteClassA y ConcreteClassB sustituir e
implementar. Esto permite a los detalles de un algoritmo para alterar
dependiendo de las subclases, pero permitir que la estructura permanezca
constante.

ConcreteClassA y ConcreteClassB heredan de AbstractClass, implementan

los mtodos abstractos, y dan los detalles del algoritmo.

c. Composite Pattern.
El patrn Composite permite una coleccin de objetos a ser tratado como una
sola instancia de un objeto. [12]

Propsito.
En el patrn Composite, los objetos pueden ser agrupados dentro rboles o
coleccin jerrquica dinmicamente y se usan como si fueran un solo objeto.
Esto le permite crear el comportamiento sobre la marcha sin el cdigo de cliente
que necesitan para comprender la compleja estructura. [12]
Notacion UML

Figura 5. Composite Pattern.

17

El component es la clase base abstracta que proporciona los medios para

que los objetos que se unen para crear cadenas de comportamiento.

El Leaf es una implementacin concreta de la clase abastracta Component

que especfica comportamiento lgica de negocio.

El Composite es tambin una implementacin concreta de la component que

permite unir Components para relacionados y proporciona la posibilidad de
llamar de forma recursiva en su comportamiento.

El client agrega objetos y elimina objetos del Composite

Patrones para la Capa de Servicios

a. The facade Design Pattern
Un patrn comn utilizado por clientes de SOA es la Facade. El patrn Facade
simplifica la interfaz de un subsistema o un grupo de subsistemas complejo,
dando un cliente de una API no complicada de usar que es consistente con otras
API que el cliente puede utilizar para trabajar en contra. [6]
Propsito.
El patrn Facade proporciona una interfaz sencilla para una API compleja. El
patrn Facade se puede utilizar en muchos escenarios diferentes:

Se puede hacer una biblioteca de terceros ms fcil de usar por envolver en

una interfaz compatible con el resto de la aplicacin

Puede ayudar al cdigo vagamente par abstrayendo las dependencias con

otros sistemas y bibliotecas.

Se puede envolver un subsistema complicada con una interfaz ms sencilla

Notacin UML

18

Figura 7. The facade Design Pattern.

El client utiliza la API simple de la Facade para realizar una tarea. El client
no es consciente de lo que realmente se necesita para lograr la transaccin.

La Facade esconde la complejidad del sistema detrs de su API simple. La

Facade y luego los delegados de los subsistemas y coteja las respuestas.

SubSystemA y SubSystemB realizar el trabajo para el client.

Patrones para la Capa de Acceso a Datos.

a. The repository Pattern.
A media Repositorio entre el dominio y las capas de asignacin de datos,
actuando como una coleccin de objetos de dominio en la memoria. Objetos de
cliente construye especificaciones de consulta declarativa y presentarlos al
repositorio de satisfaccin. Los objetos se pueden agregar y quitar del depsito,
ya que pueden partir de una simple coleccin de objetos, y el cdigo de
asignacin encapsulado por el Repositorio llevar a cabo las operaciones
correspondientes detrs de las escenas.
Conceptualmente, un repositorio encapsula el conjunto de objetos persistido en
un almacn de datos y las operaciones que se realizan sobre ellos,
proporcionando una visin orientada a objetos ms de la capa de persistencia.
Repositorio tambin es compatible con el objetivo de lograr una separacin

19

limpia y de un solo sentido de dependencia entre el dominio y las capas de

asignacin de datos. [13]

Propsito.
En un sistema grande, con muchos tipos de objetos de dominio y muchas
preguntas posibles, Repositorio reduce la cantidad de cdigo necesario para
hacer frente a todas las consultas que se enciende. Repositorio promueve el
patrn Especificacin que encapsula la consulta que se realiza de una manera
orientada a objeto puro. Por lo tanto, todo el cdigo para la creacin de un
objeto de consulta en casos especficos puede ser retirado. [13]
Tecnologas.
a. Tecnologa Cliente-Servidor.
Desde el punto de vista funcional, se puede definir la computacin
Cliente/Servidor como una arquitectura distribuida que permite a los usuarios
finales obtener acceso a la informacin en forma transparente an en entornos
multiplataforma. [14]

Cliente.
El cliente es el proceso que permite al usuario formular los requerimientos y
pasarlos al servidor, se le conoce con el trmino front-end. [14]

El Cliente normalmente maneja todas las funciones relacionadas con la

manipulacin y despliegue de datos, por lo que estn desarrollados sobre
plataformas que permiten construir interfaces grficas de usuario (GUI),
adems de acceder a los servicios distribuidos en cualquier parte de una red.
[14]

Las funciones que lleva a cabo el proceso cliente se resumen en los

siguientes puntos:
-

Administrar la interfaz de usuario.

20

Interactuar con el usuario.

Procesar la lgica de la aplicacin y hacer validaciones locales.

Generar requerimientos de bases de datos.

Recibir resultados del servidor.

Formatear resultados.

Servidor
Es el proceso encargado de atender a mltiples clientes que hacen peticiones
de algn recurso administrado por l. Al proceso servidor se le conoce con el
trmino back-end. [14]

El servidor normalmente maneja todas las funciones relacionadas con la

mayora de las reglas del negocio y los recursos de datos. [14]

Las funciones que lleva a cabo el proceso servidor se resumen en los

siguientes puntos:
-

Aceptar los requerimientos de bases de datos que hacen los clientes.

Procesar requerimientos de bases de datos.

Formatear datos para trasmitirlos a los clientes.

Procesar la lgica de la aplicacin y realizar validaciones a nivel de bases

de datos.

Caractersticas Cliente - Servidor.

Las caractersticas bsicas de una arquitectura Cliente/Servidor son [14]:

Las tareas del cliente y del servidor tienen diferentes requerimientos en

cuanto a recursos de cmputo como velocidad del procesador, memoria,
velocidad y capacidades del disco e input-output devices.

Existe una clara distincin de funciones basada en el concepto de

"servicio", que se establece entre clientes y servidores.

21

La relacin establecida puede ser de muchos a uno, en la que un servidor

puede dar servicio a muchos clientes, regulando su acceso a recursos
compartidos.

No existe otra relacin entre clientes y servidores que no sea la que se

establece a travs del intercambio de mensajes entre ambos. El mensaje es
el mecanismo para la peticin y entrega de solicitudes de servicio.

El ambiente es heterogneo. La plataforma de hardware y el sistema

operativo del cliente y del servidor no son siempre la misma. Precisamente
una de las principales ventajas de esta arquitectura es la posibilidad de
conectar clientes y servidores independientemente de sus plataformas.

El concepto de escalabilidad tanto horizontal como vertical es aplicable a

cualquier sistema Cliente/Servidor. La escalabilidad horizontal permite
agregar ms estaciones de trabajo activas sin afectar significativamente el
rendimiento. La escalabilidad vertical permite mejorar las caractersticas del
servidor o agregar mltiples servidores.

b. Tecnologas para Persistencia de Datos.

Object-Relational Mapper (ORM)

El mapeo objeto-relacional es una tcnica de programacin para convertir

datos entre el sistema de tipos utilizado en un lenguaje de programacin
orientado a objetos y la utilizacin de una base de datos relacional,
utilizando un motor de persistencia. En la prctica esto crea una base de
datos orientada a objetos virtual, sobre la base de datos relacional. Esto
posibilita el uso de las caractersticas propias de la orientacin a objetos
(bsicamente herencia y polimorfismo). Hay paquetes comerciales y de uso
libre disponibles que desarrollan el mapeo relacional de objetos, aunque
algunos programadores prefieren crear sus propias herramientas ORM.

Nhibernate: NHibernate solucin (ORM) para la plataforma NET de

Microsoft: Proporciona un framework para el mapeo de un modelo de
dominio orientado a objetos a una base de datos relacional tradicional. Su

22

propsito es aliviar el desarrollador de una porcin significativa de las

tareas de programacin relacionados con la persistencia de datos
relacionales. NHibernate es libre como el software de cdigo abierto que
se distribuye bajo la Licencia Pblica General GNU.
3.2. Desarrollo de la Investigacin.
En esta seccin se describe los requerimientos y el diseo del software que se pretende
desarrollar.
3.2.1. Requerimientos del Software
El primer paso, es la obtencin de requerimientos que especifican lo que el software
debe hacer, es decir su funcionalidad, para ello primeros debemos identificar los
usuarios del software as como sus necesidades.
A. Usuarios del Software
Hemos identificado 2 usuarios del software: el bibliotecario y el usuario de la
biblioteca (estudiante u otro).
1. Bibliotecario
Principales necesidades:

Forma fcil de crear y administrar las cuentas de los usuarios

Habilidad de controlar y administrar actividades tales como:

Reservaciones

Prestamos

Devoluciones

Renovaciones

Habilidad de generar reportes de operaciones/transacciones

Principales funciones:

Procesar prstamos solicitados por los usuarios de la biblioteca.

Procesar devoluciones de libros.

Renovar el prstamo de libros.

23

Hacer reclamo de libros en prstamo.

Registrar a nuevos usuarios de la biblioteca.

Actualizar la informacin de usuarios.

Suspender la cuenta de un usuario.

Ayudar al usuario en la bsqueda de materiales bibliogrficos.

2. Usuario de la Biblioteca
Principales necesidades:

Manera rpida y sencilla de buscar algn material bibliogrfico sea

tesis, revista o libro.

Habilidad de reservar libros desde casas

Habilidad de ver el historial de prestamos

Habilidad de recibir mensajes de alerta cuando el tiempo de prstamo

est por terminar

Principales funciones:

Solicitar prstamo de un material bibliogrfico

Devolver un libro u otro material bibliogrfico.

Solicitar Renovacin de un libro u otro material bibliogrfico.

B. Caractersticas del Software

Esta seccin describe las caractersticas del software. Cada caracterstica
proporciona la funcionalidad necesaria para satisfacer las necesidades de los
usuarios.
Gestin de Usuarios
La gestin de usuarios incluye las creaciones de nuevas cuentas de usuario,
cambio de configuracin a la cuenta de usuarios, edicin de informacin,
suspensin de cuentas e incluso eliminacin de una cuenta de usuario.

24

 Gestin de Coleccin Bibliotecaria

La gestin de coleccin bibliotecaria incluye el registro de libros,
bsqueda de material bibliogrfico por autor, titulo o ISBN, edicin de
registros de material bibliogrfico y eliminacin de los mismos.
Circulacin de Material Bibliogrfico
La circulacin de material bibliogrfico incluye el prstamo, reservacin,
retorno y reclamos de libros, revistas, tesis entre otros
C. Casos de Uso Representativos
En esta seccin se describe los casos de usos ms significativos y aquellos que
ayuden a entender como el sistema ser usado

Caso de Uso: Registrar Usuario

Actores

Bibliotecario
Este caso de uso describe como el actor

Descripcin

Bibliotecario registra un nuevo usuario

1. El caso de uso empieza cuando el bibliotecario

navega a la seccin Registrar Usuario de la
aplicacin.
2. Sistema muestra un formulario de informacin
personal
Flujo normal de
eventos

3. Bibliotecario ingresa el nombre, apellidos,

gnero, fecha de nacimiento, nmero de
telfono celular, nmero de telfono fijo, y
email, luego hace clic en registrar.
4. Sistema registra el nuevo usuario.
5. Sistema muestra la cuenta creada.
6. El caso de uso termina.

25

A1. Agregar Foto

Cuando el bibliotecario haya llenado el
Flujos

formulario de registro (paso 3) y antes de hacer

Alternativos

clic en registrar, si desea puede agregar una foto

para el usuario:

E1. Cancelar Registro

En cualquier momento del registro, si el
bibliotecario selecciona cancelar
Flujos de

1. Sistema pide confirmacin de cancelacin.

Excepcin

2. Si el bibliotecario confirma cancelacin, el

sistema cierra el formulario de registracin.
3. El caso de uso termina.

Tabla 1. Caso de Uso - Registrar Usuario

Caso de Uso: Registrar Libro

Actores

Bibliotecario.
Este caso de uso describe como el actor

Descripcin

Bibliotecario registra un nuevo libro.

1. El caso de uso inicia cuando el Bibliotecario

navega a la seccin registrar libro de la
aplicacin.
Flujo normal de

2. Sistema muestra el formulario de registro.

eventos

3. Bibliotecario ingresa informacin del libro como

su ttulo, fecha de publicacin, descripcin, uso
referencial, ISBN y hace clic en registrar.
4. El caso de uso termina.

26

Tabla 2. Caso de Uso - Registrar Libro

Caso de Uso: Prestar Libro

Actores

Bibliotecario
Este caso de uso describe como el actor

Descripcin

Bibliotecario realiza el prstamo de un libro.

1. El caso de uso inicia cuando el Bibliotecario

navega a la seccin prestar de la aplicacin.
2. Sistema muestra el formulario de prstamo
Flujo normal de
eventos

3. Bibliotecario ingresa el cdigo del usuario,

cdigo del libro (ISBN/ID), periodo de
prstamo, modo de prstamo, y luego hace clic
en prestar.
4. Sistema registra el prstamo y actualiza el estado
del libro.
5. El caso de uso termina
Tabla 3. Caso de Uso - Prestar Libro

Caso de Uso: Retornar Libro

Actores

Bibliotecario.
Este caso de uso describe como el actor

Descripcin

Flujo normal de
eventos

Bibliotecario realiza el retorno de un libro.

1. El caso de uso inicia cuando el Bibliotecario

navega a la seccin retornar de la aplicacin.
2. Sistema muestra el formulario de retorno.
3. Bibliotecario ingresa el cdigo del libro
(ISBN/ID) y hace clic en devolver.
4. Sistema registra el retorno y actualiza el estado
del libro.
5. El caso de uso termina
Tabla 4. Caso de Uso - Retornar Libro

Caso de Uso: Renovar Libro

Actores

Bibliotecario.

27

Este caso de uso describe como el actor

Descripcin

Flujo normal de
eventos

Bibliotecario realiza la renovacin de un libro.

1. El caso de uso inicia cuando el Bibliotecario

navega a la seccin renovar de la aplicacin.
2. Sistema muestra el formulario de renovacin.
3. Bibliotecario ingresa el cdigo del libro
(ISBN/ID), nuevo periodo de prstamo y hace
clic en renovar.
4. Sistema registra la renovacin.
5. El caso de uso termina.
Tabla 5. Caso de Uso - Renovar Libro

Caso de Uso: Reclamar Libro

Actores

Bibliotecario.
Este caso de uso describe como el actor

Descripcin

Flujo normal de
eventos

Bibliotecario realiza el reclamo de un libro.

1. El caso de uso inicia cuando el Bibliotecario

navega a la seccin prestamos de la aplicacin.
2. Sistema muestra una lista de los libros en
prstamo.
3. Bibliotecario selecciona un l y hace clic en
reclamar.
4. Sistema enva un mensaje al usuario al que se le
presto el libro.
5. El caso de uso termina.
Tabla 6. Caso de Uso Reclamar Libro

3.2.2. Diseo del Software

Luego de definir los requerimientos funcionales del sistema (lo que el sistema debe
hacer) Ahora crearemos el diseo y modelado del software, para ello utilizaremos
diagramas UML tales como diagrama de componentes, diagrama de clases, diagrama de
actividades.

28

A. Arquitectura del Software

El software estar organizado en 4 capas: Capa de Presentacin la cual consta
de todos los componentes de interfaz las cuales manipula el usuario, Capa de
Servicios la cual proporciona servicios y abstrae los detalles de
implementacin, Capa de Lgica del Negocio la cual modela el negocio, en
esta capa se encuentran los flujos del negocio, y sus entidades, Capa de Acceso a
Datos la cual proporciona la persistencia de los datos para nuestro modelo
(BLL). Ver figura 8

Figura 8. Arquitectura y Componentes de la Aplicacin.

29

B. Modelo del Software

El modelo es el conjunto de entidades que maneja el software y que forman
parte de la capa de lgica del negocio, es decir es un conjunto de clases POCO
(clases que ignoran la persistencia de los datos). En la figura 9 se observa el
modelo del dominio del negocio que se usara para la implementacin del
software.

Figura 9. Modelo del Dominio.

En la figura 10 se observa los atributos de nuestra entidad Prstamo, la cual se

relaciona con una Modalidad de prstamo, tiene un Estado, est asociada a un
Usuario y una Copia de un Material Bibliogrfico.

30

Figura 10. Entidad Prstamo.

En la figura 11 se muestra el algoritmo (lgica) utilizado para el procesamientos

de prstamos.

Figura 11. Algoritmo de Prstamo

4. Conclusiones.

La implantacin del Sistema permitir automatizar el rea de prstamos de

material bibliogrfico permitiendo contribuir al crecimiento tecnolgico de la
Bibliotecas de la Universidad Nacional de Trujillo.

La implantacin del Sistema optimizara el trabajo manual de prstamo de

material bibliogrfico, dando como resultado la pronta ejecucin de este
proceso.

31

5. Referencia Bibliogrfica
[1] Bhupendra Singh Baghela, Shraddha Panwar, Vijay Vaishnav, "Online Library
Management System", 2001, Disponible en:
http://www.iisjaipur.org/management_system.pdf
[Fecha de consulta: 27 agosto del 2013]
[2] Seong Seung Park March, "The Development Of A Database Management System
For Librar Loan Management", 1990 , Disponible en:
http://www.dtic.mil/dtic/tr/fulltext/u2/a226249.pdf
[Fecha de consulta: 27 agosto del 2013]
[3] Joaquim Jorge Rodrigues, " An Integrated Library System on the CERN Document
Server ", 2010 , Disponible en:
http://cds.cern.ch/record/1294486/files/CERN-THESIS-2010-115.pdf
[Fecha de consulta: 28 agosto del 2013]
[4] Neelakandan.B, Duraisek ar. S, Balasubramani .R, Srinivasa Ragavan.S , "
Implementation of Automated Library Management Systemr ", 2010 , Disponible en:
http://www.ipublishing.co.in/jarvol1no12010/EIJAER1014.pdf
[Fecha de consulta: 28 agosto del 2013]
[5] Sangsuree Vasupongayya, Kittisak Keawneam, Kittipong Sengloilaun, Patt
Emmawat, " Open Source Library Management System Softwarer ", 2011 , Disponible
en: http://www.waset.org/journals/waset/v53/v53-178.pdf
[Fecha de consulta: 28 agosto del 2013]
[6] Guy R. Lyle, The Administration of the College Library, 4th Edition, The H.W.
Wilson Company, 1974.
[7] Clements, Paul; Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little,
Paulo Merson, Robert Nord, Judith Stafford. Documenting Software Architectures:
Views and Beyond, Second Edition. Boston: Addison-Wesley, 2010.
[8] Clements P, Kazman R, Software Architecture In Practice, Third Edition. Boston:
Addison-Wesley, 2012.
[9] Evans E. Domain Driven Design: Tackling Complexity in the Heart of Software.
Addison-Wesley, 2003.

32

[10] Alonso G. , Casati F. , Kuno H. , Machiraju V. "Web Services: Concepts,

Architectures and Applications",New York Springer, 1998.
[11] Martin, Robert C.. "Design Principles and Design Patterns". Retrieved 2000.
[12] Millett S. "ASP.NET Design Patterns", Indiana Wiley Publishing, Inc, 2010.
[13] Fowler M. Patterns of Enterprise Application Architecture, Pearson Education,
2003.
[14] Kenneth E. , Kendall, Julie E , Anlisis y diseo de sistemas, Paperback
August 1, 2005.

33

A. Anexos
A.1 Formato Entrevistas a Usuarios
A.1.1 Entrevista de Usabilidad
Nombre:
Fecha:
Califique su nivel de satisfaccin de acuerdo con las siguientes afirmaciones.

1 = muy malo.
2 = malo.
3 = regular
4 = bueno
5 = muy bueno
Seale NS/NC si no tiene un juicio formado sobre la pregunta realizada.

Entrevista
Usuario (Estudiante)
1.

Bsqueda de Publicaciones ttulo, mbito, Autor,

2.

Realiza Prstamo.

3.

Bsqueda de Prestamos

Personal (Bibliotecario)
1.

Bsqueda de Publicaciones ttulo, mbito, Autor,

2.

Ingresar nueva publicacin

3.

actualizar / modificar publicacin

4.

eliminar publicacin

5.

Crear Autor

6.

Actualizar /Modificar Autores

7.

Bsqueda de usuario de Biblioteca

8.

Bsqueda de Prestamos

9.

Actualizar / Modificar Prstamo

NS/NC

NS/NC

10. Reportes Sistema

34

A.1.1 Entrevista de Satisfaccin

Nombre:
Fecha:
Califique su nivel de satisfaccin de acuerdo con las siguientes afirmaciones.

1 = deficiente.
2 = malo.
3 = regular
4 = bueno
5 = excelente
Seale NS/NC si no tiene un juicio formado sobre la pregunta realizada.

Entrevista
Usuario (Estudiante) Servicios de la Biblioteca
4.

La Biblioteca tiene las colecciones de las revistas electrnicas que necesito

5.

Estoy informado de las novedades de la Biblioteca.

6.

Con las herramientas de bsqueda de informacin encuentro fcilmente lo

NS/NC

NS/NC

que necesito;
7.

El Servicio de Reserva de libros me ahorra tiempo.

8.

La Biblioteca tiene ejemplares suficientes de los libros impresos que

necesito.

9.

En General estoy satisfecho con el servicios que brinda la biblioteca

Personal (Bibliotecario)
11. Est dispuesto a satisfacer las necesidades de los usuarios
12. Realiza el servicio correctamente
13. Es amable con los usuarios
14. Atiende con rapidez
15. El sistema actual facilita su labor.

35

A.2 Modelo de Casos de Uso

Figura A.1 Diagrama de Caso de Usos

Gestin de Usuarios
Esta seccin describe los casos de uso relacionados a la gestin de usuarios.
1. Registrar Usuario
Este caso de uso describe como el actor Bibliotecario registra un nuevo
usuario.
Flujo Principal
1. El caso de uso empieza cuando el bibliotecario navega a la seccin
Registrar Usuario de la aplicacin.
2. Sistema muestra un formulario de informacin personal
3. Bibliotecario ingresa el nombre, apellidos, gnero, fecha de
nacimiento, nmero de telfono celular, nmero de telfono fijo, y
email, luego hace clic en registrar.
4. Sistema registra el nuevo usuario.
5. Sistema muestra la cuenta creada.
6. El caso de uso termina.
Flujos Alternativos

36

Agregar Foto
Cuando el bibliotecario haya llenado el formulario de registro (paso 3) y
antes de hacer clic en registrar, si desea puede agregar una foto para el
usuario:
1. Bibliotecario hace clic en browser para localizar el archivo en la
computadora que se quiere agregar como foto del usuario.
2. Bibliotecario hace clic en registrar.
3. Sistema registra el nuevo usuario.
4. Sistema agrega el archivo seleccionado como foto de usuario.
5. El caso de uso termina
Flujos de Error
Cancelar Registro
En cualquier momento del registro, si el bibliotecario selecciona
cancelar
1. Sistema pide confirmacin de cancelacin.
2. Si el bibliotecario confirma cancelacin, el sistema cierra el
formulario de registracin.
3. El caso de uso termina (no se registra al usuario).
2. Explorar Usuarios
Este caso de uso describe como el actor Bibliotecario explora las cuentas de
los usuarios.
Flujo Principal
1. El caso de uso inicia cuando el Bibliotecario navega a la seccin
usuarios de la aplicacin.
2. Sistema presenta una lista de usuarios.
3. Bibliotecario selecciona un usuario.
4. Ejecutar Ver Detalles de Usuario (S1) para mostrar informacin
detallada del usuario seleccionado.
5. El caso de uso termina.

Gestin de Coleccin Bibliotecaria

37

Esta seccin describe los casos de uso relacionados a la gestin de material

bibliogrfico.
1. Registrar Libro
Este caso de uso describe como el actor Bibliotecario registra un libro.
Flujo Principal
1. El caso de uso inicia cuando el Bibliotecario navega a la seccin
registrar libro de la aplicacin.
2. Sistema muestra el formulario de registro.
3. Bibliotecario ingresa informacin del libro como su ttulo, fecha de
publicacin, descripcin, uso referencial, ISBN y hace clic en
registrar.
4. El caso de uso termina.

Circulacin de Material Bibliogrfico

Esta seccin describe los casos de uso relacionados a la circulacin de material
bibliogrfico.
1. Prestar Libro
Flujo Principal
1. El caso de uso inicia cuando el Bibliotecario navega a la seccin
prestar de la aplicacin.
2. Sistema muestra el formulario de prstamo.
3. Bibliotecario ingresa el cdigo del usuario, cdigo del libro
(ISBN/ID), periodo de prstamo, modo de prstamo, y luego
hace clic en prestar.
4. Sistema registra el prstamo y actualiza el estado del libro.
5. El caso de uso termina
2. Retornar Libro
Flujo Principal
1. El caso de uso inicia cuando el Bibliotecario navega a la seccin
retornar de la aplicacin.
2. Sistema muestra el formulario de retorno.

38

3. Bibliotecario ingresa el cdigo del libro (ISBN/ID) y hace clic en

devolver.
4. Sistema registra el retorno y actualiza el estado del libro.
5. El caso de uso termina.
3. Renovar Libro
Flujo Principal
1. El caso de uso inicia cuando el Bibliotecario navega a la seccin
renovar de la aplicacin.
2. Sistema muestra el formulario de renovacin.
3. Bibliotecario ingresa el cdigo del libro (ISBN/ID), nuevo
periodo de prstamo y hace clic en renovar.
4. Sistema registra la renovacin.
5. El caso de uso termina.
4. Reclamar Libro
Flujo Principal
1. El caso de uso inicia cuando el Bibliotecario navega a la seccin
prestamos de la aplicacin.
2. Sistema muestra una lista de los libros en prstamo.
3. Bibliotecario selecciona un l y hace clic en reclamar.
4. Sistema enva un mensaje al usuario al que se le presto el libro.
5. El caso de uso termina.

39

A.3 Diseo del Software

Arquitectura del Software

Figura A.2 Arquitectura del Software

40

 Diagrama de Componentes

Figura A.3 Diagrama de Componentes.

41

 Modelo del Dominio

Figura A.4 Modelo del dominio.

Entidades

Figura A.4.1 Entidad Usuario.

42

Figura A.4.2 Entidad Autor.

Figura A.4.3 Entidad Material.

43