Fat & Happy POS

Contexto

El trabajo se enmarca en el ciclo DAM con un enfoque de hostelería y cadenas: varios puntos de venta, picos de demanda y necesidad de roles claros (caja, gestión, administración) sin perder agilidad en la toma de pedidos. El alcance es académico: no hay explotación comercial ni datos de clientes finales; sí hay intención de trazabilidad y coherencia de datos entre lo que ocurre en pantalla y lo que queda registrado.

Problema

Hacía falta centralizar ventas, stock y operación sin convertir el sistema en un bloque rígido imposible de mantener en el tiempo del TFG. El dominio incluye personal y permisos, auditoría de acciones, pedidos con menús combinados, descuentos y promociones, modalidades para llevar / mesa, y un circuito de caja coherente con sesiones, cobros y devoluciones. La solución debía mantener cliente y servidor coordinados por red y una persistencia única que no duplicara verdad de negocio en cada puesto.

Qué resolvía el sistema o proyecto

El POS cubre, entre otras cosas, las capacidades descritas en el proyecto en GitHub:

• Catálogo y pedido: selección de productos con imágenes, variantes, filtros y precios visibles; construcción de líneas de ticket en tiempo real.
• Personalización: ingredientes incluidos o excluidos y extras con suplemento y cantidad, alineados con el modelo de datos.
• Menús y promociones: agrupación en menús, descuentos y promociones según reglas del dominio acotado en el entregable.
• Empleados y permisos: identificación de usuario en cabecera, menú de administración acotado y registro de movimientos relevantes para auditoría.
• Caja: sesiones de trabajo, cobros y devoluciones, con salida de ticket o resumen exportable según el diseño del proyecto.
• Stock: control por restaurante y reflejo de ventas en tablas de seguimiento (p. ej. productos vendidos).
• Centralización: registro de ventas y operaciones en un único esquema MariaDB para soportar análisis y trazabilidad entre locales del planteamiento académico.

Mi rol

Fui responsable del diseño e implementación del proyecto en el marco del DAM: definición de la estructura modular del código, desarrollo del cliente de escritorio Swing, del servidor con aceptación de conexiones y reparto de trabajo en hilos, del modelo relacional y de su uso mediante Hibernate/DAO, así como de los flujos de permisos, auditoría y del planteamiento de despliegue del lado servidor (incluida la idea de Raspberry Pi como alojamiento de base de datos y servicios auxiliares en el documento de trabajo). No atribuyo impacto en producción ni implantación real: el valor aquí es demostración técnica y criterio de ingeniería.

Stack

Java 17, interfaz Swing, sockets en Java puro para el canal cliente-servidor, Hibernate 6.x, MariaDB 10.x, construcción con Maven, registro con log4j según el README en GitHub, FTP/vsftpd para imágenes, Raspberry Pi como referencia de despliegue ligero, UFW y Fail2Ban en el relato de servidor.

Decisiones técnicas

Organización del código

El código se organiza de forma modular por paquetes, en la línea del README: productos, empleados, cajas, pedido y auxiliares (más utilidades compartidas). Esa separación reduce el acoplamiento entre la interfaz Swing, la serialización de mensajes hacia el servidor y la capa de acceso a datos, y facilita razonar sobre permisos y flujos por dominio.

Cliente y servidor (sockets)

Patrón cliente–servidor explícito. El cliente Java concentra la interfaz Swing (paneles de productos, pedido, caja, descuentos), hilos de actualización para datos que cambian en red y temporizadores de uso acotado. El servidor Java expone un ServerSocket con puerto configurable; cada conexión se gestiona con un hilo dedicado que recibe y procesa objetos y envía respuestas. Hay ping/pong, purga de clientes inactivos y lógica de reconexión ante cortes, descritos en el README en GitHub.

La persistencia se apoya en Hibernate 6.x y patrones DAO, con separación razonable entre presentación, mensajes de red y acceso a datos. Los recursos gráficos de productos se cargan desde FTP (vsftpd) en el servidor para no incrustar todo el binario de imágenes en el cliente.

Modelo relacional

Diseño relacional en MariaDB 10.x, visión multi-restaurante: varios establecimientos comparten esquema para comparativas y trazabilidad centralizada. Entre las tablas aparecen, sin ser exhaustivo, restaurantes, productos y especializaciones (hamburguesas, postres, etc.), ingredientes y extras, stock_restaurante, productos_vendidos, empleados, movimientos_empleados, cajas, pedidos, operaciones y secuencias como numero_pedido.

El README documenta disparadores que automatizan coherencia (p. ej. alta de producto propagando stock por restaurante; cambios de stock en actualizaciones_stock). El código de producto CCTTNNVV (ocho dígitos) codifica categoría, tipo, nombre base y variante para trazabilidad sin depender solo del ID interno.

El diagrama detallado está en GitHub; enlaza con el caso Datos y persistencia, donde detallo mi línea con SQL y motores relacionales.

Seguridad y despliegue (criterio del TFG)

Planteamiento con Raspberry Pi y endurecimiento básico descrito en el README a nivel de criterio, no como guía reproducible: SSH sin supuestos por defecto, UFW, Fail2Ban, MariaDB con instalación segura y usuarios con privilegio mínimo, vsftpd con opciones acotadas (modo pasivo, chroot, según memoria técnica).

En esta ficha no publico puertos concretos, reglas copiables ni credenciales: priorizo mostrar conciencia de superficie de ataque y la diferencia entre entrega académica y despliegue con políticas corporativas.

• Sockets frente a capa HTTP propia: patrón pedagógico claro y control fino del protocolo de objetos en el alcance del TFG.
• Servidor multihilo: aislar lectura/escritura por cliente y mantener tareas periódicas (ping/pong, purga) sin bloquear el accept principal.
• Hibernate y validación de esquema: alinear código y tablas (p. ej. hbm2ddl en modo validación en la configuración de ejemplo del README) para detectar desajustes antes de runtime.
• Separación FTP para binarios: desacoplar peso de imágenes del despliegue del cliente y acercarse a un reparto típico cliente/servidor.
• Auditoría y permisos: ligar acciones sensibles a empleado y sesión, coherente con el modelo de cajas y movimientos.

Restricciones o NDA

Es un proyecto académico con datos ficticios o de prueba. No publico credenciales, volcados de base de datos, topología de red real ni capturas con información identificable de terceros. Las pantallas del portfolio son material del propio entregable o de marca genérica del TFG.

Resultado o aprendizaje

El entregable demuestra que puedo coordinar interfaz de escritorio, comunicación en red y base de datos en un solo sistema acotado. Aprendí a fijar límites de módulo para que el POS no se convierta en un único archivo monolítico, y a valorar la trazabilidad (ventas, stock, empleado) como requisito de diseño, no como añadido tardío. En un proceso de selección, el código en GitHub sirve como muestra revisable de estilo, estructura de paquetes y documentación; enlaza también con Multilingual Support como ejemplo de internacionalización ligera en Java.