Programación Orientada a Objetos. Curso 08/09

Práctica 4. Programación distribuida y JSF

Duración: Semanas del 04, 11 y 18 de mayo (para detalles ver el calendario de prácticas)

Entrega: 27 de Mayo.
Examen: semana del 27 de mayo (para ver la fecha de cada grupo ver el calendario)

Objetivo

Tras completar la implementación del sistema de gestión de expedientes, se propone extender dicho sistema para su uso de forma distribuida.
El objetivo de esta práctica será crear un servidor que permita acceder a los datos del sistema de forma remota, y crear una intefaz de usuario web que se comunicará con dicho servidor y proporcionará a los usuarios información sobre las notas de las asignaturas y los informes que solicite. Para simplificar el desarrollo de la práctica solo se accederá de forma remota para leer datos, además tampoco se requiere implementar autentificación.

De esta forma el sistema se podrá ejecutar dividido en 3 partes:

1. Servidor de datos: Compuesto por un servidor del sistema que suministrará la información al cliente mediante RMI, y por el nucleo del sistema implementado en la práctica 2. El nucleo del sistema se adaptará añadiendo serialización o capacidad de ejecución remota a las clases que se considere necesario. Se ha de tener en cuenta que el cliente no creará ningún objeto remoto directamente (mediante llamada directa al constructor), de forma que todos los objetos remotos se encuentren siempre en el servidor, y los clientes solo usen las referencias a ellos (stubs).
   
2. Servidor de aplicaciones web:  El servidor web contendrá la interfaz de usuario escrita JSF, que permite ejecutar parte de la interfaz en el servidor web, y parte en el cliente. Esta interfaz de usuario permitirá buscar alumnos, o asignaturas, y una vez encontrados dará la opción de mostrar los informes correspondientes. El servidor web se comunicará con el servidor de datos mediante RMI para obtener la información solicitada. Para simplificar la interfaz web se asumirá que el servidor RMI se encuentra en la misma máquina que el servidor de datos (localhost), siendo innecesario por tanto pedir al usuario los datos de conexión.
3. Navegador: Desde cualquier browser podremos acceder al servidor web para utilizar el sistema.
   

Recursos

Para implementar esta práctica serán necesarios los siguientes recursos:

• Servidor de aplicaciones web: Tomcat 5.0 o superior. En los laboratorios se encuentra instalado tomcat 5.0, que incorpora Servlet 2.4 y JSP 2.0, por lo tanto se aconseja no utilizar características que no estén disponibles en dichas versiones de Servlet o de JSP. Página de Tomcat
  
• Liberias de JSF: Se aconseja utilizar la implementación de referencia. Será necesario incluir como parte de la librería de la aplicación los ficheros .jar necesarios. La versión 1.1 de JSF funciona correctamente en tomcat 5.0, mientras que si se utiliza una versión posterior será necesario incluir además las versiones de servlets y JSP necesarias como parte de la aplicación. Página oficial de JSF
• Otras librerías: Las librerías de servlets y JSP se pueden encontrar junto con la instalación de Tomcat, o como parte de Netbeans en las versiones recientes, incluyendo los módulos de desarrollo J2EE o desarrollo web
• Proyecto Apache MyFaces, implementación de JSF, widgets, y extensiones de JSF: http://myfaces.apache.org/
  
• Material de la práctica: Ejemplos en JSF, librerías adicionales e instrucciones de uso en el laboratorio de prácticas
  

Pruebas

Se creará una intefaz Swing para probar el servidor de datos. Esta interfaz tendrá toda la funcionalidad que después se implementará en la interfaz web. Para añadir información se aconseja emplear la interfaz de usuario de la práctica 3, accediendo al sistema directamente, o crear los datos de prueba mediante código.

Entrega

Las prácticas se deben entregar antes de la fecha de corrección indicada al comienzo del enunciado, teniendo en cuenta las horas límite de entrega mencionadas en las normas de la asignatura. En general, el grupo del lunes tiene hasta las 12 del mediodía del mismo lunes, y todos los demás grupos tienen hasta las 12 de la noche del día anterior a la fecha de corrección.

De nuevo, siguiendo las normas de la asignatura, el fichero .zip a entregar debe incluir:

• un leeme.txt que describa los ficheros incluidos en el .zip
  
• el build.xml usado para compilar y ejecutar la práctica (en general, con el que se entrega con el enunciado vale).
  
• una memoria.{pdf, rtf, odt}. En este caso, la memoria puede ser bastante breve, y basta con que expliquen las ideas principales de la implementación de cada una de las funciones incompletas. También se debe decir si se ha conseguido pasar todos los casos de prueba, o si alguno ha dado fallos. En caso de que se produzcan fallos, se debe explicar cómo se ha intentado resolverlos. Esto sólo vale para esta primera práctica: en la P2, P3 y P4, las memorias deberán seguir otros criterios.
  
• los ficheros de prueba usados para verificar que la práctica funciona. Sobre todo, si se han modificado para probar casos específicos.
• y los fuentes, en un directorio llamado "src" con la estructura de directorios necesaria para que, descomprimiendo el .zip entregado y escribiendo "ant run" (es decir, ejecutando el "build.xml" includido en el .zip), la práctica se compile y ejecute correctamente los casos de prueba.
  

NOTA: Las entregas que no cumplan los requisitos enumerados en las normas recibirán una penalización de 0.5 puntos.

Apéndice: Sobre estas prácticas

Este apartado contiene una serie de reflexiones sobre el enfoque de estas prácticas, porqué se hacen así, y qué se va a pedir en las siguientes prácticas.

Código en los enunciados

Las prácticas de POO se diferencian de otras en que, junto con cada enunciado, se entrega bastante código. Esto se hace por los siguientes motivos:

• Java no es C. Se espera que todos los alumnos tengan un nivel bastante alto de programación en C. La sintaxis de Java es muy similar a la de C, y si las primeras prácticas pidiesen escribir un programa desde cero, el resultado no tendría nada de orientación a objetos. Si se parte de un programa con diseño OO, se evita el riesgo de que todo el programa esté compuesto de métodos "public static".
• Convenciones en Java. hay mucha más uniformidad en cuanto a estilo de programación en Java que en otros lenguajes. Hay convenciones de nombrado de clases y de variables, convenciones sobre los nombres dados a métodos, de formato de comentarios de cabecera, de indentado, de organización en paquetes, etcétera. Es mejor partir de un ejemplo en el que todo está escrito siguiendo estas convenciones que intentar que se apliquen desde cero, son muchas.
• Uso de librerías. Programar en Java tiene un gran componente de saber usar código existente: las librerías disponibles son uno de los puntos fuertes de Java. Esto es menos cierto en C, donde la mayor parte de las librerías son externas (y por tanto, no tan estándares). Es fundamental perder el miedo a las librerías y saber manejar su documentación desde un primer momento.
• OO y Patrones. La orientación a objetos promueve la reutilización no sólo de código, sino también de estrategias de diseño ("patrones de diseño"). Esto se da en mucho mayor medida que en lenguajes menos abstractos, tipo C. En el código que se entrega se hace uso de varios patrones establecidos. La idea es que, desarrollando y extendiendo sobre un buen diseño, se mejora la capacidad de entender y crear buenos diseños.