Abstract
Component-based software engineering (CBSE) has rapidly gained currency over recent years. Software developed as components and as assemblies of components has realised the reuse slogan originally associated with object-oriented design. In this chapter we define what software components are along with their different characteristics and classifications. We also cover the widely debated definitions of software components to emphasise the fact that components possess different properties that can mean different things to different people. We discuss the impact of using components on the software development lifecycle and review a number of different approaches developed to procure and integrate components in software systems. Finally, the risks associated with using software components are discussed in detail with along with a trust model. Trends in CBSE research are discussed towards the end to explore some potential areas of future research.
TopIntroduction
Today, software components are available to software developers from numerous different sources including off-the-shelf (physical), component marketplaces (virtual) and within organisations, where teams of software engineers produce components for other teams within the organisation. While components have played an important role in bringing maturity to the software industry, they have also added new risks to software construction and use. It is very important for software engineers to understand the risks associated with using components, particularly off-the-shelf components.
Some of the earliest component frameworks emerged in the GUI domain with the arrival of 4GLs and Rapid Application Development (RAD). The objective of those frameworks was to allow developers to reduce their development time by reusing frequently used prebuilt user interface components. These component frameworks were very tightly coupled with the underlying development environment and as a result provided very well-defined interfaces.
The idea of treating units of software as independent components has existed for some time in the computing world. With the arrival of object-oriented (OO) paradigm, components gained increased popularity. However, while objects in the OO paradigm were very clearly defined along with their properties, the definition of software components triggered a series of useful debates among different researchers proposing different meanings for the term component.
Szyperski, Gruntz and Murer (2002) define software components as units of independent deployment and third-party composition with no externally observable state. This definition emphasises that a component encapsulates its constituent features and is deployable as a complete unit even when only a subset of its features are actually used by the consumer.
Meyer (1999) defines components as pieces of software that can be used by other program elements (clients) while the clients and their authors remain unknown to the authors of the component. This definition is closer to the idea of off-the-shelf components than that of components developed within the same organisation (or project) by developers who can easily communicate with other component developers.
Fundamentally, components are purely client-oriented pieces of software that are developed with a very clear distinction between the provider and the consumer. This distinction exists even when the provider and the consumer is the same entity. Components are developed to be used by other software components, systems, and users. This is achieved by packaging and presenting the features of the component to the outside world as an independently deployable unit. Whether the developers of a component are known to its consumers or not does not affect the component-hood of a piece of software. It should be noted that while the knowledge about the developers of a component can have direct implications on a consumer's trust in the component, it is irrelevant in the context of defining what a component is. Therefore, while we agree with Meyer's view of components as client-oriented software, we mainly use Szyperski's definition when investigating properties of software components in this chapter.
The debate on the definition of components has attracted a lot of attention in recent years (e.g. Carney, 2000; Basili, 2001; Clark, 2004). This has resulted in new varieties of components being suggested by researchers including the following:
Commercial-Off-The-Shelf (COTS): The term COTS (commercial-off-the-shelf) originated in a non-software engineering context where US military referred to different off-the-shelf components for their weaponry as COTS components. COTS components range from the smallest ActiveX components to the largest commercially off-the-shelf available database systems (like Oracle, SQL Server).
Modifiable-Off-The-Shelf (MOTS): These refer to components that can be modified either through customisation or direct modification of source code (e.g. open source components).
Key Terms in this Chapter
Component Based Software Engineering (CBSE): Software Engineering discipline that deals with building software systems from independent functional and/or logical components. Components in such systems have well-defined interfaces and communicate with one another via message-passing.
Service Components: Software entities that can be shared among multiple consumers, can be utilised by consumers on any platform and can be updated and improved by the provider without affecting consumers’ processes and interfaces.
Non-Functional Requirements: Requirements of a system that deal with aspects other than its functionality. Usually, these requirements are focused on how well the system does what it is required to do. Examples of non-functional requirements include performance, reliability, availability, scalability, security etc.
Interoperability: The ability of systems and components to interact with other systems and components, which are generally implemented on or for heterogeneous platforms. The focus is usually kept on information exchange between interacting systems.
Component Framework: Component frameworks are sets of well-defined interfaces that establish the protocols for component cooperation within the framework. These protocols are used by component developers to ensure the interoperability of their components within the scope of a given framework.
Emergent Behaviour: Behaviour of a system that emerges from the composition of its constituent parts and that is more than the sum of the behaviours of the independent constituent components.
Reusability: The property of a component or system to be used again and again, possibly in different scenarios. This term gained popularity with the arrival of object-oriented systems but can equally be applied to other types of software systems.
COTS Components: Commercial-off-the-shelf components. This term is used to refer to deployable units of software that offer a predefined set of services and are made available to consumers in a packaged form by vendors.