Item Infomation
Full metadata record
| DC Field | Value | Language |
|---|---|---|
| dc.contributor | Program Analysis | - |
| dc.creator | McCamant, Stephen | - |
| dc.creator | Ernst, Michael D. | - |
| dc.date | 2005-12-22T01:25:58Z | - |
| dc.date | 2005-12-22T01:25:58Z | - |
| dc.date | 2004-03-30 | - |
| dc.date.accessioned | 2023-04-13T11:20:50Z | - |
| dc.date.available | 2023-04-13T11:20:50Z | - |
| dc.identifier | MIT-CSAIL-TR-2004-014 | - |
| dc.identifier | MIT-LCS-TR-941 | - |
| dc.identifier | http://hdl.handle.net/1721.1/30455 | - |
| dc.identifier.uri | http://lib.yhn.edu.vn/handle/YHN/740 | - |
| dc.description | This report presents a new, automatic technique to assess whether replacing a component of a softwaresystem by a purportedly compatible component may change the behavior of the system. The techniqueoperates before integrating the new component into the system or running system tests, permitting quickerand cheaper identification of problems. It takes into account the system s use of the component, becausea particular component upgrade may be desirable in one context but undesirable in another. No formalspecifications are required, permitting detection of problems due either to errors in the component or toerrors in the system. Both external and internal behaviors can be compared, enabling detection of problemsthat are not immediately reflected in the output.The technique generates an operational abstraction for the old component in the context of the system,and one for the new component in the context of its test suite. An operational abstraction is a set of programproperties that generalizes over observed run-time behavior. Modeling a system as divided into modules,and taking into account the control and data flow between the modules, we formulate a logical conditionto guarantee that the system s behavior is preserved across a component replacement. If automated logicalcomparison indicates that the new component does not make all the guarantees that the old one did, thenthe upgrade may affect system behavior and should not be performed without further scrutiny.We describe a practical implementation of the technique, incorporating enhancements to handle nonlocalstate, non-determinism, and missing test suites, and to distinguish old from new incompatibilities. Weevaluate the implementation in case studies using real-world systems, including the Linux C library and 48Unix programs. Our implementation identified real incompatibilities among versions of the C library thataffected some of the programs, and it approved the upgrades for other programs that were unaffected by thechanges.This report is a revision of the first author s Master s thesis, submitted January 2004. | - |
| dc.format | 51 p. | - |
| dc.format | 58257912 bytes | - |
| dc.format | 2025302 bytes | - |
| dc.format | application/postscript | - |
| dc.format | application/pdf | - |
| dc.format | application/postscript | - |
| dc.format | application/pdf | - |
| dc.language | en_US | - |
| dc.relation | Massachusetts Institute of Technology Computer Science and Artificial Intelligence Laboratory | - |
| dc.title | Predicting Problems Caused by Component Upgrades | - |
| Appears in Collections | Tài liệu ngoại văn | |
Files in This Item:
