Knigge für Softwarearchitekten

Erfolgsmuster: Der vielsehende Architekt

Peter Hruschka, Gernot Starke

Willkommen in der dritten Ausgabe unserer Kolumne rund um Verhaltensmuster von Softwarearchitekten.

Drittes Muster: 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 somit zu einer tragfähigen Lösung zu kommen. Versetzen Sie sich in die Lage des Regisseurs einer erfolgreichen 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 ihnen nicht um Kamerabilder handelt, sondern um verschiedene Darstellungen oder Abstraktionen des Systems, an dem sie gerade arbeiten. Die Idee ist schon älter, sie wurde bereits in „Architectural Blueprints — The “4+1” View Model of Software Architecture“ populär gemacht sowie in „Software Systems Architecture with Stakeholders using Viewpoints and Perspectives“ und „Effektive Software-Architekturen – ein praktischer Leitfaden“ verständlich und praxisnah dargestellt – leider aber mangelt es in der Praxis immer noch an Akzeptanz.

Das könnte mit der düsteren Vergangenheit dieser Idee 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 vor. Unserer Ansicht nach eine der praxisfernsten Publikationen unter der Sonne: Zachman empfiehlt sage und schreibe 30 (in Worten: dreißig) verschiedene Sichten auf Architekturen.

Die Bausteinsicht

Eine der Sichten, die Architekten unbedingt benötigen, ist die Bausteinsicht. Sie zeigt die statische Sicht auf den Sourcecode, also die Bausteine des Systems, in verschiedenen Abstraktionsebenen. Die gröbste Ebene davon – sozusagen die Totale über den ganzen Saal – zeigt unser System als eine Blackbox, eingebettet in seine Nachbarsysteme. Interessanter ist es, etwas näher an den Sourcecode heranzuzoomen. Dann werden vielleicht die Schichten des Systems sichtbar oder – bei einer Pipe-und-Filter-Architektur – die wichtigsten Programmteile (die Filter) und die Verbindungen zwischen diesen (die Pipes). Wie nahe Sie als Architekt an den Sourcecode heranzoomen wollen, hängt ein bisschen von Ihren Zielen ab. Wollen Sie aus diesen Diagrammen oder Abstraktionen automatisch Sourcecode generieren, dann werden sie bis zu Klassen und Operationen verfeinern. Wenn Sie Sourcecode unabhängig von diesen Bausteinabstraktionen in einer Entwicklungsumgebung pflegen, dann genügt meistens eine abstraktere Stufe.

Viele Architekten denken in Abläufen

Manchen Architekten und Entwicklern liegt das Denken in dynamischen Abläufen viel näher. Sie stellen sich vor, wie eine Komponente eine andere aufruft, was sie dabei übergibt und wie der Ablauf von hier aus weitergeht. Dafür wechseln wir zur Laufzeitsicht. Sie stellt das dynamische Zusammenspiel (von Instanzen) der Bausteine dar. Hilfreich ist hier, das Zusammenspiel auf höheren Abstraktionsebenen zu betrachten, statt sich im Detail einzelner Klassen und Operation zu verlieren.

Verteilte System laufen verteilt

Eine dritte Sicht hilft Architekten oft noch: die Darstellung, welche Software auf welcher Hardware oder Infrastruktur läuft. Wir nennen das Verteilungs- oder Deployment-Sicht. Oftmals sind Designentscheidungen schon durch die beteiligten Rechner, Chips oder durch geografische Verteilung vorgegeben. Dann hilft es, diese Infrastruktur grafisch darzustellen und zu überlegen, welche Auswirkungen sie auf die Bausteinsicht oder die Laufzeitsicht hat.

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.

Wir raten Ihnen, diese Sichten insbesondere bei Architekturen einzusetzen, mit denen Sie nicht so vertraut sind. Lernen Sie als „Ablaufdenker“ einmal mehr in statischen Strukturen zu denken, aber als „Bausteinmensch“ mehr in Abläufen und Verteilung.

Peter Hruschka und Gernot Starke haben vor einigen Jahren www.arc42.de ins Leben gerufen, 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, Softwareentwurf und Entwicklungsprozesse. Mehr finden Sie unter www.systemsguild.com (Peter) und www.gernotstarke.de (Gernot).
Geschrieben von
Peter Hruschka, Gernot Starke
Kommentare

Schreibe einen Kommentar

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