En esta práctica se desarrollará un portal Web de compra de billetes de tren por parte de clientes finales. Este portal, permitirá, fundamentalmente, consultar horarios de trenes y disponibilidad de plazas, así como comprar billetes y consultar o cancelar billetes comprados previamente.

El modelo de datos de la aplicación es prácticamente el mismo que se ha publicado en el enunciado de la práctica global Swing. La única diferencia es que se añaden dos tablas nuevas que permiten almacenar los datos de los usuarios registrados en el sistema, así como asociar billetes a usuarios, cuando estos realizan la compra estando autenticados:

CREATE TABLE Usuarios (
        uid INT(3) NOT NULL auto_increment,
        nombre VARCHAR(128) NOT NULL,
        alias VARCHAR(16) NOT NULL,
        password VARCHAR(16) NOT NULL,
        PRIMARY KEY (uid),
        UNIQUE INDEX (alias)
) ENGINE = INNODB;

CREATE TABLE BilletesUsuario (
        IdUsuario INT(3) NOT NULL,
        IdBillete INT(11) NOT NULL,
        PRIMARY KEY (IdUsuario, IdBillete),
        INDEX (IdUsuario),
        FOREIGN KEY (IdUsuario) REFERENCES Usuarios (uid)
           ON UPDATE CASCADE,
        FOREIGN KEY (IdBillete) REFERENCES Billetes (IdBillete)
           ON UPDATE CASCADE
) ENGINE = INNODB;

Los campos de la tabla de usuarios son los siguientes:

La tabla BilletesUsuario relaciona los billetes comprados por un usuario autenticado con dicho usuario. Sus campos son los identificadores de billete y usuario de las tablas Billetes y Usuarios.

El sistema debe implementar el proceso de compra de un billete, y el de consulta/cancelación de billetes comprados por el usuario. Para realizar una compra es opcional estar autenticado en el sistema. Para obtener un listado de los billetes comprados es obligatorio que el usuario esté autenticado, y sólo se mostrarán aquellos billetes que hubiese comprado estando autenticado con el mismo identificador de usuario.

La vista principal del sistema presenta un formulario que permite realizar una búsqueda de líneas por estación de origen, estación de destino y fecha. Además, en algún lugar de la página debe presentar información relativa a la autenticación de usuarios: si el usuario está autenticado, presenta su nombre y un enlace a la vista de billetes comprados por el usuario; si no está autenticado, presenta un formulario que le permita autenticarse. Una vez autenticado el usuario, la aplicación volverá a mostrar esta vista principal.

Adicionalmente, se propone la realización de tareas opcionales, que serán tenidas en cuenta en la evaluación, pero no son necesarias para obtener el aprobado en la práctica.

El objetivo de estas funciones adicionales es que el alumno explote su capacidad para resolver los problemas que se le planteen de forma autónoma. Por ello, la ayuda de los profesores con respecto a estas funciones será más limitada que con respecto a las funciones mínimas. La calificación de las funciones adicionales depende de la dificultad asociada a su implementación, por lo que no todas se valorarán con la misma puntuación. Se proporciona una lista grande de funciones opcionales para que haya más variedad de opciones. Obviamente, no es necesario implementar todas para obtener la máxima calificación.

Los alumnos pueden proponer funciones adicionales que no se detallen en este enunciado, pero es necesario consultar a los profesores acerca de la posible valoración de las mismas antes de implementarlas.

Se aconseja seguir las siguientes recomendaciones para facilitar el desarrollo de la práctica:

La práctica se entregará a través del sistema Web que se habilitará al efecto, cuya URL se publicará en la página principal de la Web de la asignatura.

Se entregará un único fichero con extensión .war (comprimido con JAR), que contenga la aplicación web lista para ser desplegada (con todos los ficheros de configuración, clases compiladas, imágenes, hojas de estilo, etc.) Adicionalmente, en el directorio WEB-INF/src del fichero WAR se incluirá el código fuente de todas las clases Java utilizadas.

El fichero WAR contiene toda la estructura de la aplicación Web comprimida desde dentro del directorio principal de la misma:

cd ${CATALINA_HOME}/webapps/miaplicacion/
jar cvf miaplicacion.war *

Para reducir el tamaño de la entrega, este fichero no debe contener datos innecesarios como los siguientes:

Independientemente de que se haya desarrollado la aplicación en un entorno integrado como Eclipse o NetBeans, los autores de la práctica deben ser capaces, el día de la entrevista de evaluación, de compilar su aplicación desde línea de comandos. Aquellos que no sepan hacerlo pueden preguntar a los profesores en las prácticas o en tutorías, antes de vencer el plazo de entrega.

La calificación obtenida en esta práctica estará entre 0 y 10, y supondrá un 25% de la calificación final en la asignatura. Es necesario aprobar esta práctica (obtener al menos un 5) para aprobar la asignatura.

Parte de la evaluación se basará en una entrevista personal de los profesores con los autores de la práctica, que se realizará con cita previa en los horarios de clases prácticas. Los dos miembros de la pareja de prácticas deben demostrar conocimientos suficientes de la práctica que hayan entregado.

Además de que se implemente correctamente la funcionalidad obligatoria, se tendrán en cuenta los siguientes aspectos en la evaluación:

Para obtener una calificación de 5 o superior es necesario implementar la funcionalidad mínima expuesta en este enunciado. Por otra parte, un programa que implemente sólo la funcionalidad mínima puede optar hasta una calificación máxima de en torno a 8 teniendo en cuenta el resto de aspectos a valorar. El resto de la calificación, hasta 10, puede obtenerse implementando funcionalidad opcional.