To appear in ICSE-2000 Workshop Proceedings of Continuing Collaborations for Successful COTS Development, May 2000. TOWARD IDENTIFYING THE IMPACT OF COTS EVOLUTION ON INTEGRATED SYSTEMS * L. Davis J. Payton R. Gamble Dept. of Mathematical & Computer Sciences University of Tulsa 600 S. College Ave., Tulsa, OK 74104 {davisl, payton, gamble}@euler.mcs.utulsa.edu (918) 631-2988 voice (918) 631-3077 fax * This research is sponsored in part by AFOSR (F49620-98-1-0217). 1. INTRODUCTION Evolution is inevitable when dealing with current software systems. Often it stems from user requests, developer needs, advancements in technology, and component upgrades. COTS products are especially susceptible to evolution, including radical changes, due to the need to attain and keep a broad customer base. Sometimes this evolution is embraced as customers see added functionality or performance in the upgraded product. Other times, the product has changed so drastically that customers may be wary of adopting it because of unknown bugs, missing functionality, or lack of backward compatibility. Problems created by component evolution are magnified when a COTS product is part of a system built from independent, heterogeneous components. Often an integration solution or middleware is used to bridge the interaction among components. When one component is modified or upgraded in a manner that alters its interaction properties, it can affect the way the middleware performs. Indeed, this is a weighty issue for developers because these changes can require that an expensive integration effort be redone. The reason is that evolution can generate additional component integration issues, while, at the same time, making others obsolete. How the impact of a component upgrade on interoperability is handled determines the complexity, and ultimately the cost, of changes to the existing middleware. Simple reinsertion of the component may, in fact, work if the evolution is not drastic. However, trial and error is not the best approach, because it will not provide any clues as to what integration solution changes to make when they are needed. In contrast, we advocate a priori analysis to predict the severity of new integration problems resulting from component evolution, allowing the developer to assess tradeoffs to replacing the component with its more recent self. This suggests that in some cases, perhaps the best cause of action is no action at all. To assess the gravity of evolution the developer must first identify those component properties that reflect evolutionary changes. These properties must be such that they can be expressable for COTS products due to the extent to which the products are self-contained. Our approach uses software architecture characteristics of the component as a basis for these properties. When assembling the integrated system initially, these component characteristics provide a meaningful aid to predict interoperability conflict that determines the resulting middleware. Consequently, we hypothesize that the impact on interoperability (both in terms of new and obsolete conflicts) can likewise be predicted, should the values of