Component Based Software Engineering: A Broad Based Model is Needed

Abstract Over the past few years, a number of different models of component-based software engineering have been proposed and discussed. We argue that many of these models are too narrow and/or informal, and that a broader and more precise foundation is needed for CBSE. 1. INTRODUCTION Component-based software engineering (CBSE) has existed in one form or another for a number of years. The idea of constructing modular software has long been recognized as advantageous within the software community, even dating back to the early days of FORTRAN programming with subroutines and libraries serving as “components.” Work by Booch [2] and Meyer [5] in the 1980’s was generally regarded as seminal in the advancement of ideas regarding the fundamental nature of components, particularly with regard to low-level structural properties of the components. More recent work [1,7,8,10,12] extended these ideas along various dimensions, including the introduction of formal specifications into component frameworks, the development of new paradigms for data movement, and the development of improved design guidelines for what constitutes a good component that is both efficient and independently verifiable. Over the past few years, advances in enterprise computing and client-server communities have generated renewed interest in the concept of CBSE, bringing the terms “component” and “component engineering” into widespread use within the software community. (Publications such as Component Strategies and the recent CBSE special issue of IEEE Software [3] represent the current popular view.) However, most current popular references to these terms are in a much different context than that described above. In particular, current popular CBSE references are to technologies such as COM, CORBA and JavaBeans that support the encapsulation of so-called “binary” components. Such CBSE references and the associated technologies are also linked to the support of distributed object computing, where the notion of a component seems to be linked (perhaps equivalent to) an encapsulated object-oriented software unit that is deployed within a distributed architecture. We feel that there is a tacit impression given in much of the current dialog that the modern notion of components is based upon a brand new set of ideas and concepts. For example, the following quote appears in [4]: “Components are now an evolution beyond objects, incorporating all the best aspects of objects, adding important new engineering concepts such as separation of interface and implementation, and enabling easier development through provision of rich runtime