ENTREGA Nº2 PROYECTO SISTEMA DE GESTION HOTELERA

Transcripción

1 UNIVERSIDAD DE CARABOBO FACULTAD EXPERIMENTAL DE CIENCIAS Y TECNOLOGÌA DEPARTAMENTO DE COMPUTACIÓN DESARROLLO DE APLICACIONES WEB ENTREGA Nº2 PROYECTO SISTEMA DE GESTION HOTELERA Elaborado Por: Aura Maneiro CI: , Gabriel Redondo CI: , Marin Henry CI: , Nicolas Serrano CI: Dirigido A: Prof. Luis Guillermo León Bárbula, 04 de Junio de 2011

2 PLANIFICACIÓN Y CONFIGURACIÓN 1.1PLANIFICACION DE TIEMPOS DE DESARROLLO El proyecto consiste en el desarrollo de una aplicación web utilizando los métodos, técnicas y herramientas de la Ingeniería Web y de la metodología de desarrollo ágil SCRUM. La planificación del proyecto se verá ajustada a la proporcionada en el enunciado del proyecto. Esta planificación se resume en la siguiente tabla: Sprint Funcionalidad Fecha Entrega 0 Planificación y Configuración 4 de Junio de Consulta de Habitación Disponible 18 de Junio de Reserva de Habitación Disponible 25 de Junio de Cancelar Reserva 02 de Julio de Consumos (bebida/teléfono) 09 de Julio de Llegada de Cliente con Reserva 16 de Julio de Calculo de Factura y Salida del Cliente 20 de Julio de 2012 Cada una de estas fases corresponde con un hito o milestone del proyecto. Para cada uno de estos hitos el jefe de proyecto asignara una serie de Tickets, que corresponderán a las tareas que deben realizar los miembros del equipo de desarrollo para completar satisfactoriamente el hito que corresponde a esa semana. Cuando un ticket sea asignado a un miembro del equipo, este debe aceptarlo, una vez que haya culminado su realización debe marcarlo como solucionado en la herramienta de gestión del proyecto.

3 1.2 RECURSOS HUMANOS Y ROLES El equipo de desarrollo que se mantendrá a lo largo de la realización del proyecto esta formado por cuatro personas: 1. Aura Maneiro 2. Gabriel Redondo 3. Henry Marín 4. Nicolás Serrano Los roles a desempeñar por cada miembro del equipo será: Jefe de Proyecto: Aura Maneiro 1. Aura Maneiro: Arquitecto de Software Administrador de Base de Datos Analista/Programador 2. Gabriel Redondo Analista/Programador Codificador de Pruebas Diseñador de Interfaz Usuario 3. Henry Marín Administrador de Sistemas Administrador de Base de Datos Codificador de Pruebas 4. Nicolás Serrano Administrador de Sistemas Analista/Programador Diseñador de Interfaz Usuario Todos los roles desempeñaran su labor en cada una de las fases del proyecto.

4 1.3 REUNIONES DE PROYECTO Las reuniones con el cliente para estudiar la evolución y el seguimiento del proyecto tendrán lugar los lunes de 9:00AM 11:00AM. Las reuniones de equipo quedan establecidas los días martes a las 11:00 AM donde se hará el análisis y revisión del incremento generado en la iteración que corresponde. Por otra parte a lo largo de la semana debe existir comunicación entre el equipo para evaluar las asignaciones de los Tickets de cada hito y hacer seguimiento de las tareas asignadas a cada miembro. De ser necesario se puede convocar una reunión en un horario diferente. 1.4 ELECCION DE TECNOLOGIAS DE DESARROLLO FRAMEWORKS Y TECNOLOGIAS Debido a que el Sistema debe ser accesible vía web, se decidió seguir la arquitectura Modelo Vista Controlador, la cual aumenta las capacidades de la arquitectura conocida como Modelo Cliente/Servidor, y a su vez organiza todos los componentes que conforman el sistema según su función. Al implementar el sistema siguiendo la arquitectura mencionada anteriormente se obtienen todas las características más utilizadas actualmente ara el desarrollo de aplicaciones web, y las ventajas de los sistemas distribuidos. En el siguiente diagrama se muestran los bloques preliminares en los que será estructurado el sistema.

5 Arquitectura Modelo Vista Controlador Modelo: Es el modulo que conoce todos los datos necesarios para ser desplegados y la operaciones que pueden realizarse en la aplicación, sin embargo, no conoce nada acerca de las interfaces graficas de usuario, la manera ni la forma en que son desplegados dichos datos. Los datos conocidos por el modelo son manipulados por métodos que son totalmente independientes de las interfaces graficas de usuario. El modelo es la parte invariable de la aplicación, es decir, la parte que nunca cambia. En el caso del paradigma orientado a objetos, en modelo está compuesto por las clases que modelan y soportan el problema a resolver. Vista: La vista solo tiene la función de desplegar los datos en cualquier forma, para que estos sean observados por el usuario final, pero no puede hacer operaciones extras a estos datos, lo único que puede hacer es almacenarlos temporalmente para desplegarlos en el momento necesario. Dado que la vista no tiene facultades de hacer operaciones o modificaciones a los datos, los objetos del modelo no se deben relacionar directamente con los objetos de la vista. Controlador: La función principal del controlador es verificar las operaciones que los usuarios solicitan hacer tanto para el modelo como para la vista. En aplicaciones web, como la del presente proyecto, estas peticiones son de tipo HTTP GET y HTTP POST.

6 Puede darse el caso en que el controlador deba interactuar con la vista sin pasar antes por el modelo, por lo que el diagrama de bloques de la arquitectura Modelo Vista Controlador es la siguiente: Configuración del sistema. Para el correcto funcionamiento de la aplicación, y que pueda seguir el paradigma de la arquitectura Modelo Vista Controlador es necesario hacer uso de un servidor web, así como también se necesitara un manejador de bases de datos para el correcto almacenamiento de la información a procesar. Como se menciono anteriormente, el desarrollo de este proyecto se realizara de manera local durante sus etapas iníciales, por lo cual se utilizara la herramienta XAMPP para cumplir con los requisitos previamente mencionados. XAMPP es una herramienta open source, gratuita, que consiste básicamente en un paquete de varios software y servicios, necesarios para la implementación local de una Aplicación web.

7 XAMPP cuenta con: Servicio servidor Apache HTTP y MySQL, además de intérpretes para los lenguajes PHP y Pearl. Se trabajara con la versión más reciente de XAMPP (1.7.7), que puede ser obtenida desde la página web de los desarrolladores. Las versiones de los servicios son: Apache MySQL PHP phpmyadmin Para el desarrollo de la aplicación web se utilizara el Yii framework, en conjunto con el IDE Netbeans. Yii es un framework de alto desempeño, implementado en lenguaje PHP, utilizado como herramienta base en la creación de aplicaciones web. NetBeans es un ambiente de desarrollo Open Source y multiplataforma. Se utilizara debido a su eficiencia a la hora de trabajar con el lenguaje de programación PHP, que es la base fundamental del Yii framework. Para el control de versiones durante el desarrollo de la aplicación se utilizara el Sistema de Control de Versiones Subversion, el cual fue diseñado específicamente para reemplazar al popular CVS. Es software libre bajo una licencia de tipo Apache/BSD y se le conoce también como svn por ser el nombre de la herramienta utilizada en la línea de comando. Subversion puede acceder al repositorio a través de redes, lo que le permite ser usado por personas que se encuentran en distintas computadoras. A cierto nivel, la posibilidad de que varias personas puedan modificar y administrar el mismo conjunto de datos desde sus respectivas ubicaciones fomenta la colaboración. Se puede progresar más rápidamente sin un único conducto por el cual deban pasar todas las modificaciones. Y puesto que el trabajo se encuentra bajo el control de versiones, no hay razón para temer por que la calidad del mismo vaya a verse afectada si se ha hecho un cambio incorrecto a los datos, simplemente deshaga ese cambio. Para poder llevar un control exhaustivo sobre el correcto desarrollo del proyecto, se utilizará la herramienta online Assembla. El espacio creado es:

8 Finalmente se presenta una tabla con la especificación puntual de las tecnologías y herramientas utilizadas. Nombre Herramienta IDE de Desarrollo NetBeans IDE Framework de Desarrollo Yii PHP Framework Sistema de Control de Subversion Software Versiones Desarrollo de Interfaz Adobe Dreamweaver Repositorio, Wikis y Assemba Seguimiento de Tareas SGDB MySQL Servidor Local XAMPP 1.5 ENTREGABLES E2: Especificación de requisitos y casos de uso del sistema; arquitectura del sistema. Para este primer hito se estudio y analizo el alcance de la aplicación a desarrollar, a continuación se describe y se detalla una lista de los principales requisitos funcionales y no funcionales. Inicialmente estos son los requerimientos funcionales identificados de acuerdo al escenario actual, más adelante se procederá a realizar una más detallada de cada uno de los requerimientos, organizándolos y estableciendo un valor prioritario. REQUISITOS FUNCIONALES DE LA APLICACIÓN Los siguientes requisitos establecen los comportamientos del sistema, su interacción con el entorno y funcionamiento.

9 0. La aplicación permite a usuarios no registrados visualizar el contenido publico de la aplicación web. 1. La aplicación debe permitir, a usuarios no registrados, registrarse. 2. La aplicación debe permitir a usuarios registrados y no registrados consultar la disponibilidad de habitaciones para una fecha determinada. 3. La aplicación debe permitir a usuarios registrados reservar una habitación. Solo se podra reservar con 2 meses de adelanto. 4. La aplicación debe permitir al administrador configurar el parametro de tiempo previo a reservas. 5. La aplicación debe permitir al usuario registrado cancelar una reservación. 6. La aplicación deberá calcular el costo de penalización por cancelación tomando como criterio los días de antelación a la fecha de ocupación, quedado estos costos definidos de la siguiente manera: a. Sin coste, 5 días antes. b. 10% entre 5-2 dias antes. c. 30% entre hora antes. d. 100% en menos de 24 horas. 7. La aplicación debe permitir al administrador configurar los costos de penalización por cancelación de reserva establecidos en el punto La aplicación debe permitir al administrador configurar los precios de las habitaciones según su categoría. 9. La aplicación debe permitir al administrador agregar nuevos productos a la categoría de consumibles. 10. La aplicación debe permitir al administrador configurar los costos de los productos consumibles. 11. La aplicación debe calcular los costos por consumo de llamadas telefónicas nacionales e internacionales realizadas durante la estadía del cliente. 12. La aplicación debe permitir al administrador configurar los costos de las llamadas telefónicas nacionales e internacionales. 13. La aplicación debe calcular el precio total de la factura del cliente y emitirla. Esta debe incluir los costos de consumibles y llamas telefónicas realizadas desde la habitación. 14. La aplicación debe permitir al administrador emular el rol de un usuario registrado normal. REQUISITOS NO FUNCIONALES 1. El sistema debe estar sometido a altos niveles de seguridad, ya que deberá estar en un entorno web. 2. El sistema debe ser amigable para el usuario.

10 3. El sistema debe estar disponible en todo momento. 4. El sistema debe poseer las caracteristicas de calidad de software: mantenibilidad, eficiencia, confiabilidad, usabilidad. MODULOS QUE COMPONEN LA APLICACIÓN La aplicación se divide en 4 grandes módulos cada uno con sus funcionalidades bien concretas: 1. Modulo de Usuarios: Este modulo permite llevar el control de los usuarios de la aplicación web y su información, además de proveer de las diferentes funciones que pueden realizar dentro de la aplicación. Los usuarios son clasificados en 3 tipos: Usuario No Registrado, Usuario Registrado y Administrador. Las funciones que realiza el usuario administrador son especificadas en el modulo de administración Modulo de Usuarios No Registrados 1.1.1) Registro de Usuario 1.1.2) Visualizar Calendario de Reservas 1.1.3) Visualizar Contenido Publico de la Aplicación 1.2 Modulo de Usuarios Registrados 1.2.1) Ingresar con usuario y clave al sistema 1.2.2) Visualizar Calendario de Reservas 1.2.3) Consulta de Habitaciones Disponibles 1.2.4) Reserva de Habitaciones Disponibles 1.2.5) Cancelar Reserva 1.2.6) Consumo de Servicios 1.2.7) Visualizar Contenido Publico de la Aplicación 2. Reservas: Este modulo permite llevar el control de la disponibilidad de habitaciones en tiempo real, actualizar y consultar el calendario de reservar y reportes. 2.1 Procesar reserva de habitación. 2.2 Procesar cancelación de reserva.

11 2.3. Calendario de reservas. 3. Modulo de Administración: Este modulo permite el manejo de todas las funciones del administrador del hotel en la Aplicación Web. 3.1) Configuración de Parámetros: 3.1.1) Configurar Parámetro de Tiempo previo para realizar reservas (inicialmente establecido en 2 meses) ) Configurar Parámetro de Costos de Penalización por cancelación de reserva ) Configurar los Precios de las Habitaciones según su Tipo y Categoría ) Configurar tarifa de llamadas nacionales e internacionales. 3.2) Agregar/Eliminar productos que pertenecen a las categorias de consumibles. 4. Modulo de Empleado: Este modulo permite el manejo de la facturación a los clientes del hotel. Emisión de reportes de facturación y consumos. 4.1) Calculo de Precio Total de Alojamiento. 4.2) Calculo de Precio Total de Teléfono. 4.3) Calculo de Precio Total de Minibar. 4.4) Calculo de Precio Total a Facturar. 4.5) Emisión de Factura en Formato PDF. 4.6) Asignar habitación a Usuario con reserva. CASOS DE USO DEL SISTEMA Identificar : Usuarios No Registrado: Es aquella persona o cliente que aun no está registrada en la aplicación, este tipo de usuario puede ver el contenido publico de la aplicación web, registrarse, y además, puede visualizar un calendario de reservaciones. Usuarios Registrados: Es aquella persona o cliente que ya se registro en la aplicación web, este Actor del sistema puede, aparte de ver el contenido público,

12 realizar reservaciones de habitación en el hotel, cancelar las reservas ya realizadas, a este actor, en los modulos de reserva y facturación se le llama Cliente. Administrador del Sistema: Es el usuario con mayor privilegios sobre el sistema. Permitirá utilizar en su totalidad todas las operaciones disponibles del sistema. MODULO DE ADMINISTRACIÓN CU01 Nombre del Caso de Uso Descripción Precondición Configurar costos de Habitación El Administrador del sistema configura nuevos costos para la habitación. El Administrador del sistema. Ingresar al módulo de administrador. Obtener costos vigentes. Configurar nuevos costos. Flujo Alternativo Postcondición El sistema guarda la nueva configuración CU02 Nombre del Caso de Uso Descripción Precondición Configurar costos de Consumibles El administrador del sistema configura nuevos costos para los consumibles. El Administrador del sistema. Ingresar al módulo de administrador. Obtener costos vigentes. Configurar nuevos costos. Flujo Alternativo Postcondición El sistema guarda la nueva configuración CU03 Nombre del Caso de Uso Descripción Precondición Configurar tiempo previo a Reserva El Administrador del sistema configura el tiempo previo en el cual es permitido al usuario realizar una reserva. El Administrador del sistema. Ingresar al módulo de administrador.

13 Configurar el tiempo previo a reserva. Flujo Alternativo Postcondición El sistema guarda la nueva configuración CU04 Nombre del Caso de Uso Descripción Precondición Configurar los costos de tarifas telefónicas nacionales e internacionales: El administrador del sistema configura los costos de tarifas telefónicas nacionales e internacionales hechas desde la habitación. El Administrador del sistema. Ingresar al módulo de administrador. Obtener costos vigentes. Configurar los costos de tarifas telefónicas nacionales e internacionales. Flujo Alternativo Postcondición El sistema guarda la nueva configuración CU05 Nombre del Caso de Uso Descripción Precondición Configurar costos de penalización por cancelación El administrador del sistema configura nuevos costos de penalización por cancelación. El Administrador del Sistema. Ingresar al módulo de administrador. Obtener costos vigentes. Configurar los costos de penalización por cancelación de reserva. Flujo Alternativo Postcondicion El sistema guarda la nueva configuración

14 MODULO DE USUARIO CU06 Nombre del Caso de Uso Descripción Precondición Registro de usuarios al sistema El usuario se registra en el sistema para poder realizar Reservaciones. El usuario. Usuario no registrado. El usuario visita la página web. El usuario ingresa al módulo de Registro de Nuevo Usuario. El usuario llena el formulario de Registro. El usuario le da al botón guardar. Flujo Alternativo Postcondición El sistema guarda los datos en la base de datos El usuario queda registrado. CU07 Nombre del Caso de Uso Descripción Precondición Consulta de habitación disponible Consulta si en el Hotel hay una (o varias) habitaciones, dado un período de días. El usuario de la aplicación, que podría ser un empleado en recepción, o una posterior página web. Obtener todas las habitaciones disponibles para las fechas indicadas. Comprobar que haya suficientes disponibles de las categorias indicadas. Flujo Alternativo Si desea una habitacion individual, y no hay disponible, pero si una habitacion doble, se considerará disponible. Postcondición

15 CU08 Nombre del Caso de Uso Descripción Precondición Consumos de servicios telefónicos. El ciente realiza una llamada telefónicas. El cliente El cliente empieza la llamada, indicando si es nacional o internacional. El cliente habla por teléfono. El cliente termina la llamada, calculándose el tiempo de duración. Se incrementa el tiempo de la llamada a las anteriores. Flujo Alternativo Postcondicion MODULO DE EMPLEADO CU09 Nombre del Caso de Uso Consumo de servicios del minibar. El empleado reporta que el cliente consumió un producto Descripción del minibar y lo registra en el sistema. El empleado y el cliente. Precondición El cliente posee una habitación asignada. El cliente consume un producto del minibar. El personal del hotel reporta el consumo. El empleado incrementa el valor consumido a los anteriores. Flujo Alternativo Postcondicion CU10 Nombre del Caso de Uso Llegada de un cliente con reserva El cliente llega al hotel y el empleado le asigna una Descripción habitación. El Empleado. Precondición El cliente había realizado una reserva previamente. El empleado busca una habitación concreta y se marca como ocupada, y es asignada al cliente. Se reinicia el contador de llamadas desde la habitación. Flujo Alternativo Postcondicion El sistema marca la habitación como ocupada.

16 CU11 Nombre del Caso de Uso Descripción Precondición Cálculo de la factura Se calcula el precio total de la estancia y se presenta la factura al cliente. El empleado. Se calcula el tiempo total de llamadas. Se calcula el coste total de las llamadas realizadas. Se calcula el coste total de las bebidas consumidas por el cliente. Se calcula el coste total de las facturas. Se devuelve al cliente la factura, detallando los costes por cada apartado. Flujo Alternativo CU12 Nombre del Caso de Uso Descripción Precondición Salida del cliente. El cliente termina su estancia en el hotel. El cliente y el Empleado. Se presenta la factura (caso de uso: Cálculo de la factura). Se inicializa el tiempo de llamadas de la habitación libre. Se reponen los contadores de las bebidas disponibles del minibar. Se marca la habitación como libre, incrementándose el número de habitaciones disponibles del hotel. Flujo Alternativo Postcondicion El sistema marca la habitación como libre.

17 MODULO DE RESERVA CU13 Nombre del Caso de Uso Descripción Precondición Cancelar Reserva Cancelar una reserva realizada con antelacion. El usuario de la aplicación, que podría ser un empleado en recepción, o una posterior página web. Para cancelar una reserva, habría que indentificarse con el código de reserva correspondiente. Que exista una reserva. Calcular el número de dias que faltan para el dia de la reserva. Calcular el coste en penalizacion. Cobrar el precio en la tarjeta de crédito. Marcar la habitación como disponible. Flujo Alternativo Postcondición El sistema cancela la reserva. El sistema marca la habitación como disponible. CU14 Nombre del Caso de Uso Reserva de habitación disponible Reserva si en el hotel hay una (o varias) habitaciones, Descripción dado un periodo de dias. El usuario de la aplicación, que podria ser un empleado en recepcion, o una posterior. Precondición Usuario Previamente registrado al sistema. Hay una (o más) habitaciones disponibles. El usuario indica servicios adicionales. Mostrar el coste de alojamiento estimado. Pedir confirmación al usuario. Si es que si, marcar la habitación para las fechas indicadas como reservada para esos dias. Devolver al cliente un código de reserva y un reporte de reserva. Flujo Alternativo Si no hay habitaciones disponible se le indica al usuario. Postcondicion El sistema marca la habitacion para las fechas indicadas. El sistema le retorna al usuario un reporte de reserva.

18 DIAGRAMAS DE CASOS DE USO

19

20 DISEÑO ARQUITECTONICO Página De Calendario Reservas Página de Registro Página De Registro Exitoso Página De Login Página Principal Página Reserva de Habitación Página de Confirmación de Reserva Módulo de Administración Página Opciones de Usuario Página Consulta de Reserva Página de Cancelación de Reservas Página Configuración de Precios Página Configuración de Tiempos Página de Reportes Módulo de empleado Página de Registro de Consumo Página de asignación de habitación

21 E5: CASOS DE PRUEBA Planificación de Casos de Pruebas: A continuación se especifican la planificación de los casos de prueba y las diferentes técnicas que se podrá utilizar en esta fase de pruebas del sistema para evaluar su correcto funcionamiento. Pruebas Unitaria: La función principal de estas pruebas es garantizar que cada modulo del sistema funciona correctamente por separado, por ejemplo: pruebas de que los usuarios se registran correctamente, o que pueden realizar reservaciones (incluyendo los casos en los que las fechas en hay habitaciones disponibles y en fechas en las que no hay habitaciones disponibles) entre otras pruebas características para cada modulo. Pruebas funcionales: En estas pruebas se busca evaluar los casos bordes para cada una de las funcionalidades del sistema, por ejemplo: los máximos tiempos posibles para reservar una habitación para un usuario, o los casos de los limites de llamadas telefónicas y consumibles del minibar y que garantice que la factura este calculada correctamente. Pruebas de intregación: En estas pruebas se busca comprobar el correcto funcionamiento del acoplamiento de los cuatro módulos que componen el sistema. Ejemplo de estas pruebas es iniciar sesión con un usuario registrado y realizar una reservación, en este caso se estarían integrando los módulos de usuario y el modulo de reserva. Pruebas de seguridad: La finalidad de estas pruebas es garantizar que un usuario manipulando los URL no pueda observar o modificar información que no le corresponde según su jerarquía, y, que el flujo normal de acceso de un usuario este limitado por sus privilegios en el sistema.

22 E6: PERSISTENCIA DE DATOS En esta primera entrega se realizo el diseño del diagrama E/R de la base de datos y la normalización del esquema, se presenta la descripcion de las entidades y las interrelaciones resultantes. DIAGRAMA ENTIDAD RELACIÓN DESCRIPCION DE LAS ENTIDADES USUARIO Descripción: Es el administrador del sistema o una persona que posee una cuenta registrada en la aplicación. Atributos: Id_usuario: secuencia de mínimo 8 y máximo 15 caracteres alfanuméricos. Clave: secuencia de mínimo 8 y máximo 15 caracteres alfanuméricos. Nombre: secuencia de hasta 15 caracteres alfabéticos. Apellido: secuencia de hasta 15 caracteres alfabéticos. Tipo_usuario: carácter. A: si es administrador. U: si es Usuario.

23 Cedula: Numérico de 8 dígitos. Dirección: Secuencia de hasta 100 caracteres alfanuméricos. HABITACION Descripción: Una habitación del hotel. Atributos: Numero_habitacion: secuencia de hasta 4 caracteres alfanuméricos. Categoría: Caracter alfabético. N = normal. B = Business. A =Alta. Tipo: Carácter alfabético. I = individual. D = Doble. Precio_noche: decimal. Estado: Carácter. L = libre, O = Ocupada. RESERVA Descripción: Representa una reserva de una habitación por un cliente del hotel. Atributos: Código: secuencia de 6 caracteres alfanuméricos. Estado_reserva: secuencia de hasta 10 caracteres alfabéticos. Cama_infantil: secuencia de 2 caracteres alfabéticos. SI o NO. Categoría_hab: Carácter alfabético. N = normal. B = Business. A =Alta. Tipo_h: Carácter alfabético. I = individual. D = Doble. Numero_noches: numérico. Fecha_ingreso: secuencia de 10 caracteres alfanuméricos. Formato DD/MM/AAAA. FACTURA Descripción: Al finalizar la estancia del cliente, se le suministrará la factura calculando el costo total de los servicios Atributos: Cod_factura: secuencia de 6 caracteres alfanuméricos. Total_alojamiento: Decimal. Total_llamada: Decimal. Total_minibar: Decimal. PRODUCTO Descripción: Son las diferentes bebidas disponibles en el minibar de una habitación. Atributos: Tipo_producto: secuencia de hasta 20 caracteres alfabéticos. Cantidad: numérico. LLAMADA Descripción: Llamadas telefónicas realizadas desde una habitación del hotel. Estas pueden ser nacionales o internacionales. Atributos: Código: secuencia de hasta 4 caracteres alfanuméricos. Tipo: carácter alfabético. N = Nacional, I =Internacional Minutos: numérico.

24 DESCRIPCION DE LAS INTERRELACIONES HACE_UNA Descripción: Un usuario hace una o varias reservas en el hotel y una reserva es hecha por un usuario. Grado: Binaria SE_LE_ASIGNA Descripción: A un usuario se le asigna una o varias habitaciones en el hotel y una habitación es asignada a ninguno o máximo un usuario. Grado: Binaria EMITE Descripción: A un usuario se le emite una o varias facturas y una factura pertenece a un usuario. Grado: Binaria REALIZA_UNA Descripción: Desde una habitación del hotel se realiza ninguna, una o varias llamadas y una llamada es realizada desde una habitación del hotel. Grado: Binaria TIENE_CONSUMO Descripción: Una habitación tiene consumo registrado de ninguno o varios productos del minibar y un producto del minibar es consumido por una habitación. Grado: Binaria BASE DE DATOS (RELACIONES RESULTANTES) Usuario (id_usuario, clave, tipo_usuario, nombre, apellido, cedula, teléfono, dirección) Habitación (numero_habitacion, tipo, categoría, precio_noche, estado) Reserva (código, estado_reserva, cama_infantil, categoría_hab, tipo_h, fecha_ingreso, numero_noches) Factura (cod_factura, total_alojamiento, total_llamada, total_minibar) Producto (tipo_producto, cantidad) Emite (id_usuario, cod_factura) Hace_una (id_usuario, codigo) Realiza_una (numero_habitacion, codigo) Tiene_consumo (numero_habitacion, tipo_producto, precio)

25 RELACIONES CON CLAVES COMPUESTAS Emite (id_usuario, cod_factura) Clave primaria Clave Foránea Clave Foránea Clave alterna o candidata Id_usuario, cod_factura Id_usuario (en Usuario) Cod_factura (en Factura) No posee Hace_una (id_usuario, codigo) Clave primaria Clave Foránea Clave Foránea Clave alterna o candidata id_usuario, codigo Id_usuario (en Usuario) Código (en Reserva) No posee Realiza_una (numero_habitacion, codigo) Clave primaria Clave Foránea Clave Foránea Clave alterna o candidata numero_habitacion, codigo numero_habitacion (en Habitacion) Código (en Llamada) No posee Tiene_consumo (numero_habitacion, tipo_producto, precio) Clave primaria Clave Foránea Clave Foránea Clave alterna o candidata numero_habitacion, tipo_producto numero_habitacion (en Habitación) Tipo_producto (en Producto) No posee

26 E8: Instrucciones de Instalación A continuacion se presentan los pasos a seguir para la instalación de las diferentes tecnologias a utilizar para el desarrollo del proyecto. En proximas entregas puede ser necesario utilizar tecnologias adicionales. 1. Descargar: 1. XAMPP 2. Yii Framework Netbeans All 2. Instalacion 1. Instalar primero XAMPP. 2. Abrir XAMPP Control y activar el MySQL, Apache y verificar que la pagina abra. En caso que el Apache no arranque verificar que ningun proceso este usando los puertos 80 (Skype) 1. Configurar el PHP y el Xdebug: 1. Ir a esta pagina y seguir las intrucciones. 2. Abrir el archivo php.ini que se encuentra en C:/xampp/php y buscar las siguientes lineas y descomentarla (borrar el ";" ), en algunos casos se tendra que cambiar el valor (ejemplo: xdebug.remote_enable=0 debe ser un 1) 1. xdebug.remote_enable=1 2. xdebug.remote_handler=dbgp 3. xdebug.remote_mode=req 4. xdebug.remote_host= xdebug.remote_port= Reiniciar el servidor. 2. Colocar la carpeta Yii dentro de C:/xampp/htdocs 3. Agregar el Path de Yii y PHP al sistema (Windows) 1. Control Panel> System > Advanced System Settings > Environment Variables > Path > Edit 2. Pegar al final las rutas de PHP y el framework de Yii separadas por ";" (ejemplo: C:\xampp\php;C:\xampp\htdocs\yii\framework)