![\"\"](\"http:\/\/phaidon.philo.at\/qu\/wp-content\/uploads\/2012\/06\/220px-Turing_Test_version_3.png\")
<\/a><\/p>\nEin im Jahr 1950 von Alan Turing entwickelter Test versucht diese Frage durch ein spezielles Setting zu normieren: Es gibt 3 Spieler A, B und C. Spielerin C ist ein Mensch und muss auf Basis eines Frage- und Antwortspiels \u00fcber einen limitierten Kanal herausfinden, wer Mensch und was Computer ist. Kann C das nicht, muss sie davon ausgehen, dass auch Computer denken k\u00f6nnen (oder vorsichtig formuliert: C stellt fest, dass sie beim Output von denkenden Wesen und von Computern \u00fcber diesen Kanal keinen feststellbaren qualitativen Unterschied erkennen kann).<\/p>\n
W\u00fcrde C ausschlie\u00dflich die Meldungen zu ihrem Geburtstag<\/a> auf Facebook einem Turing-Test unterziehen, k\u00f6nnte sie sie zu dem Schluss gelangen, dass ein Gro\u00dfteil ihrer “Freunde” sich wie einfallslose Maschinen verhalten, jedoch mehr Rechtschreibfehler machen.<\/p>\n Der Streit ist vorprogrammiert<\/a>, wenn es um die Unterscheidung von Simulation und echtem, menschlichen Verhalten geht. Als ob wir ignorierten, dass die Tricks der Simulation von unserem eigenen Wunsch ausgehen, uns selbst zu \u00fcberraschen, zu t\u00e4uschen oder zu entlasten. Die zum Leben erwachte, verselbst\u00e4ndigte Maschine ist von uns selbst angetrieben<\/a>.<\/p>\n Zum 100. Geburtstag von Alan Turing schiebe ich den Turing-Test zur Seite. Zum Vorschein kommen die Turing-Maschine und die Frage nach der Relevanz in Informatikforschung und Softwareverwendung.<\/p>\n Die Turingmaschine und die Grenzen der Softwareanalyse<\/strong><\/p>\n Die Turingmaschine ist ein Gedankenexperiment, in dem einen fiktive Maschine Zeichen auf einem Band manipuliert. Es gibt vier Operationen: Der bewegliche Schreib-\/Lesekopf kann sich nach links und rechts bewegen sowie ein Zeichen an der aktuellen Position lesen bzw. \u00fcberschreiben. Wann welche Operation ausgef\u00fchrt wird, wird durch den aktuellen Zustand und einer Tabelle mit Regeln der folgenden Art bestimmt: Wenn Zustand x, dann wechsle in Zustand y und f\u00fchre Operation z aus. Auf diese Art l\u00e4sst sich jeder Algorithmus beschreiben und analysieren. Das Prinzip ist bis heute dasselbe geblieben, sodass man (mit gen\u00fcgend Geduld und Platz) jeden Algorithmus als Turingmaschine beschreiben k\u00f6nnte.<\/p>\n Turing hat mit Hilfe einer fiktiven Maschine die Grundlagen der Berechenbarkeitstheorie stark gepr\u00e4gt. Beispielsweise hat er mit dem sogenannten Halteproblem gezeigt, dass es kein Verfahren, also kein Programm, gibt mit dem wir f\u00fcr ein beliebiges<\/em> Programm p feststellen k\u00f6nnen, ob p zu einem Ende gelangt. Es stellt sich heraus, dass alle interessanten Eigenschaften von p nicht hinreichend von Programmen entschieden werden k\u00f6nnen.<\/p>\n Software die wir im Alltag verwenden sind Betriebssysteme, Internet-Browser, Textverarbeitungsprogramme. Diese sind zunehmend un\u00fcbersichtlich geworden. Microsoft Windows XP basiert auf 45 Millionen Zeilen Programmcode. Obwohl wir jedes Snippet Programmcode von Microsoft Windows analysieren k\u00f6nnten, reicht unsere Lebenszeit nicht aus, jede Zeile zu analysieren. Im Unterschied dazu ist es m\u00f6glich, ein Buch und unter Umst\u00e4nden sogar das ganze Lebenswerk von Niklas Luhmann zu lesen.<\/p>\n Motiviert durch zunehemende Komplexit\u00e4t und Un\u00fcbersichtlichkeit von Software nimmt die Informatikforschung zwar die Ergebnisse von Turing hin, versucht aber trotzdem, Verfahren zu entwickeln, die Eigenschaften von Programmen extrahieren. Die Art und Weise, mit Hilfe eines Programms Eigenschaften eines anderen Programms festzustellen, wird in der aktuellen Informatikforschung Softwareanalyse<\/em> genannt, wobei zwischen statischer und dynamischer Softwareanalyse unterschieden wird. W\u00e4hrend dynamische Softwareanalyse das Programm w\u00e4hrend es l\u00e4uft (“zur Laufzeit”) mit Hilfe eines Analyseprogramms analysiert, betrachtet statische Analyse nur den Programmcode und \u00a0die Struktur desselben. Die Ergebnisse von Turing bilden die \u00e4u\u00dfersten theoretischen Grenzen vor allem der statischen Softwareanalyse.<\/p>\n Was mich ausgehend von Turing interessiert ist die Komplexit\u00e4t heutiger Software. Ich betrachte also nicht Text zum Zwecke der Kommunikation sondern Programmcode zum Zwecke der automatischen Abarbeitung von Aufgaben. Dabei sind zwei Dimensionen zu betrachten, durch die sich verstehen l\u00e4sst, warum Software die Eigenschaft hat, un\u00fcbersichtlich zu werden. Eine dritte Dimension weist auf die materielle Abh\u00e4ngigkeit von (noch so verschachtelter) Software hin. Unter Ber\u00fccksichtigung dieser Dimension kann die Tendenz zur Komplexit\u00e4tssteigerung von Software sowohl ausgenutzt, als auch gebremst und gedreht werden, was der Softwareanalystin zumindest lokale \u00dcbersichtlichkeiten er\u00f6ffnet.<\/p>\n R\u00e4umliche Dimension – Software als Labyrinth<\/strong><\/p>\n Abh\u00e4ngig von den konkreten Eingabewerten einer Software, durchwandert der Computer einen von vielen m\u00f6glichen Pfade durch die Software. Die Gesamtheit der m\u00f6glichen Pfade bildet ein Labyrinth, genauer ein geflechtartiges Gebilde (“control-flow graph”). Die Anzahl der m\u00f6glichen Pfade w\u00e4chst exponentiell mit der Anzahl an Verzweigungen des Geflechts, d.h. praktisch: Je mehr Zeilen ein Programm hat, desto mehr m\u00f6gliche Pfade hat es in der Regel.<\/p>\n Obwohl jede Instruktion, jedes Pfadst\u00fcck, pr\u00e4zise definierte Effekte bewirkt, gelingt es uns rein syntaktisch nicht, all jene Wege zu finden, die die gew\u00fcnschten Eigenschaften erf\u00fcllt, ohne den Weg tats\u00e4chlich zu gehen. Denn nicht alle Eigenschaften sind direkt aus den Instruktionen abzuleiten, manche ergeben sich erst zur Laufzeit. Dies ist ein Grund, weswegen pragmatische Softwareentwicklerinnen davon ausgehen, dass viele Fehler erst nach der Publikation der Software gefunden werden. Sie rechnen manchmal damit, dass selbst kleine \u00c4nderungen in einer unscheinbaren Routine zu unvorhergesehenen Folgen (z.B. Abst\u00fcrzen) f\u00fchren k\u00f6nnen. Die Betrachtung eines Ausschnitts des Programmcodes ist keine Garantie daf\u00fcr, dass man ihren Einfluss auf das Gesamtverhalten des Systems verstanden hat.<\/p>\n Sowohl Menschen als auch Maschinen gelangen durch Explosion der M\u00f6glichkeiten an ihre Grenzen.<\/p>\n Zeitliche Dimension – Software lebt<\/strong><\/p>\n Selbst wenn wir f\u00fcr wichtige Programme die labyrinth-artige Struktur von Software in den Griff bekommen und durch Austesten, manuelle Code-Reviews oder ann\u00e4herungsweise Softwareanalyse Fehlfunktionen finden k\u00f6nnen, ist weiters zu betrachten, dass Software st\u00e4ndig in Bearbeitung ist.<\/p>\n Eine Referenzversion des Betriebssystems Linux kann schon nach 2 Wochen an zentralen Stellen von der Entwicklergemeinschaft modifiziert<\/a> sein. Die Analyse hinkt aktiven Codeprojekten hinterher, da diese st\u00e4ndig “work in progress” sind.<\/p>\n Software ist nat\u00fcrlicher geworden, durch unsere kontinuierliche Partizipation an ihr.<\/p>\n Materielle Dimension – Software l\u00e4uft auf Hardware<\/strong><\/p>\n Die letzten beiden Dimensionen betrachten die Sph\u00e4re von Software isoliert von der Hardware auf der sie letztlich l\u00e4uft. Gerade jetzt, wo Software in voller Bl\u00fcte steht und High-Level-Programmiersprachen direkten Hardwarezugriff vermeiden, k\u00f6nnte man \u00fcbersehen, dass unsere elektronischen Ger\u00e4te auf hoch-standardisierten Bauteilen beruhen. Anders gesagt: Nur wenn die Hardware mitspielt,\u00a0 d.h. Millionen von Transistoren, Speicherkondensatoren, etc. sich entsprechend ihrer Spezifikation verhalten, folgt ein Computer den formalen Instruktionen der Softwareentwicklerin.<\/p>\n Um physikalischen Ausf\u00e4llen tempor\u00e4r zu entgehen, setzt man etwa in gro\u00dfen Rechenzentren auf Virtualisierung ganzer Rechner. Eine virtuelle Maschine ist ein St\u00fcck Software, das mit einer physikalischen Maschine funktional \u00e4quivalent ist. Programme, die in der virtuellen Maschine laufen, merken keinen Unterschied. Sie verhalten sich, als ob sie direkt mit dem Speicher und Prozessor der physikalischen Maschine arbeiten. Tats\u00e4chlich spielt eine Software die Rolle einer physikalischen Maschine und vermittelt die Interaktion zwischen Software und Hardware. Der dadurch entstandene Spielraum kann produktiv genutzt werden.<\/p>\n Was \u00e4ndert Virtualisierung an der Tatsache, dass am Ende der Kette von Softwarekomponenten eine physikalische Maschine stehen muss? Nicht viel, aber doch Entscheidendes. Die Vermittlungsfunktion einer virtuellen Maschine f\u00fchrt zu einer Abkapselung mit vielen Vorteilen. Virtuelle Maschinen k\u00f6nnen bequem im Netzwerk transferiert werden, sodass man Rechenkraft (computational power) besser nutzen kann. Bei h\u00f6herer Auslastung werden virtuelle Maschinen automatisch auf weitere physikalische Maschinen kopiert, um Engp\u00e4sse zu vermeiden. Man erh\u00e4lt also programmatische Kontrolle \u00fcber das Verhalten von Rechnern (siehe z.B. Amazon Elastic Compute Cloud<\/a>).<\/p>\n Das Verh\u00e4ltnis zwischen physikalischer und virtueller Maschine \u00e4hnelt dem zwischen Turingmaschine (TM) und Universeller Turingmaschine (UTM).<\/p>\n Stelze, Hochstand, Flug<\/strong><\/p>\n<\/a><\/p>\n\n