Johann Mortara
email: johann.mortara@univ-cotedazur.fr

Philippe Collet
email: philippe.collet@univ-cotedazur.fr

Anne-Marie Dery-Pinna
email: anne-marie.pinna@univ-cotedazur.fr

Visualization of Object-Oriented Variability Implementations as Cities

Keywords: variability, software visualization, software cities 10

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.

I. INTRODUCTION

Recent software-intensive systems of all scales and domains are more and more variability-intensive [START_REF] Hilliard | On representing variation[END_REF]- [START_REF] Galster | Variability-intensive software systems: Product lines and beyond[END_REF]. Software variability is usually defined as the ability of a software artifact (i.e., system or element that enables to develop it) to be efficiently extended, changed, customized, or configured towards a specific context [START_REF] Capilla | Systems and software variability management[END_REF]. Being a key element of most systems [START_REF] Hilliard | On representing variation[END_REF], variability management has been heavily studied, notably leading to the Software Product Line (SPL) paradigm [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF], [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF] Within an SPL, there is a clear separation between the domain variability, commonly documented and managed in terms of features (often organized in a feature model [START_REF] Kang | Feature-oriented domain analysis (FODA) feasibility study[END_REF]), and the implemented variability, that is mapped from the domain variability, usually using a single implementation technique such as preprocessor directives [START_REF] Liebig | An analysis of the variability in forty preprocessor-based software product lines[END_REF] or a form of modules [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF]. Sometimes the implemented variability is also managed as a feature model [START_REF] Schmid | A customizable approach to full lifecycle variability management[END_REF], [START_REF] Metzger | Disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis[END_REF], but the main benefits of an SPL is to reason on consistency at the domain level and from a configuration, to derive a consistent software product.

However, many variability-rich software systems are not following a complete SPL approach. Many of them are objectoriented and implemented in a single codebase in which variability among the obtainable software products is implemented using traditional techniques (i.e., inheritance, parameters, overloading, and some design patterns such as strategy and factory) [START_REF] Capilla | Systems and software variability management[END_REF], [START_REF] Gacek | Implementing product line variabilities[END_REF], [START_REF] Svahnberg | A taxonomy of variability realization techniques[END_REF]. The implemented variability in code assets is neither explicit nor documented, which hinders its management, but more basically, hampers the simple comprehension of it. As features to be understood are not known in advance, and the code is not cloned and modified per product, none of the feature location techniques [START_REF] Dit | Feature location in source code: A taxonomy and survey[END_REF]- [START_REF] Michelon | A hybrid feature location technique for re-engineeringsingle systems into software product lines[END_REF] can be applied in this context.

Facing this comprehension problem in identifying variability implementations, we advocate that it demands a visualization based solution. Software visualization is a research area that focuses on methods and techniques for graphically representing the many facets of software [START_REF] Domingue | Software visualization: Programming as a multimedia experience[END_REF]- [START_REF] Diehl | Software visualization: visualizing the structure, behaviour, and evolution of software[END_REF]. In more than two decades, many visualization approaches have been proposed to support a diversity of software engineering activities, such as maintenance, evolution, reverse engineering [START_REF] Koschke | Software visualization in software maintenance, reverse engineering, and re-engineering: a research survey[END_REF], and more generally software comprehension and analysis [START_REF] Storey | On the use of visualization to support awareness of human activities in software development: a survey and a framework[END_REF], [START_REF] Teyseyre | An overview of 3D software visualization[END_REF]. In the variability management field, visual representations most entirely focus on the domain variability and feature models [START_REF] Lopez-Herrejon | A systematic mapping study of information visualization for software product line engineering[END_REF]. When a visualization related to implementation is provided, it is only dedicated to the validation of a detection approach and not really adapted [START_REF] Xh | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF], [START_REF] Mortara | Mapping Features to Automatically Identified Object-Oriented Variability Implementations -The case of ArgoUML-SPL[END_REF].

In this paper, we propose VariCity, a visualization using the city metaphor [START_REF] Wettel | Visualizing software systems as cities[END_REF] to exhibit zones of interest, being zones of high density of variability implementations. As the city metaphor has been shown to scale on large projects for visualizing metrics related to software quality [START_REF] Pfahler | Visualizing Evolving Software Cities[END_REF]- [START_REF] Wettel | CodeCity: 3D visualization of large-scale software[END_REF], we adapt it to our identification problem.

Reusing a recent approach [START_REF] Xh | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF], different forms of variability implementations are first detected through the usage of symmetries in code [START_REF] Zhao | Understanding symmetry in object-oriented languages[END_REF], [START_REF] Coplien | Toward a general formal foundation of design. symmetry and broken symmetry[END_REF]. For example, inheritance defines a substitution symmetry between the immutable part of the superclass and the possible changes in its subclasses. These symmetries also appear in mechanisms such as overloading of constructors and methods, and patterns such as factories and strategies. All the occurrences of these symmetries are thus detected, gathered as metrics (e.g., the number of overloaded methods in a class), and complemented with information on inheritance and usage relationships between classes.

VariCity then creates a 3D city representation with buildings being classes while the metrics on the number of symmetries 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. As variability implementations to be identified are close to elements being searched for in onboarding activities [START_REF] Berlin | Beyond program understanding: A look at programming expertise in industry[END_REF]- [START_REF] Park | Beyond pretty pictures: Examining the benefits of code visualization for open source newcomers[END_REF], we organize the usage of VariCity around scenarios based on these activities. This consists of facilitating the comprehension for a skilled newcomer while providing configuration capabilities for the expert to create adapted views for newcomers. As a result, we show that VariCity can facilitate both an high-level discovery of the variability implementations within a codebase, and a deep understanding in some specific areas. These usage scenarios have been validated over a set of ten medium to large objectoriented systems.

The remainder of this paper is organized as follows. Section II introduces concepts of object-oriented variability implementations and defines the visualization requirements based on onboarding scenarios. Section III gives some background on symmetry-based detection of object-oriented variability implementations, as well as on the city metaphor in software visualization. We then introduce the main principles and configurable views of VariCity in section IV. In section V we rely on the defined usage scenarios to evaluate the capabilities of VariCity. Threats to validity and limitations are discussed in section VI, while section VII studies related work. Finally, section VIII concludes this paper and briefly discusses future work.

II. MOTIVATIONS

Many object-oriented software systems are variability rich but do not follow a fully-fledged software product line approach [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF], [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF]. Consequently, their domain variability (i.e., features) is not very well documented and is not made explicit within code assets. In this context, comprehending the variability at code level is crucial for its management. Activities related to comprehension can be as diverse as maintaining or evolving the code, mapping the implemented variability to domain features [START_REF] Metzger | Software product line engineering and variability management: achievements and challenges[END_REF], or conducting an onboarding process for newcomers [START_REF] Azanza | Onboarding in Software Product Lines: Concept Maps as Welcome Guides[END_REF].

A. Object-oriented variability implementations

When variability is present in object-oriented systems, code assets can be structured into three different parts: core, commonalities, and variations [START_REF] Turner | A conceptual basis for feature engineering[END_REF]- [START_REF] Bachmann | Variability in software product lines[END_REF]. The core part corresponds to assets that are included in any of the final software products [START_REF] Turner | A conceptual basis for feature engineering[END_REF]. A commonality is the common part between the related variations of code assets, while variations indicate how and when should code assets vary [START_REF] Hilliard | On representing variation[END_REF]. Such commonalities and variations are usually abstracted in terms of variation points (vp-s) and variants, respectively [START_REF] Jacobson | Software reuse: architecture process and organization for business success[END_REF]- [START_REF] Rabiser | Feature modeling vs. decision modeling: History, comparison and perspectives[END_REF]. A variation point thus identifies one or more locations at which the variation will occur, while the way that a variation point is going to vary is expressed by its variants [START_REF] Jacobson | Software reuse: architecture process and organization for business success[END_REF]. They are both related to concrete elements in code assets [START_REF] John | Separation of variability dimension and development dimension[END_REF].

Usually, in object-oriented variability-rich systems implemented within a single codebase, the implementation of these concrete elements rely on different traditional techniques, such as inheritance, parameters, constructor and method overloading, or some software design patterns [START_REF] Capilla | Systems and software variability management[END_REF], [START_REF] Gacek | Implementing product line variabilities[END_REF], [START_REF] Svahnberg | A taxonomy of variability realization techniques[END_REF], [START_REF] Xh | On the diversity of capturing variability at the implementation level[END_REF]. In this context, the code units that structure the systems are classes, and they do not align well with domain features [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF], [START_REF] Anquetil | A model-driven traceability framework for software product lines[END_REF].

To comprehend implementation variability, SPL migration techniques could be used in a reverse or forward engineering way. Their approaches are characterized as feature location, feature identification [START_REF] Dit | Feature location in source code: A taxonomy and survey[END_REF], [START_REF] Rubin | A survey of feature location techniques[END_REF], [START_REF] Assunc ¸ão | Reengineering legacy applications into software product lines: a systematic mapping[END_REF], feature delimitation (with annotations) [START_REF] Liebig | An analysis of the variability in forty preprocessor-based software product lines[END_REF], or feature modularization [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF]. In these approaches, features commonly tend to describe the domain variability of an SPL or variability-rich system, but are required to be known in advance [START_REF] Metzger | Disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis[END_REF], [START_REF] Rabiser | Feature modeling vs. decision modeling: History, comparison and perspectives[END_REF]. However, domain variability is hardly documented in variability-rich systems [START_REF] Krüger | Where is my feature and what is it about? a case study on recovering feature facets[END_REF], and with a single codebase, reengineering of features from clones of a system cannot be used [START_REF] Martinez | Software Product Line Extraction from Variability-Rich Systems: The Robocode Case Study[END_REF]. As a result, migrating requires substantial manual effort and implies a complete paradigm shift.

While many studies relate on how to address variability with traditional object-oriented techniques [START_REF] Gacek | Implementing product line variabilities[END_REF], [START_REF] Svahnberg | A taxonomy of variability realization techniques[END_REF], [START_REF] Coplien | Commonality and variability in software engineering[END_REF], [START_REF] Patzke | Product line implementation technologies. programming language view[END_REF], identifying vp-s with variants [START_REF] Lozano | An overview of techniques for detecting software variability concepts in source code[END_REF] implemented with these techniques in a single codebase is known to be hard, by the diversity of the implementations [START_REF] Xh | On the diversity of capturing variability at the implementation level[END_REF], [START_REF] Lozano | An overview of techniques for detecting software variability concepts in source code[END_REF] and the lack of adapted visualization [START_REF] Xh | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF]. Moreover, according to a recent mapping study by [START_REF] Lopez-Herrejon | A systematic mapping study of information visualization for software product line engineering[END_REF], while many visual representations of variability management approaches are proposed in the context of SPL, they most often target domain variability (e.g., features in a feature model).

As a result, while identifying the variability implementations directly in code assets, that is, variation points and their variants, is the first activity to comprehend variability, this activity has no dedicated support.

B. Requirements

As program comprehension is seen as a process of both information seeking [START_REF] Sillito | Asking and answering questions during a programming change task[END_REF] and feature location [START_REF] Dit | Feature location in source code: A taxonomy and survey[END_REF], it is obvious that even if our problem is not related to domain features in a classic SPL terminology, identifying vp-s with variants is indeed a comprehension problem. Moreover, SPLs and variable software in general are known to be complex and difficult to apprehend [START_REF] Azanza | Onboarding in Software Product Lines: Concept Maps as Welcome Guides[END_REF], and tools are essential to illustrate software reuse concepts [START_REF] Acher | Teaching software product lines: A snapshot of current practices and challenges[END_REF]. We then first advocate that this context naturally calls for visualization-based solutions [START_REF] Koschke | Software visualization in software maintenance, reverse engineering, and re-engineering: a research survey[END_REF]- [START_REF] Teyseyre | An overview of 3D software visualization[END_REF]. As the essence of software visualization consists of creating an image of software by means of visual objects that represent structure and/or behavior, we believe it is well suited to enable perception of variability implementations with a closer fit to the user mental model. Furthermore, the difficulty of discovering a codebase increases with its complexity, we believe that such visualization should be able to meet the constraints of an onboarding process. Onboarding is a case of program comprehension in which a new developer joins a project or a company [START_REF] Berlin | Beyond program understanding: A look at programming expertise in industry[END_REF], [START_REF] Sim | The ramp-up problem in software projects: A case study of how software immigrants naturalize[END_REF]. Contrary to the usual information seeking in program comprehension (i.e., information pull), onboarding is more based on information push [START_REF] Yates | Characterizing the transfer of program comprehension in onboarding: an information-push perspective[END_REF] and is harder when little is known about the system [START_REF] Steinmacher | Barriers faced by newcomers to open source projects: a systematic review[END_REF]. In onboarding, it has also been shown that newcomers look for major patterns [START_REF] Yates | Characterizing the transfer of program comprehension in onboarding: an information-push perspective[END_REF], such as the ones used in variability implementations. Finally, to avoid frustration by newcomers being onboarded [START_REF] Begel | Struggles of new college graduates in their first software development job[END_REF], the capability to configure and make up adapted visualization for an expert is also crucial.

In this context, we structure our requirement analysis around software comprehension scenarios for visualization within an onboarding process. We are then supposed to target two types of users:

• newcomers in the project, skilled but with no real knowledge about the code (this role can be generalized to anyone attempting to comprehend some software with little or no prior knowledge); • experts in the project, with knowledge of the code and its architecture, but with no explicit vision of the variability implementations. With experts, once they have gained knowledge on the variability, they are likely to be more interested in its evolution [START_REF] Pfahler | Visualizing Evolving Software Cities[END_REF], [START_REF] Wettel | Visual exploration of large-scale system evolution[END_REF]. We consider that all evolution scenarios are out of the scope of this paper, as we first need to provide a visualization for a single snapshot of a project. Consequently, we focus on scenarios that engage the expert to comprehend the implemented variability while building a preconfigured visualization for newcomers. We then propose two scenarios:

• Scenario 1: The expert wants to facilitate the exploration of the codebase by giving a pre-configured visualization to the newcomer. Through this scenario, the newcomer onboards on a large codebase of which he needs to have a global comprehension of the implemented variability (e.g., understand a library or API that is going to be reused). • Scenario 2: The expert wants the newcomer to comprehend a subpart of the codebase for the newcomer to be able to reuse it. Through this scenario, the newcomer onboards on a codebase in which she will be asked to add a new feature. She, therefore, has to understand in more detail the interactions between the classes implemented variability in this subpart. Finally, Yates et al. [START_REF] Yates | Characterizing the transfer of program comprehension in onboarding: an information-push perspective[END_REF] analyze the different types of information transmitted from an expert to a newcomer during onboarding sessions. It results that newcomers find helpful when experts give coarse-grained information about complex zones (ranging from a group of classes to design patterns) of the codebase to them, so they can dig into them by themselves. According to these findings, we can say that a visualization for a newcomer should: (i) display the main elements allowing her to understand the codebase (design patterns, zones with complex variability implementations), (ii) be configurable by the expert to tailor it for newcomers, (iii) provide navigation and interaction capabilities to be adapted by a newcomer (filtering, zooming), (iv) scale on large codebases.

III. BACKGROUND

A. Object-oriented symmetries and variability

While symmetry in nature is often defined as the immunity to a possible change, this concept has also been studied in software, and especially in mechanisms of object-orientation, such as inheritance, overloading, and design patterns, which can also be interpreted in terms of symmetry [START_REF] Zhao | Understanding symmetry in object-oriented languages[END_REF], [START_REF] Coplien | Toward a general formal foundation of design. symmetry and broken symmetry[END_REF]. Taking a codebase as a whole, these implementation techniques can be seen as local symmetries [START_REF] Xh | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF], which allow a part of code to change while another part remains unchanged.

As an illustration, let us take an example from JFreeChart1 , an object-oriented library that provides a variability-rich family of charts (e.g., meters, pies). In the left part of Fig. 1 is depicted a partial UML diagram of some important classes in this library, namely the abstract class Plot with its two subclasses PiePlot and MeterPlot. As inheritance defines a substitution symmetry for its subtypes [START_REF] Zhao | Understanding symmetry in object-oriented languages[END_REF], the possibility of a change in Plot corresponds to its different subtypes, such as PiePlot and MeterPlot (which vary in how they draw a chart). On their side, these classes preserve and conform to the common behavior of their superclass. Furthermore, the main object-oriented (OO) techniques implementing variability can be characterized by local symmetries (e.g., constructor and method overloading, factory or strategy pattern), and at an abstract level, a vp represents the unchanged part while its variants are the changed parts in code assets of a system [START_REF] Xh | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF].

B. Automatic identification of variability implementations

Thanks to the available symmetries in object-oriented variability implementation techniques, its has been shown that seven different techniques can be detected (class as type, class subtyping, method and constructor overloading, strategy, template, decorator, and factory patterns) inside Java or C ++ code [START_REF] Xh | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF], [START_REF] Mortara | symfinder: A Toolchain for the Identification and Visualization of Object-Oriented Variability Implementations[END_REF], [START_REF] Mortara | Identifying and Mapping Implemented Variabilities in Java and C++ Systems using symfinder[END_REF]. It has also been observed that they represent good potential vp-s and variants [START_REF] Xh | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF], and that they can even be successfully mapped to domain features if a list of these features is provided [START_REF] Mortara | Mapping Features to Automatically Identified Object-Oriented Variability Implementations -The case of ArgoUML-SPL[END_REF]. In our example, the vp-s are present at both class and method levels, as shown on the UML diagram in Fig. 1. At the class level, the abstract class Plot is a superclass of PiePlot and XYPlot, making it a vp with two variants. At the method level, every overloaded constructor or method represents a vp, with the number of

Automatic identification of symmetries

Code base Besides, it has also been shown that the density of the variability implementations in a location denotes zones of interest in terms of variability [START_REF] Xh | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF]. In other words, zones with several techniques used, and/or with heavy usage of a technique (e.g., a lot of methods being overloaded, a lot of subclasses in a hierarchy, or inside a strategy pattern) are very likely to be a zone of variability management.

Identified potential vp-s and variants

Furthermore, if a class contains many usages of variability implementations, it is also naturally related by inheritance to some others, especially as the inheritance mechanism is the backbone of many variability implementation techniques [START_REF] Xh | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF]. More recently, the importance of usage relationships between classes, defined through typing of attributes and method parameters, has also been demonstrated to determine a zone of variability interest [START_REF] Mortara | Extending the Identification of Object-Oriented Variability Implementations using Usage Relationships[END_REF]. As a result, with information on symmetries, metrics on their occurrences, as well as relations of inheritance and usage between classes, zones of interest in terms of variability can be predetermined. For example, the metrics on the right part of Fig. 1 indicate that XYPlot possesses 30 overloaded methods (methodVPs), totalizing 77 overloads (methodVariants), making it a highly-variable class 2 .

Taking all the information and metrics on potential vps and variants that can be easily extracted from an objectoriented code base, our aim with VariCity is thus to propose 2 Since constructors all have the name of their class, multiple constructors represent only one vp (constructorVPs), with the number of constructors being the number of variants (constructorVariants). a visualization that meets the usage scenarios devised in section II-B.

C. On the city metaphor in software visualization

Metaphors are often used when designing visualizations as they bring an understandable graphical representation to concepts [START_REF] Knight | Virtual but visible software[END_REF], such as the metaphor of the city [START_REF] Knight | Comprehension with [in] virtual environment visualisations[END_REF], which has been applied to multiple types of metrics on software systems: dynamic behavior (such as concurrency between classes [START_REF] Waller | Synchrovis: 3d visualization of monitoring traces in the city metaphor for analyzing concurrency[END_REF], memory consumption of heaps [START_REF] Weninger | Memory cities: Visualizing heap memory evolution using the software city metaphor[END_REF]), and static properties such as dependency and communication links between components [START_REF] Fittkau | Software landscape and application visualization for system comprehension with explorviz[END_REF].

At a finer-grain, software cities to understand objectoriented software systems have been proposed, the first of them being CodeCity [START_REF] Wettel | Visualizing software systems as cities[END_REF], [START_REF] Wettel | CodeCity: 3D visualization of large-scale software[END_REF] which uses buildings to represent classes, grouping them in districts representing packages. These principles were enhanced by adding a temporal dimension in the analysis to visualize the evolution of the metrics through multiple versions of the system, first in CodeCity [START_REF] Wettel | Visual exploration of large-scale system evolution[END_REF] and also in a more recent approach called M3TRICITY [START_REF] Pfahler | Visualizing Evolving Software Cities[END_REF]. The Evo-Streets [START_REF] Steinbrückner | Understanding software evolution with software cities[END_REF] approach also aims at visualizing the evolution of the software but uses streets to represent the package decomposition (instead of nested boxes in CodeCity). Multiple approaches also reuse the city metaphor and adapt it to more immersive techniques, as virtual reality in VRCity [START_REF] Vincur | VR City: Software Analysis in Virtual Reality Environment[END_REF] or Minecraft in CodeMetropolis [START_REF] Balogh | CodeMetropolis-code visualisation in MineCraft[END_REF].

IV. VARICITY

As shown in section III-C, the city metaphor is a recognized way to visualize different properties of software systems. We hence adapt this visualization to the data we want to visualize and the defined scenarios.

A. Main principles

Buildings. In CodeCity, classes are buildings and their size evolves according to metrics related to code quality which are inherent to the represented class, such as the cyclomatic complexity or the number of lines of code (LoC). For example, an important number of methods will lead to a tall building, catching the attention of the user on it. In VariCity, we aim to focus the user on classes making heavy use of variability implementations. Therefore, the dimensions of every building represent the class-based metrics related to variability (i.e., the number of variants at method level -a tall building shows an important number of method variants, whereas a large building shows an important number of constructor variants). Moreover, buildings in color on the visualization (by default yellow for vp-s and blue for non vp-s) represent classes defined as hotspots. Such classes are part of dense zones of variability and are vp-s identified by matching one of the two following requirements: (i) they have a minimum number of variants, 5 in our experiments, or (ii) they are close in usage to another vp (i.e., they are situated at less than 3 transitive hops in the usage relationships graph). The shape of the building is altered according to the design pattern(s) exhibited by the class 3

(cf. table I).

Displaying differently classes being hotspots and/or exhibiting design patterns brings to the user insights on highly variable zones of the project, which she can then explore in more detail by using the different interactions provided by the visualization (spanning, zooming).

Streets. Analogously, as the representation proposed by CodeCity groups classes belonging to the same package in a district to exhibit the packages containing the most complex classes, our goal is to group in the same neighborhood classes concentrating a high density of variability implementations.

However, although the nested districts allow to efficiently represent the decomposition hierarchy of classes belonging to nested packages, it is not adapted to our notion of density of variability implementations which derives from usage relationships between classes (as a class can use and/or be used by multiple other classes). We thus rely on the visualization proposed by Evo-Streets [START_REF] Steinbrückner | Understanding software evolution with software cities[END_REF], which uses streets to decompose a hierarchy instead of boxes. In the original Evo-Streets layout, streets represent subsystems, with orthogonal branching streets representing their subsystems. The buildings on a street represent the modules belonging to this system. We adapt the visualization with buildings on streets being classes, and streets departing from a building (instead of another street) to represent a usage relationship between this class and every other class whose building is on the street. As we consider inheritance links as less important for variability, they are represented as aerial links between buildings, being only displayed when hovering over a building. This enables the user to see the inheritance information if needed, while the hotspot coloring and streets for usage bring the most important information first.

A summary of the visual properties is presented in table I and illustrated in Fig. 3. information of different nature needs to be displayed: classes, links between them, design patterns. However, on a large project, providing a first view with all classes (and their usage / inheritance relationships) displayed would bring too much information. There is thus a need to focus the visualization around known points of interest of the system. The idea is therefore to allow the expert to create a city in line with the most important elements for her and to give a first simplified vision of the city which does not show all the relationships between classes. The visualization algorithm thus relies on a certain number of inputs that focus the view (cf. section IV-B). From this first visualization, it will also be possible to gradually adapt the city, among other things, by adding or removing relationships and classes (cf. section IV-C).

TABLE I: Visual properties and their default color

B. From buildings and streets to a city

The goal of VariCity is to display the main elements allowing one to understand the variability implementations related to a given point of interest in the system (cf. section II-B). To do so, VariCity relies on three mandatory inputs. The first one defines entry point classes, which represent important points of interest for the comprehension of the system (e.g., endpoint of an API that could be automatically inferred, or street Fig. 4: Result example of the placement algorithm complex classes of the system given by the expert). The second input is the usage orientation, which can be IN and/or OUT. An orientation IN means that the classes displayed will be the classes using the defined entry points (i.e., having it as an attribute or method parameter). On the opposite, an orientation OUT means that the classes displayed will be the classes being used by the defined entry points (i.e., being an attribute or method parameter of the entry point). Depending on the objectives of the onboarding scenario envisaged by the expert, she might show either how the entry point uses or is used by other classes. More detailed examples are given in section IV-C. Finally, setting the orientation to IN/OUT displays classes using or being used by the entry points. The third input is the usage level, which is an integer value. With a usage level of n, all classes distant from an entry point by n usage relationships will be displayed. For example, a visualization set up with an entry point, usage orientation OUT and usage level of 2 will display the entry point, the classes being used by the entry point, and the classes used by these classes. Being able to adapt this value is important as depending on the complexity or the layered architecture of a system, a given level of usage might be adapted to it but shows too many classes on another one.

The root (first) street, in red on Fig. 3a, aggregates all the entry points. Then, starting from them, classes using (or being used by) them up to the usage level set are displayed. A street is initiated from an entry point, and for each class related to it, a building is placed on the border on the street. In order to exhibit density between classes, we need to place as close as possible buildings linked by a usage relationship to the same class. Following this principle, we place the buildings by decreasing order of width on both sides of the street, minimizing the total length of the street to keep the buildings as close as possible (Fig. 4).

Our placing algorithm can lead to long straight streets if a class uses many others. Work presenting techniques to prevent this behaviour and keep cities compact (such as folding) exist [START_REF] Kratt | Improving Stability and Compactness in Street Layout Visualizations[END_REF]. However, this information is valuable in the case of VariCity as it allows to quickly visualize classes concentrating many usage relationships. It is also likely to happen that a class is linked through a usage relationship to multiple visualized classes. In that case, these additional usage relationships are represented as green underground streets and appear only when hovering the class, as well as the inheritance relationships not to overload the visualization 4 .

An example of visualization after generation is presented in Fig. 3a. Additional links appearing on hover are presented in Fig. 3b.

C. Configuring the view to adapt the city

The configuration of VariCity is done in two steps. The first step concerns the adaptation of the mandatory inputs required to build the visualization (i.e., entry point classes, usage level, and usage orientation), which are preconfigured by the expert. Based on her knowledge, the expert determines which classes are relevant enough to be entry point classes. The orientation will be set depending on what she expects the newcomer to understand from the system: if she wants the newcomer to reuse a part of the implementation, she will likely choose the IN orientation as it will show which classes already use the entry point so that the newcomer can see how the class is already used. On the opposite, if she wants the newcomer to add a new feature, she will more likely choose OUT so that the newcomer sees which classes are used by the entry points to know which classes she may need to reuse. Finally, choosing IN/OUT gives an overview of both aspects. Determining the usage level can only be done empirically. A level too low might hide important information for the comprehension of the variability, and a level too high might display too much information. Such characteristics are dependent on every codebase. For example, the visualization of JFreeChart presented in Fig. 2a has JFreeChart and Plot as entry points, a usage level of 4, and a usage orientation OUT. The expert can also choose not to display classes that she considers irrelevant by putting them in a blacklist.

The second step represents options allowing to adapt the visualization, such as visual settings (colors of the visual elements, padding between the buildings) that may improve the readability of the visualization. Metrics for the height and width of the buildings can also be adapted. This parameter may be useful for the expert that has a particularly deep understanding of the system. For example, if the method level variability of classes is due to constructor overloads, it might be useful to use this metric for the height instead of the width of the buildings.

Although all these parameters for both steps have default values set by the expert, they can also be adapted by the newcomer while exploring the visualization in a sidebar to maximize her autonomy. We will illustrate in section V how different values for the inputs in the first step impact the structure of the visualization by detailing the two scenarios presented in section II-B.

D. Implementation

VariCity implementation relies on an existing toolchain complemented by its dedicated visualization.

The automatic identification of the symmetries and, relying on them, of the potential vp-s and variants, depicted in Fig. 1 is done by reusing symfinder [START_REF] Mortara | symfinder: A Toolchain for the Identification and Visualization of Object-Oriented Variability Implementations[END_REF]. After cloning the Git repository of a single Java or C ++ codebase, symfinder identifies the symmetries present in the code and stores their representation in a graph database to perform the identification of the potential vp-s and variants. Information is structured by class and used by VariCity to build the visualization (cf. section IV-B), relying on the settings provided in a configuration file. The web-based visualization is standalone, and developed in TypeScript with the Babylon.js5 3D library. The whole application is deployed with Webpack and requires only a web browser to be viewed. Both VariCity and symfinder are deployed using Docker to ease their reuse and reproducibility of the visualizations presented in this paper. The source code of VariCity is available online [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities -Reproduction package[END_REF].

V. EVALUATION

In [START_REF] Mortara | Extending the Identification of Object-Oriented Variability Implementations using Usage Relationships[END_REF], the symfinder toolchain, which detects potential vp-s with variants, was applied on ten popular open-source and variability-rich Java systems, being applications, framework, or libraries, with different characteristics (size, variation points, explicit API provided). We chose to select the same systems to test the results of VariCity. In table II are listed the systems and their VariCity configuration to facilitate the exploration or deepening of a particular area, as shown by our scenarios. The entry points have been determined by exploring the codebases and documentations, and selecting important classes accordingly. The values for usage level and orientation were determined empirically to provide a visualization showing interesting zones. By tailoring the inputs for these systems, we show that our approach is applicable to systems of various sizes and structures. The generated cities for all systems are available in the reproduction package [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities -Reproduction package[END_REF]. Entry point classes being preconfigured, the user just needs to adapt the values for the usage level and orientation.

In this section, we evaluate whether VariCity answers to the needs expressed in section II-B, relying on the scenarios presented in section IV-C. We chose the Apache NetBeans IDE with its 5 MLoC6 for Scenario 1 to illustrate the exploration of a large codebase. We chose the JFreeChart charting library for Scenario 2 to illustrate comprehension for reuse, as this scenario requires a finer-grained knowledge of the codebase, and we already detailed parts of its variability implementations in previous work [START_REF] Xh | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF]. A video walkthrough of the scenarios is available on VariCity's website at https://deathstar3.github. io/varicity-demo/.

A. Scenario 1: exploration of the codebase Objectives: With this scenario, we want to evaluate how VariCity and its configuration capabilities can help to distinguish zones of high density of variability in a codebase, which are manifested by buildings of particular height or width (i.e., important number of method level variability implementations), in color (i.e., part of dense zones of variability implementations), or with a crown (i.e., presence of a design pattern).

Unfolding the scenario: The newcomer onboards on JFreeChart, a Java library allowing to draw different types of charts, and is asked to implement a new type of chart in the library. Contrary to the first scenario, the newcomer aims at adding a new feature to the codebase, thus she needs a more fine-grained understanding of it, as, for example, the classes used by the other charts that she might also need to use. The expert thus configures the visualization to use as entry points JFreeChart 13 , being the endpoint of the library used by the users to create plots and Plot 14 , the superclass of all classes implementing a different type of chart. As the goal is to display which classes are used by these two entry points, the usage orientation is set to OUT and the usage level to 2. The obtained visualization is shown in Fig. 6a.

We notice that the colored buildings, which represent classes being part of dense zones of variability implementations, do not align with the most variable classes. For example, LegendItem is a factory and, due to its large base, exhibits an important number of constructor variants. However, although this class is internally dense in variability, it is a utility object which not related to any other vp, and for this reason, is not characterized as a hotspot.

By hovering over Plot, the newcomer can see the different displayed subclasses of the class (i.e., the variants of the vp Plot). To add another type of chart in library, she will need to implement a new variant of this vp and needs thus to have an overview of the classes used by these subclasses. To do so, the user adds the two most variable ones (XYPlot 15 and CategoryPlot 16 ) as entry points (Fig. 6b). The shape of the city changes to display the usages related to each entry point in separated neighborhoods, allowing to better visualize if (i) a particular entry point is the starting point of a dense zone of variability implementations, and (ii) a class is related (to a certain degree) to two entry points with underground streets. On Fig. 6b, an important number of classes making heavy use of variability implementations is visible, and are directly used by XYItemRenderer 17 , itself related to both XYPlot and classes related to CategoryPlot. Given these characteristics, the newcomer may need to reuse it to implement his feature and thus can add it as another entry point to visualize its usage if needed.

To visualize the classes used by XYPlot and CategoryPlot, the newcomer could also have chosen to increase the usage level on the visualization given by the expert, as shown on Fig. 6c. However, an important number of classes and relationships not related to the newcomer's interest would appear, hampering the comprehension. The newcomer could also have chosen other class variants of Plot to add as entry points. However, most likely the classes that will be added to the visualization are not dense in variability, thus less interesting for the scenario.

C. Summary

Through these two scenarios, the newcomer is able, using VariCity, to see variability implementations in an unknown codebase from a high-level perspective, and also to dig into them to have a more precise understanding. Providing a more complete experimental evaluation based on feedback from both experts and newcomers on the use of VariCity is part of our future work.

VI. THREATS TO VALIDITY AND LIMITATIONS

Without an empirical assessment, the main threat of our evaluation concerns the scenarios that we designed by ourselves. Nevertheless, we relied on both empirical work on onboarding with real experts and newcomers [START_REF] Yates | Characterizing the transfer of program comprehension in onboarding: an information-push perspective[END_REF] and challenges related to the comprehension of variability concepts [START_REF] Acher | Teaching software product lines: A snapshot of current practices and challenges[END_REF], giving us good confidence in the relevance of the scenarios.

Another threat arises by the fact that both authors and developers of VariCity determined empirically the inputs (entry points, usage level and orientation) for each scenario, based on their knowledge of the systems and of VariCity's capabilities. Still, even by having a coarse-grain understanding compared to a real expert, the obtained visualizations already exhibit satisfying results. We expect real experts to be able to determine appropriate inputs in real settings.

Concerning the structure of the visualization, the placement of the buildings on a street only relies on the width of the buildings to compact them in the street. This implies that the variability represented by the height of the buildings is not taken into account. Even if this dimension is largely visible on the visualization, this calls for an adaptation of the placement algorithm to take into account both dimensions while placing the buildings.

VII. RELATED WORK

Works on the city metaphor in software visualizations were studied in section IV-A. In this section, we discuss work related to visualization for variability management and to assist onboarding activities.

A. Visualization in the Software Product Line field

A recent mapping study has shown that visualizations in the SPL domain mainly target feature models, using tree or graph representations [START_REF] Lopez-Herrejon | A systematic mapping study of information visualization for software product line engineering[END_REF]. These visualizations are mainly used to facilitate the configuration process over features. To visualize variability at the code level, some approaches use colors [START_REF] Kästner | Visualizing software product line variabilities in source code[END_REF] or bar diagrams [START_REF] Duszynski | Recovering variability information from the source code of similar software products[END_REF], while some others focus on feature traces [START_REF] Andam | Florida: Feature location dashboard for extracting and visualizing feature traces[END_REF] or feature interactions between features and code [START_REF] Greevy | Visualizing feature interaction in 3-d[END_REF], [START_REF] Bergel | Featurevista: Interactive feature visualization[END_REF]. None of them focus on object-oriented techniques as variability implementations.

In VariCity, we reused the symmetry-based detection part of symfinder [START_REF] Xh | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF], [START_REF] Mortara | Extending the Identification of Object-Oriented Variability Implementations using Usage Relationships[END_REF], but this tool also provides a graphbased visualization in which each class level vp and variant is represented as a circle node that points out the used implementation technique, with size and shades of nodes indicating some occurrences of symmetries. These nodes are linked with both inheritance and usage relationships being different kinds of edges, forming a set of disconnected graphs. While this visualization allows showing some dense zones of variability and has filtering capabilities, it has only been used for the validation of the capabilities of symfinder in identifying potential vp-s and variant. It is not adapted for comprehending variability as in our considered scenarios, especially in largescale systems in which the resulting visualization is not usable (approx. 4k nodes for NetBeans).

B. Visual tools to assist onboarding

Some visualizations have been especially proposed for onboarding activities. Isopleth [START_REF] Hibschman | Isopleth: Supporting Sensemaking of Professional Web Applications to Create Readily Available Learning Experiences[END_REF] represents call relationships in front-end JavaScript implementations in the form of a call graph, which is interactive and can be edited to see the impact in real-time on the page. Other tools integrate information from the organization to help information seeking during development activities, such as Tesseract [START_REF] Sarma | Tesseract: Interactive visual exploration of socio-technical relationships in software development[END_REF] which visualizes the relationships between technical information from a codebase and related social data (e.g., developers, communication, code, and bugs). Finally, recent studies on onboarding in SPLs [START_REF] Azanza | Onboarding in Software Product Lines: Concept Maps as Welcome Guides[END_REF] explore concept maps [START_REF] Novak | The theory underlying concept maps and how to construct them[END_REF] to structure information about the SPL. However, this approach, as many others evoked in section VII-A relies on a feature model and documentation, which does not apply in our case.

VIII. CONCLUSION

Variability-rich object-oriented software systems often implement variability in a single code base using mechanisms from the supporting language, such as inheritance, overloading, and design patterns. These implementations are thus not explicit and difficult to comprehend, especially for a newcomer onboarding on a project and trying to comprehend variability in it. In this paper, we proposed VariCity, a 3D visualization based on the city metaphor to propose adapted and configurable views that exhibit zones of high density of variability implementations. The density relies on previous work on automated detection of symmetries in the variability implementation mechanisms. Metrics on their occurrences together with information on inheritance and usage relationships are exploited to build a city with, notably, classes as buildings and streets as usage relationships. We also detailed two onboarding scenarios showing how the different capabilities of the visualization can help to spot critical variability-related zones of a codebase and obtain fine-grained information about them.

The visualization toolchain is publicly available and has been applied to several large object-oriented systems. We expect it can help different kinds of users, from experts to newcomers, to understand variability in this kind of system. As future work, we first plan to conduct an evaluation with real experts of a codebase building scenarios for newcomers onboarding on their project. We also plan to integrate the visualization with a development environment that would automate the interactions between the source code and the city. At another level, we also want to explore the coupling of the metrics used in this visualization with other software metrics [START_REF] El-Sharkawy | Metrics for analyzing variability and its implementation in software product lines: A systematic literature review[END_REF], such as complexity or test coverage. With these experiments and improvements, we expect to gain new insights on how to better facilitate the identification of variability implementations.

Fig. 1 :

 1 Fig.1: Symmetries in object-oriented code and metrics that can be extracted

Fig. 2 :

 2 Fig. 2: Sample views of VariCity

Fig. 3 :

 3 Fig. 3: Visual properties of VariCity

Fig. 6 :

 6 Fig. 6: Scenario 2

http://www.jfree.org/jfreechart/

A design pattern often involves multiple classes, however only the vp of the design pattern has a special crown on it, not to overload the visualization.

When hovering over, class names are also displayed in a sidebar for the same reason.

https://www.babylonjs.com/

https://netbeans.apache.org/

ACKNOWLEDGMENT

We thank Paul-Marie Djekinnou, Florian Focas and Franc ¸ois Rigaut for their contribution in the development of VariCity.

https://junit.org/junit5/ 11 https://testng.org/doc/ [START_REF] Svahnberg | A taxonomy of variability realization techniques[END_REF] See here and here.

Unfolding the scenario: The newcomer onboards on the NetBeans IDE code base and needs to use the JavaPlatform API, which configures the version and location of Java to be used when building and running a project 7 . To better understand the operation of the API, the newcomer thus needs to have a global vision of the structure of the usage and inheritance relationships between the classes. To this effect, the expert configures the visualization to use the endpoint of the API, namely JavaPlatform 8 , as the entry point of the visualization. Both classes using and being used by on 5 levels (usage level 5, orientation IN and OUT) are shown to have a first overview of the classes being closely related to the endpoint of the API. The obtained visualization is shown in Fig. 5a. A neighborhood of tall and colored buildings (circled in yellow) detaches from the other buildings in the city, showing to the user zones with classes heavily using variability implementation techniques. By zooming and spanning the visualization, the user can focus on this precise part of the city (Fig. 5b) 9 . The different implemented design patterns are distinguishable due to the special shape of their buildings (e.g., JavaFix 7 https://bits.netbeans.org/12.2/javadoc/org-netbeans-modules-java-platform/ overview-summary.html 8 org.netbeans.api.java.platform.JavaPlatform 9 The names and arrows have been manually added on the figure. The name of the class corresponding to a building appears in a sidebar of the visualization when hovering over the building. Packages, when unnecessary, have been omitted for readability.

B. Scenario 2: comprehension of a subpart of the codebase for reuse

Objectives: With this scenario, we want to evaluate how the customization of the view by the newcomer can allow her to tailor the visualization to obtain fine-grained details about the codebase.