Have you ever written code in the past which you come back to later and you can't understand what it does? Our project aims to fix this. Flowcharts are important in the early stages of program design as a neat way of representing how the program will work, but we think they can be important all the way through development. Visupy takes a Python function and automatically generates a flowchart, so the developer can more clearly visualise what their program is doing and try to make sense of it. As Visupy outputs to Latex, it can also be used for students and researchers to embed code in their papers in an easy to follow and visually appealing way. Visupy is designed as an accessible visualisation tool specifically for maths/physics students, who may not have as much programming knowledge and require a simple way to see what their code does.
Our project is mainly coded in Python, where it reads the code and works out how to format and draw each line. It then compiles the code in Latex, to produce the pdf output.
The main problem we faced was ensuring our code generalised well to more complicated statements, and scaled well to large programs. The approach we took after realising this was a problem was to give each line of the code its own custom Python object, which could have relationships to other lines. This allows us to build up complicated functions by breaking them into for loops, if statements, etc.
One of the biggest challenges was trying to work out how to program the relationships between flowchart blocks and how to link them together properly. This was solved by implementing a parent/child system, where each block has relationships to the blocks before and after it. Often there were arrows being drawn wrongly which were caused by hard to debug relationship/index errors. However, investigating how the arrows were drawn made us realise how to annotate and curve the arrows as needed.
We have build a working prototype from scratch, which we feel is a good achievement for the time we have spent on it. We can render flowcharts for simple functions involving combinations of if and for statements, including statements nested in each other. The flowcharts look professional and correctly summarise the code blocks input.
The correct positioning of boxes took a longer time than expected to finalize and it is very satisfying to see boxes without overlapping. The Latex package as written does not have logic to space the boxes automatically. As we wanted all the Latex to be written by the program, we had to investigate the documentation deeply. It working to a functional degree is the pay off of many man hours.
We have learnt how to write flowcharts using Latex and gained additional experience using the Latex package Tikz, a package I use regularly at university. We learnt how to read in and decipher functional code as a text string and then analysis it’s use. Thinking abstractly about creating pseudocode also changed our workflow and allowed us to quickly generalise what functions our code was able to understand. On an interpersonal note, the three of us had never worked on an intercontinental project over Zoom which has its own specific difficulties such conflicting time zones, different cultural ideas about workflow and code logic and different programming strengths. In overcoming these challenges in a time poor challenge has made us better team players and more flexible to different work environments.