Open Source im professionellen Einsatz
Linux-Magazin 09/2008
Abbildung 1: Defekte im Quellcode finden ist nicht einfach und lässt den Ruf nach automatisierten Analysen laut werden.

Abbildung 1: Defekte im Quellcode finden ist nicht einfach und lässt den Ruf nach automatisierten Analysen laut werden.

Fehler in Programmen vermeiden, entdecken und beheben

Mensch gegen Maschine

In manchen Bereichen möchte sich der Mensch nur ungern vom Rechner ins Handwerk pfuschen lassen. Neben Fragen der Intelligenz und Kreativität gehört auch das Bugfixing mit dazu. Dabei gibt es nützliche Werkzeuge, die nicht zwangsläufig das Ende des Zeitalters der Qualitätssoftware bedeuten.

542

Inhalt

98 | Statische Software-Analyse

Ein Scanner untersucht kostenlos mittels statischer
Software-Analyse den Code von Open-Source-Projekten.

102 | Perl-Snapshot: Websites mit Catalyst

Jeder Programmiersprache ihr eigenes Framework. Statt Rails benutzt
Perl-Meister Mike Schilli Catalyst, um seine eigene Quizshow zu
veranstalten.

Niemand lässt sich gerne die eigenen Fehler vorhalten - schon gar nicht von seiner Maschine. Die Deutungshoheit des Programmierers, ob sein Programm das tut, was es tun soll, ist wohl auch nicht gefährdet, die Aufgabe scheint für Computer zu komplex.

Ein Irrtum. Tatsächlich stellen Entwickler die Frage bloß falsch: Kaum einer legt in überprüfbarer Weise eine Spezifikation seiner Software fest. Denn formale Verifikation ist ein alter Hut. Schon Mitte der 1980er Jahre kam mit der Programmiersprache Eiffel die Idee auf, Vor- und Nachbedingungen festzulegen, die ein Codefragment erfüllen sollte, um es automatisch zu verifizieren [1].

Das Prinzip des Design by Contract hat Generationen von Informatikstudenten schlaflose Nächte bereitet [2]. So mächtig die Idee auch scheint, so komplex ist es, sie umzusetzen, daher findet kaum etwas von ihr unmittelbar in der modernen Software-Entwicklung Einzug. Im Grunde ähneln sich nämlich Projektmanager und Programmierer in einem: Sie wollen Ergebnisse sehen. Stundenlang an formalen Spezifikationen zu basteln erscheint da wenig sexy.

Hier kommen Rechner wieder ins Spiel. 1979 sollte Lint den Wunsch erfüllen, lästige Qualitätssicherung an den Rechner zu deligieren. Weil es aber jenseits aller Pragmatik äußerst penibel war, verloren Entwickler den Spaß an der guten Idee.

Lange köchelte das Thema nur in den Fakultäten für Compilerbau auf Sparflamme, bis ab 2000 die Disziplin der statischen Software-Analyse neuen Aufwind bekam. Unzufrieden mit meist syntaktischen Ansätzen, begann die Forschung damit, die verfügbare Rechenpower einzusetzen. Sie simuliert viele Ablaufpfade und denkbare Variablenbelegungen und zieht daraus Schlüsse. Das klappt ziemlich gut, erfordert aber Einarbeitungszeit in die jeweiligen Tools.

Automatisierte Tests ermitteln in Produktionscode in jeder zehntausendsten (bei guter Qualität) bis jeder hundertsten Zeile (bei eher mäßiger) mögliche Probleme. Je nach Scanner sind davon etwa 20 Prozent wirkliche Schwachstellen.

Immer schlechterer Code?

Ob daraus ein Trend zu schlechterer Qualität abzuleiten ist, bleibt schwer zu sagen. Aber selbst bei gleichbleibender Fehlerquote steigt die absolute Zahl von Fehlern mit der Menge des produzierten Code. Insofern erklärt sich die Nachfrage nach kommerziellen wie freien Werkzeugen, die Entwickler entlasten.

Es ist verlockend, die Codequalität von Open Source und proprietären Produkten zu vergleichen. Das Ergebnis hängt davon ab, wer die Studie durchführt, wie bei Benchmarks üblich: Anbieter Fortify stellt OSS ein schlechtes Zeugnis aus, betrachtet aber nur Java-Programme [3]. Wettbewerber Coverity dagegen attestiert dem Linux-Kernel bessere Qualität als den meisten proprietären Produkten [4]. Das sieht Microsoft natürlich ganz anders [5]. Quintessenz: Solange Entwickler Software schreiben, machen sie Fehler. Daher nützt ein gut ausgestattetes Werkzeug. Am Ende zählt, ob jemand die Fehler behebt. Dann ist wieder ausschließlich der Mensch gefordert.

Infos

[1] Eiffel [https://www.eiffel.com]

[2] Design by Contract: [http://de.wikipedia.org/wiki/Design_By_Contract]

[3] Linux-Magazin Online: [http://www.linux-magazin.de/news/umstrittene_fortify_studie_stellt_open_source_schlechtes_security_zeugnis_aus]

[4] Forrest Cook, "Kernel Code Quality Study":[http://lwn.net/Articles/115530/]

[5] Jeff Jones, "Coverity Confused Claims Cause Consternation And Confusion": [http://blogs.technet.com/security/archive/2006/05/12/428149.aspx]

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Einführung

    Wachsende Codemengen bedeuten mehr Fehler. "Es irrt der Mensch, so lang er strebt", beschreibt Goethe dieses Menschenlos. Entwicklern stellt sich die Frage nach Konsequenzen und Präventionen.

  • Ingenieurskunst

    Viele Experten halten Eiffel für die beste Programmiersprache, um wirklich zuverlässige Software zu entwickeln. Mit dem neuerdings freien Eiffelstudio stellen Sie diese Theorie auf den Prüfstand.

  • Sichere Programme

    In fast jeder Software stecken Fehler, nicht wenige davon untergraben sogar die Sicherheit. Was können die Entwickler schon bei Beginn dagegen tun? Ein Überblick.

  • SQL-Schwäche in Ruby on Rails
  • Getriebeschaden

    Dreht sich das Perl-Rad nur noch knirschend, sind vielleicht Fehler im Perl-Interpreter oder in Erweiterungsmodulen schuld. Der gute alte GDB inspiziert das Getriebe und kommt Problemstellen auf die Schliche.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.