Masaryk University Faculty of Informatics Procedurally Generated Landscape as a Visualization of C# Code Bachelor’s Thesis Adam Štěpánek Brno, Spring 2020 This is where a copy of the official signed thesis assignment and a copy ofthe Statement of an Author is located in the printed version of the document. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Adam Štěpánek Advisor: Mgr. David Kuťák i Acknowledgements I thank my advisor, Mgr. David Kuťák, for patience and invaluable feedback. I also thank my colleagues at Riganti for their input and for letting me use their hardware to deploy Helveg. Last but not least, I thank my D&D group for their encouragement, and everyone who supported me, while working on this project, in any way. ii Abstract Software visualization helps programmers better understand code through visual means. This thesis presents a software visualization tool, named Helveg, that maps the structure of C# code, along with compiler diagnostics, onto a procedurally generated landscape. This is achieved in three stages (code analysis, landscape genera- tion, and rendering), which the thesis describes in detail. Presented are also case studies involving open-source codebases. Results of these case studies show that Helveg can be used to visualize the structure of a C# codebase in a visually appealing way. Also, analysis of these outputs helps to pinpoint the drawbacks of the current visualization thus providing ideas for future work. iii Keywords software visualization, procedural generation, C#, Roslyn, Vulkan, L-system, force-directed graph drawing, .NET Core Tool iv Contents 1 Introduction 1 2 Related Work 2 2.1 Graphs and Diagrams .....................3 2.2 Code Cities ..........................5 2.3 Islands .............................7 3 Overview of Helveg 9 3.1 Requirements .........................9 3.2 The Metaphor ......................... 11 3.3 Pipeline ............................ 15 3.4 Architecture .......................... 16 3.5 The Debug Command ..................... 17 4 Code Analysis 19 4.1 A Brief History of .NET ................... 19 4.2 Project Loading ........................ 20 4.3 Semantic Model ........................ 21 5 Landscape Generation 24 5.1 Layout ............................. 24 5.2 Terrain ............................. 28 5.3 Structures ........................... 30 5.3.1 L-systems . 30 5.3.2 Spruce Trees . 32 6 Rendering 34 6.1 Layers of Vku ......................... 34 6.2 WorldRender ......................... 36 6.3 The Camera .......................... 38 7 Distribution 39 7.1 A .NET Core Tool ....................... 39 7.2 Continuous Deployment ................... 40 8 Case Studies 42 v 8.1 Sample Projects ........................ 42 8.2 DotVVM Academy ...................... 45 8.3 Roslyn ............................. 46 9 Conclusion 47 Bibliography 49 A Electronic Attachments 56 B Build Instructions 57 vi List of Tables 4.1 Weights of type relationships. 23 5.1 Turtle drawing commands. 31 5.2 Additional symbols of the spruce L-system. 32 6.1 Keyboard control scheme. 38 vii List of Figures 2.1 Visualizations with different levels of abstraction. 2 2.2 A flame graph [12]. 4 2.3 A Gource visualization of a repository log [14]. 4 2.4 The software galaxy of Go packages [16]. 5 2.5 An isolated district of a code city [18]. 6 2.6 IslandViz [4]. 7 3.1 The mapping from C# code to a landscape. 12 3.2 The effects of compiler errors and warnings. 14 3.3 The Helveg pipeline. 15 3.4 Helveg’s architecture viewed through the file system. 16 3.5 Invocation of a debug subcommand. 17 3.6 Sample outputs of debug subcommands. 17 4.1 The layers of Roslyn APIs. 21 4.2 A visualizer of Roslyn’s syntax trees [39]. 22 5.1 The simulation of gravity in an FDG step. 25 5.2 Attractive and repulsive forces of FDG. 26 5.3 Computation of adaptive speed in an iteration of FDG. 27 5.4 The heightmap of an island. 28 5.5 The terrain of an island. 29 5.6 Orientation of Helveg’s “turtle”. 32 5.7 L-system production rules for the growing of spruce trees. 33 6.1 The layers of Vku’s framework. 35 6.2 The graphics pipeline [47]. 36 7.1 Typical Helveg installation process. 39 8.1 A visualization of a tidy project. 42 8.2 A project that breaks coding conventions. 43 8.3 A project with compiler errors. 44 8.4 A detail of the visualization of DotVVM Academy. 45 8.5 The islands of DotVVM Academy. 46 9.1 Helveg’s visualization of its own C# codebase. 47 A.1 Notable files and directories of the Helveg repository. 56 viii 1 Introduction Programming is not merely about writing code. A large portion of a programmer’s time is spent trying to understand the structure of the program. Therefore, anything that helps the programmer understand code faster and better is a welcome addition to their toolbox. One way to aid code comprehension is through software visualization. The field of software visualization concerns itself with giving in- sights into computer programs that would otherwise be difficult to gain just by reading the source code. Software visualization tools convey information about, for instance, process memory, program performance, or code structure. The subject of this work is Helveg, a tool that visualizes the struc- ture of a C# codebase as well as errors and warnings reported by the C# compiler. Helveg maps units of code structure, such as classes and MSBuild projects, to objects found in a natural landscape like trees and islands. The purpose of this metaphor is to make Helveg not only informative but also compelling. At its core, Helveg is a cross-platform console application, which uses the Vulkan graphics API1 to render the landscape. The following chapter describes the field of software visualization and existing tools. Chapter 3 contains an overview of Helveg, which is later described in detail in Chapters 4 through 7 focusing on the code analysis, landscape generation, rendering, and distribution aspects of the tool, respectively. Case studies of Helveg’s outputs are contained within Chapter 8. The thesis concludes in Chapter 9 with a summary and discussion of future work. 1. Application Programming Interface 1 2 Related Work The purpose of visualization is to gain insight into complex data by presenting it in a more understandable form. Since people are used to the processing of visual inputs, visualization strives to present infor- mation in an aesthetically pleasing manner that is easy to understand. Good visualization seeks to be both expressive — present only the data and nothing more — and effective — be interpretable at a glance and quickly rendered. As a subfield of visualization, software visualization deals with presenting various aspects of software artifacts (such as source code or compiled binaries) through visual means. It helps programmers un- derstand the static structure of the source code as well as the dynamic behavior of the compiled program. Existing approaches to software visualization differ in many char- acteristics. The input data is generally obtained either through static analysis of a software artifact or collected during a particular execu- tion of the analyzed program. Some approaches also operate on a higher level of abstraction than others. They are more “aware” of the program. Figure 2.1 illustrates this concept. On the left is the htop program whose CPU1 meters measure the amount of computational work currently performed, on the right is an animation of sorting algo- rithms. While both visualize the execution of programs, the animation is more “aware” of what the program is doing. (a) The htop program. (b) An animation of sorts [1]. Figure 2.1: Visualizations with different levels of abstraction. 1. Central Processing Unit 2 2. Related Work The format of the resulting visualization is a differentiating factor as well. A software visualization tool might present 2D or 3D graph- ics, provide multiple views, or be in virtual reality (VR) [2, 3, 4]. A visualization can also be passive (once generated, it does not change), or interactive (allowing the user to change its parameters). A tool can implement a software visualization metaphor, which is a mapping between the analyzed program and an environment that should feel intuitive to the user. The rest of this chapter deals with several metaphors that are related to Helveg. However, software visualization is a broad field, and there are approaches besides those mentioned in this chapter. Hence, I recommend An Overview of 3D Software Visualization by Teyseyre et al. [5]. 2.1 Graphs and Diagrams While graphs and diagrams are abstract and usually lack a real-life metaphor, they are omnipresent and often underlie more “metaphori- cal” approaches. They are also an old method of software visualiza- tion predating computers themselves, for example, in a diagram by Ada Lovelace [6]. There are guidelines on how to draw diagrams of software. Chen’s Entity-Relationship Model (ER model) and the class diagrams of the Unified Modelling Language (UML) are among the more popular ones [7, 8]. Both focus on data modelling, but whereas the ER model is used in database design, the UML class diagrams play their role in object-oriented programming. Both are also frequently incorpo- rated into IDEs2. For instance, SQL Server Management Studio has its Database Designer, which displays diagrams similar to the ER model, Visual Studio has its Class Designer, and IntelliJ Idea has a UML plu- gin [9, 10, 11]. While the ER model and the UML class diagrams capture static structural information, other diagrams focus on the dynamic behavior of programs instead. For instance, the Flame Graph shown in Fig- ure 2.2 is a flame-like visualization of function calls and the time spent in them [12].