Algorithm Visualizer

Algorithm Visualizer

• 1.
  CS512 Project: AndroidApplication as an Educational Tool for Algorithm Visualization and User Knowledge Testing Hristiyan Kourtev, Anwar Jameel, Aditya Ambadipudi Venkata Rutgers University, Piscataway, NJ, USA Emails: hkourtev@ruccs.rutgers.edu, aj528@scarletmail.rutgers.edu, vsa17@scarletmail.rutgers.edu RUIDs: 102009662, 166009833, 167000877 Abstract— In order to understand the algorithm, however simple it may be, we often employ some kind of visualization (drawing on paper, image, video etc.). Anyone who has studied algorithms knows how helpful a visualizer can be to understand how an algorithm works. By seeing how the algorithm works step-by-step we can often understand it with just a glance, while going through the pseudo code and other written explanations and trying to imagine what is going on, can be time consuming, confusing and frustration. There is a wide variety of algorithm visualizers for different algorithms and representations, however what we haven’t been able to find however was a tool that allows user to visually manipulate the data and data structure, in a way the algorithm would and check each step to make sure user is doing exactly what the algorithm would have done. Our application does exactly that, while also collecting statistical information about errors made by the user, which can help instructors and students to identify problematic areas/steps and work on improving them. I. PROJECT DESCRIPTION Our goal is to build an Android application, which will serve as a teaching and learning tool with 3 major components: • Learning mode, providing step-by-step visualization of graph-based algorithms, such as Kruskal/Primm’s Mini- mum Spanning Tree algorithm. • Testing mode, providing a visual interface for manip- ulating data and data structures to duplicate the steps performed by the specific algorithm, an excellent way for users to test their understanding. Each step will be verified against the algorithm and feedback will be pro- vided in real time. This latter capability is something we have been unable to find in any other mobile/touchscreen application for algorithm visualization available at the moment. • Statistics, providing an overview of the number and frequency of each type of mistake made and the step in the algorithm at which they occurred. Such statistics can be very useful to an instructor, who can use them to identify problematic areas and work on providing better explanation. We believe our project will help many students to test and improve their knowledge of algorithms. Being an application for a mobile platform it is something which students can do on the move, while waiting for the bus, for example. Our main hurdle will be to find a streamlined visual inter- face which provides all necessary information, allows the user to modify the data and data structure involved in the algorithm, while being easy and intuitive to use. We will also build the system with expandability in mind, so that it can be extended with additional algorithms without too much difficulty. The project has four stages: Gathering, Design, Infrastruc- ture Implementation, and User Interface. A. Stage1 - Requirement Gathering Stage. Before commencing any project it is important to clearly define, objectives, users, requirements, a realistic timeline and ways to fairly and efficiently divide work within the team. • Types of users: A wide variety of users can use our app, for example students, teachers and people who are just curious about algorithms. • User interaction modes: – Learning mode, where the algorithm operations will be demonstrated step by step on a random set of data, while each step is narrated in detail as well – Testing mode, where the user will be presented with input data and the necessary data structure building blocks and will be asked to perform all the steps the algorithm would perform in order to produce the correct final output. – Statistics mode, which allows users to view statis- tical information about the type and frequencies of mistakes they have made. • Real World Scenario 1 - Student learning how to use Kruskal’s algorithm to produce the Minimum Spanning Tree of a given graph: Students and other curious individuals can use the appli- cation to get a visual representation of how a particular algorithm works, step by step, together with detailed explanations. Once students are familiar with the process and data structures used they can switch to test mode and test their knowledge by trying to replicate the algorithm’s steps on a new randomly generated graph. At each step the system will verify their actions and will not allow them to proceed until they perform the right action or until they make 3 incorrect choices in a row, at which step the step will be skipped and the user can continue.
• 2.
  – Input DataTypes: A graph G with V vertices and E edges where every edge has a weight. – System Data Output: Visualization and explanation of each and every step of Kruskal’s algorithm for finding the Minimum Spanning Tree of a graph G. A Minimum Spanning Tree of G. – Output Data Types: A list of the steps involved in computing Minimum Spanning Tree of a given graph G, using Kruskal’s algorithm and a list of any errors made by the user. • Real World Scenario 2 - A teacher teaching Minimum Spanning Tree Algorithms and testing students’ knowl- edge of Kruskal’s Minimum Spanning Tree Algorithm: A teacher in a digital classroom equipped with electronic tablets can teach the algorithm by demonstrating the step by step visualization of the algorithm using this mobile application. The teacher can then use the application as a testing platform with automatic scoring and can use the statistical data collected to identify potential problems with their description of certain steps of the algorithm and work on generating better descriptions, if necessary. – Input Data Types: A graph G with V vertices and E edges where every edge has a weight. – System Data Output: Visualization and explanation of each and every step of Kruskal’s algorithm for finding the Minimum Spanning Tree of a graph G. A Minimum Spanning Tree of G. – Output Data Types for Scenario2: A Minimum Spanning Tree of G. • Project Time-line – Stage 1 - Requirement gathering stage: Submit project proposal. (Due October 28, 2015) – Stage 2 - Design stage: Choose algorithms to be included in the application, define general categories and group algorithms based on similarities of data structures used, methodology and visual represen- tation, identify visual and structural items needed to implement the algorithms in each category. (Due November 3, 2015) – Stage 3 - Implementation stage: Program visual and back-end items. Debugging and preliminary testing. Usability testing with real users. (Due November 24, 2015) – Stage 4 - Presentation: Prepare project highlights and final presentation. (Due December 3, 2015) • Division of Labor. – Hristiyan: User Interface design and implementation – Anwar: Database and Back-End design and imple- mentation – Aditya: User Experience design and implementation, usability testing B. Stage2 - Design Stage. • Short Textual Project Description. The application being designed contains 4 activi- ties (activity in android is every screen that user can see and interact with) namely Main Activity, Learn Activity and Test Activity. Main Activity is the activity which gets invoked with the application launch by the user. Main Activity provides the user with options to enter into Learning mode (Learn Activity), Testing Mode (Test Activity), Statistics Mode (Statistics Activity) or Exit the application. Learning Mode (Learn Activity) comes into the foreground when user selects Learning mode in Main Activity. Learn Activity runs the services (service in android is a background process) to generate the graph, run algorithm on the generated graph, store the algorithm steps to database and visualize the stored steps in an orderly manner. Testing Mode (Test Activity) comes into the fore- ground when user selects Test mode in Main Activ- ity. Test Activity runs the services to generate the graph, run algorithm on the generated graph, store and retrieve the algorithm steps to and from database, draw the graph on screen, check the user steps to trace an algorithm and display the statistics of test. • Flow Diagram. Flow Diagram is shown in Fig. 1 • High Level Pseudo Code System Description. Please insert high level pseudo-code describing the major system modules as per your flow diagram. • Algorithms and Data Structures. – Graph Generation Algorithm (Description) In order for the app to provide a better educational experience and to give users the ability to test themselves on the same algorithm multiple times, we decided that it is necessary for us to use randomly generated graphs. This means that every time the user reloads the application they will see a different graph. Using randomly generated graphs will ensure that the users get to see how the algorithm operates on a variety of different graphs and will prevent them from remembering a solution, so that every time they test themselves on one of the provided algorithms, they will actually need to solve a completely different problem. This required us to solve the problem of random graph generation. Our research revealed that random graph generation is a very complex prob- lem with a multitude of parameters and constraints, depending on the purpose and type of graph. Our time constraint prevents us from performing detailed research on the subject, so we looked for a simple
• 3.
  Fig. 1. AppFlow Diagram (even though imperfect) method, which would be easy to implement. We initially planned on using an algorithm called ”The Configuration Model” and in particular, ”The Erased Configuration Model”. The algorithm’s inputs are n - number of vertices and d - average vertex degree desired. It proceeds by creating n vertices and a standard probability distribution for the vertex degree F with median d. It then iterates over the list of vertices and for each one generates d stubs (stubs are edges for now just connected to the current vertex v). d is picked randomly based on the probability distribution F. Then it loops over the stubs and joins each randomly selected pair. The resulting graph may not always be simple and there could be multiple edges between vertices. To solve this problem the algorithm inspects all edges of the graph and collapses any multiple edges into a single one. Despite the relative simplicity of this algorithm it solves one problem and creates many more. Having a truly random graph requires a good universal graph visualization algorithm and that is yet another very broad research area which we will be unable to properly explore in the limited time that we have. In addition to the time constraints we are also restricted by a relatively small workspace (e.g. a cell phone screen) and the need for a clean and unambiguous visual representation, where all nodes and edges are clearly visible, not overlapping and of a size that is easy to select and manipulate with a finger. All of these restrictions and the fact that the purpose of this project is algorithm visualization, not in-depth research on graph generation and visu- alization algorithms, forced us to come up with an alternative semi-random graph generation algorithm, which would solve both problems (generation and visualization) with one stroke. We begin with a predefined matrix-like graph of 4 x 3 vertices with each node having an undirected edge to each of its neighbors (see Fig. 2). Each node can have the following types of edges E, NE, N, NW, W, SW, S, SE, where E, W, N, S represent East, West, North and South respectively. We then randomly pick X (X will probably = 3) nodes to be removed. When removing a node we check to see if there are opposing edges (e.g. N and S, or SW and NE). If such pairs exist, they are replaced with a single edge that spans the entire distance between the 2 neighbors of the node that is being removed.
• 4.
  Fig. 2. Initialdefault graph with nodes marked for deletion Fig. 3. Nodes removed Finally we loop over all edges and assign them ran- dom weights from a pre-specified range. If the graph needs to be directed, we replace each undirected edge (u,v) with a random choice of either 1 directed edge (u, v), 1 directed edge (v, u) or 2 directed edges (u, v) and (v, u) - i.e. a loop (See Fig. 4). Even though quite simple this algorithm can still generate, a wide variety of graphs, sufficient for our needs and greatly simplifies the graph visualization problem, allowing us to spend more time on the user interface and experience. – Graph Generation Algorithm (Data Structures) Please note that since a lot of the data structures we use are shared between modules, we will only list their names and for more information you can refer to the comprehensive list of data structures at the end of this section. Pseudocode: Fig. 4. Cross edges removed. Directed graph. function generate graph(height, width) input height: the height of the base graph which will prune, the width of the base graph which will prune output: A random graph begin graph base = generate empty graph(height, width) for i := 0 to height for j := width boolean node lives = gener- ate random number(0, 1) > 0.5 ? true : false; if(node lives) base[i][j].valid = true; foreach (node1, node2) in base boolean edge lives = gener- ate random number(0, 1) > 0.5 ? true : false; if(edge lives) node1.connects(node2) return base; end Data structures used for graph generation: Graph, Node, Edge – Visualize Steps (Description) In order to be able to visualize (in learn mode) and verify (in test mode) steps, we store the steps that the selected algorithm takes during its execution and store them in an ordered list. Each step can be comprised of 1 or more actions. Here’s an example of a step with multiple actions: selectEdge(u, v), relaxNode(u, v, w); During visualization we begin by drawing the original graph. We then loop over the list of steps, executing each one and redrawing
• 5.
  the graph. Inaddition to specifying what actions to take in each step, actions are also described in plain English and captions of each step are displayed, wherever applicable, each time the graph is redrawn. – Visualize Steps (Data Structures) Data structures used: Exercise, Graph, Node, Edge, SolutionStep, Action – Verify Steps (Description) The verification process is very similar to the step visualization process. After the original graph is displayed we wait for user input. We then wait for user input. When the user has made the same number of actions as the number of actions we have in the current step, we display a ”Confirm Step” button to the user. The user has the choice to make changes to the steps they have made or confirm. The total time taken by the user to execute this step is recorded for statistical purposes. Upon confirmation we compare the actions that the user made in the current step, with the actions we expect. Actions do not need to be in the same order, so for each user action we search the entire list of actions comprising the current step. If all steps match, the user is given positive feedback (ding sound) and is allowed to continue. If the user has made a mistake he is given negative feedback (buzzer sound) and is allowed to retry. If the user makes 3 mistakes the correct step is executed and visualized and the user is allowed to continue. – Verify Steps (Data Structures) Data structures used: Exercise, Graph, Node, Edge, SolutionStep, Action, Mistake, DBHandler – Draw Graph (Description) The graph generation algorithm provides us with a list of nodes and edges and has an inherently neat rectangular shape overall, so displaying the graph is quite trivial. We begin by first drawing the nodes. We know the screen size and node size relative to the screen size, margins and padding, as well as the number of rows and columns of nodes so it is easy to calculate the spacing between nodes. The edges of each node are also labeled using geographic directions so we know where each node needs to be positioned relative to others. Once the node positions for the current screen size are calculated (Fig. 4), we add some random jitter to their positions, in order to make the graph look more random and less rectangular. The jitter is a small translation in a random direction. The resulting graph now looks a lot more random and less artificial (Fig. 5). Pseudo code Function draw graph(nodes[row][col], edges, width, height) Fig. 5. Cross edges removed. Directed graph. input: nodes[row][col], edges, screen width, screen height begin node radius = min( (height - 100)/row, (width - 50)/col ); for i := 0 to row, for j := 0 to col, if(nodes[row][col] is set to show): X = 25 + col * (node radius + node padding); Y = 50 + row * (node radius + node padding); draw circle(node radius, X, Y); for each edge E, Nodes start = E.start Nodes end = E.end draw line(start.coordinates, end.coordinates) end – Verify Steps (Data Structures) Data structures used: Graph, Node, Edge – Display Statistics Upon completion of the exercise we loop through all the steps taken by the user and calculate the total number of mistakes made and time taken to complete the exercise. – Data Structures (Detailed Outline) Node (properties) ∗ label ∗ value ∗ color ∗ size ∗ border thickness ∗ position ∗ edges (E, NE, N, NW, W, SW, S, SE, Other)
• 6.
  Node (functions) ∗ create ∗delete ∗ select ∗ move ∗ draw ∗ set value ∗ set color ∗ set thickness ∗ get degree ∗ get neighbors ∗ relax Edge (properties) ∗ start node ∗ end node ∗ directed ∗ weight ∗ color ∗ thickness ∗ start point ∗ end point Edge (functions) ∗ create ∗ remove ∗ draw ∗ select ∗ set color ∗ set weight ∗ set thickness Graph (properties) ∗ nodes ∗ edges ∗ roots ∗ solution steps Graph (functions) ∗ generate ∗ draw ∗ add edge ∗ remove edge ∗ solve (takes as input the algorithm to run) SolutionStep (properties) ∗ actions (list) ∗ final (boolean) ∗ num tries ∗ time taken SolutionStep (functions) ∗ add action ∗ remove action ∗ compare actions Action (properties) ∗ action index (from a predefined list of actions) ∗ action parameters ∗ description Action (functions) ∗ compare Exercise (properties) ∗ original graph ∗ final graph ∗ algorithm ∗ solution steps Exercise (functions) ∗ initialize ∗ generate solution steps ∗ visualization next step ∗ visualization previous step ∗ exercise wait for input C. Stage3 - The Implementation Stage. Our project is an Android Mobile Application, therefore, we have used JAVA programming language and Android Studio integrated development environment for our project. The deliverables for this stage include the following items: • Sample small data snippet. – Fig6 shows the sample graph which is fed to the algorithm for finding MST. This input graph is generated randomly. Fig. 6. Randomly Generated Input Graph • Sample small output. – Fig7 shows the step by step Minimum Spanning Tree construction using Union by Rank and FindSet with path compression operations. • Working code. – Working Code is submitted in a zip file. • Demo and sample findings. – Fig8 shows the Final Output i.e. Minimum Spanning Tree – System Memory Requirement for Application to run is 512MB RAM – User cannot manipulate with the graph during Learn- ing Phase. Every time the user launches the activ- ity, user is provided with the new graph which is randomly generated in its size and the associated weights for each edge. User is provided with a
• 7.
  Fig. 7. MinimumSpanning Tree under construction using a forest of trees to represent disjoint sets Fig. 8. Output Minimum Spanning Tree Learning Method which displays the foundation of an algorithm such as Union and FindSet operations. D. Stage4 - User Interface. The developed Android application provides user with a user friendly interface to interact with the application. The User Interface is designed in order to provide the user with effective ways of learning. The HOME screen of application appears when user starts the application by pressing the appli- cation icon. The Home screen provides the user with an option to Learn, Test, View Statistics and Exit. The activity on the basis of user’s selection(learn, test etc.) will be launched next. The Learn activity provides a step-by-step visualization of the steps the algorithm makes in order to produce the final output. The Test activity provides the user with a testing environment where, using the touch screen, they can manipulate the data and data structures in the same ways the algorithm does. Each user action is verified by comparing it against the step that the algorithm would perform. Appropriate confirmation and error messages are displayed at each step, in addition to a pop-up message and auditory feedback (good sound/bad sound). At each step, in both Learn and Test activities, the user is able to switch between Tree View (the default view; displays the forest of trees that the algorithm uses) and Graph view (shows the MST as it is being built, using the original graph topology). Most figures in this section will display both views. Statistics of user attempts are stored and can be retrieved by launching Statistics activity. • The HOME screen of application appears when user launches the application and it looks like as follows: Fig. 9. HOME Screen • Learn Activity - Randomly Generated Input Graph (Fig. 10) Fig. 10. Initial Learn Mode Screen - Input Graph The user is only able to press ”NEXT”, so it is very intuitive. After the first step the user can use the ”PRE- VIOUS” button to go back and review a previous step if they like. They can use the ”SWITCH VIEW” button to switch between Tree and Graph views • Learn Activity - Make Set operation (Fig. 11) In tree view, nodes not yet in a set are displayed in the column to the right, while the nodes produced by the Make Set operation are arranged horizontally, with a rank of 0 and red halo to denote that those nodes are roots The notification box displays detailed information about this step. Message format: ”Create set of 1 with root node u”, where u is the label of the node. • Learn Activity - Select Edge operation (Fig. 12) The previously explored edges are colored in gray, un- explored edges are colored in blue, just like the nodes
• 8.
  Fig. 11. MakingSets in the trees and graph and the currently selected edge nodes are colored with 2 different colors in both the list at the bottom and in the tree/graph as well. This makes it easy for the user to visualize the sets/nodes we are working with at all times. The notification box also displays information about which set is currently selected. Message format: ”Select edge (u,v)”, where u and v are the labels of the nodes. • Learn Activity - Union operation Message format: ”Unite the sets that node u belongs to (tree with root x) and v (tree with root y) by making node u parent of node v”, where u and v are the nodes of the currently selected edge and x and y are the roots of the sets they belong to (can also be u and v, or just u or just v). • Learn Activity - IncreaseRank operation This operation increments the rank of the parent set’s root and redraws the graph. Message format: ”Since the root of the parent tree (node u) has the same rank as the root of the tree being appended (node v), we increase the rank of node u”, where u and v are the roots of the sets that the nodes of the currently selected edge belong to. • Learn Activity - AddToMST operation This operation adds an edge, that has had the Union operation performed on it, to the list of MST edges, that will be used to produce the MST. Message format: ”Adding edge (u,v) Fig. 12. Union operation performed. Selected edge can be seen colored in yellow/orange to MST”, where u and v are the labels of the nodes of the currently selected edge. • Learn Activity - SkipEdge operation This operation skips the current edge, since its nodes are already in the same set. Message format: ”Nodes u and v belong to the same set. Cannot unite. Skipping edge.”, where u and v are the labels of the nodes in the currently selected edge. • Learn Activity - Final Product (Fig. 13) The MST is complete. We can see both the final tree produced by the union of sets as well as the actual MST. Message format: ”All edges explored. Minimum Weight Spanning Tree complete. Weight: X. Press QUIT to go back” • Test Activity - Randomly Generated Input Graph The user is only able to press ”START”, so it is very intuitive what to do. • Test Activity - START The user has at their disposal 2 actions/buttons - GET NEXT EDGE and UNION. The user begins with the MakeSet operations and Sort- Edges operation already completed. This is done since the operations are trivial and time consuming if done manually one by one. Initially those actions were manual, however automating them greatly improved the user experience, without having a detrimental effect on the learning experience. The user is clearly informed of this
• 9.
  Fig. 13. Finalproduct - MST complete Fig. 14. Initial Test Mode Screen and is prompted to begin by getting an edge from the queue. Message format: ”NOTE: All MakeSet operations and the SortEdges operation have already been executed automatically, as they are trivial. Please begin by getting an edge from the list.” • Test Activity - GetEdge operation (Fig. 15) The ”GET NEXT EDGE” button combines 2 different operations - GetEdge and SkipEdge. A separate button for SkipEdge was initially created, however Simplifying by combining both of these operations under the same button (since they are very similar) resulted in a more fluid user experience. Getting an edge colors its nodes so they can be easier to identify. In case of this being the correct step there are 2 cases Fig. 15. Test Mode - Get Edge operation – Case 1 - The nodes on the edge belong to the same set so the user would like to skip this edge and get the next one. Success Message format: ”STEP CORRECT! Nodes u and v belong to the same set. Cannot unite. Skipping edge”; ”Select edge (u,v)” The user also received positive auditory feedback (ding) – Case 2 - The nodes on the edge have already been united, so the user would like to get the next edge. Success Message format: ”STEP CORRECT! Select edge (u,v)” The user also receives positive auditory feedback (ding) In the case that this is the incorrect step, the user is given the proper feedback (See Fig. 17) Error Message format: ”Error: Wrong action selected. Try again. of errors until step is skipped: X” Popup message contains the same text. It automatically disappears after a couple of seconds. The user also receives negative auditory feedback (errr) • Test Activity - FindSet operation (implicit) This operation is one of the major parts that are peformed by the user. They have to do a visual search and figure out for the node in question, which set it belongs to. • Test Activity - Union operation (Fig. 16) Pressing the UNION button prompts the user to make the right selection. They need to select the sets that the 2 nodes belong to by touching the roots of those sets. The tricky part here is the order in which the set roots
• 10.
  Fig. 16. TestMode - Union operation need to be selected, as the first selected root is to be the parent of the second. If both roots have the same rank, the order obviously doesn’t matter, however otherwise it is mandatory that the user selects the root with the higher rank first. Again in order to streamline the user experi- ence, the Union operation in Test mode combines 3 steps - Union, IncreaseRank and AddEdgeToMST. Message format: ”Action UNION selected. Select the roots of the 2 sets that should be united” After selecting one node, the user is provided with additional feedback: Message format: ”You have successfully selected node (u). Please select 1 more node or press CANCEL” Upon selecting the second node, the step is automatically verified. And the user is given the proper feedback: Success Message format: ”STEP CORRECT! Unite the sets that node u belongs to (tree with root x) and v (tree with root y) by making node u parent of node v”; ”Since the root of the parent tree (node u) has the same rank as the root of the tree being appended (node v), we increase the rank of node u”; ”Adding edge (u,v) to MST” The user also receives positive auditory feedback (ding) If the step is incorrect, there are 2 possible reasons: the user was not supposed to do a Union, or they selected the wrong sets (See Fig. 17). Error Message format: ”Error: Wrong action selected. Try again. of errors until step is skipped: X” Popup message contains the same text. It automatically disappears after a couple of seconds. The user also receives negative auditory feedback (errr) Error Message format: ”Error: Correct action selected but wrong parameters provided. Try again. of errors until step is skipped: X” Popup message contains the same text. It automatically disappears after a couple of seconds. The user also receives negative auditory feedback (errr) • Test Activity - Final Product The MST is complete. We can see both the final tree produced by the union of sets as well as the actual MST bu switching views, just like in the Learn Activity (See Fig. 13) • Test Activity - More About Errors As mentioned above the user is provided negative feedback in 3 ways - the notification box (See Fig. 17), a toast message (popup) (See Fig. 18) and via auditory (an ”errr” sound). Fig. 17. Error Messages Fig. 18. Wrong action After 3 wrong attempts in TEST mode, an error message appears and user is advanced to the next step as shown in the Figure 19: • Statistics Activity: for every TEST trial by the user is saved and displayed when user launches Statistics Activity from Home Screen. Statistics are shown in Figure 20: • Future Work: There are 2 major ways in which we believe the app can be improved:
• 11.
  Fig. 19. Useris advancing to next step automatically Fig. 20. User Test Trials Statistics. – Extendability and Usability: Add more algorithms and further improve the user experience. Currently in order to extend the app capabilities by adding an additional algorithm, the programmer would need to create a Java class with the algorithm implementa- tion, as well as create activities for the Learn and Test modes, where they implement a button for each possible algorithm action. This process is not easy to automate but it is possible to create a standardized way of doing this (e.g. a plugin architecture), so that algorithms can be added without the need to code in Java. – Global Statistics: Currently the statistics are stored in a SQLite3 database on each individual machine, so the data collected is for the users of that particular device only. The data can easily be stored in an online database. This improvement would allow a teacher to easily get statistics about multiple students at once. REFERENCES [1] Roberto Tamassia, Handbook of Graph Drawing and Visualization - https://cs.brown.edu/∼rt/gdhandbook/ [2] Force-Directed Graph Drawing Approach - https://en.wikipedia.org/ wiki/Force-directed graph drawing [3] Force-Directed Graph Drawing Approach - https://www.youtube.com/ watch?v=VxiKoT I P4 [4] JUNG - Java Universal Network/Graph Framework - http://jung. sourceforge.net/ [5] Flowchart Shape and What They Mean - http://www.rff.com/flowchart shapes.htm [6] 10 Tips and Tricks for Making Flowcharts - http://www.breezetree.com/ article generalflowcharting1.htm