Rumbaugh’s Object-Oriented Methodology

Rumbaugh’s OMT approach concentrates on first building a model of the application domain and then working out implementation details during the design.

OMT has four basic stages (some summaries omit the fourth):

1.  Analysis is the development of three related models of the problem domain: the object model describes the relevant objects; the dynamic model describes the behavior of each object by classifying its role in the various events that may happen within the system and the flow of data between objects; the functional model shows the steps necessary to perform any transformations of object data values.

2.  System design breaks down a system into subsystems and allocates system resources to those systems.

3.  Object design is the design of the objects that were identified and had their behavior classified in the first two steps.

4.  Implementation is the actual coding of the working system. If the first three stages were done well, this is supposed to be a minor, mechanical part of development.

The second stage, system design, corresponds closely to the design of SGML entity structure, because it answers the questions “How do you break down your system into pieces?” and “How will you store these pieces?” Entity management is discussed more at the end of this chapter.

The fourth stage, implementation, corresponds to Booch’s fourth stage and can be automated with a similar approach by a program that reads a DTD, creates classes for the declared document and element types, and implements the semantics identified in step one as the core behavior for these classes.

This leaves you with the analysis and object design stages. Here’s a closer look at the three models created in the analysis stage:

•  Object Model. Rumbaugh describes this as capturing “the static structure of a system by showing the objects in the system, relationships between the objects, and the attributes and operations that characterize each class of objects. The object model is the most important of the three models.” It’s the most important, and, for someone developing an application using SGML data, it’s the one that’s already done for you by the DTD, except for the specification of behavior, or “operations” that characterize each class of objects.

•  Dynamic Model. According to Rumbaugh, this specifies “allowable sequences of changes to objects from the object model.” How does this relate to SGML? Because the simplest level of useful SGML development takes static documents and manipulates copies to be output, you don’t have to worry about changes once each object’s values are assigned at creation time.
Dynamic behavior is described with state diagrams—to be honest, most object-oriented methodologies consist of the creation of lots and lots of diagrams—and Rumbaugh writes that you need “only construct state diagrams for object classes with meaningful dynamic behavior. Not all object classes require a state model.” So you can forget about it in the single-state model of an SGML document that we’re working with.

•  Functional Model. The third model specifies the algorithms necessary to transform data values, answering the question, “What do you need to do to the data?” If you view an SGML document as a database, it reduces your work if you heed the following advice from Rumbaugh: “By contrast [to interactive programs], databases often have a trivial functional model, since their purpose is to store and organize data, not to transform it.” By “trivial,” this means that you want to read data and insert new values, but you’re not calculating the shape of a boat hull here—you can create a useful SGML application without worrying about complex mathematical operations.

How much of the work described by Rumbaugh to turn an existing SGML system into an object-oriented application is already done for you, and how much remains? Of the three models, you’ve seen that the dynamic model is irrelevant for static documents and the functional model is only necessary in highly complex systems. So of these three models, the object model, which identifies the objects and their attributes, relationships, and behavior, is the only one you need to worry about, and the DTD has done all but identify the object behavior. For example, the encyclopedia DTD explicitly described the breakdown of which components comprised each of the different parts of an encyclopedia.

Of the second through fourth stages, the system design stage has already been created in an SGML system’s entity structure, the object design is done and stored in the DTD, and the implementation stage is mechanical enough to be automated. The DTD also takes care of much of the object design phase, in which you specify the structure of the individual objects identified in the analysis and the details of the behavior.

To summarize, what remains in the development of an object-oriented SGML application is the same thing that remains when you take the Booch approach; you look at the objects whose structure, relationships, and ordering are already specified for you in the DTD and assign behavior to them, and you’ll have a document object that can easily be plugged into a complete object-oriented system.