Stell dir vor, du willst ein Haus bauen:

• Ohne Plan: Jeder Handwerker macht, was er denkt
• Mit Plan: Alle wissen genau, was zu tun ist

UML ist der "Bauplan" für Software!

Vorteile:

• Entwickler verstehen sich besser
• Fehler werden früh erkannt
• Dokumentation ist automatisch da
• Planung ist einfacher

Struktur-Diagramme (WIE ist es aufgebaut?)

• Zeigen den Aufbau des Systems
• Statisch (ändert sich nicht während Laufzeit)

Verhaltens-Diagramme (WAS macht es?)

• Zeigen Abläufe und Aktionen
• Dynamisch (während Programm läuft)

Wofür?

• Struktur von Klassen zeigen
• Attribute und Methoden dokumentieren
• Beziehungen zwischen Klassen

Beispiel:

┌─────────────────┐
│     Auto        │
├─────────────────┤
│ - marke: String │
│ - baujahr: int  │
├─────────────────┤
│ + starten()     │
│ + fahren()      │
└─────────────────┘

Siehe: UML-Klassendiagramm für Details

Wofür?

• Funktionen des Systems zeigen
• Wer (Akteur) macht was (Use Case)
• Überblick über Systemfunktionen

Beispiel:

   ┌────┐
   │ 🧑 │ Kunde
   └─┬──┘
     │
     │    ┌─────────────────────┐
     ├───→│  Produkt bestellen  │
     │    └─────────────────────┘
     │
     │    ┌─────────────────────┐
     └───→│  Rechnung ansehen   │
          └─────────────────────┘

Siehe: UML-Anwendungsfalldiagramm für Details

Wofür?

• Geschäftsprozesse dokumentieren
• Workflows zeigen
• Algorithmen visualisieren
• Parallele Abläufe darstellen

Beispiel:

   ● Start
   │
   ▼
┌─────────┐
│ Login   │
└────┬────┘
    │
    ▼
   ◆
  ╱ ╲
[OK?]
 ╱   ╲
▼     ▼
Weiter Ende

Siehe: UML-Aktivitätsdiagramm für Details

Wofür?

• Kommunikation zwischen Objekten
• Zeitlicher Ablauf von Methodenaufrufen
• Interaktion zwischen Systemteilen

Beispiel:

Kunde    System    Datenbank
 │        │           │
 ├───────→│ login()   │
 │        ├──────────→│ prüfe()
 │        │←──────────┤ OK
 │←───────┤ erfolg    │
 │        │           │

Siehe: UML-Sequenzdiagramme für Details

Wofür?

• Zustände und Übergänge
• Lebenszyklus von Objekten
• Reaktion auf Ereignisse

Beispiel:

 ┌─────────┐  starten   ┌─────────┐
 │   Aus   │──────────→ │   An    │
 └─────────┘            └─────────┘
      ↑                      │
      └──────────────────────┘
         ausschalten

Siehe: UML-Zustandsdiagramme für Details

"Was kann das System?"
→ UML-Anwendungsfalldiagramm

"Wie ist das System aufgebaut?"
→ UML-Klassendiagramm

"Wie läuft ein Prozess ab?"
→ UML-Aktivitätsdiagramm

"Wie kommunizieren Objekte?"
→ UML-Sequenzdiagramme

"Welche Zustände gibt es?"
→ UML-Zustandsdiagramme

Schritt 1 - Anforderungen sammeln:

Anwendungsfalldiagramm erstellen:
- Akteure: Kunde, Admin, System
- Use Cases: Bestellen, Bezahlen, Verwalten

Schritt 2 - Struktur planen:

Klassendiagramm erstellen:
- Klassen: Kunde, Produkt, Warenkorb, Bestellung
- Beziehungen: Kunde hat Warenkorb, etc.

Schritt 3 - Prozesse definieren:

Aktivitätsdiagramm für Bestellprozess:
- Produkt wählen → In Warenkorb → Bezahlen → Bestätigen

Schritt 4 - Kommunikation klären:

Sequenzdiagramm für Login:
- Kunde → System → Datenbank → System → Kunde

1. Klarheit vor Schönheit:

• Diagramm muss verständlich sein
• Nicht zu komplex
• Beschriftungen verwenden

2. Konsistenz:

• Gleiche Namen in allen Diagrammen
• Einheitliche Notation
• Standards einhalten

3. Vollständigkeit:

• Alle wichtigen Elemente zeigen
• Aber nicht überladen
• Fokus auf das Wesentliche

4. Aktualität:

• Diagramme bei Änderungen anpassen
• Als "lebende Dokumentation"
• Teil der Projektdokumentation

1. Zu detailliert:

❌ FALSCH:
Jede kleine Methode im Klassendiagramm
→ Unübersichtlich!

✅ RICHTIG:
Nur wichtige Methoden zeigen
→ Klarer Überblick

2. Falsche Notation:

❌ FALSCH:
Eigene Symbole erfinden
→ Niemand versteht es

✅ RICHTIG:
Standard-UML-Symbole nutzen
→ Alle verstehen es

3. Keine Beschriftung:

❌ FALSCH:
Pfeile ohne Text
→ Bedeutung unklar

✅ RICHTIG:
Pfeile beschriften
→ Jeder weiß, was gemeint ist

4. Veraltet:

❌ FALSCH:
Diagramm von vor 6 Monaten
→ Entspricht nicht mehr dem Code

✅ RICHTIG:
Diagramm aktuell halten
→ Dokumentation ist nützlich

Diagramm-Typen kennen:

• Klassendiagramm (Struktur)
• Anwendungsfalldiagramm (Funktionen)
• Aktivitätsdiagramm (Abläufe)
• Sequenzdiagramm (Kommunikation)
• Zustandsdiagramm (Zustände)

Unterscheiden können:

• Strukturdiagramme vs. Verhaltensdiagramme
• Wann welches Diagramm?
• Symbole richtig verwenden

Diagramm erstellen können:

• Einfaches Klassendiagramm zeichnen
• Use Cases mit Akteuren
• Aktivitätsdiagramm mit Verzweigungen

Frage 1: "Nennen Sie drei UML-Diagrammtypen und deren Einsatzzweck."

Antwort:

1. Klassendiagramm: Zeigt die Struktur von Klassen mit ihren Attributen, Methoden und Beziehungen. Wird für das Design der Softwarearchitektur verwendet.

2. Anwendungsfalldiagramm: Zeigt die Funktionen des Systems aus Benutzersicht. Wird für die Anforderungsanalyse verwendet.

3. Aktivitätsdiagramm: Zeigt Abläufe und Prozesse mit Aktivitäten und Entscheidungen. Wird für die Modellierung von Workflows verwendet.

Frage 2: "Was ist der Unterschied zwischen Struktur- und Verhaltensdiagrammen?"

Antwort:
Strukturdiagramme zeigen den statischen Aufbau des Systems (z.B. Klassendiagramm). Sie ändern sich nicht während das Programm läuft.

Verhaltensdiagramme zeigen dynamische Abläufe (z.B. Aktivitätsdiagramm). Sie zeigen, was während der Programmausführung passiert.

Online (kostenlos):

• draw.io (diagrams.net)
• PlantUML (Code → Diagramm)
• Lucidchart

Desktop:

• Visual Paradigm
• Enterprise Architect
• StarUML

In IDE integriert:

• IntelliJ IDEA (UML-Plugin)
• Eclipse (UML2 Tools)
• Visual Studio (Class Designer)

Dieses Thema kommt immer in der IHK-Prüfung (Teil 2) vor. Also lerne es gut!