Logo Studenta

Proyecto Desarrollo de sistema de biblioteca universitaria

¡Este material tiene más páginas!

Vista previa del material en texto

1
 
 
 
 
 
 
 
CASO DE ESTUDIO 
BIBLIOTECA UNIVERSITARIA 
 2
INTRODUCCIÓN 
Este caso de estudio nos presenta el desarrollo de un sistema de BIBLIOTECA 
UNIVERSITARIA que permitirá la automatización de las operaciones la biblioteca de una 
universidad, utilizando las tecnologías de Internet. 
 
La Biblioteca Universitaria es un caso de estudio donde se utiliza el Proceso Unificado para 
definir la concepción, la elaboración, construcción y la Transición como fases principales y la 
utilización de un paradigma de Ciclo de Vida para el Análisis y Diseño Orientado Objetos 
utilizando el Lenguaje de Modelado Unificado para la implementación de un sistema. 
Este sistema permitirá a sus usuarios la búsqueda de bibliografía en forma dinámica y atractiva 
para el usuario, pues le va a evitar la engorrosa perdida de tiempo;, además se dispondrá la 
opción de realizar reservas de textos seleccionados, esta alternativa tendrá una vigencia de 
tiempo determinado, después del cual el si es que el usuario no ha recogido el texto 
reservado, este será puesto nuevamente a disposición de todos los usuarios. 
 También se pretende en un futuro cercano contar con textos electrónicos para ofrecer a los 
usuarios la posibilidad de adquirir dichos textos total o parcialmente desde Internet. 
 
El sistema presenta una gestión de biblioteca interactiva, pues vamos a ingresar el tema que 
necesitamos, ya sea ingresando titulo, autor o alguna palabra clave que nos caracteriza 
nuestra información para que sé efectúe la búsqueda de la bibliografía. Luego nos presentara 
toda una lista de la información clasificada sobre el tema a buscar para que el usuario escoja 
la que desea. 
 
También el sistema tiene la facilidad de que después de escoger de la lista lo que deseamos, 
podemos tener acceso a ese libro, simplificando así los procesos manuales y obteniendo así 
los resultados necesarios que el usuario necesita. 
 
La base de datos ha sido diseñada desde un modelo de clases, al que se han aplicado las 
reglas de derivación hacia un modelo relacional, que luego ha sido normalizado, implementado 
e instalado con MS SQL Server. 
 
 3
OBJETIVO GENERAL 
Automatizar el sistema de gestión de la biblioteca universitaria utilizando métodos, técnicas y 
herramientas de Internet, mediante una metodología orientada a objetos. 
 
OBJETIVOS ESPECÍFICOS 
 
1. Facilitar la catalogación de documentos. 
2. Actualizar en tiempo real los prestamos, las devoluciones y reservas. 
3. Brindar nuevos procesos de atención utilizando tecnologías de la información. 
4. Llevar a cabo el proceso de registro de publicación y prestamos de libros, revistas, 
tesis y otros en forma rápida, oportuna y precisa. 
5. Utilizar las herramientas de Internet en la implementación de los servicios del cliente. 
 
 
 4
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
FASE DE CONCEPCION 
 5
 
ETAPA DE PLANIFICACIÓN DEl PROYECTO 
 
 
El presente plan de trabajo de desarrollo pensando en la forma de distribuir actividades y 
responsabilidades del grupo integrado por los alumno de curso de Planeamiento y 
Administración de Proyectos informatico el presente plan estaba basado en el desarrollo de 
las actividades de cada uno de los responsable de cada área asignada y para así poder en 
conjunto analizar el tiempo de empleo en el desarrollo de actividades, costes y poder 
distribuir los equipos disponibles de los integrantes del grupo y las herramientas de trabajo 
requeridas para el proyecto propuesto en el presente curso. 
 
Objetivo General del Plan 
 
Desarrollar un programa de actividades para el desarrollo de un proyecto informatico 
orientado a objetos. 
 
Objetivos Específicos del Plan 
 
1. Asignar responsabilidades a cada uno de los integrantes del grupo de trabajo. 
2. Distribuir equipos y materiales para cada uno de los grupo asignados. 
3. Buscar herramientas para el desarrollo del proyecto. 
4. Coordinar actividades conjuntas del equipo de trabajo posibles anomalías y cambios 
en el trabajo. 
5. Cuantificar los coste al final del proyecto. 
 
LA ORGANIZACIÓN DEL GRUPO DE TRABAJO 
El presente grupo de trabajo se formo en el presente curso de Planeamiento y administración 
de proyectos Informaticos, del X ciclo de la carrera de ingeniería Industrial de la escuela 
Profesional de Ingeniería Informática, tomo como Proyecto el desarrollo de un SISTEMA 
AUTOMATIZADO DE LA BIBLIOTECA “Biblioteca Universitaria”, por acuerdo de 
los integrantes se toma la siguiente designación para los siguientes cargo y actividades teniendo 
 6
que responder puntualmente con las responsabilidades encomendadas, contado cada uno con 
la colaboración y apoyo de todos los integrantes. Teniendo el siguiente organigrama y 
responsabilidades de actividades en cada fase como valla evolucionando el proyecto. 
 
 
 
Recursos Humanos 
 
NOMBRE TIPO 
Pedro Picapiedra Jefe de Proyecto 
Pablo Bentonita Analista 1 
Vilma Caliza Analista Programador 
1 
Juan Mármol Analista Programador 
2 
Beatriz Arcilla Analista Programador 
3 
 
 
Cargos de los Integrante: 
Jefe del proyecto: 
?? Jefe. 
Encargado de la dirección del proyecto y de la distribución de las actividades, de la 
coordinación con cada uno de las áreas asignadas. Tiene toda la responsabilidad del 
proyecto. 
Desarrollo: 
?? Analista 1 
?? Analista Programador 1 
Tienen asignada la conducción de las tareas técnicas para el desarrollo del proyecto. 
Además tienen como tarea la busque de toda la información y materiales que ayude a 
Jefe del Proyecto 
Soporte Técnico Desarrollo Administración 
 7
la elaboración del proyecto, como bibliotecas de clases, patrones, tesis, libros e 
información de cualquier fuente, especialmente de algún proyecto antes desarrollado 
para tener una base conocimientos y experiencias para el desarrollo del proyecto. 
Soporte Técnico: 
?? Analista Programador 2 
Tienen como tarea mantener el funcionamiento de las computadores, software y otros 
requerimientos tecnológicos para el desarrollo del proyecto. 
Administración: 
?? Analista Programador 3 
En cargado de la gestión administrativa y financiera del proyecto, teniendo la 
responsabilidad de administrar todos los recursos durante el proyecto. 
 
Calificaciones del Equipo de Desarrollo 
En este punto vamos a describir las calificaciones de los miembros del equipo de desarrollo 
que se requieren para el desarrollo de un proyecto informatico orientado a objetos, es 
decir, los conocimientos, habilidades, destrezas y experiencia requerida para poder 
culminar con éxito el proyecto. 
 
Para que un proyecto de esta naturaleza tenga posibilidades reales de éxito, las personas 
encargadas de desarrollar el proyecto deberían poseer las siguientes calificaciones: 
 
JEFE DE PROYECTO 
1. Experiencia en Gestión de Recursos Humanos 
2. Experiencia en Herramienta d Gestión de Proyectos 
3. Conocimientos y experiencia sobre el área de negocios en estudio 
4. Capacidad de Liderazgo 
5. Experiencia en Plataforma Cliente-Servidor 
6. Conocimiento avanzados de metodologías OO, del proceso unificado y el lenguaje de 
modelado unificado. 
7. Experiencia en el modelado de datos 
8. Experiencia en el Análisis y Diseño de Sistemas 
9. Manejo de herramientas de comunicación en Internet. 
10. Experiencia en el manejo de documentación administrativa y técnica, como por ejemplo 
actas de reunión con los usuarios, encuestas, entrevistas, reportes, calendarios de 
 8
actividades, manejo de agendas, etc. 
11. Uso del Microsoft Project, herramienta que nos facilitará la coordinación del proyecto, 
administración de nuestros recursos, administración de tiempo, herramienta con la cual 
podemos verificar o estar al tanto del avance del Proyecto. 
 
 
 
 
ANALISTA 
 
1. Conocimiento avanzados de metodologías OO, del proceso unificado y el lenguaje de 
modelado unificado. 
2. Experiencia en el modelado de datos: modelo entidadrelación, operaciones relacionales, 
normalización, etc. 
3. Manejo de Herramientas CASE para el modelado de datos, como ERWIN. 
4. Experiencia en el Análisis y Diseño de Sistemas 
5. Conocimientos sobre el área de negocios del proyecto en desarrollo. 
6. Conocimiento de la Notación UML 
7. Conocimiento acerca de la metodología OO, la cual será usada en el desarrollo del 
proyecto. 
8. Manejo del Office principalmente Excel, Word esto servirá mucho al momento de 
documentar los avances e informes del proyecto. 
9. Manejo de Internet, con el fin de búsqueda de información 
. 
 
 
ANALISTA PROGRAMADOR 
1. Conocimiento avanzados de metodologías OO, del proceso unificado y el lenguaje de 
modelado unificado. 
2. Experiencia en el modelado de datos: modelo entidad relación, operaciones relacionales, 
normalización, etc. 
3. Conocimientos avanzados y experiencia comprobada en el uso de Visual Basic 6.0, 
versión empresarial, para el desarrollo de aplicaciones cliente servidor, por lo que deberá 
 9
tener conocimientos en lo que se refiere a alcance de las variables, tipos de datos y su 
manejo (por ejemplo manejo de cadenas, constantes, alcance, etc), nomenclatura, 
declaraciones, arreglos, conexión a la base de datos, clases de dominio, de interfaz, de 
entidad, de control, funciones, mensajes, manejos de librerías (estática y dinámica), etc; 
en pocas palabras dominar lo máximo posible el entorno. 
4. Conocimiento avanzados de metodologías OO, del proceso unificado y el lenguaje de 
modelado unificado. 
5. Conocimiento sobre el Sistema de Administración de Base de datos Relacional SQL 
SERVER 7.0 ., especialmente programación de consultas, vistas, restricciones, 
disparadores y procedimientos almacenados utilizando el lenguaje de consulta 
estructurada SQL. 
6. Manejo del Office principalmente Excel, Word esto servirá mucho al momento de 
documentar los avances e informes del proyecto. 
7. Conocimiento sobre Arquitectura Cliente-Servidor (solo arquitectura de dos capas) y 
conocimientos sobre desarrollo en entorno de red (bloqueos, tiempos de respuesta, etc). 
8. Manejo de Internet, con el fin de búsqueda de información. 
 
 
 
Calificaciones del personal disponible, miembros del Equipo de Trabajo 
Se utilizara la Siguiente Escala: 
 
1. poco 
2. regular 
3. bueno 
4. muy bueno 
5. excelente 
 
Característica Analista 
1 
Analista 
Programador 
1 
Analista 
Programador 
2 
Analista 
programador 3 
Jefe del 
Proyecto 
Visual Basic 6.0 
 
1 4 4 5 4 
Office(Excel, Word) 
 
5 5 5 5 5 
Manejo de Internet 
 
5 5 5 5 5 
Conocimiento de 4 4 4 5 5 
 10
Metodología OO 
 
Experiencia en Modelado de 
Base de Datos 
3 3 3 5 5 
Erwin 
 
2 3 1 5 4 
SQL SERVER 7.0 
 
3 3 3 5 5 
Notación UML 
 
4 3 3 4 4 
Experiencia en Análisis y 
Diseño de Sistemas 
3 3 3 5 5 
Correo Electrónico, FTP 4 3 3 3 4 
Conocimiento arquitectura 
Cliente / Servidor y desarrollo 
de entorno de red 
1 1 1 4 4 
Microsoft Project 
 
4 4 3 4 4 
Experiencia o Conocimiento 
sobre el dominio del 
problema 
3 3 3 5 3 
 
METODOLOGIA 
La metodología propuesta para el presente desarrollo del proyecto esta basada en el uso del 
Proceso Unificado. 
 
CICLO DE VIDA 
El paradigma de ciclo de vida seleccionado para el presente desarrollo del proyecto esta 
basado en modelo en espiral, que hemos utilizado para distribuir las actividades y 
responsabilidades a cada uno de los integrantes del Equipo. 
 
El modelo en espiral, es un modelo de proceso de software evolutivo que acompaña la 
naturaleza interactiva de construcción de prototipos con los aspectos controlados y 
sistemáticos del modelo lineal secuencial. Se proporciona el potencial para el desarrollo 
rápido de versiones increméntales del software. En el modelo espiral, el software se 
desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones, la versión 
incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, la 
 11
versión incremental podría ser un modelo en papel o un prototipo. Durante las ultimas 
iteraciones, se producen versiones cada vez más completas de ingeniería del sistema. 
 
El modelo en espiral se divide en un numeró de actividades estructurales, también llamadas 
regiones de tarea. Generalmente, existen entre tres y seis regiones de tareas. La siguiente 
figura representa un modelo en espiral que contiene seis regiones de tareas. 
 
 
 
 
 
 
 
 
 
 
 
Las seis regiones de tareas son: 
?? Comunicación con el cliente: las tareas requeridas para establecer 
comunicación entre el desarrollador y el cliente. 
?? Planificación: las tareas requeridas para definir recursos, el tiempo y otras 
informaciones relacionadas con el proyecto. 
?? Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y de 
gestión. 
?? Ingeniería: las tareas requeridas para construir una o más representaciones 
de la aplicación. 
?? Construcción y adaptación: las tareas requeridas para construir, probar, 
instalar y proporcionar soporte al usuario. 
?? Evaluación del cliente: las tareas requeridas para obtener la reacción del 
cliente según la evaluación de las representaciones del software creadas 
durante la etapa de ingeniería e implementada durante la etapa de instalación. 
Análisis de Riesgos 
Planificación 
Comunicación con 
el Cliente 
Evaluación del 
Cliente Ingeniería Y construcción 
y terminación 
 12
 
Cada una de las regiones están pobladas por una serie de tareas que se adaptan a las 
características del proyecto que va a emprenderse. Para proyectos pequeños, el número de 
tareas y su formalidad es bajo. Para proyectos mayores y más críticos, cada región contiene 
tareas que se definen para lograr un nivel más alto de formalidad. En todos los casos, se 
aplican las actividades de protección. 
 
Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira alrededor 
de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer 
circuito de la espiral produce el desarrollo de una especificación de productos; los pasos 
siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente 
versiones más sofisticadas del software. Cada paso de la región de planificación produce 
ajustes en el plan del proyecto. El coste y la planificación se ajustan según la reacción ante la 
evaluación del cliente. Además, el gestor del proyecto ajusta el número planificado de 
iteraciones requeridas para completar el software. 
 
A diferencia del modelo de proceso clásico que termina cuando se entrega el software, el 
modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de 
computadora. 
Un proyecto de desarrollo de conceptos comienza en el centro de la espiral y continuara 
hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de 
un producto real, el proceso procede a través del punto de entrada del proyecto de 
desarrollo del producto nuevo y se inicia un nuevo proyecto de desarrollo. El producto 
nuevo evolucionara a través de iteraciones alrededor de la espiral siguiendo el camino que 
limita la región algo más brillante que el centro. 
En esencia, la espiral, cuando se caracteriza de esta forma permanece operativa hasta que el 
software se retira. Hay veces en que el proceso está inactivo, pero siempre que se inicie un 
cambio, el proceso arranca en el punto de entrada adecuado. 
El modelo en espiral es un enfoque realista del desarrollo del sistemas y de software a gran 
escala. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el 
cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. El 
 13
modelo en espiral utiliza la construcción de prototipos como mecanismos de reducción de 
riesgos, pero lo que incorpora al marco de trabajo interactivoque refleja de forma más 
realista 
 14
 
 
 
 
 
Distribución de trabajo para la elaboración del Proyecto 
El Jefe de Proyecto es el encargado de coordinar las diferentes especificaciones del sistema y 
la plena funcionalidad del mismo. 
El Secretario es el encargado de mantener actualizada la Bitácora con el avance del desarrollo 
del software; es de suma importancia para la documentación final. 
Nota: Los cargos son asignados de acuerdo a las calificaciones de los integrantes del equipo 
de desarrollo del proyecto de software. 
 
Hardware disponible para el Equipo de Trabajo: 
 El Equipo de trabajo cuenta con sus propios computadores , para que esto sea tomado en 
consideración para la distribución de tareas que cada integrante pueda manejar y tenga a 
disposición las herramientas necesarias tanto para la Programación, análisis y diseño del 
sistema y de los software de apoyo para la realización de este proyecto. 
 
 
Equipos de Computo: 
?? Pentium III 550 MHz. 64 Mb. Ram, DD 15 Gb. 
Jefe del Proyecto 
Analista Diseñador y 
Secretario 
Jefe del Proyecto 
Analistas Programadores 
Base de 
datos 
SOFTWARE 
DEL SISTEMA 
 15
?? Pentium II 350 MHz. 96 Mb. Ram, DD 6.4 Gb. 
?? Pentium II 333 MHz. 96 Mb. Ram DD 20 Gb. 
?? AMDK6 333 MHz. 48 Mb. Ram DD 2 Gb. 
Software: 
?? Office 2000 
?? Windows 2000 
?? Visual Studio Edición empresarial 
?? Active server Pages 
?? Ms Project 98 
?? SQL server 7.0 
?? Rational Rose 4.0 
?? Erwin 
 
DESARROLLO DE ACTIVIDADES 
Las actividades se desempeñaron de acuerdo a un cronograma establecido por la 
organización, la elaboración de un cronograma de trabajo, cada actividad a realizarse con un 
tiempo tolerable para su normal desarrollo basada en experiencias pasadas. 
Para una mayor orden y control de las evoluciones de las actividades se tomo como 
herramienta para mostrar todos los movimientos de los integrantes y evolución de los mismo el 
software MS Project. 
?? Calendario de actividades 
?? Diagrama de Gantt 
?? Diagrama Pert 
?? Uso de tareas 
?? Uso de Recursos. 
Aquí se describen las actividades y fechas correspondientes para cada una de estas 
actividades. 
Instalaciones para el para el Proyecto de Desarrollo 
La organización cuenta con sus oficinas, donde están instalados todos los equipos y 
materiales, así como una sala de reuniones disponibles durante todo el tiempo de ejecución 
del Proyecto. 
 16
 
ANALISIS DE COSTOS DEL PROYECTO 
 
El análisis de costos es la valoración de la justificación económica para un proyecto de 
sistema basado en computador. El análisis coste / beneficios determina los costes para el 
desarrollo del proyecto y los pondera con los beneficios tangibles ( Cuantificable directamente 
en dinero) y beneficios intangibles del sistema. 
 
El análisis de beneficios variara dependiendo de las características del sistema, en el sistema 
de biblioteca tenemos los siguientes beneficios: 
- Beneficios en las tareas de búsqueda de registros. 
- Beneficios den la capacidad de reestructuración del sistema. 
- Beneficios en la capacidad de análisis y simulación 
- Beneficios en el control del proceso y los recursos. 
- Beneficios en las tareas de calculo e impresión. 
- Beneficios en las tareas de mantenimiento del almacenamiento de información. 
 
El costo del proyecto relacionado con el recurso humano se trata a continuación: 
 
Cabe anotar que las cifras expuestas en las tablas que se presentan a continuación fueron 
consideradas en moneda extranjera ($ dólares americanos), debido a la estabilidad de esta 
moneda en el mercado. 
 
Para conocer el costo del proyecto, inicialmente se calculara los costos por hora para los 
diferentes tipos de recurso humano que se necesita en la elaboración del proyecto. 
 
Definimos la siguiente tabla de sueldos que se dan en promedio en el mercado laboral actual. 
 
TIPO DE RECURSO SUELDO MENSUAL ($) 
Jefe de Proyecto (JP) 1’800 
Analista Programador (AP) 1’200 
Analista Diseñador(AD) 1’500 
Analista Documentador (AS) 1,000 
 
 17
Se asumen las siguientes reglas laborales: 
 
REGLA LABORAL DESCRIPCIÓN 
Aportes al estado ?? FONAVI = 5% 
?? ESSALUD = 9 % 
Número de días útiles ?? 22 días 
 
Número de sueldos ?? 12 sueldos mensuales 
?? 2 gratificaciones 
Sueldos extraordinarios ?? CTS, 1 vez al año y corresponde a un 
sueldo mensual. 
Vacaciones ?? 1 mes al año y corresponde a un sueldo 
mensual. 
Número de horas de trabajo al día ?? 8 horas 
 
 
 
Con estos datos se calcula el costo por mes para un recurso humano. 
 
 
El sistema de biblioteca tiene los costes asociados con el desarrollo de un sistema basado 
en computadora y son: 
Costes de elaboración 
- Costes de instalación de equipos S/.1500.00 
- Costes de personal y de gestión S/.1000.00 
Costes de puesta en marcha 
- Costes del software del sistema operativo S/. 2000.00 
- Costes de Transportes para la puesta en marcha S/. 300.00 
- Costes de gestión necesarios para dirigir la actividad inicial S/1000.00 
Costes relacionados con el proyecto 
- Costes de adquisición del software de aplicación: S/. 6000.00 
?? Microsoft SQL SERVER 7.0 
?? Windows NT 4.0 o superior con Internet Information Server 
?? Visual Studio Edición Empresarial 
?? Microsoft Internet Explorer o Nestcape Navigator o similar 
- Costes de gastos generales S/. 500.00 
- Costes de recogida de información y procedimientos de instalación S/.800.00 
 18
- Costes de preparación de la documentación S/.500.00 
Costes del proceso 
- Costes de mantenimiento del sistema S/.700.00 
- Costes de suministros(electricidad, teléfono, movilidad) S/.400.00 
- Costes de depreciación del hardware S/ 300.00 
 
 
PROGRAMACION Y DESARROLLO DE ACTIVIDADES 
Fase de Concepción 
 
1. Planificación del Proyecto (Plan del Proyecto) 
2. Análisis de Riesgos (Documento de Identificación del Riesgo) 
3. Definición de Requisitos (Documento de Especificación de Requisitos) 
4. Identificación de Clases y Objetos (Documento de Especificación de Objeto): 
Mediante documentación y Entrevistas. 
5. Identificación de Estructuras de Clasificación y Ensamblaje 
6. Identificación de Temas 
7. Establecimiento de Conexiones de Instancia 
8. Comunicación entre Objetos 
9. Construcción del Primer Prototipo 
Fase de Elaboración 
 
1. Diseño de la Estructura Arquitectónica de Datos (Modelado de Base de Datos) 
2. Definición de Clases, Jerarquía de Clases, Objetos, Atributos, Bases de Datos e 
Interrelaciones. 
3. Diseño de la Interfaz 
4. Diseño Procedimental 
 
Fase de Construcción 
 
1. Implementación del servicio de Datos 
2. Implementación del servicio del cliente 
3. Desarrollo del Plan de Procedimientos y Pruebas 
4. Pruebas de Unidad 
 19
5. Pruebas de Integración 
6. Pruebas de Validación 
Fase de transición 
1. Desarrollo del Plan de Entrenamiento (Manual de Usuario, de Sistema) 
2. Lanzamiento y Distribución 
3. Mantenimiento y Garantías de Calidad 
 
Las especificaciones desarrolladas en el MS Project 98 
 
 Formación del 
Equipo del Proyecto 
0d sa 02/09/00 sa 02/09/00 "Jefe, Analista 1, Analista-Programador 1, 
Analista-Programador 2" 
 Tema del Proyecto 26d ma 05/09/00 ma 10/10/00 "Jefe, Analista 1, Analista-Programador 1, 
Analista-Programador 2" 
 Evaluación del 
sistema actual 
5d ma 05/09/00 lu 11/09/00 "Jefe, Analista 1, Analista-Programador 1, 
Analista-Programador 2" 
 Análisis de los 
Requerimientos 
6d ma 12/09/00 ma 19/09/00 3 "Jefe, Analista 1, Analista-Programador 1, 
Analista-Programador 2" 
 Requisitos de los 
usuarios 
6d ma 12/09/00 ma 19/09/00 "Jefe, Analista 1, Analista-Programador 1" 
 Requisitos del 
contenido 
3d ma 12/09/00 ju 14/09/00 3 "Jefe, Analista-Programador 1, Analista-
Programador 2" 
 Requisitos del 
sistema 
3d ma 12/09/00 ju 14/09/00 3 "Jefe, Analista 1, Analista-Programador 1, 
Analista 1,Analista Programador 3" 
 Se construyeel 
Modelo de Objetos 
5d mi 20/09/00 ma 26/09/00 5 "Jefe, Analista 1, Analista-Programador 1, 
Analista-Programador 2" 
 Se define un Modelo 
Dinámico 
4d mi 27/09/00 lu 02/10/00 8 "Jefe, Analista 1, Analista-Programador 2" 
 Documentación del 
Análisis 
4d ma 03/10/00 vi 06/10/00 9 "Analista Programador 2,Analista 
Programador 1,Analista Programador 3" 
 Desarrollo del Plan 
del Proyecto 
2d lu 09/10/00 ma 10/10/00 10 "Analista Programador 2,Analista 
Programador 1" 
 Diseño del Sistema 
Propuesto como 
Proyecto 
24d mi 11/10/00 lu 13/11/00 
 Diseño de la interfaz 
del usuario 
8d mi 11/10/00 vi 20/10/00 "Jefe, Analista 1, Analista-Programador 1, 
Analista-Programador 2" 
 Determinación de Las 
Herramientas a 
utilizar 
2d mi 11/10/00 ju 12/10/00 2 "Jefe, Analista Programador 1, Analista-
Programador 2" 
 Diseño de la Interfaz 4d vi 13/10/00 mi 18/10/00 14 "Analista 1, Jefe, Analista Programador 2" 
 Decidir cómo integrar 
la funcionalidad 
3d vi 13/10/00 ma 17/10/00 14 "Analista 1,Jefe, Analista Programador 3" 
 Cambios en el 
Modelo del Sistema 
3d lu 16/10/00 mi 18/10/00 
 Modelo final del 
Sistema 
2d ju 19/10/00 vi 20/10/00 15 "Jefe, Analista Programador 2" 
 Diseño de la base de 
datos 
16d lu 23/10/00 lu 13/11/00 18 "Jefe, Analista 1" 
 20
 Determinación de la 
base de datos 
2d lu 23/10/00 ma 24/10/00 "Jefe, Analista Programador 3" 
 Especificaciones de 
la base de datos 
2d lu 23/10/00 ma 24/10/00 "Analista 1,Jefe" 
 Determinación Final 
de la Base de Datos 
2d lu 23/10/00 ma 24/10/00 Analista 1 
 Diseño de la Base de 
datos 
3d mi 25/10/00 vi 27/10/00 "20,
21,2
2" 
"Analista 1,Jefe" 
 Construcción de la 
Base de Datos 
2d lu 30/10/00 ma 31/10/00 23 "Analista 1,Jefe" 
 Progracion de la base 
de datos 
9d mi 01/11/00 lu 13/11/00 24 "Analista 1,Jefe" 
 Determinación de la 
Infraestructura De 
soporte Técnico 
6d lu 30/10/00 lu 06/11/00 Analista 1 
 Determinar el impacto 
en los Usuarios 
3d lu 30/10/00 mi 01/11/00 23 "Analista Programador 2, Analista 1, 
Analista Programador 1" 
 Identificar los 
cambios necesarios 
3d ju 02/11/00 lu 06/11/00 27 "Jefe, Analista Programador 3,Analista 
Programador 2" 
 Requisitos de 
soporte cumplidos 
0d lu 06/11/00 lu 06/11/00 28 "Analista 1,Analista Programador 3" 
 Desarrollo del Diseño 42d lu 23/10/00 ma 19/12/00 "Jefe, Analista 1, Analista-Programador 1, 
Analista-Programador 2" 
 Desarrollo de 
páginas y vínculos 
23d lu 23/10/00 mi 22/11/00 
 Creación de la 
'plantilla' HTML 
3d lu 30/10/00 mi 01/11/00 18 "Analista Programador 2, Analista 
Programador 1, Analista Programador 1" 
 Determinación de la 
herramienta de 
desarrollo 
1d lu 23/10/00 lu 23/10/00 18 "Jefe, Analista 1" 
 Desarrollo 15d ju 02/11/00 mi 22/11/00 "32,
33" 
"Jefe, Analista 1" 
 Desarrollo de la 
funcionalidad 
27d lu 23/10/00 ma 28/11/00 "Jefe, Analista 1" 
 Desarrollo de 
funciones 
personalizadas 
15d lu 23/10/00 vi 10/11/00 18 "Jefe, Analista 1" 
 Integración en las 
paginas 
4d ju 23/11/00 ma 28/11/00 "34,
36" 
"Jefe, Analista 1" 
 Especificación de los 
contenidos y 
Conexión con la base 
de datos 
27d ma 31/10/00 mi 06/12/00 "Jefe, analista 1" 
 Identificación de los 
contenidos de la 
base de datos 
3d ma 31/10/00 ju 02/11/00 6 "Jefe, analista 1 
 Prioridad de la 
conversión de 
contenido 
2d vi 03/11/00 lu 06/11/00 39 "Jefe, analista 1 
 Definición de las 
normas de 
conversión de 
contenido 
2d ma 07/11/00 mi 08/11/00 40 "Jefe, analista 1 
 Realización de la 
conversión y 
15d ju 09/11/00 mi 29/11/00 41 "Jefe, analista 1 
 21
migración de 
contenido 
 Prueba de los 
formatos de 
conversión 
5d ju 30/11/00 mi 06/12/00 42 "Jefe, analista 1 
 Pruebas 24d ju 16/11/00 ma 19/12/00 
 Prueba de las 
páginas 
10d ju 16/11/00 mi 29/11/00 34C
C+1
0d 
"Analista Programador 2,Jefe, analista 
Programador 1" 
 Prueba de los 
vínculos 
6d ju 23/11/00 ju 30/11/00 45F
C-
5d 
"Jefe, analista Programador 3,Analista 1" 
 Prueba del uso 9d ju 07/12/00 ma 19/12/00 "34,
37,4
3,45
,46" 
"Analista Programador 2,Analista 1" 
 Implementación Final 
del Modelo 
17d ju 07/12/00 vi 29/12/00 
 Mejoras del modelo 
después de las 
Pruebas 
3d ju 07/12/00 lu 11/12/00 "34,
37,4
3,45
,46" 
"Jefe, analista 1" 
 Revisión de la base 
de datos Final 
4d vi 08/12/00 mi 13/12/00 30F
C-
20d 
"Analista Programador 2,Jefe, analista 
Programador 1,Analista 1" 
 Funcionamientos 
final del Modelo 
2d ju 14/12/00 vi 15/12/00 50 
 Revisión Final 0d vi 29/12/00 vi 29/12/00 51F
C+1
0d 
"Jefe, Analista 1, Analista-Programador 1, 
Analista-Programador 2" 
 Documentación Final 
y Soporte 
14d mi 20/12/00 lu 08/01/01 
 Documentación Final 
del proyecto 
3d mi 20/12/00 vi 22/12/00 29 "Analista Programador 2,Analista 
Programador 1,Analista 1" 
 Documentación del 
Manual 
4d lu 25/12/00 ju 28/12/00 54 Jefe 
 Documentación del 
Plan de desarrollo del 
Proyecto 
2d vi 29/12/00 lu 01/01/01 55 "Analista Programador 2,Analista 
Programador 1" 
 Determinar el 
proceso de soporte 
5d ma 02/01/01 lu 08/01/01 56 "Analista Programador 2,Jefe, analista 
Programador 1" 
 Modificaciones Y 
cambios en el 
Modelo Final 
pruebas respectivas 
y documentación 
final del Proyecto 
2d lu 01/01/01 ma 02/01/01 "Analista Programador 3,Analista 1" 
 
ETAPA DE ANÁLISIS 
 
ANTECEDENTES 
 
 22
La importancia del tema propuesto reside en desarrollar un modelo que contenga 
dentro de su estructura los elementos que representan una realidad al sistema de 
prestamos que se dan en las bibliotecas. La unificación de conceptos que conlleva la 
estandarización propuesta permite el manejo más uniforme de la información 
involucrada, lo que ayuda a una mejor comprensión de la misma por las distintas 
entidades organizacionales que potencialmente utilizarán el modelo. 
 
El desarrollo del proyecto implica la utilización de propuestas basadas en métodos 
orientados a objetos, de los cuales hasta el momento no se conocen muchas 
aplicaciones, sirviendo así para ver en forma practica el desempeño que éstos tienen 
en una situación real de negocios. 
 
 
 
OPERACION DEL SISTEMA ACTUAL 
 
En un principio el Sistema de la Biblioteca Universitaria realiza sus transacciones de 
manera manual, en vista de las desventajas que presentaba se implemento un sistema 
mecanizado basado en un lenguaje Microisis el cual no es atractivo para el usuario y no 
brinda una seguridad para la datos. 
 
En la actualidad se usan lenguajes visuales, base de datos relacionales y las tecnologías de 
internet para el desarrollo de este tipo de sistemas por que ofrecen mayor facilidad, 
seguridad y beneficios a los usuarios, dentro de un campus universitario como desde sus 
hogares o desde cualquier lugar remoto accesible a través de Internet. 
 
Por todos estos inconvenientes que se presentan; el usuario sigue realizando colas para la 
obtención de los códigos de las publicaciones que necesita y para la hacer efectivo su 
préstamo que en algunos casos llegada a la ventanilla se dan con la sorpresa que la 
publicación solicitada no se encuentra disponible. 
Las actividades que se realizan son las siguientes: 
 
 23
?? Búsqueda 
El usuario llega a la Biblioteca Universitaria y lo primero que hace es ir a la maquina 
que se encuentran disponibles para la búsqueda sobre el documento que desea; si este 
no puede darle la referencia, existen los ficheros al cual los usuarios acceden como 
ultima opción. Luego que encuentran al ejemplar, llenan la ficha de préstamo. 
 
?? Préstamo 
 
Si encuentra la bibliografía requerida se le entrega una ficha, para que el usuario 
posteriormente la llene con sus datos personales, código universitario, fecha en la que 
se retira el libro de la biblioteca, firma, titulo y autor del libro clasificación a la que 
pertenece el libro y sus registros respectivos. 
 
La Ficha de Préstamo se muestra a continuación 
 
Luego del llenado de la ficha, se entregaesta junto con el documento de identificación 
del usuario para poder corroborar los datos de la ficha y el documento. 
 
?? Devolución 
 
El usuario lleva el libro y se lo entrega al bibliotecario, el cual verifica el estado del 
libro, luego busca el documento de identidad del usuario que encuentra junto con la 
ficha de prestamos; verificando los datos de la ficha que concuerden con el libro 
devuelto. Seguidamente se compara la fecha de entrega y la de devolución, si es que 
 
BIBLIOTECA UNIVERSITARIA 
 CLASIFICACION AUTOR 
No Registro TITULO 
LECTOR 
CARNET FECHA 
FIRMA 
 24
ésta se encuentra dentro de la fecha limite de entrega se devuelve el documento de 
identificación del usuario; de lo contrario se procede a retener el documento y aplicar 
la sanción respectiva por los días de posesión del libro. 
 
?? Catalogación 
 
La catalogación se aplica según el sistema internacional de clasificación ( Tabla de 
Dewey). Este sistema tiene una serie de reglas con las cuales se guía el bibliotecario 
para catalogar los libros. 
Para las tesis se catalogan de acuerdo al apellido y al orden en que llegan. 
Para las revistas se clasifican de dos maneras, la primera es colocando el nombre de la 
institución que los dona y la otra es colocando las tres primeras letras del titulo y el 
número de su llegada. 
 
A continuación se muestra una modelo de la ficha de catalogación. 
 
4.1.2. Restricciones del Sistema Actual 
 
?? Desactualización de los ficheros existente. Existen revistas y folletos que no están 
registrados en este catálogo, es decir no concuerda con el inventario existente. 
?? Desactualización de la Base de Datos que utiliza el sistema mecanizado, no concuerda 
con el inventario real existente. 
?? El sistema mecanizado actual esta desarrollado en Microisis y con una interfaz poco 
amigable al usuario y es incapaz de realizar funciones como por ejemplo no lista 
sancionados, no lista el inventario real existente, tampoco muestra si hay pérdidas de 
600.4058 
WIN 
 
Winston Delay, Ronald Smith 
 
"Adminis tración de Operaciones" 
Editorial Mac Graw Hill. 
Año 1990. 
 
 25
libros, no compara fechas limites para la devolución de libros, por lo tanto no se 
puede aplicar ninguna penalidad usando este sistema. 
?? Este sistema solo permite hacer búsquedas por autor y titulo de libro requiriéndose 
muchas veces hacer búsquedas por palabras clave. 
?? El sistema fue diseñado simplemente para uso monousuario, solo para que las 
búsquedas sean hechas por el servidor de la biblioteca. 
 
 
4.1.3. El Sistema Propuesto o Mejorado 
 
?? El sistema Automatizado para la atención de los Usuarios de la Biblioteca 
Universitaria de la Universidad Nacional de Piura, logrará cumplir de una manera más 
efectiva con los fines para la cual ha sido creada, como es aumentar el conocimiento y 
apoyar la investigación científica. 
?? El sistema que se propone es para que los usuarios de la biblioteca tengan acceso a 
una web que da los servicios de préstamo, reservación y venta de publicaciones, para 
los usuarios que se encuentran suscritos por medio de la INTERNET lo puedan 
realizar desde sus hogares, evitándoles así las engorrosas colas que se tienen que 
realizar para acceder a las publicaciones. 
?? En el sistema se podrá realizar la reservación de una publicación durante el tiempo ya 
establecido. 
?? Es un sistema que agilizará la actividad de solicitud bibliográfica en la Biblioteca. 
?? Le va a permitir al usuario visualizar el contenido de la bibliografía existente sobre el 
tema que solicite. 
?? Será intuitiva, de fácil uso y mostrara una interfaz gráfica amigable al usuario. 
?? El sistema mostrará consultas sobre: morosos, inventarios, pérdidas; también tendrá 
en cuenta el tiempo límite de préstamos para poder aplicar las sanciones respectivas a 
los usuarios que no cumplan esta regla. 
?? También incluirá las búsquedas por palabra clave, lo cual permitirá abarcar una mayor 
cantidad de bibliografía relacionada con ella. 
 26
 
 
 
 
 
 
 
 
FASE DE ELABORACION DEL PROYECTO 
 27
ETAPA DE ANÁLISIS DE REQUERIMIENTOS 
 
Definición del Problema 
 
Analizando la documentación del sistema de Biblioteca que actualmente posee la 
Biblioteca Universitaria, se encontró un sistema que permite hacer solamente búsquedas 
de documentos en una base de datos, este sistema que actualmente se emplea esta 
basado en un sistema desarrollado bajo el software de Microisis. 
 
La propuesta para el nuevo sistema es ampliar los servicios que ofrece mediante la 
agregación de reservas y consultas a través de Internet, las cuales podrán ser realizadas 
por los alumnos debidamente registrados en el sistema lo que proporcionará una serie de 
ventajas a los alumnos al hacer uso de un sistema más completo y confiable. 
 
Análisis de los requerimientos de Software. 
 
En esta fase de desarrollo se inicia mostrando los requerimientos del sistema de 
información los cuales se encuentran descritos a continuación: 
 
a) Descripción de los requerimientos: 
El usuario puede hacer búsquedas de textos ya sea por autor, titulo o materia, el 
sistema le presentará si es que fuera el caso una relación de las publicaciones que 
coinciden con el criterio de búsqueda ingresado. A la vez le mostrará el estado de la 
publicación es decir si se encuentra prestada, reservada o disponible para la venta. 
 
Las reservaciones hechas a través de Internet tienen una vigencia determinada, pasado 
ese tiempo la publicación queda nuevamente a disposición, de los usuarios. 
 
Los datos requeridos para un Libro son: 
?? Número de registro 
?? Clasificación 
?? Autor 
 28
?? Titulo 
?? Numero de Páginas 
?? Fecha de Ingreso 
?? Descriptores 
?? Resumen 
?? Editorial 
?? Descripción 
 
Referente a los servicios que brinda la Biblioteca se encuentran los siguientes: 
?? Atender los prestamos y devoluciones de los libros a los usuarios. 
?? Recepción, catalogación, clasificación y ubicación física de los libros en el 
ambiente de la biblioteca. 
?? Registrar los libros que ingresan a la biblioteca. 
?? Control de usuarios sancionados y aquellos que tengan mora en la devolución 
de libros. 
 
b) De los requerimientos del Software. 
El producto de software a construir debe ser tal que los usuarios tengan acceso a las 
consultas, debe proporcionar integridad y seguridad de los datos. 
 
Ofrecer a los usuarios acceso vía Internet tanto a búsquedas, reservas y compras a los 
usuarios debidamente registrados. 
 
La funcionalidad del sistema debe ser tal que permita realizar todos los servicios de la 
gestión de biblioteca. 
 
Reservación: va el usuario por medio de una pagina web podrá realizar la 
reservación de uno de los ejemplares que se encuentren en la base de datos para ello 
debe estar suscrito en la biblioteca. 
 29
La reservación se realiza cuando el usuario luego de haber seleccionado el libro de su 
preferencia de la relación de libros que ha resultado de su búsqueda, aparecerá una 
ventana que le pedirá su password para hacer efectiva dicha reservación. 
 
Análisis de Riesgos: 
Entre los posibles riesgos que hemos podido observar presentamos: 
?? Uno de los principales riesgos es debido a una evaluación del coste de desarrollo 
sopesado con los beneficios obtenidos del sistema desarrollado. 
?? El estudio de rendimiento y restricciones de nuestro sistema que puedan afectar a la 
consecuencia de que sea aceptable o no. 
?? La viabilidad legal, es decir si incurrimos en alguna infracción, violación o 
responsabilidad legal, con lo que respecta a los ejemplares. 
?? Se emplean regularmente hardware y software para el control de sistemas de 
seguridad critica. 
?? No responde cuando se activa alguna pagina web. 
?? Algunas veces no se tiene disponibilidad de recursos (hardware y software) 
necesarios para la construcción del sistema. 
?? Otro riesgo es el progreso de la tecnología respectivahasta un punto que sea capaz 
de soportar el sistema. 
 
Análisis Técnico 
En este análisis se evalúa los principios técnicos del sistema al mismo tiempo que se 
recoge información adicional sobre el rendimiento, fiabilidad, características de 
mantenimiento y productividad. 
Los requerimientos de tecnología los hemos definido anteriormente, agregando lo 
relacionado con la conexión a Internet. 
MODELO CONCEPTUAL 
 
Una cualidad esencial que debe ofrecer un modelo conceptual es que represento no 
componentes del software sino cosas del mundo real. En el UML, lo ilustraremos con un 
grupo de diagramas de estructura estática donde no se define ninguna operación. 
 
 30
 
Objetos físicos o tangibles: Publicación 
Mostrador de Biblioteca 
Especificaciones, diseño o descripciones de 
cosas: 
Estado de la publicación 
Formulario de Compras 
Formulario de Nuevo inscrito 
Plazo de Reserva 
Resultado de Búsqueda 
Sanciones al cliente 
Deudas del cliente 
Reservas del Cliente 
Lugares: Biblioteca Universitaria 
Internet 
Transacciones: Venta de publicaciones 
Pago con tarjeta de Crédito 
Reservar publicaciones 
Devolver publicaciones 
Línea o reglón de elementos de transacción Publicación Prestada 
Publicación reservada 
Papel de las Personas: Cliente 
Operador (Bibliotecario) 
Sistemas externos al sistema: Sistema de Autorización de Tarjetas de 
Crédito 
Conceptos de Nombres Abstractos: Suspendido 
Sancionado 
Organizaciones: Dpto. Catalogación, Dpto. Ventas 
Eventos: Venta, préstamo, Reserva, Devolución, 
Retiro, mantenimiento, etc. 
Procesos : Venta de una publicación 
Reserva de una publicación 
 31
Objetos físicos o tangibles: Publicación 
Mostrador de Biblioteca 
Préstamo de una publicación 
Devolución de una publicación 
Reglas y políticas: Política de Sanciones 
Políticas de Reservas 
Políticas de Préstamo 
Políticas de Cancelaciones 
Políticas de Ventas 
 
 32
 
DIAGRAMA DE CASO DE USO 
 
suscripcion
retirar suscripcion
borrar prestamo
borrar reserva
realizar prestamo
reponer publicacion
Cliente
Operario
control de acceso
Validar clave y passwoed
Hacer Reserva
<<uses>>
Hacer busqueda
<<uses>> Agente
correo_delivery
download
transaccion de venta
<<uses>>
entregar libros
<<extends>>
<<uses>>
amonestaciondevolver publicacion
catalogacion
capturar indice
ingresar nueva publicacion
retirar publicacion
mantenimiento de publicacion
<<extends>>
<<uses>>
<<uses>>
<<extends>>
 
 33
 
 
Funciones del Sistema 
 
 
 
 
??Funciones Básicas: Levantar Reservar, Sancionar préstamos según el tiempo. 
 
R.1.1. El cliente debe introducir una clave para que el 
sistema realice la búsqueda en base a este patrón. 
EVIDENTE 
R.1.2. Ofrece mecanismo de comunicación entre los 
procesos y entre los sistemas. 
EVIDENTE 
R.1.3. Muestra la descripción y el Estado (prestado, 
reservado, en mantenimiento) de las publicaciones 
encontradas 
OCULTA 
 
 
 
 
 
 
??Funciones de Hacer Reservas: 
 
R.2.1. El cliente debe haber 
seleccionado una publicación 
especifica para poder hacer la 
reserva. 
EVIDENTE 
R.2.2. El cliente debe introducir una 
identificación y su contraseña 
EVIDENTE 
 34
para poder hacer su reserva. 
R.2.3. Ofrece un mecanismo de 
almacenamiento persistente. 
OCULTA 
R.2.4. Ofrece un mecanismo de 
comunicación entre los 
procesos y el sistema. 
OCULTA 
R.2.5. Se registra la reserva. OCULTA 
R.2.6. Muestra el estado de la 
reservada (Aceptado, 
Rechazado y sus motivos) 
como el plazo de vigencia. 
EVIDENTE 
R.2.7.Actualiza la página para mostrar 
su reservada. 
EVIDENTE 
R.2.8.El sistema debe hacer el control 
del tiempo valido para reserva. 
OCULTA 
R.2.9.El Sistema debe descartar 
reservas caducas. 
OCULTA 
 
 
 
 
 
??Funciones de Borrar Reservas: 
 
R.3.1. El cliente u operador debe 
introducir un identificador y una 
contraseña para poder tener la 
opción de borrar reserva. 
EVIDENTE 
R.3.2. Actualizar la base de datos 
cambiando el estado de reserva 
OCULTA 
 35
de la publicación. 
 
 
 
??Funciones Realizar Prestamos: 
 
R.4.1.El operador debe introducir un 
identificador y una contraseña 
para poder tener la opción de 
realizar prestamos. 
EVIDENTE 
R.4.2. Actualizar la base de datos 
cambiando el estado de reserva 
de la publicación. 
OCULTA 
R.4.3.Captura la información del 
cliente que ha reservado a 
través de su código o selección 
de la publicación reservada. 
OCULTA 
R.4.4. El operador confirma o cancela 
el préstamo. 
EVIDENTE 
 
 
??Funciones devolver publicaciones: 
 
R.5.1.El operador debe introducir un 
identificador y una contraseña 
para poder tener la opción de 
devolver publicaciones. 
EVIDENTE 
R.5.2.Captura de la información de la 
publicación a devolver a través 
del ingreso manual del código 
OCULTA 
 36
de la publicación.. 
R.5.3.Actualiza la Base de Datos, 
cambiando el estado de 
prestado a la publicación. 
OCULTA 
R.5.4.Mostrar las sanciones que 
incurra el cliente. 
 
EVIDENTE 
 
??Funciones borrar préstamo: 
 
R.6.1.El operador debe introducir un 
identificador y una contraseña 
para poder tener opción a 
borrar el préstamo. 
EVIDENTE 
R.6.2.Actualizar la base de datos, 
cambiando el estado el 
préstamo de la publicación. 
OCULTA 
 
 
??Funciones de Transacción Venta: 
 
R.7.1.Captura la información sobre el 
cliente que va a comprar ya sea 
capturando datos del formulario 
y de su login y password. 
EVIDENTE 
R.7.2.Reduce las cantidades del 
inventario cuando se realiza una 
venta. 
OCULTA 
R.7.3.Actualiza las Bases de Datos 
con información de la 
OCULTA 
 37
publicación vendida. 
 
 
??Funciones de Entrega de Libros: 
 
R.8.1.Imprimir las partes de la 
publicación vendidas. 
EVIDENTE 
R.8.2.Imprimir el destinatario de la 
publicación vendida. 
EVIDENTE 
R.8.3.Actualizar la base de datos 
modificando el estado de la 
impresión. 
OCULTA 
 
 
??Funciones Básicas: 
 
R.9.1.Registrar las reservas, 
prestamos, devoluciones de las 
publicaciones. 
EVIDENTE 
R.9.2.Calcular los tiempos de reserva, 
prestamos y sanciones. 
EVIDENTE 
R.9.3.Captura la información sobre 
cliente, operador, 
publicaciones, login, claves, 
catálogos, índices. 
EVIDENTE 
R.9.4.Reduce las cantidades a 
reservas, a prestar es decir el 
inventario. 
OCULTA 
R.9.5.Registro las transacciones 
(reserva, préstamo y 
OCULTA 
 38
devolución.). 
R.9.6.El operador o cliente deben 
introducir una identificación y 
una contraseña para poder 
utilizar el sistema o acciones 
específicas. 
EVIDENTE 
R.9.7.Ofrece un mecanismo de 
almacenamiento persistente. 
OCULTA 
R.9.8.Ofrece mecanismo de 
comunicación entre los 
procesos y entre los sistemas. 
OCULTA 
R.9.9.Muestras la descripción y 
estado de los productos. 
OCULTA 
 
 
CASOS DE USOS 
 
 
CASOS DE USO EXPANDIDO: 
 
 
Caso de Uso: Hacer Búsqueda. 
Actores : Cliente (iniciador) 
Propósito : Presentar una lista de publicaciones 
aproximada a la cadena de búsqueda para 
venta, reserva, o información del mismo. 
Tipo : Primario y Especial. 
Resumen : El cliente accede a la página principal de la 
biblioteca e introduce una cadena de 
búsqueda, en la casilla respectiva, luego da un 
click en el botón aceptar o un Enter, luego se 
 39
le mostrará una lista de resultados 
Con opciones de reserva y/o compra, así 
como el estado de los mismos. 
Referencias Cruzadas: R1.3,R1.4,R4.2,R9.9 
 
 
Curso Normal de los Eventos: 
 
Acciones de los actores Respuesta del Sistema 
1. El cliente se ubica en la dirección de la 
página principal del sistema de biblioteca 
2. El sistema muestra la página principal y la 
casilla de búsqueda 
3. El cliente ingresa palabra clave, de 
búsqueda, presiona enter o hace click en 
buscar. 
4. El sistema construye la lista de 
publicaciones coincidente con las palabrasclaves y lo muestra junto con el estado de los 
mismos. 
5. El cliente lee el resultado y toma una 
decisión (reservar, comprar, leer o salir.) 
 
 
 
Caso de Uso Extendido: Hacer Búsqueda 
 
1. Precondiciones: 
 
??El sistema debe contar con las siguiente información: 
o Cadena de Búsqueda. 
??El cliente debe haber navegado a la página principal de la Biblioteca. 
 
2. Flujo Principal: 
 
o Este caso de uso empieza cuando el cliente ingresa en la casilla de texto una 
cadena y selecciona una de las opciones de búsqueda (todos, libros, revistas, 
 40
tesis, folletos, mapas, periódico,...) según la figura B1 y luego presiona 
Buscar. 
o El sistema realiza la búsqueda con la categoría seleccionada si es todos, no 
coloca limites de categorías. 
o El sistema construye la página de resultados según la figura B2, esta es 
compaginada según la cantidad de publicaciones encontradas. 
o En la página de resultados el cliente puede elegir uno de los número s de 
página indicados y obtendrá los resultados correspondientes a dicha página. 
o También se muestra el casillero de búsqueda con opciones de filtrar por 
categoría de igual forma como en la página principal. 
o Además cada publicación muestra la respectiva opción de la publicación 
indicada: Reservar o comprar. 
o Si selecciona la opción Reservar se ejecuta el Caso de uso Hacer Reserva 
o Si sé selecciona la opción Comprar se ejecuta el caso de uso Venta de 
publicación. 
 
Diseño de la Pantalla para Caso Uso Hacer Búsqueda 
 
Se representa en una pantalla principal lo referente a la búsqueda por palabra clave en la cual 
tiene que contemplar un cajón texto en donde se ingrese dicha palabra clave, luego de 
ingresada dicha palabra se deberá ejecutar la búsqueda y para ello se presenta un botón de 
búsqueda el cual permitirá ejecutar dicho proceso que dando la pantalla con respecto a la 
búsqueda de la siguiente manera. 
 41
 
 
Para el resultado de la búsqueda se debe presentar una pantalla que liste dicho resultado y 
para ello se construye la siguiente pantalla en donde se debe presentar el resultado dentro de 
un cuadro para que se muestre ordena y entendible para el usuario los atributos mas saltantes 
de las publicaciones como lo referido a : Titulo de la Publicación, el tipo, su disponibilidad 
física, si se encuentra en venta, si existe disponibilidad la publicación en medio electrónico, y 
una columna de detalles en donde tiene que especificar el enlace a los ejemplares que 
presentan el contenido de los capítulos de determinada publicación. 
 
 
 
 
 42
Caso de Uso: Hacer Reserva. 
Actores : Cliente (iniciador) 
Propósito : Reserva una cierta publicación por un tiempo 
determinado. 
Tipo : Primario y Esencial. 
Resumen : El cliente luego de los resultados de la 
búsqueda ingresa su identificación y clave y el 
sistema le devuelve un mensaje de reservado 
con éxito, reserva a destiempo o No logrado. 
Referencias Cruzadas: R1.3, R.2.1, R.2.2, R.2.5, R.2.6, R.2.7, 
R.2.8, R.2.9, R.3.2, R.4.2, R.5.4 
 
Curso Normal de los Eventos: 
 
Acciones de los actores Respuesta del Sistema 
1.Este caso de uso comienza cuando el cliente 
luego de la búsqueda decide reservar una 
publicación, cuyo estado lo permita dando 
un click para este caso. 
2. El sistema solicita su identificador y su 
clave. 
3.El cliente ingresa su identificación y su clave. 4. El sistema verifica si es usuario registrado. 
 5.Verifica si el cliente no tiene sanciones. 
 6. Verifica si el cliente no tiene deudas. 
 7. Verifica si no tiene reservas. 
 8. El sistema verifica si la publicación esta 
disponible de reserva. 
 9. Reserva la publicación (actualiza B.D.) 
 10. Calcula y presenta el plazo y tiempo total 
de reserva de las publicaciones. 
 
Cursos Alternos: 
 43
 
3. El cliente cancela la reserva. No se prosigue y vuelve a la página. 
4. El cliente no es usuario registrado. Mensaje de error clave intente de nuevo, vuelve al 
paso 2. 
5. El cliente tiene sanciones. No se prosigue, mensaje de sanciones y vuelve a la página 
principal. 
6. El cliente tiene deudas. No se prosigue, mensaje de deudas y vuelve a la página principal. 
7. El cliente tiene reservas. No se prosigue, mensaje de reservas activas, vuelve a la página 
principal. 
8. La publicación no esta disponible, no se prosigue , mensaje no disponible, se vuelve a la 
página principal. 
 
Caso de Uso Extendido: Hacer Reserva 
 
1. Precondiciones: 
 
??El sistema debe contar con las siguiente información: 
o Información del Cliente: código, login, password, estado (activo, suspendido, 
deuda, con reserva). 
o Información de la Publicación: Código, Categoría, Estado(disponible, 
prestado, reservado, mantenimiento) 
??El cliente debe haber ejecutado el caso de uso hacer búsqueda. 
 
2. Flujo Principal: 
 
o Este caso de uso empieza cuando el cliente Hacer reserva en el Caso de Uso 
hacer Búsqueda. 
o El sistema presenta el formato de validación de la figura R1, que solicita al 
cliente su login y su pasword. 
o Si selecciona la opción Aceptar: Subflujo S1: verificar cliente y estado de la 
publicación se ejecuta el Caso de uso Hacer Reserva 
 44
o Si sé selecciona la opción Cancelar: Subflujo S2: Cancelar la reserva de la 
publicación. 
 
S1: Verificar el cliente y estado de la publicación: 
 
o El sistema verifica el login y el password del cliente (E1) 
o El sistema consulta del estado de la publicación elegida 
o Si la publicación esta disponible el sistema modifica su estado a reservado, lo 
asigna al cliente y presenta en la misma ventana el éxito de la operación, esta 
ventana se cierra cuando da click en aceptar. 
o Si la publicación esta reservada o prestada, el sistema presentará la fecha en 
que estará disponible dicha publicación. 
o Si la publicación esta en mantenimiento, se presentará un mensaje indicando 
que la publicación esta fuera de servicio. 
 
S2 : Cancela la Reserva de un libro 
o La ventana S1 se cierra. 
 
3. Flujos de Excepción 
E1: El sistema muestra un mensaje informando que el cliente esta 
suspendido(sancionado) 
 
o El sistema cierra la ventana R1 
 
E2: El sistema muestra un mensaje por que el cliente no es válido o no esta registrado 
 
o El sistema cierra la ventana R1 
 
E3: El sistema muestra un mensaje por que el cliente tiene deudas, prestamos o 
reservas. 
 
 45
o El sistema cierra la ventana R1 
 
Diseño de la pantalla para el Caso de Uso de Reservar 
 
Aquí se tiene que ver una pantalla que permita la actor ingresar su login y su password y para 
ello se debe presentar cajones texto de nombre login y password respectivamente y unos 
botones para realizar la ejecución de dicho proceso de reserva y para ello se presenta la 
siguiente pantalla: 
 
 
 
Caso de Uso: Realizar Préstamo. 
Actores : Cliente (iniciador), operador 
Propósito : Entregar la publicación reservada al cliente 
respectivo. 
Tipo : Primario y Esencial 
Resumen : El cliente luego de reservar una publicación y 
durante el plazo que dure esta se acerca al 
operador y solicita la publicación que reservo, 
identificándose con su carnet, el operador 
ubica la publicación actualiza el sistema con el 
préstamo y entrega publicaciones al cliente. 
Referencias Cruzadas: R.4.1, R.4.2, R.4.3, R.4.4 
 
Curso Normal de los Eventos: 
 
Acciones de los actores Respuesta del Sistema 
 46
1.Este caso de uso comienza cuando un 
cliente llega a la recepción y solicita un 
préstamo. 
 
2.El operador registra al cliente con su código 
de carnet. 
3.Determino la publicación reservada. 
 4.Verifica si cumple con el plazo de reserva. 
 5.Registra la publicación (Actualiza la B.D.) 
 6.El sistema solicita la confirmación de la 
acción. 
7. El operador ubico el libro 8.Actualizo la reserva por prestamos. 
 9.Muestra mensaje de operación exitosa. 
10.El operario entrega publicación al cliente. 
11.El cliente recibe la publicacióny se retira. 
 
 
Cursos Alternos: 
 
3. La publicación no se encuentra, no seguir, mensaje que el cliente no tiene publicaciones 
reservadas. 
4. Plazo de reserva vencido, No seguir, mensaje de plazo vencido, regresa a la página 
principal. 
7. El operador no encuentra la publicación, se cancela la transacción. 
 
Caso de Uso: Realizar Préstamo 
 
1. Precondiciones: 
 
??El sistema debe contar con las siguiente información: 
o Información del cliente: código, nombre, estado(Activo, Suspendido, Deuda, 
con Reserva) 
 47
o Información de la publicación: código, título, estado(Disponible, Reservado, 
Prestado, Mantenimiento) 
o Informe de sanciones: Sanciones, devolución 
??El operador debe ejecutar el caso de uso control de acceso. 
 
2. Flujo Principal: 
 
o Este caso de uso empieza cuando el operador elige en el menú principal del 
sistema la opción de Realizar Préstamo. 
o El sistema presenta al operador el formulario de préstamo de la figura P1, que 
solicita el código del carnet del cliente. 
o El operador introduce el código del cliente y selecciona una de las opciones 
del final del formulario: Aceptar o Cancelar 
o Si elige la opción Aceptar: Subflujo 1: Verificar Cliente y estado de la 
publicación 
o Si elige la opción Cancelar: Subflujo 2: Cancelar Préstamo. 
 
S1: Verificar Cliente y Estado de la Publicación: 
 
o El sistema verifica el código del cliente (E1. 
o El sistema consulta la publicación reservada por el cliente. 
o Si la publicación existe, el sistema muestra la información de ella según como 
se aprecia en la figura P2, y selecciona Cancelar o Aceptar Préstamo. 
El operador deberá ubicar la publicación descrita en la figura P2 y escoger 
entre Cancelar o Confirmar el Préstamo. 
El sistema modifica el estado a Prestado asignándolo al cliente y calcula la 
fecha de devolución de la publicación. 
o Si la publicación no existe, el sistema presenta al operador el gráfico P3, 
donde informa que el cliente no ha reservado ninguna publicación o se ha 
vencido el plazo de reserva. 
 
 48
S2: Cancelar el Préstamo de la Publicación: 
 
o El sistema regresa al menú principal. 
 
 
3. Flujos de Excepción: 
E1 : El sistema presenta un mensaje informando que el Cliente no existe 
 
o El sistema regresa al menú principal 
 
Diseño de pantalla para el Caso de Uso de Realizar Prestamo 
 
Se debe presentar una pantalla que liste todas las reservaciones que hasta la fecha se hallan 
llevado acabo con el fin de cuando la persona se presente ante el operador el rápidamente la 
localice y haga efectivo su préstamo, para que el operador pueda realizar el préstamo deberá 
la pantalla tener un botón que permita que este proceso se lleve acabo, también debe llevar un 
botón de actualizar el cual permitirá ver la ultimas reservas que se están realizando 
 
 
 
Caso de Uso: Devolver Publicación 
Actores : Operador 
 49
Propósito : Registrar la devolución de una publicación 
prestada. 
Tipo : Primario y Esencial 
Resumen : El cliente se acerca con la publicación 
prestada hacia el mostrador donde hace 
entrega de ella al operador para su descarga 
respectiva.. 
Referencias Cruzadas: R.5.2, R.5.1, R.5.3, R.5.4 
 
Curso Normal de los Eventos: 
 
Acciones de los actores Respuesta del Sistema 
1.Este caso de uso comienza cuando el cliente 
llega al mostrador y entrega la publicación. 
. 
. 
2.El operador registra la publicación 
ingresando el código respectivo de la 
publicación. 
3.Determina el cliente que lo prestó 
 4.Verifica si cumple el plazo de devolución. 
 5.Devuelve la publicación(actualiza B.D.) 
 6.El sistema solicita confirmación de 
devolución. 
7.El operador confirma la devolución. 8.Actualiza el préstamo disponible. 
 9.Muestra mensaje de operación exitosa. 
10.El operador se retira del mostrador. 
 
Cursos Alternos: 
 
3.Cliente no determinado, error de cajero de código, mensaje de error de código, vuelvo a 
ingresar nuevamente el código. 
 50
4.Rebasó plazo de préstamo, mensaje de Tiempo limite excedido, levantar sanción, calcular 
sanción e imponerlo. 
7.El operador cancela la devolución, se cancela la transacción. 
 
Caso de Uso: Devolver Publicación 
 
1. Precondiciones: 
 
??El sistema debe contar con las siguiente información: 
o Información del cliente: código, nombre, estado(Activo, Suspendido, Deuda, 
con Reserva) 
o Información de la publicación: código, título, estado(Disponible, Reservado, 
Prestado, Mantenimiento) 
o Informe de sanciones: Sanciones, devolución 
??El operador debe ejecutar el caso de uso control de acceso. 
 
2. Flujo Principal: 
 
o Este caso de uso empieza cuando el operador elige en el menú principal del 
sistema la opción de devolver publicación. 
o El sistema presenta al operador el formulario de reserva de la figura D1, que 
solicita el código de la publicación a devolver. 
o El operador captura el código de la publicación y selecciona una de las 
opciones del final del formulario: Aceptar o Cancelar 
o Si elige la opción Aceptar: Subflujo 1: Verificar publicación y estado del 
Cliente 
o Si elige la opción Cancelar: Subflujo 2: Cancelar Devolución de publicación. 
 
S1: Verificar Publicación y Estado del Cliente: 
 
o El sistema verifica el código de la publicación (E1). 
 51
o El sistema consulta el cliente que ha prestado la publicación. 
o Si el cliente existe, el sistema muestra la información del cliente según como se 
aprecia en la figura D2, y selecciona Cancelar o Devolución. 
o Si elige la opción Cancelar, Subflujo S2: Cancelar Devolución. 
o Si elige la opción Devolución, Subflujo S3: Modificar Estado. 
o Si el cliente no existe, el sistema presenta al operador el grafico D3, donde 
informa que la publicación no ha sido prestada o hay un error en su código, da 
en aceptar y regresa al menú principal. 
 
S2: Cancelar la Devolución de la Publicación: 
 
o El sistema regresa al menú principal. 
 
S3: Modificar el Estado: 
 
o El sistema modifica el estado de la publicación a disponible, desligando la 
publicación del cliente que lo prestó. 
o El sistema consulta el plazo de devolución 
o Si el plazo de devolución no es aceptable modifica el estado del cliente a 
suspendido. 
o El sistema calcula el plazo de suspensión y la asignación al cliente. 
 
3. Flujos de Excepción: 
E1 : El sistema presenta un mensaje informando que el Código de Publicación no 
existe 
 
o El sistema regresa al menú principal 
 
Diseño de la pantalla para el Caso de Uso de Devoluciones de Publicación 
 
 52
Se debe presentar una pantalla que muestre o liste (Data Grid) todos los prestamos que sean 
llevado acabo en donde el operario pueda seleccionar al cliente que esta haciendo uso de 
algún ejemplar, para hacer efectivo una devolución se debe presentar un botón que permita al 
operario llevar acabo la transacción, también la necesidad de un botón actualizar el cual nos 
permitirá después de realizadas las devoluciones actualizar los registros de los prestamos. 
 
 
Caso de Uso: Venta de Publicación 
Actores : Cliente 
Propósito : Registrar la venta y su pago. 
Tipo : Primario y Esencial 
Resumen : Un cliente decide comprar alguna publicación 
la cual es seleccionada de las disponibles, 
rellena el formulario con sus datos de compra, 
los envía y espera a que llegue su pedido. 
Referencias Cruzadas: R.7.1, R.7.2, .7.3 
 
Curso Normal de los Eventos: 
 
Acciones de los actores Respuesta del Sistema 
1.Este caso de uso comienza cuando un 
cliente decide comprar una publicación o 
parte de ella y presiona un click en el punto 
de venta. 
2.El sistema le devuelve un formulario de 
compra indicando la parte o las partes de la 
publicación seleccionado. 
 53
Acciones de los actores Respuesta del Sistema 
3.El cliente selecciona lo que desea comprar y 
envía el formulario con su información de 
crédito para cancelar con su tarjeta el 
importe.4.El sistema genera una solicitud de pago con 
tarjeta de crédito y lo envía a un servicio 
externo de autorización de crédito. 
5.El servicio de autorización de crédito 
autoriza el pago. 
 
 
6.Se registra la información sobre el pago con 
tarjeta de crédito y la respuesta de 
aprobación. El servicio de autorización de 
crédito debe dinero a la biblioteca por lo 
tanto se le debe hacer el seguimiento. 
 7.Se concluye y da un mensaje de éxito de la 
transacción. 
 
Cursos Alternos: 
 
5. Solicitud de Crédito negada por el servicio de autorización de Crédito. Cancelar 
transacción. 
 
Caso de Uso Extendido: Venta Publicación 
 
1. Precondiciones: 
 
??El sistema debe contar con las siguiente información: 
o Información del Cliente: Cuenta corriente, datos del cliente. 
o Información de la Publicación: Código, Capitulo, Precios. 
??El cliente debe haber ejecutado el caso de uso hacer búsqueda. 
 
2. Flujo Principal: 
 
o Este caso de uso empieza cuando el cliente comprar publicación en el Caso 
de Uso hacer reserva. 
 54
o El sistema presenta el formato de datos de la figura V1, que solicita al cliente 
su información para hacer el pago mediante tarjeta de crédito. 
o Si selecciona la opción Enviar: Subflujo S1: Validar y estado de la publicación 
se ejecuta el Caso de uso Hacer Reserva 
o Si sé selecciona la opción Restablecer: vuelve a colocar en el formulario los 
valores iniciales.. 
o Si sé selecciona la opción Colocar precio: Subflujo S2:Verificar y mostrar 
precios. 
 
 
S1: Validar y estado de la publicación: 
 
o El sistema calcula el precio total de la venta. 
o El sistema genera una solicitud de pago con tarjeta de crédito y lo envia a un 
servicio externo. 
o Se espera un tiempo determinado a la respuesta del servicio externo. 
o El servicio externo autoriza el crédito, se modifica el estado de la publicación 
a vendido lo asigna al cliente indicando que parte ha sido comprada. 
o Si el servicio externo no autoriza el crédito se cancela la transacción. 
 
S2 : Verifica y muestra precio 
 
o El sistema consulta y presenta los precios conforme a la selección hecha. 
o El sistema suma los valores intermedios, mostrando el total. 
 
3. Flujos de Excepción 
 
E1: El sistema despliega un mensaje informando que se supero el tiempo de espera 
 
o El sistema regresa ala página principal. 
 
 55
Diseño de la pantalla para el Caso de Uso de Venta Publicación 
 
Para comodidad del cliente, el tiene la opción de comprar un libro por capítulos o todo el libro 
en una sola transacción, para ello la pantalla de venta debe presentar una tabla en la cual 
aparezcan las publicaciones con sus respectivos capítulos de manera que se le da opcion al 
cliente de seleccionar los capítulos que el desea y por ello se debe utilizar los checkbox. 
Otras datos muy importantes para el sistema son los que tiene que proporcionar el usuario con 
el fin de ver si tiene disponibilidad de dinero para hacer efectiva la accion de venta y para ello 
la pantalla debe mostrar un formulario en el cual se le especifique al cliente que ingrese sus 
datos para la transancion. Para esto se hace uso de los cajones de texto. 
 
 
 56
 
 
 
 57
4.5.2. Diagrama de Interfaces 
 
Las interfaces son un elemento de la mayor importancia para la construcción de 
sistemas bien estructurados, en los cuales juegan el papel de contratos entre los 
usuarios de los servicios ofrecidos por una clase o un subsistema, y sus 
implementaciones. 
 
Falta grafico 
 
Diagrama de capas de presentación y de dominio 
 
 58
 
 
 
FrmInicio
(from Logical View)
<<Form>>
frmAcercade
(from Logical View)
<<Form>>
Db
(from Logical View)
<<Module>>
FrmPrestamo
(from Logical View)
<<Form>>
clsPrestamo
(from Logical View)
<<Class Module>>-Prestamo
FrmDevolucion
(from Logical View)
<<Form>> ClsProcedure
(from Logical View)
<<Class Module>>
-Procedimiento
clsDevolucion
(from Logical View)
<<Class Module>>-Devolucion
-Procedimiento
FrmMenu
(from Logical View)
<<MDI Form>>
clsAutor
(from Logical View)
<<Class Module>>
FrmAutor
(from Logical View)
<<Form>>
-Autor
clsEditorial
(from Logical View)
<<Class Module>>
FrmEditorial
(from Logical View)
<<Form>>
-Editorial
clsItems
(from Logical View)
<<Class Module>>
FrmItems
(from Logical View)
<<Form>>
-Items
FrmReservas
(from Logical View)
<<Form>>
FrmUsuariosI
(from Logical View)
<<Form>>
FrmPublicacion
(from Logical View)
<<Form>>
FrmPrestamos
(from Logical View)
<<Form>>
FrmSanciones
(from Logical View)
<<Form>>
ClsPersistente
(from Logical View)
<<Class Module>>
-pReservasCP
-UsuariosI
-Publicacion-Autores -Editorial
-Temporal
-pPrestamosCP
-Sancionados
FrmPublicacionesI
(from Logical View)
<<Form>> -PublicacionesI
 
 59
 
 
4.5.3. Diagrama de Clases 
 
Un diagrama de clases es una colección de elementos (estáticos) declarativos de un 
modelo, tales como clases, interfaces, y sus relaciones, conectados como un grafo 
entre sí y con sus contenidos. 
 
El diagrama de clases representa la estructura estática de un modelo, y no muestra 
información temporal; sin embargo, puede incluir diagramas de objetos cuyas 
instancias debe ser compatibles con un diagrama de clases particular. 
 
Las clases son representadas mediante un rectángulo de tres campos. El primer 
campo contiene el nombre de la clase; el segundo los atributos, indicando nombre y 
tipo, el tercer campo contiene las operaciones o métodos de la clase. La 
representación puede simplificarse mostrando sólo dos campos, que corresponden al 
nombre de la clase y sus atributos. 
 
La visibilidad de los atributos y operaciones se puede indicar mediante el símbolo ’+’ 
para el caso de públicos, ‘-’ si son privados, y ‘#’ si son protegidos. 
 
Los atributos y operaciones con alcance de clase, es decir, que son únicos para todas 
las instancias de la clase (“Estáticos”), pueden señalarse subrayándolos. 
 
Las relaciones entre clases pueden ser de cuatro tipos: asociación, generalización, 
dependencia, y refinamiento. 
 
 
 
 
 60
 
 
TrabajoInvestigacion
Numero
InstitucionPatrocinadora
Revista
ISSN
Periodicidad
Numero
Tesis
Patrocinador
Institucion
Reserva
Prestamo
Prestamo
fecha_hora_inicio
fecha_hora_fin
Devolucion
Ventas
Descripcion
autorizacion
CodPostal
Pais
Direccion
Devolucion
Observaciones
Fecha hora_Inicio
Editorial
ISBN
Ciudad
Pais
Fecha
Descriptores
Descriptor
Autor
PaisOrigen
nombre
Libro
ISBN
Cliente
cod_biblioteca
Tipocliente
Accion
Usuario
Tipo_Usuario
cargo
Dependencia
Operador
Descripcion
Visitante
Descripcion
DNI
NroCuenta
Autorizacion
Universidad
Facultad
Escuela
TipoUniv
Docente
NroCarnet
Alumno
CodUniversitario
Trabajador
CodTrabajador
Administrador
Descripcion
Publicaciones
Titulo
Idioma
TipoPublicacion
Treserva
Tpublicacion
Alta()
baja()
prestamo()
reserva()
ventas()
1..*
1..*
1..*
1..*
1..* 1..*1..* 1..*
1..*
1..*
1..*
1..*
Capitulos
Titulo_Capitulo
Precio
Zip
Ubicacionfisica
Dependencia
Grafico
Ub.fisica
Ejemplares
Fecha de ingreso
Volumen
Edicion
NroPagina
EstadoDisp
1..*
1..*
1..*
1..*
1..*
1..*
1..*
1..*
1..*
1..*
1..*
1..*
Transaccion
Tipo_transaccion
Fecha_hora
1..*
1..*
1..*
1..*
Persona
Nombre
Ciudad
Tipo_persona
Login
clave
Comprar()
reservar()
prestar()
anular()
1..*
1..*
1..*
1..*
PenalizacionesMultas
Categoria
UnidadMulta
MinutosDeCastigo
FactorReincidenciaxMulta
descripcionDemulta
0..* 0..*0..* 0..*
 
 61
4.5.4. Diagrama de Estado 
 
Mientras que los diagramas anteriores permiten modelar la estructura de un sistema, 
representando su configuración estáticas, el comportamiento de estos, es decir, su 
dinámica, se modela utilizando Diagramas de Secuencia, Diagramas de Colaboración 
y Diagramas de Actividad. 
El diagrama de Estados permite describir el ciclo de vida de los objetos de una clase, 
en términos de los estados que estos pueden tener ylos estímulos que dan lugar a los 
cambios de estado. 
 
 
 
Ejemplar 
Retirar() 
Lanzamiento() 
Transacción() 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Penalización Multa 
Multa() 
Penaliza() 
Levantar Multa() 
 
 
 
En proceso
Disponible
retirar() lanzamiento()
constructor()
No Disponible
destructor()
Transaccion()Trasaccion()
 
 62
 
 
 
 
 
 
 
 
 
 
 
 
Persona 
Buscar() 
Penalizar() 
Multa() 
Eliminar() 
Ingreso() 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
En proceso
Activa
multa() penaliza()
constructor()
Desactiva
levantar multa()
destructor()
 
En proceso
Valida
elimina() ingreso()
constructor()
No valida
destructor()
Penaliza()
Multa()
 
 
 
 63
 
 
 
 
 
 
 
Transacción 
Ejemplar() 
Reservar() 
Prestar() 
Devolver() 
Venta() 
Buscar() 
Estado 
 
 
 
 
4.5.5. Diagramas de Secuencia 
 
Contribuye a la descripción de la dinámica del sistema en términos de la interacción 
entre distintos objetos del sistema, generalmente de distintas clases. Esta interacción se 
lleva a cabo a través de mensajes, un mensaje generalmente se implementa mediante 
la invocación de una operación desde el objeto “fuente” en el objeto “destino”. 
 
En el diagrama de secuencia aparecen desplegados de manera horizontal los objetos 
que participan en la interacción, y cada uno de ellos tiene un eje vertical que 
corresponde al tiempo. Los mensajes entre objetos se representan mediante flechas 
En proceso
Existe
retirar() lanzamiento()
constructor()
Prestado
destructor()
Reserva()
Reservado Devuelto
Venta
Venta()
Prestar() Pretar() 
 64
etiquetadas con el nombre de la operación, la señal o la acción de interacción 
correspondiente 
 
El formato de la flecha permite diferenciar el tipo de mensaje, que puede ser: 
 
??Simple: usado cuando no se conocen los detalles del tipo de comunicación o 
no son relevantes en el diagrama. También para representar el retorno de un 
mensaje síncrono. 
??Síncrono : Representa la invocación de una operación la cual el objeto 
invocante se queda bloqueado esperando la terminación de la misma. 
??Asíncrono: Representa la invocación no bloqueante cuando el objeto que 
invoca la operación continua de inmediato su hilo de ejecución sin esperar 
respuesta, ni que la operación sea ejecutada por el objeto invocado. 
 
1. - Hacer Reservas 
 
2. - Hacer Préstamo 
 
 
 : cliente
 : Reserva usuarios : 
BaseDatos
proc_ver_castig 
: BaseDatos
proc_reservar : 
BaseDatos
1: login, password, id_libro
2: cadena a validar
3: usuario ok
4: sanciones
5: estado usuario
6: reservacion
7: reservacion ok
8: confirmacion de reserva
 
 65
 
3. - Hacer Búsqueda 
 
 
 
4. - Realizar Devolución 
 
 
 : cliente : Operario : Reserva proc_prestamos 
: BaseDatos
1: codigo
2: codigo a validar
3: codigo ok
4: codigo
5: reservas validas
6: confima prestamo
7: prestamo registrado
8: da libro
 
 : cliente
consultar : 
Busqueda
proc_buscar : 
BaseDatos
validar : 
Busqueda
1: cadena a buscar
2: validez de cadena
3: cadena valida
4: consulta
5: cadenas encontradas
6: resultados de busqueda
 
 66
 
 
4.5.6. Diagramas de Colaboración 
 
Muestran no sólo los mensajes a través de los cuales se produce la interacción entre 
los objetos, sino que también los enlaces de los objetos. 
 
Pueden asumir las formas genéricas y de instancia. En la primera se muestra en un solo 
diagrama las distintas posibilidades de interacción de un conjunto de objetos, las 
etiquetas de mensajes tienen una sintaxis compleja. 
 
1. - Hacer Reserva 
 
 : cliente : Operario
 : Libro : Devolucion
1: entrega libro
2: verifica mora
3: presenta sancion
4: confirma sancion
5: registra devolucion
 
 67
 
2. - Hacer Préstamo 
 
 
 
3. – Realizar Búsqueda 
 
 
 
 : cliente
 : Reserva
usuarios : BaseDatos proc_ver_castig : BaseDatos
proc_reservar : BaseDatos
1: login, password, id_libro
8: confirmacion de reserva
2: cadena a validar
3: usuario ok
4: sanciones
5: estado usuario
6: reservacion
7: reservacion ok
 
 : cliente : Operario
 : Reserva
proc_prestamos : BaseDatos
1: codigo
8: da libro
2: codigo a validar
3: codigo ok
4: codigo
5: reservas validas
7: prestamo registrado 6: confima prestamo
 
 68
 
4. – Realizar Devolución 
 
 
 
 
4.5.7. Diagrama de Actividad 
Es utilizado para describir una secuencia de acciones, las cuales pueden corresponder 
a distintos niveles de abstracción de un sistema: el algoritmo de una operación en una 
clase, la interacción de un grupo de objetos, la especificación de un caso de uso, las 
actividades que integran un procedimiento en una empresa, etc. 
 
Los diagramas de actividad son en esencia diagramas de flujo, con algunos elementos 
adicionales que les permiten expresar conceptos como la concurrencia y la división del 
trabajo. 
 : cliente
consultar : Busqueda proc_buscar : BaseDatosvalidar : Busqueda
6: resultados de busqueda
1: cadena a buscar
2: validez de cadena
3: cadena valida 4: consulta
5: cadenas encontradas
 
 : cliente : Operario
 : Libro : Devolucion
1: entrega libro
2: verifica mora
4: confirma sancion3: presenta sancion
5: registra devolucion
 
 69
Utilizan los símbolos de estados, denominados estados de acción, para describir 
actividades, y también usan los símbolos de estado inicial y el estado final 
 
Tienen condiciones para habilitar las transacciones entre una acción y otra, y además 
un símbolo para los puntos de decisión, que consiste en un diamante grande con una 
o mas transacciones de entrada y dos o más transacciones de salidas etiquetadas con 
condiciones. 
Este diagrama es opcional. 
 
4.5.8. Diagrama de Componentes 
Presenta sus elementos tangibles: los archivos. Se lo utiliza, entonces, para describir la 
estructura física del código de la aplicación en términos de sus componentes(código 
fuente, binario, o ejecutable) y sus dependencias. 
 
 
 
4.5.9. Diagrama de Implantación 
Se muestran nodos, conexiones, componentes y objetos. Los nodos representan 
objetos físicos con recursos computacionales como procesadores y periféricos; 
pueden mostrarse como una clase o una instancia, por lo que su nombre sigue la 
sintaxis establecida para clases y objetos. Las conexiones son asociaciones de 
Index.html
acceso.asp
resultados.asp
Borrar reserva.asp
Comprar.asp
Comprar 2.asp
imagenes
ResultadosDetalle
 
 70
comunicación entre los nodos y se etiquetan con un estereotipo que identifican el 
protocolo de comunicación o la red utilizada. 
Los componentes son archivos de código ejecutable, que residen y se ejecutan dentro 
de un nodo; se pueden representar relaciones de dependencia entre los componentes 
que, de manera similar a la dependencia entre paquetes, corresponden al uso de 
servicios. 
Los objetos pueden incluirse en el diagrama contenidos en otro objeto, en un paquete 
o simplemente en un nodo. 
 
PC Cliente
Cliente
PC Operario
Operario
PC Administrador
Usuario/Administrado
Servidor Aplicaciones
cliente
Aplicacion Cliente
Aplicacion Usuario
Serv. BD
Biblioteca
<<HTTP>>
___________
___________
<<TCP/IP>>
__________________
<<ODBC>>
 
 
 
 71
CAPITULO V.- 
PRUEBAS DE ANÁLISIS Y DISEÑO ORIENTADO A 
OBJETOS 
 
 
El sistema de Biblioteca no es excepto de que los modelos de análisis y diseño no 
pueden probarse en el sentido convencional, pues no pueden ejecutarse. Sin embargo pueden 
usarse las revisiones técnicas formales para examinar la corrección exactitud y consistencia de 
ambos modelos. 
 
5.1. CORRECCIÓN DE LOS MODELOS DE AOO Y DOO 
 
En el sistema de Biblioteca durante la corrección de los modelos de análisis y diseño, 
se ha juzgan la corrección semántica, basándose en la conformidad del modelo con el dominio 
del problema del mundo real, en este caso las necesidades que tienen los usuarios al usar la 
Biblioteca Universitaria. 
 
La Biblioteca Universitaria que se esta presentando esta reflejando actividades

Continuar navegando