In diesem Beitrag zeige ich Zusammenhänge zwischen den Schnipseln des Starschnitts auf und füge einzelne zu einem kleinen Architekturüberblick von Gradle zusammen. Während zuvor also jeweils eine Zutat im Vordergrund stand, ist es nun das (nicht ganz so) große Ganze. Und wir biegen in die Zielgerade ein …

Teaser Bild Folge 12

In der letzten Folge der Serie hatte ich bereits Brettspiele als Beispiel für Dynamik und Abläufe herangezogen, wie sie die Laufzeitsicht für Softwaresysteme beschreibt. Derartige Spiele erfreuen sich in Deutschland großer Beliebtheit, nirgendwo erscheinen so viele pro Einwohner wie hierzulande. Der international gängige Begriff „German-style board game“ illustriert das Phänomen – prominente Vertreter wie „Die Siedler von Catan“ oder „Carcassonne“ sind über die Brettspielkennerszene hinaus bekannt.

Aus Essener Feder

Die Szene trifft sich konsequenterweise alljährlich in Deutschland, genauer in Essen, zur größten Brettspielmesse der Welt – der „Spiel“. Dort wird neben anderen Preisen auch die Goldene Feder der Stadt Essen vergeben – für das Autorenspiel mit der besten Spielregel (!).

Colt-Express-Spielregel_Seite_3

Quelle: Colt Express-Spielregel, Seite 3.

Ist Ihnen schon einmal aufgefallen, dass Spielregeln grundsätzlich den gleichen Aufbau haben? Zur Illustration sehen Sie rechts eine Seite aus der Anleitung von Colt Express. Verallgemeinert sieht es in der Regel so aus:

  1. Kurze atmosphärische Einführung (optional, entfällt bei abstrakten Spielen)
  2. Ziel des Spieles
  3. Spielmaterial
  4. Spielvorbereitung (Aufbau)
  5. Spielablauf (Phasen, Züge, Aktionen)
  6. Spielende (End- und Siegbedingungen)
  7. Varianten (optional, z. B. für abweichende Spielerzahl, Expertenversion, Solospiel)

Colt Express folgt diesem Muster ganz gut, inklusive Sonderregeln für zwei Spieler.

Vorteile einer festen Gliederung

Die Vorteile eines festen Aufbaues und gleicher Elemente innerhalb der Spielregeln liegen auf der Hand:

  • Leser finden sich schneller zurecht. Spieler etwa, die gezielt etwas suchen, finden die gewünschte Information sehr schnell (Wie viel XY bekommt jeder am Anfang? Wann ist das Spiel zu Ende? Wer hat gewonnen?)
  • Unterstützung bei der Kommunikation. Jemand, der das Spiel erklären möchte, kann sich an der Anleitung orientieren und auch auf Beispiele aus der Anleitung zurückgreifen.
  • Autoren erhalten Sicherheit. Jemand, der eine Spielanleitung anfertigen möchte, kann sich an dem grundsätzlichen Aufbau orientieren. Er braucht sich nichts selber ausdenken, die Struktur ist erprobt.

Und ebenso wirken diese Vorteile auch bei der Gliederung von Architekturbeschreibungen. Nicht umsonst zählt „Verwende eine Standardstrukturierung“ zu den sieben Regeln für gute Dokumentation. arc42 ist im deutschsprachigen Raum so etwas wie ein Defacto-Standard für derartige Strukturierungen (siehe hierzu auch „Ist dieses arc42 eigentlich alternativlos?“).

Zuordnung der Schnipsel zur arc42

Im Rahmen dieser Serie habe ich insgesamt 11 Zutaten einer Architekturdokumentation in Form von Schnipseln erklärt und anhand von Gradle illustriert. Die folgende Abbildung zeigt noch einmal, wo Sie die Schnipsel in einer Dokumentation gegliedert nach arc42 „abheften“ würden.

Abheften_Folge_12

Schnipsel dieser Serie in arc42 „abheften“

Sicher fällt Ihnen auf, dass ich die Schnipsel nicht in der Reihenfolge besprochen habe, in der sie in der Gliederung stehen. Das passt dazu, dass das „Ausfüllen“ von arc42 Abschnitt um Abschnitt ohnehin kein Erfolgsrezept ist. In der Praxis entstehen die einzelnen Zutaten anlass- und/oder risikogetrieben, werden im weiteren Projektverlauf verfeinert und ggf. auch massiv verändert. Erste Qualitätsszenarien fertige ich beispielsweise früh an, um die Qualitätsziele besser einschätzen zu können.

Methodischer Zusammenhang

Um Ihnen Orientierung zu geben, wie sich die einzelnen Zutaten beeinflussen, illustriert das folgende graphische Glossar mit seinen Pfeilen wichtige methodische Zusammenhänge zwischen den Schnipseln. Das gibt Ihnen eine grobe Bearbeitungsreihenfolge und zeigt auch auf, wo sie auf Konsistenz und den roten Faden achten müssen. In einem guten Architekturüberblick beispielsweise sollten die Schnipsel kein Schüttgut sein, sondern eine Geschichte erzählen.

SchnipselGlossar_680x445

Wenn Sie eine Architekturdokumentation für ein bestehendes System „aus dem Nichts“ anfertigen wollen, empfehle ich mit dem Systemkontext und dem Produktkarton zu beginnen. Der Systemkontext ist vor allem wichtig um zu klären, was eigentlich dazu gehört und was nicht.

Einen Architekturüberblick anfertigen

Der Schlüssel, um einen wirkungsvollen Architekturüberblick anzufertigen, liegt darin die Zielgruppe klar herauszuarbeiten, und im Anschluss passend erste Zutaten auszuwählen und anzufertigen. Danach bringen sie diese in Form und holen sich Feedback von der Zielgruppe. In weiteren Iterationen arbeiten Sie die Rückmeldungen ein, nehmen bei Bedarf weitere Zutaten hinzu oder verfeinern bestehende.

Je nach Zielgruppe und Kommunikationsweg sind für einen Architekturüberblick sehr unterschiedliche Formen denkbar. Häufige Beispiele:

  • Prägnantes Dokument: Strukturierter Text, angereichert mit Illustrationen, Umfang maximal 20 Seiten
  • Foliensatz: 10-15 Folien zur Unterstützung einer Präsentation der Architektur
  • Architekturportal im Wiki: Einstiegsseite(n) im Wiki, die Interessierte durch die Inhalte führen
  • Architekturflyer oder -poster: Kleines Handout, z.B. DIN A4 beidseitig bedruckt, 2-3x gefaltet, oder größer produziert (z.B. DIN A1) als Plakat zur weiten Verbreitung

architektur-spicker01-coverGerade der Flyer ist eine spannende Form — durch die Beschränkung auf wenige Seiten (z.B. 4 Seiten DIN A4) bleibt es in der Regel tatsächlich bei einem Überblick. Wir bei embarc haben diese Form auch gewählt, um methodischen Wissen auf den Punkt zu bringen. Der erste dieser „Architekturspicker“ hat passender Weise das Anfertigen eines Architekturüberblicks zum Thema (Abbildung siehe rechts). Sie finden ihn hier zum Download (4 Seiten DIN A4).

Beispielstruktur für einen Folienvortrag

Für die häufig genutzte Form einer Folienpräsentation für einen Architekturüberblick enthält die folgende Tabelle einen Vorschlag zur Gliederung. Er ist grob nach dem 4-Quadranten-Modell gegliedert, das Sie im Schnipsel #9: Übergreifende Konzepte kennengelernt haben.

Abschnitt Mögliche Inhalte Passende Folgen der Serie
I. Aufgabenstellung Mission Statement
Architekturziele
Kontextabgrenzung
Herausforderungen, Schmerzpunkte
Zentrale Randbedingungen
#1: Produktkarton
#3: Qualitätsziele
#2: Systemkontext
#8: Randbedingungen
II. „The Big Picture“ Lösungsstrategie (Tabelle)
Informelles Überblicksbild
Architekturprinzipien
#10: Lösungsstrategie
III. Die Lösung im Detail Architekturentscheidungen
Diagramme (Struktur, Verteilung, …)
Übergreifende Konzepte
Demo, Walkthrough
#5: Architekturentscheidungen
#4: Bausteinsicht
#9: Übergreifende Konzepte
#11: Laufzeitsicht
IV. Fazit und Ausblick Offene Punkte
Nächste Schritte
Diskussion
Weitere Informationen
Was sind Ihre Fragen?

Ich habe einige Inhalte aus den vergangenen Beitragen zu Gradle zu einem entsprechenden Folienvortrag kombiniert. Sie finden Ihn hier:

Architekturüberblick Gradle, Beispielfoliensatz

Zum Weiterlesen

  • Den Architektur-Spicker #1 „Der Architekturüberblick“ können Sie hier als PDF herunterladen.
  • Das graphische Glossar (auch Concept-Map) zu den Schnipseln und ihren methodischen Zusammenhängen habe ich mit dem freien Tool Cmap angefertigt.
  • Die Werkzeugfrage hat in dieser Reihe ganz bewusst keine große Rolle gespielt. Häufig genannte Stärken und Schwächen typischer Tools zur Architekturdokumentation habe ich in diesem Blog-Beitrag zusammengetragen: „Top-Tools für Architekturdokumentation: Je fünf Stärken und Schwächen“

Und Schluss.

Meine arc42-Starschnitt-Serie bei Hanser Update geht mit diesem Beitrag zu Ende. Ich hoffe, Sie können die ein oder andere Anregung für Ihre tägliche Arbeit daraus mitnehmen. An dieser Stellen möchte ich mich noch einmal für die vielen Rückmeldungen bedanken, die ich zu dieser Serie erhalten habe. Sie sind weiterhin willkommen!

Per E-Mail erreichen Sie mich unter stefan.zoerner[ät]embarc.de. Wenn Sie bezüglich Softwarearchitektur im Allgemeinen und methodischen Dingen im Besonderen auf dem Laufenden bleiben wollen: auf Twitter folgen Sie mir unter @StefanZoerner.