Codemetriken sind Kennzahlen, die aus den Inhalten und der Struktur des Programmcodes eines Projekts ermittelt werden. Diese Kennzahlen sind ein wichtiges Hilfsmittel des Qualitätsmanagements im Projekt. Codemetriken werden gewöhnlich mit einem Werkzeug aus der aktuellen Codebasis extrahiert und sind Artefakte des Projekts. Dieser Artikel erläutert die wichtigsten Metriken.
Das ist keine wirkliche Kennzahl, sondern eine Aussage über die Qualität der Komponentenstruktur allgemein. Sind Komponenten voneinander zyklisch abhängig, dann bilden sie eine Compiliereinheit. Damit lässt sich für keine Komponenten sinnvoll eine von den anderen Komponenten des Zyklus unabhängige Schnittstelle oder Funktionalität definieren. De facto handelt es sich also nicht um getrennte Komponenten, sondern um eine große Komponente.
Die meisten Kennzahlen im Projekt sind bei zyklischen Abhängigkeiten nicht sinnvoll auszuwerten. Wenn ein Zyklus identifiziert ist, muss zunächst entschieden werden, ob aus architektonischer Sicht eine Auftrennung des Zyklus überhaupt sinnvoll ist. Wenn nicht fasst man den Zyklus als Komponente zusammen. Wenn ja kann formal mittels Refactoring wie in der Einleitung beschrieben immer ein Aufbruch des Zyklus erreicht werden.
ACD - Average Component Dependency
Diese Kennzahl ist paketbasiert. Sie zählt zu jedem Paket alle direkt oder indirekt referenzierten Pakete. Ein vollkommen unabhängiges Paket bekommt den Wert 1 (es hängt nur von sich ab). Die ACD ergibt sich als der Durchschnitt dieses Werts über alle Pakete. Ein Wert von 1 sagt dann aus, dass alle Pakete isoliert sind, der maximal mögliche Wert ergibt sich als die Zahl aller Pakete und signalisiert, dass jedes Paket von jedem abhängt. Die ACD muss also immer im Zusammenhang mit der Anzahl der Pakete gesehen werden.
Die ACD im Verhältnis zur Anzahl der Pakete muss möglichst klein sein. Eine hohe ACD ist ein Zeichen für mangelhafte objektorientierte Architektur und Design. Ein Refactoring der betroffenen Pakete und der Einsatz von geeigenten Designpatterns sind Mittel zum Erreichen dieses Ziels.
Metriken nach Robert C. Martin
Diese Metrik bestimmt den Ort eines Paketes in einem Abstraktheit-Instabilität-Diagramm. Hört sich kompliziert an, ist aber alles sehr einfach über zwei Kennzahlen zu ermitteln:
RMI - Instabilität, CE/(CA + CE)Eine Zahl von 0 bis 1. 0 heißt, das Paket ist vollkommen unabhängig von Code außerhalb des Pakets. Änderungen dort haben keine Auswirkung auf das Paket, es ist also maximal stabil. 1 heißt im Gegenteil, dass jede Änderung im Projekt zu einer Anpassung im Paket führt, das Paket ist maximal instabil.
RMA - Abstraktheit, Die Zahl abstrakter Typen (Interfaces, abstrakte Klassen) dividiert durch die Gesamtzahl der Typen des Pakets.Auch das ist eine Zahl von 0 bis 1. Null heißt, dass das Paket keinen einzigen abstrakten Typen besitzt, 1, dass es nur aus abstrakten Typen besteht.
Nun erwarten wir folgende Regel. Ein Paket mit geringer Abstraktheit (mit vielen konkreten Implementierungen) darf eher instabil sein, denn es hängt ja dann bei gutem Design von vorgegebenen, möglichst abstrakten Typen anderer Pakete ab. Ein Paket hoher Abstraktion sollte möglichst stabil sein (wenig Abhängigkeiten nach außen haben). Wäre es instabil, dann überträgt es seine Instabilität auch auf alle anderen abhängigen Pakete. Optimalen Kombinationen für (RMI, RMA) sind also (0, 1) und (1, 0). Die Linie, die beide Punkte verbindet beschreibt weitere mögliche gute Punkte und wird in Anlehnung an das Sternentwicklungsdiagramm "Hauptreihe" (Main Sequence, ich verweise auf den exzellenten Artikel in Wikipedia) genannt:
RMD = A + I - 1: Distanz von der HauptreiheJe dichter diese Zahl bei 0 ist, ja näher das Paket an der Hauptreihe liegt, desto höher die Wahrscheinlichkeit, dass es sich um ein gut designedtes Paket handelt. Pakete unterhalb der Hauptreihe (RMD ist negativ) sind tendenziell "nutzlos": sie bestehen aus konkreten Implementierungen gegen keine Schnittstellen im Projekt. Solche über der Hauptreihe sind tendenziell "chaotisch": Vermischung von Schnittstellendefinitionen mit konkreter, abhängiger Implementierung.
MCC - McCabe Cyclomatic Complexity
Die MCC zählt innerhalb von Methoden die möglichen Programmzweige, die durch if, for, while, do, case, catch, den ternären Operator oder logische Operatoren entstehen können. Methoden mit hoher MCC sind Kandidaten für eine Zerlegung in mehrere Methodenfragmente.
Kopplungsgrad innerhalb eines Typcontainers. Gibt einen Hinweis auf die Möglichkeit zur Zerlegung der Komponente in Subkomponente.