Introduction

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

[1]: 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 [2].

However, there are several disadvantages and risks in using CBD which can jeopardize its success.

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.

Component-Based Software Engineering

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 [3]. 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:

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.

Challenges of Component-Based Software Engineering

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 [12] 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 [13] 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.

Components in Reliable Systems

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” [22]. 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 [23].

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.

References

[1] Basili V.R. and Rombach H.D., Support for Comprehensive Reuse. Software Engineering, IEE British Computer Society, volume 6, issue 5, 1991.

[2] Brown A. W., Large-Scale Component-Based Development, Prentice Hall, 2000.

[3] 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.

[4] Szyperski C., Component Software Beyond Object-Oriented Programming, Addison-Wesley, 1998.

[5] Maiden N.A. and Ncube C., Acquiring COTS software selection requirements, IEEE Software, volume 15, issue 2, 1998.

[6] 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.

[7] Larsson M. "Applying Configuration Management Techniques to Component-Based Systems" Licentiate Thesis Dissertation 2000-007, Department of Information Technology Uppsala University. 2000

[8] Heineman G. T. and Councill W. T., Component-based Software Engineering, Putting the Pieces Together, Addison Wesley, 2001.

[9] Josefsson, M., Programvarukomponenter i praktiken - att köpa tid och prestera mer, report V040078, Sveriges Verkstadsindustrier, 1999.

[10] Takeshita T., "Metrics and risks of CBSE", In Proceedings of 5th international symposium on software tools and technologies, IEEE Computer Society, 1997.

[11] Gartner Group, Trends and Emerging Technologies, http://www.gartner.com.

[12] OPC, OLE for Process Control, report v1.0, OPC Standards Collection, OPC Foundation, 1998.

[13] World Wide Web Consortium, XML, http://www.w3c.org/XML/.

[14] 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.

[15] Wallnau K. C. and Stafford J., "Ensembles: Abstractions for A New Class of Design Problem", In Proceedings of 27th Euromicro Conference, 2001.

[16] Voas J. and Payne J., Dependability Certification of Software Components, Journal of Software Systems, volume 52, 2000.

[17] Morris J., Lee G., Parker K., Bundell G., and Peng Lam C., Software Component Certification, IEEE Computer, volume 34, issue 9, 2001.

[18] Bosch J., Design & Use of Software Architectures, Addison-Wesley, 2000.

[19] Bosch J., "Product-Line Architectures in Industry: A Case Study", In Proceedings of 21st International Conference on Software Engineering, ACM Press, 1999.

[20] 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.

[21] 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.

[22] IEEE, IEEE Standard Computer Dictionary: A Compilation of IEEE Standard, Institute of Electrical and Electronics Engineers, 1990.

[23] Sommerville I., Software Engineering, Addison-Wesley, 2001.

[24] Voas J. and McGraw G., Software fault injection: inoculating programs against errors, John Wiley and Sons, 1998.

[25] Voas J., A Method for Discovering Unforeseen Software Output, Modes and Missing System Hazards, To appear in The Annals of Software Engineering, 2001.

[26] Besnard, J. F., Keene, S. J., and Voas, J., Assuring COTS Products for Reliability and Safety Critical Systems, IEEE Computer Society, 1999.