Defining Object Relationships in an SGML System

We must consider one more key aspect of object-oriented design even though the SGML developer doesn’t have to worry about it because, like so much else, a good DTD has already taken care of it. Object relationships must be carefully worked out in an object-oriented system, but the DTD has already done this for a document instance and its component “objects.” When dealing with object structure, object-oriented methodologies such as Booch’s and Rumbaugh’s give you all kinds of object relationship options to consider, but one of these options covers just about everything that an SGML application developer needs to worry about: aggregation.

When you define the logical structure of a document in a DTD, you don’t have to consider anything outside of the DTD. You have a document element, the pieces that comprise that document, and the pieces that make up those pieces. For example, the Bible is made up of testaments, which are divided into books, which are divided into chapters, which are divided into verses. A cookbook might be divided into chapters that are divided into recipes, which are divided into a title, optional illustration, optional attribution, introduction, ingredients, instructions, and suggestions for accompanying dishes.

In broader object-oriented development, aggregation is only one object relationship option, because some objects may be outside of other objects. If you’re designing a bank simulation, with tellers, lines, and cash registers, none of these objects are parts of each other, and Booch, Rumbaugh, and others offer various categories in which to define the relationships between these objects. These options include the “using” relationship, in which an object of one class requires an object of another in order to perform some task (for example, a road crew worker can’t dig a hole through the asphalt until a jackhammer is assigned for the task) and the “association” relationship, which identifies the relationship between objects of two classes, such as a cabdriver and that driver’s assigned cab for the day. Other possible relationships, such as inheritance, instantiation, and metaclasses, have more bearing on object-oriented implementation issues than they do on the real world.

The aggregation category is all you need when dealing with SGML documents at the logical level—that is, when planning out the relationship of your document elements. (The SGML equivalent of the physical level, on the other hand, is the entity structure, which is not yet an issue when you’re at the application analysis stage.)

Rumbaugh cautions against overuse of aggregation and says “when in doubt, use ordinary association.” He includes several tests to consider if you’re unsure whether aggregation is appropriate, and the relationship of an SGML document or element to its subelements passes all the tests:

•  “Would you use the phrase part of?” Yes.

•  “Are some operations on the whole automatically applied to its parts?” Yes; if you tell an application to print a book, you clearly mean to print the book’s chapters.

•  “Are some attribute values propagated from the whole to all or some parts?” Yes; if a legal code section has a status attribute with a value of “proposed” or “revoked,” this applies to its subsections.

•  “Is there an intrinsic asymmetry to the association, where one object class is subordinate to the other?” Yes; subordinate relationships are clear in hierarchies such as the Bible and cookbook structures described earlier.

Using the DTD To Automate Object-Oriented Development

We saw that the existence of a good DTD means that the majority of object-oriented system analysis and design has already been done and stored in a clearly defined notation that can be easily parsed and used to declare classes in an object-oriented system. The data structures have been defined the way an object-oriented developer needs them; all that’s left for a proper object-oriented system is the specification of object behavior—in other words, what the document element objects will actually do.

An object-oriented SGML application can automate this process by:

1.  Reading a DTD and declaring a class for each element type. Each class’s attributes will be the attributes declared in the DTD for the corresponding element class and any PCDATA stored with that element.

2.  After all the classes are declared, you can instantiate members of each class. A program can do this by reading a document instance and creating a new object for each document element that it reads.

In the section “A Sample Smalltalk SGML System,” later in this chapter, you’ll see a Smalltalk application that performs these two steps.

You’ll then have a document object with component objects that fit nicely into a classic object-oriented system.

If good SGML design omits behavioral specification for document elements and object-oriented design requires it, what does a developer do about the behavior of these elements? Analysis of typical SGML systems reveals common services expected of many SGML elements; you can use this collection to define a core set of capabilities as a default starting point in an automated SGML-to-object-oriented application development system.