Programmentwürfe lesen, prüfen und korrigieren: Pseudocode, Struktogramm und PAP

Programmentwürfe lesen, prüfen und korrigieren: Pseudocode, Struktogramm und PAP

https://bildung.social/@oerinformatik/

https://oer-informatik.de/programmentwurf

Programmentwurf, Pseudocode, Struktogramm, Programmablaufplan, DIN 66261, DIN 66001, Schreibtischtest, Trace-Tabelle, Testfalltabelle, Fehlersuche

tl/dr; (ca. 35 min Lesezeit): Ob Pseudocode, Struktogramm oder Programmablaufplan – oft musst Du einen fremden Entwurf nicht neu schreiben, sondern lesen, testen und reparieren. Der Artikel zeigt die Bausteine der drei Darstellungsformen nebeneinander, erklärt den Schreibtischtest mit Trace-Tabelle und Testfalltabelle, stellt die typischen Fehlerarten mit Korrektur vor und zeigt, wie Du Lücken in Vorgaben ergänzt und einen PAP in ein Struktogramm überträgst [AI-Assisted]. (Zuletzt geändert am 22.10.2026)

Dieser Artikel ist Teil einer Artikelreihe über Algorithmen und Programmentwurf: Algorithmen mit Pseudocode dokumentieren / Übersicht der Programmentwurfsmethoden / Programmentwürfe lesen, prüfen und korrigieren / Prozedurale Algorithmen mit Arrays / Übungsaufgaben zum Programmentwurf

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Dieser Artikel baut auf der Kann-Liste des Artikels Algorithmen mit Pseudocode dokumentieren auf.

Als Programmentwurf-Grundlagen kann ich nach Durchlesen des Artikels…

• … die Strukturblöcke eines Struktogramms (DIN 66261) und die Sinnbilder eines Programmablaufplans (DIN 66001) benennen und den passenden Pseudocode-Konstrukten zuordnen.

• … den Ablauf eines vorgegebenen Pseudocodes, Struktogramms oder PAP für konkrete Eingabewerte verfolgen und Rückgabe- und Ausgabewerte angeben.

• … einen Schreibtischtest mit einer Trace-Tabelle durchführen und mit einer Testfalltabelle erwartete und tatsächliche Ergebnisse vergleichen und daraus eine Schlussfolgerung ziehen.

• … ein vom Algorithmus geliefertes Ergebnis gegen die Vorgabe prüfen, es berichtigen und die Berichtigung begründen.

• … typische Fehler in Entwürfen erkennen (Grenzwert, Schleifengrenze, Startwert, Akkumulation, Anweisung an falscher Stelle, fehlender Zweig, fehlende Rückgabe, Datentyp) und sie beschreiben und korrigieren.

• … Lücken in einem vorgegebenen Struktogramm folgerichtig mit Anweisungen, Bedingungen und Schleifenköpfen ergänzen.

• … einen Programmablaufplan in ein Struktogramm oder in Pseudocode übertragen und begründen, warum dabei Rücksprünge in Schleifen umgeformt werden müssen.

Darüber hinaus kann ich als Programmentwurf-Expertenwissen…

• … einen unstrukturierten Ablauf mit Sprüngen aus einer Schleife in eine strukturierte Form mit zusammengesetzter Schleifenbedingung umbauen.

• … beurteilen, welche Darstellungsform sich für Entwurf, Dokumentation und Korrektur eines Algorithmus am besten eignet.

„Es liegt ein erster Entwurf vor, der sich als fehlerhaft erwiesen hat“ – mit diesem Satz beginnen viele Übungs- und Praxisaufgaben. Im Team schreibt selten eine Person einen Algorithmus allein: Jemand entwirft, jemand anderes prüft im Review, testet und korrigiert. Dafür musst Du einen Entwurf lesen können, ihn ohne Rechner testen und Fehler so beschreiben und korrigieren, dass andere die Änderung nachvollziehen. Dieser Artikel zeigt dafür das Handwerkszeug – unabhängig davon, ob der Entwurf als Pseudocode, Struktogramm oder Programmablaufplan vorliegt.

Drei Darstellungsformen, drei Kontrollstrukturen

Jeder Algorithmus lässt sich aus drei Kontrollstrukturen aufbauen: Folge (Anweisungen nacheinander), Verzweigung (Auswahl nach einer Bedingung) und Schleife (Wiederholung). Die drei Darstellungsformen zeigen diese Strukturen nur unterschiedlich:

• Pseudocode ist Text in programmiersprachenähnlicher Form. Es gibt keine Norm; wichtig ist, dass er eindeutig ist. Die Schreibweise hier ist das deutsche Pseudo-Pascal aus dem Artikel Algorithmen mit Pseudocode dokumentieren: := für die Zuweisung, = und <> für Vergleiche, UND, ODER, NICHT, DIV und MOD.

• Das Struktogramm (Nassi-Shneiderman-Diagramm, Nassi-Shneiderman diagram) nach DIN 66261 besteht aus ineinander geschachtelten Rechtecken, den Strukturblöcken. Es hat keine Pfeile – der Ablauf geht immer von oben nach unten.

• Der Programmablaufplan (PAP, Flussdiagramm, flowchart) nach DIN 66001 verbindet Sinnbilder mit Ablauflinien (Pfeilen). Er ist anschaulich, erlaubt aber auch beliebige Sprünge.

Kontrollstrukturen in Pseudocode, Struktogramm und Programmablaufplan

Kontrollstruktur	Pseudocode	Struktogramm (DIN 66261)	PAP (DIN 66001)
Anfang, Ende	FUNKTION name(…) : Typ … ENDE name	Titelblock mit der Signatur über dem Diagramm	Grenzstelle (Rechteck mit abgerundeten Ecken bzw. Oval)
Anweisung	summe := summe + preis	Rechteck (Strukturblock)	Rechteck (Operation)
Ein- und Ausgabe	EINGABE alter, AUSGABE text	Rechteck mit Text EINGABE …/AUSGABE …	Parallelogramm (Ein-/Ausgabe)
Verzweigung	WENN … DANN … SONST … ENDE WENN	Block mit Dreieck, Bedingung oben, Spalten „ja“ und „nein“	Raute mit genau zwei beschrifteten Ausgängen
Mehrfachauswahl	WERT VON x ENTSPRICHT … ENDE WERT VON	Block mit mehreren Spalten und Spalte „sonst“	mehrere Rauten oder Raute mit mehreren Ausgängen
kopfgesteuerte Schleife	SOLANGE bed … ENDE SOLANGE	Bedingung oben, Rumpf eingerückt (L-Form)	Raute vor dem Rumpf, Rücksprung davor
fußgesteuerte Schleife	WIEDERHOLE … SOLANGE bed	Rumpf eingerückt, Bedingung unten	Raute nach dem Rumpf, Rücksprung davor
Zählschleife	ZÄHLE i VON 0 BIS n - 1 … ENDE ZÄHLE	wie kopfgesteuerte Schleife mit ZÄHLE … im Kopf	Zähler setzen, Raute, Zähler erhöhen; alternativ Schleifenbegrenzung
Unterprogramm	ergebnis := pruefe(x)	Rechteck mit doppelten seitlichen Linien (gebräuchlich)	Rechteck mit doppelten seitlichen Linien
Rückgabe	RÜCKGABE wert	Rechteck RÜCKGABE wert	Grenzstelle RÜCKGABE wert oder Operation vor der Grenzstelle

Eine Gegenüberstellung mit Java-Code und UML-Aktivitätsdiagramm findest Du in der Übersicht der Programmentwurfsmethoden, das Aktivitätsdiagramm ausführlich im Artikel UML-Aktivitätsdiagramm.

Ein Beispiel in allen drei Formen

Ein Freizeitbad berechnet den Eintritt für eine Gruppe: Kinder unter 6 Jahren sind frei, Kinder und Jugendliche unter 18 zahlen 4 €, Erwachsene 8 €. Ab 10 Personen gibt es 10 % Rabatt auf den Gesamtpreis. Die Funktion gruppenpreis erhält die Alter aller Personen in einem Array.

FUNKTION gruppenpreis(alter: GANZZAHL[]) : GLEITKOMMAZAHL
    summe := 0
    ZÄHLE i VON 0 BIS laenge(alter) - 1
        WENN alter[i] < 6 DANN
            preis := 0
        SONST WENN alter[i] < 18 DANN
            preis := 4
        SONST
            preis := 8
        ENDE WENN
        summe := summe + preis
    ENDE ZÄHLE
    WENN laenge(alter) >= 10 DANN
        summe := summe * 0,9
    ENDE WENN
    RÜCKGABE summe
ENDE gruppenpreis

Im Struktogramm wird SONST WENN zu einer zweiten Verzweigung im Nein-Zweig der ersten. Ein leerer Nein-Zweig bleibt einfach leer (oder erhält ein Ø).

Im PAP wird die Zählschleife aufgelöst: Zähler setzen, Bedingung prüfen, Rumpf ausführen, Zähler erhöhen, zurück zur Bedingung. Die Zusammenführung mehrerer Zweige zeichnest Du als Punkt (Verbindungsstelle).

Wenn Du die drei Formen vergleichst, siehst Du: Die Schachtelung ist im Struktogramm am deutlichsten – was im Schleifenblock steht, wird wiederholt, alles darunter nicht. Im PAP musst Du dafür den Pfeilen folgen. Genau an dieser Stelle entstehen beim Lesen und Zeichnen die meisten Fehler.

Einen Entwurf lesen: Was liefert der Algorithmus?

Die einfachste Aufgabenstellung lautet: „Geben Sie die Rückgabe für folgende Aufrufe an.“ Dafür spielst Du den Algorithmus mit den Werten des Aufrufs durch. Drei Regeln helfen:

1. Parameter zuordnen: Schreib Dir zuerst auf, welcher Wert an welchen Parameter geht (gruppenpreis([34, 5, 15, 40]) → alter[0] = 34, alter[1] = 5 …). Bei mehreren Parametern zählt die Reihenfolge, nicht der Name.

2. Bei Verzweigungen genau einen Zweig gehen: Bei verschachtelten Verzweigungen prüfst Du die Bedingungen von außen nach innen und notierst Dir den Weg (z. B. „Bedingung 1 ja → Bedingung 2 nein → Bedingung 3 ja“). Achte bei Grenzwerten auf < und <=: Bei alter[i] < 18 zahlt eine 18-jährige Person den Erwachsenenpreis.

3. Zusammengesetzte Bedingungen vollständig auswerten: Bei UND müssen beide Teile wahr sein, bei ODER reicht einer. NICHT (a UND b) ist dasselbe wie NICHT a ODER NICHT b (De Morgan) – das brauchst Du später beim Umformen von Schleifenbedingungen.

Für das Beispiel ergibt sich: 34 → 8 €, 5 → 0 €, 15 → 4 €, 40 → 8 €, Summe 20 €, kein Rabatt (nur 4 Personen). Bei sechs Erwachsenen, zwei Zwölfjährigen und zwei Vierjährigen wären es 56 € minus 10 % = 50,40 €.

Der Schreibtischtest

Ein Schreibtischtest (dry run, desk check) ist ein Test ohne Rechner: Du führst den Algorithmus mit Papier und Stift aus. Es gibt zwei Formen, die in der Praxis und in Aufgaben beide vorkommen.

Trace-Tabelle: jeden Schritt mitschreiben

Bei der Trace-Tabelle (Ablaufverfolgung) legst Du für jede veränderliche Variable eine Spalte an und schreibst nach jedem Schleifendurchlauf (oder jeder Anweisung) die aktuellen Werte auf. So siehst Du genau, wo ein Wert falsch wird.

Angenommen, ein Kollege hat die Funktion so entworfen:

FUNKTION gruppenpreis(alter: GANZZAHL[]) : GLEITKOMMAZAHL
    summe := 0
    ZÄHLE i VON 1 BIS laenge(alter) - 1
        WENN alter[i] < 18 DANN
            preis := 4
        SONST WENN alter[i] < 6 DANN
            preis := 0
        SONST
            preis := 8
        ENDE WENN
        summe := summe + preis
    ENDE ZÄHLE
    …

Der Schreibtischtest mit [34, 5, 15, 40]:

Trace-Tabelle des fehlerhaften Entwurfs für gruppenpreis([34, 5, 15, 40])

i	alter[i]	Weg	preis	summe
(Start)	–	–	–	0
1	5	5 < 18 ja	4	4
2	15	15 < 18 ja	4	8
3	40	40 < 18 nein, 40 < 6 nein	8	16

Ergebnis 16 € statt 20 €. Die Tabelle zeigt beide Fehler: Die erste Person (Index 0) wird nie betrachtet, weil die Schleife bei 1 beginnt, und das Kind mit 5 Jahren zahlt 4 €, weil die Bedingung alter[i] < 6 nie erreicht wird – jedes Alter unter 6 ist auch unter 18 und landet schon im ersten Zweig. Ein solcher unerreichbarer Zweig ist ein typischer Reihenfolgefehler bei SONST WENN-Ketten: Die engere Bedingung muss zuerst geprüft werden.

Tipps für die Trace-Tabelle:

• Eine Zeile je Schleifendurchlauf reicht meist; schreib die Startwerte vor der Schleife in eine eigene Zeile.

• Notiere auch den letzten Schleifenkopf, an dem die Bedingung falsch wird – oder den Durchlauf, in dem das Programm abbrechen würde (z. B. Zugriff auf alter[4] bei vier Elementen: Index außerhalb des Arrays, Laufzeitfehler).

• Nicht initialisierte Variablen markierst Du mit „?“ – das ist schon ein Fehler.

Testfalltabelle: erwartet gegen tatsächlich

Bei der Testfalltabelle interessiert Dich nicht jeder Zwischenschritt, sondern der Vergleich von erwartetem Ergebnis (aus der Anforderung, ohne Blick in den Algorithmus ermittelt) und tatsächlichem Ergebnis (durch Ablaufverfolgung im Entwurf ermittelt).

Testfalltabelle für den fehlerhaften Entwurf von gruppenpreis

Nr.	Eingabe	erwartetes Ergebnis (Vorgabe)	tatsächliches Ergebnis (Entwurf)	bestanden?
1	[34, 40]	16 €	8 €	nein
2	[17, 18]	12 €	8 €	nein
3	[3, 30]	8 €	8 €	ja

Wichtig ist die Schlussfolgerung: Stimmt auch nur ein Testfall nicht, ist der Entwurf fehlerhaft und muss korrigiert werden. Nach der Korrektur werden alle Testfälle erneut durchgeführt, weil eine Korrektur neue Fehler verursachen kann (Regressionstest). Umgekehrt beweist ein bestandener Test nicht, dass der Entwurf fehlerfrei ist – Testfall 3 besteht zufällig, obwohl zwei Fehler enthalten sind: Das erste Element (3 Jahre) wird ausgelassen, und der Erwachsene zahlt richtig.

Gute Testfälle wählst Du deshalb gezielt:

• Grenzwerte jeder Bedingung (17 und 18, 5 und 6, 9 und 10 Personen),

• je ein Wert aus jedem Zweig (jede Altersgruppe, mit und ohne Rabatt),

• Sonderfälle: erstes und letztes Element, leeres Array, ungültige Eingaben, nur ein Element.

Wie Du Testfälle systematisch über Äquivalenzklassen und Grenzwerte bildest, zeigen die Artikel zu Blackbox-Tests und zur Whitebox-Systematik.

Ein einzelnes Ergebnis gegen die Vorgabe prüfen

Manchmal liegt nicht der Algorithmus vor, sondern ein Ergebnis: ein erzeugter Code, ein berechneter Preis, eine angezeigte Zeit. Die Aufgabe lautet dann: Prüfe, ob es der Vorgabe entspricht, berichtige es gegebenenfalls und begründe. Vorgehen:

1. Vorgabe Schritt für Schritt auf die Eingabedaten anwenden (rechnen, nicht schätzen).

2. Eigenes Ergebnis mit dem gelieferten vergleichen.

3. Antwort mit drei Teilen formulieren: Entspricht es? – Warum nicht (welche Regel verletzt, mit Rechnung)? – Richtiges Ergebnis. Wenn möglich auch die vermutete Fehlerursache im Algorithmus nennen (z. B. „abgerundet statt aufgerundet“).

Beispiel: Eine Gruppe aus 10 Erwachsenen bekommt eine Rechnung über 72 €. Nach Vorgabe sind es 10 × 8 € = 80 € abzüglich 10 % = 72 €. Das Ergebnis stimmt. Hätte die Kasse 80 € berechnet, wäre die Begründung: Ab 10 Personen gilt 10 % Rabatt; vermutlich prüft der Algorithmus > 10 statt >= 10.

Fehler finden: die typischen Fehlerarten

Die meisten Fehler in Entwürfen gehören zu wenigen Arten. Wenn Du einen Entwurf prüfst, geh diese Liste systematisch durch:

Typische Fehlerarten in Programmentwürfen

Fehlerart	Beispiel im Entwurf	Korrektur	Auswirkung
Grenzwert/Vergleichsoperator	passwort.laenge > 10 bei „mindestens 10 Zeichen“	>= 10	genau der Grenzwert wird falsch behandelt
Schleifengrenze (off by one)	ZÄHLE i VON 0 BIS laenge(a)	BIS laenge(a) - 1	Zugriff hinter das Array-Ende, Laufzeitfehler
	ZÄHLE i VON 1 BIS … bei Index ab 0	VON 0	erstes Element fehlt
	Quartal mit ZÄHLE i VON 0 BIS 3	BIS 2	ein Monat zu viel
Startwert	summe := 100, Zähler gar nicht gesetzt	summe := 0, anzahl := 0	Ergebnis verfälscht oder undefiniert
Akkumulation	summe := wert oder summe := summe * wert	summe := summe + wert	nur letzter Wert bzw. immer 0
	fehlversuche := 1	fehlversuche := fehlversuche + 1	Zähler kommt nie über 1
Anweisung an falscher Stelle	anzahl := 0 in der Schleife; Gesamtsumme nach der Schleife aus dem letzten Einzelwert	vor bzw. in die Schleife verschieben	Zwischenstand geht verloren
falsche Bedingung	art = "B" im Zweig für Satz A; > 3 statt < 3	Bedingung bzw. Zweige tauschen	falscher Zweig wird ausgeführt
fehlender Fall	WENN privat … SONST … ohne eigene Prüfung für Sonderfall	weitere Verzweigung	Sonderfall landet im falschen Zweig
Reihenfolge der Bedingungen	alter < 18 vor alter < 6	engere Bedingung zuerst	unerreichbarer Zweig
überflüssige Anweisung	gefunden := falsch im Nein-Zweig einer Suche	Anweisung streichen	früherer Treffer wird überschrieben
fehlende Rückgabe	kein RÜCKGABE am Ende	RÜCKGABE ergebnis ergänzen	Aufrufer erhält kein Ergebnis
Datentyp, Deklaration	Durchschnitt als GANZZAHL, summe DIV n; Variable nicht deklariert	GLEITKOMMAZAHL, /; Deklaration ergänzen	Nachkommastellen gehen verloren
Formel	betrag * satz / (100 - satz) statt (100 + satz)	Formel nach Vorgabe	falsches Rechenergebnis
Ressourcen	Datei geöffnet, aber nicht geschlossen; Lesen ohne Prüfung auf Dateiende	close() nach der Schleife, SOLANGE NICHT datei.EOF	Datenverlust, Sperren, Endlosschleife
Endlosschleife	Zähler oder Lesezeiger in der Schleife nicht verändert	i := i + 1 bzw. nächsten Satz lesen	Programm hängt
Testdaten	Testdaten passen nicht zur Anforderung (vier Monatswerte für ein Quartal)	Testdaten berichtigen	Test sagt nichts aus

Zwei Prüfregeln findest Du schnell mit dem Auge: Jede Variable, die gelesen wird, muss vorher einen Wert bekommen haben. Und: Jede Schleife braucht eine Anweisung, die ihre Bedingung irgendwann falsch macht.

Fehler beschreiben, erläutern und korrigieren

Wie viel Du zu einem Fehler schreiben musst, hängt vom Operator ab:

• finden/markieren und korrigieren: Stelle kennzeichnen (z. B. mit Nummer im Diagramm) und die richtige Anweisung danebenschreiben.

• beschreiben: Was steht da, und was ist daran falsch? („Die Summe wird mit 100 statt mit 0 initialisiert.“)

• erläutern: zusätzlich die Auswirkung und den Grund. („… dadurch ist der Quartalsumsatz immer um 100 € zu hoch, weil der Startwert mit aufaddiert wird.“)

Eine gute Korrektur verändert nur, was falsch ist. Wenn Du ein Struktogramm umbauen musst, zeichne den betroffenen Block neu und kennzeichne, wo er hingehört.

Vorgaben ergänzen

Statt eines vollständigen Entwurfs ist oft ein Gerüst vorgegeben: ein Struktogramm mit leeren Blöcken oder nummerierten Lücken und eine Liste von Anweisungen oder Funktionen. Gehe dabei so vor:

1. Signatur und Vorgabe lesen: Was wird übergeben, was zurückgegeben, welche Funktionen stehen zur Verfügung?

2. Struktur erkennen: Wie viele Schleifen sind vorgegeben, sind sie geschachtelt? Eine Schleife im Rumpf einer anderen bedeutet „für jedes Element … für jedes Unterelement“.

3. Abhängigkeiten nutzen: Eine Anweisung kann nur dort stehen, wo alle Variablen, die sie benutzt, schon belegt sind. teilnahmen := teilnahmenVon(aktivitaeten[i].id) gehört also in die äußere Schleife (sie braucht i), aber vor die innere (die teilnahmen durchläuft).

4. Klammern schließen: Was geöffnet wird (Datei, Datenbankverbindung), wird nach der Schleife geschlossen. Was gezählt wird, wird vor der Schleife auf 0 gesetzt und zurückgegeben oder ausgegeben.

5. Probelauf: Spiel das ergänzte Gerüst mit einem Mini-Beispiel durch (ein Element, zwei Elemente).

Ein Sonderfall ist die zusammengesetzte Schleifenbedingung. Soll eine Maschine eine bestimmte Stückzahl fertigen, aber bei Not-Halt sofort stoppen, braucht die Schleife beide Bedingungen: SOLANGE i < anzahl UND nothalt = falsch. Damit die Schleife auf einen Not-Halt reagiert, muss der Zustand in der Schleife neu abgefragt werden.

Zwischen den Darstellungen übertragen

Häufig soll ein Entwurf einheitlich dokumentiert werden – etwa alles als Struktogramm. Die Übertragung von Pseudocode in ein Struktogramm ist fast mechanisch: Jede Zeile wird ein Block, jedes WENN eine Verzweigung, jede Schleife ein Schleifenblock mit eingerücktem Rumpf.

Schwieriger ist der Weg vom PAP ins Struktogramm. Ein PAP kann mit Pfeilen beliebig zurückspringen, ein Struktogramm kennt nur Blöcke, die vollständig ineinander oder untereinander liegen. Du musst im PAP deshalb zuerst die Strukturen erkennen:

• Ein Pfeil, der nach oben zurückführt, bildet eine Schleife. Liegt die Raute vor den Anweisungen, ist es eine kopfgesteuerte Schleife; liegt sie danach, eine fußgesteuerte.

• Zwei Zweige, die nach einer Raute wieder zusammenlaufen, bilden eine Verzweigung.

• Was zwischen Rücksprungziel und Raute liegt, ist der Schleifenrumpf.

Beispiel: Ein Alter wird so lange eingelesen, bis es im gültigen Bereich liegt.

Die Eingabe steht vor der Prüfung und wird mindestens einmal ausgeführt – also eine fußgesteuerte Schleife. Die Fehlermeldung wird nur ausgegeben, wenn noch einmal gefragt wird, deshalb braucht sie im Struktogramm eine eigene Verzweigung im Schleifenrumpf:

Wenn der PAP aus der Schleife herausspringt

Richtig knifflig wird es, wenn im PAP mehrere Ausgänge aus einer Schleife führen – etwa „Code richtig → fertig“ und „drei Fehlversuche → gesperrt“. Im Struktogramm gibt es keinen Sprung aus der Schleife (das Abbruch-Symbol der DIN 66261 wird in der Ausbildung kaum verwendet). Der übliche Umbau:

1. Alle Ausgangsbedingungen in eine Schleifenbedingung zusammenfassen. Die Schleife läuft weiter, solange keine der Abbruchbedingungen erfüllt ist: SOLANGE code <> richtigerCode UND versuche < 3.

2. Anweisungen, die im PAP nur auf dem Rücksprungweg liegen (z. B. „noch einmal versuchen“), in eine Verzweigung im Rumpf stellen.

3. Nach der Schleife mit einer Verzweigung unterscheiden, über welchen Ausgang die Schleife verlassen wurde, und dort die jeweiligen Ausgaben und Rückgaben einsetzen.

Achte beim Zusammenfassen auf De Morgan: Abbruch bei „Code richtig oder drei Versuche“ heißt Weiterlaufen bei „Code falsch und weniger als drei Versuche“.

Welche Darstellung wofür?

Darstellungsformen im Vergleich

Darstellung	Stärken	Schwächen	gut geeignet für
Pseudocode	schnell geschrieben, leicht zu korrigieren, nah am Programmcode	Struktur nur über Einrückung sichtbar, keine Norm	Entwurf, Lösungen unter Zeitdruck, Code-Reviews
Struktogramm	Schachtelung sofort sichtbar, erzwingt strukturierte Algorithmen (keine Sprünge)	nachträgliches Einfügen auf Papier mühsam, Breite muss geplant werden	Dokumentation, Fehlersuche in Schachtelungen, Lehre
PAP	anschaulich, auch für Nicht-Programmierende verständlich	Sprünge erlauben unstrukturierte Abläufe („Spaghetti“), wird bei großen Algorithmen unübersichtlich	grobe Abläufe, Bedienabläufe, Kommunikation mit Fachabteilungen

In Aufgaben ist die Form meist freigestellt („in Pseudocode, als Struktogramm oder als PAP“). Nimm die Form, in der Du am sichersten bist – für Korrekturen ist Pseudocode am praktischsten, weil Du einfach Zeilen einfügen kannst.

Typische Fehler beim Lesen und Zeichnen

• Rumpf falsch abgegrenzt: Im Struktogramm gehört nur das zur Schleife, was im eingerückten Teil steht. Eine Ausgabe unter dem Schleifenblock wird einmal ausgeführt, nicht in jedem Durchlauf.

• Raute mit einem Ausgang: Jede Raute im PAP braucht zwei beschriftete Ausgänge (ja/nein); jeder Zweig muss irgendwo weitergehen.

• Zuweisung und Vergleich verwechselt: := setzt einen Wert, = vergleicht. In einer Bedingung steht nie :=.

• Fußgesteuerte Schleife falsch gelesen: WIEDERHOLE … SOLANGE bed läuft weiter, solange bed wahr ist; REPEAT … UNTIL bed (Pascal) endet, sobald bed wahr ist. Bei Übertragungen kehrt sich die Bedingung um.

• Vorgaben ignoriert: Vorgegebene Funktionen, Variablennamen und Signaturen wörtlich übernehmen; nicht nachbauen, was als Funktion bereitsteht.

• Nur den Normalfall getestet: Ohne Grenzwerte und Sonderfälle findet ein Schreibtischtest die typischen Fehler nicht.

Leitfragen

1. Welche Strukturblöcke kennt das Struktogramm nach DIN 66261, welche Sinnbilder der PAP nach DIN 66001, und wie sehen die entsprechenden Pseudocode-Konstrukte aus? Antwort

Alle drei Formen bilden Folge, Verzweigung und Schleife ab: Das Struktogramm nach DIN 66261 nutzt geschachtelte Strukturblöcke (Rechteck für Anweisungen, Block mit Dreieck für Verzweigungen, L-förmige Blöcke für kopf- und fußgesteuerte Schleifen), der PAP nach DIN 66001 Sinnbilder wie Grenzstelle, Rechteck, Parallelogramm für Ein-/Ausgabe und Raute mit zwei Ausgängen. Im Pseudocode entsprechen dem WENN … DANN … SONST … ENDE WENN, SOLANGE … ENDE SOLANGE, WIEDERHOLE … SOLANGE, ZÄHLE i VON … BIS … und RÜCKGABE (siehe Abschnitt „Drei Darstellungsformen, drei Kontrollstrukturen“).

2. Wie gehst Du vor, um für einen konkreten Aufruf die Rückgabe eines verschachtelten Algorithmus zu bestimmen? Antwort

Ordne zuerst die Werte des Aufrufs den Parametern zu (nach Reihenfolge, nicht Name), gehe bei Verzweigungen von außen nach innen genau einen Zweig und notiere den Weg, achte bei Grenzwerten auf < und <=, und werte zusammengesetzte Bedingungen mit UND/ODER vollständig aus. Bei Schleifen hilft ein Mitschreiben der Variablenwerte (siehe Abschnitt „Einen Entwurf lesen: Was liefert der Algorithmus?“).

3. Wie ist eine Trace-Tabelle aufgebaut, und woran erkennst Du darin einen Fehler bei der Schleifengrenze oder beim Startwert? Antwort

In einer Trace-Tabelle hat jede veränderliche Variable eine Spalte, die Startwerte stehen in einer eigenen Zeile, danach folgt meist eine Zeile je Schleifendurchlauf. Einen Fehler bei der Schleifengrenze erkennst Du daran, dass ein Index fehlt (z. B. beginnt die Tabelle bei i = 1 und das erste Element wird nie betrachtet) oder ein Zugriff hinter das Array-Ende entsteht; einen Startwertfehler an einem falschen Wert in der Startzeile oder an einem „?“ für eine nicht initialisierte Variable (siehe Abschnitt „Trace-Tabelle: jeden Schritt mitschreiben“).

4. Was unterscheidet das erwartete vom tatsächlichen Ergebnis in einer Testfalltabelle, und welche Schlussfolgerung ziehst Du aus abweichenden Testfällen? Antwort

Das erwartete Ergebnis ermittelst Du aus der Anforderung, ohne in den Algorithmus zu schauen, das tatsächliche durch Ablaufverfolgung im Entwurf. Weicht auch nur ein Testfall ab, ist der Entwurf fehlerhaft und muss korrigiert werden; danach führst Du alle Testfälle erneut aus (Regressionstest). Umgekehrt beweisen bestandene Testfälle nicht, dass der Entwurf fehlerfrei ist (siehe Abschnitt „Testfalltabelle: erwartet gegen tatsächlich“).

5. Wie prüfst Du ein einzelnes Ergebnis gegen eine Vorgabe, und was gehört in eine vollständige Begründung? Antwort

Du wendest die Vorgabe Schritt für Schritt auf die Eingabedaten an (rechnen, nicht schätzen) und vergleichst Dein Ergebnis mit dem gelieferten. Eine vollständige Begründung hat drei Teile: Entspricht das Ergebnis der Vorgabe? Warum nicht – welche Regel ist verletzt, mit Rechnung? Wie lautet das richtige Ergebnis? Wenn möglich nennst Du auch die vermutete Fehlerursache, z. B. > 10 statt >= 10 (siehe Abschnitt „Ein einzelnes Ergebnis gegen die Vorgabe prüfen“).

6. Welche Fehlerarten treten in Programmentwürfen besonders häufig auf, und wie korrigierst Du sie? Antwort

Häufig sind falsche Grenzwerte oder Vergleichsoperatoren, Schleifengrenzen (off by one), falsche Startwerte, fehlerhafte Akkumulation (summe := wert statt summe := summe + wert), Anweisungen an falscher Stelle, falsche Bedingungen oder fehlende Fälle, eine falsche Reihenfolge in SONST WENN-Ketten, fehlende Rückgaben, falsche Datentypen, nicht geschlossene Ressourcen und Endlosschleifen. Korrigiert wird gezielt nur die fehlerhafte Stelle; beim Erläutern nennst Du zusätzlich Auswirkung und Grund (siehe Abschnitt „Fehler finden: die typischen Fehlerarten“ und Abschnitt „Fehler beschreiben, erläutern und korrigieren“).

7. Wie ergänzt Du ein vorgegebenes Struktogramm mit geschachtelten Schleifen folgerichtig? Antwort

Lies zuerst Signatur und Vorgabe, erkenne die Struktur der geschachtelten Schleifen („für jedes Element … für jedes Unterelement“) und platziere jede Anweisung dort, wo alle benutzten Variablen schon belegt sind – z. B. eine Anweisung mit i in der äußeren, aber vor der inneren Schleife. Was geöffnet wird, schließt Du nach der Schleife, Zähler setzt Du vor der Schleife auf 0, und zum Schluss spielst Du das Gerüst mit einem Mini-Beispiel durch (siehe Abschnitt „Vorgaben ergänzen“).

8. Wie überträgst Du einen PAP mit Rücksprüngen und mehreren Schleifenausgängen in ein Struktogramm? Antwort

Erkenne im PAP zuerst die Strukturen: Ein Pfeil nach oben bildet eine Schleife (Raute davor: kopfgesteuert, danach: fußgesteuert), zusammenlaufende Zweige eine Verzweigung. Mehrere Schleifenausgänge fasst Du zu einer Schleifenbedingung zusammen, die läuft, solange keine Abbruchbedingung erfüllt ist (De Morgan beachten), Anweisungen auf dem Rücksprungweg kommen in eine Verzweigung im Rumpf, und nach der Schleife unterscheidest Du mit einer Verzweigung, über welchen Ausgang sie verlassen wurde (siehe Abschnitt „Zwischen den Darstellungen übertragen“ und Abschnitt „Wenn der PAP aus der Schleife herausspringt“).

Links und weitere Informationen

• Übungsaufgaben zum Programmentwurf

• Algorithmen mit Pseudocode dokumentieren

• Übersicht der Programmentwurfsmethoden

• Prozedurale Algorithmen mit Arrays: suchen, zählen, Extremwerte und Gruppenwechsel

• UML-Aktivitätsdiagramm

• als Norm: DIN 66001:1983-12 „Informationsverarbeitung; Sinnbilder und ihre Anwendung“ und DIN 66261:1985-11 „Informationsverarbeitung; Sinnbilder für Struktogramme nach Nassi-Shneiderman“ (beide über DIN Media)

• zum Ausprobieren: Struktogrammeditor der TU Dresden und Structorizer zum Zeichnen und Ausführen von Struktogrammen

---

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: “Programmentwürfe lesen, prüfen und korrigieren: Pseudocode, Struktogramm und PAP” von Hannes Stein, Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/programmentwurf 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]