0. Top-Down-Entwicklung am Beispiele
1. Programmentwicklung - Top-Down-Denken
2. Programmfehler
3. Compiler und/oder Interpreter
4. Anforderungen an ein Pogramm und an den Programmierer
5. Programm-Dokumentation
6. Maschinenprogrammierung
7. Echtzeitverhalten und Echtzeitsysteme
8. Programmierbeispiele
9. Verwandte Themen

• Lehr- und Übungsbuch Informatik Band 1 - 5 Seite ???
• Technische und Theoretische Informatik  Seite ???

Stammbaum der Programmiersprachen	Programmierwerkzeuge - Editoren

Fehler verhindert man dadurch, dass man keine Fehler macht. Zu diesen Zweck sollte man zuallererst gute und vernünftige Werkzeuge benutzen. Dazu gehören eine dem Problem angemessene Sprache und gute, zuverlässige Compiler.

Als nächstes sollte man die Maxime „Erst überlegen, dann programmieren“ beherzigen. Das Programm, die Module, die Datenstrukturen sollen vorher geplant sein. Wenn das Design nicht stimmt, kann das Programm später sehr kompliziert werden. Je komplizierter ein Programm ist, um so  höher seine Fehleranfälligkeit. Früh begangene Fehler rächen sich später. Je später ein Fehler gefunden wird, um so mehr Kosten verursacht er.
Als dritter Punkt ist ein sauberer, klarer Programmierstil wichtig. Der Versuchung, durch undurchsichtige Tricks noch ein Quentchen Effizienz hervorzukitzeln, sollte unbedingt widerstanden werden. Erst nachdem ein Programm korrekt läuft, ist es angebracht, mit Werkzeugen wie Profilern die Stellen herauszufinden, wo sich eine Effizienzsteigerung auswirken würde, und diese Stellen punktuell zu optimieren. Zu einem guten Programmierstil gehört natürlich auch, das Programm für menschliche Leser verständlich und übersichtlich zu halten. Unabdingbar sind in diesem Zusammenhang eine gute Dokumentation, ein Zerlegen in überschaubare Teilaufgaben, die Vermeidung von globalen Variablen und Seiteneffekten.

Auch dem gewissenhaftesten Programmierer unterläuft trotz aller Vorsichtsmaßnahmen gelegentlich ein Fehler. Um solche Fehler zu finden und ggf. zu vermeiden, bietet der Compiler gewisse Möglichkeiten: Durch Schalter (switches) lassen sich Prüfroutinen in den Code einbinden, die Bereichsüberschreitungen, Stack-Überlauf und falsche Eingabewerte abfangen. Erst wenn auf diese Weise das Vertrauen in die Software gestärkt wurde, stellt man die Schalter so, dass die Prüfroutinen weggelassen werden. Aber auch ohne Hilfsmittel kann der Programmierer das interne Verhalten des Programms diagnostizieren. Durch WRITE-Befehle können Inhalte von Variablen, Parametern und Zwischenwerten ausgegeben werden. Zwischenbehauptungen, d.h. Annahmen über die Beziehung von Variablen untereinander, können getestet werden, wenn sie als Boolesche Ausdrücke formuliert vorliegen. Ist eine solche Zwischenbehauptung nicht erfüllt, so wird ein Fehler gemeldet. Als Testroutine könnte die folgende Prozedur dienen:

PROCEDURE assert (f_behauptung:BOOLEAN;f_nummer:INTEGER); 

BEGIN{begin of procedure assert}
  IF NOT f_behauptung
  THEN
  BEGIN{begin of then}
    WRITELN(‘Zwischenbehauptung Nr. ’,f_nummer,’ verletzt’);
    assert((x>0)AND(sum=x*(x+l) div 2),17);
  END;{end of then}
END;{end of procedure assert}

Wird während des Programmablaufes eine solche Zwischenbehauptung verletzt, so erfolgt eine entsprechende Fehlermeldung.
Alle diese Methoden sind Testmethoden. Sie sind einfach durchzuführen, führen schnell zum Ziel und sind auch bei beliebig komplexen Programmen anwendbar. Leider sind Testmethoden unzuverlässig, weil man nie alle möglichen Eingaben testen kann. Ein Zitat von E. DIJKSTRA bringt dies auf den Punkt: „Durch Testen kann man die Anwesenheit, nie aber die Abwesenheit von Fehlern zeigen.“
Dem wollen wir nun eine Methode entgegensetzen, mit der die Korrektheit von Programmen formal bewiesen werden kann. Die Methode ist nicht schwierig, aber dennoch aufwendiger als das Testen. Daher lohnt sich eine formale Verifikation nur bei Anwendungen, deren absolute Zuverlässigkeit gewährleistet sein muss.
In Analogie zur Mathematik kann man feststellen, dass sich das Testen von Programmen zur Verifikation von Programmen verhält wie das Ausprobieren von mathematischen Sätzen zu deren Beweis.

1.  ...lassen ihren Nutzer nie vor einem leeren Monitor sitzen, sondern informieren immer, was getan werden kann oder muss um weiterzukommen. Dabei ist die Menüführung eindeutig, überlegt sowie leicht überschaubar. Bei komplexeren Abläufen ist eventuell eine kontextbezogene Hilfe vorzusehen.
2.  ...verfügen über eine logisch klare und minimal orientierte Datenvergabe.
3.  ...fangen fehlerhafte Eingaben (Bereichsüberschreitungen, falsche Tasten, falsche Laufwerkszugriffe, Buchstaben statt Zahlen und umgekehrt usw.) mit entsprechenden Informationen für den Nutzer ab. Im Prinzip dürfen keine Laufzeitfehler auftreten.
4. ...enthalten soviel Kommentare, wie Quelltext selbst!
5.  ...sind gut strukturiert und damit leicht lesbar - die Funktion jeder Variablen ist aus dem Listing entnehmbar (gegebenenfalls werden mögliche Werte der Variablen im Text notiert).
6.  ...führen mit knappen, aber präzise formulierten Aussagen über den Monitor (orientieren Sie sich dabei an professioneller Software).
7.  ...enthalten in jedem Programmblock eine kurze Information, welche Funktion er ausführt.
8.  ...greifen auf Dateien niemals zerstörend zu - Fehlbedienungen sind abzuweisen.
   9. ...verwenden Farbe sparsam und mit Funktion - besonders eignen sich ansonsten blauer Hintergrund mit weißem Text (Hervorhebungen mit gelb betonen!).
9. ...nutzen keine unnötigen Spielereien (Blinken, Ton usw.), sondern konzentrieren sich auf das versprochene Leistungsangebot, welches knapp als Eingangsmenü geboten werden sollte.
10. ...bringen Sprunganweisungen nur nach vorn zur Anwendung, ansonsten (rückwärts) nur um Schleifen zu schließen. Jedes Programm verfügt über nur eine END-Anweisung.
11. ...wenden sich immer an den „naiven“ Nutzer und schränken diesen so wenig wie möglich ein - bieten statt dessen selbst einen großen Leistungsumfang.
12. ...sind wartungsfreundlich und nach oben offen - also überschaubar!
13. ...sind modular aufgebaut und verwenden möglichst viele Subroutinen (Unterprogramme), welche klein und universell verwendbar sind
14. ...wechseln zwar Verzeichnisse, kehren aber nach Programmende selbständig in's Ausgangsverzeichnis zurück!
15. ...erreichen in einer, dem Problem relevanten Abarbeitungszeit eine eindeutige und möglichst richtige Lösung!

Demgegenüber werden auch Sie nach kurzer Zeit feststellen, dass dies einfach und logisch klingt, jedoch gar nicht so einfach realisierbar ist!

Und nun folgen die Forderungen an Sie:

I. Sinn und Zweck des Programms darlegen.
II. Programm in logisch möglichst unabhängige Blöcke gliedern.
III. Schnittstellen zwischen den Stellen explizit angeben., Informationsfluss zwischen den Blöcken über die Schnittstellen abwickeln.
IV. Programmtext optisch gliedern.
V. nach Bedarf Kommentare einfügen.
VI. Variablen und Konstanten ihrer Bedeutung gemäß benennen.
VII. Vor jede Eingabe eine Anfrage des Rechners stellen, Antwortalternativen angeben.
VIII. Jeder Ausgabe einen erläuternden Text beigesellen.
IX. Einfach und direkt programmieren, keine Tricks; Klarheit und Übersichtlichkeit haben Vorrang vor Schnelligkeit im Ablauf.
X. Ergebnisse im Zusammenhang des gegebenen Problems interpretieren.

... dieser Text wurde nach den Regeln irgendeiner Rechtschreibreform verfasst - ich hab' irgendwann einmal beschlossen, an diesem Zirkus (das haben wir schon den Salat - und von dem weiß ich!) nicht mehr teilzunehemn ;-)

„Dieses Land braucht eine Steuerreform, dieses Land braucht eine Rentenreform - wir schreiben Schiffahrt mit drei „f“!“

Diddi Hallervorden, dt. Komiker und Kabarettist

Diese Seite wurde ohne Zusatz irgendwelcher Konversationsstoffe erstellt ;-)