In component based software engineering (CBSE), systems are assembled from existing components. In CBSE, there are independent development processes for components and for systems built out of components. Composing a system out of components is only possible if those components conform to the same set of standards, also known as their component model. Component models differ in the way they handle quality properties. Component models differ in the way they handle quality properties. Component models affect software architecture and vice versa.

The section on Software Reuse gave a general discussion on software reuse. In this section, we focus on a particular type of reuse, that of components. A component is a building block for software, much like an LCD screen is a building block for a monitor and a chassis is a building block for an automobile. The idea behind Component Based Software Engineering (CBSE) is to assemble systems out of existing, independently developed components. Component Based Software Engineering entails more than mere reuse of components, though. It also aims to increase the flexibility of systems through improved modularization.

The idea of separating the manufacturing of parts and the assemblage of those parts into a product was pioneered around 1800 in the production of rifles. This idea has fundamentally changed the hardware-manufacturing business. The same idea can be applied to the production of software. The production of software parts - the components - is separated from the assemblage of those parts into applications. As a consequence, there will be two separate development processes, one for components and one for applications. These processes are not independent. Applications need certain components and components had better be used in applications. So there are dependencies between the two development processes.

LEGO is often taken as an example of a component-based approach. LEGO is a set of building blocks in a large variety of shapes and colors. LEGO is sold in boxes that contain a number of blocks that can be composed to make up toys such as cars, trains or airplanes. In order to enable their composition, all LEGO blocks provide small cylindrical stubs on the top and complementary holes on the bottom of the shape. The conformance of the blocks to this convention ensures that blocks, possibly even different from LEGO boxes can be combined. Moreover, they can be combined into constructions other than the construction suggested by the manufacturer. Hence, LEGO blocks have the characteristics that they are easily composable and are generic. These are also the characteristics we look for in software components.

Components are to become parts of a bigger system. As such, they have to fit the architecture of those systems. One possibility would be to first design the architecture and then search for components that fit the architecture. A second possibility is to design an architecture of a family of similar systems and develop components that fit into a variety of products within that family. A third possibility is to use a bottom-up approach in which the architecture is made to fit the available components.

A warning about terminology is warranted. In Component Based Software Engineering, the word component has a more specific meaning than its meaning in Standard English. Whereas component in general means part, in Component Based Software Engineering a component is a piece of software that conforms to the rules of a particular software component model. The component model used in one system may be very different from that used in another system. As a result, the notion of component differs between different domains.

Justification for the use of Component Based Software Engineering

Computer Based Software Engineering contributes to the following business goals:

Computer Based Software Engineering increases the productivity of software development (more software per dollar).

Computer Based Software Engineering shortens the development time, and thus time to market, of software.

Component Based Software Engineering contributes to the quality of software, especially its evolvability and maintainability. This holds for both the quality of the individual components and for the quality of the architecture of systems built in a component-based way.

The more often a component is reused, the more likely errors are found and removed.

Before components are offered to other parties on a commercial basis, they must be tested thoroughly.

Otherwise the company offering the component loses credibility and is likely to go out of business.

Components must be well documented.

Otherwise only parties other than the creator will have great difficulty in using the component.

Developing software in a component based way requires a discipline of strict modularization. The strict modularization limits the domino effects of changes in the system. Hence, the effort needed to change a component-based system is likely to be less effort needed when the same changes are made to a system that is not modularized according to a component based design discipline. This property improves maintainability. When subsystems are strictly modularized, it becomes easier to change parts to support new features. This improves the ability of the system to evolve.

Component Based Software Engineering increases productivity through the reuse of building blocks that have been developed in earlier efforts or by other parties. In order for this to enhance productivity, the acquisition and integration of a component should of course be cheaper than developing the component from scratch.

The size of professional software systems is in the order of millions of lines of code. The time needed to realize such software systems may span several years. Component Based Software Engineering contributes to reducing the development time of software by using existing components rather than developing components from scratch. Another way in which Component Based Software Engineering may reduce development time is by enabling concurrent development of components. Concurrent development of components is easier if components have minimal mutual dependencies. Any dependencies that do exist between components must be specified explicitly. Hence, in Component Based Software Engineering, components are designed and specified in such a way that they can be constructed independently of, and concurrently with, other components.

Component Models and Components

In the world of engineering, the conventions for components are chosen such that they can be used for constructing systems with certain properties. For example, a racing car requires components that are lightweight and aerodynamic in order to obtain a system that is fast on the road. An army tank requires components that are tough in order to obtain a robust system.

Software components encapsulate functionality in a form that conforms to a set of conventions. These conventions ensure composability and determine the properties of systems that can be built using a particular type of component. Rather than physical properties of shape, density and color, software components are required to have properties such as computational efficiency, resource efficiency, and reliability. These characteristics are captured in the following definition:

A component model defines standards for properties that individual components must satisfy.

A component model defines standards for methods and mechanisms for composing components.

Informally, a component model defines the types of building block and the recipe for putting those building blocks together. This definition stresses a generic constraint: components are composable.

A Component is a building block that conforms to a component model.

The key aspect of this definition is composability. For software, composability may be achieved by using explicit interfaces for defining what is offered as well as what is required by a piece of software. Composability also defines the manner in which a component can communicate with other pieces of software. Whereas composability is a necessary technical requirement, a generic (modularized) component is a desirable requirement from a business perspective. A generic component can be used more often and hence has greater potential for creating revenue. The genericity characteristic implies certain technical characteristics. For instance, components with lower coupling, or dependencies can be applied in a wider context. The following definition fo a component is more specific to software:

A software component implements some functionality.

A software component has explicit dependencies through provided and required interfaces.

A software component communicates only through its interfaces, and

has a structure and behavior which conforms to an encompassing software component model.

applies to interfaces and patterns of communication of the component.

Whereas a component model defines a standard, a component technology is the collection of implmentation artifacts that realize this standard. A software component technology is the implementation of a component model by means of:

standards and guidelines for the implementation and execution of software components, and

executable software that supports the implementation, assembly, deployment, and execution of components.

The composability requirement for components entails the standardization of interfaces and interaction. These conditions may be sufficient to ensure composability at the implementation level of the component. However, much more can be said about properties that are generally desired from software components such as granularity, encapsulation, cohesion, and testability. These additional properties are related to the design and development of components.

Although the definition of a component model allows a lot of freedom, in practice there is a lot of commonality amongst component models. Comparing component technologies shows they standardize conventions that cover multiple stages of the development of components.

Component Forms in Component Models

During the life cycle of a component, the component passes through the following global stages: development, packaging, distribution, deployment and execution as indicated in the following diagram:

Figure CM-1: Stages of a component life cycle

Development: At this stage the design, specification, implementation and meta data is constructed.

UML Diagrams

Source Code files (i.e. .cpp, .h, .java)

All components necessary to create an executable.

Packaging: Information needed for trading and deployment of the component implementation is grouped into a single package.

files that form the component are bundled together as a single unit (i.e compressed file).

Distribution: Searching, retrieval and transportation of components.

placed in network transmittable format - Internet format

Deployment: Addresses issues related to the integration of component implementation into an executable system on the target platform.

Unpackaged in a form that can be installed on the target machine.

Execution: Deals with executing and upgrading components.

Component takes form of executable blocks of code residing in memory of target machine.

The following diagram shows the component life cycle with operations:

Figure CM-2: Component Life Cycle with Operations

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

functionality: what the component does.

behavior: the order of actions a component performs.

interaction potential: the ways in which the component interacts with other software.

quality properties: Characteristics such as performance and stability.

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.

A typical use of this property of interfaces is to replace a component by a newer version. The following figure shows that component P can be replaced by component P', if P' realizes the same interface LX. Component R that uses interface LX need not be changed. This is illustrated in the following diagram:

Figure CM-3: Component Replacement P' → P

Component R that uses interface LX need not be changed. The component that offers an interface is called the Provider, while the component that uses the interface is called the Requirer of the interface.

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 the 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 describe 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 the 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; the differ in the degree to which the internals of components can be inspected and changed by parties other than its developer:

Black-Box Component: Only the specification and the contract of the component are available to the user or integrator of the component.

Glass-Box Component: The internals of the component may be inspected but not modified. The implementation can add information to the specification of the component.

Grey-Box Component: Part of the internals of the component may be inspected and even some limited modification is possible.

Only certain methods may be modified or redefined by the integrator.

White-Box Component: The component is open to both inspection and modification by the user or integrator.

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 files in the package. It may be compressed to save download time, and encrypted to improve security. It can be compared to the way a ZIP file can be used to package a collection of files as 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 similar to 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.

Architecture and Component Models

The goal of software architecture is to define the key principles and guidelines for developing a software system such that the resulting system and processes meets its functional and quality requirements.

The functional requirements can be achieved by defining the set of functional requirements for the system. Functionality behaves nicely in an additive manner. In general, to increase the functionality of a system, we only need to add a new subsystem. Achieving the quality properties, however, may prove a more daunting task. One complication is that quality properties do not have the additive property, but are the collective result of the interaction of all parts in the system. The performance of a system is not handled by one component, but rather is distributed throughout all the components in the system. 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, component based software engineering requires the proper amount of 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 requiremets. 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. Component models are developed in domains that have specific quality requirement.

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 architecture styles and component models are selected. The choice of a particular component model limits the number of architecture styles that can be realized. If a component model is not an ideal match for the target architecture style, then some additional work will be required to provide extra features or to eliminate superfluous features. So an architecture contains the possible component models and a component model contains the possible architectures. Typical issues that are the subject of architectural decisions which may influence the choice between a custom component model and custom architecture versus a commercial component and a commercial architecture are: security mechanisms, transaction mechanisms and scheduling policies. Typically, policies for such issues are fixed in 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 in the following diagram:

Figure CM-4: Extra Function Properties Quality Management

The logic that handles quality properties is located within the EFP Management containers. These reference architecture diagrams apply to quality properties in general. There are two main dimensions in which these approaches differ in managing quality properties:

Property Manager: Either the property is endogenous (handled by the component) or exogenous (handled by the system).

Scope Manager: Either the property is managed on a per-collaboration basis or on a system-wide scale

Many component models provide no specific facilities for managing quality properties. The way a property is handled is left to the designers of the system, and as a result, may not be managed at all. Comparison of different quality management methods per Figure CM-4:

Figure A: This approach makes it possible to include policies for managing quality properties. These properties can be optimized towards a specific system and can also cater adopting multiple policies on a single system. This heterogeneity may be particularly useful when Commercial Off The Shelf 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 the components.

Figure B: The compatibility of components can be improved if the component model provides standardized facilities for managing quality properties. In this approach, there is a mechanism in the component execution platform that contains policies for managing quality properties of individual components as well as for managing quality properties involving several components. The ability to negotiate the manner in which quality properties are managed 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 the by quality management properties container. This container contains the knowledge on how to manage quality properties.

Figure C: Containers can be connected to containers of other components. This approach manages interaction between two components.

Figure D: Containers can interact with a mechanism in the component execution platform that manages quality properties on a system-wide scale. 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 simpler and more cost effective to implement and integrate.

In addition to the differences just noted, component models also have a number of features in common. The features common to component models are:

Infrastructure: All component models provide an infrastructure. The following mechanisms are required to create a component that can cooperate in performing a given task:

Component Instantiation: A component instance is the instantiation of an executable component at a specific location.

Relationship analogous to object and class

Each instance may create and manage its own data structures.

Instantiation typically controlled by component infrastructure, container or factory.

Binding: The creation of a link between 2 or more component instances.

Early Binding: Done at design time,

Late Binding: Done at compile time.

Dynamic Binding: Done at run time.

Link: Used to communicate and navigate between components.

First Party Binding: Component instance binds itself to another component.

Third Party Binding: Binding created by another source that will not be bound.

Communication: A component interaction mechanism to communicate with other components

Interaction styles are defined by architectural styles supported by the component.

Determines the quality properties the system can support.

Some styles favor efficiency over flexibility.

Request-Response style is most common

Event Driven is second most common

Streaming is often used in multimedia processing.

Discovery: Mechanism used by components to become visible to system

Discovery needed to support dynamic binding.

Typically guided by the designer or developer for design-time or compile-time binding.

Registry used for run-time binding.

Capability Announcement: The way in which interface capabilities are specified to the system

→

Development Support: Features available in component for assisting software developer

→

Language Independence: Some component models support development of components in different programming languages.

→

Interface Description Language (IDL)

Platform Independence: Some components allow execution on different platforms

→

Just-In-Time Compiler

Analysis Support: Used to prove the correctness of the software to predict quality properties of components

Extension Support: Component can be upgraded after deployment.

→

Quality Property Support: Component ability to deal with performance, security and reliability.

→

Development Process and Life Cycle of Component Based Software Development

The process of component-based software development differs from the classical process of software systems. The main difference is in the separation of the development process of components from the development process of systems. Since the component-based approach is a relatively young approach in software engineering, the main emphasis in the area has been on the development of technologies. Furthermore, process modeling of Component Based Software Engineering is still a relatively unexplored area.

The main idea of the component-based approach is the building of systems from already existing components. This assumption has several consequences for the system life cycle:

The development process of systems must be kept separate from the development process of components. The components should already have been developed and possibly used in other products, when the system development starts.

Component assessment is a separate process for finding and evaluating components. Many advantages are gained if the processes are kept separate. The result of the process is a repository of components that include specifications, descriptions, documented tests, and the executable components themselves.

The activities in a component-based approach are different from those in a non-component based approach. For the system-level process, the emphasis is on finding the proper components and verifying and integrating them. For the component-level process, design reuse is the main concern.

The Component-Based System Development Process

The main components of a typical component-based waterfall life cycle model are:

Requirements Engineering

Analysis And Design

Implementation

Test

Release

Maintenance

This concept is illustrated in the following diagram:

CM-5: Component Based Waterfall Life Cycle

The primary idea of the component-based approach is to reuse the existing components instead of implementing new and unproven components. For this reason, the availability of existing components must be considered even in the requirements and design phases. The following procedures should be followed at the various stages to most successfully implement Component Based System Design:

Requirements Engineering: In a non-component based approach, the requirements specification is one of the inputs to the development of the system. In a component-based approach, the requirements specification must also consider the availability of existing components. The requirements specification is not only input to the later stages, but is also a result of the design and implementation decisions.

Analysis and Design: The design phase of the component-based system follows the same pattern as the design phase of customary development models. The design phase consists of an architectural design phase followed by the detailed design phase. From the software architecture requirements the architectural components are identified. These components are not necessarily the same as the implementation components, but they should be identified and specified in the detailed design as assemblies of existing components. As in the requirements process, a tradeoff between the desired design and a possible design using existing components must be analyzed. In addition to this, there are many assumptions that must be taken into account during design. For example, it must first be decided which component models will be used. This decision has an impact on the architectural model as well as on certain system quality properties.

Implementation: The implementation phase in a component based design requires less coding than in a more traditional development process for implementing functions and focuses more on the selection of available components. In an ideal case, there is no coding at all. In practice, components often have to be adapted to fit the requirements and design specification. Required functionality that is not provided by any existing component must be implemented and the relevant stakeholders have to decide whether these new functions are implemented in the form of new components that can be reused later. An inevitable part of the implementation of a component-based system is the glue code whice connects components, enables their intercommunication and, if necessary, solves possible mismatches. In the ideal case, glue code will be generated automatically.

Integration: The integration phase includes activities that build the system from incoming parts. The integration phase does not include creative activities in the sense of creating new functions by producing new code. For this reason, it is desirable to automate and rationalize the integration process as much as possible. Nevertheless, the integration phase is very important, as it is the point at which architectural mismatches are likely to occur. The mismatches may take the form of incoming components unable to communicate or unwanted behavior of different quality properties at the system level. That is why the integration phase must be tightly connected to the system test phase in which the system functions and quality properties are verified.

Test: In Component Based Software Engineering, the need for component verification is apparent since the system developers typically have no control over component quality or component functions. This is because the components were likely to have developed in another project with entirely different purposes. The tests performed in isolated components are usually not enough since their behavior can be quite different once integrated as an assembly, or it can also be quite different in a new environment.

Release: The release phase includes packaging the software in forms suitable for delivery and installation. The component-based software engineering release is not significantly different from the classical release phase.

Maintenance: The maintenance approach of Component Based Software Engineering is to replace old components by alternative components or by adding new components to the system. The paradigm of the maintenance process is similar to that for development systems: find a proper component, test it, adopt it if necessary, and integrate it into the system.

Figure CM-5 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. It is also assumed that the selection and adaptation processes require significantly less effort than the component's implementation. Furthermore, the figure only shows the processes directly related to system development but not the supporting processes that have to do with the assessment and development of components.

Component Assessment

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 the required characteristics. Developers must also verify that the selected components provide the required functionality, and they can be successfully 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 more efficient, many assessment activities can be performed independently, separate from system development. A generic assessment process should include the following activities:

Find: From an apparent unlimited component space, find the components that provide the required functionality.

Select: The candidate components found are compared and ranked. A component that is most suitable for the given requirements and constraints is selected. The ranked list of components should be maintained throughout system development so that alternatives for any given function can be quickly found and assimilated.

Verify: Verification is part of the component selection process. The first level of verification includes testing functional and certain quality properties of a component in isolation. A second level of verification involves testing the component after it has been integrated inot the assembly with other components.

Store: When a component is assumed to be a good candidate for the current or future applications, it is stored in the component repository. The repository should not only contain the component, but also that additional information (meta-data) that can be useful in additional implementations of the component. Examples of meta-data are measured results of the component's performance, known problems, response time, tests passed and test results.

The Component Development Process

The component development process is in many respects similar to the system development process: Final product 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 is done 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 ramifications of this difference are summarized as:

There is greater difficulty in managing requirements.

Greater efforts are required to develop reusable units.

Greater efforts are needed to provide component specifications and additional material that help developers and consumers of the components.

In order to properly develop components the following considerations should be taken into account during each phase of the development process:

Requirements Engineering: Requirements specification and analysis is a combination of both top-down and bottom up processes. The requirements elicitation should be the result of the requirements specication created at the system level. However, since the components are also built for future systems, which very likely haven't even been planned, the system requirements will not necessarily have been identified either. For this reason, the process of identifying and capturing requirements is more complex. If the requirements are unknown, then the possibility of reusability are concerns that need to be addressed. Reusability is related to generality, thus the components should be designed with an eye towards generality.

Analysis & Design: The input to the design phase in the component development process comes from system design, system constraints and system concerns. Since such systems likely don't exist yet, the component designer will need to make certain assumptions about the system. Many assumptions, constraints and design criteria can be determined by selecting a component technology. The component technology will determine component interactions, solutions that need to be included the technology and assumptions about system resources. By taking these factors into consideration a component model along with the component technology can be chosen at design time.

In order to have a reusable component, the component must be designed in a general way, rather than being custom tailored for a unique situation. Components intended to be reused require adaptability. This will increase the size and complexity of the component. At the same time, they must be concrete and simple enough to serve particular requirements in an efficient way.

Implementation of components is also determined by the component technology selected. The component technology will provide support in programming languages and automation of component compositions. The component technology will provide solutions and services that are important for the application domain. Some examples of component technologies are transaction management, database management, security, and operational support for other component technologies such as .NET, J2EE, and COM+.

Integration: Components are built to be easily integrated into systems. For this reason, integration considerations must continually be in focus. The component technology provides support for components integration with integration being performed on a continual basis.

Test activities are of particular importance. Two reasons for this importance are:

Environment Context will not be obvious. No specific conditions can be taken for granted. Extensive testing with different techniques of verification needs to be employed.

Test Results need to be documented and delivered with the component to system developers.

Release and delivery of the components is the phase where components are packaged into a medium that is suitable for distribution and installation. Such a package will not only include the executable component, but also additional information in the form of meta-data specifying component properties, input and output options, help documentation, integration methodologies, test procedures and test results.

Maintenance: A specific aspect of maintenance taken into consideration for component-based systems is the relation between a component and the systems that the component will be used in. Which systems will receive any ugrades and who will be responsible for the upgrade process are questions that need to be addressed. Moreover, if a flaw is discovered and subsequently resolved, how will the update be delivered to the customer and at what cost? It is imperative that adequate testing be performed before release of the component, to minimize or preferably eliminate these concerns.

Even more difficult problems will arise during blame analysis. The issue will encompass the manifestation of the fault and the origin of the fault. A fault might be detected in one component, but the cause of the fault could be in another component. Addressing these concerns will take extra effort, and should be noted in the contract, but these concerns should be addressed before the component is released if at all possible.

Maintenance activities can be much more extensive than expected. It is important that component producers build a strategy for performing maintenance, and take the corresponding actions to ensure the realization of this strategy. For example, a component producer may offer maintenance support, which could offset any costs as well as allow the producer to retain credibility in the case of an error occurring.

Architectural approaches in component-based development.

Industrial practice has established several approaches to using component-based development. These approaches, while similar in that they use component technology, have quite different processes as well as different solutions at the architectural level.

Product Line Development

The component-based architecture for product-line development has a strong top-down direction, but also comes with some bottom-up elements. In contrast to the component-based architecture for component development, this approach aims to enable efficient development of many variants of a product. A product with a variant is often called a product family. Some common families in consumer products would inlclude cell phones, televisions or home audio equipment. Product-line development tries to cater to easily making and maintaining many variants of a product with minimal technical diversity at a minimization of cost to produce the different variants. This is the concept driving the component-based architecture for product-line development. The architecture defines the common parts of the system and the variations that are available.

As an example of this approach consider a product family of consumer products that includes CD players, DVD players, and mobile phones. In this case, careful design of the architecture would allow easy integration of MP3 decoding across all product lines. The characteristic of the component-based architecture plays a crucial role is:

Enabling Reuse of Components and Efficient Integration

Composability and minimizing time-to-market are also equally important. Typically product lifetime will be longer the sooner the product can be introduced and assimilated into the market, leading to the maximum profit potential for the developer.

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 predefined 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-line development process. A third characteristic is that is uses a combination of top-down and bottom up procedures.

Commercial-Off-The-Shelf (COTS) Based Component Development

Commercial-Off-The-Shelf component development is mostly a bottom-up approach: Assemble a system from existing components. The architecture of the system is secondary to the combinations of components that are avaialble.

From the perspective of the system developer, the strongest driver for this approach is time-to-market A typical question developer will ask is Which components can be used to quickly assemble a functioning 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 process for components.

While the commercial-off-the-shelf approach gives instant value in new functionality, there are a number of problems with this approach that can complicate its realization: If components were not designed to comply to a component model, or the components were not designed to fit with the other components in the intended system, this approach may run into problems of composability. This may occur if the semantics are not precisely stated or if the architectural properties of the components are not properly and adequately documented. For Commercial-Off-The-Shelf based development, component assessment plays a much more important role than in component or product-line development architectures.

As an example of this approach consider a Web store. Web store architecture has a fair amount of commonality with the architecture of many business information systems. A Web-store 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 an inventory control system. In this case, a selection is made of which combination of components is the most appealing, and then an architecture is designed which successfully integrates these components.

Selection of the Optimal Architectural Style

Which of the preceding approaches produces the optimal architecture? There is no definitive answer. After a surge of enthusiasm in both industry and research, the commercial-off-the-shelf market has decreased without indication of revolutionary improvement. The greatest difficulty lies in the seemingly mutually exclusive constraints: Components need to be general, effective and simple. Yet, at the same time, components must provide attractive functionality, trustworthiness, component verification and certification.

The product-line approach has been successful in many domains and its combination with component-based software engineering is a promising approach. Possible threats are the increasing costs of development and maintenance of the component technogies developed internally, That coupled with technological innovations in compilers, debuggers and integrated development environments may make the components obsolete.

Summary

The goals of component-based software engineering are to:

Reduce Development Time

Improve Productivity, and

Improve Evolvability and Maintainability of software systems.

In order to enable the composition and integration of components, the components need to be compatible. This compatibility is achieved by developing component models that define a set of conventions to which the individual components must adhere. Component models are developed to satisfy the quality requirements of particular application domains.

To successfully develop systems in a component-based manner, an architectural system needs to be in place that:

Selects the proper component models that will achieve the system requirements.

Organizes how components fit together.

Defines how the assembled system will meet its quality requirements.

The process of Component-Based Software Engineering is characterized by a separation of the development processes of individual components and the development process of the system that uses the components.