Ever Seen Your Code as a City? | HackerNoon

Table of Links

Abstract and I. Introduction

II. Approach

A. Architectural Design

B. Proof of Concept Implementation

III. Envisioned Usage Scenarios

IV. Experiment Design and Demographics

A. Participants

B. Target System and Task

C. Procedure

V. Results and Discussion

VI. Related Work

VII. Conclusions and Future Work, Acknowledgment, and References

Abstract—Software visualizations are usually realized as standalone and isolated tools that use embedded code viewers within the visualization. In the context of program comprehension, only few approaches integrate visualizations into code editors, such as integrated development environments. This is surprising since professional developers consider reading source code as one of the most important ways to understand software, therefore spend a lot of time with code editors.

In this paper, we introduce the design and proof-of-concept implementation for a software visualization approach that can be embedded into code editors. Our contribution differs from related work in that we use dynamic analysis of a software system’s runtime behavior. Additionally, we incorporate distributed tracing. This enables developers to understand how, for example, the currently handled source code behaves as a fully deployed, distributed software system. Our visualization approach enhances common remote pair programming tools and is collaboratively usable by employing shared code cities. As a result, user interactions are synchronized between code editor and visualization, as well as broadcasted to collaborators.

To the best of our knowledge, this is the first approach that combines code editors with collaboratively usable code cities. Therefore, we conducted a user study to collect first-time feedback regarding the perceived usefulness and perceived usability of our approach. We additionally collected logging information to provide more data regarding time spent in code cities that are embedded in code editors. Seven teams with two students each participated in that study. The results show that the majority of participants find our approach useful and would employ it for their own use. We provide each participant’s video recording, raw results, and all steps to reproduce our experiment as supplementary package. Furthermore, a live demo of our tool is available online.1 We invite other researchers to extend our opensource software.2 Video URL: https://youtu.be/3qZVSehnEug

Index Terms—software visualization, dynamic analysis, program comprehension, pair programming, integrated development environment

I. INTRODUCTION

Source code comprehension is still the primary method to come to an understanding of a software system’s behavior [1]. This is not unexpected, because developers are trained to recognize recurring patterns and resulting behavior in source code. They even might spend most of their development time in integrated development environments (IDE) [2]. However, navigation in IDEs leads to a redundant but unavoidable overhead [3] and in terms of software visualization (SV) developers are concerned about the context switch caused by standalone SV tools [4]. As a result, code proximity is a necessary property for SV [5], [6] to succeed in its intended area, i.e., professional software development. Code proximity means the ability of the visualization tool to provide easy and fast access to the original, underlying source code [7]. In this context, research approaches have been shown in the past that embed SV into code editors and IDEs (both from now on referred to as code editor) to link source code with its visualization [8]–[11].

In this paper, we introduce our collaboratively usable SV approach that can be embedded in code editors. In comparison to related approaches, we use dynamic analysis as source for rendering three-dimensional code cities [12], [13]. The SV is linked directly to the source code that is under development within the code editor and vice versa. Therefore, we directly connect runtime behavior with the related program elements, for example, Java methods. User interactions are synchronized between code editor and visualization, as well as broadcasted to collaborators. As proof of concept, we implemented a Visual Studio Code3 (VS Code) extension that realizes our design. We conducted a first-time user study to collect feedback regarding the perceived usefulness and perceived usability of our approach. Furthermore, we collected logging information to provide more data regarding usage statistics of SV that are embedded into code editors. In this study, seven teams with two students each collaboratively used our approach in an onboarding-related scenario. Overall, the results show a highly rated usefulness.

The remainder of this paper is structured as follows. Section II presents the architectural overview and proof of concept implementation for our approach. We proceed by

introducing the envisioned usage scenarios for our approach in Section III. Afterwards, Section IV explains our experimental setup. Section V presents and discusses the results of our study. Then, Section VI introduces related work. Finally, we conclude this paper and present future work in Section VII.

II. APPROACH

In this section, we present the architectural design and proof of concept implementation for this research work. For that, we build upon our previously published approach named Software Visualization as a Service (SVaaS), i.e., providing an onlineaccessible and on-demand service for collaborative program comprehension using SV. Due to space constraints, we refer readers to [14] for a description of the basic concepts of our approach.

A. Architectural Design

Figure 1 shows (a simplified overview of) our approach’s architectural design. It is technology independent with the exception of a browser-based SV component. As shown, it is divided into four stages (blue-striped areas). Figure 1-A and Figure 1-B depict the monitoring and analysis stages, respectively. These are the foundation of our SVaaS concept. The analysis pipeline for example can be horizontally scaled out to handle varying load of concurrent users, therefore positively influence the effectiveness of the overall tool [15]. Although data acquisition, analysis, and cloud technologies are important aspects of our concept, a detailed explanation is beyond the scope of this paper. Therefore, we refer readers to [14] for details and focus on the remaining two stages.

The Webserver (Figure 1-C) serves the static files that comprise the web-based SV, i.e., CSS, JavaScript, and HTML. Furthermore, it acts as reverse proxy for clients to connect to the backend services, e.g., to obtain data to be visualized. Users now have two options to link the SV with their code editor:

• For the first option, they can use the standalone SV that runs inside of their web browser and connects to an extension in their code editor (Figure 1-D). The latter acts as gateway between code editor and SV. This is similar to the ‘classic’ approach for code viewers embedded into SVs and relates to many other works (see Section VI). Interactions that should be linked between code editor and SV, e.g., ‘open a class file in the code editor when the related visualization entity was clicked’, are synchronized by the Code Editor Service (Figure 1-E).

• For the second option, users can install an extension in their code editor that already includes the Frontend (Figure 1-F). In this case, we do not need an external service to synchronize interaction events, but use a built-in communication mechanism between code editor and its extension. Therefore, we reduce the context switch overhead that occurs when switching from SV to code editor and vice versa [4]. Another advantage of the second option is that it can also be installed in cloud-based code editors that run in browsers. This can be beneficial in some use cases, e.g., onboarding of new developers, as shown in Section III.

Regardless of the selected option, users can collaboratively use the SV. To achieve this, the Collaboration Service (Figure 1-G) broadcasts events, e.g., ‘user X opened package Y’, to all clients of the same session except the one that triggered an event [16]. The clients then apply the received events to their SV, therefore synchronizing their states.

B. Proof of Concept Implementation

We have prototyped our approach within our SV tool ExplorViz.4 Our tool’s development commenced in 2012 [17] and focused on several aspects throughout time, such as development concerns [18], [19] and extended reality [16], [20]. More recently, we use ExplorViz to research collaborative software visualization in the context of program comprehension [16], [21]. ExplorViz currently uses dynamic analysis as source for the visualization. Our depicted SV is configured to visualize the aggregated runtime behavior of ten seconds [14].

Figure 2 shows a screenshot of our prototype implementation. We developed a VS Code extension that realizes the previously mentioned design. It can be used as gateway to link the external SV to the code editor or provide the embedded SV instead. Due to space constraints, we focus on the latter and refer readers to our supplementary video. The extension uses an HTML iFrame to embed the web-based Frontend, therefore SV, in VS Code (see Figure 1-F on the previous page). The embedded SV can be switched on or off via the ExplorViz logo button (Figure 2-A). It is automatically placed in a new editor group next to the source code (Figure 2- B). Users can select one of their (currently or previously) analyzed software systems (as shown in the supplementary video) and open the related SV. The latter is provided as three-dimensional code cities using Three.js5 for rendering (Figure 2-C). The embedded Frontend uses cross-origin communication based on the JavaScript Window object to interact with VS Code. Therefore, we do not need an external service that synchronizes the interaction events as it is the case when using the external Frontend or as shown in related works (see Section VI). Every tenth second the Frontend triggers a SV update. For that, it obtains the latest runtime data for the selected software system from the analysis pipeline and updates the visualization if required. Furthermore, the Frontend sends new data to VS Code, which then highlights Java classes and methods that have been used in the aggregated runtime behavior. This is shown by the gutter icons and code lenses in Figure 2-D. Users can click on a code lens to focus the related entity in the SV, e.g., a high-rise building visualizing a Java class. Vice versa, pressing for example on a communication line will cause the file to open and focus on the related method in VS Code. In terms of working together, users can join or host a collaborative session from within the embedded Frontend and use the collaborative features of the SV, e.g., pinging or shared popups (Figure 2-E), to interact with each other (please see [16] for more details). Furthermore, a collaborative session also enables remote pair programming. For VS Code in general, developers can for example use Microsoft’s LiveShare extension for VS Code. LiveShare has great features and usability, but uses Microsoft servers that might be not available in the future or cannot be used due to compliance concerns. For the sake of our evaluation’s reproducibility, we therefore decided against using an available product such as Microsoft’s LiveShare, but developed our own solution (for the user study). This can be seen in Figure 2- F where the live text selection of another user is depicted (as yellow background of OwnerRepository). These text selection events are synchronized by an implementation of the external Code Editor Service (Figure 1-E) using WebSockets for almost real-time communication.