UML – eine grafische Modellierungssprache

Die Unified Modeling Language (UML), zu Deutsch: „vereinheitlichte Modellierungssprache“, ist ein Standard zur visuellen Darstellung von Objekten, Zuständen und Prozessen innerhalb eines Systems. Die Modellierungssprache kann zum einen als Blaupause für ein Projekt dienen und so eine strukturierte Informationsarchitektur gewährleisten; zum anderen hilft sie Entwicklern, die Systembeschreibung für Fachfremde nachvollziehbar darzustellen. UML findet hauptsächlich Anwendung in der objektorientierten Software-Entwicklung. Durch Erweiterungen des Standards in der Version 2.0 eignet er sich auch für die Darstellung von Geschäftsprozessen.

Bevor die UML Einzug in die Software-Entwicklung hielt, wuchs das Feld der objektorientierten Programmierung (OOP). Dieser Programmierstil basiert auf dem Konzept, dass alles ein Objekt ist: Die Bausteine eines Programms sind Objekte, die miteinander interagieren. Die Nachrichten, die zwischen den Bestandteilen hin und her gesendet werden, bestehen ebenso aus Objekten. Jedes einzelne Objekt steht exemplarisch für seine übergeordnete Klasse. Die Klasse selbst agiert auch als Objekt und bestimmt zudem das Verhalten der Objektinstanzen, die sie beinhaltet. Objekte bestehen aus Daten und Code. Die Daten ordnet das Objekt in Felder, auch Attribute genannt. Der Code bestimmt deren Verfahrensweise bzw. die Methode.

Vom Ende der 1980er Jahre bis hinein in die 1990er Jahre entstand eine Vielzahl von Methoden und Sprachen zur modellhaften Darstellung von objektorientierter Programmierung. Die Folge war eine unübersichtliche Fülle an untereinander kaum vergleichbaren Methoden. Um diese zu vereinheitlichen, entschlossen sich die drei Entwickler James Rumbaugh, Grady Booch und Ivar Jacobson dazu, mehrere bestehende Sprachen in einem gemeinsamen Standard zusammenzuführen.

Die drei hatten bereits jeweils eigene objektorientierte Software-Entwicklungs-Methoden kreiert:

• die Booch-Methode
• die Object-Modeling-Technik (OMT)
• die Object-Oriented Software-Engineering-Methode (OOSE)

Als Modellierungssprache sollte UML die Semantik bei der Darstellung dieser Methoden festlegen. Unter dem Namen „UML Partners“ arbeiteten die Entwickler ab 1996 mit einem Team an der Fertigstellung von UML. Anschließend übergaben sie es an die Object Management Group (OMG), die wiederum 1997 die Unified Modeling Language in der Version 1.1 als Standard einführte.

Damit noch nicht zufriedengestellt, gründeten die Entwickler eine Task Force, die die Sprache über mehrere Versionen hinweg verbessern sollte. Bestehende Kritikpunkte waren u. a. eine unpräzise, unnötig komplexe Semantik, eine mangelnde Anpassbarkeit und eine ungenügende Standardisierung. Deshalb wurde eine größer angelegte Überarbeitung vorgenommen. Das Ergebnis war schließlich UML 2.0, das 2005 den neuen Standard setzte. Die Version 2.4.1 bildet die Grundlage für die ISO-Normierung 19505-1 (Infrastruktur) und 19505-2 (Superstruktur) von 2012. Die UML-Version 2.5.1 erschien im Dezember 2017.

Die Unified Modeling Language wird von einigen als Lingua franca unter den Modellierungssprachen bezeichnet. Wie eingangs erwähnt, verdeutlicht die UML durch visuelle Darstellung die Zustände von und Interaktionen zwischen Objekten innerhalb eines Systems. Ihre weite Verbreitung verdankt sie möglicherweise dem großen Einfluss der OMG-Mitglieder (u. a. IBM, Microsoft und HP). Die strukturierte Semantik trägt ihr Übriges dazu bei. Mit UML-Diagrammen stellen Sie folgende Systembestandteile dar:

• einzelne Objekte (grundlegende Bestandteile)
• Klassen (fasst Elemente mit gleichen Eigenschaften zusammen)
• Beziehungen zwischen Objekten (Hierarchie und Verhalten/Kommunikation zwischen Objekten)
• Aktivität (komplexe Kombination von Aktionen/Verhaltensbausteinen)
• Interaktionen zwischen Objekten und Schnittstellen

Die obere Grafik zeigt die Metamodellierung von UML 2.0. Ebene M0 ist die grundlegende Ebene. Sie stellt konkrete, reale Objekte und einzelne Datensätze dar – z. B. ein Objekt oder eine Komponente. Ebene M1 umfasst alle Modelle, die die Daten der Ebene M0 beschreiben und strukturieren. Das sind UML-Diagramme wie das Aktivitätsdiagramm oder das Paketdiagramm (weiter unten erklärt). Um den Aufbau dieser Modelle zu definieren, legen Metamodelle der Ebene M2 die Spezifikationen und Semantik der Modellelemente fest.

Wollen Sie ein verständliches UML-Diagramm erstellen, müssen Sie das Metamodell UML mit seinen Regeln kennen. Die höchste Ebene, M3, ist ein Metamodell des Metamodells. Die erwähnte Meta Object Facility arbeitet auf einer abstrakten Ebene, die Metamodelle definiert. Diese Ebene definiert sich selbst, da sonst weitere, übergeordnete Meta-Ebenen entstünden.

UML (Ebene M2) legt die Regeln für seine eigene Semantik fest. Die Spracheinheiten sind Begriffe, die in der UML 2.0 Superstructure definiert werden. Das ermöglicht eine formale Darstellung, die alle Beteiligten verstehen können. Spracheinheiten, im Englischen language units, abstrahieren ähnlich aufgebaute und funktionierende Objekte und Prozesse und geben ihnen eine visuell darstellbare Form. Je nach Hierarchie-Ebene innerhalb des Modells übernehmen Elemente weiter spezialisierte Aufgaben oder definieren andere Elemente näher.

Klasse: Als Spracheinheit sind Klassen ein Kernaspekt von UML. Sie definieren, was eine Klasse ausmacht und wie Klassen miteinander interagieren. Diese language unit hat vier Ebenen, die von simplen Elementen bis zu komplexeren Beziehungen reichen:

• Kernel (beschreibt Elemente aus der UML 2.0 Infrastructure wie Paket, Namensraum, Attribut etc.)
• AssociationClasses (definiert Assoziationsklassen)
• Interfaces (definiert Schnittstellen)
• Powertypes (Klasse, deren Instanzen Subklassen innerhalb dieser Klasse sind)

Komponente: Komponenten sind Bestandteile, die ihren Inhalt vom äußeren System abgrenzen. Nur durch Schnittstellen oder Ports besteht eine Verbindung nach außen. Ein Kompositionskonnektor stellt über die Schnittstelle eine Verbindung mit einer anderen Komponente her. Der Delegationskonnektor verknüpft innere Elemente mit einer Schnittstelle an der Außengrenze. Komponenten sind modular aufgebaut und austauschbar.

Kompositionsstruktur: Die Spracheinheit Kompositionsstruktur beschreibt Elemente, die wie Komponenten nach innen und außen abgeschirmt sind. Nur Ports verbinden den Inhalt mit dem äußeren System. Die sogenannten gekapselten Classifier setzen sich aus Elementen, den Parts, zusammen. Parts kommunizieren über Konnektoren.

Profil: Ein Profil konfiguriert UML 2.0 für bestimmte Bedürfnisse. Abstrakte Begriffe wie Aktivität oder Objekt müssen für manche Projekte spezifiziert werden, um das Verständnis zu erhöhen. Stellenweise locker gesetzte Semantik und Notationen passen Sie mit einem Profil an.

Modell: Das Modell umfasst alle Elemente, die dazu nötig sind, eine spezifische Sicht auf Struktur oder Verhalten eines Systems darzustellen. Dazu gehören auch externe Einflüsse wie Akteure.

Aktion: Wenn es darum geht, Verhalten darzustellen, sind Aktionen von zentraler Bedeutung. Sie nehmen Werte über Eingabepins auf und geben sie an Ausgabepins aus. Das sind die thematischen Gruppen, die UML für Aktionen festsetzt:

• Objekte manipulieren
• Objektbeziehungen manipulieren
• Strukturmerkmale manipulieren
• Aufruf-Aktionen
• Werte erzeugen
• Aktionen auf Objekten
• Empfangen von Ereignissen

Verhalten: Die Spracheinheit Verhalten bzw. Verhaltensbeschreibung meint die Modellierung von dynamischen Aspekten innerhalb eines Systems. Sie umfasst drei Spezifikationen:

• Aktivität: Aktionen interagieren durch Daten- und Kontrollflüsse. Dadurch ergibt sich ein komplexes System von Verhaltensweisen – die Aktivitäten.
   
• Interaktion: Dieses Metamodell beschreibt, wie Nachrichtenflüsse zwischen Objekten ausgetauscht werden, wann eine Nachricht an welches Objekt gesendet wird und welche anderen Elemente dadurch beeinflusst werden.
   
• Zustandsautomaten: In einem Zustandsdiagramm modelliert dieses Metamodell Zustände (Situationen mit unveränderbaren Eigenschaften) sowie Pseudo-Zustände (Zustände ohne Wertebelegung) und deren Übergänge. Objekte in einem Zustand können Aktionen bzw. Aktivitäten zugeordnet werden.

Verteilung: Ein Netzwerk besteht aus Objekten, die miteinander in Maschen verbunden sind. Ein spezieller Anwendungsfall besteht, wenn diese Elemente lauffähige Software bzw. Artefakte darstellen. Diese Artefakte laufen auf Ausführungsumgebungen oder Geräten, die UML 2.0 als Knoten kategorisiert. Das Artefakt steht daher in Abhängigkeit zum Knoten. Die Verteilung stellt diese Abhängigkeitsbeziehung dar, die bei der Installation entsteht.

Anwendungsfall: Der Anwendungsfall (als Spracheinheit) stellt Systemanforderungen dar. Der Akteur (eine Person oder ein System) ist ein Element, das beschreibt, wer oder was eine bestimmte Aktivität mithilfe des Systems ausführen soll. Das System kann auch eine Klasse oder Komponente sein und wird daher als Subjekt beschrieben. Der Anwendungsfall (als Modellelement) teilt lediglich mit, dass ein genanntes, nach außen für Akteure sichtbares Verhalten erwartet wird. Die genauen Aktionen stellt es normalerweise nicht dar. Innerhalb einer Verhaltensbeschreibung ordnet die Modellierung die detaillierten Anforderungen dem Anwendungsfall zu.

Informationsflüsse: Diese UML-Spracheinheit beschreibt die Elemente Informationseinheit und Informationsfluss. Diese Modellelemente abstrahieren Techniken zur Verhaltensbeschreibung, die sehr detailorientiert sein können, wie Aktivitäten oder Interaktionen. Diese vereinfachte Darstellung erlaubt den universellen Einsatz dieser Modellierungselemente in allen UML-Diagrammtypen. Die Informationseinheit wird daher, im Gegensatz zur Klasse, nie näher durch Attribute beschrieben oder in Methoden eingebunden. Der Informationsfluss verbindet deshalb auch alle möglichen Elemente, die irgendeine Art von Informationen miteinander austauschen.

Die Modellierungssprache setzt 14 Diagrammtypen fest, die sich in zwei Kategorien aufteilen. Die Hauptkategorien Struktur und Verhalten stehen für die grundlegenden Konzepte, die die UML-Diagramme darstellen. Innerhalb der Gruppe der Verhaltensdiagramme spezifiziert UML die Unterkategorie der Interaktionsdiagramme. Eine vierte Teilspezifikation existiert seit UML 2.0. Sie legt die Gestaltung der Modelldiagramme fest.

• Verteilungsdiagramm: Das Verteilungsdiagramm modelliert die physische Verteilung von Artefakten auf Knoten. Knoten (nodes) sind entweder Hardware (device nodes), die einen Speicher bereitstellen kann, oder Software (execution environment nodes), die eine Umgebung für die Ausführung von Prozessen anbietet. Sie werden als dreidimensionaler Quader abgebildet. Artefakte zeichnen Sie als Rechtecke. Darin steht der Dateiname. Um es von einer Klasse zu unterscheiden, fügen Sie das Stereotyp <<artefact>> hinzu. Das Diagramm eignet sich zur Darstellung von Abhängigkeiten zwischen Knoten und Artefakten, sogenannten Verteilungsbeziehungen.
  
  
• Profildiagramm: Profildiagramme verwendet man auf dem Level des Metamodells. Sie dienen dazu, Klassen ein Stereotyp oder Paketen ein Profil zuzuordnen. Auf der Meta-Ebene haben Sie somit die Möglichkeit, das Modell für eine andere Plattform oder Domain anzupassen. Wenn Sie beispielsweise die UML-Semantik innerhalb eines Profils einschränken, vererbt es die Spezifikationen an die untergeordneten Klassen weiter.

• Aktivitätsdiagramm: Aktivitäten bestehen aus einem Geflecht von Aktionen, die durch Daten- und Kontrollflüsse miteinander in Bezug stehen. Während das Anwendungsfalldiagramm Systemvoraussetzungen darstellt, zeigt das Aktivitätsdiagramm, wie diese Anwendungsfälleablaufen. In dieser Art von Diagramm spielt beispielsweise das Token eine Rolle: Es ist bei parallelen Prozessen ein Marker dafür, welcher der Prozesse priorisiert wird und somit Ressourcen (z. B. Arbeitsspeicher) erhält.
   
• Zustandsautomatendiagramm: Ein Zustandsautomat, auch endlicher Automat genannt, stellt eine endliche Menge von Zuständen in einem System dar. Wird im System eine festgesetzte Bedingung erfüllt (ein Trigger ausgelöst), tritt eine korrespondierende Situation ein. Diese kann Aktivitäten oder Interaktionen umfassen. Unter UML 2.0 stellt ein Zustand diese Situation dar. Zustände werden als Knoten (engl.: vertices) angesehen und als Rechtecke mit abgerundeten Ecken dargestellt. Zudem modelliert das Zustandsautomatendiagramm die Übergänge (engl.: transitions) von einem Zustand (Quellknoten) in den anderen (Zielknoten). Zustandsübergänge modelliert UML als Kanten. Aktionen bilden den letzten Grundpfeiler. Sie ordnen dem Zustand Verhaltensspezifikationen zu.

Verhalten ist an bestimmte Situationen oder Ereignisse geknüpft. Das UML-Diagramm Zustandsautomat kennt 4 Spezifikationen:

• Eingangsverhalten (entry behavior)
• Verhalten im Zustand (doActivity)
• Verhalten, das im Fall eines Ereignisses eintritt (event behavior)
• Ausgangsverhalten (exit behavior)

Außerdem kann ein Zustand unterbrochen und an gleicher Stelle fortgeführt werden. Diese Eigenschaft nennt sich History-Zustand.

• Interaktionsübersichtsdiagramm: Das in UML 2.0 neu hinzugefügte Interaktionsübersichtsdiagramm hilft dabei, ein sehr komplexes System zunächst in einem groben Schema darzustellen, wenn ein normales Interaktionsdiagramm sonst zu unübersichtlich wird. Für die detaillierte Darstellung eignet sich beispielsweise ein Sequenzdiagramm. Das UML-Diagramm wird ähnlich dem Aktivitätsdiagramm mit Knoten dargestellt. Es stellt Kontrollflüsse zwischen Interaktionen dar. Der Unterschied zum Aktivitätsdiagramm besteht darin, dass innerhalb von Knoten, die für Aktivitäten stehen, ein ganzes Interaktionsdiagramm verschachtelt sein kann. Diese Verschachtelungen können direkt im Diagramm gezeigt werden (inline) oder man verweist (Schlüsselwort: ref, von engl.: reference) auf das Modell, das an anderer Stelle detailliert dargestellt ist.

Die folgende Übersicht zeigt übergeordnete Kategorien und Anwendungsmöglichkeiten der einzelnen Diagrammtypen in Kurzform. Wenn Sie ein modellorientiertes Software-System, einen Anwendungsfall in der Wirtschaft o. Ä. visuell darstellen wollen, sollten Sie laut Empfehlung der UML-Task-Force vorher einen der UML-Diagrammtypen wählen. Erst dann lohnt es sich, eines der vielen UML-Tools zu wählen, da diese häufig eine gewisse Methode vorschreiben. Dann erstellen Sie das UML-Diagramm.