Generalisierung (auch Vererbung genannt) zeigt eine "ist-ein"-Beziehung zwischen Use Cases oder Akteuren.

Der spezialisierte Use Case/Akteur erbt alle Eigenschaften vom allgemeinen Use Case/Akteur.

Symbol

  [Allgemein]
       △
       │  ← Pfeil zum Allgemeinen
   ────┴────
   │       │
[Speziel]  [Speziel]
  Case 1    Case 2

Pfeil: Geschlossener, nicht ausgefüllter Pfeil (wie bei Vererbung in Klassendiagrammen)

Generalisierung bei Akteuren

Zeigt Hierarchie zwischen Akteuren.

       O
      /|\
      / \
    Benutzer  ← Allgemeiner Akteur
       △
       │
   ────┴────
   │       │
   O       O
  /|\     /|\
  / \     / \
 Kunde   Admin  ← Spezialisierte Akteure

Bedeutung:

• Kunde ist ein Benutzer
• Admin ist ein Benutzer
• Beide erben alle Use Cases von Benutzer
• Haben zusätzlich eigene, spezielle Use Cases

Beispiel: E-Commerce-System

       O
      /|\
      / \
    Benutzer
       │
       ├──► [Produkte durchsuchen]
       ├──► [Profil bearbeiten]
       │
       △
       │
   ────┴─────────
   │             │
   O             O
  /|\           /|\
  / \           / \
 Kunde         Admin
   │             │
   ├──► [Bestellen]        ├──► [Produkte verwalten]
   ├──► [Bewerten]         ├──► [Nutzer verwalten]
   └──► [Retoure]          └──► [Statistiken ansehen]

Vererbung:

• Kunde kann:

  • Produkte durchsuchen ✓ (geerbt)
  • Profil bearbeiten ✓ (geerbt)
  • Bestellen ✓ (eigener Use Case)
  • Bewerten ✓ (eigener Use Case)

• Admin kann:

  • Produkte durchsuchen ✓ (geerbt)
  • Profil bearbeiten ✓ (geerbt)
  • Produkte verwalten ✓ (eigener Use Case)
  • Nutzer verwalten ✓ (eigener Use Case)

Generalisierung bei Use Cases

Zeigt, dass ein Use Case eine spezielle Variante eines anderen ist.

┌─────────────────┐
│    Bezahlen     │ ← Allgemeiner Use Case
└─────────────────┘
         △
         │
     ────┴────────────
     │       │       │
┌─────┐ ┌─────┐ ┌─────┐
│Kredit│PayPal│Bank-│ ← Spezielle Use Cases
│-karte│      │über-│
└─────┘ └─────┘│weisung│
                └─────┘

Bedeutung:

• "Mit Kreditkarte bezahlen" ist eine Art von "Bezahlen"
• "Mit PayPal bezahlen" ist eine Art von "Bezahlen"
• "Mit Banküberweisung bezahlen" ist eine Art von "Bezahlen"
• Alle teilen gemeinsame Schritte, haben aber eigene Spezifika

Visuelles Beispiel: Bibliotheks-System

     O
    /|\
    / \
  Besucher
     │
     ├──► [Katalog durchsuchen]
     │
     △
     │
 ────┴────
 │       │
 O       O
/|\     /|\
/ \     / \
Gast  Mitglied
 │       │
 │       ├──► [Buch ausleihen]
 │       ├──► [Buch verlängern]
 │       └──► [Reservieren]


┌────────────────┐
│ Medien suchen  │ ← Allgemeiner Use Case
└────────────────┘
       △
       │
   ────┴──────────
   │       │     │
┌──────┐┌──────┐┌──────┐
│Buch  ││DVD   ││Zeit- │
│suchen││suchen││schrif-│
└──────┘└──────┘│ten   │
                │suchen│
                └──────┘

Code-Analogie

Generalisierung = Klassen-Vererbung:

// Allgemeine Klasse
class Benutzer {
    void produkteDurchsuchen() { ... }
    void profilBearbeiten() { ... }
}

// Spezialisierte Klassen
class Kunde extends Benutzer {  // Vererbung!
    void bestellen() { ... }
    void bewerten() { ... }
}

class Admin extends Benutzer {  // Vererbung!
    void produkteVerwalten() { ... }
    void nutzerVerwalten() { ... }
}

Generalisierung vs. Include vs. Extend

┌──────────────────────────────────────────────────┐
│           GENERALISIERUNG (IST-EIN)              │
└──────────────────────────────────────────────────┘

   [Bezahlen]
       △
       │ "ist ein"
   [Kreditkarte bezahlen]


┌──────────────────────────────────────────────────┐
│           INCLUDE (BENÖTIGT IMMER)               │
└──────────────────────────────────────────────────┘

[Bestellen] ────<<include>>────► [Bezahlen]
                   "benötigt"


┌──────────────────────────────────────────────────┐
│           EXTEND (OPTIONAL)                      │
└──────────────────────────────────────────────────┘

[Bestellen] ◄────<<extend>>──── [Gutschein einlösen]
                   "kann erweitert werden durch"

Praktisches Beispiel: Ticket-System

       O
      /|\
      / \
     Nutzer
       △
       │
   ────┴────────────
   │       │       │
   O       O       O
  /|\     /|\     /|\
  / \     / \     / \
 Kunde  Support  Manager
   │       │       │
   │       │       │
   ├──► [Ticket erstellen]
   │       │       │
   │       ├──► [Ticket bearbeiten]
   │       │       │
   │       │       ├──► [Statistiken ansehen]
   │       │       └──► [Team verwalten]
   │       │
   │       └──► [Ticket schließen]
   │
   └──► [Ticket status prüfen]

Vererbungs-Hierarchie:

• Nutzer (Basis):

  • Keine direkten Use Cases

• Kunde (erbt von Nutzer):

  • Ticket erstellen ✓
  • Ticket-Status prüfen ✓

• Support (erbt von Nutzer):

  • Ticket bearbeiten ✓
  • Ticket schließen ✓

• Manager (erbt von Nutzer):

  • Statistiken ansehen ✓
  • Team verwalten ✓

Regeln für Generalisierung

Gute Verwendung:

✅ Kunde ist ein Benutzer
✅ Admin ist ein Benutzer
✅ Kreditkarte-Bezahlen ist eine Art von Bezahlen

Schlechte Verwendung:

❌ Bestellen ist ein Bezahlen (nein, Bestellen nutzt Bezahlen)
❌ Login ist ein Benutzer (nein, Login ist ein Use Case)

Zusammenfassung

Verwandte Konzepte

• UML-Anwendungsfalldiagramm - Hauptnotiz
• UML-Use-Case-Akteur - Akteure
• UML-Use-Case-Include - Include-Beziehung
• UML-Use-Case-Extend - Extend-Beziehung
• UML-Vererbung - Vererbung bei Klassendiagrammen