ck
1.0.0
CK berechnet Code-Metriken auf Klassenebene und Methodenebene in Java-Projekten durch statische Analyse (dh keiner kompilierter Code). Derzeit enthält es eine große Anzahl von Metriken, einschließlich des berühmten CK:
CBO (Kopplung zwischen Objekten) : zählt die Anzahl der Abhängigkeiten, die eine Klasse hat. Die Tools prüfen für jeden in der gesamten Klasse verwendeten Typ (Felddeklaration, Methodenrückgabetypen, variable Deklarationen usw.). Es ignoriert Abhängigkeiten von Java selbst (zB Java.lang.String).
CBO modifiziert (Kopplung zwischen Objekten) : zählt die Anzahl der Abhängigkeiten, die eine Klasse hat. Es ist dem ursprünglichen CBO des CKTOOL sehr ähnlich. Diese Metrik betrachtet jedoch eine Abhängigkeit von einer Klasse als sowohl die Referenzen, die der Typ auf andere liefert, als auch die Referenzen, die sie von anderen Typen erhält.
Fan-in : Zählt die Anzahl der Eingabeharten, die eine Klasse hat, dh die Anzahl der Klassen, die auf eine bestimmte Klasse verweisen. Zum Beispiel wäre das Fan-In von X die Anzahl der Klassen, die X aufrufen, indem er es als Attribut bezieht, auf einige seiner Attribute zugreift, einige seiner Methoden aufzurufen usw.
FAN-OUT : Zählt die Anzahl der Ausgabendellen, die eine Klasse hat, dh die Anzahl anderer Klassen, auf die von einer bestimmten Klasse verwiesen wird. Mit anderen Worten, bei einer Klasse X ist der Fan-Out von X die Anzahl der von X über Attribute Referenz, Methodenaufruf, Objektinstanzen usw., die von X aufgerufene Klassen, usw., ist.
DIT (Tiefenbaum) : Es zählt die Anzahl der "Väter", die eine Klasse hat. Alle Klassen haben mindestens 1 (jeder erbt Java.lang.Object). Um dies zu erreichen, müssen Klassen im Projekt vorhanden (dh wenn eine Klasse von X abhängt, die in einer JAR-/Abhängigkeitsdatei stützt und X von anderen Klassen abhängt, wird DIT als 2 gezählt).
NOC (Anzahl der Kinder) : Es zählt die Anzahl der unmittelbaren Unterklassen, die eine bestimmte Klasse hat.
Anzahl der Felder : Zählt die Anzahl der Felder. Spezifische Zahlen für die Gesamtzahl der Felder, statische, öffentliche, private, geschützte, standardmäßige, endgültige und synchronisierte Felder.
Anzahl der Methoden : Zählt die Anzahl der Methoden. Spezifische Zahlen für die Gesamtzahl von Methoden, statische, öffentliche, abstrakte, private, geschützte, standardmäßige, endgültige und synchronisierte Methoden. Konstruktormethoden zählen auch hier.
Anzahl der sichtbaren Methoden : Zählt die Anzahl der sichtbaren Methoden. Eine Methode ist sichtbar, wenn sie nicht privat ist.
NOSI (Anzahl der statischen Aufrufe) : Zählt die Anzahl der Aufrufe zu statischen Methoden. Es kann nur diejenigen zählen, die vom JDT gelöst werden können.
RFC (Antwort für eine Klasse) : Zählt die Anzahl der eindeutigen Methodenaufrufe in einer Klasse. Da die Aufrufe durch statische Analyse aufgelöst werden, schlägt diese Implementierung fehl, wenn eine Methode überlastet mit derselben Anzahl von Parametern, jedoch unterschiedlichen Typen.
WMC (Gewichtsmethodenklasse) oder McCabe -Komplexität . Es zählt die Anzahl der Zweiganweisungen in einer Klasse.
LOC (Codezeilen) : Es zählt die Zeilen der Zählung, ignoriert leere Zeilen und Kommentare (dh es sind Quellzeilen von Code oder SLOC). Die Anzahl der Zeilen hier kann sich von der Originaldatei ein wenig unterscheiden, da wir die interne Darstellung des Quellcodes von JDT verwenden, um ihn zu berechnen.
LCOM (mangelnde Zusammenhalt von Methoden) : Berechnet LCOM -Metrik. Dies ist die allererste Version von Metrik, die nicht zuverlässig ist. LCOM-HS kann besser sein (hoffentlich senden Sie uns eine Pull-Anfrage).
LCOM* (mangelnde Zusammenhalt von Methoden) : Diese Metrik ist eine modifizierte Version der aktuellen Version von LCOM, die im CK -Tool implementiert ist. LCOM* ist eine normalisierte Metrik, die den Mangel an Klassenkohäsion innerhalb eines Bereichs von 0 bis 1 berechnet. Je näher an 1 der Wert von LCOM* in einer Klasse, desto weniger der Zusammenhalt dieser jeweiligen Klasse. Je näher an 0 der Wert von LCOM* in einer Klasse, desto am meisten der Zusammenhalt dieser jeweiligen Klasse. Diese Implementierung folgt der dritten Version von LCOM*, die in [1] definiert ist.
TCC (Zusammenhalt der Klassenklasse) : misst den Kohäsion einer Klasse mit einem Wertbereich von 0 bis 1. TCC den Zusammenhalt einer Klasse über direkte Verbindungen zwischen sichtbaren Methoden, zwei Methoden oder deren Aufrufbäumen zugreifen auf dieselbe Klassenvariable.
LCC (Lose Class Cohäsion) : Ähnlich wie TCC, enthält jedoch weiter die Anzahl der indirekten Verbindungen zwischen sichtbaren Klassen für die Kohäsionsberechnung. Somit gilt die Einschränkung lcc> = tcc immer.
Return -Mengenmenge : Die Anzahl der return .
Menge an Schleifen : Die Anzahl der Schleifen (dh für, während, während er, erhöht für).
Menge der Vergleiche : Die Anzahl der Vergleiche (dh == und! =). Hinweis :! = ist nur in 0.4.2+ erhältlich.
Menge an Try/Fängen : Die Anzahl der Versuche/Fänge
Menge an Klammern : die Anzahl der Ausdrücke in Klammern.
String -Literale : Die Anzahl der String -Literale (z. B. "John Doe" ). Wiederholte Saiten zählen so oft, wie sie erscheinen.
Anzahl der Zahl : Die Anzahl der Zahlen (dh int, lang, doppelt, float) Literale.
Menge an Mathematikoperationen : Die Anzahl der mathematischen Operationen (Zeiten, Teilen, Reste, minus, linke Scheiße, rechte Verschiebung).
Menge der Variablen : Anzahl der deklarierten Variablen.
Max verschachtelte Blöcke : Die höchste Anzahl von zusammengebundenen Blöcken.
Menge anonymen Klassen, inneren Klassen und Lambda -Ausdrücke : Der Name sagt alles. Beachten Sie, dass wenn eine anonyme Klasse oder eine innere Klasse deklariert wird, sie zu einer "gesamten neuen Klasse" wird, z. B. CK generiert AB und AB $ C, C ist eine innere Klasse in AB, aber Lambda -Ausdrücke werden nicht als Klassen betrachtet und sind daher Teil der Klasse/Methode, in die sie eingebettet sind. Eine Klasse oder eine Methode hat nur die Anzahl der inneren Klassen, die auf ihrer Ebene deklariert sind, z. B. eine innere Klasse, die in einer Methode M2 deklariert wird, die sich in einer anonymen Klasse A befindet, die in einer Methode m deklariert ist, die schließlich in einer Klasse C deklariert ist, zählt nicht in der Klasse C, sondern nur in der Methode M2 (Erste. Er wurde eingestuft).
Anzahl der eindeutigen Wörter : Anzahl der eindeutigen Wörter im Quellcode. Auf Methodenebene verwendet es nur die Methodekörper als Eingabe. Auf Klassenebene verwendet es den gesamten Körper der Klasse als Metriken. Der Algorithmus zählt im Grunde genommen die Anzahl der Wörter in einer Methode/Klasse, nachdem Java -Schlüsselwörter entfernt wurden. Die Namen basieren auf Camel -Fall und unterstreicht (z. B. longname_likethis werden zu vier Wörtern). Weitere Informationen zur Implementierung finden Sie unter WordCounter -Klasse.
Anzahl der Protokollanweisungen : Anzahl der Protokollanweisungen im Quellcode. Das Zählen verwendet Regex, die mit SLF4J- und LOG4J -API -Aufrufen kompatibel sind. Weitere Informationen finden Sie NumberOfLogStatements.java und die Testbeispiele ( NumberOfLogStatementsTest und fixtures/logs ) für weitere Informationen.
Hat Javadoc : Boolean, das angibt, ob eine Methode Javadoc hat. (Nur vorerst auf Methodenebene)
Modifikatoren : öffentliche/abstrakte/private/geschützte/native Modifikatoren von Klassen/Methoden. Kann mit org.eclipse.jdt.core.dom.Modifier decodiert werden.
Verwendung jeder Variablen : Wie oft wurde jede Variable in jeder Methode verwendet.
Verwendung jedes Feldes : Wie oft jedes lokale Feld in jeder Methode verwendet wurde, sind lokale Feld Felder innerhalb einer Klasse (Unterklassen sind nicht enthalten). Außerdem werden indirekte lokale Feldnutzungen erkannt. Indirekte lokale Feldnutzungen umfassen alle Verwendungen von Feldern innerhalb des lokalen Aufrufbaums einer Klasse, z.
Methodenaufrufe : Alle direkt aufgerufenen Methoden, Variationen sind lokale Aufrufe und indirekte lokale Aufrufe.
Hinweis: CK trennt Klassen, innere Klassen und anonyme Klassen. LOC ist die einzige Metrik, die nicht vollständig von den anderen isoliert ist, z. B. wenn a eine Erklärung einer inneren Klasse B hat, dann loc (a) = loc (Klasse A) + loc (innere Klasse B).
CK ist ein Java -Code -Metriken -Sammelwerkzeug, das zu einer einfachen Struktur gestoppt wird, die sich um drei Hauptpakete dreht:
Für die Kürze werden in dieser Dokumentation Paketpräfixe wie com.github.mauricioaniche.ck weggelassen.
CK die Orchestrierung des gesamten Metrikensammlungsprozesses. Es initialisiert Metrikfinder, verarbeitet die Dateipartitionierung basierend auf dem verfügbaren Speicher, legt AST -Parsers mit geeigneten Umgebungseinstellungen ein und verwaltet den Ausführungsfluss über verschiedene Verzeichnisse und Glasabhängigkeiten hinweg. Es passt sein Verhalten dynamisch anhand von Benutzereingaben wie useJars , maxAtOnce und variablesAndFields an, um die Verarbeitung von Java -Dateien für die Sammlung von Metriken zu optimieren.ck -Paket. Diese Klasse verarbeitet Befehlszeilenargumente zum Konfigurieren und Starten des Metrikensammlungsprozesses. Es übernimmt die Benutzereingabe für den Projektpfad, die Einschließung von JARs, die Dateipartitionierung, die Details und das Ausgabeverzeichnis -Setup. Runner organisiert die Gesamtausführung, indem sie die CK -Klasse initialisieren und nutzt und die Ergebnisse der Ergebnisse über ResultWriter nutzen.FileASTRequestor , eine Komponente des Eclipse JDT (Java Development Tools). Es spielt eine zentrale Rolle im CK -Framework, indem es den Metrikensammlungsprozess orchestriert. Die MetricsExecutor koordiniert die Erstellung des abstrakten Syntaxbaums (AST) für Java -Quelldateien, was für die Analyse und Extrahiere von Codemetriken unerlässlich ist. METRICSFINDER: Diese in ck.utils gelegene Versorgungsklasse spielt eine entscheidende Rolle bei der dynamischen Identifizierung und Instanziierung von metrischen Kollektorklassen innerhalb des CK -Frameworks. Es zielt auf Klassen ab, in denen die ClassLevelMetric und MethodLevelMetric -Schnittstellen aus dem metrics implementiert werden.
Der MetricsFinder verwendet die Reflections , um metrische Kollektorklassen zur Laufzeit zu scannen und zu laden, wodurch das CK -System erweiterbar und an neue Metriken angepasst werden kann, ohne Änderungen an der Kernarchitektur zu erfordern. Diese Funktion ist besonders nützlich, um benutzerdefinierte Metriken nahtlos in den Analyseprozess zu integrieren.
CKVISITOR: Als integraler Bestandteil des CK -Frameworks erweitert CKVisitor die ASTVisitor -Klasse, die in der Eclipse JDT -Bibliothek (Java Development Tools) bereitgestellt wird, und aktiviert eine detaillierte Analyse und metrische Sammlung direkt aus dem abstrakten Syntax -Baum des Java -Quellcodes (AST).
Der Besucher ist so konzipiert, dass er verschiedene Knoten des AST durchquert und z. B. Typen und Methoden an jedem Knoten angewendet wird. Es verwaltet effektiv eine stapelbasierte Hierarchie von Klassen und Methoden, sodass Metriken im Kontext des aktuellen Knotenbereichs berechnet und gesammelt werden können.
CKASTVISITOR: Implementiert durch metrische Klassen in ck.metrics , sodass jede Metrik bestimmte interessierende AST -Knoten verarbeiten kann, z. B. Methodenaufrufe und Klasseninstanzkreationen.
Klassenlevelmetrik und Methodlevelmetric: Schnittstellen, die Methoden zum Sammeln von Metriken auf Klassenebene bzw. Methodenebene definieren.
CKNotifier -Schnittstelle zu übertragen.CKMethodResult CKClassResult .CK Framework umfasst eine Reihe gut etablierter Entwurfsmuster, um die Modularität, Erweiterbarkeit und Wartbarkeit seiner Codebasis zu verbessern. Diese Muster ermöglichen es dem Framework, komplexe Operationen wie das Durchqueren abstrakter Syntaxbäume (AST), das Sammeln von Metriken und die Benachrichtigung der Ergebnisse effizient umzugehen. Im Folgenden finden Sie die wichtigsten Konstruktionsmuster:
Besuchermuster: Die Schnittstellen CKVisitor und CKASTVisitor implementieren das Besuchermuster, das bei der Handhabung von Operationen an verschiedenen AST -Knoten entscheidend ist, ohne die Klassen der Elemente zu ändern, auf denen es arbeitet. Dieses Muster ist besonders vorteilhaft in Szenarien, in denen eine Komponente unterschiedliche und nicht verwandte Operationen in einer Klassenhierarchie von AST -Knoten ausführen muss. Es vereinfacht den Code, indem die Betriebslogik in Besucherobjekte externalisiert wird, wodurch die Hinzufügung neuer Vorgänge erleichtert wird, ohne vorhandene Knotenklassen zu ändern. Diese Trennung von Bedenken führt zu einer wartbaren und erweiterbaren Codebasis, bei der AST -Knotenstrukturen und -Operationen auf sie entkoppelt sind.
Notifiermuster: CK nimmt das Notifier -Muster durch die Verwendung von CKNotifier an, das als zentraler Mechanismus fungiert, um die Ergebnisse der Metrikensammlung an alle registrierten Beobachter zu übertragen. Dieses Muster ist entscheidend für die Erstellung einer locker gekoppelten Architektur, bei der das Subjekt (metrischer Berechnungsprozess) unabhängig von seinen Beobachtern (Ergebnisprozessoren oder Berichtsgeneratoren) ist. Auf diese Weise kann CK mehrere Komponenten über den Abschluss von Metrikberechnungen ohne Kopplung an bestimmte Komponenten informieren, was die Flexibilität und Skalierbarkeit des Systems verbessert.
Fabrikmuster: Die Instanziierung von metrischen Sammlern wird von MetricsFinder verwaltet, die das Werksmuster verkörpert. Dieses Muster wird verwendet, um die Logik der Instanziierung spezifischer Metrik -Kollektorklassen auf der Grundlage von Laufzeitentscheidungen zu verkörpern. Das Werksmuster vereinfacht den Prozess des Hinzufügens neuer Arten von metrischen Sammlern, ohne den vorhandenen Code zu stören, und liefert eine Plug-and-Play-Architektur, bei der neue Metriken nahtlos eingeführt werden können. Es hilft auch bei der Aufrechterhaltung der Trennung von Bedenken, da der Prozess der Erstellung metrischer Objekte aus der Kernlogik der metrischen Sammlung isoliert wird.
Durch die Nutzung dieser Entwurfsmuster verwaltet CK die Komplexität effizient und stellt sicher, dass das Rahmen robust, anpassungsfähig und leicht zu erweitern bleibt, wenn neue Anforderungen und Metriktypen auftauchen.
Sie benötigen mindestens Java 8, um dieses Tool kompilieren und ausführen zu können.
Um die neueste Version zu verwenden (die Sie sollten), klonen Sie das Projekt und generieren Sie ein Glas. Ein einfaches mvn clean compile package generiert die Einzel -JAR -Datei für Sie (siehe Zielordner ).
Dann renn einfach:
java -jar ck-x.x.x-SNAPSHOT-jar-with-dependencies.jar
<project dir>
<use jars:true|false>
<max files per partition:0=automatic selection>
<variables and fields metrics?:true|false>
<output dir>
[ignored directories...]
Project dir bezieht sich auf das Verzeichnis, in dem CK den gesamten Quellcode für analysiert finden kann. CK sucht rekursiv nach .java -Dateien. CK kann die Abhängigkeiten des Projekts verwenden, um seine Präzision zu verbessern. Die use jars -Parametern der Verwendung von JARs fordert CK auf, nach .Jar -Dateien im Verzeichnis zu suchen und sie zu verwenden, um die Typen besser aufzulösen. Max files per partition geben JDT die Größe der Stapel an. Lassen Sie uns das für Sie entscheiden und beginnen Sie mit 0; Wenn Probleme auftreten (dh aus dem Gedächtnis), denken Sie daran, es zu stimmen. Variables and field metrics geben CK an, ob Sie auch Metriken auf Variablen- und Feldebene wünschen. Sie sind sehr feinkörnig und produzieren viel Leistung. Sie sollten es überspringen, wenn Sie nur Kennzahlen auf der Ebene oder Methodenebene benötigen. Schließlich bezieht sich output dir auf das Verzeichnis, in dem CK die CSV -Datei mit Metriken aus dem analysierten Projekt exportiert. Optional können Sie eine beliebige Zahl ignorierte Verzeichnisse angeben, die durch Leerzeichen getrennt sind (z. B. build/ ). Standardmäßig werden .git und alle anderen versteckten Ordner ignoriert.
Das Tool generiert drei CSV -Dateien: Klasse, Methode und variable Ebenen.
Lernen Sie mit gutem Beispiel voran. Siehe Runner.java -Klasse.
Siehe die neueste Version der Bibliothek im Abzeichen zu Beginn dieses Readme oder unter https://mvnrepository.com/artifact/com.github.mauricioaniche/ck.
Verwenden Sie das folgende Ausschnitt in Ihrem pom.xml. Aktualisieren Sie XYZ mit der neuesten Version des Tools (überprüfen Sie mvnrepository.com oder das Abzeichen zu Beginn dieser ReadMe -Datei):
<!-- https://mvnrepository.com/artifact/com.github.mauricioaniche/ck -->
<dependency>
<groupId>com.github.mauricioaniche</groupId>
<artifactId>ck</artifactId>
<version>X.Y.Z</version>
</dependency>
Sie können auch das CK Maven -Plugin verwenden, das von @JazzMuesli entwickelt wurde und das CK in Ihrem Projekt automatisch ausführt. Sehr nützlich für Entwickler: https://github.com/jazzmuesli/ck-mvn-plugin.
Dieses Tool verwendet die JDT Core -Bibliothek von Eclipse unter der Haube für AST -Konstruktion. Derzeit ist die Compliance -Version auf Java 11 eingestellt.
Benötigen Sie Unterstützung für eine neuere Sprachversion? Der Additionsprozess ist sehr einfach, da ein PR beigetragen hat:
pom.xml . Sie können einen Repository -Browser wie MVN -Repository verwenden, um diesen Prozess zu erleichtern.pom.xml die source und target des Maven -Compiler -Plugins entsprechend.CK.java an: [...]
ASTParser parser = ASTParser.newParser(AST.JLS11);
[...]
JavaCore.setComplianceOptions(JavaCore.VERSION_11, options);
[...]
Weil das Werkzeug geboren wurde, um nur die CK -Klassenlevelmetrics zu berechnen, aber es wurde über meine Erwartungen hinaus ... Das Leben ist lustig!
Bitte verwenden Sie den folgenden Bibtex -Eintrag:
@manual{aniche-ck,
title={Java code metrics calculator (CK)},
author={Maurício Aniche},
year={2015},
note={Available in https://github.com/mauricioaniche/ck/}
}
Sagen Sie einfach eine PR ein! :)
Diese Software ist unter der Apache 2.0 -Lizenz lizenziert.
