What Can a DTD Do for Object-Oriented Development?

Before identifying the specific work that a DTD has already done for the object-oriented developer, let’s review the analysis and design work that an object-oriented developer needs done. This way, we can identify the work already done in DTD development that the developer can re-use and then identify the remaining tasks.

There are many, many books available on object-oriented development, but there are two in particular with the highest reputation. Grady Booch’s Object-Oriented Analysis and Design with Applications is the most quoted, and by now considered the de facto most authoritative. His incorporation of concepts from many other popular object-oriented methodologies widens his perspective and lends weight to the book’s authority. If you do any serious research into object-oriented development, you’ll run across Booch’s name repeatedly.

James Rumbaugh and several of his co-workers at General Electric developed another very important methodology, known as the Object Modeling Technique (OMT), that they describe in their book Object-Oriented Modeling and Design. Rumbaugh’s name comes up nearly as often as Booch’s in object-oriented literature. His recent acceptance of a position at Grady Booch’s Rational Software corporation means a consolidation of the two most popular OOA/OOD methods into what many feel will be a default industry standard.

Booch’s Object-Oriented Methodology

Booch recommends that you separate the logical and physical design of a system. This has particular relevance in SGML, in which good design means an awareness of the separation between logical structure and entity structure. Entity management is beyond the scope of this chapter, but as you’ll see, a promising area for future research.

For object-oriented system development, Booch advocates something known as a spiral approach, in which the four basic steps of analysis and design are repeated at finer levels of abstraction:

1.  Domain analysis, or the identification of the classes and objects necessary for the system. For an SGML system, this work is already done in the DTD design and creation. For example, the encyclopedia DTD we saw earlier tells us that the classes of objects in the encyclopedia are the encyclopedia itself, chapters, entries, paragraphs, and titles for the chapters and entries. So, Booch’s first step is done for us.
In a complete production system, a document would only be one component. You can think of the SGML document object’s role as that of a server, providing information to other objects when they request it.

2.  Identification of the class and object semantics. Because this part is deliberately left out of an SGML system, this seems to leave a lot of work for the developer. However, by analyzing currently typical SGML applications, you can identify enough semantics to automate the implementation of a useful core group.

3.  Identification of the relationship between the various classes and objects. This, too, is already done for you in a DTD’s explicit specification of the aggregation and ordering of each of a document’s parts. The encyclopedia DTD defines a chapter as being made up of a title plus one or more entries, and an entry is a title plus one or more paragraphs.

4.  Implementation of these classes and objects. This can be automated with a program that reads the DTD, creates classes for the declared document and element types, and implements the semantics identified for step two as the core behavior for these classes. In the section “A Sample Smalltalk SGML System,” later in this chapter, you’ll see an application that does just that.

So, for a simple enough application, a developer’s task has been reduced from four steps to practically nothing. In more complex ones, the developer augments the work of step two and, to implement any newly identified features, the appropriate work on step four.