By David Carr
If you missed Jim Rumbaugh's Dec. 6 visit, you missed his reprise performance of the Unified Method Song, which debuted at OOPSLA.
To the tune of "Both Sides Now," it celebrates his most obvious victory over Grady Booch with the words:
I've looked at clouds from both sides now
Both in and out, and still somehow
it's clouds' delusions I appall
I really can't stand clouds at all.
(For the complete lyrics, tune your Web browser to http://www.rational.com/htdocs/jr_song.html).
Rumbaugh, the author of the rather rectangular Object Modeling Technique (OMT), and Booch, whose modeling notation features puffy cloud shapes, have been working for the past several months to reconcile their approaches. Rumbaugh joined Booch at Rational Software this past year.
They have also joined forces with Use Case modeling prophet Ivar Jacobson, whose firm Objectory Corp. Rational recently acquired. In addition, they are working with the Object Management Group to try to make the Unified Method a true standard.
A draft of the new method was released for public comment at OOPSLA, and Booch and Rumbaugh plan to revise it in 1996. (For a copy, send e-mail to: product_info@rational.com).
Close to 300 people attended the Dec. 6 meeting at CIGNA sponsored by the Connecticut Object Oriented Users Group and the Connecticut Valley Data Administration Management Association.
Although the new look of the Unified Method that emerged may be what strikes people first -- and although Rumbaugh took obvious delight in the victory of rectangles over clouds -- the work they are doing to expand and refine the underlying logical model is more important.
"The ideas are more important than the representation you use. You can have more than one notation for the same thing," he said. In fact, the current version of Ration's object-oriented design tool, Rational Rose, lets users toggle back and forth between clouds and rectangles as two views of a common model.
The logical underpinnings of the Booch and OMT methods had been converging for several years anyway as each man adopted the other's best ideas, Rumbaugh said. They eventually agreed that their rivalry was serving little useful purpose.
The more important battle is convincing people that they ought to be following any method at all in designing software, Rumbaugh said. "People ask, 'Why don't we just do it the old fashioned way -- just sit down and write some code.' Well, a lot of reasons. If you think about airline pilots, even pilots with 20 or 30 years of experience still follow checklists before they take off. They don't just say, 'Oh, I know how to do this.' And I'm glad. If pilots flew the way people write software, everybody would be walking."
A methodology is a means of making sure that people get consistent and reliable results. "Some people won't like this because it takes away a little of the cowboy attitude," he said.
The field of object methodology has matured tremendously in the last few years, he said. "When I wrote my book five years ago, there were no books on this. That's why I wrote it. It's much easier to write a book in an empty field." In the subsequent years, there has been a great proliferation of methods, he said, but at the same time they've all been converging on some common ideas.
"The notation and terminology were different, but these differences were superficial. Also, experience has shown us what works and what doesn't work," he said.
Where OMT was a little stronger on analysis, and Booch put more emphasis on construction, the Unified Method will take the best of both, add features that didn't appear in either, and strive to offer better support for large, distributed systems.
The result is a somewhat complex and confusing document, Rumbaugh admitted. Part of the work he and Booch plan to do in 1996 is to rewrite the document with more of a layered approach, so that people who are designing simple systems won't be overwhelmed by details intended for the designers of large, distributed systems.
The Unified Method is still not all-encompassing. It addresses modeling and notation, but does not specify the process that should be employed in analysis and design. Rumbaugh said this is partly because there is more agreement on modeling and notation than there is on process. Also, the models and diagrams are the things designers really need to be able to exchange, he said, and it's possible to use them with more than one process. Different processes may also be appropriate for different-sized organizations.
The authors also recognize the continued need for improvements to the modeling of distribution, processes and threads, and real-time issues, Rumbaugh said.
They came to agreement fairly quickly on goals and concepts. "The agreement on notation was somewhat slower and more emotional because we each had our attachment to certain shapes," he said.
By a show of hands, the choice of rectangles was a popular one with this crowd, although a couple of women sitting up front let out sighs of dismay over the loss of their clouds. "Well, kiss them good-bye," Rumbaugh said. "You have to agree rectangles are a lot easier to draw."
Booch and Rumbaugh also agreed to add a number of new symbols. For instance, for people who wanted to be able to more easily see the difference between classes and objects (instances), they put points on the tops and bottoms of Rumbaugh's rectangles to denote objects. They also added or modified the symbols denoting message passing and inheritance, among other concepts.
Rumbaugh said there's little basis for the complaint he's been hearing from companies who've settled into a methodology and worry about having to retrain their people to use the Unified Method. The differences between the Booch and OMT methodologies were mostly surface anyway, and the Unified Method takes the best of each and adds features that don't appear in either. "If you can't retrain yourself in one day, I'd be surprised."
David Carr
is a freelance writer and technical communication consultant specializing in object technology issues.