Juguemos al diagrama de flujo

El diagrama de flujo es una alternativa directa al pseudocódigo. Siempre digo a mis alumnos que se puede pasar del pseudocódigo al diagrama y al revés mecánicamente, todas las veces que se quiera, y sin perder nada en el intento. Esto es bastante cierto, la información importante para el intérprete no varía. Es decir, no se pierde ninguna instrucción ni ningún argumento en el pasaje. A algunos estudiantes les resulta más fácil empezar planteando sus algoritmos en un diagrama antes que en un código. Cuando el algoritmo involucra estructuras de control (condicionales y/o bucles), el diagrama de flujo permite visualizar mejor las posibles lineas de ejecución que un código escrito secuencialmente.

Actualmente PSeInt permite ir del pseudocódigo al diagrama, pero no al revés, no permite editar el diagrama. Además de que los diagramas que muestra no son de los más lindos, y el visor no es de los más rápidos, siempre me pareció un punto bajo, un hueco donde se podía aportar mucho. Pues bien, en la próxima versión incluiré nuevo y fantabuloso visor/editor de diagramas de flujo, parecido al que se muestra en el video:

Dado que el diagrama de flujo es un elemento esencialmente gráfico, quería poner énfasis en la interfaz, haciendo que la interacción sea lo más fluida posible, de forma que el alumno encuentre realmente fácil la edición del mismo, o incluso la generación del algoritmo completo desde el diagrama de flujo.  Para lograr esto, tuve que tener especial cuidado a la hora de organizar las estructuras de datos y a la hora de representarlas en la pantalla, para lo cual, como veremos más adelante, tomé prestadas algunas ideas de la programación de juegos (de mi experiencia con los menúes de MotoGT). Por otra parte, en la transición del código hacia el diagrama de flujo sí hay en principio una pérdida: los comentarios y las líneas en blanco del código, elementos que no cambian el funcionamiento del algoritmo, pero sí su legibilidad.

Lo primero que quería era que todo fuera animado. Es decir, si agrego un elemento, no quiero que aparezca y ya, de golpe, sino que quiero ver una transición rápida pero suave del diagrama viejo al nuevo. Para esto, utilicé una idea que ya había probado para los menúes de MotoGT. La idea es simple: el programa se maneja como una gran colección de entidades (imaginen que son sprites), al calcular como debe quedar el diagrama se le dice a cada entidad su posición y tamaño final, pero la entidad maneja en un conjunto de variables "repetidas" (la posición y el tamaño con el que se encuentra dibujada en cada momento), de modo que al actualizar la pantalla, se puede interpolar entre ambas (la posición final y la que se "veía" en el instante anterior), de forma que en unas pocas iteraciones la posición que se ve tienda a la final. Así, cualquier cambio brusco sobre los datos "finales" genera una transición suave en pantalla. El loop principal le pide en cada iteración a todas las entidades que se actualicen, dándoles así la oportunidad de moverse hacia el objetivo, marcar su selección, procesar sus eventos, etc (cada una es una pequeña máquina de estados independiente). Además, para la interacción, se usan las posiciones "repetidas" como si fueran las reales, para que la entrada de eventos del usuario sea coherente con lo que ve (que puede ser un estado intermedio rumbo al final).

Respecto al tema de comentarios, no lo he solucionado aún. Los problemas son: cómo identificar a qué entidad o conjunto de entidades se asocia un comentario, y cómo representarlos gráficamente. Para el primer problema, a veces hay una respuesta trivial, como cuando el comentario está justo a continuación de una instrucción, en la misma linea; y otras veces no, como cuando está en medio de dos lineas, donde podría ser una aclaración sobre lo que acaba de terminar (linea anterior) o sobre lo que viene (linea siguiente). Además, hay comentarios que se relacionan al código completo, o a bloques, y no a una linea en particular, o comentarios que no son aclaraciones, sino código anulado. Una solución podría ser considerar como comentarios generales los que están fuera del proceso (antes de "Proceso..." o después de "FinProceso"), y como comentarios de una instrucción los que están justo antes de la misma o a continuación en la misma línea. Aún así hay casos en los que esto no se condice con lo que el usuario pensó al colocar los comentarios, y además habría que ver como se mueven al reorganizar las instrucciones. Por otro lado, resta preguntarse cómo deberían mostrarse los comentarios en el diagrama, ya que pueden ser largos y ocupar demasiado espacio como para incluirlos directamente. Yo preferiría hacerlo mediante popups, por ejemplo, que se vean solo al dejar el mouse sobre la entidad a la que hacen referencia. De momento esto no está implementado: si se edita con este editor un pseudocódigo con comentarios, al guardarlo se pierden los comentarios (razón por la cual probablemente en la GUI de PSeInt se abra una copia luego de la edición en lugar de reemplazar el pseudocódigo original, al menos en las primeras versiones).

Empecé a escribir este módulo (a organizar las estructuras de datos en realidad) como tres o cuatro veces el año pasado, y en ninguna quedó prolijo, pero al menos en este último intento cumple con las funcionalidades que necesitaba. Con el tiempo iré puliendo el código y mejorando los comentarios (que igual ya están más presentes que en los otros módulos). Espero terminar pronto de corregir los errores e implementar la ida y vuelta con la GUI actual (no es poco lo que falta) para publicar la primer versión con diagramas editables. Mientras, pueden dejar sus comentarios y sugerencias basándose en el video, o compilarlo desde el repositorio git (al principio del cpp están los comentarios sobre cómo invocarlo).