Discovering Maintainability Changes in Large Software Systems∗ Arthur Molnar Simona Motogna Babeş-Bolyai University Babeş-Bolyai University Cluj-Napoca, Romania Cluj-Napoca, Romania [email protected] [email protected] ABSTRACT 1 INTRODUCTION In this paper we propose an approach to automatically discover Software development evolved dramatically over the past decades, meaningful changes to maintainability of applications developed enabling the creation of increasingly complex applications. This in using object oriented programming languages. Our approach con- turn generated continued interest related to measuring and ensur- sists of an algorithm that employs the values of several class-level ing software quality. Large software systems are developed incre- software metrics that can be easily obtained using open source mentally by teams over a long period of time. Methodologies such as software. Based on these values, a score that illustrates the main- Agile encourage dividing development activities over smaller time tainability change between two versions of the system is calculated. frames, with emphasis placed on always having working software We present relevant related work, together with the state of research at hand. In practice, this results in many application versions that regarding the link between software metrics and maintainability allow shipping new functionalities to customers quickly. However, for object oriented systems. In order to validate the approach, we experience shows that maintenance of these systems becomes very undertake a case study that covers the entire development history expensive, with costs estimated at 50 % of total life cycle costs [28]. of the jEdit open source text editor. We consider 41 version pairs In order to address this issue, a clear understanding of main- that are assessed for changes to maintainability. First, a manual tool tainability, together with ways of measuring and controlling it are assisted examination of the source code was performed, followed by required. The IEEE guides [5] define maintainability as "the ease calculating the Maintainability Index for each application version. with which a software system or component can be modified to correct In the last step, we apply the proposed approach and compare the faults, improve performance or other attributes, or adapt to a changed findings with those of the manual examination as well asthose environment". Starting from the definition above, we consider a obtained using the Maintainability Index. In the final section, we maintainability change any modification of the source code that present the identified issues and propose future work to further impacts how easily it can be fixed, improved or otherwise changed. fine tune the approach. As "you cannot control that which you cannot measure" [18], it becomes obvious that software metrics have value in assessing key CCS CONCEPTS software characteristics. Therefore, our approach employs mature and well-studied object-oriented metrics that offer numerical in- • Software and its engineering → Maintaining software; Soft- formation about source code aspects such as hierarchical program ware version control; structure, complexity, as well as information regarding dependency, in the form of cohesion and coupling. KEYWORDS The current study proposes a new approach based on collecting maintainability; maintainability index; object oriented metrics; case object oriented metric values that provide information regarding study several aspects of source code, and observing the change in their values for consecutive versions of the target application. The reason ACM Reference format: for focusing on value differences is that most tools provide different Arthur Molnar and Simona Motogna. 2017. Discovering Maintainability thresholds when interpreting metric values. We find this to be a Changes in Large Software Systems. In Proceedings of IWSM Mensura, Gothenburg, Sweden, 2017, 6 pages. continued subject of differing scientific opinion [23]. https://doi.org/10.475/123_4 The idea of using software metrics to produce an assessment of system maintainability is not new. An illustrative example is the Maintainability Index (MI) that is used as a baseline in our ∗Produces the permission block, and copyright information study. The MI has both its users [3, 8] as well as detractors, as many practitioners and researchers consider it to be of little relevance, or even obsolete [19], [27]. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation 2 PRELIMINARIES on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). 2.1 Software Metrics IWSM Mensura, 2017, Gothenburg, Sweden Many software metrics have been proposed over the years, and their © 2017 Copyright held by the owner/author(s). ACM ISBN 123-4567-24-567/08/06. role in understanding and improving software quality is becoming https://doi.org/10.475/123_4 more important nowadays, especially for large applications. IWSM Mensura, 2017, Gothenburg, Sweden Arthur Molnar and Simona Motogna Some of the most widely used metrics simply count source code resettles the MI into the [0,100] range [8]. The thresholds used show lines, functions, classes and modules in the program. Their simplic- bad maintainability for scores between 0 and 9, moderate for scores ity and straightforwardness allowed them to remain relevant, or between 10 and 19, and good maintainability for scores above 20 [8]. be easily adopted for new programming paradigms and languages. Second, programming languages have evolved significantly since In our case study, we harness these metrics during manual source the 90’s, and their constructs and relations between them have code examination to quickly assess which areas of the application changed. Finally, by computing the MI at package or application underwent most significant change. level, the coarse granularity might not offer adequate solutions for The appearance of object oriented programming languages lead identifying the code that contributes most to low maintainability. to the definition of specialized metrics, that capture aspects related to object orientation. The Chidamber & Kemerer (CK) metrics suite 2.2 Related work [17] is one of the most popular, and is implemented in most of the The relation between object oriented metrics and maintainability available metric tools [6, 13]. Object oriented metrics are classified has presented a lot of interest in research studies. Several studies as describing four internal characteristics of the object oriented have illustrated this relation and took into consideration the CK, as paradigm: inheritance, structural complexity, coupling and cohesion well as other object oriented metrics [21], [23], [19]. Even if [21] [23]. proved that "the prediction of maintenance effort metric is possi- The study takes into consideration a subset of the CK metrics ble", no such formula has been proposed based on object oriented suite, from which one metric is selected for each of the four internal metrics. [22] proposes a comprehensive compendium of the rela- characteristics presented above. The selection ensures that relevant tion between OO metrics and ISO 9126 quality factors, including characteristics of the system are captured. Selected metrics are at maintainability. It offers valuable information that was used inthe class level in order to facilitate fine grained analysis. The selected presented study, but only at descriptive level. metrics are: The main difference between these results and the proposed • Depth of Inheritance Tree (DIT) [17] defined as the length of approach is that we do not focus on threshold values, but on the the longest inheritance path between a given class and the modification of the metric values over time. We believe thatob- root of the tree; DIT is a structural metric. servation of the changes in metric values and their cumulative • Weighted Methods per Class (WMC) [17] defined as the sum impact on maintainability offer useful information when dealing of the cyclomatic complexities of all methods of a given class. with multiple versions of large-scale applications. • Coupling Between Objects (CBO) [17] representing the num- ber of other classes that are coupled to the given class. Namely, 3 DISCOVERING MAINTAINABILITY two classes are coupled when methods declared in one class CHANGES use methods or instance variables defined by the other class. 3.1 Approach • Lack of Cohesion in Methods (LCOM4) [20] defined by the difference between the number of method pairs using at least This paper proposes a new methodology for detecting meaningful one common instance variables and the number of method changes to object-oriented software systems. The idea is based pairs that do not use any common variables. on recent work that explores the relation between metrics and desirable properties of software systems on one hand [15, 22, 24], The well established metric for maintainability is Maintainability and the availability of software tools to calculate advanced object- Index (MI), introduced in 1992 [26] as a measure of how easy it is to oriented metrics at class, package and system level [6, 11, 13], on maintain a program. Several metric and code inspection tools can the other. compute the MI, including