Stefan Zörner
08.10.2013
Teil 2 der Blog-Serie. Wir ziehen eine Linie und grenzen ab.
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?
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 …
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.
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:
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!
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.
Im Folgenden werden die gezeigten Benutzer und Fremdsysteme kurz erläutert:
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).
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.
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!
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.
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.
“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”)
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!
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).
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.