ARCHIVOS: UNA BASE DE DATOS BASADA EN ARCHIVOS BINARIOS
Análisis del problema
Un pequeño hotel de una ciudad costera precisa una aplicación para su manejo. La aplicación permitirá el registro de las actividaes habituales (reservas, entradas y salidas) y mostrará el estado de disponibilidad del hotel a los usuarios de Recepción. La carga y grabación de información serán totalmente automáticas, sin intervención del usuario. En esta versión emplearemos un formato de archivos binarios.
Diseño del programa
El hotel consta de un cierto número de habitaciones, identificadas mediante una combinación de planta y número. Las habitaciones pueden tener tres estados:
Estas habitaciones se van a gestionar mediante tres módulos:
-
Reservas, que permite registrar la ocupación futura de habitaciones a lo largo de un cierto periodo. Esta información se reflejará en el archivo anual, que contiene el estado de todas las habitaciones del hotel, para cada día. Las reservas tendrán asociada la identidad del cliente.
-
Entradas, que permite registrar la llegada de un cliente a una habitación. El estado de la habitación pasa a ser el de Ocupado, y sólo cambiará cuando el cliente la abandone. Este módulo permitirá visualizar cómodamente las habitaciones Libres, Ocupadas o Reservadas para cualquier intervalo de fechas. La entrada da lugar a la marcación del archivo de estado del hotel, y a la adición de un registro al archivo de estancias.
-
Salidas, que permite registrar la salida de un cliente de una habitación. Este proceso conlleva la emisión de una factura que refleja la fecha de entrada, fecha de salida y datos del cliente. Las salidas se reflejan en el archivo de estado del hotel, y su información procede del registro de estancias.
Implementación
Módulo de reservas
Módulo de entradas
Modulo de salidas
Programa principal
Comprobación y Depuración
La única forma de comprobar el correcto funcionamiento de un programa de cierta entidad consiste en utilizarlo de forma "real". En este caso, se han realizado pruebas de reserva, entrada y salida, hasta lograr que el programa parezca funcionar correctamente. ¡No es posible garantizar su corrección! Con todo, si el programa detecta una situación anómala, se notifica al usuario el problema detectado.
Documentación
La documentación del programador consta en los comentarios del código fuente. El Manual del usuario podría ser como sigue:
Manual del Usuario en HTML
MANTENIMIENTO
Para sorpresa de más de uno,
el ciclo vital del software es un proceso iterativo
que no tiene, en modo alguno, la documentación como etapa final. Antes bien, la documentación es un proceso que debe abarcar todas las fases del programa. Aun cuando estas ideas pertenecen más al entorno de la Ingeniería del Software que a un curso de programación, conviene hacer algunos comentarios:
-
Más del 60% del coste de desarrollo de un programa está asociado a la fase de mantenimiento. En esta fase, que tiene su punto álgido unos seis meses tras la comercialización del producto, es preciso resolver los defectos de implementación, y hay que aportar nuevas versiones que satisfagan las necesidades indicadas por los usuarios al cabo de un cierto tiempo de uso real.
-
Los resultados de las fases de análisis y diseño, independientes del lenguaje de implementación, se cuentan entre los más importantes y valiosos del desarrollo realizado. Una correcta realización de estas dos fases simplificará enormemente el cambio de lenguaje de implementación o de plataforma de desarrollo.
-
Por último, y para resaltar especialmente este hecho, el ciclo vital del software es un proceso iterativo: los errores detectados en cualquier fase pueden hacer necesario volver a cualquiera de las fases anteriores, incluyendo la fase de análisis. Es posible que se precisen varias iteraciones hasta llegar a un análisis y diseño correctos, que serán previos a todo intento de implementación. Véase la obra de Meyer,
Construcción de Software Orientado a Objetos
.