2.4 Kommunizierende endliche Automaten
65
kann. In einem solchen Fall möchten wir explizit angeben können, dass diese Entscheidung zur Laufzeit stattfinden wird (vergleiche die seeect-Anweisung von Ada
auf Seite 124).
Andere Implementierungen hierarchischer StateCharts zeigen meist nicht dieses von StateMate realisierte deterministische Verhalten. Diese Implementierungen
entsprechen einer Softwaresicht hierarchischer StateCharts. In solchen Implementierungen werden Wahlmöglichkeiten meist nicht explizit beschrieben.
Bewertung und Erweiterungen
Implizit geht StateCharts gemäß StateMate-Semantik also von einem BroadcastMechanismus zum Aktualisieren von Variablenwerten aus. Dadurch lassen sich
StateCharts oder StateMate-Modelle leicht auf shared memory-Systemen implementieren, eignen sich aber weniger für verteilte und nachrichtenbasierte Systeme.
Somit setzen Sprachen wie StateCharts implizit die shared memory-Semantik voraus, auch wenn dies nicht explizit festgelegt wird. Bei verteilten Systemen ist es sehr
schwierig, alle Variablenwerte zwischen zwei Schritten zu aktualisieren. Aufgrund
dieses Broadcast-Mechanismus sind StateCharts mit der beschriebenen Semantik
nicht geeignet, um verteilte Systeme zu beschreiben. Das Hauptanwendungsgebiet
von StateCharts sind daher lokale Systeme, die hauptsächlich Steuerungsaufgaben
durchführen. Die Möglichkeit, Hierarchieebenen beliebig zu verschachteln und mit
frei wählbaren UND- und ODER-Superzuständen zu versehen, ist der Hauptvorteil von StateCharts. Ein weiterer Vorteil ist die ausreichend präzise Definition der
Semantik von StateCharts [141] gemäß StateMate-Implementierung. Außerdem ist
eine Vielzahl von kommerziellen Programmen erhältlich, die StateCharts verwenden. StateMate [230] und StateFlow [383] sind Beispiele für solche kommerziellen
Anwendungen. Viele dieser Programme sind in der Lage, aus StateCharts-Modellen
äquivalente Beschreibungen in C oder VHDL (siehe Seite 109) zu erzeugen. Aus
VHDL kann mit Hilfe von Synthesewerkzeugen direkt Hardware erzeugt werden.
Aus diesem Grund bieten Programme, die auf StateCharts basieren, einen vollständigen Entwurfspfad von der StateCharts-Beschreibung bis zur fertigen Hardware.
Generierte C-Programme können übersetzt und ausgeführt werden, was auch Softwarerealisierungen ermöglicht.
Leider ist die Effizienz dieser automatisch erzeugten Realisierungen häufig ein
Problem. So könnten in einer automatisch erzeugten Software etwa Unterzustände
von UND-Superzuständen auf Unix-Prozesse abgebildet werden. Dieses Konzept ist
für die Simulation von StateCharts geeignet, nicht jedoch für eine effiziente Realisierung auf kleinen, leistungsschwachen Prozessoren. Der Produktivitätsgewinn durch
objektorientierte Programmierung kann mit StateCharts nicht ausgeschöpft werden,
da Objektorientierung nicht unterstützt wird. Außerdem ist es durch den BroadcastMechanismus kaum für verteilte Anwendungen geeignet. StateCharts unterstützen
keine Programmiersprachenkonstrukte, um komplexe Berechnungsvorschriften zu
realisieren. Außerdem können sie keine Hardwarestrukturen oder nicht-funktionales
Verhalten beschreiben.
65
kann. In einem solchen Fall möchten wir explizit angeben können, dass diese Entscheidung zur Laufzeit stattfinden wird (vergleiche die seeect-Anweisung von Ada
auf Seite 124).
Andere Implementierungen hierarchischer StateCharts zeigen meist nicht dieses von StateMate realisierte deterministische Verhalten. Diese Implementierungen
entsprechen einer Softwaresicht hierarchischer StateCharts. In solchen Implementierungen werden Wahlmöglichkeiten meist nicht explizit beschrieben.
Bewertung und Erweiterungen
Implizit geht StateCharts gemäß StateMate-Semantik also von einem BroadcastMechanismus zum Aktualisieren von Variablenwerten aus. Dadurch lassen sich
StateCharts oder StateMate-Modelle leicht auf shared memory-Systemen implementieren, eignen sich aber weniger für verteilte und nachrichtenbasierte Systeme.
Somit setzen Sprachen wie StateCharts implizit die shared memory-Semantik voraus, auch wenn dies nicht explizit festgelegt wird. Bei verteilten Systemen ist es sehr
schwierig, alle Variablenwerte zwischen zwei Schritten zu aktualisieren. Aufgrund
dieses Broadcast-Mechanismus sind StateCharts mit der beschriebenen Semantik
nicht geeignet, um verteilte Systeme zu beschreiben. Das Hauptanwendungsgebiet
von StateCharts sind daher lokale Systeme, die hauptsächlich Steuerungsaufgaben
durchführen. Die Möglichkeit, Hierarchieebenen beliebig zu verschachteln und mit
frei wählbaren UND- und ODER-Superzuständen zu versehen, ist der Hauptvorteil von StateCharts. Ein weiterer Vorteil ist die ausreichend präzise Definition der
Semantik von StateCharts [141] gemäß StateMate-Implementierung. Außerdem ist
eine Vielzahl von kommerziellen Programmen erhältlich, die StateCharts verwenden. StateMate [230] und StateFlow [383] sind Beispiele für solche kommerziellen
Anwendungen. Viele dieser Programme sind in der Lage, aus StateCharts-Modellen
äquivalente Beschreibungen in C oder VHDL (siehe Seite 109) zu erzeugen. Aus
VHDL kann mit Hilfe von Synthesewerkzeugen direkt Hardware erzeugt werden.
Aus diesem Grund bieten Programme, die auf StateCharts basieren, einen vollständigen Entwurfspfad von der StateCharts-Beschreibung bis zur fertigen Hardware.
Generierte C-Programme können übersetzt und ausgeführt werden, was auch Softwarerealisierungen ermöglicht.
Leider ist die Effizienz dieser automatisch erzeugten Realisierungen häufig ein
Problem. So könnten in einer automatisch erzeugten Software etwa Unterzustände
von UND-Superzuständen auf Unix-Prozesse abgebildet werden. Dieses Konzept ist
für die Simulation von StateCharts geeignet, nicht jedoch für eine effiziente Realisierung auf kleinen, leistungsschwachen Prozessoren. Der Produktivitätsgewinn durch
objektorientierte Programmierung kann mit StateCharts nicht ausgeschöpft werden,
da Objektorientierung nicht unterstützt wird. Außerdem ist es durch den BroadcastMechanismus kaum für verteilte Anwendungen geeignet. StateCharts unterstützen
keine Programmiersprachenkonstrukte, um komplexe Berechnungsvorschriften zu
realisieren. Außerdem können sie keine Hardwarestrukturen oder nicht-funktionales
Verhalten beschreiben.