arc42-Starschnitt: Gradle. Schnipsel Nr. 11: Laufzeitsicht

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 …

Einen Zug überfallen auf dem Wohnzimmertisch
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 …).

Colt Express, Spiel des Jahres 2015

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 …

• Spielvorbereitung (Aufbau, Zulosen der Banditenfiguren zu den Spielern)
• Fünf Runden
  • Rundenbeginn
  • Phase 1: Planung
    • Jeder Spieler hält sechs Aktionskarten auf der Hand
    • Reihum legen die Spieler Karten (teilweise verdeckt) auf einen Stapel, oder ziehen Karten nach
  • Phase 2: Action!
    • Die Aktionskarten vom gemeinsamen Stapel werden in genau der Reihenfolge auf dem Spielplan (dem 3D-Zug) ausgeführt, in der sie geplant wurden.
    • Ungewissen Ausgänge von Aktionen, Planungsfehler oder Überraschungen aufgrund der verdeckten Karten führen teilweise zu Slapstick-artigen Szenen
  • Rundenende
• Spielende (Ermittlung des Titels „Revolverheld“ und des Gesamtsiegers)

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.

Sichten auf Softwarearchitektur
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.

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:

• Verhalten des Systems beim Start bzw. beim Herunterfahren
• Konfiguration des Systems, z. B. bei Dependency Injection
• Interaktion von Systemteilen, z. B. Client und Server
• Walkthroughs für wichtige Use Cases oder User Stories
• Verhalten bei kritischen Situationen (z. B. Wegfall eines Teils zur Laufzeit)

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

Laufzeitsicht in Diagrammen
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:

• Zuordnung von Verantwortlichkeiten zu Schritten (Wer führt einen Schritt aus?)
• Parallelität, Nebenläufigkeit
• Austausch von Informationen zwischen Beteiligten (Stichwort Nachrichten)
• …

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 …

– – – 8< – – –

Schnipsel #11: Build-Phasen Gradle

Ein Gradle-Build besteht aus drei Phasen:

1. Initialisierung (Initialization)
   • Entscheiden, welche Projekte im Build teilnehmen (Single- vs- Multi-Project-Build)
   • Ausführen des Setting-Scriptes (Datei settings.gradle, bei Single-Project optional)
   • Erzeugen eines Project-Exemplares pro teilnehmendes Projekt
2. Konfiguration der Projekte (Configuration)
   • Konfiguration aller erzeugten Projektexemplare
   • Ausführen der Build-Skipte (build.gradle) aller beteiligten Projekte
3. Ausführung der Tasks (Execution)
   • Ermittlung der auszuführenden Tasks anhand Kommandozeile und aktuellem Verzeichnis
   • Ausführen dieser Tasks

Neben diesem Build-Zyklus böten sich weitere Abläufe in Gradle zur Darstellung in der Laufzeitsicht an, zum Beispiel

• Exemplarischer Build eines Java-Projektes mit typischen Tasks und Abhängigkeiten
• Lebenszyklus von Plugins und Tasks
• Zusammenspiel mit dem Gradle Daemon, etwa einer IDE mit dem Demon
• …

– – – >8 – – –

Wo kleben wir den Schnipsel hin?
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.

Wo würde die UML ihre Stärken ausspielen?
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.

Zum Weiterlesen

• Die Laufzeitsicht ist auch ein Dokumentationsmittel in meinem Buch „Softwarearchitekturen dokumentieren und kommunizieren“. Dort zeige ich u.a. auch das Zusammenspiel mit der Bausteinsicht in UML-Modellen. Eines der Fallbeispiele des Buches, eine Schach-Engine, ist online verfügbar und besitzt ebenfalls eine Laufzeitsicht: Laufzeitsicht DokChess
• Wer mehr über das Spiel Colt Express erfahren will, liest auf Board Game Geek nach oder/und schaut diesen netten YouTube-Film des Verlages Ludonaute.

Ausblick

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.

Sie haben einen Schnipsel des arc42-Starschnitts zu Gradle verpasst? Hier finden Sie alle bisherigen Folgen.

Der Beitrag arc42-Starschnitt: Gradle. Schnipsel Nr. 11: Laufzeitsicht erschien zuerst auf Hanser Update.