This preview shows pages 1–2. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: 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@example.com, firstname.lastname@example.org 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 systems 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/FSE03, September 15, 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....
View Full Document