Práctica Java POJO de Integración de Sistemas

Sitio Web de Apuestas Deportivas

Curso académico 2009-2010

1 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
 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
 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
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
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
[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
 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
 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
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,
http://www.adaptivepath.com/ideas/essays/archives/000385.php.

[JAVACON] Sun Microsystems, Java Code Conventions,

http://java.sun.com/docs/codeconv/index.html.

9
[TAPESTRY-AJAX] Tapestry AJAX Support,
http://tapestry.apache.org/tapestry5/guide/ajax.html.

[WEB2.0] “What Is Web 2.0: Design Patterns and Business Models for the Next
Generation of Software”,
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html.

10