Die Programmierung


Begriff des Programmierens

Die Programmierung ist ein sehr weit gesteckter Oberbegriff. Viele assoziieren zu Recht diesen Begriff mit einem Computer und glauben: "Der kennt sich mit einem Computer bestimmt gut aus". Das mag in einem gewissen Rahmen auch stimmen, doch das liegt nicht allein an der Arbeit des Programmierens. Der Computer ist mein tägliches Handwerkzeug und deshalb sollte ich mich relativ gut damit auskennen. Ich muss wissen, wie ein Computer arbeitet und funktioniert, um vernünftig damit umgehen zu können.

Die vielen möglichen assoziativen Bilder, die mit einem Programmierer verbunden sind, lassen sich noch erweitern, wenn ich Bezug nehme auf Programmierungen, die nichts oder kaum etwas mit einem Computer zu tun haben. Viele von Ihnen mögen schon den Begriff des "Neurolinguistischen Programmierens" kurz (NLP) gehört haben. Ich möchte hier nicht weiter auf den Begriff eingehen, sondern einfach nur zeigen, wie vielfältig das Programmieren sein kann. Vorgänge im Gehirn eines Menschen sollen mit Hilfe des NLP's auf Basis systematischer Handlungsanweisungen änderbar sein.

Die Analogie meiner Programmierarbeit liegt darin, dass Vorgänge in einem Computer mit Hilfe der Programmierung auf Basis systematischer Handlungsanweisungen änderbar sind. Das ist natürlich sehr abstrakt und grob formuliert.

Ein Computer kann ohne jegliche Programmierung nur elektrischen Strom verbrauchen und infolge dessen, aus physikalischen Gründen, etwas Wärme abgeben. Zu mehr ist er ohne die Programmierung nicht imstande. Jede noch so kleine weitere Annehmlichkeit eines Computers, wie zum Beispiel das Starten eines Betriebssystems, gleich welcher Art, ist mit vorheriger mehr oder weniger aufwändiger Programmierung verbunden. Das Betriebssystem ist im weitesten Sinne mit einem Programm vergleichbar, an dem viele Programmierer gearbeitet haben. Diese Programmierer definierten mit ihrer Arbeit, wie der Computer arbeiten soll und welche Komponenten dazu benötigt oder geladen werden sollen. Auch sogenannte Treiber wie etwa ein Druckertreiber haben wiederum andere Programmierer erarbeitet.

Nehmen wir als Beispiel den einfachen Taschenrechner, der mit dem Betriebssystem "Microsoft Windows" ausgeliefert wird. Wird dieser Taschenrechner gestartet, erscheint er auf dem Bildschirm als ein relativ einfaches Programm. Doch auch dieses Programm musste zunächst von einem oder mehreren Programmierern erarbeitet werden. Der oder die Programmierer mussten zunächst programmieren, wie das Programmfenster aussehen soll. Sie gaben vor, wie das Ergebnis- Ausgabefeld aussehen soll, wo die Eingabefelder etc. angeordnet sind und dass der Anwender möglicherweise seine Tastatur oder auch die Maus zur Eingabe bzw. Bedienung verwendet. Es musste ebenso genau in den Programmzeilen festgelegt werden, was passieren soll, wenn beispielsweise zukünftig "5 * 5 =" eingetippt wird. Das danach die Zahl 25 in dem Ausgabefeld als richtiges Ergebnis erscheint ist nicht selbstverständlich; und das passiert nicht einfach so. Man musste in der Entwicklung dem entstehenden Taschenrechner mitteilen, was er bei solchen Eingaben machen soll, nämlich rechnen und danach eine Ausgabe auf dem Bildschirm präsentieren. Solche Aufgaben wie etwa 5*5 sind noch relativ einfach, doch wie sehen die Programmzeilen aus, wenn der Anwender verschachtelte Klammerrechnungen, Wurzelberechnungen, oder Sinusfunktionen anwenden möchte?

Diskrepanz zwischen Anerkennung und der Programmierarbeit

Manchmal entstehen im Rahmen von Programmentwicklungen gewisse Diskrepanzen zwischen Anerkennung und den Programmierarbeiten. Während sich die Anwenderinnen und Anwender komfortable und einfach zu bedienende Programme wünschen, programmiert der Programmierer aufwändige Programmzeilen, um dies zu realisieren. Die Anwender finden zuletzt wie gewünscht ein einfach zu bedienendes und vor allem zuverlässiges Programm vor, können jedoch nicht ahnen, welcher Entwicklungsaufwand sich hinter solch einem Programm verbirgt.

Beispiel: Mein zweitgrößtes Projekt, welches ich in meiner Vergangenheit entwickelte, war ein sogenannter Submitter. Dieser Submitter hatte die Aufgabe, zahlreiche "URLs" und Domain- Informationen eines größeren Unternehmens aufzunehmen und weltweit an möglichst viele Suchmaschinen im Internet anzumelden. Nach Fertigstellung des Projektes fand man ein relativ übersichtliches und einfach zu bedienendes Programm vor. Nach dem Beladen von notwendigen Informationen, wie etwa URLs- bzw. Domain- Informationen, brauchten sie nur noch auf einen Startknopf klicken. Alle anderen Arbeiten übernahm das Programm vollautomatisch. Die Anwender sahen nur wenige Objekte, wie etwa Kontrollobjekte, oder den Beenden - Button, auf der Programmoberfläche. Sie konnten jedoch nicht ahnen, dass sich hinter dem Programm mehr als 15000 wirklich notwendige und teils komplexe Programmzeilen in den verschiedenen Modulen verbargen.

Die Entwicklungszeit

Man mag vermuten, wenn man sich noch nie an eine Programmierung herangewagt hat, dass die meiste Entwicklungszeit in die Realisierung der einzelnen direkten Programmaufgaben investiert wird. Doch jeder Programm- Entwickler wird bald merken, solange er Wert auf fehlerfreie und zuverlässige Programme legt und vor allem durchdachte Strukturen einfließen lassen möchte, dass er für die unmittelbare Realisierung der Programmaufgaben meistens nur ein Drittel der Gesamtzeit benötigt. Die restliche Zeit wird für zusätzliche Verbesserungen, Tests und Fehlervermeidungen verwendet.

Beispiel: Nehmen wir wieder den oben erwähnten Taschenrechner. Die Zeitplanung für ein solches Programm mag vielleicht relativ einfach sein, solange der Entwickler, was vorausgesetzt wird, einigermaßen in die Mathematik involviert ist. Doch was ist bei Fehleingaben des Anwenders? Wir wissen, eine Division durch Null ist nicht erlaubt. Der Programmentwickler muss dennoch in seine Arbeiten einplanen, dass der Anwender es darauf anlegen könnte, eine Division durch Null durchführen zu wollen. Oder was passiert, wenn der Anwender statt Zahlen und mathematische Symbole auf einmal fließenden Text mit einfließen lassen möchte?

Ein weiteres Beispiel wäre mein kurz umschriebenes Projekt, der Submitter. Daten an eine Suchmaschine zu senden ist relativ einfach. Doch Fehler können durchaus auch unvorhergesehen eintreten. Der Anwender könnte vergessen haben, vor Arbeitsbeginn eine Verbindung mit dem Internet herzustellen. Eine mögliche Fehlerbeseitigung wäre, das Programm überprüft dies vor Arbeitsbeginn und führt ggf. selbst eine Konnektivität herbei. Doch auch hier können wiederum Fehler auftreten, wenn zum Beispiel der Anwender falsche Zugangsdaten eingegeben hat. Oder vielleicht ist der betreibende Rechner online, nur die Suchmaschine ist vorübergehend nicht erreichbar. Vielleicht besteht auch während der Arbeit eine plötzliche Internetstörung. Wie dem auch immer sei, die Liste der möglichen Fehlerquellen sind sehr lang. Diese müssen jedoch bei einem zuverlässigen Programm immer mit in die Entwicklung eingeplant werden.

Die Entstehung eines Programmes

Doch wie entsteht eigentlich ein für den Computer ausführbares Programm?
Ein Computer kann unsere menschliche Sprache nicht verstehen. Würden wir auf einem Rechner eine Datei "rechner.exe" abspeichern, so könnten wir in die Datei zuvor hineingeschrieben haben: "Schreibe auf dem Bildschirm das Ergebnis von 5*5". Sollten wir nun versuchen diese Datei auszuführen, hätten wir keinen Erfolg, weil der Rechenprozessor diese Anweisung bzw. den Inhalt der Datei nicht verstehen und somit auch nicht verarbeiten kann. Ich möchte übrigens dringend davon abraten, dieses Experiment auszuprobieren, da dies insbesondere bei älteren Betriebssystemen, wie etwa MS-DOS zu einem fatalen Systemabsturz führen könnte.

Program Rechnen;
  uses crt, dos;
  var Zahl: Integer;
BEGIN
  Zahl := 5*5;
  Write(Zahl);
END.

Ich möchte an dieser Stelle die einzelnen Programmzeilen nicht näher erläutern. Es soll nur anschaulich werden, wie eine vorgeschriebene Syntax, die "menschennahe" Sprache, für das kleine Ausgabebeispiel aussehen kann.

Es gibt zahlreiche weitere Programmiersprachen, von denen ich einige noch auf Folgeseiten umschreiben werde.

Samstag, 27. Juli 2024