Werkzeuge zur Codeanalyse

Thomas Gangler

Technische Universitat Dresden, Fakultat Informatik,Institut Software- und Multimediatechnik, Lehrstuhl Softwaretechnologie,

01062 Dresden, Deutschlands9736463@mail.inf.tu-dresden.de

Zusammenfassung. Der Bereich der Software-Qualitatssicherung be-kommt in letzter Zeit eine immer großere Bedeutung. Nachdem fastalltaglich Nachrichten von Programmierfehlern in großen Projekten dieSchlagzeilen machen, sind die Hersteller nun gefordert geeignete Losun-gen zu entwickeln und einzusetzen um diesen negativen Trend entge-genzuwirken. Durch die enorm gestiegene Komplexitat von modernenSoftware-Systemen ist es wirtschaftlich und technisch fast nicht mehrmoglich diese Aufgaben manuell zu erledigen. Werkzeuge zur Codeana-lyse automatisieren einen großen Teil dieser Arbeit und sollen in die-sen Aufsatz umfassend vorgestellt, unterschieden und klassifiziert werdenund somit dem Entwickler helfen den richtigen Einstieg in diesen Bereichzu finden.

1 Einleitung

Software-Qualitat und das damit verbundene Code-Quality-Management spie-len eine große Rolle bei modernen Software-Entwicklern. Dass die Wahrung vonQualitatskriterien mit wachsender Codezeilenanzahl eines Projektes immer kom-plexer und schwieriger wird, ist ein einfache logische und allseits bekannte Folge.Die immer umfangreicheren Entwicklungsumgebungen oder separate Werkzeugesollen dem Entwickler dabei einen großen Teil der manuelle Test- und Analy-searbeit abnehmen. Trotzdem herrscht bei den beteiligten Rollen im Software-entwicklungsprozess noch oft Unklarheit bei folgenden Fragen. Welche Moglich-keiten zum Test- und Analysieren gibt es berhaupt? Welches Werkzeug erledigtwelche Aufgabe im Qualitatssicherungszyklus? Deshalb soll dieser Aufsatz einenEinblick und Uberblick in die Vielzahl vorhandener Test- und Analysewerkzeugeund deren Einsatzgebiete beschrieben. Als Erstes soll eine Typisierung fur Werk-zeuge zur Sicherung von Software-Qualitat vorgestellt werden und insbesondereauf die Kategorien zum Testen und zur Codeanalyse eingegangen werden (s.Kap. 2). Dabei werden immer wieder Beispielwerkzeuge genannt, wobei der Fo-kus i.A. auf frei erhaltlichen Vertretern liegt und diese oft auch als Plug-in furdie Eclipse Entwicklungsumgebung erhaltlich sind.Danach wird auf die, erweiterten statischen Analysewerkzeuge eingegangen, wel-che durch kurze Beschreibungen von zwei Beispielen abgerundet wird (s. Kap.3). Anschließend folgt ein Kapitel uber Portale (s. Kap. 4). Diese Form ver-eint mehrere Werkzeugtypen in auf sinnvolle Art und Weise, und erleichtert die

2

Zusammenarbeit zwischen den verschiedenen Rollen in der Softwareentwicklung.Letztendlich gibt das Fazit zum Schluss noch einmal ein kurze Zusammenfassunguber die Vorteile und den Nutzen des Einsatzes von Werkzeugen zur Codeana-lyse.

2 Werkzeugtypen

Die Unterteilung der Werkzeugtypen halt sich grob an die Vorlage von Ligges-meyer [6]. Dabei wird insbesondere auf die Typen dynamische Testwerkzeuge(s. Kap. 2.1) und statische Analysewerkzeuge (s. Kap. 2.2) eingegangen. Diesekooperieren oft miteinander bzw. sind ineinander integriert und bilden gene-rell die zahlenmaßig starkste Kategorie. Deshalb werden sie in diesem Aufsatzbesonders analysiert. Des weiteren werden anschließend noch die beiden Werk-zeugtypen formale Verifikationswerkzeuge (s. Kap. 2.3), und modellierende undanalysierende Werkzeuge (s. Kap. 2.4) vorgestellt, welche zwar Grundlagen furdie erweiterten statischen Analysewerkzeuge (s. Kap. 3) bereitstellen, generellaber gesondert und ausfuhrlicher betrachtet werden mussen.

2.1 Dynamische Testwerkzeuge

Die Kategorie der dynamischen Testwerkzeuge kann in verschiedene Unterka-tegorien unterteilt werden, wobei die einzelnen Werkzeugtypen eng miteinan-der in Verbindung stehen. Generell wird durch Vertreter dieser Kategorie dasProgramm wahrend des Tests mit ausgefuhrt und somit Daten uber die Lei-stungsfahigkeit und Funktionsweise der Anwendung ermittelt. Im Folgenden wer-den nun die vier Typisierungen der dynamischen Testwerkzeuge erlautert.

Strukturorientierte Testwerkzeuge. Vertreter dieser Unterkategorie stellen demEntwickler Informationen uber den Stand der Prufung bereit. Zum Nachweis derordungsgemaßen Durchfuhrung von Tests werden diverse Testuberdeckungspro-tokolle angewandt, d.h. es wird i.A. immer eine vollstandige Abdeckung des je-weiligen Uberdeckungstests gefordert1. Der Bekannteste ist dabei der Zweiguber-deckungstest, welcher die Ausfuhrung aller Zweige bzw. die Uberdeckung allerKanten fordert [6]. Das Testwerkzeug visualisiert dann die bereits ausgefuhrtenZweige mittels eines automatisch generierten Kontrollflussgraphens. Als Uber-deckungsmaß dient hierbei die Zweiguberdeckungsrate (absolut oder relativ). Einweiteres Beispiel ist der Statement-Uberdeckungstest, welcher die Ausfuhrung al-ler Codezeilen eines Programms fordert.Generell gibt es zwei Arbeitsweisen bei strukturorientierten Testwerkzeugen. DieMehrheit arbeitet instrumentierend, d.h. es werden dem Quellcode zusatzlicheAnweisungen hinzugefugt (Annotationen). Dies hat den Vorteil, dass das Test-werkzeug beim eigentlichen Test nicht mehr aktiv sein muss; gleichzeitig aber

1 Bei komplexen Programmen kann dies zu einem Zeit intensiven und teuren Prozesswerden, wenn alle Testfalle von Hand abgewickelt werden mussen [2]

3

den Nachteil, dass sich durch die Anweisungsanreicherung die Ausfuhrungszeitverlangert. Durch diese Form kann aber eine Merkmalsauswertung bei der Syn-taxanalyse mit durchgefuhrt werden (z.B. Ermittleln der zyklomatischen Zahl ; s.Kap. 2.2), d.h. statische Analysefunktionalitaten sind mit in diesem dynamischenTestwerkzeug integriert. Dieser Arbeitsweise gegenuber steht die nicht Instru-mentierende. Hierbei werden die von der Testausfuhrung genutzten Adressen di-rekt uber eine Hardware-Schnittstelle abgegriffen, was oft mittels eines separatenComputers erledigt wird. Somit konnen Uberdeckungen auf einem niedrigerenNiveau registriert werden. Durch Caching-Strategien gelangen aber nicht immeralle Adressen die sich auf dem Adressbus befinden zur Ausfuhrung, was sichwiederum nachteilig auf die Analyse auswirken kann.Die strukturorientierten Testwerkzeuge bieten unterschiedliche Formen der Dar-stellung fur die jeweiligen Testtypen an. Zum einen sind die grafischen Formenmit den bereits erwahnten Kontrollflussgraphen, welche bei Modultests genutztwerden, und Strukturdiagramme fur Integrationstests. Zum anderen ist die tex-tuelle Form, welche eine Aufbereitung des Quelltextes wiedergibt. Oft werdendiese Darstellungsformen miteinander kombiniert und es ist z.B. moglich voneiner Stelle im Kontrollflussgraphen zum zugehorigen Quelltext zu gelangen.Diese Form der Testwerkzeuge ist generell programmiersprachen-abhangig durchdie speziellen programmiersprachlichen Konstrukte der jeweiligen Programmier-sprache. Es gibt umfassende Unterstutzung fur C, C++ und Java. Des weite-ren gibt es jedoch auch Werkzeuge fur spezifischere Programmiersprachen wieAda, Pascal und Fortran fur den naturwissenschaftlichen Bereich, oder Cobol furden kaufmannischen Bereich (s. Ubersicht auf [1]). Ein Beispiel einer Werkzeu-gumgebung, welche strukturorientierte Tests mit durchfuhren kann, ist die freierhaltliche Test and Performance Tools Platform2 (TPTP) von Eclipse. DiesesPlug-in kann insbesondere einfache und verteilte Java-Anwendungen analysierenund testen. Eine weiteres Beispiel ist das kommerzielle Prevent von der FirmaCoverity3, welches die Programmiersprachen C, C++ und Java unterstutzt.

Funktionsorientierte Testwerkzeuge. Damit eine nahezu vollstandige Testab-deckung gewahrleistet werden kann, mussen Tests strukturiert geplant und Test-falle erzeugt werden. Funktionsorientierte Testwerkzeuge sollen dem Entwicklerhelfen Testfalle nach diversen Testtechniken planen zu konnen und somit denKomfort zu erhohen und einen Uberblick uber die Testplanung bereitzustellen.Deshalb ist diese Kategorie durch ihre Abstraktion i.d.R. programmiersprachen-unabhangig. Ein Bespiel fur eine Testtechnik ist die funktionale Aquivalenzklas-senbildung, wobei Testfalle aus der Spezifikation des Programmes durch Aqui-valenzklassenbildung abgeleitet werden.Daruber hinaus bieten diese Testwerkzeuge die Moglichkeit zur Definition vonTestdaten bzw. erwarteten Testergebnissen. Diese Beispieldaten konnen dadurch

2 http://www.eclipse.org/tptp/3 http://www.coverity.com/

4

immer wieder verwendet werden4 und erleichtern somit die Testautomatisierungbzw. Wiederverwendbarkeit. Ein Beispieltyp fur funktionsorientierte Testwerk-zeuge sind Zusicherungswerkzeuge, wo formale Aussagennotationen nach einerfesten Syntax in den Quellcode eingefugt werden (engl. assertions). Als Beispielfur diese Unterkategorie kann wieder das TPTP -Plug-in fur die Eclipse InterfaceDevelopment Environment (IDE) genannt werden, welches eine Testplanungs-und erzeugungsansicht besitzt (inklusive Anlegen und Verwalten von Testdaten-pools). Hierbei wird das bekannte Framework zur Testfallgenerierung fur Java-Anwendungen, JUnit, mit integriert.

Regressionstestwerkzeuge. Nachdem nun mittels funktionsorientierter Testwerk-zeuge Tests geplant und Testfalle erzeugt, und mittels strukturorientierter Test-werkzeuge wahrend der Durchfuhrung visualisiert werden konnen; benotigt derEntwickler noch einen Werkzeugtyp zur Automatisierung der Testdurchfuhrung.Regressionstestwerkzeuge ermoglichen das Einspielen von Testdaten und dasAufzeichnen von Testergebnissen. Somit ist ein Vergleich zwischen unterschiedli-chen Testdurchlaufen gewahrleistet und demzufolge eine automatisierte Meldungvon Abweichungen realisierbar.Generell sollten Regressionstests nach jeder Fehlerkorrektur und Funktionserwei-terung5 des Programmes durchgefuhrt werden. Dies ist wiederum nur durch eineautomatische Testdurchfuhrung technisch und wirtschaftlich sinnvoll. Im Allge-meinen konnen diese Werkzeugtypen programmiersprachen-unabhangig arbei-ten. Sie sind aber manchmal programmiersprachen-spezifisch, wie im Fall vonJUnit fur Java. Deshalb kann als konkretes Beispiel wieder das TPTP -Plug-in fur die Eclipse IDE genannt werden, was u.a. Komponenten zur Historien-Analyse und zur Berichterstattung enthalt.

Leistungs- und Stresstestwerkzeuge. Oft mit interegriert in Regressionstestwerk-zeuge sind die Unterkategorien fur Leistungs- und Stresstests. Die erste Formgeneriert Lasten im Normalbereich an der (vorher festgelegten) Grenze zur Uber-last. Die zweite Art simuliert den Betrieb bei Uberlast.Eine, nach festen Vorgaben definierte, Lastenerzeugung kann i.d.R. nur nochwerkzeugunterstutzt vorgenommen werden, da i.A. Lasten fur moderne Mehrbe-nutzer-Anwendungen nicht mehr von Hand erzeugt werden konnen. Die Lasten-erzeugung kann z.B. durch Vervielfaltigung und Modifikation von Regressions-test-Mitschnitten erstellt werden. Diese Werkzeugtypen enthalten zusatzlich di-verse Messfunktionen zum Registrieren von Antwortzeiten und Ressourcenaus-lastungen. Als Beispiel kommt abermals das TPTP -Plug-in fur die Eclipse IDEin Frage, welches ein Performanz-Testwerkzeug fur Webanwendungen enthalt.

2.2 Statische Analysewerkzeuge

Im Gegensatz zu den Testfallen wird bei statischen Analysen nur der Quell-code oder dessen Kompilat analysiert und ausgewertet, d.h. es sind keine kon-4 Weil sie i.d.R. persistent abgespeichert werden, z.B. in einer relationalen Datenbank5 Wobei hier ggf. die Testfalle mit erweitert werden mussen

5

kreten Testfallen und Testdaten notig. Durch den engen Bezug zum Quellcodesind Werkzeuge dieser Kategorie oft programmiersprachen-spezifisch. Wie schonbeschrieben, bilden die statischen Analysewerkzeuge oft eine Einheit mit dendynamischen Testwerkzeugen. Analog zu Diesen gibt es hier eine weitere Unter-kategorisierung, welche nun vorgestellt wird.

Messwerkzeuge. Als erste, sehr verbreitete und recht alte Unterkategorie stehendie Messwerkzeuge. Sie dienen zur Informationsgewinnung und -darstellung mit-tels statischer Analyse. Hierbei wird der gesamte Quellcode eines Programmsanalysiert und bestimmte Merkmale registriert. Verbreitete Maße hierfur sind:zyklomatische Zahl, Halstead -Maße, Maße zur Datenkomplexitat (z.B. Anzahlder Klassen) oder Anzahl der Codezeilen (engl. Lines of Code) durch den Nut-zer. Diese Maße mussen prazise definiert sein, d.h. es darf kein manueller Eingriffwahrend der Analyse vom Nutzer stattfinden.Die Ergebnisse lassen sich entweder in textueller (Tabellen, Baume) oder in gra-fischer Form (Graphen, Diagramme) darstellen. Die Messwerkzeuge ermoglichenes dem Entwickler oft Grenzewerte fur diverse Maße zu definieren und in der Er-gebnisdarstellung Grenzuberschreitungen aufzeigen zu lassen. Die abstrakte De-finition der Maßberechnungen ist zwar i.A. programmiersprachen-unabhangigaber zur Ermittlung dieser sind die Werkzeuge i.d.R. programmiersprachen-spezifisch.Beispiele sind das bekannte Open-Source Metrics-Plug-in fur die Eclipse IDEvon Frank Sauer6 und SemmleCode von der Firma Semmle7, welches ebenfallsein frei erhaltliches Plug-in fur die Eclipse Entwicklungsumgebung ist und u.a.Metriken berechnen kann.

Stilanalysatoren. Diese Unterkategorie analysiert den Quellcode nach bestimm-ten vordefinierten oder einstellbaren Verletzungen von Programmierregeln. Diessind z.B. Einschrankungen von zu verwendenden programmiersprachlichen Kon-strukten oder die Definition von zusatzlichen Forderungen um strengere Code-Konventionen festzulegen. Stilanalysatoren tragen damit gut zur Vereinheitli-chung von Programmcode in großen Projekten bei. Des weiteren sind sie teilwei-se Voraussetzung fur bestimmte Programmiersprachen in bestimmten Anwen-dungsgebieten (z.B. sicherheitskritische Anwendungen).Als altester Vertreter dieses Werkzeugtyps tritt Lint fur die ProgrammierspracheC auf, welche von Natur aus eher schwache Stildefinitionen hat. In der EclipseIDE ist ein Code Style Dialog schon durch das Java Development Toolkit miteingebettet, welcher diverse Funktionen zur Code-Formatierung und Stilanalysebereitstellt. Daruber hinaus ist das Open-Source-Plug-in Checkstyle8 fur dieseEntwicklerumgebung erhaltlich. Dieses Werkzeug besitzt eine anpassbare Kon-figuration, welche Standards wie die Sun Code Conventions fur Java umsetzen

6 http://metrics.sourceforge.net/; nicht zu verwechseln mit dem gleichnamigen Plug-in von State Of Flow (http://eclipse-metrics.sourceforge.net/)

7 http://semmle.com/8 http://checkstyle.sourceforge.net/

6

kann. Zusatzlich kann es noch diverse andere Probleme uberprufen (z.B. Erken-nung von dupliziertem Code).

Werkzeuge zur Erzeugung von Tabellen und Grafiken. Werkzeuge dieses Typsstellen im eigentlichen Sinn keine separate Unterkategorie von statischen Analy-sewerkzeugen dar. Sie sind aber i.A. Bestandteil von vielen Werkzeugumgebun-gen. Wie schon aus der Bezeichnung abgeleitet werden kann, dient dieser Werk-zeugtyp zur Erzeugung verschiedenster Ergebnisdarstellungen, z.B. Kontroll-fluss- und Aufrufgraphen, oder Variablen-Quer-Verweis-Tabellen.Das Metrics-Plug-in von Frank Sauer kann solche Abhangigkeitsgraphen gene-rieren oder die Analyseergebnisse in Tabellen mit Baumen darstellen. WeitereBeispiele fur Werkzeugumbebungen, die eine solche Visualisierung ermoglichensind das kommerzielle CodeSonar von Grammatech9 oder SemmleCode, welchesAnfragen als Tabelle, Baum, Graph oder Diagramm ausgeben kann10.

Slicing-Werkzeuge. Generell dient Slicing zum Vereinfachen von Programmen,indem nur ein bestimmter semantischer Aspekt betrachtet wird (engl. point ofinterest) [4]. Dieses Prinzip blendet einfach nicht relevante Programmteile aus.Dabei gibt es verschiedene Typen und Formen von Slicing. Die einfachste Formist das statische Slicing, wo die irrelevanten Teile einfach bei der Darstellunggeloscht werden. Darauf aufbauend befindet sich das dynamische Slicing, wozuatzlich konkrete Eingabewerte mit ausgewertet werden. Als Vermischung vonstatischen und dynamischen Slicing steht der Typ bedingtes Slicing. Hierbeiwerden keine konkreten Eingabewerte mehr ausgewertet sondern abstrakt defi-nierte Bedingungen. Somit wird schnell ein großer Bereich abgedeckt. Als letzterTyp, ist das formlose Slicing zu nennen, was unabhangig von den anderen For-men, jede Programmtransformation nutzt um das Programm zu vereinfachen.Der Programminhalt/ -zweck wird dabei aber beibehalten.Im Allgemeinen bietet das Slicing vielfaltige Anwendungsgebiete, z.B. zum Te-sten, Fehlersuchen, Umgestaltungen, Verstehen oder Vermessen von Program-men. Im Speziellen, fur den Anwendungsfall der Codeanalyse, unterstutzt Sli-cing den Entwickler bei der Fehlersuche nach Erkennung eines Fehlverhaltens(engl. debugging). Hierbei werden dann nur die Bereiche betrachtet, die poten-tiell den Fehler enthalten konnen, d.h. z.B. Variablen die mit dem Problem inZusammenhang stehen.Die Debug-Perspektive in der Eclipse Entwicklungsumgebung bietet verschiede-ne Funktionalitaten zum Eingrenzen und Fokussieren von Programmteilen. Desweiteren kann das kommerzielle Slicing-Werkzeug Wisconsin Program SlicingSystem11 von GrammaTech C-Programme in einer annehmbaren Zeit zerteilen.

Datenflussanomalieanalysatoren. Dieser Werkzeugtyp ist eigentlich selbst be-schreibend - er dient zum Auffinden von Datenflussanomalien, d.h. fehlerhafte9 http://www.grammatech.com/index.html

10 Wobei nicht immer jede Ausgabeform fur jede Anfrage sinnvoll ist und deshalb derErgebnistyp festgelegt werden kann

11 http://www.cs.wisc.edu/wpis/html/

7

Zugriffssequenzen auf eine Variable (z.B. lesender Zugriff auf eine nicht initia-lisierte Variable). Durch ihre essenzielle Funktionalitat sind sie oftmals schonin Compiler integriert. Die Analyse ist auf statischem Wege mit wenig Aufwandrealisierbar und stets automatisierbar. Dadurch bietet sie sichere und zuverlassli-che Ergebnisse.In der Eclipse Entwicklungsumgebung werden solche Fehler teilweise schon ad-hoc bei der Programmierung ausgewertet und angezeigt (mittels Online-Fehler-Uberprufung). Generell sind solche Werkzeuge in allen gangigen statischen Ana-lysewerkzeugen mit enthalten (z.B. die Uberprufung auf Null-Pointer-Derefe-renzierung).

2.3 Formale Verifikationswerkzeuge

Diese Werkzeugkategorie dient zur Uberprufung der Konsistenz zwischen Spe-zifikation und Realisierung (d.h. des Programmcodes) mittels mathematischerMittel [6]. Sie hat dabei ihre speziellen Anwendungsbereiche großtenteils in derAutomatisierungs- und Steuerungstechnik. Dort muss die eingebettete Softwareim sicherheitskritischen Umfeld unbedingt verifiziert werden (z.B. in Geldauto-maten oder militarischen Software-Entwicklungen).Dabei gibt es verschiedene Verfahren und Techniken zur formalen Verifikationvon Programmen. Fur diesen Aufsatz von Bedeutung sind die automatenbasier-ten Techniken und das symbolische Testen. Unter den ersten Ansatz fallt dasSymbolic Model Checking, welches eine formale Nachweistechnik fur Eigenschaf-ten zustandsendlich beschriebener Systeme ist. Beim zweiten Ansatz werdenTests mit allgemeinen symbolischen Werten durchgefuhrt.Ein Beispiel Werkzeug fur diese Kategorie ist UPPAAL12, welches von der Upp-sala Universitat in Schweden und der Alborg Universitat in Danemark entwickeltwurde. Es dient zum Modellieren, Simulieren und Verifizieren von Echtzeitsyste-men.

2.4 Modellierende und analysierende Werkzeuge

Diese Kategorie von Werkzeugen soll nur kurz erwahnt werden, weil sie nicht demHauptthema des Aufsatzes entspricht13. Werkzeuge diesen Typs haben ihre An-wendungsbereiche in der Risiko-, Sicherheits-, Zuverlassigkeits- und Verfugbar-keitsanalyse. Sie sind generell eher programmiersprachen-unabhangig. Diese Artbeinhaltet effiziente Spezialisierungen bzw. Unterkategorien, z.B. FMECA14-,Fehlerbaumanalyse- oder Markov -Werzeuge.Die Werkzeugumgebungen sind dabei haufig im kommerziellen Bereich angesie-delt und beinhalten oft mehrere Werkzeugtypen dieser Kategorie. Des weiterenbesitzen die Software-Firmen oft eine langjahrige Erfahrung in der Entwicklung.

12 http://www.uppaal.com/13 fur einen detaillierteren Einstieg bitte das zugehorigen Kapitel in [6] lesen14 engl. Failure, Mode, Effects and Criticality Analysis

8

Abb. 1. Aufbau erweiterter statischer Analysewerkzeuge [8]

Beispielhafte Vertreter sind der Isograph Reliability Workbench15 und das RelexReliability Studio16.

3 Erweiterte statische Analysewerkzeuge

Diese Kategorie der statischen Analysewerkzeuge hat sich aus den vorhandenenWerkzeugumgebungen in den letzten Jahren stark hervorgetan. Sie sind ahn-lich strukturiert und nutzen i.A. die gleichen grundlegenden Techniken, d.h. eskonnen eigene Abfragen zur Erkennung von Problemmustern formuliert wer-den. Dazu soll im folgenden der Aufbau (s. Kap. 3.1) und danach die genutztenTechniken (s. Kap. 3.2) dieser Werkzeuge erklart werden. Daruber hinaus wer-den verwendete Begriffe erlautert (s. Kap. 3.3) und die derzeitigen Grenzen dererweiterten statischen Analysewerkzeuge aufgezeigt (s. Kap. 3.4). Abschlieendwerden bekannte Vertreter vorgestellt (s. Kap. 3.5).

3.1 Grundstruktur

Der Aufbau dieser Analysewerkzeuge ist grafisch in der Abb. 1 visualisiert. Hiersind klar die vier Grundkomponenten: Faktenextraktor/ Dekorierer, Datenbank-system (DBS), Analyse- und Reportkomponente zu erkennen. Dabei ist die zwei-te Komponente nicht zwingend erforderlich, wenn die entstandenen Daten nichtin einer Datenbank abgespeichert werden sollen. Wie aus der Grafik gut zuerkennen ist, lasst sich der gesamte Knowledge-Discovery-Prozess leicht auto-matisieren und z.B. das Werkzeug im Batch-Betrieb als Cron-Job ausfuhren. ImFolgenden werden nun die einzelnen Bestandteile der Grundstruktur erklart.

Faktenextraktor/ Dekorierer. Als Ausgangsdaten nehmen diese Analysewerk-zeuge, wie bei der statischen Codeanalyse ublich, den Quellcode oder die Kom-pilation des Programmcodes. Hierbei extrahiert zunachst der Faktenextraktor15 http://www.isograph-software.com/index.htm16 http://www.relex.com/

9

ein Systemmodell aus den Daten. Dessen Struktur und Inhalt wird durch einSystemmetamodell vorgegeben. Dabei werden Artefakte wie z.B. Verzeichnisse,Quellcode-Dateien, Pakete, Klassen, Methoden oder Attribute erfasst. Des weite-ren werden noch die Referenzen zwischen bestimmten Artefakttypen ermittelt.Das sind Eigenschaften wie z.B. Enthaltenssein- und Vererbungsbeziehungenoder Methodenaufrufe und Attributbenutzungen.Diese Artefakttypen und Referenzarten variieren je nach Programmiersprache(z.B. friend in C++ und implements in Java). Daraus ergibt sich das Problemder Definition des Systemmetamodells. Entweder es werden alle vorhandenenUnterschiede in einem universellen bzw. generischen Systemmetamodell verei-nigt, oder es wird ein separates Modell fur jede Programmiersprache erstellt.Optional hingegen ist die Systenmodellanreicherung durch Dekorierer. Sie be-stimmen noch nicht ermittelte Merkmale aus dem Quellcode oder Log-Dateieneines Konfigurations-Management-Systems (z.B. CVS oder Subversion). Bei-spiele fur solche Merkmale sind u.a. Anderungshaufigkeit oder Angaben uberdie Vollstandigkeit der Javadoc- oder Doxygen-Kommentare. Zusatzlich konnenmit Dekorierern Vorberechnungen fur wiederholt benotigte Daten fur die Ana-lysephase vorgenommen werden (z.B. Berechnung der transitiven Hulle der Ver-erbungsbeziehungen). Generell fuhren diese Vorberechnungen zu einem spaterenPerformance-Gewinn.Die eigentliche Datenmenge wird durch den Faktenextraktor und Dekorierer re-duziert und es ist damit keine vollstandige Ruckwartsgenerierung moglich.

Datenbanksystem. Das nun extrahierte Systemmodell des Programmes wirdhaufig in einer relationalen Datenbank abgespeichert. Dies hat mehrere Vor-teile. Als Erstes konnen DBSe i.A. gut mit großen Datenmengen umgehen. AlsZweites konnen damit Relationen effizient berechnet werden. Als Drittes werdendie Daten persistent abgespeichert und es kann immer wieder auf sie zugegriffenwerden.Die Werkzeuge besitzen teilweise ein internes DBS. Diese sind i.A. nicht so lei-stungsstark und effizient wie externe DBSe, welche groe Datenmengen schnellverarbeiten konnen. Daruber hinaus besteht dann aber oft die Moglichkeit mitexternen DBSen zu kooperieren (z.B. PostgreSQL oder Oracle).

Analysekomponente. Nachdem nun die Daten persistent in einer Datenbank ab-gespeichert wurden, konnen nun vordefinierte oder neu erstellte Anfragen aufdas Systemmodell ausgeubt werden. Die Analysekomponente ist durch Nutzungeiner Datenbank zeitlich unabhangig von der Faktenextraktion und der Deko-rierung17. Zusatzlich ermoglicht dies eine Wiederholung oder Modifikation derAnalyse auf einfachen Wege.Eine Qualitatsanalyse setzt sich generell aus vielen Teilanalysen zusammen. Die-se Anfragen werden durch eine Anfragesprache, wie z.B. SQL, oder durch werk-zeugspezifische Erweiterungen beschrankt. Der dabei wichtigste Faktor ist die

17 Werkzeuge die diese Anforderung nicht erfullen verarbeiten die anfallenden Datensofort weiter

10

Laufzeit der Berechnungen, welche durch Wahl geeigneter Hardware, Wahl einesgeeigneten DBSs und Anfrageoptimierung verbessert werden kann.

Reportkomponente. Die Ergebnisse der Analysekomponente werden i.A. in Ta-bellen und Diagrammen dargestellt. Des weiteren kann die Reportkomponentedie Resultate aber als Berichte aufarbeiten und somit in verschiedenen Abstrak-tionsstufen wiedergeben (z.B. fur das Management oder den Entwickler).

3.2 Technik

Die erweiterte statische Analyse hat ihre Wurzeln, in den schon erwahnten,Model-Checking-Technologien und in der abstrakten Interpretation [2]. Sie nutztsymbolischen Eingaben, d.h. abstrakte Werte, um viele konkrete Werte gleichzei-tig abzudecken und somit effizient zu arbeiten. Folglich arbeiten diese Werkzeu-ge im Kontrast zu dynamischen Testwerkzeugen, wo konkrete Werte verwendetwerden. Dies hat den Vorteil, das i.A. einen hohere Abdeckung erzielt wird ohnespezielle Testfallgenerierungen. Dies geschieht durch die abstrakte Betrachtungund Auswertung der Pfade und Bedingungen.

3.3 Fachterminologie

Die Technologie der erweiterten statischen Analyse fuhrte zur Bildung einerReihe von neuen Fachbegriffen. Die Grundlage bilden die Fehlermuster, wel-che Problemmuster genannt werden. Dies ist die spezielle Beschreibung eineswiederkehrenden und i.d.R. erkennbaren Fehlverhaltens von Programmcode. Sieentstehen z.B. durch die unterschiedlichen Eigenschaften der Programmierspra-chen, falsch verstandene Schnittstellen-Methoden oder einfache kleine Versehen(z.B. Nutzung des falschen Boolean-Operators). Diese Fehlermuster werden dannnach ihrer Art in Fehlerklassen zusammengefasst. Dabei gibt es verschiedeneAnsatze und Kategorisierungen. Beispiele fur Fehlerklassen sind unvorhersehba-re/ kritische Fehler (z.B. Pufferuberlauf/-unterlauf), Speicher-Allokations-Fehler(z.B. doppeltes Freigeben) oder Konkurrenz-Fehler (z.B. doppeltes Sperren vonkritischen Abschnitten). Manche Kategorien beziehen sich nur auf bestimmteProgrammiersprachen. Demzufolge spielen Speicher-Allokierungs-Fehler in Java,welches eine automatische Speicherverwaltung besitzt, keine Rolle. Letztendlichwerden die Problemmuster in Qualitatsindikatorenkataloge [8] oder Fehlermu-sterkatalogen zusammengefasst. Diese variieren dann von Werkzeug zu Werk-zeug und konnen teilweise noch selbst von den Entwicklern definiert werden.Ein wichtiger Vergleichswert zwischen der Leistungsfahigkeit der verschiedenenWerkzeuge ist die sogenannte False-Positive-Rate [9]. Diese fasst die Warnun-gen zusammen, welche gar keine richtigen Fehler sind. Dem gegenuber stehtdie False-Negative-Rate, welche die Anzahl der nicht gefunden Fehler widerspie-gelt. Generell sind die Entwickler von erweiterten statischen Analysewerkzeugenbestrebt ein geringe False-Positive-Rate bei ihren Analysen zu erzielen. Diesevariiert aber von Fehlermuster zu Fehlermuster.

11

3.4 Probleme und Grenzen

1 void f 0 ( ) { i f (∗ ) { A; } else { B; } } // 2 Pfade2 void f 1 ( ) { f 0 ( ) ; f 0 ( ) ; } // 4 Pfade3 void f 2 ( ) { f 1 ( ) ; f 1 ( ) ; } // 16 Pfade4 . . .5 void f i ( ) { f i −1() ; f i −1() ; } // 2ˆ(2ˆ i ) Pfade

Listing 1.1. Beispiel fur die Entwicklung der Pfadanzahl [9]

Nach dem derzeitigen Stand der Technik konnen erweiterte statische Analyse-werkzeuge trotzdem keine 100%-ige Pfadabdeckung18 ermoglichen [9]. Dies liegtin der exponentiellen Pfadanzahlerhohung bei Schleifen und Rekursionen.Wie man im Listing 1.1 sieht, steigt die Anzahl der Pfade recht schnell an. In derersten Methode befindet sich eine Bedingung woraus sich zwei Pfade ergeben.Danach werden in den nachfolgenden Methoden die Vorherigen jeweils zweimalaufgerufen. Somit ergibt sich durch die azyklischen, interprozeduralen Metho-denaufrufe ein doppelt exponentieller Anstieg der Anzahl der Pfade.Des weiteren gewahrleisten die Zeiger-Analyse-Algorithmen noch keine exak-te Analyse [9]. Die Folge sind falsche Verweise (nicht durchfuhrbare Verweise)die in den Aufrufgraphen auftauchen oder fehlende Verweise, welche z.B. durchredundante Bedingungen entstehen. Generell ignorieren die Werkzeuge solcheAusnahmen die zu unvorhersehbaren Ausfuhrungspfaden fuhren. Auf der ande-ren Seite fordern aber diverse Sicherheitsstandards (z.B. DO-178B Standard furdie Luftfahrt) 100%-ige Abdeckung in verschiedenen Risikoklassen.Eine andere Grenze der erweiterten statischen Codeanalyse ist die eingeschrankteModellierung von konkurrienden Thread -Zugriffen (engl. mutlithreading). Hier-bei werden oft nur Annaherungen vorgenommen.Dem allgemeinen Problem, der Reduzierung der False-Positive-Rate, wird ver-sucht sich mit verschiedenen Techniken anzunahern. Auf der einen Seite werdendie Werkzeuge mit automatischen Lernfunktionen ausgestattet. Diese versuchengebrauchlichen Programmierausdrucke/ -muster und deren Absichten zu verste-hen. Auf der anderen Seite kann der Nutzer selbst bestimmte Verhaltensweisendefinieren um somit die False-Positive-Rate zu verringern.Letztendlich konnen diese Werkzeugtypen aber keine logischen Fehler im Pro-grammablauf erkennen. Diese lassen sich aber gut durch dymamische Tests her-ausfinden.3.5 Beispiele

Hierbei sollen nun kurz zwei frei erhaltliche Beispielwerkzeuge fur die erweiter-te statische Analyse betrachtet werden und weitere Anwendungen nur genanntwerden.

FindBugs. Dies ist ein Open-Source-Projekt von der Universitat von Marylandfur die Programmiersprache Java und als Eclipse Plug-in erhaltlich19. Es analy-18 Obwohl es andere Hersteller behaupten; s. [7]19 http://findbugs.sourceforge.net/

12

siert mittels Detektoren, die auf den Visitor -Entwurfsmuster beruhen, den Java-Bytecode. Dabei behaupten die Entwickler immer eine False-Positive-Rate ge-ringer als 50% zu erzielen [5]. Durch seine Struktur ist es beliebig mit neuenFehler-Detektoren erweiterbar. Bei der Analyse werden die anfallenden Datendirekt weiter verarbeitet und ausgewertet.Mittlerweile besitzt das Werkzeug schon einen ziemlich umfangreichen Fehlermu-sterkatalog der sich in verschiedene Kategorien unterteilt. Des weiteren ermog-licht es durch diverse Filter die Analyse einzuschranken und diese z.B. nur mitgewissen Detektoren durchzufuhren oder nur auf bestimmte Klassen anzuwen-den. Letztendlich kann man die Ergebnisse als XML-Report exportieren undimmer wieder in das Programm zur Fehlerauswertung und -beseitigung laden.

SemmleCode. Das schon bereits erwahnte Werkzeug SemmleCode ist ein ziemlichumfangreiches und flexibles Analysewerkzeug. Es ist als frei erhaltiches EclipsePlug-in verfugbar und basiert auf der objekt-orientierten, Allzweck-Anfragespra-che .QL, welche mehrere Ansatze in sich vereint. Somit hat sie eine starke Ahn-lichkeit zu SQL, nutzt die Fixpunkt-Semantik von Datalog20, und gebrauchtdie Eindhoven Quantifier Notation zur simplen Konstruktion von Aggregat-Funktionen21.Durch diese erweiterte Anfragesprache ist es moglich eine Vielzahl der Aufgabender statischen Analyse abzudecken und mit einer guten Performance zu berech-nen und ausgeben zu lassen, z.B. Fehler finden, Metriken berechnen, Abhangig-keiten zu verstehen oder Anfragen anzupassen und neu zu definieren. Die anfal-lenden Daten der Analyse werden in einer relationalen Datenbank abgespeichert.

Weitere Beispiele. Andere Vertreter erweiterte statische Analysewerkzeugen dieein DBS nutzen sind die kommerzielle CAST Application Intelligence Platform22

und das schon erwahnte CodeSonar. Daruber hinaus erzielt Prevent sehr guteErgebnisse und TPTP besitzt eine Komponente zur erweiterten statischen Ana-lyse.

4 Portale

Wie der aufmerksame Leser vielleicht schon wahrend des Lesen dieses Aufsatzesfestgestellt hat, reicht ein einzelnes Werkzeug heutzutage nicht mehr aus um alleBereiche der Codeanalyse zur Qualitatssicherung abzudecken. Deshalb werdendie einzelnen Werkzeugtypen oft in einer Werkzeugumgebung zusammengefuhrt(z.B. TPTP) oder ein Werkzeug ist so flexibel um mehrere Kategorien gleich-zeitig abzudecken (z.B. SemmleCode).Darauf aufbauend erstreckt sich das Gebiet der Portale zur Codeanalyse, welcheeine zentralisierte, komplexe Datenerhebung systemweit ermoglichen und diese

20 Welches eine einfache Form von logischer Programmierung ist21 Fur eine detailierte Beschreibung von .QL bitte [3] lesen22 http://www.castsoftware.com/Default.aspx

13

Abb. 2. Rollenstruktur in der Software-Entwicklung [8]

naturlich umfangreich analysieren konnen um daraus variable Berichte zu gene-rieren. Die verschiedenen Rollen in der Software-Entwicklung (Entwickler, Pro-jektleiter und Manager) haben unterschiedliche Sichten auf die zu entwickelndenSysteme (s. Abb. 2). Durch die zentralisierte Speicherung der Daten ist es nunmoglich Reporte fur jeden dieser Bereiche zu erstellen und von der Granularitatanzupassen, d.h. Analysen auf Codeebene fur den Entwickler23, Analysen aufArchitekturebene fur den Projektleiter und eine mehrere Systeme ubergreifendeSicht fur den Manager (engl. Application Portfolio Management). Des weiterenkonnen dadurch zusatzliche Metriken ermittelt werden.Oft werden Portale uber Webserver verwaltet. Dies ermoglicht es den beteilig-ten Personen mehrfach und ortsunabhangig auf die Berichte zuzugreifen undeine Personalisierung der Daten vorzunehmen (damit ist i.A. die Explorations-tiefe der Berichte gemeint). Dies hat den Vorteil einer einheitlichen Datenba-sis, welche konsistente Sichten der Ergebnisse und somit eine Vergleichbarkeitzulasst (z.B. Trendbeobachtungen auf Tages- oder Versionsbasis). Um Daten derzentralen Datenbank aktuell zu halten ist ein hoher Automatisierungsgrad er-forderlich, welcher einen relativ großen Aktualisierungsintervall zur Folge hat.Die Vernachlassigung der lokalen Gultigkeit der Analyse steht dabei deutlich imKontrast zu den Vorteilen die ein Unternehmen aus einer Portal -Nutzung ziehenkann. Diese sind Maximierung des Nutzen des ermittelten Daten, Minimierungdes Ressourcenbedarfts fur die Analyse und geringe Wartungskosten.Beispielhaft zeigt Abb. 3 den Aufbau von CodeSonar, welches eine zentralenHub hat. Dieser stellt den Zugang uber ein Web-Interface zu den automatischgenerierten Berichten bereit und ermoglicht es den beteiligten Entwicklern ihreDaten zur Analyse von Hand oder automatisch einzuspeisen. Weitere Beispiele

23 Welche auch nur auf die zu bearbeitenden Module beschrankt werden konnen

14

Abb. 3. Aufbau der Portal-Struktur von CodeSonar [9]

fur Portale sind das schon erwahnte Prevent24, Insight von Klocwork25 und dieClient/ Server-Werkzeuge von PolySpace26.

5 Fazit

Nachdem nun eine Vielzahl von Werkzeugtypen, deren Einsatzgebiete mit Bei-spielen vorgestellt wurde, sollte klar sein, dass die Nutzung solcher Hilfsmittelin einem guten Software-Entwicklungs-Prozess unerlasslich aber auch teilwei-se recht einfach ist. Die modernen Werkzeugumgebungen zum Testen und zurCodeanalyse erganzen oft die komplexen Entwicklungsumgebungen oder bindensich gut in diese als Plug-in ein. Die Vertreter aus dem Open-Source-Bereichbrauchen sich nicht vor den kommerziellen Konkurrenten zu verstecken, da diekostenlosen Projekte oft ein breites Industriekonsortium hinter sich haben (s.TPTP).Eine logische Folge, ist auch die Vereinigung mehrere Kategorien in einer Werk-zeugumgebung. Generell bilden die statischen Typen eine gute Erganzung zuden dynamischen Testwerkzeugen, ersetzen diese aber nicht. Sie helfen dem Ent-wickler trotzdem effizient echte Fehler zu finden und somit die Software-Qualitatzu steigern.Durch die breite Automatisierung reduzieren statische Analysewerkzeuge die Ko-sten im Entwicklungsprozess und sparen naturlich eine Menge Zeit ein. Mittels24 Welches sehr gut mit dem ThreadAnalyzer von Coverity zusammenarbeitet und auch

als Eclipse Plug-in in der Java-Version erhaltlich ist25 http://www.klocwork.com/default.asp26 http://www.mathworks.com/

15

variabler Berichterstellung optimieren Portale zusatzlich die Wege zur Zusam-menarbeit und den Kommunikationsfluss zwischen den beteiligten Rollen in derSoftware-Entwicklung.Deshalb sollte gerade die recht leicht zu erlernenden, frei erhaltlichen Vertreterzum Einsatz in allen (moglichen) Software-Projekt kommen, wobei diese sichoft nur auf gangigen Programmiersprachen wie C, C++ und Java beschrankendamit aber eine große Anzahl an Systemen abdecken.

Literatur

1. Liggesmeyer Home [online]. Available from: http://www.liggesmeyer.de.2. P. Anderson. Detecting Bugs in Saftey-Critical Code. Dr. Dobb’s Journal, March,

2008.3. O. de Moor, M. Verbaere, E. Hajiyev, P. Avgustinov, T. Ekman, N. Ongkingco,

D. Sereni, and J. Tibble. Keynote Address: .QL for Source Code Analysis. Technicalreport, Semmle Limited, 2007.

4. M. Harman and R. M. Hierons. An Overview of Program Slicing [online]. Availablefrom: http://www.dcs.kcl.ac.uk/staff/mark/sf.html.

5. D. Hovemeyer and W. Pugh. Finding Bugs is Easy. Technical report, Dept. ofComputer Science, University of Maryland, 2004.

6. P. Liggesmeyer. Software-Qualitat: Testen, Analysieren und Verifizieren von Soft-ware. Spektrum, Akademischer Verlag, 2002.

7. Misc. Prevent SQS C/C++. Technical report, Coverity, Inc., 2008.8. F. Simon, O. Seng, and T. Mohaupt. Code-Quality-Management. dpunkt.verlag,

2006.9. M. Zarins. Overview of GrammaTech Static-Analysis Technology. Technical report,

GrammaTech, Inc., 2008.