In diesem Kapitel sollen Sie den in den vorigen Abschnitten entwickelten Term-Interpreter bei der Erstellung eines kompletten und nützlichen Programms einsetzen: Sie werden "Ihren ultimativen Funktionenplotter" bauen. Im Verlaufe dieses Projekts werden Sie die typischen Arbeitsphasen bei der Produktion von Software kennenlernen.
Funktionen-Plotter gehören zwar nicht gerade zu den originellen, aber durchaus zu den nützlichen Programmierbeispielen im Informatikunterricht. Wohl nahezu jeder, der etwas von Programmieren versteht, hat irgendwann in seiner Laufbahn mal einen Funktionenplotter geschrieben. Und so gibt es eine unüberschaubare Vielfalt von solchen Programmen auf dem Markt.
Eine genauere Betrachtung bringt jedoch recht schnell an den Tag, dass nicht alles Gold ist, was glänzt. Viele der Programme haben den einen oder anderen Nachteil, wobei diese Einschätzung natürlich auch vom persönlichen Geschmack des Beurteilenden abhängt. Damit Sie nun "Ihren ultimativen Funktionenplotter" herstellen können, ist es zunächst wichtig, dass Sie möglichst genau klären, welche Anforderungen an dieses Programm gestellt werden sollen, was es können und wie es aussehen soll. Ein sinnvoller Arbeitsplan für diese Entwurfsphase soll Ihnen ersparen, dass Sie nach der Hälfte der Arbeit feststellen: man hätte das alles eigentlich ganz anders anfangen müssen!
Beim Bau "Ihres ultimativen Funktionenplotters" werden Sie daher in einem recht bescheidenen Rahmen einige grundlegende Arbeitsmethoden professioneller Software-Herstellung kennenlernen. Angesichts der Einfachheit unseres Projektes beschränken wir uns in der Entwurfsphase auf drei Schritte:
Zunächst sollen Sie klären, welche Grundprinzipien für den Entwurf "Ihres" Programms gelten sollen. Es ist wichtig, dass Sie diese Prinzipien schriftlich festhalten, damit Sie sich im Folgenden auch stets daran halten können.
Erst danach wird eine Liste der Fähigkeiten erstellt, die Ihr Programm haben soll.
Schließlich entwerfen Sie eine Benutzer-Oberfläche für Ihr Programm.
In den folgenden drei Aufgaben sollen Sie nun diese drei Schritte konkret durchführen. Geben Sie sich dabei wirklich Mühe: wenn nämlich eine der Entwurfsphasen für abgeschlossen erklärt wird, dann sind die in ihr erzielten Ergebnisse für die folgenden Phasen verbindlich und dürfen nachträglich nicht mehr verändert werden!
Aufgaben:
Grundsätzliche Vorentscheidungen
Es gibt einen fast unauflösbaren Konflikt zwischen den Forderungen nach einem einfach und intuitiv benutzbaren Programm einerseits und möglichst umfassender Funktionalität andererseits. Legen Sie fest, was Ihnen wie wichtig ist!
Gibt es weitere "Design-Prinzipien", die Ihnen beachtenswert erscheinen? Schreiben Sie sie ebenfalls auf!
Das Pflichtenheft
Erstellen Sie dann ein "Pflichtenheft": das ist eine Liste der Eigenschaften und Fähigkeiten, die Ihr Programm haben soll. Seien Sie dabei lieber etwas vorsichtig: das Programm soll mit dem Wissen erstellbar sein, das Sie bisher angesammelt haben! Dokumentieren Sie auch die Dinge, auf die Sie bewusst verzichten wollen.
Der Prototyp
Wenn der Funktionsumfang vollständig beschrieben ist, können Sie die Benutzeroberfläche Ihres Programms entwerfen. Sie können dies zunächst mit Bleistift und Papier machen; alternativ können Sie die Oberfläche auch gleich in Delphi "designen". Der so erstellte "Prototyp" ist zwar zunächst eine funktionslose Hülle; trotzdem kann er schon einen Eindruck vom fertigen Produkt vermitteln.
Beachten Sie, dass Sie bis zu diesem Zeitpunkt noch keine Zeile programmiert haben. Das sollte Sie aber nicht dazu verführen, die bis hier geleistete Arbeit gering zu schätzen! Sie ist mindestens genau so wichtig wie die folgende Implementierung, die der leeren Hülle des Prototypen nun Leben einhauchen soll.
Aufgaben:
Programmieren macht Spaß...
Falls Sie den Prototyp noch nicht in Delphi realisiert haben, muss dies nun zuerst geschehen. Stellen Sie dann eine Kopie dieses Prototyp-Projekts (in einem neuen Verzeichnis!) her. Erweitern Sie nun dieses Projekt, indem Sie die im Pflichtenheft festgelegte Funktionalität implementieren! Beachten Sie dabei bitte die folgenden zwei Punkte:
Für die Eingabe des Funktionsterms wird sicher eine Edit-Komponente benutzt. Um die Funktionswerte zu einer gegebenen Stelle x zu berechnen, sollen Sie die Funktion Termwert() aus der Unit TermInterpreter benutzen. Stellen Sie dazu eine Kopie der Datei "TermInterpreter.pas" ins Quell-Verzeichnis Ihrer Anwendung. Damit sie diese Unit auch wirklich benutzen können, müssen Sie sie in der USES-Anweisung Ihrer Formular-Unit aufführen.
Um sich die Möglichkeiten für spätere Änderungen oder Erweiterungen zu erhalten, sollten Sie bei der Implementierung der Grafik-Ausgabe so vorgehen, wie dies im Kapitel Grafik mit TCanvas beschrieben ist. Möglicherweise können Sie auch von den dort erstellten Quelltexten profitieren!
Halten Sie sich bei dieser Arbeit bitte genau an die im Pflichtenheft festgelegten Anforderungen: Sie sollen weder mehr noch weniger machen, als dort verlangt wird! Wenn Sie beim Programmieren eine attraktive Idee für eine gute Erweiterung haben, dann widerstehen Sie der Versuchung, diese gleich umzusetzen; schreiben Sie die Idee auf, und freuen Sie sich darauf, dies nach dem erfolgreichen Abschluss des aktuellen Projekts anzugehen.
Nach dem erfolgreichen Abschluss der Implementierung wird üblicherweise getestet, ob das Programm auch wirklich die Vorgaben der vereinbarten Entwurfsprinzipien sowie des Pflichtenheftes erfüllt. Es ist wenig sinnvoll, wenn dies durch das Entwicklerteam selber geschieht: die Versuchung, das eigene Werk "schön zu reden", ist zu groß. Deshalb sollte ein solcher Test von jemandem durchgeführt werden, der nicht direkt an der Implementierung beteiligt war, das Projekt aber doch hinreichend genau kennt.
Aufgaben:
Der Härte-Test
Übergeben Sie nun Ihr gesamtes Projekt (also das Programm mitsamt der Dokumentation der Design-Vorgaben und des Pflichtenheftes!) an eine andere Arbeitsgruppe, welche Ihnen im Gegenzug ihr Projekt zur Begutachtung überlassen soll.
Testen Sie dann, ob das jeweilige Programm die dokumentierten Vorgaben erfüllt! Beurteilen Sie, ob und wie gut diese Aufgabe erledigt wurde. Beachten Sie dabei aber, dass für diese Beurteilung nicht Ihre eigenen Vorstellungen vom "Ultimativen Funktionenplotter" maßgebend sind, sondern die in der Dokumentation des Projektes festgelegten Vorgaben!
Schreiben Sie einen Testbericht, dem das Entwicklerteam entnehmen kann, in welchen Punkten Sie mit der Umsetzung zufrieden sind und in welchen nicht. Begründen Sie im letzteren Fall Ihre Kritik möglichst so, dass die Entwickler sehen können, wie sie dem festgestellten Mangel abhelfen können. Geben Sie Ihren Testbericht an das Entwicklerteam zurück.
Nacharbeiten...
Wenn Sie den Testbericht über Ihr eigenes Projekt zurück bekommen, lesen Sie ihn aufmerksam durch. Falls er berechtigte Kritikpunkte enthält, sollten Sie Ihr Programm nochmals überarbeiten. Danach sollten Sie Ihr Projekt ein zweites Mal einem anderen Team zur Begutachtung vorlegen.
In der Praxis ist die Herstellung von Software natürlich in der Regel komplexer als wir das hier bei unserem kleinen Projekt erfahren können. Üblicherweise sind auch erheblich mehr Mitarbeiter an einem solchen Projekt beteiligt, und die einzelnen Phasen liegen oft in den Händen verschiedener Teil-Teams. Trotzdem läuft professionelle Software-Produktion im Wesentlich schon etwa so ab, wie wir es hier durchgeführt haben. Die folgende Grafik gibt nochmals einen Überblick über die einzelnen Arbeitsschritte:
Ausgangs- und Endpunkt des "Zyklus" ist der Kundenauftrag. Aus ihm erstellt das Projektteam - in der Regel zusammen mit dem Auftraggeber - ein Pflichtenheft. Dieses wird an das Programmiererteam übergeben, welches zunächst einen Prototyp erstellt. Auch dieser kann dem Auftraggeber zur Begutachtung vorgelegt werden. Ist der Auftraggeber noch nicht zufrieden, dann muss möglicherweise das Pflichtenheft überarbeitet werden.
Findet das Pflichtenheft endgültig die Zustimmung des Auftraggebers, dann kann das Programmiererteam die eigentliche Implementierung beginnen. Dabei werden nun die Algorithmen entwickelt und programmiert, mit deren Hilfe die einzelnen Forderungen des Pflichtenheftes umgesetzt werden können. Auch dies ist natürlich ein Kreisprozess: die Entwickler werden schon während ihrer Arbeit ständig testen, ob der von ihnen produzierte Code auch wirklich das tut, was er soll!
Wenn das Entwicklerteam seine Arbeit beendet hat, erfolgt zunächst die firmen-interne Qualitätskontrolle. Dabei wird nochmals geprüft, ob das Programm alle Spezifikationen des Pflichtenhefts erfüllt. Falls nicht, bekommt das Programmierteam den Auftrag, die Mängel zu beheben. Andernfalls erfolgt die Endabnahme durch den Auftraggeber. Ist der Auftraggeber zufrieden, dann ist das Projekt abgeschlossen und das Programm wird ausgeliefert. Ist er nicht zufrieden, dann muss er nachweisen, dass das gelieferte Programm nicht der im Pflichtenheft vereinbarten Spezifikation entspricht. Wenn jedoch die Qualitätskontrolle ordentlich gearbeitet hat, dürfte ihm das schwerfallen. In diesem Fall muss der Kunde einsehen, dass er bei der Erstellung des Pflichtenheftes seine Vorstellungen nicht genau genug formuliert hat. Es bleibt ihm dann nur die Möglichkeit, einen neuen Auftrag zu formulieren - und weiteres Geld in das Projekt zu pumpen!
Man sieht daraus, welch wichtige Funktion eine ordentliche Dokumentation hat: ob der Auftraggeber mit dem gelieferten Produkt zufrieden sein muss oder nicht, darüber wird anhand des Pflichtenheftes entschieden! Auch für die Programmierer ist eine gute Dokumentation lebenswichtig: wenn ein Projekt überarbeitet werden muss, ist es vorteilhaft, wenn der Quellcode des Programms klar und verständlich formuliert ist. Andernfalls wird viel Zeit damit verloren gehen, darüber nachzudenken, was diese oder jene Prozedur eigentlich genau tut, und warum man das so und nicht anders gemacht hat... Die Quelltexte wirklich professioneller Programmierer enthalten in der Regel mehr Zeilen mit Kommentaren als solche mit Programmcode!
