Arquitectura de la solucion

El sistema esta separado en cuatro capas. Cada capa tiene una unica responsabilidad, lo que permite cambiar la base de datos o la interfaz sin tocar las reglas del negocio.

   main.py  (menu de consola)
        |
        +--> servicios/   validacion de entradas + API del dolar (requests)
        |
        +--> model/       clases del negocio, propiedades validadas y excepciones propias
        |
        +--> dao/         SQLite: CRUD, transacciones y consultas parametrizadas
                              |
                              +--> datos/clickandgo.db

El modelo de clases

Doce clases en total, una por archivo dentro de model/. Las relaciones siguen el diagrama UML de la Evaluacion Sumativa N1.

Clase	Rol dentro del negocio	Archivo
`Cliente`	Comprador; valida RUT o correo	model/cliente.py
`Producto` (abstracta)	Contrato del catalogo: stock, precio y entrega	model/producto.py
`ProductoFisico`	Despacho por transporte con calculo de flete	model/producto_fisico.py
`ProductoElectronica`	Importado en USD; hereda de ProductoFisico	model/producto_electronica.py
`ProductoDigital`	Entrega inmediata con enlace y licencia, flete $0	model/producto_digital.py
`ProductoServicio`	Agenda una visita tecnica futura	model/producto_servicio.py
`DetallePedido`	Linea de la transaccion; congela cantidad y precio	model/detalle_pedido.py
`Pedido`	Transaccion; aplica las dos reglas de negocio	model/pedido.py
`Trabajador` (abstracta)	Personal y autenticacion (PBKDF2)	model/trabajador.py
`EncargadoBodega`	Despacha, pero no modifica el catalogo	model/encargado_bodega.py
`Administrador`	Control total del catalogo y de los precios	model/administrador.py
Excepciones	Una por cada regla que impide una operacion	model/excepciones.py

Diagrama de clases UML

Diagrama de clases UML de ClickAndGo

Persistencia: cinco tablas

Tabla	Guarda	Relacion
`trabajadores`	Usuarios, rol, hash PBKDF2 y salt	Independiente
`clientes`	Nombre e identificador validado	1 a 0..* pedidos
`productos`	Los cuatro tipos de producto en una sola tabla	1 a * detalles
`pedidos`	Cabecera: cliente, fecha, estados y totales	1 a 1..* detalles
`detalle_pedido`	Lineas con cantidad y precio congelado	Clave foranea al pedido

Las tablas se crean solas al iniciar el programa (dao/conexion.py), por lo que el sistema nunca depende de un script manual de instalacion.

Decisiones de seguridad

Inyeccion SQL

Todas las consultas usan parametros enlazados (? o :nombre). El texto que escribe el usuario nunca se concatena dentro de una sentencia SQL.

Validacion de entradas

Cada dato se valida por tipo, formato y rango antes de usarse. Las propiedades del modelo validan en el setter y los lectores de consola reintentan sin caer.

Autenticacion

Las contrasenas se guardan con PBKDF2-HMAC-SHA256 (120.000 iteraciones) y salt aleatorio, y se comparan con hmac.compare_digest.

Permisos (RBAC)

El encargado de bodega no puede modificar precios ni catalogo. La accion se bloquea con SinPermisoError, no con un simple mensaje.

Tiempo maximo de espera

La consulta a mindicador.cl usa timeout=5. Si la API falla, se usa el ultimo valor conocido y se informa el problema.

Transacciones atomicas

El pedido y sus lineas se graban en una sola transaccion SQL: o se guardan ambos o no se guarda nada.