Strukturierte Programmierung als einheitliche Programmiermethodik und Hilfsmittel zur Rationalisierung im EDV-Bereich

26.10.1979

Die COMPUTERWOCHE setzt in dieser Ausgabe die Serie zum Thema "Strukturierte Programmierung" fort. Dieser Beitrag stammt von Heinz Neubeck, Leiter EDV-Organisation bei der IWKA Industrie-Werke Karlsruhe Augsburg Aktiengesellschaft, Karlsruhe.

3. Konzeptbildung und Planung

3.1 Notwendigkeit einer sorgfältigen Planung

In der bisherigen Programmierung wird oft argumentiert, man habe keine Zeit, sich ein gutes Konzept für ein Programm zu überlegen, es ginge viel schneller, zunächst ein paar Befehle hinzuschreiben, man würde dann schon sehen!

Es ist möglich, aber nicht beweisen daß sich sehr kleine überschaubare Programme auf diese "experimentelle Weise schneller schreiben lassen. Für größere Programme gilt das jedoch auf keinen Fall. Verlangt man von einem Programm, daß es rationell eingesetzt werden kann und seine Aufgabe nachweislich erfüllt, so muß zuerst

die Aufgabenstellung für das Programm im Detail fixiert, dann ein geeignetes Lösungsverfahren (Algorithmus) festgelegt werden.

Erst dann kann mit dem Programmieren begonnen werden. Die Reihenfolge ist hier wesentlich.

Man muß zuerst festlegen, was erreicht werden soll, bevor man plant, w i e vorangegangen werden soll.

Der Gesamtaufwand bei der Programmentwicklung erhöht sich auf diese Weise nicht, denn man spart beim Testen mehr. als man in der Planung zusätzlich gearbeitet hat.

3.2 Benutzervorstellung als Grundlage für die Programmplanung

Unter der Benutzervorstellung versteht man die Anforderungen, die der Anwender an ein Programm stellt, das heißt Antworten auf die Fragen:

- Was genau leistet das Programm?

- Welche Eingaben benötigt es?

- Welche Ausgabe liefert es?

- Wie muß es bedient werden?

- Wie verhält man sieh in Fehler- und Störungsfällen?

Es geht hier um die Funktion des Programmes.

Die funktionelle Beschreibung eines Programmes umreißt seine Leistung, seine

Ein-, Ausgabe, seine Bedienung.

Die funktionelle Beschreibung muß exakt vorliegen, bevor mit der Programmierung begonnen werden kann. Sie muß klar und einfach sein, aber auch erschöpfend. Die funktionelle Beschreibung muß den Anforderungen der Aufgabenstellung exakt entsprechen. Sie bietet die Grundlage für die Planung .

Die eindeutige Dateninterpretierbarkeit liefert ein Maß für die Effektivität eines Programmes:

Unklarheiten erhöhen die Wahrscheinlichkeit von Benutzerfehlern .

Bei interaktiven Programmen, die einen Dialog beinhalten, kommt noch dazu. daß unnötiges Nachdenken - Müssen eines Benutzers in Form von Anschaltzeit bezahlt werden muß.

Es ist deshalb wesentlich, bei der Erarbeitung der Benutzervorstellung das sogenannte "principle of least astonishment zu beachten: Das Programm muß nach Möglichkeit immer das tun, was vom Benutzer erwartet wird, was ihm naheliegend und verständlich scheint.

Teil II

3.3 Methodik der Programmplanung

3.3.1 Gliederung in Moduln

Die Aufgabenstellung für ein Programmsystem ist im allgemeinen so komplex, daß das gewünschte Programm nicht unmittelbar in Anweisungen ausgedrückt werden kann.

Programme werden deshalb in Programmier - Struktur - Blocke gegliedert, die unabhängig voneinander hergestellt werden, und deren Zusammenwirken die Leistung des Programmes erbringt.

- In der Strukturierten Programmierung werden Programme so gegliedert, daß sowohl jede Komponente als auch die Verknüpfung von Komponenten eine Problemfunktion erfüllen.

- Jede Programmkomponente lost eine Teilaufgabe. Das Ergebnis einer Programmkomponente wird in der ihr übergeordneten Komponente verwendet.

Die übergeordnete Komponente kennt nur die funktionelle Beschreibung, nicht aber die technische Realisierung ihrer Unterkomponenten.

- Komponenten werden so wie einzelne Anweisungen aus Strukturblöcken zusammengesetzt, nach wenigen standardisierten Prinzipien.

Die wesentlichen Vorteile einer solchen Programmgliederung:

- Aufgabenstellung wird verständlicher durch Zerlegen einer Aufgabe in Teilaufgaben.

- Da jede Komponente nur durch ihre Funktion nach außen bekannt ist, können einzelne Komponente gefahrlos voneinander entwickelt werden.

-Eine Komponente eines Programms kann durch eine andere Komponente mit gleicher Leistung ausgewechselt werden, ohne den Rest des Programmes zu stören.

3.3.3 Funktionelle Beschreibung als Grundlage für die technische Realisierung

Jede Programmkomponente ist durch ihre Funktion/ Schnittstelle nach außen gekennzeichnet:

- Eingabe

- Ausgabe

- Funktion

- Fehlerbehandlung

Im allgemeinen ist mehr als eine technische Realisierung für eine gegebene funktionelle Beschreibung möglich. Zulässige technische Realisierungen sind nur solche, die genau die geforderte Leistung erbringen ohne Einschränkungen und ohne unerwünschte Nebeneffekte.

3.3.3 Unabhängigkeit von Komponenten

Wesentlich sowohl für die Änderbarkeit eines Programmes als auch für die Vermeidung von Fehlerquellen ist die Forderung, daß die technische Realisierung von je zwei Komponenten voneinander unabhängig sein muß. Jede Komponente ist dann als Ganzes gegen eine andere auswechselbar, wenn beide die gleiche Funktion haben.

3.3.4 Hierarchische Programmstrukturierung

Je komplexer die Aufgabenstellung einer Komponente ist. desto mehr muß sie sich in ihrer Realisierung auf Unterkomponenten abstützen, wenn sie verständlich bleiben soll. Man erhält ein hierarchisch strukturiertes System.

In diesem System werden Komponenten auf mehreren Ebenen realisiert. Diese Aufteilung beinhaltet zunehmende Abstraktionen (Problemnähe in Richtung nach oben beziehungsweise zunehmende Konkretisierung (Detailtiefe) in Richtung nach unten.

Auf jeder Ebene kann die Funktion des Programms vollständig beschrieben

werden, die unterste Ebene liefert die Details der technischen Realisierung.

In einer übergeordneten Komponente ist eine Komponente der darunterliegenden Ebene durch ihren Aufruf vertreten (in Cobol durch eine PERFORM - Anweisung) .