Posted inAI AI Chatbot UML

Ein umfassender Leitfaden zum Erstellen eines UML-Bereitstellungsdiagramms für das einfache Online-Food-Bestell-System

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 Bereitstellungsdiagrammen; 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 Client → Server → DB 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:

  1. Web-Server / CDN <<device>>
  2. API-Server <<executionEnvironment>>
  3. Datenbank-Server <<executionEnvironment>>
  4. Zahlungsgateway <<external>>
  5. Benachrichtigungsdienst <<external>>

5. Diagramm generiert durch den Visual Paradigm AI Chatbot

Verbesserter und aufgeräumter PlantUML-Code (mit Erklärungen)

Plantuml


Plantuml in VPasCode bearbeiten
Plantuml Edit Plantuml in VPasCode 
@startuml

title Einfaches Online-Food-Bestell-System - Bereitstellungsdiagramm

links nach rechts Richtung

skinparam {
Pfeilfarbe #424242
Pfeil-Schriftfarbe #424242
StandardSchriftgröße 14
Schattenbildung false
StereotypC-Hintergrundfarbe #ADD1B2
StereotypI-Hintergrundfarbe #ADD1B2
}

' ── Knoten ────────────────────────────────────────────────

knoten "Web-Server / CDN" <<device>> als WebServer {
[Website des Kunden HTML/JS/CSS] #..# (Kunden-SPA)
[Admin-Panel für Restaurant HTML/JS/CSS] #..# (Restaurant-SPA)
}

knoten "Cloud-Backend" <<device>> als Cloud {
knoten "API-Server" <<Ausführungs-Umgebung>> als APIServer {
Artefakt "backend-api.jar / main.exe" als BackendArtikel
}

knoten "PostgreSQL-Server" <<Ausführungs-Umgebung>> als DBServer {
datenbank "PostgreSQL-Datenbank" als Postgres <<datenbank>>
}
}

knoten "Zahlungsgateway" <<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 (Status-Updates)

' Artefakt → Komponenten-Realisierung (optional, aber klar)
(Kunden-SPA) ..> BackendArtikel : <<ruft auf>>
(Restaurant-SPA) ..> BackendArtikel : <<ruft auf>>

BackendArtikel --> Postgres : <<JDBC / SQL>>

BackendArtikel --> ZahlungsAPI : <<HTTPS-Aufrufe>>

BackendArtikel --> BenachrichtigungsAPI : <<WebSocket / HTTPS>>

' Optional: Protokoll auf DB anzeigen, falls gewünscht
' BackendArtikel -rechts-> Postgres : <<JDBC>>

notiz rechts von Cloud
Typische kleine/mittelgroße Einrichtung:
• Einzelne VM oder kleiner Cluster
• API + DB können auf derselben Maschine liegen (für Einfachheit)
oder getrennt für bessere Skalierung
ende notiz

@enduml
Edit Plantuml in VPasCode



Plantuml in VPasCode bearbeiten

6. Schritt-für-Schritt: So erstellen Sie Ihr eigenes Bereitstellungsdiagramm

  1. Alle Ausführungsziele auflisten (Server, Container, externe Dienste)
  2. Liste der bereitstellbaren Artefakte (was tatsächlich läuft: .js-Bündel, .jar, Datenbank)
  3. Gruppieren nach Knoten (verschachteln, wenn sinnvoll — z. B. API + DB in einem Cloud-Knoten)
  4. Richtung festlegen (links nach rechts funktioniert gut für Web → API → DB)
  5. Kommunikationspfade hinzufügen mit Protokollbeschriftungen
  6. Wichtige Abhängigkeiten hinzufügen (<<ruft auf>>, <<greift zu>>)
  7. Skinparam anwenden für Farben/Lesbarkeit
  8. Hinweise hinzufügen für wichtige Entscheidungen (Einzel- vs Mehrfachinstanz, Skalierungsnotizen)
  9. Validieren: Kann ein DevOps-Ingenieur verstehen, wo jedes Stück bereitgestellt werden soll?

Zusammenfassung – Kurzreferenz für die Bereitstellung einer einfachen Food-Ordering-Lösung

Teil Typischer Knotentyp Beispiel für Artefakt Verbindet sich ü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 <<executionEnv>> backend-api.jar / ausführbare Datei JDBC → DB, HTTPS → extern
Datenbank PostgreSQL <<executionEnv>> 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