Proyecto Bodega

Un solo proyecto que crece durante todo el semestre: Bodega, el sistema de inventario y ventas de una tienda pequeña de barrio. Empieza como una clase Product y termina como una aplicación de línea de comandos que registra ventas, aplica descuentos, emite reportes y guarda su estado en archivos.

La idea es que cada tema del curso tenga un lugar donde usarse en un programa que importa: el encapsulamiento protege el stock de valores imposibles, el polimorfismo permite agregar tipos de producto sin tocar el código que vende, las excepciones ordenan los errores de una venta, y los principios de diseño se notan cuando hay que cambiar un programa que ya existe. Cada entrega se construye sobre la anterior y debe seguir pasando las pruebas de todas las entregas previas.

Las fechas oficiales están en el calendario del SYLLABUS. Cada entrega tiene su enunciado detallado, con sus pruebas públicas, en su carpeta:

#	Enunciado	Carpeta
P0	Calentamiento	`p0-calentamiento/`
P1	Inventario	`p1-inventario/`
P2	Catálogo	`p2-catalogo/`
P3	Ventas	`p3-ventas/`
P4	Reportes	`p4-reportes/`
P5	Aplicación	`p5-aplicacion/`

#	Entrega	Lo que agrega	Temas del curso	Publicado	Entrega
P0	Calentamiento	Programas cortos en Java; `Product` (el producto) como primera clase	Semanas 1–2	Sem. 1	Sem. 3
P1	Inventario	Clases encapsuladas con invariantes, `ArrayList`, pruebas JUnit	Semanas 3–5	Sem. 3	Sem. 6
P2	Catálogo	Jerarquía de productos, polimorfismo, interfaces (precios y descuentos)	Semanas 5–8	Sem. 6	Sem. 9
P3	Ventas	Excepciones, genéricos y colecciones (`Map`, `Set`)	Semanas 9–11	Sem. 9	Sem. 12
P4	Reportes	Lambdas y streams; refactoring con principios SOLID	Semanas 12–14	Sem. 12	Sem. 15
P5	Aplicación	Patrones de diseño, persistencia en archivos y una interfaz de línea de comandos	Semanas 14–16	Sem. 15	Sem. 16

Qué agrega cada entrega

P0 · Calentamiento. Programas cortos en archivos compactos (void main()) para retomar Java desde lo que ya saben programar: leer datos, calcular totales, recorrer arreglos. Al final, la primera clase del proyecto: Product, con nombre, precio y stock.

P1 · Inventario. Product deja de exponer sus campos: el stock nunca es negativo y el precio nunca es cero, y la clase lo garantiza. Aparece Inventory, el inventario, que guarda productos en un ArrayList, los busca, repone stock y descuenta unidades. Desde aquí, cada clase llega con sus pruebas JUnit escritas por ustedes.

P2 · Catálogo. No todos los productos son iguales: unos se venden por unidad, otros por peso, otros vencen. Una jerarquía de productos con override de métodos, una clase abstracta donde tenga sentido y una interfaz para las políticas de precio y descuento, de modo que agregar una promoción nueva no obligue a modificar el código que ya funciona.

P3 · Ventas. Registrar ventas con varias líneas, validar stock y montos, y reaccionar a los errores con excepciones propias en lugar de valores especiales. El inventario pasa a un Map indexado por código; las categorías y clientes frecuentes usan Set. Al menos una clase genérica propia.

P4 · Reportes. Productos más vendidos, ventas por día y por categoría, stock bajo: consultas escritas con lambdas y streams. Con las pruebas como red de seguridad, se refactoriza lo construido hasta aquí aplicando los principios SOLID, y el README explica qué cambió y por qué.

P5 · Aplicación. Bodega se vuelve un programa completo: una interfaz de línea de comandos para vender, consultar y reponer; persistencia del estado en archivos CSV (la serialización queda como opción); y patrones de diseño donde resuelvan un problema concreto del proyecto (por ejemplo, Strategy para los precios u Observer para avisar del stock bajo). Se presenta en el laboratorio de la semana 16.

Reglas de entrega

P0 es individual. P1–P5 se pueden hacer en parejas; la pareja se mantiene durante el semestre.
Si se entrega con git, cada entrega es el mismo repositorio con un tag: p0, p1, …, p5, y se revisa el commit de ese tag.
El código debe compilar con javac -Xlint:all sin warnings y pasar make test dentro del contenedor del curso (env/run.sh).
Identificadores en inglés y comentarios en español, según la guía de estilo.
Incluir un README.md corto: integrantes, qué funciona, qué no, cómo se ejecuta y las decisiones de diseño principales (con un diagrama de clases desde P2). Si usaron alguna herramienta permitida que influyó en la entrega, el README lo dice (uso de herramientas).
Cualquier integrante debe poder explicar cualquier parte del código entregado; puede haber una defensa oral breve durante el laboratorio.

Cómo se corren las pruebas

Cada enunciado trae el Makefile (el mismo en todas las entregas), pruebas públicas JUnit (P0ProductPublicTest.java, P1InventoryPublicTest.java, …) y, en P0 y P5, casos de entrada y salida en la carpeta tests/. Todo se copia a la carpeta del proyecto sin modificarlo, y se queda ahí en las entregas siguientes. Las pruebas que escriben ustedes van en archivos aparte, también con nombre *Test.java.

/ruta/al/curso/env/run.sh      # desde la carpeta del proyecto
make test                      # compila a build/ y corre todas las pruebas

La revisión corre make test en el contenedor con las pruebas públicas de todas las entregas hasta la actual, más pruebas privadas que verifican los mismos requisitos con otros datos. Un proyecto que no compila no pasa ninguna prueba. Ver la guía del laboratorio.