Programación Orientada a Objetos. Curso 2009/2010

Práctica 2. Clases, herencia y RMI

Objetivos

En esta práctica el alumno se formará en los siguientes conceptos y habilidades:

• Definición e implementación de clases (variables, métodos, constructores, etc.), interfaces y elementos básicos de orientación a objetos, para el desarrollo de un programa.
• Definición de jerarquías de clases, y manejo de los mecanismos asociados a las mismas: herencia, polimorfismo, jerarquía de tipos.
• Transición del diseño abstracto de un programa a una implementación completa.
• Iniciación a la tecnología de objetos distribuidos.

Se implementará un proyecto completo en Java, a partir de un diseño orientado a objetos dado en UML. En una segunda fase, la aplicación se completará con una capa de arquitectura distribuida. Para ello, el alumno tendrá a su disposición:

• Un diagrama de clases en UML: creado por el alumno en la práctica anterior, el cual se puede modificar de acuerdo a las correcciones del profesor y de los errores encontrados por el alumno. Dichas correcciones han de incluirse en la memoria indicando la razón de la modificación.
• Un conjunto de interfaces Java, facilitadas por los profesores, como base para el desarrollo de la práctica. Las interfaces definen un protocolo común entre todas las prácticas entregadas, además de ayudar a pensar en forma orientada a objetos.
• Nota: La interfaz del Servidor permitirá usar el objeto servidor de forma remota mediante RMI, y contiene todos lo métodos que se usarán de forma remota. Estos métodos declaran que pueden producir excepciones del tipo RemoteException, ya que se podrían producir errores de comunicación, serialización, etc.
  

Se valorará un diseño que aplique adecuadamente los principios de orientación a objetos (jerarquías de clase, modularidad, etc.) y haga un uso adecuado de las clases de la librería estándar Java.

Descripción del proyecto

Se implementará completamente el sistema de reserva de entradas de cine diseñado en la práctica anterior (con las rectificaciones oportunas). Se definirán las clases e interfaces Java necesarias, las estructuras de datos y métodos de las clases, desarrollando un programa completo.

El trabajo a realizar incluye las siguientes partes:

1.  Implementación básica

En esta primera fase, se implementará la gestión completa de datos y estructuras, y todos los detalles necesarios de cada clase, necesarios para las funcionalidades básicas del sistema: creación de salas, asignación de sesiones, horarios, reserva de localidades, etc. Partiendo del diagrama y las interfaces suministrados en esta práctica, el programa se desarrollará como una especialización de un sistema abstracto de reserva de recursos. En este caso el recurso puede ser el derecho a una butaca para ver un evento un día y durante un tiempo concreto, si la sesión es numerada; o el sistema podría proporcionar una cantidad de entradas para un evento, un día y durante un tiempo determinado, en el caso de acceso a una sesión no numerada.

La implementación se podrá hacer como una aplicación local (un solo proceso). Las clases se conectarán con las interfaces proporcionadas, pero se podrán ignorar las referencias a elementos RMI que puedan aparecer en éstas, así como la terminología de cliente-servidor.

El eje de la aplicación será un objeto servidor (o cine) que se encargará de ofrecer los recursos disponibles, información sobre los eventos, butacas libres en cada zona, etc. Además permitirá completar el pago de dichas entradas.

Otro tipo de objeto fundamental será el cliente, que ofrecerá al usuario la información del servidor, y permitirá comprar las entradas en dos fases: una de reserva y otra de pago (junto con la compra y reserva definitiva de las entradas una vez realizado el pago correctamente). El usuario cliente se comunicará interactivamente con el programa, por lo que el alumno debe implementar una interfaz que permita realizar estas funcionalidades por línea de comandos.

Otro de los usuarios del sistema es el gestor del cine. Para este usuario se ha de ofrecer una funcionalidad básica adaptada a sus necesidades, para que pueda crear fácilmente cada sala, con sus filas y butacas concretas, dando la menor información posible. Por ejemplo se puede asumir que cada zona de la sala es cuadrada, con un número de filas y las mismas butacas en cada una. Además ha de poder crear las sesiones, por ejemplo especificando un rango de fechas, un intervalo (diario/semanal), la hora de la sesión y el título o código correspondiente al evento.

Para simplificar la aplicación no será necesario que el gestor diseñe los recursos de forma interactiva, sino que estos se podrán fijar directamente mediante código java que ejecutará el servidor al iniciarse, sin interfaz de usuario, aunque se han de diseñar las clases necesarias, para que el método que especifica las salas/eventos requiera el menor código posible.

Se aconseja seguir la convención de paquetes que se incluye en las clases entregadas, es decir: es.uam.eps.poo.

2.  Arquitectura distribuida

En una segunda fase, se dotará al programa de una arquitectura cliente-servidor basada en objetos distribuidos RMI. Los objetos cliente y servidor, implementados en el paso anterior, podrán encontrarse en máquinas distintas. La comunicación entre el cliente y el sistema se adaptará añadiendo capacidad de ejecución remota, o en su caso serialización, a las clases que se considere necesario. Se ha de tener en cuenta que los objetos remotos deberán crearse (llamada directa al constructor) en el lado que les es natural (generalmente servidor, o excepcionalmente cliente), de forma que el otro programa sólo use las referencias a ellos (stubs), o si se considera adecuado en algún caso, copias serializadas. El sistema permitirá a varios clientes acceder a un único servidor.

 Consideraciones:

• Se aconseja al alumno esforzarse en tener el sistema de reservas completamente funcional antes de comenzar esta segunda parte de la práctica.
• Documentación sobre RMI, y ejemplos (cliente, servidor).

3.  Opcional

1. Extender el programa con un servicio central que permita al cliente acceder a distintos cines.
2. Crear un servicio separado para el cobro con tarjeta.
3. Adaptando el diseño, crear otro tipo de sistema de gestión de recursos, como reserva de hoteles, vuelos, o tienda on-line.

Diagrama de clases abstracto

A continuación se muestra el diagrama de clases de la parte abstracta, correspondiente a las interfaces entregadas por los profesores.

Pruebas

Las prácticas entregadas han de cumplir las interfaces entregadas por los profesores. En particular, debería ser posible, dadas las prácticas de las parejas X e Y, intercambiar la parte del cliente de X y que funcione con el servidor de Y, y viceversa.

Por otro lado, no se prevé entregar ningún conjunto de test durante el desarrollo de esta práctica, pero se recomienda a los alumnos que implementen, ejecuten, entreguen y documenten tantos casos de prueba como crean necesarios.

Entrega

Las prácticas se deben entregar antes de la fecha de evaluación indicada al comienzo del enunciado, teniendo en cuenta las horas límite de entrega mencionadas en 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 (generado por netbeans o creado manualmente).
  
• una memoria en pdf y un directorio javadoc con la documentación generada para cada clase.
  
• 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.

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