Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Ansatz zur Rationalisierung der Software-Entwicklung:

Warum modulare Programme selten sind

17.10.1980

MÜNCHEN/BUDAPEST- Eines der Haupthindernisse bei der Durchsetzung einer systematischen Programmierweise ist die Größe der gewöhnlichen Anwenderprogramme. Programme mit 3000 und mehr Anweisungen sind keine Seltenheit in der DV-Praxis. Leider sind sie sogar die Regel.

Trotz aller Beteuerung der modularen und strukturierten Programmierung ist der Umfang im Stück gestrickter Programme enorm. Daß dies an sich ein Widerspruch ist, scheinen die Beteiligten nicht zu bemerken. Im Gegenteil, für große monolithische Programme gibt es immer Gründe.

Erstens sind die großen Programme nach Meinung der verantwortlichen Programmiermanager viel effizienter. Eine Call-Anweisung verursacht zu viel Laufzeit. Wieviel, kann man nur vermuten.

Das Effizienzargument ist jedoch vordergründig. Dahinter steckt das zweite Argument. Es ist ihnen zu aufwendig, so viele Einzelprogramme zu verwalten und immer wieder zu binden. Auch die Systemprogrammierung ist dagegen. Sie will nicht zusätzlich belastet werden.

Alibi für Strukturierung

Schließlich gibt es ein drittes und noch wichtigeres Argument. Bei getrennt compilierten Programmen muß man immer eine Parameterschnittstelle aufbauen. Und das ist den meisten Programmierern ein Greuel. Von der Einschränkung der Datenverfügbarkeit, sprich: "Information Hiding" wollen sie nichts wissen. Statt dessen ziehen sie eine eigene Interpretation der modularen Programmierung vor.

Ein modulares Programm ist ein Cobol-Programm mit vielen "Sections" oder ein PL/1-Programm mit vielen internen Prozeduren. Solange diese Code-Einheiten nur einen Eingang haben, glauben die Programmierer ihre Schuldigkeit gegenüber der strukturierten Programmierung getan zu haben. Daß sie eine Cobol-Section oder eine interne PL/1-Prozedur nicht ohne weiteres testen, ändern und austauschen können, stört sie nicht.

Aber hierin liegt gerade der Hauptgrund einer modularen Programmierung. Echte modulare Programme besitzen formale Parameterschnittstellen zwischen aufrufenden und aufgerufenen Moduln. Dadurch wird der interne Datenfluß erst sichtbar.

Außerdem können echte Moduln getrennt codiert, editiert, compiliert und getestet werden. Dadurch kommt man zu überschaubaren Produktionseinheiten, der ersten Voraussetzung für eine effektive Projektplanung und -überwachung. Dann kann ein systematischer Test nur mit kleineren Moduln durchgeführt werden. Ohne systematisches Testen ist aber die Zuverlässigkeit eines DV-Systems nicht zu gewährleisten.

Schließlich sind echte modulare Programme in der Wartungsphase wesentlich anpassungsfähiger. So lassen sie sich ohne Fernwirkung verändern, ergänzen oder sogar austauschen, was für "Sections" oder interne Prozeduren nicht zutrifft. Dort bringt eine Veränderung der Datenstruktur das ganze Programm ins Wanken. Es spricht also sehr viel für getrennt compilierbare Moduln, die über eine Call-Schnittstelle gekoppelt sind, trotz des dadurch verursachten Effizienzverlustes.

Eingefahrene Gleise

Es fragt sich aber, wie man zu einem echten modularen Programm kommen kann, denn es scheint in der Tat ein schwieriges Unterfangen zu sein. Programmierer sind Gefangene ihrer Gewohnheiten und diese Gewohnheiten sind so schwer zu ändern wie soziales Verhalten überhaupt. Es bedarf entweder eines Krieges, einer Revolution oder einer völlig anderen technischen Umgebung.

Ein Ansatz zur Veränderung des Programmierverhaltens ist über die Entwurfsmethode zu erreichen. Solche Methoden wie Constantine oder Jackson zielen auf eine bessere Modularisierung ab. Aber der Weg ist lang und steil. Diese Methoden sind

schwer erlernbar und stoßen auf den erbitterten Widerstand der praktizierenden Programmierer.

Der Mensch ist eben nur bedingt lernbereit - erst recht der berufserfahrene Mensch. Allen neuen Ansätzen steht er zunächst skeptisch gegenüber. Es muß ihm bewiesen werden, daß diese wirklich besser sind. Da dieser Beweis ohne seine Mitwirkung jedoch nicht erbracht werden kann, entsteht ein "Deadlock" (Stillstand, Anm. d. Red.). Kein Wunder, daß es mit der Einführung neuer Entwurfsmethoden hapert.

Ein anderer Ansatz zur Veränderung des Programmierverhaltens führt über Werkzeuge, die die technische Umgebung des Programmierens ändern. Beispiele sind der Programmers Workbench von Bell Laboratories und das PET-System von Softlab. Solche Systeme versuchen über das Sichtgerät die Kreativität des Software-Entwicklers zu kanalisieren und seine geistigen Fortschritte zu dokumentieren.

Mit seinem Softgen-Konzept will SES (Software Engineering Services) einen Weg beschreiten, bei dem ebenfalls dem Programmierer nichts anderes übrigbleibt, als modular, normiert und strukturiert zu arbeiten. Zum einen stützt sich das Konzept auf die Normierte Programmierung (NP) insofern, als es eine normierte Steuerung für Satzauswahl und Gruppenwechsel enthält, eine Steuerung, die der Programmierer übrigens gar nicht zu Gesicht bekommt.

Zum anderen geht es weit über die bestehende Norm hinaus. Die bisherige Normierte Programmierung ist auf die Stapelverarbeitung beschränkt und alles andere als modular. So sieht die konventionelle NP ein zwar einheitlich organisiertes, aber großes monolithisches Programm vor.

Um den Kriterien der modularen und strukturierten Programmierung gerecht zu werden, ist es zunächst erforderlich, einen modularisierten Programmrahmen zu haben. Innerhalb dieses Rahmens geht es weiter darum Steuerung, Terminalkommunikation Ein-/Ausgabe, Listengenerierung, Fehlerbehandlung, Einzel- und Gruppenverarbeitung zu normieren und voneinander zu trennen.

Demnach benötigt man folgende Moduln: Steuerungsmodul, E/A-Modul, Druckmodul, Fehlerbehandlungsmodul, Einzelverarbeitungsmoduln und Gruppenverarbeitungsmoduln. Da es aber zwei verschiedene Arten von Daten gibt, Bewegungsdaten und Stammdaten wird man auch zwei verschiedene EiA-Moduln brauchen, einen für sequentielle Dateien und einen für Direkt- beziehungsweise DB-Zugriffe.

Außerdem kommt für TP-Anwendungen ein Terminalkommunikationsmodul dazu. Schließlich kommt es darauf an, die Einzelverarbeitungs- und Gruppenverarbeitungsmoduln zu strukturieren. Mit Hilfe dieser standardisierten Moduln ist es möglich, einen Programmierrahmen mit einer zentralen Steuerung für Batch- und Online-Programme zu generieren.

Test- und Wartbarkeit

Jetzt fragt es sich natürlich, was außer der stärkeren Modularisierung neu an diesem Konzept ist und welche Vorteile es bringt, die eigentlichen Verarbeitungsfunktionen in getrennt compilierten Moduln zu verpacken. Die Antwort liegt nahe: Testbarkeit und Wartbarkeit werden erhöht sowie die Programmierung durch eine Trennung der Funktionsstruktur von der Datenstruktur erleichtert.

Die erhöhte Testbarkeit wird erreicht, indem der Entwickler die anwendungsbezogenen Funktionen in einzelnen voneinander unabhängigen Moduln - Cobol-Programme oder PL/1-Prozeduren - codiert und jeden für sich in einem simulierten Testrahmen austestet.

In jedem Modul sind die Eingaben und Ausgaben als Parameter deklariert, die von einem Testrahmen generierbar beziehungsweise validierbar sind. Da die Moduln sehr klein sind ist es relativ leicht, alle Ablaufzweige zu testen; die Entscheidungslogik und die Algorithmen können ohne Dateien und Datenbanken geprüft werden.

Die Wartbarkeit wird erhöht, indem jede Funktion sowie deren Datenstruktur verändert, erweitert oder eliminiert werden kann, ohne Auswirkung auf andere Funktionen. Man braucht nur die Parameter oder den Prozedurcode zu ändern. Hinzu kommt, daß jeder Verarbeitungsmodul auch jederzeit verwendbar ist.

Mundgerechtes Material

Schließlich wird die Programmierung dadurch erleichtert, daß der Programmierer sich weder um die Steuerung oder die Ein-/Ausgabe noch um sonstige Schnittstellen zur technischen Umgebung kümmern muß. Er braucht nur eine Eingabe-Struktur und eine Ausgabe-Struktur zu definieren und die Daten entsprechend umzusetzen.

Somit bekommt er nur jene Daten die die jeweilige Funktion benötigt. Das erfolgt in der Form, wie sie von der Funktion auch tatsächlich gebraucht werden, und nicht, wie sie gespeichert sind. Dies wird dadurch möglich, daß beim Test der einzelne Modul statisch analysiert und die Datenstruktur ermittelt wird.

Nach dem Test wird mit Hilfe der statischen Datenstrukturanalyse ein Transformationsmodul generiert, der einerseits die entsprechenden Sätze und DB-Segmente vom E/A-Modul holt sowie die vom Verarbeitungsmodul benötigten Argumente aussucht und in die Eingabestruktur umsetzt und andererseits die vom Verarbeitungsmodul gelieferten Ergebnisse wieder in die entsprechenden Sätze und Segmente überträgt und diese an den E/A-Modul zurückgibt. Dadurch wird der Konflikt um Funktionen und Datenstrukturen ein für allemal gelöst und mit ihm auch das Problem der "Structure Clash".

Ob sich dieser Ansatz in der Praxis bewähren wird, bleibt abzuwarten. Jedenfalls ist es ein Schritt in die gewünschte Richtung, nämlich die Programmierung auf das Wesentliche zu beschränken und gleichzeitig zuverlässige und anpassungsfähige Software zu erzielen.

*Harry Sneed ist Eigentürmer der Software Engineering Services GmbH, München, Budapest.