1. Zweck eines UML-Bereitstellungsdiagramms
Ein Bereitstellungsdiagramm zeigt die physische/Laufzeit-Architektur eines Systems:
- Hardware-Knoten (Server, Geräte, Cloud-Instanzen)
- Software-Artifakte, die auf diesen Knoten bereitgestellt sind
- Ausführungs-Umgebungen (Container, Laufzeiten)
- Kommunikationspfade zwischen Knoten (Protokolle, Verbindungen)
Für ein einfaches Online-Food-Bestell-System, visualisiert es, wie:
- Kunden- und Restaurant-Web-Oberflächen bereitgestellt werden
- Geschäftslogik ausgeführt wird
- Daten gespeichert werden
- Externe Dienste (Zahlungen, Benachrichtigungen) integriert werden
Es hilft Entwicklern, DevOps und Stakeholdern, zu verstehenBereitstellungs-Topologie, Skalierungspunkte, Sicherheitsgrenzen und Abhängigkeiten.
2. Wichtige UML-Elemente in Bereitstellungsdiagrammen
| Element | UML-Notation (PlantUML) | Bedeutung / Wann es zu verwenden ist | Stereotyp-Beispiele |
|---|---|---|---|
| Knoten | node „Name“ | Rechenressource (physisch oder virtuell), die Artefakte hosten kann | <<Gerät>>, <<Cloud>> |
| Gerät | Knoten „Name“ <<device>> | Physisches oder virtuelles Hardware (Server, Mobilgerät, Router) | <<device>>, <<server>> |
| Ausführungs-Umgebung | Knoten „Name“ <<executionEnvironment>> | Software-Laufzeitumgebung/Container (Tomcat, Node.js, Docker, JVM) | <<executionEnvironment>>, <<container>> |
| Artefakt | Artikel „filename.war“ | Bereitstellbare Einheit (ausführbare Datei, .jar, .js-Bündel, Datenbank-Schema, Konfigurationsdatei) | <<executable>>, <<file>>, <<database>> |
| Komponente | Komponente „Name“ | Logische Software-Einheit (optional in Bereitstellungsdigrammen; oft durch Artefakte realisiert) | <<web>>, <<service>> |
| Kommunikationspfad | –, –>, ..> | Netzwerkverbindung zwischen Knoten (kann Protokollbezeichnung haben) | HTTP/HTTPS, WebSocket, RMI |
| Abhängigkeit / Aufruf | ..>, –> | Verwendung/Abhängigkeit (z. B. Frontend ruft Backend auf) | <<calls>>, <<accesses>> |
| Manifestation / Realisierung | ..> mit <<realizes>> oder ..> | Artikel realisiert / wird als Komponente bereitgestellt | <<realizes>>, <<manifest>> |
| Externes System | Knoten „Name“ <<external>> | Dienstleistung von Drittanbietern außerhalb Ihrer Kontrolle | <<extern>>, <<SaaS>> |
3. Best Practices für Bereitstellungsdiagramme (insbesondere für Web-Systeme)
- Halten Sie es einfach und lesbar — vermeiden Sie Überfüllung; ein Diagramm pro Hauptumgebung (Entwicklung/Staging/Produktion optional)
- Verwenden Sie sinnvolle Knotengruppierung (verschachtelte Knoten innerhalb von Knoten) zur Darstellung von Clustern/Cloud-Bereichen
- Bevorzugen Sie präzise Notation — zeigen Sie Dateinamen/Konfigurationen nur, wenn relevant; lassen Sie überflüssige Stereotypen weg
- Zeigen Sie deutlich Grenzen — interne Cloud vs externe Dienste
- Kennzeichnen Sie Protokolle auf Pfaden (HTTP/HTTPS, WebSocket, TCP usw.)
- Verwenden Sie Richtung von links nach rechts für Web-Systeme (der Ablauf von Client → Server → Datenbank wirkt natürlich)
- Unterscheiden Sie Gerät (Hardware) vs Ausführungs-Umgebung (Laufzeit)
- Zeigen Sie Realisierung nur, wenn es Wert hinzufügt (Artifakt → Komponente)
- Verwenden Sie skinparam in PlantUML für bessere Farben/Lesbarkeit
- Für kleine/mittelgroße Systeme: maximal 4–8 Knoten
4. Empfohlene Struktur für ein einfaches Online-Food-Bestell-System
Eine saubere, moderne Anordnung für dieses System:
- Client-Seite → Browser (implizit) spricht mit Web-Server/CDN
- Web-Server/CDN hostet statische + SPA-Artefakte für die Kunden-Website und das Restaurant-Panel
- API-Server (Ausführungs-Umgebung) führt Backend-Logik aus
- Datenbank-Server hostet PostgreSQL
- Extern Zahlungs- und Benachrichtigungsdienste
Typische Knoten:
- Web-Server / CDN <<device>>
- API-Server <<executionEnvironment>>
- Datenbank-Server <<executionEnvironment>>
- Zahlungsgateway <<external>>
- Benachrichtigungsdienst <<external>>
5. Diagramm generiert durch Visual Paradigm AI Chatbot
Verbesserter und aufgeräumter PlantUML-Code (mit Erklärungen)
@startuml
title Einfaches Online-Food-Bestell-System – Bereitstellungsdiagramm
Richtung von links nach rechts
skinparam {
ArrowColor #424242
ArrowFontColor #424242
StandardSchriftgröße 14
Schattenwurf false
stereotypeC Hintergrundfarbe #ADD1B2
stereotypeI Hintergrundfarbe #ADD1B2
}
‘ ── Knoten ────────────────────────────────────────────────
knoten „Webserver / CDN“ <<gerät>> als WebServer {
[Kunden-Website HTML/JS/CSS] #..# (Kunden-SPA)
[Restaurant-Admin-Panel HTML/JS/CSS] #..# (Restaurant-SPA)
}
knoten „Cloud-Backend“ <<gerät>> als Cloud {
knoten „API-Server“ <<Ausführungs-Umgebung>> als APIServer {
Artikel „backend-api.jar / main.exe“ als BackendArtikel
}
knoten „PostgreSQL-Server“ <<Ausführungs-Umgebung>> als DBServer {
datenbank „PostgreSQL-Datenbank“ als Postgres <<datenbank>>
}
}
knoten „Zahlungs-Gateway“ <<extern>> als Zahlung {
[Zahlungs-API] als ZahlungsAPI
}
knoten „Benachrichtigungsdienst“ <<extern>> als Benachrichtigung {
[WebSocket / Push-API] als BenachrichtigungsAPI
}
‘ ── Beziehungen ─────────────────────────────────────────
WebServer –> Cloud : HTTPS (API-Aufrufe)
Cloud –> Zahlung : HTTPS (Bezahlvorgang)
Cloud –> Benachrichtigung : WebSocket / HTTPS (Statusaktualisierungen)
‘ Artikel → Komponenten-Realisierung (optional, aber klar)
(Kunden-SPA) ..> BackendArtikel : <<aufruft>>
(Restaurant SPA) ..> BackendArtifact : <<aufruft>>
BackendArtifact –> Postgres : <<JDBC / SQL>>
BackendArtifact –> PaymentAPI : <<HTTPS-Aufrufe>>
BackendArtifact –> NotifyAPI : <<WebSocket / HTTPS>>
‘ Optional: Protokoll auf DB anzeigen, falls gewünscht
‘ BackendArtifact -rechts-> Postgres : <<JDBC>>
notiz rechts von Cloud
Typische kleine/mittelgroße Einrichtung:
• Einzelne VM oder kleiner Cluster
• API + DB können auf derselben Maschine laufen (zur Vereinfachung)
oder getrennt für bessere Skalierbarkeit
ende notiz
@enduml
6. Schritt-für-Schritt: So erstellen Sie Ihr eigenes Bereitstellungsdiagramm
- Liste alle Ausführungsziele (Server, Container, externe Dienste)
- Liste bereitstellbarer Artefakte (was tatsächlich läuft: .js-Bündel, .jar, Datenbank)
- Gruppieren in Knoten (verschachteln, wenn sinnvoll — z. B. API + DB in einem Cloud-Knoten)
- Entscheiden Sie die Richtung (links nach rechts funktioniert gut für Web → API → DB)
- Kommunikationspfade hinzufügen mit Protokollbeschriftungen
- Wichtige Abhängigkeiten hinzufügen (<<aufruft>>, <<zugreift>>)
- skinparam anwenden für Farben/Lesbarkeit
- Notizen hinzufügen für wichtige Entscheidungen (Einzel- vs Mehrfachinstanz, Skalierungsnotizen)
- Validieren: Kann ein DevOps-Ingenieur verstehen, wo jedes einzelne Element bereitgestellt werden soll?
Zusammenfassung – Schnellreferenz für die Bereitstellung einer einfachen Bestellungsanwendung für Lebensmittel
| Teil | Typischer Knotentyp | Artifakt-Beispiel | Verbindet über |
|---|---|---|---|
| Kunden-UI | Webserver / CDN <<Gerät>> | SPA-Bündel (HTML/JS) | HTTPS → API |
| Restaurant-Dashboard | Webserver / CDN <<Gerät>> | Admin-SPA-Bündel | HTTPS → API |
| Geschäftslogik | API-Server <<Ausführungsumgebung>> | backend-api.jar / ausführbare Datei | JDBC → DB, HTTPS → extern |
| Datenbank | PostgreSQL <<Ausführungsumgebung>> | PostgreSQL-Datendateien + Schema | — |
| Zahlungen | Extern <<SaaS>> | Zahlungs-API-Endpunkt | HTTPS |
| Echtzeit-Updates | Extern <<SaaS>> | WebSocket / FCM / APNs | WebSocket / HTTPS |
Diese Struktur ist realistisch für MVP- oder kleiner bis mittelgroße Bereitstellungen (1–3 Server + Cloud-Datenbank + Stripe/PayPal + Firebase/Pusher).
Fühlen Sie sich frei, die Verschachtelung, Protokolle anzupassen oder Skalierungsnotizen hinzuzufügen (z. B. Lastverteilung, Replikate), wenn das System wächst.
🔗 Referenzliste (Markdown-Format)
- AI-Diagramm-Generator – Visual Paradigm: Offizielle Versionshinweise, die die Einführung und Funktionen des AI-Diagramm-Generators von Visual Paradigm beschreiben, einschließlich Text-zu-UML-Funktionen für Zustandsdiagramme.
- UML-Zustandsdiagramme in Sekunden mit KI erstellen – Visual Paradigm: Ein Schritt-für-Schritt-Leitfaden, der zeigt, wie UML-Zustandsdiagramme aus einfachem Text mit KI erstellt werden, inklusive realen Beispielen und Anwendungsfällen.
- Was ist ein Zustandsmaschinen-Diagramm? – Visual Paradigm: Ein grundlegendes Artikel, der Zweck, Struktur und bewährte Praktiken für UML-Zustandsmaschinen-Diagramme erklärt.
- Beherrschen von Zustandsdiagrammen mit Visual Paradigm AI – Cybermedian: Ein praktischer Leitfaden, der zeigt, wie KI-optimierte Zustandsdiagramme in realen Systemen wie automatisierten Mautsystemen eingesetzt werden.
- Umfassende Bewertung: Die KI-Diagrammerstellung von Visual Paradigm: Eine detaillierte Bewertung der Genauigkeit, Benutzerfreundlichkeit und Integration des AI-Diagramm-Generators in Entwicklungsabläufe.
- KI-Chatbot – Visual Paradigm: Übersicht über den KI-Assistenten, der die konversationelle Bearbeitung von UML-Diagrammen, einschließlich Zustandsdiagrammen, ermöglicht.
- OpenDocs-Update: AI-Zustandsdiagramm-Generator – Visual Paradigm: Ankündigung der verbesserten Dokumentationsintegration, die es ermöglicht, Zustandsdiagramme in technischen Dokumentationen einzubetten und zu synchronisieren.
- Visual Paradigm AI-Zustandsdiagramm-Tutorial – YouTube: Ein Videotutorial, das zeigt, wie der AI-Diagramm-Generator verwendet wird, um ein Zustandsdiagramm für einen E-Commerce-Bestellprozess zu erstellen.
- Über Zustandsdiagramme – Visual Paradigm: Eine umfassende Übersicht über UML-Zustandsdiagramme, einschließlich ihrer Komponenten, Syntax und realer Anwendungen.
- Erstellen von Zustandsdiagrammen – Visual Paradigm Benutzerhandbuch: Detaillierte Schritt-für-Schritt-Anleitungen zum Erstellen von Zustandsdiagrammen, einschließlich zusammengesetzter Zustände und Wächterbedingungen.
- Erweiterte Zustandsmaschinen-Funktionen – Visual Paradigm: Ein tiefgehender Einblick in erweiterte Modellierungstechniken mit Visual Paradigm, einschließlich verschachtelter Zustände, orthogonaler Bereiche und Ereignisbehandlung.
- Mit vorheriger Version vergleichen – Visual Paradigm Benutzerhandbuch: Dokumentation zur Änderungsvergleichsfunktion, die Teams ermöglicht, Änderungen an Zustandsdiagrammen im Laufe der Zeit zu verfolgen und zu verwalten.
