CMT++ und CMTJava Metrikentools
CMT++ und CMTJava gibt unter anderem eine Einschätzung darüber ab, wie viele
Bugs das Programm wahrscheinlich auf Grund seiner Komplexität
enthält und wie lange man braucht, um die Software zu verstehen.
Da die Zeit, die in Projekten für Softwaretests zur Verfügung
steht, normalerweise beschränkt ist, kann mit CMT++ bzw. CMTJava eine Auswahl
der Codeteile erfolgen, die unbedingt getestet werden sollten.
Die Schwerpunkte
des Softwaretests können also am "richtigen Ort" angesetzt
werden.
CMT++ und CMTJava berechnen die folgenden Softwaremetriken:
- a) McCabes Cyclomatic Number weitere Informationen
- b) Lines-of-code-Metriken weitere Informationen
- c) Halsteads Metriken weitere Informationen
- d) Maintainability Index weitere Informationen
a) McCabe Cyclomatic Number v(G)
Die Cyclomatic Number v(G) gibt die Komplexität des Steuerflusses
eines Programms an. Für eine einzelne Funktion ist v(G) eins
niedriger als Anzahl der Verzweigungspunkte im Programm. Je größer
die Cyclomatic Number ist, desdo schwieriger ist die Software zu
verstehen.
Die Cyclomatic Number einer Funktion sollte nicht größer
als 15 sein. Mehr als fünfzehn Pfade sind schwierig zu
identifizieren und zu testen. Eine Ausnahme hiervon sind lediglich
"selection statements" mit mehreren Verzweigungen. Eine vernünftige
Obergrenze von v(G) für eine Datei liegt bei 100.
weitere Informationen über McCabe Cyclomatic Number
weitere Information über McCabe-Metriken vom Software Engineering Institute der Carnegie Mellon University
b) Lines-of-code-Metriken
Lines-of-code-Metriken sind die ältesten Metriken für
Softwarekomplexität.
CMT++ und CMTJava berechnen die folgenden Line-of-Code-Metriken:
| LOCbl | Anzahl der Leerzeilen |
|
LOCcom | Anzahl der Kommentarzeilen |
| LOCphy | Anzahl aller Zeilen |
| LOCpro | Anzahl der Zeilen mit Programmcode (inkl. Kommentarzeilen) |
Eine Funktion sollte zwischen 4 und 40, eine Datei zwischen 4
und 400 Programmzeilen haben.
Dateien, die über 400 "lines of code"
haben, sind in der Regel zu lang, um als Einheit verstanden zu
werden.
Der Anteil der Kommentarzeilen sollte zwischen 30 und 75 %
liegen.
weitere Informationen über Lines-of-Code-Metriken
c) Halstead's Metriken
| B | B ist ein Wert für die wahrscheinliche Fehleranzahl
eines Programms. Die pro Datei ausgelieferte Bug-Anzahl sollte auf jeden Fall unter 2 liegen. Erfahrungsgemäß ist die Anzahl der Bugs in C bzw. C++ Dateien i.d.R. höher als durch B angegeben. |
| D | Schwierigkeitsniveau, Störungsneigung |
| E | Implementierungsaufwand |
| L | Programmniveau = Abstraktionsniveau des Programms |
| N | Programmlänge = Anzahl der Gesamtzahl der verwendeten Operatoren +
Gesamtzahl der verwendeten Operanden
N = N1 + N2 |
| N1 | Gesamtzahl der verwendeten Operatoren |
| N2 | Gesamtzahl der verwendeten Operanden |
| n | Vokablulargröße (Anzahl unterschiedlicher
Operatoren und Operanden), n = n1 +n2 |
| n1 | Anzahl unterschiedlicher Operatoren |
| n2 | Anzahl unterschiedlicher Operanden |
| T | notwendige Zeit um einen Programmteil zu verstehen |
| V | Programmvolumen bzw. Informationsgehalt des
Programms Halsteads Volume V gibt die Implementierungsgröße eines Algorithmus an. V sollte für eine Funktion zwischen 20 und 1000 liegen. Bei Volumen über 1000 macht die Funktion zu viele Dinge. Das Volumen V einer Datei sollte zwischen 100 und 8000 liegen. Diese Limits basieren auf Volumenmessungen für Dateien, deren Programmierzeilenanzahl und Cyclomatic Number an den empfohlenden Grenzen liegen. |
weitere Informationen über Halstead-Metriken
weitere Information über Halstead´s Metriken vom Software Engineering Institute der Carnegie Mellon University
d) Maintainability Index (Wartungsindex)
Der Maintainability Index ist ein Zahlenwert zur Bestimmung der Wartungsfreundlichkeit
(Maintainability) von Softwarecode.
Der Maintainability Index wird mit bestimmten Formeln errechnet, die auf den
Lines-of-Code-Metiken, den McCabe- und Halstead-Metriken basieren.
Die Messung der Maintainability hilft unter anderem dabei festzustellen, wann es
günstiger bzw. weniger riskant ist, Codeteile neu zu schreiben anstatt sie
zu verändern.
Interpretation der CMT++/CMTJava Metriken
Module, die eine hohe Komplexität haben, müssen sehr sorgfältig getestet werden. Was unter hoher Komplexität zu verstehen ist, hängt vom Entwicklungsprozeß und den Qualitätskriterien des Projektes ab. Absolute und überall gültige Werte für noch akzeptable Metriken können daher nicht gegeben werden. Die von CMT++ bzw. CMTJava angegebenen Limits geben gute Anhaltspunkte. Die CMT++/CMTJava Alarmlimits basieren auf anerkannten Erfahrungen mit Programmen, die als vorbildlich gelten. Die Alarmlimits können jedoch an die jeweiligen Projekterfordernisse angepaßt werden.
Bezüglich der dynamischen Tests sind die Cyclomatic Number v(G)
und die "Number of delivered bugs" (B) die wichtigsten Metriken.
Die Cyclomatic Number gibt die "Control Flow Complexity" an.
Hierdurch ergibt sich, daß Module und Funktionen mit hoher
Cyclomatic Number mehr Tests benötigen als solche mit einer
niedrigen Cyclomatic Number. Für jede Funktion sollten mindestens
so viele Testfälle gemacht und Fehler aufgedeckt werden, wie ihre
Cyclomatic Number angibt.
CMT++/CMTJava Produkteigenschaften
CMT++ und CMTJava sind für schnelle Arbeitsweise, einfache Handhabung und stabiles Arbeiten - im Fall von CMT++ selbst mit nicht C-präprozessiertem Code - bekannt.Die Anforderungen für eine Installation von CMT++ bzw. CMTJava sind vergleichsweise bescheiden: je nach Plattform reichen 1-2 MB Speicherplatz aus.
Weitere Informationen
Übersicht über die letzten CMT++ bzw. CMTJava-Releases
Produktpräsentation (17 Slides)
Komplexität und Qualität
von Software (Artikel aus MSCoder) (738 KB)
weitere Informationen über
CMT++ (in Englisch) bzw.
CMTJava (in Englisch)
fordern Sie CMT++/CMTJava kostenlos zur Evaluation an.
last updated: 26.06.2007
© 2003-2007 Verifysoft GmbH
CTA++, CTC++, CMT++ and CMTJava are products of Testwell Oy, Tampere (Finland)
all other trademarks of this site are the property of their respective owners.
