Paper Review
“Volume II: Technical Concepts of Component-Based Software Engineering, 2nd Edition”
By Felix Bachmann, Len Bass, Charles Buhman, Santiago Comella-Dorda, Fred Long, John Robert, Robert Seacord, and Kurt Wallnau
Part I
Jeff Schott
CS590L Distributed Component Architecture
Prof. Yugi Lee
January 21, 2004
Bachmann, et al present a feasibility study of component-based software engineering and assess its potential to advance the state of software engineering. The study is intended to establish a foundation for the Software Engineering Institute at Carnegie Mellon University to contribute to the development of component-based software engineering. This critique will cover the study in two parts. In this first part, the critique will cover the motivation of the report, its objectives, and some definitions of critical terminology. The second part of the critique will look at issues directly related to composition of component-based systems including frameworks, forms, and prediction and certification of behaviors. Because the study does not directly present a problem and propose a solution to the problem, the critique will not address the strengths and weaknesses of the proposal and suggest improvements. Instead, the critique will simply present the conclusions of the study and discuss those conclusions.
The report begins by presenting three objectives. First is to introduce the technical concepts of software component technology. Next is to understand component-based software engineering (CBSE) and how component technology should be used in this discipline. Finally is to highlight what is most significant among CBSE concepts, rather than develop definitions. The final objective may seem counter to the statement in the previous paragraph that definitions will be covered in this critique. However, a distinction must be made between definitions of critical terminology and definitions of critical CBSE concepts. Defining terminology is necessary to constrain the focus of the study, while defining CBSE concepts should be avoided in order to keep away from taking a stance on possible CBSE standards.
Software component technology and component-based systems are introduced in the second section. The concept of a design strategy is presented, which consists of the types of components in a system and their patterns of interaction. The design strategy is supported by software component technology, which are the products and concepts that make up component-based systems. A component-based design pattern diagram is given as a reference model for many of the component-based concepts to be discussed. The main features of the design pattern are presented in later sections of the paper, but four motivations are given for presenting the design pattern in the first place. These four are: independent extensions, component markets, reduced time-to-market, and improved predictability. The model is an idealized version of a component-based system and is only one of a number of possible interaction models. Many of the features may be combined or left out entirely when implemented in practice.
Because the field of component-based software engineering may encompass a number of aspects of the engineering discipline, the authors choose to narrow the focus for their vision of CBSE. This narrowed focus deals specifically with the rapid assembly of systems from certified components. That is, the components and frameworks have certified properties that provide the basis for predicting the properties of systems built from the components. CBSE implementations can be built from this foundation, with a clear and precise guiding principle. Having a focus this narrow, however, does not constrain certain other aspects of the design. This again avoids the prospect of defining CBSE principles, and allows freedom for implementers to focus on the aspects of a component-based framework that they find most important, but does not further the desire to have components that will interface with a number of other components and work within other component frameworks. Only broadening the focus and requiring adherence to the full definition of the component-based design pattern would achieve greater component interoperability.
Given the component-based design pattern and vision of CBSE, the authors now present a definition of a component that adheres to these principles. In this definition a component is characterized by the following criteria: it is an opaque implementation of functionality, it is subject to third party composition, and it is conformant with a component model. The definition does not deal with interfaces between components and other aspects of the component system framework. These are unique features of the system that are defined separately. The main point of the component definition is the concept of abstraction, which is a good software engineering practice in its own right.
Component integration is achieved through interfaces. An application programming interface (API) is a specification in a programming language of the properties of a module that clients can rely upon. This provides the foundation for a component interface, but APIs usually only express the functional properties of a module or component. To fully define an interface by including extra-functional properties, conventional APIs must be extended. This extension should also specify behavior, synchronization, and quality of service. Credentials are proposed as a means of specifying these properties by attaching a value and confidence pair to describe the manifestation of each property. Specifying credentials tends to blur the distinction between implementation and interface, which is counter to the previous definition of a component. However, a distinction must also be made between abstract and concrete interfaces. An abstract interface can have a fairly clean separation of interface and component, but when implemented certain properties may “bleed through” the interface. This distinction is important for certification, because implemented interfaces may exhibit properties not found in the abstract specification.
Interface contracts are a means of specifying the co-dependence between a component and the client that uses it. Contracts specify an agreement between two or more parties. The details are negotiated before parties become signatories, and normative and measurable behaviors are prescribed on all signatories. The contracts may not be changed unless all parties agree upon the changes. The contract imposes reciprocal obligations on the component and the client that can be expressed as pre- and post-conditions for component execution. Contracts can be thought of in two senses, one where the subject of the contract is a component and the other where the subject of the contract is the interaction. Component contracts specify services provided by the component and obligations of clients and the environment. Interaction contracts specify a pattern of interaction among different roles, and reciprocal obligations of components that fill these roles. Both senses of a contract are important for establishing the functional and extra-functional behavior of component interfaces.