Table of Links
II. Approach
B. Proof of Concept Implementation
III. Envisioned Usage Scenarios
IV. Experiment Design and Demographics
VII. Conclusions and Future Work, Acknowledgment, and References
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.
Authors:
(1) Alexander Krause-Glau, Software Engineering Group, Kiel University, Kiel, Germany ([email protected]);
(2) Wilhelm Hasselbring, Software Engineering Group, Kiel University, Kiel, Germany ([email protected]).
This paper is
