scieee AI-readable full text Open interactive document viewer

Portal de subastas electrónicas

Pérez Rubio, Sergio

Abstract

Las expectativas del proyecto son las de conseguir crear un sitio Web estable para que garantice que múltiples usuarios que accedan desde cualquier lugar o cualquier navegador a Internet, puedan hacerlo de manera simultánea a los servicios que hemos creado sin largos tiempos de espera ni situaciones indebidas de conflicto.

Full text

PORTAL DE SUBASTAS ELECTRÓNICAS 2 Índice 1 Introducción................................................................................................................... 5 1.1 Objetivos/Motivación............................................................................................. 5 1.2 Resumen ................................................................................................................. 6 1.3 Contexto.................................................................................................................. 7 1.4 Estructura................................................................................................................ 7 2 Especificación de requisitos .......................................................................................... 9 2.1. Introducción........................................................................................................... 9 2.1.2 Ámbito del sistema.......................................................................................... 9 2.1.3 Definiciones, acrónimos y abreviaturas .......................................................... 9 2.1.4 Referencias .................................................................................................... 10 2.1.5 Visión genera del apartado ............................................................................ 10 2.2 Descripción general.............................................................................................. 16 2.2.1 Perspectiva del producto................................................................................ 16 2.2.2 Funciones del producto.................................................................................. 16 2.2.3 Características de los usuarios....................................................................... 18 2.2.4 Restricciones.................................................................................................. 18 2.2.5 Suposiciones y dependencias ........................................................................ 20 2.2.6 Requisitos futuros.......................................................................................... 20 2.3 Requisitos específicos........................................................................................... 20 2.3.1 Interfaces externas......................................................................................... 21 2.3.2 Requisitos funcionales................................................................................... 28 2.3.3 Requisitos de rendimiento............................................................................. 30 2.3.4 Restricciones de diseño ................................................................................. 30 2.3.5 Atributos del sistema..................................................................................... 31 2.3.6 Otros requisitos.............................................................................................. 31 3 3 Elección de servidor y lenguaje................................................................................... 33 3.1 Elección del servidor ............................................................................................ 33 3.2 Elección de un lenguaje de programación............................................................ 35 4 Análisis y diseño.......................................................................................................... 39 4.1 Casos de Uso ........................................................................................................ 39 4.2 Estructura.............................................................................................................. 40 4.3 Modelos ................................................................................................................ 44 5 Implementación ........................................................................................................... 59 5.1 Tecnologías........................................................................................................... 59 5.2 Herramientas......................................................................................................... 60 5.3 Implementación propia de la aplicación............................................................... 60 6 Evaluación ................................................................................................................... 75 7 Referencias .................................................................................................................. 85 8 Conclusiones................................................................................................................ 87 8.1 Mejoras y ampliaciones........................................................................................ 87 8.2 Valoración personal.............................................................................................. 88 ANEXO 1 Manual De Usuario....................................................................................... 91 Parte del instalador del sistema .................................................................................. 91 Instalación del servidor........................................................................................... 91 Distribución de archivos......................................................................................... 92 Crear base de datos................................................................................................. 96 Configuración del servidor de correo..................................................................... 96 Parte del usuario ......................................................................................................... 98 Usuario Anónimo ................................................................................................... 98 Usuario Administrador......................................................................................... 108 Usuario Registrado............................................................................................... 113 4 5 1 Introducción El proyecto planteado se corresponde con el código PFC DSIC-25 de la Universidad Politécnica de Valencia y cuyo título se corresponde con Portal de Subastas Electrónicas. A continuación se comentarán brevemente los objetivos, el contexto y la estructura del proyecto realizado, así como una idea intuitiva de nuestra pretensión en el proyecto desarrollado. 1.1 Objetivos/Motivación El problema planteado consiste en el desarrollo de un portal Web de subastas que podrá ser accedido directamente desde cualquier ordenador conectado a Internet. Nuestra decisión ha sido hacer un portal de subastas intuitivo y sencillo de manejar para facilitar a todo tipo de usuarios el uso del mismo. La aplicación se puede considerar desde distinta perspectiva según el tipo de usuario que se encuentre utilizándola. Los tipos de usuarios que tendrán acceso a la aplicación siempre estarán identificados dentro de una de las categorías disponibles, que en este caso serán anónimos, registrados y administradores. Por una parte, el usuario anónimo no tiene la necesidad de registrarse para acceder, esto conlleva a que sus funciones sean estrictamente limitadas: • Tendrá la posibilidad de ver las ofertas disponibles en la Web filtradas por categoría, provincia y ordenadas por fecha de publicación. • Capacidad de registrarse para obtener mayores privilegios. • Acceso al buscador para encontrar ofertas que le resulten interesantes. • Podrá ver todos los detalles de las ofertas así como los comentarios pero no podrá comentar. Por otra parte, el usuario administrador deberá identificarse como tal ante el sistema para poder acceder a su interfaz predefinida y dispondrá de los siguientes privilegios: • Podrá ver una lista de todos los usuarios baneados actualmente y liberar de su baneo a aquellos que considere ya han cumplido su castigo. • Tendrá la potestad de evaluar las denuncias de descategorización de los artículos hechas por los usuarios decidiendo si cambia o no la categoría actual de ese artículo. 6 • Poseerá el poder para banear a los usuarios que se sospeche están llevando a cabo ventas fraudulentas o sospechosas prohibiéndoles la entrada al sistema. • Dispondrá de la capacidad de crear nuevos administradores, de forma que estos puedan aportar cierta calidad y agilidad al servicio de quejas. Por último, el usuario registrado deberá, al igual que administrador identificarse como tal ante el sistema y se le concederán una serie de privilegios distintos a los del administrador y el registrado: • Tendrá la capacidad de ejecutar todas las acciones que puede hacer el usuario anónimo salvo la de registrarse (ya que no tendría sentida al tener en uso una cuenta). • Además de esto, tendrá la capacidad de pujar por cada uno de los artículos que se encuentren en subasta actualmente, así como publicar comentarios en cada una de las ofertas valorando a su propio juicio personal la calidad del artículo. • Podrá denunciar un artículo a nivel de una mala categorización o a nivel de fraude, si hay información contrastada de que la subasta es fraudulenta, aportando dicha información. • Dispondrá de un espacio personal en el que podrá ver, añadir, editar o eliminar sus subastas e intereses. • Tendrá una interfaz en la que podrá ver y cancelar sus pujas realizadas sobre los artículos cuya fecha de fin de subasta aun no ha vencido. • Dispondrá de una sección de alarmas de manera en que recibirá un email en caso de que alguna oferta que coincida con unas características concretas definidas por él mismo sea publicada en el portal. • Tendrá la opción de cambiar su contraseña siempre que así lo desee. 1.2 Resumen Las expectativas del proyecto son las de conseguir crear un sitio Web estable para que garantice que múltiples usuarios que accedan desde cualquier lugar o cualquier navegador a Internet, puedan hacerlo de manera simultánea a los servicios que hemos creado sin largos tiempos de espera ni situaciones indebidas de conflicto. 7 1.3 Contexto El proyecto realizado posee características que coinciden con cualquier proyecto Web, ya que deberá ser accesible desde cualquier navegador y realizar un correcto funcionamiento independientemente del navegador elegido. La resolución debe ser adaptable a la configuración del usuario y deben evitarse a toda costa conflictos con la información almacenada o fugas de datos importantes como los datos bancarios que pueda introducir el usuario o los datos de acceso a su cuenta. Al ser un proyecto individual, el tiempo de desarrollo ha sido muy holgado de forma que entre el desarrollo de unas etapas y otras del proyecto el lapso de tiempo era bastante grande y ha llevado a algunas inestabilidades que veremos mas adelante. 1.4 Estructura La memoria realizada consta de una serie de bloques que engloban todo el trabajo realizado y que son descritos brevemente a continuación. En primer lugar, la especificación de requisitos, que consiste en describir las necesidades del proyecto a desarrollar, para ello hemos hecho uso del estándar IEEE 830-1998, que nos ha permitido desarrollar un documento de manera formal que reúne las características de la aplicación. En segundo lugar, análisis y diseño, que permite hacer uso de nomenclaturas estandarizadas para guiar al desarrollador en la consecución del objetivo sin forzarlo a utilizar ninguna tecnología específica de implementación. En tercer lugar, implementación, se encarga de realizar la aplicación funcional mediante la utilización de tecnologías, herramientas y componentes concretos empleados en el desarrollo. En cuarto lugar, evaluación, alberga las pruebas llevadas a cabo para determinar el buen funcionamiento del producto desarrollado así como los resultados obtenidos. 8 En quinto lugar, arquitectura del arte, en la cual veremos alguna forma o tecnología alternativa que sirviera para implementar nuestro sistema (si es que la hay) y la comparamos sobre el papel con la forma en la que nosotros la hemos implementado. En sexto lugar, conclusiones, en las cuales se compara lo planteado en la especificación con lo obtenido, así como se plantea la posibilidad de futuras extensiones y/o ampliaciones sobre este producto. En séptimo lugar, referencias, se detallan las distintas fuentes de información en las cuales no hemos apoyado para el desarrollo del proyecto. Por último, apéndices, en los cuales se incluyen manuales de usuario dentro de los que se encontrará la parte de instalación del sistema y también su parte de utilización. 9 2 Especificación de requisitos 2.1. Introducción 2.1.1 Propósito Este apartado del documento tiene como objetivo realizar una visión global pero precisa sobre la aplicación desarrollada como PFC y cada una de sus partes, cuyo desarrollador ha sido Sergio Pérez Rubio. 2.1.2 Ámbito del sistema El sistema recibirá el nombre de SUBASTLAND. Nuestra aplicación permitirá a usuarios remostos provistos de acceso a Internet realizar todo tipo de ventas y compras de productos, así como proporcionar a los usuarios facilidad para encontrar lo que buscan a un buen precio. Se pretende obtener un producto que, a parte de proporcionar una buena calificación al desarrollador, sea de utilidad a los visitantes y les incite a participar activamente en la aplicación de manera que se obtenga una gran afluencia de conexiones al portal. Con ello se podrían conseguir beneficios económicos a través de la publicidad online de distintos anunciantes que estuvieran interesados. 2.1.3 Definiciones, acrónimos y abreviaturas PFC: Proyecto Final de Carrera ETSINF: Escuela Técnica Superior de Informática. UPV: Universidad Politécnica de Valencia. DFD: Diagrama de Flujo de Datos UML: Unified Modeling Language. SGBD: Sistema Gestor de Bases de Datos. HTML: HyperText Markup Language. 16 2.2 Descripción general 2.2.1 Perspectiva del producto Nuestra aplicación permitirá a usuarios de la Web conectarse desde cualquier punto en el que tenga Internet y acceder a todas las posibilidades de nuestro portal. Nuestro producto será completamente libre de ningún tipo de atadura a dispositivos externos, de manera que con la simple disposición de un navegador (disponible en cualquier ordenador) podremos acceder a todo su contenido. La única restricción por lo tanto para utilizar nuestro sistema será disponer de un ordenador con acceso a Internet. 2.2.2 Funciones del producto La aplicación proporcionará una interfaz Web mediante la cual nos ofrecerá las siguientes funcionalidades: • Obtener un listado con las últimas subastas añadidas al portal. • Obtener un listado filtrado por categoría de todas las subastas de cierta categoría. 17 • Obtener un listado filtrado por provincia de todas las subastas de cierta provincia. • Realizar una búsqueda sobre todas las ofertas con un criterio que el usuario definirá. • Consultar los detalles de cada subasta, así como los comentarios hechos sobre ella. • Registrarse en el sistema definiendo un nombre de usuario (nick) y una contraseña. • Establecer un perfil que se almacenará en el sistema de manera que se guardarán datos como la provincia, el email, el nick o el teléfono de un usuario y se cargará cada vez que un registrado inicie sesión. • Iniciar sesión como usuario registrado. o Añadir subastas de artículos para que se añadan al portal o editar subastas ya existentes para modificar sus parámetros. Cualquier tipo de venta podrá ser eliminada siempre que no se haya vencido su fecha de fin. o Notificar su interés por alguna clase de artículo publicando una oferta de interés sobre cierto ámbito para que cualquier usuario pueda contactar con él. Esta oferta podrá ser editada en cualquier momento. o Crear alarmas que notificarán por correo electrónico al usuario cuando se publique una venta que case con las condiciones establecidas en dicha alarma. Esta alarma podrá ser modificada o eliminada por el usuario en cualquier momento. o Mostrar su interés por cualquier producto realizando una puja sobre él. Una puja realizada podrá ser cancelada siempre y cuando no haya vencido la fecha de fin de la oferta en la que se pujó. o Denunciar la mala clasificación o el posible fraude de un producto a los administradores. o Cambiar su contraseña • Iniciar sesión como usuario administrador. o Obtener un listado de denuncias por desclasificación. o Obtener un listado de denuncias por fraude. o Dar de alta un nuevo administrador en el sistema. o Banear usuarios por fraude. o Liberar el baneo de usuarios baneados. 18 o Categorizar los artículos desclasificados. 2.2.3 Características de los usuarios El conjunto de usuarios de nuestro sistema estará contenido en el de usuarios de Internet. Dado que no hay edad para el acceso a Internet, nuestro sistema deberá estar adaptado a todos los públicos, pero dispondremos de la restricción de un mínimo de 18 años para poder disponer libremente de datos bancarios necesarios en sus subastas o ventas. En caso de ser menor de 18 años el usuario deberá disponer del consentimiento del tutor y utilizar el sistema siempre con su autorización y representándole. 2.2.4 Restricciones a) Políticas de la empresa: La ETSINF nos exige, por medio del director José Ángel Carsí, el desarrollo de este proyecto siguiendo ciertos protocolos estándar como por ejemplo el que utilizamos especificando los requisitos en un documento como éste (IEEE 830-1998). También utilizamos el estándar UML para el modelado en la etapa de análisis y diseño. Además de los estándares, se nos exige también que el sistema esté dispuesto en una arquitectura de tres capas (presentación, lógica de negocio y persistencia). b) Limitaciones hardware: La aplicación será implementada en el ordenador del alumno, de manera que dispondremos de la configuración del servidor local instalado por éste. En este caso será el programa XAMPP que dispone de ciertos recursos que cubren las necesidades de desarrollo. Posteriormente el portal será migrado a un servidor en línea que dispondrá de unos recursos iguales o superiores al local. c) Interfaces con otras aplicaciones: Nuestro producto deberá ser adaptado para el uso en cualquier tipo de navegador comercial. El mencionado programa XAMPP será el que soporte la aplicación, ya que incluye un servidor Apache y soporte para MySQL y PHP. d) Operaciones paralelas: Al mismo tiempo que este proyecto, el equipo de desarrollo lleva a cabo otro tipo de estudios como es la asistencia a una escuela de ingles y un trabajo a media jornada en una empresa en la que imparte docencia básica de informática. 19 e) Funciones de control: En todo momento, estamos supervisados por el director del PFC, José Ángel Carsí, quien realiza también funciones de instructor corrigiendo las incongruencias del sistema y resaltando los errores que se escapan de la vista del desarrollador. f) Lenguajes de programación: Se utilizarán los lenguajes HTML, CSS y JavaScript para la presentación y PHP para la capa de negocio y también realizará conexión con la capa de persistencia y parte de la aplicación. Finalmente, en el SGBD habrá que utilizar MySQL, disponible en el XAMPP mediante el gestor phpMyAdmin. g) Protocolos de comunicación: El objetivo es desarrollar una aplicación que se apoya en el protocolo de la capa superior de Internet HTTP. Como el nuestro es un proyecto en entorno Web, evidentemente se utilizarán en el funcionamiento de éste todo el paquete de protocolos de Internet. Sin embargo, al ser una arquitectura cerrada, no nos afecta para nada el funcionamiento del resto de las capas. h) Requisitos de fiabilidad: La política a seguir, será la de ofrecer la máxima fiabilidad en todas las funcionalidades que se desarrollen, sacrificando para ello si fuese necesario por razones de tiempo o recursos, algunas funcionalidades menos importantes. i) Criticidad de la aplicación: Nuestro sistema no es crítico en cierta parte, ya que no se pone en peligro en ningún momento la identidad de los usuarios. Pero si empleará el manejo de información crítica en los momentos de pago, ya que el usuario deberá indicar su número de cuenta y acreditar la propiedad de esa cuenta. Nuestra base de datos no almacenará datos de carácter personal (salvo el correo y el teléfono opcionalmente) ya que los datos bancarios que se introduzcan serán cotejados en el acto y no almacenados en nuestro servidor. j) Consideraciones de seguridad: Se requiere que la identidad del usuario se valide mediante una contraseña, sin embargo esta no viajará encriptada por la red, sino que será enviada en formato HTML. Se desarrollará una funcionalidad de administración vía Internet, para evitar accesos indebidos a usuarios no registrados. De esta forma, un usuario no registrado tendrá un acceso restringido al contenido aunque copie la URL de un usuario registrado, ya que esto se manejará mediante las sesiones abiertas en el navegador. 20 2.2.5 Suposiciones y dependencias Los factores que con más probabilidad podrían influir en caso de cambio sobre los requisitos del sistema serían: • El sistema operativo Windows, que utiliza el servidor donde está soportada la aplicación. • La futura aparición de nuevos gestores online de pagos, que nos obligaría a establecer conexiones con más formas de pago. • La configuración de correo del servidor, que debería estar vinculada a la cuenta de correo del portal para realizar correctamente el envío de emails a los usuarios informándoles de toda novedad. 2.2.6 Requisitos futuros El día de mañana, se podría requerir que las contraseñas viajasen encriptadas para aumentar la seguridad del sistema. Por ejemplo, se podría utilizar para ello el protocolo HTTPS. Otro requisito que se podría pedir, es el establecer una serie banners de publicidad en la página, por los cuales los anunciantes pagarían para establecer en ellos su publicidad. Podría añadirse una nueva función a los administradores que les permita gestionar los periodos y zonas publicitarias del portal. Otro nuevo requisito de lucro económico, sería la disposición de preferencia de anuncio, donde los usuarios registrados abonarían cierta cantidad económica para que sus anuncios fueran patrocinados por el portal y aparecieran como primeros resultados a ciertas búsquedas. 2.3 Requisitos específicos Comenzaremos este apartado comentando los requisitos no funcionales generales a cumplir. Estos deberán ser enmarcados en los siguientes aspectos: 21 - Escalabilidad o El sistema utilizará la manera óptima recursos como las conexiones a la base de datos. o En el diseño habrá una clara separación de las capas de datos, lógica de negocio e interfaz, de manera que se proporcione una escalabilidad óptima del sistema. - Disponibilidad o El sistema deberá estar disponible y accesible a los usuarios en cualquier momento, de manera que ante cualquier tipo de error o inaccesibilidad el usuario sea notificado inmediatamente de manera correcta. o En caso de fallo en alguna de las partes, debe haber una medida que evite la perdida de información. - Seguridad o El sistema debe reflejar un nivel medio de seguridad en cuanto al acceso a los datos de un usuario tales como sus artículos en venta o sus ofertas de compra. Ningún usuario debe poder acceder a estos datos de cualquier otro usuario sin su consentimiento. También reflejaremos un alto nivel de seguridad sobre los datos de transacciones bancarias que se realicen para el pago de artículos en venta, solicitándolos para cada una de las compras de usuario y no guardando ninguna información de ellos en el perfil del usuario para evitar el filtrado de esta información tan delicada. - Mantenibilidad o El código será estructurado de manera consistente y fácil de leer, para poder tener un mayor seguimiento de cualquier error que aparezca. o El sistema será construido de forma que un cambio en los requisitos del mismo no suponga una reconstrucción completa de alguna de sus partes. 2.3.1 Interfaces externas En todas las interfaces, la zona superior de la pantalla estará reservada para la inclusión del logotipo de la página y el buscador. De la misma forma, mientras el usuario no este logueado, aparecerá en el menú izquierdo de navegación un campo de email y otro de password para que el usuario se identifique ante el sistema. En caso de estar un usuario logueado este será sustituido por un mensaje de bienvenida y un botón de cierre de sesión. 22 Interfaz principal Información contenida: En esta interfaz se mostrarán los 10 últimos productos puestos en venta por cualquier usuario. En esta página también aparecerá el buscador en la parte superior y un menú lateral con distintas opciones. Funcionalidad contenida: El usuario podrá entrar en cualquiera de estos productos para ver en que consiste la oferta. El menú lateral contendrá una lista con las categorías de los productos, de manera que al hacer clic en alguna de las categorías navegaremos a una página que contenga una lista de productos de dicha categoría. La otra opción del menú lateral corresponderá a la provincia en la que se hará la oferta. Seleccionando una provincia podremos encontrar ofertas de dicha ubicación geográfica. Por último, el buscador nos permitirá encontrar de manera mas ágil productos deseados, ya que podremos personalizar los productos enseñados indicando en la búsqueda el producto a encontrar. Interfaz de registro Este será el único medio a través del cual un usuario podrá registrarse en el sistema y que sus datos sean recordados por el mismo. Información contenida: Se ofrecerán los medios para introducir todos los datos necesarios para registrarse en el sistema, email, contraseña (se pedirá dos veces para confirmar), nombre de usuario, provincia a la que pertenece y un teléfono. Funcionalidad contenida: Lo único que podrá hacer el usuario es enviar los datos para que se almacenen en el servidor y poder identificarse con ellos desde ese momento. Interfaz del artículo anónimo Esta interfaz aparecerá cada vez que el usuario haga clic en cualquier artículo. Información contenida: En esta interfaz se mostrará la fecha de publicación de la oferta, la provincia en la cual se realizó esa oferta, la categoría a la que pertenece el artículo ofertado, el precio establecido como predeterminado, el tipo de oferta (subasta abierta, cerrada o compra 23 a precio exacto), una descripción del artículo y un espacio reservado para comentarios o preguntas en el que el usuario anónimo no podrá participar. Además de estos datos, la oferta contendrá fotos que identifiquen el artículo en venta y también se mostrará en la oferta el nombre de usuario, un teléfono y un email para contactar con el ofertante. Además, igual que en la interfaz principal, aparecerá el menú lateral para ver artículos por categorías o provincias y el buscador de artículos. Funcionalidad contenida: El usuario podrá ver la información y observar las distintas fotografías que contenga el artículo. Interfaz del artículo registrado Esta interfaz aparecerá cada vez que el usuario haga clic en cualquier artículo. Información contenida: En esta interfaz se mostrará la fecha de publicación de la oferta, la provincia en la cual se realizó esa oferta, la categoría a la que pertenece el artículo ofertado, el precio establecido como predeterminado, el tipo de oferta subasta abierta, cerrada o compra a precio exacto), una descripción del artículo y un espacio reservado para comentarios y valoraciones, en los que podrá participar activamente. Además de estos datos, el usuario verá las fotografías introducidas en la oferta y junto con el nombre de usuario del vendedor, se mostrará en la oferta un teléfono y un email de contacto. El usuario registrado, además de ver todo esto podrá pujar libremente o comprar el artículo en caso de ser una venta a precio fijo. Si el usuario considera que el producto esta mal clasificado o es un fraude puede escribir una queja formal a los administradores para recategorizar al el producto o banear al vendedor en caso de ser un producto fraudulento. Además, igual que en la interfaz principal, aparecerá el menú lateral para ver artículos por categorías o provincias y el buscador de artículos. Funcionalidad contenida: El usuario tendrá la libertad de comentar sobre el artículo y publicar su comentario. En función del tipo de venta que sea aparecerá una forma u otra de introducir el interés del usuario por la oferta. En caso de que la oferta sea una subasta, el usuario registrado podrá introducir una cantidad por el artículo y pujar. En caso de ser una venta a precio fijo, el usuario podrá presionar un botón denominado comprar ya. En añadido de todo esto, el usuario registrado podrá denunciar un anuncio, por diversas razones desde una opción de denuncia que aparecerá en al parte inferior de la pantalla. 24 Interfaz perfil registrado Información contenida: En esta interfaz, al igual que en la interfaz principal, aparecerá el menú lateral para ver artículos por categorías o provincias y el buscador de artículos. Como información propia de esta interfaz aparecerá una lista que permitirá al usuario navegar entre distintas opciones. Estas opciones serán ventas (artículos que actualmente tiene el usuario en subasta), intereses (artículos que el usuario busca), alertas (una forma de que el sistema comunique al usuario que se ha añadido una oferta de su interés), cambiar contraseña y pujas (artículos por los que el usuario ha pujado actualmente). Además de estos enlaces, el usuario verá la información de su nick, su teléfono y su provincia. Funcionalidad contenida: El usuario viajará a cada una de las interfaces correspondientes al hacer clic en cada una de las opciones descritas. Dichas interfaces se explicarán a continuación. Interfaz perfil subastas Información contenida: Esta interfaz contendrá la información de todos los artículos que el usuario tenga actualmente en venta. Al lado de cada uno de estos artículos aparecerán dos opciones: una primera que dirá editar y una segunda que dirá cancelar. Bajo estas opciones el usuario dispondrá de un botón para añadir una nueva oferta. Al igual que en las interfaces anteriores tendremos el menú lateral y el buscador disponibles en cualquier momento. Funcionalidad contenida: A partir de las opciones para cada una de las ventas actuales podremos editar en una interfaz diferente las características de la oferta o eliminar dicha oferta de nuestra lista. Además, con el botón añadir oferta, podremos utilizar la misma interfaz para crear una oferta nueva. Interfaz añadir/editar subasta Información contenida: En este formulario el usuario deberá especificar las características de su oferta. El registrado le pondrá un título a la oferta, seleccionará una categoría del artículo que vende, el tipo de venta que quiere realizar (subasta abierta, subasta cerrada o venta a precio fijo), establecerá un precio, hará una breve descripción del artículos y podrá elegir una imagen que actuará como imagen principal (en caso de estar creando la venta) o una serie de imágenes a añadir (en caso de estar editando la venta) que den una idea al 25 comprador del esta del producto. También en esta interfaz dispondremos del menú lateral y el buscador. Funcionalidad contenida: En la parte inferior de este formulario aparecerá un botón añadir, cuya función será añadir esta oferta a nuestra lista y publicarla en la página. En caso de estar editando una oferta el botón de confirmación recibirá el nombre aceptar. Interfaz perfil intereses Información contenida: Esta interfaz contendrá la información de todos los artículos que el usuario busca actualmente. Al lado de cada uno de estos artículos aparecerán dos opciones: una primera que dirá editar y una segunda que dirá “ya no me interesa”. Bajo estas opciones el usuario un botón para añadir un nuevo interes. Al igual que en las interfaces anteriores tendremos el menú lateral y el buscador disponibles en cualquier momento. Funcionalidad contenida: A partir de las opciones para cada uno de los intereses actuales podremos editar en una interfaz diferente las características de lo que buscamos o eliminar nuestro interés por ese artículo de nuestra lista. Además, con el botón añadir interés, podremos utilizar la misma interfaz para crear una búsqueda nueva. Interfaz añadir/editar interés Información contenida: En este formulario el usuario deberá especificar las características de lo que desea comprar. El registrado le pondrá un título a la búsqueda, seleccionará una provincia y hará una breve descripción del artículo. Por último establecerá la fecha límite en la que esperará encontrar el producto. También en esta interfaz dispondremos del menú lateral y el buscador. Funcionalidad contenida: En la parte inferior de este formulario aparecerá un botón añadir, cuya función será añadir este interés a nuestra lista y publicarla en la página. En caso de estar editando un interés ya descrito el botón de confirmación recibirá el nombre aceptar. 32 se lo llevará. En el caso de las subastas cerradas, la igual que en las abiertas, habrá una fecha final dentro de la cual los compradores ofrecerán una cantidad mayor al precio de salida, y sin saber que ofrecen los otros compradores. Al finalizar el tiempo, se enviará un email al ganador notificando que su puja ha sido la más alta y comunicándole como pagar por su nueva compra. 33 3 Elección de servidor y lenguaje En este capítulo realizaremos un análisis de las posibles tecnologías disponibles para implementar nuestro proyecto llevado a cabo y justificaremos la elección de nuestro servidor y lenguaje de programación elegidos. 3.1 Elección del servidor Un servidor web es un programa que está diseñado para transferir hipertextos, páginas web o páginas HTML: textos complejos con enlaces, figuras, formularios, botones y objetos incrustados como animaciones o reproductores de música. El programa implementa el protocolo HTTP que pertenece a la capa de aplicación del modelo OSI. El término también se emplea para referirse al ordenador que ejecuta el programa. En el siguiente gráfico podemos ver cuáles son los servidores web más utilizados en internet y su progresión en los últimos años. 34 Este es el top 5 de los servidores web más utilizados: SERVIDOR PORCENTAJE Apache 57,12 Microsoft IIS 24,11 Google GFE 6,74 Nginx 5,62 Lighttpd 0,80 Como podemos observar en la tabla de arriba hay dos servidores web que destacan por encima del resto: Apache y Microsoft IIS. Es por esto que realizaremos a continuación un análisis en varios aspectos de ambos para ver cuál de los dos se ceñiría de manera más precisa a nuestro proyecto. Coste Uno de los puntos más importantes a la hora de escoger un software para nuestro proyecto es el coste. Mientras Apache es un servidor web HTTP de código abierto, Microsoft IIS requiere de la compra de una licencia comercial para poder ser utilizado por una compañía. Seguridad Otro punto clave es la seguridad: Estadísticamente, el número de incidentes de seguridad sufridos por sistemas funcionando con productos de Microsoft es muy superior al de los ataques perpetrados contra sistemas de código abierto como Linux o Unix. Apache puede correr en varios sistemas operativos como UNIX, Linux o Windows siendo las dos primeras opciones las más seguras. Sin embargo, IIS pertenece a Microsoft y únicamente puede correr bajo un sistema operativo Windows, limitando nuestras opciones de configuración y penalizado, en mayor medida, la seguridad de nuestro servidor. Usabilidad En todo software es de agradecer poder disponer de una interfaz gráfica para su utilización ya que facilita en gran medida la configuración del mismo. Apache parece estar más limitado en este aspecto ya que toda configuración del servidor se realiza accediendo directamente a los ficheros de configuración del mismo. Por otro lado, Microsoft IIS dispone de una interfaz gráfica muy potente que facilita al usuario la utilización del software. 35 En el siguiente cuadro comparativo podemos ver un resumen de las diferencias entre ambos servidores: Apache Microsoft IIS Coste Open Source (Gratuito) Licencia (Pago) Seguridad Alta Media Usabilidad Basada en ficheros de configuración que penalizan su usabilidad Basada en interfaz gráfica que facilita su usabilidad Configuración Muchas posibilidades de configuración disponibles Posibilidades de configuración limitadas Plataformas UNIX, Linux, Windows Windows Servicios Sólo Web Web, SMTP, FTP, NNTP Recursos necesarios Consume pocos recursos Consume muchos recursos Velocidad Muy rápido gracias a una gran optimización Servidor web menos optimizado y por tanto, más lento Módulos/Plugins Dispone de un gran número de módulos y plugins desarrollados por la comunidad Dispone de un número reducido de módulos y plugins Conclusión Tras estudiar los puntos más importantes en la elección de un servidor web hemos llegado a la conclusión que Apache parece ser la mejor elección ya que, pese a no ser un software muy amigable en lo referente a su usabilidad, se trata de un servidor HTTP potente, seguro y muy configurable que cubre todas las necesidades de nuestro proyecto. 3.2 Elección de un lenguaje de programación Para realizar una buena elección de lenguaje de programación a utilizar en nuestro proyecto hemos decidido comparar las ventajas y desventajas de los tres lenguajes de programación de webs dinámicas más importantes que existen en el mercado: PHP, ASP.NET y JSP. 36 Complejidad PHP es un lenguaje de programación sencillo con una curva de aprendizaje bastante plana. ASP.NET es un lenguaje completamente orientado a objetos. Su aprendizaje es más costoso que PHP pero existen varias herramientas de desarrollo que nos facilitan el prototipazo con una interfaz gráfica y el trabajo a la hora de implementar el código. JSP también es un lenguaje orientado a objetos y su complejidad radica en que es necesario conocer y saber utilizar multitud de objetos antes de empezar a programar. Coste Mientras que PHP y JSP son dos lenguajes de programación gratuitos, ASP.NET requiere de la compra de licencias bastante caras para su utilización con fines comerciales. Servidor web ASP.NET requiere de un servidor Windows con Microsoft IIS y el framework .NET instalados para su funcionamiento. Para utilizar JSP es necesario tener instalado un servidor Tomcat. PHP puede utilizarse con varios servidores entre ellos Apache y Microsoft IIS. Base de datos Los tres lenguajes puede trabajar perfectamente con los principales servidores de base de datos si bien PHP + MySQL, ASP.NET + MSSQL Server y JSP + Oracle son las combinaciones más recomendadas. 37 Librerías Los tres lenguajes tienes muchas librerías disponibles para los desarrolladores pero sobretodo PHP y JSP disponen de multitud de librerías desarrolladas por la comunidad gratuitas y Open Source. En el siguiente cuadro comparativo podemos ver un resumen de las diferencias entre los lenguajes de programación estudiados: PHP ASP.NET JSP Complejidad Sencillo con una curva de aprendizaje plana Complejo con una curva de aprendizaje elevada Complejo con una curva de aprendizaje elevada Coste Open Source (Gratuito) Licencias de pago Open Source (Gratuito) Servidor Web Soportado por la mayoría de servidores web Requiere servidor Windows con IIS y framework .NET instalados Requiere tener un servidor Tomcat instalado Base de datos recomendadas MySQL MS-SQL Server Oracle Soporte y comunidad Gran numero de comunidades detrás. Gran número de librerías disponibles Comunidades controladas por Microsoft. Número de librerías limitado Gran numero de comunidades detrás. Número de librerías limitado Seguridad Alta. Puede correr en máquinas UNIX y Linux Media. Al requerir un servidor Windows la seguridad se limita en gran medida Alta. Puede correr en máquinas UNIX y Linux Rendimiento Velocidad de proceso alta y un consumo de recursos bajo Requiere de servidores más pesado que penalizan tanto la velocidad como el consumo de recursos Requiere de servidores más pesado que penalizan tanto la velocidad como el consumo de recursos Velocidad de desarrollo Permite la modificación “al vuelo” de ficheros sin necesidad de desplegar la aplicación Es necesario desplegar la aplicación en un servidor de aplicaciones para poder ejecutarla Es necesario desplegar la aplicación en un servidor de aplicaciones para poder ejecutarla 38 Conclusión Si tenemos en cuenta los puntos importantes que hemos comparado anteriormente vemos que PHP es un software libre que se integra perfectamente con el servidor HTTP Apache y, a su vez, es sencillo de utilizar y recibe soporte constante por parte de la comunidad poniendo a nuestra disposición multitud de librerías que nos serán muy útiles a la hora de desarrollar gran parte de los requerimientos de nuestro proyecto. Además de esto, hay que tener en cuenta que es un lenguaje multiplataforma, de manera que podrá ser ejecutado sobre cualquier sistema operativo sin necesidad de complejas instalaciones de librerías de compatibilidad. 39 4 Análisis y diseño 4.1 Casos de Uso En la figura podemos ver un breve diagrama de casos de uso que explica el funcionamiento básico del sistema. Los usuarios identificados en el sistema son fundamentalmente tres. En primer lugar tenemos el usuario anónimo, que como indica el diagrama limita su función a ver y buscar artículos. Este puede registrarse o loguearse si ya dispone de una cuenta para ser promovido al usuario fundamental del sistema, el usuario registrado. El usuario registrado, tiene un abanico de acciones mucho más extenso, ya que es él el que da sentido al sistema. En primer lugar, dispondrá de un perfil, desde el cual podrá acceder a consultar los datos que el sistema tendrá de él. Además de ver y buscar artículos al igual que el usuario anónimo, este podrá publicar sus propias ventas de artículos eligiendo para cada una que tipo de venta escogerá, ya que cada una de ellas tendrá un comportamiento lógico distinto. Tras dar de alta una subasta, el usuario podrá cancelarla en cualquier momento, siempre y cuando esté dentro del margen de tiempo establecido por él. Al igual que ve los artículos, puede establecer una valoración crítica sobre ellos, dejando un comentario para los usuarios que lo visiten posteriormente, o incluso si está interesado en el artículo en cuestión, puede pujar por él con intención de comprarlo. Cuando un usuario registrado puja por un artículo, cabe la posibilidad de que gane su subasta; en dicho caso, y mediante la entidad Fig 1 Diagrama de Casos de Uso 40 Banco, deberá proceder a pagar el precio con el que pujó, de forma que el artículo le sea entregado. Por último tenemos al usuario administrador. Este usuario será el encargado de mantener el orden en el portal de subastas. Sus tareas consistirán en evaluar todas las quejas que los usuarios envíen sobre los artículos en venta. Se encargarán de analizar la veracidad de estas quejas y de tomar medidas al respecto, tales como recategorizar artículos de categorías erróneas o banear usuarios que intenten hacer ventas fraudulentas. A continuación veremos los modelos realizados con los requisitos de diseño y de interfaz. Los modelos se han realizado mediante el uso de la herramienta de trabajo Moskitt en su versión 1.3.0 4.2 Estructura Fig 2 Diagrama de Clases UML 41 La estructura del sistema ha sido modelada mediante el diagrama de clases de UML, como podemos apreciar en la figura 2, encargado de representar la estructura y comportamiento del sistema. Para ello se han detectado 13 clases y diversas relaciones necesarias entre las mismas. A continuación explicaremos en detalle las distintas clases detectadas así como la información que en ella se representa: • Usuario: Modela el comportamiento general de todo usuario del sistema, esta clase alberga los atributos comunes a los tipos de usuario identificados en el diagrama. Estos atributos son correo y contraseña, con la que todos los tipos de usuarios entrarán al sistema. • Administrador: Representa a los usuarios que mantienen el orden entre los usuarios registrados dentro de la página Web, entre sus tareas se encuentran la de dar de alta nuevos administradores o la de banear usuarios registrados. • Registrado: Contempla a los usuarios con capacidad de realizar ciertas tareas no accesibles para los anónimos. Sus atributos son nick, provincia, teléfono y el colectivo de atributos disponibles en caso de usuario baneado, como son si esta baneado o no (baneado) y el motivo y fechas que comprenden el baneo de dicho usuario en caso de estar baneado. Será también el encargado de crear una serie de objetos como son subastas, intereses o alertas y dispondrán también del poder de cambiar su contraseña o cancelar sus propias subastas. • Alerta: Esta clase representa las alertas que un usuario creará en función de las ofertas que esté buscando, en cada alerta dispondremos de una palabra clave, una categoría en la que se encasillaría el objeto buscado y la provincia en la cual se está buscando dicho producto. • Interés: Esta clase representa ofertas de lo que un registrado busca, de manera que otro usuario pueda verlo y ponerse en contacto con él. Para cada una de estas búsquedas el usuario deberá aportar un título, una provincia en la cual lo busca, una breve descripción de lo que busca y un intervalo de fechas en las que espera encontrarlo. • Subasta: Contempla las subastas que un registrado hace, de manera que en ella se establecen el intervalo de fechas de la subasta, la categoría del artículo que se vende, el tipo de subasta que es (abierta, cerrada o precio exacto) y el precio inicial que tiene asociado. 48 Interés Esta será la interfaz encargada de mostrar las características de los elementos de categoría interés, que serán descripciones de lo que busca el usuario. Para cada uno veremos su título, descripción, provincia del interesado, intervalos de fechas de interés y también los datos de contacto con el usuario en caso de tener algo que ofertarle. Mapa navegacional administrador El mapa navegacional del administrador tendrá una serie de opciones de administración a las cuales sólo este usuario podrá acceder. Como podemos ver, el administrador comenzará su estancia en nuestro sitio Web en la página de artículos desclasificados (nodo que contiene el icono de la ventana que indica que es la página de inicio de este usuario), pudiendo acceder en cualquier momento a las páginas de denuncias, añadir administrador o baneados (nodos que contiene la estrella que indica que son sitios siempre accesibles, ya sea desde el menú de Fig 10 Vista página interés Fig 11 Mapa navegacio nal administrador 49 navegación o desde enlaces siempre visibles en la página). Dentro de denuncias o desclasificados, el administrador podrá navegar a la página en la que se enseñan las características de los artículos denunciados o desclasificados. Pasaremos ahora a ver que contiene cada una de las interfaces del usuario administrador con un poco mas de detalle. Desclasificados En esta página, como se aprecia, podremos ver una lista con las diez últimas ventas desclasificadas. Para cada una veremos el nombre del artículo y la categoría correcta introducida por el denunciante. Denuncias En esta página, como se muestra en la imagen, veremos una lista de las últimas diez ventas denunciadas. Para cada una de estas ventas, se mostrará la motivación de la denuncia, el nombre del artículo y el nick del propietario del artículo. Fig 12 Vista página desclasificados Fig 13 Vista página denuncias 50 Baneados En este nodo, podemos apreciar que se nos mostrará una lista con los cinco últimos usuarios baneados. De cada uno de estos usuarios, veremos su nick, el motivo por el que fue baneado, y la fecha en la que acabará su baneo. Producto Como podemos observar, esta es la información que se verá en la interfaz del producto a la que accede el administrador. Al igual que pasaba con el usuario anónimo, podremos ver las fechas de inicio y final de la oferta, el precio de venta de la oferta y el tipo de oferta que es (como ya se comento con anterioridad, subasta abierta/cerrada o venta a precio fijo). En cuanto a información del artículo que se vende veremos el nombre de éste junto con una pequeña descripción del mismo indicando lo que el vendedor considere oportuno, junto con Fig 14 Vista página baneados Fig 15 Vista página producto 51 las fotos del artículo que el usuario haya facilitado al ponerlo en venta. En cuanto a la información del vendedor, veremos la provincia (que será la provincia a la que pertenece el artículo) el nick y su teléfono y dirección de correo para ponernos en contacto con él en caso de tener algún problema con la oferta o pregunta sobre ella. Por último, de cada artículo veremos los últimos cinco comentarios hechos por usuarios en los que se mostrará el contenido del comentario junto con una valoración que los usuarios harán sobre él. Añadir Administrador Esta será la interfaz en la que los administradores utilizarán su permiso para crear nuevos administradores introduciendo el email de los administradores así como su contraseña de administrador. Mapa navegacional Registrado Fig 16 Vista página añadir administrador Fig 17 Mapa navegacional registrado 52 Como podemos apreciar, el usuario registrado es el que dispone de una mayor cantidad de interfaces y mayor movilidad en la página Web. De hecho, hay ciertas áreas de contenidos reservadas únicamente para él. En primer lugar, contiene una zona de navegación igual a la del anónimo, de forma que comenzando en su página principal (nodo que contiene el icono de la ventana) podrá navegar en cualquier momento a la página de categoría y provincia (páginas siempre accesibles como indica la estrella), al igual que hacía el anónimo. La diferencia entre el registrado y el anónimo radica en la parte navegacional asociada al perfil (nodo siempre accesible). El usuario registrado dispondrá de opciones de subastas, intereses, pujas y alertas de las cuales el usuario anónimo estaba privado. También, como usuario registrado que es tendrá derecho a modificar su contraseña según lo vea conveniente. A continuación veremos cada uno de los nodos que aparecen en profundidad. Principal Esta será la página de inicio del usuario registrado, al igual que la del anónimo contendrá una lista con las diez últimas ofertas añadidas al portal, listadas de manera que para cada una de ellas se verá su precio, la fecha de fin de la oferta, el tipo de venta, el nombre del artículo y el nombre del ofertante. Categoría En esta página, como se aprecia, podremos ver una lista con los diez últimos artículos en venta de la categoría elegida por el usuario. De cada artículo veremos su precio, la fecha de fin de la oferta, el tipo de venta, el nombre del artículo y el nick de quien lo vende. Fig 18 Vista página princ ipal Fig 19 Vista página categoría 53 Provincia En esta página, como se observa en la imagen, se verá una lista con los diez últimos artículos en venta en la provincia elegida por el usuario. De cada artículo se mostrará su precio, la fecha de fin de la oferta, el tipo de venta, el nombre del artículo y el nombre del ofertante Al igual que en la vista del usuario anónimo. Producto Como podemos observar, esta es la información que se verá en la interfaz del producto en oferta. En primer lugar podremos ver las fechas de inicio y final de la oferta, también se verá el precio de venta de la oferta y el tipo de oferta que sea. En cuanto a información del artículo en venta, veremos el nombre de éste junto con una pequeña descripción del mismo indicando lo que el vendedor quiera resaltar o puntualizar, junto con las fotos del artículo que el usuario haya facilitado al ponerlo en venta. En cuanto a la información del vendedor, veremos la Fig 20 Vista página provincia Fig 21 Vista página producto 54 provincia (que será la misma que se le asociará al artículo) el nick y su teléfono y dirección de correo para ponernos en contacto con él en caso de tener algún tipo de pregunta. En último lugar, de cada artículo veremos los cinco últimos comentarios hechos por usuarios en los que se mostrará el contenido del comentario junto con una valoración que los usuarios harán sobre él. Interés Esta será la interfaz encargada de mostrar las características de los elementos de categoría interés, que serán descripciones de lo que busca el usuario. Para cada uno veremos su título, descripción, provincia del interesado, intervalos de fechas de interés y también los datos de contacto con el usuario en caso de tener algo que ofertarle. Perfil En esta página se mostrará la información sobre el usuario registrado. Veremos su nick, provincia y su teléfono, así como una serie de enlaces para acceder a la gestión de sus ofertas, alertas o pujas. Fig 22 Vista página interés Fig 23 Vista página perfil 55 Cambiar contraseña En esta interfaz dispondremos de un formulario que nos permitirá realizar un cambio de contraseña para acceder al sistema. En el simplemente se nos pedirá la contraseña actual y la nueva contraseña por duplicado para evitar errores en el cambio. Alertas Como se aprecia en la figura, esta interfaz nos mostrará una lista con todas las alertas del usuario registrado que se encuentre en ese momento en el sistema. Para cada una de las alarmas se nos mostrará la categoría del producto, las palabras clave que debe haber en el nombre del artículo y la provincia en la cual el usuario pretende encontrar el artículo. Añadir alerta Lo que nos encontraremos en esta página Web será un formulario para la creación de una nueva alerta que el usuario quiera crear. Para ello deberá añadir las palabras clave, la provincia y la categoría del producto que busca. Como resultado se creará la alerta que le avisará por email de coincidencias con sus criterios. Para la modificación de esta alerta, será empleada la misma interfaz. Fig 24 Vista página contraseña Fig 25 Vista página alertas Fig 26 Vista página añadir alerta 56 Intereses En esta interfaz se nos mostrará una lista con los intereses que el usuario tenga pendientes en páginas de diez elementos. De cada uno de ellos se nos mostrará el título del mismo, la fecha de inicio y fin y una descripción de lo que el usuario busca, junto con la provincia en la que lo busca. Añadir Interés En esta interfaz dispondremos de un formulario en el cual insertaremos los datos de lo que pretendemos comprar, estos campos serán un título del interés, una fecha límite de búsqueda y una descripción. El resto de datos, se cogerán del usuario que este identificado en ese momento en el sistema. Esta misma interfaz será utilizada también para la edición de un interés concreto. Fig 27 Vista página intereses Fig 28 Vista página añadir interés 57 Subastas En esta interfaz se nos mostrará una lista con las ventas que el usuario tenga actualmente ofrecidas en páginas de diez. De cada una de éstas se nos mostrará el tipo de venta que es, la fecha de fin y el precio por el que se oferta. Además de esto, la venta tendrá como título el nombre del artículo que se vende en ella. Añadir subasta En esta interfaz dispondremos de un formulario en el cual insertaremos los datos de lo que pretendemos vender. Estos campos serán fecha límite de compra, nombre del producto, una pequeña descripción, el tipo de venta que será, el precio que tendrá y una fotografía que habrá como fotografía principal. Como anotación diremos que esta interfaz será también utilizada para modificar los datos de la subasta. En la interfaz de edición, además de los mismos datos que aparecen en la de creación, dispondremos de una múltiple selección de imágenes que añadir a nuestra oferta. Fig 29 Vista página subastas Fig 30 Vista página añadir subasta 64 Interfaz => xxxxxx.php Funciones necesarias => gestion_xxxxxx.php Lógica de negocio => gestion_logica_xxxxxx.php Por último nombraremos algunos archivos que llevan a cabo funciones complementarias, como son ventana_popup.js, grande.js o fecha.php entre otros. 5.3.2 Funciones de acceso a datos En este punto veremos el código de las funciones básicas de acceso a la base de datos de MySQL que son las que establecen la conexión entre la aplicación y la base de datos. Estas funciones estarán presentes en todos los archivos que hagan alguna consulta sobre dicha base de datos, ya que son una plantilla para realizar estas consultas o actualizaciones. En la figura 34 vemos como se elabora una función en PHP para cada uno de los tipos de operaciones posibles. La primera función devuelve la conexión a la base de datos mientras que las siguientes devuelven el resultado de una consulta, realizan una actualización de los datos, y cuentan el número de filas afectadas por una consulta respectivamente. Por último Fig 34 Código del archivo gestion_datos.php 65 disponemos de la función de desconexión de la base de datos que se encarga de eliminar esta referencia. 5.3.3 Paginación de consultas A continuación veremos y explicaremos el método utilizado para consultar la base de datos y mostrar los resultados devueltos de manera paginada. Para ello, dado que el mecanismo es el mismo en todas las interfaces, analizaremos la interfaz principal del usuario anónimo, cuyo código vemos en la figura 35. Fig 35 Código relativo a la paginación de consultas 66 Como se aprecia en la figura, en primer lugar estableceremos un tamaño de diez productos por página y recogeremos el número de página en la que estamos. La página y el tamaño de página determinarán que número de resultados será los diez siguientes, que serán asociados a la variable $datos. Tras esto, calcularemos el número total de páginas y recorreremos la variable $datos para imprimir por pantalla cada uno de los campos obtenidos en la consulta. Tras poner en pantalla todos los resultados, crearemos al final de la lista un conjunto de enlaces con los números de página siempre y cuando el número total de páginas sea mayor que uno. 5.3.4 Entrada a zonas fuera de alcance Podría darse el caso de que un usuario no registrado conociera la dirección URL de la página de un usuario registrado o administrador, y que copiando dicha dirección en el navegador quisiera acceder para suplantar sus identidades. Este caso está controlado con un sencillo código colocado en todas las páginas que requieren de un restringido acceso, de manera que no se puede acceder a ellas sin estar identificado dentro del sistema. Como se aprecia en la figura 36, al entrar en la página de un registrado la primera sentencia que se ejecuta es la de buscar una variable llamada $_SESSION[“id_registrado”]. Esto es una variable de sesión, las variables de sesión son almacenadas por el navegador, de forma que si en algún momento cambio de página, la variable sigue viviendo en la sesión de Internet. Hay que mencionar, que las variables $_SESSION[“id_registrado”] y $_SESSION[“nick”] son inicializadas siempre que un usuario hace login y destruidas en el logout, de manera que un usuario anónimo jamás podrá acceder a una página sin tener estas variables inicializadas y será reenviado a la pantalla de error en el login. Fig 36 Código de control de acceso con variables de sesión 67 5.3.5 Menú lateral desplegable Este menú, cuyo aspecto podemos apreciar en la figura 37, es simplemente un menú desplegable del que vemos todo el contenido al clicar sobre él. Este efecto es algo sencillo de conseguir y lo veremos a continuación. Según el código facilitado (figura 38) se basa sencillamente en un enlace con una lista oculta. Para hacer funcionar este pequeño truco, crearemos una entrada en el menú con la palabra categoría y que sea un enlace a la propia página (href=“#”) y que invocará a una función llamada mostrar (cuyo código se encuentra en la figura 39) que muestra una lista oculta. La lista mencionada, será creada al cargar la página cogiendo el conjunto de todas las categorías de la base de datos y creando un enlace a la sección de subastas por categoría para cada una de ellas. Fig 37 Menú desplegable Fig 38 Código asociado al menú desplegable 68 5.3.6 Formulario añadir subasta En primer lugar veremos cual es el formulario HTML que representa a esta página y luego veremos como es gestionado este formulario. En la figura 40 vemos que este formulario ejecutará la rutina del archivo gestion_anyadir_venta.php situado en esta misma carpeta. Pero antes de realizar esta rutina, deberá pasar la verificación de campos que se encuentra en el botón Añadir de tipo submit. Veremos cuales son las verificaciones a cumplir descritas en el archivo Fig 39 Código para mostrar el menú desplega ble Fig 40 Código del formulario añadir subasta 69 comprobar_anyadir_venta.js (figura 41). Estas serán una serie de condiciones que deben cumplirse íntegramente. En primer lugar los campos marcados con * deberán estar rellenos, tras haber superado esta condición se pasará a comprobar que el campo precio introducido sea numérico y por último se comprobará que la fecha introducida sea mayor que la del día actual, debido a que es uno de los requisitos para poder ofertar una subasta. Tras pasar este corte, veremos cual será el flujo a seguir para insertar una venta (código de gestion_anyadir_venta.php en la figura 42) En primer lugar, se seleccionará una rutina de controlador en función del campo oculto “tarea”, ya que este mismo archivo servirá para gestionar la adición de nuevas subastas al portal o la edición de subastas ya existentes. Al seleccionar la tarea “anyadir”, se invocará la función anyadir_venta() (figura 43). Fig 41 Código de la función que valida el formulario Fig 42 Código de control de lógica del archivo gestion_anyadir_venta.php 70 La susodicha función obtendrá todos los datos enviados en el formulario, así como algunos datos almacenados en la sesión y con todo esto, pasará a realizar las pertinentes actualizaciones en la base de datos. En primer lugar, insertará en la tabla artículo, ya que es la tabla no referenciada. Tras insertar en ella, recuperará el identificador del artículo insertado. Tras esto insertará la ruta de la fotografía en la tabla fotografía y luego pasará a la inserción de la subasta con toda la información. Tras esta inserción el sistema se encargará de encontrar a todos aquellos registrados que tuvieran una alerta establecida que cuadre con la subasta insertada y enviarles un correo notificándoles de la coincidencia. Como se aprecia antes de conectar con la base de datos habrá una sección del método que se encargará de verificar si hay una imagen seleccionada asignando en caso contrario una por defecto y en caso de que si que la haya se ejecutará una función llamada comprobar imagen que insertará la imagen en el correspondiente directorio resolviendo los conflictos de nombres y devolviéndonos de nuevo al formulario de registro de subasta nueva en caso de que el formato de la imagen no sea compatible con los utilizados por el sistema. Fig 43 Código de la función anyadir_venta() 71 5.3.7 Función banear usuario En este apartado veremos la que, junto con la función que acabamos de ver (anyadir_venta()) sería una de las funciones más completas del sistema. Observando la figura 44 comentaremos en qué consiste esta función. Como podemos observar, esta imagen recibe el identificador del usuario baneado, el motivo de su baneo y la fecha de fin del baneo. En primer lugar, como todas las funciones, establece una conexión con la base de datos. Tras hacer esto, selecciona el nick y el email del usuario que va a ser baneado almacenándolos en la variable $nombre. Tras esto, actualiza el estado del usuario a baneado con el motivo y la fecha de inicio y fin correspondientes del baneo. A continuación elimina todas las propuestas que existieran de baneo de este usuario debido a que ya ha sido baneado y cancela todas sus pujas sobre artículos y sus ofertas de tipo interés que tuviera publicadas en el portal. Después de estas operaciones el sistema selecciona todos los emails de usuarios registrados que estuvieran participando en una de sus ventas, y todas estas son inmediatamente eliminadas tras conseguir esta información. Por último, el portal envía un email a cada uno de los usuarios que habían pujado notificándole de que el usuario ha sido dado de baja y por lo tanto sus posibles ventas han sido consideradas fraudulentas y han sido canceladas. Tras finalizar con todo esto, el usuario baneado recibe un email siendo notificado de toda la información de su baneo. Fig 44 Código de la función banea r_usuario() 72 5.3.8 Momento del “adjudicado” En nuestro sistema ha habido un pequeño problema con el control del tiempo de la subasta. El problema es simple y se basa en la falta de captura de eventos temporales mediante código PHP. Todos sabemos y suponemos que cuando lleva la fecha y hora del fin de una subasta, esta debe ser adjudicada al mejor postor, pero… ¿Cómo sabe PHP que la subasta ha acabado? Dado que en PHP no hay ningún evento que se dispare en cada segundo o minuto de tiempo que pase, no podemos hacer que los correos sean enviados a la precisa hora en la que una subasta finaliza. Dado este problema, nos obligamos a introducir una porción de código que siempre que se ejecute cierto fragmento se envíe al servidor una petición de comprobación y se tomen las medidas oportunas. Este fragmento de código ha sido introducido en la función login (figura 45). Fig 45 Función de login invocando a la función de repaso_ofertas() 73 Cada vez que un usuario haga login en la aplicación, esta preguntará a la base de datos si ha pasado la fecha de fin de cualquiera de las subastas actualmente activas, de forma que ejecutará la función que aparece en la figura 46. En primer lugar se resolverán las subastas que hayan pasado sin pujas, y se enviará un correo al propietario de la subasta indicándole que su producto no se vendió y que trate de poner una nueva oferta más interesante. Tras resolver estas subastas, se pasará a resolver las subastas que si que tengan pujas y para ello se elegirá la mayor puja de la subasta enviando al usuario un email con un enlace a la página de pagos para que abone su compra. Tras esto se liberará el baneo de todos aquellos usuarios cuya fecha de baneo haya cumplido y se les notificará de ello por correo electrónico. Una vez hecho esto, y por último, se eliminarán las ofertas de tipo interés y se notificará al usuario que su oferta ha sido eliminada por exceder su fecha límite. Fig 46 Código de la función repaso_ofertas() 80 De forma que, como el usuario que añadió la mecedora era de la provincia de Valencia, el usuario recibió el siguiente email: El mensaje, como podemos apreciar, es recibido de manera satisfactoria, haciéndonos ver de esta manera que el sistema de alertas funciona de manera correcta. Fig 53 Email recibido como respuesta a la alerta 81 Editar subasta sin fotografía Puesto que la subasta creada en la primera prueba fue creada sin una fotografía asociada, procederemos ahora a introducir una imagen de dicha mecedora, observando así la asociación de la imagen con la subasta concreta y la sustitución de la imagen “Sin Foto” por la mecedora introducida. Para ello iremos a la interfaz “Editar Subasta” e introduciremos la fotografía en uno de los huecos disponibles (figura 54). Como se aprecia, tras aceptar, la imagen principal de la subasta cambia y se convierte en la imagen colocada por el usuario al editar la subasta, indicando así que esta funcionalidad esta totalmente operativa y no proporciona ningún tipo de error. Fig 54 Resultado al añadir una foto en una subasta sin imágenes 82 Acceso del usuario baneado En caso de que un usuario sea baneado, el sistema debe tener el control total de interrumpir sus acciones e impedirle entrar a su cuenta de usuario. En este caso veremos en la figura 55 que hay un usuario baneado. En este caso, este usuario intentará entrar al sistema mediante su correo y contraseña obteniendo el siguiente resultado (figura 56). Fig 55 Lista de usuarios baneados Fig 56 Resultado con la identificación de un usuario baneado 83 Como podemos apreciar, el usuario tiene totalmente negada la entrada y el sistema le informa de que consulte su correo, ya que debe haber recibido un email con su motivo y fecha de fin de baneo al ser baneado. Control de acceso a zonas externas En esta última prueba, un usuario anónimo intentará entrar en la zona de un administrador mediante la URL. Para ello, copiara en la barra de direcciones la URL del usuario administrador (figura 57), pero el sistema deberá impedirle la entrada, limitando así el acceso a sólo usuarios administradores con email y contraseña (figura 58). Fig 57 Intento de acceso a una zona restringida Fig 58 Resultado ante un acceso prohibido 84 De esta forma, una vez más la integridad del sistema esta a salvo y ningún usuario no autorizado podrá establecer cambios en una zona de la página restringida. 85 7 Referencias Libros • Una guía para la realización y supervisión de proyectos final de carrera (PFC) en el ámbito de la Web. Félix Buendía García. REF 103-792-094. Direcciones Web • http://www.programacionweb.net/foros/mensaje/?num=4990 • http://www.elcodigo.net/tutoriales/javascript/javascript2.html • http://goliatenterrado.es/2009/03/03/configurar-el-mercury32-del-xampppara-enviar-correos-externos/ • http://www.desarrolloweb.com/manuales/24/ • http://php.net/manual/es/index.php • http://www.desarrolloweb.com/manuales/manual-css-hojas-de-estilo.html • http://www.apachefriends.org/es/xampp.html • http://www.moskitt.org/ • http://compraventa.ebay.es/ 86 87 8 Conclusiones Para concluir este documento, expondremos a continuación diversas razones que hemos extraído de la realización del mismo: Una vez finalizado el proyecto podemos concluir que se han cumplido todos los objetivos. Hemos desarrollado una aplicación que cubre todas las necesidades expuestas al inicio del proyecto. Sobre el trabajo que realizado cabe destacar que hemos llevado a cabo, de forma rigurosa, todas las tareas que determinamos en la planificación de forma ordenada y eficiente: • En un inicio determinamos todos los requerimientos que tendría la aplicación. • Diseñamos los casos de uso de los requerimientos. • Diseñamos la estructura base de distribución de la información que contendría el portal. • Realizamos un estudio de la base de datos de la web. • Implementamos la estructura base del proyecto. • Llevamos a cabo la implementación de cada una de las partes del proyecto. • Realizamos una exhaustiva prueba de cada interfaz para detectar los errores que pudiera haber en cada una de ellas. • Corregimos todos aquellos errores que fueron detectados. • Presentamos el producto acabado al usuario final para comprobar su aprobación. • Por último, elaboramos un manual básico de usuario. 8.1 Mejoras y ampliaciones Tras la finalización de los requisitos básicos planteados desde el inicio del proyecto, surgen posibles ampliaciones o mejoras que podrían servirnos para mejorar aún más el aspecto y gestión de nuestro portal de subastas. En primer lugar, podría introducirse en un futuro la opción de una gestión publicitaria externa a nuestro portal, de manera que algunas empresas estuvieran dispuestas a pagar por ser anunciadas en nuestra página. Podría para ello establecerse una gestión de tiempo, zonas y precios por los cuales las empresas con intención de anunciarse deberían competir. 88 En segundo lugar, algún tipo más de ventaja podría ser la de dar la posibilidad de comprar unas facilidades a los usuarios permitiendo a algunos patrocinar sus productos para que aparezcan como recomendados en las búsquedas. Por último, se podría también pensar en una visualización de las estadísticas del portal, teniendo en cuenta la posibilidad de establecer un balance entre ofertas de subasta creadas, canceladas, vendidas o sin comprador al acabar la fecha límite, estableciendo favoritismos para ofertas menos populares y facilitando su publicidad o por el contrario establecer como preferencia las ofertas que más éxito tienen para que aparezca como recomendadas en los buscadores. De igual forma favorecer también a los usuarios que más implicación tengan con sus subastas y compras regalándoles algún tipo de descuento o ventaja con respecto a los productos del portal. 8.2 Valoración personal En primer lugar, la formación recibida en la carrera, debido a haber cursado la intensificación de ingeniería del software, ha sido orientada al análisis y diseño de los sistemas de información, siendo más paupérrima en las etapas finales de desarrollo de software. Esto ha dificultado la implementación del proyecto debido a la falta de conocimiento en muchas tecnologías web, lo cual, junto con otros factores ajenos al proyecto, ha determinado que los plazos de entrega del mismo se hayan postergado y nos hayamos visto obligados a invertir más tiempo del que en un principio habíamos estimado. En segundo lugar, la cantidad de tecnologías que hay que usar para realizar un proyecto web aceptable obliga al programador a invertir mucho tiempo en familiarizarse en el conocimiento y soltura de las mismas así como en tener que renunciar a algunas de ellas para poder cumplir los plazos haciendo que esto afecte a la calidad del producto de manera negativa. Por último, la interfaz de visualización de las páginas web sería uno de los objetivos a tener en cuenta para posibles ampliaciones de la aplicación así como eliminar los tiempos de refresco cambiándolos por una tecnología que permita realizar tan sólo refrescos parciales de 89 la página como podría ser AJAX sin necesidad de realizar una y otra vez peticiones al servidor con datos que no han sido modificados. 96 Crear base de datos En este apartado veremos qué debemos hacer para poner en marcha la base de datos de la aplicación. Para ello deberemos en primer lugar instalar un sistema de gestión de base de datos MySQL. Bajaremos un instalador de MySQL y lo ejecutaremos con privilegios de Administrador realizando la instalación estándar. Se recomienda instalar la aplicación en la carpeta C:\MySQL. Al terminar de instalar se nos pedirá una configuración, en ella modificaremos las opciones de seguridad y el asignaremos una contraseña a root, que es el administrador de MySQL. Con nuestro servidor ya en marcha, Pasaremos a instalar una interfaz gráfica para poder utilizar de manera más cómoda MySQL. Por ejemplo, phpMyAdmin. Con todo configurado y la interfaz en funcionamiento, procederemos a hacer la correcta importación de la base de datos proporcionada. La base de datos ha sido exportada en formato XML y en ese mismo formato deberá ser importada, dando lugar a la correcta creación de las tablas y relaciones entre éstas. En la base de datos deberemos crear si no existe al usuario “subastas” con contraseña “pfc2012” que tendrá privilegios sobre nuestra base de datos llamada “subastland”. Con todo en orden y configurado de esta manera, los archivos de código no tendrán problemas para acceder a la base de datos, permitiendo así el correcto funcionamiento de la aplicación. Configuración del servidor de correo Por último, dado que la aplicación lo exige, se procederá a configurar el servidor de correo de la aplicación. Para ello nos haremos con un servidor de correo Mercury/32, que nos proporcionará el comportamiento necesario exigido por la aplicación. Nos quedará tras la instalación configurar los archivos necesarios para ponerlo en marcha. Aquí vemos una lista de pasos que deberemos seguir: 1. Iniciaremos el Mercury/32 y presionaremos al botón Admin. Se iniciará el panel de control del Mercury/32. 2. Vamos a Configuration/Protocol Modules y desactivamos “MercuryB HTTP web server” y “Mercury IMAP4rev1 server”. Para mandar emails a correos externos desactivamos “MercuryE SMTP end-to-end delivery client” y en cambio activamos “MercuryC SMTP relaying client”. Damos al Ok y reiniciamos el Mercury. 97 3. Volvemos a la consola del Mercury y vamos a Configuration/Mercury core module y en nos ponemos en la pestaña General. En “internet name for this system” ponemos el dominio que tenemos en nuestro servidor, que será localhost. Los otros campos están ya configurados, sólo tenemos que desactivar todos los check de abajo menos “Send copies of all errors to postmaster”. Damos a Ok. 4. Vamos a configurar el SMTP para los emails salientes en Configuration/MercuryS SMTP Server. En la pestaña General, en el campo “Announce myself as” ponemos el nombre: “subastland SMTP”. Comprueba que el TCP/IP port está a 25, que es el del SMTP. En “IP interface to use” ponemos 127.0.0.1. Ahora limitaremos el acceso a nuestro servidor a sólo nuestra máquina local de la siguiente forma: En la pestaña Connection control damos al botón Add restriction y ponemos 127.0.0.1 to 127.0.0.1. Comprobamos que está activos Allow Connection y dejamos todos los check desactivados. En la pestaña Connection Control desactivamos Do not Permit SMTP relaying to non-local mail. Damos al OK. 5. Configuraremos el POP3 del Mercury en Configuration/MercuryP POP3 Server. En la pestaña General comprobamos el que TCP port es 110 y la “IP interface to use” es 127.0.0.1. Vamos a Connection Control y añadimos la misma restricción que en alterior punto, sólo para nuestra máquina local de la misma forma. Damos al Ok. 6. Nos toca configurar el cliente del SMTP del Mercury en Configuration/MercuryC SMTP Client. Para mandar emails al exterior necesitamos los datos de un correo exterior. En nuestro caso serán los datos del correo asociado a la página web, que serán los datos del gmail del SMTP para correos salientes. En “Smart host name” ponemos smtp.gmail.com. El puerto elegiremos el 587. Luego elegimos STARTTLS que es lo que soporta el gmail. En “Login username” ponemos nuestra cuenta de correo de gmail (subastland.[email protected]om), y en “Password” nuestra contraseña del correo gmail (subastland2012). Esta parte la tenemos resuelta. Damos al Ok. 7. Configuration/Manage local users comprobamos que tenemos los usuarios Admin y postmaster con permisos de administrador. 8. Con el Mercury ya hemos acabado, ahora toca modificar el archivo php.ini que se encuentra en apache/bin. Nos dirigimos a [mail function] y comprobamos que los siguientes datos están así: SMTP = localhost, smtp_port = 25 y añadimos la siguiente linea: sendmail_from = postmaster@localhost (o descomentamos la que hay y la cambiamos por estos datos). Guardamos y reiniciamos el apache. 98 Con el seguimiento de estos pasos tendremos nuestro último componente necesario para el funcionamiento de nuestro portal web. A continuación veremos el modo de usuario y su completo funcionamiento. Parte del usuario Como primera aclaración diremos que la aplicación consta de tres tipos distintos de usuarios, con algunas interfaces comunes como veremos más adelante. Estos tres usuarios son el usuario anónimo, el usuario registrado y el usuario administrador. Comenzaremos viendo la interfaz y las opciones disponibles para un usuario anónimo. Usuario Anónimo Zonas comunes Antes de empezar a comentar la funcionalidad de cada una de las páginas del usuario anónimo, conviene comentar la distribución de los elementos que aparecen en la figura 7. Como podemos observar, esta interfaz contiene tres partes destacadas: • Zona de navegación (zona de la izquierda). • Zona de búsqueda (zona superior). • Zona de información (zona central). Fig 7 Interfaz del usuario anónimo 99 En todas las interfaces del portal el usuario dispondrá de una zona de navegación que cambiará en función de que tipo de usuario esté viendo el sistema. En nuestro caso, la zona de navegación del usuario anónimo se compondrá de un subconjunto de las opciones que se ven en la figura 8. Esta zona se utiliza para viajar de una página a otra mediante los enlaces que se encuentran en cada una de las palabras y para identificarse en el sistema ganando así privilegios. Comentaremos que sucederá en cada uno de estos enlaces: • Inicio: Esta opción aparecerá siempre que no estemos en la pantalla principal del usuario anónimo y su función al hacer clic con el ratón sobre ella será hacernos viajar a la pantalla principal del usuario anónimo. • Registrarse: Esta entrada en el menú es también un enlace y su misión será la de hacernos viajar a la página en la que un usuario anónimo obtiene una cuenta en Subastland con una serie de privilegios, convirtiéndose en usuario registrado. Esta opción del menú no estará disponible cuando el usuario se encuentre en la pantalla de registro. Fig 8 Menú de navegación anónimo 100 • Categoría y Provincia: Estas opciones son algo distintas a las opciones anteriores. Para estas dos opciones no haremos una navegación a una ventana nueva, sino que presionar alguno de estos enlaces nos abrirá un nuevo submenú que contendrá en el caso de Categoría las distintas categorías de los actuales objetos en subasta y en el caso de Provincia las distintas provincias de las actuales subastas inacabadas (la figura 9 refleja un ejemplo de ambos menús abiertos y cerrados). Para navegar a una página con sólo las subastas de una cierta categoría o provincia haremos clic en el nombre de dicha categoría o provincia. • Login: Además de todas estas opciones mencionadas, en la parte superior vemos la opción de login, donde un usuario que posea una cuenta en Subastland podrá entrar en dicha cuenta en cualquier momento, aportando su email y su contraseña de manera correcta y presionando el botón entrar. En caso de error, el navegador nos redireccionará a la ventana de error en el login donde deberemos volver a intentarlo y en la que se nos especificará que error detecto el sistema (figura 10). Fig 9 Menús desplegables en categoría y provincia 101 • ¿Administrador? Clic Aquí: Esta última palabra (Aquí) será un enlace para que el usuario pueda acceder al sistema como administrador. Siempre y cuando el usuario tenga una cuenta de administrador, podrá navegar a la interfaz de login del administrador (figura 11) donde podrá introducir su email y contraseña y entrar a su sección presionando el botón “Entrar”. Fig 10 Pantalla de error de login del registrado Fig 11 Pantalla de login del administrador 102 Tras ver esta zona de la página, veremos la zona de búsqueda y su manera de utilizarla. Esta zona se encuentra en la parte superior de la pantalla y la forma de utilizarla es introducir lo que deseamos buscar en el cuadro de texto y presionar el botón buscar. Al presionar este botón, el portal realizará esta búsqueda y obtendrá como resultado todas aquellas subastas que contengan la palabra o palabras introducidas dentro del nombre del artículo subastado. Dado que el menú lateral y el de búsqueda son comunes en todas las páginas del anónimo, comentaremos de ahora en adelante la zona de información que se muestra y como interactuar con ella en el resto de las páginas del usuario anónimo. Página principal Cuando el usuario acceda por primera vez a Subastland se encontrará con la interfaz que podemos apreciar en la figura 12. El contenido de esta interfaz será el de mostrar las últimas ofertas introducidas en el portal en páginas de diez ofertas, permitiéndonos observar detalladamente cada una de ellas haciendo clic en su imagen, cosa que nos hará viajar a la interfaz de la subasta que comentaremos más adelante. Cuando el número de ofertas exceda las diez visibles, aparecerá bajo éstas un número de página que nos conducirá a la página siguiente en la que podremos ver más resultados (figura 13). Fig 12 Pantalla de la página principal del an ónimo 103 Página Provincia La información que aparecerá en esta página será distribuida de la misma forma que la de la página principal, a diferencia de que las subastas que aparecerán en ésta serán las asociadas a la provincia que el usuario eligió en el menú de navegación. Estas subastas serán ordenadas por fecha de publicación y se podrá navegar a su información de la misma manera que en la interfaz principal, presionando con el botón izquierdo del ratón en su imagen. Fig 13 Paginación en caso de excesivos resultados 104 Página Categoría La interfaz categoría tendrá dos visualizaciones distintas. La primera visualización será la misma que en la interfaz de página principal y provincia, subastas de la categoría seleccionada ordenadas por fecha de publicación. La segunda será la visualización al elegir la categoría “Intereses”. Esta categoría recibe un trato especial, ya que en ella no se pretende vender nada, sino solo informar de algo que un usuario busca. En la figura 15 podemos apreciar como veremos el nombre de la oferta (que será un enlace para ver plenamente sus características en la interfaz de interés) y atributos como la fecha de fin, la provincia en la que lo busca y el nombre del usuario que está interesado. Fig 14 Página de subastas en la provincia de Cuenca 105 Página Registro En esta página el usuario deberá rellenar el formulario de registro para poder convertirse en usuario registrado. Este formulario (figura 16), requerirá una serie de campos obligatoriamente, que serán dirección de correo electrónico, contraseña (que habrá que introducir dos veces para verificar) nick con el que será reconocido en el sistema y provincia a la que pertenece el usuario. Como información optativa se permitirá que el usuario introduzca un número de teléfono con el cual contactarle si fuera necesario en alguna de sus ofertas. Fig 15 Lista de resultados en la categoría intereses Fig 16 Formulario de registro de usuarios anónimos 112 botón con el nombre de “Liberar Baneo” que en caso de ser pulsado, eliminará el baneo y notificará de ello al usuario. Página Añadir Administrador En esta página el usuario deberá rellenar el formulario de registro para poder crear otro usuario de tipo administrador. Este formulario (figura 25) requerirá una serie de campos que serán dirección de correo electrónico y contraseña (que habrá que introducir dos veces para verificar). La contraseña será restringida como un mínimo de seis caracteres y las dos contraseñas deberán ser idénticas. Por último, el correo electrónico deberá no estar ya registrado y contener el carácter “@”. Interfaz Producto Véase sección “Interfaz Producto” en el tipo de usuario anónimo. Fig 24 Listado de usuarios baneados Fig 25 Formulario de registro de administradores 113 Usuario Registrado Zonas comunes En primer lugar veremos una de las pantallas que pertenecen al registrado (figura 26) e identificaremos las zonas comunes que habrá en todas las páginas de este usuario. Igual que veíamos en el anónimo podemos apreciar tres partes: • Zona de navegación (zona de la izquierda). • Zona de búsqueda (zona superior). • Zona de información (zona central). En este caso, la zona de navegación será distinta de la los usuarios mencionados anteriormente y esta vez se compondrá de un subconjunto de las opciones que se ven en la figura 27. Fig 26 Interfaz del usuario registrado 114 • Inicio: Esta opción aparecerá siempre que no estemos en la pantalla principal del usuario registrado y su función al hacer clic con el ratón sobre ella será hacernos viajar a la pantalla principal del usuario registrado. • Mi Perfil: Esta entrada en el menú es también un enlace y su misión será la de hacernos viajar a la página en la que un usuario ve todos los datos referentes a su cuenta, como veremos mas adelante. Cuando un usuario esté en la página de su perfil no verá este enlace en el menú de navegación • Categoría y Provincia: Estas opciones son algo distintas a las opciones anteriores. Para estas dos opciones no haremos una navegación a una ventana nueva, sino que presionar alguno de estos enlaces nos abrirá un nuevo submenú que contendrá en el caso de Categoría las distintas categorías de los actuales objetos en subasta y en el caso de Provincia las distintas provincias de las actuales subastas inacabadas (la figura 28 refleja un ejemplo de ambos menús abiertos y cerrados). Para navegar a una página con sólo las subastas de una cierta categoría o provincia haremos clic en el nombre de dicha categoría o provincia. Fig 27 Menú de navegación del usuario registrado 115 • Cerrar Sesión: Esta será la opción que tenga que ejecutar el usuario registrado para poder abandonar la página Web cerrando su sesión de manera correcta. Al presionar este botón será devuelto a la página principal del usuario anónimo. Página Principal Cuando el usuario acceda por primera vez a Subastland se encontrará con la interfaz que podemos apreciar en la figura 29. El contenido de esta interfaz será el de mostrar las últimas ofertas introducidas en el portal en páginas de diez ofertas, permitiéndonos observar detalladamente cada una de ellas haciendo clic en su imagen, cosa que nos hará viajar a la interfaz de la subasta que comentaremos más adelante. Fi g 28 Menús de categoría y provincia plegados y desplegados 116 Cuando el número de ofertas exceda las diez visibles, aparecerá bajo éstas un número de página que nos conducirá a la página siguiente en la que podremos ver más resultados (figura 30). Fig 29 Página principal del usuario registrado Fig 30 Paginación de resultados en la interfaz del registrado 117 Página Provincia La información que aparecerá en esta página será distribuida de la misma forma que la de la página principal, a diferencia de que las subastas que aparecerán en ésta serán las asociadas a la provincia que el usuario eligió en el menú de navegación. Estas subastas serán ordenadas por fecha de publicación y se podrá navegar a su información de la misma manera que en la interfaz principal, presionando con el botón izquierdo del ratón en su imagen. Página Categoría La interfaz categoría tendrá dos visualizaciones distintas. La primera visualización será la misma que en la interfaz de página principal y provincia, subastas de la categoría seleccionada ordenadas por fecha de publicación. La segunda será la visualización al elegir la categoría “Intereses”. Esta categoría recibe un trato especial, ya que en ella no se pretende vender nada, sino solo informar de algo que un usuario busca. En la figura 32 podemos apreciar como veremos el nombre de la oferta (que será un enlace para ver plenamente sus características en la interfaz de interés) y atributos como la fecha de fin, la provincia en la que lo busca y el nombre del usuario que está interesado. Fig 31 Interfaz de provincia con las subastas de la provincia de “Cuenca” 118 Interfaz interés En esta interfaz (figura 33) el usuario podrá ver los detalles de la oferta de tipo interés sobre la que presionó. En esta interfaz se mostrarán el título de aquello que interesa al usuario, las fechas entre las que le interesaría conseguirlo y la provincia en la cual lo esta buscando. Se mostrarán también los datos del usuario que lo busca y una descripción bajo todo esto donde podrá explayarse y describir con más precisión lo que le interesa. Fig 33 Inf ormación encontrada en la interfaz interés Fig 32 Lista de resultados en la categoría intereses 119 Interfaz subasta La interfaz que vemos en la figura 34 nos muestra aquello que veremos en la zona de información cuando hagamos clic en la imagen de uno de los artículos en subasta. Para cada artículo, el portal nos mostrará el nombre del artículo que se vende, las fechas entre las que se comprende la subasta, la provincia y categoría a la que pertenece el artículo, El tipo de venta que tiene asociada y el precio inicial y mínimo establecido por el vendedor. Como información del vendedor veremos su nick, su email y su teléfono. Dado que es interesante ver el estado del objeto a subastar podremos ver las imágenes que el vendedor coloque en el portal que se espera sean del producto que vende. En caso de no colocar imágenes aparecerá una imagen denominada “Sin Foto”. En caso de haber varias imágenes podremos ver cada una de ellas en grande pinchando sobre ella. Debajo de las imágenes aparecerá una descripción en profundidad del artículo en venta. Fig 34 Interfaz del producto del usuario registrado 120 Debajo de ésta descripción veremos dos secciones nuevas que no poseían los otros usuarios. En primer lugar veremos la sección de puja que dependerá del tipo de oferta que sea (figura 35). En primer lugar en las ofertas de “compra precio exacto” simplemente compraremos el producto pulsando el botón “Comprar Ya”, en caso de subasta abierta, veremos un precio de puja máximo hecho y tendremos que superarlo para poder ganar y en el caso de subasta cerrada solo tendremos que superar el precio que establece el comprador para poder pujar por el artículo en la subasta. En segundo lugar tendremos la opción de denunciar un artículo ya sea por mala categorización o por posible fraude. Pulsando el botón “Categoría Equivocada” se nos abrirá la ventana de la figura 36 donde introduciremos la categoría que creemos más adecuada y pulsaremos en el botón “Enviar”. Pulsando el botón “Fraude” se abrirá en este caso una ventana como la de la figura 37 donde introduciremos el motivo por el que creemos esta subasta es fraudulenta y presionaremos el botón “Enviar”. Fig 35 Interfaces de puja de los tres tipos de subastas Fig 36 Interfaz de denuncia por descategorizació n 121 Por último aparecerán una serie de comentarios hechos por usuarios registrados que podremos leer. Para cada comentario veremos quien lo hizo y en que momento y, en caso de que valorara el artículo, veremos la puntuación que le otorgó. Debajo de todos los comentarios podremos escribir nuestro propio comentario asociándole a éste una valoración o no según gustemos y publicándolo en el muro con el botón publicar. Página Perfil Esta interfaz nos mostrará un conjunto de acciones posibles a realizar dentro de nuestro espacio personal. Pinchando en cada uno de los iconos que vemos en la figura 38 podremos navegar a cada una de estas secciones y gestionar desde dentro lo que en ellas se ve o publica en el portal. Como información se puede apreciar que se verá el nick del registrado, la provincia a la que pertenece y el teléfono que introdujo cuando se registró en el portal. Fig 37 Interfaz de denuncia por fraude Fig 38 Zona de información de la interfaz del perfil de usuario registrado 128 Para cada una de estas pujas, el usuario podrá observar el nombre de la subasta, el intervalo de fechas en el que tendrá lugar, el tipo de subasta que es, el precio con el que pujamos por ella y la categoría a la que pertenece. Podremos navegar a la página del artículo haciendo clic sobre la imagen de la subasta y como última acción tendremos la autoridad para cancelar dicha puja en cualquier momento, siempre y cuando la fecha de fin no haya sido cumplida.