When | What |
---|---|
April 9th, 2015 | Donated by Jacob Swanson |
Studies who have been using the data (in any form) are required to include the following reference:
@inproceedings{Swanson:2014:BRS:2635868.2635915,
author = {Swanson, Jacob and Cohen, Myra B. and Dwyer, Matthew B. and Garvin, Brady J. and Firestone, Justin},
title = {Beyond the Rainbow: Self-adaptive Failure Avoidance in Configurable Systems},
booktitle = {Proceedings of the 22Nd ACM SIGSOFT International Symposium on Foundations of Software Engineering},
series = {FSE 2014},
year = {2014},
isbn = {978-1-4503-3056-5},
location = {Hong Kong, China},
pages = {377--388},
numpages = {12},
url = {http://doi.acm.org/10.1145/2635868.2635915},
doi = {10.1145/2635868.2635915},
acmid = {2635915},
publisher = {ACM},
address = {New York, NY, USA},
keywords = {Configurable Software, Self-Adaptive Software},
}
There are three dataset files supplemental to the study:
Self-adaptive software systems monitor their state and then adapt when certain conditions are met, guided by a global utility function. In prior work we developed algorithms and conducted a post-hoc analysis demonstrating the possibility of adapting to software failures by judiciously changing configurations. In this paper we present the REFRACT framework that realizes this idea in practice by building on the self-adaptive Rainbow architecture. REFRACT extends Rainbow with new components and algorithms targeting failure avoidance. We use REFRACT in a case study running four independently executing Firefox clients with 36 passing test cases and 7 seeded faults. The study show that workarounds for all but one of the seeded faults are found and the one that is not found never fails — it is guarded from failing by a related workaround. Moreover, REFRACT finds workarounds for eight configuration-related unseeded failures from tests that were expected to pass (and did under the default configuration). Finally, the data show that when a failure and its workaround are found, configuration guards prevent the failure from appearing again. In a simulation lasting 24 hours we see over 150 guard activations and no failures with workarounds remaining beyond 16 hours