A Framework for the Assessment and Selection of Software Components and Connectors in COTS-based Architectures Jesal Bhuta 1 , Chris A. Mattmann 1, 2 , Nenad Medvidovic 1 , Barry Boehm 1 1 Computer Science Department University of Southern California Los Angeles, CA 90089 {jesal,mattmann,neno,boehm}@usc.edu 2 Jet Propulsion Laboratory California Institute of Technology Pasadena, CA 91109 mattmann@jpl.nasa.gov Abstract Software systems of today are frequently composed from prefabricated commercially purchased components and connectors that provide complex functionality and engage in complex interactions. Unfortunately, because of the distinct assumptions made by developers of these products, successfully integrating them into a software system can be complicated, often causing budget and schedule overruns. A large amount of integration risks can often be resolved by selecting the ‘right’ set of COTS components and connectors which can be integrated with minimal effort. In this paper we describe a framework for selecting COTS software components and connectors ensuring their interoperability in software-intensive systems. Our framework is built upon standard definitions of both COTS components and connectors and is intended for use by architects and developers during the design phase of a software system. We highlight the utility of our framework using a challenging example from the data-intensive systems domain. We describe empirical results gleaned from our experience using the framework in an advanced software engineering course at USC. We conclude by pointing the reader to future research directions. 1. Introduction The increasing complexity of software systems coupled with the decreasing costs of underlying hardware has ushered forth the realization of Brook’s famous “buy versus build” colloquy [1]. In the past, a business organization could afford spending $500,000 to manually develop, maintain and evolve a sophisticated payroll system for deployment on its costly two million dollar hardware. Nowadays however, a business organization that purchases $50,000 worth of off-the-shelf (OTS) office hardware cannot afford such a customized payroll program. Instead they often opt to purchase a commercial off- the-shelf (COTS) software system (or component) that can fulfill the same desired capabilities. Such COTS systems and components recurrently have diminished up-front cost, development time, maintenance, and evolution costs. These economic considerations often entice organizations to piece together COTS components into a working software system that meets the business’s organization requirements, and the system’s functional requirements, even at the expense of altering the organization’s existing business processes! Unfortunately over the past ten years numerous studies [2-6] have shown that piecing together available open source OTS and COTS components is quite dissimilar from custom development. Instead of the traditional requirements–design–develop–test– deploy process, COTS-based development involves activities such as assessment–selection–composition– integration–test–deploy. Tantamount to the success of the entire process, are the assessment and selection of the “right set” of COTS components and connectors. Careful and precise execution of these activities often ensures the development of a system on-time, on- budget and in line with the objectives of the project. There are two major components within the assessment and selection process: (1) assessment of COTS functional and non-functional requirements; and (2) assessment of interoperability to ensure that the selected COTS components will satisfactorily interact with each other. While the former has been addressed previously [2-6] an efficient solution to the latter has eluded researchers. The first example of such an interoperability issue was documented by Garlan et al. in [5] when attempting to construct a suite of software architectural modeling tools using a base set of 4 reusable components. Garlan et al. termed this problem architectural mismatch and found that it occurs due to (specific) assumptions that an OTS component makes about the structure of the application in which it is to appear that ultimately do not hold true.