Pierre ALAUZET Ludovic JEANSON Chama EL-HASSOUNI Agnés LEBON Proyecto Practico de Construcción de un Software

Transcripción

1 SFI : Sociedad Ferroviaria Internacional Aplicación de gestión de billetes de tren Pierre ALAUZET Ludovic JEANSON Chama EL-HASSOUNI Agnés LEBON Proyecto Practico de Construcción de un Software 30/05/2008

2 Sumario 1. Requisitos y cambios.3 a. Requisitos b. Diagramas de casos de uso 2. El Software Análisis y diseño.10 a. Diagramas de clases b. Diagramas de secuencias 4. Resultados.16 Anexos..17 Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 2 sur 21

3 1. Requisitos y cambios a. Requisitos Nuestros clientes pertenecen a una empresa fervoraría. La llamaremos SIF (Sociedad Internacional Ferroviaria). Desean un software de formato web de reserva de billetes de tren. Los primeros requisitos de nuestros clientes son los siguientes : El software debe ser separado en dos partes : Una parte de reserva dónde: - El usuario reserva un viaje con su origen y su destino en una lista de trayectos. El viaje puede ser una ida o una ida y vuelta. - Una ida y vuelta es más barata que la ida sólo. - Puede elegir diferentes elementos : la clase de su viaje (turista o preferente), el tipo de vagón (fumador o no) y el tipo de asiento (ventana o pasillo). - La reserva se valida con una confirmación. - El usuario puede ver sus reservas. Una parte de administración dónde la empresa puede : - Añadir trayectos con su tren, su origen, su destino, su fecha y hora de viaje, sus precios y sus clases. - Suprimir trayectos. - Modificar las fechas de un trayecto. - Añadir una estación. - Suprimir una estación. Después de la primera iteración, nuestros clientes pidieron cómo cambio el añadido de una conexión de los usuarios, de tal manera que la aplicación sea multi-usuarios. Para hacerlo posible, añadimos la posibilidad para el usuario de identificarse y registrarse. Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 3 sur 21

4 b. Diagramas de casos de uso i. Usuario ii. Administrador Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 4 sur 21

5 El administrador puede ver los trayectos existentes, añadir y suprimir un trayecto, y añadir y suprimir una estación. El usuario puede buscar un trayecto con las fechas de ida (y vuelta), seleccionar un trayecto en la lista de trayectos disponibles, confirmar su selección, ver sus reservas, identificarse como administrador. Además puede identificarse cómo usuario o registrarse cómo un nuevo usuario. Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 5 sur 21

6 2. El Software Cualquier usuario puede buscar un viaje, elegir un origen, destino, una fecha de ida o una fecha de ida y de vuelta si quiere una ida y vuelta. Luego son propuestas las idas y vueltas disponibles correspondientes a su búsqueda, y el usuario elige las que quiere, y las opciones clase (preferente o turista), tipo (fumador o no fumador) y posición (corredor o ventana). Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 6 sur 21

7 Antes de confirmar, se figa una recapitulación de los trayectos elegidos. Para continuar y confirmar su reserva, el usuario debe identificarse. Si el usuario tiene una cuenta ya, puede conectarse y ver su reserva añadida a la lista de sus reservas ya hechas, o crea una nueva cuenta, y vuelve a su reserva hecha. Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 7 sur 21

8 Si un usuario se desconecta y se identifica otra vez, puede ver sus reservas hechas antes, que no se pierden. Un usuario puede también conectarse como administrador, y ver todos los trayectos que existen. Un administrador puede cambiar las fechas de los trayectos más allá de 3 meses o suprimir un trayecto cuya fecha más allá de 3 meses. Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 8 sur 21

9 Puede también añadir un trayecto, y definir todas sus opciones: origen, destino, periódico o único, fechas, número de coches, número de asientos, precios para cada clase y según si es una ida sola o una ida y vuelta, El administrador puede gestionar las estaciones: añadir estaciones que no existen ya o suprimir las estaciones que no están utilizadas en los trayectos. Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 9 sur 21

10 3. Análisis y diseño a. Diagramas de Clases i. Diagrama General Nuestra aplicación tiene tres niveles de acceso: - Usuario del web (que puede solo buscar un viaje) - Usuario registrado (que puede además de buscar un viaje, confirmar una reserva y ver sus reservas) - Administrador (que puede ver todos los trayectos que existen, modificar las fechas de un trayecto, añadir un nuevo trayecto y finalmente gestionar las diferentes estaciones) Primero, podemos ver en el diagrama de clases que tenemos dos clases, Usuario y Admin. Cada clase contiene los datos del usuario o del administrador. La clase Usuario, además, conoce a su lista de reservas ya hechas. Estas dos clases son controladas por dos Controladores, ControladorUsuarios y ControladorAdmin, que permiten añadir, suprimir o verificar la conexión de un usuario o de un administrador. Permiten también saber quién es el Usuario o el Administrador conectado. Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 10 sur 21

11 Los gestores de las Ventanas conocen a estos dos controladores y pueden entonces fijar las ventanas correctas para cada tipo de usuario. Como lo indican sus nombres, estas dos clases conocen las ventanas a fijar y gestionan la fijación de la correcta ventana. El objeto Conexión permite pasar de las ventanas de un Usuario (conectado o no) a las de un administrado. Segundo, cada trayecto es representado por un objeto del tipo Trayecto. Un trayecto representa el trayecto de un tren entre dos estaciones. Todos los trayectos son reunidos en clase ListaTrayectos que contiene una lista de trayectos. Un trayecto contiene: - Las horas de Salida y de Llegada del tren - La o las fecha(s) del trayecto (un trayecto puede ser utilizado a una fecha única o durante un período con días elegidos) - Los diferentes precios del trayecto (precio diferente entre clase Turista y Preferente y si el Usuario hace una ida sola o una ida y una vuelta) El mismo trayecto conoce a: - El tren utilizado (que es compuesto de objetos del tipo Coche) - Dos objetos del tipo Estacion que representan la origen y el destino del trayecto. Cada objeto del tipo Estacion tiene un nombre (por ejemplo Madrid Atocha ) y conoce a una lista de destinos que son otras estaciones (esta lista es utilizada para simplificar la fijación de la estaciones de destino cuando una origen es utilizada durante una búsqueda). Todas las estaciones son reunidas dentro de una lista de estaciones ListaEstaciones. Cada lista (de trayectos y de estaciones) está gestionada por un controlador, ControladorTrayectos o ControladorEstaciones, que los controladores de ventanas utilizan para añadir, suprimir, modificar las listas y sus objetos (vamos a discutir de estos controladores de ventanas mas tarde). Una última parte del diagrama necesita ser analizada. Hemos dicho antes, que cada objeto Usuario contiene su propia lista de Reservas. Cada objeto del tipo Reserva contiene: - La fecha seleccionada (porque un trayecto puede ser periódico, entonces tenemos que guardar la fecha seleccionada) - El precio de la reserva (porque una reserva representa un trayecto entre dos estaciones y entonces no podemos saber si al momento de la reserva, el usuario había reservado una ida y vuelta o solo una ida) La misma reserva conoce a: - El trayecto seleccionado - El usuario que ha hecho la reserva - El coche y el asiento seleccionado (un Coche está compuesto de Asientos) Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 11 sur 21

12 Existe un controlador de las reservas del usuario conectado (ControladorReservas); este controlador debe conocer al ControladorUsuarios para saber quién es el usuario conectado y entonces conocer su lista de reservas para modificarla. ii. Utilización del Modelo-Vista-Controlador En nuestra aplicación, hemos utilizado el patrón Modelo-Vista-Controlador para separar la fijación de los datos de su tratamiento y gestión. Vamos a describir cada ventana y la aplicación del MVC a ella. Aquí, estamos en la parte administrador de la aplicación. El GestorVentAdmin conoce y fija la ventana VentanaVerTrayectos. Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 12 sur 21

13 Podemos ver en el diagrama precedente que esta ventana VentanaVerTrayectos contiene dos vistas que implementan la interfaz Observer. La vista de la lista de trayectos (VistaVerListaTrayectos) conoce a la lista de trayectos y la vista de un trayecto único (VistaVerTrayectoUnico) conoce al trayecto que está fijado en detalle. Estas dos vistas envían sus eventos al controlador de la ventana (ControladorVentanaVerTrayectos). Podríamos utilizar un controlador por cada vista, pero el tratamiento es demasiado simple. Por esto, hemos decidido utilizar un único controlador por las dos vistas. Cuando una acción del usuario llega al controlador (por ejemplo suprimir un trayecto), este ultimo delega la acción al controlador de trayectos (ControladorTrayectos) que hace las modificaciones sobre el modelo (aquí la lista de trayectos). Los objetos del tipo Trayecto y la lista de trayectos (ListaTrayectos), cuando cambian, notifican a sus observadores que han cambiado (heredan de la clase Observable). Las vistas que observan estos modelos (aquí nuestras dos vistas) pueden entonces actualizarse. Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 13 sur 21

14 b. Diagramas de secuencias Aquí, en los diagramas de secuencias, tomamos en cuento unos ejemplo de utilización de la aplicación. i. Diagrama de conexión del administrador En este diagrama, un usuario simple, sin derechos, intenta conectarse como administrador : Utilizamos aquí un FirePropertyChange, que se base en el mismo sistema que el patrón Observer, para enviar unos señales entre las clases. Por ejemplo, el GestorVentUsuario escucha la VentanaConeccionAdmin sobre los señales enviados desde esta ventana. Sin embargo, la VentanaConeccionAdmin no sabe quien la escucha, pero sabe solamente que debe enviar un señal cuando unas condiciones sobre acciones se reúnen. En la ventana VentanaConeccionAdmin, el usuario pulse el botón "Conectarse" después haber entrado sus informaciones de identificación. El ControladorConneccinAdmin recibe las informaciones sobre esta acción, y en el caso que el administrador es conocido por el sistema, envía la información a la VentanaConeccionAdmin. La Ventana, gracias al FirePropertyChange, envía un señal que el GestorVentUsuario recibe. A su turno, envía un mensaje que la clase Conexión recibe. La clase Conexión sabe a este momento que un administrador está conectado, y quien es. Crea un nuevo GestorVentAdmin, cuya la primera acción es crear a su turno la VentanaVerTrayectos. Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 14 sur 21

15 i. Diagrama de derechos de acceso En este diagrama, un usuario simple, sin derechos, intenta conectarse como usuario con derechos : Aquí, los controladores de las ventanas no son representados para mas simplicidad. Pues tenemos que saber que los resultados sobre las acciones, como accionbotonbuscar(), son enviados por el controlador de cada ventana, y no por la ventana directamente. Entonces aquí tenemos un usuario que tiene dos opciones, o sea buscar un viaje sin conectarse, o sea ya conectarse antes de buscar un viaje : - Si el usuario elige buscar un viaje, puede ver la lista de viajes disponibles, y ver la confirmación de los trayectos seleccionados. En este momento, no puede confirmar y reservar, está obligado registrarse. La VentanaConexionUsuario se crea y el usuario decide o sea identificarse, o sea inscribirse si esta un nuevo usuario. Después, volvemos en la confirmación del viaje, y puede esta vez confirmar el viaje y ver sus reservas. - Si el usuario elige ya identificarse o registrarse, lo dirigimos directamente en la ventana VentVerReservas. Entonces tiene todos los derechos en la aplicación desde el principio. Después puede buscar, seleccionar, confirmar y ver el viaje seleccionado en sus reservas. Para concluir, este diagrama muestra solamente que un usuario simple no puede acceder a algunas partes de la aplicación sin registrarse, como a la ventana VentVerReservas. Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 15 sur 21

16 4. Resultados y conclusiones : Este segundo prototipo con los cambios de requisitos, nos acercamos de una aplicación real que puede ser pedido en nuestro futuro trabajo. Era un proyecto muy interesante y que nos ha aprendido muchas cosas. Del aprendizaje general, hemos entendido que el diseño y la concepción son más importantes (de un punto de vista del mantenimiento) que la manera de representar la aplicación, o que el devuelvo final. Lo que nos aparece obligatorio ahora, es empezar codificar con un diseño justo, ambiguo, flexible pero robusto. Además, hemos aprendido trabajar en equipo de más de dos personas, lo que no hacemos en nuestras estudias. De manera más técnica, entender e implementar unos patrones como el MVC (Modelo-Vista-Controlador) o el Observable nos ha aprendido mucho sobre la concepción y la implementación de un proyecto. El trabajo para cambiar la concepción del primer prototipo fue largo a causa de muchos problemas de diseño. Pero hemos llegado a un segundo prototipo que corrige una grande parte de las errores. Este trabajo en dos partes fue muy interesante y útil para nuestra carrera. Hemos dicho que una grande parte de las errores no existen más en el segundo prototipo, pero hemos visto durante la presentación que falta unas cosas. Por ejemplo, la noción de billetes no existe en nuestro diseño, o el trayecto debe contener solamente la origen y el destino sabiendo que el resto, por el ejemplo los precios, deben estar al exterior e independiente del trayecto. Con este segundo punto, ganaríamos en ambigüedad. Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 16 sur 21

17 Anexos 1. Diagramas de clases a. Diagrama general. 18 b. Diagrama de ejemplo de una parte MVC Diagramas de secuencias a. Diagrama de conexión del administrador..20 b. Diagrama de derechos de acceso. 21 Alauzet/Jeanson/El Hassouni/Lebon SFI - Proyecto Software 20/05/2008 Page 17 sur 21