Skip to content

Instantly share code, notes, and snippets.

@IoTeacher
Last active November 11, 2025 01:16
Show Gist options
  • Select an option

  • Save IoTeacher/19d4ef5030e03366a3ccf818008433bb to your computer and use it in GitHub Desktop.

Select an option

Save IoTeacher/19d4ef5030e03366a3ccf818008433bb to your computer and use it in GitHub Desktop.
image

✈️ Centro de Control de Mando del Aeropuerto Internacional - Práctica de Ingeniería de Software y Refactorización GoF

📘 Contexto del Mundo Real

El Aeropuerto Internacional "Alas del Pacífico" ha iniciado la modernización de su Centro de Control de Mando (CCM), responsable de coordinar todas las operaciones críticas:

  • Gestión de vuelos entrantes y salientes.
  • Asignación de pistas de aterrizaje y despegue.
  • Coordinación entre torres de control, hangares, tripulación y puertas de embarque.
  • Supervisión de condiciones climáticas, tráfico aéreo y mantenimiento de aeronaves.
  • Priorización de vuelos de emergencia, carga pesada o diplomáticos.
  • Comunicación en tiempo real entre múltiples subsistemas y sensores distribuidos.

Actualmente, la aplicación que ejecuta esta lógica está acoplada, difícil de escalar y propensa a errores humanos y técnicos. El código fue escrito bajo presión por múltiples desarrolladores sin una arquitectura clara, lo que resultó en una gran bola de barro (big ball of mud).

🚨 Problemas que presenta el sistema actual

A continuación se enumeran problemas comunes que los estudiantes deben identificar y refactorizar mediante patrones GoF:

  1. Clases monolíticas y acopladas que manejan múltiples responsabilidades (violación del principio SRP).
  2. Duplicación de lógica al manejar diferentes tipos de vuelos (comercial, carga, privado, emergencia).
  3. Condicionales anidados y uso excesivo de switch/case para decisiones operativas (asignación de pistas, tipo de avión, tipo de clima).
  4. Comunicación directa entre clases, sin intermediarios, provocando fuerte acoplamiento.
  5. Falta de extensibilidad al integrar nuevos sensores o protocolos de comunicación.
  6. Código procedural sin encapsular comportamiento variable (e.g. diferentes protocolos de comunicación con aeronaves).
  7. Manejo caótico del estado del aeropuerto (pistas ocupadas, vuelos en cola, alertas climáticas).
  8. Validación de datos dispersa y sin consistencia (ej. duplicación de lógica para validar si una pista está disponible).
  9. Reutilización nula: no se aprovechan las abstracciones para tratar vuelos similares de forma polimórfica.
  10. Mal manejo de logs y eventos: todo se imprime con Console.WriteLine, sin estructura o prioridad.

🎯 Objetivo

Tu equipo ha sido contratado como consultores de arquitectura de software. Se les entrega el sistema tal cual está (con spaghetti code) y deben:

  • Identificar los 10 problemas más críticos.
  • Aplicar al menos 10 patrones de diseño del catálogo GoF, justificando cada elección.
  • Mejorar la mantenibilidad, flexibilidad y escalabilidad del sistema.
  • Documentar las decisiones tomadas y preparar un entorno funcional en .NET 8.

💡 Sugerencia de Patrones a Aplicar

Algunos patrones útiles para esta práctica pueden ser:

  • Strategy: Para encapsular comportamientos distintos como protocolos de aterrizaje o despegue.
  • Observer: Para recibir actualizaciones de sensores o cambios en clima.
  • Command: Para ejecutar operaciones (e.g. asignar pista, notificar torre) de forma desacoplada.
  • Factory Method / Abstract Factory: Para crear diferentes tipos de vuelos o aeronaves sin acoplar la lógica a clases concretas.
  • State: Para gestionar el estado dinámico de una pista (libre, ocupada, mantenimiento).
  • Mediator: Para coordinar la comunicación entre módulos como torre, pista, y control meteorológico.
  • Singleton: Para un controlador central del aeropuerto (¡pero cuidado con los problemas de pruebas!).
  • Decorator: Para añadir funcionalidades dinámicas a vuelos, como prioridad diplomática o carga especial.
  • Template Method: Para definir la secuencia de pasos para un despegue o aterrizaje, dejando variaciones a subclases.
  • Chain of Responsibility: Para procesar eventos o validaciones en cadena.

📁 Entregables esperados

  1. Informe en PDF que justifique los problemas detectados y patrones aplicados.
  2. Código fuente en C# con implementación refactorizada, comentarios en español LATAM.
  3. Playbook de Ansible que instale el entorno .NET 8, compile y corra la aplicación.
  4. Grabación en LOOM de la instalación, función y ejecución del sistema refactorizado.

¡Excelente decisión, profe! Aquí tienes dos cosas:


🎨 Imagen de ambientación (DALL·E Prompt)

Este prompt está diseñado para generar una imagen visual inmersiva que puedes usar como portada para la práctica en PDF, presentación o cartel para el aula virtual:


🧠 Prompt para DALL·E:

Escena futurista en una torre de control de aeropuerto internacional durante la noche, con grandes pantallas digitales mostrando vuelos, clima y radares. Ingenieros de software, controladores aéreos y oficiales de seguridad observan información crítica en tiempo real. Fondo con pistas de aterrizaje iluminadas, aviones despegando y nubes amenazantes. Estilo realista, tonos azulados, tecnología avanzada pero ambiente de tensión operativa.

Texto sugerido en pantalla: “Centro de Control de Mando - Aeropuerto Alas del Pacífico”


Sugerencias para usar la imagen:

  • Como portada del PDF de la práctica.
  • Como slide inicial en tu presentación de clase.
  • Para motivar la discusión de los sistemas críticos y la importancia del diseño desacoplado.

📊 Rúbrica Universitaria de Evaluación (Valor total: 100 puntos)

Criterio Peso Nivel Excelente (100%) Nivel Aceptable (70%) Nivel Insuficiente (0–50%)
🔍 Identificación de problemas de diseño 20 Identifica y explica claramente ≥10 problemas reales del código. Identifica al menos 7 problemas relevantes. Detecta < 5 problemas o no los explica.
🧩 Aplicación de patrones GoF (mínimo 10) 25 Aplica al menos 10 patrones apropiados, bien justificados. Aplica 7–9 patrones con justificación parcial. Aplica < 6 o los usa incorrectamente.
🛠️ Refactorización del código (en C# / .NET 8) 20 Código limpio, modular, coherente y funcional en .NET 8. Refactorización parcial, con pequeños errores. Código aún muy acoplado o no compila.
📝 Informe técnico en PDF 15 Justificación clara de decisiones, con diagrama de clases y explicaciones. Documento correcto, pero superficial o sin diagramas. Incompleto, sin argumentos o mal presentado.
⚙️ Playbook Ansible funcional y personalizado 10 Despliegue automático exitoso y bien documentado. Playbook básico, requiere ajustes manuales. No funcional o sin lógica relevante.
🎥 Grabación LOOM y demostración de ejecución 5 Demuestra instalación y ejecución clara del sistema. Grabación incompleta pero presenta algo funcional. No hay grabación o es irrelevante.
🧠 Creatividad y profundidad en el rediseño 5 Añade mejoras propias, patrones adicionales o extensión lógica. Sigue lo pedido sin innovación adicional. No hay aportes propios.

🎯 Total: 100 puntos

  • 90–100 pts: Nivel Profesional / Sobresaliente
  • 80–89 pts: Competente / Bien logrado
  • 70–79 pts: Aceptable / Puede mejorar
  • < 70 pts: Reprobado / No observo la rúbrica

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment