Training - Beratung - Projektarbeiten

www.David-Tielke.de

Softwarearchitektur: Komponenten Teil 1 - Was wir von anderen Industrien lernen können.

imageWenn 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:

  1. Wie und wo fangen wir bei großen Systemen an zu entwickeln?
  2. 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.

image

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…)

image

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.

image

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!

Kommentare (4) -

  • Robert Mühsig

    17.02.2012 16:23:55 | Antwort

    Der Wunsch die Softwareentwicklung mehr wie ein industrialisierten Prozess abzuwickeln ist verständlich, allerdings habe ich noch keinen sinnvollen Weg gesehen. Oftmals sind die Module so "einzigartig" in ihrer Funktionsweise, dass man am Ende nix zusammenstecken kann - ohne am Ende doch wieder rumzubasteln. Bin gespannt & guten Hunger Smile

  • David

    17.02.2012 16:27:07 | Antwort

    Hallo Robert,
    Allerdings, da stimme ich dir leider zu. Abgesehen von einer Hand voll Einzelkomponenten (Logging, Useramanagement,...) ist das meist so. Allerdings soll es hier nicht um die Entwicklung von Standardkomponenten gehen (wäre aber auch interessant...), sondern darum wie man große Softwaresysteme entwickeln kann, wie man das Ganze im Team aufteilen kann und vor allem wie man Komponenten entwickelt wie man dann evtl. an anderer Stelle ohne Abhängigkeiten wieder verwenden kann Smile

  • Christian

    17.02.2012 16:53:07 | Antwort

    Ich denke auch das es schwierig ist bei größeren Sachen noch unabhängige Module zu bauen. Meiner Erfahrung nach kann man bei einer mehrschichtigen Architektur meistens nur die untersten Schichten wirklich total unabhängige Module bauen. Die obersten sind meistens abhängig von oberen oder unteren, ohne die sie nicht laufen würden. Wäre also interessant wie man das Problem vielleicht vermindern könnte. Das man das natürlich nicht ganz verhindert ist mir klar ;) Außerdem wäre interessant wie abstrakt man Komponenten und deren Inputs designen kann, umso eine größere Wiederverwendbarkeit zu gewährleisten. Gibt es eigentlich gute Frameworks, welche ein modulares Design für die eigene Software erleichtern. (in Java gibt es da ja OSGI)

    Freue mich also auf weiteren Teile und vielleicht beantworten sich da meine Fragen Smile

  • David

    17.02.2012 16:58:35 | Antwort

    Es kommt immer darauf an, wenn man im BL eine Komponente Rechteverwaltung hat, bestehen nur Abhängigkeiten zu einem IUserRepository - Interface, wobei man die Instanz dazu der DI injizieren kann. Dann bist du komplett unabhängig. Problematisch wird es, wenn ich der Rechteverwaltung durch eine Schnittstelle ein User-Objekt übergebe, dann bin ich von dem Porjektteil abhängig der die Entitäten bereitstellt. Es gibt zwar für das Entity-Framework mittlerweile die POCO-Templates aber wirklich lösen tut man das Problem damit nicht. Ist halt immer ein Leben voller Kompromisse Smile

Kommentar schreiben

Loading