Home UC3M
Home IT
Home /Docencia /Ing. Técnico de Telecomunicación Esp. Telemática /Laboratorio de Aplicaciones Telemáticas /FotoWeb
anterior siguiente

Práctica: FotoWeb

Fecha: 6, 7, 20, 21, 27 y 28 de noviembre de 2003
Conceptos: servlets, JSP, JavaBeans, bases de datos
Plazo de entrega: 11 de diciembre de 2003
Profesores: Jesús Arias Fisteus

 INTRODUCCIÓN

Introducción

Esta práctica consiste en el desarrollo de una aplicación web de gestión de fotografías personales de usuarios. La aplicación debe permitir a un usuario gestionar sus fotografías en el servidor, agrupadas en carpetas. La aplicación debe ser multiusuario.

Arquitectura de la aplicación

La arquitectura de la aplicación estará compuesta por tres sistemas:

  • Gestor de fotografías: proporciona al cliente interfaz web para trabajar. Utiliza una base de datos para almacenar información de usuarios y fotografías. Debe ser implementado utilizando servlets y JSPs.
  • Base de datos: almacena la información en tres tablas: una tabla de usuarios, una de carpetas y otra de fotografías.
  • Agente de usuario: permite al usuario interactuar con el gestor de fotografías. Puede ser cualquier navegador con soporte para XHTML, CSS y cookies.

Descripción de la aplicación

El usuario dispondrá de un conjunto de carpetas. Si lo desea, puede tanto crear nuevas carpetas como borrarlas. Una carpeta sólo puede contener fotografías. En ningún caso se puede anidar una carpeta dentro de otra.

Toda la información relativa a usuarios, carpetas y fotografías reside en la base de datos. Sin embargo, los ficheros que contienen las fotografías se almacenarán en el sistema de ficheros del servidor web. Se recomienda que este sea un subdirectorio dentro del directorio que contiene la aplicación web. De esta forma, los ficheros tendrán una URL asociada. La aplicación sólo necesita escribir las URLs de las fotografías en los elementos img de las páginas que genere, y el cliente las descargará.

Usuarios

La aplicación debe ser capaz de gestionar carpetas y fotografías de cualquier número de usuarios. Para ello, debe almacenar por lo menos la siguiente información de cada usuario. Puede almacenar datos adicionales que creas adecuados:

  • Login: nombre corto asignado al usuario.
  • Clave: clave de acceso del usuario. Por simplicidad, aunque no es una política recomendable, se almacenará en claro (sin cifrar) en la base de datos.

Carpetas

Las fotografías de un usuario se organizan mediante carpetas. La aplicación debe permitir sólo un nivel de carpetas. Cada carpeta debe tener como mínimo la siguiente información, aunque puede tener información adicional que creas conveniente:

  • Nombre: nombre de la carpeta.
  • Descripción: descripción de la carpeta.

Fotografías

El servidor debe almacenar, como mínimo, la siguiente información para cada fotografía, aunque puede tener más, si lo crees conveniente:

  • Nombre: nombre de la fotografía.
  • Descripción: descripción de la fotografía.
  • Tamaño: tamaño del fichero en bytes.
  • Carpeta: carpeta a la cual pertenece.
  • Ruta: nombre de fichero en el servidor en el cual se almacena.

Requisitos

La aplicación debe cumplir, además de los explicitados en el resto de este documento, los siguientes requisitos:

  • Todos los documentos HTML generados por la aplicación deben ser XHTML 1.1.

Recomendaciones de diseño

Se valorará la elegancia y sencillez del diseño de la aplicación. Por ejemplo, es recomendable:

  • Diseñar una clase que aísle a la aplicación del acceso a la base de datos, proporcionando una interfaz clara y sencilla. Esta clase, si está adecuadamente diseñada, podrá ser reutilizada en la segunda parte de la asignatura.
  • Diseñar una o varias clases que encapsulen información de carpetas, fotografías y usuarios, y que puedan ser usados como JavaBeans en las páginas JSP.
  • Diseñar uno o varios servlets que realicen las operaciones del usuario. Es recomendable que las páginas JSP se empleen únicamente para la representación de datos, conteniendo la menor cantidad de código Java posible.
  • Diseñar las consultas a la base de datos para minimizar el código necesario para ordenar/seleccionar los datos.


 MÓDULO 1

Se pide:

Desarrollar un conjunto de páginas JSP, JavaBeans y servlets que proporcionen las siguientes operaciones:

  1. Control de acceso. Sólo los usuarios registrados deben ser capaces de acceder a la aplicación. Para ello, es necesario que el usuario introduzca su nombre de usuario y su clave. No debe ser necesario autenticarse de nuevo a no ser que expire el tiempo de la sesión (10 min.) o el usuario indique que desea desconectarse. Un usuario sólo puede tener acceso a sus propias fotografías y carpetas.
  2. Vista de carpetas. La aplicación debe proporcionar al usuario una página de visualización de sus carpetas. Para cada carpeta se debe mostrar al menos su nombre y descripción. Si el usuario selecciona una carpeta, debe pasar a la vista de fotografías de dicha carpeta.
  3. Vista de fotografías. En esta vista la aplicación muestra todas las fotografías, en miniatura, de su carpeta seleccionada. Para cada fotografía debe aparecer, al menos, su nombre, descripción y tamaño. Si el usuario selecciona una fotografía, la aplicación debe mostrarla a tamaño real.
  4. Añadir nueva carpeta. Permite al usuario crear una nueva carpeta, inicialmente vacía. Debe comprobar que no exista una carpeta del mismo usuario con el mismo nombre.
  5. Eliminar carpeta. Permite al usuario eliminar una carpeta.
  6. Añadir nueva fotografía. Permite al usuario subir una nueva fotografía al servidor. El usuario debe seleccionar en qué carpeta desea guardarla, así como su nombre y descripción. La aplicación debe comprobar que no exista otra fotografía en la misma carpeta con el mismo nombre.
  7. Eliminar fotografía. Permite al usuario eliminar una fotografía.
  8. Cerrar sesión. Si el usuario cierra la sesión, la aplicación debe volver a la página de control de acceso. El usuario no podrá volver a acceder a la aplicación hasta que no se autentique de nuevo.


 MÓDULO 2 (opcional)

Control de cuotas de usuario

Esta funcionalidad permite limitar el espacio ocupado por las fotografías de un usuario. A cada usuario se le asignará una cuota cuando se le da de alta. En todo momento, la suma del espacio ocupado por sus fotografías debe ser inferior a su cuota. Por tanto, la aplicación debe rechazar la creación de fotografías cuando dicha creación suponga que se sobrepase la cuota del usuario. La aplicación no puede suponer una cuota igual para todos los usuarios, sino que debe permitir que a distintos usuarios se les asignen distintas cuotas.

El usuario debe disponer, en las vistas de carpetas y fotografías, de información acerca de su cuota y espacio total utilizado.

Creación de mini-fotografías

Los atributos width y height del elemento img indican al navegador el tamaño con el que debe mostrar las imágenes. Sin embargo, la imagen se transmite a tamaño completo por la red, y es el navegador el que realiza el escalado.

Para reducir el tráfico generado por la aplicación, cada vez que el usuario suba una fotografía al servidor se debe almacenar en disco dos versiones de dicha imagen:

  • Versión a tamaño real: almacena la fotografía que ha subido el usuario.
  • Versión a tamaño reducido: almacena una versión escalada muy reducida de la fotografía subida por el usuario. La aplicación debe generar esta versión reducida mediante la biblioteca de clases de procesado de imágenes que creas más adecuada.

La imagen de tamaño real debe utilizarse sólo para la visualización de la fotografía completa. En el modo de visualización de todas las fotografías de una carpeta, la aplicación debe transmitir por la red sólo las fotografías de tamaño reducido.



 APÉNDICE 1: gestor de bases de datos MySQL

Para el desarrollo de esta práctica, debe utilizarse el gestor de bases de datos MySQL instalado en alumnos.lab.it.uc3m.es.

  1. Cada grupo dispondrá de un nombre de usuario y clave para acceder al gestor, desde cualquier máquina del dominio lab.it.uc3m.es.
  2. Cada grupo dispondrá de una base de datos, inicialmente vacía, donde debe crear sus tablas e introducir datos.
  3. Con el fin de facilitar la corrección de la práctica, en la fecha de vencimiento del plazo de entrega la base de datos de cada grupo debe contener suficientes datos para realizar pruebas.
  4. Para conectarte al gestor y realizar tareas de administración sobre la base de datos (creación de tablas, introducción de datos, etc.) se puede utilizar el cliente MySQL. Debes invocarlo con los siguientes parámetros: mysql -h alumnos.lab.it.uc3m.es -u usuario -p. Se obtiene un entorno interactivo para introducir comandos. Es recomendable consultar este manual de MySQL, especialmente este apartado introductorio.
  5. Para establecer una conexión con la base de datos desde una aplicación java, es necesario utilizar un conector JDBC para MySQL. Puedes descargar MySQL Connector/J 2.0 e instalar el fichero JAR en el directorio common/lib de Tomcat. Para realizar la conexión, se puede utilizar el siguiente código:
    	try {
    	    Class.forName("com.mysql.jdbc.Driver").newInstance();
    	    java.sql.Connection conn= DriverManager.getConnection
    		  ("jdbc:mysql://host/base_de_datos", "usuario", "clave");
    	}
    	catch (SQLException ex) {
               ...
    	} 
    	catch (Exception ex) {
               ...
    	}
    


 APÉNDICE 2: formularios multipart/form-data

La API de Servlet 2.3 no permite gestionar los parámetros recibidos con codificación multipart/form-data. Dado que esta codificación es la más conveniente para subir ficheros al servidor, debes utilizar alguna API añadida que sí lo permita. A continuación se presentan dos alternativas:

  • Biblioteca de clases com.oreilly.servlet: conjunto de clases que nacieron como ejemplos del libro Java Servlet Programming de Jason Hunter (disponible en la biblioteca). El libro contiene hay ejemplos de utilización.
  • FileUpload 1.0 de Jakarta. Biblioteca de clases que gestionan los parámetros recibidos como multipart/form-data.

El siguiente código ilustra la recepción de ficheros utilizando com.oreilly.servlet. Dado que la biblioteca almacena los ficheros en el directorio temporal especificado por la aplicación, podría ser útil moverlos a un directorio y nombre distintos:

// crea una instancia
MultipartRequest multipart = new MultipartRequest(request, directorioTemporal);

// obtiene el valor de otros parámetros del formulario
String nombre = multipart.getParameter("nombre");
String descripcion = multipart.getParameter("descripcion");

// obtiene el fichero 
File ficheroTemp = multipart.getFile("foto");

// crea un nuevo nombre para el fichero y lo renombra
String nuevaRuta = ...;
File fichero = new File(nuevaRuta);
ficheroTemp.renameTo(fichero);


 CRITERIOS DE CORRECCIÓN

División en módulos:

FUNCIONALIDAD OBLIGATORIA (MÓDULO 1)
1.- Control de acceso
2.- Vista de carpetas
3.- Vista de fotografías

FUNCIONALIDAD OPCIONAL (MÓDULO 1)
4.- Añadir nueva carpeta
5.- Eliminar carpeta
6.- Añadir nueva fotografía
7.- Eliminar fotografía
8.- Cerrar sesión

FUNCIONALIDAD OPCIONAL (MÓDULO 2)
A.- Control de cuotas de usuario
B.- Creación de mini-fotografías

Criterios de corrección:

Toda entrega que implemente correctamente la funcionalidad obligatoria (1,2 y 3) se considera aprobada con una calificación de 5.

Si la aplicación implementa la funcionalidad obligatoria, se obtendrá mayor calificación implementando funcionalidades opcionales del módulo 1 (hasta un 8).

Si la aplicación implementa todas las funcionalidades obligatorias y opcionales del módulo 1, se obtendrá mayor calificación implementando funcionalidades opcionales del módulo 2 (hasta un 10).

Además se valorarán positivamente (incrementando la calificación con respecto a los máximos anteriores) aquellas prácticas con un buen diseño y estilo de programación, y una buena gestión de errores. No se valorará ni positiva ni negativamente el aspecto visual (diseño gráfico) de la aplicación.



 REFERENCIAS

Especificaciones:

Otros:

Software:



Última actualización:

Localización |Personal |Docencia |Investigación |Novedades |Intranet
inicio | mapa del web | contacta