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

Die Abhängigkeitsmatrix

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Möchte man Details über die Abhängigkeiten erfahren, bedient man sich am besten einer Matrixdarstellung.
06:15

Transkript

Wenn man Software entwickelt, dann entstehen ziemlich schnell ziemlich viele Abhängigkeiten. Diese dann detailliert in einer Baumstruktur zu analysieren, ist meist nicht mehr möglich. Möchte man also in die Details gehen, dann stellt man die Abhängigkeiten besser als eine Matrix dar. Und schon sind wir bei der "Abhängigkeitsmatrix" beziehungsweise "Dependency Structuring Matrix". Ich stelle dieses Konzept anhand der Implementierung in "NDepend" dar. Es gibt auch andere Werkzeuge, die das anbieten. Dann sieht es etwa ähnlich, aber eben nicht gleich aus, also beispielsweise die Farben können variieren. Der Code, den wir analysieren, ist von Json.NET, einer sehr beliebten Open Source Library im Microsoft-Umfeld. Was wir schon sehen, ist, dass wir hier oben ziemlich viele Einträge haben und hier links ziemlich wenige. Das kommt daher, dass auf der oberen Seite all die Elemente eingetragen werden, die Code nutzen, der von der linken Seite bereitgestellt wird, also, hier haben wir beispielsweise "Json" und wir haben "Json.Tests". Das ist einmal die Testbibliothek und einmal die tatsächliche Implementierungsbibliothek. Auf der linken Seite haben wir zusätzlich noch viele Framework-Bibliotheken, wie zum Beispiel "System" oder "mscorlib" oder "System Runtime Civilization". Diese nutzen natürlich keinen Quellcode der hier oben befindlichen Elemente, da sie ja Framework-Elemente sind. Und die greifen eben nicht auf eine solche Bibliothek zu. Die Zellen, die sich in der Matrix nun ergeben, sind bei mir gerade so konfiguriert, dass sie die Anzahl der Member darstellen, welche Abhängigkeiten darstellen. Also, "Newtonsoft.Json" nutzt beispielsweise 6 Member aus "Runtime Civilization". Das Ganze können wir auch mal auf Typen umstellen. Dann nutzt Json 4 Typen von "Civilization". Überall dort, wo keine Nutzung besteht, bleibt das Feld natürlich leer, also, "Newtonsoft.Json" verwendet offensichtlich nichts aus "Data.Entity". Nun zeigen wir mal nur die Assemblies meiner Applikationen an. Und dabei ergibt sich ein interessantes Bild: Alle Elemente sind eindeutig voneinander getrennt. Hier oben rechts sind alle Elemente grün und hier unten links sind alle Elemente blau. Dass das auch anders geht, das sehen wir gleich. Was aber eine solche Matrix darstellt, ist eine perfekte Schichtentrennung. Ganz offensichtlich gibt es keine Referenz von "Newtonsoft.Json" auf "Json.Tests", denn letztendlich ist es ja so, dass der Test die Implementierung prüft. Und wofür braucht die Implementierung dann noch die Tests? Also, es ist eine perfekte Schichtentrennung und das sollte eigentlich immer unser Ziel sein, wenn wir Code entwickeln, auch wenn es teilweise sehr schwer zu erreichen ist. Wir sehen in dem Fall auch nochmal deutlich, was die Zahlen letztendlich bedeuten. Sie stellen eine Dopplung im Sinne von dargestellten Abhängigkeiten dar. Tatsächlich stellen Sie aber zeitgleich zwei unterschiedliche Arten von Abhängigkeiten dar. Der Bereich oben rechts kennzeichnet, wie viele Elemente von Tests Elemente aus Json nutzen. Das sind also die "Ausgehenden Abhängigkeiten", die "Efferent Dependencies". Die Zelle hier unten gibt an, wieviele Elemente von Json durch Tests genutzt werden, also die "Eingehenden Abhängigkeiten", die "Afferent Couplings". Dass das Ganze auch noch ganz anders aussehen kann, das sehen wir, wenn wir einmal auf die "Name Spaces" umswitchen. Hier sehen wir erstmal, es gibt ganz viel Zeugs, das sich untereinander nicht nutzt. Das ist auch völlig normal. Wir sehen hier auch wieder mehrere Zahlen. Unsere Matrix ist ein Stück weit geformt, also, wir können Dopplungen erkennen, Muster, die in dem Bereich vorhanden sind und Muster, die in dem Bereich vorhanden sind und sich auf die Art und Weise ähneln. Aber ganz interessant ist, dass jetzt mehr Farbe hinzugekommen ist, denn wir haben hier schwarze Punkte. Diese schwarzen Zellen werden uns darüber hinaus durch einen roten Rand mit angekündigt. Dieser rote Rand bedeutet, dass innerhalb dieses Nutzungsbereichs Kreisabhängigkeiten vorliegen. Es gibt also Elemente, die sowohl das gleiche Element nutzen als auch von dem Element genutzt werden. Das ist eine sehr starke Form der Kopplung. Sie sollten solche Kreisabhängigkeiten nach Möglichkeit vermeiden. Das kann man, indem man die Funktionalität weiter aufspaltet und sie dadurch besser wiederverwendbar macht. Grundsätzlich kann es eben durch den hohen Grad der Abhängigkeit zu Problemen kommen, weil sich Änderungen automatisch auf beide Kommunikationspartner auswirken können, weil aber auch beispielsweise solche Dinge wie die Analyse von "totem Code" wesentlich schwieriger ist, wenn es Kreisabhängigkeiten gibt und so weiter und so fort. Also, Kreisabhängigkeiten nach Möglichkeit vermeiden. Und diese werden uns hier eindeutig angezeigt und wir können uns den Code auch entsprechend anzeigen lassen, direkter anzeigen lassen. Hier ist das Ganze jetzt nach einmal als Dependency Graph dargestellt. Man kann also problemlos, zumindest bei "NDepend", zwischen der Dependency Matrix und dem Dependency Graph hin- und herwechseln, weil eben der Dependency Graph uns Übersichtswissen gibt, die Dependency Matrix gibt uns Detailinformationen. Damit haben wir auch den Zusammenhang zwischen beiden kennengelernt. Gerade bei großen Codebasen macht es durchaus Sinn, diese auf die Art und Weise auch zu analysieren, ob man eben Kreisabhängigkeiten hat, ob man zu viele Abhängigkeiten hat. Das kann auch sein. Dann verändert sich die Farbe hier, um darauf hinzuweisen: Hier solltest du aufpassen, vielleicht ist da eine zu große Kopplung zwischen den einzelnen Namespaces und so weiter und so fort.

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!