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.
Entstehung der Unified Modeling Language
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.
UML: Wichtige Begriffe
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
Metamodellierung
UML 2.0 legt Spracheinheiten fest, die auf verschiedenen Ebenen agieren. Mit diesen drücken Sie die Struktur und das Verhalten eines Systems aus. Einige Elemente nutzt die Modellierungssprache, um sich selbst zu definieren. Die Meta-Modellierung umfasst alle Elemente von UML, auch solche, die UML selbst beschreiben. Dafür nutzt es vier hierarchisch angeordnete Ebenen (M0 bis M3).
Die Meta-Metaebene M3 spezifiziert die Metadaten der Modellierungssprache und deren Zusammenhänge mithilfe der Meta Object Facility (MOF). Sie definiert das Metamodell. Zudem befähigt Sie den Metadaten-Transfer. Das von der OMG definierte Format XMI ist ein praktisches Tool, um objektorientierte Daten auf Meta-Metaebene zwischen Entwicklungstools zu teilen. Die Object Constraint Language (OCL), eine deklarative Programmiersprache, ergänzt UML und reguliert Randbedingungen der jeweiligen Modellierung. Als Textsprache wirkt sie jedoch nur unterstützend, statt selbst für Modellierung zur Verfügung zu stehen.
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.
Spracheinheiten
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.
UML-Diagramme: Einsatzbereiche und kurze Einführung
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.
Strukturdiagramme
Strukturdiagramme stellen die einzelnen Elemente in einem System dar. Deshalb eignen sie sich besonders für die Darstellung von Software-Architektur. Die statische Darstellung stellt keine Veränderung dar, sondern Zustände und Abhängigkeiten zu einem bestimmten Zeitpunkt. Die einzelnen Elemente, oder Objekte, stehen in Beziehung zu einander. So gehört ein Objekt z. B. in eine Klasse. Weitere Bestandteile sind Rechnerknoten oder Artefakte – ein Artefakt stellt ein Ergebnis dar, beispielsweise eine fertige Script-Datei.
UML-Diagramme dieser Kategorie stellen ein ganzes System oder eine Teilstruktur dar. Letzteres hilft beispielsweise dabei, die Struktur detailliert zu verdeutlichen. Unter UML 2.x ordnet die Sprache der Kategorie Struktur sieben Diagrammtypen zu:
- Klassendiagramm: Weisen Objekte ein gemeinsames Verhalten oder die gleiche Struktur auf, kann man sie klassifizieren bzw. einer Klasse zuordnen. Die Klasse ist somit ein vereinfachendes, zusammenfassendes Element (Abstraktion) zur visuellen Darstellung. Klassen und Objekte werden miteinander und untereinander durch Schnittstellen verbunden. All diese Bestandteile sowie deren Beziehungen zueinander stellt das Klassendiagramm dar. Eine Klasse stellt das Diagramm mit einem Rechteck dar. Darin steht der Name der Klasse in fetter Schrift, wie unten zu sehen.
- Objektdiagramm: Das Objektdiagramm hat einen ähnlichen Aufbau wie das Klassendiagramm. Dort, wo im Klassendiagramm der Name steht (siehe oben: Person), gibt das Objektdiagramm den Instanznamen zusammen mit dem Classifier-/Kategorienamen an. Laut Spezifikation unterstreicht man diese (z. B.: Helga:Person)
- Komponentendiagramm: Eine Komponente ist ein gegen das äußere System abgeschottetes Modul, das über definierte Schnittstellen mit anderen Komponenten interagiert. Es ist eine Unterform der Klasse. Daher definieren strukturelle Merkmale wie Operationen und Attribute die Komponente näher. Die Komponente umschließt mehrere Bestandteile. Das können wieder Komponenten sein, aber auch Klassen, Subsysteme oder Parts. Bei der Modellierung gibt es zwei Darstellungsmöglichkeiten, je nach Bedarf: die Black-Box-Sicht (Inhalt ist versteckt) und die White-Box-Sicht (Inhalt ist sichtbar).
- Kompositionsstrukturdiagramm: Objekte gehören zu Klassen. Diese wiederum können auch klassifiziert werden. Diese Metaklassen nennt man in UML Klassifizierer. Das Kompositionsstrukturdiagramm stellt die Parts und Konnektoren eines Klassifizierers dar. Parts sind immer Bestandteil des Ganzen, auch wenn sie nicht notwendigerweise zur Komplettierung des Klassifizierers nötig sind. Konnektoren sind die Verbindungen zwischen Parts. Merkmale oder Dienste, die Komponenten außerhalb des Classifiers benötigen, senden Parts über eine Schnittstelle.
- Paketdiagramm: Ein Paket (package) fasst Elemente wie Schnittstellen oder Klassen in einem Namensraum zusammen. Pakete können zudem mit anderen Paketen verschmelzen (package merge), diese importieren (package import) oder andere Pakete enthalten (Unterpakete). Pakete gliedern Diagramminhalte hierarchisch wie in einem Baumdiagramm. Anwendung findet das Paketdiagramm z. B. im Metamodell von UML 2. In Software-Systemen stellt es die Teilbereiche modular dar. Laut Spezifikation besteht ein Paket aus einem Kopf und einem Inhaltsbereich.
Ein Namensraum ist ein Element des UML-2-Metamodells. Bestandteile müssen einen Namen tragen und eines der folgenden Sichtbarkeitsattribute besitzen: package, private, protected oder public. Das Paket ist ein Spezialfall des Namensraums.
- 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.
Verhaltensdiagramme
Verhaltensdiagramme (behavioral diagrams) decken die restlichen Spezifikationen unter UML ab. Im Gegensatz zu Strukturdiagrammen sind sie nicht statisch, sondern bilden Prozesse und dynamische Situationen ab. Zu den Verhaltensdiagrammen gehören auch die Interaktionsdiagramme (s. u.).
- Anwendungsfalldiagramm: Das Anwendungsfalldiagramm (use case diagram) stellt dar, welche Verhaltensweise von einem System später erwartet wird. Diese Modellierung eignet sich nicht nur für Software-Systeme, sondern beispielsweise auch für erwartete Abläufe bei Geschäftsverhältnissen. Der Anwendungsfall involviert einen Akteur (Mensch oder System) mit einem Ziel. Das Diagramm trägt normalerweise das Ziel als Namen. Die verschiedenen Anwendungsfälle innerhalb des Systems erfüllen das Ziel des Akteurs.
Das Anwendungsfalldiagramm stellt UML mit einem Rechteck mit dem Label use case dar. Der Absender ist der Akteur (dieser wird, wie oben, als Strichmännchen dargestellt, auch wenn es sich um ein System handelt). Den Akteur verbindet ein Abhängigkeitsverhältnis (als Strich dargestellt) mit dem Anwendungsfall (Ellipse mit Label) innerhalb eines Systems (Rechteck mit Label <<system>> und Name des Systems).
- 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älle ablaufen. 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.
Interaktionsdiagramme
Interaktionsdiagramme sind eine Unterart der Verhaltensdiagramme. Somit bilden auch sie dynamische Situationen ab. Im Speziellen eignen sie sich zur Modellierung von Verhalten, bei dem Elemente Informationen austauschen. Die Diagramme definieren die Rolle der involvierten Objekte. Außerdem benennen und priorisieren sie die Nachrichten, die zwischen den Objekten hin- und hergesendet werden. Interaktionsdiagramme stellen zudem dar, wie diese Nachrichten Verhaltenselemente beeinflussen. Sie können beispielsweise Aktivitäten starten oder anhalten.
- Sequenzdiagramme: Als Interaktionsdiagramm stellt das Sequenzdiagramm den Nachrichtenaustausch zwischen Objekten dar. Diese Objekte modelliert der UML-Diagrammtyp als sogenannte Lebenslinie. In diesem Sinne hat es Ähnlichkeit mit anderen Verhaltensdiagrammen wie dem Aktivitätsdiagramm. Im Gegensatz zu diesen nutzt man das Sequenzdiagramm aber nicht, um eine weite Übersicht über das Verhalten eines Systems zu bekommen, sondern um ein mögliches Verhalten unter vielen detailliert darzustellen. Dabei schreibt es eine Chronologie vor. Eine gestrichelte Linie stellt den Zeitverlauf dar.
UML 2.0 stellt synchrone Nachrichten (UML: Pfeil mit gefüllter Spitze) und asynchrone Nachrichten (UML: Pfeil mit offener Spitze) dar. Synchrone Nachrichten sind solche, die so lange einen Kanal blockieren, bis sie eine Antwort vom Zielobjekt bekommen. Sie bestimmen Verhaltensmerkmale in Form von synchronen Operationen. Asynchrone Nachrichten kontrollieren das rufende Quellobjekt. Zu ihnen gehören sowohl asynchrone Operationen als auch Signale (zwischen Aktionen gesendete Datenpakete).
- Kommunikationsdiagramm: Ähnlich wie beim Sequenzdiagramm modelliert das Kommunikationsdiagramm einen Nachrichtentransfer. Auch hier werden Lebenslinien verwendet. Jedoch verwendet dieses UML-Diagramm für die zeitliche Abfolge keine gestrichelten Linien, sondern nummeriert die Sequenzen mit Zahlen und Buchstaben. Diese sogenannten Sequenzterme befinden sich über einem Pfeil, dessen Spitze in Richtung Empfänger zeigt. Zahlen stehen für die Reihenfolge, in der Nachrichten versendet werden, Buchstaben für die hierarchische Ebene (wie in der Abbildung unten zu sehen).
- Zeitverlaufsdiagramm: Das Zeitverlaufsdiagramm ermöglicht es, das Verhalten von Systemen unter dem Aspekt der zeitlichen Sequenzierung detailliert aufzuzeigen. Echtzeitsysteme beispielsweise müssen innerhalb einer bestimmten Zeit gewisse Prozesse abwickeln. Um die zeitliche Ebene besser darstellen zu können, modelliert UML 2.0 das Zeitverlaufsdiagramm (engl.: timing diagram) als zweidimensionales Diagramm mit einer x- und einer y-Achse. Bei dieser Unterform des Sequenzdiagramms liegen die Objektzustände auf der y-Achse und die ihnen zugeschriebenen Zeitsequenzen laufen entlang der y-Achse.
- 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.
UML-Diagramme: Eine Übersicht
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.
| Kategorie | Diagrammtyp | Verwendung |
|---|---|---|
| Struktur | Klassendiagramm | Klassen visualisieren |
| Objektdiagramm | Systemzustand in einem bestimmten Moment | |
| Komponentendiagramm | Komponenten strukturieren und Abhängigkeiten aufzeigen | |
| Kompositionsstrukturdiagramm | Komponenten oder Klassen in ihre Bestandteile aufteilen und deren Beziehungen verdeutlichen | |
| Paketdiagramm | Fasst Klassen in Pakete zusammen, stellt Pakethierarchie und -struktur dar | |
| Verteilungsdiagramm | Verteilung von Komponenten auf Rechnerknoten | |
| Profildiagramm | Veranschaulicht Verwendungszusammenhänge durch Stereotype, Randbedingungen etc. | |
| Verhalten | Anwendungsfalldiagramm | Stellt diverse Anwendungsfälle dar |
| Aktivitätsdiagramm | Beschreibt das Verhalten verschiedener (paralleler) Abläufe in einem System | |
| Zustandsautomatendiagramm | Dokumentiert, wie ein Objekt von einem Zustand durch ein Ereignis in einen anderen Zustand versetzt wird | |
| Verhalten: Interaktion | Sequenzdiagramm | Zeitlicher Ablauf von Interaktionen zwischen Objekten |
| Kommunikationsdiagramm | Rollenverteilung von Objekten innerhalb einer Interaktion | |
| Zeitverlaufsdiagramm | Zeitliche Eingrenzung für Ereignisse, die zu einem Zustandswechsel führen | |
| Interaktionsübersichtsdiagramm | Sequenzen und Aktivitäten interagieren |
Die Object Modeling Group vergibt UML-Zertifikate. Wenn Sie Ihr Know-how diesbezüglich vertiefen wollen, informieren Sie sich über UML-Tutorials auf der Task-Force-Website.