Práctica Java POJO de Integración de Sistemas Sitio Web de Apuestas Deportivas

Transcripción

1 Práctica Java POJO de Integración de Sistemas Sitio Web de Apuestas Deportivas Curso académico Introducción La práctica de Integración de Sistemas consistirá en el diseño e implementación de dos aplicaciones Web, una con frameworks Java POJO (Tapestry, Spring e Hibernate) y otra con.net. Además, se realizará una integración entre ambas mediante XML sobre HTTP, de manera que la aplicación.net pueda acceder a parte de la funcionalidad y datos de la aplicación Java. Cada aplicación Web se evaluará de 0 a 5 puntos. Este documento contiene el enunciado de la aplicación Web Java, que consistirá en la implementación de un sitio Web de apuestas deportivas con un modelo de funcionamiento muy simplificado. 2 Funcionalidad básica Este apartado especifica la funcionalidad básica del sitio Web de apuestas deportivas con un modelo de funcionamiento muy simplificado. Esta funcionalidad deberá ser implementada por todos los alumnos que cursen las asignaturas IS-Ingeniería o IS- Máster. 2.1 Modelo de información Un usuario se registra en el sitio Web de apuestas especificando cierta información de registro, a saber, su seudónimo (login), contraseña, nombre, apellidos y dirección de correo electrónico. Para permitir que los usuarios puedan realizar apuestas, el sitio Web mantiene para cada usuario una cuenta virtual, que simplemente guarda su saldo. Cuando un usuario se registra, el sitio Web le proporciona un saldo inicial. El sitio Web permite visualizar en cada momento el conjunto de eventos deportivos sobre los que se pueden realizar apuestas. La información de un evento incluye su nombre (e.g. Deportivo - Real Madrid), la fecha en la que tendrá lugar y la categoría a la que pertenece (e.g. Fútbol, Motor, etc.). El sistema de categorías será plano, es decir, las categorías no tendrán subcategorías. Cada evento tiene asociado un conjunto de tipos de apuestas. Un tipo de apuesta especifica una pregunta, un conjunto de opciones de apuesta, y si admite múltiples opciones ganadoras. Cada opción indica, el resultado (e.g. Deportivo) y la cuota de ganancia asociada (e.g. 2,34) a esa opción. La cuota de ganancia representa lo que ganará el usuario si esa opción resulta ser la ganadora. Por cada opción que el usuario acierte (independientemente de que haya múltiples opciones ganadoras), su ganancia vendrá dada por: lo que apostó por esa opción * cuota de ganancia de esa opción. 1

2 A continuación se muestran algunos ejemplos de tipos de apuestas (sin indicar la cuota de ganancia de cada opción): Evento Deportivo - Real Madrid (categoría: Fútbol). Ejemplo de tipo de apuesta: pregunta = 1X2, opciones de apuesta = X, Deportivo, Real Madrid. Evento Deportivo - Real Madrid (categoría: Fútbol). Ejemplo de tipo de apuesta: pregunta = qué jugador marcará gol?, opciones de apuesta = Riki, Bodipo, Ronaldo, Van Nistelrooy. Cada usuario podrá realizar apuestas sobre cualquiera de los tipos de apuesta disponibles para los que el correspondiente evento todavía no haya empezado. Cada apuesta de usuario especifica la opción elegida por el usuario y la cantidad de dinero que éste apuesta. Obsérvese que un usuario puede apostar por n (n 1) opciones de un mismo tipo de apuesta realizando n apuestas (una por cada opción por la que apuesta), tanto si el tipo de apuesta admite múltiples opciones ganadoras como si no. Por último, la aplicación Web no tendrá que mantener información con respecto a los equipos y deportistas que aparecen en los tipos de apuestas. 2.2 Interacción con el usuario A continuación se detalla la funcionalidad que el sitio Web deberá ofrecer al usuario apostador : Registro de usuarios. Debe permitir registrar nuevos usuarios, así como permitir cambiar la información de registro posteriormente. Autenticación y salida. Un usuario se autenticará indicando su seudónimo y contraseña, con la posibilidad de recordar la contraseña para no tener que teclearla la siguiente vez. El usuario podrá salir explícitamente del sitio Web, lo que provoca que ya no se recuerde su contraseña, en caso de haber seleccionado dicha opción con anterioridad. Visualizar la cuenta. Un usuario autenticado podrá consultar el saldo de su cuenta (puede ser negativo). Búsqueda de eventos. Cualquier usuario podrá buscar eventos que todavía no hayan comenzado por palabras clave del nombre y la categoría (siendo ambos opcionales). Así, por ejemplo, si el sitio Web contiene el evento Deportivo - Real Madrid, deberá aparecer cuando se busca Deportivo - Real Madrid, Depor Madrid, madrid depor, etc., es decir, las palabras clave tienen que estar todas contenidas en el nombre del evento como palabras o parte de palabras, sin distinguir entre mayúsculas y minúsculas, y en cualquier orden. Si el usuario especifica la categoría, la búsqueda se restringirá a los eventos de dicha categoría. Si el usuario especifica la categoría, pero no las palabras clave, la búsqueda mostrará todos los eventos (que no hayan empezado) de esa categoría. Si el usuario no especifica ni las palabras clave ni la categoría, se 2

3 mostrarán todos los eventos (que no hayan empezado). Los eventos que aparecen como resultado de una búsqueda se muestran ordenados por fecha de celebración, en orden ascendente, es decir, primero los más cercanos en el tiempo. Por cada evento se mostrará su nombre y la fecha de celebración. El nombre del evento estará asociado a un enlace que permitirá visualizar todos sus tipos de apuesta (con sus opciones disponibles). Realizar una apuesta. Cada opción de un tipo de apuesta llevará asociado un enlace que permitirá a un usuario autenticado apostar por esa opción. Consultar el estado de las apuestas. Un usuario autenticado podrá consultar las apuestas hechas a lo largo del tiempo, ordenadas por fecha de realización de la apuesta, en orden descendente, es decir, primero las más recientes. Por cada apuesta, se mostrará la fecha en la que se hizo, el nombre y fecha del evento, la pregunta del tipo de apuesta, la opción elegida, la cantidad de dinero que apostó, su cuota de ganancia, la opción (u opciones) ganadora y una indicación de su estado (pendiente, ganada o perdida). Para poder insertar eventos, tipos de apuestas y publicar los resultados, un usuario especial (e.g. con seudónimo admin ) se autenticará en el sitio Web, de manera que el sitio Web le proporcione la siguiente funcionalidad: Inserción de eventos. El sitio Web le ofrecerá un enlace para añadir un nuevo evento. Búsqueda de eventos. El sitio Web le permitirá buscar los eventos por palabras clave y categoría, igual que al usuario apostador, pero a diferencia de éste, la búsqueda se restringirá a los eventos que tengan tipos de apuestas a los que no se les ha especificado la opción u opciones ganadoras o aquellos que todavía no tienen asociado ningún tipo de apuestas (estos últimos eventos corresponden a eventos que posiblemente se acaban de añadir). Gestión de tipos de apuesta. Al lado de cada evento se le mostrará un enlace que permite visualizar sus tipos de apuesta. Si el evento todavía no ha comenzado, se mostrará un enlace para añadir un nuevo tipo de apuesta. Si ya ha comenzado, para cada tipo de apuesta a la que todavía no se le hayan especificado la opción u opciones ganadoras, se mostrará un enlace que permite seleccionarlas. Una vez seleccionada la opción u opciones ganadoras de un tipo de apuesta, el sitio Web incrementará el saldo de los usuarios que han ganado apuestas de ese tipo. Para no alargar innecesariamente la práctica, la información sobre categorías se introducirá mediante sentencias INSERT INTO en un script SQL (ejecutado desde Maven, al igual que el script de creación de tablas). 3

4 2.3 Pruebas de integración de la capa modelo Para verificar el correcto funcionamiento de la capa modelo, se utilizará Spring TestContext en conjunción con JUnit 4 para implementar pruebas de integración automatizadas sobre los servicios de la capa modelo. Estas pruebas se ejecutarán automáticamente en la fase test de Maven. En una situación real, sería necesario implementar varios casos de prueba por cada método (caso de uso) de un servicio, de manera que se compruebe la correcta implementación de cada caso de uso en distintos escenarios. Sin embargo, para simplificar la realización de la práctica, bastará implementar un solo caso de prueba por cada caso de uso, que compruebe su funcionamiento en un escenario normal/usual (sin errores, sin casos especiales, etc.). 2.4 Servicios ofrecidos a otras aplicaciones En línea con la tendencia de la Web 2.0 [WEB2.0], el sitio Web de apuestas deportivas ofrece un conjunto de servicios para que otras aplicaciones puedan acceder a parte de su funcionalidad y/o datos, y potencialmente, usarlos de manera imaginativa. Cada uno de estos servicios se invocará a través de HTTP mediante una URL y devolverá el resultado (datos) en XML. Este sencillo esquema de comunicación que envía información en XML sobre HTPP es conocido normalmente como REST, y permite que una aplicación pueda acceder a funcionalidad/datos de otra sin importar la tecnología en la que estén implementadas. En un caso real, se definen modelos de negocio para que tanto el proveedor de los servicios (el sitio Web de apuestas deportivas), como las aplicaciones cliente de los servicios (la aplicación Web.NET), puedan obtener un beneficio económico. En particular, el sitio Web ofrecerá dos servicios: 1. Búsqueda de eventos que todavía no hayan comenzado, a partir de las palabras clave del nombre. Devuelve información sobre los eventos que contienen esas palabras clave en el nombre (en cualquier orden, y sin distinguir entre mayúsculas y minúsculas). La información de cada evento incluye: identificador (el usado en base de datos), nombre del evento, nombre de la categoría y fecha de celebración. 2. Visualización de los tipos de apuestas de un evento que todavía no haya comenzado. Devuelve el conjunto de tipos de apuestas (con sus opciones de apuesta) a partir del identificador del evento. 2.5 Internacionalización Con respecto a la internacionalización, sólo se pide que se use el soporte de internacionalización de mensajes, de manera que el lenguaje de la interfaz gráfica no esté dentro del código de las aplicaciones. Sin embargo, no se pedirá que la aplicación esté disponible en varios idiomas, dado que ello alargaría innecesariamente el desarrollo de la práctica (además de proporcionar otros ficheros de mensajes, sería necesario tener disponible parte de la información existente en la base de datos en varios idiomas, como por ejemplo, la información sobre eventos, tipos de apuestas y categorías). Tampoco se 4

5 pedirá que la aplicación trate otros aspectos de internacionalización (e.g. fechas, cantidades monetarias, etc.). 3 Funcionalidad adicional: pruebas de integración exhaustivas Este apartado especifica una funcionalidad opcional para las asignaturas IS- Ingeniería e IS-Master, y no forma parte de la asignatura IIS-Máster. Para el caso de uso búsqueda de eventos por palabras clave y categoría (usuario apostador ) se implementará un conjunto exhaustivo de casos de prueba (e.g. no existe ningún evento que concuerde con la búsqueda, el orden de las palabras clave no influye, etc.). 4 Funcionalidad adicional: AJAX Este apartado especifica una funcionalidad opcional para la asignatura IS- Ingeniería, no forma parte de la asignatura IS-Máster, y es obligatoria para la asignatura IIS-Máster. Con la funcionalidad básica, cuando un usuario está visualizando los tipos de apuesta de un evento, para realizar una apuesta hace clic sobre una opción de apuesta de un tipo de apuesta, y a continuación se le muestra una página que muestra la información de la apuesta con un formulario para especificar la cantidad. En esa parte opcional será preciso que la página que muestra los tipos de apuesta de un evento muestre un área (e.g. a la derecha) con las apuestas actuales del usuario, es decir, aquellas que todavía no se han resuelto. Cuando el usuario hace clic sobre una opción de apuesta, al área de apuestas actuales se le añadirá la información de la apuesta y un formulario para especificar la cantidad. Una vez especificada, la apuesta se visualizará en la lista de apuestas actuales y el formulario desaparecerá. Si el número de apuestas actuales es mayor que un determinando número (e.g. 10), el área de apuestas actuales las mostrará paginadas, con enlaces para avanzar o retroceder. Con una implementación básica, para cada una de estas interacciones (apostar y avanzar/retroceder en la lista de apuestas actuales) será preciso generar completamente la página HTML que muestra los tipos de apuesta del evento y el área de apuestas actuales. En esta parte adicional, será preciso regenerar sólo la parte afectada de la página, es decir, la que contiene el área de apuestas actuales. Este nivel de interactividad es similar al de una aplicación de escritorio. Bajo este modelo de interacción, un código JavaScript en el navegador envía una petición HTTP cuando el usuario apuesta o avanza/retrocede en la lista de sus apuestas actuales, pero a diferencia de las interacciones normales, la respuesta a la petición HTTP no es la nueva página a mostrar. La aplicación Web procesará la petición invocando el correspondiente caso de uso en la capa modelo, y a diferencia de una interacción normal, devolverá la información que es necesario actualizar en la página. Esta respuesta sólo contendrá los datos y no la forma visual de representarlos, es decir, no será una respuesta XHTML. Un código JavaScript en la página que visualiza el navegador recibirá la respuesta, accederá a los datos y modificará el árbol DOM de la página para actualizar el área de apuestas actuales. Este tipo de interacciones se denominan interacciones AJAX 5

6 [AJAX] ( Asynchronous JavaScript + XML ), y también constituyen una característica de la Web 2.0. Para la implementación de esta parte adicional, se utilizará el soporte AJAX que ofrece Tapestry [TAPESTRY-AJAX]. 5 Normativa y evaluación 5.1 Composición de los grupos La práctica se realizará en grupos de 3 personas. 5.2 Estándar de codificación Con objeto de escribir código de calidad y fácilmente legible, se seguirá un sistema de codificación común, que define reglas para nombrar clases, atributos y métodos, normas de identación, etc. Esto permite que en un equipo de desarrollo el aspecto del código sea el mismo, independientemente de qué programador lo haya escrito, lo que facilita el mantenimiento. Para la práctica se utilizará el estándar de codificación [JAVACON]. Los ejemplos de la asignatura siguen estas sencillas convenciones de nombrado. Para no alargar la práctica, no se realizará documentación JavaDoc de las clases. 5.3 Formato de entrega de la versión final La distribución fuente la aplicación se entregará con el propio sistema de control de versiones (Subversion) que se utilizará para el desarrollo de la práctica. Cuando se aproxime la fecha tope de cada entrega, se darán instrucciones detalladas. A continuación se detalla el formato de la memoria. Como norma general, los diagramas emplearán la notación UML. Los diagramas deben ser de calidad (y no hechos por reingeniería inversa; el diseño precede a la implementación!) y ESTAR EXPLICADOS de manera breve, pero clara. Es importante destacar que no se pretende que se haga un documento grande, sino un documento que explique breve, pero claramente, cada uno de los apartados que a continuación se describen. La calidad de la memoria será vital para la corrección de la práctica. 1. Arquitectura global Comenta la estructura global de paquetes de la aplicación (no es necesario emplear la notación UML para este aspecto particular). No se deben mostrar todos los paquetes, sino sólo los paquetes de más alto nivel que reflejen la arquitectura de la aplicación y sus principales subpaquetes. Por cada paquete se explicará brevemente qué contiene. 2. Modelo 2.1 Clases persistentes 6

7 Muestra todas las clases persistentes en uno o varios diagramas de clases y las relaciones relevantes entre ellas. 2.2 Interfaces de los servicios ofrecidos por el modelo Explica el criterio que se ha seguido para agrupar los casos de uso en servicios (fachadas). Incluye un diagrama de clases para cada servicio, que muestra la interfaz del servicio (con la declaración completa de sus operaciones) y los tipos de datos que utilizan las operaciones. 2.3 Diseño de un DAO Se incluirá un diagrama de clases que ilustre la implementación de uno de los DAOs de la aplicación. No es necesario mostrar el diseño del resto de DAOs, dado que su arquitectura es similar. 2.4 Diseño de un servicio del modelo Se incluirá un diagrama de clases que ilustre la implementación de un servicio del modelo, mostrando las dependencias de los DAOs que utilice. También se incluirá un diagrama de secuencia que muestre la ejecución de un caso de uso en la capa modelo. No es necesario mostrar el diseño del resto de servicios, dado que su arquitectura es similar. 2.5 Otros aspectos Se documentarán aspectos particulares que se consideren relevantes para la correcta comprensión de la capa modelo. 3. Interfaz gráfica Se mostrará un diagrama de secuencia que ilustre el procesamiento de un caso de uso representativo. El diagrama mostrará las principales clases o artefactos que intervienen en la ejecución del caso de uso. En lo que respecta al modelo, no es necesario detallar el procesamiento de la petición en el interior del servicio (dado que ya se hizo en el apartado 2.4). También se documentarán aspectos particulares que se consideren relevantes para la correcta comprensión de la interfaz gráfica. 4. Servicios XML Se explicará brevemente el formato de las URLs de los servicios XML, el formato de sus respuestas y los detalles de implementación relevantes. 5. Un apartado para las partes adicionales 7

8 Se explicará claramente cómo se ha realizado cada parte adicional. 6. Compilación e instalación de la aplicación Se explicará claramente cómo compilar e instalar la aplicación, asumiendo un entorno correctamente configurado (e.g. base de datos instalada, servidor de aplicaciones instalado y configurado, etc.), y que en consecuencia, no es preciso documentar. La instrucciones de instalación deberían ser lo más sencillas posibles. 7. Problemas conocidos Comenta los errores que se conoce que tiene el código. 5.4 Iteraciones y entregas Para la realización de la aplicación se seguirá un enfoque basado en iteraciones, de manera que cada iteración incorpora más funcionalidad sobre la anterior, hasta que en la última iteración se termina con un software que implementa toda la funcionalidad. En particular, el desarrollo de la aplicación se hará en dos iteraciones: Primera iteración. Se implementará la capa modelo y las pruebas de integración especificadas en el apartado 2.3. Además, si se desea hacer la parte adicional especificada en el apartado 3, se deberá hacer en esta iteración. Plazo de entrega: durante las clases de prácticas de Diciembre 2009 (se publicará día y hora para cada grupo). Segunda iteración. Se implementará la interfaz Web, los servicios XML, y si es necesario, se actualizarán las pruebas de integración de la capa modelo. Además se redactará la memoria. Finalmente, si se desea, se hará la parte adicional especificada en el apartado 4. Plazo de entrega: durante las clases de prácticas de Marzo 2010 (se publicará día y hora para cada grupo). A efectos de planificación debe tenerse en cuenta que cada iteración debe estar lista para el primer día posible de su plazo de entrega. La entrega de cada iteración es obligatoria y deben estar presentes todos los miembros del grupo. En la entrega se realizará una demo y se harán preguntas individualizadas sobre el diseño y la implementación. La corrección de la primera iteración no llevará una nota asociada ni será necesario entregar una memoria. Bastará con mostrar los diagramas correspondientes al apartado 2 de la memoria electrónicamente (mediante una herramienta UML o visualizando imágenes) o de manera impresa. El objetivo de la corrección de esta primera iteración es intentar detectar errores importantes, y en ese caso, orientar al alumno hacia su resolución. En la corrección de la segunda iteración se pondrá una nota y se deberá entregar la memoria impresa. Para la realización de la práctica puede reusarse todo el código (en formato binario o fuente) que se desee de los ejemplos distribuidos en la asignatura, y de hecho, se recomienda hacerlo, dado que facilitará notablemente el comienzo de la práctica. También 8

9 es importante resaltar que el código utilizado debe comprenderse (se ha explicado en clase), y no usarlo ciegamente. 5.5 Evaluación La nota de la práctica se calculará como sigue: IS-Ingeniería: o Parte básica. Puntuación: 3,75 puntos. o Parte adicional pruebas exhaustivas (opcional). Puntuación: 0,25 puntos. o Parte adicional AJAX (opcional). Puntuación: 1 punto. IS-Máster: o Parte básica. Puntuación: 4,5 puntos. o Parte adicional pruebas exhaustivas (opcional). Puntuación: 0,5 puntos. IIS-Máster: o Parte adicional AJAX. Puntuación: 5 puntos. En todos los casos, para la puntuación de cada parte se tendrá en cuenta: Su correcto funcionamiento. La calidad del diseño. La calidad del código. La calidad de la memoria. Una práctica copiada significará un suspenso para el grupo que ha dejado copiar y el que ha copiado; a todos los efectos, no se hará ninguna distinción. Los suspensos por práctica copiada tendrán que realizar una práctica distinta, que además deberán proponer (y ser aceptada). 6 Referencias [AJAX] Ajax: A New Approach to Web Applications, [JAVACON] Sun Microsystems, Java Code Conventions, 9

10 [TAPESTRY-AJAX] Tapestry AJAX Support, [WEB2.0] What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software, 10