Wenn man erfahrene Entwickler fragt, wie man große und Komplexe Softwareprojekte umsetzt, bekommt man meistens zwei Dinge zu hören: Schichten und Komponenten. Beiden ist gemeinsam, dass sie dazu dienen, innerhalb meines Softwaresystems klare Grenzen zwischen Funktionalitäten zu ziehen und sie in Module aufzuteilen mit all den einhergehenden Vorteilen wie besserer Wiederverwendbarkeit, Wartbarkeit, Testbarkeit und – vor allem – der besseren Verteilbarkeit auf einzelne Entwickler.
Herr Ober da liegt ein Haar neben meiner Suppe…
Schaut man über den Tellerrand hinaus in andere Ingenieursbereiche erkennt man, dass dort identische Probleme existieren – und gelöst wurden: durch Modularität. Modular ist etwas, was in sich eine geschlossene Einheit bildet und über verschiedene definierte Schnittstelle angesprochen wird und seinerseits die Fähigkeiten anderer Module ebenfalls über definierte Schnittstellen nutzt. Für Benutzer eines Moduls ist deren innerer Aufbau meist vollkommen unwichtig. Betrachtet man das Modul einer Backstraße zum backen von Brot, so ist klar: Es benötigt Mehl, Hefe und Wasser und produziert Brot, mehr muss ich von Außen nicht wissen um damit Brot herzustellen. Angeschlossen an ein Mehlsilo, ein Hefesilo und eine Wasserleitung kann es also los gehen. Klar wachsen Backstraßen nicht auf Bäumen, sie müssen von irgendjemandem gebaut werden. Bei dem Bau solch eines Systems, schauen wir uns die Lösung zu zwei Problemen an, die wir auch in der Softwareentwicklung haben:
- Wie und wo fangen wir bei großen Systemen an zu entwickeln?
- Wie können wir die Arbeit auf mehrere Personen aufteilen?
Aus dem Bereich der Mathematik und der Informatik kennt man die Taktik des “Divide And Conquer” (Teile und herrsche), welches besagt das man ein großes Problem in viele kleinere Probleme unterteilt. Das macht man so lange bis alle kleinen Probleme lösen werden können und somit das Gesamtproblem gelöst ist.
Fangen wir also an unser “Problem” aufzuteilen: Eine Backstraße besteht (vermutlich, Leser der Backindustrie mögen mich bitte korrigieren) aus den Untermodulen Teigverarbeitung, Teigherstellung und Backofen wobei in das Modul Teigverarbeitung die Eingabe von Mehl, Hefe und Wasser erhält.
Wie dabei dieser Teig erzeugt wird, wie die Rohlinge geformt werden oder wie gebacken wird – das interessiert den Benutzer von Außen nicht. Hauptsache an den Schnittstellen steht das definierte Ergebnis mit den definierten Eigenschaften bereit.
Nun ist so eine Teigherstellungsmaschine (die in der Backstraße enthalten ist) auch kein einfaches Modul und so ist es ebenfalls aus Untermodulen zusammengesetzt, die – ihr werdet es nicht glauben – über fest definierte Schnittstellen miteinander kommunizieren (gähn…)
Mangels Maschinenbaustudium vermute ich das solch ein Modul aus einem Mixer (zum vermengen der Zutaten) und einem Kneter (der alles zu einem Teig knetet) bestehen wird. Dieses Spiel könnte man nun so lange treiben, bis man bei Schrauben und Kabeln der einzelnen Module angekommen ist.
Haben wir den überschaubaren Level der Schrauben und Kabel erreicht, kann losgebaut werden. Die Module auf unterster Ebene können auf die Ingenieure verteilt werden, da sie ja keine anderen Komponenten brauchen um fertiggestellt zu werden. Aber auch an den Modulen der oberen Schichten kann gebaut werden (Halterungen, Rohre, Kabel, usw.) weil deren Arbeit ebenfalls unabhängig ist – auch von Untermodulen. Denn deren Ausmaße und Schnittstellen sind je genau definiert – die Ingenieure müssen dies nur beim Bau berücksichtigen. Wurde unsere Beispiel sauber durchspezifiziert, kann an 6 Stellen losgebaut werden.
Und wie man sich die Brötchen, die aus der Backstraße kommen, mit der Softwareentwicklung verdienen kann, indem man sich genau das Prinzip zu nutze macht, schauen wir uns im nächsten Teil an… Weil jetzt habe ich Hunger!