Stefan Zörner
08.09.2015
Teil 11 der Blog-Serie. Wir beschreiben wichtige Vorgänge innerhalb der Softwarearchitektur.
Im Schnipsel 4 dieser Blogserie hatte ich mit der Bausteinsicht eine Zutat vorgestellt, welche die Struktur des Systems zeigt. Dynamische Aspekte, also zum Beispiel wichtige Abläufe, blieben dort außen vor. Das holen wir jetzt mit der Laufzeitsicht nach …
Und so heißt es wieder: Schere raus und losgeschnippelt …
Alle Jahre wieder im Sommer vergibt eine Jury den Preis “Spiel des Jahres”. In drei Kategorien nominiert sie Brettspiele und prämiert das aus ihrer Sicht jeweils preiswürdigste.
Dieses Jahr ging der Hauptpreis an “Colt Express”. Bis zu sechs Spieler schlüpfen dabei in die Rolle von Banditen, und überfallen einen Zug im Wilden Westen.
Die Zutaten zum Spiel sind neben den Banditenfiguren und einem coolen 3D-Zug aus Pappe (Banditen können sich innerhalb des Zuges und auf dem Dach aufhalten) auch noch Beutestücke und reichlich Spielkarten -- vor allem Aktionskarten für die Spieler (Schießen, Laufen, Klauen ...).
Das Spielmaterial ist zunächst einmal statisch, interessanter ist, wie ein Spiel abläuft, also wie man es spielt. An dieser Stelle unterscheiden sich Spiele drastisch … Wer kann (oder muss) was in welcher Reihenfolge machen, wann ist das Spiel zu Ende, wer hat gewonnen?
Der Ablauf von Colt Express sieht grob so aus: Jedes Spiel besteht im Kern aus fünf Runden. Jede Runde besteht im Wesentlichen aus zwei unterschiedlichen Phasen …
Die Details zu den Abläufen können Sie in den Spielregeln nachlesen, die sowohl statische Aspekte (z.B. das Spielmaterial) als auch dynamische Aspekte (Runden, Phasen …) beinhalten.
Auch in der Softwarearchitektur gibt es verschiedene Aspekte zu beschreiben; in klassischen Vorgehensmodellen wie dem Rational Unified Process (oder noch allgemeiner: Architekturbeschreibungen nach IEEE 1417) ist dies die Domäne der Sichten. Die Idee dahinter: Alle Aspekte in einer Beschreibung zu vermischen, würde schnell überfrachten, zudem interessieren sich bestimmte Zielgruppen auch nur für einzelne Aspekte …
arc42 orientiert sich daran und schlägt konkrete Sichten vor; in Schnipsel #4 haben wir bereits die Bausteinsicht kennengelernt, die Kontextabgrenzung (Schnipsel #2) kann man ebenfalls als Sicht verstehen (Kontextsicht). Viele denken bei Sichten reflexartig an Diagramme im Allgemeinen und UML im Besonderen, und tatsächlich hatte ich in den beiden oben genannten Schnipseln Visualisierungen gezeigt.
In bestimmten Situationen lassen sich Informationen mit Graphiken besser ausdrücken als mit Text allein. Die Struktur der Software mit seinen Bestandteilen und Abhängigkeiten gehört ab einer gewissen Komplexität der Lösung sicher dazu – Die Bausteinsicht mit seiner hierarchischen Zerlegung in Ebenen ist genau dazu da.
Während die Bausteinsicht statische Aspekte darstellt, geht es bei der Laufzeitsicht um Dynamik.
Die Laufzeitsicht beschreibt interessante Aspekte des Systems, wenn es läuft. Bei der Dokumentation der Bausteinsicht zerlegen Sie das gesamte System und können bezüglich der Zerlegung auch eine gewisse Vollständigkeit anstreben (zumindest auf einem hohem Abstraktionsniveau, das manche Architektur nennen). Bei der Laufzeitsicht bleibt es hingegen Ihnen überlassen auszuwählen, welche Aspekte des Systems für die Zielgruppe(n) Ihrer Architekturdokumentation „interessant sind“. Hier einige typische Kategorien:
Ähnlich wie bei Zerlegungen des Systems mit Kästchen und Pfeilen sehen wir auch bei Ablaufbeschreibungen häufig Diagramme. Und tatsächlich hat die Visualisierung von Abläufen in Graphiken seinen Charme.
Die UML kennt Diagrammarten für jede Gelegenheit, grob eingeteilt in Struktur- und Verhaltensdiagramme. Die meiner Erfahrung nach für Abläufe in Architekturdokumentation gebräuchlichsten davon sind Sequenz- und Aktivitätsdiagramme. Neben der UML sind in der Architekturdokumentation nur wenige standardisierte Notationen gebräuchlich, am ehesten noch ArchiMate und die BPMN.
Ähnlich wie bei der statischen Sicht mit den berühmten Kästchen und Linien im Freestyle (“boxes and lines”) kommen stattdessen auch bei dynamischen Aspekten vielfach freie Notation zum Einsatz – am häufigsten vielleicht das Einmalen dynamischer Aspekte in statische Diagramme, z.B. mit durchnummerierten Pfeilen.
Bei der Laufzeitsicht muss es aber nicht immer Graphik sein. Einzelne Schritte können Sie auch in einer Bulletpoint-Liste aufzählen, einfache Abläufe in Pseudocode beschreiben. An die Grenzen stoßen Sie mit reinem Text, wenn die Abläufe zu kompliziert werden, was z.B. bei folgenden Aspekten passieren kann:
Nun aber zu unserem Serienstar Gradle, und einem wichtigen Ablauf dort. Und um zu unterstreichen, dass es nicht immer Graphik sein muss, skizziert in Text …
Ein Gradle-Build besteht aus drei Phasen:
Neben diesem Build-Zyklus böten sich weitere Abläufe in Gradle zur Darstellung in der Laufzeitsicht an, zum Beispiel
arc42 hält für die Laufzeitsicht einen eigenen Abschnitt bereit: den sechsten. Die Unterteilung in sogenannte Laufzeitszenerien zeigt, dass Sie hier sehr frei auswählen können, welche Abläufe Sie zeigen. Die Bausteinsicht in arc42 Abschnitt 5 ist mit seinen Ebenen weitaus mehr vorstrukturiert.
Generell empfehle ich den Einsatz von Grafiken in der Laufzeitsicht gegenüber Pseudocode oder Stichpunkten erst ab einer gewissen Komplexität (siehe oben).
Speziell die UML hat im Zusammenspiel mit der Bausteinsicht den Charme, dass die Elemente der Bausteinsicht als Beteiligte in der Laufzeitsicht Verwendung finden können. Etwa als Rollen in Sequenzdiagrammen oder als Partitionen in Aktivitätsdiagrammen. Das einheitliche Modell (das M in UML) darunter sichert dann bei geeignetem Tooling ab, dass die Umbenennung beispielsweise eines Bausteins in allen Sequenzdiagrammen konsistent nachgezogen wird.
Dieser Vorteil greift ab einem gewissen Umfang von Diagrammen. Für ein, zwei Abläufe im Rahmen eines Architekturüberblicks installiere ich keine UML-Werkzeuge. Ich greife zum Stift.
Den elften Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben, können Sie hier herunterladen. ;-)
Mit diesem Schnipsel ist der Starschnitt komplett. In der nächsten Folge fasse ich das Ganze noch mal zusammen und stelle vor allem ein paar wichtige Beziehungen zwischen den einzelnen Teilen dar.
Dieser Beitrag ist ursprünglich als Teil einer Blog-Serie beim Hanser-Verlag (“Hanser Update”) erschienen. Die Inhalte, ergänzt um reichhaltiges Bonus-Material, sind mittlerweile auch als E-Book bei Leanpub verfügbar.