Am 01.02.2018 hatten wir bei Setlog eine Einführung in C4 mit Kevin Wittek von G Data. C4 ist kein Sprengstoff, sondern eine leichtgewichtige Modellierungs- und Dokumentationssprache für Softwarearchitekturen.
In diversen Bereichen des Lebens wie z.B. in der Kartographie, Architektur oder bei Elektrizität haben sich Standards für die Modellierung, wie z.B. Landkarten, Grundrisszeichnungen oder Schaltpläne etabliert und werden durchgehend gleichartig verwendet.
In der IT gibt es zwar auch diverse Ansätze zur Modellierung, wie z.B. UML (Unified Modelling Language), doch diese haben sich bei Weitem nicht so einheitlich durchgesetzt, wie in den oben genannten Beispielen. Grund ist vor allem die Schwerfälligkeit und der im Vergleich zum Nutzen doch sehr hoher Aufwand für die Modellierung. Außerdem bietet UML gerade auf den abstrakteren Ebenen kaum einheitliche Modellierungselemente.
Das Fehlen einer allgemeinen Standardmodellierungssprache für die Architektur führt dazu, dass jede Firma, ja jedes Team, eine eigene Notation für die Beschreibung der Architekturen verwendet, so dass keiner von außen und sogar die Autoren selber nach einer längeren Zeit mehr genau wissen, was mit den einzelnen Elementen wie z.B. Pfeilen gemeint ist.
Das wurde uns klar, als wir zu dem Beispielszenario eines elektronischen Kochbuchs die Architektur modellieren sollten. Das Ergebnis sah folgendermaßen aus:
Uns wurden die folgende Punkte sofort klar:
- Ein Außenstehender würde dieses Modell niemals verstehen!
- Bevor man an eine Architekturmodellierung geht, sollte die Domäne in Form eines Domänenmodells klar sein.
- Die Begriffe müssen einheitlich verwendet werden. In unserer Diskussion hat z.B. das simple Wort „Vorschlag“ zu langen Diskussionen über die Bedeutung im System geführt.
Das hat uns die Augen für die Notwendigkeit einer standardisierten, aber leichtgewichtigen Modellierungssprache geöffnet. Gerade im Hinblick darauf, dass wir gewillt sind unsere Architektur effizienter zu gestalten, müssen wir oder das eigens dazu geschaffene Architekturteam diese Vision einheitlich und für alle verständlich dokumentieren.
Um diese Ziele zu erreichen, bietet die Modellierungssprache C4 einen pragmatischen und vergleichsweise einfachen Ansatz. Es gibt vier verschiedene Abstraktionsstufen (Levels). Der Übergang von einer Stufe zur anderen ist vergleichbar mit dem Hineinzoomen in eine elektronische Landkarte wie etwa bei Google-Maps: es werden immer mehr Details sichtbar.
Die vier Abstraktionsstufen sind:
Level 1: System Context Diagram
Level 2: Container Diagram (Kein Docker-Container!)
Level 3: Component Diagram
Level 4: Code
Level 1: System Context Diagram
Das System Context Diagram ist eine Übersicht eines einzelnen Systems mit allen Kommunikationspartnern. Mit Kommunikationspartnern sind sowohl User Rollen gemeint, als auch externe Systeme wie E-Mailserver, Twitter, SLACK, etc. Die Zielgruppe bei diesem Diagramm ist nicht nur IT, sondern auch POs und Business. Wie so eine Architektur aussehen kann, wird auf diesem Bild anschaulich dargestellt.
Auch wir haben für unsere Beispielanwendung ein System Context Diagram erstellt:
Wie man sieht, kann jeder außenstehende und technisch unvorgeprägte Betrachter direkt erkennen, um was für ein System es sich handelt und wer damit kommunizieren soll. Das liegt vor allem daran, dass alle Elemente, insbesondere die Pfeile, sauber beschriftet worden sind.
Level 2: Container Diagram
Hier wird in in das System “reingezoomt” und die einzelnen autonom agierende Elemente aufgeführt. Dabei werden auch schon die groben Technologieentscheidungen (Web, Rich Client, etc.), sowie Protokolle, Ports, etc. aufgezeichnet, über die die einzelnen Komponente miteinander kommunizieren. Auf diesem Bild wird ein Container Diagramm anschaulich dargestellt.
Unser (aus Zeitgründen unvollständiges) Ergebnis eines Container Diagramms für unsere Beispielanwendung sah dann folgendermaßen aus:
Hier kamen wir in angeregte Diskussionen über die zu verwendende Technologien, was an sich schon den Vorteil dieser Modellierungsart aufzeigt.
Level 3: Component Diagram
Die nächste Zoomstufe ist die Betrachtung eines jeden in Level 2 definierten Containers einzeln. Im Prinzip werden hier die Packages definiert, aus denen die Container bestehen, und deren Beziehungen untereinander aufgeführt.
Auf dem folgenden Bild wird ein Beispiel für ein Component Diagram aufgeführt.
Level 4: Code
Auf dieser Ebene kann ein Klassendiagramm oder andere UML Diagramme gezeichnet werden. Dies entspricht aber von der Nützlichkeit her einer Google Street View: Es ist zwar nett anzuschauen und gibt interessante Detailinformationen, die aber für den grundsätzlichen Zweck, also dem Zurechtfinden in der Architektur von sekundärem Nutzen sind. Auf dieser Ebene ist es einfach leichter sich direkt im Quellcode über die Klassen und deren Abhängigkeiten klar zu werden.
„Je niedriger die Stufe, bzw. der Level der Modellierung, auf der eine Änderung im System durchgeführt wird, desto teurer ist die Anpassung.“
C4 ist ein interessanter und klar strukturierter Ansatz, um eine Systemarchitektur auf verschiedenen Abstraktionsstufen zu modellieren. Es kann uns auf jeden Fall helfen das aktuelle System für uns und nach außen besser zu dokumentieren und für die zukünftigen Anpassungen durch das Architekturteam als Diskussionsgrundlage zu stellen.
Für mehr Informationen zu dieser Methode sind die folgenden Links zu empfehlen:
https://c4model.com/
http://static.codingthearchitecture.com/c4.pdf
03.02.2018, Eduard Heinle