When we look at the life cycle of a component, it passes through the following global stages, depicted in Figure 18.1: development, packaging, distribution, deployment, and execution. In the development stage, the design, specification, implementation, and meta data of components is constructed. In the packaging stage, all information that is needed for trading and deployment of the component implementation is grouped into a single package. The distribution stage deals with searching, retrieval, and transportation of components. The deployment stage addresses issues related to the integration of component implementations in an executable system on some target platform. Finally, the execution stage deals with executing and possibly upgrading components.

Figure 18.1. Stages of a component life cycle

Across these different stages of their life cycle, components are represented in different forms. In the development stage, components may be represented by means of a design or specification language, such as a set of UML diagrams, and as a set of source-code and configuration files, such as a directory with .c and .h files for C or a set of class files in case of Java, that together can be turned into executable code. In the packaging stage, the files that together form a component are bundled into a single unit, for example in a compressed file. In the distribution stage, packaged components are represented in a format that can be transmitted across a network or stored on some physical carrier such as a disk or memory stick. This may be standardized by a component model but, in general, distribution formats are from the area of distributed systems – nowadays, mostly Internet standards. At the deployment stage, components are unpackaged in a form that can be installed onto a target machine. In the execution stage, components take the form of blocks of code and data in the memory of a processor and cause a set of actions on this processor. All these forms are different views on, or manifestations of, what is logically a single building block.

Cheesman and Daniels (2000) introduce convenient terminology for denoting the different forms of components. Figure 18.2 shows the distinction between different forms of components that they introduced and the relations between them. Figure 18.3 shows how these different forms relate to different stages of development.

The component specification describes properties that are, or should be, realized by the corresponding component implementation. Many different properties may be included in a specification. A component specification typically includes the following important properties:

Figure 18.2. Characterization of component forms

Figure 18.3. Forms of a component at different stages of the life cycle

Of course, these properties should be specified in a complete, precise, and verifiable way.

The interface of a component is defined in the design stage and continues to play an important role in execution time. A component interface defines the actions through which components may communicate with each other. Interfaces are offered by one component in order to be used by other components. The component that offers an interface is responsible for realizing the actions of the interface. The component that uses the actions of an interface only needs to know what the action achieves, not how it is achieved. In this sense, users of an interface are shielded from the machinery that is used to implement it. This shielding is a means of abstraction – details about the realization are omitted. As a result of this abstraction, different implementations of an interface may be used to realize some action without users of the interface being aware of it. This is, of course, the basic idea of information hiding, as discussed in Chapter 12.

A typical use of this property of interfaces is to replace a component by a newer version (see Figure 18.4). This figure shows that component P can be replaced by component P'if P'realizes the same interface Ix. Component Rthat uses interface Ixneed not be changed. The component that offers an interface is called the provider of that interface; the component that uses the interface is called the requirer of the interface.

Figure 18.4. Component P can be replaced by component P' if P' realizes the same interface Ix

The purpose and scope of a component specification differ from the purpose and scope of a component interface. The most important difference is that specifications define a realization contract, while interfaces describe usage contracts. During development of a component, the specification is a prescription of what the implementation should realize. As such, the specification may include the definition of interfaces. Once the implementation of a component is finished, a specification describes what architects and developers who wish to use a component may want to know about it. Here, the specification is used to understand the component.

A component specification and an interface also differ in scope: if a component has multiple interfaces, these are all listed as part of the specification. The scope of a specification is the component as a whole. As such it needs to specify the way in which the interfaces of a component relate to each other.

A component implementation is a realization of a component specification. There has been some discussion on how strict the hiding of internals of components should be. The black-box requirement for components has been criticized as being too strong a constraint. For the purpose of tailorability or testability, components should disclose more of their internals. Several variants of black box have been proposed; they differ in the degree to which the internals of components can be inspected and changed by parties other than its developer:

A component package is a unit of distribution. A package contains the implementation of a component, relevant data files, meta-data about the component, and meta data about the package. The meta-data of a package contains a table of contents of the files in the package. It may be compressed to improve download time, and encrypted and certified to improve security. It can be compared to the way a ZIP file can be used to package a collection of files into a single unit.

Finally, the component instance consists of the executable code and associated data in the target machine. The relation between a component implementation and a component instance is like the relation between a class and an object. The component instance will form part of the execution architecture of the running system. The execution architecture determines the performance of a system by defining the mapping of functionality onto run-time entities (such as processes and resources) in a system. The component instance has to conform to conventions that are dictated for this purpose by the software architecture.

Since the mid 1990s, software architecture has been recognized as an important intermediate artifact of software engineering projects. The goal of a software architecture is to define the key principles and guidelines for developing a software system such that the resulting system and process meets its functional and quality requirements (see Chapter 11).

The functional requirements can be achieved by defining a functional decomposition of a system. Functionality behaves relatively nicely in an additive manner: to increase the functionality of a system, we just add a new subsystem. Achieving the quality properties of a system is often more difficult. One complicating factor is that quality properties do not have the additive property, but are the collective result of interaction by all parts of a system. The performance of a system is not 'handled' by one component; it is 'everywhere'. In order to achieve some set of quality properties, all parts of a system must adhere to certain principles. Since quality is to a large extent determined by the software architecture (see Chapter 11), component-based software engineering requires that attention be paid to the software architecture.

To successfully develop systems in a component-based manner, an architectural plan needs to be in place that organizes how components fit together and how, once assembled, a system meets its quality requirements. In an ideal case, the development of a system is driven by an architecture that is developed up front. Based on this architecture, a component model is selected or a dedicated component model is developed such that the rules of the component model match those of the architecture. Examples of dedicated component models are the Koala model (Ommering et al., 2000) developed for meeting resource constraints in consumer devices, and the SaveCCM (Åkerholm et al., 2007) model developed for meeting dependability requirements in the automotive domain. As these examples illustrate, dedicated component models are developed in domains that have rather specific quality requirements.

Developing a proprietary component model takes a lot of effort. Therefore, a practical alternative is to select the architecture and component model in concert. To this end, a set of candidate architectures and a set of candidate component models are selected. The choice of a particular component model limits the possible architectures that can be realized. If a component model is not an ideal match with the target architecture, then some additional work is needed to provide extra features or eliminate (or hide) superfluous features. So, an architecture constrains the possible component models and a component model constrains the possible architectures. Typical issues that are the subject of architectural decisions which may influence the choice between a custom architecture and custom component model versus a commercial component model are: security mechanisms, transaction mechanisms, and scheduling policies. Typically, policies for such issues are hard-wired into commercial component models, but can be tailored when designing a custom component model.

There are different approaches to dividing the responsibility for managing quality properties between components and the execution platform. The different types of approach are characterized by the reference architectures shown in Figure 18.5. The grey areas in this figure denote the locations where logic resides that handles quality properties of the system. These reference architectures talk about quality properties in general. An instance of the architecture could be concerned with performance, security, reliability. There are two main dimensions in which these approaches differ in managing quality properties:

Figure 18.5. Management of quality, or extra-functional properties (EFP)

Many component models provide no specific facilities for managing quality properties. The way a property is handled is, in that case, left to the designers of the system; as a result, a property may not be managed at all (approach A, in Figure 18.5). This approach makes it possible to include policies for managing quality properties that are optimized towards a specific system and can also cater for adopting multiple policies in one system. This heterogeneity may be particularly useful when commercial off-the-shelf (COTS) components need to be integrated. On the other hand, the fact that such policies are not standardized may be a source of architectural mismatch between components.

The compatibility of components can be improved if the component model provides standardized facilities for managing quality properties (approach B in Figure 18.5). In this approach, there is a mechanism in the component execution platform that contains policies for managing quality properties for individual components as well as for quality properties involving multiple components. The ability to negotiate the manner in which quality properties are handled requires that the components themselves have some knowledge about how the quality properties affect their functioning. This is a form of reflection.

A third approach is that the components should be designed such that they address only functional aspects and no quality properties. Consequently, in the execution environment these components are surrounded by a container. This container contains the knowledge on how to manage quality properties. Containers can either be connected to containers of other components (approach C in Figure 18.5) or they can interact with a mechanism in the component execution platform that manages quality properties on a system-wide scale (approach D in Figure 18.5). Approach C manages interaction between two components. In approach D, the scope of the management can be global across the system.

The container approach is a way of realizing separation of concerns in which components concentrate on functional aspects and containers concentrate on quality aspects. In this way, components become more generic because no modification is required to integrate them into systems that may employ different policies for managing quality properties. Since in this approach components do not address quality properties, they are simpler and smaller, and hence cheaper to implement or integrate.

As well as the differences discussed above, component models also have a number of features in common. An overview of these common features is given in Table 18.1. The features common to component models are:

To illustrate the specifics of the component-based development process we use the simple waterfall model as a reference. However, the illustration can relatively simply also be applied to other development processes. Figure 18.6 shows the main activities of a typical component-based waterfall life cycle model: requirements engineering, analysis and design, implementation, test, release, and maintenance.

The primary idea of the component-based approach is to (re)use the existing components instead of implementing them whenever possible. For this reason, the availability of existing components must be considered even in the requirements and design phases.

Figure 18.6 shows a simplified and idealized process. Its assumption is that the components selected and used are sufficiently close to the units identified in the design process that the selection and adaptation processes require (significantly) less effort than the components' implementation. Further, the figure shows only the process related to system development and not the supporting processes that have to do with the assessment of components and the development of components.

While development of component-based systems significantly decreases the detailed design and implementation effort during system development, it requires additional effort in other activities. For example, instead of implementing the required functions, developers have to search for components that provide such functionality. Developers must also verify that the selected components provide (or approximate) the desired functionality, and that they can successfully be integrated with other components. A consequence might be that the best components are not selected but rather the components that best fit together.

To make the system development process efficient, many assessment activities can be performed independently, separate from system development. A generic assessment process includes the following activities:

The component development process is in many respects similar to the system development process: requirements must be captured, analyzed, and defined; the component must be designed, implemented, verified, validated, and delivered. When building a new component, developers will reuse other components and will use similar procedures of component evaluation as for system development. There is, however, a significant difference: components are intended for reuse in (many) different products, many of them yet to be designed. The consequences of this difference are the following:

Below, we highlight the specific characteristics of activities of a component development and maintenance process.

Requirements Engineering. Requirements specification and analysis is a combination of a top-down and a bottom-up process. The requirements elicitation should be the result of the requirements specification at the system level. However, since the components are also built for future systems, not even yet planned, these system requirements have not necessarily been identified. For this reason the process of capturing and identifying requirements is more complex. It must address ranges of requirements and possible reusability. Reusability is related to generality, thus the generality of the components should be addressed explicitly.

Analysis and Design. The input to the design phase in the component development process comes from system design, system constraints, and system concerns. Since such systems do not necessarily exist yet, the component designer must make many assumptions about the system. Many assumptions and constraints are determined by selecting a component technology. The component technology determines, for example, possible component interactions, certain solutions built into the technology (such as transactions or security mechanisms), and assumptions of system resources (such as scheduling policies). For this reason, it is most likely that a component model and a component technology that implements that model must be chosen at design time.

For a component to be reusable, it must be designed in a more general way than a component tailored for a unique situation. Components intended to be reused require adaptability. This increases the size and complexity of the components. At the same time, they must be concrete and simple enough to serve particular requirements in an efficient way. This requires more design and development effort. Developing a reusable component may require three to four times more resources than developing a component which serves a specific purpose (Mili et al., 2002).

Implementation. Implementation of components is, to a large extent, determined by the component technology selected. The component technology provides support in programming languages and automation of component compositions. It may include many services and provide many solutions that are important for the application domain. Good examples of such support are transactions management, database management, security, and interoperability support for distributed systems provided by component technologies such as .NET, J2EE, or COM+.

Integration. Components are built to be easily integrated into systems. For this reason, integration considerations must be continuously in focus. Usually, component technology provides good support for components integration and integration is being performed on a daily basis.

Test. Test activities are of particular importance for two reasons. First, the component should be very carefully tested since its usage and environment context is not obvious. No specific conditions should be taken for granted, but extensive tests and different techniques of verification should be performed. Second, it is highly desirable that the tests and test results are documented and delivered with the component to system developers.

Release. Release and delivery of the components is the phase where (assemblies of) components are packaged into sets that are suitable for distribution and installation. Such a package not only includes the executable components, but also additional information and assets (meta-data that specifies different properties, additional documentation, test procedures, test results, etc.).

Maintenance. A specific aspect of maintenance in component-based systems is the relation between a component and the systems it is used in. If a bug in a component is fixed, the question is to which systems a new version of the component should be delivered. Who will be responsible for the update: the component producer or each of its consumers? There is also the question of who is responsible for component maintenance: is this a responsibility of the component producer or the producer of the system this component is part of? Do component producers have the obligation to fix bugs and support updates in the systems that make use of their components? Can they provide support in return for additional payment?

Even more difficult problems are related to 'blame analysis'. The issue is related to a manifestation of a fault and the origin of the fault itself. A fault might be detected in one component, but the cause of that fault might be in another component. For example, due to a high frequency of input in component A, component A requires more CPU time. As a consequence, component B does not complete its execution during the interval assumed by component C. Component C then issues a time-out error and a user of component C gets the impression that an answer from component C was not delivered. A first analysis shows that the problem is in component C, then B, then A, and finally in the input to A. The question is: who performs this analysis if the producers of components A, B, and C are different? Such situations can be regulated by contracts between the producers and consumers of the components, but this requires additional effort and, in many cases, it is not possible at all.

The above example shows that maintenance activities can be much more extensive than expected. For this reason, it is important that component producers build a strategy for performing maintenance and take corresponding actions to ensure the realization of this strategy. For example, component producers might decide to provide maintenance support; it is then important that they can reproduce the context in which the error manifested.

This is a top-down approach. Here, components are identified as part of an architectural design. The componentization of the architecture serves as a way of achieving a high level of modularity. Components are not primarily developed for reuse, but rather as pieces to fit into the specified architectures (in the same way as pieces in a jigsaw puzzle). In the implementation, component-technologies (such as .Net) are used, but this is mainly because of the extensive support of component technology for modeling and specification, because of easier implementation, and the possibility of using standard services of a component technology. The genericity of these components is limited: they only have to fit the architecture they were designed for. Reusability and time-to-market issues are of less concern.

An example of this approach would be the software that controls flying an aircraft. It requires a dedicated architecture where each of the components has highly domain-specific functionality. However, a component-based approach would allow replacing of individual components by newer versions.

This approach has a strong top-down direction, but also some bottom-up elements. In contrast to the previous approach, this approach aims to enable efficient development of many variants of products – sometimes called a family of products or a product-line. Such families are common in consumer products such as mobile telephones, televisions, and home audio equipment. Product-line development tries to cater for easily making and maintaining many variants of a products with minimal technical diversity at minimal costs. The solution for this is sought in component-based architectures. This architecture defines the common parts of the system and the parts that are variable.

As an example of this approach, consider a product family of consumer electronics products which includes CD players, DVD players, and mobile phones. In this case, careful design of the architecture would allow an MP3 decoding component to be integrated into the architecture of the CD player, DVD player, and mobile phone.

The component-based character of the architecture plays a crucial role: it enables reuse of components and efficient integration. Composability, reusability, and time-to-market are equally important.

It is characteristic of product lines that the architectural solution has a direct impact on the component model. The component model must comply with the pre-defined reference architecture. In practice, many companies have developed their own component model that suits their proprietary architecture. A second characteristic of product-line architectures is a high degree of concurrency between the component development process and product development process and a combination of top-down and bottom-up procedures.

This is mostly a bottom-up approach: it tries to assemble a system from existing components. The architecture of the system is secondary to the combinations of components that are available.

From the perspective of the system developer, the strongest driver for this approach is time to market: what components exist that we can quickly assemble into a system? For this approach to work, there must be component developers that aim at developing highly reusable functionality. Overall, this approach assumes that the system development process is completely separate from the development processes of components.

While the COTS approach gives instant value in new functionality, there are a number of problems in this approach that complicate its realization: because components were not designed to comply to a component model or to fit together, this approach may run into problems of composability. This may occur if the semantics are not clear or if architectural properties of the components are not properly and adequately documented. For COTS-based development, component assessment plays a much more important role than in the previous two approaches.

As an example of this approach consider a Web store. Web stores now have a fairly crystallized architecture that has a fair amount of commonality with the architecture of many business information systems. A Web-store system can be assembled by buying components that are sold as building blocks on the software market. Typical components include: database, Web server, search engine, payment handler, and stock-control system. In this case, a selection is made of which (combination of) components is most appealing and then an architecture is designed which integrates these components.

Which of these approaches is best or most CBSE-specific? There is no definitive answer. After a surge of enthusiasm in both industry and research, the COTS components market has decreased and does not show revolutionary improvement. One of the reasons for that is that it is difficult to achieve reusability by being very general, effective, and simple and, at the same time, provide attractive functionality. Furthermore, there are problems of trustworthiness (who can guarantee that the component is correct?), component verification, and certification.

The product-line approach has been successful in many domains and its combination with CBSE is a promising approach. Possible threats are the increasing costs of development and maintenance of the component technologies developed internally, and the pace of technological innovations in compilers, debuggers, and integrated development environments. In some cases, the internally developed component technologies are replaced by widely used general-purpose component technologies, while keeping the overall product-line approach.