UML

In short: Unified Modeling Language — a standardised graphical notation for visualising software architecture and processes.

In more detail: Covers various diagram types for different purposes: class diagrams (structure of objects/classes), sequence diagrams (the time-based flow of interactions), use-case diagrams (user interactions with the system), among others. Used in software development to plan design before implementation and to communicate it within a team.

In Depth

A UML class diagram shows classes, their attributes, methods, and the relationships between them — graphically as a rectangle with three sections (class name, attributes, methods), connected by arrows for inheritance (a solid line with an empty triangle), association (a simple line), or composition (a filled diamond). A sequence diagram, by contrast, shows no static structure, but the flow over time: vertical “lifelines” for each involved object, horizontal arrows for method calls between them, top to bottom in the order they actually happen.

UML emerged in the 1990s from merging several competing notations and quickly became the industry standard for software architecture documentation. In practice, the full formality of the UML specification is rarely used — most teams use a simplified, informal subset, to quickly sketch the rough structure of a system on a whiteboard or in a tool like draw.io, before the first code is written. Diagrams mainly serve communication within the team and with stakeholders, less as a complete, machine-readable specification.

Structure diagrams vs. behaviour diagrams

UML’s 14 official diagram types can roughly be divided into two groups: structure diagrams show static composition (class diagrams, component diagrams, object diagrams — “what exists and how it’s connected”), behaviour diagrams show dynamic behaviour over time (sequence diagrams, activity diagrams, state diagrams — “what happens when”). In practice, of these 14 types, almost only class and sequence diagrams are regularly used; the remaining types mostly only appear in very formal, documentation-heavy projects (e.g. safety-critical software requiring certification).

Tool support

Some IDEs and specialised tools can partly automatically generate UML diagrams from existing code (reverse engineering), or conversely generate a code skeleton from a diagram (forward engineering) — in practice, this automation is rarely used fully, since real code is usually adapted faster than a diagram kept in sync, and diagrams quickly go stale if not actively maintained. More often, UML today serves as a one-off planning/communication tool at the start of a project or a larger feature, not as documentation permanently kept in sync.

PlantUML and text-based alternatives

A modern approach to avoiding UML diagrams going stale is text-based tools like PlantUML or Mermaid — diagrams are defined as plain text directly in the code repository itself and automatically rendered when needed, instead of as a separate, easily forgotten image file. This lets diagrams be versioned like normal code and reviewed along with pull requests, which considerably lowers the maintenance barrier compared to classic graphical UML tools.

See also: Classes, Inheritance, Objects