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

https://bildung.social/@oerinformatik/

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

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

tl/dr; (ca. 26 min Lesezeit, Bearbeitung deutlich länger): 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 22.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. Die Beispiellösungen verwenden := 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)

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

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:

FUNKTION auswertenLauftreff(teilnahmen: GANZZAHL[]) : GANZZAHL
    summe: GANZZAHL
    schwach: GANZZAHL
    summe := 0
    ZÄHLE i VON 0 BIS laenge(teilnahmen)
        schwach := 0
        summe := teilnahmen[i]
        WENN teilnahmen[i] > 3 DANN
            schwach := schwach + 1
        ENDE WENN
    ENDE ZÄHLE
    durchschnitt := summe DIV laenge(teilnahmen)
    AUSGABE("Termine unter der Mindestzahl: " & schwach)
    RÜCKGABE durchschnitt
ENDE auswertenLauftreff

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.	Fehler	Korrektur
1	Schleifengrenze: Die Schleife läuft bis `laenge(teilnahmen)` und greift damit hinter das letzte Element (Index außerhalb).	`ZÄHLE i VON 0 BIS laenge(teilnahmen) - 1`
2	Anweisung an falscher Stelle: `schwach := 0` steht in der Schleife; der Zähler wird in jedem Durchlauf zurückgesetzt.	`schwach := 0` vor die Schleife verschieben
3	Akkumulation: `summe := teilnahmen[i]` überschreibt die Summe, statt den Wert zu addieren.	`summe := summe + teilnahmen[i]`
4	Bedingung: `> 3` zählt die gut besuchten Termine; gesucht sind Termine mit weniger als drei Personen.	`WENN teilnahmen[i] < 3 DANN`
5	Datentyp/Division: `DIV` dividiert ganzzahlig, die Nachkommastellen gehen verloren; Rückgabetyp `GANZZAHL` passt nicht; `durchschnitt` ist nicht deklariert.	`durchschnitt: GLEITKOMMAZAHL`, `durchschnitt := summe / laenge(teilnahmen)`, Rückgabetyp `GLEITKOMMAZAHL`

Korrigierte Fassung:

FUNKTION auswertenLauftreff(teilnahmen: GANZZAHL[]) : GLEITKOMMAZAHL
    summe: GANZZAHL
    schwach: GANZZAHL
    durchschnitt: GLEITKOMMAZAHL
    summe := 0
    schwach := 0
    ZÄHLE i VON 0 BIS laenge(teilnahmen) - 1
        summe := summe + teilnahmen[i]
        WENN teilnahmen[i] < 3 DANN
            schwach := schwach + 1
        ENDE WENN
    ENDE ZÄHLE
    durchschnitt := summe / laenge(teilnahmen)
    AUSGABE("Termine unter der Mindestzahl: " & schwach)
    RÜCKGABE durchschnitt
ENDE auswertenLauftreff

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)

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.

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 := falsch 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)

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: GANZZAHL) : Teilnahme[]`	liefert alle Teilnahmen einer Aktivität (mit `benutzerId` und `status`)
`morgen() : Datum`	liefert das Datum des nächsten Tages
`sendePush(benutzerId: GANZZAHL, text: ZEICHENKETTE)`	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.

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

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(km: GLEITKOMMAZAHL, hm: GANZZAHL) : ZEICHENKETTE, 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: GLEITKOMMAZAHL) : GANZZAHL`	kleinste ganze Zahl, die größer oder gleich `x` ist (`aufrunden(15.6)` = 16)
`zuText(z: GANZZAHL) : ZEICHENKETTE`	wandelt eine Zahl in Text um (`zuText(5)` = `"5"`)

FUNKTION gehzeitText(km: GLEITKOMMAZAHL, hm: GANZZAHL) : ZEICHENKETTE
    WENN km <= 0 ODER hm < 0 DANN
        RÜCKGABE "ungültig"
    ENDE WENN
    minuten := km / 4 * 60 + hm / 300 * 60
    gesamt := aufrunden(minuten / 15) * 15
    stunden := gesamt DIV 60
    rest := gesamt MOD 60
    WENN rest < 10 DANN
        text := zuText(stunden) & ":0" & zuText(rest)
    SONST
        text := zuText(stunden) & ":" & zuText(rest)
    ENDE WENN
    RÜCKGABE text
ENDE gehzeitText

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).

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 Programmentwurf: Entwürfe lesen, prüfen und korrigieren” von Hannes 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: 22.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]

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