Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico

Transcripción

1 Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico 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 una tienda de comercio electrónico. 2 Funcionalidad básica Este apartado especifica la funcionalidad básica de la tienda de comercio electrónico. 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 La tienda de comercio electrónico permitirá que los usuarios puedan comprar productos. La información de cada producto incluirá: nombre, precio, fecha de alta, número de unidades en stock y categoría a la que pertenece. Cada producto pertenece a una categoría ( Libros, Música, Películas, etc.). En general, en las tiendas electrónicas la jerarquía de categorías es un árbol. Por ejemplo, la categoría Libros podría tener las subcategorías: Arte, Literatura, Historia, Viajes, Informática, etc., y éstas a su vez, otras subcategorías. Sin embargo, para simplificar, el sistema de categorías será plano, es decir, las categorías no tendrán subcategorías. Un usuario se registra en la tienda de comercio electrónico especificando, por una parte, cierta información básica de registro, a saber, su seudónimo (login), contraseña, nombre, apellidos y dirección de correo electrónico. Como parte del registro, la tienda de comercio electrónico también le pide al usuario los datos de su dirección postal. La información de la dirección postal incluye: nombre completo, calle, número, puerta y código postal (sólo se permiten compras nacionales). Cada usuario puede buscar productos y añadirlos a su carrito de la compra. Una vez en el carrito, puede eliminarlos o modificar el número de unidades que desea adquirir. El carrito de la compra será persistente, es decir, si un usuario abandona la sesión sin comprar 1

2 los productos que añadió al carrito, la siguiente vez que entre en la tienda, el carrito todavía contendrá esos productos. Cuando el usuario decide comprar los productos de su carrito, se generará un pedido, que se compondrá de varias líneas de pedido. Un usuario puede tener varios pedidos en marcha. Por cada pedido se guardará la fecha en la que se hizo y la dirección postal a la que se desea enviar. Por cada línea de pedido se guardará el número de unidades pedidas del producto y el precio unitario. 2.2 Interacción con el usuario A continuación se detalla la funcionalidad que deberá ofrecer la tienda al usuario: 1. Registro de usuarios. Debe permitir registrar nuevos usuarios, así como permitir cambiar la información básica de registro y la dirección postal. 2. 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 introducirla la siguiente vez. El usuario podrá salir explícitamente de la tienda, lo que provoca que ya no se recuerde su contraseña, en caso de haber seleccionado dicha opción con anterioridad. 3. Búsqueda de productos. Cualquier usuario podrá buscar productos por palabras clave del nombre, especificando opcionalmente la categoría (mediante un desplegable). Así, por ejemplo, si la tienda vende un libro con título (nombre) The Java Programming Language, deberá aparecer cuando se busca The Java Programming Language, Java Programming, Programming JAVA Language, Program JAVA Lang, etc., es decir, las palabras clave tienen que estar todas contenidas en el nombre del título 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 productos de dicha categoría. Los productos que aparecen como resultado de una búsqueda se visualizan mostrando su nombre, categoría, precio y un enlace para añadirlo al carrito (para añadir un producto al carrito es preciso estar autenticado). El nombre estará asociado a un enlace que permitirá visualizar toda la información de ese producto. 4. Gestión del carrito de la compra. Un usuario autenticado puede visualizar su carrito, eliminar productos del carrito, modificar el número de unidades que desea adquirir de un producto, añadir otros productos (mediante los enlaces especificados anteriormente) o comprar todos los productos que hay en el carrito. La visualización del carrito incluye por cada producto: su nombre (con un enlace para ver sus detalles), el precio unitario y el número de unidades, así como el precio total. Cuando el usuario realiza la compra, la tienda le mostrará por defecto la dirección postal que especificó en el registro. Sin embargo, si el usuario lo desea, podrá especificar que ese pedido se le envíe a otra dirección 2

3 postal. Una vez realizada la compra, el carrito se vacía. El pedido se paga contra reembolso, es decir, cuando se le entrega la mercancía al usuario. 5. Visualización de pedidos. Un usuario autenticado podrá visualizar todos los pedidos que ha hecho. Por cada pedido se mostrará la fecha, con un enlace para poder visualizar los detalles del pedido. Para no alargar innecesariamente la práctica, no se implementará una aplicación de administración. En una situación real, esta aplicación permitiría actualizar el catálogo de productos y gestionar los pedidos. Dado que no se implementará la aplicación de administración, la información sobre el catálogo de productos se introducirá mediante sentencias INSERT INTOs, que se incluirán como parte del script de creación de tablas. 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], la tienda de comercio electrónico 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 (la tienda), como las aplicaciones cliente de los servicios (la aplicación Web.NET), puedan obtener un beneficio económico. En particular, la tienda ofrecerá dos servicios: 1. Búsqueda de productos por palabras clave del nombre, especificando opcionalmente la categoría. Devuelve información sobre los productos que contienen esas palabras clave en el nombre (en cualquier orden, y sin distinguir entre mayúsculas y minúsculas). Si se especifica una categoría, la búsqueda se restringirá a los productos de dicha categoría. La información de cada producto incluye: identificador de producto (el usado en base de datos), nombre, categoría y precio. 3

4 2. Información detallada de un producto. Permite obtener toda la información de un producto a partir de su identificador. 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 ninguna 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 productos y categorías). Tampoco se 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 productos por palabras clave se implementará un conjunto exhaustivo de casos de prueba (e.g. no existe ningún libro que concuerda 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. Entre otras cosas, la página que muestra el carrito incluye por cada producto: un enlace para eliminarlo y un formulario para actualizar el número de unidades que el usuario desea adquirir. Tras seleccionar el enlace de eliminación o el botón de actualización, se deberá mostrar otra vez la información actualizada del carrito. Con una implementación básica, será preciso volver a generar completamente la página HTML que muestra la información del carrito. En esta parte adicional, será preciso regenerar sólo la parte afectada de la página, es decir, la que contiene la información del carrito. 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 selecciona el enlace de eliminación o el botón de actualización, 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 4

5 respuesta, accederá a los datos y modificará el árbol DOM de la página para actualizar la información del carrito o un mensaje de error explicativo. Este tipo de interacciones se denominan interacciones AJAX [AJAX] ( Asynchronous JavaScript + XML ), y también constituyen una característica de la Web 2.0. A diferencia de las interacciones normales, las respuestas HTTP no contienen el XHTML de toda la página, sino sólo los datos que hay que actualizar en la página actual. Los datos no necesariamente tienen que devolverse en XML como sugiere el acrónimo AJAX. Además, las peticiones son asíncronas. Aunque en esta práctica no tiene sentido explotar esta posibilidad, otras aplicaciones utilizan esta característica para permitir que el usuario continúe interactuando con la página mientras no llega la respuesta. En cualquier caso, el uso de interacciones AJAX en una aplicación Web permiten dotar a ésta de un grado de interactividad similar al de las aplicaciones de escritorio. 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. 5

6 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 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). 6

7 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 dos servicios XML y cómo se han implementado. 5. Un apartado para las partes adicionales 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 Lista 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 2008 (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 2009 (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 7

8 nota asociada ni será necesario entregar una memoria. Bastará con mostrar los diagramas correspondientes al apartado 2 de la memoria mediante la herramienta MagicDraw instalada en el laboratorio. 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 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). 8

9 6 Referencias [AJAX] Ajax: A New Approach to Web Applications, [JAVACON] Sun Microsystems, Java Code Conventions, [TAPESTRY-AJAX] Tapestry AJAX Support, [WEB2.0] What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software, 9