Status

Advanced

Note

We recommend COTS and Open Systems--An Overview as prerequisite reading for this technology description.

Purpose and Origin

Component-based software development (CBSD) focuses on building large software systems by integrating previously-existing software components. By enhancing the flexibility and maintainability of systems, this approach can potentially be used to reduce software development costs, assemble systems rapidly, and reduce the spiraling maintenance burden associated with the support and upgrade of large systems. At the foundation of this approach is the assumption that certain parts of large software systems reappear with sufficient regularity that common parts should be written once, rather than many times, and that common systems should be assembled through reuse rather than rewritten over and over. CBSD embodies the "buy, don't build" philosophy espoused by Fred Brooks [Brooks 87]. CBSD is also referred to as component-based software engineering (CBSE) [Brown 96a, Brown 96b].

Component-based systems encompass both commercial-off-the-shelf (COTS) products and components acquired through other means, such as nondevelopmental items (NDIs).¹ Developing component-based systems is becoming feasible due to the following:

• the increase in the quality and variety of COTS products
• economic pressures to reduce system development and maintenance costs
• the emergence of component integration technology (see Object Request Broker)
• the increasing amount of existing software in organizations that can be reused in new systems

CBSD shifts the development emphasis from programming software to composing software systems [Clements 95].

Technical Detail

In CBSD, the notion of building a system by writing code has been replaced with building a system by assembling and integrating existing software components. In contrast to traditional development, where system integration is often the tail end of an implementation effort, component integration is the centerpiece of the approach; thus, implementation has given way to integration as the focus of system construction. Because of this, integrability is a key consideration in the decision whether to acquire, reuse, or build the components.

As shown in Figure 4, four major activities characterize the component-based development approach; these have been adapted from Brown [Brown 96b]:

• component qualification (sometimes referred to as suitability testing)
• component adaptation
• assembling components into systems
• system evolution

Figure 4: Activities of the Component-Based Development Approach

Each activity is discussed in more detail in the following paragraphs.

Component qualification. Component qualification is a process of determining "fitness for use" of previously-developed components that are being applied in a new system context. Component qualification is also a process for selecting components when a marketplace of competing products exists. Qualification of a component can also extend to include qualification of the development process used to create and maintain it (for example, ensuring algorithms have been validated, and that rigorous code inspections have taken place). This is most obvious in safety-critical applications, but can also reduce some of the attraction of using preexisting components.

There are two phases of component qualification: discovery and evaluation. In the discovery phase, the properties of a component are identified. Such priorities include component functionality (what services are provided) and other aspects of a component's interface (such as the use of standards). These properties also include quality aspects that are more difficult to isolate, such as component reliability, predictability, and usability. In some circumstances, it is also reasonable to discover "non-technical" component properties, such as the vendor's market share, past business performance, and process maturity of the component developer's organization. Discovery is a difficult and ill-defined process, with much of the needed information being difficult to quantify and, in some cases, difficult to obtain.

There are some relatively mature evaluation techniques for selecting from among a group of peer products. For example, the International Standards Organization (ISO) describes general criteria for product evaluation [ISO 91] while others describe techniques that take into account the needs of particular application domains [IEEE 93, Poston 92]. These evaluation approaches typically involve a combination of paper-based studies of the components, discussion with other users of those components, and hands-on benchmarking and prototyping.

One recent trend is toward a "product line" approach that is based on a reusable set of components that appear in a range of software products. This approach assumes that similar systems (e.g., most radar systems) have a similar software architecture and that a majority of the required functionality is the same from one product to the next. (See Domain Engineering and Domain Analysis for further details on techniques to help determine similarity). The common functionality can therefore be provided by the same set of components, thus simplifying the development and maintenance life cycle. Results of implementing this approach can be seen in two different efforts [Lettes 96, STARSSCAI 95].

Component adaptation. Because individual components are written to meet different requirements, and are based on differing assumptions about their context, components often must be adapted when used in a new system. Components must be adapted based on rules that ensure conflicts among components are minimized. The degree to which a component's internal structure is accessible suggests different approaches to adaptation [Valetto 95]:

• white box, where access to source code allows a component to be significantly rewritten to operate with other components
• grey box, where source code of a component is not modified but the component provides its own extension language or application programming interface (API) (see Application Programming Interface)
• black box, where only a binary executable form of the component is available and there is no extension language or API

Each of these adaptation approaches has its own positives and negatives; however, white box approaches, because they modify source code, can result in serious maintenance and evolution concerns in the long term. Wrapping, bridging, and mediating are specific programming techniques used to adapt grey- and black-box components.

Assembling components into systems. Components must be integrated through some well-defined infrastructure. This infrastructure provides the binding that forms a system from the disparate components. For example, in developing systems from COTS components, several architectural styles are possible:

• database, in which centralized control of all operational data is the key to all information sharing among components in the system
• blackboard, in which data sharing among components is opportunistic, involving reduced levels of system overhead
• message bus, in which components have separate data stores coordinated through messages announcing changes among components
• object request broker (ORB) mediated, in which the ORB technology (see Object Request Broker) provides mechanisms for language-independent interface definition and object location and activation

Each style has its own particular strengths and weaknesses. Currently, most active research and product development is taking place in object request brokers (ORBs) conforming to the Common Object Request Broker Architecture (CORBA).²

System evolution. At first glance, component-based systems may seem relatively easy to evolve and upgrade since components are the unit of change. To repair an error, an updated component is swapped for its defective equivalent, treating components as plug-replaceable units. Similarly, when additional functionality is required, it is embodied in a new component that is added to the system.

However, this is a highly simplistic (and optimistic) view of system evolution. Replacement of one component with another is often a time-consuming and arduous task since the new component will never be identical to its predecessor and must be thoroughly tested, both in isolation and in combination with the rest of the system. Wrappers must typically be rewritten, and side-effects from changes must be found and assessed. One possible approach to remedying this problem is Simplex (see Simplex Architecture).

Usage Considerations

Several items need to be considered when implementing component-based systems:

Short-term considerations

• Development process. An organization's software development process and philosophy may need to change. System integration can no longer be at the end of the implementation phase, but must be planned early and be continually managed throughout the development process. It is also recommended that as tradeoffs are being made among components during the development process, the rationale used in making the tradeoff decisions should be recorded and then evaluated in the final product [Brown 96b].
• Planning. Many of the problems encountered when integrating COTS components cannot be determined before integration begins. Thus, estimating development schedules and resource requirements is extremely difficult [Vigder 96].
• Requirements. When using a preexisting component, the component has been written to a preexisting, and possibly unknown, set of requirements. In the best case, these requirements will be very general, and the system to be built will have requirements that either conform or can be made to conform to the preexisting general requirements. In the worst case, the component will have been written to requirements that conflict in some critical manner with those of the new system, and the system designer must choose whether using the existing component is viable at all.
• Architecture. The selection of standards and components needs to have a sound architectural foundation, as this becomes the foundation for system evolution. This is especially important when migrating from a legacy system to a component-based system.
• Standards. If an organization chooses to use the component-based system development approach and it also has the goal of making a system open, then interface standards need to come into play as criteria for component qualification. The degree to which a software component meets certain standards can greatly influence the interoperability and portability of a system. Reference the COTS and Open Systems--An Overview description for further discussion.
• Reuse of existing components. Component-based system development spotlights reusable components. However, even though organizations have increasing amounts of existing software that can be reused, most often some amount of reengineering must be accomplished on those components before they can be adapted to new systems.
• Component qualification. While there are several efforts focusing on component qualification, there is little agreement on which quality attributes or measures of a component are critical to its use in a component-based system. A useful work that begins to address this issue is "SAAM: A Method for Analyzing the Properties of Software Architecture" [Abowd 94]. Another technique addresses the complexity of component selection and provides a decision framework that supports multi-variable component selection analysis [Kontio 96]. Other approaches, such as the qualification process defined by the US Air Force PRISM program, emphasize "fitness for use" within specific application domains, as well as the primacy of integrability of components [PRISM 96]. Another effort is Product Line Asset Support [PLAS 96].

Long-term considerations

• External dependencies/vendor-driven upgrade problem. An organization loses a certain amount of autonomy and acquires additional dependencies when integrating COTS components. COTS component producers frequently upgrade their components based on error reports, perceived market needs and competition, and product aesthetics. DoD systems typically change at a much slower rate and have very long lifetimes. An organization must juggle its new functionality requirements to accommodate the direction in which a COTS product may be going. New component releases require a decision from the component-based system developer/integrator on whether to include the new component in the system. To answer "yes" implies facing an undetermined amount of rewriting of wrapper code and system testing. To answer "no" implies relying on older versions of components that may be behind the current state-of-the-art and may not be adequately supported by the COTS supplier. This is why the component-based system approach is sometimes considered a risk transfer and not a risk reduction approach.
• System evolution/technology insertion. System evolution is not a simple plug-and-play approach. Replacing one component often has rippling affects throughout the system, especially when many of the components in the system are black box components; the system's integrator does not know the details of how a component is built or will react in an interdependent environment. Further complicating the situation is that new versions of a component often require enhanced versions of other components, or in some cases may be incompatible with existing components.

  Over the long-term life of a system, additional challenges arise, including inserting COTS components that correspond to new functionality (for example, changing to a completely new communications approach) and "consolidation engineering" wherein several components may be replaced by one "integrated" component. In such situations, maintaining external interface compatibility is very important, but internal data flows that previously existed must also be analyzed to determine if they are still needed.

Maturity

To date, the commercial components available and reliable enough for operational systems, and whose interfaces are well-enough understood, have primarily been operating systems, databases, email and messaging systems, office automation software (e.g., calendars, word processors, spreadsheets), and Graphical User Interface Builders. The number of available components continues to grow and quality and applicability continue to improve. As such, most successful applications have been in the AIS/MIS and C3I areas, with rather limited success in applications having real-time performance, safety, and security requirements. Indeed, in spite of the possible savings, using COTS components to build safety-critical systems where reliability, availability, predictability, and security are essential is frequently too risky [Brown 96b]. An organization will typically not have complete understanding or control of the COTS components and their development.

Examples of apparently successful integration of COTS into operational systems include the following

• Deep Space Network Program at the NASA Jet Propulsion Laboratory [NASA 96a]
• Lewis Mission at NASA's Goddard Space Center [NASA 96b]
• Boeing's new 777 aircraft with 4 million lines of COTS software [Vidger 96]
• Air Force Space and Missile System Center's telemetry, tracking, and control (TT&C) system called the Center for Research Support (CERES) [Monfort 96]

In addition to the increasing availability of components applicable to certain domains, understanding of the issues and technologies required to expand CBSD practice is also growing, although significant work remains. Various new technical developments and products, including Common Object Request Broker Architecture and Component Object Model (COM), DCOM, and Related Capabilities [Vidger 96] and changes in acquisition and business practices should further stimulate the move to CBSD.

Costs and Limitations

It is widely assumed that the component-based software development approach, particularly in the sense of using COTS components, will be significantly less costly (i.e., shorter development cycles and lower development costs) than the traditional method of building systems "from scratch." In the case of using such components as databases and operating systems, this is almost certainly true. However, there is little data available concerning the relative costs of using the component-based approach and, as indicated in Usage Considerations, there are a number of new issues that must be considered.

In addition, if integrating COTS components, an additional system development and maintenance cost will be to negotiate, manage, and track licenses to ensure uninterrupted operation of the system. For example, a license expiring in the middle of a mission might have disastrous consequences.

Dependencies

Adapting preexisting components to a system requires techniques such as Application Programming Interface, wrapping, bridging, or mediating, as well as an increased understanding of architectural interactions and components' properties.

Alternatives

The alternatives include using preexisting components or creating the entire system as a new item.

Complementary Technologies

The advantages of using the CBSD/COTS integration approach can be greatly enhanced by coupling the approach with open systems (see COTS and Open Systems--An Overview).

Domain Engineering and Domain Analysis aid in identifying common functions and data among a domain of systems which in turn identifies possible reusable components.

Index Categories

This technology is classified under the following categories. Select a category for a list of related topics.

Name of technology	Component-Based Software Development/ COTS Integration
Application category	System Allocation (AP.1.2.1), Select or Develop Algorithms (AP.1.3.4), Plan and Perform Integration (AP.1.4.4), Reengineering (AP.1.9.5)
Quality measures category	Maintainability (QM.3.1)
Computing reviews category	Software Engineering Design (D.2.10), Software Engineering Miscellaneous (D.2.m)

References and Information Sources

[Abowd 94]	Abowd, G., et al. "SAAM: A Method for Analyzing the Properties of Software Architecture," 81-90. Proceedings of the 16th International Conference on Software Engineering. Sorrento, Italy, May 16-21, 1994. Los Alamitos, CA: IEEE Computer Society Press, 1994.
[Brooks 87]	Brooks, F. P. Jr. "No Silver Bullet: Essence and Accidents of Software Engineering," Computer 20, 4 (April 1987): 10-9.
[Brown 96a]	Brown, Alan W. "Preface: Foundations for Component-Based Software Engineering," vii-x. Component-Based Software Engineering: Selected Papers from the Software Engineering Institute. Los Alamitos, CA: IEEE Computer Society Press, 1996.
[Brown 96b]	Brown, Alan W. & Wallnau, Kurt C. "Engineering of Component-Based Systems," 7-15. Component-Based Software Engineering: Selected Papers from the Software Engineering Institute. Los Alamitos, CA: IEEE Computer Society Press, 1996.
[Clements 95]	Clements, Paul C. "From Subroutines to Subsystems: Component-Based Software Development," 3-6. Component-Based Software Engineering: Selected Papers from the Software Engineering Institute. Los Alamitos, CA: IEEE Computer Society Press, 1996.
[IEEE 93]	IEEE Recommended Practice on the Selection and Evaluation of CASE Tools (IEEE Std. 1209-1992). New York, NY: Institute of Electrical and Electronics Engineers, 1993.
[ISO 91]	Information Technology - Software Product Evaluation - Quality Characteristics and Guidelines for their Use. Geneve, Switzerland: International Standards Organization/International Electrochemical Commission, 1991.
[Kontio 96]	Kontio, J. "A Case Study in Applying a Systematic Method for COTS Selection," 201-209. Proceedings of the 18th International Conference on Software Engineering. Berlin, Germany, March 25-30, 1996. Los Alamitos, CA: IEEE Computer Society Press, 1996.
[Lettes 96]	Lettes, Judith A. & Wilson, John. Army STARS Demonstration Project Experience Report (STARS-VC-A011/003/02). Manassas, VA: Loral Defense Systems-East, 1996.
[Monfort 96]	Monfort, Lt. Col. Ralph D. "Lessons Learned in the Development and Integration of a COTS-Based Satellite TT&C System." 33rd Space Congress. Cocoa Beach, FL, April 23-26, 1996.
[NASA 96a]	COTS Based Development [online]. Available WWW <URL: http://www-isds.jpl.nasa.gov/cwo/cwo_23/handbook/Dsnswdhb.htm> (1996).
[NASA 96b]	Create Mechanisms/Incentives for Reuse and COTS Use [online]. Available WWW <URL: http://bolero.gsfc.nasa.gov/c600/workshops/sswssp4b.htm> (1996).
[PLAS 96]	PLAS [online]. Available WWW <URL: http://www.cards.com/plas> (1996).
[Poston 92]	Poston R.M. & Sexton M.P. "Evaluating and Selecting Testing Tools." IEEE Software 9, 3 (May 1992): 33-42.
[PRISM 96]	Portable, Reusable, Integrated Software Modules (PRISM) Program [online]. Available WWW <URL: http://www.cards.com/PRISM/prism_ov.html>(1996).
[STARSSCAI 95]	Air Force/STARS Demonstration Project Home Page [online]. Available WWW <URL: http://www.asset.com/stars/afdemo/home.html> (1995).
[Thomas 92]	Thomas, I. & Nejmeh. B. "Definitions of Tool Integration for Environments." IEEE Software 9, 3 (March 1992): 29-35.
[Valetto 95]	Valetto, G. & Kaiser, G.E. "Enveloping Sophisticated Tools into Computer-Aided Software Engineering Environments," 40-48. Proceedings of 7th IEEE International Workshop on CASE. Toronto, Ontario, Canada, July 10-14, 1995. Los Alamitos, CA: IEEE Computer Society Press, 1995.
[Vidger 96]	Vidger, M.R.; Gentleman, W.M.; & Dean, J. COTS Software Integration: State-of-the-Art [online]. Available WWW <URL: http://wwwsel.iit.nrc.ca/abstracts/NRC39198.abs> (1996).

Current Author/Maintainer

Capt Gary Haines, AFMC SSSG
David Carney, SEI
John Foreman, SEI

External Reviewers

Paul Kogut, Lockheed Martin, Paoli, PA
Ed Morris, SEI
Tricia Oberndorf, SEI
Kurt Wallnau, SEI

Modifications

7 Oct 97: minor edits
20 Jun 97: updated URL for [NASA 96a]
10 Jan 97 (original)

Footnotes

¹ See the definition of NDI in COTS and Open Systems - An Overview.

² From Wallnau, K. & Wallace, E. A Robust Evaluation of the Object Management Architecture: A Focused Case Study in Legacy Systems Migration. Submitted for publication to OOPLSA'96.