# TP1 - Taller de Programación - Cátedra Camejo ### Fecha de entrega: **Lunes 4 - 00:00 hs** --- ## Introducción Cóndor del Sur es una aerolínea regional que opera vuelos de cabotaje dentro de Argentina. En días tranquilos, el sistema de reservas funciona sin demasiados problemas. Pero cuando un vuelo empieza a llenarse —por ejemplo, un viernes a la tarde rumbo a Bariloche o un fin de semana largo con destino a Iguazú— empiezan a aparecer situaciones más interesantes: varios pasajeros quieren los mismos asientos, algunas reservas quedan pendientes de confirmación, otras se cancelan, y además hay tareas auxiliares que el sistema tiene que disparar sin frenar toda la operatoria. La empresa quiere rehacer una versión simplificada de ese sistema para entender mejor cómo modelar concurrencia, estado y coordinación entre procesos. El problema es bastante concreto: si el sistema está mal diseñado, aparecen errores clásicos como estos: * dos pasajeros creen que reservaron el mismo asiento * una reserva queda a medio confirmar * una cancelación libera mal un asiento * una tarea auxiliar tarda demasiado y bloquea todo La idea de este TP es construir una versión simplificada pero razonable de ese sistema usando procesos manuales en Elixir, sin usar todavía OTP. No buscamos hacer “un sistema real de aerolínea”. El foco está en construir un sistema concurrente chico pero bien diseñado, donde se vea con claridad: * modelado de dominio * procesos con estado * procesos para tareas puntuales * comunicación por mensajes * consistencia frente a concurrencia --- ## Objetivo Diseñar e implementar un sistema por CLI que simule la reserva de asientos para un vuelo y que permita mostrar concurrencia real sobre recursos limitados. El proyecto debe crearse con mix, pero sin supervisor: ```bash mix new condor_del_sur --no-sup ``` No deben usar GenServer, Supervisor, Task, Agent, Registry ni behaviours de OTP. --- ## Qué tiene que hacer el sistema Como mínimo, el sistema debe permitir: * crear o cargar un vuelo con asientos * registrar pasajeros * consultar asientos disponibles * iniciar una reserva sobre un asiento específico * confirmar una reserva mediante un pago * cancelar una reserva a pedido del usuario, siempre que todavía no haya sido confirmada * mostrar un estado final claro del vuelo Además, debe haber un caso donde varios pasajeros compitan por el mismo asiento al mismo tiempo, y el sistema debe resolverlo correctamente. --- ## Estados y transiciones mínimas ### Estados de la reserva * `:pending` * `:confirmed` * `:cancelled` * `:expired` ### Estados del asiento * `:available` * `:reserved` * `:confirmed` ### Reglas mínimas esperadas * al iniciar una reserva: reserva `:pending`, asiento `:reserved` * al confirmar: reserva `:confirmed`, asiento `:confirmed` * al cancelar antes de confirmar: reserva `:cancelled`, asiento `:available` * al vencer sin confirmar: reserva `:expired`, asiento `:available` --- ## Qué queremos ver en el TP 1. Modelado de dominio con módulos y structs. 2. Entre 2 y 3 procesos centrales del sistema. 3. Procesos cliente compitiendo concurrentemente. 4. Procesos para tareas puntuales. 5. Uso explícito de: * `send / receive` * loop recursivo * `register` * `monitor` --- ## Reglas mínimas de negocio * un asiento no puede quedar asignado a dos pasajeros al mismo tiempo * solo uno gana si compiten por el mismo asiento * una reserva confirmada no puede cancelarse como pendiente * no debe haber estados inconsistentes --- ## Demo esperada La entrega debe incluir una demo reproducible por consola mostrando: * competencia concurrente por un asiento * resolución correcta del conflicto * confirmación por pago * cancelación n- expiración * tarea auxiliar ejecutándose * estado final claro del sistema --- ## Tests Algunos tests mínimos sugeridos: * reservar asiento disponible * reservar asiento ocupado * confirmar reserva pendiente * cancelar reserva pendiente * impedir cancelar reserva confirmada * liberar asiento por expiración --- ## Entrega Repositorio de GitHub con: * código fuente completo * `README.md` * instrucciones claras de ejecución * explicación de procesos principales * uso de `register` y `monitor` * demo reproducible * tests mínimos --- ## Qué no hace falta hacer * interfaz web o gráfica * pagos reales * múltiples aeropuertos * sistema comercial completo * persistencia productiva --- ## Criterios de evaluación * demo clara y funcional * modelo concurrente correcto * buen modelado de dominio * buen uso de procesos y mensajes * prolijidad del repositorio * documentación clara