Grundlagen der Informatik I “Programmierung”
Grundlagen der Informatik I “Programmierung”
Grundlagen der Informatik I “Programmierung”
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
An<strong>der</strong>erseits darf man sich aber auch nicht zu sehr auf seine Intuition und den gesundem Menschenverstand<br />
verlassen, da hierdurch zu viele schlechte Entwürfe und Fehler entstehen.<br />
Angestrebt werden sollte stattdessen ein ausgewogenes Gleichgewicht zwischen den beiden. Offensichtliches 48<br />
sollte unerwähnt bleiben, wichtige Punkte hervorgehoben werden und soviel Details hinzugefügt werden, wie<br />
für ein Verständnis nötig sind. Hierzu muß eine weniger formale, aber konsistente Notation eingeführt werden.<br />
Nur beim Auftreten von Schwierigkeiten sollte auf den genauen Formalismus zurückgegriffen werden.<br />
Dieses Gleichgewicht, das schon in <strong>der</strong> Mathematik von großer Bedeutung ist, ist für die Programmierung<br />
beson<strong>der</strong>s wichtig. Programme enthalten so viele Details, die absolut korrekt sein müssen. Auf <strong>der</strong> an<strong>der</strong>en<br />
Seite sind sie oft so groß, daß ein Einzelner sie kaum noch lesen kann.<br />
Entwurfsprinzip 4.5.5 (Formalismus und gesun<strong>der</strong> Menschenverstand)<br />
Benutze die Theorie, um Erkenntnisse zu erhalten; verwende Intuition, wo es angebracht ist; greife auf<br />
Formalismen als Hilfsmittel zurück, sobald Schwierigkeiten o<strong>der</strong> komplizierte Details auftreten.<br />
Dies erfor<strong>der</strong>t natürlich Erfahrung – sowohl im Umgang mit <strong>der</strong> formalen Theorie als auch mit dem Einsatz<br />
von Intuition bei Begründungen. Es lohnt, sich Erfahrung mit Formalismen dadurch anzueignen, indem man<br />
die vielen kleinen Routineprogramme, die man zu schreiben hat, sehr sorgfältig implementiert und verifiziert.<br />
Der Nebeneffekt dieser Vorgehensweise ist, daß eine <strong>der</strong> größten Fehlerquellen von Softwaresystemen frühzeitig<br />
eliminiert wird. 49<br />
Erfahrung kann im Endeffekt durch nichts ersetzt werden. Man kann sich noch so viel Wissen durch Lesen und<br />
Zuhören aneignen – um wirklich zu lernen, muß man selbst aktiv werden und die Prinzipien anwenden. Die<br />
Ideen mögen naheliegend und leicht einzusehen sein, aber Ihre Anwendung kann ohne Training sehr mühsam<br />
sein. Ein Prinzip zu akzeptieren und es umzusetzen sind zwei verschiedene Dinge.<br />
Entwurfsprinzip 4.5.6 (Bewußtes Anwenden von Prinzipien)<br />
Ein leicht einzusehendes Prinzip darf niemals als “offensichtlich” verworfen werden, da nur ein bewußtes<br />
Anwenden von Prinzipien zum Erfolg führt.<br />
4.5.2 Programmierung als zielgerichtete Tätigkeit<br />
In unseren Beispielen haben wir die Bedeutung des zielgerichteten Vorgehens in <strong>der</strong> Programmierung hervorgehoben.<br />
Die Zielsetzung, die ein Programm erfüllen soll, also die Nachbedingung, ist erheblich wichtiger als<br />
die Situation, von <strong>der</strong> man ausgeht (die Vorbedingung). Natürlich spielt die Vorbedingung eine Rolle, aber<br />
die Nachbedingung liefert erheblich mehr Erkenntnisse. Die Entwicklung eines Fakultätsprogramms ohne das<br />
Ziel, die Fakultät zu berechnen, wäre geradezu aberwitzig. Auch die angestrebte Verwendung vorgefertigter<br />
Softwaremodule, die in Eiffel beson<strong>der</strong>s unterstützt wird, hat nur dann einen Sinn, wenn man sich die<br />
Bestandteile danach zusammensucht, was man eigentlich lösen will.<br />
Entwurfsprinzip 4.5.7 (Zielorientierung)<br />
Jede Programmentwicklung muß sich an dem angestrebten Resultat orientieren.<br />
48 Was “offensichtlich” ist, beruht natürlich ebenfalls auf Erfahrung und dem Umfeld, in dem ein Beweis präsentiert wird.<br />
Empfehlenswert ist daher, zunächst extrem detailliert zu arbeiten, und erst später dazu überzugehen, Details wie<strong>der</strong> zu entfernen.<br />
Nach einer Weile wird sich dann herausstellen, mit welchen Argumenten man fehlerfrei umgehen kann ohne alles zu überprüfen.<br />
49 Wie wichtig dies ist, zeigt folgendes Rechenexempel. 500 einfache Routinen in einem Softwaresystem sind keine Seltenheit.<br />
Wenn jede dieser Routinen sich nur in einem von 1000 Fällen falsch verhält, dann tritt im Gesamtsystem schon in jedem zweiten<br />
Fall ein Fehler auf. Bei unverifizierten Routinen liegt die Fehlerwahrscheinlichkeit meist sogar höher, nämlich zwischen einem<br />
und 5 Prozent. In diesem Fall mach das Gesamtsystem praktisch immer einen Fehler (d.h. in 99,4% bzw. 99,999% <strong>der</strong> Fälle).