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.

17.10.1975

Jeder meint, er programmiert schon so. Aber stimmt das wirklich?Die Prinzipien der Modularisierung im Software-Engineering

MANNHEIM - Es ist immer wieder verblüffend, wie viel über modulares Programmieren gesprochen und wie wenig modular programmiert wird. Was einem täglich in der Praxis als modular begegnet, ist meist nur jener Aberglaube, der meint, etwas wie auch immer in Stücke zu brechen, heiße modular arbeiten.

"Software-Engineering" aber ist etwas anderes. Modularisierung bedeutet, ein unstrukturiertes Problem dadurch zu losen, daß seine hierarchische Struktur aufgefunden wird, das heißt daß es in eine strukturierte Menge von Teilproblemen zerlegt wird, die auf tieferer Stufe einfacher sind als das ursprüngliche Problem.

Solche Teillösungen in algorithmischer Formulierung nennen wir Moduln. Aus diesen Erkenntnissen ergeben sich die folgenden Regeln:

- Moduln müssen in ihrer Gesamtheit eine echte hierarchische Zerlegung des ursprünglichen Problems sein.

Die Definition ist rekursiv und gilt jede weitere Zerlegung von Teilproblemen in solche tieferer Stufe. Jede Ebene operiert mit einem wohldefinierten Satz von Operationen und löst genau die Probleme der jeweiligen Ebene. Jede Ebene formuliert Operationen, die auf der nächst höheren Ebene angewendet werden. Im einfachsten Fall bilden Makro-Definitionen eine solche der Assemblersprache übergeordnete Schicht.

- Moduln müssen in der Lage sein, eine Entscheidung im endgültigen System aufzuschieben.

Dies bedeutet insbesondere, daß Moduln dort innerhalb eines Systems stehen müssen, wo noch keine endgültigen Entscheidungen getroffen worden sind. Es soll etwa innerhalb eines komplizierten statistischen Auswertungssystems eine Trendberechnung

Vorgenommen werden, für die es mehrere Algorithmen gibt. Dadurch daß sich an der Stelle CALL TREND mehrere verschiedene Algorithmen einbauen lassen, wird nicht nur ein einzelner Programmkomplex errichtet sondern eine Familie von Programmen, die für besondere Zwecke durch Modulaustausch aktualisierbar sind. Das Prinzip der aufgeschobenen Entscheidung in struktural gleichartigen Programmen fördert die Adaptierbarkeit von Programmen an neue Aufgaben aber auch an neue Installationen.

- Moduln müssen überschaubar und einfach sein.

Die Überschaubarkeit wird hier verstanden als eine psychologische Funktion. Der Mensch kann nur eine bestimmte Informationsmenge verarbeiten. Die Modulgröße sollte sich also auf das gleichzeitig Wahrnehmbare beschränken. Moduln sollten deshalb nicht größer sein als eine Seite Listing oder 50 Zeilen Statements. Die Einfachheit bezieht sich ferner auf die Modulstruktur selbst. Ein Modul darf nur einen Ein- und Ausgang besitzen. Sind mehrere Ein- oder Ausgänge vorhanden, so wird mehr als eine Funktion realisiert, und dies widerspricht dem Prinzip der funktionalen Eindeutigkeit- Jeder Modul realisiert eine und nur eine wohldefinierte Funktion.

- Moduln müssen interaktiv einfach sein.

Moduln stehen nicht für sich, sondern arbeiten mit anderen Moduln zusammen. Sie verkehren miteinander über Aufrufe; mittels Parametern und über gemeinsame Daten. Die Schnittstellen müssen von größtmöglicher Einfachheit und Eindeutigkeit sein. Jeder Modul muß unabhängig vom Funktionieren anderer Moduln und unabhängig von der Umgebung, in der er arbeitet, richtige Ergebnisse produzieren. Also muß jeder Modul falsche Aufrufe oder falsche Werte zurückweisen.

Die Schnittstellen müssen generell sein Jeder muß mit jedem potentiell verkehren können. In einem System jedoch muß jeder möglichst wenig mit jedem verkehren.

- Moduln sollen so entworfen werden, daß sie wiederverwendet werden können.

Man darf beim Programmieren nicht nur das gegenwärtige Problem im Auge haben, sondern auch bereits zukünftige Probleme. Bei Konstruktion eines Systems müssen auch neue Elemente für den Baukasten zukünftiger Systeme abfallen Jede schon einmal programmierte Funktion kostet später weniger als eine Neuprogrammierung.

Daraus ergibt sich, daß Moduln so entworfen werden sollten, daß in jeder Phase der Integration die Richtigkeit des integrierten Systemteils aus der Richtigkeit der benutzten Moduln hervorgeht. Dies verbietet insbesondere Seiteneffekte und Programmiertricks.

Was hier als Grundregeln für Modularisierung vorgestellt wurde, machen gute Programmierer natürlich schon immer. Allerdings werden alle Programmierer behaupten, daß sie es schon immer so machen. Das stimmt leider nicht.

Gerhard Ziegler, Mannheim, ist freier Systemanalytiker.