Análisis y diseño de una aplicación para la gestión de reservas de un complejo de apartamentos. AIDA - MEMORIA - Fecha creación

Transcripción

1 Análisis y diseño de una aplicación para la gestión de reservas de un complejo de apartamentos. - MEMORIA - Autor Consultor Fecha creación Juan José Cuadrado Viernes, 16 de Junio de 2006 Plan de Trabajo 1/82

2 TABLA DE CONTENIDOS 1 Recogida y documentacion de requisitos Introducción Información Inicial Modelo del Dominio Modelo del Negocio El glosario del modelo del negocio Guiones Recepcionista Casos de uso Actores Diagramas de casos de uso Documentación textual Requisitos de la interfaz de usuario Análisis orientado a objetos Revisión de los casos de uso Descripción textual de los casos de uso revisados Identificación de las clases de entidades Especificación de los atributos de las clases de entidades Relaciones Identificación de las clases frontera, clases de control y operaciones Especificación formal de las clases de uso Análisis del interfaz de usuario Diseño orientado a objetos Introducción Diseño arquitectónico Diseño de los casos de uso Diagrama estático de diseño Diseño de la persistencia Diseño de la base de datos Gestores de disco El diseño de la interfaz de usuario Presentación de los datos Implementación de los diálogos Formato de ventanas Bibliografía y referencias Anexos Plan de trabajo Descripción del TFC Propósito Objetivos Planificación del proyecto División del trabajo Estimación de tiempos Identificación de hitos Encadenamiento de actividades Planificación temporal Plan de Trabajo 2/82

3 INDICE DE ILUSTRACIONES Y TABLAS. Ilustración 1 - Modelo del Dominio... 8 Ilustración 2 - Diagrama de casos de uso... 9 Ilustración 3 - Diagrama de colaboración Ilustración 4 - Modelo del Negocio Tabla 1 - Glosario de términos Ilustración 5 - Diagrama Casos de Uso Tabla 2 - Aspectos de las tareas Ilustración 6 - Diagramas de Nuevos Casos de Uso Ilustración 7 - Herencia Ilustración 8 - Agragación Ilustración 9 - Asociación Ilustración 10 - D.Colaboración 1.Actualizar reserva Ilustración 11 - D. Colaboración 2.Consultar Disponibilidad Ilustración 12 - D. Colaboración 3.Actualizar Agencia Ilustración 13 - D. Colaboración 4.Crear Entrada Ilustración 14 - D. Colaboración 5.Actualizar Apartamento Ilustración 15 - D. Colaboración 6.Actualizar Cliente Ilustración 16 - D. Colaboración 7.Emitir Factura Agencia Ilustración 17 - D. Colaboración 8.Actualizar Precios Ilustración 18 - D. Colaboración.9.Crear Salidas Ilustración 19 - D. Colaboración 10.Emitir Factura Directos Ilustración 20 - D. Secuencia 1.Actualizar Reserva Ilustración 21 - D. Secuencia 2.Consultar Disponibilidad Ilustración 22 - D. Secuencia 3.Actualizar Agencia Ilustración 23 - D. Secuencia 4.Crear Entrada Ilustración 24 - D. Secuencia.5.Actualizar Apartamento Ilustración 25 - D. Secuencia 6.Actualizar Cliente Ilustración 26 - D. Secuencia 7.Emitir Factura Agencia Ilustración 27 - D. Secuencia 8.Actualizar Precios Ilustración 28 - D. Secuencia 9.Crear Salida Ilustración 29 - D. Secuencia 10.Emitir Factura Directos Ilustración 30 - Interfaz_Reserva Ilustración 31 - Interfaz_Disponibilidad Ilustración 32 - Interfaz_Agencia Ilustración 33 - Interfaz_Entrada Ilustración 34 - Interfaz_Apartamento Ilustración 35 - Interfaz_Cliente Ilustración 36 - Interfaz_Factura_Agencia Ilustración 37 - Interfaz_Precios Ilustración 38 - Interfaz_Salidas Ilustración 39 - Interfaz_Factura_Directos Ilustración 40 - Componentes por capas Plan de Trabajo 3/82

4 Tabla 3 - C.Uso 1.Actualizar Reserva Tabla 4 - C.Uso 2.Consultar disponibilidad Tabla 5- C.Uso 3.Actualizar Agencia Tabla 6 - C.Uso 4.Crear Entrada Tabla 7 - C.Uso 5.Actualizar Apartamento Tabla 8 - C.Uso 6.Actualizar Cliente Tabla 9 - C.Uso 7.Emitir Factura Agencia Tabla 10 - C.Uso 8.Actualizar Precios Tabla 11 - C.Uso 9.Crear salida Tabla 12 - C.Uso 10.Emitir Factura Clientes Directos Ilustración 41 - Diagrama estático de diseño Ilustración 42 - Tabla Agencia Ilustración 43 - Tabla Apartamentos Ilustración 44 - Tabla Clientes Ilustración 45 - Tabla Delalle Factura Ilustración 46 - Tabla Factura Ilustración 47 - Tabla Precio Ilustración 48 - Tabla Reserva Ilustración 49 - Pantalla- Gestión de reservas Ilustración 50 - Pantalla- Disponibilidad de Apartamentos Ilustración 51 - Pantalla- Mantenimiento de Agencias Ilustración 52 - Pantalla- Gestión de entradas Ilustración 53 - Pantalla- Mantenimiento de Apartamentos Ilustración 54 -Pantalla- Mantenimiento de Clientes Ilustración 55 - Pantalla- Facturación de Agencias Ilustración 56 - Pantalla- Mantenimiento de precios Ilustración 57 - Pantalla- Gestión de salidas Ilustración 58 - Pantalla- Facturación de Clientes Directos Ilustración 59 - Diagrama de red Ilustración 60 - Diagrama de Gantt Plan de Trabajo 4/82

5 1 RECOGIDA Y DOCUMENTACION DE REQUISITOS 1.1 Introducción Los requisitos son la especificación de lo que debe hacer el software; son descriptores del comportamiento, propiedades y restricciones del software que hay que desarrollar. La recogida de requisitos busca obtener información sobre dos aspectos esenciales del software que se desarrolla; los procesos que debe realizar sobre los datos y la manera en como interactuarán estos con los usuarios. Para recoger información de los requisitos que debe cumplir el software, recurriremos a las siguientes fuentes de información:. Las entrevistas, a los futuros usuarios, acompañados de la observación directa del trabajo de los futuros usuarios.. La documentación sobre el sistema actual existente, ya sea este informatizado o realizado de forma manual.. Otros puntos de vista, que aportarán otros esquemas de trabajo que la rutina no permite ver a los usuarios directos.. Considerar otras opciones existentes en el mercado y comprobar sobre aquellas los parecidos y las opciones que no se tratan actualmente, estudiando su conveniencia. Plan de Trabajo 5/82

6 1.2 Información Inicial El complejo de apartamentos Aida, cuenta con 39 apartamentos, de los cuales 35 están en régimen de explotación, y los otros 4 en régimen de alquiler directo por sus propietarios. Estos se identifican por un número, que comprende, planta baja , primer piso , y segundo piso Mediante contrato, la dirección del complejo, acuerda con las agencias, el cupo de apartamentos de los que puede disponer cada una de ellas, así como los distintos precios, según fechas, que tendrá cada una. Como norma general, con al menos quince días de antelación y de forma diaria, las agencias solicitan reservas de apartamentos, indicando la fecha de entrada, la fecha de salida, el número de personas, y los nombres de los clientes (estos normalmente vienen de forma resumida, a modo de orientación), los nombres completos no se tendrán hasta la llegada del cliente. Estas reservas serán admitidas de forma directa, aunque sobrepasen su cupo, si bien, deberán de ajustarse al cupo dos días antes de la llegada del cliente. Por lo que podrán ser modificadas e incluso anuladas. De la misma forma, hay clientes directos (que no vienen con ninguna agencia, por lo que no tienen cupo) que pueden realizar reservas de apartamentos, estas serán temporales, hasta que no sean confirmadas en función del número de reservas de las agencias, que tienen preferencia. Una vez admitida una reserva, se le asignará un número de reserva. A la llegada de los clientes, estos tendrán que presentar el bono de reserva de la agencia (necesario para la facturación a la agencia) y el pasaporte o algún otro documento acreditativo legal (para confeccionar las fichas de policía). Les será asignado un apartamento, y se le ofrecerá alquilar una caja fuerte (habilitada en cada apartamento), si la quisieran se le entregaría la lleve, y se la cobraría el período de alquiler, así como un depósito a cuenta de la llave. Por último se procedería a activar el teléfono correspondiente al apartamento asignado. Al finalizar el día, se procederá a facturar los bonos de agencia, de los clientes que han entrado durante ese día, en función de los precios establecidos en el contrato. Llegada la fecha de salida del cliente, se comprobará si tiene alquilada caja fuerte procediéndose al reintegro del depósito contra la devolución de la llave. Asimismo se comprobará si ha hecho uso del teléfono, emitiendo, si es el caso una factura correspondiente al gasto del mismo. En el caso de cliente directo, (que no venía con ninguna agencia) se procederá a la facturación de la estancia, según los precios vigentes. Plan de Trabajo 6/82

7 A tener en cuenta: El contrato con las agencias se lleva a cabo por la dirección, y a efectos de la recepción, sólo interesa el cupo de apartamentos establecido y los precios acordados, estos datos variarán al menos dos veces al año. El control del uso telefónico se realiza mediante un programa ya existente, conectado con la centralita, que permite activar y desactivar los teléfonos, y consultar y emitir facturas. El resto de procesos de cierre y control de caja los realiza mensualmente el contable. El contable tiene su propio programa de contabilidad, en el que se lleva todo el control de cobros y pagos. Los cobros que se realizan en recepción se meterán en un sobre con sus correspondientes facturas y se pasarán a contabilidad. De la misma forma, si es necesario efectuar un pago por recepción, será el contable en que lo deje preparado. En recepción no se lleva ningún tipo de control de caja. Plan de Trabajo 7/82

8 1.3 Modelo del Dominio Recoge los tipos de objetos las clases- más importantes. A partir de la información inicial, podemos considerar las siguientes clases como más importantes: Agencias Clientes Apartamentos Precios Reservas Entradas Salidas Facturas Ilustración 1 - Modelo del Dominio Plan de Trabajo 8/82

9 1.4 Modelo del Negocio Describe a grandes rasgos los procesos y entidades principales en torno al software. Una primera aproximación al diagrama de casos de uso Ilustración 2 - Diagrama de casos de uso Plan de Trabajo 9/82

10 Para identificar los objetos que utilizamos en los casos de uso establecidos anteriormente, utilizamos el diagrama de colaboración. Ilustración 3 - Diagrama de colaboración Plan de Trabajo 10/82

11 Mediante los pasos anteriores, obteneos el diagrama de objetos del modelo del negocio: Ilustración 4 - Modelo del Negocio Plan de Trabajo 11/82

12 1.5 El glosario del modelo del negocio Agencia Apartamento Bono Caja Fuerte Cliente Cupo Depósito Disponibilidad Entrada Estado Fichas Policía Precios Recepcionista Reserva Salida Teléfono Temporada Entidad que emite reservas establecidas mediante cupo, a la que se facturarán mediante precios previamente acordados. Entidad base objeto del negocio. Impreso mediante el cual un cliente se presenta enviado por una agencia. Objeto situada en el apartamento, a fin de mantener la seguridad de los objetos preciados del cliente. Huésped que realiza la estancia en el apartamento. Número de apartamentos que se acuerda con la agencia para su utilización. Importe que se entrega, para cubrir el costo de la llave de la caja fuerte. Se le reintegra al cliente al devolver este la llave. Número de apartamentos en situación de ser ocupados por los clientes. (Check In) Proceso por el cual un cliente se incorpora como huésped del complejo. Situación en que se encuentra un determinado apartamento, este puede ser disponible o no disponible. De todos los clientes que se hospeden en los apartamentos, hay que rellenar una ficha y entregarla a la policía a efectos de control de turistas. Importes acordados a abonar en función de fechas. Persona encargada del control de reservas Proceso por el cual se destina un apartamento sin definir, a un cliente previsto. Proceso por el cual un cliente abandona el complejo Control de llamadas mediante centralita. Periodos de tiempo establecidos por una fecha de inicio y una fecha final, a la cual se le asigna un precio determinado. Tabla 1 - Glosario de términos Plan de Trabajo 12/82

13 1.6 Guiones Como quiera que el único que utilizará la gestión de reservas, será el recepcionista, que si bien son dos, ambos juegan el mismo papel, luego tienen el mismo guión: Recepcionista Llega una reserva vía fax, y se procede a su confirmación, guardándose los datos de fecha de entrada y salida, así como los datos previos de clientes. Si la reserva proviene de un cliente directo, se pasará a la dirección y se mantendrá hasta que la dirección la confirme o la rechace. Cuando un cliente llega a recepción se le solicita, el bono, y el pasaporte, preguntándosele si quiere caja fuerte, si quiere la caja fuerte se le cobra el alquiler, el depósito y se le entrega la llave de la caja fuerte, así como del apartamento asignado. Posteriormente, se le activa el teléfono, se rellena la ficha de policía, se crea la entrada, con los datos actualizados del cliente, del bono y del número de apartamento, y se adjunta el recibo de alquiler de la caja fuerte con el dinero pagado y se entrega al contable. Cuando el cliente abandona el complejo, se le recogen las llaves del apartamento, y si la tuviera, la de la caja fuerte reintegrándosele el importe del depósito, por último se desactiva el teléfono. Si el cliente es directo, se le emitirá la factura de su estancia, y se cobrará su importe, adjuntando ambos (factura y cobro) para entregar al contable. Plan de Trabajo 13/82

14 1.7 Casos de uso Si bien en el apartado del modelo del negocio, hacíamos una primera aproximación a los diagramas de los casos de uso, ahora profundizaremos un poco más en estos. Identificaremos en primer lugar los actores Actores Los actores son los usuarios finales directos del sistema, aquellos que tienen interacción con el sistema. El único actor, usuario final del sistema es el recepcionista, que es el que llevará a cabo todas las labores propias de la recepción, la gestión de reservas, la gestión de entradas y la gestión de salidas. Otros actores que podrían intervenir en el sistema, tales como el director, o el contable, no tienen interacción directa sobre el sistema, sino a través del recepcionista Diagramas de casos de uso En función de los actores y de los diagramas previamente vistos, obtenemos un diagrama de casos de uso tal y como sigue: Plan de Trabajo 14/82

15 Ilustración 5 - Diagrama Casos de Uso Plan de Trabajo 15/82

16 1.8 Documentación textual Caso de uso número 1: Crear Reserva Resumen de la funcionalidad: Añade una reserva a la base de datos. Actores: Recepcionistas. Casos de uso relacionados: Consultar disponibilidad, Consultar agencia Precondición: La reserva no existe en la base de datos. Poscondición: La reserva está incorporada en la base de datos. El recepcionista introduce los datos de la reserva, número, agencia/cliente, fecha de entrada, fecha de salida, número de personas, nombres de los clientes-huéspedes. Alternativas de proceso y excepciones: Si la agencia no está introducida, habrá de ser añadida. La fecha de salida debe ser posterior a la fecha de entrada, y ambas fechas deben ser fechas válidas. De la misma forma habrá que tener en cuenta la posibilidad de que una reserva pudiera ser anulada o modificada. Si no existe disponibilidad de apartamentos, se emitirá un mensaje con tal circunstancia y se continuará el proceso. Caso de uso número 2: Consultar disponibilidad Resumen de la funcionalidad: Comprueba la disponibilidad de apartamentos libres para una fecha dada. Actores: Recepcionistas. Casos de uso relacionados: Consultar reservas, Consultar Agencias Precondición: Poscondición: A partir de las fechas de entrada y salida, introducidas por el recepcionista, el ordenador comprobará el número de reservas en la base de datos, para cada una de las fechas comprendidas entre ambas. Alternativas de proceso y excepciones: La fecha de salida debe ser posterior a la fecha de entrada, y ambas deben ser fechas válidas. La diferencia entre el número de apartamentos contratados por una agencia y el número de reserva en una fecha determinada, no dará si hay (diferencia positiva) o no (0 o diferencia negativa) apartamentos disponibles. Plan de Trabajo 16/82

17 Caso de uso número 3: Consultar Agencia Resumen de la funcionalidad: Recupera información de una agencia determinada. Actores: Recepcionistas. Casos de uso relacionados: Precondición: La agencia está en la base de datos. Poscondición: Se muestran los datos de la agencia. Dado el nombre de una agencia por el recepcionista, se muestras los datos de la misma. Alternativas de proceso y excepciones: Se debe tener en cuenta que las agencias deben tener una mantenimiento, creación, anulación, consulta y modificación. Caso de uso número 4: Consultar Reserva Resumen de la funcionalidad: Recupera información de una reserva determinada. Actores: Recepcionistas. Casos de uso relacionados: Precondición: La reserva está en la base de datos. Poscondición: Se muestran los datos de la reserva. Dado el número de una reserva dada por el recepcionista, se muestras los datos de la misma. Alternativas de proceso y excepciones: Se debe tener en cuenta que las reservas deben tener una mantenimiento, creación, anulación, consulta y modificación. Caso de uso número 5: Crear entrada Resumen de la funcionalidad: Añade una entrada a la base de datos Actores: Recepcionistas. Casos de uso relacionados: Consultar reservas, Consultar Apartamentos, Crear clientes. Precondición: La reserva a la que corresponde el cliente existe en la base de datos, y no existe la entrada en la base de datos. El apartamento a asignar debe estar disponible. Poscondición: La entrada queda incorporada a la base de datos. El apartamento se establece como no disponible A la llegada del cliente, el recepcionista, consulta la reserva mediante su número, le asigna un número de apartamento y si es necesario crea los clientes-huéspedes recién llegados, generando la entrada. Alternativas de proceso y excepciones: Si los clientes recién llegados no figuran en la base de datos, habrá que crearlos. El apartamento asignado debe estar disponible. Plan de Trabajo 17/82

18 Caso de uso número 6: Consultar Apartamento Resumen de la funcionalidad: Recupera información de una apartamento determinado. Actores: Recepcionistas. Casos de uso relacionados: Precondición: El apartamento está en la base de datos. Poscondición: Se muestran los datos del apartamento. Dado el número de un apartamento dado por el recepcionista, se muestras los datos del mismo. Alternativas de proceso y excepciones: Se debe tener en cuenta que los apartamentos deben tener una mantenimiento, creación, anulación, consulta y modificación. Básicamente cuando consultamos un apartamento el dato básico es si está o no disponible para ser ocupado por clientes. Caso de uso número 7: Crear cliente Resumen de la funcionalidad: Añade un cliente a la base de datos Actores: Recepcionistas. Casos de uso relacionados: Precondición: El cliente no existe en la base de datos. Poscondición: El cliente queda incorporado a la base de datos El cliente introduce los datos del cliente: Nombre y apellidos, nº documento acreditativo, nacionalidad, domicilio, provincia, código postal, fecha de nacimiento y observaciones. Alternativas de proceso y excepciones: Caso de uso número 8: Emitir Factura Agencia Resumen de la funcionalidad: Emite una factura a una agencia a partir de los bonos presentados por los clientes entrados en una fecha determinada. Actores: Recepcionistas. Casos de uso relacionados: Consultar Reserva, Consultar Agencia, Consultar Precios Precondición: La factura no ha sido emitida. Poscondición: La factura ha sido impresa. El recepcionista introduce una agencia, y una fecha determinada, y el ordenador recuperará los bonos correspondientes a las reservas que han llegado en ese día, y en función de los precios por día de cada una de ellas, emite una factura. Alternativas de proceso y excepciones: Si los precios para las fechas correspondientes a cada estancia, para la agencia concreta, no han sido creados, habrán de crearse. Si la agencia no existe en la base de datos, habrá de crearse. Plan de Trabajo 18/82

19 Caso de uso número 9: Consultar Precios Resumen de la funcionalidad: Recupera el precio acordado para una fecha y una agencia determinada. Actores: Recepcionistas. Casos de uso relacionados: Consultar agencia. Precondición: Existe la agencia en la base de datos, y no existe el precio para la fecha solicitada. Poscondición: El precio queda incorporado a la base de datos Dadas una fecha y una agencia, introducidas por el recepcionista, se muestra el precio acordado para las mismas. Alternativas de proceso y excepciones: Se debe tener en cuenta que los precios deben tener una mantenimiento, creación, anulación, consulta y modificación. Este proceso puede ser realizado por el recepcionista directamente o indirectamente, al emitir una factura. Caso de uso número 10 Crear Salida Resumen de la funcionalidad: Añade una salida a la base de datos Actores: Recepcionistas. Casos de uso relacionados: Consultar reservas. Precondición: La reserva a la que corresponde el cliente existe en la base de datos, y no existe la salida en la base de datos. El apartamento está establecido como no disponible Poscondición: La salida queda incorporada a la base de datos. El apartamento está establecido como disponible A la salida del cliente, el recepcionista, consulta la reserva mediante su número, generando la salida. Alternativas de proceso y excepciones: Caso de uso número 11 Emitir Factura Directos Resumen de la funcionalidad: Emite una factura a un cliente directo a partir de los días de estancia en el complejo. Actores: Recepcionistas. Casos de uso relacionados: Consultar Reserva, Consultar cliente, Consultar Precios Precondición: La factura no ha sido emitida. Poscondición: La factura ha sido impresa. El recepcionista introduce una cliente directo, y una fecha determinada, y el ordenador en función de los precios por día, emite una factura. Alternativas de proceso y excepciones: Si los precios para las fechas correspondientes a cada estancia, para clientes directos, no han sido creados, habrán de crearse. Si el cliente no existe en la base de datos, habrá de crearse. Plan de Trabajo 19/82

20 Caso de uso número 12 Consultar Clientes Resumen de la funcionalidad: Recupera información de un cliente determinado. Actores: Recepcionistas. Casos de uso relacionados: Precondición: El cliente está en la base de datos. Poscondición: Se muestran los datos del cliente. Dado el nombre de un cliente por el recepcionista, se muestras los datos del mismo. Alternativas de proceso y excepciones: Se debe tener en cuenta que los clientes deben tener una mantenimiento, creación, anulación, consulta y modificación. Plan de Trabajo 20/82

21 1.9 Requisitos de la interfaz de usuario A efectos de establecer los requisitos de la interfaz de usuarios, en primer lugar debemos contar con los usuarios, que son los que deben trabajar con el software. Así pues debemos controlar el perfil de usuario del que disponemos. Los recepcionistas conocen su trabajo, el que menos tiempo lleva en su puesto, hace cuatro años, mientras que el otro lleva más de veinte realizándolo. Ambos tienen práctica con ordenadores, de hecho, actualmente se lleva por ordenador el control telefónico y las fichas de policía. También se utiliza el Word para generar documentos que se envían por fax, así como se accede al correo por Internet, por donde se reciben reservas y peticiones específicas de apartamentos para reservas realizadas. Con objeto de estudiar los distintos aspectos acerca del uso de la aplicación presentamos la siguiente tabla resumen: Aspectos de las tareas Aspectos Frecuencia Usuarios Entorno Tareas Anteriores Tareas Siguientes Entradas Crear Reserva 20 por semana Recepcionistas Normal Petición reserva Crear Entrada Datos Reserva Crear Entrada 20 por semana Crear reserva -- Emitir Factura Agencia Nº Apartamento Salidas Documentos Problemas Fax de agencia Nombres clientes Bono de agencia OverBooking Crear Cliente 45 por semana -- Datos cliente Documento Personal Duplicidad nombres Emitir Factura Agencia 20 por semana Crear Entrada Crear Salida Datos reserva, precios Factura Agencia Crear Salida 20 por semana Crear Entrada Emitir factura Cliente Datos reserva -- Emitir Factura Cliente 50 por año Crear Salida Estancia Especial Salidas fuera horario Datos reserva, precios Factura Cliente Estancia Especial Tabla 2 - Aspectos de las tareas Plan de Trabajo 21/82

22 2 ANÁLISIS ORIENTADO A OBJETOS Durante la fase de recogida y documentación de requisitos, se establecen básicamente, la descripción de las funciones del software, en forma de casos de uso y de tareas e usuario. El resto de documentos son complementarios. Ahora bien, esta documentación, se establece como acuerdo entre los usuarios y los desarrolladores del software, esto significa que los requisitos están expresados de una manera poco formalizada, para que sean entendibles por ambas partes. Así pues, un primer cometido del análisis es el de traducir los requisitos a un lenguaje más formal, que en el método que seguimos son los modelos y diagramas UML. Un segundo cometido de la etapa de análisis será la identificación de unas clases fundamentales que serán la base de la implementación del software. Finalmente, se expresarán estas clases en términos de casos de uso. Plan de Trabajo 22/82

23 2.1 Revisión de los casos de uso Los casos de uso elaborados en la etapa anterior, se basan en el trabajo que se realiza con una cierta frecuencia en la recepción del complejo, pero ya en la documentación textual de los mismos se exponen otros casos de uso que no se reflejan en los mismos, ya que su realización es prácticamente nula. Principalmente, hablamos de los mantenimientos; de reservas, con su posibilidad de modificación y anulación; de agencias, con sus posibilidades de creación, modificación y anulación, cosa que ciertamente nos comentas que sucede en muy pocas ocasiones (de hecho en los últimos tres años sólo ha sido modificado el nombre fiscal y el nif de una de ellas); de clientes con la posibilidad de anular y modificar cliente; de precios que se modifican dos veces al año (abril y noviembre, fecha en que se firman los contratos. Con todo esto habremos de añadir los siguientes casos de uso: Actualizar Reservas (Crear Reserva, Modificar Reserva, Consultar Reserva y Anular Reserva). Actualizar Agencia (Crear Agencia, Modificar Agencia, Consultar Agencia y Anular Agencia). Actualizar Cliente (Crear Cliente, Modificar Cliente, Consultar Cliente y Anular Cliente). Actualizar Precios (Crear Precios, Modificar Precios, Consultar Precios y Anular Precios). Actualizar Apartamentos (Crear Apartamentos, Modificar Apartamentos, Consultar Apartamentos, y Anular Apartamentos). Expresado en forma de diagrama resultaría: Plan de Trabajo 23/82

24 Ilustración 6 - Diagramas de Nuevos Casos de Uso Plan de Trabajo 24/82

25 A partir de la incorporación estos nuevos casos de uso, habrá que revisar los anteriores de forma que no haya casos de uso duplicados. En seguida nos damos cuenta que existen casos de uso que quedaría englobados en estos nuevos, tales como Crear Reserva Consultar Agencia Consultar Reserva Consultar Apartamento Crear Cliente Consultar Precios Resultando así, la siguiente relación de casos de uso: Caso de uso número 1: Actualizar Reserva Caso de uso número 2: Consultar disponibilidad Caso de uso número 3: Actualizar Agencias Caso de uso número 4: Crear entrada Caso de uso número 5: Actualizar Apartamento Caso de uso número 6: Actualizar Cliente Caso de uso número 7: Emitir Factura Agencia Caso de uso número 8: Actualizar Precios Caso de uso número 9: Crear Salida Caso de uso número 10: Emitir Factura Directos Plan de Trabajo 25/82

26 2.2 Descripción textual de los casos de uso revisados Caso de uso número 1: Actualizar Reserva Resumen de la funcionalidad: Mantenimiento de una reserva en la base de datos (creación, modificación, consulta o baja) Actores: Recepcionistas. Casos de uso relacionados: Consultar disponibilidad, Consultar agencia Precondición: Poscondición: El recepcionista introduce el número de reserva; en caso de existir muestra los datos de la reserva, número, agencia/cliente, fecha de entrada, fecha de salida, número de personas, nombres de los clientes-huéspedes, pudiendo en este momento ser anulada, o bien modificada reintroduciendo los datos; en caso de no existir presenta una plantilla en blanco, para que el recepcionista introduzca los datos de la reserva a crear. Alternativas de proceso y excepciones: Si la agencia no está introducida, habrá de ser añadida. La fecha de salida debe ser posterior a la fecha de entrada, y ambas fechas deben ser fechas válidas. Si no existe disponibilidad de apartamentos, se emitirá un mensaje con tal circunstancia y se continuará el proceso. Caso de uso número 3: Actualizar Agencias Resumen de la funcionalidad: Mantenimiento de una agencia en la base de datos (creación, modificación, consulta o baja) Actores: Recepcionistas. Casos de uso relacionados: Precondición: Poscondición: El recepcionista introduce el nombre de una agencia; en caso de existir muestra los datos de la agencia, nombre, nombre fiscal, Nif, domicilio, población, código postal, país, número de apartamentos contratados, pudiendo en este momento ser anulada, o bien modificada reintroduciendo los datos; en caso de no existir presenta una plantilla en blanco, para que el recepcionista introduzca los datos de la agencia a crear. Alternativas de proceso y excepciones: Se requieren los datos fiscales de la agencia a efectos de la facturación de la misma. Plan de Trabajo 26/82

27 Caso de uso número 5: Actualizar Apartamento Resumen de la funcionalidad: Mantenimiento de un apartamento en la base de datos (Creación, Modificación, Consulta y anulación). Actores: Recepcionistas. Casos de uso relacionados: Precondición: Poscondición: Dado el número de un apartamento dado por el recepcionista; si éste existe se muestras los datos del mismo, número, descripción y estado, pudiendo ser modificada o anulada; si éste no existe, se podrá proceder a su creación. Alternativas de proceso y excepciones: Básicamente cuando consultamos un apartamento el dato básico es si está o no disponible para ser ocupado por clientes. La anulación de un apartamento consiste en que este (normalmente por venta) queda fuera del proceso de explotación del complejo. Caso de uso número 6: Actualizar Agencias Resumen de la funcionalidad: Mantenimiento de un cliente en la base de datos (creación, modificación, consulta o baja) Actores: Recepcionistas. Casos de uso relacionados: Precondición: Poscondición: El recepcionista introduce el nombre de un cliente; en caso de existir, muestra los datos del cliente, nombre, nombre fiscal, Nif, domicilio, población, código postal, país, número de apartamentos contratados, pudiendo en este momento ser anulada, o bien modificada reintroduciendo los datos; en caso de no existir presenta una plantilla en blanco, para que el recepcionista introduzca los datos del cliente a crear. Alternativas de proceso y excepciones: Se requieren los datos fiscales del cliente, sólo, a efectos de la facturación de la misma. Plan de Trabajo 27/82

28 Caso de uso número 8: Consultar Precios Resumen de la funcionalidad: Mantenimiento de precios en la base de datos (Creación, modificación, Consulta y eliminación) Actores: Recepcionistas. Casos de uso relacionados: Consultar agencia. Precondición: Existe la agencia en la base de datos. Poscondición: El recepcionista introduce una agencia y un año; y si existen se mostrarán los precios para las distintas temporadas en las que se divide el año (mediante fecha de inicio y fecha final); si no existen se introducirán las divisiones temporales y el precio correspondiente a cada una de ellas. Alternativas de proceso y excepciones: El proceso de creación de precios se llevará a cabo al menos dos veces al año, por agencia, a la firma de los contratos con las mismas. Plan de Trabajo 28/82

29 2.3 Identificación de las clases de entidades Empezaremos por identificar las clases de entidades a partir de los casos de uso: Caso de uso número 1: Actualizar Reserva Clases: Reserva, Agencia, Cliente Caso de uso número 2: Consultar disponibilidad Clases: Reserva Caso de uso número 3: Actualizar Agencia Clases: Agencia Caso de uso número 4: Crear entrada Cases: Reserva, Entrada, Apartamento Caso de uso número 5: Actualizar Apartamento Clases: Apartamento Caso de uso número 6: Actualizar cliente Clases: Cliente Caso de uso número 7: Emitir Factura Agencia Clases: Reserva, Precios, Factura, Agencia Caso de uso número 8: Actualizar Precios Clases: Precios, Agencia Caso de uso número 9: Crear Salida Clases: Reserva, Salida Caso de uso número 10: Emitir Factura Directos Clases: Reserva, Precios, Factura, Cliente Así pues obtenemos, en primera instancia, las clases siguientes: Reserva Agencia Apartamento Cliente Precio Factura Entrada Salida. Plan de Trabajo 29/82

30 2.4 Especificación de los atributos de las clases de entidades Clase Reserva Num(integer), tipo(string) desde( date), hasta(date), NPersonas(integer) Clase Agencia Nombre(string), Nfiscal(string), NIF (string), Domicilio(string), Población(string), País(string),CPostal(string), Disponibilidad(integer) Clase Apartamento Numero(integer),descripción(string), estado(string) Clase Cliente Nombre(string), Nfiscal(string), NIF (string), Domicilio(string), Población(string), País(string),CPostal(string) Clase Precio Desde(fecha),hasta(fecha),precio(real) Clase Factura Numero(integer), fecha(date), importe(real), descuento(real), impuestos(real), total(real) Clase Entrada Napartamento(integer) Clase Salida Numero(integer) Plan de Trabajo 30/82

31 2.5 Relaciones Relaciones de herencia En primer lugar, observamos que tenemos dos clases; cliente-directos y agencia, con los mismos datos. De donde obtenemos el siguiente diagrama: Ilustración 7 - Herencia Agregaciones Lo primero que observamos en las asociaciones es la relación existente entre reserva, entrada y salida, y la dependencia que estas dos últimas tienen de la primera, pues no existiría una entrada sin una reserva, y no existiría una salida sin su entrada. Ilustración 8 - Agregación Lo que nos permite ver que podríamos prescindir de las clases entrada y salida, simplemente bastaría añadir el atributo apartamento a la reserva, y considerar entrada y salida como estados de la reserva en función de la fecha. Plan de Trabajo 31/82

32 Asociaciones Teniendo como clase principal Reserva, vemos que un apartamento puede estar o no asignado, pero si lo está es sólo uno. Asimismo, cada reserva está relacionada con un solo cliente (agencia o directo), y este a su vez con un único precio por día. Por último nos queda la relación entre reserva y factura, donde cada factura puede contener varias reservas, así pues necesitamos una nueva clase que llamaremos LíneaFactura, resultando así: Ilustración 9 - Asociación Plan de Trabajo 32/82

33 2.6 Identificación de las clases frontera, clases de control y operaciones Caso de uso 1: Actualizar reserva Ilustración 10 - D.Colaboración 1.Actualizar reserva Se introduce un número de reserva, si existe presenta los datos de la misma, pudiendo estos ser modificados; si no existe se introducirán nuevos datos para la misma. Caso de uso 2: Consultar Disponibilidad Ilustración 11 - D. Colaboración 2.Consultar Disponibilidad. A partir de una fecha dada, se consultarán las reservas efectuadas, permitiéndonos conocer las reservas disponibles para alquilar. Caso de uso 3: Actualizar Agencia Ilustración 12 - D. Colaboración 3.Actualizar Agencia. Se introduce un nombre de agencia, si existe presenta los datos de la misma, pudiendo estos ser modificados; si no existe se introducirán nuevos datos para la misma. Plan de Trabajo 33/82

34 Caso de uso 4: Crear Entrada Ilustración 13 - D. Colaboración 4.Crear Entrada. A la llegada del cliente, se introduce el número de la reserva, presentándose los datos de la misma, se introduce el número del apartamento asignado, actualizándose el mismo, tras comprobar su disponibilidad, y posteriormente se actualiza la entrada. Caso de uso 5: Actualizar Apartamento Ilustración 14 - D. Colaboración 5.Actualizar Apartamento. Se introduce un número de apartamento, si existe presenta los datos del mismo, pudiendo estos ser modificados; si no existe se introducirán nuevos datos para el mismo. Caso de uso 6: Actualizar Cliente Ilustración 15 - D. Colaboración 6.Actualizar Cliente. Se introduce un nombre de cliente, si existe presenta los datos del mismo pudiendo estos ser modificados; si no existe se introducirán nuevos datos para el mismo. Plan de Trabajo 34/82

35 Caso de uso 7: Emitir Factura Agencia Ilustración 16 - D. Colaboración 7.Emitir Factura Agencia. A partir de una fecha dada, y una agencia, se consultarán las reservas de dicha agencia con esa fecha de entrada, calculando a partir los precios el importe de cada una. Actualizando la factura y emitiendo la misma por impresora. Caso de uso 8: Actualizar Precios Ilustración 17 - D. Colaboración 8.Actualizar Precios. Se introduce un nombre de agencia y un año, si existe presenta los importes definidos por fechas correspondientes, pudiendo estos ser modificados; si no existe se introducirán nuevos datos para los límites introducidos. Plan de Trabajo 35/82

36 Caso de uso 9: Crear Salidas Ilustración 18 - D. Colaboración.9.Crear Salidas. A la Salida del cliente, se introduce el número de la reserva, presentándose los datos de la misma, y posteriormente se actualiza la salida. Caso de uso 10: Emitir Factura Directos Ilustración 19 - D. Colaboración 10.Emitir Factura Directos. A partir de un cliente, se consultarán las reservas de ese cliente, calculando a partir de los precios el importe de cada una. Actualizando la factura y emitiendo la misma por impresora. Plan de Trabajo 36/82

37 2.7 Especificación formal de las clases de uso Mediante los diagramas de secuencia tratamos de complementar los diagramas de colaboración anteriores, principalmente a efectos de aclarar en el orden en que los mensajes entran y salen de cada clase. Caso de uso 1: Actualizar Reserva Caso de uso 2: Consultar Disponibilidad Ilustración 20 - D. Secuencia 1.Actualizar Reserva. Ilustración 21 - D. Secuencia 2.Consultar Disponibilidad. Plan de Trabajo 37/82

38 Caso de uso 3: Actualizar Agencia Caso de uso 4: Crear Entrada Ilustración 22 - D. Secuencia 3.Actualizar Agencia. Ilustración 23 - D. Secuencia 4.Crear Entrada. Plan de Trabajo 38/82

39 Caso de uso 5: Actualizar Apartamento Caso de uso 6: Actualizar Cliente Ilustración 24 - D. Secuencia.5.Actualizar Apartamento. Ilustración 25 - D. Secuencia 6.Actualizar Cliente. Plan de Trabajo 39/82

40 Caso de uso 7: Emitir Factura Agencia Caso de uso 8: Actualizar Precios Ilustración 26 - D. Secuencia 7.Emitir Factura Agencia. Ilustración 27 - D. Secuencia 8.Actualizar Precios. Plan de Trabajo 40/82

41 Caso de uso 9: Crear Salida Caso de uso 10: Emitir Factura Directos Ilustración 28 - D. Secuencia 9.Crear Salida. Ilustración 29 - D. Secuencia 10.Emitir Factura Directos. Plan de Trabajo 41/82

42 2.8 Análisis del interfaz de usuario Seguidamente se adjunta el esquema de ventana correspondiente a cada clase frontera, de los diagramas de colaboración anteriores. Interfaz_Reserva Interfaz_Disponibilidad Ilustración 30 - Interfaz_Reserva. Interfaz_Agencia Ilustración 31 - Interfaz_Disponibilidad. Ilustración 32 - Interfaz_Agencia. Plan de Trabajo 42/82

43 Interfaz_Entrada Ilustración 33 - Interfaz_Entrada. Interfaz_Apartamento Ilustración 34 - Interfaz_Apartamento. Interfaz_Cliente Ilustración 35 - Interfaz_Cliente. Plan de Trabajo 43/82

44 Interfaz_Factura_Agencia Ilustración 36 - Interfaz_Factura_Agencia. Interfaz_Precios Ilustración 37 - Interfaz_Precios. Interfaz_Salidas Ilustración 38 - Interfaz_Salidas. Plan de Trabajo 44/82

45 Interfaz_Factura_Directos Ilustración 39 - Interfaz_Factura_Directos. Plan de Trabajo 45/82

46 3 DISEÑO ORIENTADO A OBJETOS 3.1 Introducción La etapa de diseño hace de puente entre el análisis y la realización. Aquí se identifican los componentes de software y hardware necesarios para satisfacer los requerimientos, como así también especifican las relaciones arquitecturales entre dichos componentes. El diseño arquitectónico tiene como objetivo definir las grandes líneas del modelo del diseño. El diseño arquitectónico comprende las actividades siguientes: establecer la configuración de la red, decidir la utilización de un marco ya disponible, si procede, y establecer los subsistemas, sus interfaces y las dependencias entre estos. Tratándose de una aplicación distribuida, tenemos que tomar decisiones sobre su arquitectura física y lógica, así como sobre la tecnología e infraestructura a que se emplearían para implementar su funcionalidad. Plan de Trabajo 46/82

47 3.2 Diseño arquitectónico Entre los objetivos del diseño de una aplicación destacamos: Seguridad: Desde un principio, teniendo en cuenta los mecanismos adecuados de autenticación, la lógica de autorización y la comunicación segura. Rendimiento: Proporcionando una adecuada optimización para operaciones frecuentes entre patrones de implementación. Escalabilidad: De forma que permita cumplir las expectativas de la demanda y admita un gran número de actividades y usuarios con el mínimo uso de recursos. Administración: Permitiendo a los operadores implementar, supervisar y resolver los problemas de la aplicación en función del escenario. Mantenimiento: Mediante la funcionalidad de diseño que nos permite tener en cuenta distintos tamaños de aplicaciones, equipos con conjuntos de habilidades variadas y requisitos técnicos y cambios empresariales. Independencia: Que funcione en los distintos escenarios de aplicaciones y patrones de implementación. Con todo esto, la arquitectura que hemos escogido será.net, que nos proporcionará el marco adecuado para el desarrollo de aplicaciones que necesiten generar soluciones distribuidas. Plan de Trabajo 47/82

48 Componentes y niveles en aplicaciones y servicios. Se ha convertido en un principio ampliamente adoptado en el diseño de aplicaciones distribuidas la división de la aplicación en componentes que ofrezcan servicios de presentación, empresariales y de datos. Los componentes que realizan tipos de funciones similares se pueden agrupar en capas, que en muchos casos están organizados en forma de apilamiento para que los componentes que se encuentran por encima de una capa determinada utilicen los servicios proporcionados por ésta, y un componente específico utilizará la funcionalidad proporcionada por otros componentes de su propia capa, y otras capas inferiores, para realizar su trabajo. Esta visión dividida de una aplicación también se puede aplicar a los servicios. Desde un punto de vista de alto nivel, se puede considerar que la solución basada en servicios está formada por varios servicios, los cuales se comunican entre sí pasando mensajes. Ilustración 40 - Componentes por capas Plan de Trabajo 48/82

49 Componentes de interfaz de usuario Necesidad de ofrecer al usuario un modo de interactuar con la aplicación. Las interfaces de usuario se implementan utilizando formularios de windows forms, así como cualquier otro tipo de tecnología que permita proceder y dar formato a los datos de los usuarios, así como adquirir y validar los datos entrantes procedentes de éstos. Componentes de proceso de usuario La interactuación del usuario con el sistema se realiza de acuerdo a un proceso predecible. Para facilitar la sincronización y organización de las interactuaciones con el usuario, resulta útil utilizar componentes de proceso de usuario individuales. Interfaces de servicios Es necesario crear interfaces de servicios que admitan los contratos de comunicación (formatos, protocolos, y excepciones) requerido por los clientes. Componentes lógicos de acceso a datos Lógica necesaria para obtener acceso a los datos en una capa independiente de componentes lógicos de acceso a dato, ya que de este modo se centraliza la funcionalidad de acceso a datos y se facilita la configuración y el mantenimiento de la misma. Agentes de servicios Permiten aislar las idiosincrasias de las llamadas a varios servicios desde la aplicación y pueden proporcionar servicios adicionales, como la asignación básica del formato de los datos que expone el servicio al formato que requiere la aplicación. Plan de Trabajo 49/82

50 3.3 Diseño de los casos de uso Dado que los requerimientos se recogieron en forma de casos de uso, una manera lógica de enfocar el diseño es describir la implementación de cada uno, partiendo de la versión revisada y documentada con diagramas de interacción en la etapa de análisis. En lugar de especificaciones textuales (mediante fichas TRAD), como las que vamos a efectuar, se podrían realizar diagramas de secuencia, pero en los casos reales a menudo serían muy complejos (Diseño Orientado A Objetos. Ingeniería del software UOC P01/75007/00570). Plan de Trabajo 50/82

51 CU 1 - Actualizar Reserva Propósito: Mantenimiento de una reserva en la base de datos (creación, modificación, consulta o baja) Actores: Recepcionistas. Precondición: La base de datos está disponible. n eventos ACTOR Eventos SISTEMA 1 El sistema ofrece el siguiente nº de reserva consecutivo 2 El recepcionista confirma el nº de reserva, o Si el número de reserva ya existe, presenta introduce uno nuevo. 3 El recepcionista introduce o modifica los datos de la reserva. Si sólo se pretendía consultar la reserva, el recepcionista puede abandonar la pantalla. El recepcionista puede también anular la reserva. los datos de la misma por pantalla El sistema realizará la validación de datos:.- fecha salida > fecha entrada..- Nº personas entre 1 y 3 4 Al grabar los datos se validarán los datos obligatorios.- Agente/Directo.- Nombre cliente 1 5 Si se han seleccionado las opciones de grabar o borrar, el sistema se reposiciona en el número de reserva, con el siguiente número consecutivo. Poscondición: La reserva queda actualizada en la base de datos. Observaciones: Los nombres de clientes, se introducirán siguiendo un formato determinado, en principio se mantendrá el que se nos envía en la reserva de la agencia (apellidos, nombre) Tabla 3 - C.Uso 1.Actualizar Reserva. Plan de Trabajo 51/82

52 CU 2 Consultar disponibilidad Propósito Comprueba la disponibilidad de apartamentos libres para una fecha dada. Actores: Recepcionistas. Precondición: La base de datos está disponible. n eventos ACTOR Eventos SISTEMA 1 El recepcionista introduce una fecha. El sistema comprobará que sea una fecha válida. 2 El sistema calcula y presenta los apartamentos disponibles para la fecha dada 3 El sistema se reposiciona en el campo fecha. Poscondición: Observaciones: Este caso de uso, al mismo tiempo, podrá ser utilizado, por el caso de uso de reservas para evitar overbooking (reservar por encima del cupo), en un posible futuro sin contrato con agencias. Ahora mismo, es la agencia, por contrato, la que controla esta circunstancia. Tabla 4 - C.Uso 2.Consultar disponibilidad. Plan de Trabajo 52/82

53 CU 3 - Actualizar Agencia Propósito: Mantenimiento de una agencia en la base de datos (creación, modificación, consulta o baja). Actores: Recepcionistas. Precondición: La base de datos está disponible. n eventos ACTOR Eventos SISTEMA 1 El recepcionista introduce un nombre de Si el nombre de agencia ya existe, presenta agencia. 2 El recepcionista introduce o modifica los datos de la agencia. Si sólo se pretendía consultar la agencia, el recepcionista puede abandonar la pantalla. El recepcionista puede también eliminar la agencia. los datos de la misma por pantalla El sistema realizará la validación de datos:.- nº de apartamentos contratados entre 1 y 39 3 Al grabar los datos se validarán los datos obligatorios.- Nombre fiscal.- Nif 4 Si se han seleccionado las opciones de grabar o borrar, el sistema se reposiciona en el nombre de agencia. Poscondición: La agencia queda actualizada en la base de datos. Observaciones: Posiblemente habría sido mejor asignar a cada agencia un número, y utilizar este como campo clave, en lugar del nombre. El mantener el nombre de la agencia como clave ha sido una petición de los recepcionistas debido a su forma de trabajo actual. Tabla 5- C.Uso 3.Actualizar Agencia. Plan de Trabajo 53/82

54 CU 4 Crear entrada Propósito Añade una entrada a la base de datos Actores: Recepcionista Precondición: La base de datos está disponible. n eventos ACTOR Eventos SISTEMA 1 El recepcionista introduce un número de reserva El sistema comprueba que la reserva exista, si existe presenta los datos de la reserva en pantalla, y si existe los datos de la entrada. 2 En caso de no existir la reserva, el sistema presentará un mensaje indicando tal circunstancia. 3 El recepcionista introduce o modifica los el número de apartamento y el bono de la agencia Si sólo se pretendía consultar la entrada el recepcionista puede abandonar la pantalla. El recepcionista puede también anular la entrada. El sistema comprueba la disponibilidad del apartamento. Si este se encuentra no disponible, se presentará un mensaje indicando tal circunstancia. 4 Al grabar los datos se validarán los datos obligatorios - Número de apartamento - Bono de la agencia El sistema actualizará el apartamento de forma que este actualice su estado a disponible o no disponible (en función de la opción seleccionada, grabar o anular) 5 El recepcionista introduce o modifica el bono de la agencia Si se han seleccionado las opciones de grabar o borrar, el sistema se reposiciona en el número de reserva Poscondición: La entrada y el apartamento quedan actualizados en la base de datos. Observaciones: Existe la posibilidad de que un cliente quiera cambiar de apartamento y el recepcionista acepte dicha petición. Tabla 6 - C.Uso 4.Crear Entrada. Plan de Trabajo 54/82