upgrades-ecoop2004 - Early Identification of...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Early Identification of Incompatibilities in Multi-component Upgrades Stephen McCamant and Michael D. Ernst Massachusetts Institute of Technology Computer Science and Artificial Intelligence Laboratory 32 Vassar Street, Cambridge MA USA smcc@csail.mit.edu , mernst@csail.mit.edu Abstract. Previous work proposed a technique for predicting problems resulting from replacing one version of a software component by another. The technique reports, before performing the replacement or integrating the new component into a system, whether the upgrade might be prob- lematic for that particular system. This paper extends the technique to make it more applicable to object-oriented systems and real-world upgrades. First, we extend the theoretical framework to handle more complex upgrades, including components with internal state, callbacks, and simultaneous upgrades of multiple components. The old model is a special case of our new one. Second, we show how to handle four real- world situations that were not addressed by previous work: non-local state, non-determinism, distinguishing old from new incompatibilities, and lack of test suites. Third, we present a case study in which we up- grade the Linux C library, for 48 Unix programs. Our implementation identified real incompatibilities among versions of the C library that af- fected some of the programs, and it approved the upgrades for other programs that were unaffected by the changes. 1 Introduction A frequent cause of software failures is the use of software in unexpected or untested situations, in which it does not behave as intended or desired. Such problems are inevitable because it is impossible to foresee, much less to test, every possible situation in which software might be used. As one example, consider a software system that successfully uses a component. A supposedly compatible software upgrade may cause system failure or misbehavior if the system uses the new component in a manner for which it was not designed or tested. Even if the component developer conscientiously tests the component in many situations, the new component may not have been tested in an environment like the users, or the developer may have inadvertently changed the behavior in the users environment. This paper builds on previous research [15] that seeks to identify unantici- pated interactions among software components, before the components are ac- tually integrated with one another. The approach is to compare the observed 1 behavior of an old component to the observed behavior of a new component, and permit the upgrade only if the behaviors are compatible, for the way that the component is used in an application. The method issues a warning when the behaviors of the new and old components are incompatible, but lack of such a warning is not a guarantee of correctness, nor is its presence a guarantee that the programs operation would be incorrect....
View Full Document

Page1 / 25

upgrades-ecoop2004 - Early Identification of...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online