Chapter 10. Components, Frameworks, and Product Lines

• Need to understand the difference between testing components and objects? See Testing Components versus Objects.

• Want to understand how to create test cases from interfaces? See Testing in a Product Line Project.

• Want to understand how to test a framework? See Framework Testing Processes.

• Want to understand how testing can be organized in a software product line project? See Testing in a Product Line Project.

Each of the topics named in the title has testing issues in its own right and we will address them in this chapter. Together they also provide power to developers and challenges to testers. The issues of ease of reuse and flexible design have been addressed in earlier chapters at the object level. In this chapter we will consider these topics once again but in a context of the development of multiple applications through component composition with a framework.

A product line is a series of related software applications that are developed from a common architecture that is designed to accept modifications in certain predefined ways. This is an organizational strategy that deploys development teams in a series of related application construction projects. The teams use design and implementation techniques to realize large increases in productivity and quality. The basic architecture can be realized as a type of application framework. Components are shared among the teams who populate the frame work's implementation of the architecture with varying arrangements and combinations of the components.

A framework is a partially completed application that is designed to be modified in certain predetermined ways. This is an architecture realization strategy that uses design techniques such as design patterns and implementation techniques such as polymorphism. The object-oriented concept of a framework is designed with numerous abstract classes in strategic locations. The application developer specializes those classes that will provide the application-specific behaviors and accepts the default behaviors where appropriate. The more general component view of a framework replaces the abstract classes with interfaces that may be implemented by individual classes or more complex, even nonobject-oriented components.

Components have become the latest silver bullet for those people who could not solve all of their problems with objects. We have used the term in several places in the book without an explicit definition and you won't find one here. The term is applied to several different implementation technologies. We have been and will continue using component to mean a significant piece of functionality that, in our case, is supplied by a set of objects. A component implements a set of interfaces that specifies the behaviors available to the rest of the world. A component uses a packaging technology that encapsulates and hides the implementation.

Much of the discussion concerning distributed objects in Chapter 8, particularly the discussion about interfaces, applies to components. We will consider some differences between objects and components, but mainly in this chapter we will consider components in the context of frameworks and product lines.

Together these three ideas provide the technology to deliver high-quality, low-cost software applications. We will consider the interplay of the three and how the testing process can be optimized in a development environment that takes advantage of these techniques.