Proyecto: Aplicación de promoción de eventos

En este proyecto desarrollarás la aplicación web de un sitio de promoción de eventos. Debes especializar tu aplicación en un tipo de evento concreto (por ejemplo, conciertos, representaciones de teatro, exposiciones, ferias, fiestas populares, etc.).

En la aplicación existirán al menos tres perfiles de usuario: administradores, organizadores de eventos y usuarios normales. Todos los usuarios, independientemente de su tipo, podrán realizar las acciones permitidas para usuarios normales, pero habrá funcionalidad que será exclusiva para administradores o exclusiva para organizadores de eventos. Un usuario no puede ser administrador y organizador de eventos al mismo tiempo. Parte de la funcionalidad de la aplicación estará también disponible para usuarios sin cuenta o no autenticados.

El proyecto se dividirá en funcionalidad obligatoria, que toda entrega debe implementar, funcionalidad adicional y funcionalidad avanzada.

La funcionalidad obligatoria incluye: crear cuentas de usuario, cambiar el tipo de cuenta de usuario (administradores), crear eventos (organizadores de eventos), ver eventos (cualquier usuario, incluso sin cuenta), guardar eventos (todos los usuarios), recomendar eventos (todos los usuarios), bloquear a usuarios (todos los usuarios) y ver estadísticas de actividad de usuarios (administradores).

Tienes libertad para decidir qué funcionalidad adicional y avanzada deseas implementar en tu proyecto.

Las siguientes condiciones aplican al proyecto:

• El proyecto debe ser desarrollado en parejas. Otras configuraciones de grupo solo serán permitidas bajo circunstancias excepcionales, y siempre con la aprobación previa de los profesores. La composición de cada pareja debe ser comunicada a los profesores con antelación, en los plazos y medios que se establezcan.
• El proyecto debe ser desarrollado con el lenguaje Java y el framework Spring MVC, usando Spring Data JPA para acceder a la base de datos.
• Las entregas deben funcionar en los ordenadores de los laboratorios del Depto. de Ingeniería Telemática (físicos o virtuales) con las bases de datos proporcionadas. Puedes trabajar en tus propios ordenadores si lo prefieres, pero debes comprobar regularmente que tu código funcione correctamente en los ordenadores del laboratorio.
• La base de datos que configures en el código de tu entrega debe contener suficientes datos para que los profesores puedan probar tu aplicación adecuadamente.
• Compartir código entre diferentes grupos está estrictamente prohibido. Será considerado y denunciado como plagio confirme a la normativa en vigor.
• Es imprescindible que te presentes a una entrevista de evaluación junto con tus compañeros de grupo en la fecha y la hora convenidas. La entrevista es una prueba de evaluación de la asignatura.
• Todos los miembros de un grupo deben participar activa y equitativamente en el desarrollo del proyecto. Los grupos en que esto no suceda pueden ser divididos por los profesores antes de la fecha de entrega, incluso con poca antelación a la misma. Las calificaciones de los miembros de un grupo podrían ser distintas si los profesores consideran que la participación de alguno de sus miembros no ha sido suficiente.

Cualquier funcionalidad que no se mencione expresamente en esta sección no es obligatoria. La funcionalidad no obligatoria que implementes será evaluada como funcionalidad adicional o funcionalidad avanzada.

Todas las entregas deben implementar la siguiente funcionalidad:

• Cuentas de usuario: Existirán al menos tres perfiles de usuario: administradores, organizadores de eventos y usuarios normales. Todos los usuarios pueden iniciar y cerrar sesión. Los usuarios sin cuenta pueden crear cuentas de usuario normal rellenando un formulario con sus datos. Habrá funcionalidad exclusiva que solo los administradores o solo los organizadores de eventos podrán realizar. Los administradores y los organizadores de eventos pueden realizar cualquier acción que puedan realizar los usuarios normales.
• Cambiar el tipo de cuenta de usuario: Los administradores pueden cambiar el tipo de cuenta de cualquier usuario a administrador, organizador de eventos o usuario normal. Si un usuario pierde privilegios, se mantienen los efectos de las acciones que este haya realizado hasta entonces. Por ejemplo, si un organizador de eventos crea un evento y posteriormente pierde su condición de organizador de eventos, el evento seguirá existiendo.
• Crear eventos: Los organizadores de eventos pueden crear nuevos eventos introduciendo sus datos.
• Ver eventos: Todos los usuarios, incluyendo los usuarios sin sesión iniciada, pueden ver los detalles de cada evento.
• Guardar eventos: Todos los usuarios pueden guardar (y dejar de guardar) cualquier evento que exista en la plataforma, con el fin de acceder al mismo en el futuro con mayor rapidez. Con este fin, la aplicación permitirá a cada usuario ver la lista de todos los eventos que haya guardado.
• Recomendar eventos: Todos los usuarios pueden recomendar eventos a otros usuarios de la aplicación de los cuales conozcan su nombre de usuario. Los usuarios verán en la vista principal de la aplicación, de forma prominente, las nuevas recomendaciones de eventos que hayan recibido, así como quién se las ha hecho. Los usuarios podrán consultar todas las recomendaciones de eventos que hayan recibido.
• Bloquear a usuarios: Los usuarios pueden bloquear a otros usuarios. No se mostrarán las recomendaciones de eventos que hayan recibido de los mismos, ya sea con anterioridad o con posterioridad al bloqueo. No debe ser posible para un usuario saber si ha sido bloqueado por otro. Por ello, todas las recomendaciones se almacenarán normalmente en la base de datos independientemente de la existencia de bloqueos, pero una recomendación no será mostrada a su destinatario si este ha bloqueado al usuario que la hace.
• Ver estadísticas de actividad de usuarios: Los administradores pueden consultar los datos de actividad de cualquier usuario (como mínimo, número de eventos creados, número de eventos guardados, número de recomendaciones de eventos enviadas, número de recomendaciones de eventos recibidas, número de bloqueos realizados y número de bloqueos recibidos).

El resto de la funcionalidad a desarrollar podrá ser elegida libremente por cada grupo, para obtener hasta 1,5 puntos adicionales conforme a los criterios de evaluación.

Una o dos funciones adicionales, dependiendo de su complejidad, podrían aportar la nota máxima de este apartado. Puedes consultar con los profesores en cualquier momento para saber a qué nota aspiras según lo que pretendas implementar.

Para obtener el punto de funcionalidad avanzada previsto en los criterios de evaluación debes hacer uso de otras tecnologías que no se hayan visto en clase o se hayan visto con menor profundidad.

Se proponen, a modo de referencia, algunas posibilidades a continuación, pero puedes implementar cualquier otra que pactes previamente con los profesores:

• Uso de funcionalidad del ecosistema de Spring que no se haya visto en clase, como por ejemplo el sistema de roles de usuario de Spring Security para distinguir entre administradores, organizadores de eventos y usuarios normales.
• Mejorar la apariencia, facilidad de uso o fluidez de la aplicación, así como introducir nueva funcionalidad mediante un uso más intensivo de JavaScript. Se valorará especialmente que lo combines con el envío de peticiones asíncronas al servidor, intercambiando información con el mismo en formato JSON.
• Uso de las nuevas APIs de JavaScript disponibles dentro del marco de HTML5 o proporcionadas por terceros para integrar funcionalidad útil en el contexto de tu aplicación web.
• Desarrollar de un aspecto visual y experiencia de uso con apariencia profesional y moderna. Se valorará como funcionalidad avanzada este aspecto de tu aplicación únicamente si, por la calidad de su apariencia visual y su facilidad de uso, está a la altura de aplicaciones web profesionales actuales.
• Uso de funciones avanzadas de CSS, como por ejemplo Flexbox.
• Diseñar la aplicación para que se adapte bien tanto a ordenadores de escritorio como a dispositivos móviles con diversos tamaños de pantalla (teléfonos móviles, tablets). Puedes opcionalmente utilizar para ello Bootstrap o algún otro entorno similar que facilite alcanzar este objetivo. No obstante, la implementación de esta mejora va más allá de simplemente utilizar dichos entornos, siendo necesario que cuides con detalle cada una de las vistas y acciones a realizar para garantizar que realmente se adapten bien a dispositivos móviles. Las herramientas para desarrolladores del navegador te permitirán comprobar cómo se vería la aplicación en dispositivos de pantalla pequeña.
• Presentación del cartel de cada evento. Los organizadores de eventos pueden subir la carátula del evento (por ejemplo, cuando lo crean) y esta se presenta a los usuarios en la vista del evento y en cualquier otra vista donde resulte conveniente. Puedes consultar cómo hacerlo en la documentación de Spring MVC.
• Enviar notificaciones por correo electrónico a los usuarios cuando reciban recomendaciones de eventos.
• Implementar otras medidas de seguridad adicionales, distintas de las que se consideren obligatorias en este enunciado o que Spring MVC o Spring Security implementen por defecto.
• Gestionar el desarrollo del proyecto mediante un sistema de gestión de versiones distribuido desde el inicio de su desarrollo como, por ejemplo, Git, y alojar el proyecto en un servicio compatible con este sistema de control de versiones como, por ejemplo, GitHub, BitBucket o GitLab. Debes asegurarte de que el proyecto sea privado, esto es, que solo los miembros del equipo puedan acceder al mismo. Los tres proveedores mencionados te permiten disponer de cuentas privadas gratuitas. Para que se tenga en cuenta en la evaluación, se debe hacer un uso conforme a las buenas prácticas comúnmente aceptadas en el uso de sistemas de control de versiones. Por ejemplo, commits progresivos y frecuentes, no mezclar en un mismo commit varios cambios que no tengan relación entre sí, poner mensajes informativos en los commits, que cada commit refleje quién es el autor real de los cambios, mantener fuera del control de versiones ficheros generados automáticamente, como por ejemplo ficheros .class y cualquier otro fichero que Gradle genere automáticamente.

Cada aspecto avanzado se evaluará en función de la complejidad de su implementación teniendo en cuenta la dificultad técnica, documentación disponible, etc.

También puedes implementar otros aspectos avanzados propuestos por ti, siempre que supongan profundizar en alguna de las tecnologías vistas en clase o el uso de otras tecnologías nuevas. Debes consultar previamente con los profesores para saber si tu propuesta resulta adecuada y obtener una estimación de cómo se valoraría en tu calificación. No se valorará que desarrolles nueva funcionalidad que simplemente consista en utilizar las mismas técnicas que se usan en la funcionalidad obligatoria y adicional.

Uno de los aspectos que más se valorarán con respecto a esta funcionalidad avanzada es tu capacidad para utilizar la documentación disponible y resolver los problemas de forma autónoma. Por ello, contarás con un soporte más limitado por parte de los profesores que para la funcionalidad obligatoria y adicional.

Es muy aconsejable que al principio del proyecto o durante el desarrollo del mismo pidas a los profesores una estimación de la puntuación que obtendrías por la implementación de cada función adicional o avanzada que te plantees realizar. Esto te permitirá conocer qué debes desarrollar para alcanzar la puntuación a la que aspires.

Aviso: el presente proyecto es una prueba de evaluación. El plagio y otros tipos de fraude académico relativos al mismo serán denunciados a las autoridades académicas conforme a la normativa en vigor.

En la evaluación se tendrá en cuenta la correcta implementación de la funcionalidad obligatoria, funcionalidad adicional y funcionalidad avanzada, así como diversos aspectos de calidad de su implementación:

• Funcionalidad obligatoria (7,5 puntos): La máxima puntuación en este bloque se otorgará a las entregas con una implementación de toda la funcionalidad obligatoria que, además de funcionar correctamente, cumpla con todos los criterios de calidad que se detallan a continuación.
• Funcionalidad adicional (1,5 puntos): Puedes integrar otras funciones en tu aplicación que decidas libremente. Consulta el apartado de funcionalidad adicional para más detalles. Para que se te otorguen puntos, la funcionalidad adicional debe estar implementada correctamente y cumplir con los requisitos de calidad.
• Funcionalidad avanzada (1 punto): La correcta implementación de funciones avanzadas te permitirá obtener 1 punto más. Si los profesores consideran especialmente meritoria tu implementación de una función avanzada, esta podría compensar parcialmente la puntuación perdida por algunos errores en la implementación de la funcionalidad obligatoria, así como puntuar igualmente en el apartado de funcionalidad adicional. Durante el desarrollo del proyecto puedes consultar a los profesores cómo se tendrá en cuenta en tu evaluación la implementación de las funciones avanzadas que planees realizar.

Los criterios de calidad que se espera que cumpla tu proyecto son:

• Que cada función implementada funcione correctamente, es decir, se comporte como se requiere.
• Que las vistas de la aplicación (su interfaz de usuario) sean claras y fáciles de usar. Que la apariencia visual sea razonablemente buena.
• Que el código fuente esté correctamente organizado y sea claro de leer y entender. Debe seguir los principios explicados en los laboratorios de Spring MVC en cuanto a organización del código. Si bien puedes dejar comentarios en partes especialmente complejas del código, no es necesario que haya comentarios exhaustivos de todo el código.
• Que el diseño del esquema de la base de datos sea adecuado, incluyendo la división de los datos en entidades (tablas), el tipo de datos de cada atributo (columna) y la declaración de relaciones uno a muchos, muchos a muchos, etc. entre clases (tablas).
• Que el uso de HTML y CSS sea correcto. Los documentos HTML deben incluir el contenido de la página, mientras que las propiedades de estilo deben ser declaradas mediante CSS. Salvo en casos justificados, debería haber una única hoja de estilos CSS compartida por todas las vistas de tu aplicación. Se deben utilizar los elementos de HTML apropiados para cada caso (por ejemplo, en un formulario cada control debe ser del tipo más adecuado para el dato a recibir).
• Que la aplicación maneje correctamente situaciones de error potenciales, dando a los usuarios mensajes de error informativos cuando sea apropiado. No se considera apropiado que la aplicación muestre trazas de excepción o mensajes de error del servidor para errores previsibles (por ejemplo, que el usuario no rellene un control obligatorio en un formulario).
• Que los controladores comprueben todos los datos que reciban de los usuarios, incluso si dichos datos están ya siendo controlados en el lado del cliente. No comprobar los datos en el lado del servidor abre la puerta a múltiples vulnerabilidades potenciales.
• Que haya controles de acceso adecuados. Por ejemplo, solo los organizadores de eventos deberían poder crear nuevos eventos. No es suficiente con que no se muestre un enlace o formulario a otros tipos de usuarios, sino que también debe el controlador que reciba la petición de creación del evento comprobar que el usuario autenticado ejerce el rol de organizador de eventos. Lo mismo aplica a otras funciones de la aplicación, como cambiar el tipo de usuario (solo un administrador puede hacerlo), dejar de guardar eventos guardados (solo el usuario que los ha guardado puede hacerlo), etc.

Parte de la evaluación se basará en una entrevista personal del profesor con los autores de la práctica, que se realizará con cita previa. Los dos miembros de la pareja de prácticas deben asistir a la misma y demostrar conocimientos suficientes de la práctica que hayan entregado. Si no fuese así, el miembro de la pareja que no muestre unos conocimientos mínimos podría recibir una nota inferior e incluso suspender el proyecto.

Durante la entrevista, se compilará y ejecutará cada proyecto, y se probará su funcionamiento en el entorno de los laboratorios. Es necesario que la aplicación entregada esté configurada para utilizar una de las bases de datos del laboratorio y que el día de la entrevista dicha base de datos que use cada grupo disponga de suficientes datos cargados para poder probar la aplicación.