# REPORTE ACADÉMICO Y TÉCNICO DE PROYECTO FINAL
## Asignatura: Programación de Vanguardia — Ciclo Lectivo 2026 (2° Cuatrimestre)
### Carrera: Licenciatura en Tecnologías Informáticas — Universidad de la Ciudad de Buenos Aires (UniCABA)
**Docente Titular:** Ing. Alejandro Vázquez
**Proyecto:** Admin Edu-Space (Plataforma Inteligente de Asignación y Gestión de Espacios Áulicos)
**Entorno de Producción:** [https://eduspace.oemspot.com.ar](https://eduspace.oemspot.com.ar)
**Repositorio Oficial:** Rama `mvp`
---
## 1. Resumen Ejecutivo
El presente documento constituye el informe técnico de entrega y defensa del proyecto **Admin Edu-Space**, diseñado y desarrollado para dar cumplimiento integral y superador a las directrices de la asignatura **Programación de Vanguardia**.
El proyecto resuelve un problema neurálgico y recurrente en la gestión universitaria: la **ineficiencia en la asignación, planificación y monitoreo de espacios áulicos físicos y virtuales**, mitigando el solapamiento horario, la subutilización de capacidades físicas y la dispersión de información operativa entre Bedelía, el cuerpo docente y el alumnado.
La solución implementa una **arquitectura políglota distribuida basada en microservicios y el patrón BFF (*Backend-for-Frontend*)**, combinando la velocidad asíncrona de **Node.js** con la potencia de cómputo científico de **Python**, un motor de **Algoritmos Genéticos** para resolución de problemas NP-Hard de optimización combinatoria, y un despliegue cloud de nivel empresarial montado sobre **contenedores Linux (LXC)** protegidos mediante un **Proxy Inverso Nginx con terminación SSL**.
---
## 2. Problemática y Propuesta de Valor Agregado
### 2.1. Diagnóstico del Estado Previo
Históricamente, la gestión de aulas en instituciones académicas ha dependido de hojas de cálculo aisladas (Excel) y comunicaciones informales. Este esquema presenta serios inconvenientes:
* **Fricción operativa en Bedelía:** Carga manual propensa a duplicaciones y solapamientos de franjas horarias.
* **Incertidumbre en Docentes:** Falta de visibilidad previa sobre recursos multimedia asignados (proyectores, aire acondicionado, computadoras) y enlaces de contingencia virtual.
* **Pérdida de tiempo en Alumnos:** Desplazamientos innecesarios entre sedes o pisos por cambios de aula de último momento no notificados en tiempo real.
* **Costos ocultos para la Institución:** Aulas con capacidad para 60 alumnos ocupadas por comisiones de 15, mientras grupos numerosos son relegados a espacios reducidos.
### 2.2. Valor Agregado por Actor
| Actor | Beneficio y Valor Agregado en Edu-Space |
| :--- | :--- |
| **Institución (UniCABA)** | • **Maximización del ROI edilicio:** Métricas analíticas de tasa de ocupación por metro cuadrado.
• **Reducción de huella de carbono y consumo energético:** Identificación de aulas vacías para apagado inteligente de climatización e iluminación.
• **Trazabilidad y Auditoría:** Registro inmutable (*audit logs*) de quién asignó, modificó o canceló cada reserva.
• **Escalabilidad cloud:** Despliegue de bajo costo operativo sin ataduras a licencias privativas. |
| **Personal de Bedelía** | • **Automatización Genética:** Generación automática del cronograma cuatrimestral en segundos mediante algoritmos evolutivos.
• **Matriz de Conflictos en Tiempo Real:** Validación preventiva instantánea que impide el solapamiento de docentes o espacios.
• **Cartelera Digital:** Tablero operativo de estado áulico ("Ocupada", "Disponible", "Mantenimiento") con filtros dinámicos. |
| **Cuerpo Docente** | • **Portal Unificado de Cátedra:** Visualización clara de comisiones asignadas, días, horarios y especificaciones técnicas del aula.
• **Sincronización Híbrida:** Generación e integración automática de enlaces de Google Meet para clases virtuales o de contingencia climática.
• **Canal de Pedidos Especiales:** Solicitud de cambio de aula justificada con flujo de aprobación digital. |
| **Estudiantes** | • **Información Instantánea y Precisa:** Consulta en tiempo real desde cualquier dispositivo del aula asignada.
• **Calendario Académico y Fechas Clave:** Visualización clara de parciales, entregas de trabajos prácticos y recesos.
• **Transparencia Institucional:** Reducción del estrés operativo durante las semanas de exámenes y cursada regular. |
---
## 3. Matriz de Cumplimiento de Prerrequisitos de la Cátedra
A continuación se detalla cómo el proyecto cubre y excede cada uno de los ítems evaluativos fijados en la rúbrica oficial de la materia (100 Puntos):
| Dimensión Exigida en Rúbrica | Criterio de la Cátedra | Implementación en Admin Edu-Space | Estado de Cumplimiento |
| :--- | :--- | :--- | :---: |
| **Arquitectura de Microservicios** | Separación funcional de responsabilidades, desacoplamiento y comunicación RESTful. | • **Microservicio 1 (BFF / Web Gateway):** Node.js + Express.
• **Microservicio 2 (Core Transaccional & Motor Heurístico):** Python Flask.
• Comunicación asíncrona interna mediante HTTP/REST con serialización JSON y gestión de excepciones. | **Superado** |
| **Algoritmia Avanzada y Predictiva** | Implementación de algoritmos de optimización, analítica o modelos de decisión. | • **Optimizador Genético de Aulas:** Implementación evolutiva con selección por torneo, cruza en dos puntos, mutación adaptativa y función *fitness* multiobjetivo ponderando capacidad vs. inscriptos, equipamiento y dispersión horaria.
• **Motor Predictivo de Demanda:** Análisis de densidad de ocupación y proyecciones de congestión horaria. | **Superado** |
| **Persistencia de Datos** | Modelado relacional, integridad referencial y transaccionalidad ACID. | • **PostgreSQL / SQLAlchemy:** Esquema robusto de 14 tablas relacionales con restricciones de clave foránea, índices compuestos en fechas/horas, enumeraciones tipadas y migraciones versionadas.
• Trazabilidad histórica y soft-delete de recursos. | **Superado** |
| **Front-End Interactivo y UX** | Interfaz intuitiva, adaptativa, reactiva y orientada a la experiencia de usuario. | • UI moderna basada en Bootstrap 5 + Vanilla CSS con variables HSL personalizadas.
• **Doble modo de visualización:** Modo Claro (diseñado para alto contraste diurno y legibilidad) y Modo Oscuro (*OLED Glassmorphism*).
• Identidad corporativa UniCABA (magenta/rosa institucional, tipografías modernas, iconografía Bootstrap Icons). | **Superado** |
| **Seguridad y Control de Acceso** | Autenticación, autorización basada en roles (RBAC) y sanitización. | • **RBAC con 4 roles jerárquicos:** Administrador, Bedelía, Docente, Alumno.
• **Tokens JWT** protegidos en cookies `HttpOnly`, `SameSite=Lax` y `Secure`.
• Middleware de verificación criptográfica de firmas.
• Rate limiting preventivo anti-fuerza bruta en login.
• Escaneo automatizado de vulnerabilidades en CI/CD (`npm audit` + `pip-audit`). | **Superado** |
| **DevOps y Despliegue** | Puesta en marcha en infraestructura accesible y automatizada. | • Despliegue en producción real en VPS Cloud.
• Aislamiento en **Contenedor Linux LXC**.
• Servidor web de borde **Nginx** como Proxy Inverso con SSL/TLS Let's Encrypt.
• Orquestación de servicios bajo **systemd** con auto-restart y monitoreo con `journalctl`. | **Superado** |
---
## 4. Justificación de Ingeniería del Stack Tecnológico
Uno de los puntos clave del diseño fue la decisión de **desacoplar el sistema mediante un patrón Backend-for-Frontend (BFF) en Node.js y un núcleo de cálculo científico en Python**, en lugar del monolito inicial sugerido en Java (Spring Boot).
### 4.1. Análisis Comparativo: Java (Spring Boot) vs. Node.js + Python
```
ARQUITECTURA DE SERVICIOS IMPLEMENTADA:
[ Cliente / Navegador ]
│ HTTPS (Puerto 443 / SSL Let's Encrypt)
▼
┌─────────────────────────────────────────────────────────────┐
│ PROXY INVERSO NGINX │
│ - Terminación SSL / HTTP/2 │
│ - Compresión Gzip/Brotli │
│ - Cabeceras de Seguridad (HSTS, CSP, XSS-Protection) │
│ - Enrutamiento interno de puertos │
└──────────────┬──────────────────────────────┬───────────────┘
│ proxy_pass 127.0.0.1:3000 │ proxy_pass 127.0.0.1:5000
▼ ▼
┌──────────────────────────────┐ Internal ┌──────────────────────────────┐
│ MICROSERVICIO 1 (BFF) │────REST───▶│ MICROSERVICIO 2 (CORE) │
│ Node.js + Express.js │ HTTP │ Python Flask + SQLAlchemy │
│ - Renderizado SSR Nunjucks │◀───────────│ - Reglas de Negocio / CRUD │
│ - Gestión de Cookies JWT │ │ - Algoritmo Genético │
│ - Sesiones y RBAC de Vistas │ │ - Analítica y Métricas │
│ - Huella RAM: ~45 MB │ │ - Huella RAM: ~90 MB │
└──────────────────────────────┘ └──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ BASE DE DATOS ACID │
│ PostgreSQL / SQLAlchemy │
└──────────────────────────────┘
```
#### A. Eficiencia de Recursos y Huella de Memoria (RAM Footprint)
* **La problemática de Java en la Nube:** Un microservicio estándar desarrollado sobre Java con Spring Boot requiere típicamente entre **450 MB y 1 GB de memoria RAM** en reposo (*idle*), impulsado por la sobrecarga intrínseca de la máquina virtual (JVM), el escaneo de paquetes de reflexión de Spring, y el recolector de basura (*Garbage Collector*). En un entorno de producción académico o infraestructura de nube económica, destinar 1 GB por instancia resulta técnica y financieramente ineficiente.
* **La solución Node.js:** El motor V8 de Node.js presenta una huella de memoria inicial inferior a **45 MB**, permitiendo una densidad de empaquetamiento notablemente superior y un arranque en frío (*cold start*) medido en milisegundos en caso de reinicio de servicios.
#### B. Modelo de Concurrencia y Conectividad Asíncrona (I/O No Bloqueante)
* Node.js opera sobre un **Event Loop monohilo no bloqueante** con `libuv`. Para una capa BFF orientada a la web, que se encarga de recibir peticiones de clientes, renderizar vistas server-side (SSR) con Nunjucks, manipular cookies JWT y consumir APIs downstream, el modelo de I/O asíncrono es el estándar de la industria. Permite sostener miles de conexiones concurrentes con un uso mínimo de CPU.
#### C. Ventajas del Patrón Backend-for-Frontend (BFF)
* La capa Node.js aísla el Front-End de la complejidad de los contratos de datos del backend. Realiza agregación de respuestas, filtra atributos sensibles antes de inyectarlos en las plantillas HTML, administra el refresco de tokens y garantiza que las claves de sesión viajen exclusivamente en cookies seguras e inaccesibles por JavaScript malicioso en el navegador (inmunidad contra ataques XSS de robo de sesión).
#### D. Python como Motor de Inteligencia y Computación Numérica
* Delegar la lógica transaccional y el optimizador áulico a Python permitió aprovechar el ecosistema más avanzado en ciencia de datos y algoritmia combinatoria (bibliotecas como NumPy, Scipy, DEAP, y utilidades estadísticas). Intentar implementar algoritmos genéticos y modelado matemático complejo en la capa web habría sobrecargado el event-loop; Python desacoplado en Gunicorn con múltiples *workers* procesa los cálculos de optimización en segundo plano sin congelar la navegación del usuario.
---
## 5. Infraestructura de Producción: Contenedor LXC y Proxy Inverso Nginx
La solución se encuentra actualmente operativa y accesible públicamente en el dominio institucional `https://eduspace.oemspot.com.ar`.
### 5.1. Despliegue en Contenedores Linux (LXC)
En lugar de utilizar máquinas virtuales convencionales que emulan hardware completo a través de hipervisores pesados (KVM, VMware), se optó por **LXC (Linux Containers)**:
1. **Virtualización a Nivel de Sistema Operativo:** Comparte el kernel de Linux del host principal mediante primitivas nativas de aislamiento: *cgroups* (para limitación granular de CPU, memoria e I/O) y *namespaces* (para aislamiento estricto de procesos, red, montaje y usuarios).
2. **Rendimiento Nativo (Bare-Metal Speed):** Sin degradación de rendimiento por traducción de instrucciones de hardware; los procesos de Node.js y Gunicorn corren directamente sobre las llamadas al sistema (*syscalls*) del kernel anfitrión.
3. **Seguridad y Contención:** Si un servicio llegara a verse comprometido, el atacante queda confinado dentro del *chroot/namespace* del contenedor LXC, sin acceso a la infraestructura física subyacente.
### 5.2. Arquitectura de Frontera con Nginx
Nginx cumple la función de puerta de enlace segura y balanceador inverso:
* **Terminación Criptográfica TLS/SSL:** Los certificados son provistos y renovados automáticamente mediante Let's Encrypt (Certbot), garantizando cifrado robusto grado A en auditorías SSL Labs (TLS 1.2 / TLS 1.3, algoritmos modernos ECDHE-RSA-AES-GCM).
* **Compresión HTTP Dinámica:** Soporte de compresión Gzip en archivos CSS, JavaScript y respuestas JSON, reduciendo el consumo de ancho de banda y mejorando los tiempos de carga en dispositivos móviles con redes 4G/3G.
* **Defensas de Cabecera (Security Headers):**
- `X-Content-Type-Options: nosniff` (previene ataques de confusión MIME).
- `X-Frame-Options: SAMEORIGIN` (mitiga vulnerabilidades de Clickjacking).
- `Strict-Transport-Security: max-age=31536000; includeSubDomains` (forzamiento permanente de HTTPS).
- Políticas de referrer y control de caché estático para activos en `/static` y `/public`.
### 5.3. Gestión del Ciclo de Vida con Systemd
Los microservicios son gestionados por el demonio init del sistema (`systemd`):
* `admin-edu-space-frontend.service` (Node.js runtime supervisado).
* `admin-edu-space-backend.service` (Python WSGI Gunicorn supervisado).
* Políticas de reinicio automático (`Restart=always`, `RestartSec=5s`) ante caídas inesperadas de proceso o reinicios del servidor.
* Registro centralizado de logs mediante `journalctl -u -f` para diagnóstico en tiempo real.
---
## 6. Algoritmia Avanzada: Optimizador Genético de Espacios Áulicos
Para responder con excelencia a la consigna de *Algoritmos de Vanguardia*, el sistema incorpora un optimizador evolutivo basado en **Algoritmos Genéticos (GA)** para la resolución del problema de asignación de recursos áulicos, clasificado formalmente en teoría de la computación como un problema **NP-Hard (Nondeterministic Polynomial-time Hard)**.
```
FLUJO EVOLUTIVO DEL ALGORITMO GENÉTICO:
Población Inicial (Cromosomas de Asignaciones Aleatorias Factibles)
│
▼
Evaluación de Aptitud (Fitness)
┌─────────────────────────────────────┐
│ Penalizaciones por Restricciones: │
│ - Choque de aula / horario (Dura) │
│ - Choque de docente (Dura) │
│ - Capacidad insuficiente (Dura) │
│ - Desperdicio de capacidad (Blanda) │
│ - Falta de proyector/recursos (Blanda)│
└─────────────────────────────────────┘
│
▼
¿Criterio de Parada Cumplido? ────SI────▶ [ Mejor Solución: Cronograma Óptimo ]
(Generaciones = N o Fitness = 0)
│ NO
▼
Selección por Torneo / Ruleta
│
▼
Cruza en Dos Puntos (Crossover)
│
▼
Mutación Genética Adaptativa
│
└────────── Volver a Evaluación
```
### Formulación Matemática de la Función de Aptitud (*Fitness Function*):
$$\text{Fitness}(\mathcal{S}) = - \left( w_1 \cdot \sum \text{ConflictosHorarios} + w_2 \cdot \sum \text{DocenteSuperpuesto} + w_3 \cdot \sum \text{DeficitCapacidad} + w_4 \cdot \sum \text{DesperdicioAsientos} + w_5 \cdot \sum \text{CarenciaEquipamiento} \right)$$
Donde los pesos $w_1, w_2, w_3 \gg w_4, w_5$ aseguran que las **restricciones duras** (*hard constraints*, físicamente imposibles en la realidad) tengan un costo prohibitivo en la supervivencia del individuo, mientras que las **restricciones blandas** (*soft constraints*, comodidad ergonómica y eficiencia económica) dirigen la convergencia hacia el óptimo de Pareto.
---
## 7. Conclusión y Defensa del Trabajo
El proyecto **Admin Edu-Space** demuestra de manera tangible cómo la integración de patrones de diseño de vanguardia (BFF, Microservicios, Algoritmos Evolutivos, CI/CD, Containerization e Infraestructura Segura) no solo satisface con creces los 100 puntos de la rúbrica de la materia, sino que genera un **activo de software real, funcional, auditable y de alto impacto operativo para la Universidad de la Ciudad de Buenos Aires (UniCABA)**.