CodeCrawler – An Information Visualization Tool for Program Comprehension
By Michele Lanza, Stephane Ducasse, Harald Gall, Martin Pinzger
The paper introduces an information visualization tool called CodeCrawler that can be used for program comprehension and problem detection. CodeCrawler takes a lightweight approach and built with Smalltalk on top of Moose – a language-independent reengineering environment. Moose implements FAMIX, a metamodel suitable for modeling programs, especially ones written in object oriented languages. It uses Hotdraw to generate 2D visualizations. Furthermore, it has a three layered architecture style- the core, the metamodel, and a visualization engine. The authors emphasize on Polymetric view, which involves representing entities as nodes and relationships as edges to describe the semantics of a program. Metrics such as no. of methods, attributes are assigned to each node to correlate with height, width, color and co-ordinate positions of the nodes. The authors applied CodeCrawler on itself to obtain a system complexity view using node width for no. of attributes, height for no. of methods, and color for LOC. They also analyzed separately on three categorical views: Coarse-Grained View to inspect system hotspots and suitable for large systems; the Fine-Grained View to inspect various aspects such as class blueprint, relationships between entities; and lastly the evolutionary view, to inspect evolution of software. Additionally they analyze Coupling View to see the difference in software between releases. With CodeCrawler the difference is not easily graspable so a difference graph is constructed.
Program Comprehension through Software Habitability
By Richard Wettel and Michele Lanza
Visualization can help developers to comprehend large software programs by detection of patterns. 2D visualization is widespread in this regard; they provide easy navigation, interaction and construction of visualizations but lack a sense of physical space. On the other hand, 3D representation would in turn make navigation and interaction harder to achieve. The authors argue the prospect of using 3D to induce a sense of software enhanced reality which will enable developers to walk through a program, as if they are in a physical entity akin to real world, like being at home. They stretch the notion by emphasizing on the underestimated concept of Habitability applying locality to a virtual space using the City Metaphor. Code City is a program that can be used to visualize a program as a city with suitable level of interaction. It is applied to visualize two software products: ArgoUML and Azureus. Classes and interfaces are depicted as buildings so that their height map to no. of methods, width to no. of attributes and such. The conventional linear view uses real metric values to depict the city but it seldom creates unrealistic view with extreme figures, thus reducing habitability. On the other hand, Box-plotting based and Threshold-based mapping are used to depict a more realistic view and upon selecting types of buildings in the model provides real metrics. The authors conclude that to induce sense of Habitability, box-plotting and threshold based model generation is more suitable. Some related tools are analyzed too, and the authors consider implementing a landscape view in the future in addition to the city view.
Below are 3 strong points about the research in my opinion-
1. The decision to visualize Object Oriented Programs/methodology is a strong point because it conforms to the current trend in software industry. It is a good thing that Moose supports Java, C++ and Python.
2. Representing a software program with real world metaphor, aided with the concept of Habitability and Locality is a good initiative to help engineers understand large software systems better.
3. Comparing to other works in this area, Code City as a tool uses classes or interfaces as references to buildings, both of which can be seen as somewhat atomic structures in two different worlds. While other tools used methods as buildings or classes as whole districts, the level of granularity used for code city seems well suited.
With due respect to authors, here are several weaknesses that may be considered-
1. LOC for both ArgoUML and Azureus seems too less, in accordance of present day assumption of LOC for a large software system.
2. Why Code City is a better alternative to UML is not clear. UML is a widely supported and used standard to visualize software programs. While Code City is limited to understanding only, UML can be used for all stages of a software project for the purpose of visualization.
3. As the authors mentioned, lower level representation is needed to improve Code City.