Automatisierte Source-Code-Metriken für C und C++

Cantata stellt mehr als 300 Source-Code-Metriken in C und C++ zur Verfügung. Das bedeutet für Sie: sinnvolle objektive Messung und Visualisierung nicht-funktionaler Eigenschaften des Quellcodes:

Das Messen nicht-funktionaler Eigenschaften umfasst die statische Prüfung des Quellcodes. So können verschiedene nicht-funktionale Merkmale in Bezug auf die Software bewertet werden. Diese Bewertung wird beim Build eines Cantata-fähigen Softwareprojekts aufgerufen. Wie die Analyse konfiguriert wird, dafür stehen folgende Methoden:

  • Analyse von Systemheadern aktivieren/deaktivieren
  • Die zu berechnenden statischen Analysemetriken festlegen (über eine Optionsdatei)
  • Zu analysierende Quelldateien, Funktionen oder Klassen angeben
  • Die zu analysierenden Quellcode-Anweisungen präzise angeben (durch Pragmas im Quellcode)

Cantata stellt Metriken für Codequalität und Codekomplexität zur Verfügung. Mit diesen Metriken können Anwender Bereiche des Codes ermitteln, in denen höchstwahrscheinlich Fehler auftreten. Gleichzeitig ermöglichen sie abzuschätzen, wie viel Zeit für das Testen erforderlich ist. Nachdem die Metriken von Cantata erfasst wurden, können sie mit einem Add-In für Microsoft Excel verarbeitet und bearbeitet werden.

Codekomplexität und -struktur

Cantata unterstützt Metriken zur Codekomplexität im prozeduralen Quellcode. Das verbessert die Wartbarkeit von Software durch objektive Messung mit anerkannten Metriken – sowohl „akademischen“ Metriken als auch solchen aus der Alltagserfahrung:

  • Halstead’s Software-Science-Metriken
  • Zyklomatische Komplexitätsmetriken nach McCabe, Myers und Hansen
  • Durchschnittlicher und maximaler Verschachtelungsgrad
  • Grundlegende Anzahl von Sprachkonstrukten (Kommentare, Codezeilen, Anweisungen, Parameter usw.)

Objektorientierte Implementierung

Neben der Messung der Codekomplexität für objektorientierten Code bietet Cantata auch eine Reihe von Metriken, mit denen Aspekte der objektorientierten Implementierung gemessen werden. Diese beinhalten:

  • Metrik-Set für Chidamber und Kemerer’s MOOSE
  • Metrik-Set für Fernando Brito e Abreu’s Mood
  • Metrik-Set für Bansiya and Davis‘ QMOOD
  • Robert Martins objektorientierte Abhängigkeitsmetriken
  • McCabes objektorientierte Metriken
  • Bansiyas Klassenentropie-Metriken

Alle Metriken werden entsprechend auf Funktionsebene, Klassenebene, Übersetzungseinheitsebene oder Systemebene bereitgestellt.

Abschätzen des Testaufwands

Wer wissen möchte, wie lange die Tests voraussichtlich dauern werden, sollte verstehen, wie komplex der Quellcode ist. Cantata Codemetriken verwenden branchenübliche Komplexitätsmetriken, um den Testaufwand für Quellelemente genau abzuschätzen. Ein Beispiel dafür: die zyklomatische Komplexität nach McCabe und seine Varianten. Aus deren Ergebnis ergibt sich die Mindestzahl an Testfällen, die erforderlich ist, um die Verzweigungen vollständig abzudecken.

Visualisierung und Berichterstellung von Metriken

Oft ist es hilfreicher, die Daten grafisch darzustellen. Datendiagramme erhöhen häufig das Verständnis für Trends und Zusammenhänge. Wer die Metriken nur als Zahlen sieht, dem fällt das in der Regel schwerer. Die Darstellung von Metriken kann auf Klassen-, Funktions- oder Kategorie-Ebene erfolgen.

Beispielanwendungen von Metriken

Cantata kann über 300 statische Metriken im Quellcode erstellen. Hier einige Beispiele für bestimmte Metriken und deren sinnvollste Anwendung. Ein vollständige Liste finden Sie im Cantata-Handbuch.

Standardmetriken zur Codegröße

Hier handelt es sich um einfache Metriken in Bezug auf die Anzahl der Codezeilen, Kommentare etc.

Name Description Scope
LINE_CODE Total number of lines of code (including blank lines and comments). Function or system
LINE_COMMENT Total number of lines of comments (both C and C++). Function or system
LINE_SOURCE Total number of lines of source code (not including blank lines or comments). Function or system

Standardmetriken zur Codequalität

Die Qualität einer Software hängt bis zu einem gewissen Grad von der Anzahl der Vorkommnissen von zweifelhaftem Code ab. Qualitätsmetriken machen den Benutzer auf solche Vorkommnisse aufmerksam.

Name Description Scope
LABEL_GOTOUSED Number of goto labels that are used. Function or system
LABEL_GOTOUNUSED Number of unused goto labels. Function or system
STMT_GOTO Number of goto statements. Function or system
SWITCH_NODEF Number of switch statements with no default. Function or system
SWITCH_FALLTHRU Number of non-empty case blocks which fall through to the next case block. Function or system
UNREACHABLE Number of statically unreachable statements in the given scope. Function or system

Standardmetriken zur Codekomplexität

Die Komplexität einer Software und der Aufwand für deren Wartung stehen im Allgemeinen im direkten Zusammenhang. Mit diesen Metriken wird versucht, die Komplexität der Software abzuschätzen. Dies geschieht auf Grundlage verschiedener Faktoren, zum Beispiel der Verschachtelungsebene.

Name Description Scope
HALSTEAD_PARAMS Number of parameters. Function
MCCABE The McCabe Cyclomatic Complexity value for the function. Function
NESTING_MAX Maximum statement nesting level. Function
NESTING_SUM Sum of the statement nesting levels for all statements in the function. Function

Objektorientierte Metriken für Spezialisten

Viele Standardmetriken sind immer noch auf objektorientierte (OO) Systeme anwendbar. Die maximalen Verschachtelungsebenen innerhalb von Funktionen gelten beispielsweise auch für Klassenmethoden. Es gibt jedoch auch eine Reihe spezifischer OO Metriken. Diese können sich auf eine bestimmte Klasse oder auf das gesamte System beziehen.

Name Description Scope
MAX_DEPTH Maximum length of inheritance path to ultimate base class. System
MOOD_AD Number of new attributes defined for this class. Class
MOOD_MD Number of new methods plus overridden methods defined for this class. Class
MOOD_AHF Proportion of attributes that are hidden (private or protected). Class
MOOD_MHF Proportion of methods that are hidden (private or protected). Class
MOOSE_CBO Level of coupling between objects.  The number of classes with which this class is coupled (via a non-inheritance dependency from this class to that, or vice versa). System
MOOSE_WMC_MCCABE Average McCabe Cyclomatic Complexity value of for all methods of the class (excluding inherited methods) defined in this translation unit. Class
MOOSE_LCOM98 Chidamber & Kemerer’s Lack of Cohesion of Methods metric (1998 definition).  The minimum number of disjoint clusters of (new or overridden) methods (excluding constructors), where each cluster operates on disjoint set of (new) instance variables. Class
MOOSE_RFC Chidamber & Kemerer’s Response for a class metric.  The number of methods or functions defined in the class or called by methods of the class. Class

Mit C++ verlieren die alten prozeduralen C-Metriken an Bedeutung. Neue Metriken haben ihren Platz eingenommen. Die beliebtesten sind MOOSE (Metrics for OO Software Engineering), MOOD (Metrics for OO Design) und QMOOD (Quality Metrics for OO Design). Dazwischen gibt es eine Reihe von Metriken, die helfen zu beurteilen, ob eine C++-Klasse bereit zum Test ist. Hier einige Beispiele:

Quality identified in source code EXAMPLE METRICS
Poor or Questionable Design

‘MCCABE Quality’

‘MOOSE Lack of Cohesion among Methods’

‘MOOD Attribute Hiding Factor’

Estimated Number of Faults

‘MOOD Methods Defined’

‘MOOD Attributes Defined’

‘MOOSE Weighted Methods in Class’

General Complexity

‘MOOSE Depth of Inheritance’

‘QMOOD Number of Ancestors’

‘MOOSE Number of Children’

Estimated Test Effort

‘Methods Available’

‘MOOSE Response for a Class’

‘MOOSE Coupling Between Objects’

‘MOOD Method Hiding Factor’

Zusätzliche Systemmetriken

Zusätzliche Metriken auf Systemebene können erstellt werden, indem Durchschnittswerte auf Basis verschiedener Klassen oder Funktionen gebildet werden. Zum Beispiel wird der Mittelwert der zyklomatischen Komplexität nach McCabe über alle Funktionen und Methoden im System berechnet.