Was ist was? Band 127: Unser Softwaresystem

Erinnern Sie sich noch an die „Was ist was?“-Bücher über Natur, Technik und vielem mehr [1]? Die Reihe gibt es noch immer; sie leistet mir gute Dienste, wenn meine Kinder mich mit Fragen bombardieren. Der menschliche Körper etwa ist ziemlich komplex. Um ihn zu beschreiben, zerlegen Bücher dieser Art ihn in funktionale, in sich abgeschlossene Teile. Es gibt reich bebilderte Kapitel über die Muskeln, die Atmung oder das Verdauungssystem. In diesen wird weiter verfeinert, kleinere Bauteile wie Herz und Lungen und ihr Zusammenspiel werden im Kontext des Teilsystems anschaulich erklärt.

Was das mit Architekturdokumentation zu tun hat? Softwaresysteme sind ebenfalls komplexe Gebilde. Zu ihrer Beschreibung bedient sich ein Architekt, wie in der letzten Folge ausgeführt, verschiedener Sichten. Eine davon haben Sie in dieser Reihe bereits kennen gelernt: den Systemkontext [2]. Eine weitere Sicht, die in keiner Architekturbeschreibung fehlen darf, stellt das System als Summe seiner funktionalen Teile dar, und zeigt deren Beziehungen untereinander. Die Literatur verwendet unterschiedliche Bezeichnungen (Struktursicht, Bausteinsicht, …), die Funktion ist aber stets die gleiche.

Die Zerlegung der anvisierten Softwarelösung in Bausteine ist eine zentrale Aktivität des Architekturentwurfes; Entscheidungen, die hier getroffen werden bilden den Rahmen für alles weitere. Ganz ähnlich wie jedes Organ eine bestimmte Aufgabe erfüllt, sollten auch Subsysteme und Komponenten innerhalb eines Softwaresystems klar abgegrenzte Verantwortlichkeiten haben. Eine angemessene Zerlegung des Softwaresystems in unabhängige Teile mit Schnittstellen untereinander erleichtert die Entwicklung in Teams, die Weiterentwicklung und Pflege, und sie eröffnet eine spätere Wiederverwendung oder einen Austausch von Teilen. Modularisierung ist kein Java-spezifisches Thema, doch gerade in unserer Gemeinde hochaktuell, wie das große Interesse am dynamischen Modulsystem OSGi zeigt.

Beim Entwurf der Bausteinsicht zerlegen Sie Ihr Softwaresystem top-down ausgehend von der Kontextsicht. Dort war das System noch eine Blackbox, jetzt schauen Sie hinein (Whitebox). Im ersten Schritt zeigen Sie die identifizierten Subsysteme mit ihren Abhängigkeiten untereinander. Jedes einzelne ist dann wieder eine Blackbox. Bei komplexen Systemen wiederholt sich dieser Vorgang einige Male; es entstehen Ebenen unterschiedlicher Detaillierung. Sie landen über System, Subsystemen, Modulen und Komponenten irgendwann bei der Implementierung.

Als Form der Darstellung bieten sich Visualisierungen an, da sich die Systemstruktur mit ihren Elementen und deren Beziehungen untereinander graphisch leicht kommunizieren lässt. Die UML kennt beispielsweise das Kompositionsstrukturdiagramm als mögliche Notation. Es zeigt die Struktur von Komponenten, die ein übergeordnetes Größeres realisieren (vgl. Abb. 1), und macht den Übergang zwischen den Ebenen (Blackbox, Whitebox) explizit.

Abb. 1: Ein Kompositionsstrukturdiagramm der UML2

Auch wenn Sie mit dieser Technik nach Belieben in das System hineinzoomen können, empfehle ich im Rahmen einer Architekturdokumentation nicht beliebig detailliert zu werden. Es wird sehr aufwendig, den Entwurf konsistent zur Implementierung zu halten. Eine veraltete Bausteinsicht bringt später keinen Mehrwert. Aktuell gehalten hingegen kann sie im weiteren Verlauf zur Kommunikation der Lösungsideen im Rahmen von Architekturbewertungen dienen, und zur Einarbeitung neuer Mitarbeiter („Was ist was?“). Formal als Modell beschrieben kann eine Bausteinsicht auch Ausgangspunkt sein für das Generieren verschiedenster Artefakte.

Zum Schluss noch einmal zurück zum menschlichen Körper. Dass man ihn in unterschiedliche „Subsysteme“ zerlegen kann, hat nicht nur die Einsteigerliteratur entdeckt. Die Ärztezunft macht sich diesen Aspekt für ihre Spezialisierungen zunutze. Ein Herzchirurg kennt sich nur mit einer Komponente, inkl. des Zusammenspiels mit den beteiligten Fremdsystemen, richtig gut aus. Bei IT-Fachkräften kann es ebenfalls schnell zu Spezialisierungen kommen. Man schaue sich nur Berater für spezielle SAP-Module an. Einen Softwarearchitekten möchte ich lieber mit einem Allgemeinmediziner vergleichen: „Wo tut’s denn weh?“

Links & Literatur

[1] “Was ist was? Band 50: Unser Körper”, Tesloff 1972, aktuelle Auflage 2005
[2] S. Zörner: „Kombiniere – der Systemkontext“, Java Magazin 11.2008

Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
“Was ist was? Band 127: Unser Softwaresystem”, Java Magazin, 01/2009, 1 Seite, S. 69
(mit freundlicher Genehmigung)