Posted inUML

Beherrschung der UML-Nutzungsfalldiagramm-Beziehungen: Die Macht und die Gefahr von «include» und «extend»

In der Welt der Software-Anforderungen und SystemmodellierungUML (Unified Modeling Language) bleibt ein Eckpfeiler zur Visualisierung von Systemverhalten. Zu den mächtigsten, jedoch häufig missverstandenen Funktionen gehören die«include» und «extend»  Beziehungen zwischen Nutzungsfällen. Diese Mechanismen sind darauf ausgelegt, Doppelungen zu reduzieren, Variabilität zu managen, und Modularität zu verbessern in Nutzungsfalldiagrammen. Ihre Missbrauch ist jedoch weit verbreitet – was zu übermäßig komplexen Diagrammen, Verwirrung bei den Stakeholdern und einem Verlust der Fokussierung auf Nutzwert führt.

 

 

Dieser Artikel bietet einen umfassenden, praktischen und von Experten unterstützten Leitfaden zum Verständnis, Anwendung und Vermeidung der häufigen Fallstricke von «include» und «extend». Wir werden ihre wahren Semantik, vergleichen sie nebeneinander, untersuchen, warum sie in dieselbe Falle wie DFDs (funktionale Zerlegung) geraten, und bieten moderne Best Practices für Teams im Jahr 2025–2026 – insbesondere für solche, die in agilen, lean oder hybriden Umgebungen arbeiten.

🔹 Kernsemantik: Was «include» und «extend» Wirklich bedeuten

✅ «include»: Pflichtmäßige Wiederverwendung – Der „Immer-Erforderliche“ Teilfluss

Definition:
Die «include»-Beziehung stellt eine verpflichtend, immer ausgeführt Unterfluss, der für die Wiederverwendung über mehrere Anwendungsfälle herausgefiltert wurde.

📌 Hauptmerkmale:

  • Immer ausgeführt: Der eingeschlossene Anwendungsfall wird jedes Mal ausgeführt, wenn der Basis-Anwendungsfall aufgerufen wird.

  • Der Basis-Anwendungsfall ist ohne ihn unvollständig: Ohne das eingeschlossene Verhalten kann der Basis-Anwendungsfall sein Ziel nicht erreichen.

  • Abhängigkeitsrichtung: Pfeil zeigt von Basis → eingeschlossen.

  • Selbstständige Bedeutung: Der eingeschlossene Anwendungsfall ist typischerweise nicht sinnvoll allein—er macht nur Sinn als Teil eines größeren Prozesses.

  • Analogie: Wie eine Funktionsaufruf oder Unterprogramm in der Programmierung—wichtig für die Hauptroutine.

🧠 Klassisches Merkmal:

„Um Anmeldung, müssen Sie Benutzer authentifizieren.”
„Um Bargeld abheben, Sie müssen PIN überprüfen.”

Das sind unverhandelbare Schritte. Sie können sich nicht anmelden, ohne sich authentifiziert zu haben. Sie können kein Bargeld abheben, ohne die PIN zu überprüfen.

💡 Wann verwenden:

  • Wenn eine gemeinsame, komplexe, wiederverwendbare Aktion tritt in zwei oder mehr Anwendungsfällen auf.

  • Beispiele:

    • Benutzer authentifizieren

    • Audit-Protokoll speichern

    • Benachrichtigung senden

    • Eingabeformat überprüfen

✅ Richtlinie: Verwenden Sie «include» nur, wenn die wiederverwendete Aktion bedeutend, nicht trivial, und tritt in ≥2–3 Anwendungsfällen auf.

✅ «extend»: Optionale Variation – Der „bedingte Zusatz“

Definition:
Die «extend»-Beziehung definiertoptional, bedingte oder variantenabhängigeVerhalten, dasineinen bestimmtenErweiterungspunktdes Basis-Nutzungsszenarios.

📌 Hauptmerkmale:

  • Bedingt ausgeführt: Wird nur unter bestimmten Umständen ausgeführt.

  • Basis-Nutzungsszenario ist allein vollständig: Der normale Ablauf funktioniert ohne die Erweiterung.

  • Abhängigkeitsrichtung: Der Pfeil zeigtvon der Erweiterung → Basis (rückwärts).

  • Selbstständige Bedeutung: Das erweiternde Nutzungsszenario istfast nie sinnvoll allein—es macht nur Sinnim Kontext.

  • Analogie: Ähnlich wie einHaken, Plugin, oderAOP (aspektorientierte Programmierung) Hinweis—es fügt Verhalten an einem definierten Punkt hinzu.

🧠 Klassischer Merksatz:

„Während man Flug buchen, könnten Sie möglicherweisewünschen, Bevorzugten Sitzplatz auswählen.”
„Während man Mit Kreditkarte bezahlen, könnten Sie möglicherweisemüssen 3D-Sicherheitscode eingeben.”

Dies sind optionale Erweiterungen—nicht erforderlich für den Hauptablauf.

💡 Wann verwenden:

  • Um alternative Pfade, Ausnahmen, oder optionale Funktionen.

  • Wenn ein Anwendungsfall verschiedene Verhaltensweisen auf Bedingungen basiert (z. B. Benutzerrollen, Systemzustände, Präferenzen).

  • Beispiele:

    • Rabatt anwenden (erweitert Bestellung aufgeben)

    • Rückerstattung anfordern (erweitert Zahlung verarbeiten)

    • PDF-Beleg generieren (erweitert Transaktion abschließen)

✅ Richtlinie: Verwenden Sie «erweitern» sparsam – nur für bedeutsame Variationen mit klaren Erweiterungspunkte.

🔍 Schnellvergleich: «einbinden» vs «erweitern»

Aspekt «einbinden» «erweitern»
Ausführung Immer Manchmal / bedingt
Basis-UC allein abgeschlossen? ❌ Nein – hängt von eingebundenen ab ✅ Ja – ohne Erweiterungen abgeschlossen
Abhängigkeitsrichtung Basis → Eingeschlossen Erweiternd → Basis
Pfeilrichtung Zeigt auf den eingeschlossenen Use Case Zeigt auf den Basis-Use Case
Hauptziel Wiederverwendung obligatorisch, gemeinsame Schritte Behandlung von optionalen/varianten Abläufen
Analogie Funktionsaufruf / Unterprogramm Hook / Plugin / AOP-Empfehlung
Selbstständige Bedeutung? Selten Fast nie
Am besten geeignet für Wiederverwendbare, komplexe, quer verlaufende Anliegen Bedingte, optionale oder alternative Verhaltensweisen

⚠️ Die „Zerlegungsfalle“: Warum Use-Case-Diagramme von der Spur abkommen

Genau wie DFD (Datenumflussdiagramme) leiden unter der Funktions-Zerlegungsfalle, sind Use-Case-Diagramme anfällig für dieselbe tödliche Krankheit: Über-Zerlegung.

📉 Die DFD-Funktions-Zerlegungsfalle (Zusammenfassung):

  • Teams teilen Prozesse weiterhin in immer kleinere Blasen auf.

  • Diagramme explodieren in Dutzende kleiner, niedrigerer Funktionen.

  • Die ursprüngliche Absicht—Wert für den Benutzer zu liefern—wird verloren.

  • Endet letztendlich so aus, als wäre es Pseudocode oder interne Algorithmusgestaltung, nicht Benutzerverhalten.

🧨 Der Anwendungsfall „Funktionale Dekompositionskrankheit“:

  • Jeder kleine Schritt wird zu einem eigenen Anwendungsfall:

    • Benutzernamen eingeben

    • Passwort eingeben

    • Login-Button anklicken

    • Format überprüfen

    • Fehlermeldung anzeigen

  • „include“ wird angewendet liberal um jede Aktion zu zerlegen.

  • Ergebnis: Eine tiefe Hierarchie von Anwendungsfällen (A → B → C → D…), ohne eindeutiges Ziel des Akteurs.

  • Diagramme werden nicht wartbar, verwirrend, und nutzlos für Stakeholder.

❌ Rotes Flagge: Wenn Ihr Use-Case-Diagramm hat mehr als 15–20 Use Cases, oder wenn die meisten Basis-Use-Cases 2–4 Schritte lang sind, sind Sie wahrscheinlich in der Falle.

🛠️ Warum das passiert: Häufige Fehler und Missverständnisse

Fehlerquelle Erklärung Wie man es vermeidet
Übermäßige Verwendung von «include» Jeden Teil-Schritt als wiederverwendbaren Use Case zu behandeln. Verwenden Sie «include» nur für wichtige, wiederverwendbare, querschnittsartige Verhaltensweisen (z. B. Authentifizierung, Protokollierung).
Verwechslung der Pfeilrichtung Zeichnen von «include»-Pfeilen rückwärts (Basis ← eingeschlossen) oder «extend»-Pfeilen vorwärts. Denken Sie daran: include = Basis → eingeschlossen; extend = erweiternd → Basis.
Verwendung von «extend» für Alternativen Modellierung von Alternativabläufen innerhalb eines Use Cases als «extend» anstelle der Verwendung von textuellen Alternativen. Verwenden Sie textuelle Alternativabläufe für die meisten Variationen. Reservieren Sie «extend» für echte optionale Erweiterungen.
Erstellen von Include-Ketten A → B → C → D → E… Vermeiden Sie tiefe Ketten. Wenn Sie mehrere Einbindungen benötigen, überlegen Sie Refactoring in einen einzigen wiederverwendbaren Anwendungsfall.
Undefinierte Erweiterungspunkte Hinzufügen von «extend»-Beziehungen ohne klare, benannte Einfügepunkte. Definieren Sie explizite Erweiterungspunkte (z. B. „Nach Bestätigung der Zahlung“) im Basisanwendungsfall.
Diagrammverschmutzung Zu viele Anwendungsfälle und Beziehungen → visuelles Rauschen. Halten Sie Diagramme klein, fokussiert und aktorzentriert. Verwenden Sie mehrere Diagramme pro Subsystem.
Verwirrung bei Stakeholdern Nicht-technische Stakeholder finden «include/extend» schwer verständlich. Verwenden Sie textuelle Szenarien oder Benutzerstory-Karten zur Klarheit.
Modellierung auf Entwurfniveau Modellierung der internen Architektur (z. B. „Datenbank aufrufen“) anstelle von Nutzerzielen. Bleiben Sie fokussiert auf Aktorwert—nicht Implementierung.
Endlose Debatten Teams streiten sich über „ist es include oder extend?“, anstatt Szenarien zu schreiben. Verwenden Sie praktische Heuristiken und Priorisieren Sie Klarheit gegenüber Formalität.

✅ Best Practices für 2025–2026: Ein moderner, agiler Ansatz

Die Landschaft der Anforderungstechnik hat sich verändert. Agile, lean und produktgetriebene Teams bewegen sich zunehmend von schweren UML-Diagrammen weg zugunsten von leichte, wertorientierte Techniken.

🎯 Kernprinzip: Fokussieren Sie sich auf den Aktorwert, nicht auf die interne Struktur

❗ Stellen Sie diese Frage, bevor Sie ein «include» oder «extend» hinzufügen:
„Hilft diese Beziehung dem Benutzer, das Ziel zu verstehen, oder dient sie nur dazu, das System zu zerlegen?“

✅ Empfohlene moderne Praktiken:

1. Verwenden Sie «include» sparsam — nur für wesentliche wiederverwendbare Verhaltensweisen

  • Verwenden Sie nur für querschnittliche Anliegen die in mehreren Anwendungsfällen.

  • Beispiele:

    • Benutzer authentifizieren

    • E-Mail-Benachrichtigung senden

    • Sicherheitsereignis protokollieren

    • Geschäftsregeln anwenden

❌ Vermeiden: Benutzernamen eingeben, Auf Absenden klicken, E-Mail-Format überprüfen

2. Textuelle Alternativabläufe gegenüber „extend“ bevorzugen

  • Anstelle von:

    „extend“: Bevorzugten Sitz auswählen → Flug buchen

  • Verwenden:

    Anwendungsfall: Flug buchen
...
Alternativer Ablauf:
  1. Benutzer wählt die Option „Bevorzugten Sitz“.
  2. System zeigt Sitzplan an.
  3. Benutzer wählt Sitz aus.
  4. System wendet Sitzpräferenz an.

✅ Warum?Textuelle Abläufe sindeinfacher zu lesen, flexibler, undweniger anfällig für Missbrauch.

3. Behalten SieAnwendungsfalldiagrammeKlein und fokussiert

  • Ein Diagramm proAktionsobjekt oder Subsystem.

  • Begrenzen auf 5–10 Use Cases pro Diagramm.

  • Verwenden Sie Paketdiagramme oder Kontextdiagramme um die hochlevel Struktur zu zeigen.

4. Fragen Sie: „Würde eine Benutzerstory-Karte diese Information besser vermitteln?“

  • Wenn Sie 10 oder mehr «include»/«extend»-Beziehungen verwenden, überlegen Sie, das Diagramm durch folgendes zu ersetzen:

    • Ein Benutzerstory-Karte

    • Ein szenario-basierte Tabelle

    • Ein einfacher Flussdiagramm mit Schlüsselpfaden

🔄 Moderne Trend: Viele agile Teams vermeiden Use-Case-Diagramme ganz oder verwenden sie nur für die hochlevel Entdeckung.

5. Verwenden Sie «extend» nur für sinnvolle Varianten

  • Reservieren Sie «extend» füroptional, nicht-kernFunktionen, die:

    • Sindselten verwendet

    • Sindkontextabhängig

    • Sindunabhängigvom Kernziel

✅ Beispiel:
Zahlung verarbeiten (basis)
3D-Secure-Authentifizierung anwenden (extend) — nur, wenn von der Bank erforderlich

❌ Vermeiden Sie:
Kartennummer eingeben → Karte überprüfen → Zahlung verarbeiten (alle sollten Schritte im selben Anwendungsfall sein)

📊 Zusammenfassung: Die Goldenen Regeln für «include» und «extend»

Regel Anleitung
1. «include» = Pflicht Verwenden Sie nur fürwichtige, wiederverwendbareSchritte, die in ≥2 Anwendungsfällen auftreten.
2. «extend» = Optional Nur verwenden für bedingte, varianten- oder seltene Verhaltensweisen.
3. Der Basis-Anwendungsfall muss vollständig sein «extend»: Basis funktioniert allein. «include»: Basis ist ohne ihn unvollständig.
4. Halte es einfach Wenn ein Anwendungsfall nach «include»/«extend» weniger als 4–6 Schritte hat, hast du übermäßig dekomponiert.
5. Priorisiere Lesbarkeit Textszenarien > komplexe Diagramme.
6. Vermeide Kettenglieder Keine A → B → C → D. Umgestalten in einen wiederverwendbaren Anwendungsfall.
7. Kenne deine Zielgruppe Interessenten kümmern sich nicht um «include»-Pfeile—sie kümmern sich um Wert.
Frag: „Ist das ein Benutzerziel oder ein interner Schritt?“ Wenn es kein Ziel für den Akteur ist, gehört es wahrscheinlich nicht in einen Anwendungsfall.

🎯 Letzte Überlegung: Werkzeuge, keine Fallen

«include» und «extend» sind mächtige Werkzeuge—keine starren Regeln. Sie wurden entwickelt, um:

  • Duplikate zu reduzieren

  • Variabilität zu managen

  • Wartbarkeit zu verbessern

Aber wie die funktionale Dekomposition in DFDs, werden sie gefährliche Waffen wenn sie übermäßig verwendet werden. Die wahre Gefahr liegt nicht in den Beziehungen selbst—es ist das Ziel des Benutzers aus den Augen zu verlieren.

🔥 Erinnere dich:
Ein Use Case ist kein technischer Prozess.
Es ist eineGeschichte darüber, was der Benutzer erreichen möchte—und wie das System dabei hilft.

Wenn du unsicher bist, frage dich selbst:

„Würde ein Benutzer dies verstehen, ohne UML zu kennen?“
Wenn nicht, vereinfache es.
Wenn ja, bist du auf dem richtigen Weg.

📚 Weitere Lektüre & Quellen

  • UML-Spezifikation (OMG): www.omg.org/spec/UML

  • Martin Fowler – Use Case-Modellierung: Analyse-Muster & UML verdichtet

  • Ivar Jacobson – Der Objektvorteil: Grundlegende Arbeit zu Use Cases

  • Agiles Modellieren (AM) von Scott W. Ambler

  • Benutzerstory-Mapping von Jeff Patton – Eine moderne Alternative zu komplexen Diagrammen

✅ Die Einesatz-Regel

Verwenden Sie «include» für obligatorische Wiederverwendung, «extend» für optionale Variation – aber nur, wenn dies wirklich Wert hinzufügt. Andernfalls halten Sie es einfach.

Denn letztendlich, ist das Ziel nicht, perfekte UML-Diagramme– sondern, Systeme zu bauen, die echten Nutzern echten Wert liefern.

📌 Hinweis des Autors (2025–2026):
Da Teams sich zunehmend hin zu produktzentriert, wertgetrieben, und kollaborativ Entwicklung wandelt sich die Rolle traditioneller UML-Diagramme. «include» und «extend» bleiben nützlich – aber nur, wenn sie mit Zurückhaltung, Klarheit und Zweckmäßigkeit eingesetzt werdennur wenn sie mit Zurückhaltung, Klarheit und Zweckmäßigkeit eingesetzt werden. Lassen Sie sie dem Nutzer dienen, nicht dem Diagramm.