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

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: 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 smcc@lcs.mit.edu, mernst@lcs.mit.edu 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

This note was uploaded on 02/24/2012 for the course CSE 503 taught by Professor Davidnotikin during the Spring '11 term at University of Washington.

Page1 / 10

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

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

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