EMZETT.UML
Kurz: Unified Modeling Language — eine standardisierte grafische Notation, um Software-Architektur und -Abläufe zu visualisieren.
Genauer: Umfasst verschiedene Diagrammtypen für unterschiedliche Zwecke: Klassendiagramme (Struktur von Objekten/Klassen), Sequenzdiagramme (zeitlicher Ablauf von Interaktionen), Use-Case-Diagramme (Nutzerinteraktionen mit dem System) u. a. Wird in der Softwareentwicklung genutzt, um Design vor der Implementierung zu planen und im Team zu kommunizieren.
Im Detail
Ein UML-Klassendiagramm zeigt Klassen, ihre Attribute, Methoden und die Beziehungen zwischen ihnen — grafisch als Rechteck mit drei Abschnitten (Klassenname, Attribute, Methoden), verbunden durch Pfeile für Vererbung (durchgezogene Linie mit leerem Dreieck), Assoziation (einfache Linie) oder Komposition (gefüllte Raute). Ein Sequenzdiagramm dagegen zeigt keine statische Struktur, sondern den zeitlichen Ablauf: senkrechte “Lebenslinien” für jedes beteiligte Objekt, waagerechte Pfeile für Methodenaufrufe zwischen ihnen, von oben nach unten in der Reihenfolge, in der sie tatsächlich passieren.
UML entstand in den 1990ern aus der Zusammenführung mehrerer konkurrierender Notationen und wurde schnell zum Industriestandard für die Softwarearchitektur-Dokumentation. In der Praxis wird selten die volle Formalität der UML-Spezifikation ausgeschöpft — die meisten Teams nutzen eine vereinfachte, informelle Untermenge, um schnell auf einem Whiteboard oder in einem Tool wie draw.io die grobe Struktur eines Systems zu skizzieren, bevor der erste Code geschrieben wird. Diagramme dienen dabei vor allem der Kommunikation im Team und mit Stakeholdern, weniger als vollständige, maschinenlesbare Spezifikation.
Strukturdiagramme vs. Verhaltensdiagramme
UMLs 14 offizielle Diagrammtypen lassen sich grob in zwei Gruppen einteilen: Strukturdiagramme zeigen statischen Aufbau (Klassendiagramme, Komponentendiagramme, Objektdiagramme — “was existiert und wie hängt es zusammen”), Verhaltensdiagramme zeigen dynamisches Verhalten über Zeit (Sequenzdiagramme, Aktivitätsdiagramme, Zustandsdiagramme — “was passiert wann”). In der Praxis werden von diesen 14 Typen fast ausschließlich Klassen- und Sequenzdiagramme regelmäßig genutzt, die übrigen Typen kommen meist nur in sehr formalen, dokumentationsintensiven Projekten (z. B. sicherheitskritische Software mit Zertifizierungspflicht) zum Einsatz.
Werkzeugunterstützung
Manche IDEs und spezialisierte Tools können UML-Diagramme teilweise automatisch aus bestehendem Code generieren (Reverse Engineering) oder umgekehrt aus einem Diagramm ein Code-Skelett erzeugen (Forward Engineering) — in der Praxis wird diese Automatisierung selten vollständig genutzt, da echter Code meist schneller angepasst wird als ein synchron gehaltenes Diagramm, und Diagramme veralten schnell, wenn sie nicht aktiv gepflegt werden. Häufiger dient UML heute als einmaliges Planungs-/Kommunikationswerkzeug zu Beginn eines Projekts oder einer größeren Funktion, nicht als dauerhaft synchron gehaltene Dokumentation.
PlantUML und textbasierte Alternativen
Ein moderner Ansatz, das Veralten von UML-Diagrammen zu vermeiden, sind textbasierte Werkzeuge wie PlantUML oder Mermaid — Diagramme werden als einfacher Text im Code-Repository selbst definiert und bei Bedarf automatisch gerendert, statt als separate, leicht vergessene Bilddatei. Das erlaubt es, Diagramme wie normalen Code zu versionieren und in Pull Requests mitzureviewen, was die Pflegehürde gegenüber klassischen grafischen UML-Tools deutlich senkt.