UML-Anwendungsfalldiagramme: Abitur-Leitfaden

1 · Was ist ein UML-Anwendungsfalldiagramm?

Grundlage — Zweck und Einordnung des Diagrammtyps

Ein UML-Anwendungsfalldiagramm (englisch: Use Case Diagram) modelliert die Anforderungen an ein Software-System aus der Sicht seiner Benutzer. Es beantwortet die Frage: „Was soll das System leisten?" — nicht wie es das intern umsetzt. Es zeigt, welche Funktionen (Anwendungsfälle) das System anbietet und welche Personen oder externe Systeme (Akteure) damit interagieren.

Kernidee: Was, nicht Wie

Das Anwendungsfalldiagramm beschreibt das externe, sichtbare Verhalten eines Systems — aus der Perspektive der Nutzer. Es ist kein Ablaufdiagramm und zeigt keine internen Methodenaufrufe. Sequenzdiagramme (die innere Logik) und Anwendungsfalldiagramme (die äußeren Anforderungen) ergänzen sich.

Im Abitur Hessen

Anwendungsfalldiagramme erscheinen regelmäßig im Abitur — meist mit 7–8 Bewertungseinheiten (BE). Es gibt drei verschiedene Aufgabentypen (→ Abschnitt 11). Der häufigste ist Typ A: eine Beschreibung der Anforderungen ist gegeben, du erhältst eine Zeichenvorlage und musst das Diagramm entwickeln und vervollständigen. Für alle Aufgabentypen gilt: Die Notationsregeln müssen sicher sitzen.

2 · Notationselemente auf einen Blick

Alle Bestandteile eines UML-Anwendungsfalldiagramms — kompakt zusammengefasst.

[ Rechteck ] Systemgrenze

Ein Rechteck umschließt alle Anwendungsfälle des Systems. Der Systemname steht innen, Akteure stehen außerhalb. Sie definiert den Geltungsbereich des modellierten Systems.

👤 Strichmännchen Akteur

Ein Strichmännchen mit dem Namen darunter. Repräsentiert eine Rolle, die ein Benutzer oder ein externes System übernimmt. Akteure stehen immer außerhalb der Systemgrenze.

( Ellipse ) Anwendungsfall (UC)

Eine Ellipse (Oval) innerhalb der Systemgrenze mit einem beschreibenden Namen (Verb + Objekt). Kann einen abgetrennten Abschnitt für Erweiterungspunkte enthalten, wenn er Basis einer extend-Beziehung ist.

————— Linie Assoziation

Eine durchgezogene Linie ohne Pfeilspitze zwischen einem Akteur und einem Anwendungsfall. Bedeutet: der Akteur ist an diesem Anwendungsfall beteiligt oder kann ihn auslösen.

- - - ﹥ «include» «include»-Beziehung

Ein gestrichelter Pfeil mit offenem Pfeilkopf und dem Stereotyp «include». Der Pfeil zeigt vom Basisanwendungsfall auf den inkludierten. Muss-Beziehung — immer ausgeführt.

- - - ﹥ «extend» «extend»-Beziehung

Ein gestrichelter Pfeil mit offenem Pfeilkopf und dem Stereotyp «extend». Der Pfeil zeigt vom erweiternden auf den Basisanwendungsfall. Kann-Beziehung — nur bei erfüllter Bedingung. Der Basisanwendungsfall hat Erweiterungspunkte.

—————▷ Generalisierung Generalisierung (Sonderfall)

Ein durchgezogener Pfeil mit offenem Dreieck. Zeigt eine Spezialisierungsbeziehung zwischen zwei Akteuren (oder Anwendungsfällen). Sehr selten im Abitur — nur einmal in den letzten 10 Jahren aufgetreten. Details in Abschnitt 9.

3 · Die Systemgrenze

Das Rechteck, das das modellierte System umschließt.

Ein System wird durch die Gesamtheit seiner Anwendungsfälle beschrieben. Diese werden durch die Systemgrenze zusammengefasst — ein einfaches Rechteck. Der Name des Systems steht innerhalb des Rechtecks, immer oben. Alle Anwendungsfälle (Ellipsen) befinden sich innerhalb dieses Rechtecks. Akteure stehen immer außerhalb.

Notation Systemgrenze mit Anwendungsfällen

Das Rechteck definiert den Geltungsbereich. Der Systemname steht innen. Anwendungsfälle befinden sich innerhalb, Akteure außerhalb der Grenze.

Systemname bestimmen

Der Systemname ergibt sich oft direkt aus der Aufgabenstellung — meistens als zusammengesetztes Substantiv wie „Festivalverwaltung", „Krankenhausverwaltung" oder „EB-System". Bei Typ-B-Aufgaben (keine Vorlage gegeben) musst du den Systemnamen selbst aus dem Aufgabentext ableiten.

4 · Der Akteur

Wer oder was interagiert mit dem System?

Ein Akteur modelliert einen Typ oder eine Rolle, die ein externer Benutzer oder ein externes System während der Interaktion mit dem System einnimmt. Im Abitur sind Akteure fast immer Personen in einer Berufs- oder Nutzerrolle (z.B. „Kunde", „Mitarbeiter", „Arzt").

Notation Akteure: Standardfall und Sonderfall

Akteur-Notation: Strichmännchen und System-Akteur

Oben: Standardfall — Strichmännchen mit Name darunter.
Unten (Sonderfall): System-Akteur als Rechteck mit Stereotyp «actor» — wurde im Abitur bisher nur einmal verwendet (ABI 2020 B, bereits in der Vorlage gegeben).

Akteur steht immer außerhalb der Systemgrenze

Akteure stehen per Definition außerhalb des Systems — sie sind externe Nutzer. Sie werden nie innerhalb des Systemrechtecks platziert. Ein häufiger Fehler im Abitur ist das versehentliche Einzeichnen von Akteuren innerhalb der Systemgrenze.

Mehrere Akteure am gleichen Anwendungsfall

Mehrere Akteure können mit demselben Anwendungsfall verbunden sein. Das ist erlaubt und kommt im Abitur regelmäßig vor — zum Beispiel sind „Mitarbeiter" und Wissensdatenbank" beide mit „Eintrag hinzufügen" verbunden (ABI 2020 B). Jeder Akteur bekommt seine eigene Assoziationslinie zu diesem Anwendungsfall.

Akteure aus dem Aufgabentext identifizieren

Im Abitur werden Akteure im Aufgabentext häufig mit einer Klammererklärung eingeführt, z.B.: „Mitarbeiterinnen und Mitarbeiter (im Folgenden Mitarbeiter genannt)" oder „Ärztinnen und Ärzte (im Folgenden Arzt genannt)". Diese Formulierung ist das Erkennungszeichen: Das Wort in der Klammer ist der Akteurname im Diagramm.

5 · Der Anwendungsfall (Use Case)

Die Hauptfunktionen des Systems — als Ellipse dargestellt.

Ein Anwendungsfall wird durch eine Ellipse (Oval) innerhalb der Systemgrenze dargestellt. In der Ellipse steht die Funktionsbeschreibung — typischerweise ein Verb mit Objekt, z.B. „Ticket buchen", „Patientenakte aktualisieren" oder „Inventur durchführen".

Wenn ein Anwendungsfall die Basis einer «extend»-Beziehung ist, enthält seine Ellipse einen zusätzlichen Abschnitt: einen horizontalen Trennstrich und darunter den oder die Erweiterungspunkte (extension points). Der Erweiterungspunkt beschreibt, an welcher Stelle und unter welcher Bedingung die Erweiterung erfolgen kann.

Notation Anwendungsfall — einfach vs. mit Erweiterungspunkt

Anwendungsfall einfach und mit Extension Point

Links: Einfacher Anwendungsfall ohne Erweiterungspunkt.
Rechts: Basisanwendungsfall einer «extend»-Beziehung — horizontaler Trennstrich und Erweiterungspunkt darunter.

Erweiterungspunkte (Extension Points): Der Erweiterungspunkt benennt den Punkt im Basisanwendungsfall, an dem die Erweiterung eingreifen kann. Im Abitur entspricht der Erweiterungspunkt oft dem Namen der Bedingung oder des erweiternden Anwendungsfalls. Er ist nur im Basisanwendungsfall einer «extend»-Beziehung einzutragen — nicht bei «include» und nicht im erweiternden Anwendungsfall.

6 · Die Assoziation

Die Verbindungslinie zwischen Akteur und Anwendungsfall.

Akteure werden über Verbindungslinien (Assoziationen) mit den Anwendungsfällen verbunden. Eine Assoziation zwischen einem Akteur und einem Anwendungsfall besagt, dass der Akteur am Anwendungsfall beteiligt ist oder diesen auslösen kann.

Notation Assoziationen zwischen Akteur und Anwendungsfall

Assoziation zwischen Akteur und Anwendungsfall

Durchgezogene Linie ohne Pfeilspitze. Ein Akteur kann mit mehreren Anwendungsfällen verbunden sein. Mehrere Akteure können denselben Anwendungsfall teilen.

Keine Pfeilspitze bei Assoziationen!

Die Verbindung zwischen Akteur und Anwendungsfall ist immer eine einfache, pfeilspitzenlose Linie. Pfeilspitzen kommen nur bei «include»- und «extend»-Beziehungen vor. Eine Assoziation mit Pfeilspitze wird ungern im Abitur gesehen.

7 · Die «include»-Beziehung

Die unbedingte Einbindung — die „Muss-Beziehung".

Eine «include»-Beziehung modelliert die unbedingte Einbindung der Funktionalität eines Anwendungsfalls in einen anderen. Der inkludierte Anwendungsfall wird immer und zwingend ausgeführt, wenn der Basisanwendungsfall ausgeführt wird. Deshalb spricht man von einer „Muss-Beziehung".

Typische Verwendung: Gemeinsame Funktionalität, die von mehreren Anwendungsfällen benötigt wird, wird in einen eigenen Anwendungsfall ausgelagert. So wird Redundanz vermieden. Merke dir auch, dass ein inkludierter Anwendungsfall für den Akteur eigenständig verfügbar ist, auch wenn der Zugriff nicht explizit dargestellt ist.

Notation «include»-Beziehung

Gestrichelter Pfeil mit offenem Pfeilkopf und Beschriftung «include». Der Pfeil zeigt vom Basisanwendungsfall auf den inkludierten — „A inkludiert B" bedeutet, der Pfeil geht von A nach B.

7.1 Pfeilrichtung — die wichtigste Regel

Pfeilrichtung bei «include»: Basis → Inkludiert

Der Pfeil zeigt vom Basisanwendungsfall auf den inkludierten Anwendungsfall. Leserichtung: „A inkludiert B" — der Pfeil geht von A nach B, die Pfeilspitze zeigt auf B.

Beispiel aus ABI 2022 B: „überweisen" inkludiert „Kontostand abfragen" → Pfeil von „überweisen" auf „Kontostand abfragen".

7.2 Erkennungsmerkmale im Aufgabentext

Im Aufgabentext verraten bestimmte Formulierungen, dass eine «include»-Beziehung vorliegt:

Formulierung im Text	Interpretation
„...welches er anschließend ... muss"	Das Folgende ist eine zwingend notwendige Funktion → include
„Dabei wird X aktualisiert"	X wird immer im Rahmen des übergeordneten Vorgangs ausgeführt → include
„was voraussetzt, dass X"	X ist eine Voraussetzung/Bedingung, die immer erfüllt sein muss → include
„bindet die Funktionalität von X ein"	Direkte UML-Beschreibung einer include-Beziehung
„muss/wird immer ... ausgeführt"	Keine Ausnahme, keine Bedingung → include

7.3 Beispiele aus dem Abitur

ABI 2025 B — Festivalverwaltung

„Ein Besucher kann ein Bändchen ausleihen, welches er anschließend mit Guthaben aufladen muss." → „Armband ausleihen" «include» „Guthaben ändern"

„Ein Besucher gibt sein Armband zurück. Das Guthaben auf dem Armband wird dann ausgezahlt." → „Armband zurückgeben" «include» „Guthaben ändern" (dieselbe Funktion wird von zwei verschiedenen Basisanwendungsfällen inkludiert — das ist erlaubt!)

ABI 2025 A — Krankenhausverwaltung

„Patienten können sich im Krankenhaus an- und abmelden. Dabei wird deren Patientenakte aktualisiert." → „Patient anmelden" «include» „Patientenakte aktualisieren" und „Patient abmelden" «include» „Patientenakte aktualisieren"

ABI 2022 B — EB-System

„– [Der Kunde] kann den aktuellen Kontostand abfragen.
– Der Kunde kann Überweisungen tätigen, wobei eine Überweisung nur ausgeführt wird, wenn das Konto des Kunden eine entsprechende Deckung aufweist."
Dieses Beispiel ist kniffliger, lässt sich aber mit logischem Denken lösen. Denn hier wird nicht mehr geäußert als dass wir zwei Anwendungsfälle haben („überweisen" und „Kontostand abfragen") und beim Überweisen der Kontostand geprüft werden muss, also „überweisen" «include» „Kontostand abfragen".

8 · Die «extend»-Beziehung

Die bedingte Erweiterung — die „Kann-Beziehung".

Eine «extend»-Beziehung modelliert die bedingte Einbindung der Funktionalität eines Anwendungsfalls in einen anderen. Der erweiternde Anwendungsfall wird nur dann ausgeführt, wenn eine bestimmte Bedingung erfüllt ist. Deshalb spricht man von einer „Kann-Beziehung". Der Basisanwendungsfall (der die Erweiterung möglich macht) enthält dazu einen Erweiterungspunkt in seiner Ellipse.

Notation «extend»-Beziehung mit Erweiterungspunkt und Bedingung

Gestrichelter Pfeil mit offenem Pfeilkopf und Beschriftung «extend». Der Pfeil zeigt vom erweiternden auf den Basisanwendungsfall. Der Basisanwendungsfall enthält den Erweiterungspunkt (abgetrennt durch einen Trennstrich). Die Bedingungsnotiz ist über eine gestrichelte Linie direkt am «extend»-Pfeil befestigt.

8.1 Pfeilrichtung — der häufigste Fehler im Abitur

Pfeilrichtung bei «extend»: Erweiternd → Basis

Der Pfeil zeigt vom erweiternden Anwendungsfall (der eine Erweiterung ist) auf den Basisanwendungsfall (der erweitert wird). Leserichtung: „B erweitert A" — der Pfeil geht von B nach (→) A, die Pfeilspitze zeigt auf A.

Merkhilfe: Die Pfeilspitze zeigt immer auf den Anwendungsfall, der die Erweiterungspunkte enthält — also auf den Basisanwendungsfall. Die Ausrichtung der Pfeilspitze kann man sich auch wie die der Vererbung vorstellen, das „Kind" (Zusatz, erweiterter Anwendungsfall) zeigt auf das „Elternteil" (ermöglicht die Erweiterung).

Beispiel aus ABI 2025 B: „Getränke nachbestellen" «extend» (erweitert) „Inventur durchführen". Pfeil von „Getränke nachbestellen" auf (→) „Inventur durchführen". Wenn wir das in Worte fassen, bedeutet das: Der Mitarbeiter kann eine „Inventur durchführen". Wenn wir dies tun, wird auch der Lagerbestand überprüft (dies ist die Bedingung), wenn dieser unter 20% liegt, werden zusätzlich automatisch Getränke nachbestellt („Getränke nachbestellen" wird auch ausgeführt). Wenn der Lagerbestand bei 20% oder mehr liegt, passiert das nicht.

8.2 Erweiterungspunkt (Extension Point)

Aufbau des Basisanwendungsfalls bei «extend»

Der Basisanwendungsfall enthält einen zusätzlichen Bereich, abgetrennt durch einen horizontalen Trennstrich:

Name des Anwendungsfalls
━━━━━━━━━━━━━━
extension points
Name des Erweiterungspunkts
(Name des 2. Erweiterungspunkts)

Der Name des Erweiterungspunkts bezeichnet die Stelle oder die Bedingung, an der die Erweiterung eingreifen kann. Im Abitur entspricht er meistens der Bedingung (die in der Notiz enthalten ist) oder manchmal auch dem Namen des erweiternden Anwendungsfalls.

8.3 Die Bedingungsnotiz

Bedingung am extend-Pfeil — nicht am Anwendungsfall!

Im Abitur ist die Bedingung direkt am «extend»-Pfeil befestigt — nicht an einem der Anwendungsfälle. Eine rechteckige Notiz mit dem Text der Bedingung ist an einen gestrichelten Pfeil ohne Pfeilspitze mit dem «extend»-Pfeil verbunden. Die Notiz enthält die Bedingung, unter der die Erweiterung stattfindet.

8.4 Erkennungsmerkmale im Aufgabentext

Formulierung im Text	Interpretation
„Sollten weniger als X ... vorhanden sein, wird Y"	Bedingte Erweiterung — Y erweitert den UC, unter dem Y möglicherweise nötig wird → extend
„Bei Bedarf" / „falls gewünscht"	Optionale Ausführung, nicht immer → extend
„Wenn der Kunde X wünscht, wird Y"	Bedingungsabhängige Erweiterung → extend
„Bei Nutzung kann ..."	Optionale, bedingte Zusatzfunktion → extend
„Sollte sich dabei zeigen, dass ..."	Nachgelagerte optionale Aktion bei Erfüllung einer Bedingung → extend
„Bei Unvollständigkeit muss ..."	Trotz „muss" — es ist nur nötig, wenn die Bedingung (Unvollständigkeit) eintritt → extend

8.5 Beispiele aus dem Abitur

ABI 2025 A — Krankenhausverwaltung

„Ein Arzt erstellt einen Behandlungsplan und aktualisiert die Patientenakte bei Bedarf."

→ „Patientenakte aktualisieren" «extend» „Behandlungsplan erstellen"
Basisanwendungsfall: „Behandlungsplan erstellen" mit extension point „Patientenakte aktualisieren"
Bedingung: bei Bedarf

ABI 2024 A — Wettbewerbsverwaltung

„– Ein Mitarbeiter kann einen Chor anschreiben.
– Die Noten und MP3-Samples können von einem Chor hochgeladen werden, welche anschließend durch einen Mitarbeiter auf Vollständigkeit geprüft werden. Bei Unvollständigkeit muss der Mitarbeiter den Chor anschreiben."

→ „Chor anschreiben" «extend» „Noten / MP3 hochladen"
Basisanwendungsfall: „Noten / MP3 hochladen" mit extension point „Chor anschreiben"
Bedingung: Noten / MP3 sind unvollständig

ABI 2025 B — Festivalverwaltung

„– Ein Mitarbeiter kann jederzeit Getränke telefonisch nachbestellen.
– Ein Mitarbeiter eines Getränkestandortes kann eine Inventur durchführen, um zu ermitteln, wie viele Getränke noch vorhanden sind. Sollten weniger als 20 Prozent des Getränkevorrats vorhanden sein, müssen Getränke nachbestellt werden."

→ „Getränke nachbestellen" «extend» „Inventur durchführen"
Basisanwendungsfall: „Inventur durchführen" mit extension point „Lagerbestand < 20%"
Bedingung: Lagerbestand < 20%

8.6 include vs. extend — der direkte Vergleich

Merkmal	«include»	«extend»
Art	Muss-Beziehung (immer)	Kann-Beziehung (bedingt)
Pfeilrichtung	Basis → Inkludiert	Erweiternd → Basis
Erweiterungspunkte	Nicht vorhanden	Im Basisanwendungsfall (Pflicht)
Bedingungsnotiz	Nicht vorhanden	Am «extend»-Pfeil (Pflicht)
Typische Schlüsselwörter	„muss", „immer", „dabei wird"	„kann", „falls", „bei Bedarf", „sollte"
Zweck	Gemeinsame Funktionalität auslagern	Optionale Erweiterung modellieren

9 · Generalisierung (Sonderfall)

Sehr selten im Abitur — aber gut zu kennen.

Die Generalisierung modelliert eine Spezialisierungsbeziehung zwischen zwei Akteuren (oder zwei Anwendungsfällen). Sie bedeutet: Der spezialisierte Akteur erbt alle Eigenschaften und Verbindungen des generalisierten Akteurs — er kann alle Anwendungsfälle nutzen, die auch der allgemeinere Akteur nutzen kann, und besitzt (normalerweise) zusätzlich eigene.

Sonderfall Generalisierung zwischen Akteuren

Durchgezogener Pfeil mit offenem (nicht gefülltem) Dreieck als Pfeilspitze. Die Pfeilspitze zeigt auf den generalisierten (übergeordneten) Akteur. In diesem Beispiel erbt „Mitarbeiter" alle Anwendungsfälle von „Mitglied", hat aber zusätzliche eigene. Merke: Jeder Mitarbeiter ist auch ein Mitglied (nicht umgekehrt). Mitarbeiter sind spezialisierte Mitglieder.

Wichtiger Hinweis zur Häufigkeit: Die Generalisierung zwischen Akteuren ist in den letzten 10 Jahren im Abitur Hessen nur ein einziges Mal aufgetreten (ABI 2017 B) — und war bereits in der Vorlage eingezeichnet. Es ist sehr unwahrscheinlich, dass du sie im Abitur selbst einzeichnen musst. Dennoch musst du sie erkennen und erklären können, falls ein vollständiges Diagramm mit ihr gegeben ist.

Bedeutung der Generalisierung (aus der offiziellen Abitur-Lösung)

Die Generalisierung kann zwischen Akteuren und zwischen Anwendungsfällen modelliert werden. Die Pfeilspitze zeigt auf den Akteur oder Anwendungsfall, der spezialisiert wird (den Elternteil). Im Abitur-Beispiel 2017 B: „Der Akteur Mitarbeiter kann alle Anwendungsfälle verwenden, die auch ein Mitglied verwenden kann — darüber hinaus ist es aber nur dem Mitarbeiter möglich, Rechnungen auszustellen."

10 · Ein vollständiges Diagramm verstehen und erläutern

Aufgabentyp C — Anhand der Taxizentrale (ABI 2023 B) erklärt.

Beim Aufgabentyp C (→ Abschnitt 11) wird dir ein fertiges, vollständiges Anwendungsfalldiagramm gegeben. Du musst es entweder inhaltlich erläutern (was zeigt das Diagramm?), die Notationselemente beschreiben (was bedeuten die verschiedenen Symbole?), oder beides. Das folgende Diagramm der Taxizentrale (ABI 2023 B) dient als Grundlage.

ABI 2023 B Vollständiges Anwendungsfalldiagramm — Taxizentrale

Vollständiges Anwendungsfalldiagramm Taxizentrale ABI 2023 B

Das vollständige Anwendungsfalldiagramm der Taxizentrale aus ABI 2023 B. Es enthält alle Notationselemente: Systemgrenze, Akteure, Anwendungsfälle, Assoziationen, eine include-Beziehung und zwei extend-Beziehungen mit Erweiterungspunkten und Bedingungsnotizen.

10.1 Notationselemente beschreiben

Wenn die Aufgabe lautet „Beschreiben Sie die wesentlichen Notationselemente", musst du alle relevanten Elemente einzeln benennen und ihre Bedeutung erklären. Die offizielle Abitur-Lösung liefert die exakten Formulierungen — lerne diese, sie geben maximale Punkte:

Systemgrenze

Ein System wird durch die Summe aller Anwendungsfälle beschrieben. Diese werden durch die Systemgrenze zusammengefasst. Der Name des Systems steht innerhalb der Systemgrenze.

Akteur

Ein Akteur modelliert einen Typ oder eine Rolle, die ein externer Benutzer oder ein externes System während der Interaktion mit dem System einnimmt.

Anwendungsfall

Ein Anwendungsfall wird durch eine Ellipse innerhalb der Systemgrenze dargestellt. In der Ellipse steht die Funktionsbeschreibung.

Assoziation (Verbindungslinie)

Die Akteure werden über Verbindungslinien (Beziehungen) mit den Anwendungsfällen verbunden. Eine Beziehung zwischen einem Akteur und einem Anwendungsfall besagt, dass der Akteur am Anwendungsfall beteiligt ist oder diesen Anwendungsfall auslösen kann.

«include»-Beziehung

Eine include-Beziehung modelliert die unbedingte Einbindung der Funktionalität eines Anwendungsfalls in einen anderen Anwendungsfall (Muss-Beziehung). Dargestellt wird die include-Beziehung durch einen gestrichelten Pfeil, wobei der Pfeil auf den inkludierten Anwendungsfall zeigt.

«extend»-Beziehung

Eine extend-Beziehung modelliert die bedingte Einbindung der Funktionalität eines Anwendungsfalls in einen anderen Anwendungsfall (Kann-Beziehung). Der erweiterte Anwendungsfall wird durch sogenannte Erweiterungspunkte (extension points) detailliert beschrieben. Die Bedingung wird definiert. Tritt die Bedingung ein, wird die Erweiterung ausgeführt. Dargestellt wird die extend-Beziehung durch einen gestrichelten Pfeil, wobei der Pfeil auf den erweiterten Anwendungsfall zeigt.

10.2 Inhalt des Diagramms erläutern

Bei „Erläutern Sie die inhaltliche Bedeutung" gehst du systematisch durch das Diagramm: Wer sind die Akteure? Was kann jeder Akteur tun? Welche Abhängigkeiten bestehen? Die offizielle Lösung für die Taxizentrale (ABI 2023 B) lautet:

Musterlösung — Inhaltliche Erläuterung Taxizentrale Im System „Taxizentrale" löst der Kunde den Anwendungsfall „Taxi bestellen" durch Anruf bei der Taxizentrale aus. Der Mitarbeiter ist an diesem Anwendungsfall beteiligt, da er den Anruf entgegennimmt. Der Anwendungsfall „Taxi bestellen" bindet die Funktionalität des Anwendungsfalls „Auftrag mit Ortsangaben erfassen" zwingend ein. Der Mitarbeiter kann die Verfügbarkeit der Taxis prüfen. Wenn ein Taxi verfügbar ist, kann der Mitarbeiter die Bereitschaft zur Übernahme des Auftrags bei dem Fahrer des Taxis anfragen. Signalisiert der Fahrer seine Bereitschaft, kann der Mitarbeiter den Auftrag an den Fahrer vergeben.

Aufbau einer guten inhaltlichen Erläuterung

1. Welches System wird modelliert (Systemname nennen)?
2. Akteure vorstellen — wer agiert mit dem System?
3. Für jeden Akteur: Welche Anwendungsfälle löst er aus / ist er beteiligt?
4. include-Beziehungen: Welcher UC bindet welchen anderen zwingend ein?
5. extend-Beziehungen: Welcher UC erweitert welchen — und unter welcher Bedingung?

10.3 Zweck von Anwendungsfalldiagrammen (Sonderfrage)

Vereinzelt wird auch der Zweck des Diagrammtyps abgefragt. Diese Frage kam in den letzten 10 Jahren nur einmal vor (ABI 2017 A). Die offizielle Antwort:

Musterlösung — Zweck von UML-Anwendungsfalldiagrammen Ein UML-Anwendungsfalldiagramm modelliert die Anforderungen an ein System — „Was" ein System leistet. Es dient der Absprache zwischen Kunden und Software-Entwicklungsteam.

11 · Die drei Aufgabentypen im Abitur

Was dich in der Prüfung erwartet — und wie häufig jeder Typ vorkommt.

Typ A Entwickeln und zeichnen — mit Vorlage häufigster Typ

Du erhältst eine textliche Beschreibung der Anforderungen (als Aufzählung) und eine Zeichenvorlage in den Materialien. Die Vorlage enthält bereits einige Akteure und meist 1–2 Anwendungsfälle, die du nicht neu erfinden musst — du erkennst sofort Systemname und Akteure. Deine Aufgabe: Das Diagramm vollständig entwickeln und einzeichnen.

Aufgetreten in: ABI 2020 B, 2021 C, 2024 A, 2024 B, 2025 A, 2025 B — mit Abstand der häufigste Typ.

Typ B Entwickeln und zeichnen — ohne Vorlage schwierigster Typ

Du erhältst nur die textliche Beschreibung der Anforderungen — keine Vorlage, keine Akteure, keinen Systemnamen als gegeben. Du musst das komplette Diagramm eigenständig konzipieren und zeichnen: Systemname ableiten, Akteure identifizieren, Anwendungsfälle bestimmen, Layout selbst wählen.

Aufgetreten in: ABI 2022 B und ABI 2022 C — nur 2 Mal in den letzten 10 Jahren. Beide Male im selben Jahr (2022, zwei verschiedene Vorschläge).

Typ C Vollständiges Diagramm erklären selten

Dir wird ein fertiges, vollständiges Anwendungsfalldiagramm gegeben. Du musst es entweder inhaltlich erläutern, die Notationselemente beschreiben, oder beides — je nach Aufgabenstellung. Manchmal wird auch der Zweck von Anwendungsfalldiagrammen abgefragt.

Aufgetreten in: ABI 2023 B (Notationselemente beschreiben + Inhalt erläutern) und ABI 2017 A (nur Inhalt erläutern) — 2 Mal in 10 Jahren. Detaillierte Vorbereitung dazu in Abschnitt 10.

Tipp für die Prüfung: Auch wenn Typ A der häufigste Typ ist, lohnt sich die Vorbereitung auf alle drei Typen. Das Wissen für Typ B und C kommt automatisch, wenn man Typ A gründlich beherrscht — man braucht nur die Strategie anzupassen.

12 · Lösungsstrategie: Schritt für Schritt

Ein systematisches Vorgehen für alle drei Aufgabentypen.

12.1 Vorgehen für Typ A und Typ B (Zeichenaufgaben)

Systemname und Akteure bestimmen. Bei Typ A: Vorlage anschauen — Systemname und alle Akteure sind hier immer bereits gegeben (keine Ausnahme in den letzten 10 Jahren). Bei Typ B: Den Aufgabentext lesen und Akteure anhand der Rollenbezeichnungen identifizieren. Merke: Akteure werden im Abitur häufig mit einer Klammerdefinition eingeführt („im Folgenden Mitarbeiter genannt").
Alle Anwendungsfälle aus dem Text ableiten. Jeder Aufzählungspunkt im Aufgabentext beschreibt in der Regel einen oder mehrere Anwendungsfälle. Benenne sie als knappe Verb-Objekt-Phrase. Vorsicht: Manche Sätze enthalten versteckte Anwendungsfälle (z.B. der inkludierte UC ist oft nicht als eigener Aufzählungspunkt formuliert). Lies jeden Satz genau.
Assoziationen einzeichnen. Welcher Akteur ist an welchem Anwendungsfall beteiligt oder löst ihn aus? Einfache durchgezogene Linie, keine Pfeilspitze. Ein Anwendungsfall kann von mehreren Akteuren aus erreichbar sein.
«include»-Beziehungen erkennen und einzeichnen. Suche nach Schlüsselwörtern wie „muss", „immer", „dabei wird", „voraussetzt". Pfeilrichtung: Basis → Inkludiert. Kein Erweiterungspunkt nötig.
«extend»-Beziehungen erkennen und einzeichnen. Suche nach Schlüsselwörtern wie „kann", „falls", „bei Bedarf", „sollte", „wenn ... gewünscht". Pfeilrichtung: Erweiternd → Basis. Erweiterungspunkt im Basisanwendungsfall eintragen. Bedingungsnotiz an den «extend»-Pfeil befestigen.
Alles überprüfen. Sind alle Anwendungsfälle aus der Aufgabe abgedeckt? Haben alle «extend»-Beziehungen einen Erweiterungspunkt und eine Bedingung? Haben alle «include»- und «extend»-Pfeile die richtige Richtung? Stehen alle Akteure außerhalb der Systemgrenze?

12.2 Vorgehen für Typ B (zusätzlich)

Ohne Vorlage: Layout selbst wählen

Bei Typ-B-Aufgaben gibt es keine Vorlage. Empfohlenes Layout: Akteure links und rechts außerhalb des Rechtecks, Anwendungsfälle in der Mitte innerhalb des Rechtecks. Der Systemname steht oben innerhalb des Rechtecks. Wähle eine übersichtliche Anordnung — Überschneidungen von Pfeilen minimieren.

12.3 Vorgehen für Typ C (Erklärungsaufgaben)

Aufgabenstellung genau lesen. Wird verlangt: (a) Notationselemente beschreiben, (b) Inhalt erläutern, (c) Zweck des Diagrammtyps angeben, oder eine Kombination? Jede Teilaufgabe hat eigene Antworten.
Notationselemente beschreiben (wenn gefragt): Systemgrenze → Akteur → Anwendungsfall → Assoziation → include → extend. Verwende die offiziellen Formulierungen aus Abschnitt 10.1.
Inhalt erläutern (wenn gefragt): Systematisch durch das Diagramm gehen — Akteure vorstellen, für jeden die möglichen Anwendungsfälle beschreiben, include-Beziehungen als „zwingende Einbindung" erklären, extend-Beziehungen mit Bedingung erläutern.

13 · Abituraufgaben 2021–2025

Alle Anwendungsfalldiagramm-Aufgaben der letzten Jahrgänge — mit Musterlösungen und Aufschlüsselung.

ABI 2025 B Festivalverwaltung Typ A 8 BE

13.1.1 Aufgabenstellung

Aufgabe 1.2 — Typ A (Vorlage gegeben, 2 Akteure + 2 UCs vorgegeben) Für die Dokumentation der Software sollen die folgenden Anwendungsfälle dargestellt werden.

– Ein Besucher kann ein Bändchen ausleihen, welches er anschließend mit Guthaben aufladen muss.
– Das Guthaben auf einem Bändchen kann jederzeit geändert werden.
– Ein Besucher gibt beim Verlassen des Festivals sein Armband zurück. Das Guthaben auf dem Armband wird dann ausgezahlt.
– Ein Besucher kann bei Mitarbeiterinnen und Mitarbeitern (im Folgenden Mitarbeiter) eines Getränkestandes ein Getränk kaufen.
– Ein Mitarbeiter kann jederzeit Getränke telefonisch nachbestellen.
– Ein Mitarbeiter eines Getränkestandortes kann eine Inventur durchführen, um zu ermitteln, wie viele Getränke noch vorhanden sind. Sollten weniger als 20 Prozent des Getränkevorrats vorhanden sein, müssen Getränke nachbestellt werden.

Vorlage Gegebene Vorlage (Material 2)

13.1.2 Aufschlüsselung der Lösung

UC
6 Anwendungsfälle: Armband ausleihen, Armband zurückgeben (vorgegeben), Guthaben ändern, Getränk kaufen, Getränke nachbestellen, Inventur durchführen.
ASSO
Besucher ist mit: Armband ausleihen, Armband zurückgeben, Getränk kaufen verbunden. Mitarbeiter ist mit: Getränk kaufen, Getränke nachbestellen, Inventur durchführen verbunden.
INCL
3 include-Beziehungen: „Armband ausleihen" inkludiert „Guthaben ändern" (Aufladen ist Pflicht). „Armband zurückgeben" inkludiert „Guthaben ändern" (Auszahlung ist Pflicht). „Getränk kaufen" inkludiert „Guthaben ändern" (Bezahlung via Guthaben ist Pflicht).
EXT
1 extend-Beziehung: „Getränke nachbestellen" erweitert „Inventur durchführen" — Bedingung: Lagerbestand < 20%. Extension point in der Ellipse „Inventur durchführen".

ABI 2025 A Krankenhausverwaltung Typ A 8 BE

13.2.1 Aufgabenstellung

Aufgabe 1.2 — Typ A (leere Vorlage mit 2 Akteuren gegeben) Die Interaktionen von Patientinnen und Patienten (im Folgenden Patient genannt) sowie dem Krankenhauspersonal mit dem System soll dargestellt werden.

– Patienten können sich im Krankenhaus an- und abmelden. Dabei wird deren Patientenakte aktualisiert.
– Ärztinnen und Ärzte (im Folgenden Arzt genannt) können sich die Akten der Patienten jederzeit ansehen und auch ändern.
– Ein Arzt kann sich die Zimmerbelegung ansehen.
– Ein Arzt führt eine Operation aus.
– Ein Arzt erstellt einen Behandlungsplan und aktualisiert die Patientenakte bei Bedarf.

Vorlage Gegebene Vorlage (Material 1)

Vorlage ABI 2025 A Krankenhausverwaltung

13.2.2 Aufschlüsselung der Lösung

UC
7 Anwendungsfälle: Patient anmelden, Patient abmelden, Patientenakte aktualisieren, Patientenakte anzeigen, Zimmerbelegung ansehen, Operation ausführen, Behandlungsplan erstellen.
ASSO
Patient ist mit: Patient anmelden, Patient abmelden verbunden. Arzt ist mit: Patientenakte aktualisieren, Patientenakte anzeigen, Zimmerbelegung ansehen, Operation ausführen, Behandlungsplan erstellen verbunden.
INCL
2 include-Beziehungen: „Patient anmelden" inkludiert „Patientenakte aktualisieren". „Patient abmelden" inkludiert „Patientenakte aktualisieren" (Schlüsselwort: „Dabei wird deren Patientenakte aktualisiert" — immer, ohne Ausnahme).
EXT
1 extend-Beziehung: „Patientenakte aktualisieren" erweitert „Behandlungsplan erstellen" — Bedingung: bei Bedarf. Erweiterungspunkt in der Ellipse „Behandlungsplan erstellen". Beachte: Arzt ist zusätzlich direkt mit „Patientenakte aktualisieren" verbunden, da er die Akte auch direkt ändern kann.

ABI 2024 B Flugticketverwaltung Typ A 7 BE

13.3.1 Aufgabenstellung

Aufgabe 1.2 — Typ A (leere Vorlage mit 2 Akteuren gegeben) Für die Kundenabwicklung am Flughafen sollen einige Anwendungsfälle von Kunde sowie Mitarbeiterinnen und Mitarbeitern (im Folgenden Mitarbeiter genannt) dargestellt werden.

– Ein Kunde kann ein Kundenkonto beim Flughafen anlegen. Die persönlichen Daten müssen dazu eingegeben werden, welche auch später geändert werden können.
– Ein Kunde kann einen Flug suchen.
– Ein Kunde kann ein Ticket buchen. Bei Kreditkartennutzung kann jenes direkt bezahlt werden. Der Bezahlvorgang kann aber auch am Flughafenschalter erfolgen.
– Ein Ticket wird vom Mitarbeiter gedruckt.
– Ein Kunde muss sein Gepäck aufgeben. Der Kunde wird nach dem Druck des Tickets danach gefragt, ob er sein Gepäck komplett bzw. anteilig abgeben möchte oder dies zu einem späteren Zeitpunkt erledigt.
– Ein Mitarbeiter kann das Ticket stornieren.

Vorlage Gegebene Vorlage (Material 2)

13.3.2 Aufschlüsselung der Lösung

UC
8 Anwendungsfälle: Flug suchen, Kundenkonto anlegen, Kundendaten ändern, Ticket buchen, Ticket bezahlen, Gepäck aufgeben, Ticket drucken, Ticket stornieren.
ASSO
Kunde: Flug suchen, Kundenkonto anlegen, Kundendaten ändern, Ticket buchen, Ticket bezahlen, Gepäck aufgeben. Mitarbeiter: Ticket drucken, Ticket stornieren.
INCL
2 include-Beziehungen: „Kundenkonto anlegen" inkludiert „Kundendaten ändern" (Daten müssen eingegeben werden). „Ticket drucken" inkludiert „Gepäck aufgeben" (nach dem Druck wird immer danach gefragt).
EXT
1 extend-Beziehung: „Ticket bezahlen" erweitert „Ticket buchen" — Bedingung: Kreditkarte vorhanden. Erweiterungspunkt in „Ticket buchen". Beachte: Der Bezahlvorgang am Schalter ist eine separate Assoziationsmöglichkeit des Kunden mit „Ticket bezahlen".

ABI 2024 A Wettbewerbsverwaltung Typ A 7 BE

13.4.1 Aufgabenstellung

Aufgabe 1.8 — Typ A (Vorlage mit 2 Akteuren + 2 UCs gegeben) Die Chöre evaluieren am Ende eines Wettbewerbs die Wettbewerbsorganisation. Zu diesem Zweck sollen die evaluierten Anwendungsfälle abgebildet werden.

– Bei der Anmeldung gibt ein Chor an, mit wieviel Teilnehmern und an welchen Kategorien er teilnimmt.
– Ein Chor kann seine Teilnehmerzahl oder Kategorien nachträglich ändern.
– Ein Chor kann sich von einem Wettbewerb abmelden.
– Ein Chor kann sein Ranking einsehen.
– Ein Mitarbeiter kann einen Chor anschreiben.
– Die Noten und MP3-Samples können von einem Chor hochgeladen werden, welche anschließend durch einen Mitarbeiter auf Vollständigkeit geprüft werden. Bei Unvollständigkeit muss der Mitarbeiter den Chor anschreiben.
– Der Mitarbeiter kann das Gesamtergebnis aller Wettbewerbe einsehen.
– Der Mitarbeiter kann einen Ablaufplan erstellen.

Vorlage Gegebene Vorlage (Material 6)

Vorlage ABI 2024 A Wettbewerbsverwaltung

13.4.2 Aufschlüsselung der Lösung

UC
9 Anwendungsfälle: anmelden (vorgegeben), abmelden (vorgegeben), Ranking einsehen, Kategorie ändern, Teilnehmeranzahl ändern, Noten / MP3 hochladen, Chor anschreiben, Gesamtergebnis einsehen, Ablaufplan erstellen.
ASSO
Chor: anmelden, abmelden, Ranking einsehen, Kategorie ändern, Teilnehmeranzahl ändern, Noten/MP3 hochladen. Mitarbeiter: Noten/MP3 hochladen (Prüfung!), Chor anschreiben, Gesamtergebnis einsehen, Ablaufplan erstellen.
INCL
2 include-Beziehungen: „anmelden" inkludiert „Kategorie ändern" (Kategorien werden bei der Anmeldung festgelegt — Änderung setzt Anmeldung voraus) sowie „Teilnehmeranzahl ändern" (Teilnehmerzahl wird bei der Anmeldung angegeben).
EXT
1 extend-Beziehung: „Chor anschreiben" erweitert „Noten / MP3 hochladen" — Bedingung: Noten / MP3 sind unvollständig. Erweiterungspunkt in der Ellipse „Noten / MP3 hochladen".

ABI 2022 B EB-System (Online-Banking) Typ B 5 BE

13.5.1 Aufgabenstellung

Aufgabe 1.1 — Typ B (KEINE Vorlage gegeben) Der Zugang einer Kundin oder eines Kunden (im Folgenden Kunde genannt) auf ein Konto erfolgt über den EB-Server. Folgende Funktionalitäten sind bei der Entwicklung des EB-Systems bereit zu stellen:

– Der Kunde muss sich beim EB-Server unter Angabe von IBAN und Online-PIN des Kontos anmelden (Login).
– Er kann den aktuellen Kontostand abfragen.
– Der Kunde kann Überweisungen tätigen, wobei eine Überweisung nur ausgeführt wird, wenn das Konto des Kunden eine entsprechende Deckung aufweist.
– Der Kunde kann sich eine Übersicht über die Buchungen seines Kontos anzeigen lassen.
– Er kann nach Buchungen suchen.
– Der Kunde kann die Sitzung beenden.

Typ B — keine Vorlage: Diese Aufgabe bietet keinerlei Vorlage. Alle Informationen (Systemname „EB-System", Akteur „Kunde", alle Anwendungsfälle) müssen vollständig aus dem Aufgabentext abgeleitet werden. Das Layout muss selbst gewählt werden.

✓ Musterlösung EB-System — vollständig selbst entwickelt

13.5.2 Aufschlüsselung der Lösung

UC
6 Anwendungsfälle: anmelden, Kontostand abfragen, überweisen, Buchungen anzeigen, Buchungen suchen, beenden.
ASSO
Der einzige Akteur Kunde ist mit allen 6 Anwendungsfällen verbunden.
INCL
1 include-Beziehung: „überweisen" inkludiert „Kontostand abfragen". Die Deckungsprüfung ist eine notwendige, immer durchgeführte Voraussetzung.
NOTE
Hier gibt es keine extend-Beziehung. Alle Bedingungen im Text beschreiben entweder einen festen Ablauf (include) oder einfache optionale Aktionen des Kunden (direkte Assoziation).

ABI 2022 C BikeVerwaltung Typ B 8 BE

13.6.1 Aufgabenstellung

Aufgabe 1.7.2 — Typ B (KEINE Vorlage gegeben) Die Fertigungsorganisation soll durch ein Verwaltungssystem erweitert werden. Folgende Funktionalitäten sollen vom System bereitgestellt werden:

– Kunden konfigurieren ihr zukünftiges Bike, das Servicepersonal kann sie dabei unterstützen.
– Das Servicepersonal ist zuständig für die Auslieferung des fertigen Bikes, was voraussetzt, dass das Bike von einer Technikerin bzw. einem Techniker (im Folgenden Techniker genannt) montiert und der Preis vom Servicepersonal ermittelt worden ist.
– Im Montageprozess der Fahrräder wird regelmäßig ein Bike ausgewählt, das ausführlich im Testlabor geprüft wird. Diese Prüfung liegt in der Verantwortung eines Technikers. Sollte sich dabei zeigen, dass eine montierte Komponente des Bikes den hohen Belastungen nicht standhält, wird sie von einem Techniker ausgetauscht.
– Das Unternehmen bietet für seine Bikes auch Zubehör an. Wenn der Kunde Zubehör wünscht, wird die Auslieferung des Bikes um den Anbau von Zubehör erweitert. Dafür ist wiederum ein Techniker zuständig.

Typ B — keine Vorlage: Drei Akteure (Kunde, Servicepersonal, Techniker), mehrere include- und extend-Beziehungen — diese Aufgabe ist die komplexeste der letzten Jahre. Besonders die verschachtelten include-Beziehungen erfordern sorgfältige Analyse des Textes.

✓ Musterlösung BikeVerwaltung — vollständig selbst entwickelt

13.6.2 Aufschlüsselung der Lösung

UC
7 Anwendungsfälle: Bike konfigurieren, Bike ausliefern, Preis ermitteln, Bike montieren, Bike testen, Komponente tauschen, Zubehör anbauen.
ASSO
Kunde: Bike konfigurieren. Servicepersonal: Bike konfigurieren (Unterstützung), Bike ausliefern, Preis ermitteln. Techniker: Bike montieren, Bike testen, Komponente tauschen.
INCL
4 include-Beziehungen: „Bike montieren" inkludiert „Bike konfigurieren" (Montage setzt Konfiguration voraus). „Bike ausliefern" inkludiert „Bike montieren" und „Preis ermitteln" (Schlüsselwort: „was voraussetzt"). „Bike testen" inkludiert „Bike montieren" (Test setzt Montage voraus).
EXT
3 extend-Beziehungen: „Komponente tauschen" erweitert „Bike testen" (Bedingung: Komponente fehlerhaft). „Bike testen" erweitert „Bike montieren" (Bedingung: Bike ausgewählt — nur regelmäßig ein Bike wird getestet). „Zubehör anbauen" erweitert „Bike ausliefern" (Bedingung: Zubehör gewünscht).

ABI 2023 B Taxizentrale Typ C 5 BE

13.7.1 Aufgabenstellung

Aufgabe 1.2 — Typ C (vollständiges Diagramm gegeben, Notationselemente + Inhalt) Kundinnen und Kunden (im Folgenden Kunden genannt) können bei der Taxizentrale telefonisch rund um die Uhr Aufträge für Fahrten, unter Angabe der Start- und Zieladresse, aufgeben. Für die Auftragsabwicklung in der Taxizentrale liegt ein Anwendungsfalldiagramm vor (Material 1).

Beschreiben Sie die wesentlichen Notationselemente des vorliegenden UML-Anwendungsfalldiagramms sowie die Unterschiede zwischen extend- und include-Beziehungen.

Erläutern Sie die inhaltliche Bedeutung des vorliegenden Anwendungsfalldiagramms.

Typ C — beides gefragt: Diese Aufgabe besteht aus zwei Teilaufgaben: (1) Notationselemente beschreiben und Unterschied include/extend erklären, (2) Inhalt des Diagramms erläutern. Das vollständige Diagramm und die Musterlösung dazu sind ausführlich in Abschnitt 10 behandelt. Lese Abschnitt 10 für die detaillierten Musterformulierungen.

Typ C Gegebenes vollständiges Diagramm — Taxizentrale (→ detailliert erklärt in Abschnitt 10)

14 · Häufige Fehler

Diese Punkte kosten oft unnötig BE — besser vorher kennen.

1. Pfeilrichtung bei «extend» vertauscht — der häufigste Fehler

Der «extend»-Pfeil zeigt vom erweiternden Anwendungsfall auf den Basisanwendungsfall. Viele Schüler zeichnen ihn genau umgekehrt — vom Basis auf den Erweiternden. Prüfe nach dem Zeichnen für jede extend-Beziehung: Zeigt der Pfeil auf den UC, der die Erweiterungspunkte enthält? Wenn ja, ist er korrekt.

2. Pfeilrichtung bei «include» vertauscht

Auch bei «include» werden Pfeile oft umgekehrt gezeichnet. Der Pfeil zeigt vom Basisanwendungsfall auf den inkludierten. Merkhilfe: Der Pfeil zeigt in Richtung des UCs, der aufgerufen wird — so wie ein Methodenaufruf.

3. Erweiterungspunkte bei «extend» vergessen

Jede «extend»-Beziehung erfordert zwingend einen Erweiterungspunkt innerhalb des Basisanwendungsfalls (Trennstrich + „extension points" + Bezeichnung). Fehlen sie, ist die Darstellung unvollständig und kostet Punkte.

4. Bedingungsnotiz bei «extend» vergessen

Zur extend-Beziehung gehört immer eine Bedingungsnotiz am Pfeil, die beschreibt, wann die Erweiterung ausgeführt wird. Ohne Bedingung fehlt die semantische Information der extend-Beziehung — und das wird bewertet.

5. Zu wenige Anwendungsfälle — kryptische Formulierungen überlesen

Der Aufgabentext enthält manchmal Anwendungsfälle, die nicht als eigener Aufzählungspunkt formuliert sind — z.B. versteckt als inkludierter UC innerhalb eines Satzes. Lies jeden Satz sorgfältig. Markiere alle Verben, die Funktionen des Systems beschreiben.

6. Keine include/extend — alles als einfache Assoziationen

In jeder Abitur-Aufgabe der letzten Jahre gab es mindestens eine include- und eine extend-Beziehung. Wenn deine Lösung keine davon enthält, hast du mit hoher Wahrscheinlichkeit etwas überlesen. Gehe den Text nochmals durch und suche gezielt nach Muss- und Kann-Formulierungen.

7. Akteur innerhalb der Systemgrenze platziert

Akteure stehen immer außerhalb des Systemrechtecks. Wird ein Akteur versehentlich innen gezeichnet, widerspricht das der UML-Definition — Akteure sind externe Nutzer des Systems.

8. Pfeilspitzen bei Assoziationen eingezeichnet

Die Verbindungslinie zwischen Akteur und Anwendungsfall ist eine einfache Linie ohne Pfeilspitze. Pfeilspitzen sind ausschließlich den «include»- und «extend»-Beziehungen vorbehalten. Eine Assoziation mit Pfeilspitze ist ein Notationsfehler.

9. Tipp: Eigene Checkliste nach dem Zeichnen

Bevor du mit der Aufgabe fertig bist, prüfe systematisch:
✓ Alle Anwendungsfälle aus dem Text vorhanden?
✓ Alle Akteure außerhalb des Rechtecks?
✓ Alle Assoziationen ohne Pfeilspitze?
✓ Alle include-Pfeile in korrekter Richtung (Basis → Inkludiert)?
✓ Alle extend-Pfeile in korrekter Richtung (Erweiternd → Basis)?
✓ Alle Basisanwendungsfälle mit Erweiterungspunkt?
✓ Alle extend-Pfeile mit Bedingungsnotiz?

UML-Anwendungsfalldiagramme zeichnen: Der Abitur-Leitfaden