ELO-329: Proyecto de diseño y programación
orientados objeto
Gestión de reservación de salas
Jean-Baptiste LACAZE
R.OL.: 2.790.108-5
Profesor
Agustín J. González V.
Índice
I. Diseño
de una conexión Cliente-Servidor
1. Gestión
de los diferentes clientes
2. Gestión
de la base de datos
1. Comunicación
con el servidor
Introducción
El proyecto propuesto a los alumnos de la clase de Programación orientada objeto, supone que sea original y sobre todo útil. En este propósito y por un cierto interés por aprender a manejar la programación de red en java, desee hacer un proyecto que permita desarrollar una relación cliente-servidor y que necesita intercambios de datos. Este proyecto debe permitir de aprovechar del sitio web de la universidad para permitir de automatizar la gestión de las reservaciones de salas.
El proyecto debe permitir, entre otro, al profesor de conectarse con su llave personal para impedir reservaciones hechas por personas que no tengan derechos a hacerlas, consultar las disponibilidades de las clases de una vista, y hacer su reservación y todo eso desde su computador que puede ubicarse en cualquier parte.
Este
proyecto debe facilitar esa gestión que todavía se efectúa de la manera la más
simple, una hoja de papel y un lápiz, pero no es la más práctica para
aprovechar de las disponibilidades de las salas y del tiempo libre de los
profesores. Por eso el proyecto debe ser pensado muy simple de utilización, y
con un control interno por la administración que queda encargada de la gestión
global y debe tener más derecho sobre las reservaciones.
I. Diseño de una conexión Cliente-Servidor
La solución encontrada más fácil para diseñar una solución apropiada, fue una relación cliente-servidor que admite conexión de múltiples usuarios (los profesores y gente de la administración), llena una tabla horaria y permite consultación de las disponibilidades en tiempo real (los datos de la tabla estarán bajados muy frecuente).
1. Esquema de la solución
Los clientes se conectan uno a uno al servidor, y una vez conectado envían recuestas al servidor para consultar lo que está en la base de datos. En este caso la base de datos solo será una carpeta que contiene archivos de texto con los datos de cada sala, cada profesor…
2. Funcionamiento general
El inicio de esta relación se hace del lado del cliente. Este crea una socket cliente mientras que el servidor espera una nueva conexión sobre un puerto sobre cuál había hecho su socket de servidor (ServerSocket). Esta esperanza se hace gracias a un lapso infinito bloqueante sobre la aceptación de la nueva conexión. Una vez la conexión aceptada, el servidor genera una socket para comunicar con su cliente. Después viene el protocolo de verificación del usuario, y luego se puede consultar la base de datos gracias a la tabla presente en la ventana del usuario.
Este protocolo como todo los intercambios de datos después se hacen gracias a flujos de entrada (InputStream) y de salida (OutputStream). El cliente y el servidor creen cada uno ambos para comunicar entre sí. Cuando el cliente se desconecta, o que se pierde la conexión, hace falta cerrar la socket creada antes solo para este cliente. En nuestro caso, se nota que sería importante incluir una gestión de múltiples conexiones lo que entrena una gestión de los diferentes flujos por un mismo servidor.
La solución presentada ha sido desarrollada sobre un mismo computador (clientes y servidor). El servidor escucha sobre un puerto (en este caso el puerto 80) y los clientes vienen a conectarse con el servidor por ese puerto. La puesta en red después no será lo más complicado, pero no ha sido probada por falta de tiempo y de material.
II. El Servidor
El servidor que se elige desarrollar es un servidor multiconexiones para permitir que al mismo tiempo muchos usuarios se conecten y consulten la base de datos para hacer sus reservaciones de sala.
1. Gestión de los diferentes clientes
El servidor se presenta bajo la forma de un programa principal que crea una socket servidor que permitirá la creación de las diferentes sockets al conectarse con un cliente. Para permitir una gestión más eficaz de los diferentes clientes, se crea un objeto de tipo “NuevaConexion.java” para cada cliente, que maneja todas las pedidas del cliente y consulta la base de datos.
En este caso se crea una lista de los usuarios conectados para permitir un día crear un sistema de chat, intercambios de archivos… Así los flujos de salida de los clientes se guardan en una lista con el nombre del usuario en un objeto de tipo “Usuario.java”. Esta lista contiene los flujos de salida de todos los usuarios conectados al servidor y permitirá luego de comunicar con otros usuarios y ahora permite una buena gestión de las comunicaciones por el servidor.
El esquema siguiente muestra una conexión de un cliente:
2. Gestión de la base de datos
La base de datos contiene archivos de texto que guardan los diferentes datos: las identificaciones y llaves de los usuarios, las reservaciones de las salas (profesor, motivo, horario). La bajada de esas informaciones se hace gracias al método Lectura de la clase “Lectura.java”, y las modificaciones de esas reservaciones se hacen por “Ecriture.java”.
Pero existe el caso de la agregación de un nuevo usuario, directamente manejado por “NuevaConexion.java”. Ese permite crear si no existe en la base de datos un usuario que ya tenga el mismo nombre.
“Ecriture.java” y “Lectura.java” usan datos del tipo Horario que a cada horario asigna un profesor, un curso y un código (opcional), o no (no reservación en el horario). Además para hacer una diferencia entre las reservaciones puntuales y las que aparecen cada semana, se agrega el boolean “fijo” que permite saber si el horario aparece cada semana. Los horarios fijos y los puntuales no se guardan en el mismo archivo. Las reservaciones puntuales crean nuevos archivos (por día de reservación cuando haga falta) y las fijas aparecen en archivos “fijosX.txt” con X el número del día en la semana (p.ej.: 1 es lunes, 2 martes…).
3. NuevaConexion.java
El Main.java crea tantas instancias de NuevaConexion.java como el número de clientes. Eso permite una gestión menos centralizada y sobre todo impide mandar los datos a la mala persona.
El funcionamiento de esta clase es basada sobre un Thread (implementación de la interfaz Runnable) cuya ejecución depende de la buena identificación del usuario. El Thread espera después palabras llaves. Una es “agregar” para agregar un usuario (solo disponible a un administrador), otra es “cambio” para guardar los cambios hechos en las reservaciones de un día y se puede también enviar el número de una sala para consultar las reservaciones de esta sala.
“agregar” invoca a la función “NuevaPersona” que después de haber chequeado (gracias a la función “Existe”) si no existe el usuario, agrega el usuario por agregar un nuevo archivo de texto al nombre del usuario, y conteniendo su llave personal. La función “Existe” es la misma que permite la identificación al principio del cliente
“cambio” llama la función “Guardar” que gracias a un objeto de tipo “Ecriture.java” permite cambiar los archivos de texto de la base de datos. Los cambios se hacen por día de reservación. Esta última elección se hizo para facilitar el almacenar de los datos. De hecho, a cada cambio, el archivo de texto correspondiente esta borrado y escrito otra vez con los cambios.
El ultimo es la consultación de los horarios por pasar el numero de la sala y luego el numero del día y del mes. Un objeto de tipo “Lectura.java” permite leer los datos en la base de datos en una lista de tipo “Horario.java” y luego mandarla al cliente para su consultación.
Cuando el sistema detecta la desconexión del cliente o el corte de la conexión, el objeto “NuevaConexion.java” destruye la socket creada para el cliente y significa la desconexión al Main.java entre otro por botar el usuario de la lista de los conectados si se puede (sino el problema es más complejo que una sola desconexión).
III. El Cliente
El cliente representa cada uno de los usuarios que se conectan al servidor. El cliente debe en primer tiempo “hablar” con el servidor para conectarse, y luego para bajar las reservaciones. Hace falta también encontrar una buena forma de presentar las reservaciones de una sala.
El esquema representa las relaciones entre las diferentes clases del lado cliente. Se nota que la ejecución se hace alrededor de una función “principal”, Fenetre.java. Pero la ejecución del programa entero depende de Conexión.java que condiciona la ejecución de Fenetre.java.
1. Comunicación con el servidor
El “main” Client.java invoca un método de conexión que crea una socket y luego abre una ventana de dialogo para la entrega de la identificación y de la llave personal. Este comunica después con el servidor para la conexión. Si esta se hace, “Conexión.java” llama a la clase “Fenetre.java” que crea la ventana del usuario. Al invocar a Fenetre.java, el programa baja desde el servidor los datos de una sala predefinida (por default), y de la semana corriente.
Esas bajadas se hacen a cualquier cambio en la ventana del cliente permitiendo así de tener siempre la última versión de las reservaciones. Las bajadas son de tamaño menor, y se hacen muy rápidamente, sin perdidas. Pues no es un problema mayor bajar tan frecuente los datos desde el servidor.
Las comunicaciones que ocurren después son las mismas que las vistas antes del lado servidor, pero al revés. Existe la función “Guardar” que permite enviar la palabra llave “cambio” al servidor y luego el día que ha cambiado (con el nombre de los profesores…). Existe “NuevaPersona” que permite agregar un nuevo usuario (por un administrador). Y la función “Actualización” invoca a la clase “NuevaSemana.java” que manda el numero de la sala, y luego la fecha de lo diferentes días de la semana, para alcanzar los datos de reservaciones. Se reconocen exactamente las cosas descritas antes.
2. Interfaz grafico
El interfaz grafico tiene una tabla donde se ponen los horarios como en cualquiera tabla horaria, ComboBoxes para cambiar la fecha y de sala, una zona de texto para poner la fecha del día seleccionado y otra zona de texto para hacer una descripción más completa de la reservación seleccionada. En el caso de un usuario “administrador” se agrega un botón “borrar” (para suprimir una reservación) y un menú que permite agregar un usuario o cerrar la ventana.
Interfaz normal
Interfaz administrador
Se nota ahora la descripción más detallada de la reservación. Esa contiene la palabra “fijo” en rojo, y quiere decir que la reservación aparecerá cada semana en esta sala.
La navegación en la tabla se puede efectuar o con el mouse, o con el teclado. En este caso se puede usar “Enter” para hacer la reservación y “Del” para borrar una reservación en el caso de un administrador.
3. Gestión del calendario
Una grande dificultad de este proyecto fue la gestión del calendario dentro de la tabla, para permitir entre otro de mostrar una semana que sea a mitad en un mes y otra en otro. Hacía falta crear una lista de los meses, con el número de día en el mes (gracias a la clase ListMes.java). Después lo mejor era poner en una tabla de tipo diasem.java, para acordarse más fácil del día y del mes de cada columna de la tabla.
Gracias a eso, y a la posibilidad de conocer el día, el mes y el número del día en la semana, se podía hacer un interfaz muy sencillo pero que tenía un máximo de informaciones útiles, y bien presentadas. Así se ve la fecha bien escrita, permitiendo así de saber sin consultar otro calendario, si la reservación es buena.
Las fechas aparecen también en los encabezases de las columnas para una mejor lectura de la tabla. Y la misma fecha que aparece acá aparecerá después en el titulo del archivo de texto en el caso de que se hace la reservación.
IV. Desarrollo del problema
1. Servidor-Cliente simple
La primera etapa era de desarrollar un servidor cliente simple con una conexión básica y entrega de respuesta del servidor. Luego desarrollar las relaciones entre servidor y cliente para permitir hacer test cuando desarrolle el multiconexion, y poner las bases de las futuras interacciones posibles.
2. Múltiples conexiones
La segunda grande etapa fue de desarrollar un servidor más elaborado que permita muchas conexiones y una gestión separada de los diferentes clientes para una mejor seguridad de intercambio de datos. Y para acabar esta etapa muchos testes para averiguar el buen funcionamiento del programa, y la idoneidad de la solución encontrada. Los problemas con el número de conexión que pueden ocurrir antes que se pare el servidor puede ser demasiado grande para usar una simple lista.
Por eso use un vector de tipo usuario que permita guardar los datos interesantes de cada cliente para poder agregar muchos clientes, y borrarlos una vez desconectados con la mejor gestión de alocacion de memoria.
3. La base de datos
El siguiente paso fue de agregar una base de datos para desarrollar las diferentes pedidas del cliente al servidor (conexión con identificación, reservación, …). Luego entro en cuenta la gestión de las reservaciones, y la solución más fácil a desarrollar se averiguo la que esta descrita antes.
4. Diseño de la ventana
El diseño de la ventana presentaba una parte importante del lado cliente, porque para servir el programa debe presentar una descripción detallada de las reservaciones y permitir una buena navegación en el calendario y una vista clara de las disponibilidades en general. Esta etapa incluye también el desarrollo de la gestión del calendario, desafío importante para la ejecución del programa entero. El diseño de la ventana y la agregación de las últimas posibilidades de los usuarios obligaron la agregación de usuarios con derechos especiales: los administradores que pueden agregar un nuevo usuario, borrar o agregar reservaciones fijas.
Conclusión
Este proyecto me ha permitido aprender mucho sobre la gestión de la red en java, completar y usar mis conocimientos aprendidos en cursos de red informáticas. La parte visual del programa no representa una dificultad mayor, pero me permitió entretener mis conocimientos en diseño de ventanas. En general, este proyecto era una buena revisión de las clases del año, y reagrupaba muchas cosas diferentes.
Este proyecto todavía no está listo para usarlo oficialmente, pero presenta una buena base para el desarrollo del futuro programa de gestión. Entre los diferentes cambios que se necesitan: una mejor gestión del mando de datos, un administrador más elaborado, tal vez una mejor gestión de la tabla calendaría, una conexión que use el nombre del login para hacer las reservaciones, mandar un mail automáticamente al profesor cuya reservación ha sido borrada por el administrador, gestión de las anulaciones puntúales de cursos fijos…
Este proyecto ha sido muy interesante para mi, y espero que alguien aprovechara de las decenas de horas de desarrollo ya hechas para hacer un programa bien elaborado.