SISTEMA HOEL REI

Diseño con reutilización

Tabla de contenidos

1. Introducción 246

2. Diseño de un hotel 246

2.1 La semejanza entre dos problemas software 246

2.2 El misterio del recurso que no aparece 250

2.3 El peso del atributo disponibilidad 250

2.4 Eficiencia Desarrollo vs. Eficiencia Ejecución 252

2.5 Una dinámica común 252

2.6 Un patrón común 254

Ejercicio 256

3. Una ampliación del hotel 257

3.1 El largo camino de una solución 257

4. Epílogo 263

1. Introducción

El propósito de este capítulo es diseñar un sistema software que se parece a un diseño previo. Habrá que reconocer en qué se parecen los dos problemas y reutilizar aquella parte del diseño anterior que sea útil para el diseño nuevo.

2. Diseño de un hotel

El cliente del cajero nos recomendó a un amigo suyo para otro trabajo. Ahora nos piden hacer software para la reserva y alquiler de habitaciones en un hotel.

Con la experiencia que ya tenemos debemos plantearnos si empezamos desde cero o reutilizamos algo. Tratemos de reutilizar, aunque a primera vista, el problema del cajero no se parece al del hotel.

2.1 La semejanza entre dos problemas software

Los datos que se manejan en el caso del cajero no tienen nada que ver con los datos que se manejan en el caso del hotel. Figura 1. Parecen ser dominios diferentes sin ningún concepto en común que pueda ser reutilizado. Pero sólo hemos mirado hacia los datos.

Figura 1. Datos del Cajero y el Hotel

Cambiemos el punto de vista y pensemos en los mecanismos. El software del cajero permite que un cliente pueda hacer retiros o ingresos de dinero en su cuenta bancaria. Para poder realizar el retiro, se requiere que el cliente tenga dinero disponible en su cuenta bancaria y, también, que el monedero tenga dinero disponible para entregar la cantidad pedida. El ingreso siempre se puede realizar, no impone restricciones. Después de realizar cualquiera de las operaciones el software actualiza la cuenta del cliente y, en el caso del retiro, se actualiza también el monedero.

Figura 2. Diagrama de clases simplificado del cajero

El software del hotel, por su parte, debe permitir reservar o alquilar las habitaciones de un hotel. Para poder reservar una habitación se necesita que la habitación este disponible. Para alquilarlo se requiere que la habitación también esté disponible, ya sea porque está libre o porque ha sido reservada a nombre de la persona que quiere hacer el alquiler. Figura 3.

Para apreciar mejor la esencia del mecanismo, hemos omitido el dibujo de los gestores de colecciones y las interfaces, en el cajero y en el hotel, pero están presentes.

Figura 3. Diagrama de clases simplificado del hotel

En ambos casos se trata de realizar operaciones sobre algo. Las operaciones en el caso del cajero son el retiro y el ingreso, y las operaciones en el caso del hotel son la reserva y el alquiler. El software debe permitir la selección de la operación que desea realizar y después ejecutar esta operación. La Figura 4 muestra una estructura común que satisface las dos situaciones.

Figura 4. Generalización excesiva del cajero y el hotel

Efectivamente existe algún parecido, pero es demasiado general, muchos sistemas software tienen esta estructura. Intentemos precisar más, estudiando con detenimiento ese Algo sobre el que se ejecutan las operaciones.

En el caso del hotel ese Algo es Habitación, que se alquila y se reserva. En el caso del cajero ese Algo es Cuenta sobre la que se extrae y se ingresa dinero. Pero, Habitación y Cuenta continúan sin tener un elemento común. Volvamos al hotel. La habitación es un recurso del hotel; un recurso del que se necesita conocer su disponibilidad. Figura 5.

Figura 5. Generalización del hotel

La situación del cajero es semejante. Se actúa sobre un recurso del que se necesita conocer su disponibilidad: el dinero. La diferencia es que el recurso no aparece de forma explícita. Las operaciones se ejecutan directamente sobre su disponibilidad. La disponibilidad del dinero en el banco, a través de la cuenta y en efectivo, a través del monedero. Por esta causa no terminábamos de encontrar el encaje entre el cajero y el hotel, a pesar de su gran semejanza. Al omitir el recurso, en el cajero, fallaba nuestro intento de hallar un parecido entre habitación y cuenta, porque estábamos comparando conceptos diferentes: recurso y disponibilidad.

Sin embargo, los dos problemas tienen una esencia común. Son operaciones sobre recursos que tienen una disponibilidad limitada. Por tanto, deben compartir una estructura y una dinámica común. Parte de la estructura ya la descubrimos en la Figura 5 al generalizar el hotel. De la dinámica, nos ocuparemos después.

2.2 El misterio del recurso que no aparece

Continuemos, ahora, estudiando porqué se omite el recurso en el cajero y porqué aparece en el hotel. En el cajero, el dinero es un recurso cuantitativo, mil pesetas no se diferencian de mil pesetas. Pero, en el hotel, una habitación es distinta de otra, aunque sólo sea por su número de identificación. En el cajero no se distinguen los recursos por su cualidad, mientras que en el hotel si se distinguen. Esto justifica la omisión del recurso en el cajero y su aparición explícita, individualizada, en el hotel.

Un tratamiento cuantitativo de las habitaciones dificultaría cargar los gastos de los clientes a las habitaciones que alquilan, como se hace habitualmente. Dificultaría apreciar las incidencias sobre una habitación en particular y dificultaría hasta que un cliente pudiese alquilar una habitación específica para recordar una historia pasada. En fin.

Aclarada la diferencia entre el cajero y el hotel respecto a la omisión y aparición del recurso, en la estructura del software, estudiemos el aspecto disponibilidad.

2.3 El peso del atributo disponibilidad

La disponibilidad de las habitaciones fue la pista para encontrar que la cuenta y el monedero eran expresiones de disponibilidad en el cajero. Gracias a su planteamiento explícito en la Figura 3, repetida ahora por comodidad, nos dimos cuenta que, en el cajero, se actuaba directamente sobre la disponibilidad, omitiendo el recurso. Por tanto, fue muy importante hacerla explícita en nuestro esquema inicial. Figura 6.

Figura 6. Repetición de la estructura del hotel

Sin embargo, quizás no merece la pena hacerla explícita en el caso concreto que nos ocupa, porque la disponibilidad puede tomarse como un atributo de la habitación. Cierto, pero sería un atributo complejo, lo que sugiere su separación de la habitación.

La disponibilidad de una habitación tiene, a primera vista, tres estados: libre, alquilada o reservada, a lo largo de un período determinado, digamos seis meses. En consecuencia, tendremos que manejar unos ciento ochenta estados por habitación. Con la particularidad, adicional, de que esa lista de estados debe ser desplazada cada día para mantener constante su longitud de seis meses. Es una gestión demasiado compleja para incluirla en las tareas de la habitación, aunque conceptualmente la disponibilidad sea un atributo de habitación.

En términos de objetos, cada objeto oHabitación debe delegar en otro objeto oDisponibilidad, de su propiedad, esta gestión. Visto al revés, cada objeto oDisponibilidad sería un agregado de un objeto oHabitación en el que se delega la realización de las tareas de la disponibilidad del objeto oHabitación.

Este es un caso claro de agregación fuerte. La disponibilidad de una habitación sólo tiene sentido mientras exista la habitación.

El hotel nos recuerda a la biblioteca, que ya estudiamos en un capítulo precedente. Por tanto, podemos pensar en reutilizar esa idea. Pero las diferencias cuantitativas y cualitativas entre ambos pueden sugerir en buscar otro camino.

2.4 Eficiencia Desarrollo vs. Eficiencia Ejecución

Siguiendo la línea del diálogo directo entre los objetos interesados, como se hizo en el cajero, la disponibilidad en el hotel se averigua y se modifica a través de cada habitación. La influencia estructurada puede sugerir que el gestor de habitaciones, puesto que son varias, se ocupe de averiguar de la disponibilidad en el hotel. Esto requiere una especialización del gestor, que se justifica cuando hay problemas con la eficiencia de la máquina. Pero la especialización del gestor introduce heterogeneidad en el software que aumentan su complejidad, al diferenciarse un gestor de otro. Y además, la especialización del gestor, dificulta la evolución posterior del software.

La función de los gestores es facilitar la manipulación de la colección de objetos y esconder la manera de acceder a ellos, no más. Al separar el acceso y la manipulación de la colección, de la acción sobre cada miembro de la colección, se facilitan las modificaciones posteriores de los gestores y, también, las modificaciones sobre los miembros de la colección por separado. Por tanto, se facilita la evolución.

El objetivo de conseguir un software eficiente desde el punto de vista de la máquina y el objetivo de conseguir un software eficiente desde el punto de vista de su evolución, son objetivos generalmente contradictorios. Nuestro método se decanta por la eficiencia de la evolución.

...