Angeregt durch einen Artikel in der COMPUTERWOCHE Nr. 4/32. Seite 10, von Jochen Rosowski über die Möglichkeiten, mit Cobol strukturiert zu programmieren, schickte uns Jan-Dirk van Vlijmen aus Excom in Südafrika einen Bericht seiner Erfahrungen auf diesem Gebiet. Rosowski griff bei der Entwicklung der in seinem Unternehmen angewandten Regeln auf die Grundelemente der strukturierten Programmierung zurück. So forderte er zum Beispiel die hierarchische Untergliederung der Module. Neben anderen Tips und Tricks über die Gestaltung der Steuerungsanweisungen propagierte Rosowski für Schleifen den Einsatz des "Perform"-Befehls. der seiner Erfahrung nach eine deutlichere Darstellung als die Verwendung des "Go To" beinhaltet. Anders jetzt Jan-Dirk van Vlijmen: Er betrachtet das "Go To" als integralen Bestandteil unseres Denkens und fordert in diesem Sinne unter anderem, der Programmierung keine künstlichen Korsetts aufzuzwingen.

Es bietet sich an, eine strukturierte Denkweise in Projekten einzuführen, da Systeme normalerweise immer - in Strukturen einteilbar sind. Dies bedeutet, daß nicht nur die Programme strukturiert werden und daß die Struktur der Programme nicht durch die Möglichkeit der Programmiersprachen bestimmt wird. Bereits in den Designphasen eines Projekts sollte die strukturierte Vorgehensweise angewendet werden, so daß die Programme das DV-technische Spiegelbild der vom Benutzer gewünschten und vom DV-Spezialisten dokumentierten Anwendung darstellen.

Wenn die Anwender die strukturierte Vorgehensweise verstehen, wird ein gemeinsames Sprachelement benutzt, das die Kommunikation zwischen Anwender und Datenverarbeitung erleichtert. Diese Vorgehensweise führt auch zu einer Verkürzung der Projekte, weil vertikale und horizontale Strukturelemente bei der Lösung eines Problems unberücksichtigt bleiben können. Dabei dürfen der Gesamtzusammenhang und die integrativen Beziehungen nicht aus den Augen gelassen werden. Hierzu werden die Schnittstellen zwischen den Strukturelementen ständig mitbetrachtet und dokumentiert.

Bei der Anwendung der strukturierten Programmierung sollte man nicht zu dogmatisch vorgehen und auf der Erfüllung des Idealzustandes beharren. Ein "Go To" ist nun einmal Bestandteil unseres Denkens. Programme sollten zum Beispiel nicht in tausend Performs unterteilt werden, um diesen Befehl zu vermeiden. Damit würde man das Ziel, übersichtliche Software zu schaffen, sicherlich nicht erreichen.

Die Standardisierung sollte nicht zu einer unnatürlichen Logik in den Programmen führen. Man kann der Programmierung auf Dauer gesehen kein künstliches, der normalen Denkweise entferntes Korsett aufzwingen. Wichtig ist auch, daß beim Verlassen des Idealweges noch Regeln vorhanden sind, die die Struktur der Programme erhalten.

Nachfolgend einige Beispiele, für die Regeln vorhanden sein sollten:

1) Layout

2) Modul-Restriktionen

3) Structure-Modul

4) Inter-Modul-Kommunikation

5) Namenskonventionen

6) Teststrategie

Es wäre an dieser Stelle zu umfangreich, eine vollständige Sammlung aller Maßnahmen zu diskutieren. Ein wichtiger Bereich, der hier ausgelassen wird, sind Aktivitätenlisten in Dokumentationssystemen; die die strukturierte Vorgehensweise stark unterstützen können.

Für jede Programmiersprache sollte ein standardisiertes Layout verwendet werden. Für COBOL hat sich folgende Einteilung des Codierblattes bewährt:

1 - 7 wie bisher

8 - 11 Section- und Paragraphennamen

8 - 20 Level-No.

12 Trace- und Testbefehle

21 Datennamen und Befehle

30 Name 1 für Operation

38 PIC-Clause und Sprungadressen

47 zweiter Teil Operation

56 zusätzliche Angaben für Datennamen Name 2 für Operator

73 - 80 Kurzmodulname, Version-No. Wartungsangaben

Aus dem Bild wird ersichtlich, wie sich allein durch dieses Layout Übersichtlichkeit erreichen läßt.

Zehn wichtige Regeln

- Jedes Modul sollte nur hantierbar groß sein, ansonsten ist eine weitere Strukturierung erforderlich.

- Module sollten als Black-Boxes betrachtet werden und unabhängig testbar sein (Schachtelprinzip).

- Vermeide Abhängigkeiten zwischen Modulen, so daß sich Änderungen nicht auf alle Programmstufen auswirken.

- Vermeide eine zu tiefe Schachtelung/Struktur.

- Trenne Struktur-Befehle von der Verarbeitung, dadurch werden Routinen transportabler. Dies gilt auch für die Ein-/Ausgabe von der Verarbeitung.

- Verwende standardisierte Routinen, das heißt, einheitlich aufgebaute Routinen.

- Selektiere allgemeingültige, vielfach verwendbare Routinen.

- Sichere die Informationen, wenn Datenfelder in verschiedenen Strukturstufen verwendet werden (Prinzip der Save-Area).

- Schaffe eine Inter-Modul-Kommunikation mit Hilfe von Returncodes.

- Ein Eingang, ein Ausgang.

Durch diese Forderungen bekommt ein Programm eine ähnliche Struktur wie in Bild 2.

Gleichartige Routinen

Jede Routine in einem Modul oder Programm, in einer Anwendung oder in einem System sollte gleichartig aufgebaut sein. Eine solche Vorgehensweise erhöht die Übersichtlichkeit und erleichtert die Wartung von Programmen.

Insbesondere hat sich diese Standardisierung bei Personalwechsel während eines Projektes als großer Vorteil erwiesen, da die Projektmitglieder gemeinsame und einheitliche Sprachelemente benutzen.

Es empfiehlt sich eine Routine immer in eine Eingangs-/Entry-Verarbeitung (ENTR-0000)

Haupt-/Main-Verarbeitung (MAIN-0100)

Ausgangs-/Exit-Verarbeitung (EXIT-0090)

zu unterteilen, wobei die Eingangs- und Ende-Verarbeitung von einer Bedingung abhängig sein können.

ENTR-0000. semeinsame

ENC0-0000. ENTRY-Einsanss-Verarbeituns

ENTH-0000. ENTRY-Condition

ENEL-0000. ENTRY-THEN-Verarbeituns

ENEN-0000. ENTRY-ELSE--Verarbeituns

MAIN-0010. semeinsame

ENTRY-Ende-Verarbeituns

EXIT-0090. semeinsame

EXIT-Einsanss-Verarbeituns

EXC0-0090. EXIT-Condition

EXTH-0090. EXIT-THEN-Verarbeituns

EXEL-0090. EXIT-ELSE-Werarbeituns

EXEN -0090. semeinsame

EXIT-Ende-Verarbeituns

Die Hauptverarbeitung wird sich insbesondere auf den höheren Stufen horizontal und vertikal weiter ausbreiten. Dieses könnte der CASE-Fall sein und/ oder eine sequentelle Folge von Routinen.

ENTR-OO00

CASE-0000 CASE-Steueruns

MAIN-0010 semeinsame

MAIN-Einsanss-Verarbeituns

SUBR-0010 Subrout ine Branch

SUBR-0011.

SUBR-0012.

MAIN-0020.

MAIN-0030.

EXIT-0090.

Der Rücksprung von einer Subroutine kann wiederum einer Bedingung unterliegen.

SUBR-0010.

SUC0-0010. SUBR-Condition

SUTH-0010. SUBR-THEN-Verarbeituns

SUEL-0010. SUBR-ELSE-Vererbeituns

SUEN-0010. SUBR-Ende-Verarbeituns

Der Ansprung zur Subroutine wird häufig auch durch Bedingungen gesteuert. Dies sollte normalerweise mit der WHILE-Schleife oder mit REPEAT-UNTIL zu lösen sein.

MAIN-0010.

WHIL-0010. oder REPT-0010.

SUBR -0010.

WHEN-0010 oder REEN-0010.

SUC0-0010.

SUTH-0010.

SUEL-0010.

MAEN-0010.

Zwischen den einzelnen Routinen findet eine Kommunikation über Return-Codes statt.

Folgende Standard-Definitionen zeigen einige Beispiele über die Verwendung von RCs:

RC

RC-OK

RC-ERROR

RC-END

RC-RNF (Record not found)

RC-EOR (End of Record, Set, File)

RC-DUP (Duplicate Record)

RC-CHD (Command)

Bei der Definition und dem Gebrauch von Namenskonventionen darf ebenfalls das Ziel einer Strukturierung nicht aus den Augen verloren werden.

Für Übergriffe haben sich aussagekräftige Namen bewährt, während zur Vermeidung von Schreibaufwand in der Codierung Kürzel Verwendung finden sollten. (Bild 3).

Während des Designs einer Routine werden parallel dazu die erforderlichen Testmaßnahmen festgelegt und dokumentiert, wie zum Beispiel Minimum/Maximumwerte, Grenzwerte, Druchschnittswerte oder Volumentest. Die Realisatoren sind für die Erstellung der Testergebnisse verantwortlich. Die erstellten Unterlagen dienen der Abteilung "Qualitätssicherung" zur Abnahme und Übernahme der Programme für die Produktion.

Es ist auch Aufgabe der Qualitätssicherung, die Einhaltung der festgelegten Regeln zu überprüfen und gegebenenfalls die Programme zur Nachbesserung an die Programmierung zurückzuverweisen.

Das Erstellen und Testen der Programme beginnt mit der ersten Stufe der Programmstruktur. Die nächst tiefergelegene Stufe kommuniziert mit der höheren Stufe erst einmal mit Hilfe der Return-Codes.

Nachdem die höhergelegenen Stufen ausgetestet sind, wird die nächste Stufe programmiert. Zum Schluß werden die eigentlichen Verarbeitungsroutinen und Ein-/Ausgaberoutinen erstellt, nachdem die Logik des Programmes läuft. Wichtig ist hierbei, daß ein Testplan vorliegt.

Bei der Festlegung des Testplanes muß überprüft werden, inwieweit die zu verarbeitenden Daten den Ablauf der Programme beeinflussen und ob eine Neutralisierung dieses Effektes durch eine geänderte Strukturierung erreicht werden kann.

Mit Hilfe eines Testplanes kann auch überprüft werden ob alle Informationen für die jeweilige Stufe vorliegen. Zur Teststrategie gehört es auch, daß allgemeingültige Standard-(Fehler-)Routinen zur Verfügung stehen. Diese Routinen bearbeiten automatisch zum Beispiel DB-, DC-, Programmfehler und erstellen Ergebnisprotokolle.

Zur Vereinfachung von Tests sind auch Forderungen an die Compiler zu stellen. Compiler sollten mehr Hinweise ausgeben, wenn Elemente der Programmiersprache benutzt werden, die gewissen Regeln zuwiderlaufen.

Zum Beispiel Rückwärtsverzweigungen, Sprungadressen außerhalb einer Section,

Alter-Befehle, Move unterschiedlicher Formate.

Die sogenannte Softwarekrise ist nicht mit einem Allheilmittel, wie der strukturierten Programmierung zu lösen. Es sind vielfältige Methoden und Hilfsmittel erforderlich, um "Gute Programme" zu erstellen. In jedem Fall wird die Entscheidung zu treffen sein, welches Instrument jeweils sinnvoll ist. Neben der strukturierten Programmierung werden Erfahrungen und Methoden wie

- Projektdesign

- DB-Design

- DC-Programmierung

- Entscheidungstabellen

- Qualitätssicherung oder

- Dokumentationsformen die industrielle Erzeugung von Programmen beeinflußen. Die Frage, die in Zukunft zu diskutieren ist, wird sich mit der Integration verschiedener Methoden befassen. Inwieweit nämlich kann die eine Methode die andere unterstützen, um zu einem Gesamtsystem zu kommen.