On porting software visualization tools to the web

Software visualization tools are a great help as they can sum up large quantities of data in dense, meaningful pictures. Traditionally such tools come in the form of desktop applications. Modern web frameworks are about to change this status quo, as building software visualization tools as web applications can help in making them available to a larger audience in a collaborative setting. Such a migration comes with a number of promises, perils and technical implications that must be considered before starting any migration process.

The figure presents moving a project or focusing on a specific project using the three concepts that are fundamental to the philosophy of SPO: contextual menu see Figure 5. Multiple Perspectives. SPO provides multiple visual perspec- Interaction.

The visual perspectives are interactive in SPO, tives on a super-repository. The focus of each perspective meaning that every element of the view can be selected either can be either on the developers or on the projects in the sys- for navigation, or filtering. The right side of Figure 5 shows a tem.

Each perspective can present an overview of the entire pop-up menu that appears when the user interacts with indi- ecosystem or a detailed view on an individual element de- vidual elements in one of the visual perspectives of SPO. Once the user has Navigation is at the core of every information visualization selected one perspective, the central view labeled 2 displays tool, and this is the case also with SPO.

Initially SPO was de- a specific perspective on a super-repository. In this case it is signed to support navigation between the different perspec- a table that presents metrics about the projects in the super- tives on the system. However, as we were using the tool we repository. The view is interactive: The user can select and realized that one type of navigation it misses is vertical navi- filter the available projects, sort the displayed projects, obtain gation: navigating between views which present information contextual menus for the projects or navigate between various at different levels of abstraction.

One example would be, nav- perspectives. We already versity of Bern, in Switzerland. The perspective presents two had a tool that was supporting the visualization of software timelines displayed in parallel: the growth of the size top architecture at the individual system level. To support vertical graph and the fluctuation of the activity bottom graph. The navigation, SPO requests architectural views from Software- size is measured in number of classes while the activity is naut.

Softwarenaut, which runs in the background, can export measured in number of commits. The figure shows that size its output to SVG and deliver it to SPO to depict it in the user is monotonically increasing while the activity fluctuates over interface. Figure 6 presents an architectural view loaded in time with regularities and with a general trend being visible. The two user interface elements highlighted are: One of the regularities is the dip in activity towards the end of every year and in the summer.

This rhythm corresponds to the — The list of available architectural views presenting all views holiday periods of students. The general trend shows increase that are available for the given system.

In Figure 6 there in activity until the peak of January when there are are two views available: the one called main, and the one commits. After that date, the overall activity level seems to called main with tests. Currently two types of queries are available: Filtering. Given the sheer amount of information residing 1.

Queries that detect elements of the system that inter- in a super-repository, filters need to be applied to the super- act with the ecosystem.

For example, all the classes repository data. The panel labeled 3 in Figure 3 lists the ac- that have methods that are called from the ecosystem, tive filters. The or all the classes that are subclassed in the ecosystem. General architecture of a web-based software visualization tool.

Highlight Queries Fig. Visualizing in SPO an architectural view that was generated in Soft- warenaut. This module caches across sessions all the information that is needed in order to speed-up the view generation. SPO 5. The visualization module takes as input information from dot graph layouting 3 Analysis 5 6 the internal representation, analysis and cache modules Visualization Softwarenaut Metrics, Aggregation Layout Engine, and generates views from it.

The web portal is the user interface of SPO. The architecture of SPO. Queries that detect elements that were active at certain periods in the lifetime of the system. For example, all the classes that were active recently. We abstracted a general architecture for web-based 2. Dashed elements are optional components.

The import module is responsible for interfacing with the source code, bug report, mail archive, etc. Currently SPO supports two types of Therefore, they have an importer module 1 which retrieves super-repositories: one based on SVN and another one the data and stores it according to an internal representation based on Store, a Smalltalk-specific repository.

The data is then optionally processed to compute metrics 2. The internal representation is a meta-model [35] for rep- 3 about the considered aspects. The data is finally visual- resenting super-repositories and ecosystems. SPO supports ized by means of a visualization engine 4 : In case the engine the analysis of multiple models at the same time.

The analysis module is responsible with computing met- is used to create the web visualization. To improve the perfor- rics, discovering collaborations, analyzing developer and mances one can use a cache component 6 which avoids re- project vocabularies, aggregating dependencies, and all computing the visualizations. The software visualization tool the other types of analysis that are be performed on an has a web portal which displays the visualizations 7 , im- ecosystem model.

The cache module. Due to the highly interactive and ex- metrics A. Summary of promises and perils. Web-based software visualization tools might In this section, we recall our experience building Churrasco have access to sensitive information about a software system, and SPO and extract various aspects in the form of promises which should be accessible only by authorized people.

For and perils, summarized in Table 1. Promise 1 - Availability: Porting software visualization tools to the web makes them more available than desktop In Churrasco we tackled this problem by letting only reg- applications.

SPO does not implement authen- Many research prototypes have problems with respect to tication yet. As a result, when we approached an industrial their availability. Often such prototypes are hard to install be- partner for a case study on the ecosystem of the company, the cause of compatibility issues, missing libraries, missing doc- partner declined to import their data in the online version of umentation, etc.

Among the various reasons behind the avail- SPO. They installed a local version of SPO on their intranet ability problem, one is that researchers do not have the man- and performed the analysis themselves. Moreover, academic research is mostly publication- tools to the web eases the process of making them collab- driven, and not tool-driven, i. Tracking the evolution of systems and components re- Sharing the data among users naturally leads to collabo- quires further effort, as compatibility issues occur over time ration.

Virtually all software is nowadays built in a collabora- when new versions of components the tool depends on are tive fashion. This ranges from the usage of software config- released. Having the application running on a Web server uration management systems SCM supporting distributed means that the environment can be frozen, so that support- development, now widely used in practice [18], awareness ing the latest version of a component is not a priority.

Just as the software development teams are geographi- In the case of both Churrasco and SPO all that needs to be cally distributed, consultants and analysts are too. Analysis given to users is the url. Users collaborate by an- respect to performance see Section 4. This simple collaboration facility proved useful This peril can be tackled by having several instances of in the experiment we report on in Section 4.

Improving it via the web application running on several servers, with a web the addition of richer communication channels, such as chat server responsible of dispatching the requests and balancing or tagging, is easy to achieve in a web application. While this solution is standard Desktop applications can also support collaboration, but fare in web applications, for research prototypes such a hard- we argue that this is harder to implement. In this case, the ware infrastructure is often not available.

However, when in- various instances of the application need a communication frastructure is an issue, one can exploit cloud computing ser- channel among themselves directly in a peer-to-peer fashion vices which provide data replication and scalability transpar- or using a centralized server.

This leads to networking issues ently. Typical examples of cloud computing service providers due to firewalls. We are not aware of software visualization are Google, Amazon and Salesforce. Promise 3 - Incremental results: Web-based software vi- sualization tools ease the creation of an incrementally en- Peril 2 - Performance and Scalability: Collaborative, vi- riched body of knowledge on software systems.

Depend- a limited reusability. To maximize their reuse, analysis results ing on the number of users and the type of application, the should be incrementally and consistently stored back into the performance per user might decrease. This is especially true analyzed models. This would allow researchers to develop for visualization applications, where for large datasets both novel analyses that exploit the results of previous analyses, the computation time and the size of the data to be sent to the leading to a cross-fertilization of ideas and results.

Since the visualizations are ren- mately would also allow one to combine techniques targeting dered on the client side, bandwidth can become and issue. This to be sent, effectively trading CPU usage for increased band- is supported in Churrasco, and can be easily implemented in width. In that case the 2MB file was reduced to KB. In the context menu example, whenever the user Peril 3 - Single point of failure: Web-based applications clicks on a figure the page changes because a new figure ap- are single points of failure.

Refreshing the entire web page for every action Excessive centralization reduces the reliability of the ap- introduces latencies which make the web application slow plication. Web-based applications run on a server, and usually when it comes to rendering large SVG files.

One way to avoid have a unique instance of the application which all the users this problem is to use semantic zoom and details on demand access. As a consequence, if the application crashes it will to keep the rendered image small. Churrasco can focus on lock out all its users, i. Another possibility is to minimize the page re- has a private instance of the application, where a crash does freshes by using AJAX updates, which refresh only the changed not impact the other users.

This peril can be tackled, together part of the page, as Churrasco does. However, while the use with performance, by distributing the computation on several of AJAX has been simplified, it is still non-trivial. The current servers for redundancy. Concurrent usage is an issue in the context of collabora- Peril 4 - Debugging and testing: Debugging and testing tive work.

With Churrasco and SPO we performed two ex- web applications is hard. Moreover, the testing of a web-based is only fully functional with Firefox. However, not all the tools provide feedback about errors and failures. To test this, we wrote a If debugging a web application is more difficult than a simple Javascript program which calculates the rendering speed desktop one, being notified of bugs and deploying the fixes is of various browsers.

We ran the script in OS X on a Power- actually easier. Because of the restricted manpower available Book G4 running at 1. The dif- when developing them, research prototypes are far from be- ferences between the browsers are very large.

For example, ing mature and stable applications. Indeed, researchers do not in one second Opera 9. This simple benchmark shows two of ing their application. These problems impact the usage of the the greatest limitations of SVG: The amount of visual ele- tools and therefore their adoption by other researchers or peo- ments that one can render is limited at least currently and ple from industry. One way to be notified about these issues the user experience is hard to predict, as the timings will be is to instrument the tool so that if it crashes, it collects infor- different for users with different system configurations.

Also, mation about the run-time scenario and then asks the users we encountered problems with the same pop-up menu being to send this information back to the developers.

This widely rendered differently in two browsers. APIs such as Processing. Javascript in particular has seen By having the tool as a web service, the tool is always a resurgence of interest among web browser builders who running on the server, and therefore the tool developer can be now compete over their Javascript performance see Section 6 notified of all bugs and failures.

Bug fixes also do not need to for details about these issues. Finally, it is not unreasonable to require a widespread browser such as Firefox over Internet Explorer if the bene- fits of the application are promising enough. Promise 5 - Usage report: Web applications make it pos- sible to gather precise usage data.

Peril 6 - Interaction: Developing interactive web applica- tions is harder than desktop applications. Similarly to error notifications, gathering usage data is easy. With desktop applications it is possible to track the num- Supporting interaction through a web browser is a non- ber of downloads of a tool, and the tool might be instrumented trivial task, and even supposedly simple features, such as con- to send back feedback about how it is used.

This is however text menus, must be implemented from scratch. In Churrasco not straightforward to implement. Web-based applications of- context menus are implemented as SVG composite figures, fer the possibility to exploit standard solutions to the usage with callbacks attached, which are rendered on top of the statistics problem, such as Google analytics.

This allows de- SVG visualization. In SPO such menus are dynamically gen- velopers to easily gather usage statistics and infer popular erated by Javascript. It is hard to guarantee a responsive user features or usability problems, to continuously improve the interface, since every web application introduces a latency tool. As with bug fixes, deploying updates is transparent. However, libraries of reusable components are quickly Peril 5 - Browser compatibility: Web applications have developing, such as Prototype, script.

Javascript, which should alleviate this problem. We provide a more detailed discussion on this in Section 6. Web browsers are a rather diverse crowd, and the fact that a web application works with one browser does not guarantee Peril 7 - Rapid evolution: Web technologies are changing that it works with other browsers. While many compatibil- fast. In these cases the users The dust is far from settled in the web technology arena. Two examples of using external tools in Churrasco and SPO.

SPO also exposes the service of Softwarenaut [36], an ar- External tool Web based visualization application running on the server chitecture recovery tool whose visualizations where adapted Viz Conversion web-suitable viz Web Viz request to the Web. Moreover, SPO is processing huge amounts of 3 4 1 module interface data entire super repositories when there are no user con- Viz request 2 nected, i.

In this way, SPO is hiding heavy computations and presenting only the results as Fig. The general schema for using external tools in web-based visualiza- tion applications and hiding them behind the web interface. Churrasco does the same thing when, given the url of a SVN or Bugzilla repository, it sends an email to the user when the data is imported.

Figure 10 shows how the usage of external tools can be evolving: New possibilities are emerging, and the amount of generalized: The web interface gets the request for a visual- support among browsers varies.

This rapid evolution makes it ization and dispatches it to an external tool. Developers must be watchful of new opportunities and potentially capable to switch to newer tech- Promise 7 - Updating and maintaining: Updating a web- nologies when needed. We hope that, with time, standard so- based visualization application is easy since it is only done lutions will emerge for highly interactive, graphical web ap- once for all the users.

In our experience with developing visualization tools as desk- top applications, usually deploying a new version takes weeks or months, since one needs to put up a new release and then Promise 6 - Hiding tasks and exposing services: Web- inform all the users.

The updates can be done only ever easier. Implementing software visualization tools as web once on the server. This promise is one of the building blocks applications allows the developer to use external tools in the of promises 4 and 5, as they rely on the instant availability backend, hiding them from the users.

On the contrary, in desk- of updates. The associated risk is that defective updates will top applications external tools have to be included in the ap- also propagate instantly to all users; careful testing is needed. In short, the web application developer has ments that will bring more software visualization applications total control over the environment the application is execut- to the web in the future.

The use of external tools offers a lot of reuse opportuni- Promise 8 - Selective deployment and feedback: One ties, such as layout engines. For example, Churrasco reuses can selectively deploy changes to a group of users and two external tools Mondrian [42] and the Evolution Radar measure their effect. Web applications being easier to update and providing This enables us to freely reuse all the visualizations and lay- feedback allows one to measure the effects of changes on the outs provided by Mondrian and the Evolution Radar.

SPO is users. Assuming an application has a steady amount of users, dispatching the layouting of its visualizations to Dot, a Unix and gathers usage statistics about how the users are using it, command line layout algorithm library see Figure 9 b. The participants were: 5 master students, 2 doctoral stu- the second group uses the application without the change. The Master students were lectured on reverse engineering to Promise 7, makes this possible.

The monitoring can be as fine-grained as needed i. If the monitoring tem Complexity and Correlation View and looking at the already in place is insufficient, it can be deployed as an- source code to 1 discover classes on which one would focus other update as well and removed later on if it proves reengineering efforts explaining why , and to 2 discover to be detrimental to performance, such as if it increases classes with a big change impact.

The target system chosen communications between clients and the server beyond for the experiment was JMol, a 3D viewer for chemical struc- what is expected. ACM Trans. Finnigan P. IBM Syst J 36 4 , — Froehlich, J. Frost R. IEEE Software 24 6 , — Gall, H. Greevy, O. ACM, New York Holten D. Comput Graph 12 5 , — Jazayeri, M. Kazman, R. Kersten, M.

Knodel, J. Kuhn, A. Lanza M. Lanza, M. Likert R. Arch Psychol 22 , 1—55 Lintern, R. Lungu, M. Lungu M. Mancoridis, S. Marcus, A. IEEE, Portland Meyer, M. PhD thesis, Rice University, Houston Nentwich C. Softw Pract Exp 30 15 , —