Knigge für Softwarearchitekten

Unterschiedliche Sichten auf Architekturen
Kommentare

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 ihnen nicht um Kamerabilder handelt, sondern um verschiedene Darstellungen oder Abstraktionen des Systems, an dem sie gerade arbeiten. Die Grundgedanken hat Phillipe Kruchten bereits 1995 in [1] in kurzer Form veröffentlicht. Weitere, verständliche und praxisnahe Darstellungen finden Sie in [2] und [3]. 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 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.

Wir haben die 4+1 Sichten von Philippe Kruchten aus [1] 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:

  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 Konzepte.

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.

Warstory

Teile eines Systems haben wir mithilfe eines Generators aus einem UML-Modell generiert (genauer: die gesamte Persistenzschicht inklusive die DB-Tabellen). Diese Generierung betraf ausschließlich die fachlichen Bausteine (Entitäten) des Systems – diese mussten wir daher bis auf Attributebene modellieren. An anderen Stellen des selben Systems waren alle Beteiligten damit zufrieden, dass wir auf sehr grober Ebene die Subsysteme mit ihren Schnittstellen beschrieben haben.

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.

Hinweis

Speziell in der Laufzeitsicht hilft es oftmals, Bausteine unterschiedlicher Abstraktionsebenen in konkreten Abläufen zusammenzubringen. Da darf ein großer, abstrakter Baustein (Beispiel: die „UI-Schicht“ oder das „SAP-FI-Modul“) gerne mit sehr feingranularen Bausteinen zusammenarbeiten.

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 und zu überlegen, welche Auswirkungen sie auf die Bausteinsicht oder die Laufzeitsicht hat.

Drei wichtige Perspektiven: Baustein-, Laufzeit- und Verteilungssicht

[ header = Technische Konzepte]

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.

War Story

Der Auftraggeber eines sehr innovativen und architektonisch anspruchsvollen Systems war ein Rechenzentrum, das mit starkem Fokus auf den Betrieb und die Administration des Systems agierte. Für diese Auftraggeber waren Verteilungssichten und Betriebshandbücher essenzielle Bestandteile der Lieferung, die zu jedem Release erwartet wurden und ohne die es keine Abnahme gab. Unser Projekt musste zusätzlich einem technischen Lenkungskreis monatlich die wichtigen Entscheidungen, Strukturen und Konzepte berichten. Für diese beiden Stakeholdergruppen haben wir im Projekt aus unserem (gut gepflegten) Wiki nach jeder Iteration sämtliche notwendigen Dokumente generiert – ohne dass wir Informationen doppelt pflegen mussten.

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 so genannte 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, Klick-Prototypen 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 nichttechnischen 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.

Hinweis

Verwenden Sie bewusst verschiedene Perspektiven auf Ihr System.

  • Drei klassische Sichten (Baustein-, Laufzeit- und Verteilungssicht) ergänzen Sie um die benötigten technischen Konzepte.
  • Oft bringt ein Domänenmodell zusätzliche Transparenz in die fachlichen Aspekte eines Systems. Hier lohnt ein Blick auf das Domain-driven Design ([4] und insbesondere [5]).
  • Setzen Sie unterschiedliche Sichten insbesondere bei Architekturen ein, mit denen Sie weniger vertraut sind.
  • Beachten Sie die Wechselwirkung zwischen den Perspektiven: Eine Entscheidung in der Bausteinsicht oder einem technischen Konzept hat möglicherweise gravierende Konsequenzen an anderen Stellen.

Verwandte Muster

Sie nutzen strukturierte Faulheit (Kap. 4) mit Augenmaß: Verwenden Sie nur die Sichten oder Perspektiven, die für Ihre Stakeholder bzw. zur Erreichung Ihrer Ziele wirklich angemessen sind – mit dem dringenden Ziel der Sparsamkeit in allen Belangen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -