Category

Kolumne

Beitragsbild_admin-ajax

arc42-Starschnitt: Gradle. Die Schnipsel zusammensetzen

By | Inhaltliches, Kolumne

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 …

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.

Schnipsel dieser Serie in arc42 "abheften"
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.

Schnipsel Glossar

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-cover

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

AbschnittMögliche InhaltePassende Folgen der Serie
I. AufgabenstellungMission 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 DetailArchitekturentscheidungen
Diagramme (Struktur, Verteilung, …)
Übergreifende Konzepte
Demo, Walkthrough
#5: Architekturentscheidungen
#4: Bausteinsicht
#9: Übergreifende Konzepte
#11: Laufzeitsicht
IV. Fazit und AusblickOffene 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!

Leanpub: arc42-Starschnitt Gradle Ein Architekturüberblick in Lebensgröße.

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.

Zum arc42-Starschnitt

Beitragsbild_admin

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

By | Inhaltliches, Kolumne

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.

Colt Express, Spiel des Jahres 2015
Colt Express, Spiel des Jahres 2015

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 …

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

Schnipsel #11 abheften in arc42

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

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.

Leanpub: arc42-Starschnitt Gradle Ein Architekturüberblick in Lebensgröße.

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.

Zum arc42-Starschnitt

Beitragsbild_admin

arc42-Starschnitt: Gradle. Schnipsel Nr. 10: Lösungsstrategie

By | Inhaltliches, Kolumne

In dieser Blogserie habe ich bereits einige Schnipsel zum Festhalten architekturrelevanter Anforderungen auf der einen und Lösungsansätze auf der anderen Seite diskutiert. In dieser Folge lernen Sie nun ein wirkungsvolles Werkzeug kennen, das die Brücke schlägt.

Und so heißt es wieder: Schere raus und losgeschnippelt…

Ihre Architektur auf einem Bierdeckel?

Die unliebsame jährliche Einkommenssteuererklärung manifestiert sich in einem grau-grünen Papierungetüm, das Ausfüllen von Mantelbogen ESt 1 A, V oder C sowie diverser Anlagen wie N, KSO  oder AVEÜR (= Anlageverzeichnis/Ausweis des Umlaufvermögens zur Anlage EÜR) lässt in Deutschland so manchen verzweifeln.

Steuererklärung

Der CDU-Politiker Friedrich Merz machte 2003 mit einem radikalen Konzept zur Steuerreform auf sich aufmerksam: Die Steuererklärung sollte demnach auf einen Bierdeckel passen! Ein verlockendes Bild, leider nicht von Erfolg gekrönt.

Können wir eine Softwarearchitektur auf einem Bierdeckel erklären? Als Idealbild ist für viele bereits ein Architekturüberblick ihres Softwaresystems auf weniger als 30 Seiten anstrebsam, und in der Regel auch inklusive Abbildungen, Inhaltsverzeichnis, Glossar usw. gut machbar.

Die Lösungsstrategie für ein Softwaresystem lässt sich jedoch noch weiter verdichten, sodass sie auf eine DIN A4-Seite passt. Oder auf ein bis zwei PowerPoint-Folien.

Eine Strategie (von griechisch strategós „Feldherr, Kommandant“) ist ein Plan zum systematischen Erreichen von Zielen …

Wikipedia

Ihre Lösungsstrategie stark verdichtet

Eine besonders kompakte und wirkungsvolle Form zur Dokumentation und Kommunikation der Lösungsstrategie stellt die wichtigsten Anforderungen den Lösungsansätzen in einer Tabelle gegenüber, siehe folgende Abbildung:

Lösungsstrategie

Die linke Spalte enthält dabei die Qualitätsziele (oder auch Architekturziele, vgl. Schnipsel #3 dieser Serie). Für ein ausdrucksstarkes Ergebnis zahlt es sich hier aus, wenn Sie den Zielen prägnante Namen gegeben haben (z.B. „Intuitive Erlernbarkeit“ statt nur „Benutzbarkeit“). In der rechten Spalte ordnen Sie den Zielen die wichtigsten Lösungsansätze Ihrer Architektur zu, die aus Ihrer Sicht der Erreichung der Ziele dienen. Als erstes sind hier die Architekturentscheidungen zu nennen.

Die folgende Tabelle listet mögliche Kategorien für Lösungsansätze für die rechte Spalte der Strategie auf und illustriert sie jeweils mit einem Beispiel. Die einzelnen Ansätze nennen Sie in Ihrer Tabelle nur schlagwortartig, beispielsweise „JPA/Hibernate als Persistenzframework“. Auf detaillierte Informationen (z.B. die ausführliche Darstellung einer Architekturentscheidung inklusive betrachteter Alternativen, das ausgearbeitete Konzept etc.) verweisen Sie lediglich.

Kategorie Beispiel (und dazu passendes Qualitätsziel)
—— ——
Entscheidungen Verwendung eines Application Server Clusters (hohe Ausfallsicherheit)
 
(Architektur-)stile Micro Services (schnelle Adaption neuer technologischer Trends)
 
(Architektur-)muster Schichtenarchitektur (leichte Austauschbarkeit des Clients, oder einfache Portierung der Lösung)
 
(Architektur-)prinzipien Bevorzuge Standards vor proprietären Lösungen (niedrige Wartungsaufwände)
 
Konzepte Caching-Konzept (Effizienz, gute Antwortzeiten)
 
Vorgehen User centered design (intuitive Benutzbarkeit)
 

Ansätze, wie in der Tabelle oben, wählen Sie und Ihr Team typischerweise selbst aus – Sie entscheiden. In Einzelfällen können Sie aber auch Randbedingungen als „Argumente“ für Ihre Architektur anführen. Wenn beispielsweise Technologien vorgegeben sind, die gleichzeitig gut zu den Zielen passen, können Sie diese in der rechten Seite ebenfalls nennen. Ein einzelner Lösungsansatz kann mitunter mehreren Zielen dienlich sein. Sie listen ihn dann einfach mehrmals in der rechten Spalte auf.

Um Interessierten einen Einstieg in Ihre bereits entstandene Dokumentation zu geben, können Sie die Lösungsstrategie als eine Art Zusammenschau nachdokumentieren. Besser noch beginnen Sie aber früh mit einer ersten Fassung, um Sicherheit im Architekturentwurf zu gewinnen und der Verwässerung wichtiger Architekturansätze entgegenzuwirken.

Zeit für ein richtiges Beispiel! Unser Serienstar Gradle ist endlich wieder an der Reihe …

– – – 8< – – –

Schnipsel #10: Lösungsstrategie Gradle

Die folgende Tabelle stellt den Qualitätszielen von Gradle aus Schnipsel #3 (links) passende Lösungsansätze (rechts) gegenüber. Genannt werden dabei zentrale Entscheidungen (z.B. Groovy für Build-Skripte, siehe Beispiel in Schnipsel #5), Konzepte (z.B. das Plugin-Konzept), Prinzipien (z.B. „build-by-convention“) und Ideen (z.B. Groovy Wrapper, Groovy Daemon).

Qualitätszielpassende Lösungsansätze in Gradle
Erweiterbarkeit——–
(Gradle lässt sich leicht um neue Funktionalität erweitern. Es kann auf lange Sicht dem technologischen Fortschritt bei Tools und Entwicklungsmethodik folgen)
  • Build-Files sind Groovy-Skripte, kleine Erweiterungen auch ohne aufwändige Programmierung möglich
  • Ausgereiftes Plugin-Konzept, Custom Plugins können in Groovy, Java, Scala … entwickelt werden
  • Exzellent dokumentierte Gradle API und erweiterbare DSL
Effizienz——–
(Teams und einzelne Entwickler erhalten durch kurze Buildzeiten schnelle Rückmeldungen; Gradle steigert so ihre Produktivität)
  • Unterstützung inkrementeller Builds
  • Dependency-Cache zur Reduktion der Download-Zeiten
  • Betrieb im Hintergrund für kürzere Start- und Ausführungszeiten möglich (Gradle Daemon)
Interoperabilität——–
(Gradle arbeitet mit bestehenden Werkzeugen wie Ant und Maven und deren Öko-Systemen nahtlos zusammen)
  • Direkte Verwendung von Ant-Tasks und Ant-Projekten in Gradle möglich
  • Konverter für Maven pom.xml nach Gradle Build-Skript verfügbar
  • Unterstützung von Maven-Repositories (Download von Abhängigkeiten, Veröffentlichen von Artefakten)
  • Gradle API erlaubt Einbetten von Gradle, zum Beispiel in IDEs
Erlernbarkeit——–
(Entwickler und Buildmanager finden sich schnell in Gradle zurecht, der Einstieg und das Erstellen erster Build-Skripte fallen ihnen leicht)
  • Verwendung der Sprache Groovy für Build-Skripte (siehe: „Why Groovy?“)
  • Deklarative Builds mit Groovy DSL und „build-by-convention“
  • Zielgruppengerechte Dokumentation (Tutorials, User-Guide)
Installierbarkeit——–
(Der Aufwand, der zum Installieren von Gradle notwendig ist, um einen Build auszuführen ist, sehr gering)
  • Java ist die einzige Systemvoraussetzung
  • Wrapper lädt Gradle automatisch herunter — Builds sind so ohne weitere Installation möglich
Skalierbarkeit——–
(Gradle bleibt auch bei sehr umfangreichen Builds und in Multi-Projekt-Szenarien handhabbar und effizient)
  • Umfassende Unterstützung für Multi-Project Builds
  • darüber hinaus: Ansätze für Effizienz (siehe oben)
 ——–

– – – >8 – – –

Die Lösungsstrategie oben ist etwas umfangreicher. Auf ein DIN A4-Blatt passt sie noch, Bierdeckel wird knapp. Das hat mehrere Gründe. Zum einen enthielt das Gradle-Beispiel in Schnipsel #3 sechs Qualitätsziele, und ich wollte hier keines unterschlagen. In einem Architekturüberblick beschränken Sie sich zum Beispiel auf die Top-3. Zum andern habe ich in der Tabelle oben die Ziele vollständig (d.h. jeweils mit Erklärung in Klammern) wiedergegeben. So sind sie auch ohne „Hin- und herblättern“ im Blog gut verständlich.

Wo kleben wir den Schnipsel hin?

arc42 hält für die Lösungsstrategie einen eigenen Abschnitt bereit: den vierten …

Schnipsel #10 abheften in arc42

In den arc42-Abschnitten davor (1-3) sind architekturrelevante Anforderungen (z.B. Randbedingungen und Qualitätsziele) versammelt, danach Lösungsdetails wie Bausteinsicht, Konzepte, Entscheidungen. Die Lösungsstrategie schlägt in dieser Anordnung die Brücke, sie führt in die Lösung ein.

Eine Architekturbewertung auf dem Bierdeckel

Das gezeigte Werkzeug der Lösungsstrategie ist nicht nur exzellent geeignet, um die grundlegenden Aspekte Ihrer Architektur zu zeigen und dabei gleichzeitig zu motivieren. Es hilft auch während des Entwurfs der Architektur dabei, Lücken und Ungereimtheiten aufzudecken. Wenn Sie zu einem Architekturziel keine passenden Lösungsansätze in der Architektur identifizieren, ist da noch etwas zu tun. Und wenn Sie umgekehrt einen zentralen Aspekt der Architektur keinem Ziel zuordnen können, sollten Sie ihn hinterfragen. Im Grunde stellt die Tabelle eine besonders schlanke Form der Architekturbewertung dar. Passt die Lösung zur Zielsetzung?

Ausblick

Den zehnten Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben, können Sie hier herunterladen. 😉

Mit der nächsten Folge — Schnipsel #11 von 11 — endet dann der arc42-Starschnitt in diesem Blog. Mit der Laufzeitsicht lernen Sie zum Abschluss eine Möglichkeit kennen, der statischen Bausteinsicht ein wenig Leben einzuhauchen …

Leanpub: arc42-Starschnitt Gradle Ein Architekturüberblick in Lebensgröße.

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.

Zum arc42-Starschnitt

Beitragsbild_admin

arc42-Starschnitt: Gradle. Schnipsel Nr. 9: Übergreifende Konzepte

By | Inhaltliches, Kolumne

Beim Zerlegen einer Softwarelösung in Subsysteme, Module o.ä. reduzieren Sie Komplexität — Modularisieren ist „Teilen und Herrschen“, der aktuelle Microservices-Trend seine neueste Facette. Gleichwohl gibt es Aspekte, die Sie nicht in jedem Teil individuell entscheiden und lösen wollen. Solche übergreifenden Themen dokumentieren Sie in sogenannten „Konzepten“. Um solche geht es in dieser Folge der Starschnitt-Serie. Und so heißt es wieder: Schere raus und losgeschnippelt…

And the Oscar goes to …

Alle Jahre wieder werden in Los Angeles die Oscars für besondere Leistungen im Film vergeben. Die beste Regie, das beste Drehbuch, die beste Filmmusik … insgesamt über 30 Kategorien.

Auch für Softwarelösungen könnte man Preise vergeben. Das beste UI. Die beste Performance … Etwas eingegrenzt passiert das sogar. Bei Spielen zum Beispiel. Vielleicht erinnert sich der ein oder andere Leser noch an seine C=64-Vergangenheit und Spieletests in den einschlägigen Zeitschriften (Stichwort Happy Computer). Kategorien dort etwa Graphic, Sound,  …

Abbildung: Rating für ein Computerspiel (Kategorien angelehnt an IGN)
Abbildung: Rating für ein Computerspiel (Kategorien angelehnt an IGN)

Computerspiele und auch einzelne Aspekte dazu lassen sich also bewerten — zumindest wird es gemacht (siehe z.B. IGN). Können wir auch Bewertungen für die beste Softwarearchitektur abgeben? Was ist überhaupt gute Softwarearchitektur?

Preisgekrönte Softwarearchitektur?

Klassische Architekturbewertung wie zum Beispiel ATAM vergibt keine Preise. Nicht einmal Noten (siehe zum Beispiel dieser Artikel). Bei Architekturbewertung geht es darum, die zentralen Lösungsansätze (z.B. Technologieentscheidungen) für ein Softwaresystem gegen die Aufgabenstellung zu halten, um Risiken zu identifizieren und Kompromisse herauszuarbeiten.

In dieser Serie haben wir schon einige Schnipsel kennengelernt, die dazu dienen architekturrelevante Anforderungen  festzuhalten und im Team und gegenüber den Stakeholdern zu kommunizieren.

Und auch schon einige, die der Lösung verpflichtet sind:

(Spoiler-Alarm: Mit dieser Folge kommt ein wichtiger Aspekt dazu)

Bei einer guten (besser vielleicht: adäquaten) Softwarelösung passen Struktur und Zerlegung, Technologieentscheidungen, … zu den Anforderungen. Sie hält die Randbedingungen (z.B. Zeitplan, Budget, geforderte Standards) ein, erreicht die Qualitätsziele, birgt wenige Risiken.

Unterm Strich also nicht einfach, Oscars für die beste Architektur, das beste Design, die beste Umsetzung, … zu vergeben. Oder die beste Wartbarkeit, Sicherheit, Benutzbarkeit … Zumal diese Dinge ja ggf. gar nicht gefragt waren. So gesehen hat auch der Kinobesucher in der Regel wenig von einem Film mit dem Oskar für das beste Make-up/die beste Frisur. Der preisgekrönte Film in dieser Kategorie war 1992 übrigens „Terminator 2 – Tag der Abrechnung“ — blöd, wenn man auf coole Frisuren aber nicht auf Action steht.

Der Oscar für die am wenigsten verkorkste Software?

Eine der wenigen Eigenschaften von Softwarearchitektur, die ich als allgemein preiswürdig erachte, ist konzeptionelle Integrität. Hinter diesen gleich zwei Fremdwörtern verbirgt sich die schlichte Tatsache, dass gleiche Probleme innerhalb des Systems stets gleich gelöst sind. Abweichungen hiervon führen zu schwer verständlichen und auch schwer zu erklärenden Lösungen. Bei der Einarbeitung neuer Kollegen fallen dann Sätze wie:

  • „Das ist so ähnlich wie im XY-Subsystem, das wir uns eben angeguckt haben, nur dass hier …“
  • „Ach ja, früher hatten wir das noch so gemacht, da gibt es noch einige Stellen von im Code …“
  • „Die Komponente hat Peter gemacht, der mochte es lieber …“

Dabei sind sehr wohl Ausnahmen zulässig, nur sollte es da gute Gründe für geben:

  • „Normalerweise greifen wir mit JPA auf die Datenbank zu. In wenigen Fällen nutzen wir aus Performancegründen natives SQL …“

Diese Tatsache gehört kommuniziert, damit ein neuer Kollege der im Quelltext darüber stolpert, nicht falsche Schlüsse zieht („Komisch, mal nehmen sie JPA, mal direkt JDBC, kann ich mir also aussuchen. Vielleicht auch was ganz anderes nehmen …“).

Wenn Sie derartige Dinge nicht reparieren, schleppen Sie technische Schulden mit. Im Extremfall verwischt mit der Zeit die Softwarearchitektur, die konzeptionelle Integrität geht verloren (oder ohne Fremdwörter: Am Ende ist alles verkackt).

Im Rahmen Ihrer Entwicklung erarbeitete Lösungen für übergreifende Themen müssen Sie im Team teilen, damit die Ansätze und Prinzipien durchgängig eingehalten werden. Sie müssen sie insbesondere auch an neue im Team kommunizieren. Ein bewährtes Werkzeug, um die entsprechende Themen zu bearbeiten und die Lösungsansätze festzuhalten sind Konzepte.

Konzepte

„Ein Konzept ist ein grober Plan, welcher die Maßnahmen zur Erreichung eines Ziels auflistet oder beschreibt, sowohl skizzenhaft im Entwurf, als auch verbindlich in der Auswahl der Mittel.“

Wikipedia

Für welche Themen Sie Konzepte anfertigen hängt von Ihrem Projekt (und dessen Zielen) ab. Die folgende Tagcloud gibt eine erste Idee vom Themenspektrum.

Übergreifende Themen

Häufig zieht eine Technologieentscheidung ein Konzept nach sich. Sie wählen in einer Entscheidung eine Technologie unter verschiedenen Alternativen aus (z.B. eine Persistenztechnologie), und beschreiben anschließend in einem Konzept, wie sie diese Technologie einsetzen (z.B. in einem Persistenzkonzept).

– – – 8< – – –

Schnipsel #9: Übergreifende Konzepte von Gradle

Die folgende Liste nennt mögliche Themen für Konzepte in Gradle

  • Aufbau eines Build-Skriptes
  • Build-Lebenszyklus
  • Abhängigkeitsmanagement
  • Gradle Wrapper
  • Gradle Daemon
  • IDE Integration
  • Logging
  • Umgang mit Repositories
  • Plugin-Konzept („Wie wird Gradle um Funktionalität erweitert?“)
  • Migration von Magen oder Ant auf Gradle

Die Themen haben gemeinsam, dass sie zentrale Lösungsansätze beschreiben, und oder an vielen Stellen von Gradle wirken.

Zu vielen dieser Themen finden sich in der Gradle-Dokumentation entsprechende Informationen, etwa im Gradle User Guide. Für das Abhängigkeitsmanagement beispielsweise liegen gleich zwei Kapitel unterschiedlicher Flughöhe vor (8. Dependency Management Basics, 51. Dependency Management). Sie erklären die grundlegenden Konzepte und Lösungsansätze, aber keine Implementierungsdetails. Letztere sind für die Zielgruppe eines User Guides aber auch von untergeordnetem Interesse.

Die Gliederungen der beiden Kapitel im User Guide zu Dependency Management sehen beispielsweise  so aus:

8. Dependency Management Basics
8.1. What is dependency management?
8.2. Declaring your dependencies
8.3. Dependency configurations
8.4. External dependencies
8.5. Repositories
8.6. Publishing artifacts
8.7. Where to next?
 51. Dependency Management
51.1. Introduction
51.2. Dependency Management Best Practices
51.3. Dependency configurations
51.4. How to declare your dependencies
51.5. Working with dependencies
51.6. Repositories
51.7. How dependency resolution works
51.8. Fine-tuning the dependency resolution process
51.9. The dependency cache
51.10. Strategies for transitive dependency Management

– – – >8 – – –

Schreibblockade. Wie genau schreibt man ein Konzept?

Nicht jeder Entwickler beherrscht das Verfassen guter technischer Konzepte. Wobei „gut“ hier vor allem zielgruppengerecht heißt. Die primäre Zielgruppe technischer Konzepte sind oftmals andere Entwickler im Team, welche die Lösung nachvollziehen und umsetzen wollen/sollen. Aber es gibt auch andere potentielle Leser.

Eine Struktur, die sich zum Gliedern von Inhalten aller Art in Vorträgen, Artikeln etc. bewährt hat, und die insbesondere unterschiedliche Zielgruppen adressiert, ist das Vier-Quadrantenmodell (alternativ: 4-Mat-System). Die folgende Abbildung zeigt die Struktur angelehnt an ein Buch von Uwe Vigenschow et al (weitere Lesehinweise für Was-Menschen am Ende des Beitrags).

Das Vier-Quadrantenmodell (Darstellung nach Vigenschow et al)
Das Vier-Quadrantenmodell (Darstellung nach Vigenschow et al)

Die Struktur lässt sich auch auf technische Konzepte prima anwenden. Inhalte ordnen Sie den vier Quadranten zu und bringen Sie dann entsprechend in Reihenfolge. So sollte beispielsweise eine Motivation stets am Anfang stehen (und niemals fehlen). Leser aus einer zentralen Zielgruppe für die meisten Konzepte, nämlich Entwickler, schätzen Kürze und freuen sich insbesondere über Inhalte im „Wie“-Quadraten:

  • Schritt-für-Schritt-Anleitungen
  • Tipps und Tricks aus der Praxis
  • Beispiele zum Abgucken

Beim „Was“ ergänzen in übergreifenden Konzepten oft gute Quellen zum Nachlesen die eigenen Inhalte. Gerade beim Einsatz gängiger Technologien passen Verweise auf gute Literatur. Tutorials im Internet oder auch Videos und Podcasts zum Thema sind eine weitere schöne Ergänzung. Damit lässt sich das Konzept selbst kürzer halten, ganz im Interesse der Entwickler.

Das Thema Abhängigkeitsmanagement aus dem Gradle-Beispiel wurde mit zwei Konzepten (Kapiteln) dokumentiert. Wenn wir diese zusammenführen wollten und dabei die Gliederungsstruktur des Vier-Quadrantenmodells einhalten finden sich schnell Unterkapitel in der bestehenden Dokumentation, die zu den Quadranten mit ihren jeweiligen W-Fragen passen. Hier einige Beispiele (Kapitelnummer aus dem User Guide in Klammern):

Warum? Introduction (51.1)
What is dependency management? (8.1)
 
Was? Dependency configurations (8.3)
How dependency resolution works (51.7)
 
Wie? How to declare your dependencies (51.4)
Dependency Management Best Practices (51.2)
 
Wohin noch? Strategies for transitive dependency Management (51.10)
Where to next? (8.7)

Technische Konzepte entstehen oftmals im Kontext eines Projektes als Antwort auf die Frage: „Wie gehen wir mit XY um?“ (XY z.B.: Persistenz, Security, …). In vielen Fällen lassen sie sich aber auch außerhalb des Projektes weiter verwenden, bewährte Konzepte sind für ähnlich gelagerte Problemstellungen interessant.

Softwarelösungen innerhalb einer Unternehmens etwa haben häufig ähnliche Randbedingen. Es besteht daher berechtigte Hoffnung, dass ein Lösungsansatz eines Projektes grundsätzlich auch auf andere Systeme im Unternehmen passt. Um das aber bewerten zu können muss Ihr Konzept nachvollziehbar sein (Stichwort „Hintergründe erläutern“ im „Was?“-Quadrant).

Fertigen Sie ein Konzept also als eigenständigen Schnipsel an, und nicht nur als Unterkapitel innerhalb eines umfangreichen Architekturbeschreibungsdokumentes (eh kein guter Plan).

Wo kleben wir den Schnipsel hin?

arc42 hält für übergreifende Konzepte einen eigenen Abschnitt bereit:

"Abheften" in arc42

Das betreffende Kapitel im arc42-Template enthält eine umfangreiche Themensammlung. Lassen Sie sich von den insgesamt 23 Unterkapiteln (Persistenz, Benutzeroberfläche, …) nicht abschrecken. Sie müssen diese nicht sklavisch abarbeiten; die Themensammlung dient zu Ihrer Inspiration und erhebt nicht einmal einen Anspruch auf Vollständigkeit. Ganz ähnlich wie die Tagcloud oben in diesem Beitrag. Wählen Sie gezielt aus!

Und was ist mit dem Preis?

Übergreifende Konzepte sind ein Mittel zum Zweck. Der Zweck: Für Themenfelder, wo es für Sie und Ihr Team (oder sogar Ihre Teams) wichtig ist, einheitliche Lösungen zu diskutieren und zu etablieren.

Und der Preis für konzeptionelle Integrität geht dieses Jahr  an … Ihr Team für Ihr Softwaresystem?

Zum Weiterlesen

Ausblick

Den neunten Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben, können Sie hier herunterladen. 😉

In der nächsten Folge geht es übrigens um die Lösungsstrategie, also Abschnitt 4 in arc42. In der dann gezeigten Form setzt sie Architekturziele und Lösungsansätze in Beziehung. Ich persönlich halte es für eines der nützlichsten Werkzeuge, um die Architekturidee zu kommunizieren…

Leanpub: arc42-Starschnitt Gradle Ein Architekturüberblick in Lebensgröße.

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.

Zum arc42-Starschnitt

Beitragsbild_admin-ajax

arc42-Starschnitt: Gradle. Schnipsel Nr. 8: Randbedingungen

By | Inhaltliches, Kolumne

Bei Softwarearchitektur geht es darum, fundamentale Entscheidungen zu treffen. Pflöcke zu setzen, die sich im weiteren Verlauf nur schwer verschieben lassen und die mithin entscheidend für den Erfolg Ihrer Softwarelösung sind. Es geht darum, aus Alternativen für eine wichtige Fragestellung die passende Option auszuwählen. Randbedingungen schränken die Menge gültiger Alternativen ein. Und um Randbedingungen (oder auch Rahmenbedingungen) geht es in dieser Folge der Starschnitt-Serie. Nun heißt es also wieder: Schere raus und losgeschnippelt …

Single-Function Devices — dem Tode geweiht?

Während viele Leute ihr Smartphone heute als elektrisches Schweizer Armeemesser für alles einsetzen, bin ich noch altmodisch und bevorzuge Single-Function Devices. Konkret heißt das bei mir, etwa eine eigene Kamera für Photos, einen extra E-Reader, ein spezielles GPS für Geocaching (der Genauigkeit wegen), wiederum anderes GPS für Läufe (Pace-Anzeige und Herzfrequenz) usw. …

Bei Kontrollen im Flughafen ist das Sicherheitspersonal regelmäßig verblüfft, wieviele unterschiedliche USB-Kabel man so mitschleppen kann. Ich habe sogar noch eine richtige Quartz-Armbanduhr (echt, Schweizer Modell).

Und selbstredend verwende ich einen separaten MP3-Player für Musik, vor allem des geringen Gewichts wegen (beim Laufen, s.o.) und der unschlagbaren Akkulaufzeit des Gerätes.

Single-Function Device: MP3-Player

Zu diesem MP3-Player gibt es auch eine nette Software zum Verwalten von Inhalten (Musik, Podcasts) und zum Synchronisieren mit PCs. Sie heißt Media Go. Na ja, für mein Notebook gibt es sie eigentlich nicht. Auf der Web-Seite des Herstellers gibt es im FAQ die passende Frage „Can I use Media Go on a Mac?“. Und eine verblüffende Antwort:

Media Go is designed to run on the Windows operating system.

Der Satz ließ mich aufhorchen.  Man hätte ja auch einfach „Nein“ schreiben können. Ich vermute, der Hersteller wollte mit dem Satz irgendetwas Positives ausdrücken: „Wir haben es genau dafür entworfen, deswegen ist es dafür auch besonders toll“ (oder so ähnlich). Bei mir hat es im Hinblick auf die Softwarearchitektur von Media Go allerdings die Frage aufgeworfen: wer hat das entschieden und warum? War das überhaupt eine explizite Entscheidung?

Entwerfen heißt entscheiden

Für mich als Außenstehenden ist es unklar: war Windows eine Vorgabe des Produktmanagements von Media Go? Also zum Beispiel: „Muss auf Windows laufen“ (andere Sachen wurden in den Anforderungen nicht erwähnt, und dann lief es halt am Ende unter Windows). Oder lag es eher an den Kenntnissen und Erfahrungen der Softwareentwickler? Vielleicht waren sie sehr versiert unter Windows und konnten Zeitplan und Budget damit einhalten, mit anderen oder weiteren Plattformen hingegen nicht … Wir wissen es im konkreten Fall nicht. Möglicherweise kaschiert der Satz „… designed to run on …“ sogar eine Entscheidung, die nur implizit getroffen wurde. Mit dem Ergebnis muss ich als Benutzer nun leben. Und die Entwickler, welche die Software vielleicht später einmal Portieren wollen, wohl auch.

Das kleine Beispiel beleuchtet ein interessantes Problem, das mir beim Nachdokumentieren von Softwarearchitektur gemeinsam mit Projektteams regelmäßig unterkommt: während Randbedingungen sich eigentlich methodisch völlig klar von Architekturentscheidungen abgrenzen lassen, ist im Nachhinein nicht immer zu unterscheiden, ob etwas eine Vorgabe war, oder ein Freiheitsgrad im Lösungsraum.

Randbedingungen schränken den Lösungsraum ein

Randbedingungen fassen all die Dinge zusammen, die im Rahmen des Architekturentwurfs vorgegeben sind und Entscheidungen entsprechend beeinflussen. Eine typische Kategorisierung unterscheidet zwischen technischen und organisatorischen Randbedingungen und gegebenenfalls noch Konventionen.

Mögliche technische Vorgaben in der Softwareentwicklung:

  • Programmiersprache
  • Frameworks
  • Zielumgebung (Plattform, Betriebssystem(e))

Beispiele für organisatorische Vorgaben:

  • Zeitrahmen und Budget  (Termine, Aufwand)
  • Vorgehen und Organisation der Teams
  • Skills der beteiligten Mitarbeiter

Gerade organisatorische Einschränkungen beeinflussen Technologieentscheidungen regelmäßig stark. Bei jeder „Make or Buy“-Entscheidung spielen Budget und Zeitplan eine Rolle. Die Skills der Mitarbeiter sind ein starkes Argument bei der Auswahl von Tools und Frameworks. Und für das Zusammenspiel von Teamorganisation und Softwarestruktur gibt es sogar ein prominentes Gesetz: Conway’s Law:

Organisationen, die Systeme modellieren, […] sind auf Modelle festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.

Melvin E. Conway (1968)

In der Praxis spiegelt sich das dann in an der Schichtenarchitektur ausgerichteten Teams wider (GUI-Team, Persistenz-Team, …), oder alternativ dazu vertikal in Featureteams.

Randbedingungen zu kennen ist für den Entwurf einer Softwarearchitektur entscheidend. Bei einer konkreten Fragestellung gibt es Alternativen, Randbedingungen schließen manche aus. Wenn Sie fälschlicherweise eine davon wählen, ist Ihre Lösung unzulässig und wenn Sie das zu spät merken, kann es teuer werden. Im Extremfall scheitert das Projekt (vgl. Definition Softwarearchitektur von Eoin Woods).

Entscheidung oder Vorgabe? 

Einer Softwarelösung selbst sehen Sie am Ende lediglich an, dass eine bestimmte Technologie eingesetzt wird. Nicht, ob es eine Vorgabe war oder eine Entscheidung des Teams. Und im Falle einer Entscheidung nicht, ob Alternativen in Betracht gezogen wurden.  Für die Nachvollziehbarkeit der Softwarearchitektur ist es daher sehr wichtig, Randbedingungen explizit festzuhalten. Sonst stellt sich später die Frage an die Entwickler: musstest Ihr das so machen oder habt Ihr das selbst entschieden? Wie im Fall von Windows als Zielplattform im Beispiel Media Go.

Doch nun zu unserem Serienstar Gradle. Auch in diesem Fall war es für mich gar nicht so einfach, technische Randbedingungen und Technolgieentscheidungen auseinander zu halten. Open Source Projekte haben oft größeren Einfluss auf Randbedingungen als Umsetzungsteams in Kundenprojekten. Der folgende Schnipsel ist als Beispiel zu sehen.

– – – 8< – – –

Schnipsel #8: Randbedingungen für Gradle (Stand: Gradle 1.12)

Technische Randbedingungen

ThemaErläuterung
BetriebssystemeGradle unterstützt (mindestens) Windows, Linux und MacOS
JVMGradle läuft unter Java JDK, Version 1.5 („Java 5“), oder höher
VCSGradle unterstützt die verbreitetsten Versionskontrollsysteme am Markt (freie und kommerzielle)
BetriebsmodiGradle kann aus den wichtigsten IDEs, von Buildservern und von der Kommandozeile aus gestartet werden
BuildGradle baut sich selbst

Organisatorische Randbedingungen

ThemaErläuterung
LizenzGradle ist Open Source und steht unter der Apache License 2.0 (ALv2)
FremdbibliothekenEs können nur solche Bibliotheken verwendet und mit ausgeliefert werden, deren Lizenz zur ALv2 kompatibel ist
GradlewareDie Firma Gradleware steht hinter Gradle. Ihre Mitarbeiter prägen, wenn auch im engen Kontakt und auf Augenhöhe mit der übrigen Community, schlussendlich die strategische Ausrichtung und Weiterentwicklung von Gradle

Konventionen

ThemaErläuterung
Source codeQuelltextverwaltung bei GitHub, https://github.com/gradle
Defect Trackingmit JIRA unter http://issues.gradle.org
CommunityInteraktion mit Nutzern unter http://forums.gradle.org/gradle

– – – >8 – – –

Beispielsweise beeinflussen die Java Version (Gradle muss auch noch unter Java 5 laufen) und die Lizenz die Auswahl von Fremdbibliotheken, die bei Gradle zum Einsatz kommen können.

Die Programmiersprache muss JVM-basiert sein, im Lösungsraum wäre aber neben Java selbst (was zur Entwicklung von Gradle verwendet wird) auch Groovy gewesen.

Wo kleben wir den Schnipsel hin?

Randbedingungen haben in arc42 einen festen Platz: Sie landen im gleichnamigen zweiten Abschnitt der arc42-Gliederung, der ebenso strukturiert ist, wie oben beschrieben (technisch, organisatorisch, Konventionen) und auch wie im Gradle-Beispiel oben gezeigt.

Schnipsel #8 in arc42 "abheften"

Der entsprechende Abschnitt in arc42 enthält eine Liste an Beispielthemen für Randbedingungen, die Sie beim Erarbeiten der Randbedingungen für Ihr eigenes Projekt hinzuziehen können.

Bleiben Randbedingungen stabil?

Randbedingungen sind im Projektverlauf typischerweise fest, können sich mit der Zeit aber ändern.

Gradle 2.0 fordert beispielsweise Java 6. Java 5 wird nicht mehr als Laufzeitumgebung unterstützt (Forenbeitrag dazu). In vielen deutschen Versicherungen war der Einsatz von Open Source in Java Projekten zur Jahrtausendwende noch grundsätzlich unzulässig. Heute ist er in geregelten Bahnen (Randbedingungen) auch dort gang und gäbe.

Diese Veränderungen sind ein weiteres Argument dafür, Randbedingungen im Rahmen der Architekturdokumentation festzuhalten. Entscheidungen sind ohne diese zentralen Einflussfaktoren später kaum nachvollziehbar.

Wenn Randbedingungen auch bei der Weiterentwicklung der Softwarearchitektur beachtet werden sollen (oft ist das der Fall, damit die Architektur nicht verwässert), formulieren Sie diese so, dass sie möglichst unempfindlich gegenüber der Zeit sind.

Im Beispiel Gradle habe ich das etwa mit „unterstützt die verbreitetsten Versionskontrollsysteme (VCS) am Markt“ anklingen lassen. Wenn später ein neuer Stern am VCS-Himmel erstrahlt, muss die Architektur eine Antwort darauf haben, wie man ihn schnell unterstützt. Falls in Gradle nur bestimmte VCS hart verdrahtet wären und kein Konzept zur Erweiterung vorläge, wäre das ein Risiko, das eine Architekturbewertung, welche die Randbedingungen mit abklopft, aufdecken würde …

Zum Weiterlesen

Ausblick

Den achten Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben, können Sie hier herunterladen. 😉

In der nächsten Folge geht es übrigens um übergreifende Konzepte. Vereinfacht gesagt ist das der Joker-Abschnitt in arc42. Warum das so ist, kläre dann auf. Es bleibt also spannend …

Leanpub: arc42-Starschnitt Gradle Ein Architekturüberblick in Lebensgröße.

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.

Zum arc42-Starschnitt

Beitragsbild_admin-ajax

arc42-Starschnitt: Gradle. Schnipsel Nr. 7: Qualitätsszenarien

By | Inhaltliches, Kolumne

Und weiter mit Gradle zerlegt nach arc42 … In diesem Schnipsel geht es vereinfacht gesagt um „beispielhafte Qualität“. Ich knüpfe dabei an die Qualitätsziele aus Folge 3 der Starschnitt-Serie an.

Zur Erinnerung: Qualitätsziele motivieren die wichtigsten drei bis fünf geforderten Qualitätsmerkmale für Ihr System (z.B. Performance, Benutzbarkeit, Wartbarkeit, …). Qualitätsszenarien (oder auch Bewertungsszenarien) konkretisieren diese nun. Neben ihrer wichtigen Rolle als Kommunikationsmittel, die auch ihre „Anwesenheit“ in arc42 erklärt, helfen Szenarien vor allem Entscheidungen früh abzusichern und Softwarearchitektur im Nachhinein zu bewerten. Also insgesamt eine ziemlich feine Sache.

Und so heißt es wieder: Schere raus und losgeschnippelt …

Sachen machen (Making things)

Trends wie Virtualisierung und Cloud-Computing entfernen viele Entwickler immer weiter von der Zielumgebung ihrer Anwendungen. Vielleicht auch um dieser Entfremdung ein wenig entgegen zu wirken entdecken immer mehr Programmierer Kleincomputer wie den Raspberry Pi als Freizeitbeschäftigung. Es ist ein erfrischendes Gefühl, Hard- und Software wieder zusammen wirken zu sehen. Und selber Dinge zu bauen, die direkt mit ihrer Umfeld interagieren.

Die Do-It-Yourself-Bewegung der Gegenwart ist kreativ und unglaublich vielseitig. Gebastelt, geschraubt, programmiert und gelötet wird mittlerweile eigentlich nahezu alles. Das reicht von selbstgemachten Visitenkarten über 3D-Drucker bis zur Kreissägeblattschleuder.

(Hagen Fisbeck auf regital.de)

Ein prominenter Protagonist dieser Bewegung ist der Arduino. In ihm verrichtet ein Atmel AVR-Microprozessor als Herz und Hirn seinen Dienst, der ATmega328 (8 bit). Mit dem Arduino-Board lassen sich recht komfortabel Microcontroller-basierte Sachen machen, die messen, steuern, regeln.

Ein Arduino Uno (links) bei der Arbeit

Doch nicht so toll?

Elliot Williams führt in seinem schönen Buch „Make: AVR Programming — Learning to Write Software for Hardware“ (Cover-Abbildung rechts) aus, welche Nachteile er beim Einsatz von Arduino sieht, wenn man sich mit der AVR-Programmierung beschäftigt. Bestimmte Entscheidungen bei der Konzeption von Arduino schränken den „Maker“ seiner Meinung nach stark ein, oder behindern ihn zumindest.

Als konkretes (und zugleich leicht verständliches) Beispiel kann die Umbenennung der Pins von Atmel-Datenblatt zu Arduino dienen. Bei AVR-Prozessoren sind die Pins in Bänken organisiert, die mit B, C, D … usw. (Anzahl je nach Typ) bezeichnet sind. Die Pins von Bank B heißen dann PB0, PB1, PB2, …, PB7, Bank C dann PC0, PC1, …

Beim Arduino sind diese Pins allerdings umbenannt worden, um durchgängige Nummern zu realisieren. Einsteigern wird dadurch die Benutzung erleichtert. Die Pins heißen z.B. Digital Pin 0 (kurz D0), Digital Pin 1 (D1) usw. was dazu führt, dass aus dem Original-Pin PB5 dann Digital Pin 13 wird. Siehe folgende Abbildung (nach Quelle).

Pinbelegung ATmega328 (notiert in schwarz) und Bezeichnungen Arduino (in rot) -- Ausschnitt

Die Namen der Pins kommen bei Arduino-Programmen direkt im Quelltext zum Einsatz, wie das „Hello World“-Pendant Blink zeigt. Die Pinnummern gehören also quasi zur API dazu — sie sind für den Benutzer spürbar.

Wer nun mit dem Original-Datenblatt von Atmel zum Prozessor arbeiten möchte, und ein Arduino-Projekt realisiert, muss die Pin-Namen jedes mal übersetzen. Vorhandenes Wissen, das ein Benutzer ggf. aus früheren Experimenten von der AVR-Pinbelegung mitbringt, kann er nicht direkt anwenden. Und wenn er irgendwann von Arduino hin zum „direkten“ Arbeiten mit AVR-Prozessoren wechseln möchte, müsste er ebenfalls umdenken. Schade, findet Elliot Williams.

Aber wie schlimm ist das nun eigentlich? Schlussendlich ist Arduino ja dazu da, Hobbyisten den Einstieg in die AVR-Welt zu eröffnen. Sind durchnummerierte Pins nicht praktisch? Andererseits lassen sich Arduino-Quelltexte und Beispiele, etwas aus Tutorials, nicht so ohne weiteres in die direkte AVR-Programmierung übernehmen. Hier ist abzuwägen zwischen leichter Erlernbarkeit auf der einen und Portierbarkeit auf der anderen Seite …

Beispielhafte Qualität

Anforderungen a la „Benutzbarkeit ist superwichtig und Portierbarkeit ist ggf. auch interessant“ sind in der Praxis nicht konkret genug, um Entscheidungen zu treffen oder zu bewerten. Qualitätsszenarien gehen daher einen Schritt weiter. Sie sind beispielhafte Verwendungen des Systems, in denen ein Qualitätsmerkmal die Hauptrolle spielt. In ihnen wird Qualität lebendig inszeniert.

Für die Arduino-Plattform und die Problemstellung von oben könnten zwei Qualitätsszenarien zum Beispiel so aussehen:

  • [BEN01] Ein in Elektronik Unkundiger mit Programmiererfahrung möchte mit einem Arduino drei LEDs nach Art einer Ampel zum Leuchten bringen. Nach einer Stunde ist das Projekt erfolgreich ohne Lötarbeiten abgeschlossen und es blinkt.
  • [PRT01] Ein Programmierer möchte ein für Arduino entwickeltes Programm auf einem anderen AVR-Mikrocontroller (zum Beispiel ATtiny13) betreiben. Dies gelingt ihm ohne Änderung des Quelltextes.
Ein ATtiny ist ziemlich klein
Ein ATtiny ist ziemlich klein

Ganz generell können solche Szenarien diejenigen, die Anforderungen haben, und diejenigen, die sie umsetzen sollen, früh miteinander ins Gespräch bringen. Plötzlich lassen sich Anforderungen bzgl. Qualität (hier im Beispiel: Benutzbarkeit und Portierbarkeit) greifen und priorisieren, und Risiken bewerten. Ist etwas schwierig umzusetzen? Widersprechen sich Anforderungen vielleicht sogar? Auf dieser Basis lassen sich Entscheidungen sicherer treffen.

Und im Nachhinein erarbeitet (wie in unserem Beispiel zu Arduino geschehen) können Szenarien auch dabei helfen Entscheidungen zu bewerten oder abzusichern. Tatsächlich sind Qualitätsszenarien eigentlich ein Werkzeug aus der qualitativen Architekturbewertung, was auch das gebräuchliche Synonym Bewertungsszenarien erklärt.

Typischer Aufbau

In der Praxis haben Qualitätsszenarien einen stets gleichen Aufbau, dargestellt in der folgenden Abbildung (nach Len Bass et al.). Die einzelnen Bestandteile (Quelle, Auslöser, Artefakt, …) helfen Ihnen dabei, Szenarien methodisch herzuleiten. Es ist allerdings nicht erforderlich, dass Ihre Szenarien stets alle Teile aufweisen. Gleichwohl bewahrt das Schema Sie vor Allgemeinplätzen. Eine Quelle und/oder einen Auslöser sollte jedes Ihrer Szenarien haben. „Das System darf niemals ausfallen“ hätte beispielsweise nichts von beidem.

Typische Bestandteile eines Qualitätsszenarios, und ein Beispiel
Typische Bestandteile eines Qualitätsszenarios, und ein Beispiel

Im Beispiel ist der in Elektronik Unkundige die Quelle, sein Wunsch ein Ampel-Projekt umzusetzen der Auslöser, das es blinkt die Antwort, die eine Stunde das Antwort-Maß usw.

Mit diesen zwei Szenarien und weiteren Beispielen könnten wir nun eine Diskussion beginnen, und bewerten ob die Entscheidungen des Arduino-Teams (die Namen der Pinbelegung waren dabei nur ein kleines Beispiel) zu den Anforderungen passen. Im Hinterkopf sollten wir dabei das Mission Statement von Arduino und die damit verbundenen Qualitätsziele behalten.

Arduino is an Open-Source electronics prototyping platform based on flexible, easy-to-use hardware and software. It’s intended for artists, designers, hobbyists and anyone interested in creating interactive objects or environments.

(von der Arduino-Webseite)

Dieses Mission Statement würde sich übrigens auch gut auf einem Produktkarton (Thema der ersten Folge dieser Blog-Serie) für Arduino machen.

Statt diese Diskussion zu führen verlassen wir den Arduino nun aber zugunsten unseres eigentlichen Serien-Stars. Im Folgenden also Qualitätsszenarien zu Gradle!

– – – 8< – – –

Schnipsel #7: Qualitätsszenarien für Gradle

Die folgende Liste enthält konkrete Szenarien, welche die zentralen Qualitätsziele von Gradle (siehe Folge 3), aber auch andere geforderte Qualitätsmerkmale illustrieren sollen.

  • [ANP01] Ein IDE-Anbieter möchte Gradle-Projekte in seinem Produkt unterstützen. Dies gelingt ihm ohne Änderung am Gradle-Quelltext in weniger als 5 Personentagen Aufwand.
  • [EFF01] Ein Gradle-Benutzer lässt sich die verfügbaren Tasks eines Projektes anzeigen. Er erhält nach maximal 5s eine Rückmeldung.
  • [ERL01] Ein Entwickler mit Ant/Ivy-Kenntnissen stellt einen bestehenden Ant/Ivy-Build auf Gradle um. Dies gelingt im deutlich schneller als mit Maven.
  • [ERL02] Ein Gradle-Neuling erstellt ein einfaches Java-Projekt mit Gradle. Spätestens nach einer Stunde übersetzt der Quelltext, laufen erste Tests, und sein Build produziert ein jar-File.
  • [ERW01] Ein Build-Master möchte eine neue Programmiersprache (3GL), für die Gradle noch keine Funktionalität bereithält,  mit Gradle unterstützen. Rudimentäre Tasks zum Übersetzen etc. laufen bereits nach einem Tag.
  • [ERW02] Ein externer (d.h. Gradleware-fremder) Entwickler stellt eigene Gradle-Funktionalität allgemein (öffentlich) bereit. Im Anschluss müssen Verwender von Builds-Skripten, die diese Funktionalität nutzen, dafür nichts separat installieren.
  • [INT01] Für eine von Gradle nicht out-of-the-box unterstützte Aufgabe steht ein Ant-Task zur Verfügung. Das Einbinden in einen Gradle-Build erfordert keine tieferen Groovy/Java-Kenntnisse.
  • [IST01] Ein Entwickler ohne Gradle-Kenntnisse (und ohne Gradle-Installation auf seinem Notebook) checkt ein Projekt, das mit Gradle gebaut wird, aus Subversion aus. Spätestens 1 Minute später startet er den Build.
  • [SKA01] Die Anzahl der Subprojekte in einem Gradle-Build verdoppelt sich. Die Zeit, um ein bestehendes Subprojekt neu zu bauen, bleibt gleich.
  • [SKA02] Die Anzahl der Quelltextdateien in einem Projekt wächst von 20 auf 200. Das Neubauen bei Änderung einer einzelnen Quelltext-Datei, zu der keine Abhängigkeiten bestehen, dauert gleich lang.
  • [STA01] Gradleware veröffentlicht eine neue Gradle-Version. Bestehende Projekte lassen sich damit ohne Änderung bauen.
  • [ZUV01] Ein Build erfordert ein Artefakt aus einem Maven-Repository. Der Build wird initial angestoßen, aber es besteht keine Verbindung zum Repository. Der Benutzer wird darüber informiert, der Build bricht ab.

Die folgende Abbildung ordnet diese Szenarien Qualitätsmerkmalen zu.

Qualitätsbaum: Zuordnung der Szenarien zu Qualitätsmerkmalen
Qualitätsbaum: Zuordnung der Szenarien zu Qualitätsmerkmalen

– – – >8 – – –

Erfüllt Gradle diese Szenarien eigentlich?

Das könnte man nun diskutieren. Geschrieben hatte ich die Qualitätsszenarien eigentlich „nur“ als Beispiele für diesen Blog. Inhaltlich plausibel sollten sie natürlich trotzdem sein, und so habe ich mich mit Rene Gröschke (Gradle Inc.) ein wenig zu den Szenarien ausgetauscht und teilweise auch noch einmal nachgeschliffen. Unterm Strich sind sie nun sinnvoll, Gradle erreicht sie in der Regel, teilweise werden sie sogar „übererfüllt“.  An dieser Stelle vielen Dank für den Austausch, Rene!

Wie konkret müssen Szenarien sein?

Da Qualitätsszenarien die geforderte Qualität illustrieren, sollten Sie diese lebendig formulieren und konkret machen. Verwechseln Sie das Werkzeug nicht mit Akzeptanzkriterien. Gerade früh formuliert müssen Szenarien meiner Erfahrung nach nicht zwingend objektiv messbar sein. Man sollte sich aber schon sinnvoll darüber unterhalten können, wie man beispielsweise die (Nicht-)Erreichbarkeit einschätzt, oder den fachlichen Nutzen. Später können Sie bei Bedarf Akzeptanzkriterien und Tests aus den Szenarien ableiten.

Wie viele Qualitätsszenarien fertigen Sie für Ihr Projekt an?

Szenarien sind Beispiele. Natürlich schreiben Sie nicht sämtliche denkbaren Anforderungen bzgl. Qualität darin fest. Das wären offensichtlich viel zu viele. Trotzdem kommt oft die Frage auf, wieviele Qualitätsszenarien in der Praxis zu formulieren sind, und wir mit ihnen weiter verfahren wird.

Für den Fall eines Architekturüberblicks genügen in der Regel ca. ein Dutzend Szenarien, welche die Qualitätsziele und einige weitere wichtige Qualitätsmerkmale illustrieren. Den Nachweis, dass Sie tatsächlich alle Qualitätsziele „erwischt“ haben, können Sie mit Hilfe eines Qualitätsbaums (engl. Utility Tree) führen und belegen. So heißt die baumartige Darstellung am Ende des Gradle-Beispiels oben.

Für andere Anwendungszwecke von Szenarien lässt sich die Frage nach der Anzahl nicht pauschal beantworten. Die Beschreibung des Einsatzes von Qualitätsszenarien etwa in der Architekturbewertung, wo das Werkzeug seine Heimat hat, sprengt den Rahmen dieses Blogbeitrages. Vorrangig geht es in dieser Serie ja darum, Softwarearchitektur festzuhalten und zu kommunizieren. Damit schließt sich natürlich die Frage an …

Wo kleben wir den Schnipsel hin?

Für Qualitätsszenarien hält arc42 einen eigenen Abschnitt bereit: Abschnitt 10 (siehe Abbildung unten). Als Form sind dort ebenfalls ein Qualitätsbaum als Einstieg und dann eine Liste oder Tabelle mit den Qualitätsszenarien selbst vorgesehen.

Schnipsel #7 abheften in arc42

Die Platzierung der Qualitätsszenarien weit hinten in der arc42-Vorlage lässt sich mit der groben Struktur der Gliederung erklären:

  • Aufgabe (Abschnitte 1-3)
  • Lösung (Abschnitte 4-9)
  • Bewertung (Abschnitte 10-11)

Das hindert Sie nicht daran, erste Qualitätsszenarien bereits früh im Projekt anzufertigen, um etwa Qualitätsziele besser mit allen Beteiligten diskutieren zu können.

Zum Weiterlesen

  • Qualitätsszenarien sind auch ein Dokumentationsmittel in meinem Buch Softwarearchitekturen dokumentieren und kommunizieren. Eines der Fallbeispiele des Buches, eine Schach-Engine, ist online verfügbar und besitzt ebenfalls Qualitätsszenarien und einen Qualitätsbaum: Qualitätsszenarien DokChess
  • Hagen Fisbeck schreibt hier auf regital.de: „Die Makerbewegung und ihre Auswirkungen auch auf den Handel“
  • Der Klassiker: Len Bass et al., „Software Architecture in Practice“, 3. Auflage Addison-Wesley 2012. Beschreibt Qualitätsszenarien, ihren hier ebenfalls gezeigten Aufbau und Einsatz in der Architekturbewertung.
  • Stefan Toth empfiehlt in seinem Buch Vorgehensmuster für Softwarearchitektur Qualitätsszenarien zum Erarbeiten und Priorisieren architekturrelevanter Anforderungen. Er diskutiert u.a. auch wie man sie in einem Scrum-Backlog mitführt.

Ausblick

Den siebten Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben können Sie hier herunterladen. 😉

Geforderte Qualitätsmerkmale gelten als zentraler Einflussfaktor auf Architekturentscheidungen. Einen weiteren wichtigen Einfluss stellen Rand- oder Rahmenbedingungen dar. Diesen widmen wir uns dann in der nächsten Folge. Ein weiterer Schnipsel für unser Gradle-Puzzle.

Leanpub: arc42-Starschnitt Gradle Ein Architekturüberblick in Lebensgröße.

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.

Zum arc42-Starschnitt

arc42_Folge6_

arc42-Starschnitt: Gradle. Schnipsel Nr. 6: Grafisches Glossar

By | Inhaltliches, Kolumne

OK: Glossar klingt jetzt nicht sooo spannend. Das Inhaltsverzeichnis von arc42 enthält einige Abschnitte, wo auf den ersten Blick sonnenklar erscheint, was sie bergen. Das Glossar zählt wohl dazu. Langweilig? Ich finde nein.
Für unser Vorhaben, Gradle nach arc42 gegliedert darzustellen, ist es wertvoll, und kommt eher zu spät. Und als Ergänzung zur „klassischen“ tabellarischen Form eines Glossars schlage ich eine grafische Ergänzung dazu vor. Nun doch gespannt?

Dann wieder: Schere raus und losgeschnippelt …

Was ist Aufklärung?

Immanuel Kant definierte in seinem berühmten Essay „Beantwortung der Frage: Was ist Aufklärung?“ nicht nur eben diesen Begriff. Er klärte in dem Zusammenhang auch noch einige weitere. Hier der Beginn des Aufsatzes …

„Aufklärung ist der Ausgang des Menschen aus seiner selbstverschuldeten Unmündigkeit. Unmündigkeit ist das Unvermögen, sich seines Verstandes ohne Leitung eines anderen zu bedienen. Selbstverschuldet ist diese Unmündigkeit, wenn die Ursache derselben nicht am Mangel des Verstandes, sondern der Entschließung und des Mutes liegt, sich seiner ohne Leitung eines andern zu bedienen. Sapere aude! Habe Mut, dich deines eigenen Verstandes zu bedienen! ist also der Wahlspruch der Aufklärung. …“

Immanuel Kant, 1784

Kant stand mit vielen Zeitgenossen in schriftlicher Korrespondenz (z.B. mit Friedrich Schiller), und tauschte sich mit ihnen aus.

Von Kant zu Clean Code

Auch bei der Kommunikation in Softwareentwicklungsprojekten ist es unerlässlich, dass die Beteiligten über dasselbe reden, wenn sie einen Begriff verwenden. Sonst reden sie buchstäblich aneinander vorbei. Muster und Prinzipien sind typische Beispiele für Kategorien in der IT-Welt, in denen sich Begriffe und in Summe eine gemeinsame Sprache etabliert haben. Diese Begriffe sind in einflussreichen Fachbüchern geklärt. Die Philosophen der IT heißen nicht Nietzsche („Gott ist tot.“, 1882)  sondern  Hunt („Der pragmatische Programmierer“, 1999) oder Martin („Clean Code“, 2008), … manchmal schreiben sie wie Kant einen Essay — heute in ihrem Blog. Sie fragen nicht „Was ist Aufklärung?“ sondern  zum Beispiel „Was ist Dependency Injection?“ (Martin Fowler, „Inversion of Control Containers and the Dependency Injection pattern“, 2004) oder (ein weiterer Klassiker) „Was ist AOP?“ (Adrian Colyer, „AOP without the buzzwords“, 2004).

Muster, Prinzipien und Paradigmen sind allgemeingültige Begriffe in der IT, wir lernen sie in Studium, Aus- oder Weiterbildung. Sie helfen uns im Projekt, die Konzepte und Ideen unserer Lösung an Dritte zu kommunizieren. Zum Beispiel an ein neues Teammitglied. Daneben gibt es noch Begriffe, die projektspezifisch sind. Und die ein neues Teammitglied, auch mit ähnlichem IT-Hintergrund, neu lernen muss, um mitreden zu können. Oft — aber nicht immer — sind sie fachlich motiviert. Hier hilft ein projektspezifisches Glossar.

Ein fachsprachliches oder technisches Glossar listet die Terminologie einer Fachsprache oder eines technischen Sachgebietes mit begrifflich-sachlichen Definitionen auf, die den richtigen Gebrauch dieser Fachausdrücke und deren eindeutiges Verständnis sichern sollen.

aus Wikipedia: Glossar

Glossare

Die klassische Form eines Glossars ist tabellarisch. Die Begriffe in der ersten Spalte sind alphabetisch sortiert. Eine zweite Spalte beinhaltet die Erläuterungen. Falls in den Erläuterungen Glossarbegriffe verwendet werden, sind diese idealerweise geeignet gekennzeichnet.

Diese Form ist leichter zu benutzen und auch zu pflegen als ein Prosa-Text. Um beim Beispiel Kant zu bleiben sieht ein tabellarisches Glossar ungefähr so aus … (die jeweiligen Erläuterungen in der Tabelle sind Wikipedia-Artikeln entlehnt):

Begriff Erläuterung
Aufklärung Epoche in der modernen westlichen Philosophie. Laut Kant der „Ausgang des Menschen aus seiner selbstverschuldeten Unmündigkeit“
Epoche längerer geschichtlicher Abschnitt mit grundlegenden Gemeinsamkeiten
Kant Immanuel Kant (1724-1804), deutscher Philosoph der Aufklärung
Mensch höheres Säugetier aus der Ordnung der Primaten. Kann Fragen stellen, die in grundlegender Weise die eigene Existenz und Zukunft betreffen
 

Grafisches Glossar als Ergänzung

Ein neues Teammitglied wird sich sehr freuen, wenn es zum Start ein Projektglossar in die Hand gedrückt bekommt. Begriffe, die „der Neue“ (oder „die Neue“) wiederholt aufschnappt, schaut er nach, und lernt sie schnell. Fehlt ein Begriff, oder wird ein Begriff inkonsistent benutzt, kann das neue Teammitglied das aufspüren, und aktiv zur Verbesserung des Glossars beitragen.

Bei umfangreichen Glossaren ist die Freude mitunter getrübt. Der ein oder andere wird sich an das Lernen von Vokabeln erinnert fühlen. Ich habe sehr gute Erfahrungen damit gemacht, ein tabellarisches Glossar mit einem Schaubild zu ergänzen. Ein solches grafisches Glossar zeigt in Form eines Graphen die wichtigsten Begriffe als Knoten. Verbindungen (Kanten) zwischen diesen Begriffen zeigen Beziehungen und können beschriftet werden. Die Kanten nehmen so weiteres Fachvokabular auf.

Als Beispiel, wie so etwas grafisch aussehen kann, habe ich mir nochmal den Text von Kant vorgenommen:

Grafisches Glossar Kant

Wenn Sie einen Begriff nehmen, und die Kanten entlang wandern, können Sie Sätze lesen wie „Mensch bedient sich Verstand“. Ein grafisches Glossar zeigt also die Verwendung des Fachvokabulars in Verknüpfung. Doch nun genug philosophiert. Längst Zeit für unseren Serienstar Gradle!

– – – 8< – – –

Schnipsel #6 (Grafisches Glossar): Eine Glossar für Gradle

Das folgende Diagramm zeigt einige wichtige Begriffe aus der Gradle-Welt und setzt sie in Beziehung zueinander.  Die dargestellten Begriffe, und noch weitere, sind in der nachfolgenden Tabelle erläutert.

Grafisches Glossar Gradle

Die Zahlen an den Linienenden im Diagramm lassen sich z.B. lesen  als „Ein Artifact wird veröffentlicht in keinem oder einem Repository“.

In den Erläuterungen der Tabelle sind verwendete Glossarbegriffe kursiv dargestellt.

BegriffErläuterung
Artifactphysisches Ergebnis (Output) eines Builds. Zum Beispiel ein JAR-File, oder eine DLL.
BuildAusführung des Build-Skriptes durch Gradle, Abarbeitung der Tasks.
Build-ScriptBeschreibt ein Projekt (Project). Bei Gradle eine Textdatei als Input für den Build, formuliert in einer Groovy-basierten DSL. Wesentliche Bestandteile: Konfiguration, Abhängigkeiten zu externen Bibliotheken, Schritte (Tasks), und Abhängigkeiten zwischen den Schritten.
DSLdomänenspezifische Sprache (engl. domain-specific language), Wikipedia
GradleJVM-basiertes Buildsystem. Führt im Rahmen des Builds das Build-Script aus.
Groovydynamisch typisierte Programmiersprache und Skriptsprache für die JVM (Homepage)
JVMJava Virtual Machine.
PluginFunktionalität von Gradle, die über Projektgrenzen hinweg wiederverwendet werden kann. Gradle liefert selbst zahlreiche Plugins mit („Core Plugins“). Eigene Erweiterungen können ebenfalls als Plugins realisiert werden („Custom Plugins“).
ProjectRepäsentiert etwas, was im Rahmen des Builds in einem oder mehreren Schritten gebaut werden kann, und/oder passieren soll. Zum Beispiel das Bauen und Ausliefern von Software.
PropertyEigenschaft eines Projektes, einer Task, eines Repositories. Erlaubt deren Konfiguration und ist typischerweise mit sinnvollem Standardwert versehen („convention over configuration“, Wikipedia).
RepositoryQuelle für externe Bibliotheken, von denen der Build abhängt. Oder Ziel für die Veröffentlichung (engl. publishing) von Artefakten (artifact). Beispiel: Maven Central.
TaskEinzelner Schritt innerhalb des Builds. Kann adhoc im Build-Script in Groovy definiert sein, oder Bestandteil eines Plugins, und im Skript verwendet.

– – – >8 – – –

Das Gradle-Glossar hier im Blog-Beitrag ist ein erster Wurf. Am Ende der Startschnitt-Serie füge ich die Schnipsel  zu einem geschlossenen Architekturüberblick zusammen. Bis dahin ergänze ich das Glossar. Daher freue ich mich über Anregungen zum Inhalt. Welche Begriffe fehlen aus Ihrer Sicht?

Wie fertigen Sie einen grafischen Glossar an?

Puzzleteil als PDF

Im grafischen Glossar nehmen Sie nur zentrale Begriffe auf. Auch bei einem umfangreichen Glossar passt das Diagramm auf ein DIN-A4-Blatt. Das Bild ergänzt lediglich die Tabelle und dient dazu sich in die Begriffswelt einzufinden. Gerade bei umfangreichen Glossaren habe ich gute Erfahrungen mit diesen Bilder gesammelt; neue Mitarbeiter legen einen Ausdruck auf ihren Schreibtisch und schauen regelmäßig drauf.

Sie müssen auch nicht alle Kanten im Diagramm einzeichnen, die zwischen Ihren Begriffen möglich wären. Da alle aus einer Fachwelt stammen, gibt es immer eine mögliche Verknüpfung. Zeigen Sie aber nur die wichtigsten, vermeiden Sie ein Liniengewirr. Interessant sind vor allem solche Kanten, die Platz für weitere fachliche Begriffe bieten. Lassen Sie spannende Sätze entstehen, Ihr Glossar eine Geschichte erzählen!

Grafische Glossare, wie hier gezeigt, haben Ähnlichkeit mit Fachklassenmodellen der objekt-orientierten Analyse und Ansätzen im Domain-Driven Design. Für das Glossar ist entscheidend, dass die Diagramme intuitiv verständlich sind. Verzichten Sie auf eine Symbolflut (z.B. viele unterschiedliche Pfeilarten). Auch die Ergänzung um Attribute schießt am Ziel vorbei. Die Bilder sollen den Zugang zur Begriffswelt erleichtern. Wenn Sie die Notation erst erklären müssen, wird das schwieriger.

Wo kleben wir den Schnipsel hin?

In arc42 ist für das Glossar der letzte Abschnitt 12 vorgesehen, siehe Abbildung.

Glossar Abheften in arc42

Mitunter haben Sie in Ihrem Projekt bereits ein Glossar angelegt. Das Glossar in Ihrer Architekturbeschreibung sollte dazu passen, und die Begriffe konsistent dazu erklären. Am einfachsten verzichten Sie in solchen Fällen auf das Einfügen des Projektglossars in Ihr Architekturdokument und referenzieren es.

Ein Glossar, das speziell für einen nach arc42 gegliederten Architekturüberblick ausgedünnt wurde, ist auch eine Option. Der Überblick ist dann leichter zu lesen. Der Ansatz birgt durch die Redundanz gleichzeitig die Gefahr, dass die beiden Glossare auseinanderlaufen. Hier sind technische Lösungen, die Glossarbegriffe zentral verwalten, interessant.

Zum Weiterlesen

  • Glossare sind auch ein Dokumentationsmittel in meinem Buch Softwarearchitekturen dokumentieren und kommunizieren. Das Buch besitzt selber eine tabellarischen Glossar, der mit einem grafischen Glossar illustriert wird.
  • Eines der Fallbeispiele des Buches, eine Schach-Engine, ist online verfügbar und besitzt ebenfalls einen Glossar (keinen grafischen allerdings): Glossar DokChess
  • Der Wikipedia-Artikel zu Immanuel Kant enthält eine Illustration seiner Erkenntnistheorie, die in seiner Form einem grafischen Glossar wie hier gezeigt ähnelt.

Ausblick

Den sechsten Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben können Sie hier herunterladen. 😉

In der nächsten Folge des Starschnitts verfeinern wir die Qualitätsziele aus Schnipsel #3 mit Hilfe von Qualitätsszenarien genauer. Solche Szenarien bilden eine Basis, um Entscheidungen zu begründen und zu bewerten.

Leanpub: arc42-Starschnitt Gradle Ein Architekturüberblick in Lebensgröße.

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.

Zum arc42-Starschnitt

Beitragsbild_admin-ajax

arc42-Starschnitt: Gradle. Schnipsel Nr. 5: Architekturentscheidungen

By | Inhaltliches, Kolumne

Erinnern Sie sich? Softwarearchitektur hatte ich in Folge 1 dieser Serie als Summe wichtiger Entscheidungen definiert, die im weiteren Verlauf nur schwer zurückzunehmen sind. Um solche Architekturentscheidungen geht es in diesem Schnipsel. Sie fundiert zu treffen (und festzuhalten) ist ein zentraler Erfolgsfaktor für eine nachvollziehbare Softwarearchitektur.

Also wieder: Schere raus und losgeschnippelt …

Aus dem Hintergrund müsste Rahn schießen …

Fussball-WM 1954 in der Schweiz. Bei der Aufstellung zum 2. Gruppenspiel der deutschen Mannschaft rieben sich viele die Augen. Kein Toni Turek? Kein Hans Schäfer? Kein Max Morlock? Trainer Sepp Herberger trat mit einer Reservemannschaft an, und die auch damals schon zahlreichen selbsternannten Nationalcoachs fragten sich: „Warum hat er das gemacht? Ich hätte ja …“ — Die Aufstellung war auf den ersten Blick nicht nachzuvollziehen. Deutschland verlor das Spiel gegen Ungarn erwartungsgemäß 3:8. Na toll.

Aus dem Hintergrund müsste Rahn schießen … (Tipp Kick)

Allerdings blieb die haushohe Niederlage ohne Konsequenz, und Herberger wusste das. Deutschland hatte trotz der Schlappe aufgrund des Turniermodus gute Möglichkeiten zum Weiterkommen. Und das Ende ist bekannt, im Finale in Bern schlug eine an sieben Positionen veränderte deutsche Mannschaft wiederum Ungarn 3:2 (Siegtreffer bei Youtube). Um die Aufstellung des verlorenen Gruppenspiels inklusive der einkalkulierten Niederlage nachvollziehen zu können, muss man das große Ganze sehen, die Rahmenbedingungen (wie z.B. den ungewöhnlichen Turniermodus) und die Ziele („Das Spiel ist aus. Deutschland ist Weltmeister“).

Die Mannschaftsaufstellung zählt übrigens zu den Dingen, die ein Trainer im Spielverlauf nur noch schwer revidieren kann. Das galt 1954 noch viel mehr als heute. Denn Auswechseln durfte man beim Fußball in Pflichtspielen erst ab 1967, und selbst dann nur einmal im Spiel (vgl. Wikipedia: Auswechslung).

Warum habt Ihr das eigentlich so gemacht?

„Würde man das nicht eigentlich eher so machen? Ich hätte ja …“ – Neue Mitarbeiter in Softwareentwicklungsprojekten stellen viele Fragen. Nachdem sie arbeitsfähig geworden sind (und etwas mutiger) sogar so spannende wir diese. Der ultimative Test für die Nachvollziehbarkeit Ihrer Architektur eröffnet Ihnen die Chance zu erläutern, warum die gewählten Konzepte und Technologien genau die richtigen, oder zumindest angemessen sind. Wer hier mit „Historisch gewachsen …“ antwortet erntet ggf. Verständnis. Der Ausspruch ist Folklore in IT-Projekten wie der Torschrei beim Fußball. Schlussendlich aber nur das Bekenntnis, dass die Lösung eher zufällig entstanden ist.

Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.

Eoin Woods

Wo Scheitern keine Option ist, treffen Sie Entscheidungen lieber bewusst. Wesentliche Punkte des Entscheidungsprozesses halten Sie explizit fest.

Wie finden Sie die entscheidenden Fragestellungen?

Jedes Softwarevorhaben ist anders, nichts desto trotz gibt es typische Fragestellungen für Architekturentscheidungen. Dort wo das Risiko groß ist, ist Aufwand für Softwarearchitektur besonders gerechtfertigt. Da das Anbinden von Fremdsystemen beispielsweise oft mit Unsicherheiten verbunden ist, liefert der Systemkontext (siehe Schnipsel #2) oft Ideen. Fragestellungen, die kritisch für die Erreichung der Qualitätsziele sind (siehe Schnipsel #3) , sind ebenfalls Kandidaten für Architekturentscheidungen.

Hier einige typische Fragestellungen zur Illustration:

  • Welche Oberflächen erhalten die unterschiedlichen Benutzer?
  • Wie binden wir Fremdsystem XY an?
  • Welches Produkt/welche Technologie verwenden wir für XY?
  • Wie kommunizieren Bestandteile unseres Systems untereinander?
  • Wie adressieren wir querschnittliche Themen (zum Beispiel Persistenz, Verteilung …)?
  • Implementieren wir eine geforderte Funktionalitat selbst, oder verwenden wir eine bestehende Lösung („Make or Buy“, „Make or Take“)?

Beispiel: Fragestellungen für Gradle

Bei der Konzeption und Entwicklung von Gradle stand das Team vor einer Reihe von Fragestellungen. Hier einige Beispiele, die für Gradle vermutlich relevant waren.

  • In welcher Programmiersprache entwickeln wir Gradle?
  • Wie entwickeln Dritte Erweiterungen („Plugins“) für Gradle? (in Java, in Groovy, …?)
  • Entwickeln wir ein eigenes Dependency Management, oder nutzen wir ein Bestehendes („Make or Buy?“)
  • In welchem Form werden Buildskripte verfasst?

Entscheidungen treffen und nachvollziehbar festhalten

Um derartige Entscheidungen zu bearbeiten und später festzuhalten habe ich gute Erfahrungen mit einer Gliederung gemacht, die ich erstmals in einer Kolumne das Java Magazins in Form einer Mindmap veröffentlicht hatte. Für jede zentrale Entscheidung fragt sie die gleichen Dinge ab. So stellen Sie in einer Dokumentation alle Architekturentscheidungen der Lösung gleichförmig dar.

Mittlerweile konnte ich die Struktur mit ihren zugehörigen Leitfragen in weiteren Projektsituationen und Workshops testen und weiterentwickeln, siehe folgende Abbildung.

Mindmap Architekturentscheidungen (klicken zum Download als PDF)

Die gezeigte Gliederung kann sowohl zur Orientierung beim Treffen der Entscheidung verwendet werden (etwa in einem Workshop), als auch zum Festhalten der Ergebnisse. Letzteres beginnt idealerweise bereits während der Bearbeitung der Entscheidung. Die Punkte 1. – 5. werden in der Dokumentation zu Kapitelüberschriften z.B. innerhalb eines Dokumentes, oder auf einer Wiki-Seite — je nachdem, wo Sie die Entscheidung dokumentieren. An den einzelnen Ästen sind Fragen angehängt, die Sie in eine Vorlage (z.B. ein Wiki-Template) mit aufnehmen können. Sie müssen diese Leitfragen aber nicht sklavisch beantworten. Vielmehr sollen diese Sie und Ihr Team bei einer konkreten Architekturentscheidung, etwa in einem Workshop, leiten, anregen und unterstützen.

Fragestellungen und Annahmen

Auf die Inhalte aller Mindmap-Äste möchte ich hier nicht im Detail eingehen (siehe kostenlose Lesetipps unter „Zum Weiterlesen“ am Endes des Beitrags). Zwei Punkte verdienen aber in Hinblick auf die Dokumentation besondere Aufmerksamkeit: Fragestellung und Annahmen.

Entscheidungen im Projekt gibt es viele. Stellen Sie überzeugend dar, warum die hier betrachtete Fragestellung tatsächlich eine Architekturentscheidung ist. Testen Sie, ob die Entscheidung schwierig zurückzunehmen ist, und/oder das Ergebnis selbst starken Einfluss auf spätere Entscheidungen hat!

Die beschriebenen Einflussfaktoren grenzen die Fragestellung nicht völlig ein, sondern lassen Ihnen Entscheidungsspielraum. Sie treffen Annahmen, welche die möglichen Optionen weiter reduzieren oder sich auf die Bewertung der Optionen auswirken. Im Grunde wird jede Architekturentscheidung unter gewissen (oft impliziten) Annahmen getroffen. Teilweise im Dunkeln, wie Phillip Kruchten so schön sagt:

The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.

Philippe Kruchten

Annahmen zählen zu den Dingen, die im Nachhinein beinahe unmöglich zu rekonstruieren sind. Halten Sie sie fest!

Doch nun zu unserem Serienstar! Und zum Schnipsel dieser Folge: Eine Architekturentscheidung von Gradle, dargestellt in der vorgeschlagenen Struktur.

– – – 8< – – –

Schnipsel #5 (Architekturentscheidung): Eine zentrale Entscheidung von  Gradle

In welchem Form werden Buildskripte verfasst?

Der Build-Manager beschreibt den projektspezifischen Build, d.h. die von Gradle zu verabeitenden Daten und Dateien, die nötigen Verarbeitungsschritte inkl. der Abhängigkeiten, die Ergebnisse des Builds, … . Dieses sogenannte Build-Skript ist sein wichtigstes Kommunikationsmittel mit dem Build-System, zudem teilt er es mit den beteiligten Entwicklern. In welcher Form wird es verfasst?  Verschiedene Build-Lösungen (etwa make, Maven, Rake) wählen sehr unterschiedliche Formate. Grundsätzlich lassen sich strukturierte Datenformate, etwa XML oder JSON,  und ausführbare Skripte, etwa formuliert in einer Skriptsprache, unterscheiden. Form und Format haben großen Einfluss auf die Akzeptanz von Gradle. Und würden Form und/oder Format im Rahmen der Gradle-Weiterentwicklung grundlegend geändert, müssten bestehende Gradle-Builds migriert werden, entwickelte Erweiterungen vermutlich ebenfalls angepasst. Die Antwort auf diese Fagestellung entscheidet schlussendlich über Erfolg und Misserfolg des Build-Systems.

Einflussfaktoren

Puzzleteil als PDF

Bei der Entscheidung ist zu beachten, dass Gradle als JVM-basiertes Build-System konzipiert ist. Weiterhin unterliegt es der Apache Apache License 2.0. Ausserdem sollte das Risiko im Auge behalten werden, dass das ausgewählte Format und/oder die verwendete Technologie langfristig an Akzeptanz verlieren könnte. Folgende Qualitätsziele sind bei der Entscheidung maßgeblich:

  • Erweiterbarkeit (die Wahl des Formates fördert das Hinzufügen neuer Funktionalität zu Gradle)
  • Erlernbarkeit (das Format ist für die Hauptzielgruppen leicht zugänglich)
  • Skalierbarkeit (auch umfangreiche Projekte lassen sich mit den Build-Skripten leicht beschreiben)

Annahmen

Wir nehmen an, dass die Akzeptanz von XML als Datenformat in der Java-Gemeinde generell abnimmt. Groovy bleibt auf lange Sicht am Markt relevant. Buildmanager sind bereit eine neue Skriptsprache zu lernen. Die Freiheiten, die durch ausführbare Skripte im Build entstehen, werden akzeptiert, und nicht als Gefahr gesehen.

Betrachtete Alternativen

Grundsätzlich lässt sich zwischen strukturierten Datenformaten (z.B. XML) und ausführbaren Skripten unterscheiden, auch ein Mix ist denkbar.

Für Dateiformate wie XML und JSON sprechen der bestehender Tool-Support (Editoren in IDEs, Parser) und im Falle von XML gute Validierungsmöglichkeiten (Stichwort: Schema). Die Erfahrung mit Ant und Maven hat allerdings gezeigt, dass XML-basierte Skripte – zumindest wie dort verwendet – einfache adhoc-Aufgaben (z.B. Fallunterscheidungen) erschweren. Auch für Kleinigkeiten ist die Programmierung von Plugins erforderlich.

Ein reines Skript (also ein direkt in einem Skriptsprache formuliertes Programm) könnte ebenfalls vom vorhandenen Tool-Support profitieren. Aber diese Form erschwert es die nötigen Inhalte (z.B. Abhängigkeiten zwischen Taks) ausdrucksstark zu formulieren. Deshalb wird dieser Ansatz nicht verfolgt.

Ziel ist daher eine Skriptform, die deskriptiv ist (also die Elemente des Build beschreibt), und gleichzeitig ausführbare Elemente beinhalten kann.

Auszuwählen ist dann noch die zu verwendende Sprache. Ein klares Bekenntnis für eine Sprache sorgt für Orientierung, und erleichtert vieles. Der Ansatz, mehrere Sprachen zu untertützen (JSR 223, Scripting for the Java TM Platform), und die Wahl dem Buildmanager zu überlassen, wird daher nicht verfolgt.

Als Kandidaten kommen auf der JVM verfügbare Skriptsprachen in Frage, z.B.:

SpracheTIOBERedMonkauf JVM (Lizenz)Erlernbarkeit (*)
Groovy#47#18Groovy (Apache License 2.0)Sehr leicht
JavaScript#10#2Rhino (Mozilla Public License)mittel
Python#8#4Jython (Python Software Foundation License)leicht
Ruby#13#5JRuby (CPL, GPL und LGPL)mittel

Der TIOBE-Index (Stand hier: Dezember 2013) und das RedMonk Programming Language Ranking (Stand hier: Juni 2013) sind Versuche, die Popularität und Verbreitung von Programmiersprachen über die Zeit zu beobachten, und zu messen.

(*) Die Einschätzung bezieht sich ausschließlich auf die Erlernbarkeit für Java Entwickler und ist subjektiv.

Entscheidung

Gradle-Buildskripte basieren auf Groovy.

Das Hauptargument für Groovy ist die betont einfache Erlernbarkeit für Entwickler mit Java-Background. Weiterhin ermöglichen die DSL-Features von Groovy deskriptive Build-Skripte und eine gute Erweiterbarkeit.

Auch wenn das RedMonk Ranking nicht allgemein anerkannt ist, und der TIOBE-Index sogar häufig in der Kritik steht – die Zahlen weisen daraufhin, dass Groovy verglichen mit den anderen Optionen wenig(er) verbreitet ist. Die Wahl fiel trotzdem auf Groovy, die leichte Erlernbarkeit wurde höher bewertet.

JavaScript ist für Java-Entwickler weniger zugänglich, und hatte zum Zeitpunkt der Entscheidung (vor 2009) noch nicht die Relevanz und Akzeptanz in der Java-Welt wie heute. Für JavaScript spräche allerdings, dass es in der Java SE mitgeliefert wird (ab Java Version 6), die Lizenz wäre daher kein echtes Hindernis.

Die Art und Weise, wie Build-Skripte in Groovy grundsätzlich aufgebaut sind, wird in einem separaten Konzept beschrieben.

– – – >8 – – –

An dieser Stelle sei noch bemerkt, dass natürlich nicht ich die Entscheidung getroffen habe, und ich auch nicht im Detail weiss, ob sie in der Form wie oben dargestellt bearbeitet wurde. Sie ist ein Beispiel, wie Sie eine Architekturentscheidung nachvollziehbar darstellen, und auch abgesicherern können.

Wie verwenden Sie die Struktur?

Die Struktur ist zur Ablage von Ideen in Workshops geeignet, und später zur Gliederung beim Festhalten. Auch wenn die fünf Punkte eine sinnvolle Reihenfolge zur Bearbeitung vorgeben — hangeln Sie sich nicht zu sklavisch daran entlang. Oft fallen Ihnen auf dem Weg Dinge ein, die in der Struktur eher nach vorne gehören. Wenn Sie beispielsweise Alternativen bewerten, treffen Sie ggf. Annahmen und entdecken weitere Einflussfaktoren.

Wo kleben wir den Schnipsel hin?

Architekturentscheidungen finden in arc42 in Abschnitt 9 („Entwurfsentscheidungen“) ihren Platz. Pro Entscheidung ist ein Unterabschnitt vorgesehen. Mein Vorschlag mit der oben gezeigten Struktur pro Entscheidung ist mittlerweile in arc42 eingeflossen (vgl. arc42-Template), worauf ich ein bisschen stolz bin. Die generischen Überschriften „Entwurfsentscheidung 1“, „Entwurfsentscheidung 2“, … tauschen Sie gegen aussagekräftige Titel aus, um die Benutzbarkeit des Inhaltsverzeichnisses zu erhöhen. Ich persönliche empfinde die Fragestellung der Entscheidung (z.B. „In welchem Form werden Buildskripte verfasst?“) als Titel sehr lebendig.

Abheften des Schnipsel #5 in arc42

Im 4. Abschnitt („Lösungsstrategie“) greifen Sie typischerweise vor und nennen bereits zentrale Entscheidungen, die Sie in Abschnitt 9 ausführlicher darstellen. Weisen Sie in Ihrer Strategie auf die genauere Begründung hin, ggf. (je nach Werkzeug) per Link.

Noch mehr Entscheidungen?

Im Rahmen eines Architekturüberblicks halte ich nur wenige, zentrale Archtekturentscheidungen in der vorgeschlagenen Form fest. Abschnitt #9 ist nicht der einzige Platz in arc42, in dem sich Entscheidungen niederschlagen. Strukturentscheidungen landen typischerweise in der Bausteinsicht (siehe Schnipsel #4), Verteilungsaspekte in der Verteilungssicht, usw. Und oft wird eine Architekturentscheidung in einem technischen oder übergreifenden Konzept weiter verfeinert.

Zum Weiterlesen

Ausblick

Den fünften Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben können Sie hier herunterladen. 😉

In der nächsten Folge werde ich mich einer stiefmütterlich behandelten Zutat widmen: dem Glossar. Und zeigen, dass Sie sowas peppiger aufziehen können als mit einer schnöden Tabelle. Neugierig? Dann lesen wir uns im neuen Jahr wieder! Eine frohe Weihnachtszeit und einen guten Start in 2014!

Leanpub: arc42-Starschnitt Gradle Ein Architekturüberblick in Lebensgröße.

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.

Zum arc42-Starschnitt

Beitragsbild_admin-ajax

arc42-Starschnitt: Gradle. Schnipsel Nr. 4: Bausteinsicht

By | Inhaltliches, Kolumne

Nachdem ich im zweiten Teil dieser Serie mit der Kontextbetrachtung (siehe Schnipsel #2) bereits eine Blackboxsicht des zu beschreibenden Systems vorgestellt habe, zoomen wir in dieser Folge hinein. Die Bausteinsicht zeigt die Struktur der Lösung, also ihre Bestandteile, und wie diese zusammenhängen.

Also wieder: Schere raus und losgeschnippelt …

Abflug Terminal 2

Im Taxi auf dem Weg zum Flughafen die unvermeidliche Frage: „Mit welcher Linie fliegen Sie?“ Eigentlich interessiert den Fahrer das nicht. Tatsächlich will er wissen, zu welchem Terminal er fahren muss. „Lufthansa.“. „Ah, das ist Abflug Terminal 2“. Der Taxifahrer — im Gegensatz zu vielen seiner Fahrgäste — weiß nämlich, dass Terminal 2 für die Lufthansa verantwortlich ist.

Flughafen Hamburg

Große Flughäfen sind verblüffend komplex. Zu den klassischen Mitteln, um mit Komplexität umzugehen, zählen Zerlegung und Hierarchiebildung. So gibt es in einem Flughafen unterschiedliche Bereiche. Die Terminals zum Beispiel, London Heathrow hat gleich fünf. Die Strukturierung ist schon deswegen nötig, um Fluggästen und anderen Menschen Orientierung zu geben, aber etwa auch um die Sicherheit zu gewährleisten. So wird unterschieden in Abflug und Ankunft, Shoppen, Speisen, Lounges …

Die Zerlegung eines Flughafens in Teile braucht dabei nicht streng hierarchisch erfolgen. Die Gliederung in Terminal 1, 2, …, in Abflug- und Ankunftsbereich oder sicherheitskritisch und nicht sicherheitskritisch sind unterschiedliche Ordnungsprinzipien, eine Gepäckabfertigung kann es sowohl in Terminal 1 als auch in Terminal 2 geben, Gates werden gern nach Buchstaben A, B, … gruppiert usw.

Teile und herrsche!

Puzzleteil als PDF

Softwaresysteme sind ebenfalls komplexe Gebilde. Die klassischen Mittel, um mit Komplexität umzugehen, kommen auch hier zum Einsatz. Die Motivation, ein Softwaresystem in Teile zu zerlegen, kann organisatorisch motiviert sein. Verschiedene Teams arbeiten unabhängig voneinander an Teilen des Gesamtsystems, oder bestimmte Teile sollen im weiteren Verlauf projektübergreifend wiederverwendet werden oder unabhängig voneinander vermarktbar sein. Es kann auch technisch motiviert sein, etwa wenn die Oberfläche leicht austauschbar sein soll. Das führt oft zu Schichten, einem weiterem Ordnungsprinzip neben fachlich motivierten Teilsystemen.

Früher wurde Softwarearchitektur sogar gern mit Struktur gleichgesetzt. Moderne Aufassungen sind da offener, wie etwa Martin Fowler in „Who Needs an Architect?“ schreibt:

Architecture is about the important stuff. Whatever that is.

Martin Fowler

Doch die Strukturierung der Lösung wird schnell wichtig, es sei denn Qualitätsmerkmale wie Wartbarkeit, Austauschbarkeit etc. sind für die Lösung völlig irrelevant (siehe Qualitätsziele in Schnipsel #3). In solch seltenen Fällen tut es auch ein Monolith oder eine große Matschkugel (Big Ball of Mud).

Die Zerlegung, orientiert an Prinzipien wie Seperation of concerns (Verantwortlichkeitsprinzip) und Information hiding (Geheimnisprinzip), nimmt großen Raum im Entwurf ein. Und die Bausteinsicht ist das zentrale Ergebnis, um betreffende Entscheidungen festzuhalten. Und um später Orientierung zu geben, etwa für neue Teammitglieder.

Bilder statt Worte

Mit einem Plan auf dem Flughafen in Hamburg

Wer sich auf einem Flughafen zurechtfinden will orientiert sich an der Beschilderung oder schaut auf einen Plan. Bestimmte Dinge lassen sich mit Bildern leichter kommunizieren als mit Text allein. Innerhalb eines großen Softwaresystems lässt sich die Option der Beschilderung nur bedingt realisieren („Wo geht es hier zur Persistenz?“). Bildhafte Pläne von der Software anzufertigen, um Orientierung zu geben, geht natürlich schon.

Software zu visualisieren ist daher sehr üblich. Ebenfalls sehr üblich ist es, Aspekte zu trennen, und nicht alles in ein Bild zu zwängen. In der Softwarearchitektur hat sich hierfür das Konzept der Sichten (engl. „Views“) etabliert. arc42 schlägt verschiedene Sichten vor, mit der Kontextabgrenzung (auch Kontextsicht) haben wir in Schnipsel #2 bereits eine kennen gelernt. Ausgehend von der Kontextsicht zeigt die Bausteinsicht die Zerlegung des Systems in Teile, und wie diese Teile zusammenhängen.

Schematische Ebenen der Bausteinsicht

Eine Bausteinsicht für Gradle

Auf Basis des Quelltextes von Gradle (Open Source) habe ich eine grobe Bausteinsicht angefertigt. Die Software wird selbst mit Gradle gebaut und besteht aus über 40 Subprojekten. Eine Bausteinsicht mit 40 Bestandteilen auf Ebene 1 würde wenig Orientierung geben und Neulinge eher abschrecken (vgl. Prinzip 7+/-2). Ich habe die Subprojekte daher in zwei Ebenen zu größeren logischen Teilen zusammengefasst, und die Abhängikeiten mit Metainformationen aus den Build-Skripten und statischer Code-Analyse herausgearbeitet. Der folgende Schnipsel stellt überblicksartig einen Ausschnitt der Sicht dar, konkret Ebene 1 und für ein Subsystem auch Ebene 2.

– – – 8< – – –

Schnipsel #4 (Bausteinsicht): Bestandteile von  Gradle

Ebene 1

Gradle lässt sich in 4 grobe Blöcke („Subsysteme“) zergliedern. Das folgende Diagramm zeigt sie mit ihrer Interaktion untereinander und mit außen, die gestrichelten Pfeile stellen Abhängigkeiten zwischen Subsystemen bzw. Verwendungen dar.

Bausteinsicht, Ebene 1

Die folgende Tabelle gibt einen Überblick über die Verantwortlichkeiten der einzelnen Subsysteme.

SubsystemKurzbeschreibung
ClientsGradle stellt Verwendern seine Funktionalität auf verschiedene Weise bereit. Kommandozeile, einfache graphische Oberfläche, Integration in Entwicklungsumgebungen und CI-Server …
Core Build SystemDer Kern von Gradle umfasst die Basisfunktionalität (Interpretation von Skripten, Abhängigkeitsmanagement, Ausführung von Tasks, Java-Unterstützung …) sowie das Plugin-Konzept als Erweiterungspunkt.
Tool IntegrationPlugins, die Werkzeuge anderer Projekte integrieren, etwa zur Qualitätssicherung, zur Veröffentlichung von Artefekten in Repositories, etc.
Language SupportPlugins zur Unterstütztung weiterer Programmiersprachen neben Java (Scala, JavaScript, …)

Ebene 2 (Subsystem „Clients“)

Das folgende Diagramm zerlegt das Clients-Subsystem weiter in fachlich motivierte Module. Sie hängen alle von Teilen des Core Build System ab, die betreffenden Pfeile sind im Diagramm der Übersicht halber aber weggelassen.

Bausteinsicht, Ebene 2, Clients
ModulKurzbeschreibungGradle Sub-Projekt(e)
LauncherInteraktion mit Gradle klassisch über Kommandozeile, oder alternativ mit einer graphischen Oberfläche.launcher, ui
Gradle Tooling APIAPI, um Gradle in andere Werkzeuge einzubetten. Hierzu zählen Entwicklungsumgebungen, Continuous Integration Server, graphische Benutzeroberflächen …tooling-api
IDE IntegrationUnterstützung für integrierte Entwicklungsumgebungen, konkret etwa Eclipse und IDEAide
Gradle WrapperDer Wrapper ermöglicht die Verwendung von Gradle, ohne dass es dafür installiert sein muss. Interessant z.B. für Open Source Projekte, welche die Hürde für das Übersetzen ihrer Quelltexte senken wollen.wrapper

– – – >8 – – –

Weitere Details?

Die Darstellung oben im Schnipsel stellt aus meiner Sicht das Minimum für einen Architekturüberblick dar: Diagramme mit erläuternden Texten, und eine kurze Darstellung der jeweiligen Verantwortlichkeit jedes gezeigten Bausteins. Eine detaillierte Architekturbeschreibung würde zum einen tiefer hineinzoomen, zum anderen mehr Details zu den Bausteinen zeigen, etwa deren Schnittstellen. Im arc42-Template ist ein Vorschlag für entsprechende Inhalte enthalten (Blackbox-Template, Whitebox-Template).

Wo und wie tief Sie tatsächlich hineinzoomen, machen Sie an den Zielgruppen Ihrer Dokumentation fest, und an deren Interessen. Jemand, der einen Flughafen bauen soll, benötigt mehr und andere Details als jemand, der später einen Fluggast abholt. Eine Bausteinsicht mit gleichem Abstraktionsniveau wie der Quelltext macht in der Regel keinen Sinn, sie aktuell zu halten hingegen viel Arbeit.

Wenn Sie beim Hineinzoomen also an einer Stelle abbrechen, geben Sie dort Hinweise, wo es weiter geht. Ab einem bestimmten Punkt wird es immer erforderlich sich, im Quelltext nachzuschauen. Machen Sie den interessierten Lesern Ihrer Dokumentation den Weg dahin nicht zu schwer! Im Beispiel oben sind zur Illustration in der Ebene 2 des Clients-Subsystem die betreffenden Gradle Subprojekte vermerkt, inkl. Link zum Quelltext in der Versionskontrolle.

Muss es immer UML sein?

Die Diagramme im Schnipsel oben sind in UML (Unified Modeling Language) notiert. Wer UML wählt, um Architekturbilder anzufertigen, steht selten in der Kritik. Macht man ja halt so. Ist standardisiert, kann jeder lesen. Tatsächlich können UML meiner Erfahrung nach bei weitem nicht alle Zielgruppen einer Architekturdokumentation lesen. Zumindest wenn etwas originellere Diagramme und Modellelemente verwendet werden. Da Dokumentation die Kommunikation eigentlich unterstützen soll, kann das ein echtes Problem werden. Gerade überblicksartige Darstellungen sollen den Einstieg erleichtern. Wenn das das Ziel Ihrer Diagramme ist, lassen Sie sich lieber von Flughafenplänen inspirieren als von der UML-Spezifikation.

Diagramme auf dem Niveau grober Bausteinsichten erfordern eigentlich kein UML. Tatsächlich tun es die berühmten Kästchen und Striche hier oft auch; vorausgesetzt Sie erklären Ihre Notation in einer Legende. Da bei UML die Diagramme Sichten auf ein einheitliches Modell sind, ist die größte Stärke die Konsistenz der Bilder — Verwendung eines Modellierungswerkzeugs vorausgesetzt. Wenn ein Baustein an einer Stelle umgenannt wird, erscheint der neue Name automatisch in allen Diagrammen der Bausteinsicht, und auch in anderen Sichten. Das ist aus meiner Sicht (wenn überhaupt) das entscheidende Argument für UML. Zielgruppengerechte UML-Diagramme erhalten Sie oft durch eine betont kleine Anzahl unterschiedlicher Modellelemente, die sich dann auch leicht erklären lassen. Die Beschriftung „Legende: UML“ hilft niemandem.

Wo kleben wir den Schnipsel hin?

Die Bausteinsicht hat ihren festen Platz in arc42, und zwar in Abschnitt 5 (siehe Abbildung unten). Die Gliederung sieht Unterkapitel 5.1, 5.2, … für die verschiedenen Ebenen vor. Hier könnte man auch anders strukturieren, beispielsweise direkt nach Subsystemen. Im Fall des Gradle-Beispiels also etwa „5.1 Clients“, „5.2 Core Build System“, …

Die von arc42 vorgeschlagene Gliederung hat den Vorteil, dass der Text beim sequentiellen Lesen nach hinten immer spezieller wird. Wer nur einen groben Überblick benötigt, braucht nicht viel hin- und herblättern; er bricht einfach bei Bedarf irgendwann ab.

Schnipsel #4 abheften in arc42

Zum Weiterlesen

  • Die Bausteinsicht ist auch ein Dokumentationsmittel in meinem Buch Softwarearchitekturen dokumentieren und kommunizieren. Eines der Fallbeispiele des Buches, eine Schach-Engine, ist online verfügbar und besitzt ebenfalls eine Bausteinsicht: Bausteinsicht DokChess
  • 7 +/- 2: George A. Miller macht in seinem Artikel „The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information“ indirekt Reklame dafür, nicht zuviele Elemente auf einer Ebene der Bausteinsicht zu zeigen. Wikipedia: Millersche Zahl
  • arc42 schlägt Templates zur Blackbox- und Whiteboxsicht von Bausteinen vor.

Ausblick

Den vierten Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben können Sie hier herunterladen. 😉

Neben der Bausteinsicht und der Kontextsicht schlägt arc42 weitere Sichten vor, die ich später noch vorstellen werde. Im nächsten Schnipsel geht es aber um Architekturentscheidungen, und wie man sie nachvollziehbar festhält.  Das sind genau die Entscheidungen, die, wenn falsch getroffen, Ihr Projekt zum Scheitern bringen können. Also Drama pur — Ich kann Ihnen eine spannende Folge und interessante Einsichten zu Gradle versprechen …

Leanpub: arc42-Starschnitt Gradle Ein Architekturüberblick in Lebensgröße.

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.

Zum arc42-Starschnitt

Beitragsbild_admin-ajax

arc42-Starschnitt: Gradle. Schnipsel Nr. 3: Qualitätsziele

By | Inhaltliches, Kolumne

Nach Produktkarton und Systemkontext hier nun der dritte Schnipsel meines arc42-Starschnitts zu Gradle. Dieses mal geht es um Qualitätsziele. Als Synonym dafür ist „Architekturziele“ gebräuchlich. Das unterstreicht ihre Bedeutung als Einflussfaktor auf Architekturentscheidungen (Architekturtreiber) — im Grunde sind es die wichtigsten architekturrelevanten Anforderungen.

Also wieder: Schere raus und losgeschnippelt …

arc42-Starschnitt, Schnipsel 3

Du musst Dich entscheiden …

Wer ein Programm entwirft, das Schach spielt (eine sogenannte Schach-Engine), trifft viele interessante Entscheidungen. Etwa: Wie stelle ich die aktuelle Spielsituation als Datenstruktur dar (wo stehen die Figuren auf dem Brett)? Da gibt es sehr unterschiedliche Möglichkeiten.

Läufer (Foto: Stefan Toth)

Naheliegend ist ein zweidimensionales Array mit 8 Zeilen und 8 Spalten für die 64 Felder, in dem jeweils die Figur gespeichert ist, die auf dem Feld steht. Man kann alternativ auch ausnutzen, dass ein long 64 Bit hat. Jedes Bit repräsentiert dann ein Feld, und wir kreuzen in einer long-Variablen an, wo die weißen Bauern stehen. Das selbe machen wir mit einer weiteren long-Variable für die schwarzen Bauern. Im Schach gibt es sechs Figurenarten und zwei Farben. Also 12 long-Variablen, und alles ist gespeichert. Das Ganze ist sehr effizient. Man kann beispielsweise durch bitweises Verodern leicht die freien Felder ermitteln, oder die Felder, wo der Gegner steht. Dafür ist es recht kompliziert zu implementieren, wie die Figuren laufen. Zumindest verglichen mit dem 2-dimensionalen Array, wo man direkt mit den Koordinaten arbeiten kann.

Was nehmen wir? Wenn Effizienz entscheidend ist, wohl die Bit-Darstellung. Wir nehmen in Kauf, dass der Quelltext für die Gangarten der Figuren schwieriger zu verstehen und damit zu warten ist. Wenn wir uns eine neue Figur ausdenken, und deswegen auf 10 x 10 Feldern spielen wollen, ist das bei der Array-Varriante leicht zu ändern. Die Bit-Darstellung ist hier weniger flexibel. Tatsächlich müssen wir verstehen, ob in dieser Situation eher Effizienz oder Wartbarkeit gefragt ist. Ein typisches Paar von sogenannten Qualitätsmerkmalen, die sich hier wechselseitig beinflussen, und ausbalanciert werden müssen.

Wartbarkeit <=> Effizienz

Alternatives Schach. Neue Regeln für das Spiel der Könige

Nun kann man leicht argumentieren, dass die Schachregeln wohl recht stabil sind, und nicht unbedingt damit zu rechnen ist, dass das Spielbrett vergrößert werden muss. Es könnte aber auch andere Anforderungen im Bereich Wartbarkeit geben, etwa dass Algorithmen leicht austauschbar seien sollen. Oder dass tatsächlich alternative Schachregeln leicht umgesetzt werden können. Wie wäre es mit Schach 960, Räuber-Schach, Zombie-Schach, Atom-Schach …? (siehe Buchtipp rechts).

Wollen wir mit unserer Lösung im Computerschach ganz vorne mitspielen oder eine Plattform zum Experimentieren mit Spielregeln und/oder Algorithmen schaffen? Hier gilt es Klarheit zu schaffen und die Qualitätsmerkmale zu priorisieren.

Wenn es um Weltmeisterschaften geht, ist Stefan Meyer-Kahlen der richtige Ansprechpartner. Sein Programm Shredder holte bisher 17 Weltmeistertitel in unterschiedlichen Kategorien des Computerschach, den letzten 2013 in Yokohama. Aus meinem persönlichen Austausch mit ihm:

Bei Shredder ist die Effizienz klar im Vordergrund, die Wartbarkeit des Quelltextes muss da leider manchmal hinten anstehen.

Stefan Meyer-Kahlen (Autor von Shredder)

Von Heiten, Keiten, Täten

Die unterschiedliche Beinflussung von Wartbarkeit und Effizienz je nach Wahl der Alternative für konkrete Fragestellungen ist ein typisches Beispiel, aber bei weitem nicht das einzige. Ein weiteres „Klassikerpaar“ sind Sicherheit und Benutzbarkeit. Regelmäßig können Sie eine Entscheidung nicht treffen oder bewerten, wenn Sie nicht die geforderten Qualitätsmerkmale kennen. Diese Merkmale neigen übrigens dazu, im Deutschen auf -heit, -keit oder -tät zu enden. Die Tagcloud unten zeigt Qualitätsmerkmale, wie sie auch in der ISO/IEC 9126, einem Modell zur Softwarequalität, beschrieben sind.

Qualitätsmerkmale, Quelle: www.wordle.net

Die wichtigsten geforderten Qualitätsmerkmale für ein Softwaresystem heißen Qualitätsziele. Typischerweise werden als Qualitätsziele im Rahmen eines Architekturüberblicks die Top-3 bis Top-5 genannt, und es wird versucht, diese zu priorisieren. Also das oberste Ziel vorn an zu stellen usw.

Im Idealfall nennt ein Architekturüberblick die Ziele aber nicht nur, er motiviert sie auch. Also nicht „Performance ist superwichtig“, sondern auch, was genau mit Performance in der konkreten Aufgabenstellung gemeint ist (Zeitverhalten, Verbrauchsverhalten, …), und warum es eine so entscheidene Rolle spielt.

Das folgende Beispiel illustriert dies wieder an unserem Serienstar Gradle.

– – – 8< – – –

Schnipsel #3 (Qualitätsziele): Qualitätsziele von  Gradle

Die folgende Tabelle beschreibt die zentralen Qualitätsziele von Gradle, wobei die Reihenfolge eine grobe Orientierung bezüglich der Wichtigkeit vorgibt.

QualitätsmerkmalZiel
———————–———————–
ErweiterbarkeitGradle lässt sich leicht um neue Funktionalität erweitern. Es kann auf lange Sicht dem technologischen Fortschritt bei Tools und Entwicklungsmethodik folgen.
 ————————————
EffizienzTeams und einzelne Entwickler erhalten durch kurze Buildzeiten schnelle Rückmeldungen; Gradle steigert so ihre Produktivität.
————————————
InteroperabilitätGradle arbeitet mit bestehenden Werkzeugen wie Ant und Maven und deren Öko-Systemen nahtlos zusammen.
————————————
ErlernbarkeitEntwickler und Buildmanager finden sich schnell in Gradle zurecht, der Einstieg und das Erstellen erster Build-Skripte fallen ihnen leicht.
————————————
InstallierbarkeitDer Aufwand, der zum Installieren von Gradle notwendig ist, um einen Build auszuführen ist, sehr gering.
————————————
SkalierbarkeitGradle bleibt auch bei sehr umfangreichen Builds und in Multi-Projekt-Szenarien handhabbar und effizient.
————————————

– – – >8 – – –

Wie Qualitätsziele erstellen?

Welches die richtigen Qualitätsziele sind, entscheiden die maßgeblichen Stakeholder. Sichern Sie ab, dass die Stakeholder sowohl die Ziele als auch deren Priorisierung akzeptiern.

Als Form für die Zutat hat sich eine Tabelle mit zwei Spalten (Qualitätsmerkmal, Ziel/kurze Erläuterung)  bewährt. Nicht nur die bloße Nennung („Gefordert sind Benutzbarkeit, Performance und Sicherheit“), sondern das Herausstellen und Motivieren der wichtigsten ca. 3-5 Merkmale. Es besteht insbesondere nicht der Anspruch, alle geforderten Qualitätsmerkmale zu nennen, sondern wirklich auf die zentralen zu fokussieren.

Zum Inhalt: Achten Sie darauf, dass die Qualitätziele zu den Inhalten des virtuellen Produktkartons (vgl. Schnipsel #1) passen. Jedes der Ziele muss für alle Beteiligten ausreichend motiviert sind. Stellen Sie in der Auflistung eine sinnvolle Reihenfolge der Ziele her (das Wichtigste zuerst, wenn möglich fachlich gruppiert).

Wenn Sie ein bestehendes Systems nachdokumentieren, macht es einen Unterschied, ob Sie den Istzustand beschreiben („Welche Ziele erreichen wir jetzt mit unserer Lösung gut?“), das ursprüngliche Soll („Welche Ziele wollten wir erreichen, als wir gestartet sind?“) oder zukünftige Ziele („Wo wollen wir mit der Weiterentwicklung hin?“). Alles drei kann je nach Situation sinnvoll sein, seien Sie sich aber bewusst, was Sie tun und vermischen Sie das nicht kommentarlos in einer Liste.

Geht es noch ein bisschen genauer?

Qualitätsziele geben Orientierung für den Architekturentwurf  und lenken die Entscheidungen in eine Richtung.Im Architekturüberblick nehmen sie einen prominenten Platz ein, da sie ein wichtiger Aufhänger sind um die Architektur nachvollziehbar zu machen.

Im konkreten Fall sind Qualitätsziele aber oft nicht genau genug, um im Architekturentwurf Alternativen sicher gegeneinander abzuwägen, angemessene Kompromisse zu finden und die Qualitätsmerkmale so auszubalancieren. Hier sind Qualitätsszenarien ein interessantes Werkzeug, um Qualitätsziele zu konkretisieren. Ich behandele sie in einem späteren Schnipsel dieser Serie.

Wo kleben wir den Schnipsel hin?

Qualitätsziele haben ihren festen Platz in arc42, und zwar in Abschnitt 1 „Einführung und Ziele“ in Unterabschnitt 1.2, siehe Abbildung unten.

Schnipsel #3 abheften in arc42

Und auch im begleitenden Text zur arc42-Vorlage wird ihre Bedeutung deutlich betont.

Beginnen Sie NIEMALS mit einer Architekturentwicklung, wenn diese Ziele nicht schriftlich festgelegt und von den maßgeblichen Stakeholdern akzeptiert sind.

(aus der Vorlage zu arc42)

Zum Weiterlesen

  • Qualiätsziele sind auch ein Dokumentationsmittel in meinem Buch Softwarearchitekturen dokumentieren und kommunizieren. Eines der Fallbeispiele des Buches, eine Schach-Engine,  ist online verfügbar und besitzt ebenfalls Qualitätsziele: Qualitätsziele DokChess
  • „Ein Bitboard (Bitmap Board) ist eine Datenstruktur, die häufig Verwendung in Computerprogrammen für Brettspiele findet, insbesondere bei Schachprogrammen.“ (weiter bei Wikipedia zur Bitboards)

Ausblick

Den dritten Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben können Sie hier herunterladen. 😉

Die bisherigen Zutaten drehten sich alle vorrangig um architekturrelevante Anforderungen. In der nächsten Folge stelle ich mit der Bausteinsicht endlich auch mal eine Zutat vor, die der Lösungsecke zuzurechnen ist. Sie können dort zum Beispiel Strukturentscheidungen festhalten.

Vielen Dank an an dieser Stelle an René Gröschke (Gradleware) für seine Rückmeldungen zur Serie und auch sein Feedback zu den Gradle-Qualitätszielen bereits im Vorfeld zu dieser Folge!

Leanpub: arc42-Starschnitt Gradle Ein Architekturüberblick in Lebensgröße.

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.

Zum arc42-Starschnitt