cyberHotel con vistas al swing

 

Para ver por fin la capa superior de cyberHotel mostramos a continuación una serie de capturas de pantalla de la interfaz gráfica de usuario desarrollada con Swing, las librerías más populares de Java para entornos de escritorio y utilizando también componentes de SwingX.

Algunas pantallas que podemos ver en la primera iteración de cyberHotel son las siguientes:

Direcciones

Bancos

Habitaciones

Tarifas

Temporadas

Capa Vista: Swing y SwingX

Una vez tenemos el modelo desarrollado en el cual se encuentra toda la lógica de negocio de nuestra aplicación, podemos acceder a él a través de algún tipo de cliente, que en este caso estará constituido por las capas vista y controlador. La capa vista será la que permita al usuario interaccionar con la aplicación, por lo que se podría tratar tanto de un sistema por comandos, un entorno de ventanas, una aplicación web, un entorno de una PDA, etc.

En nuestro caso vamos a desarrollar un entorno de ventanas de escritorio, de modo que a través de una serie de formularios podremos interactuar con la aplicación. Dado que estamos trabajando con Java, utilizaremos el entorno de ventanas Swing. Además, existe una extensión llamada SwingX, que incluye una serie de extensiones que nos facilitará la creación de algunos elementos gráficos, como por ejemplo, calendarios. Además SwingX está bajo licencia LGPL.

Ya habíamos dicho que cyberHotel debe de ser internacionalizable, por lo que, para tal fin, se podrá escoger el lenguaje en que queremos que se muestre el programa, para ello, todo el sistema de etiquetas y mensajes busca los textos sobre un archivo de configuración, que inicialmente tenemos en español.

En el post que vendrá a continuación, se mostrarán algunos de los formularios que hemos desarrollado para la capa vista de la primera iteración.

Capa Modelo: Detallando a fondo II

Hablaremos ahora del patrón de acceso a datos DAO y veremos sus particularidades utilizando Hibernate combinado con Spring. El DAO implementa siempre las operaciones básicas de acceso a datos, como por ejemplo: insertar, buscar, actualizar y borrar, entre otras. Generalmente estas operaciones se lanzan como sentencias sobre la base de datos y si utilizásemos simplemente JDBC se lanzarían como sentencias SQL embebidas en el código Java. Gracias a utilizar Hibernate no necesitamos incluír SQL en el código, y esto supone una ventaja por varios aspectos, pero principalmente porque podemos seleccionar el motor de base de datos que querramos utilizar dado que el SQL que estos implementan no siempre sigue el estándar, además muchas veces suele ser engorroso.

Si utilizamos Spring integrado con Hibernate disponemos de una clase HibernateDaoSupport en la que se incluyen las operaciones básicas de acceso a datos y también otros métodos para poder ejecutar sentencias más complejas, que muchas veces necesitaremos, estas sentencias se incluirán en los ficheros hbm.xml de mapeo, escritas en HQL (el sql de hibernate).

En cyberHotel hemos creado una clase que hereda de HibernateDaoSupport que hemos nombrado AbstractSpringDao y todos los DAO’s heredan a su vez de esta última (en los libros se suele denominar patrón Layer Supertype).

Para que todo funcione el fichero applicationContext.xml deberá de estar correctamente configurado, de forma que los DAO’s conocen los distintos ficheros de mapeo.

Todos los DAO’s se ocultan mediante el patrón Fachada que hemos mencionado en un post anterior, que utilizará estos para implementar la lógica de negocio de la aplicación y ocultará también las tecnologías empleadas, proveyendo al modelo de una interfaz hacia las demás capas (vista y controlador) que actuarán como clientes del modelo.

Un ejemplo de DAO en cyberHotel es el siguiente:

 

Capa Modelo: Detallando a fondo

En el post anterior comentamos los patrones que se utilizan para toda la fase de diseño de la capa modelo de la aplicación, son patrones por lo general conocidos y que se pueden consultar en muchos libros dedicados a los patrones de diseño de software y en multitud de sitios por internet como por ejemplo en Wikipedia, también hemos mencionado ciertas particularidades de los patrones al utilizar Hibernate y Spring, por lo tanto sería conveniente que detallásemos un poco más acerca de los patrones y de como funcionan integrados con estas tecnologías:

Hibernate es un mapeador objeto-relacional por lo tanto nos permite trabajar con la base de datos en términos de objetos directamente y además nos evita que utilicemos SQL, el cuál no es estándar para todas las bases de datos, de este modo podemos utilizar cualquier base de datos reconocida por hibernate. Para que hibernate funcione tenemos que establecer la relación entre tablas de la base de datos y las clases de persistencia, estas clases de persistencia son lo que en el apartado anterior hemos denominado POJO’s; para relacionar por lo tanto POJO’s con tablas se utilizan ficheros de mapeo en formato XML que por lo general se nombran: NombreDeLaClase.hbm.xml. Se suele crear uno por clase y se guardan en el mismo sitio que la propia clase. Posteriormente desde applicationContext.xml se hace referencia a todos los ficheros de mapeo.

De esta forma ya podemos trabajar con nuestra base de datos pensando tan sólo en términos de objetos y podremos realizar las operaciones básicas de acceso a datos desde los DAO’s, cuestión que detallaremos en el siguiente post.

Capa Modelo: Patrones de Diseño

Para la capa modelo de la aplicación utilizamos diversos patrones de diseño que serán comunes a todas las iteraciones. Los principales patrones que utilizamos serán las clases de persistencia denominadas POJO que simplemente representa el estado de los valores de los objetos más simples. Los DAO que son los objetos de acceso a datos y que en nuestro caso, dado que utilizamos Spring e Hibernate implementan a su vez un patrón denominado Layer Supertype que tiene como base la clase HibernateDaoSupport que no detallaremos aquí. Y por último la capa superior del modelo que está constituído por el patrón Facade (Fachada). Sobre el patrón fachada utilizamos además el patrón Factory con el fin de ocultar la tecnología que utilizan las fachadas.

De este modo lo que tenemos es una serie de DAO’s que manejan la persistencia de los POJO’s utilizando Hibernate y una serie de Fachadas que representan a casos de uso lógicamente relacionados y que utilizan los DAO’s asegurando la transaccionalidad mediante Spring, para ello deberemos de tener debidamente configurado el fichero de configuración de Spring (applicationContext.xml).

Podemos ver en la imagen un ejemplo de una fachada, en concreto, la fachada para la primera iteración en la que se engloban los casos de uso que se abordan en esta:

Un poco de Tecnología

Dado que en el blog anterior hemos mencionado algo acerca de usuarios y roles y de una tecnología a la que llamamos Acegi, vamos a dibujar en un esquema como se compone la tecnología que utiliza cyberHotel:

    cyberHotel funciona sobre cualquier motor de Base de Datos reconocido por Hibernate que es un framework Java consistente en un Mapeador Objeto Relacional, para tratar todo el tema del manejo de transacciones de los objetos de acceso a datos sobre hibernate utilizamos Spring que es otro framework java, y para tratar el sistema de usuarios y roles de una forma sencilla y segura utilizamos Acegi que es otro framework Java que se integra especialmente con spring.

     Toda la configuración de cyberHotel para estas tecnologías se encuentra en un fichero XML que generalmente se llama applicationContext.xml. Para el mapeo con hibernate utilizamos ficheros xml que relacionan tablas con objetos.

Primera Iteración: Casos de Uso

Mediante los Diagramas de Casos de Uso representamos todos los escenarios de interacción de los actores con el sistema. Podemos ver los diagramas en los documentos de la Forja de cyberHotel, aquí simplemente describiremos las generalidades que se pueden ver en los diagramas:

Actores: En cyberHotel, para estos casos de uso, tenemos dos actores principales que son Recepcionista (Manager) y Recepcionista (User).

Dado que se trata de una aplicación de escritorio que, generalmente, se ejecuta en un máquina situada en la recepción del hotel, o bien en varias máquinas situadas en distintos sitios del entorno hotelero, suele utilizarla una persona a la que llamamos Recepcionista de Hotel. Pues bien, las acciones correspondientes a la configuración de elementos básicos son vitales para la correcta configuración y funcionamiento del sistema, pues el esquema de nuestro hotel y la asignación de tarifas se determina en esta parte de la aplicación, es por eso que tenemos un usuario privilegiado que puede crear, editar o eliminar elementos (Manager) y otro usuario que tiene un acceso más restringido a ellos (User). La asignación de privilegios a usuarios utiliza la tecnología Acegi de modo que el rol de Manager se asignará a una persona responsable en cuanto a la administración del hotel, mientras que el rol de User podrá desempeñarlo cualquier usuario capacitado para trabajar con cyberHotel pero que no decide en cuanto a la configuración del entorno.

Caso de Uso: Cada caso de uso del diagrama que describe una acción del actor sobre el sistema, puede tener funcionalidad extendida, incluír a otros casos de uso, o estar jerarquizado en casos de uso más concretos.

Estas son las generalidades que presentan los diagramas de casos de uso, y que se implementan como parte del funcionamiento de la primera iteración de cyberHotel.