{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

upgrades-fse2003 - Predicting Problems Caused by Component...

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

View Full Document Right Arrow Icon
Predicting Problems Caused by Component Upgrades Stephen McCamant Michael D. Ernst MIT Computer Science and Artificial Intelligence Lab 200 Technology Square Cambridge, MA 02139 USA [email protected], [email protected] ABSTRACT We present a new, automatic technique to assess whether replac- ing a component of a software system by a purportedly compatible component may change the behavior of the system. The technique operates before integrating the new component into the system or running system tests, permitting quicker and cheaper identification of problems. It takes into account the system’s use of the compo- nent, because a particular component upgrade may be desirable in one context but undesirable in another. No formal specifications are required, permitting detection of problems due either to errors in the component or to errors in the system. Both external and in- ternal behaviors can be compared, enabling detection of problems that are not immediately reflected in the output. The technique generates an operational abstraction for the old component in the context of the system and generates an opera- tional abstraction for the new component in the context of its test suite; an operational abstraction is a set of program properties that generalizes over observed run-time behavior. If automated logical comparison indicates that the new component does not make all the guarantees that the old one did, then the upgrade may affect sys- tem behavior and should not be performed without further scrutiny. In case studies, the technique identified several incompatibilities among software components. Categories and Subject Descriptors D.2.7 [ Software Engineering ]: Distribution, Maintenance, and Enhancement; F.3.1 [ Logics and Meanings of Programs ]: Speci- fying and Verifying and Reasoning about Programs— Pre- and post- conditions, Mechanical verification ; D.2.4 [ Software Engineer- ing ]: Software/Program Verification General Terms Languages, Reliability, Verification Keywords Software upgrades, specification matching, software components This research was supported in part by NSF grants CCR-0133580 and CCR- 0234651 and by a gift from NTT. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ESEC/FSE’03, September 1–5, 2003, Helsinki, Finland. Copyright 2003 ACM 1-58113-743-5/03/0009 ... $ 5.00. 1. INTRODUCTION Software is too brittle. It fails too often, and it fails unexpectedly. The problem is often the use of software in unexpected or untested situations, in which it does not behave as intended or desired [36, 9]. It is impossible to test software in every possible situation in which it might be used; in fact, it is usually impossible even to foresee every such situation.
Background image of page 1

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

View Full Document Right Arrow Icon
Image of page 2
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}