DISPONIBILIDAD DE CUBCULOS

INTEGRANTES: Isabel Cisterna Natalia Gonzlez Christian Pea Camilo Silva Sergio Sanchez

INDICE ************quien haya hecho el indice que no continue no es necesario, pasare el trabajo a latex y el indice lo genera solo***************

Introduccin 1. Planificacin del Proyecto 2. Resumen General

pg.......... 3 pg.............. pg..............

2.1.Objetivo General 2.2Objetivos Especificos 3. Definicin del Problema 3.1. Formulacin Amplia 3.2. Criterios de Seleccin 3.3 Propuesta de Solucin 3.4. Requerimientos 3.5. Captura de Requerimientos 3.6. Especificacin de Requerimientos 3.6.1.Requerimientos Funcionales 3.6.2 Requerimientos de Usuario 3.6.3.Requerimientos del Sistema 3.6.4. Requerimientos No Funcionales 3.6.5. Requerimientos del Producto 3.6.6. Requerimientos Organizacionales 3.7. Metodos de Captura de Requerimientos

pg.............. pg.............. pg.............. pg..............

INTRODUCCN A la hora de desarrollar un software se debe tener presente y seguir una gran cantidad de criterios y estndares que han surgido a lo largo de los aos. El proceso diseo viene dado desde el comienzo (naturalmente luego de tener un problema al que darle solucin), por una captura de requerimientos y luego, bsicamente interpretar esos datos y transformarlos en variables tiles para nuestro propsito y recin con la informacin necesaria, comenzar a disear el software en s, hasta llegar al desarrollo lo cual concierne a otra etapa.

Lo anterior hace referencia al proceso que mostraremos en el presente informe, para ello hemos identificado una problemtica sumamente comn que se da en nuestra universidad, el desconocimiento y la mala administracin que hay sobre las disponibilidades y forma de peticin de los cubculos de la universidad, en base a esto veremos la solucin (optimizada bajo ciertos criterios) que decidimos llevar a cabo, guiada por una forma de especificacin tcnica, pretendiendo obtener el diseo de la solucin en su completitud. A continuacin damos paso a la documentacin de la primera etapa del proceso productivo de nuestro software, cumpliendo con los requerimientos establecidos para dicha etapa, es decir, el diseo.

PLANIFICACIN DEL PROYECTO ****************Ya esta hecho **************************

Resumen General Nuestro proyecto consiste en optimizar lo ms posible la problemtica existente a la hora de pedir y conocer la disponibilidad de algn cubculo de nuestra Universidad Catolica de Temuco. La funcionamiento que actualmente existe es una peticin presencial y por orden de llegada, nosotros daremos ms eficiencia al sistema que ocupamos en nuestra vida universitaria, principalmente el poder conocer de antemano los horarios y la disponibilidad de estos espacios, beneficiando as a los alumnos que integran nuestra Universidad.

Objetivo General Para esto se disear una aplicacin web, aplicando los recursos brindados por la tecnologa de javaEE entre otros, para dar solucin a la problemtica mencionada anteriormente. Objetivos Especficos Se podr agilizar la consulta de disponibilidad de espacios de estudio a travs de una aplicacin WEB. El poder realizar la peticin desde cualquier lugar con acceso a internet. Permitir disminuir el tiempo de espera para acceder a un cubculo. Definicin del problema Este proyecto intenta optimizar la problemtica existente en la mala disposicin de espacios de estudio en la Universidad, para ello buscamos dar eficiencia al sistema actual a travs de un sistema ptimo integrado a la web, as ser posible conocer los horarios y disponibilidad de estos espacios sin necesidad de estar en la biblioteca.

Los alumnos estudian individual y en grupos, por lo tanto es de gran beneficio para los grupos de trabajo disponer de un espacio de estudio adecuado a la cantidad de personas que desean estudiar y en los horarios que disponen segn sus horarios de clases. Formulacin Amplia: La peticin y disponibilidad de cubculos que actualmente opera en la Universidad es ineficiente y no permite controlar ptimamente los espacios de estudios a los administradores encargados ni a los alumnos planificar previamente su da. Estado A: Estudiante se traslada a la biblioteca para consultar si hay disponibilidad de cubculos Estado B: Estudiante consulta de manera remota(solo con acceso a internet) la disponibilidad de cubculos. Criterios de seleccin Como sabemos los criterios nos enfocan a encontrar una solucin optimizada, es decir, buscar de manera adecuada el logro de nuestro objetivo. Por lo tanto nuestro cdigo tendr criterios de bajo acoplamiento, las clases estarn lo menos interrelacionadas posible para futuras optimizaciones, ediciones y mantenciones. Adems buscaremos exhaustivamente una alta cohesin para hacer relaciones adecuadas y coherentes en cada clase.

Propuesta de Solucin Hacer consultas de manera remota a travs del sitio web, para ver la disponibilidad de cubculos para el trabajo grupal y de esa manera organizar el da con anticipacin. Adems de optimizar el tiempo de consulta se privilegiar la agilidad de reserva de reserva, con la cual es ms rpido el acceso a los cubculos de estudio. Requerimientos Este documento se caracteriza por poseer un lenguaje lo ms bsico posible para que el cliente pueda entender y/o interpretar lo que en l se estipula, est compuesto por un listado de acciones que espera que el software posea cuando se lleve a cabo, por ende este esta escrito en forma conjunta entre el cliente y el desarrollador. Cuando definimos los requerimientos que el sistema deba poseer nos enfocamos en las quejas masivas que se emitan del alumnado, que consista en la molestia por tener pocos espacios de estudio y mal uso de ellos. Al administrar los espacios de la Universidad de manera ptima ayuda a la comunidad universitaria a programar de mejor manera su da en nuestro centro de estudios y as optimizar sus tiempos. En este caso la definicin de requerimientos no fue necesaria la presencia de un cliente ya que somos nosotros los que da a da nos encontramos con este problema, por lo tanto como grupo estipulamos un listado de acciones que deba poseer nuestro sistema para dar solucin a la problemtica existente.

Captura de Requerimientos: En la captura de requerimientos de nuestro proyecto, como ya mencionamos nosotros como alumnos de la Universidad adems de ser los diseadores del sistema, a la vez, pasamos a convertirnos en en cierta forma clientes, ms acertadamente los usuarios, por lo que no es necesario acudir a entrevistas, sesiones en grupo o cualquier otro mtodo para interactuar con los clientes, como conocedores del sistema actual fue simple darnos cuenta de las falencias que tiene el sistema de prestacin de cubculos, ya que esto lo vivimos da a da. Especificacin de Requerimientos: El sistema que debemos disear trabajara con una gran cantidad de usuarios, por lo que se debe hacer uso de base datos para gestionar la informacin de cada individuos, por otro lado se debe desarrollar una interfaz intuitiva en lnea a toda hora visible por cualquier navegador incluyendo de los mviles ya que los usuarios son en su mayora alumnos y naturalmente no todos tienen buenos conocimientos computacionales, es por ello que debe adems ser simple y manejable. De la misma forma los administradores tendrn su propia interfaz con privilegios especiales, por lo que ser necesario incluir estos en su sesin. Requerimientos Funcionales: Son requerimientos que debe cumplir el sistema para poder llevar a cabo algn proceso en particular, estos a su vez los podemos separarlos en los siguientes: Requerimientos del Usuario: El sistema deber permitir que el usuario (alumno y administrador) se pueda identificar ante l (autentificando su identidad). Permitir al alumno hacer reservas en el sistema, confirmarlas o borrarlas si l lo desea. Poseer permisos de root (cancelar, aceptar, editar, reservar) al administrador en el sistema. Permitir al administrador bloquear al alumno por mal uso de los espacios(cubculos). Mostrar grficamente los espacios que pueden ser reservados(cubculos libres) y cules no. Requerimientos del sistema: El sistema necesitar de diferentes tipos de lenguaje para poder operar, tales como SQL, xHTML, JavaScript, Ajax, PHP, etc. Como tambin de un servidor HTTP Apache y por ende varios tipos de software para el desarrollo MySQL, Bluefish, Filezilla, PHPmyAdmin, etc.

Requerimientos No-Funcionales: No son necesariamente fundamentales para el funcionamiento del sistema en general, pero s ayudan a optimizar y darle una mejor experiencia al usuario al momento de utilizar dicho sistema. Los cuales se dividen en 3 subpartes:

Requerimiento del Producto: Estos asegurarn el buen funcionamiento y servicio de la base de datos, manteniendo su estabilidad y rapidez de respuesta. Tambin ofrece niveles de servicio donde la disponibilidad y recuperacin de fallos sea garantizada, por ejemplo con la prdida de informacin en la base de datos. Se desarrolla una implementacin de una funcin para enviar mensajes de confirmacin de reservas, incluyendo periodo de uso y nmero de cubculo e integrantes, adems de una funcin para la caducar la sesin despus de un periodo de tiempo inactivo, como tambin los datos tendrn una duracin de una semana en la semana la tabla de reservas de la base de datos, ya que los das viernes en la noche por razones de eficiencia de trasladarn (esto se explica en la seccin de base de datos). Requerimientos Organizacionales: Los cuales permiten la reutilizacin de cdigo, para ello, se disea un cdigo de bajos niveles de acoplamiento, dando la posibilidad de editar fcilmente parmetros que requieran cambios frecuentes. Requerimientos Externos: Dentro de este nos encontramos con 3 tipos de categoras, las cuales son: ticos, legales y de interoperabilidad, la cual nos describe que el programa constar de una conexin ligada con otros software de nuestra universidad, como pueden ser el de peticin de libros, con esta compartira trminos de bloqueo de alumnos (por algn uso indebido del material o atrasos en devolucin de libros) y por ende la base de datos .

Requerimiento de Dominio: En este tipo el requerimiento de dominio es fundamental para el proyecto, ya que sin l no se podr llevar a cabo satisfactoriamente. En nuestro caso particular reserva tu cubculo, los fundamentos del dominio de la aplicacin sera el control de la hora, hemos estipulado que la prestacin de un espacio de estudio ser como mximo una hora, ya que con esto se puede controlar con exactitud cunto tiempo estar el alumno o los alumnos ocupando el cubculo.

Mtodos de captura de Requerimientos

* Tormenta de Ideas: Tambin denominada Lluvia de Ideas, es una herramienta de trabajo grupal que facilita el surgimiento de nuevas ideas sobre un tema o problema determinado. En un principio toda idea es vlida y ninguna debe ser rechazada. Por lo tanto se anotan las siguientes en pos de buscar la mejor. Las ideas que surgieron para dar solucin a la problemtica en un principio fueron: Sistema de reserva va sms. Correo electrnico al administrador para reservar. Hacer reservas para horas posteriores va algn medio. Creacin de pgina web auto-servicio de reserva de cubculos. De las ideas que surgieron luego de evaluarlas, en grupo se concluy que la ltima de ellas fue la idea ms ptima y efectiva, adems esta idea se acotaba a nuestros recursos y posibilidades de llevarla a cabo * Investigacin de antecedentes: Para llevar a cabo nuestro proyecto adems de la lluvia de ideas, implementamos una investigacin de antecedentes (el cual consta de hacer investigaciones, muestreo, vistas, etc). Este nos ayud a escoger una mejor opcin dentro de las ideas que rescatamos usando el mtodo anterior, una de las ideas que descartamos a travs de este mtodo fue la reserva de va sms, ya que seria un gasto extra y no viable para la comunidad universitaria (porque para poder reservar algn cubculo habra que contar con saldo en el celular y no podramos saber su disponibilidad inmediata).

Descripcin del Caso de Uso: Reserva de cubculos. Administrador: Puede cancelar reservas realizadas en caso de que un actor estudiante tenga un comportamiento indebido o no respete los horarios establecidos, pudiendo ser bloqueado por un tiempo determinado. Este actor tambin tendr que estar logueado al sistema, sin embargo, tiene ms privilegios que un estudiante. Estudiante: Puede hacer reserva de un cubculo previamente registrado y/o logueado, en un perodo de tiempo determinado por el sistema. Adems tiene la opcin de borrar su reserva en caso de necesitarlo. Precondiciones: 1. El actor estudiante debe loguearse al sitio. 2. el actor estudiante debe ser alumno regular de la Universidad Catlica de temuco. 3. La reserva slo puede hacerse a cubculos libres. 4. Los alumnos que son integrantes de un grupo, que ocupan un cubculo en el da no pueden volver a hacer una reserva en el sistema.

Postcondiciones: 1. Habilitar cubculos desocupados para nueva reserva. 2. Bloquear estudiantes que no respetaron los horarios establecidos. Descripcin extendida del Caso de Uso Nombre Caso: Validar Reserva Actor(es) : Administrador. Descripcin : Cuando llega la hora de usar el cubculo reservado, el estudiante se dirige a la biblioteca para que el administrador le valide su solicitud y le pase las llaves. Flujo Normal 1.- El actor administrador se logea en el sitio web. 2.- El actor administrador selecciona el cubculo a validar. 3.- El sistema despliega la informacin respectiva del cubculo. 4.- El actor administrador revisa que el estudiante est habilitado y la informacin sea correcta. 5.- El actor administrador valida la reserva. 6.- El sistema actualiza tabla de informacin de reserva. Flujo Alterno 1.1- Al hacer login retorna error de autentificacin. 3.1- La informacin desplegada por el sistema est errnea. 4.1- El estudiante aparece como bloqueado. 5.1- El administrador rechaza la peticin de cubculo. 6.1- La actualizacin no se logra efectuar por el sistema. Precondicin: El administrador debe estar ingresado y habilitado para realizar tareas de administracin. PostCondicin: El cubculo reservado por el estudiante se encuentra habilitado por el administrador, listo para ser usado.

Base de Datos(Mer)

En el diagrama se observa que Estudiante y Administrador heredan atributos comunes de usuarios, diferencindose estos en los privilegios sobre habilitaciones y sanciones. Las sanciones se reflejarn en el atributo estado de estudiante como bloqueado o habilitado. Los usuarios reservan cubculos (cero o muchos), esto segn sus necesidades de uso, por ello incluimos datos como si poseen o no pizarra como tambie la capacidad, ya que por ejemplo si una persona reserva cubculos para ir solo con 2 alumnos ms, se buscara un cubculo pequeo para ellos y as se estar privilegiando los de ms capacidad a alumnos que agrupen ms personas. Por otro lado los cubculos tienen perodos de uso, donde se registraran las peticiones semanales, el campo adminHabilitador de la entidad PeriodosUso se llenar en el momento que el alumno pida la llave y el administrador que est en ese momento confirme su llegada ser el habilitador que ocupara ese campo, as se llevara un registro ms completo. El contenido de esta tabla ser momentneo, ya que cada noche del da viernes se reseteara borrando su contenido (que seran las reservas semanales) y comenzar vaca nuevamente a partir del sbado, esto por un asunto de optimizacin ya que tambin se pretende guardar un historial y como esta tabla tendr mucho flujo de datos despus de algn tiempo estara sobrecargada de informacin, haciendo pesado el acceso a la misma, por ello se

copiar la informacin antes de ser borrada los viernes a la entidad Historial de uso, en la cual llevaremos un registro de las peticiones de cubculos. A esta tabla podrn acceder todos los usuario (naturalmente slo a la seleccin de su historial). Por ltimo volviendo a la entidad Periodos Uso, es importante destacar que de esta tabla obtendremos tambin los perodos libres de cada cubculo que por medio de un mtodo sern mostrados en la interfaz como disponibles.

Modelo de Anlisis ++++++imagen+++++++ Este modelo o grafo determinista explica las transiciones que existen en el proceso realizado por el usuario y el administrador. Las determinaciones ocurren por ejemplo al autentificar usuario, si ocurre un error lo devuelve al principio, lo mismo ocurre con verifica disponibilidad, agrega reserva y elimina reserva.

Diagrama de Clases +++++imagen++++++ Del diagrama se puede observar: Poca dependencia de las clases, exceptuando Consulta que necesariamente debe estar relacionada con las dems. La poca dependencia, conlleva a un bajo acoplamiento, por lo que estas clases en un futuro podran ser reutilizadas en algn otro sistema de reserva o modificarlas fcilmente. El diagrama muestra una cohesin relativamente alta, en relacin a la agrupacin y funcin que realiza cada mtodo.

Diagrama de Secuencia +++++imagen++++++ El administrador hereda de usuario, puede realizar las mismas funciones y adems eliminar a cualquier reserva. Flujo Normal: Si hay disponibilidad de cubculos el usuario est posibilitado de realizar una reserva, por otro lado se logra la verificacin de identidad del alumno y slo se realizar la consulta. Por otra parte, si el usuario es identificado y inicia la sesin, el proceso de reserva se lleva a cabo, el usuario y administrador puede cancelar la reserva realizada, finalmente luego de haber mostrado el resultado final se cierra la sesin.

Diseo de Interfaz Grfica de Usuario La siguiente imagen corresponde a la interfaz grfica con la que se encontrara el usuario estudiante al momento de ingresar a nuestra pgina web. ++++++imagen de interfaz+++++++++

La siguiente imagen corresponde a la interfaz grfica con la que se encontrara el usuario estudiante al momento de ingresar a nuestra pag web. En la parte superior la pag nos muestra la hora y la fecha actual, adems de identificar al usuario, si este se ha logueado previamente, mostrando tambin la opcin de cerrar sesin. Si este no fuera el caso (que el usuario se ha logueado) entonces se mostrar la opcin de hacer login con nombre de usuario y contrasea. Un poco ms abajo se ven representados con su respectivo nmero los diferentes cubculos con los que cuenta nuestra universidad. Estos cuadritos en realidad sern una especie de botn que al ser pulsado, de manera inmediata actualizar los datos que contendr ms abajo la lista del item "informacin de reserva" con las caractersticas o atributos que tiene el cubculo presionado. En el tem "Informacin Actual" podemos ver una tabla que almacena la informacin referente a la disponibilidad y reserva de cada uno de los cubculos, desde la hora en que se esta haciendo la consulta, es decir, si son las 10:09, la tabla despliega la informacin desde las 10:00, si fueran las 10:59 tambin el sistema mostrar los datos desde las 10:00. Los espacios de tiempo que se muestran con azul muestran los periodos de tiempo en que los cubiculos se encuentran ocupados o reservados. Como opcin adicional puede consultar por la informacin de reserva y disponibilidad de cualquier da de la semana. El dia viernes en la noche se borran todos lo registros de esta tabla para que puedan volver a ser llenados la semana siguiente. Es importante aclarar que el usuario no esta restringido a reservar un periodo de tiempo preestablecido, esto es por ejemplo de 11 a 12 o de 8 a 9, sino que puede reservar un cubiculo a la hora que guste o que lo necesite, siempre y cuando este disponible. Esta opcion mejora bastante el sistema actual en el que, como los horario eran preestablecidos, el estudiante debia esperar a que llegue el periodo de prestamo del cubiculo aun estando este desocupado. Con este nuevo sistema el usuario puede el estudiante puede comenzar a usar el cubiculo a la hora que mas le acomode, especificando el inicio y el termino de uso del cubiculo, pudiendo ser ademas en algun caso particular menor a una hora. Una vez que el usuario revisa la informacin contenida en la tabla de Informacin actual puede escoger entonces el cubculo disponible que desea ocupar. Pincha en la parte superior el icono del cubculo escogido, y de inmediato se despliega la informacin de este en la Informacin de reserva que est a la derecha. Aqu es necesario que el usuario indique el periodo de uso del cubculo (especificando la hora de inicio y la hora de termino) igual o menor a una hora. Una vez seleccionado el periodo de uso el estudiante puede hacer la reserva presionando el botn "Reservar" que aparece ms abajo. Al momento de hacer la reserva se actualiza automticamente la tabla de la seccin "Reservas activas" que contiene el nmero del cubculo reservado, el periodo de una hora o menor y la fecha. las funciones de ms abajo permiten editar un reserva o borrarla en caso de que ya no se requiera.

Diseo de Interfaz Grfica de Administrador +++++imagen de interfaz++++++++ La interfaz grfica de administrador presenta leves diferencias respecto a la de usuario, las cuales radican principalmente en los privilegios, se observa que el administrador tiene la facultad de validar la reserva realizada por el estudiante, el flujo de esta situacin es el siguiente: El estudiante determina y escoge la hora que desea hacer uso del el cubculo, activando ese perodo que ahora se marcar como ocupado en la tabla de informacin actual, ms tarde cuando el alumno vaya a pedir la llave al mesn de la biblioteca el encargado en ese momento ser el administrador habilitador que validar la reserva comprobado y evidenciando los datos del alumno, esto lo har haciendo un clic en la imagen del cubculo que el alumno reservo o bien en la casilla de la tabla que corresponde a la hora reservada (de cualquier forma se resaltar la imagen del cubculo). As mismo puede rechazar la peticin por algn caso extraordinario borrando de la tabla ese perodo y dejndolo como disponible. Otra situacin que permite realizar esta interfaz es cuando un alumno sin haber reservado por su cuenta (o su sesin) un cubculo se acerca al mesn, a consultar si existe alguna disponibilidad inmediata (algo similar a la forma actual), en este caso el administrador puede ver en la tabla los periodos libres pinchar en la casilla de un periodo libre resaltando el cubculo y generando un formulario de informacin de reserva para ser llenados con los datos del alumno en el momento. El administrador al igual que los estudiantes tienen la posibilidad de ver su historial o bien el de algn alumno, por ltimo como uno de los privilegios de administrador, el puede bloquear a algn alumno en caso que se de una situacin fuera de las normas.

CONCLUSION BIBLIOGRAFIA