UML-Bereitstellungsdia­gramm: Abbildung von Software auf Infrastruktur

Während Komponentendiagramme konzentrieren sich auf die logische Organisation Ihrer Code-Module, das UML-Bereitstellungsdia­gramm schließt die Lücke zur Realität. Es beantwortet die entscheidende Frage: „Wo lebt all dieser Code eigentlich?“

Dieses Diagramm ist das einzige UML-Modell, das sich ausschließlich der physischen Laufzeitumgebung widmet. Es visualisiert die Zuordnung von Softwareartefakten zu Hardwarezielen und zeigt auf, wie die Komponenten des Systems auf Servern, Datenbanken, mobilen Geräten und Cloud-Infrastruktur verteilt sind. In der Ära des Cloud-Computings, der Mikrodienste und des IoT ist das Verständnis dieser physischen Architektur wichtiger denn je.

Die Anatomie der physischen Architektur

Das primäre Ziel eines Bereitstellungsdia­gramms besteht darin, die physische Topologie des Systems darzustellen – die Hardware (Knoten) und die Software (Artefakte), die darauf ausgeführt wird.

1. Knoten: Die Hardware und Ausführungs­umgebungen

Der grundlegende Baustein eines Bereitstellungsdia­gramms ist der Knoten. Knoten stellen rechnerische Ressourcen dar, auf denen Artefakte zur Ausführung bereitgestellt werden. Sie werden als 3D-Boxen (Würfel) dargestellt.

Knoten gibt es in zwei Hauptvarianten:

• Geräteknoten: Diese stellen physische Hardware-Ressourcen mit Verarbeitungskapazität dar.

  • Beispiele: Ein Anwendungsserver, ein Datenbankserver, ein Mobiltelefon, ein IoT-Sensor oder ein Lastverteilungs­gerät.

• Ausführungs­umgebungsknoten (Ausführungs­umgebungen): Diese sind softwarebasierte Container, die innerhalb eines Geräteknotens ausgeführt werden und bestimmte Arten von Artefakten hosten. Sie stellen die Softwareebene dar, die die bereitgestellten Komponenten verwaltet.

  • Beispiele: Ein Java-Virtual-Machine (JVM), ein .NET-CLR, ein Docker-Container oder eine Web-Browser-Instanz.

2. Artefakte: Die bereitstellbare Software

Ein Artefakt stellt die konkrete physische Manifestation einer Softwarekomponente dar. Während ein „Komponente“ eine logische Gruppierung von Klassen ist, ist ein „Artefakt“ die tatsächliche Datei, die auf dem Server installiert wird.

Artefakte werden typischerweise als Rechteck mit dem Schlüsselwort «Artefakt» oder einem kleinen Dokument-Symbol in der Ecke. Sie werden oft innerhalb des Knotens platziert, um anzuzeigen, wo sie bereitgestellt werden.

• Beispiele: user-service.jar, index.html, database-schema.sql, config.xml, oder payment-api.exe.

3. Kommunikationspfade: Die Verbindungen

Knoten arbeiten selten isoliert.Kommunikationspfade stellen die physischen Verbindungen oder Assoziationen zwischen Knoten dar und zeigen, wie sie Informationen austauschen.

Sie werden als feste Linien gezeichnet, die zwei Knoten verbinden. Entscheidend ist, dass sie häufig mit Stereotypen beschriftet sind, um das verwendete Kommunikationsprotokoll oder Netzwerktyp anzugeben.

• Beispiele: «HTTP/HTTPS», «TCP/IP», «JDBC», «RMI», oder «Nachrichtenwarteschlange».

Visualisierung der Topologie

Ein typisches Bereitstellungsdigramm erzählt eine Geschichte über die Laufzeitstruktur des Systems. Zum Beispiel könnte eine Standard-Three-Tier-Webanwendung wie folgt visualisiert werden:

1. Client-Ebene: Ein Mobilgerät (Knoten), der ein Mobil-App (Artefakt).

2. Mittel-Ebene: Ein Web-Server (Geräteknoten), der ein Docker-Container (Ausführungs-Umgebung), die innerhalb das API-Service.jar (Artefakt).

3. Daten-Ebene: Ein Datenbank-Server (Geräteknoten), der ein PostgreSQL Instanz (Ausführungs-Umgebung), die das Benutzerdaten (Artefakt).

Die Verbindung dieser Knoten würde Linien mit der Beschriftung «HTTPS» (zwischen Mobilgerät und Web-Server) und «JDBC» (zwischen Web-Server und Datenbank).

Warum sollte man ein Bereitstellungsdigramm verwenden?

Bereitstellungsdigramme sind für DevOps-Engineer, Systemarchitekten und Netzwerkadministratoren unverzichtbar.

• Bereitstellungsplanung: Sie dienen als definitive Karte für das Release-Management und zeigen genau, welche Dateien auf welche Server gelangen müssen.

• Leistungsanalyse: Durch die Visualisierung der Verteilung der Verarbeitung und der Netzwerkverbindungen können Architekten potenzielle Engpässe identifizieren (z. B. zu viele Artefakte auf einem einzelnen leistungsschwachen Knoten oder langsame Netzwerkverbindungen zwischen kommunikativen Diensten).

• Sicherheitsmodellierung: Sie helfen dabei, Sicherheitsrisiken zu identifizieren, indem sie hervorheben, welche Knoten externen Netzwerken (öffent hettes Internet) ausgesetzt sind und welche hinter Firewalls isoliert sind.

• Infrastruktur als Code (IaC) Design: In der modernen DevOps-Praxis liefern diese Diagramme die konzeptionelle Grundlage für die Erstellung von Terraform- oder CloudFormation-Skripten zur Bereitstellung von Cloud-Ressourcen.

Für weitere Informationen zu UML und künstlicher Intelligenz unterstützter Visualisierung, siehe unsereUML-Ressourcen-Hub.

Der Artikel ist auch in English, Español, فارسی, Bahasa Indonesia, Portuguese, Việt Nam, 简体中文 and 繁體中文 verfügbar.