Angeregt durch Karl heinzs Beitrag möchte ich nun auch etwas
rumtheoretisieren. Konkreter wird's dann weiter unten :-)
Computer werden üblicherweise als äquivalent zu einer Turing-Maschine
betrachtet, da man dadurch grundlegende Erkenntnisse der theoretischen
Informatik in die Praxis umsetzen kann. Bei der Entwicklung von
Programmiersprachen wie C wird darauf geachtet, dass sie Turing-
vollständig sind, d. h. dass in ihnen jede beliebige Turing-Maschine
realisiert werden kann.
Ich gehe davon aus, dass du mit Zustandsautomat einen endlichen
Automaten meinst. Endliche Automaten sind weniger mächtig als
Turing-Maschinen, d. h. jeder endliche Automat kann als
Turing-Maschine dargestellt werden, aber nicht umgekehrt.
Aus dem Geschriebenen folgt, dass ein C-Programm im Allgemeinen nicht
endlicher Automat dargestellt werden kann.
So ist das zumindest in der Theorie.
In der Praxis sieht es anders aus: Computer sind keine Turing-
Maschinen, sondern endliche Automaten, weil sie auf Grund der
begrenzten Speicherkapazität nur endlich viele Zustände annehmen
können*. Damit lassen sich entgegen dem oben Geschriebenen alle
C-Programme, die auf einem realen Computer lauffähig sind, ebenfalls
durch einen endlichen Automaten beschreiben. Man kann sogar alle auf
einem Computer lauffähigen Programme durch endliche Automaten
darstellen, die dieselben Zustände (alle möglichen Speicher- und
Registerbelegungen) und Zustandsübergänge (gegeben durch den
Hardwareaufbau) haben und sich lediglich in ihrem Anfangszustand
unterscheiden. D. h. du kannst dir (theoretisch) den Zustandsgraphen
mit einem sehr spitzen Bleistift und viel Geduld auf ein großes Stück
Papier malen, dieses an die Wand hängen und für jedes Programm, das du
entwickelst, den zugehörigen Startzustand farblich markieren. Damit
hast du die gewünschte Darstellung. Ob diese übersichtlicher ist als
der C-Quellcode wage ich allerdings zu bezweifeln.
> Ein Programm das ein beliebiges Anderes analysiert und einen
> äquivalenten Zustandsautomaten erzeugt stelle ich mir schwierig vor.
> Ich würde sogar sagen, dass du berühmt würdest wenn du sowas
> hinkriegst, denn das würde das Turing-Halteproblem lösen.
Das ist hier nicht das Problem. Geht man vom (unendlichen)
Turing-Modell aus, ist die Umsetzung in einen endlichen Automaten
nicht etwa schwierig oder algorithmisch nicht lösbar, sondern i. Allg.
schlichtweg nicht existent. Geht man vom Modell des endlichen
Automaten aus, ist die Umsetzung relativ leicht durchführbar, wenn
eine formale Beschreibung der Computerhardware vorliegt. Diese steckt
bspw. in jedem Rechnersimulationsprogramm drin.
*) Die Anzahl der Zustände ist allerdings so groß, dass die Turing-
Maschine ein handlicheres, wenn auch nicht 100%ig korrektes Modell
darstellt.
Genug theoretisiert. Ich wollte dir mit diesem Geschwätz eigentlich
nur sagen, dass die ausschließliche Verwendung von endlichen Automaten
i. Allg. nicht das geeignete Mittel ist, um komplexe C-Programme
übersichtlicher darzustellen. Man kann damit aber gewisse Teilaspekte
von Programmabläufen verdeutlichen. Andere Teilaspekte können bspw.
durch Klassendiagramme (bei objektorientierter Programmierung) oder
Sequenzdiagramme dargestellt werden.
Die Entscheidung, welche Aspekte mit welchen Mitteln beschrieben
werden, erfordert nach dem derzeitigen Stand der Technik jedoch den
Einsatz natürlicher Intelligenz, die manchmal durch geeignete Tools
(z. B. bei der Erstellung von Klassendiagrammen) unterstützt werden
kann.
Auch für die klassische Darstellung von Algorithmen mittels
Flussdiagrammen und Struktogrammen gibt es Tools, die sogar meist
vollautomatisch arbeiten. Da diesen Tools aber die Fähigkeit zur
Abstraktion fehlt, ist das Ergebnis meist wieder ein C-Programm, bei
dem um zusammenhängende Blöcke Kästchen gezeichnet werden und
Steuerkonstrukte wie Schleifen und Verzweigungen durch entsprechende
grafische Symbole ersetzt werden. Da diese Darstellunge bei komplexen
Algorithmen deutlich mehr Platz brauchen als ihr C-Äquivalent, ist
ihre Übersichtlichkeit aber meist schlechter als der ursprüngliche
C-Code.
Die beste Softwaredokumentation besteht meiner Meinung nach immer
noch aus gut kommentiertem Quellcode, einer Prosabeschreibung der
grundlegenden Ideen, die in dem Programm realisiert wurden, und
einigen manuell und mit Verstand angefertigten Bildchen (z. B.
Zustandsgraphen, Klassendiagramme, Sequenzdiagramme, Zeitdiagramme,
geometrische Skizzen, Regelkreisdiagramme oder was sonst eben so
passt), die Sachverhalte abstrahieren, d. h. wesentliche Dinge
darstellen und unwesentliche weglassen.
