Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Grundlagen der Programmierung: Codemetriken

Der Abhängigkeitsgraph

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Der Abhängigkeitsgraph bietet einen guten Überblick über die Zusammenhänge Ihrer Software.
04:34

Transkript

Abhängigkeiten innerhalb von Quellcode lassen sich nicht vermeiden. Wir müssen sie also analysieren können und wir müssen diese Analysen auch lesen lernen. Aus diesem Grund zeige ich Ihnen, was ein Abhängigkeitsgraph ist und auf welche Besonderheiten Sie dabei achten sollten. In diesem Beispiel nutze ich als Werkzeug NDepend, die darin gezeigten Dinge lassen sich aber auch sehr gut auf andere Tools übertragen. Als Quellcode zur Analyse nutze ich Json.NET. Hier haben wir einen sehr einfachen Abhängigkeitsgraph. Dieser zeigt an, dass die Solution, die ich aktuell geladen habe, bloß zwei Assemblies enthält, also zwei DLLs, und zwar "Newtonsoft.Json", das ist die eigentliche Implementierung und "Newtonsoft.Json.Tests". Das sind die Tests für die Implementierung. Der Abhängigkeitsgraph wird dabei über Knoten und Kanten dargestellt. Es ist ja üblicherweise so bei einem solchen Graph. Dabei ist aber wichtig, dass die Kanten gerichtet sind. Das sehen wir hier. Mit diesem Pfeil wird also gezeigt, dass die Abhängigkeit zwischen Tests und der Implementierung und nicht umgekehrt besteht. Es sei darauf hingewiesen, dass das Ganze natürlich nicht unbedingt immer der UML entsprechen muss. Wir haben jetzt hier einen geschlossenen Pfeil, in der UML hätte man wahrscheinlich eher einen geöffneten Pfeil. Man kann mit diesem Graph wesentlich mehr darstellen als nur diese Abhängigkeit; man kann zum Beispiel auch einen Größenvergleich machen. Aktuell sieht es so aus, als wären beide Bibliotheken etwa gleich groß. Weil sie das gleiche Volumen im Sinne von Lines of Code haben. Wenn ich nun von der Anzahl der Zeilen weggehe und das beispielsweise auf die Komplexität anwende, dann sehen wir, dass "Newtonsoft.Json" wesentlich komplexer ist als die Tests. Auch das ist völlig normal, weil Tests normalerweise keine if-else-Anweisungen oder Ähnliches enthalten, während Implementierungen diese natürlich benötigen. Gehen wir dazu über, dass wir etwas mehr Information hineinladen und zwar schauen wir uns einmal einen etwas komplexeren Graph an. Wenn wir jetzt nicht nur die beiden DLLs hinzuladen, die wir selbst geschrieben haben sozusagen, also, dass wir nur den Quellcode der Solution betrachten, sondern dass wir auch die Abhängigkeiten zu externen Bibliotheken betrachten. Diese werden von NDepend netterweise gelb dargestellt, damit man sie besser unterscheiden kann. Und hier sehen wir auch eine weiter Besonderheit und zwar können wir die Kantendicke dafür verwenden, um anzuzeigen, wie viele Elemente verwendet werden. Man sieht schon, von "mscorlib" wird offensichtlich wesentlich mehr verwendet als von "System.Core". Wenn wir nun zu den Namespaces übergehen, sehen wir, wie komplex so ein Graph werden kann. Er ist so groß, dass wir nahezu nichts lesen können und interessanterweise gibt es hier zwei Namespaces, die zwar enthalten sind in unserem Quellcode, aber nicht genutzt werden; es gibt keine Abhängigkeiten zu ihnen. Und das deutet in aller Regel toten Code an. Wenn ich jetzt heranzoome, sehen wir, dass das Chaos etwas größer geworden ist. Also hier wird wirklich sehr viel genutzt und in dem Fall ist es dann höchstwahrscheinlich sinnvoller, auf eine andere Darstellungsform, wie zum Beispiel der Abhängigkeits-Matrix beziehungsweise der Struktur-Matrix, zu wechseln. Es gibt noch eine Sache, die ich Ihnen zeigen möchte, dazu zeige ich nur die Namespaces der Applikation an und hier sehen wir etwas, das wir vorhin schon einmal näher gesehen haben und zwar diese roten Pfeile. Wenn wir die roten Pfeile näher betrachten, sehen wir, dass sie Spitzen an beiden Enden haben. In dem Fall haben wir Kreisabhängigkeiten. Kreisabhängigkeiten sind immer ein eindeutiges Zeichen dafür, dass die Schichtentrennung nicht ganz eingehalten wurde. Es kann auf Namespace-Ebene natürlich sein, dass die Lösung eines Problems eine solche Verletzung der Schichtentrennung nötig macht. Man sollte das aber eigentlich möglichst vermeiden. Solche Kreisabhängigkeiten zeigen an, dass man die Funktionalität höchstwahrscheinlich nicht richtig aufgespalten hat. Hier sollte man gegebenenfalls etwas mehr Zeit in das Design investieren beziehungsweise zusätzliche Namespaces öffnen, Funktionalität aufspalten und Ähnliches.

Grundlagen der Programmierung: Codemetriken

Lernen Sie Methoden, Prinzipien und Werkzeuge kennen, mit deren Hilfe Sie die Qualität Ihrer Software dauerhaft sicherstellen können.

1 Std. 43 min (20 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Exklusiv für Abo-Kunden
Erscheinungsdatum:25.04.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!