The authors attempt to describe hierarchical construction of software by a technique that aggregates components, and give two examples. Serious work is being done in this area, but the trend is toward object-oriented integration facilities, spearheaded by the Object Management Group’s CORBA standard and Microsoft’s OLE 2 dispatch and automation facilities. None of these current, highly visible, well-publicized efforts are discussed or referenced. As a consequence, the reader is led to wonder about the paper’s relevance to current practice.

I believe the authors are trying to convince application designers that there is a better way to organize programs, based on a starting position accepting compositions of abstract data types. While the paper is well written and covers its points thoroughly, it misses the mark by exploring directions that differ from the current trends in the industry, without referring to these trends. The length seems unusually long for this type of paper. It was hard to slog through 41 typeset pages. The paper’s best feature is that it raises awareness of program construction techniques. The worst feature is that it is technically old. The authors seem to be ignorant of current developments in its field. The paper lacks references to methods, tools, and techniques current at the time of publication.

In the discussion of “Libraries and Parameterized Components,” the authors seem to be talking about linkable components (such as UNIX archives) instead of class libraries (inheritable and specializable object constructs). I would like to see them address construction of applications by aggregation of tools containing hierarchies of objects that have services usable by request brokering or dispatching technologies (as in CORBA and OLE 2). I believe that more applications will be constructed in this manner than by distribution of compiled linkable components.

Under “Component Semantics,” it would be easier to say that “objects” can be “encapsulatable” than to attempt to discuss objects exporting unions of encapsulated interfaces. Under “Symmetric Components,” are the authors describing a communicative law feature of interface stacking? Will this remain true in an object-oriented world where object methods can be pre- and post-conditioned?

In the section on “Components,” the example of UNIX pipe expressions used is “dtbl |deqn |ditroff.” Hardly anyone uses troff now. Today, a rich selection of desktop publishers are available (including Interleaf and Frame on UNIX, and Word for Windows and its brethren on PCs). These publishers are not pipable in integration, instead using various forms of control integration and macro extension programming to accomplish the same end. The arguments here are antiquated (or I prefer to use them to push my point of control integration usurping pipe-based and linked library integration).

Under “Composition, Systems, and Domains,” a major topic of granularity is missing. Granularity of integration determines how closely integrated components work together. CORBA and OLE 2 emphasize a variety of techniques for medium and smaller granularities of integration. With the emergence of these types of program construction techniques, this sort of discussion is important.

In Section 4.1, “Object-oriented Designs,” the authors describe an approach where schemas are defined by classes of objects and their interrelationships. Many published methodologies address this phase of software engineering. A number of them do the converse, beginning with description of instances of objects, which are later grouped and collected into classes.

Footnote 12 states, “Astonishingly, the idea of stratified designs and layered systems is virtually absent in contemporary object-oriented literature.” I am the one who is astonished. That is what the current generation of CORBA and OLE 2 product technologies are all about. Perhaps there is a growing rift between commercial products and published literature, or perhaps the rate at which this technology develops is so fast that it makes it virtually impossible for authors of such well written and long papers to get them published while their technology is current.

Perhaps this paper would be current if it had been published in 1990. I realize that a long process is involved in writing a paper and getting it into the publication mills and getting reviewers to look at it, but the authors’ technology and most of their examples have been passed over by time.

Programming construction techniques are a required background for readers of this paper. Furthermore, UNIX experience would help with understanding most of the examples. For a paper published in the 1990s, on the hot topic of program construction, the references are not exactly hot. The authors need to be apprised of current developments.