Zitat Zitat von s.o.
Ich habe gerade studiumsbedingt viel mit Moore and Mealy automaten zu tun. (Etechnik in München). Ich habe die Erfahrung gemacht, dass so kleinere Codes (aka Blinklicht, Ampelsteuerung) noch verdammt übersichtlich sind. Sobald es aber etwas komplizierter wird (aka Quicksort) oder komplexere Steuerungen ist es echt schwer den Überblick zu behalten.
Dazu zwei Anmerkungen: Bei Zustandsautomaten verlierst Du schnell den Überblick, wenn Du keine Zeichnung (Grafik) des Diagramms hast, die sicher mit dem tatsächlichen Code übereinstimmt. Das Tool stellt das aber sicher (und nur das!). Deshalb behältst Du den Überblick.

Algorythmische Aufgaben, die nicht auf Ereignisse warten müssen, wie z.B. den Quicksort, solltest Du nicht versuchen, mit einem Zustandsdiagramm zu lösen. Nicht weil er zu kompliziert wäre, sondern weil er keine Zustände hat, in denen er auf Ereignisse warten muss.

Einen TCP Protokollstack aber z.B. könnte man spielend so lösen, obwohl der sicherlich auch kompliziert ist.

Zitat Zitat von s.o.
meiner Meinung nach immer noch schlechter als es gleich in C zu schreiben.
Wir schreiben in C! Der Code Generator generiert nur das Eigentliche Zustandsdiagramm (In C) und stellt damit sicher, dass Grafik und programmierter Code übereinstimmen.

Das Message Passing Framework sorgt für die Nebenläufigkeiten. Es hat auserdem ein eingebautes Tracing framework. Wir haben hier 3 Dinge, die Hand in Hand arbeiten:

1. Das message Passing Framework, das Nebenläufigkeiten, Timeouts und Tracing implementiert (In C).
2. Den StadteChartCoder, der auf dieses Framework passgenau zugeschnittene Zustandsautomaten codiert (In C).
3. Trace2UML ( http://trace2uml.tigris.org ) der die Trace Ausgaben des Framework versteht und die Zusammenarbeit der einzelnen Maschinen grafisch darstellen kann (zum debuggen)

Außerdem hat Astade noch eine Build Oberfläche um den Compiler und den Editor komfortabel aufzurufen.