Willkommen auf dem devlix Blog
11. November 2020
Methodische Priorisierung mit der MoSCoW-Methode
22. Februar 2021Die vier C’s der Softwarearchitektur
Die kleinen Details sind entscheidend. Durch viele kleine Dinge kann Großes entstehen.
John Wooden
Die ägyptischen Pyramiden: Im großen Kontext betrachtet ein Meisterwerk der Baukunst, im Detail betrachtet sind es bloß einzelne kleine aufeinandergesetzte Steine. Eine Software setzt sich typischerweise ebenfalls aus kleinen Einheiten zusammen. Um ein gutes Gesamtbild abzugeben, müssen die kleinen Komponenten gut miteinander harmonieren.
Viele aus der Softwarebranche kennen folgende Situation: Es werden Ideen für eine Softwarearchitektur gesammelt, darüber diskutiert, an einem Whiteboard oder einem Flipchart verschiedene Ansätze visualisiert und sich gemeinsam auf eine Architektur geeinigt. Als Protokoll der Meetings wird die visualisierte Architektur abfotografiert und in einem Wiki-Tool für die Zukunft gesichert.
Einige Wochen später fängt ein neuer Mitarbeiter in dem Projekt an und möchte sich zunächst einen groben Überblick verschaffen, um was es in der Software geht und wie diese eigentlich aufgebaut ist (es kann auch ein Mitarbeiter nach dem Urlaub/der Elternzeit oder Ähnliches sein 😉). Einfach ist diese Aufgabe nicht, denn teilweise fehlen Beschriftungen auf den Pfeilen und es werden gleiche Symbole für unterschiedliche Elemente der Architektur benutzt. Aus diesem Grund wendet sich der Mitarbeiter an den zuständigen Softwarearchitekten, welcher sich aber auch nicht mehr richtig an die einzelnen Details erinnert.
Fazit 1: Das Architekturschaubild liefert nicht von selbst die Informationen, welche für ein grundlegendes Verständnis (im besten Fall mehr als nur das) benötigt werden. Es fehlt schlichtweg ein allgemeiner Standard, um Softwarearchitekturen zu modellieren.
In einer anderen Situation benötigt eine bestehende Software ein neues Feature, welches mit Architekturänderungen verbunden ist. Durch die uneinheitliche und unklare Dokumentationsweise lassen sich die konkreten Änderungen schwer darstellen. Somit kann wertvolle Zeit verloren gehen, in der die Architektur zunächst rekonstruiert werden muss.
Fazit 2: Änderungen an der Architektur mit solch einem Dokumentationsstil sind immer mit großem Zeitaufwand verbunden.
Ein kleiner Ausflug in andere Branchen
In anderen Branchen, wie zum Beispiel in der Gebäudearchitektur oder in der Elektronik sind solche Modellierungstätigkeiten weitestgehend standardisiert. Für die einzelnen Schaltzeichen in elektrische Schaltungen existieren Normen, wie zum Beispiel die IEC 60617. Darüber hinaus existieren abstrakte Modelle für unterschiedliche Sichten auf einen Schaltplan, welche hier eingesehen werden können. Wichtig zu erwähnen ist, dass diese Modelle tatsächlich in der Praxis benutzt werden!
Es wäre doch schön, wenn Standards dieser Art für Softwarearchitekturen existieren würden. Einige wenige wichtige Anforderungen dafür wären:
- Außenstehende sollten die Architektur möglichst einfach mit einem Blick auf das Schaubild verstehen
- Verwendung von einheitlichen und simplen Begrifflichkeiten und Symbolen
- Verschiedene Sichten der Software, damit für jeden Stakeholder etwas dabei ist
Der letzte Punkt ist vergleichbar mit einer Karte, in welche man hineinzoomt (vgl. Abbildung 2). Damit können verschiedene Detailgrade der Architektur abgebildet werden. Benötigt wird dies für unterschiedliche Stakeholder der Software.
Beispielsweise benötigt ein Entwickler einen viel tieferen Einblick in die Architektur als ein Kollege aus dem Vertrieb.
Aber UML ist doch ein Standard?
Völlig richtig. UML (Unified Modelling Language) ist eine standardisierte Modellierungssprache, dessen Ziel es ist Softwaresysteme zu spezifizieren, konstruieren und zu dokumentieren. UML ist Vielen ein Begriff und einige aus der Softwarebranche hatten damit schon mal zu tun. Es lassen sich verschiedene Schaubilder mit UML abbilden. Hier eine kleine und unvollständige Auflistung (entnommen von hier)
- Verhaltensdiagramme
- Aktivitätendiagramm
- Anwendungsfalldiagramm
- Sequenzdiagramm
- Zustandsdiagramm
- …
- Strukturdiagramme
- Klassendiagramm
- Objektdiagramm
- Bereitstellungsdiagramm
- …
Eine gute Übersicht über die verschiedenen Arten von UML Diagrammen könnt Ihr hier finden.
UML ist sehr interessant und einige Diagramme sind wunderbar, um Ideen grafisch zu modellieren! Kleine Klassendiagramme, welche Design Patterns darstellen, sind gute Anwendungsfälle für ein UML Diagramm, denn Klassen, Interfaces, Vererbung, Daten und Verhalten lassen sich in UML problemlos darstellen.
Um jedoch die ganze Applikationsarchitektur mit UML zu visualisieren, müssten verschiedene Diagramme gezeichnet und zusammengebracht werden. Das kostet Zeit und kann unter Umständen bei großen Architekturen sehr verwirrend sein. Darüber hinaus können die Diagramme für Menschen ohne technischen Hintergrund eher für Verwirrung als Aufklärung sorgen, da sie nicht mit der Notation vertraut sind. Wir können und sollten UML verwenden, aber in Situationen, für die sie verwendet werden sollte: um Design Patterns und kleine Teile einer Applikation im Detail zu beschreiben.
Wie können wir dann aber Softwarearchitekturen beschreiben?
Die Lösung: Das C4-Modell
Simon Brown entwickelte 2006 eine simple und vergleichsweise einfache Möglichkeit Softwarearchitekturen zu beschreiben. Prinzipiell funktioniert das analog zur Abbildung 2 mit der Karte. Es gibt vier verschiedene „Zoom-Stufen“ (Level) der Architektur (hier erklärt sich auch der Name 😉):
- System Context
- Container
- Components
- Code
Bevor die einzelnen Level etwas näher beleuchtet werden, ist es wichtig eine gemeinsame Abstraktion zu vereinbaren. Diese wird hinterher in den Schaubildern auch konsequent wieder benutzt. Die folgende Auflistung liefert einen kurzen Überblick:
- Person: Ein Mensch oder eine Gruppe von Menschen, welche mit einem System interagiert.
- Software System: Ein Softwaresystem ist die höchste Abstraktionsebene und beschreibt etwas, das seinen Benutzern (sowohl menschlich als auch technisch) einen Wert liefert. Die zu modellierende Software und andere Systeme, von denen das Softwaresystem abhängt, gehören dazu.
- Container: Nicht Docker! Im C4-Modell sind damit einzelne Applikationen oder Datenspeicher gemeint. Typischerweise sind es einzeln einsetzbare/ausführbare Einheiten. (Beispiele: eine Spring Boot Applikation, eine PostgreSQL Datenbank, …)
- Component: Genauso wie Container kann dieser Begriff viele Bedeutungen haben. Im C4-Kontext ist eine Komponente eine Gruppierung von zusammengehörigen Funktionalitäten hinter einer definierten Schnittstelle. Komponenten sind – anders als Container – nicht einzeln ausführbar. Beispiel: Ein REST Controller aus Spring Boot ist eine Komponente.
Tiefere Erläuterungen und Erklärungen können auf der offiziellen Seite nachgelesen werden.
Wichtig zu erwähnen ist, dass das C4-Modell bloß beschreibt wie eine Architektur verständlich beschrieben werden soll. Das Modell beschreibt weder einen Prozess noch eine Notation. Für letzteres gibt es jedoch einen offiziellen Vorschlag. Diese wird auch in den folgenden Unterkapiteln als Beispiel benutzt.
Die folgenden Unterkapitel liefern einen kurzen Einblick in die verschiedenen Abstraktionsebenen, welche hier detaillierter nachgelesen werden können. Begleitet wird dies mit einem Beispiel von der offiziellen Seite, in welchem ein Online-Banking System grafisch modelliert wird.
Level 1: System Context
Dieses Diagramm stellt die Übersicht eines Software Systems mit allen Interaktionen fest. Dabei sind nicht nur Benutzerinteraktionen gemeint, sondern auch externe Software Systeme. Die Zielgruppe des Diagramms ist nicht nur der Entwickler der Software, sondern auch Außenstehende.
In der Abbildung 3 ist ein Beispiel eines System Context Diagramms zu sehen. Im Mittelpunkt zu sehen ist das Softwaresystem, welches beschrieben wird. Außen herum sind die beteiligten Personen und externe Softwaresysteme dargestellt und wie die Komponenten miteinander zusammenhängen.
Level 2: Container
Auf dieser Ebene wird ein Blick in das zu beschreibende System geworfen. Dabei werden die einzelnen Elemente des Systems auf einem hohen Level mit Containern beschrieben. Sofern relevant können externe Personen und Systeme mit abgebildet werden.
In Abbildung 4 ist ein Container Diagramm zu sehen. Jeder Container ist dabei eine autonom ausführbare Einheit. Grobe technologische Entscheidungen können auf dieser Ebene dokumentiert werden.
Level 3: Component
Die vorletzte Ebene betrachtet die einzelnen Container aus der zweiten Ebene separat und teilt diese in Komponenten auf. Vergleichbar ist diese Ansicht mit einem Package Diagram aus UML. Das Banking Beispiel lässt sich hier betrachten.
Level 4: Code
Die letzte Ebene betrachtet die aus Ebene 3 definierten Komponenten einzeln. Üblicherweise befinden sich in dieser Ebene Klassendiagramme oder Entity-Relationship-Diagramme. Oft wird diese Ebene als optional angesehen, da für ein grobes Verständnis einer Architektur solch ein tiefes Level nicht erforderlich ist.
C4-Modell vs. UML
Unserer Ansicht nach dürfen das C4-Modell und UML nicht gegenübergestellt werden, beide verfolgen verschiedene Ziele und haben ihre Daseinsberechtigung. Während das C4-Modell beschreibt, wie eine konkrete Systemarchitektur gut verständlich dokumentiert werden kann, setzt UML den Fokus auf eine einheitliche Notation und eine große Auswahl an Diagrammen. Tatsächlich finden wir, dass die Diagramme, welche aus dem C4-Modell resultieren, bei Bedarf mit UML-Diagrammen ergänzt werden sollen, denn die vier Diagramme stellen unter keinen Umständen eine vollständige Architekturdokumentation dar! Wenn man ein Fan von UML ist, lassen sich die C4 Schaubilder mit abgeänderter UML Notation abbilden.
Schlusswort
Das C4-Modell hat uns durchaus überzeugt und wir werden es – wenn es passt – wieder benutzen. In einem unserer Projekte konnte sich ein Kollege nach seiner Elternzeit ohne viel Aufwand wieder in die von uns veränderte Architektur einarbeiten.
Uns gefällt es gut mit dem standardisierten und leichtgewichtigen Modell Architekturen effizient zu gestalten und für alle Zielgruppen verständlich zu dokumentieren. Vorteilhaft ist die Integration des C4-Modells mit arc42, ArchiMate und weiteren Tools. Wir haben bisher draw.io mit einer Erweiterung benutzt und sind damit zufrieden gewesen.
