GSIGR05

Imported from irigoyen161817/GSIGR05 (AGENTS.md). Install upstream with npx skills add irigoyen161817/GSIGR05. Copyright stays with the author.

AGENTS.md — GSIGR05 · Práctica 01 (GSI, UPNA 2026/2027)

Instrucciones para agentes de código que trabajen en este repositorio. La fuente de verdad es Práctica_1.pdf (guion oficial); practica1.md es una transcripción de apoyo. Si hay conflicto, manda el PDF y, por encima de él, el anexo de dudas publicado en MiAulario.

1. Entorno

• Proyecto NetBeans Java SE (Ant). El proyecto real está en el subdirectorio GSIGR05/; la raíz del repo solo contiene Git, documentación y el PDF.
  • Fuentes: GSIGR05/src · Tests JUnit (opcional): GSIGR05/test · Metadatos: GSIGR05/nbproject.
  • Salidas generadas (no editar ni commitear): GSIGR05/build, GSIGR05/dist, GSIGR05/dist/javadoc, GSIGR05/nbproject/private/.
• Java: javac.source/javac.target = 23 (GSIGR05/nbproject/project.properties). No usar APIs posteriores.
• Codificación UTF-8 en todos los fuentes (nombres y Javadoc en español: Dueño, Dirección, Contestación...).
• No modificar GSIGR05/nbproject/build-impl.xml (generado por NetBeans). Los cambios de build van en GSIGR05/build.xml o project.properties.
• main.class actual: gsigr05.GSIGR05 (esqueleto generado). Para ejecutar el Tester, cambiarlo a GSILabs.BTesting.P01.Tester o ejecutarlo con run-single.

Comandos (desde la raíz del repo):

ant -f GSIGR05/build.xml clean jar        # compilar y empaquetar
ant -f GSIGR05/build.xml run              # ejecutar main.class
ant -f GSIGR05/build.xml javadoc          # generar Javadoc en GSIGR05/dist/javadoc
ant -f GSIGR05/build.xml test             # tests JUnit, si existen

Verificar siempre que jar y javadoc terminan sin errores (y sin warnings de Javadoc evitables) antes de dar un cambio por terminado.

2. Estructura obligatoria (criterio e1.1)

• Respetar exactamente estos nombres (con mayúsculas). No poner código de la práctica en el paquete gsigr05.
• Nombre del proyecto: GSIGR05 (grupo 05). No renombrar.

3. Requisitos de negocio (C01–C09)

Almacenamiento no persistente (en memoria). Operaciones: altas, bajas, modificaciones, consultas y comprobación de consistencia.

• C01 Local: nombre, dirección (Localidad, Provincia, Calle, Número) y descripción opcional ≤ 300 caracteres. No puede haber dos locales en la misma dirección.
• C02 Tipos de local: Restaurante (precio estimado de menú, capacidad máxima total y por mesa), Bar (especialidades como tags), Pub (hora de apertura y de cierre).
• C03 Usuario: nick único y de ≥ 3 caracteres, contraseña, fecha de nacimiento. Edad mínima 14 años. Perfil obligatorio: Propietario o Cliente.
• C04 Cliente: consulta locales y escribe reviews.
• C05 Review: de un Cliente sobre un Local; valoración 0–5 estrellas, comentario ≤ 500 caracteres, fecha de visita. Un cliente puede hacer varias reviews del mismo local, pero no dos de la misma visita (mismo cliente + local + fecha de visita).
• C06 Propietario/Dueño: un Local tiene entre 1 y 3 propietarios; un propietario puede tener 0..N locales.
• C07 Contestación: solo la puede hacer un propietario del local de la review; máximo una contestación por review; comentario ≤ 500 caracteres.
• C08: el sistema registra automáticamente la fecha de creación de Reviews y Contestaciones.
• C09 Reservable: Restaurante y Bar implementan Reservable (los Pub no). Una Reserva es de un Cliente, con fecha y hora y un porcentaje de descuento opcional. No se puede reservar en locales inexistentes.

Clases sugeridas por la Figura 1 (diagrama raster del PDF; no se puede leer como texto — confirmar con el PDF ante dudas de nombres): Usuario, Cliente, Dueño/Propietario, Local, Direccion, Bar, Pub, Restaurante, Review, Contestacion, Reserva, interfaz Reservable. Relaciones: Cliente y Dueño heredan de Usuario; Bar, Pub, Restaurante heredan de Local; Bar y Restaurante implementan Reservable; Local compone una Direccion. Se permiten clases/interfaces auxiliares adicionales (p. ej. excepciones, enums de perfil).

Ambigüedades en los requisitos: consultar el anexo de preguntas de MiAulario. Si no está disponible, elegir la interpretación más restrictiva/coherente, documentarla en el Javadoc y avisar al usuario.

4. Ejercicios

1. Proyecto GSIGR05 con paquete GSILabs.BModel — hecho.
2. Modelo (GSILabs.BModel):
   • Identificadores únicos generados de forma transparente para entidades sin clave natural (Review, Contestación, Reserva...), p. ej. con java.util.concurrent.atomic.AtomicInteger.
   • Validaciones mediante excepciones propias documentadas (@throws), no System.out ni valores mágicos.
   • Sobrescribir toString(), equals() y hashCode() en todas las clases instanciables, de forma coherente con la identidad de cada entidad (dirección para Local, nick para Usuario, id generado para el resto).
   • Encapsulación: atributos private, colecciones devueltas como copias o vistas inmodificables.
3. Sistema (GSILabs.BSystem):
   • LeisureOffice y LookupService se descargan de MiAulario; deben copiarse sin alterar sus firmas. No inventar sus métodos: si no están en el repo, pedir al usuario que los añada antes de implementar BusinessSystem.
   • BusinessSystem implements LeisureOffice, LookupService y gestiona el almacenamiento en memoria (colecciones de java.util) y las reglas que dependen del conjunto (unicidad de dirección y nick, 1–3 dueños, review duplicada, contestación única, existencia del local/review).
   • Coherencia referencial al borrar: mecanismo configurable de bloqueo (impedir borrar lo referenciado) o borrado en cascada (p. ej. borrar un Local elimina sus reviews, contestaciones y reservas). Hacerlo explícito (flag/política) y documentado.
4. Tester (GSILabs.BTesting.P01.Tester, con main): crea un BusinessSystem, lo puebla con locales, usuarios, reviews, reservas, etc., y comprueba mostrando por consola:

• Cada suceso debe estar comentado en el código explicando cómo se comprueba.
• Salida clara por línea: esperado vs. obtenido y OK/FALLO. El Tester no reimplementa reglas de negocio; solo ejercita el sistema.

5. Criterios de corrección (12 puntos)

Cada criterio: fallido (0 %), incompleto (25/50/75 %) o completo (100 %).

Antes de cerrar cualquier tarea, revisar el cambio contra esta tabla.

6. Convenciones de código

• Javadoc en español en todas las clases, interfaces, constructores y métodos públicos/protegidos: descripción, restricciones de dominio, @param, @return, @throws. Mantener package-info.java en cada paquete.
• Separación estricta de capas: el modelo no conoce BusinessSystem; el Tester solo usa la API del sistema.
• Invariantes intrínsecas (longitudes, rangos, edad) en el modelo; invariantes de conjunto (unicidad, cardinalidades, existencia) en BusinessSystem.
• Solo biblioteca estándar de Java; sin dependencias externas.
• Fechas con java.time (LocalDate, LocalTime, LocalDateTime).

7. Entrega

• 30 de septiembre (entrega y discusión). Sesiones de laboratorio: 9, 16 y 23 de septiembre.
• Proyecto NetBeans completo comprimido en .zip o .7z, subido a la Tarea de MiAulario (lo hace el alumno, no el agente).
• Penalización: −3 puntos por cada día o fracción de retraso.

8. Git

• Commits pequeños, en español, con el formato existente: [#N] - Descripción.
• No commitear build/, dist/, nbproject/private/ ni el PDF salvo que el usuario lo pida.