1 Ingeniería del Software Solución Examen Junio 2009  Ejercicio MasTer (1h 20 min.)  Modelo Casos de Uso (2,5 puntos) Diagrama Casos de Uso Casos de.

Presentación del tema: "1 Ingeniería del Software Solución Examen Junio 2009  Ejercicio MasTer (1h 20 min.)  Modelo Casos de Uso (2,5 puntos) Diagrama Casos de Uso Casos de."— Transcripción de la presentación:

1 1 Ingeniería del Software Solución Examen Junio 2009  Ejercicio MasTer (1h 20 min.)  Modelo Casos de Uso (2,5 puntos) Diagrama Casos de Uso Casos de Uso de Alto Nivel Un caso de uso expandido  Modelo de Dominio (1,5 puntos)

2 2 Ingeniería del Software Actores SECRETARIO TERAPEUTA

3 3 Ingeniería del Software Identificar usuario Gestionar Terapias: consulta, alta, modificación, etc. Gestionar Terapeutas: consulta, alta, modificación, baja, etc. –En modificar terapias Gestionar Terapias de Terapeuta (o Terapeutas de Terapia) Gestionar Clientes: consulta (datos personales), alta, modificación, etc. Gestionar Citas: consulta (consultar agenda), alta (pedir cita), cancelación, etc. Gestionar Observaciones: consulta, alta (Registrar Observaciones), etc. Cobrar Sesión...

4 4 Ingeniería del Software Actor Secretario

5 5 Ingeniería del Software Actor Terapeuta

6 6 Ingeniería del Software Casos de uso de alto nivel (1) Caso de uso:Identificar Usuario Actores:SECRETARIO, TERAPEUTA Descripción:Cada usuario (Secretario o Terapeuta) debe identificarse para acceder al sistema MasTer. Caso de uso:Gestionar Terapias Actores:SECRETARIO Descripción:El sistema permite Consultar el conjunto de Terapias ofertadas por el centro, Crear nuevas terapias, Modificar las terapias existentes, Ofertar terapias y Dejar de ofertar terapias.

7 7 Ingeniería del Software Casos de uso de alto nivel (2) Caso de uso:Gestionar Terapeutas Actores:SECRETARIO Descripción:El sistema permite Consultar los terapeutas que ofrecen terapias en el centro, Dar de alta nuevos terapeutas, Modificar los datos de los terapeutas, Suspender la actividad de los terapeutas, etc. Caso de uso:Gestionar las Terapias de un Terapeuta Actores:SECRETARIO Descripción:El sistema permite consultar las terapias asignadas a un terapeuta, asignar y desasignar terapias que estén en oferta a terapeutas en activo.

8 8 Ingeniería del Software Casos de uso de alto nivel (3) Caso de uso:Gestionar Clientes Actores:SECRETARIO Descripción:El sistema permite Consultar los datos personales de los clientes (Consultar Clientes), Dar de alta clientes nuevos y Modificar los datos personales de los clientes. Al cliente se le piden sus datos personales (nombre, dirección, fecha de nacimiento...) al realizar la primera cita. Caso de uso:Gestionar Citas Actores:SECRETARIO Descripción:El sistema permite consultar las citas asignadas a un terapeuta (Consultar agenda), Dar de alta nuevas citas (Pedir cita), modificar citas y cancelar citas, etc.

9 9 Ingeniería del Software Casos de uso de alto nivel (4) Caso de uso: Pedir Cita Actores:SECRETARIO Descripción:El sistema permite gestionar las peticiones de cita que realizan los clientes tanto en la sede del Centro como por teléfono. Al pedir cita para la terapia que necesita, el cliente puede mostrar su preferencia por uno de los diferentes terapeutas que realizan esa terapia y señalar la fecha o la hora que le conviene. El secretario dará las citas según las posibilidades de la agenda. Caso de uso:Consultar Agenda Actores:SECRETARIO, TERAPEUTA Descripción:Cada terapeuta puede consultar su agenda de citas para organizar su trabajo. El sistema permite consultar las citas asignadas a un terapeuta.

10 10 Ingeniería del Software Casos de uso de alto nivel (5) Caso de uso: Gestionar Observaciones Actores:TERAPEUTA Descripción:El sistema permite consultar las observaciones asignadas a un cliente. Al terminar la sesión el terapeuta registra las observaciones que considere oportunas. Caso de uso: Cobrar Sesión Actores:SECRETARIO Descripción:El secretario dará las citas según las posibilidades de la agenda y cobrará a los clientes al finalizar cada sesión.

11 11 Ingeniería del Software Modelo de dominio Ingeniería del Software Modelo de dominio

12 12 Ingeniería del Software Solución Examen Junio 2009  Ejercicio Vehículo más rentable (1h 20 min.)  Análisis (1,5 puntos): Diagrama Secuencia Sistema Contratos  Diseño (2,5 puntos): Diagramas de Secuencia

13 13 Ingeniería del Software Diagrama secuencia sistema

14 14 Ingeniería del Software Name:OR(fechaI, fechaF) : ListaRentabilidades  Responsabilities Obtener para cada tipo de vehículo la información sobre su rentabilidad en el periodo establecido, ordenados descendentemente por rentabilidad. Para cada tipo de vehículo, el Sistema obtiene su identificador, nombre, número de vehículos de ese tipo, importe total de las reservas realizadas en el periodo y su rentabilidad.  Preconditions Las fechas fechaInicio y fechaFin son válidas, fechaInicio<=fechaFin  Postconditions  Salida ListaRentabilidades = Lista( ) donde idTV = Identificador Tipo Vehículo NV = número vehículos del tipo TI = Importe total de las reservas realizadas en el periodo R = rentabilidad

15 15 Ingeniería del Software Name:ORV(id) : ObtenerRentabilidadVehículo  Responsabilities Obtiene para el tipo de vehículo seleccionado, su identificador, nombre, número de vehículos de ese tipo, kilometraje total, tiempo total, número de reservas no canceladas, importe total de las reservas realizadas en el periodo y su rentabilidad.  Preconditions Se dispone de fechaI, fechaF del periodo id es un código válido de tipo de vehículo  Postconditions  Salida RentabilidadVehículo = ) donde NV = número de vehículos Tkm = kilometraje total TT = Tiempo total NR = número de reservas no canceladas IT = Importe total R = Rentabilidad

16 16 Ingeniería del Software

17 17 Ingeniería del Software 1) Escogemos el patrón controlador para gestionar el evento externo ObtenerRentabilides (OR). Aunque otras opciones son posibles, a falta de más información sobre otros casos de uso, seleccionamos el controlador de caso de uso y creamos una clase artificial GestorOR. Además, esta clase artificial tiene acceso directo a todas los Tipos de Vehículos y gestiona la estructura auxiliar RTV (Rentabilidades por Tipo de Vehículo). Esta estructura almacenará para cada TipoVehículo su identificador, su nombre, TI (importe total reservas del periodo consultado), R (rentabilidad del periodo consultado). Buscando un comportamiento más eficiente para el Caso de Uso y un menor esfuerzo de implementación, esta estructura también guardará otros datos que podemos necesitar en la siguiente operación ORV y que pueden precalcularse en esta primera operación OR. Así, está estructura auxiliar almacenará además, NV (el número de vehículos de ese tipo), TKm (Total Kms), TT (Total Tiempo) y NR (Número de reservas no canceladas). Con ello pretendemos un diseño global con alta cohesión, bajo acoplamiento y máxima eficiencia.

18 18 Ingeniería del Software 2) Por el patrón experto, el método OR de GestorOR recorre todos los TipoVehículo. seleccionamos la clase TipoVehículo para agrupar por tipo de vehículo sus rentabilidades. Así, para cada uno de los tipos de vehículo se debe obtener su identificador y nombre. Además, también debe obtenerse el número de vehículos de ese tipo NV (TipoVehículo conoce todos los vehículos de su clase a través de las Tarifas), y dadas las fechas iniciales y finales del periodo, el importe total de las reservas realizadas en dicho periodo -TI- (de cada Vehículo podemos conocer sus reservas e importes) y su rentabilidad -R-. La rentabilidad es el importe total por tipo de vehículo dividido por el número de vehículos de ese tipo. Además, TKm (Total Kms), TT (Total Tiempo) y NR (Número de reservas no canceladas). Aunque las tarifas deberían ser de periodos disjuntos, los mismos vehículos pueden repetirse en tarifas distintas de periodos distintos. Es por ello que la operación OR de TipoVehículo, debe eliminar los vehículos repetidos. Tras obtenerse todas las rentabilidades de los distintos tipos de vehículo, estas deben ordenarse. 3) Por el patrón experto, el método OR de Tarifa recorre todos las Tarifas asociadas al TipoVehículo. Deben seleccionarse aquellas tarifas que sean de aplicación en el periodo consultado.

19 19 Ingeniería del Software 4) Por el patrón experto, el método OR de Vehículo, accede a los distintos vehículos de un mismo TipoVehículo y recorre todas las reservas no canceladas y que se hayan realizado en el periodo de consulta acumulando los importes -TIV-, kilómetros -TKmV-, tiempo total -TTV- y número total de reservas no canceladas -NRV-. 5) Por el patrón experto, el método OR de Reserva obtiene el importe de la reserva, los kilómetros realizados por el vehículo y el tiempo total de uso.

20 20 Ingeniería del Software

21 21 Ingeniería del Software Escogemos el patrón controlador para gestionar el evento externo ORV (Obtener Rentabilidad Vehículo). Aunque otras opciones son posibles, seleccionamos el mismo controlador de caso de uso: GestorOR. Además, esta clase artificial gestiona la estructura auxiliar RTV (Rentabilidades por Tipo de Vehículo). Esta estructura almacenará para cada TipoVehículo su identificador, su nombre, TI (importe total reservas del periodo consultado), R (rentabilidad del periodo consultado), NV (el número de vehículos de ese tipo), TKm (Total Kms), TT (Total Tiempo) y NR (Número de reservas no canceladas). Por el patrón experto, el método ObternerInformaciónVehículo accede a la información del tipo de vehículo almacenada en la estructura auxiliar y precalculada en la anterior operación.