HAVING a good mental model of how a

Transcription

1 DUSTIN RHODES CMPS261 PROJECT PROPOSAL 1 Dynamic Visualization of Code Control Flow Dustin Rhodes Abstract Having a good mental model of how computers execute code is important to becoming a good computer scientist. The area of program visualization and it s related field of visual programming both attempt to provide programmers with better tools for creating accurate models of their code. The majority of a program happens sequentially, however at certain critical points the flow of a programs execution jumps. This takes place at if statements, loops, and method calls. This paper shows a way of modeling if s and loops and a potential way of modeling function calls. A graph is created with sections of code being represented by nodes in the graph. A section of code is connected to all other sections of code which can potentially follow it. For the end of a loop for example the program can either jump to the top of the loop or continue on to the code after the loop. For the purpose of this paper a webpage was created which reads in a function written in javascript. It parses this code and creates a graph from it which is displayed alongside the original code. With this program I hope to provide a way of automatically producing clean, neat, and dynamic control graphs which can be changed and manipulated in real time. I believe this would be a very useful teaching tool which is not currently available. Index Terms flow graph, d3, javascript 1 INTRODUCTION HAVING a good mental model of how a program executes is both important for beginning programmers and often a difficult thing to learn. To aid in this learning there have been many program visualizations through out the years that attempt to allow a student to see what the program is doing visually. Most recently this work has been focused on generating animations of the code functioning or running the code in a glass box interpretor so the student can see the code as it runs. This visualization takes a different approach and attempts to display the running of a program as a single graphic. While this severely limits the amount of space available to view the code it allows for the user to see changes in their code as they edit. While a normal animation based visualization requires the animation to be rebuilt and re watched with a change in code this image based technique can dynamically change as the user edits. This visualization is based of a control flow diagram to show the user what sections of code get executed and when. Fig. 1. A snapshot of our visualization running on sample code 2 AREA OF RESEARCH This project touches on a number of areas of research. It is most at place in the field of

2 DUSTIN RHODES CMPS261 PROJECT PROPOSAL 2 program visualization, but it also uses some different ideas from the field of info viz to determine how it s final graph layout should look. As well as some other various info viz techniques to help to display the maximum amount of information clearly. Finally, while the project does not currently work in a visual programming way, it would be easy to extend it to that field. Most programmers form a mental model of code they are writing in their head while programming [7]. This mental model must contain elements such as program flow, memory constraints, and user input. Many modern programming techniques are used because they allow for a simplified mental model of a program. For instance method encapsulation helps immensely with program visualisation. If a method is free to modify any variables at will then we must fit all available variables into our mental model. If however we know that only a few variables which are passed in as parameters will be modified then it becomes much easier to reason about that section of code. Because these visualizations take place constantly while we program and we have so many programming paradigms to help us it is only natural that programmers would create viz representations to also help them understand their programs. These visualizations take place at many different levels, from the very high up and abstract, to the closer to code. algorithms. These animations proved helpful in teaching new students these algorithms however their use was very limited. Since each algorithm was created by hand they could not be applied to students own code or sculpted to instructor needs. Jeliot 3 Jeliot 3 uses animation to show the process of a program running in the java virtual machine. It is meant to show beginning programmers how a java program is executed. It models method calls, variables, and mathematical operations as animation. A key feature of this program is that the animations are created programatically and no special function calls in the code are needed to create an animation. Current work is being done on visualizing and animating objects in memory. [8] 2.1 Program Visualization Program visualizations come at many levels. Many of them work at a relatively high level. While these higher level viz applications are often helpful for experienced programmers to get a broad overview of their project they are of relatively little help for people just starting out. There is a whole class of programs used to help these students Early Work The first pushes in the area where static animations created to show fundamental computer science Fig. 2. this is jeliot 3 with code on the left and the current program state on the right. VINCE Vince is a similar program for C code. It focuses on showing the memory space of a program as it is being executed, instead of trying to show all the things jeliot does.

3 DUSTIN RHODES CMPS261 PROJECT PROPOSAL 3 [12] Bradman Bradman is a glass box interpretor for C code. It will run C code while showing the user the inner workings of the computer at the time it is running code. While previous work done in the animator field was focused on creating demos for class Bradman was meant to be used by students to run their own code. [9] Dr. Java and Jive Both of these programs combine a program editor with program visualization. Like Bradman students can watch as their code is executed. By combining the visualization with the coding environment it is possible to provide a very low barrier for entry to new students. Students simply type their code in and can then observe as it is executed and use the debugger to explore their code. [10] program visualizations to be developed. It does not feature an editor like Dr. Java or Jive and instead works more like older visualizations which read in source code and produced an animation. However, with Python Tutor the ease of creating these animations is greatly enhanced and the animations are interactive. Python tutor shows source code on the left and the function call stack and program memory on the right. The user can then step through their code, seeing which line is being executed and how it changes memory. The user can even step backwards in code. In addition to these features since it is online it offers many easy ways for professors to share code with their students. In addition it offers a nice view of objects in memory unlike previous visualizations.[11] Fig. 4. Python tutor in the middle of it s animation. The code that the animation is based off of and the current line are seen on the left hand side. On the right is the current function frame and also a picture of memory. Objects are well represented in memory. Fig. 3. Dr. Java editor while it is running it s debugger. The code editor can be seen on the top right with breakpoints and the stack represented in the middle section of the screen. Python Tutor Python Tutor is one of the newest Our visualization hopes to build off of these visualizations, in particular the ease of use of Python Tutor and the edit in place features of Dr. Java. It aims to display very different information from python tutor or any of the other visualizations though and does so as an image which represents your code instead of an animation which shows your code running.

4 DUSTIN RHODES CMPS261 PROJECT PROPOSAL Visual Programming Many recent program visualization tools stray into the realm of visual programming. Programs such as Dr. Java which combine a program visualization tool with an IDE come very close to being visual programming tools. Then there are other tools which function purely as visual programming tools whose results look an awful lot like common program visualization results. Our program fits into a similar spot. While it does not currently have any visual programming features implemented there are a variety of features which could be added to push it into this realm. 2.3 Info Viz Techniques In order to be a useful visualization of a program we will use a variety of different info viz techniques. The following common infoviz techniques are used. tree layout A standard tree is special graph in which each node only has 1 parent. drill down Drill down is a technique used to display more information when a user requests it. This allows for more information to be viewed then if all information was shown on screen at all times. heat map A heat map uses color to display information about an attribute. Usually cool colors are mapped to low values while hotter colors are mapped to higher values. 2.4 Motivation For beginning programmers learning which lines of a program are executed when and how often is a very important part of the learning process. Compared to other factors in code visualization it is the simplest to grasp and deals with the fundamental building blocks of code. Currently many intro programming lectures and books use hand drawn control flow graphs to explain if statements and loops. This implies that they are in fact useful for beginning programmers. There are not however any good tools currently available to allow these beginning programmers to view their own code as a flow graph. Graphs appearing in textbooks and slides are also by nature static. For those learning to code being able to play with the values of variables and see the effects this has on the execution of code is very important. A flow graph is a great way to see the effects changing variables can have on your code but there is currently no way to view this besides manually creating multiple flow graphs. 2.5 Dynamic Flow Tree The most basic idea for my program is that it generates a control flow graph based on the users inputted code. For the most part program flow starts at the top (line 1) and continues down line numbers. To represent this our graph is drawn as a dendrogram type structure. That is all elements with the same depth in the tree are drawn on the same line. This graph shows all possible flows that the program can take. If-Else statements are represented as a branching in the path of the control flow. Loops are represented like if statements as a branching but they also have a edge going back up the graph. The ends of loops are the only statements that link up the graph. Linking up the graph is of course a problem for a dendrogram type layout. While our graph is almost a tree in layout it is not quite. The fact that some nodes link upwards in the graph means that a particular node may have multiple parents. To get around this fact we assume that the depth of any given node is it s depth not counting looping. With out accounting for looping we can get an accurate depth of all nodes, place them in a dendrogram, and then draw the missing links. 2.6 Generating the Tree The first step in generating the tree is a parser. This parser reads in the user s code and generates a tree data structure from it. Each piece of this structure has a type, code, and children that it points to. Because this parser runs in real time in javascript it needs to be relatively fast for it to be usable. For this reason I used a parsing expression grammar instead of a context

5 DUSTIN RHODES CMPS261 PROJECT PROPOSAL 5 free grammar. The grammar only captures a tiny portion of javascript so the increased complexity of writing the parser as a PEG instead of a CFG was not large. However, because a PEG parser has no ambiguity like a CFG it can run in much faster time. While in the general case for analysing natural language it is still slow for much computer code it runs in O(n) time. As the parser reads through the users code it is generating the structure of the graph. There are however some differences in what the parser outputs and what the final graph shows. The first of these is if statements. An if statement has three children in this part of generation. It has a true child, a false child, and an after child. The true child is accessed if the statement in the if statement is true (this is stored as the code variable), the false is accessed if the if is false (this is the else portion if it exists), and the after child later gets pushed down so that the last statement in the if links to the after portion. Because the parser works in order it does not know at the time of parsing the if what the if s last child will be so it stores the after statment for later use. In the same manner of if statements loops also store the after portion in their own node for the parser portion of the code. The difference here is that loops just have a true child and an after child. There is no false child. The nodes created for while loops and for loops are identical after this stage so it is also the parsers job to convert for loops into a before code node, a loop node, and a code node that is executed at the end of the loop. Finally, the simplest change is the fact that in the parser each line of code receives it s own node. In the final graph this just leads to clutter so all code nodes which appear consecutively are combined into one node. This is easily accomplished by just making the link in that of the first nodes, the children that of the last nodes, and the code block that of all the code blocks added together. Now that the parser s work is done the code runs a couple of conversion methods on the tree that the parser outputs to fix the changes in what the parser outputs to what the user sees. After these have all been run we need to format the tree for display with d3. Because our graph is not technically a tree we can not give it to the dendrogram layout to layout automatically. We must compute depths ourselves in the way given earlier in the paper. After computing depths for each node we can set the appropriate y positions of each node using their depths. From here it is an easy task to set x positions such that true results appear to the left of false results. In order to create the graph code does not need to be completely syntactically correct. Only follow proper rules for creating ifs and loops. However, on the next step the user will run into problems if there are errors in the code. 2.7 Coloring the Tree Besides building a tree from the users code, the user is allowed to input specific values for their input variables and to see how their source tree is executed. Because, in building the tree our parser did not evaluate code it is perfectly possible that buggy code can generate a tree. However since this step must actually execute code in order to decide reachability it can not be run on buggy code. If buggy code is used a partial coloring of the graph will be outputted. This can be helpful for a user because they will be able to see what node the program stopped executing in and look for a bug around that area. In order to correctly color the tree the program first sets the variables that the user gives in the variables box. This box can be used by the user to set the input values of variables to be whatever they want so that they can test the graph on different inputs. After these variables are set a function is called on the root of the graph. This function calls exec on the code of the node, increments it s executed count by 1, and then calls the function on one of it s children. On a standard node with only one child that child is executed next. If the node is an if or while statement then the result of the exec statement is saved and used to decide which of the children to visit. Looping back up to the top of a loop is

6 DUSTIN RHODES CMPS261 PROJECT PROPOSAL 6 handled naturally because the only child of the bottom element of a loop is the top of the loop. At some point a node will have no children to visit and at that point we stop and are finished with our colouring. At this point our graph is complete and all the data is ready to be displayed so we give our graph data structure to d3 to display. 2.8 Reading the Graph On this graph nodes represent sections of code while links represent which code will possibly be executed next. For instance an if statement looks like the following (notice the green outlining)... The top node is executed and if it is found to be true then execution continues down along the green path. If the code is false execution instead follows down the red path and to the right. In general true statements stay to the left and follow green paths while false statements are shown on the right down red paths. That means that if all branches in your program evaluate to true the program will take a path straight down along the left hand side. This was chosen under the assumption that in general people assume a true if to be the default behaviour. While this is clearly not always the case it seemed more so then assumeing false to be the default. Here is an example of a while loop... As you can see it is structurally very similar to an if statement. It has two paths left and right with true being on the left and false being on the right. Unlike an if statement if the program takes the true path it will invariable loop back up to the top of the loop. This is shown by the purple connector going up. All connections which go up the tree are shown in purple and are shown as an arced line instead of a curve like the other paths. This is to prevent overlap as multiple statements can jump up to the same spot in code. To distinguish the node itself from an if node there are two things. First it is labelled to the left of it as a WHILE instead of as an IF. In addition to this the node is outlined in purple instead of green. Green is used for ifs, purple for loops, and blue for all other sections of code. To determine which nodes have been reached with the given inputs we look to the fill colors of the nodes. All nodes start out with a white fill and they keep this white fill if the node is not reached by the code. However if the node is reached it receives a yellow to red color. A pure yellow node will have been executed once while a pure red node will have been executed more then any other node. All the other nodes are coloured on a linear scale between these to. This allows for the user to easily see at a glance which nodes have or have not been reached and also lets them know which parts of their programs are running most often. 3 WHAT S NEW While other recent code visualization techniques have used animation to show a program executing this implementation uses a single image to show the entire execution path. While this gives you much less space to impart all the necessary information it does have a large advantage. While an animation must be generated and then watched my image can be updated as a user edits their code. This mean that if a user is using this visualization to debug their work then they can make changes and see these changes in real time, a case where an animation would not work. For example if a user is attempting to see if a given section of code ever executes they can generate a graph for their function and then try out various inputs. When they try a new input the graph will automatically recolor nodes to show which ones have been reached. This can allow them to very quickly find if

7 DUSTIN RHODES CMPS261 PROJECT PROPOSAL 7 a given section is ever executed for a large array of inputs. If they find that that section is never executed simply changing the code will automatically produce a new graph where new inputs can be tried. 4 WHAT S NEXT So far all the work on this visualization has been on the program visualization side of things. As with most program visualization tools it is easy to see how the program could be modified to work in a visual programming way. In the current program if a user wishes to change her code she must edit the source code that is being input into the viz. At this point the visualization will update. It would be nicer if the user could edit their code directly in the visualization and these changes would be pushed back to the source code. Of more interest but also significantly more complicated it would be interesting if a user could edit the structure of the graph and have these structural changes be echoed back in source code. For example a user could create an edge between two nodes on the graph and give a condition on which this edge should be travelled. This change could then be pushed back to the code. Something like this would allow a user to build up an entire algorithm visually and not just edit an existing one. Beyond making the program a visual programming tool there are a number of ways that the visualization could be improved. Most importantly the visualization is currently only useful for visualizing a single function. In the context of a larger program each function can be thought of as having it s own graph representing it. Then when a function call is executed that is represented as a link from that node to the called functions root node. In addition to that all leaf nodes of the called function will point back to the calling node in the original function. While the idea is simple enough this produces a very large and complicated graph. Navigation within the graph becomes much more of an issue as you can not simply read mostly top to bottom as in the current graph. Finally there are a number of smaller changes that could be made to make the graph representation more complete. At the moment break, continue, and try catch statements all effect the flow of a program but are not modelled in this graph. None are particularly difficult to model however. A break statement simply links to the false statement of the nearest loop node up from it, a continue statement simply links back up to the nearest loop node up from it, and a try catch functions very similarly to an if statement as far as program flow is concerned. 5 CONCLUSION This project hopes to be a simple to use program which can create dynamic control flow graphs to aid students learning computer science. As of now there are currently no other programs that do this. All products currently available are aimed at advanced users and do not allow for dynamic manipulation of input variables or code. Hopefully, this tool will allow for easier understanding of some of the most basic components of computer science. REFERENCES [1] Tim Dwyer, Edge Compression Techniques for Visualization of Dense Directed Graphs. December 2013 [2] Pak Chung Wong, Dynamic Visualization of Graphs with Extended Labels. Pacific Northwest National Laboratory [3] [4] [5] [6] Erkki Kaila, Effects, Experiences and Feedback from Studies of a Program Visualization Tool.December 2008 [7] Hundhausen, C.D., Douglas, S.A. and Stasko, J.D., A Metastudy of algorithm visualization effectiveness. Journal of Visual Languages and Computing year=2011, publisher=jeliot [8], Ben-Ari, Mordechai and Sutinen, Erkki and MyIIer, N and Garcia, AM and Bednarik, R and RoBling, G and HauBge, G and Pineau, A and Rongas, T and Levy, RBB and others, Jeliot [9] Sorva, Juha, Ville Karavirta, and Lauri Malmi, A review of generic program visualization systems for introductory programming education.. ACM Transactions on Computing Education [10] Eric Allen, Robert Cartwright, and Brian Stoler, DrJava: A lightweight pedagogic environment for Java. September 7, 2001 Presented at SIGCSE 2002

8 DUSTIN RHODES CMPS261 PROJECT PROPOSAL 8 [11] Philip J. Guo, Online Python Tutor: Embeddable Web-Based Program Visualization for CS Education. In Proceedings of the ACM Technical Symposium on Computer Science Education (SIGCSE), March [12] Glenn Rowe and Gareth Thorburn, VINCE an on-line tutorial tool for teaching introductory programming Dept of Applied Computing University of Dundee DUNDEE DD1 4HN