In Teil 1 meiner dreiteiligen Blogserie habe ich erläutert, was Softwarearchitektur ist und was die Arbeit eines Softwarearchitekten oder einer -architektin umfassen kann. In diesem zweiten Teil möchte ich auf das Handwerkliche zu sprechen kommen: Bei der Erstellung von Softwarearchitekturen hat mir bisher ein Hilfsmittel gefehlt, an dem ich mich «durchhangeln» kann – nämlich ein pragmatisches Template, das auch die Kommunikation unterstützt.
Wer in der Schweiz im Umfeld des Bundes IT-Projekte abwickelt, kennt sicherlich die HERMES-Vorlagen. Diese haben zweifelsohne ihren praktischen Nutzen, sind aber methodisch für die Softwarearchitektur nicht brauchbar. Während des Studiums des Buchs «Effektive Softwarearchitekturen – Ein praktischer Leitfaden» bin ich auf arc42 gestossen. Dies ist das von mir lang ersehnte Instrument: eine Art Baukasten, der mich durch die Erstellung einer Softwarearchitektur führt.
Im arc42-Template werden alle relevanten Teile einer Softwarearchitektur adressiert. Mittlerweile verwende ich diesen Baukasten auch zur Strukturierung meiner Softwarearchitektur-Dokumentationen.
Doch wie genau kommuniziert man nun angemessen über Architekturen? Nach wie vor gilt: Ein Bild sagt mehr als tausend Worte. Ich möchte somit ein besonderes Augenmerk auf die Sichten von Architekturen legen (vgl. die Punkte 3, 5, 6 und 7 im arc42-Template). Mit Sichten kann ein System aus unterschiedlichen Perspektiven gezeigt werden.
Im Wesentlichen gibt es vier Typen:
- Kontextsicht
- Bausteinsicht
- Laufzeitsicht
- Verteilungssicht
Kontextsicht und Bausteinsicht
Ich fasse diese beiden Sichten zusammen, da sie sich gut kombinieren lassen.
Die Kontextsicht (Level 0) zeigt das zu bauende System als Blackbox mit all seinen Schnittstellen zu Umsystemen und Interaktionen mit Stakeholdern.
Die Bausteinsicht zeigt den Aufbau des Systems – und zwar denjenigen Teil, den wir selber entwickeln; Standardprodukte oder Datenbanken gehören (höchstens untergeordnet) dazu. Die Bausteinsicht wird top-down beschrieben: In jedem Schritt werden (bei Bedarf) einzelne Komponenten verfeinert (Level 1, 2, …) dargestellt, werden also zu einer Whitebox. (Eine Blackbox wahrt das Geheimnisprinzip und wird lediglich durch ihre Schnittstellen und ihre Funktionalität beschrieben. Das Innenleben hingegen bleibt verborgen. Eine Whitebox ist eine Blackbox, deren Innenleben beschrieben wird. Sie kann ihrerseits auch wieder aus Blackboxes bestehen.)
Die Bausteinsicht adressiert alle in Entwurf, Implementation und Test involvierten Personen.
Laufzeitsicht
Im Gegensatz zur Bausteinsicht, die die statische Struktur des Systems beschreibt, beleuchtet die Laufzeitsicht die dynamischen Strukturen (Abläufe, Reihenfolgen etc.). In den meisten Fällen greife ich auf das Sequenzdiagramm zurück. Wenn Fallunterscheidungen wichtig sind, bietet sich das Aktivitätsdiagramm an.
Das Sequenzdiagramm verknüpft die Komponenten (aus der Bausteinsicht) mit einem zeitlichen Ablauf. Sie zeigt, welche Architekturbausteine benötigt werden, um einen Use-Case umsetzen zu können. Folgendes (einfaches) Beispiel zeigt den Ablauf, um in einem Webshop die Summe der Artikel im Einkaufswagen einer Person zu berechnen.
Es sei mir an dieser Stelle ein kurzer Exkurs erlaubt zu den Tools, mit denen Sichten erstellt werden können. Zu Enterprise Architect und Microsoft Visio habe ich immer noch keinen echten Zugang gefunden. Zugegeben: Ich habe mich bisher auch wenig bemüht, mich vertieft in diese Tools einzuarbeiten. Glücklicherweise gibt es PlantUML, mit dem sich die genannten Diagramme textuell beschreiben und anschliessend zeichnen lassen. Untenstehender Code resultiert in obigem Sequenzdiagramm.
Für Microsoft Visual Studio Code (momentan die IDE meiner Wahl) gibt es eine praktische Extension für PlantUML, die während der Eingabe «live» das Diagramm zeichnet. Very nice!
Verteilungssicht
Die Verteilungssicht ist unter anderem für den Betreiber des Systems relevant. Sie zeigt, welche Teile des Systems auf welcher Hardware zu liegen kommen, wie die Kommunikationskanäle aussehen und welche Protokolle eingesetzt werden.
Fazit
Ein gezielter Einsatz der genannten Sichten – Kontext-, Baustein-, Laufzeit- und Verteilungssicht – ist meines Erachtens „die halbe Miete“ für die erfolgreiche Kommunikation mit den diversen Stakeholderinnen und Stakeholdern. Jede Sicht sollte aber auch von einem gewissen Mass an „Prosa“ begleitet sein. Im Minimalfall kann eine Tabelle ausreichend sein, um die Elemente der Sicht näher zu beschreiben. Und: (intelligente) Faulheit ist erlaubt! Es muss nicht immer das gesamte System in allen Sichten abgebildet werden. Es reicht, wenn die kritischsten Teile explizit gemacht und in einer geeigneten Sicht dargestellt werden.
Im abschliessenden dritten Teil dieser Serie werde ich eingehen auf: Qualitätsanforderungen, Szenarien und die Bewertung von Softwarearchitekturen.