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
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 synchronize their states.
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
