Igor befragen, das können gestresste Programmierer auf der Internetseite www.AskIgor.org. Damit sich Igor der Sache annimmt, dürfen sie aber nicht mit völlig leeren Händen kommen: Das zu testende Programm muss zumindest unter bestimmten Umständen funktionieren.
Sie gehen auf unsere Website und dort tragen Sie den Namen des ausführbaren Programms ein, sowie, wo das Programm fehlschlägt. Dann drücken Sie einen großen Knopf "Such den Fehler" und nach ein paar Minuten bekommen Sie von unserem System eine so genannte Ursache-Wirkungskette. Die sagt Ihnen, was in ihrem Programm passiert ist.
Professor Andreas Zeller von der Universität Saarbrücken verfolgt mit der "AskIgor"-Website zwei Ziele: Zum einen soll der Webdienst schon jetzt Programmierern nützlich sein. Zum anderen geben die auf das AskIgor-System hochgeladenen Programme hervorragendes Testmaterial ab. Zeller und sein Team wollen nämlich die dahinter steckende Technologie, das so genannte "Delta-Debugging", erproben und weiterentwickeln. Beim normalen Debuggen, also bei der systematischen Fehlersuche, muss der Programmierer quasi per Hand Zeile für Zeile durch den Bauplan seines Werks, den "Quellcode" gehen. Zellers Verfahren dagegen beobachtet das Verhalten eines Programms von außen, notfalls auch ohne den Quellcode zu kennen. Oft gibt es zum Beispiel zwei Programmversionen, von denen eine funktioniert und die andere nicht. "Delta-Debugging" kann durch den Vergleich des Programmverhaltens feststellen, wo genau der Fehler liegt. Und zwar auch dann, wenn es eine ganze Reihe von möglichen Ursachen gibt:
Delta steht in der Wissenschaft allgemein für den Unterschied, und die Grundidee von Deltadebugging ist, dass wir eine Fehlerursache grundsätzlich als einen Unterschied begreifen zwischen einer Situation, wo der Fehler auftritt und einer Situation, wo der Fehler nicht auftritt. Deltadebugging versucht nun, aus einem ursprünglich großen Unterschied zwischen zwei beliebigen Szenarien automatisch diesen Unterschied durch systematische Experimente einzuengen, indem dieses Experiment immer und immer wiederholt wird, so dass wir letzten Endes bei einem kleinen, aber relevanten Unterschied landen, der die tatsächliche Fehlerursache ist.
Es gibt noch eine ganze Menge Arbeit für Zeller und seine Kollegen. Da ist zum einen die Anpassung des Prinzips auf verschiedene Betriebssysteme und Programmiersprachen. AskIgor versteht sich bislang nur auf Linux-Programme - eine Version für Windows ist allerdings in Planung. Außerdem soll es in Kürze auch eine herunterladbare Version geben, die dann auf dem Rechner des Programmierers vor Ort läuft. Denn Projekte mit kommerziellem Hintergrund wird kaum jemand einer fremden Website anvertrauen wollen. Ein weiteres Ziel ist es, dem Programmierer zu einem gefundenen "Bug" auch gleich einen grundsätzlichen Verbesserungsvorschlag zu liefern. Dazu müsste der automatische Prüfprozess auch generelle Aussagen über die Art des Fehlers machen können. Das Problem wollen die Forscher mit einem so genannten iterativen Verfahren lösen: Ein hundertfaches Wiederholen des zu prüfenden Programms mit jeweils leicht veränderten Einstellungen. Und aus Hunderten von ähnlichen Einzelfehlern kristallisiert sich dann der grundsätzliche Fehlertypus heraus. Die automatische Fehlersuche wird in naher Zukunft wichtiger Bestandteil moderner Programmiersprachen sein. Sie wird direkt beim Programmieren im Hintergrund mitlaufen, davon ist Andreas Zeller überzeugt. Schon jetzt fangen Entwicklungswerkzeuge wie "Java" oder ".net" Standardfehler wie etwa einen falschen Umgang mit dem Speicher von vornherein ab. Moderne, quasi "mitdenkende" Programmiersprachen sind zwar manchmal nicht mehr so schnell und effizient wie ihre Vorläufer. Aber der Mehraufwand lohnt sich, so Zeller:
Die Verfahren, die wir heute zur Programmanalyse benutzen, benötigen allesamt ordentlich Rechenkraft. Um Programme zu schreiben, brauchen Sie keine Rechenkraft, da brauchen Sie Menschenkraft. Nun ist aber so, dass die Anzahl der Programmierer, die Anzahl der Programme, die geschrieben werden, die Anzahl der Programmzeilen die geschrieben wird, recht konstant ist, wohingegen sich die Rechenkraft unserer Rechner alle 1,5 Jahre verdoppelt. Das heißt, alle 1,5 Jahre sind wir in der Lage, doppelt so große Analysen zu fahren wie das bisher der Fall war, und in dieser Hinsicht bin ich außerordentlich optimistisch. Da steht uns ein gewaltiges Arsenal an Rechenkraft und Verfahren zur Verfügung, was uns in Zukunft hoffentlich sehr viel robustere und sehr viel zuverlässigere Programme bescheren wird.
Sie gehen auf unsere Website und dort tragen Sie den Namen des ausführbaren Programms ein, sowie, wo das Programm fehlschlägt. Dann drücken Sie einen großen Knopf "Such den Fehler" und nach ein paar Minuten bekommen Sie von unserem System eine so genannte Ursache-Wirkungskette. Die sagt Ihnen, was in ihrem Programm passiert ist.
Professor Andreas Zeller von der Universität Saarbrücken verfolgt mit der "AskIgor"-Website zwei Ziele: Zum einen soll der Webdienst schon jetzt Programmierern nützlich sein. Zum anderen geben die auf das AskIgor-System hochgeladenen Programme hervorragendes Testmaterial ab. Zeller und sein Team wollen nämlich die dahinter steckende Technologie, das so genannte "Delta-Debugging", erproben und weiterentwickeln. Beim normalen Debuggen, also bei der systematischen Fehlersuche, muss der Programmierer quasi per Hand Zeile für Zeile durch den Bauplan seines Werks, den "Quellcode" gehen. Zellers Verfahren dagegen beobachtet das Verhalten eines Programms von außen, notfalls auch ohne den Quellcode zu kennen. Oft gibt es zum Beispiel zwei Programmversionen, von denen eine funktioniert und die andere nicht. "Delta-Debugging" kann durch den Vergleich des Programmverhaltens feststellen, wo genau der Fehler liegt. Und zwar auch dann, wenn es eine ganze Reihe von möglichen Ursachen gibt:
Delta steht in der Wissenschaft allgemein für den Unterschied, und die Grundidee von Deltadebugging ist, dass wir eine Fehlerursache grundsätzlich als einen Unterschied begreifen zwischen einer Situation, wo der Fehler auftritt und einer Situation, wo der Fehler nicht auftritt. Deltadebugging versucht nun, aus einem ursprünglich großen Unterschied zwischen zwei beliebigen Szenarien automatisch diesen Unterschied durch systematische Experimente einzuengen, indem dieses Experiment immer und immer wiederholt wird, so dass wir letzten Endes bei einem kleinen, aber relevanten Unterschied landen, der die tatsächliche Fehlerursache ist.
Es gibt noch eine ganze Menge Arbeit für Zeller und seine Kollegen. Da ist zum einen die Anpassung des Prinzips auf verschiedene Betriebssysteme und Programmiersprachen. AskIgor versteht sich bislang nur auf Linux-Programme - eine Version für Windows ist allerdings in Planung. Außerdem soll es in Kürze auch eine herunterladbare Version geben, die dann auf dem Rechner des Programmierers vor Ort läuft. Denn Projekte mit kommerziellem Hintergrund wird kaum jemand einer fremden Website anvertrauen wollen. Ein weiteres Ziel ist es, dem Programmierer zu einem gefundenen "Bug" auch gleich einen grundsätzlichen Verbesserungsvorschlag zu liefern. Dazu müsste der automatische Prüfprozess auch generelle Aussagen über die Art des Fehlers machen können. Das Problem wollen die Forscher mit einem so genannten iterativen Verfahren lösen: Ein hundertfaches Wiederholen des zu prüfenden Programms mit jeweils leicht veränderten Einstellungen. Und aus Hunderten von ähnlichen Einzelfehlern kristallisiert sich dann der grundsätzliche Fehlertypus heraus. Die automatische Fehlersuche wird in naher Zukunft wichtiger Bestandteil moderner Programmiersprachen sein. Sie wird direkt beim Programmieren im Hintergrund mitlaufen, davon ist Andreas Zeller überzeugt. Schon jetzt fangen Entwicklungswerkzeuge wie "Java" oder ".net" Standardfehler wie etwa einen falschen Umgang mit dem Speicher von vornherein ab. Moderne, quasi "mitdenkende" Programmiersprachen sind zwar manchmal nicht mehr so schnell und effizient wie ihre Vorläufer. Aber der Mehraufwand lohnt sich, so Zeller:
Die Verfahren, die wir heute zur Programmanalyse benutzen, benötigen allesamt ordentlich Rechenkraft. Um Programme zu schreiben, brauchen Sie keine Rechenkraft, da brauchen Sie Menschenkraft. Nun ist aber so, dass die Anzahl der Programmierer, die Anzahl der Programme, die geschrieben werden, die Anzahl der Programmzeilen die geschrieben wird, recht konstant ist, wohingegen sich die Rechenkraft unserer Rechner alle 1,5 Jahre verdoppelt. Das heißt, alle 1,5 Jahre sind wir in der Lage, doppelt so große Analysen zu fahren wie das bisher der Fall war, und in dieser Hinsicht bin ich außerordentlich optimistisch. Da steht uns ein gewaltiges Arsenal an Rechenkraft und Verfahren zur Verfügung, was uns in Zukunft hoffentlich sehr viel robustere und sehr viel zuverlässigere Programme bescheren wird.