Programación Orientada a Objetos. Curso 2009/2010

Práctica 1. Introducción al lenguaje Java

Objetivo

El objetivo de la primera práctica es aprender la sintaxis básica de Java (asumiendo experiencia en C) y adquirir familiaridad con el entorno de desarrollo NetBeans. Las dos primeras prácticas del curso consistirán en implementar un sistema de gestión de reserva de recursos por internet. En la primera práctica el alumno deberá analizar el problema que se plantea y crear en java el esqueleto de sus primeras clases, sin código en los métodos ni variables.

El sistema de reserva de recursos se ha de diseñar como un sistema abstracto, y se crearán las clases necesarias para que pueda ser usado como un sistema de venta de entradas que permita a varios clientes acceder a un único servidor. En este caso el recurso puede ser el derecho a una butaca para ver un espectáculo 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 espectáculo, un día y durante un tiempo determinado, en el caso de acceso a una sesión no numerada. Por lo tanto, algunos recursos como las salas, podrían poder dividirse en varios subrecursos (zonas/butacas en sesiones numeradas), o ser usados simplemente con un número de unidades disponibles (no numerado).

El servidor se encargará de ofrecer los recursos disponibles, información sobre los espectáculos, butacas libres en cada zona, etc. Además permitirá completar el pago de dichas entradas.

El cliente ofrecerá esta información al usuario y permitirá reservar las entradas necesarias en una primera fase, y en una segunda fase pedir la información al usuario para realizar el pago y reservar definitivamente las entradas una vez realizado correctamente.

Otro de los usuarios del sistema es el gestor del cine/teatro. 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 zonas, 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 espectáculo.

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/espectáculos requiera el menor código posible.

Los mensajes en este sistema cliente/servidor son llamadas a métodos Java de los objetos en el servidor desde objetos en el cliente, será la máquina virtual la que realize toda la comunicación y transformaciones necesarias cuando detecte que el objeto destino del mensaje se encuentra en otra máquina virtual.

Para que el cliente pueda encontrar al servidor se supondrá que tenemos un método que dada la IP y un nombre dado a nuestro objeto servidor, podemos obtener una referencia a este, que podrá ser utilizada en adelante como si se el objeto remoto estuviese realmente en la misma máquina virtual que el cliente.

Diagrama de clases

Se entregará un diagrama de clases con el diseño del sistema.

En esta primera práctica se puede suponer que la aplicación se ejecuta en un mismo espacio de memoria, por lo tanto no se considerarán los problemas propios de las comunicaciones cliente/servidor, y el diagrama contendrá el diseño del sistema como si fuese una sola aplicación. Sin embargo, sí será necesario tener en cuenta que la comunicación entre el cliente y servidor ha de ser sencilla y eficaz, reduciendo al máximo el número de mensajes que se intercambiarán y la complejidad o tamaño de los objetos enviados/recibidos (argumentos/resultados de los métodos de los objetos remotos).

Clases a implementar

En la primera práctica el alumno deberá crear las clases diseñadas, exceptuando las relativas a interfaz de usuario. Estas clases no contendrán código ni variables, pero sí la documentación JavaDoc para poder generar una memoria html que describa cada clase y método diseñado.
Las clases tendrán los métodos getters / setters necesarios para las propiedades de cada clase. Para que puedan ser compilados se puede incluir un retorno de algún valor trivial (null, 0, "", etc.), en el caso de que el métodos que devuelven algún valor.

También se ha de crear una clase MainServidor, con un método main que ilustre con un ejemplo sencillo como sería el código para crear los recursos.

Pruebas y 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 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, por qué 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.