PROYECTO MULTIPLAN CAPTURA DE...

PROYECTO MULTIPLAN

CAPTURA DE REQUERIMIENTOS

GRUPO 01: JON EDER ARNAN

DAVINIA AIZCORBE

ALICIA HUARTE

DANIEL DURAN

AINARA GONZALEZ

AARON CASTELLANOS

JOSE LUIS TORRES

Grupo 01 Captura de requerimientos 19/Noviembre/2007

2

INDICE

1. Interfaz de usuario 1

1.1 DESCRIPCIÓN DEL PROYECTO 2 1.2 OBJETIVOS 2

2. Modelo de Casos de uso 3

2.1 ACTORES MULTIPLAN 4 2.1 CASOS DE USO DE LA AGENCIA 5 2.2 CASOS DE USO DE LOS RECEPCIONISTAS 6 2.3 CASOS DE USO DE LOS CLIENTES 7 2.4 DESCRIPCION DE CASOS DE USO 8 Alta_excursión 8 Baja_excursión 9 Modificar Excursión 10 Confirmar/Anular excursión. 11 Incluir hotel 12 Eliminar Hotel 13

Alta_viaje 14 Baja_viaje 15 Disponibilidad de reservas 16 Reservar_excursión 17 Cancelar reserva. 18 Verificar cliente 19 Abonar anticipo 20 Devolver Anticipo 21 Pagar resto excursión (80%) 22 Consultar_Reserva_Cliente 23

3. Modelo de dominio 24

3.1 diagrama de modelo de dominio 24


3

Este documento presenta el modelo de casos de uso (MCU) y el modelo de dominio (MD)

para la gestión de Multiplan. Además se añaden los casos de uso con una descripción de alto nivel.

1. Interfaz de usuario

La interfaz constará de un menú general que dé acceso en todo momento a cada uno de los

casos de uso del sistema a los que se pueda acceder según el tipo de usuario. La interfaz indicará sólo las posibilidades admisibles según el estado en el que el usuario se encuentre. Existirá una pantalla inicial en la cual nos dará la oportunidad de identificarnos para que el sistema evalué las posibles acciones que puede ejecutar el usuario.

2. Modelo de casos de uso

El proyecto que se nos ha encomendado es crear MULTIPLAN, un software que trata sobre la gestión de los viajes facultativos que puede realizar una agencia de viajes para los hoteles de una isla. Con este, se deberá administrar las excursiones, la agencia podrá dar de alta viajes y modificar los ya existentes, describiendo a estos y dándoles un nombre e identificador independiente. Para gestionar una nueva alta en un viaje hay que inscribirse como tarde la noche antes de la excursión y adelantar el 20% del importe total si se acepta la solicitud. El sistema también debe permitir a los clientes darse de baja hasta la noche anterior de la excursión y en este caso se les devolverá el importe ya abonado. El software de MULTIPLAN debe de ser capaz de además de lo dicho con anterioridad de poder ser consultado por los recepcionistas autorizados de los hoteles asignados a las excursiones, en estas consultas se les mostrará las reservas realizadas y la capacidad máxima y mínima de admisión para un viaje. Por último el sistema tiene que realizar la tarea de planificar los viajes que hayan cubierto el quórum mínimo necesario, las excursiones que no lleguen al limite establecido serán avaluadas y se les devolverá el importe adelantado a los clientes.


4

2.1 Actores de Multiplan

Hemos identificado tres tipos de actores para la gestión de Multiplan: usuario, recepcionista

y agencia. Los usuarios, son los contratantes de los viajes y sus reservas son controlados por el sistema. Los recepcionistas realizan la tramitación de las excursiones, y la gestión diaria del sistema. Por último, el Administrador, gestiona los datos sobre excursiones, viajes y acceso al sistema. La figura anterior muestra la jerarquía de actores de Multiplan.


5

2.1 Casos de Uso de la agencia.


6

2.2 Casos de Uso del Recepcionista


7

2.3 Casos de Uso del Cliente

Cliente


8

2.4 Descripción de Casos de Uso Caso de Uso: Alta_excursión Actores: Empleados Agencia Descripción: Los empleados de la agencia incluyen una nueva excursión. Precondición: La excursión no está dada de alta Postcondición: La excursión queda añadida a la lista de excursiones. Escenario principal (o curso normal de los eventos):

1. Empleados agencia: Introduce el nombre y descripción de la excursión. 2. Sistema: Muestra identificador, nombre y descripción de la excursión. 3. Sistema: Pide confirmación. 4. Empleados agencia: Confirma la operación. 5. Sistema: Guarda la excursión.

Extensiones (o cursos alternativos): Paso 4: Cancela la operación.


9

Caso de Uso: Baja_excursión Actores: Empleados Agencia Descripción: Los empleados de la agencia dan de baja la excursión en el sistema. Precondición: La excursión este dada de alta. Postcondición: Actualiza los datos después de dar de baja la excursión. Escenario principal (o curso normal de los eventos):

1. Empleados Agencia: Busca y selecciona, la excursión que desea dar de baja. 2. Sistema: Pide confirmación. 3. Empleados Agencia : Confirma la operación. 4. Sistema: Actualiza los datos.



10

Caso de Uso: Modificar Excursión Actores: Agencia. Resumen: La Agencia en función de la ocupación que ha habido en la ruta establecida inicialmente decide modificar el itinerario de la excursión optando por otro que puede tener mas interesados. Precondición: La excursión debe tener una ruta asignada. Postcondición: Le excursión queda modificada conteniendo un nuevo itinerario. Escenario principal

1. Empleados Agencia: La agencia decide modificar una excursión. 2. Sistema: Muestra la lista de excursiones que contiene. 3. Empleados Agencia: Selecciona la excursión de la lista de excursiones. 4. Sistema: Muestra la excursión seleccionada. 5. Empleados Agencia: Realiza las modificaciones pertinentes en la excursión seleccionada,

itinerarios, lugares a visitar .. etc. 6. Sistema: pide confirmación 7. Empleados Agencia: confirma. 8. Sistema: El sistema recoge las modificaciones realizadas actualizando la descripción de la

excursión quedando la excursión modificada. Extensiones (o cursos alternativos): Paso 7: Cancela la operación.


11

Caso de uso: Confirmar/Anular excursión. Actores: Empleados Agencia. Resumen: La agencia consulta la base de datos donde aparece por cada hotel el número de reservas realizadas para una excursión determinada. Si la suma de todas las reservas hechas por los clientes de los hoteles supera el mínimo de ocupación exigido la excursión se confirma, en caso contrario la excursión quedaría anulada. Precondición: La excursión esta ofertada a cada uno de los hoteles de la isla. Postcondición: La excursión queda anulada o confirmada. Escenario principal:

1. Empleados Agencia: Consulta la bbdd. 2. Sistema: Devuelve las plazas reservadas y el número de plazas mínimas. 3. Empleados Agencia: Si el número plazas reservadas es mayor o igual al número de plazas

mínima. 4. Sistema: Pide confirmación 5. Empleados Agencia: Confirma el viaje

Extensiones (o cursos alternativos): Paso 3. Empleados Agencia: Si el número plazas reservadas es menor al número de plazas mínima. Paso 4. Sistema: Pide confirmación Paso 5. Empleados Agencia: Anula el viaje


12

Caso de uso: Incluir hotel Actores: Empleado Agencia Resumen: Un empleado de la agencia, añadirá un nuevo hotel a la cadena de hoteles. Precondiciones: El hotel a introducir no se encuentra en la cadena de hoteles. Postcondiciones: El hotel queda incluido en la lista de hoteles. Escenario principal:

1. EmpAgencia: Pone en marcha la aplicación para las altas, bajas y modificaciones de los

hoteles. 2. Sistema: Muestra la ventana de introducir un hotel nuevo. 3. EmpAgencia: Introduce el NIF y el nombre del nuevo hotel y lo añade a la lista de hoteles. 4. Sistema: El nuevo hotel queda registrado en la cadena de hoteles. 5. EmpAgencia: Cierra la aplicación.


13

Caso de uso: Eliminar Hotel. Actores: Agencia. Resumen: La agencia consulta la lista de hoteles a los que oferta las excursiones y elimina un hotel de la lista. Precondición: El hotel a eliminar esta en la lista de hoteles con la que la agencia de viajes trabaja. Postcondición: El hotel seleccionado queda eliminado de la lista. Escenario principal

1. Agencia: Consulta los hoteles a los que oferta las excursiones. 2. Sistema: Muestra la lista de hoteles de la agencia. 3. Agencia: Selecciona un hotel de la lista y lo elimina. 4. Sistema: Registra la modificación quedando la lista de hoteles sin el hotel eliminado.


14

Caso de Uso: Alta_viaje Actores: Empleados Agencia Descripción: Los empleados de la agencia incluyen un viaje para una excursión concreta. Precondición: La excursión debe estar dada de alta. Postcondición: El viaje queda incluido para dicha excursión. Escenario principal (o curso normal de los eventos):

1. Empleados Agencia: Busca la excursión donde queremos incluir el viaje. 2. Sistema: Muestra la lista de excursiones. 3. Empleados Agencia: Selecciona la excursión. 4. Empleados Agencia: Añade los datos del viaje: identificador, precio, ocupación mínima,

plazas máximas,…. 5. Sistema: Pide confirmación. 6. Empleados Agencia: Confirma la operación. 7. Sistema: Da de alta el viaje.



15

Caso de Uso: Baja_viaje Actores: Empleados Agencia Descripción: Los empleados de la agencia dan de baja un viaje en el sistema. Precondición: El viaje esta dada de alta. Postcondición: Actualiza los datos después de dar de baja el viaje, ya que se ha eliminado. Escenario principal (o curso normal de los eventos):

1. Empleados Agencia: Busca y selecciona, el viaje que desea dar de baja. 2. Sistema: Pide confirmación. 3. Empleados Agencia : Confirma la operación. 4. Sistema: Actualiza los datos.



16

Gestionar reservas: Caso de uso: Disponibilidad de reservas Actores: Cliente, Recepcionista Resumen: El recepcionista realiza una consulta del número de plazas disponibles para una excursión, proporcionando la hora de salida y de llegada. Precondiciones: El recepcionista debe estar identificado en el sistema para llevar a cabo la consulta. Postcondiciones: Muestra la disponibilidad de los viajes en el intervalo introducido. Escenario principal:

1. Cliente: Llega a la recepción para realizar la consulta. 2. Recepcionista: Iniciará la aplicación y preguntará al cliente el número de personas para

realizar el viaje, una fecha de salida y de llegada de la excursión. 3. Cliente: Le dará los datos al recepcionista. 4. Recepcionista: Introducirá en la aplicación el número de personas, la hora de salida de la

excursión y la hora de llegada, dadas por el cliente. 5. Sistema: Mostrará por pantalla la lista de excursiones cuyo número de plazas libres sean

num_max - num_ocupadas>=n (siendo n el número de personas que quieren hacer ese viaje).

6. Recepcionista: Dará la información al cliente y le preguntará si desea información sobre otras excursiones.

7. Cliente: Le dará una respuesta al recepcionista. 8. Recepcionista: Si la respuesta es afirmativa, volveremos al punto 2. De lo contrario cerrará

la aplicación.


17

Caso de uso: Reservar_excursión Actores: Cliente, recepcionista Resumen: El cliente acude al recepcionista para realizar una reserva de una excursión facilitándole al recepcionista los datos necesarios. El recepcionista realiza una consulta del número de plazas disponibles para una excursión, mediante los datos proporcionados por el cliente: tipo de excursión, número de personas, hora de salida y de llegada. Una vez comprobado que hay plazas, efectúa la reserva. Precondiciones: El recepcionista está identificado en el sistema para llevar a cabo la consulta y reserva de excursiones. Postcondiciones: La reserva queda realizada y el anticipo pagado. Escenario principal:

1. Cliente: llega a la recepción donde se llevan a cabo las reservas. 2. Recepcionista: iniciará la aplicación y realizará una nueva entrada en la gestión de reservas

del sistema. 3. Recepcionista: solicitará al cliente el dni, el nombre y su teléfono para verificar que

efectivamente está alojado en el hotel y le preguntará el número de personas que entrarán dentro de la reserva y la fecha de salida y de llegada al hotel.

4. Cliente: le da los datos al recepcionista. 5. Recepcionista: introducirá los datos del cliente. 6. Sistema: Uses: Verificar_cliente 7. Recepcionista: Si el cliente está alojado le preguntará al cliente el nombre de la excursión

(tipo). 8. Cliente: le facilitará ahora el nombre de la excursión. 9. Recepcionista: introducirá el nombre de la excursión. 10. Sistema: Uses: Disponibilidad_reservas 11. Recepcionista: Si hay plazas, le pedirá confirmación al cliente. 12. Cliente: Le dará una confirmación o anulación de la reserva de la misma, al recepcionista. 13. Recepcionista: aceptará la reserva en el caso de que la confirme el cliente, de lo contrario,

pasaremos directamente al punto 15. 14. Sistema: se registrará la reserva, con un número que la identifique, y de pondrá tanto el

pago previo como el pago total a falso, hasta que realice cada uno de ellos. Uses: Abonar_anticipo

15. Recepcionista: Tanto si ha anulado la reserva como si la ha confirmado, le dará opción de nuevo a realizar otra reserva.

16. Cliente: Le contestará al recepcionista si desea realizar otra reserva. 17. Recepcionista: Si el cliente responde que sí, le solicitará el nombre de otra excursión y se

volverá al punto 8. Si no, cerrará la aplicación. Extensiones (o cursos alternativos): Paso 7: Si el cliente no está alojado, le comunicará que no se puede realizar la reserva y cerrará la aplicación; de lo contrario, le preguntará al cliente el nombre de la excursión (tipo). Paso 11: Si no hay plazas, le dará opción al cliente de elegir otra excursión, si quiere se vuelve al paso 7 y si no se acaba.


18

Caso de uso: Cancelar reserva. Actores: Cliente-Recepcionista. Resumen: Un cliente del hotel solicita la cancelación de una reserva. El Recepcionista tras verificar que es cliente y que está hecha la reserva, la anula. Precondiciones: El recepcionista ha iniciado sesión, y la reserva debe estar hecha. Postcondiciones: Se ha eliminado la reserva de un viaje de un cliente. Escenario Principal:

1. Cliente: llega un cliente que quiere cancelar la reserva de su viaje a la recepción del hotel. El cliente se identifica, he identifica el viaje que había reservado.

2. Recepcionista: verifica que si es cliente del hotel. Uses: verificar cliente. 3. Sistema: presenta por pantalla la información del cliente y las reservas realizadas de los

viajes. Uses: Consultar reserva cliente. 4. Recepcionista: verifica la reserva del viaje identificado por el cliente y lo cancela. 5. Sistema: Disminuye en uno el número de reservas para ese viaje. 6. Recepcionista: Devuelve al cliente el anticipo del 20% realizado en la reserva. Uses:

Devolución anticipo. Extenciones (o Cursos alternativos): Paso 2: El supuesto cliente, no es cliente del hotel.


19

Caso de uso: Verificar cliente Actores: Recepcionista. Resumen: Dado un cliente el sistema comprueba si este es o no cliente del hotel. Precondiciones: El recepcionista ha iniciado sesión y tiene la identidad de un cliente. Postcondiciones: El sistema presenta la información del cliente si este es verdaderamente un cliente del hotel. Escenario Principal:

1. Recepcionista: introduce en el sistema la identidad del cliente. 2. Sistema: consulta en la base de datos del hotel la identidad introducida corresponde a un

cliente. Si es cliente del hotel, presenta por pantalla la información correspondiente a ese cliente.

Extensiones (o Cursos alternativos): Paso 2: Si el supuesto cliente no es cliente de ese hotel el sistema presenta por pantalla una advertencia de que la identidad no se encuentra en la base de datos.


20

Caso de uso: Abonar anticipo Actores: Cliente, recepcionista Resumen: antes de finalizar una reserva el cliente deberá abonar el 20% del total del viaje para dar la reserva por valida Precondiciones: Debe estar en curso el alta de la reserva y haberse facilitado los datos del cliente y de la excursión. Postcondiciones: Se dará por pagado el anticipo del viaje. Escenario principal:

1. Recepcionista: Comprobara en el sistema el coste del anticipo y se lo comunicara al cliente. 2. Cliente: Abonará el importe solicitado por el recepcionista. 3. Recepcionista: El recepcionista seguirá tramitando el alta de la reserva una vez sido

cobrado el anticipo. Extensiones (o cursos alternativos): Paso 2: En caso de no tener dinero suficiente para realizar el anticipo, el recepcionista anulará la reserva que esta en curso.


21

Caso de uso: Devolver Anticipo Actores: Cliente, Recepcionista Descripción: El cliente llega donde el recepcionista y le pide la devolución de x anticipos. El recepcionista verifica que estaba apuntado a una excursión y que había pagado el anticipo y le devuelve el dinero. Precondición: El recepcionista esta autorizado. Postcondicion: El cliente se va con el dinero del anticipo. Escenario Principal (o curso normal de los eventos)

1. Cliente: Va a donde la recepcionista a pedir la devolución del anticipo de la excursión de x personas.

2. Recepcionista: Verifica en el sistema que el cliente esta inscrito en una excursión y que ha realizado el anticipo.

3. Recepcionista: Cancela el anticipo en el sistema y la inscripción en la excursión El recepcionista repite los pasos 2 a 3 hasta cancelar los x anticipos

4. Recepcionista: Devuelve el dinero al cliente. 5. Cliente: Se marcha con el dinero de los x anticipos.

Extensiones (o cursos alternativos) Paso 2: Cliente no inscrito en la excursión o sin pagar anticipo. 1-El recepcionista indica al cliente que no se le devuelve el anticipo por dicho motivo.


22

Caso de uso: Pagar resto excursión (80%) Actores: Cliente, Recepcionista Descripción: El cliente llega donde el recepcionista y le indica que quiere realizar el pago de la excursión de x personas. El recepcionista verifica que todos están apuntados en la excursión y recibe el cobro. Precondición: El recepcionista esta autorizado. Postcondición: El recepcionista recibe el cobro de la excursión. Escenario Principal (o curso normal de los eventos)

1. Cliente: Va a donde la recepcionista y le indica que quiere pagar una reserva de excursión de x personas.

2. Recepcionista: Verifica en el sistema que el cliente esta inscrito en una excursión. El recepcionista repite el pasos 2 x veces.

3. Recepcionista: Indica el importe a pagar al cliente. 4. Cliente: Efectúa el pago. 5. Recepcionista: Registra el pago de la persona en la excursión

El recepcionista repite este paso x veces. Extensiones (o cursos alternativos) Paso 2: Cliente no inscrito en la excursión. 1-No se permite realizar el pago.


23

Caso de Uso: Consultar_Reserva_Cliente Actores: Recepcionistas hotel, cliente Descripción: Consulta las reservas que tenga hechas un cliente Precondición: … Postcondición: El cliente sabe que reserva tiene hecha. Escenario principal (o curso normal de los eventos):

1. Cliente: El cliente se identifica al recepcionista. Uses: Verificar_cliente 2. Recepcionista: El recepcionista mete los datos del cliente en el sistema. 3. Sistema: Devuelve la lista de reservas del cliente. 4. Recepcionista: Comunica al cliente las reservas que tiene.


24

3. Modelo de dominio

PROYECTO MULTIPLAN CAPTURA DE...

Documents

Transcript of PROYECTO MULTIPLAN CAPTURA DE...