5.4 Case Study Validation
5.4.2 Method-Level Disharmonies
To visualize method-level disharmonies, we use the fine-grained representation. Due to the fact that looking at entire systems using this granularity is impractical (i.e., too many depicted entities), we focus on specific parts of the systems.
Feature Envy in Jmol
After visualizing the method level disharmonies of Jmol using a fine-grained representation, we noticed that the Feature Envy design problem is by far the dominant design problem in Jmol. Figure 5.8 shows the Feature Envy disharmony map of the system using the Progressive
Bricksadaptive layout. The methods affected by this problem are colored in yellow, while the
unaffected methods are gray. The disharmony maps transmits the viewer the fact that this problem is rather severe in this system. Indeed, more than one quarter of Jmol’s methods (e.g., 1,555 out of 5,968) exhibit the Feature Envy disharmony.
Figure 5.8. Yellow-colored Feature Envy in Jmol
Our visualization depicts the Feature Envy “epidemic” in a suggestive way and the picture says it all: the system could benefit from a serious session of reengineering.
Shotgun Surgery in ArgoUML
Figure 5.9 shows a visualization of package modelin ArgoUML. This package, which was sub- ject to discussions also during the class-level analysis, contains in this representation the two most massive buildings in the city of ArgoUML (i.e., depicting the classes or interfaces with the highest number of methods), representing the interface Facadeand the only class that it, i.e.,model.mdr.FacadeMDRImpl.
FacadeMDRImpl uml.model.mdr NOMSS: 0 NOM: 349 Facade uml.model NOMSS: 140 NOM: 337 Model uml.model NOMSS: 31 NOM: 54 PseudostateKind uml.model NOMSS: 7 NOM: 7 VisibilityKind uml.model NOMSS: 4 NOM: 4 AggregationKind uml.model NOMSS: 3 NOM: 3
Figure 5.9. Red-colored Shotgun Surgery in themodeldistrict of ArgoUML
The dominating design disharmony characterizing this package is by far Shotgun Surgery, depicted by the many buildings “tainted” with the dark red color. Moreover, we see that most of the dark red “bricks” belong to only a reduced set of classes. The largest building affected by this disharmony is theFacadeinterface. In contrast to the class-level disharmonies discovered in this package, the method-level disharmonies are detected on the interface and not on the classes implementing it, due to the fact that the calls are done using polymorphism, i.e., they target references to the interface.
Of the 337 methods defined inFacade, 140 exhibit the Shotgun Surgery disharmony, as it is shown by the Number of Methods with Shotgun Surgery (NOMSS) metric. Apart from the Facadeinterface, there is another interface calledModelwhich has many methods affected by Shotgun Surgery (31 out of 54) and three small classes made entirely of methods with Shotgun Surgery: AggregationKind(with 3), VisibilityKind(with 4), andPseudostateKind (with 7), respectively.
This disharmony is somewhat expected in this package, since it is part of the system’s model and all the other modules depend on it. A class with an increased number of methods affected by
Shotgun Surgeryis fairly difficult to change, since any change is likely to require many changes throughout the system.
5.5
Related Work
Among the approaches based on a city metaphor, only two addressed the visualization of design anomalies.
Panas et al. describe a visualization which shows a city with buildings in flames, obtained using their city metaphor, enriched with the Lack of Documentation (LOD) metric on fire textures [PEQ+07]. However, the design problems we illustrate are much more complex than such simple
metrics. We consider the approach of Panas et al. more related to the program comprehension application of the city metaphor, where we also mapped simple metrics on the city’s visual properties.
The second approach is the one of Langelier et al., who addressed the problem of detecting design principle violations or anti-patterns by visually correlating outlying properties of the rep- resentations, e.g., a twisted and tall box represents a class for which the two mapped metrics have an extremely high value[LSP05]. There are several drawbacks of this approach in compar- ison to ours. First, the approach is prone to both false positives (e.g., classes which may seem good candidates for God Class or Brain Class due to their magnitude, but they are not, as seen in Section 5.4) and false negatives (i.e., classes delude through their apparently insignificant size, but in reality suffer from design problems typically found in very large classes). We have seen how the availability of precise design problem data removes the uncertainty and helps focusing on the parts of the city that are actually affected by such problems. The second problem with the approach of Langelier et al. is that for each anomaly one needs to map a different sets of metrics, because the number of metrics needed for the detection oftentimes exceeds the mapping limit of the representation (i.e., three visual properties: height, twist, and color). By using only one of the visual properties (i.e., color), we provide an overview of several design problems and, at the same time, allow the user to complement the mapping with other software metrics that may contribute to obtaining interesting insights, such as the ones we presented in the case studies.
To our best knowledge, all the previous work depicts software artifacts in terms of such low- level metrics and does not address the visual representation of such high-level design problems. To enable an efficient visualization of a system’s design problems, we drew inspiration from disease maps and built on top of the previous techniques revolving around our city metaphor a technique called disharmony maps.
However, a key part of the success of applying the city metaphor to design quality assessment is owed to the detection strategies that we relied on for computing the precise design data we have access to in our approach. The detection strategies[Mar04a] were introduced by Marinescu as a mechanism to formulate complex rules using the composition of metrics-based filters, and extended later by Lanza and Marinescu [LM06] by formalizing the detection strategies and providing solutions for recovering from detected problems. The 2D polymetric views provided as means to visualize the systems do not explicitly illustrate the disharmonious artifacts, nor do they provide an overview and distribution of the disharmonies within the observed systems. In the context of detection strategies, Ra¸tiu et al. aimed at further improving the design flaw detection by taking into account information from the history of the candidate classes to compute their persistency in exhibiting a particular design flaw during their lifetime[RDGM04].
5.6
Summary
The third application context for our city metaphor was design quality assessment. We presented a novel visualization called disharmony map, which is a code city whose color denotes the spread and distribution of design problems. By integrating the design problem data obtained by running detection strategies on software systems with the city metaphor, we obtain a visual approach able to provide an overview from the perspective of the quality of the system’s design. This third extension of the city metaphor supports the claim of our thesis related to the versatility of our city metaphor.
We validated this third application of our city metaphor by means of several case studies. Us- ing our approach, we learned about false appearances (e.g., small classes suffering from design problems that are typical for large classes), we saw how a bad organization of the package struc- ture is accompanied by many disharmonies of its classes and how disharmonies can conquer a system in the absence of reengineering. All these insights are indications of another useful application of our city metaphor.
We believe that, with the three applications of our city metaphor, we demonstrated the first claim of our thesis, which refers to the versatility of the city metaphor for software visualization. The second part, which is yet to be proven, refers to the efficiency of the approach.
However, both the application of the city metaphor in different contexts and the empirical validation of our approach—presented later in this thesis—strongly rely on the tool support presented in Chapter 6.
Tool Support
To support our approach we implemented a software visualization tool called CodeCity, with an essential role in both demonstrating the versatility of our metaphor for reverse engineering, by enabling us to apply our approach on real software systems, and supporting our empirical evaluation aimed at proving the efficiency of our approach.
Figure 6.1. CodeCity’s main window
CodeCity is a sovereign visualization tool, i.e., an application that tends to occupy the entire screen estate[CR03]. Its user interface, presented in Figure 6.1, is composed of three panels:
• main panel (left), which enables visualizing, interacting with, and navigating code cities, • information panel (top right), which shows contextual data on the inspected artifacts, and • structure panel (bottom right), which shows the system’s structure in a tree view.
6.1
The Process of Visualizing Software Systems as Cities
Visualizing software systems as code cities requires three steps:
1. Extracting the model. It is believed that the use of frameworks as underlying technology for software tools leads to faster tool innovation, as less time is spent on reinventing the wheel[Sto06]. CodeCity is implemented in Smalltalk and built on top of Moose1, a reengineering platform whose energetic community has produced over 150 publications in its fourteen years of existence[NDG05, DGKR09].
Moose provides an implementation of both the language-independent FAMIX[DTD01] meta-model, which is able to model software systems, regardless of the programming lan- guages they have been written in (currently, it supports Java, Smalltalk, C++, and C#) and an implementation of a meta-model for history, called Hismo[Gîr05]. In Hismo, a history is a sequence of versions of the same kind of entity (e.g., class history, package history, etc.), where a version is a snapshot of an entity at a certain point in time. By building on top of the Moose technology, we get access to large amounts of rich, struc- tured information—including a extensive set of software metrics—contained in the FAMIX models of software systems.
The model extraction step implies parsing the software system’s source code to produce a FAMIX model of the system. Depending on the programming language that the sys- tem is written in, we use different tools to parse the system: For Smalltalk, we use the parsing technology implemented in Moose. For Java and C++ systems, we use iPlasma [MMM+05], an analysis platform courtesy of the Loose Research Group2. For C# systems
we use the PMCS (i.e., Parsing and Modeling C# Systems) tool[Dak09].
Both external tools, i.e., iPlasma and PMCS allow exporting the FAMIX model using the MSE3 exchange format. After importing the FAMIX models, CodeCity handles software systems uniformly, unconstrained by programming language boundaries. Moreover, if the models represent different versions of the same system, they can be merged in a model of the system’s history.
2. Building the visualization model. Based on a FAMIX model of a software system, CodeCity builds a visual model of the software system, according to the user’s preferences, in terms of property mapping strategies, layouts, granularity of the representation.
3. Rendering the code city. We built our rendering layer on top of the Jun graphics library [AHK+01], which enables us to render, using OpenGL4technology, the visual model of the
software system as an interactive code city visualization.
1http://www.moosetechnology.org 2http://loose.upt.ro/iplasma
3http://scg.unibe.ch/wiki/projects/fame/mse 4http://www.opengl.org