Übungsaufgaben zum UML-Zustandsdiagramm

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-Zustandsdiagramm“.

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-zustandsdiagramm
- https://oer-informatik.de/geschaeftsprozess-ui-states-entwerfen
- https://oer-informatik.de/uml-zustandsdiagramm-plantuml
- Stilbeispiel: https://oer-informatik.de/uml-zustandsdiagramm-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- UML
- Zustandsdiagramm
- Transition
- Guard
- Zeitereignis
- Historie
- Innere Transition
- Zustandsautomat

Kompetenzstufe: Profilkompetenz (alternativ: Basiskompetenz, Kernkompetenz, 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.

Punkteverteilung:

• Startzustand mit Transition zu „Anzeige aktiv“ und Endzustand nach ausschalten aus dem Ruhebetrieb: 1 Punkt,

• at(18:00) und at(06:30) als absolute Zeitereignisse zwischen „Anzeige aktiv“ und „Ruhebetrieb“: 2 Punkte,

• innere Transition minutentakt / angeboteLaden() in „Anzeige aktiv“: 2 Punkte,

• verbindungVerloren und verbindungDa zwischen „Anzeige aktiv“ und „gestört“, entry / stoerhinweisAnzeigen() in „gestört“: 2 Punkte,

• drei Transitionen wartungStarten nach „Wartung“: 2 Punkte (alternativ: „Anzeige aktiv“, „Ruhebetrieb“ und „gestört“ in einem zusammengesetzten Zustand mit einer gemeinsamen Transition wartungStarten),

• wartungBeenden zu einer choice mit den guards [uhrzeit >= 06:30 und uhrzeit < 18:00] und [else]: 3 Punkte. Zwei Transitionen mit demselben Trigger und sich ausschließenden guards direkt aus „Wartung“ sind ebenfalls richtig.

Typische Fehler: Zeitpunkte mit after(…) statt at(…) modellieren (after misst die Dauer seit Betreten des Zustands); das Neuladen als Selbsttransition zeichnen (dann würde bei jedem Takt die entry-Aktivität erneut den Monitor einschalten); die Uhrzeit als Trigger statt als guard an die choice schreiben; den [else]-Zweig vergessen.

Ablauf: 17:55 Uhr verbindungVerloren → „gestört“. Um 18:00 Uhr tritt at(18:00) ein, aber in „gestört“ gibt es dafür keine Transition – das Ereignis verfällt. 18:05 Uhr verbindungDa → „Anzeige aktiv“. Um 18:10 Uhr ist der Player also „Anzeige aktiv“ (1 Punkt).

Problem: Der Monitor bleibt die ganze Nacht eingeschaltet, weil das nächste at(18:00) erst am folgenden Abend eintritt (1 Punkt).

Änderung (2 Punkte), z. B.: Nach verbindungDa entscheidet wie nach der Wartung eine choice anhand der Uhrzeit, ob der Player in „Anzeige aktiv“ oder in den „Ruhebetrieb“ wechselt:

Alternativ: zusätzliche Transition at(18:00) von „gestört“ in den „Ruhebetrieb“ (der Player zeigt dann aber bis 6:30 Uhr nicht an, ob die Verbindung wieder steht). Ein Änderungsereignis when(uhrzeit >= 18:00) in „Anzeige aktiv“ statt at(18:00) hilft dagegen nicht: Es tritt nur ein, wenn die Bedingung von falsch zu wahr wechselt (UML 2.5.1, Abschnitt 13.3.3) – das geschieht um 18:00 Uhr, während der Player „gestört“ ist, und beim Betreten von „Anzeige aktiv“ um 18:05 Uhr ist die Bedingung schon wahr.

Bei einer inneren Transition bleibt der Player im Zustand, exit- und entry-Aktivitäten werden nicht ausgeführt; es wird nur angeboteLaden() aufgerufen (1 Punkt). Bei einer Selbsttransition würde der Zustand verlassen und neu betreten, sodass jede Minute erneut monitorEin() ausgeführt würde – unnötig und im Diagramm missverständlich (1 Punkt).

Punkteverteilung (18 Punkte):

• 5 Zustände, je 1 P (5 P): offen, bestätigt, ausgebucht, abgesagt, stattgefunden.

• 3 entry-Aktivitäten, je 1 P (3 P): Bestätigung an alle senden (bestätigt), Absage an alle senden (abgesagt), Bewertung freischalten (stattgefunden).

• Startzustand mit Effekt / teilnehmende := 1 und zwei Transitionen zum Endzustand mit after(14 Tage) und Effekt (2 P).

• 16 Transitionen bzw. innere Transitionen mit vollständiger Beschriftung, je 0,5 P (8 P):

  • offen: Anmelden unter bzw. ab der Mindestzahl (2), Abmelden (1), Absagen (1), at(beginn - 24 h) (1),

  • bestätigt: Anmelden unter bzw. bei der Höchstzahl (2), Abmelden ab bzw. unter der Mindestzahl (2), Absagen (1), at(ende) (1),

  • ausgebucht: Anmelden auf die Warteliste (1), Abmelden mit bzw. ohne Warteliste (2), Absagen (1), at(ende) (1).

Hinweise zur Bewertung:

• Der guard wird vor dem Effekt geprüft. Deshalb steht dort teilnehmende + 1 bzw. teilnehmende - 1. Gleichwertig ist z. B. anmelden [teilnehmende = min - 1] statt [teilnehmende + 1 >= min]. Wer die Zähleränderung zuerst als Effekt notiert und dann über eine choice entscheidet, erhält ebenfalls die volle Punktzahl, sofern ein [else]-Zweig vorhanden ist.

• Die Zählertransitionen, die im Zustand bleiben, dürfen auch als Selbsttransitionen gezeichnet werden. Dann würde in „bestätigt“ aber bei jeder An- und Abmeldung erneut die entry-Aktivität ausgeführt und allen eine Bestätigung geschickt – das widerspricht der Beschreibung. In diesem Fall 0,5 P Abzug.

• Die drei Transitionen absagen dürfen durch einen zusammengesetzten Zustand (z. B. „anstehend“ mit offen, bestätigt und ausgebucht) und eine einzige Transition ersetzt werden.

• Bei at(beginn - 24 h) ist auch when(jetzt = beginn - 24 h) richtig. Ein guard [teilnehmende < min] ist nicht nötig, weil die Transition nur aus „offen“ führt.

• Typische Fehler: Tätigkeiten als Zustände („Aktivität absagen“), guard an der Starttransition, Lücken bei den Grenzwerten (z. B. [teilnehmende < min] und [teilnehmende > min] – was passiert genau bei min?), Transition aus dem Endzustand, fehlende Transition von „ausgebucht“ nach „stattgefunden“.

Nach dem Anlegen: offen, teilnehmende = 1, Warteliste 0.

Je Zeile 0,5 P. Bei Ereignis 7 wird „bestätigt“ über eine externe Transition neu betreten; deshalb läuft die entry-Aktivität erneut und alle erhalten noch einmal eine Bestätigung. Ob das gewünscht ist, sollte mit Clara Neumann geklärt werden – das Modell macht diese Folge der Beschreibung sichtbar.

Je richtigem Testfall 1 P, zum Beispiel:

Ebenfalls richtig: absagen → abgesagt (Absage an alle) oder Erreichen des Endes (at(ende)) → stattgefunden (Bewertung freigeschaltet). Die Testfälle 2 und 4 prüfen genau die Grenzwerte, an denen der Zustand wechselt – solche Grenzwerttests decken die häufigsten Fehler auf (z. B. < statt <=).

Je Fehler 1 P für die Beschreibung und 1 P für die Korrektur:

1. „Konto sperren“ ist eine Tätigkeit, kein Zustand. Außerdem fehlt der Hinweis an die Person. Korrektur: Zustand „gesperrt“ mit entry / sperrhinweisSenden() (alternativ als Effekt an der Transition sperren / sperrhinweisSenden()).

2. Die choice hat keinen [else]-Zweig. Ist die Person jünger als 16, gibt es keinen Ausgang; das System bliebe im Pseudozustand hängen. Korrektur: zweiter Zweig [else] / kontoLoeschen() zum Endzustand.

3. Zweiter Startzustand mit Trigger: Auf einer Ebene darf es nur einen Startzustand geben, und an der Starttransition steht kein Trigger. Das Wiederherstellen ist ein Übergang aus „gelöscht“. Korrektur: zweiten Startzustand entfernen, Transition wiederherstellen von „gelöscht“ nach „aktiv“.

4. Trigger und Effekt sind vertauscht: anonymisieren() / after(30 Tage) würde bedeuten, dass ein Ereignis „anonymisieren“ den Übergang auslöst und als Wirkung 30 Tage gewartet wird. Korrektur: after(30 Tage) / anonymisieren().

Für Expert*innen: Strenggenommen würde ein gesperrtes Konto nach Löschen und Wiederherstellen wieder „aktiv“ – die Sperre ließe sich so umgehen. Abhilfe: „aktiv“ und „gesperrt“ in einem zusammengesetzten Zustand zusammenfassen, die Transition loeschen an dessen Rand hängen und beim Wiederherstellen in die Historie (H) zurückkehren. Das wird hier nicht bewertet.

Punkteverteilung (20 Punkte):

• 4 neue Zustände, je 1 P (4 P): Tagesplan, Hinweis, offline, Energiesparen.

• 5 innere Aktivitäten, je 0,5 P (2,5 P): Tagesplan entry, Hinweis entry, offline entry und do, Energiesparen entry.

• Sessionanzeige ↔︎ Tagesplan: tasteKurz hin und zurück sowie after(30 s) (3 P).

• Hinweis: zwei Transitionen hinweis(text) aus Sessionanzeige und Tagesplan (1 P), Quittieren mit tasteKurz / quittungSenden() (1 P).

• innere Transition planGeaendert / anzeigeAktualisieren() in der Sessionanzeige (1 P).

• innere Transition takt / akkustandSenden() am zusammengesetzten Zustand „im Betrieb“ (1 P).

• verbindungVerloren vom Rand des zusammengesetzten Zustands nach „offline“ (1,5 P).

• Rückkehr verbunden in die flache Historie (H) mit Standard-Unterzustand Sessionanzeige (2 P).

• when(akkustand < 10) nach „Energiesparen“ und ladekabelEingesteckt nach „verbindend“ (2 P).

• tasteLang / beimBrokerAbmelden() zum Endzustand (1 P).

Hinweise zur Bewertung:

• Transitionen, die für alle Unterzustände gelten (verbindungVerloren, when(akkustand < 10), tasteLang, takt), gehören an den Rand des zusammengesetzten Zustands. Wer sie einzeln an alle drei Unterzustände zeichnet, erhält die Punkte ebenfalls, wenn keine fehlt.

• Ohne Historie würde das Türschild nach einem Verbindungsabbruch immer in der Sessionanzeige beginnen. Das widerspricht „zeigt die Anzeige, die zuletzt aktiv war“. Tiefe Historie (H*) ist hier ebenfalls richtig, weil es nur eine Ebene gibt.

• Statt when(akkustand < 10) ist auch ein Trigger mit guard richtig, z. B. takt [akkustand < 10] als externe Transition – dann wird nur einmal pro Minute geprüft.

• Wer die entry-Aktivität von Energiesparen in zwei Zeilen aufteilt, erhält die Punkte ebenfalls.

Unterschied (2 P): Bei der Selbsttransition wird der Zustand verlassen und neu betreten. Die entry-Aktivität tagesplanAnzeigen() läuft erneut, und das Zeitereignis after(30 s) beginnt neu zu zählen, weil es ab dem Betreten des Zustands misst. Bei der inneren Transition bleibt der Zustand aktiv: Es läuft nur die angegebene Aktion, entry wird nicht ausgeführt, und die 30 Sekunden laufen weiter.

Begründung (2 P), beide Entscheidungen sind mit passender Begründung richtig, zum Beispiel:

• Innere Transition: Die Person soll nach 30 Sekunden wie gewohnt zur Sessionanzeige zurückkommen; eine Planänderung, die sie gar nicht ausgelöst hat, soll die Anzeigezeit nicht verlängern. Bei mehreren Änderungen kurz hintereinander bliebe der Tagesplan sonst beliebig lange stehen.

• Selbsttransition: Nach einer Änderung soll die Person den neuen Plan vollständig 30 Sekunden lang lesen können; außerdem wird die Anzeige ohnehin über entry neu aufgebaut, eine zweite Aktion ist nicht nötig.

Punkte: Zustände der Schritte 1–7 je 0,5 P (3,5 P); Historie in Schritt 2 (Tagesplan statt Sessionanzeige) und Reihenfolge Effekt vor entry in Schritt 7 (1,5 P).

Hinweis: In Schritt 6 ginge die Planänderung „verloren“. Spätestens beim nächsten Betreten der Sessionanzeige wird über entry der aktuelle Stand angezeigt – das ist hier ausreichend, sollte aber bewusst entschieden werden.

            case TAGESPLAN:
                if (e == Ereignis.TASTE_KURZ || e == Ereignis.TIMEOUT_30S) {
                    stoppeTimer();
                    wechsleZu(Zustand.SESSIONANZEIGE);
                } else if (e == Ereignis.HINWEIS) {
                    stoppeTimer();
                    hinweistext = text;
                    wechsleZu(Zustand.HINWEIS);
                }
                break;
            case HINWEIS:
                if (e == Ereignis.TASTE_KURZ) {
                    quittungSenden();                    // Effekt der Transition
                    wechsleZu(Zustand.SESSIONANZEIGE);
                }
                break;

Punkteverteilung (6 Punkte):

• TAGESPLAN: Rückkehr zur Sessionanzeige bei TASTE_KURZ oder TIMEOUT_30S (2 P), Hinweis mit Übernahme des Textes und Wechsel nach HINWEIS (1 P), break (0,5 P).

• HINWEIS: bei TASTE_KURZ zuerst quittungSenden(), dann wechsleZu(Zustand.SESSIONANZEIGE) (2 P), break (0,5 P).

Hinweise zur Bewertung:

• stoppeTimer() ist nicht verlangt, verhindert aber, dass ein alter Timer später ein TIMEOUT_30S auslöst, obwohl das Türschild den Tagesplan schon verlassen hat. Wer stattdessen begründet, dass TIMEOUT_30S außerhalb von TAGESPLAN ohnehin ignoriert wird, liegt ebenfalls richtig – allerdings nur, solange das Türschild nicht innerhalb der 30 Sekunden erneut in den Tagesplan wechselt.

• Ohne break würde der Fall TAGESPLAN in HINWEIS „durchfallen“ (fall-through), und ein kurzer Tastendruck im Tagesplan würde zusätzlich eine Quittung senden.

• Alle nicht genannten Ereignisse (z. B. PLAN_GEAENDERT im Hinweis) werden bewusst ignoriert – genau wie im Diagramm.

Beispielbegründung (3 P, je fachlich richtigem Argument 1–1,5 P):

• Das Türschild arbeitet ereignisgesteuert: Tastendrücke, Hinweise, Planänderungen, Verbindungsabbrüche und der Takt können jederzeit eintreffen. Es gibt keinen festen Ablauf von Arbeitsschritten mit Anfang und Ende, den ein Aktivitätsdiagramm darstellt.

• Die Reaktion hängt vom aktuellen Zustand ab: Derselbe kurze Tastendruck öffnet den Tagesplan, schließt ihn wieder oder quittiert einen Hinweis. Genau das zeigt das Zustandsdiagramm übersichtlich, ein Aktivitätsdiagramm bräuchte dafür viele verschachtelte Verzweigungen.

• Das Zustandsdiagramm ist eine direkte Vorlage für die Implementierung (Zustandsvariable oder Zustandsmuster) und für Testfälle (je Transition ein Test).

Ergänzend (ohne Bewertung): Die Planänderung meldet der Sessionplaner an alle angemeldeten Anzeigen – das entspricht dem Beobachter-Muster; das Zustandsdiagramm beschreibt dann, wie jede einzelne Anzeige darauf reagiert.

Eine Transition ohne Trigger ist eine Abschlusstransition: Der guard [verbunden] wird nur einmal geprüft, wenn „offline“ sein inneres Verhalten beendet hat (Ende der do-Aktivität). Ist die Verbindung in diesem Moment noch nicht da, wechselt das Türschild nicht mehr in den Betrieb – auch wenn die Verbindung später steht. (1 Punkt)

Präziser ist das Signal-Ereignis verbunden (wie in der Beschreibung) oder das Änderungsereignis when(verbunden). (1 Punkt)