Trusted Components for the software industry

Bertrand Meyer - ISE / Monash, Christine Mingins - Monash University, Heinz Schmidt - Monash University

A shorter variant of this article appeared in Computer (IEEE), as part of the Component and Object Technology department, in the May 1998 issue.

Learn about recent Trusted Components developments at the end of this page.

Abstract

A research and application project aimed at providing a solid foundation for the software industry through extensive libraries of trusted reusable software components ("componentware"), where trust is built from a combination of approaches: use of Design by Contract; mathematical proofs of correctness; testing; wide public scrutiny; evaluation through metrics; exhaustive validation in practical projects; rigorous change management.

Can we get the bugs out?

The software industry rests on feet of clay. However carefully we may strive to build correct and reliable software, we have no way of ensuring the quality of the result: because it depends of the quality of so much else, from hardware and operating system to compiler and run-time libraries; and because any significant system has so many details and components of its own that we can hardly expect to get everything right if we do it all by ourselves.

None of the commonly suggested approaches suffices to quell these worries:

• "Test, test and retest", the implicit motto of the industry, is expensive and wasteful. Yet as any user of PC software knows all too well, the result of all this sweat is far from ideal. Microsoft and other companies systematically and openly ship "good enough" software, with large number of known bugs.
• On the academic side, much progress has been done towards "formal methods", through which it is possible in principle to prove the correctness of program elements, using mathematical techniques. But results from this important field have had only limited effect on the practice of the industry, for several reasons: the difficulty of building mathematical models of the most delicate aspects of "real" programs, from floating-point computation to pointers; the lack of powerful tools; and, even more fundamentally, the sheer cost and difficulty of applying thoroughly formal techniques.
• The recent push for reuse and "componentware" has raised the hope that by relying on reusable components we can gain an order of magnitude in quality and especially reliability. But in the absence of excellent techniques for building the components themselves this is a mirage; in fact, the spread of less-than-optimal components could lead to a worsening of the situation. At least one major industrial disaster, to the tune of half a billion dollars, has already been ascribed to the reuse of an improperly specified component. With the progress of incompletely designed approaches to reuse, such as JavaBeans, COM and CORBA, more catastrophes are likely to happen, leading to a broad rejection of the very idea of reusability, unless the industry takes measures to guarantee component quality.

The last two points were analyzed in a recent IEEE Computer Object Technology column [4], which suggested that the solution, for each of formal methods and reusability, lies in the other proposition: formal methods, because of their cost, only make sense (except for a handful of mission-critical systems, mostly in the defense and transportation industries, where the stakes are so high that money is not the issue) when applied to widely reused components, which can recoup the investment through effects of scale; and widespread reuse is only attractive if we can be formal enough to guarantee that the components will be correct, aiding rather than harming the systems that will rely on them.

The present proposal builds on the conclusions of that article to describe an ambitious but realistic project combining the ideas of reuse and formality with other more pragmatic techniques; the goal is to provide the entire software industry with a powerful set of reusable components deserving a high degree of trust -- leading to the "Trusted Objects" of the title.

How to ensure trust

No single technique can produce completely trusted components. Trust is in fact a social phenomenon. Even in mathematics, the most formal of all disciplines, professionals only believe in a theorem based on a mix of formal criteria, such as published proofs, and social ones such as: who produced the theorem and its proof; where it was published; who reviewed the publication; who else already believes it; how much the result has already been applied; whether it seems consistent with other results in the same area or others; whether it gives the "right feeling"; whether theorem and proof are "elegant". Part of the reason is that almost all published proofs omit many intermediate steps, to avoid overwhelming the reader with useless complexity -- not unlike the complexity of a software system, except that many industrial systems are far more complex than the average mathematical proof.

As a result trust, especially in software, will not be a binary proposition -- "blindly trusted" vs. "untrusted". We may trust Microsoft Word enough to use it for our next paper, but we would not bet a year's salary on the assumption that it will not produce crash while we are writing the paper.

A striking example of the power of social processes exists in software: the success of free, source-code-available products, notably GNU and Linux software. These tools, some quite ambitious, have been devoted by volunteers, under the international scrutiny of a network of enthusiasts who, relying on all the tools of the Internet (FTP, World-Wide Web, Usenet discussion groups, e-mail) scrutinize the source code of every new version, test it, report defects, suggest improvements -- leading to collective work of unprecedented scope outside of any formal organization or commercial framework. Some of the results are of astounding quality, leading many commercial companies to select, for example, the free GCC compiler over the $2,000-per-user C/C++ compiler from Sun, or the Linux operating system -- initially the work of a student -- over Sun's Solaris, the result of tens of thousands of man-years in one of the hotbeds of the industry. Such examples illustrate the power of this recent phenomenon: volunteer scrutiny as a form of free, global quality assurance.

Building trust

The Trusted Components project proposes to apply a mix of formal and informal approaches. Here are the principal techniques:

• Design by Contract [6]. This approach to software construction is meant to ensure that software is reliable from the start, by building it as collections of elements that cooperate on the basis of precise definitions of mutual obligations -- contracts. This guides the processes of analysis, design, implementation, documentation and testing, among others.
• Formal validation. Here modern techniques and tools such as B [1] or Object-Z can be applied in connection with the principles of Design by Contract.
• Thorough application of object-oriented techniques [6] and the strict principles of reusable library design [3].
• Global public scrutiny as described above. The components will be freely available in source form, and contributions as well as criticism will be sought from the worldwide Internet community, in the GNU/Linux tradition.
• Extensive testing, taking advantage of Design by Contract and focused on component reuse.
• Metrics efforts, to track the properties of the components in a controlled fashion.

Tasks

The Trusted Components project can only be successful as a collaborative, federative multi-year effort. It can be a rich source of academic gratification: journal and conference articles, books, theses (Master's, PhD), industry collaborations, grants, workshops and conferences (e.g. in the framework of TOOLS).

The major areas of effort include (non-exhaustive list):

• Choice of areas for component development, starting with the most humble, on which everything else will be built, replacing the feet of clay with more solid material.
• Base component development. For a number of technical reasons we suggest developing the base versions in Eiffel [3], which has the proper support for Design by Contract. The Eiffel Kernel Library can serve as a starting point.
• Language-specific component adaptation. Versions of the components will be needed in widely used languages such as C, C++ and Java. Interface versions will have to be produced in IDL (the Interface Definition Language of CORBA) and Microsoft COM.
• Verification technology. Existing tools such as those for B may be appropriate, but both the tools and the techniques will need to be adapted to the proof of reusable components.
• Testing technology for reusable components; standards describing the test cases and test procedures that should accompany any proposed set of reusable components.
• Assertion language and other conceptual tools for proving practical components.
• Development and application of effort metrics.
• Development of reuse-based teaching curricula, and their application to actual courses.
• Identification of interesting application areas, and development of application-specific libraries on the same principles as the general-purpose libraries, preferably in collaboration with industry and sponsoring agencies.
• Identification of further techniques and tools for building quality componentware (beyond the concepts of [4] and the patterns and frameworks literature).

The Trusted Components project offers the prospect of an academic effort that may have a major impact on the evolution of the software industry.

References

[1] Jean-Raymond Abrial: The B-Book; Cambridge University Press, 1997.

[2] Bertrand Meyer: Eiffel: The Language; Prentice Hall, 1992.

[3] Bertrand Meyer: Reusable Software; Prentice Hall, 1994.

[3] Jean-Marc Jézéquel and Bertrand Meyer: Design by Contract: The lessons of Ariane; IEEE Computer, January 1997. See online version.

[4] Bertrand Meyer: The Next Software Breakthrough; IEEE Computer, July 1997. See online version.

[5] Bertrand Meyer: Object-Oriented Software Construction, second edition; Prentice Hall, 1997.

More Trusted Components developments!

Since the publication of this article, a number of developments have happened in Trusted Components. See among others the ETH Web page.