Es geht weiter mit unserem arc42-Starschnitt/Gradle-Architekturüberblick! Letztes mal habe ich mit dem Produktkarton eine Zutat gezeigt, die herausarbeitet, worum es bei dem zu beschreibenden System (im Beispiel also Gradle) eigentlich geht (Lesen Sie hier Schnipsel #1). Bevor wir den Karton aufreissen und hineinschauen, werfen wir einen Blick auf die Umgebung — den Kontext. Mit wem interagiert Gradle? Wo nutzt es die Funktionalität anderer Werkzeuge, anstatt das Rad neu zu erfinden?

TeaserBild_Folge_2

Aber bevor es losgeht: Achten Sie beim Zusammenkleben der Schnipsel darauf, dass der Kleberand verdeckt wird. Tipp: Legen Sie die Teile erst auf einer glatten Fläche zusammen, um zu testen, ob sie passen, bevor Sie zum Klebstoff greifen!

Und jetzt wieder Schere raus …

Das System von seiner Umgebung abgrenzen

Eine Kontextbetrachtung grenzt ab, wofür das zu beschreibende System verantwortlich ist, und wofür nicht. Wer sind die Benutzer des Systems? Mit welchen Fremdsystemen interagiert es? Als Form dazu hat sich in der Praxis eine einfache Visualisierung bewährt, die das System in der Mitte als Black-Box darstellt, und die Interaktionspartner drum herum versammelt und mit dem System verbindet. Die folgende Abbildung zeigt dies schematisch am Beispiel eines einfachen Webshops.

Kontextdiagramm eines einfachen Webshops

Kontextdiagramm eines einfachen Webshops

Auch wenn manchmal weitere Symbole zum Einsatz kommen, etwa Tonnen für Datenbanken, mag ich persönlich die Unterscheidung in lediglich zwei Arten von Akteuren: Menschliche Benutzer (Symbol = Strichmännchen) und (technische) Fremd- oder Umsysteme (Symbol = Kiste). Das ist Geschmackssache, bedenken Sie aber, dass Sie jedes Symbol erklären (etwa in einer Legende).

Dass es sich beim hier gezeigten Bild um ein fotografiertes Flipchart handelt ist Absicht. Oft entstehen erste Würfe eines Systemkontextes in gemeinsamen Workshops an Whiteboard oder Flipchart, und werden abfotografiert. Es spricht nichts dagegen, ein solches Ergebnis direkt in einen Architekturüberblick zu übernehmen. Besser als wenn sich erst jemand finden muss, der es elektronifiziert, und wir müssen solange warten. Wenn der Systemkontext später weiter bearbeitet und z.B. verfeinert wird bietet sich die Überführung in ein entsprechendes Tool an.

Zu einem Systemkontext gehören neben dem Diagramm selbst aus meiner Sicht noch zwei Dinge zwingend dazu:

  1. Ein kurzer Text (1-3 Sätze), der dem Leser erklärt was das Diagramm zeigt und evtl. auch was absichtlich fehlt.
  2. Eine Liste (oder Tabelle) mit Kurzbeschreibungen für alle gezeigten Benutzer und Fremdsysteme

Der erste Punkt gilt eigentlich für jedes Diagramm in einem Architekturüberblick. Die wenig attraktive Alternative wäre den Betrachter rätseln zu lassen („Was will uns der Künstler sagen?“). Sie können im einführenden Text Informationen unterbringen, die man dem Diagramm allein nicht ansieht. Z.B. dass Sie sich nur auf die wichtigsten Fremdsysteme beschränken wollen, das Diagramm also nicht vollständig ist.

In der Liste mit Kurzbeschreibungen halten Sie für jeden Benutzertyp und jedes Fremdsystem in 1-2 Sätzen fest, was er oder es ist und warum Ihr System mit ihm interagiert, welche Rolle der Beteiligte also für Ihr System spielt. Gerade für Außenstehende sind die Bezeichnungen der Benutzer und Fremdsysteme allein nicht immer selbsterklärend und aussagekräftig genug.

Nun wird es aber Zeit uns endlich einen Systemkontext für unseren Serienstar Gradle anzuschauen!

– – – 8< – – –

Schnipsel #2 (Systemkontext): Kontextabgrenzung Gradle

Die Anzahl Werkzeuge, mit denen Gradle zusammenspielt, ist groß und wächst kontinuierlich durch Third-Party-Plugins. Das folgende Diagramm zeigt Gradle im Zusammenspiel mit wichtigen Akteuren (Benutzern, anderen Softwarelösungen).  Die dargestellten Fremdsysteme stellen oft Kategorien dar; in Klammern sind beispielhafte Vertreter des Werkzeugtyps notiert.

Systemkontext Gradle

Im Folgenden werden die gezeigten Benutzer und Fremdsysteme kurz erläutert:

  • Buildmanager erstellen Build-Skripte für ihre Projekte, testen diese und stellen sie dem Team (und ggf. auch Entwicklern außerhalb ihres Teams) bereit.
  • Konfigurationsmanager legen Konfigurationen für die zu erstellenden Artefakte fest und integrieren Informationen über die für den Build benötige IT-Infrastruktur (beispielsweise das VCS) als Konfiguration in den Gradle-Build.
  • Entwickler erstellen die Softwarelösung und tragen so zum Build bei. Für ihre Arbeit werten sie Build-Ergebnisse (zum Beispiel Test-Berichte) aus und nutzen aus dem Build resultierenden Artefakte (Binaries, Dokumentation, …). Dazu führen sie Tasks des Gradle-Builds aus.
  • Releasemanager planen und testen Releases und rollen diese auf unterschiedliche Umgebungen aus. Gradle unterstützt sie bei diesen Aufgaben, Releasemanager führen hierzu Tasks des Gradle-Builds aus.
  • Continous Integration Server (siehe Wikipedia: Continous Integration) können Builds mit Gradle anstoßen, etwa aufgrund eines Check-Ins in der Versionsverwaltung oder zeitgesteuert (z.B. Nightly Build).
  • Android SDK: Das SDK (Software Development Kit) für Googles Betriebssystem und Plattform für mobile Geräte setzt auf Gradle als Build-System für Android-Applikationen.
  • Repository: Gradle verwendet Repositories um Abhängigkeiten, die für den Build erforderlich sind, aufzulösen, und die entsprechende Artefakte zu beziehen („Download“). Umgekehrt können Ergebnisse eines Builds in Repositories veröffentlicht werden („Upload“ oder „Publish“).
  • Test Execution: Gradle stößt Tests auf unterschiedlichen Ebenen (Unit-Test, Integrationstest, …) an und stellt die Resultate bereit. Dabei werden verschiedene Lösungen/Frameworks zur Realisierung der Tests unterstützt.
  • Code Quality Tool: Gradle bindet verschiedene Werkzeuge zur statischen und dynamischen Analyse des Quelltextes bzw. des Kompilats ein, und stellt deren Berichte bereit.
  • Compiler übersetzen Quelltexte in ausführbaren (Zwischen-)Code; Gradle bietet Unterstützung für verschiedene Programmiersprachen Out-of-the-box, weitere über Plugins von anderer Seite.
  • VCS: Gradle kann verschiedene Versionsverwaltungssysteme (VCS = Version control system) ansprechen, um beispielsweise im Rahmen eines Release ein Tag zu setzen.
  • IDE: Gradle lässt sich in verschiedene integrierte Entwicklungsumgebungen (IDE = Integrated development environment) einbinden, und eröffnet so eine nahtlose Benutzung für Entwickler jenseits der Kommandozeile.

– – – >8 – – –

Wozu ist der Systemkontext interessant?

Beim Systemkontext geht es in erster Linie um die Abgrenzung des betrachteten Systems gegenüber seiner Umgebung. Sie arbeiten damit heraus, für welche Funktionalität „Ihr“ System auf andere Systeme zugreift, für was es also nicht verantwortlich ist. So ist Gradle beispielsweise selbst kein Continous Integration Server, es interagiert mit ihnen. Das Android SDK ist nicht Teil von Gradle, aber ein wichtiger Nutzer.

Aus Sicht der Architekturdokumentation bietet der Systemkontext einen guten Einstieg ins System. Gerade neuen Mitarbeitern im Team lässt sich damit prima erklären, für wen das System da ist (z.B. für die Benutzer). Der Systemkontext ergänzt den Produktkarton, der darauf fokussiert, wozu das System da ist. Das Kontextdiagramm ist oft das erste Bild, was im Architekturüberblick gezeigt wird, bevor mit Hilfe anderer Diagramme, die z.B. die fachliche Zerlegung zeigen, ins System eingetaucht wird. Dazu komme ich dann noch in späteren Schnipseln (Stichwort: Bausteinsicht).Schnipsel #2

Im Rahmen einer Neuentwicklung dient der Systemkontext oft als „Fragengenerator“. So stellt sich z.B. für jeden Benutzer im Kontext die Frage, was für eine Benutzeroberfläche er enthält, und für jedes Fremdsystem, mit welchen Technologien und Protokollen es angebunden wird. Oft verbergen sich hinter diesen Schnittstellen technische Risiken und Architekturentscheidungen – Sie erinnern sich: Softwarearchitektur ist die Summe der Entscheidungen, welche im weiteren Verlauf nur schwer änderbar sind.

Kontextbetrachtungen sind übrigens auch bei der Ablösung von Altsystemen interessant.

Kann man noch mehr Informationen in das Diagramm bringen?

Oh ja! In den gezeigten Beispielen habe ich als Notation UML verwendet (was nicht wirklich wichtig ist). Die Verbindungslinien zwischen Akteuren und dem System lassen sich beschriften, informell (z.B. „Web“) oder auch mit dem verwendeten Kommunikationsprotokoll (z.B. „LDAP“).  Auch können Sie in UML Multiplizitäten an den Enden der Verbindungen anzeigen (z.B. „*“ für beliebig viele). Tun Sie dies nur, wenn es im konkreten Fall interessant ist. Weiterhin können Sie natürlich offene Fragen im Diagramm notieren, in UML beispielsweise mit Hilfe einer Notiz. Finden Sie einen Kompromiss zwischen Detailreichtum und Wartbarkeit. Ergänzungen sollten das Verständnis erhöhen, im Zweifelsfall lieber einfach!

Zielgruppe: Fachlicher vs. technischer Kontext

Im Beispiel des Webshops oben ist der Kunde als Benutzer (Strichmännchen) eingezeichnet, der über das Web mit dem Shop interagiert. Tatsächlich greift er vielleicht über einen Webbrowser zu, den man im Grunde auch als Fremdsystem auffassen und einzeichnen könnte.  Die Verbindungslinie beschriften wir dann mit dem Protokoll, also „HTTP/S“ . Was ist nun richtig?

In einem Architekturüberblick hängt es von der Zielgruppe ab. Eher fachlich Interessierte würden den Kunden im Diagramm suchen, eine technische Zielgruppe interessiert sich auch für Verbindungsspezifika wie zum Beispiel ein verwendetes Protokoll. Es gibt hier also kein richtig und falsch — Sie müssen sich für die Zielgruppe entscheiden. Wenn Sie verschiedene Zielgruppen adressieren wollen, können Sie auch mehrere Kontextabgrenzungen anfertigen. Recht gebräuchlich sind zwei: Eben gerade eine fachliche, und eine technische Kontextsicht.

Wo kleben wir den Schnipsel hin?

Anders als in der letzten Folge mit dem Produktkarton ist die Zuordnung des Schnipsels zu arc42 dieses mal einfach. Der Systemkontext hat in arc42 einen natürlichen Platz: Abschnitt 3 („Kontextabgrenzung“). Auch arc42 sieht zwei Fassungen in den entsprechenden Unterkapiteln vor („fachlich“, „technisch“). Fertigen Sie zwei an, wenn Sie unterschiedliche Aspekte herausarbeiten wollen. Im Beispiel Gradle habe ich mich dagegen entschieden. Dort gibt es nur eine Kontextsicht.

Schnipsel #2 abheften in arc42

Zum Weiterlesen

„Das Projekt verwendet eine Entsprechung zu den weißen Linien beim Tennis, um eine unstrittige Definition des Zuständigkeitsbereichs zu erhalten.“

(aus „Die weiße Linie“)

  • Folge 2 meiner Kolumne zum Thema Architekturdokumentation im Java Magazin beschäftigte sich ebenfalls mit dem Systemkontext. Online nachzulesen, auch mit einem Beispielkontext, hier:  Kombiniere — der Systemkontext

Ausblick

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

In der nächsten Folge des Starschnitts beschäftige ich mich mit den Qualitätszielen. Oft hört man Architekturziele als Synonym, was die Wichtigkeit als Zutat für den Architekturüberblick deutlich betont. Als Beispielinhalt gibt es dann auch die Qualitätsziele für Gradle. Bleiben Sie dran!

Ich hoffe Sie finden weiterhin Gefallen an dieser kleinen Serie und freue mich auf Ihre Fragen und Rückmeldungen. Kommentieren Sie einfach hier im Blog oder schreiben Sie mir (E-Mail: stefan[ät]swadok.de). Wünsche greife ich gerne in den nächsten Folgen auf, Fragen beantworte ich direkt hier.

Eine Frage, die ich von Katrin erhalten habe: Wird am Ende „nur“ das Gradle-Logo als Ergebnis aller Schnipsel der Serie dastehen? Nein, ich beabsichtige den dann aus allen Zutaten zusammengesetzten Architekturüberblick auch als Komplett-Download bereitzustellen, als ein weiteres größeres Beispiel für den Einsatz von arc42 (nicht nur lose verteilt über die Einzelfolgen hier im Blog).