Übungsaufgaben zu Werkzeugen der Softwareentwicklung

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 „Werkzeuge der
Softwareentwicklung“.

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/entwicklungswerkzeuge
- https://oer-informatik.de/git01-repo_anlegen_und_lokal_commiten
- https://oer-informatik.de/build-tool-maven
- Stilbeispiel: https://oer-informatik.de/entwicklungswerkzeuge-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Softwareentwicklung
- Compiler
- Interpreter
- Debugger
- Git
- Open-Source-Lizenzen
- Javadoc
- Semantic Versioning
- CI/CD

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.

Je Satz 0,5 Punkte:

Die Aussage stimmt nur teilweise (1 Punkt für die begründete Bewertung, 2 Punkte für die Erläuterung):

Java wird zwar kompiliert, aber nicht in Maschinencode, sondern in plattformunabhängigen Bytecode (.class-Dateien, zusammengefasst in einer .jar-Datei). Diesen Bytecode führt zur Laufzeit die Java Virtual Machine aus, die ihn interpretiert bzw. per Just-in-time-Compiler in Maschinencode übersetzt. Auf dem Info-Server muss deshalb eine passende Java-Laufzeitumgebung (JRE/JDK in mindestens der Version, für die kompiliert wurde) installiert sein – oder sie wird mit dem Programm zusammen ausgeliefert (z. B. in einem Container-Image). Dafür läuft dieselbe .jar-Datei auf jedem Betriebssystem mit JVM.

Je 1 Punkt für die Einordnung von Svenjas und Emres Argument, 2 Punkte für ein weiteres Kriterium mit Bezug zur Situation, 1 Punkt für eine Entscheidung, die schlüssig aus der Abwägung folgt. Eine mögliche Lösung:

• Svenjas Argument (Energie): Kompilierter C++-Code erledigt dieselbe Arbeit mit weniger Rechenzeit, weil zur Laufzeit nicht mehr übersetzt wird. Bei einem E-Ink-Schild fällt das aber weniger ins Gewicht, als es scheint: Das Display braucht nur beim Umschalten Strom, und der Mikrocontroller kann zwischen zwei Aktualisierungen des Sessionplans im Tiefschlaf liegen. Entscheidend für die Akkulaufzeit ist also vor allem, wie oft und wie lange das Schild wach ist.

• Emres Argument (Entwicklungstempo): Ohne Übersetzungs- und Flash-Vorgang lassen sich Änderungen sofort ausprobieren. Bis zum 13.03.2027 bleibt wenig Zeit, und der Prototyp läuft bereits – ein Neuschreiben kostet Wochen.

• Weiteres Kriterium, zum Beispiel: Kenntnisse im Team (die Schüler*innen können Python, C++ müssten sie erst lernen; das erhöht das Fehlerrisiko kurz vor dem Barcamp), Speicher des ESP32 (der Interpreter belegt einen Teil von Flash und RAM), verfügbare Bibliotheken für E-Paper-Displays und MQTT oder Wartbarkeit für die anderen Schulen, die die Firmware später übernehmen sollen.

• Entscheidung, zum Beispiel: Für das Barcamp bleibt es bei MicroPython. Die Energiefrage wird durch Tiefschlaf zwischen den Aktualisierungen gelöst und vorher mit einem Dauertest eines Schilds über zehn Stunden überprüft. Reicht der Akku dann nicht, wird der zeitkritische Teil später in C++ umgesetzt. Eine gut begründete Entscheidung für C++ (z. B. weil der Dauertest scheitert oder der Speicher knapp wird) ist ebenfalls richtig.

Je Situation 1 Punkt für die Schilderung und 1 Punkt für die Lösung mit Git, 1 Punkt für die Empfehlung, zum Beispiel:

• Verlorene Arbeit: Emre und eine Schülerin ändern am selben Vormittag die Klasse, die im Info-Server die MQTT-Nachrichten für die Türschilder zusammenstellt. Wer sein ZIP später hochlädt, überschreibt still die Änderungen der anderen – die Chat-Absprache wurde im Trubel übersehen. Mit Git committen beide ihre Änderungen; beim Zusammenführen vereint Git Änderungen an verschiedenen Stellen automatisch und meldet einen Konflikt, wenn dieselbe Stelle betroffen ist. Verloren geht nichts.

• Kein Weg zurück: Am Abend vor dem Barcamp stürzt die Buchung in der Web-App ab. Welches der vielen ZIP-Dateien der letzte funktionierende Stand war und was sich seitdem geändert hat, weiß niemand genau. Mit Git ist jede Änderung ein Commit mit Autor*in, Zeitpunkt und Nachricht; git log und git diff zeigen, was sich geändert hat, und mit git revert oder dem Auschecken des letzten markierten Stands läuft die Web-App in wenigen Minuten wieder.

• Weitere Situationen: Experimente gefährden die lauffähige Version (mit Git: eigener Branch); niemand weiß, welcher Stand auf welchem Türschild läuft (mit Git: Tag bzw. Commit-Kennung im Build).

• Empfehlung: Git einführen, aber bewusst einfach halten: eine halbstündige Einführung, nur wenige Befehle (clone, pull, add, commit, push) oder die Git-Unterstützung der IDE bzw. die Weboberfläche von GitLab, je Aufgabe ein Branch und Zusammenführen über Merge Requests. Dieser Aufwand ist kleiner als eine Nacht, in der verlorene Änderungen rekonstruiert werden müssen.

Je falscher Aussage 1 Punkt für das Erkennen und 1 Punkt für die Korrektur:

• Aussage 2 ist falsch: git commit speichert die Änderungen nur im lokalen Repository. Erst mit git push werden sie auf den GitLab-Server übertragen; die anderen holen sie mit git pull.

• Aussage 4 ist falsch: Git überschreibt bei einem Merge-Konflikt nichts automatisch. Es meldet den Konflikt, markiert die betroffenen Stellen in der Datei, und eine Person entscheidet, welche Fassung (oder welche Kombination) gilt; danach wird der aufgelöste Stand committet.

• Aussage 5 ist falsch: Zugangsdaten gehören nicht ins Repository, weil sie dort für alle mit Lesezugriff – und in der Historie dauerhaft, auch nach dem Löschen – sichtbar sind; nach der geplanten Veröffentlichung sogar weltweit. Die Datei wird über .gitignore ausgeschlossen; ins Repository kommt nur eine Vorlage ohne Passwort (z. B. mqtt.properties.example), das Passwort wird lokal bzw. als geschützte Variable der CI-Pipeline hinterlegt.

Aussagen 1, 3 und 6 sind richtig.

Je Zeile 0,5 Punkte für die Spalte „Open Source?“ und 1,5 Punkte für die Folgen, zum Beispiel:

Je Teil der Aussage 2 Punkte (1 Punkt für das passende Beispiel aus der Tabelle, 1 Punkt für die Erklärung):

• „Open Source heißt, man kann den Quelltext lesen“ – stimmt nicht. Bei stream-overlay ist der Quelltext öffentlich lesbar, eine Lizenz fehlt aber. Dann gilt allein das Urheberrecht, und das Team darf den Code weder nutzen noch weitergeben. Open Source ist Software erst, wenn ihre Lizenz allen erlaubt, sie zu nutzen, zu untersuchen, zu verändern und – auch verändert – weiterzugeben, ohne Lizenzgebühren und ohne bestimmte Personen oder Einsatzzwecke auszuschließen (so legt es die Open Source Definition der Open Source Initiative fest).

• „Dann ist alles erlaubt“ – stimmt auch nicht. zertifikat-pdf steht unter einer anerkannten Open-Source-Lizenz, der AGPL-3.0. Trotzdem stellt sie Bedingungen: Wer die Web-App damit weitergibt oder als Netzwerkdienst anbietet, muss den gesamten Code unter AGPL offenlegen – das verträgt sich nicht mit der geplanten MIT-Veröffentlichung. Selbst die freizügige MIT-Lizenz von qrbadge verlangt, dass Lizenztext und Copyright-Hinweis erhalten bleiben. Open-Source-Lizenzen räumen also Rechte unter Bedingungen ein.

2 Punkte für die begründete Entscheidung, je 1 Punkt für eine Prüffrage, zum Beispiel:

• Entscheidung: brokerlink. Bei mqtt-mini ist seit Jahren keine neue Version erschienen, und eine gemeldete Sicherheitslücke bleibt unbeantwortet – findet jemand einen Fehler, behebt ihn niemand, und das Team müsste den fremden Code selbst pflegen. brokerlink wird aktiv gepflegt, Lücken werden schnell geschlossen, und die Dokumentation erleichtert auch den Schulen, die die Software später übernehmen, den Einstieg. Emres Argument zählt auf dem Info-Server wenig: Dort spielen 1,4 MB keine Rolle (anders als auf dem ESP32). Die drei mitgebrachten Bibliotheken müssen allerdings ebenfalls geprüft werden.

• Prüffragen, zum Beispiel:

  • Wird das Projekt aktiv gepflegt (Datum der letzten Version, Zahl der Mitwirkenden, Reaktion auf Fehlermeldungen)?
  • Gibt es offene bekannte Sicherheitslücken (CVE-Einträge), und wie schnell wurden frühere behoben?
  • Passt die Lizenz zur geplanten Veröffentlichung unter MIT?
  • Welche weiteren Abhängigkeiten bringt die Bibliothek mit, und bestehen diese dieselbe Prüfung?
  • Reicht die Dokumentation, und wie verbreitet ist die Bibliothek (Hilfe bei Problemen)?

Je 1 Punkt, zum Beispiel:

• Open-Source-Software: keine Lizenzkosten (wichtig für eine Schulveranstaltung mit knappem Budget); der offene Quelltext lässt sich selbst prüfen, und Verbesserungen anderer Schulen fließen zurück; kann an die eigenen Badges angepasst werden; keine Abhängigkeit vom Hersteller; andere Schulen können sie ebenfalls frei nutzen.

• Proprietäre Software: vertraglich zugesicherter Support (am Samstag darf nichts ausfallen); Gewährleistung und Haftung des Herstellers; ggf. bessere Zusammenarbeit mit weiterer Software und Hardware des Herstellers (z. B. Badge-Drucker); planbare Weiterentwicklung und Sicherheitsupdates durch ein Unternehmen.

2 Punkte für Argumente zugunsten der Bibliothek, 2 Punkte für die Bewertung von Natalias Einwand samt Gegenmaßnahme, 1 Punkt für eine schlüssige Empfehlung, zum Beispiel:

• Für die Bibliothek: Die Formate sind umfangreich (XML nach festgelegten Schemata und Prüfregeln, bei ZUGFeRD zusätzlich ein PDF mit eingebetteter XML-Datei). Eine Eigenentwicklung bis zum 01.01.2027 wäre für ein dreiköpfiges Team knapp und fehleranfällig. Eine verbreitete Bibliothek ist von vielen Nutzenden erprobt, und neue Fassungen der Formate kommen per Update.

• Natalias Einwand ist berechtigt: CSB-Rad macht sich von der Pflege durch Fremde abhängig; dazu kommen Einarbeitungsaufwand und weitere Abhängigkeiten, deren Fehler und Sicherheitslücken auch den Shop treffen. Gegenmaßnahmen: vor der Auswahl prüfen, wie aktiv das Projekt gepflegt wird; den Zugriff im Shop hinter einer eigenen Schnittstelle (z. B. einem Interface RechnungsExporter) kapseln, damit sich die Bibliothek später austauschen lässt. Die Apache-2.0-Lizenz erlaubt es außerdem, den Quelltext notfalls selbst weiterzupflegen.

• Empfehlung, zum Beispiel: erechnung-kit einsetzen, aber gekapselt und mit Tests, die die erzeugten Dateien gegen die offiziellen Prüfwerkzeuge validieren. Eine Eigenentwicklung lohnt sich nur, wenn keine gepflegte Bibliothek verfügbar ist.

Je Lücke 1 Punkt, zum Beispiel:

/**
 * Bestellt für eine bestehende Schließanlage zusätzliche Schlüssel
 * bei der Lipper SchließTec KG.                                         (1)
 *
 * @param schliessungscode Schließungscode der Anlage, nicht leer,
 *        Format "VS-" und acht Zeichen, z. B. "VS-7Q4K2M9"            (2)
 * @param anzahl Anzahl der nachzubestellenden Schlüssel, 1 bis 20       (3)
 * @return Bestellnummer der SchließTec, z. B. "LST-2026-08812"          (4)
 * @throws IllegalArgumentException wenn der Schließungscode falsch aufgebaut ist
 *         oder die Anzahl nicht zwischen 1 und 20 liegt
 * @throws SchliessTecException wenn die SchließTec-API nicht erreichbar ist
 *         oder den Schließungscode nicht kennt                          (5)
 * @since 2.4
 */
public String nachbestellen(String schliessungscode, int anzahl) throws SchliessTecException

Für (2) bis (4) gibt es den Punkt nur, wenn Bedeutung und gültiger Wertebereich bzw. Format angegeben sind; für (5) müssen Exception-Name und beide Auslöser genannt werden.

Für den Klassenkommentar je 1 Punkt, zum Beispiel: wozu die Klasse dient, mit einem kurzen Verwendungsbeispiel; welche Konfiguration ein Objekt braucht (Adresse und Zugangsschlüssel der SchließTec-API); ob ein Objekt von mehreren Threads gleichzeitig genutzt werden darf; wie viele Anfragen je Stunde die SchließTec zulässt; @since 2.4 und Verweise (@see) auf verwandte Klassen.

Je 1 Punkt (Versionsnummer mit Begründung):

1. 2.3.2 – reine Fehlerbehebung ohne Änderung der Schnittstelle: PATCH wird erhöht.

2. 2.4.0 – neue Funktion, abwärtskompatibel: MINOR wird erhöht, PATCH auf 0 gesetzt (passt zu @since 2.4 in Teilaufgabe ab).

3. 3.0.0 – inkompatible Änderung, weil vorhandener Code mit dem alten Aufruf nicht mehr kompiliert (Shop-Backend und Werkstattportal müssen angepasst werden): MAJOR wird erhöht, MINOR und PATCH auf 0 gesetzt.

Je Fehler 1 Punkt für die Beschreibung und 1 Punkt für die Korrektur, vier der folgenden fünf:

• Reihenfolge: Ausgeliefert wird, bevor gebaut und getestet ist – damit ginge der alte oder ein ungetesteter Stand live. Korrektur: build → test → (package) → deploy.

• Tests ohne Wirkung: Fehlgeschlagene Tests stoppen die Pipeline nicht, fehlerhafter Code wird trotzdem ausgeliefert (wie bei der Versandkostenberechnung). Korrektur: Bei einem fehlgeschlagenen Test bricht die Pipeline ab; ausgeliefert wird nur, wenn alle Stufen erfolgreich waren.

• Auslöser: Jeder Push in einen beliebigen Branch, auch unfertige Feature-Branches, landet direkt im Live-Shop. Korrektur: Bauen und testen bei jedem Push/Merge Request, aber nur Stände aus main auf ein Staging-System ausliefern und nur getaggte Versionen nach manueller Freigabe in die Produktion.

• Zugangsdaten im Repository: Das Passwort ist für alle mit Zugriff auf das Repository und dauerhaft in der Git-Historie sichtbar. Korrektur: SSH-Schlüssel statt Passwort, als geschützte und maskierte CI/CD-Variable hinterlegen, die nur in geschützten Branches/Tags verfügbar ist.

• Java-Version passt nicht zum Server: Das Build-Image nutzt Java 21, der Server Java 17 – genau der Fehler vom 12.09.2026. Korrektur: Build-Image mit Java 17 verwenden (z. B. maven:3.9-eclipse-temurin-17) oder zuerst den Server auf Java 21 aktualisieren bzw. Anwendung samt Laufzeitumgebung als Container ausliefern.

So könnte die korrigierte Pipeline aussehen:

2 Punkte für die Erläuterung, 2 Punkte für eine begründete Empfehlung:

• Continuous Delivery: Jede Änderung wird automatisch gebaut, getestet und bis in eine Testumgebung ausgeliefert, sodass jeder Stand jederzeit veröffentlicht werden könnte. Die Auslieferung in die Produktion erfolgt nach einer manuellen Freigabe (Cems Wunsch).

• Continuous Deployment: Auch die Auslieferung in die Produktion läuft ohne menschliches Zutun, sobald alle Prüfungen bestanden sind (Sophies Wunsch).

Empfehlung, zum Beispiel: Zunächst Continuous Delivery. Die Testabdeckung des Shop-Backends ist offensichtlich noch lückenhaft (Versandkostenfehler), und Fehler im Live-Shop kosten direkt Umsatz und Vertrauen. Mit der manuellen Freigabe kann eine Version auf dem Staging-System kurz geprüft und zu einem günstigen Zeitpunkt veröffentlicht werden. Wenn die automatisierten Tests zuverlässig sind und Rollbacks geübt wurden, kann später auf Continuous Deployment umgestellt werden. Eine begründete Empfehlung für Continuous Deployment (z. B. kleine, risikoarme Änderungen, schnelle Reaktion auf Kundenwünsche, Voraussetzung: hohe Testabdeckung) wird ebenfalls gewertet.

2 Punkte, zum Beispiel:

Das Team führt ein Rollback durch: Die Bereitstellungsstufe der Pipeline wird für den letzten funktionierenden Stand – z. B. das vorherige Tag v4.7.2 – erneut ausgeführt, oder das dort gespeicherte Build-Ergebnis wird erneut ausgeliefert. Das geht mit wenigen Klicks und ohne Zugriff auf den Server per Hand. Anschließend wird der Fehler in einem Branch behoben, mit einem neuen Test abgesichert und als neue Version über die Pipeline ausgeliefert (alternativ: git revert der fehlerhaften Änderung, die Pipeline liefert den korrigierten Stand aus).

Je 2 Punkte, zum Beispiel:

• Abhängigkeitsprüfung in der Pipeline (dependency scanning): Bei jedem Build werden alle direkten und transitiven Abhängigkeiten mit Datenbanken bekannter Schwachstellen (CVE) abgeglichen; bei kritischen Funden bricht die Pipeline ab bzw. meldet den Fund. So fällt eine Lücke wie in „jsonfast“ auf, auch wenn sie nur indirekt eingebunden ist.

• Software-Stückliste (SBOM): Die Pipeline erzeugt bei jedem Build eine Liste aller enthaltenen Komponenten mit Versionen. Bei einer neuen Warnung ist sofort klar, welche Versionen von Shop und Werkstattportal betroffen sind.

• Festgelegte Versionen und regelmäßige Updates: Versionen werden in der pom.xml fest eingetragen; Werkzeuge schlagen automatisch Updates vor (Merge Request mit neuer Version), die durch die Pipeline getestet werden. Eine abgesicherte Version kann so innerhalb kurzer Zeit gebaut, getestet und ausgeliefert werden.

• Sicherheitsmeldungen verfolgen: Warnungen des BSI/CERT und der Projekte der verwendeten Bibliotheken abonnieren und eine verantwortliche Person benennen.

Je Situation 2 Punkte, je 1 Punkt für die Einordnung von Compiler und Unittests, zum Beispiel:

• Unklare Spur: Solange man nicht weiß, welche Werte wichtig sind, muss Jonas für jede neue Vermutung eine weitere Ausgabe einbauen, neu übersetzen und das Backend neu starten. Am Haltepunkt zeigt der Debugger dagegen sofort alle lokalen Variablen, die Inhalte der Objekte und den Aufrufstapel; Ausdrücke lassen sich direkt auswerten.

• Langer Ablauf: Führt der Weg zum Fehler durch mehrere Methoden oder viele Schleifendurchläufe, liefern Ausgaben eine unübersichtliche Textflut. Mit dem Debugger verfolgt man den Ablauf Schritt für Schritt, hält nur unter einer Bedingung an und kann einen Wert zur Laufzeit ändern, um eine Vermutung sofort zu prüfen.

• Weitere: Vergessene Ausgaben bleiben im Code und landen in den Logs des Live-Betriebs, womöglich mit personenbezogenen Daten.

• Compiler: meldet Syntax- und Typfehler, bevor das Programm läuft (z. B. fehlendes Semikolon, String statt int). Logikfehler wie eine falsche Altersberechnung erkennt er nicht.

• Unittests: zeigen automatisch und wiederholbar, dass ein Programmteil ein falsches Ergebnis liefert. Wo und warum der Fehler entsteht, klärt dann der Debugger.

Je Situation 1 Punkt:

1. Aufrufstapel (Call Stack): zeigt die Kette der Methodenaufrufe bis zur aktuellen Zeile; ein Klick auf einen Eintrag zeigt die Variablen der jeweiligen Methode.

2. Ausnahme-Haltepunkt (Exception Breakpoint) für NullPointerException: Der Debugger hält genau dort an, wo die Ausnahme geworfen wird.

3. Step Out: führt die aktuelle Methode zu Ende aus und hält in der aufrufenden Methode an.

4. Beobachtungsausdruck (Watch): Der Ausdruck wird bei jedem Halt neu ausgewertet und angezeigt.

Je Vorgehensweise 2 Punkte (1 Punkt Vorgehen, 1 Punkt konkreter Ansatzpunkt), z. B.:

• Haltepunkt und Variablen prüfen: Haltepunkt auf die Zeile List<Aktivitaet> ergebnis = … setzen (also direkt nach der Altersberechnung) und den Wert von alter im Variablenfenster ablesen. Erwartet wäre 17, angezeigt wird 18 – der Fehler liegt also in berechneAlter.
• Einzelschrittmodus in der Schleife: Haltepunkt in der for-Schleife setzen und mit Step Over die Durchläufe verfolgen; bei der Aktivität „Kneipenquiz“ a.getMindestalter() (18) und alter vergleichen und beobachten, dass die Bedingung true ergibt.
• Step Into in die Methode: Beim Aufruf von berechneAlter mit Step Into hineinspringen und die Werte von stichtag.getYear() und geburtsdatum.getYear() ansehen.
• Werte ändern: alter im Debugger auf 17 setzen und weiterlaufen lassen; verschwindet die Aktivität, ist der Filter selbst richtig und nur das Alter falsch.

a.getMindestalter() == 18 (2 Punkte; alternativ a.getMindestalter() > alter - 1 oder a.getMindestalter() == 18 && benutzer.getBenutzerId() == 13). Ohne Bedingung müsste man sich durch alle Durchläufe klicken.

• Step Over (1 Punkt) führt die ganze Zeile einschließlich des Methodenaufrufs aus und hält in der nächsten Zeile. Das genügt, wenn man nur das Ergebnis (alter) prüfen will oder der Methode vertraut.
• Step Into (1 Punkt) springt in berechneAlter hinein. Das ist nötig, sobald feststeht, dass alter falsch ist, um die Berechnung Zeile für Zeile zu verfolgen.
• Begründung für diesen Fall (1 Punkt): Zuerst Step Over, um alter zu sehen (18 statt 17); weil das falsch ist, beim nächsten Durchlauf Step Into. (Mit Step Out kommt man aus der Methode wieder heraus.)

• Ursache (1 Punkt): Die Methode zieht nur die Jahreszahlen voneinander ab und berücksichtigt nicht, ob die Person in diesem Jahr schon Geburtstag hatte.
• Begründung (1 Punkt): Im Jahr 2026 ergab 2026 − 2009 = 17 (richtig). Seit dem 01.01.2027 ergibt 2027 − 2009 = 18, obwohl Noah erst am 12.03.2027 volljährig wird. Bis dahin sieht er Aktivitäten ab 18 – ein Verstoß gegen den Jugendschutz der App.
• Korrektur (2 Punkte):

public int berechneAlter(LocalDate geburtsdatum, LocalDate stichtag) {
    return Period.between(geburtsdatum, stichtag).getYears();
}

Ebenfalls richtig: vom Jahresunterschied 1 abziehen, wenn der Geburtstag (Monat und Tag) im Stichtagsjahr noch nicht erreicht ist.

Je 2 Punkte, z. B.:

• Fall in einer Test- oder Staging-Umgebung nachstellen, die dieselbe Programmversion und vergleichbare, aber anonymisierte oder künstliche Testdaten enthält (z. B. Testkonto mit Geburtsdatum 12.03.2009), und dort mit dem Debugger arbeiten – auch per Remote-Debugging in einen Testcontainer.
• Logging gezielt erweitern: an der verdächtigen Stelle das berechnete Alter und die Mindestalter-Prüfung mit einer passenden Protokollstufe (z. B. DEBUG) und ohne personenbezogene Daten protokollieren, z. B. nur mit Benutzer-ID, und die Logs auswerten.
• Logpoints oder Beobachtungswerkzeuge (Monitoring, Tracing) nutzen, die Meldungen schreiben, ohne das Programm anzuhalten.

Je 2 Punkte, z. B.:

• Betrieb wird gestört: Hält der Debugger an einem Haltepunkt, bleiben die Anfragen aller Nutzenden in diesem Thread hängen; die App reagiert nicht mehr oder Zeitüberschreitungen entstehen.
• Datenschutz: Im Debugger sind alle Daten im Speicher sichtbar, auch Geburtsdaten, Adressen und Chatnachrichten echter Nutzender, darunter Minderjähriger. Ein Zugriff ohne Rechtsgrundlage und Erforderlichkeit verstößt gegen die DSGVO (Datenminimierung, Vertraulichkeit).
• IT-Sicherheit: Ein offener Debug-Port (z. B. JDWP) erlaubt, Code im Prozess auszuführen und Werte zu ändern; ist er erreichbar, kann ein Angreifer den Server übernehmen.
• Veränderung des Verhaltens: Werte, die im Debugger geändert werden, wirken sich direkt auf echte Daten und Abläufe aus.

Je Testfall 1 Punkt, z. B.: