Skip to content

UML and the Three Amigos

Abstract

By the early 1990s, object-oriented software design was drowning in notation. Dozens of rival methods, the Booch method, Jim Rumbaugh’s OMT, Ivar Jacobson’s OOSE with its use cases, plus Coad/Yourdon, Shlaer/Mellor and more, fought the so-called “method wars,” each with its own boxes, arrows and clouds. The truce came when the three biggest rivals, later nicknamed the “Three Amigos,” ended up under one roof at Rational Software (Rumbaugh joined in 1994, Jacobson via the 1995 acquisition of his company Objectory) and fused their notations into the Unified Modeling Language. The Object Management Group (OMG) adopted UML 1.1 in November 1997; the sweeping UML 2.0 followed in 2005. UML became the field’s shared visual vocabulary, but its grand ambition, to draw the model and generate the system via Model-Driven Architecture, collided with the Agile backlash and never arrived. Today UML survives less as a formal language than as a lingua franca of whiteboard class and sequence diagrams.

The Method Wars

The object-oriented revolution solved one problem and created another. Once programmers began organizing systems around objects (a lineage running from Simula through Smalltalk and into 1980s C++) they needed a way to design those systems before coding them, and to communicate the design to others. This was, in part, a response to the software crisis: the recurring discovery that large systems collapsed under their own complexity, and that code alone was too fine-grained a medium to reason about architecture.

The answer, throughout the late 1980s and early 1990s, was an explosion of object-oriented analysis and design (OOAD) methods, each pairing a graphical notation with a recommended process. Grady Booch’s Booch method, set out in his 1991 book Object-Oriented Analysis and Design with Applications, was famous for the amoeba-like “cloud” shapes it used to draw classes. James Rumbaugh and colleagues at General Electric published the Object-Modeling Technique (OMT) in 1991, strong on the static, data-oriented view of a system. Ivar Jacobson’s Object-Oriented Software Engineering (OOSE), from his 1992 book of the same name, introduced the enduring idea of the use case, a description of a system’s behavior from the actor’s point of view. Around them swirled still more notations: Coad/Yourdon, Shlaer/Mellor, Wirfs-Brock’s responsibility-driven design, and others.

Practitioners called the resulting chaos the “method wars.” Every method drew the same concepts (a class, an association, an inheritance link) with different symbols, so a diagram was legible only to adherents of one camp. Choosing a method meant betting a project on a notation, a toolset and a book. The situation begged for a standard, in the same way that the contemporaneous design patterns movement was giving object-oriented designers a shared vocabulary of solutions; UML would try to give them a shared vocabulary of drawings. (Booch, tellingly, wrote the foreword to the Gang of Four’s Design Patterns.)

Three Rivals Under One Roof

The unification happened not through a committee but through corporate gravity. Rational Software, founded in 1981 by Paul Levy and Mike Devlin, had built its business around modern software-engineering practice, and Grady Booch had been its Chief Scientist from the start.

In 1994, Rational hired James Rumbaugh away from General Electric. Booch and Rumbaugh (until then competitors) began merging the Booch method and OMT into what they first called the Unified Method. In 1995, Rational acquired Objectory AB, the Swedish company Ivar Jacobson had founded, bringing the third rival and his use cases into the fold. The trio’s good humor about their former rivalry earned them the nickname the “Three Amigos.”

Crucially, they renamed the effort. It was to be a Modeling Language, not a Method, a deliberate narrowing. The Amigos conceded that they could agree on a notation (how to draw a class, a message, a state) far more easily than on a process (in what order to do the work). UML would standardize the diagrams and leave the method to others; Rational’s own answer to “what process?” became the Rational Unified Process (RUP), and its flagship modeling tool was Rational Rose.

What UML Tried To Be

The Object Management Group (OMG) (the industry consortium that had earlier shepherded CORBA) took over stewardship to make UML a genuine open standard rather than one vendor’s product. Rational and partners submitted UML 1.0 to the OMG in January 1997, and the OMG formally adopted UML 1.1 in November 1997. A major, much larger revision, UML 2.0, arrived in 2005, followed by incremental releases (UML 2.5 in 2015, 2.5.1 in 2017).

UML is a graphical modeling language, a set of diagram types with agreed-upon symbols, not a programming language and (by design) not a development method. UML 2 defines roughly fourteen diagram types across structural and behavioral families. A handful became genuinely famous:

  • Class diagrams, the static structure: classes, attributes, and the associations and inheritance links between them. UML’s most-used diagram, and the one closest to code.
  • Sequence diagrams, objects arrayed across the top with time flowing downward, messages drawn as horizontal arrows. The go-to way to sketch an interaction or protocol.
  • Use case diagrams: Jacobson’s contribution: stick-figure actors connected to the ovals of things they can do.
  • State machine and activity diagrams, behavior over time and workflow.
  • Component and deployment diagrams, the coarse-grained physical view: which software pieces run on which hardware.

The remaining diagram types (object, package, composite structure, profile, communication, timing, interaction overview) exist in the specification but are rarely drawn in practice, a foreshadowing of UML’s eventual fate.

The Agile Backlash

UML’s ascent coincided almost exactly with the movement that would undercut its grandest use. UML and RUP embodied a philosophy of “big design up front”: model the system thoroughly, in formal diagrams, before writing code. That fit the worldview of large enterprises and their tool vendors, and it was precisely the worldview that the Agile Manifesto of 2001 rejected, prizing “working software over comprehensive documentation” and “responding to change over following a plan.” (See The Agile Revolution.)

To an Agile team, a wall of UML class diagrams was ceremony, documentation that went stale the moment the code changed. What survived the backlash was not formal UML but informal UML: a class diagram or a sequence diagram sketched on a whiteboard to think through a problem, then erased. UML had become, as Martin Fowler put it, a tool for sketching rather than blueprinting or programming, useful exactly to the degree that it was not taken too seriously.

⚠️ Dead End: Draw the Model, Generate the System

UML’s most ambitious promise was that the diagram could become the software. If a model were formal and complete enough, a tool could generate the running system from it, and, in the dream of round-trip engineering, keep code and model in sync forever. The OMG codified this vision in Model-Driven Architecture (MDA), launched in 2001. A developer would build a Platform-Independent Model (PIM) capturing pure business logic; automated transformations would turn it into platform-specific code that would “survive changes in realization technologies.” Executable UML and, later, fUML aimed to make the models literally runnable.

It never arrived at scale. The reasons compound:

  • The action-language gap. To generate a whole system, a model must specify behavior down to the last conditional, but standard UML had no complete, agreed action language. So models either stayed too abstract to generate real systems, or grew so detailed they were just programming in an awkward visual syntax.
  • Round-tripping fought entropy. Keeping a hand-drawn model and hand-edited code perpetually in sync proved brittle; generated code was hard to tune, and edits to it broke the model.
  • The tools disappointed. Code generators produced skeletons, not systems; the “90% left over” was the hard part, echoing Fred Brooks’ warning in “No Silver Bullet” that no notation dissolves the essential complexity of software. UML, sold implicitly as a silver bullet, was not one.
  • The market voted. In 2006, even as Gartner listed MDA as a technology “on the rise,” Forrester Research pronounced it “D.O.A.”, dead on arrival. Vendor lock-in, scarce skilled practitioners, and the OMG’s mixed CORBA track record finished the case.

What died was UML-as-a-complete-formal-language: the idea of a single notation rich enough to specify, generate, and maintain a system without dropping to code. What lived was UML-as-shared-vocabulary. Two diagram types (class and sequence) remain near-universal on engineering whiteboards, and terms like “use case” and “sequence diagram” are common speech among programmers who have never opened the specification. UML succeeded wildly as a lingua franca and failed just as clearly as a programming system. Both statements are true, and the gap between them is the whole story.

Fun Fact

The Three Amigos deliberately gave up the harder half of their own project. Their notations were called methods, a notation plus a process telling you what to do and when. When they merged, they found they could agree on the drawings but not on the process, so they shipped only the Language and renamed everything accordingly. UML’s very name is a monument to a compromise: the amigos standardized how to draw software precisely because they couldn’t agree on how to build it.

📚 Sources