The term component has been used since software engineering emerged as a discipline in 1968, and it reflects the analogy with other engineering disciplines. Like electronic devices that have pins and are connected with wires, software components are seen as independent software artefacts that can be used unchanged to build larger systems.
In most systems, it is usually easy to identify parts that are common to a number of applications. Each system may itself be considered a set of components collaborating to achieve the overall functionality. Ideally, systems could be built from components selected from a wide range, and connected or plugged together. The term Component-Based Development (CBD) (D'Souza and Wills, 1998) has been used for software developed by assembling existing components. CBD relies on the existence of libraries of components and on the publication of information about new components that can be used in other applications. It does not necessarily require object-oriented development, but the characteristics of object technology facilitate the development.
Mostly, it is not enough simply to connect components together; some extra code needs to be written to adapt their interfaces and guarantee that they can work together; this is usually called glue code. It is also accepted now that components, rather than being developed in isolation, should be developed within a framework for their application. The concept of product line (Clements and Northrop, 2002) is based on the idea that within a specific domain many different products can be developed with a similar structure and with well-identified variation points; these variations usually correspond to alternative components that can be plugged into the defined architecture.
Explain the differences between a component and a framework. How can they be used? Give an example of each.
The development of a framework is a difficult task that should take into account the different ways it may be used. Describe what is involved in developing a framework from an existing set of similar applications.
A component is used unchanged; a framework has to be customised by creating subclasses of classes of the framework and/or writing specific operations for the specific application of the framework. A product line well exemplifies the distinction between a framework and a component. A product line architecture defines a framework and a set of components that can be used within this framework, but it also has modification and extension points that make it applicable to a wide range of applications.
When a framework is being developed, it is necessary to consider what may be common across different applications in the same domain and abstract (factor out) the commonality in the framework. This involves defining abstract classes that can be specialised and writing operations specifically for each application.