Das Verb entwerfen findet sich bereits im Mittelhochdeutschen als Fachwort in der Bildwirkerei.
Es bedeutete ursprünglich "ein Bild gestalten":
Beim Weben wurde der Schussfaden durch die aufgespannten Kettfäden geworfen um ein bestimmtes Motiv zu entwerfen.
Noch heute wird die Phrase "ein Bild hinwerfen" im Zusammenhang mit einer zeichnerischen Darstellung als synonym zu "(schnelles) skizzieren" verstanden.

— Wikipedia: Entwerfen

In unserem Programm haben wir es nur mit vier Datenwerten zu tun. In größeren Programmen werden es mehr sein. Um den Überblick zu behalten, wird ein Datenkatalog angelegt:

Die Variablennamen werden nicht auf einen Buchstaben verkürzt. Ausgeschriebene Namen machen den Code lesbarer. Man muss nicht erst darüber nachdenken, ob R nun Räder (Motorräder?) oder Reifen bedeutet. Das Wort reifen ist eindeutig. In vielen Sprachen ist es üblich, Variablennamen mit Kleinbuchstaben zu beginnen. Manche Programmiersprachen mögen Umlaute im Quelltext nicht. In moped kommt kein Umlaut darin vor, außerdem ist einfach etwas kürzer. Hoffentlich steigen mir die Fahrer größerer Zweiräder nicht aufs Autodach, weil sie die Bezeichnung als beleidigend empfinden.

Der Entwurf eines Algorithmus lässt sich als Pseudocode notieren:

Algorithmus Parkplatz1

Variablen: fahrzeuge, reifen, autos, mopeds (ganzzahlig)
Eingabe: fahrzeuge, reifen
mopeds = (4*fahrzeuge - reifen)/2
autos = fahrzeuge - mopeds
Ausgabe: autos, mopeds

Den Alternativentwurf notiere ich einmal als Struktogramm (Struktogrammelemente siehe steuern_svg.pdf). Interessanterweise geht das auch ohne weitere Hilfsmittel als ASCII-Text, auch wenn nicht besonders hübsch aussieht:

Algorithmus Parkplatz2
 
START
|-----------------------------------------|
| Var.: fahrzeuge, reifen, autos, mopeds  |
|-----------------------------------------|
| E: fahrzeuge, reifen                    |
|-----------------------------------------|
| autos = fahrzeuge                       |
|-----------------------------------------|
| mopeds = 0                              |
|-----------------------------------------|
| Solange reifen < 4*autos + 2*mopeds ist |
|  +--------------------------------------|
|  | vermindere autos um eins             |
|  |--------------------------------------|
|  | erhöhe mopeds um eins                |
|-----------------------------------------|
| A: autos, mopeds                        |
|-----------------------------------------|
ENDE

Es gibt Entwurfswerkzeuge, sog. CASE-Tools, die, z.T. für viel Geld, solche technischen Zeichnungen ansprechender gestalten, daraus Quellcode generieren, wenn in die Kästchen syntaktisch korrekte Anweisungen geschrieben wurden, oder umgekehrt aus Quellcode Struktogramme erzeugen.

Als Übungsaufgabe bleibt folgende Frage: Warum haben sich diese Werkzeuge bisher nicht durchgesetzt?¹⁾

Haben wir die später vom Computer auszuführenden Anweisungen erst einmal fixiert, können wir prüfen, ob diese Anweisungen zum richtigen Ergebnis führen werden. Wir führen einen Schreibtischtest durch, bevor wir eine Zeile Quelltext geschrieben haben. Wenn der Schreibtischtest nicht funktioniert, brauchen wir uns auch nicht die Mühe machen, das fehlerhafte Programm einzutippen.

Übungsaufgabe: Führe in Gedanken in Anweisungen der beiden Programme Schritt für Schritt aus, wie Du es von Computer erwarten würdest. Setze als Datenwerte 4 Fahrzeuge mit 10 Reifen ein. Wenn Du wie ich die 4 Zahlen nicht gleichzeitig im Kopf behalten kannst, notiere sie auf Papier. Es entsteht eine Wertverlaufstabelle. Prüfe, ob die entstandenen Ergebnisse richtig sind.

Der Entwurf wird als möglicherweise funktionstüchtig eingestuft. Bis hierhin war die Arbeit unabhängig von der Programmiersprache. Je nach Wahl der Implementierungssprache wird der Programmtext nun anders aussehen. Versuche das Programm Parkplatz1 nun in die Programmiersprache C++ zu übersetzen.

• Wie sieht der Programmrahmen in der gewählten Programmiersprache aus?
• Wie werden Speicherplätze für die Unbekannten (Variablen) vereinbart?
• Wie werden Variablen eingelesen, wie ausgegeben?
• Wie müssen Rechenanweisungen codiert werden.

Anfänger sollten an dieser Stelle der Versuchung wiederstehen, gleich am Computer zu arbeiten. Suche die einzelnen Programmteile aus der Sprachreferenz zusammen. Notiere sie handschriftlich! Das wichtigste Werkzeug des Programmierers sind Bleistift und Papier. Schreibe das komplette Programm auf Notizpapier. Der Quelltext muss so mehrfach durch den Kopf. Er prägt sich ein. Du hast beim Schreiben und Wiederdurcharbeiten Gelegenheit, nochmal darüber nachzudenken, warum jede Programmzeile so aussehen muss.

Das Eintippen ist dann ein Kinderspiel, vorausgesetzt, Du bist mit Deinem Editor vertraut. Gewöhne Dir an, immer wieder die Änderungen zu speichern. Ich habe diesen Vorgang schon automatisiert: Nach jedem abgeschlossenen Gedankengang folgt die Tastenfolge "Escape :w Enter" im vi, "Strg+S" im Windows-Editor oder "Alt D S" im edit. Nichts ist ärgerlicher, als nach einer halben Stunde Arbeit wegen einer Schusselei alles zu verlieren.

Ist der Quelltext fertig, vergleiche ihm nochmal mit dem Papier-Entwurf. Korrigiere Fehler durch die Methode "Scharfes Hinsehen". Das erspart unzählige Übersetzerläufe.

Hast Du alles richtig gemacht, müsste der Quelltext auf Anhieb übersetzbar sein. Die anfängliche Mühe bei der Planung wird durch die verkürzte Implementierungszeit aufgewogen. Je eher ein Fehler entdeckt wird, umso geringer sind die Kosten für seine Behebung.

Setze als Übung auch den Alternativ-Entwurf Parkplatz2 in C++ um und teste aus, wie lange es auf einem PC bis zur Ausgabe der Lösung dauert, wenn etwa eine Million Fahrzeuge mit zwei Millionen Reifen auf einem Parkplatz stehen. Dagegen ist das Programm sehr schnell fertig, wenn genauso viele Fahrzeuge mit vier Millionen Reifen auf dem Platz sind.

Vergleichen wir den entstandenen Quelltext.

Weiter: Teil 5.