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

...