UML

The Unified Modeling Language (UML) is a general-purpose visual modeling language for specifying, visualizing, constructing, and documenting the artifacts of software systems. It is not a programming language — nothing here compiles — but it is arguably the most consequential notation in software engineering history: a standardized vocabulary of boxes, arrows, and lifelines that lets developers describe the structure and behavior of a system before (or instead of) writing code. Adopted by the Object Management Group (OMG) in November 1997, UML ended the “method wars” of the early 1990s by merging the three dominant object-oriented design notations into one standard, and its diagrams — class, sequence, use case, state machine — remain the lingua franca of software design conversations today.

History & Origins

The Method Wars

By the early 1990s, object-oriented programming had gone mainstream, and with it came a proliferation of competing object-oriented analysis and design methods — by some counts dozens of them, each with its own notation, its own books, and its own consultants. Three stood out:

• The Booch method, developed by Grady Booch, strong in design and implementation (famous for its hand-drawn “cloud” class symbols)
• OMT (Object-Modeling Technique), led by James Rumbaugh at General Electric, strong in analysis and data-intensive systems
• OOSE (Object-Oriented Software Engineering), created by Ivar Jacobson, which introduced use cases and requirements-driven modeling

Teams had to pick a camp, tools supported one notation or another, and diagrams drawn in one method could not be read by practitioners of the next. The situation was widely described at the time as the “method wars.”

Unification at Rational

The truce began in 1994, when Rumbaugh left General Electric to join Booch at Rational Software. The two began merging the Booch method and OMT, and presented a draft “Unified Method” version 0.8 at the OOPSLA conference in October 1995. That same year Jacobson joined Rational, and his use-case-driven OOSE approach was folded in. The three creators became known throughout the industry as the “Three Amigos.”

In 1996 the effort was renamed the Unified Modeling Language — a deliberate narrowing: UML would standardize the notation and its underlying semantics, not a full development process — and versions 0.9 and 0.91 circulated for public feedback. A consortium called the UML Partners, including companies such as HP, DEC, IBM, and Microsoft, formed to complete the specification and propose it for standardization.

Standardization

UML 1.0 was submitted to the Object Management Group in January 1997. After competing submissions were merged, the combined UML 1.1 proposal was adopted by the OMG in November 1997. From that point UML was no longer a vendor method but an open industry standard, maintained by an OMG task force independent of its three authors. Maintenance revisions followed (UML 1.3 in 1999, UML 1.4, and UML 1.5 in 2003, which added action semantics), and UML 1.4.2 was later published as international standard ISO/IEC 19501:2005.

Design Philosophy

UML rests on a few core ideas:

A model is not a diagram. UML defines an underlying metamodel — a formal description of what model elements exist (classes, associations, states, messages) and how they relate. Diagrams are views onto that model. Two diagrams can show the same class from different angles, and a model can contain information no diagram displays. This is what separates UML from mere box-and-arrow sketching, and it is what makes model interchange (via the XMI format) and code generation possible.

Multiple views for multiple concerns. No single picture can capture a system. UML deliberately provides separate diagram types for static structure, dynamic behavior, interactions over time, deployment onto hardware, and packaging — the modeler chooses which views a given audience needs.

Extensible, not everything. Rather than trying to include every domain concept, UML provides profiles — a mechanism for defining domain-specific dialects using stereotypes, tagged values, and constraints. SysML (systems engineering) and MARTE (real-time and embedded systems) are OMG-standardized profiles built this way. Precise textual constraints can be attached to any element using the Object Constraint Language (OCL), part of the standard since UML 1.1.

Process-independent. UML specifies notation and semantics only. It pairs naturally with the Rational Unified Process (RUP), but works equally well with agile sketching on a whiteboard — Martin Fowler’s influential distinction between using UML as sketch, as blueprint, and as programming language captures the range of intended rigor.

Key Features: The Diagram Taxonomy

UML 2.5 defines 14 diagram types, split into two families.

Structure Diagrams (7)

Behavior Diagrams (7)

In practice a handful dominate: according to practitioner surveys, class diagrams, sequence diagrams, use case diagrams, activity diagrams, and state machine diagrams account for the large majority of real-world UML.

UML in Text: PlantUML Notation

UML itself is graphical, but one of the most common ways to write it today is through textual notations that render to standard UML diagrams. A class diagram in PlantUML syntax:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

@startuml
abstract class Shape {
  #origin : Point
  +area() : double
  +draw() : void
}

class Circle {
  -radius : double
  +area() : double
}

class Rectangle {
  -width : double
  -height : double
  +area() : double
}

Shape <|-- Circle
Shape <|-- Rectangle
Shape "1" o-- "1" Point : positioned at
@enduml

The <|-- arrow is UML generalization (inheritance), o-- is aggregation, +/-/# are public/private/protected visibility — all straight from the UML specification, just spelled in ASCII.

Evolution

UML 2: The Big Rebuild

Experience with UML 1.x exposed real problems — the semantics were imprecise in places, interactions could not express control flow well, and the metamodel had grown awkward. Proposals for a major revision were developed from 2000 to 2003, and UML 2.0 was published as a formal OMG specification in 2005. It was close to a redesign: sequence diagrams gained combined fragments (loops, alternatives, references) borrowed from the ITU’s Message Sequence Charts; activity diagrams were rebuilt on Petri-net-like token semantics rather than state machines; composite structure, timing, and interaction overview diagrams were added; and the specification itself was split into Infrastructure and Superstructure volumes.

The 2.x line then stabilized: UML 2.4.1 became international standard ISO/IEC 19505 in 2012, UML 2.5 (2015) merged the two specification volumes back into one document in a self-described “simplification” effort, and UML 2.5.1 (December 2017) remains the current version. That the specification has not needed a revision since is read two ways — as maturity by its advocates, and as stagnation by its critics.

The Rise and Fall of Model-Driven Everything

UML’s ambitions peaked with the OMG’s Model Driven Architecture (MDA) initiative, launched in 2001, which envisioned platform-independent UML models mechanically transformed into platform-specific models and finally into code — modeling as the primary development activity, with programming demoted to an output format. Executable UML approaches pushed the same idea further. Outside certain embedded and safety-critical niches where model-based code generation genuinely took hold, that vision did not survive contact with mainstream practice; the rise of agile methods in the 2000s pushed the industry toward working code and lightweight documentation, and heavyweight CASE tooling fell out of favor.

What survived is instructive. UML’s notation outlived UML’s process ambitions. Developers who would never open a CASE tool still draw UML class boxes on whiteboards, and the docs-as-code movement quietly re-mainstreamed UML through text-based tools — PlantUML (2009) and later Mermaid render sequence, class, and state diagrams from plain text checked into git.

Current Relevance

UML today occupies three distinct habitats:

1. Informal design communication. The sketch-level use is ubiquitous and largely invisible: whiteboard class diagrams, sequence diagrams in design docs, state diagrams in RFCs. Most practitioners use a pragmatic subset and ignore the specification’s finer points.
2. Model-based systems engineering (MBSE). Through SysML, UML’s metamodel underpins serious engineering of aircraft, spacecraft, vehicles, and medical devices. This is where rigorous modeling is healthiest — though notably, the mid-2020s SysML v2 effort moves away from UML’s metamodel to a new foundation, loosening the strongest industrial tie to UML itself.
3. Tooling. Open-source (Eclipse Papyrus, PlantUML, Mermaid, StarUML) and commercial (Enterprise Architect, Visual Paradigm, MagicDraw/Cameo, Rational Rhapsody) tools keep the notation executable, exchangeable, and renderable.

The specification itself is quiet — UML 2.5.1 has stood since 2017 — but the notation shows no sign of being displaced. When developers anywhere need to draw “a class” or “a sequence of messages,” they draw UML, whether they think of it that way or not.

Why It Matters

UML earns its place in any account of software history on several grounds:

• It ended the method wars. Before UML, object-oriented design knowledge was fragmented across incompatible notations. UML gave the industry a shared visual vocabulary, which made design books, courses, interviews, and tools mutually intelligible — a standardization achievement comparable to what SQL did for relational queries.
• It made “model” a first-class engineering artifact. The metamodel/diagram separation, XMI interchange, and the profile mechanism established the intellectual toolkit for model-driven engineering, which lives on in SysML and in domain-specific language research.
• It is a case study in scope. UML’s trajectory — from unifying notation, to centerpiece of a code-generation vision, back to pragmatic sketching subset — is one of software engineering’s clearest lessons about which parts of a grand vision survive: the simple, communicative core.
• It preserved good ideas. Harel statecharts, Jacobson’s use cases, and message sequence charts all reached mainstream practice largely through UML’s packaging of them.

For code archaeologists, UML is a rare specimen: a “language” with no compiler and no runtime that nonetheless shaped how two generations of developers think about, talk about, and document every other language on this site.