Evolving Software System Research Articles

Evolving software system families in space and time with feature revisions

Software companies commonly develop and maintain variants of systems, with different feature combinations for different customers. Thus, they must cope with variability in space. Software companies further must cope with variability in time, when updating system variants by revising existing software features. Inevitably, variants evolve orthogonally along these two dimensions, resulting in challenges for software maintenance. Our work addresses this challenge with ECSEST (Extraction and Composition for Systems Evolving in Space and Time), an approach for locating feature revisions and composing variants with different feature revisions. We evaluated ECSEST using feature revisions and variants from six highly configurable open source systems. To assess the correctness of our approach, we compared the artifacts of input variants with the artifacts from the corresponding composed variants based on the implementation of the extracted features. The extracted traces allowed composing variants with 99-100% precision, as well as with 97-99% average recall. Regarding the composition of variants with new configurations, our approach can combine different feature revisions with 99% precision and recall on average. Additionally, our approach retrieves hints when composing new configurations, which are useful to find artifacts that may have to be added or removed for completing a product. The hints help to understand possible feature interactions or dependencies. The average time to locate feature revisions ranged from 25 to 250 seconds, whereas the average time for composing a variant was 18 seconds. Therefore, our experiments demonstrate that ECSEST is feasible and effective.

How bugs are born: a model to identify how bugs are introduced in software components

When identifying the origin of software bugs, many studies assume that “a bug was introduced by the lines of code that were modified to fix it”. However, this assumption does not always hold and at least in some cases, these modified lines are not responsible for introducing the bug. For example, when the bug was caused by a change in an external API. The lack of empirical evidence makes it impossible to assess how important these cases are and therefore, to which extent the assumption is valid. To advance in this direction, and better understand how bugs “are born”, we propose a model for defining criteria to identify the first snapshot of an evolving software system that exhibits a bug. This model, based on the perfect test idea, decides whether a bug is observed after a change to the software. Furthermore, we studied the model’s criteria by carefully analyzing how 116 bugs were introduced in two different open source software projects. The manual analysis helped classify the root cause of those bugs and created manually curated datasets with bug-introducing changes and with bugs that were not introduced by any change in the source code. Finally, we used these datasets to evaluate the performance of four existing SZZ-based algorithms for detecting bug-introducing changes. We found that SZZ-based algorithms are not very accurate, especially when multiple commits are found; the F-Score varies from 0.44 to 0.77, while the percentage of true positives does not exceed 63%. Our results show empirical evidence that the prevalent assumption, “a bug was introduced by the lines of code that were modified to fix it”, is just one case of how bugs are introduced in a software system. Finding what introduced a bug is not trivial: bugs can be introduced by the developers and be in the code, or be created irrespective of the code. Thus, further research towards a better understanding of the origin of bugs in software projects could help to improve design integration tests and to design other procedures to make software development more robust.

A Preliminary Investigation Towards the Impact of Composition Properties on Code Anomalies

Software systems evolve through the composition of their modules. However, the complexity associated with the composition properties emerges as an extremely favorable factor for unwanted code changes. In a parallel context, several studies indicate that the occurrence of code anomalies also generates unwanted changes in the source code. Code anomaly is associated with undesirable symptoms that affect negatively the program structure. Apparently, composition properties and code anomalies share similar characteristics. However, there are no studies that analyze if and how composition properties are related to code anomalies occurrence. This paper presents a preliminary investigation about the impact of composition properties on code anomalies. Our investigation was developed across 6 versions of an evolving software system. Our preliminary findings indicate that variations on composition properties reflect directly on code anomalies occurrence.

Balancing Business and Technical Objectives for Supporting Software Evolution

Context: Successful software systems continuously evolve to accommodate feature requests of a diverse customer-base. At some point during this evolution, the variety of customer needs and increased system complexity suggests the consideration of a software product line (SPL).Aim: The goal of this research is to support the decision maker facing the enhancement of an evolving software system (ESS) by determining the most appropriate product line design (out of a given set of candidate SPL portfolios) to minimize the technical risk and maximize the business value.Method: The proposed method called OPTESS is aimed at finding an evolution plan for the ESS which optimizes both the given technical and business objectives. Business analysis using a value-based pricing mechanism is applied to a set of initially proposed SPL portfolios (for enhancing the ESS) such that profit is maximized. Technical analysis is applied to the same initially proposed SPL portfolios to minimize the risk of failure of ESS due to implementation of new features. Business and technical analyses improve the performance of solutions for their respective objectives by modifying the feature sets of candidate SPL portfolios. OPTESS helps the decision maker select a plan for enhancement of an ESS by performing trade- off analysis between economic and technical objectives.Results: The method was initially evaluated through a case study for a set of 9 new candidate features to be added to an open source text editing system called jEdit. OPTESS helped the decision maker to identify 3 non-dominated solutions judged to be the best contenders for addition when considering both technical and economic criteria.

Software Evolution via Topic Modeling: An Analytic Stud

Open-source projects continue to evolve resulted in so many versions. Managing, visualizing and understanding an evolving software system are challenging tasks. In this work, we apply Latent Dirichlet Allocation (LDA) to discover source code topics and study their evolution over multiple software versions. We apply LDA to all versions of the system together and then determine how the assignment metric evolves over time. We study the software evolution of two large open-source projects, JEdit and JHotDraw, over twelve versions. The results show that changes in topics across versions are due to actual software changes such as adding, updating, and removing features. Our work suggests that using LDA can open many paths in software evolution research.

Decision support for moving from a single product to a product portfolio in evolving software systems

Successful software systems continuously evolve to accommodate ever-changing needs of customers. Accommodating the feature requests of all the customers in a single product increases the risks and costs of software maintenance. A possible approach to mitigate these risks is to transition the evolving software system (ESS) from a single system to a portfolio of related product variants, each addressing a specific customers’ segment. This evolution should be conducted such that the extent of modifications required in ESS's structure is reduced. The proposed method COPE+ uses preferences of customers on product features to generate multiple product portfolios each containing one product variant per segment of customers. Recommendations are given to the decision maker to update the product portfolios based on structural analysis of ESS. Product portfolios are compared with the ESS using statechart representations to identify the level of similarity in their behaviors. A proof of concept is presented by application to an open-source text editing system. Structural and behavioral analysis of candidate portfolios helped the decision maker to select one portfolio out of three candidates.

Specifying features of an evolving software system

AbstractSoftware development is increasingly concerned with maintaining and extending existing software systems to meet the evolving user requirements. Many of these systems are feature‐rich and are developed incrementally. As structures of existing software systems—in addition to the user requirements—influence the specifications, specifying these systems poses unique challenges. This paper reports on our experience of applying an engineering approach to specifying an evolving feature‐rich television software system. In this approach, features are specified modularly by first fitting their problems to known problem patterns, and then analyzing typical concerns—meaning the potential causes of errors—associated with those patterns. In cases where the existing design poses difficulties when fitting problems to patterns, we transform its structure using known design mechanisms so that the problems fit the patterns. After deriving specifications of individual features, possible interactions between features are detected, before declaratively specifying resolutions to undesired interactions. As the concerns of features and their composition are addressed separately, the specifications derived are modular, thus, providing rich treaceability to their requirements. As well as discussing how features may be specified using natural language, we also show how their descriptions may be formalized using a form of temporal logic called the Event Calculus, and prove their correctness using an off‐the‐shelf tool. Copyright © 2009 John Wiley & Sons, Ltd.

Street smarts for boss

The Urban Challenge was an autonomous vehicle competition sponsored by the U.S. Defense Advanced Research Projects Agency (DARPA) in November 2007. Contestant robots were required to autonomously execute a series of navigation missions through a simplified urban environment consisting of roads, intersections, and parking lots while obeying road rules and interacting safely and correctly with other traffic. In contrast to previous DARPA challenges, which focused on rough-terrain navigation, this competition required a system capable of complex autonomous behaviors, such as waiting for precedence at an intersection or passing a slow-moving vehicle on a multilane road. These behaviors were managed by a software subsystem called the behavioral executive in Boss, Tartan Racing's winning entry in the Urban Challenge. The fulfillment of this role required the carefully structured integration and management of many disparate capabilities in a highly flexible manner over the course of the development, accommodating whatever changes were necessary to win the competition amidst a continuously evolving software system. These requirements, among many others, are reflected in the behavioral executive's architecture, the flexibility and adaptability of which played an important role in the team's success.

Empirical assessment of the impact of structural properties on the changeability of object-oriented software

The changeability of software can be viewed as the quality of being capable of change, which among others implies that the task of changing the software requires little effort. It is hypothesized that structural properties of the software affect changeability, in which case measures of such properties can be used as changeability indicators. Ways in which structural properties of the software can be measured are described and empirically validated based on data collected from an industrial Java development project. The measures are validated by using them as candidate variables in a multivariate regression model of the actual effort required to make modifications to the evolving software system. The results suggest that some measures that combine existing structural attribute measures with a weighting factor based on the relative proportion of change in each class can explain a large amount of the variation in change effort. This constitutes initial, empirical evidence that the proposed measures are valid changeability indicators. Consequently, they may help designers to identify and correct design problems during the development and maintenance of object-oriented software.

Analysing failure behaviours in component interaction

In order to facilitate the process of safety analysis of an evolving software system, this paper presents an architectural approach that enhances the safety analysis by providing appropriate abstractions for modelling and analysing interactions between components, since faulty interactions are the usual cause of accidents. For that, instead of considering components as the locus of change, the proposed approach assumes that components remain unchanged while their interactions (captured by connectors) adapt to the different changes made in the system. The behavioural description of connectors is provided in terms of extended time automata, and the safety analysis is performed using model checking, which verifies whether safe behaviour is maintained when interactions between components change. The feasibility of the approach is demonstrated in terms of a case study that deals with the safety procedures associated with the launching of a sounding rocket.

HydroJ

In an evolving software system, components must be able to change independently while remaining compatible with their peers. One obstacle to independent evolution is the brittle parameter problem : the ability of two components to communicate can depend on a number of inessential details of the types, structure, and/or contents of the values communicated. If these details change, then the components can no longer communicate, even if the essential parts of the message remain unaffected.We present HydroJ, an extension of Java that addresses this problem. In HydroJ, components communicate using self-describing, semi-structured messages, and programmers use pattern matching to define the handling of messages. This design stems from two central ideas: first, that self-describing messages reduce dependence on inessential message format details; and second, that object-oriented pattern matching naturally focuses on the essential information in a message and is insensitive to inessential information.We have developed these ideas in the context of Rain, a distributed, heterogeneous messaging system for ubiquitous computing. To evaluate the design, we have constructed a prototype HydroJ compiler, implemented some Rain services in HydroJ, studied the evolution of an existing Rain service over time, and formalized HydroJ's key features in a core language.

Predictive modeling techniques of software quality from software measures

The objective in the construction of models of software quality is to use measures that may be obtained relatively early in the software development life cycle to provide reasonable initial estimates of the quality of an evolving software system. Measures of software quality and software complexity to be used in this modeling process exhibit systematic departures of the normality assumptions of regression modeling. Two new estimation procedures are introduced, and their performances in the modeling of software quality from software complexity in terms of the predictive quality and the quality of fit are compared with those of the more traditional least squares and least absolute value estimation techniques. The two new estimation techniques did produce regression models with better quality of fit and predictive quality when applied to data obtained from two software development projects.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

A graph model for software evolution

A graph model of software evolution is presented. The author seeks to formalize the objects and activities involved in software evolution in sufficient detail to enable automatic assistance for maintaining the consistency and integrity of an evolving software system. This includes automated support for propagating the consequences of a change to a software system. The evolution of large and complex software systems receives particular attention.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

The evolution support environment system

The evolution support environment (ESE) system, which provides a framework for capturing and making available semantic information about software components of an evolving software system, is described. The goal in the design of the ESE system was to provide integrated support for management of software architecture configuration, life-cycle configuration, and version control. Software architecture configuration management allows tracking of interconnections among software components that make up a system. Life-cycle management allows traceability among specifications, design, code, and test cases during software development. Adding version control allows specific versions of software objects and their associated objects, such as specifications and test cases, to be retrieved. The authors' experience with the use of the system is discussed.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>