Components For Software Development

Since the advent of structured high-level (so-called 3rd generation) languages decades ago, there's been little advance in improving the productivity of programmers. Fourth generation languages have provided niche productivity improvements, in the form of "little languages" for domains like database management and graphical user interfaces, but these are not robust improvements; as soon as the task moves slightly outside the targetted domain, the programmer is reduced to line-by-line coding.

There's been a long-running effort to increase everyday programming productivity through the use of software components; the most common parallel is to electronic components like chips, or even to mechanical components like nuts and bolts. Every other field of engineering seems to have catalogs of standard parts, why not software? On a coding level the hope is that one will replace 100-line-long routines by 5-component-long routines, with components drawn from standard catalogs.

Despite the fact that new attempts have sprung forth at a regular pace ever since the first catalog efforts of the late 60's, componentware hasn't become part of everyday programming. VBXs are a 4GL-ish exception to the rule, but it's still true that mainstream programming involves primarily line-by-line coding. 3rd-party libraries have been another reuse attempt, notorious for being buggy with poorly defined interfaces; in the end they often get in the way more than they help.

Despite the common wisdom that accomplishing reuse is a nontechnical problem, in fact our programming languages haven't permitted the reuse of small pieces of code; the only real mechanism for building fine-grained components into a system has been to design a new language with the features designed in. Since the adoption of a new language takes a long time, one gets new batches of such minicomponents on a timescale of years rather than the days or weeks the real use of component-style programming demands.


The Newest Attempts

Recently language features have made component-based programming more possible; STL [Kef95] is a true composition language based on C++'s template feature, providing component capabilities with the efficiency needed for practical projects [Jaz95]. Although STL is an algorithmically-oriented mess, and although it provides only a single catalog of parts, it is true componentware.

Batory's ongoing work [Bat92,Bat93,Bat95,Sin93] pushes further in the same direction. He is working to define what a component interface must look like: hiding of implementation detail, reuse of common interfaces, and layered interfaces for plug-in components at many levels. He uses special language constructs and tools for guided component combination. The newer work adds refinements like extensibility to otherwise common interfaces.

But the advances that will affect most programmers are being made in the commercial object models: CORBA, SOM, and COM. These language-independent models, working hand-in-hand with C++, Java, and other OOPLs, bring the idea of the interface to center stage. Implementations written by different companies, in different languages, can now work together through a plethora of interfaces. The operating system is becoming an ever-growing API.


Fine-grained Componentware

The key idea behind component programming is the interface; the added efficiency benefit of inlined combination a la STL is a bonus to make it practical on a fine-grained scale. Each line of code is written with swappability in mind. Every module is designed to be part of a shared interface, even if only one plug-in part for that interface currently exists. This results in a plethora of micro-interfaces (nanofaces?) throughout the program, seams along which the program parts can be rearranged at a variety of levels. Each interface is clearly defined with IC, giving hundreds of well-defined access points for later programmers.

The goal is to think about combining interfaces into common ones from both directions: multiple callers into the interface, and multiple implementations of the interface. For instance, a new data type address the first goal: many uses can share a single code base. A device driver interface addresses both goals: many users access it, and many drivers implement it. Try to think in these terms for all your interfaces.

The bottom line is that component-oriented software design has little to do with lines of code and much to do with the definition of new interfaces. The quality of the product depends on the interface designer's ability to see the underlying patterns and combine them into the program's conceptual seams.


Larger-grained Componentware and Java

But in the world of bigger components shared among many companies, a world where interpreted languages are often used to glue the parts together, the level of efficiency that STL seeks is pointless. The procedure calls used by COM are more than efficient enough, there's no need to make things messier by trying to invoke inlining. In this world, object models like COM in combination with the interface-specifying abilities of Java form a perfect match, with components implemented in whatever language appearing to the Java programmer as indistinguishable from Java classes.

This is the sweet spot in the componentware continuum, the happy medium where reuse is most effective with the least complication for the programmer. And Java is both fish and fowl, perfectly suited to swim in the murky network waters while providing the free-flying features that language mavens crave. It's the future.


References

[Bat92] D. Batory, S. O'Malley, "Review of The Design and Implementation of Hierarchical Software Systems With Reusable Components", to appear in ACM Trans. on Software Engr. and Methodology, Oct 1992.

[Bat93] D. Batory, V. Singhal, M. Sirkin, J. Thomas, "Scalable Software Libraries", to appear in Proceedings of ACM SIGSOFT '93: Symposium on the Foundations of Software Engineering, Los Angeles, 7-10 Dec, 1993.

[Bat95] D. Batory, "Subjectivity and Software System Generators", technical report TR95-32, cs.utexas.edu.

[Jaz95] M. Jazayeri, "Component Programming", Feb 1995.

[Kef95] T. Keffer, "Programming with the Standard Template Library", Dr. Dobb's Sourcebook, July/August 1995.

[Sin93] V. Singhal, D. Batory, "P++: A Language for Large-Scale Reusable Software Components", Proceedings of the Sixth Annual Workshop on Software Reuse, Owego, New York, Nov 1993.

 
 
Substantive changes:
    March 21, 1996: created.
    May 29, 1996: added COM details.
Copyright © 1996, Steve Colwell, All Rights Reserved
Home page