Kolumne

Knigge für Softwarearchitekten: Der Flexibilisator

Peter Hruschka, Gernot Starke

Der Flexibilisator implementiert seine Komponenten oder Systeme am liebsten so: generisch, möglichst auf viele zukünftige Gegebenheiten vorbereitet, universell einsetzbar und grenzenlos flexibel in alle Richtungen. Er findet den ultimativen Kick, wenn er über den beschränkten Spezialfall der aktuellen User Story hinaus quasi ein zeitloses Denkmal der Flexibilität erschaffen kann. Kennen Sie das auch, diesen Drang nach Verallgemeinerung, den tiefen Wunsch, etwas Großes zu schaffen? Wir möchten in dieser Folge zuerst etwas über mögliche Arten der Flexibilität von Software klarstellen, auf einige Vor- und Nachteile davon eingehen und anschließend kräftiges Bashing auf Flexibilisatoren betreiben.

Flexibilität kann bei Software verschiedene Dinge bedeuten. Wir erklären das anhand des Begriffs „Komponente“, wobei diese Komponente eine beliebige Größe oder einen beliebigen Leistungsumfang haben kann, von einzelnen Klassen bis hin zu umfangreichen Systemen:

  • Flexibilität zur Laufzeit (Konfigurierbarkeit zur Laufzeit): Zur Laufzeit der Komponente lassen sich unterschiedliche Parameter setzen oder verändern. Beispiele dafür sind konfigurierbare Benutzungsoberflächen (etwa: skinnable UI), konfigurierbare Abläufe, Prozesse, Pfade, Gültigkeitsregeln oder sogar Datenstrukturen.
  • Flexibilität bezüglich Installation oder Inbetriebnahme (Konfigurierbarkeit zum Lade- oder Startzeitpunkt): Die Komponente lässt sich in verschiedenen Umgebungen in Betrieb nehmen, mit verschiedener Hardware, Betriebssystemen oder Netztopologien. Wesentliche Parameter wie Speicher, Netzwerk oder Datenbank lassen sich bei der Installation konfigurieren.
  • Flexibilität bezüglich Test: Die Komponente lässt sich in verschiedenen Umgebungen oder Konfigurationen testen. Beispielsweise ist sie unabhängig von der konkreten Ressourcenausstattung oder Konfiguration der Testumgebung. Oder es können zum Test Mocks oder Stubs für Teilsysteme eingesetzt werden.
  • Flexibilität bezüglich der Entwicklungszeit: Eine Komponente bietet eine flexible oder universell verwendbare Schnittstelle an, sodass sie in unterschiedlichen Verwendungssituationen oder von unterschiedlichen Konsumenten benutzt werden kann, möglicherweise über Grenzen einzelner Programmiersprachen hinweg.

Bei manchen Systemen freuen wir uns als Benutzer über die Konfigurierbarkeit zur Laufzeit, beispielsweise bei Firefox. Viele Aspekte seines Aussehens und auch Verhaltens können wir in der etwas unübersichtlichen, aber sehr mächtigen about:config zur Laufzeit anpassen. Eine gefährliche Eigenschaft, wenn sie in die falsche Hände gerät. Es ist diese Laufzeitflexibilität, der wir uns an dieser Stelle primär widmen.

Peter Hruschka (System Guild) und Dr. Gernot Starke (innoQ-Fellow) haben vor einigen Jahren www.arc42.de gegründet, das freie Portal für Softwarearchitekten. Sie sind Gründungsmitglieder des International Software Architecture Qualification Board (www.iSAQB.org) sowie Autoren mehrerer Bücher rund um Softwarearchitektur und Entwicklungsprozesse.

Generisch ist nicht gut

Mit ausreichend Bosheit, Dummheit oder Verwirrung ausgestattet, können wir als Benutzer unseren Browser, um bei diesem Beispiel zu bleiben, ganz schön verunstalten: Schwarze Schrift auf schwarzem Grund, den Proxyserver auf eine nicht existente Adresse eingestellt und dann noch die Adresszeile ausgeblendet. Damit ist der schöne Browser praktisch nicht mehr zu gebrauchen. Wenn der Flexibilisator voll zuschlägt, schenkt er den späteren Nutzern seiner Software eine Menge an Freiheitsgraden. Allerdings setzt er sie gleichzeitig gravierenden Risiken aus. Aber der meist jugendlich-leichtsinnige Flexibilisator denkt sich: „No risk, no fun.“ Hochgradig generisch oder allgemein verwendbar bedeutet, auf teilweise sinnvolle oder sogar notwendige Grenzen zu verzichten. Nennen wir die ultraflexiblen Produkte des Flexibilisators mal „übermäßig laufzeitkonfigurierbare Systeme“ (Overly Runtime Configurable Systems, kurz ORCS). Diese Abkürzung weckt doch hoffentlich auch bei Ihnen Assoziationen zum Herr-der-Ringe-Filmepos.

Wie kommt es zu ORCS?

Bekommen normale Entwicklungsteams halbwegs vernünftige Anforderungen, so entsteht hoffentlich klar strukturierte Software, die eben genau diese Anforderungen erfüllt. Schematisch finden Sie das in Abbildung 1 oben dargestellt (Variante 1), vom klar umrissenen Problem zur klar abgegrenzten Lösung. Sind die Anforderungen hingegen nur teilweise klar, ergibt sich eine leicht diffuse Lösung (in der Abbildung Variante 2). Schlimm wird es, wenn Anforderungen völlig vage oder unklar daherkommen, also im klassischen Fall von unterspezifiziert à la „die wissen nicht, was sie wollen“. Das finden Sie in Variante 3 der Abbildung: wolkige Software, die auf zu viele Eventualitäten vorbereitet ist, ohne klare Abgrenzung. In praktisch allen Fällen enthält Variante 3 viel viel mehr Code als Variante 1, ist viel größer und ungleich schwerer verständlich. Von Wartbarkeit mögen wir in Variante 3 schon gar nicht mehr reden.

Abb. 1: Umso klarer die Anforderungen, umso klarer die Implementierung

Abb. 1: Umso klarer die Anforderungen, umso klarer die Implementierung

Unser Flexibilisator bringt dieses Schema kräftig durcheinander. Er schafft es nämlich, aus einer glasklar und präzise formulierten Anforderung ein schwer fassbares Oeuvre zu produzieren – ein nach allen Seiten offenes Wunderding der Softwarekunst. In Abbildung 2 zeigen wir sein Wirken schematisch.

Abb. 2: Der Flexibilisator macht aus klar strukturierter Software ein unfassbares Kunstwerk

Abb. 2: Der Flexibilisator macht aus klar strukturierter Software ein unfassbares Kunstwerk

Flexibilisatoren verletzten die Forderung nach Kohäsion. Sie bauen Systeme oder Komponenten, die wesentlich mehr als eine einzige Sache erledigen. Jetzt können Sie berechtigt sagen: „Ist doch gut, wenn das System schön flexibel ist und sich an viele Nutzerbedürfnisse anpassen lässt.“ Das ist richtig. Doch dem halten wir Aufwände und Kosten entgegen – schematisch in Abbildung 3 dargestellt. Kompakte, wohlstrukturierte Software, bestehend aus Komponenten hoher Kohäsion hat tendenziell deutlich geringere Erstellungs- und Wartungskosten als ORCS.

Abb. 3: Bei ORCS explodieren die Wartungskosten

Abb. 3: Bei ORCS explodieren die Wartungskosten

Die Kurve verläuft nicht linear. Ein bisschen Flexibilität über die heutigen Anforderungen hinaus hält die Wartungskosten und -aufwände im Rahmen. Doch noch mehr Flexibilität und die Kosten steigen exponentiell. Wir sehen primär drei Gründe, die zu ORCS führen:

  • Unsäglich schlechte, unklare und vage Anforderungen.
  • Die Sippschaft der Flexibilisatoren, die es trotz klar umrissener Aufgaben- oder Problemstellung schaffen, ihre Lösungen noch generischer, noch allgemein verwendbarer, noch konfigurierbarer zu gestalten.
  • Schließlich ist da noch die Freude am Komplexen: Es bereitet manchen unsägliche Freude, komplizierte oder komplexe Probleme zu lösen. Warum sollen wir nur das triviale Problem der aktuellen Anforderung lösen, wenn wir doch ganz leicht ein viel spannenderes Problem darum herum erfinden können?

Fazit

Sicherlich gibt es noch viele andere Gründe, warum Software ORCS-mäßig wird. Sicherlich gibt es auch viel mehr Vorteile (laufzeit-)flexibler Systeme, als wir sie hier dargestellt haben. In jedem Fall aber gilt: Je mehr Stellschrauben ein System besitzt, desto schwerer lässt es sich ändern, desto aufwendiger ist das Testen, desto teurer sind Bugfixes und desto schneller degradiert es zu höllischem Treibsand, in dem Nebenwirkungen nicht mehr zu kalkulieren sind. Besonders flexible und generische Komponenten sind meist umfangreicher und schwerer verständlich als ihre spezifischen Pendants. Verzichten Sie auf die Herausforderung der Allgemeinverwendbarkeit oder Generalität. Finden Sie den adäquaten Kompromiss zwischen zu starr und zu flexibel. Bereiten Sie Ihre Software für sehr wahrscheinliche Änderungen und Ergänzungen vor, aber nicht für alle potenziell denkbaren Eventualitäten, die dann doch nicht eintreten und auch nicht gebraucht werden.

Geschrieben von
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare
  1. TestP2017-01-04 21:37:01

    Da erkenne ich mich schon ein wenig darin wieder. :/ Zwar vielleicht nicht so extrem wie in diesen Beispielen aber manchmal bekommen die Nutzer mehr Optionen von mir als es denen gut tut.

    Grüße

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.