Blog de cyberHotel unos días parado

Hola, lamento comentar que estos días el Blog de cyberHotel estará más parado de lo normal. En cuanto pueda volveré a introducir nuevas entradas sobre cyberHotel y su evolución. Pido disculpas a todas aquellas personas que atentamente están interesadas en el tema. Espero no tardar mucho en darle actividad al blog.

Saludos y disculpas.

Una versión para Windows

Después de algún tiempo ya tenemos al menos una versión de cyberHotel para utilizar en Windows. Dado que cyberHotel utiliza una BD relacional para almacenar sus datos (lo cual quiere decir que es un medio de almacenamiento seguro y además escalable pués se puede consultar el modelo entidad-relación) necesitamos tener instalado para esta versión el Microsoft SQL Server 2005 Express así como la Máquina Virtual de Java.

Podemos descargar cyberHotel para windows desde la forja. La versión actual para descargar es todavía una versión alfa.

Para que cyberHotel funcione es necesario además tener ant instalado en el equipo, configurar el puerto de SQL Server y crear la BD sobre el gestor. Comentaremos como se puede hacer esto en el siguiente post.

Un logo para cyberHotel

Ahora que cyberHotel está ya en la última iteración de su desarrollo podemos buscarle un logo, algo que sea representativo, bonito pero a la vez sencillo.

El logo para cyberHotel es el siguiente:

 

 

Segunda Iteración: Casos de Uso

Los Diagramas de Casos de Uso correspondientes al análisis de la Segunda Iteración pueden verse en la Forja de cyberHotel y los comentarios que se pueden hacer sobre ellos son similares a lo que se ha comentado para los de la Primera Iteración.

Tenemos igualmente los actores Recepcionista(Manager) y Recepcionista(User), solo que esta vez ambos pueden realizar las mismas acciones, dado que los casos de uso de esta iteración abarcan todas las tareas principales de recepción, esto es, sistema de clientes, reservas, entradas, salidas, cargos y gestión del estado de las habitaciones y es necesario que un usuario corriente pueda realizar estas tareas.

Capa Vista: Patrón Singleton

El patrón Singleton o Instancia Única asegura que una clase solo tiene una instancia (un único objeto) y proporciona un punto global de acceso a ella.

Es un patrón muy sencillo que impide la creación de varios objetos de una clase dada, lo que trae como consecuencia un importante ahorro de memoria, pues en muchos casos hay clases de las que no es necesario tener varios objetos, esto ocurre en nuestra capa vista para las clases que representan a muchos de los formularios. Muchos de ellos deben de estar presentes en la aplicación una única vez, de forma que el usuario no puede mostrar una determinada ventana varias veces, pues esto, además de carecer de sentido, traería asociado un coste de memoria innecesario.

Particularmente en Java el patrón Singleton se puede implementar de diversas maneras:

Instanciación bajo demanda: Una sentencia condicional en el método de creación del objeto evalúa si este ya existe o no.

Instanciación automática: Se elimina la sentencia condicional y cuando se carga la clase por primera vez en memoria se crea este.

Sin instancia: Java nos permite trabajar con clases sin necesidad de instanciarlas. Esta nueva implementación conserva la idea pero no su estructura, ya que aquí realmente no hay una instancia. El Singleton es una clase con métodos y atributos estáticos y nunca llega a existir un objeto.

Las tres ideas son igualmente válidas para implementar un Singleton en Java, en los dos primeros casos disponemos de un método estático para crear la instancia, y luego accedemos a los métodos, por ejemplo:

Singleton s = Singleton.getInstance();
s.metodo();

En el tecer caso, no podemos guardar referencias al objeto como en los casos anteriores porque el objeto no existe, así que las invocaciones a métodos serán todas del tipo:

Singleton.metodo();

Para los formularios nos hemos decantado por el primer caso de instanciación.

Un ejemplo de uso del patrón Singleton para un formulario:

 

Capa Vista: Patrón Observador

El patrón Observador (Observer) permite definir una dependencia entre objetos de forma que cuando un objeto cambia de estado, todos sus objetos dependientes son notificados y actualizados.Es un patrón que nos permite definir un sujeto determinado sobre el que tenemos uno o varios observadores, y cuando se produce algún cambio en el sujeto, este notifica a sus observadores para que cambien su estado si es necesario. Los observadores suelen consultar el estado del sujeto, pero en muchos casos pueden actualizarse independientemente del estado del sujeto.Para entender con más claridad este patrón vamos a ver como lo hemos utilizado en cyberHotel. Muchos de los formularios de la aplicación disponen de un panel de utilidades que permite añadir un nuevo elemento, editar un elemento que está siendo consultado, borrar dicho elemento, y también acceder al siguiente y al anterior. Pues bien, para que el formulario responda a los eventos de este panel utilizamos el patrón Observador, de forma que el formulario observa lo que hace el panel, quién actúa como sujeto. Cada vez que el panel ejecuta una acción, el formulario actualiza sus datos en pantalla.Podemos representar gráficamente el sistema:

Interacción Vista-Controlador: Patrón Estrategia

El patrón Estrategia (Strategy) permite que un determinado contexto trabaje con una implementación u otra de un algoritmo sin conocer su implementación concreta.

Para entendernos, pondremos como ejemplo el caso en que utilizamos este patrón en cyberHotel. Muchos de los formularios de la aplicación tienen un botón de Guardar, que nos permite almacenar en base de datos lo que hemos tecleado en el formulario, pero en diversas ocasiones podemos insertar los datos por primera vez, o bien, podemos realizar una actualización de los datos, pues bien, tanto en una ocasión como en la otra el botón simplemente llama a un método que nombramos como save, ¿cómo sabe entonces cuándo guardar y cuándo actualizar? La respuesta es sencilla, simplemente, no lo sabe, lo que ocurre es que este método save funciona mediante el patrón estrategia.

En estrategia tenemos una jerarquía de clases que implementan la estrategia, un contexto que utiliza la estrategia, y un cliente que establece la estrategia al contexto, pues bien, la estrategia son clases del Controlador que derivan de la clase SaveStrategy, nuestro contexto es el formulario que tiene el botón de guardado, y el cliente es otro formulario que establece la estrategia al formulario de guardado en base a la operación que se decida hacer. Todo esto lo vemos más claro gráficamente:

 

Y la representación del patrón:

 

Capa Controlador: Clases Utilidad

En el Controlador en muchos casos hay clases que acceden a las operaciones de las fachadas, para estas lo único que se necesita es un acceso a las operaciones y no es necesario crear objetos de estas clases.

Para este caso echamos mano de clases con métodos static (estáticos) de forma que simplemente accedemos a estas clases de la forma NombreDeLaClase.nombreDelMétodo.

Utilizamos esto para las clases del Controlador que se encargan simplemente de acceder a las operaciones de las fachadas del Modelo que representan a los casos de uso, de esta forma tenemos clases que únicamente llaman a operaciones.

Un ejemplo de estas clases:

Capas Vista-Controlador

Hemos hablado en anteriores ocasiones de una serie de patrones de diseño que utilizamos para implementar la capa modelo de cyberHotel en las distintas iteraciones, vamos a hablar ahora un poco de los patrones de diseño comunes utilizados para la capa controlador, para la capa vista y para la interacción vista-controlador.

Dado que la aplicación se divide en tres capas siguiendo el patrón arquitectónico Modelo-Vista-Controlador, el Modelo debe de estar totalmente desacoplado del conjunto Vista-Controlador, pues si en un futuro se quieren definir distintas vistas (web, interfaz de PDA, …) no será necesario modificar para nada la lógica de negocio que se encuentra en el modelo. Es decir, tendremos un único modelo al que se puede acceder desde distintos tipos de vistas.

La separación entre Vista y Controlador no es tan acusada, pues cada vista suele llevar asociado su propio controlador dependiendo de la naturaleza de esta, ya que no sería lo mismo un controlador para un entorno de ventanas que para un conjunto de páginas web hechas con JSP por ejemplo, por eso no se reutiliza la capa Controlador. Si bien, la capa Controlador accede al modelo a través de la interfaz que proporcionan las fachadas y conoce determinados objetos como los POJO’s y las propias fachadas, la capa Vista no trabaja en absoluto en términos de objetos de la capa Modelo, por este motivo se utilizarán patrones que permitan establecer un protocolo de comunicación entre Controlador y Vista.

Dado que la Vista es una interfaz de ventanas desarrollada en Swing, tanto esta capa como el Controlador están desarrollados íntegramente en Java utilizando patrones de diseño que son comunes a todas las iteraciones.

Segunda Iteración: Capa Vista

En esta segunda iteración al igual que en la anterior la capa superior o vista está implementada utilizando Java Swing y algunas librerías de SwingX de manera análoga a la primera iteración, pues lo que conseguimos con esta segunda etapa es incrementar la funcionalidad de cyberHotel para la cual necesitamos los formularios del entorno de ventanas que nos permitan realizar todas las funciones relativas a clientes, reservas, entradas, salidas, cargos y planning de habitaciones. Aquí mostramos algunos de estos formularios:

Particulares

Reservas Individuales

Entradas Individuales

Cargos

Planning de Habitaciones