Statische Programmanalysen für die Qualitätssicherung

Transkript

1 die ssicherung Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen 7. Juli 2009

2 Wer wir sind die ssicherung Bereich Softwarequalität und -sicherheit Forschungskooperation Universität Bremen Universität Stuttgart Axivion GmbH Stopping Software Erosion Literatur

3 nach ISO/IEC-Standard 9126 (2001) Änderbarkeit Übertragbarkeit Stabilität Prüfbarkeit Analysierbarkeit Reife Modifizierbarkeit Austauschbarkeit Installierbarkeit Konformität Anpassbarkeit Zuverlässigkeit Benutzbarkeit Funktionalität Verständlichkeit Erlernbarkeit Bedienbarkeit Effizienz Ordnungsmäßigkeit Angemessenheit Interoperabilität Sicherheit Richtigkeit Verbrauchsverhalten Softwarequalität Wiederherstellbarkeit Fehlertoleranz Zeitverhalten die ssicherung Literatur

4 Prüfung (Frühauf u. a., 2000) Software Prüfung nicht mechanisch (durch Menschen) Reviews Inspektionen mechanisch (durch den Rechner) statisch Programm analysen dynamisch Tests die ssicherung Literatur

5 Programmanalyse Programmanalyse = eines Programms anhand des Programmtexts, d.h. ohne Ausführung des Programms. Frühe Beispiele: Compiler Lint (1979): Aufspüren von gefährlichen Konstrukten, z.b. uninitialisierte Variablen, Überprüfung von einheitlichem Quelltext-Layout, Erkennen nicht portabler Konstrukte die ssicherung Ziele Vorgehen Probleme Statisch vs. dynamisch

6 Ziele /Sicherheitsprobleme Codierrichtlinienprüfung innerer Auffinden von Bad-Smells statische die ssicherung Ziele Vorgehen Probleme Statisch vs. dynamisch

7 1 v o i d count ( i n t t, i n t a ) { 2 FILE f ; 3 c h a r c ; 4 f = fopen ( " f i l e. t x t ", " r " ) ; 5 i f ( f!= NULL) { 6 t = 0 ; a = 0 ; 7 c = f g e t c ( f ) ; 8 w h i l e ( c!= EOF) { 9 i f ( c == a ) a = a + 1 ; 10 t = t + 1 ; 11 c = f g e t c ( f ) ; 12 } 13 c l o s e ( f ) ; 14 } 15 } 16 i n t main ( ) { 17 i n t t, a ; 18 count (&t, &a ) ; 19 p r i n t f ( "%f \n", ( f l o a t ) a /( f l o a t ) t ) ; 20 } die ssicherung Ziele Vorgehen Probleme Statisch vs. dynamisch

8 Schritte der statischen Programmtext Programmtext mit Makros Parser Zwischendarstellung Zwischensprachengenerator Präprozessor abstrakter Syntaxbaum annotierter abstrakter Syntaxbaum semantische n Lexer Ausgabe Tokenstrom Front-End die ssicherung Ziele Vorgehen Probleme Statisch vs. dynamisch

9 Typisches Vorgehen bei statischer Abstrakte statische Ausführung: 1 Repräsentation des Programms (meist als Kontrollflussgraph (KFG)) 2 Modell des Programmzustands 3 Transferfunktion jedes Programmkonstrukt 4 Inferenz beginnend mit Initialzustand über die Programmrepräsentation die ssicherung Ziele Vorgehen Probleme Statisch vs. dynamisch

10 Repräsentation des Programms 1 v o i d count ( i n t t, i n t a ) { 2 FILE f ; 3 c h a r c ; 4 f = fopen ( " f i l e. t x t ", " r " ) ; 5 i f ( f!= NULL) { 6 t = 0 ; a = 0 ; 7 c = f g e t c ( f ) ; 8 w h i l e ( c!= EOF) { 9 i f ( c == a ) 10 a = a + 1 ; 11 t = t + 1 ; 12 c = f g e t c ( f ) ; 13 } 14 c l o s e ( f ) ; 15 } 16 } (a) Code false f = fopen("file.txt","r") false entry count f!= NULL *t = 0 *a = 0 c = fgetc (f) c!= EOF true true c == a *a = *a + 1 false *t = *t + 1 c = fgetc (f) exit true close (f) (b) KFG die ssicherung Ziele Vorgehen Probleme Statisch vs. dynamisch

11 Modell des Programms Modellzustand 1: Variable ist sicher uninitialisiert vielleicht uninitialisiert sicher initialisiert Modellzustand 2: Variable ist vielleicht = 0 sicher 0 entry count f = fopen("file.txt","r") false f!= NULL true *t = 0 *a = 0 c = fgetc (f) false c!= EOF true true c == a *a = *a + 1 false *t = *t + 1 c = fgetc (f) close (f) exit die ssicherung Ziele Vorgehen Probleme Statisch vs. dynamisch

12 Transferfunktion und Inferenz Modellzustand 1: Konstrukte... Deklaration sicher uninitialisiert Zuweisung sicher initialisiert Beginn eines Blocks: Variable initialisiert alle Vorgänger initialisiert Variable sicher uninitialisiert alle Vorgänger sicher uninitialisiert sonst vielleicht uninitialisiert entry count f = fopen("file.txt","r") false f!= NULL true *t = 0 *a = 0 c = fgetc (f) false c!= EOF true true c == a *a = *a + 1 false *t = *t + 1 c = fgetc (f) close (f) exit die ssicherung Ziele Vorgehen Probleme Statisch vs. dynamisch

13 Werkzeuge zur Open-Source: FindBugs PMD Splint (LCLint) Kommerziell: Polyspace Coverity Klocwork PC-Lint die ssicherung Ziele Vorgehen Probleme Statisch vs. dynamisch

14 Probleme statischer n Aliasing Polymorphismus und dynamisches Binden Reflection Parallelität verteilte Systeme Laufzeitinstanzen versus statischer Einheiten (z.b. Klassen) viele Entscheidungen erst zur Laufzeit statische problematisch die ssicherung Ziele Vorgehen Probleme Statisch vs. dynamisch

15 Statisch vs. Dynamisch statisch dynamisch wirklich die ssicherung dynamisch: zu konkret, nicht verallgemeinerbar Teilmenge statisch: zu abstrakt, daher ungenau Obermenge Wahrheit liegt (meist) dazwischen y = f(x); if (y < 0) y = -y; Dynamisch: y {0, 2, 7, 79} Statisch: 0 y MAX_INT Wirklich: 0 y 100 Ziele Vorgehen Probleme Statisch vs. dynamisch

16 dreieck Kosten (CPU, RAM) die ssicherung Präzision 0 Vollständigkeit Ziele Vorgehen Probleme Statisch vs. dynamisch

17 zur Suche nach wiederkehrenden Programmierfehlern und Sicherheitsproblemen, z.b. Null-Zeiger-Dereferenzierung uninitialisierte Variable Zeiger auf freigegebene Objekte Division durch Null Out-of-Range-Zugriffe Buffer-Overflow... findet keine Abweichungen von der Spezifikation statische Prüfung kann Tests nicht ersetzen, nur ergänzen die ssicherung Literatur

18 Code-Richtlinienprüfung 1 i f ( b = 2) 2 x [ i ] = i ++; 3 a = 2 ; Allgemeine Standards, z.b. MISRA-C 1, MISRA-C++ Best Practices zur Vermeidung fehlerträchtiger Programmierkonstrukte mehr als 100 Regeln nicht alle sind prüfbar (z.b. sinnvolle Kommentierung) Organisationsspezifische Richtlinien, z.b richtige Verwendung von APIs organisationseinheitliches Layout 1 Motor Industry Software Reliability Association (MISRA) die ssicherung Literatur

19 Werkzeuge zur Prüfung von Code-Richtlinien Open-Source Checkstyle oft auch eingebaut in den Compiler Kommerzielle: Axivion Bauhaus Suite Parasoft SemanticDesigns QA/C die ssicherung Literatur

20 Cockpit (Dashboard) Process.Changes Performance.Time Test.Coverage Resources.Developers Code.Comments Code.Complexity die ssicherung Cockpit Vorhersagemetriken Trends

21 Ziel: Ökonomische ssicherung Ziel: Fehler so früh wie möglich finden Code-Reviews Tests Ökonomieprinzip: Fokussierung der Maßnahmen Verwendung eines Vorhersagemodells die ssicherung Cockpit Vorhersagemetriken Trends

22 Code-Metriken Klassische prozedurale Metriken: Lines-of-Code (LOC) McCabe Complexity (Anzahl der Bedingungen) Halstead-Volumen (N log(n) mit N = Gesamtzahl Tokens und n = Anzahl verschiedener Tokens)... Objektorientierte Metriken: Tiefe der Vererbungsbaums Anzahl von Methoden und Attribute Anzahl redefinierter Methoden... Änderungsmetriken: Churn (Anzahl geänderter, hinzugefügter oder gelöschter Zeilen) die ssicherung Cockpit Vorhersagemetriken Trends

23 Metriken zur Vorhersage fehlerhafter Module Defects Optimal rpart Random Forest Bagging die ssicherung Cockpit Vorhersagemetriken Trends Lines of Code Mende und Koschke (2009); Mende u. a. (2009)

24 Trend-: Modularisierung die ssicherung Cockpit Vorhersagemetriken Trends

25 Trend-: Kommentierung die ssicherung Cockpit Vorhersagemetriken Trends

26 Stink Parade of by Fowler (2000) duplizierter Code lange Funktionen oder Methoden große Module oder Klassen lange Parameterlisten divergente Änderung eine Klasse/ein Modul wird stets geändert in verschiedener Weise und unterschiedliche Gründe Schrotflinten-Chirurgie (Shotgun Surgery) kleine Änderungen überall Feature-Neid ein Modul/eine Klasse benutzt sehr viele Variablen/Attribute einer anderen Klasse bzw. eines anderen Moduls... die ssicherung Klone Code Quality Literatur

27 Duplizierter Code die ssicherung Klone Code Quality Literatur

28 Studien zu Auswirkungen von Klonen Monden u. a. (2002): 2,000 Cobol-Module mit Klonen mit mindestens der Länge 30 Zeilen (1 MLOC, 20 Jahre alt) Korrelation von max. Klonlänge und Fehlerrate höchste Fehlerdichte in Modulen mit mind. 200-Zeilen langem Klon die ssicherung Klone Code Quality Literatur

29 Studien zu Auswirkungen von Klonen Hypothese (Chou u. a., 2001) Wenn eine Funktion/Datei/Verzeichnis einen Fehler hat, dann ist es wahrscheinlicher, dass sie noch weitere Fehler hat. Beobachtungen in ihrer Studie Linux und OpenBSD: Hypothese gilt insbesondere, wenn die sich Ignoranz von API-Regeln mit Copy&Paste paart Programmierer glauben, dass operationaler Code korrekter Code ist Code kann fehlerhaft sein oder in einen Kontext kopiert werden, den er nicht gedacht war die ssicherung Klone Code Quality Literatur

30 Studien zu Auswirkungen von Klonen Li u. a. (2006) Linux-Kernel, FreeBSD, Apache, PostgreSQL: Fehler wegen Klonen, deren Bezeichner inkonsistent umbenannt wurden die ssicherung Klone Code Quality Literatur

31 Studien zu Auswirkungen von Klonen Fehler durch inkonsistent geänderte Klone (Juergens u. a., 2009) 52 % aller Klone wurden inkonsistent geändert 28 % aller inkonsistenter Klone waren ungewollt inkonsistent geändert 15 % aller inkonsistenter Klone sind Fehler die ssicherung Klone Code Quality Literatur

32 Wie können Klone gefunden werden? Granularität Klassen, Dateien Funktionen Anweisungen Vergleich von... Text Bezeichnern Token Syntaxbäume Verwendete Techniken: textuelles Diff Dotplot Data Mining Suffix-Bäume Baumvergleich Graphvergleich Information Retrieval Kontroll- und Datenabhängigkeiten Metrikenvergleich Hashing die ssicherung Klone Code Quality Literatur

33 Code Quality Index (Simon u. a., 2006) Aufwand Bauchgefühl Code Quality Index manuelles Review Objektivität, Genauigkeit Quality-Benchmark-Level auf Basis eines statisch ermittelten, objektiven Code-Quality-Index: 52 sindikatoren (Typen von ) Häufigkeitsverteilung mehr als 120 industrielle Systeme geschrieben in C++ und Java Industriestandard die ssicherung Klone Code Quality Literatur

34 Architektur in der Theorie Compiler-Architektur nach Shaw und Garlan (1993) die ssicherung Symbol Table Text Lexical Analysis Syntactic Analysis Semantic Analysis Optimization Code Generation Code AST Ideal Wirklichkeit Prüfung

35 Softwarearchitektur in der Praxis Compiler-Architektur im wirklichen Leben die ssicherung Ideal Wirklichkeit Prüfung

36 Abhängigkeiten Graph der direkten Aufrufe die ssicherung Ideal Wirklichkeit Prüfung

37 Abhängigkeiten Graph der direkten und indirekten Aufrufe die ssicherung Ideal Wirklichkeit Prüfung

38 Abhängigkeiten Alle Aufrufe und Klone die ssicherung Ideal Wirklichkeit Prüfung

39 Abhängigkeiten Nur Klone die ssicherung Ideal Wirklichkeit Prüfung

40 Architektur in Theorie und Praxis die ssicherung Symbol Table Text Lexical Analysis Syntactic Analysis Semantic Analysis Optimization Code Code Generation AST Ideal Wirklichkeit Prüfung

41 Reflexionsmethode (Murphy u. a., 1995) 1 Stelle Architekturmodell auf 2 Extrahiere Implementierungsmodell 3 Bilde Modelle aufeinander ab 4 Berechne Reflexionsmodell 5 Verfeinere/korrigiere die ssicherung Beispiel H1 H2 H3 Ideal Wirklichkeit Prüfung

42 Axivion Bauhaus-Werkzeug zur Architekturprüfung die ssicherung Ideal Wirklichkeit Prüfung

43 Die Rolle von Modellen in der Entwicklung heutige Verwendung von Modellen: deskriptiv: dienen der Dokumentation des Codes präskriptiv: dienen der Prüfung des Codes (z.b. Reflexionsanalyse) Trend: Modelle sind der Code modellgetriebene Entwicklung mit automatischer Code-Generierung Koschkesche Vermutung: Auch Modelle werden das sproblem von Software nicht lösen. Wir werden weiterhin Test und statische benötigen. die ssicherung Literatur

44 ung Innere ist langfristig entscheidend degeneriert langsam und unbemerkt Erosion Systemalter (in 100 Tage) ist komplementär zum Test findet Fehler bestimmt innere und macht Erosion sichtbar auf Code-Ebene auf Architektur-Ebene integraler Bestandteil des normalen Entwicklungsprozesses Systemgröße (in Module) die ssicherung Literatur

45 [Chou u. a. 2001] Chou, Andy ; Yang, Junfeng ; Chelf, Benjamin ; Hallem, Seth ; Engler, Dawson R.: An Empirical Study of Operating System Errors. In: Symposium on Operating Systems Principles, ACM Press, 2001, S URL citeseer.ist.psu.edu/chou01empirical.html [Fowler 2000] Fowler, Martin: Refactoring: Improving the Design of Existing Code. Addison-Wesley, 2000 [Frühauf u. a. 2000] Frühauf ; Ludewig ; Sandmayr: Prüfung. 4. Auflage. vdf Zürich, 2000 [ISO/IEC-Standard ] ISO/IEC :2001 Software engineering Product quality umgesetzt in DIN die ssicherung Literatur

46 [Juergens u. a. 2009] Juergens, E. ; Deissenboeck, F. ; Hummel, B. ; Wagner, S.: Do Code Clones Matter? In: International Conference on Software Engineering, ACM Press, 2009 [Li u. a. 2006] Li, Z ; Lu, S ; Myagmar, S. ; Zhou, Y.: Copy-Paste and Related Bugs in Large-Scale Software Code. In: IEEE Computer Society Transactions on Software Engineering 32 (2006), März, Nr. 3, S [Mende und Koschke 2009] Mende, Thilo ; Koschke, Rainer: Revisiting the Evaluation of Defect Prediction Models. In: Promise, submitted for publication die ssicherung Literatur

47 [Mende u. a. 2009] Mende, Thilo ; Koschke, Rainer ; Leszak, Marek: Evaluating Defect Prediction Models for a Large Evolving Software System. In: European Conference on Software Maintenance and Reengineering, IEEE Computer Society Press, 2009 [Monden u. a. 2002] Monden, A. ; Nakae, D. ; Kamiya, T. ; Sato, S. ; Matsumoto, K.: Software quality analysis by code clones in industrial legacy software. In: Proceedings of IEEE Symposium on Software Metrics, 2002, S [Murphy u. a. 1995] Murphy, Gail C. ; Notkin, David ; Sullivan, Kevin: Software Reflexion Models: Bridging the Gap Between Source and High-Level Models. In: Proceedings of the Third ACM SIGSOFT Symposium on the Foundations of Software Engineering. New York, NY : ACM Press, Oktober 1995, S die ssicherung Literatur

48 [Shaw und Garlan 1993] Shaw, Mary ; Garlan, David: An Introduction to Software Architecture. In: Advances in Software Engineering and Knowledge Engineering. River Edge, NJ : World Scientific Publishing Company, 1993 [Simon u. a. 2006] Simon, Frank ; Seng, Olaf ; Mohhaupt, Thomas: Code-Quality-Management Technische industrieller Softwaresysteme transparent und vergleichbar gemacht. dpunkt.verlag, 2006 die ssicherung Literatur