66
2 Spezifikation und Modellierung
Kommerzielle Implementierungen von StateCharts bieten üblicherweise einige
Mechanismen, um die Nachteile von StateCharts zu umgehen. So kann etwa CCode verwendet werden, um Programmiersprachenkonstrukte zu unterstützen. In
StateMate stellen die sogenannten Module Charts Hardwarestrukturen dar.
In Bezug auf Zeitbedingungen ermöglichen StateCharts nur die Angabe von
Timeouts. Es gibt keine weitere direkte Möglichkeit, andere Zeitbedingungen anzugeben.
UML beinhaltet eine Version von StateCharts und erlaubt damit die Modellierung
endlicher Automaten. UML Version 1 nennt diese state diagrams, während sie ab
UML 2.0 state machine diagrams genannt werden. Leider unterscheidet sich die
Semantik der UML-Diagramme von StateMate, da UML die drei beschriebenen
Simulationsphasen nicht vorgibt.
2.4.3 Synchrone Sprachen
Motivation
Es ist schwierig, komplexe Systeme mit Hilfe endlicher Automaten zu beschreiben, da diese keine komplexen Berechnungen enthalten. Standard-Programmiersprachen dagegen können komplexe Berechnungen beschreiben, garantieren dafür aber
meist nicht die Ausführungsreihenfolge mehrerer Threads. In einer Multi-ThreadedUmgebung mit präemptivem (d.h. verdrängendem) Scheduling sind viele verschiedene Ablaufreihenfolgen der einzelnen Berechnungen möglich. Es ist schwer, alle
möglichen Abläufe in einem solchen nebenläufigen System zu verstehen. Einer der
Hauptgründe dafür ist, dass im Allgemeinen mehrere verschiedene Ausführungsreihenfolgen möglich sind, die Reihenfolge der Ausführung ist also nicht festgelegt.
Allerdings kann diese Reihenfolge durchaus das Ergebnis beeinflussen. Das sich
daraus ergebende nichtdeterministische Verhalten kann eine Reihe von Problemen
zur Folge haben, wie z.B. das Problem, einen bestimmten Entwurf zu verifizieren.
Bei verteilten Systemen mit unabhängigen Uhren ist deterministisches Verhalten nur
schwer realisierbar. Bei nicht verteilten Systemen können wir aber versuchen, die
Probleme einer unnötig nichtdeterministischen Semantik zu vermeiden.
Synchrone Sprachen verbinden endliche Automaten und Programmiersprachen zu
einem Modell. Sie können komplexe Berechnungen beschreiben, folgen aber dem zu
Grunde liegenden Ausführungsmodell endlicher Automaten. Dabei beschreiben sie
nebenläufig arbeitende Automaten. Deterministisches Verhalten wird durch die folgende wichtige Eigenschaft erreicht: „wenn Automaten parallel kombiniert werden,
dann besteht eine Transition des zusammengesetzten Automaten aus der ‚gleichzeitigen‘ Transition aller einzelnen Automaten” [198]. Das bedeutet, dass man nicht
alle möglichen Abfolgen von Zustandsübergängen aller Automaten betrachten muss,
wie dies bei unabhängigen Takten in den Unterautomaten der Fall wäre. Stattdessen kann man die Existenz eines einzigen globalen Taktes annehmen. Bei jedem
Taktsignal werden alle Eingaben berücksichtigt, neue Ausgaben und Zustände wer-
2 Spezifikation und Modellierung
Kommerzielle Implementierungen von StateCharts bieten üblicherweise einige
Mechanismen, um die Nachteile von StateCharts zu umgehen. So kann etwa CCode verwendet werden, um Programmiersprachenkonstrukte zu unterstützen. In
StateMate stellen die sogenannten Module Charts Hardwarestrukturen dar.
In Bezug auf Zeitbedingungen ermöglichen StateCharts nur die Angabe von
Timeouts. Es gibt keine weitere direkte Möglichkeit, andere Zeitbedingungen anzugeben.
UML beinhaltet eine Version von StateCharts und erlaubt damit die Modellierung
endlicher Automaten. UML Version 1 nennt diese state diagrams, während sie ab
UML 2.0 state machine diagrams genannt werden. Leider unterscheidet sich die
Semantik der UML-Diagramme von StateMate, da UML die drei beschriebenen
Simulationsphasen nicht vorgibt.
2.4.3 Synchrone Sprachen
Motivation
Es ist schwierig, komplexe Systeme mit Hilfe endlicher Automaten zu beschreiben, da diese keine komplexen Berechnungen enthalten. Standard-Programmiersprachen dagegen können komplexe Berechnungen beschreiben, garantieren dafür aber
meist nicht die Ausführungsreihenfolge mehrerer Threads. In einer Multi-ThreadedUmgebung mit präemptivem (d.h. verdrängendem) Scheduling sind viele verschiedene Ablaufreihenfolgen der einzelnen Berechnungen möglich. Es ist schwer, alle
möglichen Abläufe in einem solchen nebenläufigen System zu verstehen. Einer der
Hauptgründe dafür ist, dass im Allgemeinen mehrere verschiedene Ausführungsreihenfolgen möglich sind, die Reihenfolge der Ausführung ist also nicht festgelegt.
Allerdings kann diese Reihenfolge durchaus das Ergebnis beeinflussen. Das sich
daraus ergebende nichtdeterministische Verhalten kann eine Reihe von Problemen
zur Folge haben, wie z.B. das Problem, einen bestimmten Entwurf zu verifizieren.
Bei verteilten Systemen mit unabhängigen Uhren ist deterministisches Verhalten nur
schwer realisierbar. Bei nicht verteilten Systemen können wir aber versuchen, die
Probleme einer unnötig nichtdeterministischen Semantik zu vermeiden.
Synchrone Sprachen verbinden endliche Automaten und Programmiersprachen zu
einem Modell. Sie können komplexe Berechnungen beschreiben, folgen aber dem zu
Grunde liegenden Ausführungsmodell endlicher Automaten. Dabei beschreiben sie
nebenläufig arbeitende Automaten. Deterministisches Verhalten wird durch die folgende wichtige Eigenschaft erreicht: „wenn Automaten parallel kombiniert werden,
dann besteht eine Transition des zusammengesetzten Automaten aus der ‚gleichzeitigen‘ Transition aller einzelnen Automaten” [198]. Das bedeutet, dass man nicht
alle möglichen Abfolgen von Zustandsübergängen aller Automaten betrachten muss,
wie dies bei unabhängigen Takten in den Unterautomaten der Fall wäre. Stattdessen kann man die Existenz eines einzigen globalen Taktes annehmen. Bei jedem
Taktsignal werden alle Eingaben berücksichtigt, neue Ausgaben und Zustände wer-