Modularisierung in der Softwaretechnik

Orgelsteuerung (Quelle: Wikipedia)

Wenn in Bezug auf Software von Modularisierung die Rede ist, muss zunächst einmal geklärt werden, worauf genau sich diese Modularisierung bezieht. Software in dem hier gemeinten Sinn kann allgemein als eine Anzahl von Instruktionen verstanden werden, die in einer Programmiersprache formuliert sind. Ein nicht modularisiertes System wäre in diesem Sinne eine nicht weiter zerlegte bloße Sammlung oder Sequenz von Instruktionen, ähnlich dem in der nebenstehenden Abbildung gezeigten Endlosbuch einer Tanzorgelsteuerung.

Software als "Instruktionen, die in einer Programmiersprache formuliert sind" legt eine gewisse imperative Sichtweise nahe. Diese Festlegung soll hier zwar nicht getroffen werden. Dennoch erscheint Modularisierung im Kontext beispielsweise deklarativer Sprachen weniger verbreitet und ggf. auch weniger sinnvoll als in einem imperativen Kontext. Nichtsdestotrotz könnten mit Instruktionen im hier gemeinten Sinn auch Regeln aus Prolog, Abfragen in SQL oder die Überführungsfunktion einer Turingmaschine gemeint sein. Es steht an dieser Stelle nicht im Vordergrund, die Eignung von Modularisierung für unterschiedliche Programmierparadigmen zu beurteilen. Wir stellen also folgende Definition auf:

Die Modularisierung von Software bezeichnet die Aufteilung einer Menge programmiersprachlicher Instruktionen in syntaktisch identifizierbare Teile, die im Sinne der Funktion des Gesamtsystems zusammenwirken.

Prozeduren als frühe Form der Modularisierung

In der Geschichte der Programmiersprachen taucht Modularisierung in diesem weiten Sinn erstmals in Form der Prozeduren von Algol 60 auf. Die Algol 60-Prozeduren waren syntaktisch identifizierbar (durch das Schlüsselwort procedure), wiesen verschiedene Parameterformen auf (Namens- und Wertparameter) und stellten erstmalig Gültigkeitsbereiche für Variablen zur Verfügung. Algol 60 wurde damit zu einem Wegbereiter der strukturierten Programmierung. Die Bedeutung dieser "Modularisierung" auf Prozedur-Ebene wird deutlich, wenn man sich die monolithischen Programme der wenige Jahre zuvor veröffentlichen ersten höheren Programmiersprache Fortran vergegenwärtigt, deren Kontrollfluss im Wesentlichen mittels der GOTO-Anweisung gesteuert wurde. 

Module und modulare Programmierung

Der nächste größere Modularisierungs-Schritt taucht in der Folge der Formulierung des Geheimnisprinzips in [Parnas1972] auf und lässt sich nun auch bereits namentlich als Modularisierung erkennen: Mit MODULA-2 stellt Niklaus Wirth einen Pascal-Nachfolger vor, der Module als Zusammenfassung mehrerer Deklarationen (darunter auch Prozeduren) bereitstellt. Das Schlüsselwort MODULE ermöglicht die gewünschte syntaktische Identifizierbarkeit. Eine wichtige Rolle spielt zudem die Trennung von Definition und Implementierung, die sich syntaktisch dadurch zeigt, dass jedes Modul durch ein DEFINITION MODULE und ein IMPLEMENTATION MODULE umzusetzen ist. Diese Trennung von öffentlicher Schnittstelle eines Moduls und interner Umsetzung ist die wesentliche Eigenschaft, die das Geheimnisprinzip realisiert. In Verbindung mit einem entsprechenden Import-Mechanismus und separater Kompilierbarkeit der Module ermöglicht dies insbesondere die Arbeit verschiedener Entwickler an verschiedenen Teilen einer Anwendung und wird somit zu einer wesentlichen Grundlage zur Entwicklung größerer Software-Systeme.

Modularisierung auf höheren Ebenen

Es fällt leicht sich vorzustellen, dass diese Zusammenfassung von Einheiten zu übergeordneten Einheiten (Instruktionen zu Prozeduren, Prozeduren zu Modulen, ...) eine unbeschränkt anwendbare rekursive Methode ist. Module im Sinne von MODULA-2 oder die entsprechenden Klassen in objektorientierten Sprachen lassen sich ihrerseits zu etwas zusammenfassen, das einen neuen Namen benötigt. Die UML hat in diesem Kontext den Begriff der Komponente geprägt. OSGi bezeichnet diese Form der Modularisierung als Bundle. In serviceorientierten Umgebungen spricht man von einem Service. Immer bringen diese Formen der Modularisierung neben den allgemeinen Moduleigenschaften zusätzliche Spezifika mit, die der jeweiligen Modularisierungs-Ebene angemessen sind und bestimmte Vorteile des Modularisierungs-Prinzips verstärken sollen.

Quellen

[Parnas1972] – On the Criteria To Be Used in Decomposing Systems into Modules, David L. Parnas, in: Communications of the ACM, 1972