Ivica Crnkovic and Magnus Larsson
We are witnessing an enormous expansion in the use of software in business, industry, administration, research, and not least in everyday life. Software is no longer marginal in technical systems but has become a central factor in many fields. Features based on software functionality, rather than other system characteristics, are becoming the most important factor in a competitive market. This trend increases the demands on software products such as enhanced usability, robustness, reliability, flexibility, adaptability, and simpler installation and deployment. At the same time as these demands are growing stronger, the complexity of processes that software manages is increasing as well as the demand for the integration of processes from different areas. As a consequence, software is becoming increasingly large and complex. The main challenge for software developers today is the ability to cope with complexity and to adapt quickly to changes. Traditionally, software development addressed the challenges of increasing complexity and dependence on external software by focusing on one system at a time and on satisfying delivery deadline and budget requirements without considering the evolutionary needs of the system.
Focusing on one system at a time and neglecting the forthcoming changes during the development, has led to a number of problems: the failure of the majority of projects to meet their deadline, budget, and quality requirements as well as the continued increase in the costs associated with software maintenance.
One key to the solution of these problems is reusability. The idea of software reuse is not new. But, despite some successes, reusability has not become a driving force in software development. Many of the unsuccessful approaches to reuse did not satisfy the basic requirements of reusability
: i) Reuse requires some modification of the object being reused, ii) Reuse must be integrated into specific software development. In many approaches, reusability is not immanent in the development process, what can be reused and what cannot be reused is not precisely defined, and how the changes can be introduced in the reusable parts is not formalized. The new rapidly emerging approach Component-based Development (CBD) re-establishes the idea of reuse and introduces new elements: In CBD, software systems are built by assembling components already developed and prepared for integration. CBD has many advantages. These include more effective management of complexity, reduced time to market, increased productivity, improved quality, a greater degree of consistency, and a wider range of usability .
However, there are several disadvantages and risks in using CBD which can jeopardize its success.
Time and effort required for development of components. Among the factors which can discourage the development of reusable components is the increased time and effort required to build reusable units [3,4].
Unclear and ambiguous requirements. In general, requirements management is an important and complex phase in the development process, its main objective being to define consistent and complete component requirements. One of the major problems of software development in general comes from unclear, ambiguous, incomplete and insufficient requirements specifications. Reusable components are, by definition, to be used in different applications, some of which may yet be unknown and the requirements of which cannot be predicted. This applies to both functional and non-functional requirements. This makes it more difficult to identify the requirements properly and hence to design and build components successfully [5,6].
Conflict between usability and reusability. To be widely reusable, a component must be sufficiently general, scalable and adaptable and therefore more complex (and thus more complicated to use), and more demanding of computing resources (and thus more expensive to use). A requirement for reusability may lead to another development approach, for example a design on a more abstract level, which may lose flexibility and finer tuning, but achieves greater simplicity [3,4].
Component maintenance costs. While application maintenance costs can be lowered, component maintenance costs can be very high since the component must respond to the different requirements of different applications running in different environments, with different reliability requirements and perhaps requiring a different level of maintenance support.
Reliability and sensitivity to changes. As components and applications have separate lifecycles and different kinds of requirements, there is some risk that a component will not completely satisfy the particular requirements of certain applications or that it may have characteristics not known to the application developer. When introducing changes on the application level (changes such as the updating of operating system, the updating of other components, changes in the application), there is a risk that the change introduced will cause system failure.
To enjoy the advantages and avoid the problems and risks, we need a systematic approach to component-based development at the process and technology levels.
Both customers and suppliers have expected much from CBD, but their expectations have not always been fulfilled. Experience has shown that component-based development requires a systematic approach to focus on the component aspects of software development . Traditional software engineering disciplines must be adjusted to the new approach, and new procedures must be developed. Component-based Software Engineering (CBSE) has become recognized as a new sub-discipline of Software Engineering.
The major goals of CBSE are:
To provide support for the development of systems as assemblies of components;
To support the development of components as reusable entities;
To facilitate the maintenance and upgrading of systems by customizing and replacing their components.
The building of systems from components and the building of components for different systems requires established methodologies and processes not only in relation to the development/maintenance aspects, but also to the entire component and system lifecycle including organizational, marketing, legal, and other aspects [7,10]. In addition to specific CBSE subjects such as component specification or composition and technologies, there are a number of software engineering disciplines and processes, which require specific methodologies for application in component-based development. Many of these methodologies are not yet established in practice, some not theoretically sufficiently refined. The progress of software development in the near future will depend very much on the successful establishment of CBSE and this is recognized by both industry and academia.
It is obvious that CBD and CBSE are only in the starting phase of their expansion. CBD is recognized as a powerful new approach that will significantly improve - if not revolutionize - the development of software and software use in general. We can expect components and component-based services to be widely used by non-programmers in building their applications. Tools for building such applications by component assembly will be developed. Automatic updating of components over the Internet, present already today in many applications, will be a standard means of application improvement. Another trend we can see is the standardization of domain-specific components on the interface level. This will make it possible to build applications and system from components purchased from different vendors. The standardization of domain-specific components requires the standardization of domain-specific processes. Widespread work on standardization in different domains is already in progress, (a typical example is the work of the OPC Foundation  on a standard interface to enable interoperability between automation/control applications, field systems/devices and business/office applications). Support for the exchange of information between components, applications, and systems distributed over the Internet will be further developed. Current technologies such as XML  are already used to exchange information over the Internet.
CBSE is facing many challenges today; some of these are summarized here and further developed in different chapters of the book.
Component specification – Although this problem has been addressed from the very beginning of development of component models, there is still no consensus about what is a component, and how it should be specified. Component specification is an important issue as the basic concepts of component-based development rely on it and this book therefore pays much attention to this problem. Chapter 1, Basic Concepts in Component-Based Software Engineering, Chapter 2, Specification of Software Components and Chapter 6, Semantic Integrity in Component Based Development discuss component specifications and other basic concepts of component technologies related to component specifications.
Component Models – Even though existing development models demonstrate powerful technologies, they have many ambiguous characteristics, they are incomplete, and they are difficult to use. The relations between system architecture and component models are not precisely defined. The basic principles of component models, their relations to software architecture and descriptions of the most commonly used models are presented in Chapters 3, Architecting Component-based Systems and Chapter 4, Component Models and Technology.
Component-based software lifecycle. Lifecycle of the component-based software is becoming more complex as many phases are separated in unsynchronized activities. For example, the development of components may be completely independent of the development of systems using those components. The process of engineering requirements is much more complex as the possible candidate components usually lack one or more features which the system requires. In addition, even if some components are individually well suited to the system, it is not obvious that they function optimally in combination with others in the system. These constraints may require another approach in requirements engineering – an analysis of the feasibility of requirements in relation to the components available and the consequent modification of requirements. As there are many uncertainties in the process of component selection there is a need for a strategy for managing risks in the component selection and evolution process [8,14]. Similarly there are many open questions in the late phases of component-based software lifecycles. As component-based systems include components with independent lifecycles, the problem of system evolution becomes significantly more complex. There are many questions of different types not yet solved: technical issues (can a system be updated technically by replacing components?), administrative and organizational issues (which components can be updated, which components should be or must be updated?), legal issues (who is responsible for a system failure, the producer of the system or of the component?), etc. CBSE is a new approach and there is little experience as yet of the maintainability of such systems. There is a risk that many such systems will be troublesome to maintain. The component-based system lifecycle is discussed in Chapter 5, Component-Based Development Process.
Composition predictability – Even if we assume that we can specify all the relevant attributes of components, it is not necessarily known how these attributes will determine the corresponding attributes of systems of which they are composed. The ideal approach, to derive system attributes from component attributes is still a subject of research. The question remains - “Is such derivation at all possible? Should we not concentrate on the determination of the attributes of component composites?” . Component evaluation and component compositions are discussed in detail in Chapters 8, Dispelling the Myth of Component Evaluation and 9, Component Composition and Integration.
Trusted components and component certification - Because the trend is to deliver components in binary form and the component development process is outside the control of component users, questions related to component trustworthiness become of great importance. One way of classifying components is to certificate them. In spite of the common belief that certification means absolute trustworthiness, it in fact only gives the results of tests performed and a description of the environment in which the tests were performed. While certification is a standard procedure in many domains, it is not yet established in software in general and especially not for software components [16,17]. Chapter 10, Predicting System Trustworthiness from Software Component Trustworthiness elaborates on how trustworthiness can be achieved for software components.
Component configurations – Complex systems may include many components which, in turn, include other components. In many cases compositions of components will be treated as components. As soon as we begin to work with complex structures, problems involving structure configuration appear. For example, two compositions may include the same component. Will such a component be treated as two different entities or will the system accept the component as a single instance, common to both compositions ? What happens if different versions of a component are incorporated in two compositions ? Which version will be selected? What happens if the different versions are not compatible? The problems of the dynamic updating of components are already known, but their solutions are still the subject of research [20,21]. One way to handle such complex systems with many components is to make use of product line architectures [18,19] to impose rules for component configurations. Chapter 11, Components in Product Line Architectures, presents the basis of such component configurations.
Tool support – The purpose of Software Engineering is to provide practical solutions to practical problems, and the existence of appropriate tools is essential for a successful CBSE performance. Development tools, such as Visual Basic, have proved to be extremely successful, but many other tools are yet to appear – component selection and evaluation tools, component repositories and tools for managing the repositories, component test tools, component-based design tools, run-time system analysis tools, component configuration tools, etc. The objective of CBSE is to build systems from components simply and efficiently, and this can only be achieved with extensive tool support. Three chapters in the book, Chapter 12, The Koala Component Model, Chapter 18 A Framework for Integrating Business Applications, and Chapter 19, Industrial Experience with the Dassault Système Component Model, illustrate the necessity of using tools in the development and maintenance process.
Dependable systems and CBSE - The use of CBD in safety-critical domains, real-time systems, and different process-control systems, in which the reliability requirements are specially rigorous, is particularly challenging. A major problem with CBD is the limited possibility of ensuring the quality and other non-functional attributes of the components and thus our inability to guarantee specific system attributes. Several chapters of this book treat this problem, as specified in the section below.
In many domains the CBD approach has been very successful. CBD, and software reuse in general, has been extensively used for many years in desktop environments, graphical and mathematical applications. The components used in these areas are, by their nature, precisely defined and they have intuitive functionality and interfaces. On the other hand the extra-functional characteristics and constraints are not of the highest priority. By extra-functional characteristics we mean the component and system properties which determine an overall behavior, but cannot be expressed by functions and cannot be invoked and performed explicitly. Examples of extra-functional properties: properties related to temporal constraints (execution time, latency, periodicity, deadlines, etc.), then reliability, robustness, performance, safety and security. In addition to these emergent system properties, we have properties related to system lifecycle: maintainability, usability, availability, adaptability, reusability, etc. These properties are often referred to as non-functional properties.
While component-based models successfully deal with functional attributes (although still being far from the ideal solutions), they provide no support for managing extra-functional properties of systems or components. Component-based software engineering faces two types of problems in dealing with extra-functional properties. The first type, one common to all software development, is the fact that there are many and often imprecise definitions of these properties. The second, specific to component-based systems, is the difficulty in relating system properties to component properties. Let us take reliability as an example. An intuitive definition of the reliability of a system is the probability that a system will behave as intended. The formal definition of reliability is “the ability of a system or component to perform its required functions under stated conditions for a specified period of time” . There are several points in this definition which must be considered. To predict or calculate the reliability of a system correctly, we must state precisely the relevant conditions under which it is to apply. This definition does not apply to system behavior in unpredictable situations, but experience teaches us that problems occur mostly when a system is exposed to unpredictable conditions. Uncertainty in the specification of conditions leads to uncertainty in any specification of system reliability. To include unpredictable (or predictable, but not “normal”) conditions, we introduce the property robustness . We distinguish these two properties but cannot precisely define their relation. There are also other properties which are closely related to these two. The availability of a system is the probability that it will be up and running and able to provide useful service at any given time. Trustworthiness denotes a user’s confidence that the system will behave as expected. There are systems in which the safety (i.e. the ability of the system to operate without catastrophic failure) and security (the ability of the system to protect itself against accidental or deliberate intrusion) are of the main importance. In such systems reliability, robustness, availability, etc. must be very precisely specified. These systems are often designated as dependable .
The specific problems and challenges involved in component-based development when dealing with extra-functional properties are the determination of the relations between component properties and system properties. Which properties should be considered when evaluating components, when composing them into assemblies, when testing them? Can we predict the behavior of a system from the specifications of its components? Let us again consider reliability as an example. The first question which arises is how to define the reliability of a component? It depends on specified conditions, which might be only partially defined, as these conditions are determined not only by the component itself but also by its deployment and run-time environment. The second question is how to predict the reliability of a system from the known reliabilities of its components? These questions are discussed in Chapters 8 and 9: Dispelling the Myth of Component Evaluation, and Component Composition and Integration.
Component-based development usually decreases the development time and effort, but also the possibility of guaranteeing extra-functional properties. For example, the main problem when using commercial components in safety-critical systems is the system designer’s limited insight into the safety-critical properties of components. Increasing the number of test cases may decrease this uncertainty. We also need specific test methods to be applied to components. One way of performing tests is to use fault injection which can reveal the consequences of failures in components to the rest of the system [24-26]. This and certain other methods are discussed in Chapter 10, Predicting System Trustworthiness from Software Component Trustworthiness. As in general, the trustworthiness of commercial components is less than that of software developed in-house, we must perform tests as much as needed, but not more. If a component is extensively tested in one configuration, do we need to repeat all the tests performed or can we assume some of the results of previous tests? Must we add new tests? This depends on the system requirements and on the system configuration. By reasoning about changes in requirements, changes in the system environment and changes in the entire environment in which the system is performing, we can to some extent ascertain which test cases are already covered by the previous tests. This analysis is discussed in Chapter 14, Test of Reusable Software Components in Safety-Critical Real-Time Systems.
Component-based real-time systems (systems in which the correctness is also determined by time factors), and hence real-time components, must take into consideration timing constraints. Very often these systems are dependable systems (i.e. reliable, robust, safety-critical, etc.). General-purpose component models do not provide real-time support. There are many open questions how to build component-based real time systems: what is real-time component, what are its properties, how a real-time component can be specified, etc.? Chapter 13, Components in Real-Time Systems, discusses basic principles for modeling component-based systems, Chapter 15, Providing Real-Time Services for Commercial-Off-The-Shelf Components, 16, Component-Based Embedded Systems and 17, Architectural Support for Reuse: A Case Study in Industrial Automation, illustrate via different case studies, the possibilities of applying component-based principles and building real-time systems based on non-real-time component technologies.
 Basili V.R. and Rombach H.D., Support for Comprehensive Reuse. Software Engineering, IEE British Computer Society, volume 6, issue 5, 1991.
 Brown A. W., Large-Scale Component-Based Development, Prentice Hall, 2000.
 Crnkovic I. and Larsson M., "A Case Study: Demands on Component-based Development", In Proceedings of 22nd International Conference on Software Engineering, ACM Press, 2000.
 Szyperski C., Component Software Beyond Object-Oriented Programming, Addison-Wesley, 1998.
 Maiden N.A. and Ncube C., Acquiring COTS software selection requirements, IEEE Software, volume 15, issue 2, 1998.
 Lamsweerde A. v., "Requirements engineering in the year 00: a research perspective ", In Proceedings of 22nd international conference on software engineering, IEEE Computer Society, 2000.
 Larsson M. "Applying Configuration Management Techniques to Component-Based Systems" Licentiate Thesis Dissertation 2000-007, Department of Information Technology Uppsala University. 2000
 Heineman G. T. and Councill W. T., Component-based Software Engineering, Putting the Pieces Together, Addison Wesley, 2001.
 Josefsson, M., Programvarukomponenter i praktiken - att köpa tid och prestera mer, report V040078, Sveriges Verkstadsindustrier, 1999.
 Takeshita T., "Metrics and risks of CBSE", In Proceedings of 5th international symposium on software tools and technologies, IEEE Computer Society, 1997.
 Gartner Group, Trends and Emerging Technologies, http://www.gartner.com.
 OPC, OLE for Process Control, report v1.0, OPC Standards Collection, OPC Foundation, 1998.
 World Wide Web Consortium, XML, http://www.w3c.org/XML/.
 Kotonya G. and Rashid A., "A strategy for Managing Risks in Component-based Software Development", In Proceedings of 27th Euromicro Conference in the CBSE workshop, IEEE Computer Society, 2001.
 Wallnau K. C. and Stafford J., "Ensembles: Abstractions for A New Class of Design Problem", In Proceedings of 27th Euromicro Conference, 2001.
 Voas J. and Payne J., Dependability Certification of Software Components, Journal of Software Systems, volume 52, 2000.
 Morris J., Lee G., Parker K., Bundell G., and Peng Lam C., Software Component Certification, IEEE Computer, volume 34, issue 9, 2001.
 Bosch J., Design & Use of Software Architectures, Addison-Wesley, 2000.
 Bosch J., "Product-Line Architectures in Industry: A Case Study", In Proceedings of 21st International Conference on Software Engineering, ACM Press, 1999.
 Crnkovic I. and others, Object-Oriented Design Frameworks: Formal Specifications and Some Implementation Issues, in Databases and Information Systems, editors, Barzdins J. and Caplinskas A., Kluwer Academic Publishers, 2001.
 Larsson M. and Crnkovic I., "New Challenges for Configuration Management", In Proceedings of 9th Symposium on System Configuration Management, Lecture Notes in Computer Science, nr 1675, Springer Verlag, 1999.
 IEEE, IEEE Standard Computer Dictionary: A Compilation of IEEE Standard, Institute of Electrical and Electronics Engineers, 1990.
 Sommerville I., Software Engineering, Addison-Wesley, 2001.
 Voas J. and McGraw G., Software fault injection: inoculating programs against errors, John Wiley and Sons, 1998.
 Voas J., A Method for Discovering Unforeseen Software Output, Modes and Missing System Hazards, To appear in The Annals of Software Engineering, 2001.
 Besnard, J. F., Keene, S. J., and Voas, J., Assuring COTS Products for Reliability and Safety Critical Systems, IEEE Computer Society, 1999.