Promises and challenges of components
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:
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:
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:
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:
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:
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:
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:
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:
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.