C4 Software Dokumentation
Last updated
Last updated
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
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.
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
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.
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
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.
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
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
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
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:
