Self-adaptation endows a software system with the ability to satisfy certain objectives by automatically modifying its behavior. While many promising approaches for the construction of selfadaptive software systems have been developed, the majority of them ignore the uncertainty underlying the adaptation decisions. This has been one of the key obstacles to wide-spread adoption of self-adaption techniques in risk-averse real-world settings. In this paper, we describe an approach, called POssIbilistic SElf-aDaptation (POISED), for tackling the challenge posed by uncertainty in making adaptation decisions. POISED builds on possibility theory to assess both the positive and negative consequences of uncertainty. It makes adaptation decisions that result in the best range of potential behavior. We demonstrate POISED's application to the problem of improving a software system's quality of service via runtime reconfiguration of its customizable software components. We have extensively evaluated POISED using a prototype of a robotic software system.

Embedded and mobile software systems are marked with a high degree of unpredictability and dynamism in the execution context. At the same time, such systems are often mission-critical, meaning that they need to satisfy strict reliability requirements. Most current software reliability analysis approaches are not suitable for these types of software systems, as they do not take the changes in the execution context of the system into account. We propose an approach geared to such systems which continuously furnishes refined reliability predictions at runtime by incorporating various sources of information, including the execution context of the system. The reliability predictions are leveraged to proactively place the software in the (near-)optimal configuration with respect to changing conditions. Our approach considers two representative architectural reconfiguration decisions that impact the system's reliability: reallocation of components to processes and changing the number of component replicas. We have realized the approach as part of a framework intended for mission-critical settings, called REsilient SItuated SofTware system (RESIST), and evaluated it using a mobile emergency response system.

No abstract

Conventional wisdom suggests that a software system's architecture has a significant impact on its evolution. Prior research has studied the evolution of software using the information of how its files have changed together in their revision history. No prior study, however, has investigated the impact of architecture on the evolution of software from its change history. This is mainly because most open-source software systems do not document their architectures. We have overcome this challenge using several architecture recovery techniques. We used the recovered models to examine if co-changes spanning multiple architecture modules are more likely to introduce bugs than co-changes that are within modules. The results show that the co-changes that cross architectural module boundaries are more correlated with defects than co-changes within modules, implying that, to improve accuracy, bug predictors should also take the software architecture of the system into consideration.

Software change history plays an important role in measuring software quality and predicting defects. Co-change metrics such as number of files changed together has been used as a predictor of bugs. In this study, we further investigate the impact of specific characteristics of co-change dispersion on software quality. Using statistical regression models we show that co-changes that include files from different subsystems result in more bugs than co-changes that include files only from the same subsystem. This can be used to improve bug prediction models based on co-changes.Index Terms-mining software repository, bugs, changes. I. PROBLEM AND MOTIVATIONMany researchers have used the information in source code, change history, and bug repositories to predict files that are likely to have defects in the future. Several studies indicate that prior modifications to a file are a good predictor of its fault potential [1,2,3,4,5]. For example, many studies show that the more a file is changed the more likely it is to contain faults. Sometimes several files are being changed together in a single commit to source code repository. We use the term co-change here as changes of files that are included in a single modification request. Several studies show that the number of co-changes is also a good predictor of faults [1,2]. For example, Hassan shows that the more spread the changes, the higher is the complexity of making those changes, thereby resulting in more bugs [2]. In addition, co-changes can be an indicator of a cross-cutting concern and concern scattering is known to be correlated with the number of defects [6,7].Although co-change could be a predictor for cross-cutting concerns, we believe that not all the co-changes are the same. A co-change that includes modules from different subsystems is a stronger predictor of cross-cutting concerns than a cochange that changes modules from the same component. The difference between previous studies on co-changes and ours is that we are investigating the impact of co-changes on the software system's quality from an architectural standpoint. We hypothesize that co-changes contained within the same subsystem do not have the same effect as co-changes dispersed across different subsystems. We believe we can obtain better insight about the relationship between co-changes and software quality by analyzing the nature of co-changes in more detail.A prerequisite in conducting this study is that we need to have insights into the subsystems comprising a software system under investigation. Unfortunately, most of the existing open source projects do not explicitly document the software architecture of the system. To address this challenge, we used Bunch, a reverse engineering tool that produces a subsystem decomposition model of a given software system by partitioning the system into a graph of entities (e.g., classes) and relations (e.g., function calls) in the source code [8].Empirical investigation of four apache projects has verified our hypothesis that co-changes in the same subsyst...