DE60113538T2

DE60113538T2 - Verfahren ausgeführt durch einen software-tool für die identifikation von abhängigkeitskonflikten in einem softwaresystem

Info

Publication number: DE60113538T2
Application number: DE60113538T
Authority: DE
Inventors: J. Kenneth HINES
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2000-06-23
Filing date: 2001-06-22
Publication date: 2006-06-22
Anticipated expiration: 2021-06-23
Also published as: AU2001270094A1; WO2002001362A3; US20030028858A1; US20020174415A1; WO2002001349A3; US20020062463A1; US20020059558A1; AU2001271354A1; WO2002001390A2; EP1297428A2; US20030005407A1; DE60113538D1; WO2002001349A2; EP1297424B1; WO2002001362A2; WO2002001359A2; WO2002001359A3; EP1323042A2; ATE305153T1; AU2001270079A1

Description

Verwandte Anmeldungen
Diese Anmeldung beansprucht die Priorität der vorläufigen US Anmeldung Nr. 60/213.496 vom 23. Juni 2000.
Technisches Gebiet
Die vorliegende Offenbarung bezieht sich auf eine statische Fehlerprüfung von Softwaresystemen, die zur Ausführung in einer Hardware-Architektur mit mehreren Verarbeitungsressourcen verwendet werden kann.
Hintergrund der Erfindung
Eine Systemdesign- und Programmiermethodologie ist am wirksamsten, wenn sie eng mit ihren Fehlersuchtechniken integriert und eng in diese eingebunden ist. In verteilten und eingebetteten Systemmethodologien lag jedoch von jeher der Schwerpunkt der Beziehung zwischen Fehlersuchansätzen und Design-Methodologien einseitig auf der Seite der Design- und Programmiermethodologien. Design- und Programmiermethodologien werden typischerweise ohne jede Berücksichtigung der Fehlersuchtechniken entwickelt, die später auf Softwaresysteme, die unter Einsatz dieser Design- und Programmiermethodologie konzipiert sind, angewandt werden. Obwohl diese typischen Fehlersuchansätze versuchen, Merkmale der Design- und Programmiermethodologien auszunutzen, haben die Fehlersuchtechniken normalerweise wenig oder gar keinen Einfluß auf das eigentliche Wesen der Design- und Programmiermerkmale. Dieser Mangel an Einfluß seitens der Fehlersuchansätze auf die Design- und Programmiermethodologien führt dazu, daß die Rolle der Fehlersuche weiterhin als etwas Nachträgliches betrachtet wird, obwohl in einem typischen Systemdesign der Hauptanteil der Designzeit mit Fehlersuche verbracht wird. Es ist daher weiterhin eine Design- und Programmiermethodologie notwendig, die die Eingabe möglicher Fehlersuchansätze und deren Berücksichtigung reflektiert, um das Design von Softwaresystemen zu verbessern und deren Implementierungszeit zu reduzieren.
Statische Analyse kann von großem Vorteil für die Fehlersuche in komplizierten Systemen sein. Eine tradionelle Laufzeit-Fehlersuche ist notwendig, weil bestimmte Softwarefehler erst nach der Kompilierung entdeckt werden und sich als Ausführungsfehler bemerkbar machen. Eine statische Analyse kann die Anzahl solcher Fehler reduzieren und Designern helfen, subtile Designwechselwirkungen hervorzuheben.
In „Model Checking Large Software Specifications", R. J. Anderson et al., Software Engineering Notes, Vol. 21, pp. 156–166 (1996) wird ein Modellprüfungstool zum Untersuchen der Spezifikation eines Softwaresystems beschrieben. Die Softwarespezifikation wird als erstes in einen für das Modellprüfungstool geeigneten „Input" übersetzt. Dann werden der Input und die zu prüfende Eigenschaft aufgrund von geordneten binären Entscheidungsdiagrammen in Darstellungen umgewandelt, die daraufhin an den Modellprüfungs-Algorithmus weitergeleitet werden. Der resultierende „Output" des Algorithmus gibt an, ob die Eigenschaft wahr oder falsch ist.
Zusammenfassung
Die vorliegende Erfindung stellt ein Verfahren bereit, welches von einem Softwareanalysetool zum Identifizieren von Beschränkungsdurchsetzungskonflikten in einem Softwaresystem durchgeführt wird, welches wenigstens zwei Softwareelemente und wenigstens eine Beschränkung umfaßt, wobei jedes Softwareelement wenigstens eine Betriebsart umfaßt, die, wenn sie aktiviert ist, es einer oder mehreren Handlungen ermöglicht, durch ein Ereignis auslösbar zu sein, und wobei jede Beschränkung, wenn sie durchgesetzt ist, einen Output erzeugt, der den Aktivierungszustand von wenigstens einer Betriebsart beeinflußt, wobei das Verfahren umfaßt:
Erzeugen eines Disjunktionsknotens für jede Betriebsart;
Erzeugen eines Konjunktionsknotens für jede Beschränkung;
Erzeugen einer gerichteten Kante für jede Beschränkung, die einen Output erzeugt, von dem entsprechenden Konjunktionsknoten zu dem Disjunktionsknoten jeder Betriebsart, deren Aktivierungszustand von dem Output beeinflußt ist, wobei jede gerichtete Kante einen Wert auf dem Disjunktionsknoten geltend macht, welcher auf den Einfluß schließen läßt, der von der Beschränkung auf den Aktivierungszustand ausgeübt wird; und
Darstellen von Kontrollwechselwirkungen zwischen den Softwareelementen in einem statischen Kontrollgraph, welcher umfaßt:
eine erste Gruppe graphischer Symbole, wobei jedes Symbol einen Konjunktionsknoten darstellt;
eine zweite Gruppe graphischer Symbole, wobei jedes Symbol einen Disjunktionsknoten darstellt; und
eine dritte Gruppe graphischer Symbole, wobei jedes Symbol eine gerichtete Kante darstellt und visuelle Merkmale eines Ursprungsknotens und eines Zielknotens umfaßt,
wobei ein Beschränkungsdurchsetzungskonflikt als ein Disjunktionsknoten identifiziert ist, der zwei oder mehrere einfallende gerichtete Kanten aufweist, die verschiedene Werte geltend machen.
Die vorliegende Erfindung beschreibt eine Datenstruktur und ein Verfahren zur Darstellung der statischen Aspekte eines Softwaresystems und zur Identifizierung von Kontrollbeschränkungskonflikten im System. Die hier dargestellten Techniken können in Designtools zum Einsatz in einem koordinationszentrischen Rahmen (coordination-centric framework) eingesetzt werden. Jede Technik kann Fehler vor der Ausführung beseitigen.
Systemweite Kontrollaspekte eines Softwaresystems können graphisch durch einen statischen Kontrollgraphen (SCG) dargestellt werden. Ein einfacher SCG weist typisch folgende Merkmale auf: Konjunktionsknoten, die jeweils eine Kontrollbeschränkung darstellen; Disjunktionsknoten, die jeweils eine Betriebsart innerhalb einer Komponente darstellen; und gerichtete Kanten, die jeweils Implikation zwischen einem Paar von Knoten darstellen. Der Graph abstrahiert die Kontrollbeschränkungen eines Softwaresystems zu Kanten und Konjunktionsknoten. Ein Konjunktionsknoten erbringt nur dann Ergebnisse, wenn alle Kanten zufriedengestellt sind, während ein Disjunktionsknoten Ergebnisse erbringt, wenn eine Kante zufriedengestellt ist. Eine Kante, in einem SCG, ist entweder aktiviert oder deaktiviert und spricht auf entweder einen falschen Wert oder einen wahren Wert an ihrem hinteren Ende an und erzwingt entweder einen falschen Wert oder einen wahren Wert an ihrem vorderen Ende.
Ein typischer Einsatz eines SCG besteht im Identifizieren von Beschränkungskonflikten, in denen zwei aktive Beschränkungen versuchen, einen Disjunktionsknoten in entgegengesetzte Richtungen zu zwingen. SCGs verfolgen die Wirkungen von individuellen Betriebsartzuständen auf allen anderen Betriebsarten in einem Softwaresystem. Durch Beschränkungen kann der Zustand einer individuellen Betriebsart verursachen, daß andere Betriebsarten im System bestimmte Zustände annehmen. Die Änderungen im Kontrollzustand können einen Kaskadeneffekt auf andere Teile des Systems haben. Typisch kann eine individuelle Betriebsart den Zustand anderer Betriebsarten beeinflussen, mit denen sie keine direkte Verbindung hat. Die kompletten, Ende-Ende-Auswirkungen einer Zustandsänderung für eine bestimmte Betriebsart können durch „Glätten" des SCG berechnet werden. Diese „Glättungstechnik" erzeugt eine Pseudobeschränkung zwischen zwei Knoten, die die Gesamtwirkung von überlappenden Zustandsänderungen zwischen zwei Knoten darstellt und die Instabilität im System hervorhebt.
Eine als „Kontrollkonflikt-Identifizierung und Eliminierung" bezeichnete Technik identifiziert den Satz der Betriebsartzustände, die einen Kontrollkonflikt verursachen, und ändert die Beschränkungen, um den Konflikt zu entfernen. Das Identifizieren des für den Konflikt verantwortlichen Betriebsartzustandes erfolgt dadurch, daß man die möglicherweise konfliktierenden Kanten, die durch die „Glättungstechnik" identifiziert werden, rückwärts vom Konfliktknoten zu den unmittelbar vorausgehenden Konjunktionsknoten verfolgt und bestimmt, ob eine Betriebsartkonfiguration vorhanden ist, die das Auftreten des Konfliktes zuläßt.
Dynamische Kontrollgraphen (DCGs) eignen sich für eine breitere Vielfalt von dynamischen Prüfungen und auch für Betriebsartprüfungen. Modellprüfung ermöglicht noch viele andere Systemprüfungen, wie zum Beispiel Konfigurationserreichbarkeit. Um Betriebsartprüfung auf DCGs anwenden zu können, ist es zunächst erforderlich, eine Übergangsbeziehung abzuleiten und als binäres Entscheidungsdiagramm (BDD) darzustellen. Die Größe von BDDs ist empfindlich gegen das Ordnen von Variablen, aber die Struktur von DCGs ermöglicht das Ordnen von Heuristiken, was typisch BDDs einer vernünftigen Größe ergibt.
Statistische Analyse wird nicht nur dazu verwendet, Fehler oder Unstimmigkeiten in einem System zu finden, sondern auch, um ein Programm zu optimieren. Dies ist ein typischer Einsatz von Kontrolldatenflußgraphen (CDGs). Bei Einsatz von CDGs kann ein wirksamer statischer Plan für alle modalen Datenflußregionen eines koordinationszentrischen Softwaresystems abggeleitet werden, die konstante Produktions- und Verbrauchsraten haben.
Weitere Aspekte und Vorteile dieser Erfindung ergeben sich aus der folgenden ausführlichen Beschreibung der bevorzugten Ausführungsformen, in der auf die beigefügten Zeichnungen Bezug genommen wird.
Kurze Beschreibung der Zeichnungen
1 ist eine Komponente gemäß der vorliegenden Offenbarung.
2 ist eine Komponente aus 1, die des weiteren einen Satz von Koordinationsschnittstellen aufweist.
3A ist ein „Round-Robin" Ressourcen-Zuweisungsprotokoll nach dem Stand der Technik mit einem zentralisierten Controller.
3B ist ein „Round-Robin" Ressourcen-Zuweisungsprotokoll nach dem Stand der Technik, welches ein Toking-Passing-System implementiert.
4A ist eine detaillierte Ansicht einer Komponente und einer an die Komponente angeschlossenen Koordinationsschnittstelle zum Einsatz in Round-Robin-Ressourcenzuweisung gemäß der vorliegenden Offenbarung.
4B veranschaulicht einen „Round-Robin" Koordinator gemäß der vorliegenden Offenbarung.
5 veranschaulicht mehrere typische Ports zum Einsatz in einer Koordinationsschnittstelle gemäß der vorliegenden Offenbarung.
6A ist ein unidirektionaler Datenübertragungskoordinator gemäß der vorliegenden Offenbarung.
6B ist ein bidirektionaler Datenübertragungskoordinator gemäß der vorliegenden Offenbarung.
6C ist ein Zustandsvereinigungs-Koordinator gemäß der vorliegenden Offenbarung.
6D ist ein Kontrollzustands-Mutex-Koordinator gemäß der vorliegenden Offenbarung.
7 ist ein System zur Implementierung von Subsumptions-Ressourcenzuweisung mit Komponenten, einer gemeinsam genutzten Ressource und einem Subsumptions-Koordinator.
8 ist ein Barrieren-Synchronisierungskoordinator gemäß der vorliegenden Offenbarung.
9 ist ein Rendezvous Koordinator gemäß der vorliegenden Offenbarung.
10 veranschaulicht ein dediziertes RPC-System mit einem Client, einem Server und einem dedizierten RPC-Koordinator, der die Aktivitäten des Client und des Servers koordiniert.
11 ist ein zusammengesetzter Koordinator mit sowohl preemptiver als auch Round-Robin-Koordination zum Kontrolle des Zugriffs eines Satzes von Komponenten auf eine gemein genutzte Ressource.
12A ist ein Softwaresystem mit zwei Datenübertragungskoordinatoren, die jeweils konstante Meldungsverbrauchs- und Erzeugungsregeln aufweisen, und die jeweils mit einer separaten Datenerzeugungskomponente und mit der gleichen Datenempfangskomponente verbunden sind.
12B ist ein Softwaresystem nach 12A, in welchem die beiden Datenübertragungskoordinatoren durch einen zusammengelegten Datenübertragungskoordinator ersetzt wurden.
13 ist ein System, welches ein „First-Come, First-Served" Ressourcenzuweisungsprotokoll (FCFS) gemäß der vorliegenden Offenbarung implementiert.
14 ist ein System, welches ein Multiclient RPC Koordinationsprotokoll implementiert, welches durch Kombinieren des „First-Come, First-Served" Protokolls von 13 mit dem dedizierten RPC-Koordinator von 10 gebildet ist.
15 veranschaulicht ein großes System, in dem die koordinationszentrische Design-Methodologie mit einem mit einem Funktelefonnetz zusammenwirkenden drahtlosen Gerät eingesetzt werden kann.
16 veranschaulicht eine Top-Level-Ansicht des Verhaltens und der Komponenten für ein System mit einem Handy.
17A zeigt eine detaillierte Ansicht einer GUI-Komponente des Handys von 16.
17B ist eine detaillierte Ansicht einer Anrufprotokollierungs-Komponente des Handys von 16.
18A ist eine detaillierte Ansicht einer Voice-Subsystem-Komponente des Handys von 16.
18B ist eine detaillierte Ansicht einer Verbindungskomponente des Handys von 16.
19 veranschaulicht die Koordinationsschichten zwischen einem drahtlosen Gerät und einer Basisstation, und zwischen der Basisstation und einer Vermittlungszentrale von 15.
20 veranschaulicht eine Handy-Anrufmanagementkomponente, eine Hauptvermittlungszentralen-Anrufmanagementkomponente und einen Anrufmanagementkoordinator, der die entsprechenden Anrufmanagementkomponenten miteinander verbindet.
21A ist eine detaillierte Ansicht einer Transportkomponente der Verbindungskomponente von 18B.
21B ist ein CDMA-Datenmodulator der Transportkomponente von 18A.
22 ist eine detaillierte Ansicht eines typischen TDMA und eines typischen CDMA-Signals für das Handy von 16.
23 ist eine LCD-Touchscreen-Komponente für einen Webbrowser GUI für ein drahtloses Gerät.
23B ist eine Webseitenformatierungskomponente für den Webbrowser GUI für das drahtlose Gerät.
24A ist ein vollständiges GUI System für einen Handheld-Webbrowser.
24B ist das GUI-System für den Handheld-Webbrowser, der zum Zugriff auf das Funknetzwerk von 15 mit dem Verbindungssubsystem von 18B kombiniert ist.
25 ist ein typisches Raum-/Zeitdiagramm, in dem der Raum auf einer vertikalen Achse und die Zeit auf einer horizontalen Achse dargestellt ist.
26 ist ein Raum-/Zeitdiagramm, welches einen Satz von Systemereignissen und zwei verschiedene Beobachtungen dieser Systemereignisse veranschaulicht.
27 ist ein Raum-/Zeitdiagramm, welches einen Satz von Systemereignissen und eine ideale Beobachtung der von einem Echtzeitbeobachter aufgenommenen Ereignisse veranschaulicht.
28 ist ein Raum-/Zeitdiagramm, welches zwei verschiedene aber gültige Beobachtungen einer Systemausführung veranschaulicht.
29 ist ein Raum-/Zeitdiagramm, welches eine Systemausführung und eine von einem diskreten Lamport-Beobachter aufgenommene Beobachtung dieser Ausführung veranschaulicht.
30 ist ein Raum-/Zeitdiagramm, welches einen Satz von Ereignissen veranschaulicht, die jeweils einen Lamport-Zeitstempel enthalten.
31 ist ein Raum-/Zeitdiagramm, welches die Unzulänglichkeit von skalaren Zeitstempeln veranschaulicht, um die Kausalität zwischen Ereignissen zu kennzeichnen.
32 ist ein Raum-/Zeitdiagramm, welches einen Satz von Systemereignissen veranschaulicht, die jeweils einen Vektor-Zeitstempel enthalten.
33 veranschaulicht ein Display eines POET (Partial Order Event Tracer).
34 ist ein Raum-/Zeitdiagramm, welches zwei zusammengesetzte Ereignisse veranschaulicht, die weder kausal noch gleichzeitig sind.
35 ist ein POET-Display von zwei konvexen Ereignis-Clustern.
36 ist eine BEE-Abstraktionseinrichtung (BEE = Basis for Distributed Event Environments) für einen einzelnen Client.
37 ist eine hierarchische Baumkonstruktion von Prozeß-Clustern.
38A veranschaulicht eine qualitative Kohäsions- und Kopplungsmaßnahme zwischen einem Satz von Prozeß-Clustern, die starken Verkehr aufweisen oder anhand des gleichen Quellencodes erzeugt wurden.
38B veranschaulicht eine qualitative Kohäsions- und Kopplungsmaßnahme zwischen einem Satz von Prozeß-Clustern, die keinen starken Verkehr aufweisen oder nicht Instanzen des gleichen Quellencodes sind.
38C veranschaulicht eine qualitative Kohäsions- und Kopplungsmaßnahme zwischen einem anderen Satz von Prozeß-Clustern, die starken Verkehr aufweisen oder anhand des gleichen Quellencodes erzeugt wurden.
39 veranschaulicht einen konsistenten und einen inkonsistenten Schnitt einer Systemausführung auf einem Raum-/Zeitdiagramm.
40A ist ein Raum-/Zeitdiagramm, welches eine Systemausführung veranschaulicht.
40B ist ein Gitter, welches alle möglichen konsistenten Schnitte eines Raum-/Zeitdiagramms von 40A darstellt.
40C ist eine graphische Darstellung der möglichen konsistenten Schnitte von 40B.
41A ist ein Raum-/Zeitdiagramm, welches eine Systemausführung veranschaulicht.
41B ist ein Raum-/Zeitdiagramm von 41A nach Durchführung eines Global Step.
41C ist ein Raum-/Zeitdiagramm von 41A nach Durchführung eines Step-Over.
41D ist ein Raum-/Zeitdiagramm von 41A nach Durchführung eines Step-In.
42 ist ein Raum-/Zeitdiagramm, welches ein System veranschaulicht, welches immer dann einem Domino-Effekt unterliegt, wenn das System zeitlich bis zu einem Prüfpunkt zurückgerollt wird.
43 veranschaulicht einen einfachen statischen Kontrollgraph gemäß der vorliegenden Offenbarung.
44A ist eine Kante, welche den an ihrem vorderen Ende wahren Wert geltend macht und auf den an ihrem hinteren Ende wahren Wert anspricht.
44B ist, eine Kante, welche den an ihrem vorderen Ende wahren Wert geltend macht und auf den an ihrem hinteren Ende falschen Wert anspricht.
44C ist eine Kante, welche den an ihrem vorderen Ende falschen Wert geltend macht und auf den an ihrem hinteren Ende wahren Wert anspricht.
44D ist eine Kante, welche den an ihrem vorderen Ende falschen Wert geltend macht und auf den an ihrem hinteren Ende falschen Wert anspricht.
45 ist eine Veranschaulichung der semantischen Unterschiede zwischen boolschen Netzwerken und statischen Kontrollgraphen.
46A zeigt einen grundlegenden Kontrollgraph mit reduzierten charakteristischen Funktionen.
46B zeigt einen grundlegenden Kontrollgraph mit reduzierten charakteristischen Funktionen.
47A zeigt die Auswirkung auf die Kantensemantiken auf SCG-Sementiken, wenn eine Durchsetzungskante einen an ihrem vorderen Ende falschen Wert geltend macht.
47B zeigt die Auswirkung von Kantensemantiken auf SCG-Semantiken, wenn eine Durchsetzungskante einen an ihrem hinteren Ende falschen Wert geltend macht.
47C zeigt die Auswirkung von Kantensemantiken auf SCG-Semantiken, wenn eine Überwachungskante einen an ihrem vorderen Ende falschen Wert geltend macht.
47D zeigt die Auswirkung von Kantensemantiken auf SCG-Semantiken, wenn eine Überwachungskante einen an ihrem hinteren Ende falschen Wert geltend macht.
48A veranschaulicht einen Koordinator für eine Rendezvous-artige Koordination.
48B veranschaulicht einen statischen Kontrollgraph, der einen Koordinator für eine Rendezvous-artige Koordination darstellt.
49 ist ein statischer Kontrollgraph ohne stabile oder nicht-konfliktierende Zustände.
50A ist der statische Kontrollgraph, der die Reduzierung von 3-SAT auf ASSP (Any Stable State Property) darstellt.
50B ist eine äquivalente logische Darstellung eines statischen Kontrollgraphen, der die Reduzierung von 3-SAT auf ASSP (Any Stable State Property) darstellt.
51A ist ein statischer Kontrollgraph, der einen Konflikt erster Ordnung darstellt.
51B ist ein statischer Kontrollgraph, der einen Konflikt zweiter Ordnung darstellt.
52A ist ein statischer Kontrollgraph, der einen Disjunktionsknoten (di) vor der „Glättung" darstellt.
52B ist ein statischer Kontrollgraph, der einen Disjunktionsknoten (di) nach der „Glättung" darstellt.
53 52A ist ein statischer Kontrollgraph, der einen potentiellen Konflikt, hervorgehoben durch „Glättung", darstellt.
54 ist ein statischer Kontrollgraph für 49, nach der „Glättung".
55A zeigt einen inneren Kontrollgraph einer Komponente.
55B zeigt den statischen Kontrollgraph einer Komponente, nachdem die internen Knoten zu einem einzigen unabhängigen Knoten summiert wurden.
56 zeigt eine ideale Struktur zur Anwendung von hierarchischer Reduktion, um die Instabilität eines Systems hervorzuheben.
57 veranschaulicht einen dynamischen Kontrollgraph (DCG).
58 veranschaulicht einen DCG mit einem Handlungsknoten.
59 zeigt einen DCG mit einem Handlungsknoten für eine Handlung, die bezüglich Kontrollwechselwirkungen transparent ist.
60 zeigt einen DCG mit einem Handlungsknoten für eine Handlung, die bezüglich Kontrollwechselwirkungen opak ist.
61A zeigt einen DCG für einen Rendezvous-Koordinator.
61A zeigt einen DCG für einen Rendezvous-Koordinator mit „Zwei-Teilnehmer-Preemption".
62A zeigt einen Kommunikationskanal zwischen Partitionen eines statischen Kontrollgraph (SCG), die eine Nur-Handlungs-Barriere verursachen können.
62B zeigt einen DCG entsprechend dem SCG von 62A nach Partition auf der Nur-Zugriffs-Barriere.
63 veranschaulicht die Nur-Handlungs-Barriere schneidende Beschränkungskanten von 62A und ihre entsprechenden Vorlagen.
64 veranschaulicht einen aktuellen DCG zusammen mit einem nächsten DCG – das Ergebnis des temporalen Entrollens von DCG.
65A veranschaulicht einen einfachen DCG.
65B veranschaulicht einen entrollten DCG für einen einfachen DCG.
66A zeigt eine Wahrheitstabelle für eine boolsche „und" Funktion.
66B zeigt einen Wahrheitsbaum, der der Wahrheitstabelle in 66A entspricht.
67A zeigt ein reduziertes binäres Entscheidungsdiagramm (BDD) für den Wahrheitsbaum in 66B.
67B zeigt ein anderes reduziertes BDD für den Wahrheitsbaum in 66B.
67C zeigt ein drittes anderes reduziertes BDD für den Wahrheitsbaum in 66B.
68 zeigt die Ergebnisse beim Einsatz des Anwendungsalgorithmus zur Erstellung eines BDDs, das die charakteristische Funktion des entrollten DCG aus 65B darstellt.
69A zeigt den entrollten DCG für den Rendezvous-DCG von 61A.
69B zeigt, daß ein kritischer Reihenfolgefaktor für die charakteristische Funktion des entrollten DCG von 69A die relative Reihenfolge von waitc, waitb und waita ist.
70A, B, C und D zeigen, daß Verschachteln von asynchronen Modellen kein ausreichendes Fehlerprüfungstool für koordinationszentrische Systemdesigns ist.
71 zeigt einen Kontroll-/Datenflußgraph (CDG).
72 zeigt eine CDG-Darstellung eines RPC-Systems.
73A zeigt den zweiten Schritt im Partitionieren eines CDG auf einer Nur-Handlungs-Barriere.
73B zeigt den DCG-Graph von 62B, wobei die Nur-Handlungs-Barriere in eine Nur-Meldungs-Barriere umgewandelt wurde.
74A zeigt einen CDG mit einem Satz von Meldungsratengarantien.
74B zeigt einen auf dem CDG von 74A basierenden Datenflußgraph.
75 zeigt einen Datenflußgraph.
Ausführliche Beschreibung der bevorzugten Ausführungsformen
Koordinationszentrisches Softwaredesign
1 ist ein Beispiel einer Komponente 100, die das grundlegende Softwareelement innerhalb des koordinationszentrischen Designrahmens gemäß der vorliegenden Offenbarung ist. Bezugnehmend auf 1 enthält Komponente 100 einen Satz von Betriebsarten 102. Jede Betriebsart 102 entspricht einem mit der Komponente 100 verknüpften spezifischen Verhalten. Jede Betriebsart 102 kann entweder aktiv oder nicht aktiv sein und aktiviert dementsprechend das dieser Betriebsart 102 entsprechende Verhalten. Betriebsarten 102 können die Bedingungsaspekte des Verhaltens von Komponente 100 zum Ausdruck bringen. Das Verhalten von Komponente 100 ist in einem Satz von Handlungen 104 eingekapselt, die diskrete, von einem Ereignis ausgelöste Verhaltenselemente innerhalb der koordinationszentrischen Design-Methodologie sind. Komponente 100 kann modifiziert werden und stellt die Codesharing-Vorteile der Vererbung bereit.
Handlungen 104 werden durch Betriebsarten 102 aktiviert und deaktiviert und können daher effektiv als Eigenschaften von Betriebsarten 102 betrachtet werden. Ein (nicht dargestelltes) Ereignis ist eine momentane Bedingung, wie zum Beispiel ein Tick einer Zeituhr, ein Datenabgang oder -zugang oder eine Betriebsartänderung. Handlungen 104 können Betriebsarten 102 aktivieren und deaktivieren, wodurch sie das zukünftige Verhalten von Komponente 100 auswählen. Dies hat Ähnlichkeit mit "Actor" Sprachen, in denen Verfahren erlaubt sind, mit denen das Verhalten eines Objekts ersetzt werden kann.
Bei koordinationszentrischem Design müssen jedoch alle möglichen Verhaltensweisen vor der Laufzeit identifiziert und verkapselt werden. Zum Beispiel könnte ein Designer, der eine Benutzerschnittstellenkomponente für ein Handy baut, eine Betriebsart zum Nachschlagen von Nummern in einem Adreßbuch (in dem das Benutzerschnittstellenverhalten komplette Adreßbucheinträge in formatiertem Text anzeigen soll) und eine andere Betriebsart zur Anzeige des Telefonstatus (in dem das Benutzerschnittstellenverhalten das Signalstrom- und Batterieniveau des Telefons grafisch anzeigen soll) definieren. Der Designer muß sowohl die Betriebsarten als auch die Handlungen für die gegebenen Verhaltensweisen definieren, bevor die Komponente ausgeführt werden kann.
In 2 enthält die Komponente 100 ferner eine erste Koordinationsschnittstelle 200, eine zweite Koordinationsschnittstelle 202 und eine dritte Koordinationsschnittstelle 204. Komponenten 100 nach dem koordinationszentrischen Design stellen die Codesharing-Fähigkeit der objektorientierten Vererbung durch Kopieren bereit. Ein weiterer Aspekt von objektorientierter Vererbung ist Polymorphismus durch gemeinsam genutzte Schnittstellen. Bei objektorientierten Sprachen wird die Schnittstelle des Objekts durch seine Verfahren definiert.
Obwohl die Handlungen 104 des koordinationszentrischen Designs den Verfahren in objektorientierten Sprachen ähnlich sind, definieren sie nicht die Schnittstelle für Komponente 100. Komponenten beeinflussen einander gegenseitig über ausdrückliche und separate Koordinationsschnittstellen, in dieser Figur über Koordinationsschnittstellen 200, 202 und 204. Die Form von Koordinationsschnittstellen 200, 202 und 204 bestimmt die Arten, in denen Komponente 100 innerhalb eines Softwaresystems verbunden werden kann. Die Art, in der Koordinationsschnittstellen 200, 202 und 204 mit Betriebsarten 102 und Handlungen 104 innerhalb von Komponente 100 verbunden sind, bestimmt, wie das Verhalten von Komponente 100 innerhalb eines Systems gemanagt werden kann. Systemweites Verhalten wird über Koordinatoren (siehe 4B und folgende) gemanagt.
Zur Wirksamkeit unseres Ansatzes müssen mehrere Faktoren im Design von Softwareelementen zusammenfallen: Verpackung, interne Organisation und wie Elemente ihr Verhalten koordinieren. Obwohl diese oft als unabhängige Belange behandelt werden, können Konflikte zwischen ihnen die Fehlersuche erschweren. Wir behandeln sie in einem einheitlichen Rahmen, in dem die interne Aktivität von Komponente 100 von der externen Beziehung getrennt ist. Dies gestattet Designern, mehr modulare Komponenten zu bauen und ermutigt sie, verteilbare Versionen von Koordinationsprotokollen anzugeben. Komponenten können wiederholt in einer Vielfalt von Zusammenhängen, sowohl als verteilter als auch als einzelner Prozessor 1, eingesetzt werden.
1. Einführung in die Koordination
Innerhalb dieser Anwendung bezieht sich Koordination auf die vorbestimmten Weisen, in denen sich Komponenten gegenseitig beeinflussen. Man betrachte eine allgemeine Koordinationsaktivität: Ressourcenzuweisung. Ein einfaches Protokoll hierfür ist Round-Robin: Die Teilnehmer werden aufgereiht, und die Ressource wird jedem Teilnehmer der Reihe nach zugewiesen. Nachdem der letzte Teilnehmer bedient wurde, wird die Ressource wieder dem ersten zugeteilt. Es gibt eine Ressourcen-Planungsperiode, während der jeder Teilnehmer die Ressource exakt einmal erhält, egal ob sie benötigt wird oder nicht.
3A ist ein Round-Robin-Ressourcenzuweisungsprotokoll nach dem Stand der Technik mit einem zentralisierten Controller 300, der die gemeinsam genutzte Ressource (nicht dargestellt) verfolgt und sie der Reihe nach an jedes der Softwareelemente 302, 304, 306, 308 und 310 verteilt. Mit Bezug auf 3A bestimmt Controller 300 allein, welches Softwareelement 302, 304, 306, 308 oder 310 gegenwärtig die Ressource benutzen kann, und welches sie als nächstes benutzen kann. Diese Implementierung eines Round-Robin-Protokolls ermöglicht die modulare Bauweise für Softwareelemente 302, 304, 306, 308 und 310, weil nur Controller 300 die Softwareelemente verfolgt. Leider muss, wenn diese Implementierung auf einer verteilten Architektur eingesetzt (nicht dargestellt) wird, Controller 300 typisch auf ein einzelnes Verarbeitungselement (nicht dargestellt) plaziert werden. Dies hat zur Folge, daß alle Koordinationsanforderungen durch dieses Verarbeitungselement laufen müssen, was einen Engpaß in der Kommunikationsleistung verursachen kann. Zum Beispiel betrachte man die Situation, in der Softwareelemente 304 und 306 auf einem ersten Verarbeitungselement (nicht dargestellt) implementiert sind und Controller 300 auf einem zweiten Verarbeitungselement implementiert ist. Softwareelement 304 gibt die gemeinsam genutzte Ressource frei und muß dies dem Controller 300 in einer Meldung mitteilen. Controller 300 muß dann eine Meldung an Softwareelement 306 senden, um diesem mitzuteilen, daß es jetzt ein Anrecht auf die gemeinsam genutzte Ressource hat. Wenn der Kommunkationskanal zwischen dem ersten Verarbeitungselement und dem zweiten Verarbeitungselement im Einsatz steht oder das zweite Verarbeitungselement belegt ist, muß die gemeinsame Ressource unbenutzt bleiben, obwohl sowohl der aktuelle Ressourcenhalter als auch der nächste Ressourcenhalter (Softwareelement 304 bzw. 306) auf dem ersten Verarbeitungselement (nicht dargestellt) implementiert sind. Die gemeinsam genutzte Ressource muß typisch unbenutzt bleiben, bis eine Kommunikation stattfinden und Controller 300 darauf ansprechen kann. Dies ist eine ineffiziente Art und Weise, den Zugriff auf eine gemeinsam genutzte Ressource zu kontrollieren.
3B ist ein Round-Robin-Ressourcenzuweisungsprotokoll nach dem Stand der Technik, das ein Toking Passing System implementiert. Mit Bezug auf 3B besteht dieses System aus einer gemeinsam genutzten Ressource 311 und einem Satz von Softwareelementen 312, 314, 316, 318, 320 und 322. In diesem System symbolisiert ein logisches Token 324 das Recht auf den Zugriff von Ressource 311, d.h. wenn ein Softwareelement Token 324 besitzt, hat es das Recht, auf Ressource 311 zuzugreifen. Wenn eins der Softwareelemente 312, 314, 316, 318, 320 oder 322 mit Ressource 311 fertig ist, übergibt es Token 324, und damit das Zugriffsrecht, an einen Nachfolger. Diese Implementierung kann ohne einen zentralisierten Controller verteilt werden, aber wie aus 3B ersichtlich, ist sie weniger modular, weil jedes Softwareelement im Satz benötigt wird, um einen Nachfolger zu verfolgen.
Nicht nur müssen Softwareelemente 312, 314, 316, 318, 320 und 322 verfolgen, wer der Nachfolger ist, sondern jedes Element muß auch ein potentiell kompliziertes und fehleranfälliges Protokoll zur Übertragung von Token 324 an seinen Nachfolger implementieren. Fehler können bewirken, daß Token 324 verlorengeht oder daß mehrere Tokens 324 eingeführt werden. Da keine formelle Verbindung zwischen dem physischen System und den kompletten Topologiediagrammen (Diagramme, die zeigen, wie jedes Softwareelement mit anderen innerhalb des Systems verbunden ist) besteht, könnten manche Softwareelemente versehentlich mehrere Male pro Zyklus bedient werden, während andere total vernachlässigt werden. Diese Fehler sind jedoch äußerst schwierig zu finden, nachdem das System fertiggestellt ist. Das Protokoll ist in der Funktionalität jedes Softwareelements verfangen und es ist schwierig, beide zu Fehlersuchzwecken voneinander zu trennen. Wenn sich weiterhin einige der Softwareelemente auf der gleichen Maschine befinden, kann die Implementierungsleistung schlecht sein. Die Verwicklung von Computation und Koordination erfordert tiefgehende Modifikationen, um das System zu optimieren.
2. Koordinationsansatz bei koordinationszentrischem Systemdesign
Die koordinationszentrische Design-Methodologie stellt einen einkapselnden Formalismus für Koordination bereit. Komponenten, wie zum Beispiel Komponente 100, beeinflussen sich gegenseitig über Koordinationsschnittstellen, zum Beispiel erste, zweite und dritte Koordinationsschnittstellen 200, 202 bzw. 204. Koordinationsschnittstellen stellen Komponentenmodularität sicher, während sie Teile einer Komponente hervorheben, die an der Koordination teilhaben. Diese Technik der Verbindung von Komponenten sorgt für Polymorphismus in ähnlicher Weise wie „Subtyping" in objektorientierten Sprachen.
4A ist eine detaillierte Ansicht einer Komponente 400 und einer Ressourcenzugriff-Koordinationsschnittstelle 402, die zum Einsatz in einem Round-Robin-Koordinationsprotokoll gemäß der vorliegenden Offenbarung mit Komponente 400 verbunden ist. Mit Bezug auf 4A ermöglicht die Ressourcenzugriff-Koordinationsschnittstelle 402 die Implementierung eines Round-Robin-Protokolls, das dem oben beschriebenen Token-passing Round-Robin-Protokoll ähnlich ist. Die Ressourcenzugriff-Koordinationsschnittstelle 402 weist ein einzelnes Kontrollzustandsbit, genannt Zugriff auf, welches als arbitrierter Kontrollport 404 dargestellt ist, der angibt, ob eine Komponente 400 ein (nicht dargestelltes) virtuelles Token hält oder nicht.
Komponente 400 kann auf Zugriffskoordinationsschnittstelle 402 nur dann einen Sendemeldungsport 406 benutzen, wenn der arbitrierte Kontrollport 404 wahr ist. Zugriffskoordinationsschnittstelle 402 weist ferner einen Empfangsmeldungsport 408 auf.
4B zeigt einen Round-Robin-Koordinator 410 gemäß der vorliegenden Offenbarung. In 4B weist der Round-Robin-Koordinator 410 einen Satz von Koordinator-Koordinationsschnittstellen 412 zum Anschluß an einen Satz von Komponenten 400 auf. Jede Komponente 400 enthält eine Ressourcenzugriff-Koordinationsschnittstelle 402. Jede Koordinator-Koordinationsschnittstelle 412 weist einen Koordinator-arbitrierien Kontrollport 414, einen eingehenden Sendemeldungsport 416 und einen ausgehenden Empfangsmeldungsport 418 auf. Koordinator-Koordinationsschnittstelle 412 komplementirt Ressourcenzugriff-Koordinationsschnittstelle 402 und umgekehrt, weil die Ports der beiden Schnittstellen kompatibel sind und die Funktion der Übertragung von Information zwischen den beiden Schnittstellen ausführen können.
Das Round-Robin-Protokoll benötigt den Round-Robin-Koordinator 410 zum Managen der Koordinationstopologie. Round-Robin-Koordinator 410 ist eine Instanz von allgemeineren Abstraktionen genannt Koordinationsklassen, in denen Koordinationsklassen spezifische Koordinationsprotokolle definieren, und ein Koordinator ist eine spezifische Implementierung der Koordinationsklasse. Round-Robin-Koordinator 410 enthält alle Informationen darüber, wie Komponenten 400 die Koordination durchführen sollen. Obwohl Round-Robin-Koordinator 410 eine verteilte Implementierung aufweisen kann, ist keine Komponente 400 verpflichtet, Bezugnahmen auf eine andere Komponente 400 zu speichern (im Gegensatz zu der verteilten Round-Robin-Implementierung in 3B). Alle benötigten Bezugnahmen werden vom Round-Robin-Koordinator 410 selbst verwahrt, und die Komponenten 400 müssen nicht einmal wissen, daß sie durch Round-Robin koordiniert werden. Ressourcenzugriff-Koordinationsschnittstelle 402 kann mit jedem Koordinator verwendet werden, der die entsprechende komplementäre Schnittstelle bereitstellt. Das Design eines Koordinators ist abhängig davon, ob es auf einer verteilten Plattform oder einer monolithischen Einzelprozessorplattform implementiert wird.
3. Koordinationsschnittstellen
Koordinationsschnittstellen dienen zum Anschluß von Komponenten an Koordinatoren. Sie spielen ferner eine Rolle, indem sie eine Vielfalt von nützlichen Laufzeit-Fehlersuchtechniken erlauben. Koordinationsschnittstellen unterstützen die Komponentenmodularität, indem sie alle an einem Koordinationsprotokoll teilhabenden Teile offenlegen. Ports sind Elemente von Koordinationsschnittstellen, so wie Garantien und Erfordernisse, die jeweils im Folgenden beschrieben werden.
A. Ports
Ein Port ist ein primitiver Anschlußpunkt zum Zusammenschließen von Komponenten. Jeder Port ist ein Fünfer-Tuple (T; A; Q; D; R), in dem

• T den Datentyp des Ports darstellt. T kann ein Int, ein Boolsch, ein Char, Byte, Float, Double oder Cluster sein, wobei Cluster ein Cluster von Datentypen darstellt (z.B. ein Int, gefolgt von einem Float, gefolgt von zwei Bytes).
• A ist ein boolscher Wert, der wahr ist, wenn der Port arbitriert ist, und andernfalls falsch ist.
• Q ist eine Ganzzahl größer als Null, die die logische Warteschlangentiefe für einen Port darstellt.
• D ist In, Out, Inout oder Custom und stellt die Richtung des Datenflusses mit Bezug auf den Port dar.
• R ist Discard-on-Read (nach Lesen beseitigen), Discard-on-Transfer (nach Übertragung beseitigen), oder Hold (Halten) und stellt die Verfahrensweise zur Datenbeseitigung am Port dar. Discard-on-Read zeigt an, daß Daten sofort nach dem Lesen beseitigt (und Daten in der logischen Warteschlange verschoben) werden, Discard-on-Transfer zeigt an, daß Daten vom Port sofort nach Übertragung auf einen anderen Port beseitigt werden, und Hold zeigt an, daß Daten so lange zu halten sind, bis sie von einem Wert überschrieben werden. Hold unterliegt der Arbitration.

„Custom Directionality" gestattet Designern, Ports anzugeben, die nur bestimmte spezifische Werte akzeptieren oder erzeugen. Zum Beispiel wünscht ein Designer vielleicht einen Port, der anderen Komponenten das Aktivieren aber nicht Deaktivieren einer Betriebsart ermöglicht. Während viele Port-Kombinationsattribute möglich sind, treffen wir normalerweise nur auf wenige. Die drei üblichsten sind Meldungsports (Ausgang oder Eingang), Zustandsports (Ausgang, Eingang oder beide; manchmal arbitriert) und Kontrollports (eine Art von Zustandsport). 5 veranschaulicht die visuelle Syntax, die in dieser Anmeldung durchweg für mehrere übliche Ports benutzt wird. Mit Bezug auf 5 zeigt diese Figur einen exportierten Zustandsport 502, einen importierten Zustandsport 504, einen arbitrierten Zustandsport 506, einen Ausgangsdatenport 508 und einen Eingangsdatenport 510.
1. Meldungsports
Meldungsports (Ausgangs- und Eingangsdatenports) 508 bzw. 510 sind entweder Sende-(T; false; 1; Out; Discard-on-Transfer) oder Empfangsports (T; false; Q; In; Discard-on-Read). Ihre Funktion besteht darin, Daten zwischen Komponenten zu übertragen. An einen Sendeport übergebene Daten werden sofort auf den entsprechenden Empfangsport übertragen, sie können also vom Sendeport nicht später wieder abgerufen werden. Empfangsdatenports können Warteschlangen verschiedener Länge aufweisen. Dateneingänge an diesen Ports werden häufig dazu benutzt, Datenparameter auszulösen und sie an Handlungen weiterzuleiten. Werte verbleiben so lange auf den Empfangsports, bis sie gelesen werden.
2. Zustandsports
Zustandsports weisen folgende Formen auf:

1. (T; false; 1; Out; Hold)(T; falsch; 1; Aus; Halten)
2. (T; false; 1; In; Hold)(T; falsch; 1; Ein; Halten)
3. (T; true; 1; Inout; Hold)(T; wahr; 1; Einaus; Halten)

Zustandsports, wie z.B. exportierter Zustandsport 502, importierter Zustandsport 504 und arbitrierter Zustandsport 506, halten ständige Werte, und der einem Zustandsport zugewiesene Wert kann arbitriert werden. Das bedeutet, daß Werte im Gegensatz zu Meldungsports so lange an den Zustandsports bleiben, bis sie geändert werden. Wenn mehrere Softwareelemente gleichzeitig versuchen, den Wert eines arbitrierten Zustandsports 506 zu ändern, wird der endgültige Wert auf der Basis von Arbitrationsregeln bestimmt, die vom Designer durch einen Arbitrationskoordinator (nicht dargestellt) bereitgestellt werden.
Zustandsports übertragen variable Werte zwischen Geltungsbereichen. Bei koordinationszentrischem Design sind alle Variablen einer Komponente für diese Komponente lokal, und diese Variablen müssen ausdrücklich im Geltungsbereich der Komponente erklärt werden. Variablen können jedoch an Zustandsports gebunden sein, die mit anderen Komponenten verbunden sind. Auf diese Weise kann ein variabler Wert zwischen Komponenten übertragen werden, und der variable Wert erzielt den Systemniveaueffekt einer Multivariablen.
3. Kontrollports
Kontrollports sind ähnlich wie Zustandsports, ein Kontrollport ist jedoch auf den boolschen Datentyp beschränkt. Kontrollports sind typisch an Betriebsarten gebunden. Handlungen wirken indirekt mit einem Kontrollport zusammen, indem sie die Werte einer Betriebsart, die an den Kontrollport gebunden ist, einstellen und auf diese ansprechen.
Zum Beispiel ist der arbitrierte Kontrollport 404 von 4A ein Kontrollport, der an eine Betriebsart (nicht dargestellt) gebunden sein kann, die alle Handlungen enthält, die Daten auf einem gemeinsamen Kanal senden. Wenn der arbitrierte Kontrollport 404 falsch ist, ist die Betriebsart inaktiv und deaktiviert alle Handlungen, die Daten auf dem Kanal senden.
B. Garantien
Garantien sind formelle Erklärungen über unveränderliche Eigenschaften einer Koordinationsschnittstelle. Es gibt mehrere Arten von Garantien, wie zum Beispiel Timing-Garantien zwischen Ereignissen, Garantien zwischen Kontrollzuständen (z.B. gegenseitiger Ausschluß von Zustand A und Zustand B) usw. Obwohl die Garantien einer Koordinationsschnittstelle Eigenschaften der Komponente, an die die Koordinationsschnittstelle angeschlossen ist, reflektieren, sind die Garantien nicht physisch an irgendwelche internen Teile der Komponente gebunden. Garantien können oft durch statische Analyse des Softwaresystems bestätigt werden. Garantien dienen dem Zweck, verschiedene für eine Komponente oder einen Koordinator inhärente Eigenschaften in den Cache zu kopieren, um die statische Analyse des Softwaresystems zu vereinfachen.
Eine Garantie ist ein von einer Koordinationsschnittstelle gegebenes Versprechen. Die Garantie weist die Form eines Prädikats auf, für das Unveränderlichkeit versprochen wurde. Im Prinzip können Garantien jede Art von Prädikat enthalten (z.B. x > 3, wobei x ein mit einer Ganzzahl bewerteter Zustandsport ist, oder tea – teb < 2 ms). Um weiteren Fortgang dieser Anmeldung sind Garantien nur Ereignis-Reihenfolge-Garantien (Garantien, die akzeptable Ereignisreihenfolgen angeben) oder Kontrollbeziehungsgarantien (Garantien, die sich auf akzeptable relative Komponentenverhaltensweisen beziehen).
C. Erfordernisse
Ein Erfordernis ist eine formelle Erklärung der für korrekte Softwarefunktionalität notwendigen Eigenschaften. Ein Beispiel eines Erfordernisses ist eine benötige Antwortzeit für eine Koordinationsschnittstelle – die Anzahl der Meldungen, die an der Koordinationsschnittstelle eingegangen sein müssen, bevor die Koordinationsschnittstelle die Meldungen übertragen oder „feuern" kann. Wenn zwei Koordinationsschnittstellen aneinander gebunden sind, müssen die Erfordernisse der ersten Koordinationsschnittstelle mit den Garantien der zweiten Koordinationsschnittstelle konservativ übereinstimmen (z.B. x < 7 als Garantie stimmt konservativ mit x < 8 als Erfordernis überein). Wie bei Garantien sind Erfordernisse nicht physisch an irgendetwas in der Komponent selbst gebunden. Garantien können oft als ausreichend für die korrekte Operation des Softwaresystems verifiziert werden, in dem die Komponente eingesetzt wird. Ein Erfordernis ist also ein Prädikat auf einer ersten Koordinationsschnittstelle, die konservativ mit einer Garantie auf einer komplementären zweiten Koordinationsschnittstelle übereinstimmen muß.
D. Schlußfolgerung mit Bezug auf Koordinationsschnittstellen
Eine Koordinationsschnittstelle ist ein Vierer-Tuple (P; G; R; I), in dem

• P ein Satz von benannten Ports ist.
• G ein Satz von benannten Garantien ist, die von der Schnittstelle bereitgestellt werden.
• R ein Satz von benannten Erfordernissen ist, die mit Garantien angeschlossener Schnittstellen übereinstimmen müssen.
• I ein Satz von benannten Koordinationsschnittstellen ist.

Wie diese Definition zeigt, sind Koordinationsschnittstellen rekursiv. Die Koordinator-Koordinationsschnittstelle 412 in 4B, die für Round-Robin-Koordination verwendet wird, heißt AccessInterface und ist in Tabelle 1 definiert.
Tabelle 1
Mit Koordinationsschnittstellen verwandt ist ein rekursiver Koordinationsschnittstellen-Deskriptor, der ein Fünfer-Tuple (Pa; Ga; Ra; Id; Nd) ist, in dem

• Pa ein Satz von abstrakten Ports ist, welches Ports sind, die unvollständig in ihren Attributen sind (d.h. sie weisen noch keinen Datentyp auf).
• Ga ein Satz von abstrakten Garantien ist, welches Garantien zwischen abstrakten Ports sind.
• Ra ein Satz von abstrakten Erfordernissen ist, welches Erfordernisse zwischen abstrakten Ports sind.
• Id ein Satz von Koordinationsschnittstellen-Descriptoren sind.
• Nd ein Element von Q × Q ist, worin Q = {∞} ∪ Z+ und Z+ den Satz von positiven Ganzzahlen bezeichnet. Nd zeigt die Nummer oder den Bereich von Nummern zulässiger Schnittstellen an.

Ein mächtiges Merkmal ist die Tatsache, daß Koordinationsschnittstellen andere Koordinationsschnittstellen enthalten können. So haben Designer die Möglichkeit, gemeinsame Koordinationsschnittstellen als komplexe Ports innerhalb anderer Koordinationsschnittstellen zu benutzen. Die oben beschriebenen grundlegenden Meldungsports, beispielsweise, sind nicht-blockierend, wir können jedoch eine blockierende Koordinationsschnittstelle (nicht dargestellt) bauen, die als blockierender Port dient, indem wir einen Wartezustandsport mit einem Meldungsport kombinieren.
4. Koordinatoren
Ein Koordinator ist die konkrete Darstellung von Zwischenkomponentenaspekten eines Koordinationsprotokolls. Koordinatoren ermöglichen die Verwendung einer Vielfalt von Zustandsanalysen-Fehlersuchmethodologien für Softwaresysteme, die mit der koordionationszentrischen Methodologie erstellt wurden. Ein Koordinator enthält einen Satz von Koordinationsschnittstellen und definiert die Beziehung zwischen diesen Koordinationsschnittstellen. Die Koordinationsschnittstellen komplementieren die Komponenten-Koordinationsschnittstellen, die von den innerhalb des Protokolls operierenden Komponenten bereitgestellt werden. Über übereinstimmende Schnittstellenpaare sind Koordinatoren effektiv Verbindungen zwischen Meldungsports, Korrelationen zwischen Kontrollzuständen und Transaktionen zwischen Komponenten.
Zum Beispiel muß der in 4B gezeigte Round-Robin-Koordinator 410 sicherstellen, daß nur für eine Komponente 400 der Wert ihres Komponentenkontrollports 404 oder ihr Zugriffsbit auf wahr gesetzt wurde. Weiterhin muß Round-Robin-Koordinator 410 sicherstellen, daß für die korrekte Komponente 400 der Komponentenkontrollport 404 für die gewählte Sequenz auf Wahr gesetzt wurde. Dieser Abschnitt enthält formelle Definitionen der Teile, aus denen Koordinatoren bestehen: Betriebsarten, Handlungen, Bindungen, Handlungs-Triples und Beschränkungen. Diese Definitionen ergeben eine formelle Definition von Koordinatoren.
A. Betriebsarten
Eine Betriebsart ist ein boolscher Wert, der als Guard auf einer Handlung benutzt werden kann. In einem Koordinator ist die Betriebsart oft an einen Kontrollport in einer Koordinationsschnittstelle für den Koordinator gebunden. Beispielsweise sind im Round-Robin-Koordinator 410 die „Concern"-Betriebsarten an einen Koordinator-Kontrollport 414 jeder Koordinator-Koordinationsschnittstelle 412 gebunden.
B. Handlungen
Eine Handlung ist ein primitives Verhaltenselement, welches

• auf Ereignisse ansprechen kann.
• Ereignisse erzeugen kann.
• Betriebsarten ändern kann.

Handlungen können, was ihrer Komplexität anbelangt, von einfachen Operationen bis hin zu komplizierten Teilen des Quellencodes reichen. Eine Handlung in einem Koordinator wird als transparente Handlung bezeichnet, weil die Auswirkungen der Handlung vorberechnet werden können und die internen Teile der Handlung für die koordinationszentrischen Designtools vollständig offenliegen. Wenn Bindungen zur Ereignisbenachrichtigung benutzt werden, nennt man sie Auslöser.
C. Bindungen
Bindungen verbinden Eingangsport mit Ausgangsports, Kontrollports mit Betriebsarten, Zustandsports mit Variablen und Meldungsports mit Ereignissen. Bindungen sind transparent und passiv. Bindungen sind lediglich Leitkanäle für Ereignisbenachrichtigung und Datenübertragung.
D. Handlungs-Triples
Um ausgeführt werden zu können, muß eine Handlung von einer Betriebsart aktiviert und von einem Ereignis ausgelöst werden. Die Kombination von Betriebsart, Auslöser und Handlung wird als Handlungs-Triple bezeichnet, ein Triple (m; t; a), in dem:

• m eine Betriebsart ist.
• t ein Auslöser ist.
• a eine Handlung ist.

Der Auslöser ist ein Verweis auf einen Ereignistyp, kann aber auch zur Übergabe von Daten an eine Handlung verwendet werden. Handlungs-Triples werden geschrieben: Betriebsart : Auslöser : Handlung.
Die Handlungen eines Koordinators sind gewöhnlich entweder reine Kontrolle, wobei sowohl der Auslöser als auch die durchgeführte Handlung nur den Kontrollzustand beeinflussen, oder reine Daten, wobei sowohl der Auslöser als auch die durchgeführte Handlung im Datenbereich eintreten. Im Falle des Round-Robin-Koordinators 410 ist der folgende Satz von Handlungen verantwortlich für die Beibehaltung des entsprechenden Zustands:
accessi : –accessi : +access (i + 1) mod n
Das Symbol „+" bedeutet die Aktivierungskante einer Betriebsart (d.h. das mit der Betriebsart verknüpfte Ereignis wird wahr), und das Symbol „–" bedeutet ihre Deaktivierungskante. Wenn eine Koordinator-Koordinationsschnittstelle 412 das Zugriffsbit ihres arbitrierten Kontrollports 404 deaktiviert, wird automatisch das Zugriffsbit der nächsten Koordinator-Koordinationsschnittstelle 412 aktiviert.
E. Beschränkungen
In dieser Abhandlung sind Beschränkungen boolsche Beziehungen zwischen Kontrollports.
Sie weisen folgende Form auf:
Bedingung ⇒ Wirkung
Dies bedeutet im wesentlichen, daß wenn die Bedingung (auf der linken Seite des Pfeils) wahr ist, die Wirkung (auf der rechten Seite des Pfeils) ebenfalls wahr ist. In anderen Worten, wenn die Bedingung wahr ist, ist auch die Wirkung wahr.
Eine Beschränkungen unterscheidet sich von einer Garantie dadurch, daß die Garantie darauf beschränkt ist, unveränderliche Beziehungen zwischen Komponenten mitzuteilen, ohne eine Möglichkeit bereitzustellen, die unveränderliche Beziehung durchzusetzen. Die Beschränkung auf der anderen Seite ist ein Satz von Anweisungen an das Laufzeitsystem, die angeben, wie bestimmte Beziehungen zwischen Komponenten durchgesetzt werden können. Wenn eine Beschränkung verletzt wird, stehen dem System zwei Konekturmaßnahmen zur Verfügung: (1) Modifizieren der Werte auf der linken Seite, so daß der linke Ausdruck als falsch ausgewertet wird (eine „Backpressure" genannte Wirkung) oder (2) Ändern der rechten Seite, damit sie wahr wird. Diese Techniken werden von uns als LHM (Modifizierung linke Seite) und RHM (Modifizierung rechte Seite) bezeichnet. Zum Beispiel, wenn die Beschränkung
x ⇒ ¬y und der Wert x ∧ γ
lautet, muß bei RHM Semantik das Laufzeitsystem ansprechen, indem es γ deaktiviert oder γ auf falsch setzt. Somit wird der Wert ¬γ auf wahr gesetzt.
Die Entscheidung, ob LHM oder RHM benutzt werden soll, oder ob die Durchsetzung einer Beschränkung in bestimmten Situationen suspendiert werden soll, hat eine dramatische Auswirkung auf die Wirksamkeit und Vorhersagbarkeit des Softwaresystems. Koordinationszentrisches Design versucht nicht, gleichzeitige Beschränkungen während der Laufzeit zu lösen. Vielmehr benutzen Laufzeitalgorithmen lokale Lösungen für Beschränkungsreihenfolgen. Dies kann jedoch zur Verletzung von manchen Beschränkungen führen und wird unten weiter besprochen.
Round-Robin-Koordinator 410 hat einen Satz von Sicherheitsbeschränkungen um sicherzustellen, daß nie mehr als ein Token im System ist:
access_i ⇒ ∀_j≠i ¬access_j
Die obige Gleichung, grob zu access_i übersetzt, bedeutet not access_j für den Satz aller access_j, worin j nicht gleich i ist. Selbst dieses einfache Beschränkungssystem kann Probleme für lokale Lösungssemantiken (wie LHM und RHM) verursachen. Wenn das Laufzeitsystem versuchen würde, alle Beschränkungen gleichzeitig zu lösen, würden alle Zugriffsbetriebsarten geschlossen werden. Wenn sie jeweils einzeln gelöst würden, würden Token-Duplikate beim ersten Durchgang gelöscht, wodurch alle anderen Beschränkungen zufriedengestellt würden und ein einzelnes Token im System bliebe.
Da High-Level-Protokolle aus Kombinationen von Lower-Level-Protokollen gebildet werden können, können Koordinatoren hierarchisch zusammengesetzt werden. Ein Koordinator ist ein Sechser-Tuple (I; M; B; N; A; X), in dem

• I ein Satz von Koordinationsschnittstellen ist.
• M ein Satz von Betriebsarten ist.
• B ein Satz von Bindungen zwischen Schnittstellenelementen (z.B. Kontrollports und Meldungsports) und internen Elementen (z.B. Betriebsarten und Auslösern) ist.
• N ein Satz von Beschränkungen zwischen Schnittstellenelementen ist.
• A ein Satz von Handlungs-Triplen für den Koordinator ist.
• X ein Satz von Subkoordinatoren ist.

6A, 6B, 6C und 6D stellen einige einfache Koordinatoren dar, die die Bindungen und Beschränkungen der betreffenden Koordinatoren hervorheben. 6A zeigt einen unidirektionalen Datenübertragungskoordinator 600, der Daten in einer Richtung zwischen zwei Komponenten (nicht dargestellt) überträgt, indem er den eingehenden Empfangsmeldungsport 408 an den ausgehenden Empfangsmeldungsport 418 mit einer Bindung 602 anschließt. 6B zeigt einen bidirektionalen Datenübertragungskoordinator 604, der Daten zwischen zwei Komponenten (nicht dargestellt) hin und zurück überträgt, indem er den eingehenden Empfangsmeldungsport 408 an den ausgehenden Empfangsmeldungsport 418 mit einer Bindung 602 und den Sendemeldungsport 406 an den eingehenden Sendemeldungsport 416 mit einer zweiten Bindung anschließt. Der unidirektionale Datenübertragungskoordinator 600 und der bidirektionale Datenübertragungskoordinator 604 bewegen Daten einfach von einem Meldungsport zu einem anderen. Somit besteht jeder Koordinator aus Bindungen zwischen entsprechenden Ports auf separaten Koordinationsschnittstellen.
In 6C sorgt der Zustandsvereinigungskoordinator 606 dafür, daß ein Zustandsport a 608 und ein Zustandsport b 610 immer auf den gleichen Wert eingestellt sind. Zustandsvereinigungskoordinator 606 verbindet Zustandsport a 608 mit Zustandsport b 610 über Bindung 602. In 6D hat Kontrollzustands-Mutex-Koordinator 612 eine erste Beschränkung 618 und eine zweite Beschränkung 620, wie folgt:

(1) c ⇒ ¬d und
(2) d ⇒ ¬c

Beschränkungen 618 und 620 können umformuliert werden, wie folgt:

(1) Ein Zustandsport c 614 mit einem wahren Wert bedeutet, daß ein Zustandsport d 616 einen falschen Wert hat, und
(2) Zustandsport d 616 mit einem wahren Wert bedeutet, daß Zustandsport c 614 einen falschen Wert hat.

Ein Koordinator hat zwei Arten von Koordinationsschnittstelle: Up-Schnittstellen, die den Koordinator an einen zweiten Koordinator anschließen, der auf einer höheren Ebene der Designhierarchie liegt, und Down-Schnittstellen, die den Koordinator entweder mit einer Komponente oder einem dritten Koordinator verbinden, der auf einer niedrigen Ebene der Designhierarchie liegt. Down-Schnittstellen haben Namen, denen ein „~" vorausgeht. Round-Robin-Koordinator 410 hat sechs Down-Koordinationsschnittstellen (die zuvor mit Koordinator-Koordinationsschnittstellen 412 bezeichnet wurden) mit Beschränkungen, die verursachen, daß das Abschalten eines Koordinator-Kontrollports 414 (auch mit Zugriffskontrollport bezeichnet) das Einschalten des Kontrollports 414 der nächsten Koordinator-Koordinationsschnittstelle 412 in der Reihe bewirkt. Tabelle 2 stellt alle Bestandteile des Round-Robin-Koordinators dar.
Tabelle 2
Dieses Tuple beschreibt eine Implementation eines Round-Robin-Koordinationsprotokolls für ein bestimmtes System mit sechs Komponenten, wie in Round-Robin-Koordinator 410 dargestellt. Wir benutzen eine Koordinationsklasse, um ein allgemeines Koordinationsprotokoll zu beschreiben, welches eventuell keine feste Anzahl von Koordinator-Koordinationsschnittstellen hat. Die Koordinationsklasse ist ein Sechser-Tuple (Ic; Mc; Bc; Nc; Ac; Xc), in dem

• Ic ein Satz von Koordinationsschnittstellen-Deskriptoren ist, wobei jeder Deskriptor eine Art von Koordinationsschnittstelle bereitstellt und die Anzahl der Schnittstellen angibt, die innerhalb der Koordinationsklasse erlaubt ist.
• Mc ein Satz von abstrakten Betriebsarten ist, der entsprechende Betriebsarten liefert, wenn eine Koordinationsklasse mit einer festen Anzahl von Koordinator-Koordinationsschnittstellen eingerichtet wird.
• Bc ein Satz von abstrakten Bindungen ist, der entsprechende Bindungen zwischen Elementen bildet, wenn die Koordinationsklasse eingerichtet wird.
• Nc ein Satz von abstrakten Beschränkungen ist, der sicherstellt, daß entsprechende Beschränkungen zwischen Koordinationsschnittstellenkomponenten, wie beim Einrichten angegeben, plaziert wurden.
• Ac ein Satz von abstrakten Handlungs-Triplen für den Koordinator ist.
• Xc ein Satz von Koordinationsklassen (Hierarchie) ist.

Während ein Koordinator ein Koordinationsprotokoll für eine bestimmte Anwendung beschreibt, müssen viele Aspekte, wie die Anzahl der Koordinationsschnittstellen und Datentypen festgelegt werden. Koordinationsklassen beschreiben Protokolle über viele Anwendungen hinweg. Der Einsatz der Koordinationsschnittstellen-Deskriptoren anstatt Koordinationsschnittstellen erlaubt den Koordinationsklassen, die Anzahl von Schnittstellen und Datentypen so lange unbestimmt zu lassen, bis ein bestimmter Koordinator eingerichtet wird. Ein Round-Robin-Koordinator zum Beispiel enthält eine feste Anzahl von Koordinator-Koordinationsschnittstellen mit spezifischen Bindungen und Beschränkungen zwischen den Meldungs- und Zustandsports auf der festgelegten Anzahl von Koordinator-Koordinationsschnittstellen. Eine Round-Robin-Koordinationsklasse enthält Deskriptoren für den Koordinator-Koordinationsschnittstellentyp, ohne die Anzahl der Koordinator-Koordinationsschnittstellen und Anweisungen zum Aufbau von Bindungen und Beschränkungen zwischen Ports auf den Koordinator-Koordinationsschnittstellen anzugeben, wenn ein bestimmter Round-Robin-Koordinator erstellt wird.
5. Komponenten
Eine Komponente ist ein Sechser-Tuple (I; A; M; V; S; X) in dem:

• I ein Satz von Koordinationsschnittstellen ist.
• A ein Satz von Handlungs-Triplen ist.
• M ein Satz von Betriebsarten ist.
• V ein Satz von Variablen-Typen ist.
• S ein Satz von Subkomponenten ist.
• X ein Satz von Koordinatoren ist, die zum Anschluß der Subkomponenten aneinander und an die Koordinationsschnittstellen benutzt werden.

Handlungen innerhalb eines Koordinators sind ziemlich regulär, die große Anzahl von Handlungen kann daher mit einigen einfachen Ausdrücken beschrieben werden. Handlungen innerhalb einer Komponente sind jedoch häufig häufig verschieden, und es sind daher u.U. ausgeprägte Definitionen für jede individuelle Handlung erforderlich. Typisch werden die Handlungs-Triplen einer Komponente durch eine Tabelle mit drei Spalten dargestellt: eine für die Betriebsart, eine für den Auslöser und eine für den Handlungscode. Tabelle 3 zeigt einige beispielhafte Handlungen einer Komponente, welche Round-Robin-Koordination benutzen kann.
Tabelle 3.
Eine Komponente gleicht einem Koordinator auf verschiedene Weisen (zum Beispiel sind die Betriebsarten und Koordinationsschnittstellen in jeder praktisch gleich). Komponenten können interne Koordinatoren aufweisen, und wegen der internen Koordinatoren benötigen Komponenten nicht immer Bindungen oder Beschränkungen. In den folgenden Unterabschnitten werden verschiedene Komponentenaspekte im Detail beschrieben. Zu diesen Komponentenaspekten gehören variabler Geltungsbereich, Handlungstransparenz und Ausführungssemantiken für Handlungssysteme.
A. Variabler Geltungsbereich
Zur Verbesserung der Modularität einer Komponente sind alle Variablen, auf die durch eine Handlung innerhalb der Komponente zugegriffen wird, lokal mit Bezug auf die Handlung, lokal mit Bezug auf die direkt übergeordnete Komponente der Handlung, oder der Zugriff erfolgt durch die direkt übergeordnete Komponente der Handlung über Zustandsports in einer der Koordinationsschnittstellen der übergeordneten Komponente. Um die Variablen einer Komponente einer hierarchisch untergeordneten Komponente zur Verfügung zu stellen, müssen sie von der Komponente exportiert und dann von dem untergeordneten Teil der Komponente importiert werden.
B. Handlungstransparenz
Eine Handlung innerhalb einer Komponente kann entweder eine transparente oder eine opake Handlung sein. Transparente und opake Handlungen weisen jeweils unterschiedliche Aufrufsemantiken auf. Die internen Eigenschaften, d.h. Kontrollstrukturen, Variablen, Zustandsänderungen, Operatoren usw. von transparenten Handlungen sind sichtbar für alle koordinationszentrischen Designtools. Die Designtools können alle internen Eigenschaften von opaken Handlungen voneinander trennen, beobachten und analysieren. Opake Handlungen sind Quellencode. Opake Handlungen müssen direkt ausgeführt werden und können, was ihre internen Eigenschaften anbetrifft, nur durch traditionelle Fehlersuchtechniken auf Quellenebene ausgeführt werden. Eine opake Handlung muß ausdrücklich alle Betriebsartänderungen und Koordinationsschrittstellen erklären, auf die die opake Handlung einen Einfluß ausüben kann.
C. Handlungsausführung
Eine Handlung wird durch ein Ereignis, wie die Ankunft, oder der Abgang von Daten an bzw. von einem Meldungsport, oder durch Wertänderungen, die an einem Zustandsport vorgenommen werden, ausgelöst. Eine Handlung kann den Wert eines Zustandsports ändern, ein Ereignis erzeugen und dem Softwaresystem eine Lösung zur Zusammenwirkung mit Gerätetreibern einer niedrigen Ebene bieten. Da Handlungen typisch Ereignisse erzeugen, kann sich ein einziger Auslöser durch eine Folge von Handlungen fortpflanzen.
6. Protokolle, die mit Koordinationsklassen implementiert werden
In diesem Abschnitt beschreiben wir mehrere Koordinatoren, die individuell einige allgemein verwendeten Protokolle implementieren: Subsumption, Barrierensynchronisation, Rendezvous und dediziertes RPC.
A. Subsumptionsprotokoll
Ein Subsumptionsprotokoll ist ein Priorität-basiertes, preemptives Ressourcenzuweisungsprotokoll, das allgemein im Bau von kleinen eigenständigen Robotern zum Einsatz kommt, wobei die gemeinsame Ressource der Roboter selbst ist.
7 zeigt einen Satz von Koordinationsschnittstellen und einen Koordinator zum Implementieren des Subsumptionsprotokolls. In 7 hat ein Subsumptionskoordinator 700 einen Satz von Subsumptionskoordinator-Koordinationsschnittstellen 702, die einen Subsumier-arbitrierten Koordinator-Kontrollport 704 und einen eingehenden Subsumier-Meldungsport 796 aufweisen. Jede Subsumier-Komponente 708 hat eine Subsumier-Komponenten-Koordinationsschnittstelle 710. Die Subsumier-Komponenten-Koordinationsschnittstelle 710 hat einen Subsumier-arbitrierten Komponenten-Kontrollport 712 und einen ausgehenden Subsumier-Meldungsport 714. Der Subsumptionskoordinator 700 und jede Subsumier-Komponente 708 sind über ihre betreffenden Koordinationsschnittstellen 702 und 710 miteinander verbunden. Jede Subsumptionskoordinator-Koordinationsschnittstelle 702 im Subsumptionskoordinator 700 ist mit einer Prtorität verknüpft. Jede Subsumier-Komponente 708 weist ein Verhalten auf, das an einen Roboter (nicht dargestellt) angelegt werden kann. Jede Subsumier-Komponente 708 kann jederzeit versuchen, ihr Verhalten auf dem Roboter geltend zu machen. Das geltend gemachte Verhalten, das von der Subsumier-Komponente 708 kommt, die an die Subsumptionskoordinator-Koordinationsschnittstelle 702 mit der höchsten Prtorität angeschlossen ist, ist das geltend gemachte Verhalten, welches tatsächlich vom Roboter ausgeführt wird. Subsumierkomponenten 708 brauchen nichts über andere Komponenten im System zu wissen. Jede Subsumier-Komponente ist so konstruiert, daß sie unabhängig funktioniert, egal ob ihr geltend gemachtes Verhalten durchgeführt oder ignoriert wird.
Der Subsumptionskoordinator 700 hat weiterhin eine Slave-Koordinator-Koordinationsschnittstelle 716, die einen ausgehenden Slave-Meldungsport 718 aufweist. Der ausgehende Slave-Meldungsport 718 ist an einen eingehenden Slave-Meldungsport 720 angeschlossen. Der eingehende Slave-Meldungsport 720 ist Teil einer Slave-Koordinationsschnittstelle 722, die an einen Slave 730 angeschlossen ist. Wenn eine Subsumier-Komponente 708 ein Verhalten geltend macht und diese Komponente höchste Priorität hat, steuert der Subsumptionskoordinator 700 Slave 730 (der typisch den Roboter steuert) aufgrund des geltend gemachten Verhaltens.
Die folgende Beschränkung beschreibt die Basis des Verhaltens des Subsumptionskoordinators 700:
Das bedeutet, daß wenn eine Subsumier-Komponente 708 einen Subsumier-arbitrierten Komponenten-Kontrollport 712 aufweist, welcher Port einen Wert von wahr hat, dann sind alle Subsumier-arbitrierten Komponenten-Kontrollports 712 mit niedrigerer Priorität auf falsch gesetzt. Ein wichtiger Unterschied zwischen Round-Robin und Subsumption besteht darin, daß bei Round-Robin das Ressourcenzugriffsrecht nur bei Aushändigung übertragen wird. Deshalb weist Round-Robin-Koordination kooperative Freigabe-Semantiken auf. Bei Subsumptionskoordination versucht jedoch eine Subsumier-Komponente 708, eine Ressource zu erhalten, wenn immer sie eine benötigt, und ist nur dann erfolgreich, wenn sie höhere Priorität als eine andere Subsumier-Komponente 708 besitzt, die die Ressource zur gleichen Zeit benötigt. Eine Subsumier-Komponente 708 niedrigerer Priorität, die bereits eine Ressource benutzt, muß die Ressource aushändigen, wenn eine Subsumier-Komponente 708 mit höherer Priorität versucht, auf die Ressource zuzugreifen. Subsumptionskoordination benutzt preemptive Freigabe-Semantiken, wobei jede Subsumier-Komponente 708 immer darauf vorvorbereitet sein muß, die Ressource aufzugeben. Tabelle 4 stellt das komplette Tuple für den Subsumptionskoordinator dar.
Tabelle 4
B. Barrierensynchronisationsprotokoll
Andere einfache Koordinationstypen, die Komponenten benutzen können, setzen Synchronisation von Aktivitäten durch. Ein Beispiel ist Barrierensynchronisation, wobei jede Komponente einen unabhängigen Synchronisationspunkt erreicht und wartet. 8 stellt einen Barrierensynchronisationskoordinator 800 dar. In 8 weist der Barrierensynchronisationskoordinator 800 einen Satz von Barrierensynchronisationsschnittstellen 802 auf, von denen jede einen Koordinator-arbitrierten Zustandsport 804, warten (wait) genannt, aufweist. Der Koordinator-arbitrierte Zustandsport 804 ist mit einem Komponenten-arbitrierten Zustandsport 806 verbunden, der Teil einer Komponentenkoordinationsschnittstelle 808 ist. Die Komponentenkoordinationsschnittstelle 808 ist mit einer Komponente 810 verbunden. Wenn alle Komponenten 810 ihre entsprechenden Synchronisationspunkte erreichen, werden sie alle des Wartens enthoben. Die Handlungen für einen Barrierensynchronisationskoordinator mit n Schnittstellen sind: Λ 0≤i<n waiti::∀0≤j<n – waitj
In anderen Worten, wenn alle Warte-Betriebsarten (nicht dargestellt) aktiv werden, wird jede einzelne freigegeben. Die Leerstelle zwischen den beiden Doppelpunkten zeigt an, daß das Auslöserereignis die Guard-Bedingung ist, die wahr wird.
C. Rendezvous-Protokoll
Ein der Barrierensynchronisation ähnliches Ressourcenzuweisungsprotokoll wird Rendezvous genannt. 9 zeigt einen Rendezvous-Koordinator 900 gemäß der vorliegenden Offenbarung. In 9 hat der Rendezvous-Koordinator 900 eine Rendezvous-Koordinationsschnittstelle 902, die einen Rendezvous-arbitrierten Zustandsport 904 aufweist. Ein Satz von Rendezvous-Komponenten 906, die jeweils verschiedene Funktionen durchführen oder ganz andere Handlungen und Betriebsarten haben können, hat eine Rendezvous-Komponenten-Koordinationsschnittstelle 908, zu der ein Komponenten-arbitrierter Zustandsport 910 gehört. Die Rendezvous-Komponenten 906 sind über ihre entsprechenden Koordinationsschnittstellen 908 und 902 mit Rendezvous-Koordinator 900 verbunden. Der Rendezvous-Koordinator 900 hat weiterhin eine Rendezvous-Ressourcen-Koordinationsschnittstelle 912, die einen Rendezvous-Ressourcen-arbitrierten Zustandsport 914, auch Available (Verfügbar) genannt, aufweist. Eine Ressource 916 hat eine Ressourcen-Koordinationsschnittstelle 918, die einen Ressourcen-arbitrierten Zustandsport 920 hat. Ressource 916 ist über die komplementären Koordinationsschnittstellen 918 bzw. 912 mit Rendezvous-Koordinator 900 verbunden.
Bei Rendezvous-artiger Koordination gibt es zwei Teilnehmertypen: Ressource 916 und mehrere Ressourcenbenutzer, hier Rendezvous-Komponenten 916. Wenn Ressource 916 verfügbar ist, aktiviert sie ihren Ressourcen-arbitrierten Zustandsport 920, auch als ihr verfügbarer Kontrollport bezeichnet. Wenn wartende Rendezvous-Komponenten 916 anstehen, wird eine auf die Ressource abgestimmt; dann werden beide Teilnehmer freigegeben. Der Unterschied zu Subsumption und Round-Robin besteht hier darin, daß Ressource 916 eine aktive Rolle im Protokoll spielt, indem sie ihren verfügbaren Kontrollport 920 aktiviert.
Die Handlungen für Rendezvous-Koordinator 900 sind:
available_i ∧ wait_j :: –available_i, –wait_j
(verfügbar_i ∧ warten_j :: –verfügbar_i, –warten_j)
Hier könnten auch andere Betriebsarten mit eingesetzt werden, die den Zustand nach dem Rendezvous anzeigen. Bei Rendezvous-Koordination ist wichtig, daß nur jeweils eine Komponente des Wartens (Warte-Betriebsart) enthoben wird.
D. Dediziertes RPC-Protokoll
Eine Koordinationsklasse, die sich von den oben beschriebenen unterscheidet, ist dedizierte RPC. 10 stellt ein dediziertes RPC-System dar. In 10 hat ein dedizierter RPC-Koordinator 1000 eine RPC-Server-Koordinationsschnittstelle 1002 mit einem RPC-Server-importierten Zustandsport 1004, einem RPC-Server-Ausgabemeldungsport 1006 und einem RPC-Server-Eingangsmeldungsport 1008. Der dedizierte RPC-Koordinator 1000 ist an einen Server 1010 angeschlossen. Server 1010 hat eine Koordinationsschnittstelle 1012, die einen Server-exportierten Zustandsport 1014, einen Server-Eingangsdatenport 1016 und einen Server-Ausgangsdatenport 1018 aufweist. Der dedizierte RPC-Koordinator 1000 ist über die zugehörigen komplementären Koordinationsschnittstellen 1002 bzw. 1012 an Server 1010 angeschlossen. Der dedizierte RPC-Koordinator 1000 weist weiterhin eine RPC-Client-Koordinationsschnittstelle 1020 auf, zu der ein RPC-Client-Zustandsport 1022, ein RPC-Client-Eingangsmeldungsport 1024 und ein RPC-Client-Ausgangsmeldungsport 1026 gehört. Der dedizierte RPC-Koordinator 1000 ist an einen Client 1028 angeschlossen, indem RPC-Client-Koordinationsschnittstelle 1020 mit einer komplementären Client-Koordinationsschnittstelle 1030 verbunden ist. Die Client-Koordinationsschnittstelle 1030 hat einen Client-exportierten Zustandsport 1032, einen Client-Ausgangsmeldungsport 1034 und einen Client-Eingangsmeldungsport 1036.
Das dedizierte RPC-Protokoll hat ein Client/Server Protokoll, in dem Server 1010 einem einzigen Client zugeordnet ist, in diesem Fall Client 1028. Im Gegensatz zu den Beispielen für das Ressourcenzuweisungsprotoll ist das temporale Verhalten dieses Protokolls der wichtigste Faktor beim Definieren. Die folgende Transaktionsauflistung beschreibt dieses temporale Verhalten:
Client 1028 tritt in die blockierte Betriebsart ein, indem der im Client-exportierten-Zustandsport 1032 gespeicherte Wert zu wahr geändert wird.
Client 1028 sendet eine Argumentdatenmeldung über Client Ausgangsmeldungsport 1034 an Server 1010.
Server 1010 empfängt die (mit „a" beschriftete) Argumentdatenmeldung über Server-Eingangsdatenport 1016 und tritt in die Bedien-(Serving-)Betriebsart ein, indem der im Server-exportierten-Zustandsport 1014 gespeicherte Wert zu wahr geändert wird.
Server 1010 berechnet den Rügabewert.
Server 1010 sendet eine (mit „r" beschriftete) Rückgabemeldung über Server-Ausgangsdatenport 1018 an Client 1020 und verläßt die Bedien-Betriebsart, indem der im Server-exportierten-Zustandsport 1014 gespeicherte Wert zu falsch geändert wird.
Client 1028 empfängt die Rückgabedatenmeldung über Client-Eingangsmeldungsport 1036 und verläßt die blockierte Betriebsart, indem der im Client-exportierten-Zustandsport 1032 gespeicherte Wert zu falsch geändert wird.
Dies kann in knapperer Form durch folgenden Ausdruck dargestellt werden, der kausale Beziehungen beschreibt: TRPC = +client.blocked → client.tränsmits → +server.serving → server.transmits → (–server.serving || client.receives) → –client.blocked
Die obigen Transaktionen beschreiben, was passieren müßte. Andere Eigenschaften dieses Protokolls müssen mit temporalen logischen Prädikaten beschrieben werden.
server.serving ⇒ server.blocked
server.serving ⇒ F(server.r.output)
server.a.input ⇒ F(server.serving)
Das r in server.r.output bezieht sich auf den Server-Ausgangsdatenport 1018, auch als r Ereignisport auf dem Server bezeichnet, und das a in serving.a.input bezieht sich auf den Server-Eingangsdatenport 1016, auch als a Port auf dem Server bezeichnet (siehe 10).
Zusammengenommen zeigen diese Prädikate an, daß (1) es ein Fehler für Server 1010 ist, in der Bedien-Betriebsart zu sein, wenn Client 1028 nicht blockiert ist; (2) nach dem Eintritt von Server 1010 in die Bedien-Betriebsart eine Antwortmeldung gesendet wird oder sonst ein Fehler eintritt; und (3) der Empfang einer Meldung durch Server 1010 bedeutet, daß Server 1010 in die Bedien-Betriebsart eintreten muß. Die Beziehungen zwischen Kontrollzustand und Datenpfaden müssen ebenfalls in Betracht gezogen werden, zum Beispiel:
(client.a ⇒ client.blocked)
In anderen Worten, Client 1028 muß sich in der blockierten Betriebsart befinden, wenn immer er eine Argumentmeldung sendet.
Das erste Prädikat hat die gleiche Form wie eine Beschränkung; da jedoch der dedizierte RPC-Koordinator 1000 nur die Betriebsarten client:blocked und server:serving importiert (d.h. durch RPC-Client-importierten-Zustandsport 1022 bzw. RPC-Server-importierten-Zustandsport 1004), ist dem dedizierten RPC-Koordinator 1000 nicht erlaubt, diese Werte zu ändern um sich anzupassen. Keins dieser Prädikate wird nämlich ausdrücklich von einem Laufzeitsystem durchgesetzt. Die letzten beiden können jedoch als Erfordernisse und Garantien zur Schnittstellentyprüfung verwendet werden.
7. Systemebenen-Ausführung
Die koordinationszentrische Design-Methotodologie läßt zu, daß Systemspezifikationen direkt gemäß der oben beschriebenen Semantiken ausgeführt werden. Wenn Komponenten und Koordinatoren jedoch zu Strukturen höherer Ordnung zusammengesetzt werden, ist sehr wichtig, daß Risiken in Betracht gezogen werden, die das Systemverhalten beeinflussen können. Zu Beispielen gehören konfliktierende Beschränkungen, wobei lokale Lösungssemantiken das System entweder in einen inkonsistenten Zustand oder in einen dauernden zyklischen Umlauf versetzen, und konfliktierende Handlungen, die gegenseitig ihr Verhalten aufheben. Im restlichen Teil dieses Abschnittes wird die Wirkung von Kompositionsbelangen auf Systemebenen-Ausführungen erklärt.
A. Systemkontrollkonfigurationen
Eine Konfiguration ist der kombinierte Kontrollzustand eines Systems – im Grunde genommen der Satz von aktiven Betriebsarten zu einem bestimmten Zeitpunkt. In anderen Worten, eine Konfiguration bei koordinationszentrischem Design ist ein Bit-Vektor, der ein Bit für jede Betriebsart im System enthält. Das einen Kontrollzustand darstellende Bit ist wahr, wenn der Kontrollzustand aktiv ist, und falsch, wenn der Kontrollzustand inaktiv ist. Konfigurationen, die den gesamten Systemkontrollzustand darstellen, erleichtern die Beweisführung über Systemzustände und ermöglichen mehrere Formen statischer Systemverhaltensanalyse.
B. Handlungsauslöser-Fortpflanzung
Auslöser sind formelle Parameter für Ereignisse. Wie früher erwähnt, gibt es zwei Arten von Auslöser: (1) Kontrollauslöser, die von Kontrolleignissen wie Anforderungen zur Betriebsartänderung aufgerufen werden, und (2) Datenflußauslöser, die von Ereignissen wie Meldungseingängen oder Meldungsabgängen aufgerufen werden. Komponenten und Koordinatoren können sowohl Betriebsartänderungen (für die für sie sichtbaren Betriebsarten) anfordern und neue Meldungen (an den für sie sichtbaren Meldungsports) erzeugen. Bei Einsatz von Handlungen können diese Ereignisse durch die Komponenten und Koordinatoren im System fortgepflanzt werden, wodurch ein Schwall von Datenübertragungen und Betriebsartänderungs-Anforderungen verursacht wird, von denen einige andere Anforderungen stornieren können. Wenn die Anforderungen, und die von ihnen implizierten sekundären Anforderungen, sämtlich durch das System hindurch fortgepflanzt werden, werden alle noch nicht stornierten Anforderungen bestätigt und in die neue Konfiguration des Systems aufgenommen.
Auslöser können sofort durch ihre jeweiligen Handlungen fortgepflanzt oder durch einen Planungsschritt verzögert werden. Man erinnere sich, daß Komponentenhandlungen entweder transparent oder opak sein können. Transparente Handlungen bewirken eine sofortige Fortpflanzung ihrer Auslöser, obwohl dies für sie nicht absolut notwendig ist. Opake Handlungen müssen typisch die Fortpflanzung immer verzögern.
1. Sofortige Fortpflanzung
Einige Auslöser müssen sofort durch Handlungen, aber nur durch bestimmte Typen von tranparenten Handlungen, fortgepflanzt werden. Sofortige Fortpflanzung kann oft die statische Vorberechnung der Auswirkung von Änderungen beinhalten, was bedeutet, daß bestimmte Handlungen nie tatsächlich ausgeführt werden. Zum Beispiel betrachte man ein System mit einem Koordinator, der eine Handlung aufweist, die Betriebsart A aktiviert, und einen Koordinator mit einer Handlung, die Betriebsart B bei jedem Aktivieren von A deaktiviert. Mit Hilfe von statischer Analyse kann im Voraus bestimmt werden, daß jedes Ereignis, das A aktiviert, auch Ereignis B deaktiviert; folglich kann diese Auswirkung sofort ausgeführt werden, ohne es tatsächlich durch A hindurch fortzupflanzen.
2. Verzögerte Fortpflanzung
Auslöser-Fortpflanzung durch opake Handlungen muß typisch verzögert sein, da das System opake Handlungen nicht einsehen kann, um ihre Ergebnisse im Voraus zu berechnen. Die Verzögerung der Fortpflanzung kann auch andere Gründe haben, wie zum Beispiel Systemeffizienz. Zum Beispiel erfordert sofortige Fortpflanzung eine enge Synchronisierung unter Softwarekomponenten. Wenn die Funktionalität auf eine Anzahl von architektonischen Komponenten aufgeteilt wird, ist sofortige Fortpflanzung unpraktisch.
C. Ein Protokoll, das mit mit einem zusammengesetzten Koordinator implementiert wird
Für das Design eines Systems werden typisch mehrere Koordinatoren benötigt. Die mehreren Koordinatoren können zusammen im Interesse eines einzigen, vereinigten Verhaltens benutzt werden. Leider kann ein Koordinator das Verhalten eines anderen stören.
11 zeigt einen kombinierten Koordinator 1100 mit sowohl preemptiver als auch Round-Robin-Koordination, um den Zugriff auf eine Ressource, wie oben beschrieben, zu kontrollieren. In 11 benutzen die Komponenten 1102, 1104, 1106, 1108 und 1110 vorwiegend Round-Robin-Koordination, und jede enthält eine Komponenten-Koordinationsschnittstelle 1112, die einen Komponenten-arbitrierten Kontrollport 1114 und einen Komponenten-Ausgangsmeldungsport 1116 umfaßt. Wenn jedoch eine Preemptor-Komponente 1120 eine Ressource benötigt, ist der Preemptor-Komponente 1120 erlaubt, die Ressource sofort zu beanspruchen. Preemptor-Komponente 1120 hat eine Preemptor-Komponenten-Koordinationsschnittstelle 1122. Preemptor-Komponenten-Koordinationsschnittstelle 1122 hat einen Preemptor-arbitrierten Zustandsport 1124, einen Preemptor-Ausgangsmeldungsport 1126 und einen Preemptor-Eingangsmeldungsport 1128.
Alle Komponenten-Koordinationsschnittstellen 1112 und Preemptor-Komponenten-Koordinationsschnittstellen 1122 sind an eine komplementäre kombinierte Koordinator-Koordinationsschnittstelle 1130 angeschlossen, die einen Koordinator-arbitrierten Zustandsport 1132, einen Koordinator-Eingangsmeldungsport 1134 und einen Koordinator-Ausgangsmeldungsport 1136 aufweist. Der kombinierte Koordinator 1100 ist ein hierarchischer Koordinator mit einem internen Round-Robin-Koordinator (nicht dargestellt) und einen preemptiven Koordinator (nicht dargestellt). Die kombinierte Koordinator-Koordinationsschnittstelle 1130 ist an eine Koordinationsschnittstelle zu Round-Robin 1138 und an eine Koordinationsschnittstelle zu Preempt 1140 angeschlossen. Der Koordinator-arbitrierte Zustandsport 1132 ist sowohl an einen Token-arbitrierten Kontrollport 1142, der Teil der Koordinationsschnittstelle zu Round-Robin 1138 ist, und an einen Preempt-arbitrierten Kontrollport 1144, der Teil der Koordinationsschnittstelle zu Preempt 1140 ist, gebunden. Koordinator-Eingangsmeldungsport 1134 ist an eine Schnittstelle zu Round-Robin-Ausgangsmeldungsport 1146 gebunden, und Koordinator-Ausgangsmeldungsport 1136 ist an eine Schnittstelle zu Round-Robin-Eingangsmeldungsport 1148 gebunden.
Somit stört Preemption die normale Round-Robin-Zugriffsreihenfolge auf die Ressource. Nach einem Preemptions-basierten Zugriff geht die Ressource zu der Komponente, die bei Round-Robin-Zugriffsreihenfolge der Nachfolger zu Preemptor-Komponente 1120 wäre. Wenn Preemption der Ressource zu oft erfolgt, müssen manche Komponenten hungern.
D. Mischen von Kontrolle und Daten in Koordinatoren
Da Auslöser auf Kontrollen oder auf Daten oder auf beiden basieren können, und Handlungen sowohl Kontroll- als auch Datenereignisse erzeugen können, sind Kontroll- und Datenflußaspekte eines Systems durch Handlungen gekoppelt. Indem sie Handlungen kombinieren, können Designer wirksam modalen Datenfluß erzielen, wobei relative Pläne aufgrund der Systemkonfiguration ein- und ausgeschaltet werden.
Relative Planung ist eine Form von Koordination. Diese Erkenntnis und ein Verständnis dafür, wie sie sich auf ein Design auswirkt, kann eine mächtige Klasse von Optimierungen ermöglichen. Viele datenzentrische Systeme (oder Subsysteme) benutzen konjunktives „Feuern" (Firing), was bedeutet, daß eine Komponente Meldungen so lange puffert, bis Übereinstimmung mit einer Firing-Regel gefunden wird. Bei Übereinstimmung „feuert" die Komponente und konsumiert die Meldungen in ihrem Puffer, die das Feuern verursachten, und erzeugt selbst eine oder mehrere Meldungen. Synchrone Datenflußsysteme sind solche, in denen alle Komponenten nur Feuerungsregeln mit konstantem Meldungskonsum und -erzeugung haben.
12A zeigt ein System, in dem eine Komponente N1 1200 durch einen Datenübertragungskoordinator 1204 an eine Komponente N3 1202 und eine Komponente N2 1206 über einen zweiten Datenübertragungskoordinator 1208 an Komponente N3 1202 angeschlossen ist. Komponente N3 1202 feuert, wenn sie drei Meldungen an einem Port c 1210 und zwei Meldungen an einem Port d 1212 kumuliert hat. Nach dem Feuern erzeugt Komponente N3 1202 zwei Meldungen an einem Port o 1214. Der Koordinationskontrollzustand verfolgt die logische Puffertiefe dieser Komponenten. Dies wird durch Nummern dargestellt, die die logische Wartenschlangentiefe jedes Ports in 12 darstellen.
12B zeigt das System von 12A, in dem der Datenübertragungskoordinator 1204 und der zweite Datenübertragungskoordinator 1208 zusammengelegt wurden, um einen zusammengelegten Datenübertragungskoordinator 1216 zu bilden. Das Zusammenlegen der Koordinatoren in diesem Beispiel stellt einen wirksamen statischen Plan für Komponenten-Feuern bereit. Der zusammengelegte Datenübertragungskoordinator 1216 feuert Komponente N1 1200 dreimal und Komponente N2 1206 zweimal. Der zusammengelegte Datenübertragungskoordinator 1216 feuert dann Komponente N3 1202 zweimal (um alle von Komponente N1 1200 und Komponente N2 1206 erzeugten Meldungen zu konsumieren).
Meldungsraten können von der Betriebsart her variieren. Zum Beispiel kann eine Komponente jedesmal, wenn sie in einer Betriebsart feuert, zwei Meldungen konsumieren, und jedesmal, wenn sie in einer zweiten Betriebsart feuert, vier Meldungen konsumieren.
Für eine Komponente wie diese ist es oft möglich, Pläne auf einer Konfigurationsbasis zusammenzulegen, bei der jede Konfiguration statische Konsum- und Produktionsraten für alle betroffenen Komponenten hat.
E. Koordinationstransformationen
Bei der Spezifierung kompletter Systeme müssen Designer oft nicht nur die Koordination zwischen zwei Objekten, sondern auch den Zwischenmechanismus spezifizieren, den sie zur Implementierung dieser Koordination benutzen müssen. Dieser Zwischenmechanismus kann lediglich ein gemeinsam benutzter Speicher sein, kann aber auch ein anderer Koordinator sein; demzufolge kann und ist die Koordination oft geschichtet. Zum Beispiel sitzt RPC-Koordination oft oben auf einem TCP/IP Stapel oder auf einem IrDA Stapel, in dem jede Schicht mit gleichartigen Schichten auf anderen Verarbeitungselementen unter Einsatz eindeutiger Koordinationsprotokolle zusammenwirkt. Hier stellt jede Schicht der Schicht direkt über ihr bestimmte Fähigkeiten bereit, und die oberste Schicht muß im Sinne dieser Schichten implementiert werden.
In vielen Fällen kann Kontroll- und Kommunikationssynthese verwendet werden, um benutzerspezifizierte Koordination automatisch in einen ausgewählten Satz von Standardprotokollen umzuwandeln. Für Nichtstandardprotokolle müssen Designer möglicherweise Umwandlungen manuell erzeugen.
F. Dynamisches Verhalten mit zusammengesetzten Koordinatoren
Selbst in statisch gebundenen Systemen müssen sich Komponenten möglicherweise in einer Weise gegenseitig beeinflussen, die dynamisch erscheint. Zum Beispiel hat RPC-Koordination oft mehrere Clients für einzelne Server. In diesem Fall gibt es keine augenscheinlichen Verbindungen zwischen Client und Server, bis eine Verbindung für eine Transaktion hergestellt wird. Nach Herstellen der Verbindung erfolgt die Koordination in gleicher Weise wie dedizierter RPC.
Bei unserem Ansatz wird der RPC-Server als gemeinsam genutzte Ressource benutzt, wobei Ressourcenzuweisungsprotokolle zur Kontrolle der Zuweisung benutzt werden. Keins der bis jetzt beschriebenen Ressourcenzuweisungsprotokolle würde unter diesen Umständen effizient funktionieren. In den folgenden Unterabschnitten soll ein geeignetes Protokoll beschrieben werden, das den RPC als gemein benutzte Ressource behandelt, und es wird besprochen, wie dieses Protokoll als Teil einer kompletten Multiclient-RPC-Koordinationsklasse benutzt werden sollte – einer Klasse, die die gleichen früher beschriebenen RPC-Koordinationsschnittstellen verwendet.
1. FCFS-Protokoll (First Come/First Serve)
13 veranschaulicht ein erstes FCFS-Ressourcenzuweisungsprotokoll, welches ein Protokoll ist, das dem Anfordernden, der am längsten gewartet hat, eine gemeinsam benutzte Ressource zuweist. In 13 weist eine FCFS-Komponentenschnittstelle 1300 für dieses Protokoll einen Anforderungskontrollport 1302, einen Zugriffskontrollport 1304 und einen Komponenten-Ausgangsmeldungsport 1306 auf. Ein FCFS-Koordinator 1308 für dieses Protokoll weist einen Satz von FCFS-Schnittstellen 1310 auf, die die FCFS-Komponentenschnittstellen 1300 komplementieren, da sie einen FCFS-Koordinator-Anforderungskontrollport 1312, einen FCFS-Koordinatorzugriffsport 1314 und einen FCFS-Koordinator-Eingangsmeldungsport 1316 aufweisen. Wenn eine Komponente 1318 auf eine Ressource 1320 zugreifen muß, macht sie Anforderungskontrollport 1302 geltend. Wenn Zugriff gewährt wird, macht FCFS-Koordinator 1308 den entsprechenden FCFS-Koordinatorzugriffsport 1314 geltend, wobei der FCFS-Koordinator-Anforderungskontrollport 1312 freigegeben wird.
Zu diesem Zweck benutzt FCFS-Koordinator 1308 einen Rendezvous-Koordinator und zwei Round-Robin-Koordinatoren. Einer der Round-Robin-Koordinatoren führt eine Liste leerer Slots, in denen eine Komponente in die Warteschlange gesetzt werden kann, während der andere Round-Robin-Koordinator eine Liste führt, die die nächste Komponente, der Zugriff zu gewähren ist, aufzeigt. Wenn ein FCFS-Koordinator-Anforderungskontrollport 1312 aktiv wird, startet FCFS-Koordinator 1308 einen Rendezvous-Zugriff auf eine Binder-Handlung. Bei Aktivierung bildet diese Handlung die entsprechende Komponente 1318 auf einer Position in den Round-Robin-Warteschlangen ab. Eine separate Handlung durchläuft eine der Warteschlangen und wählt die nächste Komponente aus, die auf den Server zugreifen soll. Soweit wie möglich versucht FCFS-Koordinator 1308, der frühesten Komponente 1318, die Ressource 1320 angefordert hat, Zugriff auf Ressource 1320 zu gewähren, wobei gleichzeitige Anforderungen aufgrund der Reihenfolge im Rendezvous-Koordinator der entsprechenden Komponenten 1318 bestimmt werden.
2. Multiclient RPC
14 zeigt einen Multiclient-RPC-Koordinator 1400, der durch Kombinieren des FCFS-Koordinators 1308 mit dem dedizierten RPC-Koordinator 1000 gebildet wird. In 14 hat ein Satz von Clients 1402 einen Satz von Client-Koordinationsschnittstellen 1030, wie in 10 abgebildet. Des weiteren weist Multiclient-RPC-Koordinator 1400 einen Satz von RPC-Client-Koordinationsschnittstellen 1020 auf, wie in 10 dargestellt. Für jede RPC-Client-Koordinationsschnittstelle 1020 ist der RPC-Client-Eingangsmeldungsport 1024 der RPC-Client-Koordinationsschnittstelle 1020 an den Komponenten-Ausgangsmeldungsport 1306 von FCFS-Koordinator 1308 gebunden. Die Meldungsübertragungshandlung 1403 dient zur Übertragung von Meldungen zwischen RPC-Client-Eingangsmeldungsport 1024 und Komponenten-Ausgangsmeldungsport 1306. Zur Koordination von Handlungen mehrerer Clients 1402 muß der Multiclient-RPC-Koordinator 1400 Zugriffe auf einen Server 1404 aushandeln und die vom Server 1404 zurückgegebenen Werte verfolgen.
G. Überwachungsbetriebsarten und Fortsetzungen
Merkmale wie Blockierungsverhalten und Ausnahmen können in der koordinationszentrischen Design-Methodologie mit Hilfe von Überwachungsbetriebsarten implementiert werden. Überwachungsbetriebsarten sind Betriebsarten, die alle Handlungen ausschließen mit Ausnahme eines ausgewählten Satzes von Handlungen, genannt Fortsetzungen, welches Handlungen sind, die ein von einer anderen Handlung gestartetes Verhalten fortsetzen.
1. Blockierungsverhalten
Bei Blockierungsverhalten gibt eine Handlung beim Eintritt in eine Überwachungsbetriebsart die Kontrolle frei, und eine Fortsetzung nimmt wieder die Ausführung nach dem vorweggenommenen Antwortereignis auf. Der Eintritt in die Überwachungsbetriebsart muß (zumindest lokal) sofort sein, damit keine unerwarteten Handlungen ausgeführt werden können, bevor sie von einer solchen Betriebsart blockiert werden.
Jede Überwachungsbetrtebsart hat eine Liste von Handlungen, die beim Eintritt in dieselbe nicht ausgeführt werden können. Die zulässigen (nicht aufgelisteten) Handlungen sind entweder irrelevant oder sind Fortsetzungen der Handlung, die den Eintritt in diese Betriebsart verursachte. Es liegen noch andere Bedingungen vor. Diese Betriebsart benötigt eine Ausnahme-Handlung, wenn sie zum Verlassen gezwungen wird. Diese Ausnahme-Handlung wird jedoch nicht ausgeführt, wenn die Überwachungsbetrtebsart lokal ausgeschaltet wird.
Wenn Komponenten über eine Anzahl von Verarbeitungselementen verteilt werden, ergibt die komplette Synchronisation des Kontrollzustands keinen Sinn. Es gibt eine Anzahl verfügbarer Synchronisationsoptionen, wie in Chou, P. „Control Composition and Synthesis of Distributed Real-Time Embedded Systems", Ph. D. Dissertion, University of Washington, 1998, erklärt.
2. Ausnahme-Handhabung
Ausnahme-Handlungen sind eine Art von Fortsetzung. In der Überwachungsbetrtebsart sprechen Ausnahme-Handlungen auf unerwartete Ereignisse oder Ereignisse an, die Fehlerzustände anzeigen. Zum Beispiel kann der Multiclient-RPC-Koordinator 1400 ¬client.blocked an eine Überwachungsbetrtebsart binden und eine Ausnahme-Handlung auf +server.serving setzen. Dadurch wird bei jedem Arbeitsbeginn des Servers ein Fehler angezeigt, wenn der Client mit Bezug auf eine Antwort nicht blockiert ist.
B. Ein Beispiel eines kompletten Systems
15 veranschaulicht ein großes beispielhaftes System nach der koordinationszentrischen Design-Methodologie. Das große System in 15 ist ein bimodales digitales zellulares Netzwerk 1500. Netzwerk 1500 ist zur Hauptsache eine vereinfachte Version eines zellularen GSM-Netzwerks (globales mobiles Kommunikationssystem). Das Beispiel zeigt im Detail, wie die Teile eines koordinationszentrischen Designs zusammenwirken, und wie die Methodologie in der Praxis verwirklicht werden kann. Netzwerk 1500 hat zwei verschiedene Typen von Zellen – eine Oberflächenzelle 1502 (auch als Basisstation 1502 bezeichnet) und eine Satellitenzelle 1504. Diese Zellen unterscheiden sich voneinander nicht nur, was ihre physische Position betrifft, sondern auch in den Technologien, die sie zur gemeinsamen Nutzung von Netzwerk 1500 benutzen. Satellitenzellen 1504 benutzen eine CDMA-Technologie (Code Division Multiple Access) und Oberflächenzellen 1502 benutzen eine TDMA-Technologie (Time Division Multiple Access). Typisch werden für TDMA sieben Frequenzbänder und für CDMA ein Frequenzband reserviert. Das Ziel ist, die Kommunikation möglichst durch die kleineren TDMA-Zellen, hier Oberflächenzellen 1502, laufen zu lassen, weil der Strombedarf für CDMA-Zellen, hier Satellitenzelle 1504, mit der Anzahl der Benutzer der CDMA-Zelle steigt. Mobile Einheiten 1506 oder drahtlose Geräte können sich zwischen Oberflächenzellen 1502 bewegen, wobei sie horizontale Hand-Overs zwischen Oberflächenzellen 1502 benötigen. Mehrere Oberflächenzellen 1502 sind typisch an eine Vermittlungszentrale 1508 angeschlossen. Vermittlungszentrale 1508 ist typisch an ein Telefonnetz oder das Internet 1512 angeschlossen. Zusätzlich zu Hand-Overs zwischen Oberflächenzellen 1502 muß das Netzwerk in der Lage sein, Hand-Overs zwischen Vermittlungszentralen vorzunehmen. Auch wenn mobile Einheiten 1506 die TDMA-Region verlassen, werden sie nach wie vor von Satellitenzellen 1504 durch vertikale Hand-Overs zwischen Zellen abgedeckt. Da für vertikale Hand-Overs Protokollwechsel sowie Basisstationswechsel und Vermittlungszentralenwechsel erforderlich ist, können sie, was die Kontrolle anbelangt, kompliziert sein.
Zahlreiche eingebetteten Systeme machen das Gesamtsystem aus. Zum Beispiel werden Vermittlungszentrale 1508 und Basisstationen – Oberflächenzellen 1502 – als Teil der Netzwerk-Infrastruktur benötigt, aber Handys, Handheld-Webbrowser und andere mobile Einheiten 1506 können, was Zugriff anbelangt, von Netzwerk 1500 betreut werden. Dieser Abschnitt konzentriert sich auf die Softwaresysteme für zwei bestimmte mobile Einheiten 1506: ein einfaches digitales Handy (in 16 dargestellt) und einen Handheld-Webbrowser (in 24 dargestellt). Diese Beispiele benötigen eine breite Vielfalt von Koordinatoren und wiederholt einsetzbaren Komponenten. Geschichtete Koordination ist ein Merkmale in jedem System, weil eine Funktion vieler Subsysteme darin besteht, ein geschichtetes Protokoll auszuführen. Des weiteren zeigt dieses Beispiel, wie die hierarchisch aufgebauten Komponenten in einem realistischen System eingesetzt werden können, um die Komplexität des Gesamtdesigns zu managen.
Die Diskussion beginnt mit einer Beschreibung des Handys, wobei der Schwerpunkt auf den funktionellen Handy-Komponenten und auf der Formalisierung der Wechselwirkungsprotokolle für diese substantiven Komponenten liegt. Danach wird der Handheld-Webbrowser beschrieben, wobei vor allem die Teile behandelt werden, in denen sich seine Funktionalität und Koordination von denen des Handys unterscheidet.
A. Handy
16 veranschaulicht ein Top-Level-Koordinationsdiagramm des Verhaltens eines Handys 1600. Anstatt einen einzelnen Koordinator zu benutzen, der die Komponenten nach einem einzelnen Protokoll integriert, verwenden wir mehrere Koordinatoren, die zusammenwirken.
In 16 unterstützt Handy 1600 digitale Kodierung von Sprechströmen. Jede Komponente von Handy 1600 ist hierarchisch. Eine GUI 1602 erlaubt dem Benutzer, Telefonnummern bei gleichzeitiger Anzeige einzugeben und ein Adreßbuch 1604 und eine Protokoll-Komponente 1606 abzufragen. Adreßbuch 1604 ist eine Datenbank, die Namen auf Telefonnummern und umgekehrt abbilden kann. GUI 1602 benutzt Adreßbuch 1604 zur Identifikation von Anrufern und zum Nachschlagen von Telefonnummern, die gewählt werden sollen. Protokolle 1606 verfolgen sowohl eingehende als auch ausgehende Anrufe während des Wählens. Eine Sprechkomponente 1608 kodiert und dekodiert, und komprimiert und entkomprimiert, digital ein Audiosignal. Eine Verbindungskomponente 1610 multiplext, sendet, empfängt und demultiplext das Funksignal und sondert den Sprechstrom und die Anruferidentifikationsinformation voneinander ab.
Bei der Koordination der obigen Komponenten kommen mehrere der oben beschriebenen Koordinatoren zum Einsatz. Zwischen Verbindungskomponente 1610 und einer Uhr 1612 und zwischen Protokollen 1606 und Verbindungskomponente 1610 befinden sich unidirektionale Datenübertragungskoordinatoren 600, wie mit Bezug auf 6A beschrieben. Zwischen Sprechkomponente 1608 und Verbindungskomponente 1610, und zwischen GUI 1602 und Verbindungskomponente 1610 liegen bidirektionale Datenübertragungskoordinatoren 604, wie mit Bezug auf 6B beschrieben. Zwischen Uhr 1612 und GUI 1602 liegt ein Zustandsvereinigungskoordinator 606, wie mit Bezug auf 16C beschrieben. Zwischen GUI 1602 und Adreßbuch 1604 liegt ein dedizierter RPC- Koordinator 1000, wie mit Bezug auf 10 beschrieben, wobei das Adreßbuch 1604 Client 1028 und GUI 1602 Server 1010 enthält.
Ferner liegt ein kundenspezifischer GUI/Protokoll-Koordinator 1614 zwischen Protokollen 1606 und GUI 1602. GUI/Protokoll-Koordinator 1614 erlaubt GUI 1602, neu protokollierte Information über einen r Ausgangsmeldungsport 1616 auf einer GUI-Koordinationsschnittstelle 1618 an einen r Eingangsmeldungsport 1620 auf einer Protokoll-Koordinationsschnittstelle 1622 zu übertragen. GUI/Protokoll-Koordinator 1614 erlaubt GUI 1602 ferner, aktuelle Protokolleinträge über ein Paar von c Ausgangsmeldungsports 1624 auf GUI-Koordinationsschnittstelle 1618 und ein Paar von c Eingangsmeldungsports 1626 auf Protokoll-Koordinationsschnittstelle 1622 zu wählen. Protokolle 1606 zeigen laufend je einen Eintrag für eingehende und ausgehende Anrufe an.
1. GUI-Komponente
17A ist eine detaillierte Ansicht von GUI-Komponente 1602 von 16. In 17A hat GUI-Komponente 1602 zwei Innenkomponenten, ein Tastenfeld 1700 und eine textbasierte Flüssigkristallanzeige 1702 sowie mehrere eigene Funktionen (nicht dargestellt). Bei jedem Tastendruck wird eine Handlung ausgelöst, die den Druck, abhängig von der Betriebsart des Systems, interpretiert. Zahlreiche Tastendrücke geben Werte in einen gemeinsam benutzten Wählpuffer ein. Nach Eingabe einer kompletten Nummer wird der Inhalt dieses Puffers dazu benutzt, eine neue Verbindung durch Verbindungskomponente 1610 einzurichten. Tabelle 5 zeigt die Handlungstriplen für GUI 1602.
Tabelle 5
Ein „Addr Coord" Koordinator 1704 enthält eine Adreßbuch-Betriebsart (nicht dargestellt), in der Pfeiltastendrücke in RPC-Anrufe umgewandelt werden.
2. Protokoll-Komponente
17B ist eine detaillierte Ansicht von Protokoll-Komponenten 1606, die alle eingehenden und ausgehenden Anrufe verfolgen. In 17B müssen sowohl GUI-Komponente 1602 als auch Verbindungskomponente 1610 mit Protokoll-Komponente 1606 über spezifische Meldungsports kommunizieren. Diese spezifischen Meldungsports enthalten einen Sendenummer-Meldungsport 1720, einen Empfangsnummer-Meldungsport 1722, einen Port 1724 zum Ändern der aktuell empfangenen Meldung, einen Port 1726 zum Ändern der aktuell gesendeten Meldung und zwei Zustandsports 1728 und 1729 zur Anzeige der aktuell empfangenen bzw. aktuell gesendeten Werte.
Protokollkomponente 1606 enthält zwei identische Einzelprotokoll-Komponenten: ein Sendeprotokoll 1730 für ausgehende Anrufe und ein Empfangsprotokoll 1740 für eingehende Anrufe. Die Schnittstelle der Protokollkomponenten 1606 ist über ein Paar von Adapter-Koordinatoren – Adap1 1750 und Adap2 1752 – an die individuellen Protokollkomponenten angeschlossen. Adap1 1750 hat eine Adapter-Empfangsschnittstelle 1754, die einen Port 1756 zum Empfangen des importierten Zustands und einen Port 1758 zum Empfangen einer Ausgangsmeldung aufweist. Adap1 1750 weist ferner eine Adapter-Sendeschnittstelle 1760 auf, die einen Port 1762 zum Senden des importierten Zustands und einen Port 1764 zum Senden der Ausgangsmeldung hat. Innerhalb von Adap1 ist Zustandsport 1728 an Port 1756 zum Empfangen des importierten Zustands gebunden, Port 1724 zum Ändern der aktuell empfangenen Meldung ist an Port 1758 zum Empfangen der Ausgangsmeldung gebunden, Empfangsnummer-Meldungsport 1722 ist an einen Empfangsschnittstelle-Ausgangsmeldungsport 1766 auf einer Empfangsnummer-Koordinationsschnittstelle 1768 gebunden, Port 1726 zum Ändern der aktuell gesendeten Meldung ist an Port 1764 zum Senden der Ausgangsmeldung gebunden, und Zustandsport 1729 ist an Up·rc zum Senden des importierten Zustands gebunden.
3. Sprechkomponente
18A ist eine detaillierte Ansicht von Sprechkomponente 1608 von 16. Sprechkomponente 1608 hat eine Komprimierungskomponente 1800 zum Komprimieren der digitalisierten Sprechsignale vor der Übertragung, eine Entkomprimierungskomponente 1802 zum Entkomprimieren der empfangenen digitalisierten Sprechsignale, und Schnittstellen 1804 und 1806 mit analogen Wandlern (nicht dargestellt) zum Digitalisieren von zu übertragendem Ton und zum Konvertieren von empfangenen Übertragungen zu Ton. Sprechkomponente 1608 ist eine reine Datenflußkomponente, die einen Tongenerator 1808, der als Weißrauschgenerator, als Rufzeichengenerator mit einem separaten Port für jeden auf Tongeneratorschnittstelle 1810 fungiert, und Sprechkomprimierungsfunktionalität in Form von Komprimierungskomponente 1800 und Entkomprimierungskomponente 1802 enthält.
4. Verbindungskomponente
18B ist eine detaillierte Ansicht von Verbindungskomponente 1608 von 16. In 18B arbeitet Verbindungskomponente 1610 mit Sprechkomponente 1608, Protokollkomponente 1606, Uhr 1612 und GUI 1602 zusammen. Des weiteren ist Verbindungskomponente 1610 verantwortlich für die Koordination des Verhaltens von Handy 1600 mit einer Basisstation, welcher die Oberflächenzelle 1502 (in 15 dargestellt), eine Vermittlungszentrale 1508 (in 15 dargestellt) und alle anderen Telefone (nicht dargestellt) innerhalb der Oberflächenzelle 1502 gehören. Verbindungskomponente 1610 muß wie erforderlich Benutzer authentifizieren, Verbindungen einrichten und Hand-Overs durchführen – einschließlich entsprechender Änderung in Low-Level-Protokollen (wie eine Umschaltung von TDMA zu CDMA).
19 veranschaulicht einen Satz von Kommunikationsschichten zwischen Verbindungskomponente 1610 von Handy 1600 und einer Basisstation 1502 oder Vermittlungszentrale 1508. 19 zeigt mehrere Subkomponenten, oder Lower-Level-Komponenten, von denen jede mit einer äquivalenten, oder gleichrangigen, Schicht auf entweder der Basisstation 1502 oder der Vermittlungszentrale 1508 koordiniert. Die Subkomponenten von Verbindungskomponente 1610 umfassen einen Handy-Anrufmanager 1900, einen Handy-Mobilitätsmanager 1902, einen Handy- Funkressourcenmanager 1904, einen Handy-Linkprotokollmanager 1906 und einen Handy-Transportmanager 1908, der für die Koordinierung des Zugriffs auf und die Übertragung von Daten über die gemeinsam benutzten Luftwellen TDMA und CDMA verantwortlich ist. Jede Subkomponente wird im Detail einschließlich ihrer Einbaustelle im System beschrieben.
Basisstation 1502 hat einen Anrufmanagementkoordinator 1910, einen Mobilitätsmanagementkoordinator 1912, einen Funkressourcenkoordinator 1914 (BSSMAP 1915), einen Linkprotokollkoordinator 1916 (SCCO 1917) und einen Transportkoordinator 1918 (MTP 1919). Vermittlungszentrale 1508 hat einen Vermittlungszentralen-Anrufmanager 1920, einen Vermittlungszentralen-Mobilitätsmanager 1922, ein BSSMAP 1924, ein SCCP 1926 und ein MTP 1928.
a. Anrufmanagement
20 ist eine detaillierte Ansicht einer Anrufmanagementschicht 2000, die aus Handy-Anrufmanager 1900 besteht, der über Anrufmanagementkoordinator 1910 an Vermittlungszentralen-Anrufmanager 1920 angeschlossen ist. In 20 koordiniert Anrufmanagementschicht 2000 den Anschluß zwischen Handy 1600 und Vermittlungszentrale 1508. Anrufmanagementschicht 2000 ist verantwortlich für Wählen, Funkruf (Paging) und Sprechen. Anrufmanagementschicht 2000 ist immer in Handy 1600, aber nicht unbedingt in (später besprochenen) Internet-Geräten anwesend. Handy-Anrufmanager 1900 beinhaltet einen Satz von Betriebsarten (nicht dargestellt) für Anrufmanagementkoordination, bestehend aus folgenden Betriebsarten:

• Standby (Bereitschaft)
• Dialing (Wählen)
• RingingRemote (entferntes Rufzeichen)
• Ringing (Rufzeichen)
• CallInProgress (Gespräch läuft)

Handy-Anrufmanager 1900 hat eine Handy-Anrufmanagerschnittstelle 2002. Handy-Anrufmanagerschnittstelle 2002 hat einen Port, der jedem der obigen Betrebsarten entspricht. Die Standby-Betriebsart ist an einen Standby-exportierten Zustandsport 2010 gebunden. Die Dialing-Betriebsart ist an einen Dialing-Exportzustandsport 2012 gebunden. Die RingingRemote-Betriebsart ist einen RingingRemote-importierten Zustandsport 2014 gebunden. Die Ringing-Betrtebsart ist an einen Ringing-importierten Zustandsport 2016 gebunden. Die CallinProgress-Betrtebsart ist an einen CallInProgress-arbitrterten Zustandsport 2018 gebunden.
Vermittlungszentralen-Anrufmanager 1920 beinhaltet die folgenden Betriebsarten (nicht dargestellt) für Anrufmanagementkoordination bei der Vermittlungszentrale:

• Dialing (Wählen)
• RingingRemote (entferntes Rufzeichen)
• Paging (Funkruf)
• CallInProgress (Gespräch läuft)

Vermittlungszentralen-Anrufmanager 1920 hat eine Vermittlungszentralen-Anrufmanager-Koordinationsschnittstelle 2040, die einen Port für jede der obigen Betriebsarten innerhalb Vermittlungszentralen-Anrufmanager 1920 beinhaltet.
Wenn Handy 1600 eine Verbindung anfordert, erstellt Vermittlungszentrale 1508 einen neuen Vermittlungszentralen-Anrufmanager und richtet einen Anrufmanagementkoordinator 1910 zwischen Handy 1600 und Vermittlungszentralen-Anrufmanager 1920 ein.
b. Mobilitätsmanagement
Eine Mobilitätsmanagementschicht authentifiziert die mobile Einheit 1506 oder das Handy 1600. Wenn eine Oberflächenzelle 1502 verfügbar ist, nimmt Mobilitätsmanager 1902 Kontakt mit der Vermittlungszentrale 1508 für Oberflächenzelle 1502 auf und überträgt eine mobile Einheitskennung (nicht dargestellt) für mobile Einheit 1506 an die Vermittlungszentrale 1508. Vermittlungszentrale 1508 schlägt eine mobile Home-Vermittlungszentrale für mobile Einheit 1506 nach und richtet einen Satz von Berechtigungen für die mobile Einheit 1506 ein. Diese Schicht fungiert auch als Leitkanal für die Anrufmanagementschicht. Des weiteren nimmt die mobile Managementschicht Hand-Overs zwischen Basisstationen 1502 und Vermittlungszentralen 1508 vor, die auf Information beruhen, die von der Funkressourcenschicht empfangen wurde.
c. Funkressource
In der Funkressourcenschicht wählt der Funkressourcenmanager 1904 die Zielbasisstationen 1502 und verfolgt die Änderungen in den Frequenzen, Zeitscheiben und CDMA-Codes. Handys können mit maximal 16 Basisstationen gleichzeitig verhandeln. Diese Schicht identifiziert auch, wenn Hand-Overs vorzunehmen sind.
d. Linkprotokoll
Die Linkschicht managt eine Verbindung zwischen Handy 1600 und Basisstation 1502. In dieser Schicht verpackt Linkprotokollmanager 1906 Daten zur Übertragung an Basisstation 1502 von Handy 1600.
e. Transport
21A ist eine detaillierte Ansicht der Transportkomponente 1908 von Verbindungskomponente 1610. Transportkomponente 1908 hat zwei Subkomponenten, eine Empfangskomponente 2100 zum Empfangen von Daten und eine Sendekomponente 2102 zum Senden von Daten. Jede dieser Subkomponenten hat zwei parallele Datenpfade, einen CDMA-Pfad 2104 und einen TDMA/FDMA-Pfad 2106 zum Kommunizieren in den entsprechenden Netzwerkprotokollen.
21B ist eine detaillierte Ansicht eines CDMA-Modulators 2150, der einen synchronen Datenfluß-Datenpfad implementiert. CDMA-Modulator 2150 nimmt das Dotprodukt eines eingehenden Datensignals auf Pfad 2152 und einen gespeicherten Modulationscode für Handy 1600 auf Pfad 2154, welches eine Folge von Chips ist, bei denen es sich um gemessene Zeitsignale mit einem Wert von –1 oder +1 handelt.
Transportkomponente 1908 benutzt CDMA- und TDMA-Technologien, um Zugriff auf eine Ressource zu koordinieren, die sich mehrere Handys 1600 teilen, d.h. die Luftwellen. Transportkomponenten 1908 treten an Stelle der FDMA-Technologien (e.g. AM und FM), die für analoge Handys und für Radio- und Fernsehsendungen verwendet werden. In FDMA wird ein Signal durch Modulieren mit einer Trägerfrequenz für die Übertragung verkodet. Das Dekodieren des Signals erfolgt durch Demodulieren nach Passieren eines Bandpaßfilters zum Entfernen anderer Trägerfrequenzen. Jede Basisstation 1502 hat einen Satz von Frequenzen, die so gewählt werden, daß die Störungen zwischen aneinander angrenzenden Zellen auf ein Minimum reduziert werden. (Der von einer Zelle abgedeckte Bereich kann sehr viel kleiner sein als die Nettoreichweite der in ihm enthaltenen Sender.)
22 stellt TDMA- und CDMA-Signale für vier Handys 1600 dar. In 22 wird bei TDMA jedem Handy 1600 eine Zeitscheibe zugewiesen, während der es übertragen kann. Handy 1 gehört zu Zeitscheibe t0, Handy 2 zu Zeitscheibe t1, Handy 3 zu Zeitscheibe t2 und Handy 4 zu Zeitscheibe t3. Für CDMA wird jedem Handy 1600 ein Basisvektor zugewiesen, den es mit seinem Signal multipliziert. Die den Handys 1 bis 4 zugewiesenen Basisvektoren bilden eine orthogonale Basis.
B. Handheld Web-Browser
23A ist eine LCD-Touchscreen-Komponente 2300 für einen Web-Browser GUI (in 24A dargestellt) für ein drahtloses Gerät 1506. In 23A weist eine LCD-Touchscreen-Komponente 2300 einen LCD-Bildschirm 2302 und ein Touchpad 2304 auf.
23B ist eine Webseiten-Zugriffskomponente 2350 zum Holen und Formatieren von Webseiten. In 23B hat die Webzugriffskomponente 2350 eine Seitenhol-Subkomponente 2352 und eine Seitenformat-Subkomponente 2354. Webzugriffskomponente 2350 liest HTML (Hypertext Markup Language) von einer Verbindungsschnittstelle 2356, sendet Wortplazierungsanforderungen an eine Display-Schnittstelle 2358 und sendet Bildanforderungen an die Verbindungsschnittstelle 2356. Webzugriffskomponente 2350 hat ferner eine Schriftzeichen-Eingabeschnittstelle, damit Benutzer Seitenanforderungen direkt eingeben und Formulare auf Formulare enthaltenden Seiten ausfüllen können.
24A zeigt einen fertigen Handheld-Web-Browser GUI 2400. In 24A hat Handheld-Web-Browser GUI 2400 eine LCD-Touchscreen-Komponente 2300, eine Webzugriffskomponente 2350 und eine Schriftzug-Erkennungskomponente 2402, die auf dem Touchpad 2304 mit einem Stift eingegebene Schriftzüge in Schriftzeichen umsetzt.
24B zeigt die komplette Komponentenansicht eines Handheld-Web-Browsers 2450. In 24B ist der Handheld-Web-Browser 2450 dadurch gebildet, daß Handheld-Web-Browser-GUI 2400 mit der Verbindungskomponente 1610 von Handy 1600 (mit Bezug auf 16 beschrieben) mittels des bidirektionalen Datenübertragungskoordinators 604 (mit Bezug auf 6B beschrieben) verbunden wird. Handheld-Web-Browser 2450 ist ein Beispiel einer mobilen Einheit 1506 und ist über die oben beschriebene zellulare Infrastruktur an das Internet angeschlossen. Handheld-Web-Browser 2450 hat jedoch andere Zugriffsanforderungen als Handy 1600. Für Handheld-Web-Browser 2450 ist Zuverlässigkeit wichtiger als Echtzeitlieferung. Verlorengegangene Pakete müssen für gewöhnlich erneut übertragen werden, es ist deshalb besser, ein Paket mit Verspätung auszuliefern, als es zu verlieren. Echtzeitbelange wirken sich in erster Linie auf die Download-Zeit aus und sind deshalb zweitrangig. Trotzdem muß Handheld-Web-Browser 2450 den Medienzugriff mit Handys 1600 koordinieren, und er muß somit das gleiche Protokoll wie Handys 1600 benutzen, um sich an das Netzwerk anzuschließen. Aus diesem Grund kann Handheld-Web-Browser 2450 die Verbindungskomponente 1610 von Handy 1600 wiederholt benutzen.
Fehlersuchtechniken
Theoretisch betrachtet ist die Fehlersuche ein einfacher Prozess. Ein Designer stellt die Ursache eines unerwünschten Verhaltens in einem System fest und beseitigt die Ursache. In der Praxis bleibt die Fehlersuche, selbst bei sequentieller Software, schwierig. Bei eingebetteten Systemen ist im Gegensatz zu sequentieller Software die Fehlersuche beträchtlich schwieriger aufgrund solcher Faktoren wie Konkurrenz, verteilte Architekturen und Echtzeitbelange. Themen, die bei sequentieller Software als selbstverständlich hingenommen werden, wie z.B. ein Plan, der die Reihenfolge aller Ereignisse (das Programm) bestimmt, existieren nicht in einem verteilten System. Das Feststellen und Beseitigen von Fehlern in diesen komplexen Systemen unterliegt vielen Faktoren, einschließlich eines Verständnisses für die gedanklichen Prozesse, die das Design untermauern. Die zwei allgemeinen Klassen der Fehlersuchtechniken sind ereignisbasierte Fehlersuche und zustands-basierte Fehlersuche.
Ereignisse können primitiv sein, oder sie können hierarchische Clusters anderer Ereignisse sein. Primitive Ereignisse sind Abstraktionen individueller lokaler Geschehen, die wichtig für den Debugger (Fehlersuchgerät) sein können. Zu primitiven Ereignissen für verteilte Systeme gehören Meldungssende- und Meldungsempfangsereignisse. Ereignis-basierte Fehlersuchtechniken beruhen auf dem Sammeln von Ereignisspuren individueller Systemkomponenten und dem Finden eines kausalen Zusammenhangs für diese Ereignisspuren. Diese Techniken setzen eine Fähigkeit voraus, die kausale Reihenfolge in irgendeinem gegebenen Paar von Ereignissen effizient bestimmen zu können. Das Bestimmen der kausalen Reihenfolge in verteilten Systemen kann schwierig und teuer sein.
Zustands-basierte Fehlersuchtechniken kommen beim Ermitteln von Fehlern in verteilten Systemen weniger häufig zum Einsatz. Zustands-basierte Fehlersuchtechniken bestehen typisch darin, daß sie Designern Ansichten oder Schnappschüsse eines Prozeßzustands liefern. Verteilte Systeme sind nicht eng synchronisiert, und somit beinhalten diese Techniken traditionell nur den Zustand von individuellen Prozessen. Zustands-basierte Fehlersuchtechniken können jedoch allgemeiner angewandt werden, wenn man das Konzept eines "zeitlichen Augenblicks" derart lockert, daß es effizient auf asynchrone Prozesse angewandt werden kann.
1. Ereignis-basierte Fehlersuche
A. Bestimmung und Beobachtung der Ereignis-Reihenfolge
Die Bestimmung der Reihenfolge, in der Ereignisse in einem verteilten System vorkommen, unterliegt den Grenzen der Beobachtung. Eine Beobachtung ist die Ereignis-Aufzeichnung eines Beobachters. Ein Beobachter ist eine Entität, die die Abwicklung einer Ausführung beobachtet und Ereignisse aufzeichnet, aber nicht in das Sytem eingreift. Um die Reihenfolge, in der zwei Ereignisse eintreten, zu bestimmen, muß der Beobachter beide mit Bezug auf eine gemeinsame Bezugslinie messen.
25 veranschaulicht ein typisches Raum-/Zeitdiagramm 2500, wobei Raum auf einer vertikalen Achse 2502 und Zeit auf einer horizontalen Achse 2504 dargestellt wird. In 25 stellt das Raum-/Zeitdiagramm 2500 einen Startpunkt zur Besprechung von Ausführungen in verteilten Systemen bereit. Das Raum-/Zeitdiagramm 2500 bietet eine visuelle Darstellung zur Besprechung von Ereignis-Reihenfolgen und zum Vergleich verschiedener Beobachtungsstile. Ein Satz von horizontalen Weltlinien 2506, 2508 und 2510 stellen jeweils im Raum stationäre Entitäten dar. Die durch horizontale Weltlinien 2506, 2508 und 2510 dargestellten Entitäten werden Prozesse genannt und stellen typisch Softwareprozesse im besprochenen System dar. Die Entitäten können auch jede beliebige Entität darstellen, die Ereignisse auf sequentielle Art erzeugt. Eine diagonale Weltlinie 2512 wird eine Meldung genannt und stellt diskrete Kommunikationen zwischen zwei Prozessen dar. Eine Kugel 2514 stellt ein Ereignis dar. In nachfolgenden Figuren wurden vertikale Achse 2502 und horizontale Achse 2504 aus den Raum-/Zeitdiagrammen weggelassen, außer wenn dadurch eine bestimmte Figur mehr Klarheit erlangt.
26 veranschaulicht ein Raum-/Zeitdiagramm 2600 von zwei verschiedenen Beobachtungen einer Einzelsystem-Ausführung, die von einem ersten Beobachter 2602 und einem zweiten Beobachter 2604 vorgenommen wurden. In 26 sind der erste Beobachter 2602 und der zweite Beobachter 2604 Entitäten, die das Auftreten von Ereignissen beobachten. Der erste Beobachter 2602 und der zweite Beobachter 2604 müssen jeweils deutliche Benachrichtigungen über jedes auftretende Ereignis erhalten, und jeder muß alle Ereignisse in einer bestimmten Reihenfolge aufzeichnen. Der erste Beobachter 2602 und der zweite Beobachter 2604 sind im Raum-/Zeitdiagramm 2600 als zusätzliche Prozesse oder horizontale Weltlinien dargestellt. Für jedes aufgezeichnete Ereignis ist ein Signal von dem betreffenden Prozeß an sowohl den ersten Beobachter 2602 als auch den zweiten Beobachter 2604 zu senden. Die Signale eines Ereignisses x 2606 auf einem Prozeß 2608 an sowohl den ersten Beobachter 2602 als auch den zweiten Beobachter 2604 sind in den Meldungen 2610 bzw. 2612 verkörpert. Der erste Beobachter 2602 zeichnet Ereignis x 2602 als Ereignis auf, das einem Ereignis y 2614 vorausgeht. Der zweite Beobachter 2604 jedoch zeichnet Ereignis y 2614 als ein Ereignis auf, das Ereignis x 2606 vorausgeht. Solche Effekte können durch nicht-einheitliche Wartezeiten innerhalb des Systems verursacht werden.
Die Beobachtungen des ersten Beobachters 2602 und des zweiten Beobachters 2604 sind jedoch nicht im gleichen Maße gültig. Eine gültige Beobachtung ist typisch eine Beobachtung, die die Reihenfolge der Ereignisse einhält, die von einander abhängig sind. Der zweite Beobachter 2604 zeichnet den Erhalt einer Meldung 2616 auf, bevor diese Meldung gesendet wird. Somit ist die Beobachtung des zweiten Beobachters 2604 nicht gültig.
27 veranschaulicht ein Raum-/Zeitdiagramm 2700 für einen speziellen idealen Beobachter, genannt Echtzeit-Beobachter (RTO) 2702. In 27 kann RTO 2702 jedes Ereignis sofort bei seinem Eintritt einsehen. Aufgrund der Begrenzungen von physischen Uhren und den Wirksamkeitsfragen bei ihrem Einsatz ist es gewöhnlich unpraktisch, RTO 2702 einzusetzen. RTO 2702 stellt jedoch eine obere Genauigkeitsbegrenzung für die Bestimmung der Ereignis-Reihenfolge dar.
28 veranschaulicht einen Raum-/Zeit-Graph 2800, der zwei gültige Beobachtungen eines Systems zeigt, die von zwei separaten Beobachtern vorgenommen wurden: RTO 2702 und einem dritten Beobachter 2802. In 28 gibt es nichts Besonderes, was die Reihenfolge der von RTO 2702 vorgenommenen Beobachtung betrifft. Ereignisse d 2804, e 2806 und f 2808 sind sämtlich unabhängige Ereignisse in dieser Ausführung. Folglich kann die von RTO 2702 vorgenommene Beobachtung und die von dem dritten Beobachter 2802 vorgenommene Beobachtung jeweils dazu benutzt werden, äquivalente Ausführungen des Systems zu reproduzieren. Eine Beobachtung, in der Ereignis-Abhängigkeiten gewahrt werden, ist typisch im Wert gleich mit einer Beobachtung durch RTO 2702. Verteilte Echtzeitsysteme jedoch benötigen eventuell zusätzliche Prozesse, um zeitliche Beschränkungen nachzuahmen.
29 ist ein Raum-/Zeitdiagramm 2900 eines methodologischen Beobachters, genannt DLO (Discrete Lamport Observer) 2902, der jedes Ereignis in einem Satz von geordneten Behältern aufzeichnet. In 29 zeichnet DLO 2902 ein Ereignis 2904 in einem geordneten Behälter 2906 aufgrund der folgenden Regel auf: jedes Ereignis, welches auf alle Ereignisse folgt, von denen es abhängig ist, wird im Behälter ganz links aufgezeichnet. DLO 2902 betrachtet jedes Ereignis getrennt und benötigt keine Uhr. DLO 2902 benötigt jedoch gründliche Kenntnis der Ereignis-Abhängigkeit. Um den Behälter zu bestimmen, in den jedes Ereignis plaziert werden soll, muß DLO 2902 die Behälter der unmittelbar vorausgehenden Ereignisse kennen. Die von DLO 2902 vorgenommene Beobachtung wird auch als eine Art topologische Darstellung des Ereignis-Graphen der Systemausführung bezeichnet.
Jedes Ereignis hat höchstens zwei unmittelbare Vorgänger. Deshalb muß DLO 2901 nur die Behälter von höchstens zwei Aufzeichnungen vor jeder Plazierung finden. Die transitive Schließung der unmittelbaren Vorgänger-Beziehung bildet eine kausale Beziehung. Die kausale Beziehung, ~> ⊆ E × E, ist die kleinste transitive Beziehung, so daß e_i → e_j ⇒ ~> e_j ist.
Eine gültige Beobachtung ist eine geordnete Aufzeichnung von Ereignissen aus einer gegebenen Ausführung, d.h. (R, ≺), wobei e ∈ E ⇒ (record(e)) ∈ R und ≺ ein Ordnungs-Operator ist. Eine gültige Beobachtung hat:
e_i; e_j; ∈ E, e_i ~> e_j ⇒ record (e_i) ≺ record (e_j)
Das Doppel der kausalen Beziehung ist eine Konkurrenz-Beziehung. Die Konkurrenz-Beziehung, E × E, enthält alle Paare (e_a, e_b), so daß weder e_a ~> e_b noch e_b ~> e_a. Während die kausale Beziehung transitiv ist, ist die Konkurrenz-Beziehung nicht transitiv. Die Konkurrenz-Beziehung ist symmetrisch, die kausale Beziehung ist nicht symmetrisch.
B. Verfolgung der Ereignis-Reihenfolge
30 veranschaulicht einen Raum-/Zeitgraph 3000, bei dem jedes Ereignis ein Label 3002 hat. In 30 kann der DLO 2902 Ereignis-Aufzeichnungen genau in die richtigen Behälter plazieren – auch wenn sie nicht der Reihe nach empfangen wurden – solange er die Behälter der unmittelbaren Vorgänger kennt. Wenn wir die Behälter kennen, in denen Ereignisse aufgezeichnet sind, können wir etwas über ihre Kausalität bestimmen. Glücklicherweise ist es einfach, jedes Ereignis mit der Nummer des beabsichtigten Behälters zu beschriften. Labels 3002 sind analog zur Zeit und werden typisch Lamport-Zeitstempel genannt.
Lamport-Zeitstempel können nach Bedarf zugewiesen werden, vorausgesetzt daß die Labels der unmittelbaren Vorgänger eines Ereignisses bekannt sind. Diese Information kann für jeden Prozeß P_i mit einem lokalen Zähler t_Pi, genannt eine Lamport-Uhr (nicht dargestellt), festgehalten werden. Der Wert der Uhr wird mit jeder Meldung M_j als t_Mj übertragen. Obwohl Lamport-Zeitstempel konsistent mit Kausalität sind, charakterisieren sie nicht die kausale Beziehung.
31 veranschaulicht einen Raum-/Zeitgraph 3100, der demonstriert, daß skalare Zeitstempel unfähig sind, die Kausalität zwischen Ereignissen zu charakterisieren. In 31 zeigt der Raum-/Zeitgraph 3100 Ereignis e₁ 3102, Ereignis e₂ 3104 und Ereignis e₃ 3106. e₁ 3102 verursacht e₂ 3104, und fällt auch mit e₃ 3106 zusammen, e₂ 3104 fällt mit e₃ 3106 zusammen, und es kann demonstriert werden, daß es bei Einsatz skalarer Zeitstempel so scheint, als ob e₃ 3106 sowohl mit e₁ 3102 als auch mit e₂ 3104 zusammenfällt. Da jedoch e₁ 3102 ~> e₂ 3104 ist, ist es nicht möglich, daß e₃ 3106 mit beiden zusammenfällt.
Bei Einsatz ausdrücklicher Ereignis-Abhängigkeits-Graphen kann Ereignis-Kausalität vollständig mit gerichteten Kanten von jedem Ereignis zu seinen unmittelbaren Vorgängern verfolgt werden. Leider kann bei diesem Verfahren nicht genügend Information zusammen mit jeder Aufzeichnung gespeichert werden, um zu bestimmen, ob zwei willkürlich gewählte Ereignisse kausal zueinander in Beziehung stehen, ohne den Abhängigkeitsgraph zu durchqueren.
Andere Beschriftungstechniken, wie Vektor-Zeitstempel, können bezeichnend für Kausalität sein. Vektor-Zeitstempel als typischer Ansatz basieren auf der Grundsätzlichkeit von Ereignisjournalen. Eine Basis für Vektor-Zeitstempel wird aufgrund der folgenden Definitionen und Lehrsätze eingerichtet. Ein Ereignisjournal H(e_j) eines Ereignisses e_j ist der Satz aller Ereignisse, e_i, derart, daß entweder e_i ~> e_j oder e₁ ~> e_i = e_j. Das Ereignisjournal kann auf spezifische Prozesse projeziert werden. Für einen Prozeß P_j: ist die P_j Journalprojektion von H(e_i), H_Pj(e_i) der Schnittpunkt von H(e_i) des für P_j lokalen Satzes von Ereignissen. Der durch ein Raum-/Zeitdiagramm dargestellte Ereignis-Graph kann in Äquivalenzklassen, mit einer Klasse für jeden Prozeß, unterteilt werden. Der Satz von für P_j lokalen Ereignissen ist gerade die P_j Äquivalenzklasse.
32 veranschaulicht ein Raum-/Zeitdiagramm 3200 mit Vektor-Zeitstempel-Ereignissen. Ein Vektor-Zeitstempel 3202 ist ein Vektor-Label t_e, das jedem Ereignis, e ∈ E, zugewiesen wird, derart, daß das i^te Element [H_Pi(e)] darstellt. Für zwei gegebene Elemente, e₁ und e₂, können wir ihre kausale Reihenfolge bestimmen: wenn Vektor t_ei einen kleineren Wert für den Eintrag seines eigenen Prozesses als der andere t_ei an der gleichen Position hat, dann e_i ~> e_j. Wenn beide Vektoren größere Werte für ihre eigenen Prozeßeinträge aufweisen, dann e_i || e_j. Es ist nicht möglich, daß beide Ereignisse kleinere Werte für ihre eigenen Einträge aufweisen, weil für Ereignisse e_a und e_b, e_a ↛ e_b folgendes impliziert: H_Pea(e_a) ⊇ H_Pea(e_b). Es ist nicht erforderlich, die lokalen Prozesse von Ereignissen zu kennen, um ihre kausale Reihenfolge mit Vektor-Zeitstempeln zu bestimmen.
Die Berechnung von Vektor-Zeitstempeln während der Laufzeit ist ähnlich wie die Berechnung von Lamport-Zeitstempeln. Jeder Prozeß enthält eine Vektoruhr mit Elementen für jeden Prozeß im System. Schnappschüsse dieses Vektorzählers werden zur Beschriftung jedes Ereignisses benutzt, und Schnappschüsse werden mit jeder Meldung übertragen. Der Empfänger einer Meldung mit einem Vektorschnappschuß kann seinen eigenen Vektorzähler aufgrund des Schnappschusses aktualisieren. Diese Technik plaziert genügend Information in jede Meldung, um die Meldungsreihenfolge zu bestimmen. Diese Technik wird durch Vergleichen von Schnappschüssen durchgeführt, die jeder Meldung beiliegen. Die Übertragung von ganzen Schnappschüssen ist jedoch gewöhnlich unpraktisch, besonders dann, wenn das System eine große Anzahl von Prozessen enthält.
Vektoruhren können jedoch ohne die Übertragung ganzer Schnappschüsse unterhalten werden. Ein Übertragungsprozeß P_S kann eine Liste senden, die nur solche Vektoruhr-Werte enthält, die sich seit der letzten Meldung geändert haben. Ein Empfänger P_r vergleicht daraufhin die Änderungsliste mit seinen aktuellen Elementen und aktualisiert diejenigen, die kleiner sind. Das bedeutet, daß jeder Prozeß mehrere Vektoren unterhalten muß: einen für sich selbst und einen für jeden Prozeß, an den er Meldungen gesendet hat. Die Änderungslisten enthalten jedoch nicht genügend Information, um die Meldungsreihenfolge unabhängig zu verfolgen.
Die Kosten zur Unterhaltung von Vektoruhren können ein starkes Abschreckungsmittel bei ihrem Einsatz sein. Leider kann keine Technik mit kleineren Labels Kausalität charakterisieren. Das Problem ergibt sich aus der Gleichzeitigkeit (Konkurrenz), ohne die Lamport-Zeit ausreichend wäre. Gleichzeitigkeit kann mit Gleichzeitigkeitskarten verfolgt werden, wobei jedes Ereignis alle Ereignisse verfolgt, mit denen es zusammenfällt. Da die Karten Gleichzeitigkeit charakterisieren, ist es durch Hinzufügen von Lamport-Zeit möglich, auch Kausalität zu charakterisieren (die Gleichzeitigkeitsinformation hebt die Zweideutigkeit der skalaren Zeit auf). Leider können Gleichzeitigkeitskarten erst im Nachhinein konstruiert werden, da hierzu eine Prüfung von Ereignissen aller Prozesse notwendig ist.
C. Raum/Zeit-Displays bei Fehlersuchtools
33 veranschaulicht das Display 3300 eines POET (Partial-Order Event Tracer). Das POET-System unterstützt mehrere verschiedene Sprachen und Laufzeitumgebungen einschließlich Hermes, eine High-Level Interpretationssprache für verteilte Systeme, und Java. In dem in 33 dargestellten POET-Display 3300 unterscheiden sich die verschiedenen Ereignistypen nach Form, Schattierung und Ausrichtung von entsprechenden Meldungszeilen.
2. Abstraktion bei Ereignis-basierter Fehlersuche
34 ist ein Raum-/Zeitdiagramm 3400 mit einem ersten zusammengesetzten Ereignis 3402 und einem zweiten zusammengesetzten Ereignis 3404. In 34 könnten selbst, wenn ein Paar von primitiven Ereignissen entweder kausal zueinander in Beziehung steht oder zusammenfällt, die ersten und zweiten zusammengesetzten Ereignisse 3402 und 3404, oder jedes andere Paar von zusammengesetzten Ereignissen, weder kausal zueinander in Beziehung stehen noch zusammenfallen. Abstraktion wird typisch auf zwei Dimensionen – Ereignissen und Prozessen -angewandt, um die Aufgabe der Fehlersuche in verteilter Software zu unterstützen. Ereignis-Abstraktion stellt Ereignisfolgen als einzelne Entitäten dar, um die semantische Bedeutung von Ereignisfolgen leichter erkennen zu können.
A. Ereignisfiltrierung und Clusterbildung
Ereignisfiltrierung und Clusterbildung sind Techniken, mit denen Ereignisse vor dem Designer verborgen werden, um mehr Klarheit in das Durcheinander zu bringen. Ereignisfilter sorgen dafür, daß bei Ereignis-basierten Fehlersuchtechniken ausgewählte Ereignisse aus der Verfolgung ausgeschlossen werden. In den meisten Fällen ist diese Filtrierung implizit und kann nicht modifiziert werden, ohne den Quellencode zu ändern, weil der auf Fehler durchsuchte Quellencode so ausgelegt ist, daß er dem Debugger nur bestimmte Ereignisse meldet. Bei ihrem Einsatz meldet der Code dem Tool alle derartigen Ereignisse. Dieser Ansatz findet sowohl in DPD als auch POET Einsatz, obwohl einige Ereignisse zu einer späteren Zeit aus dem Display ausgefiltert werden können. Ein Ereignis-Cluster, auf der anderen Seite, ist eine Gruppe von Ereignisse, die als einziges Ereignis dargestellt werden. Die Plazierung eines Ereignisses in einem Cluster basiert auf einfachen Parametern, wie virtuellen Zeitgrenzen und Prozeßgruppen.
35 veranschaulicht ein POET-Display 3500 mit einem ersten konvexen Ereignis-Cluster 3502 und einem zweiten konvexen Ereignis-Cluster 3504. POET verwendet eine auf virtueller Zeit basierende Clusterbildungstechnik, die konvexe Ereignis-Clusters 3502 als einzelne abstrakte Ereignisse darstellt. Ein konvexer Ereignis-Cluster ist ein Satz voln Ereignisinstanzen, C, derart, daß für Ereignisse
a, b, c ∈ E mit a, c ∈ C, a ~> b ∧ b ~> c ⇒ b ∈ C
Konvexe Ereignis-Clusters, im Gegensatz zu generischen Ereignis-Clustern, können nicht überlappen.
B. Ereignisinterpretation spezifischer Hintergrund für Verhaltensabstraktion
Die dritte Technik zur Anwendung von Ereignis-Abstraktion ist Interpretation, auch Verhaltens-Abstraktion (behavioral abstraction) genannt. Beide Ausdrücke beschreiben Techniken, die Fehlersuchtools verwenden, um das Verhalten von Ereignisfolgen zu interpretieren und einem Designer Ergebnisse vorzulegen. Die meisten Ansätze für Verhaltensabstraktion erlauben einem Designer, Ereignisfolgen unter Einsatz von Ausdrücken zu beschreiben, und die Tools erkennen die Ereignisfolgen aufgrund einer Kombination von kundenspezifischen begrenzten Automaten, gefolgt von expliziten Prüfungen.
1. Ereignisbeschreibungssprache (EDL)
Eine der ersten Verhaltensabstraktionstechniken war die Ereignisbeschreibungssprache (EDL) von Bates, bei der Ereignisströme unter Einsatz von „Shuffle Automaten" auf Übereinstimmung eines Musters geprüft werden („pattern-matched"). Eine Übereinstimmung erzeugt ein neues Ereignis, das seinerseits Teil eines anderen Musters sein kann. Abstrakte Ereignisse sind im wesentlichen hierarchisch und sind von unten nach oben aufgebaut.
Mit diesem Ansatz können Ereignismuster erkannt werden, die zusammenfallende Ereignisse enthalten. Es gibt jedoch bei diesem Ansatz einige Schwachpunkte. Erstens stimmen „Shuffle Automaten" mit Ereignissen aus einem linearen Strom überein, der stark durch Beobachtungen vorbelastet ist. Des weiteren, wenn der Strom eine gültige Beobachtung darstellt, können durch Verschachtelung falsche Zwischenereignisse zwischen einem Ereignis und seinem unmittelbaren Nachfolger verursacht werden. Schließlich scheinen gleichzeitige Ereignisse in einer spezifischen Reihenfolge einzutreten. Diese Schwächen können bis zu einem gewissen Grade kompensiert werden, der Kompensationsprozeß erschwert jedoch die Fehlersuche, Schwierigkeiten bei der Erkennung der Ereignisreihenfolge oder ein Mangel an Kausalität und Gleichzeitigkeitsprüfungen.
2. Kettenausdrücke
Kettenausdrücke sind eine Alternative für die Beschreibung von verteilten Verhaltensmustern, die sowohl Kausalität als auch Gleichzeitigkeit aufweisen. Diese Verhaltensbeschreibungen basieren auf Ereignisketten (abstrakte, nicht an Prozesse gebundene Folgen), p-Ketten (an Prozesse gebundene Ketten) und pt-Ketten (unechte p-Ketten). Ein Erkennungsalgorithmus für Kettenausdrücke hat zwei Funktionen. Erstens erkennt der Algorithmus die entsprechende Ereignisfolge aus einem linearen Strom unter Einsatz eines nicht determinierten begrenzten Automaten (NFA). Zweitens prüft der Algorithmus die Beziehungen zwischen spezifischen Ereignissen. Leider können infolge der Tatsache, daß Folgen der Reihe nach einem linearen Strom vor der Prüfung von Beziehungen entnommen werden, manche Übereinstimmungen verfehlt werden.
3. Verteilte Abstraktion
36 veranschaulicht eine BEE-Abstraktionseinrichtung 3600 (BEE = Basis for distributed Event Environments (ein verteiltes, hierarchisches Ereignissammelsystem)) für einen einzelnen Client. In 36 wird Ereignis-Interpretation auf mehreren Ebenen durchgeführt. Die erste Ebene ist ein Ereignis-Sensor 3602, der in die Quelle des zu testenden Programms eingesetzt und bei jedem Eintreten eines primitiven Ereignisses während der Ausführung aufgerufen wird. Die nächste Ebene ist ein Ereignisgenerator 3604, wo Information – einschließlich Zeitstempeln und Prozeßkennungen – an jedes Ereignis angehängt wird. Ereignisgenerator 3604 benutzt eine Ereignistabelle 3606, um zu bestimmen, ob Ereignisse an einen Ereignis-Handler 3608 weitergereicht oder einfach fallengelassen werden sollten. Ereignis-Handler 3608 managt Tabelle 3606 innerhalb Ereignisgenerator 3604. Ereignis-Handler 3608 filtriert und sammelt Ereignisse und leitet sie zu entsprechenden Ereignis-Interpretern (nicht dargestellt). Ereignis-Interpreter (nicht dargestellt) sammeln Ereignisse von einer Anzahl Clients (nicht dargestellt) und fassen sie zusammen, um sie einem Programmierer vorzulegen. Clients und ihre darauf bezogenen Ereignis-Interpreter werden in Gruppen zusammengefaßt, die von einem Ereignismanager (nicht dargestellt) gemanagt werden. Ein Schwachpunkt bei dieser Technik ist, daß dabei Kausalität nicht spezifisch verfolgt wird. Stattdessen verläßt sich diese Technik auf Echtzeitstempel, die an spezifische primitive oder abstrakte Ereignisse angehängt sind. Diese Zeitstempel sind jedoch, wie oben beschrieben, nicht fähig Kausalität zu charakterisieren.
C. Prozeß-Clusterbildung
Die meisten verteilten Computer-Umgebungen zeichnen sich durch flache Prozeßstrukturen aus, wobei nur wenige Prozeßbeziehungen formell als solche genannt werden. Automatische Prozeß-Clusterbildungs-Tools können eine hierarchische Struktur zum Teil umfunktionieren, um störende Information aus dem Blickfeld eines Debuggers zu entfernen. Instinktiv sollte eine gute Cluster-Hierarchie auf der obersten Ebene High-Level-Systemverhalten zeigen, und die Auflösung sollte sich proportional zur Anzahl der freigelegten Prozesse verbessern. Eine schlechte Cluster-Hierarchie würde sehr wenig auf der obersten Ebene zeigen, und ein Programmierer wäre erforderlich, um hierarchisch nach unten vorzudringen, bevor er sich eine ungefähre Vorstellung vom Verhalten des Systems machen kann. Prozeß-Clusterbildungs-Tools versuchen, gemeinsame Wechselwirkungsmuster wie Client-Server, Master-Slave, komplexer Server, geschichtetes System, usw. zu identifizieren. Bei Identifizierung dieser Muster werden die Teilnehmer zu Clustern zusammengefaßt. Dann können Clusters als Teilnehmer in Wechselwirkungsmustern fungieren, um weitere Clusters zu bilden. In der Vergangenheit wurden diese Cluster-Hierarchien nur als Baumstruktur, wie in 37 dargestellt, veranschaulicht, die eine hierarchische Konstruktion von Prozeß-Clustern 3700 zeigt. In 37 stellt ein eckiger Knoten 3702 einen Prozeß (nicht dargestellt) dar, und ein runder Knoten 3704 stellt ein Prozeß-Cluster (nicht dargestellt) dar.
Programmierer können einen "Debugging Focus" wählen, in dem sie die Aspekte und Detailebenen, auf denen sie eine Ausführung beobachten wollen, angeben. In 37 ist ein beispielhafter Debugging Focus dargestellt, welcher Knoten I, J, E, F, G und H enthält. Ein Nachteil bei diesem Ansatz ist, daß übergeordnete Clusters und untergeordnete Clusters nicht gleichzeitig im „Focus" sein können. Wenn zum Beispiel Prozeß K im Detail untersucht werden soll, müßte wir auch mindestens soviele Details wie möglich für Prozesse E und L und für Prozeß-Clusters D freilegen.
Jeder Prozeß nimmt gewöhnlich an vielen verschiedenen Wechselwirkungen mit anderen Prozessen teil. Folglich muß das Abstraktionstool heuristisch zwischen mehreren Optionen entscheiden. Diese Entscheidungen haben eine starke Auswirkung auf die Qualität einer Cluster-Hierarchie. Systeme nach dem Stand der Technik haben typisch die Qualität eines Clusterbildungstools ausgewertet, indem sie die Kohäsion innerhalb eines Clusters, die obwohl quantitativ ausgedrückt, in Wirklichkeit eine qualitative Messung ist (je höher je besser), und die Kopplung – ein qualitatives Maß der Information, die Clusters voneinander gegenseitig kennen müssen (je höher je schlechter) zwischen Clustern messen. Die Qualität eines Clusters wird als seine Kopplung minus seiner Kohäsion quantifiziert. In vielen Fällen stimmen diese Metriken mit vielen der Charakteristiken überein, die instinktiv gute von schlechten Clustern unterscheiden, wie in 38A, B und C dargestellt. In 38A und C ist die Kohäsion stark, wo Clusters starker Kommunikation entsprechen und wo Clusters Prozessen entsprechen, die vom gleichen Quellencode erstellt wurden. Die Kopplung, wie zu erkennen ist, ist in jedem der obigen Fälle schwach. In 38B ist die Kopplung stark, wenn Clusters nicht stark kommunizierenden Prozessen oder Instanzen des gleichen Quellencodes entsprechen. Es ist jedoch nicht klar, ob dem Cluster in 38C der gleichen Qualitätswert wie dem Cluster in 38A zugewiesen sollte. Mit diesen Metriken erzielte Kunz Qualitäten zwischen :15 und :31 für seine Clusterbildungs-Techniken. Es ist jedoch schwer sagen, was dies im Sinne von Cluster-Nützlichkeit bedeutet.
3. Zustands-basierte Fehlersuche
Zustands-basierte Fehlersuchtechniken konzentrieren sich mehr auf den Zustand des Systems und die durch Ereignisse verursachten Zustandsänderungen als auf die Ereignisse als solche. Der bekannte Quellenebenen-Debugger für sequentielle Programmfehlersuche ist zustands-basiert. Dieser Quellenebenen-Debugger erlaubt es Designern, Unterbrechungspunkte in der Ausführung des Programms zu setzen, so daß es Designern möglich ist, den Zustand an diesem Punkt der Ausführung zu untersuchen. Dieser Quellenebenen-Debugger erlaubt es ferner Programmierern, schrittweise durch die Ausführung eines Programms zu gehen und die durch jeden Schritt verursachten Zustandsänderungen zu betrachten. Konkurrente Systeme haben jedoch keine eindeutige Bedeutung für eine Instanz in Ausführungszeit.
A. Consistent Cuts (konsistente Schnitte) und globaler Zustand
Bei verteilter, Ereignis-basierter Fehlersuche ist das Konzept der Kausalität typisch von derartiger Wichtigkeit, daß fast kaum etwas, das von Wert ist, ohne ein gründliches Verständnis von Kausalität und den damit verbundenen Implikationen besprochen werden kann. Bei verteilter Zustands-basierter Fehlersuche ist das Konzept einer globalen zeitlichen Instanz gleichermaßen wichtig. Genauso wie die Bestimmung der Echtzeitreihenfolge von Ereignissen unpraktisch oder überhaupt besonders nützlich ist, ergibt die Suche nach genauen Echtzeitinstanzen wenig Sinn. Stattdessen wird eine globale Instanz durch einen konsistenten Schnitt (Consistent Cut) dargestellt. Ein konsistenter Schnitt ist ein Schnitt durch einen Ereignisabhängigkeitsgraph, der eine Ausführung darstellt, die (a) jeden Prozeß exakt einmal durchschneidet und (b) alle Abhängigkeiten, die den Schnitt durchkreuzen, in die gleiche Richtung weist. Genau wie Echtzeitinstanzen haben konsistente Schnitte sowohl eine Vergangenheit als auch eine Zukunft. Dies sind die Subgraphen auf jeder Seite des Schnitts.
39 zeigt, daß konsistente Schnitte als gezackte Linie in einem Raum-/Zeitdiagramm dargestellt werden können, das den obigen Anforderungen entspricht. Das Raum-/Zeitdiagramm 3900 in 39 hat einen ersten Schnitt 3902 und einen zweiten Schnitt 3904. Alle Ereignisse auf der linken Seite des ersten Schnitts 3902 bzw. des zweiten Schnitts 3904 liegen in der Vergangenheit jedes Schnitts, während alle Ereignisse auf der rechten Seite in der Zukunft jedes Schnitts liegen. Der erste Schnitt 3902 ist ein konsistenter Schnitt, weil keine Meldung von der Zukunft in die Vergangenheit geht. Der zweite Schnitt 3904 ist jedoch nicht konsistent, weil eine Meldung 3906 von der Zukunft in die Vergangenheit geht.
40A, B und C zeigen, daß eine in Raum-/Zeitdiagramm 4000 dargestellte verteilte Ausführung durch ein Gitter mit konsistenten Schnitten 4002 dargestellt werden kann, in dem T der Start der Ausführung und ⊥ die Systembeendigung ist. In 40A, B und C stellt das Gitter konsistenter Schnitte 4002 den globalen Zustandsraum dar, der von einer einzelnen Ausführung durchquert wird. Da die Größe des Gitters konsistenter Schnitte 4002 in der Größenordnung von |E|^|P| liegt, wird es im Gegensatz zu Raum-/Zeitdiagrammen nie wirklich konstruiert. Im restlichen Teil dieses Kapitels wird bei der Beschreibung der Eigenschaften konsistenter Schnittgitter das Symbol → l zur Darstellung unmittelbar vorausgehender Schnitte und das Symbol ~> zur Darstellung von Schnitten, zwischen denen ein Pfad besteht, verwendet.
B. „Single-Stepping" in einer verteilten Umgebung
„Controlled-Stepping" oder „Single-Stepping" durch die Regionen einer Ausfürung können zur Analyse des Systemverhaltens benutzt werden. Der Programmierer kann Zustandsänderungen am Schluß jedes Schrittes untersuchen, um ein besseres Verständnis des Systemsteuerungsflusses zu erlangen. Bei kohärentem Single-Stepping in einem verteilten System ist darauf zu achten, daß Schritte mit einem Pfad durch das konsistente Schnittgitter einer normalen Ausführung hindurch fluchten.
DPD funktioniert in Verbindung mit Standard-Einzelprozeß-Debuggern (genannt Client Debugger) wie DBX, GDB usw. Andere Systeme bieten ein einfaches Verfahren für Single-Stepping an, wobei eine „Post-Mortem" Durchquerung eines konsistenten Schnittgitters zum Einsatz kommt. An jedem Punkt im Stepping-Prozeß gibt es zwei disjunkte Mengen von Ereignissen: die vergangene Menge oder Ereignisse, die bereits vom Stepping-Tool angetroffen wurden, und die zukünftige Menge oder solche, die noch anzutreffen sind. Um mehr Schrittarten zu ermöglichen, kommen bei POET zur Unterstützung von Single-Stepping drei disjunkte Mengen zum Einsatz: executed (ausgeführt), ready (bereit) und unready (nicht bereit). Bei Einsatz dieser Mengen ist es möglich, drei verschiedene Arten von Schritten durchzuführen: Global-step, Step-over und Step-in. Global Step und Step-over werden zwischen zwei konsistenten Schnitten durchgeführt, auch wenn es mehrere konsistente Zwischenschnitte zwischen den „Step Cuts" (Schrittschnitten) gibt. 41A, B, C und D zeigen ein Raum-/Zeitdiagramm vor einem Step 4100 und ein resultierendes Raum-/Zeitdiagramm nach Durchführung eines Global Step 4102, eines Step-over 4102 und eines Step-in 4106.
C. Laufzeit-Algorithmen für konsistente Schnitte
Es ist gelegentlich erforderlich, konsistente Schnitte während der Laufzeit zu erfassen. Zu diesem Zweck führt jeder Prozeß eine Art von Schneidakt durch (z.B. Zustandsspeicherung). Dies kann bei Barrieren-Synchronisation erfolgen, wobei eine temporale Barriere errichtet wird, die kein Prozeß passieren kann, bis alle Prozesse ankommen. Jeder unmittelbar vor der oder unmittelbar nach der Barriere durchgeführte Schnitt ist konsistent. Bei Barrieren-Synchronisation müssen jedoch manche Prozesse lange warten, bis der letzte Prozeß ankommt.
Eine proaktivere Technik besteht darin, einen Prozeß, genannt „Cut Initiator", zu verwenden, um „Perform-Cut" Meldungen an alle andere Systemprozesse zu senden. Nach Erhalt einer Perform-Cut-Meldung führt der Prozeß den Schneidakt durch, sendet eine Cut-finished-Meldung an den Initiator, und suspendiert sich dann selbst. Nachdem der Cut-Initiator Cut-finished-Meldungen von allen Prozessen erhalten hat, sendet er jedem eine Meldung, die Berechnung wieder aufzunehmen. Dieser Algorithmus weist das unerwünschte Merkmal auf, daß er das System für die Dauer des Schneidakts anhält. Die folgenden Algorithmen dagegen erlauben einen bewissen Weitergang von Prozessen.
1. Chandy-Lamport Algorithmus
Der Chandy-Lamport Algorithmus erlaubt den Weiterlauf des Systems. Der Schneidakt startet auch hier, wenn ein Cut-Initiator Perform-Cut-Meldungen an alle Prozesse sendet. Wenn ein Prozeß eine Perform-Cut-Meldung erhält, stoppt er jegliche Arbeit, führt den Schneidakt durch und sendet dann eine Marke auf jedem seiner ausgehenden Kanäle; eine Marke ist eine spezielle Meldung, die den Empfänger anweist, einen Schneidakt durchzuführen, bevor er die nächste Meldung, die auf diesem Kanal ankommt, liest. Wenn alle Marken gesendet wurden, steht es dem Prozeß frei, die Berechnung fortzusetzen. Wenn der Empfänger den Schneidakt bei Empfang einer Marke bereits durchgeführt hat, kann er wie normal weiterarbeiten.
2. Farb-basierter Algorithmus
Farb-basierte Algorithmen erlauben den Einsatz einer Variante des Chandy-Lamport Algorithmus auf Kanälen, die Nicht-FIFO (First In First Out) sind. Der erste wird der Zweifarben- oder Rotweiß-Algorithmus genannt. Mit diesem Algorithmus wird Information über den Schnittzustand mit jeder Meldung übertragen. Jeder Prozeß im System hat eine Farbe. Prozesse, die an einem konsistenten Schnitt gerade nicht beteiligt sind, sind weiß, und alle Meldungen, die übertragen werden, werden mit einem weißen Ta versehen. Auch hier ist ein Cut-Initiator vorhanden, der Perform-Cut-Meldungen an alle Systemprozesse sendet. Wenn ein Prozeß diese Anforderung empfängt, hält er an, führt den Schneidakt durch und ändert seine Farbe zu Rot. Ab diesem Punkt sind alle Meldungen, die übertragen werden, mit einem roten Tag versehen, um die Empfänger zu informieren, daß ein Schnitt durchgeführt wurde.
Ein Dreifarben-Algorithmus befaßt sich mit einen Nachteil des Zweifarben-Algorithmus. Der Dreifarben-Algorithmus gleicht dem Zweifarben-Algorithmus insoweit, als jeder Prozeß nach dem Schnitt die Farbe ändert. Der Dreifarben-Algorithmus weicht jedoch insofern ab, als jede Änderung in der Farbe einen Schnitt darstellt. Für Farben Null bis Zwei, wenn ein Prozeß mit der Farbe c eine Meldung mit der Farbe (c – 1) mod 3 empfängt, registriert er dies als „Message-in-flight" (siehe unten). Auf der anderen Seite, wenn er eine Meldung mit der Farbe (c + 1) mod 3 empfängt, muß er den Schneidakt durchführen und die Farbe zu (c + 1) mod 3 wechseln, bevor er die Meldung erhält. Daraus können nun natürlich n-Farbalgorithmen gemacht werden, aber drei Farben sind gewöhnlich ausreichend.
D. Zustandswiederherstellung – Rollback (Zurückrollen) und Replay (Zurückspielen)
Da verteilte Ausführungen dazu zu neigen, nicht-deterministisch zu sein, ist es oft schwierig, Fehler zu wiederholen, die während individueller Ausführungen eintreten. Zu diesem Zweck enthalten die meisten verteilten Debugger eine Rollback-Einrichtung, die das System auf einen früheren Zustand zurücksetzt. Um dies zu ermöglichen, müssen alle Prozesse im System gelegentlich ihren Zustand speichern. Dies nennt man „Checkpointing the System" (Systemprüfpunkte setzen). Prüfpunkte müssen nicht den gesamten Zustand des Systems speichern. Es ist ausreichend, nur die Änderungen ab dem letzten Prüfpunkt zu speichern. Diese inkrementelle Prüfpunktsetzung kann jedoch die Wiederherstellung hinauszögern.
Prozesse müssen manchmal auf Zustände zurückgesetzt werden, die nicht speziell gespeichert wurden. In diesem Falle muß der Debugger zusätzliche Arbeit leisten, um das System bis zum gewünschten Punkt vorzurücken. Dies wird „Replay" genannt, wobei Ereignisverfolgungsinformation zum Einsatz kommt, um die Ausführung des Systems zu lenken. Bei Replay wählt der Debugger einen aktivierten Prozeß (d.h. einen Prozeß, dessen nächstes Ereignis keine wartenden kausalen Erfordernisse aufweist) und führt ihn aus, wobei er die Ereignisverfolgungsinformation benutzt, um zu bestimmen, wo der Prozeß wegen einer Meldung blockieren muß, die vielleicht asynchron in der ursprünglichen Ausführung angekommen ist. Wenn der Prozeß blockiert, wählt der Debugger den nächsten aktivierten Prozeß und geht von da an weiter. Auf diese Weise ist ein Replay kausal identisch mit der ursprünglichen Ausführung.
Prüfpunkte müssen so benutzt werden, daß ein Domino-Effekt verhindert wird. Der Domino-Effekt tritt dann ein, wenn Rollbacks Prozesse zwingen, mehr als einen Zustand wiederherzustellen: Domino-Effekte können das System bis zum Startpunkt zurückrollen. 42 zeigt ein Raum-/Zeitdiagramm 4200 für ein System, das beim Rollback anfällig gegen den Domino-Effekt ist. In 42, wenn das System ein Rollback bis zu Prüfpunkt c₃ 4202 von Prozeß P₃ 4204 anfordert, müssen alle Prozesse im System bis zu c₁ zurückrollen (d.h. Rollback zu P₃·c₃ 4206 erfordert ein Rollback bis zu P₂·c₂ 4208, welches ein Rollback bis zu P₁·c₂ 4210 erfordert, welches ein Rollback bis zu P₃·c₁ 4212 erfordert, welches ein Rollback bis zu P₂·c₁ 4214 erfordert, welches ein letztes Rollback bis zu P₁·c₁ 4216 erfordert). Das Problem wird durch kausale Überlappungen zwischen Meldungsübertragungen und Prüfpunkten verursacht. Wenn man Prüfpunkte nur an konsistenten Schnitten durchführt, läßt sich ein Domino-Effekt vermeiden.
E. Globale Zustandsprädikate
Die Fähigkeit, den Wahrheitswert von Prädikaten über den globalen Zustand nachzuweisen, ist für die Fehlersuche in verteilten Systemen von großem Vorteil. Diese Technik erlaubt Programmierern, Flags zu setzen, wenn globale Geltendmachungen fehlschlagen, globale Unterbrechungspunkte zu setzen und interessante Aspekte einer Ausführung zu überwachen. Globale Prädikate sind solche, deren Wahrheitswert von dem von mehreren Prozessen aufrechterhaltenen Zustand abhängig ist. Sie werden typisch mit dem Symbol Φ bezeichnet. Einige Beispiele sind (Σ_ic_i > 20) und (c₁ < 20 ^ c₂5), wobei c_i irgendeine Variable in Prozeß P_i ist, die positive Ganzzahlen speichert. Im schlimmsten Fall (wie wenn (Σ_ic_i > 20) falsch für eine gesamte Ausführung ist), ist es unter Umständen erforderlich, den Wert aller dieser Variablen in allen konsistenten Schnitten zu ermitteln. In der folgenden Diskussion benutzen wir die Notation C_α |= Φ, um anzuzeigen, daß Φ im konsistenten Schnitt C_α wahr ist.
An diesem Punkt erscheint es nützlich, temporale Branching time Logik einzuführen. Temporale Branching time Logik ist Prädikatenlogik mit temporalen Quantifikatoren P, F, G, H, A und E. PΦ ist wahr in der Gegenwart, wenn Φ an einem Punkt in der Vergangenheit wahr war; FΦ ist wahr in der Gegenwart, wenn Φ an einem Punkt in der Zukunft wahr sein wird; GΦ ist wahr in der Gegenwart, wenn Φ in jedem Moment in der Zukunft wahr sein wird; und HΦ ist wahr in der Gegenwart, wenn Φ in jedem Moment in der Vergangenheit wahr war. Wir möchten darauf hinweisen, daß GΦ das Gleiche wie ¬F ¬Φ und HΦ das Gleiche wie ¬P¬Φ ist.
Da globaler Zeitablauf (Time Passage) in verteilten Systemen durch ein teilweise geordnetes konsistentes Schnittgitter, nicht durch einen vollkommen geordneten Strom gekennzeichnet ist, benötigen wir den Quantifikator A, der einem auf allen Pfaden wahren Prädikat vorausgeht, und den Quantifikator E, der einem auf mindestens einem Pfad wahren Prädikat vorausgeht. Somit ist AFΦ wahr in dem die Gegenwart darstellenden konsistenten Schnitt, wenn Φ mindestens einmal auf allen Pfaden im Gitter, die diesen Schnitt verlassen, wahr ist. EPΦ ist wahr in dem die Gegenwart darstellenden konsistenten Schnitt, wenn Φ auf mindestens einem Pfad, der zu diesem Schnitt führt, wahr ist.
Ein monotones globales Prädikat ist ein Prädikat Φ derart, daß C_α |= Φ ⇒ C_α |= AG Φ. Ein monotones globales Prädikat ist eins, das wahr bleibt, nachdem es wahr wurde. Ein instabiles globales Prädikat, auf der anderen Seite, ist ein Prädikat Φ derart, daß C_α |= Φ ⇒ C_α |= EG¬Φ. Ein instabiles Prädikat ist eins, das falsch werden kann, nachdem es wahr wurde.
1. Nachweisen von monotonen globalen Prädikaten
Monotone Prädikate können jederzeit, nachdem sie wahr wurden, nachgewiesen wurden. Ein Algorithmus besteht darin, gelegentlich konsistente Schnitte durchzuführen und die Prädikate in jedem Schnitt auszuwerten. Eigentlich ist es nicht notwendig, konsistente Schnitte zu benutzen, da jeder quere Schnitt, dessen Zukunft ein Subsatz der Zukunft des konsistenten Schnitts ist, in dem das Prädikat zuerst wahr wurde, ebenfalls zeigt, daß das Prädikat wahr ist.
2. Nachweisen von instabilen globalen Prädikaten
Das Nachweisen von arbiträren instabilen globalen Prädikaten kann im schlimmsten Fall |E|^|P| Zeit in Anspruch nehmen, wobei |E|^|P| die Größe eines konsistenten Schnittgitters einer Ausführung, [E] die Anzahl der Ereignisse in der Ausführung und [P] die Anzahl der Prozesse ist. Dies ist so, weil es eventuell erforderlich ist, in jedem möglichen konsistenten Schnitt zu testen, ob das Prädikat da ist. Es gibt jedoch einige spezielle Umstände, die |E| Zeit-Algorithmen zulassen.
Einige instabilen globalen Prädikate sind wahr auf nur wenigen Pfaden durch das konsistente Schnittgitter, während andere für alle Pfade wahr sind. In Cooper, R., und Marzullo, K., „Consistent Detection of Global Predicates," in ACM/ONR Workshop on Parallel & Destributed Debugging (1991), beschreiben Cooper und Marzullo Prädikat-Kennzeichner definitiv als Φ für Prädikate, die wahr für alle Pfade sind (d.h., T |= AFΦ) und möglicherweise als Φ für diejenigen, die auf mindestens einem Pfad wahr sind (d.h., T |= >EFΦ).
Der Nachweis von möglicherweise Φ für schwache konjunktive Prädikate oder globale Prädikate, die als Konjunktionen von lokalen Prädikaten ausgedrückt werden können, ist φ(|E|). Der Algorithmus hierfür besteht darin, auf einem Pfad durch das konsistente Schnittgitter zu gehen, das mit einem einzelnen Prozeß P_t fluchtet, bis entweder (1) die Prozeßkomponente von Φ wahr ist oder (2) es keine Möglichkeit zum Weitermachen gibt, ohne von P_t abzuweichen. In jedem Fall wird der Zielprozeß geschaltet und der Gang fortgesetzt. Dieser Algorithmus geht so lange weiter, bis er einen Zustand erreicht, in dem alle Komponenten des Prädikats wahr sind oder bis er ⊥ erreicht. Auf diese Weise, wenn konsistente Schnitte vorhanden sind, bei denen alle Teile des Prädikats gleizeitig halten, trifft der Algorithmus mindestens einen Zustand an.
Der Nachweis von möglicherweise Φ für schwache disjunktive Prädikate oder globale Prädikate, die als Disjunktionen von lokalen Prädikaten ausgedrückt werden können, ist ebenfalls φ(|E|); es ist der gleiche Algorithmus wie oben, nur mit der Ausnahme, daß er am ersten Knoten anhält, an dem eine Komponente wahr ist. Schwache konjunktive und disjunktive Prädikate stellen jedoch nur einen kleinen Teil der Prädikattypen dar, die bei der Fehlersuche in verteilten Systemen nützlich sein können.
4. Schlußfolgerungen
Mit der Zunahme an Größe und Komplexität verteilter Systeme wächst auch die Menge der während einer Ausführung erzeugten Ereignisse bis auf einen Punkt, an dem es äußerst schwierig für Designer ist, Aspekte der Ausführung korrekt zu identifizieren, die für das Auffinden eines Fehlers relevant sein können. Um verteilte Systemfehlersuchtechniken für größere und schnellere Systeme einsetzen können, wird Verhaltensabstraktion typisch eine Notwendigkeit werden, um Designern bei der Identifikation und Interpretation von komplizierten Verhaltensfolgen in einer Systemausführung zu helfen. Schließlich müssen eingebettete Systeme in einer anderen Umgebung als der, in der sie entworfen wurden, ausgeführt werden, und eingebettete Systeme müssen auch für lange Zeiträume ohne klare Stoppunkte laufen können. Die Fehlersuche in ihnen erfordert „Sonden", um einem Designer Fehlersuchinformation während der Ausführung zu melden. Diese Sonden ändern unausweichlich das Systemverhalten, was vorhandene Fehler verschleiern oder neue Fehler erstellen kann, die in dem nicht-instrumentierten System nicht vorhanden sind. Während diese Sondenauswirkungen nicht ganz vermieden werden können, können sie durch sorgfältige Plazierung auf ein Minimum reduziert oder durch permanente Plazierung verschleiert werden.
Statische Kontrollgraphen
Ein statischer Kontrollgraph (SCG) ist eine Graph-theoretische Darstellung aller reinen Kontrollbeschränkungen. 43 zeigt einen einfachen SCG. Es ist ein zweiteiliger Digraph mit zwei Knotentypen: Konjunktionsknoten 4330 und 4332, die, wie der Name besagt, nur dann Ergebnisse produzieren, wenn alle einfallenden Kanten 4310 zufriedengestellt sind, und Disjunktionsknoten 4300, 4302, 4304, 4306 und 4308, die nur dann Ergebnisse produzieren, wenn eine einfallende Kanten 4310 zufriedengestellt ist. Disjunktionsknoten 4300, 4302, 4304, 4306 und 4308 entsprechen Betriebsarten 102 in Komponenten 100 und Koordinatoren 410 (wie vorher in 1 und 4 dargestellt) im ganzen System. Ein SCG für ein komplettes System stellt gleichzeitig alle Kontrollbeschränkungen dar.
Ein SCG ist ein Triple, G = (C, D, E), in dem

• C ein Satz von Konjunktionsknoten ist.
• D ein Satz von Disjunktionsknoten ist.
• E ⊆ [{T_f, T_t} × {H_f; H_t} × ((C × D) ∪ (D × C))] ein Satz von gerichteten benannten Kanten ist. Kanten sind empfindlich gegen entweder einen falschen Wert oder einen wahren Wart an ihrem hinteren Ende 4311 (T_f, T_t) und setzen entweder einen falschen Wert oder einen wahren Wert an ihrem vorderen Ende 4312 (H_f; H_t) durch. Diese werden visuell durch eine Blase am entsprechenden Ende für einen falschen Wert oder durch Abwesenheit einer Blase für einen wahren Wert dargestellt.

Eine Kante 4310 in einem SCG kann entweder aktiviert oder deaktiviert sein; sie produziert den Wert wahr oder den Wert falsch. 44 veranschaulicht eine graphische Notation für Kanten-Labels. Kanten 4400 und 4402, die mit einer Blase am vorderen Ende 4312, wie in 44A und 44B dargestellt, markiert sind, setzen, wenn aktiviert, den Wert falsch durch. Wenn am vorderen Ende 4312 keine Marke vorhanden ist, wie in 44C und 44D dargestellt, setzt eine Kante 4404 und 4406, wenn aktiviert, den Wert wahr durch. Eine Blase am hinteren Ende 4311, wie in 44B und 44D dargestellt, gibt an, daß Kante 4406 und 4402 empfindlich gegen falsch an dem Knoten, den sie verläßt, ist. Ein Mangel an solchen Blasen, wie in 44A und 44C dargestellt, gibt an, daß Kante 4404 und 4400 empfindlich gegen wahr ist.
Zurückgehend zu 43 veranschaulicht diese Figur einen einfachen SCG, in dem ein Knoten d 4306 immer aktiv sein muß, wenn eine Konjunktion (a ∧ b ∧ c) 4332 aktiv ist, und immer inaktiv sein muß, wenn ein Knoten e 4308 aktiv ist. Obwohl dies ähnlich wie ein boolsches Netzwerk aussieht, besteht ein Unterschied, weil die SCG-Kanten Implikation, nicht Verbindung darstellen. Dies ist in 45 veranschaulicht, welche einen ODER Knoten 4500 eines boolschen Netzwerks darstellt; wenn alle Eingänge und Ausgänge negiert sind, ist er gleichbedeutend mit einem UND Knoten 4502 (von DeMorgan). Ein SCG-Disjunktionsknoten, bei dem alle Eingänge und Ausgänge 4504 negiert sind, ist gleichbedeutend mit einem Disjunktionsknoten mit keinen negierten 4506 Eingängen und Ausgängen.
Jeder SCG hat eine boolsche charakteristische Funktion. Dies ist eine boolsche Funktion 164, die wahr für jede Konfiguration ist, in der keine Beschränkungen verletzt werden, und die falsch für Konfigurationen mit verletzten Beschränkungen ist. 46 zeigt zwei SCGs zusammen mit ihren reduzierten charakteristischen Funktionen, wobei die Funktionen (d.h. a ∧ b ⇒ ¬c) auf Funktionen reduziert sind, die nur grundlegende Operatoren benutzen (d.h. ¬(a ∧ b ∧ c)). 46A zeigt Konjunktion ohne Negation, während 46B Konjunktion mit Negation zeigt. Charakteristische Funktionen für SCGs mit mehreren Konjunktionsknoten sind die Konjunktion aller Beschränkungen und können als solche eventuell nicht zufriedengestellt werden.
47 zeigt die Auswirkung von Kanten-Semantiken auf SCG. Kanten, die auf Konjunktionsknoten einfallen, (d.h. Kanten der Form (d, c) für d ∈ D, c ∈ C), werden Überwachungskanten 4700 und 4702 genannt; Kanten, die auf Disjunktionsknoten einfallen, (d.h. Kanten der Form (c, d)), werden Durchsetzungskanten 4704 und 4706 genannt. Alle Kanten und Knoten sind mit ihrem entsprechen Quellenobjekt (d.h. einer Betriebsart/Kontrollportkombination für einen Disjunktionsknoten und einer Beschränkung für einen Konjunktionsknoten) benannt. Wenn eine Blase an das vordere Ende einer Durchsetzungskante 4707 (wie in 47A) gesetzt wird, hat sie andere Semantiken, als wenn die Blase an das hintere Ende einer Durchsetzungskante 4710, (wie in 45B), an das vordere Ende einer Überwachungskante 4712 (wie in 45C) oder an das hintere Ende einer Überwachungskante 4714 (wie in 45D) gesetzt wird.
Aktivierungseinflüsse für Konjunktionsknoten sind immer sichtbar in einem SCG: die Disjunktionsknoten, die auf der Seite des hinteren Endes von einfallenden Kanten erscheinen. Daraus ergibt sich, daß konjunktive Kanten nie benannt werden müssen. Disjunktionsknoten werden häufig auf Betriebsarten im System abgebildet; sie können daher verborgene Aktivierungseinflüsse haben. In diesen Fällen müssen Knoten benannt werden, um die Betriebsarten anzuzeigen, auf denen sie abgebildet sind. Es kann sein, daß es für alle Kanten nicht immer möglich ist, ihren Wert durchzusetzen. Kanten, für die dies nicht möglich ist, gelten als verletzt.
1. Instabilität und dynamische Eigenschaften
Obwohl SCGs statische Beziehungen zwischen Betriebsarten verkörpern, können sie durch instabile Konfigurationen (d.h. Konfigurationen, die temporär ungültig sind und daher Auflösung versuchen müssen) auch einige dynamische Eigenschaften modellieren. Man denke an das Verhalten eines Rendezvous-Koordinators 4800; er enthält Schnittstellen 4802, 4804, 4806 und 4808 für zwei Komponententypen: Ressourcenbenutzer 4810 und Ressourcen 4812. Rendezvous-Koordinator 4800 erlaubt Ressourcenbenutzern 4810 den Eintritt in eine Warte-Betriebsart 4814, und Ressourcen 4812 den Eintritt in eine verfügbare Betriebsart 4816. Wenn möglich, gibt Rendezvous-Koordinator 4800 gleichzeitig eine Wartekomponente 4818 und eine verfügbare Komponente 4820 frei. Dies kann vom SCG in 48B modelliert werden. Der SCG hat drei Konjunktionsknoten 4822, 4824 und 4826, die jeweils überwachen, ob (1) ein bestimmter Warteknoten 4828, 4830 oder 4832 und ein verfügbarer Knoten 4834 gleichzeitig aktiv sind, und ob es (2) aktive Warteknoten 4828, 4830 und 4832 gibt, die Vorrang haben. Wenn einer der Konjunktionsknoten 4822, 4824 oder 4826 zufriedengestellt ist, gibt er seinen entsprechenden Warteknoten 4828, 4830 oder 4832 und verfügbaren Knoten 4834 frei, was bewirkt, daß der Konjunktionsknoten 4822, 4824 oder 4826 aufhört zufriedengestellt zu sein.
Eine wichtige Eigenschaft eines SCG ist ASSP (any stable state property – irgendeine stabile Zustandseigenschaft). ASSP von SCGs gibt an, daß mindestens eine stabile Konfiguration besteht. Ein SCG hat angeblich diese Eigenschaft, wenn er mindestens eine Konfiguration hat, in der alle Beschränkungen gleichzeitig zufriedengestellt werden. Ein Graph ohne ASSP ist in 49 dargestellt. Bei dem Versuch, alle Beschränkungen durchzusetzen, ergibt sich ein inaktiver Knoten b 4900, der einen Knoten c 4902 zwingt, inaktiv zu sein, der seinerseits Knoten b 4900 zwingt, aktiv zu sein, der Knoten c 4902 zwingt, aktiv zu sein – wodurch Knoten b 4900 zur Inaktivität gezwungen und der Zyklus von neuem gestartet wird.
Es kann gezeigt werden, daß Auffinden von ASSP NP-Complete ist, was bedeutet, daß es wahrscheinlich keine allgemeinen effizienten Algorithmen gibt, mit denen bestimmt werden kann, ob ein SCG diese Eigenschaft hat. Ein 3-SAT-Problem – gut bekannt als NP-Complete Problem, das allgemein dazu benutzt wird, durch polynomische Zeitreduktion zu beweisen, daß andere Rechenprobleme NP-Hard sind, kann in polynomischer Zeit auf ASSP reduziert werden. 50A zeigt den SCG für ein 3-SAT-Problem. 50B zeigt das 3-SAT-Problem. 50C zeigt die repräsentativen charakteristischen Funktionen für das 3-SAT-Problem.
Zwei Durchsetzungskanten können konfliktieren und verursachen möglicherweise "Race Conditions" in bestimmten Konfigurationen. Um dies zu vermeiden, enthalten Kanten-Labels auch eine Priorität, um anzuzeigen, welche im Falle eines Konfliktes durchgesetzt wird. Gewöhnlich werden diese Prioritäten von den Koordinatoren bereitgestellt, die die Beschränkung definieren und daher die Durchsetzungskante. Obwohl Auffinden einer kompletten Beschränkungssystemlösung NP-Hard ist, ist es möglich eine Lösung vorzulegen, die in weniger als Exponentialzeit konsistent mit den Erwartungen eines Designers ist.
2. Petrinetz-Ähnlichkeiten
SCGs haben mehrere signifikante Ähnlichkeiten mit Petrinetzen. Petrinetze sind auch zweiteilige Digraphen mit den Knotentypen – Übergänge und Plätze. Ein Systemzustand wird durch die Markierung von Plätzen veranschaulicht, wobei jeder Platz entweder durch ein Token markiert oder überhaupt nicht markiert wird. Ein Übergang feuert, wenn auf jedem der Plätze auf der gegenüberliegenden Seite von eingehenden Kanten ein Token vorhanden ist. Wenn ein Übergang feuert, verzehrt er alle Aktivierunngs-Tokens und setzt Tokens auf jeden der Plätze auf der gegenüberliegenden Seite von ausgehenden Kanten.
Die hauptsächliche Ähnlichkeit zwischen Petrinetzen und SCGs besteht im konjunktiven und disjunktiven Verhalten von Übergängen und Plätzen. Die Art, wie ein Platz in einem Petrinetz markiert wird, gleicht der Art, wie ein Disjunktionsknoten in einem SCG geändert wird – denn einfallende Kanten manipulieren den Zustand direkt. Der Hauptunterschied besteht darin, daß bei Petrinetzen die einzige Möglichkeit, wie die Markierung eines Platzes aufgehoben werden kann, darin besteht, daß eine ausgehende Kante das Token entfernt. Bei SCGs sind die einzigen Konjunktionsknoten, die Zustandsänderungen verursachen können, die Knoten auf den eingehenden Kanten.
3. Konstruktion von SCGs
Bei der Konstruktion von SCGs kommen boolsche Beschränkungen aus einem Standard-Summenprodukt zum Einsatz. Eine standardmäßige boolsche Beschränkung ist ein Tuple (I, O, R, A), in dem

• I ein Satz von Input-Literalen ist.
• O ein Satz von Output-Literalen ist.
• R ein Satz von Disjunktionen auf Eingangswerten ist, d.h. R ⊆ 2^I.
• A ein Satz von Output-Literalen ist, die mit Konjunktionen auf Werte in R und Werte in C ⊆ OX2^R abgestimmt sind.

Algorithmus 1 zeigt, wie ein SCG anhand eines Satzes von Beschränkungen in einem System konstruiert wird.
Algorithmus 1 nimmt einen Satz von Betriebsarten und Beschränkungen und erstellt für jede Betriebsart einen neuen Disjunktionsknoten, und addiert für jede Beschränkung einen neuen Konjunktionsknoten. Für jedes linke Argument der Beschränkung addiert der Algorithmus eine neue Kante von dem Disjunktionsknoten, der dem Argument entspricht, zum Konjunktionsknoten. Für jedes rechte Argument der Beschränkung addiert der Algorithmus eine neue Kante vom Konjunktionsknoten zum Disjunktionsknoten, der dem Argument entspricht.
4. Nachweis von Beschränkungskonflikten
Der wichtigste Einsatz von SCGs besteht im Auffinden von Durchsetzungskonflikten. Beschränkungsdurchsetzungskonflikte treten auf, wenn zwei aktive Beschränkungen versuchen, einen Disjunktionsknoten in entgegengesetzte Richtungen zu zwingen. Da Beschränkungen mit Prioritäten versehen sind, können Konflikte während der Laufzeit zugunsten der Beschränkung mit höchster Priorität gelöst werden. Die Lösung auf diese Art und Weise kann jedoch unerwartetes, unerwünschtes Verhalten (d.h. Fehler) im eingebetteten System verursachen. Preemptive Fehlersuche, in Form von Konfliktnachweis, hilft Designern beim Einfangen solcher Probleme.
Es gibt zwei verschiedene Typen von Beschränkungskonflikten: Erster Ordnung und n-ter Ordnung. Konflikte erster Ordnung sind relativ problemlos nachzuweisen, aber der Nachweis von Konflikten n-ter Ordnung ist so schwer wie der Nachweis von ASSP. Eine Anzahl von Techniken kann benutzt werden, um die Komplexität des Nachweisens von Konflikten n-ter Ordnung zu reduzieren. Die erste Technik approximiert konservativ Konjunktionsknoten als Disjunktionsknoten. Diese Technik ist polynomisch und entdeckt alle möglichen Konflikte, sie kann aber auch eine Anzahl von falschen Positiva liefern. Die zweite Technik macht sich die hierarchischen Eigenschaften von konstruierten Systemen zunutze, wobei koordinationszentrische Modellierung zum Einsatz kommt, um Teilergebnisse zu erzielen; Für bestimmte SCGs, die man „well composed" (gut konstruiert) nennt, kann diese Technik Ergebnisse in polynomischer Zeit erbringen. Viele Subgraphen in typischen SCGs werden viele Male repliziert. In diesen Fällen kann die Replizierung dazu verwendet werden, Ergebnisse in polynomischer Zeit zu erbringen. Schließlich gibt es Subgraphen, die keine Beziehung zu anderen haben, und in diesen Fällen ist es möglich, sie separat zu analysieren.
A. Konflikte erster Ordnung
Konflikte erster Ordnung treten ein, wenn zwei potentiell koaktive Durchsetzungskanten entgegengesetzte Wirkungen auf denselben Disjunktionsknoten haben. 51A zeigt einen solchen Konflikt: wenn alle Knoten a, b, c bzw. d 5100, 5102, 5204 und 5106 gleichzeitig aktiv sind, gibt es einen Konflikt zwischen c ⋀ d 5110 und a ∧ b 5112. Da den konfliktierenden Kanten 5114 und 5116 Prioritäten zugeordnet sind, ist es leicht für ein Laufzeitsystem, dies dynamisch zugunsten von c ∧ d 5110 zu lösen.
Konflikte erster Ordnung sind leicht nachweisbar – man muß nur für jeden Disjunktionsknoten einfach alle Durchsetzungskanten feststellen, die sinngemäß konfliktieren, und sie zu ihren entsprechenden Konjunktionsknoten zurückverfolgen.
B. Konflikte n-ter Ordnung
51B zeigt einen potentiellen einfachen Konflikt zweiter Ordnung zwischen den Ausdrücken d ∧ g ∧ h 5118 und a ∧ b 5120. In diesem Fall bewirken die Priorität-Labels 5122, 5124 und 5126 der Kanten, daß der Ausdruck d ∧ g ∧ h 5118 bei Auftreten eines Konfliktes zwischen ihnen ignoriert wird. Zyklische Konflikte n-ter Ordnung sind besonders schlimm, weil sie Instabilität im zugrundeliegenden System – sogar mit Prioritätszuweisungen – verursachen können.
Das Feststellen und Beseitigen von Konflikten n-ter Ordnung ist ein anderes NP-Hard Problem, man muß daher auf praktische Techniken zurückgreifen, die angesichts der Merkmale von gängigen SCGs gute Resultate erbringen. Die Erfahrung hat gezeigt, daß diese Graphen häufig exponentielle Kontrollzustandsräume verkörpern, deshalb ist es wichtig, bei Konfliktnachweisen die Aufzählung des gesamten Kontrollzustandsraums zu vermeiden.
Algorithmus zeigt einen Konfliktnachweis-Algorithmus, der gewöhnlich eine gute Leistung erbringt. Der Algorithmus erzeugt eine komplette Schließung des SCGs, so daß Konflikte durch Konflikte im Output von Konjunktionsknoten identifiziert werden.
Die Konjunktion zwischen Ausdrücken wird durch einen einzelnen Konjunktionsknoten dargestellt, und ein potentieller Konflikt wird einzig und allein nur dann realisiert, wenn alle disjunktiven Zwischenknoten zufriedengestellt sind. In der Praxis weisen SCGs und die Systeme, von denen sie hergeleitet sind, oft Merkmale auf, die zum wirksamen Auffinden dieser potentiellen Konflikte ausgenutzt werden können.
Algorithmus 2 findet alle Disjunktionsknoten und nimmt für jeden von ihnen alle konsistenten Kanten und erstellt für jede einen neuen Konjunktionsknoten. Für jeden der neuen Konjunktionsknoten erstellt der Algorithmus neue Kanten (1) für jede Kante auf dem Konjunktionsknoten auf der Seite des hinteren Endes der linken Kante und (2) für jede Kante auf dem Konjunktionsknoten auf der Seite des vorderen Endes der rechten Kante. Die Konsistenzprüfung stellt sicher, daß keine Literalen in einem Konjunktionsknoten mit Literalen in dem anderen konfliktieren (z.B. wird falsch zurückgegeben, wenn c_j a enthält und c_k ¬a enthält). Die Abwesenheitsprüfung stellt sicher, daß der neue Knoten nicht redundant ist.
52A zeigt eine Position eines SCGs vor der Anwendung von Algorithmus 2 (Glättung) und 51B zeigt den SCG nach der Glättung. Eine neue Beschränkung zwischen den Endknoten 5200, 5202, 5204 und 5206 wird konstruiert; sie beinhaltet c_i 5210 und den Eintritt und Austritt von Kanten 5212, 5214, und 5216 in und aus c_i 5210. Die Beschränkung stellt den Kaskadeneffekt durch einen Knoten d_i 5208 hindurch dar.
Um für den benötigten Raum und die benötigte Zeit eine obere Begrenzung zu finden, sei angenommen, daß jeder mögliche konsistente, distinktive Konjunktionsknoten erstellt wird, und daß sich jeder dieser Knoten auf alle Disjunktionsknoten ausbreitet (Fan-Out). Das bedeutet, daß für n Disjunktionsknoten Raum für 3_n Konjunktionsknoten und 2n3ⁿ Kanten (höchstens n Kanten auf beiden Seiten jedes Konjunktionsknotens) benötigt werden. Unter der Annahme, daß eine riesige Mehrzahl dieser Knoten während der Ausführung des Alhorithmus erstellt wird, muß die Zeit ungefähr 4n3ⁿ betragen. Diese Raum- und Zeiterfordernisse sind äußerst empfindlich gegenüber dem anfänglichen Fan-In und Fan-Out von Knoten in dem Graphen, der anfänglichen Anzahl von Konjunktionsknoten und der Länge der nicht-zyklischen, selbst-konsistenten Pfade (d.h. Pfade, auf denen ein einzelner Änderungseffekt fortgepflanzt werden kann).
Nach Glättung des Graphen können wahre Konflikte durch Zurückverfolgen von Kantenpaaren, die auf einem Disjunktionsknoten verschiedene Werte geltend machen, sowie durch Festlegen, ob sich ihre Konjunktionsquellenknoten gegenseitig ausschließen, bestimmt werden. 53 zeigt ein Beispiel. Von c_i 5304 und c_k 5306 ausgehende Kanten 5300 und 5302 bilden einen potentiellen Konflikt 5308. Zur Bestimmung dessen, ob ein Konflikt existiert, werden die Literalen, die die entsprechenden Konjunktionen darstellen, verglichen, wobei unbenutzte Variablen als „don't cares" (gleichgültig) behandelt werden. Wie Tabelle 6 zeigt, tritt Konflikt 5308 für die Konfiguration d_i ∧ d_j ∧ ¬d_k ∧ d_i auf.
Tabelle 6 – Auffinden des Konflikts aus Fig. 54.
Algorithmus 2 hebt die Instabilität hervor, die durch einfache Zyklen dargestellt wird. Zum Beispiel ist die in 49 zu sehende Instabilität in 54 als vier einfache Zyklen 5400, 5402, 5404 und 5406 nach dem Glätten sichtbar.
Es sind mehrere Techniken verfügbar, um die Leistung von Algorithmus 2 für eine breite Vielfalt von SCGs zu verbessern. In den folgenden Unterabschnitten werden einige von ihnen beschrieben.
1. Approximierung disjunktiver Graphen
Von einem Sonderfall eines SCGs spricht man, wenn jede konjunktive Kante nur einen einzigen Input hat. In diesem Fall wird Algorithmus 2 zu einer Art Warshall-Algorithmus, in dem Konjunktionsknoten lediglich Beziehungen zwischen Disjunktionsknoten definieren. Wenn nur wenige Konjunktionsknoten mit mehr als einer einfallenden Kante vorhanden sind, kann jeder von ihnen durch mehrere Konjunktionsknoten mit einzelnen einfallenden Kanten ersetzt werden.
Dieser Ansatz ergibt eine konservative Approximierung der konfliktierenden Kanten mit der Möglichkeit einer großen Anzahl von falschen Positiva. Wenn die Anzahl der falschen Positiva, die den Designer betreffen, klein ist, können sie einzeln anhand des ursprünglichen Graphen verfiziert werden.
2. Hierarchische Reduktion
Es sei daran erinnert, daß ein Element einer Komponenten-Koordinationsschnittstelle ein Satz von Garantien ist. Garantien sind Zusammenfassungen von Komponenteneigenschaften, die bereits verifiziert sind. Diese Garantien können Zusammenfassungen interner Beziehungen zwischen Kontrollports auf der Schnittstelle beinhalten. 55A zeigt eine solche Zusammenfassung. Obwohl die tatsächliche Beziehung zwischen x 5500 und ¬y 5502 eine Anzahl von internen Knoten 5504, 5506, 5508 und 5510, wie in 55 dargestellt, beinhaltet, ist keiner dieser Knoten Teil der Schnittstelle; deshalb können sie zu einem einzelnen unabhängigen, mit einem „?" markierten Knoten 5512 zusammengefaßt werden, wie in 55B gezeigt.
Da unsere Methodologie einen hierarchischen Aufbau fördert, kann stabile Zustandskonsistenz oft hierarchisch auf diese Graphen angewandt werden. Bei diesem Ansatz stellt jede Komponente eine Zusammenfassung der Beziehungen zwischen allen Schnittstellen-Betriebsarten bereit. Bei einem auf diese Art konstruierten (well composed) System (wie in 56 dargestellt) ist die Anzahl der in jedem Geltungsbereich sichtbaren Knoten kleiner als eine angemessene Konstante c, und das Verhältnis der Anzahl der Nicht-Schnittstellenknoten innerhalb eines Geltungsbereichs zur Anzahl der Schnittstellenknoten ist immer größer als ein Konstantenfaktor d, worin d > 1. Ausgehend hiervon sind
verschiedene Geltungsbereiche zu analysieren, und die für jeden Geltungsbereich benötigte Zeit ist dann kleiner als oder gleich 4c3^c; somit ist die für einen ganzen gut konstruierten Graphen benötigte Zeit:
welches als t ≤ Pn lg n ausgedrückt werden kann, worin P die Konstante
Das bedeutet, daß hierarchische stabile Zustandskonsistenz für gut konstruierte Graphen gleich O (n lg n) ist.
Obwohl es nicht möglich ist, beliebige Systeme zur Annahme dieser Konstruktion zu zwingen, ist es möglich, vor Einsatz dieser Technik zu bestimmen, ob ein System gut konstruiert ist. Des weiteren kann das System für Komponenten, die mit Modellen ausgestattet sind, immer noch die Wechselwirkungszusammenfassung benutzen. Da die Zusammenfassung mit Komponenten in den Cache-Speicher kopiert werden kann, können die Kosten für die Vorbereitung über viele Analysierungsversuche hinweg getilgt werden.
3. Ausnutzung von Replizierungen
Es gibt viele Protokolle mit einer großen Anzahl von angeschlossenen Komponenten, aber die Wechselwirkung zwischen den Komponenten hat nichts mit ihrer Anzahl zu tun. In Protokollen wie Token Ring oder Subsumption, in denen die Schnittstelle mit vorhersagbaren Beziehungen zwischen Instanzen repliziert wird, ist es möglicherweise nicht notwendig, alle möglichen Konflikte zwischen allen Komponenten zu verifizieren. Zum Beispiel ist bei Subsumption die Wechselwirkung zwischen den Komponenten und dem Protokoll sauber, und Konflikte zwischen Komponenten sind minimal. Die Konflikte zwischen einer Komponente und einem Protokoll können als unabhängig von den anderen, an ein Protokoll angeschlossenen Komponenten behandelt werden, so daß die Komponente einfach dem Protokoll gegenüber geprüft werden kann.
4. Orthogonale Reduktion
Wechselwirkungen zwischen Schnittstellen in einem geschichteten System erfolgen oft durch opake Handlungen hindurch. Folglich kann jede Schicht als separate Entität betrachtet werden, und der Graph für jede Schicht kann unabhängig von anderen Graphen konstruiert werden. In diesen Fällen muß bei Glättung nicht das System als Ganzes betrachtet werden, sondern es genügt, lediglich die Subgraphen für jede bestimmte Schicht zu betrachten.
Dynamische Kontrollgphen
Ein dynamischer Kontrollgraph (DCG) beinhaltet reine Kontrollhandlungen sowie reine Kontrollbeschränkungen. DCGs können als Triple (Γ_d, D_d, E_e) definiert werden, worin:

• Γ_d ein Satz von Konjunktionsknoten und Handlungsknoten ist, d.h., Γ_d ⊆ (C ∪ A), worin C die Gesamtheit aller möglichen Konjunktionsknoten ist und A die Gesamtheit aller möglichen Handlungen ist.
• D_d ein Satz von Disjunktionsknoten ist.
• E_e ⊆ [{T_f, T_t} × {H_f, H_t} × {T, N} × {Γ_d, D_d} ∪ (D_d × Γ_d])] ein Satz von gerichteten Kanten ist, die entweder mit Transient (T) oder Continuous (N) benannt sind.

57 veranschaulicht einen DCG 5700. In 57 ist eine reine Kontrollhandlung (nicht dargestellt) eine transparente Handlung, die nur durch einen Kontroll-Transient ausgelöst wird, und die nur einen Kontroll-Transient erzeugt. Im DCG 5700 wird die reine Kontrollhandlung als Konjunktionsknoten, als Handlungsknoten 5702, mit gestrichelten Kanten 5704 und 5706 dargestellt. Eine reine Kontrollbeschränkung (nicht dargestellt) ist eine Beschränkung, die nur Betriebsarten (nicht dargestellt) beschränkt. Wie oben beschrieben, sind zwei Handlungstypen möglich: eine sofortige Handlung oder eine verzögerte Handlung. Die sofortige Handlung wird sofort bei Empfang des Auslösers ausgeführt, und die verzögerte Handlung wird zu irgendeinem Zeitpunkt nach dem Empfang des Auslösers ausgeführt. Die Verzögerung einer Handlung ist in ihrem Handlungsknoten 5702 verkörpert.
58 veranschaulicht einen DCG 5800 mit einem Handlungsknoten 5802. In 58 hat der Handlungsknoten 5802 keinen sichtbaren Auslöser. Dabei kennzeichnet DCG 5800 vollständig alle Kontrollaspekte der Handlung (obwohl der Datenaspekt, der in diesem Fall ein Auslöser ist, in keinen Kontrollgraph aufgenommen wird). 59 zeigt einen DCG 5900 für eine Handlung (nicht dargestellt), die mit Bezug auf Kontrollwechselwirkungen transparent ist. 60 zeigt einen DCG 6000 für eine Handlung (nicht dargestellt), die mit Bezug auf Kontrolle opak ist; der Graph zeigt eine konservative Approximierung des Kontrollverhaltens der Handlung.
Wie früher erwähnt, ist es besser, Koordinatorübergänge durch explizite Handlungen, nicht durch Instabilität statischer Kontrollgraphen (SCG) zu modellieren. 61A und 61B zeigen zwei DCGs 6100 und 6102 für Rendezvous-Koordinator 900 von 9, bzw. für einen Rendezvous-Koordinator mit Zwei-Teilnehmer-Preemption. In 61A und 61B gibt es (nicht dargestellte) n-Kontrollhandlungen (eine für jede (nicht dargestellte) Komponente mit einer (nicht dargestellten) Warte-Koordinationsschnittstelle). Jede der n-Kontrollhandlungen ist in den DCGs 6100 und 6102 durch einen Handlungsknoten 6104 dargestellt, und jeder Handlungsknoten ist durch die Konjunktion aller Warte-Betriebsarten 6106 geschützt, wobei niedrige Priorität inaktiv ist. Wenn eine Handlung aktiviert und ausgelöst wird, deaktiviert sie ihre entsprechende Warte-Betriebsart 6106 und eine Verfügbarkeits-Betriebsart 6108.
DCGs legen verborgene Wechselwirkungen zwischen Koordinatoren frei. Wie in 61B dargestellt, zeigt DCG 6102, daß zwischen wait_b und wait_c der Warte-Betriebsarten 6106 außerhalb des Rendezvous-Koordinators eine Wechselwirkung mit Zwei-Teilnehmer-Preemption auftritt. Die Wechselwirkung ist als Kombination der Kanten 6110 und 6112 und des Preempt-Handlungsknotens 6114 dargestellt. Wie zu sehen ist, kann die Wechselwirkung bewirken, daß wait_c das Warten von wait_b auf die Ressource abfängt.
A. Partitionierung von SCGs und DCGs über Nur-Handlungs-Barrieren hinweg
Eine nützliche Transformation statischer Graphen, die sowohl auf SCGs als auch auf DCGs durchgeführt werden kann, ist die Partitionierung über Nur-Handlungs-Barrieren hinweg. Eine Nur-Handlungs-Barriere ist eine Barriere innerhalb des Systems, über die hinweg Zustand nicht aufrechterhalten werden kann. 62A zeigt einen Kommunikationskanal zwischen Partitionen eines SCG 6200, der eine Nur-Handlungs-Barriere verursachen kann. 62B zeigt einen DCG 6202, der dem SCG 6200 nach Partitionieren über die Nur-Zugriffs-Barriere hinweg entspricht. Wenn man dies auf DCGs anwendet, bleiben alle Übergangskanten unverändert.
Zur Durchführung der Transformation über Nur-Handlungs-Barrieren hinweg werden folgende Schritte durchgeführt. Erstens werden die Knoten innerhalb von SCG 6200 identifiziert, die auf jede Seite der Nur-Handlungs-Barriere plaziert werden (in anderen Worten, es ist ein Graph-Schnitt über die Barriere hinweg durchzuführen, wie in 62A dargestellt). Zweitens wird jede Beschränkungskante, welche die Nur-Handlungs-Barriere schneidet, durch eine entsprechende Vorlage ersetzt. 63 veranschaulicht Beschränkungskanten 6300 und 6302, die die Nur-Handlungs-Barriere schneiden, von 62A, und ihre entsprechenden Vorlagen 6304 und 6306. Schließlich wird ein im letzten Schritt erstellter Handlungsknoten mit einer Handlung gefüllt, die auf die Aktivierung (oder Deaktivierung) des Disjunktionsknotens d gegenüber der einfallenden Kante reagiert.
B. Handlungs-Beschränkungskonflikte
Es ist möglich, daß eine Handlung während der Ausführung eines Softwaresystems mit stabilen Zuständen konfliktiert. Wenn die Handlung eine höhere Priorität als eine Beschränkung auf dem stabilen Zustand hat, tritt bei jedem Ausüben der Situation eine Art Störung ein. Die Störung läßt auf einen Systemzustand schließen, der Tatsache oder nicht Tatsache ist. Die Wirkungen der Störung können sich jedoch durch den Rest des Systemsoftwaresystems fortpflanzen, auch wenn der durch die Störung angedeutete Systemzustand nicht tatsächlich eingetreten ist. Wenn andererseits die relevante Beschränkung eine höhere Priorität als die Handlung hat, kann die Handlung nicht in einer gegebenen Systemkonfiguration durchgeführt werden und muß gegebenenfalls aus dem Softwaresystem entfernt werden.
C. Konflikte zwischen Handlungen
Eine Handlung kann zuweilen mit einer anderen Handlung konfliktieren. Konflikte zwischen Handlungen werden unter Einsatz ähnlicher Prüfungen wie solcher für stabile Zustandskonsistenz nachgewiesen. Diese Prüfungen können gelegentlich zwei oder mehr Triples mit sich überlappenden Betriebsarten und Auslösern, aber mit sich widersprechenden Handlungen zurücklassen. Diese sich widersprechenden Handlungen können auf mehrere Weisen, manche statisch und manche dynamisch, gelöst werden. Eine statische Lösung für die sich widersprechenden Handlungen besteht darin, alle möglichen konfliktierenden Teile eines der Triples konservativ zu beseitigen. Eine Laufzeit-Lösung besteht beispielsweise darin zu erlauben, daß sich die konfliktierenden Handlungen durch den Rest der Triples fortpflanzen, und den Konflikt aufgrund von Priorität zu lösen, wenn die Zeit gekommen ist, die neue Konfiguration zu verriegeln.
4. Modellprüfung
SCGs und DCGs können direkt für eine große Vielfalt von Prüfungen verwendet werden, wobei das in bestimmten Konfigurationen Erlaubte und die Wirkungen, die sich aus Änderungen im kleinen Rahmen ergeben, in Kauf genommen werden. Wenn jedoch Eigenschaften zu prüfen sind, die möglicherweise mehrere verschiedene Systemkonfigurationen in einer Folge umspannen, können andere Transformationen diese Prüfungen wirksamer durchführen.
Modellprüfung beschreibt Techniken, in denen endliche Zustandssystemmodelle gegenüber Prädikaten in temporaler Logik geprüft werden. Kontrollgraphkonfigurationen, sowohl SCGs wie auch DCGs, veranschaulichen den systemweiten Zustand für ein Softwaresystem; daraus folgt also, daß viele abstrakte Kontrollgrapheigenschaften anhand von normaler Modellprüfung verifiziert werden können. Ein binäres Entscheidungsdiagramm (BDD) kann eine kompakte, wenn auch nicht immer optimale Darstellung von Übergangsbeziehungen einer extrem großen Zustandsmaschine sein. BDDs sind oft Darstellungen des systemweiten Zustands, die mit Bezug auf die Größe des Zustandsraums des Softwaresystems logarithmisch sind. SCGs und DCGs sind ebenfalls kompakte Darstellungen großer Zustandsräume. Es gibt jedoch viele Standardprüfungen, die sich leicht auf BDD-Darstellungen durchführen lassen, während sie bei SCG- und DCG-Darstellungen Schwierigkeiten bereiten würden.
Um die Standardprüfungen, die für BDDs verfügbar sind, zu nutzen, können Ausführungsformen gemäß der vorliegenden Erfindung ein System und ein Verfahren zum Konvertieren von SCGs und DCGs in BDDs beinhalten, ohne den Zustandsraum des Softwaresystems vollständig ausarbeiten zu müssen.
A. Temporales Entrollen
64 veranschaulicht einen aktuellen DCG 6400 zusammen mit einem nächsten DCG 6402, welcher das Ergebnis des temporalen Entrollens von DCG 6400 ist. In 64 trennt eine temporale Linie 6404 den aktuellen DCG 6400 vom nächsten DCG 6402. Temporales Entrollen des aktuellen DCGs 6400 gestattet es, eine aktuelle Kontrollgraphkonfiguration des DCG, wie im aktuellen DCG 6400 verkörpert, mit einem Satz von nächsten Konfigurationen des DCG, wie im nächsten DCG 6402 verkörpert, für ein bestimmtes Softwaresystem in Beziehung zu setzen. Das Entrollen des aktuellen DCG 6400 über die temporale Linie 6404 hinweg beinhaltet das Erstellen einer Kopie rechts der temporalen Linie 6404 von allen Disjunktionsknoten, Beschränkungen und allen nicht-verzögerten Handlungen innerhalb des aktuellen DCG 6406. Aus Gründen der Klarheit wird zum Label jedes kopierten Elements ein Strich (Prime) hinzugefügt. Für jede verzögerte Handlung innerhalb des aktuellen DCG 6400 wird eine Überwachungskante 6406 mit jedem entsprechenden ungestrichenen Knoten 6408, und eine Durchsetzungskante 6410 mit jedem entsprechenden, gestrichenen Knoten 6412 verbunden. Wenn eine Überwachungskante eine Ereigniskante ist, müssen einige zusätzliche Knoten erzeugt werden. Für eine Ereignisüberwachungskante 6414 wird ein neuer Disjunktionsknoten 6416, der das Ereignis selbst darstellt, erzeugt. Ein neuer Konjunktionsknoten 6418 verknüpft den neuen Konjunktionsknoten 6418 wieder mit einem Erzeugungsknoten 6420, der das Ereignis erzeugte, und beschränkt entsprechend den Zustand und gestrichenen Zustand des neuen Konjunktionsknotens 6418 (z.B. a + f Ereignis kann nur eintreten, wenn f bereits deaktiviert ist, f' bleibt jedoch, wie dargestellt, aktiviert).
Dieser entrollte DCG hat folgende charakteristische Funktion: fc = (¬α ∨ ¬b ∨ c) ∧ (¬α' ∨ ¬b' ∨ c') ∧ (¬f ∨ ¬ + f) ∧ (¬ + f ∨ + f') ∧ (¬e ∨ ¬ + f ∨ b') ∧ (¬e ∨ ¬ + f ∨ ¬g')
In dieser Funktion ist jetzt die Beziehung zwischen der aktuellen und der nächsten Konfiguration verkodet, die beschriftet ist mit
C → c C'
für Konfigurationen C und C'.
65A veranschaulicht einen einfachen DCG 6500. 65B veranschaulicht einen entrollten DCC 6502 für den einfachen DCG 6500. In 65A und 54B ist die charakteristische Funktion des entrollten DCGs 6502 wie folgt: fc = (¬α ∨ c) ∧ (¬c ∨ ¬ + c) ∧ (¬ + c ∨ ¬α') ∧ (¬α' ∨ c') ∧ (¬ + c ∨ c')und seine Übergangsbeziehung ist in Tabelle 7 spezifiziert.
Tabelle 7: Eine Übergangsbeziehung für die charakteristische Funktion des entrollten DCG 6502.
B. CTL (Computation Tree Logic)
Bei Verwendung von Modellprüfung wird eine Prädikatenlogik benötigt, die stark genug ist, die temporalen Zustandsbeziehungen auszudrücken, die geprüft werden sollen. CTL ist ein Supersatz der oben eingeführten temporalen Logik, und sie enthält zwei neue Operatoren: X (für neXt (Nächste)) und U (für Until (Bis)). AXΦ ist wahr in der Gegenwart, wenn Φ in allen möglichen nächsten Zuständen wahr ist. EXΦ ist wahr in der Gegenwart, wenn Φ in mindestens einem der möglichen nächsten Zustände wahr ist. A (Φ₀ U Φ₁) ist wahr in der Gegenwart, wenn auf allen ausgehenden Pfaden Φ₀ so lange wahr ist, bis Φ1 wahr wird.
Die Lambda-Rechenmethode sieht eine flexible Form zur Darstellung temporaler Logikausdrücke vor: Lambda-Ausdrücke (d.h. Ausdrücke der Form λx·E) werden oft zur Darstellung von Functionals oder Funktionen, die mit anderen Funktionen arbeiten, benutzt. Der Ausdruck λx·Ep stellt den Ausdruck E dar, wobei p jedes Vorkommen von x ersetzt.
Zum Beispiel ist λx·(x + y)3 äquivalent zu (3 + y), und λx·(x + y)3y + z ist äquivalent zu (3y + z + y) oder (4y + z).
Bei Einsatz dieses Ausdrucks in CTL, ist zuerst folgendes zu bedenken:
S |= EXΦ
ist äquivalent zu
∃y(S → c y ∧ y |= Φ);
die Notation
S_α |= Φ
zeigt an, daß Φ in Zustand S_α wahr ist.
Folglich wäre ein Lambda-Ausdruck, der alle Konfigurationen darstellt, für welche Prädikat Φ auf dem nächsten Schritt auf irgendeinem Pfad wahr ist, EXΦ = λx·∃C·((x → c C) ∧ (C |= Φ))
Dies definiert EXΦ als Functional, welche auf eine Konfiguration Z angewendet werden kann, und welche zu wahr ausgewertet wird, wenn – und nur wenn –
Z |= EXΦ.
Bei Einsatz desselben zusammen mit boolschen Funktionen, welche die Übergangsbeziehung und alle Konfigurationene darstellen, für die Φ wahr ist, kann eine zusätzliche boolsche Funktion abgeleitet werden, die alle Konfigurationen darstellt, für welche EXΦ wahr ist.
Man sehe sich nochmals den Graphen in 65 an. Die charakteristische Funktion des entrollten DCG 6502 ist fc = (¬α ∨ c) ∧ (¬α' ∨ c') ∧ (¬c ∨ ¬α').
Um eine Funktion zu finden, die alle Konfigurationen darstellt, derart, daß EXΦ worin Φ gleich α ∨ c, ergibt sich: EX(α ∨ c) = ∃C'·(fc ∧ C' |= (α ∧ c)) = ∃C'·(fc ∧ (α' ∧ c')) = ∃C'·((¬α ∨ c) ∧ (¬α' ∨ c') ∧ (¬c ∨ ¬¬α') ∧ α' ∧ c') = ∃C'·¬α ∧ ¬c ∧ α' ∧ c') = ¬α ∧ ¬c
Und so wurde unter Einsatz der Lambda-Rechenmethode, Version
EX(α ∧ b)
und einer boolschen Manipulation der Ausdruck
(¬α ∧ ¬b)
erhalten, der gleich dem Ausdruck
EX(α ∧ b)
im Sinne dieses bestimmten Kontrollgraphen ist.
Ein Fixpunkt eines Lambda-Ausdrucks (L) ist ein Ausdruck (F), derart, daß LF = F. Zum Beispiel, wenn
L = λx·(x ∨ y) und F = wahr, LF = wahr ∨y = wahr,
und somit ist wahr ein Fixpunkt von L. Der kleinste Fixpunkt des Lambda-Ausdrucks λx·Ex ist notiert mit μx·Ex, und der größte Fixpunkt ist notiert mit vx·Ex. Unter Einsatz dieser kann man zwei weitere funktionellen Darstellungen beschreiben: EFΦ = μY·(Φ ∨ EXY) EGΦ = νY·(Φ ∧ EXY)
C. Binäre Entscheidungsdiagramme (BDDs)
Der schwächste Punkt bei symbolischer Modellprüfung ist die Tatsache, daß boolsche Manipulation NP-hard ist und im Speicher eines Computers große Mengen Platz einnehmen kann. Es hat sich jedoch gezeigt, daß für eine große Problemklasse binäre Entscheidungsdiagramme wirksame Darstellungen für Übergangsbeziehungen von Zustandsmaschinen bereitstellen können, die sich leicht manipulieren und kombinieren lassen. Ein BDD ist eine reduzierte Darstellung einer Wahrheitstabelle für eine boolsche Funktion. Obwohl jede boolsche Funktion als Wahrheitstabelle dargestellt werden kann, ist die Wahrheitstabelle relativ zur Anzahl der Variablen in der boolschen Funktion größenmäßig exponential. Eine Wahrheitstabelle kann als Baum dargestellt werden, in welchem jede boolsche Variable Knoten entspricht und jede Zuweisung von Werten einer gerichteten Kante entspricht. 66A zeigt eine Wahrheitstabelle 6600 für eine boolsche „und" Funktion 6602. 66B zeigt einen Wahrheitsbaum 6604, der der Wahrheitstabelle 6600 entspricht.
Auffinden des Wahrheitswertes einer Zuweisung wird wie folgt durchgeführt. Beginnend an der Wurzel werden so lange Kanten überquert, bis ein Blattknoten erreicht wird. Die jeweilige Kante, die ausgehend von jedem Knoten überquert wird, wird mit dem Wert benannt, der der entsprechenden boolschen Variable zugewiesen ist. Der erreichte Blattknoten enthält den Wahrheitswert der Zuweisung.
67A, B und C zeigen mehrere reduzierte BDDs 6700, 6702 nd 6704 für den in 66B dargestellten Wahrheitsbaum 6604. Die Prozedur zum Nachschlagen von Wahrheitswerten besteht darin, an der Wurzel zu beginnen und die mit dem der entsprechenden Variable zugewiesenen Wert benannten Kanten zu überqueren.
Während die Anzahl der Knoten in einem Wahrheitsbaum exponentiell zur Anzahl der Variablen in einer entsprechenden Funktion wächst, ist auch oft ein BDD zu finden, das nur polynomisch wächst. Die Reduktion eines BDDs wird mit Hilfe eines Cache-Speichers durchgeführt, in dem reduzierte Subgraphen gespeichert werden können. Dieser Cache-Speicher kann eine Hash-Tabelle sein. Im Reduzierungsalgorithmus, wie offenbart in BRYANT, R. E. Symbolic Boolean Manupulation with ordered Binary-decision Diagams, ACM Computing Surveys 24, 3 (September 1992), 293–318, sei angenommen daß jeder BDD-Knoten ein Tuple (n, 1. R) ist, wobei n der Name der entsprechenden Variable, 1 das mit der linken Kante verbundene BDD und r das mit der rechten Kante verbundene BDD ist. Des weiteren hat ein BDD-Cache-Speicher zwei Operationen – (1) Plazieren (BDD) zum Plazieren der BDDs in den Cache, und (2) Nachschlagen (Name, BDD, BDD) (wobei die BDD-Parameter die Subgraphen 1 und r des gespeicherten BDDs sind) – zum Auffinden von bereits gespeicherten BDDs und gibt eine Null zurück, wenn keine gefunden werden.
Somit kann ein BDD für jede boolsche Funktion erzeugt werden, indem seine Wahrheitstabelle in Form eines Wahrheitsbaums spezifiziert und der unten als Algorithmus 3 gezeigte „Reduzierungs"-Algorithmus aufgerufen wird. Dieser Ansatz leidet jedoch noch unter exponentiellem Wachstum, da exponentieller Raum für den Wahrheitsbaum benötigt wird, bis das BDD konstruiert ist. BDDs können jedoch effizient und methodisch unter Einsatz einer im „Apply-Algorithmus" verkörperten, unten als Algorithmus 4 dargestellten Prozedur entwickelt werden, wie in BRYANT, R. E. Symbolic Boolean Manupulation with ordered Binary-decision Diagrams, ACM Computing Surveys 24, 3 (September 1992), 293–318, offenbart. „Apply" erzeugt ein BDD, welches eine arbiträre boolsche Operation darstellt, die auf zwei BDDs angewandt wird, d.h. Br so daß Br = B1opB2.
Der Apply-Algorithmus wird von Shannon-Erweiterungen der Funktionen, die von den Input-BDDs dargestellt werden, abgeleitet. Eine Shannon-Erweiterung stellt eine boolsche Funktion als Ausdruck dar, der Teilbewertungen enthält. Zum Beispiel Erweiterung f(x, y, z) im Sinne von x: f(X, y, z) = (x ∧ f(l, y, z)) ∨ (¬x ∧ f(0, y, z))was natürlich im Sinne von y und z weiter erweitert werden kann. Sie ist typisch wie folgt notiert: f = (¬x ∧ f|x←0p) ∨ (x ∧ f|xn).
Dies ist auch als Kofaktor-Erweiterung einer Funktion bekannt. Eine Shannon-Erweiterung von f op g ist: f op g = ¬[x ^ (f |x ← 0 op g| x ← 0)] ∨ [x ∧ (f|x ← 1 op g|x ← 1)
Algorithmus 3 BDD reduce
Algorithmus 4 BDD apply.
D. BDD Darstellungen von Kontrollgraphen
Ein BDD kann oft zur Darstellung von Übergangsbeziehungen mit exponentiellen Zustandsräumen bei Einsatz von nur polynomischem Speicherplatz verwendet werden. Ein BDD kann aufgrund eines Kontrollgraphen durch Entrollen desselben, wie oben beschrieben, erzeugt werden, und dann kann unter Einsatz des oben beschriebenen Apply-Algorithmus ein BDD aufgrund einer charakteristischen Funktion für den entrollten Kontrollgraph erstellt werden. Zur wirksamen Darstellung des Zustandsraums ist wichtig, daß die Variablen-Reihenfolge innerhalb der charakteristischen Funktion beachtet wird. Gute Reihenfolgen haben aneinander angrenzende Folgen von stark zusammenhängenden Variablen.
Man betrachte DCG 6102, welcher den entrollten drei-Client-Rendezvous/Preempt-Koordinator in 61 darstellt. Dieses Beispiel ist interessant, weil der dargestellte Zustandsraum exponentiell mit der Anzahl der Teilnehmer wächst. BDD-Darstellungen wären wenig nützlich für unsere Zwecke, wenn sie während der Erstellung exponentiell wächsen würden, oder wenn sie einen exponentiellen Speicher benötigen würden. Wie im Folgenden dargestellt, stellen BDDs kompakte Darstellungen für solche Beispiele bereit.
68 zeigt die Ergebnisse, wenn ein Apply-Algorithmus zur Erstellung eines BDD 6800 verwendet wird, welches die charakteristische Funktion des entrollten DCG 6502 von 65 darstellt.
Ein entrollter DCG enthält eine Menge Information, die einem Designer helfen kann, eine wirksame Variablen-Reihenfolge zu finden. Beschränkungen und Pseudo-Beschränkungen (d.h. solche die beim Entrollen eingeführt werden) verbinden Variablen, bei denen mit Bezug zueinander die wenigsten Änderungen zu erwarten sind. Zum Beispiel, bei den Beschränkungen
{..., C ⇒ ¬G, C ⇒ B, B⇒C, ...}
Wenn C ⇒ ¬G nicht bestritten wird, wissen wir, daß ziemlich wahrscheinlich ist, daß C und G in der Variablen-Reihenfolge nebeneinander stehen. Allerdings bedeutet C ⇒ B und B ⇒ C, daß es noch wahrscheinlicher ist, daß B und C nebeneinander stehen.
69A zeigt einen entrollten Rendezvous-DCG 6900. Der entrollte DCG 6900 in 69A wird durch temporales Entrollen von DCG 6102 erstellt, welcher den mit Bezug auf 61 beschriebenen Rendezvous-Koordinator darstellt. Die charakteristischen Funktionen für den entrollten Rendezvous-DCG 6900 sind wie folgt: fα = waita ∧ (¬waitb ∧ ¬waitc) ∧ avail ⇒ ¬wait'a, ¬avail' fb = waitb ∧ ¬waitc) ∧ avail ⇒ ¬wait'b, ¬avail' fc = waitc) ∧ avail ⇒ ¬wait'c, ¬avail'
Der DCG zeigt, daß waitxS durchaus neben ihren entsprechenden wait'xS angeordnet werden könnten, wobei eine gute Reihenfolge waita, wait'a, waitb, wait'b, waitc, wait'c, avail, avail' wäre. Die obige Variablen-Reihenfolge ergibt ein BDD, welches fünfzehn Knoten hat, die als temporales Cluster bezeichnet werden können.
Es gibt noch weitere Verbesserungsmöglichkeiten: man beachte, daß jeder der gestrichenen Warteknoten abhängig ist von im Graphen daneben oder darunter liegenden ungestrichenen Warteknoten-Versionen (z.B. wait'a ist abhängig von waita, ¬wait_b und ¬wait_c). Dies deutet darauf hin, daß in einem BDD waita, waitb und waitc alle wait'a vorausgehen sollten, waitb und waitc wait'b vorausgehen sollten, usw. Dies, in Kombination mit der im letzten Absatz vorgeschlagenen Reihenfolge-Beschränkung zeigt an, daß waitc, wait'c, waitb, wait'b, waita, wait'a, avail, avail' eine sehr gute Reihenfolge ist. Daraus ergibt sich in der Tat ein BDD mit elf Knoten. Diese Variablen-Reihenfolge wird als Cluster/Depend bezeichnet. Obwohl Cluster/Depend nur wenig besser ist als die im vorhergehenden Beispiel angegebene Reihenfolge, ist es von Vorteil, wenn die Anzahl der Rendezvous-Warteteilnehmer über drei hinaus ansteigt. Wie in Tabelle 8 dargestellt, erstellt die einfache temporale Cluster-Reihenfolge BDDs, die beständig viermal soviele Knoten wie Variablen haben. Die Cluster/Depend-Reihenfolge erstellt BDDs, die nur ungefähr das Doppelte der Anzahl von Teilnehmern haben. Beide sind jedoch von der Größe her linear, basierend auf der Anzahl von Teilnehmern. Dies ist viel besser als die boolsche Ausdrucksform der charakteristischen Funktion, die quadratisch zur Anzahl der Teilnehmer ansteigt.
Tabelle 8: Wachstumsrate für BDDs, die temporal entfaltete Rendezvous darstellen
69B zeigt, daß der kritische Faktor für die Reihenfolge bei diesem DCG lediglich die Reihenfolge von waitc, waitb und waita relativ zueinander ist. Die Reihenfolge in 69B ist qualitätsmäßig gleichwertig zur Qualität in Cluster/Depend.
Anhand dieser kompakten und kanonischen symbolischen Darstellungen von exponentiellen Zustandsräumen für Rendezvous-Koordinatoren und andere Koordinatoren lassen sich Modellprüfungstechniken für preemptive Fehlersuche anwenden, wobei viele Fehler gefunden werden, bevor die Implementierungssoftware synthetisiert, kompiliert und eingesetzt wird.
E. Anwendung von Modellprüfung
Bei Modellprüfung kommt der AndExists Algorithmus von McMillan zum Einsatz, wie unten in zwei Teilen, Algorithmus 5 und Algorithmus 6 dargestellt.
Algorithmus 5 BDD AndExists Teil 1.
Algorithmus 6 BDD AndExists Teil 2
AndExists wertet aus: λx·∃V·(p ∧ q)wobei p und q als BDDs dargestellte boolsche Ausdrücke sind und Y ein boolscher Zuweisungsvektor
(v_i∊ {false, true}) ist.
In Verbindung mit EXΦ = λx·∃C·((x → c C) ∧ (C |= Φ))
Kann EXΦ berechnet werden.
Durch gleichzeitige Prüfung vieler Komponenten können viele Systemeigenschaften vertfiziert werden. Einige Beispiele für Deadlock
(∃S:S |= AG false)
Und Livelock
(∃S:S |= AFS).
Eine wichtige Prüfung ist die Bestimmung, ob ein Softwaresystem immer auf einem konsistenten Zustand konvergiert. Wenn ein DCG auf mehrere Subsysteme aufgeteilt ist (z.B. bei Multiprozessor-Architektur), wird eine Nur-Handlungs-Barriere zwischen den Teilen jedes Subsystems errichtet. Die überquerenden Handlungen weisen häufig Verzögerungen auf, die mehrere Planungsschritte umspannen, und diese Verzögerungen sind oft Funktionen des Busverkehrs oder anderer Faktoren. Um ein solches System in Einklang mit den hier beschriebenen Semantiken zu bringen, ist es erforderlich alle Subsysteme zu synchronisieren, damit Handlungsverzögerungen nie größer als ein einzelner Planungsschritt sind. Dies ist jedoch für ein Ausführungsmodell zu konservativ, wobei einige der Vorteile der Multiprozessor-Architektur verlorengehen. Oft ist es sinnvoller, möglichst asynchrone Wechselwirkung der Komponenten zu gestatten und sicherzustellen, daß das System immer in einem konsistenten Zustand endet. Zu diesem Zweck ist es notwendig, ein Ausführungsmodell zu wählen, welches Asynchronie darstellt.
Verschachtelte asynchrone Modelle gehen davon aus, daß Prozesse jederzeit Zustandsänderungen – jeweils die Änderung eines Zustands – vornehmen können. Diese Annahme ist jedoch möglicherweise zu konservativ, da mehrere Korrelationen zwischen Zustandsbits auf einer einzelnen Komponente vorgenommen werden können. Genauer ist die Aussage, daß jede Komponente jederzeit eine lokal legale Kontrollzustandsänderung vornehmen kann. Wie in 70A, B, C und D dargestellt, bedeutet dies, daß einen Moment, nachdem die Konfiguration von 70A gültig ist, jede der Konfigurationen in 70B oder 70C gültig sein kann. Jedoch kann die Konfiguration in 70B nicht gültig sein, weil sie zwei gleichzeitige Zustandsänderungen reflektiert. Da jedoch diese Änderungen gleichzeitig eintreten, kann sich nach zwei Zeitschritten der Konfiguration 70A die Konfiguration in 70D ergeben.
F. Look-Ahead Prädikate
Bei Einsatz von Modellprüfung zur Durchführung von Abfragen, die eine bestimmte Eigenschaft in einem DCG betreffen, wird eine boolsche Funktion erzeugt, die alle Konfigurationen identifiziert, für die sie wahr ist.
Bei der Fehlersuche in einem System wollen Designer verfolgen, ob Konfigurationen in einer bestimmten Ausführung möglicherweise zu einer Konfiguration führen können, in der ein bestimmtes Prädikat gilt, und für welche Konfiguration dies zutrifft. Die von der Modellprüfungsanwendung abgeleiteten Ausdrücke sind „Look-ahead" Prädikate.
Kontroll-/Datenflußgraphen (CDGs)
71 zeigt einen Kontroll-/Datenflußgraph (CDG) 7100. CDG 7100 veranschaulicht Datenfluß-basierie transparente Handlungen 7102 und 7104 als Teil seiner Struktur. CDG 7100 ist allgemein wie ein DCG konstruiert, erlaubt aber zudem sowohl Datenport 7106 als auch 7108 und Datenflußknoten 7110 und 7112. Innerhalb dieser Konstruktion ist Datenflußhandlungen erlaubt, Kontrolländerungen zu verursachen.
Ein CDG ist ein Triple, G = (Γf, Δf; Ef), in dem

• Γf ein Satz von Konjunktions- und Handlungsknoten ist, d.h. Γf ⊆ (C ∪ A), in dem C die Gesamtheit aller möglichen Konjunktionsknoten und A die Gesamtheit aller möglichen Handlungen ist.
• Δf ein Satz von Disjunktions- und Datenflußknoten ist, d.h. Δf ⊆ (D ∪ F), in dem D die Gesamtheit aller möglichen Disjunktionsknoten und F die Gesamtheit aller möglichen Datenflußknoten ist.
• Ef ⊆ [{Tf, Tt} × {Hf, Ht} × {T, N} × ((Γf × Δf) ∪ (Δf × Γf))] ein Satz gerichteter Kanten ist, die entweder mit T (Transient) oder N (Continuous) benannt sind.

A. Transaktions-/Beschränkungskonflikte
Transaktionen sind Teil der Koordinatordefinition. Sie werden jedoch gewöhnlich nicht direkt vom Koordinator ausgeführt. Transaktionen können von Komponenten eingeleitet werden, und Antworten müssen oft von Komponenten, nicht vom Koordinator selbst erzeugt werden. Koordinatoren enthalten Beschränkungen, die eine Rolle bei der Durchsetzung dieser Semantiken spielen können, und es ist wichtig sicherzustellen, daß die Beschränkungen einer Komponente konsistent mit den vom Koordinator vorgegebenen Transaktionen sind.
1. Dedizierter RPC
72 zeigt eine CDG 7200 Darstellung eines RPC-Systems. CDG 7200 zieht keine Kopplung zwischen Kontrolle und Daten in Betracht. Kontrolle hat zwei Aspekte. Der erste Kontrollaspekt ist statische (steady-state) Kontrolle, wobei die Übergänge von einem in einen anderen Zustand unter globaler Kontrolle stehen. Der zweite Kontrollaspekt ist die Wechselwirkung zwischen Kontrolle und Daten. Kontrolle muß typisch berücksichtigen, wie das Softwaresystem in Form von Parametern mit der Übertragung von Daten für Empfangs- und Rückgabewerte umgeht.
B. Partitionierung von DCGs über Nur-Meldungs-Barrieren hinweg
Genau wie SCGs und DCGs über Nur-Handlungs-Barrieren hinweg durch Vorlage-basierte Graphtransformationen partitioniert werden können, können sie über Barrieren hinweg partitioniert werden, die Nur-Meldungs-Verkehr zulassen. Die erste Stufe in dieser Transformation entspricht der obigen Beschreibung mit Bezug auf SCGs und CDGs. 73A zeigt den zweiten Schritt in der Partitionierung eines CDG 7300 über eine Nur-H- Barriere 7302 hinweg. In 73A besteht der zweite Schritt in der Umwandlung jeder Handlung auf der Barriere in ergänzende Handlungen und Meldungen. 73B zeigt den Graphen von DCG 6202 aus 62B, wobei die Nur-Handlungs-Barriere in eine Nur-Meldungs-Barriere 7304 umgewandelt wurde.
C. Datenflußkonsistenz und SDF-Extraktion
Datenflußkonsistenz bedeutet, daß bei Betrachtung des Systems als Ganzes die Produktionsraten kompatibel mit ihren entsprechenden Verbrauchsraten sind. Ein System, das im Sinne von Datenfluß konsistent ist, weist keine Konfiguration auf, in welcher auf irgendeinem Pfad die Produktion größer als der Verbrauch ist. Wenn Unstimmigkeiten dieser Art nicht im Voraus nachgewiesen werden, kann es schwierig sein, Fehler wie Speicherlecks und andere Fehler zu finden, bei denen Daten vor ihrer Verarbeitung (je nach Warteschlangenmanagement-Vorgehensweisen) verlorengehen oder überschrieben werden.
Synchrone Datenflußextraktion für diese Datenflußgraphen wird in zwei Teilen vorgenommen. Als Erstes wird ein Konstantraten-Sub-DAG durch ein Paar von Schnitten abgeschirmt. Ein Konstantraten-sub-DAG ist ein gerichteter azyklischer Datenflußgraph, in dem jeder Port konstante Token-Raten hat. Bei einem gegebenen Konstantraten-Sub-DAG ist jede Kante eine lineare Relation zwischen zwei Datenflußhandlungen. Zweitens können durch Auflösen einer konsistenten linearen Gleichung Plankomponenten für jeden Knoten gefunden werden. 74A zeigt einen CDG 7400 mit einem Satz von Meldungsratengarantien 7402. 74B zeigt einen auf CDG 7400 basierenden Datenflußgraph 7404. In 74A und B ist der Anfang jeder Kante 7406 mit einer Produktionsrate 7408 benannt, und die Senke ist mit einer Verbrauchsrate 7410 benannt. Inkonsistente Serien von Gleichungen führen nicht zu einer Lösung und stellen zudem inkonsistenten Datenfluß dar. Somit kann ein Algorithmus sowohl für Datenflußkonsistenz als auch SDF-Extraktion verwendet werden.
1. Auffinden von normalisierten Plankoeffizienten
Plankoeffizienten geben an, wie oft eine bestimmte Komponente sequentiell auszuführen ist, um alle von einer Komponente früher im Datenflußgraphen erzeugten Tokens zu verbrauchen. Das Problem besteht jetzt darin, einen Satz von praktischen Mindest-Plankoeffizienten zu finden. Die Mindest-Plankoeffizienten für Datenflußhandlungen a, b, c und d (in 74B dargestellt) sind mit Ao, Bo, Co und Do bezeichnet. Praktische Plankoeffizienten müssen natürliche Zahlen sein, weil es typisch nicht möglich ist, eine Komponente weniger als einmal (d.h. als Bruchzahl) auszuführen. Um diese zu erhalten, ist jedoch ein Zwischenschritt erforderlich, wobei rationale relative Plankoeffizienten benutzt werden. Relative Plankoeffizienten sind die durch den Koeffizienten einer bestimmten Komponente dividierten Mindest-Koeffizienten. Der Plankoeffizient für Komponente a, normalisiert auf den Koeffizienten von Komponente d, ist mit Ad bezeichnet. Der Wert von Dd ist als 1 definiert.
Das Auffinden von relativen Plankoeffizienten wird dadurch erreicht, daß zwischen Knotenpaaren ein Satz von relativen Planbeschränkungen abgeleitet wird. Jede interne Kante in einem Konstantraten-Cluster muß auf jeder Seite konstante Token-Raten haben. Die relativen Raten für zwei Knoten x und y, die durch eine Kante mit Token-Raten von m auf der x-Seite und n auf der y-Seite verbunden sind, ist nx = my, was bedeutet, daß jedesmal wenn x n-mal feuert, y m-mal feuern muß. Diese Beziehung gilt für alle gültigen praktischen und relativen Planungskoeffizienten, nicht nur für die Mindest-Koeffizienten.
Normalisierte Planungsraten können im Sinne einer einzelnen Komponentenreferenz ausgedrückt werden. Zu diesem Zweck wird jeder Satz relativer Raten zuerst als lineare Gleichung ausgedrückt. Beispielsweise sei Az der normalisierte Planungskoeffizient für Komponente a und Bz der normalisierte Planungskoeffizient für Komponente b. Ihre relative Koeffizienten-Beziehung wird als nAz – mBz = 0 ausgedrückt. Und somit lösen wir, für die relative Verhältnismatrix –R, für den Vektor des Planungskoeffizienten im Sinne von z oder
^Γz, mit –R·^Γz = ^1z, worin ^Γz
ein Vektor ist, der außer in der z Position immer Null ist.
Für Datenflußgraph 7404 unter Einsatz von d als Referenzkomponente ergibt sich Folgendes:
Bei Lösen von R·Γ_d = 1_d für Γ_d ergibt sich:
Hinweis: die ersten drei Reihen von –R entsprechen den drei Kanten in Datenflußgraph 7404.
Hinweis: ^Γd hat eine Lösung, wenn, und nur wenn, der Datenflußgraph konsistent ist. Grapheninkonsistenz ist nur möglich, wenn es mindestens so viele Kanten wie Handlungen gibt, d.h. wenn das System der Gleichungen überbestimmt ist. Wenn die Gaußsche Eliminierung zum Lösen des Matrixsystems benutzt wird, besteht das Ziel bei einem überbestimmten System darin, eine Reihe (typisch die letzte) zu stornieren, indem für diese Reihe nur Nullen eingesetzt werden. Wenn der Datenflußgraph inkonsistent ist, ergibt sich für ihn eine Reihe in Form von [0 0 0 0 ... 0|x], worin x ≠ 0.
75 zeigt den Datenflußgraph 7500. In Datenflußgraph 7500 ist die Gaußsche Startmatrix wie folgt:
Nach Eliminierung der letzten Reihe und dem Versuch, sie durch Nullen zu ersetzen, sieht das Ergebnis wie folgt aus:
Das obige Ergebnis zeigt, daß das durch Datenflußgraph 7500 dargestellte System nicht ordnungsgemäß geplant werden kann. Des weiteren, auch ohne genaue Produktions- und Verbrauchsraten, kann eine ähnliche Prozedur benutzt werden, um inkonsistenten Datenfluß nachzuweisen.
2. Praktische Planungskoeffizienten
Für die Ausführung eines Systems ist erforderlich, daß alle Planungskoeffizienten Ganzzahlen sind. Dies wird dadurch ermöglicht, daß man den kleinsten gemeinsamen Nenner (LCD) eines normalisierten Planungskoeffizienten findet und ihn durch multipliziert. Für 74B ist der LCD 30, und somit:
3. Planungsreihenfolge
Beim Modellieren der Kausalität im Softwaresystem muß die Reihenfolge der Komponenten im Plan konsistent sein. Eine ordnungsgemäße Reihenfolge kann durch eine topologische Art von Datenflußgraph bestimmt werden (z.B. b, a, c, d für das Beispiel in 74B). Durch Kombination der durch Vektor Γo dargestellten Planungskoeffizienten mit Reihenfolgeordnung läßt sich ein kompletter konsistenter Plan aufstellen. Für Datenflußgraph 7404 ist der komplette konsistente Plan wie folgt: 9b·8a·12c·30d. Das bedeutet, Ausführung von Handlung b neunmal mit Puffern der Ergebnisse, dann Ausführung von a achtmal mit Puffern der Ergebnisse, dann Ausführung von c zwölfmal mit Puffern der Ergebnisse, und schließlich dreißigmal Ausführung von d.
Für den Fachmann ist zu erkennen, daß an den Details der oben beschriebenen Ausführungsform oder -formen viele Änderungen vorgenommen werden können, ohne von den oben beschriebenen Prinzipien abzuweichen. Der Geltungsbereich der vorliegenden Erfindung ist daher ausschließlich durch die folgenden Ansprüche festzulegen.

Claims

Verfahren, welches von einem Softwareanalysetool zum Identifizieren von Beschränkungsdurchsetzungskonflikten in einem Softwaresystem durchgeführt wird, welches wenigstens zwei Softwareelemente (100) und wenigstens eine Beschränkung (618, 620) umfaßt, wobei jedes Softwareelement (100) wenigstens eine Betriebsart (102) umfaßt, die, wenn sie aktiviert ist, es einer oder mehreren Handlungen (104) ermöglicht, durch ein Ereignis auslösbar zu sein, und wobei jede Beschränkung (618, 620), wenn sie durchgesetzt ist, einen Output erzeugt, der den Aktivierungszustand von wenigstens einer Betriebsart (102) beeinflußt, wobei das Verfahren umfaßt: Erzeugen eines Disjunktionsknotens (4304) für jede Betriebsart (102); Erzeugen eines Konjunktionsknotens (4300) für jede Beschränkung (618, 620); Erzeugen einer gerichteten Kante (4310) für jede Beschränkung, die einen Output erzeugt, von dem entsprechenden Konjunktionsknoten (4300) zu dem Disjunktionsknoten (4304) jeder Betriebsart (102), deren Aktivierungszustand von dem Output beeinflußt ist, wobei jede gerichtete Kante (4310) einen Wert auf dem Disjunktionsknoten (4304) geltend macht, welcher auf den Einfluß schließen läßt, der von der Beschränkung (618, 620) auf den Aktivierungszustand ausgeübt wird; und Darstellen von Kontrollwechselwirkungen zwischen den Softwareelementen in einem statischen Kontrollgraph, welcher umfaßt: eine erste Gruppe graphischer Symbole, wobei jedes Symbol einen Konjunktionsknoten (4300) darstellt: eine zweite Gruppe graphischer Symbole, wobei jedes Symbol einen Disjunktionsknoten (4304) darstellt; und eine dritte Gruppe graphischer Symbole, wobei jedes Symbol eine gerichtete Kante (4310) darstellt und visuelle Merkmale eines Ursprungsknotens und eines Zielknotens umfaßt, wobei ein Beschränkungsdurchsetzungskonflikt als ein Disjunktionsknoten (4304) identifiziert ist, der zwei oder mehrere einfallende gerichtete Kanten (4310) aufweist, die verschiedene Werte geltend machen.
Verfahren, welches von einem Softwareanalysetool nach Anspruch 1 durchgeführt wird, wobei der Output einer Beschränkung (618, 620) durch den Aktivierungszustand von wenigstens einer Betriebsart (102) beeinflußt wird, und das Verfahren des weiteren umfaßt: Erzeugen einer gerichteten Kante (4310) für jede Betriebsart (102), deren Aktivierungszustand den Output einer Beschränkung (618, 620) beeinflußt, von dem entsprechenden Disjunktionsknoten (4304) zu dem Konjunktionsknoten (4300) einer Beschränkung (618, 620), deren Output von dem Aktivierungszustand beeinflußt ist.
Verfahren, welches von einem Softwareanalysetool nach Anspruch 1 oder 2 durchgeführt wird, wobei das Softwareanalysetool eine Datenstruktur zum Darstellen von Kontrollbeschränkungen und Kontrollhandlungen des Softwaresystems implementiert, wobei die Datenstruktur umfaßt: eine Gruppe konjunktiver boolscher Guards von Zustandsänderungen (618, 620) innerhalb des Softwaresystems; eine Gruppe boolscher Guards von funktionalen Objekten (102) innerhalb der Softwareelemente (100); eine Gruppe funktionaler Kontrollobjekte (104) innerhalb der Softwareelemente (100), wobei jedes funktionale Kontrollobjekt (104) auf eine Kontrollwechselwirkung anspricht und in der Lage ist, eine Kontrollwechselwirkung zu erzeugen; eine Gruppe von Datenflußknoten, wobei jeder davon eine Datenflußwechselwirkung zwischen einem ersten und einem zweiten Softwareelement darstellt; und eine Gruppe von Vergleichsverbindungen zwischen zwei Elementen aus der Gruppe der konjunktiven boolschen Guards (618, 620), der Gruppe der boolschen Guards von Objekten (102) und der Gruppe funktionaler Kontrollobjekte (104), wobei jede Vergleichsverbindung eine Implikation zwischen den beiden Elementen, welche sie verbindet, darstellt.
Verfahren, welches von einem Softwareanalysetool nach Anspruch 1 durchgeführt wird, wobei der statische Kontrollgraph des weiteren eine Gruppe von Aktionsknoten (5702) umfaßt, von denen jeder ein funktionales Objekt (104) innerhalb einer der Softwareele mente (100) darstellt, das auf Kontrollwechselwirkungen anspricht und Kontrollwechselwirkungen erzeugt.
Verfahren, welches von einem Softwareanalysetool nach einem der vorhergehenden Ansprüche durchgeführt wird, wobei das Softwaresystem einen Zustandsraum und einen anfänglichen Zustand aufweist, und das Softwareanalysetool des weiteren Vorrichtungen zum Konvertieren der statischen Kontrollgraphendarstellung des Softwaresystems in ein binäres Entscheidungsdiagramm des Softwaresystems umfaßt, wobei die Umwandelvorrichtung die folgenden Schritte implementiert: Transformieren des Kontrollgraphen, um einen möglichen nächsten Zustand des Softwaresystems nach einer vorherbestimmten Zeitperiode auszudrücken; und Erzeugen eines binären Entscheidungsdiagramms, welches auf dem transformierten Kontrollgraphen basiert, wobei bekannte statische Fehlerprüftechniken angewandt werden können, um unerwartetes Verhalten des Softwaresystems weiter zu identifizieren, ohne die Kosten eines vollständigen Ausarbeitens des Zustandsraumes des Softwaresystems hinzunehmen.
Verfahren, welches von einem Softwareanalysetool nach Anspruch 5 durchgeführt wird, wobei der Schritt des Transformierens des Kontrollgraphen ein Entrollen des Kontrollgraphen umfaßt.
Verfahren, welches von einem Softwareanalysetool nach Anspruch 6 durchgeführt wird, wobei das Erzeugen des binären Entscheidungsdiagramms das Verwenden eines Apply-Algorithmus auf einer charakteristischen Funktion des entrollten Kontrollgraphen umfaßt.
Verfahren, welches von einem Softwareanalysetool nach Anspruch 6 durchgeführt wird, wobei das Entrollen des Kontrollgraphen umfaßt: Erzeugen einer Kopie jedes Disjunktionsknotens (4304), wobei jeder Disjunktionsknoten (4304) einen boolschen Guard von einem funktionalen Objekt (102) innerhalb eines der Softwareelemente (100) darstellt; Erzeugen einer Kopie jedes Konjunktionsknotens (4300), wobei jeder Konjunktionsknoten (4300) einen konjunktiven boolschen Guard von Zustandsänderungen (618, 620) innerhalb des Softwaresystems darstellt; Erzeugen einer Kopie jedes Aktionsknotens (5702), wobei jeder Aktionsknoten (5702) ein funktionales Objekt (104) innerhalb eines der Softwareelemente (100) darstellt, welches auf eine Kontrollwechselwirkung anspricht und fähig ist, eine Kontrollwechselwirkung zu erzeugen, falls das funktionale Objekt (104), welches es darstellt, eine vorbestimmte Funktion ohne eine vorbestimmte Verzögerung durchführt: Erzeugen einer Überwachungskante (6406) für jeden der verzögerten Aktionsknoten (5702), welcher ein funktionales Objekt (104) innerhalb eines der Softwareelemente (100) darstellt, das eine vorbestimmte Verzögerung bei Ansprechen auf oder Erzeugen von einer Kontrollwechselwirkung aufweist, um den verzögerten Aktionsknoten mit einem entsprechenden Knoten (6408) in dem Kontrollgraphen (6400) zu verbinden, der den Anfangszustand des Systems darstellt, und Erzeugen einer Durchsetzungskante (6410), um den entsprechenden Knoten (6408) in dem Kontrollgraph (6400), welcher den Anfangszustand des Systems darstellt, mit einem entsprechenden nächsten Knoten (6412), der den möglichen nächsten Zustand des Systems darstellt, zu verbinden; Verbinden der gerichteten Kante (6414) für eine gerichtete Kante, die auch eine Ereigniskante (6414) ist, mit einem erzeugten Ereignisdisjunktionsknoten (6416), der ein Ereignis darstellt, welches durch den entsprechenden Knoten (6420) in dem Kontrollgraphen (6400), welcher den anfänglichen Zustand des Systems darstellt, erzeugt wird; Erzeugen einer Kante für jeden erzeugten Ereignisdisjunktionsknoten (6416) von dem erzeugten Ereignisdisjunktionsknoten (6416) zu einem Ereigniskonjunktionsknoten (6418); Erzeugen einer Kante (6414) für jeden Ereigniskonjunktionsknoten (6418) von dem Knoten (6420), der das Ereignis erzeugt hat, zu dem Ereigniskonjunktionsknoten (6418), und Erzeugen einer Kante von dem Ereigniskonjunktionsknoten (6418) zu der Kopie des Knotens, der das Ereignis erzeugt hat.