Promises and challenges of components

Bertrand Meyer

A shorter variant of this article appeared under the title On to components in Computer (IEEE), as part of the Component and Object Technology department, in the January 1999 issue.

With this issue the Object Technology department becomes Component and Object Technology. Component technology has figured prominently in earlier columns, but we felt we had to go further. Excitement about components runs high in the computing community; in a recent survey of the Computer readership, components came at the very top of the topics of interest. (Note that the July issue of Computer will be a theme issue devoted to component-baseddevelopment.)

Excitement about components is a result from a general realization that:

1. Software development is in trouble.
2. The kind of breakthrough that we need can only be achieved through economies of scale resulting from reusing other people's creations.

To emphasize point 1 is not to be utterly negative. Certainly software developers have contributed a lot to society and, by and large, much of existing software works, much to our satisfaction, much of the time. But there is a general feeling that we can't continue for very long with our current techniques. The year 2000 mess is only one example of how bad things can get through lack of proper software engineering, and the lesson that it should have given us has largely been ignored by the industry. Here components appear as part of the salvation -- although, as we shall see, there is a darker side too.

Object technology, component technology

The change of this Department's name is a broadening of its scope, not a reversal of its course. In my opinion the line "objects are dead, long live components", although a goodattention-getter, does not make much sense technically. All the evidence is there that successful component technology must build on object orientation. For one thing, no one knows how to build complex, mission-critical software today without the help of object-oriented techniques. But, even more importantly, most the fundamental ideas that define object technology are just as fundamental to any successful development of components:

• Information hiding and data abstraction, to separate component implementation from component interfaces.
• Polymorphism and dynamic binding, to allow for dynamic adaptation of components to actual client needs.
• Design by Contract, to make sure that components are properly specified and validated.
• Inheritance, for organizing components in rational hierarchies. (Inheritance, as pointed out by many authors recently, is not always the solution, and can be misused, but remains a key tool for organizing complex sets of variants.)

More generally, I have found that many of the techniques developed in connection with reusable class libraries and frameworks are of great interest to developers of coarser-grain components such as COM and CORBA. Examples from the book Reusable Software (Prentice Hall, 1994) include:

• The open-closed principle for making components both usable as they are and amenable to extension.
• The option-operand separation principle for defining simple, easy-to-learn component interfaces, which can weather successive changes in their environment.
• The command-query separation principle, for robust, surprise-free components.
• Systematic naming conventions for components, forconsistency and ease of learning.
• Systematic use of carefully crafted assertions, in particular invariants, to design, document and test components.

It's interesting to see a number of these techniques now being rediscovered independently in the context of component development.

What is a component?

I do not know of any widely accepted definition of software components. Here is a candidate:

A software component is a program element with the following two properties: It may be used by other program elements, or clients. The clients and their authors do not need to be known to the component's authors.

The first property excludes programs that are just meant for use by humans or (as with embedded software) non-software systems. The second property excludes the simple case of a module that is used by other modules -- a subroutine in a traditional program, an Ada package, a class in an O-O system -- but without the fundamental requirement of general reusability. A true component must be usable by software developers who build new systems not foreseen by the component's author, and who are not personally known to that author.

A shortened version of this definition (due to Christine Mingins) is that components are client-oriented software.

With respect to the first property, note that there is no requirement for the software to be usable only by other program elements. It is perfectly possible for a program to be usable both by humans and by client software. An example is Microsoft Word, certainly meant for use by humans, but also available as a COM component for use by other software.

The definition immediately evokes an analogy with engineering components, in particular electronics components. This analogy has been known for a long time, and was behind Brad Cox's introduction of the phrase "software IC". Like all metaphors, it can lead to confusion if we forget that it is only a metaphor; but it is a productive metaphor, and we can indeed learn a lot from the experience accumulated by our hardware colleagues with electronic components.

Varieties of components

There are several ways to classify components. Here is a review of components from five orthogonal viewpoints:

• Level of software process task.
• Level of abstraction.
• Level of execution.
• Level of accessibility.
• Economic model.

The first classification, Level of Software Process Task, addresses the software process activity to which the component applies. We may have an analysis component, which takes advantage of reusability for system modeling; a design component; or an implementation component, which is an actual executable piece of software, ready to be integrated in a working software system. Design components are also known as patterns (and there has also been discussion of analysis patterns). Note that I am using the term "Software Process Task" rather than "Process Step" because in the seamless, reversible process promoted by object technology (see Kim Waldén's 1997 column in this Department), tasks such as analysis and design are not really separate steps but activities that may intervene at many different times.

The second classification, Level of Abstraction, describes the nature of components in terms of the level of abstraction that they encapsulate. A component may cover:

• A functional abstraction: this is the role of subroutines and functions in traditional libraries, each of which covers one particular function.
• A casual grouping, as with Ada packages or C files which (unless used with precise methodological guidelines, such as data abstraction) can be used to gather arbitrarily related elements.
• A data abstraction: this is the role of classes in object-oriented languages, each of which covers a type of objects.
• A cluster abstraction, or framework, covering a set of related data abstractions intended to work together according to preset schemes; examples include EiffelBase, the C++ Standard Template Library, and some Smalltalk libraries.
• A system abstraction: this is the case of coarse-grained binary components such as some COM and CORBA components. Microsoft Word, used as a component, falls in that category.

The third classification, Level of Execution, derives from the time when the component is integrated into a software system. Components may be static (integrated at compile time or link time, and not changeable without a recompile); replaceable (like static, but with variants substitutable dynamically); dynamic (integrated at execution time).

The fourth classification, Level of Accessibility, characterizes components by the form in which they are available to client authors:

• Interface description only, no source available. Many commercial components are available in this form.
• Source only, little or no information hiding (to use the component, at least for advanced uses, you must read its source text); this is sometimes the case with some of the free software available on the Internet.
• Information hiding (reuse through the interface), source available for inspection, discussion and correction.

The fifth and last classification, economic model, addresses how one can obtain the components: free without restriction, open source license as with the IFFEL license for Free EiffelBase, "contagious" free software as described by the Gnu Public License, free binaries, commercial components.

The trouble with components

Fascination with components is palpable throughout the software industry. One has to go 10 years back, to the time when most people first came across object-oriented ideas, to find a comparable level of excitement. This is largely justified, and gratifying to those of us who have been advocating component-based development for many years.

But all the buzz shouldn't make us forget that if components (I would say: object-oriented components) are part of the answer, they are not the answer. In fact they raise new questions too. The main question has a very simple name: quality. Once the fascination subsides, every CIO and project leader is going to realize that the quality of a component-based application is defined by the quality of its least good component -- the chain is as strong as its weakest link. This is going to be a painful realization. If the project is a mess, it's the project leader or the CIO who will be blamed; "it's the fault of those COM controls we bought" will not be a very useful excuse.

So the two-step reasoning cited at the beginning of this column omitted a crucial third step. The full picture should be:

1. Software development is in trouble.
2. The kind of breakthrough that we need can only be achieved through economies of scale resulting from reusing other people's creations.
3. Components are worthless, and quite possibly harmful, without an impeccable guarantee of quality.

Only recently has the problem of component quality come to the forefront, with the appearance of such articles as Elaine Weyuker's discussion, in the October 1998 issue of IEEE Software, of testing components. This Department has, of course, repeatedly brought the issue to the forefront, with articles on the Ariane disaster (January 1997), the Trusted Components project (May 1998) and many others emphasizing Design by Contract and component specification techniques.

The analogy with electronic components helps us here too. The success of component-based technology in hardware has only been possible thanks to precise techniques for specifying components (based, ultimately, on the laws of physics) and, most importantly, to exacting techniques for quality assurance and quality control. For software components we are far behind. This truth has not yet reached the software community at large, but when it does it will be sobering.

It would be a pity if the move to components were to falter because of insufficient attention paid to quality. We shouldn't let that happen, and this Department will play its part. Welcome to the column on object technology, component technology, object quality, and component quality.