Einheit 04: C4 Software Dokumentation
Lernziele
Probleme bei der Dokumentation von Software-Architekturen verstehen
Die vier Ebenen des C4-Models kennen
Das C4 Modell auf Problemstellungen anwenden können
Software-Architekturen mit Hilfe des C4-Models dokumentieren und kommunizieren können
Probleme bei der Dokumentation
Welches ist die beste/einfachste/verstÀndlichste Art Software-Architekturen zu dokumentieren
So? Schnell und einfach aber klar und verstÀndlich?
Besser so? Formal ja, aber genĂŒgend Detailgrad und unmiĂverstĂ€ndlich?
Noch besser so? Formal ja, mehr Detailgrad, aber genug Implementierungsetails? Was bedeuten die Pfeile?
Oder seher so? Autoamtisiert ja, aber klar und verstÀndlich?
Vielleicht aber doch so:
Ganz oft dann aber auch so, weil einfach und handhabbar und nicht formal:
Problem formaler Methoden: Diese sind "synthetisch" und mĂŒssen gelernt werden. Sie mĂŒssen von beiden Seiten verstande n werden. Daher einigt man ich meistens pragmatisch auf die Ebene, die beide Seiten verstehen.
Motivation
Visuelle Kommunikation im Baugewerbe: Hier gibt es Lageplane, RaumplĂ€ne, BebauungsplĂ€ne, Querschnittsansichten, detaillierte Standardzeichnungen und technische Zeichnungen, die von den ausfĂŒhrenden Gewerken in der Regel ohne Probleme gelsen und (fehlerfrei) umgesetzt werden können.
Wie sieht hingegen die Kommunikation in Software-Projekten aus?
Durcheinander von Boxen und Linien
Inkonsistente Notationen, Farben, Formen und Linien
Mehrdeutige Bezeichnungen
Beziehungen nicht benannt
Fehlende Technologieentscheidungen und Details
Vermischte Abstraktionslevel
Aufgrund der Bewegung hin zu agilen Methoden wird weniger "Up Front Design" durchgefĂŒhrt und es finden sich weniger Software-Diagramme in agilen Projekten.
Wenn Diagramme genutzt werden sind diese oftmals
Unklar
Mehrdeutig
Verwirrend
und haben vermischte Detailgrade
C4 Modell
Das C4 Modell nutzt so.g Code-Landkarten zum verschiedene Sichten (Detaillevel) auf eine Software-Architektur zu modellieren. Jede Sicht kann fĂŒr einen ganz unterschiedlichen Zweck und eine unterschiedliche Zielgruppe genutzt werden.
Context
In welchem Gesamtkontext befindet sich das System, an welche externen Systeme grenzt es an?
Das Kontextdiagram beschreibt das Big Picture. Wie passen die Teile in den Gesamtkontext?
Container
Aus welchen Bestandeilen besteht das System. Im C4 Model sind hierbei Einheiten beschrieben, die Code hosten. Es kann sich dabei z.B. um auch einen Appliation Server handeln.
Component
Wie sind die einzelnen Bestandteile aufgebaut. In der Regel sind dies Gruppen von zusammengehörigen Funktionen, die hinter einer wohldefinierten Schnittstelle verborgen sind.
Code
Wie sehen die Bestandtiel des Systems im Detil aus. Hier werden Klassen, Schnittstelle, Objekte, Funktionen, Tabellen etc. innerhalb einer Komponente beschrieben.
Das C4 Model ist gedacht, um Software-Architekturen zu modellieren und zu kommunizieren. Es unterstĂŒtzt einen âAbstraction Firstâ Ansatz und reflektiert die Denkweise von Entwicklern und Software-Architekten
Es ist auch geeignet um Architekturen âUp Frontâ oder im Nachhinein zu dokumentieren.
C4 Metamodell
Level 1: System Context Diagram
Scope: Ein einzelnes Software System PrimÀre
Elemente: Das im Scope befindliche Software System UnterstĂŒtzende
Elemente: Personen und Software Systeme, die direkt mit dem im Scope befindlichen Software System in Verbindung
Zielgruppe: Technische und nicht-technische Personen innerhalb und auĂerhalb des Entwicklungs-Teams
Level 2: Container Diagram
Scope: Ein einzelnes Software System PrimÀre
Elemente: Der im Scope befindliche Container UnterstĂŒtzende Elemente: Personen und Software System, die mit dem im Scope befindlichen Container in Verbindung stehen
Zielgruppe: Technische Personen innerhalb und auĂerhalb des Software Entwicklungs-Teams; einschlieĂlich Software Architekten, Entwickler und Betriebs- und Supportpersonal #
Hinweis: Container Diagramme treffen keine Aussage ĂŒber die Deployment Szenarien, eventuelles Clustering, Replikations- und/oder Failover-Szenarien etc.
Level 3: Component Diagram
Scope: Ein einzelner Container PrimĂ€re Elemente: Komponenten innerhalbs des im Scope befindlichen Containers UnterstĂŒtzende
Elemente: Containers (innerhalb des im Scope befindlichen Software Systems) + Personen und Software Systeme, die direkt mit den Komponenten in Verbindung stehen
Zielgruppe: Software Architekten and Entwickler
Level 4 Code Diagram
Scope: Eine einzelne Komponente PrimÀre Elemente: Code
Elemente (z.B. Klassen, Interfaces, Objekte, Methoden und Funktionen, Datenbanken und Tabellen etc.) innerhalb der im Scope befindlichen Komponente
Zielgruppe: Software-Architekten und Entwickler
ZusÀtzliche Diagramme
Die 4 Level sind nicht immer ausreichend Wo nötig mit KomplementĂ€ren ergĂ€nzen. Beispiele hierfĂŒr sind:
Systemlandschaft: In der echten Welt sind Software Systeme schon lange nicht mehr voneinander isolier und zeigen z.B. wie Systeme innerhalb eines Unternehmen zusammenspielen
Dynamische Diagramme: UML Kollaborationsdiagramme, UML Sequenzdiagamme
Deployment Diagramme: UML Deployment Diagramme einschlieĂlich Containers and Deployment Nodes
Praxisbeispiel
Anhand der Microsoft Referenz Architektur fĂŒr Microsoft Azure App Service ist es schwer, die exkaten Komponenten und das Zusammenspiel der Systembestandteile zu verstehen und letztendlich umzusetzen.
Anhand eines Level 2 Diagrams lĂ€sst sich dies wesentlich klarer ausdrĂŒcken:
Last updated
