DBMS Interview - October 1996

Rational Software's Grady Booch, Ivar Jacobson, and Jim Rumbaugh

Toppling the Tower of Babble

Rational Software's leading object methodologists are all speaking the same Unified Modeling Language.

In many industries, market share tends to become increasingly concentrated as the industry matures. A burgeoning number of companies eagerly enter a hot new market, but eventually 80 percent of the market share ends up in the hands of three or four large companies while the remaining 20 percent is sliced up among dozens of smaller survivors, many of whom become niche players.

Even such conceptual products as object-oriented methodologies experience increasing market concentration. In the early days of the object-oriented software boom, dozens of methodologies and notations emerged in books, journal and magazine articles, conference presentations, and as part of consulting practices. Over the past five years or so, a handful of methodologies have percolated to the top of the market's mindshare. Rational Software, the intellectual home of Grady Booch, a leading object methodologist, accelerated this process by hiring Jim Rumbaugh in October 1994 and then by merging with Ivar Jacobson's firm Objectory AB in the fall of 1995. Rumbaugh and his co-workers at General Electric Research and Development Center created the popular Object Modeling Technique (OMT). Jacobson is the father of the widely adopted Object-Oriented Software Engineering (OOSE) method and use-case technology. Rational Software markets a variety of development tools, including the Rational Rose family of CASE tools, for building object-oriented applications.

Once the three object gurus had settled under one roof, they began to devise what was originally called a "Unified Method" and is now known as the Unified Modeling Language or UML. The UML is a graphical modeling and documentation language for representing the structure and behavior of object-oriented applications. The UML seeks to provide a richer, upwardly compatible alternative to users of the current versions of the Booch methodology, OMT, and use-cases. (Many other wellknown object methodologists have also contributed ideas to the UML.) Most, but possibly not all, aspects of the current methodologies will survive in the new UML. This loss led Jim Rumbaugh to launch a singing and song-writing career (see "Both Sides Now" at http://www.rational.com/ot/jr_song.html).

Rational is working hard to gain broad support for the UML within the wider object community. As early as the fall of 1994, Rational held open meetings at object conferences to discuss the UML with other object tool vendors, including companies that sell modeling products that compete with Rational's products. Rational freely distributes the UML specification from its Web site at http://www.rational.com, and the company welcomes public comments. When version 1.0 of the UML specification is released later this year, Rational will submit the UML specification to the Object Management Group (OMG) (http://www.omg.org) to be considered for standardization.

There are signs that Rational's strategy is on a roll. In July 1996, Rational announced that Microsoft and Hewlett-Packard (HP) will unite with Rational to jointly submit the UML proposal to the OMG. Rational and Microsoft are now working together to incorporate support for Microsoft's Component Object Model and ActiveX technologies in the UML. The UML will also incorporate aspects of HP's Fusion methodology.

DBMS editor Maurice Frank and DBMS columnist and contributing editor Tom Spitzer talked with Grady Booch, Jim Rumbaugh, and Ivar Jacobson at the Software Development '96 West conference in San Francisco last March. An edited transcript of their discussion follows.

FRANK: How did the effort to join your methodologies get started?
BOOCH: The unification began long before Rational was a force in the unification. If you look at the history of methods over the past several years, the first identifiable methods began to emerge in the early 1980s, and by the late 1980s a few had gained critical mass in the marketplace. We saw various reports as well; one from the Gartner Group pointed out that if you add Booch, Object Modeling Technique (OMT), and OOSE (Objectory) together they seem to be the dominant methods used in the marketplace.

OMT was first published in 1991; my book first came out in 1990, and Ivar's book was published in 1992. [See Table 1 for a bibliography.] In a way, these were first-generation methods; we followed each other without much interplay. With the market actively using these methods, in the early '90s I began adopting some of Jim's work, Jim adopted mine, and we both adopted Ivar's work. We began to see cross-fertilization, and the marketplace was driving us to it.

I remember having lunch with Jim several years ago, kind of courting him, saying we ought to get together more. And it finally happened in October of '94 when Rational hired Jim. That step not only legitimized our unification, but it also enabled Jim and me to work daily on the unification, which we believe is what the market wanted. Rational merged with Objectory in late 1995, so Ivar formally joined us almost a year after Jim did. Rational has been a catalyst, but the market forces have driven us in that direction as well.

JACOBSON: In 1993, as a guest editor for the Journal of Object-Oriented Programming, I wrote a paper entitled "Time for Cease Fire in the Methods War." And then, immediately, a few of us started to talk to one another and were trying to get together - Jim, Grady, and me, along with a few other colleagues. However, that really never worked, because we were all too busy and focused on our own methods. We needed someone who said, "Do it," and we also needed an infrastructure for making it happen. Rational's merger with Objectory was actually a business decision, because the two companies had very complimentary products. But the real bonus was that Grady, Jim, and I were able to work together.

FRANK: How has the rest of the object method community reacted to your joining forces? You talked about the methodology wars - are they over?
JACOBSON: I don't think we can really say that. Most people are very positive, but if it's dying out, what can I say?

BOOCH: I'm certainly sensitive to the needs of the other methodologists, because frankly we've learned a lot from our colleagues and I really want to praise their efforts. David Embley, Sally Schlaer, Steve Mellor, Rebecca Wirfs-Brock, Derek Coleman, Jim Odell, Don Firesmith, and many others have made essential contributions. But what's more important to us is what the real end users think about this. I think the community has reacted very, very positively to what we have done. In many ways our work reduces their risks and simplifies their problems because it lets them focus on a single common message.

FRANK: Can you summarize the current state of your work, including the name change?
BOOCH: We've been calling this work the Unified Method. Over the last few months we've realized that what we're producing is a modeling language. We call it UML, the Unified Modeling Language, because that's what is standardizable about it and because processes tend to be tailored to the domains in organizations. There are many ways to build buildings but only one way to write blueprints. We're defining blueprints.

JACOBSON: We have identified that this is a language and not a method, which is a substantial improvement in our approach. That means we use language definition techniques to define it. The work Grady and Jim did before I joined them is an excellent foundation for what we have done together since then. Basically, though, object modeling was as good as it was going to get.

The major improvement we are making is to incorporate use cases in a more semantically tight way. That means that when modeling, you don't need to worry so much about what kind of notation you use. You do need to consider how to move from use cases into objects and how to identify all the objects that participate in a use case. How do you find the responsibilities for these objects from the use cases - and the other way around? How do you identify the use cases an object participates in and the responsibilities it has in those use cases? While working together, we have found ways to improve use cases compared to what I had. I think we can say that about the whole language; not only have use cases improved, but object modeling has also improved. Everything we do is well tested, so we can say, "This has been used for 20 years or 10 years, so we know that it works."

BOOCH: In October of last year [1995], we released a 0.8 version that defines the language. Several companies are demonstrating support for the UML already. [Editor's note: the 0.9 release is now available.] One encouraging sign is that the language has actually gotten smaller and simpler. That indicates that we're on the right path, because it would be very easy to add lots of things but instead we're finding commonality - and this convergence is a sign of the maturity of what we're doing. Later this year we will submit Version 1.0 of the UML to the Object Management Group. What we have today is reasonably stable, so version 0.9 contains clean-up and additional things. Version 1.0 does all the things that the OMG needs.

FRANK: As you combined your methods and techniques, what previous practices have you left behind?
JACOBSON: In my view, there's nothing that won't be in the UML that we already had in the old Objectory; we haven't lost anything. The Objectory process is now the Rational Objectory process, so we can provide customers with complete process support, including tools.

BOOCH: The same is true for existing Booch users. There will be no loss of expressiveness in the migration path from Booch to UML. One big improvement is the fact that UML is actually simpler than Booch. The same is true for OMT. If you're a classic Booch, OMT, or Objectory user, the migration to UML means you don't have to unlearn anything. The migration will be relatively painless and you will learn some new things.

FRANK: What have been the most challenging aspects of combining your different techniques?
JACOBSON: I haven't seen any real difficulty working together. There has been no issue I've wanted to bring up that we haven't been able to discuss in a very open manner and make changes.

BOOCH: The three of us are very passionate. Jim and Ivar are extremely intelligent people, and it's been a lot of fun. From a technical perspective, the hardest thing from my view is that we have a lot of very good ideas here, and we're trying to present them in a simple way. So the hardest thing has been to make things simple.

RUMBAUGH: When I agreed to come to Rational, Grady and I were faced with the challenge of trying to refine our methods. Up to then, we had developed separately, and it was like getting married; there were a few spats. We both knew we'd have to make compromises, so at first there was some wariness. Frankly, we were both enamored of our own ways of doing things, and it took a while before we could loosen up a bit and let go of our past assumptions and recognize that we were building something new.

The challenge was to take these ideas and try and merge them together. Our separate ideas were fairly similar, but that can be good and bad: When things are fairly similar there can be lot of sectarian differences. We went through a process of trading off. We each fought for things we felt were most important. I feel very good with what we came up with.

I was concerned at first that I would be unhappy with the result. I think we came up with something that all of us stand behind and feel proud of and don't feel that we gave in. The result is actually better - and stronger - than the pieces.

Before Ivar joined us, we had tried to capture his ideas in our model, but it's certainly a lot better to have the author present to tell us what we got right and what we got wrong, so that we can fix it.

JACOBSON: I would also like to say (and this is really important) we are not inventing, we are designing; we are integrating things that work together. We don't claim to be creating something new; this is mature, well-tested technology used for, in some cases, 28 years!

FRANK: Is your work most suitable for a specific type of applications, or is it generic?
BOOCH: If it involves software, it's probably useful.

JACOBSON: Users tell us that these methods work for all kinds of systems.

FRANK: Then you've seen applications in which people have used products such as PowerBuilder and Oracle or Sybase relational databases as opposed to object databases and C++?
BOOCH: In many of the larger applications you find legacy code together with C++, VB, Smalltalk, you name it. What's consistent among all of those technologies is that the modeling language can be common among all of them.

RUMBAUGH: Look at the visual programming languages - I'd include SQLWindows, VB 4.0, and Powersoft's PowerBuilder, which are all great technologies. People have built systems of substance with every one of them. But the challenge is to use those technologies not just to build one-shot applications but to bet your business by building an architecture that is resilient over time. You still have to design; you still have to analyze. People are using UML and Booch and Objectory and OMT to help impose an architecture on what they have. That's why Rose [Rational Software's CASE tool] is coupled to Powersoft's tool, Visual Basic, SQLWindows, and others because it helps impose an architecture upon those things.

BOOCH: I just came off an architectural engagement with a company that has a massive Sybase RDBMS on the back end. All of their front-end clients are entirely object oriented. Why have they created a hybrid situation? Well, the reason is that RDBMS technology is very sound; it solves a lot of problems in some very good ways. The challenge for this customer is not that the data models are changing but that the business rules are changing. In fact, this customer's ability to react with appropriate software affects its success in the marketplace. They have this hybrid because objects enable them to put together an architecture that's very resilient. UML brings us to the point where we lose none of the expressiveness of OMT, Booch, or Objectory. I think we even have better ways of expressing some of the issues we deal with in RDBMSs, such as distribution and replication. And so we'll even have better modeling.

RUMBAUGH: My former partners and coauthors, Mike Blaha and Bill Premerlani, did a lot of work with relational databases, and they found very straightforward mappings from object-oriented models to relational databases.

FRANK: How does your combined effort compare to or differ from things like HP's Fusion, which attempts to bring together ideas from many other techniques and methodologies?
BOOCH: Fusion came out at about the same time my second edition work did. Look at the goals of Fusion that Derek [Derek Coleman of Hewlett-Packard in the UK] and his colleagues had: They were unifying Booch, OMT, CRC cards, and use cases. Their goals were very similar to ours. Fusion has done some good things. They didn't adopt some of the Booch things that I thought were relevant, such as the notion of categories, which are fundamental to designing systems that scale; without categories, you can't build large enough models. One way our work differs from Fusion is that we have the three principals of those methods that were unified.

JACOBSON: I've looked a lot at Fusion and worked with Derek Coleman, and we talked about how our project could support Fusion. Actually, we could support it in the Objectory process. The subsystems were lacking, but they've been added now. So there is only a small difference between Fusion and what we are doing.

FRANK: What concerns have users raised about your joining together?
JACOBSON: Typically, users have been worried that we wouldn't provide support for all they wanted to do. I assured them that I'll do everything I can to make it possible for them to move over to the new language. And I have. I don't see anything that Objectory users are losing. They are just getting better things.

BOOCH: Existing users are delighted we are doing this. They ask, "Why didn't you do this earlier?" It makes their lives a little bit easier. The installed base issue has been very important. People have been worried about their investment in OMT, Booch, or Objectory, and I think in all cases their investment will be preserved and they'll gain some other things.

RUMBAUGH: We assured them, in fact, that this really is an upgrade of each of these methods and will be upwardly compatible with each of them. But it also contains a number of new ideas that were missing from the original methods.

Some OMT users are concerned about losing some little features. I tell them that little notations aren't crucial; the content is still there. Look at what we're gaining: other ideas, which I didn't get right initially. There's no reason to hold onto bad ideas if you can replace them with better ones. But we've had to reassure users that it's OK; it really is better.

FRANK: If you become too dominant, will that create inertia?
JACOBSON: I don't see how we can be too dominant as a company. We are doing this in a very open fashion. We are publishing everything, including on the World Wide Web. So we are trying to make this a non-proprietary language. I think that's very important for the success of the industry.

BOOCH: There is always a danger that the process of becoming a standard will create some inertia in the marketplace, and that process may delay the incorporation of some new ideas. Rational has brought us together for a very clear reason: We believe that by this unification we actually help the whole software marketplace. If software development is improved across the board, then that's better for Rational's business. One of the things we're trying to do with UML is to make sure that elements of it are extensible. Specifically, the ideas of stereotypes and properties are extensible mechanisms in UML that we expect people to exploit.

SPITZER: Are you working with any of the tool vendors to incorporate the UML into their products?
RUMBAUGH: We made the UML public to the other vendors at the last OOPSLA [an OO computer conference] where we presented this language. We held a meeting for all of the tool companies that we knew of that were implementing the Booch, OMT, Objectory, and other methods, and we said, "Come and see this. We want to show it to you to make it clear to the world that we're not trying to gain an unfair advantage." And most of the vendors were very supportive.

I don't think this gives us any unfair advantage, because other vendors have just as much opportunity to implement the UML as we do. We just feel that we can do a better job of building a tool.

BOOCH: We're trying to produce something that is pervasive. Strangely enough, we're encouraging our competition, because we believe it's good for the whole market.

RUMBAUGH: Rational, Paradigm Plus [now owned by Platinum Technology Inc.], and IDE make OO design tools. We can't address all of the little niches - that's an opportunity for niche suppliers to make add-ons that will increase the value of the front end tools.

JACOBSON: I heard another question: Is it too early to do things like that? Is the technology mature enough? It's interesting that the very first object modeling language that was standardized by a standards committee (CCITT) was the SDL. SDL has many of the things we are now incorporating in the UML, such as objects and classes, subsystems, and state transition diagrams. These techniques are actually the foundation of object modeling, which was standardized back in 1976! So I only use these arguments to say that it's time to do it now. There is no risk that we are doing it too early.

RUMBAUGH: When we started working together, we explicitly looked at our methods. Schlaer and Mellor, Coad and Yourdon, and Odell and Martin had pretty much the same ideas. The time was right because people had Fusion and everybody agreed on the basic idea. So it wasn't premature. In fact, if we'd done it two years earlier, it probably would have been premature. People weren't ready yet.

BOOCH: And two years later would have been too late.

RUMBAUGH: Right. It was just the right time. Every book that comes out pretty much says the same thing.

FRANK: Would you like to add any final comments?
BOOCH: Even though people are using OO languages, that doesn't necessarily mean they're doing a good OO architecture. And so one of the purposes of our work has been to emphasize the importance of design and analysis in these kinds of languages.

JACOBSON: One of the key benefits that people want from object technologies is reuse. Unfortunately, very few OO users get a lot of reuse. And in fact you don't get reuse just by using objects; you have to design it in. You need a very good architecture to identify the reusable subsystems. So architecture is key; the other thing that's key is process, because you have different ways of working, whether you're developing single applications, a family of applications, or component systems. Two issues affect reuse: architecture and process. Architecture is not enough - you need processes as well in order to design an architecture that gives you reuse. That is the future of this technology.