Análisis de Liquidez

From our experience with the users of CodeCity we have evidence that learning the language of the metaphor is fairly easy. Adopting the simple conventions allows the users to look at, and reason about, software in a different way than the traditional one (i.e., source code and UML diagrams). There is a genuine curiosity most people manifest when they first see a visualization of CodeCity: “I would really like to see my system visualized as a code city”.

After discussing our approach with different developers, we realized that the slow pace of tool adoption in industry is not caused by the people, but rather by the organizations: Most of the practitioners we discussed with were quite enthusiastic about our approach and some of them were looking forward to using CodeCity to complement their working activities.

Moreover, the feedback we received from CodeCity users is encouraging. An experienced industry practitioner shared with us his experience with CodeCity: “[. . .] I loaded my music composition application into CodeCity. See the attached picture. Interestingly, the resulting image looks like expected. To a large extent, it matches the image I always had in my head.[. . .] It feels rewarding and satisfying to see a beautiful visualization of the work that took so many years to accomplish.” The fact that our approach produced a visualization of a software system which matched the developer’s mental model is a valuable insight.

We strived to build a highly configurable and flexible tool, which would allow us to extend it to unforeseen directions. This touches again the topic of research intertwined with tool building. Had we built a badly designed tool or had we not invested the time and effort into the design and implementation of the tool, we would have not been able to extend the metaphor’s imple- mentation so easily. Moreover, the language-independent meta-model that we rely on allowed us to apply our approach on systems written in different programming languages and opened a larger user base for CodeCity.

We invested significant time to make CodeCity robust, to optimize it for scalability, and to take it beyond the “research prototype” status. The robustness, scalability, and usability of the tool were all important for both the outcome of the experiment and for allowing us to chose from a large number of case studies.

The availability of the tool allowed industry practitioners to try CodeCity out before enrolling as subjects in the experiment. After experimenting with CodeCity, many of them believed that it could help them in their daily work and this was enough motivation for them to want to learn how to use it.

9.2

Contributions

After demonstrating our thesis, we reflect on the contributions of the work presented in this dissertation:

The definition of a versatile city metaphor for software visualization. We defined an initial metaphor for program comprehension and iteratively enriched it to support two new ap- plications, i.e., software evolution analysis and design quality assessment. With a similar amount of effort as the one we invested for each new application, we believe we could further extend our city metaphor to other facets of software.

The application of the city metaphor to program comprehension. We first applied our approach based on the city metaphor in the context of program comprehension and ob- tained a rough “big picture” of our case study system. Moreover, our approach allowed us to detect a number of system hotspots. We used these outliers as starting points for more in-depth analyses that led us to interesting insights about the system.

The application of the city metaphor to software evolution. We described three visualization techniques we devised for the software evolution applications. The visualizations enabled us to acquire valuable insight about the system unattainable outside the evolutionary con- text and complementary to the insights gained in the context of program comprehension. For this application, we consulted the developers of the case study systems, who confirmed our findings.

The application of the city metaphor to design quality assessment. We described a software visualization technique inspired from disease maps, called disharmony map. Disharmony maps enabled us to focus on the design problems, while maintaining the general con- text, i.e., the overview of the system. Due to the precise information obtained by using detection strategies, our approach is less prone to false positive and false negatives than traditional visualization approaches, which rely on spotting outliers in terms of simple software metrics.

The implementation of a tool which supports our city metaphor. We implemented CodeCity, a tool that supports all three applications of our city metaphor. The effort we invested into the design and implementation of the tool payed off from several perspectives: it demon- strated the value of our approach, it allowed us to confidently perform an experiment in front of experimented industry practitioners and academics, and it enabled us to illus- trate our applications by means of case studies. Moreover, the scalability of CodeCity, and implicitly of our approach, allowed us to visualize large software systems of up to three million lines of code.

The empirical validation of our approach through a replicable controlled experiment. Although our intention has been to empirically evaluate our city metaphor in all three application contexts, we only managed to evaluate two, i.e., program comprehension and software design quality assessment. For reasons described in Section 7.4.2, we dropped the evaluation of the software evolution analysis application context. However, we conducted an extensive experiment, which spanned over six months of time. We were able to engage large samples of our target population, which covered both academia and industry, and included both beginner and advanced participants. The design of our experiment, which followed a set of guidelines extracted from the body of literature, enabled us to collect rich data, which allowed us to perform a number of interesting analyses. The most important results of our controlled experiment was that our approach outperformed in terms of both correctness of the solution and task completion time the state-of-the-practice. The result is statistically significant. Moreover, by providing the entire experimental data set, we ensured the replicability of our experiment.