UML Use-Case-Übungsaufgabe: Mitfahr-App

https://bildung.social/@oerinformatik/112084338768562808

https://oer-informatik.de/uml-usecase-uebung

Anwendungsfalldiagramm, UML, Use Case, Akteur, Generalisierung, include, extend, Erweiterungspunkt, Mitfahr-App, Übungsaufgaben, Prüfungsvorbereitung

tl/dr; (Bearbeitungszeit insgesamt 33 min, mehrere Aufgaben): Zwei Übungsaufgaben, in denen Du aus einer Anforderungsbeschreibung ein Use-Case-Diagramm erstellst: eine Such-App für Übungsaufgaben und eine Mitfahr-App. Die Aufgaben nutzen die Notationsvielfalt der UML, entsprechende Kenntnisse sind also vorausgesetzt [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.

Hier findest Du zwei Übungsaufgaben zu Use-Case-Diagrammen (mit ausgeblendeten Beispiellösungen). Wenn Du die Notationen des Use-Case-Diagramms kennst, kannst Du Dich an die folgenden Aufgaben wagen.

Wortwolke zu den Übungsaufgaben mit Begriffen wie Anwendungsfalldiagramm, Akteur*in, Systemgrenze, Generalisierung, include und extend (mit KI erstellt)

Hinweise zur Bearbeitung: 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 Dein Diagramm 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, darauf, dass „oder“-Beziehungen über Generalisierung modelliert werden, auf die Richtung der gestrichelten Pfeile und darauf, dass jede «extend»-Beziehung eine Bedingung und einen Erweiterungspunkt hat. Andere fachlich richtige Lösungen sind ebenfalls richtig.

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 Use-Case-Übungsaufgabe:
Mitfahr-App“.

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/uml-usecase-plantuml
- https://oer-informatik.de/anwendungsfall
- Stilbeispiel: https://oer-informatik.de/uml-usecase-uebung

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Anwendungsfalldiagramm
- UML
- Use Case
- Akteur
- Generalisierung
- include
- extend
- Erweiterungspunkt
- Mitfahr-App

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, 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 2.1: Such-App für Übungsaufgaben (Kernkompetenz)

(ca. 13 min Bearbeitungszeit)

Für einen Dienstleister, der Prüfungsvorbereitungs-Seminare anbietet, soll eine Web-App erstellt werden, mithilfe derer Übungsaufgaben aus früheren Prüfungen der IT-Berufe gefunden werden können. Hierbei sollen nicht die Aufgaben selbst, sondern nur der Fundort der Aufgabe ausgegeben werden (z. B. „Übungsprüfung 3, Teil 1, 4. Aufgabe“). Die Inhalte der App werden von Moderierenden erstellt und von angemeldeten Benutzer*innen gelesen.

Einzelne Prüfungen werden von Moderierenden mit Namen und Prüfungsart erfasst und bearbeitet (z. B. „Übungsprüfung 5, Teil 2 Anwendungsentwicklung“).

Die jeweiligen Prüfungsthemen werden in einer Baumstruktur (Themenbaum) gegliedert, diese werden von Moderierenden erfasst und bearbeitet (z. B. „UML Sequenzdiagramm“, „Relationenmodell erstellen“, …).

Aufgaben einer Prüfung (z. B. deren Stichwörter) werden von Moderierenden erfasst und bearbeitet. Das beinhaltet immer das Einhängen der Aufgabe in den hierarchischen Themenbaum (ggf. an mehreren Stellen). (z. B. Aufgabe „3c“ der „Übungsprüfung 5, Teil 2 Anwendungsentwicklung“ betrifft die Themen „Sortieralgorithmen“ und „Struktogramm“).

Angemeldete Benutzer*innen (dazu gehören auch Moderierende) sollen die Möglichkeit haben, sich über eine Suche nach Stichwörtern eine Liste mit Aufgaben ausgeben zu lassen (z. B. alle Aufgaben zu „Normalisierung“). Wenn angemeldete Benutzer*innen über den Themenbaum navigieren, wird die Suchfunktion erweitert um die Filterung auf Einträge, die in der ausgewählten Struktur liegen. Habe ich beispielsweise im Themenbaum den Eintrag „UML“ ausgewählt, so werden nur Suchergebnisse angezeigt, die „UML“ betreffen.

Wenn Benutzer*innen nicht angemeldet sind, werden sie als Gast geführt. Gäste haben als einzigen Anwendungsfall die Möglichkeit, sich ein (kostenpflichtiges) Konto zu erstellen.

Für das Login ist keine Modellierung eines eigenständigen Anwendungsfalls erforderlich.

Sofern Daten „erfasst und bearbeitet“ werden, so soll „erfassen“ und „bearbeiten“ nicht als einzelne, sondern als ein gemeinsamer Anwendungsfall betrachtet werden.

a) Erstelle zu den oben genannten Anforderungen ein UML-Anwendungsfalldiagramm. (14 Punkte)

Eine Beispiellösung könnte etwa so aussehen:

UML-Use-Case-Diagramm zur Such-App für Übungsaufgaben

Punkteverteilung:

  • Systemgrenze mit Namen: 1 P

  • 3 Akteur*innen: 1,5 P

  • Generalisierung Moderierende → Angemeldete Benutzer*innen: 1 P

  • 7 Anwendungsfälle: 3,5 P

  • 5 Assoziationen: 2,5 P

  • «include» Aufgaben erfassen → Aufgaben in Themenbaum einhängen: 1,5 P

  • «extend» Filtern → Suche: 1,5 P

  • Erweiterungspunkt und Notiz mit Bedingung: 1,5 P

Hinweise, häufige Fehler:

  • Ein häufiger Fehler ist es, den Usecase „Suche nach Aufgaben“ mit Assoziationen zu zwei Akteuren (Angemeldete Benutzer*innen und Moderierende) zu versehen. So würden beide benötigt, um ausgeführt werden zu können. Das ist eine falsche ODER-Implementierung, korrekt muss diese mit Vererbung umgesetzt werden.

  • Usecases haben keine einfachen Assoziationen untereinander und dürfen somit nicht mit Linien verbunden werden. Ausnahmen bilden include, extend und Vererbung.

  • Die Assoziationen zwischen Usecases und Akteuren haben nur in Ausnahmen Pfeilspitzen. Üblicherweise nutzt man diese nur, wenn bei sekundären Akteuren die Navigationsrichtung relevant ist. (Pfeilspitzen gibt es bei Beziehungen von Usecases untereinander, z. B. Vererbung (geschlossen) und include/extend (offen)).

  • Das Use-Case-Diagramm ist kein Flussdiagramm. Es werden also keine zeitlich/logischen Abfolgen modelliert (also nicht z. B. „erst Login, dann Suche als angemeldeter Nutzer, dann Ergebnis filtern“). Es werden nur Anwendungsfälle verknüpft, deren Szenarien ineinandergreifen. Flussdiagramme werden in der UML mit dem Aktivitätsdiagramm modelliert.

Aufgabe 2.2: Mitfahr-App (Kernkompetenz)

(ca. 20 min Bearbeitungszeit)

Es sollen mithilfe eines UML-Anwendungsfalldiagramms die folgenden funktionalen Anforderungen an eine Mitfahr-App beschrieben werden:

Mithilfe dieser App sollen alle die Möglichkeit haben, nach Mitfahrgelegenheiten zu suchen und sich diese anzeigen zu lassen. Das System „Mitfahr-App“ soll daher die folgenden Anforderungen umsetzen:

  • Alle Nutzenden (Gäste und angemeldete Benutzer*innen) sollen in der Lage sein, mithilfe einer Suchmaske Mitfahrangebote angezeigt zu bekommen.

  • Gäste sollen in der Lage sein, sich am System über eine Login-Maske anzumelden.

  • Für den Fall, dass die Gäste noch über kein Konto verfügen, sollen sie über die Neukunden-Registrierung ein eigenes Benutzerkonto erstellen können.

  • Angemeldete Benutzer*innen können Anfragen an Anbieter*innen von Mitfahrgelegenheiten senden. Das beinhaltet immer, dass sie mit einer Captcha-Nachfrage bestätigen, kein Bot zu sein.

  • Premium-Benutzer*innen (bspw. per kostenpflichtigem Abo) dürfen alles, was auch angemeldete Benutzer*innen dürfen.

  • Premium-Benutzer*innen können Anzeigen für Mitfahrgelegenheiten im System aufgeben, um so nach Mitfahrenden zu suchen.

  • Premium-Benutzer*innen können auf Anfragen von Mitfahrenden reagieren.

  • Admins können alles, was auch angemeldete Benutzer*innen dürfen.

  • Admins können zusätzlich noch Stammdaten bearbeiten. Hierfür müssen sie ihre Identität nachweisen, indem sie ein Captcha lösen und sich mit einem zweiten Faktor authentifizieren, sofern sie das in dieser Session noch nicht gemacht haben.

  • Die Identitätsprüfung ist eine spezielle Form des Captcha-Nachweises, die zusätzlich einen zweiten Faktor (2FA) abfragt.

  • Premium-Nutzende können gemeinsam mit angemeldeten Benutzer*innen eine gegenseitige Bewertung erstellen.

  • Die Anwendungsfälle Anfragen, Antworten, Anbieten und Stammdaten bearbeiten beinhalten immer, dass die Oberfläche gemäß der Einstellungen des Profils individualisiert werden kann (und entsprechende Einstellungen automatisch gespeichert werden).

a) Erstelle zu den oben genannten Anforderungen ein UML-Anwendungsfalldiagramm. (22 Punkte)

Eine Beispiellösung könnte etwa so aussehen:

UML-Use-Case-Diagramm zur Mitfahr-App

Punkteverteilung:

  • Systemgrenze mit Namen: 1 P

  • 5 Akteur*innen (davon eine abstrakte): 2,5 P

  • 4 Generalisierungen zwischen Akteur*innen: 2 P

  • 11 Anwendungsfälle: 5,5 P

  • 8 Assoziationen: 4 P

  • 5× «include»: 2,5 P

  • 2× «extend» mit Erweiterungspunkt und Bedingung: 3 P

  • Generalisierung Identitätsprüfung → Captcha: 1,5 P

Hinweise:

  • Ein häufiger Fehler sind die „Oder“-Beziehungen (Akteur*in A oder Akteur*in B kann XY machen): diese müssen immer mit Vererbung gelöst werden. Zwei eingehende Kanten bei Usecases, die von Akteuren kommen, bedeuten „Und“! (siehe: Premium Benutzer*in UND angemeldete Benutzer*in können sich bewerten)

  • Usecases sollten eigentlich aus sich heraus einen Nutzen für Benutzer*innen produzieren. Bei den Usecases „Per Captcha nachweisen, kein Bot zu sein“ und „Überprüfung der Identität“ ist das fraglich.


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: “UML Use-Case-Übungsaufgabe: Mitfahr-App” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/uml-usecase-uebung 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]

Kommentare gerne per Mastodon, Verbesserungsvorschläge per gitlab issue (siehe oben). Beitrag teilen: