In the essay,Unified Modeling Language (UML) diagrams, and preliminary models. In this story, I want to tell you about the blueprints we created for
The fundamental task of DDM Architecture team was defining standardized messages to flow between computer systems so they could manage and access each other's data. But what would those messages look like? The messages defined by IBM's Systems Network Architecture (SNA) were similar to control blocks in memory, in which requests and their parameters were encoded in carefully mapped strings of bits. This made for short messages that were efficient to transmit, which was considered important because communication facilities were relatively slow in those days. However, these messages were complex to build and hard to interpret; there had to be a better way.
The situation was similar to the Third Generation Programming Languages (3GLs), such as RPG, COBOL, and PL/I, in which each operation that could be performed was specified by a unique, parameterized statement. For example, to read a record from a file, a READ statement would be used that named the file, specified where to put the record in memory, plus other options such as access keys. Each 3GL was defined by a large, rigid and complex grammar that specified the details of each of its statements. An alternative approach to language design was used by the LISP, APL and Smalltalk programming languages (among others). In these languages, a very simple, one-page grammar supports open-ended and flexible statements. Defining new vocabulary effectively defines new kinds of statements. Having just completed a thorough study of the Smalltalk language, I decided to use its simple grammar approach in defining DDM messages, the closer to Smalltalk's grammar, the better.
The Smalltalk programming language was defined during the 1970s by computer scientists at the Xerox Palo Alto Research Center, Xerox PARC for short. Its key feature was object orientation, in which all programming consists of objects sending messages to each other to request services. Each object contained data that defined its attributes, which were encapsulated by a set of programs, called methods, that defined all of the operations that other objects could request. These methods were invoked via messages and each method consisted of sequences of messages to be sent to other objects. This may seem a bit abstract, but within an Interactive Development Environment (IDE) it greatly simplifies programming.
The IBM System/38, also developed in the 1970s, directly supported a similar concept of encapsulated objects, but not for application programming. The System/38's Virtual Machine Interface (VMI) included instructions (i.e., messages to the VMI) for working with two types of objects. System objects implemented such things as files, libraries, and work spaces which the operating system could create and manage for application programs. Program objects implemented scalar data types, such as numbers and character strings, which 3GL programs could create and manage within system objects. The System/38 obviously had many instances of each of its System objects: many files, many libraries, etc. Their attributes and their methods were implicitly defined by the programming of the operating system.
What was missing in the System/38 was Smalltalk-like support for formally defined classes of objects. The attributes and method interfaces of Smalltalk objects are explicitly defined by CLASS objects. That is, a CLASS object specifies the list of attributes (the data) of its instances, along with the messages the instances can receive to invoke its methods. Programming in Smalltalk thus consists of defining new CLASSes of objects, along with their methods. A similar approach could be taken by DDM. A set of CLASS objects could be documented that defined the interacting entities of a distributed system, everything from simple data values through records, files, communication managers, and the messages and responses transmitted between systems.
Much of my first year, while working alone on DDM (when I wasn't flying around looking for clients) involved working out the details of this method of defining and documenting DDM classes and their messages. I wrote the first, preliminary specifications before even the first file models were chosen. My goal was to create a basic structure that could be filled in as the details of DDM architecture were defined. I started by using a document markup language similar in some ways to HTML to format the document, but this quickly became unwieldy as the number of object classes increased. Next, I put the specifications for each object in a separate VM/CMS file and created XML-like tags to indicate the beginning and end of an object, to identify its class, to specify a title, to identify its lists of attributes and methods, to specify descriptive text, and to manage versions of the object. I wrote a REXX program to interpret the XML-like tags and automatically generate a marked-up document.
This approach proved successful, and Rick Sanders, Jan Fisher, Paul Anderson and I enhanced it in several ways during the years that followed. While the resulting document was an alphabetically ordered set of named CLASSes, additional information was also needed. To cross-reference each object with all of the places it was used, we scanned all objects for references to all other objects and sorted the resulting list by object name. On a second, formatting pass, the cross-references were appended to each CLASS. Similarly, to create a full document index, we scanned the titles of all CLASSes, extracted key words and phrases. On the second pass, we scanned their text for instances of the key words and automatically inserted indexing markup as needed. This ultimately saved us a lot of work.
A further benefit to this approach was the ability to generate subsets of the specifications. The DDM specifications included ISSUE objects that each described some area of concern, specified its status, and described how it was to be resolved. The name of the ISSUE was added to an issues list in each affected object. This enabled us to create documents tailored to specific issues, which was great in that it enabled us to focus reviews and approvals during
Throughout the development of DDM architecture, we worked with people in IBM laboratories in the United States, Canada, England and Germany. We spent a lot of time flying from lab to lab, and we shipped a lot of copies of the DDM Reference Manual, but there had to be a better way! IBM had its own internal communications network, which supported e-mail services; this enabled us to discuss and resolve many issues between ACB meetings. It also enabled us to turn all of those VM/CMS files into hypertext pages. People in any IBM location could request any DDM specification object by name, and from it link to any other such object. We accomplished this several years before Internet page servers and HTML came into widespread use. The only problem was that the IBM communications network of those days was too slow for cross-country hypertext use, though it was very acceptable within the Rochester lab.
I should also mention that we also wrote two other documents. One was a Programmer's Guide to DDM that distilled parts of the DDM Specifications into a how-to description for implementing DDM clients and servers. The other document was a General Information guide. No one expected executives to understand more than just what DDM was trying to accomplish and why it was beneficial to them.
During the course of architecture design and product development, I felt justified in the view that the blueprints are the architecture. They were the central work product that kept the whole DDM effort in sync. We put a lot of effort into defining software structures that provided context to the details of the architecture and provided the implementing products with strong suggestions as to how to implement DDM products.
Going beyond paper specifications, I proposed implementing a single DDM product that could be ported to the various IBM systems, and doing so in Smalltalk. (See
Today, in 2014, I am only able to find scattered Internet references to the DDM documents we published, but not to the documents themselves. The beautifully structured specifications of which I was so proud seem to have disappeared, and DDM architecture is no longer "in the blueprints," but rather it is in products that are still being used. I believe some effort should have been made to preserve the DDM Architecture documents in an easily accessible archive. After all, are the blueprints of skyscrapers discarded after construction is complete? No, they are retained as a basis for future enhancements.
The following is a selection of pages scanned from the DDM Reference Manual.
Désolé, pas encore traduit.