cyberHotel es una aplicación en fase beta y por lo tanto puede contener “pequeños errores” y quién mejor que los usuarios finales para detectar posibles bugs en el sistema. Por lo tanto si quieres convertirte en un betatester puedes enviar los errores que encuentres a la siguiente dirección:
Hay que tener en cuenta que un bug no es una mejora esperada en el sistema, además, para enviar los errores es conveniente siempre seguir una serie de pasos ordenados, por lo que la siguiente plantilla os puede ayudar a la hora de informar de los errores si bien no es necesario seguirla estrictamente:
1. Tipo de error:
Error de ejecución
Fallo de seguridad
Error en los datos
Otro problema
2. Donde está el problema:
Configuración de datos básicos
Sistema de reservas
Sistema de facturación
3. Título para el problema (breve resumen).
4. Pasos para llegar al problema y con que datos.
5. Resultado esperado frente a resultado obtenido.
6. Características del entorno de ejecución:
Versión de la máquina virtual de java
Sistema operativo utilizado
Aunque no sigais estrictamente estos pasos, sobre todo si se trata de un error fácil de reproducir, será de agradecer toda colaboración. Muchas gracias.
cyberHotel se puede comunicar con la centralita Asterisk de software libre a través de la cual puede recoger información sobre llamadas telefónicas que utilicen esta centralita. Permite generar los cargos correspondientes para la duración de una llamada hecha desde una extensión telefónica asociada a una habitación. Desde el formulario de alta de habitaciones cyberHotel permite especificar un número o extensión telefónica para cada habitación. Desde la configuración (para la cual aún no hay un menú diseñado) se puede indicar el coste de tarificación para la unidad de llamada (como por ejemplo el segundo). Por lo tanto, cuando se hace una llamada desde un teléfono asociado a una habitación hacia el exterior, desde la pantalla de cargos y pulsando en el botón actualizar aparecerán automáticamente los cargos por llamadas telefónicas que se hicieron durante la estancia en la habitación. En el vídeo podemos ver un ejemplo con teléfonos software de una llamada desde la habitación 201 que tiene una estancia vigente.
Después de mucho tiempo, por fin tenemos disponible en la forja la versión beta de cyberHotel, hasta ahora la más funcional. De momento la versión está disponible para utilizar bajo Windows y se distribuye bajo un ejectuable con autoinstalación. Puede descargarse como siempre desde la forja, el fichero comprimido es cyberHotel-0.0b-win32.zip. Como siempre es necesario seguir los siguientes pasos antes de usar cyberHotel:
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.
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.
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.
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.
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:
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:
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:
Escrito por cyberhotel 
Escrito por cyberhotel 
Escrito por cyberhotel 
