Component-Based Software Development — An Overview
Abstract
This page presents a general overview of component-based software development. The development process is briefly covered and some active areas of research in CBSD are described.
1. Introduction
Component-based software development (CBSD) or component-based software engineering (CBSE) is concerned with the assembly of pre-existing software components into larger pieces of software. Underlying this process is the notion that software components are written in such a way that they provide functions common to many different systems. Borrowing ideas from hardware components, the goal of CBSD is to allow parts (components) of a software system to be replaced by newer, functionally equivalent, components.
The idea is not new. Componentizing software had been suggested by McIlorys (McIlroys 1969) as a way of tackling the software crisis, yet only in the last decade or so has the idea of component-based software development taken off. Nowadays there is an increasing market place for Commercial Off-The-Shelf (COTS) components, embodying a buy, don't build
(Brooks 1987) approach to software development. The promise of CBSD is a reduction in development costs: component systems are flexible and easy to maintain due to the intended plug-and-play nature of components.
2. The Development Process
Component-based software development encompasses two processes:
1. assembling software systems from software components and
2. developing reusable components.
The activity of developing systems as assemblies of components may be broadly classified in terms of four activities.
1. component qualification,
2. component adaptation,
3. component assembly, and
4. system evolution and maintenance.
Although the process differs from traditional software development, there are still problems common to both CBSD and traditional methods, for example, the problem of managing change and maintenance in developed software. In the following subsections we give a brief description of each of the above activities.
2.1. Qualification
Qualification is the process for determining the suitability of a component for use within the intended final system. When a marketplace of competing products exists, it also involves the selection of the most suitable component. Selection is dependent on the condition that measures exist for comparing one component against another and evaluating the fitness of use of components. It is during this activity that the issues of trust and certification arise. The process of certification is two-fold (Bachman et al. 2000):
1. to establish facts about a component and to determine that the properties a component possesses is also conformant with its published specification; and
2. to establish trust in the validity of these facts, perhaps by having a trusted third-party organisation attest the truth of this conformance and to provide a certificate to verify this.
The motivation for component certification is that there is a causal link between a component's certified properties and the properties of the end system. If enough is known about the (certified) components selected for assembly then it may be possible to predict the properties of the final assembled system. Accuracy in prediction is founded on the degree of trust in a component and also how well the glue that joins the components is understood. For many of components in the marketplace prediction is difficult because of a lack of information about a component's capabalities and a lack of trust in this information.
Conventional software doctrine states that component specifications should be sufficient and complete, static — writable once and frozen, and homogenous. However, full specifications may be impractical: some components may exhibit (non-functional) properties which are infeasible to document, let alone to document in a homogenous notation (some practitioners go as far to say that reusable components do not exist yet). One method for addressing this issue is to use credentials (Shaw 1996) — knowledge-based specifications that evolve as more is discovered about a component.
2.2. Adaptation
Individual components are written to meet different requirements, each one making certain assumptions about the context in which it is deployed. The purpose of adaptation is to ensure that conflicts among components are minimised. Different apporaches to adaptation depend upon the accessibility of the internal structure of a component.
White-box components may be significantly rewritten to operate with other components.
Grey-box components provide their own extension language or application programming interface (API).
Black-box, or binary, components have no extension language or API.
Ideally, a component is a black box, its services are only accessible through some well-defined interface. However, as shall be seen in the sequel, there is nothing to stop us from considering white or grey box components.
2.3. Assembly
Assembly is the integration of components through some well defined infrastructure, which provides the binding that forms a system from disparate components. COTS components, for example, are usually written to some component model defined by e.g., Enterprise JavaBeans, COM, CORBA, or, more recently, .NET.
2.4. System Evolution and Maintenance
Because components are the units of change, system evolution is based around the replacing of outdated components by new ones, or, at least, ideally. The treatment of components as plug-replaceable units is a simplistic view of system evolution. In practise, replacing a component may be a non-trivial task, especially when there is a mismatch between the new component and old one, triggering another stage of adaptation with the new component.
3. Software Components?
But what, exactly, is a software component? There is no single answer to the question. Szyperski, for example, offers the following definition. A software component is a unit of composition with contractually specified interfaces and explicit context dependencies. An interface is a set of named operations that can be invoked by clients. Context dependencies are specifications of what the deployment environment needs to provide, such that the components can function. (Szyperski et al. 2002)
D'Souza and Wills offer another. A package of software that includes implementation, with a specification of interfaces provided and required. (D'Souza and Wills 1998)
Most definitions converge to some degree but differences arise in the fact that there are different conceptions about what a component can be. Traditionally, a component is considered to be an implementation-level unit of deployment. However, it is not unheard of for some to consider abstract specifications or even design documents to be components in their own right. Reusable artifacts may occur at any level of the development cycle, in particular there is an increased interest in business-level components which are independent of any specific implementation or middleware technology. This has prompted the distinction between component-based systems engineering and component-based software engineering, where the former refers to the process of reusing requirements and specifications. There, changes are made at the requirements or specification level and code where they may be validated and the resulting code may either be generated automatically or manually.
4. CBSD Research Areas
As alluded to in the preceding sections, component-based software development encompasses many areas of research, some of which have been active research areas in traditional software development paradigms. Below are descriptions of some of these research topics.
4.1. Component Modelling and Specification
The Unified Modeling Language (UML) has become the de facto standard for nearly all application modelling and has been employed in CBD methods such as the Catalysis method (D'Souza and Wills 1998). Prior to UML version 2.0, however, there has been a need to extend UML to allow for more appropriate descriptions of a component's dependencies and also of its interface specification. These issues have been addressed in the book UML Components (Cheesman and Daniels 2001).
Besides UML, however, there is a large body of work on how the component-based development process can be approached formally. Specification-wise this work includes the specification of a component's interface — its operations' functional specifications or the specification of its interaction protocols, i.e., constraints on how and when an operation may be invoked.
4.2. Retrieval Techniques and Specification Matching
The issue of how to retrieve reusable artefacts has long been a research area in software reuse. Much of the work on retrieval has focused on what forms component descriptions should take in order that components can be retrieved from repositories while specification matching techniques are employed to search for components based on functional or behavioural criteria.
4.3. Generative Approaches to Component Development
Generative approaches are concerned with the generation of software from specifications. These techniques are employed within the context of component-based systems engineering described above. A brief mission statement on generative and component-based software engineering and associated research areas see the home page of theWorking Group on Generative and Component Based Software Engineering.
4.4. Adaptation Techniques
As mentioned previously, different adaptation techniques can be employed for black, grey, or white box components. Research on adaptation can range from wrapping techniques to more sopisticated methods such as identifying appropriate adapters for specification matching. Related work on adaptation techniques includes how the reusability of a component can be improved by considering how freely they can be adapted while they are being developed.
4.5. Coordination and Composition Languages
In the absence of a defined component infrastructure, e.g., COM and CORBA, coordination and composition languages may be used to describe the wiring or glue for component assembly. These languages may also be used to define the ways in which software may be composed within some given framework or how components interact across systems.
4.6. Verification, Testing, and Certification
CBSD implies that a component undergoes two test phases. The first phase occurs during development, verifying whether a component meets its specification and fulfils its functional requirements. A component may be certified by a third party acording to how the component performs during this round of testing. The second phase is concerned with testing how the component integrates with others during the development of a component-based system. Different testing strategies may be employed according to the visibility of the component's internal structure. Usually, for COTS components, black-box techniques are employed. For source code components, white-box techniques may be used.
4.7. Configuration Management
Software configuration management referes to the process of controlling systems evolution, establishing those apsects of a system that are likely to change and defining mechanisms for managing different versions of these aspects.
5. Summary
Component-based software development promises to reduce development costs by enabling rapid development of highly flexible and easily maintainable software systems.
In this cursory overview, we have described the different stages of the component-based development process. The success of a CBSD project depends on the ability to overcome the problems associated with each of these stages. Some of these problems are inherent in traditional software development paradigms. Some of the problem areas pertaining to CBSD have been described briefly.
Additional Information
An alternative review of the issues in component-based development is presented in the short paper Component Software Engineering: A Brief Review.
For more information about the component-based software development process (within the context of COTS), we refer the reader to the article Component-Based Software Development/COTS Integration from the Carnegie Mellon Software Engineering Institute (SEI).
The SEI also provides the following technical report examining the state of software component technology from a business perspective: Volume I: Market Assessment of Component-Based Software Engineering.
Software Component Testing Strategies, by Adrita Bhor, provides a discussion of testing techniques in the context of CBSD.
Books on the component-based development process include
A.W. Brown, Large Scale Component Based Development, and
I. Crnkovic and M. Larsson (Editors), Building Reliable Component-Based Software Systems, Artech, 2002.
For more information about the CORBA, COM, JavaBeans, and .NET technologies, consult the following pages:
the Object Management Group's CORBA web site,
Microsoft's Component Object Model (COM) technologies web site,
Sun's Enterprise JavaBeans Technology page, and
the Microsoft .NET home page.
