Einführung in C/C++ - Alex-weingarten.de

16 KAPITEL 1. PROGRAMMIEREN IN C/C++1.1.9.3 Zusammensetzen aus TeilaufgabenDer umgekehrte Weg – Bottom-up-Entwurf – liegt nicht so nahe. Es gibt wiederkehrendeGrund-Operationen wie Suchen, Sortieren, Fragen, Ausgeben, Interpolieren, Zeichnen einesKreisbogens. Aus diesen lässt sich eine gegebene Aufgabe zu einem großen Teil zusammensetzen,so dass nur wenige spezielle Teilaufgaben übrig bleiben. Hat man die Grundoperationeneinmal programmiert, so vereinfacht sich der Rest erheblich.In praxi wendet man eine gemischte Strategie an. Man zerlegt die übergeordnete Aufgabein Teilaufgaben, versucht diese in Grundoperationen auszudrücken und kommt dannwieder aufsteigend zu einer genaueren und allgemeiner gültigen Formulierung. Dieser AbundAufstieg kann sich mehrmals wiederholen. Die Aufgabenstellung ist nicht unveränderlich.Genau so geht man bei der Planung von Industrieanlagen vor.Man darf nicht den Fehler machen, die Aufgabe aus Bequemlichkeit den Eigenheiteneines Computers oder einer Programmiersprache anzupassen. Der Benutzer hat Anspruchauf ein gut und verständlich funktionierendes Programm. Die Zeiten, als der Computer alsEntschuldigung für alle möglichen Unzulänglichkeiten herhalten musste, sind vorbei.1.1.10 PrototypingIn dem häufig vorkommenden Fall, dass die Anforderungen an das Programm zu Beginnnoch verschwommen sind, ist es zweckmäßig, möglichst rasch ein lauffähiges Grundgerüst,ein Skelett zu haben. Mit diesem kann man dann spielen und Erfahrungen sammeln in einemStadium, in dem der Programmcode noch überschaubar und leicht zu ändern ist.Bei einem solchen Prototyp sind nur die benutzernahen Funktionen halbwegs ausgebaut,die datennahen Funktionen schreiben vorläufig nur ihren Namen auf den Bildschirm.Von einem menugesteuerten Vokabeltrainer beispielsweise schreibt man zunächst das Menusystemund lässt die Funktionen, die die eigentliche Arbeit erledigen, leer oder beschränktsie auf die Ausgabe ihres Namens. Damit liegt die Programmstruktur – das Knochengerüst– fest. Gleichzeitig macht man sich Gedanken über die Datenstruktur. Steht der Prototyp,nimmt man den Datenaustausch zwischen den Funktionen hinzu (Parameterübergabe und-rückgabe), immer noch mit Bildschirmmeldungen anstelle der eigentlichen Arbeit. Funktioniertauch das wie gewünscht, füllt man eine Funktion nach der anderen mit Code.Diese Vorgehensweise lenkt die Entwicklung zu einem möglichst frühen Zeitpunkt in diegewünschte Richtung. Bei einem kommerziellen Auftrag bezieht sie den Auftraggeber in dieEntwicklung ein und fördert das gegenseitige Verständnis, aber auch bei privaten Projektenverhindert sie, dass man viel Code für /dev/null schreibt.Das Prototyping ist sicher nicht für alle Programmieraufgaben das beste Modell – es gibtauch noch andere Modelle – aber für dialogintensive kleine und mittlerer Anwendungen rechtbrauchbar und in C leicht zu verwirklichen.1.1.11 FlussdiagrammeProgramme werden schnell unübersichtlich. Man hat daher schon früh versucht, mit Hilfegrafischer Darstellungen 13 den Überblick zu behalten, aber auch diese neigen zum Wuchern.Ein grundsätzlicher Mangel ist die Beschränkung eines Blattes Papier auf zwei Dimensionen.Es ist unmöglich, ein umfangreiches Programm durch eine einzige halbwegs überschaubareGrafik zu beschreiben.Flussdiagramme (flow chart), auch Blockdiagramme genannt, sollen die Abläufe innerhalbeines Programmes durch Sinnbilder nach DIN 66 001 und Text darstellen, unabhängigvon einer Programmiersprache. Obwohl das Flussdiagramm vor dem Programmcode erstelltwerden sollte, halten sich viele Programmierer nicht an diese Reihenfolge. Zum Teil ersetzteine gute typografische Gestaltung der Programmquelle auch ein Flussdiagramm, währenddas Umgekehrte nicht gilt. Ein Flussdiagramm ist nicht mit einem Syntaxdiagramm zu verwechseln,lesen Sie die beiden entsprechenden Abbildungen, die die if-else-Verzweigung darstellen,einmal laut vor.13 Real programmers don’t draw flowcharts.