Kecia Aline Marques Ferreira

Identifying thresholds for object-oriented software metrics

Abstract: Despite the importance of software metrics and the large number of proposed metrics, they have not been widely applied in industry yet. One reason might be that, for most metrics, the range of expected values, i.e., reference values are not known. This paper presents results of a study on the structure of a large collection of open-source programs developed in Java, of varying sizes and from different application domains. The aim of this work is the definition of thresholds for a set of object-oriented software metrics, namely: LCOM, DIT, coupling factor, afferent couplings, number of public methods, and number of public fields. We carried out an experiment to evaluate the practical use of the proposed thresholds. The results of this evaluation indicate that the proposed thresholds can support the identification of classes which violate design principles, as well as the identification of well-designed classes. The method used in this study to derive software metrics thresholds can be applied to other software metrics in order to find their reference values.

Reference Values for Object-Oriented Software Metrics

Although a large quantity of OO software has been produced, little isknown about the actual structure of this type of software. There is alarge number of proposed metrics for OO software, but they are stillnot employed effectively in industry. A reason for this is that thereare few data published about this topic, and typical values of themetrics are not known. This paper presents the results of a studycarried out on a large collection of open-source software developed inJava. The objective of this study was to identify characteristics ofthis type of software in terms of a set of metrics for OO software,such as connectivity, class cohesion and depth of a class in itsinheritance tree. The results of the study provide important insightson the structure of open-source OO software and exhibit values that canbe taken as baselines for the values of measures of the metrics.

Reestruturação de Software Dirigida por Conectividade para Redução de Custo de Manutenção

Most of the software cost is due to maintenance. In the last years, there has been a great deal of interest in developing cost estimation and effort prediction instruments for software maintenance. This work proposes that module connectivity is a key factor to predict maintenance cost and uses this thesis as the basis to develop a Connectivity Evaluation Model in OO Systems (MACSOO), which is a refactoring model based on connectivity whose aim is to minimize maintenance cost. We describe experiments whose results provide an example of the model application and expose the correlation between connectivity and maintainability.

FindSmells: flexible composition of bad smell detection strategies

Bad smells are symptoms of problems in the source code of software systems. They may harm the maintenance and evolution of systems on different levels. Thus, detecting smells is essential in order to support the software quality improvement. Since even small systems may contain several bad smell instances, and considering that developers have to prioritize their elimination, its automated detection is a necessary support for developers. Regarding that, detection strategies have been proposed to formalize rules to detect specific bad smells, such as Large Class and Feature Envy. Several tools like JDeodorant and JSpIRIT implement these strategies but, in general, they do not provide full customization of the formal rules that define a detection strategy. In this paper, we propose FindSmells, a tool for detecting bad smells in software systems through software metrics and their thresholds. With FindSmells, the user can compose and manage different strategies, which run without source code analysis. We also provide a running example of the tool. Video: https://youtu.be/LtomN93y6gg.

A model for estimating change propagation in software

A major issue in software maintenance is change propagation. A software engineer should be able to assess the impact of a change in a software system, so that the effort to accomplish the maintenance may be properly estimated. We define a novel model, named K3B, for estimating change propagation impact. The model aims to predict how far a set of changes will propagate throughout the system. K3B is a stochastic model that has input parameters about the system and the number of modules which will be initially changed. K3B returns the estimated number of change steps, considering that a module may be changed more than once during a modification process. We provide the implementation of K3B for object-oriented programs. We compare our implementation with data from an artificial scenario, given by simulation, as well as with data from a real scenario, given by historical data. We found strong correlation between the results given by K3B and the results observed in the simulation, as well as with historical data of change propagation. K3B may be used for comparing software systems from the viewpoint of change impact. The model may aid software engineers in allocating proper resources to the maintenance tasks.

A comparison of three algorithms for computing truck factors

Truck Factor (also known as Bus Factor or Lottery Number) is the minimal number of developers that have to be hit by a truck (or leave) before a project is incapacitated. Therefore, it is a measure that reveals the concentration of knowledge and the key developers in a project. Due to the importance of this information to project managers, algorithms were proposed to automatically compute Truck Factors, using maintenance activity data extracted from version control systems. However, to the best of our knowledge, we still lack studies that compare the accuracy of the results produced by such algorithms. Therefore, in this paper, we evaluate and compare the results of three Truck Factor algorithms. To this end, we empirically determine the truck factors of 35 open-source systems by consulting their developers. Our results show that two algorithms are very accurate, especially when the systems have a small Truck Factor. We also evaluate the impact of different thresholds and configurations in algorithm results.

Mapping the potential change impact in object-oriented software

The present work brings the results of a study carried out to investigate the change propagation impact in object-oriented programs. We have performed this analysis by considering a macroscopic topology of object-oriented program called Little House. According to this topology, the dependence graph of classes can be partitioned into six components, namely: In, LSCC, Out, Tendrils, Tubes, and Disconnected. We analyzed the data of 12 open source Java projects, in a total of 54 versions of them. The results of our study suggest that LSCC and Out concentrate the classes with the far highest potential change impact. We have also observed that this characteristic remains during the software evolution.

Statistical dataset on software metrics in object-oriented systems

This paper presents a set of statistical data on the software metrics of object-oriented systems. The data were generated from the Qualitas.class Corpus, which gathered a large amount of metrics data from the 111 systems included in Qualitas Corpus. We used the R project for Statistical Computing to generate 6 statistical graphs, 4 summarization/aggregation tables and an R script, for each of the 21 metrics evaluated in each of the 111 systems. This amounted to 13,986 graphs, 8,800 tables and 2,200 R scripts. We also utilized EasyFit to fit a large number of distributions to each dataset, which in turn provided the best fitting statistical distribution, as well as the fit ranking. We also provide a MySQL database dump that normalizes the metric measures and facilitates data manipulation tasks such as filtering and aggregation. By making this set available, we intend to help researchers in their work on software metrics.

A Generic Macroscopic Topology of Software Networks - A Quantitative Evaluation

The dependence among modules in a software system usually is represented as a network, in which the nodes are the modules, and the edges are the connections between the modules. The relationships among modules in software systems are hard to assess, especially in large programs. Knowing the nature of the software system structures is very important to improve maintenance tasks and other challenging tasks in software development. A previous work of the authors of this paper has defined a model to the topology of software networks, named Little House. This model is a generic macroscopic view of software systems, and it is an adaptation of the well-known Bow-tie model. According to Little House, a software network can be partitioned into six components, in such a way there is a special pattern of connections among them. This paper describes the results of a quantitative evaluation of Little House. The aim of this work is to investigate whether the components of Little House can be described by any pattern of software metric values. The results of this evaluation indicate that in the software systems developed currently there are two main components of Little House that have critical values of metrics. This finding suggests that classes from those components should be carefully considered when maintenance tasks are performed in the program.

A systematic literature mapping on the relationship between design patterns and bad smells

Bad Smells are symptoms that appear in the source code of a software system and may indicate a structural problem that requires code refactoring. Design patterns are solutions known as good practices that help building software systems with high quality and flexibility. Intuitively, it is possible to assume that the use of design patterns might avoid bad smells. Intriguingly, some recent studies have pointed out that this assumption is not true. This paper presents a systematic literature mapping of studies that investigate the relationship between design patterns and bad smells. We identified 16 papers which were categorized into three different approaches: impact on software quality, refactoring and co-occurrence. Amongst these three approaches, the co-occurrence relationship is the less explored in the literature. In addition, we identified that studies focusing on co-occurrence between design patterns and bad smells have generally analyzed the relationship between the GOF design patterns and bad smells described by Fowler and Beck. In this context, the Command design pattern was identified as the one with greater relationship with bad smells.