Detecting Object-Oriented Code Smells through Social Network Analysis
Dieses Paper schlägt einen neuartigen Ansatz zur Erkennung von objektorientierten Code Smells vor, indem es Softwarekomponenten und deren Interaktionen als soziale Netzwerke modelliert und Metriken der sozialen Netzwerkanalyse (Social Network Analysis, SNA) auf vier Java-Open-Source-Projekten anwendet, um verborgene Designfehler aufzudecken.
Originalarbeit lizenziert unter CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Software wird aus unzähligen kleinen Anweisungen aufgebaut, die zusammenarbeiten, ganz so, wie eine Stadt aus einzelnen Gebäuden und den Straßen, die sie verbinden, besteht. Wenn eine Stadt gut geplant ist, fließt der Verkehr reibungslos, und neue Stadtviertel können ohne Chaos hinzugefügt werden. In der Welt der Computerprogrammierung wird diese Organisation als „objektorientiertes Design“ bezeichnet, bei dem Code in in sich geschlossene Einheiten gruppiert wird, die miteinander interagieren. Doch genau wie eine Stadt unter überfüllten Kreuzungen oder verlassenen Gebäuden leiden kann, kann auch Software strukturelle Mängel entwickeln, die als „Code Smells“ (Code-Gerüche) bekannt sind. Dies sind keine Fehler, die ein Programm zum Absturz bringen, sondern vielmehr Anzeichen dafür, dass das Design unordentlich, schwer verständlich oder schwierig zu reparieren wird. Unkontrolliert lassen diese Gerüche die Software fragil und teuer in der Wartung werden, was Entwickler dazu zwingt, mehr Zeit mit dem Entwirren von Knoten als mit dem Bauen neuer Funktionen zu verbringen.
Seit Jahrzehnten versuchen Forscher, diese Mängel automatisch zu finden, oft indem sie die Anzahl der Codezeilen zählen oder messen, wie viele Variablen ein einzelner Abschnitt verwendet. Obwohl diese traditionellen Methoden hilfreich sind, übersehen sie manchmal das große Ganze, da sie es versäumen, zu erkennen, wie verschiedene Teile des Systems auf komplexe Weise voneinander abhängen. Ein neuer Ansatz, der in einer kürzlich veröffentlichten Studie von Mohamed Maddeh von der King Saud University detailliert beschrieben wurde, schlägt vor, Software nicht nur als eine Sammlung von Dateien zu betrachten, sondern als ein soziales Netzwerk. In dieser Sichtweise ist jede Code-Klasse eine Person, und jedes Mal, wenn ein Stück Code ein anderes nutzt, ist dies eine soziale Interaktion. Durch die Anwendung derselben mathematischen Werkzeuge, die zur Kartierung von Freundschaften und Einfluss in menschlichen Gemeinschaften verwendet werden, entwickelte der Forscher einen Weg, diese strukturellen Schwächen mit größerer Klarheit aufzuspüren.
Die Studie konzentrierte sich auf vier bekannte Open-Source-Softwareprojekte, die in der Sprache Java geschrieben wurden: JUnit, Spring, Apache Commons BCEL und Guava. Diese Projekte variieren erheblich in ihrer Größe und reichen von einigen hundert bis zu über viertausend distinkten Code-Einheiten. Um sie zu analysieren, extrahierte der Forscher zunächst jede Klasse innerhalb dieser Projekte und kartierte genau, wie sie miteinander interagierten. Wenn eine Klasse Daten oder eine Funktion von einer anderen benötigte, wurde eine Linie zwischen ihnen gezogen, wodurch ein massives Geflecht von Verbindungen entstand. Dieses Geflecht wurde dann in ein spezialisiertes Visualisierungstool namens Gephi importiert, das es dem Forscher ermöglichte, die gesamte Struktur der Software als eine einzige, miteinander verbundene Karte zu sehen.
Sobald die Software als Netzwerk modelliert war, wandte der Forscher spezifische Messungen an, um die „Smells“ zu identifizieren. In einem sozialen Netzwerk ist eine Person, die jeden anderen kennt und im Zentrum vieler Gespräche sitzt, hoch vernetzt. In der Software deutet eine Klasse, die mit zu vielen anderen Klassen interagiert, oft auf eine „God Class“ (Gott-Klasse) hin – eine Einheit, die zu viele Verantwortlichkeiten übernommen hat und versucht, alles zu erleden. Umgekehrt stellt eine Person, die niemanden kennt und allein am Rand der Karte sitzt, „Dead Code“ (toten Code) dar, also ein Stück Software, das nicht mehr verwendet wird. Andere Muster, wie etwa eine Gruppe von Menschen, die nur miteinander sprechen, aber nie mit der Außenwelt, oder eine einzelne Person, die die einzige Brücke zwischen zwei separaten Gruppen bildet, offenbarten Mängel wie „Data Classes“ (Datenklassen), die Informationen halten, ohne etwas zu tun, oder „Shotgun Surgery“ (Schrotflinten-Chirurgie), bei der eine einzige Änderung Modifikationen an vielen verschiedenen Stellen erfordert.
Die Ergebnisse zeigten, dass diese netzwerkbasierte Methode effektiv den Großteil des gesunden Codes herausfiltern konnte, wodurch die Entwickler eine wesentlich kleinere Liste von Verdächtigen zur Überprüfung erhielten. Im größten untersuchten Projekt, das über viertausend Klassen enthielt, markierte die Methode nur etwa 17 Prozent als potenziell problematisch. In einem anderen Projekt mit fast tausend Klassen identifizierte sie etwa 35 Prozent, die Aufmerksamkeit benötigten. Die Visualisierungswerkzeuge machten diese Erkenntnisse unmittelbar und intuitiv greifbar; die „God Classes“ erschienen als große, hell leuchtende Knotenpunkte im Zentrum der Karte, während der „Dead Code“ und die „unbenutzten Klassen“ als kleine, schwach leuchtende Knotenpunkte am äußersten Rand erschienen, oft isoliert auf ihren eigenen, unverbundenen Inseln.
Dieser Ansatz erhebt nicht den Anspruch, das menschliche Urteilsvermögen zu ersetzen oder jeden einzelnen Fehler perfekt und fehlerfrei zu identieren. Stattdessen dient er als leistungsstarkes Triage-Werkzeug, um die überwältigende Aufgabe der Überprüfung einer gesamten Codebasis auf eine handhabbare Liste der strukturell ungewöhnlichsten Teile zu reduzieren. Indem er sich auf die Beziehungen zwischen den Code-Stücken konzentriert, anstatt nur auf deren internen Inhalt, bietet die Methode eine frische Perspektive auf ein altes Problem. Sie legt nahe, dass die Gesundheit eines Softwaresystems oft in dem Muster seiner Verbindungen sichtbar ist und dass Entwickler durch die Kartierung dieser Muster die verborgenen Schwachstellen finden können, die die Stabilität ihrer digitalen Kreationen bedrohen, bevor diese unhandhabbar werden.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.