183 lines
18 KiB
Markdown
183 lines
18 KiB
Markdown
# 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.<br>• **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.<br>• **Trazabilidad y Auditoría:** Registro inmutable (*audit logs*) de quién asignó, modificó o canceló cada reserva.<br>• **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.<br>• **Matriz de Conflictos en Tiempo Real:** Validación preventiva instantánea que impide el solapamiento de docentes o espacios.<br>• **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.<br>• **Sincronización Híbrida:** Generación e integración automática de enlaces de Google Meet para clases virtuales o de contingencia climática.<br>• **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.<br>• **Calendario Académico y Fechas Clave:** Visualización clara de parciales, entregas de trabajos prácticos y recesos.<br>• **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.<br>• **Microservicio 2 (Core Transaccional & Motor Heurístico):** Python Flask.<br>• 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.<br>• **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.<br>• 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.<br>• **Doble modo de visualización:** Modo Claro (diseñado para alto contraste diurno y legibilidad) y Modo Oscuro (*OLED Glassmorphism*).<br>• 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.<br>• **Tokens JWT** protegidos en cookies `HttpOnly`, `SameSite=Lax` y `Secure`.<br>• Middleware de verificación criptográfica de firmas.<br>• Rate limiting preventivo anti-fuerza bruta en login.<br>• 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.<br>• Aislamiento en **Contenedor Linux LXC**.<br>• Servidor web de borde **Nginx** como Proxy Inverso con SSL/TLS Let's Encrypt.<br>• 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 <service> -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)**.
|