UML (Unified Modeling Language)
UML (Unified Modeling Language) ist die von der OMG (Object Management Group) standardisierte grafische Modellierungssprache zur Spezifikation, Visualisierung und Dokumentation von Softwaresystemen. UML 2 definiert 14 Diagrammtypen in den Kategorien Struktur und Verhalten — vom Klassendiagramm bis zum Zustandsdiagramm.
Diagrammkategorien: Struktur und Verhalten
Die 14 Diagrammtypen der UML 2 teilen sich in zwei Kategorien. Strukturdiagramme beschreiben den statischen Aufbau eines Systems, Verhaltensdiagramme seine Dynamik:
| Kategorie | Diagramme | Typische Fragen |
|---|---|---|
| Struktur | Klassendiagramm, Objektdiagramm, Paketdiagramm, Komponentendiagramm, Kompositionsstrukturdiagramm, Verteilungsdiagramm, Profildiagramm | Aus welchen Bausteinen besteht das System? Wie hängen sie zusammen? Wo läuft was? |
| Verhalten | Anwendungsfalldiagramm, Aktivitätsdiagramm, Zustandsdiagramm, Sequenzdiagramm, Kommunikationsdiagramm, Zeitverlaufsdiagramm, Interaktionsübersichtsdiagramm | Was tut das System? In welcher Reihenfolge? Wie reagiert es auf Ereignisse? |
In der Praxis wird nur ein Kern davon regelmäßig genutzt: Klassendiagramme für die statische Struktur, Sequenzdiagramme für Interaktionen und Zustandsdiagramme für ereignisgesteuertes Verhalten — Letztere beschreiben Zustandsautomaten und sind besonders in der Embedded-Entwicklung verbreitet.
Skizze oder Modell?
UML wird auf zwei grundverschiedene Arten eingesetzt. Als Skizze dient sie der Kommunikation: ein schnelles Diagramm am Whiteboard, um eine Architekturidee zu erklären. Das ist legitim und nützlich, aber die Semantik existiert dabei nur im Kopf der Beteiligten. Als formales Modell dagegen ist UML ein maschinenlesbares Artefakt: Hinter jedem Element steht das UML-Metamodell mit definierter Bedeutung, ein Werkzeug kann das Modell auf Konsistenz prüfen, und aus dem Modell lassen sich weitere Artefakte ableiten. Erst diese zweite Nutzungsart erschließt den eigentlichen Wert der Sprache — und über den Profilmechanismus lässt sich die UML dabei um domänenspezifische Konzepte erweitern.
Rolle in der modellgetriebenen Softwareentwicklung
In der modellgetriebenen Softwareentwicklung (MDSD) sind UML-Modelle nicht Dokumentation, sondern Quellartefakt: Ein Generator übersetzt sie deterministisch in ausführbaren Code. Aus Klassendiagrammen entstehen Datenstrukturen und Schnittstellen, aus Zustandsdiagrammen vollständige Verhaltensimplementierungen in C, C++, Java oder Python. Dieselbe Eingabe erzeugt dieselbe Ausgabe — diese Reproduzierbarkeit ist mehr als eine Annehmlichkeit: In der regulierten Entwicklung unter ISO 26262, IEC 61508 oder DO-178C ist sie die Grundlage der Nachweiskette. Handgeschriebener Code und generierter Code bleiben dabei sauber getrennt; das Modell ist die Single Source of Truth für das generierte Verhalten.
Verhältnis zu SysML und DSLs
Für das Systems Engineering wurde die UML zur SysML weiterentwickelt: SysML v1 ist als UML-Profil definiert und ersetzt softwarespezifische Konzepte durch disziplinneutrale Blöcke. Wo auch eine profilierte UML die Domäne nicht adäquat trifft, sind domänenspezifische Sprachen (DSLs) die Alternative — eigene Sprachen mit eigenem Metamodell, exakt auf ein Fachgebiet zugeschnitten.
UML in der Praxis
Der pragmatische Umgang hat sich durchgesetzt: kein Versuch, ein System vollständig in allen 14 Diagrammtypen vorab zu spezifizieren, sondern gezielter Einsatz weniger Diagrammarten dort, wo sie tragen — Architekturdokumentation, Schnittstellenverträge und vor allem Codegenerierung aus Verhaltensmodellen. Entscheidend ist die Disziplin, das Modell als verbindliches Artefakt zu pflegen: Ein UML-Modell, das neben dem Code herläuft und veraltet, ist Aufwand ohne Nutzen; ein Modell, aus dem generiert wird, kann gar nicht veralten.