Mehr Qualität und schnellere Marktreife durch effiziente Softwaretests Workshop Mehr Qualität und schnellere Marktreife durch effiziente Softwaretests Technologiepark Offenburg 24. April 2008 Während wir im zweiten Teil uns angeschaut haben, wie wir Fehler finden, soll nun gezeigt werden, wie man im Vorfeld SW-Fehler verhindern kann. Wie senkt man die Fehleranfälligkeit?

Inhalt Motivation 2. Software-Metriken 2.1 Code-Metriken 2.2 Anwendung von Code-Metriken 3. Code-Metriken im Detail 3.1 Lines of Code 3.2 Halstead 3.3 McCabe 3.4 Maintainability Index 4. Beispiel Linux Kernel 2.6.16.60

1. Motivation Vergleich Klassische Produkte Software Kennzahlen Qualitätssicherung Bewertung Klassische Produkte Software va_list args; char module_name[MODULE_NAME_LEN]; unsigned int max_modprobes; int ret; char *argv[] = { modprobe_path, "-q", "--", module_name, NULL }; static char *envp[] = { "HOME=/", "TERM=linux", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL }; static atomic_t kmod_concurrent = ATOMIC_INIT(0); #define MAX_KMOD_CONCURRENT 50 static int kmod_loop_msg; va_start(args, fmt); Qualitätssicherung Bewertung Software-Metriken Animation

1. Motivation Komplexe Softwaresysteme Eingeschränkte Testbarkeit Höhere Fehleranfälligkeit Eingeschränkte Testbarkeit Geringere Wartbarkeit Produktqualität Kosten Komplexität der Software Beispiel (aus www.wikipedia.de) Millionen LOC 1993 Windows NT 3.1 4-5 1994 Windows NT 3.5 7-8 1996 Windows NT 4.0 11-12 2000 Windows 2000 > 29 2001 Windows XP 40 2005 Windows Vista Beta 2 50 t

2. Software-Metriken Klassifikation Software-Metriken Produkt-Metriken (Produktqualität) Metriken zu Anforderungen Design-Metriken Code-Metriken Test-Metriken (C0, C1, …) … Prozess-Metriken (Prozessqualität) Softwareentwicklungsprozesse Projektmetriken Reifegradmodelle (CMMI, …) … Inhalt dieses Vortrages: Code-Metriken Siehe auch: [FP07], [LZ06], [Lig02]

2.1 Code-Metriken Übersicht wichtiger Code-Metriken Lines of Code LOC Maintainability Index MI Halstead V, N, n, … McCabe v(G) Diese Code-Metriken sind auch auf objektorientierte Sprachen anwendbar

Code-Metriken liefern Hinweise quantitativ und reproduzierbar Verwendung und empirische Studien Jede Code-Metrik bewertet jeweils einen Teilaspekt der Software Code-Metriken dienen als Basis, um Aussagen bezüglich Fehleranfälligkeit, Testbarkeit und Wartbarkeit zu machen. Code-Metriken liefern Hinweise quantitativ und reproduzierbar Studie aus [Wa89]: Korrelation von 0.8 zwischen McCabe Code-Metrik und Fehlerdichte (HP, Waltham Division) Weitere Studien zur McCabe Code-Metrik sind in [WC96] zu finden. Neuere Studien: [FO00] und [CS00] Eine Vergleichbarkeit der Studien ist nur eingeschränkt möglich

2.1 Code-Metriken Generierung Parser Sourcen werden nur geparst *.cpp *.h Sourcen werden nur geparst Keine Testumgebung notwendig Tests werden nicht ausgeführt Bsp. Linux-Kernel 16383 Funktionen (C) Dauer 4 Sekunden

Ausführbares Programm 2.2 Anwendung von Code-Metriken Szenarien Dynamische Testverfahren Intensiveres Testen kritischer Funktionen (Testprinzip: Test besonderer Werte) Dokumentation Audits usw. Ausführbares Programm Build Refactoring Wartung Neuimplementierung von Funktionen Statische Testverfahren Kritische Funktionen können einer Inspektion (Review) unterzogen werden. Code „Eingangs- Kontrolle“ Code-Metriken müssen innerhalb vorgegebener Grenzen liegen SW- Entwicklung SW- Entwicklung Animationen --- schrittweise aufbauen Outsourcing Offshoring Inhouse

3. Code-Metriken im Detail 3.1 Lines of Code LOC 3.4 Maintainability Index MI 3.3 McCabe v(G) 3.2 Halstead V, N, n, …

3.1 Lines of Code Prinzip Die Anzahl der Programmzeilen (Lines of Code LOC) pro Funktion oder Modul liefert einen Hinweis auf deren Komplexität LOC Code-Metriken LOCphy: Gesamtanzahl der Zeilen (physical lines) LOCpro: Anzahl der Programmzeilen (program lines) LOCcom: Anzahl der Zeilen mit Kommentar (commented lines) LOCbl: Anzahl der Leerzeilen (blank lines) Empfehlungen aus [CL07]: LOCphy pro Funktion <40 LOCphy pro Datei <400 LOCcom/LOCphy sollte zwischen 0,3 und 0,75 liegen

3.2 Halstead Prinzip N1: Gesamtanzahl der verwendeten Operatoren Halstead-Metriken [Hal77] berücksichtigen verschiedene Eigenschaften der Software. Nach [Lig02] wurden diese Code-Metriken mit Erfolg empirisch validiert. N1: Gesamtanzahl der verwendeten Operatoren n1: Anzahl der unterschiedlichen Operatoren N2: Gesamtanzahl der verwendeten Operanden n2: Anzahl der unterschiedlichen Operanden Operatoren % 1 () 3 , 1 ; 2 == 1 else 1 if 1 { } 1 Operanden „case2“ 1 „case3“ 1 1 1 a 2 b 2 int 2 printf 2 test 1 void 1 void test (int a, int b) { if (a%b == 1) printf("case2"); else printf("case3"); } N1 = 11 n1 = 8 N2 = 13 n2 = 9

3.2 Halstead Halstead Code-Metriken Größe des Vokabulars: Länge der Implementierung: Programmgröße: Schwierigkeitsgrad: Programmniveau Aufwand: Implementierungszeit: Anzahl ausgelieferter Fehler: Empfehlungen aus [CL07]: V einer Funktion sollte im Bereich zwischen 20 und 1000 liegen V einer Datei sollte im Bereich zwischen 100 und 8000 liegen

3.3 McCabe Prinzip Die Komplexität nach McCabe v(G) [McC76] beruht auf dem Kontrollflussgrafen G. Knoten (nodes) e: Anzahl der Kanten n: Anzahl der Knoten p: Anzahl der Komponenten Wird v(G) einer Funktion bestimmt, so ist p = 1 zu setzen. Wird v(G) eines Programms / Moduls bestimmt, so ist p gleich der Anzahl der Funktionen. Kanten (edges) Kontrollflussgraf G einer Funktion

3.3 McCabe Beispiele Vier Basis-Kontrollstrukturen v(G) = v(G) = ia = ib + 1; *pi = ia; if (a == 10) b = 5; else b = 10; while (a < 10) { a = a + 2; } do { a = a + 2; } while (a < 10); v(G) = v(G) = v(G) = v(G) =

3.3 McCabe Beispiele Bestimmung von v(G): Gleichung Regionenmethode Graf ist kreuzungsfrei. v(G) entspricht der Anzahl eingeschlossener Regionen + 1 v(G) = v(G) =

3.3 McCabe Beispiele Zeichnen Sie die beiden Kontrollflussgrafen und bestimmen Sie jeweils v(G)! if (a == 10 && c < 10) { b = 5; } if (a == 10) { if (c < 10) b = 5; } Zusammengesetzte Kontrollstrukturen sind zur Bestimmung von v(G) aufzulösen. Erkenntnis bezüglich zusammengesetzter Kontrollstrukturen:

3.4 McCabe Interpretation von v(G) Empfehlungen v(G) einer Funktion sollte begrenzt sein v(G) <= 15 [CL07] v(G) <= 10 [McC76] Ursache für hohes v(G) obwohl die betrachtete Funktion übersichtlich ist: Mehrere catch-Blöcke beim Exception-Handling (jedes catch erhöht v(G) um 1) switch–Kontrollstruktur mit vielen case-Blöcken Was tut man, wenn v(G) die vorgegebenen Grenzen übersteigt? Funktion ist in mehrere kleinerer Funktionen aufzuteilen! Diese sind danach wartbarer, testbarer und fehlerunanfälliger.

3.4 Maintainability Index Prinzip Der Maintainability Index MI setzt sich aus anderen Code-Metriken zusammen. Anwendbar auf Funktionen, Module und Programme! Empfehlungen aus [CL07]: MI >= 85: Gute Wartbarkeit MI im Bereich zwischen 65 und 85: Mäßige Wartbarkeit

4. Beispiel Linux Grundlage der Untersuchungen Linux Kernel 2.6.16.60 Unterverzeichnis /kernel 16383 Funktionen (C) Werkzeug CMT++ Dargestellte Code-Metriken als Verteilung LOCpro (Program Lines of Code) McCabe v(G) Halstead-Metrik V Maintainability-Index MI Abhängigkeiten LOCpro = f (v(G)) LOCpro = f (V) V = f(v(G))

4. Beispiel Linux Empfehlung [CL07]

4. Beispiel Linux Empfehlung [CL07]

4. Beispiel Linux Empfehlung [CL07]

4. Beispiel Linux Empfehlung [CL07]

4. Beispiel Linux

4. Beispiel Linux

4. Beispiel Linux

Zusammenfassung Anwendungsszenarien und empirische Studien Quantitative und reproduzierbare Metriken (Kennzahlen) sind notwendig Anwendungsszenarien und empirische Studien Code-Metriken im Detail - Lines of Code - Halstead - McCabe - Maintainability Index Code-Metriken angewendet auf Linux Kernel 2.6.16.60 - Die meisten Funktionen erfüllen die Vorgaben - Korrelation zwischen LOCpro und v(G) erkennbar