Das Lesen eines 5,000 Zeilen langen COBOL-Programms erklärt die Funktion jeder einzelnen Anweisung. Ein Abhängigkeitsdiagramm dieses Programms zeigt, womit es verbunden ist, was davon abhängt und welche Probleme bei Änderungen auftreten. Ein Ablaufdiagramm des Hauptausführungspfads verdeutlicht das Verhalten des Programms bei unterschiedlichen Eingaben. Diese drei Diagramme zusammen liefern Ihnen in zehn Minuten mehr handlungsrelevante Erkenntnisse, als das Lesen des Quellcodes an einem Nachmittag ermöglichen würde. Genau darin liegt der Kernnutzen der Codevisualisierung: Sie wandelt textuelle Logik in räumliche, visuelle Strukturen um, die Beziehungen, Abläufe und Risiken aufzeigen, die beim zeilenweisen Lesen verborgen bleiben.
Visualisieren Sie Ihre Codebasis
SMART TS XL Erzeugt Abhängigkeitsdiagramme, Aufrufgraphen und Strukturdiagramme direkt aus Ihrem Quellcode.
Jetzt entdeckenCodevisualisierung ist keine einzelne Technik, sondern eine Familie von Darstellungsformen: Flussdiagramme, UML-Diagramme, Abhängigkeitsgraphen, Sequenzdiagramme, Zustandsdiagramme und Aufrufgraphen – jede eignet sich für eine bestimmte Fragestellung. Die Kunst besteht darin, die passende Darstellung für die jeweilige Fragestellung auszuwählen. Dieser Artikel behandelt die Diagrammtypen, die Werkzeuge zur automatischen Generierung aus Code, den Ansatz „Diagramme als Code“, der die Synchronisierung gewährleistet, und wie die Visualisierung in Unternehmen sowohl in Legacy- als auch in modernen Systemen funktioniert.
Wie SMART TS XL Erzeugt Diagramme für das gesamte System
SMART TS XL Die Visualisierungsherausforderung für Unternehmenssysteme wird durch die Analyse aller im System vorhandenen Sprachen und Plattformen – COBOL, JCL, Java, .NET, Python, RPG, SQL und weitere – gelöst. Daraus wird ein einheitliches Querverweismodell erstellt, das alle strukturellen Beziehungen abbildet. Die generierten Diagramme sind keine manuellen Darstellungen, sondern direkte Ergebnisse der Strukturanalyse des Quellcodes und somit stets mit dem aktuellen Stand der Codebasis synchronisiert.
Das Code-Visualisierung Fähigkeit von SMART TS XL erzeugt verschiedene Diagrammtypen:
- Abhängigkeitskarten Die Darstellung zeigt, welche Programme, Module und Komponenten voneinander abhängen, und zwar auf jeder Detailebene – vom Gesamtsystem bis hin zu einzelnen Copybook-Elementen und Datenbankspalten.
- Anrufdiagramme zeigt, welche Programme welche anderen aufrufen, durchsuchbar von jedem Startpunkt bis in jede Tiefe, über Sprachgrenzen hinweg.
- Datenflussdiagramme die Nachverfolgung, wie sich ein bestimmtes Feld oder Datenelement im System von seinem Ursprungspunkt bis zu jedem Ort bewegt, an dem es gelesen, geschrieben oder transformiert wird.
- Wirkungsdiagramme wird aus jeder vorgeschlagenen Änderung generiert und zeigt alle Komponenten an, die von dieser Änderung betroffen wären.
Das Zuordnung von Anwendungsabhängigkeiten Die Funktionalität wird auf die Systemebene erweitert, indem Karten der Interaktion ganzer Anwendungen erstellt werden, die für Architekturüberprüfungen, Modernisierungsplanung und Dokumentationen zur Einhaltung gesetzlicher Vorschriften verwendet werden.
Für Teams, die durchführen Modernisierung des Altbestands, SMART TS XLDie Visualisierungen bilden die Grundlage für die Planung: Die Abhängigkeitskarte des aktuellen Systems bestimmt die Migrationsreihenfolge, der Aufrufgraph identifiziert, welche Komponenten unabhängig voneinander konvertiert werden können, und das Wirkungsdiagramm stellt sicher, dass eine geplante Änderung keine unerwarteten Ausfälle in Komponenten verursacht, die von der geänderten Komponente abhängen.
Was ist Codevisualisierung?
Codevisualisierung ist die Praxis, Quellcode, seine Struktur, sein Verhalten und seine Abhängigkeiten grafisch statt textuell darzustellen. Eine visualisierte Codebasis macht deutlich, was Text nur schwer vermitteln kann: welche Komponenten voneinander abhängen, wie die Ausführung durch bedingte Verzweigungen verläuft, wie Module im Zeitverlauf interagieren und wo sich die Komplexität konzentriert.
Mit der Größe der Codebasis steigt auch der Bedarf an Codevisualisierung. Bei einem 500-zeiligen Skript kann ein Entwickler die gesamte Struktur im Kopf behalten. In einem 500,000-zeiligen verteilten System mit fünfzehn Microservices und einem Legacy-Mainframe hat jedoch niemand mehr den vollständigen Überblick. Visualisierung macht diese Struktur in Diagrammen sichtbar, die geteilt, referenziert und im Zuge der Systementwicklung aktualisiert werden können.
Die Visualisierung von Code dient unterschiedlichen Zielgruppen auf unterschiedliche Weise:
- Entwicklung Verwenden Sie Flussdiagramme und Aufrufdiagramme, um die Ausführungslogik zu verstehen, unerwartetes Verhalten zu debuggen und Refactoring zu planen.
- Architekten Nutzen Sie Abhängigkeitsgraphen und Komponentendiagramme, um den Zustand der Struktur zu beurteilen und Migrationen zu planen.
- QA-Ingenieure Verwenden Sie Flussdiagramme und Kontrollflussdiagramme, um Testfälle zu entwerfen, die alle Zweige abdecken.
- Einsatzteams Sequenzdiagramme verwenden, um Anfrageflüsse nachzuverfolgen und Leistungsengpässe zu identifizieren.
- Nichttechnische Stakeholder Verwenden Sie vereinfachte Flussdiagramme und Komponentendiagramme, um den Systemumfang während der Planung oder der Überprüfung der Konformität zu verstehen.
Diagrammtypen und ihre jeweiligen Anwendungsbereiche
Verschiedene Visualisierungsarten beantworten unterschiedliche Fragen. Die Verwendung der falschen Diagrammart führt zu einem verwirrenden Ergebnis; die Verwendung der richtigen schafft sofortige Klarheit.
| Diagrammtyp | Die beste Frage, die es beantwortet | Am besten geeignet für |
|---|---|---|
| Flowchart | Wie läuft die Ausführung gemäß dieser Logik ab? | Entscheidungslogik, Fehlersuche, Onboarding |
| Sequenzdiagramm | Welche Nachrichten werden zwischen den Komponenten ausgetauscht und in welcher Reihenfolge? | API-Interaktionen, asynchrone Abläufe, Debugging |
| Klassen Diagramm | Welche Datenstrukturen gibt es und wie stehen sie in Beziehung zueinander? | OOP-Design, Refactoring, Dokumentation |
| Abhängigkeitsdiagramm | Wovon hängt was ab, und wie eng ist das System miteinander verknüpft? | Folgenabschätzung, Refactoring, Migrationsplanung |
| Zustandsdiagramm | Wie vollzieht das System den Übergang zwischen den Zuständen? | Protokolllogik, UI-Zustandsautomaten, eingebettete Systeme |
| Komponentendiagramm | Wie werden die Bausteine des Systems zusammengesetzt und miteinander verbunden? | Architekturprüfung, Onboarding, Cloud-Migration |
| Anrufdiagramm | Welche Funktionen rufen welche anderen Funktionen auf? | Erkennung von totem Code, Leistungsprofilierung, Wirkungsanalyse |
| Kontrollflussdiagramm | Welche Ausführungspfade sind innerhalb einer Funktion möglich? | Testen, Komplexitätsanalyse, sicherheitskritische Überprüfung |
Flussdiagramme: Entscheidungslogik sichtbar gemacht
Ein Flussdiagramm stellt den Ablauf eines Prozesses oder Programms dar und zeigt Entscheidungspunkte, Verzweigungen, Schleifen und Endzustände mithilfe standardisierter Formen. Rechtecke repräsentieren Prozesse, Rauten Entscheidungen, Parallelogramme Ein- und Ausgaben und Ovale Start- und Endpunkte.
Flussdiagramme sind das am weitesten verbreitete Visualisierungsformat, da sie die menschliche Denkweise bei sequenziellen Prozessen direkt widerspiegeln. Ein Entwickler, der neu in einer Codebasis ist und ein Flussdiagramm der Zahlungsabwicklungslogik liest, versteht diese schneller als durch das Lesen des Codes. Ein QA-Ingenieur erkennt anhand des Flussdiagramms vier Entscheidungszweige und kann vier Testfälle entwerfen, die diese abdecken.
Im Programmierkontext sind Flussdiagramme am effektivsten für:
- Erläuterung der Verzweigungslogik in einer einzelnen Funktion oder Prozedur
- Algorithmen entwerfen, bevor man Code schreibt
- Dokumentation von Geschäftsregeln zu Compliance- oder Prüfungszwecken
- Debugging durch Nachverfolgen des Pfades, der beim Auftreten eines Fehlers eingeschlagen wurde
Sequenzdiagramme: Wechselwirkungen im Zeitverlauf
Ein Sequenzdiagramm veranschaulicht die zeitlich geordnete Interaktion von Objekten oder Komponenten. Die horizontale Achse repräsentiert die Teilnehmer (Dienste, Klassen, Benutzer), und die vertikalen Pfeile zeigen die chronologisch zwischen ihnen ausgetauschten Nachrichten. Sequenzdiagramme sind das wichtigste Werkzeug zum Verständnis verteilter Systeme, der Kommunikation von Microservices und des Verhaltens von APIs.
In einer monolithischen Architektur zeigen Sequenzdiagramme, wie eine einzelne Anfrage eine Kette von Methodenaufrufen durch verschiedene Schichten auslöst. In einer Microservices-Architektur veranschaulichen sie, welche Dienste in welcher Reihenfolge miteinander kommunizieren und welche Daten jede Nachricht enthält. Sie sind das effektivste Werkzeug zur Diagnose von Leistungsproblemen, die durch sequenzielle Aufrufe verursacht werden, welche parallelisiert werden könnten, oder durch N+1-Abfragemuster, die unnötige Datenbankzugriffe erzeugen.
Abhängigkeitsgraphen: Strukturelle Gesundheit auf einen Blick
Ein Abhängigkeitsdiagramm veranschaulicht die gerichteten Beziehungen zwischen Komponenten, Modulen, Paketen, Klassen, Diensten oder Dateien. Ein Pfeil von A nach B bedeutet, dass A von B abhängt. Zirkuläre Abhängigkeiten (A hängt von B ab, B hängt von A ab) werden im Diagramm als Zyklen dargestellt und sind sofort sichtbar und behebbar.
Abhängigkeitsdiagramme zeigen:
- Knoten mit hohem Fan-InKomponenten, von denen viele andere abhängen und die ein hohes Ausfallrisiko darstellen.
- Knoten mit hohem Fan-OutKomponenten, die von vielen anderen abhängen und dadurch möglicherweise gegen das Prinzip der Einzelverantwortung verstoßen.
- Zirkuläre Abhängigkeiten: gegenseitige Kopplung, die unabhängige Bereitstellung verhindert und Refactoring erschwert
- Architekturschichtverletzungen: Komponenten niedrigerer Ebene hängen von Komponenten höherer Ebene ab, was auf eine Abweichung im Design hinweist.
Im Kontext der Abhängigkeitsgraphen und AnwendungsrisikoDie strukturellen Erkenntnisse, die ein Abhängigkeitsgraph liefert, sind für die Änderungsplanung direkt nutzbar: Bevor eine Komponente geändert wird, zeigt ihr Abhängigkeitsgraph den gesamten Umfang dessen auf, was betroffen sein könnte.
Zustandsdiagramme: Verhaltenslogik über verschiedene Bedingungen hinweg
Ein Zustandsdiagramm (oder Zustandsautomatendiagramm) zeigt die verschiedenen Zustände, die ein System, Objekt oder Protokoll einnehmen kann, sowie die durch Ereignisse oder Bedingungen ausgelösten Übergänge zwischen diesen Zuständen. Zustandsdiagramme sind unerlässlich für jede Logik, deren aktuelles Verhalten vom historischen Kontext, Authentifizierungsabläufen, Auftragsverarbeitungspipelines, Firmware eingebetteter Geräte oder Netzwerkprotokollimplementierungen abhängt.
Zustandsdiagramme beantworten die Frage „Was passiert als Nächstes?“ für jeden möglichen aktuellen Zustand und jede mögliche Eingabe und sind damit das präziseste Werkzeug zur Spezifizierung und Überprüfung der Verhaltensvollständigkeit.
Code-Visualisierungswerkzeuge: Von manuell zu automatisch
Die praktische Herausforderung bei Diagrammen besteht darin, sie aktuell zu halten. Ein manuell erstelltes Diagramm, das im Januar noch korrekt war, ist nach drei Feature-Sprints im März bereits veraltet. Die folgenden Werkzeuge reichen von manuellen Diagrammwerkzeugen bis hin zu Systemen, die Diagramme direkt aus dem Quellcode generieren.
Diagramme als Code: Die Synchronisationslösung
Die effektivste Lösung für veraltete Diagramme ist die Verwendung von Diagrammen als Code: Diagramme werden als Textdefinitionen dargestellt und zusammen mit dem Quellcode in der Versionskontrolle gespeichert. Ändert sich der Code, wird auch die Diagrammdefinition im selben Commit aktualisiert. Das Diagramm ist stets synchronisiert, da es sich im selben Repository befindet und demselben Überprüfungsprozess unterliegt.
Die Suchanfragen in den Search Console-Daten, die sich auf die Synchronisierung von Code und Diagrammen sowie die Echtzeit-Konsistenz von Code und Diagrammen beziehen, spiegeln ein reales Problem wider, mit dem Teams bei der Verwendung herkömmlicher Diagrammwerkzeuge konfrontiert sind. Diagramme als Code lösen dieses Problem strukturell.
Meerjungfrau ist das am weitesten verbreitete Tool für Diagramme als Code und wird nativ von GitHub, GitLab, Notion, Obsidian und den meisten modernen Dokumentationsplattformen unterstützt:
PflanzeUML bietet eine reichhaltigere Syntax für komplexe UML-Diagramme und wird häufig in der Unternehmensdokumentation verwendet:
@startuml
class OrderService {
+createOrder(items: List<Item>): Order
+cancelOrder(orderId: String): void
-validatePayment(payment: Payment): Boolean
}
class Order {
+id: String
+status: OrderStatus
+items: List<Item>
+createdAt: DateTime
}
class PaymentService {
+charge(amount: Decimal, card: Card): Transaction
+refund(transactionId: String): void
}
OrderService --> Order: creates
OrderService --> PaymentService: delegates payment to
@endumlD2 ist eine neuere Diagramm-als-Code-Sprache mit einer lesbareren Syntax und automatischem Layout, die große Diagramme für komplexe Abhängigkeitsgraphen besser handhabt als Mermaid:
API Gateway -> Auth Service: authenticate
API Gateway -> Order Service: route order request
Order Service -> Inventory Service: reserve stock
Order Service -> Payment Service: charge card
Order Service -> Notification Service: send confirmation
Payment Service -> Bank API: process transactionGraphviz (DOT-Sprache) ist das bevorzugte Werkzeug für Abhängigkeitsgraphen und Aufrufhierarchien in automatisierten Pipelines:
digraph dependencies {
rankdir=LR;
node [shape=box];
"OrderController" -> "OrderService";
"OrderService" -> "InventoryRepository";
"OrderService" -> "PaymentGateway";
"OrderService" -> "NotificationService";
"InventoryRepository" -> "Database";
"PaymentGateway" -> "StripeAPI";
}Automatische Code-zu-Diagramm-Konvertierungstools
Neben „Diagramme als Code“, bei dem Entwickler die Diagrammdefinition schreiben, gibt es verschiedene Tools, die den Quellcode direkt analysieren und Diagramme automatisch generieren:
| Werkzeug | Was es erzeugt | Sprachen | Integration |
|---|---|---|---|
| PflanzeUML | Klassen-, Sequenz- und UML-Diagramme | Mehrere (aus Anmerkungen oder Handbuch) | IntelliJ, VS Code, Maven |
| Sourcetrail | Interaktive Abhängigkeitsgraphen, Aufrufgraphen | C, C++, Java, Python | Standalone-Version + IDE-Plugins |
| CodeVisualizer (VS Code) | Echtzeit-Flussdiagramme, Abhängigkeitsdiagramme | Python, JS, TS, PHP | VS-Code-Erweiterung |
| Doxygen + Graphviz | Aufrufgraphen, Inklusionsgraphen, Klassenhierarchien | C, C++, Java | CI / CD-Pipelines |
| py2cfg / pycallgraph | Kontrollflussdiagramme, Aufrufdiagramme | Python | CLI / Skripte |
| JavaParser + Graphviz | Methodenaufrufdiagramme, Paketabhängigkeiten | Javac | Tool-Integration erstellen |
| SMART TS XL | Sprachübergreifende Abhängigkeitsdiagramme, Aufrufdiagramme, Ablaufdiagramme | COBOL, JCL, Java, Python, RPG, .NET, SQL | Enterprise, Mainframe |
IDE-Integration: Visualisierung während der Programmierung
Moderne IDEs bieten Visualisierungsfunktionen, die den Bedarf an separaten Diagrammwerkzeugen reduzieren:
VS-Code Mit dem Rust-Analyzer, Pylance oder anderen Sprachservern lassen sich Aufrufhierarchien (Rechtsklick → Vorschau → Aufrufhierarchie) und Importgraphen anzeigen. Die CodeVisualizer-Erweiterung generiert Echtzeit-Flussdiagramme aus Funktionen in Python, JavaScript, TypeScript und PHP.
IntelliJ IDEA / JetBrains IDEs Bietet eine integrierte Abhängigkeitsanalyse, UML-Klassendiagramme, die aus ausgewählten Klassen oder Paketen generiert werden (Rechtsklick → Diagramme → Diagramm anzeigen), und Aufrufhierarchieansichten, die sowohl Aufrufer als auch Aufgerufene rekursiv anzeigen.
Visual Studio bietet Code Maps (Abhängigkeitsgraphen Ihrer Lösung), Architekturdiagramme und Schichtendiagramme zur Durchsetzung architektonischer Einschränkungen zur Build-Zeit.
Diagramme aus bestehendem Code generieren
Das Reverse-Engineering von Diagrammen aus bestehendem Code ist der häufigste Anwendungsfall in Legacy- und Enterprise-Umgebungen. Der Prozess hängt von der Programmiersprache und dem benötigten Diagrammtyp ab.
Generierung von Klassendiagrammen aus Code
Für Java und .NET können Klassendiagramme automatisch aus dem Quellcode generiert werden mit:
- Der in IntelliJ IDEA integrierte UML-Generator (Klassen auswählen, Rechtsklick → Diagramme)
- PlantUML mit dem IntelliJ-Plugin, das ausgewählte Klassen in das PlantUML-Format exportiert
- Pyreverse (Teil von pylint) für Python:
pyreverse -o png -p MyPackage mypackage/ - NClass für .NET: Generiert Klassendiagramme aus kompilierten Assemblies
Generierung von Aufrufdiagrammen und Abhängigkeitsdiagrammen
Aufrufgraphen und Abhängigkeitsgraphen erfordern eine statische Analyse der Codebasis:
# Python: generate call graph using pycallgraph
pip install pycallgraph2
pycallgraph2 graphviz -- python my_script.py
# Python: generate package dependency graph
pip install pydeps
pydeps my_package --max-bacon 4 --cluster
# Java: generate call graph with javacg
java -jar javacg.jar my_project.jar | python3 parse_cg.py
# COBOL/JCL/Legacy: use SMART TS XL for automatic cross-program dependency mapsFlussdiagramme aus Code generieren
Die automatische Generierung von Ablaufdiagrammen erfordert das Analysieren des Kontrollflusses einer bestimmten Funktion:
# Python: generate flowchart with code2flow
pip install code2flow
code2flow my_module.py --output my_flowchart.png
# C/C++: use Doxygen with CALL_GRAPH=YES in Doxyfile
CALL_GRAPH = YES
CALLER_GRAPH = YES
HAVE_DOT = YES
# Any language: CodeVisualizer VS Code extension
# Right-click any function → Visualize Function FlowCode-Diagramm-Synchronisierung: Diagramme am Leben erhalten
Der häufigste Fehler bei der Codevisualisierung ist die Erstellung veralteter Diagramme. Teams erstellen im Januar ein ansprechendes Architekturdiagramm, die Codebasis ändert sich im Laufe von drei Feature-Sprints, und im April beschreibt das Diagramm ein System, das nicht mehr existiert. Entwickler verlieren das Vertrauen in die Diagramme. Sie häufen sich zu irreführenden Artefakten an.
Drei Strategien verhindern dies:
Strategie 1: Diagramme als Code in der Versionskontrolle. Speichern Sie Mermaid-, PlantUML- oder D2-Diagrammdefinitionen im selben Repository wie den zugehörigen Code. Jeder Pull Request, der Codeänderungen enthält, kann die entsprechende Diagrammaktualisierung beinhalten. Code-Reviewer können beide Änderungen gemeinsam überprüfen. CI-Pipelines können die Diagramme automatisch rendern und dem Pull Request hinzufügen.
Strategie 2: Automatisierte Diagrammgenerierung in CI/CD. Konfigurieren Sie die Build-Pipeline so, dass Abhängigkeitsgraphen und Aufrufgraphen bei jedem Merge in den Hauptzweig neu generiert werden. Speichern Sie die generierten Diagramme als Build-Artefakte. Das Diagramm der „aktuellen Architektur“ ist stets das Ergebnis des letzten Builds und niemals eine manuell gepflegte Datei.
Strategie 3: Visualisierungsintegrierte IDEs. Bei Diagrammen, die Entwicklern während der aktiven Entwicklung angezeigt werden, beseitigen IDE-Plugins, die Diagramme bei Bedarf aus der aktuellen Quelle generieren, das Synchronisationsproblem vollständig: Das Diagramm wird jedes Mal neu generiert und ist somit immer aktuell.
Die Kombination der Strategien 1 und 2 ist für die Teamdokumentation am effektivsten: handgezeichnete Diagramme für die architektonische Absicht (die durch Code-Review-Disziplin aktuell gehalten werden) und automatisch generierte Diagramme für die strukturelle Wahrheit (die durch CI-Automatisierung aktuell gehalten werden).
Visualisierung komplexer Codeabhängigkeiten in Altsystemen
Legacy-Codebasen stellen die größten Herausforderungen bei der Visualisierung dar und erfordern daher dringenden Bedarf. Eine Mainframe-Anwendung mit 40 Jahren COBOL-, JCL-, Copybooks- und eingebettetem SQL-Code enthält Abhängigkeitsstrukturen, die kein aktives Teammitglied mehr vollständig versteht. Die Dokumentation, sofern überhaupt vorhanden, wurde für ein System geschrieben, das sich seither grundlegend verändert hat.
Die automatisierte Abhängigkeitsanalyse von Altsystemen erfordert Werkzeuge, die die beteiligten Sprachen verstehen. Standardvisualisierungswerkzeuge für Java oder Python können COBOL nicht parsen, JCL-Jobstream-Aufrufmuster nicht verstehen und die sprachübergreifenden Verbindungen nicht nachverfolgen, die ein COBOL-Programm mit der DB2-Tabelle, in die es schreibt, und dem Java-Dienst, der aus dieser Tabelle liest, verknüpfen. Wie im Kontext von Daten- und KontrollflussanalyseDas strukturelle Verständnis dafür, wie Daten durch ein mehrsprachiges System fließen, erfordert die Analyse jeder einzelnen Sprache und die Auflösung der Verbindungen zwischen ihnen in einem einheitlichen Modell.
Die spezifischen Visualisierungsanforderungen in Legacy-Systemen unterscheiden sich von denen moderner Systeme:
- Programmaufrufdiagramme Es wird angezeigt, welche COBOL-Programme welche anderen Programme über CALL, PERFORM und LINK aufrufen.
- JCL-Jobstream-Diagramme Die Ausführungsreihenfolge der Schritte, die von ihnen aufgerufenen Programme und die zwischen ihnen fließenden Datensätze werden dargestellt.
- Sprachübergreifende Abhängigkeitskarten zeigt, wie eine Copybook-Felddefinition mit einer DB2-Spalte verbunden wird, die wiederum mit einem Java-Serviceobjektfeld verbunden ist, welches schließlich eine REST-API-Antwort liefert.
- Wirkungsdiagramme Generiert aus einer beliebigen Ausgangskomponente, zeigt an, was sich ändern würde, wenn sich diese Komponente ändert.
Diese Diagramme bilden die Grundlage für eine sichere Modernisierung: Bevor eine Komponente in die Cloud migriert oder in eine neue Sprache konvertiert wird, muss das Team wissen, womit sie verbunden ist und was von ihr abhängt. Ohne Visualisierung muss dieses Wissen manuell aus dem Quellcode rekonstruiert werden, was Wochen dauert und unvollständige Ergebnisse liefert.
Die Auswahl des richtigen Diagramms für Ihr Problem
Der häufigste Fehler bei der Codevisualisierung besteht darin, den falschen Diagrammtyp für die gestellte Frage zu erstellen oder ein Diagramm auf der falschen Abstraktionsebene zu generieren. Die folgende Entscheidungshilfe ordnet gängige technische Fragestellungen dem jeweils effektivsten Diagrammtyp zu:
| Ingenieurfrage | Bester Diagrammtyp | Zubehör |
|---|---|---|
| Wie funktioniert diese Funktion? | Flowchart | Mermaid, CodeVisualizer, code2flow |
| Wodurch wird diese Funktion aufgerufen? | Anrufdiagramm | Sourcetrail, IDE-Aufrufhierarchie, SMART TS XL |
| Wie kommunizieren diese Dienste miteinander? | Sequenzdiagramm | Mermaid, PlantUML |
| Was hängt von dieser Komponente ab? | Abhängigkeitsdiagramm | Graphviz, D2, SMART TS XL |
| In welchen Zuständen kann sich dieses System befinden? | Zustandsdiagramm | Mermaid, PlantUML |
| Wie ist das System strukturiert? | Komponentendiagramm | PlantUML, Lucidchart, draw.io |
| Welche Auswirkungen wird diese Änderung haben? | Wirkungsdiagramm | SMART TS XL |
| Wo konzentriert sich die Komplexität? | Heatmap-Überlagerung auf Abhängigkeitsgraph | CodeScene, SMART TS XL |
| In welchem Zusammenhang stehen diese Kurse? | Klassen Diagramm | IntelliJ, Pyreverse, PlantUML |
Ein weiterer häufiger Fehler ist die Verwendung von Visualisierung als einmalige Aktivität anstatt als kontinuierliche Praxis. Ein Abhängigkeitsdiagramm, das einmalig vor Beginn eines Migrationsprojekts erstellt und nie aktualisiert wird, unterstützt die Migration nicht: Es bildet lediglich den Systemzustand zum Zeitpunkt seiner Erstellung ab. Diagramme, die automatisch aus dem Code generiert, in der Versionskontrolle gespeichert oder bei Bedarf neu generiert werden, bleiben während eines gesamten Entwicklungsprogramms nützlich und verkommen nicht zu veralteten Referenzdokumenten.
Die Visualisierung ist am wirkungsvollsten, wenn sie in den Arbeitsablauf integriert wird: Sie wird während der Codeüberprüfung generiert, um zu bestätigen, dass eine neue Abhängigkeit beabsichtigt ist, sie wird während der Reaktion auf Vorfälle abgefragt, um den Verlauf eines Fehlers nachzuverfolgen, und sie wird während Architektursitzungen verwendet, um strategische Diskussionen auf die tatsächliche Struktur des Systems zu stützen und nicht auf Annahmen darüber, wie es organisiert ist.
