Visualization of Object-Oriented Variability Implementations as Cities

Abstract

Many large software systems are variability-rich, object-oriented, and implemented in a single code base. They then rely on multiple traditional techniques (inheritance, patterns) to realize variability, making these implementations not explicit. This directly hampers the comprehension of variability implementations, especially for newcomers in a project that need, in a short time, to understand the most important parts. In this paper, we propose VariCity, a visualization using the city metaphor to exhibit zones of interest, being zones of high density of variability implementations. The different forms of variability implementations are first detected through the usage of symmetries in code (e.g., inheritance defines a substitution symmetry between the immutable part of the superclass and the possible changes in its subclasses). VariCity then creates a 3D city representation with buildings being classes while the metrics on the number of symmetries (e.g., the number of overloaded methods, influence the building size, and their color if they are heavily loaded in symmetries). Contrary to the usual packagebased organization in code-related city representations, the city streets are arranged according to the usage relationships between classes. Inheritance is simply represented with hoverable aerial links. Variability-related design patterns are depicted as buildings with specific geometric forms, while some classes specified as entry points can help in shaping the whole city organization. We also report on the evaluation of VariCity on a set of large objectoriented systems, showing that several usage scenarios helping a newcomer to spot critical variability-related zones are covered.

Visualization of object-oriented software in a city metaphor: Comprehending the implemented variability and its technical debt

“…While a feature model could be generated from the symfinder output, we believe it would not be as useful as a visualization related to the codebase itself. However, some additional work has demonstrated that the detected variability can be mapped to a domain feature model with an average precision 1 and a good recall [24,25]. The graph representation was also extended so that the mapped feature can be read while hovering on the different nodes representing the implementation classes.…”

“…The identification of such implementations can then be exploited in different ways, from the maintenance of the variable system to some variability reengineering [22] or a migration to a full software product lines [23]. For example, the result of the underlying detection used in our solution (i.e., symfinder ) has been successfully mapped to a domain feature model in two different variable systems [24,25]. However, we only focus in this article on a visualization adapted to the identification of the OO implemented variabilities to facilitate variability comprehension of large OO systems.…”

IDE-assisted visualization of indebted OO variability implementations

“…In particular, CodeCity [17] and Evo-Streets [11] rely on the city metaphor to represent quality metrics on classes of an OO system. VariCity adapts the city metaphor to exhibit density of variability implementations [6] (cf. fig.…”

“…The visualization provided by VariCity shows multiple improvements compared to the graph visualization of symfinder-2. Using a navigable 3D representation of a city where the buildings exhibit the different variability metrics and are grouped by usage allows to better grasp the organization of the classes [6]. Inheritance and additional usage relationships are displayed on hover not to overload the visualization.…”

“…Dense zones of detected symmetries have also be shown to represent interesting locations in terms of variability implementations. As identification is quite cumbersome on large systems [9] the VariCity visualization, based on the city metaphor, was proposed and validated on large Java variability-rich systems [6]. While this helps architects and developers understand the implemented variability, no support was given to ease the browsing between the code and this visualization.…”