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

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

Anne-Marie Dery-Pinna

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

Customizable Visualization of Quality Metrics for Object-Oriented Variability Implementations

Keywords: Software and its engineering → Software product lines, Software reverse engineering, Object oriented architectures, • Human-centered computing → Visualization systems and tools software variability, technical debt, software visualization, quality metrics, object-oriented systems, reverse-engineering

  L'archive ouverte pluridisciplinaire

INTRODUCTION

The constantly increasing demand for software solutions constraints software practitioners to develop and maintain customizable software systems that can be delivered at high-rate while assuring an optimal level of quality and security. In this context, monitoring quality is crucial for the maintenance and evolution of such systems [START_REF] Martini | The danger of architectural technical debt: Contagious debt and vicious circles[END_REF]. For example, projects managed using Agile methodologies define specific requirements to describe the desired qualities of the system [START_REF] Behutiye | Management of quality requirements in agile and rapid software development: A systematic mapping study[END_REF][START_REF] Wiegers | Software requirements[END_REF] and limit technical debt (i.e., the impact on the system's maintainability and evolution [START_REF] Avgeriou | Managing technical debt in software engineering (dagstuhl seminar 16162)[END_REF]). While technical debt covers diverse aspects of the software and its development ecosystem [START_REF] Kruchten | Technical debt: From metaphor to theory and practice[END_REF], its identification at the implementation level is mainly done through code analysis (e.g., by computing metrics or identifying a lack of tests [START_REF] Li | A systematic mapping study on technical debt and its management[END_REF]).

Such large-scale configurable systems are variability-rich [START_REF] Galster | Variability-Intensive Software Systems: Product Lines and Beyond[END_REF][START_REF] Galster | Variability in Software Systems -A Systematic Literature Review[END_REF][START_REF] Hilliard | On Representing Variation[END_REF] and make use of various mechanisms to implement their variability, for instance, annotative approaches (e.g., preprocessor directives [START_REF] Liebig | An analysis of the variability in forty preprocessor-based software product lines[END_REF]) or aspects [START_REF] Mezini | Variability management with featureoriented programming and aspects[END_REF]. Most annotative mechanisms, however, are known to impede the quality of the software in multiple aspects, especially by bringing additional complexity [START_REF] Galster | Variability and complexity in software design: Towards a research agenda[END_REF] and polluting the code [START_REF] Le | # ifdef confirmed harmful: Promoting understandable software variation[END_REF][START_REF] Medeiros | Discipline matters: Refactoring of preprocessor directives in the# ifdef hell[END_REF], thus making the code difficult to understand, maintain and test [START_REF] Thomas | A complexity measure[END_REF], and leading to technical debt [START_REF] Li | A systematic mapping study on technical debt and its management[END_REF]. The studies of technical debt due to variability implementations led to new definitions [START_REF] Abal | 42 variability bugs in the linux kernel: a qualitative analysis[END_REF][START_REF] Mordahl | An empirical study of real-world variability bugs detected by variability-oblivious tools[END_REF] and adaptations of standard definitions [START_REF] Fenske | Code smells revisited: A variability perspective[END_REF][START_REF] Iuri | Investigating Variability-aware Smells in SPLs: An Exploratory Study[END_REF] to consider variability mechanisms. Very recently, Wolfart et al. [START_REF] Wolfart | Variability Debt: Characterization, Causes and Consequences[END_REF] reformulated the technical debt caused by variability implementations under the definition of variability debt.

Many variability-rich systems, however, do not follow a complete SPL approach and do not rely on the previously cited mechanisms to implement their variability. This is especially the case of object-oriented (OO) systems that often implement their variability in a single codebase, using the traditional OO mechanisms (i.e., inheritance, overloading of methods and constructors, 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]. This absence of dedicated implementation mechanisms causes the variability to be intertwined with the implementation, hampering its identification, analysis, and understanding as there is no traceability with domain information [START_REF] Tërnava | Identification and visualization of variability implementations in object-oriented variability-rich systems: a symmetry-based approach[END_REF][START_REF] Tërnava | Tracing Imperfectly Modular Variability in Software Product Line Implementation[END_REF]. Being completely dependent on mechanisms causing technical debt, such systems are prone to introduce variability debt [START_REF] Wolfart | Variability Debt: Characterization, Causes and Consequences[END_REF] at the code level, calling for a solution to better identify and understand it.

On one side, multiple tools and approaches exist to compute metrics on an OO codebase, analyze its quality [START_REF] Li | A systematic mapping study on technical debt and its management[END_REF][START_REF] Rasool | A review of code smell mining techniques[END_REF], and determine technical debt [START_REF] Paris C Avgeriou | An overview and comparison of technical debt measurement tools[END_REF]. Such metrics are often exploited in visualizations [START_REF] Chotisarn | A systematic literature review of modern software visualization[END_REF][START_REF] Li | A systematic mapping study on technical debt and its management[END_REF], such as CodeCity [START_REF] Wettel | CodeCity: 3D visualization of largescale software[END_REF] and Evo-Streets [START_REF] Steinbrückner | Understanding software evolution with software cities[END_REF] that are now bundled in reference code analysis tools such as SonarQube 1 . Such visualizations, however, do not allow displaying the use of OO variability implementations mechanisms. Even in case some experts have good knowledge of the implemented variability of their system, they will need to observe the quality of the concerned classes one by one. On the other side, a first approach to identify OO variability implementations has been proposed by Tërnava et al. [START_REF] Tërnava | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF], abstracting the OO mechanisms in terms of variation points (vp-s) and variants relying on the notion of symmetry [START_REF] Coplien | Symmetry Breaking in Software Patterns[END_REF][START_REF] Zhao | Understanding symmetry in objectoriented languages[END_REF] to automatically identify zones with a high density of potential variability implementations [START_REF] Mortara | symfinder: A Toolchain for the Identification and Visualization of Object-Oriented Variability Implementations[END_REF]. Mortara et al. [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities[END_REF] then proposed VariCity, a city-based visualization to ease their identification. However, this visualization does not provide information on the quality of the system's classes and experts must rely on other tools to observe more closely the quality of the classes highlighted by VariCity. Furthermore, navigating between VariCity and a metric-specific tool would be cumbersome as it would require manually finding and mapping information having heterogeneous representations. Therefore, to the extent of our knowledge, no solution exists to visualize technical debt in OO variability-rich systems.

In this paper, we propose VariMetrics, an extension of VariCity to support software quality metrics and reveal critical zones concentrating variability implementations prone to cause variability debt in the context of a single OO codebase. As determining a relevant quality measure relies on numerous factors [START_REF] Kitchenham | Software quality: the elusive target [special issues section[END_REF], practitioners need to define relevant indicators for each system relying on the profusion of existing metrics [START_REF] Nur | Software product quality metrics: A systematic mapping study[END_REF]. Thus, VariCity's configuration capabilities have been extended to enable one to compose state-ofthe-art OO quality metrics as visual properties on the buildings, which are the classes of the project. We report on the evaluation of VariMetrics, which was first applied to seven open-source software systems to show that it reveals quality-critical zones of variability implementations (section 5.1). We also assess the relevance of the indebted classes identified in one project by improving a subset of these classes and their tests, thus showing a global improvement of the project's quality (section 5.2).

The rest of the paper is organized as follows. Section 2.1 introduces the motivations for our work. Section 2.2 details related work on OO variability implementations and quality metrics, as well as their associated visualizations (VariCity and CodeCity). Section 3 gives background on the identification of OO variability implementations and on how VariCity uses them to build its visualization. We then present VariMetrics and how it extends VariCity to support quality metrics in section 4. We evaluate our approach (section 5) and discuss threats to the validity and limitations in section 6. Finally, section 7 concludes the paper while presenting future work.

MOTIVATIONS

Software quality is an important field of research due to its broad impact on the software development cost [START_REF] Slaughter | Evaluating the cost of software quality[END_REF]. In the domain of OO systems, multiple works focus on determining software quality metrics [START_REF] Campbell | Cognitive complexity: An overview and evaluation[END_REF][START_REF] Fowler | Refactoring: improving the design of existing code[END_REF][START_REF] Kafura | Software quality metrics based on interconnectivity[END_REF][START_REF] Thomas | A complexity measure[END_REF][START_REF] Misra | A suite of object oriented cognitive complexity metrics[END_REF][START_REF] Linda | Software quality metrics for object-oriented environments[END_REF], measuring the system evolution [START_REF] Hecht | Tracking the software quality of android applications along their evolution (t)[END_REF][START_REF] Sato | Tracking the evolution of object-oriented quality metrics on agile projects[END_REF], and validating the relevance of these metrics [START_REF] Ahmad Khan | An empirical validation of object oriented design quality metrics[END_REF][START_REF] Pantiuchina | Improving code: The (mis) perception of quality metrics[END_REF]. Quality metrics have been recognized as useful for determining technical debt at the code level, i.e., expedient but costly on the long term implementation constructs, primarily hampering maintainability and evolvability [START_REF] Avgeriou | Managing technical debt in software engineering (dagstuhl seminar 16162)[END_REF][START_REF] Li | A systematic mapping study on technical debt and its management[END_REF].

Problem statement

Wolfart et al. [START_REF] Wolfart | Variability Debt: Characterization, Causes and Consequences[END_REF] defined variability debt as "Technical debt caused by defects and sub-optimal solutions in the implementation of variability management in software systems". They studied 52 industrial case studies reporting technical debt issues on variable software systems with the following main results: 1. the lack of knowledge of the implemented variability, as well as the absence of traceability, causes variability debt; 2. the absence of known variability implementation mechanisms is prone to cause artifact duplication, an increase of code complexity, and a "disappearance of links between implementation artifacts to business values" [START_REF] Ebert | Tricks and traps of initiating a product line concept in existing products[END_REF]; 3. variability debt mainly impacts source code artifacts; 4. variability debt causes inability to systematically deal with customization and poor overall internal quality, complicating maintenance for the development team.

This work focuses on the identification of the part of variability debt dedicated to object-oriented variability implementations. Many large object-oriented systems are naturally variability-rich but they do not follow a systematic approach to manage variability as in the SPL paradigm [START_REF] Apel | Feature-Oriented Software Product Lines[END_REF][START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF]. Consequently, they do not define features at a domain level in a formal model, and these features are not consistently documented or made explicit in the code assets. While some organizations adopt a clone-and-own approach [START_REF] Ghabach | Supporting Clone-and-Own in software product line[END_REF][START_REF] Rubin | Managing cloned variants: a framework and experience[END_REF] to handle variability, with many disadvantages [START_REF] Echeverría | An empirical study of performance using Clone & Own and Software Product Lines in an industrial context[END_REF][START_REF] Ghabach | Guiding Clone-and-Own When Creating Unplanned Products from a Software Product Line[END_REF], our work focuses on object-oriented variability-rich systems that manage variability in a single codebase.

In such systems, code assets are structured into three distinct parts, the core being assets included in all software products, commonalities being the common part between the related variations of code assets, and variations representing how and when code assets vary [START_REF] Bachmann | Variability in Software Product Lines[END_REF][START_REF] Coplien | Multi-Paradigm Design for C++[END_REF][START_REF] Hilliard | On Representing Variation[END_REF][START_REF] Turner | A Conceptual Basis for Feature Engineering[END_REF]. Variation points (vp-s) and variants are concrete constructions in the code assets that usually abstract respectively the commonality and variation parts [START_REF] Czarnecki | Cool features and tough decisions: a comparison of variability modeling approaches[END_REF][START_REF] Jacobson | Software reuse: architecture process and organization for business success[END_REF][START_REF] John | Separation of Variability Dimension and Development Dimension[END_REF][START_REF] Rabiser | Feature Modeling vs. Decision Modeling: History, Comparison and Perspectives[END_REF]. A vp references one or more locations at which the variation is going to happen, while the variants express how the variation point varies [START_REF] Jacobson | Software reuse: architecture process and organization for business success[END_REF].

In a single OO codebase, vp-s and variants can be implemented through diverse mechanisms already present in the language, such as inheritance, parameters, constructor and method overloading, or variability-related design patterns (e.g., strategy, factory, template) [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] Tërnava | On the Diversity of Capturing Variability at the Implementation Level[END_REF]. Recently, an approach based on detecting symmetries in OO mechanisms [START_REF] Coplien | Symmetry Breaking in Software Patterns[END_REF][START_REF] Zhao | Understanding symmetry in objectoriented languages[END_REF] was proposed to identify these variability implementations without prior explicit knowledge of features [START_REF] Tërnava | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF]. Although it can abstract potential vp-s and variants, Mortara et al. [START_REF] Mortara | symfinder: A Toolchain for the Identification and Visualization of Object-Oriented Variability Implementations[END_REF] extended it to identify interesting zones of a high density of variability implementations. In a follow-up work, they rely on a city metaphor, known to help in software understanding [START_REF] Knight | Virtual but visible software[END_REF], and provide VariCity, a visualization to ease identification (see section 3 for more details).

While the object-oriented variability implementations can be more easily identified, they are especially prone to technical debt at the source code level. They are directly reusing traditional mechanisms and variability code is then intertwined with the rest of the implementation code [START_REF] Tërnava | Identification and visualization of variability implementations in object-oriented variability-rich systems: a symmetry-based approach[END_REF][START_REF] Tërnava | Tracing Imperfectly Modular Variability in Software Product Line Implementation[END_REF]. Measuring their quality is thus crucial, and using quality metrics is then a natural way [START_REF] Li | A systematic mapping study on technical debt and its management[END_REF][START_REF] Rasool | A review of code smell mining techniques[END_REF] to determine technical debt [START_REF] Paris C Avgeriou | An overview and comparison of technical debt measurement tools[END_REF], especially through visualizations [START_REF] Chotisarn | A systematic literature review of modern software visualization[END_REF][START_REF] Li | A systematic mapping study on technical debt and its management[END_REF].

To structure our definition of the problem, we define a general usage scenario that will drive our studies and design choices in the remainder of the paper. From the quality point of view, it has been shown that, in an agile context, team members involved in quality requirements definition correspond to senior profiles [START_REF] Alsaqaf | Quality requirements in large-scale distributed agile projects-a systematic literature review[END_REF][START_REF] Behutiye | Management of quality requirements in agile and rapid software development: A systematic mapping study[END_REF]. Therefore, they represent advanced developers that have enough knowledge of the system to have an overview of the implemented domain, as well as of quality to design quality requirements. In the following, we identify such people as "experts". According to our analysis above, we phrase the scenario as follows: the expert wants to analyze the quality of the variability implementations to potentially identify OO variability debt.

Related Work

Object-oriented metrics and visualization. Tools have been developed to automatically analyze OO codebases and extract quality metrics [START_REF] Lenarduzzi | A survey on code analysis tools for software maintenance prediction[END_REF], such as SonarQube2 , one of the most frequently used open-source code analysis tools, adopted by more than 200K developer teams, including more than 250K public open-source projects on its cloud version SonarCloud3 . Not only the metrics are extracted, but a set of customizable rules gives more precise insights into the defects detected, and how to correct them [START_REF] Lenarduzzi | Are sonarqube rules inducing bugs?[END_REF][START_REF] Pellegrini | On the Fault Proneness of SonarQube Technical Debt Violations[END_REF]. Finally, a set of plugins complete the tool to provide improved exploitation of the extracted metrics, such as advanced visualization solutions. One of them is SoftVis3D4 , which embeds CodeCity [START_REF] Wettel | CodeCity: 3D visualization of largescale software[END_REF] and Evo-Streets [START_REF] Steinbrückner | Representing development history in software cities[END_REF], two popular visualizations relying on the city metaphor [START_REF] Wettel | Visualizing software systems as cities[END_REF] to represent the system and its quality metrics. Figure 1 illustrates the two visualizations on the GeoTools project 5 , an open-source Java library for geospatial data management. Classes are represented as buildings and their width, height, and color are used to display the quality metrics, making discernible classes maximizing these metrics. Districts in CodeCity (fig. 1a) and streets in Evo-Streets (fig. 1b) represent the decomposition in packages. As such visualizations have proven to help the comprehension of a system's quality [START_REF] Wettel | Software systems as cities: A controlled experiment[END_REF], multiple other city-based visualization approaches for quality have been proposed [START_REF] Fittkau | Software landscape and application visualization for system comprehension with ExplorViz[END_REF][START_REF] Pfahler | Visualizing Evolving Software Cities[END_REF][START_REF] Wettel | Visual exploration of large-scale system evolution[END_REF]. However, none of them allows displaying information on the system's variability.

Object-oriented variability visualization. While visualizations for properties of variable systems are focused on systems organized as an SPL or making use of annotative approaches for which features are known [START_REF] Andam | Florida: Feature location dashboard for extracting and visualizing feature traces[END_REF][START_REF] Bergel | FeatureVista: Interactive Feature Visualization[END_REF][START_REF] Greevy | Visualizing feature interaction in 3-D[END_REF][START_REF] Kästner | Visualizing Software Product Line Variabilities in Source Code[END_REF][START_REF] Roberto | A systematic mapping study of information visualization for software product line engineering[END_REF], little work exists on visualization of OO variability implementations. symfinder [START_REF] Mortara | symfinder: A Toolchain for the Identification and Visualization of Object-Oriented Variability Implementations[END_REF] proposes a graph visualization displaying the information output by its symmetrybased detection of variability implementations. Nodes represent classes, linked together by edges, being inheritance relationships. The color and size of a node evolve according to the number of constructor and method overloads respectively. symfinder was later extended to take into account usage relationships between classes with symfinder-2 [START_REF] Mortara | Extending the Identification of Object-Oriented Variability Implementations using Usage Relationships[END_REF] and the visualization was also extended by displaying such relationships as dashed arrows. Recently Mortara et al. [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities[END_REF] proposed VariCity, a visualization relying on the city metaphor to display the information from symfinder-2. An example of generated visualization is shown in fig. 2. As with CodeCity and Evo-Streets, a class is represented by a building. The dimensions, however, represent the class-based metrics related to variability (cf. section 3.1). Streets departing from a building represent a usage relationship between this class and every other class whose building is on the street. Therefore, the discernible classes are the ones concentrating variability implementations. For example, FilterFactoryImpl is shaped as a skyscraper due to an important number of method overloads (141). Its goal is to create filters allowing to select zones from a map 6 . The large strategy is Query (10 constructors), which uses filters to query information from a data source. On the opposite, FilterVisitor is not very variable in itself but uses all the implemented filters, in the blue dotted box, noticeable by being a long street. Coloring the hotspot classes not only emphasizes the filters having more variants, but also exhibits some isolated classes, for example NumberRange, which implements a numerical range of values. On the opposite, the two red classes exhibited in fig. 1 because of their too high cyclomatic complexity (gml311.DocumentRootImpl and gml311.Gml311PackageImpl) are not visible in fig. 2 as they are not part of zones concentrating variability implementations. More details on the organization of the visualization are given in section 3.2. VariCity, however, does not display information related to the software quality of the displayed classes.

Summary. Consequently, to the extent of our knowledge, no solution exists to visualize at the same time, for an OO system, its variability implementations, and quality metrics over them. As the cities of VariCity and Evo-Streets are shaped differently, the simultaneous usage of both visualizations would be cumbersome, especially when experimenting with multiple metrics. This thus calls for a unified but customizable visualization and we propose to extend VariCity to incorporate quality metrics over a variabilitycentric visualization.

BACKGROUND

In this section, we give background details on how OO variability implementations are identified and how VariCity, which we extend in this work, exploits this information to provide a dedicated visualization.

Identification of OO variability implementations

The concept of symmetry has been studied in software [START_REF] Coplien | Commonality and Variability in Software Engineering[END_REF][START_REF] Coplien | Symmetry Breaking in Software Patterns[END_REF], and especially in mechanisms of object-orientation, such as inheritance, overloading, and design patterns, which can all be interpreted as forms of symmetry [START_REF] James O Coplien | Toward a General Formal Foundation of Design-Symmetry and Broken Symmetry[END_REF][START_REF] Zhao | Understanding symmetry in objectoriented languages[END_REF]. Taking a codebase as a whole, Tërnava et al. [START_REF] Tërnava | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF] have shown that these implementation techniques can be seen as local symmetries, which allow a part of code to change while another part remains unchanged. Detecting seven techniques (class as type, class subtyping, method and constructor overloading, strategy, template, decorator, and factory patterns) in Java and C ++ code with the symfinder toolchain [START_REF] Mortara | Identifying and Mapping Implemented Variabilities in Java and C++ Systems using symfinder[END_REF][START_REF] Mortara | symfinder: A Toolchain for the Identification and Visualization of Object-Oriented Variability Implementations[END_REF], the authors have also shown that the location where they are detected (mainly classes) represent accurate potential vp-s and variants [START_REF] Tërnava | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF].

The identification is facilitated in zones where variability implementation is dense because several techniques are used together, or a technique is heavily used (e.g., many methods being overloaded) in a set of classes related by their usages (e.g., one being attribute or method parameter of another) [START_REF] Mortara | Extending the Identification of Object-Oriented Variability Implementations using Usage Relationships[END_REF]. These zones have been defined as hotspots in the last version of the symfinder toolchain [START_REF] Mortara | Extending the Identification of Object-Oriented Variability Implementations using Usage Relationships[END_REF][START_REF] Tërnava | Identification and visualization of variability implementations in object-oriented variability-rich systems: a symmetry-based approach[END_REF] with direct relation to the computed variability metrics7 (e.g., number of overloaded methods, number of subclasses). A follow-up work has also shown that the detected OO variability implementations can be successfully mapped to domain features when they are available [START_REF] Mortara | Mapping Features to Automatically Identified Object-Oriented Variability Implementations -The case of ArgoUML-SPL[END_REF].

Visualization support in VariCity

3.2.1 Visualization dimensions. In VariCity, the city representing the system is organized to exhibit the classes concentrating variability implementations. A tall building shows an important number of method variants (e.g., FilterFactoryImpl in fig. 2), whereas a large building shows an important number of constructor variants (e.g., Query), exhibiting variability concentration at method level inside a class. Identified design patterns have a crown on their building (e.g., FilterFactoryImpl is a Factory, whereas Query is a Strategy) 8 . The placement of the buildings by decreasing order of width on both sides of the street allows for exhibiting density between classes. Additional usage relationships are represented as underground streets, and inheritance relationships as aerial links, both displayed when hovering a building. Finally, classes being part of hotspots are displayed in color (vp-s in yellow and variants in blue) to make them easily noticeable.

Configuration capabilities of the visualization.

Three parameters allow configuring the view. First, some classes selected by the user to represent points of interest of a system (e.g., API endpoint, . . . ) can be defined as entry point classes to start its exploration. Then, the usage orientation determines whether buildings on a street are using the class initiating the street (orientation IN), or used by it (orientation OUT), or both (orientation IN/OUT). Finally, the usage level can be set to define the maximum number of hops to be traversed in the usage relationships from the studied classes (starting from entry points) to other classes to be displayed. With a usage level of 𝑛, all classes distant from an entry point by 𝑛 usage relationships will be displayed.

The city is shaped by first aggregating the entry point classes on a red street. Then, starting from them, classes using (or being used by) them up to the usage level set are displayed. For example, a visualization set up with one entry point, usage orientation IN, and usage level of 2 will display the entry point, the classes using the entry point, and the classes using these classes. To generate fig. 2, VariCity has been configured to use SimpleFeatureSource9 and MapContent10 as entry points. The usage orientation has been set to OUT, and the usage level to 4.

VARIMETRICS: EXPLORING THE QUALITY OF VARIABILITY IMPLEMENTATIONS

As shown in section 2.2, although state-of-the-art approaches allow visualizing either the density of variability implementations (e.g., with VariCity [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities[END_REF]) or quality metrics (e.g., with CodeCity [START_REF] Wettel | CodeCity: 3D visualization of largescale software[END_REF] or Evo-Streets [START_REF] Steinbrückner | Understanding software evolution with software cities[END_REF]), no existing approach allows the simultaneous representation of both aspects of OO software systems. Therefore we adapt VariCity to display information about quality in the city.

Main principles

Although VariCity's configuration capabilities detailed in section 3.2.2 allow to shape the city and show a desired subpart of the project, it is not possible to configure the displayed variability metrics (i.e., the number of method overloads for the height, and the number of constructor overloads for the base). VariMetrics, however, aims to focus the expert on the quality-critical zones concentrating variability implementations. State-of-the-art proposes a plethora of quality metrics to measure several properties of a software system [START_REF] Nur | Software product quality metrics: A systematic mapping study[END_REF], ranging from the architecture [START_REF] Varela | Source code metrics: A systematic mapping study[END_REF] to the source code level [START_REF] Thomas | A complexity measure[END_REF][START_REF] Stevanetic | Software metrics for measuring the understandability of architectural structures: a systematic mapping study[END_REF]. Since no metric is relevant for all software systems due to the elusive definition of quality [START_REF] Kitchenham | Software quality: the elusive target [special issues section[END_REF], software practitioners need to pick and combine different metrics to obtain a quality measure relevant for their use case. VariMetrics extends the configuration of VariCity so that experts can choose the quality metrics they want to display, and how to combine them, to tailor the visualization according to their needs. By default, VariCity displays in yellow vp-s being hotspots, in blue variants being hotspots, and in grey classes not being hotspots (fig. 3a). On their side CodeCity and Evo-Streets color the buildings to expose properties inherent to the classes [START_REF] Steinbrückner | Representing development history in software cities[END_REF][START_REF] Wettel | Visually localizing design problems with disharmony maps[END_REF]. We thus propose two coloring strategies for quality metrics: a coloration following a red-to-green sequence (fig. 3b), and a saturation keeping the original colors of the buildings and lightening or darkening them (fig. 3c). While VariMetrics should enable some combination of metrics, combining both coloring strategies leads to bivariate chromatic maps, which are known to be difficult to read [START_REF] Wainer | An empirical inquiry concerning human understanding of two-variable color maps[END_REF]. On the opposite, applying textures on colors has shown to be an efficient way to display multiple software quality metrics [START_REF] Holten | Visual realism for the visualization of software metrics[END_REF]. We hence provide a crackled texture (fig. 3d) variably covering the building, thus enabling views simultaneously exhibiting two quality metrics.

These three visual properties are configurable to be adapted to the metric they represent, as some quality metrics are symptoms of lower quality if they have a high value (e.g., complexity) but other metrics with such values may instead indicate good quality (e.g., test coverage). Analogously, not all projects have similar ranges of values for the same metric, and proposing a fixed range of values may not allow revealing a difference of quality in some projects, thus VariMetrics allows to specify these ranges.

Determining relevant quality metrics for OO variability debt

OO variability debt identification does not only require an appropriate visualization but also adequate metrics to be exploited in the visualization. Wolfart et al. [START_REF] Wolfart | Variability Debt: Characterization, Causes and Consequences[END_REF] introduced a catalog of ten forms of variability debt, detailing for each of them its cause(s), consequence(s), and concerned type(s) of artifacts. In the following analysis, these forms are written in italics.

As OO variability implementations rely solely on standard OO mechanisms, the availability of the source code is the only requirement to identify them. Finding Code duplication is therefore possible, as well as System-level structure quality issues in the implementation. Most often, tests sources are provided along with the source code, enabling identification of Lack of tests.

However, other information is not always available, especially in the case of open-source systems, such as the documentation, leaving aside Out-of-date or incomplete documentation and Duplicate documentation. Identifying Architectural anti-patterns needs information on the domain and the associated design choices (e.g., we cannot say if a Strategy pattern has the desired behavior solely by analyzing its structure). Covering Poor test of feature interactions would require a list of features and their mapping with their implementations, which are often not available in our case, while covering Old technology in use and Multi-version support implies having information about the versions of the supporting language and used libraries. Finally, identifying Expensive tests implies determining whether test cases have been formally defined or not [START_REF] Muhammad | Exploratory testing as a source of testing technical debt[END_REF], thus requiring test cases definitions.

It results that relying on the source code and its tests, we can cover Code duplication, Lack of tests, and System-level structure quality issues in the implementation. Hence, we need to determine quality metrics to identify these types of variability debt. A common metric to identify a lack of tests is the code coverage, which can be measured at different granularities (line, condition, . . . ). For our evaluation, we opted for a coverage metric that aggregates measures for different granularities. Similarly, code duplications are commonly identified at two levels of granularity: line or block. We advocate that blocks are more likely to represent duplicated code related to variability than a single line of code. Finally, structure quality issues in the codebase impact maintainability and evolution of the system. Even though code duplication and lack of tests impact maintainability and evolution of the system, the understanding of the implementation by the maintainers of the project is also an important aspect, and cognitive complexity [START_REF] Campbell | Cognitive complexity: An overview and evaluation[END_REF] appears to be relevant for this purpose [START_REF] Peitek | Program Comprehension and Code Complexity Metrics: An fMRI Study[END_REF]. We thus choose as relevant metrics for our evaluations duplicated blocks, test coverage, and cognitive complexity.

Most often, standard tools for measuring software quality metrics also determine technical debt measures giving an estimation of the effort, as a duration, to fix the identified code smells [START_REF] Paris C Avgeriou | An overview and comparison of technical debt measurement tools[END_REF]. We did not use such measures in our evaluation for multiple reasons. First, by providing an aggregated duration, this measure is more helpful in estimating effort at the management level, but it does not describe the real causes of the debt. Then, some first empirical results seem to indicate a possible inaccuracy in the given values [START_REF] Teresa Baldassarre | On the diffuseness of technical debt items and accuracy of remediation time when using SonarQube[END_REF], and exploiting such metrics may therefore require some knowledge of the system and its implementation, which we do not have for our subject systems. Nevertheless, VariMetrics allows visualizing this metric if the experts find it relevant.

Figure 4 shows the VariCity view of fig. 2 in VariMetrics showing the cognitive complexity using the red-to-green color scale. Where the classes concentrating variability implementations revealed by VariCity (cf section 3.2) remain visible independently of their quality (e.g., FilterFactoryImpl or NumberRange), VariMetrics also exposes quality-critical classes, being variable (e.g., Query or FilterToSQL) or not (e.g., Hints or SimplifyingFilterVisitor).

Implementation

The symfinder toolchain, used by VariCity to identify the variability implementations and compute the related variability-related metrics, has been extended to support fetching of the quality metrics and their mapping with the identified variability information. If a SonarCloud account exists for the system, metrics are fetched by using the SonarCloud Web API 11 . Otherwise, a SonarQube server is executed locally to extract the metrics while running the symfinder analysis. The symfinder configuration has been extended to specify wherever running a SonarQube instance is needed or not.

EVALUATION

The evaluation of VariCity presented by Mortara et al. [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities[END_REF] validates its capacity to exhibit zones in the code concentrating mechanisms used in OO variability implementations (cf. section 3.1). VariMetrics should therefore be able to reveal the subset of these classes having quality issues. To evaluate VariMetrics against the requirements expressed by section 2.1 (i.e., identifying variability implementations for which quality metrics are problematic), we apply our approach 11 https://sonarcloud.io/web_api to multiple open-source systems. We select views with metrics combinations revealing the variability implementations that are shown by VariCity while being the most quality-critical (section 5.1). We then validate the relevance of such classes by applying maintenance actions on these classes within one project, JFreeChart (section 5.2), and show the impact on the view of the project.

Quantitative evaluation

Subject systems. We used for this evaluation 7 variability-rich open-source Java systems of various sizes, depicted in table 1. Five of them were chosen as their documentation clearly states they implement variability: Azureus (Vuze) is a BitTorrent client which supports multiple network communication protocols, GeoTools a library for geospatial data management providing multiple tools and filtering capabilities to manipulate maps, JKube, a Maven plugin to generate different types of container images, OpenAPI Generator, a library to create APIs for a plethora of programming languages, and the Spring framework, providing a Java-based support for components and services with many different plugins, on persistence management, validation, security, etc. We also picked the Java Development Kit (JDK) for its large size of ~2.5M LoC to evaluate the scalability of our approach. Finally, we also used JFreeChart, a charting library used as a subject system in the evaluation of VariCity by Mortara et al. [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities[END_REF], as its size enables us to master the implemented variability at a fine granularity. Five projects are forks from their original repositories in the Corpus-2021 GitHub organization 12 , designed by Irrazábal et al. [START_REF] Irrazábal | Modelo para curaduría de proyectos software de fuente abierta para estudios empíricos en ingeniería de software[END_REF] to serve as a catalog of software projects to analyze their metrics. They provide a SonarCloud instance for these projects 13 , allowing us to reuse these metrics for our study. Two others have also a SonarCloud instance and JFreeChart is the only one for which we had to use our prototyped setup with Sonarqube to obtain the quality metrics. Besides, the JFreeChart's build configuration was also adapted to be analyzed by a local SonarQube instance [START_REF] Mortara | Customizable Visualization of Quality Metrics for Object-Oriented Variability Implementations -Artifact[END_REF].

Evaluation process. We first generated for each project a visualization with VariCity following the same stages as in the VariCity's evaluation [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities[END_REF]. After determining entry points by selecting important classes after exploring codebases and documentations, we experimented empirically with different combinations of usage level and usage orientation to obtain a visualization we consider relevant (i.e., exhibiting classes detaching from others because they concentrate variability implementations). We finally identified manually on each view the classes that are the most visible for us (by being a hotspot or a design pattern, or due to their dimensions) to obtain a set of "noticeable classes w.r.t. variability". For example, for GeoTools (fig. 2), classes such as FilterFactoryImpl, FilterToSQL, Query, and NumberRange draw attention due to their size and/or the fact that they are hotspots, as opposed to FilterVisitor.

To determine a relevant VariMetrics view, we systematically applied all available metrics on each project and selected the ones being relevant to identifying OO variability debt (cf. section 4.2). During this step, it happened that no building stood out for a metric (i.e., no class exhibits variability debt), suggesting that the overall quality is decent w.r.t. this metric. On the opposite, if all classes appear as quality-critical, it may indicate that this metric has been neglected in quality requirements for the project as a whole. We thus restrained in this evaluation the set of significant metrics 12 https://github.com/Corpus-2021 13 https://sonarcloud.io/organizations/corpus-2021/projects relevant to identify OO variability debt to those showing some differences in quality between classes. Table 1 summarizes for each system the relevant metrics being available and significant. We then manually identified on the views the classes appearing to be quality-critical, regardless of their variability, by enumerating the classes that appeared to be the most cracked and/or red to obtain a set of "noticeable classes w.r.t. criticality". For example, for GeoTools (fig. 4), Hints, Query, SimplifyingFilterVisitor, and FilterToSQL are easily discernible. The quality-critical and variability intense classes of the project thus correspond to the intersection between the two sets of classes (i.e., in this example, FilterToSQL and Query).

In all observed systems, it appears that although fewer classes are noticeable w.r.t. criticality than w.r.t. variability, there is no direct relation between variability and quality, as it can already be seen in fig. 4. Whereas some vp-s have an important number of variants, they can be reliable, such as FilterFactoryImpl in GeoTools, and thus do not need particular attention. On the opposite, some critical classes may not concentrate variability implementations, such as Hints in GeoTools, and they are therefore less important for maintaining the functional code. This shows that, in the studied systems, visualizing both variability and quality is useful to determine quality-critical variability implementations. To evaluate to which extent, we calculated for each project the number of noticeable classes w.r.t. variability, w.r.t. criticality, and w.r.t. both aspects. The results with the configuration for each view are reported in table 2. This shows that representing on a single view variability and quality information allows reducing the number of classes appearing as relevant on the visualization between 50% (JKube) and 91% (Spring framework) compared to the VariCity visualization. We believe the mildly encouraging results obtained on JKube come from its size, so that less variability intense zones have been identified by VariCity compared to larger projects. An important number of classes are also noticeable in this project as it has globally a low code coverage. Besides, by adapting the thresholds on which the hotspot detection relies, we could obtain fewer zones and better results, but we consider these experiments as out of the scope of this paper. The definition of a hotspot is elusive [START_REF] Mortara | Extending the Identification of Object-Oriented Variability Implementations using Usage Relationships[END_REF] and determining whether a class is a hotspot or not depends on user-defined thresholds, a limitation already evoked in the work on VariCity [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities[END_REF]. Nevertheless, we consider these results as satisfying, because without VariMetrics, finding OO variability debt would have needed to manually map relevant classes on the VariCity view to their metrics, which, already on the smallest project being JKube, represents 28 classes.

Summary. By representing OO variability implementations and quality metrics in a unified representation, VariMetrics not only allows to visualize both classes concentrating variability implementations and critical classes, but also to focus on specific zones of OO variability debt.

Qualitative evaluation

Identifying technical debt helps to understand where to apply maintenance actions aiming to improve software quality. Therefore, if zones of variability debt identified by VariMetrics are relevant, correcting identified weaknesses should improve the project quality, and the effects should be visible in the visualization. To validate the relevance of these zones, we conduct an experiment in which we apply modifications to the identified classes in one project, JFreeChart.

Subject system. We chose JFreeChart as a subject system not only for its intermediate size allowing an easy discovery of the codebase, but also because this system has been extensively studied in previous work from VariCity's authors [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities[END_REF][START_REF] Tërnava | Identification and visualization of variability implementations in object-oriented variability-rich systems: a symmetry-based approach[END_REF][START_REF] Tërnava | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF], where they provide details on the implemented variability.

Evaluation process. We first selected in the set of 10 critical variability intense classes determined in the quantitative evaluation (cf. table 2) the ones maximizing their number of duplicated blocks or minimizing their test coverage. Six classes remained, of from CategoryPlot is duplicated in XYPlot). In this case, the factorization was placed in another class, created for that purpose (here, CategoryXYCommon). Regarding classes lacking tests, new test cases for several methods that were little to not tested have been added to the existing test classes. To ensure as much as possible that our modifications did not hamper the system stability, we did not change the logic of existing tests and made sure that the project could build with all tests passing. A first observation we made concerns the nature of the duplicated blocks. Whereas some duplications are pure technical debt in classes concentrating variability implementations, others clearly correspond to improperly managed variability implementations. For example, in DateAxis, multiple lines of the refreshTicksHorizontal 14 method are duplicated in refreshTicksVertical 15 . They correspond to the common part creating the time tick, whereas the variable part concerns the orientation of the text on the plot. Therefore, such zones exhibited by VariMetrics actually spot improper variability management. We reapplied VariMetrics on the new codebase [START_REF] Mortara | Customizable Visualization of Quality Metrics for Object-Oriented Variability Implementations -Artifact[END_REF] and observed the differences shown in figs. 5b, 6b and 7b. We also computed the test coverage, cognitive complexity, and number of duplicated blocks for all the classes impacted by our maintenance actions before and after their modification, and summarized these results in table 3.

Regarding the classes suffering from code duplications, evolutions can be observed in figs. 5 and 6. The disappearance of the cracks on NumberAxis and DateAxis suggests that very little to no duplication remains, while the reduced amount of cracks on 14 https://github.com/jfree/jfreechart/tree/v1.5.0/src/main/java/org/jfree/chart/axis/ DateAxis.java#L1558-L1609 15 https://github.com/jfree/jfreechart/tree/v1.5.0/src/main/java/org/jfree/chart/axis/ DateAxis.java#L1676-L1726

CategoryPlot denotes a decrease of duplications while some are still present. Finally, XYPlot appears equally cracked, propounding that duplications are still present. These observations are confirmed by the values from table 3: duplications in NumberAxis and DateAxis have been reduced by 75% and 100%, leaving respectively 4 and 0 duplications. Although the number of duplications in CategoryPlot diminished by 29%, 16 duplicated blocks remain, representing a non-negligible amount. Finally, 3 duplications have been removed in XYPlot, representing 13% of reduction, that is not significative enough to be shown on the visualization.

Similarly, improvements can also be seen in the classes that were lacking tests (fig. 7b). The transition from 31% to 91% of coverage for ChartEntity is translated on the visualization by a bright green color for its building, where the more contained improvement on ChartPanel's coverage leads to its building color changing from orange to yellow.

Another effect induced by these maintenance actions can be seen in the visualization. The crack on ChartPanel's building visible in fig. 7a disappeared in fig. 7b, although removing duplications was not a maintenance action for this class. This is because testing some methods required splitting them, leading to smaller blocks that could be reorganized. In this case, three duplicated blocks were extracted in a single testable method.

Finally, it appears that the maintenance actions on these classes improved their quality w.r.t. the considered metrics (i.e., coverage and duplicated blocks). These changes however did not only impact the six considered classes, but also three other existing classes having duplications and led to the creation of three new classes to host some duplications. It is therefore important to consider these classes and ensure that they do not express the variability debt that has been treated. Modifications applied to the already existing classes solely concern the removal of duplications, therefore their quality has also been improved. Regarding the newly created classes, they are now visible (cf. figs. 5b and 6b). DatePeriodCommon's yellow color presents a relatively low test coverage of 46%, which can be explained by the low initial test coverage of PeriodAxis of 29.3%. Adding tests would help to solve the issue. The other two classes have high coverages above 70%, and none of the three classes has a cracked texture, showing that no variability debt related to these metrics has been created.

By presenting the coverage and the number of duplicated blocks, the visualizations exhibited in figs. 5 to 7 can only demonstrate variability debt related to those two metrics. However, as explained in section 4.2, cognitive complexity is also a factor of variability debt. As this metric is significant for JFreeChart (cf. table 1), it is thus important to evaluate its evolution. It appears in table 3 that the cognitive complexity globally decreased for all relevant classes and the other already present ones. This can be explained by the fact that removing code duplications and adding tests often implies splitting methods into smaller ones, thus reducing cognitive complexity. This decrease can also be observed using VariMetrics, as its configuration capabilities easily allow to adapt the view to display this metric (cf. fig. 8 with an intensity decrease on DateAxis and NumberAxis). Concerning the newly created classes, CategoryXYCommon's important cognitive complexity of 97 is because CategoryPlot and XYPlot have major cognitive complexities of 503 and 666 respectively. Therefore, the factorized blocks are themselves complex, and would need further refactoring (e.g., splitting into separate methods) to reduce this complexity and remove its 6 duplicated blocks.

Summary. By implementing maintenance actions on the identified quality-critical variability intense classes, we improved their quality regarding the considered metrics without introducing new debt factors, leading to a positive impact at the project level. These changes are also clearly observable in the visualization. Moreover, part of the identified variability debt directly concerned roughly managed variability that could be refactored.

THREATS TO VALIDITY AND LIMITATIONS

As we did not conduct an empirical evaluation, the major threat of our work is related to the design and realization of the evaluations done by ourselves, including the configuration of the views and choice of the metrics. Nevertheless, the scenarios demonstrating VariCity [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities[END_REF] gave us insights into the criteria to design views exhibiting relevant variability implementations. The metrics choice was driven by recent work on the factors causing variability debt [START_REF] Wolfart | Variability Debt: Characterization, Causes and Consequences[END_REF], giving us confidence in their relevance in our context. Moreover, as the views we obtained allowed us to obtain positive results, we expect real experts to obtain good outcomes on their systems by applying their settings.

We evaluated our approach on 7 systems. Although this dataset is small, the studied systems have various sizes (40k → 2.5M LoC) and architectures (API, standalone library. . . ), and represent different domains (charting, programming language, geospatial data management. . . ). We are thus confident in the applicability of our results to other Java-based systems.

Regarding the visualization, we chose to offer as many configuration capabilities as possible to the expert so that they can tailor it freely and reach the view that helps them most. Combining multiple metrics on different axes can yet induce cognitive load and hamper the view's understanding. While measuring this load is of prime importance when designing visualizations [START_REF] Huang | Measuring effectiveness of graph visualizations: A cognitive load perspective[END_REF] including city-based ones [START_REF] Caserta | 3D hierarchical edge bundles to visualize relations in a software city metaphor[END_REF][START_REF] Dashuber | A Layered Software City for Dependency Visualization[END_REF] to ensure readability and usability, it would require in our case to empirically validate our approach with real experts to exchange on their needs 16 . This is part of our future work.

As for scalability, the analysis part is directly related to symfinder capabilities, which can handle projects with several millions of LoC but takes hours to do so (more than 120h for the JDK as shown in table 4). As the analysis can be synchronized with main releases, this is still reasonable for such very large projects. On the rendering side, our extension of VariCity only configures coloring and adds some textures, which are negligible for the rendering time. We are thus dependent on the main bottleneck of VariCity rendering, which lies in the computation of the city shape and streets (more than 5 five minutes for the JDK). For very large projects, this is hampering the configuration of the view as recomputation must be done when usage orientation and levels are changed. Nevertheless, from our analysis of the algorithm used in VariCity, we believe that some significant improvements could be made to make (re-)rendering practicable. 16 Such a validation would also exhibit potential accessibility issues that can be tackled by extending the existing configuration capabilities.

CONCLUSION

When object-oriented variability-rich software systems implement variability in a single codebase, they rely on mechanisms from the supporting language to realize it (i.e., inheritance, overloading, design patterns), making them prone to induce variability debt. Identifying its causes is essential for software maintenance and quality. In this paper, we proposed VariMetrics, an extension of the city-based VariCity visualization to support the organized display of OO quality metrics as additional visual properties in a city in which dense zones of highly visible buildings already show zones of potential variability implementations. Multiple additional options allow the user to configure the view by choosing and combining the desired metrics to match their definition of quality. We conducted a quantitative evaluation on several open-source systems and a deeper qualitative evaluation on one of them, showing how Vari-Metrics can help to distinguish quality-critical zones of variability implementations.

We expect VariMetrics to be a first step towards a better understanding of variability debt in the context of variable OO systems. As future work, we plan to first explore how some code smells such as code duplication can be related to a form of badly implemented variability implementations, to improve quality. We will also conduct an empirical evaluation with experts to better understand how VariMetrics could be extended to match the industry's needs and expectations.

OPEN SCIENCE

A reproducible artifact is available online as an archive [START_REF] Mortara | Customizable Visualization of Quality Metrics for Object-Oriented Variability Implementations -Artifact[END_REF] containing the source code of VariMetrics, the Excel file used to obtain the data presented in table 2, additional views for all projects presented in table 2, the codebases of JFreeChart before and after the refactor presented in section 5.2 (with the corresponding diff file, excerpts of the SonarQube analysis of both codebases showing the information presented in table 3. These information can also be found on a companion webpage 17 .

Figure 1 :

 1 Figure 1: Views of GeoTools, using cyclomatic complexity as footprint, # LoC as height, and complexity as color.

Figure 2 :

 2 Figure 2: VariCity visualization of GeoTools.

Figure 3 :

 3 Figure 3: Visual properties used to display quality metrics compared to the original VariCity visualization.

  org.geotools.filter. FilterFactoryImpl org.geotools.data.Query org.geotools.util.factory.Hints org.geotools.util.NumberRange org.geotools.data.jdbc.FilterToSQL org.geotools.filter.visitor. SimplifyingFilterVisitor org.opengis.filter.FilterVisitor

Figure 4 :

 4 Figure 4: Figure 2 in VariMetrics. The view is configured to display the cognitive complexity using the red-to-green color scale.

Figure 5 :

 5 Figure 5: View of XYPlot and CategoryPlot before and after the refactor. Block duplications are displayed on the redgreen scale (range: 0 → 50 blocks) and test coverage using the crackled texture (range: 0% → 100%).

Figure 6 :

 6 Figure 6: View of DateAxis and NumberAxis before and after the refactor. Visualization settings are identical to fig. 5.which four suffer from code duplication (CategoryPlot, XYPlot, DateAxis, and NumberAxis, visible due to their extensively cracked texture on fig.5afor the first two and on fig.6afor the last two) and two others from a lack of tests (ChartPanel and ChartEntity, visible due to their orange and yellow colors on fig.7a).We then defined and applied maintenance actions for these classes. Regarding classes suffering from code duplication, duplicated blocks were factorized in new methods. It happened that block duplications were present in different classes (e.g., behavior

Figure 7 :

 7 Figure 7: Classes lacking tests before and after the refactor. Visualization settings are identical to fig. 5.

Figure 8 :

 8 Figure 8: Figure 6 displaying cognitive complexity on the red-green scale instead of the coverage (range: 0 → 150).

Table 1 :

 1 Subject systems and their available metrics.

	Project	Version	Java LoCs variants DB COMP COV # vp-s / Available metrics
	Azureus	5.7.6.0	633,248	10,105	A	S	✗
	GeoTools	23.5	1,312,727	22,534	A	S	✗
	JDK	17-10	2,434,983	71,489	S	S	✗
	JFreeChart	1.5.0	94,203	2,849	S	S	S
	JKube	1.7.0	40,952	795	A	S	S
	OpenAPI Generator 5.4.0	88,172	768	S	S	S
	Spring framework	5.2.13	662,579	12,622	A	S	✗
	DB -duplicated blocks, COMP -cognitive complexity, COV -coverage
	✗ -unavailable metric, A -available metric, S -significant metric (available and
	showing differences between classes)

Table 2 :

 2 Number of noticeable classes due to their variability concentration, criticality, and both aspects for the given views on all subject systems.

		View configuration				Noticeable classes w.r.t.
	Project	Entry point classes	Usage Usage orientation level (visual property) Metrics	variability criticality both
	Azureus	com.aelitis.azureus.core.AzureusCoreComponent	OUT	4 COMP (red-green)	74	32	12
	GeoTools	org.geotools.data.simple.SimpleFeatureSource org.geotools.map.MapContent	OUT	4 COMP (red-green)	104	27	18
	JDK	java.net.URI java.net.URL	IN	1	COMP (red-green) DB (cracks)	84	17	13
	JFreeChart	org.jfree.chart.JFreeChart org.jfree.chart.plot.Plot	OUT	4	COV (red-green) DB (cracks)	35	31	10
	JKube	org.eclipse.jkube.generator.api.support.BaseGenerator org.eclipse.jkube.generator.javaexec.JavaExecGenerator org.eclipse.jkube.generator.api.Generator	IN/OUT	7	COV (red-green) COMP (cracks)	28	115	14
	OpenAPI Generator org.openapitools.codegen.languages.OpenAPIGenerator	IN/OUT	6	COV (red-green) COMP (cracks)	77	51	21
	Spring framework	org.springframework.beans.factory.parsing.BeanComponentDefinition org.springframework.beans.factory.support.AbstractBeanFactory	IN	8 COMP (red-green)	57	13	6

Table 3 :

 3 Measures of the refactored and added classes, before and after the refactor.

	Class name (in the org.jfree.chart package)	Coverage	# duplicated blocks complexity Cognitive
		Identified relevant classes
	plot.CategoryPlot	before after	74.9% 75.4%	23 16	503 392
	plot.XYPlot	before after	70.0% 69.9%	24 21	666 603
	axis.DateAxis	before after	71.8% 77.2%	10 0	201 139
	axis.NumberAxis	before after	78.7% 77.8%	12 4	163 127
	entity.ChartEntity	before after	30.7% 90.5%	0 0	26 26
	ChartPanel	before after	25.7% 52.2%	7 2	322 295
		Other already present classes
	axis.LogarithmicAxis	before after	16.0% 17.1%	4 0	315 281
	axis.LogAxis	before after	45.3% 47.0%	10 7	92 87
	axis.PeriodAxis	before after	29.3% 30.6%	2 1	112 104
		Added classes
	plot.CategoryXYCommon	before after	-77.4%	-6	-97
	axis.DatePeriodCommon	before after	-46.2%	-0	-8
	axis.NumberLogCommon	before after	-81.6%	-0	-5
	Overall project	before after	54.5% 55.3%	604 565	15,858 15,622

Table 4 :

 4 Subject systems and their execution times. Ubuntu 18.04.2 LTS with Intel Xeon CPU E5-2637v2 @ 3.5GHz and 128Go memory. System for VariMetrics: Google Chrome 99.0.4844.84 on Arch Linux 5.16.16-arch1-1 with Intel i7-9850H (12 cores) @ 4.6GHz and 32Go memory.

	System	symfinder execution VariMetrics city rendering
	Azureus	1 h 25 min	4 s
	GeoTools	24 h	1 min 10 s
	JDK	123 h 22 min	5 min 40 s
	JFreeChart	5 min 13s	1 s
	JKube	2 min 8 s	< 1 s
	OpenAPI Generator	3 min 45 s	< 1 s
	Spring framework	1 h 5 min	6 s
	System for symfinder:

https://www.sonarqube.org/

https://www.sonarqube.org/

https://sonarcloud.io/explore/projects

https://softvis3d.com/

https://www.geotools.org

https://docs.geotools.org/latest/userguide/library/main/filter.html

It must be noted that these metrics are used to identify variability, but are not quality metrics like code complexity or test coverage.

Although design patterns often involve multiple classes, the crown is only present on the vp of the design pattern.

org.geotools.data.simple.SimpleFeatureSource

org.geotools.map.MapContent

ACKNOWLEDGMENTS

We thank Patrick Anagonou, Guillaume Savornin and Anton van der Tuijn for their contribution in the development of VariMetrics.


Bertrand François
email: bertrand.francois@hmg.inpg.fr

THERMO-PLASTICITY OF SOILS AT VARIOUS SATURATION STATES: A CONSTITUTIVE MODEL

This paper presents a highly-coupled thermo-plasticity model for unsaturated soils. The effect of temperature on the mechanics of unsaturated soils is briefly addressed. Then the equations of the developed model, so-called ACMEG-TS, are detailed. Finally, the model is validated by the means of comparisons with experiments. This constitutive model constitutes an effective tool for modelling the thermo-hydro-mechanical (THM) behaviour of geomaterials involved in the confinement of nuclear waste disposal.

Introduction

The geomaterials that will be involved in the confinement of radioactive waste in deep geological formations will be submitted to strong thermal, hydraulic, and mechanical modifications. Those modifications may produce a significant change of the characteristics of the confinement barrier, partially due to thermo-plasticity effects in the confining soil (Laloui et al., 2008). Following the need for understanding and quantifying such effects, a constitutive model that deals with the thermo-mechanical modelling of unsaturated soils is proposed (François and Laloui, 2008). In light of elasto-plasticity, this model is based on the relevant temperature and suction effects on the mechanical behaviour of finegrained soils, as observed in experiments [START_REF] Salager | Experimental investigations on temperature and suction effects on compressibility and pre-consolidation pressure of a sandy silt[END_REF].

Thermo-plasticity in soils

The thermal effects on the mechanical response of soils must be considered not only in terms of reversible phenomena, but also in term of thermo-plasticity. The predominant effect of temperature on the behaviour of fine-grained soils is the causation of successively lower void ratios with temperature increasing for a given stress level. The normally consolidated lines at different temperatures are parallel and shifted to the left with increasing temperature. As a consequence, in a normally consolidated state, the soil undergoes thermal hardening (i.e. densification) upon heating in order to reach the normally consolidated line corresponding to the current temperature. Under undrained conditions, the generation of pore water pressure upon heating is a consequence of a higher thermal expansion coefficient of water than of the mineral phase. Also, thermo-plastic processes may induce additional pore water pressure. Moreover, the deviatoric behaviour of soils may also be affected by temperature variations [START_REF] Hueckel | Explaining thermal failure in saturated clays[END_REF].

In addition to the effect of temperature on the saturated soils, the unsaturated conditions bring additional thermo-hydro-mechanical couplings in the materials. In particular, the water retention capacity of soils decreases with increasing temperature. The retention curves, expressed in the degree of saturation vs suction axis, are shifted to the left with increasing temperature, mainly because the interfacial tension between the water and the grains decreases as temperature increases. This thermal effect indirectly influences the mechanical response of the soils by changing the suction value for the same degree of saturation.

From an experimental study of the combined effects of suction and temperature T on the preconsolidation pressure, [START_REF] Salager | Experimental investigations on temperature and suction effects on compressibility and pre-consolidation pressure of a sandy silt[END_REF] deduced logarithmic functions to describe the evolution of s c p′ with temperature and suction:

( ) [ ] { } [ ] { } [ ] { } 0 0 0 0 1 log / if , 1 log / 1 log / if c T e c c T s e e p T T s p s T p T T s s s γ γ γ ⎧ ′ - ≤ ⎪ ′ = ⎨ ′ - + ⎪ ⎩ s s ≥ (1)

The constitutive equations

The developed model uses the generalized effective stress approach, which aims to use a single stress to describe the mechanical behaviour of unsaturated soils through combinations of mechanical stresses and fluid pressures. This averaged stress variable converts a multi-phase porous media into a mechanically equivalent, single-phase, single-stress state continuum according to the following expression [START_REF] Bishop | The principle of effective stress[END_REF]:

( ) ( ) ij ij a ij r a w ij p S p p σ σ δ ′ = - + - δ (2)
where ij σ is the total external stress tensor, a p and w p the air and water pore pressures, respectively, ij δ Kroenecker's symbol and the degree of saturation.

r S

Mechanical scheme

The model, called ACMEG-TS, is based on an elasto-plastic-framework, the total strain increment dε being decomposed into non-linear, thermo-elastic, e dε , and thermo-plastic, p dε , components. The elastic part of the deformation is expressed as follows:

1 ,

e ij ijkl kl ij d E d d ε σ β - Τ ′ = - T (3)
The first term of Equation ( 3) is the contribution of the effective stress increment kl dσ ′ to the total elastic strain increment, through the elastic tensor ijkl E . According to Equation (2), this part may follow from total stress or fluid pressure variations. The second term of Equation ( 3) is related to the thermo-elastic strain of the material, through the thermal expansion coefficient vector, ( )

, 1 3 ij s ij β β δ Τ ′ = .
The plastic mechanism of the material is induced by two coupled hardening processes: an isotropic and a deviatoric one. Using the concept of multi-mechanism plasticity, both mechanisms may induce volumetric plastic strain. Therefore the total volumetric plastic strain rate p v dε is the coupling variable linking the two hardening processes. The yield functions of the two mechanical, thermo-plastic mechanisms have the following expressions (Figure 1):

; 1 0 iso iso dev dev c d p f p p r f q Mp b Log r p ⎛ ⎞ ′ ′ ′ ′ = - = - - = ⎜ ⎟ ′ ⎝ ⎠ (4)
where c p′ is the preconsolidation pressure. b , and d M are material parameters. c p′ depends on the volumetric plastic strain, p v ε , in addition to temperature and suction:

( ) (

, exp p c c v p p s T ) β ε ′ ′ = (5)
where β is the plastic compressibility modulus and ( )

, c p s T ′ is expressed in Equation (1)
. and are the degree of mobilization of the isotropic and the deviatoric mechanisms and are hyperbolic functions of the plastic volumetric strain induced by the isotropic and the deviatoric mechanisms, respectively [START_REF] Hujeux | Calcul numérique de problèmes de consolidation élastoplastique[END_REF]Laloui and François, 2008). iso r dev r

The flow rule of the isotropic mechanism is associated, while the deviatoric one is not, and they are assumed to take the following forms, respectively:

, , 1 1 ; 3 3 p p iso p dev p iso ii ij dev ij ij q q d d M Mp p λ ε ε λ α δ σ ⎡ ⎤ ⎛ ⎞ ∂ = = + - ⎢ ⎥ ⎜ ⎟ ′ ′ ′ ∂ ⎢ ⎥ ⎝ ⎠ ⎣ ⎦ (6)
where α is a material parameter. The plastic multipliers, p iso λ and p dev λ , are determined using the consistency equation.

Water retention scheme

In terms of water retention response, desaturation is also a yielding phenomenon. Hysteresis in water retention behaviour is modelled as a plastic process. As long as the soil is drying, suction increases, and the degree of saturation, , tends to decrease mainly when the air-entry suction is reached. Under re-wetting, a hysteretic phenomenon occurs, also represented by a yielding process (Figure 2). A wetting-drying cycle activates two successive yield limits in the (

0 ; 0 dry d wet d hys f s s f s s s = -= = -= (7)
where is the drying yield limit and a material parameter considering the size of the water retention hysteresis. Because air-entry suction of the materials depends on temperature and dry density, is a function of temperature and volumetric strain (François and Laloui, 2008):

d s hys s d s ( ) [ ] [ ] { } 0 0 , 1 l o g l o g1 d v d T e v s T s T T ε θ θ = - - -ε (8)
where T

θ and e θ are material parameters describing the evolution of air-entry suction with respect to temperature and volumetric strain, respectively. If the initial state is saturated, the initial drying limit is equal to air-entry suction and increases when suction overtakes as follows:

Numerical simulations

The proposed model has been extensively validated with the results of different non-isothermal experiments under saturated and unsaturated conditions (François and Laloui, 2008;[START_REF] François | Thermo-plasticity of fine-grained soils at various saturation states: Application to nuclear waste disposal[END_REF]. In this section, comparison between numerical simulations and experimental results on compacted FEBEX bentonite is briefly proposed. Figure 3a compares the numerical simulations with oedometric compression tests at different suctions (T= 22°C). The initial strain observed at 0.1 MPa of net stress is due to the suction path from 127 MPa to the suction applied during compression. The subsequent compression paths clearly shows the enhancement of elastic domain when suction increases. Figure 3b reproduces the numerical simulation of oedometric compression tests at two temperatures under 127 MPa of suction. The initial strain observed for the path at 50°C is due to the temperature increase.

Conclusions

When a soil is simultaneously submitted to mechanical, hydraulic and thermal variations, several coupling effects are involved in its global THM response. Those interactions have been introduced in a unified constitutive framework, so-called ACMEG-TS, including two interconnected aspects (a mechanical and a water retention framework) linked through a generalized effective stress expression. This constitutive approach has been confronted with experimental results through numerical predictions which tend to proof the accuracy of the developed model. ACMEG-TS constitutes an effective constitutive tool for modelling the THM behaviour of geomaterials. In addition, the model has been properly implemented in a finite element code in order to study the behaviour of the soils that confine the nuclear waste [START_REF] François | Thermo-plasticity of fine-grained soils at various saturation states: Application to nuclear waste disposal[END_REF]François et al., 2008).

Figure 1 :

 1 Figure 1: Effect of (a) temperature and (b) suction on the shape of coupled mechanical yield limits.

  drying and wetting paths, respectively):

β

  is the slope of the desaturation curve in the ( ) ln r Ss plane (Figure2).

Figure 2 :

 2 Figure 2: Schematic representation of water retention curve modelling.

Figure 3 :

 3 Figure 3: Numerical simulations of oedometric compression tests of FEBEX bentonite at (a) different suctions and (b) different temperatures. Comparisons with experiments.


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

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

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

IDE-assisted visualization of indebted OO variability implementations

Keywords: Software and its engineering → Software product lines, Software reverse engineering, Object oriented architectures, • Human-centered computing → Visualization systems and tools software variability, technical debt, software visualization, quality metrics, object-oriented systems, reverse-engineering

Object-Oriented (OO) variability-rich software systems often implement their variability in a single codebase, using the mechanisms provided by the host language (i.e., inheritance, overloading, design patterns). This variability is not documented and buried deep down in the code, thus impeding its identification and making it especially prone to variability debt at the code level. While this kind of variability implementation can now be detected, visualization support such as VariCity helps architects and developers understand the implemented variability using a city metaphor. In this paper, we demonstrate VariMetrics-IDE, an extension of VariCity that allows to visualize multiple quality metrics (e.g., code complexity, test coverage) together with the variability implementations, while supporting navigation between the source code and the visualization in an IDE. This extension thus facilitates the identification of zones of variability implementations with variability debt.

INTRODUCTION

When they reach a larger scale, sofware systems mainly become variability-rich [START_REF] Galster | Variability-Intensive Software Systems: Product Lines and Beyond[END_REF] and use various mechanisms to implement their variability. Introducing additional complexity, these variability implementations are difficult to understand, maintain and test, which leads to technical debt [START_REF] Li | A systematic mapping study on technical debt and its management[END_REF]. The debt caused by variability implementations has been defined as variability debt, while its different forms are still to be determined Wolfart et al. [START_REF] Wolfart | Variability Debt: Characterization, Causes and Consequences[END_REF]. Not following the Software Product Line (SPL) paradigm, many object-oriented (OO) systems implement their variability in a single codebase, using the traditional OO mechanisms (i.e., inheritance, overloading of methods and constructors, design patterns) [START_REF] Capilla | Systems and software variability management[END_REF]. The variability is then intertwined with the structure and implementation of the business code, and without traceability to the domain knowledge, the identification and understanding of these variability implementations are hindered [START_REF] Tërnava | Identification and visualization of variability implementations in object-oriented variability-rich systems: a symmetry-based approach[END_REF][START_REF] Tërnava | Tracing Imperfectly Modular Variability in Software Product Line Implementation[END_REF]. Moreover, as the OO mechanisms may cause technical debt, variability debt [START_REF] Wolfart | Variability Debt: Characterization, Causes and Consequences[END_REF] is likely to be introduced at the code level.

Some recent approaches such as symfinder and its extensions [START_REF] Mortara | symfinder: A Toolchain for the Identification and Visualization of Object-Oriented Variability Implementations[END_REF][START_REF] Mortara | Extending the Identification of Object-Oriented Variability Implementations using Usage Relationships[END_REF][START_REF] Tërnava | Identification and visualization of variability implementations in object-oriented variability-rich systems: a symmetry-based approach[END_REF] detect potential variation points (vp-s) with variants in the targeted systems. 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 [START_REF] Mortara | Extending the Identification of Object-Oriented Variability Implementations using Usage Relationships[END_REF] the VariCity visualization, based on the city metaphor, was proposed and validated on large Java variability-rich systems [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities[END_REF]. While this helps architects and developers understand the implemented variability, no support was given to ease the browsing between the code and this visualization. This is quite a strong limitation as developers use Integrated Development Environments (IDEs) as tools support to assist development and program comprehension activities [START_REF] Minelli | I Know What You Did Last Summer -An Investigation of How Developers Spend Their Time[END_REF]. Moreover, with some better knowledge of the variability implementations, the need for determining their technical debt naturally arises. In a companion paper [START_REF] Mortara | Customizable Visualization of Quality Metrics for Object-Oriented Variability Implementations[END_REF], the authors have proposed VariMetrics, an extension of VariCity to display zones of OO variability implementations with technical debt. It provides additional visual properties on the buildings representing classes to display some quality metrics, such as code duplication, code complexity, and test coverage. VariMetrics was successfully applied to several large open-source projects.

In this tool demonstration paper 1 we present VariMetrics-IDE, an IDE integration for VariMetrics that embeds the visualization in the JetBrains IntelliJ IDE, enables its configuration through the IDE's menus. The developers can then use all the capabilities of Vari-Metrics, including the display of OO quality metrics, as any other IntelliJ plugin without getting out of the development environment. Both configuration of the view and bi-directional navigation between the code and the buildings in the visualization are supported. We expect this extension to facilitate the identification of zones of variability implementations with variability debt.

IDENTIFYING OO VARIABILITY IMPLEMENTATIONS

In variability-rich OO systems, the mechanisms used to implement variability in a single code base , namely inheritance, overloading, and design patterns, do not align well with domain features, making their identification difficult. When these mechanisms are used to implement some variability, they also exhibit a property of symmetry [START_REF] Coplien | Symmetry Breaking in Software Patterns[END_REF][START_REF] Tërnava | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF] since the commonality and variability addressed by the mechanism also represent the unchangeable and changeable parts in code assets. For example, inheritance allows us to factorize common parts (unchangeable) of multiple subclasses (the changeable parts) into a superclass.

As the unchanged and changed parts can be abstracted in terms of variation points (vp-s) with variants [START_REF] Svahnberg | A taxonomy of variability realization techniques[END_REF], a symmetry-based identification approach has been previously proposed [START_REF] Tërnava | Identifying and visualizing variability in object-oriented variability-rich systems[END_REF] and tooled with the the symfinder toolchain [START_REF] Mortara | symfinder: A Toolchain for the Identification and Visualization of Object-Oriented Variability Implementations[END_REF]. The approach also relies on the notion of density of symmetries in the code to reveal the variability organization (i.e., vp-s with an important number of variants at class or method level) [START_REF] Tërnava | Identification and visualization of variability implementations in object-oriented variability-rich systems: a symmetry-based approach[END_REF] and display it in the shape of a graph. To fix the lack of precision of this first approach in symfinder [START_REF] Tërnava | Identification and visualization of variability implementations in object-oriented variability-rich systems: a symmetry-based approach[END_REF], the usage relationships (type used as an attribute or method parameter) has been taken into account with the definition of a parameterized density measure that enables to automatically reveal fewer but more relevant hotspot zones concentrating variability implementations [START_REF] Mortara | Extending the Identification of Object-Oriented Variability Implementations using Usage Relationships[END_REF]. However, the resulting symfinder's graph visualization is then harder to interpret on large systems with two types of relationships being displayed at the same time.

A CITY-BASED VISUALIZATION 3.1 VariCity

The city metaphor [START_REF] Wettel | Visualizing software systems as cities[END_REF] has been applied to multiple types of metrics on software systems. In particular, CodeCity [START_REF] Wettel | CodeCity: 3D visualization of largescale software[END_REF] and Evo-Streets [START_REF] Steinbrückner | Understanding software evolution with software cities[END_REF] 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 [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities[END_REF] (cf. fig. 1). Classes are buildings whose dimensions evolve according to their method level variability metrics (method variants for the height and constructor variants for the width), exhibiting variability concentration at method level inside a class. As for design patterns, they usually involve several classes, but only the identified vp is highlighted in the visualization through a specific crown on the building.

The streets in the city shape it according to the usage relationships, starting from entry point classes, representing interesting points to explore the systems. These classes are positioned on a red street and other streets represent usage relationships. Buildings are placed by decreasing order of width on both sides of the street to exhibit density between classes. Additional usage relationships are represented as underground streets, and inheritance relationships as aerial links, both displayed when hovering a building. To make the hotspot zones of variability detected by symfinder (see previous section) noticeable, they are displayed in color (vp-s in yellow and variants in blue).

The visualization is itself configurable through several parameters, the first one being the entry point classes, more entry points tends to generate a larger city to explore. The classes displayed are also dependent on the usage orientation (IN to include only classes using the entry points, OUT for the reverse usage, IN/OUT for both ways) and the usage level (the number of hops from the entry points over the usage links).

Limitations

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 [START_REF] Mortara | Visualization of Object-Oriented Variability Implementations as Cities[END_REF]. Inheritance and additional usage relationships are displayed on hover not to overload the visualization. However, it still exhibits limitations to be used in practice on very large systems.

Firstly, variability implementations hamper the quality of a system and potentially create variability debt [START_REF] Wolfart | Variability Debt: Characterization, Causes and Consequences[END_REF], especially since OO variability implementations have no dedicated mechanism and are therefore hidden in the codebase. With VariCity, understanding this debt would require to use additional tools extracting and visualizing quality metrics (such as SonarQube2 that embeds the CodeCity [START_REF] Wettel | CodeCity: 3D visualization of largescale software[END_REF] and Evo-Streets [START_REF] Steinbrückner | Understanding software evolution with software cities[END_REF] visualizations) on the side and manually map those two sources of information. As these cities are shaped differently (the classic ones being shaped through package decomposition), the simultaneous usage of VariCity and one of these visualizations would be cumbersome, especially when experimenting with multiple metrics.

Secondly, VariCity is configured relying on knowledge from the codebase (e.g., names of the entrypoint classes). Developers usually rely on an Integrated Development Environment (IDE) as tool support for assisting development and program comprehension activities [START_REF] Minelli | I Know What You Did Last Summer -An Investigation of How Developers Spend Their Time[END_REF]. Therefore, a user would need to manually input information from their IDE in VariCity and then go back to it to explore the classes exhibited by the visualization, implying important context switching. According to these limitations, we advocate that VariCity's usability would be improved by (i) displaying quality metrics and (ii) being embedded into an IDE.

VISUALIZING QUALITY METRICS IN VARIMETRICS-IDE

As OO quality metrics are usually individual measures on the classes, we have to determine how to improve the VariCity visualization. VariCity displays in yellow vp-s being hotspots, in blue variants being hotspots, and in grey classes not being hotspots (fig. 1). However classic quality-centric cities, such as CodeCity and Evo-Streets, simply color the buildings to expose properties inherent to the classes [START_REF] Steinbrückner | Representing development history in software cities[END_REF][START_REF] Wettel | CodeCity: 3D visualization of largescale software[END_REF]. In VariMetrics, three display strategies are thus introduced to handle quality metrics. First, buildings can be colored following a red-to-green sequence (fade). Second, a saturation can be applied for keeping the original colors of the buildings and lightening or darkening them (intensity). Finally, a crackled texture (cracks) can be applied over the building with different levels of cracks, allowing to combine metrics on a single view.

Since there is no single definition of quality and each user might be interested in different metrics, VariMetrics-IDE allows to configure the view. The user can select and combine the desired quality metrics on the different visual axes to visualize them simultaneously. Combining adequate metrics allows to exhibit critical classes concentrating variability implementations. Relying on work from Wolfart et al. [START_REF] Wolfart | Variability Debt: Characterization, Causes and Consequences[END_REF], it results that OO systems implementing their variability in a single codebase are prone to exhibit variability debt as code duplication, lack of tests, and increased cognitive complexity.

The VariMetrics visualization has been quantitatively evaluated on seven industrial open-source projects from several thousands to 2.4MLoC. Using these metrics, the exhibited classes were both critical and concentrating variability implementations [START_REF] Mortara | Customizable Visualization of Quality Metrics for Object-Oriented Variability Implementations[END_REF]. A qualitative evaluation was also conducted on the JFreeChart project, with the refactoring of the indebted zones detected by VariMetrics. An example of exhibited classes is visible on fig. 2, where the two classes in the white dotted box, CategoryPlot and XYPlot, exhibit multiple method overloads (due to their height) and little test coverage (due to their cracks). Refactoring those classes led to an improvement of those classes and the project's overall quality [START_REF] Mortara | Customizable Visualization of Quality Metrics for Object-Oriented Variability Implementations[END_REF]. More details on this evaluation are available on VariMetrics webpage3 .

SEAMLESS NAVIGATION WITH THE CODE

Although VariMetrics-IDE can be used as a standalone application in a web browser, an integration is provided for the popular IDE JetBrains IntelliJ IDEA 4 . As the goal of this integration is to minimize the interactions out of the development environment, the integration embeds all the interactions needed to configure and use VariMetrics-IDE. As shown on fig. 2, the visualization is embedded in a panel in the IDE window and provides controls over symfinder and VariMetrics-IDE (see violet boxes in fig. 2). It also allows the execution of the whole toolchain as detailed in section 4 from the editor's window.

Additionally, bidirectional navigation between the visualization and the code is provided to ease transitioning between the code and its visual representation. On one side, it is possible to select multiple Although we did not conduct an experiment with real users to assert the quality of the integration, interactions have been designed following the IntelliJ Platform UI Guidelines5 to ensure visual homogeneity in the editor, thus giving us confidence in its usability. In our own experience with the IDE integration, all exploration tasks conducted in the validation of the metrics part described in the previous section were heavily facilitated.

IMPLEMENTATION

Figure 3 describes the integration of VariMetrics in the analysis toolchain based on symfinder. First, symfinder [START_REF] Mortara | symfinder: A Toolchain for the Identification and Visualization of Object-Oriented Variability Implementations[END_REF][START_REF] Mortara | Extending the Identification of Object-Oriented Variability Implementations using Usage Relationships[END_REF] parses the codebase to automatically identify the symmetries and, relying on them, the vp-s and variants. Then, quality metrics are extracted either from the SonarCloud6 profile page of the project if available, or else from a local SonarQube server that is run locally. Vari-Metrics then combines the variability and quality information to render the visualization using the Babylon.js 3D library. Outside an IDE, the resulting view is deployed with Webpack and requires only a web browser to be viewed. All the toolchain components (symfinder, metrics fetching and VariMetrics) are packed in several Docker images to ease reuse of all or parts of the toolchain. The IDE integration is developed using the IntelliJ Platform SDK 7 and is installed as any other plugin for the IDE.

CONCLUSION

VariMetrics-IDE enhances the VariCity visualization by allowing to exhibit quality metrics as additional and configurable visual properties on the buildings. Displaying in a single representation variability and quality information allows to spot zones concentrating variability implementations and being less reliable. The visualization and its configuration are embedded in the JetBrains IntelliJ IDEA IDE to limit the interactions outside the developers working environment. Bidirectional browsing between the visualization and classes in the code is supported.

As future work, we aim to conduct an empirical evaluation of VariMetrics-IDE with real architects and developers to validate our approach and tooling, but also to better understand the industry needs and expectations for such tools.

Figure 1 :

 1 Figure 1: Main visual properties of VariCity, taken from [6].

Figure 2 :

 2 Figure 2: VariMetrics-IDE visualization of JFreeChart. The white and violet boxes have been manually added on the figure.

  buildings in the visualization and to open their sources as tabs in the IDE. On the other side, IntelliJ's context menu has been enriched, and right-clicking on a class in the Project sidebar or on the name of the class in the editor panel proposes a Focus on This Class button, zooming the visualization on the desired class, and another entry to add or remove a class from the entry

Figure 3 :

 3 Figure 3: Description of VariMetrics-IDE. points list. Finally, the plugin settings window allows to configure the usage level and usage orientation, and to browse the classes of the project to add them as entry points. It also embeds all the configuration capabilities of VariMetrics.Although we did not conduct an experiment with real users to assert the quality of the integration, interactions have been designed following the IntelliJ Platform UI Guidelines 5 to ensure visual homogeneity in the editor, thus giving us confidence in its usability. In our own experience with the IDE integration, all exploration tasks conducted in the validation of the metrics part described in the previous section were heavily facilitated.

External information about VariMetrics-IDE consists in a video available at https: //youtu.be/lRPK8nS5JMc and the experimental results from[START_REF] Mortara | Customizable Visualization of Quality Metrics for Object-Oriented Variability Implementations[END_REF] available at https://deathstar3.github.io/varimetrics-demo/.

https://www.sonarqube.org/

https://deathstar3.github.io/varimetrics-demo/

https://www.jetbrains.com/idea/

https://jetbrains.github.io/ui/

https://sonarcloud.io/

https://plugins.jetbrains.com/docs/intellij/welcome.html

ACKNOWLEDGMENTS

We thank Patrick Anagonou, João Brilhante, Charly Ducrocq, Ludovic Marti, Guillaume Savornin and Anton van der Tuijn for their contribution in the development of VariMetrics-IDE.