Unified Modeling Language

Grundlagen und Bedeutung

Die Unified Modeling Language (UML, „vereinheitlichte Modellierungssprache“) ist eine grafische Modellierungssprache zur Spezifikation, Konstruktion, Dokumentation und Visualisierung von Teilen von Software und anderen Systemen. Sie wird von der Object Management Group (OMG) entwickelt und ist von der OMG sowie von der ISO genormt; für Version 2.4.1 gilt ISO/IEC 19505. Die UML entstand in den 1990er-Jahren. Die aktuelle Version ist UML 2.5.1 von Dezember 2017. Ein wichtiger Dialekt ist SysML.

UML definiert Bezeichner für zentrale Modellierungsbegriffe, mögliche Beziehungen zwischen diesen Begriffen und grafische Notationen. Sie beschreibt sowohl statische Strukturen als auch dynamische Abläufe. UML ist deshalb besonders wichtig, weil verschiedene Beteiligte eines Softwareprojekts ein gemeinsames, formal geregeltes Verständnis eines Systems entwickeln können.

Ein UML-Diagramm ist nur eine grafische Sicht auf einen Ausschnitt eines UML-Modells. Das Modell enthält die zugrunde liegenden Modellelemente und ihre Beziehungen. Beispielsweise können Auftraggeber und Fachvertreter Anforderungen in Anwendungsfalldiagrammen prüfen, Softwareentwickler Arbeitsabläufe aus Aktivitätsdiagrammen umsetzen und Systemingenieure Softwaresysteme anhand eines Verteilungsdiagramms installieren und betreiben. UML regelt außerdem Formate, mit denen Modelle und Diagramme zwischen Werkzeugen ausgetauscht werden können.

Entwicklung und Aufbau von UML 2

Die erste UML-Version entstand als Reaktion auf zahlreiche Modellierungssprachen und -methoden für die damals aufkommende objektorientierte Softwareentwicklung. Grady Booch, Ivar Jacobson und James Rumbaugh führten ihre unterschiedlichen Notationssysteme bei Rational Software strukturiert zusammen. Einfluss hatten unter anderem OOSE, RDD, OMT, OBA, OODA, SOMA, MOSES und OPEN/OML. Am 19. November 1997 akzeptierte die OMG UML als Standard. Die Sprachfolge UML 1.x wurde 2005 durch die grundlegend überarbeitete UML 2 abgelöst.

Die Entwicklung von UML2 begann im August 1999 mit einem Request for Information der OMG. Im September 2000 folgten Vorschläge für drei Teilspezifikationen: UML 2.0 Infrastructure, UML 2.0 Superstructure und UML 2.0 OCL. Nach mehreren überarbeiteten Vorschlägen empfahl die zuständige Arbeitsgruppe 2003 die Entwürfe des Konsortiums U2. Im September 2004 waren die Finalization Task Forces mit Infrastructure und OCL fertig; die Superstructure verzögerte sich zunächst weiter.

Am 21. Oktober 2008 veröffentlichte die OMG die Beta 1 von UML 2.2, deren endgültige Version im Februar 2009 vorlag. UML 2.2 führte das Profildiagramm ein. UML 2.3 erschien im Mai 2010 und enthielt vor allem Fehlerkorrekturen am Metamodell sowie Präzisierungen der Semantik. UML 2.5 wurde im Juni 2015 veröffentlicht, UML 2.5.1 im Dezember 2017.

UML2 ist in drei zentrale Teilspezifikationen gegliedert. Die Infrastructure Specification bildet das Fundament und definiert häufig verwendete Elemente wie Klasse, Assoziation und Multiplizität. Die Superstructure Specification baut darauf auf und beschreibt Elemente für bestimmte Anwendungszwecke, etwa Anwendungsfälle, Aktivitäten und Zustandsautomaten. Die Object Constraint Language Specification definiert OCL2. Zusätzlich beschreibt UML 2.0 Diagram Interchange den Austausch des Diagramm-Layouts.

Metamodell, Spracheinheiten und Erweiterungen

Die Metamodellierung ordnet UML in vier Ebenen M0 bis M3 ein. Auf M3 liegt die Meta Object Facility (MOF), das Metametamodell mit grundlegenden Elementen wie Paketen, Klassen, Attributen und Assoziationen. UML2 liegt auf M2 und ist in MOF definiert. Die in der Praxis erstellten UML-Modelle liegen auf M1 und beschreiben konkrete Objekte der M0-Ebene, also Laufzeitinstanzen eines Systems. UML2 und MOF verwenden dabei eine gemeinsame Infrastrukturbibliothek mit grundlegenden Modellierungselementen.

Die UML 2.0 Superstructure ist modular in Spracheinheiten aufgebaut. Eine Spracheinheit umfasst zusammengehörige Modellierungselemente für einen bestimmten Aspekt und Formalismus. Viele Spracheinheiten sind zusätzlich in Compliance Levels gegliedert: Die untere Schicht enthält einfache und häufige Elemente, höhere Schichten ergänzen komplexere Elemente. Bei Aktivitäten definiert FundamentalActivities beispielsweise hierarchisch geschachtelte Gruppen von Aktionen; BasicActivities ergänzt Kanten und Hilfsknoten zu einem Graphen.

Wichtige Spracheinheiten sind:

• Aktionen: Elementare Bausteine des Verhaltens. Sie nehmen über Eingabepins Werte auf und erzeugen über Ausgabepins Werte.
• Aktivitäten: Modelle für Verhalten aus Aktionen sowie Kontroll- und Datenflüssen. Knoten können Objekt- oder Kontrollknoten, Kanten Objekt- oder Kontrollflüsse sein. Aktivitäten können verschachtelt und modularisiert werden.
• Allgemeines Verhalten: Gemeinsame Grundlagen für Aktivitäten, Interaktionen und Zustandsautomaten. Verhalten beginnt aufgrund diskreter Ereignisse. Die Spracheinheit behandelt auch Zeitbeobachtungen, Zeitausdrücke, Zeitintervalle und Dauer.
• Anwendungsfälle: Anforderungen an ein System. Ein Anwendungsfall beschreibt, was das System tun soll; ein Akteur bezeichnet eine Person oder ein anderes System, das mit dem System handelt.
• Informationsflüsse: Informationseinheiten und Informationsflüsse beschreiben grundlegende Informationsbewegungen auf hoher Abstraktionsstufe. Sie können unter anderem Klassen, Anwendungsfälle, Akteure, Schnittstellen und Ports verbinden.
• Interaktionen: Verhalten durch Nachrichtenaustausch zwischen eigenständigen Objekten. Ihre Semantik wird durch Mengen gültiger und ungültiger Spuren, also Folgen von Ereignissen, beschrieben. Grafisch verwendet man Lebenslinien, Nachrichten und Aktionen.
• Klassen: Kernbereich der UML. Er definiert Klassen und Beziehungen wie Assoziationen, Abhängigkeiten und Generalisierungen. Zentrale Begriffe sind Element, Namensraum, Typ und Multiplizität mit unterer und oberer Schranke.
• Komponenten: Modulare Systemteile, die durch eine äquivalente Komponente ersetzbar sein können. Sichtbar sind angebotene und benötigte Schnittstellen sowie Ports. Delegations- und Kompositionskonnektoren beschreiben Verbindungen nach außen und im Inneren.
• Kompositionsstrukturen: Ein gekapselter Classifier stellt ein Ganzes dar; Parts und Konnektoren beschreiben seine innere Struktur. Ports können die Grenze zwischen Innen und Außen durchlässig machen.
• Modelle: Diese Spracheinheit umfasst nur das Modellelement Modell.
• Profile: Leichtgewichtiger Erweiterungsmechanismus für spezielle Einsatzgebiete. Profile sammeln Stereotype, ergänzen Begriffe, Notationen oder Einschränkungen und können semantische Variationspunkte konkretisieren. Sie dürfen jedoch keine UML-Metamodellelemente entfernen, Einschränkungen aufheben oder echte neue Metaklassen einführen.
• Schablonen: Parametrisierung von Klassifizierern, Klassen und Paketen.
• Verteilungen: Modellierung installierbarer Software-Artefakte auf Knoten. Knoten sind Geräte oder Ausführungsumgebungen; eine Verteilungsbeziehung beschreibt die Installation.
• Zustandsautomaten: Beschreibung von Systemzuständen und zulässigen Übergängen. Verhaltenszustandsautomaten modellieren das Verhalten, Protokollzustandsautomaten etwa die zulässige Reihenfolge von Schnittstellenaufrufen.

Diagramme und ihre Verwendung

UML-Diagramme werden in Strukturdiagramme und Verhaltensdiagramme eingeteilt. UML 2.3 kennt jeweils sieben Typen.

Strukturdiagramme sind Klassendiagramm, Kompositionsstrukturdiagramm beziehungsweise Montagediagramm, Komponentendiagramm, Verteilungsdiagramm, Objektdiagramm, Paketdiagramm und Profildiagramm. Verhaltensdiagramme sind Aktivitätsdiagramm, Anwendungsfalldiagramm beziehungsweise Use-Case- oder Nutzfalldiagramm, Interaktionsübersichtsdiagramm, Kommunikationsdiagramm, Sequenzdiagramm, Zeitverlaufsdiagramm und Zustandsdiagramm.

Die Grenzen zwischen den vierzehn Diagrammtypen sind nicht vollständig scharf. Ein Diagramm darf grafische Elemente verschiedener Diagrammtypen enthalten; auch Elemente eines Struktur- und eines Verhaltensdiagramms können gemeinsam dargestellt werden, wenn dies eine besonders treffende Aussage über das Modell ermöglicht.

Typische Zuordnungen sind Aktivitätsdiagramme für dynamische Abläufe aus Aktionen und Flüssen, Anwendungsfalldiagramme für Anforderungen, Sequenz-, Kommunikations- und Zeitverlaufsdiagramme für Interaktionen, Klassendiagramme für Klassen und ihre Beziehungen, Komponentendiagramme für modulare Systemteile, Kompositionsstrukturdiagramme für innere Strukturen, Verteilungsdiagramme für die Installation von Artefakten und Zustandsdiagramme für Zustandsautomaten. Informationsflüsse besitzen keinen eigenen Diagrammtyp; ihre Notation kann in allen Strukturdiagrammen vorkommen.

Diagramme können mit Stift und Papier, mit einfachen Zeichenprogrammen oder mit UML-Werkzeugen erstellt werden. Einfache Programme zeichnen nur grafische Elemente und speichern die zugehörigen Modellelemente nicht in einem Repository. UML-Werkzeuge der zweiten Gruppe unterstützen sowohl die Modellierung als auch die Darstellung der Diagramme.

Austausch von Modellen und Diagrammen

Für den Austausch von UML-Modellen zwischen Werkzeugen definiert die OMG das XML-basierte Format XML Metadata Interchange (XMI). XMI und UML beruhen beide auf den Konzepten der Meta Object Facility (MOF). Dadurch können semantische Informationen eines Modells zwischen Werkzeugen übertragen werden.

In UML 1.x konnten zwar die Repository-Modelle hinter den Diagrammen ausgetauscht werden, nicht jedoch das eigentliche Diagramm-Layout. Positionen und Größen der Diagrammelemente gingen dabei verloren. UML 2.0 Diagram Interchange ergänzt deshalb ein standardisiertes Format für den Austausch und die Wiederverwendung von Diagrammen einschließlich ihres Layouts.

Der Austausch mit anderen Modellierungssprachen kann durch Modell-zu-Modell-Transformationen erfolgen. Dafür definiert die OMG den Standard MOF QVT. Eine solche Transformation kann im Unterschied zu einem reinen Austauschformat auch eine eigene Semantik festlegen, etwa die Abbildung eines Klassenmodells auf ein ER-Modell. Das ist auch beim Austausch zwischen Werkzeugen nützlich, weil verschiedene Hersteller individuelle Varianten des UML-Metamodells verwenden können.