1. Descripción del problema
Este proyecto resuelve la dificultad de comprender el funcionamiento interno de los algoritmos de ordenamiento mediante un visualizador interactivo. Desarrollado aplicando Programación Orientada a Objetos, el sistema permite a estudiantes y docentes visualizar gráficamente la ejecución, comparar múltiples algoritmos de manera simultánea en tiempo real y entender el comportamiento de las estructuras de datos paso a paso.
2. Análisis del problema
En este problema participan principalmente tres elementos: el usuario (estudiante o docente), el motor de ejecución lógica (que procesa los algoritmos de ordenamiento como Bubble Sort, Quick Sort, etc.) y la interfaz gráfica que traduce los cambios lógicos del arreglo numérico en representaciones visuales (barras o bloques).
Definición del sistema
El sistema es una aplicación de escritorio autónoma diseñada para la simulación educativa. Su límite de acción es la representación visual de la lógica del algoritmo; es decir, simula los pasos (iteraciones e intercambios) para fines didácticos, pero no evalúa el rendimiento real de la CPU ni del hardware de la máquina anfitriona.
Interacciones con el medio externo
El sistema interactúa con el usuario a través de periféricos de entrada (mouse y teclado) para recibir configuraciones: ingreso de números, selección de algoritmos y manipulación de controles de reproducción (velocidad, pasos). La salida es netamente gráfica, proyectando en pantalla animaciones y estadísticas básicas (número de pasos) en tiempo real.
3. Definición de requerimientos
A continuación se presentan los casos de uso principales del sistema, detallados según el estándar requerido.
Caso de Uso 1: Configurar simulación
1. Nombre: Configurar simulación
2. Propósito: Permitir al usuario ingresar los datos numéricos a ordenar y seleccionar los algoritmos deseados.
3. Actores: Usuario
4. Pre-condiciones: La aplicación ha iniciado y muestra la ventana principal (Sorting Algorithm Viewer).
5. Evento: El usuario desea preparar una nueva simulación de ordenamiento.
5. Curso normal de eventos:
| Actor | Sistema |
|---|---|
| 1) Ingresa un número en el campo de texto y presiona "Add". | 2) Valida el número, lo añade a la lista interna y actualiza la representación visual de las barras. |
| 3) Selecciona uno o más algoritmos mediante los botones (ej. Bubble Sort). | 4) Marca los algoritmos como seleccionados y muestra su descripción teórica en el panel derecho. |
6. Curso alternativo de eventos: Si el usuario ingresa un valor no numérico o deja el espacio en blanco al presionar "Add", el sistema ignora la entrada y señala que no se puede ingresar dicho valor.
7. Requerimientos no funcionales: La actualización de la interfaz gráfica al añadir o eliminar números debe ser casi instantánea (tiempo de respuesta menor a 0.5 segundos).
8. Autor: Grupo 5
Caso de Uso 2: Iniciar simulación simultánea
1. Nombre: Iniciar simulación simultánea
2. Propósito: Arrancar la animación paralela de los algoritmos de ordenamiento sobre el arreglo numérico previamente configurado.
3. Actores: Usuario
4. Pre-condiciones: Existen al menos dos números ingresados en el arreglo y al menos un algoritmo seleccionado.
5. Evento: El usuario presiona el botón de inicio de simulación.
5. Curso normal de eventos:
| Actor | Sistema |
|---|---|
| 1) Presiona el botón "Start". | 2) Captura el estado del arreglo y los algoritmos seleccionados. Oculta el menú principal. |
| 3) Abre la ventana "Simulación de Ordenamiento Múltiple" generando los paneles individuales (ej. 4 paneles) mostrando las barras y el contador en "Paso: 0". |
6. Curso alternativo de eventos: Si el usuario presiona "Start" pero no cumple las pre-condiciones (arreglo vacío o ningún algoritmo seleccionado), el botón no hace nada y se mantiene la vista actual.
7. Requerimientos no funcionales: La apertura de la nueva ventana debe redimensionar y distribuir los paneles geométricamente para evitar distorsiones visuales según el tamaño de la pantalla.
8. Autor: Grupo 5
Caso de Uso 3: Controlar reproducción
1. Nombre: Controlar reproducción
2. Propósito: Ajustar la velocidad de la animación, pausar, avanzar o retroceder iteraciones de los algoritmos en ejecución.
3. Actores: Usuario
4. Pre-condiciones: La ventana de simulación múltiple está abierta con los algoritmos cargados.
5. Evento: El usuario interactúa con los controles inferiores (slider de velocidad, botones de paso).
5. Curso normal de eventos:
| Actor | Sistema |
|---|---|
| 1) Ajusta la barra deslizable (slider) y presiona "Reproducir". | 2) Inicia la animación continua a la velocidad configurada moviendo las barras lógicamente. |
| 3) Presiona el botón "Adelante" o "Atrás". | 4) Pausa la animación continua, avanza o retrocede exactamente una iteración (paso) de los algoritmos y actualiza el texto "Paso: X". |
6. Curso alternativo de eventos: Si el arreglo llega a su estado completamente ordenado en todos los algoritmos seleccionados (paso final), los botones "Adelante" y "Reproducir" se bloquean temporalmente hasta que se decida retroceder.
7. Requerimientos no funcionales: Cuando el slider de velocidad se configure en su nivel máximo ("Rápido"), la actualización gráfica de las barras debe mantener una tasa de refresco fluida y constante para evitar parpadeos o saltos abruptos en la animación.
8. Autor: Grupo 5
4. Diseño
En esta sección utilizamos diagramas UML (Unified Modeling Language) como lenguaje común. Tal como se define en el curso, UML no es una metodología, sino una notación que nos permite comunicar las distintas vistas del sistema. Su uso nos ayudó a pasar de una idea conversada a un diseño visual que el equipo pudo discutir con claridad. A continuación, se presentan los diagramas que ayudan a representar la estructura del software y la interacción entre sus componentes.
5. Implementación
El código fuente incluye comentarios Javadoc en clases y métodos relevantes,
permitiendo generar documentación automáticamente. La documentación generada
con javadoc no se incluye en el entregable por ser redundante con el
código fuente comentado.
6. Pruebas
Prueba — Caso de Uso 1
Prueba — Caso de Uso 2
Prueba — Caso de Uso 3
Dificultades encontradas
- La dimensión de la interfaz debió ser reconfigurada para adaptarla al tamaño de una pantalla convencional, puesto que excedía los límites de la pantalla. Para solucionarlo se estableció un tamaño mínimo que encuadrase bien con monitores de baja resolución, cuidando no romper la distribución de elementos.
- Al ser un proyecto que maneja 4 sorts distintos que no comparten los mismos estados de proceso para cada frame, fue necesario generar múltiples constructores y ajustes polimórficos para adaptar el sistema y los argumentos de los métodos con tal de que no se generase un hipercruce de referencias y romper el encapsulamiento. Parte importante de la solución se encuentra en la clase tipo Enum, la cual permite sintetizar localmente y generalizar una buena parte de los tipos de información.
- Se presentó la dificultad de optimizar los recursos interactivos para generar una GUI familiar y responsiva. El desafío era lograr un enfoque didáctico que no requiriera una comprensión previa acabada del sistema por parte del usuario, alineándose con los estándares de la industria para productos de consumo masivo. Para lograr superarlo, se abstrajo la complejidad lógica de los algoritmos detrás de controles sencillos (botones de un solo clic, sliders de velocidad) y se utilizaron convenciones visuales universales (como códigos de colores para los estados de las barras), guiando la interacción del usuario de forma natural.
Bugs conocidos
- No se detectaron bugs conocidos al momento de la entrega.
7. Código fuente
El código fuente completo del proyecto (incluye README y Makefile)
está disponible en el siguiente archivo comprimido:
Repositorio del proyecto: Ver código en GitHub