\n
![\"UML-Klassendiagramm-Cheat-Sheet\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195e127973c.png\")
<\/p>\n
Teil 1: Die Bausteine (Syntax & Legende)<\/h2>\n
Bevor wir in die Fallstudie eintauchen, m\u00fcssen wir die in UML-Diagrammen verwendete Fachsprache festlegen.<\/p>\n
1. Klassenstruktur & Sichtbarkeit<\/h3>\n
Eine Klasse wird durch ein Rechteck dargestellt, das in drei Bereiche unterteilt ist:<\/p>\n
- \n
- \n
Oben:<\/strong>\u00a0Klassenname (z. B.
FlightBooking<\/code>).<\/p>\n<\/li>\n- \n
Mitte:<\/strong>\u00a0Eigenschaften\/Attribute (z. B.
+ nameProperty: String<\/code>).<\/p>\n<\/li>\n- \n
Unten:<\/strong>\u00a0Methoden\/Operationen (z. B.
+ isActive(): boolean<\/code>).<\/p>\n<\/li>\n<\/ul>\nSichtbarkeitsmodifikatoren:<\/strong><\/p>\n
- \n
- \n
+<\/code>\u00a0\u00d6ffentlich:<\/strong>\u00a0Zug\u00e4nglich f\u00fcr jede andere Klasse.<\/p>\n<\/li>\n- \n
-<\/code>\u00a0Privat:<\/strong>\u00a0Nur innerhalb der Klasse zug\u00e4nglich.<\/p>\n<\/li>\n- \n
#<\/code>\u00a0Gesch\u00fctzt:<\/strong>\u00a0Innerhalb der Klasse und ihrer Unterklassen zug\u00e4nglich.<\/p>\n<\/li>\n- \n
~<\/code>\u00a0Paket:<\/strong>\u00a0Nur innerhalb desselben Pakets zug\u00e4nglich.<\/p>\n<\/li>\n<\/ul>\n2. Spezielle Klassentypen<\/h3>\n
- \n
- \n
Schnittstellen (
<<interface>><\/code>):<\/strong>\u00a0Vertr\u00e4ge, die Methoden ohne Implementierung definieren. Dargestellt durch eine gr\u00fcne Box (in diesem Spickzettel) oder Standardnotation.<\/p>\n- \n
- \n
Beispiel:<\/em>\u00a0
UserRepo<\/code>\u00a0mit\u00a0+ method(): void<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Abstrakte Klassen (
<<abstract>><\/code>):<\/strong>\u00a0Basis-Klassen, die nicht direkt instanziiert werden k\u00f6nnen. Sie k\u00f6nnen abstrakte Methoden enthalten.<\/p>\n- \n
- \n
Beispiel:<\/em>\u00a0
Component<\/code>\u00a0mit\u00a0+ render(): void \/\/ abstract<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Aufz\u00e4hlungen:<\/strong>\u00a0Eine Menge benannter Konstanten.<\/p>\n
- \n
- \n
Beispiel:<\/em>\u00a0
JobStatus<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nBeispiel f\u00fcr ein Klassendiagramm eines Bestellsystems<\/h2>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195f79a1fa7.png\")
<\/p>\n\u00a0<\/p>\n
@startuml
\nskinparam classAttributeIconSize 0
\nskinparam shadowing false<\/p>\n\u2018 \u2014 Schnittstellen \u2014
\ninterface PaymentGateway {
\n+ process(amount: double): boolean
\n}<\/p>\n\u2018 \u2014 Abstrakte Klassen \u2014
\nabstract class Order {
\n# orderId: String
\n# totalAmount: double
\n+ {abstract} calculateTax(): double
\n+ getSummary(): String
\n}<\/p>\n\u2018 \u2014 Klassen \u2014
\nclass PhysicalOrder {
\n\u2013 shippingWeight: double
\n+ calculateTax(): double
\n}<\/p>\nclass DigitalOrder {
\n\u2013 downloadLink: String
\n+ calculateTax(): double
\n}<\/p>\nclass OrderItem {
\n\u2013 productName: String
\n\u2013 price: double
\n\u2013 quantity: int
\n}<\/p>\nclass PayPalGateway {
\n+ process(amount: double): boolean
\n}<\/p>\n\u2018 \u2014 BEZIEHUNGEN \u2014”
nOrder <|\u2013 PhysischeBestellung
nOrder <|\u2013 DigitaleBestellung<\/p>\nOrder *\u2013 \u201e1..*\u201c OrderItem : enth\u00e4lt
nOrder ..> PaymentGateway : verwendet<\/p>\nPaymentGateway <|.. PayPalGateway<\/p>\n
@enduml<\/p>\n
\nTeil 2: Beziehungen & Multiplizit\u00e4t<\/h2>\n
Die Linien, die Klassen verbinden, definieren, wie sie interagieren.<\/p>\n
1. Assoziationsarten<\/h3>\n
- \n
- \n
Vererbung (Verallgemeinerung):<\/strong>\u00a0Durchgezogene Linie mit einem hohlen Dreieck. \u201eIst-eine\u201c-Beziehung.<\/p>\n
- \n
- \n
Beispiel:<\/em>\u00a0
Auto<\/code>\u00a0und\u00a0Motorrad<\/code>\u00a0erben von\u00a0Fahrzeug<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Implementierung:<\/strong>\u00a0Gestrichelte Linie mit einem hohlen Dreieck. Eine Klasse erf\u00fcllt einen Schnittstellenvertrag.<\/p>\n
- \n
- \n
Beispiel:<\/em>\u00a0
Auto<\/code>\u00a0implementiert\u00a0Fahrbar<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Komposition (starke Ownership):<\/strong>\u00a0Durchgezogene Linie mit einem\u00a0gef\u00fcllten Diamanten<\/strong>. Das \u201eTeil\u201c kann nicht ohne das \u201eGanze\u201c existieren.<\/p>\n
- \n
- \n
Beispiel:<\/em>\u00a0
Restaurant<\/code> (Ganzes) besitztSpeisekarte<\/code> (Teil). Wenn das Restaurant schlie\u00dft, ist die Speisekarte weg.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Aggregation:<\/strong> Durchgezogene Linie mit einem hohlen Diamanten<\/strong>. Eine \u201ehat-ein\u201c-Beziehung, bei der Teile unabh\u00e4ngig existieren k\u00f6nnen.<\/p>\n
- \n
- \n
Beispiel:<\/em>\u00a0
Bestellung<\/code> aggregiertRestaurant<\/code> (Das Restaurant existiert auch, wenn die Bestellung gel\u00f6scht wird).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n2. Legende zur Multiplizit\u00e4t<\/h3>\n
Zahlen an den Enden der Linien geben die Kardinalit\u00e4t an:<\/p>\n
- \n
- \n
1<\/code>: Genau eines.<\/p>\n<\/li>\n- \n
0..1<\/code>: Null oder eins (Optional).<\/p>\n<\/li>\n- \n
1..*<\/code>: Eins oder mehr (Verpflichtende Liste).<\/p>\n<\/li>\n- \n
*<\/code>: Viele (Null oder mehr).<\/p>\n<\/li>\n<\/ul>\nDie Konzepte Vererbung, Implementierung, Komposition und Aggregation \u2013 Beispiel<\/h3>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a19600180d6b.png\")
<\/p>\n\n@startuml<\/div>\n\u2018 Schnittstellen und Basisklassen<\/div>\ninterface Drivable {<\/div>\n+ drive()<\/div>\n}<\/div>\nabstrakte Klasse Vehicle {<\/div>\n+ startEngine()<\/div>\n}<\/div>\n\u2018 Klassen<\/div>\nclass Car {<\/div>\n}<\/div>\nclass Motorcycle {<\/div>\n}<\/div>\nclass Restaurant {<\/div>\n\u2013 name: String<\/div>\n}<\/div>\nclass Menu {<\/div>\n}<\/div>\nclass Order {<\/div>\n}<\/div>\n\u2018 Beziehungen<\/div>\n\u2018 1. Vererbung (Verallgemeinerung)<\/div>\nVehicle <|\u2013 Car<\/div>\nVehicle <|\u2013 Motorcycle<\/div>\n\u2018 2. Implementierung<\/div>\nDrivable <|.. Car<\/div>\n\u2018 3. Komposition (starke Ownership)<\/div>\nRestaurant *\u2013 Menu : besitzt<\/div>\n\u2018 4. Aggregation<\/div>\nOrder o\u2013 Restaurant : beinhaltet<\/div>\n\u2018 Multiplizit\u00e4tsbeispiele<\/div>\n\u2018 Restaurant hat ein oder viele Men\u00fcs (1..*)<\/div>\n\u2018 Order beinhaltet null oder ein Restaurant (0..1)<\/div>\nRestaurant \u201e1\u201c *\u2013 \u201e1..*\u201c Menu<\/div>\nBestellung “1” o\u2013 “0..1” Restaurant<\/div>\n@enduml<\/div>\n<\/div>\n
\nTeil 3: Praxisfallstudie: Einheitliche Essenslieferplattform<\/h2>\n
Dieser Abschnitt analysiert das zentrale Diagramm aus dem Spickzettel und zerlegt die Architektur einer Essenslieferanwendung.<\/p>\n
1. Die Benutzerhierarchie (Vererbung & Komposition)<\/h3>\n
Das System beginnt mit einer generischen Benutzer<\/strong> Klasse, markiert als Abstrakt<\/strong>. Dies stellt sicher, dass keine generischen “Benutzer”-Objekte erstellt werden, sondern nur spezifische Typen.<\/p>\n
- \n
- \n
Vererbung:<\/strong>\u00a0
Kunde<\/code> undFahrer<\/code> erweiternBenutzer<\/code>.<\/p>\n<\/li>\n- \n
Komposition:<\/strong><\/p>\n
- \n
- \n
Kunde<\/code> hat eineLieferadresse<\/code> (Starke Ownership).<\/p>\n<\/li>\n- \n
Fahrer<\/code> hatFahrzeugdetails<\/code> (Starke Ownership).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n2. Das Restaurant- und Men\u00fc-\u00d6kosystem<\/h3>\n
Dieser Abschnitt zeigt tief verschachtelte Strukturen und Sammlungen.<\/p>\n
- \n
- \n
Schnittstellenimplementierung:<\/strong>\u00a0
Restaurant<\/code> implementiert<<interface>> Lokalisierbar<\/code>, wodurch sichergestellt wird, dass jedes Restaurant \u00fcber Standortdaten verf\u00fcgt.<\/p>\n<\/li>\n- \n
Kompositions-Kette:<\/strong><\/p>\n
- \n
- \n
Restaurant<\/code> (1) besitzt starkSpeisekarte<\/code>\u00a0(1).<\/p>\n<\/li>\n- \n
Speisekarte<\/code> enth\u00e4ltSpeisenkategorie<\/code>\u00a0(1..*).<\/p>\n<\/li>\n- \n
Speisenkategorie<\/code> enth\u00e4ltSpeisenartikel<\/code>\u00a0(*).<\/p>\n<\/li>\n- \n
Hinweis:<\/em> Diese Struktur stellt sicher, dass ein Speisenartikel nicht ohne eine Kategorie existieren kann, die ihrerseits nicht ohne eine Speisekarte existieren kann.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
3. Bestellabwicklung & Zahlungen<\/h3>\n
- \n
- \n
Bestellstruktur:<\/strong><\/p>\n
- \n
- \n
Bestellung<\/code> steht in einer Beziehung zuRestaurant<\/code> (Aggregation).<\/p>\n<\/li>\n- \n
Bestellung<\/code> besitzt starkBestellposition<\/code>\u00a0(1..*).<\/p>\n<\/li>\n- \n
Bestellung<\/code> hat eineZahlung<\/code> (0..1), was anzeigt, dass die Zahlung in der ersten Erstellungsphase optional ist.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Zahlungsstrategie (Polymorphismus):<\/strong><\/p>\n
- \n
- \n
Das System verwendet eine Schnittstelle
<<interface>> PaymentProcessor<\/code>.<\/p>\n<\/li>\n- \n
Konkrete Klassen
StripeProcessor<\/code> undPayPalProcessor<\/code> implementieren diese Schnittstelle. Dies erm\u00f6glicht es dem System, die Zahlungsanbieter zu wechseln, ohne die Kern-Bestellung<\/code>-Logik zu \u00e4ndern.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n4. Abstrakte Klasse vs. Schnittstelle (Das Fahrzeug-Beispiel)<\/h3>\n
Die obere rechte Ecke des Spickzettels kl\u00e4rt ein h\u00e4ufiges Missverst\u00e4ndnis auf:<\/p>\n
- \n
- \n
Abstrakte Klasse (
Fahrzeug<\/code>):<\/strong>\u00a0Auto<\/code> undMotorrad<\/code> erben vonFahrzeug<\/code>. Dies impliziert, dass sie Kern-Daten\/Struktur teilen (z. B.Motorart<\/code>,\u00a0R\u00e4der<\/code>).<\/p>\n<\/li>\n- \n
Schnittstelle (
Fahrbar<\/code>):<\/strong>\u00a0Auto<\/code> implementiertFahrbar<\/code>. Dies impliziertAuto<\/code> hat spezifisches Verhalten (drive()<\/code>) dasMotorrad<\/code> m\u00f6glicherweise nicht hat (oder m\u00f6glicherweise anders implementiert).<\/p>\n<\/li>\n<\/ul>\n
\nTeil 4: Visualisierung mit PlantUML<\/h2>\n
Im Folgenden finden Sie den PlantUML-Code zur Generierung der Kernstruktur der im Fallstudienbeispiel beschriebenen “Unified Food Delivery Platform”. Sie k\u00f6nnen diesen Code in jeden PlantUML-Editor kopieren, um das Diagramm anzuzeigen.<\/p>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195d5d056af.png\")
<\/p>\n\n\nPlantUML<\/span> - \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n