Knigge für Softwarearchitekten

3 Der Vielsehende

Erfolgreiche Architekten nutzen verschiedene Sichten auf Systeme, um unterschiedliche Aspekte in den Vordergrund zu rücken. Sie wechseln je nach Bedarf diese Sichten, um ein gegebenes Problem aus mehreren Perspektiven zu beleuchten und so zu einer tragfähigen Lösung zu kommen.

Versetzen Sie sich in die Lage des Regisseurs einer Fernsehshow. Sie sitzen im Kontrollraum, wo die Bilder vieler Kameras zusammenlaufen. Sie haben ständig eine große Auswahl unterschiedlicher Perspektiven und können frei entscheiden, welche dieser Aufnahmen die momentane Situation am besten wiedergibt: mal die Totale, mal die Großaufnahme des Stars von der tragbaren Handkamera neben der Bühne.

Diese Möglichkeiten eines Fernsehregisseurs nutzen auch Softwarearchitekten – nur dass es sich bei ihren Möglichkeiten nicht um Kamerabilder handelt, sondern um verschiedene Darstellungen oder Abstraktionen des Systems, an dem sie gerade arbeiten. Die Grundgedanken hat Philippe Kruchten bereits 1995 in kurzer Form veröffentlicht.1 Weitere, verständliche und praxisnahe Darstellungen finden Sie in aktuelleren Werken.2 Leider aber mangelt es in der Praxis immer noch an Akzeptanz dieser einfachen Idee. Das könnte mit deren düsterer Vergangenheit zu tun haben: Schon 1987 stellte der Amerikaner John Zachman die Idee mehrerer Sichten im IBM Systems Journal unter dem Titel „A Framework For Information Systems Architecture“3 vor. Unserer Ansicht nach eine der praxisfernsten Publikationen unter der Sonne: Zachman empfiehlt sage und schreibe 30 (in Worten: dreißig) verschiedene Sichten auf Architekturen4.

Wir haben die 4+1 Sichten von Philippe Kruchten etwas „pragmatisiert“: Das „+1“ bezieht sich – wie im Original – auf die funktionalen Anforderungen (Geschäftsprozesse, Anwendungsfälle), die Sie im System implementieren müssen.

Verwenden Sie folgende Sichten (Abb. 3.1):

1. Als wichtigste die Bausteinsicht, die Sie unbedingt brauchen.
2. Dazu die Verteilungssicht, hauptsächlich bei verteilten Systemen.
3. Die Laufzeitsicht, zur Beschreibung wichtiger Interaktionen und zum Präzisieren oder Verifizieren der Bausteine.
4. Und ergänzen Sie bei Bedarf die Sichten durch übergreifende, querschnittliche, technische Konzepte.

Abb. 3.1: Sichten auf Systeme

Die Bausteinsicht

Sie zeigt die statische Sicht auf den Quellcode in unterschiedlichen Abstraktionsebenen, also die Bausteine des Systems. Die oberste Ebene – sozusagen die Totale über den ganzen Saal – zeigt unser System als eine Blackbox, eingebettet in seine Nachbarsysteme. Wenn wir näher an den Quellcode heranzoomen, erkennen wir vielleicht die Schichten des Systems oder – bei einer Pipe-und-Filter-Architektur – die wichtigsten Programmteile (die Filter) und die Verbindungen zwischen ihnen (die Pipes). Wie nahe Sie als Architekt dem Code kommen wollen, hängt von Ihren Zielen ab. Wollen Sie aus Abstraktionen oder Diagrammen automatisch Sourcecode generieren, dann werden Sie bis zu Klassen und Operationen verfeinern. Wenn Sie Programmcode hauptsächlich manuell in einer Entwicklungsumgebung pflegen, dann genügt meistens eine abstraktere Stufe.

Die Laufzeitsicht

Die Laufzeitsicht klärt die Dynamik des Systems – das dynamische Zusammenspiel (von Instanzen) der Bausteine. Sie beschreibt, wie eine Komponente eine andere aufruft, was sie dabei übergibt und wie der Ablauf von hier aus weitergeht.

Sie können hierbei ebenfalls auf unterschiedlichen Abstraktionsebenen argumentieren: Zeigen Sie Interaktionen „im Großen“ zwischen Bausteinen hoher Abstraktionsebene, um Überblick zu bieten. Beschreiben Sie Abläufe „nahe am Code“, wenn es Ihnen um Details geht.

Die Verteilungssicht

Eine dritte Sicht hilft Architekten oft noch: die Darstellung, welche Teile der Software auf welcher Hardware oder Infrastruktur ablaufen. Wir nennen das Verteilungs- oder Deployment-Sicht. Oftmals sind Architektur- und Entwurfsentscheidungen schon durch die beteiligten Rechner, Chips oder durch geografische Verteilung vorgegeben. Dann hilft es, diese Infrastruktur grafisch darzustellen (Abb. 3.2) und zu überlegen, welche Auswirkungen sie auf die Bausteinsicht oder die Laufzeitsicht hat.

Abb. 3.2: Drei wichtige Perspektiven: Baustein-, Laufzeit- und Verteilungssicht

Technische Konzepte

Auch technische Konzepte wie das Logging-Konzept oder die technischen Grundlagen der Implementierung der grafischen Oberfläche bilden eine (weitere!) Perspektive eines Systems. Diese Konzepte sind oft übergreifender Natur, wirken teilweise auf mehrere Bausteine eines Systems.

Spezielle Perspektiven nach Bedarf

In vielen unserer Projekte konnten wir mit nur drei Sichten (Bausteine, Laufzeitszenarien, Deployment/Verteilung) sowie den technischen Konzepten alle Beteiligten versorgen.

Manchmal jedoch benötigen Stakeholder weitere Sichten auf ein System. Gehen Sie in solchen Fällen pragmatisch vor: Erfragen Sie die Wünsche dieser Menschen und suchen Sie nach passenden Darstellungen. Sorgen Sie primär für Verständlichkeit, Akzeptanz und leichte Pflegbarkeit („Wartbarkeit“) in Ihren Modellen und Dokumenten. Einige Beispiele sollen Ihnen diese abstrakten Vorschläge konkretisieren:

• In stark datenorientierten Systemen können Datenmodelle eine weitere Perspektive auf das Gesamtsystem zeigen. Diese können fachlich oder technisch sein – in der historischen Kunst der Datenmodellierung hieß das „logisches“ respektive „physisches“ Datenmodell.
• Einen Sonderfall der Datensicht bilden sogenannte Fachklassen-, Business- oder Domänenmodelle. Diese konzentrieren sich auf rein fachliche „Dinge“, wobei sie manchmal Daten und Aufgaben (Services, Controller, Prozesse, Anwendungsfälle) enthalten.
• In interaktiven Systemen können grafische Entwürfe (Bildschirmmasken, Screens, Klickprototypen oder ähnliche Mittel) eine sehr anwenderorientierte Sicht zeigen. Sie funktionieren gut als Ergänzung von Laufzeitszenarien.
• Entwickler- oder Implementierungssichten können Teile der Bausteinsicht stark verfeinern. Geben Sie beispielsweise in einer solchen Sicht Implementierungsmuster oder Nutzungshinweise Ihrer favorisierten Frameworks an.
• Schließlich gibt es noch die plakative, von Technik stark abstrahierende Marketing- oder Verkaufssicht: Hiermit können Sie die nicht technischen Stakeholder durch Reduktion auf sehr wenige Elemente und Konzepte abholen.

In der Mischung liegt die Kraft

Die Bausteinsicht ist unserer Erfahrung nach die wichtigste Perspektive, so wie für den Regisseur diejenige Kamera, mit der er von der Totalen bis hin zum kleinsten Detail zoomen kann. Oftmals unterstützen die anderen Sichten Architekten dabei, Durchblick im Dickicht komplexer Strukturen zu gewinnen. Wechseln von Perspektiven macht Architekturen schneller stabil, weil verschiedene Einflussfaktoren besser ans Tageslicht kommen.

Lernen Sie als „Ablaufdenker“ einmal mehr in statischen Strukturen zu denken, aber als „Bausteinmensch“ mehr in Abläufen und Verteilung.