Einführung

---

Übersicht

UML 2.0 ordnet Diagramme in zwei primäre Kategorien:

Kategorie	Zweck
Strukturierte Diagramme	Erfassen die physische Organisation von Elementen – wie Objekte miteinander verbunden sind
Verhaltensbasierte Diagramme	Fokussieren sich darauf, wie Elemente interagieren, ihren Zustand ändern und Verhalten im Laufe der Zeit verarbeiten

💡 Wesentlicher Grundsatz: Ein UML-Modell besteht aus einem oder mehreren Diagrammen. Jedes Diagramm stellt eine bestimmte Sicht oder Interesse im zu modellierenden System dar. Individuelle Elemente erscheinen oft in mehreren Diagrammen.

---

🔷 Strukturierte Diagramme

Strukturierte Diagramme modellieren die statische Architektur Ihres Systems – das „Was“ statt das „Wie“.

1. Klassendiagramme

Zweck: Modellklassen, Schnittstellen und ihre statischen Beziehungen.

Wichtige Elemente:

• Klassen mit Attributen und Operationen

• Schnittstellen und Realisierungsbeziehungen

• Assoziationen, Aggregationen, Kompositionen und Generalisierungen

• Sichtbarkeitsmodifizierer (+, -, #, ~)

• Vielfachkeitsangaben (1, 0..*, 1..5)

Beispielverwendung:Wann es zu verwenden ist:

Klassen-Stereotypen und Typen

Das Diagramm verwendet Stereotypen (gekennzeichnet durch Text innerhalb von Klammerzeichen, wie <<entity>>) zur Kategorisierung der Rolle jeder Klasse:

• Grenzklassen (<<grenze>>): Diese verwalten die Interaktion zwischen dem System und seinen Akteuren (Benutzer oder externe Systeme).

• Beispiele: Konsolenfenster und Dialogfeld.

• Steuerungsklassen (<<steuerung>>): Diese verwalten die Koordination, Transaktionen und den Ablauf der Geschäftslogik der Anwendung.

• Beispiele: Zeichenkontext und Datensteuerung.

• Entitätsklassen (<<entität>>): Diese stellen die zentralen Daten oder dauerhaften Informationen dar, die das System verfolgt.

• Beispiele: Fenster, Fenster, Ereignis, Form, Kreis, Rechteck, Vieleck, und Punkt.

• Abstrakte Klasse: Die Form Die Klasse stellt einen abstrakten Begriff dar. Sie dient als Grundbauplan für spezifische Formen und kann nicht direkt selbst instanziiert werden.

---

Anatomie einer Klasse

Ein standardmäßiges UML-Klassenfeld ist in Abschnitte unterteilt. Betrachtet man die Kreis Klasse als Beispiel:

• Klassenname: Befindet sich im oberen Abschnitt (Kreis).

• Attribute: Befindet sich im mittleren Abschnitt und stellt die Datenelemente dar.

• -radius : float (Das Minuszeichen - zeigt ein privates Attribut an).

• -mittelpunkt : unsigned int

• Operationen (Methoden): Befindet sich im unteren Abschnitt und stellt das Verhalten oder die Funktionen dar.

• +area(in radius : float) : double (Das Pluszeichen + zeigt eine öffentliche Methode an).

• +umfang(), +setzeMittelpunkt(), und +setzeRadius().

---

Beziehungen und Links

Die Linien und Pfeile, die die Klassen verbinden, definieren, wie sie miteinander interagieren und voneinander abhängen:

Generalisierung (Vererbung)

Dargestellt durch eine durchgezogene Linie mit einem hohlem Pfeilkopf der auf die Elternklasse zeigt. Dies deutet eine „ist-ein“-Beziehung an, bei der eine Kindklasse Attribute und Verhaltensweisen von einer Elternklasse erbt.

• Fenster erbt von Fenster.

• Konsolenfenster und Dialogfeld erben von Fenster.

• Kreis, Rechteck, und Polygon erben von der abstrakten Klasse Form (z. B. ein Kreis ist eine Form).

Aggregation

Dargestellt durch eine durchgezogene Linie mit einem hohlem Diamanten am Behälterende. Dies deutet auf eine lose „besitzt-ein“- oder Ganze-Teil-Beziehung hin, bei der das Kind unabhängig vom Elternteil existieren kann.

• Fenster aggregiert Form (Mehrfachheit 1 bis *). Ein Fenster kann mehrere (*) Formen enthalten, aber wenn das Fenster geschlossen wird, können die Formen selbst weiterhin konzeptionell im Speicher oder in einem anderen Kontext existieren.

Komposition

Dargestellt durch eine durchgezogene Linie mit einem gefüllten (schwarzen) Diamanten am Behälterende. Dies deutet auf eine starke „besitzt-ein“-Beziehung mit gleichzeitiger Lebensdauer hin – wenn der Behälter zerstört wird, werden auch die Teile zerstört.

• Kreis besteht aus Punkt Objekte (Mehrfachheit 1 zu *). Ein Kreis kann nicht ohne seinen Mittelpunkt oder seine Randpunkte existieren; das Zerstören des Kreises zerstört diese spezifischen Punktverweise.

Abhängigkeit

Dargestellt durch eine gestrichelte Pfeil. Es zeigt, dass eine Klasse von einer anderen abhängt, was bedeutet, dass eine Änderung an der Zielklasse die Quellklasse beeinflussen kann.

• Fenster hat eine Abhängigkeit von Ereignis (gekennzeichnet durch den gestrichelten Pfeil, der auf Ereignis). Das Fenster beruht auf Ereignistriggern, um Operationen wie handleEvent().

Assoziation

Dargestellt durch eine einfache durchgezogene Linie. Sie zeigt eine strukturelle Beziehung an, bei der Objekte einer Klasse mit Objekten einer anderen Klasse verbunden sind.

• Dialogfeld ist assoziiert mit Datensteuerung, was bedeutet, dass sie miteinander kommunizieren, um Informationen zu übertragen oder ihr Verhalten abzustimmen.

---

Dokumentationselemente

• Hinweis: Das Diagramm zeigt eine Notizbox mit einer umgeklappten Ecke, die über eine gestrichelte Linie mit der Fenster Klasse verbunden ist. Sie liefert verständliche Kontextinformationen: „Das Hauptfenster der Anwendung.“

• Entwerfen einer objektorientierten Softwarearchitektur

• Dokumentation von Domänenmodellen

• Generieren von Code-Skeletten

---

2. Komponentendiagramme

Zweck: Zeigen die Organisation und Abhängigkeiten von Implementierungseinheiten an.

Wichtige Elemente:

• Komponenten (stereotypisiert als«komponente»)

• Bereitgestellte/erforderliche Schnittstellen (Kugel- und Sockelnotation)

• Montageverbindungen und Abhängigkeitsbeziehungen

• Artefakte (kompilierte Ausgaben: JARs, DLLs, ausführbare Dateien)

Beispielverwendung:Wann es zu verwenden ist:

Komponenten und modulare Grenzen

Im Zentrum des Diagramms steht das Konzept einer Komponente, einer autonomen und modularen Einheit eines Systems, die ihre Inhalte kapselt und ihr Verhalten über klare Schnittstellen manifestiert. Die große äußere Grenze stellt die übergeordneteTerminalKomponente dar, die als Untersystem oder Container fungiert. Innerhalb dieses Containers befinden sich kleinere, spezialisierte interne Komponenten – nämlichSicherheitsprüfung, Personal, Defekt, undKarte. Jede dieser internen Einheiten stellt ein modulares Stück Software oder Datenverwaltungslogik dar, das gemeinsam die Verantwortlichkeiten des Terminals erfüllt.

Schnittstellen als Verträge

Komponenten zeigen ihre interne Logik nicht direkt an; stattdessen interagieren sie über gut definierte Schnittstellen, die als architektonische Verträge dienen.

• Bereitgestellte Schnittstellen: Dargestellt durch ein „Lutscher“- oder Kreissymbol, kennzeichnen diese die Dienste, Daten oder Operationen, die ein Komponente implementiert und ihrer Umgebung anbietet. Beispielsweise zeigt die äußere Terminal-Komponente externe bereitgestellte Schnittstellen wie Status, Details, und Prüfobjekt, was angibt, was externe Clients von ihr anfordern können.

• Benötigte Schnittstellen: Dargestellt durch ein „Steckdosen“- oder Halbkreissymbol, geben diese die Dienste oder Daten an, die eine Komponente von einer anderen Entität benötigt, um ordnungsgemäß zu funktionieren. Auf der rechten Seite des Diagramms zeigt die Terminal-Komponente explizit benötigte Schnittstellen für Konto und Prüf-ID, was ihre Abhängigkeiten von externen Subsystemen zeigt.

Ports und interne Verdrahtung

Um den Daten- und Steuerfluss zu verwalten, während die Kapselung gewahrt bleibt, verwendet das System Ports und Delegationsbeziehungen.

• Ports: Die kleinen Quadrate, die an der Grenze der Komponenten liegen, stellen Ports dar. Sie fungieren als eindeutige Interaktionspunkte, über die die interne Struktur der Komponente mit der Außenwelt verbunden ist. Ports ermöglichen es einer Komponente, ihre interne Verdrahtung von der externen Umgebung zu isolieren, was bedeutet, dass interne Komponenten ersetzt oder geändert werden können, ohne dass sich der Eindruck der übergeordneten Komponente von außen verändert.

• Delegation und Zusammenstellung: Innerhalb des Terminals verbinden Linien diese Schnittstellen, um die strukturelle Zusammenstellung zu bilden. Eine bereitgestellte Schnittstelle am äußeren Port delegiert eingehende Anfragen direkt an die bereitgestellte Schnittstelle eines internen Komponenten (wie bei den Pfaden für Status und Details die in Sicherheitsprüfung). Umgekehrt verdrahten interne Komponenten ihre benötigten Steckdosen-Schnittstellen direkt in die bereitgestellten Lutscher-Schnittstellen benachbarter Komponenten. Beispielsweise stützt sich die Sicherheitsprüfung -Komponente auf die Prüfer -Schnittstelle, die von Mitarbeiter, die Defektdetails Schnittstelle bereitgestellt von Defekt, und die Standort Schnittstelle bereitgestellt von Karte, wodurch ein eng koordiniertes, aber lose gekoppeltes internes Ökosystem entsteht.

• Planung einer modularen Systemarchitektur

• Verwaltung von Build-Abhängigkeiten

• Dokumentation wiederverwendbarer Komponentenbibliotheken

---

3. Zusammengesetzte Strukturdiagramme (Hinzugefügt in UML 2.0)

Wichtige Elemente:

• Teile (Eigenschaften mit Ganze-Teil-Beziehungen)

• Schnittstellen (Interaktionspunkte mit bereitgestellten/erforderlichen Schnittstellen)

• Verbindungen (Laufzeitverbindungen zwischen Teilen)

• Zusammenarbeitsergebnisse

Beispielverwendung: Modellierung einer Auto:

Kapselnder Klassifikator (Klasse)

Das äußere Rechteck stellt den enthaltenden Klassifikator dar, in diesem Fall die AutoKlasse. In einem zusammengesetzten Strukturdiagramm fungiert diese Grenze als Container, der die interne Laufzeitkonfiguration des Systems kapselt. Sie definiert den Kontext, innerhalb dessen einzelne Instanzen zusammenarbeiten, um ein umfassenderes Verhaltensziel zu erreichen, und verbirgt die Komplexität, wie ein „Auto“ intern funktioniert, vor externen Entitäten.

Teile (Interne Struktur)

Die inneren Rechtecke innerhalb der Car-Grenze stellenTeile. Ein Teil erklärt eine Rolle, die von einer Menge von Instanzen während der Ausführung des enthaltenden Klassifizierspielers gespielt wird. Anstatt eine statische Kompilierzeit-Beziehung (wie ein Standard-Klassendiagramm) darzustellen, bezeichnen diese Teile Laufzeit-Instanzen, die spezifische architektonische Slots füllen:

• -t : Getriebe: Eine Instanz, die die Rolle des Getriebespiels spielt.

• -e : Motor: Eine Instanz, die die Rolle der Motor-Energiequelle spielt.

• -s : Lenksystem: Eine Instanz, die die Rolle des Lenkmechanismus spielt.

Die Doppelpunktnotation zeigt an, dass es sich um strukturelle Rollen handelt, die durch ihre jeweiligen Klassen typisiert sind, und genau definieren, welche Komponenten innerhalb eines betriebsbereiten Autos existieren müssen.

Ports und Grenzen

Die kleinen Quadrate, die sowohl an der äußeren Klassifizierer-Grenze als auch an den inneren Teil-Grenzen eingebettet sind, stellenPorts. Ports sind unterschiedliche Interaktionspunkte, die die interne Struktur eines Klassifizierspielers von seiner externen Umgebung entkoppeln.

• Externe Ports an der Car-Grenze – beispielsweise: Rad, : Gaspedal, und: Lenkrad– zeigen auf, wie das Auto mit der Außenwelt oder der physischen Umgebung interagiert, ohne aufzudecken,welcheinterne Teile diese Interaktionen bearbeiten.

• Ports auf den inneren Teilen (wie die Ports auf den Getriebe- oder Motorblöcken) regeln, wie diese Untereinheiten miteinander oder mit der übergeordneten Grenze kommunizieren.

Verbindungen und interne Verkabelung

Die festen Linien, die die Ports miteinander verbinden, stellenVerbindungen. Verbindungen definieren die Kommunikationspfade zwischen Teilen oder zwischen einem Teil und einem externen Port zur Laufzeit.

• Delegationsverbindungen: Verbinden einen äußeren Port des Containers direkt mit einem inneren Port eines Teils. Zum Beispiel den externen: Rad Port leitet direkt in das Getriebe, und das externe : Lenkrad leitet direkt zum Lenksystem. Dies stellt sicher, dass externe Reize nahtlos an den richtigen internen Akteur weitergeleitet werden.

• Montageverbindungen: Verbinden interne Teile, um Zusammenarbeit zu ermöglichen. Die Verbindung zwischen dem Getriebe und dem Motor zeigt, dass diese beiden unterschiedlichen Laufzeitrollen direkt Signale, Daten oder mechanische Kraft austauschen, um das Auto als ein einheitliches Ganzes funktionieren zu lassen.

Wann sollte es verwendet werden:

• Dokumentation von Entwurfsmustern

• Modellierung komplexer interner Zusammenarbeit

• Verbindung zwischen Klassendesign und Komponentenimplementierung

---

4. Bereitstellungsdigramme

Zweck: Abbildung von Softwareartefakten auf Hardware-Ausführungs-Umgebungen.

Wichtige Elemente:

• Knoten (Geräte, Ausführungs-Umgebungen)

• Artefakte (bereitstellbare Einheiten)

• Kommunikationspfade zwischen Knoten

• Bereitstellungsspezifikationen (Konfigurationsdetails)

Beispielverwendung:Wann wird es verwendet:

Knoten und physische Infrastruktur

Im Gegensatz zu logischen Design-Diagrammen, die die Code-Layout oder Klassenstrukturen modellieren, konzentriert sich ein Bereitstellungsdiagramm auf die Hardware-Topographie. Die primären Bausteine sindKnoten, die visuell als dreidimensionale Würfel dargestellt werden. Knoten veranschaulichen physische rechnerische Ressourcen oder Ausführungs-Umgebungen, in denen Software-Elemente tatsächlich laufen:

• <<prozessor>> Knoten: Würfel, die mit<<prozessor>> (zum BeispielCaching-Server, Primärer Server, und generischeServer Blöcke) stellen Knoten mit Rechenkapazität, Speicher und Verarbeitungsleistung dar, die in der Lage sind, Software-Binärdateien auszuführen.

• <<netzwerk>> Knoten: Der längliche Würfel mit der BeschriftungLokales Netzwerk stellt einen Kommunikationspfad oder eine Routing-Infrastruktur dar, anstatt einen einzelnen Computer. Er symbolisiert die physische Grundstruktur, die es verbundenen Prozessoren ermöglicht, Datenpaketströme auszutauschen.

• Geräteknoten: Unstereotypisierte Knoten wieInternet undModem-Bank stellen Grenz-Hardwarekomponenten oder externe physische Infrastruktur dar, die erforderlich sind, um externen Datenverkehr in die zentrale Systemumgebung zu leiten.

Assoziationen und Kommunikationspfade

Die festen Linien, die die dreidimensionalen Würfel verbinden, stellenAssoziationen. In einem Bereitstellungsdiagramm zeigen diese Assoziationen die physischen Kommunikationspfade, Netzwerkverbindungen oder Hardwareverbindungen zwischen Knoten auf.

• Die Linie zwischen Internet und Modem-Bankveranschaulicht den Eingangspunkt externer öffentlicher Daten in die Hardware-Schicht.

• Die Assoziation, die von der Modem-Bank nach unten in die Caching-Serverzeigt die physische Routenführung des eingehenden Datenverkehrs bis zur Edge-Caching-Schicht auf.

• Assoziationen, die die Caching-Server und die zugrundeliegende Primär-ServerCluster mit dem Lokalen Netzwerkzeigen auf, wie interne Komponenten über eine gemeinsame Hochgeschwindigkeits-Lokalbus- oder Netzwerk-Switch-Infrastruktur kommunizieren.

Topologische Schichtung und Redundanz

Die Anordnung der Knoten im Diagramm zeigt explizit die Bereitstellungstopologie und architektonische Gestaltungsoptionen für hohe Verfügbarkeit und Lastverteilung.

• Edge-Caching-Schicht: Direkt unter dem Eingangsmodem-Hardware befinden sich zwei verschiedene, parallele Caching-ServerKnoten. Diese Konfiguration veranschaulicht visuell eine redundante Edge-Schicht, die darauf ausgelegt ist, die eingehende Datenlast zu verteilen und Assets zu speichern, bevor Anfragen die tiefen Infrastrukturen erreichen.

• Interne Serverfarm: Am Boden des Stapels positioniert, über das Lokalen Netzwerk, befindet sich ein Cluster von Kernservern. Die Unterscheidung zwischen den Primär-Server und das benachbarte generische Server Knoten visualisiert eine Master-Replica- oder Primär-Primär-Architektur, wodurch sichergestellt wird, dass Datenpersistenz und intensive Rechenarbeiten sicher innerhalb der internen Rechenzentrumsumgebung koordiniert werden.

Zweck: Modelliert die interne Struktur von Klassifizierern und komplexen Mustern.

• Planung der Systeminfrastruktur

• Dokumentation verteilter Architekturen

• Spezifizieren von Failover- und Redundanzstrategien

---

5. Paketdiagramme

Zweck: Organisiert und verwaltet Namensräume durch logische Gruppierung.

Wichtige Elemente:

• Pakete (Rechtecke mit Tabs)

• Import-/Zugriffsbeziehungen («import», «access»)

• Zusammenführungsbeziehungen («merge»)

• Sichtbarkeit (+ public, - private)

Beispielverwendung:

Subsystem- und Paketgrenzen

Das Diagramm stützt sich stark auf die „Ordner“-Notation, um logische Gruppierungen von Gestaltungselementen darzustellen.

• Subsystem: Der große äußere Ordner, stereotypisiert als <<subsystem>> Bestellungen stellt eine wichtige, abgeschlossene Verhaltenseinheit des physischen Systems dar. Es fungiert als hochstufige Container, der verwandte Komponenten und Pakete gruppiert, die zur Ausführung der Bestellverwaltung erforderlich sind.

• Paket: Die kleineren Ordner innerhalb und außerhalb des Subsystems (wie UI, Bestellverarbeitung, und GUIManager) sind Standardpakete. Sie dienen dazu, Elemente in überschaubare Gruppen zu organisieren, Namensräume festzulegen und Sichtbarkeitsgrenzen innerhalb der Architektur zu definieren.

Abhängigkeiten und Schichtung

Strichlierte Pfeile deuten auf Abhängigkeiten, was bedeutet, dass eine Änderung in einem Paket (dem Ziel) die Funktionsweise des ursprünglichen Pakets (der Quelle) beeinflussen kann.

• Interne Abhängigkeiten: Innerhalb des Bestell-Subsystems ist eine klare top-down architektonische Schichtung sichtbar. Das UI -Paket hängt ab von Bestellverarbeitung, das wiederum von Preiskalkulator und Externer Speicher. Dies stellt einen architektonischen Fluss dar, bei dem oberflächliche Darstellungselemente auf zentrale Geschäftslogik- und Datenzugriffsschichten angewiesen sind.

• Abhängigkeit von externem Paket: Pakete können auch auf Elemente außerhalb ihrer unmittelbaren Subsystemgrenze angewiesen sein. Zum Beispiel hängt das UI Paket hängt von externen ab GUIManager. Ebenso hängen die Zufallspeicher und Stream-Speicher Pakete am unteren Rand überschreiten die Subsystemgrenze, um von externen Datenstrukturen abzuhängen, was zeigt, wie das Subsystem in ein größeres Software-Ökosystem integriert ist.

Abstraktion und Vererbung (Generalisierung)

Das Diagramm verwendet spezielle Stilisierungen und Beziehungspfeile, um abstrakte Entwurfsmuster zu zeigen, die auf modulare Architektur angewendet werden.

• Abstrakte vs. konkrete Pakete: Pakete, die abstrakte Elemente enthalten oder eine Schnittstellen-ähnliche Struktur definieren, werden mit kursiv geschriebenen Namen dargestellt (wie Externer Speicher und Speicherverwaltung). Umgekehrt verwenden Pakete, die Implementierungen von operativem Code enthalten, wie Repository und Dateispeicher, verwenden Standardtext, um anzugeben, dass es sich um konkrete Pakete handelt.

• Generalisierung: Wird durch eine durchgezogene Linie mit einem offenen, hohlen Dreieck dargestellt, das auf das übergeordnete Paket zeigt. Dies zeigt eine Vererbungs- oder Implementierungsbeziehung an. Innerhalb des Subsystems spezialisieren sich Zufallspeicher und Stream-Speicher oder implementieren die abstrakte Externer Speicher Schnittstelle. Außerhalb des Subsystems sind die konkreten Repository und Dateispeicher Pakete verallgemeinern sich nach oben hin in das Abstrakte Speicherverwaltung Paket, wobei gezeigt wird, wie polymorphes Verhalten und strukturelle Klassifikation auf Paketebene modelliert werden können.

  

• Wann sollte es verwendet werden:

• Verwaltung großer Codebasen

• Definition von Modulgrenzen

• Steuerung von Kompilationsabhängigkeiten

---

6. Objektdiagramme

Zweck: Zeigen Momentaufnahmen von Instanzen und ihren Verbindungen zu einem bestimmten Zeitpunkt an.

Wichtige Elemente:

• Objekte (unterstrichene Namen: meinAuto:Auto)

• Verbindungen zwischen Objektinstanzen

• Attributwerte zur Laufzeit

Beispielhafte Verwendung:

Objekte und konkrete Instanzen

Im Gegensatz zu Klassendiagrammen, die abstrakte, bausteinartige Konfigurationen zeigen, erfasst ein Objektdiagramm tatsächliche Instanzen, die im Speicher existieren. Objekte werden durch Rechtecke dargestellt, und ihre Namen sind immer unterstrichen, um die Instanziierung zu kennzeichnen.

• Benannte Objekte: Sie folgen der Syntax Instanzname : Klassenname. Zum Beispiel c : Unternehmen stellt eine bestimmte Instanz eines Unternehmens namens „c“ dar, und p : Person stellt eine bestimmte individuelle Instanz namens „p“ dar.

• Anonyme Objekte: Wenn die spezifische Instanzkennung weggelassen oder für die Situation irrelevant ist, wird nur der Klassenname angegeben, vorangestellt von einem Doppelpunkt (z. B. : Kontaktinformation). Dies gibt an, dass eine konkrete Instanz von Kontaktinformationen existiert und an die Struktur angehängt ist, jedoch in diesem Kontext keinen eindeutigen Variablennamen benötigt.

Zustand und Attributwerte

Das untere Feld eines Objektrechtecks enthält seinen spezifischen Zustand, definiert durch explizite Werte, die zu diesem Zeitpunkt seinen Attributen zugewiesen wurden. Anstatt nur Datentypen aufzulisten, verwenden diese Einträge das Format Attribut = WertZuweisungsformat, um die Realität widerzuspiegeln:

• Die Abteilungsinstanz d1enthält den Attributwert name = Verkauf.

• Eine andere, unterschiedliche Abteilungsinstanz d2enthält den Wert name = Forschung und Entwicklung.

• Die Personeninstanz penthält eine komplette Menge an Zustandsdaten, die ein bestimmtes Profil darstellen: name = Derek, Mitarbeiternummer = D-12821, und titel = Manager.

Verknüpfungen und Beziehungen

Die festen Linien, die die Objekte verbinden, stellen Verknüpfungen. Ein Link ist eine konkrete Instanz einer zwischen Klassen definierten Assoziation. Wenn ein Klassendiagramm besagt, dass Unternehmen Abteilungen haben, zeigt das Objektdiagramm die tatsächlichen Laufzeitverbindungen zwischen ihnen.

• Die Unternehmensinstanz c ist aktiv mit Abteilungsinstanzen verbunden d1 (Verkauf) und d2 (Forschung und Entwicklung).

• Das Diagramm zeigt außerdem hierarchische Instanzverkabelung, bei der d1 : Abteilung (Verkauf) verweist nach unten auf eine Unterabteilungsinstanz, die ebenfalls als Abteilung typisiert ist (name = US-Verkauf).

• Schließlich ist die Personeninstanz p (Derek) mit der US-Verkaufs-Abteilungsinstanz verbunden, während sie gleichzeitig eine Verbindung zu einer anonymen : KontaktinformationInstanz mit seiner physischen Adresse hält.

Wann sollte es verwendet werden:

• Validierung von Klassendiagramm-Entwürfen

• Debuggen komplexer Objektbeziehungen

• Demonstration von Beispiel-Laufzeitzuständen

---

🔶 Verhaltensdiagramme

Verhaltensdiagramme modellieren dynamische Aspekte – wie sich das System im Laufe der Zeit verhält.

7. Aktivitätsdiagramme

Zweck: Modellieren von Workflows, Geschäftsprozessen und algorithmischen Logiken.

Wichtige Elemente:

• Aktionen (abgerundete Rechtecke)

• Steuerknoten: Anfang, Entscheidung, Zusammenführung, Verzweigung, Verbindung, Ende

• Objektknoten und Pins

• Partitionen (Schwimmbahnen) zur Verantwortlichkeitszuweisung

• Ausnahmebehandlungen und unterbrechbare Bereiche

Beispielverwendung: Auftragsverarbeitungsablauf

Strukturelle Organisation (Schwimmbahnen und Partitionen)

Das Diagramm ist vertikal in große Spalten organisiert, die abwechselnd alsSchwimmbahnenoderPartitionen. Diese Grenzen kategorisieren die Verantwortlichkeiten für die darin enthaltenen Aktionen und ordnen Schritte bestimmten Rollen oder Geschäftseinheiten zu:

• Kundenverkaufs-Schnittstelle: Verwaltet den Kunden ausgerichteten Lebenszyklus, einschließlich der Client-Initialisierung, alternativer Routen und der endgültigen Präsentation.

• Vorschlagsinhaber: Verwaltet die zentrale Planung, die operative Analyse und die Zusammenstellung der formalen Vorschlagsdatenstrukturen.

• Angebotsinhaber: Konzentriert sich ausschließlich auf die finanzielle Bewertung und die Vorbereitung der spezifischen Angebotskennzahlen.

Steuerfluss und Aktionzustände

Die schrittweise prozedurale Ausführung wird durch Steuerknoten und gerichtete Pfade geleitet.

• Anfangsknoten: Dargestellt durch den festen schwarzen Kreis oben, markiert dies den Startpunkt des gesamten Aktivitätsablaufs.

• Aktion: Die abgerundeten Rechtecke (z. B. Kontakt initialisieren, Alternativen suchen, und Zusätzliche Informationen zusammstellen) stellen einzelne, nicht weiter zerlegbare Schritte oder Aufgaben innerhalb der Ausführungsreihenfolge dar.

• Steuerfluss: Die festen Pfeile, die die Elemente verbinden, bestimmen die sequenzielle Fortschreibung des Workflows und zeigen genau an, welche Aktion abgeschlossen sein muss, bevor die nächste beginnt.

• Aktivitätsendknoten: Das Bullseye-Symbol (ein fester Kreis innerhalb eines hohlen Ringes) am unteren Rand markiert den absoluten Endpunkt der gesamten Prozessausführung.

Routing und bewachte Logik (Entscheidungsknoten)

Diamantförmige Symbole stellen darEntscheidungsknoten, die bedingte Verzweigungen im Workflow modellieren.

• Eingehende Steuerflüsse werden aufgrund spezifischer Eingaben in mehrere sich gegenseitig ausschließende Ausgangswege aufgeteilt.

• Die Bedingungen, die bestimmen, welchen Pfad eingeschlagen wird, sind in eckigen Klammern eingeschlossen und werden als Wächterbedingungen bezeichnet (z. B. [angenommen], [abgelehnt], und [verbinden mit anderem Lieferanten oder Anforderungen ändern]). Der Prozess bewertet diese Wächter zur Laufzeit, um die Ausführung auf den entsprechenden funktionalen Pfad zu leiten.

Parallele Verarbeitung (Fork- und Join-Knoten)

Die festen schwarzen Balken im Diagramm wirken als Synchronisationspunkte zur Steuerung konkurrierender oder paralleler Ausführungsströme.

• Fork-Knoten (im Diagramm-Pfeil als Flussknoten bezeichnet): Ein einzelner eingehender Steuerfluss tritt in den Balken ein und teilt sich in mehrere unabhängige, gleichzeitige Ausführungsstränge auf. Hier teilt sich der Prozess nach der Erstellung eines Projektplans auf, um dem Angebotsverfasser die Durchführung der Analyse und der Lieferplanung zu ermöglichen, während der Angebotsverfasser gleichzeitig die Erstellung des Angebots bearbeitet.

• Join-Knoten: Ein Synchronisationsbalken, der mehrere gleichzeitige Pfade wieder in einen einzigen Steuerfluss zusammenführt. Der Prozess kann den Join-Knoten nicht passieren, bis alleeingehende parallele Ströme erfolgreich den Balken erreicht haben, um sicherzustellen, dass die Angebotszusammenstellung und die Erstellung des Angebots vollständig abgeschlossen sind, bevor mit der Zusammenstellung des endgültigen Pakets fortgefahren wird.

Datenintegration (Objektknoten)

Standardrechtecke deuten anObjektknoten, die den Datenfluss in das steuerungsorientierte Aktivitätsdiagramm einführen.

• Objektknoten stellen Instanzen spezifischer Daten oder physischer Artefakte dar, die von Aktionen erzeugt oder verbraucht werden, wobei der Instanzname : Klassenname Konvention (z. B. einVorschlag : Vorschlag und einPlan : Lieferungsprojektplan).

• Explizit markiert erstellen Pfeile zeigen genau, wann eine Aktion eine Datenstruktur instanziiert oder aktualisiert, und veranschaulichen, wie Daten von Aufgabe zu Aufgabe fließen, parallel zur operativen Ausführung.

Wann verwenden:

• Dokumentation von Geschäftsprozessen

• Modellierung von Use-Case-Realisierungen

• Spezifikation komplexer Algorithmen

---

8. Zustandsmaschinen-Diagramme (Statecharts)

Zweck: Modellieren Sie den Lebenszyklus und das zustandsabhängige Verhalten von Objekten.

Wichtige Elemente:

• Zustände (abgerundete Rechtecke mit Eintritt/Ausstieg/Tätigkeit-Aktivitäten)

• Übergänge (Auslöser[Bedingung]/Wirkung)

• Pseudozustände: Anfang, Auswahl, Verzweigung, Zusammenführung, Verlauf, Beendigung

• Verbundzustände und orthogonale Bereiche

Beispielverwendung: Telefonie-Einrichtung

Zustände und Systemzustände

Das Diagramm erfasst das Verhalten eines Systems – speziell einer Telefonie-Einrichtung –, indem es dessen verschiedene diskrete Situationen oder Zustände abbildet.

• Zustände: Die abgerundeten Rechtecke stellen Zustände dar (z. B. Ruhe, Wähltone, Wählen, Verbinden, und Verbunden). Ein Zustand stellt einen Zeitraum im Lebenszyklus eines Objekts dar, in dem es eine Bedingung erfüllt, eine Aktivität ausführt oder auf ein Ereignis wartet.

• Anfangs-Pseudozustand: Der feste schwarze Kreis ganz links stellt den Startpunkt der Zustandsmaschine dar. Es handelt sich um einen Pseudozustand, nicht um einen echten Zustand, der lediglich als Zeiger auf den Standard-Aktivzustand dient, wenn das Objekt instanziiert wird (Ruhig).

• Endzustand: Das Bullseye-Symbol ganz rechts stellt das Ende der Ausführung der Zustandsmaschine dar und zeigt an, dass das Objekt seinen Lebenszyklus abgeschlossen hat.

Übergänge und ereignisgesteuerte Routing

Die gerichteten Linien, die die Zustände verbinden, sindÜbergänge, die die Bewegung von einem Zustand zum anderen als Reaktion auf einen bestimmten Auslöser darstellen.

• Standard-Übergänge: Ausgelöst durch bestimmte Ereignisse, wie eine Benutzeraktion oder eine Systemantwort, die entlang der Linien notiert sind. Zum Beispiel erfolgt die Bewegung vonRuhig zuWähltone erfolgt, wenn dasonHook Ereignis ausgelöst wird, und die Bewegung vonWähltone zuWählen passiert, wenn eine Ziffer(n) Ereignis wird empfangen.

• Selbstübergänge: Ein Übergangspfeil, der aus einem Zustand hervorgeht und direkt wieder in denselben Zustand zurückkehrt (wie im Wählen Zustand mit dem Ziffer(n) Auslöser). Dies zeigt an, dass das Ereignis verarbeitet wird und den internen Zustandskontext aktualisiert (z. B. die neu gewählte Ziffer speichert), ohne dass das Objekt den Zustand verlässt oder seinen übergeordneten Betriebszustand ändert.

Alternative Pfade und Fehlerbehandlung

Zustandsmaschinen zeichnen sich durch die Darstellung von Verhaltenslogik und Fehlerzweigungen aus, die auf unterschiedliche Bedingungen während der Ausführung basieren.

• Erfolgreicher Ausführungsverlauf: Die zentrale horizontale Pipeline zeigt den optimalen Pfad auf: Wartezustand $rightarrow$ Wähltone $rightarrow$ Wählen $rightarrow$ Verbinden $rightarrow$ Klingeln $rightarrow$ Verbunden $rightarrow$ Getrennt.

• Ausnahmen- und Fehlerbehandlungszustände: Das System berücksichtigt Fehler oder Verzögerungen, indem es in spezielle Behandlungszustände abzweigt. Wenn eine Nummer während der Verbindung besetzt ist, löst das System den NummerBesetzt Übergang zum Betreten des Besetztton Zustand. Wenn ein Benutzer beim Wählen zu lange pausiert, wechselt ein Timeout Ereignis den System in einen Warnung oder Timeout Zustand. Wenn eine falsche Sequenz erkannt wird, leitet ein ungültigeNummer Auslöser den System in einen Aufgezeichnete Nachricht Zustand, wodurch sichergestellt wird, dass der System alle realen Randfälle sicher behandelt.

 

Wann sollte es verwendet werden:

• Modellierung eingebetteter Systeme oder Protokollimplementierungen

• Spezifizierung der UI-Zustandsverwaltung

• Dokumentation der Objekt-Lebenszyklus-Regeln

---

9. Interaktionsdiagramme

Vier Diagrammtypen betonen unterschiedliche Aspekte der Objektkooperation:

a) Ablaufdiagramme(Am häufigsten)

Zweck: Zeigt zeitlich geordnete Nachrichtenaustausche zwischen Lebenslinien an.

Wichtige Elemente:

• Lebenslinien (vertikale gestrichelte Linien)

• Nachrichten (feste/gestrichelte Pfeile mit Beschriftungen)

• Ausführungsereignisse (Aktivierungsleisten)

• Kombinierte Fragmente: alternativ, optional, Schleife, parallel, Abbruch

Beispielverwendung:

Lebenslinien und Ausführungs-Kontexte

Das Diagramm wird von links nach rechts gelesen, um die Teilnehmer festzulegen, und von oben nach unten, um den Ablauf der Zeit anzugeben.

• Lebenslinien: Die Boxen am oberen Ende, die an gestrichelten vertikalen Linien befestigt sind, stellen Lebenslinien dar. Sie modellieren einzelne Teilnehmer in der Interaktion gemäß der Instanzname : Klassenname Konvention (z. B. fenster : UI, aChain : Hotelkette, und aHotel : Hotel). Die gestrichelte Linie verfolgt die Existenz dieses Teilnehmers während der gesamten Sequenz.

• Aktivierungs-Balken: Die dünnen, farbigen vertikalen Rechtecke, die auf den Lebenslinien ruhen, deuten auf eine Aktivierung (oder Ausführungs-Ereignis) hin. Diese Balken zeigen genau an, wann ein Objekt eine Operation aktiv ausführt oder auf die Rückkehr eines verschachtelten Unter-Aufrufs wartet.

• Beendet: Das große „X“-Symbol am unteren Ende des fenster : UI Die Lebenslinie zeigt eine Zerstörung oder Beendigung an und zeigt an, dass das Lebenszyklus dieses spezifischen Teilnehmers beendet ist und dessen Ressourcen freigegeben werden.

Nachrichtentypen und Kommunikation

Die Kommunikation zwischen Teilnehmern wird über horizontale Pfeile dargestellt, die Nachrichten darstellen und sequenziell mit einem hierarchischen Nummerierungssystem (z. B. 1, 1.1, 1.1.1) geordnet sind.

• Synchronisierte Nachrichten: Vollständige Linien mit vollständigen Pfeilspitzen (wie 1: makeReservation und 1.1: makeReservation) zeigen synchrone Aufrufe an. Der Absender blockiert die Ausführung und wartet, bis das empfangende Objekt seine Verarbeitung abgeschlossen hat.

• Selbstnachrichten: Eine Nachrichtenschleife, die mit und endet auf demselben Aktivierungsstrich (z. B. 1.1.1: available(roomId, date): isRoom ausgeführt von aHotel) stellt eine Selbstnachricht. Dies zeigt eine interne Methodenausführung an, bei der ein Objekt eine seiner eigenen Operationen aufruft.

• Erstell-Nachrichten: Eine gestrichelte Linie mit einer offenen Pfeilspitze, die direkt auf ein Objekt-Feld zeigt (z. B. Nachricht 1.1.2: zeigt auf aReservation : Reservation) stellt die Objekterstellung dar. Dies zeigt an, dass die aHotel Instanz instanziiert dynamisch das aReservation Objekt genau zu diesem Zeitpunkt im Laufzeitverlauf.

Kombinierte Fragmente und Steuerfluss

Große rechteckige Felder, die Abschnitte der Sequenz umgeben, sind Kombinierte Fragmente, die Interaktionsoperatoren verwenden, um komplexe Logik, Verzweigungen und Iterationen zu steuern.

• Schleifenfragment: Das äußere Feld mit der Bezeichnung Schleife mit der Wächterbedingung [jeden Tag] stellt die Iteration dar. Alle Interaktionen innerhalb dieses Feldes werden kontinuierlich für jeden Tag wiederholt, der in der Reservierungsanfrage angegeben ist.

• Alternatives kombiniertes Fragment (Alt): Innerhalb der Schleife befindet sich ein alt Fragment (mit der Beschriftung „Wenn“ im Diagramm-Verweis), das bedingte Verzweigungen behandelt. Es bewertet die Wächterbedingung [istZimmer = wahr]. Wenn die Bedingung erfüllt ist, führt die Sequenz den spezifischen Pfad innerhalb dieses Blocks aus – wodurch die aReservation Instanz erstellt und anschließend die Nachricht 2: auslöst, um aNotice : Bestätigung. Wenn die Bedingung falsch wäre, würde ein alternativer Pfad (oder keine Aktion) ausgeführt werden.

  

b) Kommunikationsdiagramme

Zweck: Betonen Sie Objektbeziehungen gegenüber der Nachrichtenzeit.

Wichtige Elemente:

• Objekte als Knoten

• Verbindungen mit nummerierten, gerichteten Nachrichten

• Fokus auf „wer mit wem spricht“

c) Interaktionsübersichtsdiagramme

Zweck: Hochlevel-Steuerfluss mit Aktivitätsdiagramm-Notation.

Wichtige Elemente:

• Interaktionsvorkommen als Aktivitätsknoten

• Entscheidung/Verzweigung für Verzweigungen

• Fork/Join für Parallelität

d) Zeitdiagramme

Zweck: Modellieren präziser Zeitbeschränkungen (Echtzeit-Systeme).

Wichtige Elemente:

• Zustandszeitachsen für jede Lebenslinie

• Zeitskalen und Beschränkungen

• Nachrichtenpfeile mit Dauermarkern

Wann Interaktionen verwendet werden sollten:

• Spezifizieren von Use-Case-Realisierungen

• Debuggen komplexer Nachrichtenflüsse

• Dokumentieren von API-Nutzungsmustern

• Modellieren der Zeitgestaltung von Echtzeitprotokollen

---

10. Use-Case-Diagramme

Zweck: Erfassen funktionaler Anforderungen aus der Perspektive eines externen Akteurs.

Wichtige Elemente:

• Use-Cases (Ovale oder Klassifizierungsrechtecke)

• Akteure (Stabfiguren oder Klassifizierer)

• Assoziationen (Akteur ↔ Use-Case)

• Beziehungen: «include», «erweitern», Verallgemeinerung

• Systemgrenzbox

Beispielverwendung: Geldautomatensystem

Wann es verwendet wird:

• Anforderungserhebung mit Stakeholdern

• Definition des Systemumfangs und der Grenzen

• Planung von Test-Szenarien

---

🎯 Die richtige Diagrammart wählen: Entscheidungshilfe

Ziel	Empfohlenes Diagramm(e)
Entwurf der Klassenstruktur	Klasse, Objekt, Paket
Modellierung von Laufzeitinteraktionen	Sequenz, Kommunikation
Dokumentation von Geschäftsabläufen	Aktivität, Use Case
Spezifikation des Objekt-Lebenszyklus	Zustandsmaschine
Planung der Systembereitstellung	Bereitstellung, Komponente
Modellierung komplexer interner Muster	Komposite Struktur
Erfassung von Echtzeit-Beschränkungen	Zeitdiagramm
Definition von Anforderungen	Use Case, Aktivität

---

🔑 Schlüsselprinzipien der Modellierung

1. Beginne einfach: Beginne mit dem Diagrammtyp, der deinem unmittelbaren Ziel am besten entspricht.

2. Iteriere: Verfeinere Modelle, je tiefer dein Verständnis wird – kein Diagramm ist bei der ersten Entwurf „endgültig“.

3. Das Publikum ist wichtig: Passe das Detailniveau an die Leser an (Entwickler gegenüber Stakeholdern).

4. Kombiniere Ansichten: Verwende mehrere Diagramme, um eine vollständige Geschichte zu erzählen (z. B. Use Case → Sequenz → Klasse).

5. Erweitere sorgfältig: Verwende Stereotypen, markierte Werte und Profile für fachspezifische Anforderungen – dokumentiere aber die Konventionen.

6. Halte es lesbar: Lasse unwichtige Details weg; verwende Notizen für ergänzende Kontextinformationen.

📌 Denke daran: „UML ist eine Sprache, keine Methodik.“ Es bietet Notation – nicht Prozess. Wähle Diagramme, die die Kommunikation klären, nicht solche, die Kästchen abhaken.

Fazit

Der Artikel ist auch in English, Español, فارسی, Français, English, Bahasa Indonesia, 日本語, Polski and Portuguese verfügbar.