UD02 · Práctica evaluable

Enunciado

Vamos a desarrollar el programa que gestiona la venta de entradas del Auditorio Municipal de Martos. Durante la temporada de invierno se celebran estos eventos:

Evento	Fecha	Platea	Butacas	Anfiteatro	Descuento anticipado
Las criadas	20/11/2026	17 €	20 €	13 €	5 %
II Concierto de Otoño	28/11/2026	12 €	15 €	8 €	7 %
Concierto de Jazz	06/12/2026	20 €	25 €	15 €	3 %

El auditorio tiene 540 localidades: 200 de platea, 200 de butacas y 140 de anfiteatro.

El menú

1. Vender entradas para un evento
2. Consultar el estado de un evento
3. Menú de administrador
     3.1. Consultar los ingresos totales por evento
     3.2. Consultar las monedas restantes para el cambio
     3.3. Apagar el software

El programa solo se puede apagar desde el menú de administrador, que además pide usuario y contraseña.

Requisitos

Venta de entradas

• Las entradas no son numeradas.
• Un comprador solo puede comprar entradas de un tipo en cada compra.
• Cada entrada lleva un código único para evitar falsificaciones. El sistema para generarlo os lo inventáis vosotros, pero tiene que combinar de alguna forma el evento, su fecha, el tipo de entrada, el número de entradas y la fecha de compra.
• Si se compran con 7 días o más de antelación, se aplica el descuento por venta anticipada del evento.

Cómo probar el descuento

Después de preguntar cuántas entradas se compran, preguntad en qué fecha se simula la compra. Si se responde no, se usa la fecha de hoy. Sin esa simulación no hay forma de probar el descuento sin cambiar la hora del ordenador.

La factura

Las entradas se muestran una a una: se imprime una, se pulsa Enter y aparece la siguiente. Cada una debe incluir:

• El número de entrada que se está imprimiendo, arriba (Entrada 2 de 4).
• Fecha y lugar del evento.
• Tipo de entrada: platea, butacas o anfiteatro.
• Los datos de vuestra empresa distribuidora y el código único generado.
• Una imagen del evento en ASCII.
• El precio de la entrada con el 10 % de IVA aplicado, sin el descuento.
• Si hay descuento por venta anticipada, en la línea siguiente.
• El total de esa entrada.

Al terminar de mostrarlas todas, se enseña el total de la compra, se pide con cuánto dinero se paga (solo efectivo) y, si hay que devolver cambio, se calcula con el menor número posible de monedas y billetes.

Consultar el estado de un evento

Al elegir un evento debe mostrarse:

• Entradas vendidas de cada tipo.
• Entradas libres de cada tipo.
• Días que faltan para el evento, indicando si todavía se está en periodo de descuento por venta anticipada.

Fechas

Necesitáis calcular días entre fechas. Se hace con el paquete java.time:

import java.time.LocalDate;
import java.time.temporal.ChronoUnit;

LocalDate hoy = LocalDate.now();
LocalDate evento = LocalDate.of(2026, 11, 20);

long diasQueFaltan = ChronoUnit.DAYS.between(hoy, evento);
boolean hayDescuento = diasQueFaltan >= 7;

Tenéis el anexo Fechas y horas en Java en la teoría de la unidad.

No uséis Date ni Calendar

Casi todo lo que encontraréis por internet sobre fechas en Java usa Date, Calendar y SimpleDateFormat. Son las clases antiguas, con un diseño confuso —entre otras cosas, los meses empiezan en 0— y sustituidas desde Java 8. Trabajad con LocalDate.

Entrega

Se entrega por Classroom:

1. El código fuente (.java), que debe ejecutarse sin errores.
2. Un manual de usuario en PDF: qué hace el programa, cómo se usa cada opción del menú y capturas de las pantallas principales.
3. Un vídeo corto (2-3 minutos) enseñando el programa funcionando: una venta con descuento, una sin él, y una consulta de estado.

Regla de oro

No se pueden usar elementos de programación que no hayamos visto en clase. Si aparece en vuestro código algo que no hemos dado, tendréis que explicar exactamente qué hace y por qué lo habéis usado; si no sabéis explicarlo, cuenta como no hecho.

Con lo visto en esta unidad tenéis todo lo necesario para resolver la práctica entera.

Defensa oral

Es obligatoria

Como todas las prácticas evaluables del módulo, hay que defenderla delante del profesor: os preguntaré por el código, por las decisiones que habéis tomado y por qué pasa lo que pasa si cambiamos un dato.

Quien no sepa defender su práctica no la aprueba, tenga el programa que tenga: la calificación será de 1.

Criterios de corrección

Criterio	Peso
El menú funciona y el programa no se rompe ante datos raros	20 %
Venta de entradas: control de aforo, precios, IVA y descuento anticipado	25 %
Factura: formato, código único, imagen ASCII y cálculo del cambio	20 %
Consulta de estado y menú de administrador	10 %
Manual de usuario y vídeo	5 %
Defensa oral	20 %

Por dónde empezar

1. El menú vacío, con el do-while del ejercicio 31. Que funcione entrar y salir.
2. Las constantes: precios, aforos, descuentos y fechas de los tres eventos.
3. La venta sin descuento ni factura: pedir evento, tipo y cantidad, y descontar del aforo.
4. La factura bonita.
5. El descuento por antelación y la simulación de fecha.
6. El cambio en el menor número de monedas.
7. El menú de administrador.

Cada paso es un programa que funciona. Eso es desarrollo incremental, y es lo que evita llegar a la fecha de entrega con 400 líneas que no arrancan.