Übungsaufgaben zum Programmentwurf: Entwürfe lesen, prüfen und korrigieren

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

https://oer-informatik.de/programmentwurf-uebungsaufgaben

Programmentwurf, Struktogramm, Programmablaufplan, Pseudocode, Schreibtischtest, Testfälle, DIN 66001, Algorithmen, Übungsaufgaben, Prüfungsvorbereitung

tl/dr; (ca. 68 min Lese- und Bearbeitungszeit): Eine umfangreiche Übungsaufgabe rund um eine Freizeit-App: Testfalltabelle und Schreibtischtest durchführen, Fehler in Struktogramm und Pseudocode beschreiben und korrigieren, Sinnbilder eines Programmablaufplans benennen und ihn in ein Struktogramm übertragen, ein Struktogramm-Gerüst ergänzen, ein Ergebnis gegen die Vorgabe prüfen und einen eigenen Algorithmus entwerfen. Alle Lösungen sind ausgeblendet und mit Punkteverteilung versehen [AI-Assisted]. (Zuletzt geändert am 23.10.2026)

Diese Übungsaufgaben gehören zum Artikel Programmentwürfe lesen, prüfen und korrigieren. Die Schreibweise des Pseudocodes erklärt der Artikel Algorithmen mit Pseudocode dokumentieren, die Symbole die Übersicht der Programmentwurfsmethoden.

Hinweise zur Bearbeitung: Die Aufgabe ist bewusst umfangreich, damit alle typischen Fragestellungen zum Thema vorkommen; die Angabe hinter dem Aufgabentitel nennt ihre Kompetenzstufe (Stufe 1 Basiskompetenz bis Stufe 4 Expertise). Wenn nichts anderes verlangt ist, darfst Du Algorithmen in Pseudocode, als Struktogramm oder als Programmablaufplan angeben. Arrays beginnen mit dem Index 0. Pseudocode kannst Du über die Registerkarten in vier Notationen anzeigen (JANA, Pseudo-Pascal, deutsches Pseudo-Pascal, Pseudo-Python); die Zeilen entsprechen sich in allen Notationen, und die Notationen sind im Artikel Algorithmen mit Pseudocode dokumentieren beschrieben. Wenn Du selbst Pseudocode schreibst, darfst Du eine der vier Notationen wählen. Struktogramme und Programmablaufpläne verwenden das deutsche Pseudo-Pascal: := für die Zuweisung, = und <> für Vergleiche, und/oder sowie div und mod für ganzzahlige Division und Rest; & verknüpft Zeichenketten. Andere korrekte Lösungen sind ebenfalls richtig. Schreib Deine Lösung zuerst vollständig auf, bevor Du die Beispiellösung aufklappst.

Aufgabe 1: Wanderungen, Lauftreffs und Check-in in einer Freizeit-App (Stufe 2 – Kernkompetenz)

Du bist Auszubildende*r im Entwicklungsteam der Let’s Meet GmbH in Bielefeld. Die App „Let’s Meet“ bringt Menschen für gemeinsame Freizeitaktivitäten zusammen. Für das nächste Release sollen Aktivitäten im Freien besser unterstützt werden: Wanderungen bekommen einen Schwierigkeitsgrad und eine geschätzte Gehzeit, Lauftreffs eine Auswertung, und die Teilnahme wird am Treffpunkt mit einem Code bestätigt. Dein Mit-Azubi Jonas Weber hat erste Entwürfe geschrieben. Yusuf Demir, Leiter der Entwicklung, bittet Dich, sie im Code-Review zu prüfen.

a) Schwierigkeitsgrad einer Wanderung

Sabine Hoffmann organisiert regelmäßig Wanderungen im Teutoburger Wald. Gemeinsam mit Clara Neumann (Product Owner) hat sie die Einstufung festgelegt:

Vorgabe für die Einstufung von Wanderungen
Schwierigkeitsgrad Bedingung
leicht Strecke höchstens 10 km und höchstens 200 Höhenmeter Aufstieg
mittel Strecke höchstens 18 km und höchstens 500 Höhenmeter Aufstieg, sofern nicht „leicht“
anspruchsvoll alle übrigen Wanderungen

Jonas hat dazu folgendes Struktogramm entworfen (km = Strecke, hm = Höhenmeter):

Struktogramm der Funktion einstufen (Entwurf von Jonas) (mit KI erstellt)
Struktogramm der Funktion einstufen (Entwurf von Jonas) (mit KI erstellt)

aa) Führe einen Schreibtischtest durch. Ermittle für jeden Testfall das erwartete Ergebnis laut Vorgabe und das tatsächliche Ergebnis laut Struktogramm und trage beide in die Tabelle ein. (10 Punkte)

Testfalltabelle für die Funktion einstufen
Nr. Testfall erwartetes Ergebnis tatsächliches Ergebnis
1 einstufen(8.0, 150)
2 einstufen(10.0, 200)
3 einstufen(7.5, 620)
4 einstufen(14.0, 380)
5 einstufen(18.5, 300)
Nr. Testfall erwartetes Ergebnis tatsächliches Ergebnis
1 einstufen(8.0, 150) leicht leicht
2 einstufen(10.0, 200) leicht mittel
3 einstufen(7.5, 620) anspruchsvoll mittel
4 einstufen(14.0, 380) mittel mittel
5 einstufen(18.5, 300) anspruchsvoll anspruchsvoll

Wege durch das Struktogramm: Fall 2: 10.0 <= 10 ja → 200 < 200 nein → „mittel“. Fall 3: 7.5 <= 10 ja → 620 < 200 nein → „mittel“. Fall 5: 18.5 <= 10 nein → 18.5 <= 18 falsch → „anspruchsvoll“.

Bewertung: je Testfall 1 Punkt für das erwartete und 1 Punkt für das tatsächliche Ergebnis (10 Punkte).

ab) Vergleiche die erwarteten mit den tatsächlichen Ergebnissen und ziehe eine Schlussfolgerung. (2 Punkte)

In den Testfällen 2 und 3 weicht das tatsächliche vom erwarteten Ergebnis ab (1 Punkt). Das Struktogramm erfüllt die Vorgabe also nicht und muss korrigiert werden; danach sind alle Testfälle erneut durchzuführen, weil die Korrektur neue Fehler verursachen könnte (1 Punkt). Dass die Fälle 1, 4 und 5 bestehen, beweist nicht, dass diese Teile fehlerfrei sind.

ac) Das Struktogramm enthält zwei Fehler. Beschreibe beide Fehler und gib ein korrigiertes Struktogramm an. (6 Punkte)

  • Fehler 1 (Grenzwert): Die Bedingung hm < 200 schließt den Grenzwert 200 aus, die Vorgabe lautet „höchstens 200 Höhenmeter“. Korrektur: hm <= 200. (1 Punkt Beschreibung, 2 Punkte Korrektur)

  • Fehler 2 (fehlender Fall): Im Ja-Zweig von km <= 10 wird jede Wanderung mit mehr als 200 Höhenmetern als „mittel“ eingestuft. Die Grenze von 500 Höhenmetern wird bei kurzen Strecken nicht geprüft, sodass z. B. 7,5 km mit 620 Höhenmetern als „mittel“ gelten. Korrektur: Im Nein-Zweig von hm <= 200 eine weitere Verzweigung hm <= 500 mit „mittel“ und „anspruchsvoll“. (1 Punkt Beschreibung, 2 Punkte Korrektur)

Korrigiertes Struktogramm der Funktion einstufen (mit KI erstellt)
Korrigiertes Struktogramm der Funktion einstufen (mit KI erstellt)

Gleichwertig ist eine flache Fassung: wenn km <= 10 und hm <= 200 → „leicht“, sonst wenn km <= 18 und hm <= 500 → „mittel“, sonst „anspruchsvoll“.

ad) Jonas hatte seinen Entwurf vorher nur mit den Testfällen 1, 4 und 5 geprüft und keinen Fehler bemerkt. Beurteile diese Auswahl an Testdaten und gib zwei weitere Testfälle an, die Du nach der Korrektur zusätzlich verwenden würdest. (3 Punkte)

Die Auswahl ist ungeeignet: Alle drei Testfälle liegen mitten in ihren Bereichen. Es fehlen Grenzwerte (genau 10 km, 200 hm, 18 km, 500 hm) und die Kombination „kurze Strecke, viele Höhenmeter“. Deshalb bestehen alle drei Fälle, obwohl der Entwurf zwei Fehler enthält – der Test sagt nichts über die Korrektheit aus. (1 Punkt)

Zusätzliche Testfälle (je 1 Punkt, z. B.):

  • einstufen(18.0, 500) → „mittel“ (beide Obergrenzen von „mittel“ genau erreicht)

  • einstufen(18.0, 501) → „anspruchsvoll“ (knapp über der Höhengrenze)

  • einstufen(10.5, 150) → „mittel“ (knapp über der Streckengrenze von „leicht“)

b) Auswertung eines Lauftreffs

Tobias Lange leitet eine Laufgruppe vor der Frühschicht. Eine Aktivität findet nur statt, wenn sich mindestens drei Personen angemeldet haben. Die App speichert die Teilnehmendenzahlen der letzten Termine in einem Array. Die Funktion auswertenLauftreff soll den Durchschnitt der Teilnehmenden mit Nachkommastellen zurückgeben und ausgeben, an wie vielen Terminen weniger als drei Personen teilgenommen haben. Jonas hat folgenden Pseudocode geschrieben (die Notation wählst Du über die Registerkarten, die Zeilen entsprechen sich):

int auswertenLauftreff(int teilnahmen[]) {
    int summe
    int schwach
    summe = 0
    for (int i = 0 … length(teilnahmen)) {
        schwach = 0
        summe = teilnahmen[i]
        if (teilnahmen[i] > 3) {
            schwach = schwach + 1
        }
    }
    durchschnitt = summe / length(teilnahmen)
    write("Termine unter der Mindestzahl: " + schwach)
    return durchschnitt
}

ba) Führe für den Aufruf auswertenLauftreff([5, 2, 7, 3]) einen Schreibtischtest mit Jonas’ Pseudocode durch. Lege dazu eine Tabelle mit den Spalten i, teilnahmen[i], summe, Bedingung und schwach an (eine Zeile je Schleifendurchlauf) und gib an, wie der Aufruf endet. (5 Punkte)

i teilnahmen[i] summe Bedingung teilnahmen[i] > 3 schwach
(Start) – 0 – ?
0 5 5 wahr 1
1 2 2 falsch 0
2 7 7 wahr 1
3 3 3 falsch 0
4 – – Zugriff auf teilnahmen[4] –

Bei i = 4 greift die Funktion auf teilnahmen[4] zu. Das Array hat nur die Indizes 0 bis 3: Der Aufruf bricht mit einem Laufzeitfehler (Index außerhalb des Arrays) ab, es erfolgt weder Ausgabe noch Rückgabe.

Bewertung: je Schleifendurchlauf 0 bis 3 eine Zeile mit richtigen Werten (4 × 1 Punkt), Abbruch bei i = 4 erkannt (1 Punkt).

bb) Der Pseudocode enthält fünf Fehler. Beschreibe die Fehler und korrigiere sie. (10 Punkte)

Nr. Zeile Fehler Korrektur
1 5 Schleifengrenze: Die Schleife läuft bis zur Länge des Arrays (in Pseudo-Python range(len(teilnahmen) + 1)) und greift damit hinter das letzte Element (Index außerhalb). Obergrenze Länge − 1, in Pseudo-Python range(len(teilnahmen))
2 6 Anweisung an falscher Stelle: schwach wird in der Schleife auf 0 gesetzt; der Zähler wird in jedem Durchlauf zurückgesetzt. Initialisierung von schwach vor die Schleife verschieben
3 7 Akkumulation: summe wird mit teilnahmen[i] überschrieben, statt den Wert zu addieren. summe um teilnahmen[i] erhöhen
4 8 Bedingung: > 3 zählt die gut besuchten Termine; gesucht sind Termine mit weniger als drei Personen. Vergleich teilnahmen[i] < 3
5 1 und 12 Datentyp/Division: Die Ganzzahldivision (div, //, in JANA / mit zwei int-Werten) schneidet die Nachkommastellen ab; der Rückgabetyp Ganzzahl passt nicht; durchschnitt ist nicht deklariert (entfällt in Pseudo-Python, das keine Deklarationen kennt). Rückgabetyp und durchschnitt als Gleitkommazahl, Division mit /; in JANA zusätzlich summe als float, weil / bei zwei int-Werten ganzzahlig teilt

Korrigierte Fassung:

float auswertenLauftreff(int teilnahmen[]) {
    float summe
    int schwach
    float durchschnitt
    summe = 0
    schwach = 0
    for (int i = 0 … length(teilnahmen)-1) {
        summe = summe + teilnahmen[i]
        if (teilnahmen[i] < 3) {
            schwach = schwach + 1
        }
    }
    durchschnitt = summe / length(teilnahmen)
    write("Termine unter der Mindestzahl: " + schwach)
    return durchschnitt
}

Bewertung: je Fehler 1 Punkt für die Beschreibung und 1 Punkt für die Korrektur. Beim fünften Fehler genügt die Korrektur der Division mit passendem Datentyp. Wer zusätzlich ein leeres Array abfängt (Division durch 0), zeigt Sorgfalt; das ist aber nicht gefordert.

bc) Gib an, welche Ausgabe und welche Rückgabe die korrigierte Funktion für [5, 2, 7, 3] liefert. (2 Punkte)

Summe 5 + 2 + 7 + 3 = 17, Durchschnitt 17 / 4 = 4,25.

  • Ausgabe: Termine unter der Mindestzahl: 1 (nur der Termin mit 2 Personen) (1 Punkt)

  • Rückgabe: 4,25 (1 Punkt)

c) Check-in am Treffpunkt

Damit Teilnahmen nur von Personen bestätigt werden, die wirklich am Treffpunkt sind, zeigt die Organisatorin bzw. der Organisator dort einen vierstelligen Treffcode an. Nach drei falschen Eingaben wird der Check-in gesperrt. Anh Nguyen hat den Ablauf mit Jonas als Programmablaufplan skizziert:

Programmablaufplan der Funktion checkIn mit den markierten Sinnbildern (1) bis (4) (mit KI erstellt)
Programmablaufplan der Funktion checkIn mit den markierten Sinnbildern (1) bis (4) (mit KI erstellt)

ca) Benenne die mit (1) bis (4) markierten Sinnbilder nach DIN 66001 und gib jeweils ihre Bedeutung an. (4 Punkte)

Nr. Sinnbild Bedeutung
(1) Grenzstelle Beginn (bzw. Ende) des Ablaufs
(2) Operation Verarbeitung, z. B. Wertzuweisung
(3) Ein-/Ausgabe Daten werden eingelesen bzw. ausgegeben
(4) Verzweigung Bedingung mit zwei Ausgängen (ja/nein)

Bewertung: je Sinnbild 1 Punkt (Name und Bedeutung).

cb) Die Software wird mit Struktogrammen dokumentiert. Übertrage den Ablauf in ein Struktogramm. (8 Punkte)

Die Eingabe wird mindestens einmal ausgeführt, die Prüfung steht danach: eine fußgesteuerte Schleife. Sie läuft weiter, solange der Code falsch ist und noch Versuche übrig sind. Der Hinweis „Code falsch“ erscheint nur, wenn noch einmal gefragt wird, und braucht deshalb eine Verzweigung im Rumpf. Nach der Schleife wird unterschieden, über welchen Ausgang sie verlassen wurde.

Struktogramm der Funktion checkIn (mit KI erstellt)
Struktogramm der Funktion checkIn (mit KI erstellt)

Bewertung:

  • Initialisierung versuche := 0 (1 Punkt)

  • Schleife mit korrekter zusammengesetzter Bedingung (2 Punkte)

  • Eingabe und Erhöhen von versuche im Rumpf (1 Punkt)

  • Verzweigung mit Hinweis „Code falsch“ im Rumpf (2 Punkte)

  • Verzweigung nach der Schleife mit beiden Ausgaben und Rückgaben (2 Punkte)

Andere korrekte Lösungen sind möglich, z. B. eine kopfgesteuerte Schleife mit einer Hilfsvariablen bestaetigt := false oder Pseudocode mit wiederhole … solange.

cc) Begründe, warum Du den Rücksprung des PAP nicht eins zu eins in das Struktogramm übernehmen kannst. (2 Punkte)

Ein Struktogramm kennt keine Ablauflinien und damit keine Sprünge: Wiederholungen sind nur als Schleifenblock darstellbar, der einen Rumpf vollständig umschließt und genau einen Ausgang hat (1 Punkt). Der PAP verlässt die Schleife an zwei Stellen (Code richtig, drei Fehlversuche). Diese Ausgänge müssen zu einer gemeinsamen Schleifenbedingung zusammengefasst und nach der Schleife mit einer Verzweigung wieder unterschieden werden (1 Punkt).

d) Erinnerungen vor einer Aktivität

Jeden Abend um 18 Uhr soll das Backend allen Personen mit bestätigter Teilnahme an einer Aktivität des nächsten Tages eine Push-Nachricht schicken und die Zahl der gesendeten Nachrichten zurückgeben. Yusuf Demir hat ein Struktogramm-Gerüst vorbereitet:

Struktogramm-Gerüst der Funktion erinnerungenSenden mit den Lücken (1) bis (7) (mit KI erstellt)
Struktogramm-Gerüst der Funktion erinnerungenSenden mit den Lücken (1) bis (7) (mit KI erstellt)

Folgende Funktionen stehen zur Verfügung:

Vorhandene Funktionen für die Erinnerungen
Funktion Beschreibung
oeffneDatenbank(): Verbindung öffnet die Datenbankverbindung
db.aktivitaetenAm(datum: Datum): Aktivitaet[] liefert alle Aktivitäten an einem Tag (mit id und titel)
db.teilnahmenVon(aktivitaetId: integer): Teilnahme[] liefert alle Teilnahmen einer Aktivität (mit benutzerId und status)
morgen(): Datum liefert das Datum des nächsten Tages
sendePush(benutzerId: integer, text: string) sendet eine Push-Nachricht
db.schliessen() schließt die Datenbankverbindung

Trage die passenden Anweisungen und Bedingungen folgerichtig in die Lücken (1) bis (7) ein. (8 Punkte)

  • A: db.schliessen()

  • B: zähle j von 0 bis laenge(teilnahmen) - 1

  • C: teilnahmen := db.teilnahmenVon(aktivitaeten[i].id)

  • D: sendePush(teilnahmen[j].benutzerId, "Morgen: " & aktivitaeten[i].titel)

  • E: aktivitaeten := db.aktivitaetenAm(morgen())

  • F: teilnahmen[j].status = "bestätigt"

  • G: anzahl := anzahl + 1

  • H: teilnahmen[j].status := "bestätigt"

Eine der Anweisungen bleibt übrig. Begründe, warum sie nicht in das Struktogramm gehört.

  1. E, (2) C, (3) B, (4) F, (5) D, (6) G, (7) A – je 1 Punkt. (5) und (6) dürfen vertauscht sein.

H wird nicht gebraucht (1 Punkt): Sie ist eine Zuweisung (:=) und keine Bedingung. An Stelle (4) würde sie jede Teilnahme auf „bestätigt“ setzen – auch abgesagte oder Wartelisten-Einträge – und damit Daten verfälschen und Nachrichten an Personen schicken, die gar nicht teilnehmen.

Vollständiges Struktogramm der Funktion erinnerungenSenden (mit KI erstellt)
Vollständiges Struktogramm der Funktion erinnerungenSenden (mit KI erstellt)

Begründung der Reihenfolge: aktivitaeten muss vor der äußeren Schleife belegt sein, weil deren Kopf laenge(aktivitaeten) braucht. teilnahmen hängt von i ab und wird von der inneren Schleife durchlaufen, gehört also in die äußere vor die innere Schleife. Die Verbindung wird erst geschlossen, wenn alle Aktivitäten bearbeitet sind.

e) Gehzeit prüfen

Zu jeder Wanderung zeigt die App eine geschätzte Gehzeit an. Laut Hilfetext gilt: Pro Stunde schafft man 4 km Strecke und 300 Höhenmeter Aufstieg; beide Zeiten werden addiert und auf die nächste volle Viertelstunde aufgerundet. Für Sabine Hoffmanns „Herbstwanderung am Hermannsweg“ mit 12,0 km und 270 Höhenmetern zeigt die Testversion „3:45 h“ an.

Überprüfe, ob die angezeigte Gehzeit der Vorgabe entspricht. Berichtige sie gegebenenfalls und begründe Dein Ergebnis. (5 Punkte)

Geg.: s = 12,0 km; h = 270 m; v_s = 4 km/h; v_h = 300 m/h
Ges.: Gehzeit t (aufgerundet auf eine Viertelstunde)

t = \frac{s}{v_s} + \frac{h}{v_h}

t = \frac{12{,}0\ \mathrm{km}}{4\ \mathrm{km/h}} + \frac{270\ \mathrm{m}}{300\ \mathrm{m/h}} = 3\ \mathrm{h} + 0{,}9\ \mathrm{h} = 3{,}9\ \mathrm{h} = 234\ \mathrm{min}

234\ \mathrm{min} \rightarrow \text{nächste volle Viertelstunde:}\ 16 \cdot 15\ \mathrm{min} = 240\ \mathrm{min} \approx \underline{\underline{4{,}000\ \mathrm{h}}}

  • Nein, die Anzeige entspricht nicht der Vorgabe. (1 Punkt)

  • Die Rechnung ergibt 3,9 h = 3 h 54 min. (2 Punkte)

  • Aufgerundet auf die nächste Viertelstunde sind das 4:00 h; die App hat auf 3:45 h abgerundet. (2 Punkte)

f) Gehzeit als Text

Entwickle die Funktion gehzeitText mit den Parametern km (Strecke als Gleitkommazahl) und hm (Höhenmeter als Ganzzahl), die die Gehzeit nach der Vorgabe aus e) berechnet und als Text im Format „Stunden:Minuten“ zurückgibt, z. B. "4:00" oder "2:15". Bei einer Strecke von höchstens 0 km oder negativen Höhenmetern soll "ungültig" zurückgegeben werden. Stelle den Algorithmus in Pseudocode, als Struktogramm oder als PAP dar. (10 Punkte)

Du darfst folgende Funktionen verwenden:

Vorhandene Funktionen für die Gehzeit
Funktion Beschreibung
aufrunden(x: double): integer kleinste ganze Zahl, die größer oder gleich x ist (aufrunden(15.6) = 16)
zuText(z: integer): string wandelt eine Zahl in Text um (zuText(5) = "5")

String gehzeitText(float km, int hm) {
    if (km <= 0 || hm < 0) {
        return "ungültig"
    }
    float minuten = km / 4 * 60 + hm / 300.0 * 60
    int gesamt = aufrunden(minuten / 15) * 15
    int stunden = gesamt / 60
    int rest = gesamt % 60
    String text = ""
    if (rest < 10) {
        text = zuText(stunden) + ":0" + zuText(rest)
    } else {
        text = zuText(stunden) + ":" + zuText(rest)
    }
    return text
}
Struktogramm der Funktion gehzeitText (mit KI erstellt)
Struktogramm der Funktion gehzeitText (mit KI erstellt)

Kontrolle mit den Werten aus e): 234 min → aufrunden(15,6) = 16 → 240 min → 4 Stunden, Rest 0 → "4:00". Weitere Beispiele: 8,0 km/150 hm → 150 min → "2:30"; 3,0 km/0 hm → 45 min → "0:45".

Bewertung:

  • Prüfung auf ungültige Eingaben mit Rückgabe (2 Punkte)

  • Gehzeit in Minuten (oder Stunden) richtig berechnet (2 Punkte)

  • Aufrunden auf eine Viertelstunde (2 Punkte)

  • Stunden und Minuten mit div und mod (oder gleichwertig) ermittelt (2 Punkte)

  • Text mit zweistelligen Minuten zusammengesetzt (1 Punkt)

  • Rückgabe des Textes (1 Punkt)

Da rest nur die Werte 0, 15, 30 oder 45 annehmen kann, genügt auch die Abfrage rest = 0. In echten Programmiersprachen kann die Gleitkommarechnung bei exakten Viertelstunden knapp über dem Wert liegen (z. B. 45,000000001); dann sollte vor dem Aufrunden auf einige Nachkommastellen gerundet werden.

Gesamtpunktzahl Aufgabe 1: 75 Punkte (a 21, b 17, c 14, d 8, e 5, f 10).


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 Programmentwurf: Entwürfe lesen, prüfen und korrigieren” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/programmentwurf-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/algorithmik/pseudocode. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 23.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: