In-Depth
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.