Analysis of pervasive multiple-component defects in a large software system

Reverse engineering aims at obtaining high-level representations of software systems from existing low-level artifacts, such as binaries, source code, execution traces or historical information. Reverse engineering methods and technologies play an important role in many software engineering tasks and quite often are the only way to get an understanding of large and complex software systems. Given for example the task to understand certain aspects of the test code in large software systems, such as Eclipse. How would you figure out the answers to the following questions:

The detection of function clones in software systems is valuable for the code adaptation and error checking maintenance activities. This paper presents an efficient metrics-based data mining clone detection approach. First, metrics are collected for all functions in the software system. A data mining algorithm, fractal clustering, is then utilized to partition the software system into a relatively small number of clusters. Each of the resulting clusters encapsulates functions that are within a specific proximity of each other in the metrics space. Finally, clone classes, rather than pairs, are easily extracted from the resulting clusters. For large software systems, the approach is very space efficient and linear in the size of the data set. Evaluation is performed using medium and large open source software systems. In this evaluation, the effect of the chosen metrics on the detection precision is investigated.

For large software systems, refactoring activities can be a challenging task, since for keeping component complexity under control the overall architecture as well as many details of each component have to be considered. Product metrics are therefore often used to quantify several parameters related to the modularity of a software system. This paper devises an approach for automatically suggesting refactoring opportunities on large software systems. We show that by assessing metrics for all components, move methods refactoring an be suggested in such a way to improve modularity of several components at once, without hindering any other. However, computing metrics for large software systems, comprising thousands of classes or more, can be a time consuming task when performed on a single CPU. For this, we propose a solution that computes metrics by resorting to GPU, hence greatly shortening computation time. Thanks to our approach precise knowledge on several properties of the system can be continuously gathered while the system evolves, hence assisting developers to quickly assess several solutions for reducing modularity issues.

Testing consumes significant human and machine resources, especially for large, complex systems such as database servers. While a variety of testing approaches have been proposed to improve the efficiency of the testing process, it is difficult to evaluate these approaches. Mutation testing has been proposed as a way to assess the adequacy of a test suite, assigning a score that can be used to compare testing approaches. While promising, serious obstacles appear to prevent mutation testing with large software systems. Recent advances in mutation testing have scaled to medium-sized programs of around 100,000 lines of code but to our knowledge there are no reported studies working with large systems with millions of lines of code and other features of database systems that complicate testing. In this paper we explore using mutation testing on a database server to evaluate its suitability for comparing test suites or testing approaches.

In the context of software maintenance, legacy software systems are continuously re-engineered in order to correct errors, provide new functionality, or port them into modern platforms. However, software re-engineering activities should not occur in a vacuum, and it is important to incorporate non-functional requirements as part of the re-engineering process. We present an incremental reengineering framework that allows for quality requirements to be modeled as soft-goals, and transformations to be applied selectively towards achieving specific quality requirements for the target system. To deal with large software systems, we decompose the system into a collection of smaller clusters. The reengineering framework can be applied incrementally to each of these clusters and results are assembled to produce the final system.

The state explosion problem faced by concolic execution is significantly serious when detecting program bugs especially in large scale software systems. To mitigate the issue, we propose a practical concolic execution approach to detect vulnerabilities in this paper. First, we identify the correlation between symbolic memory and control flow by statically analyzing the software under test, and distinguish the critical symbolic memory and ordinary symbolic memory according to the above correlation. Then, we design different strategies for two kinds of symbolic memory in order to generate state when performing concolic execution of the target software. We present these ideas in a prototype system, Pracolic, and evaluate it with four file systems in Linux, i.e., ext4, XFS, Btrfs, and ReiserFS. Experimental results show that Pracolic can effectively mitigate the problem of state explosion in concolic execution, and outperform S2E, a state-of-the-art analysis system, on state reduction and code coverage for large scale software systems.

Software systems continue to play an increasingly important role in our daily lives, making the quality of software systems an extremely important issue. Therefore, a significant amount of recent research focused on the prioritization of software quality assurance efforts. One line of work that has been receiving an increasing amount of attention is Software Defect Prediction (SDP), where predictions are made to determine where future defects might appear. Our survey showed that in the past decade, more than 100 papers were published on SDP. Nevertheless, the practical adoption of SDP to date is limited. In this paper, we highlight the findings of our thesis, which identifies the challenges that hinder the adoption of SDP in practice. These challenges include the fact that the majority of SDP research rarely considers the impact of defects when performing their predictions, seldom provides guidance on how to use the SDP results, and is too reactive and defect-centric in nature. Therefore, we propose approaches that tackle these challenges. First, we present approaches that predict high-impact defects. Our approaches illustrate how SDP research can be tailored to consider the impact of defects when making their predictions. Second, we present approaches that simplify SDP models so they can be easily understood and illustrates how these simple models can be used to assist practitioners in prioritizing the creation of unit tests in large software systems. These approaches illustrate how SDP research can provide guidance to practitioners using SDP. Then, we argue that organizations are interested in proactive risk management, which covers more than just defects. For example, risky changes may not introduce defects but they could delay the release of projects. Therefore, we present an approach that predicts risky changes, illustrating how SDP can be more encompassing (i.e., by predicting risk, not only defects) and proactive (i.e., by predicting changes before they are incorporated into the code base).

Analyzing defect inflow distribution and applying Bayesian inference method for software defect prediction in large software projects

A software system often consists of thousands of source files, which must be translated into thousands of intermediate files, which eventually must be translated into some small number of library and executable files. Collectively, these steps compose its build process. A large software system can be difficult to build. The steps can be numerous and complex. Of course, there are a variety of tools to assist us (e.g. MAKE), but their languages emphasize the specification of low-level details (e.g. compiler names and options), rather than high-level attributes (e.g. host/target platforms and required subsystems). This paper describes a new domain-specific language for specifying the composition and construction of a software system, where the emphasis is on high-level attributes. A specification is processed by a pipeline of fairly simple tools to produce a set of makefiles, which are then processed by MAKE in the usual way.

Large software systems are often deployed putting together many Commercial-Off-The-Shelf software components (COTS). The selection of the COTS to be integrated is driven by the software system requirements. In this paper, we propose the RECSS method aimed at supporting requirements elicitation and analysis in the context of COTS-based software systems. RECSS builds a goal model of the system environment which identifies the external elements that interact with it. Next, the system is decomposed into actors for which ISO/IEC-based quality models are built. As part of the process, environmental and platform characteristics that influence the behaviour of the system are identified. Last, the resulting artefacts are used to analyse and refine the system requirements.

Program slicing is a useful reduction technique in many areas such as debugging and testing, and thus, there has also been some research to try and apply slicing techniques to flat state-based models at the design level, for their maintenance and quality improvement. However, such state-based models have difficulties in specifying large and complex software systems, and so the benefit obtained from slicing such models, is very limited. In contrast, UML state machine diagrams can properly describe the behavior of large software systems; but it is difficult to apply a slicing algorithm to automatically reduce the diagram with respect to a point of interest, because of the unique properties (such as hierarchy and orthogonality) of these diagrams. In this paper, we identify important issues relevant to the slicing of UML state machine diagrams with regards to data and control dependence. We also show why the unique properties of these diagrams are important to consider when retrieving data and control dependence information, by virtue of an illustrative example.

Large software systems are expensive to develop and maintain. A significant amount of programmer activity in understanding, changing, and debugging these systems is information management. To support these activities more directly, we have designed a programming environment, called OMEGA, that provides powerful mechanisms for accessing and displaying the information in a large software system. OMEGA uses successful ideas from existing programming environments while trying to correct deficiencies. The major deficiency in these systems is that programmers can only view and manipulate a single logical representation of programs. To support multiple representations, OMEGA uses a relational database system to manage all program information. Using a database system provides a powerful mechanism for efficient access to a variety of cross-sections of program information, as well as providing traditional database facilities such as concurrency control, data integrity, and crash recovery. The user interface to OMEGA separates input specification from output display, relies on pointing rather than typing, and exploits interaction in semantic analysis to detect many errors as soon as they are made. By eliminating the traditional textual interface to programs, OMEGA also allows the unification of the different abstraction mechanisms present in traditional programming environments. We have experimented with the ideas in OMEGA by designing a relational schema for software written in a particular programming language, and by implementing a program that transfers existing programs, stored as text, into a database managed by an off-the-shelf database system. A prototype visual interface to the program database has also been implemented. The results of this thesis are new models of program representation and user interaction for software development systems. The model of program representation can be expressed in the relational data model, and software can therefore be manipulated easily and powerfully using relational calculus. Our experimental implementation demonstrates the feasibility of using a relational database system, and provides insights into potential problems and how they might be solved.

The modularization of large legacy software systems has attracted a great deal of attention in recent years. Such modularization improves the maintenance and reuse of smaller, more manageable pieces of program source codes, and also provides insight into the overall structure of the software system. This paper develops a methodology to determine the modularization programming of a legacy software system. This methodology breaks programs into modules, or groups of related functions based on the observation that a module can be defined as a group of functions having high cohesion and low coupling. Furthermore, the determination of good alternatives to perform the desired attributes, with some fuzzy constraints, is crucial in building software systems. With known modules, a rule-based fuzzy representation of the module development problem is presented, while the tradeoff of the attributes of performance among modules is analyzed, using a fuzzy neural network approach. The approach taken to reach this solution is illustrated with simulation software.

Insights and assessments about the quality, reliability, or trustworthiness of software systems is important for many software applications. Especially for large or mission-critical software systems, reliable measures and assertions are crucial. Since software repositories contain information about source code, software development processes, and team interactions, we extract the provenance of software artifacts from those repositories and store the provenance according to a provenance model defined using W3C PROV data model. We use the recorded provenance to discover insights about the software and its development process, which we apply and evaluate for a large aerospace software system.

Trends and aspects of the development of large finite element software systems