PDS Práctica 2

Informe Técnico

Adrián Morales Torrano

José Luis Serrano Salcedo

Grupo 1.1
1. Modelo de Negocio
2. Modelo de Casos de Uso

ACTOR ACCIÓN

Ayuntamiento 1. Validar campeonato

Federación 1. Solicitar campeonato de Legocars

2. Enviar justificante de pago
3. Asignar horarios de participación a los equipos
4. Gestionar los coches del campeonato
5. Consultar información sobre las tripulaciones
6. Registrar resultado de carrera y generar diplomas
7. Solicitar carrera final.
8. Registrar resultado de la carrera final.
9. Confirmar Reserva

Asistente 1. Evaluar a la tripulación

Administrador 1. Iniciar carrera en el sistema

2. Autorizar publicación de mensajes en tiempo real

Tripulación 1. Indicar tipos de coches

Equipo 1. Reservar circuito

Sistema 1. Enviar factura por carrera

2. Crear equipo
3. Registrar tripulación
3. Modelo de Dominio

4. Especificación Complementaria

4.1 Requisitos funcionales

4.2 Requisitos no funcionales

4.3 Restricciones de diseño

4.4 Reglas de negocio

5. Detalles de los Casos de Uso

5.1 Validar Campeonato

5.2 Solicitar campeonato de Legocars

5.3 Enviar justificante de pago

5.4 Asignar horarios de participación a los equipos

5.5 Gestionar los coches del campeonato

5.6 Consultar información sobre las tripulaciones

5.7 Registrar resultado de carrera y generar diplomas

Caso de Uso: Registrar resultado de carrera y generar diplomas.

Resumen: La federación calcula el resultado final de una carrera y genera el diploma a
los participantes de la misma.
Actor Principal: Federación.
Personal involucrado e Intereses:
- Federación: Quiere registrar las posiciones finales de una carrera.
- Tripulación: Ha participado en una carrera.
Precondiciones:
- Existe una instancia de Carrera “c” que cumpla que c = carrera.
- c.estado = En Progreso
Postcondiciones:
- c.estado = Finalizada
Flujo Básico:
1. La federación solicita registrar el resultado de una carrera.
2. El sistema calcula el resultado de la carrera y actualiza los rankings de cada
equipo y tripulación participante
3. El sistema actualiza cada equipo y tripulación participante en el ranking
4. El sistema establece el estado de la carrera a Finalizada.
 5. Se genera un diploma a cada tripulación participante en la carrera.
Flujos Alternativos: -

Nombre: calcularResultado(carr: Carrera)

Referencias: Registrar resultado de carrera y generar diplomas.
Controlador: ControladorCarrera.
Precondiciones:
- Existe una instancia de Carrera “c” que cumpla que c = car.
- c.estado = En Progreso
Postcondiciones:
- c.estado = Finalizada

Nombre: generarDriploma(carr: Carrera, t: Tripulacion)

Referencias: Registrar resultado de carrera y generar diplomas.
Controlador: ControladorCarrera.
Precondiciones:
- La Tripulación “t” debe de estar registrada en el sistema.
- La Tripulación “t” debe de haber participado en el sistema.
- carr.estado = Finalizada
Postcondiciones: -
5.7.1 DSS

5.7.2 Contrato-calcularResultado

5.7.3 Contrato-generarDiploma
5.8 Solicitar realización de carrera final

Caso de Uso: Solicitar realización de carrera final.

Resumen: Tras finalizar el campeonato, la federación solicitará una carrera final de
exhibición con los dos equipos mejor clasificados y se seleccionará de manera
aleatoria un piloto de cada equipo para realizarla.
Actor Principal: Federación.
Personal involucrado e Intereses:
- Equipo: Los dos equipos mejor clasificados son los que tendrán a sus pilotos
corriendo.
- Piloto: Dos pilotos serán los que corran en la carrera.
Precondiciones:
- El campeonato está finalizado.
Postcondiciones:
- Se creará un objeto de CarreraFinal “cf”.
- Se escogen dos pilotos aleatoriamente de los dos equipos.
- cf.piloto1 = piloto1.
- cf.piloto2 = piloto2.
- cf.vueltas = 4.
Flujo Básico:
1. Federación solicita carrera final.
2. El Sistema selecciona los 2 mejores equipos.
3. Escoge 2 pilotos aleatorios de esos 2 equipos.
Flujos Alternativos:
1-3a. La Federación decide cancelar la carrera final.
1. Se aborta el proceso.

Nombre: solicitarCarreraFinal()
Referencias: Solicitar realización de carrera final.
Controlador: ControladorCarrera.
Precondiciones:
- El campeonato está finalizado.
Postcondiciones:
- Se crea un objeto de CarreraFinal “cf”.
Nombre: seleccionarPilotoAleatorio()
Referencias: Solicitar realización de carrera final.
Controlador: ControladorCarrera.
Precondiciones:
- El equipo tiene pilotos registrados en el sistema.
- Existe un objeto de tipo CarreraFinal.
Postcondiciones:
- Dos objetos “Piloto” se enlazan al objeto de CarreraFinal.
- cf.piloto1 = piloto1.
- cf.piloto2 = piloto2.
- cf.vueltas = 4.

5.8.1 DSS
5.8.2 Contrato-solicitarCarreraFinal

5.8.3 Contrato-seleccionarPilotoAleatorio
5.9 Registrar resultado de la carrera final.

Caso de Uso: Registrar resultado de la carrera final.

Resumen: La federación registrará el resultado de la carrera final. Después se
conceden premios al equipo campeón y subcampeón. Se concede una ayuda a
cualquier integrante del equipo que esté desempleado.
Actor Principal: Federación.
Personal involucrado e Intereses:
- Federación: Registra el resultado final de la carrera final.
- Equipo: Quiere poder recibir el premio que ha conseguido uno de sus pilotos en
la carrera final.
- Piloto: Quiere poder recibir su parte del premio y su ayuda adicional si cumple
los requisitos.
Precondiciones:
 - La carrera es de tipo CarreraFinal
Postcondiciones:
- El resultado de la carrera final ha sido registrado en el sistema.
- El sistema ha repartido los premios a los equipos del campeón y subcampeón.
- Se ha repartido el premio entre los integrantes del equipo.
- Se ha repartido una ayuda adicional a los pilotos desempleados.
Flujo Básico:
1. La federación registra el resultado de la carrera final en el repositorio de
resultados.
2. Existen los equipos “camp” y “subCamp” en el sistema, siendo el equipo
campeón y subcampeón ganadores de la carrera final respectivamente.
3. Se concede el respectivo premio al equipo campeón.
4. Se concede el respectivo premio al equipo subcampeón.
Para cada uno de los equipos anteriores:
5. Se reparte el premio entre todos los integrantes del equipo.
Para cada piloto que cumpla los requisitos de desempleo:
6. Se concede la ayuda a los pilotos desempleados.
Flujos Alternativos: -

Nombre: registrarResultado(idCarrera: int)

Referencias: Registrar resultado de la carrera final.
Controlador: ControladorCarreraFinal.
Precondiciones:
- Existe una instancia de Carrera “c” con c.id = idCarrera.
- La carrera “c” debe tener un resultado final.
Postcondiciones:
- El resultado de la carrera “c” se ha registrado en el sistema.
- Se ha actualizado la instancia “r” de Ranking de la carrera.

Nombre: concederPremio(equipo: Equipo, idCarrera: int)

Referencias: Registrar resultado de la carrera final.
Controlador: ControladorCarreraFinal.
Precondiciones:
 - Existe una instancia de Carrera “c” con c.id = idCarrera.
- La instancia de Equipo “e” ha participado en la carrera y es campeón o
subcampeón.
Postcondiciones:
- La instancia de Equipo “e” ha recibido correctamente su premio.
- La instancia “e” ha registrado el premio en su colección de premios.
- Para cada instancia de Piloto “p” perteneciente a la instancia “e”, se ha repartido
el premio equitativamente.

Nombre: concederAyudaAdicional(idPiloto: int)

Referencias: Registrar resultado de la carrera final.
Controlador: ControladorCarreraFinal.
Precondiciones:
- Existe una instancia de Carrera “c” con c.id = idCarrera.
- La instancia “p” contiene el campo p.isEmpleado = false.
Postcondiciones:
- La instancia de Piloto “p” ha recibido la ayuda adicional por ser desempleado.

5.9.1 DSS
5.9.2 Contrato-registrarResultado

5.9.3 Contrato-darPremio
5.9.4 Contrato-otorgarAyuda

5.10 Confirmar Reserva

Caso de Uso: Confirmar reserva.

Resumen: Confirma o niega la reserva de un equipo para un circuito en una fecha.
Actor Principal: Federación.
Personal involucrado e Intereses:
- Federación: Quiere aceptar las reservas de equipos para circuitos.
Precondiciones:
- Existe una instancia de Reserva “r” que cumpla r.id = idReserva.
- r.estado = Pendiente.
Postcondiciones:
1. El estado de Reserva “r”, r.estado, será Autorizada o Denegada según la decisión
de la Federación.
Flujo Básico:
1. El sistema muestra la reserva a la federación.
2. La federación acepta la reserva.
 3. Se cambia el estado de la reserva a Autorizada.
Flujos Alternativos:
2a. La federación deniega la reserva.
1. Se cambia el estado de la reserva a Denegada.

Nombre: aceptarReserva(idReserva: ID)

Referencias: Confirmar reserva.
Controlador: ControladorReserva
Precondiciones:
- Existe una instancia de Reserva “r” que cumpla r.id = idReserva.
- r.estado = Pendiente.
Postcondiciones:
- Se ha modificado el estado de la reserva a Autorizada.

Nombre: rechazarReserva(idReserva: ID)

Referencias: Confirmar reserva.
Controlador: ControladorReserva
Precondiciones:
- Existe una instancia de Reserva “r”.
- r.id = idReserva.
- r.estado = Pendiente.
Postcondiciones:
- Se ha modificado el estado de la reserva a Denegada.
5.10.1 DSS

5.10.2 Contrato-validarReserva
5.10.3 Contrato-rechazarReserva

5.11 Evaluar una tripulación

Caso de Uso: Evaluar una tripulación.

Resumen: Un asistente otorga una calificación a una tripulación con un comentario
opcional.
Actor Principal: Asistente.
Personal involucrado e Intereses:
- Asistente: Un asistente que quiera calificar a una tripulación
Precondiciones:
- Existe una Tripulacion “t” que cumpla t = trip.
- La calificación “cal” es un número entre 0 y 10.
- El comentario “com” tiene una longitud máxima de 80 caracteres.
Postcondiciones:
2. La tripulación tendrá asignado una nueva calificación
Flujo Básico:
 1. El asistente introduce una calificación y un comentario opcional a una
tripulación
2. El sistema comprueba que la tripulación existe
3. El sistema filtra doblemente el comentario opcional
4. El sistema crea una instancia de Calificación “c” que almacena.
5. El sistema asocia la nueva instancia de Calificación “c” a la Tripulación “t”.
Flujos Alternativos:
2a. La tripulación no existe.
1. No se realiza ninguna acción.
3a. El comentario está vacío o excede el máximo de caracteres.
1. No se realiza ninguna acción.
5.11.1 DSS
5.11.2 Contrato-otorgarCalificacion

5.12 Iniciar carrera en el sistema

5.13 Autorizar publicación de mensajes en tiempo real

5.14 Indicar tipos de coches

5.15 Reservar Circuito

Caso de Uso: Reservar un circuito

Resumen: Un equipo realiza una reserva de un circuito para entrenar en una fecha
determinada con un tipo de Legocar determinado.
Actor Principal: Equipo.
Personal involucrado e Intereses:
- Equipo: Realiza una reserva para una fecha y un tipo de Legocar.
Precondiciones:
- Un Circuito “c” debe de existir en una lista de circuitos
- El Equipo “e” con e.id = idEquipo debe existir
- El tipo de Legocar “tipoLegocar” debe ser válido
Postcondiciones:
3. El sistema habrá creado una instancia de Reserva “r” para el Equipo “e” al
circuito “c”.
Flujo Básico:
1. El equipo introduce sus datos, fecha de entrenamiento y el tipo de Legocar
para realizar la reserva.
2. Se busca en el sistema el circuito introducido para la fecha y tipo de Legocar.
3. Se crea una instancia de Reserva para el circuito y equipo.
Flujos Alternativos:
3a. No existe un circuito para la fecha y tipo de Legocar.
1. No se crea la reserva.

Nombre: reservarCircuito(idEquipo: ID, tipoLegocar: String, fecha: Date)

Referencias: Reservar circuito.
Controlador: ControladorReserva
Precondiciones:
- Existe una instancia de Equipo “e”.
- Existe una instancia de Circuito “c”.
- El campo “tipoLegocar” debe ser un tipo válido de legocar.
Postcondiciones:
- Una instancia de Reserva “r” se habrá creado.
- r.equipo = equipo.
- r.fecha = fecha.
- r.circuito = circuito.
5.15.1 DSS

5.15.2 Contrato-reservarCircuito
5.16 Enviar factura por carrera

5.17 Crear Equipo

Caso de Uso: Crear Equipo.

Resumen: Tres días antes de cada carrera, el equipo designará las tres tripulaciones
que participarán en ella.
Actor Principal: Equipo.
Personal involucrado e Intereses:
- Tripulación: Son las tripulaciones de cada equipo las que correrán en cada
carrera.
Precondiciones:
- Las tripulaciones deben estar previamente registradas en el sistema.
Postcondiciones:
4. Cada tripulación tendrá asignado un Legocar aleatorio del mismo tipo.
Flujo Básico:
1. El equipo selecciona tres tripulaciones para la carrera.
2. El sistema comprueba que las tripulaciones están registradas.
3. El sistema comprueba el tipo de Legocar asociado a la carrera.
4. El sistema asigna un Legocar de este tipo aleatoriamente a las tripulaciones.
Flujos Alternativos:
2a. El sistema no tiene información sobre alguna o todas las tripulaciones.
1. El sistema notifica al equipo que deben registrar las tripulaciones.
2. Se cancela la selección.

Nombre: designarTripulacion(t: Tripulacion)

Referencias: Crear Equipo.
Controlador: ControladorCarrera
Precondiciones:
- El objeto Tripulación “t” está registrado en el sistema.
Postcondiciones:
- Se asocia “t” al objeto Equipo y un objeto Carrera.

Nombre: asociarLegocar(): Legocar

Referencias: Crear Equipo.
Controlador: ControladorCarrera
Precondiciones:
- Tripulación “t” tiene objetos Legocar registrados en el sistema.
Postcondiciones:
- Se asocia un objeto aleatorio Legocar a “t”.
- t.legocar=l.

Nombre: otorgarCalificacion(t: Tripulacion, cal: float, com: String)

Referencias: Evaluar una tripulación.
Controlador: ControladorCalificaciones
Precondiciones:
- Existe una Tripulacion “t” que cumpla t = trip.
- La calificación “cal” es un número entre 0 y 10.
- El comentario “com” tiene una longitud máxima de 80 caracteres.
Postcondiciones:
- La tripulación tendrá asignado una nueva calificación
5.17.1 DSS

5.17.2 Contrato-designarTripulacion
5.17.2 Contrato-asociarLegocar

5.18 Registrar tripulación

Caso de Uso: Registrar tripulación.

Resumen: La tripulación se registra en el sistema introduciendo los datos de la misma
así como la de sus pilotos.
Actor Principal: Tripulación.
Personal involucrado e Intereses:
- Tripulación: Se registra en el sistema para participar en el campeonato.
Precondiciones:
- No puede existir una misma tripulación en el repositorio.
Postcondiciones:
5. El sistema ha registrado correctamente a los pilotos.
6. El sistema ha registrado correctamente a la tripulación.
Flujo Básico:
1. La tripulación introduce sus datos y los de sus pilotos.
 2. El sistema comprueba que los pilotos no estén duplicados en el sistema.
3. El sistema comprueba que la tripulación no esté duplicada en el sistema.
4. El sistema registra la tripulación en el repositorio
Flujos Alternativos:
2a. El sistema no encuentra los pilotos en el repositorio.
a. El sistema crea los pilotos y los guarda en el repositorio.
3a. La tripulación ya está registrada.
a. No se realiza ninguna acción.
4a. La tripulación ya está registrada.
a. No se realiza ninguna acción.

Nombre: registroTripulacion(icono: String, email: String, cPostal: int, piloto1: Piloto, piloto2:
Piloto, tipoLegocars[3]: String)
Referencias: Registrar tripulación.
Controlador: ControladorTripulacion
Precondiciones:
- Existe instancia de Piloto “p1” con p1.id = piloto1.id registrado en el sistema.
- Existe instancia de Piloto “p2” con p2.id = piloto2.id registrado en el sistema.
- No existe ninguna instancia de Tripulación “n” con n.email = email.
Postcondiciones:
- Se creó una instancia de Tripulación “n”.
- Se asociaron los pilotos “p1” y “p2” con la tripulación “n”.

Nombre: crearPiloto(nombre:String, fechaNacimiento:Date, nickname:String, isDesempleado:

boolean)
Referencias: Registrar tripulación.
Controlador: ControladorTripulacion
Precondiciones:
- No existe una instancia de Piloto “p” con p.nickname = nickname
Postcondiciones:
- Se crea una instancia de Piloto “p”.
5.18.1 DSS

5.18.2 Contrato-registrarPiloto
5.18.3 Contrato-registrarTripulacion

6. Diagrama de Clases del Diseño

7. Diagramas de Estado

7. Persistencia