Objektorientierte Daten- und Zeitmodelle für die Echtzeit ...

6.4. KONTROLLFLUSS IN FUNKTIONALEN DATENNETZEN 119
Eine Alternative dazu, die ohne die genaue Kenntnis der zu aktualisierenden Sequenzen auskommt,
kann mit Hilfe einer modulweiten Liste ermöglicht werden, in die die Objekt bestimmte
ihrer Aktionen wie z.B. den Aufruf der ÐÐ -Methode eines Funktors eintragen, sobald diese
im Zyklus zum ersten Mal durchgeführt wird. Für Aktionen, die erfolgreich abgeschlossen
wurden, löscht das Objekt den entsprechenden Eintrag wieder aus der Liste. Einträge, die bis
zum Ende des Zyklus nicht aus der Liste gelöscht wurden, zeigen direkt die Unerreichbarkeit
von Daten oder Funktoren an.
Testzyklen mit überwachendem Agenten: Lokale und die zuletzt genannten agentenbasierten
Verfahren scheitern, wenn ein Konflikt zu einer Verklemmung führt, da in diesem Fall
der Zyklus zu keinem Ende kommt. Besteht diese Gefahr, was insbesondere bei asynchronen
Steuerungsmechanismen der Fall ist, sollte nach jeder Änderung des Netzdesigns ein spezieller
Analysezyklus durchlaufen werden, der von einem Agenten angestoßen und anschließend
ausgewertet werden kann. Hierbei können alle Daten- und Funktionsobjekte ihre jeweiligen
Aktionen in eine Liste eintragen. Darüber hinaus besteht die Möglichkeit, daß Funktoren ihre
Ó -Methode überspringen, wodurch die Laufzeit eines Testlaufs allein durch die Verwaltungsoperationen
bestimmt wird und damit sehr kurz und gut abschätzbar ist. Nach Beendigung des
Zyklus oder nach einer festen Zeitspanne analysiert der Agent die Liste, wodurch leicht festzustellen
ist, ob alle Funktoren aufgerufen und auch wieder ordnungsgemäß beendet wurden.
Auf die Aktionsliste und die anschließende agentenbasierte Auswertung des Analysezyklus
kann verzichtet werden, wenn der gesamte Testzyklus in einem ungeteilten Kontrollfluß
ausgeführt wird. Wie die folgenden Abschnitte zeigen werden, läßt sich in diesem Fall jede
potentielle Verklemmung lokal erkennen.
Voraussetzung für diese Verfahren ist zum einen die Mitwirkung der Funktoren und Datensequenzen,
die den Datenflußgraphen bilden, zum anderen ein Objekt, das in der Lage ist,
die während eines regulären oder Testzyklus angesammelten Informationen auszuwerten. Beides
ist, da als dynamische Elemente des Graphen nur Datensequenzen und Funktoren in Frage
kommen, mit relativ geringem Aufwand möglich, und soll daher — wenn lokale Verfahren nicht
greifen — als Lösung präferiert werden.
Das Potential möglicher Konflikte hängt nicht nur vom Netzdesign sondern auch wesentlich
von der Art der Programm- bzw. Modulsteuerung ab. So führen mehrere, parallel arbeitende
Kontrollflüsse, die sich asynchron im Netz ausbreiten, leichter zu Konflikten, die dazu schwerer
zu erkennen sind, als eine Steuerung, die synchron in nur einem Kontrollfluß erfolgt. Dieser
Punkt wird in den folgenden Abschnitten im Rahmen der Verwendung asynchroner Relationen
genauer untersucht werden.
Neben der Beschreibung und einem Vergleich der Ablaufmechanismen und Kontrollflüsse
unter den verschiedenen Steuerungskonzepten sollen in den folgenden Abschnitten weitere
Designentscheidungen für den objektorientierten Entwurf der beteiligten Daten- und Funktionsobjekte
und deren Realisierung in Software abgeleitet werden.
6.4.6 Asynchrone Steuerungskonzepte
Eine Stärke funktionaler Programmbeschreibungen ist, daß sie auf natürliche Art und Weise
die potentiellen Nebenläufigkeiten der durch sie repräsentierten Aufgaben ausdrücken können.
Damit dieser Vorteil bei der Realisierung des funktionalen Datenflußgraphen in einem Compu-