Übungsaufgaben zum UML-Anwendungsfalldiagramm
https://bildung.social/@oerinformatik/
https://oer-informatik.de/uml-usecase-uebungsaufgaben
UML, Anwendungsfalldiagramm, Use Case, Akteur, Systemgrenze, include, extend, Generalisierung, User Story, Übungsaufgaben, Prüfungsvorbereitung
tl/dr; (Bearbeitungszeit insgesamt 106 min, mehrere Aufgaben): Vier Übungsaufgaben zum UML-Anwendungsfalldiagramm: Notationselemente zuordnen, Signalwörter bestimmen, Diagramme aus Anforderungstexten erstellen, vorgegebene Diagramme ergänzen, einen fehlerhaften Entwurf untersuchen, User Stories aus Anwendungsfällen ableiten und «include», «extend» und Generalisierung begründet einsetzen. Alle Lösungen sind ausgeblendet und mit Punkteverteilung versehen [AI-Assisted]. (Zuletzt geändert am 29.10.2026)
Dieser Artikel ist Teil einer Artikelreihe über Anwendungsfälle: Anwendungsfälle tabellarisch erfassen / Grundlagen des Anwendungsfalldiagramms (Übungsaufgaben) / Anwendungsfalldiagramme mit PlantUML / Kurzübung: Mitfahr-App.
Diese Übungsaufgaben gehören zum Artikel UML-Anwendungsfalldiagramm. Weitere, kürzere Übungen findest Du unter Übungsaufgaben zu UML-Use-Case-Diagrammen; wie Du Anwendungsfälle tabellarisch beschreibst, zeigt der Artikel Anwendungsfälle.
Hinweise zur Bearbeitung: Bis zur Teil-1-Prüfung der IT-Berufe solltest Du die Basiskompetenz beherrschen, also Aufgabe 1.1 und Aufgabe 1.2. Als FIA, IKS oder IKD musst Du zur Teil-2-Prüfung Aufgaben auf Kernkompetenz-Ebene lösen können, das sind Aufgabe 2.1 und Aufgabe 2.2. Zeichne Deine Diagramme auf Papier oder mit einem Werkzeug Deiner Wahl, bevor Du die Beispiellösung aufklappst. Eine saubere Handskizze genügt. Achte auf die Systemgrenze mit Namen, auf die Richtung der gestrichelten Pfeile und darauf, dass jede «extend»-Beziehung eine Bedingung und einen Erweiterungspunkt hat. Du darfst eine Notationsübersicht nutzen:
Andere fachlich richtige Lösungen sind ebenfalls richtig, z. B. abweichende, aber gleichbedeutende Namen für Anwendungsfälle oder eine andere Anordnung der Elemente.
Du möchtest eigene Aufgaben zum Üben von einem KI-Sprachmodell generieren lassen?
Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.
Erstelle neue Übungsaufgaben zum Thema „UML-Anwendungsfalldiagramm“.
Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.
Fachliche Grundlage:
- https://oer-informatik.de/uml-usecase
- https://oer-informatik.de/anwendungsfall
- https://oer-informatik.de/uml-usecase-plantuml
- https://oer-informatik.de/uml-aktivitaetsdiagramm
- Stilbeispiel: https://oer-informatik.de/uml-usecase-uebungsaufgaben
Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- UML
- Anwendungsfalldiagramm
- Use Case
- Akteur
- Systemgrenze
- include
- extend
- Generalisierung
- User Story
Kompetenzstufe: Basiskompetenz (alternativ: Kernkompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan
Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
danach frage.Aufgabe 1.1: Fahrgemeinschaften in der App „RatzFahrt“ (Basiskompetenz)
(ca. 11 min Bearbeitungszeit)
Am Ratz und Rübe Berufskolleg in Bielefeld entwickelt ein Projektteam die Mitfahr-App „RatzFahrt“, mit der Auszubildende Fahrgemeinschaften zu den Berufsschultagen bilden. Jonas Wolff aus dem Projektteam hat begonnen, die Anforderungen als Anwendungsfalldiagramm festzuhalten, und bittet Dich, es fertigzustellen. Andrea Wolf betreut die App als Administratorin. Aus dem Gespräch mit ihr stammen diese Anforderungen:
Nutzende können eine Fahrt anbieten, offene Angebote suchen und eine Mitfahrt anfragen.
Beim Anbieten einer Fahrt und beim Anfragen einer Mitfahrt wird immer das Schulkonto der Person geprüft.
Die Administratorin übernimmt alle Funktionen der Nutzenden und pflegt zusätzlich die Haltepunkte, an denen sich Fahrgemeinschaften treffen. Auch dabei wird immer das Schulkonto geprüft.
- Ordne den Beschreibungen die passenden Notationselemente zu. Trage dazu den Buchstaben des Begriffs in die rechte Spalte ein. Nicht alle Begriffe werden gebraucht. (3 Punkte)
Begriffe: (A) Akteur*in, (B) Aktivität, (C) Anwendungsfall, (D) Assoziation, (E) Generalisierung, (F) «include»-Beziehung, (G) Nachricht, (H) Systemgrenze
| Beschreibung der Darstellung | Begriff |
|---|---|
| Rechteck mit dem Namen des Systems, das alle Anwendungsfälle umschließt | |
| Strichfigur außerhalb des Rechtecks | |
| Ellipse mit einer Tätigkeit wie „Fahrt anbieten“ | |
| durchgezogene Linie ohne Pfeilspitze zwischen Strichfigur und Ellipse | |
| gestrichelter Pfeil mit offener Spitze zwischen zwei Ellipsen, beschriftet mit einem Stereotyp | |
| durchgezogene Linie mit hohler Dreiecksspitze zwischen zwei Strichfiguren |
| Beschreibung der Darstellung | Begriff |
|---|---|
| Rechteck mit dem Namen des Systems, das alle Anwendungsfälle umschließt | (H) Systemgrenze |
| Strichfigur außerhalb des Rechtecks | (A) Akteur*in |
| Ellipse mit einer Tätigkeit wie „Fahrt anbieten“ | (C) Anwendungsfall |
| durchgezogene Linie ohne Pfeilspitze zwischen Strichfigur und Ellipse | (D) Assoziation |
| gestrichelter Pfeil mit offener Spitze zwischen zwei Ellipsen, beschriftet mit einem Stereotyp | (F) «include»-Beziehung |
| durchgezogene Linie mit hohler Dreiecksspitze zwischen zwei Strichfiguren | (E) Generalisierung |
Je richtiger Zuordnung 0,5 Punkte. „Aktivität“ und „Nachricht“ gehören zum Aktivitäts- bzw. Sequenzdiagramm. Ein gestrichelter Pfeil zwischen zwei Anwendungsfällen kann auch eine «extend»-Beziehung sein; welche gemeint ist, verrät erst der Stereotyp an der Linie.
- Ergänze das angefangene Anwendungsfalldiagramm um die fehlenden Akteur*innen, Anwendungsfälle und Beziehungen, sodass alle Anforderungen dargestellt sind. (7 Punkte)
Bewertung:
Anwendungsfälle „Mitfahrt anfragen“, „Haltepunkte pflegen“ und „Schulkonto prüfen“ innerhalb der Systemgrenze: je 1 Punkt (3 Punkte)
Akteurin „Administratorin“ außerhalb der Systemgrenze: 0,5 Punkte
Generalisierung mit hohler Dreiecksspitze an „Nutzende“ („übernimmt alle Funktionen der Nutzenden“): 1 Punkt
Assoziationen Nutzende – „Mitfahrt anfragen“ und Administratorin – „Haltepunkte pflegen“: je 0,5 Punkte (1 Punkt)
drei «include»-Beziehungen von „Fahrt anbieten“, „Mitfahrt anfragen“ und „Haltepunkte pflegen“ zu „Schulkonto prüfen“: je 0,5 Punkte (1,5 Punkte)
Die Administratorin braucht keine eigenen Linien zu „Fahrt anbieten“, „Angebote suchen“ und „Mitfahrt anfragen“: Diese Anwendungsfälle erbt sie über die Generalisierung. „Schulkonto prüfen“ ist ein gemeinsamer Anwendungsfall, den drei Basisfälle immer einbinden; deshalb zeigen alle drei «include»-Pfeile auf dieselbe Ellipse. „Angebote suchen“ bekommt kein «include», weil die Anforderung dort keine Prüfung verlangt.
- Entscheide für jede Aussage, ob sie zu Deinem Diagramm aus b) richtig oder falsch ist. (2 Punkte)
| Aussage | richtig | falsch |
|---|---|---|
| 1. Der «include»-Pfeil zeigt von „Fahrt anbieten“ auf „Schulkonto prüfen“. | ||
| 2. Damit die Administratorin Fahrten anbieten darf, muss sie zusätzlich mit „Fahrt anbieten“ verbunden werden. | ||
| 3. Das Diagramm zeigt, in welcher Reihenfolge die Schritte beim Anbieten einer Fahrt ablaufen. | ||
| 4. Die Flurmonitore, die offene Angebote von RatzFahrt abrufen und anzeigen, können als Akteurin außerhalb der Systemgrenze dargestellt werden. |
Je richtiger Entscheidung 0,5 Punkte:
richtig: «include» zeigt vom Basisfall zum eingebundenen Anwendungsfall („Fahrt anbieten beinhaltet Schulkonto prüfen“).
falsch: Über die Generalisierung erbt die Administratorin alle Anwendungsfälle der Nutzenden. Eine zusätzliche Linie wäre überflüssig.
falsch: Ein Anwendungsfalldiagramm zeigt, was das System für wen leistet, aber keinen Ablauf. Die Reihenfolge der Schritte gehört in ein Aktivitätsdiagramm oder eine Anwendungsfallbeschreibung.
richtig: Akteur*innen können auch andere Systeme oder Geräte sein, mit denen das System zusammenarbeitet. Sie stehen immer außerhalb der Systemgrenze.
Aufgabe 1.2: Reparaturaufträge in der Fahrradwerkstatt (Basiskompetenz)
(ca. 21 min Bearbeitungszeit)
Die CSB-Rad GmbH repariert in ihrer Werkstatt in Bielefeld-Sennestadt auch Fahrräder ihrer Kundschaft. Werkstattleiter Bastian Ludwig möchte die Abläufe in einem Werkstattportal zusammenführen. Bevor die Entwicklung beginnt, sollst Du festhalten, wer das Portal wofür nutzt. Bastian Ludwig beschreibt Dir die Anforderungen so:
„Kundinnen und Kunden melden ihre Reparatur über das Werkstattportal an. Im Portal können sie außerdem den Status ihres Auftrags verfolgen. Dafür müssen sie sich jedes Mal anmelden. Haben sie ihr Passwort vergessen, können sie es bei der Anmeldung zurücksetzen.
Die Werkstattleitung plant die Reparaturaufträge. Dazu gehört immer, den Ersatzteilbestand zu prüfen. Ist ein Ersatzteil nicht vorrätig, wird es über das Bestellsystem des Großhändlers bestellt.
Die Mechanikerinnen und Mechaniker führen die Reparaturen durch. Dazu gehört immer, ein Abnahmeprotokoll zu erstellen. Die Werkstattleitung kann alles, was Mechaniker*innen können.“
- Nenne die vier Akteur*innen, die im Text vorkommen, und gib jeweils an, ob es sich um eine Person bzw. Rolle oder um ein externes System handelt. (3 Punkte)
| Akteur*in | Art |
|---|---|
| Kund*in | Person/Rolle |
| Werkstattleitung | Person/Rolle |
| Mechaniker*in | Person/Rolle |
| Bestellsystem des Großhändlers | externes System |
Je Akteur*in 0,5 Punkte (2 Punkte), richtige Einordnung des Bestellsystems als externes System 1 Punkt. Akteur*innen werden als Rolle benannt, nicht mit dem Namen einer Person: „Werkstattleitung“ statt „Bastian Ludwig“. Das Werkstattportal selbst ist keine Akteurin, sondern das System innerhalb der Systemgrenze.
- Bestimme, welches Notationsmittel die folgenden Formulierungen aus dem Text jeweils nahelegen: Assoziation, Generalisierung, «include» oder «extend». (3 Punkte)
| Formulierung | Notationsmittel |
|---|---|
| 1. „Kundinnen und Kunden melden ihre Reparatur … an“ | |
| 2. „Dafür müssen sie sich jedes Mal anmelden.“ | |
| 3. „Haben sie ihr Passwort vergessen, können sie es … zurücksetzen.“ | |
| 4. „Dazu gehört immer, den Ersatzteilbestand zu prüfen.“ | |
| 5. „Ist ein Ersatzteil nicht vorrätig, wird es … bestellt.“ | |
| 6. „Die Werkstattleitung kann alles, was Mechaniker*innen können.“ |
| Formulierung | Notationsmittel |
|---|---|
| 1. „Kundinnen und Kunden melden ihre Reparatur … an“ | Assoziation (Kund*in – „Reparatur anmelden“) |
| 2. „Dafür müssen sie sich jedes Mal anmelden.“ | «include» („Auftragsstatus verfolgen“ beinhaltet „Anmelden“) |
| 3. „Haben sie ihr Passwort vergessen, können sie es … zurücksetzen.“ | «extend» („Passwort zurücksetzen“ erweitert „Anmelden“) |
| 4. „Dazu gehört immer, den Ersatzteilbestand zu prüfen.“ | «include» („Reparaturauftrag planen“ beinhaltet „Ersatzteilbestand prüfen“) |
| 5. „Ist ein Ersatzteil nicht vorrätig, wird es … bestellt.“ | «extend» („Ersatzteil bestellen“ erweitert „Reparaturauftrag planen“) |
| 6. „Die Werkstattleitung kann alles, was Mechaniker*innen können.“ | Generalisierung (Werkstattleitung erbt von Mechaniker*in) |
Je richtiger Zuordnung 0,5 Punkte. Signalwörter wie „jedes Mal“, „immer“ und „dazu gehört“ sprechen für «include»; „können“, „falls“ und „ist … nicht“ beschreiben eine Bedingung und damit «extend».
- Erstelle für das System „Werkstattportal“ ein UML-Anwendungsfalldiagramm, das alle Anforderungen aus dem Text darstellt. Gib bei «extend»-Beziehungen die Bedingung und den Erweiterungspunkt an. (15 Punkte)
Bewertung:
Systemgrenze mit dem Namen „Werkstattportal“: 1 Punkt
vier Akteur*innen außerhalb der Systemgrenze: je 0,5 Punkte (2 Punkte)
Generalisierung Werkstattleitung → Mechaniker*in: 1 Punkt
neun Anwendungsfälle („Reparatur anmelden“, „Auftragsstatus verfolgen“, „Anmelden“, „Passwort zurücksetzen“, „Reparaturauftrag planen“, „Ersatzteilbestand prüfen“, „Ersatzteil bestellen“, „Reparatur durchführen“, „Abnahmeprotokoll erstellen“): je 0,5 Punkte (4,5 Punkte)
fünf Assoziationen (Kund*in zu „Reparatur anmelden“ und „Auftragsstatus verfolgen“, Werkstattleitung zu „Reparaturauftrag planen“, Mechaniker*in zu „Reparatur durchführen“, Bestellsystem zu „Ersatzteil bestellen“): je 0,5 Punkte (2,5 Punkte)
drei «include»-Beziehungen in richtiger Richtung: je 0,5 Punkte (1,5 Punkte)
zwei «extend»-Beziehungen: je 0,5 Punkte für den Pfeil in richtiger Richtung und 0,75 Punkte für Bedingung und Erweiterungspunkt (2,5 Punkte)
Hinweise:
„Passwort zurücksetzen“ erweitert den eingebundenen Anwendungsfall „Anmelden“, nicht „Auftragsstatus verfolgen“: Die Bedingung „Passwort vergessen“ tritt während der Anmeldung auf. Der Erweiterungspunkt steht deshalb in der Ellipse „Anmelden“.
Eine zusätzliche Assoziation zwischen Werkstattleitung und „Ersatzteil bestellen“ ist ebenfalls richtig. Sie ist aber nicht nötig, weil die Bestellung im Rahmen der Planung stattfindet.
Die Werkstattleitung braucht keine eigene Linie zu „Reparatur durchführen“; diesen Anwendungsfall erbt sie über die Generalisierung.
Bezeichnungen wie „Login“ statt „Anmelden“ oder „Reparaturtermin planen“ sind gleichwertig, solange Objekt und Verb erkennbar sind.
- Bastian Ludwig möchte im Diagramm zusätzlich festhalten, dass ein Auftrag erst geplant und danach repariert wird. Erläutere, warum das Anwendungsfalldiagramm dafür nicht geeignet ist, und nenne eine passende Darstellungsform. (2 Punkte)
Ein Anwendungsfalldiagramm zeigt nur, welche Anwendungsfälle das System für welche Akteur*innen bietet. Es enthält keine zeitliche Reihenfolge; Linien zwischen „Reparaturauftrag planen“ und „Reparatur durchführen“ würden einen Ablauf vortäuschen, den die Notation nicht kennt (1 Punkt). Für die Reihenfolge eignet sich ein UML-Aktivitätsdiagramm, alternativ eine tabellarische Anwendungsfallbeschreibung mit Vor- und Nachbedingungen (1 Punkt).
Aufgabe 2.1: Aktivitäten und Interessengruppen in einer Freizeit-App (Kernkompetenz)
(ca. 38 min Bearbeitungszeit)
Du bist Auszubildende*r im Entwicklungsteam der Let’s Meet GmbH in Bielefeld. Die App „Let’s Meet“ bringt Menschen ab 16 Jahren für gemeinsame Freizeitaktivitäten zusammen: Wandern, Brettspiele, Laufen, Konzerte und vieles mehr. Für das neue Backend sollen die Anforderungen übersichtlich dargestellt werden, damit Geschäftsführerin Clara Neumann, die Datenschutzbeauftragte Dr. Marta Kowalczyk und das Entwicklungsteam vom selben System sprechen. Euer Ausbilder Yusuf Demir übergibt Dir seine Notizen aus dem Anforderungsworkshop:
Mitglieder suchen öffentliche Aktivitäten in ihrer Umgebung. Wer möchte, grenzt die Treffer auf barrierefreie Treffpunkte ein.
Neue Aktivitäten stellt entweder ein Mitglied oder eine Partnerorganisation ein, etwa ein Sportverein oder die Stadtbibliothek. Jede neue Aktivität bekommt in jedem Fall einen öffentlichen Treffpunkt.
Mitglieder nehmen an Aktivitäten teil. Sind alle Plätze vergeben, landet die Anfrage auf der Warteliste. Bei Aktivitäten ab 18 Jahren bestätigt zusätzlich der externe Verifizierungsdienst „IdentOWL“ die Volljährigkeit.
Verhält sich jemand bei einem Treffen daneben, können Mitglieder diese Person melden. Einen Meldegrund wählen sie dabei jedes Mal aus einer Liste aus.
Gemeldete Fälle prüft das Moderationsteam der Let’s Meet GmbH, das selbst kein Mitgliedskonto nutzt. Jede Prüfung wird lückenlos im Verlauf festgehalten. Bei einem schweren Verstoß sperrt das Team zusätzlich das Konto der gemeldeten Person.
Wie sich Mitglieder in der App anmelden (Login), bleibt im Diagramm außen vor.
- Modelliere Yusufs Notizen als UML-Anwendungsfalldiagramm für das System „Let’s Meet“. Kennzeichne eine Akteurin, die nur als Oberbegriff dient, als abstrakt. (24 Punkte)
Wichtige Entscheidungen:
„Entweder ein Mitglied oder eine Partnerorganisation“ stellt eine Aktivität ein: Für dieses Oder brauchst Du eine gemeinsame Akteurin, hier „Veranstaltende“. Nur sie ist mit „Aktivität anlegen“ verbunden; Mitglied und Partnerorganisation erben von ihr. Da es niemanden gibt, der nur „veranstaltend“ ist, wird sie als abstrakt gekennzeichnet (kursiv,
{abstract}).Das Moderationsteam ist eine eigene Akteurin ohne Generalisierung: Es nutzt kein Mitgliedskonto und soll die Anwendungsfälle der Mitglieder gerade nicht erben.
Unbedingt nötig sind der öffentliche Treffpunkt („in jedem Fall“), der Meldegrund („jedes Mal“) und der Verlaufseintrag („jede Prüfung … lückenlos“) → «include», Pfeil zum eingebundenen Fall.
Nur unter einer Bedingung kommen der Barrierefrei-Filter („wer möchte“), die Warteliste („sind alle Plätze vergeben“), die Volljährigkeitsprüfung („bei Aktivitäten ab 18 Jahren“) und die Kontosperre („bei einem schweren Verstoß“) hinzu → «extend», Pfeil zum Basisfall, mit Bedingung und Erweiterungspunkt. „An Aktivität teilnehmen“ hat deshalb zwei Erweiterungspunkte.
IdentOWL ist ein externes System und steht als Akteurin außerhalb der Systemgrenze, verbunden mit „Volljährigkeit nachweisen“. Eine gerichtete Assoziation zum Dienst (sekundäre Akteurin) ist ebenfalls richtig.
Punkteverteilung (Vorschlag):
| Element | Punkte |
|---|---|
| Systemgrenze mit Systemname | 1 |
| 5 Akteur*innen (Veranstaltende, Mitglied, Partnerorganisation, Moderationsteam, IdentOWL) je 0,5 | 2,5 |
| Veranstaltende als abstrakt gekennzeichnet | 0,5 |
| 2 Generalisierungen (Mitglied → Veranstaltende, Partnerorganisation → Veranstaltende) je 1 | 2 |
| 12 Anwendungsfälle je 0,5 | 6 |
| 6 Assoziationen je 0,5 | 3 |
| 3 include-Beziehungen in richtiger Richtung je 1 | 3 |
| 4 extend-Beziehungen in richtiger Richtung je 1 | 4 |
| Bedingung und Erweiterungspunkt je extend 0,5 | 2 |
| Summe | 24 |
Wer Mitglied und Partnerorganisation jeweils mit einer eigenen Linie an „Aktivität anlegen“ hängt, behauptet, dass beide gemeinsam beteiligt sind; dafür entfallen die Punkte für die abstrakte Akteurin, ihre Kennzeichnung und die beiden Generalisierungen. Eine Generalisierung Moderationsteam → Mitglied widerspricht dem Text („nutzt kein Mitgliedskonto“) und gibt Abzug.
- Clara Neumann arbeitet lieber mit User Stories. Erstelle zu den Anwendungsfällen „An Aktivität teilnehmen“ und „Aktivität anlegen“ aus Deinem Diagramm jeweils eine User Story nach dem Muster „Als
möchte ich , damit .“ Berücksichtige dabei die zugehörigen «include»- und «extend»-Beziehungen. (4 Punkte)
„Als Mitglied möchte ich an einer Aktivität teilnehmen, damit ich meine Freizeit gemeinsam mit anderen verbringen kann. Sind alle Plätze vergeben, möchte ich auf die Warteliste kommen, damit ich nachrücken kann. Bei Aktivitäten ab 18 Jahren bestätige ich meine Volljährigkeit über IdentOWL, damit die Altersgrenze eingehalten wird.“
„Als Partnerorganisation möchte ich eine Aktivität anlegen, damit Menschen aus der Umgebung unser Angebot finden. Dabei lege ich immer einen öffentlichen Treffpunkt fest, damit sich alle sicher treffen können.“ (Statt „Partnerorganisation“ ist auch „Mitglied“ als Rolle richtig.)
Punkteverteilung: je User Story 1 Punkt für Rolle, Funktion und Nutzen im richtigen Aufbau, 1 Punkt für die korrekt eingearbeiteten Beziehungen (Warteliste und Volljährigkeitsnachweis nur unter ihrer Bedingung, Treffpunkt in jedem Fall).
- Dein Mit-Azubi Jonas Weber hat für die geplante Funktion „Interessengruppen“ einen ersten Entwurf gezeichnet. Ihm lagen folgende Anforderungen vor:
Mitglieder können Interessengruppen suchen und einer Gruppe beitreten. Mitglieder können außerdem eine Gruppe gründen; sie werden damit zur Gruppenleitung dieser Gruppe.
Gruppenleitungen laden Mitglieder in ihre Gruppe ein. Sie können anonyme Umfragen starten und später auswerten. Haben bei der Auswertung mindestens drei Mitglieder abgestimmt, kann das Ergebnis zusätzlich veröffentlicht werden.
Beiträge in einer Gruppe dürfen von der Gruppenleitung oder von Moderierenden gelöscht werden.
Untersuche den Entwurf. Beschreibe fünf Fehler und gib jeweils an, wie sie richtig modelliert werden. (10 Punkte)
Mögliche Fehler (fünf davon genügen, je 1 Punkt für die Beschreibung, 1 Punkt für die Korrektur):
| Fehler im Entwurf | Richtige Modellierung |
|---|---|
| Die Akteurin „Gruppenleitung“ steht innerhalb der Systemgrenze; sie wäre damit Teil des Systems. | Alle Akteur*innen stehen außerhalb der Systemgrenze. |
| „App öffnen“ → «include» „Login“ → «include» „Gruppen suchen“ bildet einen zeitlichen Ablauf ab (Flussdiagramm). „App öffnen“ hat keinen eigenen Nutzen, der Login sollte laut Vorgabe gar nicht modelliert werden. | „Gruppen suchen“ als eigener Anwendungsfall, direkt mit „Mitglied“ verbunden; „App öffnen“ und „Login“ entfallen. Abläufe gehören in ein Aktivitätsdiagramm. |
| Zwischen „Gruppe“ und „Mitglieder einladen“ steht eine einfache Assoziation (durchgezogene Linie). | Zwischen Anwendungsfällen gibt es nur «include», «extend» oder Generalisierung; hier ist keine Beziehung nötig. |
| Der Anwendungsfall „Gruppe“ ist ein Substantiv und beschreibt keine Tätigkeit mit Nutzen. | Benennung mit Verb: „Gruppe gründen“. |
| Der «extend»-Pfeil zeigt von „Umfrage starten“ zu „Ergebnis veröffentlichen“, also in die falsche Richtung, und der Basisfall ist falsch: Veröffentlicht wird bei der Auswertung. Bedingung und Erweiterungspunkt fehlen. | „Ergebnis veröffentlichen“ «extend» → „Umfrage auswerten“ (Pfeil zum Basisfall), Notiz mit condition {mindestens 3 Stimmen} und extension point, Erweiterungspunkt im Basisfall. |
| „Beitrag löschen“ ist mit Gruppenleitung und Moderatorin verbunden; das bedeutet, dass beide gemeinsam beteiligt sind. Gemeint ist „oder“. | Abstrakte Akteurin (z. B. „Löschberechtigte“) mit Assoziation zu „Beitrag löschen“; Gruppenleitung und Moderatorin werden davon spezialisiert. |
| Anforderungen fehlen: „Gruppe beitreten“ und „Umfrage auswerten“; außerdem fehlt, dass jede Gruppenleitung ein Mitglied ist. | Anwendungsfälle ergänzen; Generalisierung Gruppenleitung → Mitglied. |
Eine mögliche korrigierte Fassung (nicht gefordert):
- Yusuf Demir möchte außerdem festhalten, in welcher Reihenfolge die Schritte beim Anwendungsfall „An Aktivität teilnehmen“ ablaufen (Altersgrenze prüfen, freie Plätze prüfen, Teilnahme speichern oder Warteliste, Benachrichtigung senden). Erläutere, warum das Anwendungsfalldiagramm dafür nicht geeignet ist, und nenne zwei Darstellungsformen, die sich dafür eignen. (4 Punkte)
Das Anwendungsfalldiagramm zeigt, was ein System für welche Akteur*innen leistet (Anwendungsfälle und ihre Beziehungen). Es kennt keine Reihenfolge, keine Verzweigungen und keine Schleifen; «include» und «extend» drücken keine zeitliche Abfolge aus (2 Punkte).
Geeignet sind z. B. (je 1 Punkt, zwei genügen):
ein UML-Aktivitätsdiagramm für den Ablauf des Anwendungsfalls,
eine tabellarische Anwendungsfallbeschreibung mit Vorbedingung, Standardablauf, alternativen Abläufen und Nachbedingung,
ein UML-Sequenzdiagramm, wenn der Nachrichtenaustausch zwischen App, Backend und Datenbank gezeigt werden soll.
Aufgabe 2.2: Call for Participation und Check-in beim Barcamp (Kernkompetenz)
(ca. 36 min Bearbeitungszeit)
Am Ratz und Rübe Berufskolleg (RRB) in Bielefeld findet am 13.03.2027 das Barcamp „Lernen.Digital.Leben 2027“ statt. Das Software-Team der Schüler*innen entwickelt unter der Leitung von Dimitrios Papadopoulos ein Barcamp-Portal und die Software für die Check-in-Terminals. Du bist als Auszubildende*r im Team und übernimmst die Modellierung.
- Ein erster Entwurf des Anwendungsfalldiagramms für das Barcamp-Portal liegt bereits vor:
Im Anforderungsgespräch wurden folgende Punkte festgehalten:
Teilnehmende melden sich zum Barcamp an – entweder mit einem Schulticket (die Schule muss die Teilnahme bestätigen) oder mit einem Gastticket. Bis auf die Bestätigung laufen beide Varianten gleich ab.
Teilnehmende sehen den Sessionplan an und buchen Sessions mit begrenzter Platzzahl.
Referierende können alles, was Teilnehmende können; zusätzlich reichen sie Sessions ein.
Beim Einreichen einer Session verschickt das Portal immer eine Eingangsbestätigung. Dafür nutzt es den Mailing-Dienst der Schul-IT OWL.
Wird für eine Session Unterstützung zur Barrierefreiheit benötigt (z. B. Schriftdolmetschung), geben Referierende beim Einreichen zusätzlich den Unterstützungsbedarf an.
Einreichungen werden vom Orga-Team oder von der Schulleitung bewertet.
Das Orga-Team erstellt den Sessionplan. Dabei wird immer geprüft, ob die Räume barrierefrei sind.
Ergänze das Anwendungsfalldiagramm, sodass alle Anforderungen dargestellt sind. Vorhandene Elemente darfst Du ändern, wenn die Anforderungen das erfordern. (16 Punkte)
Punkteverteilung (Vorschlag):
| Ergänzung | Punkte |
|---|---|
| Abstrakter Anwendungsfall „Zum Barcamp anmelden“ mit Assoziation zu Teilnehmende (1 + 0,5), zwei spezialisierte Anwendungsfälle (je 0,5), zwei Generalisierungen zwischen Anwendungsfällen (je 0,5) | 3,5 |
| Generalisierung Referierende → Teilnehmende | 1 |
| „Eingangsbestätigung senden“ (0,5) mit «include» (1), Akteurin Mailing-Dienst (1) mit Assoziation (0,5) | 3 |
| „Unterstützungsbedarf angeben“ (0,5) mit «extend» (1), Bedingung und Erweiterungspunkt (1) | 2,5 |
| Abstrakte Akteurin „Bewertende“ (1), Akteurin Schulleitung (1), zwei Generalisierungen (je 0,5), Assoziation von Bewertende statt Orga-Team zu „Einreichung bewerten“ (0,5) | 3,5 |
| „Sessionplan erstellen“ mit Assoziation zum Orga-Team (0,5 + 0,5), „Barrierefreiheit der Räume prüfen“ (0,5) mit «include» (1) | 2,5 |
| Summe | 16 |
Hinweise: Die Assoziation „Orga-Team – Einreichung bewerten“ aus der Vorgabe muss entfallen, sonst wäre das Orga-Team zusätzlich zu einer bewertenden Person beteiligt. Statt eines abstrakten Anwendungsfalls „Zum Barcamp anmelden“ ist auch ein einzelner Anwendungsfall „Zum Barcamp anmelden“ mit einem erweiternden Fall „Teilnahme durch Schule bestätigen“ (condition {Schulticket}) vertretbar; die Generalisierung bildet „gleicher Ablauf, verschiedene Varianten“ aber genauer ab.
- Für die Dokumentation sollst Du einige Modellierungsentscheidungen erläutern.
ba) Begründe, warum der Mailing-Dienst der Schul-IT OWL als Akteurin außerhalb der Systemgrenze dargestellt wird, und beschreibe, wie Du im Diagramm kennzeichnen kannst, dass der Mailing-Dienst nur vom Portal angesprochen wird und den Anwendungsfall nicht selbst auslöst. (3 Punkte)
Akteur*innen sind alle Personen und Systeme, die mit dem modellierten System interagieren, aber nicht dazugehören. Der Mailing-Dienst wird von der Schul-IT OWL betrieben und vom Portal nur genutzt; er wird nicht im Projekt entwickelt und liegt deshalb außerhalb der Systemgrenze (2 Punkte).
Kennzeichnung: gerichtete Assoziation vom Anwendungsfall „Eingangsbestätigung senden“ zum Mailing-Dienst (Pfeilspitze beim Dienst). Der Dienst ist damit sekundäre Akteurin, die Referierenden sind die primären, auslösenden Akteur*innen (1 Punkt). Alternativ ist eine Darstellung als Rechteck mit dem Schlüsselwort «actor» bzw. «system» möglich, um zu zeigen, dass es sich nicht um einen Menschen handelt.
bb) (Expertenwissen) Einreichungen werden in einer gemeinsamen Sitzung von mindestens zwei Bewertenden bewertet. Jede bewertende Person kann an beliebig vielen Bewertungen teilnehmen. Gib an, wie Du diese Information im Diagramm notierst. (2 Punkte)
Mit Multiplizitäten an der Assoziation zwischen „Bewertende“ und „Einreichung bewerten“: auf der Seite der Akteurin 2..* (an einer Bewertung sind mindestens zwei Bewertende beteiligt), auf der Seite des Anwendungsfalls * bzw. 0..* (eine bewertende Person nimmt an beliebig vielen Bewertungen teil). Je richtige Multiplizität an der richtigen Seite 1 Punkt.
- Am Veranstaltungstag checken Helfende die Teilnehmenden im Foyer an zwei Check-in-Terminals ein. Für die Terminal-Software gelten folgende Anforderungen:
Helfende checken Teilnehmende am Terminal ein. Jedes Einchecken endet mit einem gedruckten Namensschild (Badge) mit QR-Code.
Fehlt aus der Anmeldung zum Barcamp die Angabe zur Fotoeinwilligung, holt die helfende Person sie beim Einchecken nach.
Bleibt ein Terminal zehn Minuten unbenutzt, sperrt es sich. Wer danach jemanden einchecken will, entsperrt es zuerst mit der persönlichen PIN.
Die Schichtleitung kann alle Aufgaben der Helfenden übernehmen. Nur sie gibt Ersatzbadges für verlorene Namensschilder aus; auch dabei wird ein Badge gedruckt. Außerdem ruft sie die Tagesstatistik ab.
Ersatzbadge und Tagesstatistik gibt das Terminal erst frei, wenn die Schichtleitung ihre Leitungskarte (NFC) auflegt – bei jedem einzelnen Vorgang.
Modelliere die Anforderungen als UML-Anwendungsfalldiagramm für das System „Check-in-Terminal“. Das Entsperren mit PIN und die Freigabe mit der Leitungskarte erscheinen jeweils als eigener Anwendungsfall. (15 Punkte)
Punkteverteilung (Vorschlag):
| Element | Punkte |
|---|---|
| Systemgrenze mit Systemname | 1 |
| 2 Akteur*innen je 1 | 2 |
| Generalisierung Schichtleitung → Helfende | 1 |
| 7 Anwendungsfälle je 0,5 | 3,5 |
| 3 Assoziationen (Helfende – Einchecken, Schichtleitung – Ersatzbadge, Schichtleitung – Tagesstatistik) je 0,5 | 1,5 |
| 4 include-Beziehungen (Einchecken → Badge drucken, Ersatzbadge → Badge drucken, Ersatzbadge → Freigabe, Tagesstatistik → Freigabe) je 0,75 | 3 |
| 2 extend-Beziehungen (Fotoeinwilligung → Einchecken, Entsperren → Einchecken) je 1 | 2 |
| Bedingung und Erweiterungspunkt je extend 0,5 | 1 |
| Summe | 15 |
Der Badge-Drucker gehört zum Terminal und ist deshalb keine eigene Akteurin. Wer ihn trotzdem als externes Gerät außerhalb der Systemgrenze modelliert und mit „Badge drucken“ verbindet, bekommt dafür keinen Abzug. Die Schichtleitung braucht keine eigene Linie zu „Teilnehmende einchecken“, weil sie diesen Anwendungsfall über die Generalisierung erbt; umgekehrt erben die Helfenden nichts von der Schichtleitung und sind deshalb nicht mit „Ersatzbadge ausgeben“ verbunden.
- Dimitrios Papadopoulos hat zwei Änderungswünsche an Deinem Diagramm:
„Jede Schicht beginnt doch mit dem Entsperren. Hänge ‚Terminal mit PIN entsperren‘ deshalb per «include» an ‚Teilnehmende einchecken‘.“
„Die Leitungskarte hat nur die Schichtleitung. ‚Mit Leitungskarte freigeben‘ ist also ein Sonderfall und gehört per «extend» an die beiden Basisfälle.“
Beurteile beide Vorschläge und begründe, ob Du sie übernimmst. (4 Punkte)
Erster Vorschlag: nicht übernehmen. Entsperrt werden muss nur, wenn sich das Terminal nach zehn Minuten Leerlauf gesperrt hat; im laufenden Betrieb wird ohne PIN eingecheckt. „Teilnehmende einchecken“ ist also auch ohne Entsperren vollständig, das Entsperren kommt nur unter einer Bedingung hinzu → «extend» mit Bedingung und Erweiterungspunkt. Dass eine Schicht mit dem Entsperren beginnt, beschreibt eine zeitliche Reihenfolge, und die zeigt ein Anwendungsfalldiagramm ohnehin nicht (2 Punkte).
Zweiter Vorschlag: nicht übernehmen. Die Freigabe ist bei jedem Ersatzbadge und jedem Abruf der Tagesstatistik nötig; ohne sie sind beide Basisfälle nicht durchführbar → «include». Wer die Karte besitzt, regelt die Assoziation zur Akteurin „Schichtleitung“, nicht eine Bedingung im Ablauf (2 Punkte).
Links und weitere Informationen
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Übungsaufgaben zum UML-Anwendungsfalldiagramm” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/uml-usecase-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/uml/uml-diagramme. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 29.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
