UML (Unified Modeling Language)
UML (Unified Modeling Language) is the graphical modelling language standardised by the OMG (Object Management Group) for specifying, visualising and documenting software systems. UML 2 defines 14 diagram types in the categories structure and behaviour — from the class diagram to the state machine diagram.
Diagram categories: structure and behaviour
The 14 diagram types of UML 2 are divided into two categories. Structure diagrams describe the static composition of a system, behaviour diagrams its dynamics:
| Category | Diagrams | Typical questions |
|---|---|---|
| Structure | Class diagram, object diagram, package diagram, component diagram, composite structure diagram, deployment diagram, profile diagram | What building blocks does the system consist of? How are they related? What runs where? |
| Behaviour | Use case diagram, activity diagram, state machine diagram, sequence diagram, communication diagram, timing diagram, interaction overview diagram | What does the system do? In what order? How does it react to events? |
In practice, only a core of these is used regularly: class diagrams for static structure, sequence diagrams for interactions and state machine diagrams for event-driven behaviour — the latter describe state machines and are particularly widespread in embedded development.
Sketch or model?
UML is used in two fundamentally different ways. As a sketch, it serves communication: a quick diagram on a whiteboard to explain an architecture idea. That is legitimate and useful, but the semantics exist only in the heads of those involved. As a formal model, in contrast, UML is a machine-readable artefact: behind every element stands the UML metamodel with defined meaning, a tool can check the model for consistency, and further artefacts can be derived from the model. Only this second way of using it unlocks the real value of the language — and via the profile mechanism, UML can be extended with domain-specific concepts along the way.
Role in model-driven software development
In model-driven software development (MDSD), UML models are not documentation but source artefacts: a generator translates them deterministically into executable code. Class diagrams yield data structures and interfaces, state machine diagrams yield complete behaviour implementations in C, C++, Java or Python. The same input produces the same output — this reproducibility is more than a convenience: in regulated development under ISO 26262, IEC 61508 or DO-178C, it is the foundation of the evidence chain. Hand-written code and generated code remain cleanly separated; the model is the single source of truth for the generated behaviour.
Relationship to SysML and DSLs
For systems engineering, UML was evolved into SysML: SysML v1 is defined as a UML profile and replaces software-specific concepts with discipline-neutral blocks. Where even a profiled UML does not adequately fit the domain, domain-specific languages (DSLs) are the alternative — dedicated languages with their own metamodel, tailored exactly to a subject area.
UML in practice
The pragmatic approach has prevailed: no attempt to specify a system completely up front in all 14 diagram types, but targeted use of a few diagram kinds where they carry their weight — architecture documentation, interface contracts and, above all, code generation from behaviour models. What matters is the discipline of maintaining the model as a binding artefact: a UML model that runs alongside the code and goes stale is effort without benefit; a model from which code is generated cannot go stale at all.