Q&A: James Rumbaugh, A modeling champion

James Rumbaugh, a Rational Software Corp. Fellow and long one of the world's top software development methodologists, jointly developed the Unified Modeling Language (UML) with colleagues Grady Booch and Ivar Jacobson. Rumbaugh, who has worked on software methodology, tools and concepts for more than 30 years, was the chief developer of the Object Modeling Technique (OMT), a leading object-oriented analysis and design method that was a predecessor of UML. Before joining Rational Software Corp. in 1994, he worked for more than 25 years at the General Electric Research and Development Center in Schenectady, N.Y., where he developed the DSM object-oriented programming language. Rumbaugh was also an inventor of the data flow computer architecture at MIT.Rumbaugh recently discussed the creation of UML and its future with ADT Editor-in-Chief Mike Bucken

Q: How did you get together with Grady Booch and Rational to integrate your respective object-oriented methods and create the Unified Modeling Language (UML)?

A: At the end of the 1980s some people started suggesting we put the [Booch and Rumbaugh methods] together, but there were some conflicts at the time. Finally, I joined Rational and joined Booch, so it made sense to put the two methods together. Both methods were fairly similar in outlook. Putting two of the leading methods together was a big sea change at the time. Grady and I started working together and this was the beginning of UML. Then a year later, Rational hired [methodologist Ivar] Jacobson and ended up with three of the top five methods. That started an avalanche and people realized that unification of methods was going to happen.

Q: How did control of UML get turned over to the Object Management Group (OMG) and become the basis of an industry standard?

A: The specifications were turned over to the OMG, which decided to put out an RFP for an OMG standard for a unified object method. The three of us [Rumbaugh, Booch and Jacobson] started working with other partners to create and submit a response to this standard RFP. On the first round, about six other companies worked with us, including HP. There were five more submissions, which later joined with our submission. The combined [submission] became the UML. This was truly a collaborative effort among many different people from different companies. Once that came out, UML was accepted pretty rapidly by the industry.

Q: Were you surprised at how quickly UML was accepted as a standard by the OMG membership?

A: Yes, I thought it would take longer. People stopped using things like Booch and OMT. Steve Mellor threw in the towel and decided to adopt UML. UML is quite a big success. It's one of the examples that unification can actually work if people get together to find a common way of doing things.

Q: Are you satisfied with the evolution of the UML? Do you agree at all with some who suggest there's been too many new features added by the OMG, and that the standard is becoming an uncontrollable monster?

A: Sure. All the criticisms are correct. Things like C++, HTML, XML - they all tend to be a bit too unfocused. Most public standards tend to be a bit sloppy. That's a fact of life. But we shouldn't pay too much attention to the criticism.

Q: Do you believe that the recent surge in interest for the eXtreme Programming (XP) process is a reaction to the increasing number of UML rules and specifications?

A: Yes, it's a reaction to that. It comes from a wish that things could be simpler than they are. There are a lot of good points in eXtreme Programming. Extreme Programming and UML are not necessarily opposed, although I think some developers using eXtreme Programming think they are opposites. eXtreme programming requires a lot of discipline, and a lot of people believe it is suitable for smaller projects but would have a lot of trouble scaling up. There are a lot of different software developers in the world with a lot of different skill levels. And projects come in all sizes. There is no one size [modeling language] that can fit everything. eXtreme Programming will work well for some people, but not for others. UML is certainly not incompatible with something like XP.

Q: Is the Rational Unified Process (RUP) the next big step for UML, an improved UML, or is it something completely different?

A: They are two different things. RUP is a process; it's a series of steps you take to do something. UML is a modeling language; a way of expressing things. In the past it was called software blueprints. UML does not mandate a particular process for getting designs. It's a language for expressing designs. RUP is a process of coming up with designs. They will grow together, but it's not that one replaces the other.

Q: Has UML progressed as quickly as hoped after the initial success?

A: UML has had a fast and good acceptance. It's become the number one approach to doing modeling. It's far and away the standard modeling approach. We hope that more and more people will do modeling - that they won't sit down and build software without designing it first. As far as modeling in general, I doubt that the majority of developers still do it. I think a lot of them still sit down and write code. One of my missions, and the company's mission, is to get [software developers] to design an application before they build things. If design is a first step, they will have fewer problems, get projects done faster and include what people [users] want.

Q: As you note above, many developers are still skeptical about the benefits of modeling. Do you really expect to see more and more modeling in future development projects?

A: I think so. You can't expect to get good results if you just sit down and write code. Our company's mission is to get people to build software in more a systematic and repeatable, productive way. We think there's a big future in that. UML is one approach, RUP is another way, and software architectures are another area in which you develop software that incorporates architectural patterns that can be reused. The whole idea of patterns, of reusing the knowledge that other people have developed in the past, is another big change for software developers. Another area we're looking at is the possibility of building tools that will allow developers to capture patterns of architecture, and instantiate them to plug in off-the-shelf [and internally developed components]. This is where software is going.

Q: What is your role at Rational today?

A: I'm a guru. I help out where help is needed. I'm responsible for watching out for new technology and to ensure we are well positioned for the future.