Grundlagen der Informatik

Transkript

1 Grundlagen der Informatik Projektmanagement und Debugging bei der Entwicklung von C-Programmen Prof. Dr.-Ing. Thomas Wiedemann Fachgebiet Informatik / Mathematik Überblick zur Vorlesung Entwicklung und Test von Programmen Allgemeine Vorgehensweise im Rahmen eines Projektes Gliederung von komplexen Aufgaben Fehlersuche und Test Erkennung und Behebung typischer Fehler bei der C-Programmierung Grundlagen der Informatik I T.Wiedemann- Seite 2 1

2 Entwicklung und Test von Programmen Programmentwicklung im historischen Kontext : erste Programme umfassten nur wenige Dutzend Befehle rasch zunehmende Anforderungen erforderten schnell einige Tausend Befehle Programmierung wurde schnell zur Domäne von Experten mit starker Orientierung auf Programmierung und wenig Anwendungswissen die sehr große Anzahl von Freiheitsgraden bei der Programmierung (Namen der Variablen, Umsetzung mit verschiedenen Schleifentypen, Sequenz der Befehle, Art der Funktionsparameter) führt auch heute noch zu einem individuell sehr differenzierten Stil bei der Programmierung : Es ist teilweise einfacher und effizienter, einen komplexen, existierenden Algorithmus selbst noch einmal neu zu programmieren als den vorhandenen Sourcecode zu modifizieren! (eigene Erfahrung!) die traditionelle Abfolge von Sourcetextänderung, Compilieren und Ausführen mit Einzeltools dauerte bis zu einige Minuten (auch als Turn-around-Zeit bezeichnet) einige Unarten erster Programmiersprachen, wie das sehr häufige Springen innerhalb des Programms mit dem Goto-Befehl (gibt es in C fast nicht mehr), führte zu sehr schwer verständlichen Programmen alle Faktoren zusammen führten Ende der 60iger Jahre zur "Softwarekrise" Grundlagen der Informatik I T.Wiedemann- Seite 3 Die Softwarekrise die wachsenden Aufgabenstellungen waren mit der herkömmlichen Programmierweise nicht mehr beherrschbar typische Problemsymptome (auch heute teilweise noch auftretend) : mehrfaches Überziehen der Kosten- und Zeitbudgets, Projektabbrüche instabile Anwendungen (Abstürze, unerklärliche Fehler -> Windows...) Falsche Entscheidungen beim Grunddesign (z.b. Sicherheit beim IE ) Änderungen und Wartung der Programme sehr problematisch Ursachen: Die komplexen Zusammenhänge großer Programme waren für den einzelnen Programmierer nicht mehr überschaubar. Bei Projekten mit mehreren Programmieren führte der zunehmende Verwaltungsoverhead schon bei kleinen Gruppen zu einer schnell absinkenden Effizienz. Auftraggeber und Programmierer leben und denken in verschiedenen Welten und verstehen sich teilweise nicht! Einige "Experten" sahen eine Komplexitätsgrenze für Software aufziehen! Grundlagen der Informatik I T.Wiedemann- Seite 4 2

3 Die Bewältigung der Softwarekrise Die großen Rationalisierungseffekte der EDV und damit verbundene Geldmittel forcierten die theoretische und praktische Forschung nach Auswegen. Die Softwarekrise wurde zumindest teilweise entschärft durch : bessere Programmiersprachen zur Strukturierten Programmierung Integrierte Entwicklungswerkzeuge zur Senkung der Turn-around-Zeiten sehr starke Modularisierung der Software (Zukauf statt Eigenentwicklung) ein effizientes, EDV-bezogenes Projektmanagement Hinweis: Da die auslösenden Faktoren der Softwarekrise immer noch vorhanden sind, kann bei einer traditionellen Programmierung ohne oder bei inkorrekter Anwendung der oben aufgezählten Lösungsmethoden immer noch eine Krise bei der Anwendungsentwicklung auftreten! Die Existenz der obigen Prinziplösungen garantiert keinen Erfolg im konkreten Projekt! Grundlagen der Informatik I T.Wiedemann- Seite 5 Die Strukturierte Programmierung Der übermäßige Gebrauch des Sprungbefehls goto führte zu relativ schlecht lesbarem Code (auch Spagetti-Code genannt) siehe Beispiel rechts der Schweizer Niklas Wirth propagierte die Einführung einer geringen Anzahl von Grundkonstrukten als vollständigen Ersatz für den goto-befehl und entwickelte dazu die Sprache Pascal alle modernen Sprachen verwenden heute analog: if ( ) then { } else { } While { } do { } while for ( ) {} der Goto-Befehl ist zwar teilweise noch verfügbar, wird aber kaum noch verwendet als Ersatz für goto sind die Befehle break und continue zu betrachten Unstrukturiert 10: c = 1; a = 6; 20: c = c + a; 30: if (c<30) goto 20 40: printf( "%i", c); 50: a = a-1; 60: if (a<=1) goto 90 70: c=0; 80: goto 20 90: exit; Strukturiert c = 0; a = 6; while (a > 1) { a = a-1; c=0; while ( c < 30) { c = c + a; } printf( "%i", c); } Grundlagen der Informatik I T.Wiedemann- Seite 6 3

4 Modularisierung der Software analog zur Vorgehensweise in den Technikwissenschaften wird statt einer kompletten Eigenentwicklung immer mehr auf Zukauf orientiert Dies setzt eine praktikable Modularisierung der Software voraus Lösungsoptionen zur Modularisierung: Verwendung traditioneller Unterprogrammbibliotheken (idealerweise mit verfügbarem Sourcecode) Verwendung von Binärcode-Bibliotheken (DLL s) mit dem Nachteil der fehlenden Testmöglichkeiten in diesen Bibliotheken Verwendung von Softwarekomponenten auf der Ebene von Bedienelementen (Taste/Eingabefeld) oder Business-Komponenten für komplexe Aufgaben (z.b. Angebotserstellung oder Reportwesen) -> siehe OO-Progr. räumlich ausgelagerte Funktionen mit Zugriff über Internet oder Intranet Webservices als aktuelle Entwicklung Grundlagen der Informatik I T.Wiedemann- Seite 7 Integrierte Entwicklungswerkzeuge Bis Mitte der 80er Jahre waren der Compiler und der Linker jeweils eigenständige Programmen und mussten manuell gestartet werden. Das Programm als Ergebnis der Übersetzung konnte nur als eine Einheit gestartet und getestet werden. Die Fa. Borland stellte mit Turbo Pascal ein revolutionäres Werkzeug vor: Alle notwendigen Entwicklungswerkzeuge (Editor, Compiler, Linker) waren in einem einzigen Programm vereint und konnten mit nur einem einzigen Tastendruck aktiviert werden. (=Integrated Developing Environment IDE) Bei Syntax-Fehlern wurde die Fehlerstelle direkt im Editor angezeigt. Der Test wurde durch einen Schrittbetrieb und weitere Hilfsmittel unterstützt. Heute ist diese Konfiguration allgemein verbreitet und soll am Beispiel der Microsoft Visual Studio IDE, als übergeordnetes Paket bzgl. des Visual C++-Compilers genauer erklärt werden Grundlagen der Informatik I T.Wiedemann- Seite 8 4

5 Fehlersuche und Test - 1. Beseitigung von Syntaxfehlern Syntaxfehler: Verstoß gegen Regeln der Programmiersprache oder unreichende Konfiguration des Projektes Erkennung: meist direkter oder indirekter Hinweis durch Compiler-Fehlercode Besonderheiten beim C-Compiler : Der C-Compiler ist ein sogenannter 1-Paßcompiler, d.h. der Quelltext wird nur einmal von oben nach unten analysiert (geparst). Folge: Bezugnahmen auf weiter unten befindliche Funktionen müssen durch einen Prototypen int functionname(...) ; bekannt gemacht werden Folge: Fehler sind immer an der Hinweisstelle oder DARÜBER!!! Kontrollieren Sie bei den meisten Fehlermeldungen neben der gemeldeten Zeile immer auch gleich die Zeile vor dieser Vor dem C-Compiler verarbeitet der Präprozessor den Quelltext und kann diesen ebenfalls negativ beeinflussen. Hauptproblem durch unabsichtliche Steuerzeichen wie ; bei der Definition mit #define Pi ; Falsch! Weitere, typische Syntaxfehler und deren wahrscheinliche Ursache finden Sie auf einem Arbeitsblatt im Web. Grundlagen der Informatik I T.Wiedemann- Seite 9 Fehlersuche und Test - 2. Behandlung von Compilerwarnungen Warnungen sind in der Regel zusätzliche Hinweise des Compilers zu möglichen (!!) Fehlern oder Inkorrektheiten bei der Programmierung Das Programm ist trotzdem generierbar und ausführbar. Einige Warnungen zeigen jedoch sehr häufig logische Fehler an : "warning C4700: Lokale Variable 'b' wurde ohne Initialisierung verwendet" // a = 23; b = 10; // Initialisierung wurde ausgeblendet c = a + 2*b; B wird verwendet, ohne einen definierten Startwert zu besitzen, das Ergebnis c ist daher ein zufälliger Wert, was i.d.r. nicht beabsichtigt ist warning C4305: '=' : Verkuerzung von 'double' in 'float' bei float e; double f= 1.0 ; e= f; Es wird eine Verkleinerung des Datentyps vorgenommen. Dies ist für "normale" Zahlen unkritisch, kann aber bei physikalischen Berechnungen problematisch sein, da die Wertebereiche differieren ( ±1E37 bei float zu ±1E308 bei Double) Grundlagen der Informatik I T.Wiedemann- Seite 10 5

6 Fehlersuche und Test - Fehlereingrenzung I Status: Fehler ist offensichtlich Ursache ist jedoch unbekannt Vorgehensweise zum Erkennen und Eingrenzen von Programmfehlern : Schrittweises Eingrenzen des Fehlers auf traditionelle Art: Einbau von printf-anweisungen zur Ausgabe von Zwischenwerten Schrittweises Verlagern (= Auskommentieren vorhandener Testausgaben) der Ausgaben von korrekten Programmcode zu kritischem, fehlerbehafteten Code Kontrolle der eingegrenzten Codebereiche auf logische Fehler ("im-kopf-ausführen") eigenes Verfahren mit if (Prueflevel>2) printf("x=%f ",x); // Prueflevel 5 = geschwätzig Eingrenzen des Fehlers mit Debuggingfunktionen Annahme : das Programm ist gut strukturiert Start des Programms im Schrittmodus (bei MS-Visual C: F10-Taste) weitere Schritte im Modus "AUFRUF als ein SCHRITT F10" ruft Unterfunktionen als Gesamtheit auf Test der Ergebnisse auf Korrektheit mit den Funktionen zur Dateninspektion : mit Maus auf Parameter stellen und linke Maustaste + "Schnellüberwachung" bei fragwürdigen Funktionen kann mit "In Aufruf springen" (bei MS-Visual C: F11- Taste) - der Aufbau und die korrekte Funktion genau innerhalb dieser untersucht werden Grundlagen der Informatik I T.Wiedemann- Seite 11 Fehlersuche und Test - Weitere Hilfsfunktionen In Ergänzung der einfachen Schrittfunktionen sind weitere Tools möglich: Fortsetzen der Ausführung nach Schrittmodus mit maximaler Geschwindigkeit : F5 Fortsetzen mit maximaler Geschwindigkeit bis zum Ende der Funktion: SHIFT+F11 Fortsetzen mit maximaler Geschwindigkeit bis Cursorposition : CTRL+F10 Wenn nichts mehr geht: Versuch Programm vom Compiler aus zu stoppen : SHIFT-F5 bei fehlender Reaktion oder abgestürztem Compiler direkter Stop des Anwendungsprogramms mit CTRL+ALT+DEL Grundlagen der Informatik I T.Wiedemann- Seite 12 6

7 Fehlersuche und Test - Fehlereingrenzung II Status: Fehler ist offensichtlich Position der Fehlerstelle ist grob bekannt Eingrenzen von Programmfehlern in sehr tiefen Programmhierarchien : schrittweises Durchlaufen wäre zu aufwändig relativ effiziente Suche möglich durch Setzen von Breakpoints ein Breakpoint ist eine Markierung, welche den Prozessor bei voller (oder sehr schneller) Ausführungsgeschwindigkeit stoppt und Schrittbetrieb erlaubt Praktische Arbeit mit Breakpoints Breakpoints sind nur auf ausführbaren Anweisungen positionierbar (Kommentare/ Leerzeilen und reine Variablendef. ohne Initialisierung sind nicht möglich) Breakpoints sind in der Regel VOR die Problemstelle zu setzen : 1. entsprechende Zeile auswählen und Breakpoint setzen mit F9-Taste (oder Kontextmenü) 2. Programm normal starten (F5) und ggf. Eingaben vornehmen 3. bei Erreichen eines Breakpoints wird dieser im Quelltext markiert 4. je nach Fehlerbild mit Schrittmodus weitergehen oder nach Inspektion der Variablen mit voller Geschwindigkeit fortsetzen (F5-Taste) 5. ein Breakpoint kann auch beliebig oft aktiviert werden! (Deaktivieren wieder mit F9) Grundlagen der Informatik I T.Wiedemann- Seite 13 Fehlersuche und Test - Fehlereingrenzung III Status: Fehler ist offensichtlich tritt jedoch nur selten auf Eingrenzen von seltenen Programmfehlern : Versuchen Sie ein Merkmal des Fehlers zu bestimmen (z.b. X ist > 100 ) Fügen Sie eine if-anweisung ein, welche genau diese Bedingung testet und schreiben Sie eine Zeile tiefer eine beliebige Testanweisung : If ( x > 100 ) printf("fehlersituation X=100 erreicht!"); Breakpoint Setzen Sie auf die Testanweisung einen Breakpoint Starten Sie das Programm - der Breakpoint wird nun nur bei der Fehlersituation aktiviert! Hinweis: Einige Compiler bieten auch einen sogenannten "Bedingten Breakpoint an", welcher die gleiche Funktion auf Compilerebene realisiert! Grundlagen der Informatik I T.Wiedemann- Seite 14 7

8 Fehlersuche und Test - Typische Fehlerbilder im Schrittmodus Bei der Arbeit im Schrittmodus kommt es typischen Verhaltensmustern : Cursor bewegt sich nicht weiter: A: Erwartet das Programm eine Eingabe? Wenn ja -> Eingeben und weiter... B: Liegt an dieser Stelle eine Endlosschleife vor? -> while (x>10) ; Ausführungspfeil überspringt Codeteile A: Stimmt die Schachtelung von if () { } else {} oder while-schleifen? B: Sind die {} Klammern richtig gesetzt? Variablen weisen unsinnige Werte auf A: Sind die Variablen auf Anfangswerte gesetzt? (-> Warnung vorhanden?) B: Kann es zu einer unbeabsichtigten Bereichsverletzung bei Matrizen gekommen sein, so daß benachbarte Werte überschrieben werden? Grundlagen der Informatik I T.Wiedemann- Seite 15 Fehlersuche und Test - in Extremfällen Verdacht auf Fehler auf Prozessorebene oder Hardware oder in Speicher nur für sehr spezielle Fälle (Treiberentwicklung, Netzwerk, Performance! ) unbeabsichtigter Aufruf durch "In Funktion gehen" bei Basisfunktionen Test auf Prozessorebene : Anzeige des Maschinencode der Intel-Prozessoren (AMD ist 99% kompatibel) über -> Ansicht -> Debug-Fenster -> Register Anzeige des rückübersetzten Codes mit -> Debug-Fenster -> Register (die Zeilen ohne Adresse stellen den Quellcode dar, dazwischen ist der generierte Maschinencode zu sehen 36: if ( s > 0 ) 0040F03C cmp dword ptr [ebp-40h],0 0040F040 jle main+0fdh (0040f04d) 37: { p = p -k ; } 0040F042 mov eax,dword ptr [ebp-44h] 0040F045 sub eax,dword ptr [ebp-3ch] 0040F048 mov dword ptr [ebp-44h],eax 38: else { s = s+10; } 0040F04B jmp main+106h (0040f056) 0040F04D mov ecx,dword ptr [ebp-40h] 0040F050 add ecx,0ah 0040F053 mov dword ptr [ebp-40h],ecx 39: 40: p = -p; 0040F056 mov edx,dword ptr [ebp-44h] Grundlagen der Informatik I T.Wiedemann- Seite 16 8